如何構(gòu)建一個(gè)完整的AI Agent系統(tǒng)？本文從Perception（輸入）到Brain（大腦），再到Action（行動(dòng)），每一步都進(jìn)行了細(xì)致的講解和指導(dǎo)。無論你是AI技術(shù)的初學(xué)者還是希望深入了解AI Agent的專業(yè)人士，這篇文章都將為你提供寶貴的信息和知識(shí)。

本篇文章是使用5W1H分析框架拆解AI Agent的下篇，在進(jìn)入正文之前，先總體回顧這一系列文章的脈絡(luò)。

上篇：介紹What + Why，主要解答以下問題。

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

Why：為什么會(huì)產(chǎn)生AI Agent？AI Agent的優(yōu)勢(shì)和劣勢(shì)是什么？為什么企業(yè)和個(gè)人都要關(guān)注AI Agent？

中篇：介紹When + Where + Who，主要解答以下問題。

When：AI Agent的發(fā)展歷程是怎樣的？AI Agent未來的發(fā)展趨勢(shì)是怎樣的？

Where：AI Agent有哪些應(yīng)用場(chǎng)景？

Who：AI Agent領(lǐng)域的玩家有哪些？AI Agent領(lǐng)域的行業(yè)價(jià)值鏈?zhǔn)窃鯓拥模?/p>

下篇：介紹 How，主要解答以下問題。

How：如何實(shí)現(xiàn)AI Agent？AI Agent包括哪些系統(tǒng)模塊？如何開始學(xué)習(xí)AI Agent？

大家也可以關(guān)注GZH“風(fēng)叔云”，回復(fù)關(guān)鍵詞“拆解AI Agent”，獲得《5W1H分析框架拆解AI Agent》的完整PPT文件。

在《大佬們都在關(guān)注的AI Agent，到底是什么？用5W1H分析框架拆解AI Agent（中篇）》中，圍繞When、Who和Where，風(fēng)叔詳細(xì)闡述了AI Agent的發(fā)展歷程、行業(yè)玩家和各行業(yè)應(yīng)用場(chǎng)景。

在這篇文章中，風(fēng)叔將圍繞How，站在產(chǎn)品實(shí)踐的角度，詳細(xì)介紹AI Agent的具體實(shí)現(xiàn)路徑，以及如何更快的上手學(xué)習(xí)AI Agent。

閱讀過《大佬們都在關(guān)注的AI Agent，到底是什么？用5W1H分析框架拆解AI Agent（上篇）》的讀者應(yīng)該了解，從結(jié)構(gòu)上來說，一個(gè)AI Agent包括三個(gè)部分，如下圖所示：

Perception（輸入）：AI Agent通過文字輸入、傳感器、攝像頭、麥克風(fēng)等等，建立起對(duì)外部世界或環(huán)境的感知。

Brain（大腦）：AI Agent最重要的部分，包括信息存儲(chǔ)、記憶、知識(shí)庫、規(guī)劃決策系統(tǒng)。

Action（行動(dòng)）：基于 Brain給出的決策進(jìn)行下一步行動(dòng)，對(duì)于AI Agent來說，行動(dòng)主要包括對(duì)外部工具的API 調(diào)用，或者對(duì)物理控制組件的信號(hào)輸出

接下來，我們就按照這個(gè)模塊劃分，逐級(jí)下鉆，詳細(xì)介紹搭建一個(gè)完整的AI Agent系統(tǒng)，都需要哪些步驟。

一、Perception（輸入）

AI Agent應(yīng)該能夠接收多種信息輸入，從最簡(jiǎn)單的文本和語音，到更復(fù)雜的圖片、視頻和傳感器數(shù)據(jù)。因此從產(chǎn)品功能角度，AI Agent應(yīng)該具備以下能力。

• 文本輸入：這是最常見的AI Agent接收用戶指令的方式；如果要求AI Agent具備chat能力，還需要有基礎(chǔ)的對(duì)話框，便于和用戶進(jìn)行自然語言交互。
• 語音輸入：本質(zhì)上還是文本輸入，只需要在輸入環(huán)節(jié)額外增加一層ASR轉(zhuǎn)TTS，將語音轉(zhuǎn)化為文本。
• 文件上傳：在特定場(chǎng)景下，AI Agent需要對(duì)用戶上傳的文檔進(jìn)行分析，例如財(cái)報(bào)智能解讀、合同智能審查等，需要具備文件上傳功能
• 圖片和視頻輸入：AI Agent有時(shí)候需要處理圖片，比如進(jìn)行圖像處理、醫(yī)學(xué)影像分析。視頻輸入本質(zhì)上也是圖片輸入，在輸入層對(duì)視頻流進(jìn)行切片，比如線下門店監(jiān)控、視頻信息提取等場(chǎng)景。
• 傳感器輸入：在制造業(yè)和能源行業(yè)，會(huì)要求AI Agent進(jìn)行設(shè)備狀態(tài)監(jiān)控和預(yù)警，這個(gè)時(shí)候就要求AI Agent具備傳感器對(duì)接能力，接收來自設(shè)備的溫度、電壓、電流等數(shù)據(jù)。

現(xiàn)在的大模型主要是通過語言進(jìn)行交互，這樣顯然是不夠的。如果要進(jìn)一步理解世界，一定需要多模態(tài)輸入，包括視覺、聽覺、傳感器等等。因此，未來的AI Agent一定會(huì)更多和物理實(shí)體相結(jié)合，比如將AI Agent集成進(jìn)入機(jī)器狗，訓(xùn)練其進(jìn)行救援任務(wù)。在這個(gè)過程中，對(duì)于時(shí)間的認(rèn)知、身體運(yùn)動(dòng)的控制也需要集成到AI Agent里面去。

當(dāng)然，在實(shí)際產(chǎn)品設(shè)計(jì)中，需要根據(jù)實(shí)際AI Agent的應(yīng)用場(chǎng)景來設(shè)計(jì)其支持的輸入類型。

二、Brain（大腦）

1. 記憶模塊

記憶，在Agent系統(tǒng)中扮演著十分重要角色，負(fù)責(zé)存儲(chǔ)和組織從環(huán)境中獲取的信息，以指導(dǎo)未來行動(dòng)。記憶模塊通常包含短期記憶和長(zhǎng)期記憶兩個(gè)部分。

短期記憶暫存最近的感知，通常是和AI Agent對(duì)話的上下文，這塊相對(duì)比較簡(jiǎn)單，直接將短期記憶存入緩存即可。

困難點(diǎn)在于長(zhǎng)期記憶，長(zhǎng)期記憶的容量要遠(yuǎn)遠(yuǎn)大于短期記憶，如何讓AI Agent從長(zhǎng)期記憶中快速且準(zhǔn)確地回憶起相關(guān)內(nèi)容，是在這一模塊需要重點(diǎn)解決的問題。

要實(shí)現(xiàn)良好的長(zhǎng)期記憶性能，有三個(gè)重要的技術(shù)依賴項(xiàng)，向量數(shù)據(jù)庫、RAG技術(shù)和Rerank技術(shù)。

a.向量數(shù)據(jù)庫

AI Agent的記憶系統(tǒng)，不能采用傳統(tǒng)數(shù)據(jù)庫進(jìn)行存儲(chǔ)，必須采用向量數(shù)據(jù)庫。像MySQL這樣的傳統(tǒng)數(shù)據(jù)庫，在AI應(yīng)用場(chǎng)景中，有兩個(gè)非常致命的缺陷。

第一個(gè)缺陷是語義搜索的缺失，比如用戶想在文檔中找到表達(dá)“精彩萬分”或“激動(dòng)人心”的段落，傳統(tǒng)數(shù)據(jù)庫是肯定做不到的，傳統(tǒng)數(shù)據(jù)庫只能基于確定的“關(guān)鍵詞”進(jìn)行精確匹配或者模糊匹配。

第二個(gè)缺陷是非結(jié)構(gòu)化數(shù)據(jù)處理不足，對(duì)于圖像、音頻和視頻等非文本內(nèi)容，傳統(tǒng)數(shù)據(jù)庫無法進(jìn)行有效的內(nèi)容搜索。比如用戶想找到《星球大戰(zhàn)》電影中天行者出現(xiàn)的片段，就無法通過傳統(tǒng)數(shù)據(jù)庫實(shí)現(xiàn)。

而向量數(shù)據(jù)庫是一種特殊的數(shù)據(jù)庫，它以多維向量的形式保存信息，代表某些特征或質(zhì)量。根據(jù)數(shù)據(jù)的復(fù)雜性和詳細(xì)程度，每個(gè)向量的維數(shù)可能相差很大，從幾維到幾千維不等。這些數(shù)據(jù)可能包括文本、圖像、音頻和視頻，通過機(jī)器學(xué)習(xí)模型、單詞嵌入或特征提取技術(shù)等各種流程轉(zhuǎn)化為向量。

向量數(shù)據(jù)庫的主要優(yōu)勢(shì)在于，它能夠根據(jù)數(shù)據(jù)的向量接近度或相似度，快速、精確地定位和檢索數(shù)據(jù)。這樣就可以根據(jù)語義或上下文的相關(guān)性進(jìn)行搜索，比如根據(jù)旋律和節(jié)奏搜索出特定的歌曲、在電影中搜索浪漫的片段、在文檔中找出意圖相近的段落等等。

上圖簡(jiǎn)單展示了向量數(shù)據(jù)庫的存儲(chǔ)過程，無論是文本、音頻還是視頻，最后都會(huì)轉(zhuǎn)換成Vector，以向量的方式存儲(chǔ)。

b. 檢索增強(qiáng)生成RAG

RAG（Retrieval Augmented Generation），其主要作用類似于搜索引擎，找到用戶提問最相關(guān)的知識(shí)或者是相關(guān)的對(duì)話歷史，并結(jié)合原始提問，創(chuàng)造信息豐富的prompt，指導(dǎo)LLM大模型生成更準(zhǔn)確的輸出。簡(jiǎn)而言之，RAG就是給大模型它原本數(shù)據(jù)集中沒有的知識(shí)。

RAG技術(shù)產(chǎn)生最大的原因，是為了克服大模型的幻覺問題，以及在專業(yè)領(lǐng)域知識(shí)理解較差的缺陷。

RAG可分為5個(gè)基本流程：知識(shí)文檔的準(zhǔn)備、嵌入模型、向量數(shù)據(jù)庫、查詢檢索和生產(chǎn)回答。

現(xiàn)實(shí)場(chǎng)景中，我們面對(duì)的知識(shí)源可能包括多種格式，如Word文檔、TXT文件、CSV數(shù)據(jù)表、Excel表格，甚至圖片和視頻。因此需要使用專門的文檔加載器（例如PDF提取器）或多模態(tài)模型（如OCR技術(shù)），將這些豐富的知識(shí)源轉(zhuǎn)換為大語言模型可理解的純文本數(shù)據(jù)，然后開啟RAG的五個(gè)核心步驟。

第一步，文檔切片/分塊：在企業(yè)級(jí)應(yīng)用場(chǎng)景中，文檔尺寸可能非常大，因此需要將長(zhǎng)篇文檔分割成多個(gè)文本塊，以便更高效地處理和檢索信息。分塊的方式有很多種，比如按段落、按內(nèi)容或者其他特殊結(jié)構(gòu)。同時(shí)，需要注意分塊的尺寸，如果分塊太小，雖然查詢更精準(zhǔn)，但召回時(shí)間更長(zhǎng)；如果分塊太大，則會(huì)影響查詢精準(zhǔn)度。

第二步，嵌入模型：嵌入模型的核心任務(wù)是將文本轉(zhuǎn)換為向量形式，這樣我們就能通過簡(jiǎn)單的計(jì)算向量之間的差異性，來識(shí)別語義上相似的句子。

第三步，存入向量數(shù)據(jù)庫：將文檔切片和嵌入模型的結(jié)果存儲(chǔ)進(jìn)入向量數(shù)據(jù)庫，上文介紹了向量數(shù)據(jù)庫，此處不再贅述。

第四步，用戶查詢檢索：用戶的問題會(huì)被輸入到嵌入模型中進(jìn)行向量化處理，然后系統(tǒng)會(huì)在向量數(shù)據(jù)庫中搜索與該問題向量語義上相似的知識(shí)文本或歷史對(duì)話記錄并返回，這就是檢索增強(qiáng)。

第五步，生成問答：最終將用戶提問和上一步中檢索到的信息結(jié)合，構(gòu)建出一個(gè)提示模版，輸入到大語言模型中，由大模型生成最終的結(jié)果并返回

c. 內(nèi)容重排技術(shù)Rerank

在RAG技術(shù)中，也存在一些局限性，比如使用ElasticSearch的retrieval召回的內(nèi)容相關(guān)度有問題。多數(shù)情況下score最高的chunk相關(guān)度沒問題，但是top2-5的相關(guān)度就很隨機(jī)了，這是最影響最終結(jié)果的。

ElasticSearch使用HNSW算法，導(dǎo)致搜索的時(shí)候存在隨機(jī)性，這就是RAG中第一次召回的結(jié)果往往不太滿意的原因。但是這也沒辦法，如果你的索引有數(shù)百萬甚至千萬的級(jí)別，那只能犧牲一些精確度以換回時(shí)間。

這時(shí)候我們可以做的就是增加top_k的大小，比如從原來的10個(gè)，增加到30個(gè)。然后再使用更精確的算法來做rerank，使用計(jì)算打分的方式，做好排序。

目前，已經(jīng)有一些很成熟的Rerank工具可供大家使用，例如Cohere、JinaAI

上圖展示了在Agent應(yīng)用中使用向量數(shù)據(jù)庫的三種場(chǎng)景。

第一種情況，用戶的提問不依賴長(zhǎng)期記憶，直接從向量數(shù)據(jù)庫中獲取關(guān)聯(lián)文檔，然后向LLM大模型獲取結(jié)果。

第二種情況，用戶查詢一個(gè)問題，無法直接從向量數(shù)據(jù)庫獲取結(jié)果，需要先從長(zhǎng)期以及中獲取對(duì)應(yīng)的知識(shí)塊，再向LLM大模型獲取結(jié)果。

第三種情況，用戶進(jìn)行多次提問，則先檢查緩存中是否存在類似問題和答案，優(yōu)先從緩存中查詢返回結(jié)果；如果緩存中不存在，則向LLM大模型發(fā)起請(qǐng)求。

2. 規(guī)劃模塊

規(guī)劃模塊Planning是整個(gè)AI Agent中最核心最關(guān)鍵的部分，Agent會(huì)把大型任務(wù)分解為子任務(wù)，并規(guī)劃執(zhí)行任務(wù)的流程。同時(shí)Agent還會(huì)對(duì)任務(wù)執(zhí)行的過程進(jìn)行思考和反思，從而決定是繼續(xù)執(zhí)行任務(wù)，還是判斷任務(wù)完結(jié)并終止運(yùn)行。

在《大佬們都在關(guān)注的AI Agent，到底是什么？用5W1H分析框架拆解AI Agent（上篇）》中，風(fēng)叔詳細(xì)介紹了子任務(wù)分解和反思，其中子任務(wù)分解主要包括思維鏈COT、思維樹TOT、思維圖GOT、LLM+PDDL等方法；反思主要包括ReAct、Reflection、Multi-Agent等方式。

接下來，我們從產(chǎn)品設(shè)計(jì)的維度，來看一下比較主流的Planning設(shè)計(jì)模式。

a. ReAct

最容易理解的Planning模式，ReAct本質(zhì)上就是把融合了Reasoning和Acting的一種范式，推理過程是淺顯易懂，僅僅包含thought-action-observation步驟，很容易判斷推理的過程的正確性，使用ReAct做決策甚至超過了強(qiáng)化學(xué)習(xí)。

ReACT的主要特性是同步推理Reasoning和行動(dòng)Acting。比如在上圖中，拋出一個(gè)問題，關(guān)于最初的遠(yuǎn)程控制蘋果的設(shè)備有哪些。1a中的回答是直接的；1b的回答是基于思維鏈CoT方式，能夠一步一步進(jìn)行思考，最初只得出了iphone、ipad、ipod、itouch；1c的回答是只基于行動(dòng)，比如先搜索Apple Remote，然后根據(jù)結(jié)果繼續(xù)搜索Front Row軟件，直接就得出了答案，但是這個(gè)答案并不是想要的；在1d中，使用了ReACT方式，結(jié)合了思考Thoughts和行動(dòng)Acting，使得得出的結(jié)論更加趨于正確結(jié)果。

b. Basic Reflection

Basic Reflection可以類比于左右互博。左手是Generator，負(fù)責(zé)根據(jù)用戶指令生成結(jié)果；右手是Reflector，來審查左手的生成結(jié)果并給出建議。在左右互搏的情況下，Generator生成的結(jié)果越來越好，Reflector的檢查越來越嚴(yán)格，提供的建議也越來越有效。

c. Reflexion

Reflexion本質(zhì)上是強(qiáng)化學(xué)習(xí)，可以理解為是Basic reflection 的升級(jí)版。Reflexion機(jī)制下，整個(gè)架構(gòu)包括Responder和Reviser，和Basic Reflection機(jī)制中的Generator和Reflector有點(diǎn)類似。但不同之處在于， Responder自帶批判式思考的陳述，Revisor會(huì)以 Responder 中的批判式思考作為上下文參考對(duì)初始回答做修改。此外，Revisor還引入了外部數(shù)據(jù)來評(píng)估回答是否準(zhǔn)確，這使得反思的內(nèi)容更加具備可靠性。

d.REWOO

REWOO的全稱是Reason without Observation，是相對(duì)ReAct中的Observation 來說的。ReAct普遍有冗余計(jì)算的問題，冗余會(huì)導(dǎo)致過多的計(jì)算開銷和過長(zhǎng)的Token使用。而在ReWOO中，使用模塊化解耦，完成預(yù)測(cè)性推理和工具執(zhí)行，token使用效率要優(yōu)于ReAct，并提高了在復(fù)雜環(huán)境下的性能。

如上圖所示，左側(cè)是以ReAct為主的方法。當(dāng)User輸入Task后，把上下文Context和可能的樣本Exemple輸入到LLM中，LLM會(huì)調(diào)用一個(gè)目標(biāo)工具Tool，從而產(chǎn)生想法Thought，行動(dòng)Action，觀察Observation。由于拆解后的下一次循環(huán)也需要調(diào)用LLM，又會(huì)調(diào)用新的工具Tool，產(chǎn)生新的Thought，Action，Observation，后續(xù)的輸入是需要疊加前面的Thought，Action，Observation以及Task，Context，Examplar，從而不斷地迭代，完成推理Reasoning，然后生成答案Answer。如果這個(gè)步驟變得很長(zhǎng)，并且Token很長(zhǎng)就會(huì)導(dǎo)致巨大的重復(fù)計(jì)算和開銷。

而右右側(cè)ReWOO的方法，計(jì)劃器Planner把任務(wù)進(jìn)行分解，分解的依據(jù)是它們內(nèi)部哪些用同類Tool，就把它分成同一類。在最開始，依舊是User輸入Task，模型把上下文Context和Exemplar進(jìn)行輸入，這里與先前有所不同的是，輸入到Planner中，進(jìn)行分解，然后調(diào)用各自的工具Tool。在得到了所有的Tool的輸出后，生成計(jì)劃結(jié)果Plan和線索Evidence，放到Solver進(jìn)行總結(jié)，然后生成回答。這個(gè)過程只調(diào)用了兩次LLM。

e.Plan and Execute

Plan-and-execute這個(gè)方法本質(zhì)上是先計(jì)劃再執(zhí)行，即先把用戶的問題分解成一個(gè)個(gè)的子任務(wù)，然后再執(zhí)行各個(gè)子任務(wù)，最后合并輸出得到結(jié)果。

架構(gòu)上包含了規(guī)劃器和執(zhí)行器：規(guī)劃器負(fù)責(zé)讓 LLM 生成一個(gè)多步計(jì)劃來完成一個(gè)大任務(wù)，代碼中有 Planner 和和 Replanner，Planner 負(fù)責(zé)第一次生成計(jì)劃，Replanner 是指在完成單個(gè)任務(wù)后，根據(jù)目前任務(wù)的完成情況進(jìn)行 Replan。執(zhí)行器接受用戶查詢和規(guī)劃中的步驟，并調(diào)用一個(gè)或多個(gè)工具來完成該任務(wù)。

f. LLM Compiler

LLM Comlipler簡(jiǎn)而言之，就是通過并行Function calling來提高效率。

比如下圖的例子，向Agent提問“微軟的市值需要增加多少才能超過蘋果的市值？”，Planner并行搜索微軟的市值和蘋果的市值，然后進(jìn)行合并計(jì)算。

LLM Compiler主要有以下組件：

Planner：流失傳輸任務(wù)的DAG，每個(gè)任務(wù)都包含一個(gè)工具、參數(shù)和依賴項(xiàng)列表。

Task Fetching Unit：調(diào)度并執(zhí)行任務(wù)，一旦滿足任務(wù)的依賴性，該單元就會(huì)安排任務(wù)。由于許多工具涉及對(duì)搜索引擎或LLM的其他調(diào)用，因此額外的并行性可以顯著提高速度。

Joiner：由LLM根據(jù)整個(gè)歷史記錄（包括任務(wù)執(zhí)行結(jié)果），動(dòng)態(tài)重新計(jì)劃或技術(shù)，決定是否響應(yīng)最終答案或是否將進(jìn)度重新傳遞回Planner。

g. LATS

LATS，全稱是Language Agent Tree Search。說的更直白一些，LATS = Tree search + ReAct+Plan&solve + Reflection + 強(qiáng)化學(xué)習(xí)。

這種技術(shù)受到蒙特卡洛樹搜索的啟發(fā)，將狀態(tài)表示為節(jié)點(diǎn)，而采取行動(dòng)則視為在節(jié)點(diǎn)之間的遍歷。LATS使用基于語言模型的啟發(fā)式方法來搜索可能的選項(xiàng)，然后利用狀態(tài)評(píng)估器來選擇行動(dòng)。

與其他基于樹的方法相比，LATS實(shí)現(xiàn)了自我反思的推理步驟，顯著提升了性能。當(dāng)采取行動(dòng)后，LATS不僅利用環(huán)境反饋，還結(jié)合來自語言模型的反饋，以判斷推理中是否存在錯(cuò)誤并提出替代方案。這種自我反思的能力與其強(qiáng)大的搜索算法相結(jié)合，使得LATS在執(zhí)行各種任務(wù)時(shí)表現(xiàn)出色。

LATS有四個(gè)主要的步驟：

1. 選擇：根據(jù)下面步驟中的總獎(jiǎng)勵(lì)選擇最佳的下一步行動(dòng)，如果找到解決方案或達(dá)到最大搜索深度，做出響應(yīng)；否則就繼續(xù)搜索
2. 擴(kuò)展和執(zhí)行：生成N個(gè)潛在操作，并且并行執(zhí)行
3. 反思和評(píng)估：觀察這些行動(dòng)的結(jié)果，并根據(jù)反思和外部反饋對(duì)決策評(píng)分
4. 反向傳播：根據(jù)結(jié)果更新軌跡的分?jǐn)?shù)

h. Self Discover

Self-discover 的核心是讓大模型在更小粒度上 task 本身進(jìn)行反思，比如前文中的 Plan&Slove 是反思 task 是不是需要補(bǔ)充，而 Self-discover 是對(duì) task 本身進(jìn)行反思。

在self-discover機(jī)制下，主要有三個(gè)組件。Selector負(fù)責(zé)從眾多的反省方式中選擇合適的反省方式；Adaptor使用選擇的反省方式進(jìn)行反??；Implementor則負(fù)責(zé)在反省后進(jìn)行重新 Reasoning。

3. Action（行動(dòng)）

Action環(huán)節(jié)負(fù)責(zé)AI Agent和物理世界的交互，風(fēng)叔主要介紹兩種執(zhí)行機(jī)制，F(xiàn)unction Calling和API Bank。

3.1 Function Calling

Function calling指的是大模型調(diào)用特定函數(shù)的能力，這些函數(shù)可以是內(nèi)置的，也可以是用戶自定義的。在執(zhí)行任務(wù)時(shí)，模型會(huì)通過分析問題來決定何時(shí)以及如何調(diào)用這些函數(shù)，例如大模型在回答數(shù)學(xué)問題時(shí)，就會(huì)使用內(nèi)部的計(jì)算函數(shù)來得出答案。

Function Calling 機(jī)制主要由以下四個(gè)關(guān)鍵組件構(gòu)成：

• 函數(shù)定義：預(yù)先定義可調(diào)用的函數(shù)，包括名稱、參數(shù)類型和返回值類型等。
• 函數(shù)調(diào)用請(qǐng)求：用戶或系統(tǒng)發(fā)出的調(diào)用請(qǐng)求，包含函數(shù)名稱及所需參數(shù)。
• 函數(shù)執(zhí)行器：實(shí)際執(zhí)行函數(shù)的組件，可能是外部的 API 或本地邏輯處理器。
• 結(jié)果返回：函數(shù)執(zhí)行完畢后，返回結(jié)果給 ChatGPT，繼續(xù)對(duì)話

舉個(gè)實(shí)際的例子，比如我們?cè)儐柎竽Ｐ?，“人工智能相關(guān)股票，市盈率最低的是哪幾個(gè)？最近交易量如何？”

• 第一步，準(zhǔn)備API接口和認(rèn)證信息，確定用于獲取股票信息的API接口URL，獲取并準(zhǔn)備好API密鑰或其他認(rèn)證信息。
• 第二步，定義函數(shù)以獲取市盈率最低的人工智能股票。需要編寫一個(gè)函數(shù)，該函數(shù)接受API接口URL和API密鑰作為參數(shù)。在函數(shù)內(nèi)部，構(gòu)造請(qǐng)求參數(shù)，指定股票分類為人工智能，按市盈率升序排列，并限制返回結(jié)果的數(shù)量；發(fā)送HTTP GET請(qǐng)求到API接口，并傳入構(gòu)造好的請(qǐng)求參數(shù)和API密鑰；解析響應(yīng)內(nèi)容，提取市盈率最低的股票列表信息，返回市盈率最低的股票列表。
• 第三步，定義函數(shù)以獲取股票的最近交易量。再編寫一個(gè)函數(shù)，該函數(shù)接受API接口URL、API密鑰和股票代碼作為參數(shù)；構(gòu)造特定于股票代碼的API請(qǐng)求URL；發(fā)送HTTP GET請(qǐng)求到構(gòu)造好的URL，并傳入API密鑰；解析響應(yīng)內(nèi)容，提取交易量信息，并返回交易量信息。
• 第四步，調(diào)用函數(shù)并處理結(jié)果。調(diào)用步驟2中定義的函數(shù)，獲取市盈率最低的人工智能股票列表；調(diào)用步驟3中定義的函數(shù)，獲取該股票的最近交易量信息；遍歷股票列表，對(duì)于每只股票，打印或存儲(chǔ)獲取到的信息，包括股票代碼、市盈率和最近交易量。

但是，大家需要注意的是，目前大模型的Function Calling可靠性還非常不足，根據(jù)行業(yè)對(duì)各個(gè)大模型的測(cè)試結(jié)果來看，F(xiàn)unction Calling準(zhǔn)確性最高的也只有86%，大大限制了AI Agent和現(xiàn)實(shí)世界的交互。至少，以目前的水平來看，比較critical的場(chǎng)景下使用Function Calling還是非常受限的。

3.2 API Bank

API-Bank 模擬真實(shí)世界并創(chuàng)建了包含 53 個(gè)常用工具的 API 庫，例如搜索引擎、播放音樂、預(yù)訂酒店、圖像描述等，供 LLMs 調(diào)用。還包含了 264 個(gè)經(jīng)過人工審核的對(duì)話、568 個(gè) API 調(diào)用，來評(píng)估模型在給定的對(duì)話語境中，使用 API 完成用戶需求的表現(xiàn)。

API-Bank 將測(cè)試分為三個(gè)級(jí)別。

• 級(jí)別1：評(píng)估 LLMs 正確調(diào)用 API 的能力。在給定 API的用法描述和對(duì)話歷史的前提下，模型需要判斷是否調(diào)用 API、正確地調(diào)用 API、獲得 API 調(diào)用結(jié)果后正確的回復(fù)用戶。
• 級(jí)別2：進(jìn)一步評(píng)估 LLMs 檢索 API 的能力。在測(cè)試開始時(shí)，模型僅被告知 API 檢索系統(tǒng)的用法，任何對(duì)話中需要用到的特定 API 的信息都不可見。LLMs 必須根據(jù)對(duì)話歷史判斷用戶需求，關(guān)鍵詞搜索可能能夠解決用戶需求的 API，并在檢索到正確的 API 后學(xué)習(xí)如何使用 API。
• 級(jí)別3：評(píng)估 LLMs 規(guī)劃多個(gè) API 調(diào)用的能力。在這個(gè)級(jí)別中，用戶的需求可能不明確，需要多個(gè) API 調(diào)用步驟來解決。例如：“我想從上海到北京旅行一周，從明天開始。幫我規(guī)劃旅行路線并預(yù)訂航班、門票和酒店”。LLMs 必須推斷出合理的旅行計(jì)劃，基于計(jì)劃調(diào)用航班、酒店和門票預(yù)訂 API 來完成用戶需求。

3.3 Agent市場(chǎng)

Agent除了可以調(diào)用API之外，還可以調(diào)用其他成熟的Agent。比如完成一份關(guān)于AI Agent的市場(chǎng)調(diào)研報(bào)告，可以先調(diào)用專門做市場(chǎng)調(diào)研的Agent，輸出市場(chǎng)調(diào)研的關(guān)鍵信息；再調(diào)用專門做PPT的Agent，將關(guān)鍵信息整理成可用于匯報(bào)的PPT形式。

因此，對(duì)于一個(gè)Agent平臺(tái)來說，除了具備Agent搭建能力之外，擁有一個(gè)公開的、可供調(diào)用的Agent市場(chǎng)也是非常有必要的。比如，下圖是字節(jié)Coze的Agent市場(chǎng)示例圖。

4. Workflow模塊

為什么會(huì)產(chǎn)生workflow？

因?yàn)長(zhǎng)LM大模型本身存在“不確定性”，即無論是大模型的規(guī)劃能力、還是工具調(diào)用能力、抑或是自然語言輸出，都存在比較強(qiáng)的不可控性。因此，需要對(duì)AI Agent的行動(dòng)增加一定程度的限制，來保障AI Agent不要out of control。尤其是在嚴(yán)謹(jǐn)?shù)钠髽I(yè)級(jí)應(yīng)用中，更需要AI Agent的可控和準(zhǔn)確。

在這樣的背景下，Agentic Workflow誕生了。

Agentic Workflow 通過將一個(gè)復(fù)雜的任務(wù)分解成較小的步驟，在整個(gè)過程中中融入了更多人類參與到流程中的規(guī)劃與定義。它減少了對(duì) Prompt Engineering 和模型推理能力的依賴，提高了 LLM 應(yīng)用面向復(fù)雜任務(wù)的性能。

下面是字節(jié)Coze平臺(tái)上的工作流編排器的示例，一個(gè)快速生成PPT的流程。

通常來說，Agentic Workflow主要包含以下關(guān)鍵組件

• 開始節(jié)點(diǎn)：每一個(gè)工作流都需要一個(gè)開始節(jié)點(diǎn)，在開始節(jié)點(diǎn)內(nèi)定義輸入變量支持文本、段落、下拉選項(xiàng)、數(shù)字、文件。配置完成后，在工作流執(zhí)行時(shí)會(huì)要求輸入開始節(jié)點(diǎn)中定義的變量值。
• 結(jié)束節(jié)點(diǎn)：每一個(gè)工作流在完整執(zhí)行后都需要至少一個(gè)結(jié)束節(jié)點(diǎn)，用于輸出完整執(zhí)行的最終結(jié)果。結(jié)束節(jié)點(diǎn)需要聲明一個(gè)或多個(gè)輸出變量，聲明時(shí)可以引用任意上游節(jié)點(diǎn)的輸出變量
• 直接回復(fù)：可以在文本編輯器中自由定義回復(fù)格式，包括自定義一段固定的文本內(nèi)容、使用前置步驟中的輸出變量作為回復(fù)內(nèi)容、或者將自定義文本與變量組合后回復(fù)
• LLM大模型：LLM 是Workflow 的核心節(jié)點(diǎn)，利用大語言模型的對(duì)話/生成/分類/處理等能力，根據(jù)給定的提示詞處理廣泛的任務(wù)類型，并能夠在工作流的不同環(huán)節(jié)使用。
• 知識(shí)檢索：即記憶模塊中介紹的RAG能力，從知識(shí)庫中檢索與用戶問題相關(guān)的文本內(nèi)容，可作為下游 LLM 節(jié)點(diǎn)的上下文來使用。
• 問題分類：通過定義分類描述，問題分類器能夠根據(jù)用戶輸入推理與之相匹配的分類并輸出分類結(jié)果。常見的使用情景包括客服對(duì)話意圖分類、產(chǎn)品評(píng)價(jià)分類、郵件批量分類等
• 條件分支：允許用戶根據(jù) if/else 條件將 workflow 拆分成多個(gè)分支，極大地提升workflow的靈活性。
• 代碼執(zhí)行：該節(jié)點(diǎn)極大地增強(qiáng)了開發(fā)人員的靈活性，使他們能夠在工作流程中嵌入自定義的 Python 或 Javascript 腳本，并以預(yù)設(shè)節(jié)點(diǎn)無法達(dá)到的方式操作變量。比如結(jié)構(gòu)化數(shù)據(jù)處理、科學(xué)計(jì)算、數(shù)據(jù)拼接
• 變量聚合：變量聚合節(jié)點(diǎn)是工作流程中的一個(gè)關(guān)鍵節(jié)點(diǎn)，它負(fù)責(zé)整合不同分支的輸出結(jié)果，確保無論哪個(gè)分支被執(zhí)行，其結(jié)果都能通過一個(gè)統(tǒng)一的變量來引用和訪問。比如問題分類節(jié)點(diǎn)后、條件分支節(jié)點(diǎn)后的多路聚合
• 參數(shù)提?。?/strong>利用 LLM 從自然語言推理并提取結(jié)構(gòu)化參數(shù)，用于后置的工具調(diào)用或 HTTP 請(qǐng)求。比如從論文中提取論文作者 或 論文編號(hào)
• Http請(qǐng)求：允許通過 HTTP 協(xié)議發(fā)送服務(wù)器請(qǐng)求，適用于獲取外部數(shù)據(jù)、webhook、生成圖片、下載文件等情景
• 工具：包括谷歌搜索、天氣查詢等內(nèi)置工具；通過 OpenAPI/Swagger 標(biāo)準(zhǔn)格式導(dǎo)入或配置的自定義工具；已發(fā)布為工具的工作流，也可以被其他工作流當(dāng)做工具來引用