SWE-Bench 的作者刚刚发布论文放出一组让人后背发凉的数据。

他们提出了 ProgramBench，要求 AI 从零开始完整重建真实的开源软件项目，不允许联网，不看代码相似度，只验证最终行为。

结果是：Claude Opus 4.7、GPT-5.4、Gemini 3.1 Pro，所有一线模型完成率全部 0%。

arXiv 论文原文：《ProgramBench: Can Language Models Rebuild Programs From Scratch?》

注意，这不是说 AI 写不出代码。它能写很多代码，能把函数写得很漂亮。

但让它从零搭一个能真正跑起来的真实项目，它就会把所有逻辑塞进一个单体文件，没有模块化、没有架构、没有长期规划，最终通不过行为验证。

[!info] 阅读导览
第 1 章 现在 LLM 到底差在哪 → 第 2 章 Harness Engineering 到底在干嘛 → 第 3 章 Harness 的 5 个核心维度 → 第 4 章 看顶级团队怎么搭 Harness → 第 5 章 三个反直觉的 Harness 原则 → 第 6 章 结语

1. 现在 LLM 到底差在哪

LangChain 做过一个实验。同一个 gpt-5.2-codex 模型，权重一字没动，只优化模型周围的工程结构。结果 coding agent 在 Terminal-Bench 2.0 上从 52.8 分涨到 66.5 分，排名从 Top 30 开外冲进 Top 5。

OpenAI 公开过一个更夸张的案例。三个人的小团队，五个月时间，驱动 Codex 写出大约 100 万行代码，合并了约 1500 个 PR。这是一款真正有内部日活用户、有外部 alpha 测试用户的软件产品。

OpenAI 团队自己说，他们的工作重心已经从写代码转到了四件事上：设计环境、明确意图、搭反馈回路、让 Agent 自己能看见、能验证、能修复。

把这两组数据放一起看，结论就很清楚了：

裸模型在严肃工程任务上完成率 0%。同一个模型加上一套合适的工程基础设施，能让三人小团队做出生产级软件。

中间那个差距，就是 Harness。

2. Harness Engineering 到底在干嘛

Harness 的直译是"马具"。

大模型（Opus 4.7 / GPT-5.5）就像一匹烈马，如果你无法通过缰绳控制住它，它跑得再快也没有任何意义。

Harness Engineering 就是如何打造马具，如何通过马具来控制住这匹烈马的技术。

Hooks、Skills、MCP、CLAUDE.md / AGENTS.md、sub-agents、plugins、tools，这些东西你大概都听过或者用过几个。Harness 也可以理解为把它们当成一个系统来设计的统称。

很多人用 AI 的方式是这样的：看到一个新 MCP 觉得好玩就装，看到一个 hook 例子就抄一个，CLAUDE.md 随便写两行就忘了，遇到 bug 也不知道该补哪一块，各种功能无法配合使用。过多的 harness 也会使你的马匹感到疲惫，效果有限。

Harness Engineering 这个词存在的意义就是逼你把这些零散动作当成一个系统来审视。

它给你一份检查清单：你的 AI 工作流在 5 个核心维度上是否完整？保证你的马匹永远处在最佳状态。

业界给出过一个公式：

Agent = Model + Harness

这就是为什么你会觉得有些工具就是更顺手，有些工具模型也很强但用起来像没长脑子。马具不一样而已。

放在 AI 工程的演进脉络里看：

flowchart TB
    A[最外层 Harness 工程<br>工具编排 / 状态持久化 / 验证循环 / 任务拆解 / 子 Agent / 权限沙箱 / 回滚] --> B[中间层 上下文工程<br>给 AI 什么信息、什么时候给]
    B --> C[最内层 提示词工程<br>怎么给 AI 下指令]

• 最内层：提示词工程（Prompt Engineering），关心怎么给 AI 下指令。
• 中间层：上下文工程（Context Engineering），关心给 AI 什么信息、什么时候给。
• 最外层：Harness 工程，把前两者都包在里面，再加上工具编排、状态持久化、验证循环、任务拆解、子 Agent、权限沙箱、回滚机制，构成一套完整的工程基础设施。

接下来我们用 Harness 的 5 个维度回头看你现在的 Claude Code / Codex / OpenClaw / Cursor 的配置。

3. Harness 的 5 个核心维度

把零散的 Harness 概念落到具体工程动作上，可以拆成 5 个维度：

上下文管理、执行能力、任务编排、反馈机制、架构护栏

3.1. 上下文管理：三层记忆架构

AI 在多轮对话里忘掉项目规则，根源在上下文窗口的工作方式。每一轮模型看到的内容是一个扁平的消息列表，你过去说过的每句话和当前问题混在一起，没有项目规范和普通聊天的层级区分。对话越长，前面定的约束被稀释得越厉害。

OpenAI 在 Codex 工程文章里有一句话点破了这层：从 Agent 的角度看，运行时拿不到的知识就等于不存在。 如果没有以文件形式存在于仓库里，AI 一概看不见。

Harness 在这一层的核心做法是把规则文件化、结构化。生产实践分三层：

1. 第一层（项目地图）：根目录的 AGENTS.md 或 CLAUDE.md。每次新对话都被加载到上下文头部。内容包括技术栈、目录结构、禁止事项、提交前必须跑的命令。
2. 第二层（主题详情）：docs 目录下按主题拆分的详细规则文件，如 frontend.md、security.md。AI 根据需要主动读取。
3. 第三层（轻量索引）：Claude Code 这类工具内置的记忆机制。每条约 150 字符的轻量级索引始终加载，详细内容按需拉取。

核心原则：分层持久化上下文，避免上下文空间占用过大影响模型注意力。

3.2. 执行能力：让模型拥有手脚

模型本身只能输出文本。它没法自己跑命令、没法看运行结果、没法根据报错调整下一步。这种纯输出能力让 AI 没办法闭环工作。

Harness 在这一层的工作是把模型接入真实操作环境：

• 基础层：终端 + 文件系统 + 浏览器。让 AI 跑命令、改文件、截图验证。
• 进阶层：MCP（Model Context Protocol）。接入数据库、搜索引擎、设计工具等外部能力的标准协议。
• 更高层：Skills。把多步骤工作流封装成可复用的能力包。

核心原则：合理选择你的每一个工具，多不如精。（Vercel 的经验：删掉 80% 的专用工具，只用 Unix 基础工具，成功率反而从 80% 涨到 100%）。

3.3. 任务编排：让 AI 能够执行长任务

AI 在长任务上典型的失败模式是想 one-shot 一个完整功能。这会导致模型上下文耗尽或逻辑混乱。

Harness 在这一层做的是把长任务结构化：

1. Plan Mode：AI 先输出任务方案，人工确认后再动手。这是"刹车"，在方案阶段消化成本。
2. 步进执行：每次只做一个子任务，做完一个验证一个。
3. 状态外置：沉淀 progress.md 或 plan.md。记录已完成功能、技术方案、架构决策、待做事项。它是跨对话窗口的"外置记忆"。
4. 并行协作：互不依赖的子任务用 sub-agents 同时跑。

Ralph Loop 方案：

• Initializer Agent：负责环境搭好、需求拆解、写初始 progress.md。
• Coding Agent：负责读进度、选任务、执行、提交并更新 progress.md。

核心原则：progress.md 和 git commit 是 AI 的存档点，存了档才能放心做长任务。

3.4. 反馈机制：AI 测试驱动开发

代码能不能跑，只有真跑一遍才能确认。AI 经常自信地说"已经修好了"，但实际上可能还有错。

Harness 在这一层的工作是把验证自动搬到闭环中：

• 规则反馈：提交前自动跑 linter、typecheck、单元测试。
• 视觉反馈：UI 任务使用 Playwright 等工具截图验证。
• LLM 评审反馈：让另一个独立的 AI（Evaluator）评审代码。

核心原则：AI 嘴上说修好没有用，跑通测试才算完成。

3.5. 架构护栏：在提交前拦住 AI 的烂代码

AI 会模仿仓库里已有的模式（包括烂代码）。

Harness 在这一层的工作是把架构规则变成可执行的代码：

• Pre-commit hooks：提交前拦截不合规的代码。
• 架构 Linter：检查模块依赖是否合规、文件是否过大。
• CI gate 兜底：确保主干分支永远满足架构约束。

核心原则：提前考虑到 AI 的局限，设置好护栏。

维度	核心做法	核心原则
上下文管理	三层记忆架构：AGENTS.md → docs 主题详情 → 轻量索引	分层持久化上下文，避免占用过大影响注意力
执行能力	终端 + 文件 + 浏览器 → MCP → Skills	合理选择工具，多不如精
任务编排	Plan Mode → 步进执行 → 状态外置 → 并行协作	progress.md 和 git commit 是存档点
反馈机制	规则反馈 → 视觉反馈 → LLM 评审	跑通测试才算完成
架构护栏	Pre-commit hooks → 架构 Linter → CI gate	提前设置好护栏

4. 看顶级团队怎么搭 Harness

4.1. Anthropic / Claude Code：教科书级的长任务工程

设计一：三层记忆架构

• 上层：轻量级索引（始终加载）。
• 中层：详细文档（按需拉取）。
• 底层：原始记录（通过搜索访问）。

设计二：Ralph Loop 跨上下文接力

4.2. OpenAI / Codex：面向 AI 重构开发环境

提出 Codex legibility（对 Codex 可读）理念：

1. 独立实例：每个 git worktree 自动启动独立应用实例。
2. CDP 接入：Chrome DevTools Protocol 接入 Agent runtime。
3. 监控暴露：日志、指标、trace 暴露给 AI 直接查询。
4. Custom linter：把架构约束写成可执行规则。
5. 垃圾回收：后台定期扫描代码库并自动修补技术债。

4.3. Superpowers（obra）：开源可复用的 Skills 框架

内置常用工作流：

• TDD workflow：先写测试再写实现。
• 两阶段 Code Review：Generator 与 Reviewer 角色分离。
• Self-Evolution：使用 DSPy 优化 Harness 本身。

5. 三个反直觉的 Harness 原则

1. 原则一：Harness 不是越多越好。工具越多，模型选错路径的概率越大。
2. 原则二：上下文怎么组织比多大重要得多。注意"Lost in the Middle"现象和缓存命中的经济性。
3. 原则三：Harness 应该随着模型的进化不断精简。旧的补丁可能会变成冗余开销。

6. 结语：Harness Engineering 成为核心能力

Harness Engineering 越来越重要。

AI 已经足够聪明，但它不会替你做需求分析、任务拆解、架构设计和验证标准建立。这些事情的总和就是 Harness Engineering。

• AGENTS.md → 需求/设计文档
• 任务编排 → 敏捷迭代
• 反馈机制 → 测试与 Code Review
• 架构护栏 → 代码规范

下次你的 Agent 又把事搞砸了，请检查你的"马具"是否牢固。

[!success] 核心要点

• 核心公式：Agent = Model + Harness——模型差距之外，工程基础设施决定成败
• 两组证据：ProgramBench 全模型 0% 完成率；LangChain 只调 Harness 让 gpt-5.2-codex 在 Terminal-Bench 2.0 从 52.8 → 66.5（Top 30 → Top 5）
• 5 个维度：上下文管理（三层记忆）/ 执行能力（MCP + Skills）/ 任务编排（progress.md 存档）/ 反馈机制（测试闭环）/ 架构护栏（Linter + CI）
• 顶级实践：Anthropic 三层记忆 + Ralph Loop；OpenAI Codex legibility（worktree/CDP/监控/linter/垃圾回收）；Superpowers（obra）开源 Skills 框架
• 三个反直觉原则：不是越多越好；组织方式比体量重要；随模型进化持续精简