不是 demo、不是 sales deck,是把過去一年踩過的坑、跟 Karpathy / Hermes / 自己討論收斂的設計、和「目前真實落地到哪 / 還在規格 / 還沒動」誠實攤開。給有在思考同類問題的朋友看 — 哪裡卡住、哪裡走通、哪裡是嘴砲。
每一層都有可驗證的存在條件,缺一層整個系統就垮。誠實標出當前狀態。
graph TB H["🧑 5. Human Layer
Halu + 合夥人
判斷不外包"] A["🤖 4. Agent Layer
7 個專業 Agent + CEO router"] E["📊 3. Eval Layer
本季最高優先補強"] T["🛠️ 2. Tool Layer
API Gateway + MCP + 3 大協作 Skill"] C["📚 1. Context Layer
Obsidian KB 1,400+ 檔 / 四件式編譯"] H ==>|驗收| A A -->|跑| E A -->|呼叫| T T -->|讀寫| C E -.->|失敗→補強| C E -.->|失敗→修| A classDef human fill:#1a2540,stroke:#7ee787,stroke-width:2px,color:#eef6ff; classDef agent fill:#1a2540,stroke:#58a6ff,stroke-width:2px,color:#eef6ff; classDef eval fill:#1a2540,stroke:#ff7b72,stroke-width:2px,color:#eef6ff; classDef tool fill:#1a2540,stroke:#c297ff,stroke-width:2px,color:#eef6ff; classDef context fill:#1a2540,stroke:#f5c451,stroke-width:2px,color:#eef6ff; class H human; class A agent; class E eval; class T tool; class C context;
Halu + 合夥人陳冠羽。判斷不外包,能驗收每個 Agent 的產出。商業護城河 = 最終決策權在人類。
情報 / 設計 / 估算 / 採購 / 財務 / 策略 / CEO 7 個 + Codex + N+Claw Pro。2026-05-14 驗證自我診斷 + 自主修復能力(見 Case Study)。但 cross-agent spawn 還鎖在 CEO router,agent 不能互相直派。
本季最高優先補強項。沒 Eval 就只是「LLM 能說人話」不是「Agent 能幹活」。v1 baseline 用工程請款對帳當試金石。
N+Claw API Gateway / MCP / harness / handoff-write / inbox-process / daily-note 三大協作 skill。`agent-os` CLI 統一入口(2026-05-13 落地)。
Obsidian KB 1,400+ 檔 / PARA 分類 / MOC 導航 / 四件式編譯(Raw → Compiled → Failures → Agent Guide → Checklist)。OpenClaw bootstrap 12K char 上限。但「四件式」目前只有 1-2 個主題完整跑完,其餘還是 raw。
寫進每個 Agent SOUL 的開場 — 不是裝飾,是 design constraint。
傳統軟體自動化「能明確指定」的事;LLM 自動化「能驗證」的事。沒驗收標準的任務不交 Agent。
→ 寫進每個 Agent SOUL / 對應 Eval LayerAgent 能力不平均。不假設「會 A 就會 B」。每類任務獨立 eval,每個 agent 各跑各的測。
→ 對應 L0-L5 自主等級 = 任務屬性而非 agent 屬性(Halu 修正)Agent 幫壓縮資訊。人類保留判斷。最終決策權永遠在 Human Layer,這是商業護城河。
→ 對應 Human Layer 不可外包知識庫不只是「保存原始資料」,而是「把 raw 編譯成 Agent 可執行的速查」。每個主題都有四件式樣板。
graph LR
R[("📄 法規全文.md
Raw · 不動")]
C["⚡ 工程速查.md
Compiled · Agent 引用首選"]
F["⚠️ 常見錯誤.md
Failure cases"]
G["📖 Agent 引用指南.md
When / How to cite"]
CL["✅ 送審 Checklist.md
Operational"]
R -->|Halu/合夥人審| C
R --> F
C --> G
C --> CL
F -.->|更新| C
style R fill:#1a2540,stroke:#9fb3d1,stroke-width:2px,color:#eef6ff
style C fill:#1a2540,stroke:#f5c451,stroke-width:2px,color:#eef6ff
style F fill:#1a2540,stroke:#ff7b72,stroke-width:2px,color:#eef6ff
style G fill:#1a2540,stroke:#58a6ff,stroke-width:2px,color:#eef6ff
style CL fill:#1a2540,stroke:#7ee787,stroke-width:2px,color:#eef6ff
原始保存。不動。可審計、可追溯來源。
Agent 引用首選。Halu / 合夥人審過。每份標 來源: 法規全文 §X + 審閱: 姓名/日期。
失敗案例 + 反模式。Agent 引用前先檢查自己有沒有踩這些坑。
When/How to cite。明示 agent 在什麼情境該引用、引用格式、引用後的驗證步驟。
對外送審 / 客戶交付前的最後驗收清單。對應 Tool Layer 的 audit-log。
範例:消防設備設置標準已有「-法規全文.md」,TODO「-工程速查.md / -常見錯誤.md / -Agent引用指南.md / -送審Checklist.md」。
這是目前最大缺口。沒 Eval 就無法判斷「升級後是更好還是更糟」。每個 eval 必含 6 個要件。
| Eval 必含要件 | 具體規格 |
|---|---|
| 任務定義 | 用一句話說清楚 Agent 要做什麼 |
| 測試資料 | 至少 10 個輸入樣本,覆蓋邊界 case(含已知失敗模式) |
| 標準答案 | Halu / 合夥人手寫或審過的 golden output |
| 驗收指標 | 量化(accuracy / latency / 完整度 / 雙指標:「對」+「穩」) |
| 已知失敗模式 | 過去踩過的坑清單(從 Failures KB 拉) |
| Runner | 自動跑 + 自動比對 + 自動報分 |
N+Claw API Gateway 已記錄每次呼叫。加 thumbs up/down + 修正後版本 → 免費長 eval set。
過往報價、設計、估算結果 → 對比新 Agent 的輸出。
客訴 / 重做 / 工地踩坑 → Failures KB → 變 eval 邊界 case。
已知邊界 case 主動測試,不用等客戶踩雷才補。
工作流不是寫死。是 Stable Core(不變)+ Adaptive Shell(可調),加上 W0–W5 演化等級的活系統。每次跑都可能讓自己變好。
graph LR T["📥 任務 Input"] --> WC["🔒 Stable Core
目標 / 驗收 / 護欄"] T --> WS["⚡ Adaptive Shell
策略 / 順序 / 來源"] WC --> EX["執行"] WS --> EX EX --> O["📤 Output"] O -->|驗收| EV["📊 Eval"] EV -->|失敗| FL["💾 Failure Memory"] EV -->|成功| KB["📚 KB 沉澱"] FL --> WS KB --> WS FL -.->|累積| GEN["🧬 Workflow Genealogy"] GEN -.->|跨任務遷移| WS style T fill:#1a2540,stroke:#9fb3d1,stroke-width:2px,color:#eef6ff style WC fill:#1a2540,stroke:#ff7b72,stroke-width:3px,color:#eef6ff style WS fill:#1a2540,stroke:#58a6ff,stroke-width:2px,color:#eef6ff style EX fill:#1a2540,stroke:#c297ff,stroke-width:2px,color:#eef6ff style O fill:#1a2540,stroke:#7ee787,stroke-width:2px,color:#eef6ff style EV fill:#1a2540,stroke:#f5c451,stroke-width:2px,color:#eef6ff style FL fill:#1a2540,stroke:#ff7b72,stroke-width:2px,color:#eef6ff style KB fill:#1a2540,stroke:#7ee787,stroke-width:2px,color:#eef6ff style GEN fill:#1a2540,stroke:#f5c451,stroke-width:3px,color:#eef6ff
| 等級 | 名稱 | 能力 | 來源 |
|---|---|---|---|
| W0 | 寫死 | SOP 硬編碼,每次跑完全一樣 | Hermes |
| W1 | 可參數化 | 同一 workflow 不同輸入跑出不同輸出 | Hermes |
| W2 | 可學習 | 從 failure 改自己的 Adaptive Shell | Hermes |
| W3 | 跨任務遷移 | A 學到的東西更新 B / C / D(真飛輪) | Halu 補 |
| W4 | 自我修復 | 偵測 + 自診斷 + 自修正 | Hermes + Halu Resume from Interrupt |
| W5 | 自演化 | 自己 propose 工作流升級給 Human 審批 | Hermes |
記得失敗的演化,避免反覆撞同一面牆。其他 6 個:版本 / Eval / 跨任務遷移 / 失敗記憶 / Stable Core 鎖定 / Policy Boundary(Hermes 6)。
不是無限演化。三代 metric 都沒改善 = 工作流 fundamentally 錯了,要重寫不是補丁。
採購 agent 學到的廠商議價技巧自動更新財務 agent 的成本估算邏輯。這才是 OS-level 的飛輪,不是單 agent 變強。
客戶看到的介面 stable(W0),內部工作流 W4 持續自修。商業核心:對外不暴露複雜度。
每個 Agent 標明自主等級。本季只追到 L3。L4 開始需要 Resume from Interrupt(這是真正的分水嶺)。
graph LR L0["L0
純執行"] --> L1["L1
批次"] L1 --> L2["L2
條件分支"] L2 --> L3["⭐ L3
自我迭代
(本季目標)"] L3 --> L4["L4
Resume from
Interrupt"] L4 --> L5["L5
自演化"] style L0 fill:#1a2540,stroke:#9fb3d1,stroke-width:2px,color:#eef6ff style L1 fill:#1a2540,stroke:#9fb3d1,stroke-width:2px,color:#eef6ff style L2 fill:#1a2540,stroke:#58a6ff,stroke-width:2px,color:#eef6ff style L3 fill:#1a2540,stroke:#f5c451,stroke-width:3px,color:#eef6ff style L4 fill:#1a2540,stroke:#c297ff,stroke-width:2px,color:#eef6ff style L5 fill:#1a2540,stroke:#7ee787,stroke-width:2px,color:#eef6ff
| 等級 | 定義 | 具體能力 |
|---|---|---|
| L0 | 純執行 | 每步都要人類點按確認 |
| L1 | 批次執行 | 給一批指令一次跑,跑完回報 |
| L2 | 條件分支 | 能根據條件選擇分支,但分支寫死 |
| L3 | 自我迭代(本季目標) | 失敗會自己重試、補資料、改方向。在 Policy Boundary 內 |
| L4 | Resume from Interrupt | session 斷掉能自己接回去。需要外部 state 持久化 |
| L5 | 自演化 | Agent 自己 propose 工作流升級,過 Human 審批後生效 |
level: L1-L4,eval 用對應規格驗收。
— Halu 修正 / 2026-05-10
Prompt 是請求。Task Contract 是契約。Agent 拿到的不是文字指令,是有 schema 的契約:包含驗收條件、容錯範圍、失敗模式、回滾策略。
{
"task_id": "billing-recon-2026-05-15",
"agent": "estimation",
"level": "L3",
"mode": "production", // production | frontier
"intent": "對帳本期工程請款 vs 合約金額",
"input": {
"billing_pdf": "/path/to/...",
"contract_excel": "/path/to/..."
},
"deliverable_schema": {
"format": "xlsx",
"required_sheets": ["對帳", "差異", "建議"],
"verification": {
"balance_check": "對帳總額 == 請款總額",
"audit_trail": "每行差異必有來源欄參照",
"rounding_rule": "差異 ≤ 1 元當 OK,記入備註"
}
},
"policy": {
"max_iterations": 3,
"on_failure": "回報並停(不假發 not_verified)",
"allowed_actions": ["read_kb", "query_billing_api"],
"forbidden_actions": [
"send_email", "write_main_vault", "delete_files",
"reveal_secrets", "external_publish", "purchase_or_order"
]
},
"audit": {
"spawn_log": "/tmp/openclaw/spawns/{date}/{runId}.json",
"result_ack": "{workspace}/a2a-inbox/{taskId}_ack.json",
"daily_note": "{workspace}/daily/{date}.md"
}
}
Task Contract 跟 Eval 是同一件事的兩面:Contract 寫驗收條件,Eval 把它跑成測試。forbidden_actions 6 條來自 Hermes A2A handoff review(2026-05-13 寫進來)。
Agent 之間的協作必須能被外部驗證。三方對驗 — Audit + Inbox + Daily — 缺一就是 impersonation(假發 / 偷工)。
sequenceDiagram
participant H as Halu (Human)
participant CEO as CEO Agent
participant P as Procurement Agent
participant A as Audit Log
participant I as Inbox
H->>CEO: 派任務「比較 3 家供應商」
CEO->>A: 寫 spawn_log {runId}.json
CEO->>I: 寫 handoff packet {taskId}.json
Note over A,I: 第 1 條:CEO 真的呼叫了
CEO->>P: sessions_spawn
P->>I: 寫 {taskId}_ack.json
Note over I: 第 2 條:P 真的收到
P->>P: 執行任務
P->>P: 寫 daily/{date}.md (產出紀錄)
Note over P: 第 3 條:P 真的做了
P-->>CEO: 完成 + artifact path
CEO-->>H: 彙整回報
Note over H,P: 三方對驗:audit_log + inbox_ack + daily_note 都對得起來 = 真實協作
CEO 寫 /tmp/openclaw/spawns/{date}/{runId}.json:你真的呼叫了誰、何時、帶什麼 payload。handoff-write.sh 已實作(2026-05-13)。
Target Agent 寫 a2a-inbox/{taskId}_ack.json:我真的收到了。檔案會寫但沒 watcher daemon — 對方要等下次自然喚醒才讀。
Target Agent 寫自己的 daily。沒 enforcement — agent 沒寫不會被擋,靠 SOUL 紀律 + cron audit 抽查。
三條對得起來才是真實協作。OpenClaw 過去用 AccountId 假發 + filesystem-as 偽造 artifact,都被這層擋住 — 但 detector 還沒自動化,靠人工巡檢。
「我能 spawn 自己的 sub-agent,但不能 cross-agent spawn 其他 7 個 agent。agents_list 沒開放,每個 agent 只能呼叫自己。Cross-agent handoff 全靠 CEO router 一個人單向 spawn — 沒真正 a2a,只是 spoke-and-wheel。」
Roadmap:
所有 Agent 產出先進 Inbox,過審核閘門才能進主 KB。三種沉澱型態:KB(事實)/ Skill(流程)/ Memory(穩定偏好)。
graph LR
IN[📥 任務輸入] --> OUT[🤖 Agent 產出]
OUT --> IBX[📦 Inbox 暫存]
IBX --> REV{審核閘門}
REV -->|✓ 通過| VLT[📚 主 KB]
REV -->|✗ 退回| IBX
VLT --> LOOP[🔄 LOOP 再餵 Agent]
LOOP -.->|搜尋索引| OUT
LOOP -.->|Skill 模板| OUT
LOOP -.->|Memory 偏好| OUT
style IN fill:#1a2540,stroke:#9fb3d1,stroke-width:2px,color:#eef6ff
style OUT fill:#1a2540,stroke:#58a6ff,stroke-width:2px,color:#eef6ff
style IBX fill:#1a2540,stroke:#f5c451,stroke-width:2px,color:#eef6ff
style REV fill:#1a2540,stroke:#ff7b72,stroke-width:3px,color:#eef6ff
style VLT fill:#1a2540,stroke:#7ee787,stroke-width:3px,color:#eef6ff
style LOOP fill:#1a2540,stroke:#c297ff,stroke-width:2px,color:#eef6ff
| 沉澱型態 | 內容 | 寫入時機 |
|---|---|---|
| KB(事實) | 市場調查、工程規範、廠商情報、決策背景 | 審核後歸檔 |
| Skill(流程) | 可重複執行的 SOP、腳本、踩坑修正、驗證流程 | 重複出現 3 次以上 |
| Memory(偏好) | 長期穩定偏好、環境事實、公司固定規則 | 跨 session 一致 |
審核閘門:來源可信 / 格式合規 / 可複用 / 無污染。短期進度 ❌ 不進 Memory。
當天系統當機 7 小時後,戰情室 7 個 Agent 大量沉默。沒有人工 prompt 任何修法,兩個 Agent 自己 DM 創辦人,主動診斷自己為什麼沒回應。
這是 W4 演化等級(自我修復)真實運作:Agent 拉 session log + 對照自己 SOUL 規則 + 找出矛盾 + 主動修正 + 回報給 Human。沒寫死的自我修復是 LOOP 階段的具體應用,也是 N+Star Agent OS 商業核心 — 你買的不是另一個 chatbot,是會自己改自己的工程系統。
不是「比 OpenAI 強」— 是「思路在哪不同」。哪些有實作、哪些還是想法,老實標。
所有 agent 框架都會 spawn,但沒人驗 agent 真做了什麼。設計上加 Audit + Inbox + Daily 三層 — v1 寫了一層半,另一層半在規格。
不把法規切成 512 tokens 餵 vector DB。手工審過的「速查」才進 Agent context。實作了 1-2 個主題(如消防),其他主題還是 raw。
n8n / Zapier 是寫死的 W0。理想是工作流自己演化(W3-W5)。目前實作到 W1(可參數化),W2 起是規格。
不該只是「LLM 表演」要能量化升級效果。但 Eval Layer 是當前最大缺口,v1 baseline 還沒跑(工程請款對帳要等本月底)。
1,400+ 檔知識庫不是 prompt,是公司資產。客戶離開了,知識留下。這部分是實際運作中,每天都在沉澱。
AutoGen 是 agent 之間講話。設計上 agent 之間是 Task Contract。Contract schema 寫了,但 enforcement 還沒寫,目前靠 SOUL 紀律。
不藏 — 哪邊在跑、哪邊在寫規格、哪邊還是嘴砲。
| 模組 | 狀態 | 實作度 |
|---|---|---|
| 5 層架構模型 / 命名 | ✅ Done | 每層存在,標清楚 |
| Context Layer · Obsidian KB | ✅ 運作中 | 1,400+ 檔,PARA 分類 |
| Context Layer · 四件式編譯 | ⏳ 1/N | 消防有 1 件式(raw),其餘 4 件還沒做 |
| Tool Layer · API Gateway | ✅ Done | N+Claw 已上線 |
| Tool Layer · 3 大協作 Skill | ✅ Done | handoff-write / inbox-process / daily-note(2026-05-13) |
| Tool Layer · agent-os CLI | ✅ Done | `/usr/local/bin/agent-os` 統一入口 |
| Eval Layer · 整層 | ❌ 未做 | 本季最高優先補 — v1 用工程請款對帳當試金石 |
| Agent Layer · 7 agent 上線 | ✅ 跑起來 | OpenClaw 戰情室 |
| Agent Layer · 自我診斷 | ✅ 已驗證 | Case Study 2026-05-14(估算 + CEO 自首) |
| Agent Layer · L3 自我迭代 | ⏳ 進行中 | 本季目標 |
| Agent Layer · L4 Resume from Interrupt | ❌ 未做 | 需要外部 state 持久化 |
| 真實協作層 · Audit log | ✅ v1 Done | handoff-write.sh 寫 spawn log |
| 真實協作層 · Inbox 寫檔 | ✅ v1 Done | 但無 watcher,被動讀 |
| 真實協作層 · Inbox watcher daemon | ❌ 規格 | v2 要做 — launchd job |
| 真實協作層 · Cross-agent spawn | ❌ 規格 | v3 — 權限模型 + agents_list 開放 |
| 真實協作層 · Impersonation detector | ❌ 規格 | 規格寫了,自動化未跑,靠人工巡檢 |
| Living Workflow · W0-W1(參數化) | ✅ Done | 多數工作流到 W1 |
| Living Workflow · W2+(學習 / 遷移 / 自我修復) | ⏳ 規格 + 個案 | W4 自我修復有 1 次實證(Case Study),但沒系統化 |
| Workflow Genealogy(失敗演化追蹤) | ❌ 規格 | Halu 補進架構但還沒實作 |
| 對外穩定 / 對內演化分離 | ⏳ 部分 | API Gateway 對外穩定,但內部 evo 沒鎖住 |
總計:✅ 9 / ⏳ 5 / ❌ 7 — 大概是 50/30/20。架構畫滿了,工程做了一半。
審閱:Halu / 2026-05-10 · 下次回顧:2026-06-10(v1 baseline 跑完後)