多agent协同，真的有效吗？消耗32亿token，跑空3个不同厂商的高级会员，但是我们都错了
- 内容介绍
- 文章标签
- 相关推荐
书接上文，作为ai小白的我，利用openmoss，开发了一套自己的多agent写作流程，使其解决长篇小说写作中遇到的几大难题。但是实际上，随着我对ai产品使用的深入，以及用途的多样化，我越来越肯定，多agent协作流程，在大多数场景，只是一个美好的空想。
先抛论点，再说论据。在绝大多数场景，包括coding，写作，网站开发等等，所谓的每个agent独立提示词，干独立的活，最后汇总或者按流程层层交付结果的方式，除了额外消耗海量token以外，并不会给你带来更好的交付，甚至可能会完全偏离你的设想。
为什么会这样？因为所谓的多agent协同流程，是根据人类的能力边界，合作模式来制定的。在一个正常的多人合作流程中，人和人之间，可以通过会议，非正式沟通等方式，来修正偏差。人与人的结果交付，伴随着沟通，大家会不自觉的把所有流程，往主目标靠。人类需要分工的主要原因是：人的知识有限，专业能力有限，边界会很多。以后人基于对分工协作的直觉，策划了这么一套多agent协作的流程。但实际上，对ai来说，也是如此吗？
实际并不是这样。LLM的特性完全不同：同一个模型既能写PRD又能写代码，没有"职业边界"模型的瓶颈不是注意力广度，而是推理深度和信息完整性模型之间没有"文化"和"默契"来补偿信息损耗给Agent贴上"产品经理"的标签，不会让它更专业——但会让它拒绝越界。三省六部类的模式，从根本上，封死了ai最有价值的推理，发生在边界的推理。但这并不是最严重的问题。
最严重的问题在于，agent之间的交付方式。所有agent之间传递的，是结论，结果。但不交付推理过程。原始意图逐渐衰减，工作流越长，偏移越严重，最终得到的结果是：局部正确，但结果严重偏离。人会通过很多种方式来弥补信息损耗，但是ai不会，准确的说，是多agent协作系统不会。多agent系统大多数是单向传递，不会有沟通，不会有回头，自然也不会弥补信息损耗。
那么多agent协作真的没有未来吗？有未来，但不是现在这种模式。实际上看看头部的厂商，三家厂商实际怎么做的，当Anthropic、OpenAI、Google真正构建自己的生产级Agent系统时，他们的工程文档里几乎找不到"角色扮演"或"部门分工"的字眼。Anthropic：Context Engineering + 显式状态文件Anthropic内部把"Prompt Engineering"升级成了"Context Engineering"：问题不是怎么写好一个prompt，而是什么样的token配置最能产生想要的行为。在构建Claude Code和Research系统时，他们面对的核心挑战是：Agent必须在离散的session里工作，每个新session对之前发生的事情没有任何记忆。他们的比喻是"轮班工程师"——每个新班次的工程师到岗时对上一班的工作一无所知。解法不是让Agent扮演不同角色，而是：claude-progress.txt：一个跨session的工作日志，Agent在每个session结束时更新，下一个session开始时读取Git history：作为状态锚点，记录每一个增量变化Initializer Agent：只在第一个session运行，建立环境、展开feature list、写好runbook，供后续所有session使用图像关键洞察：推理链的连续性不靠模型"记住"，靠显式的外部状态来锚定。
上一段落标黑的内容引用了某博主的观点。实际上，为什么多agent协作，会这么流行？以为他满足了人类对于团队协作的想象。实际上，我们真正去执行复杂任务，或者长线任务时，就会发现，结果严重偏离，但是局部完全正确，甚至纠错，你都不知道从哪个地方下手。
至少从目前来讲，大于3个agent的系统，我都不会再轻易尝试。2-3个不同的agent协同，尚可以控制偏移问题，但更多，遇到复杂任务时，完全没有抓手解决问题，只能眼睁睁看着他往错误的方向跑。也许，后面会有更好形态的产品出现，但是现阶段，subagent，已经可以帮大部分小伙伴解决问题。听我的，不用再烧钱尝试多agent协同了，目前，此路不通。
学AI，上L站！
网友解答：--【壹】--：
观点很精彩，以前人们认为“你是产品经理”这样的角色扮演能够一定程度上增强大模型的能力（事实确实是这样），但是实际生活中最有价值的推理其实是存在于边界上，这样的分工思路忽略了这一点，但现在看来这一点很重要。前几天刚写一篇博客，里面也谈到了意图偏离的问题，您可以看一下 Stateless Agent Matters • ✨ EFLx ☁️
btw，佬觉得树状的异步 subagent 会好一点吗？比如，主 Agent 生成多个 subagent，一个 subagent 可以冷启动，或者基于另一个的结果继续工作，或者在一个 subagent 的上下文内继续工作；对于更大型的任务也许可以扩展成每个 subagent 都可以生成自己的 subagent。这样很大程度上能解决意图偏离的问题，因为每个 subagent 的任务都是按需派生出来的
--【贰】--：
幻觉是会好一些，但是理解偏差会更严重，不如sub agent
--【叁】--：
我个人理解, 说完全没用应该还是片面了, 大概是这块技术的探索还不够深.
subagent有用是因为其切实解决了子任务并发问题.
多agent真正的问题是结果不方便量化, 即你想说明多agent比单agent强, 你得拿出一套合理的评测体系, 量化任务完成度, 然后数据说明多agent比单agent强或者弱, 然后如果强的话强在哪个地方, 这些问题其实都没有被回答, 那做出来的结果自然就没说服力
--【肆】--：
准确的说，是现阶段用处很小，尤其是长任务、复杂任务的情况。但是多agent协作，本来就是为了这种任务而生的
--【伍】--： 小黄:
当然，其实我还没实际开发出这些所有，心里也没底，肯定需要花上很多时间，开发、调试，发现问题解决问题。
最后感谢佬友的分享！
黄老板对产品的打磨非常优质，我也在多次使用。我们可以多看到前沿的报告和研究，早点上蜂群架构，我个人认为这会是几年中多agent的最终形态！
--【陆】--：
这个能跑通，我说的是agent协同，你说的是独立agent跟人交互，两个概念
--【柒】--：
说笑话可能会稍微偏激了一点，技术进步的路线中，试错是非常关键的。试错产生的结果是具有价值的。目前来说，基于大模型本身的能力和限制，多agent协作只能说是满足人类的期待，但不具备实际很好的效果。
--【捌】--：
这问题前几天就在群里和佬友聊过了，现在的agent协同其实是一个笑话，多agent或者跨CLI本身就是一个错误的事情，因为这样做会产生一个不可避免的副作用，就是上下文漂移污染会话，一开始本来想让AI做一件简单的事情，用了跨会话或者多agent反而会污染AI最初判断，然后一步错步步错，到最后错的一塌糊涂。
--【玖】--：
我一直都不用多agent，直筒形完全满足要求。
--【拾】--：
session 不交付过程的问题，其实从本质上来说不可能解决的，因为多代理最根本的目的在于上下文的管理，也就是要节省上下文窗口的消耗，那么当结果给到 subagent 调用者的时候就必然要剔除掉 subagent 的原有的推理过程
所以我那篇博客里面说，大模型可以被训练成善于利用这样一个循环，熟练地获取上下文直到可以执行任务；而且要让上下文只能通过正常的事实来源而非人类的 memory 或 spec 去获取，这样哪怕过程和推理丢了也能拿回来，而这确实是在 Claude 模型身上能看到的能力/偏好
当然也有反例，claude code 原本流程是 Plan 之后清除对话内容、只保留 plan 然后开始执行，现在变成了不清除上下文，在原有 session 执行。所以一个 subagent 带着另一个任务描述在之前 subagent 的上下文之上，继续去做，这个也是可以有的
蜂群的实践其实我不太看好，我不太认为大模型，尤其是多个同型号模型，能产生集体智慧，因为大模型的输出是概率分布，一个模型对同样的上下文，越能产生不同的回复越说明他就是不擅长这个任务，所以生成的最高概率的回复的概率也足够低，才会产生观点不一的现象。大模型还是不擅长反思，因为后训练没往这个方向走，以前我记得有个团队，做了能自我反思几百次然后输出的模型，号称是推理模型之外的另一种 scale，但好像也没下文了
--【拾壹】--：
我觉得佬友说的很好哇，很好的观点，但其实我一直在我们内部说OpenMOSS没结束，只是一个最初的开始，你要说我现在在做什么？我在做与OpenClaw的快速对接模块，同时也留下了扩展其它平台的架子，之后可以持续扩展出对接别对Agent平台，再有，编排层是铁定要狠狠优化的重心，接着是唤醒方式(引入一套心的唤醒机制)，还有反馈层，记忆层，这些都是要落下来的。
当然，其实我还没实际开发出这些所有，心里也没底，肯定需要花上很多时间，开发、调试，发现问题解决问题。
最后感谢佬友的分享！
核心：优化！打磨！提效率！降token！
好帖，应该更多人看到！
--【拾贰】--：
诶佬友有看 kimi 最近的那个agent 集群吗，是不是原理差不多。我感觉写文档和 ppt 好用点。
--【拾叁】--：
ai 始终是随机的，他并不能像你脑子里的蛔虫，按着你自己的想法完全的去执行命令，然后你只能不断的引导引导，于是花的 token 越来越多
--【拾肆】--：
ai知道每一次出发的时候自己在哪就好。多协同我觉得可以解决一些幻觉或者理解偏差的问题？
--【拾伍】--： AlvinC:
Anthropic、OpenAI、Google真正构建自己的生产级Agent系统时，他们的工程文档里几乎找不到"角色扮演"或"部门分工"的字眼
简单总结一下就是 多 agent 协同的真正解法是增量记录，所有 agent 基于一份事实"日志"协作，并把各自的工作内容记录作为增量计入同一份事实"日志"
而不是鼓吹某个 agent 只负责统筹，某个 agent 只负责前端/后端 ，全都上下文互不相干
也就是所谓的 三省六部 类
--【拾陆】--：
kimi我订阅很久了，本质上来说，他那个是主agent调用subagent，最后汇总，跟我们讨论的情况不一样。我们说的是类似于三省六部这种，多agent协作流程
--【拾柒】--：
学习了佬，所以自媒体鼓吹的一个人+一群AI员工，是跑不通的吗？
--【拾捌】--：
是的，您最后这个例子我也有查到。但是从理论的角度来说，我非常看好这个形态，但是从落地的角度，可能还要经历技术的几次迭代。我关注您了佬友，多多交流，受益匪浅！
--【拾玖】--：
佬，我对照翻译，很认真阅读了您的博客。坦率地说，作为一个ai初学者（进入这个行业2个月），您的有些观点和描述对我来说还过于深奥。但是我总结了一下您的大概想法，以及您的问题。
关于博客里面提到的无状态，以及无状态的流程，现在跟多web已经开始实践了，方法和流程与您的描述不谋而合。主要在深度研究中，更常见。对于您的问题，异步subagent的方案，我还没有实操过。从直觉上来讲，这并不能直接解决偏移的问题。因为主agent分配任务，子agent冷启动的模式，太考验模型的架构和规划能力了。如果模型本身没问题，那还好。但是没有从根本上解决session只交付结果，不交付理解和过程的问题，这个根本问题，还是没得到解决。不过从最前沿的资讯来看，蜂群可以有效解决这个问题。但是目前还处于实验阶段。这个蜂群，不是我们之前说的蜂后指挥工蜂那种模式，而是工蜂个体影响整体的模式，量变群体产生智慧，有兴趣您可以去看看相关讨论和资料。
书接上文，作为ai小白的我，利用openmoss，开发了一套自己的多agent写作流程，使其解决长篇小说写作中遇到的几大难题。但是实际上，随着我对ai产品使用的深入，以及用途的多样化，我越来越肯定，多agent协作流程，在大多数场景，只是一个美好的空想。
先抛论点，再说论据。在绝大多数场景，包括coding，写作，网站开发等等，所谓的每个agent独立提示词，干独立的活，最后汇总或者按流程层层交付结果的方式，除了额外消耗海量token以外，并不会给你带来更好的交付，甚至可能会完全偏离你的设想。
为什么会这样？因为所谓的多agent协同流程，是根据人类的能力边界，合作模式来制定的。在一个正常的多人合作流程中，人和人之间，可以通过会议，非正式沟通等方式，来修正偏差。人与人的结果交付，伴随着沟通，大家会不自觉的把所有流程，往主目标靠。人类需要分工的主要原因是：人的知识有限，专业能力有限，边界会很多。以后人基于对分工协作的直觉，策划了这么一套多agent协作的流程。但实际上，对ai来说，也是如此吗？
实际并不是这样。LLM的特性完全不同：同一个模型既能写PRD又能写代码，没有"职业边界"模型的瓶颈不是注意力广度，而是推理深度和信息完整性模型之间没有"文化"和"默契"来补偿信息损耗给Agent贴上"产品经理"的标签，不会让它更专业——但会让它拒绝越界。三省六部类的模式，从根本上，封死了ai最有价值的推理，发生在边界的推理。但这并不是最严重的问题。
最严重的问题在于，agent之间的交付方式。所有agent之间传递的，是结论，结果。但不交付推理过程。原始意图逐渐衰减，工作流越长，偏移越严重，最终得到的结果是：局部正确，但结果严重偏离。人会通过很多种方式来弥补信息损耗，但是ai不会，准确的说，是多agent协作系统不会。多agent系统大多数是单向传递，不会有沟通，不会有回头，自然也不会弥补信息损耗。
那么多agent协作真的没有未来吗？有未来，但不是现在这种模式。实际上看看头部的厂商，三家厂商实际怎么做的，当Anthropic、OpenAI、Google真正构建自己的生产级Agent系统时，他们的工程文档里几乎找不到"角色扮演"或"部门分工"的字眼。Anthropic：Context Engineering + 显式状态文件Anthropic内部把"Prompt Engineering"升级成了"Context Engineering"：问题不是怎么写好一个prompt，而是什么样的token配置最能产生想要的行为。在构建Claude Code和Research系统时，他们面对的核心挑战是：Agent必须在离散的session里工作，每个新session对之前发生的事情没有任何记忆。他们的比喻是"轮班工程师"——每个新班次的工程师到岗时对上一班的工作一无所知。解法不是让Agent扮演不同角色，而是：claude-progress.txt：一个跨session的工作日志，Agent在每个session结束时更新，下一个session开始时读取Git history：作为状态锚点，记录每一个增量变化Initializer Agent：只在第一个session运行，建立环境、展开feature list、写好runbook，供后续所有session使用图像关键洞察：推理链的连续性不靠模型"记住"，靠显式的外部状态来锚定。
上一段落标黑的内容引用了某博主的观点。实际上，为什么多agent协作，会这么流行？以为他满足了人类对于团队协作的想象。实际上，我们真正去执行复杂任务，或者长线任务时，就会发现，结果严重偏离，但是局部完全正确，甚至纠错，你都不知道从哪个地方下手。
至少从目前来讲，大于3个agent的系统，我都不会再轻易尝试。2-3个不同的agent协同，尚可以控制偏移问题，但更多，遇到复杂任务时，完全没有抓手解决问题，只能眼睁睁看着他往错误的方向跑。也许，后面会有更好形态的产品出现，但是现阶段，subagent，已经可以帮大部分小伙伴解决问题。听我的，不用再烧钱尝试多agent协同了，目前，此路不通。
学AI，上L站！
网友解答：--【壹】--：
观点很精彩，以前人们认为“你是产品经理”这样的角色扮演能够一定程度上增强大模型的能力（事实确实是这样），但是实际生活中最有价值的推理其实是存在于边界上，这样的分工思路忽略了这一点，但现在看来这一点很重要。前几天刚写一篇博客，里面也谈到了意图偏离的问题，您可以看一下 Stateless Agent Matters • ✨ EFLx ☁️
btw，佬觉得树状的异步 subagent 会好一点吗？比如，主 Agent 生成多个 subagent，一个 subagent 可以冷启动，或者基于另一个的结果继续工作，或者在一个 subagent 的上下文内继续工作；对于更大型的任务也许可以扩展成每个 subagent 都可以生成自己的 subagent。这样很大程度上能解决意图偏离的问题，因为每个 subagent 的任务都是按需派生出来的
--【贰】--：
幻觉是会好一些，但是理解偏差会更严重，不如sub agent
--【叁】--：
我个人理解, 说完全没用应该还是片面了, 大概是这块技术的探索还不够深.
subagent有用是因为其切实解决了子任务并发问题.
多agent真正的问题是结果不方便量化, 即你想说明多agent比单agent强, 你得拿出一套合理的评测体系, 量化任务完成度, 然后数据说明多agent比单agent强或者弱, 然后如果强的话强在哪个地方, 这些问题其实都没有被回答, 那做出来的结果自然就没说服力
--【肆】--：
准确的说，是现阶段用处很小，尤其是长任务、复杂任务的情况。但是多agent协作，本来就是为了这种任务而生的
--【伍】--： 小黄:
当然，其实我还没实际开发出这些所有，心里也没底，肯定需要花上很多时间，开发、调试，发现问题解决问题。
最后感谢佬友的分享！
黄老板对产品的打磨非常优质，我也在多次使用。我们可以多看到前沿的报告和研究，早点上蜂群架构，我个人认为这会是几年中多agent的最终形态！
--【陆】--：
这个能跑通，我说的是agent协同，你说的是独立agent跟人交互，两个概念
--【柒】--：
说笑话可能会稍微偏激了一点，技术进步的路线中，试错是非常关键的。试错产生的结果是具有价值的。目前来说，基于大模型本身的能力和限制，多agent协作只能说是满足人类的期待，但不具备实际很好的效果。
--【捌】--：
这问题前几天就在群里和佬友聊过了，现在的agent协同其实是一个笑话，多agent或者跨CLI本身就是一个错误的事情，因为这样做会产生一个不可避免的副作用，就是上下文漂移污染会话，一开始本来想让AI做一件简单的事情，用了跨会话或者多agent反而会污染AI最初判断，然后一步错步步错，到最后错的一塌糊涂。
--【玖】--：
我一直都不用多agent，直筒形完全满足要求。
--【拾】--：
session 不交付过程的问题，其实从本质上来说不可能解决的，因为多代理最根本的目的在于上下文的管理，也就是要节省上下文窗口的消耗，那么当结果给到 subagent 调用者的时候就必然要剔除掉 subagent 的原有的推理过程
所以我那篇博客里面说，大模型可以被训练成善于利用这样一个循环，熟练地获取上下文直到可以执行任务；而且要让上下文只能通过正常的事实来源而非人类的 memory 或 spec 去获取，这样哪怕过程和推理丢了也能拿回来，而这确实是在 Claude 模型身上能看到的能力/偏好
当然也有反例，claude code 原本流程是 Plan 之后清除对话内容、只保留 plan 然后开始执行，现在变成了不清除上下文，在原有 session 执行。所以一个 subagent 带着另一个任务描述在之前 subagent 的上下文之上，继续去做，这个也是可以有的
蜂群的实践其实我不太看好，我不太认为大模型，尤其是多个同型号模型，能产生集体智慧，因为大模型的输出是概率分布，一个模型对同样的上下文，越能产生不同的回复越说明他就是不擅长这个任务，所以生成的最高概率的回复的概率也足够低，才会产生观点不一的现象。大模型还是不擅长反思，因为后训练没往这个方向走，以前我记得有个团队，做了能自我反思几百次然后输出的模型，号称是推理模型之外的另一种 scale，但好像也没下文了
--【拾壹】--：
我觉得佬友说的很好哇，很好的观点，但其实我一直在我们内部说OpenMOSS没结束，只是一个最初的开始，你要说我现在在做什么？我在做与OpenClaw的快速对接模块，同时也留下了扩展其它平台的架子，之后可以持续扩展出对接别对Agent平台，再有，编排层是铁定要狠狠优化的重心，接着是唤醒方式(引入一套心的唤醒机制)，还有反馈层，记忆层，这些都是要落下来的。
当然，其实我还没实际开发出这些所有，心里也没底，肯定需要花上很多时间，开发、调试，发现问题解决问题。
最后感谢佬友的分享！
核心：优化！打磨！提效率！降token！
好帖，应该更多人看到！
--【拾贰】--：
诶佬友有看 kimi 最近的那个agent 集群吗，是不是原理差不多。我感觉写文档和 ppt 好用点。
--【拾叁】--：
ai 始终是随机的，他并不能像你脑子里的蛔虫，按着你自己的想法完全的去执行命令，然后你只能不断的引导引导，于是花的 token 越来越多
--【拾肆】--：
ai知道每一次出发的时候自己在哪就好。多协同我觉得可以解决一些幻觉或者理解偏差的问题？
--【拾伍】--： AlvinC:
Anthropic、OpenAI、Google真正构建自己的生产级Agent系统时，他们的工程文档里几乎找不到"角色扮演"或"部门分工"的字眼
简单总结一下就是 多 agent 协同的真正解法是增量记录，所有 agent 基于一份事实"日志"协作，并把各自的工作内容记录作为增量计入同一份事实"日志"
而不是鼓吹某个 agent 只负责统筹，某个 agent 只负责前端/后端 ，全都上下文互不相干
也就是所谓的 三省六部 类
--【拾陆】--：
kimi我订阅很久了，本质上来说，他那个是主agent调用subagent，最后汇总，跟我们讨论的情况不一样。我们说的是类似于三省六部这种，多agent协作流程
--【拾柒】--：
学习了佬，所以自媒体鼓吹的一个人+一群AI员工，是跑不通的吗？
--【拾捌】--：
是的，您最后这个例子我也有查到。但是从理论的角度来说，我非常看好这个形态，但是从落地的角度，可能还要经历技术的几次迭代。我关注您了佬友，多多交流，受益匪浅！
--【拾玖】--：
佬，我对照翻译，很认真阅读了您的博客。坦率地说，作为一个ai初学者（进入这个行业2个月），您的有些观点和描述对我来说还过于深奥。但是我总结了一下您的大概想法，以及您的问题。
关于博客里面提到的无状态，以及无状态的流程，现在跟多web已经开始实践了，方法和流程与您的描述不谋而合。主要在深度研究中，更常见。对于您的问题，异步subagent的方案，我还没有实操过。从直觉上来讲，这并不能直接解决偏移的问题。因为主agent分配任务，子agent冷启动的模式，太考验模型的架构和规划能力了。如果模型本身没问题，那还好。但是没有从根本上解决session只交付结果，不交付理解和过程的问题，这个根本问题，还是没得到解决。不过从最前沿的资讯来看，蜂群可以有效解决这个问题。但是目前还处于实验阶段。这个蜂群，不是我们之前说的蜂后指挥工蜂那种模式，而是工蜂个体影响整体的模式，量变群体产生智慧，有兴趣您可以去看看相关讨论和资料。