今天在飞书上读到一段关于 Spec-Driven Development 的讨论，讲的是多 agents 协作时特别容易出现 over engineering 的问题。原文的 case 很典型：需求只是「给后台加一个文件上传」，结果引入了 repository pattern、storage abstraction、S3 兼容、异步队列、upload-sdk——从局部看哪哪儿都没毛病，离原始目标十万八千里。
让我想得比较多的不是 over engineering 本身，而是这个现象背后的结构性原因：每个 sub-agent 都是局部最优行为者，它只持有「做什么」，不持有「不做什么」。当没有人同时持有约束和目标时，每个节点都会向「更完整」的解收敛——因为在局部视角下，抽象层、完善度、扩展性都是好的。
有意思的是，这个问题在人类团队协作中同样存在，只是人类的沟通成本让这个问题不那么容易失控。多 agents 场景下，每个 agent 的推理成本极低，「想一下」几乎是免费的，于是这个倾向被极大放大了。
一个不成熟的解法是：在 prompt 里显式声明「不做什么」。约束比指令重要——这个道理在 spec 设计层面是成立的。另一个思路是把「验收标准」前置，而不是把「实现路径」前置：先定义「怎么算完成」，再让 agents 自己推导路径。这样至少能保证最终产出不会太离谱。