用六个工程问题重构《Agentic Design Patterns》

六个工程问题重构《Agentic Design Patterns》

• • 一、先判断是否真的需要 Agent
  • • 1.1 四级复杂度
    • 1.2 升级原则
  • 二、问题一：如何拆任务和控制流程
  • • 2.1 控制流的复杂度阶梯
    • 2.2 五个关键选择
    • 2.3 流程控制的底线
  • 三、问题二：如何安全连接外部世界
  • • 3.1 五类能力不要混用
    • 3.2 证据与动作必须受控
    • 3.3 外部连接的底线
  • 四、问题三：如何管理概率性错误
  • • 4.1 先分类，再恢复
    • 4.2 Reflection 必须依赖外部标准
    • 4.3 恢复必须是有界状态机
  • 五、问题四：如何管理状态
  • • 5.1 五层状态
    • 5.2 任务状态必须显式、可恢复
    • 5.3 记忆与学习是数据治理
  • 六、问题五：如何约束自主性
  • • 6.1 先定义自治包络
    • 6.2 四个确定性边界
    • 6.3 自主性的底线
  • 七、问题六：如何证明系统值得上线
  • • 7.1 从正确的基线开始
    • 7.2 六层评估
    • 7.3 用消融实验删除伪价值
    • 7.4 Level 3 的准入门槛
    • 7.5 上线最低门槛
  • 八、贯穿案例：退款系统如何逐级演进
  • • 8.1 五个阶段
  • 九、21 个模式的工程定位
  • • 9.1 模式不是功能清单
  • 十、架构评审清单
  • • 10.1 六问即可筛掉大部分伪复杂度
  • 十一、总结：Agent 工程的本质是约束复杂度
  • • 11.1 六个问题组成同一个控制闭环
    • 11.2 生产 Agent 的正确心智模型
    • 11.3 六条生产不变量
    • 11.4 六个工程问题的最终答案
    • 11.5 复杂度升级的最终边界

《Agentic Design Patterns》学习地址

《Agentic Design Patterns》提供了 21 个模式，但模式目录并不等于工程决策顺序。如果把 Prompt Chaining、Planning、Reflection、Memory、MCP、A2A 等能力全部装进系统，常见结果不是更智能，而是更贵、更慢、更难排障。

更有效的读法，是把全书压缩为六个生产问题：

它们对应一条更自然的研发主线：

控制流程 → 连接事实与动作 → 验证和恢复 → 管理状态 → 约束自主性 → 评估上线价值

一、先判断是否真的需要 Agent

1.1 四级复杂度

1.2 升级原则

1）始终选择最低有效复杂度

绝大多数企业应用的合理终点是 Level 2：单 Agent + 显式工作流 + 工具 + 状态 + 验证 + 人工审批。

多 Agent 是组织和系统边界带来的结果，不是角色提示词越多越高级。

二、问题一：如何拆任务和控制流程

所有 Agent 首先都是控制流系统。工程上真正要回答的是：下一步做什么、依据是什么、失败后去哪里、何时停止。

2.1 控制流的复杂度阶梯

一次调用
↓
固定顺序：Prompt Chaining
↓
条件分支：Routing
↓
独立任务：Parallelization
↓
动态路径：Planning
↓
资源竞争：Prioritization

2.2 五个关键选择

1）固定路径优先使用 Prompt Chaining 步骤可预先确定时，用分阶段流水线即可：

抽取事实 → 校验结构 → 执行分析 → 生成结果

关键不是多调用几次模型，而是单一职责、结构化传递、逐步校验和局部重试。 2）出现分支时再增加 Routing 路由优先级通常是：业务规则 → 轻量分类器 → Embedding → 通用 LLM。LLM 可以判断用户意图，但身份、权限、金额和安全等级必须由确定性系统裁决。 3）只有无数据依赖的任务才能并行 并行的难点在 Join，而不在 Fork。必须提前定义 Reducer、超时、并发上限、冲突处理和部分成功语义；否则只会把单点问题变成分布式问题。 4）路径无法预先枚举时才使用 Planning 推荐受约束的 Planner–Executor：

目标、约束、预算
↓
Planner 生成结构化计划
↓
Executor 执行当前步骤
↓
验证器检查结果
├─ 通过：继续
├─ 环境变化：局部重规划
├─ 可恢复错误：恢复
└─ 高风险或预算耗尽：停止或转人工

计划至少应包含步骤、依赖、预期输出、验收条件、风险和状态，而不是一段自然语言愿望。 5）Prioritization 本质是资源调度 优先级应综合安全与合规、截止时间、业务价值、依赖、执行成本和 Aging，不能只让 LLM 输出“高、中、低”。

2.3 流程控制的底线

控制流尽量掌握在确定性系统中，模型只负责需要语义理解和动态决策的节点。所有循环都必须设置次数、时间、Token、费用和工具调用上限。

重点监控端到端成功率、无效步骤率、重规划次数、关键路径 p95、单任务调用数和预算耗尽率。

三、问题二：如何安全连接外部世界

LLM 不能仅凭文本获知实时状态，也不能真正完成业务动作。外部连接要区分“获取证据”“执行动作”和“跨主体协作”。

3.1 五类能力不要混用

3.2 证据与动作必须受控

1）RAG 解决“依据什么回答” 可靠链路是：权限过滤 → 检索 → 重排 → 证据筛选 → 基于证据生成 → 引用校验。没有足够证据时应拒答；引用不支持结论，只是给幻觉附上链接。 2）Tool Use 解决“如何执行动作” 模型只能提出结构化调用意图，执行权属于运行时：

模型提出调用
↓
Schema 与参数白名单
↓
身份、权限和业务策略
↓
风险门或人工审批
↓
执行工具
↓
读取真实状态验证
↓
记录回执、审计和检查点

必须区分：模型建议、运行时接受、工具技术成功、业务最终生效。HTTP 200 不代表资金已经到账，模型说“退款成功”更不代表退款发生过。 3）MCP 解决接入，A2A 解决独立主体协作 MCP 像通用插座，不会自动提供权限、幂等、事务、真实性和审计。A2A 只适合拥有独立身份、权限、部署和责任的 Agent；同一应用中的不同 Prompt，通常只是函数、工具或工作流节点。

3.3 外部连接的底线

网页、文档、用户文件、工具结果、MCP Server 和其他 Agent 消息都应视为不可信数据。有副作用的工具至少需要最小权限、参数白名单、幂等键、限流熔断、写前确认、写后验证、审计和补偿。

模型可以提出动作，但不能自行获得执行权。

四、问题三：如何管理概率性错误

传统程序会抛异常，Agent 还会“正常返回错误答案”。因此，可靠性不能只依赖 try/catch。

4.1 先分类，再恢复

对非幂等写操作盲目重试，可能把一次故障升级为重复扣款或重复下单。

4.2 Reflection 必须依赖外部标准

1）可靠闭环

生成候选 → 测试、事实或 Rubric 验证 → 定位缺陷 → 局部修改 → 重新验证 → 达标或预算耗尽

算术、Schema、权限、SQL 和业务规则交给程序校验。Generator 与 Critic 若只是同一模型在相同上下文中互相认同，增加的往往只有 Token。 2）推理技巧按需启用 ReAct 适合工具循环，PAL 适合把计算交给程序，Tree of Thoughts 适合高价值小规模搜索，Self-consistency 适合多候选投票。它们都在用成本和延迟换质量，必须通过消融实验验证。

4.3 恢复必须是有界状态机

发现异常 → 分类
├─ 瞬时错误：退避重试
├─ 能力不可用：降级或 Fallback
├─ 计划失效：局部重规划
├─ 部分副作用：补偿
├─ 安全错误：阻断
└─ 无法处理：HITL
→ 验证恢复结果 → 继续、降级或受控终止

可靠性来自错误分类、外部验证、检查点和有界恢复，而不是对模型智力的乐观预期。

五、问题四：如何管理状态

Context、State、Session、Memory 和 Learning Data 不是同一件事。

5.1 五层状态

5.2 任务状态必须显式、可恢复

一个最小任务状态应包含：

task_id、goal、constraints、plan_version、current_step
verified_facts + provenance、tool_receipts、approvals
budget_remaining、errors、checkpoint_version、final_status

把所有内容塞进聊天历史，无法可靠支持版本、并发、审计和恢复。

5.3 记忆与学习是数据治理

1）长期记忆必须可追溯 记忆需要来源、置信度、用户确认、版本、可见范围、过期时间和删除机制。未经验证的结论、敏感属性推断和一次性细节不应自动沉淀。

RAG 访问外部权威知识，Memory 召回历史经验，State 保存当前执行事实，Context 是本次模型实际看到的内容；不要把四者混进同一个向量库。 2）生产学习优先走离线闭环

收集轨迹 → 脱敏筛选 → 标注 → 离线评估
→ 更新提示、路由、检索或模型 → 灰度发布 → 监控与回滚

未经筛选的在线反馈可能造成反馈投毒和错误放大。Memory 的目标不是让模型“记得更多”，而是让信息有来源、权限和生命周期。

六、问题五：如何约束自主性

自主性不是模型性格，而是一组明确授权。系统必须能说明 Agent 可以决定什么、访问什么、花费多少，以及何时必须停机或转人工。

6.1 先定义自治包络

自治包络包括：目标范围、数据权限、可用工具、允许的副作用、时间与费用预算、人工审核阈值，以及停止、降级和回滚条件。

6.2 四个确定性边界

1）Goal 必须可验证 “帮用户完成退款”过于模糊。工程化目标应同时包含成功指标、约束、预算、截止时间、非目标、停止条件和最终责任主体。

仅在订单满足政策、金额经程序计算、身份验证通过并获得用户确认后，提交一次带幂等键的退款请求；任何权限、金额或状态异常都转人工。

2）Guardrails 必须纵深部署

输入检测 → 身份与权限 → 租户隔离 → 工具策略网关
→ 执行沙箱 → 输出与事实校验 → 人工审批 → 审计与应急停机

System Prompt 中的“不要执行危险动作”不是安全边界。 3）HITL 必须提供可决策证据 人工节点应明确触发条件、审核人、证据包、批准/修改/拒绝选项、超时转派、恢复 Checkpoint 和审计记录。只展示“是否允许继续”，是在让人替黑箱背书。 4）资源预算也是权限 简单任务用小模型，复杂任务按质量门升级；稳定结果可缓存，独立 I/O 可受限并行。安全任务不能降级到不满足能力下限的模型，预算耗尽后必须停止或转人工。

6.3 自主性的底线

自主性越高，确定性约束越要前置。

七、问题六：如何证明系统值得上线

Demo 能跑通，不代表系统比更简单的方案更好。上线评估必须同时覆盖质量、成本、延迟、风险和业务收益。

7.1 从正确的基线开始

确定性程序 → Level 0 → Level 1 → Level 2 → Level 3

只把新 Agent 与“完全没有系统”比较，无法证明新增复杂度有价值。

7.2 六层评估

最终答案正确但执行过危险副作用，仍然失败；轨迹合理但没有解决业务问题，也没有价值。

7.3 用消融实验删除伪价值

逐一关闭 RAG、Reflection、Planner、Memory 或 Multi-Agent，比较质量、成本和延迟变化。无法在代表性任务集上证明贡献的模式，不应因为“更 Agentic”而保留。

7.4 Level 3 的准入门槛

1）这些情况应停在 Level 2 能力属于同一系统，权限和状态可集中管理，子任务可表达为工具或节点，多个角色只是不同 Prompt，且编排器能够掌握完整过程。 2）这些情况才考虑 Level 3 Agent 由不同组织或供应商拥有，数据与权限不能合并，独立部署和演进，任务异步且生命周期长，或必须支持运行时发现、协商、拒绝和跨框架互操作。

有多个角色不是 Multi-Agent；存在多个独立责任主体，才是 Multi-Agent。

7.5 上线最低门槛

核心评估集、失败长尾集和红队集通过；关键动作可审计；超时、限流、部分成功和补偿经过演练；成本与延迟满足 SLO；HITL 有 SLA；支持灰度与回滚；相对更简单基线存在可量化净收益。

八、贯穿案例：退款系统如何逐级演进

8.1 五个阶段

1）普通程序 订单查询、资格判断和金额计算都由规则完成。规则稳定、输入明确时，这就是最优方案。 2）Level 0：LLM 只负责语言 LLM 理解意图、抽取订单信息、解释规则结果；业务真相仍由程序负责。 3）Level 1：连接知识与动作 RAG 检索当前政策，Tool 查询订单和支付状态，程序计算金额，Tool 创建退款单。此时重点是证据、权限、幂等、写后验证和审计。 4）Level 2：处理动态异常路径

理解目标 → 查询事实 → 生成结构化计划 → 分步执行并保存检查点
→ 规则验证 → 局部恢复或重规划 → 高风险节点 HITL → 验证最终状态

跨供应商订单、部分退款和状态变化需要显式 State、预算、Reflection 和恢复策略；一个状态图通常已经足够。 5）Level 3：跨越真实组织边界 只有当支付 Agent、供应商 Agent 等由不同团队独立运营，并拥有独立认证、权限、部署和长任务状态时，A2A 才有实际价值。否则，把订单、政策和支付分别命名为三个 Agent，只是一次多余的分布式改造。

九、21 个模式的工程定位

9.1 模式不是功能清单

十、架构评审清单

10.1 六问即可筛掉大部分伪复杂度

十一、总结：Agent 工程的本质是约束复杂度

11.1 六个问题组成同一个控制闭环

六个问题不是六组可以自由堆叠的功能，而是一条从能力到责任的因果链：

目标与约束
↓
确定性编排决定流程
↓
LLM 处理语义理解、候选生成和动态决策
↓
RAG / Tool / MCP 获取事实并执行动作
↓
验证、Reflection 与 Recovery 处理偏差
↓
State / Checkpoint 支撑连续执行与故障恢复
↓
Guardrails / HITL 限制权限、预算和风险
↓
Evaluation 用质量、成本、延迟、安全和业务价值决定是否保留

缺少流程控制，系统会随机游走；缺少外部事实，答案会停留在语言幻觉；缺少验证与恢复，错误会沿链路放大；缺少显式状态，任务无法审计和续跑；缺少自治边界，模型建议可能直接变成危险动作；缺少评估，复杂度就只剩演示价值。

11.2 生产 Agent 的正确心智模型

生产 Agent 更准确的定义是：受确定性运行时约束的概率性控制器。模型负责处理语义不确定性，但执行权、事实源、状态转移和安全策略仍属于软件系统。

框架可以帮助实现链、图、工具和多 Agent 通信，但不会自动解决数据可信度、事务语义、权限治理、失败恢复和业务验收。这些仍然是架构本身的责任。

11.3 六条生产不变量

1）结构化契约优先于自然语言传递 步骤之间传递类型化状态，明确字段、来源、版本和验收条件。自然语言适合表达语义，不适合承担稳定 API 契约。 2）事实、动作和结论必须可追溯 每个关键结论都能回到证据，每次工具调用都保留参数与回执，每个副作用都能确认是否真正生效。 3）所有循环和副作用必须有边界 循环要有次数、时间、Token、费用和调用预算；写操作要有最小权限、幂等键、审批、补偿和审计。 4）状态必须支持恢复，而不只是“记住” 任务状态应记录计划版本、当前步骤、已验证事实、工具回执、审批、预算和 Checkpoint，确保超时或中断后可以安全续跑。 5）高风险决策必须绑定责任主体 权限、金额、安全和合规由确定性策略裁决；HITL 要提供证据、选项、SLA 和恢复点，而不是让人替一句黑箱结论背书。 6）每一层复杂度都必须证明净收益 以确定性程序和低 Level 方案为基线，通过离线集、红队集、消融实验和线上指标证明质量收益高于新增成本、延迟与风险。

11.4 六个工程问题的最终答案

11.5 复杂度升级的最终边界

确定性代码
↓ 只有语义理解不确定
Level 0：单次 LLM
↓ 只有外部事实或动作需求
Level 1：RAG / Tool / MCP
↓ 只有动态多步、状态和恢复需求
Level 2：单 Agent + 显式工作流
↓ 只有独立组织、权限、部署或生命周期边界
Level 3：Multi-Agent + A2A

Level 2 通常已经是企业 Agent 的合理终点。只有被委派方拥有独立身份和责任，能够拒绝、延期、要求补充信息并独立演进时，Multi-Agent 才不是角色扮演，而是真正的分布式协作。

经典软件工程并未因 Agent 出现而失效。模块化、类型契约、状态机、事务、容错、安全、测试和可观测性，反而因为模型具有概率性而变得更重要。

不要追求最 Agentic 的架构，要追求在真实约束下能够被证明有效的最低复杂度架构。