85% 的開發者支援，阿里雲丟給了 agent

15 個 agent，接掉 85% 的開發者支援請求。營運支援的工時，砍掉九成。原本要好幾天的軟體發版，壓到一天。

這是阿里雲 7 月 18 日在上海 WAIC（World Artificial Intelligence Conference）端出來的一組數字，用來證明它當天發表的新東西——Agent Native Cloud，一個「為 AI 代理人（AI agent）重新設計的雲」——不是投影片上的概念，而是它自己內部已經在跑的東西。

先別急著記下 85%。這是目前對「agent 到底能吃掉多少內部工作」講得最具體的一個公開數字，值得認真看。但它也有一個你一眼就該問的問題：這張成績單，是阿里替自己打的。分母沒公開、沒有外部客戶背書，是它自家的開發團隊在用自家的雲。這篇要做的，就是把這組數字該怎麼讀、以及它底下那條更耐用的規律，講給你聽。

「agent 原生雲」不是把 agent 裝到舊雲上

過去兩年，各家雲的做法比較像「在現有的雲上，多開一個 agent 服務」——雲的底層還是為了跑網站、跑 app、跑資料庫設計的，agent 是加上去的一層。

阿里雲這次講的是另一件事：把底層重寫成假設「主要住戶是 agent，不是人」。它端出兩個主件：

• AgentTeams：負責編排一群各有專職的 agent 協作——誰先做、誰接手、誰覆核，像在管一支團隊而不是呼叫一個模型。
• Agentic Computer：agent 實際動手的地方，強調雲端安全執行——原生沙箱（native sandbox）、工作負載隔離、彈性擴縮、企業身分整合。

差別在哪？當 agent 會自己寫程式、開網頁、改檔案、呼叫工具，你就得假設它會出錯、會被誘導、要跑很久、還要同時跑很多個。沙箱與隔離是為了讓一個 agent 搞砸時不波及其他人的資料；企業身分整合是為了讓 agent 的每個動作都掛在一個可稽核的身分上。這些不是把舊雲的功能換句話說，而是為「一群會亂動的 agent 同時上工」重畫地基。

85% 這個數字，強在哪、又不能替你證明什麼

先講它為什麼值得看。市面上談 agent 的內容，多半停在 demo 或「效率提升」這種沒有機制的空話。阿里這次給的是一個帶分母意味的落地數字——85% 的開發者支援請求由 agent 接手——這在「agent 能接掉多少既有工作」這個問題上，是難得的具體錨點。

再講它不能替你證明什麼，這段請一次讀完：

• 這是自評。阿里內部團隊、用阿里的雲、報阿里的數字，沒有第三方量測，也沒有外部客戶用同樣條件跑出同樣結果。
• 分母沒公開。「85% 的開發者支援請求」是哪一類請求、總量多少、難的簡單的各佔多少，來源沒說。同樣一個 85%，如果多半是「怎麼重設密碼」等級的問答，跟包含疑難排解，意義差很遠。
• 開發者支援本來就是好案例。它高頻、重複、而且有大量文件與歷史工單可餵——這正是 agent 目前最擅長的地盤。拿最順的任務跑出的比例，不能直接外推到需要判斷的工作。

所以這組數字的正確用法，是當「方向」讀，不是當「戰績」讀：它告訴你 agent 在某類任務上已經能扛主力，而不是告訴你你的團隊照做也會有 85%。

為什麼先被吃掉的是「開發者支援」

把上面那三點反過來看，其實浮現一條比數字本身更耐用的規律——agent 會先落在有邊界、高頻、又已經文件化的任務類。

開發者支援剛好三個都中：問題類型有限（有邊界）、每天大量重複（高頻）、而且答案多半躺在文件、工單與程式碼裡（文件化，餵得進去）。反過來，需要跨部門判斷、要承擔後果、或答案根本還沒被寫下來的工作，agent 目前接不住。

這條規律，比「阿里做到 85%」對你更有用。它可以直接變成一張自評清單：

任務長這樣	agent 現在的位置
邊界清楚、每天重複、答案在文件／工單／程式碼裡	會先被接手（像開發者支援、常見客服、格式轉換）
邊界清楚但要承擔後果	agent 草擬、人覆核（像發版、退款、對外回覆）
邊界模糊、要跨部門判斷、答案還沒被寫下來	仍需人主導

Qi Zhou 的賭注：不是 agent 數量，是能不能「留下來」

發表的雲原生應用平台負責人 Qi Zhou（祁曉）說了一句話，透露阿里真正在賭什麼：下一階段的競爭，不取決於一家組織部署了多少 agent，而在於能不能把這些 agent 變成「可控、可複用、可協作、可持續演進」的組織資產。

翻成白話：一次性叫某個 agent 幫你做完一件事不難，難的是讓它做過的事沉澱下來——這次解掉的支援問題，下次別人（或別的 agent）能直接複用；權限與規範能一路跟著；成效能持續變好。Agent Native Cloud 想賣的，與其說是「更多 agent」，不如說是「讓 agent 的產出留得住、管得動」的那層地基。這也解釋了為什麼它要從底層重畫，而不是多加一個服務。

你該帶走的，是那張清單

Agent Native Cloud 本身是不是最強的 agent 雲，還要看外部客戶跑出什麼、定價與可用性怎麼落地——這些阿里這次都還沒講。但這則新聞真正對你有用的，不是阿里的 85%，而是它替你把「哪些任務會先被 agent 吃掉」講清楚了。

回去看你手上的工作：哪些長得像開發者支援——有邊界、高頻、答案已經寫在某份文件裡？那些就是你最該先試、也最容易試出成果的地方。至於阿里那組數字，記得它是誰打的：當指北針用，別當你自己的成績單抄。