大数跨境
首页
>
从原型到生产
>
0
0

从原型到生产

从原型到生产 Super Intelligence
2025-11-16
10

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


致谢

  • 内容贡献者

    • Derek Egan
    • Chase Lyall
    • Anant Nawalgaria
    • Lavi Nigam
    • Kanchana Patlolla
    • Michael Vakoc

  • 策展人与编辑

    • Anant Nawalgaria
    • Kanchana Patlolla

  • 设计师

    • Michael Lanning

2025年11月

目录

章节
页码
摘要
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

构建一个代理很简单。信任它却很难。

摘要

  • 本白皮书提供了关于 AI 代理运营生命周期的综合技术指南，重点关注部署、扩展和生产化。
  • 它基于“Day 4”中对评估和可观测性的介绍，强调如何通过强大的 CI/CD 流水线和可扩展的基础设施来建立必要的信任，从而将代理投入生产。
  • 它探讨了将基于代理的系统从原型过渡到企业级解决方案所面临的挑战，并特别关注 Agent2Agent (A2A) 互操作性。
  • 本指南为 AI/ML 工程师、DevOps 专业人员和系统架构师提供了实用的见解。

导言：从原型到生产

您可以在几分钟内，甚至几秒钟内快速启动一个 AI 代理原型。但是，将这个巧妙的演示转化为您的业务可以依赖的、值得信赖的、生产级系统呢？

这就是真正工作开始的地方。欢迎来到“最后一英里”生产差距，我们通过与客户的实践观察到，大约 80% 的精力并未花在代理的核心智能上，而是花在了使其可靠和安全所需的基础设施、安全性和验证工作上。

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

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

这些不仅仅是技术问题；它们是重大的业务故障。

虽然 DevOps 和 MLOps 的原则提供了关键基础，但它们本身还不够。部署代理系统引入了一类新的挑战，需要我们对运维纪律进行演进。与传统的 ML 模型不同，代理是自主交互、有状态的，并遵循动态执行路径。

这带来了独特的运维难题，需要专门的策略：

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

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

本白皮书是您构建该基础并驾驭生产路径的分步手册！我们将从生产前的必需品开始，向您展示如何设置自动化的 CI/CD 流水线，并使用严格的评估作为关键的质量检查。接下来，我们将深入探讨在实际环境中运行代理的挑战，涵盖扩展、性能调优和实时监控的策略。最后，我们将展望令人兴奋的多代理系统世界，介绍 Agent-to-Agent 协议，并探讨如何让它们安全有效地进行通信。

实用实施指南

  • 在本白皮书中，实际示例引用了 Google Cloud Platform Agent Starter Pack¹——一个 Python 软件包，为 Google Cloud 提供了生产就绪的生成式 AI 代理模板。
  • 它包括预构建的代理、自动化的 CI/CD 设置、Terraform 部署、Vertex AI 评估集成以及内置的 Google Cloud 可观测性。
  • 该入门包通过您可以在几分钟内部署的工作代码演示了此处讨论的概念。

人员与流程

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

那个客户服务代理不会被魔法般地阻止送出免费产品；是 AI 工程师和提示工程师设计和实施了防护栏。机密的数据库不是由抽象概念保护的；是 Cloud Platform 团队配置了身份验证。

在每一个成功的、生产级代理的背后，都有一个精心组织的专业团队，在本节中，我们将介绍关键角色。

MLOps 机器学习与运维 人员、流程和技术 的结合，以高效地 将 ML 解决方案投入 生产。 人员 技术 流程 图 1：一个图表显示“运维”（Ops）是人员、流程和技术的交集

Figure 1: A diagram showing that "Ops" is the intersection of people, processes, and technology

在传统的 MLOps 环境中，这涉及几个关键团队：

  • 云平台团队： 由云架构师、管理员和安全专家组成，该团队管理基础云基础设施、安全性和访问控制。该团队授予工程师和服务账户最小权限角色，确保仅能访问必要的资源。

  • 数据工程团队： 数据工程师和数据所有者构建和维护数据流水线，处理摄取、准备和质量标准。

  • 数据科学和 MLOps 团队： 这包括试验和训练模型的数据科学家，以及使用 CI/CD 在规模上自动化端到端 ML 流水线（例如，预处理、训练、后处理）的 ML 工程师。MLOps 工程师通过构建和维护标准化流水线基础设施来提供支持。

  • 机器学习治理： 这个集中的职能，包括产品所有者和审计师，监督 ML 生命周期，作为工件和指标的存储库，以确保合规性、透明度和问责制。

生成式 AI 为这一领域引入了新的复杂性和专业化角色：

  • 提示工程师：
     
    虽然这个角色名称在行业中仍在演变，但这些人员将制作提示的技术技能与深厚的领域专业知识相结合。他们定义了从模型中预期的正确问题和答案，尽管在实践中，这项工作可能由 AI 工程师、领域专家或专用专家完成，具体取决于组织的成熟度。
  • AI 工程师：
     
    他们负责将 GenAI 解决方案扩展到生产，构建强大的后端系统，其中包含大规模评估、防护栏和 RAG/工具集成。
  • DevOps/应用开发者：
     
    这些开发者构建前端组件和用户友好界面，以与 GenAI 后端集成。

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

图 2：多个团队如何协作将模型和 GenAI 应用程序投入运营

迈向生产的旅程

既然我们已经确定了团队，我们转向流程。我们如何将所有这些专家的工作转化为一个值得信赖、可靠并为用户准备就绪的系统？

答案在于一个建立在单一核心原则上的严格的生产前流程：评估门控部署 (Evaluation-Gated Deployment)。这个想法简单而强大：没有通过全面评估证明其质量和安全的代理版本不应接触用户。这个生产前阶段是我们用自动化信心换取手动不确定性的阶段，它由三大支柱组成：一个作为质量关口的严格评估流程、一个强制执行它的自动化 CI/CD 流水线，以及用于降低最终进入生产步骤风险的安全部署策略。

评估作为质量关口

为什么我们需要为代理设置一个特殊的质量关口？ 传统的软件测试对于能够推理和适应的系统来说是不足够的。此外，评估一个代理与评估一个 LLM 是不同的；它不仅需要评估最终答案，还需要评估完成任务所采取的整个推理和行动轨迹。一个代理可以为其工具通过 100 个单元测试，但仍可能因为选择了错误的工具或幻觉了一个响应而遭受灾难性失败。我们需要评估其行为质量，而不仅仅是功能正确性。

这个关口可以通过两种主要方式实现：

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

无论采用哪种方法，原则都是相同的：没有经过质量检查的代理不得进入生产环境。我们关于测量内容和如何构建此评估线束的具体细节已在我们的“Day 4: 代理质量：可观测性、日志记录、跟踪、评估、指标”中深入探讨，其中探索了从制作“黄金数据集”（一套精心策划的、具有代表性的测试用例，旨在评估代理的预期行为和防护栏合规性）到实施 LLM-as-a-judge 技术，再到最终使用像 Vertex AI 评估这样的服务来支持评估的一切。

自动化 CI/CD 流水线

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

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

一个强大的流水线被设计成一个漏斗。它尽早且尽可能便宜地捕获错误，这种做法通常被称为“左移”。它将快速的预合并检查与更全面、资源消耗大的后合并部署分离开来。这个渐进式工作流通常被构建为三个不同的阶段：

  1. 阶段 1：预合并集成 (CI)。
     
    流水线的首要责任是向开启拉取请求的 AI 工程师或提示工程师提供快速反馈。
    • 自动触发，这个 CI 阶段充当主分支的守门人。
    • 它运行快速检查，例如单元测试、代码 Linting 和依赖项扫描。至关重要的是，这是运行由提示工程师设计的代理质量评估套件的理想阶段。
    • 这提供了关于更改是否在关键场景中改善或降低代理性能的即时反馈，避免在合并之前引入问题。通过在此处捕获问题，我们防止污染主分支。
    • 使用 Agent Starter Pack (ASP) 生成的 PR 检查配置模板³ 是使用 Cloud Build⁴ 实现此阶段的实际示例。
  2. 阶段 2：预生产环境中的后合并验证 (CD)。
     
    一旦更改通过所有 CI 检查——包括性能评估——并被合并，焦点就从代码和性能的正确性转向集成系统的运维就绪性。
    • 持续部署 (CD) 流程，通常由 MLOps 团队管理，将代理打包并部署到预生产环境——一个生产环境的高保真副本。
    • 在这里，运行更全面、资源消耗大的测试，例如负载测试和针对远程服务的集成测试。
    • 这S也是内部用户测试（通常称为“狗食”）的关键阶段，公司内部的人员可以与代理互动，并在其到达最终用户之前提供定性反馈。
    • 这确保了作为集成系统的代理在被考虑发布之前，在类似于生产的条件下可靠且高效地运行。
    • ASP 中的预生产部署模板⁵ 展示了此部署的一个示例。
  3. 阶段 3：门控部署到生产环境。
     
    在代理已在预生产环境中得到彻底验证后，最后一步是部署到生产环境。
    • 这几乎从不完全自动化，通常需要产品所有者给出最终批准，确保人工参与。
    • 经批准后，在预生产环境中经过测试和验证的确切部署工件被推送到生产环境。
    • 使用 ASP 生成的生产部署模板⁶ 展示了此最后阶段如何检索已验证的工件并将其部署到生产环境，并带有适当的防护措施。

图 3：CI/CD 过程的不同阶段

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

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

此外，敏感信息（如工具的 API 密钥）应使用像 Secret Manager⁸ 这样的服务安全地管理，并在运行时注入到代理的环境中，而不是硬编码在代码库中。

安全的部署策略

虽然全面的生产前检查至关重要，但实际应用中难免会发现不可预见的问题。与其一次性切换 100% 的用户，不如考虑通过渐进式部署和仔细监控来最小化风险。

这里有四种经过验证的模式，可帮助团队建立对部署的信心：

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

所有这些策略都有一个共同的基础：严格的版本控制。每个组件——代码、提示、模型端点、工具模式、内存结构，甚至评估数据集——都必须进行版本控制。当尽管有防护措施仍出现问题时，这使得能够立即回滚到已知良好的状态。将此视为您的生产“撤销”按钮！

您可以使用 Agent Engine⁹ 或 Cloud Run¹⁰ 部署代理，然后利用 Cloud Load Balancing¹¹ 进行跨版本的流量管理或连接到其他微服务。Agent Starter Pack¹ 提供了带有 GitOps 工作流的即用型模板——其中每次部署都是一次 git 提交，每次回滚都是一次 git revert，您的代码库成为当前状态和完整部署历史的单一事实来源。

从一开始就构建安全性

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

与遵循预定路径的传统软件不同，代理会做出决策。它们解释模糊的请求、访问多个工具并跨会话维护内存。这种自主性产生了独特的风险：

  • 提示注入和恶意行动：
     
    恶意用户可以欺骗代理执行非预期行动或绕过限制。
  • 数据泄露：
     
    代理可能通过其响应或工具使用不经意地暴露敏感信息。
  • 内存污染：
     
    存储在代理内存中的虚假信息可能会破坏所有未来的交互。

幸运的是，像 Google 的 Secure AI Agents 方法¹² 和 Google Secure AI Framework (SAIF)¹³ 这样的框架通过三层防御来应对这些挑战：

  1. 策略定义和系统指令（代理的宪法）：
     
    流程始于定义所需和非所需代理行为的策略。这些被工程化为充当代理核心宪法的系统指令 (SIs)。
  2. 防护栏、保障措施和过滤（执行层）：
     
    这一层充当硬性停止执行机制。
    • 输入过滤：
       
      使用分类器和服务（如 Perspective API）来分析提示并阻止恶意输入，防止它们到达代理。
    • 输出过滤：
       
      在代理生成响应后，Vertex AI 的内置安全过滤器提供对有害内容、PII 或策略违规的最终检查。例如，在将响应发送给用户之前，它会通过 Vertex AI 的内置安全过滤器¹⁴，可以配置这些过滤器以阻止包含特定 PII、有毒语言或其他有害内容的输出。
    • 人工参与 (HITL) 升级：
       
      对于高风险或模糊不清的行动，系统必须暂停并升级给人工进行审查和批准。
  3. 持续保障和测试：
     
    安全性不是一次性设置。它需要持续的评估和适应。
    • 严格评估：
       
      对模型或其安全系统的任何更改都必须触发使用 Vertex AI 评估对全面评估流水线的完整重新运行。
    • 专用 RAI 测试：
       
      通过创建专用数据集或使用模拟代理来严格测试特定风险，包括中立观点 (NPOV) 评估和奇偶校验评估。
    • 主动红队测试 (Proactive Red Teaming)：
       
      通过创新的手动测试和 AI 驱动的基于角色的模拟，积极尝试破坏安全系统。

生产环境中的运维

您的代理已上线。现在的焦点从开发转向了一个根本不同的挑战：在系统与数千用户互动时，保持其可靠、经济高效和安全。

传统服务在可预测的逻辑上运行。相比之下，代理是自主行动者。其遵循意外推理路径的能力意味着它可以表现出涌现行为，并在没有直接监督的情况下累积成本。

管理这种自主性需要不同的运维模型。有效的团队采用持续循环，而不是静态监控：观察 (Observe) 系统的实时行为，行动 (Act) 以维护性能和安全性，并根据生产学习演进 (Evolve) 代理。这个集成循环是成功运维代理的核心纪律。

观察：您的代理的感官系统

要信任和管理一个自主代理，您必须首先理解其过程。可观测性提供了这一关键洞察，充当后续“行动”和“演进”阶段的感官系统。

强大的可观测性实践建立在三个支柱之上，它们协同工作以提供代理行为的完整图景：

  • 日志 (Logs)：
     
    记录所发生事件的粒度化、事实性日记，记录每一次工具调用、错误和决策。
  • 跟踪 (Traces)：
     
    连接各个日志的叙事，揭示代理采取特定行动的因果路径。
  • 指标 (Metrics)：
     聚合的报告卡
    ，总结性能、成本和操作健康状况，以显示系统在大规模下的运行情况。

例如，在 Google Cloud 中，这是通过运维套件实现的：用户的请求在 Cloud Trace¹⁵ 中生成一个唯一 ID，该 ID 将 Vertex AI Agent Engine 调用、模型调用和工具执行与可见的持续时间关联起来。详细日志流向 Cloud Logging¹⁶，而 Cloud Monitoring¹⁷ 控制台在延迟超出阈值时发出警报。Agent Development Kit (ADK)¹⁸ 提供了内置的 Cloud Trace 集成，用于代理操作的自动插装。

通过实施这些支柱，我们从在黑暗中操作转变为对代理行为拥有清晰、数据驱动的视图，为在生产中有效管理它提供了基础。（有关这些概念的完整讨论，请参阅《代理质量：可观测性、日志记录、跟踪、评估、指标》）。

行动：运维控制的杠杆

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

  • 将“行动”视为系统设计用于实时维护稳定性的自动化反射。
  • 相比之下，稍后将介绍的**“演进”** 是从行为中学习以创建从根本上更好的系统的战略过程。

因为代理是自主的，您无法预先编程所有可能的结果。相反，您必须构建强大的机制来影响其在生产中的行为。这些运维杠杆分为两个主要类别：管理系统健康和管理系统风险。

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

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

  • 设计可扩展性： 基础是将代理的逻辑与其状态解耦。

    • 横向扩展：
       
      将代理设计为无状态、容器化服务。有了外部状态，任何实例都可以处理任何请求，从而使像 Cloud Run¹⁰ 或托管的 Vertex AI Agent Engine Runtime 这样的无服务器平台能够自动扩展。
    • 异步处理：
       
      对于长时间运行的任务，使用事件驱动模式来分载工作。这使得代理保持响应，而复杂的作业在后台处理。例如，在 Google Cloud 上，服务可以向 Pub/Sub¹⁹ 发布任务，然后 Pub/Sub¹⁹ 可以触发 Cloud Run 服务进行异步处理。
    • 外部化状态管理：
       
      由于 LLM 是无状态的，将内存持久化到外部是不可避免的。这突出了一个关键的架构选择：Vertex AI Agent Engine 提供了内置的、持久的会话和内存服务，而 Cloud Run¹⁰ 则提供了直接与像 AlloyDB²⁰ 或 Cloud SQL²¹ 这样的数据库集成的灵活性。

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

    • 速度（延迟）：
       
      通过将其设计为并行工作、积极缓存结果，并对日常任务使用更小、更高效的模型，来保持您的代理快速。
    • 可靠性（处理故障）：
       
      代理必须处理临时故障。当调用失败时，自动重试，最好使用指数退避，给服务时间恢复。这需要设计“安全重试”（幂等）工具来防止像重复收费这样的错误。
    • 成本：
       
      通过缩短提示、对简单任务使用更便宜的模型，以及批量发送请求，来保持代理经济实惠。
管理风险：安全响应手册

因为代理可以自行行动，您需要一个用于快速遏制的手册。当检测到威胁时，响应应遵循清晰的序列：遏制、分流和解决。

  1. 第一步是立即遏制。
     
    优先事项是阻止伤害，通常使用“断路器”——一个功能标志，可以立即禁用受影响的工具。
  2. 接下来是分流。
     
    在威胁被遏制后，可疑请求被路由到人工参与 (HITL) 审查队列，以调查漏洞的范围和影响。
  3. 最后，焦点转向永久性解决。
     
    团队开发一个补丁——例如更新的输入过滤器或系统提示——并通过自动化的 CI/CD 流水线部署它，确保修复在永久阻止漏洞之前经过充分测试。

演进：从生产中学习

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

在这里，您从对生产事件的反应转变为主动使您的代理更智能、更高效、更安全。您将来自“观察”阶段的原始数据转化为代理架构、逻辑和行为的持久改进。

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

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

这就是您在生产前构建的自动化 CI/CD 流水线（第 3 节）成为您的运维循环中最关键的组件的地方。它是推动快速演进的引擎。快速、可靠的生产路径使您能够在几小时或几天内关闭观察和改进之间的循环，而不是几周或几个月。

当您确定一个潜在的改进——无论是完善的提示、新工具，还是更新的安全防护栏——流程应该是：

  1. 提交更改：
     
    拟议的改进被提交到您的版本控制存储库。
  2. 触发自动化：
     
    提交自动触发您的 CI/CD 流水线。
  3. 严格验证：
     
    流水线针对您更新的数据集运行全套单元测试、安全扫描和代理质量评估套件。
  4. 安全部署：
     
    一旦验证通过，更改将使用安全部署策略部署到生产环境。

这种自动化工作流将演进从一个缓慢、高风险的手动项目转变为一个快速、可重复、数据驱动的流程。

演进工作流：从洞察到已部署的改进

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

这创造了一个良性循环，您的代理在每一次用户互动中持续改进。

演进循环在行动中

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

演进安全性：生产反馈回路

虽然基础的安全和责任框架是在生产前建立的（第 3.4 节），但工作永远不会真正完成。安全性不是一个静态的清单；它是一个动态的、持续的适应过程。生产环境是最终的测试场，在那里收集的洞察对于加固您的代理以应对真实世界的威胁至关重要。

这就是 观察-行动-演进 (Observe-Act-Evolve) 循环对于安全变得至关重要的地方。该流程是演进工作流的直接延伸：

  1. 观察：
     
    您的监控和日志记录系统检测到一个新的威胁载体。这可能是一种绕过您当前过滤器的新颖提示注入技术，或导致轻微数据泄漏的意外交互。
  2. 行动：
     
    立即安全响应团队遏制威胁（如第 4.2 节所述）。
  3. 演进：
     
    这是长期弹性的关键步骤。安全洞察被反馈到您的开发生命周期中：
    • 更新评估数据集：
       
      新的提示注入攻击作为永久测试用例被添加到您的评估套件中。
    • 完善防护栏：
       
      提示工程师或 AI 工程师完善代理的系统提示、输入过滤器或工具使用策略，以阻止新的攻击载体。
    • 自动化和部署：
       
      工程师提交更改，这会触发完整的 CI/CD 流水线。更新后的代理经过针对新扩展的评估集的严格验证，并部署到生产环境，从而关闭漏洞。

这创造了一个强大的反馈回路，其中每一个生产事件都使您的代理更强大、更具弹性，将您的安全态势从防御立场转变为持续、主动的改进。

要了解更多关于负责任的 AI 和保护 AI 代理系统的知识，请参阅白皮书 Google's Approach for Secure AI Agents¹² 和 Google Secure AI Framework (SAIF)¹³。

超越单代理运维

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

A2A - 可重用性与标准化

您的组织已经构建了数十个专业代理。客户服务团队有他们的支持代理。分析部门构建了一个预测系统。风险管理部门创建了欺诈检测。但问题是：这些代理之间无法相互通信——无论是由于它们是在不同的框架、项目还是完全不同的云中创建的。

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

为了解决这个问题，需要一个建立在两个不同但互补的协议之上的标准化原则方法。

  • 虽然 Model Context Protocol (MCP²²)，我们在《代理工具和与 MCP 的互操作性》中详细介绍过，为工具集成提供了一个通用标准，但它不足以满足智能代理之间所需的复杂、有状态的协作。
  • 这就是 Agent2Agent (A2A²³) 协议被设计来解决的问题，该协议现由 Linux 基金会治理。

区别至关重要。当您需要一个简单的、无状态的功能（如获取天气数据或查询数据库）时，您需要一个说 MCP 语言的工具。但当您需要委托一个复杂的任务时，例如“分析上一季度的客户流失并推荐三种干预策略”，您需要一个可以通过 A2A 进行推理、规划和自主行动的智能伙伴。

简而言之，MCP 让您说“做这件具体的事情”，而 A2A 让您说“实现这个复杂的目标”。

A2A 协议：从概念到实施

A2A 协议旨在打破组织孤岛，实现代理之间的无缝协作。

考虑一个场景，一个欺诈检测代理发现可疑活动。为了理解完整的上下文，它需要来自另一个交易分析代理的数据。如果没有 A2A，人类分析师必须手动弥合这个差距——这个过程可能需要数小时。有了 A2A，代理可以自动协作，在几分钟内解决问题。

协作的第一步是发现正确的委托代理——这通过 Agent Cards²⁴ 实现。Agent Cards 是标准化 JSON 规范，充当每个代理的名片。Agent Card 描述了代理可以做什么、其安全要求、其技能以及如何联系它 (url)，允许生态系统中的任何其他代理动态发现其对等体。

请参阅下面的示例 Agent Card：

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 这样的框架显着简化了此过程 (docs²⁵)。您可以使用单个函数调用使现有代理兼容 A2A，该函数会自动生成其 AgentCard 并使其在网络上可用。

Python

# Example using ADK: Exposing an agent via A2A
from google.adk.a2a.utils.agent_to_a2a import to_a2a

# Your existing agent
root_agent = Agent(
    name='hello_world_agent',
#... your agent code ...
)

# Make it A2a-compatible
a2a_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 A2A
from google.adk.agents.remote_a2a_agent import RemoteA2aAgent

prime_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 rolling
roll_agent = Agent(
    name="roll_agent",
    instruction="You are an expert at rolling dice."
)

# ADK Remote A2A agent for prime checking
prime_agent = RemoteA2aAgent(
    name="prime_agent",
    agent_card="http://localhost:8001/.well-known/agent-card.json"
)

# ADK Root orchestrator combining both
root_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 代理 (prime_agent) 作为子代理

然而，启用这种级别的自主协作引入了两个不可协商的技术要求。

  1. 首先是分布式跟踪，其中每个请求都带有唯一的跟踪 ID，这对于跨多个代理的调试和维护连贯的审计跟踪至关重要。
  2. 其次是强大的状态管理。A2A 交互本质上是有状态的，需要一个复杂的持久层来跟踪进度并确保事务完整性。

A2A 最适合需要持久服务契约的正式、跨团队集成。对于单个应用程序内紧密耦合的任务，轻量级的本地子代理通常仍然是更高效的选择。随着生态系统的成熟，新代理应内置对这两种协议的原生支持，确保每个新组件都立即可发现、可互操作和可重用，从而复合整个系统的价值。

A2A 和 MCP 如何协同工作

图 4：A2A 和 MCP 协作的一览图

A2A 和 MCP 不是相互竞争的标准；它们是互补的协议，设计用于在不同的抽象级别操作。区别取决于代理正在与什么互动。

  • MCP 是工具和资源的领域
    ——具有明确定义的、结构化输入和输出的基元，如计算器或数据库 API。
  • A2A 是其他代理的领域
    ——可以推理、规划、使用多个工具并维护状态以实现复杂目标的自主系统。

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

一个实际的类比是一家由自主 AI 代理运营的汽车修理店。

  1. 用户到代理 (A2A)：
     
    客户使用 A2A 与**“商店经理”代理**通信，描述一个高级问题：“我的车有异响。”
  2. 代理到代理 (A2A)：
     
    商店经理进行多轮诊断对话，然后将任务委托给一个专业的**“机械师”代理**，再次使用 A2A。
  3. 代理到工具 (MCP)：
     
    机械师代理现在需要执行特定行动。它使用 MCP 来调用其专业工具：它在一个诊断扫描仪上运行 scan_vehicle_for_error_codes()，使用 get_repair_procedure() 查询维修手册数据库，并使用 raise_platform() 操作平台升降机。
  4. 代理到代理 (A2A)：
     
    在诊断出问题后，机械师代理确定需要一个零件。它使用 A2A 与外部的“零件供应商”代理通信，查询可用性并下订单。

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

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

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

工具注册表使用像 MCP 这样的协议来编目所有资产，从函数到 API。与其让代理访问数千个工具，不如创建精心策划的列表，从而产生三种常见模式：

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

主要好处是人类发现——开发者可以搜索现有工具，然后再构建重复的工具，安全团队可以审计工具访问，产品所有者可以了解其代理的能力。

代理注册表将相同的概念应用于代理，使用像 A2A 的 AgentCards 这样的格式。它帮助团队发现和重用现有代理，减少冗余工作。这也为自动化代理到代理的委托奠定了基础，尽管这仍然是一种新兴模式。

注册表以维护成本提供发现和治理。您可以考虑不使用注册表开始，并且仅当您的生态系统的规模需要集中管理时才构建它！

注册表决策框架
  • 工具注册表：
     
    当工具发现成为瓶颈或安全要求集中审计时构建。
  • 代理注册表：
     
    当多个团队需要发现和重用专业代理而无需紧密耦合时构建。

整合所有要素：AgentOps 生命周期

我们现在可以将这些支柱组装成一个单一、内聚的参考架构！

生命周期始于开发者的内循环——这是一个快速本地测试和原型设计的阶段，用于塑造代理的核心逻辑。一旦更改准备就绪，它就进入正式的生产前引擎，其中自动化评估关口根据黄金数据集验证其质量和安全性。从那里，安全部署将其发布到生产环境，其中全面的可观测性捕获燃料持续演进循环所需的真实世界数据，将每一个洞察转化为下一次改进。

如需全面了解 AI 代理的运营化，包括评估、工具管理、CI/CD 标准化和有效的架构设计，请观看 Google Cloud 官方 YouTube 频道上的 AgentOps: Operationalize AI Agents 视频²⁶。

图 5：AgentOps 核心能力、环境和流程

结论：AgentOps 弥合“最后一英里”差距

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

大多数代理项目在**“最后一英里”失败不是因为技术，而是因为自主系统的运维复杂性被低估了**。本指南描绘了弥合这一差距的路径。

  • 它始于将人员与流程确立为治理的基础。
  • 接下来，建立在评估门控部署之上的生产前策略自动化了高风险的发布。
  • 一旦上线，一个持续的 观察 → 行动 → 演进 循环将每一次用户互动转化为潜在的洞察。
  • 最后，互操作性协议通过将孤立的代理转化为协作的、智能的生态系统来扩展系统。

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

您的前进之路

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

下一个前沿不仅仅是构建更好的单个代理，而是编排学习和协作的复杂多代理系统。AgentOps 的运维纪律是使这成为可能的基础。

我们希望本手册能赋能您构建下一代智能、可靠和值得信赖的 AI。弥合最后一英里因此不是项目的最后一步，而是创造价值的第一步！

尾注

  1. https://github.com/GoogleCloudPlatform/agent-starter-pack
  2. https://cloud.google.com/vertex-ai/docs/evaluation/introduction
  3. https://github.com/GoogleCloudPlatform/agent-starter-pack/blob/example-agent/example-agent/.cloudbuild/pr-checks.yaml
  4. https://cloud.google.com/build
  5. https://github.com/GoogleCloudPlatform/agent-starter-pack/blob/example-agent/example-agent/.cloudbuild/staging.yaml
  6. https://github.com/GoogleCloudPlatform/agent-starter-pack/blob/example-agent/example-agent/.cloudbuild/deploy-to-prod.yaml
  7. https://github.com/GoogleCloudPlatform/agent-starter-pack/blob/example-agent/example-agent/terraform
  8. https://cloud.google.com/secret-manager
  9. https://cloud.google.com/agent-builder/agent-engine/overview
  10. https://cloud.google.com/run
  11. https://cloud.google.com/load-balancing/docs/https/traffic-management
  12. https://research.google/pubs/an-introduction-to-googles-approach-for-secure-ai-agents/
  13. https://safety.google/cybersecurity-advancements/saif/
  14. https://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/configure-safety-attributes
  15. https://cloud.google.com/trace
  16. https://cloud.google.com/logging
  17. https://cloud.google.com/monitoring
  18. https://google.github.io/adk-docs/observability/cloud-trace/
  19. https://cloud.google.com/pubsub
  20. https://cloud.google.com/alloydb
  21. https://cloud.google.com/sql
  22. https://modelcontextprotocol.io/
  23. https://a2a-protocol.org/latest/specification/
  24. https://a2a-protocol.org/latest/specification/#5-agent-discovery-the-agent-card
  25. https://google.github.io/adk-docs/a2a/
  26. https://www.youtube.com/watch?v=kJRgj58ujEk

【声明】内容源于网络
0
0
Super Intelligence
AI 企业落地与自动化实践 | 打造好用的 Agentic AI 工具 | 分享灵感、技术和脑洞 | 一起做点有趣又有用的东西
内容 42
粉丝 0
Super Intelligence AI 企业落地与自动化实践 | 打造好用的 Agentic AI 工具 | 分享灵感、技术和脑洞 | 一起做点有趣又有用的东西
总阅读85
粉丝0
内容42