过去几年，企业讲审批流自动化，脑子里先出现的还是报销、采购、合同、用章。可最近两个月几家一线厂商公开动作放在一起看，我反而更确定另一件事： 企业下一张真正的新审批流，不在 OA 里，而在 Agent Builder 里。
4 月 10 日，微软在 Copilot Studio 公开讲 agents plus workflows，反复强调让流程保留结构、让 Agent 承担判断，把审计和一致性留在工作流里。4 月 22 日，OpenAI 发布 workspace agents，直接把“何时需要批准、哪些动作要先请示、管理员如何看见每一次配置和运行”写进产品定义。到了这周，ServiceNow 又把 MCP servers、审批、下线、AI inventory 和 agent builder 的可见性强绑在一起，明确说不被批准的连接器，根本不该出现在构建界面里。
这几条信息真正说明的，不是哪家 Agent 更聪明，而是一个老问题开始换地方出现了。以前审批流管的是“人能不能往下点下一步”。接下来审批流更先要管的，是“机器能不能碰这条线、能不能调这个工具、能不能在什么条件下继续跑”。
很多企业还没意识到这一层。它们在立项表里写“做一个销售 Agent”“做一个法务 Agent”“做一个采购 Agent”，看起来已经在治理，实际上只批了一个名字。真正决定风险和价值的东西，往往藏在 Agent Builder 的下拉框里：它能连哪个知识库，能调哪个工作流，能不能发邮件，能不能改 CRM，能不能写台账，能不能直接把某个动作提交出去。
新审批流不是先问“要不要做这个 Agent”，而是先问“这个 Agent 在构建时能看到哪些连接，运行时又能做哪些动作”。
一、为什么我说新审批流先长在 Agent Builder 里
因为真正被放权的，不是聊天窗口，而是构建界面里那一排可连接、可调用、可执行的能力。
你今天去看多数企业 Agent 项目的推进方式，会发现一个很典型的错位。业务部门讨论的是场景，IT 讨论的是模型，安全部门讨论的是权限，流程部门讨论的是节点。四方都没错，但真正把这些东西绑在一起的入口，往往已经从老审批表单转移到 Agent Builder 本身了。一个 Agent 一旦在构建阶段可以看见某个连接器、装配某个工作流、继承某组动作，它后面就不再只是“会回答问题”，而是拿到了某段真实生产能力的门票。
这张门票以前是分散的。接口权限在一个系统里批，流程动作在另一个系统里批，账号授权又在第三个地方批。现在 Builder 把它们收敛到一个地方，企业第一次可以直观看见：哪些能力正在被拼成一个非人执行者。也正因为收敛到了一个地方，审批对象也必须跟着迁移。你不能再只盯运行结果，而不盯构建时到底给了它什么零件。
所以我说新审批流先长在 Agent Builder 里，不是说 OA、BPM、审批引擎不重要了，而是说新的权力入口出现了。过去审批流管人手往下流转，接下来它还得管机器在上游有没有资格被组装成一个能动手的执行单元。
二、最近公开信息已经把方向说得很直白：治理正在前移到构建层
厂商最近最重要的共识，不是“让 Agent 更自由”，而是“让 Agent 的自由先被前置约束”。
微软 4 月 10 日在 Copilot Studio 写得很清楚：Agent 负责推理与适应，workflow 负责结构和一致性，高频和高风险环节需要靠工作流来保住可控性。这个表述的关键不在“Agent 也能进流程”，而在它承认了生产级自动化不能只靠自治，必须把判断和结构配对起来。换句话说，Agent 不是取代流程，而是被流程兜住。
OpenAI 4 月 22 日发布 workspace agents，更进一步把治理写到产品定义里。它强调管理员可以控制哪些 connected tools 和 actions 可被不同用户组访问，敏感动作可以要求先批准，Compliance API 还能看见每个 agent 的配置、更新和运行。这个动作很关键，因为它把审批从“员工是否用工具”推进到“Agent 的动作是否被允许”。对企业来说，这其实就是一张新的动作审批单，只不过不再长得像传统 OA 表单。
而 ServiceNow 这周最值得细看的，是它没有把 MCP 当成一个纯技术话题。公开信息里直接写到：MCP servers 已经被纳入 AI Asset Inventory；AI Steward 可以要求 MCP server 先走正式批准才能被激活；未批准的 server 在 agent builder 里根本不可见；下线、变更、风险分类和历史记录都跟着走。这里的重心已经非常明确了： 审批不是发生在 Agent 运行后，而是发生在 Builder 看见连接器之前。
这三条放在一起，已经不是零散产品功能，而是一条清楚的行业路径。治理正在从“结果出事了再追”往前挪，挪到构建时就把能用什么、不能用什么先锁住。
三、多数企业为什么会失控？因为它们批的是项目，不是构建权限
项目名词太宽，Builder 权限才是机器真正拿到的权力清单。
“合同 Agent”“采购 Agent”“销售 Agent”这些名字在沟通上很方便，但在治理上几乎没什么分辨率。因为同样叫合同 Agent，有的只是读合同、给建议；有的会调模板库、查客户信用、回写合同台账、发起升级审批；还有的已经能代表法务或销售，把对外版本草稿推给下一环。名字一样，权力完全不同。
企业之所以后面越来越紧张，往往不是 Agent 变坏了，而是前面批的对象太粗了。你批了一个场景，却没有批清楚它在 Builder 里到底装上了哪些部件。等试点往前走，大家才突然发现：它其实已经能读预算、能碰 CRM、能发通知、能改状态、能调桌面动作。到这个阶段再补治理，代价就比前面大得多。
真正稳的治理方式，不是给每个 Agent 起更精确的名字，而是给每个 Builder 能力做更精确的边界。哪些连接器默认不可见，哪些工作流只能作为只读工具被调用，哪些动作超过额度必须人工确认，哪些对外发送类动作必须由真人点最后一下，哪些连接在项目结束或人员离岗后需要统一下线。这些边界一旦落在构建层，后面的运行才有真实护栏。
四、如果审批对象改了，流程团队也要改打法
流程团队接下来最值钱的能力，不只是画流程，而是把 Builder 权限翻译成可审、可控、可回收的规则。
以前流程团队最熟悉的是节点、路径、表单、规则。接下来这些能力仍然重要，但还不够。因为你面对的不只是“人按节点流转”，而是“一个非人执行者在构建时被授予什么能力，在运行时如何被约束”。这就要求流程团队把原来对节点和责任链的理解，翻译成另一种更细的治理语言：连接列表、动作矩阵、人工确认点、异常暂停点、回放审计点、资产下线条件。
信息安全团队也会跟着变化。过去更多盯账号、网络、终端和系统接口。接下来还得盯 non-human identity、Builder 可见性、连接器审批、工作流调用面、MCP server 生命周期和日志穿透。安全不再只是守住系统边界，还要守住“谁能把哪些能力装配成一个会做事的 Agent”。
业务负责人同样要改问法。不要只问“这个 Agent 能不能帮我提高效率”，还要问“它是靠什么能力提高效率”。如果答案只是多了几个模板和摘要，那风险和治理压力都有限；如果答案包含访问真实业务对象、触发正式流程、调用外部动作，那你面对的就已经不是一个聊天工具，而是一个开始进入组织责任链的执行者。
五、拿采购场景举例，你会马上明白为什么审批必须前移
采购 Agent 真正危险也真正有价值的地方，不在回答，而在它能不能碰询价、下单、审批和回写。
假设你要做一个采购 Agent。按旧思路，项目申请上通常会写：帮采购同事汇总供应商信息、比对报价、起草建议。这个版本听起来风险不高，因为它主要做整理和建议。可一旦业务部门说“再往前走一步更有价值”，动作马上就会扩展：读取历史采购价、调用规则库、生成询价单、创建采购申请、路由给相应审批人、通知供应商补件、把结果回写 ERP。
这时候，如果你前面只批了“采购 Agent 试点”，组织并不知道自己到底放开了什么。但如果你审批的是 Builder 权限，情况就完全不同。系统会明确写：报价历史只读；ERP 只允许创建草稿，不允许直接生效；外发邮件默认人工确认；超预算或异常供应商直接暂停并升级；项目结束后相关连接自动下线。你会发现，治理不是在拖项目后腿，反而是在帮组织更敢把低风险动作交给机器。
采购只是一个例子。合同、报销、售后工单、主数据维护、客服回访，其实都一样。问题从来不是“能不能做一个 Agent”，而是“能不能在 Builder 层把它的真实权力写清楚”。写清楚了，很多场景反而能更快进入生产。
六、企业现在最该补的，不是更多 Prompt，而是一张 Builder 审批表
先把构建权限审明白，后面的自动化才不会一边跑一边补洞。
第一步，把组织里已经在试的 Agent 按 Builder 能力重新盘一次，不按部门分，不按名字分，直接按“能看到什么连接、能调用什么动作”来分。第二步，把能力拆成最少四层：只读、建议、回写、触发正式流程或对外动作。第三步，给每一层写清人工确认规则，特别是额度外、异常项、涉及客户或外部对象的动作，默认不能静默执行。第四步，把下线机制写进去，人员离岗、项目终止、规则变更、连接失效后，谁负责关、多久内关、日志怎么保留。
这张表最好不是某一个部门单独写，而是流程、业务、信息安全、应用管理一起写。因为它既关乎效率，也关乎责任；既关乎流程结构，也关乎权限真实落地。写完之后，你会发现很多“我们还没准备好做 Agent”的担心，其实不是准备不好，而是以前没有一个合适的审批对象。
从落地路径看，也不必一上来追求全公司统一平台。先挑一条高频、重复、跨角色多、但风险还可控的流程，按 Builder 权限把边界立起来。让一个场景先稳定跑起来，比十个演示版 Agent 更能改变组织认知。
七、真正的组织变化，是审批对象从“业务项目”变成“机器权力”
当企业开始审批机器在构建层能拿到什么权力，Agent 才算真正进入制度，而不是停在试用名单里。
这件事的现实意义很直接。它决定了企业接下来是在“多做几个会聊天的入口”，还是在“逐步建立一套能把机器纳入责任链的生产机制”。前一种路径会一直围着效果演示打转，看起来热闹，真正放权很少；后一种路径会逼着企业把连接治理、动作分层、审计回放、人工接管和资产下线补完整。短期没那么炫，长期却更接近真正的 Agent 落地。
能力迁移路径也已经很清楚。流程团队要从画流程图，走向定义机器可执行边界；安全团队要从管账号和接口，走向管 Builder 可见性和非人身份；业务团队要从提场景需求，走向定义哪些动作真值得交给机器先做；平台团队要从堆功能，走向把审批、审计、收回做成基础设施。
所以今天这篇文章真正想证明的是： 企业下一张新审批流，不在 OA 里，而在 Agent Builder 里。谁先把 Builder 里的连接、动作、确认和下线做成正式规则，谁才更可能把 Agent 从演示台带进生产线。 接下来真正拉开差距的，不是你能做出多少个 Agent，而是你有没有能力把机器的权力先审批清楚，再放心地让它开始干活。
公开信息来源
本轮选题检索完成于北京时间 2026 年 6 月 29 日凌晨。文章中的“新审批流正在前移到 Agent Builder”是基于以下公开资料形成的归纳判断。
来源 1｜Microsoft Copilot Blog｜2026 年 4 月 10 日
《Automate business processes with agents plus workflows in Microsoft Copilot Studio》强调 agents 负责推理与适应，workflows 负责结构、一致性和审计，并展示让 workflow 调 agent、让 agent 调 workflow 的双向模式。
https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/automate-business-processes-with-agents-plus-workflows-in-microsoft-copilot-studio/
来源 2｜OpenAI｜2026 年 4 月 22 日
《Introducing workspace agents in ChatGPT》明确写到组织可控制 connected tools 与 actions 的访问范围，敏感动作可要求批准，Compliance API 可查看 agent 的配置、更新与运行记录。
https://openai.com/index/introducing-workspace-agents-in-chatgpt/
来源 3｜ServiceNow Community｜2026 年 6 月 23 日左右发布，本周更新
《AI Control Tower: What's new in the June 2026 release》写明 MCP servers 已被纳入 AI Asset Inventory，AI Steward 可要求正式批准后才允许激活；未批准的 server 在 AI Agent Studio 中不可见，且支持下线、变更、风险与生命周期治理。
https://www.servicenow.com/community/ai-control-tower-articles/ai-control-tower-what-s-new-in-the-june-2026-release/ta-p/3561445