时代互联资讯中心
随着业务线越铺越宽，不少企业搭起的多 Agent 系统也跟着野蛮生长。主 Agent 站在全局统筹位置，把大任务拆成小块派发给各个 Subagent：每个子单元带着自己的提示词、独立的上下文窗口和专属工具干活，交付后再把结果交回主控。
这套主从系统的红利清晰可见。任务之间天然隔离，多个子 Agent 还能同时开跑。可一旦这些任务之间存在不小的上下文依赖，协作的隐形成本就开始冒头——每一次交接都要重新组织输入，结果经过系统压缩或摘要后，藏在细节里的信息大量流失，下一个拿到手的往往是削过一层的版本。
有意思的是，模型在规划、工具调用和指令遵循上的能力持续走强，过去非得分派给多个 Subagent 才能搞定的活儿，如今有一批已经能塞回单个 Agent Loop 里统一消化。Anthropic 近期在多个企业部署场景里就是这么做的：有意识地减少 Subagent，把业务流程沉淀成 Skill，把系统操作交给工具，再靠渐进式加载把主 Agent 的上下文压住。几轮测试下来，任务质量有改善，延迟和成本也一起降了下来。
这套调整背后其实是一连串值得掰开算清的问题：Subagent 到底该按业务领域切，还是按上下文关系切？单 Agent Loop 要怎么兜住不断增长的能力？已经跑起来的多 Agent 系统又该怎么评估、怎么落地迁移？
企业多 Agent 架构的协作成本
企业搭 Agent 时，很自然地把多个业务系统并到一个统一入口。拿客服 Agent 打比方，它可能要同时接住订单查询、物流追踪、退款申请、会员权益、产品咨询这一堆活儿。
常见的一种做法是让各业务团队各自开发自己的 Agent，再由平台团队叠一个 Orchestrator，用来识别用户意图、分发任务。好处是各团队的现成业务逻辑能复用，维护也分散。可 Subagent 一多，系统的复杂度就开始爬升，痛点集中在几个地方：
上下文管理。每个 Subagent 都要占一个独立上下文窗口，Orchestrator 还得替它决定喂哪些信息。任务跨多个子单元时，中间结果要反复转换、筛选、压缩。要是返回给主 Agent 的结果里没带上执行细节，下游的 Agent 就用不上了。
Subagent 数量的膨胀。不同团队容易做功能重叠的 Agent，调用同样的数据接口，提示词和操作规则却各走各路。有的企业攒下几百个能力高度重合的 Subagent，既没有统一的管理口径，也说不清该谁来维护。
系统指令互相打架。各团队不断往 Orchestrator 或共享提示词里塞新规则，规则越积越多，重复、冲突就冒出来了，最后拼出一坨 Frankenprompt——那种东拼西凑的提示词。
局部评测盖不住整体任务。各团队围绕自己的 Subagent 搭 Eval，能看清某一项能力的表现，却照不到完整的用户旅程。每个子单元都通过了局部评测，任务仍可能在路由、上下文交接或结果整合的环节栽跟头。
执行延迟。多 Agent 里的路由决策、嵌套模型调用、上下文传递都会额外耗时间。尤其是存在前后依赖的任务，没法并行跑，整体耗时随着层级加深一点点拖长。
这些短板在实际部署里都能找到印证。Anthropic 分享过一组企业对比测试：单 Agent Loop 的执行速度能跑到旧有多 Agent Harness 的两倍左右。另一套客服系统养了十多个专业 Subagent，不同 Agent 的表达风格还难统一，堆叠的调用也拖累了用户体验。
虽然测试结果总会受具体业务和架构条件牵制，但它点破了一个现实——Subagent 带来的专业化收益，得和它叠加的协作成本一起掂量。
更值得警惕的是，一些企业的复杂架构里还留着早期模型能力不够时搭起来的辅助流程：独立的意图分类器、固化的多阶段规划、专家路由、层层叠叠的 Orchestrator。其实不少场景里，一句清晰的系统提示词配上四五个轻量的数据工具和明确的输出约束，就能扛下大半的任务。
所以重新审视多 Agent 架构的第一步，是先摸清现有 Subagent 各自承担着什么活儿，以及它们之间的上下文依赖有多深。
单 Agent Loop 与渐进式加载机制
Subagent 减下来之后，原来分散在多个 Agent 里的规划、执行、结果分析，就得重新收拢到主 Agent Loop 里。
这种设计下，系统由一个模型、一个主上下文窗口、一轮持续迭代工具调用的循环组成。Harness 管着执行预算、权限边界和必要的校验，模型则按任务目标自己决定下一步怎么走。
一次典型的任务执行大致走这几步：
- 模型按用户目标先把计划拟出来，存进上下文。
- 模型发起一批工具调用，由 Harness 并行跑完，再把结果交回同一个上下文窗口。
- 模型加工工具返回的结果，结合实际状况修订计划——是继续调工具，还是回头向用户要更多输入。
- 任务收口，或者达到轮数、成本这类预算上限时，执行循环停住；必要时再做一次目标核对或结果验证。
关键变化在于，规划和执行交到了同一个模型手里。它能随着工具结果不断更新任务状态，省去了 Orchestrator 和各 Subagent 之间来回倒腾的麻烦。
打个比方，一个企业 Agent 可能要先查客户合同，再核对历史订单，最后给出续费建议。查下来发现合同信息有异常，模型就能顺着查询结果改后面的步骤，甚至反查相关记录，不必再把活儿甩给一个独立的规划器。
不过，能力往主 Agent 这边集中，新问题也来了：业务规则、工具定义、参考资料不断增加，系统提示词和上下文会变得相当臃肿。
应对这种膨胀，Agent 系统可以引入渐进式加载（Progressive Disclosure）。刚启动时，Agent 只需知道手里有哪些 Skill 和工具、各自管什么就够；等到任务真正碰到某个领域，再把那套完整指令、工具定义或参考文件取出来。
就像客服 Agent 带着退款、物流、会员权益等多种本事。用户一来申请退款，它就加载退款的流程 Skill，再按流程去调订单查询、退款资格校验这些工具。其余业务领域的细则还留在外面，不会占用当前这段任务的上下文。
渐进式加载同样能套在 Skill 和工具上。Skill 可以先用简短描述判断要不要用，再读详细操作流程和参考；工具则能让 Agent 通过 Tool Search 去检索，按需补齐完整的工具定义，免得一次性甩出一堆工具给模型造成选择负担。
这么一来，效果大体落在三处：
其一，多个执行步共享同一段任务上下文，模型能复用之前工具调用的原始结果，跨 Subagent 传摘要时的信息损耗明显减少。
其二，业务能力可以无限续杯，而系统提示词却不必把所有领域的细则都塞进去。Claude Code 针对较新模型的系统提示词就一度压减了近九成，其中一部分改动就和 Skill、工具的渐进式加载有关。
其三，随着模型变强，一些固定的编排逻辑也能放手交给模型自己拿主意，开发者可以删掉 Harness 里那些不必要的路由、判断和任务重规划代码。
但要记住，单 Agent Loop 还是得长期盯住上下文的增长。执行过程中要是攒下一堆无关信息，模型的表现照样会掉。所以渐进式加载、上下文压缩、任务笔记加上必要的上下文隔离，还是得配合着来。
实操贴士：在上下文预算吃紧的项目里，先把最高频出现的字段和规则塞进主上下文，其余低频内容一律走渐进式加载，往往能换来可观的稳定性提升。
Subagent 的上下文边界
要不要留下 Subagent，是这次架构调整最核心的关节，这个决定往往比写多少代码还关键。
传统多 Agent 系统习惯按任务类型切分。写代码的 coding Agent、生成测试的 testing Agent、审查代码的审查 Agent，各管一摊。
分工看着清爽，可不同任务常常需要共用同一批上下文。编码 Agent 在落地功能时，对需求理解、代码结构、接口约束以及实现里的技术取舍心里得有数；要是把测试丢给另一个子单元，这些又得重新传一遍。就算测试 Agent 拿到了最终代码，也未必懂此前的实现背景——比如某条异常分支为什么选了当前处理方式，某项兼容性要求究竟从哪来。
当多个 Agent 之间上下文依赖较强时，按任务类型切，反而把信息传递的成本抬高了。
优化路子是让同一个 Agent 把功能开发和测试编写一并做完，再丢给独立的 Verifier 做黑盒校验。Verifier 只需跑测试、返回结果，不用吃透完整实现过程，因此它可以用独立上下文，也能给出相对独立的验证结论。
从这个角度看，Subagent 的切分不必非要跟着任务类型走，而应从任务之间的上下文依赖出发。需要共享大量中间信息的活儿交给同一个 Agent；只吃少量输入、能独立出结果的任务，可以继续单独立起来。
再往下推，三种情形比较适合保留 Subagent：
上下文膨胀会换来可测量的性能下滑。主 Agent 要读海量资料、跑长任务，上下文一长就拖累任务质量时，可以把一部分活甩给独立 Subagent，让它开新上下文窗口去处理，再回传精简结果。
任务之间存在明确的并行关系。各 Subagent 负责的活儿能独立跑、各自只需回传少量结果时，并行执行能明显缩短总耗时。独立调研、多个代码组件并行开发这类任务通常符合条件。
工具选择或系统指令存在难以化解的冲突。不同领域用了相似的工具接口、执行规则却各不相同时，模型可能反复选错工具、违反领域约束。用独立 Subagent 把指令和工具隔离开，能压这类干扰。
顺带一提，权限隔离虽是多 Agent 的一项能力，但一般的业务权限未必非得靠独立 Agent 来扛。针对不同用户的数据访问限制，交给工具按调用者身份做权限校验就够了。
所以划分 Subagent 时，上下文依赖、任务独立性、并行收益、指令冲突、权限要求得一起掂量。其中上下文依赖可以拿真实执行轨迹来反推：哪些 Subagent 总被连着调，哪些得共享大量中间结果，哪些只负责回传一个结构清晰的最终结论。
从多 Agent 到单 Agent Loop 的迁移
正在运行的多 Agent 系统别急着一次大改，渐进式推进往往更稳。
迁移的主线，是在压低 Subagent 协作成本的同时，保证老系统依旧能踏实完成各项业务。
端到端评测基线
动手前，先立一套端到端 Eval，把当前架构在真实任务里的底子记下来。基线可以这么分：平台团队负责完整用户任务的评测集，各业务团队负责各自领域的局部 Eval。起步阶段先挑十几个验证过的典型任务跑一跑，再慢慢把范围铺开。
评测既要看最终任务成没成，也得盯执行过程对不对。
老的多 Agent 架构，重点看 Orchestrator 有没有选对 Subagent；合并之后，则要看主 Agent 加载的 Skill 对不对、工具用得对不对、有没有守住业务规则。
对存在前后依赖的流程，还要专门设评测点。比如查完订单再确认物流状态、身份验证通过后才提交退款、核对账户权限后才敢碰敏感数据。
靠这些评测，就能看出架构改动之后有没有冒出新工具调用或执行路径上的岔子。
按共享上下文合并 Subagent
评测基线立好后，可以拿生产环境里的调用轨迹去找能合并的 Subagent。优先盯那些被连续调用、访问同一份数据、或者互相要吃对方结果的子单元。
比如大量请求都是先调订单 Agent 再调物流 Agent，而这两个都得知道当前订单状态，那就值得把它们并进同一个领域 Agent——这类执行链路上下文依赖太强了。
对依赖弱、能独立收尾的任务，就先留着。
迁移刚起步时，还可以把原来的 Subagent 当工具甩给主 Agent。既留住了原有的专业能力，也让主 Agent 统管用户交互和结果整合。
这种过渡不用急着重写 Subagent 的全部逻辑，还能靠统一的返回结构让主 Agent 进一步校验执行结果。
只是这种方式底下还是留着独立的 Prompt、独立上下文窗口和嵌套模型调用，执行延迟和上下文传递的老问题一时消不掉。
将 Subagent 能力迁移到 Skill 和工具
对确定要并的 Subagent，可以一点点拆它内部的能力。原来 Prompt 里的业务流程、判断规则、执行顺序往 Skill 上挪；访问业务系统、发 API 请求、回传结构化结果的能力往 MCP Tool 上挪。
举个退款的例子：某个退款 Subagent 原本一手包揽查订单、判断退款资格、执行退款、通知用户。
迁完之后，主 Agent 加载退款处理 Skill，按里面的规则去调订单查询和退款执行工具；身份验证、金额上限、审批条件这类硬约束，交给工具或 Harness 来把关。
这样一来，主 Agent 留住了完整的用户任务上下文，业务团队也照样能维护退款流程和相关工具。
实操贴士：每次只啃一个 Subagent，改之前改之后都跑同一套 Eval，拿任务完成率、成本、延迟和具体失败案例逐项对比，踩坑的风险会小很多。
迁移中的性能回退与可靠性
Subagent 并完，即便总体评测分没怎么掉，某些具体任务照样可能退回老路。
一组客服 Agent 测试里，合并 Subagent 确实压低了延迟，可原本能跑的物流查询流程却翻了车。合并之前，主 Agent 把配送日期查询丢给物流 Subagent；合并之后，主 Agent 自己手里有了订单查询工具，就自作主张读订单信息答配送日期，不再去调物流 Subagent，结果答错了。
这种问题在两次测试里才冒出来一次。它说明架构改动会改掉模型的工具选择和任务路径——原先靠 Subagent 分工钉死的流程约束，合并后容易松绑。
于是评测时得分格外留意：具体任务是从通过变成失败，还是卡在哪个执行步骤。
对必须守住的业务规则，得设专门的检查。退款前身份验证做没做、物流日期对不对数据源、敏感数据过没过权限校验。这些约束要是工具和 Harness 能兜住，就尽量走程序化检查，别把宝全押在 Prompt 指令上。
同一个任务还要反复跑几遍，看模型输出的稳不稳。对没法完整回放的生产系统，可以记关键业务事件加时间戳，再据此搭针对性的 Eval。算成本也别只盯 Token 消耗，模型调用次数、工具调用数、嵌套执行深度、端到端延迟都得算进去。Subagent 一减，主 Agent 上下文可能变长，单次调用的成本也可能涨，工具调用要是没搭好，最后未必省得了总成本。
所以说评估架构改动，得结合实际执行路径一起看，光凭 Subagent 数量增减来判断优劣，容易看走眼。
Agent 架构选择的延伸讨论
单 Agent Loop 和多 Agent 怎么选，其实还能借别的 Agent 系统的经验来补脑子。
OpenAI 在《A Practical Guide to Building Agents》里提了个建议：先把单 Agent 的能力往宽处铺，靠加工具、完善指令来覆盖更多活儿。等系统冒出复杂的条件分支、反复违反指令、或选工具选不稳，再考虑拆成多个 Agent。
工具的数量和相似度本身就会影响表现。有的 Agent 能稳用地拖拽十五六个差异明显的工具，也有的 Agent 即便只用四五个高度相似的工具，照样会选错。
所以比起数工具有几个，接口清不清楚、指令复不复杂，才是更该盯的点。
反过来，多 Agent 的研究系统又展示了独立 Subagent 的价值。研究任务拆成几条检索方向，各 Subagent 用独立上下文并行跑搜索、分析、资料整理，最后主 Agent 再把结果收拢。
这类任务并行性很强，不同研究方向之间互相牵扯少，每个 Subagent 还能把一大捞检索信息压缩成几句短结论回传。
而对订单处理、客户管理这类企业工作流，往往得共享任务状态，多个 Subagent 频繁交换同一份数据，上一步结果直接影响下一步判断，多一层上下文交接就多一份成本。
这背后其实是 Agent 架构里一道挺核心的取舍：共享上下文能少丢信息，独立上下文利于任务隔离和并行。
独立性强的任务可以继续多用多 Agent；需要连续决策、共享状态的流程，则优先掂量单 Agent Loop。当然，模型能力和工具系统一直在变，这两种架构的适用边界也会跟着挪。
迁移工具与持续评测
为了托底多 Agent 架构的迁移，Anthropic 也放出了 Single Agent Loop Kit 来帮忙。
这套东西从评测和架构审计切入，先摸清现有 Subagent 之间的调用关系，再结合任务特性给建议：该并，还是转成工具调用，还是继续留着。
其中 build-eval 负责搭和扩评测集；prompt-audit 专门翻旧模型时期遗留的 Prompt 规则；hillclimb 能靠现有 Eval 持续打磨 Skill 和工具描述；cost-optimize 则去算 Token、Prompt Cache 和模型选择这些成本账。
Single Agent Loop Kit 还附了调用耦合分析、评测覆盖检查、迁移前后结果对比之类的脚本，帮识别那些总被连着调的 Subagent，也帮盯评测集有没有覆盖住生产环境里的调用链路。
这些工具能搭把手，但公开参考实现跑的真实模型测试覆盖还算有限，得多经过几个生产环境才算数。
落到真实项目里，还是得按自己的业务搭评测基线，一个个调 Subagent，验证每次改动到底有没有见效。时代互联在接手不少企业做架构梳理时也发现，这套「先立基线、再小步迭代、边调边验」的节奏最不容易翻车。
把这个流程收进持续优化机制里会更省心。模型升级、工具更迭、业务调整都会发生，团队可以定期回头看执行轨迹，掂量哪些 Subagent 能并，哪些任务又该重新独立出来。
结语
Subagent 的分与合，考的是对任务上下文、执行依赖和系统协作成本的整体把握。
对频繁同访一份数据、需要持续共享任务状态的工作流，把部分 Subagent 并回主 Agent Loop，能压掉不少上下文交接成本，也让 Harness 里的编排逻辑瘦身。
对边界清楚、能并行跑、或者需要隔离复杂指令的任务，留着独立 Subagent 反而是更踏实的选择。
