假设你是一家连锁企业的运营负责人，周五下午，几家门店说周末活动的货可能不够了。
你让 AI 看看怎么办。它很快分析销量、比较供应商、算出补货数量，还发现从附近门店调货，可能比重新采购更快。这样的能力越成熟，越容易让人产生一个想法：既然 AI 可以自己想办法，我们还需要提前给它画那么多流程吗？
这个问题，最近也出现在ADP 团队的讨论中。11 月 8 日，团队发布文章，认为工作流与 Agent 自主规划会长期共存，并区分了“怎样创建应用”和“应用运行时怎样作决定”。通过自然语言搭建应用，不意味着运行时的所有决定都交给模型。
11 月 11 日，ADP 又发布办公实践指南，介绍制度审核、服务质检、补货建议等场景。其中，补货建议需要核对数据来源，执行动作仍交由业务人员确认。这是场景实践指南，并非一份证明企业已全面自动运营的调查报告。
顺着这个讨论往下看，值得思考的是：当 AI 越来越擅长安排步骤，企业还需要通过流程保留什么？
回到刚才那个假设。
AI 发现甲店缺货，乙店恰好有库存，于是提出调拨。它查路线、估算运输时间、比较采购成本，这些工作不必都预先写成固定分支。下一次，也许临时加单更合适，也许减少活动投放更划算，AI 应该有空间寻找不同办法。
可乙店的库存里，有一部分已经答应留给另一个客户。账面上有货，不代表可以直接调走。采购系统里生成了订单草稿，也不代表供应商已经接受。供应商确认周末送达，更不意味着门店现在就可以把这批货计入可售库存。
这些差别不会因为方案写得漂亮而消失。
AI 选择怎样完成任务，是一条推理路径；企业承认哪些决定已经生效，是另一条业务路径。
前者可以不断尝试、更换方法。后者连接着真实的库存、资金、承诺和其他人的安排。一句“这样做更好”，还不足以把可讨论的建议变成别人必须履行的约定。
这也是我们容易低估流程的地方。
很多人一提流程，就想到表单、审批、签字，以及总也等不到的回复。企业里确实存在大量值得删除的步骤。但流程也承载着一些更基本的协作关系：谁可以占用这批库存，什么时候算正式下单，哪种变化需要通知另一方，出了问题由谁接手。
这些关系可以由软件执行，可以在明确条件下自动成立，也可以在少数情况下交给人判断。它们不必全部变成审批按钮。
例如，企业已经规定，同一区域内、一定数量以内、未被其他订单占用的货品可以自动调拨。满足条件就执行，没必要每次都请负责人重新表态。系统在真正占用库存时，还要核对当前余量，避免两项任务同时使用同一批货。
这类检查通常不需要模型临场发挥，也不应该靠一个人盯着每次操作。
另一些情况需要业务判断。原供应商临时无法供货，替代品价格稍高，却能赶上周末活动。是否接受，涉及成本、顾客预期和活动效果，可能需要有资格的人作出取舍。AI 可以把方案和影响说明白，让人有依据地决定。
因此，保留企业流程，并不意味着要求 AI 每走一步都停下来。
更有价值的做法，是把可以自主选择的空间、可以自动检查的条件，以及确实需要人判断的例外分别安排好。明确之后，很多正常任务反而能更连续地推进。
不过，如果企业只是把原来的流程一比一交给 AI，效果也可能很有限。
过去，员工需要从一个后台抄数据到另一个表格，再发到群里，等同事重新录入。AI 能替人把这些步骤做快，但我们还应该问：现在能直接传递同一份业务数据了，为什么还要保留这几次搬运？
有些确认原本只是因为信息看不见。有些盖章只是为了证明“前一个人确实处理过”。如果系统已经能提供可信、可核对的结果，原来的重复环节就值得重新审视。
当然，不能因为两个岗位都说“已确认”，就认定它们做的是同一件事。一个可能核实数量，另一个判断支出是否合理。删减之前，需要理解每一步保护的利益和承担的职责，再决定由什么机制接替。
流程的改造，应当让无效的搬运和等待减少，让必要的业务约定更清楚。
这会改变我们评价 AI 提效的方式。
一个助手把补货报告从两小时缩短到两分钟，是有价值的。但如果报告随后在群里等了两天，门店最后仍然缺货，我们还没有解决整件事的主要阻碍。
真正需要观察的，还有从发现缺货到货品可用经历了多久，哪一步在等谁，哪些材料反复补充，多少次人工确认只是机械重复，异常发生后又花了多少时间查清现状。
模型的回答速度，只占其中一段。
尤其在需要人介入的时候，“等待人工处理”这几个字，常常掩盖了很多没完成的设计。
系统把一份长对话转给负责人，让他自己翻出发生了什么、需要决定什么，实际上又把整理工作交还给了人。更好的交接应该说明：原本要完成什么，哪些步骤已经生效，卡住的原因是什么，目前有哪些选择，每种选择会改变什么。
如果负责人只需要判断是否接受替代品，就不必重新读一遍所有采购记录。判断所需的数量、差价、交期和影响，应当被清楚地摆在面前。决定回来后，也要能对应到这一次具体安排，而不是让 AI 重新猜测“老板大概同意了”。
还有一种更容易被忽略的情况：人作决定的时候，世界仍在变化。
负责人十分钟后同意调货，但乙店刚接到一笔新订单，可调数量已经变少。系统不能仅凭十分钟前的方案继续往下走，也没有必要把整个任务全部推倒重来。
它需要知道，变化影响的是哪一部分。原方案里仍然成立的事实可以保留，受影响的数量需要重算，超出原决定范围的取舍需要重新交接。假如另一家门店的补货完全独立，也不该因为这一处例外一起停住。
这样的运行能力，很难只靠一张提前画好的图获得。把所有事情交给模型临时判断，同样不能保证它成立。我们需要把实际业务状态、适用条件和已经发生的结果持续接回来，让后续动作有依据。
跨系统时，这件事尤其具体。
采购系统说订单已提交，库存系统还在等收货，门店活动系统显示商品未上架。这三个状态可能都正确，只是各自描述了不同阶段。若 AI 把任意一个“成功”当成整项任务完成，就可能过早告诉负责人“周末备货已经解决”。
相反，若订单已经成功，只是回传消息迟了一点，再从头下单一次，又会制造新的问题。
企业需要约定任务怎样算完成，也需要能够说明尚未完成的部分。对这次补货来说，确认供货、货物到店、验收入库、变为可售，分别意味着什么，应由实际业务规则决定，不能从一个工具调用成功直接推出来。
遇到失败时，还需要根据已发生的事实接着处理。
尚未提交的采购草稿可以取消，已经被供应商接受的订单可能需要协商，已经到货的商品可能进入退货流程。恢复并不总是回到起点，更不意味着一个“撤销”按钮能让所有系统和所有参与方一起回到过去。
能够接着办下去，往往比重新跑一遍更重要。系统要把可继续、需核实和需人工处置的部分说明白，让接手的人不必先猜一次现场。
从这里再看“Agent 会不会替代 Workflow”，这个问题就可以问得更具体。
如果我们谈的是查哪些资料、先比较哪家供应商、如何组织分析步骤，模型的自主规划确实可能减少大量预先编排。如果我们谈的是库存何时被占用、订单何时形成承诺、例外由谁决定、结果如何交接，这些协作关系仍需要明确安排。
实现方式可以变化。企业可以使用现有工作流、业务系统的原生能力，也可以增加合适的运行组件。画布上出现一个节点，并不自动证明规则被可靠执行；把规则写进一段提示词，也不能替代实际生效的约束。包含模型的工作流，本身仍然需要验证。
关键在于，某项决定由谁提供依据，哪些条件在操作发生时被检查，后续的人和系统如何知道结果。明确这些关系以后，再选择工具和编排方式，才更容易把自由用在合适的位置。
我们提出 A2B，也是希望把讨论推进到这一层。AI 无论通过软件助手还是其他载体行动，只要接受人或组织的委托，进入业务并产生后果，就需要面对这些关系。A2B 是我们为这类问题提出的认知框架，用来讨论机器行动如何进入组织协作，而不只关注它调用了多少功能。
ACC 是我们提出的开放能力契约，尝试共同表达业务能力的范围、主体要求、风险和审批意图。它可以帮助接入方理解一项能力的治理要求；库存是否还够、订单是否允许修改、某项承诺是否已经成立，仍需要相关业务系统判断。
BailingHub 则是开源控制面的实践，把能力开放、执行约束、人工介入和操作记录接入运行过程。本文讨论的完整跨系统协作、变化处理和业务恢复，还需要企业现有系统与组织安排共同落实，不能由一份声明或一个产品自动包办。
对于正在接入 AI 的企业，可以先选一项反复发生的工作，把从提出需求到真正交付的过程走一遍。看看哪些步骤只是因为过去的信息传递困难而存在，哪些决定一旦作出就会影响别人，哪些等待可以取消，哪些异常需要有人明确接住。
自主规划的空间由此可以逐步扩大，企业也能知道自己为什么敢放手。
未来，我们或许不用再提前告诉 AI 每一个动作怎么做。但把工作交出去的人，仍然需要看得见：公司已经承诺了什么，事情进行到了哪里，接下来是否还有人在等。
