父代理与子代理上下文隔离：委托书模式与Token成本优化

1. 从一次压测事故说起父代理为什么会“精神分裂”我在做一个客服工单自动质检系统的时候第一次真切感受到父—子代理的上下文隔离有多重要。当时架构很简单一个父代理负责解析工单、生成处理计划然后动态调度三个子代理分别负责情绪识别、问题归类、回复建议生成。单测和少量样例跑得挺顺可一进入连续压测阶段就露馅了明明是同一个入口、同一个工单内容第二次跑出来的结果和第一次差得离谱子代理被派去执行“补全收货地址”的简单任务给出的回复里却带着上一个工单的情绪分析表。更离谱的是某个子代理在回答里引用了父代理思考过程中才出现的候选方案而这些方案本不该让它看到。我打开链路追踪日志逐段回看了上下文内容原因非常清晰所有子代理都继承了父代理的全量上下文。父代理每处理完一个工单历史工单细节、之前子代理的完整输出原文、工具调用的原始返回全都被拼进子代理的初始上下文里。子代理以为自己接到的任务是“处理当前这一单”实际眼前却铺着几千行与本单无关的痕迹。面对这些杂音它只能在海量文本里自己找特征于是一旦某句话和当前任务语义相似就被顺手当成了任务的一部分。这事给我上了一课父—子代理模式运行得好不好不光取决于大模型本身的能力更取决于任务单元之间上下文边界的设计。上下文隔离不是可选项而是子代理架构里必须提前想清楚的底座。1.1 事故现象重复执行、串答案、越权引用先把当时的现象列清楚大家可以对号入座。结果漂移同一个输入在同一套流程下跑两次子代理输出结构一致但关键结论完全不同且没有明显规律。任务串味A任务子代理的输出里出现B任务独有的实体词、结论、编号仿佛前一个子代理没退场还在后台“托梦”。越权引用子代理明确引用了父代理在阶段规划里提到的备选方案。备选方案本属于父代理的“中间想法”根本不该暴露给子代理。成本膨胀单轮任务的 token 消耗随着处理工单数量增加而快速增长几乎呈线性上翻而不是稳定在一个可控区间。这四条里最隐蔽的是第三条。输出偶尔错一次还能靠重试掩盖但成本膨胀和上下文串味会随着任务量增加不断累积迟早把你最后一道防线击穿。1.2 根因定位共享上下文把任务边框打穿了拆开看问题出在两层。第一层是父代理的“记忆惯性”。父代理为了维持对整体目标的把握会把历史对话、中间推理、工具调用记录长期保留在自己的上下文里。这些信息对父代理是有用的因为它需要全局视角。但如果把这一整包东西直接复制给子代理就完全没有区别对待了。第二层是子代理的“锚定效应”。大模型做生成任务时上下文里那些看似无关、实则高亮的内容会产生强烈的锚定效果。哪怕你已经在系统提示里写了“只关注本次任务”只要子代理的上下文里躺着另一个任务的表格和结论它就很难不被吸附过去。这不是模型能力不够而是信息噪声盖过了任务信号。越长的无关上下文对输出质量的稀释越严重。1.3 一句话拿走结论父—子代理的上下文隔离核心不是切断父子之间的通信而是让每个子代理只看到完成自身任务所需的最小信息集让父代理只接收子代理的结构化交付摘要。把这个结论记在心里后面的设计和代码思路就顺了。2. 先把要“隔离”的信息分类再谈怎么切很多人一听“上下文隔离”下意识以为就是父子之间完全不见面、不传数据。真按这个思路做子代理会变成瞎猜的孤岛父代理也拿不到可用的结果。实际操作下来更合理的做法是给信息分三档按档位决定注入、压缩还是切断。2.1 三档信息分类法全局常量、任务输入、无关噪音我习惯把父子之间流动的信息分成 A、B、C 三类信息类别典型内容对子代理的价值隔离处理A 类全局常量项目目标、技术栈、命名规范、安全红线、输出模板需要但应精简压缩成固定摘要每次统一注入B 类任务必要输入本轮任务指令、输入数据引用、参考样例、验收标准高度需要直接决定产出质量完整放入子代理初始上下文C 类无关噪音父代理历史对话、其他子代理完整日志、工具原始返回、探索失败的记录基本无用反而干扰坚决切断不进子代理上下文很多翻车系统的问题不是不知道 A 类和 B 类而是把 C 类当成“保险起见”一起传了下去。你可能会想就算带点历史信息模型总不至于分不清吧但真实场景会告诉你它真的可能分不清。尤其在上下文窗口紧张、模型需要做长程聚焦时多一段无关对话就多一分被带偏的概率。2.2 C 类信息为什么是“沉默杀手”C 类信息不会每次都造成明显错误但它会悄悄影响结果的质量和稳定性。比如前置子代理输出里有一处错误示范后一个子代理读到时很可能不自觉地模仿它的句式甚至结论再比如父代理探索方案时提到“A 方向不太行”子代理看到后可能对该方向产生负面偏见哪怕当前任务恰好需要它认真评估 A 方向。C 类信息对 token 经济的挤压也相当可观。上下文窗口是有限的塞进了大量历史留给真正任务信息的空间就少了。但 LLM 又不会告诉你“我刚才看了太多无关内容导致没记住你的指令”它只会给出一个看似合理、实则偏航的结果。所以你很难从单次输出判断是提示写得不好还是上下文被污染了。这也是为什么我会建议从设计上就让 C 类信息物理上无法进入子代理上下文而不是靠模型自觉忽略。2.3 隔离的“度”不是越少越好信息给得太多会污染给得太少也会翻车。一个常见的反向错误是为了隔离只丢一句话给子代理连必要输入、输出格式、工具权限都不描述。结果子代理反复猜测、频繁调用工具最后交付一个结构完全不符合预期的结果。隔离的“度”是只包含 A 类和 B 类信息并且把这些信息组织成一份可直接执行的任务简报。A 类帮助子代理理解通用规则B 类帮助它聚焦当前交付C 类全部留在父代理侧。这样既不会过度膨胀也不会让子代理变成无头苍蝇。3. 隔离的实际收益从一份 Token 账单说起有人觉得上下文隔离是“洁癖”是过度设计。我用一个真实项目里的计算来说明它省下的不是一点半点。3.1 Token 经济账同样场景隔离后省下四分之三假设一个父代理管理 5 个子代理每轮任务调度时父代理的完整上下文约 8k token。不隔离每个子代理都继承父代理完整的 8k token5 个子代理一轮调度产生的输入 token 就是 40k。如果每个子代理还要执行多轮工具调用比如内部再迭代 3 次每一轮都会把这 8k 作为基础重算累计膨胀会非常惊人。隔离每个子代理只拿到 1.6k 的任务简报 0.4k 的全局约束合计 2k。5 个子代理一轮调度产生的输入 token 就是 10k内部迭代 3 次后也只有 30k。同一个业务场景光输入成本就降到原来的四分之一左右。项目里的子代理数量越多、调度频率越高这个差距越夸张。我见过一个跑批系统隔离前后月度 token 成本从 8 万降到了 1.9 万这就是把每一分预算都花在了刀刃上。3.2 专注度红利上下文越干净子代理越不容易跑偏成本还是显性收益真正让我坚持隔离的是输出稳定性。对比着做了一组实验同一道任务一组子代理带全量父上下文另一组只带任务简报。带全量上下文的那组在 20 次运行里有 6 次出现了不同程度的任务串味只带任务简报的那组20 次运行没有一次引用了无关内容。你可以把子代理想象成一位临时来帮忙的顾问。你给他一份列清楚背景、目标和约束的一页纸任务说明他大概率能在半天内给你靠谱的结果。你要是把整个项目历年的会议纪要、聊天记录、失败复盘全甩给他他反而不知道该从哪里下手。模型再强也是“上下文驱动”的输入什么料就炒什么菜。3.3 调试效率隔离让问题可定位还有一个很容易被忽略的收益调试效率。子代理的上下文一旦保持“最小且确定”你在回看日志时很快就能判断是任务简报给得不清楚还是模型生成本身出了问题。反之如果子代理的上下文每次都混着父代理一大堆历史一个输出异常可能要翻很久才能定位是从哪一层被污染的。隔离带来的调试收益本质上是把“黑盒”变成“半透明盒”。你清楚地知道子代理看到了什么自然就更容易推断它为什么这么回答。4. 边界设计父代理必须给什么必须留什么隔离策略具体落到设计上核心问题是边界。我把它拆成两个问题父代理必须给子代理什么父代理必须自己留什么4.1 必给项任务简报的六个组成要素一份合格的任务简报Task Brief至少要有六项内容任务目标一句话说清子代理正在完成什么。比如“为订单模块产出完整的 RESTful API 设计”。输入引用明确输入数据的来源路径或摘要。不要让子代理自己满世界找数据。工具白名单子代理可以调用哪些工具、禁止调用哪些工具。比如允许“代码库检索”禁止“发送外部请求”。验收标准什么样的输出算完成。比如“必须包含 OpenAPI 规范文件和变更影响清单”。输出格式最好给结构化 schema 或模板避免子代理自由发挥。安全底线涉及敏感字段时必须脱敏、哪些接口绝对禁止调用。这六项共同构成了子代理的“委托书”。有了委托书子代理就不用回溯父代理的全局上下文去猜自己该干什么它只需要从委托书出发。4.2 必须留的父代理的历史与思考链父代理必须留在自己手里的至少包括三类内容历史对话全量父代理和用户的整个交互过程属于父代理的记忆子代理只需要知道当前这一步。父代理的思考链父代理在拆解任务时可能考虑过多条路径哪些可行、哪些不可行。这些是决策过程不是决策结果交给子代理只会造成锚定污染。其他子代理的原始输出前置子代理的完整输出不该直接传给下一个子代理。父代理应该先把前置结果消化成结构化摘要再决定是否以及如何把摘要传给后续子代理。很多系统在处理“子代理串联”时偷懒直接把上一个子代理的输出全文拼进下一个子代理的提示词。短期看是省了二次加工的成本长期看是在不断放大上下文里的 C 类信息量。等到污染累积到阈值整个流程就会到处冒烟。4.3 推荐模式委托书模式取代全量继承与其给子代理一个“继承接口”不如给子代理一个“委托书”。父代理在创建子代理时只负责组装一份干净的 TaskBrief子代理的所有上下文都从 TaskBrief 开始构建。子代理不读父代理的全局变量而是通过明确的字段接收信息。委托书模式最大的优势是它把信息传递变成显式行为。你看到代码里哪里拼了 Prompt、哪里塞了字段就能一眼判断哪些信息进了子代理上下文。不像“继承”这种隐式机制信息是怎么流的靠猜。5. 用最小子代理骨架把隔离落到实处理论说得再多不落地都是空谈。下面给一个简洁的 Python 示例展示如何在代码层面实现委托书模式。这个示例不绑定具体框架langchain、llamaindex 或者自研调度器都可以套用。5.1 定义 TaskBrief 数据契约from dataclasses import dataclass, field from typing import Any, List, Dict dataclass class TaskBrief: task_id: str # 子代理任务唯一标识 task_goal: str # 任务目标 required_inputs: Dict[str, Any] # 输入数据或引用 allowed_tools: List[str] # 允许调用工具白名单 forbidden_tools: List[str] # 禁止调用工具黑名单 output_schema: Dict[str, str] # 输出结构要求 constraints: List[str] field(default_factorylist) # 附加约束 global_context: str # 只放A类全局常量的精简摘要这里最关键的是global_context字段。它只允许存放压缩后的全局约束比如项目技术栈、命名规范这类 A 类信息。父代理的完整历史对话绝不放进这个字段里。5.2 上下文构建器统一组装子代理提示词def build_child_context(brief: TaskBrief) - str: # 只拼接A类和B类信息C类信息在入口处就被挡住 sections [ # 全局约定\n brief.global_context, # 本次任务\n brief.task_goal, # 输入数据\n str(brief.required_inputs), # 工具边界\n f允许{brief.allowed_tools}禁止{brief.forbidden_tools}, # 输出要求\n str(brief.output_schema), ] if brief.constraints: sections.append(# 注意事项\n \n.join(f- {c} for c in brief.constraints)) return \n\n.join(sections)上下文构建器是隔离策略的核心落点。所有要进入子代理上下文的文本都必须经过这一个入口组装。这样做的好处是隔离规则只维护一处不会分散到业务代码里。5.3 使用示例父代理调度子代理# 父代理内部不再把完整 history 传给子代理 api_brief TaskBrief( task_idapi_designer_01, task_goal根据用户权限模块的需求文档设计RESTful API并输出OpenAPI规范。, required_inputs{ module_requirement: docs/user_permission_module.md }, allowed_tools[read_file, search_codebase], forbidden_tools[execute_shell, send_email], output_schema{ openapi_file: openapi.yaml, breaking_changes: list }, constraints[ 所有接口遵循REST风格, 字段命名统一使用snake_case, 涉及手机号、邮箱等字段必须声明脱敏规则 ], global_context项目商城后台改造技术栈FastAPI PostgreSQL接口文档位置docs/, ) child_context build_child_context(api_brief)在 langchain 这类框架里组装之后也就是转成消息对象的事from langchain.schema import SystemMessage, HumanMessage messages [ SystemMessage(contentchild_context), HumanMessage(content请开始执行任务。如有信息不足先尝试使用白名单内工具补充再决定是否反馈。), ]框架怎么调用模型并不重要重要的是子代理看到的内容从头到尾都只有 A 类全局约束加上本次任务的 B 类信息。父代理那些思考过程、历史工单、其他子代理的日志根本不在 messages 里物理上就传不进去。5.4 隔离的关键不只在“下发”更在“回传”下发隔离做得再干净如果回传环节不做约束父代理的上下文很快会再次膨胀。子代理在任务过程中可能产生大量中间日志、工具返回、调试信息如果这些原样回传父代理在后续调度其他子代理时又要背负这几千甚至上万 token 的杂质。我的做法是给子代理定义一个统一的结果模型强制结构化回传dataclass class SubAgentResult: task_id: str status: str # succeeded / failed / needs_review key_outputs: Dict[str, Any] # 结构化交付物 summary: str # 最多三句话的摘要 reference_paths: List[str] # 大体积结果落盘后的引用路径 error: str 父代理拿到SubAgentResult后只把summary和key_outputs里的必要字段并入自己的上下文。原始日志、中间产物直接写到文件或对象存储只留下引用路径。这样一来父代理的上下文增长被控制在一个很慢的节奏里后续子代理也不会因为父代理这层堆积而遭殃。6. 生产环境踩坑与排查清单隔离设计上线后真正考验人的是各种“看起来正常但隐隐不对”的边界情况。我整理了几条高频问题大家可以直接对照排查。6.1 现象对照表这类问题大概率是隔离失守现象根因修复方向子代理输出里出现其他任务的专有名词子代理继承了全量上下文词汇污染改为委托书定向组装同一输入两次执行差异巨大上下文里残留随机搜索或历史记录检查上下文构建器是否只拼接 AB 类Token 账单异常膨胀每次下发都携带父代理全量历史加日志记录子代理实际输入长度对比增量子代理回传大量原始日志回传链路没有结构化约束统一走 SubAgentResult 模型父代理调度后续任务时被“带跑偏”前置子代理全量结果回传了父代理侧只保留摘要和引用6.2 我的几条调试手段加一张上下文快照日志每次创建子代理之前把将要进入子代理上下文的文本长度、关键词列表打一条日志。这样一旦出问题可以直接比对是哪次组装引入了不该有的内容。写隔离断言在开发环境做一次自动化断言解析子代理的初始上下文确保它不包含父代理历史中独有的某些关键词。相当于给隔离规则上了回归测试。盯输入 token 曲线接入模型调用日志后重点观察每轮调度的平均输入 token 是否稳定。如果随着任务数量增长而明显上扬说明某条链路又在偷偷堆历史了。6.3 容易被忽略工具返回同样需要隔离最后提醒一个深坑即使任务简报做得再干净子代理在运行过程中还会调用工具工具返回的数据会直接进入子代理上下文。如果工具定义不加以约束比如允许子代理调用一个“网页全文抓取”工具它可能会把大段无关页面内容拖进来导致子代理当场“迷路”。所以工具层也要做隔离设计。能返回摘要的就别返回原文能用结构化字段的就别拼一坨文本敏感信息能在工具出口过滤的绝对不要留给子代理自己判断。父—子代理上下文隔离其实是一整套链路工程从任务组装、工具返回、结果回传到状态记录每一环都要守住边界。这个内容后续还可以这样扩展如果你要面对的是多层代理嵌套可以考虑给每一层单独建一个上下文命名空间层与层之间只通过 TaskBrief 和 SubAgentResult 交换数据这样即便代理树很深每一层也能保持清醒。