从提示词工程到上下文工程，再到如今的Harness Engineering，AI工程领域正在经历一场深刻的范式转移。本文揭示了AI应用的核心痛点——不是模型不够强大，而是缺乏让Agent稳定运行的环境设计。通过拆解OpenAI等团队的实战案例，我们将看到如何通过上下文工程、架构约束和熵管理三大维度，构建真正可靠的AI协作系统，以及工程师角色从代码编写者向系统设计者的本质转变。

说实话，我最近有点被这个词刷屏了。

Harness Engineering，这个两个月前还没几个人提的概念，现在已经成了 AI 工程圈里最热的关键词。我自己也花了挺长时间才想清楚它到底在说什么——不是因为概念难，而是因为它触碰到了一个我一直隐约感觉到、但没有明确说出来的问题：

我们到底在哪个环节搞错了方向？

我们曾经以为，写好提示词就够了

时间拨回 2023 年，那会儿整个 AI 圈都在研究一件事：怎么把提示词写好。

各种技巧满天飞，few-shot、思维链、角色扮演……我自己也没少折腾，专门建了一个文档收集各种”神级 prompt”，觉得找到了某种秘诀。那时候的感觉就像是，只要咒语念对了，AI 就会乖乖交付你想要的东西。

但慢慢地，问题开始出现。

同样一条提示词，昨天用没问题，今天换个任务就崩了。同样的指令，给不同的 Agent 用，结果差异大得离谱。更要命的是，当任务变得复杂，需要 Agent 连续做十几个步骤的时候，提示词写得再精妙也救不了它在中途跑偏。

Simon Willison 说过一句很扎心的话，大意是：大多数人听到”提示词工程”，脑子里浮现的就是对着聊天框打字。这个词的含义已经被稀释成那样了。

我当时看到这句话，有点沉默。因为我自己就是那个”对着聊天框打字”的人。

然后大家开始关注”上下文”

2025 年前后，风向变了，开始流行一个新词：Context Engineering。

核心逻辑是，光写好指令不够，你还得让模型”知道它需要知道的东西”。于是工程师们开始搞向量数据库、RAG 检索、上下文窗口管理，把各种信息塞进去，期待模型能做出更好的判断。

这个方向确实有用，我自己用过之后效果提升很明显。但问题也很快暴露出来——

有人记录过一个真实事故：一个没人盯着的 Agent 陷入了无限循环，等到有人发现的时候，API 账单已经跑了五万美元。

上下文再好，也管不住一个失控的 Agent。

你可以告诉它”知道什么”，但你没办法阻止它”做不该做的事”。

真正的问题，其实是”环境”

2026 年 2 月，一份来自 OpenAI 内部的技术报告让很多人开始重新思考这件事。

报告描述了一个挺极端的实验：一个最多七人的小团队，五个月时间，零行手写代码，通过 Agent 协作交付了超过一百万行代码的生产级软件。每名工程师平均每天合并 3.5 个 PR。

这个数字本身不是重点，重点是报告里的一句话，被反复引用：

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

不是模型不够聪明，不是提示词不够精妙，不是上下文不够丰富——是环境。

几乎同时，HashiCorp 的联合创始人 Mitchell Hashimoto 在博客里给这件事起了个名字，叫 Harness Engineering，并给出了一个很简洁的定义：每当你发现 Agent 犯了一个错误，你就花时间设计一个解决方案，使它永远不再犯同样的错误。

这个定义我看了好几遍。越想越觉得，这才是对的问题意识。

这个模式，其实已经出现过三次了

理解 Harness Engineering 有一个很好的切入角度，就是把视野拉远一点。

十八世纪八十年代，瓦特改良蒸汽机的时候，顺带发明了一个叫离心调速器的装置。在它出现之前，必须有工人站在机器旁边，用手不停地调节阀门。有了调速器之后，一套带飞球的机械结构会自动感知转速、自动调节。工人的工作没有消失，只是变了——从亲手拧阀门，变成设计调速器本身。

后来 Kubernetes 出现，工程师不再需要手动重启服务，只需要声明目标状态，控制器会持续监测并自动修正偏差。角色又变了一次——从执行者变成规格说明的制定者。

现在是第三次。

1948 年，数学家诺伯特·维纳给这个反复出现的模式起了一个名字：控制论，来自希腊语里”舵手”的意思。你不再亲手拧阀门，而是掌舵。

Harness Engineering 本质上就是这个——把工程师从”亲手操作”的位置，迁移到”设计让系统自动运转的机制”的位置。

环境比模型更重要，这不是一句口号

有一组数据我觉得很有说服力。

LangChain 的编码 Agent 在一个叫 Terminal Bench 2.0 的基准测试上，做了一件很干净的实验：底层模型一个参数都没动，只优化了 Agent 运行的外部环境——文档结构、验证回路、追踪系统。结果排名从全球第 30 位跃升至第 5 位，得分从 52.8% 飙到 66.5%。

模型没变，Harness 变了，结果完全不同。

这让我想到一个比喻，是 LangChain 的工程师提出来的：Agent = Model + Harness。如果模型是一匹马，Harness 就是缰绳。马再强壮，没有缰绳也跑不了你想要的方向；有了合适的缰绳，普通的马也能稳定完成任务。

试图扛着马跑，才是真正的问题所在。

Harness 到底包含什么

Thoughtworks 的工程师 Birgitta Böckeler 做了一个很清晰的拆解，把 Harness 分成三个维度，我觉得很好用。

第一个维度是上下文工程。

这里有一个 OpenAI 团队踩过的坑值得说一下。他们早期把所有内容——系统说明、架构规范、代码风格、边界条件——全部堆进一个 AGENTS.md 文件。结果 Agent 被信息淹没，性能反而下降了。

后来他们演化出一个”渐进式披露”的方案：AGENTS.md 只做目录，真实内容放在结构化的 docs/ 目录里，Agent 按需逐层读取。逻辑其实很简单，就像新员工入职，没人第一天就要读完公司所有文档。

更进一步，他们还把可观测性数据直接暴露给 Agent——日志、指标、追踪信息全部开放，Agent 可以查询运行时数据，甚至能操作浏览器来重现 Bug、验证修复。Agent 从此不只是”写代码的工具”，它开始能看见代码跑起来之后发生了什么。

第二个维度是架构约束。

这里有一个细节我觉得特别能说明问题：OpenAI 的工程师花了好几个小时，专门重写 Linter 的错误输出格式。不是为了让人看懂，而是为了让 Agent 能读懂——读懂之后自动修复。

Linter 输出的受众，从人类变成了 AI。

这件事本身就是一种思维方式的转变。约束不是用来限制的，是用来让正确的事情更容易发生的。当约束被机械化执行，Agent 会自然地在边界内工作，而不是不断试探边界。

Stripe 的做法也很有意思，他们把工作流拆成两类节点：可预测的步骤交给确定性代码，需要判断和创造力的环节才调用 LLM。把 LLM 关在”可控盒子”里，而不是让它到处乱跑。

第三个维度是熵管理。

这个维度最容易被忽视，但我觉得最关键。

Harness 本身也是代码和文档，它同样会腐化。规则会过时，例外会累积，系统会慢慢退化。如果 Harness 自身腐化了，Agent 读到混乱的指令，输出的就是混乱的代码。

OpenAI 的解法是部署专用的清理 Agent，定期扫描文档漂移和模式违规。把技术债治理从”季度任务”变成”日常垃圾回收”。

三个维度加在一起，Böckeler 的总结是：上下文工程让 Agent 知道该做什么，架构约束确保只在边界内行事，熵管理保障整个系统不随时间退化。缺少任何一环，Harness 都会在某个时间点失效。

工程师的工作在变，这件事比你想的更深

我在这个行业待了好几年，见过很多次”工程师的工作要变了”的讨论，大多数都是虚惊一场。但这次感觉不太一样。

OpenAI 实验里的工程师，日常工作已经变成了三件事：

维护文档和上下文体系，让 Agent 始终知道项目的边界在哪；把业务目标和质量标准表达成机器可以理解的形式，用 Schema 定义数据结构，用测试用例定义预期行为；构建自动化的验证机制，让质量问题在生成阶段就被拦截，而不是堆到人工审查环节。

有人描述过一个很生动的工作场景：某个做工具的创始人在用 Agent 的时候，只讨论架构和重大决策，完全不碰具体代码实现。他是那种”在脑子里保存着整个项目高层结构”的人，Agent 是他的执行系统。

这让我想了很久。系统理解的深度，比写代码的速度重要得多——这句话放在三年前说，可能是废话；但现在，它越来越像一个真实的能力要求。

组织层面的变化也很明显。小团队完成大体量的工程输出，已经不是新鲜事了。但有一个问题我觉得值得认真对待，就是”学徒缺口”——如果初级开发者一入行就跳进 Agent 驱动的循环，跳过了手动开发的阶段，他们将来能不能建出真正健壮的 Harness？

这个问题没有简单的答案，但至少值得每个技术管理者想一想。

如果你想开始，可以这样走

说了这么多理论，落地才是真的。

第一步，目标只有一个：让 Harness 能跑起来，哪怕很粗糙。把 AGENTS.md 改成目录入口，真实内容放进结构化的 docs/；加几条高价值的自定义 Lint 规则；配好 CI，让代码提交时自动跑测试。

有一个建议我觉得很实用：把同一个任务做两遍，先自己手动完成，再让 Agent 做一遍。不是为了比较结果，是为了建立对 Agent 能力边界的直觉。你得先知道它会在哪里出错，才能知道要在哪里加约束。

第2步，重点是让系统能”看见”Agent 在做什么，并判断做得对不对。建日志系统，把关键用户旅程变成可执行的验收场景，引入自动修复 PR 的流程。

第3步，开始处理 Harness 自身的腐化问题。定期跑垃圾回收任务，建质量评分看板，把高频的 review 反馈固化成工具规则。

有三个误区需要提前说清楚。

“零人工写代码”不是目标，那是一个极端实验的副产品，真正的目的是逼团队补齐 Harness 缺口。

“有 AGENTS.md 就有 Harness”，这个想法会害了你。单文档规则会迅速失效，必须结构化、可校验、可回收。

还有一个短板现在大多数团队都没补上：功能正确性验证。能通过所有 Linter 和架构测试的代码，不等于做了用户真正需要的事情。LangChain 的行业数据显示，89% 的团队已经有可观测性，但只有 52% 建了评估体系。这个差距，是接下来一年最值得填的坑。

最后想说的

那些当年设计了瓦特调速器的工人，后来没有回去拧阀门。不是因为他们不会拧，而是因为那件事已经没有意义了。

从提示词工程到上下文工程再到 Harness Engineering，三年时间，这个行业对”怎么让 AI 可靠工作”这个问题的理解，已经走过了三代。每一代的答案都没有错，只是不够完整。

现在我们知道了，光说对话语不够，光给对信息也不够，还需要设计一个让 Agent 能在其中稳定运转的环境。

这件事大多数团队还没开始做，但方向已经很清楚了。

人类最核心的竞争力，从来都不是去扛着马跑，而是通过构建高效的协作系统，让那些强大的智能精准落地