標籤: Multi-Model Orchestration

  • 80人AI腦子系統實戰建置:從0到上線的16個步驟

    重點摘要(TL;DR)

    • 把 80 人 AI 腦子系統從 0 蓋起來,共 5 個 Phase、16 個 Step、約 16 週。本文逐步拆解每一步的目標、動作、產出、坑。
    • 每一步都用四維框架檢查:安全(不洩漏)、穩定(不掛)、累積(知識變資產)、好用(員工願意用)。任何一步如果四維都不過,就砍掉。
    • 核心心法:物理保證 > 規則約束、拉力 > 推力、先粗版再精修、安全在前但好用不能放最後
    • 順序很重要,不能跳步。例如沒有 Step 6(分級對應表)就做 Step 9(Gateway),Gateway 規則沒依據;沒有 Step 12(Curator)就累積知識,3 個月後變垃圾堆。
    • 本文是《80人公司的AI腦子系統:從個人腦擴展到全公司不洩密的工程設計》的實作續篇。前篇講為什麼,本篇講怎麼做。

    為什麼要從「順序」談起

    很多公司導入 AI 治理失敗,不是技術不行,是順序錯了。常見錯誤:

    • 先買 Gateway 軟體,再去定資料分級 → 規則沒依據,Gateway 變裝飾
    • 先請大家寫 brain markdown,沒有 Curator 制度 → 3 個月後變過期文件墳場
    • 先做華麗 Dashboard,沒有 audit log 來源 → KPI 是亂編的
    • 先全公司鋪開,沒先試點 → 第一週體驗不好,80 人對系統信任歸零,救不回來

    本文每個 Step 都標「為什麼是這個位置」,讓你看完知道哪些可以平行、哪些必須串行。

    四維檢查框架

    每個 Step 都要回答四個問題。如果一個 Step 四維都打不到 ≥1 分,就砍掉 — 是 nice-to-have,不是 must-have。

    維度 問題 具體判斷
    🔒 安全 這步降低洩漏面積嗎? A 級資料更不會出去?稽核能找到證據?
    🛡️ 穩定 這步可用性夠嗎? 壞了能降級?有災難回復?HA?
    📚 累積 這步留下了什麼長期資產? 員工離職還在?可審計?可移交?
    😊 好用 員工這步以後生活更好嗎? 少打字?少切視窗?少等待?少抱怨?

    Phase 0:基礎準備(W0–W2)

    不要先動程式碼。先把組織結構知識容器建好。

    Step 1 — 召集 Working Group(W0,3 天)

    • 目標:讓 5-7 人(準 CISO + 法務 + IT + 3-4 部門 senior + 老闆 sponsor)成為這套系統的第一批決策者
    • 動作:第一次會議 60 分鐘,議程:同步為什麼要做、確認名單、排定 Phase 0 清單會議、訂下兩週一次例會
    • 產出:一份 working group 章程文件、會議紀錄、共享日曆
    • 四維:🔒 ✅(分級權威來源)、🛡️ —、📚 ✅(決策歷史可追)、😊 ✅(員工知道有人扛責)
    • 常見坑:老闆不到場 → 後面拍板沒人敢動;法務一個人說了算 → 後面所有東西判 A 級

    Step 2 — 建立雙 Repo(W1,2 天)

    • 目標:把「公司腦」和「個人腦」變成兩個物理上分離的 git repo
    • 動作:在公司 GitHub Org 建 company-brain(private)、發給每位員工一份 personal-brain template(github classroom 或 cookiecutter)
    • 產出:兩個 repo + README 說明使用方式 + .gitignore 範本
    • 四維:🔒 ✅✅(個人腦永不 push 中央=物理保證)、🛡️ ✅(git 提供版本+回復)、📚 ✅(每筆變更有 PR)、😊 ✅(員工用熟悉的 git workflow)
    • 常見坑:個人腦放公司 GitHub 而不是員工自己的 → 隱私保證失效;沒有 .gitignore 擋掉 .env / 密碼檔 → 第一週就有人 commit 進去

    Step 3 — Iron Rules v0(W1-W2,1 週)

    • 目標:寫下 3-5 條全公司必守的紅線,變成 company-brain/global/CLAUDE.md
    • 動作:Working Group 開 1 次會議,每個人提 5 條,合併成 3-5 條全體共識
    • 範例:「禁止把客戶合約原文送雲端 LLM」「Bug log 進公司腦前必須脫敏」「所有 brain 修改必須走 PR」
    • 產出:CLAUDE.md v0 commit 進 company-brain/global/
    • 四維:🔒 ✅(底線設定)、🛡️ —、📚 ✅(規則進 git)、😊 ✅(規則少而清楚 > 50 條沒人記)
    • 常見坑:寫成 30 條 → 沒人記得住;寫太抽象(「做正確的事」)→ 不能執行

    Phase 1:同步機制(W3–W4)

    讓「腦子」能流到員工每個 AI 工具。不寫 Gateway,先解決 build & sync

    Step 4 — build.sh 中性編譯器(W3,3-5 天)

    • 目標:一個 script 把 markdown 編譯到所有 AI 工具的格式
    • 動作:寫 bash / Python script,輸入 company-brain/ + personal-brain/,輸出:
      • .claude/CLAUDE.md(Claude Code / Desktop)
      • .cursor/rules/*.mdc(Cursor)
      • .github/copilot-instructions.md(Copilot)
      • ~/chatgpt-system-prompt.md(ChatGPT 用 Custom GPT 貼用)
    • 關鍵設計:每個 brain 檔的 frontmatter 加 tools: [claude, cursor, copilot, gpt],編譯時依目標 model 過濾
    • 產出:可執行的 build.sh + 4-5 種工具的編譯範例
    • 四維:🔒 ✅(可依工具過濾敏感腦)、🛡️ ✅(編譯失敗有錯誤訊息)、📚 ✅(中性格式不被工具鎖死)、😊 ✅✅(員工不用學新格式)
    • 常見坑:編譯太久 → 員工不願意每天 build,設成 git pre-push hook 自動跑

    Step 5 — 種子部門試跑(W4,1 週)

    • 目標:挑 10-15 人的部門(通常是 RD)當第一批用戶,真實流量驗證 Phase 0+1
    • 動作:每天收 1 次回饋(短 Slack 頻道)、每週 1 次 30 分鐘 retro 會議、補 brain
    • milestone:第一週結束,company-brain 有 ≥10 筆 brain markdown(由種子用戶產出)
    • 四維:🔒 —、🛡️ ✅(早期發現問題)、📚 ✅(brain 種子)、😊 ✅(早期使用者教其他員工)
    • 常見坑:挑錯部門 → 行政部根本不寫 brain;挑太大部門 → 回饋處理不過來。挑用 AI 最多的小團隊

    Phase 2:分級與脫敏(W5–W8)

    這是整個系統的核心。沒這 Phase,後面 Gateway 全是空殼。

    Step 6 — 分級對應表 v0.1(W5-W6,2 週)

    • 目標:列出 50-100 種公司會接觸的資料類型,粗分 A/B/C
    • 動作:Working Group 兩次會議,每次 90 分鐘,一次處理 30 種
    • 產出:company-brain/global/data-classification.md 表格化,進 git 管理
    • 原則:不糾結邊界 → 先有 v0.1 → Phase 2 試點時精修
    • 四維:🔒 ✅✅✅(整套架構的權威來源)、🛡️ —、📚 ✅✅(可審計、可移交)、😊 —(員工目前還用不到,但是後續所有 UX 的基礎)
    • 常見坑:法務說「不確定就 A 級」→ 後續 Gateway 90% 流量被擋,系統失效。**邊界 case 預設 B 級**(脫敏後可送雲),不是 A 級

    Step 7 — 脫敏字典 v0(W7,5 天)

    • 目標:三份純文字字典,擋掉 80% 紅字
    • 動作:從 CRM / HR / 專案系統匯出
      • client_names.txt(客戶公司名 + 簡稱)
      • employee_names.txt(員工姓名 + 暱稱 + Slack ID)
      • project_codes.txt(內部專案代號、產品代號、合約格式 regex)
    • 產出:三份 .txt + 每月由 HR / PM 維護的責任分配
    • 進階(可選):接 Microsoft Presidio v2.2.362(2025/3 釋出,2026/5 仍是最新版)當第二層補強。Presidio 是開源 PII 脫敏框架,內建 NER + regex + checksum,支援多語言,還有 image redactor 處理 DICOM 醫療影像。字典擋已知字、Presidio 擋通用 PII(信用卡、身分證、地址等),兩層疊加。
    • 四維:🔒 ✅✅(一次擋掉 80% 洩漏)、🛡️ ✅(純文字,壞不掉)、📚 ✅(離職員工從字典移除有歷程)、😊 ✅(員工不用記哪些字是紅字)
    • 常見坑:字典放 git 中 → 字典本身就是敏感資料(客戶 list)。要放另一個 access-controlled repo,build.sh 用 SSH key 拉

    Step 8 — Pre-commit Hook + Browser Extension MVP(W8,1 週)

    • 目標:在員工提交 brain 時、貼資料到網頁版 LLM 時,第一道防線
    • 動作:
      • Pre-commit hook(.git/hooks/pre-commit):掃 staged 檔案,字典命中就 block commit
      • Browser Extension(Chrome/Edge):偵測 chat.openai.com / claude.ai 的 paste 事件,字典命中跳警告 + 自動替換
    • 產出:兩個工具 + 內部 IT 自助安裝頁
    • 四維:🔒 ✅✅(防呆,擋住 80% 「員工懶得開 IDE」場景)、🛡️ ✅(本地執行,不 break 工作流)、📚 —、😊 ✅(警告比阻擋友善)
    • 常見坑:Pre-commit 跑太慢(掃整個 repo) → 員工 git commit --no-verify 繞過。**只掃 staged diff**,< 1 秒

    Phase 3:Gateway 上線(W9–W16)

    這是工程量最大的 Phase。前面都做完才有意義。

    Step 9 — LLM Gateway 骨架(W9-W11,3 週)

    • 目標:用開源 AI Gateway 做基礎,偽裝 Anthropic / OpenAI API。2026 主流選擇:LiteLLM(unified API 到 100+ providers)、Portkey(內建 guardrails + PII redaction + observability)、Kong AI Gateway。企業常見組合是 LiteLLM 當 proxy + Portkey 做 observability
    • 動作:
      • 架 LiteLLM 在內網(Docker),或用 Portkey self-host
      • 第一版只做 proxy + audit log,不做分級
      • 讓種子部門切過來:ANTHROPIC_BASE_URL=https://company-llm.internal/v1
    • 產出:可用 Gateway + audit log 進 SIEM + 每日 throughput 報告
    • 四維:🔒 ✅(流量集中)、🛡️ ✅✅(HA + 健康檢查)、📚 ✅✅(全程 audit)、😊 ✅(員工只改一行設定)
    • 常見坑:沒做 HA,Gateway 掛 = 80 人不能工作。**第一天就要 HA**,或備用 endpoint 自動切換

    Step 10 — 三層漏斗實作(W12-W14,3 週)

    • 目標:在 Gateway 內加分級 + 路由邏輯
    • 動作:
      • Layer 1:Aho-Corasick 演算法搜字典(< 5ms)
      • Layer 2:fine-tune 小模型做分類(BERT、Qwen3 1.7B、Llama 3.2 3B 都可),0.1-0.3s
      • Layer 3:fail-safe 全部判 B 級走脫敏 + 雲端
    • 產出:三層命中率分布 dashboard
    • 四維:🔒 ✅✅✅(自動分級)、🛡️ ✅(每層獨立可降級)、📚 ✅(每筆分類有紀錄)、😊 ✅(員工無感)
    • 常見坑:一開始就追求 Layer 2 LLM 完美 → 永遠上不了線。**先 Layer 1 + Layer 3 兩層上線**,Layer 2 之後加

    Step 11 — 雙引擎接入(W15-W16,2 週)

    • 目標:把雲端 frontier 和本地頂級開源模型都接進 Gateway
    • 動作:
      • 雲端:簽 Anthropic Enterprise(Claude Opus 4.7)、Azure OpenAI(GPT-5.5)、AWS Bedrock(多家)、Google Vertex AI(Gemini 3.1 Pro)。要 DPA + zero data retention 條款。2026 主流是「routing by task type」:Opus 4.7 跑 multi-file coding、GPT-5.5 跑 terminal/browser、Gemini 3.1 Pro 跑 long-context research。
      • 本地:架 Ollama 或 vLLM(production 用 vLLM,2-4x 並發)+ Qwen3-Coder-Next(80B 總參 / 3B active,MoE,256K context)或 Qwen3.6,給 A 級任務專用。MoE 架構讓消費級 GPU 可跑。
      • Gateway 路由規則:A 級 → 本地、B 級 → 脫敏 + 雲端、C 級 → 直接雲端,並依任務型別選最適合的雲端模型。
    • 產出:完整雙引擎可用、第一張月度安全報告(攔了多少 A 級)
    • 四維:🔒 ✅✅✅(A 級永不出去)、🛡️ ✅(雲端掛了本地頂)、📚 ✅(成本/用量數據)、😊 ✅(員工拿到 frontier 能力)
    • 常見坑:用個人帳號的 Claude / GPT → ISO 27001 第三方供應商不過。**必須 Enterprise 合約有 DPA**,費用貴 30-50% 但這是硬門檻

    Phase 4:治理機制(W13+,與 Phase 3 並行)

    沒這個 Phase,brain 會在 6 個月內變垃圾堆。Gateway 蓋好但沒 KPI,3 個月後沒人知道有沒有效。

    Step 12 — Curator 制度(W13,2 週啟動)

    • 目標:每個 team 一個 Curator,有權合併 / 刪除 brain
    • 動作:
      • 挑選:每 team 一個 senior(自願 + 部門主管同意)
      • 授權:GitHub team admin 權限 + 每週 1 小時 review brain PR
      • 儀式:每季全公司「腦子健檢日」,半天清掃過時 brain
    • 產出:Curator list + review SLA(PR 5 個工作天內處理)
    • 四維:🔒 ✅(防止劣化)、🛡️ —、📚 ✅✅✅(知識保鮮)、😊 ✅(垃圾不會堆)
    • 常見坑:Curator 沒被分配時間 → 永遠不 review。**1 小時/週要正式排進 KPI**,不是「有空就做」

    Step 13 — KPI Dashboard(W14-W16,3 週)

    • 目標:把 North Star + 四象限 KPI 變成可看的 dashboard
    • 動作:
      • 串 Gateway audit log → Grafana / Metabase / 自寫
      • 串 firewall log → 偵測網頁版 LLM 流量
      • 串 git activity → 計算 brain 增長率
      • 每月例會看「3 個問題」:North Star、Top 3 繞過原因、安全收益
    • 產出:每月 dashboard + 月報自動產生
    • 四維:🔒 ✅(可量測)、🛡️ ✅(早期警告)、📚 ✅(歷史趨勢)、😊 ✅(高層願意持續投資)
    • 常見坑:做太多指標(20+)→ 沒人看。**只看 5-7 個**,北極星 + 四象限就夠

    Phase 5:長期演進(M5+,持續)

    系統上線後不是結束。三件事要持續做。

    Step 14 — ISO 對應與稽核準備(M5-M6)

    • 目標:把 Step 1-13 的產出對應到 ISO 27001 / 42001 控制措施
    • 動作:
      • 產出 iso-mapping.md:每條 ISO 控制措施 → 對應的 Step + 證據(git log / Gateway log / Dashboard)
      • 第一次內部稽核(找外部顧問跑一遍)
      • 修正稽核發現的 gap
    • 產出:ISO 對應表 + 稽核 readiness 報告
    • 四維:🔒 ✅✅(對外背書)、🛡️ ✅(壓力測試)、📚 ✅✅(合規資產)、😊 —(這 Phase 員工不會直接受益,但對外贏單時受益)
    • 常見坑:把稽核當一次性活動 → 證書到手就鬆懈,3 年後重審手忙腳亂。**Dashboard 要持續跑**,稽核資料 90% 自動產出

    Step 15 — 第二批工具支援(M5+)

    • 目標:涵蓋第一批沒處理的工具
    • 動作:
      • ChatGPT 透過 Custom GPT Action 串 Gateway HTTP API
      • 移動端 Claude / ChatGPT app(只能靠規則 + 教育,管不到)
      • n8n / Dify / 自建 workflow 接 Gateway
    • 四維:🔒 ✅(更多入口受控)、🛡️ —、📚 ✅、😊 ✅(更多員工享受到拉力)

    Step 16 — 過時知識淘汰機制(M6+)

    • 目標:防止 brain 累積成考古學遺址
    • 動作:
      • 每筆 brain 加 last_verified: 2026-05 frontmatter
      • 用量遙測:90 天無 reference 的 brain 自動標 stale: true
      • 每季 Curator 審 stale list,合併 / 刪除 / 更新
    • 四維:🔒 —、🛡️ ✅(防誤用過期知識)、📚 ✅✅(品質才是知識的本質)、😊 ✅(搜尋更準)

    16 Step 全景表

    Phase Step 時程 產出 主導
    0 基礎 1 Working Group W0 章程 + 例會 準 CISO
    0 基礎 2 雙 Repo W1 git repo x2 IT
    0 基礎 3 Iron Rules v0 W2 CLAUDE.md Working Group
    1 同步 4 build.sh W3 編譯器 RD
    1 同步 5 種子部門試跑 W4 ≥10 brain 部門主管
    2 分級 6 分級對應表 v0.1 W5-W6 A/B/C 表 Working Group
    2 分級 7 脫敏字典 v0 W7 三份 .txt HR + PM
    2 分級 8 Pre-commit + Browser Ext W8 兩個工具 RD
    3 Gateway 9 Gateway 骨架 W9-W11 LiteLLM 上線 RD
    3 Gateway 10 三層漏斗 W12-W14 分級+路由 RD
    3 Gateway 11 雙引擎接入 W15-W16 本地+雲端 RD + 法務(合約)
    4 治理 12 Curator 制度 W13+(並行) Curator list + SLA 部門主管
    4 治理 13 KPI Dashboard W14-W16 月報 準 CISO + RD
    5 演進 14 ISO 稽核準備 M5-M6 對應表 準 CISO
    5 演進 15 第二批工具 M5+ ChatGPT etc. RD
    5 演進 16 知識淘汰 M6+ stale 機制 Curator

    關鍵心法:這 16 步背後的設計原則

    1. 安全在前,但好用不能放最後

    Phase 0-2 都在做安全基礎設施,但每個 Step 的「好用」維度都要 ≥1 分。**安全是必要不充分,沒有好用的安全系統會被員工繞過,等於沒做**。Step 4 的 build.sh、Step 8 的 Browser Extension,都是「安全 + 好用」並重的範例。

    2. 物理保證 > 規則約束

    能用 git 結構保證的(Step 2 雙 Repo),不要靠政策文件。能用 Pre-commit hook 自動擋的(Step 8),不要靠員工自律。能用 Gateway 路由強制的(Step 11),不要靠規範。**規則會被忘記,結構不會**。

    3. 拉力 > 推力

    Step 11 雲端 frontier 接入是「拉力」核心 — 員工為什麼選 Gateway 不選網頁版?因為 Gateway 給他 frontier model + 公司腦自動注入 + 速度更快,**而且不用自己付費**。讓 Gateway 比網頁版好用,員工自然不繞過。

    4. 先粗版上線,真實流量精修

    Step 6 分級表 v0.1、Step 7 字典 v0、Step 9 Gateway 骨架都明確標 v0 / 骨架。**等想清楚才上線 = 永遠不上線**。Phase 2 試點 4-6 週收斂的速度,比關門想 6 個月快 10 倍。

    5. 治理機制與技術建設並行

    很多公司先蓋 Gateway 再想 Curator,結果 Gateway 上線 6 個月後 brain 變垃圾堆。Step 12 Curator 在 W13 啟動,**和 Step 13 KPI Dashboard 並行**,因為 brain 累積速度從 Phase 1 試點就開始,治理不能等。

    常見問題

    16 週太長,3 個月能上線嗎?

    可以,但要砍 Phase 3+4。「3 個月版」=Step 1-8 + 簡化版 Gateway(只做 proxy + audit log,不做分級),Phase 4 治理機制延後。**重點是先把基礎(雙 Repo + 分級表 + 脫敏字典 + 種子部門)立起來**,Gateway 可以 v0.5 上線、v1.0 慢慢迭代。

    16 步可以跳哪幾步?

    可跳:Step 8(Browser Ext)、Step 15(第二批工具)。 不可跳:Step 1(Working Group)、Step 6(分級表)、Step 12(Curator)— 跳了系統會壞。 可緩:Step 14(ISO 稽核)— 等系統穩定再啟動。

    一個人(全職)能撐多少?

    • Phase 0-2(8 週):一個人可獨立完成,主要是文件 + 字典 + 簡單 script
    • Phase 3 Gateway(8 週):**要 1.5-2 個 RD**,因為要做 HA + 規則層 + 雲/本地對接
    • Phase 4-5(持續):0.5 個 RD + 0.3 個 CISO 角色就能維護
    • **最低配置:1 個全職 RD + 1 個準 CISO 兼職,跑 4 個月**

    沒有 ISO 認證需求,還要做這套嗎?

    要,只是 Step 14 可以跳。這套架構即使不認證 ISO,**對「accumulating domain knowledge」「員工生產力」「資安基線」三件事**都有獨立價值。ISO 是副產品,不是目的。

    結語:安全 / 穩定 / 累積 / 好用,缺一不可

    大部分企業 AI 治理失敗,不是某一維崩了,是四維沒有平衡:

    • 只要安全 → 員工地下繞過 → 安全也沒了
    • 只要穩定 → 沒有治理 → 半年後變垃圾堆
    • 只要累積 → 沒有 Gateway → 客戶資料外流
    • 只要好用 → 沒有分級 → 一夕事故

    這 16 步的順序,就是「四維平衡的最小可行路徑」。每一步都至少打中兩維,串起來就是一個能跑、能審、能成長、員工願意用的系統。

    第 0 週要做的事只有一件:打開行事曆,把 Step 1 的 Working Group 第一次會議排進去。其他 15 步都會跟著動起來。

    延伸閱讀:《80人公司的AI腦子系統:從個人腦擴展到全公司不洩密的工程設計》 — 講為什麼這樣設計、雙引擎本地+雲、能管 vs 不能管的邊界、拉力哲學。本文是它的實作續篇。

    2026/5 技術棧時間戳

    本文 Step 9-11 涉及的具體工具版本以撰文時間為準:

    • Gateway:LiteLLM(open source)、Portkey(內建 guardrails + PII redaction + 1600+ LLM)、Kong AI Gateway。企業常見組合 LiteLLM + Portkey 雙搭。
    • 本地 LLM:Qwen3-Coder-Next(80B-A3B MoE,256K context)、Qwen3.6、Kimi K2.6、DeepSeek V4、Llama 3.3 70B。Ollama 為日常 default,production 並發推 vLLM V1。
    • 雲端 frontier:Claude Opus 4.7(2026/4)、GPT-5.5(2026/4)、Gemini 3.1 Pro、DeepSeek V4。各家擅長領域不同,「routing by task type」是 2026 主流架構。
    • PII 脫敏:Microsoft Presidio v2.2.362(2025/3 釋出,2026/5 仍是最新版),含 image redactor + DICOM 支援。
    • 合規認證:ISO/IEC 42001:2023(目前唯一可認證的 AI 管理系統標準)。Schellman、TÜV SÜD、BSI、DNV 都是合格認證機構。
  • 80人公司的AI腦子系統:從個人腦擴展到全公司不洩密的工程設計

    重點摘要(TL;DR)

    • 把個人「腦子系統」(CLAUDE.md + brain markdown + skills)擴展到 80 人公司,核心不是技術,是畫清楚「能管」和「不能管」的邊界
    • 架構=雙 Repo(公司腦+個人腦)+ LLM Gateway 中間人 + 雙引擎(本地 model + 雲端 frontier)。員工感受不到分級存在,系統默默路由。
    • 分級判斷用三層漏斗:regex 5ms 攔 90%、小型分類器 300ms 攔 9%、保守 fail-safe 1%。不要員工自選,他們不可能每次選。
    • 「拉力 > 推力」:讓 Gateway 比網頁版 ChatGPT 好用,員工自然不繞過。唯一最重要的 KPI 是「Gateway request 數 ÷ (Gateway + 偵測到的網頁版流量)」
    • 真正的雙贏:傳統 IT 做永遠改不完的 UI,客戶都嫌不好用。AI 時代轉做「給 AI 安全取資料的入口」,客戶用自己愛的 AI 工具,RD 回去做 ISO、審核、累積 domain knowledge。

    緣起:為什麼個人腦子系統撐不住 80 個人

    過去一年,我在自己的多台電腦之間累積了一套「腦子系統」。它由四件東西組成:全域規則(CLAUDE.md)、領域知識庫(brain markdown,例如 OSGi 踩坑、Kafka 注意事項、Shopee API 陷阱)、可重用的能力包(skills)、自動記憶(MEMORY.md + 各種 user/project/feedback 檔)。同步靠 git repo,個人用 100 分。

    但當需求變成「給一間 80 人公司用,讓所有人都能累積知識、快速成長、自行用 AI 開發小工具,並且不限定 Claude Code,可能員工 A 用 Claude、B 用 Cursor、C 用 ChatGPT」,個人架構幾乎所有環節都會崩。本文把整套放大設計鉅細靡遺寫下來,讓 RD 或 IT 主管可以直接拿去當藍圖。

    你以為的「腦子」其實是四層

    先把概念釐清。很多人講「AI 腦子」其實是把四件不同的東西黏在一起,擴展時要分開看待:

    內容 載體 擴展邏輯
    規則層 Iron Rules、語言、Git 流程、安全紅線 CLAUDE.md / .cursorrules 全公司一致,變動少,PR review 嚴管
    知識層 領域踩坑、API 陷阱、業務眉角 brain/*.md 分部門、分主題、有 curator 治理
    能力層 可重用 skill、自動化腳本、模板 skills/, plugins 員工貢獻 + PR + 用量遙測
    記憶層 個人偏好、進行中工作、context MEMORY.md / 個人 .md 永遠留個人,不上中央

    這四層的擴展方式不一樣。規則層是法律,知識層是百科,能力層是函式庫,記憶層是日記。設計時要分開,不能當一坨處理。

    擴展前必須先回答的三個問題

    不要直接跳進畫架構圖。先把這三題定義清楚,不同答案會走到完全不同的系統。

    Q1:「同時使用」是什麼意思?

    • (a) 員工各挑工具,讀同一份共用知識 ✅ 正確答案,可實作
    • (b) 同一任務同時派 Claude + GPT 工作 ❌ 反模式,幾乎沒實用場景

    Q2:員工貢獻知識的開放程度?

    實務建議:opt-out(預設進公司腦,標記私人才留個人),特別是 bug 經驗 — 踩過的坑是最有價值的共享資產。但 opt-out 強制要配「自動脫敏管道」,不然 raw bug log 一進公司腦就帶四種污染:客戶名、訂單 ID、同事名、合約號。

    Q3:資料敏感度怎麼分?

    分級 例子 處理方式
    A 紅 客戶合約、財務數字、員工個資、未公開合作案 嚴禁所有雲端 AI,只能本地 LLM
    B 黃 bug log、客戶踩坑、商務邏輯、process 設計 脫敏後可送雲端
    C 綠 純技術問題、開源元件、公開文件 直接送雲端 frontier model

    務實話:不要追求 100% 不洩漏,要追求「降低洩漏面積」。100% 在 80 人團隊中不存在,追下去會做出沒人用的合規劇場。

    架構藍圖:雙 Repo + LLM Gateway + 雙引擎

    ┌─ 公司腦 repo (private GitHub Org) ─────────────────┐
    │  global/    Iron Rules(PR + 2 reviewer 才能改)      │
    │  teams/                                              │
    │    backend/  brain/* skills/*                        │
    │    frontend/ ...                                     │
    │  shared/skills/  跨部門通用 skills                   │
    │  build/    編譯器:MD → 各工具格式                    │
    │  redact/   自動脫敏規則 + 字典                       │
    └──────────────────────────────────────────────────────┘
                  │ git pull (每天自動)
                  ↓
    ┌─ 員工本機 ─────────────────────────────────────────┐
    │  公司腦/  ← clone 自上面                            │
    │  個人腦/  ← 自己的另一個 repo,永遠不 push 中央       │
    │  build.sh 把兩者編譯到所有工具:                      │
    │   → .claude/CLAUDE.md  (Claude Code/Desktop)        │
    │   → .cursor/rules/     (Cursor)                     │
    │   → .github/copilot-instructions.md (Copilot)       │
    │   → ~/chatgpt-prompt.md (給 Custom GPT 貼用)        │
    └──────────────────────────────────────────────────────┘
                  │ HTTP / MCP
                  ↓
    ┌─ 公司內網 LLM Gateway ─────────────────────────────┐
    │  攔截 → 分級 → 脫敏 → 路由 → 串流回應                │
    │  本地 Ollama (A 級任務專用)                         │
    │  雲端 frontier (B/C 級脫敏後)                       │
    │  審計 log → SIEM                                    │
    └──────────────────────────────────────────────────────┘

    為什麼是「公司腦 + 個人腦」兩個 repo

    • 員工本機把兩個 repo clone 在一起,build.sh 編譯時個人腦覆寫公司腦(個人偏好優先)
    • 個人腦本機 commit,永遠不 push 到中央 — 這就是「自己選擇要不要上」的物理保證
    • 要分享某筆個人筆記時,員工自己 git mv 進公司腦發 PR
    • 「不上傳」變成預設物理行為,不是靠規則約束

    關鍵概念釐清:Brain ≠ Model

    很多人問「為什麼一定要雲?所有人都用本地 model 配腦子就好了啊?」這個直覺方向是對的,但前提是要把兩件事拆開:

    概念 是什麼 耗 GPU? 在哪
    Brain(腦子) Markdown 文件、規則、踩坑紀錄 ❌ 完全不耗 都本地(git repo)
    Model(推理引擎) LLM(Claude / Qwen / Llama) ✅ 很耗 看你選

    腦子永遠該全本地,這沒有爭議 — 它就是 markdown 檔。爭議只在 model 要不要本地。所以真正的問題是「為什麼推理引擎要用雲」。

    為什麼不能「全本地 model」— 三個誠實的事實

    1. 能力差距是真實的

    2026/5 現況:本地頂級開源這一年大幅追上 — Qwen3-Coder-Next(80B 總參 / 3B active,MoE 架構,256K native context)已能跟 Claude Code、Cline、OpenCode 等 coding agent 直接整合;Qwen3.6、Kimi K2.6、DeepSeek V4是 2026/4 的 open-weight 第一梯隊。MoE 架構讓 80B 總參只啟動 3B per token,消費級硬體加量化可跑。但跟 frontier 雲端(Claude Opus 4.7(2026/4)、GPT-5.5(2026/4)、Gemini 3.1 Pro、DeepSeek V4)比,在 long-context agentic、跨檔案 reasoning、tool orchestration 上還是差一個檔次。差距比一年前縮小很多,但沒抹平。

    2. 80 人「全本地」的硬體成本

    • 中央 inference server(8x A100 80GB):採購百萬人民幣級別 + 機房 + 維運,80 人並發要排隊
    • 每人一台 Mac Studio M3 Ultra 192GB:採購 44 萬美金,出差不能用
    • 對比 80 人用 Claude/GPT API:每人每月 $50-200 美金,年成本 5-20 萬美金
    • 雲端在中小公司階段便宜一個量級

    3. 強制全本地會把員工逼地下

    能力不夠 → 員工抱怨 → 私下偷貼資料到 ChatGPT。把人逼到地下,比讓他在地上用更糟。雲端 ≠ 資料變成 OpenAI 訓練資料,Enterprise 合約(Azure OpenAI / AWS Bedrock / Anthropic Enterprise)是另一回事。

    真正的答案:Local-first, Cloud-when-needed(雙引擎)

    員工的 prompt
        ↓
    ┌─ 本地閘門 (Qwen3-Coder-Next / Qwen3.6) ─────┐
    │  1. 偵測敏感度(A/B/C 級)                     │
    │  2. A 級:本地 model 直接處理,不出去           │
    │  3. B 級:自動脫敏後送雲端                     │
    │  4. C 級:直接送雲端                           │
    └──────────────────────────────────────────────┘
        ↓ (B / C 級才會到這)
    ┌─ 雲端 frontier model ────────────────────────┐
    │  Claude Opus 4.7 / GPT-5.5                  │
    │  Gemini 3.1 Pro / DeepSeek V4               │
    │  各家擅長領域不同,Gateway 依任務型別路由       │
    └──────────────────────────────────────────────┘

    這才是「資料安全」和「員工生產力」雙贏的解。全雲洩漏 A 級、全本地犧牲 B/C 級體驗,雙引擎才永續

    LLM Gateway:員工感受不到的中間人

    員工不可能每次手動選分級,要他們按 🟢🟡🔴 三天就沒人用了。正確做法是系統默默判,員工不感知。員工的 IDE / Claude Code / Cursor 不直接連雲端 API,改連公司內網的 Gateway:

    員工的設定只有一行:
    ANTHROPIC_BASE_URL=https://company-llm.internal/v1
    
    之後做什麼都不變。Cursor 還是 Cursor,Claude Code 還是 Claude Code。

    Gateway 的三個職責:

    職責 在做什麼 用什麼
    分級 判 A / B / C Regex + 本地小型 LLM 分類器
    脫敏 B 級資料抽掉客戶名/同事名/合約號 字典 + regex + 本地 LLM 補刀(Microsoft Presidio 可借力)
    路由 送本地還是送雲端 規則引擎

    三層漏斗:5ms 路由掉 90% 流量

    不是「每個 prompt 都過 LLM 判」,那會塞爆。是三層漏斗:

    1. Layer 1:Regex / 字典比對(< 5ms,攔 90%)
      • 含「大有建設」/「老王」/合約號格式 → 紅,本地
      • 純英文技術詞、無中文人名地名 → 綠,雲端
      • 命中就路由,不過 LLM
    2. Layer 2:小型分類器(0.1-0.3 秒,攔 9%)
      • 用 fine-tune 過的 BERT 或 1B-7B LLM 做專門分類
      • 不是 70B 判分級,是 1B 做分類
      • 100ms 級延遲,員工幾乎感受不到
    3. Layer 3:保守路由(fail-safe,1%)
      • 真模糊的 case,全部判 B 級 → 走脫敏 + 雲端
      • 寧可多脫敏,不要誤送:錯就錯在不便利,不要錯在洩漏

    實際員工體驗:問「這個 process 跑 NPE,客戶大有建設訂單 SO20260415 卡住」→ Gateway 5ms 偵測到「大有建設」「SO\d+」→ 自動改寫成「客戶 [CUSTOMER_A] 訂單 [ORDER_ID]」→ 路由到雲端 Claude → 員工完全不知道發生了什麼,只覺得 AI 答得很好。

    能管的世界 vs 不能管的世界

    追求 100% 覆蓋會害死系統。要清楚畫出邊界,每塊用對應措施:

    範疇 可管性 措施
    Claude Code / Cursor / Continue / Aider ✅ 可改 BASE_URL Gateway 嚴管
    Claude Desktop / 自寫 script / n8n ✅ 可改 endpoint Gateway 嚴管
    公司網路出站流量 ✅ Firewall force proxy Gateway 嚴管
    ChatGPT 網頁 / Claude.ai 網頁 ⚠️ Browser extension 半攔 即時 paste 脫敏 + 警告
    GitHub Copilot inline ❌ MS endpoint 不能改 規則 + 教育
    手機 app / 私人裝置 ❌ 物理上管不到 合約 + 信任 + 事後追溯

    核心心法:不假裝管得到不該管的東西。每塊都有對應措施,沒有「假裝有但實際沒有」的灰區。資安部門能說明、員工能理解、出事能追責。

    「拉力 > 推力」的設計哲學

    對「不能管的世界」,訴諸三層(從硬到軟):

    Layer 1: 用「拉力」把人留在 Gateway 裡(最重要)

    讓 Gateway 比網頁版好用,員工自然不繞過:

    • Gateway 自動注入公司腦(員工不用每次貼 context)
    • Gateway 連 frontier 雲(Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro、DeepSeek V4),員工不用自己付費,還能依任務路由到最強模型
    • Gateway 整合公司 codebase RAG,網頁版做不到
    • Gateway 串流速度比網頁版快(內網直連)

    這是設計哲學的轉換:不是「禁止你用 X」,而是「Y 比 X 好用」。員工是理性人,會選好用的。80 人裡會有 70 人自動留在 Gateway,不用任何 enforcement。

    Layer 2: Browser Extension(半受控的中間地帶)

    • 偵測員工開啟 chat.openai.com / claude.ai / gemini.google.com
    • input 框 paste 時即時 regex 脫敏
    • 大量 paste(>500 字)跳警告:「這段內含 X 個敏感字,已自動替換 Y 個」
    • 不阻擋、不上報,只做防呆 condom

    Layer 3: 規則 + 教育 + 事後追溯

    • 明確紅字 list 寫進員工守則
    • 每季資安訓練(講具體案例)
    • DLP 遙測不阻擋只記 log,事後可追
    • 離職前 audit log 過一遍

    分級對應表怎麼從 0 開始建

    這是組織問題不是技術問題。沒有這張表,所有 Gateway 規則都是空的。

    誰主導

    • 準 CISO 角色(IT 主管 + 法務 + 老闆都接受的人)
    • 不要 IT 一個人定(太技術)
    • 不要法務一個人定(會把所有東西判 A 級,系統失效)
    • 不要部門主管各說各話

    Working Group(5-7 人)

    • 1 × 準 CISO(主導)
    • 1 × 法務(合規紅線)
    • 1 × IT 實作者(技術可行性)
    • 3-4 × 部門 senior(業務視角,挑會用 AI 的人)
    • 1 × 老闆 sponsor(拍板用,不參與每週會)

    四個 Phase(漸進式,不要追求一次到位)

    Phase 時間 目標
    Phase 0 1 週 列資料種類清單(50-100 種)
    Phase 1 2 週 粗分 A/B/C,先有 v0.1
    Phase 2 4-6 週 挑一部門試點,每週開會精修
    Phase 3 持續 全公司 + 月度 patch

    五個必避陷阱

    • ❌「不確定就 A 級」→ 系統失效,員工全跑網頁版
    • ❌ 追求 100% 完整才上線 → 永遠定不下來
    • ❌ 一次寫完不再動 → 6 個月後過時,員工不信任
    • ❌ 黑盒不公開 → 員工不知道為什麼被判 A 級
    • ❌ 法務一個人說了算 → 變成沒人用的合規劇場

    核心原則:先有粗版上線,再用真實流量精修 > 想清楚再上線

    KPI:唯一最重要的數字

    North Star(唯一最重要)

    本月 Gateway request 數
    ÷
    (Gateway request 數 + 偵測到的網頁版 LLM 流量)

    公司網路 DNS / firewall log 看得到員工開了多少次 chat.openai.com / claude.ai / gemini.google.com(域名級,不看內容,沒有隱私問題)。這個比例 = 「員工選 Gateway 的比例」,目標6 個月內達 90%+。< 70% 代表 Gateway 拉力不夠,要查為什麼。

    四象限 Dashboard

    象限 指標 目標
    採用 月活用戶 / 全員 80%+
    替代 North Star 90%+
    體驗 Gateway p50 延遲 < 500ms
    體驗 月度 NPS(vs 網頁版) 4.0/5+
    健康 Layer 1 regex 命中率 > 85%
    健康 員工申訴誤判率 < 0.5%

    月度報告:三個問題就夠

    1. 「上個月 X% 員工選擇 Gateway over 網頁版」← North Star
    2. 「員工繞過 Gateway 的 Top 3 原因」← 下個月修哪邊
    3. 「Gateway 帶來的安全收益 + 成本」← 攔住多少 A 級洩漏、雲端費用變化

    第一個月 MVP 時程

    不要一次蓋大廟。Phase 0 砍到極簡,先讓 Claude Code + Cursor 用戶跑起來,驗證治理流程能不能撐 80 人,再擴展。

    交付
    W1 公司腦 repo + 3-5 條 Iron Rules + build.sh(支援 Claude Code & Cursor)
    W2 個人腦 repo template + 員工 onboarding 文件 + 第一場培訓
    W3 脫敏字典 v0(client_names.txt + employee_names.txt)+ pre-commit hook 擋紅字
    W4 Curator 制度上線(每 team 一個 + 每週 1 小時 review)

    Brain Server / ChatGPT 整合 / 本地 Ollama / 完整 Gateway → 全部砍到 Phase 1(第 2-4 個月)。樂觀估計:1 個全職工程師 3-4 個月做到可上線 Gateway。悲觀:6 個月 + 2 個工程師。

    結語:這是 AI 時代的雙贏

    傳統 IT 部門做了再美的 UI,客戶都會嫌不好用 — 這是 ERP 行業 30 年的詛咒。AI 時代的反轉是:不要再做永遠改不完的 UI 了,做「給 AI 安全取資料的入口」就好。客戶用自己愛的 AI 工具(ChatGPT、Claude、Cursor),透過你架的 Gateway 安全地取資料、做事情。

    這對 RD 是解放:

    • 不再被「客戶嫌頁面醜」「客戶嫌操作太多步」這類無底洞的 UI/UX 工單吃掉時間
    • 可以回去做真正有複利的工作:ISO 流程符合性、資安審核、業務邏輯正確性
    • 每一個 RD 寫的 brain markdown,都是公司 domain knowledge 的長期資產,不會因員工離職就消失
    • 新進員工從第一天就站在累積的 brain 上工作,onboarding 從 3 個月縮到 3 週

    對員工是賦能:每個人都能用自己最熟的 AI 工具,在公司架好的安全護欄內,自行開發小工具、解決自己的痛點。對公司是護城河:domain knowledge 從個人腦袋變成公司資產,可累積、可審計、可傳承。

    整套設計的核心心法只有四句:

    • 能管的嚴管,不能管的不假裝管
    • 拉力 > 推力,讓 Gateway 比網頁版好用
    • 員工不感知,系統默默路由
    • 先粗版上線,真實流量精修

    剩下的就是把 working group 召集起來,開第一次會。

    2026/5 技術參考時間戳

    本文涉及的具體模型版本、開源工具、ISO 標準以撰文時間為準,LLM 領域變化快,請以最新發布為主:

    • 雲端 frontier(2026/4 發布):Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro、DeepSeek V4。各家擅長領域不同,「routing by task type」已成為主流架構。
    • 本地頂級開源:Qwen3-Coder-Next(80B 總參 / 3B active,MoE,256K context)、Qwen3.6、Kimi K2.6、DeepSeek V4、Llama 3.3 70B。
    • 本地 LLM 平台:Ollama 仍是預設選擇,production 並發推 vLLM V1(2-4 倍吞吐)。
    • AI Gateway 開源工具:LiteLLM(unified API to 100+ providers)、Portkey(observability + guardrails + PII redaction)、Kong AI Gateway。2026 企業常見組合是 LiteLLM 當 proxy + Portkey 做 observability。
    • PII 脫敏:Microsoft Presidio v2.2.362(2025/3 釋出,2026/5 仍是最新版),含 image redactor 與 DICOM 醫療影像支援。
    • 合規標準:ISO/IEC 42001:2023(AI 管理系統,目前唯一可認證 AI 標準)、ISO 27001:2022、ISO 27701。Schellman、TÜV SÜD、BSI、DNV 都是合格認證機構。
  • 你的 AI Agent Team 為什麼越做越小?視角驅動的編制方法論

    重點摘要

    • 你以為的「3 個 Agent 上限」可能是創傷的外推,不是設計 — 來自一次 OOM 事故的過度修正,結果反過來殺死你專案的角色細分工
    • 正確的限制是記憶體預算,不是數量 — 16GB 機器可用 ~11GB agent 預算,混合模型(Opus/Sonnet/Haiku)可以安全跑 8+ 個專職 agent
    • 但更深的問題是:角色不是頭銜,是視角 — 你該問「這個計畫需要哪些思考視角」,不是「我有幾個 slot」
    • 三個永遠不能省的視角:使用者、PM、測試者 — 即使是純技術、只有 Python、只有你一個人的專案,這三個視角的思考必須發生
    • 視角打分模型:每個視角用「風險 × 範圍」打 0-9 分,高分獨立成 agent,低分 fold 到其他 agent 的 prompt
    • 反直覺發現:小任務(3 行 API)比大任務更需要資深視角(架構師、運維、測試),因為實作已經不是風險,「該不該存在」才是
    • 壞規則會透過 template anchoring 自我強化 — 修了 runtime 規則還不夠,必須連 template 一起改

    我的 AGENTS.md template 有一條規則:Agent Team 最多 3 個同時跑。這條規則是對的 — 直到我發現它正在偷偷殺死我的專案設計。

    這篇文章是一趟很誠實的反思紀錄。從一次 16GB 機器 OOM 當機開始,到發現我對 AI Agent Team 的所有規則其實都建立在錯誤的抽象層上。結論不是「解除限制、大膽開 agent」,而是更根本的東西:角色根本不是我以為的那個東西

    第一層:我的規則其實是創傷,不是設計

    事情是這樣開始的。2026 年 3 月 3 日,我嘗試在 16GB 的 Mini PC 上同時跑 9 個 Opus agent 做大型重構,結果系統 OOM 當機。從那一天起,我的 MEMORY.md 多了一條 Iron Rule:「Agent Team 最多 3 個同時跑」。

    這條規則是理性的。9 個 Opus × 1GB ≈ 9GB,加上系統和 Docker 的常態佔用,16GB 當然吃不下。3 個是「經驗上安全」的數字。但我沒注意到一件事:這條規則是在「全 Opus」的情境下歸納出來的。我直接把它當成所有情境的通用上限,沒考慮混合模型的狀況。

    更糟的是,這條規則開始滲透到我的 AGENTS.md template、我的專案計畫、我對每個新專案的初始設計。結果是:即使某個專案明明應該有架構師、後端、前端、Kafka、SQL、Test、PM、QA 八個角色,我也會「收斂」到「全端 + 檢查者 + 架構師」三人組。我不是選擇了簡化設計,是我被一條舊規則綁架了設計想像力

    第二層:記憶體預算制取代數量制

    第一個修正很直覺:限制應該是記憶體總量,不是 agent 數量。16GB 機器扣掉系統和 Docker 的 ~5GB,還剩 ~11GB 可以給 agent 用。而不同模型的記憶體占用差很多:

    模型 記憶體 適合任務類型
    Opus ~1.0 GB 架構決策、跨檔案推理、複雜邏輯、資深思考
    Sonnet ~0.6 GB 實作、API、測試、文件
    Haiku ~0.4 GB 檔案掃描、config 對照、簡單查詢

    換算一下:一個架構師(Opus 1.0)+ 兩個後端(Sonnet × 2 = 1.2)+ 前端(Sonnet 0.6)+ SQL(Sonnet 0.6)+ Kafka(Sonnet 0.6)+ Test(Sonnet 0.6)+ QA + PM(Haiku × 2 = 0.8)= 5.4 GB,8 個 agent。完全在 11GB 預算內,還有 5.6GB 的 headroom。

    所以「3 個 agent」的舊規則其實是錯的。正確的說法是「全 Opus 時 ≤ 3 個;混合模型時可以到 8+ 個,只要總和在預算內」。這一步修完,我理論上可以解鎖原本想要的專職團隊設計。

    但這還不夠:我一直在錯的抽象層解決問題

    我以為修到這裡就結束了。結果真正的問題還在更上面一層。

    記憶體預算制解決了「能不能開 8 個 agent」的技術問題,但沒解決「我該開哪 8 個角色」的設計問題。我仍然在用「頭銜思維」想 Agent Team — 有一個固定的角色清單(架構師、後端、前端、QA…),看看預算能放幾個,從清單挑幾個進來。

    這個思維的錯誤在哪?它把「角色」當成頭銜 / headcount,而角色的本質其實是視角 / perspective — 一種「怎麼思考這件事」的觀點。兩個是完全不同的東西:

    思維 頭銜 Headcount 視角 Perspective
    單位 angular-dev、backend-dev 「使用者會怎麼用」「PM 會怎麼想」
    數量 固定清單 每個 plan 動態決定
    「只有 Python」專案 1 個 Python dev 就好 仍需使用者、PM、測試視角
    小任務(3 行) 給最便宜的 dev 可能需要最資深的運維視角

    三個永遠不能省的視角

    這是最實用的一條發現。不管你的專案是什麼技術、什麼規模、幾個人做,這三個視角永遠必須存在:

    • 使用者視角 — 誰會用這個東西?他們的心智模型是什麼?介面怎麼設計才順?
    • PM 視角 — 這件事符合大方向嗎?是現在最該做的嗎?會影響別的優先級嗎?
    • 測試者視角 — 什麼會壞?邊界 case 在哪?漏掉什麼?失敗模式是什麼?

    這三個視角可以 fold 到其他 agent 的 prompt 裡(例如讓 backend-dev 在設計階段戴 PM 帽子),但絕對不能默默省略。省略它們的結果是:你會產出「技術上正確、實用上無用」的東西 — API 能跑但沒人想用、feature 完成但 PM 說這不是重點、code 過 review 但上線就爆 edge case。

    「只有 Python」不是跳過使用者視角的理由。「只有你一個人」不是跳過 PM 視角的理由。「只是改一行」不是跳過測試者視角的理由。這三個視角的思考必須發生,差別只在「由誰承擔」,不在「要不要做」。

    視角打分模型:風險 × 範圍

    光知道「要列視角」還不夠,還要知道哪些重要、哪些次要。我用的打分模型很簡單:Score = Risk × Scope,兩個維度都是 0-3,總分 0-9。

    • 風險:這個視角漏掉的話多慘?(0 = 無所謂,3 = 災難)
    • 範圍:這個視角涉及多少產出物?(0 = 無,3 = 全部)

    分數算出來後按以下規則分組到 agent:

    • Score ≥ 6:獨立 agent,很可能要用 Opus 或高階 Sonnet
    • Score 3-5:獨立 agent,或跟另一個視角配對(Sonnet)
    • Score 1-2:fold 到其他 agent 的 prompt,明確列入該 agent 的優先順序
    • Score 0:在計畫裡 acknowledge 就好,不花 agent 資源

    最後檢查記憶體預算是否超過 11GB,超過就把分數最低的兩個合併。

    反直覺發現:小任務需要更資深的視角

    這是這整套方法論裡最違反直覺、也最容易忽略的一條。實作越簡單的任務,反而越需要資深視角

    原因很微妙:大任務的風險分散在許多實作細節裡,實作者視角得分最高(因為「寫錯」的機率大)。但小任務的實作幾乎免費 — 風險已經轉移到別的地方了:「這東西該不該存在」(架構師視角)、「會不會在奇怪情境下爆」(測試者視角)、「運維怎麼用這個 endpoint 做決策」(運維視角)

    具體例子:幫一個 Docker 服務加 /health endpoint,回 {"status": "ok"}

    • 實作者視角:風險 1 × 範圍 1 = 1 分(3 行誰都會寫)
    • 運維視角:風險 3 × 範圍 2 = 6 分(這個 endpoint 決定服務要不要被 monitoring 重啟)
    • 架構師視角:風險 3 × 範圍 1 = 3 分(「健康」的定義是最大問題)
    • 測試者視角:風險 2 × 範圍 1 = 2 分
    • 使用者視角:風險 2 × 範圍 1 = 2 分

    結論:這個任務要派一個 Sonnet agent,但 prompt 的優先順序是運維 > 架構 > 測試 > 使用者 > 實作。它不是「後端 dev 寫 3 行」,是「一個有運維腦袋的人剛好以 3 行 code 為產出」。

    這個例子回答了我長久的困惑:「小任務該加一個專職 agent,還是從 tester 出發、還是從 dev 出發?」答案是 — 從得分最高的視角出發,不從頭銜出發。小任務通常是資深視角得分高,所以該派的不是 junior implementer,是帶著資深視角的人。

    三個完整案例

    案例 1:純 Python script(200 行,讀 CSV 做統計)

    視角枚舉:Python 實作者、使用者、PM、測試者、架構師

    打分:實作者 6、測試者 6(資料邊界 case 是真風險)、使用者 2、PM 1、架構師 1

    分組:2 個 Sonnet(~1.2 GB)

    • Agent 1:實作 + 架構 + PM 視角(優先:實作)
    • Agent 2:測試 + 使用者視角(優先:測試 — 資料邊界主導)

    2 個 agent,但 5 個視角都被想過了。要的是「每個視角都有思考發生」,不是「每個視角都有一個人」。

    案例 2:OMS 訂單退款功能(跨前後端/Kafka/SQL/admin)

    視角枚舉:架構師、安全、後端、前端、Kafka、SQL、Admin UI、測試、使用者、PM、合規

    打分:每個都 ≥ 4 分,因為範圍廣且風險高(金流)

    分組:9 個 agent(~6.6 GB,預算內)

    • Architect(Opus)、Security(Opus)
    • Backend-dev、Frontend-dev、Kafka、SQL、Admin-UI、Tester(全部 Sonnet)
    • 使用者 + PM + 合規視角 fold 到一個 Haiku

    這就是大型專案值得完整專職團隊的時候。注意:即使 9 個 agent,使用者和 PM 視角還是被 fold 到一個 Haiku,不是各自獨立。視角沒被省,但不一定要佔獨立 slot

    案例 3:3 行 /health endpoint(已在前面詳細分析)

    分組:1 個 Sonnet,所有 5 個視角都 fold,優先順序運維 > 架構 > 測試 > 使用者 > 實作。

    計畫修訂時必須重算

    一個容易忽略的點:staffing 是 live document,不是一次性決定。當計畫執行到一半發現:

    • 新需求浮現(「喔原來這個也要接 Kafka」)→ 新視角需要打分,決定獨立或 fold
    • 某視角發現其實很關鍵(原本 fold 的安全視角,發現有 PII 暴露)→ 升級為獨立 agent
    • 某視角發現其實不必要(決定不做 admin UI)→ 該 agent 退場或重新分配

    每次 plan 修訂都該觸發 staffing 重算。如果 AGENTS.md 跟當前 plan 不同步,應該先更新 AGENTS.md 再繼續 dispatch。

    壞規則會自我強化 — template anchoring 的陷阱

    最後我想分享一個元層級的教訓,是這整件事最讓我不舒服的部分。

    我一開始以為只需要改 runtime 規則(把「3 個上限」改成「預算制」)就好了。但我後來發現:壞規則會透過 template 自我強化。我的 AGENTS.md template 原本的例子只有 2 個角色(implementer + reviewer),這個「低錨」讓我每次初始化新專案時,都自動往「3-5 個角色」的方向填,幾乎從不主動設計 7-10 個。

    這形成一個 feedback loop:

    • 創傷 → 記憶體規則收緊到「3 個」
    • Template 的例子反映記憶體規則 → 錨在低數量
    • 我用 template 寫新 AGENTS.md → 產出低角色的設計
    • 低角色的設計變成「標準」→ 我的記憶認為「就是這樣」
    • 循環加強

    光改規則不夠,template 也得改。我最後把 template 改成強迫跑完整個視角打分流程的版本:頂部要求先讀「視角驅動 staffing」的 brain,中間有「Perspective Inventory」區塊要你填每個視角的 Risk × Scope 分數,再下面是「Memory Budget」計算區塊。沒跑完流程根本填不完 template。

    這個 template 和配套的方法論 brain 都放在公開的領域腦 repo裡,歡迎 clone 參考。

    跟 VCS / 版本控制的關係

    如果你讀過我之前那篇 Jujutsu vs Git,可能會問:視角驅動 staffing 跟 jj 有什麼關係?

    答案是:沒有關係,而且這個順序很重要。視角驅動 staffing 是計畫期的事 — 你在寫 plan、決定 Agent Team 編制時發生。VCS(git / jj / worktree / workspace)是執行期的事 — Agent Team 已經成立、開始跑、產出變動需要合併的時候才登場。不能倒過來。

    我之前一度把這兩件事混在一起寫(在「VCS + AI 工作流」的 brain 裡討論 Agent Team 編制),後來意識到這是錯的。Staffing 決定「要做什麼」,VCS 決定「做的產出怎麼合併」。兩者相關但獨立,混在一起會讓人以為「切到 jj 就能多開 agent」— 不是的,能多開 agent 是記憶體預算 + 視角分析的事,跟 VCS 無關。

    結論:為什麼這個順序重要

    我從「Agent Team 最多 3 個」走到「視角驅動編制」的這段路程,對我來說最重要的一個 meta-lesson 是:你的限制規則可能不是來自設計,而是來自創傷。一次系統炸掉的記憶,會變成一條 Iron Rule,然後透過 template anchoring 滲透到你所有未來的設計決策。

    修復這種規則不能只修表面。你得:

    1. 檢視規則的原始情境 — 它是在什麼條件下產生的?那些條件還成立嗎?
    2. 把規則轉成可計算的東西 — 不是「最多 3 個」,是「11GB 預算」;不是「寫 3 行 API」,是「運維視角 6 分」
    3. 上升到更對的抽象層 — 從「數量」到「預算」是一次升級,從「頭銜」到「視角」是又一次升級
    4. 同時改 template — 不然新專案會繼承舊錨,規則永遠修不乾淨

    這個流程不只適用 Agent Team 編制,適用任何你「歸納」出來的工程規則。下次你發現自己下意識地拒絕某個選項(「不能這樣做,會爆」),請誠實問自己:這個規則是設計來的,還是創傷來的?如果是後者,它可能正在偷偷殺死你的系統設計,而你根本沒意識到。

  • LangGraph 多模型實戰:從零到 Production 的完整教學

    重點摘要

    • LangGraph 讓你把不同 AI 模型串成自動化流水線:Claude 負責「想」,Groq Llama 負責「寫」,各司其職
    • 本文從零開始,帶你走完四個階段:基本流水線 → 智慧路由 → Streaming + 容錯 → FastAPI 部署
    • 每個階段都有完整可執行的程式碼,跟著做就能跑
    • 核心區別:Claude Code / Cursor 是「你的工具」,LangGraph 是「你造工具的材料」——當你要造產品給別人用時才需要它
    • 實測結果:比全用 Claude Sonnet 省 75% 成本,同時保留深度分析的品質

    這篇文章是給誰看的?

    如果你符合以下任一情況,這篇文章就是為你寫的:

    • 你想做一個 AI chatbot(客服、內部助手、產品功能),但不知道怎麼開始
    • 你已經在用 Claude / GPT,但覺得全部用最貴的模型太浪費錢
    • 你聽過「多模型協作」但不確定具體怎麼實作
    • 你想知道 LangGraph 跟你平常用的 Claude Code / Cursor / Copilot 到底差在哪

    本文從零開始,帶你走完四個階段,每個階段都有完整可執行的程式碼。你可以在任何一個階段停下來——不是每個人都需要走到 production。

    先搞清楚:這跟 Claude Code / Cursor / Copilot 完全不同

    在往下讀之前,先釐清最容易搞混的一件事:

    面向 Claude Code / Cursor / Copilot LangGraph
    本質 開發者工具 — 你用它寫 code 開發框架 — 你用它造產品
    使用者是誰 你自己(開發者) 你的客戶 / 你的系統 / 你的團隊
    使用場景 日常寫程式、debug、重構 建 chatbot、自動化流程、API 服務
    互動方式 人 ↔ AI 即時對話 程式碼自動跑,可以無人值守
    模型選擇 工具幫你選好(通常固定一個) 你自己決定哪個步驟用哪個模型
    計費方式 月費訂閱(工具包了) 純 API 按量計費,你自己控制成本

    用一個比喻:Claude Code 是你請了一個很強的工程師坐在旁邊幫你寫 code;LangGraph 是你在蓋一條自動化產線,產線上有不同的機器人各司其職

    如果你只是日常寫程式,用 Claude Code 就好,不需要 LangGraph。往下讀之前,確認你的需求是「造一個東西給別人用」,而不是「讓自己寫 code 更快」。

    為什麼不同的 AI 模型要分工合作?

    沒有一個模型什麼都最好。每個模型有不同的強項和定價:

    能力 Claude Sonnet Groq Llama 70B Groq Llama 8B
    架構設計 / Code Review ⭐ 最強 普通
    程式碼生成 ⭐ 強且快 普通
    簡單問答 大材小用 大材小用 ⭐ 夠用且極便宜
    生成速度 ~50 tok/s ~300 tok/s ~800 tok/s
    費用 (Output/1M tokens) $15.00 $0.79 $0.08

    核心邏輯:讓擅長「想」的模型去想,讓擅長「做」的模型去做,讓便宜的模型處理瑣事。就像軟體團隊裡,架構師出規格、工程師寫程式、實習生回答簡單問題一樣。

    LangGraph 是什麼?一分鐘看懂

    LangGraph 是 LangChain 團隊開發的有狀態流程編排框架。三個核心概念:

    1. Node(節點)— 一個步驟,比如「用 Sonnet 設計」或「用 Llama 實作」
    2. Edge(邊)— 步驟之間的連線,決定「做完 A 接著做 B」
    3. State(狀態)— 所有節點共享的資料,比如設計規格、程式碼、審查結果

    把這三個組合起來,就是一個可以自動跑的流水線。你定義「什麼步驟做什麼、什麼條件走什麼路」,框架負責執行。

    環境準備(所有階段共用)

    開始之前,你需要準備兩個 API key 和安裝套件。這一步做完,後面四個階段都不用再設定。

    1. 取得 API Key(兩個都有免費額度)

    ⚠️ 注意:這是 API key,跟 Claude.ai 的月費訂閱、GitHub Copilot 的訂閱完全無關。API 是按用量計費的。

    2. 建立專案

    mkdir langgraph-duo && cd langgraph-duo
    
    # 安裝套件
    pip install langgraph langchain-anthropic langchain-groq python-dotenv
    
    # 建立 .env 檔案(填入你的 key)
    cat > .env << 'EOF'
    ANTHROPIC_API_KEY=sk-ant-xxxx
    GROQ_API_KEY=gsk_xxxx
    EOF

    3. 驗證連線

    python3 -c "
    from dotenv import load_dotenv; load_dotenv()
    from langchain_anthropic import ChatAnthropic
    from langchain_groq import ChatGroq
    
    sonnet = ChatAnthropic(model='claude-sonnet-4-6', max_tokens=50)
    llama = ChatGroq(model='llama-3.3-70b-versatile', max_tokens=50)
    
    print('Sonnet:', sonnet.invoke('Say OK').content)
    print('Llama:', llama.invoke('Say OK').content)
    "

    兩行都印出 OK,就可以開始了。

    第一階段:Duo 流水線(設計 → 實作 → 審查)

    目標:讓 Claude Sonnet 設計規格,Groq Llama 寫程式碼,Sonnet 再審查品質。審查不通過自動重做,最多 3 次。

    適合場景:批量生成程式碼、自動化 code review、需要品質把關的程式碼生成。

    Task → [Sonnet 設計] → [Llama 實作] → [Sonnet 審查]
                                ↑               |
                                └── 未通過 ──────┘  (最多 3 次)
                                      ↓ 通過
                                     END

    完整程式碼:duo.py

    from typing import TypedDict
    from dotenv import load_dotenv
    from langgraph.graph import StateGraph, END
    from langchain_anthropic import ChatAnthropic
    from langchain_groq import ChatGroq
    from langchain_core.messages import HumanMessage, SystemMessage
    
    load_dotenv()
    
    # 模型分工:Sonnet 想,Llama 做
    sonnet = ChatAnthropic(model="claude-sonnet-4-6", max_tokens=4096)
    llama = ChatGroq(model="llama-3.3-70b-versatile", max_tokens=4096)
    
    # 所有節點共享的狀態
    class AgentState(TypedDict):
        task: str             # 原始需求
        design: str           # Sonnet 的設計規格
        code: str             # Llama 的實作
        review: str           # Sonnet 的審查結果
        revision_notes: str   # 修改指示(給重試用)
        approved: bool        # 是否通過
        attempt: int          # 重試次數
    
    MAX_ATTEMPTS = 3
    
    # Node 1: Sonnet 設計
    def design_node(state):
        response = sonnet.invoke([
            SystemMessage(content="You are a senior architect. Produce a precise technical spec with function signatures, edge cases, and pseudocode."),
            HumanMessage(content=f"Request: {state['task']}")
        ])
        return {"design": response.content}
    
    # Node 2: Llama 實作
    def implement_node(state):
        prompt = f"Spec:\n{state['design']}"
        if state.get("revision_notes"):
            prompt += f"\n\nFix these issues:\n{state['revision_notes']}"
        response = llama.invoke([
            SystemMessage(content="Implement per spec. Output only Python code."),
            HumanMessage(content=prompt)
        ])
        return {"code": response.content, "attempt": state.get("attempt", 0) + 1}
    
    # Node 3: Sonnet 審查
    def review_node(state):
        response = sonnet.invoke([
            SystemMessage(content="Review code vs spec. Reply VERDICT: APPROVED or REJECTED with details."),
            HumanMessage(content=f"Spec:\n{state['design']}\n\nCode:\n{state['code']}")
        ])
        review = response.content
        approved = "APPROVED" in review.upper()
        return {"review": review, "approved": approved,
                "revision_notes": "" if approved else review}
    
    # 條件路由:通過 → 結束,未通過 → 回去重做
    def should_continue(state):
        if state["approved"] or state["attempt"] >= MAX_ATTEMPTS:
            return "end"
        return "revise"
    
    # 組裝 Graph
    workflow = StateGraph(AgentState)
    workflow.add_node("design", design_node)
    workflow.add_node("implement", implement_node)
    workflow.add_node("review", review_node)
    workflow.set_entry_point("design")
    workflow.add_edge("design", "implement")
    workflow.add_edge("implement", "review")
    workflow.add_conditional_edges("review", should_continue,
                                   {"end": END, "revise": "implement"})
    app = workflow.compile()
    
    # 跑!
    result = app.invoke({
        "task": "Write a Python function that reads a CSV and returns column averages as a dict",
        "design": "", "code": "", "review": "",
        "revision_notes": "", "approved": False, "attempt": 0,
    })
    
    print("=== CODE ===")
    print(result["code"])
    print(f"\n{'✅ APPROVED' if result['approved'] else '⚠️ BEST EFFORT'} after {result['attempt']} attempt(s)")

    實測結果

    階段 模型 結果
    🧠 Design Claude Sonnet 4.6 產出 4 個參數、10 個 edge case、9 步 pseudocode 的完整規格
    ⚡ Implement Groq Llama 70B 完整 Python 函數,含 type hints、docstring、error handling
    🔍 Review Claude Sonnet 4.6 VERDICT: APPROVED — 第一次就通過,沒有重試

    到這裡你已經有一個能跑的多模型流水線了。如果你的需求是「批量生成程式碼 + 自動品質把關」,可以停在這個階段。

    第二階段:Smart Router(自動選模型的聊天機器人)

    目標:做一個像 ChatGPT 一樣的對話介面,但底下不是固定一個模型,而是自動根據問題類型選最適合的模型。

    適合場景:客服 chatbot、團隊內部 AI 助手、需要控制 API 成本的聊天服務。

    你的問題 → [Llama 8B 分類器] → 判斷類型
                                      |
                      ┌────────────────┼────────────────┐
                      ↓                ↓                ↓
                [Claude Sonnet]  [Llama 70B]      [Llama 8B]
                 深度分析          寫程式            簡單問答
                      ↓                ↓                ↓
                      └────────────────┼────────────────┘
                                       ↓
                                    回答你

    分類器怎麼運作?

    分類器用最便宜的 Llama 8B(每次呼叫不到 $0.0001)讀取問題,輸出一個 JSON 判斷結果。分類規則:

    分類 路由到 觸發條件 費用 (Output/1M)
    🧠 深度思考 Claude Sonnet 架構分析、比較權衡、code review、規劃 $15.00
    ⚡ 寫程式 Llama 70B 實作函數、生成腳本、重構、修 bug $0.79
    💨 快速回答 Llama 8B 打招呼、簡單問答、定義、基礎算數 $0.08

    核心程式碼

    import json
    from langgraph.graph import StateGraph, END
    
    # 分類器:Llama 8B 讀問題,判斷該走哪條路
    def router_node(state):
        response = llama_8b.invoke([
            SystemMessage(content="""Classify into one category:
    - "sonnet": complex reasoning, analysis, architecture
    - "llama_70b": write code, implement, fix bugs
    - "llama_8b": greetings, simple facts, casual chat
    Reply ONLY JSON: {"route": "...", "reason": "..."}"""),
            HumanMessage(content=state["question"])
        ])
        parsed = json.loads(response.content)
        return {"route": parsed["route"]}
    
    # 條件路由:根據分類結果,走不同的回答節點
    workflow = StateGraph(RouterState)
    workflow.add_node("router", router_node)
    workflow.add_node("sonnet", answer_sonnet)
    workflow.add_node("llama_70b", answer_llama_70b)
    workflow.add_node("llama_8b", answer_llama_8b)
    
    workflow.set_entry_point("router")
    workflow.add_conditional_edges("router", lambda s: s["route"], {
        "sonnet": "sonnet",
        "llama_70b": "llama_70b",
        "llama_8b": "llama_8b",
    })
    app = workflow.compile()

    實測分類準確度:7/7

    問題 路由結果 正確?
    Hi! 💨 Llama 8B
    1+1=? 💨 Llama 8B
    Write a Python quicksort ⚡ Llama 70B
    Compare microservices vs monolith 🧠 Sonnet
    What is Docker? 💨 Llama 8B
    幫我寫一個 REST API ⚡ Llama 70B
    分析 Redis cache vs CDN 優缺點 🧠 Sonnet

    到這裡你有一個能自動選模型的聊天機器人了。但它還缺兩個東西:回答會一次全部吐出(不是逐字顯示),而且 Groq 掛了就整個壞掉。第三階段解決這兩個問題。

    第三階段:Streaming + Fallback(讓它不會掛)

    目標:回答逐字出現(像 ChatGPT 一樣流暢),而且模型掛了自動切換備用模型。

    為什麼這一步很重要:沒有 Streaming 的 chatbot,使用者體驗像 2010 年的網頁——按下送出,等 5 秒,突然一大段文字出現。沒有 Fallback 的服務,Groq 一限速(免費版每分鐘 30 次),你的整個服務就掛了。

    Streaming:體感延遲降 25 倍

    方式 使用者體驗 程式碼差別
    invoke()(非串流) 等 5 秒 → 突然出現整段文字 response = model.invoke(messages)
    stream()(串流) 0.2 秒開始出字 → 像打字一樣流暢 for chunk in model.stream(messages)
    # 只需要把 .invoke() 改成 .stream()
    # 然後迭代每個 chunk 即時輸出
    
    for chunk in model.stream(messages):
        print(chunk.content, end="", flush=True)  # flush=True 強制即時顯示

    Fallback:模型掛了自動切換

    主要模型 Fallback 模型 切換代價
    🧠 Sonnet ⚡ Llama 70B 分析品質略降,速度更快
    ⚡ Llama 70B 🧠 Sonnet 速度略慢,品質更高
    💨 Llama 8B ⚡ Llama 70B 稍慢稍貴,但一定能回答
    # Fallback 模式:try 主要模型,失敗自動切備用
    try:
        for chunk in primary_model.stream(messages):
            print(chunk.content, end="", flush=True)
    except Exception:
        print("⚠️ Primary failed, switching to fallback...")
        for chunk in fallback_model.stream(messages):
            print(chunk.content, end="", flush=True)

    完整的 router_stream.py 把 Streaming + Fallback + 對話歷史 + 使用統計整合在一起,不到 200 行。跑起來就是一個帶有自動模型切換的 terminal 聊天機器人。

    到這裡你有一個穩定的、體驗流暢的聊天機器人了。但它還是跑在你的 terminal 裡,只有你能用。第四階段讓它變成任何人都能呼叫的 API 服務。

    第四階段:FastAPI 部署(讓別人能用)

    目標:把 chatbot 包成 HTTP API,讓網頁、App、Line bot、Slack bot 都能呼叫。

    為什麼是 FastAPI:Python 生態最主流的 API 框架,原生支援 async、自動生成 API 文件、社群龐大。

    API 端點設計

    端點 方式 適合場景
    POST /chat 非串流,回傳完整 JSON Slack/Line bot、後端呼叫、批次處理
    POST /chat/stream SSE 串流,逐 token 推送 網頁聊天窗、需要即時體感的 UI
    GET /health 健康檢查 負載平衡器、監控系統
    GET /sessions/{id} 取得對話歷史 Debug、對話紀錄查詢
    DELETE /sessions/{id} 清除對話 使用者開始新對話

    啟動與測試

    # 安裝額外套件
    pip install fastapi uvicorn sse-starlette
    
    # 啟動 server
    python server.py
    # → 🤖 Smart Router API running on http://localhost:8900
    
    # 測試非串流
    curl -X POST http://localhost:8900/chat \
      -H "Content-Type: application/json" \
      -d '{"message": "什麼是 Docker?", "session_id": "test-user"}'
    
    # 回應範例:
    # {
    #   "answer": "Docker 是一個容器化平台...",
    #   "model_used": "llama_8b",
    #   "route_reason": "simple definition question",
    #   "session_id": "test-user",
    #   "fallback_used": false,
    #   "elapsed_seconds": 0.85
    # }

    前端怎麼接 SSE 串流?

    如果你要做網頁聊天窗,前端只需要幾行 JavaScript:

    // 瀏覽器原生 EventSource API
    const response = await fetch('/chat/stream', {
      method: 'POST',
      headers: {'Content-Type': 'application/json'},
      body: JSON.stringify({message: '寫一個排序函數', session_id: 'user-1'})
    });
    
    const reader = response.body.getReader();
    const decoder = new TextDecoder();
    
    while (true) {
      const {done, value} = await reader.read();
      if (done) break;
      const text = decoder.decode(value);
      // 每個 chunk 到了就即時顯示在畫面上
      document.getElementById('chat').innerHTML += text;
    }

    為什麼用 SSE 而不是 WebSocket?

    聊天場景是「使用者送一次訊息、AI 回一次」的單向推送。SSE 比 WebSocket 更適合:

    • 更簡單 — 單向傳輸,不需要管雙向連線
    • 瀏覽器原生 — EventSource API 內建自動重連
    • 穿透力好 — 走標準 HTTP,能通過代理和 CDN
    • 夠用 — 使用者的訊息用 POST 送,AI 的回應用 SSE 推

    四個階段的完整對照

    階段 檔案 新增能力 適合誰 可以停在這嗎?
    1. Duo 流水線 duo.py 設計→實作→審查 批量生成程式碼
    2. Smart Router router.py 自動選模型 個人實驗、學習
    3. Streaming + Fallback router_stream.py 逐字輸出 + 自動容錯 團隊內部使用
    4. FastAPI 部署 server.py HTTP API + SSE + Session 對外服務、產品整合

    費用比較:到底能省多少?

    假設一天 100 個問題,其中 20% 深度分析、30% 寫程式、50% 簡單問答:

    方案 月成本估算 品質
    全部用 Claude Sonnet ~$54 最高,但簡單題大材小用
    Smart Router(自動切換) ~$13.50 深度題用 Sonnet,其餘用 Llama
    全部用 Groq Llama 70B ~$4.20 最便宜,但分析品質弱

    Smart Router 方案比全用 Sonnet 省 75%,同時保留了深度分析任務的 Sonnet 品質。規模越大差距越明顯——1000 個使用者的 SaaS 產品,月省 $3000+。

    什麼場景適合?什麼場景不適合?

    ✅ 適合的場景

    1. 客服 Chatbot — 70% 簡單題用 Llama 8B 秒回,複雜題自動升級到 Sonnet
    2. 團隊 AI 助手 — 接 Slack,PM 問策略用 Sonnet,工程師要 code 用 Llama 70B
    3. 自動化 Pipeline — CI/CD 中的 AI code review,PR 提交自動跑
    4. SaaS 產品 — 加 AI 功能但要控成本,簡單摘要用 Llama,深度分析用 Sonnet
    5. 批量內容生成 — 50 篇產品描述:Sonnet 定規範 → Llama 批量寫 → Sonnet 抽檢

    ❌ 不適合的場景

    • 日常寫程式 — 用 Claude Code 或 Cursor 就好,不需要 LangGraph
    • 一次性分析 — 直接貼給 Claude 問就好,不需要搭 pipeline
    • 不需要控成本 — 個人使用月花不到 $10,Smart Router 省下的錢不值得建置成本

    三個問題判斷法

    在決定要不要用之前,問自己:

    1. 使用者是誰? — 你自己 → 不需要。別人(客戶/團隊/系統)→ 繼續看
    2. 會跑多少次? — 幾次 → 直接呼叫 API。幾百幾千次 → LangGraph 有意義
    3. 需要品質分級嗎? — 所有問題都要最高品質 → 用最強模型。不同問題可以不同品質 → Smart Router

    三個都答「後者」才值得用 LangGraph。

    走完四個階段之後,還有什麼?

    如果你的服務要上正式商業環境,還有幾個面向需要處理:

    面向 做什麼 不做的後果
    RAG(檢索增強) 接向量資料庫,讓 AI 查你的文件回答 AI 只能回答通用知識,不懂你的業務
    評估(LangSmith) 追蹤每次呼叫的路由、延遲、成本 不知道 Router 分類準不準,成本失控
    Session 持久化 用 Redis 存對話歷史(目前在記憶體) Server 重啟,所有對話消失
    認證 API key 或 JWT 驗證 任何人都能呼叫你的 API,幫你花錢
    Prompt Injection 防護 驗證使用者輸入,防止惡意 prompt 使用者讓 AI 做不該做的事
    Docker 容器化 打包成 Docker image 部署 環境不一致,部署困難
    Subgraph 嵌套 Router 判斷「寫程式」→ 啟動整個 Duo 流水線 只能單步回答,沒有品質把關

    完整專案結構

    langgraph-duo/
    ├── .env                  # API keys(不要 commit)
    ├── .gitignore            # 排除 .env
    ├── requirements.txt      # 所有套件
    ├── duo.py                # 階段 1:設計→實作→審查 流水線
    ├── duo_notebook.ipynb    # 階段 1 的 Jupyter 版
    ├── router.py             # 階段 2:Smart Router 基本版
    ├── router_stream.py      # 階段 3:+ Streaming + Fallback
    └── server.py             # 階段 4:FastAPI HTTP API

    所有程式碼都有詳細的中英文註解,說明每個模型的選用原因和適用場景。從哪個階段開始都可以,每個檔案都是獨立可執行的。

    總結

    LangGraph 多模型流水線的核心價值不是「用 AI 寫程式更快」——如果只是速度,直接用一個模型最快。它的價值在於把 AI 當成團隊來管理:讓擅長設計的去設計、擅長實作的去實作、擅長審查的去審查。

    從 Duo 流水線到 Smart Router,再到帶有 Streaming、Fallback、API 部署的生產版本,每一步都是從「能跑」走向「能上線」的必經之路。你不需要一次走完四個階段——先跑通第一階段,確認這個架構對你有用,再往下走。

    相關閱讀:LangChain/LangGraph 深度分析:架構師、顧問、個人公司的實戰指南 | Claude Code Agent Teams:從穩定執行到自動化代碼審查的完整指南 | 舊系統整合場景下,會用 vs 不會用 Claude Code 的差距