企业官网建设流程全解析

Harness Engineering效能度量：为什么Token数和PR数不是KPI？结果边界测量完整框架

【免费下载链接】harness-engineering🐎 Ryan Lopopolo’s anthology, field guide, and agent context bundle for harness engineering项目地址: https://gitcode.com/gh_mirrors/har/harness-engineering

在 Harness Engineering（驾驭工程）实践中，很多团队习惯用Token 消耗量和PR（Pull Request）数量来衡量 AI Agent 的产出。但 Ryan Lopopolo 在这个开源项目里给出了一个反直觉的结论：PR、代码行数、Token 总数都不能单独证明价值，真正该度量的是"结果边界"（Outcome Boundary）上被用户、运维或决策者接受的成果。本文带你完整理解这套 Harness 效能度量框架：为什么虚荣指标会误导团队、如何用"四个时钟"正确衡量时间、如何区分探索与浪费，以及一张可直接落地的 8 维度量清单。

为什么 Token 数和 PR 数不是 KPI？

项目的核心论文明确指出：一个 pull request、代码行数、计划文档、Token 总量或生成的产物，可以为结果做贡献，但没有一个能单独建立价值（详见 docs/effectiveness/README.md）。

几个典型陷阱：

• 📊Token 排行榜会奖励"上涨的信号"——消耗量可以一路飙升，而实际价值原地踏步；
• 💸与价值脱钩的花费对 ROI 几乎没有说明力；
• 🎯效能（effectiveness）才是目标，输入量只是成本。

一个著名的对比案例：Ryan 的60 小时重构，Codex 连续运行 3~4 天，消耗约3.3 亿~3.5 亿 Token、花费约 2800 美元，最终只产出了1 个 PR——但这次重构他估算手工需要 3 周，且只需初始提示加 2 次跟进。如果按 Token 数考核，这是一笔"昂贵"的开销；如果按结果边界考核，它用极小的同步人力换掉了 3 周的实现工作。同样的数字，不同的测量边界，得出完全相反的结论。

结果边界测量：从用户体验到起点

结果边界测量的第一步，是站在结果被体验的地方开始：

💡画门实验（painted door）是最好的例子：团队先实现了一个定时任务功能，后发现架构耦合失控，于是回滚实现、保留一个"空后端"的完整界面去测量用户是否真的需要它。最终被接受的成果不是代码，而是支撑产品决策的证据。这类"决定不构建"的验证结果，PR 数量完全无法体现。

关键原则：在代理指标开始看起来像成功之前，先声明整个任务的边界和它的证明方式（参见 docs/whole-job/README.md）。

四个时钟：把"时间"测对

"延迟"其实描述了至少 4 个不同的循环，混在一起测会掩盖团队真正要管理的取舍：

两个经典案例说明了为什么它们必须分开：

• ⏱️ 在 GPT-5.3 支持后台 Shell 后，团队用一周时间从 Makefile 换到 Bazel、Turbo、Nx，直到构建回路压缩到 1 分钟以内——这是反馈延迟的胜利，与总时长无关；
• 😴 给 Agent 加一条"查询未就绪就休眠"的指令，挂钟时长直接缩短 3 倍，底层查询速度根本没变。

**实现成本下降时，方向、接力、评审、协调、验证、恢复和维护的成本可能原封不动，甚至更高。**被实现节省的时间，可能以评审负担或未来清理的形式重新出现。

三个层次：可达性、活跃度、有效利用率

度量框架把"Agent 在干活"拆成三个严格区分的概念：

1. 🗺️可达性（Addressability）：Agent 能触达任务哪些部分？仓库访问、本地应用、测试、浏览器、日志、部署和证明能力，每加一项，可达性就扩大；
2. 🔥活跃度（Activity）：Token 和忙碌时长度量的只是活跃度；
3. ✅有效利用率（Productive Utilization）：到达被接受结果、或产出可复用证据的活跃度。可预防的丢弃、评审和修复都会削减它。

高利用率是一个"强制函数"——它逼你暴露生命周期中不可达的部分：空闲时间可能意味着缺少上下文、工具、权限或可观测性；而忙碌的 Agent 也可能在高速生产被拒的补丁。后来的表述给 Token 量加了一道结果闸门：工作必须进入 main 分支，并改进用户体验。

区分探索、返工与浪费

丢弃不一定是浪费。框架给出了清晰的判别标准：

• 🧪探索：当一次尝试解决了影响后续工作的高不确定性时，丢弃是生产性的。Ryan 的"大型一次性探针"模式：让 Agent 产出约5 万行 diff 的探索性 PR，推上去检视后整体丢弃——留下的是失败地图和约 15 个预备性 PR；
• 🔁返工：统计尝试次数、CI 周期、评审者周期、回滚和重复的失败类别；
• 🗑️浪费：在没有新证据的情况下重复已知失败，就是浪费。

配合MLD 遥测（Mistakes / Learnings / Desires，见 docs/feedback/mld.md），让 Agent 在运行中记录自己的错误、发现和愿望，重复的失败类别就应该被"提升"进环境：变成上下文、工具、测试或架构约束，而不是一次次靠人纠偏。

全生命周期计价与复利效应

效能度量的账本从模型算力和人类注意力开始，但必须继续延伸到证明、恢复、运行和维护。廉价生成降低了探索成本，但仓库会保留变更带来的所有义务——依赖数量、升级工作量、策略复杂度、标准漂移、事故暴露面，都该记在同一笔账里。

更有说服力的是纵向证据：OpenAI 团队用 Codex 从空仓库开发内部产品 5 个月，约100 万行代码、1500 个合并 PR、零手工代码。早期进展比预期慢，但随着 Harness 本身生长，吞吐随团队和 Harness 一起上升——后来的工作继承了早期工作编码的能力与判断。这正是"复利"：Harness 只有在同类任务持续改进到足以覆盖其建设和维护成本时，才算赚回了它的持有成本。

⚠️ 注意一个陷阱：模型或编码 Agent 发生实质变化时，要开启新的worker epoch（固定 Worker 原则，见 docs/fixed-worker/README.md），重新校准上下文、工具与雄心设定——否则更强的 Worker 或更简单的任务组合，会伪装成 Harness 的改进。

落地清单：8 维效能度量表

对每一个被接受的结果，记录以下 8 个维度（来自 docs/effectiveness/README.md 的原始框架）：

保持这些维度可见、各自独立——一个混合分数会掩盖团队需要管理的取舍。

如何开始：用两个 Playbook 验证你的度量

• 🔬 小步验证：用 playbooks/improve-harness.md 跑一个"基线 → 最早断点 → 最小干预 → 全新重跑"的有界循环，在固定 Worker 下观察一次干预是否真的改变了结果；
• 📐 对比评估：用 evals/README.md 的《Evaluate the Harness》方法做跨条件的对照评估。它明确列出了无效结果的情形，其中一条正中本文主题——"Token 数、行数或活跃度替代了被接受的结果"，这样的评估不能支撑任何结论。

仓库的完整导航见 ARCHITECTURE.md，理论索引见 docs/README.md。把这套结果边界测量框架带入你的团队后，下个月复盘时你可以直接问：哪些被接受的结果发生了？它们各自消耗了哪几个时钟？以及，同类任务比上一个 epoch 更容易了吗？这三个问题，比任何 Token 和 PR 排行榜都更接近"效能"的本义。

【免费下载链接】harness-engineering🐎 Ryan Lopopolo’s anthology, field guide, and agent context bundle for harness engineering项目地址: https://gitcode.com/gh_mirrors/har/harness-engineering