大家好！我是瓜哥。前互联网技术副总裁，现在带队死磕 AI 编程。
月初刷到 Mitchell Hashimoto 的博客，我愣了几秒。
他说自己每天的工作是 "harness engineering"。这人是 Terraform 作者、HashiCorp 联合创始人，全球最顶尖的基础设施工程师之一。
他的原话是："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."
翻译成人话：每次发现AI犯错，别急着吼它。而是搭一套系统，让它以后再也犯不了这个错。
我靠，这不就是 ' 基建工程师 ' 吗？
一、什么是 Harness Engineering？
先说清三层关系。
① Prompt Engineering
就是写提示词。优化单次交互。Jeff Huber 说得直接："prompt engineering's like script kitty"——像玩脚本的。
② Context Engineering
是管理模型看到什么。Jeff Huber 说这是软件工程，不是玩票。
③ Harness Engineering
是整个系统设计。包括工具、约束、反馈机制。
三者不是并列，是包含：Prompt --> Context --> Harness。
Richard Hightower 给了个形象的比喻：Model is CPU, Harness is OS。光有芯片没用，得有主板、操作系统，电脑才能跑。
Martin Fowler 把 Harness 分成三根支柱：
| 支柱 | 定义 | 示例 |
|---|---|---|
| Context Engineering | 知识库 + 动态上下文 | AGENTS.md、文档系统、observability数据 |
| Architectural Constraints | Linter、结构测试、架构规则 | 自定义linter、依赖方向约束 |
| Entropy Management | 定期运行的"垃圾回收"agent | 每周巡检的清理agent |
二、基于这个新概念的实践
01 | 0行手写代码，100万行产出
2026年2月11日，OpenAI 发了一篇爆炸性博客。
他们用 Codex 写了5个月，产出100万行代码。关键点：0行是人写的。
怎么做到的？
- 知识库系统：不用巨型 AGENTS.md，而是"table of contents"。Codex 需要什么，自己去 docs/ 查。
- 架构约束：自定义 linter，代码只能按固定方向依赖。违反就报错，agent 自己改。
- 垃圾回收：每周五有个专门的 agent 跑一遍，专门修"AI slop"。
02 | 多 agent 三角结构
Anthropic 走了另一条路。
他们发现单个 agent 有两个致命问题：
- 试图一口气做完，直接 Context Anxiety
- 自我评估时疯狂给自己放水
解决方案是三角结构：
- Planner：把需求拆成具体任务
- Generator：一个任务一个任务完成
- Evaluator：独立评审，不客气那种
测了个 2D 游戏生成器，结果如下：
| 类型 | 时长 | 成本 | 结果 |
|---|---|---|---|
| Solo Agent | 20分钟 | $9 | 看起来完整，一打开就报错 |
| Full Harness | 6小时 | $200 | 真能玩，核心功能可用 |
03 | Martin Fowler 的洞察
Martin Fowler 看了，说了一句值得记下来：
"increasing trust and reliability required constraining the solution space."
说人话：想让AI靠谱，得先给它画地为牢。
他还提了个问题值得所有团队想：你的 harness 今天长什么样？
三、关于一些未来洞察
01 | 工程师角色转变
以后的工程师分两种：
- Harness Architect：设计约束系统、反馈循环
- Traditional Coder：可能变成极少数
Mitchell Hashimoto 已经在做第一种。他不再自己写业务代码，而是维护 AGENTS.md + 自动化工具链。
02 | 技术栈收敛
OpenAI 发现的规律："boring" tech 更 AI-friendly。因为可预测、结构清晰，模型能推理。
未来可能没有 ' 技术选型自由 '，只有 ' AI-friendly ' 和 '其他'。
03 | 一个未解问题
harness 本身要不要维护？
如果 harness 也会产生技术债务，那是不是得再套一层 harness？
无限套娃？
三、写在最后
写完这篇文章，我关掉文档，发了会儿呆。
2 年前，我们说 ' Prompt Engineering '，觉得会写提示词就能吃这碗饭。
1 年前， ' Context Engineering ' 出来，发现得管信息输入，得会/compact(压缩上下文)、/clear(清除对话)。
现在， ' Harness Engineering ' 直接到了系统层。
变化真的很快。
但核心其实没变：与其调教模型，不如优化环境。大量的 AI Builder 每天都在这么做，只是比较零散，还没有构建起一套完善的工程体系。
接下来，切换思维，从驯服 AI，到为 AI 铺路。
你是怎么做的？欢迎评论区分享你的经验~
提交反馈
图文Harness Engineering：一个硅谷工程师都在说的新概念！
评论区
暂无公开评论还没有公开评论。