跳到正文
meng shao· @shao__meng · X·· 2026-05-05AI 评分74
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 工程过去重要,未来只会更关键。"

来源:meng shao · x.com