谷歌工程师：Loop Engineering 的五个积木让 AI 自动 Prompt 代理

Google 軟體工程師 Addy Osmani 於 6 月 7 日撰文定義「Loop Engineering」為一種以自動化系統取代工程師手動 Prompt AI 代理設計方法，由 Automations、Worktrees、Skills、Plugins/Connectors 和 Sub-agents 五個積木構成。

五個積木的定義與功能

根據 Addy Osmani 的框架說明：

Automations（自動化）： 按排程觸發的任務，負責自動執行「發現」（Discovery）與「分流」（Triage）。Osmani 說明，Automations 是讓迴圈成為真正循環而非「一次性執行」的核心機制。Codex app 使用 Automations 分頁並提供 /goal 指令（跑至條件成立）；Claude Code 透過排程任務、cron、/loop、/goal 和 GitHub Actions 實現相同功能。

Worktrees（工作樹）： 利用 git worktree 機制為並行執行的代理建立獨立工作目錄，防止多代理同時修改同一檔案產生衝突。Codex app 為每個 thread 內建 worktree；Claude Code 透過 git worktree 和 --worktree flag 提供相同隔離機制。

Skills（技能）： 以 SKILL.md 格式將專案知識、慣例和建置步驟寫入外部文件，使代理每次執行時無需重新推斷專案脈絡。兩個工具均使用相同的 SKILL.md 格式，Osmani 說明精確描述優於模糊敘述。

Plugins / Connectors（插件和連接器）： 基於 MCP（Model Context Protocol）建構，使代理可存取 Issue Tracker、資料庫、API 端點和通訊工具等外部系統。Codex app 和 Claude Code 均支援 MCP，Osmani 確認為同一個 connector 通常在兩個工具中均可直接使用。

Sub-agents（子代理）： 將「執行代理」與「驗證代理」拆分為獨立角色，由不同指令甚至不同模型進行互相審查，防止同一代理自我評估過於寬鬆。Codex app 在 .codex/agents/ 以 TOML 格式定義；Claude Code 在 .claude/agents/ 定義 Task subagents 和 agent teams。

外部記憶（State）：第六個組件的定義與作用

Osmani 定義外部記憶為「任何活在單次對話之外、用於記錄做了什麼、下一步是什麼的東西」，例如 Markdown 檔案或 Linear 看板。其必要性原因：大型語言模型在每次執行之間不保留記憶，因此進度必須存儲於外部，而非模型的上下文視窗中。

兩個工具均支援此機制：Codex app 透過 Markdown 或 Connector 連結 Linear；Claude Code 透過 AGENTS.md、進度檔或 MCP 連結 Linear。

常見問題

Loop Engineering 與傳統 Prompt Engineering 的核心差異是什麼？

根據 Addy Osmani 的框架，傳統 Prompt Engineering 由工程師手動撰寫 Prompt 並與代理逐輪互動；Loop Engineering 則設計由 Automations 自動觸發、Worktrees 隔離並行、Skills 提供知識、Connectors 連接工具、Sub-agents 分離執行與驗證的完整系統，工程師的角色從「直接操作代理」轉向「設計運行代理的系統」。

Codex app 和 Claude Code 目前各支援哪些積木？

根據 Osmani 的比較分析，截至其文章發布時，兩個工具均已完整支援五個積木及外部記憶機制，主要差異在於命名和具體路徑：Automations 功能均有對應，Worktrees 均基於 git worktree，Skills 均使用 SKILL.md 格式，Plugins/Connectors 均基於 MCP，Sub-agents 均使用 .agents/ 目錄下的配置文件。

Sub-agents 的「執行與驗證分離」如何實現？

根據 Osmani 的說明，Sub-agents 的設計將「撰寫代碼的代理」與「審查代碼的代理」設為兩個獨立角色，可使用不同指令甚至不同模型。Claude Code 的 /goal 指令採用相同原理：由一個全新的模型判斷任務是否完成，而非由執行任務的模型自我評估，Osmani 稱此為「做的人 vs 檢查的人」應用於停止條件本身。