过去的软件开发，有一个非常现实的问题：

功能实现成本很高。

一个需求从想法到上线，往往需要经过：

需求分析
↓
技术设计
↓
编码
↓
联调
↓
测试
↓
上线

其中大量时间花在：

把设计变成代码

因此很多团队天然会把重点放在：

怎么更快实现？

这也是为什么过去几十年软件工程一直在不断提高开发效率：

高级语言
Framework
Library
Cloud
Low Code
Copilot
Codex

而 Coding Agent 出现之后，一个新的变化正在发生。

实现代码的成本开始快速下降。

一个过去需要开发人员几天才能完成的普通功能，现在可能在 Codex 辅助下几个小时就完成。

甚至未来可能进一步变成：

工程师定义目标
↓
Agent 实现
↓
自动测试
↓
人工 Review

这看起来似乎意味着：

软件开发会越来越简单。

但我反而认为事情可能朝另一个方向发展。

编码越容易，软件架构反而越重要。

因为当“生成代码”不再稀缺以后，真正决定系统长期质量的，将越来越是：

代码应该放在哪里？
模块边界是什么？
谁可以依赖谁？
哪些东西应该共享？
哪些东西必须隔离？
未来怎么扩展？

也就是说：

Implementation 变便宜以后，Architecture 会变得更贵。

一、为什么 AI 会放大架构问题

假设一个项目的架构非常混乱。

比如：

Controller
直接访问数据库

Service
直接操作 Redis

Utility
包含大量业务逻辑

不同模块
互相调用内部实现

如果全部由人工开发，系统虽然会越来越乱，但变化速度通常有限。

因为程序员每天只能写有限数量的代码。

但 Coding Agent 出现以后，情况会改变。

一个 Agent 可以快速：

增加 10 个接口
修改 20 个文件
新增多个 Service
增加大量辅助函数

如果项目没有清晰架构约束，Agent 很容易复制已有的坏模式。

于是：

Bad Architecture
+
Fast Code Generation
=
Faster Architecture Decay

也就是说：

AI 不只会放大开发效率，也会放大架构问题。

以前一个坏设计可能半年以后才扩散。

未来一个 Agent 可能几天就复制几十次。

二、AI 最擅长的事情之一，是模仿已有代码

这既是优势，也是风险。

假设项目里已经形成统一模式：

Controller
↓
Service
↓
Repository

Agent 新增一个订单功能时，大概率会找到现有：

UserController
UserService
UserRepository

然后模仿。

最终生成：

OrderController
OrderService
OrderRepository

这种情况下：

好架构会强化好架构。

但如果项目里已有：

Controller
直接写 SQL

Agent 同样会学。

于是：

坏架构也会强化坏架构。

这意味着未来代码仓库本身其实就是一个非常大的：

Few-shot Example

Agent 会不断从已有代码学习：

这个项目“通常怎么做”。

所以项目现有代码质量，会直接影响未来 AI 生成代码的质量。

三、未来架构规则必须越来越显式

传统团队里，经常存在很多潜规则。

例如：

Controller 不允许包含业务逻辑

Domain 层不能依赖 Infrastructure

跨模块调用必须经过公开接口

公共模块不能引用业务模块

老员工都知道。

新人进来以后，慢慢学。

但 Agent 不会自动知道这些规则。

所以 AI Coding 时代一个非常重要的变化是：

Architecture Rules Need to Be Explicit

架构规则必须显式化。

例如项目中可以明确写：

# Architecture Rules

## Dependency

API → Application → Domain

Infrastructure 可以依赖 Domain。

Domain 不允许依赖 Infrastructure。

## Module Boundary

Order 模块不允许直接访问 Payment Repository。

跨模块调用必须通过公开 Service。

## Database

业务模块只能访问自己的表。

这样 Codex 在开始任务之前，就能够先建立：

Architecture Context

而不是根据经验猜。

四、架构文档不能只画一张图

很多团队所谓的架构文档，其实是一张：

系统架构图.pptx

里面画着：

前端
↓
网关
↓
微服务
↓
数据库

这种图对领导汇报可能很有用。

但对 Coding Agent 来说，价值有限。

Agent 真正需要的是：

哪些模块存在？
每个模块负责什么？
谁可以调用谁？
哪些接口是公开的？
哪些实现不能直接引用？

所以未来更加实用的架构说明应该接近：

Machine Readable Architecture

例如：

modules:
  order:
    owns:
      - orders
      - order_items
    can_call:
      - payment.public_api
      - inventory.public_api

  payment:
    owns:
      - payments
    can_call:
      - notification.public_api

这种信息比一张漂亮的大图更适合 Agent 使用。

五、架构边界其实是在减少 Agent 的决策空间

为什么架构越清晰，Agent 越容易工作？

因为它减少了：

Search Space

搜索空间。

假设没有任何架构规则。

Agent 要实现：

查询订单。

它可以：

Controller 直接 SQL

新增 Repository

调用其他 Service

新增缓存

创建公共工具类

选择非常多。

选择越多，犯错概率越高。

但如果架构明确规定：

Controller
只能调用 Application Service

Application Service
通过 Repository 访问数据

那么 Agent 的决策空间立即缩小：

OrderController
↓
OrderService
↓
OrderRepository

所以架构规则的另一个重要作用是：

帮助 Agent 少做决策。

这和人类团队完全一样。

成熟团队并不是因为每个人每天都做无数架构决策。

而是因为：

大量决策已经通过规范提前完成。

六、未来好的架构应该具备一个新特征：Agent Friendly

过去评价软件架构，通常看：

可维护性
可扩展性
可靠性
性能
安全性

未来可能还会增加：

Agent Friendliness

也就是：

Agent 是否容易理解和修改这个系统？

例如一个 Agent Friendly 的模块应该具有：

明确入口
明确职责
有限依赖
稳定接口
完整测试
清晰命名

假设一个模块：

order/
  api/
  application/
  domain/
  infrastructure/
  tests/

Agent 很容易理解。

但如果整个系统是：

common.py
common2.py
utils.py
utils_new.py
helper.py
business_helper.py

人都看不懂。

Agent 同样会迷失。

所以：

好架构不仅降低 Human Cognitive Load，也降低 Agent Cognitive Load。

七、模块化会因为 AI 重新获得更大价值

这些年软件工程经历过：

Monolith
↓
Microservices
↓
Modular Monolith

很多团队逐渐意识到：

服务拆得越多，不一定越好。

但无论是微服务还是单体，真正关键的其实都是：

Module Boundary

模块边界。

为什么在 Agent 时代边界更加重要？

因为未来多个 Agent 可能同时工作。

例如：

Agent A
修改 Order

Agent B
修改 Payment

Agent C
修改 Notification

如果模块之间边界清晰：

Order
Payment
Notification

就可以并行。

但如果：

所有模块共享大量全局状态
所有 Service 相互调用

多个 Agent 会频繁修改同一批文件。

最终：

Git Conflict
Context Conflict
Behavior Conflict

都会明显增加。

八、未来架构还有一个非常重要的指标：可并行修改性

过去设计架构时，我们很少会问：

这个系统适不适合 10 个 Agent 同时修改？

未来可能需要考虑。

例如两个系统。

系统 A：

User
Order
Payment
Inventory

边界清晰

系统 B：

所有业务都依赖一个 CommonService

如果同时运行多个 Agent：

系统 A：

Agent 1 → User
Agent 2 → Order
Agent 3 → Payment

几乎互不影响。

系统 B：

Agent 1 → CommonService
Agent 2 → CommonService
Agent 3 → CommonService

天天冲突。

所以未来好的软件架构，除了：

Maintainability

还可能需要：

Parallelizability

可并行开发性。

九、“公共模块”可能成为 Agent 时代最大的技术债来源之一

很多项目有一个目录：

common/

最开始只有几个工具。

几年以后：

common/
  string_utils
  date_utils
  db_utils
  user_utils
  order_utils
  auth_utils
  payment_utils

最后：

什么都在 common。

这种设计对 Coding Agent 尤其危险。

因为 Agent 很容易搜索到：

common

然后觉得：

这是大家共享的地方。

于是继续往里面加。

最终 common 会像黑洞一样吸收整个项目。

所以未来架构规则应该更加明确：

什么东西可以共享
什么东西绝对不能共享

特别是：

业务逻辑

尽量不要进入通用模块。

十、Codex 可以反过来帮助发现架构腐化

Agent 不只是架构问题的制造者。

它也可以成为：

Architecture Observer

例如让 Codex 定期分析：

模块依赖关系

它可以发现：

Order
突然开始依赖 Inventory Repository

而原本规定：

Order
只能调用 Inventory Service

于是提示：

发现新的跨模块内部依赖。

甚至可以生成依赖图：

Order
↓
Payment
↓
Notification

并检查有没有：

Circular Dependency

例如：

Order
↓
Payment
↓
Order

这就是非常典型的架构风险。

十一、Architecture as Code 会越来越重要

如果架构规则只存在：

架构师脑子里

那其实不是真正规则。

真正成熟的方式应该是：

Architecture as Code

例如：

Domain
不得依赖 Infrastructure

可以通过自动工具检查。

或者：

Order
不得直接依赖 PaymentRepository

也可以加入 CI。

最终形成：

Code Change
↓
Architecture Check
↓
Pass / Fail

这和：

Lint
Test
Security Scan

本质上是一样的。

只不过检查的是：

Architecture Constraint

架构约束。

十二、AI 会推动架构从“建议”变成“机器规则”

过去架构师经常说：

大家尽量不要跨层调用。

这种话执行效果通常一般。

因为：

赶需求

的时候，总有人直接：

Controller
→ Database

如果以后 Agent 大规模写代码，仅靠“建议”更加不够。

因为 Agent 会高频产生修改。

所以架构规则必须能够被：

自动检查

例如：

forbidden dependencies
module ownership
public API
database ownership

全部进入工程流水线。

未来架构治理可能逐渐从：

Architecture Review Meeting

变成：

Continuous Architecture Validation

持续架构验证。

十三、Codex 时代，接口设计会比实现细节更加重要

如果实现代码越来越容易生成，那么真正需要人重点设计的东西是什么？

我认为其中之一就是：

Interface

接口。

例如两个模块：

Order
Payment

真正重要的是：

Order
应该知道 Payment 的多少信息？

最差的方式是：

Order
直接访问 payment 表

更好的方式：

PaymentService.pay()

再进一步：

Payment API
明确输入输出 Contract

这样以后 Payment 内部怎么实现，都不会影响 Order。

这也是 AI 时代非常关键的一点。

因为 Agent 最适合：

在明确边界内部快速实现。

而不适合：

每次修改都重新思考整个系统边界。

所以人应该更多设计：

Stable Contract

然后让 Agent 在边界内部工作。

十四、“黑盒模块”可能成为 Agent 时代最理想的模块

一个设计良好的模块，对外应该像：

Black Box

外部只需要知道：

输入
输出
错误

不需要知道内部实现。

例如：

PaymentService.pay(orderId, amount)

外部根本不需要知道：

Stripe
PayPal
Bank API

如果模块边界做到这种程度，未来你甚至可以：

让 Agent 完全重写 Payment 内部实现

只要：

Contract 不变
Tests 全部通过

其他模块根本不用改。

这会大幅提高 Agent 的可操作空间。

十五、稳定边界 + 快速内部变化，可能成为 AI 时代的重要设计原则

未来系统可能出现一种新的节奏：

Interface
稳定

Implementation
快速变化

比如：

Payment Contract
几年不变

但内部：

Agent
不断重构
优化
迁移

这其实非常符合软件工程一直追求的：

High Cohesion
Low Coupling

高内聚、低耦合。

只不过 AI 的出现让这个原则变得更加现实。

因为：

内部重写成本大幅下降之后，边界稳定的重要性进一步提升。

十六、架构设计的重点会从“怎么实现”转向“怎么限制”

传统架构讨论经常是：

系统应该怎么实现？

未来可能越来越变成：

Agent 不应该做什么？

例如：

Order 不允许访问 Payment DB

Controller 不允许包含业务逻辑

Domain 不允许访问网络

Agent 不允许新增跨模块依赖

这些都是：

Negative Constraints

负向约束。

它们告诉 Agent：

可以在什么范围内自由发挥。

这种模式其实非常适合 AI。

因为模型越强：

需要告诉它的
不是每一步怎么做

而是：

哪些边界不能跨。

十七、这和“护栏”思维非常类似

可以把架构理解成高速公路。

Agent 是汽车。

如果没有任何道路规则：

哪里都能走

看起来非常自由。

但结果一定混乱。

好的架构其实是在建立：

Road
Lane
Guardrail

Agent 可以：

在车道里高速运行。

只要不突破边界。

所以 Agent 时代好的软件工程并不是：

把 Agent 限制得什么都不能做。

而是：

建立清晰护栏以后，让 Agent 在护栏内部拥有更大自主权。

十八、架构决策记录会重新变得重要

为什么系统使用：

Kafka

而不是：

RabbitMQ？

为什么订单和支付分开？

为什么没有做微服务？

为什么文件存储不用数据库？

这些问题几年以后，新人可能完全不知道。

Agent 更不知道。

所以 Architecture Decision Record，也就是：

ADR

会非常有价值。

例如：

# ADR-008

## Decision

订单和支付保持独立模块。

## Reason

支付未来需要支持多个渠道，
生命周期与订单不同。

## Constraint

Order 模块不能直接访问 Payment 表。

以后 Codex 修改 Order 时，就可以读取这个决策。

这样架构历史就不再只存在：

人的记忆

而成为：

Agent Context

十九、未来架构师可能不再画那么多图，而是设计 Agent Rules

传统架构师大量工作是：

画图
写技术方案
开评审会

未来可能增加一种新的工作：

Agent Architecture Rules

例如：

定义模块所有权

定义 Dependency Rule

定义公开接口

定义禁止依赖

定义修改风险等级

然后让这些规则进入：

Codex Context
+
CI
+
Review Agent

架构治理从：

人告诉人

逐渐变成：

规则约束 Agent

这会让架构真正进入日常开发，而不是：

半年一次架构评审

二十、未来可能出现专门的 Architecture Agent

可以想象一个：

Architecture Agent

它平时不负责写功能。

而是不断观察 Repository。

例如每天检查：

新增模块依赖

循环依赖

公共模块膨胀

跨层调用

数据库越界访问

重复能力

然后生成：

Architecture Drift Report

例如：

本周新增 7 条模块依赖。

其中：

Order → PaymentRepository
违反模块边界。

Notification → UserRepository
属于新的跨模块数据访问。

common 模块新增 12 个业务函数。

这种能力可能让架构治理第一次真正做到：

Continuous

持续化。

二十一、AI 可能让“模块重构”成本大幅下降

过去一个模块架构非常差。

大家都知道：

应该重构。

但没人愿意做。

因为：

太耗时间
风险太高

未来 Agent 可以帮助：

分析依赖
↓
补 Characterization Test
↓
提取接口
↓
迁移代码
↓
验证

重构成本下降以后，团队可能更愿意：

持续修复架构

而不是：

等到系统彻底失控
再重写

这可能是 AI 对软件架构非常积极的一面。

二十二、但 AI 同样可能制造“看起来很高级”的过度设计

这里必须警惕一个问题。

模型非常擅长：

Factory
Strategy
Abstract
Interface
Manager
Provider

如果你告诉 Codex：

设计得更加优雅。

一个原本 50 行能解决的问题，可能最后变成：

8 个类
5 个接口
3 个 Factory

从设计模式角度看：

非常专业

但从工程角度看：

完全没必要

所以 AI 时代一个非常重要的架构原则可能是：

Prefer Simplicity

优先简单。

不要因为代码生成便宜，就增加更多代码。

二十三、代码便宜之后，“少写代码”反而可能更重要

这听起来有点反直觉。

AI 可以大量生成代码。

为什么还要少写？

因为：

Code Generation Cost
↓

但是：

Maintenance Cost

并没有消失。

今天 Agent 写的：

10000 行代码

未来：

还是有人或者 Agent
需要理解它

而系统复杂度会一直存在。

所以真正优秀的软件工程可能越来越强调：

更少的概念
更少的依赖
更少的状态
更少的抽象

而不是：

生成更多代码。

二十四、未来架构质量会直接决定 Agent Productivity

可以把这个关系简单写成：

Agent Productivity
=
Model Capability
×
Repository Quality
×
Architecture Clarity

即使模型非常强，

如果：

系统高度耦合
没有模块边界
没有测试
没有规则

Agent 仍然很难可靠工作。

反过来，如果系统：

边界清晰
Contract 稳定
测试完整
架构规则明确

那么一个 Agent 就可以在局部拥有很大自主权。

因此未来企业如果想真正发挥 Codex 的价值，

不能只投资：

Model

还需要投资：

Architecture

二十五、AI Native Architecture 可能是什么样？

如果为 Agent 时代重新设计一个系统，我认为它可能有几个特点。

第一：

模块边界明确。

第二：

公开 Contract 稳定。

第三：

模块内部可以独立测试。

第四：

架构规则机器可检查。

第五：

不同模块可以独立修改。

第六：

架构决策有明确记录。

最终目标不是：

让架构看起来高级。

而是：

让 Human 和 Agent 都能快速理解，安全修改，并独立验证。

这可能才是真正的：

AI Native Architecture

结语：AI 越会写代码，人越需要设计边界

软件工程过去很长时间里，一直受到一个限制：

代码很贵。

所以我们关注：

怎么更快地把想法变成代码？

Codex 正在快速降低这个成本。

但当：

Code

越来越便宜以后，另一些东西会显得越来越昂贵：

复杂度
耦合
架构债
错误边界
隐性依赖

所以未来最有价值的软件工程能力，可能不是：

如何让 Agent 写更多代码。

而是：

如何设计一个环境，让 Agent 即使高速写代码，也不会把系统写乱。

这就是架构真正的价值。

好的架构并不是告诉开发人员：

每一行代码应该怎么写。

而是定义：

哪里可以自由变化
哪里必须保持稳定
谁可以依赖谁
哪些边界不能突破

然后在这些边界内部：

Human
和
Agent

都可以快速工作。

所以 Codex 时代的软件架构，可能会越来越像一种：

Governance System

治理系统。

它不负责生成代码。

它负责控制：

复杂度
依赖
边界
演化方向

而当 Coding Agent 的执行能力越来越强时，

这种治理能力反而会成为软件团队真正稀缺的东西。

最终，AI Coding 可能让我们重新认识一个非常经典的软件工程事实：

真正难的从来不是把代码写出来，而是让一个系统在不断变化十年以后，仍然保持可理解、可修改、可演进。

如果 Codex 能让“实现”越来越便宜，

那么软件架构的任务，就是确保：

这种越来越便宜的实现能力，不会换来越来越昂贵的复杂度。