技术 · 深入
多个 Agent 一起干活：先把"怎么说话"定死
多 Agent 的坑不在分工，在消息
多 Agent 比单 Agent 多出来的不是能力，是四类新复杂性：通信开销 · 状态一致性 · 错误传播 · 成本与延迟放大。这四类里，通信开销与错误传播都直接由"消息长什么样"决定。所以落地顺序应该反过来 —— 先定消息契约：每条消息带 trace_id · task_id · attempt · schema_version · 权限 · Deadline；长任务走可靠队列 + 持久化状态，不依赖易丢消息的 pub/sub；结果合并优先用确定性规则与业务状态校验，模型只负责解释。
方法 · 一图看懂
1
先算代价再分工 — 多 Agent 的四类新复杂性要能说出来 —— 说不出代价就说明还没到该拆的时候
2
定消息六字段 — trace_id（一次任务）· task_id（一个子任务）· attempt（第几次尝试）· schema_version（消息格式版本）· 权限 · Deadline
3
长任务走持久化队列 — 可靠队列 + 落库状态；pub/sub 丢了就丢了，长任务是丢不起的
4
合并交给确定性规则 — 价格、库存、优惠、权限这类结论以工具回执为准，模型只负责把它解释成人话
5
冲突保留证据与版本 — 不一致时不是"让模型投票"，而是保留双方证据与各自的数据版本，必要时转人工
6
按失败面写评测 — 正常之外还要覆盖：缺货、价格变化、工具超时、恶意输入、以及"多 Agent 重复执行同一动作"
attempt 与 schema_version 为什么必须有
attempt 解决的是一句"这条消息是重试还是新任务" —— 没有它，下游无法判断该幂等还是该执行，重复下单、重复发信就是这么来的。schema_version 解决的是"升级期两个版本同时在跑" —— 上游改了消息字段而下游还没更新时，消息必须能被识别并拒收，而不是被误解析成另一个含义。这两个字段名字很技术，但它们防的是最业务的事：重复执行与静默错解。
确定性优先：哪些结论不许模型说了算
一条划分线：凡是能从系统里查到真值的，就不许由模型宣布。价格、库存、优惠、权限、账户余额、订单状态 —— 这些都有唯一的权威源，模型最多负责把它们翻译成人话；反过来，需要解释、归类、措辞的环节才交给模型。这条线一旦划清，很多"多 Agent 互相矛盾"的问题会自然消失：因为它们不是观点分歧，而是本该由同一份数据裁决的事情，被交给了两个模型。
原理 · 为什么有效
这套做法有效的机理是把不确定性挡在边界上，而不是让它在系统里传播。多 Agent 系统里最贵的错误不是"某一步做错了"，而是"某一步做错了却没人知道" —— 错误沿着消息往下传，每一层都基于错的输入做出了看起来合理的决定。给消息加 trace_id / attempt / schema_version，等于给每一次传播留下可追溯的坐标；把结论交给确定性校验，等于在关键节点上装了一道不依赖模型的闸门。这两件事都不提高单步的智能，但它们决定了这套系统出错时是能定位，还是只能重启。
适用场景
适用：① 已经有单 Agent 跑通、准备拆第二三个角色的项目；② 涉及真实副作用（下单、发信、改权限）的流程 —— 这类流程不怕慢，怕重复；③ 任务时长以分钟 / 小时计的长任务。不适用：① 子任务彼此独立、一次就能问完的场景 —— 拆成多 Agent 只会白付通信与延迟；② 纯读不写的分析任务 —— 错误传播的代价小得多，先跑起来更重要；③ 探索阶段 —— 契约要在职责稳定之后定，职责天天变时先别固化格式。
自测 · 5 问
我说得出多 Agent 相对单 Agent 多出来的四类复杂性吗？
我的消息里有没有 trace_id 与 attempt —— 下游能不能分辨"重试"与"新任务"？
长任务是走持久化队列，还是压在易丢的 pub/sub 上？
价格 / 库存 / 权限这类结论，是模型宣布的，还是以工具回执为准？
我的评测集覆盖了工具超时与"重复执行同一动作"吗？
怎么上手 · 验证步骤
按三步落地：① 画一张两栏表 —— 左边写"哪些结论有唯一权威源"，右边写"哪些环节只是解释与措辞"；② 给左边那栏的每个结论指定校验方式（读哪个接口、比对哪个字段），并在合并处写成断言；③ 把消息字段按六项补齐，先只加 trace_id 与 attempt 两项跑一轮，看能不能凭日志复现一次失败。
做完回看两条：① 随便挑一次线上失败，能不能只用 trace_id 把整条链路串起来 —— 串不起来说明字段加了但没贯穿；② 故意让某个工具返回超时，确认系统是"重试一次后转人工"，而不是"两个 Agent 各自重试导致动作做了两遍"。两条都过，再往上加 Agent 数量。