你問基礎設施團隊:我們現在跑著多少臺虛擬機?他們能直接報個數。問Kubernetes集群的規模?他們會指向監控面板。可一旦你問起AI代理的盤存清單,回答往往變成一場關于“什么叫代理”的討論。而這個討論本身,就是問題所在。
這不是某個工程師的疏忽,而是一類結構性困境——在還沒統一“代理”的定義前,任何組織都無法開始清點。如今大多數企業都沒邁過這道坎。現實中,那些似是而非的例子并不是實驗室里的邊緣案例,它們大多已經在中型企業的生產環境里實際部署。問題在于,組織正在做“是否維護清單”的決策,卻連自己到底要清點什么都還沒達成共識。
![]()
基礎設施團隊的人翻開手里的資產臺賬,虛擬機的條目整齊排列,每一臺都有申請流程、分配審批、追蹤系統和成本分攤模型的痕跡。容器到來的方式也是類似的:平臺團隊事先搭好了Kubernetes集群、命名空間、資源配額和準入控制器,工作負載還沒落地,清單系統已經就位。兩種模式里,庫存體系都跑在了工作負載的前面。可輪到AI代理,故事完全翻篇了。代理不是沿基礎設施采購路徑進來的,它溜了后門。
業務用戶在用Copilot Studio搭工作流,自動化團隊在n8n和Zapier里編集成,開發者把LangChain服務接進內部工具,提示工程師通過MCP把模型連到生產數據源,SaaS廠商則在企業早已買下的軟件里激活代理能力——代理就這樣從四面八方涌入。沒有一條路徑需要基礎設施團隊的介入,也沒有任何一步觸發了附帶清單要求的采購流程。結果,這些代理堂而皇之地跑在基礎設施團隊所管理的環境里,卻全是利用治理缺口鉆進來的。
好多組織盤點不出代理,不是因為沒有代理,而是他們至今仍把代理歸在“工作流”這一類目下。每天早上定時運行的匯總任務,從三個內部系統抽取信息、生成摘要貼進Slack——這就是一個代理。那個讀取工單請求、判斷嚴重等級、分配隊列、把邊緣案例升級處理的工單分類流——這也是個代理。檢查供應商合同是否合規、標記續約風險的采購助手——這還是代理。每個都是由團隊搭建的,而搭建它的團隊會說這只是“自動化”。但在架構層面,這個叫法差異非常關鍵:工作流執行的是固定的步驟序列,而代理則引入了決策與工具調用的自主性,前者可審計,后者卻往往游離在視線之外。
分類上的失敗并非頭一回出現。早年,依賴關系分類不清,催生了VMware依賴審計的難題。基礎設施分類模糊,衍生出影子控制平面的說法。而今天,權限分類的失效,正借由MCP工具鏈被暴露出來。眼下這個代理不清的困境,不過是同一類失敗在AI基礎設施架構新一層里的重演:組織沒把這個類別定義清楚,自然也就無法彌合裂隙。說到底,只有當企業愿意坐下來,先把“到底什么算一個代理”講明白,才談得上盤存。否則,每次提問,得到的永遠只會是關于定義的新一輪爭論。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
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.