过去做智能体系统，常见做法是搭一堆子智能体：一个负责检索、一个负责整理、一个负责写稿、一个负责检查，彼此分工协作。这套架构在模型能力有限时很有必要，但代价也很明显：协调成本高、上下文来回传递容易丢信息、出了问题很难定位是哪个环节掉的链子。

Anthropic 在 10 月 25 日公开的工具集，给出了另一种思路：把始终协同工作的辅助智能体整合进一个主智能体，用主智能体的工具技能集来承接原来的分工。它的判断是，随着基础模型智能水平的提升，单一大模型已经能够独立处理过去需要多人协作的复杂任务，整合后的执行速度可以提升约两倍。

下面是按这套思路整理的六步实操流程：

第一步，盘点现有架构。把当前系统里所有子智能体列出来，写清楚每个子智能体负责什么、输入是什么、输出是什么、它和谁协作、调用频率如何。没有这张清单，后面的整合就是盲改。

第二步，识别“始终协同”的组合。重点看哪些子智能体几乎每次都一起出现、互相传递结果、缺了谁任务都完不成。这些就是优先整合的对象。反过来，那些偶尔才被调用、或者任务边界很清晰的子智能体，可以先不动。

第三步，评估整合收益与风险。对每一组候选组合，问三个问题：整合后任务完成率会不会下降？单次任务耗时能不能缩短？总成本是升还是降？如果三个问题里有两个答案是负面的，就先放一放，不要为了整合而整合。

第四步，把功能迁移进主智能体的工具技能集。不要简单地把子智能体的提示词拼在一起，而是按主智能体的执行逻辑重组：原来由子智能体 A 负责的检索，变成主智能体的一个检索技能；原来由子智能体 B 负责的整理，变成主智能体的一个整理技能。每个技能都要有清晰的触发条件和输出格式，否则主智能体会在多个技能之间摇摆。

第五步，保留需要独立上下文的子智能体。Anthropic 的建议里有一条很容易被忽略：对于需要保持独立上下文的辅助智能体，仍应予以保留。比如处理敏感数据、需要长期独立记忆、或者任务之间必须隔离的场景，强行合并反而会引入干扰和泄漏风险。

第六步，量化对比再决定。整合前后各跑同一批真实任务，记录三个指标：任务完成率、单次耗时、总成本。只有完成率不降、耗时或成本有明显改善，才算整合成功；如果完成率掉了，哪怕速度快了，也要回滚或者调整技能划分，再测一轮。

几个实操提醒：

一是先小规模试点。挑一条高频但容错率较高的任务链先整合，跑通后再推广到核心链路，不要一上来就重构整个系统。

二是给主智能体留好“分工边界”。技能越多，主智能体越容易选错工具，所以每个技能的描述要写清楚适用场景和不适用场景，必要时加一条“不知道该用哪个技能时先问用户”的兜底规则。

三是做好回滚准备。整合前把旧架构的配置和提示词完整备份，万一新架构在真实流量下表现不稳，能在最短时间内切回去。

观点：单智能体不是万能药，它是对“模型变强了”这一事实的顺势调整。判断标准始终只有一个：同一批任务，完成率、耗时、成本三项指标是不是真的变好了。指标说话，比架构信仰更可靠。