佬友们认为强模型决策，弱模型执行，多agent协作在当下的可行性如何，其能力是否被夸大了？

我觉得还是要看你对比的双方以及你的预期吧。强模型决策、弱模型执行的替代场景应该是全部用强模型或者单agent框架，那么在这种对比下，还是有收益的。相比前者成本降低，相比后者节省时间，但是指望它是最优解不太可能，毕竟框架和模型都没有针对这种场景特化过，而且这里工程上的细节应该很多难度应该很大，毕竟现在多agent协作也没有标准答案，OpenAI搞的多agent探索数学题，成本如此之高，大概率也是因为踩坑无数。

其实仔细想想，这何尝不是另一种降本增笑

也就devin这种的还能看看，剩下的子代理如果不是主代理和子代理有巨大的速度差距那就不值得开，点名沟槽的oai

多agent只有，预测这个任务上下文感觉要爆了，不得不派多个agent的情况；需要上下文隔离的情况。要不然派复杂的多subagent其实效果不一定就好。因为现在模型能力越来越强。本质上agent的管理就是上下文的管理，派越来越复杂的多agent，信息损失会倾向严重

我在一直使用6.1sol强度medium，指定的执行计划感觉可以，但是最后的执行结果有时候确实是有偏差的。。

我测过类似内容，结论就是分任务…编码时最好不要用agent去做局部功能，agent是基于主控给的提示词进行工作，但纯摘要文本内容无法让agent模型准确理解用户意图…

之前和opus讨论过这个，它找了篇论文说可以在启动agent时复制主控上下文，然后将需求附加到最新的agent user message里，效果其实不错，并且能吃到主控的上下文缓存，但实际使用几次后发现还是有问题，1是要吃主控缓存，就必须和主控参数一致，但一致后，多agent就会让缓存分叉，轮数多了就疯狂掉缓存。2是很难把握住要给agent多少主控的上下文才够，我自己的实验里是最近1轮次 + 20轮以内用户输入/助手输出文本，上限20k tokens…

主要是，你哪怕主模型制定的计划效果很好，最后真正决定执行效果的也依然是子模型。那如果子模型本身都能做的好的话，那主模型存在的价值其实就显得很微弱了，或者说，它在整个链路中发挥的作用，其实比想象中的要少。

佬友可以分享一下论文吗？^-^

其实我反而觉得是反的，（免责声明，我不从事coding相关，只偶尔搓个小玩具）。我现在反而感觉和中低思考强度模型一起讨论想法，再让高强度模型去执行是一个更高效且能让我的想法得到高质量实现的方法。最好这种中低思考强度模型是说人话的，然后再让astra这种去执行。

这样的好处有二：第一点就是快，低强度模型又快又说人话的话可以和你边聊边想，你的思绪就整理出来了，就像有一个人和你瞎聊一样。第二点就是说人话，面对astra这种模型你不可能和他讨论idea的，又慢又重，而且高强度模型执行力又可以保证实现度。

不如把任务拆小多开几个会话

真人已经应证过沟通效率低下的事情，不用ai来验证了

就小任务而言，这确实是很好的方法。毕竟你不能等着旗舰模型给你按100tks的速度输出答案，Sonnet模型去聊天或者是其他中等体量的模型，然后让Astra去干活还是很可以的。

可能要多轮验证子代理的能力，才能分派合适的任务，如果是小任务很多，确实会省token吧，但小任务多，也不需要大模型介入了，感觉很矛盾别扭

可行肯定是可行的，但是你要保证小模型的产出。你就得增加很多质量保证环节。会导致小模型的交付周期和token用量一再膨胀。而考虑到缓存时效性和审查返工再审查的问题，SOTA模型这里也不一定会省token。

强模型给开发文档，弱模型做执行。首先你要给出强模型足够的开发框架。

弱模型按照功能执行简单代码。

这个方案目前看我觉得是比较节省token得。因为如果直接用强模型执行，会反复读取很多次上下文。但是弱模型怎么读都比较省，他自己怎么浪费怎么检查修改都不怕浪费。出错了或者修改都在弱的上面执行。包括跑测试用例也是若模型来做。最后再让强模型收尾检查。这样强模型只做了规划和最终的检查 属于只执行了两次。中间的过程弱模型都能处理了。

你所谓的弱模型会把偏差传递给主模型这个环节也不存在呀。主模型是建筑工程师，弱模型是工地搬砖的，怎么搬砖弱模型肯定会呀。按照图纸来就行了呀