實用指南：常被混為一談的三個層次
大多數人談論 AI Agent 時，好像它就是一個單一的概念。
但它不是。
當一個 Agent 從玩具般的示範，進化到開始觸及檔案、API、文件、客戶或正式環境的程式碼時，你就不再只是「對模型下指令」而已。
你正在設計一個系統。
而在這個系統中，有三個概念經常被混為一談：
- Agent 框架工程
- 循環工程
- 流程圖工程
它們都圍繞著同一個模型。
它們都影響可靠性。
而且，沒錯，它們都可能包含循環。
但它們解決的是不同的問題。
如果把它們搞混了，最後你會在錯誤的層次上進行除錯。
30 秒速答
以下是精簡版的說明：
- 框架工程 建立模型周圍的運作環境
- 循環工程 設計重複的工作與反饋循環
- 流程圖工程 明確化工作流程的拓撲結構
一個好的心智模型是：
環境 → 反饋 → 流程
- 框架 提供模型工具、記憶、控制權和一個工作區
- 循環 決定工作如何被重試、檢查和改進
- 流程圖 定義下一步允許發生什麼事
這就是它們的區別。
為什麼這些術語現在很重要
一個原始的模型無法獨自完成實際工作。
它無法：
- 跨工作階段維護專案狀態
- 安全地呼叫工具
- 檢查瀏覽器
- 執行權限控制
- 重試失敗的工作
- 驗證輸出品質
- 在專家之間路由任務
- 在正確的時機停止
所有這些功能都來自於它周圍的系統。
隨著 Agent 軟體逐漸成熟，一個實用的技術堆疊正在成形：
- 框架 提供模型運作條件
- 循環 使工作可重複且可驗證
- 流程圖 使複雜的工作流程明確且可控制
一旦你將這些視為不同的層次，AI 架構上的許多困惑就會消失。
一個嚴謹的框架通常包含哪些東西
- 情境注入
模型在行動前看到的內容：
- 指令
- 檢索到的知識
- 對話狀態
- 記憶
- 政策
- 任務特定規則
- 行動介面
模型可以做的事：
- API 呼叫
- 瀏覽器操作
- Shell 命令
- 程式碼執行
- MCP 工具
- 資料庫
- 自訂函數
- 持久化
跨越時間仍存在的內容：
- 檔案
- 檢查點
- 工作階段狀態
- 進度日誌
- Git 歷史
- 長期記憶
- 執行控制
如何管理執行：
- 重試
- 超時
- 預算
- 模型選擇
- 子 Agent 生成
- 審批關卡
- 安全與治理
如何保持系統安全：
- 最小權限原則
- 隔離
- 允許清單
- 機密處理
- 人工審批
- 可觀測性
如何讓你進行除錯：
- 追蹤
- 工具輸入與輸出
- 狀態轉換
- 延遲
- 成本
- 評估結果
為什麼框架工程很重要
兩個團隊使用同一個模型，可能得到完全不同的結果。
為什麼？
因為一個團隊提供了模型：
- 乾淨的工具
- 穩定的狀態
- 結構化的記憶
- 清晰的權限
- 可觀測的執行
而另一個團隊只給了它：
- 模糊的提示
- 混亂的工具
- 雜亂的情境
- 沒有記憶
- 沒有驗證
模型可能相同。
但運作條件不同。
框架工程在以下情況至關重要：當 Agent 無法存取所需功能、跨工作階段遺失情境、在不同環境中表現不一致、無法被稽核、擁有過多權限，或在中斷後無法乾淨地恢復。
如果模型無法可靠運作，首先要檢查的就是框架。
2. 循環工程
它是什麼
每個使用工具的 Agent 都已經內建了一個微小的循環：
- 呼叫模型
- 觀察結果
- 執行工具
- 將觀察結果回饋給模型
- 重複直到完成
循環工程始於你有意地圍繞這個行為設計額外的循環。
不只是「再問一次」。
不只是「重試一次」。
而是一個真正的工作與反饋系統。
一個良好循環的構成要素
觸發條件
什麼會啟動一個新的循環？
- 使用者請求
- 測試失敗
- 新文件
- 排程執行
- Webhook
- 評估者反饋
目標
我們試圖達到的具體條件是什麼？
不是「持續改進」。
而是一個真正的目標。
狀態
下一個循環需要知道什麼？
- 當前草稿
- 前一次嘗試
- 工具結果
- 錯誤
- 進度狀態
行動策略
允許 Agent 做什麼？
- 編輯
- 委派
- 呼叫工具
- 花費 Token
- 寫入檔案
- 開啟 PR
證據
我們如何知道它是否成功？
- 測試
- 結構驗證
- 引用
- 差異
- 指標
- 審查者批准
反饋
具體失敗在哪裡？
反饋應該簡潔且可執行。
停止規則
何時結束？
- 成功
- 超時
- 預算耗盡
- 達到最大重試次數
- 不可恢復的失敗
- 升級給人類
循環工程中最重要的原則
**不要基於信心進行循環。
要基於證據進行循環。**
「Agent 說它完成了」不是一個停止條件。
一個真正的停止條件看起來更像：
- 測試通過
- 結構驗證通過
- 引用解析成功
- 審查者批准
- 政策檢查乾淨
這就是循環工程。
為什麼循環工程不只是提示工程
提示告訴模型在一次呼叫中要做什麼。
循環定義了系統在呼叫之後要做什麼。
這包括：
- 如何檢查結果
- 如何回應失敗
- 如何持久化進度
- 如何決定繼續
- 如何終止
提示改進的是回應。
循環改進的是流程。
這是兩個截然不同的工程問題。
3. 流程圖工程
它是什麼
流程圖工程使工作流程的結構變得明確。
它回答了一個不同的問題：
不只是「Agent 應該做什麼？」 而是「下一步允許發生什麼事？」
在流程圖工程中：
- 步驟是節點
- 轉換是邊
- 分支是明確的
- 平行工作是明確的
- 匯合是明確的
- 重試是明確的
- 人工中斷是明確的
流程圖成了系統的控制地圖。
流程圖工程師實際設計什麼
節點邊界
什麼東西屬於：
- 確定性函數
- LLM 呼叫
- 專科 Agent
- 人工審查步驟
狀態結構
每個節點可以讀取或寫入什麼。
路由條件
什麼證據能推動工作：
- 前進
- 後退
- 橫向移動
- 升級處理
並行性
什麼可以平行執行，什麼必須等待。
循環與出口
哪裡允許重試、允許多少次、以及如何停止。
持久性
檢查點在哪裡，以及工作流程如何在中斷後恢復。
何時值得使用流程圖
當流程包含以下情況時，流程圖很有價值：
- 有意義的分支
- 審批
- 專科交接
- 平行工作
- 恢復路徑
- 具有明確控制點的多步驟工作流程
當工作只是簡單地：
「給一個 Agent 幾個工具，讓它去工作。」
這種情況下，流程圖就沒那麼有用。
在這種情況下，一個紮實的框架加上幾個循環可能就足夠了。
流程圖增加了清晰度，但也增加了結構。
過早引入過多的結構可能會使系統變得脆弱。
這三個層次如何協同運作
假設你正在建立一個研究與發布 Agent。
它必須：
- 界定主題範圍
- 收集來源
- 篩選引用
- 草擬報告
- 通過法務審查
- 獲得批准後才能發布
以下是各層次的對應方式：
框架
提供：
- 瀏覽器存取
- 搜尋工具
- 檔案工作區
- 記憶
- 引用
- 審批
- 追蹤
- 模型路由
循環
處理：
- 當證據不足時重試來源檢索
- 修復引用失敗
- 執行評分檢查
- 當市場變化時更新工作
流程圖
控制路徑：
- 界定範圍
- 研究
- 篩選
- 綜合
- 草擬
- 審查
- 發布
在發布前設有人工關卡。
這就是為什麼這三個層次不可互換。
它們協同工作，但它們不是同一回事。
在選擇解決方案之前，先診斷問題
以下是實用規則：
如果 Agent 無法運作，請修復框架
例如：
- 缺少工具存取權限
- 狀態過時
- 記憶薄弱
- 權限不當
- 沒有可觀測性
如果 Agent 幾乎能運作但不可靠，請修復循環
例如：
- 初稿接近但薄弱
- 成功與否不一致
- 重試不受控制
- 沒有完成的證明
如果流程本身很複雜，請修復流程圖
例如：
- 許多專科人員
- 審批
- 分支邏輯
- 平行路徑
- 結構化的交接
常見錯誤
1. 過早建立流程圖
團隊常常在觀察到工作實際行為之前，就繪製出龐大的工作流程圖。
更好的方法：
- 從一個更簡單的框架開始
- 收集追蹤記錄
- 找出穩定的模式
- 只將值得控制的部分正式化
2. 讓同一個模型在沒有安全措施的情況下既寫作又評分
自我審查可能有幫助，但它共享相同的盲點。
更傾向於：
- 盡可能使用確定性檢查
- 分離的審查者情境
- 外部評估者
- 對高影響力行動進行人工審批
3. 把「持續嘗試」當作一個循環
那不是循環設計。
那是失控的成本漏洞。
每個循環都需要：
- 可衡量的目標
- 真實的證據
- 重試限制
- 升級規則
4. 把框架當作雜物抽屜
更多的工具並不自動等同於更好的 Agent。
太多的工具會導致：
- 選擇錯誤
- 情境雜亂
- 可靠性低
- 風險面擴大
一個好的框架並不擁擠。
它是精準的。
5. 將編排失敗歸咎於模型
模型無法彌補：
- 損壞的 API
- 過時的狀態
- 缺少的退出條件
- 模糊的工具結構
- 看不見的失敗模式
修復擁有該失敗的所有權的那個層次。
一個簡單的正式環境檢查清單
框架
- 工具是否狹窄且有文件說明？
- 狀態是否持久？
- 權限是否為最小權限？
- 操作者是否可以暫停、檢查和恢復？
- 追蹤記錄是否可見？
循環
- 什麼證據能證明成功？
- 失敗時會回饋什麼資訊？
- 允許重試多少次？
- 停止規則是什麼？
- 當預算用盡時會發生什麼事？
流程圖
- 哪些路徑必須是確定性的？
- 什麼可以平行執行？
- 人工關卡在哪裡？
- 哪些狀態是共享的？
- 恢復路徑從哪裡開始？
評估
- 你能重播真實的追蹤記錄嗎？
- 你能比較不同版本嗎？
- 你能將改進歸因於一個真正的改變嗎？
營運
- 你是否追蹤成本？
- 延遲？
- 失敗率？
- 干預率？
- 任務在正式環境中的成功率？
記住區別的最簡單方法
如果你只記得一件事，請記住這點：
- 框架工程 使模型可運作
- 循環工程 使工作可迭代且可驗證
- 流程圖工程 使執行路徑明確且可控制
沒有任何一個可以取代其他。
完美的流程圖無法拯救一個薄弱的框架。
一個強大的框架，如果沒有良好的循環，仍然會浪費金錢。
而當分支和審批隱藏在臨時程式碼中時，乾淨的循環也會變得難以管理。
可靠的 Agent 系統，是在所有三個層次都被有意設計時才會出現的。
這就是實際的架構堆疊。
最終結論
人們不斷地談論 AI Agent，好像突破點在於模型。
在正式環境中，這很少是真正的區別因素。
真正的區別因素在於模型周圍的系統：
- 讓它能夠工作的框架
- 讓它能夠改進的循環
- 讓它能夠在控制下運作的流程圖
這就是玩具般的 Agent 如何變成真實系統的方式。
如果你讀到這裡：
- 請收藏此頁。
- 追蹤 @LunarResearcher
- 追蹤我的 Substack
- 追蹤我的 私人 Telegram 頻道
