Agent 跑满一天不等于多一个人：用四个指标算真实产能

我见过一种很有诱惑力的 Agent 看板：

text 复制代码

运行时长：11.6 小时
并发峰值：7
生成文件：34
任务成功：29

问题是，发布列里仍然是 0。

34 个文件中，有些是中间日志，有些被审阅退回，有些只是同一任务的旧 revision。把这些数字相加，再除以 8 小时，很容易得出"今天多了一个员工"的结论。

但组织买的不是 Agent 在线时长，而是可进入下一环节的结果。

先把看板数据改成事件

不要让任务表反复覆盖成一个最终 success。先保留最小事件流：

ts 复制代码

type WorkEvent =
  | { kind: "started"; jobId: string; unit: string; ts: number }
  | { kind: "output"; jobId: string; rev: number; ts: number }
  | { kind: "intervention"; jobId: string; minutes: number; code: string; ts: number }
  | { kind: "rejected"; jobId: string; rev: number; code: string; ts: number }
  | { kind: "accepted"; jobId: string; rev: number; firstPass: boolean; ts: number }
  | { kind: "delivered"; jobId: string; rev: number; ts: number };

这里最重要的约束不是字段多少，而是：

output 不等于 accepted；
accepted 不等于外部动作已经完成；
人工介入必须有分钟数和原因码；
验收证据绑定 revision，旧版本的成功不能污染新版本。

四个指标构成一张最小产能表

1. Accepted throughput

text 复制代码

已验收吞吐量 = 观察窗口内 accepted 的交付单元数 / 窗口小时

交付单元必须提前定义。比如"发布说明包"包含变更事实、用户影响、回滚说明、两个渠道版本和最终审阅结果。只生成正文不能算一单。

2. First-pass yield

text 复制代码

一次通过率 = 没有 rejected 事件的 accepted 单元 / accepted 单元

它把"10 单都交了，但每单都要人改一遍"和"10 单里 8 单直接可用"区分开。

3. Human minutes per accepted unit

text 复制代码

每单人工分钟 = Σ intervention.minutes / accepted 单元

这个指标不能用来追求"零人工"。高风险发布、财务或对客承诺本来就应该有人把关。更有用的做法是给介入原因分组：

ts 复制代码

type InterventionCode =
  | "REQUIRED_APPROVAL"
  | "MISSING_INPUT"
  | "FACT_CORRECTION"
  | "STYLE_REWRITE"
  | "TOOL_RECOVERY"
  | "SCOPE_DECISION";

必要审批是治理成本；事实纠错和工具恢复则更接近自动化缺口。两者不能混在一个"需要人工"的桶里。

4. Oldest WIP age

text 复制代码

最老在制品年龄 = now - 最老未验收任务的最后实质进展时间

待验收数量为 5，看起来不多。但如果最老的一单卡了 72 小时，里面的资料、价格或代码基线可能已经过期。

一条 SQL 就能先跑起来

假设事件落在一张窄表中：

sql 复制代码

create table agent_work_event (
  job_id varchar(64) not null,
  unit_type varchar(64) not null,
  revision int,
  event_type varchar(32) not null,
  intervention_minutes int default 0,
  reason_code varchar(64),
  occurred_at timestamp not null,
  primary key (job_id, revision, event_type, occurred_at)
);

按天聚合验收吞吐量和人工分钟：

sql 复制代码

select
  unit_type,
  count(distinct case when event_type = 'accepted' then job_id end) as accepted_units,
  sum(case when event_type = 'intervention' then intervention_minutes else 0 end) as human_minutes,
  sum(case when event_type = 'rejected' then 1 else 0 end) as rejected_events
from agent_work_event
where occurred_at >= :window_start
  and occurred_at < :window_end
group by unit_type;

真正的系统还要处理撤回、跨窗口返工和 revision 去重，但这个表已经比"总成功数"更难自我欺骗。

为什么运行时长仍然值得保留

它不是垃圾指标，只是位置放错了。

Agent runtime、Token 和费用适合回答：哪类任务最耗资源、哪个模型档位成本异常、缓存是否生效、任务是否陷入无进展循环。它们属于资源账和诊断账。

OpenAI 9 月 6 日披露，其研究组织截至 8 月中旬按 8 小时工作日换算，使用约 3.1 个 Agent 工作日/每个人类工作日。但同文没有把这个数字直接叫作 3.1 倍生产率。它明确指出整体研究进展受多种瓶颈限制，并在方法附录中说明：代码量、使用量容易测量，却很难解释与真实进展的关系。

OpenAI：Research acceleration: The view inside OpenAI

同文还称，在可找到真实结果的任务中，超过一半成功的 4---8 小时任务至少有一次人工介入。这里不能外推到普通公司，但足以提醒我们：介入成本不应从产能表里消失。

验收口比生成端窄时，要主动降并发

设想一个小团队的发布说明流水线：三个 Agent 分别整理提交记录、改写渠道稿、生成配图；最后只有一名负责人核对事实和决定发布。

上游每小时能产出 9 个包，负责人每小时只能验收 2 个。把 Agent 并发再翻倍，不会把交付变成 18 个，只会让 backlog 更快增长。

一个够用的 admission controller 可以非常朴素：

ts 复制代码

type CapacitySnapshot = {
  pendingReview: number;
  oldestWipMinutes: number;
  expectedHumanReviewMinutes: number;
  availableHumanMinutes: number;
};

function admit(snapshot: CapacitySnapshot, priority: "high" | "normal") {
  if (priority === "high") return { allowed: true };

  const overloaded =
    snapshot.pendingReview >= 8 ||
    snapshot.oldestWipMinutes >= 180 ||
    snapshot.expectedHumanReviewMinutes > snapshot.availableHumanMinutes;

  return overloaded
    ? { allowed: false, reason: "REVIEW_BACKPRESSURE" }
    : { allowed: true };
}

被拒绝启动的任务不要假装失败。它应进入排队或取消状态，并带上重新评估时间。已经接近完成、会阻塞多个下游或有明确时限的任务，可以保留优先通道。

三个会让报表越来越好看的坑

第一，把一份完整交付拆成许多小步骤，每个都记成功。成功率上升，但交付没增加。

第二，人工在提交前大幅改写，却仍记成 Agent 一次通过。系统把人的劳动藏起来了。

第三，把客服分类、技术方案和对外发布混成一个平均数。低难度任务会掩盖高风险任务的返工。

解决方法分别是：固定交付单元、记录人工改写、按 unit_type × risk_level 分桶。报表宁可少一个总分，也不要把不可比较的工作硬算成"平均人效"。

放到垂类 AI 员工里看

这也是我们做 Tipkay 时的一个取舍。Tipkay 面向小微企业、一人公司和小团队提供按需使用的垂类 AI 员工。每个岗位助手有自己的经验、流程、Skill、MCP 和工具，并能在不同工作之间接力。

这种分工是否有效，不能只看同时运行多少个助手。内容岗位要走到事实核验、平台改写、配图、排版、后台预填和页面回读，才形成可验收的内容包；其他岗位也应该有各自窄而真实的交付契约。

这不是客户效果数据，而是一套通用测量原则。小团队的第一版也不需要复杂数仓：先记录任务类型、是否首次通过、人工分钟、最终验收时间和最老 WIP，就足以决定下一步是增加 Agent，还是先扩充验收能力、补资料或收紧在制品。

Agent 跑满一天，说明资源被使用了一天。只有当可验收吞吐量提高、每单人工成本没有失控、在制品没有持续老化时，我们才更有把握说：团队真的多了一部分产能。