佣金对账：修得好就修，修不好转人工
开源示例 · 官方 recipe
这是 open-multi-agent 官方 cookbook 示例，由元定义维护。三个来源隔离的调查 Agent 把证据交给仲裁者；证据不足时补查归档、替换被阻塞的分支，补完仍不足就在配置上限处停下转人工。无需 API key 即可跑通。
场景
典型场景：佣金对账的难点在证据：流水说按 5% 结的，代理协议摘要写着 7%，而摘要里既没有生效起止日期，也没有交易当天生效的费率表版本号。缺这两样，任何一个费率都是猜的。
示例的口径：证据不足是带类型的终局状态，系统在此停下并转人工——先说清缺什么，再定向补，补不到就把整包证据交给人。
方案
| 角色 | 任务 DAG | 工具 | 模型 | 部署形态 |
|---|---|---|---|---|
| transaction-analyst | Investigate transaction（根任务，与另两个并行） | 显式 tools: [] | synthetic-local，绑定确定性本地适配器 | npx tsx 脚本；模块无副作用，同一批函数被测试直接调用 |
| policy-analyst | Investigate policy summary；修复后追加 Retrieve policy version | 显式 tools: [] | 同上 | 同上 |
| agreement-analyst | Investigate agreement summary；修复后追加 Retrieve agreement history | 显式 tools: [] | 同上 | 同上 |
| arbiter | Reconcile initial evidence → Output initial reconciliation；修复后为 Reconcile recovered evidence → Output recovered reconciliation | 显式 tools: [] | 同上 | 同上 |
表中模型为示例仓库的默认配置；实际选型在方案阶段按场景确定。
四个 Agent 都挂了确定性适配器：它按提示内容计算返回值，替换掉的只是模型调用——调度、依赖注入、失败判定、计划修复全部走 OMA 真实代码路径。所有任务都设 maxRetries: 0、memoryScope: 'dependencies'、dependencyPayload: 'structured'，团队 sharedMemory: false：下游只拿得到直接前置任务经 Zod 校验过的结构化结果。
仲裁者挂了 afterRun 钩子：输出是合法 JSON、内容却是一份「证据不足」诊断时，把这次运行标记为失败并正常返回，诊断与用量都留给重规划器读。重规划器只对这一种带类型的失败反应，一次追加四个任务并作废尚未执行的旧输出任务；修复预算写死为 maxPlanRevisions: 1 / maxAddedTasks: 4（框架默认 3 / 20）。
结果
可运行产物与验证方式：
无需 API key 即可运行。源码头部写明「无需 API key、网络请求或 Bash」，官方 README 也把它列在「No API key needed」一节。两条命令：npx tsx packages/core/examples/cookbook/commission-reconciliation-recovery.ts --case recovered，以及把结尾换成 --case unresolved。
--case recovered 走通修复路径。本地实跑（2026-09-06）：初次对账失败、旧输出任务被作废；一次计划修订新增 4 个任务，补到协议生效区间与费率表版本后重新对账，输出 status: "RECONCILED"、selectedRule: "AGENT_AGREEMENT"、disposition: "UNDERPAID" 与 5 个来源 ID，退出码 0。金额均为脚本内联的合成记录。
--case unresolved 按设计转人工。本地实跑（2026-09-06）：归档查不到协议记录，替换后的对账仍缺「协议生效区间」。重规划器提出第五个任务，被框架真实的修订上限拒绝，任务图不再增长；结果在编排之外被映射成 MANUAL_REVIEW_REQUIRED，附缺失项、来源 ID 与下一步动作，退出码 1。
金额字段由 schema 守在失败态之外。证据不足的输出结构被 Zod 严格模式挡住了费率与金额字段，仓库里的测试逐条断言这一点；源码头部写明「不调整任何支付」，recovered 路径的结果 JSON 里也带一句同义的 note。
可核实
| 来源 | 链接 | 核实日期 |
|---|---|---|
| packages/core/examples/cookbook/commission-reconciliation-recovery.ts（commit 36e99fe） | https://github.com/open-multi-agent/open-multi-agent/blob/36e99fe/packages/core/examples/cookbook/commission-reconciliation-recovery.ts ↗ | |
| packages/core/tests/commission-reconciliation-recovery.test.ts（commit 36e99fe） | https://github.com/open-multi-agent/open-multi-agent/blob/36e99fe/packages/core/tests/commission-reconciliation-recovery.test.ts ↗ | |
| packages/core/examples/README.md「No API key needed」一节（commit 36e99fe） | https://github.com/open-multi-agent/open-multi-agent/blob/36e99fe/packages/core/examples/README.md ↗ | |
| packages/core/src/orchestrator/recovery.ts（修复上限默认值，commit 36e99fe） | https://github.com/open-multi-agent/open-multi-agent/blob/36e99fe/packages/core/src/orchestrator/recovery.ts ↗ | |
| 本地实跑两个场景，观察退出码 0 / 1 与输出 JSON（脚本同上，命令见「结果」） | https://github.com/open-multi-agent/open-multi-agent/blob/36e99fe/packages/core/examples/cookbook/commission-reconciliation-recovery.ts ↗ |
与元定义的关系
本页素材是 open-multi-agent 官方仓库里的 cookbook 示例，由元定义维护；记录、规则、金额全部为合成数据。
如果你有一条要跨多个系统取证的对账或核赔流程，需要「证据不足就明说、能补则补、补不到带着证据包转人工」这套口径，且每一次修复动作都要可审计，元定义对应的服务是 多智能体系统集成 →
相关服务
最后更新
想知道类似的流程在你这边怎么落地?