书接上文，作为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站！
11 个帖子 - 1 位参与者