實踐出真知：Agents 領域“一年打怪升級”的經驗分享原創精華

發布于 2024-8-5 10:09

瀏覽

0收藏

編者按：在你構建 AI Agents 時，是否曾遇到這些困擾：總是在簡單任務上出錯，從而讓你有時會懷疑自己的技術水平？面對客戶的需求，AI Agent 表現得像個“笨蛋”，無法準確理解和執行指令？隨著底層模型的更新，AI Agents 的性能不升反降，讓人手足無措？
這些問題不僅影響了 AI Agents 的性能，甚至可能導致項目延期、成本超支，甚至失去客戶的信任。在 AI 技術飛速??發展的今天，任何一個表現不佳的 Agents 都可能很快被市場淘汰。
今天我們分享的這篇文章將為各位提供來自一線 Agents 開發者的寶貴經驗。作者基于過去一年的實踐，總結了 7 條經驗教訓，包括重新認識 AI Agent 的推理能力、優化 Agent-Computer Interface (ACI)、選擇和適配底層模型、以及構建差異化的基礎設施等。對于正在或計劃構建 AI Agents 的開發者和企業而言，這篇文章提供了許多切實可行的操作建議和深入的見解，是一份不可多得的參考指南??。

作者 | Patrick Dougherty

編譯 | 岳揚

01 何為“Agent”？（Definitions）

在討論本文的主要內容之前，需要明確定義一下本文所指的“Agent”到底是啥。借用一下這位 Twitter 用戶的話[1]：

What the hell is “agent”?

我盡力給出了一個簡明扼要的定義：

實踐出真知：Agents 領域“一年打怪升級”的經驗分享-AI.x社區

該定義大致與 OpenAI 在 ChatGPT 中提及的 “生成式預訓練模型（GPTs）” 和其 API 中的 “助手（Assistants[2]）” 概念相符。不過，Agent 并不會局限于這些能力，任何能進行邏輯推理（reasoning）并調用工具（making tool calls）的模型都能勝任這項任務，比如 Anthropic 公司的 Claude**[3]、Cohere 的 Command R+[4] 等眾多模型皆可。

Note

tool calls 是一種讓模型表達它想要執行的某種特定操作并獲取操作結果的方式，例如調用 get_weather_forecast_info(seattle) 或 wikipedia_lookup(dealey plaza) 這樣的函數。

構建一個 Agent 僅需幾行代碼就可以了，這些代碼能夠處理一個有明確目標且由系統提示詞（system prompt）引導的對話過程，能夠處理模型想要執行的任何 tool calls ，循環執行這些操作，并在達到目標后停止。

下面這幅圖示（visual）可以幫助解釋這一流程：

實踐出真知：Agents 領域“一年打怪升級”的經驗分享-AI.x社區

構建 “Agent” 的基本步驟簡要概覽

02 Agent System Prompt Example

實踐出真知：Agents 領域“一年打怪升級”的經驗分享-AI.x社區

需要在此澄清對 AI Agent 的幾個常見錯誤觀點：

Scripted（腳本化）：根據個人理解，Agent 不會機械地執行預編寫的指令序列或工具調用步驟，AI Agent 能夠自主決定下一步應該使用哪個工具，這是其核心能力；
通用人工智能（Artificial General Intelligence, AGI）：AI Agent 并不等同于 AGI，后者無需依賴 Agents 來完成特定類型的工作，因為 AGI 本身就是一個集所有可能的輸入（inputs）、輸出（outputs）和工具（tools）于一身的單一實體（個人淺見，現有技術距離真正的 AGI 尚有很長一段路要走）；
Black Box：如果告知 AI Agents 具體任務流程，Agents 應當會如同人類接受委托執行任務一樣。

03 上下文 Context

在開發 AI Agents 項目的第一年里，我從與工程師（engineers）和用戶體驗設計師（UX designer）的合作中獲得了第一手經驗，對產品的整體用戶體驗效果進行了多次優化，收獲頗豐。我們的目標是為客戶打造一個平臺，幫助客戶使用我們標準化的數據分析 Agents，并針對其業務中特有的任務和數據結構，自行開發符合個體需求（custom）的 AI Agents。我們確保該平臺與諸如 Snowflake、BigQuery 等數據庫安全對接，同時內置安全機制，在描述數據庫內容的元數據層上調用 RAG（檢索增強生成）工具，并通過 SQL、Python 和支持數據可視化的數據分析工具分析數據。

對于哪些做法可行，哪些觀點則不盡如人意，此平臺不僅依據自身評估（our own evaluations），也參考了客戶的真實反饋。 我們的用戶大多就職于 500 強企業，他們每天都使用我們的 AI Agent 對內部數據進行深度分析。

04 經驗教訓（What I’ve Learned about Agents）

4.1 推理能力比知識量更重要

這句話在過去的一年里一直在我腦海中回響：

我認為，[生成式預訓練Transformer（gpt）]有過多的處理能力（processing power）被用于充當數據庫（database），而非將模型用作推理引擎（reasoning engine）。
— 山姆·奧特曼（Sam Altman**）在萊克斯·弗里德曼（Lex Fridman）播客[5]上發表的見解

AI Agents 正是對此觀點的合理回應！在構建 AI Agents 時，我會采用這一邏輯：

別太在意 AI Agents “了解、知道（knows）” 什么，而應更看重它的 “思考（think）” 能力。

以編寫 SQL 查詢語句（SQL Queries）為例。SQL 查詢語句（SQL Queries）往往頻繁執行出錯……，且屢見不鮮。在我擔任數據科學家（data scientist）期間，我的查詢語句（SQL Queries）執行失敗次數遠遠超過成功的次數。

如果一個復雜的 SQL 查詢語句首次就能在我們不熟悉的真實數據上執行成功，我們應該感到驚訝并產生懷疑，“糟糕，可能有問題！”，而不會自信滿滿地認為“哇！完美！我搞定了”。即便是在評估模型能否將一個簡單問題轉換為查詢語句的 text-to-SQL 基準測試[6]中，其最高準確率也只有 80 %。

因此，即便意識到該模型在編寫 SQL 語句的能力頂多只能得到 B- 的成績，那么我們該如何提升其推理能力呢？關鍵在于為 Agents 提供足夠的上下文，讓它能進行 “思考” ，而非希望它一次性答對。當 AI Agents 編寫的查詢語句執行錯誤時，需要反饋所有 SQL errors 信息以及能夠獲得的盡可能多的上下文信息，這樣 AI Agents 便能在大多數情況下自行修正問題，使 SQL 語句正常執行。我們同樣也為 Agents 提供了大量 tool calls ，使其能像人類那樣，在編寫新的查詢語句前，先對數據庫的信息架構（information schema）和數據特性（data for distributions and missing values）進行調研分析。

4.2 提升性能的最佳方式就是不斷優化“人”機交互界面（agent-computer interface, ACI）

“ACI” 這個新詞（源自普林斯頓大學（Princeton）的一項研究[7]）雖然出現不久，但我們對它的打磨卻是過去一年中的日常工作重心。ACI 指的是 AI Agents 所使用的 tool calls 的具體語法和架構，包括了 AI Agents 生成的 inputs 內容與 API 在響應內容中發回的 outputs 。這些是 Agents 獲取必要數據、推動工作進展與工作目標一致的唯一方式。

由于底層模型（比如 gpt-4o、Claude Opus 等）各有特點，所以對某一個模型來說最完美的 ACI 未必適合另一個模型。 這就意味著，構建一個優秀的 ACI 需要“科學（science）與藝術（art）齊飛”……更像是創造一種極致的用戶體驗，而非純粹地編寫代碼（writing source code），因為 ACI 會持續演變，小小的改動就能像多米諾骨牌一樣引發一連串的反應。ACI 有多么重要，我再怎么強調都不為過…… 我們對我們構建的 AI Agent 進行了數百次迭代，僅僅是對命名（names）、數量（quantity）、抽象程度（level of abstraction）、輸入格式（input formats）及輸出的響應（output responses）做出微調，就能導致 AI Agents 的性能產生巨大波動。

此處有一個具體的小案例，能夠生動地說明 ACI 有多么關鍵和棘手：我們在 gpt-4-turbo 剛推出不久后，對我們的 AI Agents 進行了多次測試，卻發現了一個棘手的問題 —— AI Agents 在處理響應信息時，會完全忽略掉某些數據（正是我們試圖通過 tool call 的響應內容來告知或傳遞給 Agents 的數據部分）。我們所使用的是直接從 OpenAI 官方文檔中提取的 markdown 格式信息，并且在同樣的數據集上與 gpt-4-32k 配合得很好。為了使 AI Agents 能夠識別出那些被它“視而不見”的數據列（columns），我們嘗試對 markdown 結構進行一些調整，但無論怎樣修改，Agents 都無動于衷...... 于是，我們決定徹底改變策略，將信息格式從 markdown 轉換為 JSON（僅針對 OpenAI 模型）格式后，奇跡發生了，一切都恢復如初。頗具諷刺意味的是，響應內容采用 JSON 格式雖然因為包含了大量語法字符而消耗了更多 tokens ，但我們發現這一步驟不僅十分必要，更是確保 Agents 能夠正確解讀模型響應的關鍵。

雖然可能對 ACI 的優化過程感覺微不足道，但這確實是改善 Agents 用戶體驗的有效途徑之一。

4.3 AI Agents 的功能受限于其所使用的模型

底層模型就好比是 Agents 的大腦。如果模型的決策不盡人意，那么無論看起來多么吸引人，都無法令用戶滿意。這一點在我們使用 gpt-3.5-turbo 和 gpt-4–32k 作為底座模型進行測試時親身感受。在使用 GPT 的 3.5 版本時，某些測試案例的情況大致為：

用戶提出了具體任務目標，比如：“按郵政編碼分析星巴克店鋪位置（starbucks locations）與房價（home prices）的相關性，探究兩者之間是否存在聯系。”
Agent卻臆造了一個數據庫表名，比如“HOME_PRICES”，并假設了諸如“ZIP_CODE”和“PRICE”等數據列，而沒有先去數據庫系統中搜索查找真正存在的數據表；
Agent 會嘗試編寫 SQL 查詢語句，打算按郵政編碼計算平均房價，然而查詢語句執行失敗，系統報錯反饋說該表并不存在；
這時，Agent 才會恍然大悟，“啊，對了！我應該可以搜索真實存在的數據表...”，于是開始搜索“home prices by zip code”來定位可用的真實數據表；
Agent 隨后根據找到的真實數據表，修正了其查詢語句，使用正確的數據列，最終成功獲取了數據；
然而，當 Agent 處理星巴克店鋪位置數據時，卻又一次重蹈覆轍...

在 gpt-4 上，以相同的指導原則運行 Agents ，情況則截然不同。它不會再立即執行錯誤的操作而浪費時間，而是會精心籌劃，制定一個有序的 tool calls 執行計劃，并嚴格按照計劃執行。不難想象，在執行更為復雜的任務時，兩個模型之間的性能差距會更為顯著。盡管 GPT 3.5 版本的速度很快，但產品用戶顯然更喜歡?? gpt-4 那更勝一籌的決策和分析能力。

Note

通過進行這些測試，我們獲得了一個重要啟示：當 Agents 出現幻覺或執行失敗時，應當極其細致地觀察這些情況是為何出現的。AI Agents 往往會展現出一種惰性（可能源于人類的懶惰特質在底層模型的訓練數據中被充分學習），因此它們不會輕易調用那些它們認為沒有必要調用的工具。同樣，即便在它們調用工具時，如果對參數說明（argument instructions）理解不清，它們往往會走捷徑（take shortcuts）或是直接忽略必要的參數。這些失敗的案例（failure modes）中蘊含著非常豐富的信息！AI Agents 實際上是在告訴你它期望 ACI（Agent Call Interface）應該怎樣設計，如果情況允許，最直接的解決方案就是順從它的意愿，調整 ACI 使其滿足 Agents 的需求。當然，也有很多時候，需要我們通過修改系統提示詞（system prompt）或 tool call 的 instructions 來對抗 Agents 的天性，但對于那些可以通過簡單調整 ACI 就能解決的問題，直接修改就能大大簡化我們的工作。

4.4 試圖通過微調模型提升 Agents 的性能實屬徒勞

對模型進行微調[8]是通過提供示例來優化模型在特定應用領域表現的一種方法。盡管當前的微調方法擅長教會模型以特定方式（specific way）完成特定任務（specific task），但并不能有效提升模型的推理能力。根據我的經驗，使用微調過的模型來驅動 AI Agents 反而可能降低其推理能力，因為 AI Agents 容易傾向于“走捷徑（cheat）”，即它會錯誤地認為微調過程中所接觸的示例總能代表最優的處理策略和工具調用序列，而不會獨立地對問題進行推理。

Note

微調（Fine-tuning）依然是多功能瑞士軍刀（Swiss Army pocket knife）里的一項利器。例如，有一種行之有效的方法是使用微調過的模型專門處理 AI Agents 提出的特定 tool calls 。設想一下，假如你擁有一個針對特定數據集專門微調過的用于編寫 SQL 查詢語句的模型…… 該 AI Agents（在未經微調的強大推理模型（reasoning model）上運行）可以通過 tool call 來表達它想要執行的 SQL 查詢語句，而我們可以將這一請求轉交由專門針對 SQL 查詢語句微調過的模型進行獨立處理。

4.5 在產品構建過程中，應慎重考慮使用 LangChain 或 LlamaIndex 等抽象化工具

我們應當完全掌控對模型的每次調用，包括其中涉及的所有輸入與輸出細節內容。一旦我們將這些核心控制權拱手讓給第三方庫，未來當我們需要與 AI Agents 合作完成新用戶操作引導流程（onboard users）、問題調試（debug an issue）、用戶拉新（scale to more users）、記錄 AI Agents 的操作日志（log what the agent is doing）、軟件迭代更新（upgrade to a new version），或是深入理解 AI Agents 的行為動機（understand why the agent did something）時，我們將會深切感受到遺憾與不便。

Note

如果你正處于純粹的產品原型階段（prototype mode），唯一的目的在于驗證 AI Agents 是否有可能完成任務，那么，不妨隨心所欲地選擇你最心儀的抽象化工具，馬上動手實踐吧[9]！

4.6 AI Agents 并非護城河

利用 AI Agents 來自動化（automating）或增強（augmenting）人類的知識型工作，蘊藏著巨大的潛力，但僅僅建立一個優秀的 AI Agents 還遠遠不夠。將 AI Agents 推向市場，服務于用戶，就需要在一系列非 AI 的基礎設施上投入大量心血，確保 AI Agents 能夠真正高效運作 —— 而這正是我們能夠塑造差異化競爭優勢的地方：

安全性（security）：AI Agents 應嚴格在用戶授予的權限范圍內運行，由用戶全面掌控。在實際中，這意味著要跨越 OAuth Integrations（譯者注：OAuth 通常用于社交登錄，如使用微信或 Google 賬戶登錄其他網站或應用程序。）、Single Sign-On Providers（譯者注：單點登錄（SSO）是一種身份驗證機制，允許用戶在多個應用程序和服務中使用單一的登錄憑證。）、Cached Refresh Tokens（譯者注：指在 OAuth 認證過程中，為了保持用戶會話的有效性和減少重復認證次數，而存儲在客戶端或服務器上的 refresh token。）等一系列的安全門檻。妥善管理這些安全環節，無疑將為我們的產品加分。
data connectors：AI Agents 通常需要實時從源系統（source systems）獲取數據才能好好工作。這就意味著需要與各種 API 接口及其他連接協議集成，通常是內部系統和外部第三方平臺。這些 integrations 不僅需要初始的構建、部署，更需要長期的維護與優化。
用戶界面（user interface）：除非用戶能夠全程跟進并審核 AI Agents 的工作流程，否則很難建立起對 AI Agents 的信任。通常，在用戶首次接觸 AI Agents 的最初幾次，這種需求尤為突出，但會隨時間逐漸減弱。最好的辦法是，AI Agents 的每一次 tool call 都應配有一套專門的交互界面，讓用戶可以觀察 AI Agents 的決策、操作過程，甚至直接與之互動，以此增進對 AI Agents 推理邏輯的信心（例如，細覽語義搜索（semantic search）結果中每個元素的具體內容）。
長期記憶（long-term memory）：AI Agents 在默認狀態下，僅限于記住當前的工作流程，受限于最大 tokens 數量這一參數。要想實現跨工作流程的長期記憶，甚至跨用戶范圍的長期記憶，就需要將信息存入記憶庫，并通過 tool calls 或將其融入提示詞中來提取。我發現 AI Agents 在判斷哪些信息值得保存至記憶庫中時并不擅長，往往需要人類來決定這些信息是否應當保存。根據具體應用場景，你也許可以接受讓 AI Agents 自主決定何時保存信息至記憶庫中，就像 ChatGPT 一樣。
AI Agents 的評估（evaluation）：構建一套評估 AI Agents 的框架是一項既耗神又似乎永無止境的任務。AI Agents 被刻意設計為保持不確定性（nondeterministic），這意味著它們會依據我們提供的指導方向，尋找最合適的 tool calls 任務序列來完成任務，這一過程就像初學走路的小寶寶，每走一步后都會進行一番思考。對這些任務序列的評估主要體現在兩個方面：一是 AI Agents 在完成任務時的整體成功率，二是每次 tool call 的準確性（例如，搜索過程中的信息檢索（information retrieval）；代碼執行的準確度（accuracy）；等等）。我發現量化整體工作流程性能的最有效且唯一的方法是建立一系列 objective / completion pairs（譯者注：訓練或測試數據集，"objective" 指的是用戶或系統設定的目標或任務，而 "completion" 則是 Agents 完成該目標的具體行動或輸出內容。例如， "objective" 可能是 "查找最近的餐廳"，而 "completion" 則可以是 AI Agents 返回的最近餐廳的名稱和地址。），其中 objective 是指派給 Agents 的初始指令，而 completion 則代表 objective 達成的最終 tool call 序列。捕捉 AI Agents 的 tool calls 中間過程和思維過程，有助于理解 tool calls 失敗的原因或是 tool calls 序列的變化。

Note

將這份清單視為一份正式的 request-for-startups[10] 。圍繞清單上的產品需求開發的產品，如果做得好，有望成為行業的新標準或關鍵組成部分，助力 AI Agents “更上一層樓”。

4.7 別假設大模型的進步會停歇

在構建 Agents 時，我們會不斷受到誘惑：過分地為所依附的底層核心大模型（primary model）開發一些綁定性功能，從而無意間降低了對 Agents 推理能力的預期。務必警惕并克服這一誘惑！ （Resist this temptation!）大模型的發展勢頭銳不可擋，也許不可能永遠在時下的“快車道”之上，但其發展速度仍將遠超歷史上的任何技術變革。客戶自然傾向于選擇能夠運行在自己喜歡、認可的大模型上的 AI Agents。而用戶最期盼的，則是在 AI Agents 中無縫體驗到最前沿的、最強大的模型。 比如當 GPT-4o 發布之后，我僅用 15 分鐘就令其在使用 OpenAI API 的產品[11]中適配該模型。能夠靈活適配不同模型提供商，無疑是巨大的競爭優勢！

Thanks for reading!

Hope you have enjoyed and learned new things from this blog!

Patrick Dougherty

Co-Founder and CTO @ Rasgo. Writing about AI agents, the modern data stack, and possibly some dad jokes.

END

文中鏈接

[1]??https://x.com/savvyRL/status/1795882798454288715??

[2]??https://platform.openai.com/docs/assistants/overview??

[3]??https://docs.anthropic.com/en/docs/tool-use-examples??

[4]??https://docs.cohere.com/docs/command-r-plus??

[5]??https://lexfridman.com/podcast/??

[6]??https://yale-lily.github.io/spider??