20個企業級案例揭示Agent落地真相：閉源模型吃掉85%，手搓代碼替代LangChain

加州大學伯克利分校（UC Berkeley）剛剛發布了一份重磅論文：《Measuring Agents in Production》。

論文地址：https://arxiv.org/pdf/2512.04123

這份論文，基于來自全球的真實請求：306名從業者深度調研，20個企業級部署案例，覆蓋 26 個行業。

這是AI Agent 領域，迄今最大規模的實證研究。

最核心的三個信息：

生產力提升是Agent 落地的第一推動力；

閉源模型、人工Prompt 和受控流程是當前的“通行公式”；

可靠性是最大的攔路虎，人工審核依然不可或缺；

這份報告信息非常多，容我慢慢道來。

73%為生產力買單，金融成Agent 第一戰場

先說一個數字：

73%的從業者表示，部署Agent的首要目的是“提高生產力”。

其他的動機也非常務實：63.6%是為了減少人工工時，50% 是為了自動化常規勞動。

形成對比的是，那些難以量化的質性收益，如“風險規避”(12.1%)和“加速故障響應”(18.2%)，排名則相對靠后。

也就是說，Agent 的落地，優先于那些能帶來直接、可量化回報的場景，那些價值難以估量的質性改進，目前還得往后稍稍。

從應用場景看，Agent早已走出寫代碼或聊天機器人，深入到了更嚴肅的商業流程中。

其中，金融與銀行業是第一大戰場，占比39.1% 其次是科技（24.6%）和企業服務（23.2%） 。

除了這些，Agent 還在很多意想不到的地方落地：

保險理賠流程自動化：代理人負責處理從保單查詢到風險識別的序列排序流程。

生物醫學工作流自動化：在科學發現領域，Agent 用于自動化執行復雜的實驗和數據分析流程。

企業內部運營支持：涵蓋人力資源信息搜索、站點故障事件診斷等多個方面。

這些跨行業的成功案例證明，AI Agent已經具備解決真實世界復雜問題的能力，并正在創造切實的商業價值。

在實際業務場景里，Agent 目前的角色，更像是人類的“超級實習生”。

92.5%的Agent 直接服務于人類用戶，其中52.2%是服務于企業內部員工 。

為什么大部分是內部員工在用？因為在組織內部，錯誤后果可控，而且隨時有人盯著。只有7.5%的Agent 是服務于其他軟件系統的，Agent 之間的全自動交互還很遙遠。

與很多想象的不一樣，Agent的響應速度并不是客戶最先考慮的問題。在生產環境中，66%的系統允許分鐘級甚至更長的響應時間。

原因很簡單：相比于人類完成任務需要的數小時或數天，Agent 花幾分鐘仍然是巨大的效率提升。這意味著，開發團隊可以將重心放在提升輸出的質量和可靠性上，而不是犧牲能力去追求極限的低延遲。

生產級Agent 的“極簡主義”：拒絕微調，死磕 Prompt

與學術界對復雜自主Agent的探索形成對比，生產級AI Agent的構建哲學是“大道至簡”。

從業者優先選擇簡單、可控、可維護的技術路徑，以最大程度地系統的可靠性。這種務實的工程選擇貫穿于模型選型、技術實現、核心架構和框架使用的方方面面。

在模型選擇上，閉源是絕對主流。

在20個深度案例中，85%（17個）使用了閉源模型 Anthropic 的 Claude 系列和 OpenAI 的 GPT 系列是首選。

選擇閉源的核心邏輯是效率。對于輔助專家（如醫生、高級工程師）的Agent來說，推理成本相比人力成本幾乎可以忽略不計，因此團隊傾向于選擇最強的模型。

開源模型更多被認為是特定場景下的補充。只要在滿足嚴格約束條件時，團隊才會選擇開源模型，一般來說兩種情況比較常見：

成本效益：對于需要大規模、高推理的場景，自托管開源模型的成本優勢凸顯。

數據隱私：受法規或企業政策限制，當敏感數據無法突破外接環境時，開源模型成為唯一選擇。

與模型選擇一樣，從業者在技術路徑上也傾向于更簡單、迭代更快的方法：拒絕微調，死磕Prompt。

學術界熱衷的微調（Fine-tuning）和強化學習（RL），在實際應用場景里極少使用。其中70%的案例直接使用現成模型，完全不進行權重微調。

大家的精力都花哪了？花在寫Prompt 上。

78%的系統采用全手動或手動+AI 輔助的方式構建 Prompt 生產環境的。Prompt 可能會非常長，12%的Prompt超過了10,000個Token。

這也說明，從業者更相信自己手寫的規則，而不是自動優化工具（如DSPy）。

為了降低Agent的不可控性，生產級Agent的自主性被嚴格限制在可控范圍內。

68%的系統在需要人工干預前，執行步驟不超過10步，甚至有47%的系統少于5步。

為什么要限制？主要有三個原因：

保證可靠性：步數越多，錯誤越容易累積；

控制成本：API 調用不是免費的；

控制延遲：每多一步，用戶就得多等一會；

所以，80%的案例采用了預定義的靜態工作流 比如一個保險Agent，它的流程是固定的：查詢保障 -> 審查必要性 -> 識別風險。 Agent只能在已有的流程里做決定，不能自己發明新的步驟。

另一個比較有意思的現象是，在問卷調查里，60%的人說愿意用第三方框架（LangChain 等），但在實際案例里，85%的團隊選擇完全自研，直接調模型API。

為什么？為了減少依賴臃腫（dependency bloat），為了獲得對系統的完全控制權。

這種對定制化解決方案的強烈偏好揭示了企業級Agent系統的一個關鍵成熟度指標：從通用框架向深度集成、定制定制的編排引擎演進，使得這些系統正成為關鍵任務基礎，需要現有工具無法提供的控制水平。

學術榜單“失靈”，75% 的團隊放棄基準測試

基準測試幾乎沒有任何參考價值。

其中，75%的團隊完全不使用基準測試。因為每個企業的業務都太特殊了，公開的學術榜單毫無參考價值。

剩下25%的團隊，選擇從零開始構建自己的自定義基準。

在這種情況下，人工循環驗證（Human-in-the-loop）是主導的評估方法，被74.2%的從業者采用。

在開發階段，領域專家直接審查和驗證系統輸出的正確性、安全性和可靠性。比如，醫療專家逐一驗證醫療保健代理生成的診斷建議，是否符合臨床標準。

在運行階段，人類作為最終決策者，基于Agent提供的建議和分析采取的行動，充當最后一個安全護欄。比如，站點修復工程師根據代理生成的故障分析報告，最終決定執行哪些修復操作。

還有另一種評估方法：自動化評估（LLM-as-a-Judge）。其典型工作流程如下：

1. Agent生成一個輸出。

2.一個“裁判”LLM對輸出進行評估，并給出一個置信度分數。

3.高分輸出被自動接受，低分輸出則被路由給人類專家進行審查。

4.同時，專家會定期進行饑餓檢查那些被自動接受的高分輸出，以監控“裁判”LLM的表現，形成一個人類持續布局的閉環反饋。

雖然這種方法也有很多人在用，但沒人敢完全信任它。

51.6%的團隊使用了LLM 當裁判，但所有這些團隊都結合了人工驗證。一個典型的做法是：LLM 給個分，高分的自動通過，低分的轉人工；同時人工還會定期抽查高分樣本。

/ 04 /

核心挑戰：可靠性，可靠性，還是可靠性

可靠性是頭號大敵37.9% 的人把“核心技術問題”（可靠性、魯棒性）列為頭號挑戰，遠超合規性（17.2%）和治理問題（3.4%）。

為什么這么難？

基準難建：數據稀缺、成本高昂、高度定制化；

測試難做：Agent 的非確定性讓傳統的單元測試失效了；

反饋太慢：很多時候，你不知道Agent 錯了，結果直到幾個月后才出現；

與可靠性相比，安全與合規性問題被認為是次要問題。原因是，它們通常可以通過“約束設計”解決。常見的“約束設計”有以下四種：

1.復雜修改操作：嚴格限制Agent只能讀取數據，界面允許其生產環境的狀態。例如，一個站點可靠性（SRE）Agent可以分析日志并生成報告，但最終的修復操作必須由人類工程師執行。

2.沙盒環境：將Agent部署在與生產系統隔離的沙盒環境中。Agent在沙盒內生成并測試代碼或配置變更，只有在通過所有驗證后，結果才會被同步到生產系統。

3.限制抽象層：在Agent和生產工具之間構建一個API封裝層。這個抽象層只公開必要的功能，并隱藏了內部實現的細節，了Agent的潛在破壞范圍。

4.控制：嘗試讓Agent繼承發起請求的用戶的訪問權限。然而，實踐表明這仍然是一個挑戰，因為Agent在調用工具時可能會繞過或遇到與用戶權限不一致的細粒度控制。

/ 04 /

總結：約束性部署的勝利

這份報告揭示了一個核心悖論：

可靠性明明是最大挑戰，為什么這些系統還能上線？

答案是：“約束性部署”（Constrained Deployment）。實現“約束性部署”的具體模式包括：

環境約束：將Agent部署于復雜模式、內部網絡或與生產隔離的沙盒環境中，從源頭上杜絕了Agent對關鍵系統的直接破壞風險。

自主性約束：將Agent的行為限定在少于10個步驟的構成、預定義工作流程內，避免了因長期自主探索而導致的不可預測行為和錯誤累積。

人工：監督將專家安置決策回路的關鍵節點，設置成為代理輸出的最終驗證者和執行者，構成了最后一個、也是人類最加固的一個安全防線。

另一個重要的啟示是，僅利用現有的前沿大模型和相對簡單的提示工程技術，就足以在超過26個不同行業中創造出可觀的、可量化的商業價值。

這意味著，企業不用等AGI，就能通過實際將現有技術確定明確的、提升范圍可控的業務問題，就能夠獲得顯著的生產力。

文/林白

PS：如果你對AI大模型領域有獨特的看法，歡迎掃碼加入我們的大模型交流群。