到底什麼是 Loop Engineer？以及如何真正落實設定
昨天凌晨一點左右，我們的程式庫突然湧入了一堆 PR（Pull Request）。這並不是因為我們的團隊熬夜加班。
這些 PR 來自不同的 Agent 迴圈：Agent 自動發現問題、領取任務、驗證變更，並在沒有人手動下達指令的情況下開啟 PR。
我們在 @SuperDesignDev 還有一個 SEO 迴圈，每天能產出 20 到 40 篇高品質的網頁。這些網頁即使我完全不插手，也已經在為公司帶來流量了。
展開畫面重點畫面以手寫字體呈現了一個系統架構概念圖，主要內容如下：
左側標示「You prompt agent」，並有一箭頭指向右側的「trigger agent」。
右側的「trigger agent」上方有多個箭頭匯入，分別標註了觸發來源：
- 「Cron job」（定時任務）
- 「Agent」
- 「Webhooks」
- 「???」（代表其他未知的觸發方式）
這就是我想談的轉變：Loop Engineering（迴圈工程）：
別再把 Agent 當成需要你手動下達 Prompt 的工具，開始設計一套能夠自行決定要做什麼、執行任務、驗證結果，並隨時間不斷改進的系統。
一個好的迴圈不只是產生輸出，它會建立一套回饋系統，讓系統運作得越久就越有價值。
我想解釋我們是如何設定這些機制，讓它們產生複利效應。
Agent harness 有兩個嵌套層級
展開畫面重點圖片為手繪風格的流程架構圖，背景為黑色。上方區塊列出了系統的核心組件：
Orchestration/workflow（編排/工作流）
State & memory (Task)（狀態與記憶（任務））
init / Work Verification（初始化/工作驗證）
Skills（技能）
...（省略符號）
下方區塊標示為「Execution」（執行），並搭配一個像素風格的圖示與一個長方形的輸入框/狀態框。圖中透過箭頭線條標示了系統內部的循環與資料流向。
「Agent harness」這個詞聽起來很模糊，因為它幾乎涵蓋了模型本身以外的所有東西。
但我發現將其拆分為兩個層級會更有幫助：Agent 迴圈（Agent loop）+ 外層迴圈（Outer loop）。
Agent 迴圈：協助 Agent 妥善完成特定任務
內層迴圈就是大家熟悉的 Agent 執行環境（runtime），例如 Claude Code、Codex 等。
你給 Agent 一個任務，它會讀取相關的 context、使用工具、執行工作、檢查結果，並持續運作直到任務完成。這也是目前大多數 Agent 優化集中的地方：更好的 context 與指令、skill 與工具定義、任務拆解、工具使用。
這一層試圖回答的問題是：
給定這個任務，我們該如何協助 Agent 可靠地完成它？
但這仍然依賴於某個人來決定「這是一個值得做的任務」。這就是外層迴圈發揮作用的地方。
外層迴圈：決定接下來該做什麼
外層迴圈圍繞著 Agent 執行環境，它負責處理以下事項：
什麼事件應該觸發 Agent
跨 session 應該保留哪些狀態
不同 Agent 如何共享資訊
如何監控成果
系統如何隨時間變得更好
這一層試圖回答的問題是：
Agent 接下來應該做什麼，系統又該如何從結果中學習？
這就是我們所說的 Loop Engineering。Loop Engineer 不只是為 Agent 撰寫 Prompt，他們是在設計一個環境，讓 Agent 能夠持續進行以下步驟：
發現值得處理的事項
進行調查
採取行動
記錄發生了什麼
驗證是否有效
利用該結果決定下一步
Agent 迴圈協助 Agent 執行，而外層迴圈則協助系統進行決策、學習並產生複利。
當迴圈共享 artifact 與 log 時，就會產生複利
展開畫面重點圖片呈現了一個以「/signals」為核心的營運流程架構圖，包含四個主要區塊：
Support（客戶支援）：
- 每 30 分鐘執行一次循環：回應支援票務（Respond support tickets）→ 記錄摩擦點與想法（Log frictions & ideas）→ 監控效能（Monitor performance）。
- 產生訊號：5 人詢問如何匯出（5 people asked how to export）。
Product growth（產品成長）：
- 每 2 小時執行一次循環：分析產品數據與訊號（Product analytics + signal）→ 優先處理實驗（Prioritise experiments）→ 交付 PR（Deliver PR）。
SEO（搜尋引擎優化）：
- 每天早上 9 點執行循環：分析數據（Analyse data）→ 研究主題（Research topics）→ 發布 SEO 頁面（Publish SEO pages）。
- 產生訊號：/ai-wireframe-generator 獲得點擊但轉換率不佳（/ai-wireframe-generator get clicks but bad conversion）。
Ads（廣告投放）：
- 每天早上 9 點執行循環：分析數據（Analyse data）→ 更新策略（Update strategy）→ 調整廣告活動（Adjust ads campaign）。
- 產生訊號：/lovable-alternative CPC 表現良好（/lovable-alternative CPC is good）。
中心樞紐為「/signals」，匯集了來自各處的 Markdown 檔案（exporttoohidden.md、conversion_gap.md），並將這些訊號反饋至產品成長與廣告策略中。
單一迴圈很有用，但真正有趣的是當多個迴圈可以互相學習時。
在我們公司，我們在支援（Support）、SEO、產品成長（Product growth）、廣告（Ads）等領域都有迴圈。每個迴圈都有自己的觸發條件、工作流程、工具與目標。
但它們都會寫入同一個共享的 artifact 系統。
例如，支援迴圈可能會注意到有五個人詢問如何匯出資料。
它會建立一個訊號（signal）：/export-too-hidden.md
`markdown
kind: signal
title: "Export gated behind Pro is a recurring friction / conversion point"
description: "Pricing friction, spawned (free, freq 5): users hit the export-is-Pro-only paywall (~769 hits/580 users), the cleanest Free->Pro trigger. Upgrade gate shipped."
category: friction
frequency: 6
segments: [free]
tags: [feedback, friction, pricing, export, conversion]
-----
Detail
...
Timeline
...
`
同時，SEO 迴圈可能會注意到某個頁面流量很高，但轉換率很差。
它會建立另一個訊號：/conversion-gap-ai-wireframe-generator.md
接著，產品成長迴圈可以同時讀取這兩個訊號以及產品分析資料。它可能會得出結論：匯出功能的問題比原始分析資料顯示的更嚴重；或者它可能會發現，透過特定 SEO 頁面進來的使用者，正遇到與支援團隊觀察到的相同的產品阻礙。
廣告迴圈可能會發現某個關鍵字點擊率很高，但缺乏對應的自然搜尋內容。這可以直接回饋給 SEO 迴圈。
這就是讓系統產生複利的原因。這些迴圈不再是孤立的自動化程式。
它們是在一個共享的知識庫上運作，這個知識庫記錄了企業正在學習的一切。
共享日誌（Brian）
展開畫面重點圖片呈現了一個名為「File structure」的檔案結構規劃，內容包含三個主要區塊：
Artifacts（紅褐色區塊）：
- Docs/
- Signals/
- Tasks/
- Contents/
- campaign/
- ...
Loop contract（綠色區塊，外框包覆）：
- G…
