治理與進化，如何成為企業級 Agent 的兩條生死線？

如何讓 Agent 低成本、低風險地在企業級場景運行。

作者｜Cynthia

編輯｜鄭玄

AI 降本增效的故事，在 B 端的進展，似乎比預想的要更慢一些。

就在一周前，深度擁抱 AI 多年的福特汽車承認，過去三年，由于人工智能系統不夠完善、頻頻在車輛質量檢測上掉鏈子，福特已經雇傭、晉升或重新召回了超過 350 名 經驗豐富的工程師。

幾乎同一時間，給出 70% 的企業將在 2026 年底在生產環境運行 AI Agents 預測的 Gartner，也在最新的 AI 報告中寫下：到 2027 年，因為人工智能裁掉客服的公司，有一半需要重新招人。

市場決策的反復橫跳背后是大模型與企業級應用之間難以磨滅的根本悖論：大模型的智慧涌現能力與幻覺是一體兩面；但企業級應用需要絕對的確定性。

其中，福特式失控的根本在于汽車行業安全標準與司乘性命直接掛鉤，而 Agent 行為不可觀測、權限不可控、責任不可追溯的治理缺位，會直接影響品牌用百年時間塑造起的安全形象。

Gartner 式反復的根本，則是在于技術不斷變化，需求也在持續調整，把 Agent 放進生產環境只是開始，它能不能在真實業務中持續被觀測、被評估、被優化，才決定了企業能否真正吃到 AI 紅利，并將 Agent 戰略持續下去。

相應的，如何在 infra 層面同時解決「治理」與「進化」這兩組矛盾，就成了當下行業最重要的命題。

01

Agent 編排越來越簡單，

需要 infra 越來越厚

讓我們先把目光投向更宏觀的行業全貌，當下市面上的各種主流 Agent，不外乎三種模式：

最早爆火的 Manus 代表了行業早期流行的成品黑盒方案。這一時期的產品，平臺會統一管控記憶、提示詞、知識庫、工作流、MCP 等完整能力層，用戶僅可通過瀏覽器交互界面進行操作。這種厚重完整的能力棧架構，本質上是用多層配套體系來彌補早期模型泛化能力不足、上下文腐爛、技術債累積等問題。

今年后來者居上的 OpenClaw 選擇了一條不同的路——它將能力層拆解為 agent.md、soul.md、User.md 等文本協議，搭配心跳、技能、會話管理模塊，交由可以用戶自主配置調試。并通過交互兼容瀏覽器與各類辦公 IM 工具，把多模塊工程復雜度簡化為文本配置復雜度，以輕量化約束機制來發揮模型自身能力。

而最近爆火的 Claude 托管 Agent，則將能力層進一步精簡為環境、會話、事件三大模塊。它不再單獨設置記憶、知識庫與工作流，相關能力下沉至模型內部，由廠商根據需求定制搭建——同樣支持多端交互。

隨著時間的推移與技術的進步，位于中間層的 Agent 編排正變得越來越輕量化。

相應的，在后端的基礎設施層，從前規律可預測的流量，人類為主導的登錄交互模式，對長期穩定資源的需求，徹底成為過去式。云服務也需要從過去的賣資源、賣流量，進化成為一朵專門 Agent 時代打造的Agent Native Cloud。

那么，如何理解 Agent Native Cloud 的概念？

以阿里云為例，這是一個與早期提出的「AI Native Cloud」相對的概念。AI Native Cloud 服務的是大模型廠商的訓練與推理；Agent Native Cloud 則向前再走一步，針對 Agent 的短生命周期、無規律突發負載、動態環境依賴、任務級安全管控、大規模動態編排、復雜數據模態六大特性，分別用運行時、編排與治理、安全、記憶、數據平面六大能力來進行應對。

具體到Agent 編排與治理上，阿里云智能集團云原生應用平臺負責人周琦分享：

過去，企業會按銷售、運營等業務部門拆分為銷售、訂單、運營的獨立微服務，客戶需求流轉依靠各微服務互相調用協作完成閉環。這一時期，治理上，需要完成標準化、確定性的 API 接口做流量、穩定性、權限與運行態治理，解決結構化、固定規則下的服務管控問題。

但步入 Agent 時代后，原有微服務體系完成智能化升級，服務間的交互邏輯轉化為 Agent 與 Agent 之間協同通信。傳統靜態 API 接口也被 AI 智能體賦能，從確定性調用升級為具備自主理解、自主編排、動態執行的智能能力入口，治理對象也從微服務接口升級為動態運行的 AI Agent。

這也是不久前 7 月 3 日阿里云飛天發布時刻，發布 AgentTeams（企業級多智能體協作與治理平臺）與 AgentLoop（企業級智能體一站式自進化平臺）的核心背景。

02

企業落地 agent，

為什么需要協作治理先行？

要理解 AgentTeams，就需要先思考清楚一件事，Agent 從 C 端走向 B 端，到底什么變了？

周琦分享了一個有意思的觀察：To C 場景的 Agent 使用，更多偏向于個人創造與娛樂（沒有統一的衡量指標）；但是在 B 端，企業需要追求 ROI，穩定性、成本、性能、可靠性等一系列指標。

他舉了個簡單例子，一個客服 Agent 的 demo，使用 AI coding 掛載一些簡單工具，可能幾個小時就能搭建完成。

但是要將它在生產環境中，我們需要把它接入 CIM 系統來讀取更多的上下文，那些為人設計的 OA 系統，要如何將 Agent 納入閉環？人又要如何與 Agent 協同？

更進一步，我們還需要在一次事件處理結束后，讓 Agent 能夠主動學習交互中人提供的經驗，并以更高維度去觀察整個客服交互過程中，agent 的行為是否可以被觀察、token 的消耗是否合理……

在這一背景下，企業的需求，早就從能這個系統能不能跑，變成了如何設計權限管控、安全兜底機制，讓我們能夠更加信任的把任務交給 Agent。

這還僅是單 Agent 落地企業場景面臨的顧慮，從完整的企業視角出發來看，面臨的問題還要更加復雜。

以小型創業公司為例，他們的團隊往往分布在不同城市，合伙人、遠程員工、外包開發者各自在本地環境中使用 AI 編碼工具。

于是就會出現，不同 Agent 各自為政，云端與本地 Agent 割裂。那么這些 Agent 之間如何通信？由誰來協調它們的分工？當某個 Agent 的執行結果出現問題時，如何追溯問題的根源？開發者本地 Agent 的 prompt、工具鏈、上下文知識都是獨立維護的，如何讓組織內的更多人能夠復用、協同。

最重要的是，Agent 直持憑證帶來的安全風險。大多數 Agent 在執行任務時需要訪問企業的各種系統和數據。如何保證這些 Agent 不會在未經授權的情況下泄露敏感信息？如何監控 Token 消耗、控制成本？

基于以上行業洞察，以及團隊多年積累下的微服務分域、分工協作的成熟治理思路，AgentTeams 誕生了。

周琦介紹，AgentTeams 可以理解為是面向企業的多智能體治理與協作平臺，支持企業在統一的控制臺中創建和管理 AI Worker。

打個通俗的比方，過去一個 Agent 是一名單兵作戰的"AI 員工"，而聚集起多個 Agent 的 AgentTeams 就是把這些員工組織起來干活的"公司的規章制度與運行規范"。它要解決的核心問題是——這群 AI 員工在協作過程中，權限怎么分、任務怎么派、憑證怎么管、出了事誰來兜底，才讓企業放心地把活兒交給它們，發揮出 1+1+1 大于 3 的效果。

它首先解決的是，企業最關心的安全問題。能力上，平臺可無縫對接企業 idP 體系并安全托管各類憑證，讓 Agent 無需明文存儲密鑰、僅按需臨時獲取權限；所有工具與 MCP 調用都會經過平臺統一攔截校驗，依據預設訪問策略動態放行；配套沙箱運行環境實現資源、網絡、存儲三層強隔離，可以保障各智能體運行互不干擾；同時集中納管企業模型、MCP 服務、Skill、Agent 模板等核心 AI 資產，提供統一鑒權與安全審核能力，實現 AI 資產 BYOC 自主可控。

權限設計上，AgentTeams 則設計了用戶和 Agent 角色，用戶分為 Admin 和普通用戶，每個普通用戶可以獨立配置是否可以使用 TeamLeader Agent 和哪些 Workers 的權限，用于保證人與 AI 協同中的精細權限管控。

更進一步，AgentTeams 還同時集成釘釘、飛書、企業微信等企業主流 IM 工具。員工在熟悉的聊天窗口即可發起任務、實時監督、審批干預，Agent 執行結果回傳 IM。

當一個項目負責人需要讓 Agent 完成一些復雜任務時，他可以通過一個 Leader Agent 拆解研發任務，將不同的子任務分派給最合適的 Agent 執行，各 Agent 完成各自的任務后，結果匯總到 Leader，由 Leader 進行整合和質量把控，最終直接在 IM 中，像個普通同事一樣，直接交付完整的成果，實現人在回路的高效協作編排。

AgentTeams 客戶端

知識沉淀方面， AgentTeams 提供了獨立的 AI Registry 注冊中心，可以統一管理組織的 Skills、MCP Servers、Agents、Team Templates，形成跨聊天、跨個體、跨部門的復用，并支持版本管理、安全審查、熱加載。

對照組織管理學的基礎理論，AgentTeams 已經解決了組織的邊界以及具體管理流程問題；那么，層層約束之下，組織又該如何不斷進化？

03

AgentLoop，

如何讓 Agent 持續進化？

當個體聚集成企業，就需要建立組織部或者人力資源部，去建立選拔考評制度，決定群體的資源管理分配標準，才能讓有限的資源不斷發揮出更大的效益。

Agent 組織成 AgentTeams 后，同樣需要一個組織部扛起監察與優化的責任。

在阿里云的Agent Native Cloud 戰略中，承擔這個任務的，是 AgentLoop，一個面向企業級智能體的一站式自進化平臺，可以提供 Agent 全棧觀測與審計、Agent 評估與實驗、Agent 資產管理與持續優化等核心能力，來持續優化企業 Agent 的質量、效率、成本與安全性。

但對于它的效果究竟體驗如何，在正式推出前，團隊一度遇到了非常多的技術挑戰。

因為微服務時代，傳統應用的輸出是確定性的——同樣的輸入必然產生同樣的輸出，質量問題容易復現。

但 Agent 的輸出天然具有隨機性。這次回答得挺好，下次怎么變差了？可能是模型的更換，可能是系統產生了錯誤的記憶，也可能只是模型的一次隨機幻覺，而傳統的 APM 工具對此毫無辦法。再加上，企業級智能體相比通用智能體，容錯空間更小，但由于 Agent 的多步驟執行特性，異常的根源可能隱藏在幾十步甚至百步的某個工具調用中，很難定位。

但阿里向來有推出產品前，內部先 dogfooding 的習慣。過去，神龍服務器、盤古存儲、云原生架構等核心產品，都是先先承載淘寶、天貓雙 11 億級流量、釘釘爆發式擴容等內部極端業務場景，在真實峰值壓力下驗證穩定性、優化性能，打磨成熟后再作為云服務對外輸出。

AgentLoop 也不例外。團隊為它找到的第一個超級場景，就是阿里云內部的實際的產品研發流程。

現如今，借助 AgentLoop，阿里云團隊將需求 → Spec → 代碼 → Review → 測試 → 發布整個端到端鏈路上的多個獨立智能體，進行執行效果的持續優化，從而提升流水線的自動化，人只在關鍵決策點介入：需求澄清、PR 合并、生產發布。

在這個過程中，AgentLoop 提供的，是一套生產環境從觀測、到分析評估，再到優化的完整鏈路。

在觀測分析層面，AgentLoop 能將原子化的觀測指標轉化為 Agent 的完整推理軌跡（Trajectory），端到端還原每一步的輸入輸出、工具調用與執行路徑，在此基礎上實現 Token 成本歸因與全鏈路智能診斷。

在評估層面，AgentLoop 采用 Agent-as-a-Judge 機制，并提供了 20+在主流業務場景下經過工程實戰的開箱即用的評估器 Agent，基于完整推理軌跡進行深度判斷。

AgentLoop 評估能力的控制臺

優化則通過將線上真實數據自動回流為評估數據集，配合 Prompts 和 Skills 等資產，形成持續進化的閉環。過去，阿里云在客戶服務 Agent、Coding Agent、Data Agent 等主流場景積累了大量的進化經驗，并和企業客戶持續共創，如今，這些 FDE 場景下的智能體資產，可以直接反哺到 AgentLoop 的經驗庫中。

周琦總結，過去阿里云團隊在微服務時代就積累了大量治理經驗，從流量管控到穩定性保障，底層邏輯是給不確定性建立確定性的兜底機制。如今升級到 Agent 時代，觀測對象從確定性的 API 接口變成了非確定性的推理軌跡，難度系數更高，但方法論一脈相承。

也正是借助這樣一套架構，AgentLoop 可以把每一次 Agent 運行時產生的日志數據變成自我優化的飛輪，讓所有企業都能獲得阿里云團隊一樣的自動化開發維護體驗。

04

尾聲

為什么 Agent 尚未在企業市場徹底爆發，就需要先為它定好約束與進化規范？

歷史其實早就給出了答案。

1880 年代之后，電力正式從實驗室走向生產，幾乎同一時間，愛迪生為代表的直流電派與特斯拉為代表的交流電派產生了正面對決。

雙方你來我往的對戰中，特斯拉在后來的芝加哥世界博覽會，用十萬盞燈泡照亮了整個會場，向全世界證明了交流電無可撼動的地位；愛迪生也一度為了證明交流電的危險性，在公開實驗中電死了小貓、小狗乃至一頭大象。紐約康尼島月神公園被銅電極擊穿的大象痛苦嘶吼的畫面，已然成為當代科技史上足以載入史冊的公關事件。

于是，此后十幾年里，盡管交流電技術已經成熟，但社會基礎設施與約束遠遠跟不上，很多電線只是用布和瀝青隨便裹一下，老鼠一咬或者墻壁受潮就會引發火災，不同發電廠送來的電電壓也忽高忽低，頻繁燒毀當年還很昂貴的燈泡。導致保險公司不敢承保，居民也始終不敢把電線拉進臥室。

直到 1897 年美國國家消防協會聯合各方制定的第一版《國家電氣規范》，這套標準嚴格規定了室內布線的絕緣材質、電流負載上限與接地規范。它沒有發明任何新技術，但它解鎖了電力的全部潛力。

有了規范，保險公司才敢承保。敢承保，銀行才敢貸款。敢貸款，建筑商才敢把電線設計進每一棟新樓。有了這套標準，交流電才真正走向了全球千家萬戶。

一定程度上，技術能力只決定了一件事能不能做到，而治理與進化體系才決定了它能不能低成本、低風險地復制一萬次。

如今的 AI Agent，正站在這個歷史拐點上。

*頭圖來源：阿里云

本文為極客公園原創文章，轉載請聯系極客君微信 geekparkGO

極客一問

你如何看待AI Agent?