從零開始理解LLM（三）——harness疑是術式公開

這是從零開始理解LLM的第三期，拖了很久。 關於harness的一點點自己的理解。

harness類比公開術式

這期的idea來自AI-Agents-in-Depth-zh-CN項目，也就是七月第四周週報的top1。我最近在看這本書的時候萌生出的想法。

“模型即 Agent”（Model as Agent）這一新範式代表了 AI Agent 發展的最新方向。先進模型通過後訓練（特別 是強化學習）將工具調用能力內化爲原生能力：何時調用工具、調哪個、傳什麼參數，都由模型自己決定，無需人工 編排。但這並不意味着框架層變得不重要了。恰恰相反，模型越強大，圍繞模型構建的 Harness 就越關鍵。Harness 這個詞原指馬具，即套在馬身上的繮繩與挽具，不是爲了限制馬的奔跑能力，而是把這種力量引導到正確的方向上。 換到 Agent 語境裏，模型是那匹強大但不可預測的馬，Harness 則是把它的能力引導成可靠任務執行的工程外殼。 你也可以把它想象成賽車手周圍的整套保障系統：安全帶、賽道護欄、進站維修團隊。車手（模型）越快，這套系統 越重要。在 Agent 中，Harness 包括上下文管理、工具接口、安全約束、驗證與糾正等基礎設施（詳見本章末節）。 模型自主決策的空間越大，出錯時的影響面也越大，因此需要更精細的約束、驗證和糾正機制來確保可靠性。 模型廠商的真正優勢不是“讓框架變薄”，而是能對模型與外圍 Harness 進行協同優化，持續迭代。

按照吧友的說法，“術式公開”相當於是給自己增加束縛，增加了不利條件，換取提升效果。欸，如果把這個設定套在harness上似乎也說得通。

agent視角：未受Harness 約束的 Agent 是一個不可控的“黑盒”，雖然可能偶爾驚豔，但無法工程化。Harness 強迫 Agent 將內部邏輯對齊到可解釋、可驗證的軌道上，這是一種白盒化的過程。

咒術視角：不公開術式是因爲害怕被針對，這本質上是一種“黑盒防禦”。而選擇公開術式，則是將自身的咒力運作邏輯白盒化，換取增強術式效果。

當然，按照這個比喻來看，開源要比harness還要像術式公開，這裏只是借這個概念理解harness，也許還有更好的比喻。

harness說到底是一種妥協

如果模型持續變強，今天這些 Harness 會不會最終被模型“喫掉”？Rich Sutton 在《苦澀的教訓》（The Bitter Lesson）中回顧了 AI 研究七十年間反覆上演的一幕1：研究者一次次把自己對領域 的理解編碼進系統，短期見效，長期卻總是輸給能隨算力與數據規模持續擴展的通用方法——搜索與學習。

如果模型的通用性和專業能力都足夠強，直接力大磚飛就好了，何須束縛。在戰鬥中也是同理，如果是碾壓姿態，完全不需要公開術式，直接秒了好嗎。

AI:都怪我沒有力量

現實生活中也有相同的例子。在代碼界，對於代碼優化是勞神費力的事情，優化可能是比寫新代碼還要麻煩的事情，一次優化提升百分之幾十上百的效率，可能遠不如CPU或者GPU的一次換代。

本書不懷疑模型會持續喫掉 Harness——工具調用、長程規劃都曾靠外部編排，如今已是模型 的原生能力；但在節奏上，這個“喫”遠比直覺慢：訓練以月計，模型也無法一次內化真實業務中所有的約束與偏好， 模型此刻的能力邊界，就是 Harness 此刻的價值所在。

harness具體做什麼工作

1.規範

讓所有參與方都說相同的話（LLM，工具，用戶，provider）

• 工具發現：註冊 + schema 生成，所有工具描述打包成 LLM 能理解的 functions 參數

• 參數驗證：LLM 生成的 JSON 可能殘缺或格式錯誤，harness 負責修復

• 結果路由：工具執行結果正確格式化成 tool 角色消息，再喂回 LLM

• ......

2.連接

把 LLM 的"想說"翻譯成系統的"能做“（當然，LLM根據廣義上下文，已經知道可以做哪些事）

• 工具並行執行 (_MAX_TOOL_WORKERS=8,hermes的最大並行數量)

• 錯誤處理 & 重試 —— 工具拋異常 → harness 捕獲 → 給 LLM 友好的錯誤說明（最早的AI使用是人將命令行執行後的報錯copy給LLM，相當於代替了這個過程）

• ......

3.安全

• 危險命令審批 (approvals)——rm -rf / git reset --hard 等要先問用戶（煩死我了，別問了，直接幹吧）

• 密鑰脫敏 (secret redaction) —— 工具輸出裏藏了 API key，harness 在進 LLM 前抹掉

• 工具超時控制 —— 一個工具卡死不能拖垮整個 agent

• ......

4.呼吸

這個小結叫呼吸是因爲我認爲，像中斷處理，上下文壓縮這些操作就是爲了LLM能夠連貫的輸出結果，就像對於人類而言，大部分時間都意識不到呼吸。

• 中斷處理 —— 用戶發新消息時優雅中斷當前循環，不崩

• 上下文壓縮 (Context Compression) —— 對話太長時自動摘要舊輪次，讓呼吸不因窒息停止

• 跨會話記憶 —— 這次呼吸之外的事，下次呼吸還能記得

• Session 持久化 —— 哪怕進程掛了，下次啓動能續上之前的呼吸

• ......

結語

因此 Harness 工程不是對苦澀的教訓的抵抗，而是這一教訓 在工程時間尺度上的實踐：模型還做不穩的，Harness 先補上；模型每內化一層，Harness 就卸下一層，轉而兜底 新的能力前沿。

隨着LLM能力提升，harness長期來看，對LLM的約束是會越來越少的，LLM早晚可以自行判斷，自行規範，自行糾正。LLM早晚會卸下繮繩（天網反叛指日可待）。

重要的不是harness具體做了什麼，是設計理念——harness是給LLM增加束縛，將輸出結果均衡優化的手段。