# 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 拆分来物理隔离上下文，是解决“迷失在中间”问题的最彻底方法。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET 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?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.