外观
Agent 系统全景解剖
读论文和跑 demo 时，一个 Agent 看起来就是一个循环：LLM 思考、调工具、再思考。但当你要把它做成生产系统——能被监控、能控成本、出了错能定位、权限收得住——你会发现真正的工程量在循环之外：输入怎么进来、上下文怎么组装、记忆怎么存取、每一次工具调用怎么审计。
这一页我们做一件事：把一个生产级 Agent 系统按层解剖。每一层讲清三个问题——它负责什么、关键的设计决策是什么、业界通常怎么实现。如果你还没建立 Agent 的基本直觉，建议先读什么是 AI Agent再回来。
一个先决判断
Anthropic 在 Building Effective Agents（2024-12）里强调的核心取舍至今没过时：能用一个定义好的 workflow（代码编排 LLM 的固定流程）解决的问题，就不要上自主 agent（LLM 在循环里自己决定下一步）。下文的「六层解剖」描述的是完整形态，但大多数生产系统是裁剪后的子集——判断哪些层你需要、哪些层是过度设计，本身就是架构能力。
一、总览：六层架构图
先看全貌。下面这张图把一个生产级 Agent 系统拆成五个纵向层加一个横切的治理层，箭头标注了一次完整任务从输入到输出的数据流：
┌─────────────────────────────────────────────┐
│ 治理层（横切所有层） │
│ 权限/审批 · 评测 · Trace 可观测 · 成本/限流 │
└──────┬──────┬──────┬──────┬──────┬──────────┘
▼ ▼ ▼ ▼ ▼
用户/事件 ──(1)──▶ ┌──────────────┐
文本/文件/截图 │ 感知层 │ 输入解析、多模态转文本、
/工具返回 │ Perception │ 会话状态、输入校验
└──────┬───────┘
│ (2) 结构化后的观察 observation
▼
┌──────────────┐ (3) 组装 prompt ┌──────────────┐
│ 认知核心 │ ◀────────────────────── │ 记忆层 │
│ LLM + 提示词 │ ──────────▶ LLM 推理 ──▶│ Memory │
│ + 上下文组装 │ │ 短期上下文 │
└──────┬───────┘ │ 长期记忆/RAG │
│ (4) 输出：回复 或 工具调用意图 └──────▲───────┘
▼ │ (7) 写入
┌──────────────┐ │ 摘要/事实/
│ 规划层 │ 任务分解、todo 清单、 │ 经验
│ Planning │ 反思与重规划 │
└──────┬───────┘ │
│ (5) 下一步动作 action │
▼ │
┌──────────────┐ │
│ 行动层 │ 工具调用、代码执行沙箱、 │
│ Action │ 浏览器/电脑操作 │
└──────┬───────┘ │
│ (6) 工具返回结果 observation ────────────┘
▼
回到认知核心，循环直到产出最终答复 ──(8)──▶ 用户一次任务的循环是 (2)→(3)→(4)→(5)→(6)→回到(3)，中间穿插记忆读写（(3)时读、(7)时写）。这就是经典 Agent Loop 在分层视角下的样子：循环本身只是认知核心和行动层之间的往返，其余四层都是为了让这个循环在真实环境里可靠运转。
二、感知层：系统的五官
职责：把外部世界的信号变成认知核心能消化的结构化输入。
感知层处理的输入远不止「用户打的一句话」：
| 输入类型 | 典型来源 | 感知层要做的处理 |
|---|---|---|
| 用户文本 | 聊天框、API 请求、IM 机器人 | 意图识别、会话归属、敏感信息检测 |
| 文件 | 用户上传的 PDF/代码仓库/表格 | 解析、切块、OCR，转成文本或结构化数据 |
| 截图/图像 | GUI 截图、用户贴图 | 多模态模型直接理解，或先转描述文本 |
| 工具返回 | 上一轮工具调用的结果 | 清洗、截断、错误归一化 |
| 系统事件 | webhook、定时任务、消息队列 | 反序列化成任务描述，附带触发上下文 |
关键设计决策：
- 多模态还是文本化。让多模态模型直接看截图，还是先用视觉模型把截图转成文字描述再喂给主模型？前者保真度高、token 贵；后者便宜但丢信息。生产系统里常见做法是分层：主推理用文本，只有需要精确视觉定位时（比如 GUI 操作的坐标点击）才走原生多模态。
- 工具返回也算感知。很多教程把工具结果简单拼回上下文，但工具返回是 agent 最重要的「感知」渠道。一个返回了 5MB JSON 的 API 会把 context window 打爆，感知层需要在这里做截断、摘要、结构化错误（
{"error": "rate_limited", "retry_after": 30}比一坨 stack trace 有用得多）。 - 输入即攻击面。文件和网页内容里可能藏着 prompt injection，感知层是清洗的第一道关口，深入讨论见安全。
常见实现：轻量系统就是一个 FastAPI/Express 入口加文件解析库；重的系统会有独立的 ingestion pipeline（队列 + 解析 worker），把「收到请求」和「开始推理」解耦。
三、认知核心：LLM、提示词与上下文组装
职责：每一轮循环里，基于当前所有已知信息，决定「说什么」或「做什么」。
认知核心不是一个模型调用那么简单，它是三个部件的组合：
┌─ 系统提示词 system prompt ── 角色、规则、工具说明（相对静态）
│
├─ 上下文组装 context assembly ── 从各数据源拉出本轮需要的材料：
│ 会话历史 + 检索到的知识 + 长期记忆 + 工具结果 + 规划状态
│
└─ LLM 推理 ── 在有限 context window 内产出：最终答复 or 工具调用关键设计决策：
- 上下文工程是这一层的主战场。Anthropic 2025 年 9 月的 Effective Context Engineering 一文把这件事说得很直白：context window 是有限的、会衰减的资源（所谓 context rot），工程目标是在每一轮给模型「刚刚好」的信息——不是越多越好。具体手段包括：工具结果即时截断、历史会话压缩（compaction）、把大块资料放到文件系统里按需读取而不是塞进上下文。深入见上下文工程。
- 提示词分层。系统提示词管「你是谁、守什么规矩」，任务提示管「这次干什么」，few-shot 示例管「按什么格式做」。把三者混在一个巨型 prompt 里是最常见的维护灾难。见提示词工程。
- 结构化输出。行动层能不能可靠执行，取决于认知核心输出的工具调用是否严格符合 schema。用原生 tool calling / JSON schema 约束解码，别靠正则解析自由文本。
常见实现：一次 chat.completions / messages 调用，外面包一层上下文组装器。框架层面，LangGraph 把它显式建模成节点，OpenAI Agents SDK 把它包在 Runner 里——本质相同，见框架选型各页。
认知核心是系统里唯一「不可替代」的层
感知可以简化成纯文本入口，规划可以不要，记忆可以只有会话内上下文，行动可以只有一两个工具——但认知核心不行。反过来，这也意味着模型升级时这一层的变化最大：为 GPT-4 时代设计的复杂提示词脚手架，在新一代推理模型上往往是负资产。保持提示词和组装逻辑的可替换性，是给未来留的保险。
四、规划层：任务分解、todo 与反思
职责：把「用户想要的结果」变成「一串可执行的步骤」，并在执行偏离时修正路线。
规划在工程上有三种形态，复杂度和自主性递增：
- 无显式规划：agent 每一轮只决定下一步（ReAct 风格，arXiv:2210.03629）。适合短任务、工具少的场景。大多数客服、问答类 agent 停在这里就够了。
- 显式 todo 清单：开始执行前先产出计划（往往是一个 markdown 清单），执行中逐项勾选、允许修订。Claude Code 等编程 agent 的 TodoWrite 工具就是这个形态——计划本身作为工具状态存在，既给模型自我约束，也给人可视化的进度。
- 反思与重规划：执行后评估结果，失败时回溯修订计划。Reflexion（arXiv:2303.11366）是学术原型；工程上更常见的是「验证节点」——在关键步骤后插入一个检查（测试跑通了吗？检索结果相关吗？），不通过就回到规划。
关键设计决策：
- 先规划还是边做边想。先出完整计划（plan-then-execute）可控、可审查，但对环境变化的适应差；边做边想灵活，但容易在长任务里漂移。编程类 agent 的实践共识是混合：先粗计划，执行中允许局部重规划。
- 计划放在哪里。放在模型「脑子里」（每轮重新推理）不可靠——长任务里模型会忘记原计划。放在显式状态里（todo 工具、scratchpad 文件、图节点）才可靠，这也让治理层能审计「它打算干什么」。
- 反思不是免费的。每加一次自我评估就是一次额外的 LLM 调用，延迟和成本都翻倍。只在「失败代价高」的步骤上加验证节点，不要全局反思。
深入讨论见规划与任务分解。
五、行动层：工具、代码执行与电脑操作
职责：把认知核心的意图变成对真实世界的副作用，并把结果带回来。
行动层的工具按「副作用强度」可以排成一个光谱：
| 工具类别 | 例子 | 风险特征 |
|---|---|---|
| 只读检索 | 搜索、数据库查询、读文件 | 低：注意注入和数据泄露 |
| 代码执行 | 沙箱里跑 Python/JS | 中：需要隔离环境、资源限额 |
| 写操作 | 改文件、发 API 写请求、操作数据库 | 高：需要权限边界和审计 |
| 不可逆外部动作 | 发邮件、下单、删资源、转账 | 最高：必须 human-in-the-loop 审批 |
关键设计决策：
- 工具描述的工程质量决定调用质量。工具名、参数 schema、docstring 是模型选择工具的唯一依据。「返回用户对象」不如「返回用户对象，含 id/name/email；未找到时返回 null 而不是报错」。这是工具与 MCP 页的核心话题。
- MCP 正在统一工具接入面。Model Context Protocol 把「工具/数据源暴露给 agent」标准化成 client-server 协议——官方类比是 AI 应用的 USB-C 接口。2025 年后 Claude、ChatGPT、VS Code、Cursor 等主流客户端都支持 MCP，新系统接工具优先考虑 MCP server，而不是每家客户端写一套适配。
- 执行环境隔离。代码执行必须在沙箱（容器、microVM）里跑，带网络白名单和资源限额。浏览器/电脑操作（computer use）同理：给 agent 一个受控的虚拟机，而不是你的开发机。
- 失败是常态输入。网络超时、限流、schema 不匹配——行动层要把所有失败归一化成模型能理解的错误返回，让认知核心决定重试、换工具还是放弃。把异常直接抛出循环的系统都活不过第一个 Monday。
涉及人工审批的拦截设计，见Human-in-the-loop。
六、记忆层：短期上下文、长期记忆与知识库
职责：让 agent 拥有超出单次请求的信息——记得这轮对话、记得这个用户、知道组织里的知识。
记忆层通常分三档，对应人类记忆的经典分类（学术界 2023 年以来的主流 taxonomy）：
┌─ 短期/工作记忆 ── 就是 context window 里的会话状态
│ 生命周期 = 单次任务；管理手段 = 截断、摘要、compaction
│
├─ 长期记忆 ── 跨会话持久化，三类：
│ · 语义记忆 semantic：用户画像、偏好、事实（"用户是后端工程师"）
│ · 情节记忆 episodic：过去交互的事件记录（"上周三那次部署失败了"）
│ · 程序记忆 procedural：学到的流程与技能（"这个团队的发布流程是…"）
│
└─ 知识库 / RAG ── 组织的文档、代码库、工单
严格说不算「记忆」，而是外接知识；检索后注入上下文关键设计决策：
- 谁决定记什么。两条路线：被动提取（对话结束后由后台流程抽取事实入库，Mem0 是代表）与 agent 自主管理（模型自己调用「记忆读写」工具决定存什么，MemGPT/Letta 是代表，arXiv:2310.08560，其分层为 core / recall / archival 三级，类比操作系统的内存管理）。前者简单可控，后者灵活但更难调试。2025-2026 年的趋势是两者融合：agent 主动记，后台异步整理（Letta 称之为 sleep-time compute）。
- 记忆写错了比没记忆更糟。一条错误的用户画像会污染之后所有会话。长期记忆需要写入置信度、来源、过期机制——这本质上是数据治理问题，不是检索问题。
- RAG 与记忆的边界。工程上有用的区分：记忆是「关于交互历史的」，RAG 是「关于世界知识的」。两者存储和检索技术栈高度重叠（向量库 + 混合检索），但更新频率、权限模型、错误代价完全不同，不要塞进同一张表。深入见记忆系统与RAG。
七、治理层：横切一切的控制面
治理层不是数据流上的一环，而是架在所有层之上的控制面。它回答四个问题：
1. 权限：它能做什么？ 每个工具调用经过策略检查：这个 agent 身份有没有权限调这个 API、动这份数据？高危动作（发邮件、改生产配置）走人工审批队列。最小权限原则对 agent 比对人更重要——人滥权是恶意的，agent 滥权可能只是幻觉。见安全。
2. 评测：它做得好不好？ 离线 eval（固定数据集上跑回归）+ 在线抽检（生产 trace 抽样打分）。没有 eval 的 agent 迭代等于闭眼改代码。见评测与评测实践。
3. 可观测：刚才发生了什么？ 一次 agent 执行是一条调用链：用户输入 → 组装 → LLM → 工具 → LLM → …… → 答复。每一跳都要记录输入输出、token 消耗、延迟、工具参数与返回——也就是 trace。OpenTelemetry 的 GenAI semantic conventions 已经为模型调用、工具调用、token 用量定义了标准 span 属性，LangSmith（2025 年 3 月起完整支持 OTel）、Langfuse（开源自托管）、Arize Phoenix 等平台都围绕这套数据模型构建。trace 同时是评测和调试的原材料，见可观测性。
4. 成本：这轮值多少钱？ agent 的成本结构是非线性的：循环轮数不可预期，一个失控的重试循环可能烧掉一顿饭钱。治理层需要：每会话/每租户预算上限、循环轮数硬上限、按任务复杂度路由到不同价位的模型（简单分类走小模型，主推理走大模型）、prompt caching。细账见成本控制。
治理层最容易被砍掉，也最不该被砍掉
demo 阶段治理层的代码量是零，出事的概率也是零——因为没有真实用户和数据。上线后反过来：多数生产事故不是「模型不够聪明」，而是权限没收住、失败没 trace、成本没上限。把治理层当成 v2 再加的团队，往往没有机会做 v2。
八、一次请求的系统之旅
把前面六层串起来，看一个具体请求——「帮我查一下上个月的账单异常，给财务写封邮件草稿」——在系统里的完整旅程：
| # | 阶段 | 经过的层 | 系统里实际发生的事 |
|---|---|---|---|
| 1 | 接收 | 感知层 | 鉴权、会话恢复；治理层记录请求入口（trace root span） |
| 2 | 理解 | 感知层 → 认知核心 | 输入结构化；组装器拉入会话历史、用户画像（语义记忆）、财务知识库检索结果 |
| 3 | 规划 | 规划层 | 产出 todo：①查账单数据 ②找异常 ③起草邮件；写入显式计划状态 |
| 4 | 决策 | 认知核心 | LLM 输出工具调用：query_billing(month=2026-07) |
| 5 | 权限检查 | 治理层 | 策略引擎确认该用户身份可读账单数据，放行并记审计日志 |
| 6 | 执行 | 行动层 | 调用账单 API；结果 200KB，感知层截断摘要为关键字段后返回 |
| 7 | 循环 | 认知核心 | 模型基于账单数据发现 3 笔异常，决定再调 get_invoice_detail 取证 |
| 8 | 反思 | 规划层 | todo ①② 勾选完成；验证节点检查「异常都有单据支撑」通过 |
| 9 | 高危拦截 | 治理层 | 模型想调 send_email——策略判定为高危外部动作，降级为「生成草稿待用户确认」（human-in-the-loop） |
| 10 | 产出 | 认知核心 → 感知层 | 生成邮件草稿 + 异常摘要，渲染给用户 |
| 11 | 沉淀 | 记忆层 | 后台提取：「用户关注账单异常」「财务联系人是谁」写入长期记忆 |
| 12 | 收尾 | 治理层 | trace 关闭：总轮数、总 token、总成本入账；该会话计入用户月度配额 |
注意第 5、9、12 步：一个「裸循环」的 demo 里这三步完全不存在，而它们是生产系统和玩具的分水岭。
九、单 Agent 与多 Agent：解剖差异
同样的六层框架，套在单 agent 和多 agent 系统上，长出来的形状很不一样：
| 维度 | 单 Agent | 多 Agent |
|---|---|---|
| 认知核心 | 一个 LLM 循环，一份主上下文 | 每个子 agent 独立上下文，彼此通过消息通信 |
| 规划层 | 规划与执行同一脑内完成 | 出现专职 orchestrator：分解任务、分派、汇总 |
| 记忆层 | 一套记忆服务一个主体 | 多出「共享记忆/黑板」问题：谁写、谁读、冲突怎么解 |
| 行动层 | 工具集有限且内聚 | 各 agent 工具集按角色隔离，权限天然最小化 |
| 治理层 | trace 是一条链 | trace 是一棵树：跨 agent 的 span 关联、成本归账、错误传播都变复杂 |
| 失败模式 | 上下文爆炸、循环失控 | 上述全部 ×N，外加通信失真、死锁、责任难以归因 |
什么时候多 agent 才是正解？ LangChain 2026 年初的选型文章给出的建议与 Anthropic 一脉相承：从单 agent + 好工具开始，多数任务到此为止。真正的升级信号是这几个：
- 单 agent 的上下文塞不下任务所需的全部领域知识（每个子 agent 各有独立 context window，是最实在的收益）；
- 工具数量多到模型选错率明显上升（按角色拆分工具集）；
- 任务天然并行（如同时调研十个主题）；
- 不同环节需要不同模型/不同权限边界。
反过来，「一个 agent 扮演产品经理、一个扮演工程师、一个扮演测试」式的角色扮演多 agent，在多数生产场景里是过度设计——子 agent 间用自然语言传信息是有损压缩，协调成本经常超过分工收益。判断框架和拓扑的细节见多 Agent 架构。
把多 agent 想成组织设计，不是算法设计
单 agent 系统的瓶颈是模型能力；多 agent 系统的瓶颈是接口设计——任务怎么切、交接信息传什么格式、谁来仲裁冲突。这和设计一个工程师团队的分工是同一类问题。如果你的多 agent 拓扑画出来像一个真实公司臃肿的汇报链，它大概率也会像那样低效。
十、小结：分层视角怎么用
这份解剖图的实际用途有三个：
- 设计时当清单。新系统立项，逐层问一遍：这层我要不要？要什么形态？多数内部工具的答案是：感知从简、规划省略、记忆只有短期、行动三五个工具、治理只要 trace 和轮数上限。
- 排障时当地图。agent 行为异常时先定位是哪一层的问题：答非所问看认知核心的上下文组装，乱调工具看行动层的工具描述，重复劳动看记忆层，失控烧钱看治理层的上限设置。
- 学习时当索引。本站核心组件与进阶架构两个栏目，基本就是按这六层组织的——从全景学习路径出发，哪层不熟补哪层。
参考资料
- Building Effective Agents — Anthropic —— workflow 与 agent 的经典区分，「从最简单的方案开始」的总原则出处。
- Effective Context Engineering for AI Agents — Anthropic —— 上下文作为有限资源，compaction、工具结果管理、子 agent 隔离等认知核心与记忆层工程实践。
- Choosing the Right Multi-Agent Architecture — LangChain —— 单 agent 优先、多 agent 升级信号与拓扑选型的权威建议。
- Model Context Protocol 官方文档 —— MCP 的定位、client-server 架构与生态支持现状。
- ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629) —— 推理-行动循环的原型论文，规划层「无显式规划」形态的来源。
- Reflexion: Language Agents with Verbal Reinforcement Learning (arXiv:2303.11366) —— 反思机制的学术原型。
- MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) —— 分层记忆（core/recall/archival）与 agent 自主记忆管理的开山之作。
- OpenTelemetry GenAI Semantic Conventions —— LLM 调用、工具调用、token 用量的标准 trace 属性定义，可观测层的数据模型基础。