Harness即產品

作者|周楓

編者按：

網易有道CEO周楓近日撰文，就對Harness的思考與實踐進行了分享。

“在大模型應用里，團隊真正在設計和迭代的產品，往往不是一個個具體的功能，而是這一整層Harness本身”。

周楓以構建一個好的Harness產品要點為核心，提出7個方面：面向下一代模型能力設計產品；要做高智能產品；有價值的Agent產品，往往消耗較多tokens……

以下為分享全文。

最近和同事關于Harness/Agent的討論比較多，總體上大家共同的看法是：現在是通過Harness來做大模型創新應用的好時機，但是Harness和以往的應用開發范式有較大不同，需要用一些不同的方法，才能做出好的產品，沿用原有的思維方式可能事倍功半。

本文從行業分享和內部實戰中總結了一些最佳實踐，和大家探討。

先界定一下概念。所謂Harness（馬具/載體），指的是模型之外、把模型包裝成一個可用產品的那一整層工程：上下文管理、工具、記憶、持久化狀態、評測、循環控制、可觀測性與權限治理。

一個標準的說法是Agent = Model + Harness：模型負責“思考”，Harness負責讓這份思考變得可理解、可協作、可復現、可長期運行。長程Agent對Harness的依賴，超過它對任何單個模型的依賴。更強的模型并不會自動變成更可靠的Agent服務。簡單來說，對于一個復雜的Agent，模型也許只完成20%的工作，剩下80%、讓產品持續可靠工作的基礎，是Harness。[1]

這正是標題“Harness即產品”的含義：在大模型應用里，團隊真正在設計和迭代的產品，往往不是一個個具體的功能，而是這一整層Harness本身。

下面七點，是我看到的構建一個好的基于Harness產品的要點。

1. 面向下一代模型能力設計產品

很多團隊一開始就犯一個錯誤：圍著模型今天的能力優化和打磨，試圖讓功能更準、更快、更便宜，結果產品上線沒多久就被新模型直接替換。

解決這一問題的一個辦法，是做一定的超前定位：產品路線圖不該只問模型今天能不能做，更要問“半年后如果模型在規劃、工具使用和長上下文上再上一個臺階，我們如何抓住紅利”。

工程上，可以先用強模型跑出效果，再逐步嘗試小模型替換；業務上，則優先選擇會隨著模型智能提升而不斷放大價值的場景，比如復雜決策場景、需要深度思考的功能、跨系統調度，或者需要深入專業知識的產品。

Claude Code負責人Boris Cherny在里把這件事講得很清楚：Claude Code一開始只是個小嘗試，團隊是在“賭模型半年后的能力”——他們刻意按“模型將會變成什么樣”、而不是“模型現在能做什么”來設計產品。

當時他的判斷是，模型獨立編程的能力正在快速上升，交互方式因此必須從以人為主的自動補全（auto-complete）轉向以Agent為主：“模型能做到很多還沒有產品接住的事…… 我們其實不必再做type-ahead了，可以直接讓Agent把所有代碼都寫出來。”這個賭注在2025年5月Opus 4發布時兌現，產品隨之取得巨大成功。

他給出的兩條產品原則也值得思考：“別試圖把模型框死”（少用僵硬的編排，多給工具和目標讓模型自己想），以及“押注更通用的模型”——在模型一夜之間就能改變能力邊界的領域里，能隨模型一起變強的靈活方案，往往勝過為當下定制的腳手架。

2. 要做高智能產品

不是所有AI功能都值得投入。

一個簡單的判斷標準是：如果這個問題主要靠規則、搜索和模板就能解決，那它未必值得產品化；如果它依賴模糊判斷、跨文檔理解、多步驟推理和人與系統之間的復雜協作，那它才更適合為之開發大模型產品。

一個考慮的角度，是“類比一個需要資深員工處理的復雜任務切片”。如果你是產品負責人，最應該優先篩選的場景，不是流量最大，而是單次任務價值最高、判斷復雜度最高、人工成本最貴的那些。這類場景雖然起步看起來更難，但一旦做通，用戶會把它當真正的生產力工具，而不是新鮮一下的演示玩具。

換個角度說，任務切片越難、價值越高，模型單獨能交付的比例就越低，當然最終能不能穩定上線，恰恰取決于Harness建得好不好，對模型能力的判斷是否正確，但總的來說，把注意力集中在高智能產品方向上，是成功可能性更大的。

3. 有價值的Agent產品，往往消耗較多tokens

很多團隊的第一直覺是“把token用量壓到最低”，但對真正困難的任務來說，這往往是一上來就設定錯了優化目標。對于高價值場景來說，token消耗是創造價值的，因此在一定范圍內是越多越好。所以這類場景里，正確的默認態度是舍得花——和上一點呼應，單次任務價值越高、判斷越復雜，越不該在token上摳門。一個Agent任務跑下來，累計輸入token在數十萬到數百萬之間，都是比較正常的。

因此Harness的一個重要任務，是讓token的花費具有經濟上的可核算性——能夠統計和優化token的消耗，使得該花的地方花充分，不該花的地方足夠節省。這個和公司的增長團隊一定要量化計算ROI一樣，是團隊一個必要的基本功。

這里有一些重要的杠桿： 一是提示詞的緩存，是團隊要關注和優化的要點；二是分層與路由——用強模型跑出比較好的效果后，把簡單節點下放給小模型；也可以用批處理（batch）的方式跑可異步的批量任務、必要時做上下文重置來進一步節省開銷。注意，這些手段省的是無謂的浪費，在高價值環節應該放開手腳，放心大膽地花。

4. 把上下文工程當成主任務

上下文工程（context engineering），目的是讓模型在某一時刻究竟知道什么、不知道什么、記住什么、遺忘什么，而不是寫更長、更巧妙的提示詞。如果說Harness有一個心臟，那就是上下文管理：前面幾點，最終都要落到管理上下文內容這個動作上，而不是簡單地使用不斷積累對話上下文的默認規則。至少要把上下文拆成幾層：系統規則、當前任務、檢索知識、用戶歷史、長期偏好、工具結果。不同層應該有不同的優先級、生命周期和壓縮方式（見下圖）。Anthropic把上下文工程的目標概括成一句話：找到“能最大化達成目標的、最小的一組高信號token”，因為上下文是一種邊際收益遞減的有限資源。[3]

關于上下文工程的好文章不少，比如這篇：。

5. 工具是給模型看的產品界面

Agent調不好工具，往往不是模型不聰明，而是工具設計得不對。

現在國內外主流模型的Agent能力都已經較強，在絕大多數場景下都有有效地驅動設計良好的工具集合來工作，所以在上下文工程之后，工具的設計是團隊應該聚焦的點。對于不熟悉這個方法的團隊，這需要一次觀念升級：你不只是寫一個API給自己的前端或服務端調用，而是在設計一個“模型可消費的能力單元”。如果工具過多、命名相似、參數含糊，模型就容易誤選；如果返回結果冗長且噪音大，還會進一步污染上下文。

比較實用的做法是：先收斂工具數量，把高頻業務動作做成少數幾個高信號、強約束的工具；其次使用嚴格的schema和結構化輸出，避免自由文本在節點之間傳遞錯誤指令；最后為關鍵工具寫清“什么時候該用、什么時候不該用、調用成功與失敗分別長什么樣”。

Anthropic在工具使用文檔里也強調，影響調用效果最重要的因素之一，就是工具描述本身。不少一線實踐也指向同一組做法：工具一旦超過二十來個，模型就容易在相似工具間選錯（比如把“訂單查詢”和“物流查詢”搞混）；同時避免“瑞士軍刀式”的多功能工具，改用單一職責、強schema的小工具，并在真正調用前先做參數校驗、把錯誤直接“回吐”給模型修正。

6. 用評測驅動開發

做Agent比較容易掉入的一個坑是做出“差不多”能工作的產品，然后碰到問題反復手工調整，但是按下葫蘆浮起瓢，陷入打地鼠的困境。這個時候，團隊缺乏的就是量化的評測辦法。一個真正可上線的Agent，必須有細分任務級的、量化的評測體系。評測至少要覆蓋四層：最終答案質量、工具調用正確率、流程完成率和安全樣本通過率。更進一步來講，還應該有邊界樣本、對抗樣本和真實線上日志回灌。一定要把“憑感覺”換成“看數據”。

從實操角度，Anthropic的《Demystifying Evals for AI Agents》是目前最權威的Harness/Agent評測指南，同時也已經有多個開源的框架出現，大家可以選擇參考和使用。[4]

7. 默認從單Agent開始

多Agent很容易讓人興奮，因為看上去更像“組織協作”。但很多有經驗的團隊都建議先把單Agent做到極致，只有當prompt邏輯過于復雜、工具集合擁擠、權限等級不同、任務目標天然分離時，再拆成多Agent。

原因很簡單：多Agent會帶來handoff、狀態同步、權限分層、成本疊加和調試復雜度。拆對了，系統會更清晰；拆錯了，只會讓問題在更多節點里來回傳遞。真正值得拆的，是那些邊界清楚且目標不同的角色，比如“分診—執行—質檢”“檢索—分析—操作”或者“客服—退款—物流”。[2]

這件事社區里有一場很有代表性的爭論：Cognition（Devin背后的團隊）寫過《Don't Build Multi-Agents》，主張默認就用單Agent——多個Agent之間很難共享完整上下文、容易決策沖突，對“寫”類的強一致性任務（比如寫代碼）尤其脆弱；而Anthropic在《How we built our multi-agent research system》里給出了反例：在“讀”類的開放式研究任務上，主從式（orchestrator-worker）多智能體比單個Claude Opus 4高出90.2%，但代價是token消耗約為普通對話的15倍。兩邊其實指向同一條分界線——任務偏“讀”還是偏“寫”、能不能共享上下文，決定了該不該拆。

小結：你迭代的產品，就是Harness

把這七點連起來看，它們其實是同一個工程的七個側面：超前定位定方向、高智能場景定取舍、舍得花token求價值、上下文管理是心臟、工具是手、評測是免疫系統、循環編排是骨架。

模型會一代代變強，而且只會越來越強——但更強的模型不會自動變成更可靠的Agent服務，從demo到完整產品的鴻溝，始終要靠Harness來填。

所以做大模型應用，真正在持續設計、打磨、積累壁壘的，是這一整層Harness。模型是可更換的引擎，Harness才是你自己造的車。

[1] Anthropic, Harness design for long-running application development. https://www.anthropic.com/engineering/harness-design-long-running-apps

[2] OpenAI, A practical guide to building agents. https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

[3] Anthropic, Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[4] Anthropic, Demystifying Evals for AI Agents. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

以上文章來源于：

教育從業者年度必讀丨《教育科技這一年：教育+AI新紀元》火熱銷售中，點擊小程序購買?

掃碼加入多知新書交流群，共同探討教育+AI的未來

由肖云著、多知首發的《價值：增長的邏輯》今日開售！點擊下方小程序即可搶購！