> ## Content Index
> Fetch the complete content index at: https://yonglun.me/llms.txt
> Use this file to discover other available public pages before exploring further.

# 智能体介绍
- URL: https://yonglun.me/introduction-to-agents/
- Published: 2025-11-17T13:51:31.000Z
- Updated: 2025-11-17T13:51:31.000Z
- Description: 《智能体介绍》，全面概述了人工智能（AI）从预测模型向自主智能体的演进。它将智能体的核心架构分解为三个要素：模型（大脑）、工具（双手）和编排层（神经系统），并详细阐述了智能体如何通过“思考、行动、观察”的循环来解决问题。此外，文档还提供了一个智能体系统分类法，从连接式问题解决者（Level 1）到协作式多智能体系统（Level 3）再到自我演化系统（Level 4），勾勒出智能体的能力层级。最后，文章强调了部署和治理的重要性，介绍了 Agent Ops 运维方法论，以及实现安全、互操作性和规模化所需的架构和协议。
- Author: Yonglun
- Tags: AI, #lang-zh

# 

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

**翻译：Google notebooklm**

**英文原版PDF下载链接：**[https://drive.google.com/file/u/0/d/1C-HvqgxM7dj4G2kCQLnuMXi1fTpXRdpx/view](https://drive.google.com/file/u/0/d/1C-HvqgxM7dj4G2kCQLnuMXi1fTpXRdpx/view?ref=yonglun.me)

---

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

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

**人工智能正在发生变化**。多年来，焦点一直放在擅长**被动、离散任务**的模型上：回答问题、翻译文本或根据提示生成图像。这种范式虽然强大，但每一步都需要持续的人工指导。我们现在正看到一场**范式转变**，从仅仅预测或创建内容的 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`。”

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

![](https://yonglun.me/content/images/2025/11/----1-------------AI-------------------.png)

图 1：****智能体** AI 问题解决过程

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

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

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

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

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

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

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

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

# **智能体系统分类法**

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

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

![](https://yonglun.me/content/images/2025/11/----2----------------------5----.png)

图 2：智能体系统分 5 步

## **级别 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”。

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

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

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

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

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

## **级别 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）智能体**分析一个复杂的请求，分割主要任务，并智能地将每个子任务路由到适当的**专业智能体**（例如研究员、作家或编码员）。然后，协调器聚合来自每个专业**智能体**的响应，以形成最终的、全面的答案。

![](https://yonglun.me/content/images/2025/11/----3----------https---cloud.google.com-architecture-choose-design-pattern-agentic-ai-system----------------------------.png)

图 3：来自 [https://cloud.google.com/architecture/choose-design-pattern-agentic-ai-system](https://cloud.google.com/architecture/choose-design-pattern-agentic-ai-system?ref=yonglun.me) 的“迭代改进”模式

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

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

## 智能体部署和服务

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

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

![](https://yonglun.me/content/images/2025/11/----4----------https---cloud.google.com-vertex-ai-generative-ai-docs-agent-engine-overview-----Vertex-AI-Agent-builder.png)

图 4：来自 [https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/overview](https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/overview?ref=yonglun.me) 的 Vertex AI Agent builder

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

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

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

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

![](https://yonglun.me/content/images/2025/11/----5---DevOps---MLOps-----GenAIOps----------------------------.png)

图 5：DevOps、MLOps 和 GenAIOps 运营领域之间的关系

**智能体运维（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：不同主体认证类别的非详尽示例

| 主体实体            | 认证/验证             | 备注                   |
| --------------- | ----------------- | -------------------- |
| **用户**          | 使用 OAuth 或 SSO 认证 | 具有完全自主权和对其行为负责的人类行动者 |
| **智能体** (新类别主体) | 使用 SPIFFE 验证      | 智能体具有委托权限，代表用户采取行动   |
| **服务账户**        | 集成到 IAM           | 应用程序和容器，完全确定性，不对行动负责 |

## **限制访问的策略**

**策略**是一种**授权（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**）——是构建一个既强大又值得信赖的单个**智能体**的方式。

![](https://yonglun.me/content/images/2025/11/----6---------------------------Security-and-Agents---------------https---saif.google-focus-on-agents.png)

图 6：安全性与智能体（Security and Agents），来源：[https://saif.google/focus-on-agents](https://saif.google/focus-on-agents?ref=yonglun.me)

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

单个 **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）修正性反馈**。然后，它将此反馈**泛化**为一个新的、可重用的指南（例如，为批评**智能体**更新规则或为报告**智能体**优化上下文）。

![](https://yonglun.me/content/images/2025/11/----7---------------------------------------------.png)

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

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

## 模拟和智能体训练场（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** 孵化了一个**相互协作的完整智能体生态系统**。

![](https://yonglun.me/content/images/2025/11/----8---AI----------------------------.png)

图 8：AI 联合科学家设计系统

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

![](https://yonglun.me/content/images/2025/11/----9---Co-Scientist----------------------.png)

图 9：Co-Scientist 多智能体工作流

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

## **AlphaEvolve 智能体**

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

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

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

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

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

![](https://yonglun.me/content/images/2025/11/----10---Alpha-Evolve-------------.png)

图 10：Alpha Evolve 设计系统

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

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

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

![](https://yonglun.me/content/images/2025/11/----11---------------.png)

图 11：算法进化