Agent 小知识｜别让过程挤垮主 Agent：子 Agent 的隔离、回传与验收

摘要：

任务契约划清边界，子 Agent 处理局部过程，主 Agent 负责验收与整合

正文：

上一期「Agent 小知识｜存得下不等于想得起：Agent 跨会话记忆的工程设计与对账机制」讲完 Memory，我们留下了一个问题：当一次任务产生的过程信息已经太多，仅靠记忆和压缩还够不够？

一次复杂任务刚做到一半，当前上下文可能已经堆满检索结果、测试日志、失败尝试和局部判断。Agent 还记得目标，注意力却不断被过程信息拉走。反复把前面的内容压缩成摘要，可能会丢掉证据；把材料全部保留，又会让判断重点更难辨认。

举个例子，一个主 Agent 接到任务，要把一个大型代码仓库中使用的 API 从 v1 升级到 v2。它先读迁移文档，再搜索旧接口的调用位置，接着修改代码、运行测试、分析报错，还要检查示例和使用文档。

每一步单独看都很合理，可它们进入同一个上下文后，问题开始出现：刚确认过的兼容性约束被后面的日志冲淡，已经排除的原因又被调查了一遍，一处代码改动让某组测试通过，却破坏了另一个模块的旧客户端。这时，继续提醒 Agent「请关注重点」通常不够，任务的组织方式也需要调整——把边界清楚、过程庞大的局部工作从主链路中拆出来，交给独立的执行单元处理，再把经过整理、能够验收的结果带回全局任务。

在本文中，负责维护全局目标、拆分任务和完成最终验收的执行单元称为主 Agent；在限定边界内承接局部任务，并按约定返回结果的执行单元称为子 Agent。这里的“主”与“子”描述的是任务分工，具体使用什么模型、进程或工作空间，取决于系统实现。本期将围绕这套分工，讨论子 Agent 如何借助独立上下文承接局部过程，以及主 Agent 如何接收并验收结果。

一张图概览子 Agent 的任务闭环

图 1. 单 Agent 承载全部过程，与局部过程隔离后的信息负担对比

这张图概括了本期的主链路：主 Agent 划定子任务，局部过程进入独立上下文，子 Agent 按约定返回结果，主 Agent 再完成验收和整合。后文会沿着这条链路逐步展开。

复杂任务容易挤占单 Agent 的上下文

模型每次工作，都要在自己的上下文窗口里处理信息。窗口有明确的容量边界，但复杂任务往往在触碰硬上限前就会出现上下文拥堵。

迁移文档、代码片段、搜索结果、测试输出和失败记录都与任务有关，只是重要程度不同。当它们进入同一条执行轨迹，主 Agent 既要记住全局目标，又要处理每个局部问题留下的细节，各类信息便开始争夺模型的注意力。随着过程增长，影响决策的约束也更容易淹没在大量记录中。

摘要和压缩当然有用，第 2 期「Agent 小知识｜上下文预算：让 Agent 知道该看什么」已经讨论过怎样控制上下文预算。但压缩也有天然限制，一段测试调查被缩成「问题来自兼容性变化」后，相关日志、排除过程和例外情况可能一起消失。主 Agent 得到了一句更短的话，却未必得到一份可以验收的结果。因此，上下文还有剩余空间，只能说明容量尚未耗尽，无法证明其中的信息已经组织妥当。

把部分工作交给子 Agent 后，局部检索、测试和试错可以留在各自独立的上下文中，主 Agent 主要接收全局决策需要的信息。系统由此能够利用多个独立上下文分担过程信息，但基础模型单次调用的窗口大小和能力没有改变。这种分配方式仍然依赖清晰的任务边界。边界含糊时，盲目增加子 Agent 只会带回几份难以整合的结果，原有混乱也会被进一步放大。

清晰边界决定任务能否委派

回到仓库升级任务，主 Agent 可以先把工作摊开：查找旧 API 的调用位置，主要是只读搜索和影响面整理；核对 API v1 与 v2 的差异，依赖迁移资料和接口定义；归类失败测试，需要统一的测试基线；检查示例和文档，则主要关注过期用法。这 4 项工作的过程可能很长，但输入和交付物相对明确，也能分别核验，因此都可以进入任务委派的候选范围。

核心代码修改则需要更谨慎，因为多个执行者同时修改同一个适配层，容易产生文件冲突；步骤之间持续依赖同一份实时状态，也会削弱独立执行的条件。主 Agent 可以分派前期调查，把共享核心文件的取舍和整合留在主链路中。

判断一项工作能否交给子 Agent，可以检查 4 个条件：边界是否清楚，能否独立执行，能否独立验收，与其他任务共享的可变状态是否足够少。完成这轮判断后，还要比较两类成本，看局部过程隔离为主 Agent 节省的上下文空间和注意力，能否覆盖拆分、沟通与验收的投入。

所以，「隔离优于压缩」需要明确适用条件。当局部任务边界清楚、过程信息量大、结果能够独立验收时，可以优先隔离执行过程，再压缩和汇总返回结果。两种方法可以同时使用，局部过程留在子 Agent 的上下文中，整理后的结果再返回主 Agent。

小任务通常适合由单 Agent 直接完成；执行步骤稳定、分支可以预先定义时，固定 Workflow 往往更可靠；子任务需要频繁澄清，或者多个执行者必须持续修改同一份实时状态时，委派产生的协调成本很可能超过收益。因此，是否启用子 Agent，需要同时核对委派条件与成本收益。

任务契约限定子 Agent 的工作范围

任务边界确定后，主 Agent 还要把它写成一份可以执行的约定，因为「帮我检查一下兼容性」很难支撑一次可靠的委派。

只拿到这句话，子 Agent 无法判断应该检查哪些模块、以什么资料为准、能否修改文件，也不知道什么时候算完成。它可能返回一份很长的接口说明，也可能顺手改掉主 Agent 不希望触碰的代码，结果做了很多工作，交付物仍然无法直接使用。

执行前需要定义任务契约。本文所说的任务契约，是主 Agent 与子 Agent 对局部工作的明确约定，不对应统一的行业协议。兼容性核对任务可以整理成下面这张任务卡。

目标：找出 API v1 升级到 v2 时可能破坏现有调用的变化
输入：指定的迁移文档、接口定义和目标模块
边界：只调查和报告，不修改核心代码，不扩展到无关依赖
工具与权限：允许读取仓库和运行指定检查，不允许发布、提交或修改外部状态
输出：按模块列出变化、影响位置、证据来源和建议处理方式
完成条件：目标模块全部核对，并为每项判断提供依据
停止条件：资料冲突、输入缺失或操作需要超出权限时，停止并上报

任务契约与第 4 期「Agent 小知识｜让 Agent 调对工具：输入输出契约的设计」中介绍的 Tool 契约共享一个思路，都通过预先约定减少歧义。Tool 契约约束一次工具调用，任务契约约束一段包含检索、分析和工具调用的局部工作，后者还要说明责任边界、权限和停止条件。

这份约定也划清了双方职责：主 Agent 负责拆解任务、提供输入、控制权限、跟踪进度，并定义完成条件；子 Agent 负责在限定范围内执行，保存关键证据，再按照约定返回结果。

任务契约越清楚，子 Agent 越容易独立工作；如果一个子任务每走一步都需要向主 Agent 追问，它通常还缺少稳定的委派边界。

局部过程隔离执行并按约定回传

任务交出去以后，上下文隔离会改变过程信息的分布。兼容性核对过程中读过的长文档、排除过的无关变化和零散搜索结果，可以留在对应子 Agent 的上下文中；失败测试归类产生的大量日志，也无需逐行返回主 Agent。主 Agent 继续保留全局目标、任务契约、子任务依赖、权限、进度和未决事项，同时接收全局决策所需的证据与结果。

上下文隔离解决的是过程信息由谁处理，文件冲突和安全问题仍需其他机制处理。子 Agent 需要修改代码时，可以增加工作空间隔离，例如让不同执行者在独立的 Git 工作树中修改代码；任务涉及不可信代码时，可以使用沙箱或其他执行隔离；每个子 Agent 还应只获得完成任务所需的工具与权限。

这些隔离层级各自处理不同问题。独立上下文不会自动生成独立文件系统；独立工作树可以避免多个执行者直接写入同一工作副本，但修改仍需在合并环节处理文件冲突和跨文件语义冲突，也无法隔离共享数据库、远程 API 和其他外部状态；沙箱能够限制执行能力，却无法替代清晰的任务边界。因此，生产系统需要结合任务风险选择隔离层级，启动子 Agent 这一个动作，无法自动建立全部边界。

局部工作结束后，信息开始返回主 Agent。本文把这组回传约定称为结果契约，它是一种便于说明的工程抽象，不对应统一的行业协议。按照这份约定组织的结构化结果包，可以包含结论或交付物、关键证据与来源、产物位置、完成状态、局部验证结果、风险与限制，以及仍需确认的问题。

在仓库升级案例里，负责影响面分析的子 Agent 返回旧 API 的调用位置清单，负责兼容性核对的子 Agent 返回接口变化、依据和待确认行为，负责测试归类的子 Agent 返回失败用例、复现条件和日志位置，负责文档检查的子 Agent 返回过期示例及对应文件。4 份结果采用统一字段后，主 Agent 更容易继续核对和整合。

图 2. 任务契约、隔离执行和结构化结果回传的完整链路

“主 Agent 只拿结论不拿过程”容易引起误解。更准确的说法是：回传可以压缩执行轨迹，但支撑判断的依据必须保留。完整聊天、反复试错和未经整理的工具输出可以留在子 Agent 一侧；显式日志则应按审计需要保存，并在追查时按需读取。

这里讨论的是显式任务记录、工具结果、证据和产物，系统不要求获取或展示模型的隐藏思维链，工程验收依赖可审计的外部依据。

信息完成回传后，主 Agent 还要检查结果能否进入最终交付。

主 Agent 负责验收和整合结果

负责兼容性核对的子 Agent 根据迁移资料认定某个旧接口已经废弃，并建议直接删除；负责测试归类的子 Agent 则发现，仓库里的旧客户端测试仍然依赖这个接口。两项事实可以同时成立，冲突发生在处理方案上：是直接删除旧接口，还是暂时保留兼容适配，并把旧客户端纳入迁移范围。

两项调查分别采用了不同证据，主 Agent 不能只按返回顺序或票数选择方案。它需要回到任务契约，检查两边是否覆盖约定范围，再核对迁移资料、调用位置和测试证据，随后作出取舍。

验收时，主 Agent 要检查结果包是否完整、抽查关键证据、确认产物是否可以访问、重新运行影响交付的测试，并处理局部结果之间的冲突。

持续运行或可能进入循环的子任务，需要有明确的停止条件，并按风险设置超时、步骤数或 Token 预算。遇到网络波动等可恢复错误，可以在预算内重试；目标缺失、权限不足等问题应停止并上报。局部失败也要进入结果包，明确已完成项、失败原因和未覆盖范围，不能用部分成功代替整体完成。

并行任务还可能出现级联取消。当一项发现使部分后续工作失去必要性时，主 Agent 可以取消这些仍在运行且能够安全停止的任务；系统支持优雅终止时，还应保存已有产物和任务状态。

子 Agent 报告「局部测试通过」，无法代替整合后的全量验证，因为局部修改分别成立，组合后仍可能产生接口冲突、依赖变化或行为差异，主 Agent 需要在统一状态下完成回归检查。

这种主从式委派也会增加成本。任务拆分需要时间，消息传递会消耗 Token，隔离环境需要资源，结果越多，主 Agent 的验收压力越大。并行执行相互独立的任务，可能缩短部分工作的实际等待时间，却不会自动减少总计算量；加上启动、通信和验证开销，总成本往往更高。

如果主 Agent 一次分派过多边界含糊的任务，它也会成为汇总瓶颈，需要持续追踪进度、处理冲突和补充上下文，同时占用自身的上下文与调度资源。因此，成熟的委派机制关注任务价值、验收条件和责任归属，不追求子 Agent 数量；多个 Agent 给出相似答案，也无法直接证明结果质量有所提高。

子 Agent 补全 Agent 系统的任务分工

这条任务链路走完后，第一季讨论过的组件也可以串联起来。Agent 接到目标时，上下文限定模型当前能够看到的信息，动态 Prompt 组装负责把目标、规则和运行时资料整理成本轮输入；开始执行后，工具提供行动接口，运行环境承载文件、网页、进程和其他外部对象。

任务进入持续推进阶段，任务状态记录当前进度，检查点保存可恢复的状态快照，编排机制安排步骤、依赖和控制流。Agent 在运行环境提供的现场中行动，运行支撑层再通过工具管理、权限控制和沙箱等机制落实执行边界与安全约束。

遇到可以复用的方法时，能力模块可以组织完成一类任务所需的方法、约束和相关资源；需要在未来任务中继续使用的信息，则由跨会话记忆机制进行选择性写入、按需取回和更新对账。当前任务中边界清楚、过程庞大的局部工作，还可以交给子 Agent，由主 Agent 通过任务契约、结果契约和验收机制，把各项结果重新汇成一次完整交付。

图 3. Agent 系统第一季全景：从上下文与能力，到局部委派与结果闭环

这些组件相互约束、彼此配合，共同支撑 Agent 系统的可靠运行。回到开头的仓库升级任务，主 Agent 可以把边界清楚的局部工作交给子 Agent，把冗长过程留在独立上下文中，再依据回传的证据和产物完成取舍与交付。隔离的是过程，保留的是依据。

Agent 小知识第一季完结寄语

第一季从上下文、动态 Prompt 组装、工具、任务状态、编排、运行环境、能力模块和跨会话记忆，一路讲到本期的子 Agent。这些主题共同回答了一个问题：怎样把一个会生成文字的模型，组织成能够在真实环境中持续工作、接受约束并对结果负责的 Agent 系统。

下一期，Agent 小知识专栏将进入第二季，视线也会从 Agent 系统内部的运行机制，转向 Agent 与工具、业务系统和其他 Agent 的连接。我们会先从 MCP 中工具、资源和提示词的分工讲起，逐步梳理这些连接如何建立、约束与协同。

参考资料支撑正文的工程判断

• Haggai Roitman, The Hitchhiker's Guide to Agentic AI: From Foundations to Systems，arXiv:2606.24937v2
• 李博杰，《深入理解 AI Agent：设计原理与工程实践》
• 《Agent 小知识｜上下文预算：让 Agent 知道该看什么》
• 《Agent 小知识｜让 Agent 调对工具：输入输出契约的设计》
• 《Agent 小知识｜存得下不等于想得起：Agent 跨会话记忆的工程设计与对账机制》