2026/08/20Don’t Let Every Department Build AI in Isolation
人工智慧與機器學習｜約沛科技｜2026/08/20
企業導入 AI Agent 最容易遇到的問題，可能不是員工不願意使用，而是大家都開始使用得太快。當客服、財務、工程、業務與各地分公司分別建立自己的 Agent，企業很快就會面對另一種形式的資訊孤島：每個 Agent 各自保存憑證、串接系統、設定權限，也重複開發相同的能力。AGCO、Microsoft 與 Amazon Web Services 的最新實務顯示，企業若要讓 Agent 從零星試驗擴展成真正的營運能力，就必須建立一套共用的人工智慧基礎設施。
2026 年，美國農業機械製造商 AGCO 在推動企業人工智慧時遇到了一個很多公司都會羨慕的問題：員工對 AI Agent 的興趣遠超出預期。在一場約 2,200 人參與的主管與員工會議中，公司詢問誰願意開始學習建立 Agent，當場有約 900 人舉手。之後這個內部建立者社群又擴大到約 2,000 人，公司陸續產生數百個由員工或團隊建立的 Agent。
AGCO 並沒有把這股熱情當成單純的工具採購計畫。管理團隊很早就意識到，如果每個員工都自行尋找工具、各自連接公司資料，最後很可能只是把過去的 Shadow IT 換成新的 Shadow AI。AGCO 因此讓員工提出工作上的摩擦點，再由人工智慧團隊與專家共同把需求轉化成適合的 Agent、流程或自動化；公司刻意建立的是一套可以讓多個 Agent 持續加入的框架，而不是一連串互不相干的小專案。
這種做法已經開始影響 AGCO 的製造與品質管理流程。過去有些品質與保固案件可能需要數週甚至數月，由少數專家在多個團隊之間整理資訊、驗證資料與協調下一步；導入 Agent 後，公司希望讓人工智慧負責把不同系統中的資訊帶進同一個流程，使問題可以更快被閱讀、驗證並往下一階段推進。真正的價值不是某一個聊天機器人回答得多快，而是整個組織開始建立可以重複使用的 AI 能力。
同樣的問題正在其他大型企業出現。Microsoft 將快速增加的 Agent 描述成新的企業工作負載，Amazon Web Services 則直接指出，當企業開始擁有數百甚至數千個 Agent 時，會出現三個核心問題：看不見目前有哪些 Agent、無法一致管理哪些能力可以對外提供，以及不同團隊反覆建立已經存在的功能。AWS 因此在 2026 年推出 Agent Registry，試圖讓企業能集中發現、分享與管理 Agent、工具與能力。
這些案例透露出一個重要的轉折。企業人工智慧的第一階段，競爭的是「誰可以比較快做出一個 Agent」；到了下一階段，真正的問題會變成「公司怎麼讓第一百個 Agent 仍然可以快速、安全地建立」。當 Agent 數量開始增加，單一產品的好壞不再是唯一問題，架構本身會開始決定擴展速度。
從員工自發創新到 Agent Sprawl
企業的人工智慧採用通常不會一開始就失控。第一個客服 Agent 可能只需要串接客戶關係管理系統；第二個財務 Agent 連接企業資源規劃系統；工程部門另外建立程式開發 Agent；行銷部門再自己採購一套工具。每個專案單獨來看都合理，而且往往可以在短時間內證明價值。
問題是在這些 Agent 逐漸增加之後，每個團隊會開始重複處理完全相同的事情。每個人都要研究怎麼登入公司系統、如何保存憑證、怎麼描述 API、怎麼留下操作紀錄、如何控制權限。原本希望人工智慧消除重複工作的企業，反而在「建立人工智慧」這件事情上製造了大量重複工作。
Amazon Web Services 把這種情況稱為 Agent Sprawl，也就是 Agent 數量快速增加，卻缺乏共同的盤點、治理與重用機制。AWS 在介紹 Agent Registry 時指出，如果沒有中央目錄，團隊很容易因為不知道其他部門已經做過類似能力，而重新建立另一套 Agent 或工具，最後增加維護成本與技術債。
AGCO 的經驗正好顯示另一條路。公司沒有阻止員工建立 Agent，而是建立一個從個人試驗逐步進入企業正式環境的治理路徑。員工仍然可以快速嘗試，但較大型、會影響企業流程的 Agent 則由中央團隊與專家共同協作。這種模式讓創新保持分散，基礎設施與治理則逐漸集中。
重新定義企業 AI 基礎設施
企業要解決 Agent Sprawl，並不代表所有 Agent 都必須由一個中央人工智慧部門開發。這種做法很可能又回到傳統資訊專案的瓶頸：每個部門有任何需求都排隊等待資訊部門，最後中央團隊永遠做不完。真正需要集中管理的，不是「誰可以做 Agent」，而是大家重複需要的底層能力。
例如身分驗證、權限管理、憑證保存、企業工具目錄、連線方式、流量控制、稽核紀錄與監控，都沒有必要由每一個 Agent 團隊重新開發。這些能力越標準化，事業單位就越能把時間花在真正有差異的地方，例如業務流程、提示詞、資料品質、人機分工與使用者體驗。
Microsoft 在自己的 Agent 管理實務中也開始採取類似方向。Microsoft Digital 使用中央控制層來了解不同平台建立的 Agent，由誰建立、誰能使用以及可以存取哪些資料；管理者不必在多套系統之間逐一尋找 Agent 的狀況。這種中央可觀測、分散創新的模式，很可能會成為企業 Agent 架構的重要特徵。
定義這個共同控制層
從目前大型企業與雲端平台的架構來看，共用的人工智慧基礎設施通常不會是一個單一產品，而是一組位在 Agent 與企業系統之間的共同服務。不同企業可以依既有架構把它放在不同位置，例如：
- 企業人工智慧平台，由中央資訊或人工智慧團隊維運
- API Gateway 或 MCP Gateway 類型的共用連線層
- 身分與存取管理平台
- Agent Registry 或企業工具目錄
- 跨部門的人工智慧治理與可觀測平台
無論採用哪一種產品或組織方式，它們的目的都很接近：把每個 Agent 都需要重新解決的問題抽出來，變成公司可以重複使用的能力。Amazon Bedrock AgentCore Gateway 就是一個具體例子，它讓 Agent 透過單一安全入口連接工具、其他 Agent 與模型，並集中處理進站與出站驗證、OAuth、憑證保存、工具整合與稽核能力。
一個成熟的企業 AI 共用層，通常需要負責以下工作：
- 建立企業可用 Agent、MCP Server 與工具的共同目錄
- 統一處理 Agent 與使用者身分
- 管理企業系統所需的 API Key、OAuth Token 與其他憑證
- 控制哪些 Agent 能夠呼叫哪些工具
- 留下每一次工具使用與系統操作的稽核紀錄
- 提供流量、成本、錯誤、效能與異常行為的監控
- 建立正式上線、版本更新、停用與生命週期管理機制
企業有了這一層之後，Agent 的開發方式就會出現很大的改變。開發者不必再問「我要怎麼重新串一次企業資源規劃系統」，而是問「公司現在已經提供哪些可以使用的能力」。這個差異看似只是少寫一些整合程式，實際上卻決定了一家公司能不能從十個 Agent 擴展到一百個 Agent。
好的 AI 基礎設施具備哪些特質
我們觀察目前 Microsoft、Amazon Web Services、Google 以及 MCP 生態系的發展後，可以看到企業共用基礎設施逐漸形成幾項共同特徵。這些能力與單一模型的推理能力不同，並不會因為半年後換了另一個大型語言模型就失去價值：
- 模型中立：企業底層能力不應綁死在某一個模型。今天可以使用 OpenAI，明天可以加入 Claude、Gemini 或自建模型，而企業系統不必全部重做。
- 工具可重用：同一個「查詢客戶」「建立工單」「取得庫存」能力應該可以被不同 Agent 使用，而不是每一個 Agent 各自重新串接。
- 身分一致：Agent 不論由哪一個平台建立，都應該能被企業辨識、授權與追蹤。Microsoft Entra Agent ID 已經朝這個方向發展，並支援非 Microsoft 平台建立的 Agent。
- 治理集中、創新分散：事業單位仍可以自行建立符合需求的 Agent，但安全、權限、資料與稽核政策應由共同平台提供。
- 完整可觀測性：企業除了知道模型用了多少 Token，還必須知道哪個 Agent 使用哪個工具、成功率多少、發生哪些錯誤，以及實際產生多少商業價值。
- 可替換與可擴充：企業增加新的 Agent 平台、新系統或新工具時，不應該造成整套架構重新改寫。
這種設計特別重要，是因為人工智慧模型的變動速度遠高於企業核心系統。客戶關係管理系統、企業資源規劃系統與內部資料庫可能使用十年以上，但企業使用的模型供應商可能一年內就改變數次。如果企業把所有企業整合直接寫死在某個模型供應商的 Agent 裡，每一次平台策略改變都會形成重新開發成本。
所以，真正長期有價值的不是「公司今天用了哪個模型」，而是企業逐漸累積的工具、權限、資料治理與流程能力。模型可以換，Agent 可以換，甚至 Agent 平台也可以換；企業真正不希望一直重做的，是後面那一整套公司自己的能力。
如何建立企業共用的 Agent 平台
企業建立這套架構時，不需要第一天就打造一個龐大的「人工智慧作業系統」。比較合理的方式，是從目前重複發生最多的整合問題開始。例如，當三個不同團隊都開始需要查詢客戶資料，就應該思考能否把「查詢客戶」變成共同能力，而不是再讓第四個團隊重新串一次客戶關係管理系統。
第二步，是建立 Agent 與工具的清冊。企業需要知道目前有哪些 Agent 已經存在、有哪些工具可以使用、負責人是誰、哪些仍在正式環境運作。AWS Agent Registry 就是針對這個問題發展的中央目錄：使用者與 Agent 都可以搜尋已存在的 Agent、MCP Server、工具與能力，避免不必要的重複開發。
第三步，是把憑證與權限從 Agent 本身抽離。如果每一個 Agent 都保存自己的企業系統密碼、API Key 或 Token，公司很難管理撤銷、更新與稽核。Gateway 類型的架構可以讓 Agent 只知道「我要呼叫某個工具」，真正連往後端系統所需的企業憑證則由共用層安全管理。AWS AgentCore Gateway 已經將這類 Secure Credential Exchange 與 OAuth 管理列為核心能力。
第四步，是建立低風險 Agent 的快速通道。只要使用企業已核准的工具、資料與身分機制，而且沒有高風險動作，團隊就可以比較快把 Agent 推進正式環境；需要接觸新的敏感資料、付款、刪除或不可逆操作時，再進入更嚴格的審查。這種風險分級會比「所有 Agent 都一律送資訊部門審查」更能兼顧速度。
最後，企業必須建立共用的衡量方式。某一個 Agent 為員工節省多少時間只是其中一個指標；更重要的是，企業是否開始減少重複整合、新 Agent 上線時間是否縮短、既有 Tool 的重用率是否提高、事故能否快速追蹤。當平台開始讓下一個 Agent 比上一個更容易建立時，企業才真正累積了人工智慧的組織能力。
AI 基礎設施競賽正在快速升溫
這個領域之所以值得企業現在就關注，是因為大型科技公司已經開始從「提供模型」往「提供 Agent 基礎設施」延伸。Microsoft 建立 Agent 365 與 Entra Agent ID；Amazon Web Services 建立 AgentCore Gateway 與 Agent Registry；Google Cloud 則開始提供企業級 MCP Server 與相關治理能力。這顯示市場的焦點已經從單一模型競賽，進一步延伸到誰可以管理大量 Agent、工具與企業系統。
對企業來說，真正值得投資的因此不是某一個 Agent 專案本身，而是一套可以持續吸收新模型、新工具與新工作流程的架構。今天建立的客服 Agent 可能兩年後就被另一套產品取代，可是它背後使用的客戶資料、權限規則、客服政策與企業工具，仍然是公司的長期資產。
企業的人工智慧成熟度，最後可能不會由「有多少 Agent」決定，而是由「新增一個 Agent 有多容易」決定。當每個部門各自養一隻 AI 時，公司得到的是許多人工智慧專案；當資料、工具、權限與治理可以被反覆重用時，公司才真正開始建立自己的人工智慧基礎設施。
