都2026年了，多agent协作完成复杂任务，大家有什么好的方案？

蹲一个等看看大家的答案，可能是可以尽可能的用各种不同模型的优点？

我牢记了站内一位大佬的忠告

有偏差的，有错误的，不要改

直接回滚

重新优化提示词，强调好约束再执行

这坑我踩过。方案写太长，执行的那个就开始自己脑补，验收再甩一堆问题，上下文越攒越歪。

我这边现在方案只留接口、边界、不能动的文件，执行的只许改指定目录。跑歪了直接回滚，提示词改完重来，别在长对话里修。

你们方案一般写多细？

“代码是很便宜的”，有了约束边界之后写代码是很简单的事，所以应该花最多的时间在制定边界上

team订阅有什么强制规则吗？老哥们有路子吗

ccg，佬友开发的。一个claude一个gpt协作，足够了。

我现在感觉码代码不是问题，最大的问题还是spec要详细，我一般都用gpt pro来搞蓝图和spec，整个逻辑自洽了再来开发，中间开发的小问题模型自己处理下。

主要是把验收标准，设计逻辑要说得通，但是对于一些大型架构多少会有一些breaking change的时候，因为你不可能想的太全面。

现在spec一个版本就几千行，非常详细，还带伪代码，目前实践下来十万行左右项目没任何问题，就是2个subagent互相干，一个实施，一个review，一个主agent兜底看看review的成果。

饭要一口一口的吃, 别一口气吃成胖子, 如果太复杂就拆分任务, 多开几个会话完成, 并且推荐用grill-me这个skill, 让ai理解清楚需求再写代码, 而且我记得好像是之前看到一个帖子是说一次生成的代码比生成之后在改的代码代码质量要好, 所以最好写清楚一口气实现

建议不要搞一次性的复杂任务，现在ai的边界是就是一个个feature来做，复杂任务你不管怎么写方案实施都会偏差，多agent只会加剧这个情况。human in loop是必不可少的，随时纠正随时新开线程甚至随时回滚重做。

如果真的能一次性完成复杂任务，那就没发解释现在ai人才越来越贵的现象。

现在的多agent感觉还是一坨啊

要效率没效率

要能力没能力

要经济没经济

这是我的方案~

https://linux.do/t/topic/2827579/14?u=flyingmoon

不是专业码，所以我方案一般是写清除需要的功能，用到什么技术栈就不清楚了，不过ui方面我会自己挑，然后让他用ui库，因为不是专业码，很笨的就是很多市面上都有的ai在哪里自己想着瞎写，我就会规定，让他去找类似的成熟项目，用了什么库让他自己调用不要自己写 ^-^之前看过那种ai编程规范的skills啥的但是也没去用过

方案也是gpt自己写的，一般会比较长，约束我看起来算是比较清晰，但是总会跑歪了。。

我自己就在做多agent协作的harness,个人觉得多agent协作就是流程编排,人应该负责制定和调整流程方向,流程本身应该由agent来生成.

另外发散一下,多agent编排,最终的方向可能是中心化的流程聚合和去中心化的多点协作,重复的流程经过固化后可以形成稳定回路嵌入到另一个流程中.

人在回路的流程节点会变成数据慢慢被模型本身吸收,最后变成稳定的回路由模型包圆,人类作为frontier向圆外探索不停拓展圆形边界.

spec

请问佬说的spec是指啥？

subagent和主agent是通过什么调度的 啊？

不是程序员，只会调ai写小玩具。我的体验似乎也是这样，一开始功能没做好没做全，不要让模型在原来的基础上改，能推倒重来最好推倒重来 ^-^

多Agent是建立在模型智能同级的情况下，而不是强模型带弱模型，这就跟木桶效应一样，抱着节省成本的目的带个弱模型干困难任务绝对漏水

我已经差点把自己玩报废，我一直在改自己本地的herness，最后发现，简单提示词约束，限制上下文，好像其实就能搞，给个路由规则去控单个Agent的输出上限，，拆出来好像就可以

spec就是开发计划，非常详细的开发计划，包括整个架构，接口，函数，方法都要列出来。

我用pi，subagent和主agent直接就是rpc调用，主agent直接rpc一个subagnent来执行该计划，做好纵向切分，一个功能一个功能的实施，实施完在找另一个subagent来review。

我自己coding了一个pi的subagent的tool，支持有状态的subagent，多次派发调用同一个subagent是自带context（session不变）的，这样也有一定的延续性。否则每次调用subagent都是无状态的，即便给subagent提示词非常详细，subagent仍然习惯性的读整个项目，会导致注意力分散。

供参考哈