Token Efficiency 是什麼？從 DeepSeek V4 看大模型規劃、小模型執行

Fri, 15 May 2026 08:59:33 +0800

AI 程式設計接下來真正重要的指標，可能不是“誰的模型最強”，而是誰能用更少的 token、更低的成本、更穩定的流程，完成更多可驗收的工作。

這就是 Token Efficiency 的價值。

很多人理解 Token Efficiency，只會想到模型便宜、上下文變長、快取命中更低價。但這些只是底層條件。真正能把它變成生產力的，是模型分工、任務編排、上下文預算和評估體系。

換句話說，Token Efficiency 不是省錢技巧，而是一套把 token 轉換成產出的工程方法。

DeepSeek V4 的定位：把大小模型分工產品化

這篇文章最應該先補上的背景，是 DeepSeek V4 的定位。

DeepSeek V4 不是單純釋出一個更強模型，而是把 Token Efficiency 需要的兩層能力直接拆成了 V4 Pro 和 V4 Flash：Pro 更適合做規劃、推理、架構判斷和關鍵審查，Flash 更適合做高頻執行、批次改寫、程式碼補全、資料整理和 agent 迴圈裡的普通節點。

這正好對應 AI 程式設計裡的兩個角色：

V4 Pro：當作 planner / consultant，用在需求拆解、技術方案、複雜 bug 根因、架構審查和最終驗收。
V4 Flash：當作 executor，用在檔案掃描、簡單實現、測試補齊、文件整理、候選方案生成和重複性任務。

DeepSeek 官方 API 文件顯示，V4 Flash 和 V4 Pro 都支援 1M 上下文、JSON Output、Tool Calls、Chat Prefix Completion 和 FIM Completion；價格頁也把快取命中輸入單獨計價，並說明全模型 input cache hit 價格已降到釋出價的十分之一。這幾個點組合起來，才是它和 Token Efficiency 關係最密的地方。

1M 上下文解決的是複雜 agent 任務容易被壓縮的問題；低快取命中價格解決的是長系統 prompt、專案文件、程式碼片段和歷史狀態反覆進入上下文的成本問題；Flash / Pro 雙模型形態解決的是“每一步都用旗艦模型太貴、每一步都用小模型又不穩”的分工問題。

所以 DeepSeek V4 的優勢不應該只寫成“便宜”或“上下文長”，而應該理解成三件事：

執行層便宜：大量 agent 節點可以交給 V4 Flash，讓 token 消耗落在低成本模型上。
判斷層可用：關鍵步驟仍然可以呼叫 V4 Pro，避免為了省錢犧牲複雜推理質量。
長鏈路友好：1M 上下文和快取價格讓程式碼庫、文件、工具呼叫歷史更容易留在可用視窗裡。

這就是為什麼 DeepSeek V4 對 AI 程式設計的意義，不只是又多了一個模型選項，而是給“顧問模型 + 執行模型 + harness 編排”的模式提供了更現實的成本結構。

不要讓最強模型幹所有活

過去使用 AI，常見做法是找一個最聰明的模型，讓它從需求分析、程式碼實現、測試、總結一路幹到底。

這個方式簡單，但不一定高效。因為很多工並不需要最高階別的推理能力。真正貴的模型，應該更像顧問、架構師或規劃員：只在關鍵決策點介入。

更合理的結構是：

大模型負責拆問題、定方向、做關鍵判斷。
小模型負責執行、批次處理、重複修改。
工具和 harness 負責流程、狀態、上下文和驗證。
人負責定義產品、驗收結果和決定取捨。

這樣做的好處是，前沿推理能力不會被浪費在機械執行上。大部分 token 消耗可以落到便宜模型和快取輸入裡，貴模型只處理真正需要“腦力”的部分。

上下文不是越大越好

長上下文很重要，尤其是 coding agent。程式碼、文件、歷史對話、測試輸出、錯誤日誌都會吃掉上下文。上下文一旦接近上限，模型就容易觸發壓縮、遺忘或誤判。

但長上下文不等於可以無限塞資料。

Token Efficiency 的關鍵，是讓每個任務都能在一個清晰、可控的上下文視窗內完成。最理想的狀態不是“把整個倉庫塞進去”，而是：

當前任務只帶必要檔案。
背景文件只帶決策相關部分。
歷史資訊只保留當前階段需要的狀態。
每個節點有明確輸入和輸出。
完成後把結果壓縮成結構化摘要，交給下一個節點。

上下文越便宜，越要警惕浪費。便宜 token 會誘導人把無關資訊全塞進去，最後模型不是更聰明，而是更容易被噪聲拖慢。

Harness 比單個模型更重要

如果只是把 Claude Code、Codex 或其他 coding agent 接到便宜模型上，效果未必好。小模型容易在長鏈路任務裡跑偏，需要更強的流程控制。

真正讓小模型發揮價值的，是 harness。

這裡的 harness 可以理解為一套排程系統：它知道任務怎麼拆、節點怎麼跑、模型怎麼選、結果怎麼驗收、失敗怎麼重試、上下文怎麼傳遞。

一個可用的編排系統，至少要回答幾個問題：

哪些任務需要規劃？
哪些任務可以直接執行？
哪些節點可以並行？
哪些節點必須序列？
哪個節點用大模型，哪個節點用小模型？
每個節點最多允許多少上下文？
每個節點完成後輸出什麼結構？
誰來 review，誰來決定是否繼續？

沒有這層軟體，小模型只是便宜；有了這層軟體，小模型才可能變成槓桿。

用 DAG 拆任務

一個有效的思路，是把複雜任務拆成有向無環圖，也就是 DAG。

比如一個功能開發任務，可以拆成：

需求澄清
方案設計
任務拆分
編碼實現
測試補齊
Code Review
修復問題
提交 PR

每個節點都可以是一個獨立 agent。它們執行在獨立環境裡，有自己的角色、prompt、工具許可權和輸出格式。節點之間不靠長篇聊天傳遞資訊，而是靠預先定義好的結構化結果。

這會帶來兩個直接收益。

第一，單個節點更短。任務越小，越容易被小模型完成，也越不容易撐爆上下文。

第二，流程更可測。你可以單獨觀察“編碼節點失敗率高”還是“review 節點漏問題多”，然後針對性最佳化。

任務可以跑多個副本

當 token 足夠便宜時，一個有趣的變化會出現：同一個任務不一定只跑一次。

你可以讓同一個任務用不同模型、不同 prompt、不同編排跑多個副本，再從結果裡選最好的，或者把多個結果合併。這個思路有點像“抽卡式任務解決”，但前提是必須有評估和驗收。

適合多副本的任務包括：

方案設計
文案生成
測試用例補全
Bug 根因假設
重構方案比較
Code Review

不適合盲目多副本的任務，是那些會直接修改共享狀態、會產生外部副作用、或者驗收標準不清楚的任務。

多跑幾次不是為了碰運氣，而是為了獲得可比較樣本。樣本越多，越能反過來最佳化編排、模型選擇和節點技能。

必須建立評估體系

Token Efficiency 不能只看價格。便宜但失敗率高，最後會吞掉人的時間，反而更貴。

所以每個團隊都應該逐步建立自己的評估體系。它不需要一開始就很複雜，但要能量化。

可以先記錄這些指標：

任務完成率
人工介入次數
工具呼叫失敗率
測試透過率
Review 發現的問題數量
單任務 token 成本
單任務耗時
返工次數
不同模型組合的差異

有了這些資料，才能知道哪些任務適合小模型，哪些任務必須上大模型，哪些任務應該交給人判斷。

真正的最佳化不是“所有地方都換便宜模型”，而是把每類任務放到最合適的模型和流程裡。

業務流程要原子化

普通使用者不一定要自己寫完整 harness。未來這類工具會越來越多，也會越來越成熟。

但現在就可以做一件事：把自己的業務流程拆成原子節點。

比如內容生產可以拆成：

選題
資料收集
提綱
初稿
事實核查
風格改寫
SEO 標題
多語言翻譯
釋出檢查

軟體開發可以拆成：

需求確認
技術方案
資料結構
介面變更
單元測試
實現
遷移指令碼
文件
Review

每個節點都要儘量做到輸入明確、輸出明確、驗收明確、上下文可控。這樣等 harness 工具成熟時，你的業務流程可以直接接進去。

硬體不是第一優先順序

很多人聊 Token Efficiency，很快就會聊到本地部署和顯示卡。但對大多數人來說，第一選擇仍然應該是 API。

原因很簡單：在沒有跑通經濟模型之前，本地硬體只是成本前置。你還不知道 token 怎麼轉化成收入或生產力，就先買昂貴裝置，很容易變成玩具。

更穩的順序是：

先用 API 跑通業務流程。
建立任務評估和成本統計。
找到穩定高頻的執行節點。
再考慮哪些節點值得本地化。
最後再計算硬體、電費、維護和折舊。

如果只是個人提效，API 往往已經夠用。如果是創業團隊，要驗證模型邊界和推理框架，本地 CUDA 平臺才更有學習價值。如果已經有明確生產場景和經濟模型，多卡部署才有討論空間。

小結

Token Efficiency 的本質，不是“用便宜模型替代貴模型”，而是重新設計 AI 工作流。

大模型負責關鍵判斷，小模型負責批次執行，harness 負責排程和驗證，人負責定義目標和驗收結果。只有這四層配合起來，token 才能穩定變成生產力。

接下來真正有價值的能力，不只是會用最新模型，而是能把任務拆小、把上下文控住、把結果量化、把流程編排起來。

模型會繼續降價，上下文會繼續變長，小模型會繼續變強。越是這樣，越應該早點理解 Token Efficiency。因為未來的差距，很可能不在誰呼叫了最強模型，而在誰能用同樣的 token 撬動更多真實產出。

該放棄 MCP 嗎？為什麼 CLI 正在成為 Agent 的預設工具層

Fri, 10 Apr 2026 21:55:12 +0800

過去一年，關於 Agent 工具鏈的爭論越來越集中在一個問題上：

MCP（Model Context Protocol）是讓工具調用更簡單，還是把原本簡單的事情變複雜？

在大多數日常開發任務中，CLI 正在成為更實用的預設方案。

成本差異不是「體驗問題」，而是數量級問題

MCP 最大的現實壓力是 token 開銷。

在常見場景裡，MCP 在真正執行任務前，往往需要先載入大量工具 schema。以 GitHub MCP Server 為例，初始化就可能消耗數萬 tokens。對長任務而言，這會直接擠壓上下文預算。

社群基準測試也反覆指向同一個結論：

MCP 單次調用成本常見是 CLI 的數倍到數十倍
失敗重試成本也更高（要重建連線、重新載入上下文）

這不是「慢一點」的差距，而是會放大成 API 成本、延遲與穩定性問題。

為什麼模型天然更「會用 CLI」

一個常被忽略的事實是訓練分布。

LLM 在訓練中看過海量終端文本：命令、輸出、報錯、腳本、man page。也就是說，CLI 互動模式本來就接近模型的「母語輸入」。

相對地，MCP 的 JSON-RPC 與 tool schema 是近兩年才大規模出現的新範式。模型當然能學會，但熟悉度與壓縮效率通常仍不如 CLI 這類歷史語料。

這也解釋了為什麼很多時候：

同樣目標，CLI 指令更短
輸出更適合直接持續推理
錯誤恢復路徑更穩定

安全與隔離：MCP 還有補課空間

MCP 不是不能做安全，而是生態還在早期。

當前常見擔憂包括：

工具描述投毒（Tool Poisoning）
服務行為漂移（Rug Pull）
同名工具覆蓋（Shadowing）

CLI 當然也有安全問題（注入、越權、路徑風險），但它的進程模型、權限邊界、審計鏈路已經過數十年工程實踐驗證。對生產環境而言，這種「可預期性」很重要。

這不等於 MCP 沒價值

我不認為 MCP 應該被拋棄。

更合理的定位是：

CLI 負責執行層（本地、低延遲、高頻調用）
MCP 負責連接層（遠端服務發現、統一認證、審計與多租戶）

也就是常說的混合架構：CLI + MCP Gateway。

在需要對接大量遠端系統、做統一權限治理與合規審計時，MCP 仍然有明顯價值；但在「讓 Agent 快速完成開發任務」這件事上，CLI-first 往往更符合當前模型能力邊界。

在今天的工程現實裡，CLI 更像 Agent 的工作母語；MCP 更適合作為連接協議，而不是唯一執行協議。

Token Efficiency on KnightLi的博客