模式/组合工具/常见模式组合

双轴框架是一张模式地图。企业里的应用、数据、人、政策、等待状态和验收点构成任务地形。两个团队可以选择同一组模式，因为事实和责任放置的位置不同，最后仍会形成两套架构。

模式组合是一张有方向的任务图。节点是业务活动或模式，边上传递任务身份、业务状态、授权和完成证据。每条重要的边都要回答谁生产、谁消费、谁可以修改，以及失败后由谁停止、补偿或接管。

组合要保持四条线不断

组合评审还要分三层。先看任务与模式是否匹配：每个模式是否对应已经观察到的失败；再看模式之间能否连接：接缝处传递什么、由谁写、谁验收；最后看架构能否承受真实负载：同样的输入、故障和权限条件下，候选是否比最小基线更好。

先画完整任务

先定义一项能够独立判断、审批、执行、验收和补偿的业务变更。这个边界比“做一个薪酬 Agent”更具体，也比“调用一次写入 API”更完整。开始选模式前，应写清以下内容：

四类组合关系

组合契约

组合关系需要落到结构化定义。下面的示例省略业务字段，只保留架构评审所需的接口。

composition_id: payroll-allowance-change
goal: change one employee allowance for the next pay period

steps:
  - id: triage
    pattern: P1
    output: goal_contract
  - id: retrieve_policy
    pattern: M2
    input: goal_contract
    output: evidence_bundle
  - id: plan
    pattern: A2
    input: [goal_contract, evidence_bundle]
    output: plan_steps
  - id: execute
    pattern: A1
    input: approved_intent
    output: action_receipt

guards:
  - pattern: G1
    protects: execute
  - pattern: G2
    limits: [amount_delta, batch_size, employee_scope]
  - pattern: A4
    checks: [preconditions, tool_result, postconditions]

acceptance:
  probe: payroll_read_after_write
  evidence: [action_receipt, state_delta]

failure_policy:
  duplicate_request: return_existing_receipt
  policy_conflict: stop_and_escalate
  partial_write: compensate_then_checkpoint

每条边都应说明产物类型与所有者。若一个节点只输出自然语言，后续节点往往无法区分建议、决策、授权和执行结果。

薪酬变更怎样组合

1. P1 上下文分诊把用户表达解析为 Goal Contract，分离员工、字段、目标值、生效日期和 non-goals。
2. M2 检索增强读取政策版本和解释性证据；当前津贴值、员工状态和审批状态直接查询业务系统。
3. A2 规划执行建立读取、校验、准备、审批、提交和写后读取六类步骤，每一步带完成条件。
4. A1 工具调度只暴露当前步骤允许的工具。G1 把批准绑定到具体 Intent，G2 限制金额、批量和资源范围，A4 在调用前后检查状态。
5. 外部验收读取薪酬系统最终值并核对生效期。模型生成的完成说明不能替代这一结果。
6. X1、X2 与反馈模式把运行轨迹、状态差异和延迟结果连接到回归集、失败日记和后续修改。

保护机制不应重复拥有同一项裁决权

审批门决定某个具体 Intent 是否获准；爆炸半径控制规定系统即使判断错误，最多能影响多少对象与资源；护栏三明治检查工具调用前置条件、返回结构和执行后状态。这三者可以保护同一个动作，但职责不能互相替代。

当两个组件都能修改同一项决策，系统会出现责任不清：一个组件放行，另一个组件事后收回，日志却无法说明最终裁决来自哪里。组合设计应为准入、限界、执行、验收和补偿分别指定唯一责任主体。

另一个公开代码路径：DeerFlow Guardrail

DeerFlow Guardrail 案例展示了另一种组合方式。工具在装配时先经过筛选，进入运行时后再通过 Provider、策略决策和 hook 执行确定性检查。这个路径把“Agent 看见哪些工具”“某次调用能否执行”“执行点怎样留下证据”拆成不同责任。

它与薪酬示例的业务对象不同，但组合评审方法相同：沿工具从注册到暴露、选择、准入、执行和记录逐段检查，避免把全部控制塞进一个 prompt 或一个中间件。

执行型 Agent 参考架构

一项会修改外部系统的任务，通常经过目标、取证、计划、承诺和验收五段。P1 把自然语言请求收束成 Goal Contract；M2 或结构化查询分别提供政策证据和机械状态；A2 保存计划与步骤状态；A1 把当前 Intent 绑定到具体工具；G1、G2 和 A4 在提交前后处理授权、影响范围与状态检查；X1 将状态差异和外部回执接回同一条运行记录。

这条起步架构需要按任务删减或增加。一次只读问答通常不需要审批门；跨会话任务需要 M3；并行写入会增加 C5 子 Agent 隔离和写入冲突检查；结论需要独立审查时，再加入 F1 生成评审或 C3 对抗评审。每次增加都应能指回一项失败证据或业务约束。

八类应用怎样起步

ReAct、程序化工具调用与 CodeAct

三者都在运行时连接推理与行动，控制节奏和行动空间各不相同。

在 ADPS 中，ReAct、程序化工具调用和 CodeAct 属于执行机制概念，不单设模式编号。ReAct 通常使用 Loop；程序化工具调用位于 A1 工具调度与 A2 规划执行的交界；CodeAct 提供更宽的代码行动空间。临时程序经过验证、命名和版本化，并获准跨任务复用后，才进入 M5 程序性记忆。

常见组合问题

• 按名称购物：先挑流行模式，再寻找问题，结果是状态和控制重复。
• 模式堆叠：模式数量很多，节点之间仍然只传递长文本，没有明确产物。
• 循环无退出：反思、重试或多 Agent 辩论没有预算、终止条件和人工接管点。
• 控制权重叠：路由器、审批器、护栏和工具都能改写同一决策，无法归因。
• 验收停在 Agent 内部：评分器确认文本合理，却没有核对真实系统是否改变。
• 保护面可被一起改写：Agent 同时修改执行逻辑、护栏和评分器，回归结果失去独立性。

组合评审清单

1. 组合是否围绕一个明确的业务变更或任务边界？
2. 每个节点的输入、输出、状态所有者和完成条件是否明确？
3. 高风险动作由谁准入、谁限界、谁执行、谁验收？
4. 重试、循环、并行和委派是否有预算与终止条件？
5. 失败能否定位到具体节点、版本和状态交接？
6. 外部结果、人工纠正和延迟反馈是否进入下一轮验证？
7. 新增模式是否消除了一个明确缺口，还是只增加了结构？

组合与生命周期

组合描述一个版本在运行时怎样工作；生命周期管理这个组合怎样登记、验证、发布、复验和退出。组合中的 prompt、工具、Skill、策略或拓扑发生变化，都可能产生一个需要重新验证的新版本。完整阶段见Agent 设计生命周期。

相关资料

• ADPS 模式目录与选型框架
• 模式选型卡
• 六步选型法
• Agent 设计生命周期
• 人与 Agent 的协作边界
• 梁博执行型 Agent 案例
• DeerFlow Guardrail 代码与架构演进
• 行动模块总纲
• 治理模块总纲

修订源稿 · 查看发布源稿 · 协作规范