专题/Agent 模式组合

双轴框架帮助团队定位模式：当前问题属于哪种认知功能，采用哪种执行拓扑。真实系统还要完成下一步，把多个模式连接成一条能运行、能失败、能恢复的路径。

模式组合是一张有方向的关系图。节点是模式或业务步骤，边是数据、状态、授权和证据的交接。它不增加第三条坐标轴，也不要求每个方案覆盖更多模式。组合质量取决于接口是否明确，以及失败时能否判断由谁停止、回滚或接管。

组合从一个任务边界开始

先定义一项能够独立判断、审批、执行、验收和补偿的业务变更。这个边界比“做一个薪酬 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 辩论没有预算、终止条件和人工接管点。
• 控制权重叠：路由器、审批器、护栏和工具都能改写同一决策，无法归因。
• 验收停在 Agent 内部：评分器确认文本合理，却没有核对真实系统是否改变。
• 保护面可被一起改写：Agent 同时修改执行逻辑、护栏和评分器，回归结果失去独立性。

组合评审清单

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

组合与生命周期

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

相关资料

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