北京
你問基礎設施團隊：我們現在跑著多少臺虛擬機？他們能直接報個數。問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.
