wtf is Loop Engineer & how to setup for real
三句話摘要
如何設計能自動觸發、持續運行並相互複利的 AI Agent Loop 系統（Loop Engineering），讓 Agent 在無人介入的情況下完成跨 Session 的長期任務。 --- Loop Engineering 的本質是設計一套自動觸發、共享狀態、相互餵養信號的 Agent 環境，讓多個 Loop 複利運行，而非不斷手動 Prompt 單一 Agent。 Loop Engineering 是「環境設計」而非「Prompt 設計」
重點整理
重點- 1
Loop Engineering 是「環境設計」而非「Prompt 設計」
- 2
傳統做法是優化單次 Prompt 讓 Agent 把一個任務做好；Loop Engineering 則是設計外部環境，讓系統決定「要做什麼」並自動喚醒 Agent，使其不需人工介入即可持續輸出。
- 3
共享檔案系統是多 Loop 複利的核心
- 4
各個 Loop（支援、SEO、廣告、產品）讀寫同一份 `signals/` 資料夾，彼此的發現能交叉餵給其他 Loop，例如廣告發現高點擊關鍵字後，SEO Loop 會自動優先製作對應的有機內容。
- 5
Codebase 必須具備三個特性才能支援平行 Agent
- 6
程式碼庫要「可讀（Legible）」讓 Agent 知道改哪裡、「可執行（Executable）」讓 Agent 用一個腳本就能啟動 Dev Server、「可驗證（Verifiable）」讓 Agent 能測試並記錄結果，三者缺一不可。
- 7
每個 Loop 需要一份「契約（Contract）README」
- 8
Contract 包含 Loop 的目標、工作流程邊界、待辦 Backlog 與時間軸日誌，Agent 每次被觸發時先讀此契約，理解上次停在哪裡再繼續，確保跨 Session 的狀態連貫性。
- 9
--
實用技巧與重點
乾貨- 數字與規模
- SEO Loop 每天產出 20–40 頁，已持續運行 2 天
- 支援 Loop 每 30 分鐘觸發一次（Cron Job）
- Context Window 標稱 1M token，實際有效約 128k–200k
- OpenAI 的 `agents.md` 控制在約 100 行，作為 Agent 入口索引
- 工具與平台
- Claude Code、Codex（Agent Runtime）
- MCP（工具整合協議）
- Playwright CLI（瀏覽器自動化 + 影片錄製）
- Intercom（客服票）、Stripe（訂閱付款查詢）、Supabase（後端日誌）
- GitHub PR 附件（Playwright 影片）
- Worktree（Git 工作樹，支援多 Agent 平行互不衝突）
- 核心元件四項
- Triggers（Cron Job / Webhook / 另一個 Agent）
- File Structure Design（Artifact 資料夾 + Loop Contract）
- Tools & Connectors（MCP 技能集）
- Parallel-safe Codebase（Worktree + 驗證腳本）
- 檔案系統三層抽象
- `artifacts/`：各 Loop 的輸出物（docs、signals、tasks、tickets），每個 Artifact 類型有自己的 README 定義 Schema
- Loop Contract：每個 Loop 一份 README，含目標、工作流、Backlog、Timeline
- `worklog.md`：全域日誌，Agent 完成大批工作後寫入，下次啟動前讀取最近 5–10 筆
- PR 提交流程
- 定義 PR Skill，列出 Agent 提交 PR 前必須執行的步驟清單
- 強制 Agent Spawn 一個獨立 Read-only Verifier Agent 審查，而非自我驗證
- --
結論
結論“Loop Engineering 的本質是設計一套自動觸發、共享狀態、相互餵養信號的 Agent 環境，讓多個 Loop 複利運行，而非不斷手動 Prompt 單一 Agent。”
完整解析
詳細2023 年 GPT-3.5/4 API 剛出現時，多數使用場景是單次輸入輸出：給一段文字，模型回傳結果，用於抽取結構化資料或撰寫文章。此時的核心技術是 Prompt Engineering，重點在於如何在單次呼叫中注入正確的上下文以控制模型行為。進入 2024 年中期，模型不僅更聰明，Context Window 也從 4k 大幅擴展至 128k，再到 Google 將預設拉至 1M token，這讓完全不同的使用模式成為可能：讓模型搭配工具（如 MCP），在一次對話中反覆呼叫工具、觀察結果、決定下一步，直到任務完成。Context Window 的擴大直接改變了「如何使用大型語言模型」的問題定義。
然而，有效 Context Window 實際上仍在 128k–200k 之間，因此各種管理長對話的技術隨之而來：Prompt Cache 觸發策略、Compaction 壓縮機制、Skill 擴充 Agent 能力而不膨脹 Context。進入 2025 年，任務規模進一步拉長，開始出現「一次 Claude Code Session 完成 30 分鐘甚至 2 小時工作量」的場景。這時候，跨 Session 的狀態管理問題浮現：不再是一個 Agent Session 把一件事做完，而是多個平行 Agent Session 各自負責一塊，需要共享狀態才能接力作業。這個「模型以外的所有東西」，包括狀態追蹤、觸發邏輯、日誌系統，就是 Harness 的概念。
Loop Engineering 就是在這個 Harness 層面進行設計的工程實踐。它的核心不是讓 Agent 把單一任務做得更好，而是設計一個外部環境，讓系統自動決定「現在該做什麼」並喚醒 Agent。以講者自己的公司為例，目前運行中的 Loop 包括：每 30 分鐘執行一次的支援 Loop（拉取客服票、自動回覆、記錄產品摩擦點至 `signals/` 資料夾）、每天早上 9 點執行的 SEO Loop（研究主題、產出頁面、記錄轉換率缺口信號）、產品成長 Loop（讀取所有 Loop 的 signals 來排定開發優先順序），以及廣告 Loop。這些 Loop 共享同一套 `artifacts/` 資料夾，互相讀寫信號，形成複利效應——廣告 Loop 發現高點擊關鍵字後寫入 `signals/`，SEO Loop 讀到後自動優先製作對應的有機內容。
要讓這套系統穩定運作，需要四個核心元件到位。第一，Codebase 必須對 Agent 友善：一個腳本啟動 Dev Server（不消耗 Agent 的認知負擔）、支援 Git Worktree 讓多個平行 Agent 互不衝突、搭配 Playwright CLI 讓 Agent 能操作瀏覽器並錄製影片附在 PR 上供人工 Review。第二，檔案結構設計：Artifact 資料夾每種類型配一份 README 定義 Schema，每個 Loop 有一份 Contract README 記錄目標、工作流與歷史時間軸，全域 `worklog.md` 讓跨 Loop 的狀態對齊。第三，工具與 Connector 要能接到真實業務系統（Intercom、Stripe、Supabase）。第四，也是最常被忽略的：禁止 Agent 自我驗證，改為強制 Spawn 一個獨立的 Read-only Verifier Agent 來審查 PR，確保驗證結果的可信度。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
