68歲亞馬遜CTO：別讓恐懼，替企業做AI決策

來源原標題

68歲亞馬遜CTO：別讓恐懼，替企業做AI決策

作者

十三

原始標籤

資訊 · Agent · Werner Vogels · 雲端計算 · 亞馬遜雲科技

原始連結

https://www.qbitai.com/2026/10/503815.html

摘要原文

68歲亞馬遜CTO：別讓恐懼，替企業做AI決策 十三 2026-10-16 15:01:31 來源： 量子位 經驗沒有壓縮演算法 金磊 發自 深圳 量子位 | 公眾號 QbitAI 恐懼是一種非常糟糕的決策方式。 當企業擔心錯過AI轉型視窗，亞馬遜CTO Werner Vogels 提醒，越是著急，越需要先想清楚：企業究竟要解決什麼問題，AI又能幫上什麼忙。 如今每週都有新模型冒出來，大家越看越焦慮，生怕一步慢、步步慢。提效率、搞創新的心情一個比一個迫切，可技術到底能做什麼，反倒沒顧上弄清楚。 在深圳的一次交流中，他直言，企業不會因為此刻沒有用上AI就立即倒閉。所以作決定之前，企業需要先讓工程師和管理者充分學習，瞭解技術的能力。 但這話從Werner嘴裡說出來，多少是有點反差在身上的。 畢竟這位擔任亞馬遜CTO二十多年的技術老兵，向來不願意接受“不可能”。講起雲端計算的幕後故事時，他還特意搬出計算機先驅Grace Hopper的名言，提醒開發者警惕那句“我們一直都是這樣做的”。 一個不斷鼓勵工程師打破常規的人，為什麼到了AI這裡，又讓大家先緩一緩？ 他講起的一場資料庫故障，或許能解釋這種看似矛盾的態度。 資料庫踩過的坑，AI還要再踩一遍嗎？ 2004年12月12日，亞馬遜正處在聖誕購物季的關鍵節點。當時使用者購物滿25美元就能享受免費配送，但運輸需要時間，再晚下單，包裹就可能趕不上聖誕節。 偏偏就在這一天，客戶資料庫背後的共享磁碟出了故障，使用者無法登入，也無法下單。按照Werner的回憶，這次故障持續了 十二個多小時 ，讓亞馬遜 損失了數百萬美元 。 資料庫供應商後來找上門，Werner原以為對方會鄭重道歉，聽到的卻是“你們應該做好測試”。 自家的產品出了問題，怎麼還怪起客戶來了？ Werner當然生氣，但他後來也意識到，亞馬遜的規模確實已經遠遠超出了這套商業軟體的設計範圍。繼續和供應商爭論，也解決不了下一次故障。 於是，團隊開始調查一個更基本的問題。 亞馬遜究竟怎樣使用資料庫？ 調查結果顯示，約70%的關係型資料庫使用場景，只需要鍵值訪問。 拿購物車來說，系統通常只需要根據使用者標識，取出對應的購物車。亞馬遜並不需要把所有使用者的購物車都調出來，做一次複雜查詢。 既然需求如此，團隊能不能換一種實現方式？順著真實的訪問方式往下想，他們構建了鍵值儲存系統 Dynamo ，也就是DynamoDB的前身。 這段經歷放到今天，頗有既視感。當年大家拿關係型資料庫這把大錘處理各種資料問題，如今大模型也很容易成為那把順手的錘子。 談到企業採用AI，Werner反覆追問的也是類似的問題。 企業究竟想解決什麼，AI是否適合，當前這一代AI是否適合？ 他提醒，影像識別、語音處理、預測等領域，早就積累了大量有效的方法。企業選擇技術之前，需要先看任務本身。即使用大模型，也未必需要追著榜單第一名跑。 Werner對基準測試有所保留，因為人為構造的測試與真實業務之間，仍有距離。如果一個模型已經足夠完成任務，企業繼續為更高的排名付錢，就得重新掂量收益。 而且Werner算這筆賬， 已經算了二十多年 。 當交流的話題轉向雲端計算帶來的根本變化時，他格外看重經濟模式的改變。 過去買企業軟體，企業往往得先簽五年、十年的合同。管理者連明年的需求都很難預測，卻要先把錢付出去。Werner覺得，這就像顧客進餐廳先放下一千美元，沒吃完也不退款。 雲端計算把資源使用量和付費聯絡起來，也讓“縮容”有了實際意義。夜裡沒那麼多使用者，企業就可以把不需要的資源關掉。成本終於能夠進入架構討論，業務部門也需要回答，某項能力到底值得花多少錢。 到了AI時代，這筆賬又有了新專案。 比如在量子位問起， “為什麼智慧體連遺忘都成了重要工程問題？” 時，Werner直言，如果智慧體每次工作前，都要掃描自己知道的一切，系統開銷就會很大；開發者需要想辦法，讓它留下對任務真正重要的內容。 他還提到，一些程式設計工具重新啟動時，會再次載入專案內容。使用者昨天已經為這些準備工作付過錢，今天又得重新付一遍。Kiro的跨會話記憶，正是想減少這樣的重複勞動。 所以，除了模型有多聰明，開發者還得追問，它為了完成一次任務，反覆做了多少無用功。 這也解釋了Werner為何願意談較小的模型，以及DeepSeek、通義千問、Kimi等開放權重模型。按他的觀察，有些客戶經過持續實驗，發現更小的模型已經能滿足需求，使用成本也低得多。 用什麼、怎麼用、花多少錢，這些老問題，企業到了AI這裡依然繞不過去。 誰來替Agent犯的錯兜底？ 即使企業算清了成本，還有另一個問題等著開發團隊。 聊天機器人給出一段文字，人可以看完再決定怎麼辦。Agent則會代表使用者採取行動，改行程、呼叫工具、執行程式。模型一旦給錯答案，錯誤就可能順著執行過程變成真實後果。 Werner在交流的過程中表示，他很樂意讓Agent幫忙改簽車票，但他也有明確要求。系統得知道如何操作、記住他的偏好，同時受到約束。 而這種對邊界的執著，在他講的 Nitro 故事裡，已經有所提及。 早期雲端計算依賴虛擬化，把一臺物理伺服器分給多個使用者；但負責管理虛擬機器、處理網路和儲存訪問的軟體，本身也要消耗資源。隨著虛擬機器越來越多，管理層還可能成為瓶頸。 AWS後來構建Nitro，把大量網路、儲存等功能卸載到專用硬體，並去掉了原先那個完整的Linux管理環境dom0。團隊緩解了效能瓶頸，也隨之縮小了一大塊攻擊面。 Nitro還有一個有意思的設計，叫“被動通訊”。根據Werner的介紹，虛擬機器監控程式等待Nitro控制器下發命令。如果它反過來主動聯絡控制器，就出現了正常流程裡不該有的行為，平臺可以據此將相關係統退出服務，展開調查。 順著這個思路，也就容易理解Werner對Agent的要求了。使用者允許系統做什麼，必須提前說清楚。他舉了一個簡單例子，使用者可以規定Agent每天不能花費超過100美元，一旦超出，就需要人參與決策。 按他的介紹，亞馬遜為Agent設計了規則執行機制，對Agent訪問工具、執行指令碼等操作進行檢查，以限制它在客戶明確授權的範圍內行動。 使用者的授權給自主行動劃出了具體範圍，即便模型判斷某件事值得做，執行系統仍要檢查它有沒有許可權做。 但這些約束，會不會拖累Agent的效率？面對這個問題，Werner先談的是 責任 。 你構建它，你就對它負責。（You build it, you own it.） 在他看來，Agent的開發者必須能夠控制它。系統採取了什麼行動、有沒有超出邊界，最終仍然需要人負責。 Werner也把對AI的信任，放回了分散式系統的經驗裡。工程師從來不會假定每個元件都永遠可靠，所以才需要複製、隔離和各種可靠性機制。團隊對單個元件保持警惕，才能建立對整個系統的信任。 不過，工程師要把這些保護機制做成客戶用得起、又不會明顯拖慢任務的服務，還得經歷不少取捨。Lambda就曾遇到過類似的難題。 早年WeTransfer為了處理上傳到S3的檔案，需要一直執行一批計算例項，等待新檔案到來。客戶光是為了等待事件發生，就得維護一整套基礎設施。 AWS希望把這些工作接過來，讓客戶提交程式碼，按執行時間和記憶體使用量付費。團隊想清楚了收費方式，底層怎樣高效實現，卻仍是一道難題。 為了隔離不同客戶，早期Lambda使用的虛擬機器，對函式任務來說依然太大，成本很高。後來，團隊通過Firecracker把隔離單元做成更輕的微虛擬機器，才提高了資源利用率。 隔離問題得到解決之後，團隊還得處理冷啟動。函式真正執行前，系統需要準備好執行環境、程式碼和依賴。SnapStart通過儲存已初始化環境的快照，減少這部分準備開銷，改善啟動表現。 客戶看到的，可能只是一次函式呼叫。工程團隊卻要在背後持續打磨隔離、資源分配、啟動和網路機制。 Werner把這些工作稱為 “看不見的工程創新”（Invisible Engineering） 。 Agent要進入實際業務，開發團隊同樣少不了這些細活。演示跑通之後，團隊還得繼續明確許可權怎樣限制、異常怎樣處理，以及使用者願意把多大範圍的任務交給它。 經驗沒有壓縮演算法 當Agent開始寫程式碼，上面這些問題又回到了開發團隊自己身上。 談到初級工程師的就業，Werner回應，亞馬遜招聘初級工程師的數量與過去一樣。隨後，他把話題轉向了新人進入團隊之後的學習。 一個剛畢業的人加入S3團隊，面對的可能是二十年前的程式碼。學校很難提前教會他，怎樣理解這樣一個系統，以及怎樣和維護它的人協作。 因此，Werner看重好奇心、學習能力和開源專案經歷。一個新人參加過開源協作，意味著他的程式碼接受過其他人的審視，他也需要與別人一起解決問題。 AI可以幫新人解釋團隊規則，讓資深工程師少花一些時間反覆說明。Werner介紹Kiro時，強調的也是規格說明驅動。開發者先把需求、架構和開發規則交代清楚，再讓系統開展工作。 不過，AI生成程式碼的速度上來了，團隊理解和檢查程式碼的速度，未必跟得上。 Werner提到了一個值得開發團隊留意的概念，驗證債。 過去為了趕進度，開發者走了捷徑，記下以後要修，積累的是技術債。現在，AI生成的程式碼中，有些部分還沒經過驗證，團隊也就留下了另一筆債。 一個介面元素偏了幾毫米，與一段可能洩露客戶資訊的程式碼，後果相差甚遠。開發團隊需要根據風險安排檢查，把精力投入最需要驗證的地方。 沿著Werner的思路看，團隊很容易增加程式碼產量，但能否理解這些程式碼、承擔它們帶來的後果，還需要另外衡量。否則，開發者今天省下的時間，可能會在後續排查和返工中重新花掉。 這也是Werner為什麼堅持讓初級工程師閱讀程式碼，和資深工程師一起審查、討論。工具可以解釋知識，人面對具體問題時所需要的判斷，仍要一點點積累。 經驗沒有壓縮演算法。 （There is no compression algorithm for experience.） Werner的這句話，用來回答開發者的焦慮，頗為貼切。 不過，談到中國之行，他又講起了一個讓他對AI應用更樂觀的例子。他花了不少時間介紹“大米和小米”的參訪經歷。 這家機構為自閉症、注意缺陷多動障礙等有發展支援需求的兒童提供干預服務。據Werner介紹，機構利用AI分析教學記錄、觀察孩子的進展，並向康復師提供方案建議。康復師再結合專業判斷，決定採用哪些建議。 讓他印象深刻的，是AI幫助專業人員減少了事務性工作，讓他們能把更多精力留給孩子和家庭。 談到這裡，Werner的樂觀有了具體物件。技術能讓哪些人少一點負擔，又能幫助哪些原本難以獲得支援的人？這些具體應用，讓他看到了AI的價值。 回頭看那句“先按暫停鍵”，企業需要停下來想清楚的事情，也就具體了。任務是否適合交給AI，成本能否承擔，行動範圍怎樣規定，結果由誰驗證，開發團隊都得逐項回答。 Werner說，開發者最出色的工作，往往藏在別人看不見的地方。 AI替人多寫了一段程式碼，工程師還得知道，這段程式碼上線後會發生什麼。 版權所有，未經授權不得以任何形式轉載及使用，違者必究。 Agent Werner Vogels 雲端計算 亞馬遜雲科技 十三 iPhone斷網跑35B多模態！國產開源新模型，只佔3G記憶體 2026-10-14 TRAE終於把Code和Work合併了 2026-10-09 真香！做這個邪惡老奶版「GTA 6」，我只花了5元！ 2026-10-08 把記憶交給CPU，大模型會變快 2026-09-16 相關閱讀