多智能体架构未必更强：把专家子智能体折回主循环，质量常更好、延迟更低

企业智能体架构出现一种反向做法：把路由器、规划器和领域子智能体合并进一个主智能体循环，而不是继续叠加编排层。 此前的常见设计是意图分类器、固定多步推理流水线、用户分群、独立推荐分支，再在顶部加一个多智能体编排器；也有企业让每个团队各建一个子智能体，架构变成组织架构图的翻版。 在若干企业部署的对比中，带技能的单一智能体在质量上经常同时优于“一个提示包打天下”和子智能体设计，且每任务成本与延迟往往更低；一家公司发现其客户侧智能体里的十多个专家子智能体难以维持一致的品牌体验，并增加了拖累用户体验的延迟。

做法是让一个模型在一个上下文窗口里跑开放式工具循环，由模型自己写计划并在结果到达时修改计划。 原先由代码步骤按规则目录重写计划，顺序与领域流程放在编排层，硬性校验和审批门放在外层。 每一轮模型发出一批工具调用，由外层框架并行执行并把原始结果返回同一模型，由它决定下一步；顺序与领域流程移入技能，校验、审批门和记忆查询移入工具，循环在模型给出答案或触及预算时停止。

迁移按阶段推进：先建任务完成度评测，再逐个把子智能体折成技能加工具，并比较折入前后的表现。 此前各团队各自添加只针对自身子任务的评测，没有人维护整体评测集，管理层依据被稀释的局部分数做决策。 建议由一个中央小团队持有一套端到端评测，每个技能随附各自的小评测集，十个黄金样例即可起步；在一个客服智能体样本上，折入一个子智能体降低了延迟，但也破坏了一个原本通过的流程，且该问题两次运行中只出现一次。

讨论范围是使用 Claude Platform 构建的企业智能体，尤其是已有编排器与专家子智能体的生产系统；给出的迁移路径是先建小型端到端评测，再逐个折入子智能体，折入后表现更差才保留为子智能体。子智能体仍被明确保留在三种情形：单一循环因上下文膨胀出现可测的性能下降、多个任务需要并行且用完即可丢弃的新上下文窗口、单一智能体难以选择工具或系统提示中存在冲突指令。

结论来自若干企业部署的对比与一个客服智能体样本，并非受控的大规模基准；折入子智能体可能破坏原本通过的流程，且这类问题在重复运行中不一定每次出现。单一循环设计要求严格管理系统提示、技能与工具描述以及上下文和记忆，文中也指出模型能力仍在变化，最佳实践会随之调整。