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

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

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

作者 | Utkarsh Kanwat 責(zé)編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

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

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

• “Agent 是 AI 的下一個風(fēng)口”

• “未來是屬于 Agent”

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

我不是唱反調(diào)的人，我是真干過的

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

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

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

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

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

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

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

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

• 上下文窗口帶來的 token 成本是二次增長的。對話越長，成本越高，規(guī)模化后開銷驚人。

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

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

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

AI Agent 流程中的錯誤累積

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

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

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

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

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

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

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

長對話意味著成本爆炸

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

整合現(xiàn)實考驗

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

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

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

那些吹噓“全自動 Agent 能無縫集成你整個技術(shù)棧”的公司，要么太樂觀，要么根本沒真正在大規(guī)模生產(chǎn)環(huán)境試過。現(xiàn)實中，集成現(xiàn)實場景往往是 AI Agent 的墳?zāi)埂?/strong>

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

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

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

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

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

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

我的 CI/CD Agent 有明確的成功標(biāo)準(zhǔn)和回滾機制。AI 負(fù)責(zé)分析代碼質(zhì)量、生成修復(fù)建議，但最后合并與否由流水線控制。

總結(jié)一句話：

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

我的預(yù)測

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

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

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

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

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

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

正確的構(gòu)建方式

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

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

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

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

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

• 打好基礎(chǔ)：AI 負(fù)責(zé)難點（理解意圖、內(nèi)容生成），關(guān)鍵環(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)拆解

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