这两周最值得流程负责人警惕的，不是谁又接通了几个 MCP Server，而是谁开始认真讨论 Agent 的身份、工具边界、调用策略、审计路径和预算约束。6 月 18 日，微软把 Copilot Control System 放到前台，明确说要把 Agent 当成需要治理、保护和度量的对象；6 月 22 日，Salesforce 讨论 AI-native architecture 时，把 trusted agent identity、workflow 和 platform-mediated trust 写进同一套架构；Databricks 6 月直接把文章标题写成 governing coding agent sprawl，并把 Unity AI Gateway 拉到治理一线；ServiceNow 则在 5 月把受治理的 workflows、approvals、playbooks 接给 AI Agent。
这些公开动作放在一起，其实在说一件更尖锐的事：行业已经不是在比“谁能接更多工具”，而是在比“谁能把 Agent 当成正式资产管起来”。如果企业现在还在用“先接上再说”的思路扩 MCP，短期看会很热闹，长期看很容易养出新一代影子 IT。
很多团队今天对 MCP 的兴奋，和当年对 SaaS 自助采购、RPA 野生扩张、低代码无序搭建的兴奋很像。入口变便宜，接入变简单，试用变顺手，于是大家默认“接上了就等于能力扩展”。问题在于，一旦 Agent 能跨系统读写、调工具、触发动作，它就不再只是一个会聊天的入口，而是一个会留下权限后果的执行主体。
真正危险的不是 Agent 会不会用 MCP，而是企业还没建立 Agent 台账，就让它带着工具链在系统里到处跑。
一、最该先纠偏的误区，是把“接通MCP”误当成“Agent已经可管可用”
工具接通只解决了“能不能连”，没有解决“谁在连、连了什么、出了事怎么算”。
这段时间不少团队一谈 Agent 落地，第一反应就是列一个 MCP 清单：接知识库、接 CRM、接工单、接 ERP、接邮件、接文档、接数据库。演示上这当然非常有冲击力，因为一旦工具多起来，Agent 的可见能力会陡然上升，看上去像是一下子从聊天助手进化成了数字员工。
问题是，MCP 解决的是能力暴露和能力调用，不自动解决资产治理。Agent 连上工具之后，谁是责任主体，继承的是谁的权限，能调用哪些动作，什么时候必须停，哪些数据不能拿，哪些输出不能写回，失败后谁接管，这些都不会因为“协议标准化”就自动变得清楚。标准接口让接入变简单，但也让无序扩张变得更简单。
所以今天企业最危险的误判，不是低估协议，而是高估协议。MCP 能让工具更容易被调用，却不能替企业决定这批工具该不该被调用、由谁调用、在什么边界内调用。没有台账，你看到的是接入速度；真正累积起来的，是治理债务。
二、这轮公开信息已经很明确：头部厂商开始把Agent当资产管，不当插件管
几家平台同时强调治理、身份、策略和可见性，说明行业已经意识到 Agent 蔓延本身就是管理问题。
微软在 2026 年 6 月 18 日写 Copilot Studio 更新时，把 Copilot Control System 定义成治理、保护和度量 AI 的统一控制平面，并强调 IT 团队需要看到 AI 的生命周期。这句话背后的变化很大，因为它默认 Agent 不是一个“功能开关”，而是一个要持续运维的对象。
Salesforce 6 月 22 日谈 AI-native architecture 时，把 trusted agent identity、workflow、platform-mediated trust 和 MCP server 放在同一条逻辑里。更关键的是，它明确提出要用 custom named query 限制读什么、用 least privilege 限制能做什么。这等于公开承认：如果 Agent 能经由标准接口去碰企业系统，那权限设计必须前置，不然标准化只会放大风险半径。
Databricks 6 月直接把话说穿了。它讨论的不是“如何多做几个 Agent”，而是“如何治理 coding agent sprawl”。当一家平台开始把 sprawl 这个词写进正式文章，本身就说明企业内部已经出现了 Agent 无序扩张、难盘点、难审计、难控费的问题。
ServiceNow 5 月把 approvals、flows、playbooks、catalogs 这些受治理工作开放给 AI Agent，同时配上 Control Tower、身份验证和审计。这个动作的意义不是“系统终于支持 Agent”，而是“只有受治理的工作，Agent 才能被允许进入”。四家厂商的共同信号非常一致：Agent 数量不是关键，正式台账才是关键。
三、多数企业为什么还卡在L1？因为它们接的是工具，不是登记的是责任
会接 MCP，不等于会运营 Agent。真正卡住落地的，通常不是协议，而是责任边界没有被正式登记。
如果按成熟度来看，L0 是人工阶段，大家还在手工切系统、查资料、转消息；L1 是会话增强阶段，Agent 能答、能找、能总结；L2 是工具接入阶段，Agent 能查系统、能调动作、能回写字段；L3 才进入台账治理阶段，每个 Agent 的身份、工具、数据范围、预算、升级规则和人工接管开始被统一登记；L4 则是运营闭环阶段，系统能跨 Agent 做策略下发、风险拉闸、行为回放和资产盘点。
很多项目看上去已经很先进，是因为它们演示时会展示一串很长的工具链：今天接 CRM，明天接财务系统，后天再接邮件和知识库。问题在于，工具接入表不是资产台账。前者只告诉你“技术上能不能连”，后者才告诉你“业务上该不该连、由谁来连、连完后谁负责”。
所以多数企业真正卡住的原因，不是 Agent 太少，也不是模型太弱，而是组织里开始出现一批没有清晰归属、没有统一指标、没有风险分级、没有退场机制的野生 Agent。它们短期看像创新，长期看像影子 IT。因为没人能说清到底有多少个、在帮谁做事、碰过哪些系统、花了多少钱、造成过什么后果。
四、一套能落地的Agent台账，至少要登记五类关键对象
台账不是做给审计看的表格，而是企业决定能不能继续放权的最小治理单元。
第一类是 身份对象。这个 Agent 代表谁工作，是个人代理、岗位代理、部门代理，还是只能做局部动作的受限代理。身份不清楚，后续所有权限讨论都会变成空话。
第二类是 工具对象。它连了哪些 MCP Server、能调用哪些能力、这些能力是只读、可建议还是可写回。企业最容易出事故的，不是工具太少，而是“顺手全接上了”。
第三类是 数据对象。它能看哪些数据，能不能跨客户、跨项目、跨地域，哪些字段必须脱敏，哪些结果不能被二次扩散。标准接口打通之后，真正要补的不是更多连接器，而是更细的数据边界。
第四类是 动作对象。它可以生成建议，还是可以真实触发工单、改状态、发通知、提审批、下指令。很多团队把“能调用工具”误听成“能执行动作”，这是两件完全不同的事。
第五类是 运营对象。这个 Agent 谁负责、看什么指标、预算上限是多少、什么时候升级、什么时候下线、什么时候收权。没有退场机制和运营指标，所谓台账就只是一次性登记，不是可持续治理。
五、拿合同评审举例，你就能看出“接了MCP”和“建了台账”的差别
前者让 Agent 能碰系统，后者才让组织敢让它碰系统。
假设销售提交一份非标合同，希望 Agent 帮忙做初筛。如果只是接了 MCP，Agent 很快就能读合同模板、调历史案例、查客户信息、调回款记录，甚至起草一版法务意见。演示效果会很好，因为材料一瞬间就全了，判断也显得很像一个熟练员工。
但真正让法务和业务放心的，不是“它看得多快”，而是“它有没有在台账边界里工作”。这个合同评审 Agent 代表的是销售本人、法务岗位还是共享审单岗？它能调用的是只读条款库，还是能修改审批状态？它能看到的是当前客户，还是所有客户？命中高风险条款时是自动退回、升级法务，还是只给建议？这些问题如果没有登记在台账里，所谓智能化只是把潜在风险移动得更快。
一旦台账补齐，情况就完全不同。Agent 可以被限制为只读历史案例，只允许生成风险摘要；或者只在低风险合同里自动补件和推进节点；又或者在特定额度内代共享岗位发起标准化复核。这样组织交出去的不是模糊信任，而是写清边界后的有限授权。真正可持续的放权，永远发生在台账之后，不发生在演示之前。
六、企业明天该怎么做？先别冲着接入数冲业绩，先把台账立起来
Agent 台账不是最后补的治理文档，而是所有扩接动作的前置门槛。
第一步，先拉一张最小台账，不求完美，先把现有 Agent、负责部门、目标场景、连接工具、数据范围和真实动作列出来。第二步，给它们做风险分级，区分只是问答、可以建议、可以触发低风险动作、可以推进正式流程这几层。第三步，只允许台账内的 Agent 扩接新 MCP，并且要求新增接入必须写明用途、边界、预算和退场条件。第四步，挑一个低风险场景做治理试点，比如合同初筛、报销补件、工单分流或知识检索，把接入、审计、暂停、回退和人工接管一起跑通。
这条路径看上去不如“本周又接了多少系统”那么热闹，但它更接近企业真正要的结果。因为企业需要的不是一堆会调工具的 Agent，而是一批能被看见、能被解释、能被约束、能被下线的正式资产。没有台账，扩接速度越快，后续收权成本越高。
七、真正会改变组织的，不是你接了多少MCP，而是你有没有能力给Agent立账、审账、收账
企业 AI 的下一阶段，不是“人人都能接工具”，而是“每个 Agent 都要像一项正式资产那样被管理”。
这件事的现实意义已经摆在眼前。微软开始讲统一控制平面，Salesforce 开始把最小权限和命名查询前置，Databricks 开始正面讨论 Agent sprawl，ServiceNow 只让受治理工作进入 Agent 运行面。外部平台都在逼企业接受一个现实：Agent 不再只是体验层的新入口，它正在变成有权限、有成本、有审计后果的新型数字资产。
能力迁移路径也很明确。接下来最值钱的，不是谁先把公司所有系统都接上，而是谁先形成一套台账机制：知道自己有哪些 Agent，它们代表谁工作，碰过什么系统，依赖什么工具，能做到哪一步，花了多少钱，出了问题怎么停。只要这套机制没有建立，组织表面上是在推进 Agent，实际上是在积累下一轮影子 IT。
所以今天最值得转发的一句判断是： 没有 Agent 台账，MCP 接得越快，影子 IT 来得越快。 真正成熟的企业，不会把“接上”当成终点，而会把“立账、分级、约束、回放、退场”当成新起点。你明天最该做的，不是再接一个新工具，而是先盘清已经在跑的那批 Agent。
公开信息来源
本轮选题检索完成于 2026 年 6 月 26 日（北京时间）。文章中的“没有 Agent 台账，MCP 很容易演变成新一代影子 IT”是基于以下公开信息形成的归纳判断。
来源 1｜Microsoft Copilot Blog｜2026 年 6 月 18 日
微软把 Copilot Control System 定义为治理、保护和度量 AI 的统一控制平面，并强调 AI 的生命周期可见性，说明 Agent 正在被当成正式运营对象管理。
https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/new-and-improved-agent-governance-intelligent-workflows-and-connected-app-experiences/
来源 2｜Salesforce Blog｜2026 年 6 月 22 日
Salesforce 在 AI-native architecture 文章中把 trusted agent identity、workflow、platform-mediated trust 与 MCP server 放进同一结构，并强调 custom named query 与 least privilege。
https://www.salesforce.com/blog/design-ai-native-architecture-salesforce-headless-360/
来源 3｜Databricks Blog｜2026 年 6 月 26 日
Databricks 直接讨论 governing coding agent sprawl，并把统一网关、策略、可观测性与预算约束放到治理主线，说明 Agent 无序扩张已成为现实管理议题。
https://www.databricks.com/blog/governing-coding-agent-sprawl-unity-ai-gateway
来源 4｜ServiceNow Newsroom｜2026 年 5 月 7 日
ServiceNow 把 approvals、flows、playbooks、catalogs 等 governed work 开放给 AI Agent，并配套 Control Tower、身份验证与审计，强调只有受治理工作才适合被 Agent 接手。
https://newsroom.servicenow.com/press-releases/details/2026/ServiceNow-opens-its-full-system-of-action-to-every-AI-Agent-in-the-enterprise/default.aspx