很多团队一碰到交接失败，就直觉地把更多聊天历史、更多截图、更多中间推理一起塞给下一个角色，仿佛只要“带全上下文”，任务就不会丢。现实往往正相反。交接包越接近原始会话，接手方越难在有限窗口里识别真正重要的事实，控制器也越难判断该继续执行、回退重试，还是升级给人。
更稳的做法，是把交接当成一个有边界的契约，而不是会话转发。交出去的不是整段历史，而是当前目标、必要事实、约束条件、会话身份和预期回传结构。这样做既符合多 Agent handoff 的设计思路，也更容易复用会话状态、减少重复上下文和控制 token 成本。对 TaskPilots 这类要处理异步分发、人工升级和多角色协作的平台来说，交接包越小但越完整，系统越容易恢复、审计和迭代。
为什么这个问题重要
真实运行代价不在模型，而在链路
交接失败的代价，很少只表现为一次回答变差。它更常见的后果是链路变长、返工变多、人工接管时看不懂来龙去脉。OpenAI Agents SDK 的 handoff 设计强调，交给下一个 Agent 的应该是明确的任务边界和输入，而不是无差别复制整段对话。Sessions 文档也提醒我们，会话状态本身可以由系统持续保存，不需要每次委派都把历史重新塞回 prompt。把“状态持久化”和“交接输入”混成一件事，正是很多系统越跑越重的起点。
- 一次交接如果需要重读几十轮历史，延迟和成本会先上升。
- 接手方看不到清晰目标时，最容易重复调查已经确认过的事实。
- 人工升级缺少摘要和结论边界时，运营同事往往只能整段补课。
不处理时最先暴露的四种问题
第一种是上下文膨胀。每次交接都附带完整历史，会让后续每一步都继承上一步的冗余。第二种是契约失真。没有固定字段时，A 角色交出的内容和 B 角色期待的内容并不一致。第三种是异步队列丢状态。任务被重新消费或跨队列流转时，系统分不清哪些是已确认事实，哪些只是历史讨论。第四种是人工升级失焦。人真正需要的是“现在该判断什么”，而不是重新看一遍系统怎么犹豫过。Prompt caching 一类机制也从侧面说明，重复的大前缀是可以被复用和缓存的，但频繁变化的交接部分应该尽量短，才更适合高频生产流转。
适用场景
谁最需要把交接包做小
这套方法最适合任务会跨角色、跨步骤或跨队列流转的团队，比如支持运营、销售分诊、研究助理链路、内容审核、运维事件排查和任何带人工升级节点的自动化流程。它的共同特征不是“任务复杂”，而是“任务会被多次转手”。只要一个任务在生命周期里可能经历控制器、专家角色、工具执行器和人工复核，交接包就必须从第一天开始被设计成可恢复的最小单元。
- 同一任务至少会经过两个以上角色。
- 不同角色需要的上下文范围明显不同。
- 系统必须支持暂停、恢复、重试或转人工。
什么时候不要把它做成复杂契约
如果你的流程本来就是单一执行者、短时完成、没有异步恢复，也没有人工升级需求，那交接包不必被设计得很重。一个固定输入模板往往已经足够。另一个不适用边界是探索型长对话本身就是产出，例如高互动咨询或共同创作。此时完整会话就是工作对象的一部分，不能被简单压缩。真正需要最小交接包的，是“会话只是执行过程，任务结果才是交付物”的系统。
推荐系统结构
把会话、交接包和回传包拆成三层
比较稳的结构通常有三层。第一层是会话状态，用来保存长期上下文、已确认事实、历史动作和可恢复身份。第二层是交接包，只包含下一位执行者完成当前步骤所必需的信息。第三层是回传包，用统一字段告诉控制器这一步完成了什么、缺了什么、是否需要升级。这样设计时，历史不会消失，但也不会被每次原样转发。
- 交接包至少要有目标、输入事实、约束、禁止动作和完成标准。
- 会话状态要有稳定的 session identity，保证暂停后还能续跑。
- 回传包要区分已确认结论、待补信息、失败原因和建议下一步。
与 TaskPilots 的映射
放到 TaskPilots 里，可以把上下文包理解为发给下一节点的工作指令，把消息流转理解为状态与动作的编排层，把回传契约理解为节点结束时必须交回的结构化结果。控制器不需要知道每个节点完整经历了什么推理，但必须知道四件事：目标是否完成、是否产生新事实、是否触发风险、下一步建议是什么。只要这四件事是结构化返回的，系统就能在不复制整段对话的前提下继续流转。
一个简单的判断标准是：如果你删掉交接包里的某个字段，会不会让接手方无法安全完成当前步骤？不会，就说明那部分更适合留在会话状态里，而不是塞进交接包。
风险与失效点
最常见的失控不是太少，而是太杂
很多团队担心交接包过小会丢信息，于是不断往里追加背景。真正的失控通常不是信息不够，而是关键事实和噪声没有分层。接手方收到一大段混合了目标、猜测、已过期上下文和中间争论的材料，反而更容易忽略真正的边界条件。另一个常见问题是把“引用历史”误写成“复制历史”，结果每次交接都在扩散冗余。
- 把未验证猜测和已确认事实混写，会直接污染后续决策。
- 没有版本或时间边界时，旧结论会在重试中被当成新事实。
- 没有失败类型时，控制器无法区分该重试、补资料还是转人工。
必须保留人工兜底的地方
凡是涉及权限提升、对外发送、资金承诺、客户承诺、写库修改或高风险判断的节点，都不应该只靠最小交接包自动流转到底。人工兜底不是因为模型一定不行，而是因为这些动作需要额外责任边界和审计证据。比较稳的做法，是让自动链路先把任务压缩成一个清晰的人工升级包，再由人基于摘要、证据和待决策问题做最终判断，而不是临时打开完整会话从头阅读。
验证指标
上线前先验证“更小”有没有损伤可完成性
最直接的验证办法，是拿同一批真实样本分别跑“整段历史交接”和“最小交接包”两个版本，对比后续步骤的完成率、返工率和平均恢复时间。如果最小包版本在结果不下降的前提下明显降低 token、缩短人工阅读时间，就说明包体积确实在收敛到合适区间。还可以做字段删减实验，逐项移除字段，观察哪一项一删就明显影响任务完成，这能帮助团队识别真正的必要事实。
- 检查接手方是否能仅靠交接包完成当前步骤。
- 检查重试或恢复时是否必须重新回放完整历史。
- 检查人工接管时能否在短时间内看懂“现在该判断什么”。
上线后持续追踪四类信号
生产环境里，建议长期追踪交接成功率、返工率、恢复时间和人工升级清晰度。交接成功率看的是下游是否能一次接住任务；返工率看的是有多少任务因为缺关键事实被打回；恢复时间衡量暂停、重试、跨队列恢复是否高效；人工升级清晰度则可以通过工单标注或审核评分判断升级包是否足够让人快速决策。若交接包长度持续增加，而这些指标没有改善，通常就意味着系统又在偷懒地把历史当交接了。
下一步 / FAQ
下一步建议
如果你正在治理多 Agent 协作，不要先从“能不能压缩更多 token”开始，而是先盘点最近二十个交接失败案例，逐条回答三个问题：接手方真正缺的事实是什么、哪些历史只是噪声、升级给人时最想先看到什么。然后把答案固化成最小交接字段和回传字段，再让控制器只传这些字段。先把一个高频链路做通，再复制到别的流程，会比一次性重做整个平台安全得多。
FAQ
交接包越小越好吗？ 不是。目标不是最短，而是只保留完成当前步骤所需的必要事实、约束和回传要求。
那完整历史还要不要留？ 要留，但应放在会话状态或审计层里，需要时可引用，不必每次委派都原样转发。
怎么判断某个字段是不是必要？ 删掉它做一次样本验证。如果接手方仍能稳定完成任务，它大概率不属于交接包核心字段。
这会不会增加集成成本？ 初期会增加一点字段设计和日志治理工作，但通常能换来更低的 token 成本、更快的恢复速度和更清晰的人工升级链路。