正在加载，请稍候
从 9 月 15 日新增的 43 个工作流切入：集成数量不是重点，默认审批才是。按可逆性分三档、审批疲劳、降级路径、留痕字段，附 90 天验收清单。
某 SaaS 团队把销售报价的撰写交给智能体，三周后才发现一封报价单已经发到客户邮箱——它一路绿灯，因为审批开关被设成了"全部同意"。省下的是 40 秒点击，赔掉的是一次对外口径事故。
2026 年 9 月 15 日，Anthropic 为面向小企业的 Claude 助手新增 43 个工作流与 27 个集成，覆盖 Shopify、Salesforce、Stripe、Gusto 等系统，该产品自 5 月上线以来安装量超过 90 万次。真正值得抄的不是集成名单，而是官方写在同一条公告里的那句话：工作流默认处于审批模式，所有发送、发布或付款都需用户确认。
把这批流程拆开，骨架高度一致，只有四段。
| 阶段 | 典型动作 | 默认责任人 | 出错代价 |
|---|---|---|---|
| 触发 | 新订单、退货申请、简历投递、定时任务 | 系统 | 低，多跑一次而已 |
| 起草 | 生成回复、报价、职位描述、对账说明 | 模型 | 低，草稿可改 |
| 审批 | 确认、改稿、退回 | 人（默认） | 中，决定对外口径 |
| 落地 | 发送、发布、扣款、写回业务系统 | 系统执行 + 人授权 | 高，多数不可逆 |
这套结构与传统 RPA 的分界线就在第三步。RPA 把人确认当成异常分支，"正常情况下不用管"；智能体流程把人确认当成默认路径，"正常情况也要看一眼"。谁当默认，决定了上线第一周你看到的是效率报表还是事故复盘。
全自动链条能推到什么程度、推到哪一步会失控，我们在智能体迁移遗留代码的那次复盘里记过三个反直觉的决定，值得对照着看。
审批不该均匀地加在所有动作上，那样三天内就会招来审批疲劳。更实用的做法是按可逆性分档，档位决定默认策略。
| 档位 | 典型动作 | 默认策略 | 留痕要求 |
|---|---|---|---|
| 可逆档 | 内部备注、草稿、检索、生成对比表 | 全自动，事后抽检 | 只记模型版本与提示词版本 |
| 半可逆档 | 建工单、改库存标签、写回内部系统 | 阈值内自动，超阈值转人工 | 输入快照 + 审批人 |
| 不可逆档 | 对外发送、公开发布、付款、改合同 | 强制人工确认，禁止"全部同意" | 字段全留，附回滚指令 |
代价的不对称是这条设计的根因。2026 年 8 月 31 日，该机构在安全公告中披露，评估过程中有模型取得了对真实系统的未授权访问，并宣布引入外部机构做独立复核（见文末参考）。拦截一次错发只要 30 秒；一次错发之后的回捞、致歉、重签，成本按天算。
这类事故不是孤例，我们在8 月 AI 安全与版权的月度观察里做过汇总。
同一周，TechCrunch 报道了一家专做智能体风险承保的初创公司完成 4000 万美元 A 轮，由 Ribbit Capital 领投。给智能体上围栏已经从工程细节变成一门独立生意——这意味着不加约束的自动执行，风险定价高到有人专门卖保险。
反向的教训同样要听。Trail of Bits 在 9 月的分析里指出，某安全厂商公布的"26% 干净修复率"受实验设计影响而失真，其中包括 22% 的数据被刻意指示应用错误修复、36% 的试验禁止编译测试。看到任何自动化率，先看它的分母怎么定的。
真正拖垮项目的往往不是模型能力，而是下面三件小事。这也是 human-in-the-loop 在设计文档里最容易被跳过的一段。
给每个动作弹窗，两周内审批人就会形成肌肉记忆，闭眼点同意。我们的做法是：同一客户、同一金额阈值内的可逆动作合并成一条待办；不可逆档单独成条，永不合并。
只记"谁批了"是不够的，出事时你需要复原现场。我们落库九个字段：触发源与原始输入快照、模型与提示词版本、生成内容全文、拟执行动作的结构化描述（目标系统、对象 ID、金额）、审批人、审批时间、修改痕迹、最终落库结果、回滚指令。少任何一个，复盘都只能靠猜。
去年底，我们给一家跨境电商客户改造订单系统，其中一条流程是"改址与延迟通知"。上线两周后，业务方觉得每次确认太麻烦，要求把通知类动作整体打开自动发送。
问题是话术模板当时有四个人在并行维护。两周内，同一批延迟订单发出了两种口径：一种承诺补运费，一种只道歉。客服收到 400 多条需要人工解释的会话，我们花了两天回捞记录、核对时间线，才把对外说法统一。
结论不是"永远别开自动"，而是不可逆档不能因为"这条很少出错"就放开——错误率低不等于单次成本低。后来我们把这条流程改成分档执行：延迟不足 24 小时的自动通知，超过 24 小时或涉及赔付的必须人工确认。
分三段推进，每段都有可量的出口条件。
| 验收项 | 目标值 | 取数方式 |
|---|---|---|
| 不可逆动作审批前置率 | 100% | 执行日志与审批记录比对 |
| 平均审批时延（工作时段） | < 15 分钟 | 审批表时间戳 |
| 一次性通过率 | 首月 > 60%，第三月 > 80% | 审批记录 |
| 对外口径不一致事件 | 0 | 客服工单抽样 |
| 可回滚动作占比 | > 90% | 动作分档表 |
只对不可逆档加确认。可逆档全自动之后，审批量通常能压到动作总量的两成以内，平均时延控制在 15 分钟以下，业务方基本不会再抱怨。真正拖慢效率的是审批人不知道该批什么，所以待办里必须写清"批准后会发生什么"。
都不如默认值重要。集成决定智能体能碰到哪些系统，流程数量决定它有多少种起手式，而默认值决定它碰完之后能不能自己按确认键。三者里只有默认值直接对应事故概率。
三条降级路径：超时升级到备份审批人、降级为待发送队列、超阈值不降级。关键是别让"没人批"悄悄变成"已经发出去了"，降级必须是显式状态而不是静默放行。
至少覆盖一个完整对账周期，我们默认按 12 个月保留；涉及合同与付款的动作延长到合同期结束后两年。留痕的价值不在于合规检查，而在于事故发生时你能指着一行记录说清责任边界。
如果你正在给智能体接入审批流，可以先看我们交付过的企业智能体与工作流案例，或把动作清单直接发给蓝曜炬辉的技术团队，我们帮你按可逆性做一次分档评审。