Article: From Microservices to Agents: The Next Evolution of Distributed Systems

从微服务到代理：分布式系统的下一步演进 - InfoQ

InfoQ 首页 文章 从微服务到代理：分布式系统的下一步演进

架构与设计

扩展 OpenTelemetry：管理收集器、配置和成本（11月19日网络研讨会）

从微服务到代理：分布式系统的下一步演进

2026年10月19日 12分钟阅读

作者：

• Mallika Rao

审阅者：

• Rafał Gancarz

#### 关注我们

Youtube

232K 粉丝

Linkedin

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 喜欢

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

• 阅读列表

关键要点

• 代理AI系统将分布式系统设计从协调服务转向协调运行时做出的决策。

• 与微服务不同，代理系统引入了由上下文、推理和工具选择驱动的非确定性执行路径。

• 决策质量成为与延迟、可用性和吞吐量并列的首要可靠性关注点。

• 生产环境中的故障模式通常表现为推理质量的静默退化，而非显式的系统错误。

• 有效的代理架构需要有限的自主性、评估循环和混合确定性回退系统。

本文是“代理AI架构”系列文章的一部分。在本系列中，我们试图将代理AI架构确立为一种新的软件架构类型，这种架构预计将在未来几年主导行业。由行业专家撰写的这些文章涵盖了代理AI架构的各个方面。我们的目标是呈现最新趋势和正在塑造这种新型架构主流化的技术发展。

分布式系统正在进入一个新阶段

过去十年间，微服务重塑了大规模软件系统的设计和运营方式。它们使团队能够将单体架构分解为可独立部署的服务，扩展所有权边界，并逐步演进系统。对于许多组织而言，微服务已成为构建可扩展分布式系统的主流模型。

本质上，微服务解决了根本性问题：如何以支持独立演进的同时保持系统可靠性的方法，在服务和团队之间分解功能。它们引入了明确的服务边界、定义良好的API和可预测的执行流程。

#### 相关赞助商

#### 相关赞助商

• 2026年11月19日 东部时间中午12点 扩展 OpenTelemetry：管理收集器、配置和成本 主讲人：David Iparraguirre - Datadog 高级产品市场经理，Jessica Yang - Datadog 产品经理

代理系统与传统服务在本质上存在根本性差异。它们不再执行预定义逻辑，而是动态决定采取哪些操作、使用哪些工具以及如何编排多步骤推理过程。执行流程不再在设计时完全确定，而是在运行时根据上下文、目标和中间结果动态生成。

这种转变带来了新的能力。系统可以变得更适应性强、更了解上下文，并能更好地处理模糊或不断变化的输入。但同时，它也引入了传统分布式系统思维难以应对的新形式复杂性。

本文旨在深入探讨这一转变：代理AI架构与微服务有何不同，正在出现哪些架构模式，我们在生产系统中开始观察到哪些故障模式，以及可观测性和可靠性实践必须如何演变。讨论基于在搜索、推荐和基础设施服务等领域的大型分布式系统运营经验。

微服务解决了服务分解问题 — 代理解决了决策分解问题

图1：执行模型：微服务与代理系统（来源：作者使用OpenAI ChatGPT创建）

[点击此处查看上方图片全尺寸版本]

微服务架构为构建分布式系统引入了清晰的模型。系统不再是一个单一的单体应用，而是被分解为与业务能力对齐的服务。每个服务拥有一个界定的上下文——明确的责任领域和数据所有权范围——通过API进行通信，并可以独立演进。

这种分解使部署周期更快、所有权边界更清晰，并提升了扩展特性。然而，尽管具有灵活性，微服务仍然依赖确定性执行。请求的控制流通过服务间交互明确定义。

在典型的微服务系统中，请求遵循一条众所周知的路径：进入某个服务后被处理，按定义顺序调用下游服务，最后返回响应。即使在高度复杂的系统中，执行路径在事先已知并编码在系统逻辑中。

代理AI系统引入了不同的执行模型。系统不再提前定义完整操作序列，而是动态确定执行路径。关于调用哪些工具、查询哪些数据源以及应用哪些策略的决策在运行时做出。

这标志着从服务分解向决策分解的转变。系统不再将功能分布到服务中，而是将推理过程分布到参与动态决策循环的组件中。

实际上，这意味着执行不再是固定的流水线，而是适应性过程。系统可能根据上下文选择不同的候选数据源，动态调整排序策略，或根据中间结果重新评估输出。执行结构取决于输入和不断演化的系统状态。

这种变化对我们思考分布式系统的方式产生了深远影响。它带来了灵活性，但也降低了可预测性。它用动态推理路径取代了静态工作流，而这些路径本质上更难追踪和调试。

使代理系统根本不同的因素

图2：Agentic系统架构（来源：作者使用OpenAI ChatGPT创建）

Agentic系统与传统分布式系统在三个关键维度存在差异：控制流、状态管理以及失败语义。

控制流不再固定。在微服务架构中，执行路径在设计阶段就被预先定义和编码。而在Agentic AI系统中，执行路径会根据上下文和中间推理结果在运行时动态确定。这种灵活性带来了系统行为的多样性，因为不同请求可能根据用户意图、检索信息或执行过程中先前的决策触发完全不同的执行路径。

状态也变得更加流动且定义不再严格。传统系统依赖显式的状态转换和明确的持久化模型。相比之下，Agentic系统通常在持续更新的执行上下文中运行，该上下文随着推理过程不断演变。此上下文可能包含对话历史、中间计划、检索文档、排序信号、工具输出或先前的评估结果。

管理这种动态上下文成为系统设计的核心关注点。上下文需要在多个代理、工具和服务之间传播，同时保持足够的一致性以支持后续推理的连贯性。实践中，许多系统引入共享上下文存储、执行作用域内存或结构化推理工件，以避免上下文碎片化和执行步骤间的矛盾决策。随着执行链变长，上下文管理开始呈现出类似早期分布式系统中遇到的分布式状态协调问题。

失败语义也发生了变化。在传统系统中，失败通常是二元的：请求成功或失败，服务响应或超时。而在Agentic系统中，失败往往表现为决策质量的下降。系统可能继续运行但由于推理错误、工具选择不当、上下文过时或对中间结果的不完整解释，导致次优结果。

这些差异从根本上改变了分布式系统在生产环境中的行为方式。它们也要求新的架构模式来管理复杂性、可靠地传播上下文，并在大规模场景下保持可预测的系统行为。

Agentic AI系统中的架构模式

随着Agentic系统开始出现在生产环境中，一些架构模式正在逐渐形成。这些模式并非正式标准，而是帮助管理复杂性和控制决策系统中变化性的常见结构。

一种常见模式是规划与执行职责的分离。在此模型中，规划组件负责解释意图并确定高层次策略，而执行组件则执行确定性操作，如数据检索、转换或排序。这种分离使系统能够将非确定性推理与确定性执行隔离，从而提高可靠性和可追溯性。

第二种模式涉及代理的专业化。与依赖单一通用代理不同，系统越来越多地由多个专业代理组成，每个代理负责特定能力，如检索、排序、评估或编排。这些代理协作以产生最终结果。

这种结构类似于微服务架构中的服务分解，但其应用对象是决策过程而非数据处理逻辑。虽然专业化提升了推理质量和模块化程度，但也引入了协调开销并增加了系统复杂性。延迟变得更加不可预测，故障模式可能通过智能体交互传播。

第三种模式是将评估直接集成到执行循环中。系统不再将评估视为离线过程，而是越来越多地在运行时评估输出结果。根据评估结果，系统可能动态地优化、重试或调整策略。

这为执行过程引入了反馈循环，使系统具备更强的适应性。然而，这也需要谨慎控制以避免过度重试或失控的执行循环。延迟预算、迭代限制和置信度阈值等约束条件对于保持系统稳定性变得至关重要。

另一种新兴模式是引入工具抽象层。随着智能体与越来越多的服务和API交互，团队正在创建标准化的工具使用接口。这些抽象层将智能体推理与底层服务实现解耦，并提供了统一的能力发现和调用机制。

随着时间推移，这种抽象层逐渐演变为一个能力平台，而非单一服务的集合。它成为跨团队和领域扩展智能体系统的关键使能器。在这些模式中，一个共同的主题逐渐显现：复杂性正在从服务编排向决策编排转移。系统不再主要关注服务如何交互，而是关注决策如何被制定、评估和适应。

智能体分布式系统的故障模式

图3：智能体系统中的静默故障模式（来源：作者使用OpenAI ChatGPT创建）

智能体系统引入了与传统分布式架构显著不同的新故障模式。虽然微服务通常因延迟、可用性问题或数据不一致性而失败，但智能体系统往往因决策质量下降而失效。

一个重要的故障模式是决策质量的级联退化。在传统流水线中，故障通过显式依赖关系传播。在智能体系统中，早期的错误决策可能微妙地影响下游推理，导致输出质量的退化累积。例如，如果系统在执行早期选择了次优的候选源，后续的排序和评估步骤将基于质量较低的输入进行操作，从而放大初始错误。

这种模式在大规模搜索和推荐系统中尤为相关，因为早期候选生成阶段对下游排序质量有显著影响。即使基础设施保持健康，早期决策的小幅变化也可能导致系统结果的明显变化。

另一种故障模式是评估循环驱动的重试放大。智能体系统通常包含评估输出质量并重试的机制。虽然这提高了适应性，但也可能导致过多的迭代循环。与传统重试机制（与显式错误绑定）不同，这些重试由主观质量判断驱动，使其更难以界定和控制。

如果没有适当的约束，评估驱动的重试可能会增加延迟、放大后端负载，并导致不可预测的执行模式。

第三种故障模式是静默质量退化。在许多情况下，系统性能可能在不触发传统运维告警的情况下逐渐下降。基础设施指标（如延迟和错误率）可能保持稳定，但用户感知的质量会因决策行为的变化而恶化。

这种情况在依赖排序、个性化或推荐逻辑的系统中尤为常见。工具选择、推理策略或上下文解释的微小变化可能随时间累积，导致系统行为发生渐进但显著的变化。检测这些问题需要具备评估意识的监控，而非以基础设施为中心的可观测性。

协调开销和延迟累积也逐渐成为重要问题。随着系统将推理过程分布到多个代理中，执行路径会变得更为复杂且难以预测。每个额外的协调步骤都会引入延迟的不确定性，并增加部分失败的风险。

最后，状态漂移和上下文不一致可能导致多步骤执行流程中的推理错误。当上下文在代理或步骤之间逐步更新时，状态传播的不一致性可能导致矛盾或不完整的决策。这类似于分布式系统中的一致性挑战，但表现为推理漂移而非数据不一致。

代理系统的可观测性与可靠性

基于延迟、吞吐量和错误率等指标的传统可观测性模型仍然必要，但不足以应对代理系统。需要一个新的可观测性维度：决策质量。

除了观察系统健康状况，团队还必须观察决策是如何做出的。这包括追踪工具选择、推理步骤、中间输出和评估结果。决策级别的追踪能够揭示系统行为随时间演变的方式以及退化来源。

监控系统行为的变化也变得至关重要。随着时间推移，工具使用模式、策略选择频率、回退率或重试行为的变化可能表明系统的决策过程正在发生偏移。例如，重试次数的突然增加或对单一策略的强烈偏好可能预示着推理质量下降、上下文过时或评估信号不佳。

这些行为变化通常比传统用户感知指标（如参与度或延迟）更早暴露问题。因此，观察决策在系统中的分布情况可以作为早期预警机制，在质量退化变得运维可见之前就检测到问题。

评估基础设施在可靠性中发挥核心作用。评估不应被视为离线验证机制，而是运行时系统的一部分。它通过反馈循环引导执行并帮助维持质量。然而，这些循环必须受到严格约束，以避免过度迭代或不稳定。

代理AI架构的可靠性还依赖于有限自主性。系统必须在明确的约束范围内运行，例如延迟预算、重试限制和推理深度边界。这些约束确保灵活性不会以可预测性为代价。

回退机制仍然至关重要。当智能代理推理变得不确定或系统置信度较低时，确定性执行路径能提供稳定性。在许多生产系统中，结合智能代理决策与确定性回退流程的混合架构，在灵活性和可靠性之间提供了务实的平衡。

渐进式部署策略同样关键。基于AI的功能应通过实验、影子执行和受控部署逐步引入。这使团队能够建立对系统行为的信心，同时限制风险暴露。

最终，智能代理系统的可靠性需要思维方式的转变。系统不应将故障视为二元事件，而应设计为在决策质量下降时能优雅退化，同时保持可预测的用户体验。

前景展望

智能代理AI架构代表了分布式系统的自然演进。微服务实现了功能的解耦；智能代理系统实现了决策的解耦。

这种转变带来了适应性、个性化和动态执行的新能力。同时也带来了可观测性、可靠性和系统设计的新挑战。

最重要的影响是，分布式系统不再仅仅是服务编排。它们越来越多地涉及决策编排。这需要将已有的分布式系统工程原则扩展到新的抽象层次。

当组织采用智能代理架构时，成功将取决于灵活性与纪律性的结合。使微服务实现扩展的相同原则——清晰的边界、可观测性、可靠性工程和平台思维——在这个新范式中同样至关重要。

我们仍处于这一转变的早期阶段。然而，方向已经变得清晰。分布式系统正在从执行工作流的系统演变为做出决策的系统。理解和塑造这一转变将定义下一代大规模软件架构。

作者信息主容器

关于作者

章节标题

每位作者的主要信息容器

#### Mallika Rao

显示更多

显示更少

#### 本内容属于人工智能主题

##### 相关主题：

• 架构与设计

• AI、机器学习与数据工程

• 智能代理架构系列

• 智能代理架构

• 大型语言模型

• AI架构

• 分布式系统

• 微服务

• 人工智能

• 架构

• 相关编辑内容

• InfoQ热门内容

• Cloudflare新收购Vite+ 1.0版本支持GitLab CI、钩子和tsup迁移

• Cloudflare的OHTTP网关拒绝解密通过Cloudflare传输的请求

• 反向工程任何项目：将AI代理引入二进制分析

• Google Antigravity SDK增加本地模型支持以提高令牌效率和代码隐私

• AWS推出Strands Decider 2B和Strands Box用于AI代理开发

• Web应用的未来：AI代理是否会实时生成UI？

InfoQ新闻通讯

每周五发送InfoQ最新内容摘要。加入超过25万名高级开发者的社区。查看示例

我们保护您的隐私。