Codex、Claude Code、OpenCode 與中國 CLI 智慧體：AI 到底是如何操作電腦系統

很多人第一次看到 Codex 在 Mac 上剪影片、操作剪映、修改程式碼、呼叫 Git，甚至同時派出多個 agent 幹活時，都會產生一種錯覺：模型似乎已經鑽進電腦，取得了滑鼠、鍵盤和終端機，開始像一個真正的人類工程師那樣工作。

其實沒有那麼神祕。

大模型仍然只是「大腦」。真正讓它取得行動能力的，是外面那一整套 agent runtime：檔案系統、Terminal、Git、瀏覽器、Computer Use、MCP、外掛、權限控制、任務迴圈與上下文管理。Claude、GPT、Kimi、Qwen 是大腦；Codex、Claude Code、Kimi Code、Qwen Code、OpenCode 是身體和工作制度；FFmpeg、Git、Shell、瀏覽器與剪映，才是它真正拿在手裡的工具。

一旦把這四層分開，今天看似紛繁複雜的 AI coding 生態，立刻就清楚了。

一、先建立一個最重要的四層模型

這四層經常被混在一起，於是才會出現許多似是而非的問題：Kimi K3 能不能執行 CLI？OpenCode 是不是一個模型？Codex 能不能剪影片？Claude 訂閱能不能直接登入 OpenCode？

答案分別是：

• Kimi K3 是模型，本身不執行 CLI；Kimi Code 或其他 agent runtime 才負責執行。
• OpenCode 不是模型，而是一個開源 coding agent 外殼和執行時。
• Codex 可以組織影片剪輯，但真正執行裁剪、轉碼和合成的是 FFmpeg 等本機工具。
• Claude Code 官方用戶端可以使用 Claude 訂閱 OAuth；OpenCode 不能合規地複用這套訂閱憑證。

模型決定上限，agent 決定它怎麼思考和迴圈，工具決定它能做什麼，權限決定它到底能走多遠。

這才是整件事的底層結構。

二、Codex 為什麼能在本機 Mac 上剪影片

Codex 不是 Premiere，不是 Final Cut，也不是剪映，更不是一個內建影片引擎。它能完成影片剪輯，是因為它可以把自然語言要求翻譯成工具呼叫，再在本機反覆檢查結果。

最典型的工作流是：

1. 用 ffprobe 讀取影片的編碼、解析度、幀率、時長和音軌。
2. 根據使用者要求生成 ffmpeg 命令。
3. 執行裁剪、拼接、轉碼、壓縮、抽幀、混音、浮水印或字幕燒錄。
4. 檢查輸出檔案、時長、解析度和編碼是否符合預期。
5. 必要時重新調整參數，再執行一輪。

因此，Codex 在本機最擅長的是確定性剪輯：

說實在的，CLI 剪影片和 GUI 剪影片是兩種完全不同的生產方式。前者像數控工具機，參數明確，結果可重複，適合批次和自動化；後者像剪輯台，依賴畫面觀察、時間軸拖曳、範本和審美判斷。Codex 兩種都能參與，但效率、成本和穩定性並不相同。

三、所謂「滑鼠外掛」，本質是 Computer Use

抖音裡常見的「AI 直接操作剪映」，通常不是某個神祕的剪映專用外掛，而是 Computer Use 一類視覺操作能力。

它的基本迴圈並不複雜：

取得螢幕截圖
    ↓
模型識別視窗、按鈕、文字和目前狀態
    ↓
決定下一步點擊、輸入、捲動或拖曳
    ↓
執行滑鼠鍵盤動作
    ↓
再次截圖並判斷結果

在 macOS 上，這類能力通常需要 Screen Recording 和 Accessibility 權限。它能夠開啟應用程式、點擊按鈕、輸入文字、切換視窗、使用剪貼簿，也就能原則上操作剪映、Photoshop、Excel 或各種沒有 API 的老軟體。

但「能操作」不等於「操作得最划算」。GUI 會遇到彈出視窗、動畫、介面改版、按鈕位移、拖曳誤差和載入延遲。每一步又都需要截圖、視覺理解、動作決策和結果確認，於是一次本來只需一條 FFmpeg 命令的任務，可能變成幾十輪互動。

所以最合理的組合通常是：

• 確定性處理交給 FFmpeg、Shell 和指令碼。
• 必須使用範本、濾鏡、特效或平台專屬能力時，再交給 Computer Use 操作剪映。
• 最終成片仍由人檢查節奏、字幕、畫面和審美。

Computer Use 解決的是「這個軟體沒有開放介面，我仍然要操作它」的問題。它是通用滑鼠和眼睛，不是專業剪輯引擎。

四、為什麼 Computer Use 通常比 CLI 更費額度

問題不在於外掛被單獨收了一道稅，而在於它需要處理的資訊和互動輪次更多。

CLI 任務通常長這樣：

讀取少量文字 → 生成命令 → 執行 → 讀取文字結果

Computer Use 則更接近：

截圖 → 視覺識別 → 定位控制項 → 決策 → 點擊 → 再截圖 → 判斷 → 重試

兩者的消耗差異來自四個地方：

因此，同樣是在 Mac 上完成任務，優先順序通常應該是：API 或結構化工具，其次是 CLI，最後才是 GUI 自動化。不是因為 GUI 不先進，恰恰是因為 GUI 為人類設計，資訊豐富卻不夠確定；CLI 為機器設計，樸素，卻精準。

五、Codex App 與 Codex CLI 不是兩套完全隔離的系統

一個常見理解是：Codex App 和 Codex CLI 分別安裝在兩個路徑，使用兩套設定、兩套 hooks、兩套 Git 和兩套權限。這個判斷只對了一半。

它們確實是不同的互動介面，但共享相當一部分底層狀態。

CLI 更像高效執行器。它離 Shell、Git、測試和日誌最近，在路徑明確、命令明確、目標明確時，通常速度更快、上下文更短、token 性價比更高。

App 更像工程工作台。它的價值不只是套一個圖形介面，而是把任務、執行緒、worktree、瀏覽器、外掛、截圖、Computer Use、長任務和結果預覽組織在一起。它犧牲了一部分極簡性，換來了更強的協調能力。

所以不能簡單說 App 必然比 CLI 低效。如果在 App 裡仍然主要呼叫 Terminal 和結構化工具，差距可能很小；真正顯著增加成本的，是截圖、GUI 操作、瀏覽器長鏈路、多 agent 並行和高強度推理。

安裝位置也確實不同：CLI 通常是一個命令列可執行檔，Desktop App 則位於 macOS 的應用程式目錄。但使用者設定、專案規則和許多執行狀態，會圍繞 ~/.codex 與專案內 .codex 目錄匯合。它們是同一套 Codex 生態的不同駕駛艙，不是互不相識的兩台機器。

六、Codex App 與 ChatGPT App 的市場分工

ChatGPT 與 Codex 的邊界，也不是「一個能聊天，一個能寫程式碼」這麼簡單。

ChatGPT 面向的是通用知識工作：文件、搜尋、分析、寫作、圖片、表格、研究與日常辦公。Codex 面向的是工程執行：程式碼儲存庫、Terminal、Git、測試、worktree、hooks、MCP、程式碼審查、自動化和長期任務。

兩者面對的是不同的高頻使用者。ChatGPT 要成為知識工作者的通用入口；Codex 要成為工程師和自動化工作流的執行中樞。底層模型、外掛架構和部分桌面能力可以共享，但產品的重心完全不同。

七、Codex 與 Claude Code：不是簡單抄襲，而是高速趨同

Claude Code 的先發優勢非常清楚。2025 年 2 月 24 日，Anthropic 隨 Claude 3.7 Sonnet 發布 Claude Code research preview。它從一開始就是 terminal-first 的 coding agent：搜尋程式碼、讀取檔案、編輯、執行測試、呼叫命令列工具，甚至提交和推送程式碼。

OpenAI 在 2025 年 5 月 16 日發布 Codex research preview 時，重點還是雲端軟體工程 agent。此時兩者的產品形態並不相同：Claude Code 已經在程式設計師每天使用的 Terminal 裡形成自然工作迴圈，Codex 更像一個非同步雲端工程師。

隨後差距快速縮小。

從產品史看，Claude Code 是 terminal coding agent 的先發標竿，Codex 則在 2025 年下半年到 2026 年上半年完成了一次非常猛烈的平台化追趕。

能不能因此說 Codex「抄襲」Claude Code？從官方資料無法證明。更準確的說法是：當產業確認「模型加 Terminal 加工具迴圈」是有效形態之後，所有主要廠商都在向同一組工程答案收斂。專案規則檔、hooks、skills、subagents、MCP、權限審批、非互動模式，這些能力會越來越相似，就像瀏覽器最終都會有分頁、網址列和開發者工具。

但是趨同不代表完全相同。

Claude Code 仍然強在哪裡

• Terminal-first 的互動更早成熟，工作流連貫，agent loop 的體感自然。
• CLAUDE.md、hooks、commands、skills 和社群實踐累積較深。
• Claude Sonnet 系列長期在 agentic coding、程式碼理解和複雜重構上口碑穩定。
• 對長期使用 Terminal 的工程師而言，認知負擔很低。

Codex 強在哪裡

• CLI、Desktop App、IDE、Cloud、SDK、Slack 等多種表面協同發展。
• sandbox、exec policy、審批和企業治理體系更強調邊界控制。
• App 中的 worktree、任務並行、可視化審查和桌面工具整合更突出。
• 從單個 coding agent 向多任務工程平台擴張得很快。

所以，到 2026 年再問「誰全面領先」，答案已經不像 2025 年初那麼簡單。Claude Code 在 CLI 手感和成熟度上仍有累積，Codex 在平台廣度、桌面編排和多表面協作上追得極快。差距仍然存在，但已經從代際差距，變成不同設計取向之間的差距。

八、Codex 也有 workflow、loop 和多 agent

Claude Code 的 workflow 和 loop 往往顯得自然：讀取任務、搜尋程式碼、制定計畫、修改、測試、發現問題、再次修改，直到收斂。Codex 也有同類設計，只是官方命名和觸發方式不同。

Codex 使用的主要術語是：

• Agent loop：模型在觀察、行動、驗證之間迴圈。
• Subagents：把子任務委派給獨立 agent。
• Subagent workflows：由主 agent 規劃和協調多個子任務。
• Multi-agent operations：建立、等待、恢復、傳送訊息和關閉 agent。
• Goal mode：圍繞長期目標持續推進，而不是只完成一輪問答。
• Worktrees：讓不同 agent 在隔離的 Git 工作樹中並行修改。

其內部邏輯大致如下：

Codex 內建或常見的 agent 角色包括 default、worker 和 explorer，也允許在使用者或專案設定中定義自有 agent。主 agent 可以執行 spawn_agent、send_input、wait_agent、resume_agent 和 close_agent 等操作。

一個現實差異是：Claude Code 的 agent loop 往往更像預設行為，Codex 的多 agent 編排則更強調顯式委派。使用者如果明確要求「派兩個 agent 分別研究」「每個模組一個 worker」「先讓 explorer 查資料」，通常更容易看到 Codex 的分流過程。

九、中國大陸已經出現真正的 CLI coding agent

中國模型廠商並沒有停留在「提供一個 API，讓別人接入 Claude Code」的階段。到 2026 年，已經出現數個形態完整的 CLI coding agent。

第一梯隊：已經具備完整 CLI agent 形態

第二類：模型很強，但官方 CLI 並非核心產品

國內第一梯隊已經具備 Claude Code/Codex CLI 大約六到八成的產品形態：能理解儲存庫、修改檔案、執行 Shell、呼叫 MCP、使用專案規則、執行非互動任務，也開始支援 subagents、skills 和 hooks。

真正的差距主要不在「能不能改程式碼」，而在更深的工程層：長期任務是否穩定，權限模型是否清晰，複雜任務能否持續收斂，多 agent 是否真正可控，worktree 與 Git 是否成熟，失敗恢復是否可靠，企業稽核和生態是否完善。

功能列表可以在幾個月內追平，工程穩定性和社群方法論需要時間。這一點，才是今天中外 coding agent 最真實的距離。

十、Kimi K3 已經是頂級開放權重 agent 模型，但它不是 CLI

Kimi K3 是 Moonshot AI 發布的開放權重、多模態、面向 agent 任務的模型。官方資料顯示，它採用 2.8T 總參數、104B 啟用參數（每 token 從 896 個專家中啟用 16 個）的稀疏 MoE 架構，支援最高 1M context，並針對程式碼、工具呼叫、瀏覽和長任務進行了重點訓練。

它可以透過 Kimi Code CLI 使用。使用者進入 Kimi Code 後透過 /model 選擇 k3 或 k3-256k，也可以使用 OpenAI-compatible 或 Anthropic-compatible API 接入其他 agent runtime。

但必須再次強調：

Kimi K3 負責理解和決策，Kimi Code 負責讀檔案、執行命令和修改程式碼。

這和 GPT 加 Codex、Claude 加 Claude Code 是同一層關係。

K3 大致相當於什麼水平

按照 Kimi 官方公布的評測，K3 在多個 agentic coding、Terminal、瀏覽和電腦操作基準上，已經進入 Claude Opus 4.6/4.8、GPT-5.5 一帶的競爭區間，部分項目接近或超過更強閉源模型。

例如官方表格中：

表中 K3 資料整理自 Moonshot 官方公布的 Kimi K3 評測（技術部落格與模型頁，連結見文末「Kimi 與中國 CLI Agent」），核對於 2026-08-02——其中 GPQA Diamond 93.5、Terminal-Bench 2.1 88.3、BrowseComp 91.2 與官方數值一致。對比列（GPT-5.5、Claude Opus 4.8）取自各自官方口徑，harness 與推理預算未必對齊，橫向比較僅供參考。

這些數字不能機械理解為「K3 全面超過 Opus」。不同模型可能使用不同 agent harness、推理預算、溫度和工具環境，官方自測也應保留審慎。但它至少說明一件事：K3 已不是廉價替代品，而是可以在真實 coding agent 與長上下文任務中正面對比頂級閉源模型的開放權重模型。

如果拿 2025 年初的 GPT-4.5 做參照，K3 已經明顯更強，尤其是在程式碼、Terminal、工具呼叫、長上下文與 agent 工作流上。GPT-4.5 是當時強大的通用聊天模型，卻不是今天這種為長鏈路工具執行而生的 agent 模型。

更穩妥的結論是：

• K3 明顯超過 GPT-4.5 所代表的上一代通用模型水平。
• 在 CLI 程式設計和工具任務上，可視為 Opus 4.6 級別的有力競爭者。
• 在複雜抽象判斷、超長任務穩定性、表達品質和安全邊界上，不能宣稱全面超過 Claude Opus。
• 日常任務可以優先使用 k3-256k 控制消耗；大型儲存庫和超長資料再使用 1M context 的 k3。

十一、OpenCode 是什麼：開源 agent 外殼，不是模型

OpenCode 的官方定義是「開源 AI coding agent」。安裝它，相當於安裝了一套可在 Terminal、Desktop App 或 IDE 中執行的 agent 系統，而不是下載了一個獨立大模型。

它負責的事情包括：

• 掃描和理解專案目錄。
• 讀取、搜尋、寫入和修改檔案。
• 執行 Bash 命令和測試。
• 呼叫 LSP、MCP、Web Search 與自訂工具。
• 管理 build、plan 和 subagent 等角色。
• 控制工具權限是 allow、deny 還是 ask。
• 把任務狀態、工具結果和歷史上下文重新交給模型，形成 agent loop。

OpenCode 背後仍然必須有一個模型 provider。它透過 AI SDK 與 Models.dev 支援大量雲端模型和本機模型，使用者安裝後通常需要執行：

brew install anomalyco/tap/opencode
cd /path/to/project
opencode

然後在 OpenCode 內完成：

/connect   連接模型供應商
/models    選擇具體模型
/init      初始化專案規則，生成AGENTS.md

模型可以是 Anthropic Claude、OpenAI GPT、Kimi、Qwen、DeepSeek，也可以是 Ollama 等本機模型。設定的本質是 provider_id/model_id，例如：

{
  "model": "anthropic/claude-sonnet-4-5"
}

所以，OpenCode 的商業和技術價值並不在於「它擁有最強模型」，而在於模型可替換。今天接 Claude，明天換 GPT，某些任務用 Kimi，離線環境用本機模型，agent 的工具、權限和專案工作流仍可保留。

這是開源外殼路線最迷人的地方，也是它最現實的代價：你獲得選擇權，同時要自己處理 API、模型差異、上下文費用、權限和相容性。

十二、OpenCode 不能合規複用 Claude Pro/Max 訂閱 OAuth

這是 OpenCode 使用中最容易踩坑，也最需要說清楚的一點。

Claude Code 官方 CLI 支援 Claude Pro、Max、Team 和 Enterprise 等訂閱使用者透過 /login 走 OAuth 登入。但這套授權的用途，是使用者在 Anthropic 自有應用程式中使用 Claude Code。

Anthropic 的官方法律與合規說明明確指出：Claude 的訂閱 OAuth 憑證面向原生 Anthropic 應用程式；第三方開發者和產品不應提供 Claude.ai 登入，也不應代使用者轉接 Free、Pro 或 Max 憑證。第三方整合應該使用 Claude Console API Key，或透過受支援的雲服務商接入。

OpenCode 官方與社群記錄也已經把這件事寫明：過去存在讓 OpenCode 複用 Claude Pro/Max 訂閱的 OAuth 外掛，但 Anthropic 明確禁止這種方式；2026 年 3 月，應 Anthropic 法務要求，OpenCode 移除了內建的 Claude 訂閱 OAuth 外掛與相關 system prompt。

因此，目前穩定、合規的接入方式是：

• 使用 Anthropic Console 建立的 API Key。
• 透過 Amazon Bedrock、Google Vertex AI 等官方支援管道。
• 使用 OpenRouter、Vercel AI Gateway 等第三方 API provider，但需接受其價格、隱私和可用性條款。
• 如果只想消費 Claude Pro/Max 訂閱，使用 Anthropic 官方 Claude Code CLI。

OpenCode 中的典型設定流程是：

啟動 opencode
  ↓
/connect
  ↓
選擇 Anthropic
  ↓
輸入 Anthropic Console API Key
  ↓
/models 選擇 Claude 模型

網路上可能仍能找到第三方 OAuth 外掛、舊教學或繞行方案。它們「暫時能用」不代表合規，也不代表長期穩定。Anthropic 有權限制這類憑證，使用者還要承擔帳號風控與突然失效的風險。

一句話概括：Claude Code 訂閱屬於官方用戶端消費權，Anthropic API Key 才是第三方 agent 的正式通行證。

十三、如何選擇：別先問誰最強，先問任務屬於哪一層

面對 Codex、Claude Code、OpenCode、Kimi Code 和 Qwen Code，最實用的選擇方法不是尋找一個永遠第一的排行榜，而是看自己的任務和約束。

還可以用一條更樸素的決策鏈：

1. 有 API，就先用 API。
2. 有 CLI，就優先用 CLI。
3. 有結構化檔案格式，就直接讀寫檔案。
4. 只有圖形介面時，再使用 Computer Use。
5. 任務能拆分且邊界清楚時，才派多個 agent。
6. 模型越貴、上下文越長，越要控制無效截圖、重複日誌和無邊界探索。

技術世界喜歡炫耀「AI 已經會自己操作電腦」，但真正決定生產力的，從來不是它點了多少次滑鼠，而是它能否選擇正確工具、保持清晰邊界、驗證真實結果，並在失敗之後繼續收斂。

結語：大模型正在從會說話，變成會做事

過去我們評價一個模型，看它知道多少、寫得多好、考試多少分。現在評價一個 agent，要看它能不能進入真實環境，理解專案，呼叫工具，管理權限，拆分任務，發現錯誤，持續修正，最後交付一個可以被驗證的結果。

這是一場從「語言智慧」到「行動智慧」的遷移。

Claude Code 率先證明了 Terminal 可以成為大模型的工作場；Codex 用極快速度把這套能力擴展到 App、Cloud、SDK、worktree 和多 agent；OpenCode 把外殼開源，讓模型成為可以更換的大腦；Kimi、Qwen、騰訊和字節則證明，中國廠商已經不再滿足於只提供模型 API，而是在爭奪 agent runtime、CLI 入口和開發者工作流。

說到底，未來真正有價值的，不是某一個模型在某一天多領先三分，而是誰能建立一套穩定、可控、可遷移、可驗證的工作制度。模型會換，價格會降，榜單會變，訂閱政策甚至可能一夜之間收緊；但專案規則、工具體系、知識資產、權限邊界和工作流，可以留下。

大腦終會越來越多。真正稀缺的，是身體，是秩序，是讓智慧持續做成事情的能力。

也許，這才是 CLI agent 革命真正開始的地方。

官方資料與延伸閱讀

OpenAI Codex

• Introducing Codex
• Codex is now generally available
• Introducing the Codex app
• Codex Hooks
• Git worktrees
• Subagents
• Computer Use
• GPT-5.5 model documentation
• GPT-5-Codex model documentation

Claude 與 Anthropic

• Claude Code authentication
• Claude Code legal and compliance
• Claude API authentication

OpenCode

• OpenCode GitHub repository
• OpenCode documentation
• OpenCode providers
• OpenCode models
• OpenCode agents
• OpenCode tools

Kimi 與中國 CLI Agent

• Kimi K3 GitHub repository
• Kimi K3 官方技術部落格（含評測資料）
• moonshotai/Kimi-K3 · Hugging Face（開放權重與模型卡）
• Kimi Code models
• Kimi Code GitHub repository
• Qwen Code GitHub repository
• Qwen3-Coder introduction
• Trae Agent GitHub repository
• Tencent CodeBuddy CLI documentation
• DeepSeek agent integrations