構建AI代理？以下是應避免的反模式。

AI代理的失敗往往是可以預測的，問題通常不在於模型本身，而在於架構、記憶設計、工具決策以及複雜性引入的方式。大多數失敗的代理專案都有一系列結構性的錯誤，這些錯誤只有在後期才會顯現，且修復成本高昂。

理解AI代理為何失敗以及如何失敗，有助於建立更清晰的心智模型，瞭解工作代理真正需要什麼。有效的方法是從簡單開始，為可觀測性而構建，並且只在能衡量回報時才增加複雜性。而反模式則發生在團隊反其道而行之時。

本文涵蓋三個主要方面：代理失敗為何比簡單AI系統更嚴重；隨系統增長而累積的架構錯誤；以及僅在生產環境中才出現的操作錯誤。

代理失敗的影響更大，因為語言模型回答問題，而代理系統解決任務，它評估下一步行動、選擇工具、根據結果行動，並在出錯時調整。推理迴圈使代理強大，也使其以提示-響應系統絕不會有的方式失敗。當聊天機器人給出錯誤答案時，對話結束；但當代理在任務中途出錯時，它會繼續執行，可能使用錯誤引數呼叫工具、產生下游步驟依賴的輸出，或因無法識別卡住而無限迴圈。錯誤的決策在每一步中擴大影響範圍。

自主代理還會跨步驟累積狀態，這意味著錯誤會複合。第二步中的錯誤工具呼叫會影響第五步的上下文。過時的記憶條目會影響三步後的決策。到使用者看到問題時，代理可能已經基於錯誤假設採取了多個錯誤行動。因此，代理失敗在種類上不同，而不僅僅是程度。

最常見的架構錯誤是過早追求多代理架構。團隊讀到多代理系統、分層協調器和點對點協作，並尚未驗證單一代理能否解決問題時就設計這些模式。多代理系統引入的協調開銷會以難以預測的方式增加成本和除錯難度。在採用多代理之前，應詢問幾個問題：單一代理加上良好設計的工具是否能解決問題？是否已測量單一代理實際失效的地方？業務價值是否抵消了令牌成本和增加的複雜性？通常，對於首次部署，單一代理就能勝任。

構建一個做所有事情的代理是另一個常見錯誤。一個配置了十五種工具、指令龐大且承擔多種任務型別的代理會在所有任務上表現不佳。最佳化一種輸入會損害其他輸入的效能，因此將輸入路由到專門代理往往比一個通用代理產生更好結果。解決方案不一定是增加更多代理，通常一個範圍明確的專用代理表現優於臃腫的通用代理。先縮小職責範圍，如果仍然不夠，才有理由拆分。

工具列表的擴散也是一個問題。每增加一個工具到代理的上下文中，模型在決定下一步行動時就需要考慮更多。大的工具表面會增加模型錯誤選擇的可能性，膨脹提示大小，並使除錯更困難。保持工具集最小且目的明確，工具應該是離散的、可重用的模組，具有清晰且不重疊的職責。如果工具功能相似，應明確名稱空間以便模型區分。如果為了處理邊緣情況而新增工具，則表明任務範圍需要縮小。

硬編碼邏輯而非為變化而構建會帶來風險。代理系統在生產環境中不斷變化，今天有效的提示下週可能需要修訂。如果邏輯硬編碼在單體實現中，每次更改都可能破壞其他部分。模組化設計意味著提示放在配置中心，工具作為離散單元，代理由所需元件組裝而成。

跳過專用記憶設計是另一個常見問題。許多團隊像設計聊天機器人一樣設計代理：傳入對話，得到回覆。但處理多步任務的代理需要知道兩步前的動作、工具呼叫是否成功以及攜帶的中間結果。如果沒有深思熟慮的記憶設計，上下文視窗溢位會成為生產事故。分層方法可以處理：短期會話記憶用於當前任務狀態和最近工具輸出，長期記憶用於跨會話上下文，結構化日誌用於審計和除錯。從一開始就構建記憶架構，因為事後改造非常痛苦。

在缺乏可觀測性的情況下交付代理會導致診斷困難。AI代理通常是非確定性的，具有不透明的推理過程。當出現問題時，無法透過堆疊跟蹤瞭解代理的決策原因。需要檢視提示鏈、工具呼叫及其引數、模型推理路徑以及上下文在步驟間的流動。沒有可觀測性的團隊可能會花費數週除錯那些透過適當儀表化幾分鐘就能診斷的問題。從第一行程式碼開始構建可觀測性。

給予代理無管控的寫訪問許可權非常危險。LLM可能產生幻覺、推理錯誤並以高置信度給出錯誤答案。具有直接寫生產系統許可權的代理需要在輸出和操作之間設定防護。讀寫操作屬於不同風險類別，應從一開始就區別對待。實踐上意味著：在任何寫操作執行前進行輸出驗證，限制代理能觸及的範圍，並對高風險或不可逆操作要求人機確認。

忽略長時間執行任務中的上下文漂移會導致問題。代理啟動時準確的上下文會隨著任務執行而退化，工具輸出變得過時。上下文視窗應視為有限資源，具有遞減的回報。緩解措施包括：自動清除過時的工具結果，僅從工具響應中提取需要的資訊，並限制工具輸出大小。不要等到代理開始產生幻覺才處理。

最後，在未充分評估前就部署是常見錯誤。在受控測試環境中工作的代理會在生產環境中暴露新的失敗模式。有效的評估意味著在部署前用多樣化、對抗性和邊緣情況的輸入執行代理，定義與業務成果相關的成功指標，並建立反饋迴圈使生產失敗直接影響下一輪迭代。

總結而言，代理失敗更多是架構性而非模型性，可避免的錯誤包括過度工程、代理過載、缺乏記憶、可觀測性差和無管控工具訪問。本文提供了反模式及其修復的詳細表格，並推薦了值得閱讀的資源。祝構建順利！