如何构建一个完整的AI Agent系统？本文从Perception（输入）到Brain（大脑），再到Action（行动），每一步都进行了细致的讲解和指导。无论你是AI技术的初学者还是希望深入了解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系统，都需要哪些步骤。
AI Agent应该能够接收多种信息输入，从最简单的文本和语音，到更复杂的图片、视频和传感器数据。因此从产品功能角度，AI Agent应该具备以下能力。
现在的大模型主要是通过语言进行交互，这样显然是不够的。如果要进一步理解世界，一定需要多模态输入，包括视觉、听觉、传感器等等。因此，未来的AI Agent一定会更多和物理实体相结合，比如将AI Agent集成进入机器狗，训练其进行救援任务。在这个过程中，对于时间的认知、身体运动的控制也需要集成到AI Agent里面去。
当然，在实际产品设计中，需要根据实际AI Agent的应用场景来设计其支持的输入类型。
记忆，在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大模型发起请求。
规划模块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有四个主要的步骤：
h. Self Discover
Self-discover 的核心是让大模型在更小粒度上 task 本身进行反思，比如前文中的 Plan&Slove 是反思 task 是不是需要补充，而 Self-discover 是对 task 本身进行反思。
在self-discover机制下，主要有三个组件。Selector负责从众多的反省方式中选择合适的反省方式；Adaptor使用选择的反省方式进行反省；Implementor则负责在反省后进行重新 Reasoning。
Action环节负责AI Agent和物理世界的交互，风叔主要介绍两种执行机制，Function Calling和API Bank。
3.1 Function Calling
Function calling指的是大模型调用特定函数的能力，这些函数可以是内置的，也可以是用户自定义的。在执行任务时，模型会通过分析问题来决定何时以及如何调用这些函数，例如大模型在回答数学问题时，就会使用内部的计算函数来得出答案。
Function Calling 机制主要由以下四个关键组件构成：
举个实际的例子，比如我们询问大模型，“人工智能相关股票，市盈率最低的是哪几个？最近交易量如何？”
但是，大家需要注意的是，目前大模型的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 将测试分为三个级别。
3.3 Agent市场
Agent除了可以调用API之外，还可以调用其他成熟的Agent。比如完成一份关于AI Agent的市场调研报告，可以先调用专门做市场调研的Agent，输出市场调研的关键信息；再调用专门做PPT的Agent，将关键信息整理成可用于汇报的PPT形式。
因此，对于一个Agent平台来说，除了具备Agent搭建能力之外，拥有一个公开的、可供调用的Agent市场也是非常有必要的。比如，下图是字节Coze的Agent市场示例图。
为什么会产生workflow？
因为LLM大模型本身存在“不确定性”，即无论是大模型的规划能力、还是工具调用能力、抑或是自然语言输出，都存在比较强的不可控性。因此，需要对AI Agent的行动增加一定程度的限制，来保障AI Agent不要out of control。尤其是在严谨的企业级应用中，更需要AI Agent的可控和准确。
在这样的背景下，Agentic Workflow诞生了。
Agentic Workflow 通过将一个复杂的任务分解成较小的步骤，在整个过程中中融入了更多人类参与到流程中的规划与定义。它减少了对 Prompt Engineering 和模型推理能力的依赖，提高了 LLM 应用面向复杂任务的性能。
下面是字节Coze平台上的工作流编排器的示例，一个快速生成PPT的流程。
通常来说，Agentic Workflow主要包含以下关键组件
另外，大家需要注意的是，大模型根源的“不太聪明”，是加上workflow也解决不了的。因为工作流解决的并不是意图理解准确率的问题，而是在流程上的被干预后的可控性，吴恩达老师也在红杉的演讲上提到提升大模型本身质量依旧十分重要。
AI Agent的安全主要包含两方面。一方面是LLM大模型对齐，即大模型本身的输出要符合人类的价值观，不能输出涉黄涉黑涉恐等不合法的言论。另外一方面是Agent的访问和数据安全，确保Agent的数据、模型和决策过程不被未经授权的实体访问或攻击。
LLM大模型对齐是一个非常宏大和复杂的话题，到目前为止，风叔尚未在这块有较多的知识和经验积累，而且大模型对齐更多是OpenAI、LLama等企业才能做的事情，所以此处不做展开。
Agent的数据和访问安全，可以通过SSL协议传输、私有化部署、移动Agent安全信任模型TMMARC等方式，防止Agent数据泄露或被恶意篡改。
一个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系列就讲完了。
作者：风叔，微信公众号：风叔云
本文由@风叔 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。