“In the loop, on the loop, or out of the loop?” — 2026 年 Thoughtworks 的工程師把這個問題提升成了架構決策。 兩篇 martinfowler.com 文章給出了截然不同但互補的框架：Kief Morris 用軟體工程迴圈分析人的正確位置；Dirk Lässig 用控制論把這個問題提升到管理科學層次。
Kief Morris 的迴圈框架：為什麼 “On the Loop” 才是對的
來源：Kief Morris（Thoughtworks），Humans and Agents in Software Engineering Loops，2026-03-04
Morris 把軟體交付描述為巢狀的反饋迴圈：
- Why Loop（為什麼迴圈）：人在想法和運作軟體之間反覆迭代的策略層——「我們在解決什麼問題？這個方向對嗎？」這個迴圈由人跑，因為人才是想要產出的那一方。
- How Loop（怎麼做迴圈）：中間工件（程式碼、測試、spec）的生成和精煉，包含多個子迴圈——這是 agent 可以接管的部分。
三種人的站位：
| 站位 | 行為 | 後果 |
|---|---|---|
| Out of the loop | 讓 agent 完全自主運作 | 品質螺旋下降、方向持續偏移 |
| In the loop | 親自修每個工件，或逐步指揮修正 | 消耗人力，扼殺 agent 的速度優勢 |
| On the loop（推薦） | 建立和管理讓 agent 工作的 harness | 人的精力用在系統設計，不是逐行監督 |
Morris 的核心論點：
「我們人類的正確位置，是建立和管理這個運作中的迴圈，而不是讓 agent 自己跑，也不是微管理每個產出。」
Agentic Flywheel（自我改進的飛輪）：
- 建立 harness（spec、品質檢查、工作流引導）
- 給 agent 豐富的效能訊號（測試、運維資料、用戶指標）
- 讓 agent 建議 harness 改進
- 對低風險建議進化到自動核准
→ 迴圈越跑越緊，harness 自我提升，人的監督從微觀轉向系統層次。
Dirk Lässig 的控制論框架：把 Agent 管理變成系統設計
來源：Dirk Lässig（Thoughtworks），Cybernetics and the “human-on-the-loop” in agentic coding，2026-04-20
Lässig 借用 1940–1970 年代的管理控制論（Cybernetics）為 on-the-loop 建立理論基礎：
- Norbert Wiener（1940s）：控制論基礎——研究複雜系統中的通訊與控制
- Stafford Beer 的 Viable System Model（1970s）：以五個遞歸控制系統組織複雜環境中的可行系統；被 Lässig 直接套用到 agentic 開發的組織設計
- Ross Ashby 的 Law of Requisite Variety：「只有多樣性才能吸收多樣性」——人必須在元層次（meta-level）匹配系統複雜度，而不是在操作層次
- Conant-Ashby 定理：有效的系統調節者必須對被調節的系統有足夠的模型
兩種主要的人類控制工具：
| 工具 | 方向 | 機制 |
|---|---|---|
| Attenuation（衰減） | 過濾多樣性、減少需要人處理的複雜度 | 儀表板、例外警報、聚合指標 |
| Amplification（放大） | 擴展人類影響力到整個系統 | 編碼化的政策、知識庫、分散式控制 |
三個具體實踐：
- Harness Engineering：在 agent 多樣性外圍建立結構化框架（與 Morris 和 Böckeler 的框架 互相交叉）
- Gemba / Go See：定期深入查看實際程式碼，驗證感測器準確性、更新心智模型——不能只看儀表板
- Double-Loop Learning：不只修正效能問題，也質疑底層假設本身（「我們的評估標準是否仍然正確？」）
Böckeler 的技能清單：什麼真的不能被取代
來源：Birgitta Böckeler（Thoughtworks），The role of developer skills in agentic coding，2025-03-25
Böckeler 用三個影響層次組織 agent 在哪裡容易出錯，反推出人必須保留的技能：
即時開發層（Time to Commit）
- 問題診斷與除錯（識別 agent 走進死胡同的時機）
- 「何時放棄 AI 方向」的技術判斷——不是感覺，是基於理解
團隊工作流層（Iteration Level）
- 理解增量交付模式
- 根因分析 vs 快速修補的區別（agent 偏向快速修補）
- 早期識別被誤解的需求——agent 不會主動質疑需求的正確性
長期可維護性層（Codebase Lifetime）
- 測試設計與測試放置的策略
- 程式碼模組化與可重用性
- 識別不必要的複雜度（agent 傾向加複雜度，不傾向減少）
- Design pattern 辨識和依賴結構
個人護欄：code review 紀律、判斷何時中斷 session、結對編程、對「看起來快得可疑的解法」保持懷疑。
組織護欄：Sonarqube / Codescene 的程式碼品質監控、pre-commit hooks、記錄「出錯日誌」（documented go-wrong logs）、自訂規則配置、建立心理安全的文化讓人不怕舉報 AI 問題。
Vol.35 更新：問題從「人該站哪裡」變成「人審得完嗎」
來源：Technology Radar Vol.35（2026-11-04）。完整判讀見 Vol.35 判讀。
Vol.35 把「Human judgment」列為四大主題之一，並且對本篇的核心共識提出了最直接的反駁——站位對了不等於審查有效。
Caution：Human-in-the-loop theater〔人在迴圈劇場〕
Thoughtworks 的定義：
「把人留在 agent 的迴圈裡，卻只是一個空的核准步驟，而不是真正的檢查——人核准了他其實沒有能力評估的動作、prompt 或 diff。」
這一刀切在本篇整個論述的要害上。Morris 的三種站位假設了 in-the-loop 代表「真的在審」；Vol.35 指出在平行跑多個 agent session、加上整夜無人值守建置之後，in-the-loop 很容易退化成一個橡皮圖章——形式上人還在迴圈裡，實質上已經 out of the loop，而且因為有核准紀錄，連「誰該負責」都被模糊掉了。
Caution：Meat proxy〔人肉代理〕
同一個病的另一種型態：把未經閱讀與查證的 LLM 輸出直接轉給同事。Thoughtworks 點明兩者的差別——human-in-the-loop theater 假的是核准，meat proxy 假的是作者身分。 KDE 的 AI 指引草案把它濃縮為一句「Don’t be a meat proxy」。
這同時給了 Böckeler 技能清單一個新項目：願意承擔自己送出之內容的責任，是 agent 時代第一條職業倫理，而不是技術能力。
Trial：Risk-tiered human oversight〔風險分級的人工監督〕
這是 Thoughtworks 給出的正面解方，也是對 Morris 框架最實用的補強。核心論點：所有變更都用同等強度審查，必然導致 human-in-the-loop theater——因為人的注意力是固定的，攤平就等於攤薄。做法是按「可能造成的損害」分三層：
| 層級 | 處理方式 |
|---|---|
| 最危險或最難回復 | 由人親手改，不是審查 agent 的版本 |
| 中風險 | 人工審查 |
| 低風險 | coding agent 經 CI 自動合併 |
分層的兩個判斷策略：codebase zones（特定檔案或目錄一律提高審查強度，確定性）與 LLM 變更分類（會出錯，非確定性）。Meta 公開的流程兩者並用。
這對 Lässig 的控制論框架是一個直接的實例化：風險分級就是 Ashby 意義下的 attenuation——不是讓人處理更多多樣性，而是減少需要人處理的多樣性，把固定的注意力配置到真正會痛的地方。
Trial：Unattended overnight agentic builds〔無人值守的整夜建置〕
下班前交付一個 feature 等級的任務，隔天早上審結果。值得注意的是 Thoughtworks 強調它不需要 agent 群，通常一個就夠，而且它的四個前置條件（沙箱執行、事前規格、回饋感測器、經過測試的 harness）才是真正的價值——「一整夜的產出可能大到無法逐行審查」這句話，正是 risk-tiered oversight 存在的理由。
對本篇結論的修正：原文說工程師的角色從「寫程式碼的人」轉為「設計和維護讓 AI 可靠工作之系統的人」。Vol.35 加上一個條件——這個系統必須包含「人的審查量能」這個有限資源的配置方案。沒有分級，on-the-loop 會在規模化的第一天就退化成劇場。
主張 vs 可佐證
- 可佐證：Böckeler 的技能清單來自 Thoughtworks 工程師的直接觀察；Morris 和 Lässig 的框架都有明確的知識系譜（控制論有完整學術基礎）；「out of the loop 品質會螺旋下降」被多個 Thoughtworks 案例和 arXiv 研究印證（多 agent 錯誤放大效應）。
- 主張：Agentic Flywheel 的自我改進特性是預測性框架，目前缺乏公開的大規模實施數據；控制論框架（VSM）在 AI agent 管理的有效性是類比，未經系統性驗證；「哪些技能最先被取代」的時間線是工程意見，不是研究結論。
- 收斂結論：三個框架指向同一個結論：工程師的角色從「寫程式碼的人」演變為「設計和維護讓 AI 可靠工作之系統的人」。 這不是降級，是工程重心的轉移——從操作技能（coding）轉向系統設計技能（harness design, context curation, quality sensing）。
🕒 更新紀錄
- 2026-11-09 — 補 Vol.35（2026-11-04）：human judgment 成為雷達四大主題；新增 human-in-the-loop theater、meat proxy 兩個 Caution 與 risk-tiered human oversight、unattended overnight agentic builds 兩個 Trial 的對照，並據此修正本篇結論。
- 2026-07-04 — 建立本篇。
來源：
- Humans and Agents in Software Engineering Loops — Kief Morris (Thoughtworks), 2026-03-04
- Cybernetics and the “human-on-the-loop” in agentic coding — Dirk Lässig (Thoughtworks), 2026-04-20
- The role of developer skills in agentic coding — Birgitta Böckeler (Thoughtworks), 2025-03-25