给 AI 套上缰绳:一篇文章讲透 Harness Engineering

一、先从一个朴素的问题说起

过去一年，你大概率见过类似的场景：

• Demo 阶段惊艳，上线就崩
  。一个 Agent 五分钟搞定小工具演示，放到真实业务里跑两天就原地打转。
• 长任务跨不过夜
  。一个需求拆成三十步，跑到第十五步就"失忆"了，忘记自己在干什么。
• 写到一半，拍着胸脯说"搞定了"
  。打开产物一看，一堆没跑通的函数、几个永远红着的测试。
• 想回滚找不到现场
  。它在你的代码库里大笔一挥，但没人说得清它到底改了什么、为什么这么改。

换个模型能解决吗？试过。GPT-5 换 Claude 4.6 换 Gemini 3，问题依旧。LangChain 做过一个有意思的实验：模型不动，只优化外层工程，编程基准通过率从 42% 直接拉到 78%。同一个模型，前后差了 36 个百分点。

结论很硬核：瓶颈不在模型，在模型外面那一圈。

这一圈，就是 Harness。

二、Harness 是什么？为什么叫这个名字

Harness 原本是英文里"马具"的意思——马鞍、缰绳、马镫、辔头，一整套装备。

为什么偏偏挑了这个词？因为它精准抓住了三个要点：

1. 马是强壮的、有灵性的，但方向不定
   。对应大模型——能力惊人，但随机性也惊人。
2. 马具本身不增加马的力量
   ，只是把它的力量约束在正确的方向上。对应 Harness——不提升模型能力，只让能力被可靠地利用。
3. 骑手不直接去"驱动每一块肌肉"
   ，而是通过缰绳、马刺、膝盖给信号。对应工程师——不再手把手指挥 Agent 每一步，而是设计约束让它自己跑对。

2026 年 3 月之后，这个词突然在全球技术圈密集出现。Anthropic 的工程博客直接用 "Effective harnesses for long-running agents" 当标题；OpenAI、LangChain、Cursor 不约而同把它写进技术栈的正式命名。

Harness 不是某家公司的术语。它是整个行业在同一个问题上撞到同一堵墙之后，自发长出来的答案。

三、一句话定义 Harness

Harness 是包裹在大模型外部的"确定性外壳"，让非确定性的 Agent 能在真实环境中长期、安全、可控地执行任务。

拆开看三个词：

• 外部
  ：它不在模型里，也不是一条 Prompt，而是真实的工程代码、真实的文件系统、真实的状态机。
• 确定性
  ：模型本身是概率性的（同样的 Prompt 两次回答能不一样），Harness 要用确定性的机制把它包起来。
• 长期运行
  ：几秒钟搞定的一次性问答不需要 Harness，需要跑几小时、几天、几百步的任务才需要。

一句更直白的类比：如果大模型是 CPU，Harness 就是操作系统。没有操作系统，再好的 CPU 也只能跑单片机程序。

四、Harness 的五大子系统（核心架构）

这是一张整体图，先看一眼再讲：

1. Environment 环境层：给 Agent 一个工作的世界

这是 Agent 的"工位"：文件系统、沙箱终端、浏览器、数据库。它必须满足两个条件——

• 受控
  ：出错了能还原，不会把你的生产库洗掉；
• 真实
  ：不是模拟的 mock，而是真实的 IDE、真实的 shell，让 Agent 的每个操作都有真正的后果。

2. Tools 工具层：把世界抽象成一个个 Action

环境是原始的、复杂的。工具层的工作，是把环境能力包成 Agent 能安全调用的原语。

反面教材：给 Agent 一个"执行任意 shell 命令"的工具。正面做法：read_file(path)、write_file(path, content)、run_test(suite)、commit(message)——粒度越小、副作用越明确，Agent 越不容易跑飞。

Vercel 内部有个案例，重构后砍掉了 80% 的冗余工具，模型表现反而更好了。因为工具越杂，Agent 的"选择焦虑"越严重。

3. Control 控制层：管住执行边界

这是 Harness 里最容易被低估、但最关键的一层。它负责：

• 步数/时长限制
  ：一个任务最多跑 50 步、最多跑 2 小时。
• 状态机
  ：任务必须从 PLANNING → CODING → TESTING → REVIEW 走，不能乱跳。
• 权限控制
  ：可以读日志，不能删库；可以提 PR，不能直接 merge 到 main。
• 错误分类
  ：把错误拆成"临时/可重试/需回滚/需人工"四类，每类走不同的恢复路径。

一句话：把规则写进系统，别写在 Prompt 里。写进 Prompt 的规则，模型心情不好就忘了；写进系统的规则，模型没有选择。

4. Memory 记忆层：把状态从模型里搬出来

模型上下文窗口就是它的短期记忆，满了就溢出。所以长任务的关键是：任何重要信息都不能只活在上下文里，必须外置到文件/数据库/Git。

Anthropic 在一个克隆 claude.ai 的实验里用了这套做法：

• 一开始建一个 claude-progress.txt 记录进度；
• 一个 JSON 文件列出 200 多个功能点，每个状态是 pass/fail；
• 每完成一步就 git commit，下一步开工前先 git log 读历史；
• Agent 的"记忆"其实是文件系统，不是上下文
  。

这个设计非常反直觉但非常有效——它让 Agent 像一个交接班的工程师：走进办公室先看看进度表、看看 commit 日志，再决定今天干什么。

5. Evaluation 验证层：让系统自己判断"做对了没有"

模型最大的毛病之一是"盲目自信"——明明代码跑不通，它也敢说"已完成"。解决办法是把生成和评估拆成两个角色：

• Generator
   写代码；
• Evaluator
   打开浏览器真点一遍、真跑一遍测试、真看一眼截图。
• 评估器被显式校准为"怀疑论者"，任务开工前就约定好"验收合同"（Sprint Contract），不满足就打回去。

Cursor 甚至用 8 通道并行盲审 + 多数投票：八个独立 Agent 同时评估，多数说通过才算通过。工业级可靠性，是这么堆出来的。

五、Harness 和 Prompt、Context 到底什么关系？

很多人一上来就问："Harness 是不是要替代 Prompt Engineering？"

不是替代，是分层。

再打个更接地气的比方——

招一个水平极高但刚入职的实习生：

• Prompt
   = 你布置任务时的那段话；
• Context
   = 你塞给他的那堆文档和示例；
• Harness
   = 你给他配的开发环境、测试流程、Code Review 规范、回滚机制、代码仓库。

前两个能决定他"今天这件事做得好不好"，只有第三个能决定他"能不能独立交付三个月的项目"。

六、Harness 能解决什么问题？三个真实案例

案例一：42% → 78%，同一个模型的能力被"解锁"了

LangChain 的实验：同样的模型、同样的任务集，只改进 Harness（加自验证循环、加目录映射、优化工具接口），SWE-Bench 通过率从 42% 提到 78%。

启示：很多时候你以为模型不行，其实是外壳不行。

案例二：Stripe 一周合并 1300 个 Agent PR

这不是 demo，是生产。关键是三件事：

• 工具层：所有工具都带"副作用白名单"，碰不到敏感资源；
• 控制层：每个 Agent 只能操作自己的分支，冲突全靠门控；
• 验证层：CI 全绿才允许人工 review，人不是审代码，是审"这改动值不值得"。

人从"每行代码审阅者"变成了"门槛把关者"。

案例三：OpenAI Codex 项目，5 个月 100 万行代码 0 人工编写

具体做法在业界有共识——

• 仓库即现实：架构规则、风格偏好、依赖约束全部写进代码仓，不写在 Prompt 里；
• Doc-gardening Agent 定期巡检文档与代码的一致性；
• Linter 是硬门禁，过不了就自动打回重做。

不是给 Agent 一个更聪明的大脑，而是给它一个更严谨的环境。

七、通俗易懂的场景理解

三个真实生活里都能对得上的类比：

🚗 驾校学车 vs Harness

• 教练不控制你的手脚（他控制不了，也不该控制）；
• 教练控制的是"离合到半联动再走"这个流程、"今天只练直角转弯"这个边界、"后视镜不看就踩刹车"这个反馈。
• 这就是 Harness：不控制动作，控制约束和反馈。

🏭 工厂流水线 vs Harness

• 每个工位的工人不用知道"一辆车怎么造"，只需要拧自己那颗螺丝；
• 流水线本身规定了顺序、节奏、质检关卡；
• 工人可以被替换、被升级，但流水线保持稳定。
• 这就是 Harness：把复杂的全局问题拆成简单的局部问题。

🍳 米其林餐厅厨房 vs Harness

• 大厨的随机创造力很珍贵，但菜不能每次都不一样；
• 标准化的 mise en place（食材备料）、标准化的酱汁配方、标准化的摆盘 checklist——这些保证了每次上菜质量一致；
• 大厨还是大厨，但餐厅变成了"可规模化复制"的餐厅。
• 这就是 Harness：用标准化框架包裹创造力，让天才变成可重复的输出。

八、2026 年的范式跃迁

这两年 AI 编程经历了三次范式转变：

第一代 · Vibe Coding

自然语言写代码｜"哎，你帮我写个登录页"｜适合 1000 行以内的快速原型

第二代 · Spec Coding

结构化规格驱动｜把需求写成 OpenAPI / ADR / 行为清单｜适合团队协作项目

第三代 · Harness Engineering

工程化驾驭 AI｜用外壳驯服随机性，让 Agent 可以跑长周期任务｜适合生产级部署

三代不是替代关系，是升级关系：

• 写脚本工具
  ？Vibe Coding 就够了。
• 做一个后端服务
  ？上 Spec Coding。
• 要让 Agent 每周自主交付 1300 个 PR
  ？必须 Harness。

工程师的角色也在同步跃迁：从"骑手"（写代码的人）→ "驯马师"（设计让马跑对的系统的人）。

九、一个"最小可用 Harness"怎么搭？

如果你今天就想试一试，路径非常清晰：

Step 1 · 搭环境 + 写最薄的工具层（半天）

• 一个干净的沙箱（Docker 或 git worktree）
• 5 个以内的核心工具：read_file、write_file、run_shell、run_test、commit

Step 2 · 加 Task Loop（一天）

• 明确 PLANNING → EXECUTING → EVALUATING → DONE 状态机
• 每步之间做 checkpoint，状态写到文件里

Step 3 · 上记忆层（一天）

• 建一个 progress.md 和 AGENTS.md
• Agent 开工前第一件事：读 progress、读 git log、读 AGENTS

Step 4 · 上验证层（一到两天）

• 一个独立的 Evaluator Agent（或者干脆就是一组硬测试）
• 说"完成"之前必须过 Evaluator，过不了打回来

Step 5 · 引入 Human-on-the-loop

• 不是 Human-in-the-loop（人还在链路上等）
• 是 Human-on-the-loop（人在旁边看，只在关键节点或异常时介入）

做完这五步，你会有一个粗糙但完整的 Harness。比你现在反复调 Prompt 有效得多。

十、写给普通人：把 Harness 思想用到生活和工作里

Harness 看起来是给工程师的，其实它的思想对任何需要"驾驭不确定性"的场景都成立。这是我最近感触最深的地方，分享四条可落地的心得：

💡 心得一：别只靠"自律"，搭"环境"

Harness 最核心的一条哲学是：能用环境约束解决的问题，不要指望意志力。

• 想少刷手机？把手机放客厅、在卧室只放书 >>> 告诉自己"今晚不刷"。
• 想早睡？房间温度调到 19 度 + 遮光窗帘 + 23 点断 Wi-Fi >>> 每天立 Flag。
• 想写作？打开固定文档 + 关掉所有通知 + 开 25 分钟计时器 >>> 坐下来想"今天写啥"。

把规则写进环境，不是写在自己的脑子里。这就是个人版 Harness。

💡 心得二：把"状态外置"到文件

工程师的 progress.md，换成普通人的语言就是——

• Today 文件
  ：每天早上第一件事，打开昨天的 today.md，决定今天 3 件最重要的事。
• Issue 文件
  ：遇到任何 blocker 立刻写进 issues.md，不想当场解决就扔那儿等合适时机。
• Decision 文件
  ：重要决定都写"为什么这么定"+"备选方案"，3 个月后复盘时就不会忘了上下文。

本质就是：不相信自己的脑子，相信写下来的东西。

💡 心得三：把"自验证"塞进流程里

Harness 里最反直觉的一点：Generator 和 Evaluator 必须分开。同一个脑子写的东西，同一个脑子审不出问题。

翻译成生活语言：

• 写完一封重要邮件，放半小时再回来读一遍（把自己变成 Evaluator）。
• 做完一个决定，写下"如果三个月后发现这个决定错了，可能是哪里错？"（预演反面）。
• 重要的事情约一个朋友，让他扮演怀疑论者，专门挑毛病。

每一次"间隔 + 换角色"，都是在给自己套一层 Harness。

💡 心得四：追求"可重复"而不是"一次牛逼"

Vibe Coding 能写出惊艳的 demo，但惊艳一次没用，Harness 追求的是每次都稳。

• 健身：不是某一天练到力竭，是每周三次稳定出现。
• 读书：不是某个周末读完一本，是每天通勤 30 分钟稳定推进。
• 副业：不是某个夜晚灵感爆发，是每周固定四小时的固定时段。

把你想要的结果拆成最小的可重复单元，然后给它搭一个不需要意志力的环境——这就是 Harness 送给普通人最值钱的一课。

十一、结尾

模型会越来越强，但"如何可靠地利用模型"这个问题永远存在。就像 CPU 越来越快，但操作系统的价值从未消失。

2026 年是 Harness Engineering 的元年。工程师们在用马具驯服 AI，普通人也可以用同样的思想驯服自己的工作和生活。

核心就一句话——

不要告诉 AI 怎么做，为 AI 搭一条跑道；不要告诉自己要做到，为自己搭一个不得不做的环境。

马年用马具，正是时候。