Loop Engineering
Loop Engineering（迴圈工程）是把「人反覆提示 AI」改成「系統反覆提示、檢查與修正 AI」的工作流設計。bnext 文章把它定位成 AI coding 從 prompt 操作轉向 loop 設計的分水嶺：工程師不只寫提示詞，而是設計會自己尋找工作、交給 agent、驗證結果、記錄狀態並決定下一步的閉環。
與 prompt engineering 的差異
Prompt engineering 聚焦單次輸出品質；Loop Engineering 聚焦可重複、可驗證、可持續運轉的 feedback loop。
- prompt：給 agent 一道指令。
- loop：給 agent 一份可反覆推進的工作。
- prompt 工程師：自己讀回覆、補下一段指令。
- loop 工程師：設計 discover / plan / execute / verify / iterate 的系統。
這與 dynamic-agent-workflows、harness-engineering-for-ai-coding、agent-trace-observability 形成同一條脈絡：AI coding 的關鍵不再只是模型回答，而是模型如何被環境、工具、測試與狀態檔約束。
2026-06-22 的 bnext Codex record and replay 文章，直接示範「錄一次操作 → 轉成技能 → 重播執行」，把 loop engineering 從抽象流程落到 UI / workflow capture 層，與 aiark-loop-engineering 的 watch / ingest / verify / synthesize 閉環互相呼應。
BusinessNext 2026-07-22 的 Claude Cowork「Record a skill」是同一種 loop input 的跨產品案例：人類操作並口述一次，系統把示範整理成可重複呼叫的 Skill。它降低流程建模門檻，但不能取代 agent-skills 的變體測試、權限檢查、失敗分支與驗收 gate；「能錄下來」不等於「能安全重播」。
2026-06-05 的 aihao-blog Codex App 文章補上一個更偏 GUI 的輸入面：appshots 可以把游標所在視窗、畫面外文字與介面脈絡一起塞進 Codex，讓 loop 的上下文不再只靠 CLI 複製貼上。這對 dynamic-agent-workflows 與 agent-trace-observability 都是實用補強。
Bnext 的提示詞除錯文章把 loop 的前半段拉回到評估清單、結構整理與輸出契約，和 prompt-debugging-eval-checklist、model-specific-system-prompts 互相呼應。
2026-04-15 的 bnext 文章把 loop engineering 拉回到「Context」與溝通：先讓 AI 跟人對齊目標、寫設計文件、定義完成條件，再讓 AI 自己測試與修 bug。這補強了 dynamic-agent-workflows 與 prompt-debugging-eval-checklist 的交界，也說明 loop 不只是工具迴圈，更是溝通與驗證迴圈。
決策分層
Rex 雷 的實戰貼文補了一個很實用的層次：不是所有交互都應該回到人類手上。更好的做法是先把操作分成三層：
- 自動：讀檔、搜尋、看 log、跑型別檢查這類低風險操作。
- 回報：技術分析、修改計畫、風險清單、資料流與 UI flow 設計。
- 確認：schema、migration、production deploy、刪資料與權限模型等高風險動作。
這個分層與 loop engineering 的關係在於：loop 不只是執行 / 驗證，還要在一開始就定義哪些節點可以自動前進，哪些節點必須停下來問。這能把「即時決策」變成「預先規則」，降低決策疲勞，也讓 loop 更適合長時間協作。
Agentic Engineering Patterns 的內層品質迴圈
AIHAO 2026-07-25 導讀 Simon Willison 的 guide，將 loop 的內層驗證具體化：先跑既有測試、用 red/green TDD、再做手動探索；遇到 agent 產出的認知債，就用 walkthrough 或互動式說明補回理解；最後以小 PR、測試紀錄與截圖等 evidence 交給 review。這些步驟把「一直做下去」的 loop 接回「知道什麼算完成」的 harness-engineering-for-ai-coding，也避免把 code generation 速度誤當成品質。
來源同時提供反過度自動化的限制：subagent 優先用於保護頂層 context 與高 token 探索，不必把每個簡單任務拆成代理群；未經本人執行、理解與驗證的 agent PR，不應推進到下一個 loop 狀態。這與 agentic-engineering-patterns、ai-code-validation-bottleneck 共同構成「產出便宜、證據不能省」的品質 gate。
六個組件
文章整理的 loop building blocks：
- Automations：週期觸發、遇到條件才回報，是 loop 的心跳。
- Worktree：用
git worktree隔離多個 agent 的改動，避免檔案互撞。 - Skills：用
SKILL.md保存專案慣例、建置步驟與事故知識。 - Connectors / MCP：讓 agent 能接任務系統、資料庫、測試環境與協作工具。
- Sub-agents：讓生成者與驗證者分離，避免同一個 agent 自我說服。
- Memory / state：用 markdown、看板或其他外部狀態保存跨輪進度。
最小可行 loop
文章主張不要一開始就堆代理群，先用四個零件：
- 一個 automation：照週期或條件觸發。
- 一個 skill：保存每輪都需要的專案脈絡。
- 一個 state file：記錄已做與待做事項。
- 一道 gate：測試、型別檢查、build 或其他客觀關卡。
實作順序是：先讓一次手動執行穩定，再變成 skill，再包成 loop，最後才排程。這與 ponytail-loop-review-gate 對 aiark-loop-engineering 的約束一致：先跑通、留下 evidence，再抽象化。
BusinessNext 2026-08-05 的 Gemini Spark 實測提供一個個人工作流版本：先讀取 Gmail／Calendar 的脈絡，再建立任務與排程，於背景執行文件修改或電子報整理，最後把結果寄回並保留人工檢查點。它把最小 loop 的 automation、skill、state 與 gate 具體化，但三個產品情境仍是媒體操作觀察，不是獨立效能 benchmark。
可重用的邊界是先把低風險、可還原、規則明確的工作排程化，驗證資料範圍、輸出、通知與暫停／接手，再擴大到高影響動作；若只是在背景重複產出而沒有停止條件，就只是 slop in a loop。
Claude Cowork Scheduled Tasks：排程不是 runtime 或驗證本身
Anthropic Help Center 將 Claude Cowork Scheduled tasks 定義為可依週期或按需執行的任務：每次執行是獨立的 Cowork session，可使用 connectors、skills 與 installed plugins；遠端排程即使電腦睡眠或 Claude Desktop 關閉也能運作。這補強 loop 的 persistent task → scheduled trigger → independent session → result review，但排程只負責觸發，不等於結果已通過驗證。
同一份官方文件也把資料位置變成 runtime gate：一般 scheduled task 使用 Claude 帳號裡的檔案與 connectors，不能綁定電腦資料夾；手動設定若需要本機檔案或應用程式，則只在本機執行。可重用的設計是先決定 context 放在遠端帳號／connector 還是 localhost，再配置低風險、可回查的輸出與人工 review；不要把「電腦關著也會跑」當成所有資料情境都成立。
Gemini Spark 的 2026-08-06 週報實測提供另一個最小 loop：以 Gmail／Calendar／Drive 作為 context，固定產出含進度與風險欄位的 HTML 報告，按週期觸發後寄給指定收件者，再由人核對內容與名單。這個案例把 automation 的成功條件從「任務有跑」改成「資料範圍、輸出契約、收件者與人工停止點都可驗證」；因此排程只能負責觸發，不能取代 harness-engineering-for-ai-coding 的檢查與 agent-experience 的交付狀態。
AIHAO 駕馭工程第 6 篇把「外層 loop」定義得更窄：只有在任務超過單一 context、需要平行處理多張 ticket，或必須由 webhook / CI / cron 自動觸發時，才需要把迴圈推到 agent session 之外。Ralph、Symphony、Cron 的共同點不是 fancy orchestration，而是把進度搬到磁碟或控制平面：git history、progress.txt、prd.json、看板狀態、排程紀錄。這補強 harness-engineering-for-ai-coding 的邊界：外層 loop 負責重啟、分派與持續推進，但不能取代測試、typecheck、review 與人類審核。
從終點反向拆解 Agent 工作流
BusinessNext 對非工程師建立 Agent 的訪談，補上 loop 在任務建模前的最小步驟：先定義最終成果，再逐層反推每一步需要的輸入；每個 Output 都要能成為下一步的 Input。這種反向拆解把 agent-skills 從一組提示詞推進成可觀測的流程節點，也能讓 agent-ready-data-governance 具體回答「哪份資料在何時交給哪個步驟」。
驗證不能只看最後結果。若面試排程出錯，要回查候選人日期格式、資料比對與行事曆操作哪一個斷點漏了檢查，再把檢核指令寫回 Skill。採用前也要做 ROI gate：以每月執行次數乘每次省下時間，對照整理與維護 Skill 的成本；沒有重複頻率或節省效益的任務，不值得被 loop 化。
招募流程的採用迴圈
凱鈿招募案例把 loop 從系統執行延伸到組織採用：流程兩週內可由非工程師組裝完成，但團隊真正接受並使用系統又花了一個月。原因不是模型不會做，而是職缺情境的輸入變體，以及新流程打散了資深 HR 原有的操作記憶。可重用的最小迴圈是 選一個有幫助的節點 → 新舊流程並行 → 觀察錯寄、未使用與卡點 → 會議回饋 → 修正 Skill／介面 → 再擴大；這比一次要求全員採用所有節點更容易留下有效 feedback。
這個案例也把 loop 的停止條件分成技術與人類兩層：寄信、排會議、履歷初審可由 AI 加速，但候選人關係、適配判斷與薪資協商仍需由人接手。若自動化讓團隊失去信任或破壞必要的人際連結，即使單一節點成功，也不代表整條 workflow 應繼續擴張；這連到 ai-native-enterprise-governance 的 owner／人工決策 gate 與 agent-experience 的可用性驗收。
Claude Code 官方的四種 loop
BusinessNext 對 Claude Code 官方方法論的整理，將 loop 依「觸發方式、停止條件、內建工具與適用任務」分成四類。這補上本頁原本偏向建構零件的分類：先決定人類要交出去的是一步動作、停止條件、觸發時機，還是整段持續工作的提示，再選擇自動化程度。
- 回合制（turn-based）：由使用者 prompt 觸發，Claude 自己判斷完成或等待補充；適合短期、非例行任務。把人工驗收步驟寫進 agent-skills，可降低來回提示輪數。
- 目標式（goal-based）：用
/goal設定可驗證的終態與回合上限，由 evaluator model 依對話中的測試輸出或分數報告判斷是否達標；適合複雜但成功標準清楚的任務。這與 harness-engineering-for-ai-coding 的 Goal / Outcome gate 直接相連。 - 時間式（time-based）：用
/loop按固定間隔重跑，或用/schedule把任務交給雲端排程；適合定期檢查 PR、CI 或外部系統。排程不是驗證本身，仍要搭配可否決壞輸出的 gate。 - 主動式（agentic）：由事件或排程觸發，結合
/schedule、/goal、skill、auto mode 與 dynamic workflows，讓多個子代理分類、修改與審查持續流動；適合 bug、issue、遷移與依賴升級等定義明確的工作串流。它擴大了 dynamic-agent-workflows 的實例，但不代表每個任務都值得多代理化。
這個分類也把成本與安全邊界說清楚：沒有明確驗收標準、只是一次性的工作，或涉及敏感資料與對外發布時，先用回合制 loop；重複性高且能自動驗證時，才逐步升級到目標式、時間式或主動式。/goal 的 evaluator 只看 transcript 中的證據，不會自行讀檔或執行測試；auto mode 也不取代高風險動作的人類審查。因此 loop 的停止條件、權限邊界與 token budget 必須一起設計，而不是把「讓 agent 一直跑」當成完成。
採用條件
Loop 只有在以下條件同時成立時才划算：
- 任務會重複發生。
- 有自動化 gate 可以否決壞輸出。
- agent 能執行並觀察自己改動的程式。
- 有硬性停止點，例如預算、次數、時間上限或明確完成字串。
- 不可逆動作前仍有人類審核。
如果缺少這些條件，手動 prompt 反而更便宜、更可控。
部署是 vibe coding 的最後一道 gate
BusinessNext 2026-07-17 對 ChatGPT Sites 的示範補上 loop 的最後一哩：把 HTML 或由對話產出的 prototype 部署成可分享網站，不應被視為「產碼完成」的自動延伸，而是要有獨立的發布 gate。文章先把網站設成私人瀏覽，再檢查小孩出生月份等個資，提供維持私人、指定分享或移除敏感資訊後公開三種路徑；上線後仍可透過對話修改內容、分享對象、標題與自訂網域。
可重用的最小規則是：先 prototype、再私有部署、做機敏資訊與用途檢查，最後才公開；不涉及登入、金流、信用卡資料或持續變動後端的展示型與輕量互動型頁面，才適合用這種低摩擦部署。這把 cloud-agent-vs-localhost-agent 的環境選型、agent-sandbox-architecture 的風險邊界與 ai-code-validation-bottleneck 的驗證責任接到同一個發布流程：部署便利不能取代資料清理、權限設定與人工確認。
風險
文章列出三個 loop 不會自動解決的問題：
- Ralph Wiggum loop：agent 提早宣告完成，loop 在半成品上退出。
- Comprehension debt：系統快速交付了團隊沒理解的程式碼，日後除錯成本上升。
- Cognitive surrender：人把判斷權交給 loop，停止形成自己的工程判斷。
因此 loop 的價值不在「不用當工程師」，而在把工程師的槓桿點從逐句提示提高到設計、驗證與審查閉環。
BusinessNext 的 Claude Code 管理文把這個風險落到組織層：產碼速度上升後，loop 若沒有 spec、review gate 與整合狀態，很容易變成多人各自用 agent 快速產出、卻沒有人理解整體的孤島。這補上 ai-code-validation-bottleneck：loop 的價值不只是讓 agent 跑更快，而是讓驗證與協調也跟著進入閉環。
由決策到可驗收交付的五站 loop
BusinessNext 2026-07-29 拆解 Matt Pocock 的五站工作流：grill-with-docs 把決策樹、名詞表與 ADR 外化，to-spec 把共識寫成不綁死路徑的規格，to-tickets 用 vertical slice 拆成可獨立驗收的任務，implement 先做 TDD，再由兩個不同角度的 reviewer 檢查規範與規格忠實度。Wayfinder 進一步把超出單一 context 的工作放進可追蹤的研究、拷問、原型與 task 子票。
這個 pattern 的價值不在「五站」本身，而在每一站都留下下一站可檢查的 artifact：決策、規格、垂直切片、紅綠測試與 review evidence。它補強 harness-engineering-for-ai-coding 的 sensors 與 ai-code-validation-bottleneck 的驗證責任；若工作很小、沒有重複性或沒有客觀 gate，直接手動處理會更便宜。
Graph Engineering：把 loop 組成可恢復的圖
BusinessNext 2026-07-28 的 Graph Engineering 導讀把 loop 的單一工作流再往外組織：節點各做一件可測試的事，交棒處明確定義輸出與下一步，獨立狀態檔記錄進度、成本、產出與來源。沒有依賴的節點可平行執行，失敗時只重做壞掉的節點，長任務也能暫停等待人核准或換模型接手。這補強 loop 的恢復性與預算 gate，但術語仍非業界標準；小型一次性任務不應為此增加圖編排層。
因此可把三者簡化成：harness-engineering-for-ai-coding 提供 feedback 與否決點，loop 負責持續推進單項工作，graph-engineering 負責管理多個 loop 的依賴、交棒與恢復。AI Ark 目前的 queue、raw、hash、wikilink 與 index evidence 已足以支撐最小 loop，先不要因為 Graph 名詞出現就擴建 workflow engine。
Persistent thread、heartbeat 與 Goal loop
BusinessNext 對 Jason Liu Codex 工作流的整理，補上一個以同一條對話串為狀態容器的 loop pattern：thread automation 以固定頻率或條件喚醒原有 thread，讓它持續處理 pull request、連接器與日常追蹤，而不是每次都建立沒有記憶的新 session。Goal 模式則把可驗證的終態、跨數小時或數天的執行與工作日誌接在一起；可重用的最小設計是 persistent state + wake-up trigger + observable completion condition，不是「讓 agent 一直跑」。
這種 loop 仍要設喚醒頻率、無更新時的低噪音回報、預算與停止條件；高風險的對外行動要在 agent-sandbox-architecture、權限政策與人工確認 gate 內執行。來源中的「幕僚長對話串」是產品示範與個人方法，不是普遍成功率證據；對 AI Ark 而言，它可作為 aiark-loop-engineering 的類比，但目前 JSONL queue、raw hash 與 wikilink verification 已足夠，不需要新增排程框架。
Gemini Spark：背景 loop 的產品化邊界
BusinessNext 2026-07-30 對 Gemini Spark 的整理，提供一個非 coding 的 background loop 案例：任務先定義目標，排程負責固定時間或事件觸發，技能負責工具與步驟，工作面板則保存進度、檔案與可接手狀態。使用者可暫停或繼續排程，遠端瀏覽器任務也能在中途交還控制權；這把 persistent state + wake-up trigger + observable completion condition + human takeover 延伸到個人助理場景。
這個案例也保留兩條 loop gate：產品報導提到同時執行數量與運算量上限，代表背景工作需要容量與停止條件；Spark 可讀寫多種 Workspace 與第三方資料，代表排程不等於授權。可重用的設計是先固定資料範圍、進度訊號、接手點與失敗處理，再決定是否讓 loop 長時間運轉，而不是把「24/7」當成品質保證。
Claude Cowork：非 coding 的本機交付 loop
BusinessNext 2026-07-30 的 Claude Cowork 五種場景，把 loop 的最小形狀落到一般知識工作：先給定資料夾與目標，查看執行計畫，針對讀寫／刪除／移動提出授權，再讓 agent 在本機處理檔案，最後檢查報告、簡報、圖表或 Excel 等交付物。這可簡化成 goal → plan → permission → execute → artifact check，其中 permission 與 artifact check 都不能被「自動完成」省略。
這個案例補足 coding loop 之外的資料工作 loop：PDF、CSV、收據與雲端同步資料都可能含有機敏內容，且檔案移動、刪除與對外發布具有不同風險。可重用的判準是先縮小資料範圍、固定輸出契約與停止點，再把真正重複的步驟抽成 agent-skills；不要把一次性的產品示範直接擴成新的 orchestration layer。
長時程 loop：先刪 scaffold，再把驗證做成回饋
BusinessNext 2026-07-30 整理 Boris Cherny 對 Claude Code 的公開說法：長時程 agent 不應靠一份越寫越長的 prompt 維持秩序，而應給它足夠困難、但有可檢查成果的任務，讓它透過執行結果、截圖或其他工具自行驗證。這把 loop 的核心從「更多指令」移到 可觀察中間產物 + 自我檢查 + 明確停止條件；長時間執行本身不是完成證據。
實作上可沿用三步：先刪掉未證明有效的 prompt／skill／hook，照常跑一組固定任務，只有在重複失敗時回填最小規則；再用 harness-engineering-for-ai-coding 的 sensors、eval-is-spec 的 task-level eval 與 agentic-ai-cost-management 的預算／重試指標判斷是否保留。對高風險或像素級驗證，仍需 deterministic check、人工審查與可中止的 session，不能把媒體整理中的長時程案例當成普遍可靠性證據。
Karpathy 的 3D world 實驗：迴圈需要可觀察回饋
BusinessNext 2026-08-03 整理 Karpathy 讓 Claude Opus 5 以 1M token 預算、three.js 與 procedural generation 建立可探索《魔戒》世界的實驗。它把長時程 loop 的成功條件說得很具體：模型可以持續寫程式、維持大量幾何與動畫結構，但若不能直接看影片或操作成品，就只能靠分段截圖反推錯誤；這個回饋迴圈慢且容易留下粗糙結果。
因此，對互動或視覺產物，loop 的 gate 不應只檢查程式是否生成或頁面是否啟動，還要提供可重播的 render、截圖、互動操作與結果比對。這補強 harness-engineering-for-ai-coding 的 sensors，也把 agent-experience 的「agent 能否取得可行動觀察」接回 generative-media-agent-workflow；成本便宜不等於驗證便宜。
Wayfinder：把大型 loop 的未知決策外部化
Wayfinder 把大型、模糊且超過單一 context 的工作先轉成決策地圖，而不是直接把整包需求交給 agent。destination 定義終點，fog of war 收納尚未釐清的決策，frontier 只允許未被阻塞的票前進；每解完一張票就把摘要與證據寫回地圖，再把清楚的決策轉成規格與實作 tickets。
這是 agent-skills 與 harness-engineering-for-ai-coding 的交界：skill 負責固定 map／resolve／specify 的行為，harness 負責要求真人參與、每 session 一張票、研究與原型的例外，以及停止前的 evidence。對 graph-engineering 而言，Wayfinder 仍是最小的依賴圖，不足以證明需要新增 workflow engine；小型或路徑已知的任務直接做，才符合 ponytail-loop-review-gate。
Hex：資料 agent 的 feedback loop
Hex 的資料 agent 顯示，長時程 loop 的難點不是把 LLM 放進工具迴圈，而是讓 agent 在探索、驗證與停止之間取得可用訊號。Context Studio 先由 LLM 標記可疑答案，再由資料團隊修 guide、semantic model 與 warehouse 說明；Metric City 則把狀態帶過 90 個模擬回合，測 agent 是否主動整理可取回的 wiki。這補強 agent-trace-observability 與 eval-is-spec：loop 的成果要包含中間證據、失敗分群、context 更新與後續回合的改善，不只是最後一句答案。
這個案例也保留 ponytail 邊界：Temporal、context agent 或更大的 orchestration 只有在單一回合、單一 context 或人工維護真的成為瓶頸時才值得抽象化；先用明確停止條件、可觀察 artifact、人工資料 owner 與小型目標型 eval 跑通，再擴大外層 loop。
設計 artifact 作為 coding loop 的輸入
Claude Code /design 的早期預覽把 coding loop 的輸入從文字需求往前推到可編輯的 UI artifact：先產生多個設計候選，人類挑選與修改，再交給 agent 實作。這能把「我想要的介面」變成可回看、可交接與可比較的中間狀態，連結 agent-experience、generative-ui 與 harness-engineering-for-ai-coding 的 feedback surface。
最小 loop 仍是 design → select/edit → implement → render／互動檢查 → revise；畫板若不能保存、載入既有 design system，或沒有對照實作的檢查，就只是較漂亮的 prompt。來源尚未證明 /design 已能進入 repository／PR 或自動修正偏差，因此先把它視為低成本的 pre-implementation artifact，不新增設計編排層。
Problem-first prompting 與 empirical loop
DHH 對 agent coding 的轉折可抽象成一個更短的 loop：描述問題／目標 → 讓 agent 提出路徑 → 使用或執行產物 → 以差異評估與驗證回填需求。Boris Cherny 的訪談也把這件事寫成先刪除未證明必要的 prompt／skill／hook，觀察重複失敗後才加回最小規則。這不是鼓勵省略 spec，而是把規格拆成目標、guardrails、exit criteria 與可觀察 evidence，避免把上一代模型的實作路徑硬編進目前 harness。
這個 loop 仍有兩條停止線：在新問題或低風險 prototype 上，可先讓 agent 探索多個候選；在既有大型 codebase、security-critical system 或對外發布前，必須把 codebase understanding、測試、架構整合與人類決策重新放回 gate。DHH 的 Basecamp 5 案例說明「每個 PR 看起來合理」不等於「整個 loop 的狀態可交付」。
對 AI Ark wiki 的意義
這篇文章補強 aiark-loop-engineering 的外部來源基礎：目前 wiki 的 watch / ingest / verify / synthesize 正是在用 state file、manual gate、raw source、queue record 與 log 形成最小 loop。ihower 這篇則把 harness 和 loop 放在同一張圖上，幫我們補上一層「回饋面 vs 迴圈面」的拆解。Gary Chen 的 cross-model review 又補上一個更具體的操作層：不是只靠人類提醒要 review，而是用 stop hook、marker 和同一個 reviewer session 把 review 強制寫進流程，讓 loop 可以持續收斂而不是每次冷啟動。^[raw/transcripts/garychen-claude-codex-auto-review-2026-06-27.md] 下一步不是立刻上 cron，而是繼續累積 queue evidence，等 scoring noise 與重複操作真的出現後再抽象化。