（下篇）大佬们都在关注的AI Agent，到底是什么？用5W1H分析框架拆解AI Agent

本篇文章是使用5W1H分析框架拆解AI Agent的下篇，在进入正文之前，先总体回顾这一系列文章的脉络。

上篇：介绍What + Why，主要解答以下问题。

What：AI Agent是什么？AI Agent有哪些组成部分？AI Agent的原理是什么？AI Agent是怎么分类的？

Why：为什么会产生AI Agent？AI Agent的优势和劣势是什么？为什么企业和个人都要关注AI Agent？

中篇：介绍When + Where + Who，主要解答以下问题。

When：AI Agent的发展历程是怎样的？AI Agent未来的发展趋势是怎样的？

Where：AI Agent有哪些应用场景？

Who：AI Agent领域的玩家有哪些？AI Agent领域的行业价值链是怎样的？

下篇：介绍 How，主要解答以下问题。

How：如何实现AI Agent？AI Agent包括哪些系统模块？如何开始学习AI Agent？

大家也可以关注GZH“风叔云”，回复关键词“拆解AI Agent”，获得《5W1H分析框架拆解AI Agent》的完整PPT文件。

在《大佬们都在关注的AI Agent，到底是什么？用5W1H分析框架拆解AI Agent（中篇）》中，围绕When、Who和Where，风叔详细阐述了AI Agent的发展历程、行业玩家和各行业应用场景。

在这篇文章中，风叔将围绕How，站在产品实践的角度，详细介绍AI Agent的具体实现路径，以及如何更快的上手学习AI Agent。

阅读过《大佬们都在关注的AI Agent，到底是什么？用5W1H分析框架拆解AI Agent（上篇）》的读者应该了解，从结构上来说，一个AI Agent包括三个部分，如下图所示：

Perception（输入）：AI Agent通过文字输入、传感器、摄像头、麦克风等等，建立起对外部世界或环境的感知。

Brain（大脑）：AI Agent最重要的部分，包括信息存储、记忆、知识库、规划决策系统。

Action（行动）：基于 Brain给出的决策进行下一步行动，对于AI Agent来说，行动主要包括对外部工具的API 调用，或者对物理控制组件的信号输出

接下来，我们就按照这个模块划分，逐级下钻，详细介绍搭建一个完整的AI Agent系统，都需要哪些步骤。

一、Perception（输入）

AI Agent应该能够接收多种信息输入，从最简单的文本和语音，到更复杂的图片、视频和传感器数据。因此从产品功能角度，AI Agent应该具备以下能力。

• 文本输入：这是最常见的AI Agent接收用户指令的方式；如果要求AI Agent具备chat能力，还需要有基础的对话框，便于和用户进行自然语言交互。
• 语音输入：本质上还是文本输入，只需要在输入环节额外增加一层ASR转TTS，将语音转化为文本。
• 文件上传：在特定场景下，AI Agent需要对用户上传的文档进行分析，例如财报智能解读、合同智能审查等，需要具备文件上传功能
• 图片和视频输入：AI Agent有时候需要处理图片，比如进行图像处理、医学影像分析。视频输入本质上也是图片输入，在输入层对视频流进行切片，比如线下门店监控、视频信息提取等场景。
• 传感器输入：在制造业和能源行业，会要求AI Agent进行设备状态监控和预警，这个时候就要求AI Agent具备传感器对接能力，接收来自设备的温度、电压、电流等数据。

现在的大模型主要是通过语言进行交互，这样显然是不够的。如果要进一步理解世界，一定需要多模态输入，包括视觉、听觉、传感器等等。因此，未来的AI Agent一定会更多和物理实体相结合，比如将AI Agent集成进入机器狗，训练其进行救援任务。在这个过程中，对于时间的认知、身体运动的控制也需要集成到AI Agent里面去。

当然，在实际产品设计中，需要根据实际AI Agent的应用场景来设计其支持的输入类型。

二、Brain（大脑）

1. 记忆模块

记忆，在Agent系统中扮演着十分重要角色，负责存储和组织从环境中获取的信息，以指导未来行动。记忆模块通常包含短期记忆和长期记忆两个部分。

短期记忆暂存最近的感知，通常是和AI Agent对话的上下文，这块相对比较简单，直接将短期记忆存入缓存即可。

困难点在于长期记忆，长期记忆的容量要远远大于短期记忆，如何让AI Agent从长期记忆中快速且准确地回忆起相关内容，是在这一模块需要重点解决的问题。

要实现良好的长期记忆性能，有三个重要的技术依赖项，向量数据库、RAG技术和Rerank技术。

a.向量数据库

AI Agent的记忆系统，不能采用传统数据库进行存储，必须采用向量数据库。像MySQL这样的传统数据库，在AI应用场景中，有两个非常致命的缺陷。

第一个缺陷是语义搜索的缺失，比如用户想在文档中找到表达“精彩万分”或“激动人心”的段落，传统数据库是肯定做不到的，传统数据库只能基于确定的“关键词”进行精确匹配或者模糊匹配。

第二个缺陷是非结构化数据处理不足，对于图像、音频和视频等非文本内容，传统数据库无法进行有效的内容搜索。比如用户想找到《星球大战》电影中天行者出现的片段，就无法通过传统数据库实现。

而向量数据库是一种特殊的数据库，它以多维向量的形式保存信息，代表某些特征或质量。根据数据的复杂性和详细程度，每个向量的维数可能相差很大，从几维到几千维不等。这些数据可能包括文本、图像、音频和视频，通过机器学习模型、单词嵌入或特征提取技术等各种流程转化为向量。

向量数据库的主要优势在于，它能够根据数据的向量接近度或相似度，快速、精确地定位和检索数据。这样就可以根据语义或上下文的相关性进行搜索，比如根据旋律和节奏搜索出特定的歌曲、在电影中搜索浪漫的片段、在文档中找出意图相近的段落等等。

上图简单展示了向量数据库的存储过程，无论是文本、音频还是视频，最后都会转换成Vector，以向量的方式存储。

b. 检索增强生成RAG

RAG（Retrieval Augmented Generation），其主要作用类似于搜索引擎，找到用户提问最相关的知识或者是相关的对话历史，并结合原始提问，创造信息丰富的prompt，指导LLM大模型生成更准确的输出。简而言之，RAG就是给大模型它原本数据集中没有的知识。

RAG技术产生最大的原因，是为了克服大模型的幻觉问题，以及在专业领域知识理解较差的缺陷。

RAG可分为5个基本流程：知识文档的准备、嵌入模型、向量数据库、查询检索和生产回答。

现实场景中，我们面对的知识源可能包括多种格式，如Word文档、TXT文件、CSV数据表、Excel表格，甚至图片和视频。因此需要使用专门的文档加载器（例如PDF提取器）或多模态模型（如OCR技术），将这些丰富的知识源转换为大语言模型可理解的纯文本数据，然后开启RAG的五个核心步骤。

第一步，文档切片/分块：在企业级应用场景中，文档尺寸可能非常大，因此需要将长篇文档分割成多个文本块，以便更高效地处理和检索信息。分块的方式有很多种，比如按段落、按内容或者其他特殊结构。同时，需要注意分块的尺寸，如果分块太小，虽然查询更精准，但召回时间更长；如果分块太大，则会影响查询精准度。

第二步，嵌入模型：嵌入模型的核心任务是将文本转换为向量形式，这样我们就能通过简单的计算向量之间的差异性，来识别语义上相似的句子。

第三步，存入向量数据库：将文档切片和嵌入模型的结果存储进入向量数据库，上文介绍了向量数据库，此处不再赘述。

第四步，用户查询检索：用户的问题会被输入到嵌入模型中进行向量化处理，然后系统会在向量数据库中搜索与该问题向量语义上相似的知识文本或历史对话记录并返回，这就是检索增强。

第五步，生成问答：最终将用户提问和上一步中检索到的信息结合，构建出一个提示模版，输入到大语言模型中，由大模型生成最终的结果并返回

c. 内容重排技术Rerank

在RAG技术中，也存在一些局限性，比如使用ElasticSearch的retrieval召回的内容相关度有问题。多数情况下score最高的chunk相关度没问题，但是top2-5的相关度就很随机了，这是最影响最终结果的。

ElasticSearch使用HNSW算法，导致搜索的时候存在随机性，这就是RAG中第一次召回的结果往往不太满意的原因。但是这也没办法，如果你的索引有数百万甚至千万的级别，那只能牺牲一些精确度以换回时间。

这时候我们可以做的就是增加top_k的大小，比如从原来的10个，增加到30个。然后再使用更精确的算法来做rerank，使用计算打分的方式，做好排序。

目前，已经有一些很成熟的Rerank工具可供大家使用，例如Cohere、JinaAI

上图展示了在Agent应用中使用向量数据库的三种场景。

第一种情况，用户的提问不依赖长期记忆，直接从向量数据库中获取关联文档，然后向LLM大模型获取结果。

第二种情况，用户查询一个问题，无法直接从向量数据库获取结果，需要先从长期以及中获取对应的知识块，再向LLM大模型获取结果。

第三种情况，用户进行多次提问，则先检查缓存中是否存在类似问题和答案，优先从缓存中查询返回结果；如果缓存中不存在，则向LLM大模型发起请求。

2. 规划模块

规划模块Planning是整个AI Agent中最核心最关键的部分，Agent会把大型任务分解为子任务，并规划执行任务的流程。同时Agent还会对任务执行的过程进行思考和反思，从而决定是继续执行任务，还是判断任务完结并终止运行。

在《大佬们都在关注的AI Agent，到底是什么？用5W1H分析框架拆解AI Agent（上篇）》中，风叔详细介绍了子任务分解和反思，其中子任务分解主要包括思维链COT、思维树TOT、思维图GOT、LLM+PDDL等方法；反思主要包括ReAct、Reflection、Multi-Agent等方式。

接下来，我们从产品设计的维度，来看一下比较主流的Planning设计模式。

a. ReAct

最容易理解的Planning模式，ReAct本质上就是把融合了Reasoning和Acting的一种范式，推理过程是浅显易懂，仅仅包含thought-action-observation步骤，很容易判断推理的过程的正确性，使用ReAct做决策甚至超过了强化学习。

ReACT的主要特性是同步推理Reasoning和行动Acting。比如在上图中，抛出一个问题，关于最初的远程控制苹果的设备有哪些。1a中的回答是直接的；1b的回答是基于思维链CoT方式，能够一步一步进行思考，最初只得出了iphone、ipad、ipod、itouch；1c的回答是只基于行动，比如先搜索Apple Remote，然后根据结果继续搜索Front Row软件，直接就得出了答案，但是这个答案并不是想要的；在1d中，使用了ReACT方式，结合了思考Thoughts和行动Acting，使得得出的结论更加趋于正确结果。

b. Basic Reflection

Basic Reflection可以类比于左右互博。左手是Generator，负责根据用户指令生成结果；右手是Reflector，来审查左手的生成结果并给出建议。在左右互搏的情况下，Generator生成的结果越来越好，Reflector的检查越来越严格，提供的建议也越来越有效。

c. Reflexion

Reflexion本质上是强化学习，可以理解为是Basic reflection 的升级版。Reflexion机制下，整个架构包括Responder和Reviser，和Basic Reflection机制中的Generator和Reflector有点类似。但不同之处在于， Responder自带批判式思考的陈述，Revisor会以 Responder 中的批判式思考作为上下文参考对初始回答做修改。此外，Revisor还引入了外部数据来评估回答是否准确，这使得反思的内容更加具备可靠性。

d.REWOO

REWOO的全称是Reason without Observation，是相对ReAct中的Observation 来说的。ReAct普遍有冗余计算的问题，冗余会导致过多的计算开销和过长的Token使用。而在ReWOO中，使用模块化解耦，完成预测性推理和工具执行，token使用效率要优于ReAct，并提高了在复杂环境下的性能。

如上图所示，左侧是以ReAct为主的方法。当User输入Task后，把上下文Context和可能的样本Exemple输入到LLM中，LLM会调用一个目标工具Tool，从而产生想法Thought，行动Action，观察Observation。由于拆解后的下一次循环也需要调用LLM，又会调用新的工具Tool，产生新的Thought，Action，Observation，后续的输入是需要叠加前面的Thought，Action，Observation以及Task，Context，Examplar，从而不断地迭代，完成推理Reasoning，然后生成答案Answer。如果这个步骤变得很长，并且Token很长就会导致巨大的重复计算和开销。

而右右侧ReWOO的方法，计划器Planner把任务进行分解，分解的依据是它们内部哪些用同类Tool，就把它分成同一类。在最开始，依旧是User输入Task，模型把上下文Context和Exemplar进行输入，这里与先前有所不同的是，输入到Planner中，进行分解，然后调用各自的工具Tool。在得到了所有的Tool的输出后，生成计划结果Plan和线索Evidence，放到Solver进行总结，然后生成回答。这个过程只调用了两次LLM。

e.Plan and Execute

Plan-and-execute这个方法本质上是先计划再执行，即先把用户的问题分解成一个个的子任务，然后再执行各个子任务，最后合并输出得到结果。

架构上包含了规划器和执行器：规划器负责让 LLM 生成一个多步计划来完成一个大任务，代码中有 Planner 和和 Replanner，Planner 负责第一次生成计划，Replanner 是指在完成单个任务后，根据目前任务的完成情况进行 Replan。执行器接受用户查询和规划中的步骤，并调用一个或多个工具来完成该任务。

f. LLM Compiler

LLM Comlipler简而言之，就是通过并行Function calling来提高效率。

比如下图的例子，向Agent提问“微软的市值需要增加多少才能超过苹果的市值？”，Planner并行搜索微软的市值和苹果的市值，然后进行合并计算。

LLM Compiler主要有以下组件：

Planner：流失传输任务的DAG，每个任务都包含一个工具、参数和依赖项列表。

Task Fetching Unit：调度并执行任务，一旦满足任务的依赖性，该单元就会安排任务。由于许多工具涉及对搜索引擎或LLM的其他调用，因此额外的并行性可以显著提高速度。

Joiner：由LLM根据整个历史记录（包括任务执行结果），动态重新计划或技术，决定是否响应最终答案或是否将进度重新传递回Planner。

g. LATS

LATS，全称是Language Agent Tree Search。说的更直白一些，LATS = Tree search + ReAct+Plan&solve + Reflection + 强化学习。

这种技术受到蒙特卡洛树搜索的启发，将状态表示为节点，而采取行动则视为在节点之间的遍历。LATS使用基于语言模型的启发式方法来搜索可能的选项，然后利用状态评估器来选择行动。

与其他基于树的方法相比，LATS实现了自我反思的推理步骤，显著提升了性能。当采取行动后，LATS不仅利用环境反馈，还结合来自语言模型的反馈，以判断推理中是否存在错误并提出替代方案。这种自我反思的能力与其强大的搜索算法相结合，使得LATS在执行各种任务时表现出色。

LATS有四个主要的步骤：

1. 选择：根据下面步骤中的总奖励选择最佳的下一步行动，如果找到解决方案或达到最大搜索深度，做出响应；否则就继续搜索
2. 扩展和执行：生成N个潜在操作，并且并行执行
3. 反思和评估：观察这些行动的结果，并根据反思和外部反馈对决策评分
4. 反向传播：根据结果更新轨迹的分数

h. Self Discover

Self-discover 的核心是让大模型在更小粒度上 task 本身进行反思，比如前文中的 Plan&Slove 是反思 task 是不是需要补充，而 Self-discover 是对 task 本身进行反思。

在self-discover机制下，主要有三个组件。Selector负责从众多的反省方式中选择合适的反省方式；Adaptor使用选择的反省方式进行反省；Implementor则负责在反省后进行重新 Reasoning。

3. Action（行动）

Action环节负责AI Agent和物理世界的交互，风叔主要介绍两种执行机制，Function Calling和API Bank。

3.1 Function Calling

Function calling指的是大模型调用特定函数的能力，这些函数可以是内置的，也可以是用户自定义的。在执行任务时，模型会通过分析问题来决定何时以及如何调用这些函数，例如大模型在回答数学问题时，就会使用内部的计算函数来得出答案。

Function Calling 机制主要由以下四个关键组件构成：

• 函数定义：预先定义可调用的函数，包括名称、参数类型和返回值类型等。
• 函数调用请求：用户或系统发出的调用请求，包含函数名称及所需参数。
• 函数执行器：实际执行函数的组件，可能是外部的 API 或本地逻辑处理器。
• 结果返回：函数执行完毕后，返回结果给 ChatGPT，继续对话

举个实际的例子，比如我们询问大模型，“人工智能相关股票，市盈率最低的是哪几个？最近交易量如何？”

• 第一步，准备API接口和认证信息，确定用于获取股票信息的API接口URL，获取并准备好API密钥或其他认证信息。
• 第二步，定义函数以获取市盈率最低的人工智能股票。需要编写一个函数，该函数接受API接口URL和API密钥作为参数。在函数内部，构造请求参数，指定股票分类为人工智能，按市盈率升序排列，并限制返回结果的数量；发送HTTP GET请求到API接口，并传入构造好的请求参数和API密钥；解析响应内容，提取市盈率最低的股票列表信息，返回市盈率最低的股票列表。
• 第三步，定义函数以获取股票的最近交易量。再编写一个函数，该函数接受API接口URL、API密钥和股票代码作为参数；构造特定于股票代码的API请求URL；发送HTTP GET请求到构造好的URL，并传入API密钥；解析响应内容，提取交易量信息，并返回交易量信息。
• 第四步，调用函数并处理结果。调用步骤2中定义的函数，获取市盈率最低的人工智能股票列表；调用步骤3中定义的函数，获取该股票的最近交易量信息；遍历股票列表，对于每只股票，打印或存储获取到的信息，包括股票代码、市盈率和最近交易量。

但是，大家需要注意的是，目前大模型的Function Calling可靠性还非常不足，根据行业对各个大模型的测试结果来看，Function Calling准确性最高的也只有86%，大大限制了AI Agent和现实世界的交互。至少，以目前的水平来看，比较critical的场景下使用Function Calling还是非常受限的。

3.2 API Bank

API-Bank 模拟真实世界并创建了包含 53 个常用工具的 API 库，例如搜索引擎、播放音乐、预订酒店、图像描述等，供 LLMs 调用。还包含了 264 个经过人工审核的对话、568 个 API 调用，来评估模型在给定的对话语境中，使用 API 完成用户需求的表现。

API-Bank 将测试分为三个级别。

• 级别1：评估 LLMs 正确调用 API 的能力。在给定 API的用法描述和对话历史的前提下，模型需要判断是否调用 API、正确地调用 API、获得 API 调用结果后正确的回复用户。
• 级别2：进一步评估 LLMs 检索 API 的能力。在测试开始时，模型仅被告知 API 检索系统的用法，任何对话中需要用到的特定 API 的信息都不可见。LLMs 必须根据对话历史判断用户需求，关键词搜索可能能够解决用户需求的 API，并在检索到正确的 API 后学习如何使用 API。
• 级别3：评估 LLMs 规划多个 API 调用的能力。在这个级别中，用户的需求可能不明确，需要多个 API 调用步骤来解决。例如：“我想从上海到北京旅行一周，从明天开始。帮我规划旅行路线并预订航班、门票和酒店”。LLMs 必须推断出合理的旅行计划，基于计划调用航班、酒店和门票预订 API 来完成用户需求。

3.3 Agent市场

Agent除了可以调用API之外，还可以调用其他成熟的Agent。比如完成一份关于AI Agent的市场调研报告，可以先调用专门做市场调研的Agent，输出市场调研的关键信息；再调用专门做PPT的Agent，将关键信息整理成可用于汇报的PPT形式。

因此，对于一个Agent平台来说，除了具备Agent搭建能力之外，拥有一个公开的、可供调用的Agent市场也是非常有必要的。比如，下图是字节Coze的Agent市场示例图。

4. Workflow模块

为什么会产生workflow？

因为LLM大模型本身存在“不确定性”，即无论是大模型的规划能力、还是工具调用能力、抑或是自然语言输出，都存在比较强的不可控性。因此，需要对AI Agent的行动增加一定程度的限制，来保障AI Agent不要out of control。尤其是在严谨的企业级应用中，更需要AI Agent的可控和准确。

在这样的背景下，Agentic Workflow诞生了。

Agentic Workflow 通过将一个复杂的任务分解成较小的步骤，在整个过程中中融入了更多人类参与到流程中的规划与定义。它减少了对 Prompt Engineering 和模型推理能力的依赖，提高了 LLM 应用面向复杂任务的性能。

下面是字节Coze平台上的工作流编排器的示例，一个快速生成PPT的流程。

通常来说，Agentic Workflow主要包含以下关键组件

• 开始节点：每一个工作流都需要一个开始节点，在开始节点内定义输入变量支持文本、段落、下拉选项、数字、文件。配置完成后，在工作流执行时会要求输入开始节点中定义的变量值。
• 结束节点：每一个工作流在完整执行后都需要至少一个结束节点，用于输出完整执行的最终结果。结束节点需要声明一个或多个输出变量，声明时可以引用任意上游节点的输出变量
• 直接回复：可以在文本编辑器中自由定义回复格式，包括自定义一段固定的文本内容、使用前置步骤中的输出变量作为回复内容、或者将自定义文本与变量组合后回复
• LLM大模型：LLM 是Workflow 的核心节点，利用大语言模型的对话/生成/分类/处理等能力，根据给定的提示词处理广泛的任务类型，并能够在工作流的不同环节使用。
• 知识检索：即记忆模块中介绍的RAG能力，从知识库中检索与用户问题相关的文本内容，可作为下游 LLM 节点的上下文来使用。
• 问题分类：通过定义分类描述，问题分类器能够根据用户输入推理与之相匹配的分类并输出分类结果。常见的使用情景包括客服对话意图分类、产品评价分类、邮件批量分类等
• 条件分支：允许用户根据 if/else 条件将 workflow 拆分成多个分支，极大地提升workflow的灵活性。
• 代码执行：该节点极大地增强了开发人员的灵活性，使他们能够在工作流程中嵌入自定义的 Python 或 Javascript 脚本，并以预设节点无法达到的方式操作变量。比如结构化数据处理、科学计算、数据拼接
• 变量聚合：变量聚合节点是工作流程中的一个关键节点，它负责整合不同分支的输出结果，确保无论哪个分支被执行，其结果都能通过一个统一的变量来引用和访问。比如问题分类节点后、条件分支节点后的多路聚合
• 参数提取：利用 LLM 从自然语言推理并提取结构化参数，用于后置的工具调用或 HTTP 请求。比如从论文中提取论文作者 或 论文编号
• Http请求：允许通过 HTTP 协议发送服务器请求，适用于获取外部数据、webhook、生成图片、下载文件等情景
• 工具：包括谷歌搜索、天气查询等内置工具；通过 OpenAPI/Swagger 标准格式导入或配置的自定义工具；已发布为工具的工作流，也可以被其他工作流当做工具来引用

另外，大家需要注意的是，大模型根源的“不太聪明”，是加上workflow也解决不了的。因为工作流解决的并不是意图理解准确率的问题，而是在流程上的被干预后的可控性，吴恩达老师也在红杉的演讲上提到提升大模型本身质量依旧十分重要。

5. 安全模块

AI Agent的安全主要包含两方面。一方面是LLM大模型对齐，即大模型本身的输出要符合人类的价值观，不能输出涉黄涉黑涉恐等不合法的言论。另外一方面是Agent的访问和数据安全，确保Agent的数据、模型和决策过程不被未经授权的实体访问或攻击。

LLM大模型对齐是一个非常宏大和复杂的话题，到目前为止，风叔尚未在这块有较多的知识和经验积累，而且大模型对齐更多是OpenAI、LLama等企业才能做的事情，所以此处不做展开。

Agent的数据和访问安全，可以通过SSL协议传输、私有化部署、移动Agent安全信任模型TMMARC等方式，防止Agent数据泄露或被恶意篡改。

一个Agent系统，除了上述五大模块之外，还需要有辅助系统，比如账号权限、系统部署、使用引导等等。

三、如何学习AI Agent

如果大家希望更多了解AI Agent，或者未来想从事AI Agent相关的职业，风叔建议按照以下三步来学习。

第一步，上手体验

先通过上手体验，直观地知晓AI Agent能做什么，因为AI Agent最核心的应用场景其实是在工作流workflow，风叔建议使用Dify或者字节Coze进行实操。

Dify和Coze都提供了非常详细的Guide，以Coze为例，大家可以通过coze的官方文档 https://www.coze.cn/docs/guides/welcome 快速学习到如何搭建一个Agent和Workflow。

如果大家能实际跑通一个Agent或workflow，就会对Agent的很多概念和组件有更深刻的认识。

第二步，挖掘本质

初步上手Agent之后，可以进一步深挖，学习Agent背后的知识。

风叔建议直接通过AutoGPT进行学习，https://github.com/Significant-Gravitas/AutoGPT，AutoGPT的Github地址提供了丰富的文档和源代码。对于有一定编程基础的同学，建议把代码下载下来，在本地跑通的同时，了解其底层的技术架构。对于没有编程基础的同学，可以详细阅读AutoGPT的Document。

此外，还有一些重点知识，比如RAG、Rerank、COT/TOT/GOT、ReAct、Reflection等技术，可以通过阅读相关文章或论文进行学习。

第三步，动手实操

对于想更进一步学习和实践AI Agent的同学，可以仔细研究一下LangChain，https://github.com/langchain-ai/langchain。

虽然Langchain有很多的不足，在实际产品开发中有不少的局限，但仍然是一个入门AI Agent的好工具。而且Langchain的作者很用心，持续在维护Github，也提供了很丰富的example。有代码能力的同学，也可以通过Langchain提供的demo进行一定程度的二开。

四、总结

本篇文章是使用5W1H分析框架拆解AI Agent的下篇，围绕How，详细介绍AI Agent的具体实现路径，以及如何更快的上手学习AI Agent。至此，整个5W1H框架拆解AI Agent系列就讲完了。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！