多代理系统为什么要做上下文隔离？父子代理协同的正确姿势

1. 从一次“翻车”说起当子代理背负了整个家族的对话史我先讲个真实场景。上个月我在调一个多代理协作的POC让父代理去拆解一个“分析某开源项目代码质量”的任务父代理把任务拆给了三个子代理——一个看核心模块、一个看测试覆盖率、一个看依赖安全。起初我图省事让子代理直接继承父代理的完整上下文结果翻车翻得很彻底子代理A在处理核心模块时被上下文里“父代理和用户讨论测试覆盖率”的内容带偏开始大谈特谈测试策略子代理B甚至开始引用父代理和用户闲聊时提到的某段无关历史。这不是偶然事故。任何一个把LLM的上下文窗口当“通用水缸”的开发者迟早会撞上这堵墙。今天聊的“父—子代理为什么要上下文隔离”说白了就是一件事当父代理把任务分拆给子代理时子代理应该拿到多少“历史”答案往往不是“越多越好”而是“越精简越好”。这篇文章适合什么人看如果你在折腾Agent工作流、在做多代理系统、或者用Claude/OpenAI/国产模型搭过“任务分拆-并行执行-结果汇总”的管道你会在这篇里找到那层窗户纸。我会把“上下文隔离”背后的原理、实操中的具体动作、以及我踩过的坑一次性讲透。2. 上下文隔离的本质窗口不是U盘拷不走也装不下2.1 先给新手补个底LLM的“工作记忆”是什么关于“上下文窗口”这个概念很多人理解成“LLM能记住多长的历史”这个理解大致对但容易漏掉一个关键点上下文不仅是“历史”还包括了任务说明、角色设定、工具定义、中间推理结果、临时变量。它相当于LLM正在工作时的“桌面”——桌面上摊了哪些文件、哪些草稿纸、哪些便利贴决定了它能办成什么事。当一个父代理和子代理之间做上下文传递时很多人第一反应是“把父代理的对话历史打包扔给子代理”这就像把整个办公室的文件柜搬到了新员工的工位上。问题是新员工只需要那两张图纸你却把十年来所有合同、报销单、零食采购记录全塞给了他。结果就是Token被大量无关内容占据有效工作空间缩小模型注意力被无关信息稀释相关性判断能力下降父代理某轮对话里的错误信息或过期结论成了子代理的“权威参考”2.2 继承上下文 vs 隔离上下文一张表看清差别我自己在做多代理框架时通常会把“上下文策略”列成一张对比表凡是涉及架构评审我都直接往上甩场景继承全部上下文隔离上下文只传必要信息父代理解任务好但代价大好因为父代保留的是完整信息子代执行效率差Token浪费在无关处好专注局部任务子代输出稳定性差容易被带偏好提示词污染少多子代并行几乎不可用互相干扰可用互不传染失败重试成本高重试时全量重传低轻量化重试结果可信度低混入父代偏见高子代独立判断这张表提到的“提示词污染”我解释一下。假设父代理的任务是“分析项目风险”父代理在和用户对话时反复提到了“团队可能延期”这个话题。如果子代理继承了这段上下文它自己的任务明明是“检查数据库表结构”却可能因为上下文里“延期风险”的反复出现而把自己的输出也往时间风险上带。LLM没有“选择性失忆”它看到什么都会影响它。2.3 隔离不等于切断上下文隔离的实质是“责任边界”这里要特别说清楚“隔离”不是把子代理变成瞎子更不是让子代理不携带任何信息去执行任务。隔离的本质是把“任务上下文”和“环境上下文”区分开。任务上下文子代完成任务必须的信息比如目标、约束、输入数据、验收标准环境上下文父代理和用户之间发生过什么、其他子代理在做什么、系统的全局状态父—子代理之间应该传递的是精简后的任务上下文。环境上下文在父代理那儿留着由父代理统一消化和调度。这像一个项目经理他不会把客户的抱怨原话一字不差地转告给每位工程师但会把“客户对交付日期非常敏感”这个结论写进任务简报里。3. 五大理由为什么必须做上下文隔离3.1 Token预算的硬约束窗口就那么大别浪费我得先上一个最直白的理由——Token。现在主流模型的上下文窗口从8K到200K不等听起来200K很大但用起来分分钟爆掉。我实测过一段200K的上下文光Recalling和Recitation原文重复就会占掉30%真正能给推理用的空间远没有想象中那么大。在父子代理场景下如果你让N个子代理都继承父代理的全部上下文假设父代理上下文是80K Token三个子代理各调一次API光输入就是240K Token的消耗。现实中你往往不止调一次子代理要多次交互、自我反思、修正输出最终成本可能翻到1M Token以上。而做上下文隔离后每个子代理只拿自己那几K的局部上下文输出又只回传一个结构化摘要整体成本能降一个数量级。在API计价时代上下文隔离不是架构洁癖是成本控制。3.2 父代“桌面”太乱子代无法聚焦我做Agent开发时最大的一个体会是模型对上下文的“绝对位置记忆”很强但对“哪些是重点”的判断力取决于信息密度。抽象一点理解LLM的工作机制是预测下一个Token上下文越长它在决定复制哪些Token时就越容易“抓到哪个算哪个”。具体到一个代码仓库审查任务父代理读了整个README、读了源码目录、读了用户问的问题、甚至读了一段用户随手贴的日志。然后它把这段完整历史扔给子代理子代理的任务是“列出所有未处理的安全漏洞”。但它的上下文里最显眼的信息是README里的项目简介和用户日志里的某次报错这会让子代理在生成时分配过多注意力到错误方向。隔离上下文本质上是在帮LLM做“注意力规划”。你给子代理的上下文越集中模型越有可能沿着你期望的方向走。3.3 输出风格与格式的稳定性隔离是“格式保证”的前提我们做多代理最怕的是子代理输出的结果格式五花八门。如果子代理被父代理上下文里的对话风格“污染”了——比如父代理用口语化的方式和用户聊天子代理可能也照着用口语化的语气输出但你的下游步骤比如子代理输出要作为另一个子代理的输入需要的是严谨JSON这就会直接崩。上下文隔离把子代理的“输入来源”定得很干净只包含四类东西角色指令你是谁、你要完成什么任务任务输入你给我什么数据、我要分析什么输出格式你输出的结构长什么样、字段是什么少量示例Few-shot告诉模型“就像这样输出”这四类内容都跟“父代理的历史对话”无关自然就不会有风格污染。我团队里的SOP是父代理永远是“会做摘要的高管”子代理永远是“收到简报就干活的专员”。两边语言系统不同才能保证系统稳定。3.4 并行执行的需要隔离才能“互不传染”多代理系统最重要的一点是并行。要让三个子代理同时分析三份文档互不干扰关键前提就是它们的上下文空间是隔开的。如果共享一份全局上下文子代理A在工作时写入了中间结果这个中间结果又出现在子代理B的上下文里那子代理B的分析就被“传染”了。很多工程师在第一次做多代理时都会遇到“幻觉传染”的问题子代理B说“根据前面的分析结果我判定风险等级为高”但实际上前面的分析结果是子代理A做出来的可能A的分析基于了一个错误假设。上下文隔离是并行计算的防火墙。3.5 可调试性和可解释性出了问题能定位最后这个理由可能比较“工程向”但非常现实上下文不隔离出了错你根本没法归因。比如最终汇总结果里有条明显的错误结论你不隔离的话得翻完父代理80K的历史对话才能排查是哪一步带歪的而上下文隔离后问题域被切成了一个个独立切片哪个子代理的输入输出有问题一目了然。我自己排查问题时最常做的事就是“回放子代理的局部上下文”——看它收到什么、输出了什么、哪里偏离了预期。这个动作在隔离架构下只需要几秒钟在继承了全量上下文的架构下可能需要反复调试半天的提示词。从运维角度看隔离带来的可观测性提升比它带来的性能提升更有价值。4. 怎么落地父-子代理上下文隔离的实操方法与模式4.1 最基本的设计简报式隔离这种模式最接近真实管理经验。父代理先把用户的请求理解成一个“任务简报”简报里包含任务目标一句话关键约束三个以内输入数据引用不是全量数据而是数据定位或摘要期望输出格式和字段然后父代理把这个简报发给子代理子代理只接收简报之后它跟父代理之间仅通过“结果摘要”交互。我在用这种模式时一般会在提示词里写下类似下面的结构这是你的任务简报。不要参考其他对话历史你也不需要知道任务的全貌只需完成简报中列出的局部目标。目标{任务目标} 约束{约束1}{约束2}{约束3} 输入{数据切片或引用} 输出{JSON格式要求}这种模式适用于子代理负责的是“清晰的单点任务”。优点是非常简单缺点是父代理如果拆解任务不够精准子代理拿到的简报信息不足容易做偏。4.2 扩展设计黑箱代理模式黑箱模式的思路是子代理是“黑箱”——父代理只关心子代理喂进来的输入和吐出来的输出完全不关心子代理内部的推理过程。这意味着子代理内部用什么样的提示词、做几次自我反思、用不用思维链都是子代理自己的事与父代理无关。这个模式在实践中的关键设计点是“输入输出的接口契约化”。我会为每个子代理定义一套严格的输入输出Schema比如一个“代码审查子代理”的Schema{ input: { code_snippet: string, language: string, review_focus: [security, performance] }, output: { findings: [ { severity: critical|warning|info, category: string, line_number: int|null, suggestion: string } ] } }在这个模式下父代理向子代理传的不是自然语言的历史对话而是结构化的JSON对象。上下文的隔离由“数据通道”实现不经过自然语言的自由传递。4.3 更进一步的冗余设计有损摘要隔离如果你的父代理上下文特别长而你又不希望子代理漏掉关键背景信息可以做一个“有损摘要”——父代理先用自己的能力把全量上下文压缩成一份摘要再把摘要传给子代理。这里的“有损”是有意为之就像给子代理一份“会议纪要”而不是会议录音。我常用的一种做法是让父代理执行两次总结第一遍提取与任务相关的全部事实排除无关对话第二遍把提取出的事实浓缩成“要点列表”限制点数为10-15条以内实践表明这个二次压缩能显著减轻子代理的Token压力也能让子代理更聚焦。要注意的是这个有损摘要动作本身会消耗一定调用量所以只适用于高价值的长任务场景不是每次都做。4.4 任务回传协议隔离之后如何“收账”上下文隔离不只是输入方向的隔离输出方向也要“收账”。子代理完成任务后回传给父代理的内容也需要打包降级。最常见的问题是子代理回传了“长篇大论的推理过程”但没有把“结论”单独摘出来。父代理要处理的是一个“结果”而不是一篇散文。我在实践中定义了“四段式回传协议”段位字段说明第一段conclusion直接结论不含推理第二段evidence支撑结论的关键证据清单第三段confidence置信度评分1-10第四段raw_output原始输出归档不作为下游输入父代理只把前三段作为后续处理的输入第四段留在日志里供排查。这个协议也倒逼子代理在输出时先做“思考压缩”而不是把推理过程当成交付物交差。4.5 状态管理隔离了上下文但别隔离了“记忆”很多人在实现上下文隔离后遇到另一个坑子代理在执行过程中需要“记住”自己做到哪一步了尤其是长任务型子代理比如一个子代理要执行5个子步骤。如果你对子代理之间做的是完全无状态隔离它每一步都是“失忆上岗”会导致低效甚至重复劳动。解决办法是给子代理内部做“任务内短程记忆”——子代理自己维护一个局部工作区这个工作区用于记录它在本任务内的中间结果。我在实现时通常是在子代理的提示词里加一个“工作日志”字段要求子代理每完成一个子步骤就把结果更新到工作日志中{ task_id: sub_agent_001, work_log: [ { step: parse_input, status: done, result: 5 focus points extracted }, { step: pattern_match, status: in_progress, partial_result: 3 risk candidates found } ] }这个工作日志是子代理的“私有记忆”和父代理无关也和兄弟子代理无关。做完这一步任务内上下文依然隔离但任务状态不再丢失。5. 一个完整实操案例用上下文隔离重写“市场调研”多代理流程5.1 案例背景为什么继承式流程必须改我拿一个典型的“市场调研”多代理任务来说。假设用户丢给父代理一个需求“对比三款主流项目管理工具输出一份选型建议。”懂行的朋友都知道这种任务特别适合分给多个子代理去调研一个查功能清单一个查价格模型一个查用户口碑。如果按“继承全量上下文”的做法流程是这样的父代理接收用户需求三个子代理各复制一份完整对话历史然后各自行动。结果会怎样你大概率会遇到子代理A查功能在输出时引用了父代理后来才提到的“用户偏好”信息——但这信息是父代理在和其他子代理聊天时才说的这个子代理本不该知道结果提前“剧透”了子代理C查口碑看到的上下文里包含了大量功能特性讨论它误以为用户主要关心功能而忽略了口碑调研本身5.2 改造后的隔离流程我最终落地的流程分为四个阶段。阶段一父代理需求分解与任务建构父代理第一次接收用户请求后不做任何调研先做任务分解。它把“对比三款工具”拆成三个子任务并为每个子任务做一份“简报”。这个阶段的关键是约束说明——指定三款工具的名称、指定输出格式统一。阶段二子代理并行执行与局部上下文工作三个子代理各领一份简报各自只持有简报、工具信息、以及自己的局部工作区。子代理之间没有任何上下文的交叉引用。如果子代理A需要知道“某工具是否支持某功能”它调工具去查但查的结果只写入自己的局部工作区。阶段三回传结构化结果子代理各自完成调研后按四段式回传协议输出。这里父代理看到的“三份结果”是三个结论证据置信度的结构化信息而不是三篇长文。阶段四父代理汇总与最终判断最后父代理基于三份“结构化结果”结合用户最初的需求这部分是父代理独有的上下文输出选型建议。在这个阶段父代理的信息优势是子代理不具备的——它见过用户完整的原始需求也知道其他子代理没有涉及的背景信息。5.3 这个案例中的关键收获做完这个案例后我对“上下文隔离”有了更具体的理解隔离的不只是信息隔离的更是“决策语境”。子代理在自己的决策语境里做出专业判断父代理在自己的决策语境里做全局统筹。一旦允许子代理“越界”访问父代上下文子代理的决策语境就被污染了。它会把“父代理的焦虑”当成“任务约束”。如果你发现某个子代理输出总不理想先检查它的输入简报是否“太肥”——简报里写了太多和本任务无关的约束这往往就是祸根。6. 常见问题与排障实录上下文隔离实战中的暗礁6.1 子代理上下文被“截断”导致重要信息丢失现象父代理生成的简报太长超过了子代理的局部Token限制子代理拿到的是被截断的版本导致它做出来的结论缺胳膊少腿。排查思路如果你看到子代理输出中频繁出现“根据我手头的信息”这种“打折扣”的表述十有八九是简报超长了。这时候你要做的不是加Token而是给简报“瘦身”——把“约束”“输入数据”压缩成更精准的字段。我自己的一句话是简报不是越多越好它应该像“驾驶舱仪表盘”只显示要用的表盘不放操作手册。6.2 子代理“偷看”了其他子代理的输出现象并行执行时子代理B的输出里出现了子代理A才应该知道的信息。这意味着你在设计并行管道时可能不小心让B的上下文里包含了我一个共享变量。解决方案如果是技术原因检查是否用了同一个“会话对象”去发多个子代理的请求如果是架构原因检查父代理是不是把子代理A的结果传给了子代理B作为“参考信息”。现在很多LangChain/LlamaIndex生态里的老坑就是这样——会话历史被全局共享一定要打开日志看每个子代理实际收到的上下文。好的隔离架构永远该有一个“日志回放”功能能够逐帧查看每个子代理的完整输入输出。6.3 父代理拿到子代理结果后“消化不良”现象子代理结果回传是正常的但父代理汇总时越汇总越乱几份结果之间出现自相矛盾。原因多个子代理各自的理想假设不一致。比如调研功能的子代理假设用户用的是2人小团队调研价格的子代理假设用户用的是50人企业。它们各自在自己的局部上下文里做了“隐性假设”但把这些假设带回来时父代理没发现冲突。对策在简报设计阶段就要给每个子代理写入“禁止自行假设”的约束同时让子代理在结果里显式声明“我基于哪些假设得出此结论”。这样父代理在做汇总时能够通过“假设对齐”消解矛盾。6.4 隔离之后子代理缺乏“常识”怎么办现象子代理隔离后经常问出“很傻”的问题——比如某个明显不需要调研的常识性问题它反复去查文档或者在输出里报出常识性错误。原因通用大模型在微调时接触了大量世界知识但如果你的子代理被隔离到一个专业领域内它可能不再从“通用常识池”里取答案而是从“局部上下文”里推断。对策在执行隔离时预留一个“常识参考区”。这部分上下文不来自父代理而是来自一个固定的“常识提示”比如“你是一个经验丰富的DevOps工程师”“你熟悉主流云平台差异”它不是任务上下文但能给子代理补足“背景知识”。7. 写在后面上下文隔离的真正意义是“降低协同复杂度”做过多代理系统的人都知道一句话——每一个代理的智力上限不是模型本身而是它手里握着那叠纸。上下文隔离的本质就是在降低协同复杂度。父代理不需要理解子代理的每一个内部推理子代理也不需要背负父代理的每一项历史包袱它们之间只需要在“有效信息”的接口上进行交换。我个人在实操中踩过的最大一个坑就是企图让子代理“懂得更多一点以便它们更智能一点”。结果适得其反。在这个系统里子代理越专业越好用父代理只需要做好拆解、分发、汇总这三级跳。如果你也在做多代理系统我的建议是下次你再做父代理和子代理之间传递上下文之前先问一句——“子代理需要知道多少才能完成它的局部任务” 然后把答案输入给它其余的都锁在保险柜里。这就像在真实团队里项目经理最多只会跟测试工程师说“需求文档里与当前版本相关的PRD是这几页”而不是把三个月以来所有邮件、周报、会议纪要全发过去。学会隔离你的代理团队才能真正“各司其职”。最后分享一个小技巧在每次“父-子”交互后我习惯加一条约束“如果你发现任何信息缺失请向父代理索取而不是自行脑补。”这一句话能有效减少子代理“自作主张”的概率。上下文隔离不是不提供信息而是让信息的通道刻意变窄从而倒逼子代理在必要时请求补充——这个请求动作本身就是你要捕获的“信息缺失信号”。