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 自己发现问题

我发现，

我总结出了几条核心原则：

1. 任务拆解： 别指望一步到位，要把任务拆成清晰、可执行的小块。
2. 规划与执行分离： 模糊的需求要先让 AI 出方案，再执行。
3. 闭环验证： 给 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 在一个可控、可验证、可积累的工程环境里工作。