持续改进 Agent Harness：用真实失败驱动迭代

先说结论

Harness 优化不能只看一次漂亮演示。可靠做法是先提出可证伪假设，再同时看离线任务、真实使用和错误轨迹；模型升级后，还要重新检查旧 guardrail 是否已经变成负担。

原文解决什么

同一个模型放进不同提示、工具和上下文管理方式里，实际表现会明显不同。但“更好”不等于调用更少或速度更快，也不一定能由单一 benchmark 说明。文章介绍 Cursor 如何评估 Harness 变化、追踪工具退化，并针对不同模型调整工具形状和指令。

核心机制

• 静态上下文逐步缩到操作系统、Git 状态和当前文件等少量信息，让更强模型主动拉取其余材料。
• 离线 eval 提供快速可重复的比较，线上 A/B 再观察代码保留、后续用户反馈、延迟和工具错误等真实信号。
• 未知工具错误直接当 Harness bug；预期错误按原因分类，并按“工具 × 模型”建立基线，异常升高才报警。
• 不假设所有模型适合同一套编辑工具、提示和压缩方式。切换模型时，旧历史和旧工具形状也会成为分布外输入。

和 Zero-to-AI 现有实践如何接上

本站现有 npm run verify 是稳定离线门禁，Git diff 和页面人工操作是更接近真实使用的证据。可以把一次失败先记录为“内容错误、工具错误、环境错误或用户中止”，再决定修改教程、脚本还是环境。不要因为某次验证变绿，就立刻把偶然修法写成永久规则。

最小记录不需要建设指标平台：任务编号、模型、唯一改动变量、退出码、人工返工原因五项，就足以避免凭印象迭代。

一个低成本实验

输入： 三个固定小任务：修断链、改 frontmatter、修一个移动端样式；选定同一模型与同一仓库快照。

步骤：

1. 记录基线：每个任务的完成结果、工具错误、总耗时和最终人工返工。
2. 只改一个 Harness 变量，例如在测试用练习仓的 AGENTS.md 增加“先运行最窄检查”的指针；不要把父工作区文件当成站点仓自带配置。
3. 在新 worktree 重跑三题，仍用相同验收。
4. 若改善只来自某一题，保留为场景规则；若错误转移到别处，撤销并分析轨迹。

成功证据： 至少两个任务的验收不下降，目标错误减少，且没有明显增加无关调用或人工返工。

停止线： 样本不足三题、同时改了模型和规则，或只凭主观“感觉更聪明”；这些条件下停止归因，不升级为全局 Harness。

常见误区

• 只追 token、耗时或工具调用数：它们是诊断指标，不等于任务质量。
• 把模型错误都归因于模型：矛盾上下文、陌生工具形状和环境异常同样会制造失败。
• 新模型沿用全部旧补丁：曾经必要的限制可能已经过时，应逐项做消融。

原文与证据边界

Cursor 的 Keep Rate、线上满意度推断、错误率改善和模型差异来自其产品流量与内部评测，本站未独立复现。本文实验只用于本地比较一个小改动，不能推出生产规模的用户满意度。

本文是原创中文实践解读，不是逐句翻译。阅读英文原文。