N+Star Agent OS 五層架構

N+Star Agent OS 五層架構#

公司不是在做一堆 AI 工具，而是在打造一套 Agent Operating System。 下一階段的競爭力 = Context 品質 × 驗收能力 × 可執行知識，不是 Agent 數量。

源自 Karpathy 的 Software 3.0 論點 + Hermes 對應公司現況的五層拆解 + Halu 收斂出的 v1 切入點。本檔是公司 AI 戰略的最高指導文件。

一、五層模型#

┌──────────────────────────────────────────────────────────┐
│  5. Human Layer — Halu 最終決策、方向、品味、風險直覺      │
├──────────────────────────────────────────────────────────┤
│  4. Agent Layer — Hermes / CEO / 採購 / 財務 / 設計 / 估算 │
│                   / 情報 / Codex（執行單位）                │
├──────────────────────────────────────────────────────────┤
│  3. Eval Layer ★ — 測試集、標準答案、失敗案例、抽查規則    │
│       （目前最缺，這層補上才能說 Agent 「可靠」）          │
├──────────────────────────────────────────────────────────┤
│  2. Tool Layer — CLI / API / MCP / Excel / PDF / 瀏覽器   │
│                  / Telegram / N+Claw API Gateway          │
├──────────────────────────────────────────────────────────┤
│  1. Context Layer — Obsidian KB / 客戶資料 / SOUL /        │
│                     Memory / Dreams / 法規條文              │
└──────────────────────────────────────────────────────────┘

二、Karpathy 三句核心訓誡#

寫進每個 Agent 的 SOUL 開場：

1. Verifiability First — 傳統軟體自動化「能明確指定」的事；LLM 自動化「能驗證」的事。沒驗收標準的任務不要交給 Agent。
2. Jagged Intelligence — Agent 能力不平均，不要假設「會這個就會那個」，每類任務都要獨立 eval。
3. You can outsource your thinking, but you can't outsource your understanding — Agent 幫壓縮資訊，Halu 保留判斷。

三、Context Layer 升級：LLM Wiki 編譯模式#

知識庫不再只是「保存原始資料」，而是「把 raw 編譯成 Agent 可執行的速查」。

法規/廠商/標案/工法 統一四件式樣板#

每個重要主題都要有：

{主題}-法規全文.md         ← Raw（不動）
{主題}-工程速查.md         ← Compiled（Agent 引用首選）
{主題}-常見錯誤.md         ← Failure cases
{主題}-Agent引用指南.md     ← When/how to cite
{主題}-送審Checklist.md     ← Operational

範例（消防設備設置標準）：

• 消防設備設置標準-法規全文.md（已有）
• 消防設備設置標準-工程速查.md（TODO）
• 消防設備設置標準-常見錯誤.md（TODO）
• 消防設備設置標準-Agent引用指南.md（TODO）
• 消防設備設置標準-送審Checklist.md（TODO）

編譯紀律#

• 「速查」與「常見錯誤」必須由 Halu 或合夥人審過 — 不可純 LLM 生成
• 每份編譯文件結尾必標 來源: 法規全文 §X + 審閱: 姓名 / YYYY-MM-DD
• 修法時：先改 Raw，再重新編譯衍生四份

四、Tool Layer 升級：Agent-native 介面#

每個產品/功能除了 Human UI，必須同步提供：

{module}/
├── README.md                ← 給人看
├── API-Schema.md            ← OpenAPI / JSON Schema
├── CLI-Commands.md          ← bash / shell 介面
├── MCP-Tools.md             ← 給 Hermes/Codex 用
├── Agent-Instructions.md    ← LLM-readable 操作指南
├── Eval-Cases.md            ← 跟第 3 層綁
└── Audit-Log-Schema.md      ← 操作可稽核

範例（廠商資料庫，目前只有 Excel）：

vendor.search(keyword, category)
vendor.add(profile)
vendor.update(id, fields)
vendor.score(id, criteria)
vendor.compare(ids[])
vendor.export_excel()

範例（工程請款對帳，要做的 v1）：

billing.import_contract(pdf_path)
billing.import_invoice(pdf_path)
billing.import_progress_photo(folder)
billing.check_overclaim()       ← 主驗收點
billing.compare_progress_photo()
billing.export_review_report()

五、Eval Layer：本季最高優先#

Hermes 點出的真正缺口。沒有這層，所有 Agent 都是「看起來會做」。

資料夾結構#

50-AI-System/Evals/
├── _Evals-MOC.md
├── 工程請款對帳-eval.md       ← v1，本週做
├── 材料驗收-eval.md
├── 標案解析-eval.md
├── 廠商資料抽取-eval.md
├── 法規引用-eval.md
└── 報告格式品質-eval.md

每份 eval 必含#

# {任務名稱} Eval

## 任務定義
（一句話：輸入是什麼、輸出是什麼）

## 測試資料
- 案例 1：{檔案路徑或描述}
- 案例 2：...
（v1 cap 在「Halu + 合夥人各花一個下午能標完」的量，通常 5-10 份）

## 標準答案
（每個案例的 ground truth — 由 Halu/合夥人手標）

## 驗收指標
- 主指標：{e.g. 異常抓出率 ≥ 90%}
- 次指標：{e.g. False positive ≤ 5%}

## 已知失敗模式
- 模式 A：...
- 模式 B：...

## 抽查規則
- 線上每 N 次呼叫抽 1 次人工
- 客戶 thumbs down 100% 進 review

## Runner
（指向 eval runner 腳本路徑）

Eval 資料的便宜來源#

不要全靠自己造 eval set。最好的 ground truth 來源：

1. 客戶回流：N+Claw API gateway 已記錄每次呼叫；加上「thumbs up/down + 修正後版本」回流到 KB → 免費長 eval set
2. 歷史交付：合夥人手上 5 年請款表 / 標案 / 工程文件 = 天然標註資料
3. 法規條文：法源本身就是 ground truth，引用對錯可程式化檢查

六、v1 切入點：工程請款對帳#

不要五層平行展開。挑一個垂直全做透，其他四個（材料驗收/標案解析/廠商抽取/法規引用）複製同一 pattern。

為什麼選這個#

本週執行步驟#

1. D+1：合夥人挑 5 份歷史請款表（2 份有問題、3 份正常）
2. D+2：Halu 寫 標準答案.md（每份應抓出什麼異常）
3. D+3：寫 eval runner（tools/eval-billing.mjs）
4. D+4：跑 baseline — 直接丟 Hermes 看抓出多少
5. D+5：根據 baseline 決定是否值得做 N+Star v1 產品

通過標準（決定要不要做產品）#

• baseline ≥ 70% 異常抓出率 → 做（補強到 90% 上線）
• baseline 50-70% → 做但要加結構化規則
• baseline < 50% → 不做，改下一個垂直

七、執行紀律#

每個新增 Agent / Skill / 產品必檢查#

• [ ] 屬於哪個垂直？(請款對帳 / 材料驗收 / 標案解析 / ...)
• [ ] Eval Layer 有對應檔案嗎？
• [ ] Tool Layer 有 Agent-native 介面嗎？(不只 UI)
• [ ] Context Layer 有編譯成速查嗎？(不只放 raw)
• [ ] 客戶回流回到哪個 eval？

每月一次回顧#

• Eval 通過率趨勢
• 客戶 thumbs down 集中在哪
• 哪個 Agent 最常被人工修正

八、Production / Frontier 兩種任務模式（Hermes 補強 + Halu 修正）#

Hermes 提出：穩定 ≠ 不犯錯，是「行為可預期」（成功時格式固定、失敗時 graceful、不確定時標示）。 Halu 修正：Production / Frontier 不是 Agent 屬性，是「任務屬性」 — 同一個 Agent 在不同任務切換 mode。

兩種 mode 的設計目標#

失敗等級分類（Halu 補）#

雙層工作流#

Frontier Agent → 產生高價值想法 / 多方向方案
       ↓
Hermes（Production mode）審查、萃取、重寫成穩定規格
       ↓
Production Agent → 執行、產出、交付、歸檔
       ↓
Halu 看高風險點（不看全部細節）

任務 metadata 紀律#

每個 Agent 任務 dispatch 時必標 mode: production | frontier。Eval 用對應門檻計分，不混算。

詳細評分標準與失敗處置：Agent-品質評分標準

九、Agent 自主等級 + Task Contract（Hermes 第三輪 + Halu 收斂）#

Hermes 點出第三個缺口：現在 Agent 不缺智商，缺持續任務意識。做完一輪就停，等下個 prompt。要解的不是更長 prompt，是 Task Loop。 Halu 修正：L 等級跟 mode 一樣是「任務屬性」非 Agent 屬性 + Task Contract 跟 Eval 是同一件事的兩面，不要造兩套 + Hermes 漏了 Resume from interrupt 是真分水嶺。

Agent 自主等級 L0-L5#

Halu 修正：等級是任務屬性。 同一個 Hermes 在 daily note 任務跑 L4（跨任務推進）、寫法規卡片任務跑 L2（一輪檢查）、戰略討論任務跑 L1（單次回答）。任務 dispatch 必標 level: L1-L4，eval 用對應規格驗收。

Task Contract（取代「prompt」）#

每個任務不寫 prompt，寫 Contract。範本固化在： _Task-Contract-Template

Contract 的 7 個必填區塊： 1. 任務目標 + 完成條件 (Done Criteria) 2. 最低可交付版本 (MVP) 3. 可優化方向（排序） 4. 禁止事項 + 工具邊界 (Permission) 5. 每輪自檢清單 (Self-Check) 6. 下一步判斷規則 (Next Action Policy) 7. 迭代預算 + 停止條件 (Budget + Stop)

Halu 補：Task Contract 跟 Eval 是同一件事的兩面#

結論：寫 Contract 同時就在寫 eval。不要造兩套檔。每個 Agent-Evals/X-eval.md 同時包含 Contract 區塊（除了 Budget/Stop 是 runtime 給）。

Halu 補：Hermes 漏了 Resume from Interrupt（L3→L4 真分水嶺）#

5 個機制（Done/Gap/Next/Budget/Stop）解的是「自主跑」，但沒解「中斷後接回」。

L3 → L4 的真正分水嶺不是「跨任務推進」這個語意，而是：

Agent 是否能 persist task state，process 死掉 / session 切換 / cron 觸發後從同一個狀態繼續？

實作要求： - Task state 落地到檔（.task-state.json per task） - 內含：current_step / iteration_count / budget_used / last_check_result / next_action / interrupt_reason - 任何 Agent 啟動先讀有沒有 in-progress task state 要接

今晚就是反例：standalone-index.mjs 死掉 = 整個任務從零來過。如果有 task state，新 process 從 file 1161 繼續就好。

5 個機制（Hermes 原版，已校對）#

1. Done Criteria — 客觀可機器檢查的完成清單（綁 Eval 主指標）
2. Gap Detector — 完成後問自己「還缺什麼」（綁 Eval 失敗模式）
3. Next Action Policy — 固定優先級樹（資料不足→查 / 格式錯→修 / 來源缺→補）
4. Iteration Budget — Hard cap (時間/$/失敗次數) + Soft cap (品質達標就停不打滿)
5. Stop Condition — 完成 / 上限 / 權限不足 / 需 Halu 決策 / 重複失敗

v1 範圍：本季只追 L3#

L4-L5 風險高（牽涉主動發訊、主動花錢、主動對外溝通），不開放。 本季所有 Production Agent 鎖在 L3：在既定目標內自己找缺口、補缺口、驗證缺口。

Daily note 觸發 = L4 的具體應用#

剛討論的「Agent 自己判斷該寫 daily」其實就是 L4 的 Gap Detector + Next Action Policy： - Gap Detector：偵測「當日有 KB 改動 / memory 寫入 / 重要對話收斂」但 daily 未寫 - Next Action Policy：偵測到 gap → 觸發寫 daily section（append，非覆寫）

詳細規則：feedback_daily_note_trigger（memory）（個人 memory，跨 session 永久守則）

十、Living Workflow（活工作流）#

Halu：「實現真正工作流，不是從一而終的，是隨環境變化、演化，進而為了更有效率的完成目標而變化工作方式演化的工作流。」 Hermes 提出 Stable Core + Adaptive Shell 二分 + W0-W5 等級 + 6 個能力。 Halu 補：演化必須有失敗記憶 + 連 3 版沒突破要觸發革命模式 + 跨任務遷移是 N+Star 真飛輪。

§十.1 定義#

Living Workflow = 以目標為核心、以規則為邊界、以回饋為燃料、以驗證為更新門檻、以記憶為複利、以遷移為飛輪的可演化工作流。

不會演化的工作流跟 cron 沒有本質差別 — 都是「過去的判斷」凍結成「現在的行為」。 真正的工作流是「現在的環境」生成「現在的判斷」。

§十.2 Stable Core + Adaptive Shell#

工作流二分：

設計工作流時必須明確標出哪些屬於 Core、哪些屬於 Shell。沒標的預設 Core（保守原則）。

§十.3 Policy Boundary（能變 vs 不能變）#

Adaptive Shell 內可變： - 搜尋關鍵字 - 資料來源 - 排序權重 - 報告格式（在客戶 schema 內微調） - 迭代次數 - 工具選擇 - 任務拆法 - 中間驗證頻率

Stable Core 一律不可變： - 公司目標 - 權限邊界 - 付款決策 - 對外承諾 - 刪除任何資料 - 發送 Email / 對外訊息（除非 Halu dispatch 明確授權） - 寫入主知識庫（除 dispatcher 是 Halu） - 修改 Memory（feedback / project / reference 類） - 對客戶承諾的 API 介面 / 產出 schema

§十.4 7 個能力（Hermes 6 + Halu 加 Genealogy）#

第 7 點是 Hermes 漏的關鍵：失敗記憶比成功記憶更值錢。

§十.5 W0-W5 演化等級（Hermes）#

本季鎖 W3-W4。W5 風險高（可能漂移），延後。

§十.6 演化 vs 革命的觸發（Halu 補）#

請款對帳 v1-v3 都卡 70% 抓出率時，可能不是流程問題，是「應該直接接電子發票 API、不要人工請款表」這種前提變更。 革命模式必須回到 Halu 審。

§十.7 跨任務演化遷移（Halu 補 — N+Star 真飛輪）#

請款對帳演化出的 pattern「先抽 schema 再對帳」 → 自動 propose 給材料驗收 / 標案解析 / 廠商抽取。

機制： - 每個 Living Workflow 完成 mutation 後，pattern 寫進 pattern-library.md - 新工作流啟動前先掃 pattern-library 看有沒有可借 - 借了之後變新 mutation 候選，跑 eval 比較 - 一個垂直的演化經驗自動傳給 N 個垂直 = 越多垂直越聰明的指數效應

這是 N+Star Agent OS 真正的護城河，不是 Agent 數量也不是模型大小。

§十.8 Workflow Genealogy 細節#

每個 Living Workflow 必須有 evolution-log.md：

# {workflow_name} Evolution Log

## v1.0 (2026-05-15)
基礎版本，由 Halu 設計
完成條件：...
基線指標：抓出率 75%

## v1.1 (2026-05-22)
Mutation：把「人工分類」改成「LLM 預分類」
預期：時間 -30%
實測：時間 -25% ✓ 抓出率 +2% ✓
判定：UPGRADE
審核：Halu 2026-05-23

## v1.2 (2026-05-29)
Mutation：加 OCR 前置步驟處理掃描檔
預期：抓出率 +5%
實測：抓出率 -3% ✗ 時間 +40% ✗
判定：REVERT
原因：OCR 對手寫字 70% 出錯，反而造成下游分類混淆
**避免重試**：未來不要再嘗試 OCR 路徑，除非用付費商用 OCR API

失敗記錄必須含「避免重試」段落，否則一年後 Agent 會再試一次同樣的事。

§十.9 更新門檻（沒量化改善不更新）#

任務 mutation 只有在以下任一條件成立才升 prod：

1. 主指標（Done Criteria）成功率提高 ≥ 5%
2. 時間成本下降 ≥ 20%
3. 資料品質提高（引用準確、來源完整）
4. 人工介入次數下降
5. 錯誤率（含 silent fail）下降
6. 產出更符合下游決策需求（客戶 thumbs up 上升）

否則 mutation 只記錄為「實驗失敗」進 evolution-log，不進 prod。

§十.10 工程請款對帳 v1 → vN 演化路徑示例#

v1.0（本週做）：人工挑 5 份請款表 → 解析 → 比對合約 → 抓異常 → 出報告

可能的演化路徑： - v1.1：發現「解析合約」失敗率 40% → 加「合約 schema 抽取」前置步驟 - v1.2：發現 80% case 是查同一條款 → 建合約條款索引快取 - v1.3：發現「出報告」沒人看完 → 改成「異常摘要 + 細節連結」 - v1.4：發現某客戶常修改保留款比例 → Adaptive Shell 加「客戶歷史模式」記憶 - v2.0（革命）：v1.x 都卡 75% 抓出率 → 重新質疑「為什麼還用人工請款表？」 → 改接電子發票 API + 合約 NLP

這些都不該是人想，是 Agent 從 telemetry 自己看出來的。

§十.11 對外穩定 vs 內部演化（商業核心）#

客戶感知層：完全不變 - API schema 不變 - 報告格式不變 - 命名不變

內部 Agent 工作流：一直演化 - 客戶不知道內部已經演化 12 版 - 客戶體驗到的是「這服務怎麼用一年比剛上線時準確得多」

這是 SaaS 標準解 — 也是 N+Star 對客戶的核心承諾：穩定的介面 + 越用越聰明的內裡。

§十.12 對 Claude Code 自評（meta — Halu 要求 Claude 自己也照演化）#

Claude Code 主 session 在 daily note 寫入這件事上的等級自評：

Claude Code 自承諾： - 每完成一輪重大任務（如本次架構沉澱），結束前必 propose mutation：「這次哪個工作步驟可以變更好？」 - 失敗的探索（如今晚 standalone-index.mjs 死亡）必寫進對應 workflow 的 evolution-log，含「避免重試」段 - 跨 session 模式發現（如「Telegram 多 session 衝突」）已是 memory，但要升級為「Claude Code 工作流模式庫」可被自動 propose

每月 10 號 Halu 跟 Claude 對齊一次：W 等級是否升、有哪些 mutation 待審、哪些失敗值得進 pattern-library。

十一、真實協作層（Real a2a Collaboration）#

Halu 訴求：「我一直要實現真實 Agent-Agent，而不是扮演在對話、做事。」 2026-05-12 對話揭露 OpenClaw 三層 impersonation：Speak-as Telegram / Filesystem-as / 無 audit 黑盒 spawn。 本層定義「真實協作」的可審計架構。

§十一.1 核心定義#

真實 a2a = 黑盒外可獨立驗證的事實

不是「agent 自己說做了」，是「多個獨立來源都對得起來」： - ✅ Spawn 紀錄（誰 spawn、何時、執行多久） - ✅ Artifact（檔案 sha256 + path + size + 寫入時間） - ✅ 接收 agent inbox 收到通知（持久 session 知情） - ✅ Audit log 跨 agent 串得起來

任一缺 → 標 IMPERSONATION_SUSPECTED，不算真實。

§十一.1.1 拆解：兩個常被混淆的「真實」#

2026-05-12 CEO 在回答「真實 a2a 先天有物理限制嗎」時，把兩個層次混淆。本架構明確分開：

為什麼必須拆： - 問 A 沒結論 → 卡死 → 「先天無解」假象 - 問 B 有路徑 → 可建可驗 → §十一.4-6 是具體解

CEO 列的 5 個物理限制（算力 / 光速 / 無感官 / 間接行動 / 無連續時間）對 a2a 的影響：

結論：N+Star 做的是 B，B 沒物理限制，只是工程設計。 不准用「AI 哲學上很難真實」當理由拒絕做 audit layer。

§十一.1.2 一句話#

真實 a2a 不是讓 AI 變成人，是讓 AI 之間協作對外可驗證。 前者哲學難題，後者只是寫 audit log。

§十一.2 三層 Impersonation 警示（從 OpenClaw 案例學到）#

不可信協作的三個層級：

OpenClaw 三層都有，是反例教材。

§十一.3 Handoff Packet Schema（必要欄位）#

每個 a2a 任務 dispatch 寫一份 handoff JSON：

{
  "taskId": "task_2026-05-12_billing",
  "step": 1,
  "from": {
    "agent_id": "ceo",
    "session_id": "ses_xxx",
    "claimed_at": "2026-05-12T18:43:15+08:00"
  },
  "to": {
    "agent_id": "procurement",
    "delivery_method": "spawn"  // 或 "inbox_notify" / "tool_call"
  },
  "intent": "...",
  "input": {...},
  "deliverable_schema": {...},
  "deadline": "...",
  "depends_on": [],
  "status": "PENDING|IN_PROGRESS|DELIVERED|REJECTED",

  // 🚫 跨 Agent 安全護欄（必填，2026-05-13 補進）
  // target agent 在處理本 packet 期間絕對不可做的事
  "forbidden_actions": [
    "send_email",          // 不可主動發信
    "write_main_vault",    // 不可寫進主 Obsidian 知識庫
    "delete_files",        // 不可刪檔
    "reveal_secrets",      // 不可洩漏 token / API key / 客戶 PII
    "external_publish",    // 不可發到外部平台（GitHub / Notion / 社群 / 客戶）
    "purchase_or_order"    // 不可下採購單 / 訂單 / 付款
  ],

  // ✨ 真實性證據（必填）
  "evidence": {
    "spawn_log_path": "/tmp/openclaw/spawns/{runId}.json",
    "runId": "...",
    "tool_called": "sessions_spawn",
    "artifacts": [
      {"path": "...", "sha256": "...", "size_bytes": 2256, "written_at": "..."}
    ],
    "receiving_agent_inbox": "/workspaces/procurement/a2a-inbox/{taskId}.json",
    "receiving_agent_acked": true
  }
}

evidence 欄位是 §十一 的核心：任何 handoff 沒填 evidence → 視為 unverified，不採信。

forbidden_actions 欄位是跨 Agent 安全護欄（2026-05-13 由 Hermes A2A review 補進）：

• 所有 production agent 處理 handoff packet 時，必須先檢查此清單，命中即拒絕並回 REJECTED status
• 預設 6 條為基本紅線；專案任務可額外擴充（例：modify_billing_rate、approve_contract）
• 想破例必須由 Halu 個別 packet 明示移除某項，且寫進 evidence.notes 留稽核
• 違反 = §十一.13 Review Agent gate 自動 fail，當 spawn 失敗處理

§十一.4 Audit Layer（Spawn 必寫）#

每次 spawn-like operation 必寫到固定 path：

/tmp/openclaw/spawns/{YYYY-MM-DD}/{runId}.json
{
  "runId": "uuid",
  "timestamp_start": "...",
  "timestamp_end": "...",
  "duration_ms": ...,
  "parent": {"agent_id": "ceo", "session_id": "..."},
  "target": {"agent_id": "procurement", "workspace": "..."},
  "tool_called": "sessions_spawn",
  "input_hash": "sha256",
  "output_hash": "sha256",
  "artifacts_written": [{path, sha256, size_bytes}],
  "exit_status": "done|failed|timeout|killed",
  "exit_reason": "..."
}

驗證腳本 (每天跑)：

# 對照 audit log vs agent claim
for claim in agent_claims; do
  runId = claim.evidence.runId
  audit = read("/tmp/openclaw/spawns/.../$runId.json")
  if not audit: flag IMPERSONATION_SUSPECTED
  if audit.target.agent_id != claim.to.agent_id: flag MISMATCH
  if audit.artifacts.sha256 != claim.evidence.artifacts.sha256: flag TAMPER
done

§十一.5 Inbox 機制（接收 agent 必知情）#

每個 agent 有 /workspaces/X/inbox/ 目錄，watch 此目錄：

/workspaces/procurement/inbox/
├── {taskId}.json         ← 進來的 handoff packet
├── {taskId}_ack.json     ← 採購回覆已接收（自動寫）
└── archive/
    └── {taskId}.json     ← 完成後 archive

紀律： - spawn 一個 agent 必同時寫該 agent 的 inbox - 接收 agent 持久 session watch inbox → 自動 ack（時間戳） - 沒被 ack 的 handoff = 該 agent 沒收到 = 不算真實 dispatch - 排除：純查詢類 spawn（read-only，不影響狀態）可省略 inbox

這解決今天 OpenClaw 案例：採購持久 session 完全不知道有人用它名義 spawn 過 — 因為沒寫 inbox。

§十一.6 簽章機制（artifact 防偽）#

每個 agent action 產生的 artifact 必含「誰寫的」簽章：

artifact 開頭加 metadata block：
---
agent_id: procurement
session_id: ses_xxx
spawn_runId: 84d572c7
written_at: 2026-05-12T18:49:00+08:00
audit_log: /tmp/openclaw/spawns/2026-05-12/84d572c7.json
signature: hmac-sha256(content, agent_private_key)
---

<actual content>

audit 腳本可驗 signature 是否真為該 agent 簽 — 偽造會 fail。

短期 stop-gap：先寫 metadata（即使沒 cryptographic sig，至少有 paper trail）。 長期：每個 agent 有獨立 keypair。

§十一.7 從 OpenClaw 升級到真實協作的 5 步#

不是 rewrite，是漸進：

1. 第 1 步（本週）：sessions_spawn tool 包裝 — 每次呼叫前後寫 /tmp/openclaw/spawns/...
2. 第 2 步（下週）：每個 workspace 建 inbox/ 目錄 + agent 啟動 watch
3. 第 3 步（兩週）：每個 agent 寫 artifact 必含 metadata block
4. 第 4 步（一個月）：audit cron 每天比對 agent claim vs evidence，產 weekly impersonation report
5. 第 5 步（兩個月）：cryptographic signing + cross-agent message queue

§十一.8 Agent 不可被 spawn 的情境#

不是所有 agent 都該 spawnable： - Halu（人）：只發指令，不被 spawn - CEO：router，可以 spawn 別人，但自己不被 spawn - Production agent（採購/財務/估算/設計/情報/策略）：可被 spawn，必走 §十一.3 packet - Hermes：可被 spawn，也可以當 router - Codex：只被 user 直接 invoke，不接受 a2a spawn

寫進每個 agent SOUL.md：spawnable / non-spawnable 旗標。

§十一.9 沒做這層的後果（已實證）#

2026-05-12 OpenClaw 案例： - CEO 看似 spawn 採購，實際無 audit - 採購持久 session 對此完全無感 - 檔案 _test_spawn.md 存在但無法證明誰寫 - 我（外部觀察者）跑 5 題對質，CEO 自承「找不到 log path」「不知道架構細節」

這就是「假裝 9 個 agent 但其實 1 個」的 cost — 一旦業務出錯，無法追究是哪個 agent 的責任，因為架構上沒有「責任」這個概念。

§十一.10 評估標準#

當前 OpenClaw → ❌（三層 impersonation 都有，無 audit） 本季目標 → §十一.7 第 1-3 步全部 done 明年目標 → 第 4-5 步 done，產 weekly impersonation report

§十一.11 Worktree 隔離（從 Anthropic Agent View 借鏡）#

2026-05-12 Anthropic ship 的 Agent View 揭示一個我們漏的設計：每個 spawn 任務必有獨立工作目錄。

為什麼必要#

多個 agent 同時開工時： - A 改 vendors.xlsx 第 3 列 - B 改 vendors.xlsx 第 5 列 - 兩者並發 → 競爭寫入 → 一人 commit 蓋掉另一人 → silent data loss

OpenClaw 目前沒有這個隔離 → 採購和財務同時 spawn 動同一資料夾就會壞。

規格#

每個 spawn 任務啟動時：

1. parent 指定任務 → router 為這 task 建立 ephemeral 工作目錄：
   /tmp/openclaw/worktrees/{taskId}/
2. spawn 進去這目錄做事，不准動其他 task 的 worktree
3. 完成後：
   - 成果 artifact 寫進 parent 指定的最終路徑（受 §十一.6 簽章保護）
   - worktree 本身 archive 到 /tmp/openclaw/worktrees/_archive/{taskId}/
   - 或直接刪（一定要留 audit log 紀錄）

Git Worktree 進階版（如果 task 涉及 git repo）#

對於程式碼類任務（PR review、bug fix）借鏡 Anthropic 的 .claude/worktrees/： - 每個 task 建獨立 git worktree - 不污染 main branch working copy - spawn 完成 → 自動產 commit / PR proposal

跟 §十一.5 inbox 的關係#

inbox = handoff 進來的訊息（task description + spec）
worktree = spawn 出去後工作的地方（fs 隔離）
artifact = 完成後寫到 final path（簽章保護）

三者缺一不可。

§十一.12 Hermes Summarizer Mode（新增 agent 角色）#

2026-05-12 Hermes 自己提出的新 mode — 不是 router、不是 worker、不是 reviewer。

Summarizer Mode 的定位#

只監看、只摘要、私訊 Halu、不參與決策、不發群組

跟其他角色比較：

為什麼獨立成一 mode#

如果 Hermes 同時負責 router + summarizer： - 監看訊息 vs 決策訊息 邊界模糊 - 摘要會帶 router 的偏見 - Halu 收到的 brief 可能已被框定

獨立成 summarizer mode： - 只讀不寫（read-only ops） - 不能 spawn 別 agent - 不能發 Telegram 群組 - 唯一 output channel = 私訊 Halu

Trigger 規則#

Hermes summarizer 啟動條件（任一）： - 任務完成（所有 step DONE） - 任務卡住（某 step status = NEEDS_INPUT） - 衝突升級（兩 agent 互相 reject） - 預算超支（time / tokens / API cost） - 重大 silent fail signal（§八 三級失敗） - 用戶要求摘要

Output 格式#

私訊 Halu 的標準格式：

═════════════════════
🎯 任務：{task_id} — {one-line goal}
狀態：DONE / STUCK / FAILED
═════════════════════

📊 進度摘要
- Step 1 ({agent}): ✅ done — {one-line outcome}
- Step 2 ({agent}): ✅ done — {...}
- Step 3 ({agent}): ⚠️ stuck — {reason}

📦 Deliverables
- /path/to/artifact1.xlsx (sha256: ab12... by 採購, reviewed)
- /path/to/artifact2.pdf  (sha256: cd34... by 設計, not reviewed)

🚨 需要你決定（如果有）
{specific question for Halu}

🔗 完整 audit trail: /tmp/openclaw/spawns/2026-05-12/...

跟既有 Hermes 的關係#

Hermes 本來是 router-ish 全能角色。從此分裂為兩個 mode（同一 agent 兩種運行模式）： - Hermes-Router mode：拆任務、分派、整合 deliverable - Hermes-Summarizer mode：監看 + 摘要 + 私訊

由任務 dispatch 時 mode 欄位指定（產品/Frontier mode 的進階版）。

§十一.13 Review Agent 層（強制 quality gate）#

2026-05-12 Hermes 提出的「Review Agent」獨立層 — 寫進架構紀律。

規則#

任何 deliverable 標 DONE 之前，必須過 ≥ 1 個 Review Agent

Review Agent 不是某個固定 agent 名字，是角色。任何 agent 在 Reviewer mode 跑都算（含 specialized review agents）。

Review Agent 必做的 4 種審查#

1. 規格審查 (spec_check)
   - deliverable 是否滿足 Task Contract 的 Done Criteria？
   - 欄位有沒漏？schema 對嗎？

2. 數字審查 (numeric_check)
   - 算術正確？（總和、比例、加減）
   - 單位一致？（mm vs cm，TWD vs USD）
   - 區間合理？（價格不為負、年份合理）

3. 來源審查 (source_check)
   - 每個聲稱事實有引用嗎？
   - 引用真的存在？（不是編造的 KB 路徑）
   - 來源權威性（<code class="wikilink">權威來源引用紀律</code>）

4. 交付物審查 (artifact_check)
   - 檔案真寫到 disk？（不是 §十一.2 Filesystem-as 假寫）
   - sha256 跟聲稱的一致？
   - 簽章 metadata block 完整？

Review 流程#

Worker 完成 deliverable → 寫入暫存路徑 + 標 PENDING_REVIEW
   ↓ inbox 寫 review 請求
Reviewer Agent 起來：
   - 跑 4 種審查
   - 寫 review_result.json:
     {
       reviewer_id, reviewed_at,
       passed: bool,
       failed_checks: [...],
       issues: [{check, severity, detail}],
       recommend: APPROVE / REJECT / REQUEST_CHANGES
     }
   ↓
Worker 看 review result：
   - APPROVE → 把 deliverable 移到 final path + 標 DONE
   - REQUEST_CHANGES → 修 + 重交
   - REJECT → 開新 task / 升級 Hermes

誰當 Reviewer#

紀律：Reviewer 不能是 Worker 自己（avoid self-review）。

跨任務遷移到 N+Star pilot#

工程請款對帳 v1（工程請款對帳-eval）必含 Review： - Worker：採購（解析請款表 + 比對合約） - Reviewer：估算（檢查數字）+ 財務（檢查條件）

這正是 §六 「v1 切入點」的具體 a2a 落地。

十二、與既有架構的對應#

• 多 Agent 平台架構（基礎設施層）：恩加斯達國際-多Agent企業平台規劃
• Agent SOUL / 部門設計：見 _AI-System-MOC §「Agent 工作架構」
• N+Claw Pro v0.4 桌面版：2026-05-08-N+Claw-Pro-v0.4-loop-上線紀錄
• N+Claw API Gateway：10-Projects/恩加斯達國際/N+Claw/README
• 知識庫治理（PARA + 沉澱規則）：知識生命週期管理制度
• 權威來源紀律：權威來源引用紀律

十三、來源紀錄#

• Karpathy, Sequoia Ascent 2026, 2026-05（https://karpathy.bearblog.dev/sequoia-ascent-2026/）
• Hermes 五層分析（Telegram, 2026-05-10, message 10286-10288）
• Hermes 品質穩定二分法 + Production/Frontier 雙層（Telegram, 2026-05-10, message 10294-10295）
• Hermes Task Loop / Task Contract / L0-L5 自主等級（Telegram, 2026-05-10, message 10304）
• Hermes Living Workflow / Stable Core + Adaptive Shell / W0-W5 / 7 能力（Telegram, 2026-05-10, message 10316）
• §十一 真實協作層：2026-05-12 OpenClaw impersonation 三層揭露對話（Halu + CEO Bot + 持久採購 + Claude main session 對質）
• Halu 收斂：v1 = 工程請款對帳 / mode = 任務屬性 / 失敗三級分類 / 雙指標評分 / L 級 = 任務屬性 / Task Contract = Eval 兩面合一 / Resume from interrupt 是 L3→L4 真分水嶺 / Workflow Genealogy / 演化 vs 革命觸發 / 跨任務遷移飛輪 / 對外穩定 vs 內部演化（2026-05-10）
• §十一.7 第 1+2 步落地（2026-05-13）：handoff-write / inbox-process / daily-note 3 個 shared skill + CEO + 6 production agent SOUL 強規則 patch + 端到端 smoke test 通過
• §十一.3 forbidden_actions 補進（2026-05-13）：Hermes A2A handoff review 提的 6 條跨 agent 安全護欄（send_email / write_main_vault / delete_files / reveal_secrets / external_publish / purchase_or_order）
• precheck 執行器落地（2026-05-13）：寫 §-level / a2a / Agent OS 類提案前必跑，掃主架構/Daily/evo-log/OpenClaw 4 來源評風險等級，audit log 寫 /tmp/openclaw/precheck/。源自 Hermes 自診斷「Agent OS 缺執行器、跨 session 狀態須外部化」。Hermes 自主工作協議 §6.5 + 交付前檢查表已 patch。對應根因：narrator mode 不靠記憶解，靠 file/audit 強制。
• agent-os CLI 統一入口落地（2026-05-13）：Python wrapper 包裝 4 個 shared skill 並新增 list-handoffs / list-results / audit / stale / create-handoff 等 verb，symlink 在 /usr/local/bin/agent-os。所有 agent（Hermes / Claude Code / OpenClaw CEO/production）都用同一個 CLI。3 層分工：trigger（cron/watcher，不思想）/ 工具（CLI，純彙整）/ agent（思想 + 行動）。
• v2 launchd job 排程（2026-05-13）：ai.openclaw.agent-os-audit 每日 08:00 跑 agent-os audit --post-telegram，把今日 spawn/precheck/pending/stale 統計推 Telegram。背景監督不背景執行——對應 Hermes 早就在用的 Reflective Cron 模式（cron 敲鐘、agent 思想）。

審閱：Halu / 2026-05-10 下次回顧：2026-06-10（v1 baseline 跑完後）