智能体入门（Introduction to Agents）

• 作者：艾伦·布朗特（Alan Blount）、安东尼奥·古利（Antonio Gulli）、舒巴姆·萨布（Shubham Saboo）、迈克尔·齐默尔曼（Michael Zimmermann）、弗拉基米尔·武斯科维奇（Vladimir Vuskovic）
• 单位： 谷歌（Google）

内容贡献者
恩里克·陈（Enrique Chan）、迈克·克拉克（Mike Clark）、德里克·伊根（Derek Egan）、阿南特·纳瓦尔加里亚（Anant Nawalgaria）、坎查娜·帕特洛拉（Kanchana Patlolla）、朱莉娅·维辛格（Julia Wiesinger）
策划与编辑
阿南特·纳瓦尔加里亚（Anant Nawalgaria）、坎查娜·帕特洛拉（Kanchana Patlolla）
设计师
迈克尔·兰宁（Michael Lanning）
2025年11月

从预测性AI到自主智能体 6
智能体入门 8
智能体问题解决流程 10
智能体系统分类法 14
第0级：核心推理系统 15
第1级：互联问题解决者 15
第2级：战略问题解决者 16
第3级：协作式多智能体系统 17
第4级：自我进化系统 18
智能体核心架构：模型、工具与编排 19
模型：AI智能体的“大脑” 19
工具：AI智能体的“双手” 20
执行动作：改变世界 21
检索信息：扎根现实 21
函数调用：连接智能体与工具 22
编排层 22
注入领域知识与设定角色 23
核心设计选择 23
通过上下文增强能力 24
多智能体系统与设计模式 24
智能体部署与服务 26
智能体运维（Agent Ops）：应对不确定性的结构化方法 27
聚焦关键指标：像A/B测试一样衡量成效 29
重质不重“过/失”：使用语言模型评估器（LM Judge） 29
数据驱动开发：部署的“通过/否决”标准 30
借助OpenTelemetry追踪调试：解答“为什么” 30
重视人类反馈：指导自动化进程 31
智能体互操作性 31
智能体与人类 32
智能体与智能体 33
智能体与货币 34
单个智能体的安全防护：信任权衡 34
限制访问的策略 35
智能体身份：一类新型主体 37
ADK智能体的安全防护 37
从单个智能体扩展至企业级智能体集群 39
安全与隐私：加固智能体前沿防线 40
智能体治理：以控制平面替代无序扩张 40
智能体的进化与学习方式 42
智能体如何学习与自我进化 43
模拟与智能体训练平台（Agent Gym）——下一个前沿领域 46
高级智能体案例 47
谷歌协研智能体（Google Co-Scientist） 47
阿尔法进化智能体（AlphaEvolve Agent） 49
结论 51
注释 52

智能体是语言模型（LM）的自然演进，在软件中实现实用价值。

从预测性AI到自主智能体

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

本文是五部分系列文档的第一篇，为开发者、架构师和产品负责人提供正式指南，助力其从概念验证过渡到稳健的生产级智能体系统。构建简单原型固然直接，但确保系统的安全性、质量与可靠性则极具挑战。本文提供了全面的基础框架：

• 核心构成：将智能体拆解为三大关键组件——推理模型（Model）、可执行工具（Tools）与管控编排层（Orchestration Layer）。
• 能力分类法：将智能体划分为不同级别，从简单的互联问题解决者到复杂的协作式多智能体系统。
• 架构设计：深入探讨各组件的实际设计考量，从模型选择到工具实现。
• 生产级构建：建立智能体运维（Agent Ops）规范，涵盖评估、调试、安全防护与规模扩展，实现从单个实例到具备企业级治理能力的智能体集群。

本文基于此前的《智能体白皮书》¹与《智能体配套指南》²，提供了构建、部署和管理新一代智能应用所需的基础概念与战略框架——这类应用能够通过推理、行动和观察来达成目标³。

用语言描述人类与AI的交互并不充分。我们倾向于将AI拟人化，使用“思考”“推理”“知晓”等人类词汇。但我们尚无专门术语区分“基于语义的知晓”与“基于最大化奖励函数概率的知晓”——这两种“知晓”类型不同，但99.X%的情况下结果一致。

智能体入门

简而言之，AI智能体可定义为：融合模型、工具、编排层与运行时服务的系统，通过语言模型的循环调用实现目标。这四大要素构成了任何自主系统的核心架构：

• 模型（大脑）：作为智能体核心推理引擎的语言模型（LM）或基础模型，负责处理信息、评估选项并做出决策。模型类型（通用型、微调型或多模态型）决定了智能体的认知能力。智能体系统是语言模型输入上下文窗口的终极管理者。
• 工具（双手）：连接智能体推理能力与外部世界的机制，使其能够超越文本生成开展行动。包括API扩展、代码函数和数据存储（如数据库或向量数据库），用于获取实时、真实信息。智能体系统允许语言模型规划工具使用、执行工具调用，并将工具结果纳入下一次语言模型调用的输入上下文窗口。
• 编排层（神经系统）：管控智能体运行循环的核心流程，负责规划、记忆（状态）与推理策略执行。该层借助提示框架和推理技术（如
  思维链（Chain-of-Thought）⁴或反应式推理（ReAct）⁵），将复杂目标拆解为步骤，并决定何时进行推理、何时使用工具。同时，该层还负责为智能体提供“记忆”能力。
• 部署（身体与四肢）：在笔记本电脑上构建智能体适用于原型验证，但生产级部署才能使其成为可靠、可访问的服务。这包括将智能体部署在安全可扩展的服务器上，并集成监控、日志记录和管理等关键生产级服务。部署后，用户可通过图形界面或其他智能体通过智能体间（A2A）API以编程方式访问该智能体。

归根结底，构建生成式AI智能体是一种解决任务的全新开发方式。传统开发者如同“砌砖工”，精确定义每一个逻辑步骤；而智能体开发者更像“导演”——无需为每个动作编写明确代码，只需搭建场景（提供指导指令和提示）、挑选“演员”（工具和API）并提供必要上下文（数据）。核心任务是引导这个自主“演员”呈现预期效果。

你会很快发现，语言模型最大的优势——极强的灵活性，也是最令人头疼的问题。大语言模型“无所不能”的特性，使其难以被约束在特定任务中稳定、完美地执行。我们过去所说的“提示工程”（Prompt Engineering），如今被称为“上下文工程”（Context Engineering），其作用是引导语言模型生成期望输出。每次调用语言模型时，我们都会输入指令、事实、可用工具、示例、会话历史、用户画像等信息——为上下文窗口填充恰好所需的内容，以获取理想输出。智能体正是通过管理语言模型输入来完成工作的软件。

当出现问题时，调试至关重要。“智能体运维（Agent Ops）”本质上重新定义了熟悉的“衡量-分析-系统优化”循环。通过追踪和日志，你可以监控智能体的“思考过程”，识别偏离预期执行路径的情况。随着模型和框架的升级，开发者的核心任务是提供关键组件：领域专业知识、明确的角色设定，以及与实际任务执行所需工具的无缝集成。需谨记，全面的评估往往比初始提示更为重要。

当智能体具备清晰指令、可靠工具、集成化记忆上下文、优质用户界面、规划与问题解决能力，以及通用世界知识时，它将超越“工作流自动化”的范畴，成为协作实体——高效、适应性强、能力卓越的“团队新成员”。

本质上，智能体是专注于上下文窗口管理的系统。它通过持续循环实现目标：整合上下文、提示模型、观察结果，再为下一步整合新的上下文。上下文可能包括系统指令、用户输入、会话历史、长期记忆、权威来源的支撑知识、可用工具及已调用工具的结果。这种对模型注意力的精细化管理，使其推理能力能够应对全新场景、实现目标。

我们将AI智能体定义为：融合推理模型、可执行工具与管控编排层的完整目标导向型应用。简而言之，就是“通过工具循环调用语言模型实现目标”。

但这个系统实际如何运作？从接收请求到交付结果，智能体经历了哪些过程？

智能体的核心运作逻辑是通过持续循环实现目标。尽管这个循环可能极为复杂，但可拆解为五个基本步骤（详见《智能体系统设计》一书⁶）：

1. 接收任务（Get the Mission）：由具体的高阶目标启动流程。该任务可由用户发起（如“为团队即将到来的会议安排差旅”），或由自动化触发（如“收到高优先级客户工单”）。
2. 场景扫描（Scan the Scene）：智能体感知环境以收集上下文，由编排层调用可用资源：“用户请求包含哪些信息？”“短期记忆中有什么？我是否已尝试过该任务？用户上周是否提供过指导？”“通过工具（如日历、数据库、API）可获取哪些信息？”
3. 思考分析（Think It Through）：这是智能体的核心“思考”循环，由推理模型驱动。智能体结合任务（步骤1）与场景（步骤2）制定计划，通常涉及一系列推理：“要预订差旅，首先需确认团队成员名单（调用get_team_roster工具），然后通过calendar_api查询他们的可用时间。”
4. 采取行动（Take Action）：编排层执行计划的首个具体步骤，选择并调用合适工具——调用API、运行代码函数或查询数据库。这是智能体作用于外部世界的关键环节。
5. 观察迭代（Observe and Iterate）：智能体观察行动结果（如get_team_roster工具返回5人名单），将新信息添加到上下文或“记忆”中，随后循环返回步骤3：“现已获取成员名单，下一步通过calendar_api查询这5人的日程。”

这种“思考-行动-观察”循环在编排层的管控、模型的推理与工具的执行下持续进行，直至智能体完成内部计划、达成初始任务目标。

1. 确认：首先在内部数据库中查找该订单，核实其存在性并获取详情。
2. 追踪：从订单详情中提取快递公司运单号，通过外部快递公司API查询实时状态。
3. 反馈：将收集到的信息整合为清晰易懂的回复呈现给用户。”

基于该多步骤计划，智能体开始执行：
在首次“行动”阶段，执行计划第一步，调用find_order(“12345”)工具，观察结果——获取包含运单号“ZYX987”的完整订单记录。
编排层识别到计划第一步完成，立即推进至第二步，调用get_shipping_status(“ZYX987”)工具，观察新结果：“正在派送中（Out for Delivery）”。
最终，智能体完成数据收集阶段，进入“反馈”步骤，确认已获取所有必要信息后，生成并返回响应：“你的订单#12345正在派送中！”

理解五步骤运行循环是基础，其次需认识到：该循环可通过复杂度升级形成不同类型的智能体。对于架构师或产品负责人而言，首要决策是明确需构建的智能体类型。

我们可将智能体系统划分为多个层级，每个层级均基于前一层级的能力构建：

第4级：自我进化智能体
第3级：协作式多智能体系统的兴起
第2级：战略问题解决者
第1级：互联问题解决者
第0级：核心推理系统
（Figure 2: Agentic system in 5 steps）

第0级：核心推理系统

构建智能体前，需从最基础的“大脑”——推理引擎开始。在该层级，语言模型独立运行，仅基于海量预训练知识响应请求，无工具、无记忆，也不与实时环境交互。

其优势在于丰富的训练数据，能够深入解释已确立的概念并规划问题解决思路。但代价是完全缺乏实时感知能力——对于训练数据之外的事件或事实，它本质上“视而不见”。

例如，它可以解释职业棒球规则和纽约洋基队的完整历史，但如果询问“昨晚洋基队的比赛最终比分是多少？”，它无法回答——该比赛是训练数据收集后的真实事件，相关信息并未存储在其知识库中。

第1级：互联问题解决者

在该层级，推理引擎通过连接并使用外部工具（架构中的“双手”）成为功能性智能体，问题解决不再局限于静态预训练知识。

借助五步骤循环，智能体可回答前文的问题：面对“昨晚洋基队的比赛最终比分是多少？”这一任务，“思考”阶段识别出需要实时数据，“行动”阶段调用谷歌搜索API（输入正确日期和搜索关键词），“观察”到搜索结果（如“洋基队5-3获胜”），并整合为最终答案。

这种与外部世界交互的核心能力——无论是通过搜索工具查询比分、通过金融API获取实时股价，还是通过检索增强生成（RAG）查询数据库——正是第1级智能体的关键特征。

第2级：战略问题解决者

第2级智能体的能力实现显著扩展，从执行简单任务升级为战略规划复杂多部分目标。核心新增能力是上下文工程：智能体能够主动选择、整合并管理每个步骤所需的最相关信息。

智能体的准确性依赖聚焦、高质量的上下文。上下文工程通过优化模型的有限注意力，避免信息过载，确保高效性能。

例如，面对任务：“查找位于我（山景城1600 Amphitheatre Parkway办公室）与客户（旧金山1 Market St办公室）之间的优质咖啡店。”

第2级智能体将启动如下计划：

1. 思考：“首先需确定中点位置。”
   • 行动：调用地图工具输入两个地址。
   • 观察：“中点为加利福尼亚州米尔布雷（Millbrae, CA）。”
2. 思考：“现在需查找米尔布雷的咖啡店。用户要求‘优质’，因此筛选评分4星及以上的选项。”
   • 行动：调用google_places工具，查询条件为“coffee shop in Millbrae, CA”，最低评分4.0（这正是上下文工程——根据上一步结果自动生成聚焦的新搜索查询）。
   • 观察：“搜索结果返回‘米尔布雷咖啡（Millbrae Coffee）’和‘每日研磨（The Daily Grind）’。”
3. 思考：“整合结果并呈现给用户。”

这种战略规划能力还支持主动协助，例如智能体读取冗长的航班确认邮件后，提取关键上下文（航班号、日期）并自动添加到用户日历中。

第3级：协作式多智能体系统

在最高层级，范式发生彻底转变——不再构建单一全能的“超级智能体”，而是打造“专家团队”协同工作，这一模式与人类组织架构高度契合。系统的集体优势源于分工协作。

在此模式中，智能体将其他智能体视为工具。例如，“项目经理智能体”接到任务：“推出新款‘Solaris’耳机。”

项目经理智能体不会独自完成所有工作，而是像现实场景中那样，为专业智能体团队分配新任务：

1. 委派给市场研究智能体：“分析降噪耳机的竞品定价，明日返回总结文档。”
2. 委派给营销智能体：“以‘Solaris’产品规格说明书为上下文，起草三份新闻稿。”
3. 委派给网页开发智能体：“根据附带的设计原型生成新产品页面HTML代码。”

这种协作模式虽目前受限于现有语言模型的推理能力，但代表了自动化完整复杂业务流程的前沿方向。

第4级：自我进化系统

第4级智能体实现了从“委派任务”到“自主创建与适配”的巨大飞跃。该层级的智能体系统能够识别自身能力缺口，并动态创建新工具甚至新智能体来填补缺口——从使用固定资源升级为主动扩展资源。

延续前文示例，负责“Solaris”耳机推出任务的“项目经理智能体”若发现需要监控社交媒体舆情，但团队中无此类工具或智能体，将按以下流程行动：

1. 元推理（Think）：“需追踪‘Solaris’的社交媒体讨论，但缺乏相关能力。”
2. 自主创建（Act）：调用高阶AgentCreator工具，发起新任务：“构建新智能体，监控社交媒体中‘Solaris耳机’关键词，执行情感分析并每日提交总结报告。”
3. 观察（Observe）：新的专业情感分析智能体（SentimentAnalysisAgent）被实时创建、测试并加入团队，为初始任务提供支持。

这种能够动态扩展自身能力的自主性，使智能体团队成为真正具备学习和进化能力的组织。

我们已了解智能体的运作方式与能力层级，但如何实际构建？从概念到代码的关键在于三大核心组件的具体架构设计。

模型：AI智能体的“大脑”

语言模型是智能体的推理核心，其选择是关键的架构决策，将决定智能体的认知能力、运营成本和响应速度。但将选择标准简化为“基准测试分数最高”往往会导致失败——生产环境中智能体的成功很少由通用学术基准决定。

现实场景的成功要求模型在智能体核心能力上表现卓越：具备应对复杂多步骤问题的出色推理能力，以及与外部世界交互的可靠工具使用能力⁷。

要实现这一点，需先明确业务问题，再针对直接映射业务成果的指标测试模型：若智能体需编写代码，就在私有代码库中测试；若需处理保险理赔，就评估其从特定文档格式中提取信息的能力。随后，还需结合成本和延迟等实际因素综合分析。“最佳”模型是在特定任务的质量、速度和价格之间达到最优平衡的模型⁸。

你也可以选择多个模型组成“专家团队”——无需“用大锤敲坚果”。稳健的智能体架构可能采用前沿模型（如Gemini 2.5 Pro）处理初始规划和复杂推理等核心工作，同时将分类用户意图、文本摘要等简单高频任务，智能路由至更快、更具成本效益的模型（如Gemini 2.5 Flash）。模型路由可自动执行或硬编码设置，是优化性能与成本的关键策略⁹。

处理多样化数据类型时同样适用这一原则：虽然Gemini实时模式（Gemini live mode）等原生多模态模型提供了处理图像和音频的简化路径，但也可选择Cloud Vision API¹¹或语音转文本API¹²等专业工具——先将外部信息转换为文本，再传递给纯语言模型进行推理。这种模式虽增加了灵活性并支持选用最优组件，但也引入了显著的复杂度。

最后，AI领域正处于快速持续的演进中，当前选择的模型可能在六个月后就被超越。“一劳永逸”的心态不可持续，因此需构建灵活的运营框架——“智能体运维（Agent Ops）”实践¹³。借助强大的CI/CD流水线持续评估新模型与关键业务指标的匹配度，可降低升级风险、加快迭代速度，确保智能体始终搭载最优“大脑”，而无需彻底重构架构。

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

若模型是智能体的大脑，工具就是连接其推理能力与现实世界的双手。工具使智能体能够突破静态训练数据的限制，获取实时信息并采取行动。稳健的工具接口包含三个环节：定义工具功能、调用工具、观察结果。

以下是智能体开发者常用的核心工具类型（更多细节详见本系列中聚焦工具的白皮书）：

检索信息：扎根现实

最基础的工具是获取最新信息的能力。检索增强生成（RAG）为智能体提供了查询外部知识的“图书馆借阅证”——外部知识通常存储在向量数据库或知识图谱中，涵盖企业内部文档到谷歌搜索的网络知识。对于结构化数据，自然语言转SQL（NL2SQL）工具允许智能体查询数据库，解答“上季度最畅销产品是什么？”等分析类问题。通过在输出前查询文档或数据库，智能体能够扎根事实，大幅减少幻觉。

执行动作：改变世界

智能体的真正力量在从“读取信息”升级为“主动行动”时释放。通过将现有API和代码函数封装为工具，智能体可发送邮件、安排会议或更新ServiceNow中的客户记录。对于更动态的任务，智能体还能实时编写并执行代码：在安全沙箱中生成SQL查询或Python脚本，解决复杂问题或执行计算，从“知识助手”转变为“自主行动者”¹⁴。

这还包括人类交互工具：智能体可通过人机协同（HITL）工具暂停工作流，请求确认（如ask_for_confirmation()）或从用户界面获取特定信息（如ask_for_date_input()），确保关键决策有人类参与。人机协同可通过短信和数据库任务实现。

函数调用：连接智能体与工具

智能体要可靠地实现“函数调用”和工具使用，需要清晰的指令、安全的连接和编排能力¹⁵。OpenAPI规范等成熟标准提供了结构化契约，描述工具的用途、必填参数和预期响应，使模型能够每次生成正确的函数调用并解读API响应。对于更简单的工具发现与连接，模型上下文协议（MCP）等开放标准因其便捷性而广受青睐¹⁶。此外，部分模型具备原生工具，如支持原生谷歌搜索的Gemini，其函数调用可直接作为语言模型调用的一部分¹⁷。

编排层

若模型是智能体的大脑、工具是双手，编排层就是连接二者的中枢神经系统。它是运行“思考-行动-观察”循环的引擎，是管控智能体行为的状态机，也是开发者精心设计的逻辑落地载体。这一层并非简单的“管道”，而是整个智能体系统的“指挥家”——决定模型何时推理、工具何时行动，以及行动结果如何指导下一步运作。

核心设计选择

首要架构决策是确定智能体的自主程度，该选择呈光谱分布：一端是确定性、可预测的工作流（将语言模型作为特定任务的工具，为现有流程增添AI能力）；另一端是语言模型主导的动态适配模式（自主规划、执行任务以实现目标）。

并行决策是实现方式：无代码构建工具注重速度和易用性，助力业务用户快速自动化结构化任务、构建简单智能体；对于复杂的关键任务系统，代码优先框架（如谷歌智能体开发工具包ADK¹⁸）能提供工程师所需的深度控制、定制化和集成能力。

无论采用哪种方式，生产级框架都至关重要：需具备开放性，支持接入任意模型或工具以避免供应商锁定；需提供精准控制，支持混合模式（用硬编码业务规则约束语言模型的非确定性推理）；最重要的是，需具备可观测性——当智能体行为异常时，无法在模型“思考过程”中设置断点，因此稳健的框架需生成详细追踪和日志，暴露完整推理轨迹：模型的内部独白、选择的工具、生成的参数及观察到的结果。

注入领域知识与设定角色

在该框架中，开发者最强大的工具是通过系统提示或核心指令，为智能体注入领域知识并设定独特角色——这相当于智能体的“宪法”。

例如，你可以明确：“你是Acme公司的贴心客服智能体……”，同时提供约束条件、期望输出格式、互动规则、特定语气，以及何时/为何使用工具的明确指导。在指令中加入少量示例场景通常能显著提升效果。

通过上下文增强能力

智能体的“记忆”在运行时被整合到语言模型的上下文窗口中（更多细节详见本系列中聚焦记忆的白皮书）。

短期记忆是智能体的活跃“草稿本”，记录当前会话的运行历史，追踪循环中的（行动、观察）对，为模型提供下一步决策所需的即时上下文，可通过状态、工件、会话或线程等抽象概念实现。

长期记忆支持跨会话持久性，在架构上几乎总是通过专用工具实现——连接向量数据库或搜索引擎的检索增强生成（RAG）系统。编排层使智能体能够预获取并主动查询自身历史，“记住”用户偏好或数周前类似任务的结果，提供真正个性化、连续性的体验¹⁹。

多智能体系统与设计模式

随着任务复杂度提升，构建单一全能的“超级智能体”会变得低效。更有效的方案是采用“专家团队”模式（与人类组织架构一致）：将复杂流程拆分为离散子任务，分配给专门的AI智能体。这种分工使每个智能体更简单、聚焦，更易于构建、测试和维护，适用于动态或长期运行的业务流程。

架构师可采用成熟的智能体设计模式（尽管智能体能力及模式仍在快速演进）²⁰：对于动态或非线性任务，协调者模式（Coordinator pattern）至关重要——引入“管理者智能体”分析复杂请求、拆分核心任务，并将子任务智能路由至相应专家智能体（如研究员、撰稿人、程序员），再整合专家响应形成完整答案。

（Figure 3: The “iterative refinement” pattern from https://cloud.google.com/architecture/choose-design-pattern-agentic-ai-system）

对于线性工作流，序列模式（Sequential pattern）更合适——如同数字装配线，一个智能体的输出直接作为下一个智能体的输入。其他关键模式聚焦质量与安全：迭代优化模式（Iterative Refinement pattern）构建反馈循环，由“生成智能体”创建内容，“评论智能体”根据质量标准评估；对于高风险任务，人机协同（HITL）模式至关重要——在智能体采取重大行动前暂停工作流，获取人类批准。

在本地构建智能体后，需将其部署到服务器上持续运行，供其他人和智能体访问。延续前文类比，部署与服务相当于智能体的“身体与四肢”。智能体需多种服务支持才能有效运作，包括会话历史存储、记忆持久化等。作为智能体开发者，你还需决定日志内容、数据隐私安全措施及合规要求——这些均属于智能体生产级部署的范畴。

幸运的是，智能体开发者可依托数十年的应用托管基础设施——智能体本质上是新型软件，许多传统原则依然适用。开发者可选择专门的智能体部署方案（如Vertex AI Agent Engine），在单一平台中整合运行时及其他所需服务²¹；对于希望直接控制应用栈或在现有DevOps基础设施中部署智能体的软件开发者，可将任意智能体及大部分智能体服务封装到Docker容器中，部署到Cloud Run或GKE等行业标准运行时环境²²。

（Figure 4: Vertex AI Agent builder from）

若你并非软件开发者或DevOps专家，首次部署智能体可能颇具挑战性。许多智能体框架通过部署命令或专用平台简化了这一过程，适用于早期探索和入门。而要搭建安全的生产级环境，通常需要投入更多时间并遵循最佳实践，包括智能体的CI/CD和自动化测试²³。

智能体运维（Agent Ops）：应对不确定性的结构化方法

构建首个智能体时，你会反复手动测试其行为：添加功能后是否可用？修复漏洞后是否引发新问题？测试是软件开发的常态，但在生成式AI中运作方式不同。

从传统确定性软件向随机智能体系统的转变，需要新的运营理念。传统软件单元测试可直接断言“输出==预期结果”，但智能体的响应本质上具有概率性，无法采用这种方式；此外，语言的复杂性意味着通常需要语言模型评估“质量”——智能体的响应是否完成所有应做事项、无多余内容，且语气恰当。

（Figure 5: Relationships between the operational domains of DevOps, MLOps, and GenAIOps from https://medium.com/@sokratis.kartakis/genai-in-production-mlops-or-genaiops-25691c9becd0）

智能体运维（Agent Ops）是管理这一全新现实的严谨结构化方法，是DevOps和MLOps的自然演进，专为构建、部署和治理AI智能体的独特挑战设计，将不确定性从劣势转化为可管理、可衡量、可靠的特性²⁴（更多细节详见本系列中聚焦质量的白皮书）。

聚焦关键指标：像A/B测试一样衡量成效

要优化智能体，需先定义业务场景中的“更好”——将可观测性策略设计为A/B测试，明确证明智能体价值的关键绩效指标（KPI）。这些指标应超越技术正确性，衡量实际业务影响：目标完成率、用户满意度、任务延迟、每次交互的运营成本，以及最重要的——对收入、转化率或客户留存率等业务目标的影响。这种自上而下的视角将指导后续测试，推动数据驱动开发，并计算投资回报率。

重质不重“过/失”：使用语言模型评估器（LM Judge）

业务指标无法反映智能体行为的正确性。由于无法简单判定“通过/失败”，我们转向使用“语言模型评估器（LM as Judge）”评估质量：借助强大模型，根据预设标准评估智能体输出——答案是否正确？是否有事实依据？是否遵循指令？通过在“黄金数据集”的提示上运行自动化评估，可获得一致的质量衡量标准。

创建评估数据集（包含理想问题和正确响应）可能较为繁琐，需从智能体的现有生产或开发交互中采样场景，覆盖所有预期用例及部分意外场景。尽管评估投入能快速见效，但评估结果仍需领域专家审核后才能确认有效。如今，产品经理在领域专家支持下，正逐渐承担起评估数据集的整理和维护职责。

数据驱动开发：部署的“通过/否决”标准

当你完成数十个自动化评估场景并建立可信质量分数后，即可自信地测试开发版智能体的变更：将新版本在完整评估数据集上运行，直接与现有生产版分数对比。这套稳健系统消除了猜测，确保每次部署都有可靠依据。需注意，除自动化评估外，还需考量延迟、成本和任务成功率等因素；为最大限度保障安全，可采用A/B部署逐步推出新版本，将真实生产环境指标与模拟分数对比。

借助OpenTelemetry追踪调试：解答“为什么”

当指标下滑或用户反馈漏洞时，需明确“为什么”。OpenTelemetry追踪是智能体完整执行路径的高保真分步记录，可用于调试智能体步骤²⁵。通过追踪，你能查看发送给模型的精确提示、模型的内部推理（若可用）、选择的具体工具、生成的精确参数及返回的原始数据。初次查看追踪数据可能较为复杂，但它能提供诊断和修复根本问题所需的详细信息。追踪中的关键细节可转化为指标，但查看追踪主要用于调试，而非性能概览。追踪数据可无缝收集到Google Cloud Trace等平台，通过可视化和海量检索简化根本原因分析。

重视人类反馈：指导自动化进程

人类反馈并非需要应对的麻烦，而是优化智能体最宝贵、数据最丰富的资源。当用户提交漏洞报告或点击“差评”按钮时，相当于提供了一份礼物——自动化评估场景中遗漏的真实边缘案例。收集和汇总这些数据至关重要：当类似报告或指标下滑达到统计显著水平时，需将其与分析平台关联，生成洞见并触发运营问题警报。有效的智能体运维流程通过“闭环管理”捕获反馈、复现问题，并将具体场景转化为评估数据集中永久的新测试用例——确保不仅修复当前漏洞，还能防范同类错误再次发生。

构建高质量智能体后，需使其能够与用户及其他智能体互联。延续前文身体部位类比，这相当于智能体的“面部”。需注意，智能体与数据/API的连接，与智能体之间的连接存在差异——智能体并非工具²⁶。假设你已为智能体配置好工具，接下来将探讨如何将智能体融入更广泛的生态系统。

智能体与人类

智能体与人类最常见的交互方式是通过用户界面。最简单的形式是聊天机器人：用户输入请求，作为后端服务的智能体处理后返回文本块。更高级的智能体可提供JSON等结构化数据，支持丰富的动态前端体验。人机协同（HITL）交互模式包括意图优化、目标扩展、确认和澄清请求。

计算机使用是一类特殊工具：语言模型可控制用户界面，通常需人类交互和监督。支持计算机使用的智能体可决定下一步最佳行动——导航至新页面、高亮特定按钮或预填充相关信息表单²⁷。

除智能体代表用户操作界面外，语言模型还能根据实时需求调整界面：可通过控制界面的工具（MCP UI）²⁸、同步客户端与智能体状态的专用界面消息系统（AG UI）²⁹，甚至生成定制界面的协议（A2UI）³⁰实现。

当然，人类交互并非局限于屏幕和键盘。高级智能体正突破文本限制，通过“实时模式（live mode）”实现多模态实时通信，建立更自然的类人连接。Gemini Live API³¹等技术支持双向流式传输，用户可与智能体对话并随时打断，如同自然交流一般。

这种能力从根本上改变了智能体与人类的协作模式：通过设备的摄像头和麦克风，智能体可“看到”用户所见、“听到”用户所说，并以接近人类对话的延迟生成语音响应。

这开启了众多文本交互无法实现的用例：技术人员维修设备时获得免手持指导、购物者获得实时风格建议等。智能体由此成为更直观、更易访问的协作伙伴。

智能体与智能体

正如智能体需与人类连接，它们之间也需相互协作。随着企业大规模应用AI，不同团队会构建不同的专业智能体。若无通用标准，连接这些智能体需构建复杂脆弱的定制API集成，难以维护。核心挑战有两点：发现（智能体如何找到其他智能体并了解其功能？）与通信（如何确保它们“语言互通”？）。

智能体间（A2A）协议是解决该问题的开放标准，相当于智能体生态的“通用握手协议”。A2A允许任意智能体发布数字“名片”（Agent Card）——包含智能体功能、网络端点和交互所需安全凭证的简单JSON文件，使发现过程标准化、简单化。与聚焦事务性请求的MCP不同，智能体间通信通常用于协同解决复杂问题。

发现后，智能体通过任务导向架构通信：不同于简单的请求-响应模式，交互以异步“任务”形式呈现。客户端智能体向服务器智能体发送任务请求，服务器智能体可通过长连接在处理过程中提供流式更新。这种稳健的标准化通信协议是实现协作式第3级多智能体系统的关键，将分散的智能体转化为真正可互操作的生态系统。

智能体与货币

随着AI智能体为人类处理更多任务，部分任务涉及购买、销售、谈判或促成交易。当前网络是为人类点击“购买”按钮设计的，责任由人类承担；而若自主智能体点击“购买”，则会引发信任危机——若出现问题，责任归属谁？这些涉及授权、真实性和问责制的复杂问题，需要新的标准支持智能体代表用户安全可靠地进行交易。

这一新兴领域尚未成熟，但两大关键协议正奠定基础：智能体支付协议（AP2）是专为智能体商业设计的开放协议，通过引入加密签名的数字“授权书”扩展A2A等协议，作为用户意图的可验证证明，为每笔交易创建不可否认的审计跟踪——使智能体能够基于用户委托权限，在全球范围内安全浏览、谈判和交易。与之互补的是x402协议，这一开放互联网支付协议利用标准HTTP 402“需要支付（Payment Required）”状态码，支持无摩擦的机器对机器微交易，使智能体能够按使用量支付API访问或数字内容等服务，无需复杂账户或订阅。这两大协议共同为智能体网络构建基础信任层。

要应对这一挑战，不能仅依赖AI模型的判断（其可能被提示注入等技术操纵³³），最佳实践是采用分层防御的混合模式³⁴：

第一层是传统的确定性防护栏——硬编码规则构成的安全关卡（独立于模型推理）。例如，政策引擎可阻止超过100美元的购买行为，或要求智能体与外部API交互前需获得用户明确确认。这一层为智能体的权力设定了可预测、可审计的硬性限制。

第二层是基于推理的防御——利用AI保障AI安全。包括训练模型增强抗攻击能力（对抗性训练），以及部署小型专用“防护模型”（类似安全分析师）：在智能体执行计划前，这些模型可审查其提议步骤，标记潜在风险或违反政策的行为供审核。这种结合代码刚性确定性与AI上下文感知能力的混合模式，为单个智能体构建了稳健的安全态势，确保其权力始终与目标一致。

智能体身份：一类新型主体

在传统安全模型中，人类用户通过OAuth或SSO认证，服务通过IAM或服务账户认证。智能体引入了第三类主体：它并非单纯的代码，而是自主行动者，需要独特的可验证身份。如同为员工发放工牌，平台上的每个智能体都应获得安全可验证的“数字护照”。

这种智能体身份独立于调用它的用户和构建它的开发者，是企业身份与访问管理（IAM）的根本性转变。

每个身份的验证及所有访问控制，是智能体安全的基石。一旦智能体获得加密可验证身份（通常采用SPIFFE³⁵等标准），即可被授予特定的最小权限：销售智能体（SalesAgent）获得CRM的读写权限，而人力资源入职智能体（HRonboardingAgent）则被明确拒绝。这种精细化控制至关重要——即使单个智能体被入侵或行为异常，也能控制潜在影响范围。若无智能体身份机制，智能体就无法代表人类行使有限委托权限。

（Table 1: A non-exhaustive example of different categories of actors for authentication）

限制访问的策略

策略是授权（AuthZ）的一种形式，区别于认证（AuthN）。通常，策略限制主体的能力，例如“营销部门用户仅能访问这27个API端点，且不能执行DELETE命令”。开发智能体时，需为智能体、工具、其他内部智能体、共享上下文及外部智能体设置权限。可以这样理解：当你为系统添加所有API、数据、工具和智能体后，必须将访问权限限制在完成任务所需的最小范围内——这是推荐做法：遵循最小权限原则，同时保持上下文相关性³⁶。

ADK智能体的安全防护

确立身份和策略的核心原则后，保护基于智能体开发工具包（ADK）构建的智能体，就转化为通过代码和配置应用这些概念的实际操作³⁷。

如前所述，该过程需明确身份定义：用户账户（如OAuth）、服务账户（运行代码）、智能体身份（行使委托权限）。完成认证后，下一层防御是制定限制服务访问的策略——通常在API治理层实现，同时为MCP和A2A服务提供治理支持。

再下一层是在工具、模型和子智能体中构建防护栏以执行策略：无论语言模型如何推理或恶意提示如何诱导，工具自身逻辑都将拒绝执行不安全或违反政策的操作。这种方式提供了可预测、可审计的安全基线，将抽象安全政策转化为具体可靠的代码³⁸。

为实现适应智能体运行时行为的动态安全，ADK提供了回调（Callbacks）和插件（Plugins）：before_tool_callback允许在工具运行前检查其参数，根据智能体现有状态验证以防止不一致行为；对于更具复用性的政策，可构建插件——常见模式是“Gemini评估器（Gemini as a Judge）”³⁹，利用Gemini Flash-Lite等快速低成本模型或自定义微调的Gemma模型，实时筛查用户输入和智能体输出，防范提示注入或有害内容。

对于倾向于通过托管服务实现这些动态检查的企业，可将Model Armor作为可选服务集成。Model Armor作为专用安全层，筛查提示和响应中的各类威胁，包括提示注入、越狱尝试、敏感数据（PII）泄露和恶意URL⁴⁰。将这些复杂安全任务外包给专用服务，可使开发者无需自行构建和维护防护栏，就能确保一致、稳健的保护。ADK中的这种混合模式——结合强大身份认证、确定性工具内逻辑、动态AI防护栏和可选托管服务（如Model Armor），能够构建既强大又可信的单个智能体。

（Figure 6: Security and Agents from https://saif.google/focus-on-agents）

安全与隐私：加固智能体前沿防线

企业级平台必须应对生成式AI特有的安全和隐私挑战，即使仅运行单个智能体也是如此。智能体本身成为新的攻击面：恶意攻击者可能尝试通过提示注入劫持智能体指令，或通过数据投毒破坏其训练或检索增强生成（RAG）所使用的信息；此外，约束不足的智能体可能在响应中意外泄露敏感客户数据或专有信息。

稳健的平台通过分层防御策略缓解这些风险：从数据层面入手，确保企业专有信息不会用于基础模型训练，并通过VPC服务控制等措施提供保护；实现输入输出过滤，如同提示和响应的防火墙；最后，平台需为训练数据和生成输出提供知识产权保障等合同条款，让企业在部署智能体时获得法律和技术层面的双重信心。

智能体治理：以控制平面替代无序扩张

随着智能体及其工具在企业内扩散，会形成复杂的交互网络和潜在漏洞——这一挑战被称为“智能体无序扩张（agent sprawl）”。管理这一问题需要超越单个智能体安全防护，采用更高阶的架构方法：建立作为所有智能体活动控制平面的中央网关。

想象一个繁华都市，数千辆自主车辆（用户、智能体、工具）有序移动。若无交通灯、车牌和中央控制系统，必将陷入混乱。网关模式正是构建这样的控制系统——为所有智能体流量设立强制入口，包括用户与智能体的提示或界面交互、智能体与工具的调用（通过MCP）、智能体之间的协作（通过A2A），以及对语言模型的直接推理请求。通过位于这一关键节点，企业可检查、路由、监控和管理每一次交互。

该控制平面承担两大核心关联功能：

1. 运行时政策执行：作为实施安全策略的架构关卡，处理认证（“我是否认识该行动者？”）和授权（“他们是否有权执行该操作？”）。集中式执行提供了“单一可视化面板”的可观测性，为每笔交易生成统一日志、指标和追踪——将分散的智能体和工作流转化为透明可审计的系统。
2. 集中式治理：要有效执行政策，网关需要单一真实来源——即企业智能体和工具的中央注册表（类似应用商店）。该注册表允许开发者发现和复用现有资产，避免重复工作，同时让管理员掌握完整资产清单；更重要的是，它为智能体和工具提供了正式生命周期管理——发布前安全审核、版本控制，以及制定细分政策（明确哪些业务部门可访问哪些智能体）。

通过将运行时网关与中央治理注册表结合，企业可将智能体无序扩张的风险转化为可管理、安全高效的生态系统。

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

最终，企业级智能体必须既可靠又具成本效益。频繁故障或响应缓慢的智能体投资回报率为负；反之，成本过高的智能体无法规模化满足业务需求。底层基础设施必须设计为在安全合规、数据主权合规的前提下，平衡可靠性与成本。

在某些场景中，需具备“零扩展（scale-to-zero）”能力——针对特定智能体或子功能的非规律性流量；对于关键任务、低延迟负载，平台需提供专用保障容量，如语言模型服务的预配置吞吐量（Provisioned Throughput）⁴¹或Cloud Run等运行时的99.9%服务等级协议（SLAs）⁴²。这确保了最重要的智能体即使在高负载下也能保持可预测的性能。通过提供多样化的基础设施选项，并结合成本和性能的全面监控，可为智能体从创新原型向企业核心可靠组件的演进，奠定最终的关键基础。

部署在现实世界中的智能体，需在政策、技术和数据格式不断变化的动态环境中运行。若无适应能力，智能体性能将随时间退化（这一过程称为“老化”），导致实用性和可信度丧失。手动更新大规模智能体集群以跟上变化既不经济也不高效，更具扩展性的解决方案是设计能够自主学习和进化的智能体——在工作中持续提升质量，同时最大限度减少工程投入⁴³。

智能体如何学习与自我进化

与人类类似，智能体从经验和外部信号中学习。学习过程由多种信息源驱动：

• 运行时经验：智能体从会话日志、追踪数据和记忆等运行时工件中学习，这些数据记录了成功案例、失败经历、工具交互和决策轨迹。其中，人机协同（HITL）反馈尤为重要，提供了权威的修正和指导。
• 外部信号：新的外部文档（如更新后的企业政策、公共监管指南）或其他智能体的评论，也能驱动学习过程。

这些信息被用于优化智能体的未来行为。高级系统并非简单总结过往交互，而是创建可泛化的工件指导未来任务。最成功的适配技术分为两类：

• 增强型上下文工程：系统持续优化提示、少样本示例和从记忆中检索的信息，通过为每个任务优化提供给语言模型的上下文，提高成功概率。
• 工具优化与创建：智能体的推理能力可识别自身能力缺口并采取行动填补——获取新工具、实时创建新工具（如Python脚本），或修改现有工具（如更新API架构）。

其他优化技术（如动态重新配置多智能体设计模式、基于人类反馈的强化学习（RLHF））仍处于活跃研究阶段。

示例：学习新合规指南

以金融或生命科学等高度监管行业的企业智能体为例，其任务是生成符合隐私和监管规则（如GDPR）的报告。

这可通过多智能体工作流实现：

1. 查询智能体（Querying Agent）响应用户请求检索原始数据。
2. 报告智能体（Reporting Agent）将数据整合为报告草稿。
3. 评论智能体（Critiquing Agent）基于已知合规指南审核报告，若遇歧义或需最终签字确认，则上报给人类领域专家。
4. 学习智能体（Learning Agent）观察整个交互过程，重点关注人类专家的修正反馈，将其泛化为可复用的新指南（如更新评论智能体的规则或优化报告智能体的上下文）。

（Figure 7: Sample multi agent workflow for compliance guidelines）

例如，若人类专家指出某些家庭统计数据必须匿名化，学习智能体将记录这一修正。下次生成类似报告时，评论智能体将自动应用这一新规则，减少人类干预需求。这种“评论-人类反馈-泛化”循环，使系统能够自主适应不断变化的合规要求⁴⁴。

模拟与智能体训练平台（Agent Gym）——下一个前沿领域

我们提出的设计模式可归类为“在线学习（in-line learning）”——智能体利用自身设计模式和资源进行学习。目前，更高级的研究方向是构建专用平台，通过离线流程优化多智能体系统，配备运行时环境中不具备的高级工具和能力。这类智能体训练平台（Agent Gym）⁴⁵的核心特征包括：

1. 独立于执行路径：作为独立的离线生产平台，可接入任意语言模型、离线工具和云应用等资源。
2. 提供模拟环境：智能体可在新数据上“练习”和学习，该环境适用于多优化路径的“试错”训练。
3. 支持高级合成数据生成：引导模拟尽可能贴近现实，对智能体进行压力测试（包括红队测试、动态评估和评论智能体集群等高级技术）。
4. 优化工具库可扩展：可通过MCP或A2A等开放协议接入新工具，或在更高级场景中学习新概念并围绕其构建工具。
5. 连接人类专家网络：面对企业中常见的“隐性知识（tribal knowledge）”相关边缘案例，智能体训练平台可连接领域专家网络，咨询合适的结果以指导后续优化。

谷歌协研智能体（Google Co-Scientist）

协研智能体（Co-Scientist）是一款高级AI智能体，定位为虚拟研究协作伙伴，通过系统探索复杂问题空间加速科学发现。研究人员可定义目标、为智能体提供指定的公共和专有知识源，随后智能体将生成并评估一系列新假设。

为实现这一目标，协研智能体将构建完整的智能体生态系统协同工作。

（Figure 8: The AI co-scientist design system）

可将该系统视为研究项目经理：AI首先接收宽泛的研究目标并制定详细项目计划，随后“主管智能体（Supervisor）”担任管理者角色，将任务委派给专业智能体团队，并分配计算资源等支持。这种结构确保项目可轻松扩展，且团队方法在迈向最终目标的过程中持续优化。

（Figure 9: Co-scientist multi agent workflow）

各类智能体将持续工作数小时甚至数天，不断优化生成的假设，通过循环和元循环不仅改进生成的想法，还优化判断和创造新想法的方式。

阿尔法进化智能体（AlphaEvolve Agent）

另一款高级智能体系统是阿尔法进化智能体（AlphaEvolve），它专为发现和优化数学与计算机科学复杂问题的算法而设计。

阿尔法进化智能体通过融合Gemini语言模型的创造性代码生成能力与自动化评估系统实现功能：AI生成潜在解决方案，评估器为其评分，最有前景的想法将作为下一代代码的灵感来源——这一进化过程已取得多项重大突破：

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

阿尔法进化智能体擅长处理“验证解决方案质量易、发现解决方案难”的问题。

（Figure 10: Alpha Evolve design system）

阿尔法进化智能体旨在实现人类与AI的深度迭代协作，这种协作主要通过两种方式实现：

• 透明解决方案：AI以人类可读的代码形式生成解决方案，透明度使用户能够理解逻辑、获得洞见、信任结果，并根据需求直接修改代码。
• 专家指导：人类专业知识在问题定义中至关重要。用户通过优化评估指标和引导探索方向指导AI，避免系统利用问题定义中的非预期漏洞——这种交互式循环确保最终解决方案既强大又实用。

该智能体的最终成果是持续优化的代码，不断提升人类设定的指标。

（Figure 11: Algorithm evolution）

生成式AI智能体标志着人工智能的关键演进——从被动的内Agent 智能体容创作工具，转变为主动自主的问题解决协作伙伴。本文提供了理解和构建这类系统的正式框架，助力从原型验证迈向可靠的生产级架构。

我们已将智能体拆解为三大核心组件：推理模型（大脑）、可执行工具（双手）与管控编排层（神经系统）。正是这些组件的无缝集成，通过持续的“思考-行动-观察”循环，释放了智能体的真正潜力。通过对智能体系统的分类——从第1级互联问题解决者到第3级协作式多智能体系统，架构师和产品负责人可根据任务复杂度，战略性地设定目标。

核心挑战与机遇在于新的开发者范式：我们不再是定义明确逻辑的“砌砖工”，而是引导、约束和调试自主实体的“架构师”与“导演”。语言模型的灵活性既是其强大之处，也是其不可靠的根源。因此，成功不仅取决于初始提示，更在于对整个系统的工程严谨性——稳健的工具契约、弹性错误处理、复杂上下文管理和全面评估。

本文概述的原则和架构模式构成了基础蓝图，为探索这一软件新前沿提供了指引，助力我们构建的不仅是“工作流自动化工具”，更是真正协作、高效、适应能力强的“团队新成员”。随着技术成熟，这种严谨的架构方法将成为充分释放智能体AI全部潜力的决定性因素。

1. 朱莉娅·维辛格（Julia Wiesinger）、帕特里克·马洛（Patrick Marlow）等，2024年，《智能体（Agents）》，详见：https://www.kaggle.com/whitepaper-agents。
2. 安东尼奥·古利（Antonio Gulli）、拉维·尼加姆（Lavi Nigam）等，2025年，《智能体配套指南（Agents Companion）》，详见：https://www.kaggle.com/whitepaper-agent-companion。
3. 姚顺宇（Shunyu Yao）等，2022年，《反应式推理（ReAct）：语言模型中推理与行动的协同》，详见：https://arxiv.org/abs/2210.03629。
4. 魏杰（Wei, J.）、王晓等，2023年，《思维链提示（Chain-of-Thought Prompting）：激发大语言模型的推理能力》，详见：https://arxiv.org/pdf/2201.11903.pdf。
5. 姚顺宇（Shunyu Yao）等，2022年，《反应式推理（ReAct）：语言模型中推理与行动的协同》，详见：https://arxiv.org/abs/2210.03629。
6. 详见：https://www.amazon.com/Agentic-Design-Patterns-Hands-Intelligent/dp/
7. 姚顺宇（Shunyu Yao）等，2024年，《τ基准测试（τ-bench）：现实世界领域中工具-智能体-用户交互基准》，详见：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?e=&hl=en
12. 详见：https://cloud.google.com/speech-to-text?e=&hl=en
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年，《生产环境中的生成式AI：MLOps还是GenAIOps？》，详见：https://medium.com/google-cloud/genai-in-production-mlops-or-genaiops-25691c9becd0。
25. 刘光亚（Guangya Liu）、苏杰·所罗门（Sujay Solomon），2025年3月，《AI智能体可观测性——演进中的标准与最佳实践》，详见：https://opentelemetry.io/blog/2025/ai-agent-observability/.
26. 详见：https://discuss.google.dev/t/agents-are-not-tools/
27. 达米恩·马松（Damien Masson）等，2024年，《DirectGPT：与大语言模型交互的直接操作界面》，详见：https://arxiv.org/abs/2310.03691。
28. MCP UI是通过MCP工具控制界面的系统，详见：https://mcpui.dev/.
29. AG UI是通过事件传递（可选共享状态）控制界面的协议，详见：https://ag-ui.com/.
30. A2UI是通过结构化输出和A2A消息传递生成界面的协议，详见：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.proxy.ustclug.org/gweb-research2023-media/pubtools/.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）等，2025年，《借助AI协研智能体加速科学突破》，详见：https://research.google/blog/accelerating-scientific-breakthroughs-with-an-ai-co-scientist/.
45. 迪帕克·纳塔尼（Deepak Nathani）等，2025年，《MLGym：推进AI研究智能体的新框架与基准》，详见：https://arxiv.org/abs/2502.14499.