Harness Engineering 最近特别火，一起来读读这个术语的源头文章，Mitchell Hashimoto 在 2026-02-05 发的： My AI Adoption Journey
以下是经过整理后的中文版，感兴趣的朋友可以移步英文原版：My AI Adoption Journey
真正有价值的 AI 开发，不是让 AI 一次性写出完美代码，而是给 Agent 一个能行动、验证、纠错、积累经验的环境。
目录
- 第 1 步：告别聊天机器人
- 第 2 步：复现你自己的工作
- 第 3 步：部署“下班后”智能体
- 第 4 步：外包那些“稳赢”的任务
- 第 5 步：构建“工程化约束” (Harness Engineering)
- 第 6 步：让智能体永不掉线
- 现状与思考
我在上手任何有意义的工具时，必然会经历三个阶段：
(1) 效率阵痛期
(2) 勉强够用期
(3) 工作流重塑与突破期
大多数情况下，我得强迫自己熬过前两个阶段。毕竟我早已习惯了现有的工作流，用起来既顺手又舒服。
拥抱新工具就像是在“加班”，我本心并不想折腾，但为了保持专业素养，成为一个更纯粹的“手艺人”，我通常会选择坚持。
这是我如何发掘 AI 工具价值的心路历程。
在当下充斥着浮夸、炒作的舆论大海中，我希望分享一种更细腻、更克制的视角，记录我的观念是如何随时间演变的。
第 1 步：告别聊天机器人
立即停止尝试通过聊天界面（如网页版 ChatGPT、Gemini 等）来处理正式工作。
聊天机器人当然有价值，也是我日常流的一部分，但它们在编程中的作用非常有限。因为你本质上是在赌它能靠以前的训练“蒙”对结果；一旦它错了，你还得像教小孩一样反复告诉它哪儿错了。这种“你一言我一语”的纠错极其低效。
我第一个“真香”时刻，是将 Zed 编辑器的命令面板截图发给 Gemini，让它用 SwiftUI 复现。结果令我震惊——它做得非常棒。现在 Ghostty macOS 版中的命令面板，基本就是 Gemini 几秒钟内生成的初版。
但当我试图在更复杂的“棕地项目”（Brownfield projects，指在现有代码库上开发）中复现这种成功时，我失望了。在复杂的上下文里，聊天机器人经常翻车，我得不停地在编辑器和网页间反复粘贴代码和错误日志。这显然比我自己写要慢得多。
结论：要产生真正的生产力，你必须使用 Agent（智能体）。
Agent 是指能够在一个循环中运行、并能调用外部工具的 LLM。
它至少得具备：：
- 读项目文件
- 执行命令
- 调用工具
- 根据结果继续修正
- 在真实仓库里工作
换句话说，Agent 让 AI 从“回答问题的人”变成了“能操作项目的协作者”。
第 2 步：让 Agent 复刻自己的工作
我尝试了 Claude Code。起初印象平平：结果不理想，我还得给它“擦屁股”，花的时间比自己写还长。
但我没有放弃，而是强迫让 Agent 把我刚写完的代码重写一遍。
我相当于把活儿干了两遍：先手写，然后让 Agent 在看不到我答案的情况下，挑战达到同样的质量和功能。
过程很痛苦，因为它阻碍了我的进度。但作为一个老兵，我知道这种摩擦是必然的。
这样做是为了校准：
- Agent 哪些任务能做
- 哪些任务容易失败
- 任务应该怎么拆
- 什么验证方式能帮 Agent 自己发现问题
我发现，
我总结出了几条核心原则：
- 任务拆解： 别指望一步到位，要把任务拆成清晰、可执行的小块。
- 规划与执行分离： 模糊的需求要先让 AI 出方案，再执行。
- 闭环验证： 给 Agent 明确的验证路径，比如测试脚本、截图、lint，它通常能自己修好 Bug。
在这个阶段，我摸清了 Agent 的边界，不再盲目使用，达到了“不比手写慢”的平衡点。
第 3 步：部署“下班后”智能体
为了榨取效率，我开启了一个新模式：每天下班前最后 30 分钟，启动一个或多个 Agent。
既然我没法 24 小时工作，那就让 Agent 在我休息时帮我推点进度。
我发现这几类工作特别适合“离线运行”：
- 深度调研： 比如“调研某语言下所有符合某种授权协议的库，整理优缺点、活跃度和社区口碑”。
- 方案探索： 尝试我脑子里一些不成熟的点子，第二天看 Agent 的尝试是否帮我排雷。
- Issue 过滤： 让 Agent 用 GitHub CLI 把积压的 Issue 过一遍，打好标签，我第二天就能直接处理高价值任务。
重点不是 Agent 一定要直接产出可合并代码，而是让第二天的工作有一个“热启动”。
第 4 步：把高确定性任务交给 Agent
当我足够了解 Agent 的能力边界后，我开始把那些它肯定能搞定的任务彻底外包出去，而我同时去干别的事。
适合 Agent 的任务通常是：
- 范围清晰
- 验证明确
- 有现成模式可参考
- 改动风险可控
不适合 Agent 的任务通常是：
- 需求模糊
- 架构判断重
- 缺少测试
- 失败代价高
关键点：关掉 Agent 的桌面通知。 频繁的上下文切换是效率杀手。
作为人类，我要掌控干扰的时机。
在我工作的自然间隙，切过去扫一眼 Agent 的进度即可。
这种方式让我能专注于那些我真正热爱、需要深度思考的代码，而把琐碎但必须做的杂事交给这位“略显笨拙但任劳任怨”的机器人助手。
第 5 步：构建“工程化约束” (Harness Engineering)
Agent 的效率取决于它能不能“一次跑对”。实现这一点最可靠的方法不是写更长提示词，而是给它一套快速、高质量的工具，让它在犯错时能立刻察觉。
我称之为 “Harness Engineering”（线束/约束工程） 。
只要 Agent 犯了一次错，我就去写个脚本或更新配置，确保它以后再也不会犯同样的错：
第一种是更新规则文件，比如 AGENTS.md。
如果 Agent 总是：
- 跑错命令
- 用错 API
- 忽略项目规范
- 改错文件
- 重复犯同类错误
那就记录各种避坑指南和规范，把规则写进项目说明里，让后续 Agent 能继承这次经验，运行时隐式加载。
第二种是写真正的工程工具。
比如：
- 自动测试脚本
- 截图验证工具
- lint 规则
- 类型检查
- 架构约束
- 本地检查命令
规则文件是“告诉 Agent 不要犯错”，工具和检查是“让 Agent 更容易发现自己错了”。
这就是 Harness Engineering 的核心：把每次错误沉淀成可复用的约束、工具和反馈回路。
第 6 步：让 Agent 永不掉线
现在，我的目标是只要我在电脑前，背景里就一定有一个 Agent 在跑。
如果它没在跑，我会问自己：“现在有什么事是可以分给它做的吗？”
我尤其喜欢用一些“慢而深”的模型（如 Amp 的 Deep Mode），它们可能要跑 30 分钟才能完成一点小改动，但质量极高。
重点是找到那些 Agent 真能推进的任务，让它成为异步生产力。
人类做判断、拆任务、评审和设计环境；Agent 做执行、尝试和重复劳动。
我目前还没打算同时跑多个 Agent。一个背景 Agent 能让我保持专注，同时又像有一个“有点呆但出活”的机器人在旁边搭把手，这种平衡感刚好。
现状与思考
这就是我目前的进度。
我成了一名依然热爱手艺、但学会了使用现代重型武器的软件工匠。
我并不太在意 AI 是否会取代人类，我只想纯粹地因为热爱而创造。
这个领域变化太快，也许几个月后回看此文我会觉得自己很幼稚。
但正如那句话所说：如果你不为过去的自己感到羞愧，说明你没有进步。
总结
这篇文章的价值不在于“AI 很强”，而在于它提出了一种工程师的新职责：
- 不只是写代码，而是设计 Agent 能稳定工作的环境
- 不只是修 bug，而是让同类 bug 不再发生
- 不只是 prompt，而是规则、工具、测试、反馈、约束一起构成系统
真正成熟的 AI coding 工作流，不是靠神奇提示词，而是靠持续建设 harness，让 Agent 在一个可控、可验证、可积累的工程环境里工作。
