Workflow State Machine：AI 数字员工不能只显示“运行中”

Axon AI 2026-05-30 AI 数字员工 Agents 数字员工

#AI数字员工#Workflows#状态机#Axon

Workflow State Machine：AI 数字员工不能只显示“运行中”

摘要：本文说明 Workflow State Machine 如何让 Axon AI 数字员工的进度、确认点、异常和验收结果可见，避免黑盒式自动化。

Workflow State Machine 是 AI 数字员工的运行状态机：它把一个 workflow 从草稿、dry-run、等待确认、执行中、异常、已验收到归档的每个状态都显性化。很多团队每天重复处理报表、客户邮件和研究摘要，最怕的不是 Agent 慢，而是它只显示一个模糊的“运行中”。30 分钟后没人知道它卡在资料读取、Skill 调用、人工确认，还是产物验收。Axon 继续坚持 Workflows 路线，是因为 LLM 执行要进入办公生产环境，必须先把状态讲清楚。

Anthropic 在 Building Effective Agents 中把预设 workflows 和更开放的 agents 分开讨论，并强调检查点和人工反馈。NIST 的 AI Risk Management Framework 也要求 AI 系统可治理、可测量、可管理。放在 Axon 里，Workflow State Machine 就是把这些原则变成业务能看懂的运行界面。

黑盒 Agent 只告诉你“我在做”。状态机告诉你“我做到哪一步、下一步是否需要你确认、失败后谁接手”。

不要把进度条当成状态机

进度条适合文件上传，不适合 AI workflow。一个 80% 的进度条不能解释为什么任务不能继续，也不能说明是否可以安全自动化。Workflow State Machine 应该至少暴露七类状态：

状态	业务含义	允许动作
draft	workflow 还在设计	编辑 trigger、Source Data、Skill chain
dry-run	使用样本资料试跑	查看日志、比较产物、调整 Skill
waiting-confirmation	触达 Trust Mode 边界	批准、拒绝、修改输入
running	正在执行已授权步骤	查看当前 Skill 和中间产物
exception	运行失败或输入缺失	指派 owner、补资料、重新运行
accepted	产物被业务 owner 验收	记录证据、进入下一轮
archived	运行记录归档	审计、复盘、复制模板

这组状态和 Workflow Runtime Contract 不冲突。运行合约回答“什么边界内可以跑”，状态机回答“现在跑到哪里、能不能继续”。

一份状态转移草图

stateDiagram-v2
  draft --> dry_run: sample source ready
  dry_run --> waiting_confirmation: risky action reached
  dry_run --> running: auto-safe path
  waiting_confirmation --> running: owner approves
  waiting_confirmation --> draft: owner rejects
  running --> exception: missing source or failed skill
  exception --> dry_run: repaired input
  running --> accepted: artifact approved
  accepted --> archived: run evidence saved

这张图不需要暴露给所有终端用户，但产品内部必须有相同的状态语法。没有状态机，后台日志、前台按钮、通知消息和验收记录很容易各说各话。

状态机让 Trust Mode 更像业务语言

很多团队把 Trust Mode 理解成“弹一个确认框”。这太窄。确认框只是表现层，真正重要的是状态变化：workflow 为什么停下、停在哪个动作前、用户批准后会继续哪一个 Skill、拒绝后会回到哪里。

例如，一个供应商报价复核 Agent 读取报价表、客户邮件和毛利规则后，准备生成谈判邮件。读取、比较、生成草稿可以自动；发送邮件必须进入 waiting-confirmation。业务 owner 看到的不应只是“是否发送”，还要看到：

本次报价来源是否完整；
触发发送的 Skill 输出是什么；
邮件草稿将发给谁；
拒绝后是否保存修改意见；
批准后是否进入运行记录。

这和 Workflow Evals 与 Trust Mode 形成闭环。Evals 证明能力稳定，Trust Mode 定义确认边界，状态机让每次停顿都有解释。

三个容易被忽视的状态

dry-run 不是测试按钮。
它应该保存样本输入、Skill 输出和产物差异。没有 dry-run 证据，团队很难判断 workflow 是否可以进入定时执行。

exception 不是失败提示。
它要带上失败步骤、缺失 Source Data、中间产物和建议接手人。可以参考定时 Agent 运行日志的思路，把失败变成可复盘记录。

accepted 不是完成动画。
AI 数字员工真正完成任务的信号，是业务 owner 接受了 artifact。这个状态也应进入 Workflow KPI Ledger，否则团队只能统计“跑了多少次”，看不到“有多少产物被采用”。

给产品和运营的检查清单

步骤 1：先确认用户能看到哪些状态，不要把所有后台节点都压成“运行中”。步骤 2：为每个状态绑定 owner、证据链接和下一步动作。步骤 3：把 waiting-confirmation、exception、accepted 三个状态接入 Trust Mode、运行日志和产物验收。

stateMachineReview:
  visibleStates:
    - draft
    - dry-run
    - waiting-confirmation
    - running
    - exception
    - accepted
    - archived
  eachStateMustShow:
    - current owner
    - current source or artifact
    - next allowed action
    - evidence link
  forbidden:
    - "single running label for all states"
    - "silent retry without reason"
    - "accepted state without human or rule-based acceptance"

状态机问题

Q1：小型 Agent 也需要 Workflow State Machine 吗？
临时草稿任务可以轻量处理；定时运行、外发、覆盖文件、跨团队协作的 AI 数字员工必须有明确状态。

Q2：状态越多会不会让用户困惑？
用户界面可以简化，但底层状态不能混乱。前台可以显示“等待你确认”，后台仍要知道它来自哪个 Skill 和哪条规则。

Q3：状态机和运行日志有什么区别？
状态机描述当前处境和下一步动作；运行日志记录已经发生过的步骤。两者结合，workflow 才能可控也可复盘。

先把一个黑盒任务拆成状态

如果你正在用 Axon 设计 AI 数字员工，不要只问“它能不能自动跑”。先选一个重复任务，写出 draft、dry-run、waiting-confirmation、running、exception、accepted、archived 七个状态分别由谁负责、看什么证据、允许什么动作。了解更多运行日志和验收方式，探索更多状态边界后，再把这个 Workflow State Machine 接到真实的 Agent Pipeline。