企业的 OA 里，审批是最常见的工作入口之一。请假、采购、立项、报价、合同、信息变更……很多事情进入系统之后，最后都会变成一张表和一条审批流。

于是到了 AI 时代，一个很自然的需求出现了：能不能让 Agent 帮我填审批、催审批，甚至自动处理一部分审批？

看起来，这是一个典型的效率问题。但如果真的准备让 Agent 接手这些流程，会先遇到一个更基础的问题：OA 里今天被叫作“审批”的这些东西，真的都是审批吗？

这其实也是一个更普遍的 workflow 问题。业务长期通过固定流程被表达以后，我们很容易把系统中的节点和顺序当成业务本身，而忘了继续追问：这些节点为什么存在，它们分别承担了什么作用？

一条审批流，可能只是把不同业务动作压成了同一种界面

传统 OA 很擅长把业务表达成一种固定结构：

填写表单 → A 处理 → B 处理 → C 处理 → 流程结束。

问题在于，真实业务并不是按“表单”和“节点”组织的。

例如一张报价申请单，看起来可能是销售填写需求，负责人审批，然后进入报价环节。但从业务对象来看，真正发生的事情更接近：客户产生报价需求，企业据此形成报价方案，再对方案中的价格、利润、交期或特殊条款作出必要判断，最后向客户输出报价。

“报价申请单”只是把这几个过程暂时装进了一张表里。需求和报价方案其实是两个不同的对象，所谓审批节点也并不是业务天然存在的一步，而只是其中某些判断被系统表现成了“同意 / 不同意”。

其他流程也类似。一张立项申请通过，真正发生的是项目被创建；一张信息变更单完成，真正发生的是某个已有对象的状态或属性被修改；有些所谓审批甚至只是要求某个人知晓一件事，并没有任何需要他决定的内容。

当系统缺少这些业务语义时，最容易采用的办法就是把一切都塞进流程引擎：需要留痕走审批，需要别人知道也走审批，需要创建对象还是走审批。

最终，不同性质的业务动作在界面上越来越像，都变成了：

这里有一张单，轮到你处理了。

从这个角度看，所谓“审批流”并不是一种原子的业务结构，而是把对象变化、信息补充、判断、责任转移、通知和留痕等不同机制编排成了一条固定路径。

OA 告诉了你“轮到你”，却没有真正说明“你要做什么”

这也是很多 OA 用久以后很别扭的地方。

系统可以非常准确地告诉一个人：你有 12 条待审批、8 条抄送、5 条通知，还有几个流程已经超时。但这些数字并不能直接回答他一天工作中更重要的问题：我现在到底应该做什么？

原因不只是消息太多，而是流程节点本身丢失了大量业务语义。

“报价申请待审批”这句话，并没有告诉负责人，他此刻真正需要判断的是利润率是否可接受、交期是否承诺得出去，还是某项特殊条款是否需要额外授权。

“项目立项待审批”也可能把完全不同的工作压成同一个节点：有人需要确认资源是否充足，有人负责预算，有人其实只是被知会这个项目已经成立，要开始准备后续工作。

OA 记录得很完整，但展示给人的往往只是流程走到了哪里，而不是业务现在处于什么状态，以及这个人为什么需要介入。

这也是为什么，把所有审批、通知、邮件和聊天记录汇总起来，再让 AI 选出“今天最重要的三件事”，经常还是会差一点。AI 可以从文字里推测紧急程度和优先级，却仍然需要自己猜：这个节点对应什么业务对象，当前发生了什么变化，我在其中承担什么责任，以及真正需要完成的动作是什么。

问题并不只是信息没有聚合，而是原来的数字系统没有把“工作”表达清楚。

与其优化审批流，不如先回到业务对象发生了什么变化

如果重新设计，起点就不应该是“这张审批单需要经过哪几个节点”，而应该先问：这件事在业务世界里究竟发生了什么？

还是以报价为例。

客户提出报价需求后，系统首先应该形成一个明确的报价需求，其中包含客户、产品、数量、交期和特殊要求等事实。在此基础上，销售或系统形成一个或多个报价方案，方案里包含价格、成本、利润、交期和商务条件。

这时，真正需要人判断的可能只是其中某几个问题：利润是否低于授权线，特殊付款条件是否可以接受，交付周期是否存在风险。只有这些需要责任人作出取舍的地方，才真正构成决策。

一旦报价方案确定，后续发生的是方案被确认、输出给客户，并可能进一步转成合同或订单。

这样一来，原先一整条“报价审批流”，就被重新还原成了业务对象的产生和变化，以及夹在其中少量真正需要判断的节点。

而这些判断本身也不应该继续被压成一个笼统的“报价审批”。利润是否低于授权线，需要的是成本、报价、目标毛利和授权规则；特殊付款条件能不能接受，关注的是客户信用、账期政策和资金风险；交期能不能承诺，又依赖库存、产能、采购周期和当前订单负荷。它们面对的是同一份报价方案，但判断依据和责任主体并不相同。

因此，未来无论这些判断由人还是 Agent 承担，更合理的设计都不是造一个什么都懂的“报价 Agent”，而是先把具体在判断什么、需要哪些上下文、依据什么逻辑、由谁负责表达清楚，再决定哪些部分适合自动化，哪些需要辅助判断，哪些必须由人确认。

这和“Agent 帮我自动点审批”已经是两种完全不同的产品思路。

前者是在理解并推动业务，后者只是在自动操作一套既有界面。

再往前一步：从“审批中心”走向真正的工作台

当业务不再被压成一条条审批流之后，还会自然出现下一个问题：如果系统已经知道有哪些对象发生了变化、哪些地方需要判断、哪些动作需要由某个人完成，那么首页为什么还要以“审批、通知、抄送”来组织工作？

一个真正面向工作的系统，也许更应该回答：现在有哪些事情需要我完成，为什么是我，它针对什么业务对象，如果不处理又会影响什么。

这时，“任务”才开始成为一个需要独立定义的对象，而不是审批节点、消息红点或一条带截止时间的通知。

从 OA 往前走一步，会看到一个很明确的方向：未来的工作台不应该只是把审批和通知聚在一起，而应该直接呈现业务正在发生什么，以及此刻真正需要谁采取什么行动。

而当执行主体进一步从人扩展到 Agent，这个问题还会再向前推进一层。过去固定 workflow 可以顺便把很多前置条件、判断规则和责任边界藏在节点顺序里；Agent 一旦不再严格沿着这条路径行动，这些约束就必须被单独表达出来。

Agent 可以获得更大的路径自由，但这并不意味着业务依赖和治理边界一起消失。相反，越不依赖固定流程，系统越需要说清楚：在什么状态下允许发生什么动作，以及哪些变化必须经过额外检查。

这个问题在《Agent 不会消灭工作流，它只会逼我们重新理解工作流》中继续展开：当固定路径被拆掉以后，原来隐藏在 workflow 里的业务依赖、检查点与行动边界应该如何重新表达。