第二章：Agent 的现代系统架构

2.1 从“四组件模型”到生产级架构

入门资料通常将 Agent 概括为四个组件：

模型 + 工具 + 记忆 + 规划

这个模型便于理解，但还不足以描述一个可运行、可控制、可观测的生产级 Agent。更完整的现代架构是：

Model + Tools + State/Memory + Planning/Control + Runtime/Guardrails

各部分的职责如下：

需要特别注意：LLM 并不会亲自访问数据库或执行代码。它只能提出一个工具调用请求，真正的执行由 Agent Runtime 完成。

2.2 组件如何协同工作

flowchart TB
    U[用户目标] --> RT[Agent Runtime / Orchestrator]

    subgraph Context[上下文与状态层]
        ST[任务状态]
        WM[工作记忆]
        LM[长期记忆]
        CB[Context Builder]
        ST --> CB
        WM --> CB
        LM --> CB
    end

    RT --> CB
    CB --> MP[Model + Planner]
    MP --> DEC{下一步决策}

    DEC -->|回答| OUT[最终结果]
    DEC -->|调用工具| PG[Policy / Permission Gate]
    DEC -->|委派任务| A2A[其他 Agent]

    PG --> TR[Tool Registry / MCP Client]
    TR --> TS[Tool / MCP Server]
    TS --> ENV[搜索、文件、数据库、代码、API]
    ENV --> OBS[Observation]

    A2A --> OBS
    OBS --> RT
    RT --> ST
    RT --> WM
    RT --> LM

    RT -.运行轨迹.-> OT[Tracing / Evaluation / Audit]
    OUT -.结果评估.-> OT

一次典型执行包含以下步骤：

1. Runtime 接收用户目标并初始化任务状态。
2. Context Builder 从当前状态、工作记忆和长期记忆中组装上下文。
3. 模型判断应该回答、调用工具、委派任务，还是重新规划。
4. 工具调用先经过参数校验、权限检查和风险控制。
5. Runtime 执行工具，并把结果作为 Observation 返回模型。
6. 系统更新状态和记忆，进入下一轮决策。
7. 满足完成条件、预算限制或人工审批条件后终止。

2.3 Model：推理与策略生成器

将 LLM 称为 Agent 的“大脑”是一种直观类比，但并不完全准确。现代模型可能同时处理文本、图像、音频等多种输入，因此它不只是“语言处理器”。

在 Agent 中，模型主要负责：

• 理解用户意图和约束；
• 分析当前任务状态；
• 生成或调整计划；
• 选择工具并生成参数；
• 根据工具反馈决定下一步；
• 判断是否可以生成最终结果。

模型能够生成工具调用请求，但默认不具备直接产生外部副作用的能力。它不能仅凭生成一段 JSON 就真的完成转账、发邮件或删除文件。

模型负责提出动作，Runtime 负责验证和执行动作。

这种分工使系统能够在执行前加入权限检查、参数校验、人工确认和审计记录。

2.4 Tools：连接模型与外部世界

工具可以封装搜索、数据库查询、代码执行、文件操作和业务 API。原则上，能够通过稳定接口表达的外部能力都可以封装为工具。

但生产级工具不仅是一个函数，还应包含：

• 唯一且清晰的名称；
• 明确的功能描述；
• 结构化输入输出 Schema；
• 身份认证与权限范围；
• 参数校验；
• 超时、重试和取消机制；
• 幂等性与副作用说明；
• 可供模型理解的错误信息；
• 日志和审计记录。

2.4.1 工具定义

下面是一个简化的 OpenAI Function Calling 风格工具定义：

{
  "type": "function",
  "function": {
    "name": "search_web",
    "description": "搜索公开网页并返回与查询相关的结果",
    "parameters": {
      "type": "object",
      "properties": {
        "query": {
          "type": "string",
          "description": "需要搜索的关键词"
        }
      },
      "required": ["query"],
      "additionalProperties": false
    }
  }
}

模型决定使用工具时，会返回结构化调用意图。不同 API 的具体字段可能不同，下面只表示其核心语义：

{
  "tool_call": {
    "name": "search_web",
    "arguments": {
      "query": "2026 年 Agent 技术最新进展"
    }
  }
}

应用程序随后执行以下流程：

sequenceDiagram
    participant U as User
    participant R as Runtime
    participant M as Model
    participant T as Tool

    U->>R: 提交目标
    R->>M: 目标 + 上下文 + 工具定义
    M-->>R: Tool Call
    R->>R: 校验参数与权限
    R->>T: 执行工具
    T-->>R: Tool Result
    R->>M: 返回 Observation
    M-->>R: 下一步动作或最终答案
    R-->>U: 返回结果

2.4.2 工具调用的安全边界

并非所有工具调用都应该自动执行。生产系统通常按风险等级处理：

2.5 MCP：标准化工具与上下文连接

这里讨论架构集成边界；MCP 协议本身见Tools：MCP，需要跨系统 Agent 协作时见Tools：A2A。

MCP（Model Context Protocol）为 AI 应用连接工具和数据源提供了标准协议。

MCP 最初由 Anthropic 在 2024 年提出，2025 年 12 月成为 Linux 基金会旗下 Agentic AI Foundation 的创始项目。基金会提供厂商中立的组织治理，协议的技术方向仍由 MCP 社区维护者管理。

MCP 包含三个主要角色：

• Host：面向用户的 AI 应用，负责模型、权限和整体交互；
• Client：由 Host 创建和管理，维护与某个 MCP Server 的连接；
• Server：向 Client 暴露 Tools、Resources 和 Prompts 等能力。

flowchart LR
    H[Host
AI Application] --> C1[MCP Client]
    H --> C2[MCP Client]
    C1 <--> S1[MCP Server
Files]
    C2 <--> S2[MCP Server
Database]
    S1 --> F[文件系统]
    S2 --> D[数据库]

“MCP 是工具世界的 USB-C”是一个有用的类比，但需要补充两个边界：

1. MCP Server 通常仍需安装、配置或由 Host 建立连接，并不是自动发现互联网上的所有工具。
2. 接口标准化不等于自动获得权限，认证、授权和用户确认仍由系统负责。

MCP 降低的是协议适配成本，而不是消除安全治理和业务集成。

2.6 State 与 Memory：不要混为一谈

2.6.1 任务状态

State 描述任务当前执行到哪里，例如：

• 原始目标；
• 当前计划；
• 已完成和待执行步骤；
• 工具调用及其结果；
• 错误、重试次数和预算；
• 等待中的人工审批。

状态通常需要结构化保存，并支持 checkpoint、恢复和并发控制。即使进程重启，可靠的 Agent 也应能够从 checkpoint 继续执行。

2.6.2 工作记忆

工作记忆服务于当前任务，保存模型本轮决策所需的信息，例如最近的消息、关键观察和中间结论。

工作记忆受上下文窗口限制，但不一定在任务结束后立即销毁。系统可能将其摘要、归档或转化为长期记忆。

2.6.3 长期记忆

长期记忆保存跨任务可复用的信息。它并不等同于向量数据库，常见存储方式包括：

• 关系数据库：用户资料、权限和结构化事实；
• 键值或文档数据库：偏好、配置和任务快照；
• 向量数据库：非结构化内容的语义检索；
• 事件存储：完整操作历史和审计轨迹；
• 知识图谱：实体关系和可解释的关联查询。

向量检索适合“语义相近”的召回，但精确事实、时间条件和权限约束通常需要 metadata 过滤或结构化查询配合。

2.7 长期记忆的认知分类

可以借用认知科学中的分类理解 Agent 记忆，但它只是概念模型，不代表底层必须建立三个独立数据库。

2.7.1 语义记忆（Semantic Memory）

保存可复用的事实和概念，例如：

• 用户从事金融行业；
• 某 API 的调用限制是每分钟 60 次；
• 项目使用 PostgreSQL 作为主数据库。

2.7.2 情景记忆（Episodic Memory）

保存带有时间和上下文的具体经历，例如：

• 上次处理退款任务时发现订单已超过退款期限；
• 某次部署因为数据库迁移顺序错误而失败。

2.7.3 程序性记忆（Procedural Memory）

保存“如何完成任务”的经验，例如：

• 处理退款前先检查订单状态和支付渠道；
• 发布版本前依次执行测试、构建和变更检查。

程序性记忆在工程上可能表现为工作流、Skill、策略模板或经过验证的操作手册，而不一定是普通的向量文本。

2.8 Context Engineering：管理有限上下文

2.8.1 上下文是会耗尽的预算，不是可以填满的桶

复杂任务会产生大量工具结果。若将所有内容不断追加到 Prompt，会导致：

• 超出上下文窗口；
• 推理成本和延迟增加；
• 关键信息被噪音淹没；
• 模型出现“中间遗忘”或关注错误内容。

一个常见的误解是：上下文窗口越来越大，这个问题就自动消失了。

事实并非如此。实验证据表明，模型性能会随输入长度非均匀地下降，而且这种下降在远未触及窗口上限时就已经发生——这一现象通常被称为 Context Rot。经典的“大海捞针”式测试之所以显得乐观，是因为它只考察字面匹配的检索，而真实任务需要的是在长上下文中做语义判断与多步推理。

因此正确的心智模型是：

把上下文当作有限且会随使用而衰减的注意力预算，目标是找到“完成当前决策所需的最小充分 Token 集合”，而不是尽量多塞。

2.8.2 上下文失效的四种形态

把“上下文太长”笼统当成一个问题，是无法定位故障的。工程上应该区分四种不同的失效模式，它们的成因和解法都不同：

Context Confusion 是最容易被低估的一个。 已有评测显示，可选工具数量增长到几十个量级时，工具选择准确率就会明显下降——这远早于上下文被填满。这直接否定了“把所有 MCP 工具都挂上去，模型自己会挑”的做法。

2.8.3 四类基本操作：Write / Select / Compress / Isolate

业界常用的一个组织框架，是把所有上下文管理手段归为四类操作：

flowchart TB
    CE[Context Engineering] --> W[Write 写出去]
    CE --> S[Select 选进来]
    CE --> C[Compress 压缩]
    CE --> I[Isolate 隔离]

    W --> W1[Scratchpad / 笔记文件]
    W --> W2[长期记忆]
    S --> S1[检索记忆与文档]
    S --> S2[按需加载工具]
    C --> C1[摘要 / Compaction]
    C --> C2[结果裁剪]
    I --> I1[Sub-Agent 独立上下文]
    I --> I2[沙箱中处理大对象]

前面的策略表可以映射到这个框架里：

2.8.4 Just-in-Time 检索：只维护引用，用时再取

一种已被生产系统验证的做法是：上下文里只保留轻量引用（文件路径、查询语句、URL、ID），真正的内容在需要时通过工具动态加载。

这模仿了人类使用文件系统的方式——你不会把整个代码库背下来，而是记住目录结构，需要时再打开具体文件。

实践中效果最好的通常是混合模式：

• 预加载少量稳定且高价值的内容，例如项目约定文件（AGENTS.md / CLAUDE.md）、核心业务规则；
• JIT 加载体量大或时效性强的内容，例如具体源文件、检索结果、数据库记录。

需要注意的是，JIT 检索本身也有成本：每次加载都要多一轮工具调用，会增加延迟。对于每次任务都必然用到的内容，预加载反而更划算。

2.8.5 Compaction：接近上限时重建上下文

当上下文接近窗口上限时，把历史压缩为摘要，然后用「摘要 + 少量最近工作集」重新初始化会话。典型的工作集包括最近访问的几个文件、当前待办清单、以及尚未验证的假设。

压缩时的一条实用原则是：先保证召回，再考虑精简。宁可摘要长一点也不要漏掉关键决策与约束，因为漏掉的信息在后续轮次里无法恢复。

Compaction 有两个必须知道的风险：

1. 摘要会把不确定的结论固化成事实。例如某个命令因超时被中断、只输出了部分结果，摘要却把它记录成“已确认的执行结果”，这个虚假的确定性会跨会话传播且不会被重新验证。缓解方式是在摘要中显式保留状态标记（已验证 / 未验证 / 失败），而不是只记结论。
2. 反复压缩会累积信息损耗。长周期项目中，早期的关键决策经过多轮压缩后可能彻底丢失，形成难以追溯的“历史债”。缓解方式是把重要决策同时写入外部文件（Write 操作），而不是只依赖上下文内的摘要链。

2.8.6 结构化笔记：把状态放到上下文之外

让 Agent 主动维护外部笔记文件（进度、已确认事实、待办、失败尝试），是成本极低但收益很高的做法。它的价值在于上下文可以被重置，但文件不会丢，从而让 Agent 具备跨越压缩边界甚至跨会话的连续性。

这一做法在长时间运行的任务中效果尤其明显：即使中途多次触发 Compaction，Agent 依然能通过重读笔记恢复完整的任务状态。

2.8.7 Sub-Agent 隔离：用于分离关注点，而不只是并行

把探索性的子任务交给 Sub-Agent，让它在干净的上下文中工作，最后只向主 Agent 回传一份浓缩结论（通常在一两千 Token 量级）。

这里有一个常见误解需要澄清：Sub-Agent 的首要价值是上下文隔离，而不是并行加速。 即使串行执行，让子任务的大量中间过程不污染主上下文，本身就是收益。

主 Agent 的上下文因此只包含「目标 + 各子任务结论」，而不是「目标 + 所有中间过程」，这让它在长任务中更不容易分心。

2.8.8 工具与知识的渐进式披露

对于工具和技能这类“可能用得上、但大多数任务用不到”的内容，正确做法是分级加载：

1. 一级：只加载名称与一句话描述（判断相关性用）；
2. 二级：判定相关后，才加载完整说明与用法；
3. 三级：需要细节时，再读取绑定的参考文件或脚本。

这样绑定的知识总量可以近乎无限，而运行时实际占用的上下文保持很小。Anthropic 的 Agent Skills 就是这一思路的标准化实现。

工具规模较大时（几十上百个），进一步的做法是用检索代替全量注入：提供一个 search_tools 元工具，由 Agent 先检索出候选工具再调用。另一种更彻底的思路是把工具暴露成代码 API，让模型写代码来调用工具，并在沙箱内先对结果做过滤和聚合，只把最终需要的少量数据送回上下文。已公开的工程实践显示，这类改造在工具数量庞大的场景下可以把工具相关的 Token 占用降低一到两个数量级。

需要保持清醒的是，渐进式披露不是无条件有效的。已有对照研究指出，当底层 Agent 框架本身已经具备较强的检索与导航能力时，额外的分级结构收益接近于零，甚至再增加一层路由会损害准确率。它买到的是上下文空间，而不是智能——决定是否采用，取决于你的工具/文档规模和框架的原生导航能力。

2.8.9 小结

现代 Agent 通常组合使用上述所有策略，而不是只依赖滑动窗口。

上下文工程的核心，不是“保存得越多越好”，而是在正确的时刻提供完成当前决策所需的最小充分上下文。

2.9 记忆写入、检索与衰减

2.9.1 什么值得保存

如果把所有内容都写入长期记忆，噪音、重复和错误信息会持续累积。写入前应考虑：

• 是否与未来任务有关；
• 是否具有稳定性和可信来源；
• 是否包含敏感或受监管数据；
• 是否已经存在重复记录；
• 是否需要用户同意；
• 是否应该设置有效期。

可以结合重要性、新颖性、可信度和可复用性决定是否持久化。

2.9.2 基础时间衰减

一种简单的时间衰减函数是：

$$ D(\Delta t)=e^{-\lambda \Delta t} $$

其中：

• $\Delta t$ 表示记忆距当前时间的间隔；
• $\lambda$ 表示衰减速度；
• $D(\Delta t)$ 表示时间权重。

最简单的检索分数可以写为：

$$ Score(m,q)=S(m,q)\cdot D(\Delta t) $$

其中 $S(m,q)$ 是记忆 $m$ 与查询 $q$ 的语义相似度。

2.9.3 更稳健的生产级排序

仅使用“相似度乘以时间衰减”可能错误地压低重要但久远的事实。更常见的思路是综合多个信号：

$$ Score(m,q)= \alpha S_{sem} + \beta S_{time} + \gamma S_{importance} + \delta S_{task} + \epsilon S_{trust} $$

这些信号分别表示语义相关性、时间新鲜度、重要性、任务匹配度和可信度。

不同业务应采用不同策略：

• 客服对话可以更强调新鲜度；
• 用户长期偏好可以缓慢衰减；
• 法律、审计和合规记录不应因时间自动删除或降级；
• 安全策略和明确事实应具有更高可信度权重。

此外，还需要处理记忆更新、冲突、去重、删除、隐私和数据保留策略。

2.10 Planning：从推理到可执行控制

规划模块负责：

• 将目标拆解为子任务；
• 识别步骤依赖；
• 选择执行顺序和工具；
• 跟踪完成状态；
• 根据反馈重新规划；
• 判断何时终止或请求人工帮助。

规划通常不是完全独立的单一模块，而是由模型、状态机、工作流引擎和 Runtime 共同实现。

2.10.1 CoT：链式推理

CoT（Chain of Thought）通过中间推理步骤帮助模型解决复杂问题。历史上常使用“Let's think step by step”等提示触发逐步推理。

但在现代 Agent 系统中，需要区分：

• 内部推理：模型用于完成决策的内部计算；
• 可展示依据：提供给用户的简洁理由、证据和执行记录。

系统不应依赖模型向用户暴露完整的隐藏思维过程。更可靠的做法是要求模型输出结构化计划、引用证据、工具轨迹和可验证结论。

2.10.2 ToT：搜索多个候选路径

ToT（Tree of Thoughts）在多个候选推理路径之间进行展开、评估和回溯：

flowchart TB
    S[当前状态] --> A[候选路径 A]
    S --> B[候选路径 B]
    S --> C[候选路径 C]
    A --> EA[评估]
    B --> EB[评估]
    C --> EC[评估]
    EA --> BEST[选择或回溯]
    EB --> BEST
    EC --> BEST

它适合搜索空间较大、存在多种方案的任务，但调用次数、延迟和成本通常高于线性推理。生产系统更常使用受预算约束的候选生成、评分和回退，而不是无限展开完整思维树。

2.11 两类基础执行模式

2.11.1 Plan-and-Execute

Plan-and-Execute 先生成整体计划，再逐步执行：

flowchart LR
    G[目标] --> P[生成完整计划]
    P --> S1[步骤 1]
    S1 --> S2[步骤 2]
    S2 --> S3[步骤 3]
    S3 --> R[结果]

优点：

• 全局结构清晰；
• 易于估算成本和依赖；
• 可以在执行前进行人工审核。

缺点：

• 早期计划可能建立在错误假设上；
• 环境变化后需要局部或整体重规划。

2.11.2 ReAct

ReAct 将推理、行动和观察交替进行：

flowchart LR
    R[Reason] --> A[Act]
    A --> O[Observe]
    O --> R

优点：

• 能根据最新反馈动态调整；
• 适合信息不完整或环境变化频繁的任务。

缺点：

• 容易只关注局部下一步；
• 可能循环、走偏或反复调用工具；
• 成本和完成时间较难预估。

现代实现不一定向用户展示 ReAct 中完整的“Thought”，但会保留结构化的 Action、Observation 和运行轨迹。

2.11.3 分层混合规划

生产级 Agent 通常将两种模式结合：

1. 先生成高层里程碑和约束；
2. 每个里程碑内部采用动态执行；
3. 遇到失败或关键假设变化时重新规划；
4. 持续检查目标、预算和终止条件。

flowchart TB
    G[目标] --> HP[高层计划]
    HP --> M1[里程碑 1]
    HP --> M2[里程碑 2]
    HP --> M3[里程碑 3]

    M1 --> L1[局部 Reason-Act-Observe 循环]
    L1 --> C{里程碑完成?}
    C -->|否| L1
    C -->|是| M2
    C -->|假设失效| HP

这种方式同时保留全局方向和局部适应性，是比单独使用 Plan-and-Execute 或 ReAct 更稳健的默认方案。

2.12 Runtime 与 Guardrails

Runtime 是把模型能力变成可靠系统的执行层，通常负责：

• 模型和工具调用调度；
• 状态持久化与 checkpoint；
• 超时、取消和重试；
• 并发与队列管理；
• Token、时间和费用预算；
• 人工审批；
• 错误传播和恢复；
• Trace、日志和审计。

Guardrails 则用于限制 Agent 可以做什么，包括：

• 输入输出校验；
• 工具白名单；
• 最小权限；
• 敏感数据保护；
• 高风险操作确认；
• Prompt Injection 防护；
• 沙箱和网络访问限制；
• 最大步骤数和循环检测。

没有 Runtime 与 Guardrails 的 Agent 更接近一个实验性 Demo，而不是可安全部署的生产系统。

2.13 可观测性与评估

Agent 的结果具有非确定性，仅判断“最终有没有回答”通常不够。系统还应记录和评估：

• 计划是否合理；
• 工具选择是否正确；
• 参数是否有效；
• 是否出现无效循环；
• 结果是否有证据支持；
• 成功率、延迟和成本；
• 是否违反权限或安全策略。

常见评估层次包括：

1. 结果评估：最终任务是否完成；
2. 轨迹评估：执行路径是否正确、高效；
3. 工具评估：工具选择和参数是否合理；
4. 安全评估：是否越权或产生高风险副作用；
5. 在线监控：部署后的失败率、延迟和成本变化。

2.14 主流框架的侧重点

不同框架都覆盖 Agent 的若干组件，但侧重点不同：

框架只是实现手段。设计 Agent 时，应先明确状态、控制流、权限和评估方式，再选择合适的框架，而不是让框架替代系统架构设计。

2.15 本章总结

一个现代 Agent 通常按下面这条链路工作：

接收目标 → 读取状态与记忆 → 规划下一步 → 请求工具或 Agent → Runtime 安全执行 → 获取观察 → 更新状态 → 评估并继续

四组件模型解释了 Agent 的基本能力，而 Runtime、Guardrails 和 Observability 决定了这些能力能否安全、稳定地运行在真实环境中。

参考资料

• MCP Governance and Stewardship
• MCP joins the Agentic AI Foundation
• Microsoft Agent Framework Overview
• AutoGen Maintenance Mode
• Anthropic: Effective context engineering for AI agents
• Chroma Research: Context Rot — How Increasing Input Tokens Impacts LLM Performance
• LangChain: Context Engineering for Agents
• Drew Breunig: How Contexts Fail and How to Fix Them
• Anthropic: Equipping agents for the real world with Agent Skills
• Anthropic: Code execution with MCP
• Cloudflare: Code Mode — the better way to use MCP
• RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation