讨论多 Agent 流程时，一个容易跳过的问题是：为什么这个任务需要分工？如果一个明确的步骤就能完成工作，增加更多参与者也会增加交接和检查的负担。
从一张流程草图开始
以“整理一组资料，形成一份摘要草稿”为练习，可以先划分三个角色：资料整理、摘要起草、结果检查。这只是用于理解协作的设计示例，并不是某个产品已经具备的能力清单。
资料整理 → 带来源的材料清单 → 摘要起草 → 带引用的草稿 → 结果检查 → 人工阅读确认。
各角色之间传递的应该是能够被检查的结果。比起“资料已经处理好了”，一份包含标题、相关段落和来源位置的材料清单更容易接着使用。
给每一次交接写一份约定
- 输入：这个步骤接收哪些材料，是否允许缺失字段。
- 输出：下一步需要什么格式，哪些信息必须保留。
- 完成条件：满足什么条件才能继续，什么情况必须退回。
- 操作范围：只负责整理和建议，还是允许执行指定操作。
例如，摘要起草环节只使用材料清单中的内容；检查环节逐项核对草稿是否有依据。检查不通过时，指出具体缺少的来源或不一致的句子，再交回前一步修改。
为异常留出出口
资料缺失、步骤超时、输出格式不符，都应该有明确的下一步。可以选择补充输入、有限次数重试或交给人处理，而不是让角色之间反复转交同一个问题。
流程记录可以保留任务标识、步骤名称、输入摘要、输出位置和处理结果，方便回看哪里出现偏差。记录什么、由谁查看和保留多久，需要在实际使用前明确，并避免记录不必要的敏感信息。
先做小流程，再考虑扩展
先用少量示例走完整条流程，观察最常出现的问题在哪里。如果任务始终被退回，优先改进输入和交接约定；只有发现明确的职责边界，才考虑增加一个新角色。
多 Agent 协作的价值，需要通过实际任务验证。能解释每一步为什么存在、怎样完成、失败后怎么办，比流程图上有多少个节点更重要。