父—子代理上下文隔离：让每个Agent各司其职的关键设计

让每个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_nametask[name], task_goaltask[goal], input_datatask[input], output_formattask[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回头看看你的上下文隔离有没有做到位——这个问题解决好后很多看似玄学的“智能下降”问题其实都会迎刃而解。