昨天那六個名詞都指得出實體，可以指著某個行程或某個檔案說這就是它，今天這一組講的是做事的方法。

這一組名詞的用處在遇到問題時定位：該去改 prompt、改 context，還是改權限。

Agent 工程的四個範式

Guo 等人 2026 年的調查（arXiv:2606.20683）把 agent 工程的演進整理成四個範式：

前三者是疊加關係。 到了 harness 這一代，prompt 仍然要寫，context 仍然要配置，新的一代處理的是舊的一代範圍以外的問題。

第四個範式動到模型訓練，需要自己訓模型才碰得到，接下來 30 天的範圍停在第三個。

遇到問題時先定位

對照時先確認模型落在哪一種狀態：

• 資訊停在 context 之外 → 往 context 找
• 資訊已進入，行為偏離 → 靠權限層擋
• 行為正確，結果待驗 → 建立驗證機制

迴圈、規格與驗證

Loop Engineering

Anthropic 在 2026 年 6 月的文章裡把 loop 定義為 agent 重複執行工作，直到停止條件成立，並依觸發方式分成四種：

四種的差別集中在一件事，什麼時候停。停止條件決定 agent 何時收手，條件模糊時它會一路做下去，把 context window 耗光為止。

Spec-Driven Development

GitHub 在 2025 年 9 月開源 Spec Kit，對這套做法的說明是：

先寫規格，這份規格是一份合約，agent 拿它來產生程式碼、測試、驗證

重點在同一份。產生用的規格與驗證用的規格是同一份時，通過驗證等於符合規格；驗證另寫一套標準時，系統就有兩個真實來源，通過驗證只代表符合另外那一套。

驗證迴圈

Anthropic 那篇文章有一句講得很直接：

寫程式的迴圈，需要另一個檢查它的迴圈

要防的是這種狀況：

• 程式編譯得過
• JSON 解析得出來
• 指令回傳成功
• 執行的內容與規格要求的那件事有落差

這種輸出在下游看起來很正常，往往要好幾層之後才會顯現，回頭追原因的成本隨層數上升。

程式碼以外也適用。我在既有的 IoT 專案上做過一版，排程送出控制指令之後，agent 回頭讀感測端點，比對現在的狀態與預期的狀態，兩者有落差就重試並記錄。

指令回傳成功屬於通訊層的回應，設備實際動作要回讀狀態才能確認。

三者怎麼組在一起

三者由內而外包覆，外側依賴內側：

1. 規格：說清楚什麼叫做對
2. 驗證步驟：拿規格去比對結果
3. 迴圈：把驗證步驟放進每一輪

• 規格提供比對的基準，驗證依賴它才有比對對象
• 驗證提供每一輪的判定，迴圈依賴它才會在結果偏離時反應

既有領域名詞在 agent 系統的語意對應

這三個詞在網路架構、資訊安全與可靠度工程裡都有既有用法，搬到 agent 系統之後語意會有些出入，先講清楚各自對應到什麼。

control plane

RFC 7426 把網路設備拆成 control plane 與 forwarding plane 之後，換掉轉送硬體時決策邏輯照舊。Agent 系統套同一個結構，換掉 Model 時記憶、身分與權限設定照舊。

least privilege

Saltzer 與 Schroeder 在 1975 年那篇論文裡說：

系統裡的每個程式、每個使用者，都應該只用完成工作所需的最小權限集合來運作

放到 agent 上有個特別的地方，權限上限由憑證決定：

差別在於能否驗證。

failure mode

這個詞要求把形式、原因、後果分開講：

• 合格的寫法：「重新啟動後，先前寫入的偏好遺失」，它講的是可重現的固定形式
• 停在感受的寫法：「agent 壞了」，形式、原因與後果混在同一句裡

Hashimoto 對 harness engineering 的定義就建立在這個區分上，每發現一次錯誤，就做一個機制讓它不再發生，前提是那次錯誤能被講成一種形式。

心得

同一個技術名詞在二手文章與一手文件裡的定義可以差很多。

Loop Engineering 就是例子。部分文章把它描述成「Spec-Driven Development 的執行期形式」，這個框架讀起來合理，而 Anthropic 的原文界定的範圍限於停止條件，以及依觸發方式分出來的四種 loop。

那個「執行期形式」是撰文者自己的類比。

二手轉述有兩個問題：

1. 撰文者的詮釋與原文的定義混在同一段裡
2. 出自原文的句子與自行補充的句子共用同一種語氣

名詞的定義取自二手來源時，別人的推論會混進定義，後面所有以該定義為前提的判斷都跟著偏掉。查一手文件的成本通常是多開一個連結。

明天

拆解 Agent = Model + Harness，說明既有文獻把 harness 分成哪六項執行期職責。