12：TriClaw 設計藍圖 — 三隻貓、三個模型、一個自建 Router
上一篇說到，4/4 之後 OpenClaw 必須退役，方向定了：以 Claude Code 為主控，自建一個 session-router 直接控制三個模型的 CLI。
這一篇把設計藍圖攤開。動工之前先想清楚，是我從九次容器陣亡學到的事。
從合規倒推架構
這次架構的第一性原理不是技術，是合規：每一條模型通道，都必須是「官方工具＋官方認證」。
把市面上能用訂閱 OAuth 合法驅動的官方 CLI 排開，剛好三家：
- Claude Code（Anthropic OAuth）— 我的主力，Opus 品質所在
- Codex CLI（OpenAI OAuth）—
codex exec可以全自動跑任務 - Gemini CLI（Google OAuth）—
gemini -p一行派工
三條通道、三個模型、三種性格。這不是湊數，正好接上我在〈把 AI 當成真正的團隊成員〉寫過的需求：不同職責應該由不同的 Agent 承擔，而且最好彼此能互相制衡。
第三隻貓：青喵登場
黑喵和貓爪讀者都認識了。這次的新成員，是坐鎮 Claude Code 的主控——青喵（CyanMeow）。
分工照各模型的強項來：
| 成員 | 底層 | 職責 |
|---|---|---|
| 💠 青喵 | Claude Code | 主控：協調、品質把關、知識庫管理 |
| 🐾 黑喵 | Codex CLI | 開發：寫程式、Code Review、QA |
| 🔍 貓爪 | Gemini CLI | 研究：搜尋、資料蒐集、分析 |
過去雙貓時代有一個結構性問題：同一個模型自己審自己的作業，審不出自己的盲點。三個不同供應商的模型互相看彼此的產出，盲點才有機會被照到。這是 TriClaw 對我來說最重要的設計理由，重要性不亞於合規。
Router 而非 OS
session-router 是整個架構唯一要從零寫的東西。設計原則一句話：它是調度員，不是作業系統。
它只做四件事：
- Discord 入口：三個 bot 帳號掛在同一個 daemon 上，訊息進來辨識該找哪隻貓
- 路由與 spawn：把訊息轉成對應的 CLI 呼叫，帶上正確的工作目錄與環境
- 配額熔斷：每條通道有用量上限，撞線就熔斷，不讓單一通道燒穿訂閱額度
- 異常告警：CLI 掛了、回應逾時，發 Discord 通知我
同樣重要的是它不做的事：不管記憶、不管人格、不帶 UI、不做工具編排。這些要嘛交給各 CLI 自己的機制，要嘛交給檔案系統。Daemon 越小，4/4 那種「上游一變動就全身受制」的故事就越難在我自己身上重演。
技術選型用 Bun 寫 daemon、LaunchAgent 常駐，全部程式碼一個下午可以讀完。
記憶與人格：檔案就是真相
OpenClaw 時代記憶和人格是 Gateway 包辦的，搬走之後這塊要自己設計。原則：單一事實來源（SSoT），全部放檔案。
- 每隻貓一份 SOUL（人格）與 capabilities（職責）文件
- 共用層放架構、框架規則、CLI 呼叫規範
- 一支 sync 腳本把這些拼接好，寫進各 CLI 的指示檔（Claude 的 CLAUDE.md、Gemini 的 GEMINI.md、Codex 的 instructions）
檔案的好處是無聊：可以 diff、可以備份、可以在任何編輯器打開。被黑盒咬過之後，無聊就是優點。
移轉排程：給自己三個月
OpenClaw 不會直接斷電。計畫拆成三個 Gate：
- G6（5 月中）：router 與調度鏈路驗證，新舊系統並行
- G7（5 月中後）：Discord 入口正式切換到 daemon
- G8（6 月中）：OpenClaw 完整封存——tarball 打包加 rollback 視窗，七月中才算完全解除
從現在算起大約三個月。穩一點，畢竟這套系統現在每天都在上工。
計畫是這樣寫的。實際發生的事，下一篇說。
Build Log 系列
← 上一篇：11：4/4 斷接之日 — OpenClaw 退役的真正原因
下一篇：13：Sunset 之日 — 原定三個月的移轉，一天做完 →
