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