Cursor团队分享Agent Harness持续改进的实战方法论 · AI HOT
meng shao@shao__meng精选74
2026-05-05 10:20·59天前
精选理由Cursor 团队把 agent harness 的衡量与定制方法全盘托出，从上下文范式演进到错误分类告警，做 AI 编程工具的必读，这种坦诚的实战分享太稀缺了。
AI 摘要Cursor团队认为，模型能力决定上限，而Harness（模型控制框架）决定其实际表现。他们采用愿景驱动与实验闭环的方法，通过线上A/B测试和离线评估持续优化。随着模型能力提升，Harness设计正从“守卫式”转向“动态获取式”，即减少静态信息注入，赋予模型更多动态获取上下文的权力。衡量体系结合离线基准、在线A/B测试及留存率、LLM判读等质量指标。Harness需为不同模型重度定制，贴合其工具格式与Prompt风格。团队判断AI编程的未来是多Agent协作，其成功关键取决于能协调任务分配与工作流缝合的Harness工程。
meng shao@shao__meng · X 2026-05-05 10:20·59天前
在 X 看原推· x.com精选理由Cursor 团队把 agent harness 的衡量与定制方法全盘托出，从上下文范式演进到错误分类告警，做 AI 编程工具的必读，这种坦诚的实战分享太稀缺了。
AI 摘要Cursor团队认为，模型能力决定上限，而Harness（模型控制框架）决定其实际表现。他们采用愿景驱动与实验闭环的方法，通过线上A/B测试和离线评估持续优化。随着模型能力提升，Harness设计正从“守卫式”转向“动态获取式”，即减少静态信息注入，赋予模型更多动态获取上下文的权力。衡量体系结合离线基准、在线A/B测试及留存率、LLM判读等质量指标。Harness需为不同模型重度定制，贴合其工具格式与Prompt风格。团队判断AI编程的未来是多Agent协作，其成功关键取决于能协调任务分配与工作流缝合的Harness工程。
这就是他们说的 "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 工程过去重要，未来只会更关键。"
上下文窗口的演进：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 工程过去重要，未来只会更关键。"