本人也在AI agent领域浮沉了一段时间了，落地过几个Agent架构的产品，对Agent的认识逐渐清晰具象。当首次看到Google的Agent白皮书时（https://www.kaggle.com/whitepaper-agents），不觉间竟坐在咖啡厅里一口气读完了。期间不断赞叹你歌还是你歌，清晰易懂且专业。大概也是因为真正去做过Agent的产品，平时也有很多深度思考，所以我认为这篇Agent真的非常必读。因此，想以谷歌白皮书（自己手动机翻）的中文版作为主线，并穿插一些我个人积累的Agent的关键点和前沿观点，整理成一篇适合AI产品经理读的Agent文章。

一、引言——什么是智能体

人类在复杂的模式识别任务中表现卓越，但通常需要借助工具（如书籍、搜索引擎或计算器）来补充先验知识以得出结论。同理，生成式AI模型可通过训练使用工具获取实时信息或建议的实际动作。例如：

  • 模型可利用数据库检索工具获取客户购买历史以生成个性化购物推荐

  • 基于用户查询，模型可通过API调用发送邮件或完成金融交易

为实现此能力，模型需具备：

  1. 外部工具集访问权限

  2. 自主规划与执行任务的推理能力

这种结合推理逻辑与外部信息访问的系统，即构成智能体（Agent]）。

生成式人工智能智能体可以被定义为一种应用程序，它试图通过观察世界，并利用其可用的工具对世界采取行动来实现目标。智能体具有自主性，可以在无需人类干预的情况下独立行动，尤其是在被赋予了它们应该实现的适当目标时。智能体在实现目标的过程中也可以积极主动。即使在没有人类明确指令集的情况下，智能体也能推理出接下来应该采取什么行动来实现其最终目标。


为了理解智能体的内部工作原理，我们先来介绍驱动智能体行为（behavior）、行动（action）和决策（decision making）的基础组件。这些组件的组合可以被描述为一种认知架构，通过对这些组件的混合和匹配，可以实现多种这样的架构。从核心功能来看，如图 1 所示，智能体的认知架构中有三个基本组件：模型（Model）、工具（Tools）和编排（Orchestration）。

模型


在智能体的范畴内，模型指的是语言模型（LM），它将作为智能体流程的核心决策器。智能体使用的模型可以是一个或多个任意规模（小型 / 大型）的语言模型，这些模型能够遵循基于指令的推理和逻辑框架，如 ReAct、思维链（Chain-of-Thought）或思维树（Tree-of-Thoughts）。模型可以是通用的、多模态的，也可以根据特定智能体架构的需求进行微调。为了在生产中获得最佳效果，你应该选择最适合你期望的最终应用的模型，理想情况下，该模型应在与你计划在认知架构中使用的工具相关的数据特征上进行过训练。需要注意的是，模型通常不会使用智能体的特定配置设置（即工具选择、编排 / 推理设置）进行训练。不过，通过向模型提供展示智能体能力的示例，包括智能体在各种场景中使用特定工具或推理步骤的实例，就有可能进一步优化模型以适应智能体的任务。

工具


基础模型尽管在文本和图像生成方面表现出色，但仍然受到无法与外部世界交互的限制。工具弥补了这一差距，使智能体能够与外部数据和服务进行交互，解锁了比基础模型本身更广泛的行动范围。工具可以采用多种形式，复杂程度各不相同，但通常与常见的网络 API 方法（如 GET、POST、PATCH 和 DELETE）类似。例如，一个工具可以更新数据库中的客户信息，或者获取天气数据，以影响智能体为用户提供的旅行建议。借助工具，智能体可以访问和处理现实世界的信息。这使它们能够支持更专业的系统，如检索增强生成（RAG），显著扩展了智能体的能力，超越了基础模型单独所能达到的水平。

编排层


编排层描述了一个循环过程，它控制智能体如何获取信息、进行一些内部推理，并利用这些推理来指导其下一个行动或决策。一般来说，这个循环会持续进行，直到智能体达到其目标或某个停止点。编排层的复杂程度因智能体及其执行的任务而异。有些循环可能是简单的带有决策规则的计算，而其他循环可能包含链式逻辑，涉及额外的机器学习算法，或采用其他概率推理技术。我们将在认知架构部分更详细地讨论智能体编排层的具体实现。

对比澄清一些易混淆的概念

Agents vs. 模型

Agent vs. Workflow

Anthropic将Agent系统划分为两类：

  1. 第一类是workflow。遵循预定义的工作流，编排LLM和工具，固定代码路径。

  2. Agent：此类Agent被定义为完全自主的系统，这些系统在较长时间内独立运行，可以动态地指导自身流程和工具使用的系统。通过自身的推理、规划能力，自主控制，完成任务。

工作流为定义明确的任务提供可预测性和一致性，而当需要大规模的灵活性和模型驱动的决策时，Agent是更好的选择。但是，Agent系统通常会以延迟和成本为代价来获得更好的任务性能，在生产环境中应该考虑何时进行这种权衡。

认知架构：智能体如何运作

智能体可以通过认知架构，迭代地处理信息、做出明智的决策，并根据先前的输出优化后续行动，以实现其最终目标。智能体认知架构的核心是编排层，它负责维护记忆、状态、推理和规划。它利用快速发展的提示工程领域及相关框架来指导推理和规划，使智能体能够更有效地与环境交互并完成任务。语言模型的提示工程框架和任务规划领域的研究正在迅速发展，产生了多种有前景的方法。以下是当下一些最受欢迎的框架和推理技术：

  • ReAct 是一种提示工程框架，它为语言模型提供了一种思维过程策略，使其能够针对用户查询进行推理并采取行动，无论是否有上下文示例。ReAct 提示已被证明优于多个当前最优（SOTA）基线，并提高了大语言模型（LLMs）与人类的交互性和可信度。

  • 思维链（Chain-of-Thought，CoT）是一种提示工程框架，它通过中间步骤实现推理能力。思维链有各种子技术，包括自一致性、主动提示和多模态思维链，每种技术根据具体应用都有其优缺点。

  • 思维树（Tree-of-thoughts，ToT）是一种提示工程框架，适用于探索或战略前瞻性任务。它是对思维链提示的扩展，允许模型探索各种思维链，这些思维链可作为使用语言模型解决一般问题的中间步骤。

智能体可以使用上述推理技术为给定的用户请求选择下一个最佳行动。例如，我们考虑一个被编程为使用 ReAct 框架为用户查询选择正确行动和工具的智能体。事件序列可能如下：

  1. 用户向智能体发送查询。

  2. 智能体开始 ReAct 序列。

  3. 智能体向模型提供一个提示，要求它生成下一个 ReAct 步骤及其相应输出：

  • 问题（Question）：来自用户查询的输入问题，随提示一起提供。

  • 想法（Thought）：模型对下一步应该做什么的思考。

  • 行动（Action）：模型对下一步采取什么行动的决策。

    • 这是选择工具的地方。

    • 例如，一个行动可以是 [航班、搜索、代码、无] 中的一个，前三个代表模型可以选择的已知工具，最后一个代表 “不选择工具”。

  • 行动输入（Action input）：模型对为工具提供什么输入的决策（如果有）。

  • 观察（Observation）：行动 / 行动输入序列的结果。

    • 根据需要，这个想法 / 行动 / 行动输入 / 观察可能会重复 N 次。

  • 最终答案（Final answer）：模型对原始用户查询提供的最终答案。

4. ReAct 循环结束，最终答案被返回给用户。

如上图 所示，模型、工具和智能体协同工作，根据用户的原始查询，为用户提供有依据的、简洁的回复。模型使用了一个工具（航班工具）来搜索实时外部信息。这些额外信息被提供给模型，使其能够根据真实数据做出更明智的决策，并将这些信息总结后返回给用户。

二、工具：连接外部世界的钥匙

虽然语言模型在处理信息方面表现出色，但它们缺乏直接感知和影响现实世界的能力。这限制了它们在需要与外部系统或数据交互的情况下的实用性。从某种意义上说，这意味着语言模型的能力仅限于它从训练数据中学到的内容。但是，无论我们为模型提供多少数据，它们仍然缺乏与外部世界交互的基本能力。那么，我们如何使我们的模型能够与外部系统进行实时的、上下文感知的交互呢？函数（Functions）、扩展（Extensions）、数据存储（Data Stores）和插件（Plugins）都是为模型提供这一关键能力的方式。

扩展Extensions

理解扩展的最简单方法是将其视为以标准化方式在 API 和智能体之间架起桥梁，使智能体能够无缝执行 API，而无需考虑其底层实现。假设你构建了一个智能体，目标是帮助用户预订航班。你知道你想使用谷歌航班 API 来检索航班信息，但你不确定如何让你的智能体调用这个 API 端点。


一种方法可能是实现自定义代码，该代码获取传入的用户查询，解析查询以获取相关信息，然后进行 API 调用。例如，在航班预订用例中，用户可能会说 “我想预订从奥斯汀到苏黎世的航班”。在这种情况下，我们的自定义代码解决方案需要从用户查询中提取 “奥斯汀” 和 “苏黎世” 作为相关实体，然后才能尝试进行 API 调用。但是，如果用户说 “我想预订去苏黎世的航班”，却没有提供出发城市，会发生什么情况呢？如果没有所需的数据，API 调用将失败，并且需要实现更多代码来处理此类边缘和极端情况。这种方法缺乏可扩展性，并且在任何超出已实现的自定义代码范围的场景中都很容易出错。

一种更具弹性的方法是使用扩展。扩展通过以下方式在智能体和 API 之间架起桥梁：

  1. 使用示例教导智能体如何使用 API 端点。

  2. 教导智能体成功调用 API 端点所需的参数。

扩展可以独立于智能体进行构建，但应作为智能体配置的一部分提供。智能体在运行时使用模型和示例来决定哪个扩展（如果有的话）适合解决用户的查询。这突出了扩展的一个关键优势，即其内置的示例类型，使智能体能够动态地为任务选择最合适的扩展。

函数Functions

在软件工程领域，函数被定义为自包含的代码模块，用于完成特定任务，并且可根据需要重复使用。软件开发人员在编写程序时，通常会创建多个函数来执行不同的任务。他们还会定义何时调用函数 a 而非函数 b 的逻辑，以及预期的输入和输出。
不过我们可以用模型来替代软件开发人员。模型可以获取一组已知的函数，并根据其规格说明来决定何时使用每个函数，以及该函数需要哪些参数。函数与扩展有几个方面的不同，最显著的是：

  1. 模型输出一个函数及其参数，但不会进行实时 API 调用。

  2. 函数在客户端执行，而扩展在智能体端执行。

再次以谷歌航班为例，一个简单的函数设置可能如图 7 中的示例所示。

请注意，这里的主要区别在于，无论是函数还是智能体都不会直接与谷歌航班 API 进行交互。那么，API 调用实际是如何发生的呢？
对于函数而言，调用实际 API 端点的逻辑和执行操作从智能体转移到了客户端应用程序，如上面的图 8 和下面的图 9 所示。这使开发人员能够更精细地控制应用程序中的数据流向。开发人员可能选择使用函数而非扩展，原因有很多，常见的几种应用场景如下：

  • API 调用需要在应用程序堆栈的另一层进行，而不是在智能体架构的直接流程内（例如，在中间件系统、前端框架等中）。

  • 安全或认证限制阻止智能体直接调用 API（例如，API 未暴露到互联网，或者智能体基础设施无法访问）。

  • 时间或操作顺序限制导致智能体无法实时进行 API 调用（即批量操作、人工介入审核等 ） 。

Function Call

https://mp.weixin.qq.com/s/lVqdBxYmA9EfSNQ2M7n4DA（来源）

本小节摘抄自《那么多接入 DeepSeek 的，终于有一家支持 Function Call 了！！！》，进一步理解Agent如何进行函数调用。
字节率先将 DeepSeek 支持了 Function Call（2025年02月）。现在，模型会自己思考判断是否该调用插件，该调用哪个插件。
Function Call 本质上是让 LLM 成为一个更智能的“操作员”，通过标准化的接口来调用外部工具和服务，从而扩展其能力边界。那么大模型是怎么实现 Function Call 的呢，其大概流程是这样的：

  1. 用户输入；

  2. LLM 开始生成回应，直到意识到需要工具调用时；

  3. 暂停原有 Token 生成，开始生成函数调用的参数；

  4. 外部系统截获函数参数，执行后返回结果；

  5. LLM 基于返回结果和前文，继续生成完整回应。

不过，体验下来，当下的工具调用版 R1 还存在一些偶发的小问题，包括：

  1. 不知道何时应当调用函数，或忘记调用函数；

  2. 参数输入不完全准确，未生成具体可被外部解析的 Action，而是输出代码块；

  3. 对于较复杂的需求，单次对话里较难重复调用工具。

一些举例

示例1：

模型可用于调用函数，以便为终端用户处理复杂的客户端执行流程，在这种情况下，智能体开发者可能不希望语言模型来管理 API 的执行（扩展的情况就是如此）。我们来看下面这个例子，一个智能体被训练成旅行助手，与想要预订度假旅行的用户进行交互。目标是让智能体生成一份城市列表，用于中间件应用程序为用户的旅行规划下载图片、数据等。用户可能会这样说：
“我想和家人去滑雪旅行，但不确定该去哪里。”
在向模型发送的典型提示中，输出可能如下：
当然，以下是一些你可以考虑的适合家庭滑雪旅行的城市：

  • 美国科罗拉多州的克雷斯特德比特

  • 加拿大不列颠哥伦比亚省的惠斯勒

  • 瑞士的采尔马特


虽然上述输出包含了我们需要的数据（城市名称），但其格式并不适合解析。通过函数调用，我们可以训练模型以结构化的格式（如 JSON）输出数据，这样更便于其他系统进行解析。对于用户给出的相同输入提示，函数输出的一个 JSON 示例可能如代码片段 5 所示。

这个 JSON 由模型生成，然后被发送到我们的客户端服务器，以便我们对其进行任何想要的处理。在这个特定的例子中，我们将调用谷歌地图地点 API（Google Places API ），使用模型提供的城市信息来查找相关图片，然后将这些图片以格式化的丰富内容形式返回给用户。参考图 9 中的序列图，它详细地逐步展示了上述交互过程。

图 9 中示例的结果是，模型被用来 “填空”，提供客户端用户界面（UI）调用谷歌地图地点 API 所需的参数。客户端 UI 使用模型在返回的函数中提供的参数来管理实际的 API 调用。


用户输入了一个query给客户端UI，客户端调用Agent，Agent将prompt给到LLM，LLM生成了JSON格式的输出（包括了需要调用的函数名及其需要的参数），JSON格式输出被返回给客户端，客户端进行API call去调用该API，API返回的结果给到客户端，得到最终的响应。


关于函数，有一个关键要点需要记住：函数不仅旨在让开发者能更好地控制 API 调用的执行过程，还能更好地掌控整个应用程序中的数据流动。在图 9 的示例中，开发者选择不将 API 信息返回给智能体，因为这些信息与智能体后续可能采取的行动无关。然而，根据应用程序的架构，将外部 API 调用数据返回给智能体，以便影响其未来的推理、逻辑判断和行动选择，也可能是合理的做法。归根结底，对于特定的应用程序而言，怎样做才合适，决定权在应用开发者手中。

示例2：

虽然这是一个相当简单的智能体示例，但它展示了模型、编排和工具等基础组件协同工作以实现特定目标的过程。

数据存储

把语言模型想象成一个巨大的图书馆，里面存放着它的训练数据。但与不断购入新书的图书馆不同，这个 “图书馆” 是静态的，仅包含其最初训练时的知识。这就带来了一个挑战，因为现实世界的知识在不断发展。数据存储通过提供对更动态、最新信息的访问，解决了这一限制，并确保模型的回复基于事实且具有相关性。


数据存储使开发人员能够以原始格式向智能体提供额外数据，从而无需进行耗时的数据转换、模型重新训练或微调。数据存储会将传入的文档转换为一组向量数据库嵌入，智能体可以利用这些嵌入提取所需信息，为其下一步行动或对用户的回复提供补充。

实现与应用：
在生成式人工智能智能体的情境下，数据存储通常被实现为向量数据库，开发者希望智能体在运行时能够访问该数据库。虽然我们在此不会深入探讨向量数据库，但关键要理解的是，它们以向量嵌入的形式存储数据，向量嵌入是一种高维向量，是对所提供数据的数学表示。近年来，数据存储在语言模型中的一个极为常见的应用示例，就是基于检索增强生成（RAG）的应用程序。这些应用程序旨在通过让模型访问各种格式的数据，如：

  • 网站内容；

  • 以 PDF、Word 文档、CSV、电子表格等格式存在的结构化数据；

  • 以 HTML、PDF、TXT 等格式存在的非结构化数据，

每个用户请求和智能体响应循环的底层过程通常如下图 13 所示。

  1. 用户查询被发送到嵌入模型，以生成该查询的嵌入表示。

  2. 然后使用类似可扩展最近邻搜索（SCaNN）这样的匹配算法，将查询嵌入与向量数据库的内容进行匹配。

  3. 从向量数据库中以文本格式检索匹配的内容，并将其发送回智能体。

  4. 智能体接收用户查询和检索到的内容，然后制定响应或行动。

  5. 最终的回复被发送给用户。

图 14 展示了一个与采用 ReAct 推理 / 规划来实现检索增强生成（RAG）的智能体的示例交互。（强烈建议看一下图中的具体内容，它示例了Agent的一个循环过程）

工具总结

总而言之，扩展、函数和数据存储构成了几种不同类型的工具，可供智能体在运行时使用。每种工具都有其独特用途，智能体开发者可自行决定将它们结合使用或单独使用。

通过定向学习提升模型性能

有效使用模型的一个关键方面，在于模型在生成输出时能否选择合适的工具，尤其是在生产环境中大规模使用工具的情况下。虽然常规训练有助于模型培养这种技能，但现实场景往往需要训练数据之外的知识。可以将其想象成基本烹饪技能与精通某一特定菜系之间的差别。两者都需要基础烹饪知识，但后者需要定向学习，才能取得更精细的成果。
为帮助模型获取这类特定知识，有几种可行方法：

  • 上下文内学习In-context learning：此方法在推理时，为通用模型提供提示、工具以及少量示例，使其能够 “即时” 学习如何以及何时针对特定任务使用这些工具。自然语言处理中的 ReAct 框架就是这种方法的一个例子。

  • 基于检索的上下文内学习Retrieval-based in-context learning：该技术通过从外部存储器中检索信息，动态地用最相关的信息、工具及相关示例填充模型提示。比如 Vertex AI 扩展中的 “示例存储”，或者前面提到的基于检索增强生成（RAG）架构的数据存储，都是这种方法的实例。

  • 基于微调的学习Fine-tuning based learning：此方法在推理前，使用大量特定示例的数据集对模型进行训练。这有助于模型在接收任何用户查询之前，就理解何时以及如何应用某些工具。

为了更深入地了解每种定向学习方法，让我们以烹饪作为类比。

  • 想象一下，一位厨师从顾客那里收到一份特定的食谱（提示）、一些关键食材（相关工具）以及几道示例菜肴（少量示例）。基于这些有限的信息以及厨师的烹饪常识，他们需要 “即时” 想出如何制作出与食谱和顾客偏好最相符的菜肴。这就是上下文内学习。

  • 现在，假设我们这位厨师身处一个食材储备丰富的厨房（外部数据存储），里面摆满了各种食材和烹饪书籍（示例和工具）。此时，厨师能够从厨房储备中动态挑选食材和烹饪书籍，更好地契合顾客的食谱和偏好。这使得厨师能够借助已有的知识和新知识，制作出更符合要求且更精致的菜肴。这就是基于检索的上下文内学习。

  • 最后，设想我们送这位厨师回学校学习一种或几种新菜系（使用大量特定示例的数据集进行预训练）。这样一来，厨师在面对未来从未见过的顾客食谱时，就能有更深入的理解。如果我们希望厨师精通特定菜系（知识领域），这种方法就非常合适。这就是基于微调的学习。

  • 就速度、成本和延迟而言，每种方法都有其独特的优缺点。然而，通过在智能体框架中结合这些技术，我们可以发挥它们的各种优势，将劣势降至最低，从而获得一个更强大、适应性更强的解决方案。

虽然本文探讨了智能体的核心组件，但构建生产级应用程序还需要将它们与用户界面、评估框架和持续改进机制等其他工具相结合。

总结

本文的一些关键要点包括：

  1. 智能体通过利用工具来访问实时信息、提出现实世界中的行动建议，以及自主规划和执行复杂任务，从而扩展了语言模型的能力。智能体可以利用一个或多个语言模型来决定何时以及如何在不同状态间转换，并使用外部工具来完成模型自身难以或无法独立完成的各种复杂任务。

  2. 智能体运行的核心是编排层，这是一种认知架构，它组织推理、规划、决策过程并指导智能体的行动。诸如 ReAct、思维链（Chain-of-Thought）和思维树（Tree-of-Thoughts）等各种推理技术，为编排层提供了一个框架，使其能够接收信息、进行内部推理，并生成明智的决策或响应。

  3. 扩展、函数和数据存储等工具，是智能体通向外部世界的钥匙，使它们能够与外部系统交互，并获取超出其训练数据范围的知识。扩展在智能体与外部 API 之间架起了一座桥梁，能够执行 API 调用并检索实时信息。函数通过分工为开发者提供了更精细的控制，允许智能体生成可在客户端执行的函数参数。数据存储使智能体能够访问结构化或非结构化数据，从而实现数据驱动的应用程序。

智能体的未来充满令人激动的发展，而我们目前仅仅是浅尝辄止，尚未充分发掘其潜力。随着工具变得更加精良，推理能力得到提升，智能体将能够解决愈发复杂的问题。
此外，“智能体链式连接” 这一策略性方法的发展势头将持续增强。通过将专长于特定领域或任务的专业智能体组合在一起，我们可以打造一种 “智能体专家组合” 的模式，使其能够在各个行业和各类问题领域取得卓越成果。

本人写在最后

（1）为什么Agent还没有爆发

  1. 没有清晰的AI或Agent-Native的产品形态落地

  2. 需要对AI、行业know-how的认知，都非常深

  3. 另外，还有一个“Agent爆发”需要的前置条件当前远没有具备，就是：Agent和Agent之间通信、交互的标准和基建，目前还几乎是行业空白。

（2）基于Agent的框架，产品经理的产品思维要有哪些变化

过去互联网/移动互联网时代，典型的思考格式是“场景-用户-需求”（什么场景下，怎样的典型用户画像，有什么痛点需求）。AI 2.0时代，需要增加一个关键词，“关系”。某个Agent在某个场景里，和用户或者其他Agent之间，是什么的关系？定义了关系，其实就定义了边界、约束条件和需求属性。

（3）回归问题本质，AI 只是锤子

对于产品经理来说，在落地产品的时候，核心是解决你的问题：至于是不是智能体，是不是大语言模型，是不是 AI 帮你决策，都不是最重要的。
一个被提及很多的是吴恩达老师写的多智能体翻译的例子，简单来说就是用三个智能体：一个直译智能体、一个审查智能体、一个意译润色智能体，确实可以大幅提升翻译质量。但并非一定要三个智能体才能提升翻译质量，其实，基于 Prompt 让 LLM 在翻译时，使用直译 + 反思 + 意译三个步骤输出，也可以得到高质量的翻译结果。
其实大部分 AI 应用场景都类似：要用 AI 解决问题，核心不在于智能体，而在于设计出一个适合 AI 的工作流。我们有时候过于关注一些流行的概念或技术，而忽略了要解决的根本问题是什么，将 AI 变成了目的而不是手段。
如果你有了解马斯克的第一性原理思维，其强调的就是回归事物最基本的条件，把其解构成各种要素进行分析，从而找到实现目标最优路径的方法。
而运用第一性原理通常有三个步骤：

  • 第 1 步：定义清楚你要解决的根本问题。

  • 第 2 步：拆解问题。

  • 第 3 步：从头开始创建解决方案。

而这也个思路也适用于我们去借助 AI 解决问题，设计出适合 AI 的工作流。真正要用好 AI，让 AI 发挥最大效能，核心是还是要基于你要解决的问题，重新设计一个适合 AI 的工作流，让 AI 在工作流中完成它最擅长的工作，至于是不是智能体，是不是大语言模型，是不是 AI 帮你决策，都不是最重要的。