Loop Engineering 研究筆記

一句話摘要：Loop Engineering 主張透過設計自動化的「迴圈」系統，讓 AI 代理在無需人工逐步提示的情況下完成任務，工程師的角色從 prompt 撰寫者轉變為系統設計師。

5+1 架構拆解（含與 Hermes 對照）

根據 Addy Osmani（2026/6/8）的描述，Loop Engineering 包含五個核心建構塊，外加一個外部記憶體（External Memory），形成 5+1 架構。

#	建構塊	功能說明	在 Hermes 中的對應實現
1	Automations（自動化）	定時觸發、發現/分類工作、執行技能，可排程運行並觸發後續流程。	Hermes 提供 `cronjob` 工具、事件鉤子、批次處理及代理 delegation，可實現相似的排程與自動觸發。
2	Worktrees（工作樹）	為每個代理分配隔離的 git worktree，避免多人協作時的檔案衝突。	Hermes 內建支援 git worktree，每個子代理可取得獨立分支、工作目錄與 `/rollback` 检查点。
3	Skills（技能）	外部化的專案知識（慣例、建置步驟、過去事故）以 `SKILL.md` 形式儲存，減少每次運算時重新導入上下文。	Hermes 的 Skills System 以累進披露方式提供按需知識文件，符合 agentskills.io 標準，作為程序性知識載入。
4	Plugins & Connectors（外掛與連接器）	基於 MCP 協議，使代理能達到檔案系統以外的資源：issue tracker、資料庫、API、Slack 等，實現開 PR、更新票務、發訊息等行為。	Hermes 具備三類外掛：一般工具/鉤子、記憶提供者、context 引擎；可添加工具、斜線指令、CLI 指令、資料檔案、捆綁技能，並支援多種後端（gateway、圖像生成、記憶體、context 壓縮）。
5	Sub‑agents（子代理：Maker vs Checker）	將編寫程式的「Maker」代理與檢閱的「Checker」代理分離，降低自我偏見，各自可使用不同模型或推論力度。	Hermes 透過 `delegate_task` 建立子代理，支援 `leaf`（不能再委派）與 `orchestrator`（可自行派工）兩種角色。預設允許 3 個平行子代理，可依需求實作 Maker/Checker 模式。
+1	External Memory（外部記憶體）	持久化儲存（Markdown 檔、看板等）保存「已完成、待做」資訊，讓迴圈在每次運行間斷後仍能續接。	Hermes 內建 8 種外部記憶體提供者（Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory），提供知識圖譜、語意搜尋、自動事實擷取及跨會話使用者建模。

建構塊

功能說明

在 Hermes 中的對應實現

Automations（自動化）

定時觸發、發現/分類工作、執行技能，可排程運行並觸發後續流程。

Hermes 提供 cronjob 工具、事件鉤子、批次處理及代理 delegation，可實現相似的排程與自動觸發。

Worktrees（工作樹）

為每個代理分配隔離的 git worktree，避免多人協作時的檔案衝突。

Hermes 內建支援 git worktree，每個子代理可取得獨立分支、工作目錄與 /rollback 检查点。

Skills（技能）

外部化的專案知識（慣例、建置步驟、過去事故）以 SKILL.md 形式儲存，減少每次運算時重新導入上下文。

Hermes 的 Skills System 以累進披露方式提供按需知識文件，符合 agentskills.io 標準，作為程序性知識載入。

Plugins & Connectors（外掛與連接器）

基於 MCP 協議，使代理能達到檔案系統以外的資源：issue tracker、資料庫、API、Slack 等，實現開 PR、更新票務、發訊息等行為。

Hermes 具備三類外掛：一般工具/鉤子、記憶提供者、context 引擎；可添加工具、斜線指令、CLI 指令、資料檔案、捆綁技能，並支援多種後端（gateway、圖像生成、記憶體、context 壓縮）。

Sub‑agents（子代理：Maker vs Checker）

將編寫程式的「Maker」代理與檢閱的「Checker」代理分離，降低自我偏見，各自可使用不同模型或推論力度。

Hermes 透過 delegate_task 建立子代理，支援 leaf（不能再委派）與 orchestrator（可自行派工）兩種角色。預設允許 3 個平行子代理，可依需求實作 Maker/Checker 模式。

External Memory（外部記憶體）

持久化儲存（Markdown 檔、看板等）保存「已完成、待做」資訊，讓迴圈在每次運行間斷後仍能續接。

Hermes 內建 8 種外部記憶體提供者（Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory），提供知識圖譜、語意搜尋、自動事實擷取及跨會話使用者建模。

Maker/Checker 分離的價值

減少自我偏見：Maker 專注於產出方案，Checker 負責獨立審查，類似程式碼審查流程。

可使用不同模型：Maker 可使用較快、較省資源的模型生成草稿；Checker 則使用較強的推論模型進行驗證。

隔離上下文：每個子代理擁有獨git worktree 與受限工具集，防止資訊洩漏或過度依賴。

提升系統可靠性：透過分層驗證，降低錯誤直接流入主線的機率。

對 Hermes 的適用性：Hermes 的 delegate_task 已能支援此模式，僅需在工作流程中明確區分「orchestrator」（作為 Checker）與「leaf」（作為 Maker），或自行包裝成 maker/checker 兩種角色的子代理。

風險

理解債（Comprehension Debt）：隨著系統自動產出更多代碼，工程師對實際程式的理解可能落後，導致未來除錯或維護變得困難。

認知投降（Cognitive Surrender）：當迴圈高度自動化時，人類容易放棄判斷，僅接受系統輸出而不進行批判性評估。

驗證不足（Insufficient Verification）：即使有 Checker 子代理，「完成」仍是宣稱而非嚴格證明；若驗證不夠嚴謹，錯誤仍可能進入生產。

對 Hermes 現狀的對齊度評估

Automations、Worktrees、Skills、Plugins/Connectors、External Memory：Hermes 已具備相應功能，與 Loop Engineering 的五個建構塊高度對齊。

Maker/Checker：雖 Hermes 文件未直接使用此術語，但其 delegate_task 的 leaf/orchestrator 角色分離提供相同機制，可透過適當配置實作 Maker/Checker 模式。

總體來說，Hermes 的架構已經涵蓋 Loop Engineering 所倡導的 5+1 元素，僅需在工作流程設計上刻意採用分離的 Maker/Checker 角色以及建立清晰的外部記憶體使用習慣，即可完整實踐 Loop Engineering 原則。

風險方面，Hermes 仍需依賴工程師主動進行程式碼審閱、理解維護以及設置嚴格的驗證步驟（例如測試、型別檢查、連接器的審核），以避免上述理解債、認知投降與驗證不足的問題。