Kimi K3 編碼代理評測操作指南
這篇教你用同一套任務與評測框架，實際比較 Kimi K3 與其他編碼代理，最後算出可重現的接受率與每次接受變更成本。
67.3 分與 88.3 分只是起點，這篇教你用同一套任務、同一個測試框架，實際比較 Kimi K3 與其他編碼代理。
這篇給要做模型評測、工具鏈驗證、或代理式程式開發選型的工程師看。你照著做完，會得到一份可重跑的評測計畫、一個版本固定的測試框架，還能算出「每次接受變更成本」，而不是只看宣傳分數。
開始之前
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
- Moonshot 帳號，且已開通 Kimi K3 API 權限
- 可用的 Kimi Code GitHub 倉庫
- 可查閱的 Kimi 官方文件
- Node 20+ 或 Python 3.11+
- Git 2.40+
- 至少一個真實專案，內含測試、lint，且有已知錯誤或待辦事項
- 足夠的評測預算，因為代理評測需要多次重跑
Step 1: 定義任務形狀
這一步的產出是「任務範圍清單」。先決定你要比的是修 bug、終端機操作、長流程功能開發，還是模型輔助研究，再挑出和日常工作相似的題型。
任務數量先少後多，先用 3 到 10 個就好。每個任務都要能用自動化方式驗收，例如依賴升級、失敗測試、或有明確回歸條件的 issue。
# 任務清單範例：每列都要有唯一驗收條件
# task_id | repo | branch | acceptance_check
# 001 | app-a | bugfix/001 | npm test
# 002 | app-b | bugfix/002 | pytest -q
# 003 | app-c | bugfix/003 | make verify你應該看到一份每項只對應一個明確通過條件的清單。如果你沒辦法用一句話寫出驗收條件，這個任務就太模糊，不適合拿來做代理評測。
Step 2: 固定框架與模型版本
這一步的產出是「可重現環境設定檔」。把模型識別碼、系統提示、工具權限、上下文政策、歷史壓縮規則都先鎖定，第一輪測試前就不要再改。
同一套框架要套在所有模型上。若 K3 在 Kimi Code 裡保留了較完整的推理歷史，其他比較對象也要盡量走相近的執行路徑，不然結果沒有可比性。
export MODEL_ID="kimi-k3"
export HARNESS_VERSION="[email protected]"
export EVAL_SEED=42
export MAX_ATTEMPTS=3
export TOOL_MODE="restricted"
npm run eval -- \
--model "$MODEL_ID" \
--harness "$HARNESS_VERSION" \
--seed "$EVAL_SEED" \
--attempts "$MAX_ATTEMPTS"你應該看到每次執行紀錄裡的模型名稱與框架版本都一致。如果紀錄開始漂移，就代表你其實已經在比不同系統。
Step 3: 重複跑代理試驗
這一步的產出是「試驗結果資料夾」。每個任務都要跑不只一次，因為代理表現會受工具錯誤、重試次數、上下文長度影響，單次結果很容易失真。
每次試驗都要保留完整對話、命令輸出、token 數量與完成狀態。若 K3 或其他模型產生較長的推理內容，這些成本都要一起記錄。
建議每個 trial 各放一個資料夾，至少保存輸入、輸出、時間戳與失敗原因。這樣你之後要回放失敗案例時，才找得到完整脈絡。
你應該看到每個任務都有成功與失敗紀錄，而不只是成功案例。若失敗樣本不見了，通常代表你的評測流程把難題藏起來了。
Step 4: 以接受變更計分
這一步的產出是「計分表」。不要用主觀印象打分，優先採用可重現的檢查，例如測試、lint、型別檢查、或 golden output 比對。
先把每次嘗試標成接受或拒絕，再算出接受率與每次接受變更成本。這樣你得到的不是單純通過率，而是能直接拿來做採購或選型的判斷指標。
# 接受準則範例
# accepted = 測試全過 AND patch 變更小 AND 沒有改到敏感檔案
# rejected = 測試失敗 OR 任務未完成 OR 需要人工回滾
accepted_changes=$(jq '[.runs[] | select(.status=="accepted")] | length' results.json)
total_cost=$(jq '.billing.total_usd' results.json)
printf "accepted=%s\n" "$accepted_changes"
printf "cost_per_accept=%.2f\n" "$(echo "$total_cost / $accepted_changes" | bc -l)"你應該看到重複試跑後的接受率相對穩定。如果數值上下跳很大，通常不是模型突然變強或變弱，而是框架或任務設計太吵。
Step 5: 對照基準版本
這一步的產出是「比較表」。把 K3 跟你現有模型、開源基準、或較便宜的替代方案放在同一批任務上比較，而且一定要沿用同一套計分規則。
比較時只看對團隊有意義的指標。若你做的是維護型代理，就看每美元可接受修正數；若你做的是研究型代理，就看長流程完成率與工具失敗率。
你應該看到一個在核心指標上明確勝出的結果，而不是模糊的「感覺不錯」。如果 K3 品質較高但成本也高很多，最後可能還是別的模型更適合上線。
| 指標 | 基準／優化前 | 結果／優化後 |
|---|---|---|
| DeepSWE 共用框架分數 | mini-SWE-agent 基準 | K3 報告為 67.3 |
| Terminal-Bench 2.1 分數 | 前沿比較組 | K3 報告為 88.3 |
| 輸出 token 吞吐 | 比較中位數約 72 | K3 測得 62 |
| 總評測成本 | 中位數約 63M 輸出 token 類別 | K3 評測成本 2,690.80 美元 |
常見錯誤
- 不同模型混用不同框架。修法：所有模型都走同一個代理迴圈、同一套權限、同一組停止條件。
- 把原始 benchmark 分數當成上線證據。修法：回到你自己的專案任務，用可重現的驗收條件驗證。
- 忽略 token 花費與重試次數。修法：記錄每次接受變更成本，而不是只看通過率。
接下來可以看什麼
當你的對照流程跑順後，可以把它擴成每月一次的評測套件，固定資料集、保存逐輪紀錄，並加上回歸告警。這樣你就能持續追蹤 Kimi K3，或任何替代模型，是否還值得留在你的編碼代理清單裡。