Agent Loop Architect (循環工程)
概觀
Agent Loop Architect 是一種執行標準與設計模式，用於透過閉環迭代、持久記憶與狀態追蹤，來編排複雜的多階段代理工作流程。
它並非將代理執行視為一次性提示或線性管線，而是強制執行一個迭代生命週期，讓子代理專精化、透過客觀閘門驗證其工作，並在多次執行中系統性地學習。
循環的兩條黃金法則
- 未經學習，不得執行： 在提出或實作任何解決方案之前，代理必須先執行學習階段，查閱記憶中現有的正面與負面模式。
- 未經壓縮，不得完成： 一個循環在寫完程式碼或內容時並未結束；只有在壓縮階段將結果提煉到記憶中並更新狀態後才算完成。
flowchart TD
Start([任務啟動]) --> Learn[1. 學習：載入 .loop-memory/]
Learn --> Plan[2. 規劃：階段分解與 etapas.json]
Plan --> Exec[3. 執行：分派專業子代理]
Exec --> Verify{4. 驗證：客觀閘門通過？}
Verify -- 否：回歸 / 轉向 --> Learn
Verify -- 是 --> Compress[5. 壓縮：提煉記憶與更新狀態]
Compress --> Done([循環完成])
循環的 5 個階段
每個循環都嚴格依序經歷五個階段：
第一階段：學習 (飛行前載入)
- 強制性檢查： 子代理必須讀取：
.loop-memory/positive-cases/(成功模式、已驗證的修正、高轉換率的文案角度、最佳提示模板)。.loop-memory/negative-cases/(反模式、失敗的假設、邊界案例回歸、禁止的方法)。
- 目標： 防止代理重複已記錄的錯誤，並強制重複使用經過驗證的模式。
第二階段：規劃與編排 (狀態初始化)
- 將目標分解為離散、有序的階段。
- 初始化或更新
etapas.json，包含階段狀態、指定子代理、輸入、輸出與驗收標準。 - 指派與領域需求相符的專屬子代理角色。
第三階段：執行 (專業子代理分派)
- 根據階段依賴關係，依序或並行執行子代理。
- 子代理在隔離的上下文中工作，傳遞簡潔的產出物或 diff，而非完整的對話內容。
第四階段：驗證與評估 (客觀驗收閘門)
- 根據明確、自動化或確定性的標準驗證執行輸出 (例如：單元/整合測試結果、Lint 檢查、事實查核引用、語氣合規)。
- 若驗證失敗：
- 將失敗記錄為中間負面模式。
- 帶著失敗反饋返回學習/規劃階段。
- 若驗證通過：繼續進行壓縮階段。
第五階段：壓縮 (飛行後記憶提煉)
- 正面提煉： 提取成功的確切模式、模板、提示片段或程式碼修正，並寫入
.loop-memory/positive-cases/CASE-<ID>.md。 - 負面提煉： 將死胡同、被拒絕的假設與回歸問題記錄在
.loop-memory/negative-cases/CASE-<ID>.md中。 - 狀態最終化： 更新
etapas.json，包含完成時間戳記、最終產出物與執行指標。
目錄結構與記憶體架構
每個使用循環模式的專案都遵循以下根目錄或工作區結構：
<project-root>/
├── .loop-memory/
│ ├── positive-cases/
│ │ ├── CASE-001-fix-auth-race-condition.md
│ │ └── CASE-002-high-conversion-cold-hook.md
│ └── negative-cases/
│ ├── CASE-001-failed-jwt-in-localstorage.md
│ └── CASE-002-clickbait-hook-bounce.md
├── etapas.json
├── references/
│ └── domain-examples.md
└── SKILL.md
記憶案例結構 (.loop-memory/*/CASE-*.md)
每個案例檔案必須遵循以下標準化 Markdown 模板：
# 案例：[簡短描述性標題]
- **日期：** YYYY-MM-DD
- **領域：** [工程 | 文案創作 | 銷售 | 研究]
- **類型：** [正面 | 負面]
- **觸發條件 / 背景：** [確切情況、錯誤訊息或提示目標]
## 模式 / 技術
[詳細說明什麼有效或為什麼失敗]
## 具體產出物 / 程式碼片段 / 提示
```[語言]
[在此貼上具體的片段、模板或 diff]
要點與啟發式規則
- 要： [針對未來代理的可操作規則]
- 不要： [必須避免的行為]
### `etapas.json` 結構
`etapas.json` 檔案追蹤當前的生命週期進度：
```json
{
"project": "agent-loop-project",
"loop_version": "2.0.0",
"updated_at": "2026-11-06T21:00:00Z",
"current_stage": "fix",
"stages": [
{
"id": "reproduce",
"role": "QA 重現子代理",
"status": "completed",
"input": "Bug report #402",
"output": "tests/repro_spec.ts",
"memory_consulted": ["CASE-001-fix-auth-race-condition.md"]
},
{
"id": "fix",
"role": "核心修正工程師子代理",
"status": "in_progress",
"input": "tests/repro_spec.ts",
"output": null,
"memory_consulted": []
}
],
"metrics": {
"total_cycles": 1,
"positive_patterns_harvested": 0,
"negative_patterns_avoided": 1
}
}
整合領域原型
Agent Loop Architect 包含 4 個經過實戰考驗的領域管線。有關每個原型的完整逐步說明與提示，請參閱 domain-examples.md。
1. 錯誤修正與工程
- 管線：
重現 -> 根因 -> 修正 -> 測試 -> 文件化 - 學習檢查： 載入相關子系統的先前修正；避免過去的回歸。
- 驗證閘門： 重現測試從 RED 變為 GREEN；不造成其他測試中斷。
- 壓縮： 將根因解釋與最小修正 diff 儲存在
.loop-memory/positive-cases/。
2. 內容與文案創作
- 管線：
受眾與角度研究 -> 鉤子與敘述草稿 -> 評論與語氣潤飾 -> 校對與事實查核 -> 發佈包裝 - 學習檢查： 閱讀表現最佳的鉤子和被禁止的流行語/陳腔濫調。
- 驗證閘門： 目標閱讀等級、品牌語氣評分 >= 8.5/10、已驗證的事實主張。
- 壓縮： 將表現優異的角度與鉤子公式收錄到記憶中。
3. 銷售外展
- 管線：
ICP 情報 -> 價值假設 -> 個人化排序 -> 異議反駁 -> 分派準備 - 學習檢查： 查詢價值主張、異議模式與無效假設的回應率。
- 驗證閘門： 具體性檢查清單 (無泛用郵件合併行)、符合垃圾郵件規範。
- 壓縮： 儲存成功的個人化鉤子，並將回應率低的角度記錄在負面案例中。
4. 研究、金融與法律分析
- 管線：
探索與來源載入 -> 事實查核與風險矩陣 -> 量化/法律綜合分析 -> 情境壓力測試 -> 高層簡報 - 學習檢查： 載入先例案例、過往分析疏漏與資料有效性標準。
- 驗證閘門： 100% 引用來源可追溯；對壓力測試情境測試風險矩陣。
- 壓縮： 儲存綜合分析模板、來源可靠性評級與風險評估啟發式規則。
子代理分派指南
在循環內部分派子代理時：
- 角色明確性： 切勿對通用代理下提示。請在提示前加上領域角色說明 (例如：
你是 QA 重現子代理...)。 - 記憶注入： 務必在初始子代理提示中提供相關
.loop-memory/案例的路徑或摘要。 - 離散交接： 子代理應透過明確的檔案 (例如：重現腳本、草稿檔案、評估評分量表) 進行通訊，而非對話歷史。
- 自主階段閘門： 子代理不得在沒有可驗證證據 (日誌、測試輸出、驗證分數) 的情況下，將
etapas.json狀態推進為"completed"。
常見錯誤與反模式
| 反模式 | 為何破壞循環 | 正確做法 |
|---|---|---|
| 跳過學習階段 | 代理會重新發明已知的錯誤或使用被拒絕的文案角度。 | 強制在每個提示中將讀取 .loop-memory/ 作為第 0 步。 |
| 省略壓縮階段 | 一旦會話上下文重置，教訓便會遺失。 | 絕不在未將成功/失敗案例提煉成檔案的情況下結束任務。 |
| 單體代理執行 | 單一代理在嘗試同時規劃、編寫程式碼、驗證與文件化時會感到困惑。 | 為每個離散階段分派專業子代理。 |
| 軟性驗證 ("看起來不錯") | 幻覺會溜進生產環境。 | 使用確定性閘門：測試套件、Lint 輸出、事實引用。 |
| 無限制的重試循環 | 代理在無法修復的缺陷上無限循環。 | 將循環重試限制為 3 次迭代，之後觸發人工升級閘門。 |