一、为什么是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 适合写高性能服务吗？" 它就会规划并协调相应子智能体完成任务。
👉观看视频版live.csdn.net/v/494503
为什么要做技术调研呢------其实写代码就像盖房子，开头打好地基很重要。软件工程也是这样，一开始做技术选型、设计基础架构就是打地基。之后所有丰富项目的功能、增加更多优化都是在往上盖楼。盖好了一定的楼层、加了一定数量的功能以后，就很难再改动底层的一些内容。如果非要改动，那么代价非常非常大。所以一个项目开始，或者一个新功能开始的时候，都需要做大量调研来做技术选型。技术选型其实挺难的，万一选错了就是整个项目组的人大量辛苦成果白费。
现在可以让Architect智能体发挥其多智能体架构的能力，做一下Deep Research工作，确定技术选型。Architect 能够根据你的研究选题，多轮调用最适合的 Subagent 去进行调研，在这里使用的是 WebSearch 智能体。WebSearch 也有各种调研的角度，进行多轮的搜索。最终 Architect 根据所有结果，综合给你一个报告。
Case2：通过多智能体协同完成数据分析与交互
作为产品经理，在工作中有些使用SubAgent的心得：可以把自己平常一些任务进行拆解，将工作流定义成SubAgents，再交给Architect调度。比如说需要对原始工作数据进行二次加工，并进行一些分析。就可以先定义一个数据分析师智能体，让它按照平常处理这些数据的方式处理。相当于把自己原来的工作流程总结后自动化了。
这里再教卷王同学们一个进阶操作------汇报的时候光展示ppt已经是常规操作了，显得没那么亮眼了？开始上互动网页！我们可以设定一个 "交互式网页生成智能体" ，让它来帮我们生成交互式网页。从此，你的汇报展示更上一层楼！（Prompt： 拖入文件， 输入 "分析一下文件中的数据，并生成一个交互式的网页展现报告"）
👉观看视频版live.csdn.net/v/494504
可以看到，我们最终效果是一个可以互动的，鼠标悬浮有对应动态效果的展示报告。还综合了相关的判断结论，一起展示在一个网页上。
Case3：通过多智能体协同，"自我对抗"提升代码质量
Comate有不少专业开发者用户在日常工作中会遇到很多复杂的编码场景。作为产品研发人员，有些进阶使用技巧可以分享～在平常写的代码有的时候总有点"自家孩子滤镜"------总觉得自己写的很优雅很好。如果去读别人的代码，则会直接锐评：写得真烂！但是看自己同样烂的代码就看不出来。
可以定期让AI帮优化一下，定义一个Linus的赛博分身来专门喷人，这是我从网上看到的别人写的智能体的提示词，可以把它抄过来，放到自己的自定义智能体里。要注意一下，提示词不支持emoji，所以如果里面有emoji得手动处理一下。然后定期让Architect安排这些智能体优化一下自己的代码库。（输入"锐评一下这个代码库，给出改进意见，等我审核确认后，按照最终意见修改这个这个代码库"）
👉观看视频版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在 里写了他们如何构造一个多智能体系统来支持他们的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能处理更多边界条件，覆盖更灵活的场景。