Harness Engineering: Why the Best AI Engineers in 2026 Stopped Writing Code 提出了一个简单但颠覆性的观点：决定 AI 编程质量的不是模型本身，而是模型外面那层系统——harness（缰绳）。
一个数据点改变了问题的定义方式
有研究者用同一个 AI 模型跑同一套编码基准测试，第一次得分 42%，第二次 78%。模型没换，测试没换，温度没调，prompt 也没改。唯一变了的是 harness——包裹在模型外围的规则、工具、技能文件、记忆和反馈回路。
LangChain 独立验证了同样的结论：他们的 coding agent 在 Terminal Bench 2.0 上从前 30 开外直接冲进前 5，模型没动，只改了 harness。OpenAI 的 Codex 团队更激进——他们用 agent 构建了一个超过一百万行代码的生产应用，其中零行由人手写。工程师的工作不是写代码，而是设计 harness。
这就是 harness engineering（缰绳工程）的由来。这个术语几周前才被造出来，已经在 YouTube 和工程博客上开始流行，但主流开发者社区还几乎没有讨论。
缰绳是什么
用骑马来类比：模型是马，很强壮，但没有缰绳、鞍座和嚼子，马会往它想去的方向跑。AI coding agent 也一样——没有设计过的 harness，它会猜测、漂移、重复犯同样的错误，写出看起来很棒但在生产环境会崩的代码。
Terraform 的创建者 Mitchell Hashimoto 把这个理念浓缩成一句话：
Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.
不要祈祷更好的模型。修复模型周围的系统。
五个可调的杠杆
每个 coding agent 都有五个配置点，拉对了杠杆，同一个模型能产出截然不同质量的代码。
System prompt（系统提示文件）——放在仓库根目录的 CLAUDE.md 或 AGENTS.md，每次会话开始时注入 agent 上下文。ETH Zurich 的一项研究测试了 138 个 agent 文件，发现 AI 自动生成的版本反而损害性能，还多花 20% 的 token；人写的版本有效，但前提是简洁和具体。规则：控制在 60 行以内，只写对所有任务通用的指令——技术栈、测试命令、编码约定、硬性规则。不放目录清单（agent 自己能发现结构），不放条件逻辑（“如果做 X 就 Y”会制造混乱）。
Skills（技能文件）——agent 按需加载的指令模块。与其把所有知识塞进系统提示，不如拆成聚焦模块：数据库迁移一个、API 端点创建一个、前端组件模式一个。agent 遇到匹配任务时自动加载对应 skill，其余留在上下文窗口之外。这就是 progressive disclosure（渐进式披露）——agent 从最小上下文起步，按需拉取更多。
MCP servers（模型上下文协议服务器）——扩展 agent 的能力边界，比如连接 Linear 做 issue 跟踪、Sentry 做错误监控、数据库做实时查询。但每多连一个 MCP 工具，就多占一份系统提示空间。HumanLayer 团队把这种现象叫 tool thrash（工具抖动）——agent 把时间浪费在选择用哪个工具上，而不是干活。建议从两三个开始，碰到真正的瓶颈再加。
Sub-agents（子代理）——不是”前端工程师 agent + 后端工程师 agent”式的分工，HumanLayer 试过，放弃了。Sub-agent 的真正用途是 context firewall（上下文防火墙）：主 agent 遇到会把上下文窗口塞满中间噪音的任务时，委托给 sub-agent 在隔离上下文中完成，只返回结果，中间步骤不污染主线程。Chroma 的研究表明 AI 模型在长上下文时性能显著下降，sub-agent 让你把大问题拆成多个短而聚焦的会话，模型保持在最佳区间。
Hooks（钩子）——在 agent 工作流的特定节点自动运行的脚本，给非确定性系统加上确定性控制。例如 pre-commit hook 在提交前跑 linter，pre-completion hook 强制 agent 在宣布完成前跑测试，loop-detection hook 捕捉 agent 反复做同一个编辑的死循环。LangChain 构建了一个 PreCompletionChecklistMiddleware，在 agent 完成任何任务前拦截并强制对照原始需求做验证——这个单一钩子是他们整个 harness 中收益最大的改进之一。
为什么 harness 比模型更重要
开发者花大量时间争论 Claude、GPT 还是 Gemini 更好，追逐每一次模型发布，相信下一个版本会修复一切。数据不支持这种信仰。
同一个模型从 42% 到 78% 的跳跃，接近翻倍的性能提升——历史上没有任何一次模型升级做到过这个幅度。但设计良好的 harness 能常规性地做到。
OpenAI Codex 团队的表述很直接：当 agent 遇到困难，他们把它当作信号，找出缺少什么——工具、护栏还是文档——然后反馈回仓库。不换模型，修 harness。
模型是引擎，harness 是方向盘、刹车和道路。再强的引擎，没有方向盘也会撞墙。
职业护城河
AI 模型正在商品化，每家公司都能用同样的前沿模型。模型不再是竞争优势。但一套经过精心工程化的 harness 是——它专属于你的代码库、你的团队模式、你的领域边界情况，不能通过下载模型来复制，只能通过持续把真实失败编码进系统来积累。
能设计这些 harness 的开发者是公司无法替代的人。不是因为他们写最好的代码，而是因为他们设计了让 AI 写出最好代码的系统。
Prompt engineering 是 2023 年的技能，context engineering 是 2025 年的技能，harness engineering 是 2026 年的技能。