Agent 跑得很勤，不代表系统有价值：从 Output Metrics 到 Outcome Metrics

我见过一种很有迷惑性的 Agent Dashboard：Token 曲线每天创新高，Tool Call 数量稳步上涨，任务状态几乎全是绿色。

但顺着事件链往后看，accepted 少得可怜。大量任务停在 artifact_ready，然后进入人类的返工队列。

这类系统不是没有产出，而是把输出当成了结果。

OpenAI 9 月 1 日发布的 AI 原生工作流文章里，有一句话可以直接拿来给 Agent 可观测性"纠偏"：Output volume can show that people are asking AI to do more; workflow outcomes show whether it matters。

同一组 Enterprise Signals 数据显示，高使用组每位活跃用户的输出 Token 已达到典型组的 8.3 倍。但官方紧接着强调，Token 只是使用深度的代理指标，不是业务价值本身。这个限定比 8.3 倍更值得工程团队记住。

Output Metrics 为什么会失真

Token、调用次数、运行时长都有用，它们适合回答容量、成本和异常问题，却无法单独回答"工作有没有完成"。

典型失真有三种：

Agent 重试五次，调用量增加，结果质量没有增加；
生成了 30 份草稿，人工只接受 3 份，Dashboard 却记录 30 次成功；
一个步骤执行成功，但下游字段、权限或发布页面失败，系统仍把局部成功算成任务完成。

所以，生产系统需要把观察单位从一次推理，提升到一次端到端交付。

先设计状态机，再设计指标

以内容运营工作流为例，我会让任务至少经过下面这些状态：

text 复制代码

triggered
  -> context_ready
  -> artifact_ready
  -> review_requested
  -> accepted
  -> submitted

异常分支则进入：

text 复制代码

revision_requested | blocked | failed

这里最重要的不是枚举名，而是每次状态变化都要有证据。例如 context_ready 需要来源清单；artifact_ready 需要三份平台差异稿和图片；accepted 需要审核人的明确动作；submitted 需要平台成功页或作品记录，而不是"点击过发布按钮"。

如果团队连"成功"的状态转移都没有定义，计算再精致的成功率也只是绿色幻觉。

一个够用的四指标面板

Workflow Completion Rate

text 复制代码

WCR = reached(done_state) / eligible_triggers

这里的 done_state 要按岗位定义。写作助手可能止于"可验收稿件"，发布助手则应止于"平台确认受理"。被取消或输入不完整的触发要单独计数，不能随意塞进失败或成功。

First-pass Acceptance Rate

text 复制代码

FPAR = accepted_without_major_revision / reviewed_artifacts

建议把 revision reason 做成枚举：事实错误、结构返工、语气偏差、平台不适配、素材问题、工具异常。自然语言备注可以保留，但枚举才方便后续做 Pareto 分析。

Human Review Load

不要只计"审批按钮花了几秒"，而要累计人为补上下文、核事实、改内容和处理异常的活跃时间。

如果人均复核时间持续上升，常见原因不是模型参数不够大，而是岗位输入不稳定、完成定义含糊，或者一次工作塞了太多职责。

Cost per Accepted Delivery

text 复制代码

CPAD = (model_cost + tool_cost + human_review_cost) / accepted_count

把 accepted_count 放在分母，会让无效重试和批量废稿真实地反映到成本上。它也方便比较不同模型路由：便宜模型多次返工，未必比贵模型一次通过便宜。

事件模型可以非常朴素

json 复制代码

{
  "task_id": "content-20260903-01",
  "role": "content_operator",
  "event": "revision_requested",
  "reason": "platform_mismatch",
  "model_ms": 184000,
  "human_review_ms": 420000,
  "tool_cost": 0.18,
  "evidence": ["source-list.md", "platform-check.json"]
}

这只是示意字段，不是通用规范。真实系统还要处理并发、重试幂等、人工接管和跨平台回调。但只要 task_id 能贯穿整条链，就可以从局部调用追到最终交付。

可观测性之外，还要有权限边界

OpenAI 的三个案例有一个共同点：工作越接近外部行动，证据、测试和人工决策越重要。Basis 把稳定入职流程做成可复用 Skill；Clay 把一手证据放在建议旁边；Exa 让 Agent 创建 PR、运行测试，但在真正发出承诺前保留人类判断。

指标不能鼓励 Agent 为了"完成率"绕过这些关口。发布、付款、对外承诺和高风险事实应该是显式 stop point；否则优化目标很可能把谨慎行为当成低效。

为什么岗位化更容易形成有效基线

通用 Agent 的任务分布一直变化，今天生成代码，明天写营销稿，后天分析报表，平均完成率几乎没有解释力。固定岗位后，触发条件、上下文、工具、完成定义和复核方式相对稳定，版本之间才可比较。

这也是我们做 Tipkay 时选择"岗位化 AI"而不是万能聊天入口的原因之一。像博客发布、公众号编辑、视频制作这样的助手，各自围绕一类交付组织流程，并可按计划运行。我们与产品存在直接关系，所以这里说的是产品设计取舍，不把它包装成第三方测评。

但方法本身与产品无关：先选一条重复发生、结果可验收的工作流；定义状态机和证据；记录四项结果指标；最后才决定给 Agent 接多少工具、放多大权限。

一个 Agent 装了 100 个工具，监控面板会很热闹。只有 accepted 和 submitted 稳定增加，系统才真的在创造价值。

参考：

OpenAI, How AI-native companies turn workflows into operating capability（2026-09-01）：openai.com/index/ai-na...
OpenAI, Enterprise Signals（2026-08-12 更新）：openai.com/signals/ent...