# Kimi K3 實戰：親身體驗與 Claude Code 比較

> 速度、token 用量、快取，以及與多代理設定的相容性：作者的親身經驗與已發表的獨立基準測試。

Source: https://ailoot.ai/blog/zh-hant-tw/kimi-k3-hands-on-review/
Canonical: https://ailoot.ai/blog/zh-hant-tw/kimi-k3-hands-on-review/
Language: zh-Hant-TW
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-163
Revision: sha256-f5a1c5d7a718e3fdc151cda3c355eeee9e6084bdbbf49a2468871fa9be347a45


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

7 月 25 日，Kimi K3 評測建議實際測試看看：花一天時間設定，看看是否值得。我親自試了。在基準測試中，這個模型的前端工作排名第一，在終端機任務上勝過 Claude。在我的任務中，它的速度慢了兩倍，消耗的 token 明顯更多，也打亂了多代理協作。

</div>

<div class="aside" data-semantic="ailoot-docs-link" role="note" aria-label="Ailoot documentation">

[Ailoot 文件](https://ailoot.ai/docs/)說明如何連接模型及使用 API。

</div>

## 作者的實驗結果如何

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

7 月 25 日，我發布了 Kimi K3 評測，並在結尾建議花一天時間調校，看看切換是否值得。接著我在頻道裡說我正在測試這個模型，而且感到驚喜。最初幾個小時確實如此。之後開始了與多個代理長時間工作的階段，情況就變了。

</div>

Kimi K3 於 2026 年 7 月 16 日推出。它有 2.8 兆個參數、100 萬 token 的上下文視窗、開放權重，並在盲測前端比較中排名第一。我已在[Kimi K3 與 Claude Code 完整評測](https://ailoot.ai/blog/zh-hant-tw/kimi-k3-vs-claude-code/)中整理了架構、基準測試和價格的所有細節，因此不在這裡重複。

在那篇評測的結尾，我寫道：風險是花一天時間設定；回報則是從第二週起帳單會降低。我用自己的任務進行了實驗。

最初幾個小時確實令人興奮。模型會積極接手任務，產出連貫的前端成果，面對大型檔案也毫不遲疑。這就是我在頻道裡發文說自己感到驚喜的原因。問題是在長時間工作、多代理協作、反覆編輯，以及晚上使用終端機時浮現的。

最後，我恢復了原本的設定。以下是促使我做出這個決定的原因，並附上數據和第一手來源連結，讓你可以自行查證。

## 為什麼基準測試顯示 Kimi K3 勝過 Claude？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

在特定領域中，Kimi K3 的基準測試表現確實勝過 Claude：終端機任務、長時間工程工作，以及盲測前端比較。但若看完整的 35 項基準測試，結果就不同了：Claude Fable 5 贏了 22 項，Kimi K3 贏了 12 項，另有 1 項平手。兩種說法都正確，只是前一種更常被引用。

</div>

以下是 Kimi K3 勝過 Claude Fable 5 的基準測試：

| 基準測試           | Kimi K3 | Claude Fable 5 | 差距 |
|--------------------|---------|----------------|------|
| Terminal-Bench 2.1 | 88.3    | 84.6           | +3.7 |
| SWE-Marathon       | 42.0    | 35.0           | +7.0 |
| BrowseComp         | 91.2    | 88.0           | +3.2 |
| Program Bench      | 77.8    | 76.8           | +1.0 |

llm-stats彙整了這些基準測試；每一列都是與 Claude Fable 5 比較。

數據是真實的。同一份彙整中的全部 35 項基準測試裡，Claude Fable 5 贏了 22 項，Kimi K3 贏了 12 項，另有 1 項平手。

更有意思的是 Kimi K3 表現較差的項目。它在程式編寫基準測試中的差距不大，約為 4–5 分；但在知識和推理方面就落後了：在 HLE 上，Claude 領先將近 10 分。長時間任務正是在這裡碰壁：你得先理解，之後才能寫。

Moonshot 在發布文章的主要章節中如此描述：

<figure>
<blockquote>
<p>雖然整體而言仍落後於最強大的封閉模型 Claude Fable 5 和 GPT 5.6 Sol，但 Kimi K3 在我們整套基準測試中展現了前沿水準。</p>
</blockquote>
<figcaption>— Moonshot AI，https://www.kimi.com/blog/kimi-k3</figcaption>
</figure>

## 為什麼實際使用時 Kimi K3 感覺慢了兩倍？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

Kimi K3 回傳第一個 token 的速度是 Claude 的兩倍，但接下來的串流速度卻慢了兩倍。在短暫聊天中會覺得很快；用來完成工作任務時，等完整回應的時間明顯更長。獨立基準測試顯示，它的速度是每秒 34.7 個 token，而 Claude Opus 4.8 為 61.3 個。

</div>

| 指標                    | Kimi K3       | Claude Opus 4.8 |
|-------------------------|---------------|-----------------|
| 輸出速度                | 34.7 tokens/s | 61.3 tokens/s   |
| 首個 token 所需時間     | 4.19 s        | 9.50 s          |
| 智慧指數                | 57            | 56              |
| 每百萬 token 平均價格   | $2.31         | $3.85           |

比較採用 Claude Opus 4.8，這是 Claude 有完整速度測試數據的版本。

Kimi K3 較早開始回應，所以在短暫聊天中主觀上感覺比較快。工作時，時間花在另一件事上：等待完整回應慢慢送達。在這方面，它的速度幾乎慢了一半；回應越長，差距累積起來就會多出幾分鐘。

Kimi Code 宣稱速度可達每秒 180–260 個 token，和我的 34.7 相比，這個數字看起來很有說服力。但它指的是前一代的高速版本 K2.7 Code HighSpeed。Kimi K3 根本沒有這種版本，而獨立基準測試測量的就是 Kimi K3 本身。



## 如果推理無法關閉，token 都花到哪裡去了？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

Kimi K3 的推理完全無法關閉。若直接透過 API 呼叫模型，預設會採用最高的努力程度，而且每個請求都會進行推理，包括簡單的請求。

</div>

你可以降低努力程度；文件列出三個等級：low、high 和 maximum。但無法完全關閉推理：文件明確指出，Kimi K3 的推理及其歷史記錄始終啟用。直接呼叫 API 時，預設為最高等級，而大多數包裝程式不會更改這項設定。



每一輪都會增加數千個輸出 token，每百萬個收費 $15。此外，Moonshot 要求你傳回助理的完整訊息，包括推理歷史；這些輸出 token 到了下一輪又會成為輸入 token。

因此，同一份推理內容你要付兩次費用：第一次是模型寫出來時，第二次是你把它傳回模型時。

在整體指標上，Kimi K3 的輸出 token 數量比前代 K2.6 少了 21%。相較於自己的前一版本，這個模型更省了。但在相同任務中，Claude 仍然用得更少。

提示「hi」會按 86 個 token 計費。底層有一段約 85 個 token 的隱藏系統提示，而且每次請求都會向你收費。

我另有一篇評測說明如何計算用量，以及在哪裡查看剩餘額度：[Claude Pro 和 Max 提供多少 token](https://ailoot.ai/blog/zh-hant-tw/claude-pro-max-usage-limits/)。那裡的計算方式相同，只有價格不同。

## 模型陷入推理迴圈時會發生什麼？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

Kimi K3 有好幾次陷入迴圈：推理區塊開始重複同一段文字，接著碎裂成音節片段，而下層代理則一動也不動。這種情況不只發生在我身上。Moonshot 自己的已知問題清單裡，也不只一次出現這類迴圈的回報。

</div>

情況看起來是這樣：模型開始思考，但沒有推進思路，文字反而陷入重複：同一個詞，接著變成音節片段，無止盡地循環。token 計數器持續轉動，任務卻停滯不前。

Moonshot 已知問題中的 7 月 28 日回報描述 Kimi K3 連續六次嘗試讀取同一個檔案，收到「no-op call, file hasn’t changed since the previous read」拒絕訊息七次，接著若無其事地結束回合。在Kimi CLI issue tracker中，作者列出四種同類型的卡住情況——讀取、取代、測試和分析——並用一句話總結：

<figure>
<blockquote>
<p>即使已經讀過檔案好幾次，我還是會繼續讀。即使成功完成取代，我還是會繼續執行。這些死迴圈耗掉了大量 token。</p>
</blockquote>
<figcaption>— 開發者，Kimi CLI issue tracker，</figcaption>
</figure>

Moonshot 直接說明了原因。模型是在保留推理歷史的模式下訓練的，而且需要完整收到過去的推理內容。如果收到的歷史不完整，模型就會試著重建答案，產生相同的工具呼叫，然後再次陷入迴圈。

第三方請求路由器中的一篇分析作者也提出相同診斷：Kimi 嚴格到會拒絕推理歷史不完整的請求。外部包裝程式不知道它有這項嚴格要求，於是截斷了歷史。

## 為什麼多代理設定在 Kimi K3 上會崩潰？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

Claude Code 連接 Moonshot API 時，部分功能會出問題。WebFetch 完全不受支援，延遲載入工具會讓請求回傳 400 錯誤，而這類錯誤發生幾次後，工作階段甚至不再回應純文字。問題出在 Claude Code 與 Moonshot API 的介面交界處。

</div>

[Moonshot 官方文件](https://platform.kimi.ai/docs/guide/claude-code-kimi)明確指出：他們的 API 尚未支援 WebFetch。換句話說，通常會連線到網路擷取網頁的 Claude Code，在 Kimi K3 上無法這麼做。替代方法是手動貼上內容，或連接第三方工具。

Claude Code 可以按需求載入工具，並在歷史記錄中放入 `tool_reference` 類型的服務區塊。Kimi 不接受這種類型，並回傳 400 錯誤。錯誤訊息沒有指出欄位或原因：

```
{"error":{"type":"invalid_request_error","message":"Invalid request Error"},"type":"error"}
```

作為比較，以下是 Anthropic 原生 API 遇到相同錯誤時的樣子；至少伺服器會指出欄位，並列出接受的類型：

```
messages.166.content.0.tool_result.content.0: Input tag 'tool_reference' found
using 'type' does not match any of the expected tags: 'document', 'image',
'search_result', 'text'
```

這個差異很重要。第一則訊息根本無從診斷：用戶端和背後的人都無法判斷是哪個區塊遭到拒絕。報告作者抱怨的正是這件事。提供者切換工具的開發者已經建議，對 Kimi 預設停用工具延遲載入，或將 Moonshot API 標記為不接受這些區塊。

另一份報告描述了後果；報告於 7 月 17 日建立，至今仍未獲回覆。作者在單一工作階段中遇到這項錯誤七次。工作階段撐過了前六次，第七次則徹底崩潰：此後即使輸入純文字「continue」，也會讓它崩潰。作者另外指出，當時距離上下文上限還遠得很，因此「歷史太長」的解釋並不成立。

以下整理 Moonshot API 接受與拒絕的區塊類型：

| Claude Code 的操作         | Kimi K3 上的結果                        |
|----------------------------|------------------------------------------|
| 標準工具呼叫               | 可以                                     |
| 網頁搜尋                   | 可以                                     |
| 透過 WebFetch 擷取頁面     | 不行，API 不支援                         |
| 工具延遲載入               | 不行，會出現 400 錯誤，並有工作階段遺失風險 |

這裡的「相容」只描述請求格式。其他一切都不同：接受哪些區塊類型、歷史記錄必須包含什麼，以及究竟有哪些工具可用。

## 使用 Kimi K3 時有哪些東西無法沿用？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

切換模型會改變引擎，但包在外面的一整套工具——Claude Code 本身、它的工具和子代理——仍然是為 Claude 打造的。指示檔、技能和子代理都是按照 Claude 的行為撰寫。Moonshot 明確建議使用已證實相容的包裝程式，並且不要在工作階段中途切換模型。

</div>

發布文章的限制事項章節原文如下：

<figure>
<blockquote>
<p>K3 是在保留推理歷史的模式下訓練的。如果代理包裝程式未按要求傳回完整推理歷史，或是將以其他模型開始的工作階段切換至 K3，生成品質可能會變得極不穩定。我們建議使用已證實相容的包裝程式，例如 Kimi Code，並避免在工作階段進行到一半時切換至 K3。</p>
</blockquote>
<figcaption>— Moonshot AI，限制事項章節，https://www.kimi.com/blog/kimi-k3</figcaption>
</figure>

模型開發者的意思是：請使用我們的用戶端；我們不保證其他人的用戶端會如何運作。

同一章節的第二點，則解釋了另一件我原本歸因於模型固執的事：

<figure>
<blockquote>
<p>K3 的訓練著重於長時間且複雜的任務。因此，在工作時遇到小矛盾或使用者意圖不明確的情況，它可能會代替使用者做出出乎意料的決定。</p>
</blockquote>
<figcaption>— Moonshot AI，限制事項章節，https://www.kimi.com/blog/kimi-k3</figcaption>
</figure>

我的 CLAUDE.md 是按照相反的習慣撰寫的：先提問、展示計畫，然後等待確認。指示仍在那裡，但現在讀取它的是一個個性不同的模型。

如果你想讓多個代理共用一份規則檔，我在[Claude Code、Codex 和 Cursor 共用一份指示檔](https://ailoot.ai/blog/zh-hant-tw/agents-md-claude-md-one-instruction-file/)中另有介紹這種設定。

## Kimi K3 的實際花費是多少？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

以每個 token 計算，Kimi K3 的價格幾乎只有 Claude 的一半。在代理工作流程中，這種計算方式會因快取而失準：只要系統提示或工具清單有任何變更，快取就會完全重設，輸入 token 的價格便會從每百萬 30 美分回到 $3。Claude Code 經常而且持續進行這類變更。

</div>

首先是對 Kimi K3 有利的價格：

| 項目                         | Kimi K3 | Claude Opus 5 |
|------------------------------|---------|---------------|
| 每百萬 token 輸入            | $3.00   | $5.00         |
| 每百萬 token 輸入（使用快取）| $0.30   | $0.50         |
| 每百萬 token 輸出            | $15.00  | $25.00        |

Kimi 的價格來自[上下文快取文件](https://platform.kimi.ai/docs/guide/use-context-caching-feature-of-kimi-api)；右欄列的是截至 2026 年 7 月 30 日 Claude Opus 5 的價格。

Kimi 的快取是自動啟用的，無法停用，並以請求開頭的雜湊值識別。只要編輯系統提示或工具清單，訊息快取就會完全清除。

Claude Code 在一般工作日會做以下事情：

1. 隨著任務進展連接和中斷外部工具。
2. 在需要時按需求載入工具。
3. 使用不同的工具組啟動子代理。
4. 將指示檔加入系統提示。
5. 壓縮上下文時重建歷史記錄。

清單中的每一項都會重設請求的開頭，因此也會重設快取。輸入 token 的價格會從每百萬 30 美分再次回到 $3，貴了十倍。除此之外，持續推理的輸出 token 每百萬要 $15，而相同的 token 下一輪又會作為輸入傳回。這就是標價低的模型也可能產生超出預期帳單的原因。

根據 [OpenCode 的彙整數據](https://opencode.ai/data/moonshot/kimi-k3)，在將近 280,000 個即時工作階段中，Kimi K3 每個工作階段的平均費用為 $1.86，平均用量為 3.1 million 個 token。這個數字以 93% 的輸入 token 命中快取為前提。只要更改請求開頭，這個數字就不適用於你。

Kimi 方案價格為 $19、$39、$99 和 $199。額度來自整個會員共用的額度池，每週重設且未使用的額度不會累積，並採用滾動式五小時區間。方案評測指出，四個終端機同時執行推理常開的 Kimi K3，很快就會用完五小時區間的額度。

$99 方案的程式編寫額度與 Anthropic 的 $200 方案相當，這與我的看法相反。Kimi 的 token 單價較低，但到了晚上的帳單上，你就看不出這項差別了。

## Kimi K3 客觀上擅長什麼？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

Kimi K3 擅長的是一個明確定義的大型單一任務：前端工作、大規模程式碼重構、處理長檔案，以及分析大型儲存庫。它在盲測前端比較中名列第一，讓它負責這類任務很合理。以下列出它的五項優勢。

</div>

1. **前端。** 在現職開發者參與的盲測中排名第一。它能整齊地建立版面，品味也不錯。
2. **處理量。** 100 萬 token 的上下文視窗，長檔案也難不倒它。分析大型儲存庫並描繪全貌，正是它擅長的任務。
3. **首次回應。** 回傳第一個 token 所需時間是 Claude 的一半。在短對話中，差異明顯而且令人愉快。
4. **每個 token 的價格。** 約為 Claude Opus 5 價格的 60%。如果請求開頭沒有變動，就能在大量重複工作中真正省錢。
5. **開放權重。** 不會被綁定在單一提供者上。

最後一點有個但書。要在家裡執行這種規模的模型並不實際：即使經過壓縮，權重仍有數 TB。此處所說的開放，代表不依賴單一提供者。

## 如何在一個晚上親自測試以上內容

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

你需要用平常做的任務測試 Kimi K3：短暫聊天看不出差異。測量兩件事：花了多少時間，以及這個晚上花了多少錢。以下依序列出七個步驟，避免把模型本身的問題和外部包裝程式的問題混為一談。

</div>

1. **按照說明設定存取方式。** 我在[Kimi K3 與 Claude Code 評測](https://ailoot.ai/blog/zh-hant-tw/kimi-k3-vs-claude-code/)中說明了三個環境變數，以及各層級的模型替換方式。用 `/status` 命令檢查設定：Kimi 不會出現在模型選擇選單中，因為選單內建了別名清單，而且你不需要動它。
2. **移除舊的金鑰。** 如果你先前設定過 `ANTHROPIC_API_KEY`，請將它移除。它與 `ANTHROPIC_AUTH_TOKEN` 一起使用會造成衝突，讓你無故收到授權錯誤。
3. **立即關閉工具延遲載入。** 第一次執行前就要做，而不是等第一個工作階段中斷後才做。
4. **不要在任務途中切換模型。** 如果你以 Kimi K3 開始，就用 Kimi K3 完成。反過來也一樣。這是 Moonshot 的直接要求，我已在上文引用。
5. **使用自己的真實任務。** 選一個你昨天做過、還留著各種混亂和未完成事項的任務。貪吃蛇遊戲看不出差異：差異只會在長時間使用後出現。
6. **記下兩個數字。** 花了幾分鐘，以及那個晚上花了多少錢。與平常使用 Claude 的夜晚相比。
7. **另外追蹤閒置時間。** 代理卡住、反覆讀取相同檔案，或回傳錯誤時，這些也算成本的一部分。

如果晚上的帳單比預期高，幾乎總是快取造成的：算算那個晚上請求開頭被重設了多少次。token 單價與此關係不大。

## 最後我保留了什麼

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section highlights">

本節重點

Kimi K3 沒有完全取代 Claude Code，我也沒有強行這麼做。長時間任務和多代理設定仍以 Claude Code 為主引擎。Kimi K3 則作為第二引擎，負責大量重複版面工作、且可以整件交辦的任務。區分依據是任務需要切換多少次。

</div>

和我一起測試模型的頻道讀者，也各自得出了相同的設定：讓 Kimi K3 檢查儲存庫並提供第二意見，主要工作則交給他們熟悉的代理。這種設定行得通，因為不必遷移包裝程式，也不會破壞已經正常運作的部分。

可以這麼說：完整的單一任務交給 Kimi K3；涉及工具和子代理的長流程交給 Claude Code。任務需要在工具之間切換的次數越多，使用 Kimi K3 的成本越高，工作階段出問題的機會也越大。

我另有一篇評測說明如何為兩個代理分配角色而不混淆：[使用兩個代理的三種方式](https://ailoot.ai/blog/zh-hant-tw/claude-code-codex-together/)。

基準測試回答的是「在實驗室條件下誰比較強？」這個問題。你當晚的帳單和已完成工作清單，回答的則是「對你來說誰比較強？」當兩個答案不一致時，請相信第二個：這是你自己計算的，不是行銷部門算的。

檢視完這一切後，我自己做出了決定：不管大家怎麼說新模型，領先者仍然是領先者。Claude Code 仍是我的主引擎。

<div class="section" role="doc-bibliography" aria-label="Sources">

### 來源

- [Kimi K3 官方發布文章與限制事項章節](https://www.kimi.com/blog/kimi-k3) - Moonshot AI
- [透過 Claude Code 使用的 Kimi 文件](https://platform.kimi.ai/docs/guide/claude-code-kimi) - 環境變數、未支援 WebFetch
- [Kimi 上下文快取文件](https://platform.kimi.ai/docs/guide/use-context-caching-feature-of-kimi-api) - 快取機制與價格
- [K3 即時代理工作階段統計](https://opencode.ai/data/moonshot/kimi-k3) - OpenCode

</div>





<div class="aside" data-semantic="ailoot-link" role="note" aria-label="Ailoot">

你可以在 [Ailoot](https://ailoot.ai/) 繼續使用 AI 工作。

</div>

## 常見問題：Kimi K3 實戰：親身體驗與 Claude Code 比較

### 第一個 token 較快，代表 Kimi 完成程式任務較快嗎？

不代表。首 token 延遲與後續輸出速度不同，應計時整項任務，包含工具步驟、重試及檢查，不只看開頭回應。

### 如何測 Kimi 是否適合自己的流程？

選代表性任務，用與現有設定相同的起始檔案及成功檢查，記錄總耗時、token 用量與成果；長時間依賴前，再獨立測多代理流程。


## Ailoot · 公司及其專案組合

Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。

公司及其專案組合：數百萬客戶，每月銷售額達數十億。

Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。