Agent 的默认答案是「再加一个文件」：41% 的复杂度上涨，和四条压回去的路

Wed, 21 Oct 2026 06:50:00 +0800

周三下午两点，你让 Codex 给后台加一个导出订单的功能。二十分钟后它交活：测试通过，顺手把 lint 也修了，PR 上是 6 个新文件、+840 行、-12 行。

你扫了一眼，觉得挺利索，approve。

问题在于 src/utils/ 往外数三个目录，两年前就有一个 export/csv.py，做的就是这件事，连字段映射都差不多。Agent 没见过它，也没找过它。它只是按最省事的方式把活干完了。

单看这一次，没什么关系。这样的事发生八百次之后，你的仓库会变成一个只有 agent 敢动的地方。

数字比感受更刺人

2026 年 MSR 会议上，He 等人交了一份用双重差分设计做的研究。样本是 806 个开源仓库，把采用了 Cursor 的仓库和匹配的对照组放在一起比，结论扛住了他们做的每一轮稳健性检验。

环复杂度平均上涨 25.1%。同一份研究里，整体代码复杂度的涨幅是 41%，静态分析告警多了 30%。速度提升是真的，但只在短期，复杂度是留下来那个。

GitClear 从另一个角度看到了同一件事。他们分析了 6.23 亿次真实代码变更，对比 2022 年的基线，八项可维护性指标里没有一项是往好的方向走的。转折点很明确，AI 辅助提交占比越过 25% 之后，所有信号同时掉头。

中间那三行才是要害。不是代码总量变多了，是新写的代码几乎不跟老代码发生关系。重复率涨 81%，跨文件调用掉 35%，这两件事本来就是同一件事的两面。

三个原因，全都跟模型聪不聪明没关系。

它看不见。 272,000 token 的上下文窗口装不下一个中等规模的仓库。当它看不到三个目录之外那个已经在做同样事情的函数时，能选的只有自己写一个。这不是推理出错，是信息没到手。在一个不完整的世界观里，写新函数就是最优解。