編者按：

　　網(wǎng)易有道CEO周楓近日撰文，就對Harness的思考與實(shí)踐進(jìn)行了分享。

　　“在大模型應(yīng)用里，團(tuán)隊(duì)真正在設(shè)計(jì)和迭代的產(chǎn)品，往往不是一個個具體的功能，而是這一整層Harness本身”——周楓以構(gòu)建一個好的Harness產(chǎn)品要點(diǎn)為核心，提出7個方面：面向下一代模型能力設(shè)計(jì)產(chǎn)品;要做高智能產(chǎn)品;有價值的Agent產(chǎn)品，往往消耗較多tokens……

　　以下為分享全文。

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

　　本文從行業(yè)分享和內(nèi)部實(shí)戰(zhàn)中總結(jié)了一些最佳實(shí)踐，和大家探討。

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

　　一個標(biāo)準(zhǔn)的說法是Agent = Model + Harness：模型負(fù)責(zé)“思考”，Harness負(fù)責(zé)讓這份思考變得可理解、可協(xié)作、可復(fù)現(xiàn)、可長期運(yùn)行。長程Agent對Harness的依賴，超過它對任何單個模型的依賴。更強(qiáng)的模型并不會自動變成更可靠的Agent服務(wù)。簡單來說，對于一個復(fù)雜的Agent，模型也許只完成20%的工作，剩下80%、讓產(chǎn)品持續(xù)可靠工作的基礎(chǔ)，是Harness。[1]

　　這正是標(biāo)題“Harness即產(chǎn)品”的含義：在大模型應(yīng)用里，團(tuán)隊(duì)真正在設(shè)計(jì)和迭代的產(chǎn)品，往往不是一個個具體的功能，而是這一整層Harness本身。

　　下面七點(diǎn)，是我看到的構(gòu)建一個好的基于Harness產(chǎn)品的要點(diǎn)。

　　1. 面向下一代模型能力設(shè)計(jì)產(chǎn)品

　　很多團(tuán)隊(duì)一開始就犯一個錯誤：圍著模型今天的能力優(yōu)化和打磨，試圖讓功能更準(zhǔn)、更快、更便宜，結(jié)果產(chǎn)品上線沒多久就被新模型直接替換。

　　解決這一問題的一個辦法，是做一定的超前定位：產(chǎn)品路線圖不該只問模型今天能不能做，更要問“半年后如果模型在規(guī)劃、工具使用和長上下文上再上一個臺階，我們?nèi)绾巫プ〖t利”。

　　工程上，可以先用強(qiáng)模型跑出效果，再逐步嘗試小模型替換;業(yè)務(wù)上，則優(yōu)先選擇會隨著模型智能提升而不斷放大價值的場景，比如復(fù)雜決策場景、需要深度思考的功能、跨系統(tǒng)調(diào)度，或者需要深入專業(yè)知識的產(chǎn)品。

　　Claude Code負(fù)責(zé)人Boris Cherny在Lenny's Podcast的訪談里把這件事講得很清楚：Claude Code一開始只是個小嘗試，團(tuán)隊(duì)是在“賭模型半年后的能力”——他們刻意按“模型將會變成什么樣”、而不是“模型現(xiàn)在能做什么”來設(shè)計(jì)產(chǎn)品。

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

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

　　2. 要做高智能產(chǎn)品

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

　　一個簡單的判斷標(biāo)準(zhǔn)是：如果這個問題主要靠規(guī)則、搜索和模板就能解決，那它未必值得產(chǎn)品化;如果它依賴模糊判斷、跨文檔理解、多步驟推理和人與系統(tǒng)之間的復(fù)雜協(xié)作，那它才更適合為之開發(fā)大模型產(chǎn)品。

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

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

　　3. 有價值的Agent產(chǎn)品，往往消耗較多tokens

　　很多團(tuán)隊(duì)的第一直覺是“把token用量壓到最低”，但對真正困難的任務(wù)來說，這往往是一上來就設(shè)定錯了優(yōu)化目標(biāo)。對于高價值場景來說，token消耗是創(chuàng)造價值的，因此在一定范圍內(nèi)是越多越好。所以這類場景里，正確的默認(rèn)態(tài)度是舍得花——和上一點(diǎn)呼應(yīng)，單次任務(wù)價值越高、判斷越復(fù)雜，越不該在token上摳門。一個Agent任務(wù)跑下來，累計(jì)輸入token在數(shù)十萬到數(shù)百萬之間，都是比較正常的。

　　因此Harness的一個重要任務(wù)，是讓token的花費(fèi)具有經(jīng)濟(jì)上的可核算性——能夠統(tǒng)計(jì)和優(yōu)化token的消耗，使得該花的地方花充分，不該花的地方足夠節(jié)省。這個和公司的增長團(tuán)隊(duì)一定要量化計(jì)算ROI一樣，是團(tuán)隊(duì)一個必要的基本功。

　　這里有一些重要的杠桿： 一是提示詞的緩存，是團(tuán)隊(duì)要關(guān)注和優(yōu)化的要點(diǎn);二是分層與路由——用強(qiáng)模型跑出比較好的效果后，把簡單節(jié)點(diǎn)下放給小模型;也可以用批處理(batch)的方式跑可異步的批量任務(wù)、必要時做上下文重置來進(jìn)一步節(jié)省開銷。注意，這些手段省的是無謂的浪費(fèi)，在高價值環(huán)節(jié)應(yīng)該放開手腳，放心大膽地花。

　　4. 把上下文工程當(dāng)成主任務(wù)

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

　　關(guān)于上下文工程的好文章不少，比如這篇：《Agent全面爆發(fā)!萬字長文詳解上下文工程》。

　　5. 工具是給模型看的產(chǎn)品界面

　　Agent調(diào)不好工具，往往不是模型不聰明，而是工具設(shè)計(jì)得不對。

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

　　比較實(shí)用的做法是：先收斂工具數(shù)量，把高頻業(yè)務(wù)動作做成少數(shù)幾個高信號、強(qiáng)約束的工具;其次使用嚴(yán)格的schema和結(jié)構(gòu)化輸出，避免自由文本在節(jié)點(diǎn)之間傳遞錯誤指令;最后為關(guān)鍵工具寫清“什么時候該用、什么時候不該用、調(diào)用成功與失敗分別長什么樣”。

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

　　6. 用評測驅(qū)動開發(fā)

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

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

　　7. 默認(rèn)從單Agent開始

　　多Agent很容易讓人興奮，因?yàn)榭瓷先ジ?ldquo;組織協(xié)作”。但很多有經(jīng)驗(yàn)的團(tuán)隊(duì)都建議先把單Agent做到極致，只有當(dāng)prompt邏輯過于復(fù)雜、工具集合擁擠、權(quán)限等級不同、任務(wù)目標(biāo)天然分離時，再拆成多Agent。

　　原因很簡單：多Agent會帶來handoff、狀態(tài)同步、權(quán)限分層、成本疊加和調(diào)試復(fù)雜度。拆對了，系統(tǒng)會更清晰;拆錯了，只會讓問題在更多節(jié)點(diǎn)里來回傳遞。真正值得拆的，是那些邊界清楚且目標(biāo)不同的角色，比如“分診—執(zhí)行—質(zhì)檢”“檢索—分析—操作”或者“客服—退款—物流”。[2]

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

　　小結(jié)：你迭代的產(chǎn)品，就是Harness

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

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

　　所以做大模型應(yīng)用，真正在持續(xù)設(shè)計(jì)、打磨、積累壁壘的，是這一整層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