> 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-san-bu-fen-jin-jie-ji-shu-yu-jia-gou/09_agents/9.1_agent_architecture.md).

# 9.1 智能体架构与上下文

> 💡 关于智能体的完整介绍，请参阅《智能体 AI 权威指南》。

## 9.1.1 智能体的核心特征

**AI 智能体** 是一个能够感知环境、做出决策并采取行动以实现特定目标的自主系统。与单次对话的 LLM 应用相比，智能体的关键差异在于：

* **自主规划**：不是被动响应，而是独立拆解任务并制定执行策略
* **工具协作**：通过 API、文件系统、代码执行等工具扩展能力，与现实世界交互
* **循环执行**：遵循“思考-行动-观察-反思”的循环，而不是单轮交互
* **上下文依赖**：每一步的决策都依赖于之前的执行历史和当前的环境状态

## 9.1.2 为什么上下文是智能体的核心

不同于一次性的聊天应用，智能体需要在 **多步执行** 中维持一致的上下文：

* 早期步骤的决策可能影响后期的规划
* 环境观察需要被记录和回顾
* 执行历史需要被压缩或组织，否则会快速耗尽 token 预算
* 不同的任务阶段需要不同的上下文关注点

一个 agent 失败往往不是因为推理能力不足，而是因为：

1. 关键信息在执行过程中被遗忘（上下文管理不当）
2. 环境状态变化，但智能体仍基于过时信息决策（上下文不同步）
3. 历史积累过长，导致 token 溢出（上下文压缩不当）

这正是本章的关注点。

## 9.1.3 智能体上下文的特殊挑战

相较于普通对话，智能体面临更复杂的上下文管理问题：

| 挑战         | 表现                       | 影响                   |
| ---------- | ------------------------ | -------------------- |
| **长程依赖**   | 任务跨越数十甚至数百轮交互            | 早期信息容易被遗忘或稀释         |
| **状态爆炸**   | 需要同时追踪任务进度、环境变化、中间结果     | 上下文快速膨胀，token 成本急剧上升 |
| **信息来源多元** | 用户输入、工具返回、环境观察、历史回顾      | 难以区分哪些信息是关键、哪些是噪声    |
| **动态重规划**  | 计划可能需要实时调整               | 需要频繁修改上下文，但频繁修改易引入错误 |
| **可观性不足**  | Agent 的思考过程被隐藏在 token 流中 | 难以调试失败原因，难以审计决策过程    |

这些挑战无法通过简单的“塞更多信息进去”来解决。需要 **结构化的上下文工程策略**。

## 9.1.4 智能体上下文的典型层级

为了应对上述挑战，上下文应该按以下原则分层：

```
┌─────────────────────────────────────────────┐
│  系统层：Agent 定义、角色、约束             │  稳定，不变
├─────────────────────────────────────────────┤
│  任务层：当前目标、成功标准、约束           │  任务级，变化频率低
├─────────────────────────────────────────────┤
│  状态层：进度、环境观察、动态计划           │  需要频繁更新
├─────────────────────────────────────────────┤
│  历史层：执行轨迹、观察、决策（可压缩）    │  可能很长，需要管理
├─────────────────────────────────────────────┤
│  交互层：当前步骤、即时输入、观察           │  最新、最关键
└─────────────────────────────────────────────┘
```

**分层的好处**：

* 不同层级有不同的更新频率，避免无谓的重复
* 支持选择性压缩：可以摘要历史层，但保留状态层的完整性
* 清晰的结构让模型快速定位需要的信息

## 9.1.5 ReAct 与 Reflexion 的上下文含义

智能体运行模式决定了上下文的结构和更新策略。两种常见模式各有对上下文的不同需求：

**ReAct 循环**（思考 → 行动 → 观察）：

* 上下文需要记录每一步的 Thought、Action、Observation
* 频繁更新，但每个循环的上下文是相对独立的
* 适合需要即时反馈调整的任务

**Reflexion 模式**（执行 → 整体反思 → 调整策略）：

* 上下文需要累积所有执行轨迹，然后进行整体评估
* 更新频率低，但单次更新涉及更多信息
* 适合需要从失败中学习的复杂任务

**上下文工程的启示**：选择错误的运行模式，会导致上下文管理困难。例如，如果用 Reflexion 模式处理频繁交互的任务，历史会快速膨胀而无法得到及时压缩。

## 9.1.6 上下文管理的核心原则

**1. 信息分层**

按重要性和时效性分层管理。智能体的上下文应该有清晰的层级结构：系统级定义最稳定、任务级目标相对固定、状态信息需要持续更新、历史记录可以压缩或淘汰。不同层级采用不同的保留策略和更新频率。

**2. 动态更新**

随任务进展更新状态信息。智能体执行过程中，环境在变化、进度在推进、计划可能调整。上下文必须反映这些变化，否则智能体将基于过时信息做出错误决策。建立清晰的状态更新机制，确保关键信息及时同步。

**3. 选择性保留**

保留关键信息，压缩或丢弃冗余。长程任务会产生大量历史信息，不可能全部保留。需要智能地选择：哪些是关键结论必须保留？哪些是过程细节可以压缩？哪些是临时信息可以丢弃？这需要根据任务类型设计合理的淘汰策略。

**4. 结构化组织**

清晰的结构便于规划和推理。杂乱的上下文会让模型迷失方向。使用明确的标签和分区组织不同类型的信息，让模型能快速定位需要的内容。良好的结构不仅提高效率，也减少模型的理解错误。

## 9.1.7 上下文工程的四大模式

上下文工程（Context Engineering）不仅仅是编写提示词，而是对智能体“操作系统”的 RAM（上下文窗口）进行系统化管理。我们可以将上下文管理策略归纳为四大模式，分别对应本书的第二部分核心章节：

1. **Write Context（写入/卸载）**：对应 [第四章 写入策略](/context_engineering_guide/di-er-bu-fen-he-xin-ji-shu-yu-ce-le/04_write.md)。
2. **Select Context（选择/加载）**：对应 [第五章 选择策略](/context_engineering_guide/di-er-bu-fen-he-xin-ji-shu-yu-ce-le/05_select.md)。
3. **Compress Context（压缩/提炼）**：对应 [第六章 压缩策略](/context_engineering_guide/di-er-bu-fen-he-xin-ji-shu-yu-ce-le/06_compress.md)。
4. **Isolate Context（隔离/分治）**：对应 [第七章 隔离策略](/context_engineering_guide/di-er-bu-fen-he-xin-ji-shu-yu-ce-le/07_isolate.md)。

在智能体架构中，这四大模式协同工作以解决不同的挑战：

| 模式           | 解决的核心问题    | 典型技术                 |
| ------------ | ---------- | -------------------- |
| **Write**    | 窗口容量限制     | Scratchpad，外部笔记，长期记忆 |
| **Select**   | 注意力分散 / 成本 | Just-in-time 检索，RAG  |
| **Compress** | 历史累积过长     | Compaction，摘要，轨迹剪枝   |
| **Isolate**  | 任务复杂度过高    | 多智能体协作，VM 环境卸载       |

## 9.1.8 生产级智能体的上下文架构（案例思路）

在一些生产级 Agent 的实现中，上述上下文模式会被系统性地组合使用，以构建更健壮的“环境上下文”架构。

（关于相关案例思路的进一步讨论，请参见 [13.5 案例分析：全自主智能体架构（示意）](/context_engineering_guide/di-si-bu-fen-gong-cheng-shi-zhan-yu-wei-lai-yan-jin/13_cases/13.5_generalist_agent.md)）

## 9.1.9 Agent Harness 的上下文平面（Context-Plane）

**背景与动机**

在大规模生产环境中，智能体系统需要在多个不同的“平面”上进行协调工作。Agent Harness 框架将这些关注点分解为五个正交的平面，其中 **上下文平面（Context-Plane）** 是最核心的一个。

**上下文平面的四个维度**

上下文平面负责管理智能体执行过程中的以下四个关键维度：

1. **会话状态（Session State）**
   * 追踪智能体执行到哪一步
   * 记录每一步的中间结果和输出
   * 在中断后支持从检查点恢复
   * 例如：OpenAI Responses 的 Step 管理，Azure Durable Functions 的 Orchestration State
2. **记忆管理（Memory）**
   * 短期工作记忆：当前对话和任务的即时信息
   * 长期持久记忆：跨会话的用户偏好、领域知识、解决方案模板
   * 记忆的检索、更新和遗忘机制
   * 例如：Google Agent Runtime（原 Vertex Agent Engine）的 Agent Platform Sessions（会话内存）vs Memory Bank（跨会话记忆）
3. **上下文压缩与整理（Compaction/Summarization）**
   * 历史信息的摘要与精简
   * 对话历史的管理和截断
   * 多轮交互中的冗余消除
   * 支持 Token 成本优化和性能提升
4. **工件日志（Artifact Logs）**
   * 每一步的执行结果都被记录为有类型的工件
   * 支持完整的追踪（Tracing）和重放（Replay）
   * 便于调试、审计和合规验证
   * 与可观测性系统（如 OpenTelemetry）集成

**上下文平面的核心原则**

```
推理过程 → 有类型的行动 → 可重放的工件 → 可观测的追踪
```

上下文平面的本质是将智能体的“思维过程”转化为“可审计、可验证、可恢复”的执行流。每一个推理步骤都对应一个明确的行动（Action），该行动产生的结果都被记录为结构化的工件，这些工件通过追踪系统被串联起来，形成完整的执行链路。

**设计示例**

```
┌─ 智能体执行 ──────────────────────────────────────┐
│                                                      │
│  [思考] → [决策工具] → [执行工具] → [观察结果]     │
│    ↓         ↓           ↓          ↓               │
│  会话状态   行动日志    结果工件    状态更新       │
│                                                      │
└──────────────────────────────────────────────────────┘
           ↓
    [上下文平面]
    ├─ Session State: 步骤3/10, 等待工具返回
    ├─ Memory: 提取相关历史经验
    ├─ Compaction: 压缩早期步骤历史
    └─ Artifacts: 记录所有工具调用和结果
           ↓
    [可观测性系统]
    ├─ Traces: 完整的执行链
    ├─ Metrics: 延迟、成本、成功率
    └─ Logs: 结构化的事件日志
```

**与其他平面的关系**

Agent Harness 框架的五个平面协同工作：

| 平面        | 职责             | 与上下文平面的关系     |
| --------- | -------------- | ------------- |
| **工具平面**  | 外部工具和 API 的集成  | 工具执行的输出被记录为工件 |
| **上下文平面** | 状态、记忆、压缩、工件    | 核心，管理所有中间信息   |
| **推理平面**  | LLM 的推理策略和提示优化 | 消费上下文平面的记忆和状态 |
| **协调平面**  | 多智能体间的通信和同步    | 通过工件交换信息，状态同步 |
| **可观测平面** | 追踪、监控、告警       | 消费上下文平面的工件和日志 |

这种分离使得各平面可以独立演进，同时保持良好的接口契约。