AI Agent 为何在重演 2019 年微服务的错误

O'Reilly Radar· Shania Rasheed Nalagath·2026-11-09 19:55· 2 小时前AI 评分63

为什么 AI 智能体正在重蹈 2019 年微服务的覆辙

AI 导读

作者复盘一次多智能体工作流的质量滑坡：每个 Agent 都按设计运行，却因摘要 Agent 丢弃了一个低信号字段导致下游给出错误推荐，排查耗时三周。

正文 · 原文

微服务通过将大型应用拆分为更小、可独立部署的服务，改变了我们构建软件的方式。这让系统更易于开发和扩展，但也引入了一类不同的问题：整个系统的行为变得更难观察。AI 智能体如今正走上类似的道路。一个原本存在于单个应用内的工作流被拆分到多个智能体上，每个智能体负责一项任务。各个部分可能完全按设计运行，而整体工作流却逐渐产出更差的结果。区别在于，智能体让这类系统的创建变得快得多、便宜得多，从而更容易在更大规模上重蹈同样的架构错误。

我是通过惨痛教训才明白这一点的。那份设计文档上署着我的名字。把那个工作流拆分到三个智能体上是一个合理的决定，我至今仍会为其中大部分推理辩护。但如果你那天下午问我，当这套东西悄悄停止正常工作时我们该如何发现，我答不上来。

几个月后，在一次质量评审中，一位评审者在我们的任何监控手段察觉之前就感觉有些不对劲。延迟看起来正常，错误率平稳，链条中的每个服务都返回了它应该返回的内容。我们面对的是输出质量的缓慢下滑，而追查它花了大约三周时间。

第一个智能体将一组文档交给下一个进行摘要。摘要器丢弃了一个它判定为低信号的字段。下游智能体在没有该字段的情况下给出了一个自信的推荐。每个智能体都做了它被设计要做的事，结果却仍然是错的。我本应预见到这一点，因为我在微服务那些年里一直身处产品侧，以前见过这种模式。

我们已经付过代价的宿醉

对大多数团队来说，拆分单体应用是个好决定，但有一件事被遗忘了。分解并没有让系统中困难的部分消失。它把它们移到了服务之间的缝隙里，在那里，对整体产品负责的人再也看不到它们。账单大约在 2019 年到期，而且落在交付进度上，而不是事故频道里。团队运行着数百个服务，追踪能力有限，也没有契约版本管理，真正的症状是交付变慢。发布比以往耗时更长，因为工程师们把数周时间花在翻查那些服务上。

智能体正以更快的速度走完同样的弧线，因为搭建一个智能体只需一个下午加一段提示词，而不是一个代码仓库和一条部署流水线。当创建智能体如此廉价时，产品团队不请示任何人就造出智能体，也没人跟踪这些智能体是什么、在做什么。

什么会坏，以及它让你付出什么代价

这不仅仅是我的经历。Cemri 及其合著者标注了七个流行多智能体框架中的 1600 多条执行轨迹，并构建了一个包含 14 种反复出现的失败模式的分类体系（MAST，NeurIPS 2025）。出问题的大多数情况都可追溯到系统是如何被定义的、其智能体是如何协调的，而不是其中的模型。

清单听起来微不足道，其实并非如此。服务蔓延至少还会体现在你的 Kubernetes 清单里。而智能体是在产品界面和工作流工具内部被创建的，也在某个人为自己工作做的周末自动化里被创建。直到合规审查者问起哪个自动化系统碰过某个特定决策时，你才会发现你手里到底有什么，而那时已经太晚了。

可见性缺口让我们付出了三周代价。当一个智能体调用另一个智能体，后者又调用一个检索层，检索层再调用另一个智能体，而每一跳都有一个模型在决定要往前传什么时，你需要能贯穿整条路径的追踪上下文。大多数技术栈只按每次调用记录提示词和补全结果，然后就到此为止。你拿到了每一跳，却永远拿不到整条链，而失败的恰恰是整条链。

复合置信是我最担心的失败模式。分布式系统会大声失败，这后来成了没人领情的好事。一个服务抛出 500，调用方就知道该停下。智能体则会安静而流畅地失败，所以当上游智能体产出一份看似合理却错误的摘要时，下游智能体收不到任何信号，还会在此基础上自信地推理。等结果送到用户手里时，它传达出的置信度是初始证据根本支撑不了的。

当有人改了响应格式却没有做版本管理时，API 契约就漂移了，我们为此建了机制在构建时抓住它。而当有人编辑系统提示词时，智能体契约就漂移了。这种情况下没有 schema diff，也没有类型检查。什么都不会坏，直到下游智能体开始收到不同的输出，并在不告诉任何人的情况下适应了它。

从微服务继承下来的东西

注册表是最便宜该建的东西，也是所有人最先跳过的东西。构建微服务时，我们维护一个服务目录，记录每个服务的负责人和范围。对智能体，我们需要同样的记录，外加一份每个智能体被允许调用什么的明确清单。

追踪几乎原样继承，因为关联 ID 本来就是为这个确切问题发明的。OpenTelemetry 的GenAI 语义约定给了你词汇表，一次智能体运行会以 span 树的形式呈现，而不是一堆互不相关的日志行：

如果我们当时就在发出这些 span，摘要器的 span 和推荐器的 span 就会并排出现在同一条 trace 里，缺失的字段就会变成一次 diff，而不是三周的追查。这些约定仍在演进，所以把属性名放在你自己的薄映射层后面。

在 trace 里找到缺失字段本可以缩短调查。我还想要一个测试，在提示词变更进入生产之前就抓住它的遗漏。这正是我会套用微服务契约测试纪律的地方：定义下游智能体依赖什么，然后检查上游变更是否保留了它。对这个工作流里的摘要器，评估需要检查它的输出是否保留了推荐器所需的信息。我会给提示词做版本管理，并要求变更在发布前通过那些评估。已有早期证据表明这值得：SEMAP 是一种协议层方法，在 Google 的 A2A 基础设施上应用行为契约建模和生命周期验证，据报告在按 MAST 评分时，函数级编码任务的失败率最多降低了约 70%。

信任边界是我在设计评审中要争论的问题。2019 年我们认识到，一个服务不会仅仅因为位于边界之内就被信任，而这正是服务网格存在的主要意义。智能体版本的情况是：一个智能体不会仅仅因为是我们构建的、而且我们是好人，就获得广泛的工具访问权限。智能体被允许做什么，应该放在模型无法用花言巧语绕过的策略层中，而不是放在一个礼貌请求的系统提示词里。

成本是微服务与智能体之间类比失效的地方。一个陷入重试循环的微服务会消耗你的 CPU，并在凌晨 3 点给你一个告警。一个陷入循环的智能体每一轮都会花费真金白银，而且不会以任何能让自己显而易见的方式达到饱和。这个问题落在产品负责人而不是基础设施团队身上，因为它表现为单位经济性而不是服务中断，这意味着 PM 最终要在计费周期结束时为这个数字辩护。

我在批准拆分之前会问的问题

这一切都不是在反对多智能体系统，它们像服务一样证明了自己的价值。我的论点是，运维实践应该与架构同步演进，而不是重蹈上一次转型中长达五年的滞后。负责交付产品的人通常最适合确保这一点发生。

因此，我重点追问四件事。我们能否跟踪一个请求的完整路径，并重建每个智能体决定了什么以及为什么？如果不能，我们就是在构建无法调试的东西。当一个上游智能体出错时会发生什么，而不是它是否会出错？如果诚实的答案是下一个智能体照常继续，那我们就没有设计失败模式。我们设计了一个失败，并让它继续运行。

谁拥有这个智能体，它的工具访问权限在哪里强制执行？系统提示词不是强制执行。在今天的十倍流量下，这要花多少钱，当数字出错时什么会把它关掉？我很早就问这个问题，因为没人会主动提。

最有效地管理服务拆分的团队从一开始就把追踪和契约测试纳入构建过程。这些实践帮助他们理解服务如何交互，并验证变更是否保持了预期行为。这项工作现在是一两个冲刺的事，而当你运行 40 个智能体、有人问其中哪些接触了客户数据时，这就远不止一两个冲刺了。

来源：O'Reilly Radar · oreilly.com