云計算一哥，給 Agentic AI 工程做“減法”

作者 | 李文朋、王一鵬、凌敏

2025 年的拉斯維加斯，亞馬遜云科技 re:Invent 現(xiàn)場依舊人潮洶涌——超過 6 萬名參會者線下到場，近 200 萬人在線收看主題演講。

但在這層喧囂之下，會場里明顯多了一種氛圍：大家比起興奮，更關(guān)注具備自主行動力的 Agent。

前兩年的大會主旋律還是“云 + 大模型”的宏大敘事，今年更聚焦在“Agent”，并且把焦點拉回到了三個具體的問題：算力和成本怎么算，基礎(chǔ)設(shè)施怎么重構(gòu)，以及最關(guān)鍵的——Agent 該怎么被快速開發(fā)出來并跑進生產(chǎn)環(huán)境。

在首日的主題演講中，亞馬遜云科技首席執(zhí)行官 Matt Garman 提出，未來每家公司、每一個可以想象的領(lǐng)域里，都將運行數(shù)十億個 Agent。這是一個足夠宏大的判斷。但對臺下負責(zé)預(yù)算和落地的技術(shù)管理者來說，眼前的問題要現(xiàn)實得多：

從一個在 PC 上跑得很順的 Demo，到一個能接住真實業(yè)務(wù)、經(jīng)得住高并發(fā)、算得清成本的生產(chǎn)級 Agent，中間還有多長的一段路？

在今年的主題演講上，亞馬遜云科技把這一現(xiàn)實問題提升到了“范式變革”的層面：正如二十年前亞馬遜云科技通過推動“云原生（Cloud Native）”改變了軟件開發(fā)方式，如今，它希望在“Agentic AI”上，完成一次類似級別的重構(gòu)。

演講中提到，光有“模型能力”已經(jīng)遠遠不夠，真正擋在企業(yè)面前的，是如何構(gòu)建可長期托付的“企業(yè)級 Agent”。對大多數(shù)團隊來說，從概念驗證（PoC）走向生產(chǎn)環(huán)境，往往會面臨著“編排能力、安全性、擴展性”三大隱形高墻。

為了解決這一問題，亞馬遜云科技的策略是從單純的“模型超市”轉(zhuǎn)型為提供完整的“Agentic AI 基礎(chǔ)設(shè)施”，旨在讓 Agent 的開發(fā)像搭積木一樣高效。

亞馬遜云科技 Agentic AI 副總裁 Swami Sivasubramanian 進一步拆解了這一路徑。他沒有只停留在發(fā)布幾個新功能，而是展示了一套全棧技術(shù)改造：例如開發(fā)者用的 SDK 和平臺級服務(wù)（如 Amazon Bedrock AgentCore）、模型定制與訓(xùn)練的路徑，包括由亞馬遜云科技自身驗證過的規(guī)范、策略和自動推理支撐的安全機制。

他的目標很明確：通過標準化的 Agent 架構(gòu)，將企業(yè)構(gòu)建智能體的周期，從“作坊式”的數(shù)月摸索，壓縮到工業(yè)化生產(chǎn)的“周”甚至“天”。

這也標志著亞馬遜云科技正在引領(lǐng)新一輪的 Agent 開發(fā)范式轉(zhuǎn)移：從提供算力、存儲等基礎(chǔ)資源的“云底座”，轉(zhuǎn)變?yōu)樘峁┮惶卓蓮?fù)用、工業(yè)化的“Agent 生產(chǎn)流水線”。

對企業(yè)來說，接下來的競爭重點，也正從“有沒有 Agent”，轉(zhuǎn)向“誰能更快、更穩(wěn)地把 Agent 造出來、用起來”。

1 給 Agent 開發(fā)做減法——讓“從想法到原型”變成幾天之內(nèi)的事

Swami 提到，當(dāng)下有兩件事在同時發(fā)生。

第一，“誰能構(gòu)建 Agent”的用戶主體，正在被改寫。過去，要做一個像樣的系統(tǒng)，必須熟練掌握編程語言，還要記住一堆 API 和參數(shù)。現(xiàn)在，越來越多的工作開始交給 Agent 完成，會把需求說清楚的人，正變成新的“構(gòu)建者”。

第二，“要花多久構(gòu)建”的現(xiàn)狀，也在被改寫。過去要幾年才能做出來的系統(tǒng)，現(xiàn)在有機會在幾個月內(nèi)上線；過去需要幾個月打磨的功能，正在被壓縮到幾周，甚至幾天。從想法到產(chǎn)生業(yè)務(wù)影響，這條路在變短，而 Agent 就是這條路徑上的加速器。

在這樣的前提下，Swami 把一個 Agent 拆成了三塊：模型，是“大腦”，負責(zé)推理、規(guī)劃和決策；代碼，是“身份和角色”，定義它能做什么、如何做決定；工具，是“手腳”，包括各類 API、數(shù)據(jù)庫、瀏覽器、解釋器等執(zhí)行手段。

Agent 開發(fā)慢，往往卡在這三者的配合上。模型不夠可靠，開發(fā)者就只能寫大量狀態(tài)機和決策樹，把流程一條條寫死，為各種可能情況提前設(shè)定工作流；工具調(diào)用和狀態(tài)切換需要硬編碼，一旦出現(xiàn)意料之外的情況，發(fā)生在 AI Agents 之間的復(fù)雜協(xié)作就會失效。久而久之，代碼庫被一層層“膠水代碼”包裹，既難維護，也很難在新場景中復(fù)用。

這次發(fā)布的 Amazon Strands Agents SDK，就是在這一層做“減法”。

Swami 提到，亞馬遜最初是為自家產(chǎn)品做 Agent，做到一半停下來問了自己一句話：如果從頭設(shè)計一套面向未來的 Agents SDK，它應(yīng)該是什么樣？

他們的答案很直接：盡量把控制流交給模型，讓模型結(jié)合上下文和可用工具自行規(guī)劃步驟；開發(fā)者只需要定義好三樣?xùn)|西——用哪顆“大腦”（模型）、這個 Agent 是誰（代碼里的身份和能力）、它可以動用哪些工具。

Amazon Strands Agents SDK 采用的就是這種“模型驅(qū)動”的方式：不再要求開發(fā)者提前寫完所有狀態(tài)機和工作流，而是讓 Agent 在運行時根據(jù)目標和環(huán)境做決策、動態(tài)調(diào)用工具。

效果很具體：在內(nèi)部的 Agent 系統(tǒng)中，他們刪掉了成千上萬行與工具選擇、狀態(tài)協(xié)調(diào)相關(guān)的膠水代碼，開發(fā)效率提升，Agent 的準確性和可維護性也更好。

驗證之后，亞馬遜決定將 Amazon Strands Agents SDK 開源。短短幾個月內(nèi)，Amazon Strands Agents SDK 下載量超過 500 萬，社區(qū)貢獻了大量擴展能力：支持更多模型、多 Agent 協(xié)同、TypeScript 和邊緣設(shè)備等。

這說明，Amazon Strands Agents SDK 確實踩中了開發(fā)者的痛點，它讓“寫一個 Agent”變得更加簡單。

不過，寫得快只是第一步。在 Swami 看來，真正拖慢項目的，還有一整段“從 PC 到生產(chǎn)環(huán)境”的路：Demo 很好看，業(yè)務(wù)部門卻遲遲等不到真正上生產(chǎn)的版本。

幾乎每家公司里，都有人在本地機上跑各種 Agent Demo，但領(lǐng)導(dǎo)層更關(guān)心的是：為什么這些東西進不了生產(chǎn)？什么時候能跑在 VPC 里，連上真實系統(tǒng)？這叫作“概念驗證困境”。

概念驗證要跨過去，需要解決五個問題：基礎(chǔ)設(shè)施能否從 0 擴展到幾千個并發(fā)會話；會話上下文和跨會話記憶怎么管理；身份與訪問控制如何保證安全；如何與內(nèi)部 API、數(shù)據(jù)庫以及第三方服務(wù)安全集成；出現(xiàn)問題時，日志、監(jiān)控和調(diào)試從哪里入手。

過去，要解決這些問題，往往得先拉起一個團隊，花上幾周甚至更久搭一套“Agent 環(huán)境”。

Amazon Bedrock AgentCore 的作用，就是把這部分也做成標準件。它不是再造一個新的框架，而是一套專門為 Agent 準備的工具箱：管理運行時、彈性擴縮容、會話隔離、會話記憶、身份和訪問控制，以及與各類服務(wù)之間的安全集成。

以身份管理為例，如果從零開始，你可能要花幾周時間處理認證協(xié)議、安全規(guī)范和各種邊緣場景；而用Amazon Bedrock AgentCore Identity，只需要幾行代碼，就能讓 Agent 代表用戶，在亞馬遜云科技和 Slack、Zoom 等第三方應(yīng)用之間安全地執(zhí)行操作。

當(dāng)控制流交給模型、基礎(chǔ)設(shè)施變成標準組件之后，從“想做一個 Agent”到“讓它在生產(chǎn)環(huán)境里跑起來”，就不必再是幾周甚至幾個月的排期，而有機會被壓縮到“幾天”這個量級。

而這只是亞馬遜“Agent 天級構(gòu)建”的起點，接下來更重要的是 Agent 的“大腦”——模型。

2 給模型訓(xùn)練做減法——讓“訓(xùn)練”更快更實用

Swami 在演講里說得很直接：今天搭一個 Agent 已經(jīng)不算難，難的是讓它跑得又快又省，還要貼合各自行業(yè)。

雖然，現(xiàn)在的大型語言模型足夠“聰明”，能多步推理，會用工具，也能處理意外情況。但一應(yīng)用到具體業(yè)務(wù)上，很容易遇到三個現(xiàn)實約束：

延遲：用戶和客服都等不了幾秒鐘的“轉(zhuǎn)圈”；規(guī)模：大促、旺季一來，系統(tǒng)是穩(wěn)住還是排隊；迭代速度：發(fā)現(xiàn)問題到修正上線，是按季度還是按天算。

因此，在他看來，問題已經(jīng)不在于“要不要定制模型”，而是兩個更具體的問題：能多快開始定制，能多快看到效果。

這也是為什么，強化學(xué)習(xí)在模型訓(xùn)練領(lǐng)域的定位始終是關(guān)鍵。過去，強化學(xué)習(xí)一直被視作“高配玩法”——模型通過行動結(jié)果學(xué)習(xí)，做好事有獎勵，犯錯就被“扣分”。原來有兩種路徑：

基于人類反饋的強化學(xué)習(xí)（RLHF）：給標注人員看同一個問題的多個回答，讓人類按好壞排序，再訓(xùn)練出一個“獎勵模型”，像人一樣打分。之后 Agent 每執(zhí)行一次動作，這個獎勵模型都會給它打分，模型在不斷試錯中學(xué)會什么是好的回答。

基于 AI 反饋的強化學(xué)習(xí)（RLAIF）：把“打分的人”換成大模型，讓它來評估和排序回答。這種方式比人工更快、更便宜、更一致，適合有明確對錯，或可以清晰表達的場景，還能獎勵“好的過程”，而不只是正確答案，讓模型學(xué)會更有條理的思考路徑。

這兩種方式聽上去很理想，但現(xiàn)實是：要在生產(chǎn)環(huán)境里做一輪像樣的強化學(xué)習(xí)訓(xùn)練，你需要獎勵建模、策略優(yōu)化、反饋整合方面的專家，還得搭起一整套分布式訓(xùn)練基礎(chǔ)設(shè)施。從立項到見效，6～12 個月很常見，而且結(jié)果未必穩(wěn)定，對大多數(shù)公司來說，這就是“勸退”。

把這些復(fù)雜性和成本都藏在平臺里，讓普通開發(fā)團隊也用得起這套技術(shù)，亞馬遜云科技發(fā)布了Amazon Bedrock Reinforcement Fine-Tuning（RFT），它很簡單：無須強化學(xué)習(xí)專家團隊，也能有強化學(xué)習(xí)帶來的效果。

用 RFT 時，開發(fā)者只需要做三件事：選一個基礎(chǔ)模型；指向在 Amazon Bedrock 中積累的日志，讓模型看到真實的 Agent 交互；選擇一個獎勵函數(shù)。最簡單的方式，是用一個大模型做“評審”，判斷哪種回答更好。剩下的工作，包括獎勵模型如何訓(xùn)練、策略如何優(yōu)化、訓(xùn)練如何調(diào)度，都由 Amazon Bedrock 在后臺完成。

在多數(shù)用例中，這種方式能在易用性和效果之間取得平衡，讓基礎(chǔ)模型在特定任務(wù)上的準確率明顯提升，而無需拉起一個半年周期的大項目。換句話說，原本只屬于少數(shù)玩家的強化學(xué)習(xí)，被壓縮成了一個任何團隊都能嘗試的“提效選項”。

此外，很多客戶的開發(fā)訴求則更直接：律師事務(wù)所希望模型真正掌握自己多年積累的案例與推理模式；醫(yī)療服務(wù)提供者希望模型能基于特定患者結(jié)果來學(xué)習(xí)；金融機構(gòu)需要的是對本國市場、監(jiān)管環(huán)境有深刻理解的模型。他們希望完全掌控定制技術(shù)和數(shù)據(jù)，而不僅僅是在通用模型上“加一層強化微調(diào)”。

亞馬遜云科技在 2024 年推出的 Amazon SageMaker AI，其實就是在圍繞這個問題布局，到了 2025 亞馬遜云科技 re:Invent，又發(fā)布了Amazon SageMaker AI Serverless Model Customization，它能為開發(fā)者提供兩種體驗：一種是自助式體驗，適合喜歡掌控全局的開發(fā)者；一種是 Agent 驅(qū)動，只需自然語言描述用例，AI Agent 會推薦微調(diào)技術(shù)、生成數(shù)據(jù)集、設(shè)置 Serverless 訓(xùn)練、評估模型效果。

這意味著，原本需要數(shù)月完成工作，如今只需要幾天，全程由懂最佳實踐的 Agent 指導(dǎo)完成，并且支持最新的強化學(xué)習(xí)技術(shù)，包括 RLAIF、RLVR 和 DPO。

當(dāng)然，還有一類客戶的目標更高。他們要的不是“懂一點行業(yè)術(shù)語”的模型，而是一個從底層就理解該行業(yè)的基礎(chǔ)模型。

以藥物研發(fā)公司為例，他們需要模型真正理解分子結(jié)構(gòu)、蛋白質(zhì)相互作用、特定治療領(lǐng)域的臨床數(shù)據(jù)。對這種需求來說，只在通用模型上做微調(diào)是不夠的——就像隨手教一個通用翻譯幾句醫(yī)學(xué)詞匯，和從頭培養(yǎng)一位醫(yī)療翻譯，是兩件完全不同的事。

按照傳統(tǒng)路徑，要獲得這樣的基礎(chǔ)模型，幾乎只能從零開始訓(xùn)練：組建頂級機器學(xué)習(xí)團隊；承擔(dān)數(shù)百萬美元的算力成本和數(shù)月的訓(xùn)練周期；還要接受“辛苦訓(xùn)練完，效果未必理想”的不確定性。這也是為什么，定制基礎(chǔ)模型長期以來幾乎只屬于大廠和頭部 AI 創(chuàng)企。

亞馬遜云科技針對這些痛點推出的 Amazon Nova Forge，試圖改寫的就是這條“起跑線”。

它允許你在 Amazon Nova 的訓(xùn)練過程中訪問中間檢查點：不必從頭開始，而是在訓(xùn)練中段接手；用自有數(shù)據(jù)與亞馬遜云科技精選數(shù)據(jù)混合繼續(xù)訓(xùn)練；既繼承 Amazon Nova 的通用智能、安全性和可靠性，又在后半段注入你所在行業(yè)的知識和工作流理解。

最終可以得到的是一個既“前沿”，又“貼身”的模型：對通用世界有足夠理解；對特定行業(yè)有深入洞察；而你不需要承擔(dān)完整訓(xùn)練生命周期的全部成本和工程復(fù)雜度。

從“訓(xùn)練效率”的角度看，這是更高一層的減法：不是簡單把每一次訓(xùn)練跑得更快，而是改變了從哪一步開始訓(xùn)練。

3 給 Agent 工程化做減法——高效解決 Agent“信任”與“可靠”難題

目前，大多數(shù) AI Agent 系統(tǒng)仍主要依賴大模型的統(tǒng)計式推理能力來做決策。在聊天、寫稿這類輕量場景里問題不大，但一旦涉及資金、生產(chǎn)環(huán)境或安全責(zé)任，這種不確定性就變成核心風(fēng)險。

Swami 的比喻也很直白：給 Agent 開通信用卡的權(quán)限，就像把信用卡交給一個青少年——他確實能幫你辦不少事，也可能哪天突然買了一匹小馬，或一倉庫零食。

根源在于，大模型的本性是概率式產(chǎn)生“幻覺”，容易在復(fù)雜規(guī)則和法律條文面前犯錯、推理路徑不透明，很難像讀程序那樣逐行檢查，以及容易被刻意設(shè)計的輸入“帶跑偏”。

面對這種不確定性，企業(yè)通常會“過度補償”：一種是事事人工復(fù)核，層層加簽，流程越拉越長，Agent 的價值被拆得所剩無幾；另一種是把 Agent 寫成腳本，用硬編碼規(guī)則把它綁住，犧牲掉 Agent 自主性。

兩條路的共同結(jié)果，是信任問題變成效率問題：想上線一個 Agent，難點不在能不能做出來，而在審批和風(fēng)控始終不敢放行，“快速落地”無從談起。

要打破這個局面，亞馬遜云科技提出了先換一種思路：不再靠加人、加流程來換安全感，而是把“能做什么、不能做什么”變成可以形式化驗證的約束。

幾年前，亞馬遜云科技內(nèi)部第一個 AI Agent 原型（也就是今天 Kiro CLI 的前身），就暴露過一個關(guān)鍵問題：模型會出現(xiàn)“API 調(diào)用幻覺”——調(diào)用一個看似合理、但根本不存在的接口。

為了解決這一問題，他們當(dāng)時把科學(xué)家、機器學(xué)習(xí)工程師和自動推理團隊拉到一起，最后確定了一條路徑：把大模型（神經(jīng)網(wǎng)絡(luò)）和形式化推理（符號邏輯）結(jié)合，做成所謂的“神經(jīng)符號 AI”。

這個背后的“自動推理”能力，簡單說，就是用數(shù)理邏輯窮盡程序可能的執(zhí)行路徑，去回答一個問題：在所有這些路徑里，有沒有一種會違反規(guī)則？

事實上，這套技術(shù)，亞馬遜云科技已經(jīng)使用了十多年：內(nèi)部用來分析虛擬化、加密、身份認證、網(wǎng)絡(luò)系統(tǒng)；對外則以 Amazon IAM Access Analyzer、Amazon VPC Reachability Analyzer、Amazon S3 Block Public Access 等工具的形式提供；在其他行業(yè)，它也被用在航空航天、鐵路信號、工業(yè)控制等“不允許出錯”的系統(tǒng)中。

目前，這套“老技術(shù)”將系統(tǒng)性地接入 Agent 領(lǐng)域：用自動推理驗證 Agent 輸出的程序和指令，有問題就打回；用推理系統(tǒng)的結(jié)果反向訓(xùn)練模型，讓模型更懂約束和邏輯；更重要的是，把驗證器直接嵌入 Agent 的推理和執(zhí)行鏈路，讓約束從一開始就是系統(tǒng)的一部分，而不是上線前的“補丁”。

在這樣的框架下，“信任”的含義也被改寫了：不再是“我覺得它大概沒問題”，而是“在這個邊界內(nèi)，它不會越線”。

信任之外，另一個同樣關(guān)鍵的問題是可靠性——不僅要“不越界”，還要“每次都能干好”。

許多企業(yè)已經(jīng)有過教訓(xùn)：Agent 在 Demo 里表現(xiàn)亮眼，第一天上線也沒問題，但到了第 N 次，或環(huán)境稍一變化，就開始犯糊涂。這種不穩(wěn)定同樣會拖慢上線節(jié)奏，讓團隊遲遲不敢把真正關(guān)鍵的流程交出去。

亞馬遜云科技對這個問題的回答是Amazon Nova Act。它專門負責(zé)自動化各種帶界面的企業(yè)工作流程——填表、改記錄、發(fā)請求、走審批，看上去像 RPA 的升級版，但思路完全不同：

傳統(tǒng) RPA 靠錄腳本，一變腳本就失效；通用大模型雖然能理解界面變化，但協(xié)調(diào)和糾錯復(fù)雜，一旦走錯分支，很容易“一錯到底”。Amazon Nova Act 則從一開始就把模型、協(xié)調(diào)器、執(zhí)行器和 SDK 當(dāng)成一個整體，在訓(xùn)練階段就緊密打包，而不是各自為戰(zhàn)。

更關(guān)鍵的是，它的可靠性不是靠“沒出過大事”的經(jīng)驗判斷，而是通過強化學(xué)習(xí)與訓(xùn)練環(huán)境練出來的。

亞馬遜云科技已經(jīng)為常見企業(yè)流程搭建了大量仿真環(huán)境（RLGyms）：CRM、人力資源、工單、審批系統(tǒng)……只要有 UI，就可以復(fù)制出一個“訓(xùn)練版”。

在這些環(huán)境里，Amazon Nova Act 的 Agent 反復(fù)跑任務(wù)：每次完整走完流程會被獎勵；出錯則受到懲罰。數(shù)百個環(huán)境、數(shù)千條并行工作流，讓它在不影響真實系統(tǒng)的前提下，把“常見業(yè)務(wù)流程”跑熟、跑穩(wěn)。

最終呈現(xiàn)出來的，是可以量化的結(jié)果：在它瞄準的企業(yè)工作流場景中，Amazon Nova Act 的可靠性可以達到約 90%；在 RealBench、ScreenSpot 等基準測試上，Amazon Nova Act 的表現(xiàn)與該領(lǐng)域最好的模型相當(dāng)甚至更好。

當(dāng)信任與可靠性都被拉進這樣的工程框架里，Agent 項目從“技術(shù)可行”到“敢上線、敢托付”的最后一公里，才真正有了“提速”空間。

可以說，這一屆 re:Invent，亞馬遜云科技試圖證明的是：當(dāng) Agent 開發(fā)、模型訓(xùn)練、工程化這三道關(guān)都完成了“減法”，企業(yè)就有能力把智能體的構(gòu)建周期，從按“月”計算，實實在在壓縮到可以按“天”來衡量——而且不是停留在實驗室里。

而可以預(yù)見的是，未來圍繞 Agent 的競爭，也會從“誰先喊出口號”，真正轉(zhuǎn)向“誰能更快、更穩(wěn)地把 Agent 推向生產(chǎn)”。在這一場新的競賽里，誰能率先過濾掉“噪音”，把時間和資源押在可驗證、可交付的能力上，誰也就更有機會抓住這輪生產(chǎn)力升級的窗口。

2025 亞馬遜云科技re:Invent 中國行即將啟幕！12月18日開始，北京、上海、深圳、成都四城線下巡演及線上專場將同步開啟，無論你是云計算新手還是技術(shù)老兵，都將從高階演講、實戰(zhàn)內(nèi)容、技術(shù)分享和專家互動中受益。點擊【閱讀原文】立即注冊，搶占席位，把握Agentic AI時代的新機遇！