最近用ChatGPT、Codex处理真实项目时，我越来越明显地感觉到一个变化：

Agent不只是“帮你写代码”了，它开始越来越多地替你决定“代码应该怎么写”。

以前让AI改一个功能，更多像这样：

你已经决定好方案。

AI负责实现。

比如：

这个逻辑放Service。

这个接口返回什么。

这个模块不能动。

AI只是执行。

但现在很多Agent任务已经变成：

读项目。

理解需求。

自己选择实现路径。

决定改哪些文件。

判断要不要抽公共逻辑。

决定是直接调用，还是增加一层封装。

甚至自己选择：

新增Service。

扩展现有模块。

还是重新组织一部分代码。

单独看，这些决定可能都没有错。

问题出在：

如果几十个Agent任务，每一次都在做自己的“局部正确选择”，项目长期下来会不会慢慢变成另一套架构？

这就是我最近越来越关注的一个问题：

Architecture Drift——架构漂移

它不是某一次代码明显写错。

而是：

每一次修改单独都能解释，但整个项目逐渐偏离了原来的设计原则。

---

一、一个很真实的场景：每次Diff都合理，半年以后项目却越来越乱

假设一个项目最初的规则很清楚：

Controller只负责请求和响应。

业务逻辑放Service。

核心规则放Domain。

数据访问统一走Repository。

刚开始用Codex时，你给它的任务也比较明确。

所以整体结构还能保持得很好。

但后来Agent越来越能自己完成任务。

比如一次需求：

新增一个权限判断。

Agent觉得逻辑很简单，于是直接写在Controller。

单看：

没问题。

代码少。

测试也通过。

下一次另一个Agent任务：

也需要做权限判断。

这次Agent觉得应该抽一个Helper。

于是新建一个工具函数。

第三次：

Codex分析项目以后觉得权限属于业务逻辑。

于是又在Service里加了一套判断。

半年以后，你回头看：

同一种权限规则已经分散在：

Controller。

Helper。

Service。

Middleware。

每一个修改当时都能解释。

没有哪个Commit明显“写错了”。

但项目整体已经失去统一规则。

这就是典型的架构漂移。

---

二、为什么Agent时代，这个问题会比以前更明显？

因为过去很多架构决策其实天然由人统一。

同一个开发者长期维护一个项目，会逐渐形成习惯：

这个项目不喜欢把业务规则写进Controller。

这个模块不允许反向依赖。

公共逻辑尽量放哪一层。

哪些东西必须走接口。

这些规则不一定全部写在文档里。

但人脑里有。

所以即使每次需求不同，开发者还是会用相对统一的方式处理。

但Agent不一样。

Agent每次看到的是：

当前任务。

当前上下文。

当前相关文件。

它最容易优化的是：

这一次任务怎么最快、最合理地完成。

而不是：

半年以后整个项目是否仍然保持同一种设计语言。

这就是为什么Agent越自主，架构一致性反而越值得管理。

---

三、真正危险的不是“错误架构”，而是“多个合理架构同时存在”

很多人一说架构漂移，会想到：

代码质量变差。

其实更麻烦的一种情况是：

每种写法都不差，但项目里出现了太多种写法。

比如同一个问题：

模块A使用事件驱动。

模块B直接函数调用。

模块C通过Service协调。

模块D又引入新的Adapter。

你单独拿任何一个模块出来看：

都能解释。

但整个项目开始缺乏统一性。

这种状态对开发者特别麻烦。

因为以后做新功能时，你不知道应该参考哪一种模式。

Agent也会遇到同样的问题：

它读到四种实现。

下一次到底模仿哪一个？

结果它可能再创造第五种。

于是架构漂移开始自我放大。

---

四、为什么“局部最优”很容易制造长期漂移？

Agent处理任务时，天然会考虑：

当前修改成本。

当前代码结构。

当前测试。

当前需求。

所以它做出的方案往往是局部最优。

比如当前功能只需要一个简单判断。

直接放Controller是最省事的。

从当前任务看：

完全合理。

但项目长期规则可能是：

所有权限必须统一走Policy层。

如果Agent不知道这个约束，就会做一个“局部合理、全局不一致”的决定。

当这种决定偶尔出现一次时，影响不大。

但AI让修改次数变多以后：

一次。

十次。

五十次。

局部偏差就会逐渐积累成整体结构变化。

所以AI提高的不只是代码生成速度。

它也提高了：

架构决策发生的频率。

而决策频率越高，没有统一约束时，漂移速度就越快。

---

五、更深一层：AI让“设计决策”从低频变成高频

以前一次明显架构调整，可能是：

专门开会。

讨论方案。

做设计文档。

然后再改。

因为人工修改成本高，所以架构变化通常是低频事件。

但现在Agent可以在一个普通开发任务里顺手完成：

抽象。

拆层。

新增接口。

重构依赖。

于是很多原本属于“设计层”的决定，被悄悄塞进了普通任务。

比如一句：

“顺便把重复逻辑整理一下。”

Agent可能就会决定：

抽一个新的公共模块。

这已经不是纯代码生成。

而是在改变项目结构。

所以未来最大的变化可能是：

架构不再只在“大重构”时发生变化。

而是在每天几十个小Agent任务里持续发生。

这也是为什么架构漂移会越来越快。

---

六、为什么项目越大，这个问题越明显？

小项目里，架构漂移影响没那么大。

几十个文件。

一个人基本都能看懂。

即使写法不完全统一，也容易改回来。

但大型项目不一样。

模块多。

团队多。

历史代码多。

依赖关系复杂。

很多规则本身就带有历史原因。

比如：

为什么这个模块不能直接访问数据库？

为什么这个Service不能调用另一个Service？

为什么某个接口必须经过Adapter？

这些规则如果没有显式写出来，Agent很难通过代码本身完全推断。

于是大型项目越依赖Agent：

显式架构约束越重要。

否则Agent越强，反而越可能快速做出大量“看起来没问题”的偏离。

---

七、架构漂移最常见的几个信号

1. 同一种逻辑开始出现在不同层

比如权限判断：

一会儿Controller。

一会儿Service。

一会儿Middleware。

说明规则归属开始不稳定。

---

2. 相似模块使用完全不同的设计模式

一个模块事件驱动。

另一个模块直接调用。

第三个又自己封装一套。

如果没有明确理由，往往说明一致性开始下降。

---

3. 新的公共层越来越多

每次Agent遇到重复代码，都可能抽一个Helper、Manager、Adapter、Service。

久而久之：

抽象层越来越多。

但每层职责越来越难解释。

---

4. 依赖方向开始变得模糊

原本是：

UI → Service → Domain → Data

后来开始出现：

Domain反向调用Service。

工具层依赖业务层。

公共模块依赖具体实现。

这种往往是很危险的信号。

---

八、为什么测试通过也阻止不了架构漂移？

因为测试主要回答：

行为对不对。

但架构问题很多时候回答的是：

这个行为应该在哪里实现。

比如权限判断写在Controller。

只要功能正确：

测试可以全部通过。

但从长期设计看：

它可能仍然放错位置。

所以：

Functional Correctness ≠ Architectural Consistency

功能正确，不代表架构一致。

这是Agent时代特别重要的区别。

因为AI越来越擅长保证局部功能正确。

但长期结构是否统一，需要额外约束。

---

九、为什么Review也很容易漏掉这个问题？

因为Review通常围绕当前Diff。

开发者会看：

有没有Bug。

有没有明显风险。

测试够不够。

修改是不是太大。

但架构漂移是一个跨时间问题。

单个PR看不出来。

只有把最近几十次修改放在一起看，才会发现：

这个模块的写法开始变了。

同一种规则出现了三种实现。

依赖方向逐渐偏离。

所以架构漂移很像一种慢变量。

它不会在某一次修改里突然爆炸。

而是：

每天偏一点。

---

十、Agent时代真正需要的，不只是AGENTS.md，而是“架构边界”

很多人给Codex写AGENTS.md时，会写：

怎么运行测试。

代码风格。

目录结构。

常用命令。

这些当然重要。

但如果Agent开始拥有更多自主决策能力，我觉得还需要增加一类东西：

Architecture Constraints——架构约束

比如明确：

Controller不写业务规则。

Domain不能依赖Infrastructure。

所有权限统一走Policy。

公共接口不能直接修改返回结构。

跨模块通信必须经过某一层。

这些约束越清楚，Agent的局部决策就越容易保持在同一条轨道上。

---

十一、第二个办法：让Agent先解释“为什么放在这里”

对于稍微大一点的修改，不要只让它说：

改哪些文件。

可以额外问一句：

为什么这个逻辑应该放在这一层？

这个问题很简单，但非常有效。

比如Agent说：

我要在Controller里加判断。

你再问：

为什么不是Service或者Policy？

它就必须重新考虑职责归属。

这一步能过滤掉很多：

“因为这里改起来最方便”

导致的架构漂移。

---

十二、第三个办法：给项目设置“参考实现”

与其写很多抽象规则，有时候更有效的是直接告诉Agent：

如果做新的权限功能，参考模块A。

如果做新的异步任务，参考模块B。

如果新增API，参考模块C。

因为Agent非常擅长模式模仿。

一个稳定的参考实现，往往比一句：

“保持架构一致”

更有用。

这样下一次任务不会重新发明一套结构。

---

十三、第四个办法：周期性做Architecture Diff

我们平时看Git Diff：

代码变了什么。

但Agent时代，我觉得还值得偶尔做一次：

Architecture Diff

比如每隔一段时间看：

有没有新增层级。

有没有新的依赖方向。

有没有同一规则出现多种实现。

有没有模块职责开始重叠。

有没有原本禁止的依赖出现。

这不是每次任务都做。

而是定期检查：

项目整体有没有慢慢偏离原来的结构。

---

十四、给自己测一个指标：架构一致率

这篇我建议只用一个指标：

Architecture Consistency Rate——架构一致率

统计最近一段时间较大的AI修改。

看看其中有多少仍然遵守：

分层规则。

模块职责。

依赖方向。

接口约束。

统一设计模式。

例如最近20次较大的Codex任务。

其中15次都能明显遵守项目已有架构规则。

5次后来发现：

逻辑放错层。

新增了不必要的抽象。

依赖方向不一致。

那么：

架构一致率 = 75%。

这个指标比：

“Agent一次写了多少代码”

更能反映AI是否真正被项目吸收。

---

十五、架构一致率低于50%，意味着什么？

说明Agent虽然能完成任务。

但大量任务都在重新做局部设计。

这种状态下：

修改越多。

项目漂移越快。

所以当前最应该优化的是：

架构说明。

参考实现。

边界约束。

Review标准。

而不是继续扩大Agent并发。

否则AI产能增加以后，首先被放大的可能不是开发速度。

而是：

设计分叉速度。

---

十六、架构一致率50%—80%，重点是把“隐含规则”显式化

这个阶段通常说明：

大部分修改还比较统一。

但偶尔会出现Agent自己的实现方式。

最值得做的是找出：

为什么那些偏离会发生？

通常原因是：

项目规则只有老开发者知道。

代码里没有表达。

文档里也没有。

那就把这些规则写出来。

比如：

为什么某类逻辑必须放Domain。

为什么禁止跨模块直接调用。

为什么某个接口不能随便改。

只要这些规则显式化，Agent就更容易保持一致。

---

十七、架构一致率长期超过80%，才真正适合继续扩大AI产能

如果你的项目已经做到：

Agent自己做很多实现决策。

但大多数决策仍然符合项目长期架构。

新增模块风格一致。

职责边界清楚。

依赖方向稳定。

这说明AI自主性已经被有效约束。

这时候增加：

更多任务。

更长任务。

更高并发。

才不容易制造结构性混乱。

---

十八、Plus和Pro怎么判断？

如果你的架构一致率还比较低：

每个Agent任务都能做完。

但项目不断出现新的实现模式。

相似逻辑分散。

模块职责开始混乱。

这时候真正的瓶颈不是AI容量。

而是：

缺少统一的架构护栏。

这种阶段Plus通常已经足够。

更应该先完善：

AGENTS.md。

架构规则。

参考实现。

依赖约束。

Architecture Review。

否则提高到更高AI容量以后，只会让架构漂移得更快。

---

如果你的架构一致率已经很高：

Agent可以自主决定实现路径。

但大部分修改仍然保持统一设计。

团队很少需要返工架构。

项目规则也已经被机器和人共同理解。

同时又长期存在：

大量高价值任务等待执行。

多个成熟Agent任务排队。

AI侧容量明显限制吞吐。

这时候Pro才更容易真正放大生产力。

因为增加的不是：

更多不同风格的代码。

而是：

更多符合统一架构的工程产出。

所以判断顺序应该是：

先让Agent在同一条轨道上跑，再考虑让更多Agent同时跑。

---

十九、Agent越来越强以后，架构的价值反而会更高

以前很多人觉得：

AI越来越聪明以后，架构是不是没那么重要了？

我反而觉得可能相反。

因为以前一天只能产生少量代码。

即使设计偶尔有偏差，变化也慢。

现在Agent可以快速产生大量修改。

如果没有稳定架构约束：

偏差会快速累积。

所以架构真正的价值可能会从：

告诉人怎么写

变成：

限制大量Agent不要各自发明自己的写法。

这时候架构不只是设计工具。

还是AI产能的“方向控制系统”。

---

最后

ChatGPT、Codex越来越能自己完成复杂任务以后，一个很有意思的变化正在发生：

我们越来越少需要告诉Agent：

每一行代码怎么写。

但越来越需要告诉它：

这个项目到底允许怎样变化。

因为Agent可以自己选择：

在哪一层实现。

用什么抽象。

怎么组织模块。

如何处理依赖。

如果这些决定没有统一边界：

单次任务可能全部正确。

但几十次任务以后，项目却会慢慢变成：

多种风格。

多套规则。

多条依赖路径。

最后谁都很难解释：

这个项目真正的设计原则到底是什么。

所以以后衡量Agent是否真的适合大型项目，可能不能只看：

它一次任务写得对不对。

还要看：

它连续做50次任务以后，项目是不是还像同一个项目。

如果答案越来越经常是否定的，

那真正开始累积的就不是普通技术债。

而是：

架构漂移。

持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。