用多 Agent 協調流程（Codex review + Claude Code execution）將 Claude Code 51.2 萬行源碼蒸餾成一個 Agent Skill，提煉 6 個 harness 層設計原則。核心 insight：文件系統做協調層 + 品味注入做方向引導。
Claude Code 源碼洩露（51.2 萬行 TypeScript）。作者趁熱用多 Agent 協調流程將其「蒸餾」成一個可安裝嘅 Agent Skill（agentic-harness-patterns-skill），提煉出 6 個 harness 層嘅設計原則。最終產出涵蓋：Agent 記憶管理、上下文設計、多 Agent 協調、工具權限、生命週期設計。關注嘅係背後嘅 why 而非 Claude Code 嘅 how，以期可遷移到其他 Agent 框架。
設計原則來源： - Anthropic — Effective harnesses for long-running agents - OpenAI — Harness engineering: leveraging Codex in an agent-first world - OpenAI — How we used Codex to build Sora for Android in 28 days
Reviewer（Codex GPT 5.4 xhigh） ←→ 文件系統（handoff.md） ←→ Executor（Claude Code Opus 4.6 max）
review & direction task-board.md build & execute
全新 session 每輪 progress-log.md 全新 session 每輪
同唔讓 implementation 自己 review 自己嘅邏輯一樣： - Codex 以全新視角對照源碼審查（冇先前決策嘅包袱） - Claude Code 帶住對先前決策嘅完整理解執行修改 - 兩個 Agent 互不可見對方嘅 session
Anthropic 喺 Building multi-agent systems 中提過類似思路：One multi-agent pattern that consistently works well is the verification subagent — a dedicated agent whose sole responsibility is testing or validating the main agent's work.
通過文件名 + 簡單嘅 Read Tool，低成本且唔會丟信息。
Anthropic 嘅 How we built our multi-agent research system 嘅原則：Subagent output to a filesystem to minimize the 'game of telephone.'
由於係文檔型任務（唔係 Coding），頂層編排（讓兩個 Agent 交互）由人控制。
呢套文件體現咗 harness engineering 嘅核心理念：先建協調機制，再開始幹活。 如果直接讓 Agent 開始提取模式，冇 task-board 追蹤進度、冇 review-checklist 定義質量標準，後面嘅多 Agent 協作就無從協調。
告訴 Agent「你是誰，規則是什麼」：
| 文件 | 作用 |
|---|---|
clean-agent-brief.md |
Builder Agent 嘅入場說明：操作規則、最低輸出要求、咩情況應該停下來問人 |
review-agent-brief.md |
Reviewer Agent 嘅入場說明：審查優先級、輸出模板、問題嚴重度嘅分級標準 |
Agent 之間嘅共享狀態：
| 文件 | 作用 |
|---|---|
context-map.md |
源碼上下文地圖：50+ 源文件按 harness 層分組，標注每個文件點解重要 |
pattern-notes.md |
探索筆記：前幾輪掃描嘅關鍵發現，供後續 Agent 直接讀取而非重新探索 |
task-board.md |
共享任務隊列：35 個任務，含依賴關係和退出標準 |
progress-log.md |
只追加嘅活動日誌 + 決策日誌（最終記錄咗 13 項關鍵決策） |
handoff_v0_*.md |
Review 與 execution 之間嘅行動簡報 |
codex_review_v0_*.md |
Codex 嘅審查輸出：含嚴重度分級、源碼引用、推薦修復方向 |
定義「咩算完成」：
| 文件 | 作用 |
|---|---|
review-checklist.md |
阻塞性問題（事實錯誤、無源碼依據嘅聲明）vs. 質量檢查（跨運行時可移植性、觸發詞準確性） |
execution-strategy.md |
多 Agent 執行策略：誰做什麼、並行度、子 Agent 嘅 brief 模板 |
output-format.md |
產出物嘅格式規範：文件結構、元數據字段、長度限制 |
每份 handoff 恰好包含下一個 Agent 執行所需嘅信息（一般係索引，告訴新 agent 需要嘅 contexts 嘅大致範圍）。接收方喺全新 session 中啟動，讀取最新嘅 handoff（例如 @xxx_handoff_xx.md），然後執行。
因此，每次 review or execution，agent 都有三類 contexts： 1. Agent role（角色定義） 2. Agent task handoff（task specific）— 對 codex 則係 progress-log.md 中嘅 diff 3. Repo filesystem — OpenAI 博客嘅 insight：give Codex a map, not a 1,000-page instruction manual.
漸進式披露（Gradual Disclosure）： Handoff 做嘅就係粗索引，讓 Agent 只喺需要時獲得恰好足夠嘅上下文。
整個過程中最有意思嘅部分。
作者把之前寫嘅幾篇關於 Context Engineering 嘅博客作為 instruction / taste 喂畀 Claude Code，等佢喺提煉模式時參考自己嘅分析框架。
因此，Agent 唔係從零開始提取 Agent 最佳實踐 嘅。佢帶住作者對 select / write / compress / isolate Context Engineering 四軸框架嘅理解，帶住對 "Do the simple thing that works" 嘅偏好，以及對抽象層級嘅判斷標準。
蒸餾出嚟嘅嘢唔係 Claude Code 源碼嘅「客觀映射」（最開始生成嘅都係呢種），而係經過作者嘅偏好基向量投影後嘅結果。
古老嘅數模記憶攻擊咗我
Negative rules（唔好做 X）→ 管底線 Positive direction（朝呢個方向做）→ 決定品質
Example — OpenAI Harness engineering: Enforcing architecture and taste — 智能體喺具有嚴格邊界和可預測結構嘅環境中效率最高。
如果你畀 Agent 一個近乎無限嘅 Action Space，Agent 會直接失敗。你需要先 Laying the foundation by hand 親手奠定基礎（源自 OpenAI — How we used Codex to build Sora for Android in 28 days）。
親手確定方向後，agent 會越做越「好」（至少符合你嘅需求）。呢個同品味注入係同一個理念嘅兩面。
任何 Agent 動手之前，先同 Codex 對齊項目範圍和命名，然後生成全套 harness 文件。
畀 Codex 嘅 Prompt：
「我們需要一個完整的 guidance（用於 clean agent 領取任務和快速了解 contexts）和對應嘅 progress tracking（方便 clean agent 了解已經做了什麼）嘅 Harness。能否幫我生成呢個 necessary harness set？」
比起 coding 任務，呢類文檔任務嘅 harness 設計可以更輕量。
references/*.md）Codex 第一輪 review 發現 6 個事實錯誤： - 記憶系統未覆蓋 - 並發分類搞錯字段 - 權限來源數量寫錯 - 等等
Claude Code 喺新 session 中修正。
然後 Codex 指出方向有問題： - 應該提取設計原則，而唔係解釋代碼 - 定位選擇：從「Claude Code 有哪些子系統？」轉向「構建者正在解決什麼問題？」 - 呢個重新定位嘅決策係 Codex 建議嘅，但選擇接受並執行，係人做嘅判斷
確定「原則優先」後，8 個子 Agent 同時按統一模板重寫所有文檔：
問題（通用）→ 黃金法則（可移植）→ 適用場景 → 權衡 → 實現模式（無代碼）→ 踩坑指南 → Claude Code 實證
最後一個 section 用自然語言描述 Claude Code 嘅實現決策，不出現源碼路徑、函數名或代碼片段。
| Review 輪次 | 發現 | 關鍵問題 |
|---|---|---|
| v0.4 | 1P1 + 6P2 + 1P3 | 記憶模型仍然描述錯誤 |
| v0.5 | 3P3（通過） | 僅措辭級別嘅調整 |
| UX 審計 | 1P1 + 2P2 + 2P3 | skill 運行時嘅技能列表有 250 字符硬限，精心調嘅觸發詞全被截掉 |
嚴重度在下降 = 收斂在發生。 但 UX 審計又引入一個新 P1 — 內容層面已經收斂，展示層面還有關鍵問題冇人發現。
呢套流程嘅設計目標係最少 human effort 完成大規模蒸餾。但最少唔等於零。
Agent 唔係從零提取嘅，佢帶住作者嘅分析框架、偏好、抽象層級判斷。博客就係基向量。
一個客觀嘅模式提取可能反而最冇用，因為冇視角就冇優先級（無法歸約 agent action space）。
好嘅「蒸餾」需要一個明確嘅立場，然後誠實咁標注呢個立場係咩。同 Ray Dalio 嘅《Principle》裡面嘅概念比較接近。
後續會用同一組基向量分析 Codex CLI 同 Gemini CLI。如果一個模式喺三套獨立實現中都沿同一個方向出現，佢反映嘅大概率唔係某個團隊嘅設計偏好（亦唔只係作者嘅偏好），而係構建 Agent 呢件事本身嘅規律。呢個或許係最值得繼續做嘅事情。
代碼係高維嘅，但有價值嘅設計模式係低秩嘅。蒸餾嘅本質就係搵呢啲主成分。
| 文章概念 | 我哋嘅 Direction | 差距 |
|---|---|---|
| 文件系統協調層 | Delegation Template → Handoff Template | 缺 explicit handoff 機制（已 MVP 實現） |
| 品味注入（基向量） | Taste System v1 | 只有 negative rules，缺 positive direction |
| 質量門控（P1/P2/P3） | Skill Contract | 停喺 research phase |
| 只追加活動日誌 | Memory Hygiene | 冇 decision log |
| 先建協調再幹活 | Scope Enforcer | 方向正確，已部分實現 |
| 漸進式披露 | Context Engineering | 我哋嘅 context injection 太粗粒度 |
| 三組文件結構 | AGENTS.md + projects/ + wiki/ | 缺 task-board、progress-log、handoff 文件 |