# Cursor团队分享Agent Harness持续改进的实战方法论

- 来源：meng shao (@shao__meng)
- 发布时间：2026-05-05 10:20
- AIHOT 分数：74
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmos0c9f803x9slrjv53m4oas
- 原文链接：https://x.com/shao__meng/status/2051487288769790223

## 精选理由

Cursor 团队把 agent harness 的衡量与定制方法全盘托出，从上下文范式演进到错误分类告警，做 AI 编程工具的必读，这种坦诚的实战分享太稀缺了。

## AI 摘要

Cursor团队认为，模型能力决定上限，而Harness（模型控制框架）决定其实际表现。他们采用愿景驱动与实验闭环的方法，通过线上A/B测试和离线评估持续优化。随着模型能力提升，Harness设计正从“守卫式”转向“动态获取式”，即减少静态信息注入，赋予模型更多动态获取上下文的权力。衡量体系结合离线基准、在线A/B测试及留存率、LLM判读等质量指标。Harness需为不同模型重度定制，贴合其工具格式与Prompt风格。团队判断AI编程的未来是多Agent协作，其成功关键取决于能协调任务分配与工作流缝合的Harness工程。

## 正文

Cursor 团队这篇「持续改进我们的 Agent Harness」，写的真不错，很实战：
· 如何衡量 harness 的好坏？
· 如何为不同模型定制 harness？
· 中途换模型到底会有什么问题？
· 对未来的判断：Multi-Agent 是 harness 问题
https://cursor.com/blog/continually-improving-agent-harness

Cursor 团队对模型和 harness 的判断：模型的上限决定天花板，但 harness 决定模型实际能跑多远。

# 方法论：愿景驱动 + 实验闭环

· 先有一个"理想 agent 体验"的主观判断，再分解为可验证的假设。
· 通过线上 A/B 与离线 eval 双轨验证，靠仪表化判断每次改动是否真的更好。
· 大改动罕见，常态是"强迫症式地堆叠小优化"。
· 每当拿到新模型早期访问，会花数周专门为该模型重塑 harness，使同一模型在 Cursor 里更快、更聪明、更省 token。

# 上下文窗口的演进：harness 的核心战场

2024 年末的旧范式：守卫式
· 模型自己挑上下文能力差，所以 Cursor 加了大量护栏：每次编辑后回灌 lint/类型错误、读文件行数太少时自动改写、限制单轮工具调用次数。
· 静态注入大量上下文：目录结构、语义匹配的代码片段、被压缩过的用户附件文件。

2026 年的新范式：动态获取式
· 静态上下文大幅瘦身，只保留确实有用的（OS、git 状态、当前/最近查看的文件）。
· 拆掉护栏，把"取什么上下文"的权力交还模型，由它在工作中动态拉取。
· 现在的工作重心是给 agent 提供更多与世界交互的方式，而不是替它准备好一切。

关键启示：随着模型能力提升，harness 设计的趋势是 "减少喂养，增加感官"。

# 如何衡量 harness 的好坏

Cursor 用三层叠加的衡量体系：
1. 离线基准：公开 benchmark + 自研 CursorBench。快、可对比，但只是真实使用的近似。
2. 在线 A/B：把多个 harness 变体并行投放给真实用户。
3. 质量指标--重点在两个"模糊但更重要"的指标：
· 留存率：agent 写的代码在固定时间窗后还有多少留在用户代码库里。被改动越多，说明初版质量越差。
· LLM 判读用户回应：用模型读用户的回复来判定满意度。"用户开始下一个功能" = 成功；"用户贴了个 stack trace" = 失败。

案例：他们曾试过用更贵的模型做上下文摘要，A/B 显示质量提升微乎其微，于是放弃。

# 把 harness 当生产软件来运维：错误分类与告警

随着模型与能力变多，harness 的状态空间膨胀，bug 面变大。工具调用是最大的 bug 表面，且工具错误会污染上下文，让后续决策一起劣化。

错误被分类管理：
· InvalidArguments / UnexpectedEnvironment：模型自身错误或上下文矛盾
· ProviderError：第三方工具（如 GenerateImage、WebSearch）故障
· UserAborted / Timeout 等

告警策略：
· 未知错误 = bug，超阈值即报警。
· 预期错误用按工具、按模型分别建立基线的异常检测，避免被代码库体量等因素误导。
· 每周跑一个 Cloud Agent Automation：让 agent 自己翻日志，发现新问题或激增问题，在 backlog 自动建/更新 ticket，再调度其他 Cloud Agents 去修。
· 一次专项 sprint 把"未知工具错误率"压低了一个数量级。

这就是他们说的 "agent harness 的自动化软件工厂"--用 agent 维护 agent。

# 为不同模型定制 harness

Harness 的所有抽象都是模型无关的，但实际为每个模型重度定制：
· 工具格式贴合训练分布：OpenAI 训练时用 patch 格式编辑文件，Anthropic 用字符串替换。给错工具会让模型多花推理 token、多犯错。
· Prompt 风格分化：OpenAI 模型偏字面、精确；Claude 更直觉化、容忍模糊指令。
· 新模型上手流程：从最接近的现有模型 harness 复制起步 → 离线 eval 找混乱点 → 团队真人试用 → 反复调。
· 真实模型怪癖案例：某模型出现 "context anxiety"（上下文焦虑）--窗口快满时拒绝继续、说"任务太大"。通过 prompt 微调缓解。

中途换模型（mid-chat switching）的难题
· 切模型 → 自动切到该模型对应的 harness（prompts + 工具集）。
· 但对话历史是别的模型生成的，对新模型而言是 OOD 输入。
· 解法：注入 "你正在中途接手另一个模型对话" 的指令；劝阻它去调用历史里出现但当前不属于自己的工具。
· 缓存难题：cache 是按 provider + model 的，切换 = cache miss，第一轮变慢变贵。试过切换时做对话摘要降本，但深度任务里摘要会丢细节。
· 官方建议：除非有理由，否则一段对话用一个模型到底。
· 替代方案：用 subagent 起一个全新上下文的子任务，可以指定模型。

# 对未来的判断：Multi-Agent 是 harness 问题

Cursor 认为 AI 编程的未来是多 agent 协作：规划一个、快速编辑一个、调试一个，各司其职。
让这套体系真正跑通的关键，不是某个更强的单一 agent，而是 harness--它要决定：
· 派哪个 agent 接手
· 如何按目标 agent 的强项重新组织任务描述
· 如何把多 agent 的产出缝合为连贯工作流

结论："harness 工程过去重要，未来只会更关键。"