AI Agent介绍与架构

作者：Alan Blount, Antonio Gulli, Shubham Saboo, Michael Zimmermann, 和 Vladimir Vuskovic

致谢内容贡献者

Enrique Chan

Mike Clark

Derek Egan

Julia Wiesinger

策划与编辑

Anant Nawalgaria

Kanchana Patlolla

设计师

Michael Lanning

1. 从预测型AI到自主代理

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

这个新的前沿建立在AI代理的基础上。代理不仅仅是静态工作流程中的AI模型；它是一个完整的应用程序，制定计划并采取行动来实现目标。它结合了语言模型（LM）的推理能力与实际行动能力，使其能够处理模型单独无法处理的复杂、多步骤任务。关键能力是代理可以独立工作，无需每一步都有人类指导，就能找出实现目标所需的下一步。

本文是五篇系列文章的第一篇，为从概念验证过渡到稳健、生产级代理系统的开发者、架构师和产品领导者提供正式指南。虽然构建一个简单的原型很简单，但确保安全性、质量和可靠性是一个重大挑战。本文提供了一个全面的基础：

核心结构：将代理分解为其三个基本组成部分：推理模型、可执行工具和治理编排层。
能力分类法：将Agent从简单的连接问题解决者分类到复杂的协作多Agent系统。
架构设计：深入探讨每个组件的实际设计考虑因素，从模型选择到工具实现。
适用于生产的构建：建立Agent运营学科，以评估、调试、安全性和扩展从单个实例到具有企业治理的机群规模的Agent系统。

基于之前的《Agent白皮书》^{1}和《Agent伴侣》^{2}；本指南提供了您成功构建、部署和管理这一代能够推理、行动和观察以实现目标的新一代智能应用所需的基础概念和战略框架。

语言不足以描述人类如何与AI互动。我们倾向于拟人化，并使用人类术语，如“思考”、“推理”和“知道”。我们还没有“具有语义意义的知道”与“具有最大化奖励函数高概率的知道”这样的词汇。这两种类型的“知道”结果在99.X%的情况下是相同的。

2. AI Agent简介

最简单的说法，AI Agent可以被定义为模型、工具、编排层和运行时服务的组合，它通过循环使用LM来实现目标。这四个元素构成了任何自主系统的基本架构。

模型（“大脑”）：作为Agent的中心推理引擎的核心语言模型（LM）或基础模型，用于处理信息、评估选项和做出决策。模型的类型（通用、微调或多模态）决定了Agent的认知能力。Agent系统是LM输入上下文窗口的最终管理者。
工具（“双手”）：这些机制将Agent的推理与外部世界连接起来，使Agent能够执行超越文本生成的动作。它们包括API扩展、代码函数和数据存储（如数据库或向量存储）以访问实时、事实信息。Agent系统允许LM规划使用哪些工具，执行工具，并将工具结果放入下一个LM调用的输入上下文窗口中。
编排层（“神经系统”）：管理Agent操作循环的治理过程。它处理规划、记忆（状态）和推理策略执行。这一层使用提示框架和推理技术（如思维链^{4}或ReAct^{5}）将复杂目标分解为步骤，并决定何时思考或使用工具。这一层还负责为Agent提供“记忆”。
部署（“身体和腿”）：在笔记本电脑上构建Agent对于原型设计是有效的，但生产部署才是使其成为可靠和可访问服务的关键。这涉及到在安全、可扩展的服务器上托管Agent，并将其与监控、日志记录和管理等基本生产服务集成。一旦部署，Agent可以通过图形界面供用户访问，也可以通过Agent到Agent（A2A）API由其他Agent以编程方式访问。

最终，构建生成式AI Agent是解决任务的新方法。传统的开发者充当“砖匠”，精确地定义每个逻辑步骤。相比之下，Agent开发者更像是一位导演。你不需要为每个动作编写显式的代码，而是设定场景（指导性指令和提示）、选择演员（工具和API），并提供必要的环境（数据）。主要任务变成了引导这个自主的“演员”以实现预期的表现。

您很快会发现，大语言模型最大的优势——其惊人的灵活性——也是您最大的烦恼。大语言模型能够做任何事情的能力，使得它难以可靠且完美地执行一项特定任务。我们过去称之为“提示工程”，现在称之为“上下文工程”，它引导大语言模型生成所需的输出。对于对大语言模型的任何一次调用，我们输入我们的指令、事实、可调用的工具、示例、会话历史、用户资料等——将上下文窗口填充恰好所需的信息，以获取我们需要的输出。Agent是一种软件，它管理大语言模型的输入以完成任务。

当出现问题时，调试变得至关重要。“Agent Ops”本质上重新定义了熟悉的测量、分析和系统优化的循环。通过跟踪和日志，您可以监控代理的“思维过程”，以识别偏离预期执行路径的偏差。随着模型的发展和框架的改进，开发者的角色是为提供关键组件：领域专业知识、明确的个性和与实际任务完成所需工具的无缝集成。重要的是要记住，全面的评估和评估往往超过初始提示的影响。

当一个代理被精确配置，具有明确的指令、可靠的工具和作为记忆的集成上下文，拥有出色的用户界面、规划能力和解决问题的能力，以及一般的世界知识时，它超越了仅仅是“工作流程自动化”的概念。它开始作为一个协作实体运作：一个高效、独特适应性强、能力非凡的新团队成员。

本质上，代理是一个专注于上下文窗口管理的系统。它是一个不懈的循环，包括组装上下文、提示模型、观察结果，然后为下一步重新组装上下文。上下文可能包括系统指令、用户输入、会话历史、长期记忆、来自权威来源的扎根知识、可能使用的工具以及已调用的工具的结果。这种对模型注意力的复杂管理，允许其推理能力为新颖的情况解决问题并完成目标。

Agentic问题解决过程

我们将AI代理定义为一种完整、以目标为导向的应用程序，它集成了推理模型、可操作的工具和治理编排层。简而言之，“具有完成目标所需工具的大语言模型在循环中。”

但是，这个系统实际上是如何工作的？从接收到请求的那一刻起，代理是如何做到交付结果的？

在核心上，代理通过一个连续、循环的过程来实现其目标。虽然这个循环可能变得非常复杂，但它可以分解为Agentic System Design一书中详细讨论的五个基本步骤：

获取任务：这个过程由一个具体、高级的目标启动。这个任务由用户（例如，“为即将到来的会议组织我团队的旅行”）或自动触发器（例如，“一个新的高优先级客户工单已到达”）提供。
扫描场景：代理感知其环境以收集上下文。这涉及到编排层访问其可用资源：“用户请求说了什么？”“我的长期记忆中有哪些信息？我已经尝试过这个任务了吗？上周用户是否给了我指导？”“我可以从我的工具（如日历、数据库或API）中访问什么？”
深思熟虑：这是Agent的核心“思考”循环，由推理模型驱动。Agent将任务（步骤1）与场景（步骤2）进行分析，并制定计划。这并非单一的想法，而通常是一系列推理：“为了预订旅行，我首先需要知道团队中有谁。我将使用get_team_roster工具。然后我需要通过calendar_api检查他们的可用性。”
执行行动：编排层执行计划的第一个具体步骤。它选择并调用适当的工具——调用API、运行代码函数或查询数据库。这是Agent在自身内部推理之外对世界采取行动。
观察与迭代：Agent观察其行动的结果。get_team_roster工具返回五个人的名单。这些新信息被添加到Agent的上下文或“记忆”中。然后循环重复，回到步骤3：“现在我已经有了名单，我的下一步是检查这五个人的日程。我将使用calendar_api。”

这个“思考、行动、观察”的循环持续进行——由编排层管理，由模型推理，由工具执行，直到Agent的内部计划完成，初始任务达成。

图1：Agent式AI问题解决流程

让我们以一个现实世界的例子来说明一个客户支持Agent如何在这个5步骤循环中运作：想象一下，一个用户问道：“我的订单号12345在哪里？”

Agent并非立即采取行动，而是首先进入其“Think It Through”阶段，制定完整的策略。它进行推理： “用户想要了解交付状态。为了提供完整的答案，我需要一个多步骤的计划：

识别：我必须首先在我们的内部数据库中找到该订单，以确认其存在并获取其详细信息。
跟踪：从这些详细信息中，我需要提取运输承运人的跟踪号码。然后，我将查询外部承运人的API以获取实时状态。
报告：最后，我必须将收集到的信息综合成一个清晰、有帮助的回复给用户。”

有了这个多步骤计划，Agent开始执行。在其第一个“行动”阶段，它执行计划的第一步，调用find_order("12345")工具。它观察到结果——一个完整的订单记录，包括跟踪号码“ZYX987”。 Agent的编排层认识到其计划的第一部分已经完成，并立即进入第二部分。它通过调用get_shipping_status("ZYX987")工具进行行动。它观察到新的结果：“已发货。” 最后，在成功执行了计划的数据收集阶段后，Agent进入“报告”步骤。它意识到自己拥有了所有必要的组件，计划了最终的消息，并通过生成回复：“您的订单号12345已‘发货’！”

3. Agentic系统的分类学

理解5步骤操作循环是拼图的第一部分。第二部分是认识到这个循环可以扩展其复杂性，以创建不同类别的Agent。对于架构师或产品领导者来说，一个关键初始决策是确定要构建哪种类型的Agent。我们可以将Agent式系统分类为几个广泛的层级，每个层级都建立在上一层的功能之上。

图2：5步法Agent系统

第0级：核心推理系统

在拥有代理之前，我们必须从其最基本的形式——“大脑”开始：推理引擎本身。在这个配置中，语言模型（LM）独立运行，仅根据其庞大的预训练知识做出响应，没有任何工具、记忆或与真实环境的交互。其优势在于广泛的训练，使其能够深入解释既定概念并规划如何解决问题。然而，其代价是完全缺乏实时意识；它对其训练数据之外的事件或事实完全“盲目”。例如，它可以解释职业棒球规则和纽约洋基队的完整历史。但如果你问，“昨晚洋基队的比赛最终比分是多少？”它将无法回答。那场比赛是一个发生在其训练数据收集之后的特定、真实世界事件，所以相关信息根本不存在于其知识中。

第1级：连接的解决问题者

在这一级别，推理引擎通过连接并利用外部工具——我们架构中的“手”组件——成为了一个功能性的代理。其问题解决不再局限于其静态、预训练的知识。使用5步循环，代理现在可以回答我们之前的问题。给定“任务”： “昨晚洋基队的比赛最终比分是多少？”其“思考”步骤识别这是一个实时数据需求。其“行动”步骤随后调用一个工具，如带有正确日期和搜索词的Google搜索API。它“观察”搜索结果（例如，“洋基队以5-3获胜”），并将这一事实综合成一个最终答案。

这种与世界互动的基本能力——无论是使用搜索工具获取比分、金融API获取实时股价，还是通过检索增强生成（RAG）访问数据库——是第1级代理的核心能力。

第2级：战略解决问题者

第2级标志着能力的显著扩展，从执行简单任务到战略规划复杂、多阶段目标。这里出现的关键技能是情境工程：代理主动选择、打包和管理其计划每一步最相关信息的能力。代理的准确性取决于一个专注、高质量的环境。情境工程整理模型的有限注意力，以防止过载并确保高效性能。例如，考虑“任务”： “在位于1600 Amphitheatre Parkway，Mountain View的办公室和位于1 Market St，San Francisco的客户办公室之间找到一个好的咖啡馆。” 一个第2级代理将开始制定计划：

Think：“我必须首先找到中点。”
Act：调用带有两个地址的地图工具。
Observe：“中点是Millbrae，CA。”
Think：“现在我必须找到Millbrae的咖啡馆。用户要求‘好的’咖啡馆，所以我将搜索评分为4星或更高的地方。”
Act：调用google_places工具，查询="咖啡店在Millbrae，CA"，min_rating=4.0。（这是情境工程——它自动从上一步的输出中创建了一个新的、专注的搜索查询）。
Observe：“搜索返回‘Millbrae Coffee’和‘The Daily Grind’。”
Think：“我将综合这些结果并向用户展示。”

这种战略规划还使主动协助成为可能，例如，一个阅读长飞行确认电子邮件的代理，构建关键情境（航班号、日期），并通过将其添加到您的日历中采取行动。

第3级：协作多代理系统

在最高层面上，范式发生了彻底的转变。我们不再构建一个单一、全能的“超级代理”，而是转向一个“专家团队”协同工作的模式，这种模式直接反映了人类组织。系统的集体力量在于这种劳动分工。

在这里，代理将其他代理视为工具。想象一个“项目经理”代理接收到一个“任务”： “推出我们新的‘Solaris’耳机。”

项目经理代理不会自己完成所有工作。它通过为团队中的专业代理创建新的任务来行动，这与现实生活中的工作方式类似：

指派给市场研究代理：“分析降噪耳机的竞争对手定价。明天提供一份总结文档。”
指派给营销代理：“根据‘Solaris’产品规格说明书，草拟三个版本的新闻稿。”
指派给网页开发代理：“根据所附的设计草图生成新产品页面的HTML。”

这种协作模式，尽管目前受限于当今大语言模型的推理限制，但代表了从头到尾自动化整个复杂业务工作流程的前沿。

第4级：自我进化的系统

第4级代表了从委托到自主创造和适应的巨大飞跃。在这个级别上，代理系统可以识别自身能力的差距，并动态地创建新的工具或甚至新的代理来填补这些差距。它从使用固定资源转变为积极扩展资源。

以我们的例子为例，负责“Solaris”发布的“项目经理”代理可能会意识到它需要监控社交媒体情绪，但团队中没有这样的工具或代理。

Think（元推理）：“我必须跟踪‘Solaris’的社交媒体热度，但我缺乏这种能力。”
Act（自主创造）：而不是失败，它调用一个高级代理创建工具，并赋予一个新的任务：“创建一个新的代理，用于监控社交媒体中的关键词‘Solaris耳机’，执行情感分析，并报告每日摘要。”
Observe：一个新创建的、专业的情感分析代理被创建、测试，并即时加入团队，准备为原始任务做出贡献。

这种自主性，其中系统可以动态地扩展其自身能力，将代理团队转变为一个真正学习和进化的组织。

4. 核心代理架构：模型、工具和编排

我们知道代理做什么以及它可以如何扩展。但我们实际上如何构建它？从概念到代码的转变在于其三个核心组件的具体架构设计。

4.1 模型：你AI代理的“大脑”

大语言模型是代理的推理核心，其选择是一个关键的建筑决策，它决定了你的代理的认知能力、运营成本和速度。然而，将这个选择视为简单地选择具有最高基准分数的模型是常见的失败路径。代理在生产环境中的成功很少由通用的学术基准决定。

现实世界的成功需要在大语言模型中表现出色的模型：在复杂、多步骤问题中具有优越的推理能力，以及与世界可靠交互的工具使用 $ ^{7} $ 。

为了做得好，首先定义业务问题，然后测试模型与直接映射到该结果的指标。如果代理需要编写代码，就在你的私有代码库上测试它。如果它处理保险索赔，就评估其从特定文档格式中提取信息的能力。然后，将这种分析与成本和延迟的实际情况进行交叉参考。对于特定任务，“最佳”模型是质量、速度和价格的最佳结合点 $ ^{8} $ 。

您可以选择多个模型，一个“专家团队”。您不会用大锤砸核桃。一个健壮的智能体架构可能会使用像Gemini 2.5 Pro这样的前沿模型来进行初始规划和复杂推理的重型工作，但随后会智能地将简单的、高容量的任务——如分类用户意图或总结文本——路由到更快、更经济的模型，如Gemini 2.5 Flash。模型路由可能是自动的或硬编码的，但这是优化性能和成本的关键策略 $ ^{9} $ 。

同样的原则也适用于处理多种数据类型。虽然像Gemini live mode $ ^{10} $ 这样的原生多模态模型为处理图像和音频提供了一个简化的路径，但另一种选择是使用专门的工具，如Cloud Vision API $ ^{11} $ 或Speech-to-Text API $ ^{12} $ 。在这种模式中，世界首先被转换为文本，然后传递给仅语言模型进行推理。这增加了灵活性，并允许使用最佳组件，但也引入了显著的复杂性。

最后，人工智能领域处于不断快速演变的状况。您今天选择的模型将在六个月后过时。一种“设置后即可忘记”的心态是不可持续的。为了适应这种现实，意味着投资于一个敏捷的运营框架——“智能体运营”实践 $ ^{13} $ 。通过一个健壮的CI/CD管道，持续评估新模型与您的关键业务指标，您可以降低风险并加速升级，确保您的智能体始终由最好的大脑驱动，而无需进行完全的架构改造。

4.2 工具：您AI智能体的“双手”

如果模型是智能体的“大脑”，那么工具就是连接其推理与现实的“双手”。它们允许智能体超越其静态训练数据，检索实时信息并在世界中采取行动。一个健壮的工具界面是一个三部分循环：定义工具可以做什么，调用它，并观察结果。

以下是智能体构建者将放入其智能体“双手”中的主要工具类型。欲了解更多详细信息，请参阅本系列中专注于智能体工具的白皮书。

获取信息：在现实中扎根

最基础的工具是能够访问最新信息的能力。检索增强生成（RAG）为智能体提供了一个“图书证”，可以查询外部知识，通常存储在向量数据库或知识图谱中，从内部公司文档到通过Google搜索的网页知识。对于结构化数据，自然语言到SQL（NL2SQL）工具允许智能体查询数据库以回答分析问题，例如，“我们上季度的最畅销产品是什么？”通过在说话之前查找信息——无论是在文档中还是在数据库中——智能体在事实中扎根，大大减少了幻觉。

执行行动：改变世界

当智能体从阅读信息转变为积极做事时，其真正的力量才得以释放。通过将现有的API和代码函数作为工具包装，智能体可以发送电子邮件、安排会议或在ServiceNow中更新客户记录。对于更动态的任务，智能体可以即时编写和执行代码。在一个安全的沙盒中，它可以生成SQL查询或Python脚本来解决复杂问题或执行计算，从而将其从知识渊博的助手转变为自主行动者 $ ^{14} $ 。

这还包括用于人类交互的工具。智能体可以使用人类在回路（HITL）工具暂停其工作流程并请求确认（例如，ask_for_confirmation()）或从用户界面请求特定信息（例如，ask_for_date_input()），确保人在关键决策中发挥作用。HITL可以通过短信文本消息和数据库中的任务来实现。

函数调用：将工具连接到您的智能体

对于Agent能够可靠地执行“函数调用”和使用工具，它需要明确的指令、安全的连接和编排 $^{15}$。像OpenAPI规范这样的长期标准提供了这些功能，为Agent提供了一个结构化的合同，描述了工具的目的、所需参数和预期响应。这个模式让模型每次都能生成正确的函数调用并解释API响应。为了更简单的工具发现和连接，像模型上下文协议（MCP）这样的开放标准因其便利性而变得流行 $^{16}$。此外，一些模型具有原生工具，例如Gemini与原生Google Search，其中函数调用作为LM调用的一个部分发生 $^{17}$。

4.3 编排层

如果模型是Agent的大脑，工具是它的双手，那么编排层就是连接它们的中央神经系统。它是运行“思考、行动、观察”循环的引擎，是控制Agent行为的有限状态机，是开发者精心设计的逻辑得以实现的地方。这一层不仅仅是管道；它是整个Agent交响乐的指挥，决定何时让模型进行推理，哪个工具应该行动，以及如何让行动的结果影响下一步。

核心设计选择

第一个架构决策是确定Agent的自主程度。这个选择存在于一个光谱上。一端是确定性的、可预测的工作流程，将LM作为特定任务的工具——AI的点滴来增强现有流程。另一端是LM处于驾驶座，动态适应、规划和执行任务以实现目标。

一个平行的选择是实现方法。无代码构建器提供速度和易用性，使业务用户能够快速自动化结构化任务和构建简单的Agent。对于更复杂、关键任务系统，如Google的Agent开发工具包（ADK）$^{18}$这样的代码优先框架，提供了工程师所需的深度控制、可定制性和集成能力。

无论采用哪种方法，都需要一个生产级框架。它必须是开放的，允许你插入任何模型或工具以防止供应商锁定。它必须提供精确控制，使LM的非确定性推理受到硬编码的业务规则的约束。最重要的是，框架必须为可观察性而构建。当一个Agent行为异常时，你无法简单地在该模型的“思考”中设置断点。一个健壮的框架会生成详细的跟踪和日志，暴露整个推理轨迹：模型的内部独白、它选择的工具、它生成的参数以及它观察到的结果。

使用领域知识和角色进行指导

在这个框架中，开发者最有力的杠杆是使用领域知识和一个独特的角色来指导Agent。这是通过一个系统提示或一组核心指令来实现的。这不仅仅是一个简单的命令；这是Agent的宪法。

在这里，你告诉它，你是Acme Corp的有帮助的客户支持代理...并提供约束、期望的输出模式、参与规则、特定的语气，以及何时以及为什么应该使用其工具的明确指导。通常，指令中的几个示例场景非常有效。

增强上下文

Agent的“记忆”在运行时编排到LM上下文窗口中。欲深入了解，请参阅本系列中专注于Agent记忆的白皮书。

短期记忆是Agent的活跃“草稿本”，维持当前对话的运行历史。它跟踪从持续循环中来的（动作，观察）对序列，为模型提供决定下一步做什么的即时上下文。这可以实施为诸如状态、工件、会话或线程等抽象。

长期记忆提供跨会话的持久性。在架构上，这几乎总是实现为另一个专门的工具——一个连接到向量数据库或搜索引擎的RAG系统。协调器赋予Agent预取和主动查询其自身历史的能力，使其能够“记住”用户的偏好或几周前类似任务的成果，从而实现真正个性化且连续的体验。$^{19}$

多智能体系统和设计模式

随着任务的复杂性增加，构建一个单一、全能的“超级Agent”变得低效。更有效的解决方案是采用“专家团队”的方法，这反映了人类组织。这是多智能体系统的核心：一个复杂的过程被分割成离散的子任务，每个子任务都分配给一个专门的、专业的AI Agent。这种劳动分工使得每个Agent都更简单、更专注，更容易构建、测试和维护，这对于动态或长期运行的业务流程来说是非常理想的。

架构师可以依赖经过验证的Agent设计模式，尽管Agent的能力以及因此产生的模式正在迅速演变。对于动态或非线性任务，协调器模式是必不可少的。它引入了一个“管理者”Agent，该Agent分析复杂请求，分割主要任务，并将每个子任务智能地路由到适当的专家Agent（如研究员、作家或程序员）。然后协调器汇总每个专家的响应，以制定最终的、全面的答案。

图 3：来自 https://cloud.google.com/architecture/choose-design-pattern-agentic-ai-system 的“迭代优化”模式

对于更线性的工作流程，序列模式更为合适，它就像一条数字流水线，其中一个 Agent 的输出直接成为下一个 Agent 的输入。其他关键模式则侧重于质量和安全性。迭代优化模式创建了一个反馈循环，使用“生成器”Agent 创建内容，并使用“评论家”Agent 评估其是否符合质量标准。对于高风险任务，人机协作（HITL）模式至关重要，它会在 Agent 执行重大操作之前，在工作流程中故意暂停以获得人员的批准。

4.4 Agent 的部署和服务

在构建了本地 Agent 之后，您可能希望将其部署到服务器上，使其能够持续运行，并允许其他人和 Agent 使用它。继续我们的类比，部署和服务将是我们的 Agent 的身体和双腿。Agent 需要多个服务才能有效运行，例如会话历史记录和内存持久化，以及更多。作为 Agent 构建者，您还将负责决定您要记录的内容，以及您为数据隐私、数据居住地和法规合规性采取的安全措施。在将 Agent 部署到生产环境中时，所有这些服务都在范围内。

幸运的是，Agent 构建者可以依赖数十年的应用托管基础设施。毕竟，Agent 是一种新的软件形式，许多相同的原理都适用。构建者可以依赖专为 Agent 定制的、专门的部署选项，如 Vertex AI Agent Engine，它在一个平台上支持运行时和其他一切内容 $^{21}$。对于希望更直接控制其应用堆栈的软件开发人员，或希望在现有的 DevOps 基础设施中部署 Agent 的，任何 Agent 和大多数 Agent 服务都可以添加到 Docker 容器中，并部署到行业标准运行时，如 Cloud Run 或 GKE $^{22}$。

图 4：Vertex AI Agent 构建器，来源：https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/overview

如果您不是软件开发者或 DevOps 专家，部署您的第一个 Agent 的过程可能会让人感到畏惧。许多 Agent 框架通过部署命令或专门的平台来简化 Agent 的部署，这些工具应该用于早期的探索和入门。要将 Agent 部署到安全且适合生产的环境中，通常需要投入更多的时间和采用最佳实践，包括为您的 Agent 实施持续集成/持续部署（CI/CD）和自动化测试 $^{23}$。

4.5 Agent 运维：对不可预测性的结构化方法

当您构建第一个 Agent 时，您将手动测试其行为，反复进行。当您添加一个功能时，它是否工作正常？当您修复一个错误时，是否又引发了其他问题？测试对于软件开发来说是正常的，但在生成式 AI 中，测试的方式有所不同。

从传统的、确定性的软件过渡到随机的、代理式系统需要一种新的运营理念。传统的软件单元测试可以简单地断言输出 == 预期；但当代理的响应是设计上的概率性时，这就不适用了。此外，由于语言本身的复杂性，通常需要大语言模型（LM）来评估“质量”——即代理的响应是否完成了它应该完成的所有事情，没有完成不应该做的事情，并且以适当的语气表达。

图5：DevOps、MLOps和GenAIOps的运营领域之间的关系，来源：https://medium.com/@sokratis.kartakis/genai-in-production-mlops-or-genaiops-25691c9becd0

Agent Ops 是一种严谨、结构化的方法，用于管理这一新现实。它是 DevOps 和 MLOps 的自然演变，针对构建、部署和管理 AI 代理的独特挑战进行了定制，将不可预测性从一项负债转变为一种可管理、可衡量且可靠的特性。$^{24}$ 若想深入了解，请参阅本系列中专注于代理质量的白皮书。

关注关键指标：如同A/B实验般度量成功

在改进您的代理之前，您必须定义在您的业务环境中“更好”的含义。将您的可观察性策略构建成一个 A/B 测试，并问自己：哪些关键绩效指标（KPIs）可以证明代理正在创造价值？这些指标应超越技术正确性，并衡量实际影响：目标完成率、用户满意度评分、任务延迟、每次交互的运营成本，以及——最重要的是——对业务目标（如收入、转化率或客户保留率）的影响。这种自上而下的视角将指导您接下来的测试，让您走上以指标驱动的开发之路，并帮助您计算投资回报率。

质量而非通过/失败：使用大语言模型作为评判标准

商业指标并不能告诉你代理是否表现正确。由于简单的通过/失败判断是不可能的，我们转向使用“大语言模型作为评判标准”来评估质量。这涉及到使用一个强大的模型来评估代理的输出与预定义的评分标准：它是否给出了正确的答案？回答是否基于事实？它是否遵循了指示？这种针对黄金数据集的自动化评估，为质量提供了一个一致的衡量标准。

创建评估数据集——包括理想（或“黄金”）问题和正确答案——可能是一个繁琐的过程。为了构建这些数据集，您应该从现有的生产或开发与代理的交互中抽取场景样本。数据集必须涵盖您预期用户将参与的全部用例，以及一些意外的用例。虽然对评估的投资很快就能得到回报，但评估结果在被视为有效之前，应始终由领域专家进行审查。越来越地，这些评估的编辑和维护成为产品经理的关键责任，并得到领域专家的支持。

以指标驱动的开发：部署的Go/No-Go决策

一旦您自动化了数十个评估场景并建立了可信的质量评分，您就可以自信地测试您开发中的代理。这个过程很简单：将新版本与整个评估数据集运行，并直接比较其评分与现有生产版本。这个稳健的系统消除了猜测，确保您对每次部署都充满信心。虽然自动化评估至关重要，但不要忘记其他重要因素，如延迟、成本和任务成功率。为了最大程度地保证安全，使用 A/B 部署缓慢推出新版本，并将这些现实世界的生产指标与您的模拟评分进行比较。

使用OpenTelemetry跟踪调试：回答“为什么？”

当您的指标下降或用户报告了一个错误时，您需要理解“为什么”。OpenTelemetry跟踪是对代理整个执行路径（轨迹）的高保真、逐步记录，使您能够调试代理的步骤。$ ^{25} $ 使用跟踪，您可以查看发送给模型的精确提示，模型内部推理（如果可用），它选择的特定工具，为该工具生成的精确参数，以及作为观察返回的原始数据。跟踪在第一次查看时可能很复杂，但它们提供了诊断和修复任何问题根本原因所需的详细信息。重要的跟踪细节可以转换为指标，但审查跟踪主要是为了调试，而不是

概述性能。跟踪数据可以无缝收集在Google Cloud Trace等平台上，这些平台可视化并搜索大量跟踪，简化根本原因分析。

重视人类反馈：指导您的自动化

人类反馈不是需要处理的烦恼，而是您改善代理最有价值和数据丰富的资源。当用户提交错误报告或点击“不喜欢”按钮时，他们给您一份礼物：一个新出现的、真实世界的边缘情况，您的自动化评估场景遗漏了。收集和汇总这些数据至关重要；当您看到大量类似报告或指标下降时，您必须将这些事件与您的分析平台联系起来，以生成见解并触发操作问题的警报。有效的代理操作流程通过捕获此反馈、复制问题并将特定场景转换为评估数据集中的新、永久性测试用例来“闭合循环”。这不仅确保您修复了错误，而且还使系统免受该类错误再次发生的侵害。

4.6 代理互操作性

一旦您构建了高质量的代理，您希望能够将它们与用户和其他代理互连。在我们的身体部位类比中，这将相当于代理的面部。连接到代理与连接代理与数据和API之间存在差异；代理不是工具$ ^{26} $ 。让我们假设您已经将工具连接到您的代理中，现在让我们考虑如何将您的代理引入更广泛的生态系统。

代理和人类

代理与人类最常见的交互形式是通过用户界面。在其最简单的形式中，这是一个聊天机器人，用户输入请求，代理作为后端服务处理它，并返回一段文本。更高级的代理可以提供结构化数据，如JSON，以支持丰富、动态的前端体验。闭环人类（HITL）交互模式包括意图细化、目标扩展、确认和澄清请求。

计算机使用是一种工具类别，其中LM控制用户界面，通常伴随着人类交互和监督。一个启用了计算机使用的代理可以决定下一步的最佳行动是导航到新页面、突出显示特定按钮或预先填充包含相关信息的表单$ ^{27} $ 。

不是代理代表用户使用界面，LM可以改变UI以满足当前的需求。这可以通过控制UI的工具（MCP UI）$ ^{28} $ 、专门的消息系统（AG UI）$ ^{29} $ ，甚至生成定制界面（A2UI）$ ^{30} $ 来完成。

当然，人类交互不仅限于屏幕和键盘。高级代理正在打破文本障碍，进入实时、多模态通信，"实时模式"创建了一种更自然、更类似人类的连接。Gemini Live API $ ^{31} $ 等技术实现了双向流，使用户能够像在自然对话中一样与代理交谈并打断它。

这种能力从根本上改变了Agent与人类协作的本质。通过访问设备的摄像头和麦克风，Agent可以看到用户所看到的，听到用户所说的话，并以模拟人类对话延迟的生成语音进行响应。

这为使用文本无法实现的大量用例打开了大门，从技术人员在维修设备时获得免提指导，到购物者获得实时风格建议。这使得Agent成为一个更加直观和易于访问的合作伙伴。

Agent与Agent

正如Agent必须与人类连接一样，它们也必须相互连接。随着企业对AI的使用规模扩大，不同的团队将构建不同的专用Agent。如果没有一个共同的标准，连接它们将需要构建一个错综复杂、脆弱的、定制的API集成网络，这是难以维护的。核心挑战有两个方面：发现（我的Agent如何找到其他Agent并了解它们能做什么？）和通信（我们如何确保它们使用相同的语言？）。

Agent2Agent（A2A）协议是为了解决这个问题而设计的开放标准。它作为Agent经济的通用握手。A2A允许任何Agent发布一个数字“名片”，称为Agent Card。这个简单的JSON文件宣传了Agent的能力、其网络端点和与之交互所需的身份验证凭证。这使得发现变得简单和标准化。与专注于解决交易请求的MCP不同，Agent 2 Agent通信通常用于额外的解决问题。

一旦被发现，Agent使用面向任务的架构进行通信。而不是简单的请求-响应，交互被框架为异步的“任务”。客户端Agent向服务器Agent发送任务请求，服务器Agent可以在长时间运行连接上处理问题时提供流式更新。这种强大、标准化的通信协议是最后一块拼图，使得协作的、第三级的多Agent系统成为自动化的前沿。A2A将一组孤立的Agent转换为一个真正的、可互操作的生态系统。

Agent与货币

随着AI Agent为我们执行更多任务，其中一些任务涉及购买或销售、谈判或促进交易。当前的互联网是为人类点击“购买”而构建的，责任在人类身上。如果自主Agent点击“购买”，就会引发信任危机——如果出了问题，责任在谁？这些都是授权、真实性和问责的复杂问题。为了解锁真正的Agent经济，我们需要新的标准，允许Agent代表用户安全、可靠地进行交易。

这个新兴领域还远未建立，但有两个关键协议正在铺平道路。Agent Payments Protocol（AP2）是一个开放协议，旨在成为Agent商业的终极语言。它通过引入加密签名的数字“授权”来扩展A2A等协议。这些作为用户意图的可验证证明，为每次交易创建了一个不可否认的审计轨迹。这允许Agent根据用户的授权在全球范围内安全地浏览、谈判和交易。与之相辅相成的是x402，这是一个开放互联网支付协议，它使用标准的HTTP 402“支付所需”状态代码。它实现了无摩擦的机器对机器微支付，允许Agent以按使用付费的方式支付API访问或数字内容，而不需要复杂的账户或订阅。这些协议共同构建了Agent网络的信任基础层。

4.8 保护单个Agent：信任权衡

当您创建第一个AI代理时，您立即面临一个基本矛盾：效用与安全的权衡。为了使代理有用，您必须赋予它权力——自主做出决策和执行发送电子邮件或查询数据库等行动的工具。然而，您赋予的每一盎司权力都引入了相应的风险。主要的安全担忧是越权行为——意外或有害的行为——以及敏感数据泄露。您希望给代理一条足够长的缰绳来完成其工作，但又足够短，以防止它撞上交通，尤其是当这种交通涉及不可逆的行动或您公司的私有数据时。$^{32}$

为了管理这一点，您不能仅仅依赖AI模型的判断，因为它可能被像提示注入$^{33}$这样的技术操纵。相反，最佳实践是混合的深度防御方法$^{34}$。第一层由传统的、确定性的护栏组成——一组硬编码的规则，作为模型推理之外的安全瓶颈。这可能是一个阻止任何超过100美元的购买或要求代理在与外部API交互之前进行明确用户确认的策略引擎。这一层为代理的权力提供了可预测的、可审计的硬性限制。

第二层利用基于推理的防御，使用AI来帮助保护AI。这包括训练模型以更具抗攻击性（对抗性训练）并采用更小、更专业的“护栏模型”，这些模型就像安全分析师一样行动。这些模型可以在执行之前检查代理提出的计划，标记出可能具有风险或违反政策的步骤以供审查。这种混合模型，结合了代码的刚性确定性和AI的情境意识，为单个代理甚至提供了强大的安全态势，确保其权力始终与其目的保持一致。

代理身份：一类新的主体

在传统的安全模型中，有使用OAuth或SSO的人类用户，以及使用IAM或服务账户的服务。代理增加了一个第三类主体。代理不仅仅是一段代码；它是一个自主行动者，一种需要其自身可验证身份的新类型的主体。正如员工会被发放身份证牌一样，平台上的每个代理都必须发放一个安全、可验证的“数字护照”。这种代理身份与调用它的用户和构建它的开发者的身份不同。这是我们在企业中处理身份和访问管理（IAM）的基本转变。

确保每个身份都得到验证并为所有身份提供访问控制是代理安全的基础。一旦代理拥有加密可验证的身份（通常使用SPIFFE$^{35}$等标准），它就可以被授予自己的特定、最小权限。SalesAgent被授予对CRM的读写访问权限，而HRonboardingAgent被明确拒绝。这种细粒度的控制至关重要。它确保即使单个代理被入侵或行为异常，潜在的破坏范围也会得到控制。如果没有代理身份结构，代理就无法代表具有有限授权的人类工作。

主要实体	身份验证/验证	备注
用户	通过OAuth或SSO进行身份验证	具有完全自主权和对其行为负责的人类参与者
Agent（新类别原则）	通过SPIFFE进行验证	Agent拥有委托权限，代表用户执行操作
服务帐户	集成到IAM	应用程序和容器，完全确定，不对操作负责

表1：不同类别参与者的身份验证非详尽示例

限制访问的策略

策略是一种授权（AuthZ）形式，与身份验证（AuthN）不同。通常，策略限制主体的能力；例如，“市场营销部门用户只能访问这些27个API端点，不能执行DELETE命令。”随着我们开发Agent，我们需要将权限应用于Agent、其工具、其他内部Agent、可以共享的上下文以及远程Agent。可以这样思考：如果你将所有API、数据、工具和Agent添加到你的系统中，那么你必须限制对这些仅用于完成工作的能力子集的访问。这是推荐的方法：在保持上下文相关性的同时应用最小权限原则。$ ^{36} $

保护ADK Agent

在确立了身份和策略的核心原则之后，使用Agent开发工具包（ADK）构建的Agent的安全保护就变成了通过代码和配置应用这些概念的实际练习$ ^{37} $。

如上所述，这个过程需要明确定义身份：用户帐户（例如OAuth）、服务帐户（用于运行代码）、Agent身份（用于使用委托权限）。一旦处理了身份验证，下一层防御就是建立策略以限制对服务的访问。这通常在API治理层完成，同时支持MCP和A2A服务。

下一层是在你的工具、模型和子Agent中构建护栏以执行策略。这确保了无论LM如何推理或恶意提示可能提出什么，工具自身的逻辑将拒绝执行不安全或违反策略的操作。这种方法提供了一个可预测和可审计的安全基线，将抽象的安全策略转化为具体、可靠的代码$ ^{38} $。

为了实现更动态的安全，能够适应Agent的运行时行为，ADK提供了回调和插件。before_tool_callback允许你在工具调用运行之前检查其参数，通过验证它们与Agent当前状态的一致性来防止不匹配的操作。为了构建更可重用的策略，你可以构建插件。一个常见的模式是“Gemini作为法官”$ ^{39} $，它使用快速、低成本的模型如Gemini Flash-Lite或你自己的微调Gemma模型，实时筛选用户输入和Agent输出中的提示注入或有害内容。

对于偏好完全托管、企业级解决方案以进行这些动态检查的组织，Model Armor可以作为可选服务进行集成。Model Armor充当一个专门的安全层，对提示和响应进行广泛的威胁筛查，包括提示注入、越狱尝试、敏感数据（PII）泄露和恶意URL $ ^{40} $ 。通过将这些复杂的安全任务委托给专门的服务，开发者可以确保一致、强大的保护，而无需自行构建和维护这些防护措施。ADK中的这种混合方法——结合强大的身份验证、确定性的工具逻辑、动态的AI辅助防护措施以及可选的托管服务如Model Armor——是构建一个既强大又值得信赖的单个Agent的方法。

图6：安全和Agent，来源：https://saif.google/focus-on-agents

4.8 从单个Agent扩展到企业车队

单个AI Agent的生产成功是一项壮举。将其扩展到数百个Agent则是对架构的挑战。如果你正在构建一两个Agent，你的主要关注点是安全问题。如果你正在构建许多Agent，你必须设计系统来处理更多内容。就像API蔓延一样，当Agent和工具在一个组织中扩散，

它们会创建一个新的、复杂的交互网络、数据流和潜在的安全漏洞。管理这种复杂性需要一个更高层次的治理层，将所有身份和策略整合到一个中央控制平面中。

安全和隐私：加固Agent前沿

即使只有一个Agent运行，企业级平台也必须解决生成式AI固有的独特安全和隐私挑战。Agent本身成为了一个新的攻击向量。恶意行为者可能会尝试注入提示以劫持Agent的指令，或者数据中毒以破坏其用于训练或RAG的信息。此外，一个约束不当的Agent可能会无意中泄露敏感的客户数据或专有信息。

一个强大的平台提供了一种多层次防御策略来减轻这些风险。它从数据开始，确保企业的专有信息永远不会用于训练基础模型，并通过如VPC服务控制等控制措施得到保护。它需要输入和输出过滤，就像防火墙一样对提示和响应进行操作。最后，平台必须提供合同保护，如对训练数据和生成输出的知识产权赔偿，为企业提供部署Agent所需的法律和技术信心。

Agent治理：控制平面而非蔓延

随着Agent及其工具在一个组织中扩散，它们创建了一个新的、复杂的交互网络和潜在漏洞，这通常被称为“Agent蔓延”。管理这种复杂性需要超越保护单个Agent，转向实施更高层次的架构方法：一个作为所有Agent活动控制平面的中央网关。

想象一个熙熙攘攘的大都市，有成千上万的自动驾驶汽车——用户、Agent和工具——都在有目的地移动。如果没有交通灯、车牌和中央控制系统，将会陷入混乱。网关方法创建了这样的控制系统，为所有Agent流量建立了强制性的入口点，包括用户到Agent的提示或UI交互、Agent到工具的调用（通过MCP）、Agent到Agent的合作（通过A2A）以及直接到LM的推理请求。通过位于这个关键交汇点，组织可以检查、路由、监控和管理每一次交互。

这个控制平面有两个主要、相互关联的功能：

运行时策略执行：它作为实施安全的架构瓶颈。它处理身份验证（“我是否知道这个行为者是谁？”）和授权（“他们是否有权这样做？”）。集中执行提供了“单点玻璃”的可观察性，为每一笔交易创建共同的日志、指标和跟踪。这把分散的Agent和工作流程的混乱转变为一个透明且可审计的系统。
集中式治理：为了有效执行政策，网关需要一个可信的来源。这由一个中心注册表提供——一个针对Agent和工具的企业应用商店。此注册表允许开发者发现和重用现有资产，防止重复工作，同时为管理员提供一个完整的清单。更重要的是，它为Agent和工具提供了一个正式的生命周期，允许在发布前进行安全审查、版本控制和创建细粒度的策略，以规定哪些业务单元可以访问哪些Agent。通过结合运行时网关和集中式治理注册表，组织将混乱蔓延的风险转化为一个可管理、安全和高效的生态系统。

4.9 成本与可靠性：基础设施基础

最终，企业级Agent必须既可靠又具有成本效益。一个经常失败或提供缓慢结果的Agent具有负的投资回报率。相反，成本过高的Agent无法扩展以满足业务需求。底层基础设施必须设计用于管理这种权衡，同时确保安全和符合监管以及数据主权要求。在某些情况下，您需要的特性是零扩展，当您对特定Agent或子功能的流量不规则时。对于关键任务、对延迟敏感的工作负载，平台必须提供专用、保证的容量，例如LM服务的预留吞吐量$^{41}$或Cloud Run等运行时的99.9%服务水平协议（SLA）。这提供了可预测的性能，确保在重负载下，您最重要的Agent始终能够响应。通过提供这一系列基础设施选项，并结合对成本和性能的全面监控，您为将AI Agent从有潜力的创新扩展为企业核心、可靠的组件奠定了最终、必要的基础。

4.10 Agent如何演进和学习

部署在现实世界中的Agent在动态环境中运行，其中政策、技术和数据格式不断变化。如果没有适应能力，Agent的性能会随着时间的推移而下降——这个过程通常被称为“老化”——导致效用和信任的丧失。手动更新大量Agent以跟上这些变化既不经济又缓慢。一个更可扩展的解决方案是设计能够自主学习和演化的Agent，通过最小的工程努力在工作岗位上提高其质量。$^{43}$

Agent如何学习和自我演进

与人类类似，Agent通过经验和外部信号进行学习。这个过程由以下几种信息来源驱动：

运行时经验：Agent从运行时工件中学习，例如会话日志、跟踪和内存，这些工件捕获了成功、失败、工具交互和决策轨迹。关键的是，这包括人机交互（HITL）反馈，它提供了权威的纠正和指导。
外部信号：学习还受到新外部文档的驱动，例如更新的企业政策、公共监管指南或其他Agent的批评。

然后，这些信息被用来优化Agent的未来行为。而不是简单地总结过去的交互，先进的系统创建可推广的工件来指导未来的任务。最成功的适应技术分为两大类：

增强上下文工程：系统持续优化其提示、少样本示例和从内存中检索的信息。通过优化为每个任务提供的LM上下文，它增加了成功的可能性。
工具优化与创建：Agent的推理能力可以识别其能力上的差距，并采取行动来填补这些差距。这可能包括获取新的工具、即时创建新的工具（例如，Python脚本）或修改现有工具（例如，更新API架构）。

除此之外，还有如动态重新配置多Agent设计模式或使用基于人类反馈的强化学习（RLHF）等额外的优化技术，这些也是当前研究的热点领域。

示例：学习新的合规指南考虑一个在高度监管的行业（如金融或生命科学）中运行的企业代理。其任务是生成必须符合隐私和监管规则的报告（例如，GDPR）。这可以通过多Agent工作流程来实现：

查询Agent根据用户请求检索原始数据。
报告Agent将此数据综合成草稿报告。
批评Agent，拥有已知的合规指南，审查报告。如果遇到模糊不清或需要最终批准，则升级至人类领域专家。
学习Agent观察整个交互过程，特别关注来自人类专家的纠正反馈。然后，它将这种反馈归纳为新的、可重用的指南（例如，更新批评Agent的规则或改进报告Agent的上下文）。

图7：符合指南的多智能体工作流程示例

例如，如果一位人类专家标记指出某些家庭统计数据必须进行匿名化处理，学习代理（Learning Agent）会记录这一更正。下次生成类似报告时，评论代理（Critiquing Agent）将自动应用这一新规则，减少对人工干预的需求。这种评论、人工反馈和泛化的循环使系统能够自主适应不断变化的合规要求 $ ^{44} $ 。

模拟与智能体健身房——下一个前沿

我们提出的模式可以归类为内联学习，其中智能体需要利用它们设计和工程中所使用的资源和设计模式进行学习。目前，正在研究更高级的方法，其中有一个专门的平台被设计用来在离线过程中通过高级工具和能力优化多智能体系统，这些工具和能力不属于多智能体运行时环境的一部分。此类智能体健身房（Agent Gym）$ ^{45} $ 的关键属性包括：

它不在执行路径上。它是一个独立的离线平台，因此可以借助任何大语言模型（LM model）、离线工具、云应用等。
它提供了一个模拟环境，智能体可以在其中“锻炼”新数据并学习。这个模拟环境非常适合进行“试错”和探索多种优化路径。
它可以调用高级合成数据生成器，引导模拟尽可能真实，并对智能体进行压力测试（这可以包括高级技术，如红队攻击、动态评估和一系列评论代理）。
优化工具的库不是固定的，它可以采用新的工具（通过如MCP或A2A等开放协议，或在更高级的设置中——学习新概念并围绕它们构建工具）。
最后，即使是智能体健身房这样的结构，也可能无法克服某些边缘情况（由于企业中“部落知识”的众所周知问题）。在这些情况下，我们看到智能体健身房能够连接到领域专家的人类网络，并与他们协商以确定正确的结果集，以指导下一轮优化。

5. 高级智能体的示例

谷歌联合科学家

联合科学家（Co-Scientist）是一种高级人工智能代理，旨在作为虚拟研究合作伙伴，通过系统地探索复杂问题空间来加速科学发现。它使研究人员能够定义一个目标，将代理建立在指定的公共和专有知识源上，然后生成和评估一系列新颖的假设。为了能够实现这一点，联合科学家（Co-Scientist）会孵化一个完整的生态系统，其中的代理相互协作。

图8：AI协同科学家设计系统

将这个系统比作一个研究项目管理员。AI首先确定一个广泛的研究目标，并制定详细的计划。随后，“主管”Agent扮演管理者的角色，将任务委派给一支由专业Agent组成的团队，并分配如计算能力等资源。这种结构确保了项目可以轻松扩展，并且随着团队向最终目标迈进，他们的方法也会得到改进。

图9：协同科学家多智能体工作流程

各种智能体工作数小时，甚至数天，不断改进生成的假设，运行循环和元循环，不仅提高了生成的想法，还改进了我们判断和创造新想法的方式。

AlphaEvolve智能体

另一个高级智能体系统的例子是AlphaEvolve，这是一个AI智能体，它发现并优化了数学和计算机科学中复杂问题的算法。

AlphaEvolve通过结合我们Gemini语言模型的创造性代码生成和自动化评估系统来工作。它使用进化过程：AI生成潜在解决方案，评估者对其进行评分，最有希望的想法被用作下一代代码的灵感来源。

这种方法已经导致了重大的突破，包括：

提高谷歌数据中心、芯片设计和AI训练的效率。
发现更快的矩阵乘法算法。
找到解决开放数学问题的新的解决方案。

AlphaEvolve在验证解决方案质量远比最初找到它更容易的问题上表现出色。

图10：Alpha Evolve设计系统

AlphaEvolve旨在实现人与AI之间深度、迭代的合作伙伴关系。这种协作主要通过以下两种方式实现：

透明解决方案：AI以人类可读的代码形式生成解决方案。这种透明性使用户能够理解逻辑、获得洞察、信任结果，并直接修改代码以满足其需求。
专家指导：人类的专业知识对于定义问题至关重要。用户通过细化评估指标和引导探索来指导AI，这有助于防止系统利用问题定义中的意外漏洞。这种交互式循环确保最终解决方案既强大又实用。代理的结果是代码的持续改进，不断优化人类指定的指标。

图11：算法演变

6. 结论

生成式AI代理标志着一次关键性的演变，将人工智能从被动的内容创作工具转变为主动、自主的问题解决伙伴。本文档提供了一个正式的框架，用于理解和构建这些系统，超越了原型，建立了一个可靠、适用于生产的架构。

我们将代理分解为其三个基本组成部分：推理模型（“大脑”）、可执行工具（“双手”）和治理编排层（“神经系统”）。这些部分的无缝集成，在持续的“思考、行动、观察”循环中运行，才能释放代理的真正潜力。通过将代理系统分类——从第1级连接问题解决者到第3级协作多代理系统——架构师和产品领导者现在可以战略性地界定他们的抱负，以匹配手头任务的复杂性。

中央的挑战和机遇在于新的开发者范式。我们不再是简单地定义明确逻辑的“砖匠”；我们是“建筑师”和“导演”，必须引导、约束和调试一个自主实体。使大语言模型如此强大的灵活性也是它们不可靠的来源。因此，成功不仅仅在于最初的提示，而在于应用于整个系统的工程严谨性：在健壮的工具契约、弹性错误处理、复杂的环境管理和全面评估。

这里概述的原则和架构模式构成了一个基础蓝图。它们是导航这个新软件前沿的指南针，使我们能够构建的不仅仅是“工作流程自动化”，而是真正协作、能干和适应性强的新团队成员。随着这项技术的成熟，这种纪律性的架构方法将成为利用代理AI全部力量的决定性因素。

7. 参考文献

Julia Wiesinger, Patrick Marlow等. 2024 “代理”。可在：https://www.kaggle.com/whitepaper-agents.
Antonio Gulli, Lavi Nigam等. 2025 “代理伴侣”。可在：https://www.kaggle.com/whitepaper-agent-companion.
Shunyu Yao, Y. 等，2022，《ReAct：在语言模型中协同推理和行动》。可在：https://arxiv.org/abs/2210.03629.
Wei, J., Wang, X. 等，2023，《思维链提示激发大语言模型的推理》。可在：https://arxiv.org/pdf/2201.11903.pdf.
Shunyu Yao, Y. 等，2022，《ReAct：在语言模型中协同推理和行动》。可在：https://arxiv.org/abs/2210.03629.
https://www.amazon.com/Agentic-Design-Patterns-Hands-Intelligent/dp/3032014018
Shunyu Yao, 等，2024，《τ-bench：现实世界领域中工具-代理-用户交互的基准》。可在：https://arxiv.org/abs/2406.12045.
https://artificialanalysis.ai/guide
https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/vertex-ai-model-optimizer
https://gemini.google/overview/gemini-live/
https://cloud.google.com/vision?e=48754805&hl=en
https://cloud.google.com/speech-to-text?e=48754805&hl=en
https://medium.com/google-cloud/genaiops-operationalize-generative-ai-a-practical-guide-d5bedaa59d78
https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/code-execution/overview
https://ai.google.dev/gemini-api/docs/function-calling
https://github.com/modelcontextprotocol/
https://ai.google.dev/gemini-api/docs/google-search
https://google.github.io/adk-docs/
https://google.github.io/adk-docs/sessions/memory/
https://cloud.google.com/architecture/choose-design-pattern-agentic-ai-system
https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/overview
Kubernetes Engine 简介
Google Cloud Platform 代理启动包
Sokratis Kartakis, 2024, 《生产环境中的 GenAI：MLOps 还是 GenAI Ops？》。可在以下链接查看：Medium。
Guangya Liu, Sujay Solomon, 2025 年 3 月 "AI 代理可观察性 - 发展中的标准和最佳实践"。可在以下链接查看：OpenTelemetry 博客。
Google Dev 讨论区 - 代理不是工具
Damien Masson 等人，2024 年，《DirectGPT：与大型语言模型交互的直接操作界面》。可在以下链接查看：arXiv。
MCP UI 是一种通过 MCP 工具控制 UI 的系统。MCP UI 网站。
AG UI 是一种通过事件传递和可选共享状态控制 UI 的协议。AG UI 网站。
A2UI 是一种通过结构化输出和 A2A 消息传递生成 UI 的协议。A2UI GitHub 仓库。
Vertex AI 生成式 AI 文档 - Gemini 模型 2.5 Flash Live API。
Focus on Agents。
Prompt Injection 系列文章。
qweb-research2023-media 上的 pubtools。
SPIFFE。
OpenReview 网站上的论文。
Google ADK 文档 - 安全。
Google GitHub 仓库 - ADK 文档 - 回调设计模式与最佳实践
TKTK
Google Cloud Security Command Center - Model Armor 概述
Vertex AI 生成式 AI 文档 - 预配吞吐量概述
Google Cloud Run 服务水平协议
Self-Evolving Agents GitHub 仓库
Juraj Gottweis 等人，2025 年，《利用 AI 合作者加速科学突破》。可在以下链接查看：Google Research 博客。
Deepak Nathani 等人，2025 年，《MLGym：推进 AI 研究代理的新框架和基准》。可在以下链接查看：arXiv。

本章结构