如何讓排名第一的開源前端模型發揮作用：Kimi K3 Harness 指南

Prompt、Context、Loop 和 Graph Engineering 最終都被證明是同一台機器的不同零件。Harness（框架）才是它們真正共存的地方。

AI 開發的每個階段都有了自己的職位名稱。Prompt Engineering（提示詞工程）最早出現，當時整個技藝的核心在於找到正確的句子。

接著是 Context Engineering（上下文工程），因為人們意識到句子本身不如圍繞它的資訊重要。今年夏天流行的是 Loops（迴圈），幾週後又變成了 Graphs（圖譜）。

現在開始普及的名稱是 Harness Engineering（框架工程），它是第一個能解釋所有其他學科的術語。

Harness 是指模型周圍的一切：它可以調用的工具、它在執行前讀取的檔案、它允許寫入的目錄、輸出必須通過的檢查、喚醒它的排程以及結束執行的規則。

在此之前，每個學科其實都只是這個框架中的一個獨立組件，各自被單獨構建並賦予了不同的名稱。

我開始關注這一點有一個很實際的原因。底層模型不斷變化，有時一次更新就會讓排行榜排名變動十七位，而 Harness 是系統中唯一完全由你掌控的部分。

1/ 七種工程，一台機器

學科

它回答的問題

在 Harness 中的位置

Prompt engineering

我到底在問什麼？

SKILL.md，最先載入的任務規範

Context engineering

模型在每一步看到什麼？

上下文組裝器：約束、架構、檢索到的頁面

Tool engineering

它能觸碰什麼，以什麼形式？

帶有類型化輸入輸出的工具定義

Loop engineering

什麼啟動執行，什麼結束執行？

Runner（執行器）：觸發器、停止條件、預算

Graph engineering

它記得什麼，事物如何關聯？

記憶層：節點、類型化邊、別名

Eval engineering

結果如何被拒絕？

驗證器，位於 Agent 控制之外

Harness engineering

是什麼將上述所有部分結合在一起？

框架、權限和 Hooks

從上到下閱讀這張表，這是一部歷史。從下到上閱讀，這是一種架構：Harness Engineering 的工作就是決定其他六種工程各自的位置，確保沒有任何一部分最終隱藏在 Prompt 裡。

最後一點承載了最重的分量。

Prompt 是最容易塞東西的地方，所以一切都漂移進去了：輸出格式、停止規則、上週的修正事項、Agent 絕不能觸碰的事物清單。它在為你撰寫的那個模型上運作完美，然後下一個模型卻以不同的方式解讀同一段文字。

2/ Harness 的解剖結構

我養成的最有用的習慣是將整個 Harness 寫成一個設定檔，這樣就沒有重要資訊會保持隱性狀態：

1# harness.yaml
2model:        kimi-k3          # 一行代碼。以下所有内容都能經受模型更換
3tools:        [browser, fs, shell, search]
4permissions:
5  write:      [./10-returns, ./20-graph, ./40-runs]
6  ask_first:  [send, publish, pay, delete]
7context:
8  always:     [SKILL.md, CONSTRAINTS.md, SCHEMA.md]
9  per_agent:  return_schema
10runner:
11  trigger:    cron "0 2 * * *"   # 每晚執行，趁你睡覺時
12  stop:       40 verified nodes OR 3 passes with nothing new
13  budget:     { agents: 300, minutes: 45, retries: 2 }
14memory:
15  graph:      ./20-graph
16  aliases:    ./aliases.csv
17verify:
18  - script:   checks/schema.py
19  - agent:    reviewer, fresh context
20hooks:
21  pre_tool:   hooks/pre_tool.sh
22  post_run:   append 40-runs/

該檔案中的三行代碼承擔了大部分工作。

model: 故意只設為一行。 其他所有内容都是為了不關心那一行寫了什麼而設計的。這就是可移植性的全部故事。

permissions: 比 tools: 更重要， 儘管它在檔案中位置較低。寫下 Agent 可以修改什麼以及必須先詢問什麼，區分了你可以整夜運行的系統和你必須盯著看的系統。

verify: 有兩個條目是有原因的。 腳本成本為零，能捕捉任何機械性錯誤。Reviewer 是一個從未見過前者工作的第二個 Agent，因為一個給自己輸出打分的 Agent 總能找到批准的理由。

在磁碟上，Harness 就是一個資料夾，表格中的每種工程在其中都有自己的地址。

3/ 為什麼 Kimi K3 是我會放入其中的引擎

Harness 需要的

Kimi K3 帶來的

能夠分散併發的 Runner

Agent Swarm：在同一問題上同時運行多達 300 個 Agents，無需編寫編排器

強大到足以編寫自身檢查程式碼的能力

在 Frontend Code Arena 排名第 1，分數 1,679，領先 Fable 5 (1,631) 和 GPT-5.6 Sol (1,618)，在 7 個領域中的 6 個領先

在你底下自我改進的引擎

在 7 月的一次更新中從第 18 名躍升至第 1 名

第一行比看起來更重要。幾乎每個自製的 Harness 在某個時刻都會長出一個手工打造的編排器，而且它通常是資料夾中最脆弱的檔案。有了 Swarm，分散併發變成了一行預算配置 agents: 300，Harness 只需要處理返回的結果。

第二行很重要，因為 Harness 主要是模型為你編寫的程式碼：Hook 腳本、架構檢查、讀取 40-runs 的小型儀表板。在 Frontend Arena 領先的引擎能更頻繁地在第一次嘗試中就做對這些事情。

第三行是用一個數據點來論證 Harness Engineering 的案例。當一個模型在一夜之間攀升十七個名次時，Harness 能在當天就利用這種提升，因為唯一需要改變的行就是 model。

4/ Hooks：反射神經

Hook 是 Harness 在固定時刻運行的短腳本，無論模型決定做什麼。Hooks 是 Harness 從一個資料夾佈局轉變為安全系統的地方。

Hook

觸發時機

功能

pre_tool

在任何工具呼叫之前

阻止權限清單之外的寫入操作

post_tool

在每次返回之後

執行架構檢查，當場拒絕格式錯誤的輸出

pre_send

在任何內容離開機器之前

將其保留在佇列中，直到你批准

on_fail

在結果被拒絕之後

將失敗原因附加到重試請求中

post_run

當停止條件命中時

將執行記錄附加到 40-runs 並對圖譜進行差異比較

表格第一行的 pre_tool Hook 只需五行代碼：

1# hooks/pre_tool.sh
2case "$TARGET" in
3  ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;
4  *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;
5esac

單單 on_fail Hook 就改變了迴圈的經濟效益。攜帶上次嘗試失敗原因的重試是一次修正。沒有那個原因，迴圈就要為同樣的錯誤付費兩次。

5/ 一夜之間發生了什麼

將所有部分組合起來，Harness 的行為就像一個遵守規則的夜班。02:00 觸發器啟動，啟動查詢挑選出所有需要工作的節點。Swarm 分散併發，每個節點一個 Agent。

不符合架構的返回結果會在到達圖譜之前被 post_tool 拒絕，每個被拒絕的節點會帶著其失敗原因重試一次。當一個 Agent 試圖寫入其資料夾之外時，pre_tool 會阻止它，而不驚動任何人。

合併後的節點和類型化的邊落入 20-graph。草擬的郵件到達 pre_send 並等待。post_run 附加記錄，迴圈在其自身條件下停止，遠低於設定檔中的 45 分鐘預算。

07:30 你閱讀一個檔案並做出兩個決定。這就是以這種方式運行 Loop Engineering 和 Graph Engineering 的整個早晨成本，也是 Harness 的全部意義：所有不需要你的事情都已經完成，而那幾件需要你的事情正靜靜地待在同一個地方。

6/ 更換測試

對任何 Agent 設置最快的審計方法：更改 model 行並再次運行。任何崩潰的地方都是放錯位置的 Harness。

更換後什麼壞掉了

它原本藏在哪裡

它應該屬於哪裡

輸出格式漂移

Prompt 中的「始終以 JSON 回答」

一個返回架構加上拒絕任何其他格式的腳本

執行不再自行停止

「繼續直到徹底完成」

由計數組成的停止條件

上週的修正消失了

聊天歷史

CONSTRAINTS.md，每次執行都載入

同一家公司出現了三次

模型的判斷

aliases.csv，在合併前檢查

它寫入了不該寫的地方

Prompt 中一句禮貌的話

權限清單和 pre_tool Hook

通過更換測試的設置是可移植的，而可移植性正是使其具有價值的原因。

成本與回報

公司投入整個季度來建設內部 Agent 平台。一個可用的 Harness 只是一個資料夾、一個設定檔和五個短腳本，並且運行在 Kimi 訂閱服務上。這個差距就是機會。

渠道

回報

首先你需要什麼

小型團隊的 Harness 設置

針對他們工作流程的配置、Hooks 和驗證器收取四位數的一次性費用

你自己的一個 Harness，按排程運行

發布日顧問費

每月收費，在每個主要模型發布時運行更換測試，並將團隊遷移到領先的模型

一個其執行記錄已經寫入 40-runs 的客戶

利基市場 Harness 模板

為單一行業打包的資料夾和 yaml：研究、招聘、合規

在兩個不同市場驗證過的相同 Harness

我會優先建立第二個渠道。每個主要發布都會重新洗牌排行榜，僅 K3 就在一次更新中移動了十七個名次，每個擁有 Harness 的團隊都需要一個在發布日負責運行更換測試的人。

簡短版本

Prompt、Context、Tool、Loop、Graph 和 Eval Engineering 最終都被證明是一台機器的組件，而 Harness Engineering 則是決定每個組件所在位置的過程。

將模型放在一行代碼後面，將權限置於工具之前，將驗證器置於 Agent 之外。那麼下一次排行榜的跳躍將只是設定檔的更改，而不是重建。

如果你覺得這篇文章有用：

• 收藏這篇文章。連結會變，新的 Repo 每週湧現，你會需要它作為參考
• 想要每週深入探討 AI 架構、量化交易和 Agent 經濟，請追蹤我：@polydao
• 加入 TG Channel：Buzzoni Notes - 在這裡我分享我的原始 Prompts、自訂技能，以及還太早無法在 X 上分享的 Alpha