使用多 Agent 协作三个月后，我复盘出 5 个痛点和 2 个心得

多agent协作用的也挺久了，优缺点还是很明显的，以下五个坑大家可以对照一下，看自身是否存在这些问题，还有两点心得，可以给大家带来一些感悟。

** 痛点一：Agent 之间产生矛盾，越往后越难合并**

• 同时开三个 Agent，产品、后端、前端各自独立工作。

• 跑完之后发现产品 Agent 和后端 Agent 对同一个功能做了不同的假设

• 一个认为用户自己配置 webhook，一个认为系统统一管理。两边都没错，但合并时只能选一个。

• 原因不在 Agent，在需求。需求里写的是“处理 webhook“，太模糊。每个 Agent 在各自上下文里填了自己的假设。

解决方法：

• ** 每次开 Agent 前把约束写死。**

• 不是“处理 webhook“

• 是“webhook 由用户自己配置，Agent 只负责检测是否配好，异常时通知用户去配置“。

• 超过三个 Agent 之后这种矛盾会明显增加，需求里的模糊之处被放大，Agent 只是帮你提前暴露问题。

痛点二：Agent 系统性跳过边界条件

• Agent 的目标是完成功能，不是找出功能在什么情况下不该执行。

• 让它写一个检测循环，正常路径很快写完了。

但它不会主动想：

• 同事请假没有 commit 记录怎么办、

• 私密频道读不了怎么办、

• 周末没数据怎么处理。

这些不是能力问题，是 Agent 的设计目标决定了它往前看，不往边缘看。

解决方法：在需求里单独列一节“边界条件“。

• 写具体的，不写笼统的。

• “最近 24 小时无 commit，跳过本次检测，标记为空日”。

• “频道标记为私密，跳过，日志记录原因”。

• “当地时间 22:00-08:00 的消息不参与自动报告”。

• 不要写“做好错误处理“，Agent 听不懂。

痛点三：自己审查自己等于没审查

• 同一模型写代码，同一模型审查代码。

• 写代码时忽略的假设和盲点，审查时继续忽略。

• 我试过几轮，没一次审出过实质问题。

• 不是模型不行——是它不会挑战自己做的假设。

解决方法：

• 单独开一个审查 Agent，

• tools: Read, Grep，

• 只读，无写权限。

• 任务只有一条：找出产出中的问题，不提供解决方案，不改代码。它不知道你的原始意图

• 这恰好是优势。你的隐式假设只要没写进文档，就会被它标出来。

• 它帮我找到过没处理的数据空窗期、没跳过的受限频道、差点被自动发送的内部消息。三个月下来这是唯一一个一直保留的 Agent。

痛点四：合并决策只能人做

• 两个 Agent 产出互相矛盾。

• 一个倾向全自动处理，一个倾向人工审核。都正确，都能讲出道理。

• Agent 可以列出各自利弊——自动节省时间但风险更高，人工更稳妥但响应慢——但选哪一个不是技术问题。

• 这个选择涉及你更在乎什么。快还是稳。覆盖面还是准确度。

解决方法：

• 这个没有自动化方案。把两种路线各自的代价看清楚，然后选。

• 如果两个 Agent 产生矛盾，说明这个决策点本身就存在需要权衡的东西，Agent 只是让它提前暴露了。不是坏事。

痛点五：Agent 压缩了执行，但暴露了更难的事

• 以前写初稿、整理竞品、调布局这些占掉大部分时间。

• 忙到晚上觉得做了很多事。

• Agent 一个下午把这些做完之后，下午三点，面前是两三个需要判断的选择、Agent 处理不了的边界设计、获客方案、方向性问题。

• 这些事情本来就在。只是以前被执行的忙碌盖住了。Agent 把执行压缩了，更难的事提前推到面前。

解决方法：

• 把省下的时间用在 Agent 碰不到的地方

• 合并决策、产品方向、边界定义、获客。

• Agent 能做的部分以后还会更便宜。不能做的部分才是你的时间该去的地方。

两个心得

一、最值钱的 Agent 不写代码。

• 只读审查 Agent 是我唯一没降过频的。

• 它不欠任何 Agent 人情，不理任何目标，只负责说“这里有问题“。

• 几个月下来帮我拦住的问题比所有写代码的 Agent 加起来还多。

二、Agent 之间产生矛盾不是 bug。

• 以前我觉得 Agent 互相不能看上下文是限制。

• 现在发现它们产生分歧的原因恰恰有价值——说明需求里有没写清楚的地方。

• 两个 Agent 对同一需求做了不同假设，回头改需求，下次就没了。Agent 帮你找到你没说清楚的话，这件事本身就有用。