Agent 工程模式：一张分层地图，而不是一份模式清单

作者：Zafer_Liu ｜ www.zaferliu.me

写在前面：清单不是架构

2024 年底 Anthropic 发了一篇《Building Effective Agents》，随后一年里，中文技术圈涌现出大量"XX 种 Agent 设计模式"的汇编。这类文章可读性往往不错，但它们不能在工程上直接用。原因不在条目对错，而在层级：一份平铺十几条的清单里，有的是模式，有的是前置条件，有的是协议，还有几条互为子集。把它们摆成一张平行列表，会让人误以为"凑齐十几个积木就能搭出稳定系统"——而实际工程里，稳定系统恰恰死于积木之间的相互打架。

这篇文章做三件事：

1. 重新分层。把概念按"它在架构里站在哪一层"归位，而不是按主题贴标签。
2. 去重与补齐。合并重复条目，并补上生产系统里决定成败、但常被漏掉的几个模式。
3. 每条给出失败代价。不只写"优点/缺点"，而是写明不这么做会发生什么。

一、为什么平铺的清单不能直接用

这一节不讲某一份具体清单的得失，而是说清四类任何平铺式清单都会犯的结构性错误。你可以拿它去检验自己手上那一份。

1.1 层级错位

平铺清单最常见的问题，是混淆了三类性质完全不同的东西：

把「工具使用」和「优先级排序」并列，等于把承重墙和一盏射灯放在同一张采购清单上。前者缺了整个建筑不存在，后者缺了只是不够好看。看一份清单是否有用，先看它有没有区分"缺了就不成立"和"缺了只是不优雅"。

1.2 概念对立被抹平：Workflow 不是 Agent

这里有一个最容易被抹平、也最容易误导实践者的对立。

Anthropic 原文里有一个关键区分：Workflows是"通过预定义代码路径编排 LLM 与工具"，Agents是"由 LLM 动态决定自己的流程与工具使用"。这个区分不是为了分类学好看，而是因为它决定了你该在哪里设防：

• Workflow 的失败模式是路径写错——靠测试覆盖即可。
• Agent 的失败模式是路径没写——你无法穷举，只能靠护栏、预算和可观测性兜。

一旦把「提示链」「路由」「并行化」和「规划」平铺成同级条目，这个对立就被抹掉了。而规划（Planning）恰恰是 Agent 区别于 Workflow 的定义性能力，它不是一个可以横向比较的可选件，而是那条分界线本身。

顺带一提：这个对立对应到今天的实际形态，就是单次调用（Single-call）与自主循环（Agentic Loop）的区别。前者你能测，后者你只能观测。

1.3 重复项没有合并

平铺清单的条目越多，越容易把同一件事拆成两条：

条目数会因此虚高。一份清单的数字越大，越要问其中有多少是同一件事的不同说法。

1.4 协议混入模式

MCP 和 A2A 是线格式与能力发现机制，不是抽象解法骨架。它们会随生态演进被替换。

模式回答"结构该怎么组织"，协议回答"字节该怎么流动"。两者不该在同一张表里。

1.5 该重的写轻：成本工程

最后一条，也是最要命的一条：成本工程几乎总是被写轻。

大多数清单里都会有一条类似「资源感知优化」的条目，用三四步泛泛带过——估计复杂度、选择模型等级、削减上下文、监控开销。听起来没错，但它完全没有触及真正决定"能不能上生产"的那几件事：分层的依据是什么、缓存命中率怎么算、上下文预算怎么分配、以及什么条件下该主动降级。

二、重排后的骨架：六层 × 四轴

去掉重复、归位层级、补齐缺失之后，得到下面的结构。

六层

四轴（贯穿所有层的正交属性）

分层地图（总览）

*注意 L1 虽然排第二，却是花时间最少的一层；L0 和 L2 才是工程量的大头。拓扑选错最多是效率差，上下文和状态做错是直接不可用。

三、L0 地基：不可裁剪的两件

3.1 工具契约

定义：工具不是"给模型调用的函数"，是一份带权限边界的契约。每个工具需要同时定义：schema、权限范围、幂等性、超时、失败语义、以及返回结果的压缩形态。

步骤：

1. 写出工具的 JSON Schema，字段尽可能窄（能枚举就枚举，能约束范围就约束）。
2. 标注三个属性：只读/写入、幂等/非幂等、可逆/不可逆。
3. 明确失败语义：超时算失败还是未知？非幂等工具超时后能不能重试？
4. 定义返回值的压缩形态——原始响应往往几百 KB，进上下文前必须先削减。

优点：把最容易出事的地方（不可逆操作）显式化；重试策略有依据。

缺点：前期设计成本高；工具一多，契约本身需要版本管理和文档。

不这么做会怎样：

• 非幂等工具被当成幂等重试 →重复下单、重复发信、重复扣款。这是生产事故里最常见的一类。
• 工具返回未压缩 → 三次调用就把上下文吃满，系统"莫名其妙"变笨。
• 权限无边界 → 一个提示注入就能让 Agent 删库。

上面是声明了属性之后的正确分诊，下面是没声明时框架的默认行为——而框架默认「能重试」。这张图想说的是：幂等性不是一个文档字段，它是超时之后唯一还能决定动作对错的东西。

这是所有 Agent 的地基，不是清单里的一个并列条目。任何试图跳过它直接聊"多智能体架构"的讨论都是空谈。

3.2 上下文工程

定义：Context Engineering——把"模型此刻看到的每一个 token"当作被主动设计的产品，而不是被动累积的聊天记录。它是 2025 年从 Prompt Engineering 演化出来的概念，在 Agent 场景下重要性远超前者。

步骤：

1. 分配预算：给系统提示、工具定义、检索内容、历史对话、当前任务各划一条上限。
2. 定优先级：预算不够时，先砍谁？（通常是历史对话，最后才是系统提示和当前任务）
3. 被动 vs 主动：区分"被动追加"（把一切都塞进去）和"主动裁剪"（每轮重算该放什么）。
4. 格式即信号：结构化的分隔、标签、字段名本身会影响模型注意力，不是装饰。

优点：同样的模型、同样的任务，上下文设计好坏的差距可以大于换模型。

缺点：需要大量实验；效果依赖具体模型，换模型要重调。

不这么做会怎样：

• 上下文腐化（Context Rot）：对话越长，早期有效指令被稀释，模型开始在后期"忘记"约束。
• 成本线性膨胀而质量不涨——你花钱买到了噪声。
• 关键信息被埋在第 8 万 token 处，模型事实上读不到。

判断标准：如果你的上下文策略是"把历史全部保留"，那么你的 Agent 一定会在某个长度后突然变蠢。它只是还没到那个长度。

四、L1 拓扑：四种控制流

选控制流时真正要问的不是"哪个更强"，而是"我愿意承担哪种失效方式"。

4.1 提示链（Prompt Chaining）

定义：把任务拆成 2–6 个顺序步骤，每步留下稳定的中间产物。

步骤：定义完成标准 → 拆分子步骤并规定中间输出 → 每步强制固定结构 → 顺序执行并记录 → 在关键位置设验证关卡。

失败模式：误差复利。第一步 90% 准确，五步之后剩下 59%。链越长越脆。

不这么做会怎样：巨型 Prompt 里各步骤相互干扰，改一处崩三处，无法定位。

判断标准：如果你不能说出每一步的中间产物长什么样，你就没有真正拆开它。

4.2 路由（Routing）

定义：判断请求该交给哪条工作流/哪个工具/哪个模型。

步骤：提取信号（意图、领域、紧急度、置信度）→ 规则/分类器/混合决策 → 执行选中路径 → 不确定走后备（澄清、安全默认、升级）。

失败模式：静默错路由。用户拿到一个格式完美但答错方向的回答，比报错更糟。

不这么做会怎样：所有请求走同一条最重的路径，成本高且都不够专精。

判断标准：路由必须能"不确定"。一个永远返回确定答案的路由器会把错误分散到所有路径上，让你连问题出在哪都看不出来。

4.3 并行化（Parallelization）

定义：无依赖的子任务并发执行，再汇合。

步骤：识别独立子任务 → 并发执行 → 在汇合步骤合并（去重、排序、投票、总结）。

失败模式：汇合点冲突。并行分支返回矛盾结果时，如果没有仲裁规则，汇合就是随机选一个。

不这么做会怎样：串行等待，端到端延迟随子任务数线性增长。

判断标准：并行化唯一真正的难点是汇合策略，不是并发本身。想不清楚怎么合并，就先别并行。

4.4 反思循环（Reflection）

定义：生成 → 批评 → 修订，直到达到质量标准。

步骤：生成草稿 → 批评检查（缺失要求、逻辑漏洞、格式违规）→ 针对明确问题修订 → 达到 N 轮或评分通过则停。

失败模式（最关键的一条）：自我确认偏差。当检索本身错了，模型会用幻觉去"验证"幻觉——批评者与被批评者共享同一套错误前提，循环越多次反而越自信。

破解方法：批评者必须与被批评者信息源不同。用不同模型、不同检索、或外部工具（编译器、测试、计算器）做校验，而不是让同一个模型自我审视。

不这么做会怎样：你得到一个"看起来很仔细"的系统，它的错误被反复抛光但不被消除。

判断标准：如果批评者和生成者看到的是同一份上下文，这个循环基本没有价值。它只是让模型多花 token 重申自己。

五、L2 状态：被最严重低估的一层

大多数清单会把"记忆"写成一条：存什么、怎么标记、取什么、怎么注入。四步都对，但远远不够——状态管理是长任务 Agent 最容易失败的地方，比拓扑选择重要得多。把它压缩成一个条目，本身就是在低估它。

5.1 记忆分层

定义：按生命周期把状态分成三层，每层有不同的写入与遗忘规则。

失败模式：把三层混成一层。最常见的做法是"全部塞进向量库"——结果偏好和临时事实权重相同，检索出来互相干扰。

不这么做会怎样：要么每次从头问用户（体验差），要么记住一堆过期事实（更差）。

判断标准：记忆必须有遗忘机制。一个只增不减的记忆库，其检索质量必然随时间单调下降。

5.2 上下文压缩（Compaction）

定义：当上下文接近预算上限时，主动把历史摘要化，保留决策与结论，丢弃过程细节。

步骤：监控上下文占用 → 触发阈值时对最旧部分摘要 → 保留结构（决策、未决问题、关键事实）→ 重建上下文。

失败模式：摘要丢掉关键约束。压缩时把"用户要求不要动生产库"这条给蒸发了，后面的操作就全错了。

不这么做会怎样：长任务必然在某一次工具调用后崩掉（超长上下文报错），或质量骤降。

红色虚线走的是「可以丢弃」的路径，但它们最终都汇到同一个终点——「约束被蒸发」。这张图想说的是：丢什么是设计，唯独约束与禁令不是，它丢了就是事故。

判断标准：压缩时必须显式保留"约束与否定式指令"，这些是最容易被摘要方法丢掉、又最致命的内容。摘要 prompt 里应该明确要求保留所有约束、禁令、和未解决的问题。

压缩是长任务里唯一一处"你的输入会悄悄变掉"的地方，所以它值得单独校验：重建之后检查一遍约束还在不在。这一步的成本远低于出事后排查，而省掉它是压缩事故的主要来源。

一句话：长任务 Agent 的成败，取决于 L2。拓扑和护栏都是其次。

六、L3 自主：下一步由谁决定

这一层只有一项，但它是 Agent 与 Workflow 的真正分界。

先看 L1 那四种的共同前提：下一步做什么，由你写死的条件决定。提示链的步骤、路由的分支条件、并行的扇出数、反思跑几轮——走向都由你定的规则给出，模型只负责在规则指定的位置上填内容。你提前知道有哪些位置。

（L0 和 L2 不参与这个比较，因为它们不是控制流——它们管的是手边有什么工具、记不记得住事，不管流程怎么走。这条对比只在控制流之间成立。）

单智能体循环打破了这个前提：下一步做什么，是模型自己决定的。你给的是目标和工具，不是下一步的清单。同一个输入，两次运行可能走出完全不同的路径——不是随机性意义上的不同，而是「该做第几步」这个判断本身被交给了模型。

所以它和 L1 那四种的差别，不是「有没有循环」。反思循环也有环，它的环甚至也是模型驱动的：停止条件取决于模型给修订版打的分。差别在于环里跑的是你指定的动作，还是模型自己选的动作。反思的第 2 步永远是「批评」，第 3 步永远是「修订」，只有「还要不要继续」是问出来的；循环的下一步是执行搜索、还是换工具、还是直接回答，全是模型自己选。

L1 的四种，你可以在运行前列出所有可能的执行路径，从而静态回答它最坏会走到哪；L3 不能，它的路径树是模型输出空间的大小，只能靠运行时的手段兜住——硬预算、停止条件、超时、人工接管。而这些手段全部是 L4 的内容。所以循环单独成层，是因为它需要一套别处都用不到的验证方式；把治理项放在它下面，是因为它自己什么都保证不了。

6.1 单智能体循环与规划（Agentic Loop & Planning）

定义：模型自己决定下一步做什么、调用什么工具、何时停止。这是 Agent 与 Workflow 的分界。

步骤：把请求转为目标与约束 → 生成计划（步骤、依赖、所需工具）→ 执行并每步检查进度 → 新信息或失败时改计划。

失败模式：无限自我修正 + 目标漂移。Agent 在长循环里逐渐"忘记"最初要什么，转向容易达成的子目标。

不这么做会怎样：只能处理你能预先画出流程的任务，遇到开放式问题就废。

判断标准：单智能体循环必须配一个硬预算（轮数、token、时间、金额），且预算耗尽时的行为要预先定义（是交还部分结果，还是报错）。没有硬预算的单智能体循环不是 Agent，是烧钱器。

它唯一的安全边界就是硬预算耗尽时的行为：是交还部分结果，还是报错，还是升级给人。这三种都要在写第一行代码之前定好——因为除此之外，你对它的行为没有任何事先约束。

七、L4 弹性：出事和花钱时怎么办

关键在那道「幂等或已知断点？」的闸门：两条都不满足时，正确动作是升级给人，而不是重试。图中红色路径都是不该走的路——「部分成功 → 整批重试 → 重复执行」是生产事故的常见形态，「审批点太多 → 审批疲劳 → 全部放行」则说明 HITL 的安全感是假的。

7.1 异常处理与恢复（Recovery）

定义：预先为超时、schema 无效、工具故障、限流、部分成功准备应对策略。

步骤：检测错误 → 暂时性故障则退避重试（限次数）→ 切换替代工具/路径 → 必要时修复或回滚状态 → 高风险或持续失败则升级处理。

失败模式：把部分成功当成完全失败。批量操作做了 7 个失败 3 个，直接重试整批 → 前 7 个被执行两次（若工具非幂等，就是七次事故）。

不这么做会怎样：一次工具抖动中断整条工作流，用户看到的是"系统崩了"。

判断标准：重试的前提是幂等，或你确切知道上次执行到哪一步。这两条都不满足时，正确动作是升级给人，不是重试。

7.2 护栏（Guardrails）

定义：分层安全控制——输入筛查、策略约束、工具权限限制、输出验证。

步骤：筛查输入风险意图与缺失信息 → Prompt 与路由层执行策略 → 限制工具（只读模式、白名单、沙箱、限速）→ 验证输出（合规、格式、泄漏）→ 必要时拒绝或升级。

失败模式（注意这条）：过度拦截。护栏太紧，Agent 变成"什么都不敢做"，用户放弃使用。这在医疗、金融类场景里非常普遍。

不这么做会怎样：提示注入拿到工具权限 = 远程代码执行级别的风险。

判断标准：护栏的正确位置是工具边界，不是 prompt 里的一句叮嘱。写在系统提示里的"不要删除文件"，在提示注入面前等于没有。

7.3 人工回路（HITL）

定义：高风险操作先提交方案和理由，人工批准/编辑/拒绝后才执行。

步骤：Agent 起草方案与理由 → 人批准/编辑/拒绝 → 仅执行获批项 → 保存反馈改善后续行为。

失败模式：审批疲劳。如果每步都要批，人会在第三天开始无脑点"同意"——此时 HITL 提供的安全感是假的，而且比没有更危险（因为它给了你"有人在把关"的错觉）。

不这么做会怎样：不可逆操作（转账、发公告、删数据）被自动执行，一次误判就够。

判断标准：只对不可逆 + 高影响的操作设 HITL，其余靠护栏和回滚。让审批出现在真正需要人判断的地方，它的价值才守得住。

7.4 成本分层（Resource-Aware Optimization）

定义：按任务复杂度、重要性、风险、SLA 选择算力等级，在质量、延迟、成本间平衡。

步骤：

1. 估计复杂度/重要性/风险（可以用便宜的模型来做这层估计）。
2. 选择模型与工作流等级。
3. 削减无效上下文——这是省钱最大的一块，往往比换模型便宜一个数量级。
4. 监控开销与延迟，回头调优路由阈值。

失败模式：分层依据选错。按"任务类型"分层（简单问题→小模型）常常失败，因为表面的简单问题可能暗藏复杂推理。按可验证性分层更可靠：有客观校验手段的任务才敢降级。

不这么做会怎样：所有请求走最强模型，单位成本降不下来，规模化时被迫砍功能。

判断标准：在换小模型之前，先把上下文砍一半。上下文削减通常带来同等的成本下降，且不损失质量——换模型有质量风险，砍上下文的收益是纯赚。

这个话题最常被一句空话带过，却最该展开讲。它才是 Agent 从 demo 走到生产的门槛。

7.5 优先级排序

定义：多任务并发时，按紧急度、价值、风险、依赖关系评分并动态重算。

步骤：工作转成明确任务 → 策略评分 → 执行最高优先级 → 条件变化时持续重算。

失败模式：饥饿。评分函数设计不当，某类任务永远排在后面，长期得不到处理，且不易被发现。

判断标准：评分函数必须包含"等待时间"作为加分项，否则饥饿几乎必然发生。

八、L5 质量与协作

这四件——评估、可观测性、多智能体、Agent 间通信——单独看都不难，难的是前两件必须串成环才起作用。链断了，另外两件就没有输入。

上面那条是闭环，下面红色是每一环断掉时的样子。注意它们是上下对齐的：断在哪一环，症状就长在哪一环的下面。

8.1 评估体系（Evaluation）

定义：持续跟踪质量、成本、安全指标，用生产轨迹 + eval 数据集验证每次改动。

步骤：定义指标（准确率、有据性、延迟、成本、拒绝率）→ 构建 eval 集（含标准答案与对抗案例）→ 监控生产轨迹并告警 → 改进上线前做 A/B 对比。

失败模式：指标与目标脱节。优化"有据性"评分，模型学会只说没风险的空话——分数涨了，有用性掉了。

不这么做会怎样：你无法判断一次 prompt 改动是变好还是变坏，只能凭感觉，改到最后没人敢动。

8.2 可观测性（Observability）

定义：完整记录每一步的输入、输出、工具调用、决策依据、耗时、成本，形成可回放的轨迹。

步骤：定义 trace 结构（step / 输入 / 输出 / token / 成本 / 决策理由）→ 全量采集 → 提供按会话回放与检索 → 从中挖掘 eval 案例。

失败模式：只记结果不记理由。你知道它答错了，但不知道它为什么这么选——于是只能瞎改 prompt。

不这么做会怎样：线上问题无法归因，每次修复都是赌博。

判断标准：轨迹必须可回放。这是四轴里"证据"轴的落点，也是把生产问题转成 eval 案例的唯一通道。

8.3 多智能体协作（Multi-Agent）

定义：把研究、构建、验证交给不同专业 Agent，由协调器合并。

步骤：协调器拆解 → 分配子任务 → 专业 Agent 产出（笔记、代码、批评）→ 协调器合并并解决冲突，必要时迭代。

失败模式（最重要的一条）：协调开销吃掉收益。多个 Agent 之间传递上下文，信息在每次转手时衰减，最后合并出的结果比单 Agent 更差——而且成本是几倍。

红色虚线是每一次上下文转手，三路汇到同一个「合并结果」——而它标着「可能不如单体」。右边那条不拆分的绿线直接绕到单体 Agent，再以虚线汇入同一个终点，这就是这张图的核心对照：拆分多付了几倍成本和三次信息衰减，终点却可能一样甚至更差。

不这么做会怎样：单体 Agent 承担所有角色，上下文里角色混杂，互相干扰。

判断标准：只有当子任务真正可独立验证时才值得拆分。自问一句：你能给每个子 Agent 写出独立的验收条件吗？写不出来，说明拆早了。

8.4 Agent 间通信（A2A）

定义：跨团队、跨框架协作时，用结构化协议描述能力、任务请求、结果与进度。

步骤：Agent 声明能力 → 调用方发结构化任务请求 → 接收方返回结果/进度 → 调用方合并继续。

失败模式：信任边界丢失。跨组织调用时，接收方无法验证调用方的身份与意图，协调错误被逐级放大。

判断标准：A2A 是接口层，不是模式层。它随生态演进会被替换——把它写进你的架构模式清单，等于让清单的保质期被协议版本绑架。

九、可落地配方

以下是常见的组合方法：

配方 1：RAG + Reflection（检索 → 起草 → 批评 → 修订）

坑：检索错误时自我确认。批评者与生成者看同一份检索结果，模型把幻觉当依据校验通过。

解法：批评者必须独立取数（重新检索、或调用外部工具核验），而不是审视生成者的文本。

配方 2：Routing + Tool Use（分类 → 调用正确工具 → 回答）

坑：分类器与工具集漂移。新增工具后忘记更新路由规则，新工具永远不被调用。

解法：把"路由覆盖度"做成一个监控指标——统计每个工具被调用的比例，长期为 0 的工具要么没用，要么路由漏了。

配方 3：Planning + Recovery（规划 → 执行 → 失败恢复 → 继续）

坑：恢复后计划失同步。工具失败后走了替代路径，但计划里没更新，后续步骤基于过期前提执行。

解法：恢复动作必须同时更新计划状态，而不是只重试当前步骤。计划是有状态的，不是只读的。

配方 4：Multi-Agent + Evaluation（专业 Agent 起草 + 审查者评分 + 协调器合并）

坑：审查者与起草者同源。用同一个模型同一个 prompt 换个角色名，审查退化为走过场。

解法：审查者用不同的模型，或至少不同的上下文与明确的评分标准（rubric）。无 rubric 的"你觉得这个好不好"没有任何信息量。

配方 5：Guardrails + HITL（工具白名单 + 敏感操作人工批准）

坑：审批疲劳。审批点太多，人开始无脑放行。

解法：只对不可逆操作设审批；可逆操作靠护栏 + 回滚。并统计审批的"拒绝率"——长期为 0，说明这个审批点可以撤掉或收紧条件。

配方 6：Cost Tiering + Compaction（成本分层 + 上下文压缩）

坑：压缩在降级之后。先换小模型再压缩上下文，小模型本来就弱的指令遵循被噪声进一步削弱，质量断崖。

解法：先压缩，后降级。压缩是纯收益，降级有质量风险——把免费的收益先吃掉，再评估是否值得冒风险。

结语

这偏文章的价值，在于它把行业共识一次性铺开，让"Agent 工程"这件事有了可讨论的词汇表。它的问题在于铺平了——平铺的清单不告诉你哪条在地基、哪条在屋顶，而工程上的成败几乎全由层级决定。

我重排后的结论其实很短：

先把地基和状态做对，再挑拓扑。这是投入的优先级，不是施工的顺序。
四轴（上下文、成本、证据、爆炸半径）是判断一切模式是否做到位的尺子。
停不下来的单智能体循环，不是 Agent，是事故。

条目多少条，不重要。重要的是每一层都知道自己在哪，以及漏掉它的代价是什么。