Day5 从原型到生产

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

致谢 内容贡献者

Derek Egan

Chase Lyall

Anant Nawalgaria

Lavi Nigam

Kanchana Patlolla

Michael Vakoc

编辑

Anant Nawalgaria

Kanchana Patlolla

设计师

Michael Lanning

1. 摘要

本白皮书提供了关于AI Agent运营生命周期的全面技术指南，重点关注部署、扩展和生产化。在涵盖评估和可观察性的第4天基础上，本指南强调如何通过健壮的CI/CD流水线和可扩展的基础设施建立必要的信任，将Agent投入生产。它探讨了从原型到企业级解决方案的Agent系统过渡的挑战，特别关注Agent2Agent（A2A）互操作性。本指南为AI/ML工程师、DevOps专业人士和系统架构师提供了实用的见解。

2. 引言：从原型到生产

您可以在几分钟内启动一个AI Agent原型，甚至可能只需要几秒钟。但将这个聪明的演示变成一个值得信赖、适用于生产的企业级系统，您的业务可以依赖的系统？这才是真正的挑战所在。欢迎来到“最后一英里”的生产差距，我们在实践中与客户持续观察到，大约80%的努力不是花在Agent的核心智能上，而是花在使其可靠和安全所需的基础设施、安全和验证上。

跳过这些最后一步可能会造成一些问题。例如：

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

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

这创造了一些独特的运营难题，需要专门的策略： - 动态工具编排：Agent的“轨迹”在它选择工具时实时组装。这需要一个强大的版本控制、访问控制和可观察性，因为每次的行为都不同。 - 可扩展的状态管理：Agent可以在交互中记住事情。在规模上安全且一致地管理会话和内存是一个复杂的系统设计问题。

不可预测的成本与延迟：Agent可以通过多种路径来找到答案，这使得其成本和响应时间难以预测和控制，除非进行智能的预算管理和缓存。

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

这份白皮书是您构建该基础并通往生产之路的逐步操作指南！我们将从预生产必备要素开始，向您展示如何设置自动CI/CD管道，并使用严格的评估作为关键的质量检查。接着，我们将深入探讨在野外运行Agent的挑战，涵盖扩展、性能调优和实时监控的策略。最后，我们将展望充满活力的多Agent系统世界，探讨Agent到Agent协议，并探索使它们安全有效地通信所需的因素。

实践实施指南

在这份白皮书中，实用示例参考了Google Cloud Platform Agent Starter Pack $ ^{1} $ ——一个提供适用于Google Cloud的生产就绪生成式AI Agent模板的Python包。它包括预构建的Agent、自动CI/CD设置、Terraform部署、Vertex AI评估集成和内置的Google Cloud可观察性。该入门包通过您可以在几分钟内部署的运行代码展示了此处讨论的概念。

3. 人员和流程

在讨论了CI/CD、可观察性和动态管道之后，为什么还要关注人员和流程？因为即使是最先进的技术，如果没有合适的团队来构建、管理和治理，也是无效的。

那位客户服务Agent不会神奇地阻止免费产品的发放；AI工程师和提示工程师设计和实现了防护措施。机密数据库不是由一个抽象概念来保护；云平台团队配置了身份验证。在每一个成功的、生产级别的Agent背后，都有一个协调良好的专业团队，在本节中，我们将介绍关键角色。

图 1：展示“运维”是人员、流程和技术交集的示意图

在传统的 MLOps 生态系统中，这涉及到几个关键团队：

云平台团队：由云架构师、管理员和安全专家组成，该团队管理基础云基础设施、安全性和访问控制。团队授予工程师和服务账户最小权限角色，确保只有访问必要资源的权限。
数据工程团队：数据工程师和数据所有者构建和维护数据管道，处理数据摄取、准备和质量标准。
数据科学和 MLOps 团队：包括进行模型实验和训练的数据科学家，以及使用 CI/CD 在规模上自动化端到端 ML 管道（例如，预处理、训练、后处理）的 ML 工程师。MLOps 工程师通过构建和维护标准化的管道基础设施来支持这一工作。
机器学习治理：这个集中式功能，包括产品所有者和审计员，监督 ML 生命周期，作为工件和指标的存储库，以确保合规性、透明度和问责制。生成式 AI 为这个景观引入了新的复杂性和专业角色：
提示工程师：虽然这个角色名称在行业中仍在演变，但这些个人结合了编写提示的技术技能和深厚的领域专业知识。他们定义模型正确的提问和预期答案，尽管在实践中这项工作可能由 AI 工程师、领域专家或专门的专家根据组织的成熟度来完成。
AI 工程师：他们负责将 GenAI 解决方案扩展到生产环境，构建强大的后端系统，该系统包含规模化的评估、安全网和 RAG/工具集成。
DevOps/应用开发者：这些开发者构建前端组件和用户友好的界面，与 GenAI 后端集成。组织的规模和结构将影响这些角色；在较小的公司中，个人可能需要戴多顶帽子，而成熟组织将拥有更多专业化的团队。有效协调所有这些不同的角色对于建立坚实的运营基础和成功地将传统 ML 和生成式 AI 初始化项目投入生产至关重要。

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

4. 生产之旅

现在我们已经组建了团队，接下来是流程。我们如何将这些专家的工作转化为一个值得信赖、可靠且为用户准备就绪的系统？

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

4.1 评估作为质量门

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

手动“预PR”评估：对于寻求灵活性或刚开始评估旅程的团队，质量门通过团队流程强制执行。在提交拉取请求（PR）之前，AI工程师或提示工程师（或负责组织中代理行为的任何人）在本地运行评估套件。然后，将生成的性能报告——比较新代理与生产基线——链接到PR描述中。这使得评估结果成为人类审查的强制文档。现在，审阅者——通常是另一位AI工程师或机器学习监管者——负责评估的不仅仅是代码，还有代理的行为变化是否违反了安全线以及提示注入漏洞。
自动管道门：对于成熟的团队，由数据科学和MLOps团队构建和维护的评估工具直接集成到CI/CD管道中。失败的评估会自动阻止部署，为机器学习治理团队定义的质量标准提供严格、程序化的强制执行。这种方法以手动审查的灵活性换取了自动化的连贯性。CI/CD管道可以配置为自动触发一个评估作业，将新代理的响应与黄金数据集进行比较。如果关键指标，如“工具调用成功率”或“有用性”，低于预定义的阈值，则程序性地阻止部署。

无论采用哪种方法，原则都是相同的：没有经过质量检查的代理不能进入生产。我们在第4天的深入探讨中涵盖了要测量的具体内容和如何构建这个评估工具箱的细节：代理质量：可观察性、日志记录、跟踪、评估、指标，该探讨从制作“黄金数据集”（一个精心策划的、代表性的测试案例集，旨在评估代理的预期行为和安全线合规性）到实施LLM作为裁判的技术，最终使用像Vertex AI Evaluation $ ^{2} $ 这样的服务来推动评估。

一个AI代理是一个复合系统，它不仅包括源代码，还包括提示、工具定义和配置文件。这种复杂性带来了重大挑战：我们如何确保对提示的更改不会降低工具的性能？我们如何在它们达到用户之前测试所有这些组件之间的相互作用？解决方案是一个CI/CD（持续集成/持续部署）管道。它不仅仅是自动化脚本，而是一个结构化的流程，它帮助团队中的不同人员协作管理复杂性并确保质量。它通过分阶段测试更改，在代理发布给用户之前逐步建立信心。一个健壮的管道被设计成一个漏斗。它尽可能地早且低成本地捕获错误，这种做法通常被称为“左移”。它将快速预合并检查与更全面、资源密集型的后合并部署分开。这种渐进式工作流程通常分为三个不同的阶段：

第一阶段：预合并集成（CI）。管道的第一个责任是为提交了拉取请求的AI工程师或提示工程师提供快速反馈。这个CI阶段由自动触发，充当主分支的守门人。它运行快速检查，如单元测试、代码检查和依赖项扫描。关键的是，这是运行由提示工程师设计的代理质量评估套件的理想阶段。这可以在合并之前立即提供关于更改是否改善或降低代理针对关键场景的性能的反馈。通过在这里捕获问题，我们防止了主分支的污染。使用Agent Starter Pack（ASP）生成的PR检查配置模板$^{3}$是一个使用Cloud Build实现此阶段的实际例子$^{4}$。
第二阶段：在预发布环境中的后合并验证（CD）。一旦一个更改通过了所有CI检查——包括性能评估——并被合并，重点就转向了集成系统的操作就绪性。持续部署（CD）过程通常由MLOps团队管理，它打包代理并将其部署到预发布环境——生产环境的高保真副本。在这里，运行更全面、资源密集型的测试，如负载测试和针对远程服务的集成测试。这也是内部用户测试的关键阶段（通常称为“狗食”），公司内部人员可以与代理互动并提供定性反馈，在它到达最终用户之前。这确保了代理作为一个集成系统在类似生产的环境下可靠且高效地运行，在它被认为可以发布之前。ASP的预发布部署模板$^{5}$展示了这种部署的例子。
第三阶段：受控部署到生产环境。在代理在预发布环境中经过彻底验证后，最后一步是部署到生产环境。这几乎永远不会完全自动化，通常需要产品负责人给出最终批准，确保有人工介入。一旦批准，经过测试和验证的精确部署组件将从预发布环境提升到生产环境。使用ASP生成的生产部署模板$^{6}$展示了如何在这一最终阶段检索已验证的组件，并使用适当的保护措施将其部署到生产环境。

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

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

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

此外，像工具的API密钥这样的敏感信息应通过Secret Manager $ ^{8} $ 之类的服务安全地管理，并在运行时注入到代理的环境中，而不是在存储库中硬编码。

4.3 安全发布策略

虽然全面的预生产检查是必不可少的，但现实世界的应用不可避免地会揭示未预见到的问题。与其一次性切换100%的用户，不如通过逐步发布并仔细监控来最小化风险。

原型到生产

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

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

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

您可以使用Agent Engine $ ^{9} $ 或Cloud Run $ ^{10} $ 部署代理，然后利用Cloud Load Balancing $ ^{11} $ 进行跨版本的流量管理或连接到其他微服务。Agent Starter Pack $ ^{1} $ 提供了带有GitOps工作流程的现成模板——每次部署都是一个git提交，每次回滚都是一个git revert，您的存储库成为当前状态和完整部署历史的唯一真相来源。

4.4 从一开始构建安全性

安全的部署策略可以保护您免受错误和中断的影响，但代理面临一个独特的挑战：它们可以自主推理和行动。即使代理部署得完美无缺，如果没有经过适当的安全和责任措施，它仍然可能造成损害。这需要从第一天开始嵌入的综合治理策略，而不是事后添加。

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

提示注入和恶意行为：恶意用户可以欺骗代理执行未打算的行为或绕过限制。
数据泄露：代理可能会无意中通过其响应或工具使用泄露敏感信息。
内存中毒：存储在代理内存中的错误信息可能会破坏所有未来的交互。

幸运的是，像Google的Secure AI Agents方法 $ ^{12} $ 和Google Secure AI Framework（SAIF） $ ^{13} $ 这样的框架通过三层防御来应对这些挑战：

政策定义和系统指令（Agent的宪法）：这个过程从定义期望和不可期望的Agent行为政策开始。这些政策被设计成系统指令（SIs），作为Agent的核心宪法。
防护栏、保障措施和过滤（执行层）：这一层充当硬性停止的执行机制。
输入过滤：使用分类器和像Perspective API这样的服务来分析提示，并在它们到达Agent之前阻止恶意输入。
输出过滤：在Agent生成响应后，Vertex AI内置的安全过滤器提供对有害内容、个人身份信息（PII）或政策违规的最终检查。例如，在将响应发送给用户之前，它将通过Vertex AI内置的安全过滤器$^{14}$，这些过滤器可以被配置为阻止包含特定PII、有毒语言或其他有害内容的输出。
人类在环（HITL）升级：对于高风险或模糊的操作，系统必须暂停并升级到人类进行审查和批准。
持续保障和测试：安全性不是一次性的设置。它需要持续的评估和适应。
严格评估：对模型或其安全系统的任何更改都必须触发使用Vertex AI评估的全面评估管道的完整重新运行。
专用RAI测试：通过创建专用数据集或使用模拟Agent（包括中立观点（NPOV）评估和公平性评估）来严格测试特定风险。
积极的红队攻击：通过创造性的手动测试和基于AI的基于角色的模拟来积极尝试破坏安全系统。

5. 生产中的操作

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

管理这种自主性需要不同的运营模式。而不是静态监控，有效的团队采用一个持续循环：实时观察系统的行为，采取行动以维持性能和安全，并根据生产学习来进化Agent。这个综合循环是成功在生产线中运营Agent的核心学科。

5.1 观察：您的Agent的感官系统

要信任和管理一个自主Agent，您必须首先了解其过程。可观察性提供了这种关键的洞察力，作为后续“行动”和“进化”阶段的感官系统。一个强大的可观察性实践建立在三个支柱之上，这三个支柱共同提供了一个完整的Agent行为图景：

日志：详细的事实日记，记录了每个工具调用、错误和决策。
跟踪：连接单个日志的叙述，揭示了Agent采取特定行动的原因路径。
指标：汇总的报告卡，总结性能、成本和运营健康状况，以展示系统表现如何。

例如，在Google Cloud中，这是通过操作套件实现的：用户的请求在Cloud Trace$^{15}$中生成一个唯一的ID，将Vertex AI Agent Engine$^{9}$调用、模型调用和工具执行与可见持续时间链接起来。详细的日志流向Cloud Logging$^{16}$，而Cloud Monitoring$^{17}$仪表板在超过延迟阈值时发出警报。Agent开发套件（ADK）$^{18}$提供了内置的Cloud Trace集成，用于自动检测Agent操作。

通过实施这些支柱，我们能够从黑暗中走向清晰、数据驱动的对代理行为的了解，为在生产环境中有效管理代理提供了基础。（关于这些概念的详细讨论，请参阅《代理质量：可观察性、日志记录、跟踪、评估、指标》）。

5.2 行动：操作控制的杠杆

仅有观察而没有行动只是昂贵的仪表盘。 “行动”阶段涉及实时干预——根据观察到的结果，通过拉动管理代理性能、成本和安全的杠杆。

将“行动”视为系统自动化的反射机制，旨在实时维持稳定性。相比之下，“进化”，将在后面介绍，是学习行为以创建根本更好的系统的战略过程。

由于代理是自主的，你不能预先编程每个可能的结果。相反，你必须构建强大的机制来影响其在生产中的行为。这些操作杠杆主要分为两大类：管理系统的健康和管理其风险。

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

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

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

水平扩展：将代理设计为无状态的、容器化的服务。具有外部状态，任何实例都可以处理任何请求，从而使得像 Cloud Run $^{10}$ 或 Vertex AI Agent Engine Runtime $^{9}$ 这样的托管平台能够自动扩展。
异步处理：对于长时间运行的任务，使用事件驱动模式卸载工作。这使代理保持响应，而复杂的工作在后台处理。例如，在 Google Cloud 上，一个服务可以将任务发布到 Pub/Sub $^{19}$，然后触发 Cloud Run 服务进行异步处理。
外部化状态管理：由于大语言模型是无状态的，持久化内存到外部是非协商的。这突出了关键架构选择：Vertex AI Agent Engine 提供内置的、持久的会话和内存服务，而 Cloud Run 提供直接与数据库（如 AlloyDB $^{20}$ 或 Cloud SQL $^{21}$）集成的灵活性。
平衡竞争目标：扩展始终涉及平衡三个竞争目标：速度、可靠性和成本。
速度（延迟）：通过设计并行工作、积极缓存结果和使用较小、高效的模型来处理常规任务，保持代理快速。
可靠性（处理故障）：代理必须处理暂时性故障。当调用失败时，自动重试，理想情况下使用指数退避，以便服务有时间恢复。这需要设计“安全重试”（幂等）工具，以防止如重复收费等错误。
成本：通过缩短提示、使用更便宜的模型来处理简单任务以及批量发送请求来降低代理的成本。

管理风险：安全响应手册

由于代理可以自主行动，你需要一个快速遏制手册。当检测到威胁时，响应应遵循一个明确的顺序：遏制、诊断和解决。

第一步是立即遏制。重点是停止伤害，通常使用“断路器”——一个可以立即禁用受影响工具的功能标志。

接下来是诊断。在威胁被遏制后，可疑请求被路由到人工审查队列（HITL）以调查利用的范围和影响。

最后，重点转向永久性解决方案。团队开发补丁——如更新的输入过滤器或系统提示——并通过自动化的 CI/CD 管道部署，确保修复在永久阻止利用之前得到充分测试。

5.3 进化：从生产中学习

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

“行为”阶段提供了系统的即时战术反应，而“进化”阶段则是关于长期战略改进。它从分析你在可观察性数据中收集到的模式和趋势开始，并提出了一个关键问题：“我们如何修复根本原因，以确保这个问题不再发生？”

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

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

从生产中获得的洞察力只有在你能够快速采取行动时才有价值。如果你需要六个月的时间来部署一个修复方案，那么发现30%的用户在特定任务上失败是无用的。

这就是你在预生产阶段构建的自动化CI/CD管道成为操作循环中最关键组件的地方。它是推动快速进化的引擎。一条快速、可靠的生产路径允许你在数小时或数天内，而不是数周或数月内，关闭观察和改进之间的循环。

当你确定一个潜在的改进——无论是改进的提示、新工具还是更新的安全护栏——过程应该是：

提交更改：建议的改进被提交到你的版本控制仓库。
触发自动化：提交自动触发你的CI/CD管道。
严格验证：管道运行完整的单元测试、安全扫描和针对更新数据集的Agent质量评估套件。
安全部署：一旦验证通过，更改将使用安全的发布策略部署到生产环境中。

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

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

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

这创造了一个良性循环，你的Agent随着每次用户交互而持续改进。

进化循环的实际应用

一位零售Agent的日志（观察）显示，15%的用户在请求“类似产品”时收到错误。产品团队通过创建一个高优先级工单来采取行动。进化阶段开始：使用生产日志为评估数据集创建一个新的失败测试用例。一位AI工程师改进了Agent的提示，并添加了一个新的、更健壮的相似性搜索工具。更改被提交，通过了现在更新的评估套件，并通过金丝雀部署安全地推出，在不到48小时内解决了用户问题。

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

虽然基础的安全和责任框架在预生产（第3.4节）中已经建立，但这项工作永远不会真正完成。安全不是一个静态的清单；它是一个动态的、持续的适应过程。生产环境是最终的测试场，在那里收集的洞察对于强化Agent抵御现实世界威胁至关重要。

这就是观察→行动→进化循环在安全方面变得至关重要的地方。这个过程是进化工作流程的直接扩展：

观察：你的监控和日志系统检测到一个新的威胁向量。这可能是一种绕过你当前过滤器的创新提示注入技术，或者是一次导致轻微数据泄露的意外交互。
行动：立即的安全响应团队控制了威胁（如第4.2节所述）。
进化：这是实现长期弹性的关键步骤。安全洞察被反馈到您的开发生命周期中：
更新评估数据集：将新的提示注入攻击添加为永久性测试案例到您的评估套件中。
精炼防护措施：提示工程师或AI工程师精炼代理的系统提示、输入过滤器或工具使用策略，以阻止新的攻击向量。
自动化和部署：工程师提交更改，触发完整的CI/CD管道。更新的代理将严格验证于新扩展的评估集，并部署到生产环境中，关闭漏洞。

这创建了一个强大的反馈循环，每个生产事件都会使您的代理变得更强大、更具弹性，将您的安全态势从防御姿态转变为持续、主动的改进。

要了解更多关于负责任的人工智能和保障AI代理系统安全的信息，请参阅谷歌的《安全AI代理方法》白皮书$^{12}$和谷歌安全AI框架（SAIF）$^{13}$。

5.5 超越单一代理操作

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

6. A2A - 可重用性和标准化

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

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

为了解决这个问题，需要一种基于两个不同但互补协议的原则性标准化方法。虽然我们在《代理工具和MCP的互操作性》中详细介绍了模型上下文协议（MCP$^{22}$），它为工具集成提供了一个通用标准，但它不足以满足智能代理之间复杂、有状态协作的需求。这就是Agent2Agent（A2A$^{23}$）协议旨在解决的问题，现在由Linux基金会管理。

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

6.1 A2A协议：从概念到实施

A2A协议旨在打破组织壁垒，并使代理之间实现无缝协作。考虑一个场景，一个欺诈检测代理发现可疑活动。为了理解完整的上下文，它需要来自单独的交易分析代理的数据。如果没有A2A，分析师必须手动弥合这个差距——这个过程可能需要数小时。有了A2A，代理可以自动协作，几分钟内解决问题。

协作的第一步是发现合适的代理进行委派——这通过代理卡（Agent Cards）得以实现，$ ^{24} $ 代理卡是一组标准化的JSON规范，相当于每个代理的名片。代理卡描述了代理能做什么，其安全要求、技能以及如何联系它（URL），使得生态系统中任何其他代理都能动态地发现其同伴。以下是一个示例代理卡：

{
  "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 的示例代理卡片

采用此协议不需要进行架构上的大改动。例如，ADK 等框架显著简化了这一过程（$文档^{25}$）。您可以通过一个函数调用将现有代理转换为 A2A 兼容，这会自动生成其代理卡片并将其发布到网络上。

# 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 工具将现有 Agent 封装并暴露以进行 A2A 通信

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

# 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
)

Snippet 3: 使用 ADK 的 RemoteA2aAgent 类连接并消费远程 Agent

这解锁了强大的分层组合功能。根 Agent 可以配置为协调一个用于简单任务的本地子 Agent，以及通过 A2A 连接的远程、专业 Agent，从而创建一个更强大的系统。

# 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）作为层次化代理结构中的子代理

然而，启用这种级别的自主协作引入了两个不可协商的技术要求。首先是分布式追踪，每个请求都携带一个唯一的追踪 ID，这对于调试和在多个代理之间维护一致的审计记录至关重要。其次是强大的状态管理。A2A 交互本质上是有状态的，需要复杂的数据持久层来跟踪进度并确保事务完整性。

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

6.2 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提供了标准化的管道，使机械师代理能够可靠地使用其特定的、结构化的工具来完成工作。

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

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

工具注册表使用类似于MCP的协议来编目所有资产，从函数到API。你不必给代理提供数千个工具的访问权限，而是创建精选列表，导致三种常见的模式：

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

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

代理注册表将相同的概念应用于代理，使用A2A的AgentCards等格式。它帮助团队发现和重用现有代理，减少重复工作。这也为自动化代理到代理委托奠定了基础，尽管这仍然是一个新兴模式。注册表以维护成本提供发现和治理。你可以考虑在没有它们的情况下开始，只有当你的生态系统规模需要集中管理时才构建它们！

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

7. 整合一切：代理操作生命周期

我们现在可以将这些支柱组装成一个单一的、统一的参考架构！生命周期始于开发者的内部循环——一个快速本地测试和原型设计的阶段，以塑造Agent的核心逻辑。一旦变更准备就绪，它将进入正式的预生产引擎，其中自动评估门控验证其质量与安全性，与黄金数据集进行对比。从那里，安全的发布将其推向生产环境，其中全面的可观察性捕捉了推动持续进化循环所需的真实世界数据，将每个洞察转化为下一次改进。

要全面了解操作AI Agent的过程，包括评估、工具管理、CI/CD标准化和有效的架构设计，请观看官方Google Cloud YouTube频道上的“AgentOps：操作AI Agent”视频 $^{26}$。

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

8. 结论：借助AgentOps跨越最后一英里

将人工智能原型迁移到生产系统是一项组织变革，需要一种新的运营纪律：AgentOps。

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

立即的收益——如防止安全漏洞或实现快速回滚——证明了投资的合理性。但真正的价值在于速度。成熟的AgentOps实践使团队能够在数小时内而不是数周内部署改进，将静态部署转变为持续演变的产物。

您的前进之路

如果您是初学者，请关注基础：构建您的第一个评估数据集，实施CI/CD管道，并建立全面的监控。Agent入门包是一个很好的起点——它可以在几分钟内创建一个具有这些基础的生产就绪代理项目。
如果您正在扩展，请提升您的实践：自动化从生产洞察到部署改进的反馈循环，并采用互操作性协议来构建一个统一的生态系统，而不仅仅是点解决方案。

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

我们希望这份操作手册能够赋予您构建下一代智能、可靠和值得信赖的AI的能力。跨越最后一英里因此不是项目的最终步骤，而是创造价值的第一步！

Day5 从原型到生产

本章结构

Day5 从原型到生产

目录

1. 摘要 ..... 5

2. 引言：从原型到生产 ..... 6

3. 人员与流程 ..... 8

4. 生产之旅 ..... 11

5. 生产中的运营 ..... 19

6. A2A - 可重用性和标准化 ..... 27

7. 整合一切：AgentOps生命周期 ..... 36

8. 结论：通过AgentOps弥合最后一英里差距 ..... 38

9. 参考 ..... 40

1. 摘要

2. 引言：从原型到生产

3. 人员和流程

4. 生产之旅

4.1 评估作为质量门

4.3 安全发布策略

原型到生产

4.4 从一开始构建安全性

5. 生产中的操作

5.1 观察：您的Agent的感官系统

5.2 行动：操作控制的杠杆

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

管理风险：安全响应手册

5.3 进化：从生产中学习

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

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

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

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

5.5 超越单一代理操作

6. A2A - 可重用性和标准化

6.1 A2A协议：从概念到实施

6.2 A2A 和 MCP 如何协同工作

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

7. 整合一切：代理操作生命周期

8. 结论：借助AgentOps跨越最后一英里

9. 脚注