決定 Agent 能力的兩個方面：工具和規劃。
人工智慧：一種現代方法 (1995) 將 Agent 定義為任何可以通過傳感器感知其環境並通過執行器作用於該環境的事物。
這意味著，一個 Agent 的特徵在於它所處的環境和它能執行的一系列行動。如果開發一個 Agent 來玩遊戲（例如，Minecraft、圍棋、Dota），那麼該遊戲就是它的環境。如果你希望 Agent 從互聯網上抓取文檔，那麼互聯網就是它的環境。自動駕駛汽車 Agent 的環境則是道路系統及其周邊區域。
AI Agent 能夠執行的一系列動作因其可訪問的工具而得到增強。ChatGPT 就是一個 Agent，它能夠搜索網頁、執行 Python 代碼以及生成圖像。RAG 系統也是 Agent —— 文本檢索器、圖像檢索器和 SQL 執行器是它們的工具。
Agent 的環境與其工具集之間存在強烈的依賴關係。 環境決定了 Agent 可能使用的工具。例如，如果環境是國際象棋遊戲，Agent 唯一可能的動作就是有效的棋步。然而，Agent 的工具清單限制了其可操作的環境。例如，如果機器人的唯一動作是游泳，那麼它將被限制在水環境中。
與非 Agent 用例相比，Agent 通常需要更強大的模型，原因有二：
- 复合错误：Agent 通常需要執行多個步驟來完成一項任務，隨著步驟數量的增加，整體準確性會下降。如果模型每步的準確率為 95%，經過 10 步後，準確率將降至 60%，而經過 100 步後，準確率僅為 0.6%。
- 更高風險：借助工具，Agent 能夠執行更具影響力的任務，但任何失敗都可能帶來更嚴重的後果。
每當我向一群人談論自主 AI Agent 時，總會有人提到自動駕駛汽車。“如果有人黑進汽車綁架你怎麼辦？” 雖然自動駕駛汽車的例子因其物理性而顯得直觀，但 AI 系統無需存在於物理世界也能造成傷害。
任何希望利用人工智慧的組織都需要認真對待安全與保障問題。然而，這並不意味著 AI 系統永遠不應被賦予在現實世界中行動的能力。如果我們能信任機器將我們送入太空，我希望有一天，安全措施將足以讓我們信任自主的 AI 系統。此外，人類也可能犯錯。就我個人而言，相比讓一個陌生人載我一程，我更信任自動駕駛汽車。
可以在同一個提示中將規劃與執行結合起來。例如，給模型一個提示，要求它逐步思考（如使用思維鏈提示），然後在一個提示中執行這些步驟。但如果模型制定了一個 1000 步的計劃，卻未能達成目標呢？在沒有監督的情況下，Agent 可能會運行這些步驟數小時，浪費時間和 API 調用費用，直到你意識到它毫無進展。
為避免無效執行，規劃應與執行解耦。需要要求 Agent 首先生成計劃，只有在計劃經過驗證後才執行。計劃可以通過啟發式方法進行驗證。例如，一個簡單的啟發式方法是排除包含無效操作的計劃。如果生成的計劃需要進行 Google 搜索，而代理無法訪問 Google 搜索，則該計劃無效。另一個簡單的啟發式方法可能是排除所有步驟超過 X 的計劃。
規劃系統現在包含三個組件：一個用於生成計劃，一個用於驗證計劃，另一個用於執行計劃。如果將每個組件視為一個 Agent，這可以被視為一個多 Agent 系統。由於大多數 Agent 工作流程足夠複雜，涉及多個組件，因此大多數 Agent 都是多 Agent 的。
解決一個任務通常涉及以下過程。需要注意的是，反思對 Agent 來說並非強制要求，但它將顯著提升 Agent 的表現。
- 計劃生成：制定完成此任務的計劃。計劃是一系列可管理的行動，因此此過程也稱為任務分解。
- 反思與糾錯：評估生成的計劃。如果計劃不佳，則生成一個新計劃。
- 執行：按照生成的計劃採取行動。這通常涉及調用特定函數。
- 反思與糾錯：在收到行動結果後，評估這些結果並確定目標是否已達成。識別並糾正錯誤。如果目標未完成，則制定新計劃。
將模型轉變為計劃生成器的最簡單方法是使用 Prompt 工程。假設創建一個 Agent 來幫助客戶了解 Kitty Vogue 的產品。該 Agent 提供了三個外部工具的訪問權限：按價格檢索產品、檢索熱門產品和檢索產品信息。以下是一個用於計劃生成的提示示例。此提示僅用於說明目的，實際生產中的提示可能更為複雜。
Propose a plan to solve the task. You have access to 5 actions:
* get_today_date()
* fetch_top_products(start_date, end_date, num_products)
* fetch_product_info(product_name)
* generate_query(task_history, tool_output)
* generate_response(query)
The plan must be a sequence of valid actions.
Examples
Task: "Tell me about Fruity Fedora"
Plan: [fetch_product_info, generate_query, generate_response]
Task: "What was the best selling product last week?"
Plan: [fetch_top_products, generate_query, generate_response]
Task: {USER INPUT}
Plan:
許多模型提供商為其模型提供工具使用功能，有效地將其模型轉變為 Agent，工具即函數。因此，調用工具通常被稱為函數調用。一般而言，函數調用的運作如下：
- 創建工具清單。聲明可能希望模型使用的所有工具。每個工具由其執行入口點（例如，其函數名稱）、參數及其文檔（例如，函數的功能及其所需參數）描述。
- 指定 Agent 可用於查詢的工具。由於不同的查詢可能需要不同的工具，許多 API 允許為每個查詢指定要使用的已聲明工具列表。
例如，給定用戶查詢 “40 磅等於多少公斤？”，代理可能會決定需要使用工具 lbs_to_kg_tool，並傳入參數值 40。代理的響應可能如下所示。
response = ModelResponse(
finish_reason='tool_calls',
message=chat.Message(
content=None,
role='assistant',
tool_calls=[
ToolCall(
function=Function(
arguments=**'{"lbs":40}'**,
name='lbs_to_kg'),
type='function')
])
)
計劃是概述完成任務所需步驟的路線圖。路線圖可以有不同的粒度級別。為一年做計劃時，季度計劃比月度計劃更高層次，而月度計劃又比周計劃更高層次。
詳細的計劃更難制定，但更易於執行；而較高層次的計劃則更易制定，卻執行起來更具挑戰。一種規避此權衡的方法是採用分層規劃。首先，利用規劃器生成高層次計劃，如季度計劃。隨後，針對每個季度，使用相同或不同的規劃器進一步細化出月度計劃。
使用更自然的語言有助於計劃生成器對工具 API 的變化具有更強的適應性。如果模型主要是在自然語言上訓練的，那麼它很可能更擅長理解和生成自然語言計劃，並且不太可能出現幻覺。
這種方法的缺點是需要一個翻譯器將每個自然語言動作翻譯成可執行的命令。Chameleon（Lu 等，2023）將這個翻譯器稱為程序生成器。然而，翻譯比規劃簡單得多，可以由較弱的模型完成，且幻覺風險較低。
控制流包括順序、並行、if 語句和 for 循環。在評估 Agent 框架時，檢查其支持的控制流程。 例如，如果系統需要瀏覽十個網站，它能否同時進行？並行執行可以顯著減少用戶感知的延遲。
即使是最好的計劃也需要不斷評估和調整，以最大限度地提高成功的可能性。雖然反思並非 Agent 運作的嚴格必要條件，但它是 Agent 取得成功所必需的。
反思和糾錯是兩種相輔相成的機制。反思產生洞察，有助於發現需要糾正的錯誤。 反思可以通過同一 Agent 使用自我批評提示來完成。也可以通過一個單獨的組件來完成，例如一個專門的評分器：一個為每個結果輸出具體分數的模型。
ReAct（Yao 等人，2022 年）提出交錯推理與行動已成為智能體的常見模式。Yao 等人使用 “推理” 一詞來涵蓋規劃與反思。在每一步中，智能體被要求解釋其思考（規劃），採取行動，然後分析觀察結果（反思），直到智能體認為任務完成。
可以在多智能體環境中實現反思機制：一個智能體負責規劃並執行行動，而另一個智能體則在每一步或若干步之後評估結果。如果 Agent 的響應未能完成任務，您可以提示 Agent 反思失敗的原因及改進方法。基於此建議，Agent 生成新的計劃。這使得 Agent 能夠從錯誤中學習。
在 Reflexion 框架中，反思被分為兩個模塊：一個評估結果的分析器和一個分析出錯原因的自省模塊。使用術語 “trajectory（軌跡）” 來指代計劃。在每一步驟後，經過評估與自我反思，Agent 會提出新的軌跡。
與計劃生成相比，反思相對容易實現，並能帶來令人驚訝的性能提升。這種方法的缺點是延遲和成本。思考、觀察，有時甚至是行動，可能需要生成大量的 token，這增加了成本和用戶感知的延遲，特別是對於具有許多中間步驟的任務。為了促使他們的 Agent 遵循格式，ReAct 和 Reflexion 的作者在他們的提示中使用了大量的示例。這增加了計算輸入 token 的成本，並減少了可用於其他信息的上下文空間。
更多工具將賦予 Agent 更多能力。然而，工具越多，高效使用它們的難度就越大。 這類似於人類掌握大量工具的難度增加。添加工具還意味著增加工具描述，這可能無法適應模型的上下文。
與構建 AI 應用程序時的許多其他決策一樣，工具選擇也需要實驗和分析。以下是一些可以幫助你做出決定的事項：
- 比較 Agent 在不同工具集下的表現；
- 進行消融研究，看看如果移除某種工具，Agent 的性能會下降多少。如果可以在不降低性能的情況下移除工具，就移除它；
- 尋找 Agent 經常出錯的工具。如果某個工具對 Agent 來說太難使用，例如，大量的提示甚至微調都無法讓模型學會使用它，那就更換工具；
- 繪製工具調用分佈圖，以查看哪些工具使用最多，哪些工具使用最少；
不同模型和任務表現出不同的工具使用模式。不同的任務需要不同的工具。ScienceQA（科學問答任務）比 TabMWP（表格數學問題解決任務）更依賴於知識檢索工具。不同模型有不同的工具偏好。例如，GPT-4 似乎比 ChatGPT 選擇了更廣泛的工具集。ChatGPT 似乎更傾向於圖像描述，而 GPT-4 則更傾向於知識檢索。
規劃是困難的，且可能以多種方式失敗。最常見的規劃失敗模式是工具使用失敗。Agent 可能會生成包含以下一個或多個錯誤的計劃。
- 無效工具
例如，它生成了一個包含bing_search的計劃，而該工具不在工具清單中。 - 有效工具，無效參數。
例如，它調用lbs_to_kg時傳入了兩個參數，但該函數僅需要一個參數lbs。 - 有效工具，參數值不正確。
例如，它調用lbs_to_kg時使用了一個參數lbs，但在應該使用 120 時卻使用了值 100 來表示磅。
另一種規劃失敗的模式是目標失敗：Agent 未能實現目標。這可能是因為計劃未能解決任務，或者雖然解決了任務但未遵循約束條件。舉例來說，假設你要求模型規劃一次從舊金山到印度的兩周旅行，預算為 5000 美元。Agent 可能會規劃一次從舊金山到越南的旅行，或者為你規劃一次從舊金山到印度的兩周旅行，但費用遠超預算。
在 Agent 評估中，一個常被忽視的常見約束是時間。在許多情況下，Agent 完成任務所需的時間並不那麼重要，因為可以將任務分配給 Agent，只需在完成後檢查即可。然而，在許多情況下，隨著時間的推移，Agent 的作用會降低。例如，如果你要求 Agent 準備一份資助提案，而 Agent 在資助截止日期後才完成，那麼 Agent 的幫助就不大了。
Agent 可能使用正確的工具生成一個有效的計劃來完成任務，但可能效率不高。以下是可能希望跟蹤以評估 Agent 效率的幾個方面：
- Agent 平均需要多少步驟來完成一個任務？
- Agent 完成任務的平均成本是多少？
- 每個操作通常需要多長時間？是否有特別耗時或昂貴的操作？
可以將這些指標與你的基線進行比較，基線可以是另一個 Agent 或人類。在將 AI Agent 與人類進行比較時，請記住人類和 AI 的操作模式截然不同，因此對人類來說高效的行為可能對 AI 來說是低效的，反之亦然。例如，訪問 100 個網頁對於一次只能訪問一個頁面的人類來說可能是低效的，但對於可以同時訪問所有網頁的 AI Agent 來說則是輕而易舉的。