AI Coding 模型與 Agent 工具：2026 年 7 月最新全景

AI coding 市場已經不存在一張有意義的總排行榜。到了 2026 年 7 月，每一家主要實驗室賣的都不只是模型組合，還有一套 agent harness（代理執行框架）：模型負責判斷，harness 負責工具、權限、平行 worker、持久化與執行環境。

這個區分很重要。最強模型如果被放進一個很薄、容易中斷的終端迴圈，未必適合長時間 migration；稍小一點的模型若搭配成熟的 worktree、狀態保存與 resume，反而更可能真的把工作做完。現在選 AI coding stack，必須同時選這兩層。

資料快照：2026 年 7 月 19 日。 模型 alias、Preview 標籤、配額與產品可用性都變得很快。本文會明確標示 Preview／Experimental，並連到各家目前的官方文件；請不要把這張表當成永久不變的排名。

先看結論

供應商	目前模型階梯	主要 coding agent 介面	重要狀態
Anthropic	Fable 5、Opus 4.8、Sonnet 5、Haiku 4.5	Claude Code：CLI、IDE、desktop/web、subagent、dynamic workflow、Agent Teams	Fable 5 已 GA；Agent Teams 仍為 Experimental
OpenAI	GPT-5.6 Sol、Terra、Luna	Codex desktop、CLI、IDE、cloud、`exec` 與 SDK	不同介面成熟度不同；`codex exec` 為 Stable，部分 cloud/app-server 指令仍是 Experimental
Google	Gemini 3.5 Flash、3.1 Pro Preview、3.1 Flash-Lite	Antigravity／Antigravity CLI、Gemini API Managed Agents、Jules	3.1 Pro 是 Preview；消費者版 Gemini CLI 已轉向 Antigravity CLI
xAI	Grok 4.5	Grok Build 終端 agent 與開源 harness	Grok Build 以 Early Beta 推出；7 月 15 日公開原始碼

沒有一個工具在所有工作都贏。真正有用的問題是：在這種 workload、這種故障模式與這個規模下，哪個組合最合適？

Anthropic：四個模型層級，多種平行工作邊界

Anthropic 的目前模型總覽列出四個主要公開層級：

Claude Fable 5（claude-fable-5）是最強的廣泛發行模型，定位在長時間 agent 與最困難的判斷工作。
Claude Opus 4.8（claude-opus-4-8）適合複雜 agentic coding、大型重構與企業工作。
Claude Sonnet 5（claude-sonnet-5）以速度與智慧的平衡，承擔日常實作。
Claude Haiku 4.5（claude-haiku-4-5-20251001）仍是最快、最經濟的層級，適合 fan-out、掃描與高量支援工作。

實際策略不是「所有地方都用 Fable」，而是便宜地扇出，昂貴地判斷：讓 Haiku 或 Sonnet 找檔案、跑機械式檢查，再把架構、對抗式驗證與最終綜合交給 Fable 或 Opus。

Claude Code 現在有好幾種平行工作抽象，不應混為一談：

標準 subagent 有自己的 context，最後把結果回傳給 caller。從 Claude Code v2.1.172 起，subagent 已能再 spawn nested subagent，固定最多五層。只有最上層 subagent 的摘要需要回到主 conversation；depth 5 的 agent 不再取得 Agent tool。
Agent Teams 是多個獨立 Claude Code instance，共用 task list，teammate 之間能直接傳訊。它目前仍是預設關閉的 Experimental 功能。Teams 消耗更多 token，不會自動把每個 teammate 隔離到 worktree，而且不能建立 nested team。
Dynamic workflows 把大規模編排放進 workflow 結構，在背景執行，並用 /workflows 觀察。近期版本又加入 workflow size 與 telemetry 控制，見 Claude Code v2.1.202 release。
Background session 與 worktree 適合需要完整 session 壽命或獨立 checkout 的任務，而不是只回傳一次結果的短委派。

這是目前最豐富的原生編排選單之一，但它不是一棵可以無限往下長的 subagent 樹；五層上限固定，而且每種抽象都有不同的生命週期與協調邊界。

OpenAI：GPT-5.6 加上最廣的 Codex 介面

OpenAI 的模型目錄把 GPT-5.6 變成三層選擇：

GPT-5.6 Sol（gpt-5.6-sol，gpt-5.6 是建議起點 alias）是複雜專業推理與 coding 的旗艦。
GPT-5.6 Terra（gpt-5.6-terra）平衡智慧、延遲與成本。
GPT-5.6 Luna（gpt-5.6-luna）面向成本敏感、高吞吐量工作。

這個分層和 Anthropic 的角色分配很像：Sol 負責模糊、多步驟工作與最後決策；Terra 負責日常 agent 與支援 reviewer；Luna 負責量。最終映射仍要用自己的 repository 評測，因為供應商 benchmark 不會反映你的 build 時間、工具可靠性與專案規範。

Codex 的差異化，在於同一個工作模型涵蓋很多產品介面：ChatGPT desktop、終端 CLI、IDE 與 cloud。自動化方面，codex exec是 Stable 的非互動指令，可輸出一般文字或 JSONL，也能 resume 先前的 exec session。嵌入自家系統時，Codex SDK用 TypeScript 與 Python 提供可延續的 coding thread；其中 Python SDK 目前仍是 Beta。

Codex 也確實支援遞迴委派，但安全預設刻意很淺。依照設定參考，agents.max_depth 預設為 1：root 可以產生直接 child，但 child 不能再生 descendant，除非你主動提高設定。更深的樹是「可設定」，不是免費能力——它會同步放大 token、延遲、本機資源壓力與失控 fan-out 的風險。agents.max_threads 預設為六並限制並行數，卻不能讓一個邊界不清楚的遞迴計畫自動變可靠。

如果你想讓同一套 agent 環境跨越互動工作、scripted exec、SDK 程式控制與可調深度的 subagent tree，Codex 很合適。但「可以疊更多層」是一個控制面，不是品質分數。

Google：Gemini 3.5 Flash，以及全面轉向 Antigravity

Google 的 Gemini 模型頁把 production 狀態標得相當清楚：

Gemini 3.5 Flash 是 Stable，官方稱它為適合持續型 frontier agentic 與 coding 工作的最聰明模型。
Gemini 3.1 Flash-Lite 是 Stable，針對速度、規模與成本效率最佳化。
Gemini 3.1 Pro 仍是 Preview，即使它定位在進階推理與 coding。Preview endpoint 可能有更緊的限制與更短的淘汰通知期。

大多數新的 production integration，都應先把 3.5 Flash 當基準。大量分類、掃描與簡單 tool call 可先測 3.1 Flash-Lite。只有當 3.1 Pro Preview 在你自己的 eval 中明顯獲勝，而且你能承受 Preview 生命週期風險時，才應押它。

工具面的變化比模型更大。Google 已宣布從 Gemini CLI 轉向 Antigravity CLI。自 6 月 18 日起，舊路徑不再替免費／consumer、Google AI Pro 與 Google AI Ultra 提供 Gemini CLI 與 Gemini Code Assist IDE request；Standard 與 Enterprise 客戶不在這次 consumer cutoff 內。

Antigravity CLI 保留 Gemini CLI 的關鍵概念——skills、hooks、subagents，以及改包成 plugin 的 extensions——但 Google 也明確說第一版不會一比一功能相等。方向是一個統一、server-backed 的 multi-agent platform，與 Antigravity 2.0 共用 agent harness，支援非同步背景 workflow。它很適合 Google 生態的 agent 工作，但 migration testing 是採用流程的一部分，不是之後有空再做的清理。

Jules 是另一種工具，不只是舊 CLI 換名字。 Jules 仍是Public Beta、整合 GitHub 的 cloud coding agent。每個 task 啟動 fresh VM，非同步工作，最適合有範圍的 repo 任務、scheduled maintenance、CI repair 與 PR delivery。想「丟工作，晚點回來收 PR」就選 Jules；想在終端裡互動並編排多 agent，才是 Antigravity CLI 的場景。

xAI：Grok 4.5 與剛開源的 Grok Build Harness

xAI 在 7 月 16 日推出 Grok 4.5，定位為目前最強的 coding、agentic task 與 knowledge work 模型。它已可經 xAI API 使用，也成為 Grok Build 的預設模型。

Grok Build 是終端 coding agent，提供 plan review、diff、AGENTS.md、skills、plugins、hooks、MCP、平行 subagents 與 worktree integration。-p headless mode 讓它能被 script 與 automation 呼叫，ACP 則提供另一個整合邊界。產品在 5 月以 Early Beta 推出，因此可靠性與介面變動都必須納入評估。

7 月最值得注意的是架構透明度：xAI 在 7 月 15 日開源 Grok Build 的 agent loop 與 TUI。公開程式碼涵蓋 context assembly、tool dispatch、終端 UI 與 extension system，也能 local-first build 並指向本機 inference。開源讓 harness 可檢查、可擴充；它本身不保證 hosted model、配額或 Beta 介面永遠不變。

如果你要的是快速、terminal-first、可讀原始碼，而且能讓很多 worker 各自在 worktree 平行執行，Grok Build 很有吸引力。但在這份快照裡，Grok 4.5 與開源版都只有幾天歷史；先拿一個有代表性的 repo 實測，不要直接全面 migration。

按 Workload 選，不要按 Logo 選

工作類型	建議先測	原因
架構、模糊除錯、對抗式驗證	Fable 5 或 GPT-5.6 Sol	在錯誤決策最昂貴的地方使用 frontier tier
有人類 review 的日常實作	Sonnet 5、GPT-5.6 Terra 或 Gemini 3.5 Flash	智慧、延遲與吞吐量較平衡
高量掃描與機械式 fan-out	Haiku 4.5、GPT-5.6 Luna、Gemini 3.1 Flash-Lite	支援工作很少需要最昂貴的判斷層
大規模 Claude-native 編排	Claude Code dynamic workflows	Workflow 結構、背景執行與原生監控
desktop、CLI、IDE、cloud 與嵌入式 automation 共用一套	Codex	介面廣，另有 Stable `exec` 與 SDK 控制
Google 生態的非同步 multi-agent 工作	Antigravity CLI	統一的 Google agent harness 與背景 workflow
遠端執行 GitHub task 並回傳 PR	Jules	Cloud VM、排程、CI loop、非同步交付
Terminal-first 平行工作且要能檢查 harness	Grok Build	Headless、subagents、worktrees 與開源 agent loop

比「哪個模型最強」更好的評測法

用同一個真實任務跑過每個候選 stack，記錄五件事：

**Patch correctness：**修對了嗎？有沒有造成 regression？
**Verification discipline：**有沒有跑對測試，並誠實回報失敗？
**Recovery：**中斷後能否 resume，而不是重做或忘記？
**Isolation：**平行 worker 能否避免撞檔案、撞狀態？
**總完成成本：**把重試、人類 review 時間與失敗 run 一起算，不只看 token 單價。

短而乾淨的任務，模型智慧通常主導結果；長而混亂的任務，harness 架構會開始主導。因此，2026 年 7 月最好的配置常是一個 portfolio：frontier model 負責決策、便宜 worker 負責 fan-out，再依任務真正的生命週期選 process boundary。

最後結論

Anthropic 現在有最清楚的「便宜 worker 到高判斷模型」階梯，也提供最多種 Claude 原生協調方式。OpenAI 把 GPT-5.6 與最廣的 Codex 介面、可調深度的遞迴 subagent 結合。Google 以 Gemini 3.5 Flash 提供很強的 Stable coding baseline，但 consumer 工具使用者必須理解 Gemini CLI 到 Antigravity 的遷移。xAI 則在 Grok 4.5 成為預設 coding model 的同時，讓 Grok Build 變得異常可檢查，只是 CLI 仍很年輕。

不要孤立地購買一個 benchmark 冠軍。你需要選的是模型角色、process boundary 與失敗恢復方式。這三件事，才決定 agent demo 能不能變成可靠的工程系統。

官方資料：Anthropic models、Claude Code subagents、Claude Code Agent Teams、OpenAI models、Codex non-interactive mode、Gemini models、Antigravity transition、Jules FAQ、Grok 4.5、Grok Build open source。