智能体简介

发表于 分类于

智能体简介

Introduction to Agents

作者：艾伦·布朗特、安东尼奥·古利、舒巴姆·萨布、迈克尔·齐默尔曼和弗拉基米尔·武斯科维奇

Agents are the natural evolution of Language Models, made usefu in software.

智能体是语言模型的自然演化，在软件中得到了应用。

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

From Predictive AI to Autonomous Agents

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

这一新兴领域的核心是AI智能体。智能体并非仅仅是静态工作流程中的人工智能模型；它是一个完整的应用程序，能够制定计划并采取行动以实现目标。它将语言模型（LM）的推理能力与实际行动的能力相结合，使其能够处理大模型自身无法单独应对的复杂的、多步骤的任务。其核心能力在于，智能体（Agent）可以独立工作，在无需人类步步引导的情况下，自行摸索出达成目标所需的后续步骤。

本文是五篇系列文章的第一篇 ，旨在为开发人员、架构师和产品负责人提供正式指南，帮助他们从概念验证过渡到稳健的、生产级的智能体系统。构建简单的原型虽然容易，但确保安全性、质量和可靠性却是一项重大挑战 。本文将提供全面的基础知识：

  • 核心解剖结构 ：将智能体分解为三个基本组成部分：推理模型、可操作工具和控制编排层（ the reasoning Model, actionable Tools, and the governing Orchestration Layer.）。

  • 能力分类 ：将智能体从简单的、相互关联的问题解决者分类到复杂的、协作的多智能体系统。

  • 架构设计（Architectural Design）： 深入探讨每个组件的实际设计考虑因素，从模型选择到工具实施。

  • 为生产而建： 建立智能体运维规范，以便评估、调试、保护和扩展智能体系统，从单个实例到具有企业治理的集群。

在前文 Agents whitepaper 和 Agent Companion 的基础上，本指南提供了构建、部署和管理新一代智能应用程序所需的基本概念和战略框架，这些应用程序能够推理、行动和观察，从而实现目标。

Words are insufficient to describe how humans interact with AI. We tend to anthropomorphize and use human terms like “think” and “reason” and “know.” We don’t yet have words for “know with semantic meaning” vs “know with high probability of maximizing a reward function.” Those are two different types of knowing, but the results are the same 99.X% of the time.

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

AI智能体简介

简而言之，AI智能体可以定义为模型、工具、编排层和运行时服务的组合，它循环使用语言模型（LM）来实现目标。这四个要素构成了任何自主系统的基本架构。

  • The Model模型（“大脑”）： 核心语言模型（LM）或基础模型是智能体处理信息、评估选项和做出决策的中央推理引擎。模型类型（通用型、微调型或多模态）决定了智能体的认知能力。智能体系统最终负责管理输入上下文窗口，即核心语言模型。

  • Tools工具（“双手”）： 这些机制将智能体的推理过程与外部世界连接起来，使其能够执行除文本生成之外的其他操作。它们包括用于访问实时事实信息的 API 扩展、代码函数和数据存储（例如数据库或向量存储）。智能体系统允许语言模型 (LM) 规划要使用的工具，执行工具，并将工具结果放入下一次 LM 调用的输入上下文窗口中。

  • The Orchestration Layer编排层（“神经系统”）： 管理智能体运行循环的底层流程。它负责规划、记忆（状态）和推理策略的执行。这一层使用提示框架和推理技术（例如思维链或者反应)负责将复杂目标分解成若干步骤，并决定何时思考何时使用工具。此外，该层还负责赋予智能体“记忆”的能力。

  • Deployment展开（“身体和腿部”）： 虽然在笔记本电脑上构建智能体程序对于原型设计来说很有效，但生产环境部署才是确保其成为可靠且易于访问的服务的关键。这包括将智能体程序托管在安全、可扩展的服务器上，并将其与必要的生产服务集成，以实现监控、日志记录和管理。部署完成后，用户可以通过图形界面访问智能体程序，其他智能体程序也可以通过智能体到智能体 (A2A) API 以编程方式访问该智能体程序。

归根结底，构建生成式AI智能体是一种开发解决方案以解决任务的新方法。传统开发者就像“砌砖工”，精确定义每一个逻辑步骤。相比之下，智能体开发者更像是导演 。他们无需为每个动作编写明确的代码，而是设定场景（指导性指令和提示）、选择演员（工具和API），并提供必要的上下文（数据）。主要任务变成了引导这个自主的“演员”完成预期的表演。

你很快就会发现，语言模型最大的优势——其惊人的灵活性——也是你最大的难题。大语言模型能够胜任任何任务的能力，反而使得我们很难迫使它可靠且完美地去执行某一项特定的任务。我们过去称之为“提示工程（prompt engineering）”，现在称之为“上下文工程（ context engineering ）”的技术，引导语言模型生成所需的输出。对于任何一次对语言模型的调用，我们都会输入指令、事实、可用调用工具、示例、会话历史记录、用户配置文件等信息——用恰当的信息填充上下文窗口，以获得所需的输出。智能体是管理语言模型输入以完成工作的软件。

当出现问题时，调试就变得至关重要。“智能体运维”本质上重新定义了我们熟悉的测量、分析和系统优化循环。通过跟踪和日志，您可以监控智能体的“思考过程”，从而识别与预期执行路径的偏差。随着模型的演进和框架的改进，开发人员的角色是提供关键要素包括：领域专业知识、鲜明的个性以及与完成实际任务所需工具的无缝集成。务必记住，全面的评估和考核往往比最初的提示更为重要。

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

In essence, an agent is a system dedicated to the art of context window curation. It is a relentless loop of assembling context, prompting the model, observing the result, and then re-assembling a context for the next step. The context may include system instructions, user input, session history, long term memories, grounding knowledge from authoritative sources, what tools could be used, and the results of tools already invoked. This sophisticated management of the model’s attention allows its reasoning capabilities to problem solve for novel circumstances and accomplish objectives.

本质上，智能体是一个专注于上下文窗口管理的系统。它是一个永不停歇的循环：构建上下文、提示模型、观察结果，然后重新构建上下文以进行下一步操作。上下文可能包括系统指令、用户输入、会话历史记录、长期记忆、来自权威来源的基础知识、可用的工具以及已调用工具的结果。这种对模型注意力的精细管理使其推理能力能够应对新的情况并实现目标。

主动问题解决过程

我们将AI智能体定义为一个完整的、目标导向的应用程序，它集成了推理模型、可操作工具和控制编排层。简而言之，就是“语言模型与工具协同工作以实现目标”。

但这一系统究竟是如何运作的呢？从接收到请求的那一刻起，到交付最终结果的那一瞬，智能体（Agent）期间究竟做了什么？

从本质上讲，智能体通过一个持续的、循环的过程来实现其目标。虽然这个循环可能变得非常复杂，但正如《智能体系统设计（Agentic System Design）》一书中详细讨论的那样，它可以分解为五个基本步骤：

  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。”

这个“思考、行动、观察”的循环不断持续——由编排层（Orchestration Layer）负责管理，模型（Model）负责推理，工具（Tools）负责执行，直到智能体的内部计划全部完成且最初的核心任务（Mission）得以实现。

让我们来看一个客户支持专员如何在这 5 个步骤的循环中运作的实际例子：

假设用户询问：“我的订单号 12345 在哪里？”

智能体并没有立即采取行动，而是首先进入“深入思考（Think It Through）”阶段，以制定出一个完整的策略。它推理道： “用户想要了解快递状态。为了提供一个完整的答复，我需要一个多步骤的计划：

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

心中带着这个多步骤计划，智能体开始执行。

在第一个“行动（Act）”阶段，它执行了计划的第一步，调用了 find_order("12345") 工具。它观察到了结果——一条完整的订单记录，其中包括物流单号“ZYX987”。

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

最终，在成功执行了计划中的数据收集阶段后，智能体转入“报告（Report）”步骤。它感知到自己已经拥有了所有必需的组件，构思好最终的信息，并通过生成回复采取了行动：“您的订单 #12345 正处于‘正在派送’状态！”

智能体系统的分类

理解五步操作循环是解决问题的第一步。第二步是认识到这个循环的复杂性可以扩展，从而创建不同类型的智能体。对于架构师或产品负责人来说，一个关键的初始决策是确定范围。什么类型的智能体构建。

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

第零级：核心推理系统

Level 0: The Core Reasoning System

在构建智能体之前，我们必须从最基本形式的“大脑”——推理引擎本身——入手。在这种配置下，语言模型（LM）独立运行，仅基于其庞大的预训练知识做出响应，无需任何工具、记忆或与实时环境的交互。

它的优势在于其广泛的训练，使其能够解释既定概念并深入规划解决问题的方法。但缺点是完全缺乏实时感知能力；它实际上对训练数据之外的任何事件或事实都“视而不见”。

例如，它可以解释职业棒球的规则和纽约扬基队的完整历史。但如果你问“昨晚扬基队比赛的最终比分是多少？”，它就无法回答。因为那场比赛是一个具体的、真实发生的事件。它的训练数据已经收集完毕，所以它的知识库中根本不存在这些信息。

第一级：关联问题解决者

Level 1: The Connected Problem-Solver

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

利用这五步循环，智能体现在可以回答我们之前的问题。给定“任务”：“昨晚洋基队比赛的最终比分是多少？”，其“思考”步骤会识别出这是一个实时数据需求。然后，其“行动”步骤会调用一个工具，例如使用正确的日期和搜索词调用谷歌搜索API。它“观察”搜索结果（例如，“洋基队以5比3获胜”），并将该信息综合成最终答案。

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

第二级：战略问题解决者

Level 2: The Strategic Problem-Solver

Level 2（第2级别）标志着能力的显著扩展，从执行简单任务跨越到对复杂的、多部分的战略目标进行规划。在这里涌现出的核心技能是上下文工程（Context Engineering）：即智能体在计划的每一步中，主动筛选、打包和管理最相关信息的能力。

智能体的准确性取决于其所处的高质量、目标明确的上下文。上下文工程旨在优化模型的注意力范围，防止其过载，从而确保高效运行。

例如，考虑一下“使命”：“请找一家不错的咖啡馆，位置在我位于山景城圆形剧场大道 1600 号的办公室和我位于旧金山市场街 1 号的客户办公室的中间。”

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

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

• 行为： 调用地图工具包含这两个地址。

• 观察： “中点是加利福尼亚州米尔布雷。”

  1. 思考 “现在我得在米尔布雷找咖啡馆。用户要求的是‘好的’咖啡馆，所以我得找评分在四星或以上的。”

• 行为： 调用谷歌地点工具查询="加州米尔布雷的咖啡店", 最低评分=4.0（这是上下文工程——它根据上一步的输出自动创建了一个新的、更聚焦的搜索查询）。

• 观察： “搜索结果为‘Millbrae Coffee’和‘The Daily Grind’。”

  1. 思考 “我会将这些结果综合起来，呈现给用户。”

这种战略规划还能提供主动协助，例如，智能体会阅读冗长的航班确认电子邮件，提取关键信息（航班号、日期），然后将其添加到您的日历中。

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

Level 3: The Collaborative Multi-Agent System

在最高层面上，范式发生了彻底的转变。我们不再构建一个全能的单一“超级智能体”，而是转向一个协同工作的“专家团队”，这种模式直接反映了人类组织的运作方式。系统的集体力量就蕴藏在这种分工之中。

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

项目经理智能体并不亲自完成所有工作。它的工作方式与现实生活中类似，即为其专业智能体团队创建新的任务：

1. 市场调研智能体的代表： “分析竞品降噪耳机的定价。明天之前提交一份总结报告。”

2. 委托给营销智能体： “以‘Solaris’产品规格表为背景，撰写三份新闻稿草稿。”

3. 委托给 WebDevAgent： “根据附件中的设计稿生成新产品页面HTML代码。”

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

第四级：自我演化系统

Level 4: The Self-Evolving System

第四级代表着从委托到自主创造和适应的重大飞跃。在这个级别，智能体系统能够识别自身能力的不足，并动态地创建新的工具甚至新的智能体来弥补这些不足。它从使用固定的资源集转变为主动扩展资源。

以我们的例子为例，负责“Solaris”项目启动的“项目经理”可能会意识到需要监控社交媒体情绪，但他的团队中却没有这样的工具或人员。

1. 思考（元推理 Meta-Reasoning）： “我必须追踪社交媒体上关于《索拉里斯》的热议情况，但我缺乏这方面的能力。”

2. 行动（自主创造 Autonomous Creation）： 它没有失败，而是调用了一个高级 AgentCreator 工具，并赋予其新的任务：“构建一个新的智能体，监控社交媒体上的关键词‘Solaris 耳机’，进行情感分析，并生成每日摘要。”

3. 观察： 我们创建、测试并立即将一个新的、专门的 SentimentAnalysisAgent 添加到团队中，随时准备为最初的任务做出贡献。

这种程度的自主性，即系统能够动态地扩展自身能力，将智能体团队转变为一个真正学习和发展的组织。

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

Core Agent Architecture: Model, Tools, and Orchestration

我们知道智能体的功能以及它的扩展方式。但我们究竟该如何实现呢？建造 它？从概念到代码的转变在于其三个核心组件的具体架构设计。

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

Model: The “Brain” of your AI Agent

语言模型（LM）是智能体的推理核心，它的选择是一项至关重要的架构决策，它决定了智能体的认知能力、运行成本和速度。然而，仅仅选择模型性能最高的模型是远远不够的。

基准测试得分往往是导致失败的常见途径。智能体在生产环境中的成功很少能用通用的学术基准来衡量。

在现实世界中，要获得成功，模型必须在智能体基础能力上表现卓越：不仅要具备高超的推理能力以应对复杂的、多步骤的问题，还要具备可靠的工具调用能力以实现与外部世界的互动。

要做好这一点，首先要明确业务问题 ，然后根据与该结果直接相关的指标来测试模型。如果你的智能体需要编写代码，请在你的私有代码库上进行测试。如果它处理保险索赔，请评估它从你的特定文档格式中提取信息的能力。然后，必须将此分析与成本和延迟等实际情况进行交叉验证。“最佳”的模型，是指在你的特定任务中，能够完美兼顾质量、速度与价格，并在三者之间取得最佳平衡点的那个模型。

你可以选择不止一个模型，而是组建一支“专家团队”。常言道，杀鸡焉用牛刀。一个强健的智能体架构可能会采用像 Gemini 2.5 Pro 这样的前沿模型，来承担初始规划和复杂推理等繁重工作，然后智能地将任务量大但相对简单的任务（例如对用户意图进行分类或总结文本）分流给速度更快、成本效益更高的模型（如 Gemini 2.5 Flash）。这种模型路由（Model Routing）可以是自动的，也可以是硬编码的，但它都是优化性能和控制成本的核心策略。

同样的原则也适用于处理多样化的数据类型。虽然像 Gemini 实时模式（Live Mode）这样原生支持多模态的模型为处理图像和音频提供了一条精简的路径，但另一种替代方案则是使用专门的工具，如 Cloud Vision API 或 Speech-to-Text API。

在这种模式下，外部世界的信息首先被转化为文本，然后再传递给纯语言模型进行推理。这种方式增加了灵活性，并允许选用各领域最顶尖的组件，但同时也引入了相当高的复杂度。

最后，AI 领域正处于持续、快速的演进状态之中。你今天选择的模型，在六个月后就会被更先进的模型所取代。那种“一劳永逸”的心态是难以为继的。

为了应对这一现实，在构建系统时必须投入精力打造一个敏捷的运维框架——即“智能体运维（Agent Ops）”实践。通过建立一个强健的 CI/CD 流水线，根据你的核心业务指标对新模型进行持续评估，你可以降低升级风险并加速迭代，从而确保你的智能体始终由最强大的“大脑”驱动，而无需对整体架构进行彻底的重构。

个人注：CI/CD 流水线

持续集成（Continuous Integration）和持续交付/持续部署（Continuous Delivery/Continuous Deployment）。

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

Tools: The “Hands” of your AI Agent

如果说模型是智能体的大脑，那么工具就是连接其推理与现实的双手。它们使智能体能够超越静态的训练数据，获取实时信息并在现实世界中采取行动。一个强大的工具接口是一个三步循环：定义工具的功能、调用工具以及观察结果。

以下是一些智能体平台搭建商会提供给其智能体的主要工具类型。如需更深入的了解，请参阅本系列中专门介绍智能体工具的白皮书。

信息检索：立足现实

Retrieving Information: Grounding in Reality

获取最新信息的能力是最基础的工具。检索增强生成（RAG） 它赋予智能体一张“借书证”，用于查询外部知识，这些知识通常存储在向量数据库 或者知识图谱 ，范围涵盖公司内部文档到通过谷歌搜索获取的网络知识。对于结构化数据，自然语言到 SQL (NL2SQL) 工具使智能体能够查询数据库，回答诸如“上个季度我们最畅销的产品是什么？”之类的分析性问题。通过在说话前查找信息（无论是在文档中还是在数据库中），智能体能够立足于事实，从而大大减少幻觉。

执行行动：改变世界

Executing Actions: Changing the World

当智能体从阅读信息转变为主动执行任务时，它们的真正力量才能被释放出来。通过封装现有信息，智能体可以更好地发挥其作用。API 通过将代码功能作为工具，客服人员可以发送电子邮件、安排会议或更新 ServiceNow 中的客户记录。对于更动态的任务，客服人员可以即时编写和执行代码。在安全的沙箱环境中，它可以生成 SQL 查询或 Python 脚本来解决复杂问题或执行计算，从而从一个知识渊博的助手转变为一个真正的自主行动者。

这也包括用于人类交互的工具。智能体可以使用人机协同（Human in the Loop, HITL）工具来暂停其工作流并请求确认（例如：ask_for_confirmation()），或者通过用户界面请求特定的信息（例如：ask_for_date_input()），从而确保人类能够参与到关键的决策当中。HITL 既可以通过短信（SMS）文本消息来实现，也可以通过数据库中的任务列表来落实。

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

Function Calling: Connecting Tools to your Agent

为了让智能体能够可靠地进行“函数调用（Function Calling）”并使用工具，它需要清晰的指令、安全的连接以及周密的编排。诸如 OpenAPI 规范这类长期存在的标准便提供了这些支持，它为智能体提供了一个结构化的契约，用以描述工具的用途、所需的参数以及预期的响应结果。这种架构（Schema）使大模型每次都能生成正确的函数调用并理解 API 的响应。而为了更简单地发现和连接工具，像模型上下文协议（Model Context Protocol, MCP）这样的开放标准因其更加便捷而变得流行起来。此外，少数模型还拥有原生工具，例如 Gemini 具有原生的谷歌搜索（Google Search）功能，其函数的调用本身就是语言模型（LM）调用的一部分。

编排层

The Orchestration Layer

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

核心设计选择

Core Design Choices

首要的架构决策是确定智能体的自主程度。 这一选择存在于一个光谱（连续体）之上。在光谱的一端，是确定性强、可预测的工作流，它仅将语言模型（LM）作为执行特定任务的工具来调用——即通过引入少许 AI 来增强现有流程。而在光谱的另一端，则是让语言模型稳坐驾驶位，由其动态地调整、规划并执行各项任务以达成目标。

与之并行的另一个抉择是实现方式。 无代码构建工具（No-code builders） 提供了极高的速度与准入门槛的降低，使业务人员能够快速实现结构化任务的自动化并构建简单的智能体。而对于更复杂、关乎核心业务的系统，代码优先（Code-first）的框架 ——例如谷歌的智能体开发套件（Agent Development Kit, ADK）——则提供了工程师所必需的深度控制、定制化以及集成能力。

无论采用哪种方法，一个生产级别的框架都是必不可少的。它必须具备开放性，允许你接入任何模型或工具，以防止供应商锁定。它还必须提供精准的控制，从而支持一种混合模式 ：用硬编码的业务规则来约束语言模型非确定性的推理过程。最重要的一点是，该框架必须为了可观测性（Observability）而设计 。当智能体出现异常行为时，你无法简单地在模型的“思考”中设置一个断点。一个强健的框架能够生成详细的追踪（Traces）和日志，将整个推理轨迹完全暴露出来：包括模型的内部独白、它选择的工具、它生成的参数以及它观察到的结果。

运用领域知识和角色进行指导

Instruct with Domain Knowledge and Persona

在此框架下，开发者最有效的手段是赋予智能体领域知识和独特的角色。这可以通过系统提示或一组核心指令来实现。这不仅仅是一条简单的命令，而是智能体的构成要素。

在这里，你告诉它：“你是一名 Acme 公司的得力客户服务智能体，……”，并向其提供约束条件、期望的输出架构、交互规则、特定的语气风格，以及关于何时以及为何应当使用其工具的明确指引。在指令中加入几个场景示例通常会非常有效。

增强上下文信息

Augment with Context

智能体的“记忆”在运行时被整合到 LM 上下文窗口中。如需更深入的了解，请参阅本系列中专门介绍智能体记忆的白皮书。

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

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

多智能体系统与设计模式

Multi-Agent Systems and Design Patterns

随着任务复杂性的增加，构建一个单一的、全能的“超级智能体”效率会降低。更有效的解决方案是采用“专家团队（team of specialists）”模式，这种模式类似于人类组织。这是多智能体系统的核心：一个复杂的过程是任务被分解成若干独立的子任务，每个子任务都分配给一个专门的、专业的AI智能体。这种分工使得每个智能体都更简单、更专注，也更容易构建、测试和维护，这对于动态或长期运行的业务流程来说非常理想。

架构师可能会依赖成熟的智能体设计模式，尽管智能体的能力以及由此产生的模式都在不断发展快速演变。 对于动态或非线性任务，协调员 模式至关重要。它引入了一个“管理”智能体，该智能体分析复杂的请求，将主要任务分解，并智能地将每个子任务分配给相应的专家智能体（例如研究员、撰稿人或程序员）。然后，协调智能体汇总每位专家的回复，形成最终的、全面的答案。

对于更线性的工作流程，顺序 这种模式更合适，它就像一条数字装配线，一个智能体的输出直接成为下一个智能体的输入。其他关键模式则侧重于质量和安全。迭代改进 该模式创建了一个反馈回路，使用“生成器”智能体创建内容，并使用“评论家”智能体对其进行评估质量标准。对于高风险任务，人机交互（HITL） 模式至关重要，它需要在工作流程中刻意暂停，以便在智能体采取重大行动之前获得相关人员的批准。

智能体部署和服务

Agent Deployment and Services

构建好本地智能体后，您需要将其部署到服务器上，使其持续运行，以便其他用户和智能体可以使用。继续沿用之前的比喻，部署和服务就好比智能体的身体和腿。 智能体要有效运行，需要多种服务，例如会话历史记录和内存持久化等等。作为智能体构建者，您还需要负责决定记录哪些信息，以及采取哪些安全措施来保护数据隐私、确保数据驻留安全并符合相关法规。所有这些服务都包含在将智能体部署到生产环境时需要考虑的范围内。

幸运的是，智能体构建者可以依赖沉淀了数家之久的应用程序托管基础设施。毕竟，智能体也是一种新形态的软件，许多相同的软件工程原则依然适用。构建者可以依赖专为智能体打造的特定部署选项，例如 Vertex AI Agent Engine，它在同一个平台中集成了运行时（Runtime）以及所有其他必要的支持。而对于希望更直接地控制其应用技术栈，或者希望将智能体部署在现有 DevOps 基础设施中的软件开发人员来说，任何智能体以及绝大多数智能体服务都可以打包进 Docker 容器中，并部署到诸如 Cloud Run 或 GKE（Google Kubernetes Engine）等行业标准的运行时上。

如果你不是软件开发人员或 DevOps 专家，部署你的第一个智能体的过程可能会令人望而生畏。许多智能体框架通过一个部署命令（deploy command）或专用的部署平台简化了这一流程，在早期的探索和入门阶段，应当充分利用这些便利。然而，为了升级到安全且具备生产级别的环境，通常需要投入更多的时间并应用最佳实践，这其中就包括为你的智能体引入 CI/CD 和自动化测试。

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

Agent Ops: A Structured Approach to the Unpredictable

在构建你的第一个智能体时，你需要反复手动测试其行为。添加新功能后，它是否有效？修复错误后，是否又引入了其他问题？测试在软件开发中很常见，但在生成式人工智能领域却有所不同。

从传统的确定性软件向随机的智能体系统过渡需要一种新的运行理念。传统的软件单元测试可以简单地断言：输出与预期相符。但当智能体的响应本身就是概率性的，这种方法就行不通了。此外，由于语言的复杂性，通常需要语言模型来评估“质量”——即智能体的响应是否做到了所有应该做的事情，没有做任何不应该做的事情，并且语气恰当。

智能体运维（Agent Ops）是管理这一新现实的一种严谨、结构化的方法。它是开发运维（DevOps）和模型运维（MLOps）的自然演进，专门针对构建、部署和治理 AI 智能体所带来的独特挑战而量身定制，从而将不可预测性从一种劣势转变为可控、可衡量且可靠的特性。如需更全面的深度探讨，请参阅本系列中专注于智能体质量的白皮书。

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

Measure What Matters: Instrumenting Success Like an A/B Experiment

在改进客服系统之前，您必须首先定义“更好”在您的业务环境中意味着什么。将您的可观测性策略构建成类似 A/B 测试的框架，并问问自己：哪些关键绩效指标 (KPI) 可以证明客服系统正在创造价值？这些指标不应仅仅关注技术上的正确性，而应衡量实际影响：目标完成率、用户满意度评分、任务延迟、每次交互的运营成本，以及——最重要的是——对收入、转化率或客户留存率等业务目标的影响。这种自上而下的视角将指导您后续的测试工作，引领您走上指标驱动开发的道路，并帮助您计算投资回报率。

质量评价而非及格/不及格：使用LM评测器

Quality Instead of Pass/Fail: Using a LM Judge

业务指标无法判断智能体的行为是否正确。由于简单的通过/失败判定无法实现，我们转而采用“学习模型作为评判者”来评估智能体的质量。这需要使用一个强大的模型，根据预定义的标准来评估智能体的输出：它是否给出了正确答案？答案是否基于事实？它是否遵循了指令？这种基于黄金数据集的自动化评估，能够提供一致的质量衡量标准。

创建评估数据集（包括理想（或“黄金”）问题和正确答案）可能是一个繁琐的过程。为了构建这些数据集，您应该从现有生产或开发环境中与智能体的交互场景中抽取样本。数据集必须涵盖您预期用户会遇到的所有用例，以及一些意料之外的用例。虽然对评估的投入很快就能获得回报，但评估结果始终应该经领域专家审核后方可被采纳为有效评估结果。在领域专家的支持下，这些评估结果的整理和维护正日益成为产品经理的一项关键职责。

指标驱动开发：部署是否可行的关键因素

Metrics-Driven Development: Your Go/No-Go for Deployment

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

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

Debug with OpenTelemetry Traces: Answering “Why?”

当你的指标下降或用户报告 Bug 时，你需要理解“为什么”。一个 OpenTelemetry 追踪（Trace）是对智能体整个执行路径（轨迹）的高保真、分步记录，它允许你对智能体的各个步骤进行调试。

通过追踪，你可以看到发送给模型的准确提示词（Prompt）、模型的内部推理过程（如果可用）、它选择调用的特定工具、它为该工具生成的精确参数，以及作为观察结果返回的原始数据。初次接触追踪时可能会觉得它很复杂，但它们提供了诊断和修复任何问题根本原因所需的详尽细节。重要的追踪细节可以被转化为指标，但审查追踪主要用于调试，而非性能的宏观概览。追踪数据可以无缝收集到诸如 Google Cloud Trace 等平台中，这些平台能够对海量的追踪进行可视化和搜索，从而简化根本原因分析的工作流。

重视人类反馈：指导您的自动化

Cherish Human Feedback: Guiding Your Automation

用户反馈并非令人烦恼的麻烦事，而是您改进客服系统最宝贵、数据最丰富的资源。当用户提交错误报告或点击“踩”按钮时，他们其实是在赠送您一份礼物：一个全新的、真实世界的极端案例，而您的自动化评估场景却未能捕捉到。收集和汇总这些数据至关重要；当您发现大量类似的报告或指标出现显著下降时，必须将这些事件与您的分析平台关联起来，以便生成洞察并触发针对运营问题的警报。高效的客服运维流程通过捕获这些反馈、重现问题并将该特定场景转化为评估数据集中的全新永久测试用例，从而实现“闭环”。 这不仅确保您修复了错误，还能使系统免受此类错误的再次发生。

智能体互操作性

Agent Interoperability

一旦你构建了高质量的智能体，你就需要将它们与用户和其他智能体连接起来。用身体部位来比喻，这就好比是智能体的“脸”。连接智能体与将智能体与数据和API连接起来是有区别的；智能体不是工具26假设您已经将工具集成到您的智能体中，现在让我们考虑如何将您的智能体融入更广泛的生态系统。

智能体与人类

Agents and Humans

最常见的智能体与人类交互的形式是通过用户界面（UI）。在其最简单的形态中，这表现为一个聊天机器人：用户输入请求，而作为后端服务的智能体对其进行处理并返回一段文本。更高级的智能体则可以提供诸如 JSON 的结构化数据，以驱动丰富、动态的前端体验。人机协同（HITL）的交互模式包括意图提炼、目标扩展、二次确认以及澄清请求。

计算机使用（Computer use）是一类特殊的工具，在这种模式下，语言模型会接管用户界面，通常伴随着人类的交互和监督。一个具备计算机使用能力的智能体可以判定，下一步的最佳操作是跳转到一个新页面、高亮显示一个特定按钮，或是用相关信息预填表格。

除了智能体代表用户使用界面之外，语言模型还可以改变 UI 以满足当下的需求。这可以通过控制 UI 的工具（如 MCP UI）、能够将客户端状态与智能体同步的专用 UI 消息系统（如 AG UI），乃至生成定制化界面（A2UI）来实现。

当然，人类的交互并不局限于屏幕和键盘。先进的智能体正在打破文本的壁垒，迈向实时、多模态的沟通，其“实时模式（live mode）”创造了一种更自然、更像人类的连接。诸如 Gemini Live API 等技术实现了双向流式传输，允许用户向智能体说话并打断它，就像在日常的自然对话中一样。

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

这开辟了文本无法实现的各种应用场景，例如技术人员在维修设备时可以获得免提指导，以及购物者可以获得实时穿搭建议。这使得客服人员成为更直观、更易于沟通的合作伙伴。

智能体和智能体

Agents and Agents

正如智能体必须与人类互动一样，它们也必须彼此连接。随着企业扩大人工智能的应用规模，不同的团队会构建不同的专业化智能体。如果没有通用标准，连接这些智能体就需要构建一个错综复杂、脆弱且难以维护的自定义API集成网络。核心挑战有两个方面：发现（我的智能体如何找到其他智能体并了解它们的功能？）和通信（我们如何确保它们使用相同的语言？）。

Agent2Agent (A2A) 协议 是旨在解决此问题的开放标准。它充当智能体经济的通用握手协议。A2A 允许任何智能体发布数字“名片”，称为智能体卡。这个简单的 JSON 文件会公布智能体的功能、网络端点以及与其交互所需的安全凭证。这使得智能体发现变得简单且标准化。与专注于解决事务性请求的 MCP 不同，智能体 2 智能体通信通常用于解决其他问题。

一旦被发现，智能体便会使用面向任务的架构进行通信。交互不再是简单的请求-响应，而是以异步“任务”的形式进行。客户端智能体向服务器智能体发送任务请求，服务器智能体随后可以通过长时间连接，在处理问题的同时提供流式更新。这种强大且标准化的通信协议是实现自动化前沿的协作式三级多智能体系统的最后一块拼图。A2A 将一组孤立的智能体转变为一个真正可互操作的生态系统。

智能体和资金

Agents and Money

随着AI智能体承担越来越多的任务，其中一些任务涉及买卖、谈判或促成交易。当前的互联网是为人类点击“购买”按钮而设计的，责任也由人类承担。如果由自主智能体点击“购买”，就会引发信任危机——一旦出现问题，责任该由谁承担？这些都是关于授权、真实性和问责制的复杂问题。为了真正实现智能体经济，我们需要新的标准，使智能体能够代表用户安全可靠地进行交易。

这一新兴领域远未成熟，但两项关键协议正在为其铺平道路。智能体支付协议（AP2） 是一个开放协议，旨在成为智能体商务的权威语言。它通过引入加密签名的数字“授权”扩展了 A2A 等协议。这些授权可作为用户意图的可验证证明，为每笔交易创建不可否认的审计跟踪。这使得智能体能够基于用户授予的授权，在全球范围内安全地浏览、协商和交易。此外，还有x402 这是一个开放的互联网支付协议，使用标准的 HTTP 402“需要支付”状态码。它支持无摩擦的机器对机器微支付，允许智能体按需付费购买 API 访问权限或数字内容等，而无需复杂的账户或订阅。这些协议共同构建了智能体网络的基础信任层。

个人注：

HTTP 402 是一个 HTTP 状态码，它的官方标准名称是**“Payment Required”（需要付款）** 。

它属于 4xx 客户端错误状态码系列（这类状态码通常意味着请求包含错误或无法被满足）。

HTTP 402 是一个诞生于互联网早期、本意用于网络微支付，但如今被广泛应用于API 欠费、充值提示或支付失败 场景的特殊状态码。

选择单一智能体：信任权衡

Securing a Single Agent: The Trust Trade-Off

当你创建第一个 AI 智能体时，你会立刻面临一个根本性的张力：实用性与安全性之间的权衡。要让智能体发挥作用，你必须赋予它权力——即做出决策的自主权，以及发送电子邮件或查询数据库等执行操作的工具。然而，你赋予的每一分权力都会带来相应程度的风险。主要的安全性考量在于流氓行为（Rogue actions，即无意或有害的行为）以及敏感数据的泄露。你想给你的智能体一条足够长、长到可以完成工作的牵引绳，但也必须足够短，短到能防止它冲进车流之中——尤其是当这些“车流”涉及不可逆的操作或你公司的私有数据时。

为了管理这一风险，你不能完全依赖 AI 模型自身的判断，因为它可以被诸如提示词注入（Prompt injection）等技术所操纵。相反，最佳实践是采用一种混合的、纵深防御（Defense-in-depth）的方法。

第一层由传统的、确定性的栅栏（Guardrails）组成——这是一套硬编码的规则，在模型推理过程之外充当安全关卡。这可以是一个策略引擎，用以拦截任何超过 100 美元的采购，或者在智能体与外部 API 交互之前要求用户进行显式确认。这一层为智能体的权力提供了可预测、可审计的硬性限制。

第二层则利用基于推理的防御，即“用 AI 来保障 AI 的安全”。这包括训练模型使其对攻击更具韧性（对抗性训练），以及采用体积更小、更专业的“防御模型（Guard models）”，让它们扮演安全分析师的角色。这些模型可以在智能体提出的计划付诸执行之前对其进行审查，标记出潜在风险或违反策略的步骤以供复核。这种结合了代码的刚性确定性与 AI 的上下文感知能力的混合模式，即使对于单个智能体而言也能构建出强健的安全态势，从而确保其权力始终与其使命保持一致。

智能体身份：一种新型委托人

Agent Identity: A New Class of Principal

在传统的安全模型中，存在可能使用 OAuth 或 SSO 的人类用户，以及使用 IAM 或服务账户的服务。而智能体则引入了第三类“主体（Principal）”。智能体不仅仅是一段代码，它是一个自主的行动者，是一种需要其自身可验证身份的新型主体。就像员工会被发放工牌一样，平台上的每个智能体也必须被授予一个安全、可验证的“数字护照”。这种“智能体身份（Agent Identity）”与启动它的用户身份以及开发它的开发者身份是截然不同的。这是企业在处理身份与访问管理（IAM）时必须面对的根本性转变。

确保每一个身份都经过验证，并对所有这些身份实施访问控制，是智能体安全的核心基石。一旦智能体拥有了加密可验证的身份（通常使用 SPIFFE 等标准），就可以被授予其自身特定的、最小特权的权限。例如，“销售智能体（SalesAgent）”被授予对 CRM 的读写权限，而“人力资源入职智能体（HRonboardingAgent）”则被明确拒绝该权限。这种细粒度的控制至关重要。它确保了即使单个智能体受到攻击或出现异常行为，潜在的爆炸半径（Blast radius，即受影响范围）也会被控制在有限范围内。如果没有智能体身份这一概念的构建，智能体就无法在有限的委托授权下代表人类开展工作。

表 1：身份验证中不同类别参与者的示例（并非详尽无遗）。

限制访问的策略

Policies to Constrain Access

策略是一种授权 (AuthZ) 形式，与身份验证 (AuthN) 不同。通常，策略会限制主体的权限；例如，“市场部的用户只能访问这 27 个 API 端点，且不能执行 DELETE 命令。” 在开发智能体时，我们需要对智能体、其工具、其他内部智能体、它们可以共享的上下文以及远程智能体应用权限。不妨这样想：如果您将所有 API、数据、工具和智能体都添加到系统中，那么您必须将访问权限限制在完成其工作所需的特定子集内。这是推荐的做法：在保持权限控制的前提下，应用最小权限原则。与上下文相关的。

保障 ADK 智能体的安全

Securing an ADK Agent

在确立了身份验证和策略的核心原则之后，保障基于智能体开发套件（ADK）构建的智能体的安全，便演变为了一个通过代码和配置将这些概念付诸实践的过程。

正如上文所述，这一过程需要对各类身份进行清晰的定义：用户账户（例如 OAuth）、服务账户（用于运行代码）以及智能体身份（用于行使委托权限）。一旦处理好身份验证，下一层防御就涉及建立策略以限制对服务的访问。这通常在 API 治理层完成，并伴随着对 MCP（模型上下文协议）和 A2A（智能体对智能体）服务的治理支持。

再往后一层是在你的工具、模型和子智能体中构建栅栏（Guardrails）以强制执行策略。这可以确保无论语言模型如何推理，也无论恶意提示词如何诱导，工具自身的逻辑都会拒绝执行不安全或违反策略的操作。这种方法提供了一个可预测且可审计的安全基线，将抽象的安全策略转化为具体、可靠的代码。

为了实现能够适应智能体运行时行为的更动态的安全防护，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 蔓延一样，当智能体和工具在组织内激增时，它们构建了一个全新的、复杂的交互网络、数据流以及潜在的安全漏洞。管理这种复杂性需要一个更高层次的治理层，将所有身份、策略和报告整合到一个中央控制平面中。

安全与隐私：强化智能体边界

Security and Privacy: Hardening the Agentic Frontier

企业级平台必须应对生成式人工智能固有的独特安全和隐私挑战，即使仅运行单个智能体也是如此。智能体本身会成为新的攻击途径。恶意行为者可能会尝试快速注射 劫持智能体的指令，或者数据中毒 它会破坏用于训练或 RAG 的信息。此外，约束不足的智能体可能会在其响应中无意泄露敏感的客户数据或专有信息。

一个强大的平台能够提供纵深防御策略来降低这些风险。它首先从数据入手，确保企业的专有信息绝不会用于训练基础模型，并受到诸如 VPC 服务控制之类的保护措施。它需要输入输出过滤，如同防火墙一般保护提示和响应。最后，该平台必须提供合同保护，例如针对训练数据和生成输出的知识产权赔偿，从而赋予企业在生产环境中部署智能体所需的法律和技术保障。

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

Agent Governance: A Control Plane instead of Sprawl

随着智能体及其工具在组织内迅速扩散，它们会形成一个全新的、复杂的交互网络，并带来潜在的安全漏洞，这种挑战通常被称为“智能体蔓延”。应对这一挑战需要超越保护单个智能体的层面，转而实施更高层次的架构方法：建立一个中央网关，作为所有智能体活动的控制平台。

想象一下，一座熙熙攘攘的大都市里，成千上万辆自动驾驶车辆——用户、智能体和工具——都在有目的地运行。如果没有交通信号灯、车牌和中央控制系统，将会一片混乱。网关方法正是构建了这样一个控制系统，它为所有智能体流量（包括用户到智能体的提示或用户界面交互、智能体到工具的调用（通过 MCP）、智能体到智能体的协作（通过 A2A）以及直接向 LM 发出的推理请求）建立了一个强制入口点。通过占据这个关键的交汇点，组织可以检查、路由、监控和管理每一次交互。

该控制平面具有两个主要且相互关联的功能：

1. 运行时策略执行（Runtime Policy Enforcement）： 它作为架构中安全实施的关键节点，负责处理身份验证（“我是否认识这个参与者？”）和授权（“他们是否拥有执行此操作的权限？”）。集中式的安全执行提供了一个“单一窗口”以方便观察，为每笔交易创建通用日志、指标和追踪记录。这使得原本分散的智能体和工作流程变得混乱不堪，最终形成一个透明且可审计的系统。

2. 集中式治理（Centralized Governance）： 为了有效执行策略，网关需要一个权威的数据源。这由中央注册表 提供——一个用于存放智能体和工具的企业应用商店。该注册表允许开发人员发现并重用现有资产，从而避免重复工作，同时为管理员提供完整的资产清单。更重要的是，它为智能体和工具建立了正式的生命周期管理，允许在发布前进行安全审查、版本控制，并创建细粒度的策略来规定哪些业务部门可以访问哪些智能体。

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

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

Cost and Reliability: The Infrastructure Foundation

归根结底，企业级智能体必须兼具可靠性和成本效益。频繁故障或响应缓慢的智能体会带来负投资回报率。反之，成本过高的智能体则无法扩展以满足业务需求。底层基础设施的设计必须能够权衡这种利弊，确保安全性，并符合监管和数据主权要求。

在某些情况下，当特定智能体或子功能的流量具有不规则性时，“缩容至零（Scale-to-zero）”便是你所需要的功能。而对于关乎核心业务且对延迟敏感的工作负载，平台则必须提供专用的、有保障的能力，例如针对语言模型（LM）服务的预置吞吐量（Provisioned Throughput），或者针对 Cloud Run 等运行时提供 99.9% 的服务等级协议（SLA）。这提供了可预测的性能，确保你最重要的智能体即使在高负载下也始终能够即时响应。通过提供这一系列的基础设施选项，并结合对成本和性能的全面监控，你便为将 AI 智能体从一项前景广阔的创新技术扩展为企业核心、可靠的组件奠定了最后一块至关重要的基石。

智能体如何演化和学习

How agents evolve and learn

部署在真实世界中的智能体运行在动态的环境中，其中的策略、技术和数据格式都在不断发生变化。如果缺乏适应能力，智能体的性能随着时间的推移就会出现退化——这一过程通常被称为“老化（Aging）”——从而导致其实用性和信任度的丧失。通过手动更新庞大的智能体集群来跟上这些变化的步伐，既不经济也非常缓慢。一个更具扩展性的解决方案是设计能够自主学习和演进的智能体，使其在工作岗位上只需极少的工程投入便能不断提升自身的质量。

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

How agents learn and self evolve

与人类类似，智能体通过经验和外部信号进行学习 。这一学习过程由多种信息来源驱动：

  • 运行时体验： 智能体通过会话日志、跟踪记录和内存等运行时工件进行学习，这些工件记录了成功、失败、工具交互和决策轨迹。至关重要的是，这包括人机交互（HITL）反馈，它提供权威的纠正和指导。

  • 外部信号： 学习也受到新的外部文件的影响，例如更新的企业政策、公共监管指南或其他机构的批评。

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

  • 增强型上下文工程： 该系统不断优化提示、少量镜头示例以及从内存中检索的信息。通过针对每个任务优化提供给语言模型的上下文，它可以提高任务成功的概率。

  • 工具优化和创建： 智能体的推理能力可以识别自身能力的不足，并采取行动弥补这些不足。这可能包括获取新工具、即时创建新工具（例如，Python 脚本）或修改现有工具（例如，更新 API 架构）。

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

例如：学习新的合规指南

设想一家企业智能体公司在金融或生命科学等监管严格的行业中运营。其任务是生成必须符合隐私和监管规则（例如 GDPR）的报告。

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

  1. 一个查询智能体 响应用户请求检索原始数据。
  2. 一个报告智能体 将这些数据综合成一份报告草稿。
  3. 一个批判智能体 审核人员在掌握相关合规准则后，对报告进行审核。如果遇到歧义或需要最终签字确认，则会将审核工作上报给领域专家。
  4. 一个学习智能体 观察整个交互过程，特别关注人类专家的纠正性反馈。然后，它将这些反馈概括为新的、可重用的指导原则（例如，为批评智能体更新的规则或为报告智能体完善的上下文）。

例如，如果专家指出某些家庭统计数据必须匿名化，学习智能体会记录这一更正。下次生成类似报告时，评估智能体会自动应用这条新规则，从而减少人工干预的需要。这种评估、人工反馈和概括的循环使系统能够自主适应不断变化的合规要求。

模拟与智能体训练——下一个前沿领域

Simulation and Agent Gym - the next frontier

我们所介绍的这种设计模式可以被归类为“在线学习（In-line learning）”，即智能体需要利用其在构建时所配备的资源和设计模式来进行学习。目前，研究人员正在探索更为先进的方法，即通过一个专用的平台，在离线流程中利用先进的工具和功能来优化多智能体系统，而这些工具和功能并不属于多智能体运行时（Run-time）环境的一部分。这样一个“智能体健身房（Agent Gym）”的核心属性包括：

  1. 它不在执行路径上 ：它是一个独立的、生产环境之外的平台，因此可以借助任何语言模型（LM）、离线工具、云应用程序等提供协助。
  2. 它提供了一个模拟环境 ：使得智能体可以在新数据上进行“演练”并学习。这种模拟环境非常适合通过多种优化路径进行“试错”。
  3. 它可以调用先进的合成数据生成器 ：这些生成器能够引导模拟过程尽可能贴近现实，并对智能体进行压力测试（这可以包括诸如红队对抗、动态评估以及一系列批判智能体等先进技术）。
  4. 其优化工具库并非固定不变 ：它可以采纳新的工具（无论是通过 MCP 或 A2A 等开放协议），或者在更高级的设定下——学习新概念并围绕这些概念自主打造工具。
  5. 最后，即使是像 Agent Gym 这样的架构，也可能无法克服某些极端情况（Edge-case） ：（这是由于企业中普遍存在的“隐性知识/部落知识”问题所致）。在这些情况下，我们能看到 Agent Gym 可以连接到由领域专家组成的人类网络，并向他们咨询正确的预期结果，以指导下一阶段的优化。

高级智能体示例

Examples of advanced agents

谷歌联合科学家

Google Co-Scientist

Co-Scientist 是一款先进的AI智能体，旨在作为虚拟研究合作者，通过系统地探索复杂的难题领域来加速科学发现。它使研究人员能够定义目标，将智能体置于指定的公共和专有知识库中，然后生成并评估一系列新颖的假设。

为了实现这一目标，Co-Scientist 构建了一个由相互协作的智能体组成的完整生态系统。

可以将该系统视为一个科研项目经理。人工智能首先会设定一个宽泛的科研目标，并据此制定详细的项目计划。“主管”智能体则扮演经理的角色，将任务分配给由多个专业智能体组成的团队，并分配计算能力等资源。这种结构确保项目能够轻松扩展，并且团队的方法也会随着他们朝着最终目标不断改进。

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

AlphaEvolve 智能体

AlphaEvolve Agent

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

AlphaEvolve 的工作原理是将我们 Gemini 语言模型的创造性代码生成功能与自动化评估系统相结合。它采用一种进化过程：人工智能生成潜在的解决方案，评估人员对其进行评分，并将最有前景的想法作为下一代代码的灵感来源。

这种方法已经取得了一些重大突破，包括：

  • 提升谷歌数据中心、芯片设计和人工智能训练的效率。

  • 探索更快的矩阵乘法算法。

  • 寻找解决未解数学问题的新方法。

AlphaEvolve 擅长解决那些验证解决方案质量远比找到解决方案本身容易的问题。

AlphaEvolve旨在实现人类与人工智能之间深入、迭代的合作关系。这种合作主要通过两种方式实现：

  • 透明的解决方案： 人工智能生成的解决方案是人类可读的代码。这种透明性使用户能够理解其逻辑、获得洞见、信任结果，并直接根据自身需求修改代码。

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

该智能体的结果是代码不断改进，从而不断提升人类指定的各项指标。

结论

Conclusion

生成式AI智能体标志着人工智能发展的一个关键转折点，它将人工智能从被动的内容创作工具转变为积极主动、自主解决问题的伙伴。本文提供了一个用于理解和构建这些系统的正式框架，超越了原型阶段，建立了一个可靠的、生产级的架构。

我们将智能体分解为三个基本组成部分：推理能力模型 （“大脑”），可操作的工具 （“手”），以及统治编排层 （“神经系统”）。正是这些部分的无缝整合，在一个持续的“思考、行动、观察”循环中运行，才释放了智能体的真正潜能。通过对智能体系统进行分类——从一级互联问题解决器到三级协作多智能体系统——架构师和产品负责人现在可以根据当前任务的复杂性，战略性地规划他们的目标。

核心挑战和机遇在于一种全新的开发者范式。 我们不再仅仅是定义显式逻辑的“砌砖工”，而是必须引导、约束和调试自主实体的“架构师”和“总监”。 语言模型（LM）强大的灵活性也正是其不可靠性的根源。 因此，成功并非仅仅取决于初始提示，而是取决于应用于整个系统的严谨工程设计：包括强大的工具契约、弹性错误处理、精细的上下文管理以及全面的评估。

本文概述的原则和架构模式构成了基础蓝图。它们是引领我们探索软件新领域的指路明灯，使我们能够构建的不仅仅是“工作流自动化”，而是真正协作、高效且适应性强的团队新成员。随着这项技术的成熟，这种严谨的架构方法将成为充分发挥智能体人工智能全部潜能的关键因素。