多 Agent 的合作到底是不是一个伪命题?

目前个人用户组多agent唯一的优势就是成本吧 主脑用claude 下面的用各家flash之类的 真要是能力的话 不如claudecode或者codex自己启subagent 个人和专门的公司产品相比还是相差太多了

多Agents的意义是你的任务能拆分出严格的上下级或可并行的小任务，而不是让多个Agent干平级的活

我认为大多数基于先验角度而给Agent设计的workflow或者方案都是不可靠的，还是要花时间实际验证调整，不然很多时候不是1+1=2而是1+1<1

多agent，成本和效率都还是可以的

是趋势，只要限制的好，未来好多应用都不需要写代码了。直接多个功能agent协助传递。流式应用。

很喜欢用herdr让gpt和claude互相讨论方案来达成一致的工作模式，对于复杂场景代码质量有显著提升 （数据库内核相关

Oh my Pi

偶尔用，但是发现很多 flash 模型并不遵守 主脑规则，而且主脑最后做验收感觉也挺费 token，还不如直接让贵的模型全干

大家都想着是一个聪明的带动一些笨蛋，实际上笨蛋最后会拖垮聪明的

我觉得不同agent之间要建立持久化的沟通模式，比如数学证明系统Danus的fact graph啥的，不同成果的依赖通过有向无环图表达出来，这样主agent派发子agent包括子agent根据成果相互对话就有根据。

你要明确你用多Agent的目的，其本质是注意力的分配。

如果是一主多从式的多Agent，引入第二主体是为了节省那个第一主体的注意力，比如主任务做一个研究需要研究网页，知识库，书本PDF等，只用单一主体会让第一主体过于偏向某一特定阶段而冲散主要目标的注意力。并且由于自回归机制的存在，过于偏向研究比如网页，可能大量的内容在弄怎么查看网页调用工具上。会更为严重。

如果是多Agent平级的形式也是注意里分配，只是更加灵活。抓住这个点就能抓住多Agent的设计机制

我对多agent的理解比较浅显：单个agent完成一个大任务，上下文窗口可能不够用，压缩上下文可能导致信息丢失；把大任务拆成小任务给subagent，主agent只需要发命令、等结果就行了，对上下文窗口负担更小

很多方案看起来流程很完整：路由、拆任务、分角色、互相 review，最后实际跑起来就是 token 花更多、等待时间更长，而且上下文在不同 Agent 之间传来传去，信息多少都会损失一点。有时候一个强模型自己从头做到尾，反而更快更稳。

复杂研究任务用的，简单任务就没必要。

不知道佬用没用过 grok bot 我感觉里边多 agent 通信做的挺好的几乎可以约等于一个微信好友了，但是在合作开发上的话，claude code 给我的感觉就是多 agent 等于快速消耗 token 约等于 快。

在 grok bot 里我感觉多 agent 更像一个我定义好的某个领域专家或者权限 limit ，然后在我做一个大项目的时候就可以把涉及到的拉进来，然后各自做自己的部分就好了，重点是 grok bot 会保持 bot 存活，所以复用和记忆就是最大的价值

附一个我自己使用 grok bot 的案例：

其实把自己想成大老板就好啦，调度自己的手下干活这种场景，包括楼上也有很多说，注意力的其实也可以这么理解，任务拆分好了，各自只做自己的，会比脑雾的状态好

佬的回复很说到点子上。最近我这个项目经过长期开发，再加上天天跟 AI 聊天，自己也有点晕头转向，有些失去判断力了。

其实我的初心，就是想减缓主 Agent 上下文的增长。我认为 LLM 的底层原理很大程度上就是在控制上下文，你想对工作流进行任何优化，基本都要建立在上下文管理之上。

但后面我开始转向以主对话为主，让子 Agent 并行工作来提升任务完成速度，从这里开始，整个事情就逐渐失控了。

之前单个对话里，主 Agent 只是利用子 Agent 来减缓上下文的增长速度，出现的问题也比较少，就算有问题，主脑也能比较快地解决，整体效果其实还是不错的。

但是后来我想让主脑把任务全部并行起来，并且尽可能外包给子 Agent 去做，事情就开始失控了。问题大量出现，而主脑最后还是得回头去查这些问题到底是怎么产生的，再慢慢一个个解决。

所以我才逐渐意识到，这样的合作方式可能并不可取，甚至方向本身就是错的。

项目开发其实更偏向工程，如果你要做工程控制，还是让其写文档记录比较好。GitHub - LVincent555/PSDR-workflow: A human-in-the-loop, Git-native workflow for managing AI-assisted software development and research engineering. · GitHub （不知道违不违规）

既然是你手动控制项目，那不如像我一样让各种Agent共同维护一套文档工程。

PRB定义需求/问题

SUG定义各种方案/设计/实施计划

DEC定义架构约束/多Agent流程规划/项目目标

RES让所有的Agent留痕记录

P->S->D->R … ->P

这样让整个流程变成工程。当然我这个是草稿比较灵活

如果你懒，就是SUG和RES附带一些DEC做约束。