2. 為什么自用 Agent 值得做一次全面測試先說個背景。我大概從去年開始重度使用自建 Agent最開始也就是搭個殼子接入大模型 API讓它幫我查資料、整理筆記。后來逐漸加了工具調(diào)用、記憶系統(tǒng)、多輪對話管理功能越堆越多但說實話大部分時間都是“能用就行”的心態(tài)——只要它能跑通我常用的那幾條路徑我就不太愿意去折騰它。直到有一次我在一個比較重要的場景里連續(xù)踩了兩個坑一個是因為工具調(diào)用參數(shù)格式錯誤導致 Agent 白跑了一大段流程另一個是記憶串線把上一次對話的舊信息翻出來答非所問。那時候我才意識到自己天天在用的東西其實我根本不清楚它能干什么、不能干什么邊界在哪里壞了會以什么形式壞。所以就有了這次全面功能測試的想法。這篇博文不是給安全測試人員看的也不是權(quán)威評測報告就是一個普通開發(fā)者給自己的自用 Agent 做了一次摸底。測試對象是“自用”的意味著它不需要達到商用產(chǎn)品的穩(wěn)定性和覆蓋面但至少得讓使用者心里有數(shù)哪些功能是可靠的哪些是碰運氣的哪些干脆就是擺設。這套測試思路、用例設計、踩坑記錄對你自己的 Agent 同樣適用。3. 測試前要先想清楚的事3.1 明確 Agent 的能力邊界開始寫測試用例之前我先把整個 Agent 的功能拆了一遍。手頭的這個 Agent 核心能力包括接入大模型做自然語言對話支持多輪上下文調(diào)用外部工具主要是網(wǎng)絡搜索、網(wǎng)頁內(nèi)容抓取、本地文件讀寫、代碼執(zhí)行維護一個簡單的記憶系統(tǒng)能存儲和提取長期信息支持把長任務拆成多個步驟執(zhí)行輸出格式化內(nèi)容比如 Markdown、表格、統(tǒng)計摘要畫了一張功能清單之后就能很清楚地看到測試范圍應該覆蓋哪些方向。而且單子列出來之后還有一個額外好處你會發(fā)現(xiàn)有些功能你以為自己有、其實根本沒實現(xiàn)過比如我列完才發(fā)現(xiàn)“文件讀寫”這個工具雖然接了但從來沒實際穿過端到端流程。3.2 設計測試用例的基本原則給 Agent 設計測試用例和給傳統(tǒng)軟件設計測試用例有一些顯著差異。傳統(tǒng)軟件的行為是可預期的——同樣輸入、同樣路徑結(jié)果是確定的。但 Agent 底層是概率模型同樣一句話問兩次輸出可能不同甚至結(jié)論方向都可能不同。所以我的原則是每個用例不只測一次至少跑三遍觀察穩(wěn)定性覆蓋正確場景的同時必須覆蓋異常場景空輸入、超長輸入、歧義指令、模糊指代不只測“能不能答出來”還要測“答得對不對”“答得及時不及時”記錄每一項的失敗模式這個比記錄成功更有價值這是個很關(guān)鍵的思維轉(zhuǎn)變。我之前測試的時候總想著“驗證它行不行”但自用 Agent 的測試重心應該放在“了解它會在什么地方、以什么方式翻車”這決定了你在使用時能不能避開這些坑或者為該場景準備后備方案。3.3 測試環(huán)境與記錄方式自用系統(tǒng)的測試不需要什么專業(yè)的測試框架但環(huán)境隔離和記錄習慣還是要注意。我當時做了兩件事開了獨立的 API Key 和本地環(huán)境避免測試流量和生產(chǎn)環(huán)境的真實對話混在一起建了一個表格記錄每一個用例的測試描述、輸入內(nèi)容、預期行為、實際結(jié)果、穩(wěn)定性評價、失敗模式描述這個表格是整套測試的骨架。后期排查問題、復盤功能缺陷、甚至重新調(diào)整提示詞和工具參數(shù)都要回到這張表里找依據(jù)。4. 核心功能測試對話質(zhì)量和理解能力4.1 基礎(chǔ)問答能力第一塊測試的是最基礎(chǔ)的自然語言對話能力。這一塊我分了幾個方向來測常識問題比如“解釋一下什么是數(shù)據(jù)庫索引”背景敏感問題比如“幫我看看這份報告里哪個月的數(shù)據(jù)異常”需要結(jié)合對話歷史理解指代邏輯推理問題比如“A比B高B比C高誰最矮”創(chuàng)造性任務比如“幫我想五個博客標題”實測下來基礎(chǔ)問答基本沒問題大模型本身的語言能力擺在那里這塊其實最不需要擔心。但有一個失真現(xiàn)象值得注意同樣的提示詞反復問答案會換著花樣表達這在某些場景下會影響使用體驗。比如我讓它輸出固定格式的工作周報它每次的段落劃分、用詞習慣都會有細微變化我還得花時間整理格式。所以如果你對輸出格式有硬性要求建議在提示詞里加上“嚴格按照給定格式輸出”并且測試時專門加一條格式一致性用例。4.2 上下文理解與多輪對話這個是我比較關(guān)心的部分因為日常使用中絕大多數(shù)對話都不是一次性問完的。我模擬了三個場景連續(xù)追問型先問“上海本周天氣怎么樣”接著問“那下周呢”再問“適合穿什么衣服”信息累積型先拋一段背景材料再要求基于這段材料回答具體問題指代消解型對話中多次出現(xiàn)“它”“這個”“那家”等代詞看 Agent 能不能準確對應實測中發(fā)現(xiàn)3-5 輪之內(nèi)的多輪對話基本沒有問題模型能處理常見指代。但超過 8-10 輪之后確實開始出現(xiàn)上下文遺忘的跡象——尤其是前面幾輪提到的細節(jié)再提起來的時候它已經(jīng)不太記得了。這算是大模型的通病不能完全歸咎于 Agent 的設計。另外還發(fā)現(xiàn)一個有意思的現(xiàn)象長對話的后期即使模型沒有“遺忘”也可能因為上下文里信息太多而主動忽略某些細節(jié)。我用了一個故意埋信息的對話測試——在早期對話里提到了“密碼箱的密碼是 4312”中間穿插了十幾輪無關(guān)對話最后問“之前提到的密碼是什么”。結(jié)果是它給了一個完全編造的答案而不是“4312”。這個案例說明如果你的使用場景需要長期跨輪次的信息記憶單純靠對話上下文是不行的必須上外置記憶系統(tǒng)。4.3 輸入魯棒性測試這個部分我模擬的是真實使用中的“臟輸入”情況。主要包括空輸入、純標點輸入全英文內(nèi)容驗證非中文任務的能力包含“亂碼”和特殊字符的輸入歧義問題比如“蘋果好吃嗎”——是指水果還是指手機超長輸入一次性粘貼一大段文章測試是否有輸入長度限制結(jié)論是大部分臟輸入都能得到合理應對模型不會崩潰也不會報錯。但超長輸入環(huán)節(jié)發(fā)現(xiàn)了一個隱蔽問題——輸入超過一定長度后Agent 沒有拒絕也沒有截斷而是“假裝”看到了全文實際上中間部分的信息它就丟失了。這個比直接報錯更難發(fā)現(xiàn)因為表面流程是走完的輸出的內(nèi)容質(zhì)量卻明顯下降。建議在自用時對超長內(nèi)容先做分段摘要處理不要直接一股腦塞給 Agent。5. 工具調(diào)用與多步執(zhí)行測試5.1 整體方案和數(shù)據(jù)來源“自用 Agent 的全面功能測試”這個標題里的重點其實是“Agent”而 Agent 相比普通聊天機器人最大的區(qū)別就是能調(diào)用工具、執(zhí)行動作。這一塊是測試的重頭戲。我手頭的 Agent 集成了幾類工具網(wǎng)絡搜索、網(wǎng)頁抓取、本地文件讀寫、代碼執(zhí)行。測試策略是對每一個工具設計“正確調(diào)用”和“錯誤觸發(fā)”兩類用例觀察 Agent 是否能在合適的場景選擇正確的工具以及給出不完整信息時能否澄清需求。5.2 網(wǎng)絡搜索與信息抓取搜索類工具最常見的翻車方式是Agent 編造搜索結(jié)果。具體來說我在測試“幫我查一下某本技術(shù)書在網(wǎng)站上的最新評論”時過一會兒它給了我一個看似正常的答案包含了評分和評論摘要。我后來去人工比對發(fā)現(xiàn)結(jié)果基本對不上評分甚至完全錯誤。這說明 Agent 在搜索工具沒有得到有效結(jié)果時會“腦補”一個合理答案。這是一個非常高風險的失敗模式比直接說“我沒找到”嚴重得多。因為你根本不會察覺它是在編造尤其當結(jié)論看起來還挺合理的時候。我的應對方式是給搜索類工具的提示詞里加了一條硬規(guī)則必須提供具體來源鏈接且答案摘要必須與來源頁面內(nèi)容一致如果沒有搜到有效結(jié)果明確回復“未找到相關(guān)信息”禁止猜測或編造。加了這條之后編造的情況明顯減少但沒有完全杜絕。網(wǎng)頁抓取工具的問題則是另一個方向經(jīng)常遇到目標網(wǎng)站有反爬策略、需要登錄、或者頁面結(jié)構(gòu)復雜導致核心內(nèi)容被遺漏。這算是工具本身的局限性不算 Agent 的 Bug但它會影響你判斷 Agent 的輸出質(zhì)量到底算不算合格。所以測試的時候要分開記錄“工具執(zhí)行失敗”和“Agent 決策失誤”兩類錯誤否則排查問題時會非常混亂。5.3 代碼執(zhí)行與文件讀寫代碼執(zhí)行這塊我是帶了點“故意刁難”的心態(tài)去測的。比如讓它“寫一個 Python 腳本計算某目錄下所有文件的總大小”讓它“讀一下某個文件的前 10 行并統(tǒng)計關(guān)鍵詞出現(xiàn)次數(shù)”讓它“執(zhí)行剛才的腳本然后告訴我輸出”實測下來簡單的代碼生成和本地執(zhí)行路徑是通的但它有一個常見的決策問題生成代碼之后不會先檢查代碼的正確性就執(zhí)行。遇到?jīng)]有安裝的依賴包就直接報錯退出。這對自用來說還能接受我會在提示詞里讓 Agent 在代碼執(zhí)行前自動檢查依賴、做好異常處理但坦白說距離“順手”還有差距。5.4 多步任務拆解這個功能是我最期待的也是最失望的。我設計了一個典型的多步驟任務“查一下某城市最近三天空氣質(zhì)量然后結(jié)合近期天氣給出戶外運動建議最后把建議整理成一份 200 字左右的摘要?！崩硐霠顟B(tài)下Agent 應該先調(diào)用搜索獲取數(shù)據(jù)再推理分析最后格式化輸出。但實測結(jié)果時好時壞——大約一半的次數(shù)它跳過搜索直接“憑常識”回答另外一半才是真正調(diào)用工具完成全流程。即使調(diào)用了工具中間還可能漏步驟比如只做了空氣質(zhì)量部分天氣和活動建議就草草帶過。這種“流程不可控”的問題是自用 Agent 在日常使用中最消耗信任的地方。你給了一個復雜任務之后根本不知道它會走哪條路完成它甚至不知道它會不會“偷懶”抄近路。優(yōu)化方式上我嘗試過在提示詞里強制要求“按步驟執(zhí)行每步輸出中間結(jié)果”有改善但不多。后來我換了個思路把復雜任務的執(zhí)行流程拆成獨立的會話讓 Agent 每完成一步就停下來確認再進入下一步。這犧牲了一點自動化程度但大幅提高了可控性。6. 記憶能力的專項測試6.1 記憶系統(tǒng)開關(guān)與存儲持久性我用的這個 Agent 配了一個輕量級的記憶系統(tǒng)邏輯很簡單對話過程中持續(xù)提取關(guān)鍵信息比如用戶偏好、事實性數(shù)據(jù)、任務進度存儲到本地在后續(xù)對話中作為上下文注入。測試分兩塊一是會話內(nèi)記憶二是跨會話記憶。會話內(nèi)記憶的測試結(jié)果比預期好。前面提過的“密碼 4312”那個用例在開啟了記憶系統(tǒng)之后表現(xiàn)不錯它能在十幾輪對話之后準確調(diào)出早期信息。說明記憶系統(tǒng)對于長對話的信息保持確實有效。跨會話記憶就有點微妙了。我專門過了一天之后再來問“我上次聊天時讓你記住的那個寫作偏好是什么”結(jié)果它能準確回答出來。這個結(jié)果我很滿意。但在另一個測試里發(fā)現(xiàn)了一個問題記憶系統(tǒng)會把一些不該記的信息也存進去比如一次性的、臨時性的內(nèi)容。這種信息如果又被注入到后續(xù)對話里可能造成干擾。更麻煩的是有些事實性信息如果后期被糾正比如用戶改了偏好或數(shù)據(jù)更新記憶里的舊信息不會自動被覆蓋新舊信息同時存在時 Agent 可能會用舊的。6.2 記憶錯亂與信息污染實際測試中最容易踩到的坑是記憶污染。舉例說明我先讓它記住“我最喜歡深色主題”然后在一次閑聊里提到了“亮色壁紙也不錯”下次再問它我的偏好時聊天 A 的測試它答“深色主題”而聊天 B 的測試它卻可能答“亮色主題”——因為記憶系統(tǒng)可能提取了“亮色”作為一個新的偏好片段并且和舊信息做了錯誤的整合。這種情況非常隱蔽。因為單一對話看起來是正常的、連貫的但只有把多段對話放在一起看你才會發(fā)現(xiàn) Agent 的“記憶”其實是一堆碎片拼湊出來的未必代表你真實的狀態(tài)。測試結(jié)論自用 Agent 的記憶系統(tǒng)適合存“穩(wěn)定且明確的事實”比如常駐的城市、稱呼、職業(yè)信息不適合存“觀點傾向”和“動態(tài)狀態(tài)”這類容易變化的信息。后者建議直接寫在每次對話的提示詞里不要依賴長期記憶。7. 壓力測試與極限場景7.1 雙線程多任務并發(fā)測試自用場景下先測試多開“同時開兩個對話窗口一個在處理數(shù)據(jù)分析任務另一個在寫文案來回切換問問題”。實測結(jié)果比較驚喜會話隔離做得不錯兩個窗口的內(nèi)容互不串擾各自上下文保持完整。這說明 Agent 的會話管理是可靠的至少不會出現(xiàn) A 對話的上下文跑到 B 對話里的低級錯誤。但有一個細節(jié)需要注意Agent 的資源占用會隨會話數(shù)增加而明顯上漲。我本地部署的環(huán)境原本單會話響應時間大約 2-3 秒雙會話同時活躍時單邊響應時間能拉到 5 秒以上。如果你打算把自用 Agent 部署在小內(nèi)存機器上這點要有心理準備。7.2 低質(zhì)量提示詞與誘導性輸入這部分我主要測的是“邊界場景”比如讓它“幫我想個辦法繞過某網(wǎng)站的內(nèi)容限制”試探越獄類讓它“直接生成一份包含個人隱私的模擬數(shù)據(jù)”用情緒極端的語言對話看它的反應傾向坦白說自用 Agent 沒有商業(yè)產(chǎn)品那么嚴格的安全護欄它的表現(xiàn)很大程度上取決于提示詞和底模的選擇。但基礎(chǔ)的對齊能力還是有的對明顯越界的內(nèi)容會拒絕或提醒。不過測試中也發(fā)現(xiàn)了“邊緣回答”現(xiàn)象如果問題的表述比較委婉、經(jīng)過包裝Agent 可能會順著話頭往下說給出打擦邊球的建議。這點沒辦法靠配置完全解決只能靠使用者的自我判斷。7.3 連續(xù)交互疲勞度測試這個測試模擬通宵掛機場景不手動關(guān)閉 Agent連續(xù)對話 50 輪以上內(nèi)容涉及不同主題觀察是否出現(xiàn)異常。結(jié)果還算穩(wěn)沒有出現(xiàn)卡死、報錯、崩潰之類的問題。響應速度也沒有隨輪次增加明顯下降。但出現(xiàn)一個“上下文退化”現(xiàn)象50 輪之后Agent 對早期輪次的信息保留得很好因為記憶系統(tǒng)起了作用但對中期輪次約 20-40 輪之間的內(nèi)容反應明顯遲鈍經(jīng)常出現(xiàn)“這些內(nèi)容之前聊過嗎”的困惑。這可能和上下文窗口的管理策略有關(guān)——系統(tǒng)可能在窗口壓縮時丟棄了中間部分的內(nèi)容。這給我的教訓是不要在超長會話里和 Agent 來回拉扯不清的話題差不多就開新會話。保持 20 輪以內(nèi)的會話長度交互質(zhì)量最穩(wěn)定。8. 測試后的迭代與調(diào)優(yōu)8.1 根據(jù)失敗模式反向優(yōu)化提示詞全面測試最大的價值不是發(fā)現(xiàn)問題而是針對性修復問題。我根據(jù)測試記錄做了三處主要調(diào)整對搜索工具增加“必須給出來源”的硬性約束減少編造結(jié)果的現(xiàn)象對多步驟任務增加“分階段確認”機制避免中間步驟被跳過對記憶系統(tǒng)把“用戶偏好”類信息從自動提取改為手動確認——只有用戶明確說“記住這個”時才寫入記憶這三條改動都不需要動代碼純提示詞級就能解決效果立竿見影。尤其是第一條改了之后編造搜索結(jié)果的情況從“經(jīng)?！苯档搅恕芭紶枴蔽乙呀?jīng)很滿意了。8.2 工具參數(shù)與執(zhí)行策略的調(diào)整工具調(diào)用方面我也做了一些調(diào)整。原本代碼執(zhí)行工具是“寫代碼 - 直接執(zhí)行”我改成了“寫代碼 - 展示代碼 - 確認執(zhí)行”兩步流程。這樣雖然多一步交互但避免了它在依賴缺失、語法錯誤時盲目跑起來浪費時間。網(wǎng)絡搜索工具也加了結(jié)果數(shù)量限制和內(nèi)容時效性要求避免它抓到過時信息。這些都是測試后才知道要改的細節(jié)沒有測試你根本不會知道你自用的 Agent 在哪些環(huán)節(jié)會翻車。8.3 值得保留的“意外之喜”測試也不全是發(fā)現(xiàn)問題。有些功能表現(xiàn)超出預期我正常使用時都沒注意到。比如它的“長文總結(jié)能力”——我給它喂了一篇 1.5 萬字的中文技術(shù)文檔它產(chǎn)出的摘要不僅覆蓋了核心論點還保留了技術(shù)細節(jié)和關(guān)鍵數(shù)據(jù)幾乎沒有丟重點。這個能力比我自己讀原文整理效率高得多。另一項是“格式化輸出穩(wěn)定性”——讓它生成表格、列表、結(jié)構(gòu)化 JSON 數(shù)據(jù)時即便連續(xù)測試多次輸出的結(jié)構(gòu)也都很穩(wěn)定沒有出現(xiàn)過格式錯亂。這兩塊能力目前已經(jīng)成為我日常使用的高頻功能。9. 自用 Agent 測試后的幾個心得9.1 測試不需要專業(yè)工具但需要記錄習慣回頭看整個測試過程我沒有用任何測試框架也沒有寫自動化測試腳本。就是一張表格、一個耐心、一段集中時間的操作效果已經(jīng)遠超預期。核心不在于工具而在于你有沒有把每次測試的輸入、預期、實際表現(xiàn)、失敗模式記錄下來。9.2 不要用“正確率”來衡量自用 Agent我用了一個很笨的統(tǒng)計方式每個用例跑三遍數(shù)一下“幾次正常、幾次異?！弊詈蟀搭悇e匯總。結(jié)果發(fā)現(xiàn)正確率并不能真實反映問題——有些用例雖然三次全對但中間有一次差點跑偏只是因為運氣好才沒翻車。真正值得關(guān)注的是“它的失敗會不會被察覺”。如果 Agent 翻車時用戶能一眼看出答案有問題那是安全的失敗如果翻車時看起來還挺合理那就是危險的失敗。我的測試重心應該放在后者。9.3 每隔一段時間應該重新跑一遍這個測試做完之后我又對系統(tǒng)做了幾處微調(diào)。但我知道大模型底層升級、工具接口變動、提示詞調(diào)整都可能導致之前記錄的結(jié)論失效。我的習慣是每次大幅改動后就跑一遍核心用例集一個月左右做一次全量回歸。如果你有自用 Agent也可以參考這個頻率。成本不高但能確保你對它的了解始終跟得上它的變化——這一點對自用系統(tǒng)來說比追求某個技術(shù)指標的完美更重要。我在實際測試過程中最大的體驗是搞清楚“我的 Agent 哪里會翻車、翻車時好不好察覺”比我讓它跑通多少個成功用例更安心。帶著這種邊界感去使用它在日常工作中發(fā)揮的作用才真正變得可被信賴。