AI 编程质量不够好，问题可能不在模型，在 Harness

大家好，我是 Immerse

专注分享 AI 玩法、独立开发与AI 出海的 AGI 实践者

用同一个模型，只改外面那层"壳"，编程基准成功率从 42% 跳到 78%。这是国外 Nate B Jones 今年做的研究，变量只有一个：Harness。

Harness 这个词 2026 年 2 月才开始在 AI 圈爆火。

模型相当于是引擎，引擎能不能跑出成绩，就要看外面那套系统怎么设计。

Harness（直译是马具、缰绳）指的就是包裹模型的那层运行框架：约束规则、反馈链路、工具链、上下文管理，这些加在一起决定了 AI Agent 最终能产出啥

为什么现在开始讲这个

过去几年 AI 编程经历了三个阶段。

Prompt Engineering 时代（2022-2024），大家研究怎么把指令写漂亮，让模型一次就写出可用的代码。

Context Engineering 时代（2025），把项目文档、代码库都喂给模型，让它懂业务背景再写代码。

到了 Harness Engineering 阶段，问题换了，不是"怎么跟 AI 对话"，而是让 "AI 在自主干活的时候，你怎么更好严格控制它"。

HashiCorp 联合创始人 Mitchell Hashimoto 今年 2 月在博客里把 AI 编程分成六个阶段，第五个阶段叫 Engineer the Harness，他的定义只有一句话：

每当你发现 Agent 犯了一个错误，你就花时间去工程化一个解决方案，让它再也不会犯同样的错。

规则文件里的每一行，背后都对应一个 Agent 犯过的错。

OpenAI 的实验

OpenAI 发了篇报告，专门做了次实验项目

Codex 团队从一个空 git 仓库开始，5 个月，大概 100 万行代码，1500 个 PR，全部由 Agent 生成，人一行代码都没写。

团队从 3 个工程师扩到 7 个，平均每人每天合并 3.5 个 PR。核心工程师 Ryan Lopopolo 的总结就一句话：Agent 不难，Harness 才难。

他们做了三件事：

仓库就是大脑。代码、markdown、schema、可执行计划全都版本化存在仓库里。Agent 看不到仓库之外的东西，所以在这个仓库里必须有 Agent 工作的所有资料。随着项目推进，越来越多的"隐性知识"需要显性化推入仓库，以前靠老员工口头传授的东西，现在必须写成文档，因为 Agent 不会来问你。

代码要对 Agent 可读。Agent 理解代码的方式跟人类不一样，它更依赖结构化线索：严格的分层架构、一致的命名模式、显式的类型定义。那些对人类"一看就懂"的隐含约定，对 Agent 可能是盲区。这是新的可读性标准，他们管它叫 application legibility。

架构约束靠 linter，不靠 prompt。告诉 AI "请遵守分层架构"是软约束，没用。他们的做法是用确定性的 linter 和结构化测试来机械执行，Agent 违反了架构规则，CI 直接挂掉，没有任何讨价还价的余地。而且 linter 的报错信息里包含了修复指引，告诉 Agent 应该怎么改。

Anthropic 工程师的多 Agent 实验

Anthropic Labs 工程师 Prithvi Rajasekaran 做了一个不一样的实验，专门研究怎么让 Agent 持续跑几个小时不跑偏。

他发现 AI 有两个常见失效模式：上下文窗口快满时失去连贯性，以及自我评估时倾向于称赞自己的工作（即使质量明显平庸）。

他的解法是拆开"做工作的 Agent"和"评判工作的 Agent"。借鉴 GAN（生成对抗网络）的思路，搭了三个 Agent 的架构：

• Planner：接一句话需求，扩展成完整产品的形式
• Generator：按 sprint 逐功能实现，每个 sprint 结束后自我评估再交 QA
• Evaluator：用 Playwright MCP 像用户一样点击运行中的应用，测 UI 功能、API 端点、数据库状态，每个标准有硬性阈值，任何一项低于阈值，sprint 失败，Generator 获得详细失败反馈

同一个单句提示，单 Agent 跑了 20 分钟、花了 ，产出的游戏完全损坏；三个跑了小时、花了200，游戏能玩，还有完整的精灵编辑器和内置 Claude 集成。

Opus 4.6 发布后他又简化了 harness，移除了 context reset 和 sprint 构建（因为 4.6 原生支持更长任务），但保留了 Planner 和 Evaluator。他的结论：Harness 里的每个组件都编码了一个假设——假设模型无法独立完成某件事。这些假设值得随模型进化定期重新测试。

行业在怎么做

数字说话：

LangChain 团队在同一个模型上只改 Harness，Terminal Bench 2.0 排名从三十名外冲进前五，成绩从 52.8% 升到 66.5%。

Vercel 把 Agent 的工具从 15 个砍到只剩 2 个，准确率从 80% 升到 100%。工具越少，Agent 越知道该用哪个。

Stripe 内部的 Minions 系统每周合并 1300 多个 AI 生成的 PR，无人值守。他们有个硬性规定：CI 最多跑两轮，跑两次还不过直接交给人类，不允许 Agent 无限重试。

约束解空间，反而让 Agent 更有生产力。自由度越大，越容易跑偏。

几个可以马上用的配置

• AGENTS.md / CLAUDE.md：在仓库根目录放一个规则文件，60 行以内，写架构约定和命名规范，别写百科全书。每次 Agent 犯错就加一条规则。
• 硬约束替代软指令：linter、类型检查、pre-commit hooks。Agent 无法绕过的东西，比 prompt 里说"请遵守"管用得多。
• 工具精简：别一口气把所有工具都给 Agent，按任务类型给对应子集。
• 反馈闭环：让 Agent 写完代码后自己跑测试、看日志，不要所有验证都靠人工。
• CI 限速：设一个最大重试次数，超了就停，交给人类。

Philipp Schmid 的建议：Start Simple. Build to Delete. 先搭最薄的一层，随着 Agent 犯错不断加规则，随着模型进化不断减组件。