一、为什么是 SubAgent？

其实多智能体系统是一个非常自然的想法。因为单个智能体的能力总是有限的，所以为了实现更大的目标、完成更复杂的任务，就需要彼此协作共同配合。多智能体主要有以下几个好处：

• 将任务拆分后，能够让每个 SubAgent 更加专注于某类特别的任务，就可以让 SubAgent 在这些任务上特化。之前没有多智能体时，构建通用智能体是一件比较复杂的事：一个智能体既要能回答用户问题，也要能分析代码库，还要能增删修改其中的功能逻辑，可能还得能写单测、运维部署啥的。这就让一个智能体的设计异常的复杂，需要平衡各方面的能力，而且每一种能力的构建都让系统变得更加复杂。这就像把所有的功能都写在一个文件里，发展到后期就变得难以维护或更新。其实人类社会也是这样，才会分为各种不同的职业岗位。有了多智能体后，每个 subagent 就只需要干它擅长的那个领域的任务就好，对于单个智能体的负担就没那么重了。

• 多智能体能够并行完成同一个任务，从而加快任务的进度。比如公司团队分成市场、产品、技术等不同岗位，不是说每个岗位一个人就行，每个方向都有许多人。虽然某一个种类的员工能干对应的活，但是活太多做不完的时候，就可以多找几个人一起做。在 Agent 里就是并行调用 SubAgent。一个典型的场景就是智能体去阅读分析代码库，或者做网络搜索的时候，并行调用多个 SubAgent 一起执行，就能大大缩短所需时间。

• 主智能体调度协作 SubAgent 的时候可以只考虑初始任务布置及最终结论，不需要关心中间的完成过程。比如主智能体让 websearch 智能体去调研搜索相关内容，可以省去 SubAgent 去阅读的具体网页内容，而是直接获取 SubAgent 总结好的结论。这就极大缩减了主智能体的上下文占用。因此，主智能体就能规划执行一些更长程、复杂、宏大的任务。

二、多智能体框架的原理

多智能体的关键在于任务的拆解以及派发。需要设计好一个善于将任务拆解的智能体，能够将任务拆解为适合每个 SubAgent 执行的子任务，在 Comate 里就是 Architect 智能体。接着需要设计一个让 Architect 能调用其他 SubAgent 完成任务，再获得结果的机制。

Comate 直接将其做成了一个特殊的工具 Subtask，Architect 调用这个工具的时候会将子任务目标作为参数输入工具。同时输入的还有具体的 SubAgent 名字，然后框架启动对应的 SubAgent，并把子任务目标作为需求交给 SubAgent。当 SubAgent 执行完整个任务后，SubAgent 总结的报告将作为 Subtask 工具的结果返回给 Architect，继续执行 Architect 的核心循环。

这里会有一些细节，比如实现的时候需要考虑 SubAgent 如何能被主智能体充分了解，能够让主智能体知道什么任务是最适合这个 SubAgent 执行的场景。这里做了一套 SubAgent 动态加载模块,每个 SubAgent 的名字以及对于它适用场景的描述会根据主智能体的勾选，动态加载进主智能体提示词里。这样既可以保证主智能体不去调用那些它不应该调用的 SubAgent，也可以保证主智能体的上下文不被这些不需要的信息占用。

同时，任务之间可能会有反复的交互以及接续。比如 SubAgent 某个任务执行到一半后，需要让主智能体判断一下再继续执行。这个时候就需要主智能体有从过往执行的任务中再次启用该任务的能力，也就是说需要对这些子任务也进行管理。

那么，能不能只管理 SubAgent ，每次复用同一个 SubAgent 就好？其实是不可以的，有两个点：

1.子任务可能交由不同的 SubAgent 接续执行（这样的场景很少）；

2.有些子任务需要多个相同的 SubAgent 并行执行，比如可以让多个 websearch 智能体并发执行搜索，这样能大大减少任务的执行时间。

对于 SubAgent 来说，用户写的这些指令远不足以让它用得好。所以需要有一些保持 SubAgent 良好运转的 prompt 默认加载，再加上用户定义的特别指令，共同作用下，能既让用户的指令影响到 SubAgent 的行为，又能保证所有 SubAgent 在多智能体系统中良好运转。

当然，在工程实现以及具体落地过程中，也有很多很多细节要优化，比如：用共同文件技术让多个 SubAgent 在 Vibe Execution（氛围执行任务）时处于同一个 Vibe 下。

左边的是 Cognition 当时提出的多智能体协同时可能出现的方案，右边是我们的共同文件方案

这个共同文件技术，是指 SubAgent 以及主 Agent 会同时修改一些共用文件：比如对项目的理解笔记、用户请求的执行计划。这些共同文件会直接展示给智能体，而不需要它们自己去阅读。它们在执行自己子任务的过程中，会把自己任务的执行详情写入到这个共同文件中。这样就能保证在不同的子任务中，所有 SubAgent 能够保持对项目理解、对任务的总体规划、对其他子任务的完成情况都有一个相同的认知。

三、3 个典型的 SubAgent 使用场景案例

Case1：通过多智能体协同完成技术调研

上期直播《一句话驱动智能体团队》已经介绍了 SubAgent 的基础用法，现在来更进一步，了解一些我们内部觉得很有意思、很有前景、比较有扩展度的用法。

之前 OpenAI 还有 Anthropic 都做了 Deep Research 这样的功能，就是给一个想要研究的议题，然后让智能体针对这个议题反复调研，并根据调研获得的结果进一步调研。用好这套多智能体系统，就可以马上获得一个 Deep Research 系统。可以尝试用它来做技术选型的调研。比如我在这里选中 Architect 智能体，在输入框中让它“调研一下 Rust 适合写高性能服务吗？” 它就会规划并协调相应子智能体完成任务。

👉观看视频版https://live.csdn.net/v/494503

为什么要做技术调研呢——其实写代码就像盖房子，开头打好地基很重要。软件工程也是这样，一开始做技术选型、设计基础架构就是打地基。之后所有丰富项目的功能、增加更多优化都是在往上盖楼。盖好了一定的楼层、加了一定数量的功能以后，就很难再改动底层的一些内容。如果非要改动，那么代价非常非常大。所以一个项目开始，或者一个新功能开始的时候，都需要做大量调研来做技术选型。技术选型其实挺难的，万一选错了就是整个项目组的人大量辛苦成果白费。

现在可以让 Architect 智能体发挥其多智能体架构的能力，做一下 Deep Research 工作，确定技术选型。Architect 能够根据你的研究选题，多轮调用最适合的 Subagent 去进行调研，在这里使用的是 WebSearch 智能体。WebSearch 也有各种调研的角度，进行多轮的搜索。最终 Architect 根据所有结果，综合给你一个报告。

Case2：通过多智能体协同完成数据分析与交互

作为产品经理，在工作中有些使用 SubAgent 的心得：可以把自己平常一些任务进行拆解，将工作流定义成 SubAgents，再交给 Architect 调度。比如说需要对原始工作数据进行二次加工，并进行一些分析。就可以先定义一个数据分析师智能体，让它按照平常处理这些数据的方式处理。相当于把自己原来的工作流程总结后自动化了。

这里再教卷王同学们一个进阶操作——汇报的时候光展示 ppt 已经是常规操作了，显得没那么亮眼了？开始上互动网页！我们可以设定一个 “交互式网页生成智能体”，让它来帮我们生成交互式网页。从此，你的汇报展示更上一层楼！（Prompt：拖入文件， 输入 "分析一下文件中的数据，并生成一个交互式的网页展现报告"）

👉观看视频版https://live.csdn.net/v/494504

可以看到，我们最终效果是一个可以互动的，鼠标悬浮有对应动态效果的展示报告。还综合了相关的判断结论，一起展示在一个网页上。

Case3：通过多智能体协同，“自我对抗”提升代码质量

Comate 有不少专业开发者用户在日常工作中会遇到很多复杂的编码场景。作为产品研发人员，有些进阶使用技巧可以分享～在平常写的代码有的时候总有点“自家孩子滤镜”——总觉得自己写的很优雅很好。如果去读别人的代码，则会直接锐评：写得真烂！但是看自己同样烂的代码就看不出来。

可以定期让 AI 帮优化一下，定义一个 Linus 的赛博分身来专门喷人，这是我从网上看到的别人写的智能体的提示词，可以把它抄过来，放到自己的自定义智能体里。要注意一下，提示词不支持 emoji，所以如果里面有 emoji 得手动处理一下。然后定期让 Architect 安排这些智能体优化一下自己的代码库。（输入“锐评一下这个代码库，给出改进意见，等我审核确认后，按照最终意见修改这个这个代码库”）

👉观看视频版https://live.csdn.net/v/494505

之前的直播《职场新人》那一期也说过可以让 AI 来帮优化，当时还没用多智能体系统，和现在说的优化是有区别的。当时那一期的优化还只是单智能体系统，所以只能分析一个文件的内容。现在有了多智能体系统，锐评时 Linus 赛博分身阅读文件、探索文件的内容完全限制在了 Linus 自己的上下文中，最终只有和 Architect 的交流，告诉它问题的点以及对应的文件之类的信息。就可以极大节省 Architect 自己的上下文，也让 Architect 的注意力不会被其他信息干扰。才能在第一个锐评阶段后，让它再调用 Actor 修改相关内容。

当时智能体的锐评远没有这么犀利，因为当时没办法修改智能体自己的提示词，只能用通用智能体的提示词。通用智能体的提示词为了兼顾各种任务，在单一任务上的表现并没有很强。但现在可以自定义 SubAgent，并且通过 Architect 来调用，就可以针对每一类任务去写针对性提示词。在模型能力还没有足够强大的今天，这样的解决方案无疑是更好的。

四、直播 Q&A 精选

Q1：多智能体系统这么好，有什么缺点吗？

A1：token 消耗量、时长。所以尽量在复杂场景下再使用这样的模式，这样才划算。

Q2：对于个人使用 architect ，有什么好的建议吗？

A2：整理自己的各种工作流，把它们变成多个 SubAgent，然后让多智能体系统来协作完成。

Q3：怎样看待 Anthropic 和 Cognition 关于多智能体系统的争论？

A3：其实殊途同归。Anthropic 在 <How we built our multi-agent research system> 里写了他们如何构造一个多智能体系统来支持他们的 deep research 功能，取得的效果相比单智能体提升巨大。Cognition 则在 <Don’t Build Multi-Agents> 中说他们在构建 Devin 时意识到了 Multi-Agent 的系统架构在共享上下文、对任务处理的一致性上会存在很多问题，所以他们不建议用 Multi-Agent System。

两篇文章我都看过，觉得其实是殊途同归。他们都意识到了多智能体系统的好处，以及多智能体在完成任务时存在的缺陷。但一个团队更看重智能体的成功率、稳定性（因为 Devin 定义是一个可以完全脱手托管的 Agent），Anthropic 则是追求极致的性能，所以花了很多工程上的细节把这个问题压制住了一部分。

我们在实践过程中也遇到了他们提到的那些问题，我们考虑还是追求更加极致的性能，所以选择了 Multi-Agent 这样性能更好的技术架构。我们也通过当前的一些技术手段尽可能地维护住 SubAgent 之间的共同协作能力。比如说之前所提到过的共同文件技术，就是我们给出的方案。

Q4： 智能体太多了记不住什么是做什么的，怎么办？

A4：一个是智能体有一个描述，会描述他是干嘛的，鼠标放上去也会有提示。另外，其实可以它们全部都作为 Architect 的子智能体。Architect 来帮你选择用哪个 SubAgent 来完成相关任务。相当于有了一个管家，比较省心。

Q5：未来发展方向？

A5：算法老师个人觉得 Agentic tools 是一个值得尝试的方向。首先明确一下 Agent 和 Workflow 的区别：Agent 可以【自主】决策完成任务，可以处理【非预期】的结果，但是这也带来了不稳定性。Workflow 胜在稳定，但只有一些固定的模式。算法老师觉得将来的工具会越来越发展，慢慢集成到一个对应类别的 SubAgent 中去，直至变成 Agentic 的工具。这样就能比一般的 tool 能处理更多边界条件，覆盖更灵活的场景。