企业智能体架构：何时将子智能体并入主循环？

AI应用团队在企业部署Agent系统的过程中发现，不少原本拆分的子Agent整合进主循环后，整体效果反而更好。在为企业搭建Agent架构的实践中，需要明确哪些分工值得保留，以及如何逐步完成整合优化。

在搭建Agent时，减少子Agent的使用，改为按需逐步加载上下文与工具，既可以提升系统质量，也能降低成本与延迟。

子Agent是Agent设计中的核心组件，各自拥有独立的上下文窗口、工具与指令，由协调者统一调度，在任务验证、并行处理、模块化权限管理等场景中具备优势。但在企业实际部署中，不少团队发现，将负责路由规划、特定领域处理的子Agent并入主循环后，系统表现反而得到提升。对多家企业的架构对比显示，配备技能库的单Agent系统，在任务质量上同时优于“单一提示词”和多子Agent的设计，且任务成本与延迟更低。

某企业的面向客户Agent曾包含十几个专用子Agent，结果不仅难以维持统一的品牌体验，还大幅增加了延迟，损害了用户使用感受。

不少企业的Agent设计容易陷入“功能堆砌”的误区：从意图分类器，到多步推理流水线、用户分群、推荐分支，再到多层子Agent编排，层层叠加的结构反而让系统变得臃肿。这类情况下，模型本身已经可以承担大部分原本需要外部拆分的工作，一条清晰的系统提示词、4到5个轻量数据工具，加上明确的输出约束，就能覆盖绝大多数业务需求。

当然，子Agent仍有其适用场景，尤其是前沿研究领域。当出现以下情况时，保留子Agent是合理的选择：

• 单Agent循环因上下文膨胀出现明显性能下降；

• 需要并行处理多项独立任务，每项任务使用独立上下文窗口且完成后可丢弃；

• 单Agent难以选择合适工具，或系统提示词存在相互冲突的指令。

但企业中常出现的问题是，每个团队或每类问题都单独配置子Agent，最终Agent架构完全照搬企业组织架构，康威定律的效应被不断放大。本文结合实践，介绍何时应该考虑把子Agent整合进主Agent循环。

大型企业Agent架构的典型痛点

企业通常希望构建统一的Agent界面，整合多种产品与服务能力。这些能力往往由不同团队负责，因此初期会让各团队分别搭建子Agent，再由中央团队搭建编排器，形成“编排器-子Agent”或单Agent调用专用Agent的结构。

这种看似简单的方案，会立刻带来以下复杂性：

• 上下文管理难题：需要决定Agent间的上下文交换范围，信息在传递过程中容易丢失细节。
• 子Agent泛滥：各团队独立开发子Agent，最终形成大量能力重叠的子Agent，缺乏统一标准与总负责人。
• 提示词冲突：各团队在系统提示词中添加专属规则，导致指令相互矛盾，风格不统一。
• 局部化评测问题：各团队仅优化自身子任务的评测，无人负责整体系统的评测，管理层依据局部化的分数做决策。
• 延迟增加：多Agent架构的复杂性会提升运行延迟，某客户对比后发现，单Agent循环的运行速度比多Agent架构快一倍。

基于渐进式加载的单循环设计

“编排器-子Agent”是协调多团队子Agent的常用方式，但更有效的做法是通过技能按需加载上下文，通过工具按需加载资源，这就是渐进式披露的思路——Agent先获取技能与工具的简短描述，仅在需要时加载完整内容。

这种设计更合适的原因有三个：

• 共享上下文带来更优回答：对于长时间运行的Agent，多任务的上下文保留在主窗口中，Agent能关联之前的结果，相比仅接收子Agent的摘要，产出更丰富、洞察更深入，同时减少上下文窗口的使用与信息传递的损耗。
• 渐进式加载避免上下文膨胀：团队可以构建单Agent完成多任务，无需将所有内容塞进冗长的系统提示词，这也消除了拆分多个子Agent的核心原因。
• 模型能力提升降低架构复杂度：新模型会自动说明工作进展、自我校验，减少了运行框架中的冗余环节。每一代新模型都让更多决策从框架转移到模型自身，更简单的循环也更容易适配下一代模型。

单Agent循环仍需严谨管理：精心维护系统提示词，让技能与工具在合适的时机触发，同时处理上下文窗口、记忆与笔记。建议由中央团队负责端到端质量与系统提示词，新工具与评测上线前需审核，精简的中央团队能降低协调成本。

如果选择多Agent路线，应从最简单的模式入手，比如“生成器-验证器”。按上下文划分工作，给每个子Agent分配不依赖其他部分的任务，返回简洁结果，是合适的边界划分方式。如果按问题类型拆分Agent，会陷入“传话游戏”，每次交接都会损失信息保真度。

子Agent整合为主循环的实施路径

多数团队已部署了编排器与专用Agent，建议逐步向单循环设计演进，核心包括：

• 单一模型与上下文窗口，运行开放式工具循环，轮次与成本预算等限制由框架设置；

• 每轮模型输出工具调用，框架并行执行后返回结果，模型决定下一步操作；

• 模型给出回答或达到预算上限时循环结束，可增加目标或验证检查；

• 模型在第一轮写入计划，后续不断修订，制定与执行计划为同一模型，可在单轮内调整；

• 上下文由Agent自行管理，无需额外代码步骤，执行顺序放入技能，硬性限制放入工具，低价值信息用代码处理。

将子Agent转化为工具与技能，可通过以下步骤逐步推进：

围绕任务完成情况做评测

第一步是建立评测体系，判断是否整合子Agent。有效的评测结构是：中央团队维护共享的端到端评测，各技能团队配备小型评测集，起步时10个样例即可。按评分标准评价Agent回复，是跟踪质量的基础，整合后需检查Agent是否加载了正确技能或工具。

逐步减少子Agent

向单循环演进，意味着把子Agent转化为工具和技能，可通过合并领域子Agent、作为工具调用、用技能替代三种方式实现。

合并领域Agent

合并前先建立小规模端到端评测，从使用最频繁的子Agent开始，优先合并前后依赖、处理相同数据或常一起调用的子Agent。

把子Agent作为工具调用

如果需要保留子Agent，可让主Agent以工具方式调用，仅在子Agent需直接交互时接管对话。这种方式的问题是：子Agent仍有独立提示词与评测，返回结果为摘要，嵌套模型循环增加延迟。

通过技能和工具整合子Agent

逐个将子Agent整合为主Agent：将提示词转为技能，API转为工具，比较保留与移除子Agent的评测表现。比较时不仅看分数，还要看任务结果变化，整合后需确保评测覆盖所有调用链与规则。

跨团队协作下的Agent共建模式

领域推理所需内容可从知识库、技能与工具获取，各团队可将重点转向技能与工具，由精简的中央团队负责系统提示词与端到端质量审核。

MCP工具

当Agent需执行动作、读取实时数据或返回固定结果时，工具更合适。建议按用户意图组织工具，减少工具数量以提升选择能力，工具内部处理依赖条件与权限，避免单独设置Agent。

技能

当Agent需了解团队工作流程时，技能更合适。技能库扩大后，由编写团队维护，可借助工具精简技能，各团队负责人负责技能的设计与评测。

知识库

对于偶尔需要的参考材料，知识库更合适，避免代码检索后粘贴进提示词，可放在搜索工具后或作为技能参考。

提升迁移效率的辅助工具

近期推出的一系列API技能可帮助完成迁移，工具包提供引导式工作流，包含演示可试用：

• 帮助建立端到端评测的工具；

• 检查并优化提示词的工具；

• 迭代优化技能与工具的工具；

• 分析并降低成本的工具。

随着模型演进，架构原则比具体方法更重要：先测量，每次仅修改一项，保留有效做法。整合子Agent无需一步完成，先建立评测，再逐步整合，仅当整合后表现下降时保留子Agent。