从一份失联结果看协作缺口
虚构的城市植物园准备更新导览页面：资料角色整理花期，编辑角色生成草稿，核对角色检查来源。一次试跑中，资料角色说“已完成”，编辑却拿到旧文件；核对者又把另一轮任务的意见合并进来。这里需要解决的是任务身份、通信和审核，而不是先换框架。本文保留原文的拆解编排、消息传递、结果审核三段，聚焦可复现的交接。 多 Agent 可以采用中心协调、子任务调用、状态路由或其他模式；开多个窗口、把另一个 Agent 当工具也可能构成有用方案，不能仅凭形式宣布它“不是真协作”。先用一个小任务验证分工是否带来收益。本文未启动实际团队、发送跨会话消息或发布导览内容，所有案例为合成流程。
第一段：任务卡先于派发
把最终目标写成验收清单：哪些植物、哪一版来源、输出语言、页面范围和必须保留的未知项。再拆成来源整理、草稿、审核与合并，标清依赖。不同资料分组可以并行，草稿必须使用确认版本，合并只接受通过审核的同一批产物。不要把大目标切成一堆彼此无法验收的小聊天。 每张任务卡包含批次、任务编号、输入版本、负责范围、允许工具、产物路径、完成条件和失败返回。资料角色不能通过修改页面“顺手解决”，编辑也不能自行补查未授权数据。协调者保留任务状态与负责人，一项任务只有一个明确的主产物拥有者，其他角色以意见或补丁交接。 上下文按需要提供，同时保留来源与限制。不能默认子 Agent 会记得主会话，也不能默认它必定无状态；具体继承和持久化方式取决于运行环境与配置。直接复制全部历史可能增加成本与冲突，过度压缩又会遗漏要求，应用任务卡与可读来源补足，而不是依靠人设名称。 派发前先做一个干跑：让执行者复述输入版本、目标和不允许行为，检查是否理解一致。这个检查可用产物字段自动验证，不必把每个普通动作重新交给用户确认。已有授权沿用，缺少权限或材料就返回明确状态，不能悄悄换来源或扩大访问。 本段产物是任务依赖图、任务卡、输入快照与状态表。先试两三个明确步骤，角色数量由任务决定，不把固定五个或六个持久会话当最佳实践。框架提供调度能力，具体任务契约仍需团队设计。
第二段：消息确认与业务完成分开
统一消息信封：发送者、接收者、批次、任务编号、输入版本、消息类型、产物位置与必要摘要。类型可包含分派、已接收、进度、结果、阻塞、修订与取消。已接收只说明消息被接到，不代表任务完成；结果消息也需核对产物实际存在、版本正确且内容符合要求。 为重复、延迟和乱序设计处理。资料角色若晚到一条旧版本结果，应标为过期而不是覆盖新文件；同一消息重发不能造成重复合并。设置可解释的消息标识与状态转换，约定谁能更新共享状态。若采用轮询，间隔与超时有预算；若采用事件推送，也要处理漏通知与重复事件。 传产物引用与短摘要通常比广播整段聊天更合适，但接收者必须有权限读取引用，摘要不能隐藏未确认项。共享工作区需要写入所有权与版本策略，单独上下文并不能防止文件覆盖。跨会话标签只帮助定位，不是账户权限或安全隔离。 超时后区分没接收、执行中、失败和结果未知。先查任务标识与产物，再决定重派；涉及写入、发布或发送的步骤尤其不能盲目重试。取消消息要说明停止哪个任务与后续处理，不能让已取消的结果后来被当作当前交付。恢复时保留消息和状态关联，避免只从最新聊天猜发生过什么。 原文中的 sessions_spawn、sessions_send 属于具体环境的工具名称，不是所有 Agent 或框架的统一接口。采用任何框架前，检查它实际支持的派发、查询、结果读取与取消方式，不把一个 Skill 的方法描述当成已经存在的通信通道。不同系统里的任务、会话与检查点也不应只按名词硬对应。 本段产物为消息协议、状态转换、过期与重复处理、超时与取消规则，以及用合成消息演练的记录。正常一次能收到结果只是起点，还要测试旧结果晚到、重复分派、接收者不可读文件和执行者失败，确认不会错误推进流程。
第三段：审核产物，而不是给角色投信任票
审核先对输入版本与任务范围，再看结构和证据。植物花期草稿中的每条事实应能回到指定资料；没有来源的内容标缺口，不用模型常识补造。确定性规则检查字段、编号与引用完整性，语义审核检查来源是否真的支持表述。不同检查分工明确，避免多个角色重复给模糊分数。 审核结论可用通过、需修订或拒绝，但每项都附问题位置、标准、证据与复测条件。拒绝不等于重写所有内容，修订应返回变更说明和新版本。设最大轮次与预算，到限后交付未解决问题和负责人决定，不让角色互相说服直到输出“通过”。 多人交叉审核有助于发现不同问题，但六个 Agent 并不自动意味着六份独立证据。若共享错误摘要、提示或来源，可能一起漏掉同一个事实。不要把多数票、置信度分数或自我评价当客观正确性。高影响判断、来源冲突和无法复现项应回到有责任的人或可靠材料。 技术交接规范的文字复核可使用 Writing Guidelines。公开详情、Vercel 固定来源与 MIT 许可已核验；提供脱敏协议草稿和读者，它适合整理术语、前提和失败步骤的表达。它不建立通信会话、不自动审核植物事实，也不提供多 Agent 调度；关联只用于文档整理。 合并前再次确认所有产物属于同一输入快照，引用可读，修订已通过，拒绝与未知项没有被丢掉。交付负责人的是最终草稿、来源表、审核与变更记录，不只是“团队已完成”的一句话。真正对外发布是独立动作，本例不自动执行。
一次端到端演练
准备三份公开或合成植物资料，其中一份缺少日期，另一份有旧版说明。按任务卡派发，故意让旧结果晚到，再重发一次相同结果。检查编辑是否只用当前资料，核对者是否指出缺失日期，汇总是否避免重复。最后取消一项未完成任务，确认其晚到结果不会进入最终稿。 可给 Agent 的说明是：“只设计或在授权测试环境验证植物园交接流程，包含任务身份、版本、消息确认、重复与取消；审核按证据给可定位结论。不要创建外部账户、扩大文件访问或发布。交付实际执行和未执行项分开。”用同一夹具比较单流程与拆分流程，再判断是否值得增加角色。
FAQ 与常见故障
框架应该先选哪一个？先看状态、工具、通信与运维需求，再用相同夹具试验，不能把某个框架简单等同于 DAG 或角色。多开窗口是否没用？人在调度也能有效，自动编排解决的是另一部分成本，不代表必然更优。接收到了但没结果怎么办？查任务状态和产物，不把消息确认当业务确认。 文件存在却内容错怎么办？核对输入快照、产物版本、写入所有权和审核记录。多位审查者意见冲突怎么办？列出各自证据与标准，不让票数直接决定事实。技能能跨所有客户端吗？格式、工具和支持特性要分别验证；许可、模型与服务费用也不统一。 本次没有取得可核验的编排或通信 SkillPI 候选，因此不编造这类关联。未来目录增加时，再按实际派发、通信或审查步骤核对公开详情、固定来源、许可和依赖。写作关联不应被理解为整套协作系统。
来源与维护
保留原文中英文的任务拆解、Agent 通信、结果审核及 FAQ，使用原创植物园与乱序消息案例。参考 LangChain 多 Agent 与子任务模式文档、CrewAI 任务输出验证说明及写作包固定源码。移除热度、通用工具名称、绝对兼容和多评审必定可靠保证。归档的两个 _new 条目构成同主题语言配对，公开地址采用独立的有效 slug，后续更新保持稳定。