做過AI Agent相關(guān)開發(fā)的朋友應(yīng)該都有同感寫一個(gè)能跑通的代理不難難的是讓它穩(wěn)定地跑完一百遍。LLM天然帶有隨機(jī)性同樣的輸入今天輸出這個(gè)結(jié)果明天就可能換個(gè)路徑哪怕最終答案都對中間調(diào)用的工具順序、傳參格式、思考鏈路都可能不一樣。這意味著傳統(tǒng)單元測試?yán)飻嘌苑祷刂捣项A(yù)期那套玩法到了Deepagents這類Agent框架上直接失靈——你沒法斷言Token流里的每一句話。Deepagents這個(gè)名字本質(zhì)上指向的是一類具備自主規(guī)劃、工具調(diào)用、多步執(zhí)行能力的Agent框架。它的質(zhì)量保障不能靠多調(diào)試幾次必須靠一套專門為非確定性系統(tǒng)設(shè)計(jì)的自動化測試體系。這篇文章我會從三個(gè)層面拆解Agent測試和傳統(tǒng)測試到底差在哪、Deepagents自動化測試該怎么設(shè)計(jì)斷言和用例、以及我在實(shí)踐中踩過的坑和沉淀下來的排查方法。無論你是正在做AI應(yīng)用的QA、負(fù)責(zé)Agent平臺的工程師還是剛接觸這個(gè)領(lǐng)域想建立測試體系的新手這套思路都可以直接落地。1. 為什么AI代理測試和傳統(tǒng)測試不在一個(gè)維度在動手寫測試用例之前最要緊的是想明白一個(gè)問題我們對一個(gè)Agent的正確到底該怎么定義。這個(gè)定義想不清楚后面所有的斷言、回歸、穩(wěn)定性建設(shè)都是空中樓閣。1.1 不確定性帶來的測試哲學(xué)轉(zhuǎn)變傳統(tǒng)軟件測試的本質(zhì)是驗(yàn)算。你有一個(gè)確定函數(shù)輸入11斷言輸出2跑一萬次也是一樣的結(jié)果。如果某次跑出3那就是bug定位修復(fù)即可。AI代理完全不是這么回事。Deepagents這類框架讓模型自己決定調(diào)用哪個(gè)工具、按什么順序調(diào)用、如何拆解子任務(wù)。這是個(gè)開環(huán)系統(tǒng)輸出空間幾乎是無限的。用一個(gè)固定答案去套一個(gè)開放系統(tǒng)測試用例本身就會變成抖動的源頭這次跑通了下次跑不通你說這是產(chǎn)品壞了還是測試寫錯(cuò)了所以我在實(shí)際項(xiàng)目中把測試哲學(xué)從驗(yàn)算換成了監(jiān)考。傳統(tǒng)測試是檢查學(xué)生交上來的答案是不是100Agent測試是給監(jiān)考老師一個(gè)評分標(biāo)準(zhǔn)學(xué)生有沒有在規(guī)定時(shí)間內(nèi)交卷、有沒有作弊抄隔壁、答題過程是否符合考試紀(jì)律至于中間草稿紙上的演算步驟只要不違規(guī)寫不寫都行。這個(gè)轉(zhuǎn)變非常關(guān)鍵。它意味著斷言的對象從終態(tài)字符串遷移到了行為軌跡與終態(tài)達(dá)成兩層。我后面會詳細(xì)展開這兩層的具體寫法。1.2 Deepagents測試體系的設(shè)計(jì)理念基于監(jiān)考這個(gè)思路我給Deepagents測試體系定了三條設(shè)計(jì)原則。第一條是行為可觀測。測試環(huán)境里所有工具調(diào)用必須留下結(jié)構(gòu)化日志不能只有自然語言文本。框架每次調(diào)用工具時(shí)的名稱、入?yún)?、出參、延遲都要能JSON化落盤。這是后續(xù)一切斷言的基礎(chǔ)——你沒法斷言一個(gè)你看不到的過程。第二條是環(huán)境可隔離。Agent測試絕對不能打在真實(shí)生產(chǎn)服務(wù)上。我見過團(tuán)隊(duì)直接拿生產(chǎn)環(huán)境當(dāng)測試場結(jié)果Agent半夜調(diào)用了一個(gè)真實(shí)的下單接口產(chǎn)生了實(shí)際扣款。這種事故一次就足夠讓人長記性。測試環(huán)境里外部服務(wù)全部用可控的樁實(shí)現(xiàn)或容器化Mock數(shù)據(jù)源用種子數(shù)據(jù)快照。第三條是結(jié)果可復(fù)現(xiàn)。對于給定的測試用例要么你接受路徑不同但殊途同歸要么你把隨機(jī)性壓到可控范圍。一個(gè)實(shí)用做法是固定模型版本、溫度參數(shù)設(shè)為接近0、禁用流式輸出。這樣雖然不百分百保證確定性但能把合法路徑的數(shù)量從無限壓縮到有限幾類讓斷言規(guī)則可以覆蓋。2. Deepagents自動化測試的關(guān)鍵設(shè)計(jì)斷言、工具調(diào)用與狀態(tài)管理理清了理念接下來就是具體設(shè)計(jì)。Deepagents的測試用例我在項(xiàng)目里通常拆成三個(gè)核心組件前置條件、執(zhí)行動作、斷言規(guī)則。前置條件和傳統(tǒng)測試一樣構(gòu)造輸入與狀態(tài)執(zhí)行動作就是跑Agent差別全在斷言規(guī)則上。2.1 斷言的不再是返回值而是行為軌跡剛才說了Deepagents測試的第一層斷言是行為軌跡。所謂軌跡就是Agent從開始到結(jié)束的完整工具調(diào)用序列。我第一個(gè)建議是不要嚴(yán)格比對該序列除非你的場景是必須按固定流程操作。舉個(gè)例子一個(gè)查天氣的Agent它可以先查城市編碼再查天氣也可以直接傳城市名查天氣。兩條路徑的結(jié)果完全一樣但嚴(yán)格序列比對會讓測試用例變成易碎的瓷器。正確做法是提取軌跡的關(guān)鍵特征調(diào)用了哪些工具、工具的入?yún)⑹欠駶M足約束、是否有重復(fù)無效調(diào)用、是否有循環(huán)死鎖。在代碼層面我一般把完整的工具調(diào)用Sequence做一個(gè)投影運(yùn)算只保留我們關(guān)心的屬性然后對投影結(jié)果做斷言。比如必須調(diào)用過SearchToolSearchTool的關(guān)鍵詞參數(shù)非空從發(fā)起請求到返回結(jié)果的總步數(shù)不超過N步。這樣既有約束力又留足了Agent自主規(guī)劃的彈性空間。2.2 工具調(diào)用鏈的驗(yàn)證方法第二層斷言是對每個(gè)工具調(diào)用的出入?yún)⑦M(jìn)行約束性校驗(yàn)。這里的核心不是斷言精確等于某某值而是斷言滿足某個(gè)不變量。我總結(jié)了三類驗(yàn)證方法實(shí)戰(zhàn)中配合使用。第一類是Schema校驗(yàn)。每個(gè)工具在框架里都有輸入Schema測試時(shí)對Agent實(shí)際傳入的參數(shù)做JSON Schema校驗(yàn)字段類型錯(cuò)誤、必填項(xiàng)缺失這種低級幻覺立刻就能抓出來。這相當(dāng)于給Agent的工具使用劃了一條底線你可以自由發(fā)揮但話不能亂說。第二類是領(lǐng)域不變量校驗(yàn)。特定業(yè)務(wù)場景下的硬約束。比如金額字段不能為負(fù)數(shù)、用戶身份必須是測試白名單內(nèi)的ID、時(shí)間參數(shù)不能早于某個(gè)基準(zhǔn)點(diǎn)。這類校驗(yàn)往往比Schema校驗(yàn)更貼近業(yè)務(wù)也更能抓住真正有殺傷力的bug。第三類是副作用校驗(yàn)。工具不是無痕的它會有數(shù)據(jù)庫寫入、緩存更新、外部資源占用。測試要在Agent執(zhí)行完成后比對前置狀態(tài)與后置狀態(tài)排除泄漏的臟數(shù)據(jù)。這個(gè)需求引出下一個(gè)關(guān)鍵設(shè)計(jì)。2.3 狀態(tài)管理與隔離Deepagents有狀態(tài)這是它和普通API的重要區(qū)別。對話上下文、中間變量、臨時(shí)文件、外部服務(wù)連接都會在執(zhí)行過程中累積。測試如果不管理狀態(tài)用例之間會互相污染出現(xiàn)A用例單獨(dú)跑能過跟著B用例跑就失敗的邪門問題。我推薦的辦法是事務(wù)級回滾 環(huán)境級重建雙管齊下。事務(wù)級回滾針對數(shù)據(jù)庫這類有事務(wù)支持的組件。每個(gè)測試用例外層包一個(gè)事務(wù)執(zhí)行完直接回滾數(shù)據(jù)恢復(fù)到測試前狀態(tài)。緩存類組件則在用例開始前刪除相關(guān)Key形成干凈起點(diǎn)。環(huán)境級重建針對Agent持有的上下文對象。Deepagents運(yùn)行時(shí)會維護(hù)agent state測試必須確保每個(gè)用例拿到的是全新初始化的State不能復(fù)用上一個(gè)用例殘留的中間變量。這塊我在框架層封裝了一個(gè)fixture每個(gè)用例自動實(shí)例化新Agent、注入新會話ID。效果立竿見影狀態(tài)串?dāng)_導(dǎo)致的口角問題基本清零。3. 實(shí)操搭建一套Deepagents質(zhì)量保障基線從設(shè)計(jì)落到工程下面是我在模擬項(xiàng)目X里完整落地過的一套Deepagents測試體系。這套體系可以按需裁剪但整體架構(gòu)是經(jīng)過驗(yàn)證的。3.1 測試環(huán)境與資源配置Deepagents測試環(huán)境和傳統(tǒng)API測試環(huán)境最大的區(qū)別是你需要一個(gè)可控的LLM網(wǎng)關(guān)。LLM調(diào)用是Agent測試中最大的變量源和成本源。直接打供應(yīng)商的在線接口網(wǎng)絡(luò)抖動、限流、隨機(jī)性會把測試結(jié)果攪成一鍋粥。我建議團(tuán)隊(duì)在測試環(huán)境里部署一個(gè)代理網(wǎng)關(guān)統(tǒng)一攔截測試用例里的模型調(diào)用。網(wǎng)關(guān)要提供幾個(gè)能力按預(yù)置內(nèi)容響應(yīng)模擬固定模型輸出、按用例維度限制調(diào)用次數(shù)、記錄每次調(diào)用的Token消耗與耗時(shí)。有了這個(gè)網(wǎng)關(guān)你在測試用例里可以對Agent說最多只能調(diào)用N次LLM超過就斷言失敗防止循環(huán)失控。外部依賴方面我的基線配置是數(shù)據(jù)庫用PostgreSQL容器初始數(shù)據(jù)從SQL快照恢復(fù)搜索/檢索類工具用一個(gè)預(yù)置索引的輕量向量庫替代數(shù)據(jù)量幾百條覆蓋典型場景HTTP類外部API全部用接口Mock服務(wù)按路由規(guī)則返回固定Fixture文件系統(tǒng)操作指向臨時(shí)目錄用例結(jié)束自動清空特別注意LLM網(wǎng)關(guān)不等于把模型換成人教版教材。真實(shí)項(xiàng)目里我會區(qū)分兩類用例。冒煙測試用網(wǎng)關(guān)的定值響應(yīng)追求速度與穩(wěn)定完整回歸用真實(shí)模型跑完整場景追求探索未知問題。兩者缺一不可。3.2 第一類測試確定性單元測試這類測試針對的是Agent內(nèi)部不需要模型參與的純邏輯模塊。雖然Deepagents的核心是LLM但工程上一定存在大量非智能組件比如工具調(diào)用參數(shù)的預(yù)處理、結(jié)果解析器、提示詞模板渲染、錯(cuò)誤處理分發(fā)。這些組件是確定性的完全可以按傳統(tǒng)單測方式來寫。我用pytest框架針對每個(gè)純函數(shù)模塊維護(hù)一份測試矩陣。核心價(jià)值不在于測試多復(fù)雜而在于給Agent系統(tǒng)建立一個(gè)確定性錨點(diǎn)——每當(dāng)提示詞模板或工具定義發(fā)生變化時(shí)先跑這批測試能第一時(shí)間發(fā)現(xiàn)模板語法錯(cuò)誤、參數(shù)名不匹配這類低級問題不用每次都啟動完整Agent鏈路。這類測試的覆蓋率在項(xiàng)目里大約占30%左右。別小看這30%它們保證了Agent運(yùn)行時(shí)的地基是穩(wěn)的。地基不穩(wěn)上層再聰明的模型也會被絆倒。3.3 第二類測試端到端場景測試重頭戲在這里。端到端場景測試模擬一個(gè)真實(shí)用戶從發(fā)起請求到目標(biāo)達(dá)成的完整鏈路。我給每個(gè)場景維護(hù)一個(gè)結(jié)構(gòu)化用例文件包含場景描述、初始環(huán)境、預(yù)期行為不變量、禁止行為列表。場景設(shè)計(jì)上我遵循二八法則。先梳理線上運(yùn)營反饋中高頻率出現(xiàn)的Top 20用戶需求把它們固化為場景用例。比如用戶查詢本月賬單并申請備注修改用戶咨詢退貨政策并引導(dǎo)提交售后單。這20個(gè)場景覆蓋了80%的生產(chǎn)流量形態(tài)是穩(wěn)定性的基本盤。每個(gè)場景用例的斷言按照前面說的兩層結(jié)構(gòu)來寫。行為軌跡層面斷言必須在N步內(nèi)完成、必須調(diào)用特定核心工具、不得調(diào)用禁區(qū)工具。業(yè)務(wù)結(jié)果層面斷言最終寫入數(shù)據(jù)庫的實(shí)體狀態(tài)、對外返回的關(guān)鍵字段。雙斷言確保Agent既干成了事又沒干出格。為了保證場景測試高效執(zhí)行我給測試框架設(shè)置了超時(shí)熔斷。單個(gè)場景最長允許多久由場景復(fù)雜度決定但每個(gè)用例都硬性設(shè)上限優(yōu)雅超時(shí)并導(dǎo)出截止當(dāng)前的軌跡日志方便排查是卡死還是慢。3.4 第三類測試穩(wěn)定性壓力測試場景測試解決對不對壓力測試解決扛不扛得住。Deepagents的壓力測試我是從三個(gè)維度做的。并發(fā)維度同一場景用例并發(fā)N個(gè)實(shí)例觀察資源占用和接口錯(cuò)誤率。連續(xù)維度同一場景串行循環(huán)執(zhí)行N次觀察Token消耗是否有泄漏、內(nèi)存是否持續(xù)增長、外部樁服務(wù)是否有連接泄漏。長鏈路維度構(gòu)造一個(gè)需要多個(gè)工具交替調(diào)用、跨數(shù)個(gè)上下文輪次的復(fù)雜任務(wù)驗(yàn)證長時(shí)間運(yùn)行下Agent的規(guī)劃能力和上下文記憶衰減情況。壓力測試的通過標(biāo)準(zhǔn)不是零失敗。LLM系統(tǒng)里零失敗是不現(xiàn)實(shí)的理想態(tài)。我定的標(biāo)準(zhǔn)是連續(xù)運(yùn)行的失敗率低于2%且任何一次失敗都能在30秒內(nèi)由重試機(jī)制拉起不會造成死循環(huán)或狀態(tài)錯(cuò)亂。實(shí)際操作中會發(fā)現(xiàn)很多在場景測試?yán)锱艿煤煤玫挠美贿M(jìn)壓力測試就出事。最常見的兩類一是Agent進(jìn)入循環(huán)策略反復(fù)調(diào)用同一個(gè)工具Token成本爆炸二是并發(fā)場景下多個(gè)實(shí)例共享某個(gè)工具的內(nèi)部可變狀態(tài)產(chǎn)生競態(tài)。這兩類問題都需要靠壓測來暴露。4. 高頻問題與排查實(shí)錄測試體系建起來之后運(yùn)維的挑戰(zhàn)才真正開始。下面是我在Deepagents測試建設(shè)過程中遇到的幾類高頻問題全部來自實(shí)際記錄每一類都對應(yīng)著可以復(fù)用的排查思路。4.1 斷言抖動問題測試結(jié)果忽綠忽紅這是Agent測試?yán)镒钭屓搜獕荷叩膯栴}。同一份代碼同一個(gè)用例上一條跑得好好的下一條就紅了而且沒有任何代碼變更。等十分鐘再跑一次又綠了。我排查這類問題有個(gè)固定流程。第一步看日志把失敗用例的完整軌跡和成功用例的軌跡做diff觀察差異發(fā)生在哪個(gè)環(huán)節(jié)。是LLM調(diào)用返回不同了還是某個(gè)工具M(jìn)ock返回值被并發(fā)修改了。第二步檢查測試隔離性看是不是有共享的可變狀態(tài)在用例間泄漏。第三步才輪到模型隨機(jī)性。一開始我經(jīng)常歸咎于LLM隨機(jī)性后來發(fā)現(xiàn)一大半抖動其實(shí)是測試自身不干凈造成的。Shared fixture、環(huán)境變量被某個(gè)用例改寫、Mock服務(wù)內(nèi)部計(jì)數(shù)器跨用例累積這些才是真正的元兇。把狀態(tài)隔離做好之后抖動率能下降一半以上。剩下的模型隨機(jī)性抖動通過放寬非關(guān)鍵路徑的斷言粒度來消化。4.2 工具副作用導(dǎo)致的狀態(tài)污染Deepagents執(zhí)行過程中經(jīng)常會出現(xiàn)連帶副作用。比如一個(gè)查詢用戶訂單的工具可能順手在訪問日志表里寫了一行記錄一個(gè)生成報(bào)告的工具可能向消息隊(duì)列推送了一個(gè)通知。單次執(zhí)行看不出問題但測試用例一多這些副作用就像漏水的水龍頭把測試環(huán)境的地板全泡濕了。我總結(jié)的排查信號是用例單獨(dú)跑全綠按某個(gè)固定順序跑就翻車且失敗位置和順序密切相關(guān)。這種九成是副作用污染。解決方案分兩層。第一層對所有測試用到的工具做副作用審計(jì)凡是會寫外部狀態(tài)的工具要么改成Mock版本要么在用例結(jié)束后做狀態(tài)回滾。第二層引入執(zhí)行前后快照比對機(jī)制跑完用例自動比對數(shù)據(jù)庫表行數(shù)、緩存Key集合、消息隊(duì)列積壓量一旦差異超出閾值直接標(biāo)紅。這個(gè)機(jī)制起來后測試環(huán)境的穩(wěn)定性上了一個(gè)臺階。副作用不再靠人肉排查系統(tǒng)會自動捕捉。4.3 成本控制與超時(shí)設(shè)計(jì)Deepagents測試跑久了最肉疼的是Token賬單。場景測試跑一次可能只要幾萬Token但壓力測試一晚跑下來消耗可以上百萬。我見過團(tuán)隊(duì)上線AI功能后測試環(huán)境成本比生產(chǎn)還高一截財(cái)務(wù)過來拍桌子的場面。成本控制我用了三板斧。第一板斧是分級執(zhí)行。日常提交只跑確定性單測和冒煙場景完整場景測試在夜間定時(shí)跑壓力測試只在發(fā)版前跑。第二板斧是規(guī)劃限制器。每個(gè)用例設(shè)置最大LLM調(diào)用次數(shù)一旦突破就被判失敗防止Agent陷入亂試循環(huán)。第三板斧是調(diào)用結(jié)果緩存。相同輸入條件下命中斷言規(guī)則的路徑結(jié)果緩存復(fù)用避免反復(fù)燒錢。超時(shí)設(shè)計(jì)是個(gè)容易被忽視的細(xì)節(jié)。Agent測試的超時(shí)不能簡單到點(diǎn)殺進(jìn)程——?dú)⑦M(jìn)程丟的是調(diào)試線索。我會在超時(shí)觸發(fā)時(shí)先嘗試導(dǎo)出當(dāng)前完整軌跡與工具調(diào)用鏈再做中斷。這樣即使用例最終是紅的也拿到了足夠分析的數(shù)據(jù)不會白白燒一次請求只得到一個(gè)timeout。5. 穩(wěn)定性建設(shè)的進(jìn)階心得如果前面的內(nèi)容是在解決有沒有這一節(jié)想聊的是穩(wěn)不穩(wěn)。Deepagents測試體系跑到后期真正拉開團(tuán)隊(duì)差距的不是用例數(shù)量而是對穩(wěn)定性細(xì)節(jié)的處理這里分享三個(gè)我反復(fù)打磨過的點(diǎn)。5.1 重試策略與指數(shù)退避Agent執(zhí)行過程中的失敗很多是臨時(shí)性的。Mock服務(wù)偶發(fā)延遲、外部API限流、LLM網(wǎng)關(guān)瞬時(shí)擁堵這類故障重試一下就好了。但重試要有策略最簡單粗暴的失敗就立即重跑是下策會讓系統(tǒng)在負(fù)載高峰時(shí)雪上加霜。我在框架層實(shí)現(xiàn)了指數(shù)退避重試。第一次失敗等待短信級別的時(shí)間第二次翻倍最多重試四輪。重試之間還加入了隨機(jī)抖動避免多個(gè)并發(fā)用例同時(shí)重試形成諧振峰。更關(guān)鍵的是重試只重跑失敗的那一步動作鏈不重新執(zhí)行整個(gè)Agent流程。這里需要Deepagents具備步驟級狀態(tài)快照能力運(yùn)行到每個(gè)工具調(diào)用處都記錄檢查點(diǎn)從檢查點(diǎn)恢復(fù)推進(jìn)。這套機(jī)制上線后壓測的最終成功率從96%級別提到了逼近100%。5.2 回歸測試基線的維護(hù)穩(wěn)定性還體現(xiàn)在不倒退。AI系統(tǒng)是持續(xù)迭代的提示詞文件在改、工具定義在改、模型版本在換。每次改動都可能讓原本穩(wěn)定的行為變得不穩(wěn)定?；貧w測試基線就是把每個(gè)場景的歷史成功軌跡特征沉淀下來做增量比對。具體做法我把每次發(fā)布的成功用例軌跡投影哈希后存入基線庫。新版本跑完同樣用例生成新的軌跡哈希和基線比對。如果哈希完全一致說明行為收斂如果差異較大就需要人工審查差異原因確認(rèn)是預(yù)期的優(yōu)化還是非預(yù)期的漂移。這個(gè)機(jī)制讓我在模型升級時(shí)心里有底。換模型前先跑基線庫觀察漂移面的范圍再決定是灰度切流還是繼續(xù)用老版本。沒有這層基線保護(hù)每次模型升級都是一場賭運(yùn)氣。5.3 把測試當(dāng)作產(chǎn)品功能本身來建設(shè)最后一個(gè)心得可能聽起來有點(diǎn)虛但它是整個(gè)體系的根基Deepagents測試不能當(dāng)作QA的負(fù)擔(dān)項(xiàng)目來做它應(yīng)該被當(dāng)作一條獨(dú)立的產(chǎn)品線來建設(shè)。我觀察到一個(gè)普遍現(xiàn)象AI項(xiàng)目早期測試都是員工抽空用腳本堆一些臨時(shí)用例接口一變腳本就崩然后沒人維護(hù)自動化測試就名存實(shí)亡了。要讓測試體系活下來必須賦予它和業(yè)務(wù)功能同等級的資源投入。團(tuán)隊(duì)里要有明確負(fù)責(zé)人維護(hù)測試框架用例要有版本管理測試環(huán)境的搭建和銷毀要實(shí)現(xiàn)一鍵化以及最關(guān)鍵的一點(diǎn)——測試用例的可讀性必須當(dāng)作代碼質(zhì)量來要求讓新成員能看懂得能改。我見過太多測試資產(chǎn)變成僵尸代碼的案例。那些用例其實(shí)跑過也發(fā)現(xiàn)過問題但因?yàn)闆]人維護(hù)斷言越寫越粗糙最后全被注釋掉或者干脆被刪除。Deepagents這個(gè)領(lǐng)域變化太快測試資產(chǎn)如果不用產(chǎn)品化的標(biāo)準(zhǔn)去維護(hù)三個(gè)月就報(bào)廢屆時(shí)穩(wěn)定性建設(shè)等于從零再來。最后的一點(diǎn)私貨Deepagents的自動化測試走到今天我感觸最深的一點(diǎn)是與其追求消除所有隨機(jī)性不如學(xué)會與不確定性共舞。LLM的創(chuàng)造力正是Agent產(chǎn)品的價(jià)值來源你不能既想要它靈活規(guī)劃又想讓它每條路徑都可預(yù)測。測試體系的全部藝術(shù)在于劃定一條范圍合理的邊界——邊界之內(nèi)自由發(fā)揮邊界之外有規(guī)則托底。在這個(gè)領(lǐng)域待久了會形成一種直覺看到一次測試失敗先不急著翻代碼而是去看Agent的行為軌跡里它是在哪一步開始偏離的。很多時(shí)候不是邏輯錯(cuò)了是它在嘗試一個(gè)你沒預(yù)料到的合理路徑而你的測試太窄了。改斷言而不是改產(chǎn)品這本身就是AI系統(tǒng)開發(fā)的常態(tài)。最后分享一個(gè)感覺把測試體系穩(wěn)定建設(shè)好之后團(tuán)隊(duì)最大的變化是敢改了。有了可信賴的回歸網(wǎng)絡(luò)提示詞調(diào)優(yōu)、工具增刪、模型替換都不再是如履薄冰的事反而變成了可以快速驗(yàn)證的實(shí)驗(yàn)過程。真正卡住AI應(yīng)用落地速度的往往不是模型能力不夠而是你不知道改完這一版會不會把線上已經(jīng)穩(wěn)的功能改壞。一套高質(zhì)量的自動化測試補(bǔ)齊的正是這個(gè)安全感缺口。如果你也正在被Agent穩(wěn)定性問題困擾我建議從最小閉環(huán)開始先固定測試環(huán)境再寫三個(gè)核心場景的端到端用例最后壓上壓力和回歸層。跑通這條路小步快跑前面提到的所有復(fù)雜設(shè)計(jì)都會在需要它們的時(shí)刻自然浮現(xiàn)出來。