多 Agent 工作流里，最容易出问题的地方不是单个 Agent 不会做事，而是上下游交接太薄。上一个 Agent 只传一句“已处理，请继续”，下一个 Agent 不知道用了哪些资料、哪些结论被确认、哪些风险还没解决，只能重新猜一遍。
OpenClaw 做多 Agent 协作时，交接单应该成为标准结构。它可以和 运行日志、异常看板、回放测试 放在一起，保证每次交接都能复盘和验证。
交接单先写任务目标
下游 Agent 首先要知道，这个任务到底为了完成什么。是生成草稿、核对数据、发送提醒、写入系统，还是等待人工确认？目标不清，后续动作就容易越界。
任务目标旁边还要写当前状态：已完成、部分完成、待确认、失败重试中、已升级人工。状态越清楚，下游越不会重复执行或误以为任务已经闭环。
输入来源要能追溯
交接单里必须保留输入来源，包括用户原始请求、表单字段、外部系统记录、知识库片段和工具返回。不要只保留上游 Agent 总结后的文字，因为总结可能丢掉关键证据。
这和 权限复核 也有关。下游 Agent 如果不知道数据来自哪里，就很难判断自己是否有权继续处理这些信息。
未决问题要显眼
多 Agent 交接最怕把不确定项藏起来。比如客户身份未确认、合同版本有冲突、供应商交期待回复、数据样本不足，这些都要单独列为未决问题，而不是混在正文里。
未决问题应该有负责人和截止时间。需要人确认的，进入 人工接管队列；可以由系统重试的，进入异常或重试队列。
下游验收条件要写清
交接不是把内容传过去就结束。下游 Agent 要知道什么叫处理完成：是否需要生成报告，是否需要写入 CRM，是否需要发通知，是否需要把结果回填给上游。
如果下游发现证据不足或权限不足，也要有退回路径。退回时不能只说“无法处理”，而要写明缺什么字段、缺哪条证据、需要谁确认。
总结
OpenClaw 多 Agent 交接单的价值，是把上下游任务从一句话传递，变成有目标、来源、状态、未决问题、风险和验收条件的结构化交接。交接越清楚，多 Agent 协作越不容易断在中间。
