深度理解Agent: AI产品经理入门必读! (下)

在AI领域，智能体（Agent）正成为推动产品创新的关键技术。本文作为《深度理解Agent：AI产品经理入门必读》系列的下篇，继续深入探讨Agent的核心组件及其在产品中的应用。文章详细介绍了数据存储的作用、模型性能提升的方法，以及从产品经理视角对Agent应用的洞见与警示。

上一篇介绍了什么是Agent（包含模型、工具、编排、如何运作）、工具篇的扩展和函数部分。

本篇将介绍工具篇的数据存储及总结、模型性能提升、产品经理视角的洞见与警示。

工具篇（续）

数据存储

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

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

实现与应用：

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

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

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

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

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

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

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

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

工具总结

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

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

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

为帮助模型获取这类特定知识，有几种可行方法：

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

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

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

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

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

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

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

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

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

总结

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

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

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

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

4）智能体通常包含以下几个部分：

推理能力：指支撑复杂逻辑推理、语言理解与决策过程的基础模型。这些模型负责评估信息，构成了Agent的认知中枢。

记忆系统：负责存储、组织并检索短期上下文信息以及长期积累的知识。

工具调用：指Agent与外部应用程序、API接口、数据库、互联网及其他软件进行交互的集成能力。

规划能力：指Agent内部用于拆解复杂任务为可管理步骤、评估执行效果并适时调整策略的架构设计。

智能体的未来充满令人激动的发展，而我们目前仅仅是浅尝辄止，尚未充分发掘其潜力。随着工具变得更加精良，推理能力得到提升，智能体将能够解决愈发复杂的问题。

此外，“智能体链式连接”这一策略性方法的发展势头将持续增强。通过将专长于特定领域或任务的专业智能体组合在一起，我们可以打造一种“智能体专家组合”的模式，使其能够在各个行业和各类问题领域取得卓越成果。

写在最后

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

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

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

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

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

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

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

对于产品经理来说，在落地产品的时候，核心是解决你的问题：至于是不是智能体，是不是大语言模型，是不是AI帮你决策，都不是最重要的。

一个被提及很多的是吴恩达老师写的多智能体翻译的例子，简单来说就是用三个智能体：一个直译智能体、一个审查智能体、一个意译润色智能体，确实可以大幅提升翻译质量。但并非一定要三个智能体才能提升翻译质量，其实，基于Prompt让LLM在翻译时，使用直译+反思+意译三个步骤输出，也可以得到高质量的翻译结果。

其实大部分AI应用场景都类似：要用AI解决问题，核心不在于智能体，而在于设计出一个适合AI的工作流。我们有时候过于关注一些流行的概念或技术，而忽略了要解决的根本问题是什么，将AI变成了目的而不是手段。

如果你有了解马斯克的第一性原理思维，其强调的就是回归事物最基本的条件，把其解构成各种要素进行分析，从而找到实现目标最优路径的方法。

而运用第一性原理通常有三个步骤：

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

第2步：拆解问题。

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

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