在多 Agent 协作、异步分发和人工升级链路里，最常见的失控点并不是模型不够聪明，而是任务交接仍然停留在“写一段总结”。这类总结看起来像在压缩信息，实际上经常把目标、状态、证据和未决问题混在一起，导致接手方还要重新判断什么是真的、什么已经完成、什么需要继续做。
更可靠的做法，是把回传设计成结构化结果，而不是叙述性摘要。结构化回传要求每次委派都明确输入包、会话身份、必返字段、升级条件和证据引用，让下游角色、控制器或人工审核者都能基于同一份最小上下文继续工作。本文会结合 LangGraph 对 memory 与 persistence 的设计思路，以及 MemGPT 对分层记忆的启发，说明为什么 TaskPilots 更强调上下文包与回传契约，而不是继续堆聊天历史。
为什么这个问题重要
真实运行代价
一旦系统把“回传”默认成自然语言摘要，交接质量就会高度依赖写摘要的那个角色是否刚好表达完整。问题在于，生产环境里的交接并不是写周报，而是让另一个执行单元可以无歧义地继续推进。LangGraph 在 memory 与 persistence 的文档里都强调，长期有效的信息应进入可恢复的状态层，而不是只停留在会话文本里；这意味着回传如果没有固定字段，真正关键的状态就会被埋进描述性段落，后续节点既难检索，也难验证。
这类代价通常先体现在四个地方。第一，返工率上升，因为下游需要重新澄清目标和边界。第二，恢复时间拉长，因为异步任务被重新拉起时无法快速定位上次停在何处。第三，人工升级变得模糊，审核人看到的是一段“我已经做了这些”的叙述，而不是“已完成什么、缺什么、为什么卡住”。第四，系统指标会失真，看起来任务都有回复，但实际上可直接消费的结果比例并不高。
如果不处理会怎样
如果不把回传契约结构化，最容易先暴露的是上下文膨胀。团队为了弥补交接不清，往往继续把更多历史、更多引用、更多解释塞给下一个角色。结果不是更安全，而是让每次接手都先做一次“阅读和猜测”。再往后会出现契约失真：上游以为已经交代清楚，下游却理解成另一个问题；异步队列里只有一串文本，缺少 thread id、任务版本或状态标签，重试时也无法知道该从哪里续跑。
MemGPT 提供的启发很直接：并非所有上下文都应该长期驻留在活动窗口，系统必须区分活跃工作区、可检索记忆和持久状态。把所有内容都保留在连续叙述里，等于让系统没有边界地积累工作记忆。随着流程变长，这种设计会让“交接”退化成“把混乱转交给下一位”。
适用场景
谁最需要这套方法
最适合采用这套方法的，不是单次问答型工作流，而是任务会跨角色、跨步骤、跨时间片流转的系统。典型场景包括：控制器把任务分派给多个专长 Agent，再汇总结果生成结论；客服或运营流程先由自动化系统处理，再在风险节点升级给人工；长周期任务在夜间、队列重试或权限切换后，由另一个执行单元继续推进。只要接手方不是原来的上下文所有者，结构化回传就比自由摘要更有价值。
还有一类高匹配场景是“部分完成”的工作。比如调研 Agent 找到了候选资料，但还缺权威证据；或者执行 Agent 已经修改了三个系统中的两个，剩下一个因为权限不足需要升级。如果回传只是写成“目前大致完成，剩余部分需要人工跟进”，人工还是得重开上下文。若回传改成结构化字段，例如 completedItems、blockedItems、requiredDecision 和 evidenceLinks，交接就会清楚得多。
什么时候先不要这么做
如果流程非常短、只有一个执行者、没有异步恢复需求，也没有审计或升级要求，就不必过度设计回传契约。比如站内单页文案润色、一次性标题改写、单步检索问答，这些任务的上下文边界天然简单，结构化字段过多反而会增加操作负担。
另一个不适用边界是目标仍在探索期。如果团队连“什么算完成”都没有统一定义，过早要求严格回传模板，往往只会让字段被机械填写。这时应该先定义任务边界和结果类型，再谈结构化回传。换句话说，回传契约不是替代业务设计，而是把已经明确的业务边界变成机器与人都能消费的接口。
推荐系统结构
核心角色与状态
一套可落地的结构，至少要有四层。第一层是输入包，明确任务目标、已知事实、约束、可用工具和完成标准。第二层是会话状态，保存 thread id、任务 id、当前阶段、最近一次成功检查点和必要的持久事实。第三层是回传结构，要求执行单元返回统一字段，而不是自由发挥。第四层是升级路径，当任务因不确定性、权限或风险被卡住时，能把最小必要信息交给人工或更高权限的控制器。
具体到字段，回传至少应覆盖五类信息：status 表示任务是完成、部分完成、阻塞还是失败；outputs 表示可直接消费的结果对象；evidence 说明关键结论基于哪些来源、页面或操作记录；openQuestions 说明尚未解决的问题；nextAction 指定下一步应该由谁在什么条件下继续做。这样设计的重点，不是让 JSON 看起来整齐，而是让系统能够路由、重试、审计和升级。
与 TaskPilots 的映射
把这套方法映射到 TaskPilots，可以理解为三件事。第一，TaskPilots 的上下文包负责缩小问题，只携带下一步真正需要的任务定义、事实与边界，而不是整段对话。第二，消息流转层负责保存会话身份和状态变化，让任务在异步重试、人工接管或多角色接力时仍能找到同一个工作对象。第三，回传契约层要求每个节点输出可消费的结构化结果，让上游编排器知道该合并、继续分派，还是升级。
对系统设计者来说，一个很实用的做法是把“聊天内容”降级为辅助证据，把“契约字段”升级为正式接口。这样，编排器判断任务走向时依据的是结构化状态，而不是自然语言语气；人工接手时看到的是已确认事实、待决策项和证据链接，而不是一长串需要重新阅读的上下文。相关文章如 《如何设计不会丢失上下文的智能体交接》 讨论的是交接包本身，而本文进一步强调回传端同样要契约化。
风险与失效点
常见失控方式
第一类失效，是字段存在但语义不稳。比如 status 同时被不同节点解释成“模型认为差不多完成”或“业务上已经可交付”，最终控制器无法稳定路由。第二类失效，是把结构化字段做成表面工作，真正重要的判断仍写在备注里，导致系统只能继续解析长文本。第三类失效，是异步队列或重试机制没有绑定会话身份，回传虽然结构化，却挂错任务、错版本或错线程。
第四类失效，往往出现在人工升级。很多系统把升级写成一句“请人工处理”，却不说明为什么升级、已经做到哪里、建议决策是什么。这样人工并不是在接管一个清楚的问题，而是在接管一段失败历史。正确做法是让升级包也遵守契约，至少明确 escalationReason、decisionNeeded、attemptedActions 和 supportingEvidence。否则所谓的人工兜底，只是把问题重新打开一遍。
需要人工兜底的地方
涉及权限越权、资金风险、法律承诺、对外发布和不可逆操作时，必须保留人工审批，即使前面的执行结果已经结构化。结构化回传能帮助人工更快判断，但不能替代责任主体本身。对于这类节点，系统至少要保留审批人、审批时间、使用证据和最终决定的审计记录。
另外，当来源互相冲突、任务目标发生变更、或者执行单元对完成标准本身产生疑问时，也不应该让系统继续自动下钻。此时最有价值的不是追加更多摘要，而是停在一个清楚的升级包上，让人工快速判断“继续、修改边界，还是终止”。
验证指标
上线前怎么验证
上线前可以用三种方式做小规模验证。第一，挑选一批历史交接失败案例，把原先的自然语言回传改写成结构化契约，观察新的接手方能否在不阅读完整历史的前提下继续执行。第二，做字段完备性检查，确认每个任务类型都能稳定产出必须字段，而不是依赖个别提示词运气好。第三，做中断恢复演练，主动在队列中插入重试、换人接手或延迟恢复，看系统是否仍能根据会话身份和回传结构继续推进。
如果要更严格一些，可以要求审核者只看回传包，不看完整聊天，再判断他能否回答四个问题：任务现在处于什么状态、哪些结果已经可用、哪些问题仍未解决、下一步应该由谁处理。只要这四个问题还需要回头翻历史，说明回传契约仍不够清晰。
上线后怎么持续判断
上线后建议持续追踪至少四个指标。第一，交接成功率，也就是下游是否能直接基于回传继续执行而不再回问。第二，返工率，看多少任务因为回传信息不足或歧义被重新打开。第三，恢复时间，衡量异步任务从被重新拉起到恢复有效执行所需的时间。第四，人工升级清晰度，可以通过审核打分或升级后首次补问次数来观察升级包是否真的可用。
除此之外，还可以补两个操作性指标：字段缺失率与证据可追溯率。字段缺失率能帮助团队发现哪些契约字段只是写在文档里、没有真正落地；证据可追溯率则能衡量回传中的结论是否可以追到来源链接、工具输出或操作记录。对 TaskPilots 这类强调上下文包和消息流转的系统来说，这两个指标往往比“平均回复长度”更能说明交接质量。
下一步 / FAQ
下一步建议
如果你准备把这套方法落地，最实际的第一步不是重写所有提示词，而是先选一个最容易丢上下文的交接点，定义它的最小输入包和最小回传契约。通常只要先固定 5 到 8 个字段，并明确每个字段由谁填写、由谁消费，就已经能显著降低返工。第二步再补会话身份与检查点，让任务可以恢复。第三步才是把这些字段接入路由、监控和人工升级流程。
从组织推进角度看，也建议把“结构化回传”当成接口治理，而不是提示词优化。接口治理的好处是跨团队可协作、可审计、可演进；而仅靠某个角色写得更仔细，很难在规模化后保持一致。等这套契约跑稳之后，再扩展到更多任务类型，成本会低很多。
FAQ
结构化回传会不会增加系统成本？ 会增加一点设计与字段治理成本，但通常能换来更低的返工和更短的恢复时间，尤其适合长链路或高风险流程。
是不是所有结果都要 JSON 化？ 不一定。关键不是格式本身，而是是否有稳定字段、明确语义和可追溯证据。最终展示给人的内容可以是自然语言，但系统之间的交接层最好仍是结构化接口。
如果已有聊天记录和日志系统，还需要回传契约吗？ 需要。聊天记录适合追溯，回传契约适合继续执行。两者功能不同，不能互相替代。
怎么和现有人工流程集成？ 最简单的方式，是先让人工审批或接管页面直接消费同一份升级包，而不是额外再写一份摘要。这样人工和系统看到的是同一个任务状态。