[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-858":3,"consumer-news-interaction-858":39,"consumer-news-related-858":42},{"detail":4,"item":35},{"card":5,"schemaVersion":22,"fields":23,"content":29},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":15,"href":16,"sourceName":12,"meta":17,"metrics":19,"tags":20,"resolved":21},"NEWS_ARTICLE:858","news","NEWS_ARTICLE",858,"资讯","Agent上下文管理概述-1","博客园","Agent上下文管理核心是组织与压缩。组织采用静态+动态提示词：启动时载入系统提示词、工具描述、Skill名称路径；运行时拼接用户消息、工具调用及结果，并依KV缓存命中优化排列。压缩需兼顾速度与token占用。工业界常用确定性清理加摘要：Pi\n  Agent压缩历史后重建上下文，OpenCode对工","https:\u002F\u002Ffiles.seeusercontent.com\u002F2026\u002F08\u002F19\u002FxH5o\u002F20260819210036197.png","","\u002Fnews\u002F858",[18],"2026",{},[],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":24,"summary":13,"description":13,"publishTime":25,"updateTime":26,"sourceUrl":27,"language":28},"Big-Yellow-J","2026-09-01T21:17","2026-09-02T20:37:50","https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274","中文",{"format":30,"policy":31,"normalized":21,"html":32,"text":33,"wordCount":34,"hasBody":21},"HTML","NEWS_CONTENT_V1","\u003Cp>agent在运行过程中一般会去将历史、任务状态、记忆等内容进行“选择拼接”去构成完整的上下文（context）去交给大模型处理，其中就有几点设计理念需要考虑：1、大模型推理过程中都会选择kv-cache去加速推理，那么如何保证对话过程中cache命中高加快推理，亦或者说频繁的工具调用\u002F文本内容如何拼接到上下文中；2、模型输入上下文总是有限的如何保证在超出上限之后对上下文压缩，而且压缩还不能都是关键信息；3、过长的上下文反而会去影响到模型的效果\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fn1\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">[1]\u003C\u002Fa>，因此这些都是上下文管理需要考虑的事情。\u003C\u002Fp>\n\u003Ch2>上下文组织\u003C\u002Fh2>\n\u003Cp>claude code\u002Fcodex\u002Fpi agent等在构建上下文中一般选择的架构组织方式是：\u003Ccode>静态提示词+ 动态提示词\u003C\u002Fcode>，其中\u003Cstrong>静态提示词\u003C\u002Fstrong>指的一般是不会改变的提示词，如系统提示词、工具介绍等，而\u003Cstrong>动态提示词\u003C\u002Fstrong> 指的是经常发生改变内容，比如用户内容输入等，在上文组织过程中以pi agent为例介绍其组织过程，在第一次启动之后其context为：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>AgentContext\n├── systemPrompt\n│    ├── Pi Base System Prompt\n│    ├── Tool 使用说明\n│    ├── Guidelines\n│    ├── APPEND_SYSTEM.md\n│    ├── AGENTS.md \u002F CLAUDE.md\n│    ├── Available Skills Index\n│    └── Current Working Directory\n├── messages\n│    └── []\n└── tools\n     ├── read schema\n     ├── bash schema\n     ├── edit schema\n     ├── write schema\n     └── extension tool schemas...\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>这里 \u003Ccode>messages\u003C\u002Fcode> 还是空的，因为用户还没有真正开始对话；但 System Prompt 和可用 Tool 已经准备完成。Pi 会在启动阶段读取 \u003Ccode>AGENTS.md\u003C\u002Fcode>、\u003Ccode>CLAUDE.md\u003C\u002Fcode> 等项目规则，同时扫描当前可用的 Skills（\u003Cstrong>Skill 并不会在启动时把完整内容全部塞进 Context\u003C\u002Fstrong> 一般只会保存 description、name、path）。\u003Cstrong>不断对话过程中\u003C\u002Fstrong> \u003Ccode>用户输入问题->调用工具\u003C\u002Fcode> 此过程会将工具结果 \u003Cem>补充到对话结尾\u003C\u002Fem>\u003C\u002Fp>\n\u003Ch2>上下文压缩\u003C\u002Fh2>\n\u003Cp>因为模型上下文是有限的因此不对对话过程中就需要去对内容进行压缩保证后续对话进行，对于普通对话压缩可能就是对上下文进行简短即可，但是对于Agent而言上下文不是一篇单纯的长文本，而是一个持续变化的运行状态。压缩策略也比较多一般而言压缩需要同时考虑：速度、效率（压缩后内容尽可能少的占用token），从两个角度出发了解上下文压缩策略：\u003C\u002Fp>\n\u003Ch3>常用Agent架构中使用的压缩策略\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>工业 Agent 很少使用 LLMLingua 式 Token 分类器直接压缩整个对话。更常见的是“确定性选择与清理 + 专用 LLM 生成任务交接摘要 + 原始尾部 + 外部可恢复状态”。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch4>1、Pi Agent 上下文压缩策略\u003C\u002Fh4>\n\u003Cp>Pi 的自动触发条件是：\u003Cspan>\\(\\text{ContextTokens}> \\text{ContextWindow}-\\text{ReserveTokens}\\)\u003C\u002Fspan> 其中 \u003Ccode>reservetokens\u003C\u002Fcode> 表示给下一次模型输出和工具执行留空间，除此之外在压缩过程中假如对话窗口为 \u003Ccode>SystemPrompt+Context_i\u003C\u002Fcode> 其中 \u003Ccode>Context_i\u003C\u002Fcode>可能就是表示一轮对话结果（\u003Ccode>User+Assistance+toolCall+toolResult\u003C\u002Fcode> 其中 \u003Ccode>toolCall\u003C\u002Fcode> 表示调用工具名称、 \u003Ccode>toolResult\u003C\u002Fcode> 表示对应的工具返回的结果）在Pi的\u003Cem>第一轮压缩过程\u003C\u002Fem>中它会先从\u003Cstrong>最新消息往前扫描\u003C\u002Fstrong>，尽量找到一段近期上下文（比如检索到 \u003Ccode>i=2\u003C\u002Fcode> 那么就会将前两轮对话历史结果进行压缩）在压缩过程中通过\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fearendil-works\u002Fpi\u002Fblob\u002Fee29aa118bdeb7d8c4fdafa81130e0c61f8e0423\u002Fpackages\u002Fcoding-agent\u002Fsrc\u002Fcore\u002Fcompaction\u002Fcompaction.ts#L467\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">提示词\u003C\u002Fa>引导进行“结构化压缩”比如说：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>## Goal\n当前任务最终目标\n\n## Constraints & Preferences\n用户约束、技术限制、不允许执行的操作\n\n## Progress\n### Done\n已经完成的工作\n\n### In Progress\n当前正在做什么\n\n### Blocked\n被什么问题阻塞\n\n## Key Decisions\n关键决策，以及做出决策的原因\n\n## Next Steps\n后续动作\n\n## Critical Context\n关键报错、实体、路径、函数名、API和数据结构\n\n## Read Files\n已经读取的文件\n\n## Modified Files\n已经修改的文件\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>压缩后不是将内容进行删除只是以后\u003Cstrong>不再发送给 LLM\u003C\u002Fstrong>。官方文档明确描述为：追加 \u003Ccode>CompactionEntry\u003C\u002Fcode>，然后下一轮根据 \u003Ccode>firstKeptEntryId\u003C\u002Fcode> 重建 Context，所以下一轮对话内容为：\u003Ccode>SystemPrompt+CompactionSummary+Context_j\u003C\u002Fcode>。在\u003Cem>后续n轮压缩过程中\u003C\u002Fem> 会直接把 上一轮的压缩内容和最近需要压缩的内容一起进行压缩。\u003C\u002Fp>\n\u003Cp>从上面过程可以发现Pi里面压缩比较简单粗暴并\u003Cstrong>没有去区分tool result直接通过一个prompt进行全部压缩\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Ch4>2、Open Code 上下文压缩策略\u003C\u002Fh4>\n\u003Cp>OpenCode 比 Pi 更复杂一点，因为它实际上有两个完全不同的 Context Reduction 层：\u003Ccode>Tool Result Pruning\u003C\u002Fcode> 和 \u003Ccode>Conversation Compaction\u003C\u002Fcode>。\u003Cstrong>第一层对工具调用结果进行压缩\u003C\u002Fstrong>（也容易理解在coding任务中一个 \u003Ccode>grep\u003C\u002Fcode>的工具调用，返回的结果可能就有上千行内容这些内容不是都有用的，只需要对他们进行标记后续去掉就行）在对话中一轮工具调用可能是 \u003Ccode>Assistance+ toolCall+ toolResult+ Assistance\u003C\u002Fcode> OpenCode 会把旧 Tool Result 标记为 compacted，其中\u003Cstrong>它主要压掉的是 Tool Result 的 output，而不是直接把整个 Tool Call + Assistant 消息链都删掉。\u003C\u002Fstrong> 换言之在进行对话过程中 \u003Ccode>toolResult\u003C\u002Fcode> 是有生命周期的，这一层没有去调用llm处理，在代码里面会对旧 completed tool parts 上标记 \u003Ccode>compacted\u003C\u002Fcode>，而不是调用 LLM 改写这些结果。\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Assistant: 我先搜索 refresh_token。 \nToolCall: grep -R \"refresh_token\" src\u002F \nToolResult: src\u002Fauth\u002Ftoken.py:... src\u002Fauth\u002Fservice.py:... src\u002Fapi\u002Flogin.py:... ...... 几千行内容 \nAssistant: 主要逻辑位于 src\u002Fauth\u002Ftoken.py，接下来读取该文件。\n\n----- 进行 tool result pruning -----\nAssistant: 我先搜索 refresh_token。 \nToolCall: grep -R \"refresh_token\" src\u002F \nToolResult: [旧 output 已从 Active Context 中移除] \nAssistant: 最终定位到 src\u002Fauth\u002Ftoken.py\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cblockquote>\n \u003Cp>OpenCode 并不知道某条 Tool Result 在语义上“已经没用了”。它采用的是一种更工程化的启发式规则：近期工具输出优先保护，较老、已完成、非保护类型的工具输出，在累计超过一定 Token 预算以后直接从 Active Context 中驱逐。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>\u003Cstrong>第二层对内容进行压缩\u003C\u002Fstrong>这个过程和上面的Pi的处理类似通过\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fanomalyco\u002Fopencode\u002Fblob\u002Fdev\u002Fpackages\u002Fcore\u002Fsrc\u002Fsession\u002Fcompaction.ts\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">提示词\u003C\u002Fa>进行结构化压缩，不过对话过程中进行压缩之后为了保证agent loop不被打断，会将对话重新拼接到压缩后内容后面（\u003Ccode>Summary + RecentContext\u003C\u002Fcode>）\u003C\u002Fp>\n\u003Ch4>3、其他闭源压缩策略\u003C\u002Fh4>\n\u003Cp>Manus 强调将网页、文件、中间结果和长 Tool Output 写入文件系统，只在活动 Context 中保留路径、URL、对象 ID 和简要结论。Todo \u002F Plan 会不断重写到最近上下文，形成 Goal Recitation\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fn2\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">[2]\u003C\u002Fa>。Langchain DeepAgents会先把大型 Tool Result 写入文件，并在 Context 中留下文件指针和预览；必要时再对旧历史生成 Summary，同时保留完整 Transcript 作为 Canonical Record\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fn3\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">[3]\u003C\u002Fa>。\u003C\u002Fp>\n\u003Ch3>学术领域中常用的压缩策略\u003C\u002Fh3>\n\u003Cp>个人认为工程化实践上可以重点关注两点策略：\u003Cstrong>1、离散文本与token级压缩\u003C\u002Fstrong> 以及 \u003Cstrong>2、面向Agent运行轨迹压缩\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Ch4>1、离散文本与token级压缩\u003C\u002Fh4>\n\u003Cblockquote>\n \u003Cp>推荐直接使用: \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FLLMLingua\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FLLMLingua\u003C\u002Fa>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>这一类方法最终仍然输出可读文本，对于原始输入文本 \u003Cspan>\\(X=[x_1,x_2,\\ldots,x_n]\\)\u003C\u002Fspan> 通过压缩器为每个 Token 或文本片段决定 \u003Cspan>\\(z_i\\in\\{0,1\\}\\)\u003C\u002Fspan> 最终保留：\u003Cspan>\\(X'=\\{x_i\\mid z_i=1\\}\\)\u003C\u002Fspan>（一般希望\u003Cspan>\\(\\max_{X'}\\operatorname{Utility}(X',Q) \\quad \\text{s.t.} \\quad |X'|\\le B\\)\u003C\u002Fspan> 其中 \u003Cspan>\\(B\\)\u003C\u002Fspan> 为压缩后的token budget）。\u003Cbr>\n  在论文 \u003Cstrong>Selective Context\u003C\u002Fstrong>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fn4\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">[4]\u003C\u002Fa>和\u003Cstrong>LLMLingua-2\u003C\u002Fstrong>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fn5\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">[5]\u003C\u002Fa>处理思路类似都是 \u003Cem>对不重要token进行过滤只将重要token进入模型推理\u003C\u002Fem> ，以selective context为例其处理思路很简单对于较长的prompt直接计算 \u003Cspan>\\(I(x)=-\\log P(x)\\)\u003C\u002Fspan> 其中 \u003Cspan>\\(x\\)\u003C\u002Fspan> 表示较长的prompt而 \u003Cspan>\\(P\\)\u003C\u002Fspan> 对应一个较小的模型而后对计算结果计算阈值过滤即可达到压缩目的（\u003Cstrong>实际过程llm类似prefill处理prompt这样就可以得到每一个token的logits然后阈值过滤即可\u003C\u002Fstrong>）下图红色表示保留文本\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"https:\u002F\u002Fi1.wp.com\u002Ffiles.seeusercontent.com\u002F2026\u002F08\u002F19\u002FxH5o\u002F20260819210036197.png?w=720&quality=65&strip=all\" alt=\"image.png585\">\u003C\u002Fp>\n\u003Cp>这一类方法最大的优点是兼容闭源模型；最大的局限是：\u003Cstrong>Token 级“相关性”不等于 Agent 状态级“未来效用”。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch4>2、latent压缩\u003C\u002Fh4>\n\u003Cp>将长 Context 编码 \u003Cspan>\\(X\\in\\mathbb{R}^{n\\times d}\\)\u003C\u002Fspan> 压缩为：\u003Cspan>\\(Z=C_{\\phi}(X)\\in\\mathbb{R}^{m\\times d},\\quad m\\ll n\\)\u003C\u002Fspan> 其目标不是生成可读摘要，而是\u003Cstrong>让下游模型能够从少量隐状态中恢复任务所需信息\u003C\u002Fstrong>，简而言之将中间状态结果进行压缩处理，不过对于这种策略需要考虑一点就是LLM都是自回归的，就需要考虑如何将内容进行拼接输入。比如在论文\u003Cstrong>ICAE\u003C\u002Fstrong>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fn6\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">[6]\u003C\u002Fa>直接将原本的大模型推理过程\u003Ccode>Context+Prompt+Deocer\u003C\u002Fcode> 替换为 \u003Ccode>Context+Summary\u003C\u002Fcode>在经过一次编码后在将 \u003Ccode>Summary+Prompt\u003C\u002Fcode> 就行decoder处理。训练分为两部分预训练和微调，预训练阶段\u003Cstrong>文本复写任务\u003C\u002Fstrong>通过MemoryTokens去复写后面内容（相当于截断文本而后decoder通过MemoryTokens去复写出来）以及 \u003Cstrong>文本续写任务\u003C\u002Fstrong>（或者说“问题回答”）。在后续论文\u003Cstrong>500xCompressor\u003C\u002Fstrong>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fn7\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">[7]\u003C\u002Fa>中处理思路类似不过将 \u003Ccode>embeding\u003C\u002Fcode> 替换为 \u003Ccode>KV-value\u003C\u002Fcode>去实现压缩。\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"https:\u002F\u002Fi1.wp.com\u002Ffiles.seeusercontent.com\u002F2026\u002F08\u002F21\u002Fht4J\u002F20260821222214428.png?w=720&quality=65&strip=all\" alt=\"image.png772\">\u003C\u002Fp>\n\u003Ch4>3、面向Agent运行轨迹压缩\u003C\u002Fh4>\n\u003Cp>主要是将 \u003Cspan>\\(t\\)\u003C\u002Fspan> 轮中对话结果进行压缩比如说 \u003Cspan>\\(S_t=\\{G,C,P,D,E,F,A_t,O_t\\}\\)\u003C\u002Fspan> 其中内部就是Agent不同运行轨迹状态因此轨迹压缩的目标是构造 \u003Cspan>\\(\\hat{S}_t=C(S_{1:t})\\)\u003C\u002Fspan> 。\u003Cstrong>MEM1\u003C\u002Fstrong>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fn8\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">[8]\u003C\u002Fa>在处理React每一步推理过程中进行“微压缩”然后进入下一轮的推理在react中每一轮推理都会直接将上一轮内容叠加到状态里面进行推理。\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"https:\u002F\u002Fi1.wp.com\u002Ffiles.seeusercontent.com\u002F2026\u002F08\u002F20\u002FGdy7\u002F20260820163238916.png?w=720&quality=65&strip=all\" alt=\"image837\">\u003C\u002Fp>\n\u003Cp>比如说上图中左下方每一次act推理过程中都会将工具结果等都记录到 \u003Ccode>IS\u003C\u002Fcode>中，再训练过程中因为每轮都有一个压缩处理因此在计算Attention过程中下一轮的 \u003Ccode><IS>\u003C\u002Fcode> 状态“看不到”前面状态结果（\u003Ccode>2D Attention Mask\u003C\u002Fcode>）。在\u003Cstrong>Context-folding论文\u003C\u002Fstrong>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fn9\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">[9]\u003C\u002Fa>和\u003Cstrong>论文 ACM\u003C\u002Fstrong>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fn10\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">[10]\u003C\u002Fa>中不是讲状态进行总结而是将状态进行“折叠”，比如在Context-folding中：\u003Cbr>\u003Cimg src=\"https:\u002F\u002Fi1.wp.com\u002Ffiles.seeusercontent.com\u002F2026\u002F08\u002F23\u002FvjS8\u002F20260823152852098.png?w=720&quality=65&strip=all\" alt=\"image665\">\u003C\u002Fp>\n\u003Cp>在上述过程中，工具调用产生的中间结果会被统一“折叠”，仅将 Sub-agent 最终返回的结果保留在主上下文中。该方法采用 Main Agent 与 Sub-agent 协同的架构：前者负责在 Planning State 中进行任务规划与子任务拆解，后者根据规划执行 ReAct 式推理及工具调用。与其他上下文压缩方法的主要区别在于，Sub-agent 的完整执行轨迹不会写入主上下文，只有其最终返回的结果会被保留。而ACM更加简单直接通过两个上下文管理工具，使代理能够模仿人类的记忆机制：manage_context，它将之前的转换压缩成简洁的摘要，并将原始消息卸载到磁盘上的外部文件中；以及 query_memory，它允许代理查询存储的原始消息以精确地检索信息。\u003C\u002Fp>\n\u003Ch4>4、KV cache压缩\u003C\u002Fh4>\n\u003Cp>KV Cache Compression 处理的是 Transformer 每层的 Key 和 Value：\u003Cspan>\\(K_l,V_l\\)\u003C\u002Fspan>，目标是在生成过程中只保留一部分历史 KV：\u003Cspan>\\((K'_l,V'_l)=\\operatorname{Select}(K_l,V_l,B_l)\\)\u003C\u002Fspan> 其中 \u003Cspan>\\(B_l\\)\u003C\u002Fspan> 是第 \u003Cspan>\\(l\\)\u003C\u002Fspan> 层的缓存预算，所以说严格意义上不太算是上下文压缩策略，在论文 \u003Cstrong>StreamingLLM\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fn11\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">[11]\u003C\u002Fa>中发现使用 windows attention并不能扩展长度（主要测试的是Llama-2模型，发现模型不能很好外推到训练长度之外），但是通过一种现象 attention sink（保留 起始token 的 KV ）能够恢复 windows attention 的效果。之所以出现这一现象是因为\u003Cstrong>起始 token 有着更高的注意力分数，即便是当它在语义上已经不重要了\u003C\u002Fstrong>（实验直接将其换成 \u003Ccode>\\n\u003C\u002Fcode> 对于表现影响很大）也依然如此。\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"https:\u002F\u002Fi1.wp.com\u002Ffiles.seeusercontent.com\u002F2026\u002F08\u002F21\u002FGr3b\u002F20260822010355744.png?w=720&quality=65&strip=all\" alt=\"image773\">\u003C\u002Fp>\n\u003Cp>操作方式也很简单在计算 windows attention 时候将开始的 \u003Cspan>\\(n\\)\u003C\u002Fspan> 个token保留即可（测试llama-2中 \u003Cspan>\\(n=4\\)\u003C\u002Fspan> ）\u003C\u002Fp>\n\u003Ch2>总结\u003C\u002Fh2>\n\u003Cp>对于 Agent 运行上下文，主要分为两大部分：\u003Cstrong>1、上下文组织\u003C\u002Fstrong>，可分为两个阶段：\u003Cem>启动时\u003C\u002Fem>，拼接系统提示词、Skills、工具 Description、必备文件（如 CLAUDE.md）等静态内容；\u003Cem>运行时\u003C\u002Fem>，持续拼接用户消息、Agent 回复、工具调用及工具结果。参考 Pi Agent 的组织方式，可以概括为：\u003Ccode>静态内容 + 用户消息 + Agent 交互轨迹 + 工具结果\u003C\u002Fcode>。\u003Cstrong>2、上下文压缩\u003C\u002Fstrong>，考虑到每个 LLM 的上下文窗口都存在上限，因此需要对内容进行压缩。综合工业实践和学术研究，较为稳妥的策略包括：\u003Cem>1、选择性保留工具结果\u003C\u002Fem>，例如 OpenCode 的 Tool Result Pruning 和 Context Folding。Agent 运行过程中，工具结果可能占用大量上下文，并且部分结果会过期、重复或可以重新获取，因此没有必要始终保留在主上下文中；\u003Cem>2、基于提示词进行摘要\u003C\u002Fem>，通过提示词将历史内容压缩为结构化摘要，同时保留任务目标、运行状态、执行进度、关键结论、环境变化、失败尝试和待办事项，具体可以参考 OpenCode、Pi Agent 和 Claude Code 的提示词设计；\u003Cem>3、选择性丢弃或 Token 级压缩\u003C\u002Fem>（谨慎使用），直接丢弃低价值、重复或可恢复的内容，或者通过离散 Token 压缩等算法缩短文本。此类方法只能尽量保持原始语义，无法保证关键信息完全不丢失；\u003Cem>4、运行状态压缩\u003C\u002Fem>（不建议作为应用层首选方案），直接对 KV-cache 等模型运行状态进行压缩或量化。这类方法主要用于降低显存占用和提高推理效率，并不等同于语义层面的上下文压缩。\u003C\u002Fp>\n\u003Ch2>参考\u003C\u002Fh2>\n\u003Chr>\n\n \u003Col>\n  \u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fpdf\u002F2307.03172\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Farxiv.org\u002Fpdf\u002F2307.03172\u003C\u002Fa> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fnref1\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">↩︎\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\n  \u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fmanus.im\u002Fblog\u002FContext-Engineering-for-AI-Agents-Lessons-from-Building-Manus\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Fmanus.im\u002Fblog\u002FContext-Engineering-for-AI-Agents-Lessons-from-Building-Manus\u003C\u002Fa> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fnref2\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">↩︎\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\n  \u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fdocs.langchain.com\u002Foss\u002Fpython\u002Fdeepagents\u002Fcontext-engineering\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Fdocs.langchain.com\u002Foss\u002Fpython\u002Fdeepagents\u002Fcontext-engineering\u003C\u002Fa> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fnref3\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">↩︎\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\n  \u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fpdf\u002F2310.06201\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Farxiv.org\u002Fpdf\u002F2310.06201\u003C\u002Fa> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fnref4\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">↩︎\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\n  \u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fpdf\u002F2403.12968\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Farxiv.org\u002Fpdf\u002F2403.12968\u003C\u002Fa> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fnref5\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">↩︎\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\n  \u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fpdf\u002F2307.06945\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Farxiv.org\u002Fpdf\u002F2307.06945\u003C\u002Fa> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fnref6\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">↩︎\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\n  \u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Faclanthology.org\u002F2025.acl-long.1219.pdf\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Faclanthology.org\u002F2025.acl-long.1219.pdf\u003C\u002Fa> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fnref7\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">↩︎\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\n  \u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fpdf\u002F2506.15841\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Farxiv.org\u002Fpdf\u002F2506.15841\u003C\u002Fa> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fnref8\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">↩︎\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\n  \u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fpdf\u002F2510.11967\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Farxiv.org\u002Fpdf\u002F2510.11967\u003C\u002Fa> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fnref9\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">↩︎\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\n  \u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fpdf\u002F2607.23809\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Farxiv.org\u002Fpdf\u002F2607.23809\u003C\u002Fa> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fnref10\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">↩︎\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\n  \u003Cli>\u003Cp>\u003Ca href=\"http:\u002F\u002Farxiv.org\u002Fabs\u002F2309.17453\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">http:\u002F\u002Farxiv.org\u002Fabs\u002F2309.17453\u003C\u002Fa> \u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FBig-Yellow\u002Fp\u002F22797274#fnref11\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">↩︎\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\n \u003C\u002Fol>","agent在运行过程中一般会去将历史、任务状态、记忆等内容进行“选择拼接”去构成完整的上下文（context）去交给大模型处理，其中就有几点设计理念需要考虑：1、大模型推理过程中都会选择kv-cache去加速推理，那么如何保证对话过程中cache命中高加快推理，亦或者说频繁的工具调用\u002F文本内容如何拼接到上下文中；2、模型输入上下文总是有限的如何保证在超出上限之后对上下文压缩，而且压缩还不能都是关键信息；3、过长的上下文反而会去影响到模型的效果[1]，因此这些都是上下文管理需要考虑的事情。 上下文组织 claude code\u002Fcodex\u002Fpi agent等在构建上下文中一般选择的架构组织方式是：静态提示词+ 动态提示词，其中静态提示词指的一般是不会改变的提示词，如系统提示词、工具介绍等，而动态提示词 指的是经常发生改变内容，比如用户内容输入等，在上文组织过程中以pi agent为例介绍其组织过程，在第一次启动之后其context为： AgentContext ├── systemPrompt │ ├── Pi Base System Prompt │ ├── Tool 使用说明 │ ├── Guidelines │ ├── APPEND_SYSTEM.md │ ├── AGENTS.md \u002F CLAUDE.md │ ├── Available Skills Index │ └── Current Working Directory ├── messages │ └── [] └── tools ├── read schema ├── bash schema ├── edit schema ├── write schema └── extension tool schemas... 这里 messages 还是空的，因为用户还没有真正开始对话；但 System Prompt 和可用 Tool 已经准备完成。Pi 会在启动阶段读取 AGENTS.md、CLAUDE.md 等项目规则，同时扫描当前可用的 Skills（Skill 并不会在启动时把完整内容全部塞进 Context 一般只会保存 description、name、path）。不断对话过程中 用户输入问题->调用工具 此过程会将工具结果 补充到对话结尾 上下文压缩 因为模型上下文是有限的因此不对对话过程中就需要去对内容进行压缩保证后续对话进行，对于普通对话压缩可能就是对上下文进行简短即可，但是对于Agent而言上下文不是一篇单纯的长文本，而是一个持续变化的运行状态。压缩策略也比较多一般而言压缩需要同时考虑：速度、效率（压缩后内容尽可能少的占用token），从两个角度出发了解上下文压缩策略： 常用Agent架构中使用的压缩策略 工业 Agent 很少使用 LLMLingua 式 Token 分类器直接压缩整个对话。更常见的是“确定性选择与清理 + 专用 LLM 生成任务交接摘要 + 原始尾部 + 外部可恢复状态”。 1、Pi Agent 上下文压缩策略 Pi 的自动触发条件是：\\(\\text{ContextTokens}> \\text{ContextWindow}-\\text{ReserveTokens}\\) 其中 reservetokens 表示给下一次模型输出和工具执行留空间，除此之外在压缩过程中假如对话窗口为 SystemPrompt+Context_i 其中 Context_i可能就是表示一轮对话结果（User+Assistance+toolCall+toolResult 其中 toolCall 表示调用工具名称、 toolResult 表示对应的工具返回的结果）在Pi的第一轮压缩过程中它会先从最新消息往前扫描，尽量找到一段近期上下文（比如检索到 i=2 那么就会将前两轮对话历史结果进行压缩）在压缩过程中通过提示词引导进行“结构化压缩”比如说： ## Goal 当前任务最终目标 ## Constraints & Preferences 用户约束、技术限制、不允许执行的操作 ## Progress ### Done 已经完成的工作 ### In Progress 当前正在做什么 ### Blocked 被什么问题阻塞 ## Key Decisions 关键决策，以及做出决策的原因 ## Next Steps 后续动作 ## Critical Context 关键报错、实体、路径、函数名、API和数据结构 ## Read Files 已经读取的文件 ## Modified Files 已经修改的文件 压缩后不是将内容进行删除只是以后不再发送给 LLM。官方文档明确描述为：追加 CompactionEntry，然后下一轮根据 firstKeptEntryId 重建 Context，所以下一轮对话内容为：SystemPrompt+CompactionSummary+Context_j。在后续n轮压缩过程中 会直接把 上一轮的压缩内容和最近需要压缩的内容一起进行压缩。 从上面过程可以发现Pi里面压缩比较简单粗暴并没有去区分tool result直接通过一个prompt进行全部压缩。 2、Open Code 上下文压缩策略 OpenCode 比 Pi 更复杂一点，因为它实际上有两个完全不同的 Context Reduction 层：Tool Result Pruning 和 Conversation Compaction。第一层对工具调用结果进行压缩（也容易理解在coding任务中一个 grep的工具调用，返回的结果可能就有上千行内容这些内容不是都有用的，只需要对他们进行标记后续去掉就行）在对话中一轮工具调用可能是 Assistance+ toolCall+ toolResult+ Assistance OpenCode 会把旧 Tool Result 标记为 compacted，其中它主要压掉的是 Tool Result 的 output，而不是直接把整个 Tool Call + Assistant 消息链都删掉。 换言之在进行对话过程中 toolResult 是有生命周期的，这一层没有去调用llm处理，在代码里面会对旧 completed tool parts 上标记 compacted，而不是调用 LLM 改写这些结果。 Assistant: 我先搜索 refresh_token。 ToolCall: grep -R \"refresh_token\" src\u002F ToolResult: src\u002Fauth\u002Ftoken.py:... src\u002Fauth\u002Fservice.py:... src\u002Fapi\u002Flogin.py:... ...... 几千行内容 Assistant: 主要逻辑位于 src\u002Fauth\u002Ftoken.py，接下来读取该文件。 ----- 进行 tool result pruning ----- Assistant: 我先搜索 refresh_token。 ToolCall: grep -R \"refresh_token\" src\u002F ToolResult: [旧 output 已从 Active Context 中移除] Assistant: 最终定位到 src\u002Fauth\u002Ftoken.py OpenCode 并不知道某条 Tool Result 在语义上“已经没用了”。它采用的是一种更工程化的启发式规则：近期工具输出优先保护，较老、已完成、非保护类型的工具输出，在累计超过一定 Token 预算以后直接从 Active Context 中驱逐。 第二层对内容进行压缩这个过程和上面的Pi的处理类似通过提示词进行结构化压缩，不过对话过程中进行压缩之后为了保证agent loop不被打断，会将对话重新拼接到压缩后内容后面（Summary + RecentContext） 3、其他闭源压缩策略 Manus 强调将网页、文件、中间结果和长 Tool Output 写入文件系统，只在活动 Context 中保留路径、URL、对象 ID 和简要结论。Todo \u002F Plan 会不断重写到最近上下文，形成 Goal Recitation[2]。Langchain DeepAgents会先把大型 Tool Result 写入文件，并在 Context 中留下文件指针和预览；必要时再对旧历史生成 Summary，同时保留完整 Transcript 作为 Canonical Record[3]。 学术领域中常用的压缩策略 个人认为工程化实践上可以重点关注两点策略：1、离散文本与token级压缩 以及 2、面向Agent运行轨迹压缩。 1、离散文本与token级压缩 推荐直接使用: https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FLLMLingua 这一类方法最终仍然输出可读文本，对于原始输入文本 \\(X=[x_1,x_2,\\ldots,x_n]\\) 通过压缩器为每个 Token 或文本片段决定 \\(z_i\\in\\{0,1\\}\\) 最终保留：\\(X'=\\{x_i\\mid z_i=1\\}\\)（一般希望\\(\\max_{X'}\\operatorname{Utility}(X',Q) \\quad \\text{s.t.} \\quad |X'|\\le B\\) 其中 \\(B\\) 为压缩后的token budget）。 在论文 Selective Context[4]和LLMLingua-2[5]处理思路类似都是 对不重要token进行过滤只将重要token进入模型推理 ，以selective context为例其处理思路很简单对于较长的prompt直接计算 \\(I(x)=-\\log P(x)\\) 其中 \\(x\\) 表示较长的prompt而 \\(P\\) 对应一个较小的模型而后对计算结果计算阈值过滤即可达到压缩目的（实际过程llm类似prefill处理prompt这样就可以得到每一个token的logits然后阈值过滤即可）下图红色表示保留文本 这一类方法最大的优点是兼容闭源模型；最大的局限是：Token 级“相关性”不等于 Agent 状态级“未来效用”。 2、latent压缩 将长 Context 编码 \\(X\\in\\mathbb{R}^{n\\times d}\\) 压缩为：\\(Z=C_{\\phi}(X)\\in\\mathbb{R}^{m\\times d},\\quad m\\ll n\\) 其目标不是生成可读摘要，而是让下游模型能够从少量隐状态中恢复任务所需信息，简而言之将中间状态结果进行压缩处理，不过对于这种策略需要考虑一点就是LLM都是自回归的，就需要考虑如何将内容进行拼接输入。比如在论文ICAE[6]直接将原本的大模型推理过程Context+Prompt+Deocer 替换为 Context+Summary在经过一次编码后在将 Summary+Prompt 就行decoder处理。训练分为两部分预训练和微调，预训练阶段文本复写任务通过MemoryTokens去复写后面内容（相当于截断文本而后decoder通过MemoryTokens去复写出来）以及 文本续写任务（或者说“问题回答”）。在后续论文500xCompressor[7]中处理思路类似不过将 embeding 替换为 KV-value去实现压缩。 3、面向Agent运行轨迹压缩 主要是将 \\(t\\) 轮中对话结果进行压缩比如说 \\(S_t=\\{G,C,P,D,E,F,A_t,O_t\\}\\) 其中内部就是Agent不同运行轨迹状态因此轨迹压缩的目标是构造 \\(\\hat{S}_t=C(S_{1:t})\\) 。MEM1[8]在处理React每一步推理过程中进行“微压缩”然后进入下一轮的推理在react中每一轮推理都会直接将上一轮内容叠加到状态里面进行推理。 比如说上图中左下方每一次act推理过程中都会将工具结果等都记录到 IS中，再训练过程中因为每轮都有一个压缩处理因此在计算Attention过程中下一轮的 \u003CIS> 状态“看不到”前面状态结果（2D Attention Mask）。在Context-folding论文[9]和论文 ACM[10]中不是讲状态进行总结而是将状态进行“折叠”，比如在Context-folding中： 在上述过程中，工具调用产生的中间结果会被统一“折叠”，仅将 Sub-agent 最终返回的结果保留在主上下文中。该方法采用 Main Agent 与 Sub-agent 协同的架构：前者负责在 Planning State 中进行任务规划与子任务拆解，后者根据规划执行 ReAct 式推理及工具调用。与其他上下文压缩方法的主要区别在于，Sub-agent 的完整执行轨迹不会写入主上下文，只有其最终返回的结果会被保留。而ACM更加简单直接通过两个上下文管理工具，使代理能够模仿人类的记忆机制：manage_context，它将之前的转换压缩成简洁的摘要，并将原始消息卸载到磁盘上的外部文件中；以及 query_memory，它允许代理查询存储的原始消息以精确地检索信息。 4、KV cache压缩 KV Cache Compression 处理的是 Transformer 每层的 Key 和 Value：\\(K_l,V_l\\)，目标是在生成过程中只保留一部分历史 KV：\\((K'_l,V'_l)=\\operatorname{Select}(K_l,V_l,B_l)\\) 其中 \\(B_l\\) 是第 \\(l\\) 层的缓存预算，所以说严格意义上不太算是上下文压缩策略，在论文 StreamingLLM [11]中发现使用 windows attention并不能扩展长度（主要测试的是Llama-2模型，发现模型不能很好外推到训练长度之外），但是通过一种现象 attention sink（保留 起始token 的 KV ）能够恢复 windows attention 的效果。之所以出现这一现象是因为起始 token 有着更高的注意力分数，即便是当它在语义上已经不重要了（实验直接将其换成 \\n 对于表现影响很大）也依然如此。 操作方式也很简单在计算 windows attention 时候将开始的 \\(n\\) 个token保留即可（测试llama-2中 \\(n=4\\) ） 总结 对于 Agent 运行上下文，主要分为两大部分：1、上下文组织，可分为两个阶段：启动时，拼接系统提示词、Skills、工具 Description、必备文件（如 CLAUDE.md）等静态内容；运行时，持续拼接用户消息、Agent 回复、工具调用及工具结果。参考 Pi Agent 的组织方式，可以概括为：静态内容 + 用户消息 + Agent 交互轨迹 + 工具结果。2、上下文压缩，考虑到每个 LLM 的上下文窗口都存在上限，因此需要对内容进行压缩。综合工业实践和学术研究，较为稳妥的策略包括：1、选择性保留工具结果，例如 OpenCode 的 Tool Result Pruning 和 Context Folding。Agent 运行过程中，工具结果可能占用大量上下文，并且部分结果会过期、重复或可以重新获取，因此没有必要始终保留在主上下文中；2、基于提示词进行摘要，通过提示词将历史内容压缩为结构化摘要，同时保留任务目标、运行状态、执行进度、关键结论、环境变化、失败尝试和待办事项，具体可以参考 OpenCode、Pi Agent 和 Claude Code 的提示词设计；3、选择性丢弃或 Token 级压缩（谨慎使用），直接丢弃低价值、重复或可恢复的内容，或者通过离散 Token 压缩等算法缩短文本。此类方法只能尽量保持原始语义，无法保证关键信息完全不丢失；4、运行状态压缩（不建议作为应用层首选方案），直接对 KV-cache 等模型运行状态进行压缩或量化。这类方法主要用于降低显存占用和提高推理效率，并不等同于语义层面的上下文压缩。 参考 https:\u002F\u002Farxiv.org\u002Fpdf\u002F2307.03172 ↩︎ https:\u002F\u002Fmanus.im\u002Fblog\u002FContext-Engineering-for-AI-Agents-Lessons-from-Building-Manus ↩︎ https:\u002F\u002Fdocs.langchain.com\u002Foss\u002Fpython\u002Fdeepagents\u002Fcontext-engineering ↩︎ https:\u002F\u002Farxiv.org\u002Fpdf\u002F2310.06201 ↩︎ https:\u002F\u002Farxiv.org\u002Fpdf\u002F2403.12968 ↩︎ https:\u002F\u002Farxiv.org\u002Fpdf\u002F2307.06945 ↩︎ https:\u002F\u002Faclanthology.org\u002F2025.acl-long.1219.pdf ↩︎ https:\u002F\u002Farxiv.org\u002Fpdf\u002F2506.15841 ↩︎ https:\u002F\u002Farxiv.org\u002Fpdf\u002F2510.11967 ↩︎ https:\u002F\u002Farxiv.org\u002Fpdf\u002F2607.23809 ↩︎ http:\u002F\u002Farxiv.org\u002Fabs\u002F2309.17453 ↩︎",6627,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":16,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":38},"#2563eb","16 \u002F 10",[7,8],{"targetType":8,"targetId":9,"likedByMe":40,"likeCount":41,"commentCount":41,"contentLikeCount":41,"contentCommentCount":41,"sourceLikeCount":41,"sourceCommentCount":41},false,0,[43,52,58,65,73,80,86,93],{"id":44,"kind":7,"title":45,"summary":46,"image":47,"href":48,"meta":49,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":50},"NEWS_ARTICLE:827","MHS 三部曲（下）：谁允许 AI 行动？——权力、合规与中国厂商的答卷","我们总在等待一个像 ChatGPT 那样的机器人时刻。但具身智能真正的拐点，也许先发生在更不起眼的地方：一台陌生设备，第一次能把自己的能力、状态和边界完整告诉 AI；一个 Agent，第一次能把试出来的经验固化成可验证、可复用的机器技能。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830153745229-1536981088.jpg","\u002Fnews\u002F827","2026 · 人工智能",[51],"人工智能",{"id":53,"kind":7,"title":54,"summary":55,"image":15,"href":56,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":57},"NEWS_ARTICLE:829","我不会美工，用 WorkBuddy 1 分钟做出 4 张海报","先说结果：下面这 4 张海报，从我发出指令到拿到图片，大约 1 分钟。 我不会美工，也没有打开 Photoshop。用的工具，是我之前用 WorkBuddy 做的一个海报生成器。这个生成器本身也没花几分钟，具体开发过程我在上一篇文章里写过。 这次我把海报生成器的网址、产品截图和要求一起发给 Work","\u002Fnews\u002F829",[7,8],{"id":59,"kind":7,"title":60,"summary":61,"image":62,"href":63,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":64},"NEWS_ARTICLE:828","一个人抵一个团队的时代，企业级 AI Agent 还需要做什么？","对于企业而言，真正需要的，不是一个“会聊天”的 Agent，而是一套能被多用户、多场景复用，且权限清晰、过程可审计、成本可控制的 Agent 能力体系。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2232255\u002F202609\u002F2232255-20260902173524728-659996478.png","\u002Fnews\u002F828",[7,8],{"id":66,"kind":7,"title":67,"summary":68,"image":15,"href":69,"meta":70,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":71},"NEWS_ARTICLE:832","用 runtime-async 写一个支持 async\u002Fawait 的轻量脚本引擎","起因：一个好奇 事情的开头很简单。 给 .NET 做过动态脚本的人大概都碰到过同一堵墙：表达式树也好、Reflection.Emit 也好，都很难支持 async\u002Fawait。原因不在语法，而在 await 的实现方式——C# 编译器要为每个 async 方法生成一个状态机结构体，把方法体切成若干片","\u002Fnews\u002F832","2026 · 软件开发",[72],"软件开发",{"id":74,"kind":7,"title":75,"summary":76,"image":77,"href":78,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":79},"NEWS_ARTICLE:831","Agent Sandbox 规模化：JuiceFS 探索与实践","过去一段时间，我们在和云厂商以及 Agent 团队推进 Sandbox 落地时，除了要解决数据如何进入 Sandbox，还需要考虑任务所需的数据和执行过程中产生的数据，如何跨任务、跨阶段持续使用。Sandbox 可以随任务快速创建和销毁，但数据往往需要继续保留、共享和流转。 当 Sandbox 并发","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2544292\u002F202609\u002F2544292-20260902171045357-1907499098.png","\u002Fnews\u002F831",[7,8],{"id":81,"kind":7,"title":82,"summary":83,"image":15,"href":84,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":85},"NEWS_ARTICLE:830","百智云长期记忆服务：长期记忆与上下文窗口的区别","很多人在接触 AI 长期记忆时，第一反应是：「这不就是把聊天记录存起来吗？」其实这是一个很常见的误解。今天我们把「长期记忆」和「上下文窗口」这两个概念彻底讲清楚。 一、什么是上下文窗口 上下文窗口（Context Window）是模型在单次推理时能「看到」的文本上限。它像一个临时的工作台：模型只能处","\u002Fnews\u002F830",[7,8],{"id":87,"kind":7,"title":88,"summary":89,"image":90,"href":91,"meta":49,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":92},"NEWS_ARTICLE:835","体验向量数据库 qdrant","作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！ cnblogs博客 zhihu Github 公众号:一本正经的瞎扯 背景 为了早点搞懂公司的百万行 C# 的祖传代码，我想在缺乏文档、缺乏帮手的情况下，先建立一个 企业知识库 来快速帮我理清头绪。 一开始，我是打算以 weav","https:\u002F\u002Fimg2022.cnblogs.com\u002Fblog\u002F1457949\u002F202202\u002F1457949-20220216153819145-1193738712.png","\u002Fnews\u002F835",[51],{"id":94,"kind":7,"title":95,"summary":96,"image":15,"href":97,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":98},"NEWS_ARTICLE:833","如何利用AI技术实现漫画翻译","漫画作为图文结合的特色文化载体，承载着各国潮流文化与人文故事，但跨语言的文字壁垒，长期制约着漫画的传播与交流。传统漫画翻译高度依赖人工操作，需要人工框选文字、擦除原图文字、翻译文案、排版适配画风，流程繁琐、耗时费力，且极易出现排版错乱、画风违和、语义偏差等问题。 随着深度学习、计算机视觉与大模型技术","\u002Fnews\u002F833",[7,8]]