谷歌白皮书:从原型到生产

编者按： 这份 Google 的《从原型到生产》(Prototype to Production) 白皮书是非常前沿且实用的工程指南，涵盖了从 AI 智能体（Agent）的构建、评估、部署到运维的全生命周期。

从预测性 AI 到自主代理

人工智能正在发生变革。多年来，重点一直放在那些擅长被动、离散任务的模型上：回答问题、翻译文本或根据提示生成图像。这种范式虽然强大，但每一步都需要持续的人工指导。我们现在正见证范式的转变，从仅仅预测或创建内容的 AI，转向一类能够自主解决问题和执行任务的新型软件。

这个新前沿围绕着 AI 代理（AI Agents）构建。代理不仅仅是静态工作流中的 AI 模型；它是一个完整的应用程序，能够制定计划并采取行动以实现目标。它结合了语言模型（LM）的推理能力与采取行动的实践能力，使其能够处理模型本身无法独自完成的复杂、多步骤任务。关键能力在于代理可以独立工作，自行找出实现目标所需的后续步骤，而无需人类在每一步进行指导。

本文档是五部分系列文章的第五篇，涵盖了从“非确定性世界”到“智能体质量评价艺术”的核心深度内容。

从原型到生产
Prototype to Production

作者：
Sokratis Kartakis, Gabriela Hernandez Larios,
Ran Li, Elia Secchi, and Huang Xia

出品：
Google

发布时间：
2025年11月

致谢
内容贡献者： Derek Egan, Chase Lyall, Anant Nawalgaria, Lavi Nigam, Kanchana Patlolla, Michael Vakoc
策展与编辑： Anant Nawalgaria, Kanchana Patlolla
设计： Michael Lanning

摘要
(5)
引言：从原型到生产
(6)
人员与流程
(8)
通往生产的旅程
(11)
评估作为质量门控 (12)
自动化 CI/CD 流水线 (13)
安全的发布策略 (15)
从一开始就构建安全性 (17)
生产中的运维
(19)
观察：智能体的感知系统 (19)
行动：运维控制的杠杆 (20)
管理系统健康：性能、成本和规模 (20)
管理风险：安全响应手册 (22)
进化：从生产中学习 (22)
进化的引擎：通往生产的自动化路径 (23)
进化工作流：从洞察到部署改进 (24)
进化安全性：生产反馈循环 (25)
超越单智能体运维
(26)
A2A - 复用性和标准化 (27)
A2A 协议：从概念到实现 (28)
A2A 和 MCP 如何协同工作 (33)
注册表架构：何时以及如何构建 (35)
融会贯通：AgentOps 生命周期
(36)
结论：用 AgentOps 跨越“最后一公里”
(38)
尾注
(40)

摘要

构建一个智能体（Agent）很容易。但信任它很难。

本白皮书为 AI 智能体的运维生命周期提供了一份全面的技术指南，重点关注部署、扩展和生产化。基于之前的“第 4 天：评估与可观测性”内容，本指南强调了如何通过强大的 CI/CD 流水线和可扩展的基础设施来建立必要的信任，从而将智能体投入生产环境。它探讨了将基于智能体的系统从原型过渡到企业级解决方案所面临的挑战，并特别关注了智能体对智能体（Agent2Agent, A2A）的互操作性。本指南为 AI/ML 工程师、DevOps 专业人员和系统架构师提供了实用的见解。

引言：从原型到生产

你可以在几分钟甚至几秒钟内启动一个 AI 智能体原型。但是，要把那个聪明的演示变成一个你的企业可以依赖的、值得信赖的生产级系统呢？那才是真正工作的开始。欢迎来到“最后一公里”的生产差距，我们在与客户的实践中一致观察到，大约 80% 的精力并非花在智能体的核心智能上，而是花在使其可靠和安全所需的基础设施、安全性和验证上。

跳过这些最后步骤可能会导致几个问题。例如：

一个客户服务智能体被诱骗免费赠送产品，因为你忘记设置正确的护栏。
用户发现他们可以通过你的智能体访问内部机密数据库，因为身份验证配置不当。
一个智能体在周末产生了一笔巨额消费账单，但没有人知道原因，因为你没有设置任何监控。
一个昨天还完美运行的关键智能体突然停止工作，但你的团队却手忙脚乱，因为没有部署持续评估机制。

这些不仅仅是技术问题；它们是重大的业务失败。虽然 DevOps 和 MLOps 的原则提供了重要的基础，但仅靠它们是不够的。部署代理系统（Agentic Systems）引入了一类新的挑战，要求我们的运维规程进行进化。与传统的机器学习模型不同，智能体是自主交互的、有状态的，并且遵循动态的执行路径。

这就造成了独特的运维难题，需要专门的策略：

动态工具编排：
智能体的“轨迹”是随着它选择工具而动态生成的。这需要对一个每次行为都可能不同的系统进行强大的版本控制、访问控制和可观测性管理。
可扩展的状态管理：
智能体可以跨交互记忆事物。在大规模下安全且一致地管理会话和内存是一个复杂的系统设计问题。
不可预测的成本与延迟：
智能体可能通过许多不同的路径来找到答案，这使得如果不采用智能预算和缓存，其成本和响应时间将极其难以预测和控制。

为了成功应对这些挑战，你需要建立在一个由三大支柱构成的基础上：自动化评估、自动化部署 (CI/CD) 和 全面的可观测性。

本白皮书是你建立这一基础并导航通往生产之路的分步手册！我们将从生产前的要素开始，向你展示如何设置自动化 CI/CD 流水线，并使用严格的评估作为关键的质量检查。随后，我们将深入探讨在现实环境中运行智能体的挑战，涵盖扩展策略、性能调优和实时监控。最后，我们将通过智能体对智能体（Agent-to-Agent）协议展望多智能体系统的激动人心的未来，并探索让它们安全有效地进行通信需要什么。

实践实施指南
在本白皮书中，实践示例参考了 Google Cloud Platform Agent Starter Pack [1]。这是一个 Python 包，为 Google Cloud 提供了生产就绪的生成式 AI 智能体模板。它包括预构建的智能体、自动化 CI/CD 设置、Terraform 部署、Vertex AI 评估集成以及内置的 Google Cloud 可观测性。该入门包通过你可以分分钟部署的工作代码演示了本文讨论的概念。

人员与流程

在讨论了 CI/CD、可观测性和动态流水线之后，为什么要关注人员和流程？因为如果没有合适的团队来构建、管理和治理，世界上最好的技术也是无效的。

那个客户服务智能体不会因为魔法而不去免费赠送产品；是 AI 工程师和提示词工程师（Prompt Engineer）设计并实施了护栏。机密数据库不是被一个抽象概念保护的；是云平台团队配置了身份验证。每一个成功的生产级智能体背后，都有一个协调良好的专家团队，在本节中，我们将介绍这些关键角色。

[图表 1：展示“Ops”（运维）是人员、流程和技术交集的图表]

图 1：MLOps = 人员 + 流程 + 技术

传统 MLOps 版图中的关键团队：

云平台团队 (Cloud Platform Team)：
由云架构师、管理员和安全专家组成，该团队管理基础云设施、安全性和访问控制。团队授予工程师和服务账户最小权限角色，确保仅访问必要的资源。
数据工程团队 (Data Engineering Team)：
数据工程师和数据所有者构建并维护数据流水线，处理摄取、准备和质量标准。
数据科学与 MLOps 团队 (Data Science and MLOps Team)：
包括进行实验和训练模型的数据科学家，以及使用 CI/CD 自动化端到端 ML 流水线（如预处理、训练、后处理）并进行扩展的 ML 工程师。MLOps 工程师通过构建和维护标准化的流水线基础设施来提供支持。
机器学习治理 (Machine Learning Governance)：
这个中心化职能部门（包括产品负责人和审计员）监督 ML 生命周期，充当工件和指标的存储库，以确保合规性、透明度和问责制。

生成式 AI 引入的新复杂性和专门角色：

提示词工程师 (Prompt Engineers)：
虽然这个职位的头衔在行业中仍在演变，但这些人将编写提示词的技术技能与深厚的领域专业知识相结合。他们定义向模型提出的正确问题和预期的答案，尽管在实践中，这项工作可能由 AI 工程师、领域专家或专门的专家完成，具体取决于组织的成熟度。
AI 工程师 (AI Engineers)：
他们负责将生成式 AI (GenAI) 解决方案扩展到生产环境，构建强大的后端系统，整合大规模评估、护栏和 RAG/工具集成。
DevOps/应用开发者 (App Developers)：
这些开发者构建前端组件和用户友好的界面，与 GenAI 后端集成。

组织的规模和结构将影响这些角色；在较小的公司中，个人可能身兼数职，而成熟的组织将拥有更专业化的团队。有效地协调所有这些不同的角色，对于建立稳健的运维基础并成功地将传统 ML 和生成式 AI 计划投入生产至关重要。

[图表 2：展示多个团队如何协作以运维模型和 GenAI 应用的流程图]

图 2：多团队协作流程图 - 从 AI 治理、云平台、数据科学到 GenAI 应用开发

通往生产的旅程

既然我们已经建立了团队，现在我们转向流程。我们如何将所有这些专家的工作转化为一个值得信赖、可靠且可供用户使用的系统？

答案在于建立在单一核心原则之上的严格的预生产流程：评估门控部署 (Evaluation-Gated Deployment)。这个想法简单而强大：没有任何智能体版本应该在没有通过证明其质量和安全性的全面评估之前就触达用户。这个预生产阶段是我们用自动化信心交换人工不确定性的地方，它由三个支柱组成：作为质量门控的严格评估流程、强制执行该流程的自动化 CI/CD 流水线，以及用于降低最后一步进入生产环境风险的安全发布策略。

评估作为质量门控

为什么我们需要为智能体设置专门的质量门控？传统的软件测试对于能够推理和适应的系统来说是不够的。此外，评估智能体不同于评估大语言模型 (LLM)；它不仅需要评估最终答案，还需要评估为完成任务而采取的整个推理轨迹和行动。一个智能体可能通过了 100 个工具单元测试，但仍然因为选择了错误的工具或产生幻觉而彻底失败。我们需要评估其行为质量，而不仅仅是功能正确性。这个门控可以通过两种主要方式实施：

人工“Pre-PR”评估：
对于寻求灵活性或刚开始评估之旅的团队，质量门控通过团队流程来执行。在提交拉取请求 (Pull Request, PR) 之前，AI 工程师或提示词工程师（或组织中负责智能体行为的任何人）在本地运行评估套件。生成的性能报告——将新智能体与生产基线进行比较——随后被链接在 PR 描述中。这使得评估结果成为人工审查的强制性工件。审查者——通常是另一位 AI 工程师或机器学习治理人员——现在不仅要评估代码，还要评估智能体针对护栏违规和提示注入漏洞的行为变化。
自动化流水线内门控：
对于成熟的团队，评估工具——由数据科学和 MLOps 团队构建和维护——直接集成到 CI/CD 流水线中。评估失败会自动阻止部署，提供机器学习治理团队定义的质量标准的刚性、程序化强制执行。这种方法用自动化的那种一致性换取了人工审查的灵活性。CI/CD 流水线可以配置为自动触发评估作业，将新智能体的响应与黄金数据集进行比较。如果关键指标（例如“工具调用成功率”或“有用性”）低于预定义的阈值，部署将在程序上被阻止。

无论采用哪种方法，原则都是一样的：没有质量检查，智能体就不能进入生产环境。我们在之前的深度文章《智能体质量：可观测性、日志、追踪、评估、指标》中涵盖了测量内容和如何构建评估工具的细节，探讨了从制作“黄金数据集”（一组旨在评估智能体预期行为和护栏合规性的经过策划的、具有代表性的测试用例）到实施“LLM作为裁判”技术，最后使用 Vertex AI Evaluation 等服务来驱动评估的所有内容。

自动化 CI/CD 流水线

AI 智能体是一个复合系统，不仅包含源代码，还包含提示词、工具定义和配置文件。这种复杂性带来了重大挑战：我们如何确保对提示词的更改不会降低工具的性能？在触达用户之前，我们如何测试所有这些工件之间的相互作用？

解决方案是 CI/CD（持续集成/持续部署） 流水线。它不仅仅是一个自动化脚本；它是一个结构化的流程，帮助团队中的不同人员协作管理复杂性并确保质量。它的工作原理是分阶段测试更改，在智能体发布给用户之前逐步建立信心。

一个健壮的流水线被设计成一个漏斗。它尽可能早且低成本地捕获错误，这种做法通常称为“左移 (shifting left)”。它将快速的合并前检查与更全面的、资源密集型的合并后部署分离开来。这个渐进式工作流通常构建为三个不同的阶段：

阶段 1：合并前集成 (Pre-Merge Integration, CI)。
流水线的首要责任是向打开拉取请求的 AI 工程师或提示词工程师提供快速反馈。此 CI 阶段自动触发，充当主分支的守门人。它运行快速检查，如单元测试、代码 Linting 和依赖项扫描。至关重要的是，这是运行由提示词工程师设计的智能体质量评估套件的理想阶段。这提供了关于更改是否在合并之前改善或降低了智能体针对关键场景的性能的即时反馈。通过在这里捕获问题，我们防止了污染主分支。使用 Agent Starter Pack (ASP) 生成的 PR 检查配置模板 [3] 是使用 Cloud Build [4] 实现此阶段的一个实践示例。
阶段 2：预发布环境中的合并后验证 (Post-Merge Validation in Staging, CD)。
一旦更改通过所有 CI 检查——包括性能评估——并被合并，重点就从代码和性能正确性转移到集成系统的运维就绪状态。通常由 MLOps 团队管理的持续部署 (CD) 流程将智能体打包并部署到预发布 (Staging) 环境——一个生产环境的高保真副本。在这里，运行更全面、资源密集型的测试，例如负载测试和针对远程服务的集成测试。这也是内部用户测试（通常称为“吃自己的狗粮 / dogfooding”）的关键阶段，公司内部的人员可以与智能体互动并在其触达最终用户之前提供定性反馈。这确保了智能体作为一个集成系统在被考虑发布之前，在类生产条件下表现可靠且高效。ASP 的预发布部署模板 [5] 展示了这种部署的示例。
阶段 3：门控部署到生产环境 (Gated Deployment to Production)。
在智能体在预发布环境中经过彻底验证后，最后一步是部署到生产环境。这几乎从未是完全自动的，通常需要产品负责人给予最终签字，确保“人类介入 (human-in-the-loop)”。一旦批准，在预发布环境中经过测试和验证的确切部署工件将被晋升到生产环境。ASP 生成的生产部署模板 [6] 展示了这一最终阶段如何检索经过验证的工件并在适当的保障措施下将其部署到生产环境。

[图表 3：CI/CD 流程的不同阶段]

图 3：CI 流水线 -> CD 流水线 1 (Staging) -> CD 流水线 2 (Prod, 带人工审批)

实现这三阶段 CI/CD 工作流需要强大的自动化基础设施和适当的机密信息管理。这种自动化由两项关键技术提供支持：

基础设施即代码 (IaC)：
像 Terraform 这样的工具以编程方式定义环境，确保它们是相同的、可重复的且受版本控制的。例如，Agent Starter Pack 生成的此模板 [7] 提供了完整智能体基础设施的 Terraform 配置，包括 Vertex AI、Cloud Run 和 BigQuery 资源。
自动化测试框架：
像 Pytest 这样的框架在每个阶段执行测试和评估，处理智能体特有的工件，如对话历史、工具调用日志和动态推理追踪。

此外，像 API 密钥这样的敏感信息应使用 Secret Manager [8] 等服务进行安全管理，并在运行时注入到智能体环境中，而不是硬编码在代码库中。

安全发布策略 (Safe Rollout Strategies)

虽然全面的预生产检查至关重要，但现实世界的应用不可避免地会暴露出不可预见的问题。与其一次性将 100% 的用户切换过去，不如考虑通过带有仔细监控的渐进式发布来最小化风险。

以下是四种经过验证的模式，帮助团队建立对其部署的信心：

金丝雀发布 (Canary)：
从 1% 的用户开始，监控提示注入和意外的工具使用情况。逐渐扩大规模或立即回滚。
蓝绿部署 (Blue-Green)：
运行两个相同的生产环境。将流量路由到“蓝色”环境，同时部署到“绿色”环境，然后瞬间切换。如果出现问题，切回原环境——零停机时间，瞬间恢复。
A/B 测试：
在真实的业务指标上比较智能体版本，以便进行数据驱动的决策。这可以在内部或外部用户中进行。
功能开关 (Feature Flags)：
部署代码但动态控制发布，首先与选定的用户测试新功能。

所有这些策略都有一个共同的基础：严格的版本控制。每个组件——代码、提示词、模型端点、工具架构、内存结构，甚至评估数据集——都必须进行版本控制。当尽管有保障措施仍出现问题时，这使得可以立即回滚到已知的良好状态。把这看作是你的生产“撤消”按钮！

你可以使用 Agent Engine [9] 或 Cloud Run [10] 部署智能体，然后利用 Cloud Load Balancing [11] 进行跨版本的流量管理或连接到其他微服务。Agent Starter Pack [1] 提供了带有 GitOps 工作流的现成模板——其中每个部署都是一次 git commit，每个回滚都是一次 git revert，你的代码库成为当前状态和完整部署历史的单一事实来源。

从一开始就构建安全性

安全的部署策略保护你免受错误和中断的影响，但智能体面临着独特的挑战：它们可以自主推理和行动。如果一个部署完美的智能体没有建立适当的安全和责任措施，它仍然可能造成伤害。这需要从第一天起就嵌入全面的治理策略，而不是作为事后想法添加。

与遵循预定路径的传统软件不同，智能体做决策。它们解释模棱两可的请求，访问多个工具，并在会话之间保持记忆。这种自主性产生了独特的风险：

提示注入与恶意行为：
恶意用户可以诱骗智能体执行非预期的操作或绕过限制。
数据泄露：
智能体可能通过其响应或工具使用无意中暴露敏感信息。
记忆投毒：
存储在智能体记忆中的虚假信息可能会破坏所有未来的交互。

幸运的是，像 Google 的“安全 AI 智能体方法”[12] 和“Google 安全 AI 框架 (SAIF)”[13] 等框架通过三层防御来应对这些挑战：

策略定义和系统指令（智能体的宪法）：
过程始于为期望的和不期望的智能体行为定义策略。这些被工程化为充当智能体核心宪法的系统指令 (System Instructions, SIs)。
护栏、保障措施和过滤（执行层）：
这一层充当强制停止的执行机制。

输入过滤：
使用分类器和 Perspective API 等服务来分析提示词，并在恶意输入到达智能体之前将其阻止。
输出过滤：
在智能体生成响应后，Vertex AI 的内置安全过滤器提供对有害内容、PII 或策略违规的最终检查。例如，在响应发送给用户之前，它会通过 Vertex AI 的内置安全过滤器 [14]，该过滤器可以配置为阻止包含特定 PII、有毒语言或其他有害内容的输出。
人类介入 (HITL) 升级：
对于高风险或模棱两可的操作，系统必须暂停并升级给人类进行审查和批准。

持续保障和测试：
安全不是一次性的设置。它需要不断的评估和适应。

严格评估：
对模型或其安全系统的任何更改都必须触发使用 Vertex AI Evaluation 进行的全面评估流水线的重新运行。
专门的 RAI (Responsible AI) 测试：
通过创建专门的数据集或使用模拟智能体（包括中立观点 NPOV 评估和公平性评估）来严格测试特定风险。
主动红队测试：
通过创造性的人工测试和 AI 驱动的基于角色的模拟，主动尝试破坏安全系统。

生产中的运维

你的智能体已经上线了。现在重点从开发转移到了一个根本不同的挑战：在它与成千上万的用户互动时，保持系统的可靠、经济高效和安全。传统服务基于可预测的逻辑运行。相比之下，智能体是一个自主的行动者。它遵循意外推理路径的能力意味着它可能会表现出涌现行为并在没有直接监督的情况下累积成本。

管理这种自主性需要一种不同的运维模式。高效的团队不采用静态监控，而是采用一个持续的循环：观察 (Observe) 系统的实时行为，行动 (Act) 以维持性能和安全性，并根据生产学习 进化 (Evolve) 智能体。这个集成循环是在生产环境中成功运维智能体的核心规程。

观察：智能体的感知系统

为了信任和管理自主智能体，你必须首先了解它的过程。可观测性提供了这一关键洞察，充当后续“行动”和“进化”阶段的感知系统。一个强大的可观测性实践建立在三个支柱之上，它们共同提供智能体行为的完整图景：

日志 (Logs)：
发生的事件的细粒度、事实性日记，记录每一次工具调用、错误和决策。
追踪 (Traces)：
连接单个日志的叙述，揭示智能体为何采取特定行动的因果路径。
指标 (Metrics)：
聚合的成绩单，总结大规模下的性能、成本和运行状况，以显示系统的表现如何。

例如，在 Google Cloud 中，这是通过运维套件实现的：用户的请求在 Cloud Trace [15] 中生成一个唯一的 ID，该 ID 连接 Vertex AI Agent Engine 调用、模型调用和具有可见持续时间的工具执行。详细日志流入 Cloud Logging [16]，而 Cloud Monitoring [17] 仪表板在延迟超过阈值时发出警报。Agent Development Kit (ADK) [18] 提供了内置的 Cloud Trace 集成，用于智能体操作的自动插桩。

行动：运维控制的杠杆

没有行动的观察只是昂贵的仪表板。“行动”阶段是关于实时干预——你根据观察到的情况拉动杠杆来管理智能体的性能、成本和安全性。

将“行动”视为系统旨在实时维持稳定性的自动反射。相比之下，稍后将介绍的“进化”是从行为中学习以创建根本上更好的系统的战略过程。由于智能体是自主的，你无法预先编程每一个可能的结果。相反，你必须建立强大的机制来影响其在生产中的行为。这些运维杠杆主要分为两类：管理系统健康和管理风险。

管理系统健康：性能、成本和规模

与传统微服务不同，智能体的工作负载是动态且有状态的。管理其健康状况需要一种处理这种不可预测性的策略。

为规模设计：
基础是将智能体的逻辑与其状态解耦。

水平扩展：
将智能体设计为无状态的容器化服务。有了外部状态，任何实例都可以处理任何请求，从而使 Cloud Run [10] 或托管的 Vertex AI Agent Engine Runtime 等无服务器平台能够自动扩展。
异步处理：
对于长时间运行的任务，使用事件驱动模式卸载工作。这使得智能体保持响应，而复杂的工作在后台处理。例如在 Google Cloud 上，服务可以将任务发布到 Pub/Sub [19]，然后触发 Cloud Run 服务进行异步处理。
外部化状态管理：
由于 LLM 是无状态的，在外部持久化记忆是不可协商的。这突出强调了一个关键的架构选择：Vertex AI Agent Engine 提供了一个内置的、持久的会话和记忆服务，而 Cloud Run 提供了直接与 AlloyDB [20] 或 Cloud SQL [21] 等数据库集成的灵活性。

平衡相互竞争的目标：
扩展总是涉及平衡三个相互竞争的目标：速度、可靠性和成本。

速度（延迟）：
通过设计并行工作、积极缓存结果以及对常规任务使用更小、更高效的模型来保持智能体快速。
可靠性（处理故障）：
智能体必须处理临时故障。当调用失败时，自动重试，最好使用指数退避以给服务恢复时间。这需要设计“可安全重试”（幂等）的工具，以防止重复收费等错误。
成本：
通过缩短提示词、对更简单的任务使用更便宜的模型以及分组发送请求（批处理）来保持智能体负担得起。

管理风险：安全响应手册

因为智能体可以自行行动，你需要一本用于快速遏制的手册。当检测到威胁时，响应应遵循清晰的顺序：遏制、分流和解决。

遏制：
立即停止伤害，通常使用“断路器”——一个功能开关来立即禁用受影响的工具。
分流：
威胁得到遏制后，可疑请求被路由到人类介入 (HITL) 审查队列，以调查利用的范围和影响。
解决：
团队开发补丁——如更新的输入过滤器或系统提示词——并通过自动化 CI/CD 流水线部署它，确保在永久阻止利用之前修复已经过全面测试。

进化：从生产中学习

虽然“行动”阶段提供了系统的即时战术反射，但“进化”阶段是关于长期的战略改进。它始于查看可观测性数据中收集的模式和趋势，并提出一个关键问题：“我们如何修复根本原因，以便这个问题不再发生？”

这是你从对生产事故做出反应转向主动让你的智能体更聪明、更高效、更安全的地方。你将来自“观察”阶段的原始数据转化为智能体架构、逻辑和行为的持久改进。

进化的引擎：通往生产的自动化路径

只有当你能迅速采取行动时，来自生产的洞察才有价值。如果你的团队需要六个月才能部署修复程序，那么观察到 30% 的用户在特定任务上失败是无用的。

这就是你在预生产阶段（第 3 节）建立的自动化 CI/CD 流水线成为你运维循环中最关键组件的地方。它是为快速进化提供动力的引擎。快速、可靠的通往生产的路径允许你在数小时或数天内，而不是数周或数月内，闭环观察和改进。

当你发现一个潜在的改进——无论是完善的提示词、新工具还是更新的安全护栏——流程应该是：

提交更改：
提议的改进被提交到你的版本控制代码库。
触发自动化：
提交自动触发你的 CI/CD 流水线。
严格验证：
流水线运行全套单元测试、安全扫描以及针对更新后数据集的智能体质量评估套件。
安全部署：
一旦验证通过，更改将使用安全发布策略部署到生产环境。

进化工作流：从洞察到部署改进

分析生产数据：
从生产日志中识别用户行为、任务成功率和安全事件的趋势。
更新评估数据集：
将生产失败转化为明天的测试用例，扩充你的黄金数据集。
完善与部署：
提交改进以触发自动化流水线——无论是完善提示词、添加工具还是更新护栏。

这创造了一个良性循环，你的智能体随着每一次用户交互而不断改进。

行动中的进化循环示例
一个零售智能体的日志（观察）显示，15% 的用户在询问“类似产品”时收到错误。产品团队行动 (Act) 创建了一个高优先级工单。进化 (Evolve) 阶段开始：生产日志被用来为评估数据集创建一个新的、失败的测试用例。一位 AI 工程师完善了智能体的提示词，并添加了一个新的、更强大的相似性搜索工具。更改已提交，通过了 CI/CD 流水线中现已更新的评估套件，并通过金丝雀部署安全发布，在 48 小时内解决了用户问题。

进化安全性：生产反馈循环

虽然基础的安全和责任框架是在预生产阶段（第 3.4 节）建立的，但工作从未真正完成。安全不是一个静态的清单；它是一个动态的、持续的适应过程。生产环境是终极试验场，那里收集的洞察对于加固你的智能体以抵御现实世界的威胁至关重要。

这是观察 -> 行动 -> 进化循环对安全性变得至关重要的地方。该过程是进化工作流的直接延伸：

观察：
你的监控和日志系统检测到一个新的威胁向量。这可能是一种绕过你当前过滤器的新型提示注入技术，或者是导致轻微数据泄露的意外交互。
行动：
立即响应的安全团队遏制威胁（如第 4.2 节所述）。
进化：
这是长期恢复力的关键步骤。安全洞察被反馈到你的开发生命周期中：

更新评估数据集：
新的提示注入攻击被作为永久测试用例添加到你的评估套件中。
完善护栏：
提示词工程师或 AI 工程师完善智能体的系统提示词、输入过滤器或工具使用策略以阻止新的攻击向量。
自动化与部署：
工程师提交更改，触发完整的 CI/CD 流水线。更新后的智能体针对新扩展的评估集进行严格验证并部署到生产环境，关闭漏洞。

超越单智能体运维

你已经掌握了在生产中运维单个智能体并且可以高速发布它们。但随着组织扩展到数十个专门的智能体——每个都由不同的团队使用不同的框架构建——一个新的挑战出现了：这些智能体无法协作。下一节探讨了标准化协议如何将这些隔离的智能体转变为一个可互操作的生态系统，通过智能体协作释放指数级价值。

A2A - 复用性和标准化

你在整个组织中构建了数十个专门的智能体。客户服务团队有他们的支持智能体。分析团队构建了一个预测系统。风险管理创建了欺诈检测。但问题来了：这些智能体无法相互交谈——无论是因为它们是在不同的框架、项目还是完全不同的云中创建的。

这种隔离造成了巨大的低效。每个团队都在重建相同的能力。关键洞察被困在孤岛中。你需要的是互操作性——任何智能体利用任何其他智能体能力的能力，无论谁构建了它或使用了什么框架。

为了解决这个问题，需要建立在两个不同但互补的协议之上的原则性标准化方法。虽然我们在《使用 MCP 的智能体工具和互操作性》中详细介绍的 **模型上下文协议 (MCP [22])** 提供了工具集成的通用标准，但它不足以支持智能代理之间所需的复杂、有状态的协作。这就是 **Agent2Agent (A2A [23])** 协议旨在解决的问题，该协议现在由 Linux 基金会管理。

这种区别至关重要。当你需要一个简单的、无状态的函数，如获取天气数据或查询数据库时，你需要一个说 MCP 的工具。但是，当你需要委托一个复杂的目标时，例如“分析上个季度的客户流失并推荐三种干预策略”，你需要一个能够通过 A2A 自主推理、规划和行动的智能伙伴。简而言之，MCP 让你说，“做这件具体的事”，而 A2A 让你说，“实现这个复杂的目标”。

A2A 协议：从概念到实现

A2A 协议旨在打破组织孤岛，实现智能体之间的无缝协作。考虑这样一个场景：欺诈检测智能体发现可疑活动。为了了解完整的背景，它需要来自单独的交易分析智能体的数据。没有 A2A，人类分析师必须手动弥合这一差距——这个过程可能需要数小时。有了 A2A，智能体自动协作，在几分钟内解决问题。

协作的第一步是发现要委托给的正确智能体——这是通过 **Agent Cards (智能体名片)** [24] 实现的，这是一种充当每个智能体名片的标准化 JSON 规范。Agent Card 描述了智能体能做什么、它的安全要求、它的技能以及如何联系它 (URL)，允许生态系统中的任何其他智能体动态发现其同伴。

Python{"name": "check_prime_agent","version": "1.0.0","description": "An agent specialized in checking whether numbers are prime","capabilities": {},"securitySchemes": {"agent_oauth_2_0": {"type": "oauth2", }"defaultInputModes": ["text/plain"],"defaultOutputModes": ["application/json"],"skills": [ {"id": "prime_checking","name": "Prime Number Checking","description": "Check if numbers are prime using efficient algorithms","tags": ["mathematical", "computation", "prime"] } ],"url": "http://localhost:8001/a2a/check_prime_agent"}

代码片段 1：check_prime_agent 的示例 Agent Card

采用此协议不需要架构大修。像 ADK 这样的框架显着简化了此过程（文档 [25]）。你可以通过单个函数调用使现有的智能体兼容 A2A，该函数会自动生成其 AgentCard 并使其在网络上可用。

Python# Example using ADK: Exposing an agent via A2Afrom google.adk.a2a.utils.agent_to_a2a import to_a2a# Your existing agentroot_agent = Agent( name='hello_world_agent',# ... your agent code ...)# Make it A2A-compatiblea2a_app = to_a2a(root_agent, port=8001)# Serve with uvicorn# uvicorn agent:a2a_app --host localhost --port 8001# Or serve with Agent Engine# from vertexai.preview.reasoning_engines import A2aAgent# from google.adk.a2a.executor.a2a_agent_executor import A2aAgentExecutor# a2a_agent = A2aAgent(# agent_executor_builder=lambda: A2aAgentExecutor(agent=root_agent)# )

代码片段 2：使用 ADK 的 to_a2a 实用程序包装现有智能体并将其公开用于 A2A 通信

一旦智能体被公开，任何其他智能体都可以通过引用其 AgentCard 来消费它。例如，客户服务智能体现在可以查询远程产品目录智能体，而无需了解其内部工作原理。

Python# Example using ADK: Consuming a remote agent via A2Afrom google.adk.agents.remote_a2a_agent import RemoteA2aAgentprime_agent = RemoteA2aAgent( name="prime_agent", description="Agent that handles checking if numbers are prime.", agent_card="http://localhost:8001/a2a/check_prime_agent/ .well-known/agent-card.json")

代码片段 3：使用 ADK 的 RemoteA2aAgent 类连接并消费远程智能体

这解锁了强大的分层组合。根智能体可以配置为编排用于简单任务的本地子智能体和通过 A2A 的远程专用智能体，从而创建一个功能更强大的系统。

Python# Example using ADK: Hierarchical agent composition# ADK Local sub-agent for dice rollingroll_agent = Agent( name="roll_agent", instruction="You are an expert at rolling dice.")# ADK Remote A2A agent for prime checkingprime_agent = RemoteA2aAgent( name="prime_agent", agent_card="http://localhost:8001/.well-known/agent-card.json")# ADK Root orchestrator combining bothroot_agent = Agent( name="root_agent", instruction="""Delegate rolling dice to roll_agent, prime checking to prime_agent.""", sub_agents=[roll_agent, prime_agent])

代码片段 4：在 ADK 的分层智能体结构中使用远程 A2A 智能体作为子智能体

然而，实现这种级别的自主协作引入了两个不可协商的技术要求。首先是分布式追踪，每个请求都携带唯一的追踪 ID，这对于调试和维护跨多个智能体的连贯审计跟踪至关重要。其次是稳健的状态管理。A2A 交互本质上是有状态的，需要复杂的持久层来跟踪进度并确保事务完整性。

A2A 和 MCP 如何协同工作

[图表 4：A2A 和 MCP 协作示意图]

图 4：A2A（智能体间协作）与 MCP（智能体使用工具）的层级关系

A2A 和 MCP 不是相互竞争的标准；它们是设计用于在不同抽象级别上运行的互补协议。区别在于智能体正在与什么交互。MCP 是工具和资源（具有定义良好的结构化输入和输出的原语，如计算器或数据库 API）的领域。A2A 是其他智能体（可以推理、规划、使用多个工具并保持状态以实现复杂目标的自主系统）的领域。

最强大的代理系统在分层架构中同时使用这两种协议。应用程序可能主要使用 A2A 来编排多个智能智能体之间的高级协作，而每个智能体内部使用 MCP 来与其自己的一套特定工具和资源进行交互。

一个实际的类比是由自主 AI 智能体组成的汽车修理店：

用户对智能体 (A2A)：
客户使用 A2A 与“车间经理”智能体沟通，描述一个高级问题：“我的车发出咔哒声。”
智能体对智能体 (A2A)：
车间经理进行多轮诊断对话，然后再次使用 A2A 将任务委托给专门的“机械师”智能体。
智能体对工具 (MCP)：
机械师智能体现在需要执行特定操作。它使用 MCP 调用其专用工具：它在诊断扫描仪上运行 scan_vehicle_for_error_codes()，使用 get_repair_procedure() 查询维修手册数据库，并使用 raise_platform() 操作升降平台。
智能体对智能体 (A2A)：
在诊断问题后，机械师智能体确定需要一个零件。它使用 A2A 与外部“零件供应商”智能体沟通，查询可用性并下订单。

在这个工作流中，A2A 促进了客户、车间智能体和外部供应商之间的高级、对话式和面向任务的交互。同时，MCP 提供了标准化的管道，使机械师智能体能够可靠地使用其特定的结构化工具来完成工作。

注册表架构：何时以及如何构建

为什么有些组织建立注册表而其他组织不需要？答案在于规模和复杂性。当你只有五十个工具时，手动配置很好。但是，当你达到分布在不同团队和环境中的五千个工具时，你将面临需要系统解决方案的发现问题。

工具注册表 (Tool Registry) 使用像 MCP 这样的协议来编目所有资产，从函数到 API。你不必让智能体访问数千个工具，而是创建策划列表，从而导致三种常见模式：

通才智能体：
访问完整的目录，用速度和准确性换取范围。
专家智能体：
使用预定义的子集以获得更高的性能。
动态智能体：
在运行时查询注册表以适应新工具。

主要好处是人类发现——开发人员可以在构建重复工具之前搜索现有工具，安全团队可以审核工具访问权限，产品负责人可以了解其智能体的能力。

智能体注册表 (Agent Registry) 将相同的概念应用于智能体，使用像 A2A 的 AgentCards 这样的格式。它帮助团队发现和重用现有的智能体，减少重复工作。这也为自动化的智能体对智能体委托奠定了基础，尽管这仍然是一个新兴的模式。

注册表以维护成本为代价提供发现和治理。你可以考虑在没有它的情况下开始，只有在生态系统的规模需要集中管理时才构建它！

注册表的决策框架
工具注册表：
当工具发现成为瓶颈或安全性需要集中审计时构建。
智能体注册表： 当多个团队需要在没有紧密耦合的情况下发现和重用专门的智能体时构建。

融会贯通：AgentOps 生命周期

我们现在可以将这些支柱组装成一个单一的、有凝聚力的参考架构！生命周期始于开发者的内部循环——一个快速本地测试和原型的阶段，以塑造智能体的核心逻辑。一旦更改准备就绪，它就进入正式的预生产引擎，自动评估门控在那里根据黄金数据集验证其质量和安全性。从那里，安全发布将其发布到生产环境，全面的可观测性捕捉现实世界的数据，为持续进化循环提供燃料，将每一个洞察转化为下一次改进。

[图表 5：AgentOps 核心能力、环境和流程的全景图]

图 5：包含开发、预发布、生产环境及数据/治理层的完整架构

要全面了解 AI 智能体的生产化，包括评估、工具管理、CI/CD 标准化和有效架构设计，请观看 Google Cloud 官方 YouTube 频道上的视频《AgentOps: Operationalize AI Agents》[26]。

结论：用 AgentOps 跨越“最后一公里”

将 AI 原型转移到生产系统是一场组织变革，需要一种新的运维规程：AgentOps。

大多数智能体项目在“最后一公里”失败，不是因为技术，而是因为低估了自主系统的运维复杂性。本指南描绘了弥合这一差距的路径。它始于建立人员和流程作为治理的基础。接下来，建立在评估门控部署之上的预生产策略使高风险发布自动化。一旦上线，持续的 观察 -> 行动 -> 进化 循环将每一次用户交互转化为潜在的洞察。最后，互操作性协议通过将孤立的智能体转变为协作的智能生态系统来扩展系统。

立竿见影的好处——如防止安全漏洞或实现快速回滚——证明了投资的合理性。但真正的价值在于速度。成熟的 AgentOps 实践允许团队在数小时而不是数周内部署改进，将静态部署转变为不断进化的产品。

你前进的道路

如果你刚开始，请专注于基础：构建你的第一个评估数据集，实施 CI/CD 流水线，并建立全面的监控。Agent Starter Pack 是一个很好的起点——它可以在几分钟内创建一个生产就绪的智能体项目，并且已经内置了这些基础。
如果你正在扩展，请提升你的实践：自动化从生产洞察到部署改进的反馈循环，并在可互操作协议上进行标准化，以构建一个有凝聚力的生态系统，而不仅仅是点解决方案。

下一个前沿不仅仅是构建更好的单个智能体，而是编排能够学习和协作的复杂多智能体系统。AgentOps 的运维规程是实现这一点的基础。

我们希望这本手册能让你有能力构建下一代智能、可靠且值得信赖的 AI。因此，跨越最后一公里不是项目的最后一步，而是创造价值的第一步！

尾注 (参考文献)

1. Google Cloud Platform. (2025). Agent Starter Pack [代码仓库]. GitHub.
https://github.com/GoogleCloudPlatform/agent-starter-pack

2. Google Cloud. (2025). Vertex AI 评估简介 [文档]. Google Cloud.
https://cloud.google.com/vertex-ai/docs/evaluation/introduction

3. Google Cloud Platform. (2025). PR 检查配置 [源代码]. GitHub.
https://github.com/GoogleCloudPlatform/agent-starter-pack/blob/example-agent/example-agent/.cloudbuild/pr_checks.yaml

4. Google Cloud. (2025). Cloud Build [产品页面]. Google Cloud.
https://cloud.google.com/build

5. Google Cloud Platform. (2025). 预发布环境部署配置 [源代码]. GitHub.
https://github.com/GoogleCloudPlatform/agent-starter-pack/blob/example-agent/example-agent/.cloudbuild/staging.yaml

6. Google Cloud Platform. (2025). 生产环境部署配置 [源代码]. GitHub.
https://github.com/GoogleCloudPlatform/agent-starter-pack/blob/example-agent/example-agent/.cloudbuild/deploy-to-prod.yaml

7. Google Cloud Platform. (2025). Terraform 基础设施配置 [源代码]. GitHub.
https://github.com/GoogleCloudPlatform/agent-starter-pack/blob/example-agent/example-agent/terraform

8. Google Cloud. (2025). Secret Manager [产品页面]. Google Cloud.
https://cloud.google.com/secret-manager

9. Google Cloud. (2025). Agent Engine 概览 [文档]. Google Cloud.
https://cloud.google.com/agent-builder/agent-engine/overview

10. Google Cloud. (2025). Cloud Run [产品页面]. Google Cloud.
https://cloud.google.com/run

11. Google Cloud. (2025). 负载均衡流量管理 [文档]. Google Cloud.
https://cloud.google.com/load-balancing/docs/https/traffic-management

12. Google. (2025). Google 安全 AI 智能体方法简介 [白皮书]. Google Research.
https://research.google/pubs/an-introduction-to-googles-approach-for-secure-ai-agents/

13. Google. (2025). 安全 AI 框架 (SAIF) [页面]. Google Safety.
https://safety.google/cybersecurity-advancements/saif/

14. Google Cloud. (2025). 配置安全属性 [文档]. Google Cloud Vertex AI.
https://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/configure-safety-attributes

15. Google Cloud. (2025). Cloud Trace [产品页面]. Google Cloud.
https://cloud.google.com/trace

16. Google Cloud. (2025). Cloud Logging [产品页面]. Google Cloud.
https://cloud.google.com/logging

17. Google Cloud. (2025). Cloud Monitoring [产品页面]. Google Cloud.
https://cloud.google.com/monitoring

18. Google. (2025). Cloud Trace 可观测性 [文档]. Agent Development Kit (ADK).
https://google.github.io/adk-docs/observability/cloud-trace/

19. Google Cloud. (2025). Pub/Sub [产品页面]. Google Cloud.
https://cloud.google.com/pubsub

20. Google Cloud. (2025). AlloyDB [产品页面]. Google Cloud.
https://cloud.google.com/alloydb

21. Google Cloud. (2025). Cloud SQL [产品页面]. Google Cloud.
https://cloud.google.com/sql

22. Model Context Protocol. (2025). 模型上下文协议 [官方网站].
https://modelcontextprotocol.io/

23. A2A Protocol. (2025). A2A 协议规范 [文档].
https://a2a-protocol.org/latest/specification/

24. A2A Protocol. (2025). 智能体发现：Agent Card [文档].
https://a2a-protocol.org/latest/specification/#5-agent-discovery-the-agent-card

25. Google. (2025). ADK A2A 文档 [文档]. Agent Development Kit.
https://google.github.io/adk-docs/a2a/

26. Google Cloud. (2025). AgentOps: 运维 AI 智能体 [视频]. YouTube.
https://www.youtube.com/watch?v=kJRgj58ujEk