从单体到微服务再到 AI Agent：架构演进的底层逻辑

一、一条暗线

回头看这十年，软件架构的演进其实有一条暗线——"拆"。

• 单体时代：所有功能塞一个进程里
• 微服务时代：按业务边界拆成几十个服务
• AI Agent 时代：连"功能"本身都在被拆成"感知-决策-执行"的协作单元

每一次"拆"，本质上都是在回答同一个问题：

当复杂度超过一个人、一个团队、一个进程能掌控的边界时，怎么组织系统，才能让它继续生长而不是坍塌？

二、单体架构：简单，但天花板清晰

2014 年前后，大部分公司的后台还是一个 WAR 包打天下。好处显而易见：

• 开发快、调试简单、部署一个包就完事
• 事务天然一致，不用操心分布式
• 新人上手成本低

但天花板也很明确：

• 代码膨胀到一定程度，没人能"全看懂"了。改一个订单逻辑，不小心把用户模块搞挂
• 发布耦合。改一行代码，整个应用重新部署。周五下午谁敢发版？
• 技术栈锁死。想试试 Go 写新模块？不好意思，整个项目是 Java

单体不是"错"，是在规模超过临界点后，沟通成本超过了开发效率。

三、微服务：拆了，然后呢？

微服务的核心思想是：按业务边界拆，让每个服务可以独立开发、独立部署、独立扩缩。

听起来美好，但落地后你会发现新问题：

1. 分布式系统的复杂度被转移到了"人"身上

• 网络不可靠 → 要重试、要熔断、要降级
• 数据分散 → 要最终一致性、要 Saga、要事件溯源
• 链路变长 → 要链路追踪、要集中日志、要全链路压测

你以为拆了就解耦了，实际上只是把耦合从"代码层"搬到了"运维层和网络层"。

2. "拆多细"是个玄学

拆太粗，回到单体；拆太细，服务间调用爆炸。我见过一个团队把"发送短信"都拆成了独立微服务，结果一次注册流程要跨 7 个服务，P99 延迟 800ms。

3. 康威定律在起作用

微服务架构成功的公司，都有一个共性：组织结构本身就是按服务边界划分的。​ 每个小组对自己那个服务全权负责——开发、测试、部署、运维、值班。

架构从来不是技术问题，是组织问题。

四、AI Agent：下一轮"拆"的对象是什么？

2025~2026 年，一个新的架构形态在快速成型：AI Agent 系统。

它的核心思想和微服务有相似之处，但"拆"的粒度变了：

微服务的"拆"是按业务边界拆功能，AI Agent 的"拆"是按认知边界拆决策。

举个例子：一个"智能客服系统"在微服务架构下是：

API Gateway → 意图识别服务 → 订单查询服务 → 退款服务 → 回复生成服务

在 AI Agent 架构下变成：

用户消息 → Orchestrator Agent
                ├─ 意图识别 Sub-Agent（调用 LLM）
                ├─ 工具调用 Agent（查订单、查库存、调退款 API）
                ├─ 策略 Agent（判断是否满足退款条件）
                └─ 回复生成 Agent（组织最终回复）

每个 Agent 可以独立迭代、独立替换模型、独立调整 prompt。甚至可以让不同 Agent 用不同模型——意图识别用轻量模型省钱，复杂推理用大模型保质量。

五、底层逻辑：为什么每次都在"拆"？

我总结了一个框架，叫"三层边界模型"，帮你理解每一次架构演进的本质：

┌─────────────────────────────────────────┐
│  第一层：人脑边界                         │
│  一个人能掌控的代码量有上限 → 模块化、分层   │
├─────────────────────────────────────────┤
│  第二层：团队边界                         │
│  一个团队能维护的服务数有上限 → 微服务       │
├─────────────────────────────────────────┤
│  第三层：认知边界                         │
│  一个模型/系统能处理的决策复杂度有上限 → Agent │
└─────────────────────────────────────────┘

每一次架构演进，都是在把上一层"管不了的东西"交给下一层去自治。

• 单体管不了复杂度 → 拆成微服务，每个服务自治
• 微服务管不了认知任务 → 拆成 Agent，每个 Agent 自治决策

六、对开发者意味着什么？

1. 你的角色在从"实现者"变成"编排者"

微服务时代，你写代码实现业务逻辑。AI Agent 时代，你更多是在定义：

• Agent 的职责边界是什么？
• 它有哪些工具可用？
• 它的 prompt 怎么写？
• 多个 Agent 之间怎么协作？
• 出错了怎么回退？

写代码的比重在下降，"设计系统行为"的比重在上升。

2. "接口"的定义在变

以前的接口是 API 定义（OpenAPI/Swagger）。未来的接口是：

• Agent 的能力描述（我能做什么、我需要什么输入、我返回什么）
• 工具的定义（MCP 协议）
• 上下文的传递格式

会用自然语言定义清晰的接口，比会写代码更重要。

3. 可观测性的内涵在扩展

以前监控的是 CPU、内存、延迟、错误率。现在还要监控：

• Agent 的决策质量（幻觉率、偏离率）
• 工具调用的成功率
• Token 消耗和成本
• 多 Agent 协作的链路追踪