# 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）** * 短期工作记忆：当前对话和任务的即时信息 * 长期持久记忆：跨会话的用户偏好、领域知识、解决方案模板 * 记忆的检索、更新和遗忘机制 * 例如：Vertex Agent Engine 的 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 的推理策略和提示优化 | 消费上下文平面的记忆和状态 | | **协调平面** | 多智能体间的通信和同步 | 通过工件交换信息，状态同步 | | **可观测平面** | 追踪、监控、告警 | 消费上下文平面的工件和日志 | 这种分离使得各平面可以独立演进，同时保持良好的接口契约。 --- # 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-san-bu-fen-jin-jie-ji-shu-yu-jia-gou/09_agents/9.1_agent_architecture.md?ask= ``` 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.