13.5 案例分析：全自主智能体架构（示意）

本节以“通用全自主智能体”的架构思路为例，说明在长程任务中如何通过上下文工程策略应对上下文窗口有限、Token 成本与记忆连续性等挑战。

13.5.1 核心挑战

在构建全自主智能体时，团队通常会面临三个主要挑战：

1. 上下文爆炸 (Context Explosion)：长时间任务会产生海量的工具调用日志、网页内容和代码文件，迅速耗尽上下文窗口（即使上下文很长，塞满后的推理成本也可能无法接受）。

2. 注意力稀释 (Attention Dilution)：随着上下文长度增加，模型对关键指令的注意力会下降，导致“迷失在中间” (Lost in the Middle) 现象，执行准确率大幅下降。

3. 成本与延迟 (Cost & Latency)：每次全量输入历史记录进行推理，不仅昂贵，而且首字延迟 (TTFT) 极高，严重影响用户体验。

13.5.2 解决方案：三位一体的上下文策略

一种常见的组合拳策略可以总结为 ROI 模型：Reduction（缩减）、Offloading（卸载）和 Isolation（隔离）。

1. 上下文缩减

系统需要克制地使用 Context Window，将 Token 视为昂贵的稀缺资源。

• 双重工具结果 (Dual-form Tool Results)：

  • 对于 browse 或 read_file 等产生大量数据的工具，系统将完整内容存储在沙箱文件系统中，只向 Context Window 返回一个紧凑的摘要对象（包含 URL、标题、摘要和文件路径引用）。

  • 只有当 Agent 明确表示需要查看某段具体细节时，才会通过 read_file_chunk 等工具按需加载。

• 轨迹压缩 (Trajectory Compaction)：

  • 不仅是对结果压缩，对交互历史也进行压缩。当一轮对话结束或任务告一段落，系统会自动将之前的 Thought-Action-Observation 链条压缩为结构化的 StepSummary。

  • 例如，将多轮的“尝试调试-失败-再尝试-成功”过程，压缩为一条结构化记录，保留关键结论与后续行动建议。

2. 上下文卸载

系统将“记忆”的职责从 LLM 的 Context 转移到外部环境（Environment）。

• 文件系统即记忆 (Filesystem as Memory)：

  • 智能体运行在一个可持久化的执行环境中。它生成的代码、下载的资料、整理的笔记，都直接保存在文件系统中。

  • Context Window 中只需要保留“索引”（即文件路径）。只要文件在磁盘上，Agent 就认为自己“记得”这件事，需要时用工具去查。这模仿了人类的工作方式——我们不需要背诵整本书，只需要知道书架在哪。

• 状态持久化：

  • Agent 的状态不仅存在于对话历史中，更存在于它改变的环境中（安装的包、修改的配置、创建的文件夹）。这种环境副作用（Side Effects）构成了隐式的、无限的上下文。

3. 上下文隔离

为了防止不同子任务之间的干扰，系统会采用严格的隔离机制。

• Planner-Executor 架构：

  • Planner 负责高层规划，它的上下文包含用户意图和宏观进度，但不包含具体的代码实现细节或网页爬取日志。

  • Executor 负责具体执行，它被唤起时是一个全新的、干净的上下文环境，只接收 Planner 传来的明确指令和必要的背景资料。这一方面节省了 Token，另一方面避免了 Executor 被之前的无关历史干扰。

• 子智能体沙箱：

  • 不同的子任务（如“撰写文档”和“编写代码”）可以由不同的子智能体并行执行，互不干扰。它们通过共享的文件系统交换成果，而不是通过共享巨大的 Context Window。

13.5.3 架构图示

13.5.4 给开发者的启示

这类案例说明，优秀的上下文工程不仅仅是写好 Prompt，更重要的是设计好系统架构。

1. 不要把 Context Window 当作数据库：它是 CPU 的 L1/L2 缓存，昂贵且易失。真正的数据库应该是文件系统或向量库。

2. 拥抱环境：给 Agent 一个可以交互、持久化的 OS 环境，比单纯增加 Context 长度更有效。

3. 分而治之：通过 Agent 拆分来物理隔离上下文，是解决“迷失在中间”问题的最彻底方法。