通过对比Agent与传统模型及工作流的差异，揭示了智能体在灵活性和效率上的优势。无论是AI新手还是资深产品经理，本文都能帮助你快速掌握Agent的关键要点，为打造智能产品提供实用指导。

本人也在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 基于返回结果和前文，继续生成完整回应。

一些举例

示例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 调用数据返回给智能体，以便影响其未来的推理、逻辑判断和行动选择，也可能是合理的做法。归根结底，对于特定的应用程序而言，怎样做才合适，决定权在应用开发者手中。

小结

本篇介绍了什么是Agent（包含模型、工具、编排、如何运作）、工具篇的扩展和函数部分。下一篇将介绍工具篇的数据存储及总结、模型、为什么Agent没有爆发。