Harness Engineering：从写代码到设计赛道

OpenAI 刚公布了一个内部实验：3 个工程师，5 个月，100 万行代码，零行手写。

不是 Demo，不是概念验证。是一个有真实用户、能部署上线、会出 Bug 也能修复的生产级产品。

但让我反复回去看了三遍的，不是这个数字。而是报告里一句不起眼的话：

“我们目前最困难的挑战，集中在设计环境、反馈回路和控制系统上。”

不是模型不够强，不是提示词不够精巧。是环境没准备好。

因为我一直是 Java 后端，一看就觉得眼熟。微服务治理不就是这回事吗？单个服务写得再好，注册中心、熔断器、链路追踪这些”环境”没搭好，整个系统照样崩。

AI Agent 的世界里，正在发生一模一样的事。

这就是 2026 年最重要的工程范式转移：Harness Engineering（线束工程）。

提示词过时了，上下文也不够用了

过去三年，行业对”怎么让 AI 干好活”的理解，换了三次底层逻辑。

2023 年，所有人都在卷提示词。 Few-shot、Chain-of-Thought、角色扮演，教程满天飞。信念很朴素：问对问题，就能拿到好答案。

在聊天场景确实成立。但 AI 一旦从”回答问题”进化到”独立干活”，光靠一条指令就不够了。Simon Willison 说得很到位：“大多数人听到 prompt engineering，想到的就是对着 ChatGPT 打字。”

2025 年中，焦点转向上下文。 Karpathy 提了 Context Engineering，Shopify CEO 迅速认同。大家开始琢磨怎么动态组装 RAG、对话历史、工具输出。

但下半年的实践暴露了一个要命的悖论：即便模型支持 100 万 Token，性能衰减在 25.6 万左右就出现了。更吓人的是，有人的 Agent 陷入无限循环，一次事故烧了 5 万美元。

上下文可以告诉 Agent”知道什么”，但拦不住 Agent”做不该做的事”。

2026 年 2 月，Mitchell Hashimoto 给缺失的那块拼图命了名。

HashiCorp 联合创始人，在博客里写了一句话，我觉得简洁到可以刻在墙上：

每当你发现 Agent 犯了一个错误，你就花时间设计一个解决方案，使 Agent 永远不再犯同样的错误。

Prompt Engineering 管的是”说什么”，Context Engineering 管的是”知道什么”，Harness Engineering 管的是”在什么环境里做事”。

说白了，人类的角色从”直接干活的”变成了”设计赛道的”。你不再亲手跑每一步，而是把围栏、弯道、刹车全部提前造好，然后让 Agent 自己跑。

OpenAI 那个实验，到底发现了什么？

回到开头那个实验。

OpenAI 自己说得很明白：设定”零手写代码”不是为了炫技。这个约束本身就是目的。 是为了倒逼团队去搞清楚一件事：Agent 要在什么样的环境里，才能大规模可靠地工作？

瓶颈不在模型，在环境

初始团队 3 人，最终 7 人。五个月交付百万行生产级代码，平均每人每天合并 3.5 个 PR。

但早期进展比预期慢。不是 Codex 能力不够。是环境规范不够。Agent 缺少工具、缺少抽象、缺少结构。

大多数人第一反应是”模型还不够强”。但真相恰好反过来：模型够强了，环境没跟上。

这一点做后端的人应该秒懂。你给一个再强的开发者，项目没有 CI/CD，没有代码规范，没有接口文档，他一样写出一堆烂代码。Agent 更甚，因为它连”凭经验猜”的能力都没有。

从此工程师的工作逻辑变了。遇到 Bug 不是”换个提示词再试一次”，而是问自己：缺少什么能力？怎么把这个能力做成 Agent 能理解、能执行的东西？

不加人，加”眼睛”

代码产出量上去后，人类 QA 跟不上了。

团队的做法让我印象很深：没有招更多测试，而是让 Agent 自己”看见”运行时。

他们给 Codex 接上了 Chrome DevTools Protocol，Agent 可以直接启动应用、截屏、操作 DOM、重现 Bug。再把日志、指标、链路追踪全部暴露给 Agent，它可以直接用 LogQL 和 PromQL 查询。

于是”确保服务启动在 800ms 内”这种以前只有人才能判断的事，Agent 也能执行了。

团队经常看到 Codex 跑一个任务跑六个小时。通常是在人类睡觉的时候。

给地图，别给百科全书

OpenAI 学到的第一课：指令文件太长，Agent 反而表现更差。 一个巨大的说明文件会挤占真正重要的信息空间。当所有内容都”重要”时，什么都不重要了。

所以他们把 AGENTS.md 从百科全书变成了目录。大约 100 行，只告诉 Agent”接下来去哪里找信息”，具体内容全在 docs/ 目录下。

这叫渐进式披露。先给入口，再按需深入。

更牛的是，他们连文档维护都交给了 Agent。一个”文档园丁”Agent 定期扫描过时内容，自动提 PR 修复。

架构围栏：规矩越严，Agent 跑得越快

团队给应用搭了非常严格的架构：每个业务领域固定分层，依赖方向严格校验，跨领域只能通过统一接口进入。全部通过自定义 Linter 强制执行，违反了就报错，报错信息里直接写修复建议。

这种架构约束，一般大公司到几百人的时候才会搞。但他们在三个人的时候就上了。因为 Agent 在有明确规则的环境里，跑得比”自由发挥”快得多。规则对 Agent 来说就是导航，不是枷锁。

还有一个细节：团队要求 Codex 在模块边界处做数据校验，但不规定用什么库。结果 Agent 自己选了 Zod。没人指定过，但它自己选了一个合理的方案。

集中控制边界，局部允许自治。 这就像管理一个工程团队：你管架构规范，不管他用 for 循环还是 stream。只不过这次你管的”团队成员”是 Agent。

Hashimoto 的六步路径：从怀疑到”始终在线”

OpenAI 的实验是组织视角。Mitchell Hashimoto 的个人经历则更接地气。

他把自己的 AI 采用之路拆成了六步，前三步最有借鉴意义。

第一步：扔掉聊天机器人。

他试过把 Zed 命令面板截图丢给 Gemini 重现 SwiftUI 界面，效果惊艳。但复制到其他任务就不行了，尤其是旧项目，聊天界面产出的东西改起来比自己写还慢。

关键转折：必须用 Agent，不是 Chatbot。 Agent 至少能读文件、跑命令、发请求。

第二步：同一件事做两遍。

这步最狠。他强迫自己先手动完成任务，再让 Agent 独立做一遍。“极其痛苦”，他自己说的。但逼出了三个关键发现：拆任务要拆细；模糊需求先规划再执行；给 Agent 自我验证的手段，它会自己修 Bug。

还有一个很多人忽略的效率来源：搞清楚什么时候不该用 Agent。

第三步：每天下班前 30 分钟，启动 Agent。

三类任务特别适合这个时段：

让 Agent 做深度调研，比如扫描某个领域所有库的优缺点。启动多个 Agent 并行探索模糊想法，不求成品，只求揭示”未知中的未知”。还有 Issue 分诊，用 GitHub CLI 批量处理，第二天早上直接看报告。

Hashimoto 说这给了他”第二天的热启动”。他还分享了一条心态建议：“关掉 Agent 的桌面通知。我的职责是控制何时中断 Agent，而非被它中断。”

后面几步就是自然的递进：外包有把握的任务、围绕 Agent 建工具和环境、始终保持一个 Agent 在后台运行。

从怀疑，到共处，到离不开。 采用任何有意义的工具都是这个曲线。

LangChain 的实验：不换模型，排名从第 30 涨到第 5

如果上面的案例你觉得是大厂才能玩的，LangChain 的故事可能更有说服力。

他们的编码 Agent 参加 Terminal Bench 2.0 基准测试，只改了 Harness，没碰底层模型，排名从全球第 30 跳到第 5，得分从 52.8% 涨到 66.5%。

改了什么？四件事：

强制闭环：Agent 说”做完了”不算数，必须跑验证才算
环境注入：启动时告诉 Agent 目录结构、工具路径、评测标准
死循环检测：追踪文件编辑次数，Agent 空转就强制停
推理三明治：规划和验证用强模型，执行用便宜的

没换引擎，只改了赛道。成绩就上去了。

“环境比模型重要”这句话，看完这个案例就不用再争了。

三件值得认真想的事

第一，核心竞争力在转移。

从”写代码的速度”到”理解系统的深度”。有人描述顶级工程师用 Agent 的方式：只聊架构和重大决策，完全不碰具体实现。他脑子里装着项目全貌，Agent 负责把想法变成代码。

我作为后端程序员听到这个很有感触。这些年积累的架构经验、对系统瓶颈的直觉、踩过的坑，这些东西以前觉得”不如会写代码值钱”，现在反过来了。你理解得越深，Harness 就建得越好，Agent 的产出质量就越高。

第二，今天就可以开始建自己的 Harness。

不用等什么最佳实践。在你的项目里建一份 AGENTS.md，从最基本的内容写起：核心架构说明、常见 Agent 错误、测试命令、Agent 不能碰的东西。

每次 Agent 犯错，回来补一条规则。日积月累，这份文件就是你的 Harness。Hashimoto 就是这么干的，OpenAI 也是。

第三，别让初级开发者跳过”手写代码”这一关。

Thoughtworks 的 Böckeler 提了一个尖锐的问题：如果新人一上来就用 Agent 写所有代码，从来没经历过手动开发的磨练，将来谁来建 Harness？

你得先知道代码怎么写、系统怎么崩、Bug 怎么藏，才知道赛道的护栏应该装在哪。

2026 年最值得关注的技术辩论之一：Big Model vs Big Harness。

短期简单任务，模型够强就行。但长期复杂项目，没有 Harness，再强的模型也会漂移、失控、腐化。

Hashimoto 那句话我越想越觉得精准：每当 Agent 犯错，就设计一个方案让它永远不再犯。

这不就是工程的本质吗？把经验编码成系统，让错误只发生一次。

只不过这一次，你编码的对象不是业务逻辑，而是 Agent 运行的整个世界。

参考资料

OpenAI：Harness engineering: leveraging Codex in an agent-first world
Mitchell Hashimoto：My AI Adoption Journey
Martin Fowler：Harness Engineering