2026 年的企业软件采购会议上，很少有人再问“要不要上 AI Agent”，问题已经变成了“怎么防止 Agent 失控”。这个转变本身就说明了问题：采用速度已经远远跑在了治理能力前面。OutSystems 发布的 2026 年度 AI 开发现状报告把这个反差量化得很清楚：96% 的企业已经在不同程度地使用 AI Agent，但只有 12% 建立了统一的管理平台来管控这些 Agent，中间的空白，就是这篇文章要谈的“蔓延”。
Gartner 预测，到 2028 年，一家典型的《财富》500 强企业平均会运行多达 15 万个 AI Agent（2025 年这个数字还不到 15 个），治理能力完全跟不上这个增速。
协议层的狂飙，让蔓延变得更容易
这一轮 Agent 浪潮能跑这么快，很大程度上得益于协议层的成熟。Model Context Protocol（MCP，一套让 AI 模型能够标准化地调用外部工具和数据源的通信协议）在短时间内积累了大量公开的 MCP Server（也就是遵循这套协议、可以被模型直接调用的外部服务接口），并被集成进 ChatGPT、Cursor、Gemini、Microsoft Copilot 和 VS Code。而 Agent2Agent 协议（简称 A2A，一套让不同厂商的 Agent 之间能互相发现、互相调用的协议），基于 JSON-RPC 2.0（一种轻量级的远程调用通信格式）和 HTTPS 传输，用“Agent Card”（描述一个 Agent 具体能做什么、边界在哪里的说明文件）来声明每个 Agent 的能力边界，已经有多家主要云厂商参与支持。这意味着，不同厂商、不同框架的 Agent，第一次可以用一套标准化的方式互相发现、互相调用。生态的开放是好事，但它也意味着一个企业内部可能同时存在几十个来自不同供应商、遵循不同协议版本、权限模型完全不统一的 Agent，彼此之间几乎没有一个统一的审计视角——协议越标准化，Agent 越容易被随手拼接进工作流，蔓延的门槛反而更低了。
蔓延，才是真正的风险，而不是采用本身
问题的根源往往不是某个 Agent 本身写得不好，而是企业根本不知道自己到底跑了多少个 Agent、它们各自能访问哪些系统、谁批准过它们的权限。一个客服团队引入的 Agent 可以读取工单系统，一个财务团队引入的另一个 Agent 可以调用发票接口，两者分别看都合理，但当它们都被允许写入同一个 CRM 字段时，没有人能预判会发生什么。更现实的情况是，很多 Agent 根本没有经过正式批准，而是某个团队顺手接入的一个插件，半年后已经没人记得它还在运行。
这个领域里一个越来越常见的说法是：企业现在要问的已经不是要不要用 Agent，而是三个月后，还有没有人知道自己到底授权了多少个 Agent。
答案不是减速，而是把架构收回自己手里
面对蔓延，大多数企业的本能反应是收紧审批流程，给每个新 Agent 加一道人工审查。这能缓解症状，却治不了病根，因为问题从来不是“批准得不够严”，而是这些 Agent 本来就散落在几十个互不相通的 SaaS 工具里，各自维护独立的记忆、独立的权限、独立的日志。前面提到的采用率与治理率之间的鸿沟，靠加审批流程是补不上的，因为审批只能挡住新 Agent，挡不住已经跑了一年、没人记得的旧 Agent。真正可持续的解法，是把 Agent 的执行环境和记忆收回到一个你自己能审计的工作空间里，无论是单个任务型 Agent，还是多 Agent 编排，所有的调用记录、权限边界和记忆存储都在同一套可观测的系统里完成，而不是分散在供应商各自的黑箱后台。这正是主权 AI Agent 工作空间存在的意义：不是让企业用更少的 Agent，而是让企业第一次能看清自己到底在用多少个 Agent，以及它们各自在做什么。