上個月幫一個團隊把內部的數(shù)據(jù)查詢助手從Demo接進生產第一周就崩了六次。不是模型變笨了是系統(tǒng)層面根本沒準備好工具調用超時、上下文塞爆、同一個問題復現(xiàn)不了、模型偶爾抽風輸出一個空JSON直接把下游任務干掛了。那幾天我一直在想一個問題——為什么Demo階段明明很順一上生產就到處冒煙答案其實不復雜Demo驗證的是“模型能不能做這件事”生產考驗的是“整個系統(tǒng)能不能穩(wěn)定地讓模型把這件事做完”。這中間隔著一整層工程我習慣把它叫做Harness Engineering也就是給AI Agent的智能能力裝上韁繩、護具和儀表盤的那套工程體系。這篇文章就圍繞這個名字展開講講從Demo到生產到底差在哪幾步、每一步具體怎么落地。如果你是剛跑通第一個Agent原型、正要往生產推的工程師或者已經(jīng)在生產里被Agent折騰過幾輪、想系統(tǒng)化梳理一下方案這篇應該能幫上忙。我會盡量用具體的配置、代碼和踩坑記錄來講不寫空話。1. Demo能跑和能穩(wěn)定生產中間隔著一整層工程1.1 一個Demo跑通只需要三條“好消息”我自己跑通第一個Agent的時候心里想的全是三個正反饋模型會調用工具了、流程走通了、輸出看起來有模有樣。這三個好消息確實能撐起一個Demo但充其量只是證明了一條理想路徑能被走通。理想路徑是什么是模型在正確的時機調用正確的工具、工具返回了干凈的數(shù)據(jù)、模型據(jù)此給出了正確的答案、用戶恰好沒有提出邊界問題、網(wǎng)絡和接口都穩(wěn)定如絲。Demo階段的運氣成分極大因為你根本沒有把系統(tǒng)置于“壞環(huán)境”里考察過。到了生產環(huán)境模型面對的是嘈雜的輸入、不完整的工具返回、用戶不會再按你的腳本提問。這個時候你會陸續(xù)收到一堆壞消息某個時間點接口變慢導致Agent卡死、用戶上下文太長導致費用飆升、模型突然不按工具契約輸出而是開始自由發(fā)揮、重試機制把同一個寫操作重復執(zhí)行了三次。這些基本都不在Demo的考察范圍內卻都是生產事故的主力來源。1.2 生產環(huán)境對Agent的真正考察項我一般用一個簡單的對照表來跟團隊解釋Demo和生產之間的差距。每次Review都用這張表過一遍它已經(jīng)變成我們項目評審的標準動作考察維度Demo階段的通常狀態(tài)生產環(huán)境的要求成功路徑只驗證理想路徑驗證成功路徑、失敗路徑、邊界路徑輸入分布自己手工準備的正例真實用戶分布包含臟數(shù)據(jù)、多輪歧義執(zhí)行穩(wěn)定性偶發(fā)成功即可演示95%以上的請求成功且可復現(xiàn)工具調用工具總是可用且快工具會慢、會錯、會返回臟數(shù)據(jù)上下文管理單輪或短輪不關注Token多輪、超長上下文有成本預算約束可觀測性打印模型文本即可需要追蹤完整軌跡、歸因和復盤安全護欄無需超時、預算、鑒權、兜底切換發(fā)布變更重新運行Notebook即可需要灰度、版本管理和回滾你會發(fā)現(xiàn)生產環(huán)境真正考察的不是模型智商而是系統(tǒng)的工程韌性。這種韌性不會自動出現(xiàn)只能靠明確的設計和測試去構建這就是我把Harness Engineering當作必修課的原因。1.3 為什么傳統(tǒng)后端工程的思維在這里部分失靈做過后端服務的人會習慣性地想Agent就是“編排層加上模型API調用”那我用常規(guī)的微服務思路來處理不就完了這個思路對了一半但有一塊核心差異很容易被忽略傳統(tǒng)后端里控制流是開發(fā)者在代碼里寫死的而在Agent里控制流是模型在運行時動態(tài)生成的。這個差異帶來了兩個連鎖后果。第一你的代碼不再完全決定行為走向模型可能走出一條你沒預料到的執(zhí)行路徑。第二系統(tǒng)里最難排查的問題從“哪里邏輯寫錯了”變成“模型為什么在某個語境下做了這個決定”。后者的可復現(xiàn)性很差可能換個會話、調換一下上下文順序同樣的調用就走向了不同的分支。所以Harness Engineering的核心目標不是“控制模型的每一個token”而是在模型自由度的周圍建立一套約束和響應機制。就像騎馬你不可能控制馬腿的每一步肌肉運動但你能控制韁繩、馬鐙、馬鞍通過這套“騎具”穩(wěn)定方向、保持平衡、及時停下。工程體系的本質就是這套圍繞模型建立的騎具。2. Harness Engineering到底是什么給AI能力裝上“韁繩與儀表盤”2.1 名字的來由和邊界Harness這個詞在工程領域并不陌生。早期軟件測試里就有test harness指的是測試夾具把被測對象架起來、喂入輸入、抓取輸出、匯報結果的那套支撐結構。把這個概念遷移到AI Agent上Harness Engineering就成了包裹在模型能力外面的整層工程設施。這層設施做什么我傾向于給出一個覆蓋關系它把Agent從“一個會調用工具的模型”變成“一個可以被管理、被評估、被控制、被觀測的生產組件”。具體拆成四件事對應的就是下面要展開的內容。第一是可靠性。通過執(zhí)行循環(huán)設計、重試和降級保證長鏈路任務在真實環(huán)境下盡量穩(wěn)定。第二是可評估。建立評測集和回歸機制讓每次模型或提示詞改動都可以量化判斷好壞。第三是可控制。通過超時、預算、并發(fā)限流和人在回路讓系統(tǒng)在最壞情況下仍然有兜底動作。第四是可觀測。把模型的每一步推理、工具調用和內部狀態(tài)變成日志和指標出了問題能定位、能歸因。這四個能力不是可選增強而是生產級Agent的底線。Demo里模型發(fā)揮失常你重跑一次就行生產里模型發(fā)揮失常影響的是業(yè)務和用戶信任你不能靠“重跑”來交差。2.2 它解決的問題域和框架、提示詞工程的分工有些朋友會問這些事難道LangChain、Semantic Kernel這類框架沒做嗎框架確實提供了很多編排能力比如Agent循環(huán)、工具注冊、記憶組件用起來能省很多時間。但我的經(jīng)驗是框架解決的是“怎么搭”Harness Engineering解決的是“怎么?！薄４騻€比方框架給你一輛配置齊全的車Harness是你要給它裝上的安全帶、氣囊、行車記錄儀和維修保養(yǎng)計劃。車本身不錯但上不上市、能不能長期可靠運行取決于你裝了哪些保護設施。反過來Harness Engineering也不該去搶提示詞工程的工作。提示詞工程優(yōu)化的是“模型輸出的質量”Harness優(yōu)化的是“系統(tǒng)對模型輸出的處理能力”。兩者有交疊但重點不同一個在思考層面發(fā)力一個在執(zhí)行和反饋層面發(fā)力。真正成熟的分工是提示詞讓模型盡量少犯錯Harness讓模型即使犯錯系統(tǒng)也能把損失控制在一定范圍內。2.3 判定Harness做得好不好的三個信號做了幾輪生產改造之后我總結出三個說明Harness做得比較到位的信號。第一個信號是失敗可以被routine地處理。新出現(xiàn)的失敗模式很快就能歸入已有的重試、降級、兜底或告警分類里而不是每次都像第一次遇到那樣手足無措。第二個信號是上線改動不再手心出汗。提示詞、模型版本、工具實現(xiàn)都可以灰度放量用數(shù)據(jù)和評測說話而不是靠“我覺得沒問題”。第三個信號是事故能夠被復盤和歸因。出事后你能講清楚“哪個環(huán)節(jié)出了問題、當時系統(tǒng)的狀態(tài)是什么、為什么做出那個決定”而不是只能籠統(tǒng)地說“模型抽風了”。這三個信號同時出現(xiàn)意味著Harness Engineering基本成型了。下面從執(zhí)行循環(huán)開始講具體怎么造橋。3. 第一道橋墩執(zhí)行循環(huán)的可靠性加固3.1 把一次性長鏈拆成可重試的短步驟Agent的執(zhí)行循環(huán)通常長這樣模型接收任務規(guī)劃一系列動作逐個調用工具根據(jù)工具結果繼續(xù)推理直到完成。問題是這個循環(huán)里的任何一步失敗整個鏈就可能斷。我踩過最典型的一個坑是讓模型依次調用三個工具才能給出最終答案結果第二個工具返回超時整個任務直接失敗。Demo里不會遇到這種問題因為工具都在本地、數(shù)據(jù)量小、網(wǎng)絡通暢生產里這是家常便飯。解決思路是給每一步一個明確的“狀態(tài)邊界”。我在設計工具調用層時要求每一步操作要么成功、要么失敗絕不允許出現(xiàn)半成功、半失敗的狀態(tài)。舉例來說一個工具先寫數(shù)據(jù)庫再通知下游就必須把“寫數(shù)據(jù)庫”和“通知下游”拆成兩個獨立調用或者用事務保證原子性。這樣重試就安全了失敗時重放同一個步驟不會產生重復副作用。這一步做完執(zhí)行循環(huán)就從“一條脆弱的邏輯鏈”變成了“一串可以單獨重放的短步驟”。可靠性提升的基礎是這個。3.2 給每個工具寫“契約”而不是寫“說明”框架里注冊工具通常就是傳一個函數(shù)、加一段描述模型通過描述理解該不該調用這個工具。我的經(jīng)驗是描述只能解決“模型愿不愿意調用”解決不了“調用之后系統(tǒng)怎么處理結果”。我們項目的做法是給每個工具維護一份契約文檔核心包括輸入?yún)?shù)的JSON Schema、輸出結果的結構約定、錯誤碼和錯誤信息約定、副作用說明、超時閾值。模型看到的說明是把契約翻譯成自然語言的版本而系統(tǒng)層拿契約做解析、校驗和報錯映射。舉個例子有一個內部查詢工具返回結果可能是“查詢成功數(shù)據(jù)為空”、“查詢失敗權限不足”、“查詢失敗依賴接口超時”三種情況。模型如果只看到“返回查詢結果”這句描述它根本沒有辦法區(qū)分這三種情況背后應該怎么決策。有了契約和錯誤映射模型才能知道“權限不足”時要跟用戶解釋而不是重試三遍。我甚至會把關鍵的契約寫進系統(tǒng)提示詞里讓模型在決策時就能看到邊界。寫作時保持簡短比如“工具查詢失敗時如果是超時錯誤可以重試一次如果是權限錯誤請直接告知用戶缺少權限?！边@種約束在Demo里看不出價值在生產里能讓很多無效循環(huán)提前終止。3.3 模型輸出到系統(tǒng)指令之間需要翻譯器模型并不總是會嚴格按照你規(guī)定的JSON結構輸出。尤其在你讓它自由規(guī)劃、自己決定下一步Action的時候偶爾會冒出來多一個字段、少一個逗號、把字符串寫成了數(shù)組等格式錯誤。傳統(tǒng)做法是把這個原始輸出直接丟給下游結果下游一解析報錯整個流程就斷了。我采用的方案是加一個解析翻譯層。模型輸出先經(jīng)過一個輕量級的解析器把它整理成標準化的指令對象。解析器要做三件事第一是格式修正比如提取被代碼塊包裹的JSON、修復明顯的語法問題第二是字段映射把同義字段名統(tǒng)一到標準字段第三是置信度判斷如果解析結果與預期結構偏差過大不強行使用而是觸發(fā)生成解析失敗的提示要求模型重新輸出或者直接降級為安全回復。這個翻譯層的價值不僅僅是讓流程不崩更在于它給系統(tǒng)一個“可控的失敗點”。失敗被集中在這里就可以針對性地retry或fallback而不是讓莫名其妙的格式錯誤跑到業(yè)務的各個角落去爆炸。3.4 超時與重試的邊界條件關于超時我給自己定過一條非常簡單的原則沒有超時的環(huán)節(jié)就是生產事故的預留位置。模型的推理調用要設超時工具調用要設超時整個Agent的一輪執(zhí)行也要設總超時。這幾個超時是層層收縮的類似TCP的超時和重傳。具體參數(shù)上我們會對不同工具單獨配置。比如本地數(shù)據(jù)庫查詢一般2秒沒回來就很可疑我會給3秒超時、允許重試1次外部API調用會留到5秒因為網(wǎng)絡抖動存在但重試要加指數(shù)退避第一次失敗等500毫秒第二次等1.5秒最多3次。這里有一個特別重要的坑重試不能對冪等之外的請求無腦使用。如果工具調用有副作用比如扣費、發(fā)消息、創(chuàng)建資源重試一次就等于把同樣的副作用執(zhí)行兩次。所以我會在工具契約里顯式標注是否冪等不冪等的操作只能靠人工介入或異步確認去兜底絕不在Agent內部自動重試。這塊想清楚重試機制才真正安全。4. 第二道橋墩上下文與記憶的工程化治理4.1 Token不是游客記憶需要分層你可能會好奇上下文治理有什么好講的不就是把歷史消息拼在一起喂給模型嗎這么做在短會話里確實能跑但生產環(huán)境里用戶的會話可能長達幾十輪中間穿插著工具調用結果、臨時文件內容、用戶中途修改的需求。全塞進上下文幾個問題立刻找上來費用暴漲、響應變慢、模型注意力被無關信息稀釋。我的做法是把記憶做成分層結構簡單說就是三類記憶分開存。長期記憶存用戶的基本偏好和不變的事實比如賬號類型、常用語言、業(yè)務線的固定配置工作記憶存當前任務相關的臨時信息比如正在填寫的表單字段、本次查詢的中間結果會話記憶存對話的歷史消息只保留用于銜接語境的關鍵內容而不是把每句話都堆進上下文。分層的意義在于你可以為每一層設置不同的保留時長和Token預算。長期記憶每次請求都注入但內容很少工作記憶在任務完成后清理會話記憶按輪數(shù)或Token上限截斷。這樣既保住了必要的語境信息又不至于讓上下文變成一筆糊涂賬。4.2 上下文壓縮的三個實用策略在Token預算有限的情況下我常用三種壓縮策略它們可以組合使用。第一種是摘要替換。當歷史對話超過一定長度時用一個摘要節(jié)點替代最早的那些輪次。摘要可以在后臺異步生成生成完畢后再注入后續(xù)請求。需要注意摘要本身不要寫太詳細能回答“用戶之前問過什么、結論是什么、還有什么遺留事項”就夠了寫太細等于沒壓縮。第二種是截止窗口。有些歷史信息對當前問題已經(jīng)完全沒有影響比如用戶上一單的配送地址已經(jīng)改掉了。這類信息要主動識別并從上下文中清除而不是“帶著以防萬一”。我見過很多案例是模型因為上下文里的舊信息而答錯信息污染造成的錯誤比信息缺失更隱蔽。第三種是檢索增強把完整信息放到向量庫里只在需要時才檢索相關片段放回上下文。這個方法適合知識庫類場景但要控制好檢索結果的裁剪和去重。壓縮不是無限砍核心原則是把“上下文”當作一種需要管理的資源而不是隨手可以無限追加的緩沖。4.3 一次因上下文污染引發(fā)的故障排查記錄這里分享一個具體排查案例。某公司內部工單Agent上線后部分用戶的反饋是明明在上一步確認了自己的賬號類型是企業(yè)版下一步模型又開始按個人版的規(guī)則回答。我和團隊花了半天最后定位到原因一個用戶歷史切換過賬號類型舊賬號類型的信息還躺在會話記錄里沒被清理。鏈路是這樣的第一輪用戶說“我切換成企業(yè)版了”系統(tǒng)處理完上下文里同時存在“切換前是個人版”和“切換后是企業(yè)版”兩條信息。后續(xù)幾輪里模型通過注意力機制抓取信息時偶爾會命中舊信息導致判斷漂移。修復方案很簡單在賬號切換事件發(fā)生時主動改寫上下文節(jié)點刪除掉與賬號類型相關的舊記錄并在摘要節(jié)點里注明“已切換到企業(yè)版”。這個案例給我一個啟發(fā)上下文治理不只是Token層面的省錢手段更是模型認知一致性的保障。你不主動管理上下文里的事實性信息模型就會在矛盾證據(jù)里隨機搖擺而這種搖擺是最難人工追查的。5. 第三道橋墩評測體系與回歸護欄5.1 手工體驗測試的局限性我經(jīng)常跟團隊說如果你評估Agent的改進效果靠“自己試了十幾個問題感覺變好了”那這個項目還沒有達到可以上線改動的水平。手工測試有致命弱點覆蓋量太小、結果不可復現(xiàn)、評估標準不一致。我自己就犯過這樣的錯。改了一版系統(tǒng)提示詞手工測試了幾個典型案例覺得輸出更精煉了心里很滿意。結果上線后發(fā)現(xiàn)調用工具的頻率下降了一些需要查數(shù)據(jù)的請求被模型憑“記憶”硬答了。手工測試時我沒注意到這個偏向因為那幾個問題恰好不需要工具。這充分說明無評測集的改動就是在憑感覺賭博。后來我們立了一條規(guī)矩任何影響模型行為的改動提示詞、工具定義、上下文策略、模型版本都必須過評測集得先出數(shù)字再談上線。5.2 評測集應該怎么建評測集建設是個臟活但很值得做。我們起步時選了三種來源搭它。第一種是真實會話采樣。從生產環(huán)境的日志里按一定比例抽出歷史請求包括成功和失敗的經(jīng)典案例。這些數(shù)據(jù)最真實能避免你構建出和實際需求脫節(jié)的“理想數(shù)據(jù)”。注意脫敏處理。第二種是人工構造的邊界用例。針對你已知的風險點手工寫案例比如歧義問題、多意圖嵌套、工具異常時的應對請求這些樣例專門用來測模型的“抵抗力”。第三種是合成變體。拿真實案例做模板改動里面的實體、數(shù)字、措辭來生成更多變體增加覆蓋范圍這種方法成本低特別適合初期擴充規(guī)模。評測的維度不要只盯著“答案對不對”。我常用五維評估任務完成度看核心目標有沒有達成工具選擇正確率看該調用的工具是否調了、不該調的是否忍住輸出結構合規(guī)率看格式和字段是否符合契約浪費程度看是否走了不必要的冗余步驟安全表現(xiàn)看是否說了越權或離譜的話。每個維度都要有明確定義和打分標準盡量讓兩個評估者打分的結果基本一致。5.3 如何把評測接進發(fā)布流程評測建好之后接下來是把評測從“跑一次看結果”變成“發(fā)布流程的關卡”。我用的是三級門檻機制?；A門檻是自動化跑一遍核心評測集要求任務完成度不低于某個閾值比如90%。第二個門檻是差異對比新版本和線上版本各跑一遍相同評測集比較各維度優(yōu)劣。模型行為是多變的允許有些指標略降尤其是那些能換來響應速度或成本大幅改善的提升比都可以接受但要人來看、要記錄下原因。第三個門檻是線上灰度的小流量驗證用真實流量在看板指標上跑一段時間再放量。這套機制跑通之后團隊的信心會明顯不一樣。改動上線不再依賴“某開發(fā)哥覺得好”而是有一套可追溯的評估鏈條。這個習慣本身也是從Demo思維轉向生產思維的重要標志。6. 第四道橋墩成本、并發(fā)與人在回路6.1 Token預算與并發(fā)控制生產環(huán)境里成本不是事后統(tǒng)計的而是事前要鎖死的。我一般會給每個會話和每個用戶分別設置Token預算會話級預算是控制單次任務不失控比如一個復雜任務最多消耗30萬Token超過就強制收斂或終止用戶級預算是防止某個高頻用戶在整體成本上造成沖擊。模型API的調用也需要并發(fā)控制。Demo里單線程調用并發(fā)問題不會出現(xiàn)生產里有多個用戶同時使用如果一個用戶的任務內部包含20個串行步驟那么10個并發(fā)用戶就會在中間環(huán)節(jié)堆積大量待處理請求。不加并發(fā)限制可能一瞬間打爆下游接口的負載。我常用的做法是給Agent接入通用信號量機制限制同時進行的模型調用數(shù)量加上基于令牌桶的請求速率限制。限流策略不會讓單個請求變快但它能讓整體服務穩(wěn)定不雪崩。這個往往不是第一次上線就做而是出了接口占用率告警后才補建議一開始就規(guī)劃好。6.2 人在回路與緊急剎車并不是所有任務都能完全自動化。對于高風險操作比如刪除數(shù)據(jù)、批量發(fā)消息、修改核心配置我堅持引入人在回路Agent可以生成建議但執(zhí)行前必須經(jīng)過人工確認。實現(xiàn)上就是在執(zhí)行鏈路上加一個“暫?！惫?jié)點將待審批的Action轉成審核任務等待人工返回后才繼續(xù)。另一種兜底是“緊急剎車”開關也就是全局熔斷。當某類錯誤連續(xù)出現(xiàn)或請求成功率跌到閾值之下系統(tǒng)自動暫停受影響鏈路的執(zhí)行轉入降級模式或直接返回人為兜底提示。這個開關平時不應該被觸發(fā)但一旦出現(xiàn)異常它能保住系統(tǒng)和數(shù)據(jù)不至于被帶崩。6.3 可觀測性與版本管理生產運維里你至少需要三類數(shù)據(jù)來回答“剛才發(fā)生了什么”。第一是軌跡日志記錄每一步模型輸入輸出、工具調用參數(shù)和結果、耗時與Token消耗第二是聚合指標包括請求成功率、平均響應時長、單會話Token消耗、工具調用失敗率第三是事故事件也就是那些觸發(fā)了重試、降級、熔斷或人工審核的關鍵節(jié)點。這些信息光記錄還不行還要能高效檢索。排查時候我最常做的事就是輸入一個會話ID按時間線回放Agent到底做了哪些決策。沒有軌跡日志這件事幾乎不可能完成只能靠復現(xiàn)和猜。版本管理同樣重要。一個Agent版本不只包含模型版本還包括提示詞、工具契約、上下文策略和評測結果的組合。我們上線時會對這一整套打一個版本標簽這樣線上出了問題能精準回滾到某個穩(wěn)定版本而不是逐個配置文件去找。7. 一個案例數(shù)據(jù)查詢Agent從Demo到生產的完整改造7.1 原版Demo的問題清單為了把這些方法論串起來我拆一個實際幫團隊改造的例子是一個內部數(shù)據(jù)查詢助手。最初版本Demo做得挺漂亮用戶用自然語言提問Agent判斷需要查哪張寬表、調用查詢接口、給出數(shù)據(jù)摘要。團隊覺得可以加真實用戶了找我做了一次上線前體檢開出來的問題清單是這樣的工具調用沒有總超時某個聚合查詢慢的時候整個會話會卡到用戶放棄工具描述寫得太簡略模型經(jīng)常分不清“按日匯總”和“按周匯總”該調用哪個參數(shù)上下文全量保留用戶多問十幾個問題后Token消耗直接翻倍沒有任何評測集團隊說“效果不錯”的依據(jù)是手動測試了二十個問句查詢失敗時模型只會原樣報錯誤碼用戶根本看不懂。問題不少但每一條都在Harness的覆蓋范圍內改起來有章法。7.2 改造步驟與效果改造分四步推進。第一步加固執(zhí)行層。給查詢工具加上3秒超時超時后返回標準錯誤系統(tǒng)把它映射為“查詢超時請稍后再試”的回復模板模型側重試邏輯調整為最多一次加了退避。同時把查詢接口按冪等性標注清楚只對冪等查詢開啟自動重試。第二步重寫工具契約。查詢工具的輸入?yún)?shù)改成結構化Schema并明確區(qū)分“時間粒度”“維度字段”“過濾條件”三個獨立參數(shù)最關鍵是給模型提供錯誤碼到用戶話術的映射表。權限不足、數(shù)據(jù)為空、接口超時三種情況的回復策略在提示詞里寫明防止模型在不該重試的場景下反復請求。第三步做評測集和回歸。從歷史查詢日志里抽了80條真實問題手工構造了20條邊界問題包括“查詢條件互相矛盾”“用戶一次性問了三個指標”“表格不存在”等。跑完評測后發(fā)現(xiàn)工具選擇準確率從改造前的60%左右提升到85%以上浪費Token的平均值下降了約一半。第四步上線灰度。先在內部群邀請20個重度用戶試用一周看軌跡日志里是否有新的失敗模式之后擴大到20%流量最終全量。全程開著超時告警和評測回歸任何一次改動都先過一遍評測集再放量。7.3 改造過程中最容易忽略的兩個細節(jié)這個項目里有兩個細節(jié)我印象很深。第一個工具返回的“數(shù)據(jù)為空”和“查詢結果沒有命中任何記錄”在模型眼里是兩件事寫契約時必須顯式區(qū)分否則模型會開始強行編造“沒有數(shù)據(jù)時存在的趨勢”。第二個提示詞里明確要求模型“當查詢失敗時用清晰的話術告訴用戶而不是展示原始錯誤代碼”。這個約束看著很簡單但如果沒有顯式寫明模型默認會傾向于把原始報錯信息原封不動拋給用戶。評測集里加了兩條“接口超時”的用例就是為了盯住這個行為。這些細節(jié)不是理論推出來的都是改造過程中逐步暴露、逐步補上的也是Harness Engineering要有評測集兜底的原因。8. 我在幾次生產事故之后學到的事經(jīng)歷這些之后我對AI Agent生產化有了幾個比較踏實的認知。第一個認知是穩(wěn)定性不是加幾個防御性代碼就能解決的它來自一整套成體系的設計。超時、重試、契約、評測、預算、可觀測這些環(huán)節(jié)少一塊短期內可能沒感覺長期一定會在某個深夜變成告警電話。第二個認知是模型的能力會持續(xù)變強但Harness這部分不會自動變好。模型升級了你的評測集和工具契約需要跟著動場景變了你的預算策略和上下文策略也要重新審視。工程體系的維護和模型的迭代是并行推進的缺一不可。最后再分享一個個人體會不要把Agent當成一個黑盒去“誠心祈禱”一定要把它當成一個你隨時可以拆開、可以控制、可以反問的系統(tǒng)來設計。多想想“這里如果失敗會怎樣”“這一步用戶會怎么看”“這個決策為什么這樣做”你就是在做Harness Engineering了。這些東西并不性感但正是它們把一個“驚艷的演示”變成了一個“每天都能穩(wěn)定交付價值的產品”。如果你正準備把Agent從Demo推向生產我建議你從最小的一環(huán)開始先給自己的工具調用加上超時然后把第一次失敗的過程記進日志。從這一個小小的動作開始你已經(jīng)在修橋了。