很多团队在做多 Agent 协作时，会把“检索”与“交接”都当成同一种补上下文手段。结果往往是，一边不断把知识库片段塞进 prompt，一边继续把整段历史和中间摘要往下游转发，最后谁都说不清当前步骤到底该依赖什么。表面上看，系统像是补足了背景；实际上，它把可复用知识、当前责任边界和局部工作状态混成了一团。
更稳的做法，是先把检索增强和交接上下文明确分工。检索层负责在需要时取回长期有效、可复用、可校验的知识；交接层负责把当前步骤的目标、已确认事实、约束条件、会话身份和回传契约压缩成最小工作包。两层一旦分清，系统就不必再靠“把更多内容一起带着走”来维持连续性，异步恢复、人工升级和多角色协作也会更容易收口。
为什么这个问题重要
不分层时，系统会同时背着知识负担和交接负担
MemGPT 提醒我们，长上下文系统需要把不同层次的信息分配到不同记忆面中，而不是都堆在一个窗口里。Generative Agents 也展示了，代理行为的连续性依赖于可检索的记忆结构，而不是每轮都重放全部经历。再加上 Reflexion 里“把经验转成下一轮可用反馈”的思路，我们可以看到一个共同结论：不是所有信息都应该直接进入当前 prompt，更不是所有信息都该被原样传给下一个角色。若检索层和交接层不分工，系统既会重复搬运旧知识，也会把本该短小的当前责任边界拖得越来越重。
- 下游同时读知识背景和交接历史，真正当前要做的事反而不够醒目。
- 同一份规则、FAQ 或业务说明会被重复复制进多次委派，成本和噪声一起上升。
- 人工接管时很难分辨什么是长期知识，什么是这一轮任务刚确认的新结论。
如果继续混用，最先暴露的是责任漂移
这类问题最早往往不是以“检索失败”出现，而是以下游角色开始过度解释、重复调查和误用旧材料的方式暴露出来。一个本该只处理当前步骤的执行者，会被长知识片段诱导去扩展目标；一个本该依赖新事实做判断的控制器，会反而照着旧摘要继续路由。结果是交接包越来越像“混合备忘录”，检索结果越来越像“隐式指令”，而团队却不知道到底是知识命中了错误内容，还是交接边界本来就没有写清楚。
适用场景
最适合这套分工的，是会反复取知识又反复转手的流程
如果任务既需要查制度、文档、案例或产品知识，又会在多个角色、多个步骤和多个等待点之间流转，就很适合把检索层与交接层拆开。典型场景包括客服升级、销售支持、内部知识问答接运营动作、研究助理链路、审核与风控流程，以及任何会经历“查资料后继续分发”的工作流。这些流程的共同点是：知识背景可能反复复用，但当前责任边界每一步都在变化。
- 同一任务需要多次访问知识库，但每一步只消费其中一小部分。
- 任务会跨角色或跨队列流转，且接手方不需要重读全部历史。
- 系统必须支持暂停、恢复、重试和人工升级。
不适用边界，是知识本身就是这一步的主要产出
如果当前流程本质上就是一次性研究、开放式探索或长文共创，完整材料本身就是工作对象的一部分，那么检索和交接未必需要被拆得很细。另一个不适用场景，是单轮、同步、无转手的简单工具调用。此时先把输入输出定义好，比搭两层复杂上下文更重要。分工真正有价值的地方，在于“知识可复用，但当前步骤责任必须被显式收缩”。
推荐系统结构
让检索层负责找资料，让交接层负责定义当前动作
更可靠的结构，是把系统分成至少三层。第一层是检索层，负责按任务需要拉取可复用知识、历史案例、外部文档和规则依据。第二层是会话与状态层，负责保存当前 run 的身份、最近确认事实、步骤状态和关键证据。第三层是交接层，负责把下一位执行者真正需要的目标、输入、限制、禁止动作和完成标准组织成最小上下文包。这样设计后，知识不会消失，但也不会被误当成当前责任说明书。
- 检索结果回答的是“有哪些材料可用”。
- 交接包回答的是“当前这一步必须做什么”。
- 回传契约回答的是“做完以后要交回什么，缺什么，下一步建议是什么”。
在 TaskPilots 里，检索与交接应该经由状态层汇合
映射到 TaskPilots，可以把检索层看成上下文补给，把消息流转层看成状态和会话边界，把上下文包与回传契约看成节点之间的明确责任接口。稳妥的做法不是把检索命中的所有片段直接塞进下游 handoff，而是先经过控制器或当前节点筛选，只把与本步骤有关的已确认事实写入交接包。站内像 交接包应该有多小：只传必要事实，不传整段历史、先压缩再委派：上下文越来越长时如何避免交接失真 和 可恢复交接需要显式会话身份 讨论的，正好对应这条原则：知识可以按需取，责任必须按步交。
风险与失效点
最常见的失效方式，是把检索结果直接当成交接内容
很多系统一旦接入 RAG，就会默认“检索到了，就可以直接发给下游”。这正是责任混淆的起点。检索命中的内容可能是背景材料、历史案例、旧规则甚至互相冲突的片段，它们最多说明“值得参考”，并不自动等于“本步骤已经确认的事实”。如果不经过筛选和标注就进入交接包，下游就会把知识片段误当成执行指令，最终出现过度行动、重复求证或沿用过期结论的问题。
- 把检索材料和当前事实混写，会污染当前步骤的判断边界。
- 检索层没有版本或时效标记时，旧政策可能被当成现行规则。
- 交接层没有回传契约时，下游即使发现资料冲突，也不知道该怎么反馈。
高风险决策仍然需要人工兜底和证据可追溯
一旦流程涉及对外承诺、权限变更、资金动作、合规判断或高风险分类，系统不能只依赖“检索到了某段规则”就自动执行。人工兜底的重点，是核对当前结论到底来自哪条检索证据，哪些是已确认事实，哪些只是待验证候选。也就是说，人工看到的应该是一份压缩后的升级包，里面既有当前责任边界，也有检索来源和不确定项，而不是一大堆原始片段。
验证指标
上线前先验证“知识命中”与“交接完成”是不是两回事
比较有效的验证方法，是把同一批样本拆成两组评估。第一组看检索层是否能稳定命中正确资料，第二组看交接层是否能让下游在不重读长历史的情况下完成当前步骤。如果检索命中率很高，但交接成功率仍然低，通常说明问题不在知识缺失，而在责任边界没有被压缩清楚。反过来，如果交接包很清晰，但仍频繁返工，就可能是检索层没有提供足够可靠的材料。
- 分别统计检索命中质量和交接成功率，不把两者混成一个总指标。
- 抽样检查交接包里的每条事实，能否回溯到明确来源或当前状态。
- 做恢复测试，确认跨队列续跑时不需要重新拼接检索历史。
上线后长期盯四类信号
生产环境里，建议至少持续看四类指标：检索命中后仍需补料的比例、交接返工率、平均恢复时间和人工升级清晰度。第一项帮助判断检索层是否真的补到了有用知识；第二项反映交接包是否准确交代了本步骤责任；第三项衡量状态层是否支持可恢复执行；第四项则能看出人工接手时，知识来源、当前事实和待决策问题是否已经被清晰分开。如果这几项没有改善，往往说明系统只是加了检索，却没有重新定义交接契约。
下一步 / FAQ
下一步先画一张“什么进入检索，什么进入交接”的边界表
最务实的第一步，是挑一条经常既要查资料又要转手的流程，把最近十到二十个案例拆开看。逐条标记哪些信息属于可复用知识，哪些属于当前步骤确认事实，哪些只该留在局部草稿里。然后把这些判断固化成字段规则：什么内容进入检索索引，什么内容进入状态层，什么内容才允许进入 handoff。先把边界表跑通，再谈更复杂的自动压缩和检索编排，会稳得多。
FAQ
检索结果能不能直接塞进 handoff？ 可以引用，但不应该无差别整包转发。进入 handoff 的应是和当前步骤直接相关、且已被确认或明确标注状态的内容。
交接包里还需要带来源吗？ 需要。尤其是关键事实、规则依据和高风险判断，最好能带上可追溯的来源线索，而不是只给结论。
这样做会不会让系统更复杂？ 初期会增加一些字段治理和状态设计成本，但通常能明显减少重复检索、错误转派和人工补课时间。
如果知识库质量本来就一般怎么办？ 更应该分层。这样你至少能明确地知道，是检索材料本身不够好，还是交接契约把责任写乱了，而不是把两个问题混在一起排查。