測(cè)對(duì)比為何失真？從執(zhí)行回路到自建評(píng)測(cè)方法)
終端智能體Terminal Agent是近幾年“大模型 工程實(shí)踐”結(jié)合最緊密的方向之一。它讓大模型不再停留在對(duì)話窗口里而是直接接管 Shell通過執(zhí)行命令、觀察輸出、修正步驟來完成實(shí)際軟件任務(wù)。也正是因?yàn)樗尤氲氖钦鎸?shí)系統(tǒng)不同項(xiàng)目之間的對(duì)比才會(huì)出現(xiàn)許多看起來互相矛盾的結(jié)果同一個(gè)智能體在一個(gè)評(píng)測(cè)集上接近 SOTA在另一個(gè)評(píng)測(cè)集上卻排在中游同一套工具在一次演示中能完成多文件重構(gòu)在另一臺(tái)機(jī)器上卻連依賴都沒裝好。這個(gè)現(xiàn)象并不是評(píng)測(cè)方故意制造差異而是終端智能體的工作方式、評(píng)測(cè)基準(zhǔn)的設(shè)計(jì)目標(biāo)、使用場(chǎng)景的約束條件三者在互相影響。需要先澄清一個(gè)概念這里討論的“終端智能體”指運(yùn)行在命令行終端里的 AI 代理程序研究對(duì)象是如何讓大模型自動(dòng)執(zhí)行 Shell 命令并完成任務(wù)而不是指手機(jī)、電腦等終端設(shè)備上的端側(cè)模型。理解這一點(diǎn)后再看綜述材料里的“矛盾”會(huì)清晰很多。接下來文章會(huì)先拆解終端智能體的執(zhí)行回路再盤點(diǎn)主流項(xiàng)目與評(píng)測(cè)基準(zhǔn)最后給出可執(zhí)行的自建評(píng)測(cè)方法和生產(chǎn)落地建議。1. 先拆清楚終端智能體的執(zhí)行回路才能理解對(duì)比為什么失真很多綜述把終端智能體當(dāng)作一個(gè)整體來比較但實(shí)際使用時(shí)它是一條由“任務(wù)理解、命令執(zhí)行、輸出觀察、狀態(tài)更新、結(jié)果判斷”組成的回路。兩個(gè)項(xiàng)目表面上都能執(zhí)行命令內(nèi)部回路的設(shè)計(jì)卻可能完全不同對(duì)比結(jié)果自然不統(tǒng)一。1.1 終端智能體的最小工作單元終端智能體的輸入是一個(gè)自然語言任務(wù)描述輸出是若干命令、文件修改和最終總結(jié)。和聊天機(jī)器人相比它最大的特點(diǎn)是輸出會(huì)落在真實(shí)文件系統(tǒng)、進(jìn)程和網(wǎng)絡(luò)環(huán)境中因此每一步都要對(duì)現(xiàn)實(shí)結(jié)果負(fù)責(zé)。一個(gè)標(biāo)準(zhǔn)的執(zhí)行循環(huán)可以拆成四個(gè)階段。第一任務(wù)解析與規(guī)劃。智能體拿到任務(wù)后需要把目標(biāo)拆成可執(zhí)行步驟。比如“修復(fù)項(xiàng)目中的依賴沖突”需要先分析 package.json、鎖定文件、npm 版本再?zèng)Q定是升級(jí)依賴還是調(diào)整版本范圍。第二命令生成與執(zhí)行。智能體基于當(dāng)前狀態(tài)生成一條或多條 Shell 命令并送到終端執(zhí)行。這一步看起來簡(jiǎn)單實(shí)際難點(diǎn)在于命令的上下文依賴可能需要先讀取目錄結(jié)構(gòu)再?zèng)Q定執(zhí)行哪個(gè)腳本。第三輸出觀察與狀態(tài)更新。命令執(zhí)行后標(biāo)準(zhǔn)輸出、標(biāo)準(zhǔn)錯(cuò)誤、退出碼都需要被采集并回傳給模型。很多失敗就發(fā)生在這一層模型沒有看到完整報(bào)錯(cuò)只觀察到截?cái)嗪蟮哪┪灿谑亲龀隽隋e(cuò)誤判斷。第四結(jié)果判斷與循環(huán)控制。智能體判斷任務(wù)是否完成如果未完成則基于新的狀態(tài)繼續(xù)生成命令。為了防止死循環(huán)必須設(shè)置最大步數(shù)或超時(shí)時(shí)間。這個(gè)回路決定了終端智能體的能力邊界它既受底層模型推理能力影響也受命令執(zhí)行環(huán)境和狀態(tài)采集方式影響。綜述對(duì)比如果只比較“誰能完成任務(wù)”不比較回路里的這些細(xì)節(jié)結(jié)果就會(huì)失真。1.2 終端智能體與聊天機(jī)器人和 IDE 插件的關(guān)鍵差異要理解終端智能體的定位可以用三類工具做對(duì)比。對(duì)比維度聊天機(jī)器人IDE 插件終端智能體輸入用戶文本代碼上下文 用戶操作任務(wù)文本 環(huán)境狀態(tài)輸出對(duì)話文本補(bǔ)丁、建議、補(bǔ)全命令、文件修改、執(zhí)行結(jié)果狀態(tài)管理會(huì)話上下文編輯器緩沖區(qū)文件系統(tǒng)、進(jìn)程、環(huán)境變量反饋來源用戶繼續(xù)提問IDE 報(bào)錯(cuò)和代碼分析命令退出碼、stdout、stderr權(quán)限邊界無真實(shí)系統(tǒng)操作限制在編輯器內(nèi)可讀寫文件、安裝依賴、運(yùn)行服務(wù)失敗成本低重問一次即可中補(bǔ)丁可能不合法高可能污染環(huán)境或破壞代碼IDE 插件的控制范圍通常限制在編輯器和項(xiàng)目解析結(jié)果中終端智能體的控制范圍則擴(kuò)展到整個(gè) Shell。它既能執(zhí)行npm install也能運(yùn)行測(cè)試、修改配置、提交 Git 記錄。權(quán)限越大能力越強(qiáng)但可復(fù)現(xiàn)性和安全性就越差。這也是不同項(xiàng)目在“哪個(gè)更好用”上結(jié)論分歧非常大的原因之一。1.3 用最小代碼結(jié)構(gòu)模擬一個(gè)終端智能體循環(huán)為了把執(zhí)行回路講清楚這里用一段說明性 Python 代碼模擬一個(gè)終端智能體的最小骨架。這個(gè)示例只用于理解流程不構(gòu)成生產(chǎn)實(shí)現(xiàn)。import subprocess MAX_STEPS 30 class TerminalAgent: def __init__(self, model): self.model model self.history [] def run(self, task: str) - str: plan self.model.plan(task) for step in range(MAX_STEPS): command self.model.decide(plan, self.history) if command is None: break proc subprocess.run( command, shellTrue, capture_outputTrue, textTrue ) self.history.append({ command: command, stdout: proc.stdout[-2000:], stderr: proc.stderr[-2000:], code: proc.returncode, }) if self.model.is_done(plan, self.history): return self.model.summarize(plan, self.history) raise RuntimeError(max_steps_exceeded)這段代碼里有幾個(gè)設(shè)計(jì)點(diǎn)需要重點(diǎn)理解。第一是proc.stdout[-2000:]。真實(shí)終端輸出可能非常長模型上下文有限必須截?cái)嗷蛘咦稣＝財(cái)嚅L度會(huì)影響模型對(duì)失敗原因的判斷如果真正報(bào)錯(cuò)發(fā)生在輸出尾部之外模型就會(huì)丟失關(guān)鍵信息。第二是記錄returncode。退出碼是判斷命令是否成功的最硬指標(biāo)比解析輸出文本更可靠。但退出碼為 0 也不代表任務(wù)正確完成比如一個(gè)測(cè)試腳本沒有真正運(yùn)行測(cè)試就正常退出這種情況需要結(jié)合 stdout 內(nèi)容判斷。第三是MAX_STEPS。沒有它一個(gè)執(zhí)行失敗的智能體會(huì)無限嘗試既浪費(fèi) token也可能不斷修改文件造成不可控結(jié)果。生產(chǎn)系統(tǒng)中通常還應(yīng)該有總時(shí)長限制和操作審計(jì)。2. 主流終端智能體盤點(diǎn)和“看似同代、其實(shí)不同”的設(shè)計(jì)取向當(dāng)前終端智能體項(xiàng)目數(shù)量增長很快類型也很多樣。綜述對(duì)比矛盾的一個(gè)重要原因是作者把“都是終端里的智能體”當(dāng)作同一種東西卻沒有深究每個(gè)項(xiàng)目在權(quán)限模型、執(zhí)行方式、模型依賴上的差異。2.1 當(dāng)前常見的終端智能體項(xiàng)目以下表格用于幫助理解設(shè)計(jì)差異不構(gòu)成排名也不代表任何真實(shí)評(píng)測(cè)結(jié)果。這些項(xiàng)目迭代速度很快能力邊界也在不斷變化。項(xiàng)目常見定位執(zhí)行環(huán)境模型依賴開源情況Codex CLIOpenAI 推出的命令行編程智能體本地終端OpenAI 系列模型客戶端開源Claude CodeAnthropic 推出的終端編碼智能體本地或遠(yuǎn)程終端Claude 系列模型商業(yè)產(chǎn)品Gemini CLIGoogle 推出的終端智能體本地終端Gemini 系列模型開源OpenHands開源通用軟件工程智能體容器沙箱為主可插拔模型開源SWE-agent學(xué)術(shù)場(chǎng)景下的 Agent 框架評(píng)測(cè)沙箱可插拔模型開源GooseBlock 開源的終端智能體本地終端可插拔模型開源Qwen Code阿里 Qwen 生態(tài)的編碼智能體本地終端Qwen 系列模型開源從表格能看出不同項(xiàng)目至少存在四類差異執(zhí)行環(huán)境是本地還是容器沙箱、模型是綁定還是可插拔、產(chǎn)品形態(tài)是開源框架還是商業(yè) CLI、是否默認(rèn)鼓勵(lì)自主執(zhí)行。這些差異會(huì)直接改變使用體驗(yàn)和評(píng)測(cè)結(jié)果。2.2 最容易讓對(duì)比失真的一批配置項(xiàng)即使使用同一個(gè)項(xiàng)目只要配置不同任務(wù)表現(xiàn)就可能完全不同。綜述如果不記錄這些配置排名就失去了參考價(jià)值。配置項(xiàng)常見取值對(duì)結(jié)果的影響執(zhí)行模式dry-run、confirm、auto、audit確認(rèn)步驟越多速度越慢但誤操作越少文件系統(tǒng)權(quán)限允許寫整個(gè)目錄、只允許寫工作區(qū)權(quán)限過窄會(huì)失敗過寬會(huì)破壞環(huán)境網(wǎng)絡(luò)訪問允許安裝依賴、禁止外網(wǎng)無法安裝依賴的任務(wù)直接失敗上下文上限8k、32k、128k、200k截?cái)嗪竽Ｐ涂赡軄G失關(guān)鍵報(bào)錯(cuò)模型版本GPT-4o、Claude 3.5、Gemini 2.5 等不同模型對(duì)同一條命令鏈的推理差異明顯溫度與隨機(jī)參數(shù)0、0.2、0.7高隨機(jī)性會(huì)導(dǎo)致多次運(yùn)行結(jié)果不穩(wěn)定工作目錄項(xiàng)目根目錄、系統(tǒng)任意目錄路徑感知錯(cuò)誤會(huì)引發(fā)整條命令鏈偏離最容易踩的坑是把“同一個(gè) Agent 的默認(rèn)配置”誤當(dāng)成“該 Agent 的唯一能力”。一個(gè)配置為confirm模式的工具和一個(gè)配置為auto模式的工具在自主性指標(biāo)上會(huì)有巨大差異但這種差異并不代表底層模型能力不同。2.3 開源與商業(yè)產(chǎn)品的可觀測(cè)性差異開源終端智能體通常能輸出完整執(zhí)行日志方便二次分析和定制但日志字段、格式、采集方式需要自己維護(hù)。商業(yè)產(chǎn)品往往自帶可觀測(cè)面板但日志字段不一定完整開放對(duì)比時(shí)需要統(tǒng)一數(shù)據(jù)口徑。這導(dǎo)致一個(gè)現(xiàn)實(shí)問題綜述中的性能數(shù)據(jù)可能來自不同來源。有的數(shù)據(jù)是作者自己跑出來的有的引用廠商文檔有的來自開源倉庫的 README。這些數(shù)據(jù)的環(huán)境、模型、配置不同直接放在一張表里對(duì)比就會(huì)產(chǎn)生“矛盾”。后續(xù)章節(jié)會(huì)專門說明如何規(guī)避這個(gè)問題。3. 評(píng)測(cè)基準(zhǔn)差異是綜述對(duì)比矛盾的第一個(gè)放大器評(píng)測(cè)基準(zhǔn)是用戶觀察終端智能體能力的窗口但每個(gè)基準(zhǔn)的設(shè)計(jì)目標(biāo)不同考察的能力維度也不同。把不同基準(zhǔn)的結(jié)果放在一起比較就像把數(shù)學(xué)競(jìng)賽和編程比賽的成績直接相加結(jié)論必然失真。3.1 常見評(píng)測(cè)基準(zhǔn)和它們真正想考察的東西評(píng)測(cè)基準(zhǔn)主要面向典型任務(wù)結(jié)果判定方式SWE-bench軟件工程問題修復(fù)根據(jù) GitHub Issue 生成代碼補(bǔ)丁運(yùn)行隱藏測(cè)試集Terminal-Bench終端智能體能力操作終端完成命令、調(diào)試、版本管理檢查命令結(jié)果和輸出LiveCodeBench代碼生成與推理在線算法題執(zhí)行測(cè)試用例AgentBench多環(huán)境智能體操作系統(tǒng)、數(shù)據(jù)庫、網(wǎng)頁等執(zhí)行結(jié)果結(jié)合規(guī)則SWE-bench 關(guān)注的是模型能否理解一個(gè)真實(shí) Issue 并生成可通過測(cè)試的補(bǔ)丁。Terminal-Bench 更關(guān)注智能體能否在終端環(huán)境里逐步操作比如創(chuàng)建文件、運(yùn)行腳本、讀取日志、修正參數(shù)。LiveCodeBench 本質(zhì)上更接近代碼生成評(píng)測(cè)它不要求智能體操作終端只要求生成正確代碼。這些基準(zhǔn)的差異意味著一個(gè)智能體在 Terminal-Bench 上表現(xiàn)很好并不代表它能在 SWE-bench 上拿高分。反之亦然。3.2 同一個(gè)智能體為什么在不同評(píng)測(cè)集上名次不同造成名次漂移的原因可以分成四類。第一技能維度不同。SWE-bench 需要長上下文理解和精準(zhǔn)生成 diffTerminal-Bench 需要多輪命令交互和錯(cuò)誤恢復(fù)能力。一個(gè)模型可能長上下文能力強(qiáng)但命令糾錯(cuò)能力弱。第二任務(wù)粒度不同。SWE-bench 的每個(gè)任務(wù)可能需要閱讀多個(gè)文件、理解項(xiàng)目結(jié)構(gòu)、修改代碼Terminal-Bench 的某些任務(wù)可能只是執(zhí)行一條命令并檢查輸出。智能體在復(fù)雜任務(wù)上的策略和在簡(jiǎn)單任務(wù)上的策略完全不同。第三成功標(biāo)準(zhǔn)不同。有的基準(zhǔn)要求“最終狀態(tài)正確”有的要求“生成補(bǔ)丁能通過隱藏測(cè)試”還有的要求“交互過程中不能有高成本操作”。對(duì)同一個(gè)任務(wù)用不同標(biāo)準(zhǔn)判斷會(huì)得到完全不同的結(jié)論。第四嘗試次數(shù)策略不同。有的評(píng)測(cè)允許智能體反復(fù)嘗試直到超時(shí)有的只統(tǒng)計(jì)第一次成功。多輪嘗試會(huì)顯著提高成功率但也讓結(jié)果更難以解釋。3.3 評(píng)測(cè)污染、版本漂移和口徑不一致“為什么報(bào)告中的結(jié)果互相矛盾”還有一個(gè)重要來源評(píng)測(cè)集可能進(jìn)入了模型的訓(xùn)練語料或者模型版本已經(jīng)更新。公開評(píng)測(cè)集一旦被廣泛傳播新訓(xùn)練的模型就有可能見過題目。此時(shí)評(píng)測(cè)成績反映的更像“記憶能力”而不是“泛化能力”。這是很多綜述不愿意面對(duì)但必須承認(rèn)的問題。版本漂移也很常見。同一個(gè)終端智能體底層模型從舊版本升級(jí)到新版本后命令生成質(zhì)量可能顯著變化。如果兩份報(bào)告分別引用升級(jí)前后的結(jié)果又沒有標(biāo)注版本單看數(shù)字就會(huì)覺得矛盾。口徑不一致指成功判據(jù)、超時(shí)時(shí)間、是否人工輔助等細(xì)節(jié)不同。同樣是“80% 成功率”一個(gè)來自單輪自動(dòng)執(zhí)行一個(gè)來自多輪人工輔助執(zhí)行兩者完全不可比。寫綜述時(shí)這些信息每一項(xiàng)都必須記錄。4. 使用場(chǎng)景不同會(huì)讓同一個(gè)智能體得到兩種相反評(píng)價(jià)“這個(gè)智能體到底好不好用”在很大程度上取決于你在什么環(huán)境里使用它。本地開發(fā)和云端沙箱對(duì)智能體的要求截然不同一個(gè)在實(shí)驗(yàn)室里好用的 Agent到了生產(chǎn)環(huán)境可能因?yàn)闄?quán)限和審計(jì)限制而表現(xiàn)平平。4.1 本地開發(fā)、云端沙箱和 CI 流水線對(duì)智能體的要求場(chǎng)景網(wǎng)絡(luò)權(quán)限數(shù)據(jù)安全可重復(fù)性主要限制本地開發(fā)通常有外網(wǎng)代碼在本地中依賴本地環(huán)境環(huán)境差異化大操作可能影響開發(fā)機(jī)云端沙箱可控?cái)?shù)據(jù)隔離好高可構(gòu)建一致鏡像資源受限網(wǎng)絡(luò)策略復(fù)雜CI 流水線通常受限有代碼和密鑰高任務(wù)冪等權(quán)限管理嚴(yán)格失敗成本高在本地開發(fā)場(chǎng)景智能體可以直接修改文件、安裝依賴、運(yùn)行測(cè)試體驗(yàn)接近“一個(gè)人坐在終端前工作”。在云端沙箱場(chǎng)景智能體通常運(yùn)行在隔離容器里可以放心讓它自主執(zhí)行高風(fēng)險(xiǎn)操作。在 CI 流水線場(chǎng)景智能體可能只負(fù)責(zé)生成命令或補(bǔ)丁真正執(zhí)行由流水線完成因?yàn)樯婕按a倉庫權(quán)限和部署密鑰。這些場(chǎng)景對(duì)“成功”的定義也不同。本地任務(wù)可能以“開發(fā)體驗(yàn)順暢、沒破壞環(huán)境”為成功CI 任務(wù)可能以“補(bǔ)丁不引入新錯(cuò)誤”為成功云端任務(wù)可能以“有限時(shí)間內(nèi)完成全部步驟”為成功。4.2 自主程度與人工確認(rèn)會(huì)改變?nèi)蝿?wù)結(jié)果如果兩個(gè)評(píng)測(cè)分別使用不同執(zhí)行模式結(jié)果幾乎無法直接對(duì)比。常見執(zhí)行模式包括以下四種。dry-run 模式只打印命令不真實(shí)執(zhí)行。用于模型行為檢查和成本預(yù)估。confirm 模式每執(zhí)行一條高風(fēng)險(xiǎn)命令前都詢問用戶。安全但慢人工成本高。auto 模式智能體自主執(zhí)行全部命令只在任務(wù)結(jié)束時(shí)匯報(bào)。效率高但風(fēng)險(xiǎn)大。audit 模式全自主執(zhí)行但把每一步操作寫入審計(jì)日志事后可追溯。適合與權(quán)限回收配合。舉一個(gè)常見例子在 confirm 模式下智能體想執(zhí)行npm install需要等用戶確認(rèn)用戶如果不理解可能會(huì)拒絕導(dǎo)致任務(wù)失敗。在 auto 模式下同樣任務(wù)會(huì)自動(dòng)執(zhí)行并成功。如果把兩個(gè)模式的結(jié)果放進(jìn)同一種成功率統(tǒng)計(jì)里得出的結(jié)論就沒有意義。4.3 安全策略和權(quán)限模型影響成功率之外的所有指標(biāo)終端智能體的權(quán)限模型不只是安全話題也直接決定可用性。用一個(gè)簡(jiǎn)化的 YAML 示例說明最小權(quán)限原則在終端智能體上的落地。permissions: allow: - pwd - ls - git status - git diff - npm ci - npm test deny: - rm -rf / - curl * | bash - sudo * require_confirm: - git push - rm -rf dist - npm publish這個(gè)配置的含義是只允許查看目錄、Git 狀態(tài)、安裝依賴和運(yùn)行測(cè)試禁止危險(xiǎn)命令對(duì)推送倉庫、刪除構(gòu)建目錄、發(fā)布 npm 包這類高風(fēng)險(xiǎn)操作要求人工確認(rèn)。權(quán)限模型一旦變化成功率、耗時(shí)、token 消耗都會(huì)變化。在一個(gè)允許全權(quán)限的環(huán)境里智能體可以自由嘗試在最小權(quán)限環(huán)境里很多任務(wù)根本執(zhí)行不了。綜述如果不說明權(quán)限配置讀者看到“這個(gè) Agent 比那個(gè) Agent 差”就會(huì)產(chǎn)生錯(cuò)誤歸因。5. 不被綜述帶偏自己搭一套可復(fù)現(xiàn)的終端智能體評(píng)測(cè)選擇終端智能體的正確方式不是比較論文摘要而是建立自己的評(píng)測(cè)任務(wù)集在固定條件下驗(yàn)證。這里的核心原則是任務(wù)要貼近實(shí)際環(huán)境要可復(fù)現(xiàn)判定要客觀。5.1 先定義任務(wù)集而不是先比較總分一份好的任務(wù)集應(yīng)該覆蓋四類任務(wù)命令操作、代碼修改、環(huán)境配置、排錯(cuò)恢復(fù)。每個(gè)任務(wù)都應(yīng)有明確的輸入、準(zhǔn)備步驟、成功判據(jù)和超時(shí)時(shí)間。下面是一個(gè)任務(wù)描述示例使用 YAML 記錄便于腳本化執(zhí)行。task: id: t001 name: fix-dependency-conflict description: 修復(fù)項(xiàng)目中的依賴沖突使 npm test 通過 setup: - git clone https://example.com/repo.git - cd repo git checkout v1.0.0 success_criteria: - npm ci 執(zhí)行成功 - npm test 全部通過 timeout_seconds: 900 execution_mode: confirm model: claude-3-5-sonnet任務(wù)集的規(guī)模不需要很大。對(duì)于內(nèi)部選型20 到 50 個(gè)任務(wù)已經(jīng)能暴露穩(wěn)定差異。關(guān)鍵是要覆蓋自己實(shí)際工作的典型場(chǎng)景而不是從公開評(píng)測(cè)集里隨便抽幾條。5.2 固定環(huán)境、模型和執(zhí)行模式的評(píng)測(cè)步驟為了讓多次評(píng)測(cè)可以復(fù)現(xiàn)需要把環(huán)境固定下來。推薦用容器鏡像來保證每次運(yùn)行的文件系統(tǒng)、工具版本一致。docker build -t terminal-agent-eval:${COMMIT_ID} . agent eval --config eval.yaml --suite ./suites --output ./results固定內(nèi)容包括容器鏡像的提交哈希底層模型的名稱和版本API 端點(diǎn)和超時(shí)參數(shù)執(zhí)行模式auto、confirm、audit上下文長度上限最大步數(shù)和總時(shí)長評(píng)測(cè)任務(wù)集版本每次運(yùn)行后日志必須保留原始命令、輸出、退出碼和最終判定結(jié)果。沒有這些信息任何“成功”或“失敗”都無從復(fù)核。5.3 分析結(jié)果時(shí)重點(diǎn)關(guān)注哪些指標(biāo)和日志只看最終成功率是最容易犯的錯(cuò)誤。至少應(yīng)該同時(shí)記錄以下指標(biāo)。指標(biāo)含義為什么重要一次通過率未經(jīng)過修正就成功完成反映模型對(duì)任務(wù)的理解質(zhì)量最終成功率經(jīng)過多輪嘗試后成功反映智能體的容錯(cuò)和恢復(fù)能力平均命令數(shù)完成任務(wù)用了多少條命令衡量執(zhí)行效率和規(guī)劃能力平均 token 消耗單任務(wù)消耗多少上下文直接關(guān)系到成本平均耗時(shí)從任務(wù)開始到結(jié)束的時(shí)間影響生產(chǎn)環(huán)境可用性失敗原因分布環(huán)境、理解、權(quán)限、命令錯(cuò)誤的比例幫助定位瓶頸失敗原因分類可以按下面幾種統(tǒng)計(jì)環(huán)境準(zhǔn)備失敗、任務(wù)理解偏差、命令語法錯(cuò)誤、依賴安裝失敗、權(quán)限不足、超時(shí)、模型生成不穩(wěn)定。如果一份評(píng)測(cè)里失敗原因以“權(quán)限不足”為主說明問題不在智能體能力而在環(huán)境配置。6. 常見誤區(qū)、排查路徑與生產(chǎn)落地清單綜述對(duì)比中的“矛盾”大多數(shù)可以通過檢查實(shí)驗(yàn)條件來消除。這一部分歸納常見誤導(dǎo)方式并給出生產(chǎn)落地時(shí)需要遵守的工程底線。6.1 綜述里最容易誤導(dǎo)人的六種對(duì)比方式誤區(qū)為什么錯(cuò)正確做法用不同時(shí)間點(diǎn)的結(jié)果對(duì)比模型和工具版本都會(huì)變化同時(shí)段重新驗(yàn)證忽略底層模型版本同 Agent 換模型后表現(xiàn)差異大明確記錄模型版本拿 confirm 模式比 auto 模式的自主性執(zhí)行模式不同不可比統(tǒng)一執(zhí)行模式只對(duì)比成功率忽略成本和安全性同時(shí)看耗時(shí)、token 和失敗原因忽略環(huán)境差異容器與本地環(huán)境差異巨大統(tǒng)一鏡像和目錄結(jié)構(gòu)被演示視頻誤導(dǎo)演示通常挑選成功案例用任務(wù)集重復(fù)運(yùn)行并統(tǒng)計(jì)方差6.2 當(dāng)兩份報(bào)告出現(xiàn)矛盾時(shí)按這條鏈路排查面對(duì)兩個(gè)互相矛盾的對(duì)比結(jié)論不要馬上判斷誰對(duì)誰錯(cuò)。按以下順序檢查。確認(rèn)兩份報(bào)告的時(shí)間段是否重疊模型和 Agent 版本是否一致。確認(rèn)執(zhí)行模式是否相同是否一個(gè)用 confirm、一個(gè)用 auto。確認(rèn)評(píng)測(cè)任務(wù)集是否一致成功判據(jù)是否相同。確認(rèn)運(yùn)行環(huán)境是否一致本地、容器、CI 的網(wǎng)絡(luò)和權(quán)限差異是否被處理。確認(rèn)統(tǒng)計(jì)口徑成功率是最終成功率還是一次通過率。查看原始日志和失敗任務(wù)分布判斷差異由少數(shù)異常任務(wù)造成還是整體水平差異。用相同配置在同一任務(wù)集上重復(fù)運(yùn)行至少三輪觀察方差。6.3 學(xué)習(xí)環(huán)境、測(cè)試環(huán)境和生產(chǎn)環(huán)境的實(shí)施差異學(xué)習(xí)環(huán)境的目標(biāo)是快速體驗(yàn)可以直接運(yùn)行官方 demo使用默認(rèn)配置把項(xiàng)目放在臨時(shí)目錄里不要連接真實(shí)生產(chǎn)倉庫。測(cè)試環(huán)境的目標(biāo)是評(píng)估真實(shí)能力應(yīng)該建立固定任務(wù)集、固定容器鏡像、固定模型版本并保留全部運(yùn)行日志。生產(chǎn)環(huán)境的目標(biāo)是受控落地終端智能體不能直接獲得生產(chǎn)服務(wù)器的高權(quán)限。推薦的最低要求如下。使用最小權(quán)限賬戶只授權(quán)任務(wù)所需的目錄和命令。高風(fēng)險(xiǎn)操作必須有人工確認(rèn)或者接入審批流程。所有執(zhí)行記錄寫入審計(jì)日志包含時(shí)間、命令、退出碼和執(zhí)行者。設(shè)置資源限制包括最大步數(shù)、最大 token 數(shù)、最大運(yùn)行時(shí)長。對(duì)文件系統(tǒng)做快照或版本控制方便回滾。配置異常通知智能體連續(xù)失敗時(shí)及時(shí)告警。7. 綜述寫作與選型把結(jié)論建立在可復(fù)現(xiàn)的事實(shí)上無論你是要寫一篇終端智能體綜述還是要為公司做技術(shù)選型最底層的方法論是一致的減少不確定信息保留可復(fù)現(xiàn)信息。7.1 寫綜述或選型報(bào)告時(shí)應(yīng)該保留哪些信息一份合格的對(duì)比報(bào)告至少應(yīng)該包含以下元數(shù)據(jù)。智能體名稱和版本底層模型名稱和版本評(píng)測(cè)時(shí)間執(zhí)行模式權(quán)限配置容器鏡像或系統(tǒng)環(huán)境評(píng)測(cè)任務(wù)集名稱和版本成功判據(jù)單任務(wù)最大步數(shù)、超時(shí)時(shí)間運(yùn)行輪次和結(jié)果方差沒有這些信息任何對(duì)比結(jié)論都只能用于初步參考不能用于正式選型。7.2 終端智能體落地時(shí)的工程底線終端智能體不是更大的代碼生成模型它是一套可以修改真實(shí)環(huán)境的自動(dòng)化系統(tǒng)。落地時(shí)應(yīng)該像對(duì)待發(fā)布系統(tǒng)一樣對(duì)待它而不是像對(duì)待聊天機(jī)器人一樣。安全邊界要前置設(shè)計(jì)在接入終端智能體之前先明確它能訪問哪些目錄、能執(zhí)行哪些命令、能連接哪些網(wǎng)絡(luò)。日志要默認(rèn)全量記錄而不是失敗時(shí)才記錄。權(quán)限控制要支持按任務(wù)粒度動(dòng)態(tài)收縮不能一個(gè)授權(quán)貫穿所有任務(wù)。遇到系統(tǒng)被誤操作或命令鏈條失控時(shí)要能利用快照快速回滾。7.3 后續(xù)值得關(guān)注的擴(kuò)展方向終端智能體的發(fā)展還處在早期以下幾個(gè)方向值得持續(xù)關(guān)注。評(píng)測(cè)標(biāo)準(zhǔn)化終端智能體的評(píng)測(cè)會(huì)逐漸從“看論文數(shù)字”轉(zhuǎn)向“看可復(fù)現(xiàn)基準(zhǔn)”更多團(tuán)隊(duì)會(huì)建立內(nèi)部任務(wù)集把評(píng)測(cè)納入 CI 流程。多智能體協(xié)作一個(gè)智能體負(fù)責(zé)理解任務(wù)另一個(gè)負(fù)責(zé)代碼修改第三個(gè)負(fù)責(zé)測(cè)試驗(yàn)證每個(gè)角色都能在更窄的權(quán)限范圍內(nèi)運(yùn)行有助于控制風(fēng)險(xiǎn)。可觀測(cè)性增強(qiáng)執(zhí)行軌跡、命令副作用、上下文窗口利用率都會(huì)成為調(diào)試和選型的標(biāo)準(zhǔn)指標(biāo)。安全沙箱成熟化更細(xì)粒度的系統(tǒng)調(diào)用過濾、文件系統(tǒng)虛擬化和網(wǎng)絡(luò)代理會(huì)讓終端智能體在生產(chǎn)環(huán)境中獲得更大的操作空間同時(shí)不突破審計(jì)邊界。對(duì)比終端智能體時(shí)最需要保留的判斷是沒有脫離環(huán)境和配置的絕對(duì)能力排名。一份可靠的綜述真正有價(jià)值的不是“誰第一誰第二”而是那些可以被復(fù)現(xiàn)的運(yùn)行條件、失敗原因統(tǒng)計(jì)和生產(chǎn)風(fēng)險(xiǎn)提示。下次再看到兩個(gè)結(jié)論完全相反的終端智能體報(bào)告優(yōu)先去對(duì)比它們的評(píng)測(cè)時(shí)間、模型版本、執(zhí)行模式和環(huán)境配置而不是急著相信某一個(gè)結(jié)論。你能找到的“矛盾”往往就是評(píng)測(cè)信息不完整留下的缺口也是你自己搭建評(píng)測(cè)任務(wù)集時(shí)最該補(bǔ)上的位置。 終端智能體評(píng)測(cè)對(duì)比為何失真？從執(zhí)行回路到自建評(píng)測(cè)方法
終端智能體Terminal Agent是近幾年“大模型 工程實(shí)踐”結(jié)合最緊密的方向之一。它讓大模型不再停留在對(duì)話窗口里而是直接接管 Shell通過執(zhí)行命令、觀察輸出、修正步驟來完成實(shí)際軟件任務(wù)。也正是因?yàn)樗尤氲氖钦鎸?shí)系統(tǒng)不同項(xiàng)目之間的對(duì)比才會(huì)出現(xiàn)許多看起來互相矛盾的結(jié)果同一個(gè)智能體在一個(gè)評(píng)測(cè)集上接近 SOTA在另一個(gè)評(píng)測(cè)集上卻排在中游同一套工具在一次演示中能完成多文件重構(gòu)在另一臺(tái)機(jī)器上卻連依賴都沒裝好。這個(gè)現(xiàn)象并不是評(píng)測(cè)方故意制造差異而是終端智能體的工作方式、評(píng)測(cè)基準(zhǔn)的設(shè)計(jì)目標(biāo)、使用場(chǎng)景的約束條件三者在互相影響。需要先澄清一個(gè)概念這里討論的“終端智能體”指運(yùn)行在命令行終端里的 AI 代理程序研究對(duì)象是如何讓大模型自動(dòng)執(zhí)行 Shell 命令并完成任務(wù)而不是指手機(jī)、電腦等終端設(shè)備上的端側(cè)模型。理解這一點(diǎn)后再看綜述材料里的“矛盾”會(huì)清晰很多。接下來文章會(huì)先拆解終端智能體的執(zhí)行回路再盤點(diǎn)主流項(xiàng)目與評(píng)測(cè)基準(zhǔn)最后給出可執(zhí)行的自建評(píng)測(cè)方法和生產(chǎn)落地建議。1. 先拆清楚終端智能體的執(zhí)行回路才能理解對(duì)比為什么失真很多綜述把終端智能體當(dāng)作一個(gè)整體來比較但實(shí)際使用時(shí)它是一條由“任務(wù)理解、命令執(zhí)行、輸出觀察、狀態(tài)更新、結(jié)果判斷”組成的回路。兩個(gè)項(xiàng)目表面上都能執(zhí)行命令內(nèi)部回路的設(shè)計(jì)卻可能完全不同對(duì)比結(jié)果自然不統(tǒng)一。1.1 終端智能體的最小工作單元終端智能體的輸入是一個(gè)自然語言任務(wù)描述輸出是若干命令、文件修改和最終總結(jié)。和聊天機(jī)器人相比它最大的特點(diǎn)是輸出會(huì)落在真實(shí)文件系統(tǒng)、進(jìn)程和網(wǎng)絡(luò)環(huán)境中因此每一步都要對(duì)現(xiàn)實(shí)結(jié)果負(fù)責(zé)。一個(gè)標(biāo)準(zhǔn)的執(zhí)行循環(huán)可以拆成四個(gè)階段。第一任務(wù)解析與規(guī)劃。智能體拿到任務(wù)后需要把目標(biāo)拆成可執(zhí)行步驟。比如“修復(fù)項(xiàng)目中的依賴沖突”需要先分析 package.json、鎖定文件、npm 版本再?zèng)Q定是升級(jí)依賴還是調(diào)整版本范圍。第二命令生成與執(zhí)行。智能體基于當(dāng)前狀態(tài)生成一條或多條 Shell 命令并送到終端執(zhí)行。這一步看起來簡(jiǎn)單實(shí)際難點(diǎn)在于命令的上下文依賴可能需要先讀取目錄結(jié)構(gòu)再?zèng)Q定執(zhí)行哪個(gè)腳本。第三輸出觀察與狀態(tài)更新。命令執(zhí)行后標(biāo)準(zhǔn)輸出、標(biāo)準(zhǔn)錯(cuò)誤、退出碼都需要被采集并回傳給模型。很多失敗就發(fā)生在這一層模型沒有看到完整報(bào)錯(cuò)只觀察到截?cái)嗪蟮哪┪灿谑亲龀隽隋e(cuò)誤判斷。第四結(jié)果判斷與循環(huán)控制。智能體判斷任務(wù)是否完成如果未完成則基于新的狀態(tài)繼續(xù)生成命令。為了防止死循環(huán)必須設(shè)置最大步數(shù)或超時(shí)時(shí)間。這個(gè)回路決定了終端智能體的能力邊界它既受底層模型推理能力影響也受命令執(zhí)行環(huán)境和狀態(tài)采集方式影響。綜述對(duì)比如果只比較“誰能完成任務(wù)”不比較回路里的這些細(xì)節(jié)結(jié)果就會(huì)失真。1.2 終端智能體與聊天機(jī)器人和 IDE 插件的關(guān)鍵差異要理解終端智能體的定位可以用三類工具做對(duì)比。對(duì)比維度聊天機(jī)器人IDE 插件終端智能體輸入用戶文本代碼上下文 用戶操作任務(wù)文本 環(huán)境狀態(tài)輸出對(duì)話文本補(bǔ)丁、建議、補(bǔ)全命令、文件修改、執(zhí)行結(jié)果狀態(tài)管理會(huì)話上下文編輯器緩沖區(qū)文件系統(tǒng)、進(jìn)程、環(huán)境變量反饋來源用戶繼續(xù)提問IDE 報(bào)錯(cuò)和代碼分析命令退出碼、stdout、stderr權(quán)限邊界無真實(shí)系統(tǒng)操作限制在編輯器內(nèi)可讀寫文件、安裝依賴、運(yùn)行服務(wù)失敗成本低重問一次即可中補(bǔ)丁可能不合法高可能污染環(huán)境或破壞代碼IDE 插件的控制范圍通常限制在編輯器和項(xiàng)目解析結(jié)果中終端智能體的控制范圍則擴(kuò)展到整個(gè) Shell。它既能執(zhí)行npm install也能運(yùn)行測(cè)試、修改配置、提交 Git 記錄。權(quán)限越大能力越強(qiáng)但可復(fù)現(xiàn)性和安全性就越差。這也是不同項(xiàng)目在“哪個(gè)更好用”上結(jié)論分歧非常大的原因之一。1.3 用最小代碼結(jié)構(gòu)模擬一個(gè)終端智能體循環(huán)為了把執(zhí)行回路講清楚這里用一段說明性 Python 代碼模擬一個(gè)終端智能體的最小骨架。這個(gè)示例只用于理解流程不構(gòu)成生產(chǎn)實(shí)現(xiàn)。import subprocess MAX_STEPS 30 class TerminalAgent: def __init__(self, model): self.model model self.history [] def run(self, task: str) - str: plan self.model.plan(task) for step in range(MAX_STEPS): command self.model.decide(plan, self.history) if command is None: break proc subprocess.run( command, shellTrue, capture_outputTrue, textTrue ) self.history.append({ command: command, stdout: proc.stdout[-2000:], stderr: proc.stderr[-2000:], code: proc.returncode, }) if self.model.is_done(plan, self.history): return self.model.summarize(plan, self.history) raise RuntimeError(max_steps_exceeded)這段代碼里有幾個(gè)設(shè)計(jì)點(diǎn)需要重點(diǎn)理解。第一是proc.stdout[-2000:]。真實(shí)終端輸出可能非常長模型上下文有限必須截?cái)嗷蛘咦稣＝財(cái)嚅L度會(huì)影響模型對(duì)失敗原因的判斷如果真正報(bào)錯(cuò)發(fā)生在輸出尾部之外模型就會(huì)丟失關(guān)鍵信息。第二是記錄returncode。退出碼是判斷命令是否成功的最硬指標(biāo)比解析輸出文本更可靠。但退出碼為 0 也不代表任務(wù)正確完成比如一個(gè)測(cè)試腳本沒有真正運(yùn)行測(cè)試就正常退出這種情況需要結(jié)合 stdout 內(nèi)容判斷。第三是MAX_STEPS。沒有它一個(gè)執(zhí)行失敗的智能體會(huì)無限嘗試既浪費(fèi) token也可能不斷修改文件造成不可控結(jié)果。生產(chǎn)系統(tǒng)中通常還應(yīng)該有總時(shí)長限制和操作審計(jì)。2. 主流終端智能體盤點(diǎn)和“看似同代、其實(shí)不同”的設(shè)計(jì)取向當(dāng)前終端智能體項(xiàng)目數(shù)量增長很快類型也很多樣。綜述對(duì)比矛盾的一個(gè)重要原因是作者把“都是終端里的智能體”當(dāng)作同一種東西卻沒有深究每個(gè)項(xiàng)目在權(quán)限模型、執(zhí)行方式、模型依賴上的差異。2.1 當(dāng)前常見的終端智能體項(xiàng)目以下表格用于幫助理解設(shè)計(jì)差異不構(gòu)成排名也不代表任何真實(shí)評(píng)測(cè)結(jié)果。這些項(xiàng)目迭代速度很快能力邊界也在不斷變化。項(xiàng)目常見定位執(zhí)行環(huán)境模型依賴開源情況Codex CLIOpenAI 推出的命令行編程智能體本地終端OpenAI 系列模型客戶端開源Claude CodeAnthropic 推出的終端編碼智能體本地或遠(yuǎn)程終端Claude 系列模型商業(yè)產(chǎn)品Gemini CLIGoogle 推出的終端智能體本地終端Gemini 系列模型開源OpenHands開源通用軟件工程智能體容器沙箱為主可插拔模型開源SWE-agent學(xué)術(shù)場(chǎng)景下的 Agent 框架評(píng)測(cè)沙箱可插拔模型開源GooseBlock 開源的終端智能體本地終端可插拔模型開源Qwen Code阿里 Qwen 生態(tài)的編碼智能體本地終端Qwen 系列模型開源從表格能看出不同項(xiàng)目至少存在四類差異執(zhí)行環(huán)境是本地還是容器沙箱、模型是綁定還是可插拔、產(chǎn)品形態(tài)是開源框架還是商業(yè) CLI、是否默認(rèn)鼓勵(lì)自主執(zhí)行。這些差異會(huì)直接改變使用體驗(yàn)和評(píng)測(cè)結(jié)果。2.2 最容易讓對(duì)比失真的一批配置項(xiàng)即使使用同一個(gè)項(xiàng)目只要配置不同任務(wù)表現(xiàn)就可能完全不同。綜述如果不記錄這些配置排名就失去了參考價(jià)值。配置項(xiàng)常見取值對(duì)結(jié)果的影響執(zhí)行模式dry-run、confirm、auto、audit確認(rèn)步驟越多速度越慢但誤操作越少文件系統(tǒng)權(quán)限允許寫整個(gè)目錄、只允許寫工作區(qū)權(quán)限過窄會(huì)失敗過寬會(huì)破壞環(huán)境網(wǎng)絡(luò)訪問允許安裝依賴、禁止外網(wǎng)無法安裝依賴的任務(wù)直接失敗上下文上限8k、32k、128k、200k截?cái)嗪竽Ｐ涂赡軄G失關(guān)鍵報(bào)錯(cuò)模型版本GPT-4o、Claude 3.5、Gemini 2.5 等不同模型對(duì)同一條命令鏈的推理差異明顯溫度與隨機(jī)參數(shù)0、0.2、0.7高隨機(jī)性會(huì)導(dǎo)致多次運(yùn)行結(jié)果不穩(wěn)定工作目錄項(xiàng)目根目錄、系統(tǒng)任意目錄路徑感知錯(cuò)誤會(huì)引發(fā)整條命令鏈偏離最容易踩的坑是把“同一個(gè) Agent 的默認(rèn)配置”誤當(dāng)成“該 Agent 的唯一能力”。一個(gè)配置為confirm模式的工具和一個(gè)配置為auto模式的工具在自主性指標(biāo)上會(huì)有巨大差異但這種差異并不代表底層模型能力不同。2.3 開源與商業(yè)產(chǎn)品的可觀測(cè)性差異開源終端智能體通常能輸出完整執(zhí)行日志方便二次分析和定制但日志字段、格式、采集方式需要自己維護(hù)。商業(yè)產(chǎn)品往往自帶可觀測(cè)面板但日志字段不一定完整開放對(duì)比時(shí)需要統(tǒng)一數(shù)據(jù)口徑。這導(dǎo)致一個(gè)現(xiàn)實(shí)問題綜述中的性能數(shù)據(jù)可能來自不同來源。有的數(shù)據(jù)是作者自己跑出來的有的引用廠商文檔有的來自開源倉庫的 README。這些數(shù)據(jù)的環(huán)境、模型、配置不同直接放在一張表里對(duì)比就會(huì)產(chǎn)生“矛盾”。后續(xù)章節(jié)會(huì)專門說明如何規(guī)避這個(gè)問題。3. 評(píng)測(cè)基準(zhǔn)差異是綜述對(duì)比矛盾的第一個(gè)放大器評(píng)測(cè)基準(zhǔn)是用戶觀察終端智能體能力的窗口但每個(gè)基準(zhǔn)的設(shè)計(jì)目標(biāo)不同考察的能力維度也不同。把不同基準(zhǔn)的結(jié)果放在一起比較就像把數(shù)學(xué)競(jìng)賽和編程比賽的成績直接相加結(jié)論必然失真。3.1 常見評(píng)測(cè)基準(zhǔn)和它們真正想考察的東西評(píng)測(cè)基準(zhǔn)主要面向典型任務(wù)結(jié)果判定方式SWE-bench軟件工程問題修復(fù)根據(jù) GitHub Issue 生成代碼補(bǔ)丁運(yùn)行隱藏測(cè)試集Terminal-Bench終端智能體能力操作終端完成命令、調(diào)試、版本管理檢查命令結(jié)果和輸出LiveCodeBench代碼生成與推理在線算法題執(zhí)行測(cè)試用例AgentBench多環(huán)境智能體操作系統(tǒng)、數(shù)據(jù)庫、網(wǎng)頁等執(zhí)行結(jié)果結(jié)合規(guī)則SWE-bench 關(guān)注的是模型能否理解一個(gè)真實(shí) Issue 并生成可通過測(cè)試的補(bǔ)丁。Terminal-Bench 更關(guān)注智能體能否在終端環(huán)境里逐步操作比如創(chuàng)建文件、運(yùn)行腳本、讀取日志、修正參數(shù)。LiveCodeBench 本質(zhì)上更接近代碼生成評(píng)測(cè)它不要求智能體操作終端只要求生成正確代碼。這些基準(zhǔn)的差異意味著一個(gè)智能體在 Terminal-Bench 上表現(xiàn)很好并不代表它能在 SWE-bench 上拿高分。反之亦然。3.2 同一個(gè)智能體為什么在不同評(píng)測(cè)集上名次不同造成名次漂移的原因可以分成四類。第一技能維度不同。SWE-bench 需要長上下文理解和精準(zhǔn)生成 diffTerminal-Bench 需要多輪命令交互和錯(cuò)誤恢復(fù)能力。一個(gè)模型可能長上下文能力強(qiáng)但命令糾錯(cuò)能力弱。第二任務(wù)粒度不同。SWE-bench 的每個(gè)任務(wù)可能需要閱讀多個(gè)文件、理解項(xiàng)目結(jié)構(gòu)、修改代碼Terminal-Bench 的某些任務(wù)可能只是執(zhí)行一條命令并檢查輸出。智能體在復(fù)雜任務(wù)上的策略和在簡(jiǎn)單任務(wù)上的策略完全不同。第三成功標(biāo)準(zhǔn)不同。有的基準(zhǔn)要求“最終狀態(tài)正確”有的要求“生成補(bǔ)丁能通過隱藏測(cè)試”還有的要求“交互過程中不能有高成本操作”。對(duì)同一個(gè)任務(wù)用不同標(biāo)準(zhǔn)判斷會(huì)得到完全不同的結(jié)論。第四嘗試次數(shù)策略不同。有的評(píng)測(cè)允許智能體反復(fù)嘗試直到超時(shí)有的只統(tǒng)計(jì)第一次成功。多輪嘗試會(huì)顯著提高成功率但也讓結(jié)果更難以解釋。3.3 評(píng)測(cè)污染、版本漂移和口徑不一致“為什么報(bào)告中的結(jié)果互相矛盾”還有一個(gè)重要來源評(píng)測(cè)集可能進(jìn)入了模型的訓(xùn)練語料或者模型版本已經(jīng)更新。公開評(píng)測(cè)集一旦被廣泛傳播新訓(xùn)練的模型就有可能見過題目。此時(shí)評(píng)測(cè)成績反映的更像“記憶能力”而不是“泛化能力”。這是很多綜述不愿意面對(duì)但必須承認(rèn)的問題。版本漂移也很常見。同一個(gè)終端智能體底層模型從舊版本升級(jí)到新版本后命令生成質(zhì)量可能顯著變化。如果兩份報(bào)告分別引用升級(jí)前后的結(jié)果又沒有標(biāo)注版本單看數(shù)字就會(huì)覺得矛盾。口徑不一致指成功判據(jù)、超時(shí)時(shí)間、是否人工輔助等細(xì)節(jié)不同。同樣是“80% 成功率”一個(gè)來自單輪自動(dòng)執(zhí)行一個(gè)來自多輪人工輔助執(zhí)行兩者完全不可比。寫綜述時(shí)這些信息每一項(xiàng)都必須記錄。4. 使用場(chǎng)景不同會(huì)讓同一個(gè)智能體得到兩種相反評(píng)價(jià)“這個(gè)智能體到底好不好用”在很大程度上取決于你在什么環(huán)境里使用它。本地開發(fā)和云端沙箱對(duì)智能體的要求截然不同一個(gè)在實(shí)驗(yàn)室里好用的 Agent到了生產(chǎn)環(huán)境可能因?yàn)闄?quán)限和審計(jì)限制而表現(xiàn)平平。4.1 本地開發(fā)、云端沙箱和 CI 流水線對(duì)智能體的要求場(chǎng)景網(wǎng)絡(luò)權(quán)限數(shù)據(jù)安全可重復(fù)性主要限制本地開發(fā)通常有外網(wǎng)代碼在本地中依賴本地環(huán)境環(huán)境差異化大操作可能影響開發(fā)機(jī)云端沙箱可控?cái)?shù)據(jù)隔離好高可構(gòu)建一致鏡像資源受限網(wǎng)絡(luò)策略復(fù)雜CI 流水線通常受限有代碼和密鑰高任務(wù)冪等權(quán)限管理嚴(yán)格失敗成本高在本地開發(fā)場(chǎng)景智能體可以直接修改文件、安裝依賴、運(yùn)行測(cè)試體驗(yàn)接近“一個(gè)人坐在終端前工作”。在云端沙箱場(chǎng)景智能體通常運(yùn)行在隔離容器里可以放心讓它自主執(zhí)行高風(fēng)險(xiǎn)操作。在 CI 流水線場(chǎng)景智能體可能只負(fù)責(zé)生成命令或補(bǔ)丁真正執(zhí)行由流水線完成因?yàn)樯婕按a倉庫權(quán)限和部署密鑰。這些場(chǎng)景對(duì)“成功”的定義也不同。本地任務(wù)可能以“開發(fā)體驗(yàn)順暢、沒破壞環(huán)境”為成功CI 任務(wù)可能以“補(bǔ)丁不引入新錯(cuò)誤”為成功云端任務(wù)可能以“有限時(shí)間內(nèi)完成全部步驟”為成功。4.2 自主程度與人工確認(rèn)會(huì)改變?nèi)蝿?wù)結(jié)果如果兩個(gè)評(píng)測(cè)分別使用不同執(zhí)行模式結(jié)果幾乎無法直接對(duì)比。常見執(zhí)行模式包括以下四種。dry-run 模式只打印命令不真實(shí)執(zhí)行。用于模型行為檢查和成本預(yù)估。confirm 模式每執(zhí)行一條高風(fēng)險(xiǎn)命令前都詢問用戶。安全但慢人工成本高。auto 模式智能體自主執(zhí)行全部命令只在任務(wù)結(jié)束時(shí)匯報(bào)。效率高但風(fēng)險(xiǎn)大。audit 模式全自主執(zhí)行但把每一步操作寫入審計(jì)日志事后可追溯。適合與權(quán)限回收配合。舉一個(gè)常見例子在 confirm 模式下智能體想執(zhí)行npm install需要等用戶確認(rèn)用戶如果不理解可能會(huì)拒絕導(dǎo)致任務(wù)失敗。在 auto 模式下同樣任務(wù)會(huì)自動(dòng)執(zhí)行并成功。如果把兩個(gè)模式的結(jié)果放進(jìn)同一種成功率統(tǒng)計(jì)里得出的結(jié)論就沒有意義。4.3 安全策略和權(quán)限模型影響成功率之外的所有指標(biāo)終端智能體的權(quán)限模型不只是安全話題也直接決定可用性。用一個(gè)簡(jiǎn)化的 YAML 示例說明最小權(quán)限原則在終端智能體上的落地。permissions: allow: - pwd - ls - git status - git diff - npm ci - npm test deny: - rm -rf / - curl * | bash - sudo * require_confirm: - git push - rm -rf dist - npm publish這個(gè)配置的含義是只允許查看目錄、Git 狀態(tài)、安裝依賴和運(yùn)行測(cè)試禁止危險(xiǎn)命令對(duì)推送倉庫、刪除構(gòu)建目錄、發(fā)布 npm 包這類高風(fēng)險(xiǎn)操作要求人工確認(rèn)。權(quán)限模型一旦變化成功率、耗時(shí)、token 消耗都會(huì)變化。在一個(gè)允許全權(quán)限的環(huán)境里智能體可以自由嘗試在最小權(quán)限環(huán)境里很多任務(wù)根本執(zhí)行不了。綜述如果不說明權(quán)限配置讀者看到“這個(gè) Agent 比那個(gè) Agent 差”就會(huì)產(chǎn)生錯(cuò)誤歸因。5. 不被綜述帶偏自己搭一套可復(fù)現(xiàn)的終端智能體評(píng)測(cè)選擇終端智能體的正確方式不是比較論文摘要而是建立自己的評(píng)測(cè)任務(wù)集在固定條件下驗(yàn)證。這里的核心原則是任務(wù)要貼近實(shí)際環(huán)境要可復(fù)現(xiàn)判定要客觀。5.1 先定義任務(wù)集而不是先比較總分一份好的任務(wù)集應(yīng)該覆蓋四類任務(wù)命令操作、代碼修改、環(huán)境配置、排錯(cuò)恢復(fù)。每個(gè)任務(wù)都應(yīng)有明確的輸入、準(zhǔn)備步驟、成功判據(jù)和超時(shí)時(shí)間。下面是一個(gè)任務(wù)描述示例使用 YAML 記錄便于腳本化執(zhí)行。task: id: t001 name: fix-dependency-conflict description: 修復(fù)項(xiàng)目中的依賴沖突使 npm test 通過 setup: - git clone https://example.com/repo.git - cd repo git checkout v1.0.0 success_criteria: - npm ci 執(zhí)行成功 - npm test 全部通過 timeout_seconds: 900 execution_mode: confirm model: claude-3-5-sonnet任務(wù)集的規(guī)模不需要很大。對(duì)于內(nèi)部選型20 到 50 個(gè)任務(wù)已經(jīng)能暴露穩(wěn)定差異。關(guān)鍵是要覆蓋自己實(shí)際工作的典型場(chǎng)景而不是從公開評(píng)測(cè)集里隨便抽幾條。5.2 固定環(huán)境、模型和執(zhí)行模式的評(píng)測(cè)步驟為了讓多次評(píng)測(cè)可以復(fù)現(xiàn)需要把環(huán)境固定下來。推薦用容器鏡像來保證每次運(yùn)行的文件系統(tǒng)、工具版本一致。docker build -t terminal-agent-eval:${COMMIT_ID} . agent eval --config eval.yaml --suite ./suites --output ./results固定內(nèi)容包括容器鏡像的提交哈希底層模型的名稱和版本API 端點(diǎn)和超時(shí)參數(shù)執(zhí)行模式auto、confirm、audit上下文長度上限最大步數(shù)和總時(shí)長評(píng)測(cè)任務(wù)集版本每次運(yùn)行后日志必須保留原始命令、輸出、退出碼和最終判定結(jié)果。沒有這些信息任何“成功”或“失敗”都無從復(fù)核。5.3 分析結(jié)果時(shí)重點(diǎn)關(guān)注哪些指標(biāo)和日志只看最終成功率是最容易犯的錯(cuò)誤。至少應(yīng)該同時(shí)記錄以下指標(biāo)。指標(biāo)含義為什么重要一次通過率未經(jīng)過修正就成功完成反映模型對(duì)任務(wù)的理解質(zhì)量最終成功率經(jīng)過多輪嘗試后成功反映智能體的容錯(cuò)和恢復(fù)能力平均命令數(shù)完成任務(wù)用了多少條命令衡量執(zhí)行效率和規(guī)劃能力平均 token 消耗單任務(wù)消耗多少上下文直接關(guān)系到成本平均耗時(shí)從任務(wù)開始到結(jié)束的時(shí)間影響生產(chǎn)環(huán)境可用性失敗原因分布環(huán)境、理解、權(quán)限、命令錯(cuò)誤的比例幫助定位瓶頸失敗原因分類可以按下面幾種統(tǒng)計(jì)環(huán)境準(zhǔn)備失敗、任務(wù)理解偏差、命令語法錯(cuò)誤、依賴安裝失敗、權(quán)限不足、超時(shí)、模型生成不穩(wěn)定。如果一份評(píng)測(cè)里失敗原因以“權(quán)限不足”為主說明問題不在智能體能力而在環(huán)境配置。6. 常見誤區(qū)、排查路徑與生產(chǎn)落地清單綜述對(duì)比中的“矛盾”大多數(shù)可以通過檢查實(shí)驗(yàn)條件來消除。這一部分歸納常見誤導(dǎo)方式并給出生產(chǎn)落地時(shí)需要遵守的工程底線。6.1 綜述里最容易誤導(dǎo)人的六種對(duì)比方式誤區(qū)為什么錯(cuò)正確做法用不同時(shí)間點(diǎn)的結(jié)果對(duì)比模型和工具版本都會(huì)變化同時(shí)段重新驗(yàn)證忽略底層模型版本同 Agent 換模型后表現(xiàn)差異大明確記錄模型版本拿 confirm 模式比 auto 模式的自主性執(zhí)行模式不同不可比統(tǒng)一執(zhí)行模式只對(duì)比成功率忽略成本和安全性同時(shí)看耗時(shí)、token 和失敗原因忽略環(huán)境差異容器與本地環(huán)境差異巨大統(tǒng)一鏡像和目錄結(jié)構(gòu)被演示視頻誤導(dǎo)演示通常挑選成功案例用任務(wù)集重復(fù)運(yùn)行并統(tǒng)計(jì)方差6.2 當(dāng)兩份報(bào)告出現(xiàn)矛盾時(shí)按這條鏈路排查面對(duì)兩個(gè)互相矛盾的對(duì)比結(jié)論不要馬上判斷誰對(duì)誰錯(cuò)。按以下順序檢查。確認(rèn)兩份報(bào)告的時(shí)間段是否重疊模型和 Agent 版本是否一致。確認(rèn)執(zhí)行模式是否相同是否一個(gè)用 confirm、一個(gè)用 auto。確認(rèn)評(píng)測(cè)任務(wù)集是否一致成功判據(jù)是否相同。確認(rèn)運(yùn)行環(huán)境是否一致本地、容器、CI 的網(wǎng)絡(luò)和權(quán)限差異是否被處理。確認(rèn)統(tǒng)計(jì)口徑成功率是最終成功率還是一次通過率。查看原始日志和失敗任務(wù)分布判斷差異由少數(shù)異常任務(wù)造成還是整體水平差異。用相同配置在同一任務(wù)集上重復(fù)運(yùn)行至少三輪觀察方差。6.3 學(xué)習(xí)環(huán)境、測(cè)試環(huán)境和生產(chǎn)環(huán)境的實(shí)施差異學(xué)習(xí)環(huán)境的目標(biāo)是快速體驗(yàn)可以直接運(yùn)行官方 demo使用默認(rèn)配置把項(xiàng)目放在臨時(shí)目錄里不要連接真實(shí)生產(chǎn)倉庫。測(cè)試環(huán)境的目標(biāo)是評(píng)估真實(shí)能力應(yīng)該建立固定任務(wù)集、固定容器鏡像、固定模型版本并保留全部運(yùn)行日志。生產(chǎn)環(huán)境的目標(biāo)是受控落地終端智能體不能直接獲得生產(chǎn)服務(wù)器的高權(quán)限。推薦的最低要求如下。使用最小權(quán)限賬戶只授權(quán)任務(wù)所需的目錄和命令。高風(fēng)險(xiǎn)操作必須有人工確認(rèn)或者接入審批流程。所有執(zhí)行記錄寫入審計(jì)日志包含時(shí)間、命令、退出碼和執(zhí)行者。設(shè)置資源限制包括最大步數(shù)、最大 token 數(shù)、最大運(yùn)行時(shí)長。對(duì)文件系統(tǒng)做快照或版本控制方便回滾。配置異常通知智能體連續(xù)失敗時(shí)及時(shí)告警。7. 綜述寫作與選型把結(jié)論建立在可復(fù)現(xiàn)的事實(shí)上無論你是要寫一篇終端智能體綜述還是要為公司做技術(shù)選型最底層的方法論是一致的減少不確定信息保留可復(fù)現(xiàn)信息。7.1 寫綜述或選型報(bào)告時(shí)應(yīng)該保留哪些信息一份合格的對(duì)比報(bào)告至少應(yīng)該包含以下元數(shù)據(jù)。智能體名稱和版本底層模型名稱和版本評(píng)測(cè)時(shí)間執(zhí)行模式權(quán)限配置容器鏡像或系統(tǒng)環(huán)境評(píng)測(cè)任務(wù)集名稱和版本成功判據(jù)單任務(wù)最大步數(shù)、超時(shí)時(shí)間運(yùn)行輪次和結(jié)果方差沒有這些信息任何對(duì)比結(jié)論都只能用于初步參考不能用于正式選型。7.2 終端智能體落地時(shí)的工程底線終端智能體不是更大的代碼生成模型它是一套可以修改真實(shí)環(huán)境的自動(dòng)化系統(tǒng)。落地時(shí)應(yīng)該像對(duì)待發(fā)布系統(tǒng)一樣對(duì)待它而不是像對(duì)待聊天機(jī)器人一樣。安全邊界要前置設(shè)計(jì)在接入終端智能體之前先明確它能訪問哪些目錄、能執(zhí)行哪些命令、能連接哪些網(wǎng)絡(luò)。日志要默認(rèn)全量記錄而不是失敗時(shí)才記錄。權(quán)限控制要支持按任務(wù)粒度動(dòng)態(tài)收縮不能一個(gè)授權(quán)貫穿所有任務(wù)。遇到系統(tǒng)被誤操作或命令鏈條失控時(shí)要能利用快照快速回滾。7.3 后續(xù)值得關(guān)注的擴(kuò)展方向終端智能體的發(fā)展還處在早期以下幾個(gè)方向值得持續(xù)關(guān)注。評(píng)測(cè)標(biāo)準(zhǔn)化終端智能體的評(píng)測(cè)會(huì)逐漸從“看論文數(shù)字”轉(zhuǎn)向“看可復(fù)現(xiàn)基準(zhǔn)”更多團(tuán)隊(duì)會(huì)建立內(nèi)部任務(wù)集把評(píng)測(cè)納入 CI 流程。多智能體協(xié)作一個(gè)智能體負(fù)責(zé)理解任務(wù)另一個(gè)負(fù)責(zé)代碼修改第三個(gè)負(fù)責(zé)測(cè)試驗(yàn)證每個(gè)角色都能在更窄的權(quán)限范圍內(nèi)運(yùn)行有助于控制風(fēng)險(xiǎn)。可觀測(cè)性增強(qiáng)執(zhí)行軌跡、命令副作用、上下文窗口利用率都會(huì)成為調(diào)試和選型的標(biāo)準(zhǔn)指標(biāo)。安全沙箱成熟化更細(xì)粒度的系統(tǒng)調(diào)用過濾、文件系統(tǒng)虛擬化和網(wǎng)絡(luò)代理會(huì)讓終端智能體在生產(chǎn)環(huán)境中獲得更大的操作空間同時(shí)不突破審計(jì)邊界。對(duì)比終端智能體時(shí)最需要保留的判斷是沒有脫離環(huán)境和配置的絕對(duì)能力排名。一份可靠的綜述真正有價(jià)值的不是“誰第一誰第二”而是那些可以被復(fù)現(xiàn)的運(yùn)行條件、失敗原因統(tǒng)計(jì)和生產(chǎn)風(fēng)險(xiǎn)提示。下次再看到兩個(gè)結(jié)論完全相反的終端智能體報(bào)告優(yōu)先去對(duì)比它們的評(píng)測(cè)時(shí)間、模型版本、執(zhí)行模式和環(huán)境配置而不是急著相信某一個(gè)結(jié)論。你能找到的“矛盾”往往就是評(píng)測(cè)信息不完整留下的缺口也是你自己搭建評(píng)測(cè)任務(wù)集時(shí)最該補(bǔ)上的位置。