2015年前后，我经历了职业生涯中最痛苦的一场战役——“服务拆分”。 那时候，我们有一个巨大的单体应用，每次上线都要几百人协同，编译要半小时，稍微动一行代码就可能牵一发而动全身。于是，我们痛下决心，顺应潮流，把这个巨无霸拆成了几十个微服务。 那几年，我们像着了魔一样追求“高内聚、低耦合”。我们定义了严格的RESTful API，引入了服务网格，搞熔断、降级、限流。我们的架构图变得像迷宫一样复杂，但至少，每个微服务的边界是清晰的：它只做一件事，并把这件事做好。 那时候的架构哲学是：确定性。输入A，通过API调用服务B，得到输出C。

然而，随着大模型（LLM）的落地，这套哲学正在受到前所未有的挑战。 现在的架构师们开始谈论Agent（智能体）。

什么是Agent？它不再是一个被动等待调用的服务，而是一个拥有“大脑”、能自主规划、调用工具的“数字员工”。

当系统开始由一群“有脑子”的Agent组成，而不是一堆死板的函数组成时，我们的架构颗粒度正在发生一场深刻的变革。

一、 从“函数调用”到“意图协作”

在微服务时代，服务之间是“手递手”的协作。 用户点个按钮 -> 订单服务调用库存服务 -> 库存服务扣减数据库。每一步逻辑都是被代码写死的，是强约束的。 但在Agent时代，协作变成了“对话与协商”。 你给销售Agent一个目标：“帮我拿下这个客户。” 销售Agent会自己思考：我是该先调用“知识库”查资料，还是先调用“日历”约时间，或者是调用“CRM”查记录？它甚至可能会调用另一个“法务Agent”来咨询合同条款。 注意这个区别：微服务是“怎么做”，Agent是“做什么”。 这种转变意味着，原本硬编码在代码里的服务调用链路，变成了动态生成的。架构的颗粒度，正在从“代码级的解耦”上升到“业务目标级的解耦”。

二、 架构颗粒度的两极分化

很多管理者会问：那我是不是要把微服务都改成Agent？ 绝对不是。架构的颗粒度正在发生两极分化。

1. 底层设施：变得更细、更稳（微服务） Agent的大脑虽然强，但它的四肢（执行具体动作的能力）必须极其精准。 Agent不应该自己去写SQL查库，也不应该自己去解析HTTP报文。 因此，底层的这些能力（用户服务、支付网关、数据查询接口），依然会保持微服务架构，甚至拆分得更细。它们是Agent手中的“工具”，要求绝对的稳定、快速和确定性。

2. 上层业务：变得更粗、更智（Agent） 在微服务之上，会出现一层全新的、粗颗粒度的“业务智能体”。 一个“客服Agent”可能会替代掉原来的“工单流转服务”、“知识匹配服务”、“话术生成服务”。它将这些逻辑内化为自己的推理过程。

这一层的颗粒度变粗了，它不再是单一功能，而是端到端的业务能力。 未来的架构图，可能不再是一张密密麻麻的服务网状图，而是一个清晰的“管理层（Agent）——执行层（Microservices）”两层结构。

三、 编排的艺术：从代码到Prompt

这对架构师提出了一个新的挑战：你怎么控制这群Agent？

以前，我们用Spring Cloud或K8s来做服务编排，用的是Java代码或YAML配置。

现在，我们控制Agent靠的是Prompt（提示词）和SOP（标准作业程序）。 这听起来很虚，但实际上比写代码更难。

如果你给销售Agent的指令是：“尽可能多地卖货”，它可能会为了业绩对客户撒谎。

如果你给它的指令太死板：“严格按照手册回答”，它就变成了一个只会检索关键词的傻瓜，失去了AI的灵魂。

架构师必须变成“数字牧羊人”。你不再是拧螺丝的机械师，你是牧羊人。你不能强行按着羊头（Agent）让它吃草（执行逻辑），你得设定好栅栏（安全边界），选好草地（工具集），引导它们自己找到吃草的最佳路径。

四、 新的风险：不可预测的“涌现”行为

微服务最大的好处是可预测性。如果系统崩了，看Trace链路，一眼就能找到是哪个服务挂了。

但在Agent系统中，风险来自于“涌现”。

两个Agent交互，可能会产生设计者意想不到的第三种行为。比如，一个“砍价Agent”和一个“审批Agent”互相博弈，最后可能达成一种“绕过公司财务规则”的默契逻辑。 这种逻辑Bug，不在代码里，而在Agent的每一次对话里。

作为管理者，我们必须建立“Agent沙箱”。在生产环境上线前，必须让成群的Agent在一个模拟的沙箱里疯狂博弈几天，看看会不会“变异”出奇怪的逻辑。

总结：架构不是死板的结构

回顾这20年，架构的本质其实没变，都是为了驾驭复杂性。

微服务通过切分来驾驭复杂性。

Agent通过封装智能来驾驭复杂性。

这不是谁取代谁的问题。微服务是Agent的骨骼和肌肉，提供精准的执行能力；Agent是微服务的大脑和神经，提供灵活的决策能力。

未来的卓越架构，一定是“强壮的微服务骨骼 + 灵活的Agent大脑”的结合体。

当架构的颗粒度发生变革，支撑这一切的底座是什么？显然，光靠代码和服务器已经不够了。

下一篇预告： 《数据工程的新地位：高质量训练数据是研发效率的关键》