跳转至

cursor harness model production floor

Ch01.235 cursor harness model production floor

📊 Level ⭐⭐ | 15.3KB | entities/cursor-harness-model-production-floor.md

Cursor 复盘 Harness：模型决定能力上限，Harness 决定生产下限

原文存档：原文存档

  • 这次重点不在解释 Harness 是什么，而在回答一个更实际的问题：当 Harness 开始承重，团队怎么持续运营它。
  • Agent 质量不能只看模型分数。更准确的发布单元，是"模型 + Harness"的组合。
  • Cursor 早期靠大量静态上下文和护栏兜底，现在更多转向动态上下文。模型变强以后，旧护栏要定期重测，有些该删掉。

太长不看

核心结论速览：

  • 发布单元：不是单独的模型，是模型 + Harness 组合
  • 评估三层体系：离线评测（CursorBench）+ 线上 A/B + 代理指标（Keep Rate / 语义反馈）
  • 上下文范式转移：从静态上下文塞入 → 动态按需拉取，窗口只承载当前推理不负责保存全部历史
  • 错误是上下文污染源：工具失败留在 context 里消耗 token 并可能污染后续决策
  • 多智能体关键在调度：不是角色数量，是 Harness 能否决定"调度谁、怎么描述任务、怎么合并结果"

核心洞察

模型决定上限，Harness 决定下限

模型决定系统能理解多复杂的任务、能否在陌生问题里做像样的推理。但"生产下限"是另一件事：上下文不完整、工具超时、日志很脏、用户需求含糊、模型中途切换、缓存突然失效时，系统还能不能把任务稳稳带下去。

把 Harness 当线上系统运营

Cursor 把这种手感做成了可重复的工程动作：说清假设 → 跑离线评测 → 看线上反馈和错误切片 → 决定回滚/调优/清旧补丁。目标三角是"更快、更聪明、更省 token"——这三件事天然在打架，Harness 的日常工作就是在这个三角里找平衡。

从静态上下文到动态上下文

2024 年末 Cursor 靠大量静态上下文兜底（lint 回灌、改写读取请求、限制调用次数、塞目录结构）。现在更多转向动态上下文——大块信息不必提前塞进窗口，可以在模型需要时通过引用拉取 MCP 工具、活跃终端、历史对话等外部信息。关键转变：上下文不是越多越好，而是越会取越好。

评估三层体系

Cursor 的三层评估体系 ：

  1. 离线评测：CursorBench 基于真实 Cursor 会话，覆盖正确性、代码质量、效率、交互行为
  2. 线上 A/B：延迟、token 效率、工具调用次数、缓存命中率

  3. 代理指标：

  4. Keep Rate：Agent 生成的代码改动，过一段固定时间后还有多少留在用户代码库里

  5. 后续反应判读：用模型读取用户下一句话，从语义上判断是否满意

迁移思路可推广到其他 Agent 类型：客服 Agent 看"回答后用户是否继续追问同一问题"；写作 Agent 看"生成段落最终保留比例"；数据分析 Agent 看"生成 SQL 有没有被执行"。

工具报错是上下文污染

工具调用失败的影响往往不止当下那一轮——失败信息会留在上下文里，消耗 token，也可能污染后续判断。Cursor 用 SRE 风格错误分类（按每个工具、每个模型分别计算基线）：InvalidArguments（模型传参错）、UnexpectedEnvironment（上下文环境假设和真实环境矛盾）、ProviderError（工具提供方异常）、UserAborted（用户主动中止）、Timeout（超时），以及默认按 Harness bug 处理的未知错误。

关键判断：Agent 的错误不是均匀分布的。某个模型更容易把 patch 格式写错；另一个更容易过度调用搜索；某个工具在大仓库里更容易超时。只看总量，很容易被平均数骗过去。

换模型不只是改一个 model id

Harness 抽象可以模型无关，但每个模型都需要深度定制 ：

  • OpenAI 模型训练时更习惯基于 patch 的方式编辑文件；Anthropic 模型更习惯字符串替换
  • OpenAI 偏字面理解、强指令遵循；Claude 对模糊指令更宽容

中途切模型的挑战在于新模型要接手旧模型生成的对话历史（工具调用形态、提示风格、上下文分布可能不匹配），且缓存是提供商和模型特定的，中途切模型会让缓存未命中。

多智能体的关键在调度

AI 辅助软件工程会走向多智能体，但重点在后半句：系统要知道调度哪个 Agent、怎么按它的优势描述任务、怎么把结果整合回一个连贯工作流。Claude Code Subagents 的适合隔离场景：高输出任务（测试、日志、文档查找）、并行研究独立模块、需要专门工具权限/模型/Prompt 的子任务；不适合场景：需要频繁来回讨论、多阶段共享大量上下文、很小的目标修改。

深度分析

1. "模型 + Harness" 作为发布单元的工程含义

Cursor 最核心的洞察是把 Agent 的发布单元从"模型"升级为"模型 + Harness 组合"。这不只是命名上的调整，而是改变了整个发布流程的风险模型 。当团队升级模型时，需要验证的不只是模型能力本身，而是该模型与现有 Harness 的交互质量。这相当于后端服务升级时的回归测试范围扩大——不仅要测新版本的某个模块，还要测整个集成。

这个设计隐含了一个重要的工程债务：随着支持的模型数量增加，测试矩阵呈 n×m 增长（n 个模型 × m 个工具/提示版本）。Cursor 的建议是"没有明确理由，复杂会话最好保持在同一个模型里"——这是对测试成本扩张的一种主动约束。

2. 动态上下文 vs 静态上下文：Token 经济学的范式转移

Cursor 从"静态上下文塞入"转向"动态上下文按需拉取"，背后是对 Token 经济学更激进的优化 。传统做法（塞入 lint 规则、目录结构、历史摘要）本质上是用 Token 换确定性——预加载所有可能需要的信息，让模型不必探索。但随着模型推理能力变强，这种确定性的代价（大量 Token 开销 + 陈旧信息污染）超过了它带来的收益。

动态上下文的核心是引用语义：模型接收的不再是文件内容本身，而是一个指向外部信息源的引用（文件路径、终端状态、历史对话片段）。这要求模型理解引用的语义——"收到一个路径引用后，模型是否能正确理解这个引用指向什么？"如果模型不能可靠地解读引用，动态上下文就退化为一种更慢的静态上下文。

Cursor 的配套工程实践（每年主力模型升级后做 dead weight 清理）值得注意：这意味着 Harness 本身也在"演化"，需要定期修剪那些模型已经能自主处理的老护栏。 这是一个反直觉的设计——通常我们认为"护栏越多越安全"，但 Cursor 的经验表明，过时的护栏反而会浪费模型的推理预算。

3. Keep Rate：重新定义 Agent 质量的代理指标

Keep Rate（Agent 生成内容在固定时间窗口后的保留比例）是这篇文章最有价值的评估创新 。传统评估指标（正确性、benchmark 分数）衡量的是 Agent 的"能力上限"，Keep Rate 衡量的是 Agent 的"生产价值"——用户真正用了多少 Agent 生成的内容。

这个指标的优势在于它是端到端的：不需要人工定义"什么是好代码"，只需要看用户最终接受了多少。缺点是它不能区分"Agent 做得很好所以被接受"和"用户懒得改所以被迫接受"——需要配合语义反馈（"后续反应判读"）来消除歧义 。两者结合构成了一套"行为 + 价值"双维度的评估体系。

4. 工具错误的非均匀分布：SRE 方法论在 Agent 系统的应用

Cursor 把 SRE（Site Reliability Engineering）方法论系统性地引入 Agent 系统：错误分类不是按"成功/失败"二分，而是按工具 × 模型维度分别建立基线 。这个方法的深层价值在于它改变了问题定位的方式——从"Agent 犯错了"变成"在模型 X + 工具 Y 的组合下，Agent 更容易犯错误类型 Z"。

这种精细化的错误建模，使得"每次 Agent 犯错都反向沉淀成一条 Harness 设计"成为可能 ——每一次真实的工具失败，都成为改进 Harness 的信号。这是一个持续改进的闭环，而非一次性的护栏设计。

5. 多智能体的调度抽象：比角色划分更本质的问题

文章指出了一个微妙但重要的区分：多智能体的关键不在"有多少个角色"，而在"Harness 能不能调度谁" 。这意味着多智能体系统的核心抽象不是"角色"，而是路由规则：什么条件下触发哪个 Agent、如何描述任务使得该 Agent 能正确执行、如何合并不同 Agent 的结果。

Claude Code Subagents 的设计实际上就是这种路由抽象的具体实现 ：适合隔离的场景（高输出、并行、独立上下文）vs 不适合的场景（来回讨论、共享上下文、小修改）。这些边界条件定义了一个多智能体系统的调度语义，比"有 3 个 Agent 角色"更有工程价值。

实践启示

对 Agent 团队的建议

  1. 建立三层评估闭环：离线评测（CursorBench 类）用于回归验证，线上 A/B 用于效率监控，代理指标（Keep Rate / 语义反馈）用于价值验证。三者缺一不可——前两者测能力，最后者测价值。

  2. 每年模型升级后做一次护栏审计：Harness 不是一次性工程，需要随模型能力成长而演化。旧护栏要么删掉，要么更新——留下来只会浪费推理预算。关键检查：模型现在能自主处理哪些场景？这些场景的护栏是否可以移除？

  3. 按工具 × 模型维度建立错误基线：不要只看 Agent 的总错误率，要分解到"工具 + 模型"组合上。这才能发现特定组合的系统性弱点，而不是被平均值掩盖。

  4. 不要中途切模型：复杂会话中切换模型会面临上下文格式不匹配、缓存失效、推理状态丢失三重问题。如果必须切换，按状态迁移处理而不是简单的 model id 替换。

  5. 每次 Agent 失败都沉淀为 Harness 改进：建立从"错误事件 → Harness 改进"的闭环。每次失败都是一次真实世界测试，积累下来就是 Agent 系统的运维经验库。

对 Harness 设计者的建议

  1. 区分动态上下文和静态上下文的适用场景：静态上下文适合"模型缺乏自主探索能力"的阶段；动态上下文（引用语义）适合"模型具备主动探索能力"的阶段。选择取决于模型能力，而非绝对的优劣。

  2. 模型适配要有版本管理：Prompt 版本、工具 schema 版本、上下文策略版本、错误基线——这些都需要纳入版本控制。每次模型切换时，这些版本组合都要重新验证。

  3. Subagent 描述要像路由规则：不是描述角色身份，而是描述触发条件、输入格式、输出预期、边界责任。"负责什么/什么时候调用/不负责什么"比"是后端 Agent 还是前端 Agent"更有调度价值。

对评估框架设计者的建议

  1. 代理指标的跨域迁移：Keep Rate 思维可以迁移到任何 Agent 类型。客服 Agent →"回答后用户是否继续追问"；写作 Agent →"生成段落最终保留比例"；数据分析 Agent →"生成 SQL 有没有被执行"。这个模式的关键是找到 Agent 输出的"最终消费者行为"。

  2. 错误分布的非均匀性检测：设计评估框架时，不仅要测 Agent 在标准场景下的正确率，还要在特定工具 × 模型组合下注入异常，观察 Agent 的错误模式是否系统性地偏向某种类型。这能发现 Harness 设计中的盲点。

  3. 把上下文预算做成可观测指标：Harness 运营中，"上下文用了多少 token"和"模型推理了多少步"同样重要。上限不是 128K 或 200K，而是"达到多少上下文量时 Agent 质量开始下降"。这个边界值是 Harness 调优的关键参考。

关联阅读

相关实体