smolagents 文件
什麼是 Agent？🤔
並獲得增強的文件體驗
開始使用
什麼是 Agent？🤔
Agentic 系統簡介。
任何使用 AI 的高效系統都需要為大型語言模型（LLM）提供某種與現實世界的連線：例如，調用搜索工具以獲取外部資訊，或對特定程式進行操作以解決任務。換句話說，LLM 應該擁有 **代理能力（agency）**。Agentic 程式是 LLM 連線外部世界的門戶。
AI Agent 是 **LLM 輸出控制工作流的程式**。
任何利用 LLM 的系統都會將 LLM 的輸出整合到程式碼中。LLM 輸入對程式碼工作流的影響程度就是 LLM 在系統中的代理能力水平。
請注意，根據這個定義，“Agent”並非一個離散的、0 或 1 的定義：相反，“代理能力”在一個連續的譜系上演變，取決於你賦予 LLM 對你的工作流多少權力。
請看下錶，瞭解代理能力在不同系統中如何變化
| 代理能力等級 | 描述 | 簡稱 | 程式碼示例 |
|---|---|---|---|
| ☆☆☆ | LLM 輸出對程式流沒有影響 | 簡單處理器 | process_llm_output(llm_response) |
| ★☆☆ | LLM 輸出控制 if/else 開關 | 路由器 | if llm_decision(): path_a() else: path_b() |
| ★★☆ | LLM 輸出控制函式執行 | 工具呼叫 | run_function(llm_chosen_tool, llm_chosen_args) |
| ★★☆ | LLM 輸出控制迭代和程式繼續執行 | 多步智慧體 | while llm_should_continue(): execute_next_step() |
| ★★★ | 一個代理工作流可以啟動另一個代理工作流 | 多智慧體 | if llm_trigger(): execute_agent() |
| ★★★ | LLM 在程式碼中操作，可以定義自己的工具 / 啟動其他 Agent | 程式碼 Agent | def custom_tool(args): ... |
多步 Agent 具有這種程式碼結構
memory = [user_defined_task]
while llm_should_continue(memory): # this loop is the multi-step part
action = llm_get_next_action(memory) # this is the tool-calling part
observations = execute_action(action)
memory += [action, observations]這個 Agentic 系統在一個迴圈中執行，每一步執行一個新的動作（該動作可以涉及呼叫一些預定義的**工具**，這些工具只是函式），直到其觀察結果表明已達到令人滿意的狀態以解決給定任務。這是一個多步 Agent 如何解決一個簡單數學問題的示例
✅ 何時使用 Agent / ⛔ 何時避免使用 Agent
當你需要 LLM 決定應用程式的工作流時，Agent 會很有用。但它們通常是殺雞用牛刀。問題是：我真的需要工作流的靈活性才能有效解決手頭的任務嗎？如果預定工作流經常力不從心，那意味著你需要更多的靈活性。舉個例子：假設你正在開發一個處理衝浪旅行網站客戶請求的應用程式。
你可能事先知道請求將屬於兩個類別中的一個（根據使用者選擇），並且你為這兩種情況都預定義了工作流。
- 想了解旅行資訊？⇒ 讓他們訪問搜尋欄來搜尋你的知識庫
- 想與銷售交談？⇒ 讓他們填寫聯絡表格。
如果這種確定性工作流適合所有查詢，那麼儘管放心地將所有內容編碼！這將為你提供一個 100% 可靠的系統，沒有任何因讓不可預測的 LLM 干預你的工作流而引入錯誤的風險。為了簡潔和健壯性，建議儘量不使用任何 Agentic 行為。
但是，如果工作流無法事先確定得那麼好呢？
例如，使用者想問：“我週一能來，但我忘了護照，所以可能會延遲到週三，週二早上可以帶我和我的東西去衝浪嗎，有取消保險嗎？”這個問題取決於許多因素，上面預先確定的標準可能都不足以滿足這個請求。
如果預設的工作流經常無法滿足需求，那意味著你需要更大的靈活性。
這時，Agentic 設定就派上用場了。
在上面的例子中，你可以簡單地建立一個多步 Agent，它能夠訪問天氣 API 獲取天氣預報、Google Maps API 計算出行距離、員工可用性儀表板以及你的知識庫上的 RAG 系統。
直到最近，計算機程式還受限於預設的工作流程，透過堆疊 if/else 開關來處理複雜性。它們專注於極其狹窄的任務，例如“計算這些數字的總和”或“找出圖中最短路徑”。但實際上，大多數現實生活中的任務，比如我們上面提到的旅行示例，都不符合預設的工作流程。Agentic 系統為程式打開了廣闊的現實世界任務的大門！
為什麼選擇 smolagents？
對於一些低級別的 Agent 用例，例如鏈或路由器，你可以自己編寫所有程式碼。這樣做會更好，因為它可以讓你更好地控制和理解你的系統。
但是一旦你開始追求更復雜的行為，比如讓 LLM 呼叫函式（這就是“工具呼叫”）或者讓 LLM 執行 while 迴圈（“多步 Agent”），一些抽象就變得必要了。
- 對於工具呼叫，你需要解析 Agent 的輸出，所以這個輸出需要一個預定義的格式，比如“Thought: 我應該呼叫工具‘get_weather’。Action: get_weather(Paris).”，你用一個預定義的函式來解析它，並且給 LLM 的系統提示應該通知它這個格式。
- 對於 LLM 輸出決定迴圈的多步 Agent，你需要根據上次迴圈迭代中發生的事情給 LLM 不同的提示：所以你需要某種記憶體。
看到了嗎？透過這兩個例子，我們已經發現需要一些元素來幫助我們
- 當然，作為驅動系統的引擎的 LLM
- Agent 可以訪問的工具列表
- 一個系統提示，指導 LLM 的 Agent 邏輯：反射 -> 動作 -> 觀察的 ReAct 迴圈，可用的工具，要使用的工具呼叫格式…
- 一個解析器，用於從 LLM 輸出中提取工具呼叫，其格式由上面的系統提示指定。
- 記憶
但是等等，既然我們允許 LLM 做決策，它們肯定會犯錯誤：所以我們需要錯誤日誌記錄和重試機制。
所有這些元素都需要緊密耦合才能形成一個執行良好的系統。這就是為什麼我們決定需要構建基本模組，讓所有這些東西協同工作。
程式碼 Agent
在多步 Agent 中，LLM 在每個步驟中都可以編寫一個動作，形式是呼叫外部工具。編寫這些動作的常用格式（Anthropic、OpenAI 和許多其他公司使用）通常是“將動作寫成包含工具名稱和要使用的引數的 JSON，然後解析它以知道執行哪個工具以及使用哪些引數”的不同變體。
多篇 研究 論文 表明，將 LLM 的動作寫成程式碼片段是一種更自然、更靈活的編寫方式。
其原因很簡單：**我們設計程式語言就是為了表達計算機執行的動作**。換句話說，我們的 Agent 將編寫程式來解決使用者的問題：你認為它們用 Python 塊還是 JSON 來程式設計會更容易？
下圖取自可執行程式碼動作能更好地激發 LLM Agent，說明了用程式碼編寫動作的一些優點
用程式碼而非類似 JSON 的片段編寫動作，能提供更好的
- **可組合性：** 您可以將 JSON 操作相互巢狀，或者定義一組 JSON 操作供以後重用，就像您可以定義一個 Python 函式一樣嗎？
- **物件管理：** 如何在 JSON 中儲存
generate_image等操作的輸出？ - **通用性：** 程式碼旨在簡單地表達計算機可以做的任何事情。
- **LLM 訓練資料中的表示：** 大量高質量的程式碼操作已經包含在 LLM 的訓練資料中，這意味著它們已經為此做好了訓練！