起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識 深度理解Agent：AI產(chǎn)品經(jīng)理入門必讀?。ㄉ希?/h2>
通過對比Agent與傳統(tǒng)模型及工作流的差異，揭示了智能體在靈活性和效率上的優(yōu)勢。無論是AI新手還是資深產(chǎn)品經(jīng)理，本文都能幫助你快速掌握Agent的關(guān)鍵要點，為打造智能產(chǎn)品提供實用指導。
本人也在AI agent領(lǐng)域浮沉了一段時間了，落地過幾個Agent架構(gòu)的產(chǎn)品，對Agent的認識逐漸清晰具象。當首次看到Google的Agent白皮書時（https://www.kaggle.com/whitepaper-agents），不覺間竟坐在咖啡廳里一口氣讀完了。期間不斷贊嘆你歌還是你歌，清晰易懂且專業(yè)。大概也是因為真正去做過Agent的產(chǎn)品，平時也有很多深度思考，所以我認為這篇Agent真的非常必讀。因此，想以谷歌白皮書（自己手動機翻）的中文版作為主線，并穿插一些我個人積累的Agent的關(guān)鍵點和前沿觀點，整理成一篇適合AI產(chǎn)品經(jīng)理讀的Agent文章。
由于篇幅太長，分為了上下兩篇：
第一篇：引言——什么是智能體、工具篇上
第二篇：工具篇下、模型性能提升、產(chǎn)品經(jīng)理視角的洞見與警示
一、引言——什么是智能體
人類在復雜的模式識別任務(wù)中表現(xiàn)卓越，但通常需要借助工具（如書籍、搜索引擎或計算器）來補充先驗知識以得出結(jié)論。同理，生成式AI模型可通過訓練使用工具獲取實時信息或建議的實際動作。例如：
- 模型可利用數(shù)據(jù)庫檢索工具獲取客戶購買歷史以生成個性化購物推薦
- 基于用戶查詢，模型可通過API調(diào)用發(fā)送郵件或完成金融交易
為實現(xiàn)此能力，模型需具備：
- 外部工具集訪問權(quán)限
- 自主規(guī)劃與執(zhí)行任務(wù)的推理能力
這種結(jié)合推理邏輯與外部信息訪問的系統(tǒng)，即構(gòu)成智能體（Agent）。
生成式人工智能智能體可以被定義為一種應(yīng)用程序，它試圖通過觀察世界，并利用其可用的工具對世界采取行動來實現(xiàn)目標。智能體具有自主性，可以在無需人類干預的情況下獨立行動，尤其是在被賦予了它們應(yīng)該實現(xiàn)的適當目標時。智能體在實現(xiàn)目標的過程中也可以積極主動。即使在沒有人類明確指令集的情況下，智能體也能推理出接下來應(yīng)該采取什么行動來實現(xiàn)其最終目標。
為了理解智能體的內(nèi)部工作原理，我們先來介紹驅(qū)動智能體行為（behavior）、行動（action）和決策（decision making）的基礎(chǔ)組件。這些組件的組合可以被描述為一種認知架構(gòu)，通過對這些組件的混合和匹配，可以實現(xiàn)多種這樣的架構(gòu)。從核心功能來看，如圖 1 所示，智能體的認知架構(gòu)中有三個基本組件：模型（Model）、工具（Tools）和編排（Orchestration）。
模型
在智能體的范疇內(nèi)，模型指的是語言模型（LM），它將作為智能體流程的核心決策器。智能體使用的模型可以是一個或多個任意規(guī)模（小型 / 大型）的語言模型，這些模型能夠遵循基于指令的推理和邏輯框架，如ReAct、思維鏈（Chain-of-Thought）或思維樹（Tree-of-Thoughts）。模型可以是通用的、多模態(tài)的，也可以根據(jù)特定智能體架構(gòu)的需求進行微調(diào)。為了在生產(chǎn)中獲得最佳效果，你應(yīng)該選擇最適合你期望的最終應(yīng)用的模型，理想情況下，該模型應(yīng)在與你計劃在認知架構(gòu)中使用的工具相關(guān)的數(shù)據(jù)特征上進行過訓練。需要注意的是，模型通常不會使用智能體的特定配置設(shè)置（即工具選擇、編排 / 推理設(shè)置）進行訓練。不過，通過向模型提供展示智能體能力的示例，包括智能體在各種場景中使用特定工具或推理步驟的實例，就有可能進一步優(yōu)化模型以適應(yīng)智能體的任務(wù)。
工具
基礎(chǔ)模型盡管在文本和圖像生成方面表現(xiàn)出色，但仍然受到無法與外部世界交互的限制。工具彌補了這一差距，使智能體能夠與外部數(shù)據(jù)和服務(wù)進行交互，解鎖了比基礎(chǔ)模型本身更廣泛的行動范圍。工具可以采用多種形式，復雜程度各不相同，但通常與常見的網(wǎng)絡(luò) API 方法（如 GET、POST、PATCH 和 DELETE）類似。例如，一個工具可以更新數(shù)據(jù)庫中的客戶信息，或者獲取天氣數(shù)據(jù)，以影響智能體為用戶提供的旅行建議。借助工具，智能體可以訪問和處理現(xiàn)實世界的信息。這使它們能夠支持更專業(yè)的系統(tǒng)，如檢索增強生成（RAG），顯著擴展了智能體的能力，超越了基礎(chǔ)模型單獨所能達到的水平。
編排層
編排層描述了一個循環(huán)過程，它控制智能體如何獲取信息、進行一些內(nèi)部推理，并利用這些推理來指導其下一個行動或決策。一般來說，這個循環(huán)會持續(xù)進行，直到智能體達到其目標或某個停止點。編排層的復雜程度因智能體及其執(zhí)行的任務(wù)而異。有些循環(huán)可能是簡單的帶有決策規(guī)則的計算，而其他循環(huán)可能包含鏈式邏輯，涉及額外的機器學習算法，或采用其他概率推理技術(shù)。我們將在認知架構(gòu)部分更詳細地討論智能體編排層的具體實現(xiàn)。
對比澄清一些易混淆的概念
Agents vs. 模型
Agent vs. Workflow
Anthropic將Agent系統(tǒng)劃分為兩類：
- 第一類是workflow。遵循預定義的工作流，編排LLM和工具，固定代碼路徑。
- Agent：此類Agent被定義為完全自主的系統(tǒng)，這些系統(tǒng)在較長時間內(nèi)獨立運行，可以動態(tài)地指導自身流程和工具使用的系統(tǒng)。通過自身的推理、規(guī)劃能力，自主控制，完成任務(wù)。
工作流為定義明確的任務(wù)提供可預測性和一致性，而當需要大規(guī)模的靈活性和模型驅(qū)動的決策時，Agent是更好的選擇。但是，Agent系統(tǒng)通常會以延遲和成本為代價來獲得更好的任務(wù)性能，在生產(chǎn)環(huán)境中應(yīng)該考慮何時進行這種權(quán)衡。
認知架構(gòu)：智能體如何運作
智能體可以通過認知架構(gòu)，迭代地處理信息、做出明智的決策，并根據(jù)先前的輸出優(yōu)化后續(xù)行動，以實現(xiàn)其最終目標。智能體認知架構(gòu)的核心是編排層，它負責維護記憶、狀態(tài)、推理和規(guī)劃。它利用快速發(fā)展的提示工程領(lǐng)域及相關(guān)框架來指導推理和規(guī)劃，使智能體能夠更有效地與環(huán)境交互并完成任務(wù)。語言模型的提示工程框架和任務(wù)規(guī)劃領(lǐng)域的研究正在迅速發(fā)展，產(chǎn)生了多種有前景的方法。以下是當下一些最受歡迎的框架和推理技術(shù)：
- ReAct是一種提示工程框架，它為語言模型提供了一種思維過程策略，使其能夠針對用戶查詢進行推理并采取行動，無論是否有上下文示例。ReAct 提示已被證明優(yōu)于多個當前最優(yōu)（SOTA）基線，并提高了大語言模型（LLMs）與人類的交互性和可信度。
- 思維鏈（Chain-of-Thought，CoT）是一種提示工程框架，它通過中間步驟實現(xiàn)推理能力。思維鏈有各種子技術(shù)，包括自一致性、主動提示和多模態(tài)思維鏈，每種技術(shù)根據(jù)具體應(yīng)用都有其優(yōu)缺點。
- 思維樹（Tree-of-thoughts，ToT）是一種提示工程框架，適用于探索或戰(zhàn)略前瞻性任務(wù)。它是對思維鏈提示的擴展，允許模型探索各種思維鏈，這些思維鏈可作為使用語言模型解決一般問題的中間步驟。
智能體可以使用上述推理技術(shù)為給定的用戶請求選擇下一個最佳行動。例如，我們考慮一個被編程為使用 ReAct 框架為用戶查詢選擇正確行動和工具的智能體。事件序列可能如下：
1）用戶向智能體發(fā)送查詢。
2）智能體開始 ReAct 序列。
3）智能體向模型提供一個提示，要求它生成下一個 ReAct 步驟及其相應(yīng)輸出：
- 問題（Question）：來自用戶查詢的輸入問題，隨提示一起提供。
- 想法（Thought）：模型對下一步應(yīng)該做什么的思考。
- 行動（Action）：模型對下一步采取什么行動的決策。這是選擇工具的地方。例如，一個行動可以是 [航班、搜索、代碼、無] 中的一個，前三個代表模型可以選擇的已知工具，最后一個代表 “不選擇工具”。
- 行動輸入（Action input）：模型對為工具提供什么輸入的決策（如果有）。
- 觀察（Observation）：行動 / 行動輸入序列的結(jié)果。根據(jù)需要，這個想法 / 行動 / 行動輸入 / 觀察可能會重復 N 次。
- 最終答案（Final answer）：模型對原始用戶查詢提供的最終答案。
4）ReAct 循環(huán)結(jié)束，最終答案被返回給用戶。
如上圖 所示，模型、工具和智能體協(xié)同工作，根據(jù)用戶的原始查詢，為用戶提供有依據(jù)的、簡潔的回復。模型使用了一個工具（航班工具）來搜索實時外部信息。這些額外信息被提供給模型，使其能夠根據(jù)真實數(shù)據(jù)做出更明智的決策，并將這些信息總結(jié)后返回給用戶。
二、工具：連接外部世界的鑰匙
雖然語言模型在處理信息方面表現(xiàn)出色，但它們?nèi)狈χ苯痈兄陀绊懍F(xiàn)實世界的能力。這限制了它們在需要與外部系統(tǒng)或數(shù)據(jù)交互的情況下的實用性。從某種意義上說，這意味著語言模型的能力僅限于它從訓練數(shù)據(jù)中學到的內(nèi)容。但是，無論我們?yōu)槟Ｐ吞峁┒嗌贁?shù)據(jù)，它們?nèi)匀蝗狈εc外部世界交互的基本能力。那么，我們?nèi)绾问刮覀兊哪Ｐ湍軌蚺c外部系統(tǒng)進行實時的、上下文感知的交互呢？函數(shù)（Functions）、擴展（Extensions）、數(shù)據(jù)存儲（Data Stores）和插件（Plugins）都是為模型提供這一關(guān)鍵能力的方式。
擴展Extensions
理解擴展的最簡單方法是將其視為以標準化方式在 API 和智能體之間架起橋梁，使智能體能夠無縫執(zhí)行 API，而無需考慮其底層實現(xiàn)。假設(shè)你構(gòu)建了一個智能體，目標是幫助用戶預訂航班。你知道你想使用谷歌航班 API 來檢索航班信息，但你不確定如何讓你的智能體調(diào)用這個 API 端點。
一種方法可能是實現(xiàn)自定義代碼，該代碼獲取傳入的用戶查詢，解析查詢以獲取相關(guān)信息，然后進行 API 調(diào)用。例如，在航班預訂用例中，用戶可能會說 “我想預訂從奧斯汀到蘇黎世的航班”。在這種情況下，我們的自定義代碼解決方案需要從用戶查詢中提取 “奧斯汀” 和 “蘇黎世” 作為相關(guān)實體，然后才能嘗試進行 API 調(diào)用。但是，如果用戶說 “我想預訂去蘇黎世的航班”，卻沒有提供出發(fā)城市，會發(fā)生什么情況呢？如果沒有所需的數(shù)據(jù)，API 調(diào)用將失敗，并且需要實現(xiàn)更多代碼來處理此類邊緣和極端情況。這種方法缺乏可擴展性，并且在任何超出已實現(xiàn)的自定義代碼范圍的場景中都很容易出錯。
一種更具彈性的方法是使用擴展。擴展通過以下方式在智能體和 API 之間架起橋梁：
- 使用示例教導智能體如何使用 API 端點。
- 教導智能體成功調(diào)用 API 端點所需的參數(shù)。
擴展可以獨立于智能體進行構(gòu)建，但應(yīng)作為智能體配置的一部分提供。智能體在運行時使用模型和示例來決定哪個擴展（如果有的話）適合解決用戶的查詢。這突出了擴展的一個關(guān)鍵優(yōu)勢，即其內(nèi)置的示例類型，使智能體能夠動態(tài)地為任務(wù)選擇最合適的擴展。
函數(shù)Functions
在軟件工程領(lǐng)域，函數(shù)被定義為自包含的代碼模塊，用于完成特定任務(wù)，并且可根據(jù)需要重復使用。軟件開發(fā)人員在編寫程序時，通常會創(chuàng)建多個函數(shù)來執(zhí)行不同的任務(wù)。他們還會定義何時調(diào)用函數(shù) a 而非函數(shù) b 的邏輯，以及預期的輸入和輸出。
不過我們可以用模型來替代軟件開發(fā)人員。模型可以獲取一組已知的函數(shù)，并根據(jù)其規(guī)格說明來決定何時使用每個函數(shù)，以及該函數(shù)需要哪些參數(shù)。函數(shù)與擴展有幾個方面的不同，最顯著的是：
- 模型輸出一個函數(shù)及其參數(shù)，但不會進行實時 API 調(diào)用。
- 函數(shù)在客戶端執(zhí)行，而擴展在智能體端執(zhí)行。
再次以谷歌航班為例，一個簡單的函數(shù)設(shè)置可能如圖 7 中的示例所示。
請注意，這里的主要區(qū)別在于，無論是函數(shù)還是智能體都不會直接與谷歌航班 API 進行交互。那么，API 調(diào)用實際是如何發(fā)生的呢？
對于函數(shù)而言，調(diào)用實際 API 端點的邏輯和執(zhí)行操作從智能體轉(zhuǎn)移到了客戶端應(yīng)用程序，如上面的圖 8 和下面的圖 9 所示。這使開發(fā)人員能夠更精細地控制應(yīng)用程序中的數(shù)據(jù)流向。開發(fā)人員可能選擇使用函數(shù)而非擴展，原因有很多，常見的幾種應(yīng)用場景如下：
- API 調(diào)用需要在應(yīng)用程序堆棧的另一層進行，而不是在智能體架構(gòu)的直接流程內(nèi)（例如，在中間件系統(tǒng)、前端框架等中）。
- 安全或認證限制阻止智能體直接調(diào)用 API（例如，API 未暴露到互聯(lián)網(wǎng)，或者智能體基礎(chǔ)設(shè)施無法訪問）。
時間或操作順序限制導致智能體無法實時進行 API 調(diào)用（即批量操作、人工介入審核等 ） 。
Function Call
https://mp.weixin.qq.com/s/lVqdBxYmA9EfSNQ2M7n4DA（來源）
本小節(jié)摘抄自《那么多接入DeepSeek的，終于有一家支持 Function Call 了！?。 ?，進一步理解Agent如何進行函數(shù)調(diào)用。
字節(jié)率先將 DeepSeek 支持了 Function Call（2025年02月）。現(xiàn)在，模型會自己思考判斷是否該調(diào)用插件，該調(diào)用哪個插件。
Function Call 本質(zhì)上是讓 LLM 成為一個更智能的“操作員”，通過標準化的接口來調(diào)用外部工具和服務(wù)，從而擴展其能力邊界。那么大模型是怎么實現(xiàn) Function Call 的呢，其大概流程是這樣的：
- 用戶輸入；
- LLM 開始生成回應(yīng)，直到意識到需要工具調(diào)用時；
- 暫停原有 Token 生成，開始生成函數(shù)調(diào)用的參數(shù)；
- 外部系統(tǒng)截獲函數(shù)參數(shù)，執(zhí)行后返回結(jié)果；
- LLM 基于返回結(jié)果和前文，繼續(xù)生成完整回應(yīng)。
一些舉例
示例1：
模型可用于調(diào)用函數(shù)，以便為終端用戶處理復雜的客戶端執(zhí)行流程，在這種情況下，智能體開發(fā)者可能不希望語言模型來管理 API 的執(zhí)行（擴展的情況就是如此）。我們來看下面這個例子，一個智能體被訓練成旅行助手，與想要預訂度假旅行的用戶進行交互。目標是讓智能體生成一份城市列表，用于中間件應(yīng)用程序為用戶的旅行規(guī)劃下載圖片、數(shù)據(jù)等。用戶可能會這樣說：
“我想和家人去滑雪旅行，但不確定該去哪里?！?/p>
在向模型發(fā)送的典型提示中，輸出可能如下：
當然，以下是一些你可以考慮的適合家庭滑雪旅行的城市：
- 美國科羅拉多州的克雷斯特德比特
- 加拿大不列顛哥倫比亞省的惠斯勒
- 瑞士的采爾馬特
雖然上述輸出包含了我們需要的數(shù)據(jù)（城市名稱），但其格式并不適合解析。通過函數(shù)調(diào)用，我們可以訓練模型以結(jié)構(gòu)化的格式（如 JSON）輸出數(shù)據(jù)，這樣更便于其他系統(tǒng)進行解析。對于用戶給出的相同輸入提示，函數(shù)輸出的一個 JSON 示例可能如代碼片段 5 所示。
這個 JSON 由模型生成，然后被發(fā)送到我們的客戶端服務(wù)器，以便我們對其進行任何想要的處理。在這個特定的例子中，我們將調(diào)用谷歌地圖地點 API（Google Places API ），使用模型提供的城市信息來查找相關(guān)圖片，然后將這些圖片以格式化的豐富內(nèi)容形式返回給用戶。參考圖 9 中的序列圖，它詳細地逐步展示了上述交互過程。
圖 9 中示例的結(jié)果是，模型被用來 “填空”，提供客戶端用戶界面（UI）調(diào)用谷歌地圖地點 API 所需的參數(shù)?？蛻舳?UI 使用模型在返回的函數(shù)中提供的參數(shù)來管理實際的 API 調(diào)用。
用戶輸入了一個query給客戶端UI，客戶端調(diào)用Agent，Agent將prompt給到LLM，LLM生成了JSON格式的輸出（包括了需要調(diào)用的函數(shù)名及其需要的參數(shù)），JSON格式輸出被返回給客戶端，客戶端進行API call去調(diào)用該API，API返回的結(jié)果給到客戶端，得到最終的響應(yīng)。
關(guān)于函數(shù)，有一個關(guān)鍵要點需要記?。汉瘮?shù)不僅旨在讓開發(fā)者能更好地控制 API 調(diào)用的執(zhí)行過程，還能更好地掌控整個應(yīng)用程序中的數(shù)據(jù)流動。在圖 9 的示例中，開發(fā)者選擇不將 API 信息返回給智能體，因為這些信息與智能體后續(xù)可能采取的行動無關(guān)。然而，根據(jù)應(yīng)用程序的架構(gòu)，將外部 API 調(diào)用數(shù)據(jù)返回給智能體，以便影響其未來的推理、邏輯判斷和行動選擇，也可能是合理的做法。歸根結(jié)底，對于特定的應(yīng)用程序而言，怎樣做才合適，決定權(quán)在應(yīng)用開發(fā)者手中。
小結(jié)
本篇介紹了什么是Agent（包含模型、工具、編排、如何運作）、工具篇的擴展和函數(shù)部分。下一篇將介紹工具篇的數(shù)據(jù)存儲及總結(jié)、模型、為什么Agent沒有爆發(fā)。
本文由 @「愛」原生 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可，禁止轉(zhuǎn)載
題圖來自Unsplash，基于CC0協(xié)議
更多精彩內(nèi)容，請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
通過對比Agent與傳統(tǒng)模型及工作流的差異，揭示了智能體在靈活性和效率上的優(yōu)勢。無論是AI新手還是資深產(chǎn)品經(jīng)理，本文都能幫助你快速掌握Agent的關(guān)鍵要點，為打造智能產(chǎn)品提供實用指導。
本人也在AI agent領(lǐng)域浮沉了一段時間了，落地過幾個Agent架構(gòu)的產(chǎn)品，對Agent的認識逐漸清晰具象。當首次看到Google的Agent白皮書時（https://www.kaggle.com/whitepaper-agents），不覺間竟坐在咖啡廳里一口氣讀完了。期間不斷贊嘆你歌還是你歌，清晰易懂且專業(yè)。大概也是因為真正去做過Agent的產(chǎn)品，平時也有很多深度思考，所以我認為這篇Agent真的非常必讀。因此，想以谷歌白皮書（自己手動機翻）的中文版作為主線，并穿插一些我個人積累的Agent的關(guān)鍵點和前沿觀點，整理成一篇適合AI產(chǎn)品經(jīng)理讀的Agent文章。
由于篇幅太長，分為了上下兩篇：
第一篇：引言——什么是智能體、工具篇上
第二篇：工具篇下、模型性能提升、產(chǎn)品經(jīng)理視角的洞見與警示
一、引言——什么是智能體
人類在復雜的模式識別任務(wù)中表現(xiàn)卓越，但通常需要借助工具（如書籍、搜索引擎或計算器）來補充先驗知識以得出結(jié)論。同理，生成式AI模型可通過訓練使用工具獲取實時信息或建議的實際動作。例如：
- 模型可利用數(shù)據(jù)庫檢索工具獲取客戶購買歷史以生成個性化購物推薦
- 基于用戶查詢，模型可通過API調(diào)用發(fā)送郵件或完成金融交易
為實現(xiàn)此能力，模型需具備：
- 外部工具集訪問權(quán)限
- 自主規(guī)劃與執(zhí)行任務(wù)的推理能力
這種結(jié)合推理邏輯與外部信息訪問的系統(tǒng)，即構(gòu)成智能體（Agent）。
生成式人工智能智能體可以被定義為一種應(yīng)用程序，它試圖通過觀察世界，并利用其可用的工具對世界采取行動來實現(xiàn)目標。智能體具有自主性，可以在無需人類干預的情況下獨立行動，尤其是在被賦予了它們應(yīng)該實現(xiàn)的適當目標時。智能體在實現(xiàn)目標的過程中也可以積極主動。即使在沒有人類明確指令集的情況下，智能體也能推理出接下來應(yīng)該采取什么行動來實現(xiàn)其最終目標。
為了理解智能體的內(nèi)部工作原理，我們先來介紹驅(qū)動智能體行為（behavior）、行動（action）和決策（decision making）的基礎(chǔ)組件。這些組件的組合可以被描述為一種認知架構(gòu)，通過對這些組件的混合和匹配，可以實現(xiàn)多種這樣的架構(gòu)。從核心功能來看，如圖 1 所示，智能體的認知架構(gòu)中有三個基本組件：模型（Model）、工具（Tools）和編排（Orchestration）。
模型
在智能體的范疇內(nèi)，模型指的是語言模型（LM），它將作為智能體流程的核心決策器。智能體使用的模型可以是一個或多個任意規(guī)模（小型 / 大型）的語言模型，這些模型能夠遵循基于指令的推理和邏輯框架，如ReAct、思維鏈（Chain-of-Thought）或思維樹（Tree-of-Thoughts）。模型可以是通用的、多模態(tài)的，也可以根據(jù)特定智能體架構(gòu)的需求進行微調(diào)。為了在生產(chǎn)中獲得最佳效果，你應(yīng)該選擇最適合你期望的最終應(yīng)用的模型，理想情況下，該模型應(yīng)在與你計劃在認知架構(gòu)中使用的工具相關(guān)的數(shù)據(jù)特征上進行過訓練。需要注意的是，模型通常不會使用智能體的特定配置設(shè)置（即工具選擇、編排 / 推理設(shè)置）進行訓練。不過，通過向模型提供展示智能體能力的示例，包括智能體在各種場景中使用特定工具或推理步驟的實例，就有可能進一步優(yōu)化模型以適應(yīng)智能體的任務(wù)。
工具
基礎(chǔ)模型盡管在文本和圖像生成方面表現(xiàn)出色，但仍然受到無法與外部世界交互的限制。工具彌補了這一差距，使智能體能夠與外部數(shù)據(jù)和服務(wù)進行交互，解鎖了比基礎(chǔ)模型本身更廣泛的行動范圍。工具可以采用多種形式，復雜程度各不相同，但通常與常見的網(wǎng)絡(luò) API 方法（如 GET、POST、PATCH 和 DELETE）類似。例如，一個工具可以更新數(shù)據(jù)庫中的客戶信息，或者獲取天氣數(shù)據(jù)，以影響智能體為用戶提供的旅行建議。借助工具，智能體可以訪問和處理現(xiàn)實世界的信息。這使它們能夠支持更專業(yè)的系統(tǒng)，如檢索增強生成（RAG），顯著擴展了智能體的能力，超越了基礎(chǔ)模型單獨所能達到的水平。
編排層
編排層描述了一個循環(huán)過程，它控制智能體如何獲取信息、進行一些內(nèi)部推理，并利用這些推理來指導其下一個行動或決策。一般來說，這個循環(huán)會持續(xù)進行，直到智能體達到其目標或某個停止點。編排層的復雜程度因智能體及其執(zhí)行的任務(wù)而異。有些循環(huán)可能是簡單的帶有決策規(guī)則的計算，而其他循環(huán)可能包含鏈式邏輯，涉及額外的機器學習算法，或采用其他概率推理技術(shù)。我們將在認知架構(gòu)部分更詳細地討論智能體編排層的具體實現(xiàn)。
對比澄清一些易混淆的概念
Agents vs. 模型
Agent vs. Workflow
Anthropic將Agent系統(tǒng)劃分為兩類：
- 第一類是workflow。遵循預定義的工作流，編排LLM和工具，固定代碼路徑。
- Agent：此類Agent被定義為完全自主的系統(tǒng)，這些系統(tǒng)在較長時間內(nèi)獨立運行，可以動態(tài)地指導自身流程和工具使用的系統(tǒng)。通過自身的推理、規(guī)劃能力，自主控制，完成任務(wù)。
工作流為定義明確的任務(wù)提供可預測性和一致性，而當需要大規(guī)模的靈活性和模型驅(qū)動的決策時，Agent是更好的選擇。但是，Agent系統(tǒng)通常會以延遲和成本為代價來獲得更好的任務(wù)性能，在生產(chǎn)環(huán)境中應(yīng)該考慮何時進行這種權(quán)衡。
認知架構(gòu)：智能體如何運作
智能體可以通過認知架構(gòu)，迭代地處理信息、做出明智的決策，并根據(jù)先前的輸出優(yōu)化后續(xù)行動，以實現(xiàn)其最終目標。智能體認知架構(gòu)的核心是編排層，它負責維護記憶、狀態(tài)、推理和規(guī)劃。它利用快速發(fā)展的提示工程領(lǐng)域及相關(guān)框架來指導推理和規(guī)劃，使智能體能夠更有效地與環(huán)境交互并完成任務(wù)。語言模型的提示工程框架和任務(wù)規(guī)劃領(lǐng)域的研究正在迅速發(fā)展，產(chǎn)生了多種有前景的方法。以下是當下一些最受歡迎的框架和推理技術(shù)：
- ReAct是一種提示工程框架，它為語言模型提供了一種思維過程策略，使其能夠針對用戶查詢進行推理并采取行動，無論是否有上下文示例。ReAct 提示已被證明優(yōu)于多個當前最優(yōu)（SOTA）基線，并提高了大語言模型（LLMs）與人類的交互性和可信度。
- 思維鏈（Chain-of-Thought，CoT）是一種提示工程框架，它通過中間步驟實現(xiàn)推理能力。思維鏈有各種子技術(shù)，包括自一致性、主動提示和多模態(tài)思維鏈，每種技術(shù)根據(jù)具體應(yīng)用都有其優(yōu)缺點。
- 思維樹（Tree-of-thoughts，ToT）是一種提示工程框架，適用于探索或戰(zhàn)略前瞻性任務(wù)。它是對思維鏈提示的擴展，允許模型探索各種思維鏈，這些思維鏈可作為使用語言模型解決一般問題的中間步驟。
智能體可以使用上述推理技術(shù)為給定的用戶請求選擇下一個最佳行動。例如，我們考慮一個被編程為使用 ReAct 框架為用戶查詢選擇正確行動和工具的智能體。事件序列可能如下：
1）用戶向智能體發(fā)送查詢。
2）智能體開始 ReAct 序列。
3）智能體向模型提供一個提示，要求它生成下一個 ReAct 步驟及其相應(yīng)輸出：
- 問題（Question）：來自用戶查詢的輸入問題，隨提示一起提供。
- 想法（Thought）：模型對下一步應(yīng)該做什么的思考。
- 行動（Action）：模型對下一步采取什么行動的決策。這是選擇工具的地方。例如，一個行動可以是 [航班、搜索、代碼、無] 中的一個，前三個代表模型可以選擇的已知工具，最后一個代表 “不選擇工具”。
- 行動輸入（Action input）：模型對為工具提供什么輸入的決策（如果有）。
- 觀察（Observation）：行動 / 行動輸入序列的結(jié)果。根據(jù)需要，這個想法 / 行動 / 行動輸入 / 觀察可能會重復 N 次。
- 最終答案（Final answer）：模型對原始用戶查詢提供的最終答案。
4）ReAct 循環(huán)結(jié)束，最終答案被返回給用戶。
如上圖 所示，模型、工具和智能體協(xié)同工作，根據(jù)用戶的原始查詢，為用戶提供有依據(jù)的、簡潔的回復。模型使用了一個工具（航班工具）來搜索實時外部信息。這些額外信息被提供給模型，使其能夠根據(jù)真實數(shù)據(jù)做出更明智的決策，并將這些信息總結(jié)后返回給用戶。
二、工具：連接外部世界的鑰匙
雖然語言模型在處理信息方面表現(xiàn)出色，但它們?nèi)狈χ苯痈兄陀绊懍F(xiàn)實世界的能力。這限制了它們在需要與外部系統(tǒng)或數(shù)據(jù)交互的情況下的實用性。從某種意義上說，這意味著語言模型的能力僅限于它從訓練數(shù)據(jù)中學到的內(nèi)容。但是，無論我們?yōu)槟Ｐ吞峁┒嗌贁?shù)據(jù)，它們?nèi)匀蝗狈εc外部世界交互的基本能力。那么，我們?nèi)绾问刮覀兊哪Ｐ湍軌蚺c外部系統(tǒng)進行實時的、上下文感知的交互呢？函數(shù)（Functions）、擴展（Extensions）、數(shù)據(jù)存儲（Data Stores）和插件（Plugins）都是為模型提供這一關(guān)鍵能力的方式。
擴展Extensions
理解擴展的最簡單方法是將其視為以標準化方式在 API 和智能體之間架起橋梁，使智能體能夠無縫執(zhí)行 API，而無需考慮其底層實現(xiàn)。假設(shè)你構(gòu)建了一個智能體，目標是幫助用戶預訂航班。你知道你想使用谷歌航班 API 來檢索航班信息，但你不確定如何讓你的智能體調(diào)用這個 API 端點。
一種方法可能是實現(xiàn)自定義代碼，該代碼獲取傳入的用戶查詢，解析查詢以獲取相關(guān)信息，然后進行 API 調(diào)用。例如，在航班預訂用例中，用戶可能會說 “我想預訂從奧斯汀到蘇黎世的航班”。在這種情況下，我們的自定義代碼解決方案需要從用戶查詢中提取 “奧斯汀” 和 “蘇黎世” 作為相關(guān)實體，然后才能嘗試進行 API 調(diào)用。但是，如果用戶說 “我想預訂去蘇黎世的航班”，卻沒有提供出發(fā)城市，會發(fā)生什么情況呢？如果沒有所需的數(shù)據(jù)，API 調(diào)用將失敗，并且需要實現(xiàn)更多代碼來處理此類邊緣和極端情況。這種方法缺乏可擴展性，并且在任何超出已實現(xiàn)的自定義代碼范圍的場景中都很容易出錯。
一種更具彈性的方法是使用擴展。擴展通過以下方式在智能體和 API 之間架起橋梁：
- 使用示例教導智能體如何使用 API 端點。
- 教導智能體成功調(diào)用 API 端點所需的參數(shù)。
擴展可以獨立于智能體進行構(gòu)建，但應(yīng)作為智能體配置的一部分提供。智能體在運行時使用模型和示例來決定哪個擴展（如果有的話）適合解決用戶的查詢。這突出了擴展的一個關(guān)鍵優(yōu)勢，即其內(nèi)置的示例類型，使智能體能夠動態(tài)地為任務(wù)選擇最合適的擴展。
函數(shù)Functions
在軟件工程領(lǐng)域，函數(shù)被定義為自包含的代碼模塊，用于完成特定任務(wù)，并且可根據(jù)需要重復使用。軟件開發(fā)人員在編寫程序時，通常會創(chuàng)建多個函數(shù)來執(zhí)行不同的任務(wù)。他們還會定義何時調(diào)用函數(shù) a 而非函數(shù) b 的邏輯，以及預期的輸入和輸出。
不過我們可以用模型來替代軟件開發(fā)人員。模型可以獲取一組已知的函數(shù)，并根據(jù)其規(guī)格說明來決定何時使用每個函數(shù)，以及該函數(shù)需要哪些參數(shù)。函數(shù)與擴展有幾個方面的不同，最顯著的是：
- 模型輸出一個函數(shù)及其參數(shù)，但不會進行實時 API 調(diào)用。
- 函數(shù)在客戶端執(zhí)行，而擴展在智能體端執(zhí)行。
再次以谷歌航班為例，一個簡單的函數(shù)設(shè)置可能如圖 7 中的示例所示。
請注意，這里的主要區(qū)別在于，無論是函數(shù)還是智能體都不會直接與谷歌航班 API 進行交互。那么，API 調(diào)用實際是如何發(fā)生的呢？
對于函數(shù)而言，調(diào)用實際 API 端點的邏輯和執(zhí)行操作從智能體轉(zhuǎn)移到了客戶端應(yīng)用程序，如上面的圖 8 和下面的圖 9 所示。這使開發(fā)人員能夠更精細地控制應(yīng)用程序中的數(shù)據(jù)流向。開發(fā)人員可能選擇使用函數(shù)而非擴展，原因有很多，常見的幾種應(yīng)用場景如下：
- API 調(diào)用需要在應(yīng)用程序堆棧的另一層進行，而不是在智能體架構(gòu)的直接流程內(nèi)（例如，在中間件系統(tǒng)、前端框架等中）。
- 安全或認證限制阻止智能體直接調(diào)用 API（例如，API 未暴露到互聯(lián)網(wǎng)，或者智能體基礎(chǔ)設(shè)施無法訪問）。
時間或操作順序限制導致智能體無法實時進行 API 調(diào)用（即批量操作、人工介入審核等 ） 。
Function Call
https://mp.weixin.qq.com/s/lVqdBxYmA9EfSNQ2M7n4DA（來源）
本小節(jié)摘抄自《那么多接入DeepSeek的，終于有一家支持 Function Call 了！?。 ?，進一步理解Agent如何進行函數(shù)調(diào)用。
字節(jié)率先將 DeepSeek 支持了 Function Call（2025年02月）。現(xiàn)在，模型會自己思考判斷是否該調(diào)用插件，該調(diào)用哪個插件。
Function Call 本質(zhì)上是讓 LLM 成為一個更智能的“操作員”，通過標準化的接口來調(diào)用外部工具和服務(wù)，從而擴展其能力邊界。那么大模型是怎么實現(xiàn) Function Call 的呢，其大概流程是這樣的：
- 用戶輸入；
- LLM 開始生成回應(yīng)，直到意識到需要工具調(diào)用時；
- 暫停原有 Token 生成，開始生成函數(shù)調(diào)用的參數(shù)；
- 外部系統(tǒng)截獲函數(shù)參數(shù)，執(zhí)行后返回結(jié)果；
- LLM 基于返回結(jié)果和前文，繼續(xù)生成完整回應(yīng)。
一些舉例
示例1：
模型可用于調(diào)用函數(shù)，以便為終端用戶處理復雜的客戶端執(zhí)行流程，在這種情況下，智能體開發(fā)者可能不希望語言模型來管理 API 的執(zhí)行（擴展的情況就是如此）。我們來看下面這個例子，一個智能體被訓練成旅行助手，與想要預訂度假旅行的用戶進行交互。目標是讓智能體生成一份城市列表，用于中間件應(yīng)用程序為用戶的旅行規(guī)劃下載圖片、數(shù)據(jù)等。用戶可能會這樣說：
“我想和家人去滑雪旅行，但不確定該去哪里?！?/p>
在向模型發(fā)送的典型提示中，輸出可能如下：
當然，以下是一些你可以考慮的適合家庭滑雪旅行的城市：
- 美國科羅拉多州的克雷斯特德比特
- 加拿大不列顛哥倫比亞省的惠斯勒
- 瑞士的采爾馬特
雖然上述輸出包含了我們需要的數(shù)據(jù)（城市名稱），但其格式并不適合解析。通過函數(shù)調(diào)用，我們可以訓練模型以結(jié)構(gòu)化的格式（如 JSON）輸出數(shù)據(jù)，這樣更便于其他系統(tǒng)進行解析。對于用戶給出的相同輸入提示，函數(shù)輸出的一個 JSON 示例可能如代碼片段 5 所示。
這個 JSON 由模型生成，然后被發(fā)送到我們的客戶端服務(wù)器，以便我們對其進行任何想要的處理。在這個特定的例子中，我們將調(diào)用谷歌地圖地點 API（Google Places API ），使用模型提供的城市信息來查找相關(guān)圖片，然后將這些圖片以格式化的豐富內(nèi)容形式返回給用戶。參考圖 9 中的序列圖，它詳細地逐步展示了上述交互過程。
圖 9 中示例的結(jié)果是，模型被用來 “填空”，提供客戶端用戶界面（UI）調(diào)用谷歌地圖地點 API 所需的參數(shù)?？蛻舳?UI 使用模型在返回的函數(shù)中提供的參數(shù)來管理實際的 API 調(diào)用。
用戶輸入了一個query給客戶端UI，客戶端調(diào)用Agent，Agent將prompt給到LLM，LLM生成了JSON格式的輸出（包括了需要調(diào)用的函數(shù)名及其需要的參數(shù)），JSON格式輸出被返回給客戶端，客戶端進行API call去調(diào)用該API，API返回的結(jié)果給到客戶端，得到最終的響應(yīng)。
關(guān)于函數(shù)，有一個關(guān)鍵要點需要記?。汉瘮?shù)不僅旨在讓開發(fā)者能更好地控制 API 調(diào)用的執(zhí)行過程，還能更好地掌控整個應(yīng)用程序中的數(shù)據(jù)流動。在圖 9 的示例中，開發(fā)者選擇不將 API 信息返回給智能體，因為這些信息與智能體后續(xù)可能采取的行動無關(guān)。然而，根據(jù)應(yīng)用程序的架構(gòu)，將外部 API 調(diào)用數(shù)據(jù)返回給智能體，以便影響其未來的推理、邏輯判斷和行動選擇，也可能是合理的做法。歸根結(jié)底，對于特定的應(yīng)用程序而言，怎樣做才合適，決定權(quán)在應(yīng)用開發(fā)者手中。
小結(jié)
本篇介紹了什么是Agent（包含模型、工具、編排、如何運作）、工具篇的擴展和函數(shù)部分。下一篇將介紹工具篇的數(shù)據(jù)存儲及總結(jié)、模型、為什么Agent沒有爆發(fā)。
本文由 @「愛」原生 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可，禁止轉(zhuǎn)載
題圖來自Unsplash，基于CC0協(xié)議
- 目前還沒評論，等你發(fā)揮！
