最近google发表了一篇Agent白皮书，介绍Agent相关的一些内容。本文主要是针对Agent白皮书的解读，抽取出其中一些比较重要的部分进行展示。读完本文能够解答以下问题：
- 什么是Agent？
- 为什么会提出Agent？
- Agent的具体组成是怎样的？
- Agent中是如何进行思考和推理的？
- Agent是如何和tools进行交互的？
Agent基本概念
什么是Agent? 白皮书给出的定义如下：
This combination of reasoning, logic, and access to external information that are all connected to a Generative AI model invokes the concept of an agent, or a program that extends beyond the standalone capabilities of a Generative AI model.
以人作为类比，当我们要去完成一个任务的时候，我们可能会基于自己的先验知识去使用一些外部工具来帮助我们完成最终的任务。对于模型而言，它同样也可以调用一些工具来实现自己的目标。在这个过程中，可能会涉及到逻辑、推理和外部信息感知等过程。把这些内容和一个生成式AI模型联系起来，就引出了一个Agent的概念。简单总结：Agent就是一个以生成式AI模型为中心，进行外部信息感知、逻辑处理、推导并能完成最终用户目标的工具/应用程序。
那为什么要把这些工具和模型连接起来呢？本质的原因是纯模型的能力不足，不足以支撑更多的应用场景。纯模型和Agent的能力对比如下（这里是结论，建议看完文章后再想想这里）：
| 纯模型 | Agent |
|---|---|
| 知识受限于其训练数据 | 通过tools连接外部系统和数据，使其知识得以扩展。 |
| 只能进行单步推理或者预测。除非为模型明确实现，否则没有对会话历史或连续上下文的管理。 | 管理会话历史（即聊天历史）以允许基于用户查询和在编排层中做出的决策进行多轮推理/预测。 |
| tool没有原生实现 | 在agent架构中原生实现tools |
| 没有原生的逻辑层实现。需要用户自己组织prompt以引导模型预测 | 使用CoT、ReAct框架的原生认知架构 |
Agent认知架构
基于这个概念，一个Agent的基本认知架构如下：
图中包含的主要组件及其说明如下：
| 组件 | 说明 |
|---|---|
| orchestration | 编排层，一个循环的过程，它决定了Agent如何获取外部信息、执行一些外部推理以及如何使用这些推理得到的信息决定下一步或者结束整个过程。在框架中，编排层是核心，负责维护记忆、状态、推理和规划。使用提示工程领域的相关框架来指导推理和规划，使智能体能够有效的于环境进行交互并完成任务。 |
| model | 在Agent的上下文中，model指的是用来给agent流程做中心决策的语言模型。 |
| tools | Tools可以让生成式AI模型和外部进行交互，弥补基础模型的不足 |
Agent工作原理
当接受到用户查询时，Agent运行时的orchestration会使用配置的推理框架对问题进行分析、推理，思考推理的过程依赖于底层的model。当model对当前情况做出决策要进行下一步行为时，Agent会去调用相关的tools完成和外部的交互。最终当model决策处理完成时，Agent返回给用户最终处理结果。这里我们主要关注下orchestration和Tools的实现。
Orchestration
在这个过程中，编排层配置的推理框架决定了Agent的思考推理策略。目前常见的一些推理框架如下：
| 推理框架 | 说明 |
|---|---|
| ReAct | 一种提示工程框架，为语言模型提供一种思考过程策略，以便对用户查询进行推理并采取行动, 可能会带有一些示例。 |
| CoT(Chain-of-Thought) | 一种能够通过中间步骤实现推理能力的提示工程框架。CoT 有各种子技术，包括self-consistency, active-prompt, 和multimodal CoT，每种技术在特定应用中都有其优缺点。. |
| ToT(Tree-of-thoughts) | 一种提示工程框架，非常适合探索或战略前瞻性任务。它对思维链提示进行了概括，并允许模型探索各种作为语言模型通用问题解决中间步骤的思维链。 |
关于这些推理框架的详细信息，在本文中不准备详细展开。上图就是使用ReAct框架的Agent思考推理过程。
Tools
对于Tools, 文中将它分成了三种类型。不同的类型对应了不同的能力和使用场景。
Extensions
Extensions和Function Calling都是为了解决如何让Agent感知调用外部的API而提出的。当Agent需要调用外部工具时，需要知道每个工具的api是什么、怎么调用、入参有哪些。可以写死代码，但这样不灵活，扩展性不足。因此提出一个中间的概念Extension, 通过配置它来让Agent感知到外部的API是什么样的，应该怎么调用，从而让Agent在思考过程中合适的时机时可以对外部的工具进行调用。
Function Calling
Function Calling也是一种让Agent感知API能力的方式，但是相比于Extentsions来说，它将更多主动权交给了Agent的用户（client端）而不是Agent。（如下图B链路，A链路对应Extensions过程，可以明显看出差别）
在使用FunctionCall的时候，返回的内容时需要被调用的函数名字和参数。这部分内容会被返回给调用端，由调用端决定何时发起调用。这在一些场景下是非常有用的（比如异步调用、审核、安全等场景）。一个使用Function Calling类型tools处理请求的时序如下：
DataStores
DataStore的使用场景是从外部获取一些实时的新信息。它的实现目前主要是vector store，将结构化或者非结构化的数据进行嵌入，然后存储到vector strore中，当Agent进行查询时从vector store中获取最新的信息来进行后续的推理。一个使用DataStore的典型应用就是RAG应用，它的处理流程如下：
不同类型的对比
三种不同类型的Tools的对比如下：（这里直接使用文中的对比结果，不做翻译了）
最后
本文没有尝试完全照搬翻译白皮书的内容，而是抽取出其中一些主要的知识信息整理后进行展示，关于白皮书的完整内容，感兴趣的同学可以去查看原文章。读完本文，预期的收获是：对于文章开头的这些问题，我们能够清晰的进行解答。
