2026-06-24

一個企業 AI Agent 專案值不值得做：6 個工程判斷訊號

在啟動企業 AI Agent 專案前，如何從工程角度做出理性判斷？本文將模糊的「能不能做」拆解為 6 個可量化的工程訊號：任務可斷言性、流程穩定性、確定性邊界（pass^k）、ROI 天花板、風險可治理性與評估可補建性。每個訊號都有明確的檢驗方式，幫助技術團隊在立項階段完成嚴謹的 AI Agent 專案評估，避免在錯誤的方向上持續投入。

先問「能不能做」：把模糊判斷拆成 6 個工程訊號

大多數 Agent 專案的立項會議，最後拍板靠的是兩樣東西：一段跑得很順的演示，和供應商一句「這個場景我們做過」。這兩樣都不假，但都回答不了真正該問的問題——這個任務交給 Agent，工程上能不能穩定收斂。把「值不值得做」直接當成商業問題來談，往往是把後面三個月的返工提前埋進了合同裡。

問題的根子在評估這一端還沒收口。如今衡量 Agent 的基準遍地都是，從偏學術的推理題到貼近產業的端到端任務，光是成體系的大類就有十幾種，彼此口徑不一、覆蓋場景各異。結果是同一個 Agent 拿不同基準去測，分數可以差出一截，而決策者手上並沒有一把能橫向對齊的尺子。基準多不等於有標準，恰恰因為缺一個公認座標系，選型才更容易被漂亮的單點數字帶偏。

更要緊的是，演示態和生產態之間隔著一道很陡的臺階。在受控的、步驟不長的樣例裡，今天的強模型確實能給出令人信服的表現；可一旦換到需要多輪規劃、跨工具呼叫、狀態會累積的複雜流程，哪怕是第一梯隊的模型，能把整條鏈路一次走通的比例也會掉得很厲害——遠沒到能閉眼託付給終端使用者的程度。這不是某個模型的短板，而是當前這代技術在長程任務上的共同天花板。它給決策者的提示很直接：不要用一次成功的 demo，去推斷一萬次執行的穩定性。

所以我們把「能不能做」拆開，落到六個可以逐項核驗的工程訊號上。它們不是打分表，而是一串前置閘門——任何一道關不上，後面投多少資源都是在賭運氣：

資料可得性：任務的對錯能不能被明確「斷言」，有沒有足夠的真實樣本去定義成功與失敗。這一關決定了你後面有沒有東西可測。
流程穩定性：除了最終的 success_rate，中間每一步是否可觀測、可復現。整體成功率高，未必代表過程不靠運氣。
確定性邊界：同一個輸入反覆跑，結果分佈有多散。這直接決定它能不能直接面向用戶，還是只能放在人工兜底之後。
ROI 邊界：能力天花板在哪，評估會不會過早飽和。投入產出不是看峰值，而是看那條能力曲線還有沒有繼續抬升的空間。
風險可治理性：錯誤發生時有沒有 Guardrail 能攔住。沒有可落地的護欄，再高的平均表現也不該上線。
評估可補建：現在沒有現成評測集，並不意味著專案要否決。它是 Go/No-Go 前最後補齊的一勾，而非阻塞立項的硬條件。

這六個訊號的次序是有講究的。前兩個回答「任務本身可不可被工程化」，中間兩個回答「做到什麼程度算夠用」，後兩個回答「出了問題收不收得住」。一個值得做的 Agent 專案，不是六項都滿分，而是清楚自己卡在哪一項、缺口有多大、補這個缺口要花多少代價。接下來我們逐個拆解，先從最容易被跳過、卻最致命的那一條說起——任務的成敗，到底能不能被明確地斷言出來。

訊號一：任務能否被「斷言」——資料與樣本可得性

很多團隊在評估 Agent 專案時，第一句話就問錯了:「現在的模型夠不夠強?」這個問題排在後面。立項階段真正卡住你的，是一個更樸素的事實——你能不能把這個任務寫成一組可被檢驗的「斷言」。也就是說，給定某個輸入，你能否清楚說出「正確的結果應該長這樣」,並且找出幾十個真實場景把這句話填滿。如果連這一步都做不到，模型再強也沒有抓手。

所謂「斷言」,落到工程上就是一條樣本：一個輸入、一個期望行為、一個判定標準。把任務拆成斷言的過程，本質是在逼問自己——這件事到底有沒有明確的對錯。能拆出來，說明業務邏輯是收斂的；拆不出來，往往不是技術問題，而是需求本身還停在含糊地帶。這一道閘門攔掉的，常常是那些「聽起來很值得做、但誰也說不清做成什麼樣算成功」的專案。

樣本量不必嚇人。一個常見的誤區是覺得評估集要上千條才有意義，於是遲遲不敢動手。實際上，Anthropic 在其 2024 年發布的 Agent 評估實踐中給出的起點是 30 到 50 條高價值樣本即可啟動；另有面向 Agent 開發的工程指引(2024 年)也提到，從 20 到 50 個真實失敗案例出發就能跑起有效評估，不必等攢夠幾百個任務。背後的道理很直接：早期 Agent 每改一次系統，行為差異往往是肉眼可見的量級，這種粗顆粒的變化，小樣本就足以分辨。等到後期需要區分 92% 和 93% 的細微差距時，再擴充樣本量也不遲。換句話說，樣本規模應該跟著你要回答的問題精度走，而不是一上來就追求統計學上的好看。

真正決定樣本品質的，是覆蓋面而非數量。一組只有正常路徑的樣本，等於在演示「一切順利時它能跑」,這對判斷可行性幾乎沒有價值。值得攢的樣本必須橫跨幾類截然不同的路徑：

正常路徑:輸入規範、流程通暢，任務該怎麼完成就怎麼完成。這是基線，但只是基線。
邊界路徑:資訊不全、參數缺失、上下文模糊。Agent 是會追問、會合理兜底，還是會硬著頭皮編一個答案出來。
故障路徑:依賴的工具呼叫失敗、介面超時、返回了非預期結構。這一類直接檢驗它在不確定環境下的魯棒性。
風險路徑:涉及不可逆操作、敏感動作或高代價決策的場景。它該停下來請示，還是會自作主張地往前衝。

這套四類劃分，和業界一些更細的分法是一脈相承的。有評估方法(2024 年)進一步把任務拆成正常完成、資訊缺失、工具失敗、高風險動作、干擾噪音五類，建議初期構建 50 到 100 個任務。粒度不同，核心一致——你要主動去構造那些「不順利」的情形，因為 Agent 的真實價值恰恰體現在它如何處理意外，而不是它在理想條件下的表現。

這裡藏著一個比「湊不齊樣本」更值得警惕的訊號。當你試圖為某一類路徑構造樣本，卻發現根本寫不出來——比如說不清楚「資訊缺失時正確的行為是什麼」,或者無法定義「哪些算高風險動作」——這通常不是樣本難找，而是業務規則壓根沒想透。這種情況下，缺的不是資料，是對問題本身的理解。強行上馬，只會把模糊的需求外包給一個無法被檢驗的系統，最後誰也說不清它到底有沒有做對。

所以這一節的判斷很乾脆：湊不齊樣本，比模型不夠強更應該叫停。模型能力會隨時間提升，介面會升級，成本會下降，這些都是可以等的變數。但如果一個任務無法被斷言、無法被構造成可檢驗的樣本，那它在工程意義上就是個黑箱——你既無法判斷它現在能不能做，也無法在做了之後知道它做得對不對。立項前花一兩天時間，認真攢 30 到 50 條覆蓋四類路徑的樣本，本身就是最便宜的一次可行性測試。攢得出來，後面的訊號才值得繼續往下看；攢不出來，省下的可能是幾個月的返工。

訊號二：流程穩定性——success_rate 之外的中間層

很多專案立項時只盯著一個數：任務最終做對了多少。這個數高，團隊就覺得穩；低，就覺得不能上。問題是，這個數把整條執行鏈路壓成了一個二元結果，所有發生在中間的事故都被它吞掉了。一個 Agent 可以在規劃階段把步驟排錯順序、卻因為後續步驟恰好糾正回來而蒙對最終答案；也可以在呼叫工具時傳了不合 schema 的參數、靠重試三次才僥倖通過；還可以把檢索到的證據截斷了一半，最後輸出卻碰巧落在正確區間。這些情況下最終成功率看著沒問題，但你部署到生產、換一批輸入分佈，它們立刻原形畢露。

所以判斷一個 Agent 任務值不值得做，第二個訊號是：你能不能看見它「怎麼完成的」，而不只是「完成了沒有」。如果現在的評估只能產出一個總成功率，那這個專案的真實穩定性對你是黑箱，立項時給出的任何穩定性承諾都是猜的。

要把黑箱開啟，得把觀測拆成四個獨立的層，每一層回答一個不同的問題，並且必須同時看，不能只挑順眼的那層：

任務層——最終結果對不對。這是大家熟悉的那個成功率，是結論，不是過程。
證據層——結論站不站得住。Agent 給出的答案背後有沒有對應的檢索引用，證據是否被完整保留。一個沒有證據支撐的「正確答案」，在合規和可追溯場景裡等於沒答。
執行層——工具有沒有被正確驅動。工具呼叫的成功率、schema 校驗的失敗率，直接反映 Agent 和外部系統的介面是否穩。這一層崩了，任務層的成功往往是靠重試堆出來的，不可複製。
風險層——有沒有踩線。越權操作被攔截的比例、預算/配額超限的比例。這一層是底線，哪怕前三層都漂亮，這層有漏，系統就不能面向真實使用者。

這四層的價值在於互相印證。任務層告訴你結果，另外三層告訴你結果是不是可信、可複製、可控。只看任務層，等於只驗收了一棟樓的外立面，牆裡的鋼筋有沒有偷工你一無所知。我見過不少團隊在 demo 階段任務層很漂亮，一進灰度執行層的 schema 失敗率就飆起來，原因是測試集裡工具返回格式太規整，真實環境一變就崩——這種問題，單看成功率永遠暴露不了。

四層框架解決了「看見故障」的問題，但還有一個更隱蔽的維度：效率。兩個 Agent 都能把任務做對，一個走五步，一個走二十步外加七次重複呼叫，從任務層看它們一模一樣，工程意義上卻是天壤之別。步數多意味著延遲高、token 成本高、出錯面更大，長期跑下來穩定性必然更差。所以過程指標要單獨拎出來觀測——平均步數、無效呼叫率（調了但對任務沒貢獻的那些）、重複呼叫率（同一個工具用幾乎相同的參數反覆打）。這幾個數能幫你區分「勉強做對」和「乾淨利落地做對」，前者上線就是定時炸彈。

效率之外，工具呼叫本身的品質也得拆開看，因為「呼叫失敗」和「呼叫成功但用錯了」是兩類完全不同的問題，混在一個成功率裡就廢了。具體拆成四個維度：

選擇正確——該用哪個工具就用哪個，沒有拿查詢介面去做寫操作這類錯配。
參數正確——傳進去的欄位、型別、取值合規，不靠下游容錯兜底。
時機正確——在該呼叫的步驟呼叫，沒有過早（資訊還沒齊）或過晚（已經能答了還在查）。
結果理解正確——拿到工具返回後能正確解析，不會把報錯當資料、把空結果當有效內容繼續往下走。

這四個維度裡，時機和結果理解最容易被忽略，也最容易在生產裡出事。參數錯了通常會立刻報錯、有跡可循；但時機錯了、結果理解錯了，Agent 往往不會報錯，它會帶著錯誤的前提一路往下走，直到最終輸出才暴露，而那時你已經很難定位是哪一步出的問題。所以這兩個維度值得單獨統計，不要並進籠統的工具成功率裡。另外，對那些高風險工具——能改資料、能花錢、能對外發請求的——它們的違規呼叫次數必須單獨計數，而不是和普通呼叫混在一起算比例。一個普通查詢工具偶爾調錯無傷大雅，一個支付或刪除工具調錯一次就是事故，二者的容忍度不在一個量級，評估口徑也不該一樣。

把這些放在一起，訊號二的判斷標準就清楚了：如果你現在只能拿到一個最終成功率，那這個專案的流程穩定性是不可知的，立項時應該把「建立四層觀測 + 過程指標 + 工具呼叫分維度統計」列為前置工作，而不是上線後再補。能把這套觀測建起來，你才有資格說這個 Agent 流程「穩」；建不起來，所謂的穩定就只是一句沒有資料支撐的樂觀判斷。

訊號三：確定性邊界——pass^k 決定它能不能面向使用者

很多團隊在驗證 Agent 時只看一個數字：跑一遍，成了沒有。成了就覺得「這事能做」，於是排期、立項、對外承諾。問題是，給單次結果背書，和給「每次都對」背書，是兩件完全不同的工程承諾。前者只需要運氣配合一次，後者要求系統在連續呼叫裡都不掉鏈子。把這兩件事混為一談，是 Agent 專案上線後口碑崩盤的常見起點。

區分它們，業內用兩個指標：一個回答「在 k 次嘗試裡至少成功一次」，另一個回答「連續 k 次每一次都成功」。前者衡量能力上限，對探索類、可重試的任務有意義；後者衡量交付下限，決定一個 Agent 能不能直接面對真實使用者。決策的關鍵在於：你的業務吃的是哪一個。如果終端使用者每次互動都期待正確結果，那就只有後者算數，前者再漂亮也是自欺。

這裡有個反直覺的算術，值得每個決策者算一遍。假設單次任務的成功率是 75%——聽起來已經相當不錯，四次裡只錯一次。但如果一個完整業務流程需要連續三步都成功，按獨立事件估算，整條鏈路走通的機率是 0.75 的三次方，大約只剩四成出頭。也就是說，單看一步你覺得「基本靠譜」，串起來使用者實際拿到正確結果的機率，還不到一半。這個塌陷不是線性的，而是隨步數指數級惡化。鏈路越長、串聯節點越多，單點的小瑕疵被放大得越狠。

把這個規律倒過來看更有用：當你發現一個面向使用者的 Agent 上線後投訴率高得離譜，但單步抽查又「看起來還行」，多半不是某個環節壞了，而是你從一開始就用單次成功率給多步鏈路做了背書。指數衰減不會因為每一步都「差不多」就放過你，它只會把每一步的「差不多」乘起來，變成使用者眼裡的「經常出錯」。

更要命的是基礎能力本身的天花板。行業評測普遍顯示，在足夠複雜的真實場景裡，即便是當前最強的模型，單次任務成功率也可能低到只有三成左右。把 30% 代入上面的連乘邏輯：兩步串聯剩不到一成，三步幾乎歸零。這意味著，在強一致性、面向使用者、不容許出錯的場景裡，一個基礎成功率只有三成的方案根本不是「再最佳化最佳化就能上」，而是結構上就不具備交付資格。再多的提示詞調優也救不回數量級的差距。

那是不是說成功率不夠高就一律槍斃？也不是。這條邊界的鬆緊，取決於業務能不能容忍兜底。我的判斷框架是這樣分的：

可以人工兜底的場景：Agent 輸出先進人工審核或人工修正環節，錯了有人接得住。這類場景對「每次都對」的要求可以放寬，單次成功率達到能顯著降低人力的水平就值得做，重點變成衡量節省了多少人工，而不是追求零錯誤。
可以非同步重試的場景：任務不要求即時返回，失敗了能自動重跑或換路徑再試。這時候真正該看的是「幾次嘗試內至少成一次」的機率，而不是單次的確定性，重試本身就是把成功率往上抬的工程手段。
既不能兜底也不能重試的場景：使用者即時拿到結果、結果直接生效、錯了就是事故。支付、合規判定、對外自動回覆都屬於這類。這條線必須在立項文件裡標紅——它要求的是連續成功的確定性下限，而不是某次跑通的能力上限。

所以這一節給決策者的動作很具體：先確認你要做的 Agent 落在哪一類，再決定用哪個口徑去驗收。把任務拆成它實際要走的步數，對每一步估一個保守的成功率，連乘一遍，看看鏈路末端剩下多少。如果這個數字撐不起業務對一致性的要求，而場景又恰好不能兜底、不能重試，那麼無論單步演示多驚豔，結論都應該是緩做或不做。這不是悲觀，是把上線後必然暴露的成本提前算清楚——立項階段多算這一次乘法，省下的是事故復盤時一整個團隊的時間。

訊號四：ROI 邊界——能力天花板與評估飽和陷阱

立項會上最容易被採信的，是一條向上的曲線。有人會拿出公開基準的進步速度說事：在 SWE-bench Verified 這類編碼評估上，前沿模型一年之內把得分從四成左右推到了八成。這個斜率確實陡，足以讓會議室裡的人相信「再等半年就能落地」。但把這條曲線直接當成自己專案的 ROI 預期，是我見過最常見的誤判。

問題出在分數和能力之間並不是線性對應。當一個基準接近飽和，留在榜單上沒被解決的那批任務，恰恰是難度最高、最反直覺、最依賴長鏈推理的部分。模型能力即便有實打實的躍升，反映到分數上也只是幾個百分點的挪動。換句話說，越接近天花板，每一分的含金量越高、獲取成本越陡，而你從曲線斜率推算出來的「進步速度」卻在系統性地高估後續收益。決策者看到的是平滑外推，工程上對應的卻是邊際收益急劇遞減的那一段。把演示階段的樂觀斜率當作落地後的增長假設，ROI 模型從第一步就偏了。

更隱蔽的失真，發生在你只盯著一個指標的時候。我手上有一個企業知識庫 Agent 的真實例子，能說明單指標視角會怎樣騙人。團隊改了一版 Prompt，在離線 20 條樣本上跑下來，任務成功率從 71% 抬到了 83%。單看這一個數，提升十二個點，立項材料裡寫「顯著最佳化」毫無壓力。

但把同一批樣本的其他維度攤開看，畫面完全變了：

引用準確率（citation_rate）從 88% 塌到 61%——成功率漲上去的代價，是模型開始編造或張冠李戴引用來源，而這在知識庫場景裡幾乎是致命缺陷；
平均工具呼叫次數從 2.1 次漲到 3.8 次——成功更多是靠「多試幾次」堆出來的，每一次呼叫都是真金白銀的 token 和介面成本；
p95 延遲直接翻倍——頭部使用者體驗到的等待時間翻了一番，在互動式場景裡這往往就是流失的分水嶺。

這就是關鍵：成功率這一個數字孤立地看是漲的，綜合算下來收益可能是負的。多出來的兩次工具呼叫乘以日活和單次成本，是一筆持續支出；翻倍的延遲意味著要麼擴容、要麼犧牲體驗；而引用準確率的崩塌，會把人工複核的工作量重新加回來——你以為 Agent 替人省下的那部分活，又因為不可信的引用被退回到人工核對的環節。這三項疊加，很可能把那十二個點的成功率紅利全部吃掉，甚至倒貼。

所以 ROI 判斷不能錨在任何單一指標的樂觀讀數上，要錨在兩件事上。第一是能力天花板：這類任務在公開基準上是處於陡升段還是已經接近飽和？如果你的核心場景對標的恰好是榜單上那批最難任務，那就別指望短期內靠模型迭代白撿收益，該投入的工程兜底一分都省不掉。第二是綜合成本賬：把延遲、呼叫次數、token 開銷、以及最容易被忽略的人工複核成本，全部折算進同一張表，再去和成功率的提升做淨額對沖。一個只在某個指標上變好、卻在其餘維度集體劣化的方案，工程上不叫最佳化，叫成本轉移——你只是把代價從一個看得見的地方挪到了幾個看不見的地方。

給決策者的可操作判斷是：要求任何「成功率提升」的結論，都必須附帶同一批樣本上的引用準確率、呼叫次數和 p95 延遲三項配套資料；缺其中任何一項，這個 ROI 結論就不成立，不能作為 Go 的依據。演示階段挑一個好看的數字很容易，能把整張成本表攤開還為正的，才值得往下走。

訊號五：風險可治理性——沒有 Guardrail 不要上

前四個訊號回答的是「做不做得出來」，這一節回答另一個問題：做出來之後，它失控時你攔不攔得住。一個 Agent 一旦能調工具、能寫資料，它的每次決策就不再只是文本生成，而是帶副作用的動作。判斷一個專案值不值得上線，最現實的標準不是它平均表現多好，而是它出錯時的代價你能不能兜住。如果答案是「不能」，那這個專案的優先順序應該往後排，先把治理層補齊再談上線。

我習慣把治理拆成三層來看：能不能擋住、能不能恢復、能不能看見。三層缺一層，風險就不可控。

第一層：動作發生前能不能擋住

最小可用的線上防護，落到實處其實就是幾道硬卡點，每一道都對應一類已經踩過的坑。模型輸出的結構體如果通不過 schema 校驗，就不該進入下游執行，直接阻斷比「盡力解析」安全得多——下游拿到半個欄位的 JSON，往往比直接報錯更難排查。任何寫操作都要先過一遍策略校驗，把「能不能寫、寫到哪、誰授權」從模型的自由發揮裡拿出來，交給確定性的規則。單次任務的 token 或工具呼叫一旦逼近預算上限，立刻降級而不是硬扛，否則一個陷入循環的 run 能把成本和延遲同時拉爆。還有一類容易被忽略的：當模型在沒有檢索到任何證據的情況下仍然給出結論，這種回答要被打上高風險標記，而不是和正常回答混在一起返回給使用者。

這些卡點的共同點是，它們都不依賴模型自己「想清楚」，而是把判斷權收回到工程側。這正是 Guardrail 的意義：模型可以犯錯，但犯錯的邊界由你畫。

第二層：出錯之後能不能恢復

擋住只是第一步，更能區分專案成熟度的是錯誤恢復能力。這裡我不建議用一個籠統的「恢復成功率」來衡量，因為不同錯誤型別的正確恢復姿勢完全不同，混在一起算反而看不出問題。

缺參數：正確的反應是停下來向用戶追問，而不是拿預設值蒙一個。能不能識別「資訊不足」並主動發問，是一個很硬的能力分水嶺。
工具超時：要做的是有限次重試加退避，而不是無腦重試到把對方服務打掛，也不是一次失敗就直接放棄。
權限不足：唯一正確的反應是停止並上報，絕不能讓 Agent 學會「繞過權限」。一個會想辦法繞權限的 Agent，比一個會報錯的 Agent 危險得多。

按錯誤型別分別統計恢復行為，你才能看清模型是真的會處理異常，還是只是在順境裡表現良好。

第三層：線上能不能看見

前兩層做得再好，看不見也等於沒有治理。關鍵的 run 要全量保留 trace——不是抽樣，是全量，因為出問題的往往恰好是你沒采樣到的那一條。在指標層，僅靠任務完成率遠遠不夠，它只告訴你「成了多少」，不告訴你「怎麼成的、差點出了什麼事」。

一套能真正支撐判斷的線上監控，大致需要十來個維度協同：工具呼叫次數、任務完成率、平均執行步數、使用者追問率、工具失敗率、超時率、重複呼叫率，這幾項刻畫「跑得順不順」；而高風險動作確認率、使用者取消率、人工接管率、使用者差評率、安全攔截次數，這幾項才真正刻畫「風險大不大」。後半組裡，人工接管率和安全攔截次數尤其值得盯——前者反映系統在多少比例的情況下還得靠人兜底，後者反映防護層到底有沒有在幹活。如果這些指標在你現有的可觀測體系裡根本採不上來，那風險可治理性這一項就應該判定為不達標。

把這三層連起來看，結論很直接：能擋、能恢復、能看見，三者齊備，專案才具備上線條件；缺任何一層，這個 Agent 就還不該面向真實使用者和真實資料。Guardrail 不是上線後再補的最佳化項，而是決定「能不能上」的前置條件。

訊號六：評估可補建——它不是立項的阻塞項，而是 Go/No-Go 的最後一勾

前面五個訊號談的都是「這件事本身能不能做」，到了第六個訊號，關注點轉向「我們有沒有能力知道自己做得對不對」。很多團隊卡在這裡：現成的評估體系一個都沒有，於是判斷陷入停滯，要麼因為「測不了」而否決一個本該上馬的專案，要麼因為「先跑起來再說」而上線一個無法回看的黑箱。這兩種都是誤判。評估體系的價值毋庸置疑，但它的建設時機和立項決策是兩件事。

真實工程裡的常見路徑，是先有產品、有了真實流量之後，再回頭把評估補齊。已經積累了相當規模使用者的 agent 團隊，在產品跑起來之後才系統性地搭建評估，把靜態分析打分、瀏覽器端的真實任務測試、模型充當裁判這三層組合起來，整個過程花的是數月而非數年。另一類做法是讓評估隨產品一起長大：早期靠人工逐條打分，等到積累了足夠的判斷樣本，再把人的判斷蒸餾成 LLM 評分器，圍繞「不破壞原有內容、確實完成了指令、產出品質過關」這幾個維度建立打分邏輯，並保留定期人工校準的環節，最終演進成兩套互相獨立的套件——一套盯品質基線，一套防迴歸。這兩條路徑說明同一件事：評估能補，而且補建的成本是可控的、可預期的。所以在立項階段，它不該是一票否決的硬門檻，而應該是上線前必須勾完的最後一項。

反過來，更值得警惕的不是「沒有評估」，而是「評估本身有缺陷」。一個設計粗糙的評估，會系統性地低估你的 agent，進而讓你親手砍掉一個其實跑得很好的專案。在某個程式碼與科研類基準上，一個能力很強的模型最初只拿到四成出頭的分數，看上去差得離譜；後來研究者逐條排查才發現，問題出在評估側：評分器把數值近似當成了錯誤（一個理應判對的答案因為小數尾數被算成錯），任務描述本身含糊，還有部分隨機任務根本無法穩定復現。把這些坑填平、換用更合理的判定口徑之後，同一個模型的分數直接逼近滿分。差距不在 agent，而在尺子。

另一個例子更微妙。在一個航班預訂類的對話基準裡，agent 鑽研了規則、為使用者找到了一個比標準答案更划算的方案，結果因為這個方案不在評估腳本預先寫死的「正確路徑」裡，被判定為失敗。它做得比評估期望的更好，卻因此扣了分。這類錯誤的可怕之處在於，它懲罰的恰恰是真正有創造力、有能力的 agent——如果你只看分數，就會得出「這條路走不通」的結論，然後轉身投入一個看起來分數漂亮、實則平庸的方案。

所以第六個訊號的真正含義是：評估必須建，但更要建對。把前面六個訊號收斂下來，立項時不必要求評估體系到位，上線前卻必須滿足一份發布清單——至少三十條帶明確斷言的離線樣本，讓「對不對」有客觀依據；指標按資料、單步、流程、業務四個層次拆開，避免用一個籠統的成功率掩蓋真正的故障層；關鍵失敗樣本支援原樣回放，否則你修了 bug 也無從驗證；所有高風險的寫操作必須接入線上 Guardrail，把不可逆的動作擋在閘門之後；每次版本變更都留下前後對比結果，讓每一次改動都能說清楚是變好了還是變壞了。六個訊號全部過關，並不保證專案成功，但任何一個長期亮紅燈，都值得你在投入之前停下來重新算賬。

這六個訊號有優先順序嗎？哪個不過關就該直接否決？

有先後，但不是簡單排序。前三個訊號——資料與樣本能不能拿到、流程穩不穩、確定性邊界夠不夠——屬於「地基級」，任何一個長期不達標，專案基本不成立，應當直接否決或推遲。後三個是「可治理級」：ROI 邊界幫你判斷值不值得做，風險可治理性決定能不能面向真實使用者，評估可補建則是上線前的最後一道勾。地基級不過關是硬否決，可治理級不過關往往是「先解決再上」，而不是「放棄」。

成功率只有 30% 是不是意味著企業 Agent 現在都不值得做？

不是。單看一個籠統的成功率得出否決結論，恰恰是這套框架要避免的錯誤。三成的端到端成功率，可能意味著流程裡某一個具體環節在拖後腿，把指標按四層拆開之後，你常常會發現資料層和單步層都不差，問題集中在流程銜接或某類邊界輸入上——這些是可修的。更何況，正如前面那兩個評估缺陷的例子，低分本身也可能是尺子的問題。先定位失敗發生在哪一層，再決定值不值得做，比盯著一個總分拍板要可靠得多。

立項階段還沒有評估體系，是不是就不能做判斷？

恰恰相反。評估體系是可以在產品成熟階段補建的工程資產，數月即可成型，不該成為立項的前置條件。立項階段你真正需要確認的，是「任務能不能被斷言」——也就是結果有沒有客觀的對錯標準、樣本能不能拿到。只要這一點成立，評估就是早晚能補上的；如果連這一點都不成立，那才是真正該停下來的訊號，而且補建評估也救不了。

如何避免被漂亮的 demo 或評測分數誤導？

對 demo，看的是它能不能穩定重放——同一個場景跑十次有幾次成功，而不是剪輯過的一次成功。對評測分數，先去讀評分邏輯本身：它是怎麼判對錯的，有沒有把數值近似算成錯誤，任務描述是否含糊，更優的非標準解會不會被誤殺。一個能力很強的 agent 被低分埋沒的情況是真實存在的。把「分數」和「分數怎麼來的」分開看，再疊加前後對比和失敗回放，你才不會被一個單一數字牽著走。