退款是否成立，需要订单事实、质量证据和供应商条款。可以让一个 Agent 依次调查，也可以让三个 Agent 分工。后者看起来只是同时发出三个请求，实际上多出了一个问题：谁负责确认这些工作都已结束，并把结果变成一个可靠决定？
多 Agent 的难点不在给模型取不同角色名，而在管理多个独立执行过程之间的关系。
角色与执行实例不是一回事
“订单调查员”是职责定义，同一角色可以同时处理一百个订单。某次调查 A1042 的执行实例，才有自己的 task ID、输入版本、截止时间和结果。
共享角色 Prompt 不代表共享可变状态。若把所有调查结果写入同一个全局字典，租户和订单之间可能串数据。子任务应显式收到 tenant ID、order ID、允许读取的资料范围以及结果契约。
一个父任务可以记录三个 child task ID。子任务再有自己的 run 和 step。这样某个子任务重试时，不需要假装整个父任务从未执行过，也不会让另一位已经完成的调查员再查一遍。
什么时候顺序执行，什么时候并行
订单信息和政策检索互不依赖，可以并行。供应商协议查询需要先从订单找到供应商编号，就必须依赖前一步结果。
若三个独立任务分别耗时 2、4、6 秒，理想并行时间接近 6 秒，而不是 12 秒；实际还要加调度、合并和资源竞争。若并发调用挤满模型限额，尾延迟可能反而上升。
因此先画数据依赖，再决定拓扑。固定流水线适合依赖明确的步骤；主管分派适合运行时选择任务；交接适合将对话责任转给另一角色。交接时必须转移必要状态和责任，不能只在文本中写“现在由另一个 Agent 接手”。
子任务应该返回什么
订单调查返回“看起来可以退”，父任务仍然不知道证据是什么。更有用的结果包含事实、来源、读取版本和未解决问题。
{
"order_id": "A1042",
"order_revision": 13,
"facts": {"quality_verified": true},
"evidence_ids": ["inspection-92"],
"unresolved": []
}这只是教学契约。事实字段仍需来自受信工具与校验；JSON 合法不能证明事实正确。父任务还要确认订单身份一致、证据在权限范围内、版本未过期。
子任务不必都拥有退款权限。调查员只读资料，父级业务执行器在汇总和审批后才提交支付，可以显著缩小错误决策的影响范围。
谁拥有最后的写入权
两个 Agent 同时更新“最终退款金额”，不能依靠最后写入者获胜。更稳妥的是让子任务提交各自的提案，由指定合并步骤检查冲突，再形成单一业务命令。
独立证据可以按稳定 ID 合并；相同 ID 内容不同应报冲突。金额与审批状态则通常不能使用列表拼接式 Reducer。Reducer 定义的是状态合并规则，不是业务裁判。
如果政策 Agent 认为应退 299 元，订单 Agent 发现已部分退过 100 元，合并步骤应重新计算剩余金额并说明差异。再让模型多数投票，不能代替权威账本。
一个子任务失败后怎样办
父任务应区分必需与可选结果。质量证据是必需，失败后不能声称退款成立；补充的措辞建议是可选，失败可以降级。
常见策略包括全部成功才继续、达到足够证据即继续、某个必需任务失败立即停止。每一种都要定义迟到结果如何处理，以及其他子任务是否继续消耗资源。
失败传播不意味着把所有异常原样抛给用户。父任务保存具体错误与可恢复状态，再呈现“质量报告尚未获取，暂不能判断”。若重试只影响质量查询，就只创建该步骤的新 attempt。
超时和取消怎样向下传
父任务剩余 30 秒，不能给每个子任务各自 30 秒再无限重试。子任务截止时间应受到父级总截止时间约束，并为结果合并留出预算。
取消可以向所有未结束子任务传播，但每个子任务仍需报告自己的实际状态。有的尚未开始，有的已完成只读查询，有的远端请求结果未知。父任务不能在发送取消通知后立即断言所有副作用都停止。
Worker 崩溃还可能留下孤儿子任务。数据库保存 parent ID 和租约，协调器定期判断父任务是否仍有效，并按策略接管或停止。清理规则不能只依赖某个 Python 对象被垃圾回收。
单进程并发能说明什么
Python 的 TaskGroup 可以表达一组协程的生命周期，并在异常时协调取消；它没有自动提供进程重启后的恢复，也不能让远端服务撤销已执行请求。
将协程并发称为“分布式多 Agent Runtime”会跳过存储、消息和恢复问题。先用局部并发验证分工，再根据任务时长和部署边界决定是否需要持久子任务。
本系列将多 Agent 看作 Runtime 上的一种执行组织方式。模型负责提出动作和解释结果，运行时负责身份、预算、生命周期和可靠交付。下一篇讨论跨系统协作时，可以用什么协议交换这些任务。