先说结论：token 只证明机器很忙，交付周期才证明项目成功

AI 项目评测里最容易失真的指标是 session 数和 token 消耗：它们只证明机器很忙；客户核对的是交付周期有没有缩短、产出有没有被组织接受。“把客户现场变成最高保真评测集”指的是：用真实企业环境里的交付周期、被合并 PR（pull request，拉取请求）和故障情况评测 AI Agent，替代实验室基准分数。这套口径出自 Cognition 部署工程负责人 Jia Wu 在 2026 年 6 月 30 日 AI Engineer World’s Fair FDE 议程的演讲，案例口径包括约 150 人工程容量、交付周期缩短约 82%、合并 PR 接近翻倍。FDE 岗位背景见《FDE 是什么岗位》。

从 13% 的 SWE-bench 到“我们现在真的好用了”

演示能力和生产能力之间隔着两年产品迭代：Wu 提到的 13%，指向 Devin 早期在 SWE-bench 上的表现——该基准用真实 GitHub 问题评估代码修复。2024 年发布时，“首位 AI 软件工程师”的叙事引发巨大关注，一周后很多工程师发现它在自己的复杂代码库里经常需要救场；Cognition 后来在旧金山投放的自嘲广告概括了这段变化：“我们现在真的好用了。”两年后的产品答案：让能力对准客户问题，产品市场契合看重叠面积。

写代码只约占问题的 20%

模型写出语法正确的改动，组织也未必敢合并上线——Wu 把编码估为整个问题的约 20%（演讲者估计，非通用研究结论）。用户故事进入 backlog（待办任务清单）后，要先判断影响范围，再理解遗留系统、补测试、通过审查和 CI（持续集成）、协调发布窗口，几年后还有人负责回滚维护；Agent 在中间写出代码，没有自动完成这条链。所以 Cognition 的 FDE 一半时间在客户会议上识别最高杠杆的业务计划，一半时间进代码库验证假设。

三层指标：活动量、交付周期、组织接受度

session 数只是第一层。Wu 把评测拆成三层：

层指标回答的问题局限
活动量session 数、有效工程小时Agent 跑了多少有生产意义的工作像另一种使用量
交付周期部署前后的 ticket、sprint 对比工作是否提前结束可能以质量为代价
组织接受度被合并的 PR产出是否进入主干单看数量会读错信号

三层必须连着看：大量 session 却没有合并 PR，说明 Agent 在反复尝试；PR 增加而项目周期不变，瓶颈已转移到审查、发布或组织协调；周期缩短却故障增加，同样不能称为价值。Wu 称下一阶段为智能编排：整个组织更快还要改积压管理和发布流程——这类改造由谁承担，见《公司要不要组建FDE团队》。

token-maxxing：使用量指标为什么失真

早期 Agent 市场常把使用量当成功：模型成本被补贴时，更多 session、更多 token 的曲线看起来像增长；失败重试都被算成“采用增长”，供应商收入与客户成本同时上涨。演讲把这种堆使用量冲增长的做法称为 token-maxxing；结果指标把问题变严格：一美元模型成本换来了什么。

Cognition 案例口径清单：只能参照，不能当基准

案例数字只有带着口径引用才有价值。以下均为 Wu 演讲中的案例口径，不能当作所有客户都能复制的行业基准：

  • 三个月部署提供约 150 人规模的额外工程容量；
  • 某些项目的交付周期缩短约 82%；
  • 相较单点工具，合并的 PR 数量接近翻倍；
  • 巴西数字银行 Nubank 的 ETL（抽取、转换、加载）迁移：原需约 50 名工程师，按公司口径约三分之一时间完成；
  • 拉美一家大型银行的税务系统迁移涉及 COBOL 与 JCL 等遗留技术，所需人力约减少一半。

共同点只有一个：Agent 被放进了边界清楚、可用完成时间和接受结果衡量的工程任务——看案例先看边界，再看数字。

把客户现场变成评测集：给失败建立形状

实验室基准用预先定义的任务衡量能力；客户现场包含模糊目标、权限、遗留代码和实际代价，所以 Wu 称它为最高保真的评测集。高保真也意味着高噪声：失败可能来自产品缺陷，也可能来自错误配置、缺少权限或代码库没有测试。

FDE 的任务是给失败建立形状：失败出现在哪类仓库、前置条件是什么、多少客户重复遇到、修复后解锁哪类任务。多支团队共用同一种绕行方案（workaround），往往指向应该原生支持的功能。

整理过的现场证据能降低路线图风险：产品团队按缺口影响多少部署排优先级。这与 Ramp 用评分规则（rubrics）约束 Agent 流水线的做法同向，详见《AI项目范围界定（Scoping）怎么做》。

Agent Readiness：自主上限由验证循环决定

把现场变成评测集之后，下一道门槛是验证。Factory 联合创始人兼 CTO Eno Reyes 的口径：一个代码库能让 Agent 自主工作多久，取决于它拥有多少高质量、确定性的验证循环——他称之为 Agent Readiness（Agent 准备度）。类型检查、测试、安全扫描以通过或失败给出机器可读的密集奖励信号。

提升准备度常暴露原有工程问题：构建无法在干净环境重现、测试互相影响、代码所有权不清——补测试、统一构建、明确所有权因此成为 FDE 的第一批价值。Reyes 给出的约 30% 到 40% “低垂果实”可直接交给 Agent、客户环境当前自主程度约 15% 到 20%，均为 Factory 演讲中的项目经验与估计。验证器怎么建，见《FDE的AI工具箱》。

一份结果合同的评测口径（结构示意）

指标定了层次，还要落成合同式字段。下面的 YAML 是“结果合同”评测口径示例——结构示意，非厂商公开规格：

# 结构示意：结果合同（outcome contract）评测口径模板
contract: "发票字段抽取 Agent"
primary_metrics:              # 结果指标
  solve_rate:                 # 解决率
    definition: "无需人工干预即通过全部校验的任务数 / 总任务数"
  handoff_rate:               # 转人工率
    definition: "触发人工接管的任务数 / 总任务数"
  defect_rate:                # 错误率
    definition: "被审查退回或引发缺陷的产出数 / 被合并产出数"
counter_metrics:              # 反指标：上升即警报
  - retry_sessions_per_task     # 单任务平均重试 session 数
  - avg_tokens_per_solved_task  # 单个解决任务的平均 token 消耗
review_cadence: "每周对照交付周期与被合并 PR 复盘一次"

解决率、转人工率、错误率对应客户感知的三种结果，反指标防止“解决率靠反复重试刷出来”；复盘时对照三层指标表：活动量和结果放在一起看。

常见问题

AI Agent 评测该看哪些指标？

活动量、交付周期、组织接受度三层连着看，外加故障率作质量底线，只报 session 数等于只证明机器很忙。

三层分别回答 Agent 跑了多少、项目是否提前结束、产出是否进入主干；session 多而无 PR 是反复尝试，故障增加仍不算价值。

token 消耗高说明 AI 用得好吗？

不说明。token 只证明运行量，失败重试和无效探索都会推高消耗，这种堆使用量冲增长的做法就是 token-maxxing。

替代做法是把反指标写进评测合同：单任务重试 session 数、单解决任务平均 token 消耗上升即警报。

怎么把客户现场变成评测集？

给失败建立形状：记录失败出现在哪类仓库、前置条件是什么、多少客户重复遇到、修复后解锁什么。

现场是最高保真也最高噪声的评测集，失败要先归因再上报；多支团队共用的 workaround 往往指向该原生支持的功能。