尧图网页设计 
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 消耗量和PRPull 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 个不同的循环混在一起测会掩盖团队真正要管理的取舍时钟测量什么为什么重要Worker 反馈延迟从动作到有用的测试/构建/追踪信号决定迭代速度Worker 挂钟时长从开始到运行结束占用执行容量、可能阻塞依赖工作同步人类注意力人必须指挥/接力/评审/救援的分钟数决定组织能监督多少工作时间到被接受结果从请求到已证明、被接受或部署的结果汇总队列、重跑、评审和交付两个经典案例说明了为什么它们必须分开⏱️ 在 GPT-5.3 支持后台 Shell 后团队用一周时间从 Makefile 换到 Bazel、Turbo、Nx直到构建回路压缩到 1 分钟以内——这是反馈延迟的胜利与总时长无关 给 Agent 加一条查询未就绪就休眠的指令挂钟时长直接缩短 3 倍底层查询速度根本没变。**实现成本下降时方向、接力、评审、协调、验证、恢复和维护的成本可能原封不动甚至更高。**被实现节省的时间可能以评审负担或未来清理的形式重新出现。三个层次可达性、活跃度、有效利用率度量框架把Agent 在干活拆成三个严格区分的概念️可达性AddressabilityAgent 能触达任务哪些部分仓库访问、本地应用、测试、浏览器、日志、部署和证明能力每加一项可达性就扩大活跃度ActivityToken 和忙碌时长度量的只是活跃度✅有效利用率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 的原始框架维度回答的问题代表性证据outcome结果用户/运营/业务/决策发生了什么变化任务专属的验收与部署行为attention注意力整个任务消耗了多少人力时间引导、接力、评审、QA、协调、恢复分钟数flow流程哪个时钟约束了完成四类时钟的百分位rework返工什么被丢弃、重复或学到尝试、回滚、CI 与评审周期risk风险什么可能失败信心如何建立与声明匹配的证明、事故、回滚、恢复lifetime生命周期未来义务增加了还是减少了依赖、工具、策略、升级与变更负担compute算力被接受的结果消耗了什么Token、推理成本、CPU/GPU、CI 分钟、存储compounding复利同类工作在同一 worker epoch 内改进了吗按 Harness 版本划分的趋势保持这些维度可见、各自独立——一个混合分数会掩盖团队需要管理的取舍。如何开始用两个 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Harness Engineering效能度量：为什么Token数和PR数不是KPI？结果边界测量完整框架
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 消耗量和PRPull 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 个不同的循环混在一起测会掩盖团队真正要管理的取舍时钟测量什么为什么重要Worker 反馈延迟从动作到有用的测试/构建/追踪信号决定迭代速度Worker 挂钟时长从开始到运行结束占用执行容量、可能阻塞依赖工作同步人类注意力人必须指挥/接力/评审/救援的分钟数决定组织能监督多少工作时间到被接受结果从请求到已证明、被接受或部署的结果汇总队列、重跑、评审和交付两个经典案例说明了为什么它们必须分开⏱️ 在 GPT-5.3 支持后台 Shell 后团队用一周时间从 Makefile 换到 Bazel、Turbo、Nx直到构建回路压缩到 1 分钟以内——这是反馈延迟的胜利与总时长无关 给 Agent 加一条查询未就绪就休眠的指令挂钟时长直接缩短 3 倍底层查询速度根本没变。**实现成本下降时方向、接力、评审、协调、验证、恢复和维护的成本可能原封不动甚至更高。**被实现节省的时间可能以评审负担或未来清理的形式重新出现。三个层次可达性、活跃度、有效利用率度量框架把Agent 在干活拆成三个严格区分的概念️可达性AddressabilityAgent 能触达任务哪些部分仓库访问、本地应用、测试、浏览器、日志、部署和证明能力每加一项可达性就扩大活跃度ActivityToken 和忙碌时长度量的只是活跃度✅有效利用率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 的原始框架维度回答的问题代表性证据outcome结果用户/运营/业务/决策发生了什么变化任务专属的验收与部署行为attention注意力整个任务消耗了多少人力时间引导、接力、评审、QA、协调、恢复分钟数flow流程哪个时钟约束了完成四类时钟的百分位rework返工什么被丢弃、重复或学到尝试、回滚、CI 与评审周期risk风险什么可能失败信心如何建立与声明匹配的证明、事故、回滚、恢复lifetime生命周期未来义务增加了还是减少了依赖、工具、策略、升级与变更负担compute算力被接受的结果消耗了什么Token、推理成本、CPU/GPU、CI 分钟、存储compounding复利同类工作在同一 worker epoch 内改进了吗按 Harness 版本划分的趋势保持这些维度可见、各自独立——一个混合分数会掩盖团队需要管理的取舍。如何开始用两个 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考