Google 白皮书 - Introduction to Agents

From Predictive AI to Autonomous Agents

核心解构：将智能体解构为三个基本组成部分：推理模型（Model）、可执行工具（Tools）和管控编排层（Orchestration Layer）
能力分类体系：将智能体从简单的联网解题者分类到复杂的协作多智能体系统
架构设计：深入探讨每个组件的实际设计考量，从模型选择到工具实现
生产环境构建：建立必要的智能体运维（Agent Ops）规范，以便评估、调试、保护和扩展智能体系统，实现从单实例到具备企业级治理的集群化管理
语言往往不足以描述人类如何与 AI 互动。我们倾向于将其拟人化，使用诸如“思考”、“推理”和“知道”等人类术语。我们尚无词汇来区分“具有语义理解的知道”与“基于最大化奖励函数的高概率知道”

这是两种不同类型的“知道”，但在 99.X% 的情况下，其结果是相同的

Introduction to AI Agents

AI 智能体可以定义为模型、工具、编排层和运行时服务的组合，它在一个循环中使用语言模型（LM）来达成目标

模型（“大脑”）：作为智能体核心推理引擎的核心语言模型（LM）或基础模型，用于处理信息、评估选项并做出决策。模型的类型（通用、微调或多模态）决定了智能体的认知能力

智能体系统是语言模型输入上下文窗口（context window）的最终管理者

工具（“双手”）：这些机制将智能体的推理能力与外部世界连接起来，使其能够执行文本生成以外的操作。它们包括 API 扩展、代码函数和数据存储（如数据库或向量存储），用于访问实时的、事实性的信息

智能体系统允许语言模型规划使用哪些工具，执行该工具，并将工具的运行结果放入下一次语言模型调用的输入上下文窗口中

编排层（“神经系统”）：管理智能体运行循环的管控流程。它处理规划、记忆（状态）和推理策略的执行。该层使用提示框架和推理技术（如思维链 Chain-of-Thought 或 ReAct）将复杂目标分解为步骤，并决定何时进行思考以及何时使用工具。该层还负责赋予智能体“记忆”的能力
部署（“躯体与双腿”）：虽然在笔记本电脑上构建智能体对于原型设计很有效，但生产部署才是使其成为可靠且可访问服务的关键。这涉及将智能体托管在安全、可扩展的服务器上，并将其与用于监控、日志记录和管理的必要生产服务集成

一旦部署，用户可以通过图形界面访问智能体，或者其他智能体可以通过智能体对智能体（A2A）API 以编程方式访问它

归根结底，构建生成式 AI 智能体是一种开发解决方案以完成任务的新方式。传统的开发者充当“砌砖工”，精确定义每一个逻辑步骤

相比之下，智能体开发者更像是一位导演。你不再为每一个动作编写显式代码，而是设定场景（指导指令和提示词），挑选演员（工具和 API），并提供必要的背景（数据）。主要任务变成了引导这位自主的“演员”来呈现预期的表现

你很快会发现，语言模型最大的优势——其惊人的灵活性——也是你最大的头痛来源。大语言模型无所不能的能力，使得强迫它可靠且完美地做一件具体的事情变得困难

我们过去称之为“提示工程（Prompt Engineering）”，现在称为“上下文工程（Context Engineering）”，旨在引导语言模型生成预期的输出
对于语言模型的任何一次单次调用，我们输入指令、事实、可调用的工具、示例、会话历史、用户画像等——用恰到好处的信息填充上下文窗口，以获得我们需要的结果。智能体本质上就是管理语言模型输入以完成工作的软件

当问题出现时，调试变得至关重要。“智能体运维（Agent Ops）”本质上重新定义了测量、分析和系统优化的熟悉周期

通过链路追踪（traces）和日志，你可以监控智能体的“思维过程”，识别其与预期执行路径的偏差
随着模型的发展和框架的改进，开发者的角色转变为提供关键组件：领域专业知识、定义明确的个性（Persona），以及与完成实际任务所需工具的无缝集成
必须记住，全面的评估和考核往往比初始提示词的影响更为重要

当一个智能体被精确配置了清晰的指令、可靠的工具、作为记忆的集成上下文、优秀的用户界面、规划和解决问题的能力以及通用的世界知识时，它就超越了单纯的“工作流自动化”概念

它开始作为一个协作实体发挥作用：成为你团队中一位高效、独特适应性强且能力非凡的新成员

本质上，智能体是一个致力于“上下文窗口策展”艺术的系统。它是一个持续不断的循环：组装上下文、提示模型、观察结果，然后为下一步重新组装上下文

上下文可能包括系统指令、用户输入、会话历史、长期记忆、来自权威来源的基础知识（Grounding Knowledge）、可用工具以及已调用工具的结果
这种对模型注意力的复杂管理，使其推理能力能够解决新奇情况下的问题并达成目标

The Agentic Problem-Solving Process

AI 智能体定义为一个完整的、面向目标的应用程序，集成了推理模型、可执行工具和管控编排层。简而言之，就是“语言模型在循环中利用工具来达成目标”
其核心，智能体通过一个连续的、循环的过程来实现其目标。虽然这个循环可能会变得非常复杂，它可以分解为五个基本步骤

接收任务（Get the Mission）：过程由一个具体的高层目标启动。该任务由用户提供（例如，“为即将到来的会议安排我团队的行程”）或由自动触发器提供（例如，“收到一个新的高优先级客户工单”）
扫描场景（Scan the Scene）：智能体感知环境以收集上下文。这涉及编排层访问其可用资源：“用户的请求说了什么？”，“我的短期记忆里有什么信息？我之前尝试过这个任务吗？用户上周给过我指导吗？”，“我可以通过工具（如日历、数据库或 API）访问什么？”
深入思考（Think It Through）：这是智能体核心的“思考”循环，由推理模型驱动。智能体结合场景（第2步）分析任务（第1步）并制定计划。这通常不是单一的念头，而是一条推理链（Chain of Reasoning）：“要预订行程，我首先需要知道团队里有谁。我将使用 get_team_roster 工具。然后我需要通过 calendar_api 检查他们的空闲时间”
采取行动（Take Action）：编排层执行计划的第一个具体步骤。它选择并调用适当的工具——调用 API、运行代码函数或查询数据库。这是智能体在其内部推理之外对世界采取的行动。
观察并迭代（Observe and Iterate）：智能体观察其行动的结果。get_team_roster 工具返回了一个包含五个名字的列表。这一新信息被添加到智能体的上下文或“记忆”中。然后循环重复，回到第3步：“既然我已经有了名册，我的下一步是检查这五个人的日历。我将使用 calendar_api”
观察并迭代（Observe and Iterate）：智能体观察其行动的结果。get_team_roster 工具返回了一个包含五个名字的列表。这一新信息被添加到智能体的上下文或“记忆”中。然后循环重复，回到第3步：“既然我已经有了名册，我的下一步是检查这五个人的日历。我将使用 calendar_api”

A Taxonomy of Agentic Systems

Level 0：核心推理系统

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

Level 1：联网的解题者

在这个层级，推理引擎通过连接并利用外部工具——即我们架构中的“双手”组件——变成了一个功能性智能体。其解决问题的能力不再局限于其静态的预训练知识
利用 5 步循环，智能体现在可以回答我们之前的问题了。给定“任务”：“昨晚洋基队比赛的最终比分是多少？”，其“思考”步骤识别出这是实时的信息需求。其“行动”步骤随即调用工具，例如带有正确日期和搜索词的 Google 搜索 API。它“观察”搜索结果（例如，“洋基队 5-3 获胜”），并将该事实综合成最终答案
这种与世界互动的基本能力——无论是使用搜索工具查询比分、使用金融 API 获取实时股价，还是通过检索增强生成（RAG）查询数据库——是 1 级智能体的核心能力

Level 2：战略性解题者

2 级标志着能力的显著扩展，从执行简单任务转向战略性地规划复杂的、由多部分构成的目标。这里出现的关键技能是上下文工程（Context Engineering）：智能体能够为计划的每一步主动选择、打包和管理最相关的信息
例如，考虑这个“任务”：“在我位于山景城 1600 Amphitheatre Parkway 的办公室和客户位于旧金山 1 Market St 的办公室之间，找一家好的咖啡店。”
2 级智能体将开始制定计划：

思考：“我必须先找到中间点。”

行动：使用两个地址调用地图工具。

观察：“中间点是加利福尼亚州的米尔布雷（Millbrae）。”

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

行动：调用 google_places 工具，查询参数为 query="coffee shop in Millbrae, CA", min_rating=4.0。（这就是上下文工程——它根据上一步的输出自动创建了一个新的、聚焦的搜索查询）

观察：“搜索结果返回 'Millbrae Coffee' 和 'The Daily Grind'

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

这种战略规划还使主动协助成为可能，例如智能体可以读取一封冗长的航班确认邮件，提取关键上下文（航班号、日期），并采取行动将其添加到你的日历中

Level 3：协作多智能体系统

在最高层级，范式完全转变。我们不再致力于构建单一、全能的“超级智能体”，而是转向协同工作的“专家团队”，这种模式直接反映了人类组织的运作方式。系统的集体力量在于这种分工
在这里，智能体将其他智能体视为工具。想象一下一个“项目经理”智能体接收到一个“任务”：“发布我们的新款‘Solaris’耳机。”
项目经理智能体不会自己完成所有工作。它通过为其专业智能体团队创建新任务来采取行动，就像在现实生活中一样

委派给 市场研究智能体（MarketResearchAgent）：“分析降噪耳机的竞争对手定价。明天之前提交一份总结文档。”
委派给 营销智能体（MarketingAgent）：“使用‘Solaris’产品规格表作为上下文，起草三个版本的新闻稿。”
委派给 Web开发智能体（WebDevAgent）：“根据附带的设计模型生成新产品页面的 HTML。”

这种协作模式虽然目前受到当今语言模型推理局限性的制约，但它代表了从头到尾自动化整个复杂业务工作流的前沿方向

Level 4：自我进化系统

4 级代表了从委派到自主创造和适应的巨大飞跃。在这个层级，智能体系统可以识别自身能力的差距，并动态创建新工具甚至新智能体来填补这些空白。它从使用固定的资源集转变为主动扩展资源
沿用我们的例子，负责‘Solaris’发布的“项目经理”智能体可能会意识到它需要监控社交媒体情绪，但其团队中不存在此类工具或智能体

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

行动（自主创造）：它没有失败，而是调用一个高级的 AgentCreator 工具并下达新任务：“构建一个新的智能体，监控社交媒体上关键字‘Solaris headphones’，执行情感分析，并报告每日摘要。”

观察：一个新的、专门的 SentimentAnalysisAgent（情感分析智能体）被即时创建、测试并添加到团队中，准备为原始任务做出贡献

这种系统能够动态扩展自身能力的自主水平，将智能体团队变成了一个真正具备学习和进化能力的组织

Core Agent Architecture: Model, Tools, and Orchestration

我们知道了智能体做什么以及它如何扩展。但我们实际上如何构建它呢？从概念到代码的转变在于其三个核心组件的具体架构设计
Model: The “Brain” of your AI Agent

语言模型是智能体的推理核心，其选择是一个关键的架构决策，决定了智能体的认知能力、运营成本和速度

然而，将这一选择简单地视为挑选基准测试分数最高的模型，是通往失败的常见路径。智能体在生产环境中的成功很少由通用的学术基准决定

现实世界的成功要求模型在智能体基础能力方面表现出色：具备卓越的推理能力以应对复杂、多步骤的问题，以及可靠的工具使用能力以与世界互动
要做好这一点，首先要定义业务问题，然后针对直接映射到该结果的指标测试模型

如果你的智能体需要编写代码，请在你的私有代码库上测试它
如果它处理保险理赔，请评估其从你特定文档格式中提取信息的能力
然后，必须将此分析与成本和延迟的实际情况进行交叉参考。对于你的特定任务而言，“最佳”模型是位于质量、速度和价格最佳交汇点的那一个

你可以选择不止一个模型，组建一支“专家团队”。杀鸡焉用牛刀。

一个稳健的智能体架构可能会使用像 Gemini 2.5 Pro 这样的前沿模型来承担初始规划和复杂推理的繁重任务
然后智能地将更简单、高频的任务——如分类用户意图或总结文本——路由给像 Gemini 2.5 Flash 这样速度更快、更具成本效益的模型
模型路由可以是自动的或硬编码的，但它是优化性能和成本的关键策略

同样的原则也适用于处理多种数据类型

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

最后，AI 领域正处于持续、快速的演进状态。你今天选择的模型将在六个月内被取代

“一劳永逸”的心态是不可持续的。针对这一现实进行构建意味着投资于一个灵活的运营框架——即“智能体运维（Agent Ops）”实践
凭借强大的 CI/CD 流水线，针对你的关键业务指标持续评估新模型，你可以降低风险并加速升级，确保你的智能体始终由可用的最强大脑驱动，而无需进行彻底的架构重构

Tools: The "Hands" of your AI Agent

如果模型是智能体的大脑，那么工具就是将其推理连接到现实的双手。它们允许智能体超越其静态训练数据，检索实时信息并在世界上采取行动

一个稳健的工具接口是一个三部分循环：定义工具能做什么，调用它，并观察结果

检索信息：扎根于现实

最基础的工具是访问最新信息的能力

检索增强生成（RAG）为智能体提供了一张“借书证”，用于查询外部知识，这些知识通常存储在向量数据库或知识图谱中，范围从内部公司文档到通过 Google 搜索获取的网络知识
对于结构化数据，自然语言转 SQL（NL2SQL）工具允许智能体查询数据库以回答分析性问题，例如“上个季度我们最畅销的产品是什么？”
通过在发言前进行查阅——无论是在文档中还是在数据库中——智能体将自身建立在事实基础之上，从而大幅减少幻觉

执行动作：改变世界

当智能体从读取信息转向主动做事时，其真正的力量才得以释放

通过将现有的 API 和代码函数封装为工具，智能体可以发送电子邮件、安排会议或更新 ServiceNow 中的客户记录
对于更动态的任务，智能体可以即时编写并执行代码。在安全的沙箱中，它可以生成 SQL 查询或 Python 脚本来解决复杂问题或执行计算，从而将其从知识渊博的助手转变为自主的行动者

这也包括用于人机交互的工具

智能体可以使用人在回路（HITL）工具暂停其工作流并请求确认（例如 ask_for_confirmation()），或从用户界面请求特定信息（例如 ask_for_date_input()），确保人类参与关键决策
HITL 可以通过 SMS 短信和数据库中的任务来实现

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

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

The Orchestration Layer

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

首要的架构决策是确定智能体的自主程度

这种选择存在于一个谱系上
在一端，你有确定性的、可预测的工作流，它们将语言模型作为工具调用以完成特定任务——用一点 AI 来增强现有流程
在另一端，语言模型处于驾驶座位置，动态地适应、规划和执行任务以达成目标

与之并行的选择是实现方法

无代码构建器提供速度和易用性，授权业务用户自动化结构化任务并快速构建简单的智能体
对于更复杂、任务关键型系统，代码优先（Code-first）的框架，如 Google 的智能体开发套件（ADK），提供了工程师所需的深度控制、可定制性和集成能力

无论采用哪种方法，生产级框架都是必不可少的

它必须是开放的，允许你插入任何模型或工具以防止供应商锁定
它必须提供精确的控制，支持混合方法，即语言模型的非确定性推理受硬编码的业务规则管辖

在构建 AI 智能体（Agent）系统时，不能完全信任大模型（LLM）的“自由发挥”，必须用传统的、写死的代码逻辑（硬编码规则）给它套上“紧箍咒”，作为最后的防线
LLM 的特性（非确定性）： 大语言模型本质上是概率模型。你问它同一个问题，它可能会给出不同的回答。它富有创造力，能理解自然语言，但也容易“一本正经地胡说八道”（幻觉），或者因为被用户误导而试图执行违规操作
业务的需求（确定性）： 在商业环境中，很多规则是绝对的、黑白分明的。例如：银行转账余额不足绝对不能转、非管理员绝对不能删除数据库、退货超过30天绝对不能退
“混合方法”就是利用 LLM 的理解能力去处理复杂的对话和意图，但利用代码的执行能力去守住底线
Step 1：模型思考（AI） -> 用户说“我要转账 100 万给张三”。LLM 分析意图，决定调用 transfer_money 工具。
Step 2：规则审查（硬编码） -> （这里就是“管辖”发生的地方） 框架在真正执行转账函数之前，先运行一段写死的 if/else 代码：

Check 1: 用户余额是否 > 100万？
Check 2: 单日转账限额是否允许？
Check 3: 收款人是否在黑名单？

Step 3：执行或驳回 -> 如果规则检查不通过，框架直接告诉 LLM：“操作被拒绝，原因：余额不足”。此时，LLM 只能根据这个硬性结果回复用户，而不能自己编造转账成功的谎言

最重要的是，该框架必须为可观测性而构建。当智能体行为异常时，你不能简单地在模型的“思想”中设置断点
一个稳健的框架会生成详细的链路追踪（traces）和日志，展示整个推理轨迹：模型的内心独白、它选择的工具、它生成的参数以及它观察到的结果

注入领域知识与设定人设

在这个框架内，开发者最有力的杠杆是用领域知识和鲜明的人设（Persona）来指导智能体。这是通过系统提示词（System Prompt）或一组核心指令来完成的。这不仅仅是一个简单的命令；它是智能体的宪法
在这里，你告诉它：你是 Acme Corp 的一名乐于助人的客户支持智能体，...，并提供约束条件、期望的输出模式、交互规则、特定的语气，以及关于何时以及为何应该使用其工具的明确指导。指令中的几个示例场景通常非常有效

利用上下文增强

短期记忆是智能体活跃的“草稿本”，维护当前对话的运行历史

它追踪正在进行的循环中的（行动，观察）对序列，提供模型决定下一步行动所需的即时上下文。这可以通过状态、工件（artifacts）、会话或线程等抽象概念来实现

长期记忆提供跨会话的持久性

在架构上，这几乎总是作为另一个专用工具来实现——连接到向量数据库或搜索引擎的 RAG 系统
编排器赋予智能体预取和主动查询其自身历史的能力，使其能够“记住”用户的偏好或几周前类似任务的结果，从而提供真正个性化和连续的体验

多智能体系统与设计模式

随着任务复杂性的增加，构建单一、全能的“超级智能体”变得低效

更有效的解决方案是采用“专家团队”的方法，这反映了人类组织的运作模式
这是多智能体系统的核心：一个复杂的过程被分割成离散的子任务，每个子任务被分配给一个专门的、特化的 AI 智能体
这种分工使得每个智能体更简单、更专注，且更容易构建、测试和维护，这对于动态或长期运行的业务流程是理想的选择

架构师可以依赖经过验证的智能体设计模式，尽管智能体能力及其模式正在迅速演变
对于动态或非线性任务，协调者（Coordinator）模式至关重要

它引入了一个“经理”智能体，负责分析复杂请求，分割主要任务，并将每个子任务智能地路由给适当的专家智能体（如研究员、作家或程序员）
然后，协调者汇总是来自每位专家的响应，以制定最终的、全面的答案

对于更线性的工作流，顺序（Sequential）模式更为合适

它就像一条数字装配线，一个智能体的输出直接成为下一个智能体的输入

其他关键模式侧重于质量和安全
迭代优化（Iterative Refinement）模式创建了一个反馈循环

使用“生成器”智能体创建内容，并使用“批评家”智能体根据质量标准对其进行评估

对于高风险任务，人在回路（HITL）模式至关重要，它在工作流中创建一个故意的暂停，以便在智能体采取重大行动之前获得人员批准

Agent Deployment and Services

在构建了本地智能体后，你会希望将其部署到服务器上，使其能够持续运行并供其他人或智能体使用

继续我们的类比，部署和服务将是我们智能体的躯体和双腿。智能体需要多种服务才能有效运行，包括会话历史、记忆持久化等
作为智能体构建者，你还要负责决定记录什么日志，以及为数据隐私、数据驻留和监管合规采取什么安全措施。当将智能体部署到生产环境时，所有这些服务都在考虑范围内

幸运的是，智能体构建者可以依赖数十年的应用托管基础设施

毕竟智能体是一种新形式的软件，许多相同的原则依然适用
构建者可以依赖专门构建的、针对智能体的部署选项，如 Vertex AI Agent Engine，它在一个平台上支持运行时及其他所有功能
对于希望更直接地控制其应用栈，或在其现有 DevOps 基础设施内部署智能体的软件开发者来说，任何智能体和大多数智能体服务都可以添加到 Docker 容器中，并部署到像 Cloud Run 或 GKE 这样的行业标准运行时上

如果你不是软件开发者或 DevOps 专家，部署第一个智能体的过程可能会令人生畏

许多智能体框架通过 deploy 命令或专用平台简化了这一过程，这些应主要用于早期探索和上手。升级到安全且生产就绪的环境通常需要更多的时间投入和最佳实践的应用，包括为你的智能体建立 CI/CD 和自动化测试

Agent Ops: A Structured Approach to the Unpredictable（应对不可预测性的结构化方法）

当你构建第一个智能体时，你会一遍又一遍地手动测试其行为。当你添加一个功能时，它能工作吗？当你修复一个错误时，是否引发了另一个问题？测试对于软件开发来说是常态，但在生成式 AI 中，其工作方式有所不同
从传统的、确定性的软件过渡到随机的（Stochastic）、智能体系统需要一种新的运维哲学

传统的软件单元测试可以简单地断言 output == expected；但这在智能体的响应本质上是概率性的情况下行不通
此外，由于语言的复杂性，通常需要一个语言模型来评估“质量”——即智能体的响应是否做到了它应该做的一切，没有做它不该做的，并且语气得当
智能体运维（Agent Ops） 是管理这种新现实的纪律严明、结构化的方法。它是 DevOps 和 MLOps 的自然演进，专为构建、部署和治理 AI 智能体的独特挑战而定制，将不可预测性从一种负担转变为一种可管理、可测量和可靠的特性

衡量关键指标：像 A/B 实验一样检测成功

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

注重质量而非通过/失败：使用语言模型作为裁判

业务指标无法告诉你智能体的行为是否正确。由于简单的通过/失败判定是不可能的，我们转向使用“语言模型作为裁判（LM as Judge）”来评估质量

这涉及使用一个强大的模型根据预定义的标准评估智能体的输出：它给出了正确的答案吗？回答是否有事实依据？它遵循指令了吗？针对黄金数据集提示运行的这种自动评估，提供了一致的质量衡量标准

创建评估数据集——包括理想（或“黄金”）问题和正确回答——可能是一个乏味的过程

为了构建这些数据集，你应该从现有的生产或开发交互中抽取场景样本。数据集必须涵盖你预期用户会涉及的所有用例，外加一些意想不到的用例
虽然在评估上的投资回报很快，但评估结果在被接受为有效之前，应始终由领域专家进行审查。日益增加的是，这些评估的策划和维护正成为产品经理在领域专家支持下的关键职责

指标驱动开发：部署的通过/不通过依据

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

使用 OpenTelemetry 链路追踪调试：回答“为什么？”

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

珍视人类反馈：指导你的自动化

人类反馈不是需要处理的麻烦；它是你改进智能体所拥有的最有价值、数据最丰富的资源
当用户提交错误报告或点击“踩”按钮时，他们是在给你一份礼物：一个新的、现实世界的边缘案例，而你的自动评估场景错过了它
收集并聚合这些数据至关重要；当你看到统计上显著数量的相似报告或指标下降时，你必须将这些事件关联回你的分析平台，以产生洞察并触发运营问题的警报
一个有效的智能体运维流程通过捕获此反馈、复现问题并将该特定场景转换为评估数据集中一个新的、永久的测试用例来“闭环”。这确保你不仅修复了错误，而且为系统接种了疫苗，防止整类错误再次发生

Agent Interoperability（智能体互操作性）

一旦构建了高质量的智能体，你会希望能够将它们与用户和其他智能体互连

在我们的身体部位类比中，这将是智能体的面孔。连接到智能体与连接智能体到数据和 API 之间存在差异
智能体不是工具。假设你已经将工具接入到智能体中，现在让我们考虑如何将你的智能体带入更广泛的生态系统

Agents and Humans

智能体与人类互动最常见的形式是通过用户界面。在其最简单的形式中，这是一个聊天机器人，用户输入请求，充当后端服务的智能体处理该请求并返回一段文本。更高级的智能体可以提供结构化数据（如 JSON），以支持丰富、动态的前端体验
人在回路（HITL）交互模式包括意图细化、目标扩展、确认和澄清请求
计算机使用（Computer use）是一类工具，其中语言模型接管用户界面的控制权，通常伴随着人类的交互和监督

具备计算机使用能力的智能体可以决定下一个最佳行动是导航到新页面、高亮显示特定按钮，还是用相关信息预填表格

除了智能体代表用户使用界面外，语言模型还可以更改 UI 以满足当下的需求

这可以通过控制 UI 的工具（MCP UI）、可以将客户端状态与智能体同步的专用 UI 消息系统（AG UI），甚至生成定制界面（A2UI）来实现

当然，人类交互不仅限于屏幕和键盘。高级智能体正在打破文本障碍，进入实时的、多模态通信，通过“实时模式（live mode）”创造更自然、更类人的连接。像 Gemini Live API 这样的技术支持双向流式传输，允许用户与智能体交谈并打断它，就像在自然对话中一样
这种能力从根本上改变了智能体与人类协作的性质。通过访问设备的摄像头和麦克风，智能体可以看到用户所见，听到用户所说，并以模仿人类对话的延迟响应生成的语音

这开启了文本无法实现的大量用例，从技术人员在维修设备时接收免提指导，到购物者获得实时风格建议。这使得智能体成为一个更直观、更易接近的伙伴

Agents and Agents

正如智能体必须与人类连接一样，它们也必须彼此连接。随着企业扩大 AI 的使用规模，不同的团队将构建不同的专用智能体

如果没有统一的标准，连接它们将需要构建一个由脆弱的、自定义 API 集成组成的错综复杂的网络，这是无法维护的
核心挑战是双重的：发现（我的智能体如何找到其他智能体并知道它们能做什么？）和通信（我们如何确保它们说同样的语言？）

Agent2Agent (A2A) 协议是为解决此问题而设计的开放标准

它充当智能体经济的通用握手协议。A2A 允许任何智能体发布数字“名片”，称为智能体卡片（Agent Card）
这个简单的 JSON 文件宣传智能体的能力、其网络端点以及与之交互所需的安全凭证。这使得发现变得简单且标准化。与专注于解决事务性请求的 MCP 不同，智能体对智能体的通信通常用于额外的问题解决

一旦被发现，智能体使用面向任务的架构进行通信。交互不是简单的请求-响应，而是被构建为异步的“任务”

客户端智能体向服务端智能体发送任务请求，服务端智能体随后可以通过长连接在处理问题时提供流式更新
这一稳健、标准化的通信协议是拼图的最后一块，使得代表自动化前沿的协作式、3 级多智能体系统成为可能
A2A 将一组孤立的智能体转变为一个真正的、可互操作的生态系统

Agents and Money

随着 AI 智能体为我们执行更多任务，其中一些任务涉及买卖、谈判或促成交易

当前的互联网是为人类点击“购买”而构建的，责任在于人类。如果一个自主智能体点击“购买”，就会产生信任危机——如果出了问题，谁负责？这些是关于授权、真实性和问责制的复杂问题
为了解锁真正的智能体经济，我们需要新的标准，允许智能体代表其用户安全、可靠地进行交易

这一新兴领域尚未成熟，但有两个关键协议正在铺平道路。智能体支付协议（AP2）是一个开放协议，旨在成为智能体商业的权威语言

它通过引入加密签名的数字“授权书（mandates）”扩展了 A2A 等协议。这些作为用户意图的可验证证明，为每笔交易创建了不可否认的审计线索
这允许智能体基于用户的委派授权，在全球范围内安全地浏览、谈判和交易。与之互补的是 x402，这是一个开放的互联网支付协议，使用标准的 HTTP 402 "Payment Required" 状态码。它实现了无摩擦的机器对机器微支付，允许智能体在按次付费的基础上为 API 访问或数字内容等付费，而无需复杂的账户或订阅。这两个协议共同构建了智能体网络的信任层基础

Securing a Single Agent: The Trust Trade-Off（保护单个智能体：信任权衡）

当你创建第一个 AI 智能体时，你立即面临一种基本的张力：实用性与安全性之间的权衡

为了使智能体有用，你必须赋予它权力——做决策的自主权以及执行发送邮件或查询数据库等操作的工具
然而，你赋予的每一分权力都会引入相应程度的风险
主要的安全隐患是流氓行动（rogue actions）——意外或有害的行为——以及敏感数据泄露
你想给智能体足够长的绳索来完成工作，但也足够短以防止它乱跑闯祸，尤其是当涉及到不可逆转的行动或公司的私有数据时

为了管理这一点，你不能仅依赖 AI 模型的判断，因为它可以被提示词注入（prompt injection）等技术操纵

相反，最佳实践是采用混合的、纵深防御（defense-in-depth）方法
第一层由传统的、确定性的护栏组成

一组硬编码规则，充当模型推理之外的安全检查点。这可以是一个策略引擎，阻止任何超过 100 美元的购买，或在智能体与外部 API 交互之前要求用户明确确认。这一层对智能体的权力提供了可预测、可审计的硬性限制

第二层利用基于推理的防御，使用 AI 来帮助保护 AI

这包括训练模型使其更具抗攻击性（对抗性训练），并使用较小的、专门的“卫兵模型”充当安全分析师。这些模型可以在智能体提议的计划执行之前对其进行检查，标记潜在风险或违反策略的步骤以供审查

这种混合模型结合了代码的刚性确定性与 AI 的上下文感知，即使对于单个智能体也能建立稳健的安全态势，确保其权力始终与其目的保持一致
Agent Identity: A New Class of Principal（智能体身份：一类新的主体）

在传统安全模型中，有人类用户（可能使用 OAuth 或 SSO）和服务（使用 IAM 或服务账号）。智能体增加了第三类主体（Principal）
智能体不仅仅是一段代码；它是一个自主的行动者，一种需要自身可验证身份的新型主体。就像员工被发放 ID 徽章一样，平台上的每个智能体必须被发放一个安全、可验证的“数字护照”。这种智能体身份与调用它的用户身份以及构建它的开发者身份是区分开的。这是我们必须在企业中处理身份和访问管理（IAM）方式的根本性转变
验证每个身份并对其拥有访问控制，是智能体安全的基石。一旦智能体拥有了加密可验证的身份（通常使用 SPIFFE 等标准），就可以授予其特定的、最小权限的许可

SalesAgent（销售智能体）被授予 CRM 的读/写访问权限，而 HRonboardingAgent（人力资源入职智能体）则被明确拒绝。这种细粒度控制至关重要

它确保即使单个智能体受到损害或行为异常，潜在的爆炸半径也会被控制住。没有智能体身份构造，智能体就无法以有限的委派权力代表人类工作

Principal entity	Authentication / Verification	Notes
Users	Authenticated with OAuth or SSO	Human actors with full autonomy and responsibility for their actions
Agents (new category of principles)	Verified with SPIFFE	Agents have delegated authority, taking actions on behalf of users
Service accounts	Integrated into IAM	Applications and containers, fully deterministic, no responsible for actions

Policies to Constrain Access（约束访问的策略）

策略是一种授权（AuthZ）形式，有别于认证（AuthN）。通常，策略限制主体的能力

例如，“市场部的用户只能访问这 27 个 API 端点，并且不能执行 DELETE 命令”
在开发智能体时，我们需要对智能体、其工具、其他内部智能体、它们可以共享的上下文以及远程智能体应用权限
可以这样想：如果你将所有 API、数据、工具和智能体添加到你的系统中，那么你必须将访问权限限制在完成工作所需的那些能力的子集上
这是推荐的方法：在保持上下文相关性的同时应用最小权限原则

Securing an ADK Agent（保护 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——就是构建既强大又值得信赖的单个智能体的方式

Scaling Up from a Single Agent to an Enterprise Fleet（从单个智能体扩展到企业级集群）

单个 AI 智能体在生产环境中的成功是一场胜利。扩展到数百个智能体的集群则是一个架构挑战。如果你只构建一两个智能体，你主要关注的是安全性
如果你构建许多智能体，你必须设计系统来处理更多问题。就像 API 蔓延一样，当智能体和工具在组织内激增时，它们会创建一个新的、复杂的交互网络、数据流和潜在的安全漏洞
管理这种复杂性需要一个更高阶的治理层，整合你所有的身份和策略，并向中央控制平面（Control Plane）报告
Security and Privacy: Hardening the Agentic Frontier（安全与隐私：加固智能体前沿）

企业级平台必须解决生成式 AI 固有的独特安全和隐私挑战，即使只有一个智能体在运行。智能体本身变成了一个新的攻击向量
恶意行为者可能会尝试提示词注入来劫持智能体的指令，或进行数据投毒以破坏其用于训练或 RAG 的信息
此外，约束不当的智能体可能会在响应中无意泄露敏感的客户数据或专有信息
一个稳健的平台提供纵深防御策略来减轻这些风险

它从数据开始，确保企业的专有信息绝不用于训练基础模型，并受到 VPC（虚拟私有云） 服务控制等措施的保护
它需要输入和输出过滤，充当提示和响应的防火墙。最后，平台必须提供合同保护，如针对训练数据和生成输出的知识产权赔偿，给予企业在生产中部署智能体所需的法律和技术信心

Agent Governance: A Control Plane instead of Sprawl（智能体治理：控制平面而非蔓延）

随着智能体及其工具在组织内激增，它们创建了一个新的、复杂的交互网络和潜在漏洞，这一挑战通常被称为“智能体蔓延（Agent Sprawl）
管理这一点需要超越保护单个智能体的范畴，实施更高阶的架构方法：一个充当所有智能体活动控制平面的中央网关
想象一个繁忙的大都市，成千上万的自动驾驶车辆——用户、智能体和工具——都在有目的地移动。没有交通信号灯、车牌和中央控制系统，混乱将占据主导地位
网关方法创建了该控制系统，为所有智能体流量建立了一个强制性入口点，包括用户对智能体的提示或 UI 交互、智能体对工具的调用（通过 MCP）、智能体对智能体的协作（通过 A2A）以及对语言模型的直接推理请求

通过位于这一关键路口，组织可以检查、路由、监控和管理每一次交互

这个控制平面提供两个主要且相互关联的功能

运行时策略执行：它充当实施安全性的架构检查点

它处理认证（“我知道这个行动者是谁吗？”）和授权（“他们有权这样做吗？”）
集中执行为可观测性提供了一个“单一管理视图（single pane of glass）”，为每笔交易创建通用的日志、指标和链路追踪
这将分散的智能体和工作流的“意大利面式”混乱转变为一个透明且可审计的系统

集中治理：为了有效执行策略，网关需要一个单一事实来源（Source of Truth）

这是由一个中央注册表提供的一个用于智能体和工具的企业应用商店
该注册表允许开发者发现并重用现有资产，防止重复工作，同时给管理员提供完整的清单
更重要的是，它实现了智能体和工具的正式生命周期，允许在发布前进行安全审查、版本控制，并创建细粒度的策略来规定哪些业务部门可以访问哪些智能体

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

Cost and Reliability: The Infrastructure Foundation（成本与可靠性：基础设施基础）

归根结底，企业级智能体必须既可靠又具成本效益。一个频繁失败或结果缓慢的智能体具有负投资回报率

相反，一个极其昂贵的智能体无法扩展以满足业务需求。底层基础设施的设计必须管理这种权衡，在安全的同时符合监管和数据主权要求

在某些情况下，当特定智能体或子功能有不规则流量时，你需要的功能是缩容至零（scale-to-zero）

scale to zero ：当没有人使用服务时，自动彻底关闭它以节省成本；当有人使用时，再瞬间启动它

对于任务关键型、延迟敏感型工作负载，平台必须提供专用的、有保证的容量，例如语言模型服务的预配置吞吐量（Provisioned Throughput）或像 Cloud Run 这样运行时的 99.9% 服务级别协议（SLA）
这提供了可预测的性能，确保你最重要的智能体即使在重负载下也总是响应迅速。通过提供这一系列基础设施选项，加上对成本和性能的全面监控，你建立了将 AI 智能体从有前景的创新扩展为企业核心、可靠组件所需的最终且必要的基础

How agents learn and self evolve（智能体如何进化与学习）

部署在现实世界中的智能体在动态环境中运行，那里的策略、技术和数据格式不断变化
如果缺乏适应能力，智能体的性能将会随时间推移而下降——这一过程通常被称为“老化（aging）”——导致实用性和信任度的丧失
手动更新庞大的智能体集群以跟上这些变化是不经济且缓慢的
更可扩展的解决方案是设计能够自主学习和进化的智能体，以极少的工程投入在工作中提高其质量

很像人类，智能体从经验和外部信号中学习。这一学习过程由多种信息来源驱动

运行时经验：智能体从运行时工件（如会话日志、链路追踪和记忆）中学习，这些工件记录了成功、失败、工具交互和决策轨迹。至关重要的是，这包括人在回路（HITL）反馈，它提供了权威的纠正和指导
外部信号：学习也由新的外部文档驱动，例如更新的企业策略、公共监管指南或其他智能体的批评
这些信息随后用于优化智能体的未来行为。先进系统不仅仅是总结过去的交互，而是创建可泛化的工件来指导未来的任务。最成功的适应技术分为两类

增强的上下文工程：系统持续改进其提示词、少样本示例（few-shot examples）以及从记忆中检索的信息。通过为每个任务优化提供给语言模型的上下文，它增加了成功的可能性（上下文工程的迭代）
工具优化与创建：智能体的推理可以识别其能力的差距并采取行动填补它们。这可能涉及获取新工具的访问权限、即时创建一个新工具（例如 Python 脚本），或修改现有工具（例如更新 API 模式）

额外的优化技术，如动态重新配置多智能体设计模式或使用基于人类反馈的强化学习（RLHF），是活跃的研究领域

Example: Learning New Compliance Guidelines（示例：学习新的合规准则）

一个在受严格监管行业（如金融或生命科学）运营的企业智能体。其任务是生成必须符合隐私和监管规则（如 GDPR）的报告
这可以使用多智能体工作流来实现：

查询智能体（Querying Agent） 响应用户请求检索原始数据
报告智能体（Reporting Agent） 将此数据综合成报告草稿
批评智能体（Critiquing Agent），装备有已知的合规准则，审查报告。如果遇到歧义或需要最终签署，它会升级给人类领域专家
学习智能体（Learning Agent） 观察整个交互，特别关注来自人类专家的纠正反馈。然后，它将此反馈泛化为一条新的、可重用的准则（例如，批评智能体的更新规则或报告智能体的优化上下文）

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

Simulation and Agent Gym - the next frontier 下一个前沿（仿真与智能体健身房）

我们提出的设计模式可以归类为在线学习（in-line learning），即智能体需要在其被设计的资源和模式下进行学习
目前正在研究更先进的方法，即有一个专用平台，旨在通过高级工具和能力在离线流程中优化多智能体系统，这些工具和能力不是多智能体运行时环境的一部分。这种“智能体健身房（Agent Gym）”的关键属性包括

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

它提供了一个仿真环境，让智能体可以在新数据上“锻炼”和学习。这种仿真环境非常适合具有多种优化路径的“试错”

它可以调用高级合成数据生成器，引导仿真尽可能真实，并对智能体进行压力测试（这可能包括高级技术，如红队测试、动态评估和批评智能体家族）

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

最后，即使是像智能体健身房这样的构造，也可能无法克服某些边缘情况（由于企业中众所周知的“部落知识/隐性知识”问题）。在这些情况下，我们看到智能体健身房能够连接到领域专家的人类网络，并就正确的结果集咨询他们，以指导下一轮优化

高级智能体示例

Google Co-Scientist

锦标赛审查Co-Scientist 是一个高级 AI 智能体，旨在充当虚拟研究合作者，通过系统地探索复杂问题空间来加速科学发现。它使研究人员能够定义目标，将智能体建立在指定的公共和私有知识源之上，然后生成并评估一系列新颖的假设

Scientist

科学家通过自然语言指定研究目标与系统交互。他们还可以提出自己的想法和建议，提供反馈和审查，并通过聊天界面进行互动，以引导“AI合作科学家”系统（通过聊天界面讨论）
科学家描述研究目标，以及偏好、实验约束和其他属性

AI co-scientist

AI合作科学家针对科学家提供的研究目标，持续生成、审查、辩论并改进研究假设和提案

Research proposals and overview 研究提案与概述

排名靠前的科研假设和提案被总结为研究概述，并与科学家共享

Ranking Agent tournaments 排名智能体锦标赛

在锦标赛中通过科学辩论对研究假设进行比较和排名。总结局限性和主要胜负模式，并将其作为反馈提供给其他智能体。这实现了研究假设生成质量的迭代改进，从而创建一个自我改进的循环

Research plan configuration

Generation Agent

文献探索
模拟科学辩论

Reflection Agent

结合网络搜索的全面审查
模拟审查
锦标赛审查
深度验证

Evolution Agent

从其他想法中获取灵感
简化
研究扩展

Proximity Check Agent
Meta-review Agent

研究概述制定

为了实现这一目标，Co-Scientist 孵化了一个由相互协作的智能体组成的整个生态系统
可以将该系统视为一个研究项目经理。AI 首先接受一个广泛的研究目标并创建一个详细的项目计划。然后，一个“主管（Supervisor）”智能体充当经理，将任务委派给专门的智能体团队并分配计算能力等资源。这种结构确保项目可以轻松扩展，并且团队的方法在朝着最终目标努力的过程中不断改进

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

AlphaEvolve Agent

用于发现和优化数学及计算机科学中复杂问题的算法
AlphaEvolve 的工作原理是将我们 Gemini 语言模型的创造性代码生成与自动评估系统相结合。它使用进化过程：AI 生成潜在的解决方案，评估器对其进行评分，最有希望的想法被用作下一代代码的灵感

Human defines “What?”

设定评估标准，提供初始方案及可选的背景知识

AlphaEvolve figures out “How?”

提示采样器 —(包含过去试验和想法的丰富上下文)→ 大语言模型 (LLMs) 集合—(改进后的程序代码)→ 评估器池 —-(带有质量评分和其他反馈的程序)→ 程序数据库 —(待改进及作为灵感的程序)→ 提示采样器

Scientist / Engineer

提示模板和配置
选择现有的或自定义的大语言模型
评估代码
包含待进化组件的初始程序

这种方法已经带来了重大突破，包括

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

AlphaEvolve 擅长解决那些验证解决方案质量比最初找到解决方案容易得多的问题
AlphaEvolve 专为人类与 AI 之间深入、迭代的伙伴关系而设计。这种协作主要通过两种方式进行

透明的解决方案：AI 生成人类可读的代码作为解决方案。这种透明度允许用户理解逻辑、获得洞察、信任结果，并直接根据需要修改代码
专家指导：人类专业知识对于定义问题至关重要。用户通过优化评估指标并引导探索方向来指导 AI，从而防止系统利用问题定义中非预期的漏洞。这种交互式循环确保了最终的解决方案既强大又实用

智能体的结果是代码的持续改进，不断提升人类指定的指标

Conclusion

生成式 AI 智能体标志着一个关键的进化，将人工智能从内容创作的被动工具转变为解决问题的主动、自主伙伴
本文档提供了一个理解和构建这些系统的正式框架，超越原型阶段，建立可靠的、生产级的架构
我们将智能体解构为其三个基本组成部分：推理模型（“大脑”）、可执行工具（“双手”）和管控编排层（“神经系统”）
正是这些部分的无缝集成，在持续的“思考、行动、观察”循环中运行，释放了智能体的真正潜力。通过对智能体系统进行分类——从 1 级的联网解题者到 3 级的协作多智能体系统——架构师和产品负责人现在可以战略性地规划其愿景，以匹配手头任务的复杂性
核心挑战和机遇在于新的开发者范式。我们不再仅仅是定义显式逻辑的“砌砖工”；我们是“架构师”和“导演”，必须指导、约束和调试一个自主实体
使语言模型如此强大的灵活性也是其不可靠性的来源。因此，成功不仅仅在于初始提示词，而在于应用于整个系统的工程严谨性：稳健的工具契约、弹性的错误处理、复杂的上下文管理和全面的评估
此处概述的原则和架构模式作为基础蓝图。它们是探索这一软件新前沿的路标，使我们能够构建的不仅仅是“工作流自动化”，而是真正协作、有能力且适应性强的团队新成员。随着这项技术的成熟，这种纪律严明、架构化的方法将是驾驭智能体 AI 全部力量的决定性因素