康威定律遇上 AI Agent：微服务为什么又值得讨论了

这些年我给小型工程团队的建议一直很稳定：从单体开始，保持模块化和清晰的边界，在没有真实理由之前不要引入分布式系统的复杂度。我看过太多公司一头扎进微服务，也知道那个故事通常怎么收场。

但最近大量用 AI 编码 Agent 在大代码库上干活之后，我开始重新审视一个我以为早就尘埃落定的结论。微服务可能有了新的存在理由——只是这个理由跟扩基础设施、扩团队都没关系，而是跟管理大型系统变更的复杂度和风险有关。

康威定律的新变量：可用的上下文窗口

康威定律告诉我们：系统的结构会反映构建它的组织的沟通结构。这是微服务适配大型工程组织的原因之一——独立团队独立开发部署，软件边界最好跟责任边界对齐。

可当大量实现工作由 AI Agent 完成时，约束条件变了。除了围绕人类团队的沟通边界设计软件，我们还需要考虑：一个 Agent 能有效推理的上下文到底有多大？

注意，我说的不是模型宣传的上下文窗口。模型能吃下几十万甚至上百万 token，不代表它能可靠地推理这些 token 里每一个依赖关系、历史取舍和意外后果。

真正重要的是可用上下文窗口：Agent 能真正理解多少相关信息，足以让它做出一个改动并对改动的正确性建立合理信心。这比原始 token 数有趣得多，也苛刻得多。

在一个十年的遗留系统里，Agent 也许能读海量代码，但这不等于它对系统如何相互作用有可靠的心智模型。问题不在于能不能读到信息，而在于能不能分辨哪些信息重要、各部分怎么关联、一个改动会引发什么后果。

而设计良好的架构边界恰好能帮上忙：显式的契约、清晰的数据归属、有限的依赖、独立的验证手段——这些把 Agent 要面对的问题裁剪到它的推理能力之内。

这就是微服务重新变得有趣的地方。不是因为需要独立团队或独立扩缩容，而是因为服务边界可以造出一个恰好能被 Agent 有效推理的工作单元。

当然，这不意味着按 token 数来切服务、或者一个 Agent 一个服务——那会是糟糕的软件设计。相关的边界不是「Agent 能读多少行代码」，而是「为了安全地完成这个改动，它需要理解系统的多大范围」。

康威定律反映的是人类组织的沟通约束；AI 时代的架构，可能越来越多地反映 AI Agent 的推理约束。我不认为这取代了康威定律——人类依然拥有系统、做架构决策、对生产负责。但当 Agent 承担更多实现工作，这会成为一个越来越重要的约束。

Agent 改大代码库的真正难点

在大代码库上用 Agent 干活，我观察到一件关键的事：Agent 能做出一个改动，和它对改动后果有信心，是完全不同的两回事。

现代编码 Agent 在仓库里穿梭、追依赖、跨文件改功能，做得出奇地好。但理解一段代码做了什么，不等于理解改它的时候可能发生什么。

想象一个跑了十年的应用：换过几茬团队、经历过几次架构转向、有没迁移完的半截工程、还有一大堆当时合理但从未记录的决定。隐性契约无处不在——一个看起来可选其实必填的数据库字段；一个依赖特定状态变更顺序的后台任务；一个五年前被某个客户集成了的 API 行为。

老工程师知道这些坑，是因为他们亲眼见过它们炸。Agent 没有这份历史，除非这些知识被记录在它够得着的地方。

AI 让这个问题更尖锐的原因在于：Agent 能产出大量代码，却不需要等量的人类实现时间。在我用 Agent 最顺的工作流里，代码本身往往是廉价的，贵的是理解、审查、测试和安全部署。系统越大越复杂，这部分越贵。

问题不是 Agent 没法在大代码库上工作，而是「有信心验证一个改动」所需的可用上下文，可能远远超过被修改的那点代码。这让架构边界有了新的价值：它不只是组织代码，它约束 Agent 需要推理的系统范围。

微服务作为隔离不确定性的手段

换个角度：与其把微服务当成组织工程团队的方式，不如把它当成创造更小的、可独立验证的功能单元的方式。

假设你要给现有应用加一个实质性的新能力——大部分是新功能，但要跟系统的要害部位打交道，比如一条新的数据处理流水线，性能特征未知。

你可以让 Agent 直接在现有应用里实现。有时这确实是对的。但你等于让它同时解两个问题：搞清新功能该有的行为，以及搞清怎么把它安全地接入一个复杂的存量系统。这是两种不同的不确定性，都在消耗 Agent 的有效推理容量。

换个做法：让 Agent 把这个功能做成一个相对隔离的服务。给它清晰的 API 契约，定义好依赖和数据归属，保证它能独立部署和观测。现在 Agent 面对的是一个有边界的问题——不需要重建整个遗留应用的心智模型，只需专注服务内的功能和那几条明确的对外契约。

然后你可以把功能灰度给一部分客户，观察它在真实流量下的行为，随着信心增长逐步放量。出了问题，排查的位置更清楚，回滚的路径更简单。

你不只是在隔离功能，你是在隔离不确定性。

有两点要提醒：如果服务在改共享的数据库表、制造跨应用的副作用、参与复杂的分布式事务，那这种隔离是假的；而且你也不一定需要微服务——模块化单体加功能开关加认真设计的边界，能做到同样的事。独立服务的真正吸引力在于运行时隔离、独立部署和不同的扩缩容特征。

更大胆的想法：第一版实现是「一次性」的

软件行业聊「临时软件」聊了几十年，谁都知道那通常怎么收场：临时绕过变成永久依赖，原型变成产品，说好只活六个月的服务五年后还在跑。

原因很简单。历史上写软件需要投入大量人类工程时间，一旦花几个月建了个东西，推倒重来意味着再花一份时间和钱回到你已有的功能上。返工被视作失败。所以哪怕所有人都同意实现不理想，经济上总是偏向留着它。这也是我们在实现前拼命想把架构搞对的原因——因为我们知道改主意很贵。

Martin Fowler 在 2014 年就提过「牺牲性架构」（Sacrificial Architecture），绞杀者模式也是用中间架构支撑系统渐进演进的例子。我的想法是：AI Agent 是否正在改变经济性，让这种做法在以前不划算的场合变得实用？

如果 Agent 大幅降低了实现和重实现功能的劳动力成本，那扔掉一个能工作的实现就变成了合理得多的选项。当然返工不是免费的——迁移生产数据、保持兼容、验证行为、迁移客户，这些才是真正的硬成本，AI 消灭不了它们。但「写代码和重构代码的劳动力」可能不再是主要约束。

如果是这样，我们就该重新掂量：值得花多大力气去避免重新实现？与其在理解问题之前试图做出完美的架构决策，不如先建一个临时实现，用它来消除不确定性，然后再决定永久实现长什么样。

第一版不是失败品，它的使命是学习。

实现即规格

流程走完后会发生一件有趣的事：你手里不只是一个能工作的软件，而是一份被真实生产环境检验过的「可执行规格」——API 契约、测试、观测到的使用模式、已知边界情况、性能指标、真实客户反馈。你比开始时对问题的理解深刻得多。

当然要留个心眼：源代码本身不是完整规格，它可能包含偶然行为、没记录的假设、以及恰好在已观测条件下不出事的 bug。你需要刻意地把学到的东西沉淀下来——行为契约、测试、数据语义、故障模式、运维特征。

但一旦做完这些，你就拥有了比任何原始设计文档都有用的东西：一份被工作实现和真实用户验证过的规格。这时再做架构决策，质量完全不同。

也许证据告诉你这功能该合回单体——那就把验证过的行为、契约、测试连同参考实现一起交给 Agent，让它解决「集成」这个更窄的问题，而不是同时猜功能该长什么样、又在遗留系统的复杂度里打转。也许证据说独立服务就是对的架构——扩缩容需求不同、数据归属清晰、隔离有真实价值，那就留着它。

重点是：这个决策基于证据，而不是在什么都没建之前预测所有的需求和取舍。

这引出一个有用的区分：为学习而设计的架构，和为长期运行而设计的架构，不必是同一个实现。

一个诚实的提醒

上面这些不是说「微服务文艺复兴了，都给我拆」。运营开销是真实的，数据迁移的坑是真实的，分布式系统的复杂度不会因为写代码便宜了而消失。

变的是等式的另一端：当实现成本下降、验证和学习的相对成本上升，架构设计的重心会从「一次性把边界画对」转向「让边界服务于快速学习」。单体优先依然是我的默认建议——但在 AI Agent 深度参与实现的世界里，「先隔离、后决策」这条路，值得放进你的工具箱。