如何構建一個完整的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系統，都需要哪些步驟。

一、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 腳本，并以預設節點無法達到的方式操作變量。比如結構化數據處理、科學計算、數據拼接
• 變量聚合：變量聚合節點是工作流程中的一個關鍵節點，它負責整合不同分支的輸出結果，確保無論哪個分支被執行，其結果都能通過一個統一的變量來引用和訪問。比如問題分類節點后、條件分支節點后的多路聚合
• 參數提?。?/strong>利用 LLM 從自然語言推理并提取結構化參數，用于后置的工具調用或 HTTP 請求。比如從論文中提取論文作者 或 論文編號
• Http請求：允許通過 HTTP 協議發送服務器請求，適用于獲取外部數據、webhook、生成圖片、下載文件等情景
• 工具：包括谷歌搜索、天氣查詢等內置工具；通過 OpenAPI/Swagger 標準格式導入或配置的自定義工具；已發布為工具的工作流，也可以被其他工作流當做工具來引用