編者按：
網易有道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在Lenny's Podcast的訪談裡把這件事講得很清楚：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 (多知)