> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/context_engineering_guide/di-si-bu-fen-gong-cheng-shi-zhan-yu-wei-lai-yan-jin/13_cases/13.5_generalist_agent.md).

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

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

## 13.5.1 核心挑战

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

1. **上下文爆炸 (Context Explosion)**：长时间任务会产生海量的工具调用日志、网页内容和代码文件，迅速耗尽上下文窗口（即使上下文很长，塞满后的推理成本也可能无法接受）。
2. **注意力稀释 (Attention Dilution)**：随着上下文长度增加，噪声、冲突证据和位置偏置的暴露面扩大，模型对关键指令和证据的利用可能变得不稳定。
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 架构图示

```mermaid
graph TB
    User[用户请求] --> Planner[Planner Agent]

    subgraph "Context Management System"
        planner_mem["Planner Context<br/>(Macro Plan, Progress)"]
        executor_mem["Executor Context<br/>(Specific Task, Tool Output)"]

        fs["Filesystem<br/>Long-term Memory"]
    end

    Planner --拥有--> planner_mem
    Planner --分派任务--> Executor[Executor Agent]
    Executor --拥有--> executor_mem

    executor_mem -.引用.-> fs
    executor_mem --写入--> fs

    Planner --读取摘要--> fs
    Executor --工具调用--> VM[Virtual Machine]
    VM --结果--> fs
    VM --紧凑摘要--> executor_mem
```

图 13-1：全自主智能体内存架构示意图

## 13.5.4 给开发者的启示

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

1. **不要把 Context Window 当作数据库**：它是 CPU 的 L1/L2 缓存，昂贵且易失。真正的数据库应该是文件系统或向量库。
2. **拥抱环境**：给 Agent 一个可以交互、持久化的 OS 环境，比单纯增加 Context 长度更有效。
3. **分而治之**：通过 Agent 拆分来物理隔离上下文，是解决“迷失在中间”问题的最彻底方法。