出品 | 51CTO技术栈（微信号：blog51cto）
今年以来，多智能体（Multi-Agents）频频成为AI领域的热点话题。但现在，越来越多开发者发现，“多智能体协作”的酷炫演示，很多只是AI 的一场秀，并非切实可靠。
这两天，Reddit、X平台上关于多智能体的讨论再次甚嚣尘上。小编刷到一篇网友的帖子，他说自己做了超过25个Agent，为客户服务已经两年多，最后得出的结论是：很多人做的多智能体系统，看起来复杂、炫技，却没什么必要。
许多开发者也在网上表示，日常任务中没必要构建多智能体系统，不仅会提升复杂度，增加成本以及上下文传递时间，而且流程出问题时难以调试。
图片
另外，Cognition（知名 AI 编程智能体 Devin 的母公司）的创始人Walden Yan在其博客文章《不要构建多智能体系统》（Don’t Build Multi‑Agents）中指出，当前流行的多智能体范式（如OpenAI的Swarm和Microsoft的AutoGen）违背了认知可靠性的基本原理，他认为：
“2025 年的多智能体系统，本质上仍然脆弱、分散，决策不一致”。
那么，多智能体真的毫无必要吗？
1.“95% 的情况下，你根本不需要多智能体”
Reddit 上这位有 25+ 项 Agent 系统实战经验的开发者直言：
我理解，多智能体系统确实很酷。看着不同的 Agent 互相对话，就像科幻电影一样。但说真的，你们很多人造的东西更像是“AI版鲁布·戈德堡机器”——复杂、炫技，却没什么必要。
我为客户做 AI Agent 已经有两年多了。真正能赚钱、而且不会每周都出问题的那些Agent，其实都非常简单。
图片
他举了几个真实的例子：
- 一个读取邮件并自动更新 CRM 字段的 Agent（每月 200 美元，全天候运行）
- 一个帮招聘方解析简历、提取关键信息的 Agent（卖 50 美元/月）
- 一个只回答常见问题（FAQ）的客服 Agent
- 一个在评论上线前标记违规内容的内容审核 Agent
这些都不需要什么“多 Agent 协作”，不需要复杂的记忆系统，更不需要什么“研究员 Agent”、“写作 Agent”、“监督 Agent”互相开会讨论下一步。
而现在的AI Agent社区，很多人是这样的：本来只需要解决一个小任务，但看了 LangGraph、CrewAI 的介绍，就开始造庞大的系统：研究员 Agent、撰写 Agent、评论 Agent、监督 Agent 一应俱全。结果系统幻觉严重、丢上下文、每月光 API 成本就 500 美元，而其实一个精心设计的 GPT-4 prompt 就能搞定。
这位身经百战的开发者坦言：如果一个好的系统提示和单个 Agent 就能解决问题，那就别多此一举。每多一个 Agent，就多一个故障点；每一次信息传递，都是上下文丢失的风险；每一次“规划”步骤，都有可能出错。
他还分享了自己现在最常用的 Agent 技术栈：
- OpenAI API（没错，平平无奇）
- N8N
- 带示例的基础 prompt
- 一个简单的 webhook 或定时任务（cron job）
- 如果需要存储数据，就加个 Supabase
就这样。没有框架，没有复杂编排，没有长链路。
另一位开发者也发帖子称，他认为多智能体系统主要存在3个问题：
1. 协调开销毁掉了性能每一次 Agent 之间的交接都会增加延迟。我曾经做过一个包含 5 个专业 Agent 的内容生成系统，而单 Agent 版本做同样的事，不仅快了 3 倍，效果还更好。多 Agent 系统花在“传递上下文”上的时间，比花在“思考”上的还多。
2. 成本会爆炸每个 Agent 调用，都是一次新的 API 请求，而那个“规划 Agent”还得先决定该调用哪些 Agent。恭喜，你又多烧了一堆 token——干的活还不如一个 if 条件判断。我见过因为“多 Agent 协作”导致的账单直接涨了三倍。
3. 调试几乎不可能当一个 6-Agent 流程出问题时，祝你好运：是研究 Agent 输出错了？还是规划 Agent 路由有误？又或者上下文在交接时被破坏？
你不得不花上好几个小时，埋头翻日志，看着一群 Agent 在互相对话。
图片
而真正的问题在于，大多数任务根本不需要“分工”。
一个经过精心提示、拥有完整上下文的单 Agent，就能干好你硬拆成五个 Agent 的工作。
你不是在建汽车装配线，你只是在做文本生成和推理。就好比一个强壮的工人，胜过五个在抢同一个笔记本的专家。
2.多智能体架构违背「认知可靠性原则」
人工智能公司Cognition的创始人Walden Yan在其博客文章《不要构建多智能体系统》中提出了一个重要概念：「上下文工程」 （Context Engineering）。
这是继“Prompt Engineering（提示工程）”之后，Agent 时代的新核心能力。
Walden Yan指出，构建长时间运行的 Agent 时，最核心的问题不是模型是否强大，而是上下文是否可靠传递。为此，他总结了两条原则。第一，共享上下文。所有 Agent 必须共享完整的决策轨迹，而不仅仅是消息片段。
他举了个例子：主任务是“做一个 Flappy Bird 游戏”，结果一个子 Agent 画出了马里奥风格的背景，另一个子 Agent 做出了一只飞行不正常的鸟。如果不同 Agent 各自理解任务，那么最终系统输出的，只是把两个错误的东西拼贴到一起。
图片
第二，行动蕴含决策。每个行动背后都隐含着决策逻辑，如果多个 Agent 独立行动、互不协调，结果必然是冲突的。这就像多个编辑同时修改一篇文章，没有主编审稿，最后合并时发现风格割裂、逻辑不通。
最终Walden Yan得出的结论是：“多智能体架构天然违背了上下文一致性与决策可靠性。”这些系统看似模块化，实则极度脆弱，每一个误解、每一次遗漏的上下文，都会让结果偏离初衷。
图片
他认为，2025 年的多智能体系统，本质上仍然脆弱、分散，决策不一致。
值得一提的是，为了应用上述两条原则，Walden Yan提出了两个方案。一是最简单的方案，单线程线性 Agent。一个持续线性的 Agent，在连续上下文中决策与行动。这种方式稳定、可预测，足以支撑 90% 的应用场景。但当任务极大、上下文溢出时，系统会遇到窗口限制。
图片
二是上下文压缩模型，这也是Cognition正在做的事情。他们引入了上下文压缩模型（Context Compression Model），一个专门负责总结历史行为与关键决策的 LLM。
图片
它能把漫长的对话历史浓缩成核心要点，从而延长 Agent 的“有效记忆”，甚至可以针对特定领域微调一个小模型来承担这个任务。它的优点是支持更长任务，减少上下文负担，适合长任务（几十分钟甚至几小时）。
3.哪些任务适合用多智能体？
尽管很多人都在批评多智能体系统，但这也不代表多智能体一无是处。
那什么任务才适合多智能体呢？
Reddit上这位一开始大吐苦水的开发者指出，只有当你确实需要不同模型、不同能力时，多 Agent 才真的有意义。例如，用 GPT-5 负责推理，用 Claude 处理超长上下文，用本地模型处理隐私数据（PII）——这种才是真正的“专业分工”。
他还举了一个例子：
我做过最好的 Agent 系统，只有两个 Agent：一个负责干活，另一个负责核查输出是否符合严格标准——通过就放行，不通过就退回修改。
简单、高效，而且确实提升了质量，因为验证步骤能捕捉幻觉错误。
相反，则有网友提出，如果你的应用不需要大量分支式思考，也不依赖复杂的多步骤推理或多 Agent 协作，那多智能体系统就不适合你。
你应该把时间和预算都花在充分利用一次高质量 API 调用上，选择你能负担得起的最强模型。
尤其是在做 B2B/B2C 类生产力工具的团队里，高度分支化的场景极其罕见，很多时候任务的关键反而是降低分支复杂度。
图片
另外，也有网友认为，关键是明确并细化每个 AI 的角色，确保它们的工作不重叠。
解决幻觉的办法，不是多 Agent 网络，而是更清晰的角色定义。
我们该关注的重点是：让每个 Agent 自身更强，而不是搭建更多互相扯后腿的 Agent 网络。
图片
总的来说，“该不该构建多智能体”这个问题目前还是众说纷纭。
除了Coginiton，Anthropic和LangChain都是这个话题中的赞成派，分别发过文章《How we built our multi-agent research system》和《How and when to build multi-agent systems》阐述构建多智能体系统的经验和可行性。
两家团队最终都总结，只有当任务价值高、信息面宽且可高度并行时，多智能体的 Token “烧钱”才划算。典型就是广域信息研究，而大部分代码任务还不够“宽”。
聊到这里，或许你可能已经在心里默默数过自己项目里有几个 Agent。
这些 Agent 是真正需要的团队协作，还是为了炫酷的架构演示？欢迎在评论区聊聊——你见过最“离谱”的多智能体设计是什么？你又认为哪种场景下，它真的有价值？
参考链接：
https://www.reddit.com/r/AI_Agents/comments/1oheym9/stop_building_complex_fancy_ai_agents_and_hear/
https://www.reddit.com/r/AI_Agents/comments/1o5hvhm/multiagent_systems_are_mostly_theater/
https://cognition.ai/blog/dont-build-multi-agents#a-theory-of-building-long-running-agents
https://www.anthropic.com/engineering/multi-agent-research-system
https://blog.langchain.com/how-and-when-to-build-multi-agent-systems/
