这周最值得流程负责人警惕的，不是哪家厂商又把聊天界面做得更顺，而是哪几家平台突然开始认真管 连接、动作、审批和下线。ServiceNow 在 June 2026 release 里把已批准 MCP servers 的可见性、强制审批和 AI 资产下线写进治理动作；Salesforce 在 6 月 22 日谈 AI-native architecture 时，把 workflow、permissions、trust 放到同一层；微软这两个月一边把 agents plus workflows 往前推，一边把 computer-using agents 放进更正式的企业自动化语境。
这些信号摆在一起，真正说明的不是“Agent 越来越强”，而是 Agent 开始真正摸到生产系统的接线板。一旦它能接 CRM、ERP、工单、采购、合同、邮件、桌面界面，企业要审批的就不再是一个抽象的“Agent 项目”，而是它到底代表谁、能看什么、能改什么、能推进到哪一步。
很多团队今天还在用旧思路治理新东西。项目申请表里写着“做一个法务 Agent”“做一个采购 Agent”，听起来像是在治理，实际上只是在给一个名字盖章。真正危险也真正关键的部分，被放过了：这个 Agent 可以连几条线，哪条线是只读，哪条线能回写，什么动作默认执行，什么动作必须先请人确认。
Agent 进入企业，不是先审批“它像不像一个员工”，而是先审批“它有没有资格碰这条线”。
一、最容易看错的地方，是把“Agent 立项”误当成“Agent 已被治理”
一个名字被批准，不代表一组动作被约束；项目被立项，不代表接线权被产品化。
企业里现在最常见的说法是：“我们准备上线一个报销 Agent”“我们在试一个合同 Agent”“我们要做一个采购 Agent。”这些说法方便沟通，但它们天然会把治理对象说虚。因为真正有风险的，不是“这个 Agent 叫什么”，而是它背后连了哪些系统、调用了哪些入口、拿了谁的身份、在什么条件下能真正执行。
你把这个问题换一种问法，治理焦点马上就会变清楚。不是问“要不要上法务 Agent”，而是问“这个 Agent 能不能读历史争议条款、能不能调用模板库、能不能回写合同台账、能不能触发升级审批、能不能直接给外部回函草稿进下一步”。只要问题落到这一层，组织就不可能再只靠一张模糊项目单放行。
很多企业项目之所以后面越做越慌，就是因为前面批的是一个愿景，后面跑出来的却是一串真实动作。前期演示时大家看到的是问答、摘要、建议、起草，很容易觉得风险可控。等它开始连系统、写字段、触发通知、改状态、发请求，才发现真正需要审的对象从来不是“AI 能不能说”，而是“AI 到底能碰什么”。
二、本周公开动作很一致：平台厂商开始把“接线权”做成正式治理对象
行业这周不是在比谁更会聊天，而是在比谁先把连接器、工作流和审批收进制度里。
ServiceNow 这次最值得盯的，不是一个更花哨的 Agent 演示，而是治理层的动作。它在 June 2026 release 里写到，Agent Studio 只显示已批准的 MCP servers，还支持强制审批和 AI 资产 offboarding。这句话分量很重，因为它默认承认了一件事： MCP server 不只是一个技术接入件，它本身就该是审批对象。谁能看见它，谁能用它，谁离职或项目终止后如何下线，都不该靠口头约定。
Salesforce 6 月 22 日谈 AI-native architecture，也没有把重点放在“对话更自然”上，而是强调 workflow、permissions、trust 和平台中介。这个方向同样说明，企业 Agent 的核心价值正在从前台交互转移到后台受控执行。平台真正要守住的，不是聊天窗口，而是动作经过什么信任边界、带着什么权限去调用工具。
微软 5 月 20 日写 agents plus workflows 时，强调的是把 Agent 放进业务流程，而不是只停留在建议层。紧接着，Copilot Studio 又把 computer-using agents 推到更正式的企业自动化语境里。这个动作背后的含义很直接：当 Agent 不只是调 API，还开始点按钮、读网页、走桌面，你原来躲在接口治理后面的灰区会一下子暴露出来。因为它不再只是在回答，它已经开始摸真实系统的门把手。
三家信号放在一起，行业方向已经很清楚了。下一轮企业竞争，不是做出多少个 Agent，而是谁先把“连接什么能力、继承什么权限、触发什么动作、怎么停下来”写成正式规则。前台体验会越来越同质，后台接线权会越来越稀缺。
三、为什么“接线权”会变成第一审批对象？因为它决定了Agent的真实权力
一个连接器，看上去只是接了个系统，实际接进来的是身份、上下文、数据面和动作面。
当一个 Agent 获得某条连接，它拿到的往往不是一条孤立能力，而是一整段真实工作空间。它可能读到客户级别、合同状态、历史工单、预算余额、发票影像、审批备注、邮件上下文，也可能顺着这条线改字段、发通知、推进流程、创建任务、触发回写。这时候“连上了系统”这句话太轻了，真正发生的是一组权力进入了可自动调用状态。
这就是为什么很多企业对 Agent 总有一种说不清的不安。并不是大家保守，而是他们隐约知道，一旦接线，AI 的身份就从“会聊天的助手”变成了“可以触碰生产对象的代理人”。只不过不少项目还没把这层说清楚，于是组织只能用笼统方式表达担心，比如“先别放太开”“先只做只读”“先别碰审批”。这些话本身没错，但如果不进一步产品化，就永远只能靠人盯着。
真正稳的做法，是把接线权拆开审。每条线都要问五件事：它代表谁接入；能读哪些对象；能写哪些对象；什么条件下自动执行；异常时如何停、如何追、如何下线。只要这五件事写清楚，你会发现很多所谓的“Agent 风险”其实不是模型问题，而是授权对象没有被清晰定义。
四、多数企业今天卡住，不是不会做Agent，而是批错了对象
你如果批的是“一个智能项目”，最后得到的多半是更多灰区；你如果批的是“动作矩阵”，组织才敢真的放权。
很多组织的治理流程还停留在旧软件时代。上一个系统项目时，审批的是预算、需求、供应商、接口改造范围。到了 Agent 时代，项目形态变轻了，入口变快了，甚至几个业务团队自己就能试起来。结果就是：正式制度管的是大项目，真实风险却从小连接、小动作、小工作流里一点点长出来。
这也是为什么你会看到一种很常见的落差。表面上团队说“我们还没放开自动执行”，看起来很谨慎；实际上很多试点已经默认让 Agent 连了知识库、邮箱、表单、桌面界面、内部网页和若干外部站点。它暂时不自动，不代表它不危险。因为连接一旦铺开，后面只要多加几个触发条件和回写动作，它就能从建议层滑进执行层。
所以审批表也该重写了。别再只写“项目名称：采购 Agent；用途：辅助审批”。应该直接写成动作矩阵：可连接的系统列表、只读或可写、代表身份、最大权限、允许触发的工作流、必须人工确认的节点、离线或异常时的停机方式、人员变动时的收回机制。这样批出来的不是一句模糊同意，而是一份机器和组织都能共同遵守的边界。
五、拿合同评审举例，你就能看出“项目审批”与“接线审批”的差别
前者批准了一个想法，后者批准了一套可追责的动作边界。
假设一家企业要做合同评审 Agent。按旧思路，项目申请里通常会写：读取合同文本，结合制度和历史案例，给出风险提示和修改建议。这个申请大多数公司都敢批，因为听起来主要是辅助判断。可一旦业务部门希望它更有用，动作很快就会加上去：调模板库、查供应商履约记录、拉付款条件、比对历史争议、回写台账、提醒业务补件、生成对外修订版本。
这时候，如果你前面只批了“做一个合同 Agent”，组织其实并不知道自己到底放开了什么。可如果你审批的是接线矩阵，情况就完全不同。系统会明确写：模板库只读；台账允许新建草稿但不允许正式生效；供应商履约记录只允许读取指定字段；触发对外版本前必须人工确认；命中高风险条款自动暂停并升级给法务负责人；项目结束或人员变动时，相关连接统一下线。
你会发现，这样的治理并没有让项目变慢，反而让组织更敢往前走。因为真正让企业迟疑的，从来不是 AI 够不够聪明，而是不知道它到底在哪些地方算正式开工。一旦接线权和动作边界清楚，合同评审 Agent 才有可能从“帮你看一眼”升级成“替你先推进一段低风险流程”。
六、企业明天最该做的，不是多上几个Agent，而是先立一张接线审批表
先把线审明白，再谈自治；先把动作分层，再谈提效。
第一步，先把正在试点或计划上线的 Agent 全部拉清单，不按部门分，也不按名字分，直接按“它准备连接什么”来分。第二步，给每条连接加上最基本的动作标签：只读、建议、回写、触发工作流、外发动作、桌面动作。第三步，把高风险节点单独拎出来，规定哪些动作默认人工确认，哪些动作只允许在额度或规则带内自动执行。第四步，把收回机制写进去，特别是人员离岗、项目终止、连接失效、规则变更后的权限回收。
这件事最适合流程团队、信息安全、应用管理和业务负责人一起做。因为它既不是纯技术问题，也不是单纯制度问题。它本质上是在重写一份组织对非人执行身份的授权合同。谁负责开口子，谁负责关口子，谁负责异常接管，谁负责回放追责，这些问题都不能再靠“到时候看”解决。
如果你现在就在推进企业 Agent，我更建议你先挑一条高频、重复、跨角色多、但风险仍可控的链路来做，比如合同草拟后的台账回写、报销单完整性预审、采购单资料补齐、工单分类与派发。别一上来就追求大而全的统一入口。先用一张接线审批表，把一个节点做成，组织心智会比十场路演更快改变。
七、真正会改变组织的，不是Agent数量，而是审批对象从“项目”变成“权力接口”
当企业开始审批接口权力而不是抽象项目，Agent 才真正从概念进入制度。
这件事的现实意义很大。因为它决定了企业接下来是在“更热闹地试用 AI”，还是在“更稳地把 AI 纳入生产”。前一种路径会让组织一直围着聊天入口打转，演示很多，放权很少；后一种路径会逼着团队把权限、工作流、人工接管、异常暂停和资产下线这些底层能力补齐。短期看没那么炫，长期却更接近真正的执行闭环。
能力迁移路径也很清楚。以前流程团队最擅长的是画图、写制度、定节点。接下来更重要的能力，会变成把这些规则翻译成机器可判的接线权限和动作边界。以前安全团队盯人、盯账号、盯系统。接下来还要盯非人身份、盯连接资产、盯动作授权和收回机制。以前业务部门只问“这个 Agent 好不好用”。接下来还得问“它凭什么碰这条线”。
所以今天最值得转发的一句判断是： 企业真正该审批的，不是 Agent 这个名字，而是 Agent 能接哪条线、能动哪种动作。 只要审批对象还停留在项目名词上，治理就会一直滞后于执行能力；只有当审批对象变成权力接口，Agent 才会从“会说话的工具”变成“可追责的执行单元”。
公开信息来源
本轮选题检索完成于北京时间 2026 年 6 月 28 日凌晨。文章中的“接线权正在成为 Agent 第一审批对象”是基于以下公开资料形成的归纳判断。
来源 1｜ServiceNow Community｜June 2026 release
AI Control Tower 更新提到 Agent Studio 仅展示已批准 MCP servers，并支持审批强化与 AI 资产 offboarding，说明连接资产本身正在被正式纳入治理对象。
https://www.servicenow.com/community/ai-control-tower-articles/ai-control-tower-what-s-new-in-the-june-2026-release/ta-p/3561445
来源 2｜Salesforce Blog｜2026 年 6 月 22 日
讨论 AI-native architecture 时，把 workflow、permissions 与 platform-mediated trust 放在同一架构层，说明企业 Agent 的核心竞争点正在转向受治理执行。
https://www.salesforce.com/blog/design-ai-native-architecture-salesforce-headless-360/
来源 3｜Microsoft Copilot Blog｜2026 年 5 月 20 日
Copilot Studio 把 agents plus workflows 作为企业流程自动化重点，表明厂商正在推动 Agent 进入正式工作流，而不是停留在建议层。
https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/automate-business-processes-with-agents-plus-workflows-in-microsoft-copilot-studio/
来源 4｜Microsoft Copilot Blog｜May 2026 updates
Computer-using agents 进入更正式的产品阶段，意味着 Agent 不只调接口，还会直接碰网页与桌面界面，进一步放大了连接与动作治理的重要性。
https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/new-and-improved-computer-using-agents-a-new-workflows-experience-and-real-time-voice-experiences/