《AI Agent 落地实践：从 prompt 到工具调用的心得》

一、背景

過去一年，大語言模型的推理能力大幅提升，AI Agent 從概念驗證走向實際落地。與單純的對話式應用不同，Agent 的核心在於「自主規劃＋工具調用」的閉環：模型根據用戶目標拆解任務、選擇合適的工具、執行並根據回饋調整策略。

我們團隊在過去幾個月裡，將一個人工操作流程改造成 Agent 驅動的自動化流程，經歷了從 prompt 工程到工具調用的演進。本文記錄其中的關鍵決策與踩坑經驗。

二、實踐過程

1. 從 prompt 說明書開始

最初的做法是把所有規則寫進 system prompt：角色定義、輸出格式、邊界條件、異常處理。這個階段最大的體會是：prompt 是 Agent 的「操作手冊」，但手冊再厚，也解決不了模型「看不見外部世界」的問題。例如讓模型查詢即時數據，單靠 prompt 只能得到幻覺式的回答。

2. 引入工具調用

當需求涉及外部系統（查數據庫、調 API、讀文件）時，必須給模型「手」。我們採用了 function calling 機制，有三點體會：

第一，工具定義要精準。每個工具的名稱、描述、參數 schema 必須清晰，描述是寫給模型看的，而不是寫給人看的。模糊的描述會導致模型選錯工具或填錯參數。我們統一採用「適用場景＋輸入說明＋輸出說明」的三段式描述，調用準確率明顯提升。

第二，參數校驗前置。在工具執行前做參數合法性校驗，避免把髒數據送進下游系統。校驗失敗時，返回給模型的應該是結構化的錯誤說明，而不是異常堆棧。

第三，返回結果要結構化且節制。工具的輸出應保持簡潔的結構化格式，過長的原始文本會擠佔上下文窗口。我們對工具返回做了字段裁剪，只保留決策需要的關鍵字段。

3. 規劃與執行的分層

複雜任務需要多步推理。我們讓模型先輸出執行計劃（plan），再逐步調用工具，每步執行後把觀察結果（observation）回饋給模型做下一步決策。這種 ReAct 模式效果穩定，但要控制循環次數上限，防止模型陷入無效重試。我們設置了最大步數與超時熔斷，超限後轉人工處理。

4. 狀態與記憶管理

多輪工具調用會快速消耗上下文。我們把中間狀態持久化到外部存儲，而不是全部塞進 prompt；對歷史調用結果做摘要壓縮，只保留關鍵結論。長流程任務的穩定性明顯提升，token 成本下降約四成。

三、踩坑總結

1. 工具描述寫得太「人性化」。曾把工具描述寫成產品文案，結果模型不知道何時該調用。教訓：描述要寫給模型看，突出觸發條件。

2. 忽視冪等性。某個寫操作工具被模型重複調用三次，導致數據重複。教訓：有副作用的工具必須設計冪等，或在編排層做去重。

3. 錯誤信息直接透傳。初期把下游系統的原始報錯直接丟給模型，模型被技術細節帶偏。後來把錯誤轉譯為「業務語義＋建議下一步」，糾錯能力明顯變好。

4. 沒有設置護欄。模型曾嘗試調用高風險的管理工具。現在按風險分級：讀操作默認開放，寫操作需二次確認，高風險工具默認不開放。

5. 過度依賴單次大 prompt。把所有邏輯塞進一個巨型 prompt，調試困難且成本高。拆分為「規劃＋執行＋校驗」三個 prompt 後，迭代效率高很多。

四、結語

從 prompt 到工具調用，本質是從「讓模型說」到「讓模型做」的轉變。Prompt 決定下限，工具設計決定上限。建議從小閉環開始驗證，先讓一兩個工具穩定工作，再逐步擴展。希望對正在做 Agent 落地的同行有所幫助。