打造可靠 AI Agent 的關鍵：與其鑽研 Prompt，不如專注於可預測的工具設計

在建構 AI Agent 的過程中，許多人常陷入一個誤區：認為只要不斷優化 Prompt，就能提升系統的穩定性與可靠性。然而，我的觀察與 Anthropic、OpenAI 近期的實踐指引都指向同一個結論：Agent 的可靠性上限，往往取決於我們提供給它的工具（Tools）是否被當成嚴謹的軟體工程模組來設計，而不是取決於 Prompt 的繁複技巧。一個可預測、可測試、可組合的工具，遠比任何華麗的提示詞都來得重要。

當我們將 Agent 視為一個軟體系統，大型語言模型（LLM）是其非確定性的「大腦」，而工具則是其確定性的「手腳」。如果手腳的動作本身就充滿變數，我們很難期待大腦能穩定地指揮它們完成複雜任務。因此，將開發重心從 Prompt Engineering 轉向 Tool Engineering，才是打造 Production-ready Agent 的務實之路。

為什麼工具設計比 Prompt 更重要？

大型語言模型本質上是機率性的，即使我們用盡方法約束，其輸出仍然存在一定程度的隨機性。這意味著，完全依賴 Prompt 來確保 Agent 每一步都精準無誤，是一項艱鉅甚至不可能的任務。相比之下，工具是我們自己編寫的程式碼，它們的行為是確定的、可測試的。

Anthropic 在其建構高效能 Agent 的工程指引中明確指出，工具的設計對 Agent 的成功至關重要，其重要性甚至超過 Prompt 設計。當工具設計良好時，LLM 的任務就從「想出複雜的解決方案」簡化為「在幾個清晰的選項中做選擇」。這大幅降低了模型的認知負擔，從而顯著提升了任務的成功率與穩定性。

這個觀念的轉變，意味著 Agent 開發者的角色，也從一個神秘的「詠唱師」（Prompt Whisperer），回歸到更為我們所熟悉的「系統工程師」。我們的工作重點，是為 LLM 搭建一個穩定可靠的執行環境與腳手架，而不是試圖去微觀管理它腦中的每一個念頭。

可靠工具的核心設計原則

那麼，一個「設計良好」的工具應該具備哪些特質？綜合業界的最佳實踐，我們可以歸納出幾個核心原則，這些原則大多源自於傳統軟體工程，但在 Agent 開發的脈絡下尤為重要。

• 單一責任原則（Single Responsibility Principle）：每個工具應該只做一件事情，並且把它做好。避免設計一個擁有多個模式、接受大量複雜參數的「萬能工具」。例如，與其設計一個 manage_user(action, user_id, data) 的工具，不如將其拆分為 get_user(user_id)、create_user(data)、update_user(user_id, data) 三個獨立的工具。這讓 LLM 更容易理解每個工具的用途，並正確地選用。
• 冪等性（Idempotency）：一個工具被同樣的參數重複呼叫多次，其產生的效果應該與只呼叫一次相同。這在處理網路延遲、系統重試時至關重要。例如，一個 charge_payment 的工具如果不是冪等的，重試機制可能會導致用戶被重複收費。確保操作的冪等性，能讓 Agent 在面對不穩定的外部環境時更具韌性。
• 防呆設計（Poka-yoke）：這個概念源自日本的精實製造，意指「預防錯誤」。在工具設計中，我們應該預見到 LLM 可能會傳入錯誤或格式不符的參數，並在工具層面進行驗證與處理。與其讓錯誤的參數導致系統崩潰，不如回傳一個清晰、能讓 LLM 理解並修正的錯誤訊息。

這些原則的共通點，是將「可預測性」注入到 Agent 系統中。當工具的行為是可預測的，整個系統的行為才會趨於穩定。

如何處理工具執行時的錯誤與不確定性？

即使工具本身設計得再好，它們與外部世界的互動（如呼叫 API、讀寫資料庫）仍然可能失敗。因此，一個完整的 Agent 系統還需要健全的錯誤處理與管理機制。

傳統的軟體工程模式，如「斷路器」（Circuit Breaker）和「驗證閘門」（Validation Gate），在這裡同樣適用。斷路器可以在某個外部服務持續失敗時，暫時阻斷對該工具的呼叫，防止資源浪費與連鎖失敗。驗證閘門則可以在執行工具前，先對 LLM 生成的參數進行一輪檢查，確保其符合業務邏輯。

與其期望 LLM 總能完美無瑕地生成正確的工具呼叫，不如設計一個能夠容錯、並能從錯誤中恢復的系統。這才是務實的工程思維。

近年來，模型供應商和開發框架也開始提供更強大的工具管理功能。例如，OpenAI 的 Function Calling 提供了 strict mode，可以強制模型輸出的 JSON 嚴格符合預先定義的 Schema。Anthropic 也在其模型（如 Claude Code 系列）中持續強化工具使用的準確性。這些功能從模型層面降低了工具呼叫出錯的機率，但並不能完全取代應用層的防禦性設計。

當我們面對像 SWE-bench 這類複雜的軟體工程任務時，Agent 需要協調數十甚至上百個工具（如讀檔、寫檔、執行測試、程式碼分析）。在這種情境下，如果沒有一套系統化的工具設計與錯誤處理框架，整個系統將很快變得混亂而不可維護。

從軟體工程的角度看待 Agent 開發

從早期的 OpenAI Codex CLI 實驗，到如今圍繞 LangChain 等框架建構的複雜 Agent 系統，我們可以看到一個清晰的演進軌跡：AI Agent 開發正在從一門「藝術」走向一門「工程學」。

在這條路上，Prompt 仍然是與 LLM 溝通的重要介面，但它更像是專案的需求文件，而不是產品的原始碼。真正的核心，是那些被良好定義、嚴格測試、具備韌性的工具模組。它們構成了 Agent 可靠性的基石。

因此，下次當你的 Agent 表現不如預期時，先別急著去修改 Prompt。或許，我們該回頭檢視一下：我們給它的「手腳」，是否足夠穩固、靈活、且值得信賴？

延伸閱讀

• Building effective agents (Anthropic Engineering)
• AIエージェントツール設計の7原則：Anthropic・OpenAI公式ガイドに学ぶ実装パターン (Zenn.dev)

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。