【译】从原型到生产

原文：Prototype to Production, Google 作者：Sokratis Kartakis, Gabriela Hernandez Larios, Ran Li, Elia Secchi, Huang Xia 发布日期：2025 年 11 月

构建 Agent 容易，信任它难。

摘要

本白皮书为 AI Agent 的运营生命周期提供了全面的技术指南，重点涵盖部署、扩展和生产化。在第四天关于评估与可观测性内容的基础上，本指南着重阐述如何通过强健的 CI/CD 流水线和可扩展的基础设施，建立将 Agent 推向生产环境所需的信任基础。本文探讨了将基于 Agent 的系统从原型过渡到企业级解决方案所面临的挑战，并特别关注 Agent2Agent（A2A）互操作性。本指南为 AI/ML 工程师、DevOps 专业人员和系统架构师提供实用洞察。

引言：从原型到生产

你可以在几分钟甚至几秒钟内搭建出一个 AI Agent 原型。但要将这个精彩的演示转变为企业可以依赖的可信、生产级系统？那才是真正工作的开始。欢迎来到“最后一公里”生产差距——我们在客户实践中持续观察到，大约 80% 的工作量不是花在 Agent 的核心智能上，而是花在使其可靠、安全所需的基础设施和验证上。

跳过这些最后步骤可能导致以下几个问题：

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

这些不仅仅是技术问题，更是重大的业务失败。虽然 DevOps 和 MLOps 的原则提供了重要的基础，但仅靠这些还不够。部署 Agentic 系统引入了一类新的挑战，需要我们在运营纪律上进行演进。与传统 ML 模型不同，Agent 具有自主交互性、有状态性，并遵循动态执行路径。

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

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

要成功应对这些挑战，你需要建立在三个关键支柱上的基础：自动化评估、自动化部署（CI/CD） 和全面可观测性。

本白皮书是你构建该基础并导航生产路径的分步手册！我们将从预生产要素开始，展示如何设置自动化 CI/CD 流水线并将严格评估作为关键质量检查。然后，我们将深入探讨在真实环境中运行 Agent 的挑战，涵盖扩展、性能调优和实时监控策略。最后，我们将展望多 Agent 系统的激动人心的世界，探索 Agent 间协议（A2A）以及如何让它们安全高效地协作。

实践实施指南

本白皮书中的实践示例均参考 Google Cloud Platform Agent Starter Pack——一个为 Google Cloud 提供生产就绪的生成式 AI Agent 模板的 Python 包。它包含预构建的 Agent、自动化 CI/CD 设置、Terraform 部署、Vertex AI 评估集成和内置 Google Cloud 可观测性。这个 Starter Pack 用可立即部署的工作代码演示了本文讨论的概念。

人员与流程

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

那个客服 Agent 不会魔法般地被阻止赠送免费产品；是 AI 工程师和提示工程师设计并实现了护栏。机密数据库不会被抽象概念所保护；是云平台团队配置了身份验证。每个成功的生产级 Agent 背后都有一个精心协调的专家团队，在本节中，我们将介绍关键角色。

在传统的 MLOps 体系中，涉及以下几个关键团队：

• 云平台团队：由云架构师、管理员和安全专家组成，负责管理基础云基础设施、安全和访问控制。该团队为工程师和服务账户授予最小权限角色，确保只访问必要的资源。
• 数据工程团队：数据工程师和数据负责人构建并维护数据流水线，处理数据摄取、准备和质量标准。
• 数据科学与 MLOps 团队：包括实验和训练模型的数据科学家，以及使用 CI/CD 在规模上自动化端到端 ML 流水线（例如预处理、训练、后处理）的 ML 工程师。MLOps 工程师通过构建和维护标准化流水线基础设施来支持这一工作。
• 机器学习治理：这个集中化功能，包括产品负责人和审计员，监督 ML 生命周期，作为制品和指标的存储库，确保合规性、透明度和问责制。

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

• 提示工程师：虽然这个角色头衔在行业中仍在演变，但这些人将技术性的提示设计技能与深厚的领域专业知识相结合。他们定义向模型提出正确问题并期望得到的正确答案，尽管在实践中，根据组织的成熟度，这项工作可能由 AI 工程师、领域专家或专职专业人员来完成。
• AI 工程师：负责将生成式 AI 解决方案扩展到生产环境，构建包含大规模评估、护栏和 RAG/工具集成的强健后端系统。
• DevOps/应用开发者：这些开发者构建与生成式 AI 后端集成的前端组件和用户友好界面。

组织的规模和结构会影响这些角色；在较小的公司中，个人可能身兼多职，而成熟的组织将拥有更专业化的团队。有效协调所有这些多样化角色对于建立强健的运营基础、成功地将传统 ML 和生成式 AI 项目推向生产至关重要。

走向生产的旅程

现在我们已经建立了团队，转向流程。我们如何将所有这些专家的工作转化为可信、可靠且为用户准备好的系统？

答案在于建立在单一核心原则之上的严格预生产流程：评估门控部署。这个理念简单但强大：没有任何 Agent 版本应该在未经过证明其质量和安全性的全面评估之前到达用户。这个预生产阶段是我们用自动化信心替代手动不确定性的地方，它由三个支柱组成：作为质量门的严格评估流程、强制执行它的自动化 CI/CD 流水线，以及降低最终进入生产风险的安全发布策略。

评估作为质量门

为什么 Agent 需要特殊的质量门？传统软件测试对于能够推理和适应的系统是不够的。此外，评估一个 Agent 与评估一个 LLM 是不同的；它要求评估的不仅仅是最终答案，而是完成任务所采取的整个推理和行动轨迹。一个 Agent 可以通过其工具的 100 个单元测试，但仍然可能因为选择了错误的工具或产生了幻觉响应而惨败。我们需要评估其行为质量，而不仅仅是功能正确性。这个门可以通过两种主要方式实现：

1. 手动”预 PR”评估

对于寻求灵活性或刚开始评估旅程的团队，质量门通过团队流程来强制执行。在提交拉取请求（PR）之前，AI 工程师或提示工程师在本地运行评估套件。将新 Agent 与生产基线对比的性能报告随后附在 PR 描述中。这使评估结果成为人工审查的必要制品。审查者——通常是另一位 AI 工程师或机器学习治理人员——现在不仅负责评估代码，还负责评估 Agent 在护栏违规和提示注入漏洞方面的行为变化。

2. 自动化流水线内门控

对于成熟团队，由数据科学和 MLOps 团队构建并维护的评估框架直接集成到 CI/CD 流水线中。评估失败会自动阻止部署，提供机器学习治理团队定义的质量标准的严格、程序化执行。这种方法用自动化的一致性换取手动审查的灵活性。CI/CD 流水线可以配置为自动触发评估作业，将新 Agent 的响应与黄金数据集进行比较。如果关键指标（例如”工具调用成功率”或”有帮助性”）低于预定义阈值，部署将被程序化地阻止。

无论采用哪种方法，原则是相同的：没有 Agent 在未经质量检查的情况下进入生产。我们在第四天的深度剖析：Agent 质量中详细介绍了衡量什么以及如何构建这个评估框架。

自动化 CI/CD 流水线

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

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

一个强健的流水线被设计为漏斗形。它尽早、尽可能廉价地捕获错误，这种做法通常被称为”左移”。它将快速的预合并检查与更全面、资源密集的后合并部署分离。这个渐进式工作流通常分为三个不同阶段：

阶段一：预合并集成（CI）

流水线的第一个职责是为开启拉取请求的 AI 工程师或提示工程师提供快速反馈。自动触发后，这个 CI 阶段充当主分支的守门人。它运行快速检查，如单元测试、代码检查和依赖扫描。至关重要的是，这是运行由提示工程师设计的 Agent 质量评估套件的理想阶段。这在变更被合并之前，就能立即反馈变更是否改善或降低了 Agent 在关键场景中的表现。

阶段二：暂存环境中的后合并验证（CD）

一旦变更通过所有 CI 检查——包括性能评估——并被合并，焦点从代码和性能正确性转移到集成系统的运营就绪性。持续部署（CD）流程通常由 MLOps 团队管理，将 Agent 打包并部署到暂存环境——一个生产环境的高保真副本。在这里运行更全面、资源密集的测试，例如负载测试和针对远程服务的集成测试。这也是内部用户测试（通常称为”狗粮测试”）的关键阶段，公司内部人员可以与 Agent 互动并在到达最终用户之前提供定性反馈。

阶段三：门控部署到生产

在 Agent 在暂存环境中经过彻底验证后，最后一步是部署到生产环境。这几乎从不是完全自动化的，通常需要产品负责人给出最终批准，确保人机协同（HITL）。获批后，在暂存中经过测试和验证的确切部署制品被推广到生产环境。

使这个三阶段 CI/CD 工作流成为可能需要强健的自动化基础设施和适当的密钥管理。这种自动化由两项关键技术驱动：

• 基础设施即代码（IaC）：Terraform 等工具以编程方式定义环境，确保它们是相同的、可重复的且受版本控制的。
• 自动化测试框架：Pytest 等框架在每个阶段执行测试和评估，处理特定于 Agent 的制品，如对话历史、工具调用日志和动态推理追踪。

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

安全发布策略

虽然全面的预生产检查至关重要，但真实世界的应用不可避免地会暴露出未预见的问题。与其一次性将 100% 的用户切换过来，不如通过谨慎监控的逐步发布来最小化风险。

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

• 金丝雀发布：从 1% 的用户开始，监控提示注入和意外工具使用。逐步扩大规模或立即回滚。
• 蓝绿部署：运行两个相同的生产环境。将流量路由到”蓝”环境，同时向”绿”环境部署，然后立即切换。如果出现问题，切换回来——零停机，即时恢复。
• A/B 测试：在真实业务指标上比较 Agent 版本，做出数据驱动的决策。
• 特性标志：部署代码但动态控制发布，先用精选用户测试新功能。

所有这些策略都有一个共同基础：严格的版本控制。每个组件——代码、提示、模型端点、工具模式、内存结构，甚至评估数据集——都必须进行版本控制。当问题出现时，这能够立即回滚到已知的良好状态。

从一开始就构建安全性

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

与遵循预定路径的传统软件不同，Agent 会做出决策。它们解释模糊的请求，访问多种工具，并在会话间维持记忆。这种自主性带来了独特的风险：

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

幸运的是，Google 的 Secure AI Agents 方法和 Google 安全 AI 框架（SAIF）等框架通过三层防御来应对这些挑战：

1. 策略定义和系统指令（Agent 的宪法）
2. 护栏、安全措施和过滤（执行层）
3. 持续保证和测试

生产中的运营

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

管理这种自主性需要不同的运营模型。有效的团队采用持续循环，而不是静态监控：观察系统的实时行为，行动以维持性能和安全，演进 Agent 基于生产学习。这个集成循环是在生产中成功运营 Agent 的核心纪律。

观察：Agent 的感知系统

要信任和管理一个自主 Agent，你必须首先了解其过程。可观测性提供了这种关键洞察，作为后续”行动”和”演进”阶段的感知系统。强健的可观测性实践建立在三个支柱上：

• 日志：细粒度、事实性的日记，记录发生了什么，记录每次工具调用、错误和决策。
• 追踪：连接各个日志的叙事，揭示 Agent 采取某个行动的因果路径。
• 指标：聚合的报告卡，在规模上汇总性能、成本和运营健康状况。

行动：运营控制的杠杆

没有行动的观察只是昂贵的仪表板。“行动”阶段是关于实时干预——基于你观察到的内容，拉动管理 Agent 性能、成本和安全的杠杆。

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

• 设计扩展性：水平扩展、异步处理、外部化状态管理。
• 平衡竞争目标：速度（延迟）、可靠性（处理故障）、成本。

管理风险：安全响应手册

当检测到威胁时，响应应遵循明确的顺序：遏制、分类、解决。

演进：从生产中学习

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

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

生产洞察只有在你能快速采取行动时才有价值。这就是自动化 CI/CD 流水线成为运营循环中最关键组件的原因。

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

1. 分析生产数据
2. 更新评估数据集
3. 优化和部署

演进安全：生产反馈循环

每次安全事件都是改进系统的机会。关键是建立一个结构化的反馈循环，将安全事件转化为评估案例，并更新护栏和过滤策略。

超越单 Agent 运营

你已经掌握了在生产中运营单个 Agent 的技术。但随着组织扩展到数十个专业 Agent——每个都由不同团队使用不同框架构建——一个新的挑战出现了：这些 Agent 无法协作。下一节探讨标准化协议如何将这些孤立的 Agent 转化为可互操作的生态系统。

A2A——复用性与标准化

你已经在整个组织中构建了数十个专业 Agent。但问题是：这些 Agent 无法相互通信——无论是因为它们在不同框架、不同项目还是不同云上创建。

这种孤立造成了巨大的低效。为了解决这个问题，需要一种建立在两个不同但互补协议上的标准化原则性方法。虽然模型上下文协议（MCP）为工具集成提供了通用标准，但对于智能 Agent 之间所需的复杂、有状态的协作，它是不够的。这正是 Agent2Agent（A2A）协议设计要解决的问题。

这种区别至关重要：MCP 让你说”做这件特定的事”，而 A2A 让你说”实现这个复杂的目标”。

A2A 协议：从概念到实现

A2A 协议旨在打破组织孤岛，实现 Agent 之间的无缝协作。协作的第一步是发现合适的 Agent 进行委托——这通过 Agent Cards 实现，它是作为每个 Agent 名片的标准化 JSON 规范。

{
  "name": "Customer Support Agent",
  "description": "Handles customer inquiries and support tickets",
  "url": "https://agent.example.com/customer-support",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "handle_inquiry",
      "name": "Handle Customer Inquiry",
      "description": "Process and respond to customer support requests",
      "inputModes": ["text"],
      "outputModes": ["text"]
    },
    {
      "id": "escalate_ticket",
      "name": "Escalate Support Ticket",
      "description": "Escalate complex issues to human agents",
      "inputModes": ["text"],
      "outputModes": ["text"]
    }
  ]
}

Agent Card 包含 Agent 能力的全面描述，使其他 Agent 和编排系统能够发现和选择合适的 Agent 来委托任务。

以下是将 Agent 转换为 A2A 兼容格式的示例：

def to_a2a(self) -> dict:
    """将 Agent 转换为 A2A AgentCard 格式"""
    return {
        "name": self.name,
        "description": self.description,
        "url": self.endpoint_url,
        "version": self.version,
        "capabilities": {
            "streaming": self.supports_streaming,
            "pushNotifications": self.supports_push
        },
        "skills": [skill.to_dict() for skill in self.skills]
    }

而 RemoteA2aAgent 类允许一个 Agent 将任务委托给另一个远程 Agent：

class RemoteA2aAgent:
    """通过 A2A 协议与远程 Agent 交互的客户端"""

    def __init__(self, agent_card: dict):
        self.agent_card = agent_card
        self.url = agent_card["url"]
        self.client = httpx.AsyncClient()

    async def send_task(self, task: str, context: dict = None) -> str:
        """向远程 Agent 发送任务并等待结果"""
        payload = {
            "task": task,
            "context": context or {}
        }
        response = await self.client.post(
            f"{self.url}/tasks/send",
            json=payload
        )
        response.raise_for_status()
        return response.json()["result"]

A2A 与 MCP 如何协同工作

A2A 和 MCP 不是竞争标准；它们是设计在不同抽象级别上运行的互补协议。MCP 是工具和资源的领域。A2A 是其他 Agent 的领域。

一个实用的类比是一家由自主 AI Agent 组成的汽车修理店。

想象一下，你带着汽车去修理店说：“我的车发出异响。“这是一个复杂的、开放式的目标——这是 A2A 领域。接待 Agent（总 Agent）接收你的请求，分析问题，并将其委托给诊断 Agent（专业 Agent）。诊断 Agent 使用各种工具进行深入检查——OBD 扫描仪工具、振动分析工具、历史维修记录查询工具。这些工具调用是 MCP 领域——特定、确定性的操作，产生精确的结果。诊断完成后，诊断 Agent 将发现报告回接待 Agent，后者协调维修计划，可能还会委托给其他专业 Agent，如零件 Agent 或调度 Agent。

这个例子说明了关键区别：

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

随着 Agent 数量增加，你需要一种系统的方式来发现和管理它们。这里有两种关键的注册表架构：

工具注册表

工具注册表使用 MCP 等协议来目录化所有可用资产。它提供：

• 工具发现：Agent 可以查询注册表以找到完成任务的合适工具
• 版本管理：跟踪工具版本并确保兼容性
• 访问控制：管理哪些 Agent 可以访问哪些工具

Agent 注册表

Agent 注册表将相同的概念应用于 Agent，使用 A2A 的 AgentCards 等格式：

• Agent 发现：允许编排系统找到合适的专业 Agent
• 能力索引：基于技能和能力进行搜索
• 健康监控：追踪 Agent 可用性和性能

结合工具注册表和 Agent 注册表，你可以构建完全动态的、自我组织的多 Agent 系统，其中 Agent 可以在运行时发现彼此和所需工具，实现真正的模块化和可扩展性。

综合全局：AgentOps 生命周期

将所有这些组件整合在一起，就形成了 AgentOps 生命周期——一个端到端的框架，用于管理生产 AI Agent 系统。

AgentOps 生命周期涵盖三个主要环境：

开发环境：AI 工程师和提示工程师在这里构建和迭代 Agent。评估套件在本地运行，在问题进入主分支之前捕获回归。

暂存环境：集成测试、负载测试和内部用户测试在这里进行。这是高保真的生产副本，让团队在不影响真实用户的情况下验证系统行为。

生产环境：真实用户在这里与 Agent 交互。可观测性工具持续监控行为，安全系统实时响应威胁，反馈循环捕获改进机会。

贯穿这三个环境的是 AgentOps 核心能力：

• 评估：持续质量门控，确保每次变更都符合性能和安全标准
• CI/CD：自动化流水线，将变更从开发推进到生产
• 可观测性：日志、追踪和指标，提供对 Agent 行为的完整可见性
• 安全：多层防御，保护 Agent 免受提示注入、数据泄露和记忆污染的侵害
• A2A 协作：标准化协议，实现多 Agent 系统中的无缝通信

结论：用 AgentOps 弥合最后一公里

将 AI 原型转变为生产系统是一场组织变革，需要新的运营纪律：AgentOps。

大多数 Agent 项目失败于”最后一公里”，原因不在于技术，而在于自主系统的运营复杂性被低估了。

你的前进路径：

如果你刚刚起步，专注于基础：

• 从第一天就设置评估框架
• 实现基本的 CI/CD 流水线，包括自动化测试
• 构建可观测性基础（日志、追踪、指标）
• 从安全开始：策略定义、基本护栏

如果你正在扩展，提升你的实践：

• 实现评估门控部署的自动化
• 通过 A2A 协议构建多 Agent 协作
• 建立工具和 Agent 注册表以实现可发现性
• 实施金丝雀和蓝绿等高级发布策略

下一个前沿不仅仅是构建更好的单个 Agent，而是编排能够学习和协作的复杂多 Agent 系统。掌握 AgentOps——评估、CI/CD、可观测性和 A2A 的结合——是从精彩演示到企业级影响的关键差异化因素。

那些投资于这种运营严格性的组织将是那些超越炒作、部署真正值得信任的 AI 系统的组织。那种信任，一如既往，不是希望或运气的问题——它是通过我们在本白皮书中概述的系统性、工程严格性的方法构建的。

参考文献

1. Google Cloud Platform Agent Starter Pack: github.com/GoogleCloudPlatform/agent-starter-pack
2. Google Secure AI Framework (SAIF): safety.google/saif
3. Agent2Agent (A2A) Protocol: github.com/google/A2A
4. Model Context Protocol (MCP): modelcontextprotocol.io
5. Vertex AI Evaluation Service: cloud.google.com/vertex-ai/docs/evaluation
6. Google Cloud Secret Manager: cloud.google.com/secret-manager

欢迎关注我的其它发布渠道

WeChat