让每个Agent只干自己那摊事：父—子代理上下文隔离到底隔离了什么
先讲个我自己的真实经历。去年年初我在一个企业内部知识库问答项目里，第一次正经用上了父—子代理（Parent-Child Agents，也叫 Sub-Agents）这套架构。当时主代理负责理解用户意图、拆解任务，子代理负责查数据库、读文档、算指标，分工看着挺美。结果联调那天，我盯着日志差点没把咖啡喷出来——一个子代理的上下文里，居然带着主代理在另一个子任务里检索到的无关文档片段，还有一段上一轮对话的用户闲聊。更离谱的是，token 消耗比单代理方案还翻了一倍，回答质量却明显下降，子代理甚至开始“自作主张”回答起跟它任务无关的问题。
这个问题不在模型能力，也不在 Prompt 写得不够好，而是我当时压根没想明白一个最基础的问题：父—子代理为什么要做上下文隔离？
如果你也准备上多智能体架构，或者已经在用 LangGraph、AutoGen、Coze 这类工具搭过类似流程，但总觉得哪里不对，这篇内容基本就是照着我的踩坑经历写的。我会把“为什么隔离”这个事从原理到实操掰开讲清楚，包括哪些上下文必须传、哪些打死也不能传、隔离后怎么避免子代理变成“瞎子”，以及我自己验证过好几次的经验方案。
1. 不是所有“共享信息”都叫上下文，先搞清楚你面对的是什么
1.1 单代理时代的“上下文”和多代理时代根本不是一回事
早期做单代理应用，上下文这个概念其实很简单——就是把用户的几轮对话、系统 Prompt、检索到的参考资料拼在一起，一次性扔给模型。模型自己从头读到尾，然后生成回答。你不需要考虑“这个信息给谁看”“那个信息该不该让另一个环节知道”，因为从头到尾只有一个脑子在干活。
但父—子代理模式一上，情况就变了。主代理（父代理）负责拆解任务、做规划、调动资源；子代理（子代理）负责执行某个具体的子任务，比如查一个数据库、算一组指标、写一段代码。此时“上下文”不再是单一模型要读的那一坨文本，而是分布在多个执行单元之间的信息集合。
这里最要命的问题是：很多新手（包括当时的我）会想当然地认为，既然子代理是父代理“派出去”的，那它理应知道父代理掌握的一切信息——用户问的完整问题、之前所有轮次的对话、父代理的完整规划思路，全都塞给子代理不就完事了？反正模型上下文窗口那么大，多给点又不吃亏。
这个想法恰恰是子代理模式里最大的坑。
1.2 上下文隔离的本质：让“知道什么”和“做什么”精准匹配
上下文隔离要做的事情，从设计目标上看其实就一句话：每个子代理只拿到完成自己那个子任务所必需的最少信息，不碰与它无关的任何上下文。
这句话听着简单，但背后涉及到三层东西：
第一层是知识边界。子代理A负责查销售数据，它不需要知道子代理B正在读哪些技术文档，更不需要知道用户脑子里对项目背景的完整预设。给多了不仅没用，反而会稀释它对核心任务的注意力。
第二层是信任边界。子代理在某些架构里是可以执行工具的，给一个负责查天气的子代理塞进用户的支付账户信息，这本身就是一个安全隐患。虽然目前多数 Agent 框架不会让子代理乱调权限，但设计上的“最小权限”原则放在上下文上同样成立。
第三层是成本边界。上下文越长，token 消耗越大，模型的响应延迟也越高。一个子代理如果拿着几百条无关对话记录去执行一个本来只需几行数据就能搞定的任务，那是拿大炮打蚊子，还打得不准。
我用一个比较生活化的比喻：单代理模式就像一个人既当项目经理又当工程师又当测试员，他脑子里所有信息都可以随时取用。而父—子代理模式相当于你请了个项目经理（父代理），项目经理把活派给工程师A、工程师B、测试C。这时候你不可能要求工程师A同时背下项目经理跟客户聊天的所有内容、工程师B负责的模块的全部设计文档——他只需要拿到自己负责那个零件的图纸就够了。
1.3 不隔离的后果，远比你想的严重
有人可能觉得，“不隔离顶多就是浪费点 token，效果差一点，不至于出大问题”。我一开始也这么想。但实际跑下来，不隔离至少会带来以下四类恶果，每一类都足够让一个项目从“能用”变成“没法用”。
第一，任务目标漂移。子代理的 Prompt 里如果混入了大量与当前子任务无关的上下文，模型对“我到底要做什么”的权重感知会被稀释。我见过一个子代理，原本被分配的任务是“从客户表中提取近30天的复购用户名单”，因为上下文里带着主代理在另一个环节对用户情感的分析结论，结果它把任务理解成了“分析用户情感倾向”，返回的完全不是需要的数据。
第二，上下文污染导致的虚假关联。LLM 本质上是在做概率预测，你喂给它的材料里如果存在大量不相关的信息，它就有可能在回答时把这些信息“编织”成看似合理、实则错误的关联。比如子代理A拿到了一段子代理B检索到的、跟本任务完全无关的技术文章，它可能会在最终报告里引用这段内容，理由是“系统给我提供了这段信息，所以应该有关系”。
第三，token 失控与成本爆炸。一个父代理如果负责5个子代理，每个子代理都拷贝一份完整上下文，那总 token 消耗就是单代理方案的5倍起步。叠加对话轮次递归，稍微复杂点的任务就可能把上下文窗口撑爆。
第四，调试地狱。这是我个人最痛的一点。上下文不隔离时，你看到的每个子代理返回结果都是“脏”的——你根本分不清这个输出是基于它该有的信息，还是被无关信息“污染”后产生的幻觉。排查问题时，你没法快速定位是 Prompt 的问题、检索的问题，还是上下文混杂的问题。
> 提示：上下文隔离不是“要不要做”的问题，而是“怎么设计”的问题。凡是父—子代理架构，隔离都必须是基础选项，不是可选项。2. 隔离的边界在哪：哪些上下文必须传，哪些打死也不能传
2.1 必须传的：任务卡片、必要背景、明确约束
上下文隔离不是说“子代理什么都不知道，只给它一句话让它干活”。那叫甩锅，不叫隔离。合理的隔离方案，是在隔离噪音的同事，保证子代理有足够的信息完成工作。
我自己的经验是，三类信息属于“必须传”的范围：
第一，任务卡片（Task Card）。这是核心中的核心。一份好的任务卡片应该包含：任务的唯一标识符、任务目标（尽量用可量化的描述，比如“统计2024年Q3各区域销售额并输出对比表格”）、输入数据的来源说明、输出格式要求、截止条件或完成标准。
第二，必要的最小背景信息。比如子代理要执行的是“从文档中提取关键词”，那它需要知道文档主题是什么、关键词的提取维度是什么、最终谁会消费这份关键词列表。这个背景不需要展开成一大段对话记录，两到三句话足够。
第三，明确的输出边界和约束。子代理不仅要清楚做什么，还要清楚不做什么。比如“只返回JSON格式结果，不生成Markdown表格”“如果数据不足，直接返回错误码，不要编造数据”。这类约束越明确，子代理执行起来越不走样。
我用一个标准的任务卡片模板做示范，这个模板我已经在多个项目里跑过，效果比较稳定：
任务ID: TASK-001 任务名称: 查询指定客户的历史订单 任务目标: 根据客户名称，从订单数据库中查询该客户近12个月的全部订单记录， 按订单时间倒序排列，返回前50条。 输入数据: - 客户名称: "深圳华科电子有限公司" - 查询字段: ["订单号", "订单时间", "订单金额", "订单状态"] 输出格式: - JSON数组，每个元素包含上述四个字段 - 若客户不存在，返回 {"error": "CUSTOMER_NOT_FOUND"} 约束条件: - 只做查询和格式化，不做数据分析和归纳 - 不调用除订单数据库外的其他工具这段任务卡片被我作为系统 Prompt 的一部分，在每次调用子代理时直接放进去。它把“子代理该知道的”和“不该知道的”用结构化方式划清了边界。
2.2 绝对不能传的：完整的对话历史、父代理的中间思考、其他子代理的中间产物、原始全量数据
刚才说了该传什么，现在说不能传什么。这部分是“隔离”的真正重点，也是大多数项目翻车的地方。
第一，完整的用户对话历史不能传。我理解大家为啥想传——子代理需要知道用户完整的诉求嘛。但问题是，用户对话历史里含大量的冗余、情绪表达、迂回描述，这些东西在父代理做意图判断时有用，但对执行具体查询的子代理来说就是彻头彻尾的噪声。更危险的是，对话历史里可能包含用户隐私信息（比如电话号码、家庭住址），把这些数据传递给每个子代理，等于把你的数据边界撕开一个大口子。
第二，父代理的中间推理过程不能传。部分 Agent 框架允许把父代理的推理链条（比如“用户可能想要A，所以我先查B，再根据B的结果决定是否查C”）传给子代理。这个东西听着好像有利于子代理理解全局，但实操中副作用极大——子代理会拼命尝试“帮助”父代理完成整个推理链条，而不是专注于自己的子任务。
第三，其他子代理的中间产物不能传。这个我特别想强调，因为很多框架（比如某些早期的 AutoGen 示例）会把所有子代理的输出都塞回共享上下文，供其他子代理参考。听起来很美好，仿佛大家在协作，实际上这是上下文污染最严重的来源。子代理B看到子代理A的中间输出后，极有可能在自己的结果里去“呼应”A的内容，哪怕两者压根没关系。
第四，原始全量数据不能传。有些朋友做子代理时，习惯先把相关文档、数据库记录全部检索出来，拼成一个巨大的上下文，再让子代理去分析。这等于把“检索增强”的功能从父代理下沉到了子代理，但父代理在拆解任务时根本不知道哪些数据是子代理真正需要的。这个操作的结果是：子代理的上下文窗口塞满了无关数据，真正有用的信息反而被淹没了。
2.3 什么是“最小必要上下文”：三句话判断法
那到底怎么判断一条信息是该传还是不该传？我给自己定了一个“三句话判断法”，每次设计子代理上下文时都拿这个筛一遍：
- 第一问：这个信息能直接帮助子代理完成当前子任务吗？能，就传；不能，就不传。
- 第二问：缺少这个信息，子代理会做出错误判断吗？会，就传；不会，就不传。
- 第三问：这个信息包含了其他子任务才需要的细节吗？包含，就不传，哪怕它看起来“有用”。
这三句话看着简单，但真到设计场景里，你会发现人特别容易犯“信息囤积癖”——总觉得多给点总没错。实际上LLM和人类一样，给的信息越杂，犯错的概率越高。
我举一个真实例子。有一个项目需要子代理从技术文档中提取 API 参数说明，父代理的完整上下文里既有文档全文，又有用户之前的提问（“这个API的鉴权方式是什么”），还有另一条子代理的结论（“该API支持OAuth2.0”）。按照三句话判断法，子代理真正需要的是：文档全文的指定段落（必要信息）＋“只提取参数说明，不回答鉴权问题”（任务目标）。至于用户提问的历史、另一个子代理关于鉴权的结论，统统不该传。这样设计之后，子代理的输出结构化程度明显提升，还出现过一次“把别人结论当作事实写进自己结果里”的乌龙。
> 注意：上下文隔离的“最小必要”原则，不是让你抠门到只给一句话，而是让你在每一份传入子代理的信息前面都问一句：它对当前任务是否“直接且必要”。3. 实操方案：在框架里怎么做到上下文隔离
3.1 方案一：每次调用子代理时显式构建独立上下文（适用 LangGraph、自研框架）
最直接的隔离方式，就是在代码层面把“传给子代理的上下文”和“父代理当前持有的上下文”彻底分开。不要让子代理直接继承父代理的 messages 列表，而是把父代理的 messages 当作“分析材料”，从中抽取出子任务需要的片段，重新组装成一个干净的 context 传给子代理。
以 LangGraph 为例，我当时的做法是这样的：
from langgraph.graph import StateGraph, END class AgentState(TypedDict): messages: list # 全局对话状态，仅父代理持有 tasks: list # 任务拆解结果 sub_results: dict # 各子代理的结果汇总 def build_sub_agent_context(task: dict, global_state: AgentState) -> list: """从全局状态中提取子代理所需的最小上下文""" sub_messages = [ {"role": "system", "content": SUB_AGENT_PROMPT.format( task_name=task["name"], task_goal=task["goal"], input_data=task["input"], output_format=task["output_format"] )} ] # 注意：这里绝不把 global_state["messages"] 直接塞进去 return sub_messages def call_sub_agent(task: dict, global_state: AgentState, sub_graph) -> dict: context = build_sub_agent_context(task, global_state) result = sub_graph.invoke({"messages": context}) return result核心就一行代码的关注点：context是从任务卡片外加少量必要字段手工构建的，而不是global_state["messages"]的直接列表拼接。这一步做到了，隔离的基本盘就稳了。
有朋友问：那有些框架（比如 AutoGen），子代理天然会继承 group chat 的所有消息，怎么隔离？
答案是：能隔离的框架就直接在调用时做过滤，不能隔离的框架就换个思路——把子代理的“上下文”控制在他自己的会话窗口内，通过约束群聊消息的可见性来做。比如 AutoGen 的GroupChatManager可以通过select_speaker逻辑控制谁看到什么消息，你自己实现一个“只给某个 speaker 发送与其任务相关的最近一条消息”逻辑，而不是让所有人看到所有消息。
3.2 方案二：用“结果过滤通道”做出口隔离，别让脏数据回流
上面说的是入口隔离——子代理拿到的信息是干净的。但隔离还有一个对称的方向：出口隔离——子代理产出的结果，回到父代理那里时要经过一次“滤芯”。
为什么需要出口隔离？因为子代理的输出有可能包含它自己脑补的内容、格式不规范的字段、甚至调工具时返回的原始报错信息。如果这些脏东西直接回流到父代理的全局上下文里，父代理后续的任务拆解就可能被带偏。
我的做法是：子代理的原始输出不直接进入全局状态，而是经过一个“结果规范化”环节。这个环节可能是代码写的校验函数，也可以是一次轻量的LLM调用。
def normalize_sub_result(raw_output: str, task: dict) -> dict: # 1. 按任务卡片要求的格式解析 try: parsed = json.loads(raw_output) # 2. 校验关键字段是否存在 for required_field in task.get("required_fields", []): if required_field not in parsed: return {"status": "error", "message": f"缺少字段: {required_field}"} return {"status": "success", "data": parsed} except json.JSONDecodeError: # 3. 解析失败则返回错误，不让脏数据进入全局状态 return {"status": "error", "message": "子代理输出不是合法JSON"}这个“过滤通道”的价值在于：子代理的行为再怎么飘，最后汇报给父代理的一定是符合规范的结构化信息。父代理不需要“理解”子代理的原始输出，只需要拿到一个可用的、干净的数据包。这样父代理在做下一步决策时，它的上下文里只存在有意义的数据，而不存在子代理的推理垃圾。
3.3 方案三：任务上下文“白名单”和“黑名单”设计
除了上述代码层面的隔离，我还引入了两个配置表，专门管理上下文的进出——白名单和黑名单。这个方法适合框架已经做了基本隔离、但你还想更精细控制场景。
白名单，管的是“什么样的信息可以从父代理传给子代理”。常见白名单项包括：
- 用户当前请求中，与子任务直接相关的原始片段（如用户说“帮我看一下A区域的数据”，子代理需要“A区域”这个关键词）
- 父代理拆解任务时给该子任务的明确定义（任务目标、输入、约束）
- 全局配置中与该任务相关的参数（如时间范围、区域范围）
- 允许子代理调用的工具清单
黑名单，管的是“什么样的信息禁止传给子代理”。常见黑名单项包括：
- 其他任务的中间输出、临时结论
- 用户的个人敏感信息（姓名、手机号、地址、账号等）
- 父代理的全部推理过程（包括候选规划、被否决的方案等）
- 对话历史里与当前任务无关的部分（哪怕是同一轮对话里的其他问题）
我建议把这两张表放在项目配置里，不要写死在代码里。因为在开发阶段，你会发现黑名单和白名单都需要频繁调整——某个信息你一开始觉得该传，跑了几轮发现它就是造成幻觉的元凶，就得把它从白名单挪到黑名单。配置化管理能让这个调整成本降到最低。
4. 隔离之后，子代理“瞎了”怎么办：信息不足的补充机制
4.1 问题出现：隔离太狠，子代理开始瞎猜
说实话，上下文隔离这个事很容易走向另一个极端——我把上下文隔离做得太彻底，子代理几乎是在“睁眼瞎”的状态下执行任务。结果就是它开始瞎猜，或者直接说“信息不足，无法完成任务”。
我遇到过的一次典型场景：让子代理“从数据仓库中提取订单金额排名前10的客户”，结果我只给它任务目标和一个数据库连接工具，没有给它任何关于“排名指标口径是什么”“时间范围是什么”的说明。它想了半天，默认按“2024年全部订单金额”跑了，但用户实际上要的是“最近3个月”。父代理不知道这些细节，它以为子代理能根据“排名前10”这句话自动理解口径。结果就是：子代理返回了错误的数据，而且它自己并不知道错在哪。
这个问题的根子在于：最小必要上下文里“必要”这两个字，不是只来源于父代理的拆解，还来源于对子代理执行能力的客观评估。子代理需要多少背景信息才够用，不能想当然，要基于你对自己那套 Prompt 和模型能力的了解。
4.2 补充机制一：子代理主动“索要”上下文
解决“信息不足”的第一招是：允许子代理在执行过程中主动向父代理索要更多上下文。
这个机制在 OpenAI 的 function calling 框架里天然支持——子代理可以调用一个request_more_context(topic)工具，告诉父代理“我需要更多关于XX的信息”。父代理收到这个请求后，再决定是补充信息给它，还是调整任务描述。
def request_more_context(topic: str): """子代理专用工具：向父代理申请补充上下文""" # 记录申请记录，供主流程调度 pending_requests.append({ "agent": current_sub_agent_id, "topic": topic, "timestamp": datetime.now() }) return "已记录你的补充申请，父代理即将处理"这个设计的好处是，它给了子代理一个“自助服务”的通道，而不是让它要么瞎猜、要么摆烂。缺点是增加了流程的复杂度，父代理需要多一个处理补充申请的节点。我的建议是：对于任务依赖较重、信息维度较多的子代理场景（比如数据分析、报告生成），这个机制很值得加；对于简单任务（比如查一个字段、转一个格式），加了反而画蛇添足。
4.3 补充机制二：可查询的全局知识库接口
另一个思路是，不要直接给子代理塞上下文，而是给它一个“搜索全局上下文”的接口。子代理需要哪方面的背景信息，随时去查，查到了自己精炼成摘要，然后用摘要完成后续任务。
这个方案尤其在子代理数量多、任务复杂的架构里很实用。父代理不再为每个子代理手工组装上下文，而是维护一个全局的状态数据库，子代理通过接口按需检索。
全局状态库（仅父代理维护）: - user_intent: 用户意图的最简描述 - task_plan: 当前任务拆解清单 - shared_data: 各子任务公开的、允许被检索的数据片段 - exec_log: 各子代理的执行状态记录子代理想要看“task_plan”里关于自己那部分的内容，就可以调用：
def query_global_context(key: str, agent_id: str) -> str: """子代理按需查询全局上下文，只返回与key匹配的信息""" if key not in GLOBAL_STATE: return "NO_SUCH_KEY" # 精细控制：只返回与该代理相关的片段 if key == "task_plan": return GLOBAL_STATE["task_plan"][agent_id] if key == "user_intent": # 只允许查询与当前任务相关的意图摘要 return GLOBAL_STATE["user_intent"][agent_id] return GLOBAL_STATE[key]这个方案等于把“上下文传递”从“推模式”变成了“拉模式”。推模式的问题是容易给多，拉模式的问题是子代理可能不知道自己要查什么，所以实际项目中我更推荐的做法是：父代理在任务卡片里明确告诉子代理“你可以查询哪些全局键”，让子代理在需要时按图索骥。这样既不会给多，也不会给少，主动权还在子代理手里。
4.4 隔离的前提：父代理的任务拆解能力必须过关
说到这，我得提一个容易被忽视的前提：上下文隔离的效果上限，取决于父代理的任务拆解质量。
如果父代理把一个本来应该保留整体分析的任务，硬生生拆成了几个互不相干的子任务，然后要求子代理在隔离状态下各自完成，最后再把结果拼起来——这个结果大概率是拼接感非常强的，甚至会出现逻辑断层。好比你把一个完整的故事情节拆成三个人分别写开头、中间和结尾，还让他们互不沟通，出来的东西能连贯才怪。
所以，在设计父代理的任务拆解逻辑时，就要想清楚“哪些任务可以安全地拆出去并行，哪些任务必须保留在父代理内部，做整体规划”。我自己的经验原则是：
- 可以拆的：数据检索、格式转换、单点事实查询、分类/打标、可独立完成的计算。
- 不适合拆的：需要综合多源信息才能做判断的任务、需要跨任务进行权衡取舍的任务、涉及用户复杂意图消解的任务。
这句话反过来说就是：上下文隔离不是让你把一切任务都无脑拆给子代理去做。它只是说“确实需要拆出去的任务，彼此之间要做信息隔离”，而不是“所有任务都必须拆出去”。
5. 我看过的失败案例和排查技巧：从隔离到失控
5.1 案例一：共享内存导致子代理“串味”
这是我在另一个开源项目里看到的情况（原型阶段，还没上线）。他们用的是共享内存式上下文——所有子代理读同一个内存消息池，父代理通过关键字过滤来控制子代理能看到什么。理论上是隔离的，但实现时关键字过滤做得太粗，只按“子代理ID”过滤，结果好几个子代理共用同一个 ID 前缀，互相看到了对方的中间输出。
现象非常典型：负责“提取信息”的子代理，报告里出现了负责“生成摘要”的子代理早先输出的摘要片段。排查了很久才定位到，是共享内存池里的消息没有按“线程”彻底分隔，只是按关键字打标，而打标规则因为 ID 前缀重叠互相覆盖了。
这个教训的核心是：凡是用共享内存、共享消息列表的架构，隔离必须靠“物理分隔”，不能靠“逻辑过滤”。所谓物理分隔，就是每个子代理有自己独立的会话线程，有自己的消息数组，父代理写入时明确指定写入哪个线程，读取时也只从指定线程读。逻辑过滤（在一个公共列表里按关键字挑消息）看着省事，但一旦边缘情况处理不严，就会漏出脏数据。
5.2 案例二：子代理返回的“错误结论”污染父代理决策
这是我自己项目里遇到的最头疼的问题。早期我做隔离时，只关注了入口（子代理拿到干净上下文），忽略了出口（子代理返回结果要筛选），结果一个子代理在数据缺失的情况下，自作聪明地编了一个“默认结论”（比如“该区域无销售记录”），返回给父代理后，父代理信以为真，接着基于这个错误结论做了后续任务拆解。
排查起来极其隐蔽——子代理的原始输出里其实带着“注意：数据缺失，此为推断结论”之类的提示，但我的结果规范化函数没有检查这个提示，直接把它当成最终结果存进了全局状态。父代理读取的时候只看到字段值，没看到风险提示。
这件事之后，我在结果规范化函数里加了一条硬性规则：子代理输出如果包含“推断”“估计”“可能”“无法确认”这类不确定性词，必须显式标注confidence字段，并且父代理在使用这个结果时，必须把低置信度的结果当作“待确认”而不是“已确认”来处理。这个改动直接减少了后续决策的连锁错误。
def normalize_sub_result(raw_output: str, task: dict) -> dict: try: parsed = json.loads(raw_output) # 新增：检查置信度标记 if "confidence" not in parsed: # 做一次启发式检查：是否包含不确定性关键词 if any(kw in raw_output for kw in ["推断", "估计", "可能", "大概", "无法确认"]): parsed["confidence"] = "low" parsed["need_confirmation"] = True else: parsed["confidence"] = "high" return {"status": "success", "data": parsed} except: return {"status": "error", "message": "子代理输出格式错误"}5.3 案例三：小上下文导致子代理“拒绝工作”
如果隔离做到了某种极致——子代理的上下文里只有一句话：任务目标，其余什么都没有——它会开始出现一种“摆烂”行为，直接回复“信息不足，无法回答”。
这不算 bug，这是模型面对残缺上下文时的正常反应。但问题在于，有时候子代理的“信息不足”判断是错误的——它其实只需要一点点引导，就能自己检索到答案。我在项目里跑数据分析子代理时，它经常因为不知道“时间范围”而拒绝计算，哪怕我给它的任务卡片已经说明了“数据源中默认包含最近一年的数据”。
这个问题的解法，是在任务卡片里增加一个“假定条件”字段。把那些任务执行中可能需要、但没有显式提供的默认值写进去。比如：
假定条件: - 若无明确时间范围，默认使用最近12个月的数据 - 若无明确币种，默认使用人民币 - 若查询失败超过2次，直接返回错误码，不进行重试假定条件不是让子代理瞎猜，而是给它一个明确定义的兜底策略。这样它的行为就是“可预期”的，不会因为缺乏某个细节就彻底停摆。
5.4 排查技巧：上下文隔离问题的定位三板斧
如果你的项目跑出不靠谱的结果，想排查跟上下文隔离有没有关系，我总结了三板斧：
第一，打开调试开关，看真实传给子代理的上下文。别看日志里显示“已传5条消息”，要看实际内容。很多框架在调试模式会显示完整上下文，你就一条一条扫，看有没有混杂别的任务的内容、有没有被截断、有没有多传或少传字段。
第二，手动复现子代理的Prompt。直接把传出去的任务卡片拿过来，在不带任何额外上下文的情况下，让我手动输入到同一个模型里跑一次。如果手动跑的结果和子代理跑的结果差异巨大，那说明上下文在传递过程中发生了污染或截断。
第三，在子代理入口处做“上下文快照”对比。把传给子代理的上下文完整保存下来，在父代理的全局状态里也保存一份快照，跑完任务后对比二者差异。如果发现子代理上下文里出现了全局状态里没有的信息，说明隔离逻辑有漏洞；如果发现缺失了应有的信息，说明隔离逻辑过于激进。
排查的时候要有心理准备，这类问题往往不会给你一个“报错信息”，而是让你看到结果别扭但说不出哪别扭。这种情况下，三板斧能帮你把问题定位到具体的上下文内容上。
6. 隔离设计不是一锤子买卖，要随子代理演化持续调整
最后说一个经验：上下文隔离的策略，最好不要在项目开始时一次性定死，而是留出调整的余地。
原因很简单。子代理的行为特性、模型版本的能力分布、任务的复杂性，都会在开发过程中动态变化。你今天认为“这条信息必须隔离”，跑两周后可能会发现子代理因为缺失这个信息而频繁出错，需要把它从黑名单里拿出来。同样，你一开始觉得“这个信息传进去也无所谓”，也可能会因为token成本飙升，被迫把它挪进黑名单。
我在项目里维护了一个context_policy.json文件，专门记录每个子代理的上下文白名单、黑名单、假定条件和任务卡片模板。每次调整都是改这个文件，不动代码。这样既能快速试错，又不至于把逻辑混在代码里难维护。
{ "sub_agent_configs": [ { "agent_id": "data_query", "whitelist": ["task_goal", "input_data", "output_format", "time_range"], "blacklist": ["other_agent_results", "full_dialog_history", "user_privacy"], "default_assumptions": [ "时间范围默认最近12个月", "币种默认人民币" ], "task_card_template": "TASK_CARD_V2" } ] }这个配置文件的价值在于，它把“上下文隔离策略”从代码逻辑中解耦出来，变成了一个可观察、可修改、可版本化的独立产物。团队成员评审的时候可以直接看配置，不用翻代码；模型效果变差了，可以快速回溯是哪个上下文策略改变导致的。
我个人的体会是：上下文隔离这项工作，本质上是在跟“模型的信息利用瓶颈”做博弈。模型的上下文窗口是有限的、注意力是稀缺的、对无关信息的容忍度是低于大多数人的直觉的。父—子代理能不能真正发挥“多脑协同”的优势，不在于你把多少子代理堆起来，而在于你能不能把每一条信息精准地送到需要它的那个脑袋里，同时让其他脑袋保持安静。
下次如果你发现自己的子代理架构跑起来效果不佳，先别急着换模型、调Prompt，回头看看你的上下文隔离有没有做到位——这个问题解决好后，很多看似玄学的“智能下降”问题，其实都会迎刃而解。
