AI 数字员工上线前，先过 Workflow Evals 和 Trust Mode
Workflow Evals 是 AI 数字员工上线前的一组工作流评估：它不只看模型回答是否漂亮，而是检查重复任务能否稳定读取输入、调用 Skills、生成可验收产物、触发正确的 Trust Mode，并在失败时留下可接管证据。很多团队每天、每周都想把重复工作交给 AI，却低估了上线门槛。一次演示成功不代表可以定时运行；一个 Agent 能跑通，不代表它能无人值守处理真实业务。
Anthropic 在 Building Effective Agents 中提到 evaluator-optimizer workflow，也强调 Agent 需要从环境获得 ground truth，并在检查点请求人类反馈。NIST 的 AI Risk Management Framework 也把 AI 风险管理放在组织设计、部署和使用过程里。放到 Axon 语境下，结论很直接：AI 数字员工上线前，必须先过 Workflow Evals，再由 Trust Mode 决定自动化等级。
一个成熟的 Agent 不是“跑过一次”，而是能被评估、能被约束、能被复盘、能在正确位置停下来。
不要把 demo 成功当成上线通过
办公自动化最危险的误判，是把一次 demo 的顺利输出当成生产稳定性。真实环境里，资料会缺失，网页会变，文件格式会乱，用户会换需求，邮件和发布动作会影响外部对象。没有这组上线评估，团队只能靠感觉判断 Agent 是否可靠，最后往往在最忙的时候才发现流程断了。
Axon 的 Workflow Evals 应该覆盖四个层面：
- 重复性：同类输入是否走同样的 Skill chain。
- 产物性：输出是否是可下载、可检查、可继续处理的 artifact。
- 权限性：发送、删除、发布、覆盖等动作是否进入 Trust Mode。
- 恢复性：失败后是否有日志、workspace 文件和人工接管入口。
这和 Scheduled Agent run journal 的思路一致：定时任务不是黑盒，它应该留下可复盘记录。
一张上线成熟度梯
| 阶段 | 允许范围 | 必须证明 |
|---|---|---|
| Draft | 人工触发，低风险资料 | 能生成初版 artifact |
| Reviewed | 人工触发，真实资料 | 产物通过验收，失败能定位 |
| Confirmed | 部分自动，外部动作确认 | Trust Mode 拦截正确 |
| Scheduled | 定时运行，低风险闭环 | 多次运行稳定，有 run journal |
| Expanded | 扩展到更多流程 | 有异常队列、变更记录和 owner |
这张梯子的目的不是拖慢上线，而是避免把“会跑”误判成“能托付”。
上线评估应该测什么
一个可执行的评估矩阵，可以比抽象讨论更有用：
workflowEvals:
repeatability:
question: "same class of input triggers same Skill chain?"
passSignal: "step sequence and artifact types remain stable"
artifactQuality:
question: "does the output satisfy the acceptance contract?"
passSignal: "owner can use the file without rewriting it"
riskBoundary:
question: "does risky external impact stop at Confirm or Auth?"
passSignal: "email, publish, delete, overwrite never happen silently"
recovery:
question: "can a human continue after failure?"
passSignal: "workspace evidence and error class are visible"
这个矩阵的重点，是把评估对象从“模型表现”转到“工作流表现”。模型可能很强，但如果产物不可验收、权限不清晰、失败不可恢复，AI 数字员工仍然不能上线。
落地时可以按三步执行：
- 先选一条低风险 Agent，只覆盖一个固定交付物。
- 连续运行多次，记录输入、Skill chain、产物、权限拦截和失败类型。
- 由 owner 根据验收规则决定进入 Draft、Reviewed、Confirmed 还是 Scheduled。
Trust Mode 是上线决策，不只是弹窗设计
很多团队把人工确认理解成最后一步弹窗。Axon 应该把 Trust Mode 当作上线决策语言：
- Auto：低风险、可重跑、无外部影响。
- Confirm：会影响外部对象，但人工确认即可放行。
- Auth：需要账号、授权或更高责任边界。
如果一个流程里所有动作都被标成 Auto，通常不是自动化成熟，而是风险没有被识别。涉及邮件时，可以读 Trust Mode 邮件确认。涉及异常处理时，可以读 Agent exception queue runbook。
评估失败时，不要只让模型重试
这类评估的另一个价值，是让失败进入正确修复路径。资料缺失时，应该补 Source Data；产物不合格时，应该改输出 schema 或模板；权限越界时，应该调整 Trust Mode；流程漂移时，应该回到 Agent steps 或 User Skill，而不是简单让模型“再认真一点”。
这也是为什么 Axon 的 AI 数字员工叙事必须围绕 Skills 和 Workflows。只有步骤明确，评估才有对象；只有产物明确，验收才有标准；只有权限明确，自动化才有边界。否则，所有问题都会被包装成一句含糊的“模型不稳定”。
如果你想从可靠性角度继续阅读，可以看 workspace Agent reliability review。
常见问题
Q1：Workflow Evals 和普通模型评测有什么不同？
普通模型评测常看回答质量。Workflow Evals 看整条执行链：输入、Skill 调用、产物、权限、日志、异常恢复和人工接管。
Q2：什么时候可以开启定时运行？
至少要证明同类输入多次运行稳定，产物能被 owner 验收，高风险动作进入 Confirm 或 Auth，并且失败后能通过 workspace 和日志继续处理。
Q3：Workflow Evals 会不会增加太多成本？
短期会增加设计成本，长期会降低返工成本。没有评估的自动化，通常会在上线后用更高代价补救。
把上线判断写进流程
AI 数字员工能不能上线，不应该靠感觉。开始使用 Axon 时，可以先为一个低风险 Agent 建立上线评估：重复性、产物质量、Trust Mode、恢复路径。通过后再进入定时任务；没通过就回到 Skill、Source Data 或输出合同。阅读更多运行日志、Trust Mode 和 workspace reliability 内容，再把 AI 数字员工从演示推进到可托付的工作流。