AI Agent 入门指南

原文：Introduction to Agents (Google, 2025年11月)

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

目录

• 从预测式AI到自主Agent
• AI Agent简介
• Agent问题解决流程
• Agent系统分类
• 核心Agent架构：模型、工具和编排
• 多Agent系统和设计模式
• Agent部署和服务
• Agent运维
• Agent互操作性
• 安全性
• Agent如何演化和学习
• 高级Agent示例
• 结论

致谢

内容贡献者

• Enrique Chan
• Mike Clark
• Derek Egan
• Anant Nawalgaria
• Kanchana Patlolla
• Julia Wiesinger

策划和编辑

• Anant Nawalgaria
• Kanchana Patlolla

设计

• Michael Lanning

从预测式AI到自主Agent

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

这个新前沿是围绕AI Agent构建的。Agent不仅仅是静态工作流中的AI模型；它是一个完整的应用程序，能够制定计划并采取行动来实现目标。它结合了语言模型（LM）的推理能力和实际行动能力，使Agent能够处理单个模型无法完成的复杂多步骤任务。关键能力在于Agent可以自主工作，在无需人类每一步指导的情况下，找出达成目标所需的下一步行动。

Agent是语言模型的自然演进，在软件中变得有用。

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

• 核心解剖：将Agent解构为三个基本组件：推理模型、可操作的工具和管理编排层。
• 能力分类：将Agent从简单的连接式问题解决器分类到复杂的协作式多Agent系统。
• 架构设计：深入探讨每个组件的实际设计考虑，从模型选择到工具实现。
• 生产构建：建立评估、调试、保护和扩展Agent系统所需的Agent运维规范，从单个实例到具有企业治理的Agent集群。

基于之前的Agent白皮书和Agent伴侣，本指南提供了成功构建、部署和管理这一代能够推理、行动和观察以完成目标的智能应用所需的基础概念和战略框架。

AI Agent简介

关于人类与AI互动的词汇说明

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

最简单地说，AI Agent可以定义为模型、工具、编排层和运行时服务的组合，它使用语言模型在循环中完成目标。这四个元素构成了任何自主系统的基本架构。

1. 模型（“大脑”）

核心语言模型（LM）或基础模型，作为Agent的中央推理引擎来处理信息、评估选项和做出决策。模型类型（通用、微调或多模态）决定了Agent的认知能力。Agent系统是LM输入上下文窗口的终极策展者。

2. 工具（“双手”）

这些机制将Agent的推理连接到外部世界，使其能够执行文本生成之外的操作。它们包括API扩展、代码函数和数据存储（如数据库或向量存储），用于访问实时的、事实性的信息。Agent系统允许LM规划使用哪些工具，执行工具，并将工具结果放入下一次LM调用的输入上下文窗口中。

3. 编排层（“神经系统”）

管理Agent操作循环的治理流程。它处理规划、记忆（状态）和推理策略执行。这一层使用提示框架和推理技术（如思维链[Chain-of-Thought]或ReAct）将复杂目标分解为步骤，并决定何时思考与使用工具。这一层还负责赋予Agent”记忆”的能力。

4. 部署（“身体和腿”）

虽然在笔记本电脑上构建Agent对原型设计很有效，但生产部署才能使其成为可靠且可访问的服务。这涉及将Agent托管在安全、可扩展的服务器上，并与监控、日志记录和管理的基本生产服务集成。部署后，Agent可以通过图形界面被用户访问，或通过Agent到Agent（A2A）API被其他Agent以编程方式访问。

归根结底，构建生成式AI Agent是开发解决方案以完成任务的新方式。传统开发者像”砌砖工”一样，精确定义每个逻辑步骤。相比之下，Agent开发者更像是一位导演。你不是为每个动作编写显式代码，而是设置场景（指导说明和提示），选择演员阵容（工具和API），并提供必要的上下文（数据）。主要任务是引导这个自主的”演员”提供预期的表现。

你很快会发现，LM最大的优势——其令人难以置信的灵活性——也是你最大的麻烦。大型语言模型能做任何事情的能力，使得很难强制它可靠且完美地做某一件特定的事情。我们过去称为”提示工程”，现在称为”上下文工程”的东西，用于引导LM生成所需的输出。对于对LM的任何单次调用，我们输入指令、事实、可调用的工具、示例、会话历史、用户配置文件等——用恰到好处的信息填充上下文窗口以获得我们需要的输出。Agent是管理LM输入以完成工作的软件。

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

当Agent被精确配置了清晰的指令、可靠的工具、作为记忆的集成上下文、出色的用户界面、规划和解决问题的能力以及通用世界知识时，它就超越了”工作流自动化”的概念。它开始作为一个协作实体发挥作用：一个高效、独特适应性强且能力卓越的团队新成员。

本质上，Agent是一个致力于上下文窗口策展艺术的系统。

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

Agent问题解决流程

我们已将AI Agent定义为一个完整的、目标导向的应用程序，它集成了推理模型、可操作的工具和管理编排层。简短版本是”LM在循环中使用工具完成目标”。

但这个系统实际上是如何工作的？Agent从接收请求到交付结果的整个过程中做了什么？

其核心是，Agent在一个持续的循环过程中运作以实现其目标。虽然这个循环可能变得非常复杂，但可以分解为五个基本步骤（详见《Agent系统设计》一书）：

1. 获取任务（Get the Mission）

流程由一个具体的高级目标启动。这个任务由用户提供（例如，“为即将到来的会议组织我团队的旅行”）或由自动触发器提供（例如，“有一张新的高优先级客户工单到达”）。

2. 扫描场景（Scan the Scene）

Agent感知其环境以收集上下文。这涉及编排层访问其可用资源：“用户的请求说了什么？”，“我的长期记忆中有什么信息？我之前试过做这个任务吗？用户上周给我指导了吗？”，“我可以从我的工具访问什么，比如日历、数据库或API？“

3. 思考（Think It Through）

这是Agent的核心”思考”循环，由推理模型驱动。Agent分析任务（步骤1）与场景（步骤2），并制定计划。这不是单一的想法，而是通常是一连串推理：“要预订旅行，我首先需要知道团队中有谁。我将使用 get_team_roster 工具。然后我需要通过 calendar_api 检查他们的可用性。“

4. 采取行动（Take Action）

编排层执行计划的第一个具体步骤。它选择并调用适当的工具——调用API、运行代码函数或查询数据库。这是Agent对其内部推理之外的世界采取行动。

5. 观察和迭代（Observe and Iterate）

Agent观察其行动的结果。get_team_roster 工具返回五个名字的列表。这个新信息被添加到Agent的上下文或”记忆”中。然后循环重复，返回到步骤3：“现在我有了名单，下一步是检查这五个人的日历。我将使用 calendar_api。”

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

实际示例：客户支持Agent

让我们看一个客户支持Agent如何在这个5步循环中运作的真实示例：

想象用户问：“我的订单 #12345 在哪里？”

Agent不会立即行动，而是首先进入其”思考”阶段来制定完整策略。它推理：

“用户想要配送状态。为了提供完整的答案，我需要一个多步骤计划：

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

有了这个多步骤计划后，Agent开始执行。

在第一个”行动”阶段，它执行计划的第一步，调用 find_order("12345") 工具。它观察结果——一个完整的订单记录，包括跟踪号”ZYX987”。

Agent的编排层识别到计划的第一部分已完成，立即进行第二步。它通过调用 get_shipping_status("ZYX987") 工具来行动。它观察新结果：“正在配送”。

最后，成功执行了计划的数据收集阶段后，Agent进入”报告”步骤。它感知到拥有所有必要组件，规划最终消息，并通过生成响应来行动：“您的订单 #12345 ‘正在配送’！“

Agent系统分类

理解5步操作循环是谜题的第一部分。第二部分是认识到这个循环可以在复杂性上扩展，以创建不同类别的Agent。对于架构师或产品负责人来说，一个关键的初始决策是确定要构建什么类型的Agent。

我们可以将Agent系统分类为几个广泛的级别，每个级别都建立在上一个级别的能力之上。

Level 0：核心推理系统

在我们拥有Agent之前，我们必须从最基本形式的”大脑”开始：推理引擎本身。在这种配置中，语言模型（LM）孤立运行，仅基于其庞大的预训练知识进行响应，没有任何工具、记忆或与实时环境的交互。

其优势在于这种广泛的训练，使其能够深入解释既定概念和规划如何解决问题。权衡是完全缺乏实时意识；它在功能上对其训练数据之外的任何事件或事实”视而不见”。

例如，它可以解释职业棒球的规则和纽约洋基队的完整历史。但如果你问”洋基队昨晚比赛的最终比分是多少？“，它将无法回答。那场比赛是在其训练数据收集后发生的特定真实世界事件，因此信息根本不存在于其知识中。

Level 1：连接式问题解决器

在这个级别，推理引擎通过连接和利用外部工具成为功能性Agent——我们架构的”双手”组件。它的问题解决不再局限于静态的、预训练的知识。

使用5步循环，Agent现在可以回答我们之前的问题。给定”任务”：“洋基队昨晚比赛的最终比分是多少？“，其”思考”步骤将其识别为实时数据需求。其”行动”步骤然后调用一个工具，如带有适当日期和搜索词的Google搜索API。它”观察”搜索结果（例如，“洋基队以5-3获胜”），并将该事实综合成最终答案。

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

Level 2：战略问题解决器

Level 2标志着能力的重大扩展，从执行简单任务转向战略规划复杂的、多部分的目标。这里出现的关键技能是上下文工程：Agent主动选择、打包和管理每个计划步骤最相关信息的能力。

Agent的准确性取决于一个聚焦的、高质量的上下文。上下文工程策划模型有限的注意力以防止过载并确保高效性能。

例如，考虑”任务”：“在我位于山景城圆形剧场大道1600号的办公室和我客户位于旧金山市场街1号的办公室之间找一家好的咖啡店。”

Level 2 Agent将开始创建计划：

1. 思考：“我必须首先找到中点。”

   • 行动：使用两个地址调用地图工具。
   • 观察：“中点是加州米尔布雷。”

2. 思考：“现在我必须在米尔布雷找咖啡店。用户要求’好的’，所以我将搜索评分4星或更高的地方。”

   • 行动：调用 google_places 工具，查询=“米尔布雷，加州的咖啡店”，min_rating=4.0。（这是上下文工程——它自动从前一步的输出创建了一个新的、聚焦的搜索查询）。
   • 观察：“搜索返回’Millbrae Coffee’和’The Daily Grind’。”

3. 思考：“我将综合这些结果并呈现给用户。”

这种战略规划还实现了主动协助，比如一个Agent读取长篇航班确认邮件，提取关键上下文（航班号、日期），并通过将其添加到您的日历来行动。

Level 3：协作式多Agent系统

在最高级别，范式完全转变。我们从构建单一的、全能的”超级Agent”转向协同工作的”专家团队”，这种模型直接反映了人类组织。

系统的集体力量在于这种分工。在这里，Agent将其他Agent视为工具。想象一个”项目经理”Agent接收”任务”：“推出我们的新’Solaris’耳机。”

项目经理Agent不会自己完成全部工作。它通过为其专业Agent团队创建新任务来行动，就像在现实生活中的工作方式一样：

1. 委派给市场研究Agent：“分析降噪耳机的竞争对手定价。明天之前返回摘要文档。”

2. 委派给营销Agent：“使用’Solaris’产品规格表作为上下文起草三个版本的新闻稿。”

3. 委派给Web开发Agent：“基于附加的设计原型生成新产品页面的HTML。”

这种协作模型虽然目前受到当今LM推理限制的约束，但代表着从头到尾自动化整个复杂业务工作流的前沿。

Level 4：自我演化系统

Level 4代表了从委派到自主创建和适应的深刻飞跃。在这个级别，Agent系统可以识别自身能力的差距，并动态创建新工具甚至新Agent来填补它们。它从使用固定的资源集转向主动扩展它们。

继续我们的示例，“项目经理”Agent被任务推出’Solaris’，可能意识到它需要监控社交媒体情绪，但团队中不存在这样的工具或Agent。

1. 思考（元推理）：“我必须跟踪’Solaris’的社交媒体热度，但我缺乏这种能力。”

2. 行动（自主创建）：它不是失败，而是使用新任务调用高级 AgentCreator 工具：“构建一个新Agent，监控关键词’Solaris耳机’的社交媒体，执行情感分析，并报告每日摘要。”

3. 观察：一个新的、专门的 SentimentAnalysisAgent 被创建、测试并即时添加到团队中，准备为原始任务做出贡献。

这种自主性水平，即系统可以动态扩展自己的能力，将Agent团队转变为一个真正学习和演化的组织。

核心Agent架构：模型、工具和编排

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

模型：Agent的”大脑”

LM是Agent的推理核心，其选择是决定Agent认知能力、运营成本和速度的关键架构决策。然而，将这种选择视为简单地选择基准分数最高的模型是通向失败的常见路径。Agent在生产环境中的成功很少由通用学术基准决定。

现实世界的成功需要一个在Agent基础方面表现出色的模型：卓越的推理以应对复杂的多步骤问题和可靠的工具使用以与世界互动。

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

您可以选择多个模型，一个”专家团队”。你不会用大锤敲碎坚果。强大的Agent架构可能使用像Gemini 2.5 Pro这样的前沿模型进行初始规划和复杂推理的重活，但随后智能地将更简单、大量的任务路由到更快、更具成本效益的模型，如Gemini 2.5 Flash，用于分类用户意图或总结文本。模型路由可能是自动的或硬编码的，但是优化性能和成本的关键策略。

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

最后，AI领域处于不断快速演变的状态。您今天选择的模型将在六个月内被取代。“一劳永逸”的心态是不可持续的。为这种现实构建意味着投资于灵活的运营框架——“Agent运维”实践。通过强大的CI/CD管道，针对关键业务指标持续评估新模型，您可以降低风险并加速升级，确保您的Agent始终由可用的最佳大脑驱动，而无需完全架构大修。

工具：Agent的”双手”

如果模型是Agent的大脑，工具就是将其推理连接到现实的双手。它们允许Agent超越其静态训练数据来检索实时信息并在世界上采取行动。强大的工具接口是一个三部分循环：定义工具可以做什么、调用它并观察结果。

以下是Agent构建者将放入其Agent”双手”的几种主要工具类型。有关更完整的深入探讨，请参阅本系列中专注于Agent工具的白皮书。

检索信息：立足现实

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

执行操作：改变世界

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

这还包括人机交互的工具。Agent可以使用**人在环路（HITL）**工具暂停其工作流并请求确认（例如，ask_for_confirmation()）或从用户界面请求特定信息（例如，ask_for_date_input()），确保人员参与关键决策。HITL可以通过SMS短信和数据库中的任务实现。

函数调用：将工具连接到Agent

为了让Agent可靠地进行”函数调用”并使用工具，它需要清晰的指令、安全的连接和编排。像OpenAPI规范这样的长期标准提供了这一点，为Agent提供了一个结构化的合约，描述工具的目的、所需参数和预期响应。这个模式让模型每次都能生成正确的函数调用并解释API响应。为了更简单地发现和连接工具，像**模型上下文协议（MCP）**这样的开放标准变得流行，因为它们更方便。此外，一些模型有原生工具，如具有原生Google搜索的Gemini，其中函数调用作为LM调用本身的一部分发生。

编排层

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

核心设计选择

第一个架构决策是确定Agent的自主程度。选择存在于一个范围内。一端是确定性的、可预测的工作流，将LM作为工具用于特定任务——在现有流程中加入一点AI。另一端，LM处于驾驶席，动态适应、规划和执行任务以实现目标。

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

无论采用何种方法，生产级框架都是必不可少的。它必须是开放的，允许您插入任何模型或工具以防止供应商锁定。它必须提供精确控制，实现混合方法，其中LM的非确定性推理由硬编码的业务规则管理。最重要的是，框架必须为可观察性而构建。当Agent行为异常时，您不能简单地在模型的”想法”中设置断点。强大的框架生成详细的追踪和日志，暴露整个推理轨迹：模型的内部独白、它选择的工具、它生成的参数以及它观察到的结果。

使用领域知识和角色指导

在这个框架内，开发者最强大的杠杆是用领域知识和独特角色指导Agent。这是通过系统提示或一组核心指令来完成的。这不仅仅是一个简单的命令；它是Agent的章程。

在这里，你告诉它：“你是Acme Corp的有帮助的客户支持Agent……”并提供约束、所需的输出模式、参与规则、特定的语气，以及关于何时以及为什么应该使用其工具的明确指导。指令中的一些示例场景通常非常有效。

用上下文增强

Agent的”记忆”在运行时被编排到LM上下文窗口中。有关更完整的深入探讨，请参阅本系列中专注于Agent记忆的白皮书。

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

长期记忆提供跨会话的持久性。从架构上讲，这几乎总是作为另一个专门的工具实现——连接到向量数据库或搜索引擎的RAG系统。编排器使Agent能够预取并主动查询自己的历史，使其能够”记住”用户的偏好或几周前类似任务的结果，以获得真正个性化和连续的体验。

多Agent系统和设计模式

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

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

对于更线性的工作流，顺序模式更合适，像数字装配线一样，一个Agent的输出成为下一个Agent的直接输入。其他关键模式关注质量和安全性。迭代细化模式创建一个反馈循环，使用”生成器”Agent创建内容和”评论家”Agent根据质量标准评估它。对于高风险任务，人在环路（HITL）模式至关重要，在Agent采取重大行动之前，在工作流中创建一个有意的暂停以获得人员批准。

Agent部署和服务

在构建了本地Agent之后，您将希望将其部署到一个始终运行的服务器上，其他人和Agent可以使用它。继续我们的类比，部署和服务将是我们Agent的身体和腿。Agent需要几个服务才能有效，包括会话历史和记忆持久性等。作为Agent构建者，您还将负责决定记录什么，以及为数据隐私、数据驻留和法规合规性采取什么安全措施。所有这些服务都在范围内，当将Agent部署到生产环境时。

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

如果您不是软件开发人员和DevOps专家，部署第一个Agent的过程可能令人生畏。许多Agent框架通过部署命令或专用平台使这变得容易，这些应该用于早期探索和入门。提升到安全且生产就绪的环境通常需要更大的时间投资和最佳实践的应用，包括Agent的CI/CD和自动化测试。

Agent运维

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

从传统的、确定性软件到随机的、Agent系统的过渡需要一种新的运营理念。传统的软件单元测试可以简单地断言 output == expected；但当Agent的响应设计上是概率性的时，这不起作用。此外，因为语言很复杂，它通常需要LM来评估”质量”——Agent的响应是否完成了它应该做的一切，没有做它不应该做的，并且具有适当的语气。

Agent运维是管理这一新现实的有纪律的、结构化的方法。它是DevOps和MLOps的自然演变，针对构建、部署和治理AI Agent的独特挑战量身定制，将不可预测性从负债转变为可管理的、可测量的和可靠的特性。有关更完整的深入探讨，请参阅本系列中专注于Agent质量的白皮书。

衡量重要的事情：像A/B实验一样检测成功

在改进Agent之前，您必须在业务上下文中定义”更好”意味着什么。像A/B测试一样构建可观察性策略，并问自己：什么关键绩效指标（KPI）证明Agent正在交付价值？这些指标应该超越技术正确性，衡量真实世界的影响：目标完成率、用户满意度评分、任务延迟、每次交互的运营成本，以及——最重要的——对收入、转化或客户保留等业务目标的影响。这种自上而下的观点将指导其余的测试，使您走上指标驱动开发的道路，并让您计算投资回报。

质量而非通过/失败：使用LM作为判断者

业务指标不会告诉您Agent是否行为正确。由于简单的通过/失败是不可能的，我们转向使用”LM作为判断者”评估质量。这涉及使用强大的模型根据预定义的标准评估Agent的输出：它给出了正确的答案吗？响应是否基于事实？它是否遵循了指令？这种自动评估针对黄金数据集的提示运行，提供一致的质量度量。

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

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

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

使用OpenTelemetry追踪进行调试：回答”为什么？”

当您的指标下降或用户报告错误时，您需要理解”为什么”。OpenTelemetry追踪是Agent整个执行路径（轨迹）的高保真、逐步记录，使您能够调试Agent的步骤。通过追踪，您可以看到发送给模型的确切提示、模型的内部推理（如果可用）、它选择调用的特定工具、它为该工具生成的精确参数，以及作为观察返回的原始数据。追踪第一次看时可能很复杂，但它们提供了诊断和修复任何问题根本原因所需的详细信息。重要的追踪详细信息可能会转化为指标，但查看追踪主要用于调试，而不是性能概述。追踪数据可以在Google Cloud Trace等平台中无缝收集，这些平台可视化并搜索大量追踪，简化根本原因分析。

珍视人类反馈：引导您的自动化

人类反馈不是要处理的烦恼；它是您改进Agent的最有价值和数据丰富的资源。当用户提交错误报告或点击”拇指向下”按钮时，他们给您一份礼物：一个新的、真实世界的边缘情况，您的自动评估场景遗漏了。收集和聚合这些数据至关重要；当您看到统计上显著数量的类似报告或指标下降时，您必须将发生与您的分析平台联系起来以生成洞察，并触发运营问题的警报。有效的Agent运维流程通过捕获此反馈、复制问题并将该特定场景转换为评估数据集中的新的、永久的测试用例来”关闭循环”。这确保您不仅修复了错误，而且还为系统接种了该整个错误类别再次发生的疫苗。

Agent互操作性

一旦您构建了高质量的Agent，您希望能够将它们与用户和其他Agent互连。在我们的身体部位类比中，这将是Agent的面孔。将Agent与数据和API连接与连接Agent之间有区别；Agent不是工具。假设您已经将工具连接到Agent，现在让我们考虑如何将Agent引入更广泛的生态系统。

Agent和人类

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

计算机使用是一类工具，其中LM控制用户界面，通常在人类交互和监督下。启用计算机使用的Agent可以决定下一个最佳操作是导航到新页面、突出显示特定按钮或使用相关信息预填表单。

Agent不是代表用户使用界面，LM可以更改UI以满足当前需求。这可以通过控制UI的工具（MCP UI）或可以同步客户端状态与Agent的专门UI消息系统（AG UI），甚至生成定制界面（A2UI）来完成。

当然，人机交互不限于屏幕和键盘。高级Agent正在打破文本障碍，通过”实时模式”进入实时、多模态通信，创造更自然、类人的连接。像Gemini Live API这样的技术实现双向流式传输，允许用户与Agent交谈并打断它，就像在自然对话中一样。

这种能力从根本上改变了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可以在长时间运行的连接上工作时提供流式更新。这种强大的、标准化的通信协议是拼图的最后一块，使协作式Level 3多Agent系统成为可能，这代表着自动化的前沿。A2A将孤立Agent的集合转变为真正的、可互操作的生态系统。

Agent和金钱

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

这个新兴领域远未确立，但两个关键协议正在铺平道路。Agent支付协议（AP2）是一个开放协议，旨在成为Agent商务的权威语言。它通过引入加密签名的数字”授权”来扩展A2A等协议。这些作为用户意图的可验证证明，为每笔交易创建不可否认的审计跟踪。这允许Agent基于用户委派的权限在全球范围内安全地浏览、谈判和交易。补充这一点的是x402，一个使用标准HTTP 402”需要付款”状态码的开放互联网支付协议。它实现无摩擦的、机器对机器的小额支付，允许Agent为API访问或数字内容等按使用付费，而无需复杂的账户或订阅。这些协议共同为Agent网络构建基础信任层。

安全性

保护单个Agent：信任权衡

当您创建第一个AI Agent时，您立即面临一个基本张力：实用性和安全性之间的权衡。要使Agent有用，您必须赋予它权力——做出决策的自主权和执行操作的工具，如发送电子邮件或查询数据库。然而，您授予的每一分权力都会引入相应的风险度量。主要的安全担忧是恶意行为——意外或有害的行为——和敏感数据泄露。您想给Agent一个足够长的绳子来完成其工作，但又足够短以防止它跑到交通中，尤其是当该交通涉及不可逆的行动或您公司的私人数据时。

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

第二层利用基于推理的防御，使用AI帮助保护AI。这涉及训练模型对攻击更具弹性（对抗训练），并使用较小的、专门的”守卫模型”，像安全分析师一样。这些模型可以在Agent的建议计划执行之前检查它，标记潜在的风险或违反策略的步骤以供审查。这种混合模型将代码的严格确定性与AI的上下文意识相结合，为即使是单个Agent创建了强大的安全态势，确保其权力始终与其目的保持一致。

Agent身份：新的主体类别

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

让每个身份都经过验证并对所有身份进行访问控制是Agent安全的基石。一旦Agent具有加密可验证的身份（通常使用SPIFFE等标准），就可以授予其自己特定的、最小权限的权限。SalesAgent被授予对CRM的读/写访问权限，而HRonboardingAgent被明确拒绝。这种细粒度控制至关重要。它确保即使单个Agent被破坏或行为异常，潜在的爆炸半径也是受控的。没有Agent身份构造，Agent无法代表具有有限委派权限的人类工作。

不同类别执行者的认证示例表

策略以约束访问

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

保护ADK Agent

建立了身份和策略的核心原则后，保护使用Agent开发套件（ADK）构建的Agent成为通过代码和配置应用这些概念的实际练习。

如上所述，该过程需要明确定义身份：用户账户（例如OAuth）、服务账户（运行代码）、Agent身份（使用委派权限）。一旦处理了认证，下一层防御涉及建立策略以约束对服务的访问。这通常在API治理层完成，以及支持MCP和A2A服务的治理。

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

对于可以适应Agent运行时行为的更动态的安全性，ADK提供回调和插件。before_tool_callback 允许您在工具调用运行之前检查其参数，根据Agent的当前状态验证它们以防止不一致的行动。对于更可重用的策略，您可以构建插件。一个常见的模式是”Gemini作为判断者”，它使用像Gemini Flash-Lite这样的快速、便宜的模型或您自己微调的Gemma模型来实时筛选用户输入和Agent输出，检查提示注入或有害内容。

对于喜欢完全托管的、企业级解决方案进行这些动态检查的组织，可以将Model Armor集成为可选服务。Model Armor充当专门的安全层，筛选提示和响应以应对各种威胁，包括提示注入、越狱尝试、敏感数据（PII）泄漏和恶意URL。通过将这些复杂的安全任务卸载到专用服务，开发人员可以确保一致的、强大的保护，而无需构建和维护这些护栏。ADK内的这种混合方法——结合强身份、确定性工具内逻辑、动态AI驱动护栏和像Model Armor这样的可选托管服务——是您如何构建既强大又值得信赖的单个Agent。

从单个Agent扩展到企业集群

单个AI Agent的生产成功是一场胜利。扩展到数百个Agent集群是架构的挑战。如果您正在构建一两个Agent，您的关注点主要是安全性。如果您正在构建许多Agent，您必须设计系统来处理更多。就像API蔓延一样，当Agent和工具在整个组织中激增时,它们会创建一个新的、复杂的交互、数据流和潜在安全漏洞网络。管理这种复杂性需要一个更高阶的治理层，集成所有身份和策略，并报告到中央控制平面。

安全和隐私：加固Agent前沿

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

强大的平台提供深度防御策略来缓解这些风险。它从数据开始，确保企业的专有信息永远不会用于训练基础模型，并受到VPC Service Controls等控制的保护。它需要输入和输出过滤，像提示和响应的防火墙一样。最后，平台必须提供合同保护，如训练数据和生成输出的知识产权赔偿，使企业有信心在生产中部署Agent所需的法律和技术信心。

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

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

想象一个拥有数千辆自动驾驶车辆的繁华大都市——用户、Agent和工具——所有这些都有目的地移动。没有交通灯、车牌和中央控制系统，将会陷入混乱。网关方法创建了该控制系统，为所有Agent流量建立了一个强制入口点，包括用户到Agent的提示或UI交互、Agent到工具的调用（通过MCP）、Agent到Agent的协作（通过A2A）以及对LM的直接推理请求。通过坐在这个关键交叉点，组织可以检查、路由、监控和管理每次交互。

此控制平面服务于两个主要的、相互关联的功能：

1. 运行时策略执行：它充当实施安全性的架构检查点。它处理认证（“我知道这个执行者是谁吗？“）和授权（“他们有权限做这个吗？”）。集中执行为可观察性提供了”单一窗格”，为每笔交易创建通用日志、指标和追踪。这将不同Agent和工作流的意大利面转变为透明和可审计的系统。

2. 集中治理：为了有效地执行策略，网关需要一个真相来源。这由中央注册表提供——一个Agent和工具的企业应用商店。这个注册表允许开发人员发现和重用现有资产，防止冗余工作，同时为管理员提供完整的库存。更重要的是，它为Agent和工具启用了正式的生命周期，允许在发布前进行安全审查、版本控制，并创建细粒度策略，规定哪些业务单位可以访问哪些Agent。

通过将运行时网关与中央治理注册表相结合，组织将混乱蔓延的风险转变为一个受管理的、安全的和高效的生态系统。

成本和可靠性：基础设施基础

最终，企业级Agent必须既可靠又具成本效益。经常失败或提供缓慢结果的Agent具有负的ROI。相反，过于昂贵的Agent无法扩展以满足业务需求。底层基础设施必须设计为管理这种权衡，安全地且符合监管和数据主权要求。

在某些情况下，您需要的功能是缩放到零，当您对特定Agent或子功能有不规则的流量时。对于关键任务、延迟敏感的工作负载，平台必须提供专用的、有保证的容量，如LM服务的Provisioned Throughput或Cloud Run等运行时的99.9% SLA。这提供了可预测的性能，确保您最重要的Agent始终响应，即使在重负载下。通过提供这种基础设施选项范围，加上成本和性能的全面监控，您为将AI Agent从有前途的创新扩展到企业的核心、可靠组件建立了最终的、必不可少的基础。

Agent如何演化和学习

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

Agent如何学习和自我演化

就像人类一样，Agent从经验和外部信号中学习。这个学习过程由几个信息来源推动：

• 运行时经验：Agent从运行时工件（如会话日志、追踪和记忆）中学习，这些工件捕获成功、失败、工具交互和决策轨迹。至关重要的是，这包括人在环路（HITL）反馈，它提供权威的更正和指导。

• 外部信号：学习也由新的外部文档驱动，如更新的企业策略、公共监管指南或其他Agent的批评。

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

• 增强的上下文工程：系统不断细化其提示、少样本示例以及从记忆中检索的信息。通过优化为每个任务提供给LM的上下文，它增加了成功的可能性。

• 工具优化和创建：Agent的推理可以识别其能力的差距并采取行动来填补它们。这可能涉及获取新工具的访问权限、即时创建新工具（例如，Python脚本）或修改现有工具（例如，更新API模式）。

其他优化技术，如动态重新配置多Agent设计模式或使用来自人类反馈的强化学习（RLHF），是活跃的研究领域。

示例：学习新的合规指南

考虑在金融或生命科学等受严格监管的行业中运作的企业Agent。它的任务是生成必须符合隐私和监管规则（例如，GDPR）的报告。

这可以使用多Agent工作流实现：

1. 查询Agent检索原始数据以响应用户请求。
2. 报告Agent将这些数据综合成草稿报告。
3. 批评Agent，配备已知的合规指南，审查报告。如果遇到歧义或需要最终签字，它会升级到人类领域专家。
4. 学习Agent观察整个交互，特别关注来自人类专家的纠正性反馈。然后它将此反馈概括为新的、可重用的指南（例如，批评Agent的更新规则或报告Agent的精炼上下文）。

例如，如果人类专家标记某些家庭统计数据必须匿名化，学习Agent会记录这个更正。下次生成类似报告时，批评Agent将自动应用这个新规则，减少人类干预的需要。这种批评、人类反馈和概括的循环允许系统自主适应不断发展的合规要求。

模拟和Agent Gym——下一个前沿

我们提出的设计模式可以归类为在线学习，其中Agent需要使用它们被设计的资源和设计模式来学习。现在正在研究更高级的方法，其中有一个专门的平台，旨在通过高级工具和功能在离线流程中优化多Agent系统，这些功能不是多Agent运行时环境的一部分。这种Agent Gym的关键属性是：

1. 不在执行路径中。它是一个独立的非生产平台，因此可以获得任何LM模型和离线工具、云应用程序等的帮助

2. 提供模拟环境，因此Agent可以在新数据上”练习”和学习。这个模拟环境非常适合具有许多优化路径的”试错”

3. 可以调用高级合成数据生成器，引导模拟尽可能真实，并对Agent进行压力测试（这可以包括高级技术，如红队、动态评估和一系列批评Agent）

4. 优化工具的武器库不是固定的，它可以采用新工具（通过MCP或A2A等开放协议），或在更高级的设置中——学习新概念并围绕它们制作工具

5. 最后，即使是Agent Gym等构造也可能无法克服某些边缘情况（由于企业中众所周知的”部落知识”问题）。在这些情况下，我们看到Agent Gym能够连接到领域专家的人类结构，并咨询他们关于正确的结果集以指导下一组优化

高级Agent示例

Google Co-Scientist

Co-Scientist是一个高级AI Agent，旨在作为虚拟研究合作者发挥作用，通过系统地探索复杂的问题空间来加速科学发现。它使研究人员能够定义目标，在指定的公共和专有知识来源中为Agent提供基础，然后生成和评估新颖假设的景观。

为了能够实现这一点，Co-Scientist生成了一个整个Agent生态系统相互协作。

将系统视为一个研究项目经理。AI首先采用广泛的研究目标并创建详细的项目计划。然后，“主管”Agent充当经理，将任务委派给专业Agent团队并分配资源，如计算能力。这种结构确保项目可以轻松扩展，并且团队的方法随着他们朝着最终目标努力而改进。

各种Agent工作数小时，甚至数天，并不断改进生成的假设，运行循环和元循环，不仅改进生成的想法，还改进我们判断和创建新想法的方式。

AlphaEvolve Agent

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

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

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

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

AlphaEvolve擅长验证解决方案的质量远比首先找到它容易的问题。

AlphaEvolve是为人类和AI之间的深度、迭代伙伴关系而设计的。这种协作以两种主要方式工作：

• 透明的解决方案：AI生成人类可读代码的解决方案。这种透明度使用户能够理解逻辑、获得洞察、信任结果并直接修改代码以满足他们的需求。

• 专家指导：人类专业知识对于定义问题至关重要。用户通过细化评估指标和引导探索来指导AI，这防止系统利用问题定义中的意外漏洞。这种交互循环确保最终解决方案既强大又实用。

Agent的结果是代码的持续改进，不断改进人类指定的指标。

结论

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

我们已将Agent解构为其三个基本组件：推理模型（“大脑”）、可操作的工具（“双手”）和管理编排层（“神经系统”）。正是这些部分的无缝集成，在持续的”思考、行动、观察”循环中运作，释放了Agent的真正潜力。通过对Agent系统进行分类——从Level 1连接式问题解决器到Level 3协作式多Agent系统——架构师和产品负责人现在可以战略性地确定其抱负的范围，以匹配手头任务的复杂性。

核心挑战和机遇在于新的开发者范式。我们不再简单地作为”砌砖工”定义显式逻辑；我们是必须引导、约束和调试自主实体的”架构师”和”导演”。使LM如此强大的灵活性也是其不可靠性的来源。因此，成功不是仅在初始提示中找到的，而是在应用于整个系统的工程严谨性中：在强大的工具合约、弹性错误处理、复杂的上下文管理和全面的评估中。

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

参考文献

1. Julia Wiesinger, Patrick Marlow, et al. 2024 “Agents”. https://www.kaggle.com/whitepaper-agents
2. Antonio Gulli, Lavi Nigam, et al. 2025 “Agents Companion”. https://www.kaggle.com/whitepaper-agent-companion
3. Shunyu Yao, Y. et al., 2022, ‘ReAct: Synergizing Reasoning and Acting in Language Models’. https://arxiv.org/abs/2210.03629
4. Wei, J., Wang, X. et al., 2023, ‘Chain-of-Thought Prompting Elicits Reasoning in Large Language Models’. https://arxiv.org/pdf/2201.11903.pdf
5. Shunyu Yao, Y. et al., 2022, ‘ReAct: Synergizing Reasoning and Acting in Language Models’. https://arxiv.org/abs/2210.03629
6. https://www.amazon.com/Agentic-Design-Patterns-Hands-Intelligent/dp/3032014018
7. Shunyu Yao, et. al., 2024, ‘τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains’, https://arxiv.org/abs/2406.12045
8. https://artificialanalysis.ai/guide
9. https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/vertex-ai-model-optimizer
10. https://gemini.google/overview/gemini-live/
11. https://cloud.google.com/vision
12. https://cloud.google.com/speech-to-text
13. https://medium.com/google-cloud/genaiops-operationalize-generative-ai-a-practical-guide-d5bedaa59d78
14. https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/code-execution/overview
15. https://ai.google.dev/gemini-api/docs/function-calling
16. https://github.com/modelcontextprotocol/
17. https://ai.google.dev/gemini-api/docs/google-search
18. https://google.github.io/adk-docs/
19. https://google.github.io/adk-docs/sessions/memory/
20. https://cloud.google.com/architecture/choose-design-pattern-agentic-ai-system
21. https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/overview
22. https://cloud.google.com/kubernetes-engine/docs/concepts/gke-and-cloud-run
23. https://github.com/GoogleCloudPlatform/agent-starter-pack
24. Sokratis Kartakis, 2024, ‘GenAI in Production: MLOps or GenAIOps?’. https://medium.com/google-cloud/genai-in-production-mlops-or-genaiops-25691c9becd0
25. Guangya Liu, Sujay Solomon, March 2025 “AI Agent Observability - Evolving Standards and Best Practice”. https://opentelemetry.io/blog/2025/ai-agent-observability/
26. https://discuss.google.dev/t/agents-are-not-tools/192812
27. Damien Masson et. al, 2024, ‘DirectGPT: A Direct Manipulation Interface to Interact with Large Language Models’. https://arxiv.org/abs/2310.03691
28. https://mcpui.dev/
29. https://ag-ui.com/
30. https://github.com/google/A2UI
31. https://cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-5-flash-live-api
32. https://saif.google/focus-on-agents
33. https://simonwillison.net/series/prompt-injection/
34. https://storage.googleapis.com/gweb-research2023-media/pubtools/1018686.pdf
35. https://spiffe.io/
36. https://openreview.net/pdf?id=l9rATNBB8Y
37. https://google.github.io/adk-docs/safety/
38. https://google.github.io/adk-docs/callbacks/design-patterns-and-best-practices/#guardrails-policy-enforcement
39. TKTK
40. https://cloud.google.com/security-command-center/docs/model-armor-overview
41. https://cloud.google.com/vertex-ai/generative-ai/docs/provisioned-throughput/overview
42. https://cloud.google.com/run/sla
43. https://github.com/CharlesQ9/Self-Evolving-Agents
44. Juraj Gottweis, et. al., 2025, ‘Accelerating scientific breakthroughs with an AI co-scientist’. https://research.google/blog/accelerating-scientific-breakthroughs-with-an-ai-co-scientist/
45. Deepak Nathani et. al. 2025, ‘MLGym: A New Framework and Benchmark for Advancing AI Research Agents’, https://arxiv.org/abs/2502.14499

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

WeChat