多 Agent 协作最容易出现的错觉，是把“信息带得越多越安全”当成交接原则。于是一个任务每流转一次，就多附一层聊天历史、更多中间猜测和更多已经过期的讨论。表面上看，下游像是拿到了更完整的背景；实际上，它拿到的往往是一份越来越难判断优先级、越来越难恢复执行、也越来越难交给人接管的上下文混合物。
更稳的做法不是继续堆历史，而是先压缩，再委派。压缩不是删掉关键信息，而是把会影响当前步骤成败的事实、约束、会话身份和回传要求提炼成最小上下文包，把其余历史留在可引用的状态层。这样设计后，系统才能在长链路里保持清楚边界，既让下游知道“现在该做什么”，也让控制器和人工升级节点知道“这一步做完后该怎么看结果”。
为什么这个问题重要
真正失控的不是模型能力，而是交接边界
当任务要经过控制器、专家角色、工具执行器和人工升级节点时，失败往往不是因为某个模型不会回答，而是因为每次转手都在转发不同版本的“背景”。Anthropic 在 prompt caching 文档里强调，稳定的大前缀更适合被复用，而频繁变化的部分应该尽量收敛。LangGraph 对 memory 和 persistence 的区分也说明，长期保存状态是一回事，把什么交给下一步执行又是另一回事。两层混在一起，交接就会越来越重，系统也会越来越难判断哪些内容仍然有效。
- 下游必须重读长历史才能找到当前目标，响应时间和 token 成本会同步上升。
- 同一任务在多次转派后出现多个“版本正确”的摘要，返工和争议会增加。
- 人工接管缺少压缩后的当前结论时，只能重新补课整段会话。
如果继续把历史当交接，最先坏掉的是恢复能力
长上下文链路里最常见的故障，不是某一步完全失败，而是恢复动作越来越像重新开始。异步队列重试时，系统不知道哪部分是已确认事实；控制器换模型或换角色时，下游不知道哪些结论已经过审；人工升级时，人也看不清“现在要判断的问题”究竟是什么。上下文越长，这种失真越难靠补更多文本来修复，因为问题已经从“信息够不够”变成“边界清不清”。
适用场景
这套方法适合多次转手、需要恢复的任务
如果一个任务只由单一执行者在短时间内完成，压缩交接未必是第一优先级。但只要任务会跨角色、跨步骤、跨队列或跨小时流转，这套方法就会迅速变得重要。典型场景包括支持工单升级、销售线索分发、内容审核、研究助理链路、运维排障和带人工审批的业务自动化。这些流程的共同点不是“特别复杂”，而是“任务会被多次接力”，所以每一次委派都必须是可恢复的最小单元。
- 同一任务至少经过两个以上角色，且角色关注点明显不同。
- 流程支持暂停、重试、回退、补料或人工接管。
- 系统需要在不重放全部历史的情况下继续执行下一步。
不适用边界是把会话本身当成产出
如果完整对话本来就是交付物的一部分，比如深度咨询、陪伴式共创或需要保留完整推演轨迹的工作坊，会话不应该被粗暴压缩。另一个不适用场景，是本来没有异步恢复、没有多角色委派、也没有人工升级的单轮工具流程。此时先把输入输出字段写清楚，往往比设计复杂的压缩包更有价值。压缩交接适合的是“会话只是执行过程，结果和状态才是可流转对象”的系统。
推荐系统结构
把会话状态、交接包、回传包拆成三层
可靠交接最重要的结构动作，是把“保存历史”和“传递下一步输入”彻底分开。第一层是会话状态，用来保存长期背景、最近一次确认结论、关键证据和恢复锚点。第二层是交接包，只包含下一位执行者完成当前步骤所必需的目标、事实、约束、禁止动作和完成标准。第三层是回传包，用统一字段告诉控制器：这一步完成了什么、缺了什么、风险在哪里、下一步应该怎么路由。这样历史仍被保留，但不会每次都原样进入新的 prompt。
- 会话状态负责“留档”，交接包负责“开工”，回传包负责“收口”。
- 交接包里只放当前步骤的必要事实，不把全部思考过程转交下游。
- 回传包必须区分已确认结论、待补资料、失败类型和建议下一步。
在 TaskPilots 里，压缩就是把契约显式化
映射到 TaskPilots，可以把上下文包理解为下一节点的最小工作说明，把消息流转理解为会话身份和状态迁移层，把回传契约理解为节点结束时必须交回的结构化结果。控制器真正需要看到的不是整段推理，而是四件事：目标是否完成、是否产生新事实、是否触发风险、推荐下一步是什么。站内像 交接包应该有多小：只传必要事实，不传整段历史、可恢复交接需要显式会话身份 和 全局记忆和局部记忆应该如何分层 讨论的，其实都是同一件事：不要让历史直接承担交接职责，而要把交接做成明确契约。
风险与失效点
最常见的失效方式，是压缩成了模糊摘要
很多团队意识到历史太长之后，会开始做摘要，但新的问题很快出现了: 摘要变成泛泛而谈的段落，既没有明确目标，也没有标出哪些是事实、哪些是不确定项，更没有回传格式。这样的“压缩”只是把冗长历史变成冗长摘要，依然不能稳定交接。另一个高频风险是把旧摘要持续叠加，导致每次压缩都继承了上一次未清理的噪声，最后只是在不同形式上重复膨胀。
- 把未验证猜测和已确认事实混写，会让下游误把讨论当结论。
- 没有时间边界或版本边界时，旧约束可能在恢复时被当成当前限制。
- 没有失败类型和升级条件时，控制器无法判断该重试、补料还是转人工。
高风险节点仍然需要人工兜底
压缩交接的目标是提升链路可控性，不是把所有动作都自动化到底。凡是涉及权限提升、客户承诺、对外发送、写库修改、资金决策或多方责任边界的节点，都应该保留人工审批或人工接管。区别在于，人工不该再被迫从头阅读整段历史，而应该接到一份压缩后的升级包，里面清楚写明当前目标、关键证据、未决风险和待判断问题。这样人工兜底才是接管决策，而不是替系统整理上下文。
验证指标
上线前先验证“压缩后还能不能稳定完成”
验证压缩交接是否有效，不能只看 prompt 变短了没有，而要看下游是否仍能稳定接住任务。比较实用的方法，是拿同一批真实样本分别跑“整段历史直传”和“压缩后委派”两个版本，对比完成率、返工率和平均恢复时间。如果压缩版在结果不下降的前提下明显缩短人工阅读时间和上下文长度，就说明最小交接包在收敛。还可以逐字段做删减实验，看看删掉哪个字段会显著降低完成率，从而识别真正必要的信息。
- 检查接手方是否只靠交接包就能理解当前步骤目标。
- 检查重试或恢复时是否还需要回放全部聊天历史。
- 检查人工升级时能否快速看懂“现在该判断什么”。
上线后长期盯四个信号
生产环境里，至少要持续追踪交接成功率、返工率、平均恢复时间和人工升级清晰度。交接成功率衡量下游是否能一次接住当前步骤；返工率反映压缩包是否仍缺关键事实；平均恢复时间能揭示暂停、重试、跨队列恢复是否真正变快；人工升级清晰度则可以通过审核评分、备注完整度或决策耗时来衡量。如果交接包越来越长，但这些指标没有改善，通常说明系统又退回到了“把历史往下发”的旧习惯。
下一步 / FAQ
下一步先做字段盘点，不要先做大改造
最实际的起点，不是马上重写整套编排系统，而是挑一条最常出问题的交接链路，回看最近二十个失败案例。逐条回答三个问题：接手方真正缺了什么事实，哪些历史只是噪声，升级给人时最想先看到什么。然后把答案固化成最小交接字段和回传字段，再让控制器只传这些字段。先把一条高频链路做通，再复制到更多流程，通常比一次性铺开更稳。
FAQ
压缩是不是等于做摘要？ 不是。摘要只是形式，压缩交接更强调字段边界、当前目标、必要事实和回传契约。
完整历史还要不要保存？ 要保存，但更适合留在会话状态或审计层里，需要时再引用，而不是每次委派都原样转发。
怎么判断一个字段该留在交接包还是状态层？ 删掉它做样本测试。如果下游仍能安全完成当前步骤，它通常不属于交接包核心字段。
这样会不会增加系统实现成本？ 初期会增加一点字段设计和日志治理工作，但通常能换来更低的 token 成本、更快的恢复速度和更清晰的人工升级链路。