Workflow Runtime Contract：AI 数字员工自动运行前要固定什么

Workflow Runtime Contract 是 AI 数字员工自动运行前的运行合约：触发条件、输入边界、Skill 链、交付产物、Trust Mode、异常接管和 replay key 都要先固定。很多团队每天都在处理重复、手动、容易出错的任务，却急着把一个聊天式 Agent 放进定时执行。结果常见问题不是模型不会写，而是今天读错资料、明天少跑一步、后天越过确认边界。Axon 的 Workflows 路线要解决的正是这件事：让 LLM 智能执行之前，先让运行环境可控。

Anthropic 在 Building Effective Agents 里把 workflows 和更开放的 agents 区分开来，并强调检查点、反馈和人工输入的重要性。NIST 的 AI Risk Management Framework 也要求组织把治理、测量和管理放进 AI 系统生命周期。放到 Axon 产品里，最实际的形态就是 Workflow Runtime Contract。

自动化不是“让 Agent 自己发挥”。自动化是把能自动的部分固定下来，把该停下来的地方明确写进运行合约。

运行合约先固定七件事

一个 AI 数字员工是否能上自动运行，不应只看 demo 是否成功。更好的做法，是先看运行合约是否完整：

合约项	要回答的问题	失控信号
Trigger	什么时候运行？手动、定时、事件触发？	同一任务被重复触发或漏触发
Source Data	本次运行允许读哪些资料？	Agent 临时猜资料范围
Skill chain	哪些 Skills 必须按什么顺序执行？	每次调用能力都不一样
Artifact	最终交付什么文件或记录？	只有一段聊天回复
Trust Mode	哪些动作必须确认？	外发、发布、覆盖静默发生
Exception route	出错后交给谁、带什么证据？	失败后只能重跑
Replay key	如何识别同类任务和同类运行？	无法比较两次运行差异

这和 可重放 AI Workflows 一脉相承。可重放关注运行后留下什么证据；Runtime Contract 关注运行前必须承诺什么。

一份最小运行合约

runtimeContract:
  workflow: "daily supplier quote review"
  trigger: "workdays 09:00"
  sourceData:
    required:
      - "supplier quote sheet"
      - "customer email thread"
      - "margin rule"
  skillChain:
    - "extract quote terms"
    - "compare margin and payment risk"
    - "draft negotiation options"
  artifact: "quote-review.md"
  trustMode:
    requireConfirmBefore:
      - "send email"
      - "publish customer-facing wording"
  exceptionRoute:
    owner: "sales operations"
    include: ["missing source", "failed Skill", "artifact draft"]
  replayKey: "customer_id + quote_date"

这份合约不追求复杂，而是让业务 owner、Skill owner 和 Agent 在同一张纸上工作。没有它，所谓全自动很容易变成“模型每次临场发挥”。

为什么它不是普通配置表

普通配置表只告诉系统“怎么跑”。Workflow Runtime Contract 还要告诉团队“为什么可以让它跑”。这两者差别很大。

配置项通常服务工程执行；运行合约服务业务信任。业务负责人关心的不是 cron 表达式写得对不对，而是任务触发后会不会读错资料、会不会覆盖文件、会不会把不该发的邮件发出去。合约把这些担心显性化，让自动化从“技术动作”变成“可授权的工作安排”。

如果一个流程已经有 Workflow Evals 与 Trust Mode，运行合约就能作为上线前的最后检查：eval 证明它能稳定完成，Trust Mode 定义哪些动作不能直接放行，runtime contract 则把触发、输入、产物和异常连接起来。

三种不该自动运行的情况

第一种：输入边界还不清楚。
如果团队还在争论“Agent 到底应该看哪些资料”，就不要急着定时。先把 Source Data 字段固定下来，可以参考 Source Data 到决策证据链。

第二种：交付物没有验收标准。
如果结果只是“写得还行”，自动化会把主观判断放大。至少要有 artifact 名称、格式和验收规则。

第三种：异常没人接。
自动化最怕失败后没人知道该怎么办。运行合约必须写清楚异常交给谁、带哪些证据、是否允许补跑。

上线前的小型评审

可以把评审控制在 15 分钟内：

1. 业务 owner 确认 trigger 和 Source Data。
2. Skill owner 确认 Skill chain 和 artifact。
3. 风险 owner 确认 Trust Mode 和异常接管。
4. 运行一次 dry-run，检查 replay key 是否能定位运行记录。

这不是流程官僚化，而是把“全自动”前面那一步做扎实。

运行合约问题

Q1：每个 Agent 都需要 Workflow Runtime Contract 吗？
不是。临时探索、一次性研究、纯草稿生成可以轻一些；定时、外发、覆盖文件、跨部门协作的 Agent 必须有。

Q2：运行合约会不会拖慢上线？
短期会多一次检查，长期会减少返工。没有合约的自动化，出错后通常更慢。

Q3：Runtime Contract 和 Workflow Evals 有什么区别？
Evals 证明流程能不能稳定完成；Runtime Contract 规定流程在什么边界内被允许运行。

先把一个自动任务签成合约

第一次在 Axon 里做自动化，不要先追求“全公司流程都跑起来”。选择一个高频低风险任务，写清 trigger、Source Data、Skill chain、artifact、Trust Mode、exception route 和 replay key，再结合 AI Workflow 界面 让业务团队看得懂。了解更多运行证据、探索更多合约边界后，再把这个合约扩展到更复杂的数字员工。