Agentic工作流赋能微服务！AI代理驱动，现有微服务变身工具，通过API网关协调，实现服务动态编排。关注OpenAPI、gRPC等接口标准化，提升服务自描述能力。Envoy、Kong等传统网关集成AI，Portkey等新型AI网关涌现，MCP协议助力Agent与微服务无缝集成，开发者需拥抱可控的不可预测性！
译自：What Agentic Workflows Mean to Microservices Developers
作者：Janakiram MSV
微服务通过将系统分解为可组合、独立部署的单元，改变了我们构建软件的方式。但随着系统规模的扩大，开发者在认知和运营方面的负担也随之增加——跟踪依赖关系、跨服务调试和管理部署。我们正在达到收益递减的阶段。
Agentic 工作流应运而生：在这种系统中，自主代理解释目标，计划行动，并使用可用的工具执行任务。有趣的是，对于微服务开发者来说，这些工具通常是已经部署在容器化或 Kubernetes 环境中的现有服务。
Agentic 工作流不是微服务的替代品；它们是建立在现有服务调用之上的新协调层。正如微服务抽象了单个组件一样，agentic 工作流抽象了整个工作流。开发工作从手动连接服务转变为使智能代理能够动态地执行此操作。
正如微服务抽象了单个组件一样，agentic 工作流抽象了整个工作流。
在传统环境中编排微服务和在 agentic 环境中编排微服务之间的根本区别在于调用和流程的确定方式。微服务编排在某种程度上是确定性的，并且遵循特定的路径。例如，执行定义良好且紧密集成的服务调用以完成诸如退款处理之类的工作流。同时，在 agentic 工作流中，具有访问所有相关微服务权限的强大 AI 模型会动态决定哪些服务将参与工作流。在 AI 模型中注册的服务将成为执行操作的工具，以响应模型做出的决策。
在传统的微服务架构中，服务旨在通过 API、命令行界面（CLI）和仪表板供其他服务或人工操作员使用。但是，在 agentic 工作流中，使用者不再是人，而是代理。这种细微的转变改变了我们对服务角色的看法。
这种 agentic 方法从根本上改变了开发者组合微服务之间交互的方式。虽然仍然遵循松散耦合服务、无状态服务、异步执行和其他最佳实践，但工作流的入口点和出口点主要取决于 AI 模型来决定。
当这些代理（使用您现有的微服务作为工具）开始自动化以前需要手动编排的复杂流程时，核心价值就会显现出来。诸如事件响应、资源扩展和跨服务调试之类的任务从手动过程转变为自我执行的工作流，从而使开发者可以专注于更高级别的问题。
精心设计的微服务已经具备了使其成为 agentic 系统理想构建块的特性。它们的有界上下文、定义良好的接口和操作独立性为代理交互创建了自然的边界。考虑一个典型的电子商务平台，其中包含订单处理、库存管理和通知服务——每个服务都成为代理可以利用的专用工具，以实现更广泛的业务目标。
关键的区别在于如何利用这些服务。在传统架构中，服务响应来自其他服务或客户端应用程序的直接调用。在 agentic 工作流中，服务响应代理，这些代理会根据上下文做出关于何时以及如何调用它们的决策。“订单履行代理”可能会监视库存水平，根据客户 SLA 确定订单的优先级，并在履行服务之间进行协调，而无需更改那些底层服务。
为了使微服务“为代理做好准备”，开发者应强调以下几点：
- 自我描述：通过标准化接口描述（OpenAPI、gRPC 等）记录其功能的服务允许代理发现它们支持哪些操作。
- 状态透明：通过定义良好的指标和运行状况端点公开其内部状态的服务使代理能够就其利用率做出明智的决策。
- 幂等操作：支持重试和重复请求处理的服务适应代理的自主执行模式。
许多开发者发现他们已经将这些模式集成到微服务最佳实践中。投资于清晰的接口、适当的错误处理和全面的可观测性，在与 agentic 工作流连接时会产生显着的效益。 微服务为我们提供了可组合性。Agentic 工作流为我们提供了可编程的协调能力。
开发重点不再是重建服务，而是转向提高可发现性和稳健性，从而确保服务成为 agent 工具库中可靠的工具。
与从头开始构建 agent 功能相比，这种方法显著降低了开发开销。例如，您现有的身份验证服务不需要重写，只需要能够被身份管理 agent 发现和使用，这些 agent 可以对访问模式和安全风险做出复杂的决策。
API 网关已经是许多微服务架构的核心，自然会演变为 agentic 工作流的协调中心。开发人员无需构建新的 agent 通信基础设施，而是可以利用现有的网关投资作为连接 agent 与其编排的服务的神经系统。
在传统的实现中，API 网关主要处理路由、身份验证和请求转换。对于 agentic 工作流，这些网关承担了扩展的职责，而无需进行重大的架构更改。
- 服务发现变成 agent 发现： 帮助服务相互发现的完全相同的注册机制现在使 agent 能够发现可用的工具。通过扩展服务元数据以包括与 agent 相关的能力，网关有助于 agent 动态选择工具。
- 请求路由演变为工作流编排： 网关不再只是将请求路由到预定义的目的地，而是可以支持 agent 确定的路由路径，其中链中的下一个服务是根据运行时条件和 agent 目标选择的。
- 速率限制转变为资源治理： 现有的限制机制保护单个服务并规范 agent 如何跨系统消耗资源，从而防止激进的 agent 行为产生级联效应。
这里的开发工作是渐进式的，而不是革命性的。已经处理身份验证的网关可以扩展为支持 agent 身份和授权范围。现有的日志记录和跟踪功能对于观察 agent 决策模式和排除自主工作流的故障至关重要。
MCP 标志着微服务架构中 agentic 工作流的重大进步。
对于开发人员来说，这种方法最大限度地减少了新的基础设施，同时最大限度地利用了现有功能。为您的微服务提供支持的 Kong、Ambassador 或自定义网关成为 agent 协调的基础，重点是增强功能，而不是完全替换。
这种演变反映了微服务本身的历程：从有效的方法开始，逐步增强，避免破坏性的重写。通过将您的 API 网关定位为 agent 的协调中心，您可以建立一个自然的控制点，用于观察、管理和发展整个生态系统中的 agent 行为。
Anthropic 新兴的 模型上下文协议 (MCP) 标志着微服务架构中 agentic 工作流的重大进步。通过标准化 AI agent 接收上下文信息、访问工具和处理事件的方式，MCP 在 agent 和它们编排的微服务之间建立了一致的接口层。该协议使 agent 能够理解服务能力，在交互过程中保持上下文感知，并与现有的 API 基础设施（如 API 网关）无缝集成。
对于开发人员来说，MCP 通过为上下文共享、工具发现和执行流程提供结构化的格式，简化了 agent-服务通信的实现复杂性。随着 agentic 工作流的进展，采用 MCP 使微服务团队能够准备好他们的服务以“支持 agent”，同时确保技术独立性，从而创建一个生态系统，其中来自不同提供商的 agent 可以可靠地与跨组织边界的服务进行交互。
传统的 API 网关，如 Envoy、Kong 和 Cloudflare 正在增加 AI 功能以支持 agentic 工作流。像 Portkey 这样的 Greenfield AI 网关对于将大型语言模型 (LLM) 与微服务集成至关重要。
采用 agentic 工作流从根本上改变了开发人员与微服务系统交互的方式。开发人员不再直接编排服务交互，而是定义 agent 用于自主导航服务环境的目标、约束和决策标准。
这种转变要求开发人员培养新的能力。调试不再是跟踪特定请求，而是分析跨多个服务的代理决策模式。成功指标从服务可用性转变为目标达成率。测试扩展到包括模拟各种条件，以验证代理在不确定性下的行为。
工具领域通过增强的可观测性平台来弥合这一差距，这些平台可以可视化代理决策过程，策略编辑器可以将业务规则转换为代理约束，仿真环境可以在生产部署之前测试代理行为。
最重要的思维模式转变是拥抱可控的不可预测性。与确定性的服务调用不同，代理会做出运行时决策，这些决策可以遵循不同的路径来实现相同的目标。开发人员学会指定成功的样子，而不是确切地说明如何实现它——这是一个深刻的转变，最终提供了更具弹性、适应性的系统，同时减少了管理复杂服务交互的认知负担。
建立有效的防护措施对于这种开发方法至关重要。通过实施明确的约束、资源限制和熔断器，开发人员可以创建安全边界，代理可以在其中自主运行。这些防护措施可以防止级联故障，保护关键服务免受过度负载的影响，并确保代理即使在适应不断变化的环境时也能与业务优先级保持一致。正确实施防护措施可以在代理灵活性和系统稳定性之间取得平衡，从而在不牺牲可靠性的前提下实现自主运行。
Agentic 工作流开辟了强大的新可能性，但它们不是魔法，也不是免费的。为自主编排进行设计会带来新的挑战。
首先，代理的质量取决于它们所依赖的接口。模糊的 API、不一致的行为或不明确的错误处理可能会导致错误的决策。与人类开发人员不同，代理不会“更清楚”——它会根据它所能看到和推理的内容来执行。这使得清晰性、一致性和可观测性成为不可协商的要素。
其次，代理引入了不确定性：行动是动态的，计划是概率性的，结果可能会有所不同。这需要新的方法来测试、验证和审计工作流——不仅在单元级别，而且在行为级别。
但尽管存在这些挑战，机会依然清晰。微服务为我们提供了可组合性。Agentic 工作流为我们提供了可编程的协调——一种将例行决策转移到可以代表我们行动的系统的方法，使用我们已经构建的服务。
对于微服务开发人员来说，这并不是要放弃最佳实践，而是要发展它们。首先将您的服务公开为工具。在构建时要牢记意图。并将 Agentic 工作流视为下一个抽象层，而不是一种破坏——在这里，推理与执行相遇。