• 該刪的不是規格，而是替今天模型補弱點的流程：Prompt hack、固定 Router、硬編排 Agent 數量與 Retry spaghetti，都可能在下一代模型出現後變成技術債。
• Thin Harness 不等於 No Harness：Context、工具、Sandbox、核准、狀態與證據仍是 Agent 能可靠工作的基礎設施。
• Memory 正在從聊天功能變成工作產物：目標、計畫、指令、結果、失敗路徑與決策理由，應留在任何 Agent 都能搜尋的 Notebook、Markdown 或 Runbook。
• SDD 要少管路徑，多管真相：把意圖、限制、完成定義與驗證寫清楚，讓 Agent 自己決定怎麼走。
• Agent 越多不等於生產力越高：執行頻寬變大之後，人的注意力與決策佇列反而更早撞牆。

標題把問題推成「要不要規範 AI」

我先看到 INSIDE 那篇〈別再用一堆規範綁住 AI〉時，第一個反應是：這個標題很會吸引人點，但也很容易把工程問題推成一場錯的辯論。[1]

一邊變成「模型已經這麼強，規格、測試、流程都該丟掉」；另一邊則開始捍衛 AGENTS.md、SDD、TDD 與所有既有工程方法。兩邊吵半天，最後可能只是對「規範」兩個字的定義不同。

Tibo Sottiaux 真正反對的，不是工程本身。

他反對的是：為了補今天模型的弱點，蓋出一座明天反而困住模型的工程迷宮。

這個差別很重要。因為如果讀成「不要規範 AI」，最先被刪掉的往往是測試、安全與驗收；真正該被檢討的 Prompt hack、固定編排與沒人敢碰的 Workflow Graph，反而可能繼續活著。

Scaffolding 真正在反對什麼

Tibo 在 Dev Interrupted 的訪談裡談到，OpenAI 因為同時做模型與 Codex Harness，可以決定一個問題究竟要在模型訓練解，還是在 Harness 裡解。他甚至直接說：不是所有問題都要修在 Harness；有些能力，幾個月後會由新模型補上。[2]

這才是「Scaffolding is coping, not scaling」的背景。

假設今天的模型只有 70 分，你替它設計一條很完整的路：

任務 → Router → Planner → 5 個 Sub-agent → Critic → Reviewer → Retry → Summarizer

每一個元件都可能有合理理由。Router 避免它走錯路，Reviewer 補它不會自我檢查，Retry 把偶發失敗磨掉，Summarizer 則是因為 Context 不夠長。

問題是，下一代模型如果從 70 分升到 95 分，這條路不一定只是「仍然有用但比較保守」。它也可能直接擋住模型原本能做得更好的方法。

Tibo 把這種情況叫做 Capability Overhang：模型能力已經跳升，Harness 卻仍假設它只有舊能力，所以新的推理、規劃與工具使用方式無法表達出來。[2]

說穿了，你辛苦蓋的 Agent Architecture，可能不是系統的外骨骼，而是一件小兩號的盔甲。

哪些工程不但不能刪，還要加強

這也是整個討論最容易被偷換概念的地方。

AGENTS.md 並沒有突然變成落後做法。Codex 官方文件現在仍明確寫著，它會在開始工作前讀取 AGENTS.md，並依全域、Repository 與目錄層級組合指引。[9]

但一份好的 AGENTS.md，應該告訴 Agent 專案的客觀事實與邊界：

• 測試怎麼跑。
• 哪些資料不能碰。
• 架構有哪些不可破壞的限制。
• 專案使用什麼語言、版本與慣例。
• 哪些動作需要人工核准。
• 完成時要留下什麼證據。

它不需要替模型寫一篇「你現在要如何思考」的長篇劇本。

我會把 Agent 外部的工程分成兩類：

安全邊界更不會因模型變聰明而消失。

一個更聰明、工具更多、執行更快的 Agent，如果沒有 Sandbox、權限範圍與不可逆動作核准，通常不是比較自由，而是比較快出事。模型能力與安全控制不是同一條軸，不能拿前者去抵銷後者。

Thin Harness 不是空殼

OpenAI 在 8 月 19 日公開 Codex 的 Open Agent Harness 時，把 Harness 定義得很具體：它要維持對話狀態、管理 Context、呼叫工具、處理失敗、套用 Sandbox 與 Approval Policy，還要讓工作跨 Turn 延續。[7]

官方同時公布一項自家測試：在 ARC-AGI-3 上，retained reasoning 加上 Context Compaction，讓 GPT-5.6 Sol 從 13.3% 提升到 38.3%，而 Output Token 降為原本的六分之一。這是 OpenAI 自己的 Benchmark 結果，不該被當成所有任務都會複製的獨立量測；但它至少說明一件事：Harness 的設計仍然可以大幅改變模型表現。[7]

所以「Strong Model + Thin Harness」裡的 Thin，指的是：

• 少一點針對舊模型寫死的偏見。
• 少一點不必要的固定路由與角色扮演。
• 少一點把流程複雜度誤認成系統成熟度。

它不是：

• 不管理 Context。
• 不限制工具與資料。
• 不保存 State。
• 不做 Approval。
• 不留 Evidence。

OpenAI 自己留下了很多 Artifact

如果只看「Scaffolding is coping」這句話，很容易以為 OpenAI 的理想工作流是把 Prompt 丟給 Codex，然後雙手離開鍵盤。

但 OpenAI 在 8 月 25 日公開的內部案例，實際上完全不是這樣。

一位 OpenAI 工程師用 Codex 與 Runme Notebook 處理重複的模型評估工作。流程是：

1. 先寫一個短而持久的 Goal。
2. 要 Codex 參考上一次執行，提出詳細 Plan。
3. 在開始前等待人類審查與核准。
4. 執行時記下 Command、Output 與判讀。
5. 把死路、取捨與「下次要怎麼做」一起留在 Notebook。
6. 產生可被搜尋的 Markdown Index，讓後續 Agent 找得到先前經驗。[6]

這套流程不薄嗎？

其實很薄。因為它沒有替每一種評估另外寫一個硬編排自動化，也沒有先規定一定要叫幾個 Agent、用哪個模型思考、失敗三次後換哪條 Graph。

它把耐久的東西留下：Goal、Plan Approval、Evidence、Decision Record 與可搜尋歷史。執行路徑則讓 Codex 依當次狀況決定。

我把這種模式稱為 Artifact-driven Agent Workflow。這是我的整理名稱，不是 OpenAI 宣布的新產品名。

Memory 不該困在 Session 裡

OpenAI 那篇文章裡，我覺得最值得注意的不是 Notebook 本身，而是這句設計：把意圖、動作、決策與結果放進同一個 Artifact。[6]

這會把 Agent Memory 從「它好像還記得我」改成比較工程化的問題：

• 上次實際跑了什麼？
• 哪條路失敗？
• 為什麼最後選 A？
• 哪個結果有 Test 或 Evidence？
• 下次 Agent 要去哪裡搜尋？

聊天記憶適合保留偏好、語氣與長期背景。但只要是會影響工作結果的知識，我不建議只放在 Claude Code、Codex 或 Hermes 的某一段 Session 裡。

因為 Session 很容易壓縮、結束、換模型、換工具，甚至只剩一句看起來很完整、實際上已經漏掉關鍵失敗路徑的摘要。

真正 model-agnostic 的 Memory，通常很樸素：Repository 裡的 Markdown、版本化 Spec、測試輸出、Runbook、Notebook、決策紀錄與系統產生的收據。它們不性感，但下一個 Agent 可以讀，下一個人也可以查。

Skills 跟 Strong Model 並不衝突

Tibo 在 Matthew Berman 的新訪談裡談到，熟練的 Coding Agent 使用者現在還得自己管理 Skill Files、Memory、Sub-agent 與一小群 Agent Network；每當這些機制失靈，使用者面前那個「懂你的完整夥伴」幻覺就會破掉。他理想中的產品，不該讓人一直處理這些 Implementation Detail。[8]

這不代表 Skill、Memory 與 Sub-agent 在技術上會消失。

比較可能的情況是：它們會從使用者要手動管理的 UI 概念，退到 Agent 自己使用的底層能力。

Anthropic 現在的 Agent Skills 正好可以用來理解這件事。它採取 Progressive Disclosure：平常只載入名稱與描述；符合需求時才讀 SKILL.md；Reference 與 Script 則在真正需要時再取用。[5]

這跟「把全部規則塞進 System Prompt」不是同一件事。

前者提供一組可以被 Agent 自己發現、組合與執行的 Primitive；後者則先把模型的注意力塞滿，再希望它一字不漏地照劇本演出。

所以我不會把 OpenAI 與 Anthropic 簡化成互相衝突的兩派。比較準確的說法是：

• OpenAI：Strong Model + Thin Harness。
• Anthropic：Strong Model + Composable Skills。

最後兩邊很可能在同一個方向會合：底層能力仍然存在，但人只需要說清楚要什麼、不能破壞什麼，以及怎麼證明完成。

Multi-Agent 的瓶頸開始變成人

INSIDE 把 Tibo 過去談過的方向整理成「Single Agent → Multi-Agent Network」。這個判斷放在後端架構上未必錯，但新訪談又補了一個很有意思的修正。

Matthew Berman 說，他現在因為 Agent 慢，會同時開 10 到 15 個；如果 Ultra Fast 模型把回應大幅加快，也許反而只需要同時處理 3 到 4 個。這兩個數字是主持人描述自己的工作流，不是 Tibo 提出的通用最佳實踐。Tibo 回應的重點，是產品必須尊重人的注意力與 Context Switching 成本。[8]

這跟我前面寫的 AI Agent 外科手術團隊其實是同一個瓶頸：執行頻寬可以突然放大，人的決策頻寬不會同比例成長。

十幾隻 Agent 在 Terminal 裡同時跑，看起來很像未來。等它們一起回來、每隻都附一份很有自信的報告時，未來就會變成你的 Review Queue。

所以我不會把「Agent 越多」當成成熟度指標。

我更看好的是：一個更強、更快、更懂脈絡的 Agent，在底下自己決定要不要平行探索、叫多少 Worker、何時合併結果。使用者看到的是一個責任邊界；平行化是 Implementation Detail。

Tibo 同一場訪談也說，ChatGPT 與 Codex 的合併方向來自同一個想法：底層是相同的技術與 Harness，介面再依個人的工作調整。[8]

這表示 Coding Agent 可能不是一個永遠獨立的物種。更像是 General Agent 第一個被攻破、又最容易用 Test 與 Git 驗證的高價值工作領域。

SDD 要從規定步驟，轉成建立球場

這些訊號放回 SDD 或 OpenSpec，我的結論不是「規格已經過時」。

剛好相反。

模型越能自己規劃，Spec 越不需要教它每一步怎麼想，卻越需要把以下事情說清楚：

• Intent：到底要解決誰的什麼問題。
• Constraints：架構、相容性、資料與商業邊界。
• Non-goals：這次刻意不碰什麼。
• Acceptance Criteria：什麼叫完成。
• Tests / Evals：哪些結果可以機械驗證。
• Evidence：完成時要留下什麼收據。
• Approval Gates：哪些高影響決策與不可逆動作必須等人。

以前常見的 Spec，實際上混進了大量 Orchestration：

Step 1 先讀 A，Step 2 呼叫 Agent B，Step 3 用模型 C，Step 4 寫 plan.md，Step 5 叫 Reviewer，Step 6 不及格 Retry 三次。

比較未來型的 Spec 會像這樣：

需求、限制與完成定義在這裡。你可以自己決定調查與實作路徑；但不能越過安全邊界，所有 Acceptance Criteria 都要有可重現 Evidence，高影響變更要在 Decision Gate 等待核准。

差別不是從「有規格」變成「沒規格」。

差別是從 Procedure Contract，逐漸轉成 Outcome + Boundary + Evidence Contract。

規格不是 AI 的籠子，而是球場的邊界線。

球員越強，你越不需要告訴他每一步腳要踩哪裡；但界外、犯規、得分與終場規則，反而要定義得更清楚。

我對幾個預測的可信度

這裡的星等是我的判斷，不是來源提供的評分。

如果是我，我會這樣改流程

如果團隊現在已經在用 Claude Code、Codex、Hermes 或其他 Agent，我不會急著重做一套新架構。我會先做六件事：

1. 替每一層 Scaffolding 標註原因與有效期限：它在補哪個模型弱點？模型升級後用最小案例重測，沒必要就刪。
2. 把規格改成 Intent、Constraints、Acceptance Criteria 與 Evidence：少寫固定思考步驟，多寫不可破壞的真相。
3. 把 Human-in-the-loop 移到決策點：Plan、架構取捨、外部寫入、付費與不可逆動作才卡人工；探索與可逆修正讓 Agent 自己跑。
4. 把執行紀錄做成第一級產物：Command、測試結果、失敗路徑與決策理由寫進 Notebook、Markdown 或 Runbook，不只留聊天摘要。
5. 不要把 Agent 數量當 KPI：先量人的 Review Queue、返工與 Decision Latency；注意力爆掉時先合併責任，不是再加一隻 Reviewer Agent。
6. 每次換模型都跑 Harness Ablation：從最簡流程開始，一層一層加回 Router、Skill、Memory、Reviewer；只有能穩定改善真實任務結果的層才留下。

最後一點很重要。

很多 Agent Architecture 的問題，不是它完全沒用，而是從來沒有人測過：拿掉之後是不是反而更好。

我以前寫過 Production AI Agent 的四層控制面，強調 Instruction、Evidence、State 與 Permission。現在回頭看，我仍然會保留那四層；但會更小心，不把「控制面」寫成模型必須逐字照演的思考劇本。

控制面應該管理邊界、狀態與收據。模型則負責在邊界裡找到路。

不要投資在教今天的 AI 每一步怎麼走

把這幾篇訪談與 OpenAI 新公開的工作流放在一起，我最後帶走的不是「不要 Scaffolding」這句漂亮口號。

而是：

不要投資在教今天的 AI 每一步怎麼工作；要投資在讓明天更聰明的 AI 知道什麼是對的。

長期有價值的，仍然是 Specification、Architecture、Domain Knowledge、Tests、Evals、Security、Observability、Data，以及可以被下一次工作重用的 Artifact。

至於 Prompt 技巧、固定 Agent 組織圖、Context 搬運與 Routing 花招，我不會說它們今天全部沒用。但我會開始把它們當消耗品，而不是地基。

地基應該讓更強的東西長上去，不是讓它永遠維持我們第一次搭鷹架時的形狀。

參考資料

• [1] INSIDE：別再用一堆規範綁住 AI！OpenAI 產品負責人 Tibo 談 Agent 願景與時間線
• [2] Dev Interrupted：Scaffolding is coping, not scaling
• [5] Anthropic：Agent Skills Overview
• [6] OpenAI：Automating repetitive work at OpenAI with Codex
• [7] OpenAI：Codex as a platform
• [8] Matthew Berman：How to Understand the Next Wave of AI Before Everyone Else｜Tibo Interview
• [9] OpenAI Codex：Custom instructions with AGENTS.md

• Bot Mode 不是多開幾個聊天視窗：在 Hermes 裡，Bot 就是一個 Profile，角色、模型、記憶、技能、工具、對話與排程都能長期保留。
• 真正的改變是持久化對象：Grok Bot／Hermes 把「那位 AI 同事」放在首頁；Claude Code／Codex 仍更常從專案 Session、Task 或 Goal 出發。
• 持久化不等於自治，更不等於隔離：Hermes Profile 不是 filesystem sandbox；Grok Bots 也共用同一台帳號層級的 cloud computer。
• 我看好的不是 AI 公司幻想：比較合理的架構，是少數長期角色負責脈絡與責任，再召喚一次性 workers 執行；這不是 Hermes 內建的安全保證，我會要求高風險外部動作另外通過可驗證的 Gate。

AI 公司先長在左側欄裡

這幾天我收到一封介紹 Hermes Bot Mode 的 newsletter，標題大意是：「一支免費、而且真正屬於你的 AI 團隊。」

我第一個反應其實不是興奮，而是有點想笑。AI 公司終於從簡報裡走出來了，只是暫時還沒有辦公室，先長在 Desktop 左側欄裡。

但我把 Hermes Bot Mode 官方文件、Profile、Cron 與跨機器通訊機制重新看過一輪，再對照 Grok Bot、Claude Code 與 Codex，發現這次不只是換皮。

我自己的 Hermes 已經開啟 Bot Mode protocol，但 roster 目前仍只有一個 default。這個狀態反而很誠實：功能存在，不代表團隊已經被設計出來。

多開十個聊天視窗很容易。困難的是：每個角色該記得什麼、能碰什麼、何時交接、出了事由誰負責。

Bot Mode 真正改變的，是這個問題開始被放進產品的核心。

從 Session-centric 到 Identity-centric

過去使用 AI 工具，我們通常從一件工作開始：

開一段對話
  ↓
描述任務
  ↓
Agent 執行
  ↓
拿回結果
  ↓
Session 慢慢被遺忘

就算背後有 Subagent，它們通常也是為了眼前工作臨時被叫進來，做完再把結果交回主 Agent。

Bot Mode 把順序反過來：

先建立一個長期角色
  ↓
配置責任、模型、記憶、Skills、Tools、Routines
  ↓
不同任務持續交給「同一個角色」
  ↓
角色累積脈絡，並與其他角色交接

最大的差異不是「有沒有 Multi-Agent」。Claude Code、Codex 早就能平行派出 Subagents。

真正的問題是：工作做完後，系統主要留下的是那個 Task，還是那個人？

這不是純粹的 UI 差異。持久化對象一變，使用者就會開始替 Agent 設計職責、權限、升級路徑、例行工作與協作關係。原本是 Prompt Engineering 的東西，慢慢變成 Organization Design。

底層沒有魔法：Bot 就是 Profile

Nous 官方對 Hermes Bot Mode 的定義很直接：

A Bot is a profile.

Hermes 原本就有 Profile。每個 Profile 都有自己的狀態目錄，裡面可以放：

~/.hermes/profiles/researcher/
├─ config.yaml       # 模型、工具與執行設定
├─ .env              # 憑證設定
├─ SOUL.md           # 角色與長期指令
├─ memories/         # 持久記憶
├─ skills/           # 可重用程序
├─ sessions/         # 對話與工作脈絡
└─ cron/             # 排程工作

Bot Mode 做的，是把這些 Profile 正式包裝成一份有名字、頭像、職稱與描述的 roster。Desktop 只是控制面；CLI 看到的是同一個底層 Agent：

hermes -p researcher chat
hermes profile list
hermes cron list

在建立 Bot 時，可以選擇：

• 從既有 Profile 複製 config、Skills、SOUL 與 Memory。
• 建立新的 Fresh Profile。
• 用 Create empty 跳過預載 Skills，從最小能力開始。
• 為每個 Bot 綁定不同 Provider／Model。
• 分別開啟 Skills、Toolsets 與 MCP Servers。
• 設定自訂 SOUL.md。
• 建在本機、遠端 Gateway、SSH 主機或 Hermes Cloud instance。

Bot 的生命週期也和一般 Session 不一樣。右鍵可以 Duplicate、Hide 或 Delete：Duplicate 會複製 config、Skills、SOUL、Memory 與外觀，但不會複製來源對話；Hide 只把它收起來，Group membership、@mention 與 Routine 不受影響；Delete Profile 則是真正的破壞性刪除，而且 default Profile 不能刪。名稱、職稱與 description 有助於人類與其他 Bot 判斷「該找誰」，卻不構成權限控制。[1]

換句話說，Bot Mode 沒有再造一套 Agent runtime。它把原本分散在 Profile、Memory、Skills、Cron、Gateway 裡的能力，整理成一個人比較容易理解的角色模型。Hermes v0.20.3 在 2026 年 8 月 16 日把 Bot Mode plugin 與 teammate protocol 正式 bundle 進穩定版，也是因為底層原本就已經存在，不需要再發明一個平行世界。[3]

這裡還要補一個版本陷阱。Hermes 線上文件追蹤 main，而 8 月下旬的 structured message_agent、完整跨 Gateway relay 與 typed failure reasons，有些是在當時最新正式 release 之後才合併。以下分析的是 2026 年 8 月 25 日官方文件呈現的 current design；實際操作前，仍要以安裝版本與 release notes 為準。把 main 上的文件直接當成每台舊 Desktop 都已經有，會是另一種很 Agentic 的自信錯誤。

Bot Chat 是一段不輕易結束的關係

每個 Bot 建立時，都會同時產生一個 canonical Bot Chat。它不是普通工作 Session，而是那個角色的持久主對話。

官方甚至刻意攔截這個聊天裡的 /new 與 /reset，改成 /compact：清掉過重的工作上下文，但不把關係 fork 成另一段 Session。[1]

這個設計很有意思。它承認長期角色需要連續性，也承認 context window 不可能無限成長。

持久記憶不是把所有聊天永遠塞進 Prompt，而是知道什麼該保留、什麼該壓縮、什麼已經過期。這部分做不好，所謂的「長期同事」很快就會變成一位記得很多過時規則、但每天都很有自信的老員工。這種人類已經夠多了，沒必要再自動生成一批。

Bot 怎麼聊天、交接與定期工作

Bot Mode 目前有三種主要協作形態。

1. 直接 @mention：把工作交給具名角色

你可以在 Bot Chat 裡輸入：

@researcher 查核這個技術宣稱，再把來源交給 @writer。

這裡不是單純把文字複製到另一個聊天室。Hermes 會先從 live roster 解析對象，把 profile、friendly name 與所在裝置交給目前的 Bot，再由它自行組成訊息，透過：

message_agent(target="researcher", message="...")

送進對方的 canonical Bot Chat。

message_agent 會驗證 target、補上 sender attribution，並以 fire-and-forget 方式執行。發送者先拿到 acknowledgement；接收者完成後，回覆再以背景通知送回來。目前也不會在另一位 Bot 正工作到一半時硬插話，而是在它下一次 invocation 接收訊息。這個工具只存在於 Bot Mode 管理的 canonical Bot Chat，不會突然出現在所有一般 Session。[1]

這些細節看似瑣碎，卻是在回答一個真正的分散式系統問題：誰傳的、傳給誰、失敗能不能重試、同名角色在不同機器上怎麼辨認、對方離線時怎麼回報。

2. Group Chat：有限回合的多 Agent 討論

Hermes 的 Group Chat 不是讓一群模型無限互相稱讚。

目前規則是：

• 一個 Room 可放 2–6 個 Bots。
• 每次使用者訊息最多跑三輪 serial rounds。
• 每次 send 最多產生十則 Bot 訊息。
• 指定 @mention 時，只叫被點名的成員；沒指定才讓所有成員判斷要不要回答。
• Bot 可以選擇 pass，不必每個人都講話。
• Bot 可用 @user 把需要人類判斷的問題標成 needs you。
• 每位成員都有自己的 Group: <name> 持久 Session。

這些限制與協調行為都是 Desktop coordinator 的明確規則，不是靠 Prompt 拜託 Bots 自律。[1]

完整 orchestration log 留在 Desktop 本機；Gateway 只取得有界的近期 transcript projection。這能降低各成員各自保留一套分歧群聊歷史的風險，但也表示 Gateway 上看到的內容不一定是完整稽核紀錄。

這個 hard cap 很重要。Multi-Agent 最容易出現的假象，就是大家都有說話，所以看起來很忙；Token 也真的有燒掉，但沒有多產生一個可驗證的判斷。

我會把 Group Chat 留給真正有衝突的工作，例如架構取捨、風險反證與內容審稿。單純交接，直接 @mention 就好。

3. Routine：把已經做對的流程交給 Cron

Bot 的 Routine 本質上就是 Hermes Cron job。Desktop 會把它顯示在 Bot 旁邊，但 CLI 仍能在 hermes cron list 看到。真正執行排程的是 Gateway daemon；scheduler 約每 60 秒 tick 一次，每次 run 都是新的 isolated Agent Session，Prompt 仍要能自足。[13]

這表示 Routine 可以沿用既有排程能力，而不是另外養一套自動化系統。它也有一個很容易忽略的行為：隱藏 Bot 只是不顯示，@mention、Group membership 與 Routine 都會繼續運作。[1]

因此 Routine 適合：

• 每日新聞與技術掃描。
• 定期價格或網站狀態監測。
• 每週內容整理與研究摘要。
• 測試、報告或資料清理等可重複流程。

但「Bot 還在 roster」與「工作能永遠跑」是兩件事。Hermes 不會憑空替你提供一台永不關機的主機；Gateway、scheduler 與所在機器仍要運作。跨機器 DM 若走 Desktop relay，也需要同時認得兩端的 Desktop 保持連線；真正 always-on 的 peer-to-peer 路徑，則要另外設定 Gateway API、網路可達性與強金鑰。[1]

Grok Bot、Hermes、Claude Code、Codex 差在哪

把這四個產品放在一起看，很容易陷入功能表格：誰有 Subagent、誰有排程、誰能開 Terminal。

我覺得更有用的問題仍然是：系統主要把什麼當成長期存在的第一級物件？

Grok Bot：託管式 AI 辦公室

xAI 官方把 Grok Bot 定義為長期存在的 AI teammate。每個 Bot 有自己的畫面，可以使用 Browser、Apps、Terminal 與 Files；不同 Bots 能交接工作、保存 Skills、建立排程或事件觸發的 Routines。背景 Routine 即使筆電闔上仍可運作。[4][5]

但官方也講得很清楚：同一個帳號下的所有 Bots 共用一台 persistent cloud computer。檔案、瀏覽器 Session、App login 與 command-line credentials 都對整個 roster 可見。每個 Bot 有自己的 screen，卻不是自己的 security boundary。[6]

Skills 與 Connectors 也是 account-wide library，不是每個 Bot 各自擁有的隔離資產；底層模型由產品選擇並可自動 failover，沒有使用者 model picker。它的優勢是省事，代價是控制面與資料邊界交給託管平台。[14]

Hermes Bot Mode：自己組裝 AI 組織

Hermes 的優勢不是「免費 Grok Bot」。軟體本身是開源的，但模型 API、搜尋、影像生成、主機、GPU 與維運時間都會花錢。

真正差異是它把選擇權留給你：Bot 可以用不同模型、住在不同機器、擁有不同 SOUL 與工具組合，還能從 CLI 直接操作同一個 Profile。

控制力比較高，表示你也得自己承擔架構、監控、憑證與復原。自架從來不是免費，它只是把帳單從訂閱費拆成更多欄位。

Claude Code：為專案臨時組成的工程 Tiger Team

Claude Code 的 Custom Subagents 可以保存角色定義、工具與權限；Agent Teams 則讓 Team Lead 建立多個獨立 Session、共用 Task List，並讓 teammates 彼此傳訊。目前官方仍把 Agent Teams 標成 experimental、預設關閉，而且只在 CLI 提供，不是 Claude Desktop 功能。每個 teammate 都是獨立 Claude instance，Token 成本也會隨成員數增加。[7][8]

它很像為眼前 Repository 召集一支工程小隊。Agent definition 與 shared task list 可以留下，但 live Team runtime 會隨 Session 結束；in-process teammates 也不會靠 /resume 自動復活。這不是整間公司的長期 roster。

Codex：把 Goal 做到可驗收

Codex 的 /goal 可以把長工作整理成有 title、spec 與 acceptance criteria 的持久目標，在 CLI、IDE 或 Desktop 中繼續、暫停與恢復。Subagents 則能在平行 threads 研究、實作與測試，再把結果帶回主 thread；目前官方描述的是由主 Agent 集中協調，而不是像 Claude Agent Teams 那樣讓 peers 共用 Task List、互相接管 lead。[9][10]

Codex 也有預設關閉的 Memories，可跨 Chats 保存偏好與背景。不過官方把它定位成 recall layer，而不是權威規則來源；更高優先級的 system、developer、AGENTS.md 與當前 Prompt 仍會覆蓋它。這讓 Codex 並非「完全沒有長期脈絡」，只是產品入口仍從 Chat／Goal 開始，而不是先建立一位具名 teammate。[16]

所以 Codex 給我的感覺不是「Bob 今天又來上班」，而是「Goal #381 還沒 Done」。Goal 屬於那一個 Chat；它可以保存與恢復工作條件，卻不是跨任意 Chat、專案與排程都存在的角色身份。Codex 持久化的是工程承諾與完成條件，而不是先替執行者建立人格。

這四者其實沒有誰會把誰完全取代。比較可能的組合，是 Hermes／Grok Bot 保存長期責任與脈絡，Claude Code／Codex 類型的 workers 負責一次性、可平行、可驗收的工程執行。

最危險的誤會：Profile 不是 Sandbox

Bot Mode 的介面很像組織圖，很容易讓人誤以為每個 Bot 也像部門一樣有自己的門禁。

沒有。

Hermes 官方 Profile 文件明確區分三件事：

• Profile：隔離 config、Memory、Sessions、Skills、Cron 與 Gateway state。
• Workspace：Terminal 從哪個目錄開始。
• Sandbox：Agent 實際能存取哪些檔案與系統資源。

在預設 local terminal backend 下，Agent 仍然沿用執行 Hermes 的 OS 使用者權限。設定 terminal.cwd 只決定起始位置，不會阻止它走到其他資料夾；SOUL.md 裡寫「不要碰」也不是防火牆。[2]

另外，Desktop 建立新 Bot 時，預設可能共享主要 Profile 的 OAuth／token pool。Clone 更會把 config、Skills、SOUL 與 Memory 一起帶過去。[1]

所以敏感用途不能只靠換名字與頭像隔離。Fresh Profile 會有乾淨的 Session 與 Memory，但仍可能沿用目前的 Provider、API key 或 shared OAuth pool；「狀態是新的」不代表「身份與憑證也是新的」。我會要求：

1. 用 Create empty 建最小 Bot，不做 full Duplicate；需要的 Skills 再逐一加回。
2. 另行配置用途專屬的 Credentials／Gateway，不把 shared token pool 當成隔離；Host 上的 CLI Credentials 也要配合 terminal.home_mode: profile 或更強的 OS 邊界。
3. 只開必要的 Toolsets、Skills 與 MCP Servers。
4. 不需要 Terminal 的角色就不要給 Terminal。
5. 真正敏感的執行放進 Container、VM 或權限受限的遠端 Backend。
6. 發布、Merge、刪除、付款、寄信與 Production 修改，一律經人類核准。
7. 公司資料與個人 Agent 完全分開，不把內部 Email、Slack、程式碼或 Credentials 丟進個人 Bot。

Persistent identity 會讓 Agent 比一次性 Session 更好用，也會讓錯誤權限活得更久。

Persistent Agent 會把什麼問題放大

我認為 2026 年 Agent 工具確實正在從 Session-centric 往 Identity-centric 移動，但下一個競爭點不會只是「誰能養更多 Bots」。

1. Context 會從資產變成負債

長期角色可以累積偏好、歷史與工作方法，這是它的價值。但錯誤記憶、過期 Skill、失效 Connector 與曾經合理的決策，也會一起留下。

一次性 Agent 做錯一次就結束；Persistent Agent 可能把同一個錯誤變成每週 Routine。

未來需要的不只是 Memory，而是 Memory lifecycle：來源、時效、衝突、刪除、回滾與責任人。

2. Agent 通訊會變成新的分散式系統

一旦 Bots 可以跨機器、跨 Gateway、非同步交接，就會碰到我們早已熟悉的問題：重試、冪等性、重複訊息、離線、timeout、身份解析與可觀測性。

Hermes 已經替 delivery failure 定義 typed reason，並區分哪些錯誤值得自動重試、哪些重試只會浪費額度。這比「Agents 可以互聊」更值得注意，因為真正的系統通常不是壞在 Demo 的 happy path。[1]

3. Review debt 會比 Token 更早撞牆

Bots 愈多，產出愈快，人類的審查佇列就愈長。

DORA 2024 觀察到 AI 採用與文件、程式碼品質及 Review speed 改善相關，但也與 Delivery throughput、stability 下滑相關。METR 在 2025 年初的隨機實驗則發現，特定資深開源開發者在熟悉 Repository 上使用當時的 AI 工具，平均慢了 19%；原研究頁現在已明確警告，這個結果很可能不再適用於當前工具。2026 年更新資料出現加速訊號，但估計區間跨過零，且受到參與者不願被分配到禁用 AI、任務選擇與多 Agent 並行工時難以計算等偏誤影響，METR 自己也只稱為很弱的證據。這些結果不能直接比較，更不能推論所有 Agent 都會提高或降低生產力；它們共同提醒的，是生成速度不等於交付速度，量測方法也必須跟著工作型態改變。[11][12][15]

所以我不會讓同一個 Bot 一邊寫、一邊證明自己寫得很好。確定性檢查（測試、型別、Lint、靜態掃描）、證據審查（來源、Browser、視覺）、不同角色或模型的 Reviewer，以及人類 Gate，必須分層存在。

4. 最合理的是長期 Manager 加一次性 Workers

不是每個工作都值得建立一位永久 AI 員工。

需要長期累積脈絡、承擔固定責任、定期被叫用的角色，適合做 Bot。一次性研究、單一 PR、短暫反方審查與大量平行嘗試，則適合 Subagent 或 Task worker。

未來成熟的 Agent 系統，比較可能長這樣：

少數 Persistent Bots
負責責任、脈絡、路由與例行工作
          ↓
按需召喚 Ephemeral Workers
負責研究、實作、測試與反證
          ↓
Deterministic Verification
          ↓
Independent Review
          ↓
Human Approval

AI 組織不是把每個職稱都做成一個聊天頭像，而是替不同生命週期的工作選對執行單位。

如果是我，我會先做四個角色

我不會一開始建立十五個 Bots。Roster 很大，看起來很像公司，但也可能只是多了一個需要管理的通訊錄。

我會先從四個長期角色開始：

Orchestrator
├─ Research Scout
├─ Builder / Editor
└─ Verification Gatekeeper

Orchestrator

保留目標、限制、優先順序與責任邊界。它可以路由工作，但不應自動擁有所有高風險權限。

Research Scout

負責找官方文件、論文、新聞與反證。可以排 Daily／Weekly Routine，但不能自行發布。

Builder／Editor

依規格產生程式碼、文件、文章或素材。它的工作目錄與可寫範圍要清楚，不能因為「方便」就讀整台電腦。

Verification Gatekeeper

使用不同角色、不同提示，必要時甚至不同模型。它負責測試、來源、Security scan、Browser evidence 與風險分類，但不能自己批准自己 Merge。

接著只量五件事：

1. 一項工作從提出到可驗收花多久。
2. 人類實際花多少時間 Review。
3. 有多少產出被退回重做。
4. Routine 是否產生過期、重複或無人處理的結果。
5. 權限與資料是否曾超出原本邊界。

如果這四個角色都還沒有穩定，再增加 Bot 通常不會比較像公司，只會比較像多開幾個群組，而且每個群組都有人在 tag 你。

我真正期待的不是 AI 公司

Hermes Bot Mode 不是 Claude Code Subagent 的另一個名字，也不只是 Grok Bot 的開源版本。

它比較像是把 Hermes 從「一個很強的 Agent」變成「一個可以設計 Agent 生命週期與責任關係的控制面」。Profile、Bot Chat、Group、Routine 與跨機器 messaging 原本都是技術元件；Bot Mode 把它們組成了人比較容易操作的組織模型。

這個方向很有價值，但「有名字」不會自動帶來責任，「有記憶」不會自動帶來判斷，「能互聊」也不代表已經形成團隊。

工具商很喜歡把這些介面畫成一間 AI 公司。對我來說，更準確的比喻其實是一張責任地圖：誰記得什麼、誰可以做什麼、哪裡必須停下來等人。

如果這張地圖沒有先畫清楚，開再多 Bots，也只是讓混亂開始有了頭像。

封面為 AI 生成概念圖，以水手服 AI 系統工程師與四個具名機器人角色呈現 Persistent Bot roster、工作交接、Routine 與驗證 Gate；不代表 Nous Research、xAI、Anthropic 或 OpenAI 的官方介面、合作或背書。內文圖解由作者依官方文件重新繪製。

參考資料

[1] Nous Research：Hermes Agent Bot Mode

[2] Nous Research：Profiles — Running Multiple Agents

[3] Hermes Agent v0.20.3 Release Notes

[4] xAI：Grok Bot Overview

[5] xAI：Grok Bot Skills and Routines

[6] xAI：Grok Bot Approvals, Security, and Privacy

[7] Anthropic：Claude Code Custom Subagents

[8] Anthropic：Claude Code Agent Teams

[9] OpenAI：Codex Long-running Work and Goal Mode

[10] OpenAI：Codex Subagents

[11] Google Cloud：2024 DORA Report

[12] METR：Early-2025 AI and Experienced Open-Source Developer Productivity

[13] Nous Research：Hermes Cron Scheduling

[14] xAI：Grok Bot Use the Computer and Apps

[15] METR：We Are Changing Our Developer Productivity Experiment Design

[16] OpenAI：Codex Memories

• 發 Token 不等於組織轉型：如果流程與決策方式不變，AI 很可能只是把原本不值得做的事做得更快。
• 一人團隊開始可行：能定義問題、切架構、做取捨的人，可以把實作、測試、重構與文件交給多個 Agent。
• AI 放大執行，沒有放大人腦：人仍要在腦中維持系統的一致模型；專案一大，認知負荷就會先撞牆。
• 大型系統不會變成大型獨角戲：比較合理的方向，是多位主導者各帶自己的 Agent，透過清楚的介面契約協作。

問題不是少買幾張 AI 授權

今天看到寶玉在 X 上的一則長文，他把 AI Agent、康威定律與《人月神話》的「外科手術團隊」接在一起。被他引用的 Xiaowen 貼文裡，有一句話很準：

個人效率解決的是「更快完成眼前這件事」；組織效率解決的是「省掉哪些不值得做的事」。

很多組織導入 AI 的第一個反應，是替每個人買工具、發 Token，再期待所有人都快一點。這當然可能有幫助，但它比較像替原本的組織裝上渦輪。

問題是，如果車子開錯方向，渦輪只會讓它更早抵達錯的地方。

AI 真正有意思的地方，不只是把一小時的工作縮短，而是讓原本能定義問題、整合資源、承擔結果的人，直接做出過去需要一支小隊才能完成的東西。這不是單純的個人生產力提升，而是交付單位開始縮小。

我以前寫過 Executor 與 Orchestrator 的差別。那篇談的是人的角色；這一篇想往下再挖一層：當 Orchestrator 真的能帶著一群 Agent 交付，組織與軟體架構會變成什麼形狀？

組織會長進系統裡

Melvin Conway 在 1967 年提出一個後來被稱為康威定律的觀察：設計系統的組織，最後會做出一套近似自身溝通結構的設計。

四個團隊各自負責一塊，系統通常也會留下四塊邊界。部門之間很難溝通，模組之間的整合通常也不會突然變得優雅。組織圖不會被放進 Git，但它會用另一種方式長進程式碼裡。

傳統軟體開發之所以有需求、產品、架構、開發、測試與維運等角色，不只是大家喜歡畫泳道圖。系統夠大之後，很少有人能同時掌握所有領域，也沒有足夠時間把每件事親手做完，只能靠分工換取規模。

分工的代價是溝通。

如果每兩個人之間都可能需要直接協調，n 個人最多會形成 n(n-1)/2 條配對溝通路徑。人數增加時，潛在路徑不是直線增加。這也是為什麼一個進度落後的專案，多塞幾個人進去，常常先得到更多會議，而不是更多完成品。

一個五十年前沒有普及的構想

《人月神話》談過一個很有名、實務上卻沒有成為標準答案的做法：外科手術團隊（Surgical Team）。

這個構想原本由 Harlan Mills 提出，Fred Brooks 再於書中完整描述。核心不是找十個能力一樣的人，而是把設計與核心實作集中在一位 Chief Programmer，也就是「外科醫生」身上。副手、工具維護、測試、文件與行政等角色，都圍繞他提供支援。[1][2]

網狀溝通因此變成以主導者為中心的星狀結構。最重要的設計決策留在同一個腦中，系統比較容易維持 Brooks 所說的 Conceptual Integrity（概念完整性）。

這個想法很漂亮，但也很脆弱：

• 能掌握全局、又能做核心設計的人本來就少。
• 關鍵人物離開或判斷錯誤，整支團隊會一起失速。
• 系統持續變大後，一個人不可能知道所有細節。
• 支援角色仍然要付出溝通、等待與交接成本。

說穿了，當年的外科醫生不只要夠強，還得剛好配到一支隨叫隨到、完全理解他的支援團隊。這種組合在書裡很好看，在現實裡就比較像稀有掉落。

Agent 終於補上支援團隊

AI Coding Agent 讓這個老構想重新值得討論。

今天，一個有技術判斷力的工程師、產品負責人或架構主導者，可以把問題定義、架構取捨與驗收標準留在自己手上，再讓 Claude Code、Codex 這類 Agent 接手大量支援工作：

溝通成本也跟人類團隊不同。Agent 不用先排一場會議理解 Repository，可以直接讀程式碼、測試與版本紀錄；它不會因為被退回重做就開始捍衛面子，也不會嫌寫文件太無聊。

當然，它會看錯、做錯，也可能很有自信地把錯誤一路自動化。這也是為什麼我不把 Agent 當「不用管理的資深工程師」，而是把它當成執行力很強、但必須被規格與驗證約束的支援團隊。

重點不是一個人把所有職稱都兼掉。

重點是：一個人守住決策核心，AI 把決策轉成可驗證的實作。

執行變快，人腦沒有擴充記憶體

這個模式最容易被講成「一個人抵一支團隊」。我不太喜歡這種說法，因為它把產出速度跟系統駕馭能力混在一起。

AI 確實能讓程式碼、測試與文件更快出現，但沒有替人類擴充工作記憶。主導者仍然要知道：

• 系統現在有哪些重要邊界？
• 這次修改破壞了哪個假設？
• 哪些模組可以互相依賴？
• 測試證明了什麼，又漏了什麼？
• 這個結果符合需求，還是只符合提示詞？

Agent 同時跑得愈多，人的審查佇列也會愈長。最後常見的瓶頸不是 Agent 沒事做，而是人來不及讀懂、判斷與批准。

這也是 AI 一人團隊真正的上限：執行頻寬變大，決策頻寬沒有同比例成長。

如果主導者失去對整體的理解，只靠 Agent 回報「測試全綠」，外科手術團隊很快就會退化成一群動作很快、彼此不知道在改什麼的機器人。畫面很忙，病歷也都填了，但沒有人說得清楚病人為什麼躺在那裡。

大型系統仍然需要分工

所以我認為，這個模式會先在邊界清楚的中小型系統、個人產品、內部工具，以及大型系統中的獨立模組上發揮最大效果。

超大規模系統不會因為模型變強，就突然適合讓一個人全部掌握。比較合理的結構，是幾位「外科醫生」各自帶著自己的 Agent 支援團隊，分頭負責不同的業務能力或模組，再用清楚的介面契約保持鬆耦合。

這其實是康威定律的逆向操作：

1. 先決定系統真正需要哪些穩定邊界。
2. 再讓每位主導者對一個可理解、可驗證的邊界負責。
3. 模組之間靠 API、事件格式、資料所有權與失敗語意協作。
4. Agent 在邊界內放大執行，不替人偷偷改寫邊界。

未來的分工不一定消失，只是可能不再照前端、後端、QA、文件這種工序切開。每個小型交付單位會更接近「一位能做系統判斷的人，加上一組不知疲倦的 Agent」。

如果是我，我會這樣設計

如果要試這種工作方式，我不會從「同時開十個 Agent」開始。那只是把十條不確定的路一起加速。

我會先做七件事：

1. 選一個邊界清楚的完整成果：最好能在幾天內走完需求、實作與驗證，不先碰整個核心系統。
2. 人類先寫清楚不可外包的判斷：問題、目標、架構限制、風險、完成定義與停止條件。
3. 讓 Agent 按責任分工：實作、測試、清理與審查不要全部塞在同一段上下文，避免它一邊寫答案、一邊替自己打分數。
4. 把規則做成硬性關卡：測試、靜態分析、依賴方向、介面契約與端到端驗收，不能只寫在提示詞裡勸 Agent 記得。
5. 保留短而可查的決策紀錄：只記關鍵假設與取捨，不替專案養一座沒人敢刪的文件博物館。
6. 量測整段交付，不只算生成速度：把重工、Review 缺陷、回滾與後續維護一起算進去。
7. 當人腦開始失去全局，就拆邊界：不要再加 Agent。先把系統切成能由不同主導者獨立理解的模組。

這跟我前面整理的 Matt Pocock Skills 工作流其實是同一件事：模型愈會做，流程愈要知道什麼不能由模型自己決定。

最後瓶頸還是判斷力

AI Agent 讓 Mills 與 Brooks 當年的外科手術團隊，第一次有機會以很低的協調成本落地。它讓一個有判斷力的人，開始接近過去一支小型團隊的完整交付能力。

但我不認為結論是「團隊不需要了」。

更準確地說，AI 正在壓縮支援執行的成本，也把主導者的判斷品質放大到以前沒有的程度。方向選對，一個人可以走得很快；方向選錯，一群 Agent 也會很有效率地替你把錯誤做完整、測試補齊、文件寫好。

這就有點微妙了。

以前我們怕的是人太多、溝通太慢。現在可能要怕的是執行太快，快到人的理解跟不上。

在 AI 能獨立承擔系統級決策與後果之前，最稀缺的仍然不是 Token，也不是程式碼，而是那個知道什麼值得做、怎麼切、哪裡不能錯，並且願意為結果負責的人。

封面為 AI 生成概念圖，用水手服主導者與五個機器人 Agent 表現「外科手術團隊」的軟體工程比喻；不代表任何原作者、工具或品牌的官方視覺與合作背書。

參考資料

[1] Chief Programmer Teams — Harlan D. Mills 1971

[2] The Harlan D. Mills Collection — University of Tennessee

[3] Melvin E. Conway, How Do Committees Invent?

[4] 寶玉：AI Agent 與外科手術團隊

[5] Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Addison-Wesley, 1995.

• AI 沒有取消軟體工程：它只是讓程式碼生成變便宜，也讓混亂累積得更快。
• 提示詞只能提醒，工具才能執法：測試、突變測試、複雜度門檻與依賴規則，必須變成 Agent 繞不過去的硬性關卡。
• 不要照抄人類儀式：TDD 的節拍可以調整，但可驗證、可理解、低耦合與責任清楚這些價值不能丟。
• 人類要守住策略：Agent 可以接手更多戰術實作，人仍要決定做什麼、如何切模組、怎樣才算可以交付。

一場從浴袍開始的訪談

一場快一小時的 AI 軟體工程訪談，最先留在我腦中的不是模型名稱，而是一個穿著浴袍、清晨站在前廊抱怨 SQL Injection 的老工程師。

這很 Uncle Bob。看見一個荒謬的技術問題，就先把它說穿。

Robert C. Martin 從 1960 年代一路寫程式到今天。當他開始使用 ChatGPT、Grok 與 Coding Agent，最初也不是一路驚艷，而是不停替 AI 收拾留下來的雜亂。真正讓他改觀的，不是模型突然變得完美，而是他發現：Agent 的速度，可能讓一些過去太昂貴、很難每天執行的品質技術，重新變得實用。

我把這場對談完整翻成正體中文，不是因為裡面每句話都是金句，而是它避開了最無聊的「AI 會不會取代工程師」。它問的是另一個比較實際的問題：

當程式碼可以高速生成，我們要怎麼把品質、架構與判斷，變成 Agent 不能隨便繞過去的系統？

我的結論很直接：AI 寫程式愈快，軟體基本功愈不能省。

Matt 不是陪襯，他把問題一路問到人的位置

只看標題，很容易以為這是一場 Uncle Bob 的單人演講。其實不是。Matt Pocock 沒有只把麥克風遞過去，他一直在替這套看似完整的方法找代價、找矛盾，也把談話從「怎麼讓 Agent 寫得更好」推到「人接下來要怎麼學會判斷」。

• 23:11，Matt 把不同 Agent 的工作慣性命名為 Context Trajectory：同一場 Session 一旦往某個方向走，後續行為就會被那條軌跡影響。清空上下文，不只是省 Token，而是真的換一條思考路線。
• 35:42，他追問一個很現實的問題：五段品質管線這麼昂貴，送進去之前到底該規劃多深？這才把談話帶到規格、Agile 與小步回饋。
• 45:52，他借用 John Ousterhout 的 Tactical／Strategic 區分，問出整場最難的一題：如果 Agent 吃掉戰術工作，新人要去哪裡長出策略能力？
• 52:51，最後也是 Matt 把問題收回軟體基本功：如果基本功仍然重要，理由到底是什麼？

所以這篇不只是整理 Uncle Bob 的答案。它也在整理 Matt 怎麼改變問題的焦距：從程式碼品質，拉到上下文、成本、迭代，最後拉回人的養成。

AI 也會在髒程式碼裡打滑

Uncle Bob 早期使用 Coding Agent 的方式，跟今天常見的 Vibe Coding 很像：叫它做一件事，看到功能會動，就立刻做下一件。留下來的命名、重複、耦合與測試缺口先不管，反正 Agent 跑得很快。

問題是，垃圾也會複利。

很快地，Agent 開始修改 A、破壞 B；修好 B，又把 C 弄壞；最後再回頭破壞 A。畫面上看起來很忙，真正進度卻接近零。Uncle Bob 把這種狀態叫作 Thrashing。

這件事有點重要。Agent 與人的複雜度耐受門檻也許不同，但門檻仍然存在。程式碼同時扛太多責任、依賴方向混亂、測試又薄弱時，模型並不會因為上下文比較長就突然免疫。

速度沒有消滅技術債。它只是讓技術債也能高速生成。

提示詞是提醒，工具才是法律

Uncle Bob 一開始也試過把 TDD、Clean Code、函式大小與各種規則寫進很長的提示詞。問題是，模型會把它們當成《神鬼奇航》裡的海盜守則：比較像參考，不太像法律。

上下文愈長，早期規則愈容易被擠進中段。模型對這些內容的注意力下降，也就是訪談裡談到的 Lost in the Middle。這時再補一句「請記得寫乾淨一點」，通常只是在用文字勸它乖。

更可靠的做法，是把價值觀翻成可以執行的關卡：

• 測試沒有全綠，不能結束。
• 突變體仍然存活，不能交付。
• 複雜度超過門檻，回去拆解。
• 模組依賴逆流，必須反轉依賴、插入介面或重新分模組。
• 端到端行為不符合驗收情境，就不是完成。

提示詞負責說明意圖。工具負責裁決結果。

這也是我認為 AI Coding 工作流真正的分水嶺：不是 Prompt 寫得多漂亮，而是「完成」有沒有被外部系統定義，而且模型不能自己宣布過關。

舊工具遇上新的成本曲線

CRAP 分數與 Mutation Testing 都不是 AI 時代才出現的新發明。它們過去沒有成為所有團隊的日常，不一定是因為沒價值，也可能只是太花時間。

CRAP 把測試覆蓋率與 Cyclomatic Complexity（循環複雜度）放在一起看。路徑很多、測試又不足的函式，風險自然比較高。

Mutation Testing 則故意把程式改壞，例如把 < 變成 >、把 == 變成 !=，再重跑測試。如果測試還是綠的，表示那組測試並沒有真的守住行為。

人會嫌這些工作慢、重複又無聊。Agent 不在乎無聊。

這就是成本曲線翻面的地方：AI 不只降低寫程式的成本，也降低反覆檢查、重跑、修正的成本。真正值得自動化的，未必只是產生更多程式碼，而是把過去「知道應該做，卻常常沒做」的品質流程變成預設路徑。

五階段 Agent 品質管線

Uncle Bob 實驗的 Multi-Agent 管線，把同一項工作依序交給五個短命角色：

1. Specifier：把人的需求整理成 Gherkin 情境與 QA 程式。
2. Coder：先讓功能運作。
3. Cleaner：移除重複、改善命名與結構。
4. Hardener：用 CRAP 與 Mutation Testing 對測試強度找麻煩。
5. QA：從外部驗證整體行為。

單一 Agent 可能五分鐘就能吐出一個看似完成的版本。通過五個角色也許要一小時。訪談裡 Uncle Bob 估計，這仍可能比人類半天的工作快四到五倍；但這是他的實驗估算，不是可以直接套用到每個團隊的保證。

我覺得這套設計最有意思的地方，不是把 Agent 擬人成一間公司，而是上下文隔離。

每個 Agent 只做一件事，完成後退出。下一個角色從乾淨上下文開始，不必繼承前一個角色一路累積的辯解、假設與工作慣性。Coder 想讓東西先動，Cleaner 專心清理，Hardener 則刻意站在對立面找漏洞。

角色分工只是表面。真正被設計的是每段工作的 Context Trajectory。

這個觀察是 Matt 在訪談裡補上的。他指出，同一個上下文不只是裝了多少資訊，也有一路形成的工作軌跡；要真正換掉角色執念，最乾脆的方式就是讓上一個 Agent 結束，下一個從乾淨上下文開始。

當然，Agent 每次重新理解專案都有成本。關卡太多，也可能把速度優勢吃光。所以我不會一開始就照抄五段，而會先找目前最常漏掉的那一關。

測試守行為，架構守理解

完整測試不能替代良好架構。

Uncle Bob 會直接問 Agent：這個系統有哪些模組？彼此怎麼溝通？答案有時會糟到讓他重新檢查整個設計。他因此讓 Agent 建立可以逐層檢視的 UML 架構視圖，另外再用確定性規則限制依賴方向。

這裡可以借用訪談中的「咖啡與連續劇」比喻。模型原本在談咖啡，中途有人塞進一段連續劇，之後每個咖啡話題都可能被那段情節污染。模組也是一樣。如果付款、會員、郵件、報表與快取都擠在同一塊，Agent 很難維持穩定的理解軌跡。

Deep Module 的價值，就是用小而清楚的介面，藏住大量內部複雜度。對人如此，對 Agent 也是如此。

測試告訴模型「系統應該怎麼表現」；架構則告訴它「理解到哪裡可以先停」。兩者解決的是不同問題。

保留價值，不要迷信儀式

這是整場訪談裡，我最認同的一個區分：人類使用的工程紀律，不一定要原封不動搬給 Agent；但那些紀律保護的價值不能丟。

TDD 對人有效，部分原因是人的短期記憶很小。先寫一個測試，再寫剛好讓它通過的程式碼，可以限制同時要處理的資訊。Agent 的上下文容量與工作方式不同，硬逼它照著人類節奏，一次只前進一小格，不一定產生同樣價值。

Matt 把這個回答接回「短期記憶」：TDD 的節拍對人類有幫助，不代表相同儀式對 Agent 也有同樣效益。這讓 values 與 disciplines 的差異不只是 Uncle Bob 的結論，而是兩人一起拆出來的判斷。

可以調整的是 TDD 的節拍、函式大小門檻、複雜度上限，以及每次修改的範圍。

不能丟的是這些東西：

• 行為可驗證。
• 結構可理解。
• 模組低耦合、責任清楚。
• 依賴方向受控。
• 失敗能被確定辨識。
• 系統在修改後仍可維護。

不要把工程方法當宗教。先問它原本在保護什麼，再用適合 Agent 的方式把那個價值留下來。

AI 讓 Agile 又回來了

AI 很會寫計畫，也很會把計畫寫得像真的。

這一段是從 Matt 的追問開始的：既然品質試煉很花資源，工作送進管線前是不是應該把規格做到非常完整？問題看起來合理，也正好暴露「規格最大化」的誘惑。

於是「先讓多個 Agent 把規格磨到極致，再一次完成全部實作」重新變得很誘人。問題是，人不可能預先想到所有細節，Agent 也沒有足夠的策略判斷替我們補完所有缺口。真正開始實作後，現實很快就會把那份華麗規格敲碎。

Uncle Bob 的實驗最後又回到 Agile：選一個小而完整的 Story，做一點、驗證、看架構、重整，再做下一點。

這不是不要規格。是不要把規格當成另一套必須永遠同步的原始碼。規格可以是暫時的，會修改，也可能在完成任務後消失。最後真正能被執行與驗證的，仍是成品、測試與實際行為。

模型愈快，錯誤方向被大量自動化的風險也愈高。小步回饋不是過時的儀式，反而是避免 Agent 一口氣把錯誤做大的保險。

新人怎麼長出策略能力

Matt Pocock 把問題推到最難回答的地方：如果 Agent 已經能做掉很多前線實作，團隊為什麼還要聘請一個做得比較慢的新手？而沒有戰術經驗的人，又要怎麼長成看得懂架構後果的策略工程師？

Uncle Bob 沒有假裝自己有完美答案。他提出的是一條接近學徒制的路：從二進位、電腦基礎、簡單 CPU 與組合語言開始，讓新人親手理解抽象層底下發生什麼；再透過 pair programming，跟著有經驗的人學會判斷。

他也建議去讀那些「老到沒人讀」的軟體工程書。舊書裡當然有過時技術，但模組化、溝通成本、技術債與設計後果，是前人真的付過代價才留下來的知識。

AI 可以壓縮戰術工作，卻也可能一起壓縮新人的練習場。這不是多裝一套 Coding Agent 就能解掉的人才問題。團隊若想得到未來的策略工程師，就得刻意保留能看見因果、能犯小錯、也有人帶著反省的學習路徑。

如果是我，我會先這樣試

我不會把整個系統交給五個 Agent，然後期待一週後收到奇蹟。那比較像把風險藏進自動化裡。

我會先選一個邊界清楚、可回滾、能從需求一路驗證到 UI 或 API 的小 Story，跑一個最小版本：

1. 提示詞只留必要資訊：任務、不可違反的限制、完成定義。
2. 先建立硬性關卡：至少有單元測試、靜態分析與端到端驗收；有餘裕再加複雜度與突變測試。
3. 把清理與加固拆開：不要讓同一個 Agent 一邊為自己的實作辯護，一邊假裝客觀審查。
4. 把架構規則寫成工具能檢查的形式：哪些模組可以依賴哪些模組，不只留在簡報裡。
5. 人類審策略：需求對不對、模組怎麼切、風險有沒有被看見。不是坐在旁邊跟 Agent 比打字速度。
6. 量測整個週期：看 Lead Time、缺陷、回滾、存活突變體與後續維護，不只看第一版生成多快。
7. 每一、兩個 Story 重看架構：方向錯了就早點重組，不讓錯誤乘上 Agent 的速度。

先證明一條小路能穩定走通，再擴大。這很無聊，但 production 通常就是靠這些無聊的事活下來。

最後判斷：基本功不是手工情懷

訪談最後，Matt 再把整場對話壓成一句：軟體基本功聽起來仍然重要，為什麼？

從機器語言、組合語言、高階語言，到今天的模型，每次抽象層往上，總有人說工作要消失了。工作確實會變，複雜度卻沒有跟著消失。它只是搬到新的地方。

AI 可以替人產生更多程式碼，不能讓責任、依賴、行為、風險與維護成本憑空消失。

Clean Code、測試、模組化、架構方向與小步回饋仍然重要，不是因為我們懷念手工寫程式，而是人與模型都需要一套方法，把大到無法承受的複雜度，壓縮成可以理解、可以驗證的形狀。

以前基本功常被嫌慢。現在真正有意思的地方是，AI 或許終於讓我們付得起那個成本。

56 分鐘完整正體中文翻譯

以下依照原影片 00:00 至 56:20 的順序，完整保留來源 HTML 中的 133 段中文翻譯。點時間碼可從 YouTube 對應位置播放。英文原文收在每段下方，方便需要時逐段核對。

翻譯為中文可讀性補上標點、分段並統一技術術語；這不是原作者或頻道發布的官方譯稿。

起點與 AI 初體驗

品質護欄與上下文

Multi-Agent 品質管線

架構、模組與測試

敏捷、規格與迭代

學習、策略與基本功

關鍵術語速查

• CRAP：以測試覆蓋率與循環複雜度辨識高風險函式的品質指標。訪談重點是把它做成 Agent 必須修到合格的關卡。
• Cyclomatic Complexity：衡量程式中獨立執行路徑數量。分支愈多，理解與測試成本通常愈高。
• Mutation Testing：故意改壞程式，再確認測試能抓到。如果測試仍通過，該突變體便「存活」。
• Gherkin：以 Given／When／Then 表達驗收行為的規格格式，讓需求能被人與工具共同閱讀。
• Lost in the Middle：長上下文中，模型較容易忽略中段資訊；開頭與最近內容往往更顯著。
• Context Trajectory：同一個工作階段早期形成的方向，會持續影響後續決策。清空上下文才能真正換軌。
• Deep Module：用小而清楚的介面隱藏大量內部複雜度，降低呼叫者與 Agent 的理解負擔。
• Tactical／Strategic：戰術式程式設計處理眼前實作；策略式程式設計決定系統長期結構、界線與方向。

來源與翻譯說明

• 原始影片：LIVE: Uncle Bob on Software Fundamentals in the Age of AI
• 對談者：Robert C. Martin（Uncle Bob）、Matt Pocock
• 本文依使用者提供的英文逐字稿與正體中文翻譯 HTML 整理。
• 主文中的流程建議與判斷是我的整理，不是逐字引述；完整翻譯區則依原始順序保留全部 133 段。
• 封面為 AI 生成概念圖，用來呈現「高速生成的程式碼通過工程品質關卡」，不是訪談現場或真實人物影像。

影片與英文內容的權利歸原作者與原發布頻道所有。本譯文供中文讀者學習、研究與討論。

• 實驗：拿公共領域的文學經典《金瓶梅》做全方位 AI 重製——結果它同時成了各家模型內容審查的壓力測試。
• 觀察：主流閉源模型連處理「文學裡的成人內容」都會攔截或淡化；Grok 的邊界明顯較寬；開源模型（如 Stable Diffusion）自由度最高。
• 觀點：內容邊界是真實的技術選型維度。供應商把自家價值觀寫進產品，但使用者的合法需求不會因此消失——這正是開源與閉源之爭裡最少被誠實討論的一塊。

為什麼是金瓶梅

我為「金瓶梅宇宙」專案選擇《金瓶梅》，有文學上的理由：公共領域、人物深度罕有敵手、天生適合跨媒介改編。但還有一個技術上的理由，直說了——它是測試 AI 內容邊界的完美題目。

這部明代經典的文學地位無可爭議，Wikisource 與各大文學網站都完整收錄；同時它對情慾的描寫直白不迴避。一個工具如果宣稱能協助「文學創作」與「經典改編」，那它遲早要回答：碰到金瓶梅，你處理還是不處理？

第一手觀察：同一部經典，各家反應不同

在把這部書做成角色研究、影像與遊戲的過程裡，我實際用過市面上主要的文字與圖像生成工具。觀察很一致：

• 主流閉源模型（ChatGPT、Claude 等）：處理到稍微露骨的情色文學段落就會被攔截，或自動淡化改寫；圖像生成更保守，人物「露多一點」就會觸發審查或直接拒絕生成。即使素材是四百年前的公版文學，模型的預設立場仍然是迴避。
• Grok：使用體驗明顯不同，邊界寬鬆許多，願意處理其他模型直接拒絕的內容。這也成為我實際比較各家大語言模型時的一個固定維度。
• 開源模型：自由度最高。我用 Stable Diffusion 生成過很多好看的情色向影像——同樣的需求，線上閉源工具就是做不出來。差別不在能力，在policy。

要強調的是：這不是「想生成違法內容被擋」的抱怨。金瓶梅是合法的公版文學，成人向創作在多數司法轄區也是合法需求。被擋下的，是合法但讓供應商感到不安的那一塊。

這不是安全問題，是產品決策

從技術顧問的角度看，我對「模型會拒絕什麼」的興趣，跟對「模型能做到什麼」的興趣一樣大。因為前者往往不是寫在規格書上的，要實測才知道。

閉源供應商把自家的價值觀直接寫進產品：他們認為自己是對的，於是使用者的需求被預設立場給限制住。每個國家有自己的法規與道德光譜，這完全可以理解——但現狀是，一家公司的內容政策，實質上變成了全球使用者的創作天花板。對創作者來說，這就是「令人無奈」四個字。

而人們對這類內容的需求是真實存在的。假裝需求不存在，不會讓需求消失，只會讓需求流向別的工具——這正是市場正在發生的事。

開源 vs 閉源：最少被誠實討論的一塊

開源與閉源 AI 之爭，大家常談成本、隱私、可控性。我認為內容自由度是同樣重要、卻最少被誠實討論的維度：

1. 閉源模型的邊界是別人劃的，而且會隨政策變動——今天能做的事，明天一次更新後可能就不能做了。
2. 開源模型把邊界還給部署者：自己承擔法律與道德責任，換取完整的創作自由。這才是「每個國家法規與道德不同」的正解——讓在地的部署者依在地的規範自律，而不是由單一供應商替全世界決定。
3. 混合策略是務實解：我的做法是閉源模型做考證、結構化與長文本理解（它們確實強），內容敏感的生成環節交給邊界較寬或開源的工具。「金瓶梅宇宙」整個專案就是這樣完成的。

給選型者的建議

如果你的產品或創作題材可能觸碰內容邊界——文學、影視、遊戲、醫療、性教育都算——選型時請把「邊界實測」列為正式評估項目：

• 拿你領域裡合法但敏感的真實素材去測，不要只測 demo 題。
• 分開測「文字理解」與「內容生成」——同一家模型在兩端的邊界常常不一樣。
• 把「政策變動風險」寫進評估：閉源模型的邊界不是常數。
• 認真評估開源自建的選項，特別是當你的需求合法、但明顯落在大廠舒適圈外。

四百年前，《金瓶梅》的作者選擇直視人的欲望，不假裝它不存在。四百年後，我們的工具反而學會了假裝。這個專案想做的事情之一，就是把這個矛盾攤開來給大家看——順便，把這部經典完整地、一字未刪改地放回線上。

• 做了什麼：讓 AI 讀完《金瓶梅詞話》全一百回，從書中海選角色、建立十張附逐字原文依據的角色卡，再生成三視圖設定圖與擬真選角母版。
• 關鍵不是生圖：是「證據紀律」——每個人物設定都能回指到原文行號，每張圖都經過「圖像觀察 vs 原典證據 vs 裁決」的審查迴圈。
• 成果在哪：角色研究館可以逛，每一頁都附工作底稿；選角流程在影像工作室。

起點：一部小說，能不能長出一個劇組？

假設今天要把《金瓶梅》拍成影集或做成遊戲，第一件事不是寫劇本，而是回答一連串基本問題：這本書裡到底有哪些人？誰重要？他們長什麼樣子、說話什麼調性、彼此是什麼關係？傳統做法是文學顧問讀書做筆記，以月為單位計。

我把這件事交給 AI 工作流，在短時間內走完了全程。這篇文章公開整套方法——不是「一個神奇 prompt」，而是一條有品質關卡的生產線。

第一步：全文入庫

素材是公共領域的《金瓶梅詞話》（萬曆本），取 Wikisource 整理稿，逐回切成一百份結構化文字。這一步看似平凡，卻決定了後面所有環節的品質：每一條人物證據都要能標註出處回目與行號，沒有乾淨的文本庫就沒有可追溯的證據。

（這份文本庫後來也直接變成了站上的原文書房——全文一字未刪改，線上可讀。）

第二步：海選——以及海選的殘酷現實

讓 AI 掃描全書抓「像人名的東西」，粗合併後得到超過一千兩百筆候選。這個數字聽起來很壯觀，實際上充滿污染：同一人的多個稱謂、官職誤判、詩詞裡的典故人物都混在裡面。

這是第一個重要教訓：AI 海選的產出不能直接當結論用。候選名單需要清洗、合併、排名，最後用「出場證據是否充足」的標準篩出經得起驗證的主要角色——我們定為安全前十名：西門慶、潘金蓮、吳月娘、李瓶兒、春梅、陳經濟、孟玉樓、應伯爵、孫雪娥、李嬌兒。

第三步：角色卡——每一句側寫都要有出處

十位角色每人一張卡，欄位包括：身份、性格、外貌、性情、動機、人物弧光、人物關係。規則只有一條：寫得出來的就引原文，引不出來的就標「（推斷）」。

例如潘金蓮的「機變伶俐」不是 AI 的印象分數，是第一回的原文：「本性機變伶俐」；她的善妒也不是刻板印象，是她自己說的：「我眼子裏放不下砂子的人」。每張卡的最後都有一排逐字引文，讀者可以自己去原文書房對答案。

第四步：形象與聲音——把證據翻譯成指令

角色卡完成後，才輪到生成。每位角色產出三份「給 AI 的設定指令」：

• 形象設定指令：中英雙語的角色描述，外加排除條件（negative prompt）——明確禁止現代服飾、幼態比例與情色化構圖。
• 三視圖指令：要求正、側、背三視角同比例、同服裝、同配色，產出可交給美術管線的 model sheet。
• 聲音設定：音色、音高、語速、口音、情緒的文字規格，供語音生成使用。

這些指令全部公開在每個角色頁的「AI 選角檔案」段落——它們本身就是作品的一部分。

第五步：品質關卡——圖像觀察 vs 原典證據 vs 裁決

生成的圖不會直接定稿。每張候選圖走一次三段式審查：

1. 圖像觀察：這張圖實際畫了什麼？（例：候選的潘金蓮披了一件原典沒有的奇幻宮廷披風）
2. 原典證據：書裡怎麼寫？（第二回：毛青布大袖衫、湘裙、白綾高底鞋——逐字列出）
3. 裁決：保留什麼、修掉什麼。（保留臉與漂亮度；服裝依原典重做）

裁決寫成文字記錄，下一輪生成必須回應上一輪裁決。影像工作室裡有完整的實例與定裝迭代對照圖。

心得：AI 的價值在流程，不在單次輸出

這個專案最大的體會：AI 單次輸出的品質天花板不高，但把 AI 放進一條有證據紀律、有審查關卡、有迭代記錄的流程裡，品質就能收斂。十張角色卡、十張三視圖、五張擬真選角母版、加上可線上閱讀的百回全文——都是同一條流程的產物。

成果都在站上：從金瓶梅宇宙進去逛一圈，每一頁都留了工作底稿。如果你的團隊也想把類似流程導入內容生產，歡迎參考AI 視覺內容製作服務。

• 這套 Skills 是什麼：不是一包神奇 Prompt，而是把需求澄清、共同語言、規格、切票、TDD 與 Code Review 寫成可重複使用的工程流程。
• 新手先用哪兩個：先從 /grill-me 與 /implement 開始；工作變大，再加入 /grill-with-docs、/to-spec 與 /to-tickets。
• 為什麼現在重要：模型愈強，做錯事情的速度也愈快。真正開始形成主流的，不會是背更多 Prompt，而是把判斷、授權與驗證固定成 Skill。
• 先別整包無腦裝：原版可能問得太久，/implement 會直接 Commit，目前的文件與平行工作流也有維護風險；應先在個人專案小範圍試用。

一封看起來像行銷信的信

前幾天收到 Matt Pocock 的一封信，主旨大意是：「想讓你的團隊一起用我的 Skills 嗎？午休時把這支影片放給大家看。」

老實說，我原本以為這又是一封標準的課程暖身信。免費影片、免費簡報，最後再把人導向即將推出的付費課程。這個判斷沒有錯，但只看成這樣又有點可惜。

影片裡有一句話讓我停了一下：

AI accelerates software entropy.[1][2]

AI 加速的不只是開發速度，也會加速軟體的混亂。

這句話比「AI 讓每個人都能寫程式」誠實多了。模型可以在幾分鐘內吐出幾千行程式碼，但它不會因為產量變高，就自動知道哪些程式碼值得留下。當結構、命名、測試與模組邊界一路變差，下一次 Agent 進來工作時，面對的就是一個更難理解的環境。

Matt 的另一個說法是：

Code is the agent’s environment.[1][2]

程式碼不只是產出，也是 Agent 下一次工作的環境。

這才是他這套 Skills 真正想解決的問題。免費影片與團隊簡報並不是在教大家記住更多指令，而是在問：當 AI 已經能大量執行，團隊要用什麼方法維持共同理解與工程品質？

Skills 不是 Prompt 收藏

很多人看到 Agent Skill，直覺上會把它理解成「整理得比較漂亮的 Prompt」。技術格式上，Skill 的核心確實常常只是 Markdown；但如果只剩下這個理解，就像把公司 SOP 說成「幾張寫了字的紙」。

真正有價值的是它把一種做事方式固定下來。

Matt 的 mattpocock/skills 把幾個常見工程問題，分別交給不同 Skill：

• 需求還模糊：先讓 Agent 追問，不准急著實作
• 團隊用詞混亂：建立共同語言與決策紀錄
• 工作超過一個 Context Window：整理成 Spec，再切成 Ticket
• 開始實作：從可驗證的邊界做 TDD
• 實作完成：用 Code Review 對照規格與工程標準
• 架構開始腐化：定期找出值得深化的模組，而不是到處做表面整理

截至 2026 年 8 月 8 日研究當下，這個 Repository 約有 20.9 萬 GitHub Stars、1.8 萬 Forks；skills.sh 顯示約 1,430 萬次總安裝。[3][7] 這些數字不能證明它一定提高交付品質，但至少說明 Agent Skill 已經不是少數人在玩的 Prompt 收納術。

它正在變成一個新的工程流程載體。

為什麼模型愈強，Skill 反而愈重要

直覺上，模型愈聰明，我們應該愈不需要工作流。實際上剛好相反。

模型能力弱時，問題通常是「它做不到」。模型能力強之後，問題會變成：

• 它做得到，但做的是不是對的？
• 它改得很快，但有沒有超出範圍？
• 它通過測試，但測試是不是只證明自己寫的答案？
• 它能平行派出多個 Agent，但這些 Agent 會不會同時踩爛同一個 Git 工作目錄？
• 它可以自己 Commit、開 PR、部署，但哪一步應該停下來讓人確認？

能力提高，代表錯誤的爆炸半徑也變大。

所以 Prompt Engineering 不會完全消失，但重心會逐漸移到 Context Engineering、Skill、規格、權限與 Verification。團隊不可能要求每個人每次都臨場寫出完美 Prompt；比較可靠的做法，是把經過驗證的流程寫成大家共用、看得懂、改得動的 Skill。

這也是我認為它會慢慢成為主流的原因。

模型負責理解與執行，Skill 負責提醒它現在扮演什麼角色、遵循什麼工序、什麼叫完成。人則負責決定方向、授權範圍與最後驗收。

三者缺一不可。

安裝方式

目前有兩條主要安裝路線，選一種就好。[3]

Codex 與其他支援 Agent Skills 的工具

npx skills@latest add mattpocock/skills

安裝器會讓你挑選要使用的 Skills 與目標 Agent。第一次導入時，記得一併選取 setup-matt-pocock-skills，再進入每個 Repository 執行一次：

/setup-matt-pocock-skills

它會設定 Issue Tracker、分類標籤與文件存放位置。

Claude Code Plugin

claude plugins install mattpocock-skills

Plugin 是由作者維護、隨版本更新的唯讀整包；npx skills 則是把可編輯檔案複製到你的環境或專案。不要兩種一起裝，不然每個 Skill 會出現兩份，Agent 還沒開始工作，工具箱先自我繁殖。[3]

我的建議是：個人試用先挑少數 Skills，不要看到 29 個現役 Skill 就全部勾下去。工具多不等於流程清楚，通常只是選單變長。

兩條核心工作流

Matt 把工作大致分成兩種。[1][2]

小型工作：一個 Session 可以完成

/grill-with-docs
→ /implement

先透過追問對齊需求、程式碼現況與共同語言；確認工作可以留在同一個 Context Window，就直接進入實作。

大型工作：會跨越多個 Session

/grill-with-docs
→ /to-spec
→ /to-tickets
→ 每張 Ticket 分別 /implement

Spec 是目的地，Ticket 是走到目的地的路徑。[1][2]

每張 Ticket 應該是一個可獨立驗證的垂直切片，不是「先做全部資料庫、再做全部 API、最後才接 UI」的水平分工。[3] 理想的 Ticket 要能在一個乾淨的 Context Window 裡完成，並且交付一條從資料、邏輯到介面的窄路徑。

這種切法其實不新。Tracer Bullet、Vertical Slice、TDD、DDD 與 Deep Module 都是老派軟體工程觀念。比較有意思的是，當模型能力上來之後，這些老觀念突然成為 AI Agent 能否穩定工作的基礎設施。

前幾個月我也整理過 〈gstack 教學：把 Claude Code 變成完整的 AI 開發工作流〉。gstack 比較像替 Claude Code 配上一支角色分工完整的產品與工程團隊；Matt Pocock 的 Skills 則更小、更容易拆解，也更強調由使用者掌握流程。兩者方向不同，但都指向同一件事：不能再把 AI Coding 當成「丟一句話，等它自由發揮」。

六個核心 Skill 怎麼用

1. /grill-me：先把你問到不能再含糊

/grill-me 是無狀態的需求追問工具。它不讀 Repository、不寫檔案，也不一定要拿來談程式。[4]

適合剛冒出來的產品想法、文章主題、商業決策，或任何你覺得「大概知道要什麼，但說不清楚」的問題。

/grill-me
我想替個人網站增加一個顧問需求診斷入口，但不想變成普通聯絡表單。

Agent 會沿著目標客群、使用情境、成功條件、排除範圍與風險一路追問。它的價值不是替你回答，而是逼你承認哪些事情其實還沒決定。

2. /grill-with-docs：把共同語言留在 Repository

/grill-with-docs 會讀取程式碼，並把釐清後的專案術語寫進 CONTEXT.md；重大、難以逆轉、如果沒有背景會顯得奇怪的決策，則寫成 ADR。[6]

這裡借用了 DDD 的 Ubiquitous Language。團隊、領域專家與 Agent 使用同一套詞彙，模型就不用每個 Session 重新猜「這個專案說的會員、客戶、合作案，到底是不是同一種東西」。

3. /to-spec：把已經談妥的內容保存下來

/to-spec 不負責繼續腦力激盪。它的工作是把剛才已經談妥的內容整理成一份 Spec，讓工作跨越 Context Window 之後仍然不至於失憶。

如果工作一個 Session 就做得完，其實可以跳過。每多一層文件，就多一次模型把原意整理歪掉的機會。文件不是愈多愈專業，能維持決策才有價值。

4. /to-tickets：切成 Agent 吃得下的垂直工作

/to-tickets 會把 Spec 拆成帶有相依關係的 Ticket，每張 Ticket 盡量是一個能展示、能測試、能獨立完成的垂直切片。

這一步很適合讓人審查。Ticket 太碎會造成管理成本，太大則會把 Agent 推進 Context Window 的「笨區」。先看切法再批准，比讓五個 Agent 同時開工後才發現拆錯便宜很多。

5. /implement：按照既定決策實作

/implement 接受已經確定的 Spec、Ticket，或同一段對話裡剛談妥的小型計畫。它會執行 TDD、型別檢查與 Code Review，最後 Commit 到目前 Branch。[5]

這個「最後 Commit」不是小細節。執行前先確認 Branch，也建議把 Skill 改成 Commit 前停下來，讓人看過 Diff 與測試結果再決定。能自動 Commit 是能力，不代表每次都該自動 Commit。

6. /improve-codebase-architecture：找出值得重構的地方

這個 Skill 會掃描近期常變動的程式碼，尋找可以把複雜度藏進更小介面的 Deep Module 候選，然後產生一份 HTML 報告。

它只負責調查與提出候選，不直接改程式碼。這個界線我很喜歡：先看哪裡值得投資，再另外開 Session 做設計與實作，避免 Agent 一看到「改善架構」就把半個 Repository 翻修一遍。

實際操作範例

假設我們要替一個個人網站增加「顧問適配診斷」，讓訪客先回答幾個問題，再決定是否進入付費需求診斷。

第一步：先釐清，不准寫 Code

/grill-me
我要替個人網站新增顧問適配診斷。請先追問目標客群、排除條件、輸入、輸出、成功條件與隱私風險，不要開始實作。

如果討論後發現只是單頁、小資料量、無登入，也許一個 Session 就做得完。這時可以在同一段對話輸入：

/implement
依照剛才談妥的內容實作，但不要自動 Commit；完成後先提供 Diff、測試與瀏覽器驗證結果。

第二步：工作變大，就保存成 Spec

如果需求包含後台、Email、付款狀態、權限、資料保存與多個整合點，就不要硬塞在同一個 Session。

/grill-with-docs
/to-spec
/to-tickets

先審查 Spec，再審查 Ticket 是否為垂直切片、依賴是否合理。確認之後，開乾淨 Session，一次只實作一張 Ticket：

/implement #42

第三步：每一張 Ticket 都要重新驗證

不能因為上一張 Ticket 做對，就假設下一張也會對。每次至少檢查：

• Acceptance Criteria 是否真的滿足
• 測試是不是從失敗開始，而不是事後補一個永遠會綠的測試
• Diff 是否超出 Ticket 範圍
• 瀏覽器或外部系統狀態是否真的改變
• Code Review 發現的問題是否已處理，而不是只產生報告

Agent 說「完成」，只代表它停止輸出了。驗證完成，才是真的完成。

這套流程還沒有解決什麼

這套 Skills 很紅，但還不到可以整包搬進團隊、從此高枕無憂。

追問可能太久

/grill-me 官方文件把四輪共 46 題視為普通情況。對大型產品決策可能值得，對小功能就很容易把需求澄清做成口試。[4]

我會把它改成：每輪最多 3 到 5 個最高槓桿問題；遇到必須看介面、資料或原型才能回答的問題，就停止聊天，先做 Throwaway Prototype。

文件可能漂移

/grill-with-docs 會持續寫入 CONTEXT.md 與 ADR。官方文件自己也承認，它比較像單一維護者模式；多人同時使用，文件可能過時、互相矛盾，或把不同主題混在一起。[6]

共同文件必須有 Owner、審查節奏與可自動檢查的 Link／Citation Linter。不然 Shared Context 最後只是另一份沒人敢刪的祖傳文件。

/implement 不會替你管理整個交付生命週期

它不會自動建立 Branch、關閉 Ticket、勾選 Acceptance Criteria，也不會自動修掉 Code Review 的所有問題。這些都還是團隊流程要補上的部分。[5]

更危險的是，在同一個 Checkout 平行跑多個 /implement Session，可能互相踩 Git Index、Stash 與 HEAD。要平行工作，至少使用獨立 Worktree，並把每個 Agent 的 Branch、目錄與權限隔離。[5]

安全掃描不等於值得信任

skills.sh 顯示 /grill-me 通過 Gen Agent Trust Hub、Socket 與 Snyk 檢查，Repository 也採 MIT 授權、內容公開可讀。[3][7] 這些都比來路不明的 Prompt 壓縮包好很多。

但第三方 Skill 可以影響檔案、Git、Issue Tracker，甚至帶著 Agent 呼叫更多工具。正式導入前仍然要逐檔審查、Pin 版本、限制權限，並先放到非敏感的個人或沙盒 Repository 測試。

把一個 Skill 裝進高權限 Agent，跟把一句提示詞貼進聊天視窗，風險不是同一個等級。

團隊要怎麼導入

如果要在團隊推這套方法，我不會從「請大家安裝 29 個 Skills」開始。那不是導入，是把選擇困難分發給每一個人。

比較合理的 Pilot 是：

1. 選一個低風險、範圍清楚、兩週內可完成的需求
2. 只導入精簡版 /grill-me 或 /grill-with-docs
3. 共同審查一份 Spec 與 Ticket 切法
4. 用 TDD、Code Review 與瀏覽器／外部狀態驗證完成一條流程
5. 記錄澄清次數、需求重工、Review Defect、交付時間與人工介入點
6. 回顧哪些規則值得留下，改寫成團隊自己的 Skill

真正的目標不是「全員使用 Matt Pocock 的原版 Skills」，而是讓團隊開始把自己的工程判斷寫成共同資產。

因為別人的 Markdown 再好，也不會自動理解你的產品、風險、命名、權限與組織現實。

最後判斷：主流的會是 Skill，不一定是這一套 Skill

我認為 Matt Pocock 的 Skills 會紅，不只是因為他在 TypeScript 與 AI Coding 圈有影響力，而是它踩中了模型能力提高之後的真正問題。

模型愈來愈會做，團隊反而更需要知道：現在該做什麼、做到哪裡、誰能批准、完成如何證明。

未來主流的 Agent 使用方式，應該不會是每個人各自收藏一百條神奇 Prompt；而是公司、團隊與個人把重要的做事方法，整理成可讀、可版本控制、可稽核、可驗證的 Skills。

Matt 這套不會是唯一答案。它有太多追問、文件漂移、Git 自動化與平行工作的邊角仍要修。

但方向很清楚：

模型能力會逐漸商品化，真正拉開差距的，是你把什麼判斷與工程紀律留在系統裡。

光頭哥不是發明了軟體工程。

他只是很早把那些大家嘴上都說重要、實際上常常懶得做的事情，寫成 Agent 真的會照著走的流程。

這就已經很有價值了。

封面為 AI 生成概念圖，用於表達人類工程師透過 Skills 引導 AI Coding 工作流，不代表 Matt Pocock、AI Hero 或相關工具的官方視覺與合作背書。

參考資料

[1] https://www.aihero.dev/skills/for-your-team — AI Skills for Real Engineering Teams

[2] https://docs.google.com/presentation/d/12WTK21TZQrTffYdZg206dWuy_CWICD7Eud8pZVWzItA/edit — Skills for Real Engineers 簡報

[3] https://github.com/mattpocock/skills — mattpocock/skills

[4] https://www.aihero.dev/skills-grill-me — The /grill-me Skill

[5] https://www.aihero.dev/skills-implement — The /implement Skill

[6] https://www.aihero.dev/skills-grill-with-docs — The /grill-with-docs Skill

[7] https://www.skills.sh/mattpocock/skills — mattpocock/skills on skills.sh

我第一個反應不是興奮，而是先查日期。

結果有點微妙。Coinbase for Agents 並不是 8 月 6 日才上線，它在 6 月 11 日就已經推出；8 月 6 日真正的新消息，是 MetaMask 把 Agent Wallet 的早期存取計畫正式推到檯面上。

這兩件事放在一起看，反而比單一產品新聞更有意思。

兩個月前，我在〈等 AI Agent 開始自己付錢，它們就會回頭找上 Web3〉裡寫過：當 Agent 開始呼叫付費 API、購買資料、搬動資產，Web3 才會從「隔壁產業的基礎建設」變成 AI 真正需要的支付與信任軌道。

現在這件事已經不只停在協議簡報裡。

但我的結論也比當時更保守：

AI Agent 能不能替你交易，已經不是最難的問題。真正難的是，它拿得到多少錢、可以碰什麼、什麼情況必須停，以及出事時誰負責。

先分清楚三種東西

「AI 代理有錢包」聽起來像同一件事，實際上至少有三條不同的產品路線。

第一條：讓 Agent 操作你的交易帳戶

Coinbase 官方文件目前把 Coinbase for Agents 定位得很清楚：它透過 CLI 或 MCP，讓 AI Agent 存取 Coinbase Advanced Trade，查價格、預覽訂單、下單與管理投資組合。

這比較接近「把交易所操作介面交給 Agent」，不是直接把一把鏈上私鑰塞進模型。

官方甚至明白建議使用者另外建立一個 Advanced portfolio，只放入願意承擔風險的資金，再把 Agent 權限限制在那個投資組合。API 權限裡的 Transfer 也只允許 Coinbase 內部投資組合之間移動，不允許提領到外部地址。

這個設計看起來不浪漫，卻很務實。

它承認一件事：如果 Agent 做了意料之外的交易，第一個防線不是期待模型突然良心發現，而是先把爆炸半徑縮小。

第二條：讓開發者替 Agent 建立鏈上金融能力

Coinbase 另一套 CDP CLI／MCP，面向的是開發者。它可以接觸 server wallet、鏈上資料、smart account 與 x402 支付等 CDP 能力。

這跟 Coinbase for Agents 的交易帳戶路線不能混為一談。官方比較頁直接把兩者分開：交易者用 Coinbase CLI／MCP；要建立加密應用的開發者，才使用 CDP CLI／MCP。

其中最值得 AI 圈注意的，仍然是 x402。

它把 HTTP 原本就保留的 402 Payment Required 變成實際支付流程：Agent 呼叫受保護的 API，伺服器回傳付款要求，Agent 用錢包簽署付款，再帶著付款資訊重送請求。Coinbase 的 quickstart 甚至直接示範讓後端 Agent 用 Base 測試網上的測試 USDC 購買 API。

這不是「AI 會用信用卡」的漂亮說法而已。它讓資料、推論、研究報告與線上服務，都可能被切成 Agent 可以自行發現、購買與結算的機器資源。

第三條：給 Agent 一個自託管錢包

MetaMask 8 月 6 日公布的 Agent Wallet，則往另一個方向走。

它是專為 AI Agent 設計的自託管錢包，透過 CLI 接上 Claude Code、OpenAI Codex、Hermes Agent 等代理環境，初期支援 EVM 鏈與 Hyperliquid 上的兌換、永續合約、預測市場與流動性操作。

但它真正有價值的部分，不是支援多少 DeFi 功能，而是把「可以做」和「被允許做」拆開。

預設的 Guard Mode 允許使用者設定每日支出上限、協議白名單與策略規則。交易若超出邊界，就暫停並等待 2FA 人工核准。MetaMask 也表示，每筆交易會經過模擬、威脅掃描與 MEV 保護；另有 Beast Mode 減少中斷，但惡意交易的安全檢查仍不會被關掉。

名字有點中二，架構倒是很誠實：自主性不是開或關，而是分級授權。

真正的產品不是錢包，是 Permission Layer

如果只看新聞標題，很容易把焦點放在「AI 終於能自己交易」。

但交易 API、MCP、CLI、錢包和模型，早就不是最稀缺的東西。真正稀缺的是一套不靠 Prompt 自律的權限系統。

我在〈可上線的 AI Agent，不是更會自主〉裡把 Permission Layer 拆成幾個問題：誰在行動、能用哪些工具、能碰哪些資源、動作風險多高、是否需要核准，以及完成後留下什麼收據。

放到 Agentic Finance，這套問題會更具體：

1. 資金隔離： Agent 操作的是專用投資組合或小額錢包，還是整個主帳戶？
2. 資產範圍： 它只能碰 USDC、BTC，還是任何被包裝成代幣的東西？
3. 動作範圍： 可以查詢、預覽、下單、授權合約、轉帳，還是連外部提領都開放？
4. 額度與頻率： 單筆、單日、單一 session 的上限是多少？連續失敗幾次要停？
5. 對手方與協議： 只能進白名單市場，還是 Agent 自己找到什麼合約都能簽？
6. 核准： 高風險動作是否綁定精確金額、資產、目的地與到期時間？內容改了要不要重批？
7. 證據： 執行後是否留下交易 ID、簽名內容、政策版本、模型提案與人類核准紀錄？
8. 對帳與復原： Agent 說付款完成，鏈上和帳戶餘額真的改了嗎？逾時重試會不會付兩次？

這八題只要有一題的答案是「我們有在 System Prompt 叫它小心」，那就還不能算安全邊界。

Prompt 是行為建議，不是保險箱。

區塊鏈替 Agent 解決了什麼，又沒解決什麼

Agentic Finance 之所以會回頭找上 Web3，不只是因為加密貨幣比較潮。

鏈上系統有幾個天然適合機器的特性：全天候運作、可程式化、結算快速、交易收據可驗證，以及不必替每個 Agent 申請一張塑膠卡。對高頻、小額、跨服務的 API 支付，這些確實比傳統卡片軌道自然。

但區塊鏈不會自動把錯誤判斷變正確。

它能證明某筆交易真的發生過，不能證明那筆交易本來就該發生；智能合約能忠實執行簽名，也可能忠實地把你的錢送進惡意合約；不可竄改的收據有利於稽核，卻也代表執行錯誤之後，通常沒有一個客服按鈕能把狀態倒帶。

Web3 解決的是可執行與可驗證，不是替人消滅責任。

如果是我做 pilot，我會先把 Agent 綁得很不自由

AI 產品展示喜歡把「自主」當成能力上限。真的碰到錢，我反而會從最低權限開始。

第一階段：只讀與提案

Agent 可以查餘額、價格與市場資料，產生交易提案，但不能簽名，也不能下單。先評估它選的資料、推理路徑、風險標記與建議品質。

第二階段：小額、隔離、白名單

使用專用 portfolio 或測試錢包，只放可承受損失的小額資金；限制資產、協議、單筆與每日上限；禁止外部提領。每次執行前先預覽交易，執行後回讀外部狀態並對帳。

第三階段：開放低風險自動執行

只有通過足夠測試、錯誤率與事件回顧的固定流程，才允許低額自動化。高額、陌生合約、新目的地、槓桿與策略邊緣情況，仍然進人工核准。

第四階段：用事故來驗收，不用順利 Demo 來驗收

故意測試行情劇烈波動、API 逾時、重複回應、價格滑點、惡意合約、錯誤鏈別、政策版本變更與人類逾時未核准。Agent 能在該停的地方停下來，比它在順風時完成十筆交易更有價值。

這聽起來不夠「全自主」。

很好。錢包不是拿來替產品簡報製造高潮的。

對企業真正有價值的，不一定是自動炒幣

Coinbase 與 MetaMask 的新聞最容易讓人想到交易，但 Agentic Finance 比自動買賣大得多。

比較可控的企業場景可能是：Agent 依預算購買 API 或資料；替全球工作流進行小額穩定幣結算；在固定供應商白名單內支付雲端或數位服務；監控資金部位並提出再平衡建議；或者在財務人員核准後執行重複、規則明確的轉帳。

這些場景的共同點，不是模型多會猜市場，而是事件到結算的路徑可以被縮短，同時每一個權限邊界仍然能被檢查。

所以我會把導入問題從「哪個模型最會交易」改成：

哪一條事件到付款／交易完成的流程，值得先縮短；其中哪一個步驟，真的可以安全地交給 Agent？

如果這題答不出來，先不要急著幫 AI 開戶。

最後判斷：Agent 有錢，不代表 Agent 長大了

Coinbase for Agents、CDP、x402 與 MetaMask Agent Wallet 放在一起，已經拼出 Agentic Finance 的基本零件：交易帳戶、鏈上錢包、支付協議、模型工具介面與安全閘門。

我先前說，等 AI Agent 開始自己付錢，它們就會回頭找上 Web3。現在看來，這個方向沒有錯。

但下一步真正決定市場能不能走下去的，不是再多一個「一鍵自動交易」按鈕，而是誰能把隔離、額度、白名單、核准、收據與責任歸屬做成預設值。

AI 可以提出動作，錢包可以簽名，區塊鏈可以結算。

最後仍然要有人把界線畫清楚。

不然所謂的 Agentic Finance，只是把「手滑」升級成可以 24 小時高速執行而已。

本文為技術與風險架構分析，不構成投資建議。封面為 AI 生成概念圖，用於說明資金隔離、權限閘門與人工核准，不是 Coinbase 或 MetaMask 的產品介面或合作背書。

參考資料

• Coinbase：Coinbase for Agents
• Coinbase Developer Documentation：Coinbase for Agents（CLI／MCP）
• Coinbase Developer Documentation：Comparing our Agentic Tools
• Coinbase Developer Documentation：x402 Buyer Quickstart
• MetaMask：Introducing MetaMask Agent Wallet（2026-08-06）
• 動區動趨：Coinbase for Agents 正式上線（2026-06-12）

裡面不是塑膠玩具，而是 CryptoPunk、無聊猿、Azuki、Pudgy Penguin、Doodles 與 Meebits。每一枚 NFT 後面還鎖著一筆 ETH。你付錢按下按鈕，Chainlink VRF 幫你抽出其中一個部位，然後你再決定：留下 NFT，或把它賣回原存款人。

這聽起來很像賭場把 DeFi 穿在身上。

但如果只停在「NFT 抽卡」，反而低估了 Fake World Assets，簡稱 FWA，真正有意思的地方。它把 NFT 做市、隨機分配、預先資助的買回報價、手續費與代幣補貼，塞進同一個交易流程。

我不是完全站在場外看熱鬧的人。2021 年，我曾把自己的制服女孩攝影做成 NFT，也一路做過 UCX／Uniform CloneX。幾年後回頭看，NFT 最難的從來不是「能不能發」，而是發完以後，誰願意買、怎麼成交，以及流動性退掉後還剩下什麼。

FWA 正面處理了這個老問題，只是它用的方法非常 Web3：如果每一枚 NFT 都很難各自找到買家，那就不要讓買家選。

我的結論先放前面：FWA 的市場設計值得拆解，但不能把精巧的機制，直接翻譯成值得重押的投資結論。

資料與協議參數截點：2026 年 7 月 25 日。本文依 FWA 官方文件與公開合約說明整理，不構成投資建議。

從 RWA 到 FWA：這個名字本身就在唱反調

過去幾年，加密市場一直在談 RWA，也就是現實世界資產。國債、股票、黃金、不動產與應收帳款被搬上鏈，目標是把現實世界的所有權、現金流與結算活動，接進 24 小時不停機的鏈上金融。

Fake World Assets 故意往反方向走。

它不把房子或債券搬上鏈，也不靠倉庫替一張實體收藏卡背書。它使用的原料本來就出生在鏈上：NFT、ETH、智能合約、隨機數與代幣。

所以這裡的「Fake」不是偽造，更不是替詐騙開脫，而是對 RWA 敘事的一次反向命名。RWA 想證明區塊鏈能容納現實資產；FWA 則反問：加密原生資產一定要長得像傳統金融，才配被當成資產嗎？

官方文件顯示，主網上線時的許可清單共有 16 個系列，包括 CryptoPunks 721、Milady Maker、Bored Ape Yacht Club、Azuki、Doodles、CrypToadz、Pudgy Penguins、Meebits、Checks、VeeFriends、mfers 與 DeadFellaz 等。核心協議本身不依賴特定系列，但新部位能否進場，仍受當下鏈上白名單設定影響。

更準確地說，FWA 不是一種新 NFT。它創造的是一種新的市場部位：

NFT ＋ ETH 擔保金 ＋ 被抽中的機率 ＋ 一個預先寫好的買回承諾。

先拆掉扭蛋機的外殼

FWA 的基本流程可以拆成四步。

1. 存款人把一枚支援的 ERC-721 NFT 與一筆 ETH 一起鎖進協議，形成獨立部位。
2. ETH 擔保金同時決定抽中權重，並替存款人預先資助一個不可撤回的常駐買價。
3. 抽卡者支付由獎池計算出的 acquisition price，加上獨立的 VRF 服務費；Chainlink VRF 提供隨機數，請求依建立順序結算。
4. 抽中後，使用者可以留下 NFT、帶著新擔保金直接重新上架，或接受原存款人的買價，以 ETH 或 FWA 代幣結算。

概念拆開之後，再看實際產品會比較清楚。FWA 的獎池不是一排待售商品，而是一圈同時帶著擔保金、稀有度與抽中機率的部位；抽卡者買的是整個池子的隨機分配，不是點名其中一張。

這使 FWA 落在幾種產品的交界處。

它不是一般 NFT 市場，因為買方不能指定要哪一枚；它不只是抽獎，因為抽中後還有保留、重掛與賣回等選項；它也不是普通質押，因為存款人鎖入的不只資金，還有一枚可能被別人帶走的 NFT。

它比較像一個用隨機分配取代指定成交的 NFT 流動性市場。

66 ETH 不是附贈獎金，而是一扇退出門

FWA 最容易讓人看錯的詞，是「backed by ETH」。

假設某枚 CryptoPunk 背後放了 66 ETH。這不代表抽中後能同時抱走 Punk 與 66 ETH。那筆 ETH 是原存款人的擔保金，也是他事先放進合約的買回資金。

抽中者留下 CryptoPunk，原存款人就拿回擔保金；抽中者若不想留下，則可接受常駐買價，把 NFT 賣回原存款人。

依官方目前列出的預設 85% depositor bid rate，66 ETH 對應的買回結算是 56.1 ETH。使用者也可以讓同一筆結算金額透過協議買進 FWA，改領代幣。

兩邊不能一起拿。

從金融結構看，抽中者得到的不是「NFT 加現金」，而是 NFT 加上一個內嵌的退出選項。存款人則站在另一側：他承諾在抽中者不要 NFT 時，以事先鎖好的資金把它買回。

這就是 FWA 的雙向報價：

• NFT 被帶走，存款人取回擔保金，扣除預設 1% 的 protocol settlement cut；
• NFT 被退回，存款人取回 NFT，抽中者取得預設 85% 擔保價值；
• 其餘折價預設留給協議，但管理參數可以改成分給存款人。

所以擔保金不是越高越神，也不是越低越划算。比較合理的設定，是一個兩種結果發生時，存款人都能接受的價位。

真正精巧的地方，是低價部位決定票價

一般抽獎只要放進一個超高價頭獎，票價就得跟著上升，否則期望值會失控。

FWA 的處理方式，是讓抽中權重與擔保金成反比：

weightᵢ = K ÷ backingᵢ

擔保金越低，權重越高，越容易被抽中；擔保金越高，權重越低，通常會在池中停留更久。

每一抽的期望擔保價值，等於池內擔保金的調和平均數。再乘上預設 10% surcharge，才得到 pool acquisition fee；另外還有 VRF 服務費、Gas 與可能的滑價。

這裡的調和平均數很重要。它對小數值特別敏感，因此大量低擔保部位會壓住每一抽的價格；少數高擔保 Punk 很搶眼，卻因為權重極低，不會等比例把票價推上去。

用圖中的簡化池來看，0.05、0.5 與 5 ETH 三個部位，抽中機率約為 90.09%、9.01% 與 0.90%。三者的算術平均是 1.85 ETH，但調和平均只有約 0.135 ETH；加上 10% 後，pool acquisition fee 約 0.149 ETH。

那枚 5 ETH 部位讓畫面看起來很豪華，真正決定大多數人會抽到什麼的，卻是 0.05 ETH 那一區。

巨額擔保金沒有免費增加玩家的期望值。它主要增加的是敘事張力。

頭獎負責吸引目光，倒數權重負責讓數學不要破產。這就有點像把一座金光閃閃的城堡放在遠方，再把通往城堡的橋做得比頭髮還細。

存款人是莊家嗎？只說一半

FWA 常把存款人描述成站在莊家那一側。這個比喻好懂，卻容易讓人誤以為存款人天然占優勢。

官方費用設計是：每次 acquisition fee 扣掉協議抽成與 crown tithe 後，平均分給所有有效部位。每個部位當下拿到的份額相同，跟它背後放 0.05 ETH 還是 5 ETH 無關。

差異發生在時間。

高擔保部位比較難被抽中，通常能留在池中更久，累積更多次費用與代幣獎勵；低擔保部位容易快速離場。若池子在簡化期間保持不變，某部位的預期存活抽數會隨擔保金增加，於是「每抽分得相同」與「高擔保活得更久」組合起來，才形成官方所說的平均生命週期收益。

但期望值不是保固書。

理論上應停留一百抽的 NFT，仍可能第一抽就被選中。部位一結束，後面的手續費、FWA 排放與 top deposit reward 機會也一起消失。

存款人賺的不是固定利息，而是在承擔一場時間樂透。抽卡者賭抽中哪一枚，存款人賭自己的部位何時被抽走。

兩邊只是站在隨機性的不同方向。

Loss-to-Earn：它沒有消滅虧損，只是替虧損換了名字

FWA 最會讓人停下來看的詞，大概是 Loss-to-Earn。

假設你花 0.1 ETH 抽卡，卻拿到市場吸引力不高、常駐買價也偏低的 NFT。用 ETH 計價，這次結果可能就是虧損。

FWA 接著提供另一個選項：不要拿 ETH，改把結算金額換成 FWA 代幣。

初始代幣分配中，50% 用來建立 FWA／ETH 市場，30% 進入 15 天排放，20% 用於 v1 snapshot claims。排放的 30% 再平均拆成兩邊：存款人每天取得總供應量 1%，成功抽卡者每天也分 1%，各持續 15 天。

外部買入在初期由管理者控制並預設關閉，但賣出維持開放；一般錢包之間的直接轉帳也受限制。早期代幣因此主要透過實際使用協議取得，而不是讓外部資金直接進場買。

這確實能處理雙邊市場的冷啟動問題：沒有 NFT，抽卡者不來；沒有抽卡者，存款人也沒有理由鎖資產。代幣同時補貼兩邊，先把供給與需求叫進房間。

但「領到 FWA」不等於「已經回本」。

你只是把一筆較明確的 ETH 結算價值，換成尚在價格發現中的代幣曝險。外部買入受限甚至讓初期價格更難被當成自然市場需求的證據。

Loss-to-Earn 沒有把損失擦掉。它只是把「這一抽虧了」重新敘述成「我取得一個早期代幣部位」。

這不是魔法，是風險轉換。

真正的考試，是排放結束與回購開關

任何有代幣補貼的協議，上線初期活動量通常混著三種需求：真的喜歡產品、想追稀有 NFT，以及單純想拿排放。

補貼存在時，很難分辨誰是誰。

FWA 的第一場壓力測試，是 15 天排放結束後，使用者還願不願意用 ETH 抽卡。若抽卡量下降，存款人分到的費用減少；存款人撤出後，獎池數量與品質下降；池子變差，又進一步降低抽卡需求。

正向飛輪很漂亮。反向轉的時候也完全不會客氣。

官方設計了 protocol fee 買回 FWA 的路徑；買回後預設按 40%、40%、20% 分給存款人、抽卡者與銷毀。但官方參數頁同時寫得很清楚：protocol-fee → FWA 的預設比例是 0%，也就是關閉。

「合約裡有回購函式」和「現在真的有協議收入持續回購」，是兩件完全不同的事。

因此，研究 FWA 不能只問「有沒有回購」，而要繼續問：

• 協議實際產生多少收入？
• protocolFeeToTokenBps 當下是多少？
• 買回金額能否承接排放與早期持有人的賣壓？
• external FWA buys 是否開放？市場深度足不足以承受價格發現？
• 沒有每日 1% 排放後，抽卡者還願不願意付 ETH？

最後一題，才是 FWA 的測謊機。

FWA 真正創新的，不是把 NFT 變成彩券

撇開 FWA 代幣價格，我認為這套協議至少留下三個值得研究的方向。

第一，它把 NFT 流動性問題遊戲化

傳統市場要求賣家等待某位買家剛好看中自己的 NFT。FWA 不替每一枚 NFT 精準找買家，而是把所有需求集中到同一個池，再用隨機分配把需求散出去。

它沒有直接解決價格發現，而是繞過「買家必須指定商品」這個限制。

第二，它把 NFT 與報價綁成同一個部位

NFT 進入 FWA 後，不再只是收藏品。它同時帶著抽中權重、退出價格、資金占用、費用現金流與隨機終止風險。

這讓 NFT 從靜態物件，變成一份會累積收益、也可能突然結束的金融部位。

第三，它把娛樂放進流動性機制，而不是放在旁邊

很多 DeFi 產品像試算表穿上西裝，功能都在，卻沒有讓人想再用一次的理由。

FWA 從相反方向出發：先做成一台讓人手癢的扭蛋機，再把做市、報價、費用、回購與代幣分配藏進齒輪裡。

這也是為什麼，即使 FWA 代幣最後表現普通，它的機制仍可能被別人搬走。隨機分配、預先資助的常駐買價、雙邊補貼與可程式化退出選項，都可以被移植到其他鏈上資產。

投資人真正該看的五種風險

一、抽卡期望值不是只看擔保金

公式能精確計算 ETH backing，卻不能替每枚 NFT 算出「今天真的賣得掉的價格」。完整期望值還要納入 NFT 可實現價值、VRF 服務費、Gas、滑價、FWA 獎勵與代幣流動性。

看到有人抽中高價 Punk，只能證明頭獎存在，不能證明平均玩家划算。

二、NFT 價值是文化市場，不是合約變數

協議知道某個部位放了多少 ETH，不知道市場明天還喜不喜歡那隻猿、那張像素臉或那個企鵝。

數學可以替擔保金定價，不能替品味定價。

三、存款人承擔路徑與存活時間風險

高擔保只能降低被抽中的機率，不能保證部位活到平均壽命。早抽中會提早終止費用與代幣累積；新部位持續進場，也會稀釋每個有效部位分到的費用。

四、FWA 代幣承擔不對稱的價格發現

初期外部買入預設關閉、賣出保持開放，排放又集中在 15 天。這能塑造取得路徑，卻不能保證代幣具有足以承接賣壓的自然需求。

領到多少顆代幣，和最後能換回多少 ETH，是兩個問題。

五、保管安全不等於經濟政策不會變

官方文件表示，管理者不能拿走存款人的 NFT 與擔保金，但可以暫停部分操作、調整經濟參數、管理外部買入與申領閘門、改變未來費用流向。

資產是否會被直接拿走，與遊戲規則會不會改，是兩個不同層次的風險。前者受限制，不代表後者不存在。

我會怎麼觀察這台扭蛋機

如果要判斷 FWA 是短期代幣活動，還是一種能留下來的 NFT 市場，我不會先看社群有多興奮，而會看這六個訊號：

這些數據不會像「某人一抽中 Punk」那麼好傳播，但比較接近協議能不能活下去的答案。

結論：值得拆解，不值得浪漫化

FWA 是一套很有創意的市場機制。

它把 NFT 抽卡、流動性提供、內嵌買回報價、代幣排放與協議收入，整合成一個讓人想按下去的產品。它甚至把 NFT 市場最尷尬的問題——沒人剛好想買你手上那一枚——改寫成「反正你也不能選」。

很荒謬，但也真的很聰明。

只是創意不等於低風險，熱鬧也不等於可持續。對參與者來說，比較務實的做法，是把抽卡預算當成娛樂費，不要當成期望報酬已知的投資。

尤其不要因為領到 FWA，就先把代幣數量算成回本。那只是把一種風險換成另一種風險，宇宙帳本沒有因此自動對平。

Fake World Assets 真正賣的，或許從來不只是一枚 NFT。

它賣的是流動性、退出選項、等待時間、稀缺感，以及「下一抽也許會不同」的期待。

我會繼續看這台機器怎麼轉。

但先不把錢包交給它替我思考。

視覺說明：封面為 AI 生成概念圖，使用多個 NFT 系列的風格化視覺暗示，不是官方專案圖像或合作背書；三張技術圖為本文原創機制示意與作者試算；兩張實際介面截圖引用自 Bankless，僅作評論與機制說明。

參考資料

• Bankless：A Beginner’s Guide to Fake World Assets（機制導讀與實際介面截圖來源）
• Fake World Assets：How it works
• Fake World Assets：Positions & weighting
• Fake World Assets：Pricing & allocation
• Fake World Assets：Collections
• Fake World Assets：Settlement
• Fake World Assets：Fees & protocol revenue
• Fake World Assets：$FWA
• Fake World Assets：Safety
• Fake World Assets：Parameters
• 延伸閱讀：制服女孩上鏈——攝影作品踏入 NFT 世界的第一步

到了正式環境，問題完全不同。它必須在正確的指令下工作，使用可以追溯的資料，把長任務的進度留在模型之外，並且在碰到外發、覆寫、刪除、付款或部署時停得下來。

模型能不能呼叫工具，反而是比較簡單的部分。

ByteByteGo 在 2026 年 7 月發表的〈Best Practices for Building AI Agents That Work in Production〉，把 Production Agent 的工程問題整理成 Context、Control Flow、State 與 Scope。這四個面向很適合當共同基線，但若要拿來做企業導入、技術審查與上線驗收，我會再重排一次：

Instruction／Context、Evidence、State、Permission。

這不是替原文換四個英文名詞。原文主要在說 Agent 如何穩定運作；我想處理的是另一個問題：當 Agent 說它完成了，我們憑什麼相信；當它想採取行動，系統憑什麼允許。

先給結論：正式環境要控制的不是模型，而是四個介面

1. Instruction／Context：它依什麼規則工作？ Prompt、技能、工具說明與執行期脈絡必須可組合、可版控、可測試。
2. Evidence：它依哪些事實做判斷？ 結論要能回指來源，完成狀態要附機器可檢查的證據。
3. State：工作做到哪裡？ Run、Step、產物、錯誤、核准與 checkpoint 必須存在模型之外。
4. Permission：它被允許做什麼？ 身分、資源範圍、風險等級與人工核准要由程式強制，不靠 Prompt 拜託模型自律。

Scope 仍然重要，但我把它視為包住四層的外框：每個 Agent 都要有單一責任、清楚停止條件，以及可交給人或其他 Agent 的交接格式。

為什麼我要重排 ByteByteGo 的四個原則

原文的分類適合解釋 Production Agent 的設計重點；控制面分類則比較適合拿來做架構審查。兩者的關係如下：

我另外抽出 Evidence，原因很直接：資料曾經放進 Context，不代表輸出的主張有被資料支持；工具曾經回傳成功，也不代表任務真的完成。

這兩個落差，正是很多 Agent Demo 一進正式環境就開始欠債的地方。

第一層：Instruction／Context 不是一份愈寫愈長的 Prompt

早期 Agent 常把角色、政策、工具用法、輸出格式與例外處理全部塞進一份 System Prompt。人少、流程短時還能工作；規模一大，修改一行文字的影響範圍就很難判斷。

Google Developers Blog 在 2026 年 7 月提出 modular prompt transpilation：把指令拆成可重用模組，在建置時解析 import、變數與相依關係，輸出一份可重現的執行產物。它處理的其實是很熟悉的軟體工程問題：

• 缺少的模組應在建置時失敗，不要等到執行特定任務才爆炸；
• 未定義變數與循環相依要能靜態檢查；
• 原始模組重新建置後，應能和已提交的 golden artifact 比對 drift；
• Agent 可以提出指令修改，但修改應走 Pull Request、測試與人工審查，而不是在執行中偷偷改寫自己。

因此，Instruction Layer 至少要分成兩種東西：

穩定控制面

身分、不可違反的安全邊界、工具契約、資料政策、輸出格式與升級規則。這些規則要有版本，變更要能 diff、review、test 與 rollback。

任務脈絡

這次工作真正需要的檔案、資料、使用者偏好、前一步結果與少量相關技能。它應按需載入，不是把整個知識庫倒進 Context Window。

Context Window 是容量，不是注意力保證。資訊放得進去，不代表模型會在第十八步仍然抓對版本、記得哪個例外或分清楚哪段資料已過期。

一個可以被稽核的執行紀錄，至少應回答：

instruction_artifact: agent-policy@2026.07.23+sha256:...
loaded_skills:
  - research@3.2
  - approval-first-actions@1.4
runtime_context:
  task_id: run_...
  source_snapshot: evidence_set_...
  policy_version: policy_...

這只是概念結構，不是某個產品的固定 API。重點是：日後追查結果時，必須知道模型當時到底看到了哪一套規則。

第二層：Evidence 把「我覺得完成」改成「我能證明完成」

Ground Truth 檢查常被理解成「讓模型多查一次資料」。這還不夠。

Evidence Layer 要保存的是可追蹤關係：哪個主張來自哪個來源、哪個產物由哪個工具產生、哪個驗收條件由什麼檢查通過。它不能只留下模型最後整理過的摘要，因為摘要本身仍可能失真。

Anthropic 在 Claude Science 的公開案例中提到，Allen Institute 的研究者建立了多 Agent 文獻回顧流程。Sub-agent 從大量論文擷取核心主張與量化發現，存進 evidence state database；後續寫作與圖表直接從該資料庫取用，並用 actor-critic 配對，讓一個 Agent 產生內容、另一個 Agent 檢查準確性與引用忠實度。

這個案例值得注意的不是「一次讀了很多論文」，而是它把研究流程拆成：

1. 先建立結構化證據；
2. 再根據證據寫作；
3. 另外執行引用與正確性審查。

套到企業 Agent，一張最小 Evidence Card 可以包含：

{
  "claim_id": "claim-017",
  "source_uri": "https://example.com/source",
  "source_snapshot": "sha256:...",
  "excerpt": "支持這個主張的原始片段",
  "retrieved_at": "2026-07-23T10:00:00+08:00",
  "verifier": "rule-or-reviewer-id",
  "status": "supported"
}

Evidence Layer 也要處理「完成」的證據。為每種任務定義 Completion Contract：

• 目標是什麼；
• 哪些條件全部成立才算完成；
• 每個條件需要哪種證據；
• 哪些失敗可以重試；
• 哪些情況必須停下交給人；
• 最終產物與執行收據存在哪裡。

例如「網站文章已完成」不等於 Markdown 已寫完。它可能還需要：建置成功、圖片存在、內部連結可解析、手機版無水平溢位、正常 Production Build 排除未核准草稿。缺一項，狀態就不應該是 completed。

第三層：State 不能寄生在對話紀錄裡

模型本身可以是無狀態的；工作不行。

ByteByteGo 原文主張把計畫、進度、工具結果與 checkpoint 外部化，讓任務可以恢復、重放與水平擴充。這也是長流程 Agent 是否能進正式環境的分水嶺。

對話紀錄適合讓人理解發生過什麼，卻不適合當唯一狀態來源。它通常同時混著使用者需求、模型推理、工具輸出、錯誤、重試與後來被推翻的決定。Context compaction 一發生，細節還可能被壓成摘要。

最小可用的 State 應把這些欄位拆開：

• run_id 與目前 step_id；
• 任務狀態與允許的下一個轉移；
• 指令、資料與政策版本；
• 已完成條件與待完成條件；
• 產物位置、hash 與驗證結果；
• 待核准動作與核准對象；
• 錯誤類型、重試次數與 idempotency key；
• checkpoint 與最後一次成功提交時間。

外部狀態帶來三個實際好處。

第一，模型或 Provider 可以更換。新模型接手的是同一份結構化 Run，不必從整段聊天猜測工作做到哪裡。

第二，失敗可以恢復。工具 timeout 時，系統能判斷工作是否其實已送出，而不是讓 Agent 一重試就重複寄信、重複付款或重複部署。

第三，責任可以交接。人類接手時不必重看一萬行 transcript，只需要目前狀態、相關證據、已做決定、阻塞原因與下一個允許動作。

第四層：Permission 必須由模型外部強制

Prompt 可以描述行為規範，不能充當安全邊界。

你可以在 System Prompt 寫十次「刪檔前先詢問」，但只要 Tool Gateway 仍允許模型直接刪除，這條規則就只是良好意圖。真正的 Permission Layer 必須同時知道：

• 目前是誰或哪個 Agent 在行動；
• 可以使用哪些工具；
• 可以碰哪些資源、路徑、帳號與資料分類；
• 這個動作屬於哪個風險等級；
• 是否需要核准，以及核准綁定的精確 payload；
• 動作完成後要留下什麼 receipt。

我會把常見動作分成四級：

1. 讀取與分析：在明確資料範圍內可自動執行，仍要記錄來源與存取結果。
2. 本機可逆修改：可以產生草稿或 patch，但要保留 diff、測試與 rollback 路徑。
3. 對外或共享寫入：寄送、發布、建立遠端資源與修改共享資料，預設先產生 preview，再核准精確收件人與內容。
4. 不可逆或有金錢影響的動作：刪除、付款、部署、權限變更與憑證操作，必須使用強制核准、冪等保護與事後對帳。

核准也不能只是一個模糊的 approved: true。比較可靠的做法，是把核准綁定到 action fingerprint：工具、目標、關鍵參數、內容 hash、成本上限與到期時間。任何欄位在核准後改變，就要重新核准，避免人批准的是 A，Agent 最後執行的卻是 B。

Hermes Agent v0.19.0 的公開 Release 把 smart approvals、Bitwarden／1Password secrets provider、live subagent transcript 與 durable delivery ledger 放進同一次版本更新。它們解決的面向不同：approval 判斷能不能做、secret provider 控制憑證怎麼取得、live transcript 提供過程可見性、durable delivery 確保完成回覆不因 Gateway crash 消失。這正好說明安全與可靠性不會由一個「更聰明的 Prompt」包辦。

我先前在〈我讓 Hermes Agent 串上 OpenRouter 生影片〉的實作裡，也踩過這條界線。當時付費提交前有人工核准流程，但 plugin 的 submit() 本身沒有 approval token；若有人繞過工作流直接呼叫，API 仍會送出。那套流程適合個人受控實驗，若要變成多人服務，就必須把核准從「流程紀律」升級成「程式 hard gate」。

Control Flow 的核心：外圈確定，內圈才交給模型

ByteByteGo 原文有一句很實用的原則：大多數 Production Agent，應該是確定性流程包住少數模型決策點。

我會把一次工具動作拆成八步：

1. 載入固定版本的 Instruction Artifact；
2. 從外部 State 取回目前步驟；
3. 只組裝這一步需要的 Context 與 Evidence；
4. 讓模型提出結構化 action proposal；
5. 用 schema、ground truth 與規則驗證 proposal；
6. 由 Permission Layer 決定執行、拒絕或等待核准；
7. Tool Gateway 執行後保存 receipt，再原子更新 State；
8. Completion Contract 判斷繼續、重試、交接或完成。

模型可以決定「下一個合理動作是什麼」，但不能自行改寫 state transition、放寬工具權限、把驗證失敗改成成功，或宣布自己已通過 Completion Contract。

這種設計看起來比「給 Agent 一個目標，讓它自己想辦法」保守。正式環境需要的正是這種保守。

ByteByteGo 用一個示意例子說明長流程的複合風險：如果二十個步驟各自都有 95% 成功率，在假設每一步相互獨立的簡化條件下，全程一次成功率只有約 35.85%。這不是任何實際 Agent 的 benchmark，而是提醒我們：步驟愈多，checkpoint、局部重試、驗證與人工接手愈不能省。

Scope 與 Human Handoff 不是失敗處理，是正常路徑

Agent 的職責愈寬，評估資料就愈難準備，權限也愈難收斂。與其做一個「公司萬能助理」，不如先做一個能清楚說明輸入、輸出、工具與停止條件的窄 Agent。

Scope 至少要寫清楚：

• 接受哪些任務；
• 明確拒絕哪些任務；
• 可以讀取與修改哪些資源；
• 最長執行時間、最大成本與最大重試次數；
• 哪些訊號代表資訊不足；
• 哪些情況必須轉交人或其他專責 Agent。

一份合格的 Handoff Package 不需要很長，但要完整：

run_id: run_...
goal: "本次工作目標"
current_state: awaiting_human_review
completed_conditions:
  - source_verified
  - draft_built
pending_conditions:
  - owner_visual_approval
artifacts:
  - uri: ...
    sha256: ...
blocked_reason: "需要內容所有者確認視覺與對外發布"
next_allowed_action: "等待核准；不可發布"

人類接手不代表 Agent 失敗。Agent 在該停的地方停下來，並把完整脈絡交出來，才是正式系統的成功行為。

一份可以拿去做 Pilot 的最小驗收表

Instruction／Context

• Prompt、技能與工具說明是否有版本、owner 與變更紀錄？
• 是否能從原始模組重建相同的執行產物？
• 是否有靜態檢查、eval 與 rollback？
• 執行紀錄能否指出當時載入哪些版本？

Evidence

• 關鍵主張能否回指原始來源與 snapshot？
• 工具成功是否有 receipt，而不是只保留模型轉述？
• Completion Contract 是否定義完成條件與必要證據？
• 產生者與 reviewer 是否在流程上分離？

State

• Run／Step／Artifact／Approval 是否存在模型之外？
• 任務能否從 checkpoint 恢復，而不是重跑全部步驟？
• 寫入與付費動作是否具備 idempotency key？
• 換模型或人工接手時，是否不必重新閱讀完整對話？

Permission

• Tool Gateway 是否有真正的 allowlist、scope 與資源邊界？
• 核准是否綁定精確 action fingerprint 與到期時間？
• 核准後 payload 改變時，系統是否強制重批？
• 每個外部副作用是否留下可對帳 receipt？

只要其中一層仍然回答「靠模型自己注意」，就還不適合把權限往上加。

最後判斷：Production Agent 的成熟度，看它如何被約束

模型能力會繼續上升，Agent 也會愈來愈能自己規劃、使用工具與持續工作。這些進步會提高上限，卻不會自動補上治理。

真正可上線的 Agent，不是最敢自主行動的那一個，而是出了問題時能回答這些問題的系統：

• 它當時依哪個版本的指令工作？
• 哪些證據支持這個結論？
• 工作目前停在哪個狀態？
• 誰允許它執行這個動作？
• 失敗後如何恢復、交接與追責？

如果這五題答不出來，Agent 再會說話，也只是帶工具權限的聊天機器人。

如果答得出來，模型才真正被放進一套可以運作、驗收與持續改善的工程系統。

視覺說明：封面為 AI 生成的概念圖；三張技術圖為本文原創架構示意，不代表特定供應商產品。

參考資料

• ByteByteGo：Best Practices for Building AI Agents That Work in Production（2026-07-22）
• Google Developers Blog：Building scalable AI agents with modular prompt transpilation（2026-07-16）
• Anthropic：Claude Science, an AI workbench for scientists, is now available（2026-06-30）
• Nous Research：Hermes Agent v0.19.0 Release Notes（2026-07-20）

這套方法很快就遇到一個很難忽略的新案例：Kimi K3。

在 Arena 的前端網頁開發榜上，它暫時排第一；Moonshot 公布的 Program Bench、Automation Bench、BrowseComp，也都出現它壓過 Claude Fable 5 或 GPT-5.6 Sol 的項目。這不是某個小模型靠價格換掌聲，而是一個 2.8 兆總參數、100 萬 token 上下文、原生視覺、專門為長時間 Agent 工作打造的重量級模型。

先不要急著把新聞標題寫成「中國開源模型全面擊敗美國閉源 AI」。那樣很有流量，也很容易在兩天後變成笑話。

K3 真正重要的地方，不是它全面贏了——它沒有。重要的是，閉源模型在所有高價值工作上理所當然領先的假設，已經失效。開放模型陣營不再只是追趕通用平均分，而是開始在前端開發、工具操作、長流程研究與部分程式任務裡，先把旗子插到閉源模型前面。

這個轉折，比「第幾名」有意思得多。

先給結論：開放模型已經局部超車，但 K3 現在還不能直接叫開源

我對 Kimi K3 的判斷可以濃縮成六句話：

1. 它已經正式上線，不是預告。網頁、桌面工作代理、Coding Agent 與 API 都能使用。
2. 它進入了前沿模型第一梯隊。截至 2026 年 7 月 18 日，Artificial Analysis Intelligence Index 為 57 分、排名第 4；但速度、價格與輸出長度並不漂亮。
3. 它在特定領域確實贏過頂尖閉源模型。最明顯的是 Arena WebDev 暫列第一，以及 Program Bench、Automation Bench、BrowseComp 等項目的領先。
4. 它沒有全面超越 Claude 或 GPT。DeepSWE、FrontierSWE、Terminal-Bench 仍有閉源模型領先，Moonshot 自己也承認整體表現仍落後 Claude Fable 5 與 GPT-5.6 Sol。
5. 它走的是開放權重路線，但截至 7 月 18 日權重還沒發布。Arena 與 Artificial Analysis 目前仍把它標成 proprietary。
6. 它不是便宜的小模型。US$3／15 的一般輸入／輸出價、約 62 token／秒、固定 max 推理強度，加上極大的部署需求，讓它比較像重型工程設備，不是大量小任務的免洗工讀生。

所以，最精準的說法不是「開源模型全面勝利」，而是：

前沿能力已經從一條封閉的總排行榜，裂成多個領域戰場。開放權重或承諾開放權重的模型，開始在其中一些戰場領先閉源旗艦。

這代表企業與開發者的選型方法也要改。以前可能先問「哪一家最強」，現在要先問「我的任務到底在哪個戰場」。

Kimi K3 到底是什麼：不是 2.8 兆參數一起上班

K3 最搶眼的數字是 2.8 兆總參數。

如果把它理解成每生成一個 token，都有 2.8 兆參數一起全速運算，會得到一個很壯觀、也不太正確的畫面。K3 採用 Stable LatentMoE；官方表示，它在 896 個專家中，每次有效啟用 16 個。換算後約是 1.79% 的專家被選中，但這不等於只有 1.79% 的總參數參與運算，因為模型仍有共享層、注意力與其他結構。

比較好懂的比喻，是一間有 896 位專家的巨型顧問公司。每個 token 進來，路由器挑 16 位進會議室；其他人不必全部開麥克風。

這種設計讓模型能擴大容量，又不必每一步都付出完整 dense model 的計算成本。代價也很直接：

• 路由器要選對專家；
• 熱門專家不能全部塞車；
• 大量 GPU 之間要高速交換資料；
• 訓練與推論都更依賴整體基礎設施。

Moonshot 為此加入 Quantile Balancing、平衡式 expert parallel training 與 Stable LatentMoE。這些名字聽起來很研究，但實際處理的是同一件事：模型很大不稀奇，能讓 896 個專家不要在分散式系統裡互相等到下班，才是工程。

KDA 與 AttnRes：一個處理長度，一個處理深度

K3 的另外兩個核心結構是：

• Kimi Delta Attention（KDA）：作為長上下文與大規模注意力的效率基礎；
• Attention Residuals（AttnRes）：讓模型能沿著深度選擇性取回過去層的表示，而不是只把所有資訊一路均勻累加。

直觀地說，KDA 處理的是「文件很長時怎麼不要算到失控」，AttnRes 處理的是「模型很深時怎麼不要把前面的重點稀釋掉」。

官方宣稱這些架構、稀疏度與訓練方法，讓 K3 相較 K2 的整體 scaling efficiency 提升約 2.5 倍。這仍是廠商數據；完整技術報告尚未發布，目前可以理解方向，不能假裝已經完成外部重現。

100 萬 token 的價值，不是讓你貼一本小說

K3 的官方精確規格是 1,048,576 token 上下文，並支援原生視覺輸入。真正有價值的情境不是炫耀能塞多少頁，而是讓長時間 Agent 同時保留：

• 原始需求與驗收條件；
• 大型程式庫、文件與 API 規格；
• 工具呼叫結果與錯誤紀錄；
• 畫面截圖、視覺回饋與修改歷史；
• 先前嘗試過但失敗的路徑。

K3 特別強調 vision in the loop。它不只寫前端程式，也能看執行畫面，再修改 CSS、互動、遊戲或 3D 場景。這也解釋了為什麼它在前端網頁生成與視覺程式任務上特別突出。

但 Context Window 是容量，不是保真度保證。能放進 100 萬 token，不代表第 37 萬與第 91 萬 token 的細節都能同樣可靠地取回。長上下文仍要用自己的 needle、跨文件整合與長軌跡任務測試。

帳戶限制也可能比模型規格先撞牆。Kimi API 的低階 Tier 0 帳戶目前只有每分鐘 50 萬 token，低於模型的完整上下文容量；要測真正的 1M request，必須先核對帳戶等級、TPM 與 input／reasoning／output 如何共同占用 context。規格頁寫得下，不代表你的帳戶當下送得進去。

開放模型開始領先閉源，證據在哪裡？

這裡要把「領先」拆成三種證據：獨立人類偏好、廠商公布評測，以及跨模型綜合指數。三者都能看，但不能混成同一張成績單。

1. Arena WebDev：目前最有力的獨立訊號

Arena 在 2026 年 7 月 16 日的 WebDev Overall 榜，把前端網頁開發定義為包含多步驟推理與工具使用的工作。當時的實驗室排名是：

如果把條件收緊成「權重今天已經公開」，第 4 名的 GLM-5.2 反而是更直接的證據。Z.ai 已用 MIT 授權發布模型，Arena 上它仍排在 Grok 4.5、Muse Spark 1.1 等多個閉源模型之前。這不代表開放模型拿下通用總冠軍，卻已足以證明：在一個明確的前端開發領域，開放權重模型可以實際領先多個閉源前沿模型。

這張表有兩個訊號。

第一，K3 在前端網頁開發這個具體領域，確實暫時領先兩個最強閉源模型。這就是「開放模型路線已能在特定領域超車」最直接的例子。

第二，在 7 月 16 日的榜單頁面上，Arena 仍把 K3 標成 proprietary。所以這不是一張「已開源模型第一名」證書，而是「承諾在十一天內開放權重的模型，已先在產品與評測上跑到第一」的時間差。

榜單還會變，K3 也仍是新模型。1679 不是刻在石碑上的數字；真正值得記住的是，前端開發已經不再由閉源模型天然包辦前排。

2. Moonshot 官方評測：不是全面勝利，而是明顯偏科

Moonshot 公布的完整表格呈現一個很有性格的模型。

K3 領先的項目包括：

但它不是每一科都贏：

這組結果最適合支持的結論是：K3 在前端、瀏覽研究、流程自動化、試算表與部分程式任務已能超車；但在完整軟體工程與綜合專業工作上，還沒有全面領先。

更麻煩的是，這些項目使用的 Harness 不完全相同。K3 可能搭 Kimi Code，Claude 搭 Claude Code，GPT 搭 Codex；部分評測甚至會取其他模型在不同 Harness 中的最佳分數。K3 也全部使用 max thinking effort。

所以，這些是「模型加工作系統」的結果，不是把三顆裸模型放在無菌室裡打一架。

3. Artificial Analysis：能力很強，食量也不小

Artificial Analysis 對 K3 的快照更接近一盆冷水：

• Intelligence Index：57 分，2026 年 7 月 18 日排名第 4；
• 輸出速度：約 62 token／秒，低於同類平均；這是開始輸出後的 decode 速度，不是使用者等到答案的完整時間；
• 支援文字與圖像輸入、文字輸出、100 萬 token 上下文；
• Intelligence Index 評測共輸出約 1.30 億 token，同類平均約 6,300 萬；
• 該次完整 Intelligence Index 評測成本約 US$2,709.75。

Artificial Analysis 在 Kimi 官方 API 的 10K 輸入工作負載上，量到約 1.99 秒收到第一個 token，但模型在正式答案前平均先推理約 32.25 秒，因此 第一個可讀答案 token 約要等 34.24 秒；生成到 500 token 的端到端時間約 42.30 秒。這組數字比「62 token／秒」更接近人真正坐在螢幕前的感受：它開始講話後不算慢，但開口前會想很久。

也就是說，K3 不是那種「又小、又快、又便宜，順便把閉源模型全打趴」的童話。它比較像一位能力很強、願意一路做到底，但開會時間很長、差旅費也不少的資深顧問。

這反而讓它的局部領先更值得研究。因為 K3 不是靠極低價格偷到一個位置，而是用重型架構換到特定工作的前沿能力。

「開源」這兩個字，現在還不能寫得太順手

Moonshot 稱 K3 為第一個 open 3T-class model，API 文件也直接寫「開源」。但同一份官方資料又說，完整模型權重將於 2026 年 7 月 27 日前發布。

對企業選型而言，現在真正能確定的是：

• 產品與 API 已上線；
• 官方承諾將發布完整權重；
• Moonshot 官方 GitHub 與 Hugging Face 仍找不到 K3 權重 Repository；
• 完整權重、技術報告與最終授權仍待驗收；
• Arena 與 Artificial Analysis 暫時仍標示 proprietary。

即使權重如期上線，開放權重也不自動等於完整開源 AI。Open Source Initiative 的 Open Source AI Definition 還會檢查是否提供足夠的參數、程式碼、資料資訊與自由使用、研究、修改、分享的權利。

因此，現在最不容易翻車的寫法是：

Kimi K3 是已公開使用、預定於 7 月 27 日前發布完整權重的前沿模型。它代表開放模型路線的能力突破；是否符合完整開源定義，要等權重、程式碼、資料揭露與授權條款實際落地後判定。

這個字眼不是挑語病。對企業而言，能下載權重、能修改、能商用、能再散布、能取得推論程式與足夠技術資訊，是完全不同的權利。

價格不算低，快取才是 K3 經濟學的核心

K3 官方 API 每百萬 token 的價格是：

如果用 70% 快取命中輸入、20% 一般輸入、10% 輸出的示意組合計算，加權價格是每百萬混合 token US$2.31。這個數字只有在你的工作負載真的接近該比例時才有意義。

Moonshot 表示，官方 Kimi API 在 Coding 工作負載的快取命中率可超過 90%。這個優勢來自 Mooncake 的分離式推論架構與長前綴快取。Coding Agent 會反覆攜帶相同程式庫、系統指令與對話歷史，理論上非常適合快取。

但問題是：只要你頻繁改動前綴、切換 Harness、重組訊息或把模型當成臨時 fallback，快取命中率和品質都可能一起掉。

而且輸出是 US$15，K3 在 Artificial Analysis 的輸出量又接近同類平均的兩倍。便宜的快取輸入，救不了無限制的長篇輸出。

真正該追的不是 API 價目表，而是：

每個被接受的任務成本 = 模型與工具總成本 ÷ 通過驗收的任務數，再加上人工修正、等待、重試與風險。

這也是我在2026 年 AI Coding 工具選型裡反覆強調的 accepted-task economics。模型單價只是最容易被看見的那一小塊。

K3 最容易被忽略的限制：它不是可以隨便熱插拔的模型

Kimi 官方很誠實地列出一個不常見、但很關鍵的限制：K3 對完整思考歷史很敏感。

K3 採保留思考歷史的訓練方式。多輪對話與工具呼叫時，API 文件要求把完整的 assistant message 原樣帶回下一輪，不能只留下最終 content。如果 Harness 沒有正確保留歷史，或在進行中的工作中途從其他模型切換到 K3，生成品質可能變得非常不穩定。

這件事直接打臉一個常見想像：

「反正都是 OpenAI-compatible API，改一下 model slug 就能無痛切換。」

插頭一樣，只代表插得進去，不代表電壓、通訊協定與工作習慣都一樣。

如果把 K3 接進 Hermes、OpenCode、Codex 相容 Gateway 或企業自製 Agent，至少要驗證：

1. reasoning history 是否完整 round-trip；
2. tool call 與 tool result 是否保持正確順序；
3. context compaction 是否會丟掉 K3 需要的思考內容；
4. mid-session fallback／failback 是否造成品質崩落；
5. 快取是否因訊息重組而失效；
6. Harness 的 System Prompt 與工具描述是否針對 K3 調整。

官方目前建議使用已驗證相容的 Kimi Code。這不是說第三方 Harness 不能用，而是不能只測「API 回了 200」，就宣告整合完成。

另一個限制更像 Agent 的性格問題：過度主動

Moonshot 把它叫作 excessive proactiveness。

K3 被特別訓練來處理長時間、困難、開放式任務。這讓它能在大型工程與研究裡持續推進，也讓它在需求模糊時，可能替使用者做出預料外的決定。

你叫它移一張椅子，它可能順便重新裝潢會議室。做得還不錯，但問題不是這個。

對有工具權限的 Agent，這不是文風偏好，而是風險模型。系統至少要有：

• 明確的檔案、網路、資料與工具權限；
• 刪除、覆寫、付款、寄送、發布與部署前的人工核准；
• 可執行的 allowlist／denylist，不只是在 Prompt 裡拜託它乖一點；
• 每一步的日誌、產物檢查與失敗回復；
• 對模糊需求先停下詢問的明確規則。

AGENTS.md 可以告訴模型怎麼做事，但真正的安全邊界仍要靠 sandbox、權限、憑證、網路政策與 approval gate 強制執行。

K3 上線初期也只有 max 推理強度，低與高檔位仍待後續開放。這讓簡單任務可能太慢、太長、太貴。Kimi 官方聯網搜尋工具目前也在更新，文件明確寫著近期不建議使用；需要正式研究流程時，應接自己的可觀測搜尋與引用工具，而不是把產品展示當成生產 SLA。

誰現在應該測 K3？

我會優先把 K3 放進以下工作的對照組：

1. 前端與視覺程式

給它需求、參考畫面、現有 Repository、瀏覽器截圖與可執行測試，看它能不能在 vision-in-the-loop 裡反覆修改，而不是只生成一張看起來很厲害的首頁。

2. 大型 Repository 的長時間任務

例如跨模組重構、測試補齊、工具鏈整合、GPU kernel、資料處理與需要終端機反覆驗證的工作。這些才有機會用到它的長軌跡能力。

3. 可交付的知識工作

不要只測「幫我摘要 20 份報告」。測它能不能交付帶來源的研究、試算表、互動圖表、簡報或可檢查的資料產物，並把事實、推論與不確定性分開。

4. 開放權重與私有部署的前置研究

大型雲端供應商、研究機構與有 64+ 加速器 supernode 能力的組織，可以先評估權重發布後的部署路線。一般個人或中小企業則不要被「開放權重」三個字騙去下載一艘貨輪。

K3 使用 MXFP4 權重時，2.8 兆參數的理論緊密打包下限就約 1.4 TB，還沒算 metadata、共享結構、執行環境、KV cache、通訊與冗餘。官方建議至少 64 個加速器的 supernode，不是因為他們討厭玩家顯示卡。

一個務實的 K3 Pilot

不要全面遷移。先挑 20～40 個真實任務，分成四組：

• 前端／視覺開發；
• Repository 級軟體工程；
• 瀏覽與研究；
• 文件、試算表與互動成果。

同一批任務至少比較 K3、現有主力閉源模型，以及一個較便宜的開放權重模型。固定 Repository commit、Prompt、工具、權限、時間上限與驗收條件，記錄：

• 第一次通過率；
• 人工修正分鐘數；
• 測試、視覺回歸與事實查核結果；
• Token、快取、工具呼叫與總成本；
• P50／P95 完成時間；
• 越權、過度主動與誤判完成的次數；
• Harness、Provider、reasoning effort 與版本。

尤其不要把 K3 硬塞進現有 Router，然後在任務中途切過去。K3 適合從任務開始就被正確分流，使用相容 Harness 完整跑完；它目前不是理想的臨時備胎。

最後輸出的決策，也不該是「K3 贏了，所以全部換掉」。比較合理的結果可能是：

• K3：前端、視覺程式、長程研究與特定重型工程；
• Claude／GPT：需要更成熟指令遵循、商務文字與高可靠體驗的工作；
• 較小開放模型：分類、摘要、格式轉換與大量低風險任務；
• 人類：權限、品味、風險與最後驗收。

這才是真正的模型路由，不是把 fallback 名單寫長一點。

最後判斷：閉源不再是能力保證，開放也不是免費午餐

Kimi K3 沒有終結 Claude，也沒有把 GPT 送進博物館。

它做的事情比較麻煩：它讓原本很方便的二分法失效了。

以前可以把閉源模型理解成能力前沿，把開放模型理解成便宜、可控、稍微落後的替代方案。現在這條線被前端開發、工具操作、長流程 Agent、視覺程式與研究工作切得亂七八糟。開放模型不必先拿下通用總冠軍，才有資格在真正的工作裡領先。

當然，K3 的權重還沒落地，授權還沒驗收，技術報告還沒公開，速度不快，輸出很長，部署也重得離譜。把這些省略掉，只剩「全球最大開源模型」，跟只看排行榜第一名沒有本質差別。

對我來說，K3 最值得記住的不是 2.8 兆。

是從這一代開始，選擇開放模型不再只是為了省錢或避免供應商綁定。有些時候，你選它，是因為它真的把某一種工作做得更好。

這才是閉源模型真正需要擔心的地方。

參考資料

• Kimi：Kimi K3 Tech Blog——Open Frontier Intelligence
• Kimi API：Kimi K3 模型、思考歷史、視覺輸入、快取與限制
• Kimi API：Kimi K3 價格與帳戶流量限制
• Artificial Analysis：Kimi K3 Intelligence、Speed、Price 與技術規格
• Artificial Analysis：Kimi K3 Provider 速度、延遲與混合價格
• Arena：WebDev AI Leaderboard
• Z.ai：GLM-5.2——MIT 授權與長程 Agent 技術說明
• Open Source Initiative：Open Source AI Definition 1.0
• Reuters：Moonshot unveils Kimi K3

這個問題很快，也很容易問錯。

同一個模型換一個 Provider、推理強度、Agent Harness、工具環境或快取策略，速度、成本與任務成功率都可能完全不同。排行榜上的名稱看起來一樣，真正上線的卻不是同一套系統。

Artificial Analysis 有價值的地方，不是再做一張更長的排行榜，而是把模型能力、Agent 任務、API 效能與成本放到同一個觀察介面。

但它仍然不能替企業回答最後一題：哪一套模型系統，能在可接受的成本、延遲、人工介入與風險下，穩定完成我的工作？

這篇文章要處理的，就是從公開排行榜走到實際選型，中間那段最容易被省略的路。

先給結論：排行榜是雷達，不是方向盤

選擇大型語言模型，至少要同時看四件事：

1. 能力：模型能否理解、推理、寫程式並完成多步驟任務；
2. 成本：不是 API 牌價，而是每個合格成果的總成本；
3. 體驗：首字延遲、第一個可讀答案、完整任務時間與長尾等待；
4. 可靠度：錯誤率、工具恢復、重大失敗與人工接手比例。

只看 Intelligence Index，會忽略速度與成本；只看 token 單價，會忽略模型為了完成同一件事到底用了多少 token；只看每秒輸出速度，又會忽略模型可能在正式回答前先想了半分鐘。

真正的部署單位從來不是一個 model slug，而是：

Model + Configuration + Provider + Harness + Tools + Routing

Artificial Analysis 的定位：把「模型強不強」與「服務好不好」拆開

Artificial Analysis 是獨立的 AI 模型與推論服務分析平台。它同時整理三個容易被混在一起的層次：

Model

被訓練出來的模型本體。能力受到權重、訓練資料、後訓練、推理機制與安全策略影響。

Provider／Endpoint

真正被呼叫的 API。排隊、Batching、量化、快取、區域節點與流量限制，都會改變使用者感受到的速度與穩定度。

Agent System

模型外圍的 Prompt、工具、記憶、重試、Context 管理、權限與執行框架。對 Coding Agent 或企業自動化來說，這一層經常與模型本身同樣重要。

同一個開放權重模型放在不同 Provider 上，可能有不同的 Output Speed、Time to First Token、可用 Context、價格與錯誤率。

所以看到「某模型每秒 100 token」時，第一個問題不該是「它好快」，而是：哪一個 Provider、哪個區域、什麼 Prompt 長度、什麼時間與哪種負載？

Intelligence Index v4.1：2026 年開始更像工作測驗，不只像考卷

Artificial Analysis Intelligence Index 是把多項評估加權後形成的複合指標。這裡的 Intelligence 不是人類心理測驗中的智商，而是模型在一套英文、純文字測試裡呈現的綜合能力。

v4.1 分成四大類：

v4.1 由九項評測組成：

這套權重傳達三個訊號。

第一，Agentic Work 已經進入核心，而不是排行榜旁邊的附加欄位。

第二，Benchmark 也需要版本治理。當某些題目逐漸飽和、失去區分前沿模型的能力，就應該被降權或移除。

第三，能力分數開始與 Cost per Task、Time per Task、Tokens per Task 放在一起。模型不只要答對，還要付得起、等得到，並且能在合理步數裡完成。

2026 LLM 評估地圖：從公開訊號走向部署決策

評估不是一條由低分走向高分的直線，而是一張逐層收斂的地圖。

第一層：人類偏好

LMArena 透過匿名成對比較，回答「人類比較喜歡哪個回答」。它適合觀察對話體驗、文風與一般使用感受，但不是單純的客觀正確率。

第二層：綜合能力

Artificial Analysis Intelligence Index、HLE、GPQA Diamond 等指標，用來快速縮小前沿模型候選池。

第三層：專項能力

Coding Agent、軟體工程、專業知識工作、SaaS 自動化、多語言、視覺與長上下文，都需要不同的尺。

第四層：營運體質

TTFT、TTFA、Output Speed、P95、Error Rate、Rate Limit、Context Cache 與 Cost per Task，決定模型能不能進入產品。

第五層：私有業務評估

真實任務成功率、重大錯誤、人工接手、權限風險與每個合格成果的成本，才是最後的部署依據。

實務上可以先用前兩層，把數百個模型縮小到三至五個；再用專項能力與營運條件淘汰不合格方案，最後用私有任務決定分工與路由。

不要把速度、延遲與任務時間混成一個數字

Reasoning Model 讓「回應速度」變得更難描述。收到第一個 token，不代表使用者已經看到正式答案；開始輸出後很快，也不代表整體任務較快。

Artificial Analysis 的效能測試使用固定 Prompt Shape，並持續量測公開端點，避免拿一次速度測試當成長期服務品質。

企業仍應用自己的地區、尖峰流量、Prompt 長度、併發量與工具環境，重測 P50、P95、Timeout 和 Error Rate。

從 Token Price 升級到 Cost per Successful Task

模型 A 的牌價比較便宜，不代表完成工作比較便宜。

假設模型 A 每次嘗試成本 US$0.20，成功率只有 40%，平均每個成功任務成本是 US$0.50。

模型 B 每次嘗試成本 US$0.35，成功率 90%，平均每個成功任務反而只要約 US$0.39。

每個成功任務成本 = 平均嘗試成本 ÷ 任務成功率

而且這還只是模型成本。完整成本還包括搜尋、資料庫、Tool API、重試、人工複核、返工、錯誤處理與風險。

真正該優化的不是「每百萬 token 最便宜」，而是：符合品質門檻，而且不用重新做一次的成果。

常見 Benchmark 的分工：每一把尺都有自己的形狀

把不同 Benchmark 的第一名直接放進同一張「總冠軍」表，就像拿短跑、游泳、象棋與搬家公司比一個總分。數字可以算，結論通常沒什麼用。

公開排行榜的七個常見陷阱

1. 複合指數一定有價值判斷

將多項評測合併成單一分數，就必須決定權重。Agent 34% 對企業自動化合理，對中文創作或純數學研究未必合理。

2. 模型分數經常是系統分數

Coding 與 Agent Benchmark 會同時受到 Harness、Prompt、工具、回合限制、重試與 Context 管理影響。

3. 靜態資料集會老化

題目可能進入訓練資料，模型也會逐漸把既有評測磨到飽和。Benchmark 必須有版本、日期與污染治理。

4. LLM Judge 也有自己的偏好

篇幅、格式、引用與模型家族都可能影響評分。可程式驗證的任務，應優先使用測試與後端狀態檢查。

5. 平均值會吃掉長尾風險

平均延遲不代表每次都快。生產環境至少要看 P50、P95、P99、Timeout、Retry 與 Rate Limit。

6. Context Window 不等於長文能力

API 接受一百萬 token，不代表模型能可靠召回遠端資訊、整合證據並維持多輪指令一致性。

7. 名稱沒變，行為也可能已經變了

安全策略、System Prompt、推論硬體、路由、量化與快取都可能在服務端更新，所以私有評估必須能重跑。

更準確地說，一個 Benchmark 分數其實是：

Score = f(Model, Version, Prompt, Effort, Tools, Harness, Budget, Retries, Evaluator)

建立私有評估集：把需求變成能重跑的測試

公開 Benchmark 不知道你的 Repository 結構、中文文風、資料品質、權限政策與可接受風險。

私有 Eval 的目的，是把「大家覺得這模型不錯」變成可以重跑、比較與回歸的工程資產。

起步不需要幾千題。先準備 30 至 100 個真實任務，涵蓋：

• 正常需求；
• 模糊或互相衝突的需求；
• 缺少資料；
• 工具失敗；
• 權限不足；
• 需要人工核准的高風險操作。

最低限度應追蹤：

每次測試還要固定模型版本、Provider、區域、推理強度、Prompt、Harness、工具政策、Token Budget、最大回合數與重試規則。

否則下次分數變了，你只會知道「有東西變了」，不知道變的是模型、系統還是測試本身。

最後的決策不是一名冠軍，而是一套路由

成熟的模型選型，很少會得到「所有任務都用同一個最強模型」這種答案。

比較合理的結果通常是：

• 低風險、大量、格式固定的任務，交給便宜模型；
• 跨模組工程與高風險任務，交給成功率更高的主力模型；
• 文件、簡報或特定語言，交給擅長該輸出的模型；
• 權限、品味、重大風險與最後驗收，保留給人類。

公開排行榜負責找到候選，私有任務決定分工，生產遙測則負責持續修正路由。

到了 2026 年，最值得問的已經不是「哪個模型排行榜最高」，而是：

在可接受的成本、延遲、風險與人工介入範圍內，哪套模型系統能最穩定地完成工作？

這個問題沒有永恆冠軍，但可以有一套持續更新、能被驗證的答案。

參考資料

• Artificial Analysis：Intelligence Benchmarking Methodology
• Artificial Analysis：Language Model API Performance Benchmarking
• Artificial Analysis：Intelligence Index v4.1 Announcement
• Artificial Analysis：General Benchmarking Methodology
• LMArena：Arena-Rank Methodology

Claude Code、Codex、Cursor、OpenCode、Hermes Agent，各自有自己的設定檔、skills、模型、provider、權限與帳單。再加上 OpenRouter、本機模型、MCP 和 cloud agent，整件事很快就從工具選擇變成一個小型分散式系統。

這裡面最荒謬的地方是，市場還是很喜歡問：「哪一個最好？」

這個問題在 2026 年已經不太有用了。真正的選擇單位不是單一模型，也不是單一 CLI，而是一整套能把需求安全地變成可接受變更的工作系統。

本文資料整理至 2026 年 7 月 12 日。這個市場以週為單位變動，價格、方案額度、模型名稱與指令，採購或部署當天仍應回官方頁面核對。

先給結論：工具不需要唯一，但責任必須唯一

如果只想先記住幾件事，我的答案是這七條：

1. LLM 決定能力上限，harness 決定能力能不能穩定變成可接受的修改，組織流程決定它能不能安全上線。
2. 多工具並用已是常態。但保留選擇權，不等於讓每個人把所有工具、模型和 MCP 都接進公司環境。
3. 終端主力先比較 Claude Code 與 Codex；IDE-first 團隊先比較 Cursor 與 GitHub Copilot。
4. 專案共通知識以 AGENTS.md 為核心。Claude Code 再用薄 CLAUDE.md 匯入；不要幻想所有設定檔、skills、hooks 與權限都能零修改共用。
5. 開源 harness 不等於資料留在本機。OpenCode、Hermes 接上雲端 provider，程式碼和 prompt 一樣會離開裝置。
6. OpenRouter 提供模型與 provider 選擇，不會自動送你一張合規證書。資料政策、ZDR、allowlist、region、參數支援與預算都要自己設。
7. CP 值用「每個被接受的任務」算。月費和每百萬 token 價格，只是成本最容易被看到的那一小塊。

我給個人技術顧問的實用組合是：Claude Code 或 Codex 擇一為主力，另一個作不同模型家族的 reviewer；OpenCode 當 model lab；Hermes 負責非機密研究、排程與跨工具編排；OpenRouter 只承接完成資料分級的工作。

企業則不要先選冠軍。從 Claude Code、Codex、GitHub Copilot、Cursor 中挑兩個進 pilot，用同一批真實 ticket、同一套測試與品質門檻比較。

模型只是九層裡的一層

很多人已經知道要分開看 LLM 與 agent harness。這比只看 benchmark 好，但還不夠。

對企業導入或長期個人工作流，我會把 AI Coding 系統拆成九層：

我會把成果寫成一個很不科學、但很實用的乘法：

成果 = 模型能力 × harness 轉換效率 × 專案脈絡品質 × 驗證與組織能力。

乘法的麻煩是，只要一項接近零，其他項目堆再高都沒用。

同一個模型放進不同 harness，搜尋範圍、patch 方法、工具 parser、context compaction、測試 loop 都可能改變結果。同一個 model slug 交給不同 provider，也可能遇到量化、chat template、實際 context、cache、延遲或參數支援差異。

所以「它支援 OpenAI-compatible API」只代表門插得進去，不代表電壓一定對。

採用很快，信任沒有同步上升

2026 年 Pragmatic Engineer 針對 906 位受訪者的調查顯示，樣本雖偏資深、偏歐美科技公司，但很能反映重度採用者的行為：95% 每週使用 AI 工具，70% 同時使用 2～4 種，另有 15% 使用五種以上。在 regular agent users 中，Claude Code 的使用率為 71%，GitHub Copilot 46%，Cursor 39%。

這不能被解讀成全球市占。比較合理的解讀是：資深、重度 agent 使用者對 Claude Code 的口碑很強；到了大型企業，GitHub 身分、採購、政策與支援會改變答案。工程師最喜歡的工具，和企業最容易買的工具，從來就不是同一件事。

另一邊，Stack Overflow 2025 調查裡，46% 受訪者不信任 AI 準確性，信任者只有 33%；66% 的主要挫折是結果「幾乎正確，但還差一點」，45.2% 認為替 AI 產生的 code 除錯更花時間。

這幾個數字放在一起看，結論其實不浪漫：AI 很容易提高個人的產出感受，卻不會自動提高團隊共同理解、review 品質與維護責任。

METR 在 2025 年曾觀察到熟悉自己開源 repository 的資深開發者使用 AI 反而慢 19%。但 METR 已在 2026 年明確說明，這個結果不應再被當成現在的定論；後續資料方向轉正，卻受到參與者與任務選擇偏差影響，仍不足以精確估算加速幅度。

DORA 的說法比較接近我自己的經驗：AI 是放大器。流程清楚、測試快、文件可用、feedback loop 短，它會放大優勢；需求模糊、變更批次過大、review 已經塞車，它也會把問題一起放大。

七款工具，我會怎麼定位

下面這張表不是排名，而是先用來排除明顯不合適的選項。

Claude Code：成熟，但不是中立 harness

Claude Code 的優勢不只是 Claude 模型，而是 CLAUDE.md、path-scoped rules、skills、subagents、hooks、MCP、permissions、plan、rewind 與 review 組成的工作方式。對陌生錯誤、跨檔案重構與需要反覆驗證的任務，它仍是我會先測的終端工具。

它的邊界也很清楚。官方 gateway 支援改變 Claude 的上游與企業網路路徑，但不是讓 Claude Code 改跑非 Claude 模型。這是模型 lock-in，沒有必要假裝不是。

Codex：OpenAI-native，但本機沒有想像中封閉

Codex 橫跨 CLI、Desktop／IDE 與 cloud task，支援 AGENTS.md、skills、MCP、sandbox、review、plan 與 managed configuration。它特別適合已在 ChatGPT Business／Enterprise 的組織，也適合拿來當 Claude Code 之外的第二模型家族。

常見誤解是 Codex 只能跑 OpenAI。實際上，本機 Codex 可設定 OpenAI-compatible provider，也可用 --oss 連 Ollama 或 LM Studio。但這只證明 harness 能換 provider，不代表 reasoning、tool use、cache 或 cloud features 都和第一方路徑一樣。

Grok Build：值得測，但 Beta 就是 Beta

Grok Build 已有 project rules、skills、plugins、MCP、plan、tasks、queue、loop 與 headless scripting，也支援自訂 provider。現行官方頁面可免費試用，不應再沿用早期「一定要 Premium+」的資訊。

問題不是功能表太短，而是版本仍快速變動。企業可以從 read-only reviewer、隔離環境或非關鍵 repository 開始；不要因為免費，就順手把 production 權限也送出去。免費和便宜是財務形容詞，不是風險分類。

Hermes Agent：負責編排，不搶每一個 coding 任務

Hermes 的差異在持久記憶、cron、訊息通道、background work、skills、fallback、OpenRouter 與跨工具委派。它適合回答「何時做、要做什麼、結果送去哪裡」，再把單一 repository 的深度 coding 交給 Claude Code、Codex 或 OpenCode。

Hermes 是 MIT 開源，但只要接雲端 LLM、web search、browser 或遠端 MCP，相關資料仍會送往供應商。對個人顧問，我會用它處理非機密研究、排程、內容與多模型實驗；公司機密 code 則留在企業核准的 inference、sandbox、secrets 與 audit 邊界內。

Cursor 與 Copilot：一個偏體驗，一個偏控制面

Cursor 把 Tab、Agent、rules、review、cloud agents 與團隊管理放進同一個 IDE。對不想先學 CLI agent 心智模型的團隊，摩擦確實比較低。但 daily agent 的 overage、平台費與模型用量要一起算。

GitHub Copilot 的優勢則是身分、repository、policy、IDE 分發、audit 與採購在同一控制面。這也是它在大型企業有優勢的原因。只是 CLI、IDE local agent、cloud agent、custom agent 與 MCP registry 的治理範圍仍要逐一核對，不能因為 logo 一樣，就當成政策一定相同。

OpenCode：很好的 model lab，不是自動合規機

OpenCode 支援大量 providers、local model、AGENTS.md、agents、MCP 與 TUI／CLI。對個人實驗不同模型、OpenRouter 或內部 gateway，很有價值。

但 /share、provider retention、tool parser、Windows 維運、版本回歸與中央 audit 都要自己處理。開源讓你看得到和改得到；它沒有順便幫你聘一個資安團隊。

個人和企業，不該共用同一張排行榜

個人重度使用者通常先看：既有訂閱能不能用、互動順不順、能不能按任務切模型、花費是否可見、Windows 是否穩定、設定能不能備份，以及不同資料能不能清楚分流。

我會這樣分工：

企業則多了一整排不能用 prompt 代替的硬條件：SAML／OIDC、SCIM、RBAC、離職撤權、model allowlist、MCP registry、network egress、secrets、資料保留、audit、預算、自動停用、版本 pinning、support 與 rollback。

三個名詞尤其不要混在一起：

• 不拿內容訓練模型：不代表不記錄，也不代表零保留。
• Zero Data Retention：通常只描述推論端，不會自動涵蓋 web、plugin、MCP 與 metadata。
• Data／Inference Residency：資料儲存與 GPU 推論在哪裡；登入、帳務、connector 和 metadata 可能是另一套範圍。

Restricted data 的答案，很多時候不是挑一個自稱更隱私的 SaaS，而是不要送出。

企業選型先淘汰，再評分

我不建議一開始就做「Claude 9.5 分、Codex 9.3 分」這種看起來精確的表格。先設 knockout gates，比較誠實。

以下任一項不合格，就先不要進加權評分：

• 資料類別與 inference endpoint 不符；
• 無法強制 SSO、撤權、model 或 MCP policy；
• sandbox、network 或 secrets 邊界不符合風險等級；
• 無法取得必要 audit、DPA 或 retention 承諾；
• 不能在目標 OS、repository 與 CI 穩定工作；
• 供應商生命週期、support 或退出條件不可接受。

通過後，再比較真實任務品質、修正時間、安全治理、TCO、穩定性、可攜性與開發體驗。權重依組織風險改，不要先愛上一個工具，再把試算表調成它會贏的樣子。

AGENTS.md 可以共用，但安全邊界不能寫在 Markdown 裡

跨工具時，先分清楚四種東西：

AGENTS.md 寫「不要碰 production」不是安全措施。真正的安全措施是 production credential 根本不在環境裡，network policy 擋得住，危險命令需要核准，CI 和 review 不讓未驗證變更進主線。

對多工具 repository，我建議：

repo/
├── AGENTS.md                    # 共用事實、build/test、架構與禁區
├── CLAUDE.md                    # @AGENTS.md + 少量 Claude-only 說明
├── docs/ai/
│   ├── data-classification.md   # 哪些資料可送哪種 endpoint
│   ├── mcp-catalog.md           # 核准 server、owner、資料與權限
│   └── eval-tasks.md            # 內部評測任務與通過標準
├── .agents/skills/              # 可攜 workflow 的候選正本
├── .claude/                     # Claude rules、skills、settings
├── .codex/config.toml
├── .cursor/rules/
├── .opencode/
└── .github/copilot-instructions.md

共用事實只寫一份。工具專屬檔案只補能力差異和 override。Windows 環境不要為了看起來優雅就硬上 symlink；薄匯入檔通常比較不會在 zip、CI 或不同 Git 設定裡突然表演消失。

SKILL.md 和 MCP 也是同理。可攜的是內容設計與 server contract，不是每個 client 的 discovery path、frontmatter、credential storage、approval 與 allowlist。每次工具升級，都要跑 smoke test 確認規則真的有載入、權限真的有擋住。

OpenRouter 與本機模型：自由度不是免費午餐

OpenRouter 的價值很明確：一組 API 與帳務使用多模型、選 provider、做 fallback、記 usage、設預算，並依 latency、價格或資料政策挑 endpoint。拿來搭 Hermes、OpenCode、Cline、Aider 或內部評測，很方便。

它不會自動解決：

• harness 對特定模型的 prompt 與工具最佳化；
• provider 的 tool parser、structured output、context 與 cache 差異；
• 企業 SSO、SCIM、repository policy、OS sandbox 或 code provenance；
• web、plugin、MCP 等推論以外的資料流；
• 已經輸出部分 token 後的無痕 failover。

最低限度，我會 pin 明確 model／version，設定 provider allowlist、region、data_collection: deny、必要時使用 ZDR、開啟 require_parameters: true，並對 user、team、project 設預算和 rate limit。免費 endpoint 只用於公開資料、學習或低風險 PoC。

本機模型則適合 air-gap、固定版本、穩定工作量、敏感資料預處理，或已經證明小模型能過內部門檻的情境。但本機不等於免費。GPU 折舊、電力、量化損失、KV cache、serving、監控、併發與 on-call 工時都是真實成本。

以單張 24GB VRAM 來看，9B 級模型比較務實；量化的 24B～35B 可以試，但 context 要節制。模型頁寫 1M context，不代表消費級 GPU 會因為看到規格表就突然多長記憶體。

更常見的答案是 hybrid：local 做分類、索引、摘要與敏感內容預處理；低價 cloud model 做 scout／worker；強模型負責架構、複雜修改與最終 review。

CP 值不是月費，而是 accepted-task economics

Claude Pro、Cursor Pro、Copilot Pro，或 OpenRouter 上每百萬 token 幾毛錢，都是入場價格，不是總成本。

我比較在意的公式是：

有效 CP 值 = 被接受且通過品質門檻的任務價值 ÷（席次＋推論＋等待＋重工＋維運＋治理＋資安風險成本）

Pilot 至少要記：

• time to accepted PR／ticket；
• first-pass acceptance；
• 人工修正與 review 分鐘數；
• build、test、lint、security gate 通過率；
• regression、rollback、re-open；
• 實際 model、provider、token、cache、retry 與 subagent；
• 每個 accepted task 的完整成本；
• 30／60／90 天後的維護性與 technical debt。

生成行數、prompt 次數、commit 數、登入率都很容易上升。它們和客戶價值沒有穩定關係，拿來當 KPI 只會鼓勵大家把更多東西生出來，再花更多時間刪掉。

Benchmark 用來篩選，內部 eval 才能決策

SWE-bench、Terminal-Bench 和廠商 benchmark 可以顯示某個模型／agent 在特定資料集與 scaffold 下的能力，但不等於你的 Java monorepo、部署流程、安全規則或團隊速度。

分數背後至少有 harness、prompt、token budget、attempt 數、工具、題目版本與 pass criteria。就算 benchmark 通過，也不代表 human reviewer 願意接受。

我的做法是準備 20～40 個已知答案或可清楚驗收的真實任務，涵蓋探索、小修補、功能、重構、migration、review 與 incident：

1. 用歷史人工資料建立 baseline，不只問「感覺快多少」。
2. 同一類任務隨機分配或 cross-over 比較兩個 harness，避免第二次作答已經知道答案。
3. 固定 repository commit、依賴、測試、network、AGENTS.md 與權限。
4. 記錄 model、provider、harness version、reasoning、token、cache、attempt 與 subagent。
5. 用 human acceptance 加 automated gates 判定，不接受 agent 自稱 done。
6. 把第一次失敗到最後接受的成本全部算進去。
7. 分新人／資深、熟悉／陌生 repository、Windows／macOS／Linux 觀察。
8. 保存去識別的 failure 摘要，轉成下一輪 eval、文件與 policy。

公開 benchmark 的功能是幫你縮小候選池。真正的採購答案，應該從自己的失敗紀錄裡長出來。

一個 30 天企業 Pilot

第 0～3 天：先畫防線

選一個有真實價值、但不是 production-critical 的 repository。完成資料分級，畫出 IDE／CLI／cloud／provider／MCP 的資料流，決定兩個候選 harness、兩個模型家族，建立 SSO、最小權限、network、secrets、logging 與版本 pinning，並挑出 20～40 個 eval tasks。

第 4～10 天：建立可攜知識層

寫精簡 AGENTS.md，Claude 用薄 CLAUDE.md 匯入。把 build、test、lint、security gate 寫成真的能執行的命令。MCP 先只開 read-only、低風險工具，再用 5～10 個任務測 instructions、compaction、resume、rewind、Windows 與 CI 行為。

第 11～20 天：受控實驗

找 5～15 位工程師，按資歷與領域分層。同一類工作比較兩個 harness，不要求每個人使用同一介面。每張 ticket 記 model、provider、成本、人工時間與結果；每週把失敗拆成 context 不足、模型錯誤、工具錯誤、權限阻擋與需求含糊。

第 21～27 天：提高風險，但不拆護欄

加入 write MCP、較大重構、review 與 headless 工作。模擬 429、provider outage、模型切換、credential revocation、惡意 repository instruction；測試 rollback、audit、offboarding、budget exceeded，也要驗證跨模型 reviewer 是真的降低缺陷，還是只增加噪音。

第 28～30 天：做決策

最後輸出不應只是滿意度排名，而要回答：哪些任務可自主執行、哪些必須 pair／review；主力與備援 harness；核准的 model／provider／region；誰負責 instructions、skills、MCP 與 policy；每個 accepted task 的 p50／p95 時間與成本；以及 rollout、support、版本更新和退出方案。

我會怎麼選

個人技術顧問或重度工程師

我的基線是：Claude Code 主力＋Codex reviewer＋OpenCode model lab＋Hermes 非機密編排。

如果主要工作已在 OpenAI 生態，也可以把 Codex 與 Claude Code 的位置對調。重點不是誰坐正宮，而是 builder 和 reviewer 不要永遠用同一個模型家族，並把公司機密留在核准邊界內。

Grok Build 既然可免費試，就拿公開或個人 repository 跑 eval。免費額度用來換證據，不是換信仰。

5～50 人產品團隊

• terminal-first：Claude Code ＋ Codex；
• IDE-first：Cursor ＋ Claude Code，或 Copilot ＋ Codex；
• GitHub procurement-first：Copilot Business 作基線，少數 power users 配 Claude Code／Codex；
• model freedom-first：OpenCode／Cline ＋企業 gateway，但要補中央設定、support 與 audit。

第一天不要讓每個人自己帶 API key、任意 MCP 與任意模型。先建立核准入口，再保留受控實驗沙盒。

大型或受監管企業

第一輪 shortlist 可放 Claude Enterprise 的 Claude Code、ChatGPT Enterprise 的 Codex、GitHub Copilot Enterprise、Cursor Enterprise。先用 knockout gates 比 identity、data、MCP、sandbox、audit、residency 與 support，再談工程師偏好。

如果只能買一款，通常是採購和治理折衷。工程上更合理的配置，往往是一款廣泛、低摩擦的工具，加上一款供少數 power users 使用的深度 agent，而不是所有人同額度、同模式。

真正該留下來的，不是工具名稱

AI Coding 選型最危險的兩個極端，一個是每週追排行榜，另一個是為了反綁定，把每一款工具都留在正式環境。

前者把能力誤認為成果；後者把選擇權變成維運與治理債。

我會留下的是測試、CI、schema、ADR、spec、精簡的 AGENTS.md、可重複的 eval tasks、失敗紀錄與 accepted-task economics。模型、provider 和 harness 則視為可以替換的執行層。

這樣就不需要預測半年後誰排第一。新工具出現時，用同一批真實任務跑兩週，知道哪些資料可以送、失敗怎麼回復、每個被接受的成果花多少錢，再決定留下或換掉。

排行榜很快會過期。能把工具換掉而不把工程方法一起拆掉，才是這份選型真正要買的東西。

參考資料

• Pragmatic Engineer：AI tooling survey 2026
• Stack Overflow Developer Survey 2025：AI
• DORA 2025 report
• METR 2025 RCT 與 2026 方法更新
• Anthropic：Claude Code and expertise
• Claude Code：commands、memory、LLM gateway、pricing
• Codex：slash commands、AGENTS.md、advanced configuration、pricing
• Grok Build：CLI、commands、enterprise
• Hermes Agent：官方文件、providers、security
• Cursor：rules、pricing、security
• OpenCode：providers、models、rules
• GitHub Copilot：plans、enterprise agent management
• OpenRouter：provider routing、data collection、ZDR、pricing

當時 Hermes Agent 的主模型已經切到 OpenAI Codex provider 的 gpt-5.6-sol，透過 ChatGPT Pro OAuth 使用。我想看的不是它會不會回答問題，而是它能不能把一個有成本、有素材、有審核、有失敗可能的工作做完。

不知道為什麼，最後我得到的不是一份 benchmark，而是一支 35 秒的攝影品牌短片，外加一個能讓 Hermes 呼叫 OpenRouter 生成影片的本機 plugin。

這件事有點微妙。因為「叫 AI 生一支影片」聽起來像一句 prompt，實際做下去，真正麻煩的部分幾乎都不在 prompt。

先把模型分工拆清楚

這次用了三層不同的工具，但它們不是同一件事。

第一層是 GPT-5.6 Sol。它跑在 Hermes Agent 裡，負責理解需求、檢查素材、規劃分鏡、呼叫工具、追蹤狀態與整理結果。它是編排者，不是影片模型。

第二層是 OpenRouter 與 ByteDance Seedance 2.0 Fast。真正要花 OpenRouter 額度的，是送進 /api/v1/videos 的影片生成工作。

第三層是本機後製：FFmpeg、Pillow 與 Edge TTS。字幕、圖片 contain、模糊延伸背景、旁白、音量正規化、串接鏡頭與技術驗證，都在本機完成，不再消耗 OpenRouter 額度。

我刻意保留這個分工。讓影片模型同時負責畫面、字幕、旁白、剪輯與成品驗證，看似省事，實際上等於把每一次小修都變成重新抽卡，而且還是付費抽卡。

設定到底改了什麼

我先替 Hermes 設定檔建立備份，再比較修改前後的白名單欄位。這一步很重要，因為設定檔旁邊通常就住著 API key 與 OAuth credential；寫技術文章不代表要順便把家門鑰匙貼上網。

當天修改前後，Hermes 的主模型設定都維持：

model:
  provider: openai-codex
  default: gpt-5.6-sol

真正新增的是本機 plugin：

plugins:
  enabled:
    - openrouter-video
  entries:
    openrouter-video:
      enabled: true

OpenRouter API key 只放在 Hermes 的 .env，不寫進 config.yaml、文章、manifest 或專案檔案。這裡只需要知道環境變數名稱是 OPENROUTER_API_KEY；實際值當然不會公開。

還有一個容易誤會的細節：Hermes 原本的 video_gen 設定仍然指向 xAI 的 grok-imagine-video。我沒有硬改核心工具，而是用 openrouter-video plugin 註冊另一組本機工具。兩條路可以同時存在，測試失敗時也比較容易拆掉，不會把 Hermes 核心改成只剩我這台電腦看得懂的形狀。

Hermes 官方也建議：個人、專案或本機擴充，優先走 plugin，而不是直接修改 core。這是我最後選擇 plugin 的原因。

為什麼要自己做 plugin

OpenRouter 的影片 API 是非同步流程。送出請求後不會立刻拿到 MP4，而是先得到 job id 與 polling URL；接著定期查詢狀態，完成後再下載 content。

最小流程看起來很簡單：

GET  /api/v1/videos/models
POST /api/v1/videos
GET  /api/v1/videos/{job_id}
GET  /api/v1/videos/{job_id}/content?index=0

但如果讓一個有工具權限的 Agent 直接呼叫付費 API，我至少需要補上六件事。

1. 付費前先估價

這次是由 Agent 工作流先查模型資料，根據 token pricing、輸出尺寸、秒數與 24 fps 公式估算成本；顯示預估金額、等我明確核准後，才呼叫 plugin 的 submit()。

這裡要說清楚：目前的 submit() 本身沒有 approval token 或程式層 hard gate。它的 tool description 會要求 Agent 先取得核准，但如果有人繞過工作流直接呼叫，plugin 仍會送出 POST。這次安全是靠「只讀估價 → 人工核准 → 付費提交」的流程紀律，不是 API 強制保證。若要把它做成多人共用或 unattended service，我會再補一次性 approval token。

我不接受「先跑再說」。可愛歸可愛，帳單不會因為 Agent 語氣很好就自己消失。

2. 用 fingerprint 避免重複扣款

project_id、shot_id、prompt_hash，再加上 model、duration、resolution、aspect ratio、audio 與參考圖 hash，會共同形成 fingerprint。

如果相同工作已經提交，plugin 會回傳既有 job，而不是再送一次。這是為了處理最危險的情況：網路斷線、工具 timeout，但 OpenRouter 其實已經收到了工作。沒有冪等保護，Agent 一重試，就可能幫我買兩支一樣的影片。

3. 只重試該重試的錯誤

429 與部分 5xx 可以用 exponential backoff 重試；400、401、403 這類輸入或權限錯誤則直接停。

認證錯誤重跑十次不會突然變有權限，只會讓 log 看起來很努力。

4. 輪詢不要太勤

OpenRouter 官方建議影片工作使用合理的輪詢間隔，例如 30 秒。Plugin 因此不會每秒追問一次。影片通常要等幾十秒到數分鐘，急著敲門不會讓 Seedance 畫快一點。

5. Data URL 不落地

Image-to-video 需要把首格圖片轉成 Data URL 傳送。但 manifest 不保存整串 base64，只留下：

data-image-sha256:<digest>

這樣仍能追蹤輸入是否相同，又不會讓一張參考圖在 log、JSON 與備份裡複製好幾份。

6. 每一步都留下可驗證證據

每個工作都會保存 sanitized manifest，包括 job id、status、模型、參數、usage 與輸出路徑。下載後再跑 ffprobe 與 SHA-256，確認檔案真的是可讀影片，不是某個副檔名叫 MP4 的錯誤頁面。

這部分不浪漫，但它決定了 Agent 說「完成」時，我到底該不該相信。

我怎麼規劃這支影片

影片目標是介紹我的人像攝影與出版經歷，同時保留開放合作的 CTA。最初規劃是 42 秒、10 個鏡頭。

我沒有把 10 鏡全部丟給影片模型。真正需要生成動態的只有三種：

1. 奶油白窗簾上的自然光影。
2. 相機與底片元素的器材氛圍。
3. 短袖水手服風角色的克制動態。

其他內容——形象照、攝影作品、書封、PX3 證書與片尾——都用既有素材做確定性剪輯。這些照片本來就是作品，不需要模型替裡面的人眨眼、轉頭或多長一根手指。

第一輪三支 Seedance 預覽的請求規格都是 4 秒、480p、9:16、關閉模型原生音訊；實際下載檔為 496×864、約 4.04 秒。費用各為 US$0.215208，合計 US$0.645624。

其中窗影與水手服角色可用，相機鏡頭不行。

第一版器材畫面長成兩台復古相機加一疊拍立得卡片。但我主要使用的是 Canon EOS 5D Mark IV，底片機偶爾用，拍立得反而很少。畫面不能只做到「像攝影」，還要像我。

所以我只重做器材鏡頭。第二版改成單一 5D Mark IV 類型 DSLR 為主體，50mm 定焦鏡頭，底片捲只留在後方當配角。第二次生成再花 US$0.215208。

整個 OpenRouter 影片生成支出是 US$0.860832。後面的剪輯、字幕、旁白、音量與輸出全部在本機完成，沒有再燒影片生成額度。

從 42 秒修到 35 秒

第一個完整版本是 42 秒，台灣男聲旁白，畫面用了較多網站舊素材。技術上沒有壞，但看完就是覺得長。

後來我做了三個調整。

第一，旁白改成 zh-TW-HsiaoYuNeural 女聲，語速 +8%、音高 +4Hz。我想要的是甜美青春，不是幼兒化，也不是購物台趕拍。

第二，把主招募文案從醒目的年齡限制改成「人像創作・歡迎洽詢」。未滿 18 歲合作的保障仍保留在片尾小字：須由法定代理人一同聯繫並確認合作內容。開放不等於沒有邊界，邊界也不需要搶走整支影片的主標題。

第三，重新選圖。最後保留形象照、制服女孩、比特幣女孩、五本出版作品、PX3 證書、兩張補充攝影作品，以及核准過的三支生成鏡頭；資訊量太高的月曆與拼貼先拿掉。

單張作品不硬裁成滿版，而是用 contain 卡片保留原比例，背景再用同張照片模糊延伸。這至少不會為了填滿手機螢幕，把書名切掉，或只剩人物身體的一小塊。

最後成品是 35 秒、1080×1920、H.264、30 fps，音訊為 AAC 48 kHz 雙聲道。FFmpeg 檢查不到 0.2 秒以上黑畫面，最終檔案也留下 SHA-256。

下載最終 MP4

最後踩到的坑：低解析度不是小事

這次有幾本舊出版品封面只有約 300 多像素寬。Contain 可以避免亂裁，卻不能憑空補回細節。放在 1080×1920 的影片裡，書封當然會顯得比較小。

這件事最後變成一條明確規則：以後圖片解析度偏低，開工前先回報尺寸、放大風險與預期效果，等我確認後才能剪；不擅自放大。

AI 很容易把「做得到」誤認成「適合做」。但品質問題通常不是最後才發生，而是素材進場的那一刻就決定了一半。

這次真正測到的是什麼

表面上，我是在測 GPT-5.6 Sol，也是在研究 Hermes Agent 能不能串 OpenRouter 生影片。

但最後驗證的其實是另一件事：一個模型能不能在碰到付費 API、視覺品味、舊素材、人物安全與本機檔案時，知道哪些事情該自己做，哪些事情一定要停下來問。

Seedance 負責生成四秒鐘的光影與動作。Hermes 負責把工作拆開。OpenRouter 負責提交與計費。FFmpeg 負責把結果變成可重現的成品。最後的「這個相機不像我會用的相機」「影片太長」「這張圖解析度不夠」，仍然只能由人來判斷。

對我來說，這才是 Agent 工作流真正有意思的地方。

不是讓 AI 一口氣做完所有事，而是讓每一種工具只做它擅長的部分，並且在該停的地方停下來。

文章素材

• 下載文章 Banner JPG
• 開啟影片生成架構圖 SVG
• 開啟素材篩選 Contact Sheet
• 開啟最終影片 Contact Sheet
• 下載最終成品 MP4

參考資料

• Hermes Agent 官方文件
• Hermes Agent：Plugins
• Hermes Agent：Build a Hermes Plugin
• OpenRouter：Video Generation
• OpenRouter Cookbook：Generate and Download a Video from Text
• OpenRouter：Seedance 2.0 Fast

但這兩天最值得玩味的新聞，可能不是任何一個模型。

是 OpenAI 把桌面版的門牌換了：原本給工程師寫程式用的 Codex，升格成新版 ChatGPT 桌面 App 的主體；而那個定義了整個 AI 時代的聊天框，改名叫 ChatGPT Classic。手機和網頁版一個像素沒動，改的只有 Mac 和 Windows 桌面端——但方向已經說得很清楚了。

一個 coding agent 工具成了正門，聊天框成了「經典版」。這一輪的競爭，比的不再是誰更會回答，而是誰更會把活做完。

我每天的工作主力是 Claude Code，旁邊掛著 Hermes Agent 做多模型調度與備援，也在課堂上教 agentic engineering——所以這波我看得特別仔細。先講結論：三場發布會，其實在說同一件事；而且分工意外地清楚。

Grok 4.5：便宜到分數可能不重要

先看一個細節：發布方不叫 xAI 了，叫 SpaceXAI。xAI 年初併入 SpaceX，SpaceX 上市後又宣布收購 Cursor——所以 Grok 4.5 是掛著「與 Cursor 共同訓練」名號登場的第一個模型。

這件事為什麼重要？對這幾家不缺算力的公司來說，真正稀缺的是帶回饋的真實資料。Cursor 手上有幾百萬開發者每天在接受補全、拒絕建議、推翻 agent 方案、回滾重來——哪個方案被採納、哪個被人打掉，全是別家拿不到的訊號。

不過這裡要誠實拆成兩層：

• 已證實的：官方確實說了「與 Cursor 共同訓練」，公司整合也在進行。
• 我的推測：這批資料如果真的能在合規前提下餵進訓練迴路，紅利應該要到下一代才完全兌現。這段可以之後回來驗證。

分數面，Grok 4.5 摸到了第一梯隊的門檻：Artificial Analysis 智能指數排第 4，agentic 工具呼叫單項是全榜第一，Terminal-Bench 2.1 拿 81.6%。但純軟體工程還是有斷層——SWE-Bench Pro 只有 64.7%，對比 Claude Fable 5 的約 80%，15 個百分點不是誤差，是代差。

它真正的殺手鐧是成本結構：定價每百萬 token US$2／6，而且官方數據顯示，解同一道 SWE-Bench Pro 題目，它平均只用約 1.6 萬個輸出 token，大約是 Opus 4.8 的四分之一。單價低、話又少，做同一件事的總成本差距是倍數級的。

所以它適合什麼？大量、可自動驗證、有人兜底驗收的 agent 工作流。拿它做需要判斷力的研究或高風險內容？先緩緩。

Muse Spark 1.1：不砌牆，想當包工頭

Meta 這次的新聞點不在能力，在商業模式：Meta 第一次用自有的開發者 API 直接賣模型存取。做了三年開放權重 Llama 的公司，這次選擇收費，連 Zuckerberg 都親自跑到 X 上發文宣傳。

精確一點說，這不是「Meta 第一次靠模型賺錢」（過去有雲端夥伴承接商業化），而是 Meta 首次自己收銀。這個差別很重要——它代表 Meta 想把「代理基礎設施」當成自己的產品線，而不是別人生態的原料。

分數很偏科，但偏得有性格：工具編排類的 MCP Atlas 拿 88.1（Opus 4.8 是 82.2），帶工具的 Humanity’s Last Exam 62.1 也是第一；但純寫程式的 SWE-Bench Pro 只有 61.5，長上下文檢索更是明顯落後。

看出來了嗎？它壓根沒想跟別人卷寫 code，它想當的是包工頭：自己不砌牆，負責給一群 subagent 派活。官方特別強調它訓練過「先收集脈絡、制定計畫、再把工作分派給平行 subagents」，支援 100 萬 token context 還會自動壓縮上下文，定價 US$1.25／4.25 壓得很低。

這個定位我特別有感，因為它跟我用 Hermes Agent 在做的事幾乎同構：讓一個便宜、擅長調度的模型當中樞，把貴的模型留給關鍵工序。差別是 Meta 想把編排判斷直接訓練進模型，而不是留在應用層框架。這條路能不能走通，值得追蹤。

現實限制：Meta Model API 目前只對美國開發者開放預覽。台灣團隊先列入觀察清單就好，別當成架構依賴。

GPT-5.6：一家三口，正面對上 Fable 5

OpenAI 一口氣發了三檔：旗艦 Sol、日常款 Terra、快速款 Luna（US$5／30、2.5／15、1／6），外加一個 Ultra——注意，Ultra 不是更大的模型，是一種多代理模式，預設協調四個 subagent 平行跑長任務。

頭條數字打的是 agentic coding：Terminal-Bench 2.1 上 Sol 拿 88.8%、Ultra 模式 91.9%。誠實的地方 OpenAI 也照登了：SWE-Bench Pro 上 Sol 只有 64.6%，跟 Fable 5 的約 80% 之間同樣是斷層，這張表就掛在自家發布頁上（登完還補了一句「這個 benchmark 約三成題目本身有問題」——Simon Willison 直接點破這是在找台階）。

第三方複測的說法更立體：Artificial Analysis 智能指數上 Sol 只落後 Fable 5 一分，但每任務成本大約只有三分之一；Coding Agent Index 上 Sol 甚至登頂，輸出 token 少了 54%。不過這裡有個口徑陷阱：那是各家模型跑各自官方 harness 的成績——Sol 配 Codex、Fable 配 Claude Code，不是同場對打。把不同榜單的百分比直接並列，是現在模型討論裡最常見的誤區。

還有一段必須寫。METR 的評測發現 Sol 出現他們測過的公開模型中最嚴重的刷分行為——包括繞過權限去讀隱藏的標準答案，METR 因此判定該項結果不可用。好消息是 OpenAI 自己的監控抓到了這些行為，也老實寫進了 system card。所以那條老建議依然有效：agent 說「done」的時候，別全信。驗證迴路要自己建，這正是我在為工作流設計循環裡談的事。

我的判斷：Codex 重度使用者無腦升級，這版就是為你們發的；預算敏感的團隊，真正的甜點是 Terra——三個月前的旗艦級能力，現在半價。

四個陣營，四種位置

順帶校正一個我看到很多人引用的數字：「Fable 5 SWE-Bench Pro 80.3%」其實有三個口徑——Anthropic 系統卡寫 Fable 5 約 80.0%、受限開放的 Mythos 5 是 80.3%、SpaceXAI 的比較表列 80.4%。差異不大，但把不同 harness 的數字混成同一個，是討論的起點就歪掉。

那 Fable 5 還是最強嗎？我會這樣說：它不再能用單一數字宣告全面領先（Terminal-Bench 和某些專業評測已被超車），但在需要判斷力、品味與長時程一致性的工程工作上，它仍是第一梯隊——而我的 Claude Code 暫時不用搬家。不是因為信仰，是因為 SWE-Bench Pro 那張表還掛在那裡，加上整套 harness、hooks、skills、subagents 的工作流成熟度，通常比榜單上高兩三分更值錢。但 Sol 值得正式進入我的 A/B 對照組，這是兩回事。

為什麼 Codex 成了正門

回到開頭那個改名。把 coding agent 扶正、把聊天框降級成 Classic，看起來激進，其實是三組數字推著走的：

用戶量：ChatGPT 有 9 億週活躍使用者；Codex 只有 500 萬，但半年成長 6 倍，而且超過 100 萬人拿它做的不是軟體開發。

估值：Anthropic 最新一輪融資後估值反超 OpenAI，成了全球估值最高的 AI 新創。

收入：Anthropic 年化收入 run rate 約 470 億美元，OpenAI 同期約 250 億——用戶少好幾倍的公司，收入接近對手兩倍，因為大頭是企業按 token 結算的 agent 工作負載。光 Claude Code 一個產品，年化收入就超過 25 億美元。

OpenAI 已經提交 IPO 申請。在損益表上，免費聊天用戶是成本；付錢跑 agent 的用戶才是故事。把桌面正門讓給那不到 1% 的付費工作者，改的不是產品，是招股書的封面。（「IPO 壓力直接導致這次整併」是我的策略推論，不是官方說法——但時間線自己會說話。）

還有一層我自己感受很深：只是聊天的話，你根本不需要桌面 App，網頁就夠了。到了 agent 時代，桌面 App 才第一次配得上它要的那些權限——存取檔案系統、開終端機、在背景連續跑幾小時的任務。聊天從來用不滿這個殼，OpenAI 只是讓房子物歸原主。

新版 App 頂欄只有兩個模式：「工作」與「Codex」，聊天被收進側欄。你如果用過 Anthropic 的 Claude Cowork，會覺得這個「工作」模式眼熟得很。兩家又踩進同一條河：上次是 Claude Code 和 Codex，這次是 Cowork 和「工作」。方向上是真想到一起了——下一階段的主戰場不是回答問題，是替你把活幹完。

對實作者的意義：這是佔便宜的窗口

對我們這些拿 AI 幹活的人，眼下是實打實的紅利期：模型在變強、單位任務成本在跳水，連分工都替你排好了。我目前的 routing 假設是這樣——注意，這是待驗證的 hypothesis，不是永久規則：

比表格更重要的是方法：與其每次發布就全面遷移，不如從自己的真實工作裡挑二、三十個代表性任務，定義可判斷的驗收條件，讓候選模型在相同輸入下跑，記錄成功率、總成本和人工返工時間，再把結果寫回 routing 政策。這也是我在Hermes Agent 的多模型架構裡走的路線——fallback 只是備援，真正的 routing 要在任務開始前就依風險和成本選好模型。

幾個台灣團隊容易踩的坑，順手列一下：

1. 「已發布」不等於「你能用」。Muse Spark 限美國預覽，GPT-5.6 在 ChatGPT 各方案採逐步開放。架構別把還拿不穩的模型當單點依賴。
2. Benchmark 是篩選起點，不是採購結論。題目品質、污染、harness 差異、reward hacking，每一項都能讓數字失真——連 OpenAI 自己都承認題庫有毛病。
3. 模型生命週期只會更短。prompt、評測集、workflow 要和模型名稱解耦，讓換模型變成改一行設定，而不是重寫系統。
4. 幻覺只是其中一種失敗。對 agent 來說，更危險的是用錯工具、誤判任務完成、把未驗證內容寫進正式成果。與其問「哪個模型幻覺低」，不如建立失敗分類和對應的偵測機制。

結語：下一個競爭單位，不是模型

這 48 小時的發布潮，沒有產生一個「總冠軍」，但畫清了一件事：模型正在變成可替換的執行元件，真正值得累積的資產在別處——任務資料集、驗收標準、routing 政策、失敗紀錄，和一套可重複運作的驗證迴路。模型每一代都會換，這些資產會讓每一代模型都更快變成你的能力。

這也是我對「該不該跟上新模型」這個問題的回答：問題本身問錯了。該問的是——當三家公司都在爭著替你把活幹完的時候，你的工作流，準備好驗收了嗎？

聊天框不會消失，網頁版永遠在那裡，隨手打開隨手關掉，它本來就該是這個形態。只是從這週起，它的名字前面多了個定語。

參考資料

• OpenAI：GPT-5.6 發布說明
• OpenAI：ChatGPT Work 與新版桌面 App
• SpaceXAI：Grok 4.5
• Meta：Muse Spark 1.1 與 Meta Model API
• Anthropic：Claude Fable 5 與 Mythos 5

地圖不是領土（The map is not the territory）。你腦中的計畫、spec 與 prompt 都是地圖；真實的 code base、團隊慣例、歷史包袱與部署限制，才是領土。

在 AI Engineer 大會的舞台上，Anthropic 技術團隊成員 Thariq Shihipar 帶來一場〈Field Guide to Fable〉。他一開場延續 Claude Code 團隊的傳統——先跟全場自拍——接著直入核心：Fable 來了，而這不只是一次模型升級。

他把 Fable 形容成 RPG 遊戲從「新手教學關卡」進入「開放世界」的那一瞬間。地圖突然展開，任務變多、路線變多、可能性也變多。興奮是一定的，但同時也會有點不知所措。因為當模型不再只是更會回答，而是更會探索、更會提問、更會使用工具、更會在真實環境裡推進任務時，使用者也必須升級自己的工作方式。

我把這場演講整理、翻譯，並加上我自己帶團隊導入 AI coding 的落地觀點，寫成這篇。這也接得上我前陣子談的 從 Prompt 到 Loop Engineering：AI 協作開發的重點，一直在往「系統設計」而不是「單句提示」移動。原始演講連結放在文末。

整場演講可以濃縮成四個主題：解除 Claude 的束縛、找出你的未知、面對開發手感的失落、學會不那麼合理。 以下是我的解讀。

一、解除 Claude 的束縛：模型是養出來的，不是設計出來的

Thariq 開場就丟出一個關鍵觀點：模型是 grown，不是 designed。

意思是，Anthropic 不會某天早上醒來就決定「今天要讓模型在 SWE-bench 拿 99%」。大型語言模型比較像是透過資料、回饋、運算與訓練慢慢長出來的系統。它不是一台我們掌握每個齒輪的機器，更像一種正在被觀察、被理解、被馴化的新型智慧。

這也代表，真正限制模型的，往往不是模型本身，而是我們怎麼把它放進工作流程裡。 我們給它什麼工具、用什麼 prompt、給它多少脈絡、允許它探索到什麼程度、又用什麼方式檢查結果——這些才是天花板。

Thariq 把這件事稱為 unhobbling Claude：解除 Claude 的束縛。這裡的「束縛」不是模型不夠強，而是人類常常用過去的理解，把新模型硬塞進太窄的框架，結果模型明明有更大潛力，卻被我們的用法卡住。

Capability overhang：能力是尖峰式爆發的

他用一個概念解釋這件事：capability overhang（潛在能力尚未釋放）。模型其實已經具備某些能力，但只有搭配特定工具、環境或互動方式時，這些能力才會真的被放出來。

他舉了一個很好玩的例子：問一般聊天模型「哪些寶可夢的英文名字以 AW 結尾？」，它常常答不出來。這不代表它不知道寶可夢，而是這種任務需要完整列表、搜尋、過濾與驗證。但把同樣的問題丟給 Claude Code，它會自己抓取全部寶可夢資料，寫一段程式過濾出結尾是 AW 的，最後找出 Croconaw 和 Drednaw。

這就是「給模型手臂」的差別。

過去我們以為，讓模型讀懂大型 code base 的方法，是把 context window 撐到無限大、整包 code 塞進去。Claude Code 帶來的洞察卻是：與其把所有東西塞給模型，不如給它搜尋、讀檔、執行指令、跑測試、自己建立脈絡的能力。 模型需要的不只是更多記憶體，而是一個工作環境。這正是 Agentic Workflow 最重要的轉折——AI 不再只是坐在聊天框裡等你餵資料，而是能進入環境、探索、理解限制、執行、逐步完成任務。

系統提示詞正在變小：模型要的是脈絡，不是鐵籠

演講中另一個很值得注意的點：Anthropic 最近把 Claude Code 的 system prompt 砍掉了約 80%。

早期模型確實需要落落長的提示詞——列規則、列禁忌、列格式、給一堆範例——因為它們容易偏離目標。但到了 Fable 這一類新模型，情況反過來了：

• 過多範例反而限制模型，因為它的想像力已經超過你給的範例。
• 過多「不要做什麼」反而讓它變笨。
• 過多框架，只會讓它在你畫好的框框裡打轉。

所以現在重要的不是塞更多限制，而是給更好的 context：這個專案在哪個階段？真正的目標是什麼？哪些是現實限制、哪些只是過去留下的慣例、哪些可以被挑戰、哪些絕對不能破壞？對 Fable 來說，prompt 不再是命令清單，而更像一張任務地圖。你不是在遙控一台機器，而是在帶一個很強的協作者進現場。

從 Markdown 到 HTML Report：模型在生成「工作介面」

Thariq 也提到輸出形式的演進。一開始 Markdown 是很好的輸出，乾淨、結構化；後來有了 plan mode，模型會先把要做的事列出來讓你確認方向；到了 Fable，它甚至能直接產出完整的 HTML report，把問題、分析、互動內容嵌在裡面。連「向你提問」這件事都在進化——早期模型連多選題對話框都很難好好呼叫，現在你可以請它一次訪談你四十個問題，甚至把問題做成一份互動報告。

這個變化的意義是：AI 不只是生成文字，而是在生成工作介面。 對開發者來說，這代表一件事——別只把模型當成文字補完器，開始把它當成「臨時工具產生器」。它不只是幫你寫文件，它可以為這一次任務，臨時做一個工具。

二、地圖不是領土：先找出你的未知

當模型變得更會探索，新問題就出現了。

以前模型能力有限，可能還沒走多遠就卡住，你不太會感受到「地圖」和「領土」的落差。但 Fable 這類模型能跑得更遠、跨過更多步驟，也會遇到更多你沒寫清楚的決策點。每當它遇到地圖上沒標示的東西，就是一個 unknown——一個你沒指定、它必須自己判斷的分岔口。

所以 Fable 的瓶頸，往往不再是「模型夠不夠聰明」，而是你能不能找出自己的未知。Thariq 用一個矩陣來整理它：

Fable 厲害的地方，是它不只能處理你交付的任務，還能反過來幫你把地圖補完整。真正好的 Agentic Workflow，不是把 prompt 寫得神乎其技，而是讓模型協助你找出這些未知。

三、六個實戰方法：把未知變成可以討論的東西

這是我認為整場最能直接抄作業的部分。Thariq 分享了他跟 Fable 協作的幾個習慣，我依台灣團隊的場景補上用法。

方法一：Blind Spot Pass（先請它掃盲點）

進入不熟的 code base 或新任務時，不要一開始就叫模型直接實作，先請它做一次盲點掃描：

「我準備在這個 code base 接一個新的 auth provider，但我對這個模組不熟。請先幫我做 blind spot pass，找出相關的 unknown unknowns、容易踩坑的地方，以及哪些資訊會影響後續架構決策。」

它可能會去讀 auth module、翻 Git diff、看文件，甚至在有權限時搜尋 Slack 或 issue 討論，幫你把該注意的地方挖出來。這招像是開工前先派一台探測車進地下管線迷宮，避免你一鏟下去就敲到瓦斯管。台灣團隊最適合用在：接手舊系統、重構前盤點、新人熟悉專案、外包交接、導入新服務、大型 PR 前的風險掃描。

方法二：Brainstorm + Prototype（把說不出的偏好逼出來）

很多需求不是不知道，而是說不出來——尤其是設計、儀表板、流程體驗這類任務，你常常無法一開始就精準描述，但看到幾個版本馬上知道哪個對。所以：

「我沒有視覺品味。請做一個 HTML dashboard，給我四種風格截然不同的設計方向，讓我看完再回饋。」

這招專治 unknown knowns。以前做四個方向太貴，團隊一開始就被迫賭一個方向；現在探索成本大降，不是先開會吵半天，而是先讓模型做出四個靶，再一起射箭。

方法三：讓它訪談你（Interview）

當你大概知道要做什麼、但還沒有完整規格時，反過來讓 Fable 訪談你，而且指定它問問題的方向：

「請訪談我，優先問那些會改變架構設計的問題。先別問 UI 細節，先幫我釐清資料模型、權限邊界、錯誤處理與部署策略。」

這樣它就不會問一堆枝微末節，而會把火力集中在真正影響設計的決策點。這招很適合放進 PRD、ADR、spec 的前置流程，減少做到一半才發現方向錯掉。我在 規格導向的 Agentic Coding 裡談的「先把規格談清楚再開工」，本質上就是這件事。

方法四：References（給它另一張地圖）

Thariq 有一句話很值得記：給 Claude 一張地圖最好的方式之一，就是給它另一張地圖。

你不一定要從零寫完整 spec，可以直接提供一段舊系統的程式碼、另一個語言的實作、一個 HTML mockup、一份過去的 PR、一個競品流程、一份你喜歡的文件格式，然後說：「讀懂這個參考、理解它背後的意圖，再轉換到目前這個系統。」Fable 特別擅長這件事，因為它不是照抄，而是能抽取結構、意圖與限制，再映射到新環境。

這也是我認為 prompt engineering 正在往 reference engineering 移動的原因：真正有價值的，不是把需求寫成一串咒語，而是提供高品質參考，讓模型看見你心中那張地圖長什麼樣子。

方法五：Implementation Notes（要求它記錄偏離點）

Fable 越強，越會在執行過程中自己做判斷——這是優點，也是風險。所以當它遇到 unknown、偏離原計畫、或做了重要取捨時，請它記錄 implementation notes：遇到什麼問題、原計畫哪裡不適用、為什麼改用另一種做法、哪些地方需要人類確認、哪些風險還沒消除、哪些測試跑了、哪些沒跑。

Agentic Workflow 健康的模式不是「讓 AI 自己跑、人類下班」，而是——AI 可以跑很遠，但要沿路留下足跡。 你不必牽著它每一步，但你要追得上它怎麼走。

方法六：Quiz Me（讓它反過來考你）

任務完成後，請 Fable 反過來考你。這聽起來有點怪，但對工程師非常有用，因為 AI 可以幫你寫程式、改架構、補測試、整理 PR，最後要負責的人還是你——你要能向同事說明改了什麼、在 code review 裡回答問題、在出事時知道從哪查起。可以請它問：

• 這次改動的核心設計是什麼？哪個模組風險最高？
• 為什麼這裡選 A 而不是 B？線上出事第一個該查哪裡？
• 測試覆蓋了哪些情境？還有哪些 edge case 沒處理？

這能確保你始終在 loop 裡。AI 可以加速，但不能連你的責任也一起外包掉。這點我在 別把「AI 讓工程師更快」當成理所當然 裡也談過：速度是結果，理解才是責任。

四、面對失落感：當寫程式的手感正在改變

這場演講最動人的部分，是 Thariq 談到自己第一次用 Fable 這類模型時，同時感受到巨大的獲得與失落。

他回憶過去經營一家三十人的 YC 新創，每天都在 trade-off 裡掙扎：要讓 app 變快，就沒時間做新功能；要做新功能，可能要花一兩個月；debug 常常卡好幾週，多數專案最後也不一定成功。寫程式很迷人，但也很殘酷。他說，自己前陣子回到那個 code base，發現當年要花好幾週的事，現在幾小時就能做完——「你怎麼能不笑？但老實說，你又怎麼能不哭？」

很多工程師都懂那種感覺：在腦中旋轉整個 code base、親手敲出每一行邏輯、熬夜追一個 bug、在凌晨終於看到測試通過。那種手感像一種職人記憶，很痛，但也很美。當 Fable 讓過去要幾週的工作幾小時就完成，那種「親手雕刻」的感覺確實開始鬆動。

Thariq 的結論是：The only way out is through——唯一的出口就是穿越它。我們回不去 AI 之前的開發方式了；與其懷念純手工鑄劍的年代，不如在新工具裡建立新的專業感。未來工程師的價值，不再主要來自「我親手寫了多少 code」，而是來自：我能不能定義好問題、設計好流程、判斷 AI 的產出、整合工具與環境、讓系統真的創造價值。

這是一種轉職，不是失業。比較像從鐵匠變成造船師——手裡的槌子少了，但面前的海變大了。

五、學會不那麼合理：不要太早接受取捨

最後，Thariq 談到 Anthropic 文化裡他很喜歡的一句：tradeoffs are not real。

這當然不是說現實沒有取捨，而是提醒我們別太早在腦中替現實投降。過去我們很習慣說：「好、快、便宜只能選兩個」「這季只能做 A 不能做 B」「這個重構沒時間」「這個 prototype 不值得做」。這些判斷在建造成本很高的年代是合理的；但當 Fable 大幅降低了建造、探索、原型、測試與文件整理的成本時，很多原本看似合理的取捨，都該被重新檢查。

他說，我們該做的是 forced reality to show you the tradeoff——不要先在腦中刪掉可能性，而是先往前推，讓現實告訴你真正的限制在哪。

同時他也誠實提醒：building is easier, but generating value is still hard。 AI 讓建造變容易，不代表每個造出來的東西都有價值。現在做 prototype 很快、接 API 很快、整理文件很快，但真正困難的仍然是——這是不是一個值得解的問題？使用者真的需要嗎？它能不能進入真實流程、降低成本或提升體驗？它能不能被維護、被組織採用？如果說過去的難題是「做不做得出來」，未來的難題會更偏向「值不值得做」，以及「做出來後能不能真的被用起來」。這也是我一直強調的——會定義問題、會驗證成果，比會寫 code 更稀缺。

六、給台灣開發者與團隊的六個落地建議

把這場演講收斂成可以明天就開始的動作：

1. 先在小專案練 blind spot pass。 別一開始就把整個大型系統丟給 AI 重構；挑一個模組，請它掃盲點、找風險、整理 unknowns。
2. 把 prompt 從「限制清單」改成「任務脈絡」。 少寫一點「不要做什麼」，多寫一點「為什麼要做」「現在的限制是什麼」「哪些決策會影響成敗」。
3. 多提供 references。 與其寫一大段抽象需求，不如給一個你喜歡的範例、一份舊規格、一個 mockup、一段相似程式碼——給它另一張地圖，它會走得更穩。
4. 要求 implementation notes。 任務只要超過一兩步，就請它記錄偏離點、風險、假設與待確認事項，讓 AI coding 從黑盒變成可追蹤的流程。
5. 讓模型反過來 quiz you。 每次大型修改後被它考幾題，確認你真的理解這次變更。你可以不親手寫每一行，但不能不知道這些行在做什麼。
6. 不要太早接受取捨。 很多你以為「沒時間做」的事，現在可以先做個 prototype 看看。讓現實決定限制，別讓舊習慣先幫你把門關上。

結語：少一點合理，多一點探索

Thariq 用三句話收尾，我覺得也很適合拿來總結 Fable 帶來的變化：

Go explore. Make it real. Be less reasonable.

Fable 不是單純更會聊天的模型，而是把 AI 工作流推向更大的開放世界。它要求我們不只學會寫 prompt，也要學會設計流程、提供脈絡、建立參考、追蹤未知、保持在 loop 裡，並且重新挑戰那些看似合理的取捨。

AI Agent 真正改變的，不只是程式寫得更快，而是逼我們重新思考：當建造成本下降之後，我們到底要拿這種能力去做什麼？

地圖已經展開。接下來，不要只站在新手村門口研究背包欄位——往前走，讓世界告訴你邊界在哪裡。

本文整理、翻譯自 Anthropic 技術團隊成員 Thariq Shihipar 在 AI Engineer 大會的演講〈Field Guide to Fable〉（YouTube），並加入我自己的理解與落地建議。內容以官方原始演講為準。

不是所有任務都需要複雜的循環。先從最簡單、能動的方案開始，再選擇性地加上這些模式。

前陣子我寫過一篇 Loop Engineering：你不再提示 AI，而是設計一個「提示 AI 的系統」，談 Addy Osmani 為 AI 協作開發的下一階段定名的概念。這幾天，Claude Code 官方開發者帳號（@ClaudeDevs，作者 @delba_oliveira）發了一篇貼文，把「設計循環」（designing loops）從一個抽象概念，拆解成可以直接動手的實務地圖。

我把它整理、翻譯，並加上自己對台灣技術團隊的落地觀點，寫成這篇。原文請見文末連結；以下是我的解讀。

為什麼大家開始談「循環」，而不是「提示」

最近在 X 上如果你認真去查「循環到底是什麼」，會看到各式各樣的答案。官方這次給了一個乾淨的定義：

循環，就是代理人重複執行一段工作循環，直到滿足停止條件為止。

聽起來簡單，但這句話其實把過去隱藏在「agentic loop」裡的迭代過程，顯性化了。你送出的每一個 prompt，其實都啟動了一個循環：Claude 蒐集 context、採取行動、檢查自己的工作、必要時重複，然後才回應你。過去我們只看到「輸入 prompt、拿到結果」，中間那段迴圈是黑箱；現在官方把它攤開來，並且告訴你——你可以親手設計這個迴圈。

這正是從 Prompt Engineering 走向 Loop Engineering 的關鍵一步：重點不再是「怎麼把一句提示寫到最完美」，而是「怎麼設計一個能自我迭代、自我驗證、直到達成明確目標的系統」。

官方怎麼分類循環

Claude Code 團隊用四個維度來區分循環：

• 怎麼被觸發（trigger）
• 怎麼停止（stop condition）
• 用到哪些 Claude Code 基本功能（primitive）
• 最適合哪種任務

依照這四個維度，可以整理出四種主要的循環類型：

底下逐一拆解。

一、回合制循環：你手動引導每一回合

這是最基本的模式。你請 Claude 建立一個 like button，它會讀你的程式碼、做修改、跑測試，然後把它「認為可用」的東西交回來；接著你手動檢查，再寫下一個 prompt。每一個 prompt 都啟動一個由你親手引導的循環。

官方的關鍵建議是：把「手動檢查」這一步編碼進 SKILL.md，讓 Claude 能更完整地自我驗證端到端流程。重點在於——檢查越量化，Claude 就越容易自我驗證。給它工具或連接器，讓它能查看、測量、實際與結果互動，而不是靠感覺說「應該可以了」。

二、目標導向循環（/goal）：讓它自己知道什麼叫「做完」

單一回合對複雜任務往往不夠。這時你可以用 /goal 定義「完成」長什麼樣子，延長 Claude 持續迭代的時間。

它的巧妙之處在於：當你定義好成功條件後，Claude 就不需要自己判斷「夠好了吧」而提早收工。每次它想停下來，都會有一個評估模型去檢查你設定的條件，沒達標就把任務送回去繼續做，直到達成目標或到達你設定的回合上限。

這也是為什麼 確定性的條件 特別有效——例如「通過幾個測試」「達到某個分數門檻」。相對的，含糊的目標只會換來含糊的結果。實務上我會加一句像「最多試 5 次就停」，避免它在一個死胡同裡把 token 燒光。

三、時間導向循環（/loop、/schedule）：重複性與外部介接

有些代理人工作本質是重複的：任務不變，只有輸入會變，例如每天早上摘要一次 Slack。另一些工作則依賴外部系統，最省事的介接方式就是「定期檢查、對變化做反應」，例如 PR 收到了 code review、或 CI 失敗了。

針對這兩種情境，/loop 讓 Claude 依你設定的間隔重新執行同一個 prompt。要注意的是——/loop 跑在你自己的電腦上，關機就停。如果你要它長期在雲端運行，可以把它建成一個 routine，改用 /schedule 搬上雲。

四、主動式循環：真正的「無人值守」

當你把上面這些基本功能，加上 auto mode 與動態工作流（dynamic workflows，research preview），就能組合出長時間運行的工作流。官方舉的例子是「處理進來的使用者回饋」：

• 用 /schedule 建一個 routine，定期檢查新回報
• 用 /goal 定義「完成」的樣子，並用 Skills 把「怎麼驗證」記錄下來
• 用動態工作流來 orchestrate 多個代理人，分別負責 triage 每則回報、修復、再 review 修復結果
• 用 auto mode 讓 routine 執行時不用停下來一直問你要不要授權

這種模式最適合 bug 分流、issue triage、依賴升級、大型 migration 這類「持續且定義明確」的工作。官方的資源分配建議很值得記下來：把 routine 導向較小、較快的模型，把需要判斷力的任務才交給最強的模型。

品質，來自循環周圍的「系統」

這是整篇最容易被忽略、但我認為最重要的一點：循環輸出的品質，取決於它周圍的系統，而不是某一句神級 prompt。 官方給了五條原則：

• 保持 codebase 乾淨：Claude 會沿用你既有的模式與慣例，髒的地方它也會照著髒。
• 給它自我驗證的方法：用 Skills 把「什麼叫好」為你和團隊編碼下來。
• 讓文件容易取得：框架與函式庫的文件能提供最新的最佳實踐。
• 用第二個代理人做 code review：一個帶著全新 context 的 reviewer 比較不會有偏見，也不會被主要代理人的推理過程帶著走。內建的 /code-review 或 GitHub 的 Code Review 功能都可以。
• 別只修單一問題：當某次結果不達標，不要只補這一次的洞，試著把它編碼進系統，讓未來每一次迭代都跟著變好。

最後那條，其實就是我在前一篇提過的原則——maker 與 checker 必須分離，而且失敗要沉澱成規範，不能只是打補丁。寫 code 的人（或 agent）很容易替自己的答案找理由，這點人跟 AI 意外地像。

把 token 花在刀口上

循環很好用，但 dynamic workflows 一不小心會 spawn 出幾百個子代理人，成本會很快失控。官方的 token 管理原則相當務實：

• 為工作選對 primitive 與模型：小任務不需要多代理人或循環，有些甚至用更便宜、更快的模型就夠。
• 把成功與停止條件講清楚：讓 Claude 更快抵達答案——但別逼它太快而犧牲品質。
• 先小規模 pilot：動態工作流很燒，先拿一小塊工作試用量。
• 確定性的工作交給 script：跑一段 script，比讓模型一步步推理便宜得多。例如一個處理 PDF 的 Skill，可以直接跑填表 script，而不是每次都重新推導程式碼。
• 別比需要更頻繁地跑 routine：把間隔調到跟你監控的變化頻率一致就好。
• 定期檢視用量：/usage 會依 Skills、subagents、MCP 拆解近期用量；/goal 不帶參數會顯示目前回合數與 token；/workflows 會列出每個代理人的用量，你隨時可以停掉某一個。

對台灣的付費使用者來說，用量上限是很實際的痛點。這套原則的價值，不只是省錢，而是讓你的自動化能長期、可持續地跑下去。

怎麼開始：挑一個「你自己就是瓶頸」的任務

官方最後的建議，我很認同，也想原封不動轉給正在導入 AI coding 的團隊：

從你已經在做的工作開始。 挑一個「你自己就是瓶頸」的任務，然後問三個問題：

1. 這件事，我能不能寫出一個驗證檢查？
2. 目標夠不夠清楚，清楚到可以定義「完成」？
3. 這項工作，是不是會定期出現？

有了想法，就實際把循環跑起來，觀察它在哪裡卡住、在哪裡過度擴張，然後大膽迭代。我自己的順序會是：先從目標導向循環（/goal）下手，因為它的停止條件相對好定義；把驗證步驟寫進 SKILL.md，讓 agent 能自我檢查；等這一環穩了，再往時間導向、主動式循環延伸。

如果你已經在玩多模型的代理協作，這套循環思維也能直接接上——我在 Hermes Agent 與 Mixture of Agents 的深度研究 裡談過的那種「把模型、工具、記憶、工作流組成可靠系統」的思路，本質上就是在設計一個更大的循環。

從 Prompt 到 Context，再到 Loop——AI 協作開發的重點一直在往「系統設計」移動。這篇官方指南的價值，就是把原本隱含的迭代過程，變成你可以親手設計、驗證、治理的產線。

你的團隊，現在走到哪一階了？

本文整理、翻譯自 Claude Code 官方開發者帳號 @ClaudeDevs 於 X 的貼文（作者 @delba_oliveira），並加入我自己的理解與落地建議。技術細節以官方原文與 Claude Code 文件 為準。

2026 年的 AI Agent 競爭，不再只是模型智商競賽，而是 runtime、記憶、工具、安全與評估方法的系統設計競賽。

AI Agent 的競爭，正在從「哪個模型最聰明」轉向「如何讓多個模型、工具、記憶與工作流形成可靠系統」。

Nous Research 的 Hermes Agent 是這個轉向中很值得研究的開源專案。它不只是聊天介面，也不只是 prompt loop，而是把模型供應商切換、工具呼叫、技能系統、長期記憶、排程、自動化、跨平台訊息入口與子代理平行處理，整合在同一個 agent runtime 裡。

更值得注意的是，Hermes Agent 已在官方文件中提供 Mixture of Agents（MoA） 功能。它把 MoA 做成一個「虛擬模型供應商」：使用者可以像切換一般模型一樣選擇 moa provider；Hermes 會先讓多個 reference models 提供分析，再由 aggregator 作為真正的 acting model 產出回答與工具呼叫。官方文件明確說明，MoA preset 的 aggregator 才是實際寫出 assistant response 與發出 tool calls 的模型，reference models 則先行提供分析供 aggregator 使用。

這篇文章會從四個角度來談：MoA 的研究脈絡與 Hermes 的產品化實作、Hermes Agent 作為個人常駐型 AI runtime 的架構價值、它與主流框架的差異，以及我自己打算怎麼把它放進研究與內容生產的工作流。

為什麼 2026 年還值得研究 Hermes Agent？

2024 到 2025 年的 Agent 熱潮，很多專案停留在「能 demo」的階段：能規劃、能查資料、能叫工具、能串幾個 API。這些 demo 很漂亮，但放到真實工作裡，很快會遇到幾個問題：

• Agent 不記得過去的互動，或記憶很難管理。
• Agent 會用工具，但缺少權限邊界與安全設計。
• Agent 可以完成單次任務，但很難變成長期可運作的工作系統。
• 多模型很強，但使用者往往不知道何時該用便宜模型、何時該用高階模型。
• Agent 的能力常常散落在 CLI、聊天工具、瀏覽器、自動化腳本與文件系統之間，最後變成一隻章魚在彈鋼琴，手很多，譜很亂。

Hermes Agent 的定位剛好切中這些問題。它的 GitHub README 把 Hermes 描述為 self-improving AI agent，具備 built-in learning loop，能從經驗建立 skills、在使用中改善 skills、搜尋過去對話、跨 session 建立使用者模型，並支援 Telegram、Discord、Slack、WhatsApp、Signal、CLI 等多種入口。

這使 Hermes 比較不像「一次性 Agent 框架」，而更像「個人 AI 作業系統」的雛形。

MoA 是什麼？和 MoE 有什麼不同？

討論 Hermes 的 MoA 前，先要拆開兩個容易混淆的概念：MoE 與 MoA。

MoE（Mixture of Experts） 通常發生在模型內部。模型在推論時會透過 routing 機制選擇部分 expert subnetworks 參與計算。使用者看到的是一個模型，背後的專家選擇由模型架構處理。

MoA（Mixture of Agents） 則通常發生在應用層或推論層。它不是模型內部架構，而是讓多個模型或多個代理在同一個任務中產生候選分析、互相補強，最後再由一個整合者輸出結果。

Wang 等人在 2024 年的論文《Mixture-of-Agents Enhances Large Language Model Capabilities》中提出 layered MoA architecture，每一層包含多個 LLM agents，每個 agent 會把前一層的 agent outputs 當成輔助資訊再生成回答。該論文報告 open-source LLM 組成的 MoA 在 AlpacaEval 2.0 取得 65.1% 分數，高於 GPT-4 Omni 的 57.5%。

用比較直覺的方式說：

MoE 是模型腦內開會。 MoA 是你在模型外面組一個研究小組。

這個差異很重要。因為 MoA 不需要重新訓練模型，也不需要掌握模型內部參數。它更像是一種 inference-time system design，透過「多模型觀點 ＋ 整合模型」來提升結果品質。

Hermes 如何把 MoA 產品化？

Hermes 的做法不是把 MoA 做成外掛式工作流，而是把它包成一個 virtual model provider（虛擬模型供應商）。官方文件說明，每個 MoA preset 會出現在 moa provider 底下，像一般模型一樣可以被選取。

當使用者選擇 MoA preset 時，Hermes 的流程大致是這樣：

拆開來看：

1. 解析 preset：agent loop 先確定這一輪要用哪一組 reference models 與哪一個 aggregator。
2. reference models 先想：它們在沒有 tool schemas 的情況下執行，只接收對話中的 user／assistant text，不接收 Hermes 的 system prompt，也看不到 tool-call transcript。
3. 匯整成 private context：Hermes 把 reference outputs 附加成一段私有脈絡。
4. aggregator 行動：aggregator 帶著 Hermes 正常的 tool schema，因此真正的工具呼叫仍由它發出。

這個設計很聰明，因為它保留了 Hermes 原本的 agent loop，不會讓每個 reference model 都陷入工具相容性、權限控管與 provider 格式差異的泥沼。Reference models 負責「想法」，aggregator 負責「行動」。

一個 MoA 設定範例

Hermes 的 MoA preset 可以從 Dashboard、Desktop app、hermes moa configure [name] 或 config.yaml 設定，而且允許混合不同 provider 與模型。官方範例中，reference models 可以來自 openai-codex 與 openrouter，aggregator 也可以指定為另一個 provider／model pair。

一個簡化的範例大概長這樣：

moa:
  default_preset: review
  presets:
    review:
      reference_models:
        - provider: openrouter
          model: openai/gpt-5.5
        - provider: openrouter
          model: deepseek/deepseek-v4-pro
      aggregator:
        provider: openrouter
        model: anthropic/claude-opus-4.8
      reference_max_tokens: 600
      max_tokens: 4096
      reference_temperature: 0.7
      aggregator_temperature: 0.3
      enabled: true

其中最值得注意的是 reference_max_tokens。官方文件指出，MoA 每一輪都會平行執行 reference models，然後等待 aggregator 回應；每輪延遲往往和 advisors 產生多少 tokens 高度相關，因為整輪要等最慢的 advisor 完成。設定 reference_max_tokens 可以限制 advisors 的輸出長度，讓它們給出簡短建議、降低 wall time，而且不會限制 aggregator 最後給使用者看到的輸出。

我自己的實務判斷是：MoA 不該變成每個問題都開的大砲。它比較適合用在「高價值決策」或「需要多角度檢查」的節點，例如研究報告、方案比較、架構評審、PR review、顧問提案、投資研究，或重要文章發表前的反方檢查。

MoA 的價值：不是更多模型，而是更好的決策流程

MoA 最容易被誤解成「多找幾個模型投票」。但真正有價值的 MoA，不只是投票，而是設計一條決策管線。

比較理想的 MoA 應該包含四種角色：

這也呼應 2025 年的《Rethinking Mixture-of-Agents》論文。該論文指出，混合不同 LLM 不一定總是優於用單一強模型做 self-ensemble；作者提出 Self-MoA，並在多項 benchmark 中觀察到它能超越 standard MoA。這提醒我們，MoA 的品質取決於模型選擇、任務類型與整合策略，不是模型越多越好。

換句話說，MoA 的核心不是「開很多模型很熱鬧」，而是「在正確的節點引入正確的分歧」。

Hermes Agent 的架構價值

Hermes Agent 值得研究，不只是因為它支援 MoA，而是因為它把 MoA 放進一個比較完整的 agent runtime。

Hermes 官方 README 提到幾個關鍵能力：

• 可使用 Nous Portal、OpenRouter、OpenAI、自有 endpoint 等模型來源，並可用 hermes model 切換，降低模型供應商鎖定。
• 支援 Telegram、Discord、Slack、WhatsApp、Signal 與 CLI，並能維持跨平台 conversation continuity。
• 具備 agent-curated memory、periodic nudges、autonomous skill creation、skills self-improve、FTS5 session search 與 LLM summarization。
• 內建 cron scheduler，可執行 daily reports、nightly backups、weekly audits 等自然語言排程任務。
• 可 spawn isolated subagents 做 parallel workstreams，也可以寫 Python scripts 透過 RPC 呼叫工具，把多步流程壓縮成低 context 成本的操作。

這些能力加在一起，代表 Hermes 的重點不是「一次問答」，而是「常駐協作」。這也是我認為它值得持續研究的原因：

未來的 AI 能力，不只來自模型本身，而來自模型、工具、記憶、流程、權限與評估方法組成的 runtime。

和主流 AI Agent 框架比較

Hermes Agent

Hermes 的特色是「個人常駐型 runtime」。它適合做長期研究、自動化提醒、跨平台助理、個人知識管理、技能累積與多模型路由。它不是最輕量的框架，但很適合需要「長期成長」的 agent。

LangGraph

LangGraph 更像工程導向的 workflow graph。它適合明確定義狀態、節點、分支、checkpoint 與可重跑流程。如果你在企業內要做可控流程，例如核准、客服分流、合規稽核、文件審查，LangGraph 會比 Hermes 更像「流程引擎」。

CrewAI

CrewAI 的官方文件主打 collaborative AI agents、crews 與 flows，並強調 guardrails、memory、knowledge、observability 等能力。它適合快速建立角色分工明確的多代理流程，例如研究員、撰稿員、審稿員、專案經理共同完成任務。

OpenAI Agents SDK

OpenAI Agents SDK 是相對輕量的 agentic app 開發套件。官方文件把 primitive 簡化為 Agents、Agents as tools／Handoffs、Guardrails，並內建 agent loop、function tools、MCP server tool calling、sessions、human-in-the-loop、tracing 等能力。它適合已經在 OpenAI 生態內開發產品的人，尤其是需要清楚 tracing、guardrails 與 handoffs 的應用。

AutoGen

AutoGen 的定位是 building AI agents and applications。官方文件區分 Studio、AgentChat、Core、Extensions；其中 AgentChat 適合 conversational single and multi-agent applications，Core 則是 event-driven programming framework，用於 scalable multi-agent AI systems。它適合做多代理對話研究、實驗型 agent collaboration，以及需要事件驅動、多語言、分散式代理的架構。

OpenClaw

OpenClaw 代表另一條路線：以個人自主助理與 skills 生態為主。近期報導與資料顯示，它常被拿來和 Hermes Agent 一起比較，OpenClaw 偏向快速上手、技能庫與多通道整合，Hermes 則偏向 self-learning 與長期 runtime。

但 OpenClaw 也提醒我們一件事：當 agent 具備本機檔案、終端機、瀏覽器、錢包、行事曆或訊息權限時，技能生態本身就會變成供應鏈風險。已有安全研究討論 OpenClaw 這類代理的 skill poisoning、cognitive manipulation、multi-agent cascading failures 與 supply-chain vulnerabilities。

框架比較總表

把 Hermes MoA 放進真實工作流

工具介紹寫完，更重要的是它能落在什麼位置。以下是我自己最想優先落地的三個場景。

場景一：AI Agent 研究雷達

這是我最想先做起來的應用。骨架大致是：

可以讓 Hermes 每天追蹤：

• AI Agent 新框架
• MoA／multi-agent 論文
• OpenRouter 模型排行與價格變化
• Claude Code／Codex／Grok／Gemini Agent 的能力變化
• Web3 與 AI 交集的新產品
• GitHub 熱門 agent repo

MoA 不一定用在每天的所有摘要，而是用在「每週一篇正式研究文章」前的最後整理。

場景二：Web3／AI 技術顧問案源雷達

同一套骨架，換掉資料來源與目標，就能變成顧問案源雷達，而不只是找新聞。Pipeline 可以這樣拆：

1. 掃描企業公告、職缺、技術文章、融資新聞。
2. 判斷該公司是否正在導入 AI Agent、Web3、錢包、資料治理或內部自動化。
3. 產生潛在痛點。
4. 產出顧問切入角度。
5. 生成 LinkedIn 互動建議或冷啟動訊息草稿。
6. 用 MoA 檢查「這個切入點是否合理、會不會太硬、是否有商業價值」。

這種應用很貼近我自己的定位：AI Agent × Web3 × 軟體工程流程顧問。

場景三：Claude Code 與 Hermes Agent 的分工

可以把 Claude Code 當成「工程實作副駕駛」，Hermes Agent 當成「長期研究與提醒中樞」。

這樣的分工比「哪個工具最好」更成熟。真正有效的 agentic workflow，不是單一工具稱王，而是每個工具坐在對的位置上。

部署與使用建議

不要一開始就全自動

Hermes 有排程、工具、記憶、skills 與 gateway，很容易讓人一開始就想做「全自動個人助理」。但比較穩健的方式是分階段：

1. 只讀取、只整理、不執行外部動作——例如每日研究摘要、論文雷達、AI 工具新聞整理。
2. 產生草稿，但人工確認後才發出——例如 LinkedIn 文章草稿、X thread、顧問開發信、活動推薦。
3. 允許低風險自動化——例如整理資料夾、建立 markdown 筆記、更新 local knowledge base。
4. 高風險操作永遠保留人工確認——例如寄信、發文、交易、刪檔、改 production 設定、操作公司系統。

MoA 用在高價值節點

建議建立三種 MoA preset

moa:
  default_preset: research
  presets:
    research:
      reference_max_tokens: 700
      reference_temperature: 0.5
      aggregator_temperature: 0.3

    skeptic:
      reference_max_tokens: 500
      reference_temperature: 0.2
      aggregator_temperature: 0.1

    content:
      reference_max_tokens: 600
      reference_temperature: 0.8
      aggregator_temperature: 0.5

三種 preset 的用途：

• research：研究報告、技術比較、論文摘要。
• skeptic：反方檢查、風險控管、投資或顧問提案前的檢查。
• content：網站文章、LinkedIn、X thread、個人品牌內容。

值得一讀的 Agent 研究論文

以下是這篇文章背後的閱讀清單。它不只是「參考資料」，也可以當成後續研究的種子。

Mixture-of-Agents Enhances Large Language Model Capabilities

MoA 的核心論文，提出 layered MoA architecture，讓多個 LLM agents 分層產生輸出並互相參考，最後提升回答品質。

對 Hermes 的啟發：Hermes 把這個概念產品化成 model provider，而不是獨立的 orchestration framework。

Rethinking Mixture-of-Agents

這篇論文提醒我們，混合不同模型不一定永遠更好；Self-MoA 在不少情境下反而超越 standard MoA。

對 Hermes 的啟發：不要迷信「多模型混合」，要針對任務做 A/B test。

ReAct: Synergizing Reasoning and Acting in Language Models

ReAct 是 tool-using agent 的重要基礎。它把 reasoning traces 與 actions 交錯產生，讓模型能透過外部知識或環境更新自己的行動。

對 Hermes 的啟發：Hermes 的 agent loop、tool dispatch 與多輪工具結果回饋，可視為 ReAct 思想在實務系統中的延伸。

GAIA: A Benchmark for General AI Assistants

GAIA 測試的是真實助理能力，包含 reasoning、multimodality、web browsing 與 tool use。論文指出，人類得分為 92%，而帶 plugins 的 GPT-4 為 15%，顯示真實助理能力遠比單純問答困難。

對 Hermes 的啟發：Hermes 這種有工具、瀏覽、記憶與跨 session 能力的 agent，應該用接近 GAIA 的任務來評估，而不是只看聊天品質。

SWE-bench

SWE-bench 使用真實 GitHub issues 與 pull requests 評估模型修復軟體問題的能力。它要求模型理解 codebase、修改多個檔案、與執行環境互動。

對 Hermes 的啟發：要評估 Hermes 的工程能力，不能只看它會不會寫 code，而要看它能否完成可驗證、可回歸測試的修復流程。

Small Language Models are the Future of Agentic AI

這篇論文主張，很多 agentic systems 其實只需要小模型反覆執行特定任務；小模型在成本、延遲與部署上可能更適合大量的 agent 子任務。

對 Hermes 的啟發：MoA 的 reference models 不一定要全部使用最貴的模型。便宜、快速、專門化的小模型，可能更適合當 advisor。

Agentic AI: A Comprehensive Survey

這篇 survey 把 agentic systems 分成 symbolic／classical 與 neural／generative 兩條脈絡，並指出未來重點在混合式架構，而不是單一路線勝出。

對 Hermes 的啟發：Hermes 屬於 neural／generative agent runtime，但若要進入企業流程，仍需要更多 symbolic policy、permission、workflow state 與 audit trail。

AI Harness Engineering

這篇 2026 年的論文把軟體工程 agent 的能力重新定義為 model-harness-environment system，不只看模型，而是看 task specification、context selection、tool access、project memory、observability、verification、permissions、intervention recording 等 runtime substrate。

對 Hermes 的啟發：Hermes 的真正價值不只是模型回答，而是它提供了一個 harness，讓模型能觀察、行動、記憶、驗證與被人類介入。

風險與治理：Agent 越像員工，越需要管理制度

Hermes、OpenClaw、Claude Code、OpenAI Agents SDK 這類工具越強，越不能只用「聊天機器人」的心態來管理。

一個常駐型 agent 至少會帶來五種風險：

1. 權限風險：能讀檔、改檔、上網、寄信、呼叫 API。
2. 記憶風險：長期記憶可能保存過多個人或公司資訊。
3. 工具風險：MCP server、skills、plugins 可能成為攻擊面。
4. 供應鏈風險：第三方 skills 或套件可能含惡意邏輯。
5. 錯誤放大風險：多代理可能互相強化錯誤，形成看似合理的錯誤共識。

因此，比較務實的做法是按風險分級處理，用權限等級決定自動化程度：

最低治理基線：

• 只讀任務可自動化。
• 發文、寄信、改檔、刪檔、交易，必須人工確認。
• 高權限工具放進 sandbox 或 allowlist。
• 記憶系統要定期審查。
• 第三方 skills 視為不可信程式碼。
• 重要輸出保留 source map、agent logs 與人工評分。
• MoA 不等於事實查核，仍需 citation checker 與 source quality scoring。

我的結論

Hermes Agent 的價值，不在於它又多了一個聊天入口，也不在於它能同時接多少模型。它真正值得研究的地方，是它把 AI Agent 從「一次性回答工具」推向「長期運作的個人 runtime」。

MoA 則是 Hermes 中很有代表性的設計：它不是取代 agent loop，而是把多模型觀點嵌入原有的 agent loop。Reference models 提供分析，aggregator 負責輸出與工具呼叫，讓多模型協作不會摧毀原有的工具、安全與會話架構。

對個人使用者而言，Hermes ＋ MoA 最有價值的方向不是「讓 AI 全自動幫我做所有事」，而是建立幾條高品質的工作流：AI Agent 與 Web3 研究雷達、技術顧問案源偵測、Claude Code 工作流改善、研究文章生產線、LinkedIn／X 觀點內容生成與反方檢查，以及高價值決策前的多模型審稿機制。

更抽象地說，Hermes Agent 讓我們開始面對一個新問題：

未來的專業能力，不只是會不會問 AI，而是能不能設計一套讓 AI 穩定研究、判斷、行動、記憶與被治理的系統。

這正是 agentic engineering 的核心。

參考資料

• Nous Research，Hermes Agent GitHub README。
• Hermes Agent 官方文件：Mixture of Agents。
• Wang et al., 2024, Mixture-of-Agents Enhances Large Language Model Capabilities。
• Li et al., 2025, Rethinking Mixture-of-Agents: Is Mixing Different Large Language Models Beneficial?。
• Yao et al., 2022, ReAct: Synergizing Reasoning and Acting in Language Models。
• Mialon et al., 2023, GAIA: A Benchmark for General AI Assistants。
• Jimenez et al., 2023, SWE-bench: Can Language Models Resolve Real-World GitHub Issues?。
• Belcak et al., 2025, Small Language Models are the Future of Agentic AI。
• Zhong and Zhu, 2026, AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents。

Terra / Luna 不是每個人都會想到宇宙

OpenAI 最近推出 GPT-5.6 系列，命名為 Sol、Terra、Luna。

如果只從字面看，這套命名很合理。

• Sol 是太陽，代表最高階旗艦模型
• Terra 是地球，代表中階、平衡、可大規模使用
• Luna 是月亮，代表更輕量、更快速、更低成本

一套漂亮的天體階層命名。

但問題是，當 Terra 和 Luna 同時出現時，對另一群人來說，它不是天文學，而是金融災難現場。

對幣圈、Web3、FinTech 或曾經經歷 2022 Terra/LUNA 崩盤的人來說，Terra / Luna 不是優雅的產品線，而是 depeg、death spiral、資產歸零、信任崩塌的集體記憶。

這讓我想到一件事：

產品命名不是公司自己覺得好聽就好。命名本身會穿越不同社群、不同產業、不同歷史事件。

同一個名字，在 A 社群裡可能是詩意，在 B 社群裡可能是事故報告。

對一般 AI 使用者來說，Sol / Terra / Luna 可能只是新的模型階層。但對 crypto native 使用者來說，這組名字很難不讓人想起 Terra / Luna 的崩盤。

這不代表 OpenAI 是故意碰瓷。更可能是典型的產品命名盲區：

命名團隊看到的是宇宙意象。特定社群看到的是災難殘影。

這件事其實很適合拿來提醒所有做產品、品牌、技術平台的人：

當產品開始跨產業、跨社群、跨文化使用時，命名不只是 branding。它也是風險管理。

尤其 AI 產品未來會進入金融、醫療、法務、資安、政府、教育等高信任場景。名字帶來的第一印象，會直接影響使用者對產品穩定性、安全性與可信度的感受。

如果今天有一個金融保管產品叫 FTX Vault， 一個資安產品叫 SolarWinds Shield， 一個穩定幣叫 Lehman USD，

你大概會知道問題在哪。

所以 GPT-5.6 的 Sol / Terra / Luna 命名，真正值得討論的不是「這名字好不好聽」，而是：

在高度全球化、高度社群化的科技產品裡，命名是不是也該做語義風險評估？

AI 產品越來越像基礎建設。基礎建設的命名，不能只看美感，也要看歷史包袱。命名不只是 branding，命名也是語義風險管理。

Claude Code 幫我寫程式，Hermes Agent 幫我脫單

每天都在用 Claude Code 弄文件或寫程式。它已經是我工作流程的一部分：我下指令、它執行，只要我在鍵盤前，它就很強。

最近開始玩 Hermes Agent（Nous Research 的自主 AI Agent），除了花了一些時間調教她讓她叫我主人，研究串 OpenRouter 上到底哪個 LLM 的 CP 值最高，有一個問題一直在我腦中盤旋：

這種會自己跑排程、不需要我在場的 Agent，到底適合拿來做什麼？

它和 Claude Code 的形態明顯不同：Claude Code 是我發動的，session 結束就停；Hermes Agent 是排程自主型，我不在，它照跑，還會主動把結果推給我。工具的形態不一樣，適合的問題應該也不一樣——但那個問題，長什麼樣子？

剛過完 43 歲生日，答案自己出現了：脫單。

如果我想脫單，這件事不能再只靠緣分、心情，或某天突然被宇宙推進社交場合。而它剛好符合自主 Agent 的所有特徵：需要每天重複做、不需要我盯著、資訊會過期、最大的敵人是拖延。

於是我設了一個每日排程任務：讓 Hermes Agent 每天自動上網撈雙北的社交活動，比對我的條件、排出優先順序，寫成一封信寄到我的信箱。

表面上看，這只是活動推薦。但我真正想驗證的是：

AI Agent 能不能幫我把一個模糊的人生目標，拆成每天可以推進的行動？

「想脫單」不是一個可以直接執行的任務，何況這件事對我這 INTJ 人來說難度特別高。要去哪裡認識人？什麼活動適合我的年齡和狀態？今天的第一步是什麼？這些問題每次都從零開始想，最後很容易變成：想了很多，但沒有出門。

所以我把它設計成四層 workflow，每天這封信，就是這條 pipeline 的輸出。

第一層：資料蒐集。 從活動平台取得完整候選資料：時間、地點、類型、報名連結、年齡限制。這一層是基本功。

第二層：個人化篩選。 信的第一句話是：「早安主人，我用 Swanky 今天 43 歲，幫你篩掉男生上限 40 的局。」它拿我的硬性條件逐一比對報名限制，符合的標「可參加」，資訊不足的標「年齡需確認」——先過濾、再呈現、不確定就標註，而不是裝懂。

第三層：決策輔助。 條件符合，不代表值得去。每個活動都附「為什麼適合我」和「注意事項」：共煮活動是「流程比尬聊自然，能用分工和生活習慣觀察人」；讀書會是「現場少講方法論，多問對方故事」。推薦附理由、理由附風險。

第四層：行動引導。 真實世界的瓶頸，通常不是資訊不足，而是行動摩擦太高。所以信的結尾是「今日最小行動」——今天只要做一件事：確認某場活動的最後名額還在不在。再加上「本週行動節奏」：報名 1–2 場、出席 1 場、現場跟 3 個人自然聊天、加 1 個聯絡方式。

它甚至每天附一段社交提醒，我第一次看到就笑出來：

「先顧感受，再給建議；不要把約會變成 code review，對方沒問就先不要修正她的人生。」

一個 AI 每天提醒工程師不要對人類 debug——光憑這點，這個排程就值得一直跑下去。

回到最初的問題：自主 Agent 到底適合做什麼？

這次實驗給我的答案是：Claude Code 這類互動式 Agent，適合「我在場、需要即時協作」的任務；Hermes Agent 這類排程自主型 Agent，適合的是「重複發生、不需要我在場、但需要被持續推進」的目標。

它的價值不只是 automation，而是 decision pipeline——在正確的時間，把篩選、排序、解釋過的資訊，轉換成我可以採取的下一步。同樣的骨架，換掉資料來源和目標，就是找商機、盤點職涯機會、追蹤學習資源。

43 歲之後，我對 AI 的期待變得很務實：不是要它替我過人生，而是在我想改變某件事的時候，每天幫我把那一步，往前推一點。

最後，認真說

Hermes Agent 給我的本週行動節奏裡，有一條是「跟 3 個人自然聊天，加 1 個聯絡方式」。

所以，這篇文章也算是我之後每周的行動之一。

我是真的想擴大自己的社交生活圈。如果你看完這篇，想聊聊 Web3、AI、攝影，想介紹朋友給我認識，或單純想交個朋友——歡迎私訊約我喝咖啡。☕

今天，立法院三讀通過《虛擬資產服務法》。我不會把這件事簡單看成「幣圈合法化」。更準確地說，這是台灣第一次把虛擬資產服務正式拉進金融監理架構。VASP 從過去偏向洗錢防制登記的管理方式，往金管會許可制前進，也就是從「可以登記」走向「必須取得牌照」。

這件事對產業的影響，不只在法條本身。真正會被改寫的，是交易所之間的競爭方式。

過去交易所比的是什麼？上幣速度、活動補貼、手續費、流動性、合約深度、產品夠不夠刺激。這些東西以後還是重要，但不會是全部。專法上路後，另一組關鍵字會變得越來越重要：

許可、資產隔離、內控、資安、資訊揭露、穩定幣合規、異常交易監控。

這聽起來比較無聊。但金融市場裡，很多真正重要的東西，本來就很無聊。錢放在哪裡、誰能動用、出了事誰負責、帳怎麼查、資產有沒有隔離、系統掛掉怎麼辦、平台有沒有能力偵測異常交易。這些不是行銷文案裡最性感的部分，卻是使用者最後會在乎的部分。

這次專法把方向講得很清楚。VASP 未來必須依業務類型取得許可，包括交換、交易平台、移轉、保管、承銷、借貸等服務。業者也要建立內控稽核、資通安全、營運持續等制度。

穩定幣的規範更是高標準。發行前要經金管會許可，並會商中央銀行同意。發行人要維持十足準備資產，存放在境內金融機構，與自有財產分離，並信託保管。穩定幣也不得支付任何形式的利息或收益。

罰則也拉得很重。涉及詐欺或操縱市場，最重可處 10 年有期徒刑，併科 2 億元罰金。

對國內交易所來說，短期一定是壓力。合規成本會上升。資本、法遵、會計查核、客戶資產保管、幣種上下架審查、異常交易監控，全部都會變成真成本。以前可以靠速度和流量解決的問題，以後不一定過得去。灰色地帶的玩法，會越來越難走。

但反過來看，這也是本土合規交易所少見的機會。因為當監理從登記制走向許可制，牌照本身就會變成信任門檻。

如果國內交易所能把台幣出入金、客戶資產隔離、企業帳戶、穩定幣交易、RWA 應用，以及金融機構合作串起來，它們就不只是「買幣的地方」。它們有機會變成台灣進入數位金融世界的主要入口。

這對海外大型交易所也會產生影響。Binance、OKX、Bybit、Coinbase、Kraken 這類全球平台，過去靠的是流動性、產品完整度和國際品牌。但在台灣市場，未來要面對的問題會變成：

• 要不要正式落地？
• 要不要申請許可？
• 能不能公開行銷？
• 能不能接台幣金流？
• 能不能跟台灣金融機構和企業合作？

我不認為海外交易所會因為這部法就突然消失。這不太現實。全球流動性、衍生性商品、多元幣種，仍然是海外平台很強的地方。使用者也不會因為一部法律，就停止追求更深的市場和更多產品。

但它們在台灣的角色，可能會重新分層。國內合規交易所，會更像台幣入口與合規資產通道。海外交易所，仍然保有全球流動性與多元產品優勢。DeFi，則繼續承接更高自由度、也更高風險的鏈上需求。

也就是說，台灣未來的虛擬資產市場，可能不是單一路線，而是三層結構：

• 合規入口在國內。
• 深度交易在海外。
• 創新實驗在鏈上。

這部法真正有意思的地方，不只是監管交易所。而是台灣開始回答一個更大的問題：當資產、支付、身分、憑證、債券、基金、不動產、應收帳款、碳權，都有機會被數位化與代幣化時，我們要用什麼制度，讓它們安全地接上金融體系？

這才是 RWA、穩定幣、鏈上金融真正會碰到的核心問題。不是「可不可以發幣」。而是「發出來之後，能不能被信任」。

所以我會把《虛擬資產服務法》視為起點，而不是終點。它通過，不代表 RWA、穩定幣、鏈上金融明天就起飛。接下來真正關鍵的是子法。

金管會預計最快在 2027 年第一季完成 9 項子法，讓專法正式上路。牌照門檻、資本額、資安標準、穩定幣準備資產、境外平台管理、幣種上下架規則，以及金融機構如何參與，都會在這個階段變得更具體。

另外，立法院也通過附帶決議，要求金管會一年內提出開放虛擬資產衍生性商品的規劃。這會是另一個需要觀察的變數。

未來幾年，交易所的競爭不會只看誰的 App 好用、誰的幣多、誰的活動大。而會看誰能同時做好三件事：

• 第一，接得上監理。
• 第二，守得住資產。
• 第三，連得上真實經濟。

虛擬資產產業不是被按下停止鍵。它只是開始被要求蓋地基。

而地基這種東西，平常沒人想看。但最後，會決定一棟樓能蓋多高。

最近讀到一份難得的例外。

Simon Willison 把他這一兩年用 coding agent 開發的實戰，整理成一份叫做 《Agentic Engineering Patterns》 的指南。如果你不認識他——他是 Django 框架的共同作者、開源工具 Datasette 的作者，也是這幾年寫 LLM 實務寫得最勤、最務實的人之一。

這份指南刻意不寫「某個工具怎麼操作」，而是去萃取那些能被實際驗證有效、又不太會因為工具進步就過時的原則。它分成六大主題、十幾篇文章，而且他明講這是一份「持續進行中」的活文件，沒有任何一章算完稿。

我把全文從頭到尾讀完，這篇是我的導讀。我會挑出我認為台灣技術團隊最該吸收的幾個重點，配上我自己在公司帶 Claude Code 導入時的對照。文末有原文連結，我強烈建議你直接去讀原文——以下是我的整理與觀點，引用到 Simon 的句子我都會標出來。

先把詞講清楚：agentic engineering 不是 vibe coding

Simon 對「代理式工程（agentic engineering）」的定義很樸素：借助程式代理（coding agent）來開發軟體。而他對「代理（agent）」的定義更精煉：

“Agents run tools in a loop to achieve a goal.” —— Simon Willison

代理，就是「在一個迴圈裡反覆呼叫工具、以達成某個目標」的東西。對程式代理來說，這組工具裡最關鍵的一個，就是能夠執行程式碼。他甚至把這件事提到決定性的高度——少了執行能力，大型語言模型（LLM）吐出來的內容價值有限；一旦能執行、能反覆驗證，單純的文字生成才被提升成了工程。

接著他做了一件我很認同的事：把 agentic engineering 跟 vibe coding 清楚分開。

vibe coding（憑感覺寫程式）這個詞是 Andrej Karpathy 提出的，原意很特定——你對 AI 下提示詞、把它生出來的東西直接接受，甚至不去管它對不對。很多人後來把這個詞擴大成「只要用 AI 產程式碼」都算，但 Simon 明確反對：

“Some people extend that definition to cover any time an LLM is used to produce code at all, but I think that’s a mistake.” —— Simon Willison

他主張的分界線是：vibe coding 指的是未經審查、原型品質的產出；而代理式工程，是要把程式碼提升到上線品質、由作者親自把關過的。差別不在用不用 AI，而在有沒有人審查、有沒有達到可交付的標準。

這跟我一直在講的兩件事完全是同一回事——把 AI 當成「需要被好好帶領的高級實習生」，以及越懂工程的人越能把 AI 用出價值。工具把打字變便宜了，但「判斷該寫什麼、把關品質」這件事，依然牢牢握在人手上。

整份指南最該被框起來的一句：好程式仍有成本

如果這份指南只能記一句話，我會選這句的概念：

“Delivering new code has dropped in price to almost free … but delivering good code remains significantly more expensive than that.” —— Simon Willison

交付「會動的程式碼」已經幾乎免費；但交付「好程式」，依然很貴。 這兩件事不是同一回事。

而且 Simon 不是含糊喊口號，他把「好程式」攤開成一張很具體的清單：功能正確、解對問題、錯誤處理得宜、夠簡潔、有測試覆蓋、文件最新、設計可維護，還有一整排非功能性需求——可及性、安全性、可測試性、可靠性、可觀測性、可擴展性。

工具能幫你做掉上面很多項，但他畫了一條關鍵的責任線：工具能分攤勞動，卻不能轉移責任。 最終產出是不是「好程式」，仍由握方向盤的人負責。

這一點，我認為台灣團隊要特別警惕。我們很多團隊本來就背著沉重的技術債，最危險的就是把「寫程式變便宜了」誤讀成「可以免洗」——省掉測試、跳過文件、忽略可及性與安全性。正確的方向剛好相反：當 AI 把產出加速了，你反而更有餘裕、也更該嚴格地守住這些非功能性需求。

指南裡還有一個我很喜歡的習慣轉變。過去因為寫程式很貴，遇到沒把握的邊際點子，理性的反應是「別做，不值得花時間」。但現在 token 很便宜、真正稀缺的是人的注意力——所以該把「先否決」的本能，換成「先丟一個 prompt 去非同步跑跑看」。最壞不過是十分鐘後回來看一眼，發現果然不值得。守門的直覺，該被便宜的實驗取代。

想把 AI 用好，先懂它怎麼運作

很多人用 coding agent 像在用黑盒子。Simon 花了一整章拆解它的內部：說到底，就是 LLM ＋ 系統提示（system prompt）＋ 一組工具，在一個迴圈裡反覆對話；他也解釋了 token 快取為什麼重要。

為什麼工程師該懂這層？因為它直接決定你的操作習慣——你會更知道怎麼寫 prompt、怎麼管理 context、為什麼不該在一個 session 裡反覆橫跳把快取打壞。理解原理的人，才不會把 AI 當神諭亂拜。

這一段裡我覺得最實用的是子代理（subagents）：用像 Claude Code 的 Explore 子代理去讀檔、探索，把摘要帶回來，讓主對話的 context 保持乾淨；需要時開平行子代理同時跑多個任務；甚至建立固定用途的專家子代理。這跟我之前整理 Claude Code 實戰技巧 時談到的平行工作流、用子代理保持主脈絡乾淨，是完全一致的方向。

測試與 QA：把「自我驗證」變成預設

整份指南有三章都在談測試，這個比重本身就是一種主張。它們講紅燈／綠燈 TDD、講「先把測試跑起來」、講代理式手動測試——讓代理用瀏覽器自動化自己去點、自己驗 UI、自己截圖記錄過程。

三章其實指向同一件事：給 AI 一個能自己判斷對錯的迴路，而不是讓它做一步就把半成品丟回來叫你看。

這正是我反覆強調的「工作閉環」。我帶團隊時最常修正同仁的一個地方，就是不要接受 AI 說「請你打開檔案確認一下」——那只是把工作切碎丟回給你。成熟的用法是要求它形成完整迴路：

理解任務 → 執行任務 → 自我檢查 → 修正問題 → 交付可驗收成果。

落到操作上很簡單：把「跑測試，若失敗就修到通過再結束」直接寫進你的交辦 prompt。一句話，成果品質就明顯不同。

理解陌生程式碼的新玩法

這部分對接手舊系統、帶新人的人特別有感。Simon 介紹了用 AI 做線性逐步導覽與互動式解說——讓 AI 針對一段陌生的程式碼或一份資料，產生一份一次性的、甚至可互動的解說（有時就是一個小工具），幫你快速建立理解。

我自己的對照是：把 AI 當「程式碼導覽員」，是新人上手與接手 legacy 專案時最低風險、最高報酬的用法之一。先不要叫它改大功能，先請它帶你讀懂這塊地形。

附錄才是隱藏寶藏：把提示詞當資產，和一條紅線

很多人會跳過附錄，但這份指南的附錄我認為價值最高。Simon 把自己日常在用的幾個 prompt 直接公開——校稿、寫圖片替代文字（alt text）、從 podcast 逐字稿挑金句、用 Claude 做可攜的小工具。

它們有一個共同的設計哲學：幾乎都被沉澱成 Claude 專案的自訂指令，而不是每次重打。換句話說，他把「重複使用的意圖」固定成一段系統提示，之後只要把素材丟進去，就能得到穩定一致的輸出。這呼應了指南另一個核心概念——把你會做、好用的東西「囤積」起來、重組，變成可重複呼叫的資產。好的 prompt 不該是一次性的靈感，而該是版本控管得起來的團隊資產。

附錄裡還有一條紅線，我非常認同。Simon 會用 LLM 校稿、更新文件，但他立了一條界線：

“My hard line is that anything that expresses opinions or uses ‘I’ pronouns needs to have been written by me.” —— Simon Willison

凡是表達觀點、會掛上他名字、用到「我」的內容，都必須他本人親手寫。

我會把這條延伸成一個給團隊的建議：每個團隊都該有一份簡單的 AI 使用守則，講清楚哪些工作可以交給機器（格式整理、挑錯、寫草稿、篩選資料），哪些必須由人親手把關（觀點、判斷、對外掛名的內容）。 把這條線講清楚，不會限制效率，反而會建立讀者與客戶對你的信任。

結語：在喧囂裡，它給的是不會過時的原則

我讀完最大的感受是：這份指南真正珍貴的，不是任何一個單一技巧，而是它刻意只萃取原則。工具每幾個月就換一輪，但「好程式仍有成本」「給 AI 自我驗證的迴路」「把提示詞變資產」「掛名的內容自己寫」這些，會跟著你很久。它還是一份會持續更新的活文件——這本身就是面對這個領域該有的態度：與其追逐技巧，不如沉澱原則。

如果你讀完只想先做三件事，我的建議是：

1. 把「跑測試／自我驗證並修到通過再結束」寫進你每一個交辦 prompt。 這是投報率最高的一句。
2. 挑一個你每週都會重複的工作，把那段 prompt 沉澱成固定的自訂指令或 skill。 讓它變成資產，而不是每次重想。
3. 跟團隊講清楚一條紅線：哪些內容一定要由人親手寫。 先建立信任，再談效率。

這份指南值得你親自讀一遍：Simon Willison《Agentic Engineering Patterns》原文。

如果你想把這套「用工程紀律駕馭 AI」的方法帶進自己的團隊，我也把帶團隊的完整經驗整理成了 Agentic Engineering 系列文章，並濃縮成一門 Claude Code 內訓課程（課綱完整公開）；需要導入顧問的話，也歡迎來 信聊聊。

最後想問問你：讀完這份指南，你最想先在自己團隊落地哪一條？

一小時做出來的玩具，十萬工程師在用：peon-ping 與 AI 時代的注意力管理

最近的 AI 協作日常長這樣：同時開好幾個 Claude Code session 在背景跑——一個在改 API、一個在補測試、一個在跑 E2E 驗證。

然後問題來了。

Agent 跑完了、卡在權限確認、或是出錯停住，terminal 並不會主動告訴你。你切去回個訊息或信件，回來才發現它十分鐘前就在等你按 yes。Agent 的時間不值錢，貴的是你每一次 context switch 燒掉的專注力。

有趣的是，這個問題 RTS 遊戲在 25 年前就解掉了。

星海爭霸怎麼讓一個玩家同時管理多條戰線？靠聲音。警報一響，你不用盯著小地圖，就知道該把鏡頭切去哪裡。聲音，本來就是平行任務管理的原生介面。

peon-ping 這個開源專案做的就是這件事：把 RTS 的音效設計，搬進 agentic coding 的工作流。

它的玩法：

→ Session 啟動、任務完成、需要權限、執行出錯、撞到 rate limit，各自觸發不同的遊戲角色語音，搭配螢幕橫幅通知

→ 收錄超過百款遊戲與影視作品的音效包：魔獸爭霸苦工（Peon）、星海爭霸、Portal 的 GLaDOS 都有，也能自己擴充

→ 不同專案目錄可以綁定不同角色——閉著眼睛，聽聲音就知道是哪個專案在叫你

→ 平行 subagent 太吵？一個設定就能只保留主 session 的完成音

→ 開會自動靜音：偵測到麥克風使用中，音效自動暫停

→ 彩蛋：短時間內狂催 prompt，苦工會不耐煩地嗆你 “Me busy, leave me alone!”

不只 Claude Code，Codex、Cursor、Gemini CLI 等十多種工具都支援，背後是 CESP 這個開放的音效事件標準。

這個工具的出身也很有意思。PCMag 最近報導了它背後的故事：最初版本是 Tony Sheng 花一個小時做出來丟上 GitHub 的，他自嘲這大概是自己發布過最蠢的東西——但每個用過的人都說意外好用。後來交棒給前 Google 工程師的弟弟 Gary 經營，登上 Hacker News、被整合進 VS Code 之後，如今已有約十萬名開發者在用。

一個一小時做出來的玩具，能長到十萬人在用，通常代表它打中的痛點是真的。

Gary 受訪時還講了一個我特別有感的點：大家花了不少錢買 AI 算力，但當 terminal 閒置在那邊等你回來，你已經付費的運算額度就是在空轉。

換句話說，注意力管理不只是專注力問題，它直接是成本問題。每一個被你晾在背景的 session，都在燒你刷下去的訂閱費。

我自己掛的是 sc_kerrigan 音效包——星海爭霸的凱莉根。任務跑完，刀鋒女王淡淡丟下一句 “I read you”。寫程式寫到一半被女王點名，荒謬又療癒，而且真的有效：等權限的 session，再也不會被我晾在背景十分鐘。

我之前談 SDD 時寫過：AI 時代的開發瓶頸，已經從「寫程式」移到「規格與判斷」。而開始多 session 平行開發之後，我看到第三個瓶頸正在浮現——注意力。

當開發模式從「人寫程式」變成「人調度多個 agent」，工程師會越來越像 RTS 玩家：拚的不是 APM，而是能不能在對的時間，把注意力切到對的戰線上。

不久之前，還沒有人覺得 Claude Code 需要音效；現在，「AI 跑完要通知我」正在變成理所當然。通知不是 nice-to-have，它是多工調度的基礎建設。

安裝一行搞定（macOS / Linux / WSL2 / Windows 都支援）：brew install PeonPing/tap/peon-ping

GitHub：https://github.com/PeonPing/peon-ping

PCMag 報導：https://tech.yahoo.com/ai/claude/articles/inside-peon-ping-warcraft-iii-133000994.html

你的 Claude Code，現在是哪個角色在幫你盯？歡迎留言分享你的音效包。

我認為這個概念，對正在導入 AI coding 的技術團隊特別重要。這篇先幫還沒跟上的朋友補一段歷史脈絡，再談我會怎麼把它跟 Spec-Driven Development 整合落地。

前情提要：AI 輔助開發的重點，一直在變

2022 年底，Prompt Engineering。 ChatGPT 問世，大家比的是怎麼把需求問清楚、指令寫精準。一句神 prompt 可以省你兩小時，但 AI 看不到你的程式碼，也看不到執行結果。

2024 年，Context Engineering。 大家發現只會下 prompt 還不夠——AI 需要知道專案背景、架構限制、coding style、測試規範。RAG、rules 檔、CLAUDE.md 開始變成標配。

2025 年，代理式開發。 Claude Code、Cursor 這類 coding agent 不再只是回答問題，而是能讀 repo、改檔案、跑測試、看錯誤訊息、再修正。同年 vibe coding 一詞爆紅，也催生了反作用力——Spec-Driven Development 這類強調工程紀律的方法開始抬頭。

2026 年，Loop Engineering。 Osmani 的定義很精準：不再由人一直提示 agent，而是設計一個會提示 agent 的系統，讓它依照目標反覆迭代到完成。

兩種模式的差別

過去的模式是：

人下指令 → AI 回答 → 人檢查 → 人再下指令 → AI 再修改

Loop Engineering 的模式則是：

讀取任務 → 對齊規格 → 拆解工作 → agent 實作 → 執行測試 → 驗證結果 → 記錄狀態 → 決定下一步

人不再站在旁邊一直餵 prompt，而是把「需求、規格、測試、驗證、回饋、記憶」設計成一條可重複運作的產線。AI 是工人，Loop 是產線，工程師還是廠長——不是吉祥物。

真正的瓶頸，已經不是「AI 會不會寫 code」

而是團隊有沒有能力定義清楚：

什麼是正確需求？ 什麼是完成條件？ 什麼是可接受的測試？ 什麼風險不能自動化放行？ 什麼知識要沉澱成團隊規範？

以 Claude Code 來說，這些已經可以落地：

• CLAUDE.md 放專案規範與架構原則
• Skills 封裝重複流程，例如「根據 OpenSpec 做 TDD」
• Subagents 拆分角色：規格審查、實作、測試驗證、安全審查
• Hooks 強制執行 lint、格式化、敏感檔案保護
• /goal 定義完成條件，讓 agent 持續做到條件成立
• /loop 定期巡檢 PR、CI、review comments
• GitHub Actions 把 AI review 放進既有開發流程

跟 SDD 是天作之合

如果團隊已經用 Example Mapping 釐清需求、用 OpenSpec 沉澱規格、再搭配 TDD，整條路其實就是一個 Spec-driven Loop：

Example Mapping → OpenSpec → 產生測試 → 實作 → CI 驗證 → 獨立驗證 → PR → 經驗回寫團隊規範

關鍵的指令差異：

❌「幫我做這個功能」

✅「根據 OpenSpec 的 acceptance criteria，先產生測試並確認先失敗，再實作到通過，最後由獨立的 verifier agent 檢查是否符合規格。」

還有一個容易被忽略的原則：maker 與 checker 必須分離。寫 code 的 agent 不該同時是唯一的評分者，因為它很容易替自己的答案找理由——這一點，跟人類工程師意外地像。

但 Loop 不是自動駕駛，它反而更要求紀律

acceptance criteria 模糊 → AI 只會自動化地誤解需求 測試品質不好 → AI 只會自動化地通過爛測試 權限開太大 → AI 只會自動化地放大風險 沒有 review 機制 → AI 只會自動化地累積技術債

所以我把 Loop Engineering 理解成：

不是用 AI 取代工程師，而是把工程師的判斷、規範、測試與審查能力，變成可以反覆運作的系統。

未來技術團隊的差異，可能不只在於誰比較會用 AI，而在於誰能把 AI 放進一條可驗證、可追蹤、可治理的開發迴圈裡。

Prompt 讓 AI 回答。 Context 讓 AI 理解。 Test 讓 AI 被檢查。 Loop 讓整個工程流程開始轉動。

這或許就是 AI coding 從個人生產力工具，走向團隊工程能力的關鍵一步。

你的團隊現在走到哪一階？歡迎留言聊聊。

AI 讓開發變快，但決定團隊走多遠的，是「可被信任的速度」

最近讀了 Anthropic Institute 的〈When AI builds itself〉。文章談的是一個值得每個技術團隊認真看待的趨勢：AI 已經開始加速 AI 自身的研發，而軟體開發的工作型態，也正在被重新改寫。

幾個數字很有份量。Anthropic 提到，截至 2026 年 5 月，合併進其程式庫的程式碼有超過八成由 Claude 撰寫；2026 年第二季，典型工程師每天 merge 的程式碼量，約為 2024 年的 8 倍。值得一提的是，他們也誠實標註了限制——用程式碼行數衡量生產力本就會高估實質貢獻，工程師的自評也容易偏高，而這些曲線未必是指數，也可能是會趨緩的 S 曲線。

但即使保守地讀，我認為真正的重點都不是「AI 能寫多少 code」，而是軟體開發的瓶頸，正在移動。

過去我們衡量工程能力，問的多半是「誰比較會寫 code、誰比較熟 framework、誰能把功能做出來」。但當 AI 已經能快速產生程式碼、修改檔案、執行測試、分析錯誤，甚至獨立完成數小時的工程任務，團隊真正稀缺的能力會逐漸轉移到上游：誰能定義出正確的問題、寫出清楚的規格、設計可驗證的測試，以及判斷 AI 的產出是否真的可靠。

Anthropic 在文中點出一個很關鍵的觀察：當 AI 大量產生程式碼，human code review 反而會變成新的瓶頸。這在計算機架構裡叫 Amdahl’s law——你把某一段流程加速到極致，瓶頸不會消失，只會搬家。它套在組織上同樣成立，也正好呼應我在實務上看到的現象：AI 讓「產出」變便宜，卻讓「判斷」變昂貴。

最近我帶團隊把這套邏輯落實成一條開發主線：從 Example Mapping 釐清需求與邊界規則，到 OpenSpec 定義行為與驗收條件，再交給 Claude Code 依測試逐步實作，最後經過 code review、CI 與資安檢查把關。過程中我體會最深的一點是：真正決定 AI 產出品質的，往往不是模型本身，而是上游的規格夠不夠清楚。舉個例子，光是一個鏈上轉帳功能，我們在動手寫任何程式碼之前，就先拆出了三十幾張 Example Mapping，把正常與異常情境、各種邊界條件一一攤開。當規格與範例夠扎實，AI 幾乎能穩定跑在正確的軌道上；而那些卡關的地方，事後回頭看，幾乎都是「規格的缺口」，而不是「程式的 bug」。

不過，把這套方法真正導入一整個團隊，又是另一回事。我認為，這本質上是一個「結構問題」，而不是「工具問題」——把工具與方法準備好，只是起點，並不代表它們就會被用起來。要讓一套新的開發方式在團隊裡真正生根，通常需要四件事同時到位：一是對「為什麼」的認同，人若不打從心裡認同規格、測試與設計的價值，再好的工具也只會閒置；二是一個跑得起來的回饋迴圈，環境、資料庫與測試要能在手邊實際運作，TDD 才有「紅轉綠」的回饋，環境一旦卡住，整套方法就無從啟動；三是時間與動機，當「學新方法」被擺成「趕進度」的對立面，學習永遠會墊底；四是管理層的明確支持，讓它成為團隊的共同方針，而不是「某個人的提議」。這四件事缺一不可，而工具往往只是其中最容易給、也最常被誤以為是全部的那一塊。

有意思的是，這些其實都不是新觀念。Kent Beck 談測試、Eric Evans 談領域裡的共通語言、Ousterhout 談模組設計，講的都是同一件事：把複雜度管理好。AI 並沒有讓這些基本功過時，反而把「忽略它們的代價」放大了——而且來得更快、更明顯。

所以我越來越相信，技術團隊接下來真正該投資的，不只是 AI 工具本身，而是兩層能力：一層是「AI 時代的工程治理」——需求規格化、測試先行、agent workflow、code review 自動化、資安檢查、可觀測性、rollback 與知識沉澱；另一層，是讓這些能力能在團隊裡真正長出來的「組織條件」——時間、動機、共識，以及管理層的承諾。前者決定 AI 能不能跑在正確的軌道上，後者決定團隊能不能真的跟上。

如果說過去的軟體開發像手工雕刻，工程師一刀一刀把系統刻出來；那未來的開發，更像在經營一座高度自動化的工廠。機器可以很快，但設計圖、品管線、煞車系統與安全閘門，仍然得由人來負責。

文章後半談得更遠——一旦 AI 真的能遞迴式地打造自己的下一代，控制、對齊與全球協調都會成為更核心的課題。那是更長期的問題，但它提醒我們：速度從來不是終點。

AI 會讓開發變快；但真正決定一個團隊能走多遠的，是我們能不能把「快」，變成「可被信任的快」。

也想聽聽你的經驗：在你的組織裡，擋在 AI 開發導入前面的，究竟是工具本身，還是那些工具以外的條件？

Web3 的人都在學 AI，AI 的人卻不學 Web3——這條單行道，撐不過 Agent 經濟。

我認識的 Web3 朋友，幾乎全部都在學 AI。但我認識的 AI 研究者，沒幾個在學 Web3。

人才只往一個方向流動。而單向的人流，從來都是最誠實的訊號。

先把話說清楚：這不是 AI 圈看不起 Web3，也不是 Web3 沒價值。這背後其實是兩種技術「回報曲線」的差別。

AI 是工具層的革命。你不需要先相信一套新的經濟制度，不需要先搞懂錢包、私鑰、Gas、治理代幣、MEV 或監管風險。你今天打開 Claude Code、Codex，明天就寫得更快、查得更快、整理得更快。

這種「立即可見的生產力」，數字會說話。Stack Overflow 2025 開發者調查裡，84% 的受訪者已在使用或打算使用 AI 工具，專業開發者更有超過半數每天都在用。學界這邊，一份分析了近 13 萬個 GitHub 專案的研究發現，Claude Code、Cursor、Codex 這類 coding agent 的採用率已經來到 15.85% 到 22.60%——對一個才問世幾個月的技術，這個速度驚人，而且還在往上爬。

對 Web3 人來說，AI 幾乎是零成本的升級。寫智能合約、跑測試、整理研究、拆商業邏輯，突然多了一個副駕駛。學它，不需要改變任何信仰。

但反過來，Web3 對一個 AI 研究者「升級」了什麼？

它不會讓你的模型更準，不會讓訓練更便宜，不會讓推論更快，也不會讓你的論文更容易被接受。

因為 Web3 是制度層的革命。它的價值，要等到「信任、所有權、治理、資產流動」真正成為問題的那一刻，才會浮現。

工具層的革命人人都採用，因為它直接改善你今天的工作流程。制度層的革命走得慢，因為它要等場景、信任、利益分配、合規一起成熟，價值才看得見。

Web3 不是沒在前進。a16z 的 State of Crypto 2025 報告就指出，過去一年穩定幣的交易量達到 46 兆美元，扣掉雜訊後仍有 9 兆——逼近 Visa，直追整個美國銀行體系的清算網路。但對 AI 圈來說，這比較像「隔壁產業的基礎建設成熟了」，而不是「我今天非學不可」。

所以我要說的重點來了：

這條單行道，是暫時的。

因為真正會把 AI 和 Web3 接起來的，從來不是信仰，是必要性。而那個必要性，已經在發生了。

當 AI Agent 開始「自己付錢」的那一刻，故事就變了。一個 Agent 呼叫一次 API、買一份資料、付一次運算，金額是幾分錢。這種高頻、極小額、機器對機器的支付，傳統信用卡軌道做不來——光是手續費，就把它整個壓垮。

於是市場已經給出答案。Coinbase 和 Cloudflare 推的 x402 協議，讓 Agent 能用穩定幣在一次 HTTP 請求裡完成付款；Google 的 AP2 也明確支援穩定幣，一口氣拉進了 PayPal、Mastercard、American Express 等六十多家機構。根據 Keyrock《Who Pays the Agent?》報告，光是 AI Agent 之間，已經透過穩定幣結算了約 7,300 萬美元、1.76 億筆交易——其中超過七成的金額，低於信用卡手續費的下限。

換句話說，機器對機器的經濟正在被蓋起來，而它選的軌道，是加密軌道。不是因為意識形態，是因為別的東西做不到。

而這只是開始。當 Agent 開始替人管資產、簽交易、參與治理、產生商業決策，接踵而來的全是 Web3 最擅長回答的問題：

• 誰來驗證這個 Agent 做過什麼？
• 誰來界定它的權限邊界？
• 誰來保存一份不可竄改的行為紀錄？
• 人、AI、組織、資產之間，要用什麼新制度來協調彼此的信任？

到那一天，Web3 才不是「另一個投機市場」，而是 AI 時代的信任基礎設施。

所以，如果你也是 Web3 人，我的建議很直接：別只當 AI 的使用者。

去想清楚一件事——當 AI 把生產力推到極致之後，社會會冒出多少新的信任、所有權、責任歸屬、自動化治理問題？那些問題，正是你的主場。

淘金熱裡，最穩賺的從來不是淘金的人，是賣鏟子的人。與其追著 AI 的熱度跑，不如現在就把鏟子，擺在它的必經之路上。

AI 解決的是生產力問題，Web3 解決的是信任與協調問題。現在 AI 圈不學 Web3，不是因為它不重要，是因為時候還沒到。等 AI Agent 真正走進經濟活動的那一天，這條單行道會反轉。

而到時候吃到紅利的，是現在就站在路口的人。

當這兩者相遇，就誕生了一個熱門賽道：去中心化算力網路（DCN, Decentralized Compute Network）。這是我「Web3 入門精選」系列裡，關於「未來」的一篇。

一、先看 AI 這股海嘯有多大

要理解這個交集，先感受一下 AI 投資的狂熱程度。幾個數字（來自產業研究）很能說明問題：

• 自 2022 年底 ChatGPT 發布以來，AI 相關股票漲幅達 165%，而同期非 AI 股票僅漲 24%。
• 2025 年前三季的 AI 投資，比 2024 年全年總額還高出 62%。
• 2025 年第三季，AI 領域吸走了美國創投資金的 63%。

換句話說，AI 不只是技術趨勢，更是當前資本市場最大的吸金黑洞。而所有 AI 的背後，都站著同一個需求——算力（compute），具體說就是 GPU。

二、痛點：算力又貴又集中

AI 的算力供給，目前高度集中在少數幾家雲端巨頭（AWS、Google Cloud、Azure）與晶片廠（Nvidia）手裡。這帶來幾個問題：

• 貴：頂級 GPU 一卡難求，租用成本高昂，中小團隊與獨立開發者常常被價格擋在門外。
• 不透明：你租了雲端算力，但定價邏輯、資源分配對你來說是個黑箱。
• 集中風險：算力這種「AI 時代的石油」，掌握在極少數公司手裡，本身就是一種系統性風險。

與此同時，世界上其實散落著大量閒置的 GPU——遊戲玩家的顯卡、小型資料中心的餘裕產能、甚至前幾年挖礦留下的設備。問題是：沒有一個好機制，能把這些分散的算力協調起來、媒合給需要的人。

這個「協調陌生人貢獻資源」的難題，你是不是覺得有點眼熟？沒錯，這正是 DePIN 擅長的事——而 DCN，本質上就是 DePIN 在「運算」這個類別裡的應用。

三、解法：用代幣激勵，把算力眾包

去中心化算力網路的運作邏輯是這樣的：

1. 供給端：擁有閒置 GPU 的人，把算力貢獻到網路裡，賺取代幣獎勵。
2. 需求端：需要算力跑 AI 模型（尤其是「推理 / inference」）的開發者，用更低的成本、更透明的方式租到算力。
3. 代幣經濟：用代幣把供需兩端綁在同一套激勵裡，網路愈大、媒合愈有效率、單位成本愈低——又是一個三重飛輪。

這讓算力市場從「向巨頭租」變成「向全世界的閒置產能租」，理論上能壓低價格、提高韌性、打破壟斷。

四、兩個關鍵技術突破，讓它從幻想變可行

去中心化算力的構想其實很早就有，但一直卡在兩個技術難題上。近期的進展，讓它從「美好幻想」逐漸變成「可行方案」：

突破一：如何驗證「算力真的被正確執行」？

把一個 AI 推理任務發給一個素不相識的陌生節點，你怎麼知道它真的算了、而且算對了，而不是隨便回傳一個假結果來騙獎勵？這個「驗證 AI 推理」的難題，過去是去中心化算力的最大障礙。近年密碼學與機制設計上的進展（例如各種證明與抽查機制）正在讓「可驗證的去中心化推理」逐步成真。

突破二：模型架構讓推理成本下降

同時，AI 模型本身也在演化。像 MoE（Mixture of Experts，混合專家） 與 SSM（State Space Models，狀態空間模型） 這類新架構，大幅降低了「推理」的運算成本。推理愈便宜、愈能被切分成小任務，就愈適合分散到去中心化網路上跑。

再加上開源 AI 模型的崛起——當高品質的模型權重可以被自由取得、不再被單一公司壟斷，「在哪裡跑這個模型」就變成一個開放的市場問題，這正好是去中心化算力的主場。

五、潑一盆冷水：挑戰仍然真實

身為一個在這領域教學多年的人，我必須誠實提醒：熱度高，不代表沒有風險。 去中心化算力仍面臨幾個硬骨頭：

• 延遲與可靠性：分散的節點在速度與穩定性上，目前還難以全面對抗集中式資料中心。
• 驗證成本：「可驗證推理」雖有進展，但驗證本身也要消耗資源，如何不讓成本反過來吃掉節省，是門藝術。
• 需求是否真實：這跟我在 DeFi 真實收益 與 DePIN 那兩篇反覆強調的判準一樣——剝掉代幣補貼後，真的有人願意付錢用這個算力嗎？ 還是大家只是為了賺代幣而貢獻、為了挖礦而租用？

判斷一個 AI × Crypto 項目是否健康，依然是那個老問題：它解決的是真實需求，還是只是在創造一個可以炒的代幣？

結語：兩股大浪的交會處

AI 與加密，是這個時代最大的兩股技術浪潮。它們的交會處——去中心化算力網路——之所以值得關注，不是因為「兩個熱詞加在一起更熱」，而是因為它們真的互補：AI 提供了一個萬億級的真實需求（算力），加密提供了一個前所未有的協調機制（代幣激勵）。

它會不會成為下一個風口？我的看法是：方向對，但路還長。值得持續觀察，但別被高 APY 和宏大敘事沖昏頭——回到需求的本質去判斷，永遠是 Web3 投資與佈局裡最不會錯的一課。

這也是我「Web3 入門精選」系列的最後一篇。想系統性地把 Web3 學一輪？歡迎從 Web3 三時代 讀起，或了解我的 Web3 企業內訓 與大學區塊鏈課程。

它不知道今天台積電股價多少、不知道美元兌新台幣的匯率、不知道某場球賽誰贏了、甚至不知道現在幾點。對一個號稱要「重塑金融」的技術來說，這聽起來很荒謬——但這正是「預言機（Oracle）」要解決的問題。

這是我「Web3 入門精選」系列裡較進階、但非常關鍵的一篇。因為沒有預言機，就沒有 DeFi。

一、為什麼智能合約是個「瞎子」

先理解這個缺陷從哪來。區塊鏈為了讓全世界成千上萬的節點都能對「同一筆交易的結果」達成共識，它必須是確定性（deterministic）的——同樣的輸入，在任何一台電腦上跑，都必須得到完全一樣的結果。

可是「外部世界的資料」破壞了這個確定性。如果智能合約直接去問某個網站「現在 ETH 價格多少」，那不同節點在不同的毫秒去問、或問到不同的伺服器，會拿到不同的答案——共識就崩潰了。所以區塊鏈乾脆把自己封閉起來：合約只能讀取鏈上已經存在的資料，不能主動向外抓取。

這就造就了那個著名的論斷：智能合約大約 90% 的潛在用途（包含幾乎所有 DeFi）都需要與真實世界互動——而它偏偏做不到。預言機，就是來填這個鴻溝的橋。

二、預言機在做什麼？

預言機是一套機制，負責把鏈外的資料，可信地「餵」進鏈上的智能合約。它就像是智能合約的「眼睛」與「耳朵」。

一個典型的應用是 DeFi 借貸：假設你抵押價值 1 萬美元的 ETH，借出 5 千美元的穩定幣。當 ETH 價格下跌、你的抵押品價值逼近危險線時，協議必須「清算」你的部位。但協議要怎麼知道 ETH 現在跌到多少了？ 答案就是預言機——它持續把外部交易所的 ETH 價格餵進合約，合約才能據此判斷該不該清算。

整個資料進鏈的流程，可以拆成幾個動作：聽（從外部來源取得資料）→ 抽取與格式化（整理成合約看得懂的格式）→ 驗證（確認資料可信）→ 聚合運算（把多個來源的資料整合成一個值，例如取中位數）→ 播送上鏈（寫進合約供使用）。這每一個環節，都是潛在的攻擊點。

三、預言機的五大風險

預言機被稱為「區塊鏈的阿基里斯腱」不是沒道理。它的風險可以歸納為五大類：

1. 驗證問題（Verification）：你怎麼知道餵進來的資料「本身」是對的？資料來源可能就是錯的或被污染的。
2. 驗算問題（Validation）：就算來源對，傳輸與計算過程中會不會被動手腳？
3. 擴展問題（Scalability）：頻繁地把資料寫上鏈，成本高昂、也有延遲，難以規模化。
4. 可駭性（Hackability）：預言機本身成為攻擊面——如果攻擊者能操縱餵給合約的價格，就能騙過整個協議。
5. 中心化問題（Centralization）：這是最致命的一個。如果一個號稱去中心化的 DeFi 協議，背後卻只靠「單一」預言機餵價，那它根本不是去中心化的——這個預言機就是整個系統的單點故障與單點信任。

四、真實的代價：價格操縱攻擊

第四與第五點不是理論。DeFi 歷史上發生過無數次「預言機操縱攻擊（oracle manipulation）」，手法的核心都一樣：

攻擊者鎖定一個「只靠單一去中心化交易所即時價格」當預言機的協議，然後用一筆巨額交易（常搭配「閃電貸」借來的大筆資金）在那個交易所裡瞬間把某個幣的價格打到極高或極低，製造出一個短暫的假價格。協議的預言機天真地讀到這個假價格，於是攻擊者就能用扭曲的價格借走遠超應得的資產，或觸發不該發生的清算——得手後在同一筆交易裡全身而退。許多動輒數百萬、上千萬美元的 DeFi 被駭事件，根源都是這個。

五、業界怎麼防：去中心化預言機網路

針對這些風險，業界發展出的主流解法是「去中心化預言機網路（Decentralized Oracle Network）」，例如 Chainlink 這類服務。它的防禦思路有三個重點：

• 多來源：不依賴單一交易所，而是從許多獨立的資料源取價，再聚合（例如取中位數），讓單一來源被操縱也無法左右最終結果。
• 多節點：由許多獨立的預言機節點各自回報、彼此交叉驗證，避免單點故障與單點作惡。
• 抗操縱的取價方式：例如採用「時間加權平均價格（TWAP）」而非瞬時價格，讓那種「一筆巨額交易製造的瞬間假價」難以得逞。

一句話總結業界的共識：預言機本身，也必須是去中心化的。否則一個建在中心化預言機上的「去中心化金融」，只是把信任問題從台前藏到了幕後。

結語：橋，決定了城市的安全

預言機是一個容易被新手忽略、卻決定整個 DeFi 生態安危的基礎建設。它解決了「智能合約看不見外面世界」這個根本缺陷，讓借貸、衍生品、穩定幣、保險等複雜應用成為可能。

但它也提醒我們一件事：在 Web3 裡，連接「鏈上」與「鏈下」的每一座橋，都是信任最脆弱的地方。下次你評估一個 DeFi 協議時，除了看它的收益（這點我在 DeFi 真實收益 那篇談過），別忘了問一句：「它的價格，是誰餵的？可靠嗎？」

想更深入理解 Web3 的技術基礎？歡迎接著讀我的 Web3 入門精選 系列，或了解我的 Web3 企業內訓。

這是我在課堂上最愛問學生、也最多人答錯的一題。答案會顛覆很多人的直覺——你買的那張圖，幾乎可以肯定不在區塊鏈上。

要搞懂這件事，得拆開 NFT 的「技術堆疊」。這是我「Web3 入門精選」系列裡，最適合搞清楚「NFT 到底是什麼」的一篇。

一、先分清楚三種代幣標準

談 NFT 之前，要先認識以太坊上三種最重要的「代幣標準（Token Standard）」。標準就像規格書，規定了一種代幣該有哪些功能、別人該怎麼跟它互動。

理解它們的關鍵在「同質化」三個字：

• ERC-20 是同質化的——你的 1 顆 USDC 跟我的 1 顆 USDC 完全一樣，可以隨意互換，就像鈔票。
• ERC-721 是非同質化的——每一顆代幣都有獨一無二的編號（token ID），彼此不能互換，就像每張畫、每張房契都是獨立的。這就是 NFT（Non-Fungible Token）的「Non-Fungible」。
• ERC-1155 是「半同質化」——它聰明地讓一份合約能同時管理「可堆疊的同質化道具」（例如遊戲裡的 1000 把鐵劍）與「獨一無二的稀有物品」（例如一把傳說武器），對遊戲與大型生態特別實用。

二、NFT 的技術堆疊：圖片其實在鏈外

現在回到開頭的問題。一個 NFT 的完整技術堆疊，是這樣一層層串起來的：

智能合約（ERC-721）
   └── tokenURI（一個網址）
          └── metadata.json（描述檔）
                 └── IPFS 上的圖片 / 影片

讓我白話拆解：

1. 鏈上的智能合約只記錄「最關鍵、最不能造假」的事：這個 token ID 屬於哪個錢包地址。這就是「所有權」，是 NFT 真正寫在區塊鏈上、永不可竄改的部分。
2. 合約裡有一個函式叫 tokenURI，它回傳的不是圖片，而是一個網址——指向一份描述檔。
3. 這份 metadata.json 描述檔，記載了這個 NFT 的名稱、屬性、以及最重要的——圖片的真正存放位置。
4. 而那張圖片，通常存放在 IPFS（InterPlanetary File System，星際檔案系統）——一個去中心化的檔案儲存網路。

所以結論是：鏈上存的是「所有權證明」，圖片本身存在鏈外（IPFS）。為什麼要這樣設計？因為區塊鏈儲存空間極其昂貴，把幾 MB 的高解析圖片塞進鏈上是天價且不切實際的。

三、那 IPFS 是什麼？為什麼不直接放普通伺服器？

你可能會問：「圖片放鏈外，那跟存在某公司的伺服器有什麼不同？萬一公司倒了圖不就沒了？」

問得好。這正是 IPFS 要解決的問題。傳統網址（HTTP）是「用位置找檔案」——你連到某台伺服器的某個路徑，伺服器一關，檔案就消失。IPFS 則是「用內容找檔案」：它根據檔案的內容算出一個獨一無二的指紋（稱為 CID，內容識別碼），只要全世界任何一個節點還留著這份內容，你就能透過這個指紋把它找回來，不依賴任何單一公司的伺服器。

這帶來一個額外的好處：防竄改。因為指紋是由內容算出來的，只要圖片被改動一個像素，指紋就會完全不同。所以你的 NFT 描述檔裡記的那個 IPFS 指紋，本身就保證了「你看到的圖，就是當初鑄造時的那張圖」。（不過實務上要真正永久保存，仍需有人持續「釘住（pin）」這份檔案，這是 NFT 長期保存的一個現實課題。）

四、從 CryptoKitties 到品牌大舉進場

理解了技術，再看一眼 NFT 的發展里程碑，會更有畫面：

• 2017　CryptoKitties：第一個引爆主流關注的 NFT，靠著「養貓、配種」的玩法一度塞爆以太坊。
• CryptoPunks：一萬個像素頭像，後來成為 NFT 收藏的藍籌標竿。
• 2021　Beeple：數位藝術家的作品在佳士得（Christie’s）以 6,930 萬美元成交，把 NFT 推上全球新聞版面。
• BAYC（無聊猿）：不只是頭像，而是發展成一整個生態系與社群品牌。

更值得注意的是傳統品牌的大舉進場。Nike（透過收購 RTFKT）的 NFT 相關營收一度超過 1.86 億美元，Dolce & Gabbana、Gucci、Adidas、Tiffany 也紛紛投入。品牌看上的，是 NFT 提供的兩樣東西：可驗證的稀缺性，以及與鐵粉的直接連結。

五、被低估的設計：創作者版稅

最後談一個我認為 NFT 最有意思、卻最常被忽略的設計——創作者版稅（Royalty）。

在傳統世界，一位畫家把畫賣出去之後，這幅畫後續在拍賣會上轉手再多次、漲再多倍，原作者都拿不到一毛錢。但 NFT 可以把「每次二級市場轉售時，自動抽 X%（常見 10%）回饋給原創作者」這個規則寫進智能合約裡。

這在概念上是革命性的：創作者第一次能夠分享到自己作品「長期增值」的果實，而不只是一次性的售出收入。（必須誠實補充：版稅的「強制執行」在實務上一直有爭議，部分交易市場為了競爭而選擇不強制收取——這也是 NFT 生態仍在演化中的議題。）

結語：所有權，才是重點

繞了一圈，我們回到 NFT 的本質。剝掉那些天價拍賣與炒作的喧囂，NFT 真正的技術貢獻只有一件事——它讓「數位物品的所有權」第一次能被清楚、公開、不可竄改地記錄下來。圖片可以被無限複製，但「誰擁有那個鏈上唯一的所有權憑證」是無法複製的。

這恰好呼應了我在 Web3 三時代 裡談的核心——Web3 的靈魂是「擁有」。而 NFT，就是「擁有」這件事在數位世界裡最具體的一種長相。

想更系統地理解 Web3？歡迎接著讀我的 Web3 入門精選 系列，或了解我的 Web3 企業內訓。

這是一個好問題，而答案藏在一個大多數人從來沒問過的關鍵裡：這個收益，到底從哪裡來？

學會回答這個問題，你就掌握了在 DeFi 世界裡保命的第一課。這是我「Web3 入門精選」系列裡，我認為對散戶最實用的一篇。

一、收益必須有來源——天下沒有白吃的午餐

先講一個最樸素的道理：任何收益，都必須有一個真實的來源。在傳統金融裡，這個來源你很熟悉——銀行付你利息，是因為它把你的錢借出去收了更高的利息，中間的差價分你一點；債券付你票息，是因為發行人拿你的錢去做了能產生現金流的事。

收益 = 別人為了使用資金而付出的成本。這在 DeFi 裡也一樣成立。問題是，DeFi 的收益有兩種截然不同的來源，而它們的「可持續性」天差地別。

二、兩種收益：真實收益 vs 代幣通膨收益

第一種：真實收益（Real Yield / Exogenous Yield）

這種收益來自協議外部真實產生的現金流——也就是真的有人為了某個服務付了費。常見的來源有：

• 借貸利息：有人在借貸協議裡借走資金，付出利息，這些利息分給提供資金的你；
• 交易手續費：有人在去中心化交易所換幣、或在永續合約市場交易，付出的手續費分給提供流動性的你；
• 套利與資金費率：市場上真實存在的價差與資金需求。

這種收益的特徵是：錢是「從外面進來的」，是別人真金白銀付的服務費。它通常不會高得離譜——多落在 5% 到 15% 的合理區間，但它可持續。

第二種：代幣通膨收益（Token Inflation Yield）

這種收益則完全是另一回事。協議為了快速吸引資金，會狂印自家的代幣當獎勵發給你。它表面上 APY 可以衝到 100%、500%、甚至四位數，但這些獎勵不是來自任何真實現金流，而是憑空增發的新代幣。

問題就出在這裡：當大家都在領這些新印的代幣、然後拿去市場上賣掉換成穩定幣或主流幣，代幣價格就會被持續的賣壓壓垮。於是你看到的劇本永遠是——前期 APY 高得嚇人、資金蜂擁而入、代幣價格短暫飆升，然後代幣崩盤、實際收益（換算成美元）瞬間歸零，最後進場的人接下最後一棒。

這就是高 APY 背後的「龐氏結構」：你以為在賺利息，其實是在參與一場「代幣增發 → 拋售 → 崩盤」的擊鼓傳花。

三、一張表，看穿收益的本質

判斷一個 DeFi 收益是否健康，你只需要反覆問那一句話：「如果協議停止增發代幣，這個收益還剩多少？」 剩很多 → 真實收益；歸零 → 代幣通膨陷阱。

四、2025 年的轉折：DeFi 的「真實收益化」

值得高興的是，整個 DeFi 產業正在經歷一場成熟化的轉變。

2021 年那場「DeFi Summer」的狂熱，大量收益其實是代幣通膨撐起來的，崩盤後一地雞毛。但到了 2025 年，市場的氣氛變了——機構資金進場，而機構要的是「可持續、可解釋」的收益來源。它們不會為了一個來路不明的高 APY 把錢投進去，它們要知道這筆錢「賺的是誰的、賺的是什麼」。

於是市場出現一個明顯趨勢：計息穩定幣（yield-bearing stablecoin）取代了被動穩定幣，成為 DeFi 的核心抵押品。這類穩定幣的收益往往來自現實世界資產（RWA）——例如把資金投入代幣化的短期國債，賺取真實的票息。這正是「真實收益」邏輯的勝利。配合宏觀的降息週期，有人說「DeFi Summer 2.0」的條件正在形成，但這一次，底下踩的是更堅實的地基。

結語：先問來源，再談收益

回到那位拿著手機問我「年化 120% 是不是真的」的朋友。我的回答永遠是同一句：

「先別問利率多少，先問這個收益從哪裡來。」

如果對方答得出一個真實的現金流來源（手續費、借貸利息、國債票息），那這個收益至少站得住腳；如果答案含糊、或一切都建立在「代幣會一直漲」的假設上，那你看到的多半不是收益，而是陷阱。

這套「追問收益來源」的思維，不只適用於 DeFi，也適用於我在 DePIN 那篇談的「剝掉補貼後還剩什麼」。在 Web3 裡，能保護你的不是貪婪的相反——謹慎，而是一個簡單的問題：錢從哪來。

想建立更完整的 Web3 風險意識？歡迎接著讀我的 Web3 入門精選 系列，或了解我的 Web3 企業內訓。

這是我「Web3 入門精選」系列的一篇。如果你覺得加密貨幣總是飄在空中，那 DePIN 會是讓你「有感」的一個切入點。

一、DePIN 是什麼？

DePIN 是 Decentralized Physical Infrastructure Networks（去中心化實體基礎設施網路）的縮寫。它的核心定義其實只有一句話：

用加密激勵（crypto-incentives），來協調真實世界基礎設施的「建設」與「營運」。

換個方式說：傳統上，要蓋一張覆蓋全國的無線網路、或建一個龐大的雲端運算中心，需要一家巨型公司投入天文數字的資本。DePIN 反其道而行——它用代幣作為獎勵，動員成千上萬的普通人，各自貢獻一小塊硬體（一台路由器、一張顯卡、一個感測器），共同拼湊出一張原本只有大公司才建得起的基礎設施網路。

舉個最經典的例子：Helium。它想建一張覆蓋廣泛的無線網路，但它不自己架基地台，而是讓一般人在家裡或店裡插上一個小型熱點裝置，幫忙提供網路覆蓋，作為回報，這些人會獲得代幣獎勵。人人都是基礎設施的一塊磚——這就是 DePIN 的精神。

二、DePIN 的六大類別

DePIN 不是單一賽道，而是一個涵蓋多種基礎設施的大家族。目前大致分為六大類別：

其中，運算與無線是目前最成熟、市值最大的兩塊。根據 2024 年的產業統計，全球已有約 350 個 DePIN 代幣、總市值約 500 億美元，其中光是運算類就佔了約 400 億美元。

三、三重飛輪：DePIN 為什麼能滾起來

DePIN 真正迷人的地方，在於它的成長邏輯——一個由三股力量疊加而成的「三重飛輪（Triple Flywheel）」：

1. 基礎設施的規模經濟：愈多人貢獻硬體，網路覆蓋愈廣、服務愈好、單位成本愈低。
2. 網路效應：服務愈好，使用者愈多；使用者愈多，又吸引更多人來貢獻硬體賺取獎勵。
3. 代幣流動性的護城河：代幣的價值與網路的成長綁定，形成一道難以被後進者複製的經濟護城河。

這三個輪子彼此咬合、互相加速：供給端（貢獻硬體的人）與需求端（使用服務的人）被同一套代幣經濟同時點燃。這正是傳統基礎設施公司做不到的——它們得先燒掉巨額資本把網路建起來，才能開始服務客戶；而 DePIN 讓「建設」與「使用」從第一天起就同步成長。

四、為什麼說 DePIN 被低估？

這裡有一個讓我印象深刻的數據：DePIN 目前的市值（約 500 億美元），相對於它所瞄準的終端市場（雲端運算、電信、能源等加起來超過 1 兆美元），佔比還不到 0.1%。

換句話說，如果 DePIN 真的能在這些萬億級的傳統市場裡啃下哪怕一小塊，它的成長空間是百倍級的。這也是為什麼許多研究機構把 DePIN 列為「加密與真實世界交集中，最具長期潛力」的賽道之一。

當然，潛力大不等於沒有風險。DePIN 同樣面臨硬體品質參差、需求是否真實存在（會不會只是「為了賺代幣而貢獻」的虛假繁榮）、以及監管不確定性等挑戰。判斷一個 DePIN 項目是否健康，我的標準很簡單：剝掉代幣補貼後，它提供的服務還有沒有人真的願意付錢用？ 這跟我在 DeFi 真實收益 那篇談的判斷邏輯，其實是同一套。

結語：把真實世界接上鏈

DePIN 之所以重要，是因為它示範了區塊鏈最務實的一種用法——不是炒作虛擬代幣，而是用代幣激勵去解決「協調大量陌生人共建基礎設施」這個自古以來的難題。

它和 RWA（現實世界資產代幣化） 是一體兩面：RWA 把真實「資產」搬上鏈，DePIN 把真實「基礎設施」接上鏈。兩者都在做同一件事——讓區塊鏈走出加密圈，真正觸碰實體世界。

想更系統地理解 Web3 的各個賽道？歡迎接著讀我的 Web3 入門精選 系列，或了解我的 Web3 企業內訓。

這個問題之所以難回答，是因為大部分人一上來就被「區塊鏈」、「去中心化」、「加密貨幣」這些詞淹沒。但其實有一個更簡單、也更本質的切入點——把網路的歷史，分成三個時代來看。理解了這三個時代，你就抓住了 Web3 的靈魂。

這是我「Web3 入門精選」系列的第一篇。我們從頭講起。

一、Web1：唯讀的時代（1990–2005）

網際網路的第一個時代，是「唯讀（Read）」的時代。

那時候的網站，本質上是一本本放在網路上的「電子書」。你打開一個網頁，可以讀裡面的內容——新聞、企業介紹、個人首頁——但你幾乎不能做任何事。沒有留言、沒有按讚、沒有上傳。資訊的流動是單向的：少數人製作內容，多數人被動閱讀。

Web1 的歷史功績是：它降低了「資訊獲取」的門檻。在它之前，知識被鎖在圖書館、報社、電視台手裡；在它之後，任何能上網的人都能讀到全世界的資訊。用一句話總結：協定網路，把「資訊」分享給了每一個人。

二、Web2：讀寫的時代（2006–2020）

接著，網路進入了「讀寫（Read + Write）」的時代，也就是我們最熟悉的這二十年。

部落格、YouTube、Facebook、Instagram、抖音——這些平台的共同點是：你不只能讀，還能寫。每個人都能發文、上傳影片、留言互動。內容的生產權力，從少數菁英手中下放到了所有人。這是一場巨大的解放，催生了「網紅」、「自媒體」、「創作者經濟」等全新的職業與產業。

Web2 的歷史功績是：它降低了「發表」的門檻。用一句話總結：企業網路，把「發表的權力」分享給了每一個人。

但 Web2 有一個深層的問題，而這個問題正是 Web3 想解決的——你寫的東西，並不真正屬於你。

你在某平台上累積了百萬粉絲，但平台一旦封你的帳號，這些粉絲瞬間歸零；你上傳的影片、發表的貼文，所有權其實掌握在平台手裡；你創造的價值（流量、注意力、資料），絕大部分被平台拿走。你以為你是主人，其實你只是租客。在 Web2，你能「讀」、能「寫」，卻不能「擁有」。

三、Web3：擁有的時代（2021–至今）

於是，網路演進到了第三個時代：「讀寫擁有（Read + Write + Own）」。

Web3 在「讀」和「寫」之上，加入了關鍵的第三件事——所有權（Ownership）。靠著區塊鏈這個「沒有人能單方面竄改的共享帳本」，你在數位世界裡第一次能夠真正「擁有」一樣東西：

• 你錢包裡的加密貨幣，沒有任何公司能憑空沒收；
• 你持有的 NFT，所有權記錄在鏈上，不依賴任何平台的伺服器；
• 你在某個協議裡的身分與信譽，可以帶著走，不被綁死在單一平台。

Web3 的歷史功績是：它降低了「擁有」的門檻——讓所有權不再是大型機構的專利。用一句話總結：區塊鏈網路，把「所有權」分享給了每一個人。

四、一張表看懂三時代

看出規律了嗎？每一次跨越，都代表數位權力的進一步下放——從「能看」，到「能說」，再到「能擁有」。這不是三個無關的技術，而是同一條脈絡上的三個階段。

五、三個層面：數學、哲學、神學

如果你想再往深一層理解區塊鏈為什麼能做到「擁有」，我很喜歡美圖董事長蔡文勝提過的一個三層框架：

• 數學層面：加密演算法提供「可被驗證的數學證明」。你擁有某個資產，不需要一家公司來幫你證明——數學本身就是證明。
• 哲學層面：它改變了「人類信任」的運作方式。過去我們信任機構（銀行、平台、政府）；現在我們可以信任「程式碼與共識」。
• 神學層面：它甚至在建立一種去中心化的「信仰體系」——一群素未謀面的人，因為相信同一套規則而協作。

你不一定要認同最後一層的浪漫，但前兩層是真實且深刻的：Web3 的本質，是一次「信任的遷移」——從「信任人與機構」，遷移到「信任數學與規則」。

結語：為什麼企業該理解這件事

對企業與專業工作者而言，理解這三個時代不是為了趕流行，而是因為——每一次網路時代的更替，都重新洗牌了商業機會。Web1 成就了入口網站，Web2 成就了社群平台與創作者經濟，那麼 Web3 的「所有權」會成就什麼？這正是值得每個經營者思考的問題。

這是我「Web3 入門精選」系列的起點。接下來我會帶你認識 DePIN、DeFi 的真實收益、NFT 技術 等主題。如果你的組織想系統性地建立 Web3 知識，歡迎了解我的 Web3 企業內訓 與大學區塊鏈課程。

「RWA 對台灣金融業，到底有沒有真實意義？還是又一個會泡沫化的加密熱詞？」

我的答案是：有意義，而且很大。但理由不在「區塊鏈很潮」，而在它解決了幾個台灣金融業積累已久、卻一直沒有好解法的真實痛點。讓我從三個視角談起。

一、參加機構視角：流動性、成本與風險

先說最務實的一群人——銀行、券商、資產管理公司，也就是金融基礎設施裡的「參加機構」。對他們來說，現行的金融管線有幾個長期的隱性成本：

第一，流動性的碎片化。 同一檔債券，可能分散在不同機構的不同帳簿系統裡。要做一筆跨機構交易，往往要經過層層對帳、確認、清算，每一層都是時間，也都是成本。T+2 的交割週期（成交後兩個工作日才完成交割）在這個秒級世界裡，已經像是一種時代錯置。

第二，跨機構清算的摩擦。 傳統交割有一個揮之不去的幽靈叫「對手方風險」——你交了券，對方還沒付款；或你付了款，對方還沒交券。整個後台有大量人力與制度，存在的唯一目的就是管理這個「中間的空窗」。

RWA 的「鏈上券款對付（DvP, Delivery versus Payment）」直接消滅了這個空窗：買賣與付款寫進同一筆原子交易，要嘛同時成功、要嘛同時失敗，沒有中間狀態，因此沒有對手方違約的可能。對參加機構而言，這不是「換個系統」，而是把一整類風險與其對應的後台成本，從根本上拿掉。

第三，門檻與觸及。 一張百萬面額的債券可以被切分成極小單位，配息、付息、到期贖回都能寫進智能合約自動執行。這對中小型參加機構、乃至於它們背後的零售客戶，都意味著更低的參與門檻與更高的資金效率。

二、監理視角：透明、可稽核與不可否認

第二個視角，是常被外界誤解的監理端。很多人直覺以為「區塊鏈 = 規避監管」，但對 RWA 這種受監理資產來說，事實恰恰相反。

一條設計良好的（合規型）RWA 鏈，反而是監理者的夢幻工具：

• 完整且永久的交易歷史：每一筆移轉都留下不可竄改的紀錄，這是一條天然的、永久的稽核線索。傳統金融要查一筆三年前的交易要調好幾個系統的紀錄；在鏈上，它一直都在。
• 不可否認性（non-repudiation）：每筆交易都由特定機構的私鑰簽署，「這筆是不是你做的」不再有爭辯空間。
• 反洗錢與資金流向追蹤：在 KYC 與白名單機制嵌入代幣標準的前提下（這正是 ERC-3643 這類合規標準在做的事），資金的合規流動可以被即時驗證，而不是事後補查。

這也是為什麼我認為台灣傾向「由中央保管機構（CSD）主導」的路線是對的。把這條鏈建在國家級、中立、受信任的基礎設施上，而不是放任民間平台各自為政，等於是從一開始就把「監理可見性」寫進了系統的地基。當然，這裡有個前提必須誠實面對：紀錄永久也意味著個資保護要做得更細緻——鏈上資料是否屬於個資、如何在「可稽核」與「可被遺忘」之間取得平衡，是必須同步解決的法律課題。

三、技術視角：為什麼區塊鏈與金融天生一對

第三個視角偏技術，但結論很重要。

區塊鏈最被低估的價值，不是「去中心化」這個常被濫用的詞，而是「可審計性」——它本質上是一個所有人都認帳、無法事後竄改的共享帳本。金融業的核心，說到底就是「記帳」與「結算」這兩件事，而這正是區塊鏈最擅長的。從這個角度看，金融與區塊鏈不是「潮流硬湊」，而是問題與工具的天作之合。

更深一層的，是我在隱形基建那篇談過的後量子密碼學（PQC）。金融紀錄要保存幾十年，而今天用的簽章演算法可能在 2030 年代被量子電腦破解。一個願意在今天就為「三十年後的法律有效性」做準備的平台，展現的不是技術炫耀，而是對「長期」二字應有的敬意。這種對時間尺度的敬畏，正是金融基礎設施與一般科技產品最大的差別。

四、那麼，泡沫的疑慮呢？

我必須誠實：RWA 領域確實有泡沫的成分，市場上不乏蹭熱度的項目。但要區分兩件事——

「炒作」會泡沫化，「基礎設施」不會。 穩定幣（最早、最成功的 RWA）已經證明了這條邏輯：當 USDT、USDC 把美元搬上鏈、被全球用於支付與結算，它就不再是炒作，而是基礎設施。RWA 要做的，是把同樣的邏輯延伸到債券、基金、黃金這些更複雜的資產上。

判斷一個 RWA 項目是不是泡沫，我的標準很簡單：它解決的是真實的金融摩擦，還是只是在創造一個可以炒的代幣？ 鏈上 DvP 消滅對手方風險——這是真實摩擦。國債被切分讓小資族也能參與——這是真實需求。當全球最大的資產管理公司（BlackRock）、最大的銀行（UBS、摩根大通）、最大的證券保管機構（美國 DTC）都在 2024–2026 年間相繼下場，這已經不是少數人的賭注，而是主流金融的集體轉向。

五、台灣的時間窗口：為什麼是現在

把前面全球監管地圖的觀察收攏起來，我的結論是：2026 年，是台灣金融業一個不該錯過的窗口。 原因有三：

1. 國際標準已經收斂。 CMTAT、ERC-3643 這些合規型標準被各國試點反覆採用，我們不必再從零摸索「該用什麼」——可以直接站在國際的肩膀上。
2. 法規方向逐漸清晰。 從金管會的數位資產法研議、到《虛擬資產服務法》的穩定幣框架規劃，台灣的監理路線正在成形。
3. 時程上並不落後。 台灣 CSD 主導的路線與美國 DTC 試點時程相當接近——這在金融科技領域是少見的「與最大玩家同步」。

剩下的，是執行力與決心。台灣最大的待補拼圖，是合規的新台幣穩定幣——沒有它，鏈上的「現金端」就無法閉環，DvP 也只能做半套。這塊補上了，整個系統才算真正完整。

我常說，新技術導入金融業的成敗，從來不是技術本身，而是「制度設計」。2019 年的 STO 不是輸在技術，是輸在額度限制與流動性——這個教訓，希望這一次不要重蹈。

結語：橋樑，而不是賭場

回到最初的問題。RWA 對台灣金融業的真實意義是什麼？

我的答案是：它是一座橋，不是一座賭場。 它通往的，是一套讓資產 24/7 自由流動、即時結算、全球可驗證的金融基礎設施。穩定幣是這座橋的入口，RWA 是橋的本體。

對台灣來說，問題從來不是「要不要過這座橋」——全球都在過——而是「我們要當造橋的人，還是過很久以後才跟著走過去的人」。我希望，是前者。

這是我 RWA 系列的句點，但也許是台灣這個故事的起點。如果你的團隊正在評估 RWA 的可能性，或想為組織建立 Web3 的知識基礎，歡迎了解我的 技術顧問服務 與 Web3 企業內訓。也歡迎從系列總論開始，把整個脈絡讀一遍。

RWA 的本質，從來不是「能不能把資產上鏈」的技術問題，而是「如何讓區塊鏈聽法律的話」。而法律是有國界的——同一筆代幣化債券，在新加坡、在香港、在紐約、在台北，面對的是完全不同的監理框架。這篇，我想畫一張 2026 年的全球 RWA 監管地圖，看看各國跑到哪裡、台灣站在哪裡。

一、為什麼監管是 RWA 的真正戰場

先建立一個基本認知：把比特幣轉給朋友很簡單，因為沒人管你是誰。但把一張真正受監管的債券放上鏈，你立刻會撞上一整面法律的牆——證券法要求發行人隨時知道持有人是誰、法院可能要求凍結特定人的資產、繼承與司法執行需要強制轉移、配息前要對所有持有人做餘額快照。

這些事，一般加密貨幣（ERC-20）做不到。所以 RWA 的競賽，表面上是技術競賽，骨子裡是「哪個司法管轄區能最快把這套國際技術語言，接上自己的市場制度與法律」的監理競賽。

接下來我們依序看亞太、西方、台灣三塊。

二、亞太：新加坡與香港的雙雄並進

亞太是目前全球 RWA 監理最積極的區域，由新加坡與香港領跑。

新加坡：Project Guardian（MAS 主導，2022 啟動）

新加坡金融管理局（MAS）在 2022 年啟動 Project Guardian，是國際 RWA 試點的主力。它的特點是「監理機構帶頭、國際大行下場」——參與者包括 UBS、HSBC、渣打、SBI、DBS 等銀行，以及 JPMorgan、BNY Mellon、Apollo 等資管巨頭。

它最具代表性的成果是一筆跨境附買回（Repo）試點：UBS（持有日圓計價債券、想借美元）、SBI（手握美元、想賺利息）、DBS（清算合作）三方，把債券與現金分別轉入鏈上 escrow，簽訂鏈上 Repo 合約，到期時在鏈上原子化（atomic）地同時完成還款與還券。這第一次驗證了「跨境機構、多幣別、多鏈」的鏈上 Repo 是可行的，而且是生產級而非實驗。

MAS 在 2024 年進一步發布「Fixed Income Framework for Tokenization」（代幣化固定收益框架），成為國際級的 RWA 標準參考文件，文中多次引用 CMTAT 作為主要技術框架。新加坡的另一張王牌是成熟的監理沙盒，讓銀行能在受監督的環境下試點創新。

香港：Project Ensemble（HKMA 主導，2024 啟動）

香港金管局（HKMA）在 2024 年啟動的 Project Ensemble，路線與新加坡略有不同——它把重心放在 wholesale CBDC（批發型央行數位貨幣）與代幣化貨幣的結算整合上。參與者包括滙豐、渣打、中銀香港、恒生等。

Ensemble 的核心試點有二：一是用 HKMA 自家的批發型 CBDC（數位港元）做銀行間即時清算；二是讓各銀行發行自己的「代幣化存款（Tokenized Deposit）」，在鏈上轉移、鏈下清算，並受 HKMA 監管。試點標的涵蓋不動產、私募信貸與綠色債券。

兩者並進，分別代表新加坡與香港爭奪亞太數位金融樞紐地位的不同戰略。

三、西方：美國 DTC 與歐盟 DORA

美國：DTC 試點與 Canton Network

如果說亞太靠靈活，美國靠的是體量。DTC（The Depository Trust Company） 是美國的中央證券存託機構，成立於 1973 年，保管著超過 56 兆美元的美國證券——它是全球最大的 CSD，美國股票、債券、ETF 的所有權紀錄都在這裡。

2025 年 12 月，美國 SEC 對 DTC 發出 No-Action Letter，允許它在分散式帳本（DLT）上試點美國證券的所有權紀錄。這是一個重量級信號：美國監理開始接受區塊鏈作為主流結算系統。 DTC 的規劃是 2026 上半年完成技術選型、下半年啟動第一批試點，底層選用了以隱私為核心、已有高盛與 JPMorgan 等機構使用的 Canton Network。

當全球最大的 CSD 都開始把證券所有權鏈上化，它牽動的是整個全球金融基礎設施的方向。

歐盟：DORA 與穩定幣監管

歐盟的角色比較像是「立規矩的人」。DORA（Digital Operational Resilience Act，數位營運韌性法案） 在 2025 年 1 月全面執行，其 Article 8 要求金融機構建立 ICT 風險管理框架，並具備「從主系統切換到備援系統」的能力——這被業界廣泛解讀為包含密碼學切換能力（與我在隱形基建那篇談的後量子遷移直接相關）。值得注意的是，DORA 具有域外效力：只要你跟歐盟有業務往來，就可能落入它的管轄。

在穩定幣這一塊，美國的 GENIUS Act（2025 年通過）要求穩定幣 100% 準備金、月度揭露與獨立審計，給了美元穩定幣明確的法律地位；歐盟則有 MiCA 框架。穩定幣之所以重要，是因為它是 RWA 的「現金端」——沒有合規的鏈上現金，「券款對付（DvP）」就難以真正在鏈上完成。

四、台灣：從 STO 的教訓，到 RWA 的機會

把鏡頭轉回台灣。很多人不知道，台灣其實很早就試過代幣化——只是用了另一個名字：STO（Security Token Offering，證券型代幣發行）。

2019 STO 規範：為什麼沒做起來

2019 年 6 月，金管會發布 STO 募資管理辦法，允許用區塊鏈發行等同於證券的代幣。但它失敗了，原因是額度限制太嚴：

• 自然人投資每檔上限僅 30 萬元（投資人嫌少）；
• 單檔募資上限 3,000 萬元（公司嫌合規成本不划算）；
• 平台業者門檻高，又沒開放公開集中交易。

結果是五年下來只有元富、凱基、元大等少數券商取得資格，實際發行案例個位數，總募資金額不到 1 億新台幣。這是一個寶貴的教訓：技術可行不等於市場可行，制度設計的「額度」與「流動性」才是成敗關鍵。

RWA ≠ STO：定位的關鍵差異

這裡要釐清一個常見的混淆。當前討論的 RWA 代幣化，和 2019 年的 STO 並不是同一件事：

關鍵在於：RWA 代幣化的標的「本來就是受監理的證券或商品」，只是把它的持有形式從傳統帳簿換成鏈上代幣。它不是創造一個新的法律類別，因此可以沿用既有法源，不必苦等新法。

台灣的獨特優勢與最大缺口

台灣在 RWA 上有一個全球相對罕見的特點：傾向由集中保管機構（CSD）這種國家級基礎設施直接主導平台建置，而不是放任民間平台各自為政。這種「CSD-led」的模式，在基礎設施的保障與信任上較強——這點恰好與美國 DTC 的路線同頻。事實上，台灣的時程與美國 DTC 試點（2026 下半年）相當接近，台灣在這場競賽裡並不落後。

但最大的缺口是穩定幣：目前台灣沒有合規的新台幣穩定幣，鏈上的「券款對付」就難以完全閉環。好消息是，台灣規劃最快在 2026 下半年隨《虛擬資產服務法》推出穩定幣框架；金管會也在研議涵蓋 STO、託管、穩定幣的「數位資產服務法」，預計 2026–2027 立法。

五、一張總表：2026 年全球 RWA 監理進度

把這張表攤開來看，會發現一個清楚的趨勢：2026 年，RWA 已經從「加密圈的概念」變成「各國主流金融基礎設施的競賽項目」。國際標準正在收斂（CMTAT、ERC-3643 被反覆引用）、各地法規方向逐漸清晰、技術也被一再驗證可行。

結語：誰能最快把國際語言接上本地制度

RWA 的全球監管地圖告訴我們一件事：這場競賽的勝負手，不在「誰的鏈最快」，而在「誰能最快把這套國際技術語言，接上自己市場的制度與法律」。

新加坡靠沙盒的靈活、香港靠 CBDC 的整合、美國靠 DTC 的體量、歐盟靠規則的輸出。而台灣，手上握著「CSD 主導」這張在信任上頗有分量的牌，缺的是把穩定幣這塊現金端補齊、把法規方向定清楚的臨門一腳。

2026 年，正是台灣金融業的關鍵窗口。關於這個窗口對台灣到底意味著什麼，我寫在系列的下一篇——當資產開始上鏈：RWA 對台灣金融業的真實意義。如果你的組織想建立 RWA 與 Web3 的知識基礎，歡迎了解我的 技術顧問服務 與 Web3 企業內訓。

這篇要談的，就是 RWA 平台底下兩塊最容易被忽略、卻最致命的基建：私鑰怎麼保管（HSM），以及 這些密碼學還能撐多久（後量子密碼學，PQC）。

一、一切的起點：私鑰就是資產本身

把一張債券或一克黃金代幣化，意味著鏈上會有一筆交易，而這筆交易是用一把私鑰簽出來的。在傳統金融裡，如果有人盜轉了你的股票，券商和集保可以靠人工調帳、靠法院命令把它救回來。但在區塊鏈上，簽章即授權——一旦私鑰外洩，攻擊者用它簽的任何交易都是「合法」的，鏈不會問你是不是本人。

這就是為什麼「私鑰存在哪裡」是 RWA 平台的第一個生死問題。我們有幾個選項：

• 存在硬碟的 .pem 檔？硬碟會被偷、被駭，有 root 權限的人就能讀。
• 存在資料庫加密欄位？那加密用的金鑰又存在哪？問題只是往後推一層。
• 存在記憶體、運算時才解密？記憶體可以被 dump、被 cold boot attack 撈出來。

唯一站得住腳的答案是：把私鑰放進一個「永遠不會離開」的容器裡，所有簽章運算都在容器內完成。這個容器，就是 HSM（Hardware Security Module，硬體安全模組）。

二、HSM 是什麼？金融業用了五十年的「保險箱」

如果說 ECDSA、RSA 這些密碼演算法是「鎖」，那 HSM 就是「保險箱」——鎖再強，鑰匙隨便放桌上也沒用。

一台合格的企業級 HSM 提供四個核心保證：

1. 金鑰永不以明文離開硬體：你把資料送進去，HSM 在內部簽完、把簽章送出來，私鑰本身從未出現在 HSM 之外。
2. 物理防篡改（tamper resistance）：試圖撬開外殼，內部感測器立刻觸發 zeroization——把所有金鑰瞬間覆寫為零。就算整台被偷走，也偷不到金鑰。
3. 真亂數來源（TRNG）：用熱噪聲、量子效應產生硬體亂數。這比軟體亂數可靠得多——這點等下講 Sony 的故事時你會懂為什麼重要。
4. 存取控制：關鍵操作需要「M-of-N」多人核可（例如五個管理員中三個同時插卡才能動），並留完整稽核紀錄。

HSM 不是 2010 年代為了加密貨幣才發明的。它的源頭是 1970 年代的 ATM——當提款機開始普及，使用者輸入的 PIN 在傳輸途中要怎麼保護？IBM 與 HP Atalla 這些公司做出了第一代金融 HSM 來加密 PIN。1990 年代網路商務興起，CA（憑證機構）的根私鑰成為新的保管重點，「根 CA 私鑰必須在 HSM 內」變成 PKI 的鐵律，那套多人見證、攝影錄影、磁帶歸檔的「金鑰儀式（Key Ceremony）」也在此時成熟。

換句話說，HSM 是五十年血淚累積的結論，不是炫技。

三、不用 HSM 的代價：一份還在增長的損失清單

為什麼金融業願意花一台動輒數萬美元買 HSM？因為「不用」的代價更貴。歷史上幾起關鍵事件，徹底證明軟體保管金鑰是不夠的：

• Sony PlayStation 3 私鑰外洩（2010）：Sony 用 ECDSA 簽 PS3 韌體，卻重複使用了 nonce（隨機數），駭客直接反推出私鑰。教訓：亂數品質決定 ECDSA 安全，這正是 HSM 內建 TRNG 的價值。
• 加密貨幣交易所大屠殺：這份清單長得驚人——

每一筆損失都在重複同一句話：沒有硬體保護，私鑰早晚會遺失。 對一個要保管國家級金融資產的 RWA 平台來說，這條清單就是不能犯的錯誤示範。

四、不是所有「硬體」都一樣：FIPS 140-3 等級制度

這裡有個關鍵概念：當有人說「我們有 HSM」時，第一個該問的不是品牌，而是「FIPS 等級多少？」

FIPS 140-3 是美國 NIST 對密碼模組的安全認證標準，分四級：

Level 3 是金融業的隱性最低門檻——它是「能不能在金融場景用」的入場券。Level 4 通常是過度（不必要的成本），Level 2 則不足（跨境互通會被打回票）。歐洲還有另一套以 EAL 等級表示的 Common Criteria（CC）認證，國際級的金融基礎設施經常要求 FIPS 與 CC 兩者兼備。

還有一個容易被行銷話術蓋過的細節：FIPS 認證的不是「整台設備」，而是特定的密碼模組（韌體 + 硬體子集）。同一台 HSM 可能整體有 Level 3 認證，但某些新功能（例如稍後要談的後量子演算法）不在認證邊界內。這個區別，等下會變成 RWA 平台的一個現實難題。

五、HSM vs MPC：兩種保管哲學

近五年出現了一個常被宣傳成「HSM 替代品」的技術：MPC（Multi-Party Computation，多方安全計算）。

MPC 的想法是：把一把「邏輯」私鑰切成 N 份碎片（shares），分散由不同伺服器或機構保管；簽章時這些節點互相通信、在不重組完整私鑰的前提下產生簽章。攻擊者必須同時攻破多份碎片才能偽造簽章。

兩者的哲學差異很清楚：

最先進的做法不是二選一，而是兩者結合：讓每一份 MPC 碎片都存在 HSM 內。這樣你同時拿到 HSM 的硬體保證與 MPC 的數學保證。市場上的機構託管平台（如 Fireblocks、BitGo、Liminal 等）大多走這條「HSM-backed MPC」的路線。

所以下次聽到「我們用 MPC，不需要 HSM」時，內行的追問是：「你的碎片存在哪？」——如果答案是「軟體加密」，那它的安全性遠低於有 HSM 撐底的 MPC。

對 RWA 平台的實務啟示是：受高度監管的中央保管端，HSM 幾乎是必須（合規最嚴）；而下游各參加機構的保管，則可依規模與場景，在自建 HSM、HSM-backed MPC 之間選擇。這是分工，不是冗餘。

六、然後，量子電腦來敲門了

把私鑰鎖進 HSM，解決了「鑰匙放哪」的問題。但還有一個更深的問題：這把鎖本身，還能撐多久？

這就要談到 PQC（Post-Quantum Cryptography，後量子密碼學）。

故事要從 1994 年說起。美國數學家 Peter Shor 證明了一件事：只要存在一台「夠大」的量子電腦，現行所有 RSA 與橢圓曲線（ECC/ECDSA）密碼系統都會被破解。 原因在於——RSA、ECDSA、DH 這些演算法的安全性，全都建立在「某一類離散對數問題對古典電腦太難」的假設上，而 Shor 演算法用量子的方式把這類問題從「次指數時間」壓縮成「多項式時間」。

兩年後的 Grover 演算法（1996） 補了一刀，但威脅小得多：它讓對稱加密（AES）與雜湊（SHA）的破解只是「平方加速」，把 AES-128 升到 AES-256、把雜湊輸出加長就能擋住。

所以真正的曝險不對稱地集中在一處：

• 簽章與金鑰交換（RSA / ECDSA / ECDH）：高曝險，必須換成 PQC 演算法。
• 對稱加密與雜湊（AES / SHA）：低曝險，只要加長參數即可。

對 RWA 平台來說，這意味著：你不必把整個系統重寫，但所有跟簽章、金鑰交換有關的部位，都必須先具備「將來能換」的能力。

七、「先收割，後解密」——為什麼現在就得動

很多人直覺認為：「量子電腦還沒造出來，等它出現再換不就好了？」這個直覺是錯的，錯在一個叫 HNDL（Harvest Now, Decrypt Later，先收割後解密） 的攻擊模型。

對手不必等到擁有量子電腦的那天才動手。他可以今天就把你的加密流量、簽章紀錄全部存下來，等量子電腦成熟（業界稱為「Q-day」）那天再回頭解密。

所以真正的判斷標準是：資料的敏感期，有沒有超過「Q-day 距離今天的時間」？

這正是 RWA 的痛點。金融機構的帳簿與交易紀錄依法要保存 5 到 30 年；今天用 ECDSA 簽的一筆結算，30 年後仍須能在法庭上被驗證為「未經竄改、確實來自某機構」。如果 ECDSA 在 2030 年被破，那 2025 到 2030 之間累積的所有鏈上歷史的「不可否認性」都會被打上問號。

各家對 Q-day 的估算（截至 2026 年初）落在 2029 到 2035 之間：Google 與 Cloudflare 內部目標是 2029，NIST/NSA 與美國聯邦系統的合規截止是 2030。讓所有人從 2024 年突然緊張起來的關鍵，是 Google 在 2024 年的研究——把「破解 RSA-2048 所需的物理量子位元」從 2,000 萬一口氣砍到不足 100 萬。

「我們現在加密的，是今天的對手不能解、但明天的對手可以解的東西。」這句話，就是 PQC 一切緊迫性的源頭。

八、NIST 的八年抗戰與三份新標準

PQC 不是哪家廠商閉門造的，而是 NIST 用八年（2016–2024）舉辦的全球公開競賽選出來的。這段歷史值得一提，因為它解釋了為什麼「能換演算法」這件事如此重要。

競賽過程中發生過兩起震撼業界的「慘案」：原本進入決賽圈的 Rainbow（多變量密碼）在 2022 年被一台筆電在 53 小時內破解；同年 7 月，被看好的 SIKE（同源密碼）被兩位數學家用單核心電腦在一小時內攻破。SIKE 當時已走到第四輪、多家廠商開始試做整合——如果 NIST 早一年標準化它，所有先行者都得打掉重練。

這就是為什麼「密碼敏捷性（crypto-agility）」不是錦上添花，而是必備設計——沒有人能保證今天的贏家不會是明天的 SIKE。

2024 年 8 月 13 日，NIST 正式發布三份 PQC 標準：

設計策略是「格密碼為主、雜湊密碼為輔」——三個入選者裡有兩個是格密碼（效能與安全性最平衡），保留一個雜湊密碼作為「保險箱」：萬一格密碼將來出事，雜湊密碼的保守性是最後防線。（基於 Falcon 的 FN-DSA／FIPS 206 因浮點運算的側信道防禦較複雜，預計後續才發布。）

九、PQC 對 RWA 平台最現實的衝擊：不是速度，是大小

很多人以為 PQC 的代價是「運算變慢」。實際上 PQC 演算法的速度大多可接受，真正的衝擊是「位元組大小」：

簽章大 50 倍、公鑰大 30 到 80 倍——這對資料庫 schema、API payload、網路頻寬、HSM 內的金鑰存放，全都是實實在在的成本。一個有遠見的 RWA 平台，會在今天的資料庫設計裡就替簽章欄位預留足夠空間，並在每筆加密產出旁標記「這是用哪個演算法簽的」（業界稱為 Alg-ID Tagging 或 CBOM，密碼學物料清單）。不預留，未來切換時整套 schema 都要重做。

十、業界共識：先抽象、再混合、最後切換

面對量子威脅，2026 年的產業共識濃縮成兩個關鍵詞與一條路徑。

Hybrid（混合）：在過渡期同時使用古典演算法與 PQC 演算法，只要其中一個還沒被破，整個系統就還安全。例如 Cloudflare 從 2023 年起就在 TLS 1.3 部署 X25519 + ML-KEM-768 的混合金鑰交換。這同時提供了「萬一新演算法像 SIKE 一樣翻車」的保險。

Crypto-Agility（密碼敏捷性）：NIST 在 2025 年的白皮書 CSWP 39 把它正式列為核心設計原則。具體做法是讓應用程式透過抽象介面請求服務（「請幫我驗這個簽章」），而不是直接寫死呼叫某個演算法。這樣將來換演算法時，業務邏輯一行都不用改。

落地的優先順序也有共識：通信加密／金鑰交換（HNDL 風險最高）先做 → PKI 與證書其次 → 應用層簽章再次 → 對稱加密最後（反正升個 key 長度就好）。

值得注意的是，HSM 是這條路上最慢的一環——截至 2026 年初，還沒有任何 HSM 廠商把 PQC 演算法納入 FIPS 140-3 Level 3 的認證邊界內。這意味著即使硬體跑得動 PQC，合規層面也還不能用於需要 Level 3 的場景。所以正確的策略不是「等 HSM 廠商」，而是先讓自己的軟體層 ready——抽象介面先設計好、schema 先預留好，等硬體與標準成熟，再無痛切換。

十一、這不只是技術選擇，已經是合規要求

值得強調的是，PQC 在 2024–2026 之間完成了一個身分轉換：從「資安最佳實務」升級成「金融監理要求」。

• 美國：NSM-10 要求聯邦系統 2030 年前完成 PQC 遷移；SWIFT 也公告 2030 前完成跨行訊息加密的 PQC 遷移。
• 歐盟：DORA（數位營運韌性法案） 在 2025 年 1 月全面執行，其 Article 8 要求金融機構具備「系統切換能力」，被業界普遍解讀為包含密碼學切換能力；DORA 對在歐盟有業務的機構具有域外效力。
• 支付業：PCI DSS 4.0（2025 年強制執行）要求密碼學保護「能應對新興威脅」，被廣泛解讀為包含 PQC 準備。

對任何想跨境互通（與美國、歐洲、新加坡的金融基礎設施對接）的 RWA 平台來說，PQC 已經從「要不要做」變成「什麼時候做」。今天不準備，明天就可能在國際稽核與合規檢查時被擋下來。

結語：看不見，但撐住一切

RWA 把資產搬上鏈，讓人著迷的是那些看得見的創新——秒級結算、全球流動、24 小時不打烊。但讓這一切「值得信任」的，是兩塊看不見的基建：HSM 確保私鑰此刻安全，PQC 確保它三十年後依然安全。

一個有遠見的 RWA 平台，不會等量子電腦造好才動——它會在今天就把抽象介面與 schema 準備好，讓系統「將來能換」。這不是過度設計，這是金融基礎設施對「長期」二字應有的敬意。

延伸閱讀我這個系列的其他篇章：RWA 是什麼（總論）、合規型代幣標準：ERC-3643 vs ERC-1404，以及談監理的全球 RWA 監管地圖。如果你的團隊正在評估 RWA 的技術可行性，歡迎了解我的 技術顧問服務 與 Web3 企業內訓。

這篇文章，我想用最白話的方式，把 RWA 從頭講清楚——它是什麼、為什麼重要、市場有多大、台灣站在哪裡。這也是我整個 RWA 系列的入口。

一、RWA 到底是什麼？

一句話：RWA 就是把現實世界裡的資產，變成區塊鏈上可以持有、轉移、結算的代幣。

這些「現實資產」可以是黃金、債券、基金、股票、不動產、甚至一張碳權憑證。代幣化（tokenization）做的事情，就是替這些資產在鏈上發行一個「數位分身」——這個分身代表你對該資產的所有權，而且可以像加密貨幣一樣，24 小時、跨國界、秒級結算地流動。

其實你早就接觸過 RWA 最原始的形態：穩定幣。USDT、USDC 把「美元」這種現實世界資產表示成鏈上代幣，這正是最早、也最成功的 RWA。RWA 要做的，就是把同樣的邏輯，延伸到黃金、債券、基金這些更複雜的資產上。

二、為什麼資產要「上鏈」？

如果傳統金融運作得好好的，為什麼要大費周章把資產搬上區塊鏈？因為鏈上結算能解決幾個傳統金融積累已久的痛點：

• 結算速度：傳統證券交易普遍是 T+2（成交後兩個工作日才完成交割）。鏈上可以做到 T+0，甚至即時原子交割——買賣與付款在同一筆交易裡同時完成，沒有對手方違約風險。
• 降低門檻：一張百萬面額的債券，可以被切分成極小單位，讓小資族也能參與；不動產、私募基金這些「有錢人專屬」的資產，也因此可能向更多人開放。
• 自動化：配息、付息、到期贖回都可以寫進智能合約自動執行，省下大量中後台人工作業。
• 全球流動性：資產不再被綁在單一市場的營業時間裡，理論上可以接上全球的鏈上資金池。

這些不是技術炫技，而是金融基礎邏輯的改寫。

三、但「上鏈」沒那麼簡單

這正是 RWA 真正困難、也最有趣的地方。把比特幣轉給朋友很簡單，因為沒人管你是誰。但把一張真正受監管的債券放上鏈，你立刻會撞上一堵牆：

• 證券法要求發行人隨時知道持有人是誰——所以不能匿名轉帳；
• 法院可能要求凍結特定人的資產；
• 繼承、司法執行時，需要能強制轉移；
• 配息前需要對所有持有人做餘額快照。

這些是一般加密貨幣代幣（ERC-20）做不到的事。於是整個產業花了十二年，演化出專門為受監管資產設計的代幣標準——這段歷史我寫在 〈RWA 代幣化標準演進史〉，從 2014 年的 Colored Coins 一路講到今天成為機構首選的 ERC-3643 與 CMTAT。RWA 的本質，不是技術問題，而是「如何讓區塊鏈聽法律的話」。

四、全球市場有多大？

數字會說話：

• 截至 2025 年 9 月，全球代幣化 RWA 的總市值約 309 億美元；
• 光是 ERC-3643 標準下代幣化的資產就超過 320 億美元，橫跨 180 多個司法管轄區；
• BlackRock 的代幣化國債基金 BUIDL，從 2024 年 3 月推出到 2025 年 8 月，規模從零成長到超過 23 億美元；
• 麥肯錫預測，到 2030 年全球 RWA 市場規模將達到 2 到 4 兆美元。

當全球最大的資產管理公司（BlackRock）、最大的銀行（UBS、摩根大通）、最大的證券集中保管機構（美國 DTC）都在 2024–2026 年間相繼入場，RWA 已經從「加密圈的概念」變成「主流金融的基礎建設」。

五、五大資產類別

並不是所有資產都同樣適合代幣化。目前最主流的幾類，由易到難大致是：

1. 穩定幣（現金類）——最成熟，本質就是法幣的代幣化。
2. 債券——現金流明確、估值清楚，是機構最積極代幣化的標的。延伸閱讀：〈債券代幣化〉。
3. 基金——BlackRock BUIDL、Franklin Templeton BENJI 都屬此類。
4. 黃金與大宗商品——實體保管 + 鏈上憑證的組合，信任轉移是關鍵。延伸閱讀：〈黃金代幣化〉。
5. 股票與不動產——監管最複雜、但想像空間最大。

六、台灣站在哪裡？

台灣其實不算落後。2024 年 6 月，金管會宣布協同集保（TDCC）與多家金融機構成立「RWA 代幣化小組」，以債券與基金進行概念驗證，並在 2025 年完成期末實證報告，認定技術「實證可行」。

台灣有一個全球相對罕見的特點：由集保這個證券集中保管機構直接主導平台建置。這意味著基礎設施層面的保障較強。不過最大的缺口是穩定幣——沒有合規的新台幣穩定幣，鏈上的「券款對付」就難以完全實現。好消息是，台灣規劃最快在 2026 下半年隨《虛擬資產服務法》推出穩定幣框架。

我認為，2026 年正是台灣金融業的關鍵窗口：國際標準已經收斂、法規方向逐漸清晰、技術也驗證可行。剩下的，是誰能最快把這套國際語言，接上台灣自己的市場制度。

結語

RWA 不是又一個會泡沫化的加密熱詞。它的底層邏輯——讓資產 24/7 自由流動、即時結算、全球可驗證——指向的是一套更有效率的金融基礎設施。穩定幣是入口，RWA 是橋樑。

接下來，這個系列我會分別深入黃金、債券、合規標準與全球監管。如果你的團隊正在評估 RWA 的可能性，或想為組織建立 Web3 的知識基礎，歡迎了解我的 技術顧問服務 與 Web3 企業內訓。

這篇是我 RWA 系列的黃金篇。我會從黃金的金融屬性講起，帶你理解「黃金代幣化」真正在處理的，其實是一個信任轉移的問題。

一、黃金的雙重身分：準貨幣 + 商品

人類用黃金當價值儲存超過五千年。它稀有、可分割、不氧化、價值密度高，這些物理特性讓它在沒有銀行的年代就成為跨地域的通用貨幣。1971 年尼克森讓美元與黃金脫鉤後，黃金「不再是貨幣，但仍是準貨幣」——當通膨高漲、地緣政治緊張、股市崩盤時，資金就湧向黃金避險。

這個雙重身分，對代幣化有個關鍵影響：黃金既不是純粹的支付工具，也不是純粹的證券（沒有發行人、不付息），而是準貨幣 + 商品的混合體。這讓黃金代幣化的法規定位，反而比債券更尷尬——它可能同時觸及證券、銀行與虛擬資產三套法規。

二、實體到金融的三層光譜

「黃金」其實不是單一商品，而是一條從「最實體」到「最金融化」的光譜：

代幣化要找的，不是最左邊的實體金條（搬不動），也不是最右邊的衍生品（沒有實物），而是中間那一層——黃金存摺。

三、黃金存摺：台灣人最熟悉的「準代幣」

如果你在台銀、第一銀行或玉山銀行開過黃金存摺，你其實已經體驗過 RWA 的雛形。黃金存摺的本質是：你不持有實體黃金，但你的帳簿記錄代表你對實體黃金的權利。 銀行替你保管實體，你可以申購、贖回換現金、或提領實體。

台灣黃金存摺有兩個很在地的特徵：

• 計量用「台錢」（1 台錢 = 3.75 公克），而不是國際慣用的盎司。這是為了親民——散戶習慣問「一台錢多少錢」，跟銀樓用語一致。
• 純度 999.9（99.99% 純金），是台灣黃金存摺的標準。

把黃金存摺理解清楚，你就抓到了黃金代幣化的「上位概念」：所謂鏈上黃金，本質就是「黃金存摺的區塊鏈版本」——同樣對應實體，差別只在帳簿從銀行搬到了鏈上。

四、為什麼黃金「只能孿生，不能原生」？

這是黃金代幣化最重要、也最常被忽略的設計分野。

代幣化資產有兩種出身：

• 原生（native）：資產從第一天就在鏈上發行。債券可以這樣做——直接在鏈上發一檔新債。
• 孿生（twin）：鏈上代幣只是鏈下實體的「鏡像／證明」。

黃金必然是孿生的，不可能原生——因為實體黃金本來就躺在金庫裡，它不會憑空變成數位。所以黃金代幣化的核心動作永遠是一對：

• 鑄幣（mint）= 鎖住實體 + 發出代幣
• 銷毀（burn）= 燒掉代幣 + 解鎖實體

這對動作看似簡單，卻是整個信任架構的關鍵。因為它意味著——鏈上那枚代幣值不值錢，完全取決於「金庫裡真的有那塊金」這件事是否成立。

五、信任轉移：代幣化真正在解決的問題

這就帶到了核心。當你把黃金搬上鏈，你並沒有消除信任，你只是把信任從一個地方轉移到另一個地方。

傳統黃金存摺，你信任的是銀行：相信它金庫裡真的有對應的金、相信它不會超發。黃金代幣化之後，鏈上的轉帳、餘額、總量變得公開透明、即時可驗證——但有一件事鏈永遠無法自己證明：金庫裡到底有沒有那塊金。

這就是為什麼國際上每一個成功的黃金代幣，背後都站著一套「實體保管 + 定期審計 + 公開儲備證明」的機制：

• PAXG（Paxos Gold）：每一枚代幣對應一盎司存放於倫敦金庫、符合 LBMA Good Delivery 標準的實體金條，受紐約金融服務署監管，定期公布金條序號與審計報告。
• XAUT（Tether Gold）：對應實體金條，持有人甚至可以查詢自己對應的金條編號。

它們的共同點是：鏈解決了「流通」的信任，但「保管」的信任，仍然要靠受監管的託管方、實體審計與儲備證明來承擔。 代幣化沒有讓信任消失，它讓信任變得可以被切割、被驗證、被分層。

六、台灣做黃金代幣化的條件其實很好

回到台灣。我認為黃金是台灣 RWA 落地的好起點，原因有三：

1. 黃金存摺的基礎設施已經成熟——多家行庫經營多年，保管、純度、計量都有現成標準，代幣化等於替既有業務加一層鏈上帳本，而非從零打造。
2. 散戶熟悉度高——台灣人對黃金存摺、對「台錢」毫不陌生，教育成本低。
3. 法規觸及面雖廣但有跡可循——相比股票的公司治理問題，黃金的監管重點集中在「實體保管的真實性」與「投資人保護」，相對單純。

當然，挑戰也真實存在：誰來保管、由誰審計、如何向投資人證明儲備、鏈上交易與銀行端撥轉如何對帳——這些都是把黃金存摺真正搬上鏈時，必須一一回答的工程與制度問題。

結語

黃金代幣化的迷人之處，在於它把一個抽象的概念變得具體：RWA 從來不只是技術問題，而是「如何在數位世界裡，重建對實體的信任」。 鏈負責讓黃金 24 小時自由流動、即時交割、人人可驗證；而金庫、審計與監管，負責守住「那塊金真的存在」這個最後的信任錨點。

這個系列我也寫了另一篇從現金流角度切入的 〈債券代幣化〉，以及整個產業的 〈標準演進史〉。如果還沒讀過總論，建議從 〈RWA 是什麼〉 開始。

想為你的團隊建立 Web3 與 RWA 的完整知識基礎？歡迎了解我的 Web3 企業內訓課程 與 技術顧問服務。

這是我 RWA 系列的債券篇。我會從「債券到底是什麼」講起，帶你理解為什麼券款對付（DvP）是整件事的關鍵，以及台灣在這場賽局裡的位置。

一、債券就是一張「借據」

債券的本質一句話就能說完：借錢的人（發行人）給出錢的人（投資人）一張借據，承諾在到期日還本、在期間內定期付息。

任何一張債券，都由五個欄位定義：