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

翻译：Google notebooklm

英文原版PDF下载链接：https://drive.google.com/file/u/0/d/1C-HvqgxM7dj4G2kCQLnuMXi1fTpXRdpx/view

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

从预测性人工智能到自主智能体

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

这个新领域是围绕 AI 智能体构建的。智能体不仅仅是静态工作流中的 AI 模型；它是一个完整的应用程序，能够制定计划并采取行动以实现目标。它将语言模型（LM）的推理能力与实际的行动能力相结合，使其能够处理仅凭模型无法完成的复杂、多步骤任务。

关键能力在于智能体可以自主工作，无需人工在每一步进行指导，就能找出实现目标所需的下一步骤

本文件是五部曲系列中的第一部，旨在为从概念验证阶段过渡到稳健、生产级智能体系统的开发者、架构师和产品负责人提供正式指南。虽然构建一个简单的原型很简单，但确保安全性、质量和可靠性是一个重大挑战。

本文提供了全面的基础知识：

• 核心结构（Core Anatomy）：将智能体分解为三个基本组成部分：推理模型（the reasoning Model）、可操作工具（actionable Tools） 和管理编排层（the governing Orchestration Layer）。
• 能力分类（A Taxonomy of Capabilities）：对智能体进行分类，从简单的互联问题解决者到复杂的协作式多智能体系统。
• 架构设计（Architectural Design）：深入探讨每个组件的实际设计考量，从模型选择到工具实现。
• 为生产环境而构建（Building for Production）：建立 智能体运维（Agent Ops） 规范，用于评估、调试、保护和扩展智能体系统，使其从单个实例发展为具备企业治理能力的大型集群。

本指南基于此前的《智能体白皮书》和《智能体伴侣》而构建；它提供了基础概念和战略框架，您将需要这些内容来成功构建、部署和管理新一代的智能应用程序，这些程序能够推理（reason）、行动（act）和观察（observe）以实现目标。

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

人工智能智能体导论

用最简单的话来说，人工智能智能体可以定义为模型、工具、编排层和运行时服务的组合，它在一个循环中利用语言模型（LM）来完成一个目标。这四个要素构成了任何自主系统的基本架构。

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

归根结底，构建一个生成式 AI 智能体是开发解决方案来解决任务的一种新方式。传统的开发人员充当“砌砖工”，精确地定义每个逻辑步骤。相比之下，智能体开发人员更像一名“导演”。您无需为每个动作编写明确的代码，而是设置场景（指导说明和提示）、选择演员阵容（工具和 API），并提供必要的上下文（数据）。主要任务变成了指导这个自主的“演员”来交付预期的表现。

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

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

本质上，智能体是一个致力于上下文窗口策划艺术的系统。它是一个不懈的循环，包括汇集上下文、提示模型、观察结果，然后为下一步骤重新汇集上下文。上下文可能包括系统指令、用户输入、会话历史、长期记忆、来自权威来源的基础知识、哪些工具可以使用，以及已调用工具的结果。对模型注意力的这种复杂管理使其推理能力能够解决新情况并实现目标。

智能体的问题解决过程

我们已将 AI 智能体定义为一个完整的、以目标为导向的应用程序，它集成了推理模型、可操作工具和管理编排层。简而言之，就是“语言模型（LM）在一个循环中与工具配合以完成一个目标”。

但这个系统实际上是如何运作的？从接收请求到交付结果的那一刻，一个智能体都做了些什么？

智能体的核心是以一个持续的、周期性的过程来达成其目标。虽然这个循环可能会变得高度复杂，但正如《智能体系统设计》一书中所详细讨论的那样，它可以分解为五个基本步骤：

1. 获取任务（Get the Mission）：该过程由一个特定的、高层级的目标启动。这个任务可以由用户提供（例如，“组织我的团队参加即将举行的会议的行程”），也可以由自动化触发器提供（例如，“一个新的高优先级客户工单已到达”）。
2. 扫描场景（Scan the Scene）：智能体感知其环境以收集上下文。这涉及编排层访问其可用资源：“用户的请求说了什么？”，“我的长期记忆中有什么信息？我以前尝试过执行这个任务吗？用户上周给我指导了吗？”，“我可以从我的工具中获取什么，比如日历、数据库或 API？”。
3. 仔细思考（Think It Through）：这是由推理模型驱动的智能体核心“思考”循环。智能体根据场景（第 2 步）分析任务（第 1 步），并制定计划。这通常不是一个单一的想法，而是一连串的推理：“要预订行程，我首先需要知道团队中有哪些人。我将使用 get_team_roster 工具。然后我需要通过 calendar_api 检查他们的可用性。”
4. 采取行动（Take Action）：编排层执行计划中的第一个具体步骤。它选择并调用适当的工具——调用 API、运行代码函数或查询数据库。这是智能体在超出其自身内部推理范围的世界上采取行动。
5. 观察与迭代（Observe and Iterate）：智能体观察其行动的结果。get_team_roster 工具返回了五人名单。这个新信息被添加到智能体的上下文或“记忆”中。然后循环重复，返回到第 3 步：“既然我已经有了名单，我的下一步是检查这五个人的日历。我将使用 calendar_api。”

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

让我们来看一个客户支持智能体如何在这个五步循环中运作的真实世界例子：

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

智能体不会立即行动，而是首先进入其“仔细思考”阶段，以制定一个完整的策略。它推理道：

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

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

考虑到这个多步骤计划，智能体开始执行。在其第一个“行动”阶段，它执行计划的第一步，调用 find_order("12345") 工具。它观察结果——一个完整的订单记录，其中包括追踪号码“ZYX987”。

智能体的编排层识别到其计划的第一部分已完成，并立即进行第二部分。它通过调用 get_shipping_status("ZYX987") 工具来采取行动。它观察到新的结果：“正在派送中（Out for Delivery）”。

最后，在成功执行了计划中的数据收集阶段后，智能体进入“报告”步骤。它感知到它拥有所有必要的组成部分，规划最终消息，并通过生成回复来采取行动：“您的订单 #12345 正在‘派送中’！”。

智能体系统分类法

理解五步操作循环是解决问题的第一个环节。第二个环节是认识到该循环可以按复杂性进行扩展，以创建不同类别的智能体。对于架构师或产品负责人来说，一个关键的初始决定是确定要构建哪种智能体的范围。

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

级别 0：核心推理系统

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

它的优势在于这种广泛的训练，使其能够解释既定的概念，并深入规划如何解决问题。但其权衡是完全缺乏实时感知；对于其训练数据之外的任何事件或事实，它在功能上是“盲目”的。

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

级别 1：互联问题解决者

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

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

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

级别 2：战略性问题解决者

级别 2 标志着能力的显著扩展，从执行简单任务转变为战略性规划复杂的、多部分的目标。这里出现的关键技能是上下文工程（context engineering）：智能体主动选择、打包和管理与其计划的每一步最相关的信息的能力。

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

例如，考虑“任务”：“在我的办公室（1600 Amphitheatre Parkway, Mountain View）和我客户的办公室（1 Market St, San Francisco）之间找一家好的咖啡馆”。

一个级别 2 智能体将开始制定计划：

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

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

◦ 观察：“中点是 Millbrae, CA”。

2. 思考：“现在我必须在 Millbrae 找到咖啡馆。用户要求‘好的’咖啡馆，所以我将搜索评级在 4 星或更高的地方”。

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

◦ 观察：“搜索返回‘Millbrae Coffee’和‘The Daily Grind’”。

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

这种战略性规划还支持主动协助，例如一个智能体可以阅读一封冗长的航班确认邮件，策划关键上下文（航班号、日期），并通过将其添加到您的日历来采取行动。

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

在最高级别，范式完全转变。我们不再构建单个、万能的“超级智能体”，而是转向协同工作的“专家团队”，这种模式直接模仿了人类组织。系统的集体力量在于这种分工。

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

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

1. 委托给 MarketResearchAgent（市场研究智能体）：“分析降噪耳机的竞争对手定价。明天返回一份摘要文件”。
2. 委托给 MarketingAgent（营销智能体）：“使用‘Solaris’产品规格表作为上下文，起草三个版本的宣传稿”。
3. 委托给 WebDevAgent（网页开发智能体）：“根据附件的设计模型生成新产品页面的 HTML”。

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

级别 4：自演进系统

级别 4 代表了从委托到自主创建和适应的深刻飞跃。在这个级别，智能体系统可以识别自身能力中的差距，并动态创建新工具，甚至新智能体来填补这些空白。它从使用一组固定的资源转变为主动扩展它们。

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

1. 思考（元推理）：“我必须跟踪‘Solaris’的社交媒体热度，但我缺乏这个能力”。
2. 行动（自主创建）：它没有失败，而是调用一个高级的 AgentCreator 工具，并附带一个新任务：“构建一个新的智能体，用于监控‘Solaris headphones’等关键词的社交媒体，执行情绪分析，并报告每日摘要”。
3. 观察：一个新的、专业的 SentimentAnalysisAgent（情绪分析智能体）被即时创建、测试并添加到团队中，随时可以为最初的任务做出贡献。

这种自主水平——即系统可以动态扩展自身能力——将智能体团队转变为一个真正学习和演进的组织。

核心智能体架构：模型、工具和编排层

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

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

语言模型（LM） 是您的智能体的推理核心，它的选择是一个关键的架构决策，决定了您的智能体的认知能力、运营成本和速度。然而，将这种选择简单地视为挑选具有最高基准分数的模型，是通往失败的常见途径。智能体在生产环境中的成功很少由通用学术基准决定。

现实世界的成功要求模型擅长智能体的基本要素：卓越的推理能力以应对复杂的、多步骤的问题，以及可靠的工具使用来与世界互动。

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

您可以选择不止一个模型，即一个“专家团队”。您不需要用大锤来砸核桃。一个稳健的智能体架构可能会使用像 Gemini 2.5 Pro 这样的前沿模型来处理初始规划和复杂推理的繁重工作，但随后会智能地将更简单、高容量的任务（例如分类用户意图或总结文本）路由到一个更快、更具成本效益的模型，例如 Gemini 2.5 Flash。模型路由可以是自动的或硬编码的，但它是优化性能和成本的关键策略。

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

最后，AI 格局处于持续、快速的演变状态。您今天选择的模型将在六个月内被取代。“一劳永逸”的心态是不可持续的。为应对这一现实而构建意味着投资于一个灵活的运营框架——即 “智能体运维（Agent Ops）”实践。通过一个强大的 CI/CD（持续集成/持续部署）管道，持续根据您的关键业务指标评估新模型，您可以降低升级风险并加速升级，确保您的智能体始终由可用的最佳“大脑”提供支持，而无需进行彻底的架构大修。

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

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

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

检索信息：奠定现实基础

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

执行行动：改变世界

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

这也包括用于人机交互的工具。智能体可以使用**人工回路（Human in the Loop, HITL）**工具来暂停其工作流程并请求确认（例如 ask_for_confirmation()），或请求用户界面中的特定信息（例如 ask_for_date_input()），确保在关键决策中有人参与。HITL 可以通过短信或数据库中的任务来实现。

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

为了让一个智能体可靠地进行“函数调用”和使用工具，它需要清晰的指令、安全的连接和编排。诸如 OpenAPI 规范之类的长期标准提供了这一点，为智能体提供了一个结构化的契约，描述了工具的用途、所需的参数及其预期的响应。这个模式允许模型每次都生成正确的函数调用并解释 API 响应。对于更简单的发现和连接工具，像 模型上下文协议（Model Context Protocol, MCP） 这样的开放标准已经变得流行，因为它们更加方便。此外，一些模型拥有原生工具，例如带有原生 Google 搜索的 Gemini，其中函数调用作为 LM 自身调用的一部分发生。

编排层

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

核心设计选择

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

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

无论采用哪种方法，生产级框架都是必不可少的。它必须是开放的，允许您接入任何模型或工具以防止供应商锁定。它必须提供精确的控制，实现一种混合方法，即 LM 的非确定性推理受到硬编码业务规则的约束。最重要的是，该框架必须以可观察性为目标而构建。当一个智能体行为异常时，您不能简单地在其模型的“思维”中设置一个断点。一个稳健的框架会生成详细的轨迹（traces）和日志，暴露完整的推理轨迹：模型的内部独白、它选择的工具、它生成的参数以及它观察到的结果。

通过领域知识和人设进行指导

在这个框架内，开发人员最强大的杠杆是用领域知识和独特的人设来指导智能体。这是通过系统提示或一套核心指令来实现的。这不仅仅是一个简单的命令；它是智能体的“宪法”。

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

用上下文增强

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

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

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

多智能体系统和设计模式

随着任务复杂性的增加，构建一个单一的、无所不能的“超级智能体”变得低效。更有效的解决方案是采用**“专家团队”方法，这模仿了人类组织。这是多智能体系统**的核心：一个复杂的过程被

分割成离散的子任务，并且每个子任务都分配给一个专用、专业的 AI 智能体。这种分工允许每个智能体更简单、更专注、更容易构建、测试和维护，这对于动态或长期运行的业务流程是理想的。

架构师可能会依赖经过验证的智能体设计模式，尽管智能体的能力和模式正在迅速发展。对于动态或非线性任务，协调器模式（Coordinator pattern）智能体分析一个复杂的请求，分割主要任务，并智能地将每个子任务路由到适当的专业智能体（例如研究员、作家或编码员）。然后，协调器聚合来自每个专业智能体的响应，以形成最终的、全面的答案。

对于更线性的工作流，顺序模式（Sequential pattern）智能体的输出成为下一个智能体的直接输入。其他关键模式侧重于质量和安全。**迭代改进模式（Iterative Refinement pattern）**创建一个反馈循环，使用一个“生成器”智能体来创建内容，并使用一个“批评者”智能体来根据

质量标准对其进行评估。对于高风险任务，人工回路（Human-in-the-Loop, HITL）模式至关重要，它在工作流中创建一个有意的暂停，以便在智能体采取重大行动之前获得人员的批准。

智能体部署和服务

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

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

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

智能体运维：应对不可预测性的结构化方法

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

从传统的、确定性的软件到随机性的智能体系统，需要一种新的运营理念。传统的软件单元测试可以简单地断言“输出 == 预期”；但这在一个智能体的响应本质上是概率性的情况下不起作用。此外，由于语言的复杂性，它通常需要一个语言模型（LM）来评估“质量”——即智能体的响应是否做了所有应该做的事情，没有做不该做的事情，并使用了恰当的语气。

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

衡量重要指标：像 A/B 实验一样监测成功

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

质量而非通过/失败：使用语言模型评判（LM Judge）

业务指标并不能告诉您智能体的行为是否正确。由于简单的通过/失败是不可能的，我们转向使用“语言模型作为评判者”来评估质量。这涉及使用一个强大的模型，根据预定义的规则来评估智能体的输出：它是否给出了正确的答案？响应是否有事实依据？它是否遵循了指令？这种针对黄金数据集提示运行的自动化评估，提供了持续一致的质量衡量标准。

创建评估数据集——包括理想的（或“黄金”）问题和正确响应——可能是一个乏味的过程。要构建这些数据集，您应该从与智能体现有的生产或开发交互中抽样场景。该数据集必须涵盖您期望用户参与的全部用例，以及一些意料之外的用例。虽然对评估的投资会迅速带来回报，但评估结果

在被接受为有效之前，应始终由领域专家进行审查。评估的策划和维护正日益成为产品经理的主要职责，并得到领域专家的支持。

指标驱动开发：您的部署批准/否决（Go/No-Go）

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

使用 OpenTelemetry 轨迹进行调试：回答“为什么？”

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

性能概述。轨迹数据可以无缝地收集在像 Google Cloud Trace 这样的平台中，这些平台可以可视化和搜索大量轨迹，从而简化根本原因分析。

珍视人工反馈：指导您的自动化

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

智能体互操作性

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

智能体与人类

智能体与人类交互的最常见形式是通过用户界面。在最简单的形式中，这是一个聊天机器人，用户输入请求，智能体充当后端服务对其进行处理并返回一段文本。更高级的智能体可以提供结构化数据，例如 JSON，以支持丰富、动态的前端体验。人工回路（Human in the Loop, HITL）交互模式包括意图提炼、目标扩展、确认和澄清请求。

计算机使用是一种工具类别，其中语言模型（LM）控制用户界面，通常伴随人工交互和监督。一个启用计算机使用的智能体可以决定下一步最佳行动是导航到新页面、突出显示特定按钮，或用相关信息预填充表单。

智能体也可以改变用户界面以满足当前的需求，而不是代表用户使用界面。这可以通过控制用户界面的工具（MCP UI）或可以与智能体同步客户端状态的专业用户界面消息系统（AG UI），甚至是通过生成定制界面（A2UI）来实现。

当然，人类交互不限于屏幕和键盘。先进的智能体正在突破文本障碍，迈向实时、多模态通信，通过“实时模式（live mode）”创造出更自然、更像人类的连接。像 Gemini Live API 这样的技术 实现了双向流媒体，允许用户与智能体对话并打断它，就像在自然对话中一样。

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

这为文本无法实现的广泛用例打开了大门，例如技术人员在修理设备时获得免提指导，或者购物者获得实时着装建议。这使得智能体成为一个更直观、更容易接触的伙伴。

智能体与智能体

就像智能体必须与人类连接一样，它们也必须相互连接。当一个企业扩大其对 AI 的使用时，不同的团队将构建不同的专业智能体。如果没有一个共同的标准，连接它们将需要构建一个难以维护的、由脆弱的定制 API 集成组成的复杂网络。核心挑战是双重的：发现（我的智能体如何找到其他智能体并知道它们能做什么？）和通信（我们如何确保它们使用相同的语言？）。

Agent2Agent (A2A) 协议是旨在解决此问题的开放标准。它充当智能体经济的通用握手。A2A 允许任何智能体发布一个数字“名片”，称为 Agent Card。这个简单的 JSON 文件宣传了智能体的能力、其网络端点以及与之交互所需的安全凭证。这使得发现过程简单且标准化。与侧重于解决事务性请求的 MCP 不同，智能体到智能体通信通常是为了额外的解决问题。

一旦被发现，智能体就会使用面向任务的架构进行通信。交互不是简单的请求-响应，而是被框架化为异步的“任务”。客户端智能体向服务器智能体发送任务请求，然后服务器智能体可以在长时间运行的连接上在处理问题时提供流式更新。这种稳健的、标准化的通信协议是解决问题的最后一部分，它实现了代表自动化前沿的协作式 级别 3 多智能体系统。A2A 将孤立的智能体集合转变为一个真正的、可互操作的生态系统。

智能体与金钱

随着 AI 智能体为我们完成更多任务，其中一些任务涉及购买或销售、谈判或促进交易。当前的网络是为人类点击“购买”而构建的，责任在于人类。如果一个自主智能体点击“购买”，就会引发信任危机——如果出现问题，谁来承担责任？。这些是关于授权、真实性和问责制的复杂问题。为了开启一个真正的智能体经济，我们需要新的标准，允许智能体代表其用户安全可靠地进行交易。

这个新兴领域远未成熟，但有两个关键协议正在铺平道路。Agent Payments Protocol (AP2) 是一个开放协议，旨在成为智能体商务的权威语言。它通过引入加密签名的数字“授权书（mandates）”智能体基于用户委托的授权，在全球范围内安全地浏览、谈判和交易。与之相辅相成的是 x402，这是一个开放的互联网支付协议，它使用标准的 HTTP 402 “要求付费”状态码。它实现了无摩擦的、机器对机器的小额支付，允许智能体以按使用付费的方式支付 API 访问或数字内容等费用，而无需复杂的账户或订阅。总而言之，这些协议正在为智能体网络构建基础信任层。

保护单个智能体：信任权衡

当您创建您的第一个 AI 智能体时，您立即面临一个根本性的矛盾：实用性与安全性之间的权衡。为了使一个智能体有用，您必须赋予它权力——自主决策的权力和执行行动的工具，例如发送电子邮件或查询数据库。然而，您赋予的每一点权力都会引入相应的风险。主要的安全担忧是流氓行动——非预期或有害的行为——和敏感数据泄露。

您希望给予您的智能体足够长的“绳子”来完成它的工作，但又要足够短，以防止它“跑到马路上”，特别是当这种“马路”涉及不可逆转的行动或您公司的私人数据时。

为了管理这种情况，您不能仅仅依赖 AI 模型的判断，因为它可能被诸如提示注入（prompt injection）混合的、纵深防御的方法。

第一层由传统的、确定性的防护栏组成——这是一套硬编码的规则，充当模型推理之外的安全**“瓶颈”。这可以是一个策略引擎，它阻止任何超过 100 美元的购买，或者在智能体与外部 API 交互之前需要明确的用户确认。这一层为智能体的权力提供了可预测、可审计的硬性限制**。

第二层利用基于推理的防御，即使用 AI 来帮助保护 AI。这包括训练模型使其更能抵抗攻击（对抗性训练），以及采用更小、专业的**“防护模型”充当安全分析师。这些模型可以在智能体执行其提议的计划之前对其进行检查，标记出潜在的高风险或违反策略的步骤以供审查。这种结合了代码的刚性确定性与 的混合模型，为即使是单个智能体也创建了一个强大的安全态势**，确保其权力始终与其目的保持一致。

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

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

让每个身份都得到验证并对它们全部进行访问控制，是智能体安全的基石。一旦一个智能体拥有一个加密可验证的身份（通常使用像 SPIFFE35 这样的标准），就可以赋予它自身特定的、最小权限的许可。例如，SalesAgent（销售智能体）被授予对 CRM 的读/写访问权限，而 HRonboardingAgent（人力资源入职智能体）则被明确拒绝。这种粒度控制至关重要。它确保即使单个智能体被泄露或行为异常，潜在的影响范围也能被遏制。如果没有智能体身份结构，智能体就不能在有限的委托授权下代表人类工作。

表 1：不同主体认证类别的非详尽示例

限制访问的策略

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

保护 ADK 智能体

在确立了身份和策略的核心原则之后，保护使用智能体开发工具包（Agent Development Kit, ADK）智能体，就成了一个通过代码和配置应用这些概念的实际练习。

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

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

对于可以适应智能体运行时行为的更动态的安全性，ADK 提供了回调（Callbacks）和插件（Plugins）。before_tool_callback 允许您在工具调用运行之前检查其参数，根据智能体的当前状态验证它们，以防止错位的行动。对于更可重用的策略，您可以构建插件。一个常见的模式是“Gemini as a Judge”（Gemini 作为评判者），它使用像 Gemini Flash-Lite 这样的快速、廉价的模型或您自己微调的 Gemma 模型，实时筛选用户输入和智能体输出中的提示注入或有害内容。

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

从单个智能体扩展到企业级智能体集群

单个 AI 智能体在生产环境中的成功是一个胜利。但扩展到数百个智能体集群则是一个架构挑战

从单个智能体扩展到企业级智能体集群

单个 AI 智能体在生产环境中的成功是一个胜利。但扩展到数百个智能体集群则是一个架构挑战。如果您正在构建一两个智能体，您的主要顾虑是安全性。如果您正在构建许多智能体，您必须设计能够处理更多事务的系统。就像 API 蔓延一样，当智能体和工具在整个组织中激增时，它们会形成一个新的、复杂的交互、数据流和潜在安全漏洞网络。管理这种复杂性需要一个更高级别的治理层，将您的所有身份和策略集成到一个中央控制平面中并进行报告。

安全与隐私：强化智能体前沿

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

一个稳健的平台提供纵深防御策略来减轻这些风险。它从数据开始，确保企业的专有信息永远不会被用于训练基础模型，并受到像 VPC 服务控制（VPC Service Controls） 这样的控制措施的保护。它需要输入和输出过滤，充当提示和响应的防火墙。最后，该平台必须为训练数据和生成的输出提供合同保护，例如知识产权赔偿，从而为企业在生产环境中部署智能体提供所需的法律和技术信心。

智能体治理：控制平面而非蔓延

随着智能体及其工具在整个组织中激增，它们会形成一个新的、复杂的交互网络和潜在的漏洞，这一挑战通常被称为“智能体蔓延（agent sprawl）”。管理这种情况需要超越保护单个智能体，实施一种更高级别的架构方法：一个充当所有智能体活动控制平面的中央网关。

想象一个拥有数千辆自动驾驶汽车——用户、智能体和工具——都在有序移动的繁华大都市。如果没有红绿灯、牌照和一个中央控制系统，混乱将占据主导地位。网关方法创建了这个控制系统，为所有智能体流量建立了一个强制性的入口点，包括用户到智能体的提示或 UI 交互、智能体到工具的调用（通过 MCP）、智能体到智能体的协作（通过 A2A） 以及对语言模型（LM）的直接推理请求。通过位于这个关键的交汇点，组织可以检查、路由、监控和管理每一次交互。

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

1. 运行时策略执行（Runtime Policy Enforcement）：它充当实施安全的架构瓶颈。它处理身份验证（“我认识这个执行者吗？”）和授权（“他们有权限这样做吗？”）。集中执行提供了可观察性的“单一管理面板”，为每笔交易创建通用日志、指标和轨迹。这会将分散的智能体和工作流的“意大利面条式”网络转变为一个透明且可审计的系统。
2. 集中治理（Centralized Governance）：为了有效地执行策略，网关需要一个单一事实来源。这由一个中央注册表提供——一个智能体和工具的企业应用商店。这个注册表允许开发人员发现和重用现有资产，防止重复工作，同时为管理员提供一个完整的库存清单。更重要的是，它为智能体和工具启用了正式的生命周期，允许在发布前进行安全审查、版本控制，以及创建细粒度的策略来规定哪些业务部门可以访问哪些智能体。

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

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

归根结底，企业级智能体必须既可靠又具有成本效益。一个经常失败或提供缓慢结果的智能体会带来负投资回报率。相反，一个成本高昂得令人望而却步的智能体无法扩展以满足业务需求。底层基础设施的设计必须能够管理这种权衡，同时确保安全并遵守法规和数据主权。

在某些情况下，当您对特定智能体或子功能的流量不规律时，您需要的功能是缩减到零（scale-to-zero）。对于任务关键型、对延迟敏感的工作负载，平台必须提供专用、有保障的容量，例如针对 LM 服务的 Provisioned Throughput 或针对 Cloud Run 等运行时的 99.9% 服务级别协议（SLAs）。这提供了可预测的性能，确保您最重要的智能体始终保持响应，即使在重负载下也是如此。通过提供这种基础设施选项的范围，以及对成本和性能的全面监控，您就建立了将 AI 智能体从一个有前景的创新扩展为企业核心、可靠组件的最终且必要的基础。

智能体如何演进和学习

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

智能体如何学习和自我演进

就像人类一样，智能体通过经验和外部信号进行学习。这种学习过程由几个信息来源驱动：

• 运行时经验（Runtime Experience）：智能体从运行时工件中学习，例如会话日志、轨迹和记忆。这些工件捕捉了成功、失败、工具交互和决策轨迹。至关重要的是，这包括**人工回路（Human-in-the-Loop, HITL）**反馈，它提供了权威性的修正和指导。
• 外部信号（External Signals）：学习也受到新的外部文档的驱动，例如更新的企业策略、公共监管指南或其他智能体的批评。

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

• 增强的上下文工程（Enhanced Context Engineering）：系统不断优化其提示、少样本示例以及它从记忆中检索到的信息。通过为语言模型（LM）为每个任务提供的上下文，系统增加了成功的可能性。
• 工具优化和创建（Tool Optimization and Creation）：智能体的推理可以识别其能力中的差距并采取行动来填补它们。这可能涉及获得新工具的访问权限，即时创建新工具（例如，一个 Python 脚本），或修改现有工具（例如，更新 API 模式）。

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

示例：学习新的合规指南

考虑一个在金融或生命科学等受到严格监管的行业中运行的企业智能体。它的任务是生成必须遵守隐私和监管规则（例如 GDPR）的报告。

这可以使用一个多智能体工作流来实现：

1. **查询智能体（Querying Agent）**响应用户请求检索原始数据。
2. **报告智能体（Reporting Agent）**将这些数据合成为报告草稿。
3. 批评智能体（Critiquing Agent），配备已知的合规指南，审查报告。如果它遇到歧义或需要最终签署，它会升级给人类领域专家。
4. 学习智能体（Learning Agent）修正性反馈。然后，它将此反馈泛化为一个新的、可重用的指南（例如，为批评智能体更新规则或为报告智能体优化上下文）。

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

模拟和智能体训练场（Agent Gym）——下一个前沿

我们提出的设计模式可以归类为内联学习（in-line learning），即智能体需要使用它们被设计时的资源和设计模式进行学习。目前正在研究更先进的方法，即存在一个专用平台，该平台被设计用于在离线过程中优化多智能体系统，并配备了不属于多智能体运行时环境的高级工具和能力。这种**智能体训练场（Agent Gym）**的关键属性包括：

1. 它不处于执行路径中：它是一个独立的非生产平台，因此可以得到任何语言模型、离线工具、云应用程序等的帮助。
2. 它提供了一个模拟环境：因此智能体可以“演练”新数据并进行学习。这个模拟环境非常适合通过许多优化途径进行“试错（trial-and-error）”。
3. 它可以调用高级合成数据生成器：这些生成器指导模拟尽可能真实，并对智能体进行压力测试（这可以包括高级技术，例如红队测试（red-teaming）、动态评估和一系列批评智能体）。
4. 优化工具库不是固定的：它可以采用新工具（通过 MCP 或 A2A 等开放协议），或者在更高级的设置中——学习新概念并围绕它们设计工具。
5. 最后，即使是智能体训练场这样的构造，也可能无法克服某些边缘案例（由于企业中众所周知的“部落知识”问题）。在这些情况下，我们看到智能体训练场能够连接到领域专家的人力结构，并与他们协商正确的输出集以指导下一组优化。

高级智能体示例

Google Co-Scientist（Google 联合科学家）

Co-Scientist 是一个先进的 AI 智能体，旨在作为虚拟研究协作者发挥作用，通过系统地探索复杂问题空间来加速科学发现。它使研究人员能够定义一个目标，将智能体以特定的公共和专有知识来源为基础，然后生成和评估一系列新颖的假设。

为了能够实现这一目标，Co-Scientist 孵化了一个相互协作的完整智能体生态系统。

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

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

AlphaEvolve 智能体

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

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

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

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

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

AlphaEvolve 专为人类与 AI 之间深入的、迭代的伙伴关系而设计。这种协作主要通过两种方式实现：

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

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