问题域
组织中的大部分运营工作，都是跨越多个系统的流程：一张发票通过邮件到达，与 ERP 中的采购订单核对，由经理审批，过账到账本，然后付款。是人在系统之间搬运这个流程，重复录入数据，并记住下一步该做什么。自动化省去的正是这种搬运。要把它做好，自动化后的流程至少要和它所替代的人一样可靠，并且更容易检查。
这样的流程里有两类步骤。一类是完全可以明确规定的：如果金额低于阈值且供应商已获批准，就转入付款。这类步骤应当放在确定性代码或规则引擎中，在那里它们快速、便宜、可测试、可解释。另一类涉及非结构化输入或判断：读取扫描文档、对客户邮件分类、起草回复、判断一个含糊的引用指的是几条记录中的哪一条。这才是语言模型发挥价值的地方。
工程上的难题，是把两者结合起来而不失去控制。能够调用工具的 AI 智能体能力强大，同时也是非确定性的。把它放进持久化工作流中，配上类型化的输入输出、有边界的权限、校验，以及在关键节点上的人工审批，它就成为一个可以托付实际工作的组件。任由它在生产系统上自由运行，则不然。
难在哪里
工程挑战
静默失败的自动化
定时脚本在第三步抛出错误后停止。没有任何机制重试，没有人收到通知，做到一半的工作要等客户投诉时才被发现。没有持久化的状态和可见性，每一个自动化都是一处隐患。
规则就能解决的地方用了 AI
在逻辑完全已知的情况下把决策交给语言模型，每次运行都会增加成本、延迟和小概率的错误答案，结果也更难解释。相反的错误同样常见：用几百条脆弱的规则去解析自由文本，而模型本可以轻松处理。
权限过大的智能体
一个拥有宽泛 API 凭证和开放式目标的智能体，可能做出没有人打算让它做的操作，当它读取的文档中含有被注入的指令时尤其如此。风险随它持有的权限同步放大。权限必须按任务限定范围，有后果的操作必须设卡把关。
文档的多样性
发票、表单和合同以扫描件、照片和 PDF 的形式到达，版式多达数百种。基于模板的抽取在供应商更改格式时就会失效。抽取需要置信度评分、与已知数据的校验，以及把不确定的情况转交给人的通道。
跨系统的部分失败
流程更新了 CRM，随后更新 ERP 失败。从头重试会重复第一次更新；就此停下则让系统之间不一致。每一步都需要是幂等的，流程也需要为无法完成的步骤定义补偿措施。
事后才考虑的人工审批
通过邮件处理的审批没有期限、没有升级机制，也没有与流程关联的记录。工作就这样搁置在收件箱里。人工任务需要成为流程中的正式步骤，具备指派、超时、委托和审计轨迹。
我们如何构建
架构
流程运行在持久化每一步的工作流引擎之上。确定性规则、文档处理和 AI 智能体作为带类型化契约的活动被调用，人的决策则被建模为显式任务。
- 01
持久化工作流引擎
由 Temporal 这类引擎，或 Camunda 这类 BPMN 平台，把每个流程作为持久化的状态机来执行。如果工作节点崩溃，流程从最后一个已完成的步骤恢复。重试、超时和定时器在工作流定义中声明，流程可以为等待一个外部事件而停留数天，却不占用资源。
- 02
集成连接器
每个外部系统都通过连接器访问，由连接器处理认证、限流、分页和错误映射。连接器的操作被设计为幂等，使用自然键或幂等令牌，因此重试的步骤不会产生重复记录。当某个系统不提供 API 时，才把基于用户界面的机器人流程自动化（RPA）作为最后手段，并把它隔离在同样的接口之后。
- 03
规则与决策服务
可以完全明确规定的业务规则，以版本化的决策表或代码的形式放在决策服务中，与调用它们的工作流分开。这样策略变更可以单独评审和测试。每次求值都记录输入、规则版本和结果，为任何一项自动决策提供直接的解释。
- 04
文档处理流水线
传入的文档先分类，再经过光学字符识别（OCR）和版面分析，由适合该文档类型的模型抽取字段。抽取出的值与参考数据进行校验，例如匹配 ERP 中的供应商和采购订单，并被赋予置信度评分。高置信度的结果自动继续；其余的进入审核界面，界面上并排显示原件与抽取出的字段。
- 05
AI 智能体运行时
智能体作为工作流活动被调用，有明确的目标、固定的工具集合，以及对步数、时间和花费的限制。工具是功能单一、带类型化参数的函数，以限定在该任务范围内的凭证执行。智能体的输出必须符合既定 schema 并通过校验，工作流才会据此行动；智能体读取的内容则被视为不可信数据。
- 06
人工任务服务
审批、审核和异常都是指派给某个角色或个人的任务，带有到期时间、升级路径和委托规则。审核人可以看到自动化所依据的证据和它提议的操作，并可以批准、修改或拒绝。决定被记录在工作流实例上，并使其恢复运行。
- 07
流程可观测性
每个工作流实例都对外呈现其当前步骤、历史、输入和输出。仪表盘报告吞吐量、周期时间、失败率、无需人工干预即完成的案例占比，以及 AI 步骤对照持续维护的评估集所得到的质量。失败的实例会出现在运营队列中，可以在那里检查、修正并恢复运行。
推理
- 01
触发
事件、定时任务或用户请求
- 02
规划
把目标拆成有边界的步骤
- 03
工具调用
通过类型化工具只读查询
- 04
拟定操作
拟议的变更及其证据
受控执行
- 01
策略检查
限额、权限与风险评级
- 02
人工审批
高影响操作必须审批
- 03
执行
向目标系统幂等写入
- 04
验证
确认结果，重试或回滚
- 05
审计
每一步都有日志且可重放
一次合作交付什么
- 流程分析，识别基于规则的步骤与基于判断的步骤
- 部署在持久化引擎上的工作流定义
- 连接相关系统的幂等连接器
- 带置信度阈值与审核界面的文档抽取流水线
- AI 智能体的工具、权限范围与评估集
- 带升级规则的审批与异常处理
- 运营仪表盘，以及处理失败实例的运维手册
开始之前
需要尽早做出的决策
- 某一步骤用规则，还是用 AI
- 当输入是结构化的、逻辑可以完整写下来时，使用规则；它们更便宜、更快，并且可审计。当输入是非结构化的，或者情况多到规则难以管理时，使用 AI。一个不错的默认做法是由模型负责抽取和分类，再由规则作出决定，这样决策本身仍然是确定性的。
- 人工审批放在哪里
- 放在出错代价高或不可逆的地方：付款、对外沟通、合同变更，以及任何触及客户法律地位的事项。使用置信度阈值，让人只审核不确定的情况，而不是每一个案例。随着证据的积累重新审视这些阈值；取消一个人工步骤，应当是一项经过深思熟虑并有记录的决定。
- 工作流引擎，还是事件协同
- 当流程有既定顺序、需要清晰地看到自身状态并且带有补偿逻辑时，使用工作流引擎。当各个独立系统对事实作出反应、没有哪一方拥有整个流程时，使用事件协同（choreography）。冗长的协同链条难以追踪和修改，因此对核心业务流程而言，编排器通常更为合适。
- 一个全能的智能体，还是多个专精的智能体
- 优先选择工具集小、职责单一的专精智能体，由工作流把它们组合起来。它们更容易评估，运行成本更低，并且能限制任何单点失败的影响范围。一个拥有许多工具的通用智能体起步更简单，却更难预测、测试和保障安全。
常见问题
常见问题
这与机器人流程自动化（RPA）有什么不同？
机器人流程自动化通过用户界面驱动应用程序，在没有 API 时很有用，在界面变化时却很脆弱。这里的做法是尽可能通过 API 和事件集成，在工作流引擎中持久化流程状态，并把 AI 用于非结构化输入。界面自动化只保留给别无选择的系统。
AI 智能体可以在无人监督的情况下执行操作吗？
对于影响小且可撤销的操作，在限定于该任务的权限范围内，可以。有后果的操作要经过人工审批步骤。这条界线按流程、与对流程负责的人共同设定，并由工作流强制执行，而不是交给智能体自行判断。
某个步骤失败时会怎样？
引擎以退避方式重试瞬时故障。如果故障持续存在，实例会暂停在一个可见的错误状态，并保留完整历史，运营人员可以修正数据并从该步骤恢复运行。对于跨多个系统的操作，补偿动作会撤销已经完成的步骤。
组织应该从哪里入手？
从一个发生频繁、已被充分理解并且令人头疼的流程入手，其输入和结果应当可以度量。在规范的引擎上把一个端到端流程自动化，可以建立起后续流程能够复用的连接器、审批模式和监控。