2026 年，AI 領域最值得注意的一句話不是關於某個新模型，而是 Anthropic、Martin Fowler 以及半個 AI 研究圈在最近幾週共同收斂出來的一個公式：
Agent = Model + Harness（智能體 = 模型 + 套件）。
最近如果你在 AI Twitter 上轉過，你一定到處都能看到 harness 這個詞。普林斯頓發布了 HAL harness，HKUDS 開源了 OpenHarness。一篇新的 Meta-Harness 論文證明：在不動模型權重的前提下， 自動重寫一個 Harness，就可以讓 TerminalBench-2 的分數提高幾個點。Philipp Schmid 把 Agent Harness 稱作「解決長任務模型漂移的首要工具」。
但有件事沒人公開講：2026 年關於 Harness 的幾乎所有討論，對象都是編碼 Agent。Claude Code、SWE-bench、終端任務、程式碼倉庫導覽。
那除此之外的世界呢？那些不涉及 Git 倉庫的 Agent 工作呢？
我們是 Lessie，專門為一個具體任務打造 Harness Agent：找人。 招聘人員用我們找候選人；業務用我們找決策者；VC 用我們找創辦人；行銷團隊用我們找創作者。 所以當 Harness 這個話題火起來的時候，我們很想知道一個具體問題：「Harness 比模型更重要」這個論點，離開編碼場景後還成立嗎？
於是我們做了一個基準測試，跑了一次完整實驗。這個基準叫做 PeopleSearchBench，最關鍵的一個數字是這樣的：
在 119 條真實人脈搜尋查詢上，Lessie 得分 65.2。 跑在 Sonnet 4.6 上的 Claude Code 得分 45.8。 這是 42% 的差距——而唯一改變的變數，就是 Harness。
下面我們把這件事拆開講清楚。
什麼是 Harness Agent，用人話說
OpenHarness 團隊給過最簡潔的定義：模型是 Agent，程式碼是 Harness。 Parallel Web 給的定義略長一些：Harness 是包裹模型的一層執行階段， 負責攔截它的工具呼叫、管理它的上下文，並把它持續地拉回任務正軌。
Martin Fowler 把它拆成兩個互相配合的半部分。Guides（前饋引導）是前饋控制—— 在 Agent 行動之前塑造它的行為（系統提示詞、工具描述、檢索到的上下文、環境快照）。Sensors（回饋感測）是回饋控制—— 觀察 Agent 做了什麼，然後把修正餵回去（linter、驗證器、驗證迴圈）。 一個好的 Harness 同時具備兩者；一個差的 Harness 只有前饋， 眼睜睜看著 Agent 在第 47 輪重複同一個錯誤。
所以 Harness Agent 是一個完整的組合：模型 + 引導 + 感測 + 工具 + 記憶 + 驗證邏輯， 把原始的 Token 預測能力變成一個真正能完成任務的系統。
當下出現了兩種 Harness：
- 通用型 Harness，例如 Claude Agent SDK、OpenHarness、以及 Claude Code 內建的 Harness。它們的設計初衷是不綁定特定領域。
- 垂直型 Harness，圍繞一個具體任務來建構， 引導和感測都專門針對這個任務的失敗模式調校。
你聽過的幾乎所有 Harness 基準——SWE-bench、TerminalBench-2、USACO、AppWorld—— 測的都是通用 Harness 在編碼任務上的表現。據我們所知， PeopleSearchBench 是第一個把垂直 Harness Agent 和通用 Harness 放在非編碼任務上對決的基準。
為什麼人脉搜尋需要專屬的 Harness
如果你曾經讓一個通用 AI Agent 去「幫我找柏林 Series B 新創公司裡 發過 LLM 產品的資深機器學習工程師」，你應該已經見識過它的幾種典型失敗。 其中三種特別頑固，並且全部是 Harness 問題，不是模型問題：
1. 跨源實體解析（Entity Resolution）。一個真實的人同時存在於 LinkedIn、X、GitHub、會議演講、公司主頁、學術資料庫裡。 他們用著不同的名字、不同的頭像，有時拼寫都不一樣。 通用 Harness 沒有內建「這條 LinkedIn 資料和這個 GitHub 帳號是同一個人」的概念。一個人脉搜尋 Harness 必須在每一次查詢裡都解決這件事。
2. 驗證迴圈（Verification Loop）。沒有感測層的 Agent 會很自信地捏造人物。 它會引用一個「Stripe 柏林的資深 ML 工程師」， 但這個人根本不存在——因為這些 Token 聽起來很合理。 修復辦法不是換一個更聰明的模型——跑在 Claude Code 裡的 Sonnet 4.6 一樣會犯。 修復辦法是一個 感測器：每一個返回的人都要先用真實網頁源核驗， 通過之後才會到達使用者面前。
3. 人類屬性的查詢拆解（Query Decomposition）。「柏林 Series B 發過 LLM 產品的 ML 工程師」不是一個查詢， 它是一張清單：角色 + 資歷 + 公司階段 + 地點 + 領域 + 近期產出。 通用 Harness 會把整句話原封不動塞進搜尋框； 垂直 Harness 會把它拆成多條標準，並行去合適的源裡查，再回收、重組、排序。
這三件事，正是 Fowler 所說的 引導 和 感測。 只是它們恰好是沒人會專門為通用編碼 Harness 去做的引導和感測—— 因為編碼 Harness 用不上。
實證：PeopleSearchBench
我們建構 PeopleSearchBench 是為了誠實地測試這件事。完整方法在論文裡，這裡給一個簡短版本：
- 119 條真實查詢，全部來自實際的招聘、業務和研究工作流
- 4 種語言（英語、葡萄牙語、西班牙語、荷蘭語）
- 4 類場景：招聘（30）、B2B 拓客（32）、專家 / 確定性查詢（28）、 網紅 / KOL（29）
- 4 個被測平台：Lessie（垂直 Harness Agent）、Exa（結構化搜尋 API）、 Juicebox / PeopleGPT（擁有 8 億+ 資料的招聘平台）、 Claude Code（跑在 Sonnet 4.6 上的通用 Harness）
- 三個獨立維度：Relevance（padded nDCG@10）、 Coverage（任務完成率 × 產出量）、Utility（資料完整度）
- 用真實網頁搜尋驗證，而不是 LLM 拍腦袋打分。 每一個被返回的人都會去 LinkedIn、公司主頁和公開資料對照核實。 驗證 Agent 完全不知道某條結果是哪個平台返回的。
總分如下：
- Lessie：總分 65.2 | Relevance 70.2 | Coverage 69.1 | Utility 56.4
- Exa：總分 54.6 | Relevance 53.8 | Coverage 58.1 | Utility 53.1
- Claude Code：總分 45.8 | Relevance 54.3 | Coverage 41.1 | Utility 42.7
- Juicebox：總分 45.8 | Relevance 44.7 | Coverage 41.8 | Utility 50.9
Lessie 在每一個維度上都排第一。它也是唯一一個把 119 條查詢全部跑完的平台——100% 的完成率。其他三個平台在偏門搜尋上經常什麼都返回不了。
但對於 Harness 這個論點，最關鍵的數字是 Lessie 和 Claude Code 之間的差距。 兩邊都是 AI Agent，都能呼叫工具，都能搜尋網頁。Claude Code 跑在地球上最強的幾個模型之一上。 最終它在總分上輸了 19.4 分，其中 Coverage 單項差距高達 28 分。
這 19.4 分不是模型的差距。它是 Harness 的差距。
單場景裡差距最大的是 網紅 / KOL 發現：Lessie 62.3，Claude Code 43.2。 網紅搜尋是通用 Harness 崩得最厲害的地方，因為正確答案同時分布在 TikTok、Instagram、 YouTube 和 X 上，而通用 Harness 不知道怎麼把這些源融合起來。 差距最小的是招聘場景，三家平台都跑過了 64 分——招聘是人脉搜尋裡最成熟的垂直， 產業有多年時間為它打造工具。
規律是一致的：一個場景越需要多源融合和驗證，Harness 的重要性就越大。
Lessie Harness 內部長什麼樣
我們不會公開自己的系統提示詞。但 Lessie 的架構有三層， 恰好可以對應到 Guides 和 Sensors 模型。它們值得描述出來， 因為它們大致就是任何垂直 Harness Agent 都需要的結構：
第 1 層——多源編排（Guides）。當一個查詢進入系統，Harness 會把它並行路由到職業網絡、社群平台、學術資料庫和公開記錄庫。 每個源都有自己的檢索策略。模型從來不會看到原始的扇出結果，它只會看到一個統一的候選集。
第 2 層——標準拆解與驗證（Sensors）。每個查詢都會被拆成顯式的標準——角色、資歷、地點、公司階段、相關訊號—— 每一個候選人都要先經過真實網頁查詢，按這些標準被驗證一遍，才會進入排序環節。 這正是 PeopleSearchBench 用來給我們打分的方法學，而這並非巧合： 我們就是圍繞這個基準要測的失敗模式來建構 Harness 的。
第 3 層——資料增強（Profile Enrichment）。通過驗證後，Harness 會再去抓結構化資料——當前職位、近期動態、聯絡方式、社群存在。 這就是為什麼我們的 Utility 分領先全場：返回正確的人但欄位全空，沒有任何價值， 而通用 Harness 沒有理由把 enrichment 當作一個內建步驟。
中間的模型在做模型擅長的事：推理、排序、總結、判斷。 Harness 在做剩下的所有事。 把 Harness 拿走，剩下的是聊天機器人；把模型拿走，剩下的是搜尋管線。 合在一起，才是一個垂直 Harness Agent。
這件事對 Harness 之爭意味著什麼
2026 年關於 Harness 的有趣觀點是：模型在靜態基準上的進步在放緩， 但 Agent 的整體表現還有大量空間，因為剩下的提升大多都活在 Harness 裡。 Meta-Harness 透過自動發現更優 Harness 在編碼場景印證了這一點； PeopleSearchBench 則從另一個方向印證： 手工搭建的垂直 Harness 可以讓一個跑在通用 Harness 裡的前沿模型顯著落後， 而這個差距是任何模型升級都關不上的。
如果這一點成立，那麼有兩件事會隨之發生。
第一，每一個具備商業價值的 Agent 任務，都會擁有自己的 Harness Agent。人脉搜尋是其中之一。法律研究是另一個。 臨床推理、金融分析、供應鏈調查、科學文獻綜述——每一個都有通用 Harness 永遠不會去最佳化的失敗模式， 因為通用 Harness 是在為所有事情同時最佳化。 垂直 Harness Agent 將吃掉 Agent 工作的長尾， 就像 SaaS 當年吃掉軟體的長尾一樣。
第二，基準也需要跟上。SWE-bench 和 TerminalBench-2 都很好，但它們只測了 Harness 品質的一個切面。 如果業界真的認真對待 Harness 論點， 就需要為每一個有商業價值的垂直建立 Harness 基準。 PeopleSearchBench 是我們為人脉搜尋這個垂直所開的頭。 資料集、評測管線、完整結果都已經開源。
模型是引擎，Harness 是車身。我們把這台車造給了一條特定的路。 如果你的工作和找人有關——候選人、客戶、投資人、創作者、合作夥伴——試試這台車：lessie.ai。 想看我們到底是怎麼在一個原本不是為它而生的任務上擊敗前沿模型編碼 Agent 的， 完整基準和論文在這裡。
2026 年，Harness 就是護城河。資料已經替我們說了。