跳转到内容
Agentic Engineering Fieldbook

业务流程与运营智能体

业务流程里有大量看起来适合智能体的工作：阅读请求、补齐事实、路由案例、起草回复、更新系统、等待审批、跟进，以及在出错时恢复。不同于一次聊天，这些流程有状态、负责人、期限、外部影响和审计义务。

危险在于把自适应智能体当成流程本身。模型可以帮助解释、起草、分类和协调，但不应悄悄成为定义流程、提交外部影响、遗忘审批或在没有问责主体时决定例外的权威。

核心论点

Section titled “核心论点”

业务流程智能体最安全的形态，是把模型介导工作放在受治理的流程模型之内：确定性工作流系统负责持久状态、提交、计时器、审批和恢复；智能体在明确权限内处理解释、起草、路由和异常分诊。

已接受结果是业务案例中的进展，而不只是一次对话完成。系统应能够说明案例在哪里、由谁负责、哪些证据支持下一次转换、哪些行动已经提交，以及智能体无法继续时会发生什么。

流程智能体需要案例模型

Section titled “流程智能体需要案例模型”

在加入智能体之前，先定义案例：

  • 目标和业务价值；
  • 发起行动者、受影响方和问责负责人；
  • 当前状态和允许的转换；
  • 每个转换所需证据；
  • 期限、服务目标和过期行为；
  • 审批和例外权限；
  • 外部系统和副作用；
  • 补偿、纠正和审计要求。

没有这个模型，智能体的计划就会变成流程本身。这很脆弱。模型可能跳过必需审批，重复运行不可逆操作，在证据完整前发送消息，或在权限过期后继续工作。

案例模型不必对每个任务都采用重量级 BPMN。内部工作流可能只需要轻量状态机。关键是持久流程状态存在于模型上下文之外，并且转换由确定性控制或负责的行动者接受。

将工作流控制与模型决策权分开

Section titled “将工作流控制与模型决策权分开”

业务流程智能体结合了两类不同控制：

  • 确定性工作流控制：计时器、队列、重试、审批、状态转换、幂等、审计和恢复；
  • 模型介导决策权：解释文档、总结证据、选择常规路径、起草沟通，或识别例外。

OpenAI 的智能体构建文章把工具、防护栏、移交和人为干预描述为智能体系统关注点（OpenAI, 2026）。Temporal 等持久工作流平台把已持久化的 workflow execution、activities、重试和回放描述为围绕长时间工作运行的控制机制（Temporal Workflow Execution）。Camunda 等 BPMN 工具则为任务、事件、网关、用户任务和补偿提供流程建模词汇（Camunda BPMN documentation）。

模式是让确定性工作流拥有“什么状态可以改变”和“何时改变”。当证据和权限允许时，让智能体帮助判断“这个输入意味着什么”或“应提出哪个合格的下一步”。

外部影响需要转换提议

Section titled “外部影响需要转换提议”

在业务运营中，外部影响包括：

  • 创建或关闭案例；
  • 变更客户或员工记录；
  • 发送消息；
  • 批准费用；
  • 发放退款；
  • 下订单；
  • 更改访问权限；
  • 通知监管方、合作方或客户；
  • 启动或停止下游自动化。

模型通常应先提出转换，再提交外部影响。转换提议应识别目标系统、操作、行动者、权限、输入、证据、预期影响、可逆性、审批要求和超时。执行边界负责验证和记录该提议。如果提议不完整、缺乏支持、超出策略或已过期，就应被拒绝、修订或升级处理。

这保留了一个关键区别：智能体可以推理业务行动，但业务系统提交它。

审批必须有意义

Section titled “审批必须有意义”

许多流程智能体设计会加一个审批步骤，然后把设计视为安全。只有当审批人具备下列条件时，审批才有意义：

  • 有批准该行动的权限；
  • 有足够证据理解决策；
  • 对应后果有足够时间和注意力；
  • 有清晰的拒绝、编辑或升级处理路径；
  • 不响应时有安全默认；
  • 有记录说明究竟批准了什么。

审批应绑定到具体转换和当前状态。案例变化后，不应复用过期审批。像“处理这个供应商入驻”这样的宽泛审批，不应授权后来可能出现的每笔付款、访问授予、合同变更和通知。

异常处理是产品，不是边缘情况

Section titled “异常处理是产品，不是边缘情况”

业务流程包含异常：缺失文档、策略冲突、愤怒客户、局部故障、特殊折扣、重复记录、过期审批、付款失败和所有权含糊。智能体可以帮助发现和路由异常，但不应在没有常规路径时被迫编造策略。

设计显式异常状态：

  • 需要缺失信息；
  • 需要策略负责人；
  • 需要客户或请求者确认；
  • 需要风险接受；
  • 被依赖项阻塞；
  • 外部影响结果未知；
  • 需要补偿；
  • 已过期或被放弃；
  • 已升级给人工负责人。

面向用户的体验应展示这些状态，而不是假装工作完成。如果部分结果保留了证据、识别了阻塞点，并让案例准备好交给正确负责人，那么它仍然有价值。

恢复是流程设计的一部分

Section titled “恢复是流程设计的一部分”

外部影响可能失败、部分提交，或对调用方变成未知结果。盲目重试可能重复订单、重复发送消息，或给账户重复入账。可靠性章节讲的是通用机制；流程智能体必须把它应用到业务含义上。

Microsoft Azure 的补偿事务模式有用，因为它区分补偿和简单回滚，并强调恢复本身也可能失败或需要人工干预（Azure Architecture Center）。对于流程智能体，补偿应是带所有权和证据的领域操作，而不是神奇的撤销按钮。

有用的恢复记录包括：

  • 逻辑意图和幂等键；
  • 外部系统请求与响应；
  • 最后已知的权威状态；
  • 影响是已确认、失败、未知还是部分提交；
  • 补偿选项与限制；
  • 所需的客户、合作方或内部通知；
  • 负责核对并纠正的负责人。

设计选项

Section titled “设计选项”
选项 最适合 主要风险
智能体辅助的工作流步骤 起草、总结、分类、抽取字段 智能体输出可能在缺乏证据时被接受
流程 copilot 人类拥有的案例工作与下一步建议 人在高负载下变成橡皮图章
有边界的流程智能体 带严格工具和审批的常规转换 隐性权限扩张和状态过期
异常分诊智能体 将非常规案例路由给负责人 误分类延迟紧急工作
自主流程片段 有强恢复机制的狭窄低风险片段 难以证明超出该片段的安全性

多数组织应把确定性工作流和智能体步骤结合起来。智能体可以让流程不那么僵硬，但流程模型仍应是事实来源。

失效模式

Section titled “失效模式”
  1. 智能体变成流程。 状态只存在于对话中，无法安全审计或恢复。
  2. 审批漂移。 人批准了一件事，但行动提交前案例已经变化。
  3. 例外编造。 本来需要负责人的案例，智能体却创造出看似合理的策略。
  4. 重复影响。 重试重复了付款、订单、访问授予或通知。
  5. 静默过期。 审批、报价、同意或数据快照不再有效后，工作仍在继续。
  6. 无人拥有的补偿。 系统发现不良影响，但没有人负责纠正。
  7. 指标盲区。 流程看似更快，但错误、投诉或人工清理增加。

本手册的判断

Section titled “本手册的判断”

在流程拥有状态模型之前，不要问智能体能不能“跑完整个流程”。先问哪些转换需要解释，哪些需要确定性验证，哪些需要人工权限，哪些必须可恢复。

把持久状态放在模型之外。用模型提出、解释和分诊。用工作流和业务系统提交、等待、重试、过期、通知和记录。

把异常当作一等对象。如果业务流程对缺失证据、依赖失败或策略含糊没有安全默认，智能体不应自信填补缺口。它应保留案例并移交给可问责负责人。

检查清单

Section titled “检查清单”
  • 是否存在带状态、转换、负责人、期限和终止结果的持久案例模型？
  • 模型介导决策是否与确定性提交分开？
  • 每个外部影响是否有执行边界、幂等策略、审计记录和恢复路径？
  • 审批是否绑定到具体行动者、行动、范围、证据、状态和时间？
  • 异常状态是否明确，并路由给负责的所有者？
  • 系统能否从失败、部分、重复或未知的外部影响中恢复？
  • 流程指标是否包含已接受结果、纠正、投诉、老化和人工清理？
  • 审查者能否从持久记录而不是聊天历史中重建案例？

参考文献及其使用方式

Section titled “参考文献及其使用方式”