作者按：上周一位做企业软件的朋友发给我一篇文章，标题大概是"CTO 必须跨越的技术断层"。读完之后，我坐在电脑前沉默了很久。不是被震撼，而是被一种熟悉的焦虑感击中——这种"不跟上就淘汰"的叙事，我在云计算时代听过，在中台时代听过，在低代码时代也听过。每一次，技术社区都像是被按下了集体恐慌按钮。我想写点不一样的东西。不是反驳，而是厘清。不是唱衰 Agent，而是追问：当我们谈论"从微服务到 Agent"时，我们到底在谈论什么？
让我先亮明立场：Agent 架构确实代表了软件系统交互方式的重要演进，但它不是微服务的掘墓人，更不是一道必须"跨越"否则就"坠落"的断层。
那篇文章将微服务描述为"确定性 DAG"，将 Agent 描述为"动态规划+条件分支+自我修正"，然后宣布两者之间存在"真实的技术断层"。这个对比本身就有问题。
微服务从来不是纯粹的"确定性"系统。从 2015 年 Netflix 开源 Zuul 开始，服务网格（Service Mesh）就支持基于权重、Header、甚至自定义规则的动态路由。Temporal、Cadence、Camunda 这些工作流引擎在微服务生态中运行多年，它们处理的就是复杂的条件分支、重试、补偿和状态机。Saga 模式本身就是为了处理长事务中的不确定性而设计的。
所以，"动态性"不是 Agent 带来的新东西，"将决策权从代码交给模型"才是。 这是一个关键的区别。Agent 架构的核心创新不是"系统能动态决策了"，而是"系统的决策逻辑由概率模型生成"。
这个区别之所以重要，是因为它直接指向了 Agent 架构的成本结构和风险轮廓——而这两件事，恰恰是大多数"Agent 将取代微服务"叙事中刻意模糊的地带。
我过去一年参与了三个 Agent 项目的架构评审，其中两个已经回退到"LLM 作为辅助决策层"的方案。失败的原因出奇地一致：成本模型撑不住。
让我们做一道简单的算术题。
一个中等复杂度的业务请求，在微服务架构下通常涉及 5-7 次内部 API 调用。假设每次调用的计算成本（含序列化、网络、数据库查询）折合为 0.001 美元。一次完整请求的成本约为 0.005-0.007 美元。
同样的业务逻辑交给 Agent 处理，假设需要 3 轮 LLM 推理（规划、执行中的反思、最终总结），使用 GPT-4 级别的模型，每轮输入输出平均 4K tokens。按 2026 年的市场价格，这大约是 0.05-0.08 美元。
十倍到十五倍的成本差异。 而且这还没有算上前置的 Embedding 检索、RAG 上下文构建、以及多 Agent 协作时的通信开销。
对于客服、内部数据分析、文档生成这些低频、高价值的场景，这个成本是可以接受的。但对于电商下单、支付路由、物流跟踪这些高频、低毛利的核心业务流程，将 Agent 作为主路径意味着直接摧毁单位经济模型。
微服务架构优化的目标之一，是将 P99 延迟控制在 200ms 以内。这要求每一跳服务调用都尽可能快——内部通信走 gRPC，数据库查询有缓存，序列化用 Protobuf。
Agent 架构的延迟结构完全不同。一次 LLM 推理的冷启动延迟通常在 500ms-2s 之间，复杂的多步 Agent 任务可能涉及数十轮推理，总耗时轻松达到 10-30 秒。这不是优化能解决的，这是概率模型推理的物理极限。
那篇文章提到"高频、低延迟、强一致性要求的交易类场景，短期内微服务仍然是更好的选择"。这个"短期"用得很微妙——它暗示延迟问题会被技术迭代解决。但事实是，推理延迟与模型能力之间存在根本性的权衡。 更大的模型、更长的上下文、更复杂的 CoT（思维链）都会增加延迟。这不是一个会被"摩尔定律"抹平的问题。
这是我最担心的一点，也是那篇文章几乎完全回避的一点。
微服务系统的可靠性可以通过工程手段逼近确定性：熔断、限流、重试、幂等设计、最终一致性保证。这些机制的共同前提是组件行为是可预测的。
Agent 基于 LLM，而 LLM 本质上是概率模型。同样的输入，在不同时间、不同温度参数下，可能产生不同的输出。这意味着：
你无法用传统单元测试"Assert 输出等于期望值"
你无法保证 Agent 在两次相似请求中做出一致的决策
你无法完全排除 Agent 产生"幻觉"并执行错误操作的风险
那篇文章提出的"Eval 替代 Assert"方案，实际上是将质量保障从确定性验证降级为统计性评估。这在学术研究、内容生成、推荐系统等领域是合理的。但在金融交易、医疗诊断、航空管制等高风险领域，"95% 的情况下是对的"远远不够。我并不是在说 Agent 不可靠。我是在说，Agent 的可靠性模型与微服务完全不同，不能简单地用"更先进的架构"来概括。 它引入了一种新的、尚未被充分理解的系统性风险。
让我们回到一个基本问题：Agent 架构的"工具"（Tool）到底是什么？
答案是：它们就是微服务 API。
Google ADK、LangGraph、CrewAI 这些框架并不替代你的订单服务、支付服务、库存服务。它们只是在这些服务之上增加了一个"智能编排层"——用自然语言理解目标，用 LLM 推理决定调用顺序，用工具调用（Function Calling）与实际业务系统交互。
这意味着 Agent 架构的底层依赖仍然是微服务（或单体、或 Serverless）。它不是"从马车到汽车"的替代，而是"在汽车上加装自动驾驶系统"的增强。
这个定位至关重要，因为它决定了迁移策略：
不是"从微服务迁移到 Agent"，而是"在微服务之上增加 Agent 层"。
那篇文章的"三步走"路线图实际上也承认了这一点（第一步就是"在现有微服务之上叠加 Agent 层"），但标题和前半部分的叙事却在制造"必须跨越断层"的焦虑。这种言行不一暴露了文章的真实目的：不是技术教育，而是注意力收割。
如果让我给 2026 年的技术领导者一个决策框架，它会是这样的：
将业务场景按"错误成本"分类：
高容错场景（内部问答、文档生成、营销文案、数据分析探索）：Agent 是优秀候选
中等容错场景（客服、售后、销售辅助）：Agent 可以作为主路径，但需要人工兜底和审批流
低容错场景（支付、交易、库存、核心账务）：Agent 最多作为"建议系统"，决策权必须保留给确定性逻辑
不要只看"Agent 能做什么"，要看"Agent 做这件事要花多少钱"。
一个简单的公式：
Agent 月度成本 = 日均请求量 × 单次平均推理轮数 × 每轮 token 成本 × 30如果这个数字超过你现有微服务集群月度成本的 30%，你需要重新评估。技术选型必须服从商业逻辑。
画出你业务的延迟 SLO（服务等级目标）：
P99 < 100ms：Agent 不适合作为主路径
P99 < 1s：Agent 可能需要异步处理或预计算
P99 < 10s：Agent 可以胜任，但需要优化推理链路
无严格延迟要求：Agent 的理想场景
我见过的最成功的 Agent 落地案例，都遵循一个共同模式：
Phase 1：在现有 API 网关前增加一个"智能路由层"，用 LLM 做意图识别和简单参数提取，实际业务逻辑仍由微服务处理
Phase 2：将部分高频、低风险的查询类请求（如"我的订单状态"）交给 Agent 处理，积累经验
Phase 3：在严格监控和人工兜底机制下，逐步扩展 Agent 的决策权限
从来没有成功案例是一夜之间"All-in Agent"的。 那些声称要"跨越断层"的激进转型，往往以回退和重写告终。
技术社区有一种危险的倾向，我称之为"技术达尔文主义"——将每一次技术演进都包装成"适者生存"的进化压力，暗示不采纳新技术就等于被淘汰。
但技术史告诉我们，演进不是替代，而是叠加。 单体应用没有被微服务杀死，它们以 Serverless 和模块化单体的形式继续存在。SOAP 没有被 REST 杀死，它在企业集成领域依然活跃。关系型数据库没有被 NoSQL 杀死，它们各自找到了适合的战场。
Agent 架构也不会杀死微服务。它会在客服、数据分析、内容生成、运维辅助等领域找到立足点，与微服务长期共存。
作为技术领导者，我们的职责不是被焦虑驱动着追逐每一个新范式，而是在理解新技术的能力边界和成本结构后，做出符合业务现实的理性决策。
那篇文章的结尾说："技术断层从来不是一夜之间出现的，但跨越它的窗口期是有限的。"
我想改写这句话：真正的技术领导力，不在于你跨越了多少道"断层"，而在于你能否分辨哪些是真实的演进，哪些只是被营销放大的焦虑。
Agent 值得投入，但值得冷静地、务实地、有边界地投入。不是因为我们害怕被时代甩下，而是因为我们看清了它能做什么、不能做什么，以及——最重要的是——该不该做。
本文仅代表个人观点，不构成任何技术选型建议。架构决策应基于具体业务场景、团队能力和成本约束综合评估。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。