佬们觉得多Agent协作有意义吗

意义不大，最大的好处可能是可以节省上下文吧

我理解应该只能节省主Agent的上下文吧，上下文现在应该不是使用的痛点，如果上下文不够的话一定还是任务太大了，可以自己再拆？

唯一的好处就是方案写好后，前后端可以并行稍微省点时间

把 BA、前端、后端、测试等角色分别分配给不同的 Agent，让它们各自负责对应的开发工作。我感觉这种方式意义可能不是很大，尤其是同一份信息还需要让每个 Agent 都了解，这样 token 消耗也会很大。

如果按照这样划分角色/agent，我感觉多agent意义并不大。好多任务之间有依赖关系，工作流需要是串行的。

项目一大，子代理是必须的。一个会话上下文不够读完项目，几乎都是转成建立验收标准来跑多子代理。

主agent负责规划、统筹、决定。子agent负责单个模块处理。数据验证或计算时并行多个子agent跑。但目的都是为了减少主agent上下文臃肿带来的降智和token消耗问题。

主要是目前的multi-agent 算法方面研究也不是特别多，而且一般用multi-agent 是用token 来换时间的，效果并不一定比single agent的强

我感觉是节省时间，串行和并行，还是有区别的

有实际跑起来的例子吗，token消耗降低这块我还不太能够理解，多个子Agent要获取上下文这个不应该会消耗更多的token吗

token消耗是降低的。原理得从无状态LLM开始解释。

ai每一个调用和返回都是重新提交了会话，一个会话可能刷新100次甚至200次。

最开头的内容就被重复100次，最后面的重复1次。

对于子agent，可以这样理解，主agent在多轮会话里已经积攒了较多的历史记录，此时使用子agent去进行一些任务，对于子agent是不需要携带主agent的历史记录的，这样是可以减少为了完成这个任务造成的token消耗，同时可以避免历史上下文造成的影响，专注于主agent要它完成的任务。

我觉得最大的用处可能就是减少主agent的上下文；其它没有什么特别的用处：

现在的大模型本就是多模态的大模型，各个方面的能力都很强，尤其在编程方面，前端、后端、嵌入式等等，各种语言各种算法都会，就像一个全能的工程师啥都会，还有必要像人类一样各司其职把活分给不同的agent吗？主要是你调用的agent背后都是同一个大模型，除非你用opencode这种给不同的agent配置不同的模型，比如前端用gemini，我觉得才有点意义，因为gpt的前端真的是太拉了（指的是UI/UX)

这个能理解，相当于起的子Agent是不会把历史上下文都带进去的，状态比较干净

我理解是对能力不强的模型更重要？

可以通过角色划分来要求一定执行特定流程，可以更好强调方向避免走偏

而且会和楼内同步的一样避免单一agent塞入太多无关上下文的注意力漂移问题

是的，我也是觉得按角色拆分意义不是很大，除非像copilot cursor这种内置Agent流程的，可以把不同的任务交给不同的模型来处理，可能效果会好一点

多 agent 最有价值的我觉得应该是方案决策、问题排查这些场景，单个模型会有忽略和幻觉，多 agent 把这个最大的问题解决了。比如每次生成设计方案后都让其他 agent 审查一次，总能提出没有考虑到的点；或者是代码执行后的审查，两三个 agent 以不同的视角针对改动进行审查 。

单独执行的场景我觉得直接丢给 flash 这种又快又听话的模型就行了，上下文够就直接全跑，不够就分一下

怎么个协作法？我平时是为了节省token，让codex去写计划方案，然后让mimo执行，最后codex审核，审核改动的点在继续让mimo执行写，不然全部让codex写太贵了，哪怕是gpt5.4mini

见仁见智吧，你不妨尝试一下呢？单 Agent 和多 Agent 我都用过，codex 就是典型的单 agent，claude code 的 workflow、opencode 的 ohmyopenagent 就是多 Agent，你问的问题做工程实践的也能想到。你哪个用的顺手就用哪个。不过我觉得你应该把多 Agent 理解为一个函数调用的过程，是需要传递一些上下文，但是专用 agent 是有好处的。比如 ohmyopenagent 就是对 git visual 等任务做了特化的 agent，你可以做专门的提示词优化。

我是用不同的agent，然后很多人用claude code配置内置agent智能体是什么概念，具体还不太懂，想要阿里qoder专家团的概念做是最好