
LLM、AI 代理與工作流程架構:有何分別?
簡短回答: 大型語言模型負責生成或轉換語言;AI 代理把模型與指令、工具和目標循環結合;工作流程架構再加入業務步驟、狀態、政策、驗證與人工管控。OpenClaw 可以構成代理運行時的一部分,但不能取代周邊運作設計。
讓企業 AI 工作流程可靠運行
LLM 可以回答、摘要、抽取和起草,但本身沒有存取企業系統的權限。工具型代理可在已批准的界線內檢索、計算或調用工具。工作流程定義一項業務工作的重複路徑、分支和結果。
設計、管控與持續改進
企業架構需要將模型、工具、狀態、身份、政策、稽核紀錄、評估和審批連接起來。每層各司其職,系統便更容易理解、測試和變更,也不會把關鍵管控交給不透明的提示詞。
擴展範圍前先驗證
先為每一層設定介面:甚麼輸入交給模型、哪些工具可被調用、狀態存放在哪裏、何時必須驗證、誰可批准外部行動。把確定性規則從模型判斷中分開。
不要由「選擇一個代理」開始,而是由一個有明確成果和管控要求的業務流程開始。
常見問題
如何開始?
由一個範圍明確、可驗證且風險可控的流程開始。
為何需要管治?
管治讓權限、證據、責任及例外處理在擴展使用前保持清晰。
互動實踐指南
選擇滿足需要的最小層次
選擇一個項目,查看相應的營運模式。應查看的證據: 業務系統權限
按照層次思考,而非產品標籤
可靠的企業系統通常至少有六層:負責語言和推理的模型;負責情境和動作的檢索與工具;負責動態決策的代理循環;負責狀態和業務順序的工作流程編排;負責身份、政策、審批及預算的控制面;以及負責追蹤、評估及審計的證據層。一個產品可能實作多層,但每項責任仍需明確負責人。
生產級架構指引區分預先定義程式路徑的工作流程與動態選擇過程和工具的代理;常見代理設計把代理描述為模型、工具與指令透過運行循環協作。把它們視為不同層次時,兩種定義並不矛盾。
把數據面與控制面分開
數據面承載提示、檢索紀錄、工具參數及輸出;控制面決定哪個身份可以存取哪個工具、動作是否需要審批、運行可以花費多少及何時必須停止。政策執行應放在模型之外,避免有說服力的輸入重寫界線。
類型化工具協定可標準化能力發現和調用,但統一協定不會消除授權、租戶隔離、網絡政策及數據分類需求。整合便利與企業信任是兩個不同的架構問題。
把記憶視為多種不同儲存
對話歷史、工作流程狀態、用戶偏好、檢索到的企業知識與習得技能,並不是一種通用「記憶」。它們有不同來源、保留期、存取規則及正確性要求。工作流程狀態需要精確持久化;檢索知識需要新鮮度和來源;用戶偏好需要同意與刪除機制;摘要需要恢復壓縮中遺漏關鍵事實的方法。
為每種儲存定義結構及負責人,並決定哪些內容可以跨用戶、會話、項目或區域。更多記憶不一定更好,它可能增加私隱風險、成本並保留過時假設。
分別評估每一層和完整系統
模型評估測試抽取、分類或推理;工具測試驗證結構、權限與故障處理;代理軌跡評估檢查多輪決策;工作流程測試涵蓋狀態轉移、重試、審批及端到端結果;營運測試則涵蓋延遲、成本、復原與審計證據。
單層通過不代表整體成功,例如模型答案正確,卻因重試產生重複寫入。應在層與層的介面建立測試,並維持一組接近生產的端到端個案。能夠定位、限制和修復失敗,而不靠猜測,才是良好架構。
架構決策清單
- 由可量度業務結果開始
- 加入代理循環前先嘗試直接模型調用
- 把確定性政策放在模型推理之外
- 在每個工具界線定義身份、狀態與證據
- 為每種記憶定義保留及存取規則
- 測試層間介面、復原與端到端結果
選擇滿足需要的最小層次
| 需要 | 架構選擇 | 不應獨自承擔 |
|---|---|---|
| 轉換範圍明確的內容 | 直接 LLM 調用與驗證 | 業務系統權限 |
| 選擇工具或動態步驟 | 帶限制的代理循環 | 獨自保存持久業務狀態 |
| 運行可重複業務流程 | 圍繞模型或代理的編排器 | 無限模型自由裁量 |
| 連接外部能力 | 類型化工具介面 | 靠假設完成授權政策 |
