context-mode 的分析与批评 by GPT5.5

repo

Context Mode 实现方式与生产化评估

摘要

Context Mode 的核心价值不是“把所有信息压缩成指针”，而是尽量避免大体量原始数据直接进入主 Agent 的上下文窗口。

它更适合解决这类问题：

原始数据很大，但真正需要交给主 Agent 的结论很小。

例如日志分析、测试失败、构建错误、网页快照、文档检索、API 响应检查等场景。它的典型路径是：先把大输出留在外部环境里，再通过代码执行、索引检索或摘要提取，只把小规模结果返回给模型。

但它并不是通用的上下文压缩方案。如果一个任务最终仍然需要主 Agent 读取完整材料，那么 Context Mode 只能延迟成本，不能真正消除成本。这个边界在生产环境里非常重要。

当前方案的基本思路

Context Mode 可以理解成一层运行在 Agent 和外部工具之间的“上下文保护层”。

它主要做三件事：

1. 拦截或提示那些容易产生大量输出的工具调用。
2. 把大输出保存在沙盒、文件或数据库里，而不是直接放进模型上下文。
3. 只把摘要、命中片段、统计结果或后续检索入口返回给主 Agent。

这种设计并不会要求用户修改项目里的所有 shell 脚本，也不会替换系统里的原生命令。它主要影响的是 Agent 使用工具的方式。

在支持 hooks 的平台上，它会通过工具调用前的钩子来引导 Agent：小输出和文件修改类命令可以继续走原生工具，而日志、测试、构建、网页抓取、长文档读取等容易爆上下文的操作，则会被引导到 Context Mode 提供的工具中执行。

降低上下文占用的几个机制

1. 让模型写代码分析，而不是直接阅读大输出

这是最有效的一类优化。

传统方式是：

执行命令
  -> 大量 stdout/stderr 进入上下文
  -> 模型阅读并分析

Context Mode 更推荐：

执行命令或读取数据
  -> 在沙盒里运行分析代码
  -> 只打印关键结论
  -> 主 Agent 只看到结论

例如，让脚本统计日志中最常见的错误、提取失败测试、解析 JSON 中异常字段、聚合访问日志状态码。这种情况下，原始数据不需要进入主 Agent 上下文，收益非常明显。

这类机制的本质是：

用程序计算替代模型阅读。

2. 文件内容在外部加载，只返回处理结果

对于日志、CSV、JSON、构建输出、浏览器快照等大文件，Context Mode 会让文件在外部环境中被读取和处理。模型不直接看到完整文件，只看到处理代码输出的摘要或结论。

这对“分析文件”很有用，但不适合“编辑文件”的场景。如果 Agent 要修改代码，它仍然需要读取相关代码内容，否则无法安全编辑。

3. 大输出转成可检索资料，而不是直接返回全文

当某次命令或工具调用产生很大的输出时，Context Mode 会把它保存并切分成多个片段，然后建立全文检索索引。

返回给主 Agent 的通常不是原始全文，而是类似这样的信息：

内容已索引，共包含若干片段。
如需细节，请使用指定查询继续检索。

如果调用时已经给出了明确意图，它也可能直接返回少量命中片段，例如和“TypeScript 错误”“失败测试”“HTTP 500”相关的部分。

这种方式能减少初始上下文占用，但它不是无成本的。如果 Agent 后续为了理解问题反复检索很多次，最终返回的片段总量仍然可能变大。

4. 批量执行和批量检索

Context Mode 也提供了批量执行能力：一次运行多条命令、统一保存输出、建立索引，并一次性用多个查询提取结果。

这可以减少多轮工具调用，避免 Agent 一次查一个问题、反复进出工具的低效模式。

不过，这仍然依赖 Agent 能提出相对合理的查询。如果 Agent 不知道该找什么，批量检索也可能漏掉真正重要的信息。

5. 会话恢复和历史信息检索

在长会话中，模型上下文可能被压缩或清理。Context Mode 会把一部分会话事件保存在外部，并在恢复时只注入必要提示。

详细历史不一次性塞回上下文，而是通过检索按需找回。

这对保持长任务连续性有帮助，但同样依赖检索质量和事件记录质量。

真实价值在哪里

Context Mode 最有效的场景是“大数据，小答案”。

例如：

• 从大量日志中找出错误类型和示例。
• 从测试输出中提取失败用例和关键栈。
• 从构建输出中找出真正导致失败的错误。
• 从大型 JSON 或 API 响应中提取异常记录。
• 从浏览器快照中提取表单、按钮、链接等结构化信息。
• 从文档中检索少量相关代码示例。

这些任务的共同点是：原始材料很大，但最终给主 Agent 的信息可以很小。

如果能够在外部用确定性程序完成统计、过滤和提取，Context Mode 的收益会非常明显。

主要问题和边界

1. 指针不等于压缩

把大输出变成索引入口或引用，并不天然减少总信息量。

如果主 Agent 最终还是需要读取完整内容，那么这些内容迟早还是要进入上下文。此时 Context Mode 只是把一次大读取变成多次小读取，甚至可能增加工具调用成本。

因此，它的收益取决于一个前提：

任务不需要主 Agent 阅读完整原文，只需要少量关键证据或结论。

2. 搜索不能替代理解

当前的检索更接近增强版全文搜索，而不是完整语义理解。

它擅长匹配明确的错误码、文件名、函数名、关键词、日志级别、命令输出中的固定格式。但当 Agent 不知道该搜什么，或者问题隐藏在跨段落、跨时间线、跨多个片段的模式里，纯搜索就可能失效。

例如：

• 关键问题不是某个错误词，而是一组事件的顺序。
• 真正原因出现在日志前面，报错出现在日志后面。
• 输出里没有明显关键词，但异常模式需要归纳。
• 搜索词选错，导致命中片段看起来相关但不是根因。

这就是生产环境里最需要警惕的地方。

3. 反复检索可能抵消收益

如果 Agent 反复进行多次搜索，每次返回若干片段，最终累计上下文和工具调用成本可能并不低。

这种情况下，使用一个便宜的长上下文模型或 Sub-agent 先做整体摘要，可能更快，也可能质量更好。

换句话说：

检索适合已知目标。
摘要适合未知目标。

4. 切块会损失全局结构

把 Markdown、日志或命令输出切成多个片段有利于检索，但也会带来上下文断裂。

一些问题需要跨片段理解：

• 错误栈和根因分布在不同位置。
• 测试失败摘要和详细断言不在同一块。
• 日志需要按时间线关联。
• 文档的解释需要多个章节连起来看。

因此，切块索引适合做证据定位，不应该被视为完整分析能力。

5. 系统复杂度较高

Context Mode 引入了额外组件：

• MCP 服务。
• hooks 规则。
• 沙盒执行。
• 外部存储。
• 全文索引。
• 缓存和失效判断。
• 会话恢复。
• 安全策略。

这些复杂度是否值得，取决于实际工作负载。如果团队主要处理大日志、大测试输出、大文档和长会话，它可能很有价值。如果任务大多是小规模代码编辑，它的收益会比较有限。

更适合生产环境的改进方向

1. 先过滤，再搜索

对日志、测试输出、构建输出、CI 输出来说，第一步不应该总是全文检索，而应该先做确定性过滤和解析。

更合理的流程是：

原始输出
  -> 识别输出类型
  -> 使用专门规则解析
  -> 提取结构化错误和告警
  -> 必要时再检索原文证据

例如，一个构建输出可以先被解析成：

{
  "summary": "构建失败：发现 3 个 TypeScript 错误和 1 个缺失模块错误。",
  "findings": [
    {
      "severity": "error",
      "kind": "typescript",
      "message": "Cannot find module '@/lib/db'",
      "location": "相关模块的导入位置",
      "evidence": "构建输出中的对应片段"
    }
  ],
  "stats": {
    "errors": 3,
    "warnings": 12
  }
}

这种结构化结果通常比搜索片段更适合 Agent 使用，因为 Agent 不需要猜关键词，也不需要先判断哪段日志值得看。

2. 建立专用解析器

日志和构建输出往往有稳定格式，适合用硬编码规则先抽取高价值信息。

优先级较高的解析对象包括：

• TypeScript 编译错误。
• ESLint 输出。
• Jest 或 Vitest 测试失败。
• Python traceback。
• Java stack trace。
• 通用异常栈。
• Docker 构建失败。
• Kubernetes Pod 状态和事件。
• HTTP access log。

每个解析器应尽量返回：

• 严重级别。
• 错误类别。
• 错误消息。
• 文件和行号。
• 去重后的错误分组。
• 原始证据位置。
• 置信度。

这样可以让主 Agent 优先看到最重要的信息，而不是从大量片段中自行判断。

3. 在检索层之上加入便宜模型或 Sub-agent

对于无法靠规则稳定解析的输出，可以让便宜的长上下文模型或 Sub-agent 做一层外部摘要。

推荐职责划分：

Context Mode：数据层
便宜模型或 Sub-agent：分析层
主 Agent：决策和执行层

数据层负责保存原文、建立索引、提供证据定位。

分析层负责阅读过滤后的材料或必要的原文窗口，判断哪些信息重要，归纳根因，输出结构化结论。

主 Agent 只消费最终摘要和关键证据，在需要确认时再回查原文。

这种方式比让主 Agent 多轮搜索更稳定，因为第一轮处理是“判断信息价值”，而不是“关键词召回”。

4. 让搜索退居为证据回查机制

在更成熟的架构里，搜索不应该承担全部分析责任。

更好的定位是：

先过滤。
再摘要。
最后按需回查证据。

也就是说：

1. 先用规则或程序找出明显问题。
2. 再用便宜模型或 Sub-agent 判断重要性和可能根因。
3. 最后用搜索按需拉取精确原文证据。

这样既保留了 Context Mode 防止上下文爆炸的优势，也减少了反复搜索带来的低效。

5. 调整评估指标

不能只看“返回给主 Agent 的字节数减少了多少”。生产环境更关心整体效果。

应该同时评估：

• 主 Agent 上下文是否减少。
• 总工具调用次数是否增加。
• 总耗时是否变长。
• 总 token 成本是否下降。
• 是否漏掉关键错误。
• 摘要是否忠实。
• 证据是否可追溯。
• 多轮检索是否变成瓶颈。
• 对真实修复任务是否有帮助。

只有这些指标一起改善，才能说明方案在生产环境中真正有效。

推荐的混合架构

更稳妥的生产架构可以是：

1. 捕获
   保存原始输出，避免直接进入主 Agent 上下文。

2. 分类
   判断输出属于日志、测试、构建、JSON、文档还是网页快照。

3. 过滤
   使用确定性规则提取错误、告警、失败项和证据位置。

4. 摘要
   可选地让便宜模型或 Sub-agent 做语义总结和根因归纳。

5. 返回
   主 Agent 获取结构化结论、关键证据和建议动作。

6. 回查
   只有在需要确认细节时，才检索或读取原文片段。

这个架构保留了 Context Mode 的核心优势：不让大输出污染主上下文。同时也补上了它当前最薄弱的部分：判断哪些内容真正重要。

结论

Context Mode 在生产环境中有价值，但它更像底层数据管道，而不是完整的智能分析方案。

它最适合负责：

• 隔离大输出。
• 保存原始证据。
• 提供按需检索。
• 支持会话连续性。
• 防止主 Agent 上下文被 stdout、stderr、日志和网页快照淹没。

它不擅长单独解决：

• 判断哪些日志最重要。
• 在未知目标下发现根因。
• 跨大量片段做全局语义归纳。
• 替代便宜模型或 Sub-agent 的摘要能力。

因此，更合理的方向不是让主 Agent 反复搜索所有索引内容，而是把 Context Mode 作为数据层，在它之上叠加过滤器、专用解析器、便宜模型摘要或 Sub-agent 分析。

最终目标应该是：

大数据留在外部。
确定性规则先过滤。
便宜模型负责摘要。
主 Agent 只处理决策和修复。
需要证据时再回查原文。