看似聪明的 Agent 方法论，可能是陷阱。少即是多。

前言

前几天在刷推的时候，看到了 cline 的开发者 Ara 提到的一段话。
他说，在构建 AI Agent 时，有三种听起来很聪明的想法，其实常常是「思维毒药」。

“思维毒药” 这个词总归怪怪的，我觉得“陷阱”这个比喻让我更有共鸣。因为这些思维确实很有吸引力，就像远远看去是一条捷径，但走进去才发现，里面布满了泥潭。

作为一个开发者，我一边读，一边在回想自己做 Agent 的过程——踩过的坑，走过的弯路，几乎都能在这里找到影子。

一、关于多代理编排

想象一下这样的画面：
有一支虚拟团队，里面有“分析员 Agent”“执行员 Agent”“总调度 Agent”。它们像人类小组一样，分工协作、互相传递消息，最后汇总出完美的结果。

听上去是不是很酷？我当初也实践过。

可现实是：大多数真正有价值的 Agent 工作，本质上还是单线程的。

复杂的编排，不仅增加了技术上的不确定性，还让我们更难解释模型的行为。
换句话说，它让项目背上了两份负担：实现复杂度 + 解释复杂度。

曾经做过一个 Team Demo 来完成 AI Coding 这件事，尝试用多个 Agent 分工协作。结果没走几步，就被“状态同步”和“出错恢复”折腾得焦头烂额。调试的时候，根本不知道到底是哪个 Agent 在搞鬼。

到最后，我还是把逻辑简化掉，留给一个更强的单体 Agent 去完成。意外的是，效果比多代理方案还要稳定。

二、关于 RAG 的补丁效应

过去两年，RAG（检索增强生成）几乎成了构建 Agent 的标配。好像不加上它，整个系统就“不完整”。

但真实的情况是：RAG 更像是一块补丁。
很多时候，一个简单的 grep 命令，或者一张设计良好的数据库表，就能解决问题。
如果你的数据和知识管理一团乱，RAG 只会把混乱放大，它不是万能钥匙。重要的数据，数据，还是 TMD 数据。

我刚开始用 RAG 的时候，觉得它是“救命稻草”。模型终于可以“记住”外部知识了。可随着项目复杂度增加，我发现问题并没有减少，反而多了新的麻烦：检索不准、上下文过载、延迟变高…… 慢慢我意识到：真正重要的，其实是信息组织方式。

三、关于「更多指令 = 更好结果」

还有一个陷阱，是很多人都会踩的：
我们常常相信，只要写更长、更详细的 prompt，模型就会更聪明。

现实往往相反。
长 prompt 增加了 token 成本，响应速度更慢，结果也不一定更好。更糟糕的是，它掩盖了真正的问题：模型本身的能力边界。

我刚开始玩 LLM 的时候，我也写过像“说明书”一样长的 prompt，把能想到的规则全堆上去。
但最后发现，简洁、清晰的三句话，往往比十段废话更有效。

现在我更看重的是 任务建模和上下文管理。
比如明确拆分任务，合理设计输入输出，这些往往比写一个“超级提示词”来得靠谱。

总结：少即是多

回顾这三点：

  • 多代理编排：是幻觉，现实里常常多余。
  • RAG：是补丁，价值有限，不该当成金科玉律。
  • 长 prompt：是迷思，解决不了模型的根本限制。

别被“听起来聪明”的概念绑架，真正有效的，往往是简单、直接、可解释的方案。
作为开发者，我更愿意拥抱这种“少即是多”的原则。
因为时间和资源有限，每一行代码、每一个设计选择，都需要指向真正的核心价值。