AI 代理程式架構：可靠工作流的組成部分

AI 代理程式架構是圍繞模型設計的軟體系統，包括狀態、檢索、工具、編排、安全與評估。好的架構會讓不確定性和失敗可見，而不是把它們隱藏在聊天介面後面。

研究與揭露: 本文的架構建議參考以下官方資料：OpenAI, Anthropic, LangChain, NIST。資料查閱於 2026 年 9 月 2 日。

參考分層

層	責任	設計問題
介面	接收目標並顯示狀態	使用者需要核准什麼？
編排器	控制步驟、重試與停止	每次狀態變化都能記錄嗎？
模型	解釋上下文並提出行動	需要什麼輸出結構？
上下文	檢索檔案、記憶和狀態	檢索前是否套用權限？
工具	執行外部操作	呼叫是否受限且具冪等性？
評估	衡量品質與安全	哪些失敗會阻止發布？

狀態與記憶

將一次執行的暫時狀態與長期專案記憶分開。檢索到的事實要保存來源和時間戳。沒有審核或來源政策，不要把模型之前的回答當作權威記憶。

要區分架構和工作流，可以參考智能體工作流指南：架構描述系統邊界，工作流描述系統執行的有序工作。

工具邊界

提供範圍狹窄的函式，不要暴露不受限制的憑據。執行前驗證參數，設定逾時，對傳送、刪除、購買或修改權限等操作要求確認。使用冪等鍵，避免重試造成重複副作用。

檢索與事實依據

只檢索使用者有權限存取的內容。把來源識別放入模型上下文，並要求結果帶引用或證據欄位。檢索為空或存在衝突時，返回升級狀態，而不是自行填補缺口。

從可撤銷的小範圍開始

先做一個唯讀任務，再增加寫入權限。基於來源生成簡報或分類結果可以提供有用的執行軌跡，同時避免不可逆風險。每次只增加一個工具，並記錄它的權限邊界。

請求與回應契約

為每一層定義契約。請求應包含目標、使用者身分、允許的來源和預算；回應應包含狀態、結構化結果、引用、工具呼叫，以及仍需審核的內容。

Prompt

{
  "status": "needs_review",
  "claims": [],
  "sources": [],
  "open_questions": ["核准的資料集中缺少最新季度。"]
}

明確的狀態比一段隱藏缺失來源的流暢文字更安全。

評估與運維

準備正常、不完整、惡意和多語言測試案例。追蹤工具錯誤、升級率、延遲、成本和審核修正。Prompt、工具、模型設定和策略應一起做版本管理。

上線檢查清單

每次工具呼叫和模型版本都有可重播軌跡
測試與生產使用不同憑據和資料
寫入操作具備冪等性和回滾路徑
每次 Prompt 或模型變更前執行評估案例
有人負責接收升級並檢討事故

同步、非同步與人工檢查點

短分類可以同步完成。長時間檢索或文件生成應非同步執行，並提供進度和取消功能。不可逆操作之前，以及信心度、權限或政策檢查失敗時，應設定人工檢查點。將審核決定保存為執行狀態，避免重試時遺失上下文。

成本與延遲預算

限制模型輪次、工具呼叫、token 和總耗時。簡單擷取可以交給較小模型，把成本較高的推理留給模糊情況。預算既是運營控制，也是對使用者的產品承諾：工作流應明確何時停止並請求協助。

常見問題

需要多 Agent 架構嗎？

不需要。先從一個 Agent 和明確工具開始。只有當角色、權限或評估標準真正不同，才增加多個 Agent。

安全應該放在哪一層？

所有層都需要：身分、檢索、工具權限、密鑰、日誌和人工審核。安全不是最後才添加的一項檢查。

如何減少幻覺？

改進來源選擇，限制輸出格式，要求證據，並讓不確定性觸發實際處理。Prompt 文字本身不是完整控制措施。

第一個原型應該做什麼？

選擇一個邊界清晰、操作可撤銷且有明確審核人的工作流。先驗證控制路徑，再增加工具。