第9章 生产环境中运行智能体 应用程序
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
在第8章中,我们探讨了人工智能驱动应用程序的架构模式,并在概念层面介绍了智能体工作流。 现在我们将视角从架构转向实际挑战——如何在生产环境中运行这些系统。 由于2026年的人工智能领域仍在快速演变,技术细节可能在数月内就过时。 与其罗列可能消失的框架,我们更专注于那些跨越工具与标准的持久化运维模式。 我们的目标是提供可适配任何框架的指导原则。
本章将探讨在Kubernetes上运行智能体应用的三大核心挑战:
- 安全
-
代理程序常代表用户与外部工具( )及数据源交互。您需要强大的身份管理、认证模式和授权控制机制,在保障用户上下文完整性的同时,允许代理程序自主运作。
- 智能体协同
-
多智能体系统需要标准化通信协议。智能体必须发现彼此的能力,跨服务边界分配任务并追踪进度。
- 状态管理
-
与无状态的REST API不同,智能体需在多次交互中维持对话上下文。生产环境部署需采用持久化存储模式,确保在Pod重启后数据不丢失并支持水平扩展。
本章涵盖两种协议 ,它们在2024年末已成为代理通信的事实标准。 模型上下文协议(MCP)规范了代理与工具间的通信,而代理间协议(A2A)则规范了代理间的协同机制。 这些并非官方标准机构制定的理论规范,但OpenAI、谷歌、微软、AWS等行业巨头及开源社区已达成共识。 2025年成立的智能体AI基金会 为这些标准化工作提供了中立平台(详见侧边栏)。
首先让我们探讨模型上下文协议,该协议为智能体提供了连接所需工具和数据源的标准化方式,从而完成工作任务。
模型上下文协议
模型上下文协议(MCP)是 推出的开放协议,可让AI驱动的智能体以一致、结构化的方式连接外部工具、数据源及服务。 该协议由Anthropic于2024年末推出,被称为"AI应用的USB-C接口",因其解决了早期工具调用方案的集成痛点,迅速成为智能体与工具互操作性的事实标准。 在MCP出现之前,框架采用临时API调用、专有插件和无法扩展的M×N集成方案,工具间上下文传递过程脆弱且易出错。 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access