北京
【TechWeb】7月14日消息，根據 Gartner 2026年CIO與技術高管調研數據，截至目前僅有17%的組織部署了AI智能體，但超過60%的組織預計在未來兩年內完成部署。Agentic AI 目前正處于期望膨脹期的高峰。
但現實是，一邊是洶涌的預期，一邊是較低的落地率，這道橫亙在“Demo成功”與“生產可用”之間的鴻溝，究竟因何而生？又該如何跨越？
今年7月8日，在亞馬遜云科技中國峰會上，亞馬遜云科技正式發布《企業生產級智能體開發部署指南》（以下簡稱《指南》）。
這份《指南》用4個章節、從理論到實踐，回答了讓越來越多企業頭疼的問題：AI智能體在演示時一切順利，為什么一上生產就狀況百出？并最終幫助企業破解Agent從原型走向生產時的規模化部署難題。
智能體不是“另一種軟件”
為什么傳統軟件開發方法在智能體身上不管用？《指南》指出了三個根本原因。
第一，輸出不確定。 傳統軟件的邏輯很簡單：輸入A，輸出B，不對就是有bug。但大模型本質上是概率模型，同樣的問題今天問和明天問，答案可能不一樣。
第二，Prompt就是代碼，但沒有人管它。 開發團隊改一行代碼要走評審流程、留修改記錄、可以隨時回滾。但改一段Prompt呢？可能只是加了一句話，智能體的行為就徹底變了，開始拒絕某類請求、工具調用順序亂了、輸出格式變了。沒有任何工具能提前告訴你這次改動影響有多大。
第三，依賴的東西會自己變。 傳統軟件依賴的庫有明確的版本號，但大模型是云端服務，提供商會悄悄做安全微調、能力升級，不會發詳細的更新日志。結果就是企業端用戶的代碼一行沒動，但智能體的表現卻莫名其妙地變了。
這三件事合在一起，意味著傳統的測試、發布、監控體系全都不好使了。問題不在模型能力，而在于缺少一套工程化的手段來持續回答：它到底好不好？
《指南》的核心解法：讓評估成為一切的基礎
面對這個困境，指南給出的核心思路并不復雜：把“評估”放在整個開發生命周期的起點，而不是上線前才補的作業。
具體來說，就是六步形成一個閉環：先定義什么叫“好”、然后構建、接著評估、達標了才能上線、上線后持續監控、從生產中發現的問題再回流到評估集里。如此循環往復，每一次迭代都讓系統更可靠。
與傳統開發流程最本質的區別在于：傳統流程里，生產是終點；在這套體系里，生產是下一輪迭代的起點。每一個真實用戶觸發的失敗案例，都比會議室里預設的測試用例更有價值。
《指南》進一步把這套方法論提煉成了三條具體的工程實踐：
第一，先把評估跑起來。 很多團隊啟動智能體項目時，第一個問題是“這個智能體能做什么”。《指南》指出，正確的第一個問題是“我們要解決什么問題”。從問題出發，先圈定邊界，它該處理什么、不該處理什么。然后準備一套覆蓋常見情況和邊緣情況的基準數據集。有了這個基礎，每一次改動都可以用同一套標準去衡量效果。
第二，讓數據持續流入評估。 可觀測性經常被推遲到“功能先做出來再說”。但《指南》強調，從第一天就要接入追蹤手段，讓智能體的每一步，如調了什么模型、用了什么工具、傳了什么參數等等全都結構化地記錄下來。沒有這些數據，用戶只能知道“出錯了”，卻不知道“錯在哪一步”。
第三，讓系統架構可被評估。 這里有一條重要的設計原則：能用確定性代碼解決的事，就別讓大模型做。比如獲取當前日期、做數學計算、校驗數據格式，一行Python代碼就能搞定的事情，如果交給大模型去推理，既慢又貴還不穩定。正確的做法是讓智能體負責理解和編排，讓代碼負責執行和計算。
怎么知道智能體“好不好”？
智能體評估要評什么？《指南》給出了一個很務實的框架。
首先看粒度，從粗到細分三層：看最終回答對不對（黑盒）、看整個執行路徑對不對（玻璃盒）、看每一步對不對（白盒）。三層配合使用：粗的告訴用戶結果好不好，細的告訴用戶問題出在哪兒。
然后看證據強度，不是什么指標都同樣可信。能用代碼直接檢查的（比如輸出格式對不對、延遲多長、花了多少Token），是最高級別的證據；需要用另一個大模型來打分的，是次一級的證據，必須經過人工校準才能用；至于“有沒有創意”這類純主觀的判斷，干脆不評，強行打分只會制造虛假的精確。
在這個框架下，企業需要根據自己的業務場景挑重點。一個購物助手最該盯的是工具選得準不準、參數填得對不對；一個客服智能體最該盯的是意圖理解準不準、任務完沒完成；一個涉及多智能體協作的系統，還得額外關注協作效率。
亞馬遜內部怎么做的？
《指南》分享了三個亞馬遜內部的真實案例，分別對應三種不同的評估側重點。
Amazon購物助手面對的是成百上千個企業API，工具定義模糊會直接導致智能體選錯工具、答非所問。解法是先建立統一規范，再用自動化工具生成標準化的工具描述，最后用歷史日志持續回歸測試，核心指標就盯工具選擇的準確率。
Amazon客服智能體的第一道關卡是搞清楚用戶到底想干什么。一旦意圖識別錯了，后續所有環節都會跟著錯。解決思路是用歷史真實對話做基礎，再用大模型模擬各種虛擬用戶場景來擴大測試覆蓋面。核心盯意圖識別正確率和任務完成度。
Amazon賣家助手涉及多個智能體協同工作。多智能體系統最怕的是出現“涌現行為”——單個智能體都正常，但放在一起就產生了設計者沒預料到的失控。所以在自動化指標之外，必須有人工定期抽檢來兜底。
三個案例覆蓋了從簡單到復雜的演進路徑，也印證了一個觀點：評估體系不是一步建成的，而是隨著系統復雜度提升逐步深化的。
企業智能體的落地，瓶頸從來不在模型能不能做到，而在于有沒有一套體系能持續回答“它還能不能持續做到”。
正如亞馬遜全球副總裁、亞馬遜云科技亞太區聯席總裁儲瑞松在峰會上所說：底層技術平臺可以采購，但評估標準必須自己掌控。評估是什么標準，決定了智能體長什么樣。只有掌握了評估，才真正掌握了智能體生命周期的核心。
這份指南的價值，就在于把“評估”從一句口號變成了一套可操作的工程方法。對于正在考慮把智能體推向生產的企業來說，現在正是從評估入手、建立工程紀律的時候，從一個小而清晰的場景開始，把評估跑起來，再逐步擴展。
附：
《指南》配套動手實驗代碼已開源：
https://github.com/aws-samples/sample-eval-first-building-enterprise-agents-with-agentcore
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
