重點摘要(TL;DR)
- AI 工具有三類完全不同定位:Coding Agent(Claude Code / OpenCode)、Chat-native General-purpose Agent(OpenClaw / QwenPaw / Nanobot)、Bridge(ccbot / 官方 Channels)。前一版混淆了,本篇修正。
- OpenClaw 事件(2026/4/4):Anthropic 撤銷 OAuth、訂閱費不再支援第三方工具。對企業最重要的教訓:永遠用 API key 走 Enterprise 合約,不要把員工個人訂閱當公司基建。
- OpenClaw 替代品光譜:QwenPaw(對企業 air-gapped 最優)、Nanobot(輕量)、PraisonAI(low-code multi-agent)、Hermes / grip-ai / Chatbox / Enclave AI 等。
- Harness 設計(Anthropic 2026/3 三 agent 方法論):Simplicity First / Strip away non-load-bearing / Evaluator 看任務難度。模型升級時主動砍腳手架。
- 企業整合三版本:A(Claude Code + 官方 Channel)、B(Claude Code + ccbot + Gateway)、C(QwenPaw + Ollama + Gateway 完全 air-gapped)。可同時並存於同一集團不同 BU。
- 本文是腦子系統四部曲第四篇(Tools 工具中性化),前三篇:Why / How / Scale。
一、修正前篇:三類工具的真實定位
本文重寫前一個版本,因為前版誤把 OpenClaw 當作 OpenCode 處理。實際上這兩個工具完全不同類,分屬不同層的解決方案。整個生態系應該分成三類來看:
| 類別 | 代表工具 | 主要任務 | 介面 | 目標用戶 |
|---|---|---|---|---|
| A. Coding Agent | Claude Code、OpenCode、Cursor、Aider、Cline、Codex CLI | 寫 code、debug、跨檔案 refactor | Terminal / IDE | RD / DevOps |
| B. Chat-native General Agent | OpenClaw、QwenPaw、Nanobot、PraisonAI、Hermes | email / 行事曆 / 訂機票 / 表單填寫 / 一般行政自動化 | 原生支援多 chat app(WhatsApp/Telegram/Slack/Signal/iMessage) | 全公司員工(含非 RD) |
| C. Bridge / Channel | ccbot、Anthropic 官方 Channels、CloudCLI | 把 Coding Agent 延伸到行動端 | Telegram / Discord / iMessage | RD(出差/移動中) |
關鍵 insight:B 類(Chat-native)對「萬人集團 80% 不寫 code 的員工」覆蓋面最大 — 業務、客服、行政、HR 不需要 coding agent,他們要的是 email / 行事曆 / 訂機票 / 表單自動化,而且要從原本就在用的 chat app 直接呼叫。
二、OpenClaw 事件:企業導入的重大警訊
2.1 事件時間軸
- 2025/11:作者 Peter Steinberger(奧地利開發者)發布 Clawdbot
- 2026/2/14:作者宣布加入 OpenAI(這個時間點在後續事件中很微妙)
- 2026/3:Clawdbot 改名 OpenClaw,支援 50+ integrations
- 2026/4/4:Anthropic 正式撤銷第三方工具的 OAuth 存取,Claude Pro/Max 訂閱不再支援 OpenClaw 等工具(改算 extra usage)
- 2026/4/10:Anthropic 短暫封鎖作者本人帳號,輿論發酵後恢復
2.2 為什麼被封鎖
Anthropic 的官方說法:違反 Consumer Terms of Service。
- Claude.ai 訂閱(Pro / Max)是個人用 — 「for personal use through Anthropic’s own interfaces」
- 不可 power programmatic workflows(自動化流程、批次處理)
- OpenClaw 用 OAuth 把訂閱費當 API 用,實質是「訂閱價跑 API 等級流量」 — Anthropic 形同補貼
- Anthropic 法務頁面明寫:「Using OAuth tokens obtained through Claude Free, Pro, or Max accounts in any other product, tool, or service — including the Agent SDK — is not permitted」
2.3 對企業的四個重大教訓
- 永遠用 API key,不要用個人訂閱 OAuth:員工說「我用我的 Claude Pro 帳號接公司工具」聽起來省錢,實際上隨時被切。企業 AI 基建只能架在 Enterprise 合約 + API key 之上。
- 「廠商封鎖風險」要納入工具選型:同一家廠商可能因為政策、競爭、法務等原因突然改規則。OpenClaw 的 50 倍成本上漲、不少 OpenAI 第三方工具被封鎖、API rate limit 突調 — 都是真實案例。不要把全公司流量壓在單一廠商。
- 本地模型 + 開源 chat-native agent 是唯一不被綁的路徑:OpenClaw + Anthropic 訂閱會被切,但 QwenPaw + Ollama + Qwen3-Coder-Next 完全自主,沒有任何第三方可以動你的服務。對 A 級資料 BU 是必選。
- 合約條款要求「廠商如改政策提前 90 天通知」:Enterprise 合約 negotiate 時,把「policy stability」寫進去。Anthropic 對個人訂閱可以說改就改,但對 Enterprise 客戶通常得提前通知 — 這個條款要爭取。
三、OpenClaw 替代工具完整地圖
OpenClaw 事件後,生態系冒出大量替代品。按企業適用場景分:
3.1 對企業 air-gapped BU 最理想:QwenPaw
- 來源:agentscope-ai 開源(原名 CoPaw,2026 改名 QwenPaw 強調 Qwen 生態整合)
- 特色:本地模型優先(Qwen3-Coder-Next、Qwen3.6 等)+ 多 chat app 介面(DingTalk / Feishu / WeChat / Discord / Telegram)
- 對台灣企業:中文 chat app 支援度最高,適合製造業 / 集團內部
- 適合:萬人集團 A 級 BU、要完全 air-gapped、製造業 BOM / 財務 / HR
3.2 輕量化:Nanobot
- 來源:香港大學,4,000 行 Python(對比 OpenClaw 的 430K 行)
- 支援:Telegram / Discord / WhatsApp / Slack / Email out of the box
- 適合:小團隊、想完全掌控代碼、不需要 50+ integrations 的企業
3.3 多 agent 編排:PraisonAI
- 特色:low-code 多 agent 平台,100+ LLM 支援,內建 handoffs / guardrails / memory / RAG
- 支援:Telegram / Discord / WhatsApp
- 適合:需要 Anthropic 三 agent harness 設計、但不想自己從頭寫的企業
3.4 其他主流選項
| 工具 | 特色 | 適合 |
|---|---|---|
| Hermes Agent | self-improving 學習迴圈,從複雜任務生 skill 文件 | 需要長期累積能力的場景 |
| grip-ai | Claude Agent SDK based,31 tools,826 tests | 仍想用 Anthropic 但要可控的開發者 |
| NanoClaw | 5 個檔案 vs 430K 行,Linux 容器隔離,WhatsApp focus | 資安要求高、要細粒度隔離 |
| Chatbox | 統一介面接 ChatGPT / Claude / Gemini / Ollama | 員工想跨多家 LLM 的桌面用戶 |
| Enclave AI | iPhone / Mac 完全本地,語音對話 | A 級資料行動端、無雲依賴 |
| OpenJarvis | Ollama / vLLM / SGLang / llama.cpp 整合,有 learning loop | 已有本地推理基建的企業 |
| Moltworker | Cloudflare 推出的 self-hosted personal agent | 已用 Cloudflare 生態的企業 |
四、Harness 設計方法論
「Harness」(腳手架)是 Anthropic 2026 提出的核心工程概念,指 AI agent 周邊的所有非模型組件:system prompt、memory 機制、tool 定義、context 管理、agent 多步循環、評估迴圈。Anthropic 在 Harness design for long-running application development(2026/3)正式發表了完整方法論。
4.1 Anthropic 三 agent harness
| Agent 角色 | 職責 | Handoff 產出 |
|---|---|---|
| Planner | 把模糊的初始 prompt 展開成詳細規格 | feature 清單(Anthropic 範例 200+ 條) |
| Generator | 執行核心工作、實作功能、自我評估進度 | code + progress tracking artifact |
| Evaluator / QA | 用具體 criteria 獨立評估,抓 generator 漏掉的 gap | 合格/不合格 + 具體缺漏清單 |
三 agent 分離的目的:解決長時間任務的 context overflow。一個 agent 跑 8 小時 context 會爆,三個 agent 用 structured handoff artifact 傳遞狀態,每個 agent 自己 context 重置 — 這就是 Anthropic 講的「maintain coherence across multiple context windows」。
4.2 公司腦子系統如何映射到 Harness
| Anthropic Harness 元件 | 公司腦子系統對應 | 維護方 |
|---|---|---|
| System Prompt | global/CLAUDE.md(Iron Rules) | Working Group |
| Memory(persistent) | 公司腦 brain markdown + 個人腦 | Curator + 員工自己 |
| Tools / MCP servers | Skills(可重用能力包)+ 內部 RAG | RD + 部門 Curator |
| Context 管理 | build.sh 編譯時依目標 model 過濾 | RD |
| Evaluator agent | Curator 月度 review + KPI Dashboard + ISO 稽核 | 準 CISO + Curator |
4.3 修改 Harness 的三條原則
- Simplicity First:找最簡解,需要才增加複雜度。每個 harness 元件都 encode 了一個假設「模型自己做不到 X」 — 這些假設要定期 stress-test。
- Strip away non-load-bearing pieces:模型升級時(Opus 4.5 → 4.6 → 4.7),原本必要的腳手架可能變成包袱。Anthropic 觀察 Opus 4.6 比 4.5 需要更少腳手架 — 模型越強,harness 越輕。
- Evaluator 看任務難度:「worth the cost when the task sits beyond what the current model does reliably solo」。簡單 CRUD 不需要 evaluator;跨檔案 refactor 才需要。不為對稱加 evaluator,只在它真的攔到問題時保留。
五、行動端通訊三種模式(正確分類)
| 模式 | 對應 | 機制 | 適合場景 |
|---|---|---|---|
| A. Coding Agent + 官方 Channel | Claude Code + 官方 Channels(2026/3/20) | Anthropic 官方 MCP server,連 Telegram/Discord/iMessage | 純 Claude Code 用戶、簡單設定 |
| B. Coding Agent + Bridge | Claude Code / OpenCode + ccbot(tmux 之上) | tmux thin layer,讀 pane output、送 keystrokes | RD 想多 session 平行、跨 coding agent |
| C. Chat-native Agent(Native) | QwenPaw / Nanobot / OpenClaw 等 | 自帶 agent + 自帶多 chat app,本機跑 | 全公司員工(含非 RD),日常自動化 |
關鍵差別:
- A 和 B 後面接 Coding Agent(只做 coding 任務的延伸)
- C 本身就是 Agent(做廣義自動化:email、行事曆、表單、訂機票)
- 覆蓋面:A、B 給 RD;C 給全員
5.1 ccbot 機制深入(B 模式代表)
ccbot 是 B 模式主流。技術核心:tmux 之上的 thin control layer,不是 SDK wrapper。
- Claude Code 進程原封不動跑在桌機 tmux window
- ccbot 監聽 JSONL 轉錄檔(每 2 秒 polling)
- Telegram 訊息 → 送 keystrokes 到 tmux pane
- terminal output → ccbot 解析後 forward 回 Telegram
- 1 Telegram topic = 1 tmux window = 1 Claude session
適配到其他 coding agent(OpenCode / Aider / Cline)需要 fork ccbot 改 transcript parser,核心架構不變,1-2 週可做出 v0。
六、企業整合架構:三種模式 × Gateway
6.1 完整流量路徑
員工手機 (WhatsApp / Telegram / Slack / Signal)
↓ chat message
┌────────────── 三種入口都進這層 ──────────────┐
│ A: Coding Agent + 官方 Channel │
│ B: Coding Agent + ccbot Bridge │
│ C: Chat-native Agent (QwenPaw 等) │
└────────────────────────────────────────────┘
↓ HTTP request 經 BASE_URL 改寫 (關鍵!)
公司 LLM Gateway (LiteLLM + Portkey)
├─ Layer 1 regex 脫敏 / 分級
├─ Layer 2 小模型 fail-safe
├─ 路由 + audit log
└─ ↓ ↓
雲端 frontier 本地 Ollama
(B/C 級,API key) (A 級)三種模式的共同點:都要把 endpoint 指向公司 Gateway,讓分級 / 脫敏 / audit 都生效。不可以讓員工的 Chat-native Agent 直接連 Anthropic / OpenAI 的 API,即使是 Enterprise 合約也不該繞過 Gateway。
6.2 安全考量(必看)
- 訊息 channel 也要分級:Telegram / Discord / WhatsApp 訊息會經過第三方伺服器 → 即使 Gateway 端脫敏,訊息已經先到第三方。建議:
- Slack(enterprise)/ Mattermost(self-host)→ B/C 級可
- Signal → B 邊界、C 級可
- Telegram / Discord / WhatsApp → 僅 C 級
- iMessage → 視所在地區法規(歐盟禁、台灣彈性)
- A 級 BU(財務 / HR / BOM 配方 / 法務)禁止任何外部 chat channel,只能 Mattermost self-host
- 身份驗證:Bridge / Chat-native Agent 必設 ALLOWED_USERS 白名單,綁員工 chat app 帳號;離職立即撤銷
- 不要用個人訂閱 OAuth:OpenClaw 事件的核心教訓 — 員工說「我用我的 Claude Pro 接公司工具」聽起來省錢,實際上隨時被切;公司基建只能架在 API key + Enterprise 合約
七、企業導入的三個版本
A 基礎版:Claude Code + 官方 Channels
- 適合:80 人以下、已用 Claude Code、員工以 RD 為主
- 成本:Anthropic Enterprise 合約 + 官方 Channels 免費
- 工程量:1 人 1 週設定完成
- 限制:覆蓋率低(只給寫 code 的人)、A 級資料無法處理
B 開源版:Claude Code + ccbot + 公司 Gateway
- 適合:80-1000 人、有 RD 維護能力、想多 session 平行
- 成本:Anthropic Enterprise + ccbot 自架 + 公司 Gateway
- 工程量:1.5 RD x 2-3 個月
- 限制:仍綁 Anthropic、覆蓋率仍偏 RD、A 級資料要走 Mattermost self-host
C 完全本地版:QwenPaw + Ollama + 公司 Gateway ⭐
- 適合:萬人集團、製造 / 金融 / 國防 / 醫療,有 air-gapped 法規要求
- 成本:QwenPaw 免費 + GPU 機房(中央 1x H100 + 多台 4090)+ Mattermost self-host + 公司 Gateway
- 工程量:2-3 RD x 4-6 個月
- 優勢:
- 整套 air-gapped,A 級資料完全可處理
- 不被任何雲端 LLM 廠商鎖死(OpenClaw 事件不會發生在你身上)
- 覆蓋全公司員工(含 80% 不寫 code 的人)
- 支援中文 chat app(QwenPaw 原生支援 DingTalk / Feishu / WeChat)
三個版本可以同時並存於同一集團:RD BU 用 B 版(Claude Code + ccbot)做 coding;業務 / 客服 / 行政用 C 版(QwenPaw)做日常自動化;管理層內部工具用 A 版(官方 Channels)。不同 BU 不同需求,Gateway 是唯一共用層。
八、結語:工具中性化 + 廠商獨立
不應該把員工綁在某個 AI 工具的某個 UI 上,也不應該把公司基建綁在某家廠商的政策善意上。
讓員工選工具(Claude Code / OpenCode / QwenPaw / OpenClaw),選位置(桌機 / 手機 / 平板),選通訊頻道(Telegram / Discord / Signal / Slack / WhatsApp / Mattermost)。公司只負責 Gateway 那層的腦子注入和分級路由。
OpenClaw 事件提醒我們:廠商可以在任何時間用任何理由改規則。本地模型 + 開源工具 + 自有 Gateway 是唯一不會被切的路徑。Bridge 和 Gateway 正交組合,工具汰換不影響腦子系統 — 這才是真正的工具中性化。
同樣道理:模型升級時,Anthropic 教我們「strip away non-load-bearing pieces」。腦子系統的每季健檢就是這個原則的應用。Harness 不是寫一次就完的,是隨模型演化、隨廠商政策變動而調整的活系統。
延伸閱讀
- 第一篇 (Why):80 人公司的 AI 腦子系統 — 為什麼這樣設計、雙引擎、能管 vs 不能管
- 第二篇 (How):16 步驟實戰建置 — Phase 0-5 / 16 Step 工程細節
- 第三篇 (Scale):萬人集團農村包圍城市策略 — 跨國集團尺度的順序倒轉
- 本文 (Tools):Chat-native Agent + Harness 設計 + OpenClaw 事件 — 工具中性化、廠商獨立
2026/5 工具與事件參考
- OpenClaw 事件:TechCrunch 報導、The Register
- Anthropic Channels:官方文件(2026/3/20 發布)
- ccbot:six-ddc/ccbot(Telegram ↔ tmux thin bridge)
- QwenPaw:agentscope-ai/QwenPaw(本地優先,多 chat app)
- Anthropic Harness Engineering:Harness design for long-running application development(2026/3)
- Awesome Harness Engineering:ai-boost/awesome-harness-engineering