多agent协作，研发流水线交流！

佬友，是基于langchain开发的嘛

不是，编排系统纯自研的，cli是用的openclaw的pi agent

生产系统不敢用吧 自己做些工具还可以 但自己做工具也不用这复杂流程

春节的时候就搞过，结果就是上下文混乱了，无效沟通，我反正觉得多agent是无效的副作用。

一个上下文内，multi mode比multi agent更适合

这么多agent 你一个小问题都得跑半天，不太建议吧

我觉得你应该再来一个agent，作为项目“主管”，看看到底该用哪些“员工”

佬, 以后会开源吗? 如果要优化整个链路的话, 可以先做一版评估, 看看结果, 然后根据结果来优化

就是生产级的，个人没有必要折腾了，单agent加工作流就搞定了

不需要关注跑的时间，效果是他能自己完成开发＋测试，达到上线要修，肯定要比开发＋测试的工时要少的多

请教一个问题，如果只是让不同模型开圆桌会议，应该向哪个方向学习开发？

按照人的工作职能去拆分智能体，感觉就像软件架构演进一样，单体，微服务，领域，中台什么之类的，没有最好的，注意看需求。具体指是用token做了重复的工作，还是说编码之后进行测试浪费部分的token（代码是没问题的）。

我就四个……

plan、build、review、探索

部署、测试咋不上工作流捏，

一个tdd测试 一个主agents 多worktree 然后一个量化交接模板 架构设计啥的直接调用子代理 重复造轮子没必要 最初我单子代理都配置角色 后面发现 每个子代理要基于上下文 消耗很大啊 还不如用过文档交接 类似于拆分目标 标准可量化 分步去执行啊 思路是这样的

上下文混乱是没做好交接，我用消息总线做的agent解耦，通过过程产物来传递，目前没有发下有混乱的情况

我最近也在建agent工作流，最大的问题不是你agent分工细，

而是人要监督的注意力被分散，组合的复杂度提高，

问题不在分工上，而是你能同时handle多少agent

要先处理自己能处理多少复杂度的问题，先接受不可能一开始就全自动

再来才是做好沙箱隔离，上下文控管，工具调用透明那块

看着很像这个https://cto.new/business/marketplace/engineering-team

对于用户来说就一个入口，流水线的协作他们不需要关心，只有需要人审的时候才会参与

其实是这样，只是我把流程固化成了一个编排系统