大模型爆紅后，不少人都在高喊“AI Agent 才是未來”，連英偉達 CEO 黃仁勛也曾斷言，Agent 將催生萬億級新市場。然而在一線開發(fā)者眼中，現(xiàn)實遠沒那么樂觀。

近日，一位曾在開發(fā)、運維和數(shù)據(jù)運營等領域構建過 12 個以上生產(chǎn)級 AI Agent 系統(tǒng)的工程師發(fā)文，直言自己并不看好 2025 年這波 Agent 熱潮——他認為，當下關于“自主智能體”的設想在數(shù)學上根本走不通，真正能在生產(chǎn)環(huán)境中跑得穩(wěn)的 Agent，也完全不是現(xiàn)在市面上宣傳的那一套。

原文鏈接：https://utkarshkanwat.com/writing/betting-against-agents/

作者 | Utkarsh Kanwat 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

很多人說“2025 是 AI agent 元年”。各種新聞文章標題都這么寫：

• “AI agent 會徹底改變工作方式”

• “Agent 是 AI 的下一個風口”

• “未來是屬于 Agent”

而我卻剛剛花了一年時間搞清楚哪些 Agent 在生產(chǎn)環(huán)境里真的能用，也正因如此，我才不看好這股風。

我不是唱反調的人，我是真干過的

過去一年我做了十幾個上線的 Agent 系統(tǒng)，覆蓋整個軟件開發(fā)流程，比如：

• 開發(fā)類 Agent：自然語言生成 React 組件、重構老代碼、自動維護 API 文檔、根據(jù)說明生成函數(shù)。

• 數(shù)據(jù)和基礎設施類 Agent：自動執(zhí)行復雜 SQL、搞定數(shù)據(jù)庫遷移、用 AI 管基礎設施代碼（IaC）并支持多云。

• 質量和流程類 Agent：AI 驅動的 CI/CD 流水線，自動修復 lint、生成測試、做代碼審查、寫 PR 描述。

這些系統(tǒng)確實能用，確實創(chuàng)造了實際價值，每天都能幫人省下好幾個小時的手動操作。也正因為如此，我才認為外界把 2025 稱作 “AI Agent 元年” 的說法，忽略了很多關鍵現(xiàn)實。

要點速覽：關于 AI Agent 的三個殘酷現(xiàn)實

在構建了 12 套以上的生產(chǎn)級系統(tǒng)之后，我得出以下幾點結論：

• 多步驟流程中的錯誤率會呈指數(shù)級放大。即便每一步的成功率有 95%，到第 20 步時整體成功率也只剩 36%。而生產(chǎn)環(huán)境的要求是 99.9% 起步。

• 上下文窗口帶來的 token 成本是二次增長的。對話越長，成本越高，規(guī)?；箝_銷驚人。

• 最大的難題不是 AI 本身的能力，而是如何設計 Agent 真正能用的工具和反饋系統(tǒng)。

一個沒人愿意面對的數(shù)學現(xiàn)實

所有做 AI Agent 的公司都在回避一個難以接受的事實：在生產(chǎn)級別的多步驟任務中，錯誤的累積讓“全自動智能體”在數(shù)學上根本行不通。

AI Agent 流程中的錯誤累積

咱們算算賬。如果一個 Agent 流程中每一步的可靠率是 95%（這對現(xiàn)在的大模型來說已經(jīng)很樂觀了），那么整體成功率就是：

• 5 步流程，成功率約為 77%

• 10 步流程，成功率約為 59%

• 20 步流程，成功率僅剩 36%

而生產(chǎn)環(huán)境要求的可靠率通常要達到 99.9% 以上。即使你奇跡般地讓每步成功率達到 99%（目前沒人做到），20 步的整體成功率也只有 82%。這不是提示詞設計的問題，也不是模型能力的問題，而是數(shù)學上的現(xiàn)實。

我做的 DevOps Agent 能用，正是因為它根本不是一個 20 步的全自動流程。它被拆分成 3-5 個獨立的、可以單獨驗證的操作，有明確的回滾點和人工確認環(huán)節(jié)。Agent 負責生成復雜的基礎設施代碼，但整個系統(tǒng)架構都是基于可靠性這個數(shù)學限制來設計的。

我做過的每一個成功 Sgent 系統(tǒng)都有相同的規(guī)律：有邊界清晰的上下文、可驗證的操作步驟，以及關鍵節(jié)點上的人工決策點。一旦你試圖讓智能體自主串聯(lián)起超過幾個步驟的復雜操作，數(shù)學就會讓你吃癟。

長對話意味著成本爆炸

還有一個數(shù)學現(xiàn)實是很多 AI agent 支持者故意忽略的：上下文窗口會導致 token 成本呈二次方增長，這讓基于對話的 Agent 在經(jīng)濟上根本不劃算。

具體來說，做一個“會聊天”的 Agent 會遇到這樣的問題：

• 每次新交互都得處理之前所有的上下文

• token 消耗隨著對話長度成二次方增長

• 一場 100 輪的對話，僅 token 成本就可能高達 50 到 100 美元

• 用戶一多，成千上萬，這成本完全無法承受

我自己在做一個會話型數(shù)據(jù)庫 Agent 的原型時就深有體會。

剛開始幾次交互成本還低，但到了第 50 次請求時，每條回復花費已經(jīng)是幾美元，遠超它能帶來的價值。絕大多數(shù)場景下，這種經(jīng)濟模型根本行不通。

我做的函數(shù)生成 Agent 之所以成功，是因為它完全無狀態(tài)：輸入描述-輸出函數(shù)-過程結束。沒有需要維護的上下文，也不用追蹤對話，避免了成本的爆炸。它不是“和代碼聊天”的體驗，而是專注解決具體問題的工具。

實際上，生產(chǎn)環(huán)境中最成功的 Agent 往往根本不依賴對話。他們是聰明而有邊界的工具，專注做好一件事，然后干凈利落地退出，不拖泥帶水。

最大難題不是模型能力，而是工具設計

你就算搞定了上面兩個數(shù)學問題，還得面對一個現(xiàn)實：AI 想用好工具，必須有合適的接口和反饋系統(tǒng)。但現(xiàn)在很多團隊都嚴重低估了這個挑戰(zhàn)。

現(xiàn)在的工具調用其實已經(jīng)相當精準了，真正的難點在于工具設計。每個工具都必須經(jīng)過精心打磨，既能給出合適的反饋，又不能讓上下文窗口被信息淹沒。你需要考慮：

• Agent 怎么知道某個操作只是部分成功？怎么在不浪費大量 token 的情況下傳達復雜的狀態(tài)變化？

• 比如數(shù)據(jù)庫查詢可能返回 1 萬條數(shù)據(jù)，但 Agent 只需要知道“查詢成功，1 萬條結果，這里是前 5 條”，設計這種抽象是一門藝術。

• 當工具失敗時，Agent 需要哪些信息來恢復？信息太少它會卡住，太多又浪費上下文資源。

• 怎么處理相互影響的操作？比如數(shù)據(jù)庫事務、文件鎖、資源依賴關系。

我做的數(shù)據(jù)庫 Agent 能用，不是因為工具調用不出錯，而是因為我花了幾周時間設計了能和 AI 有效溝通的工具接口。每個工具都會返回結構化的反饋，Agent 能真正用來做決策，而不是單純拿到一堆原始的 API 響應。

那些號稱“接上 API，Agent 就能搞定一切”的公司根本沒做過這方面的工程工作。他們把工具當成人機交互界面設計，而不是針對 AI 設計。結果是，雖然 Agent 表面上能成功調用 API，卻無法真正完成復雜流程，因為它根本沒弄懂發(fā)生了什么。

每個生產(chǎn)環(huán)境中的 Agent 系統(tǒng)背后有個不為人知的真相：AI 可能只做了 30% 的工作，其余 70% 是工具工程——設計反饋接口、高效管理上下文、處理部分失敗，以及構建 AI 能理解和利用的恢復機制。

整合現(xiàn)實考驗

假設你已經(jīng)解決了可靠性和經(jīng)濟性問題，接下來還得面對一個更大的挑戰(zhàn)——和現(xiàn)實世界系統(tǒng)的集成，而現(xiàn)實往往很復雜糟糕。

企業(yè)系統(tǒng)并不是一套干凈利落的 API，等著 AI agent 去協(xié)調。它們大多是遺留系統(tǒng)，有各種怪癖、存在各種故障模式、隨時可能變動的認證流程、按時間變化的訪問頻率限制，還有一些合規(guī)要求，根本套不進簡單的提示模板里。

我的數(shù)據(jù)庫 Agent 不只是“自動執(zhí)行查詢”。它還得處理連接池管理、事務回滾、只讀副本、查詢超時，并且記錄所有操作以備審計。AI 負責生成查詢語句，其他一切都靠傳統(tǒng)系統(tǒng)編程。

那些吹噓“全自動 Agent 能無縫集成你整個技術?！钡墓荆刺珮酚^，要么根本沒真正在大規(guī)模生產(chǎn)環(huán)境試過。現(xiàn)實中，集成現(xiàn)實場景往往是 AI Agent 的墳墓。

什么才是真正可行的（以及原因）

做過十幾個覆蓋整個軟件開發(fā)生命周期的 Agent 系統(tǒng)后，我發(fā)現(xiàn)成功的項目都有共同特點：

我的 UI 生成 Agent 之所以能用，是因為每個界面都會有人審查后才上線。AI 負責將自然語言轉成可用的 React 組件，最終用戶體驗由人來把關。

我的數(shù)據(jù)庫 Agent 之所以可靠，是因為每次有破壞性的操作都會先確認。AI 負責把業(yè)務需求轉成 SQL，但數(shù)據(jù)完整性由人來保證。

我的函數(shù)生成 Agent 只在明確的邊界內(nèi)工作：給它一個規(guī)范，它輸出一個函數(shù)。沒有副作用，沒有狀態(tài)管理，也沒有復雜集成。

我的 DevOps 自動化 Agent 通過生成基礎設施即代碼（IaC）來工作，這些代碼可以審查、版本控制、回滾。AI 負責把需求轉成 Terraform 代碼，但部署流程有我們多年積累的安全機制。

我的 CI/CD Agent 有明確的成功標準和回滾機制。AI 負責分析代碼質量、生成修復建議，但最后合并與否由流水線控制。

總結一句話：

AI 負責處理復雜問題，人工負責掌控關鍵決策，傳統(tǒng)軟件工程保障系統(tǒng)穩(wěn)定可靠。

我的預測

以下是我對 2025 年哪些人將陷入困境的具體預測與判斷：

• 那些靠風險投資撐腰、打著“完全自主 Agent”旗號的初創(chuàng)公司，會最先碰到經(jīng)濟瓶頸。他們的 Demo 在五步以內(nèi)的流程還挺順，但客戶真正需要的是 20 步以上的復雜流程，這從數(shù)學上根本撐不住。為了解決這種不可能解決的可靠性問題，燒錢速度會飆升。

• 那些在已有企業(yè)軟件產(chǎn)品上硬塞“AI agent”的公司，用戶接受度會停滯不前。因為他們的 Agent 根本無法深入集成，處理不了真正的工作流程。

• 勝出者會是那些打造受限、面向特定領域的工具團隊，這些工具用 AI 處理難點，同時在人類控制或關鍵決策上保持嚴格邊界。換句話說，不是“全自動一切”，而是“能力超強且邊界清晰的助手”。

• 市場最終會學會區(qū)分“演示效果好”的 AI 和“真正穩(wěn)定可用”的 AI，而這個過程對許多公司來說代價會很高。

我并不是不看好 AI，而是對當前 Agent 架構的做法不看好。但我相信，未來會遠比現(xiàn)在的炒作更有價值。

正確的構建方式

如果你打算做 AI agent，先從這些原則開始：

• 明確界限：你的 Agent 到底能做什么，哪些部分交給人或確定性系統(tǒng)處理？

• 設計容錯：AI 出錯的情況可能占 20-40%，你怎么應對？有沒有回滾機制？

• 解決經(jīng)濟問題：每次交互花多少錢，隨著用戶增長成本怎么擴展？無狀態(tài)設計往往比有狀態(tài)劃算。

• 把可靠性放在自治前面：用戶更信賴穩(wěn)定好用的工具，而不是偶爾能搞出神操作的系統(tǒng)。

• 打好基礎：AI 負責難點（理解意圖、內(nèi)容生成），關鍵環(huán)節(jié)（執(zhí)行、錯誤處理、狀態(tài)管理）仍靠傳統(tǒng)軟件工程。

Agent 革命遲早會來，只是它絕不會像 2025 年的宣傳那樣光鮮炫目，正因為如此，它才更可能成功。

2025 全球產(chǎn)品經(jīng)理大會

8月15–16日·北京威斯汀酒店

互聯(lián)網(wǎng)大廠&AI 創(chuàng)業(yè)公司產(chǎn)品人齊聚

12 大專題，趨勢洞察 × 實戰(zhàn)拆解

掃碼領取大會 PPT，搶占 AI 產(chǎn)品新紅利