前段时间发了一篇关于CL-bench 的文章，聊的是上下文工程的天花板问题。
模型的吸收能力有硬天花板，你塞再多上下文，它也只能消化一小部分。
而接下来这个实验，恰好补上了另一半答案。
同一个AI模型，代码一行没改，在一个编程benchmark上的排名从三十名开外直接冲进了前五。涨了13.7%。
模型纹丝不动，成绩变了。
这就是LangChain二月份做的一个实验，用的GPT5.2 Codex，只调了模型外面那层东西，系统提示、工具配置、几个中间件钩子。
然后在Terminal Bench 2.0上，排名直接起飞。
以前大家默认的逻辑是，AI编程效果不好，那就换更强的模型。但这个实验说的是另一件事，天花板不一定在模型上，也可以在模型外面，在你给它搭的那套环境里。
2026年有个词，你会越来越频繁地听到，Harness Engineering。
Harness，一套给AI用的缰绳
Harness这个词，字面意思是马具，就是那套缰绳、马鞍，套在马身上，让骑手能控制方向和力度的全套装备。
用在AI这个语境里，这个比喻不要太贴切。
AI就像一匹动力爆棚但不太守规矩的马，跑得快没问题，但你不给它套上缰绳，它往哪跑、什么时候停、跑偏了怎么拉回来，就全是问题。
Harness Engineering，就是造这套缰绳的工程学。
这个概念最早是Mitchell Hashimoto提出来的，就是HashiCorp的联合创始人、Terraform的缔造者。
他在2026年2月的一篇博客里，把自己跟AI协作的历程分成了六个阶段，第五个阶段就叫Engineer the Harness。
他的定义特别朴素，每当你发现Agent犯了一个错误，你花时间设计一个方案，确保它永远不会再犯同样的错误。
不是去骂模型笨，不是去换更贵的模型，而是在环境层面堵住这个错误再次发生的可能性。
OpenAI的实验
在Mitchell发文几天之后，OpenAI发布了一篇叫《Harness engineering: leveraging Codex in an agent-first world》的实践报告。
他们用三个工程师，五个月时间，从一个空仓库开始，全程用Codex Agent写代码，最后交出来的成绩单是这样的，合并了大约1500个PR，产出了约一百万行代码，工程师手写代码行数是0。
三个工程师，五个月，零行手写代码，那他们每天的工作内容是什么？
- 设计仓库结构写agent.md、写文档，告诉Agent这个仓库的规矩是什么，哪些目录放什么，哪些文件不能动，架构的依赖方向是什么。
- 配Linter规则在 agent-first 工作流里，linter 不只是给人看的工程规范，它也成了 Agent 的即时纠错信号。Agent写了一段不符合架构约束的代码，Linter直接拦住，Agent自己就知道要改。
- 搭CI管道创建反馈循环，Agent写完代码，自动跑测试，测试不过就自动打回，Agent再改，改到通过为止。
很多编码与修复动作可以在 Agent 循环里完成，但人类工程师仍然负责规格、约束、反馈系统和关键结果把关。
还有一个特别有意思的做法，他们专门搞了一个“垃圾回收”Agent。
这个Agent定期扫描整个仓库，找到跟架构约束不一致的地方，自动提PR修好。
纪律没有消失，只是转移了。
以前纪律体现在好好写代码、认真做Code Review、遵守编码规范。现在纪律体现在，构建好让Agent工作的环境，包括文档、约束、反馈回路。
这些工作大多发生在环境层，但它们决定了整个系统能不能稳定往前推进。
这其实已经很接近一个新的岗位画像了：
你不再主要是写代码的人，你开始变成给Agent造环境的人。
AI编程经历的三个范式
回头看过去三年，AI编程经历了三个范式，每一代关注的问题不一样，每一代都比上一代管得更宽。
2023到2024年是Prompt Engineering的时代，核心问题是怎么跟AI说话。大家研究的重心全在措辞上，一条提示词反复打磨，加角色设定、加Few-Shot示例、加思维链。
这一轮留下来的遗产是，大家终于意识到了措辞很重要，不同的说法结果天差地别。
但局限也很快暴露了，一条消息里能塞的信息就那么多，任务稍微复杂一点，靠措辞根本兜不住。
到了2025年，Context Engineering被更集中地讨论起来，核心问题变成了给AI看什么信息。
不再只盯着措辞本身，而是开始设计整个信息环境，系统提示词怎么动态注入、对话历史保留多少、RAG检索结果怎么接、工具调用的输出怎么再喂回去。
这一步的进步很大，但它还是只管输入端，管的是你塞给模型什么信息。
Agent跑出去干活的过程中发生了什么，你依然管不了。
到了2026年，Harness Engineering来了，核心问题再次升级，给AI造什么样的工作环境。
它管的不只是给模型喂什么信息，而是模型之外的整个执行环境。
打个比方：
- Prompt Engineering是你在教马听懂口令
- Context Engineering是你在给马看清路况，
- Harness Engineering是你在给马造一条完整的赛道，有护栏、有弯道提示、有终点线，马在里面跑，既快又不会翻车。
前两代你是AI的对话伙伴，到了第三代你是AI的环境架构师。
Agent翻车的原因
跟模型聪不聪明基本无关
回到LangChain的那个实验。
他们事后分析了Agent失败最常见的原因，发现了一个很反直觉的结论，大部分翻车，跟模型的智商没关系。
真正让Agent翻车的是这些事：
- 写完代码不测试就提交了：加提交前必须跑验证的中间件，解决。
- Agent不知道自己在什么目录、什么位置、当下有什么工具可用，全靠瞎摸：加自动注入项目结构和工具列表的中间件，解决。
- 反复改同一个文件，陷入死循环：加一个循环检测器，改N次就提醒换思路，解决。
- Agent不会管理时间，无限迭代，永远觉得还能更好：加时间预警，解决。
每一个问题的答案，都不是换更强的模型，而是给现有模型加了一道缰绳。
他们的结论也很直白，花在Harness上的工程，回报率远高于花在模型选择上面。
这是目前非常重要的一个认知，尤其是做AI产品的。
一个真实踩坑的例子
腾讯云开发者社区有一篇文章提到了一个很典型的案例。
一个团队在做跨服务开发的时候，服务A定义了某个错误码的含义，但服务B的Agent在实现的时候完全不知道这个跨服务的语义约定，于是Agent自己猜了一个处理方式。
关键是，AI的猜测不会告诉你这里我猜了。它只是生成了一段看起来完全合理的代码，然后上线之后才发现行为不符合预期。
这个Bug不是Agent能力不够，是跨服务的错误码契约没有被写进规范文档里，在Harness的环境信息里，这一块是空白的。
后来他们在系统级Spec里补充了完整的错误码契约，同一个Agent生成的实现直接通过了验证。
所以你会发现，Harness Engineering干的最核心的一件事，
其实不是什么高深的技术架构，
而是把原来散落在人脑里、对话里、会议记录里的那些隐性知识，变成Agent能读到、能推理的显性资产。
Harness的三根支柱
如果按Martin Fowler网站上的工程分析来拆，Harness大致可以看成三层：
1
Context Engineering
没错，上下文工程没有被淘汰，而是被吸纳成了Harness的一部分。
持续增强代码库中的知识库，加上Agent对可观测性数据、浏览器导航等动态上下文的访问，这些依然是基础。
2
Architectural Constraints
架构约束，用代码强制执行。
自定义Linter、结构化测试、依赖方向检查，这些都是确定性的手段，不存在模型心情好就遵守、心情不好就忽略的情况。
3
Entropy Management
熵管理，也可以叫垃圾回收。
在长时间运行的系统中，一切都会腐烂，文档过时、规则被绕过、约定被遗忘。
所以需要定期运行的Agent来主动对抗熵增，发现不一致就自动发起修复。OpenAI的做法是让Agent定期扫描架构漂移，自动提PR。
技术债务就像一笔高息贷款，不断地小额偿还，总比让债务不断累积要好。
写在最后
从Prompt，到Context，再到Harness，AI工程这条线走到今天，其实也就短短几年。
但这几年里，变化已经足够明显。
AI工程的难点，正在慢慢离开模型本身，转向模型之外。
Harness当然不会是终点。
今天我们开始讨论怎么给 Agent 搭环境，
明天很可能就会开始讨论：这套环境能不能自己优化、自己发现漏洞，自己减少错误，自己推动下一轮迭代...
如果这一步继续往前走，很多角色可能都会被重新定义。
当然，另一面的问题也已经出现了。
Harness越来越强，系统也会越来越重。
规则会不会越来越复杂？配置会不会越来越膨胀？不同团队 fork 出去的那一套“缰绳”，最后会不会变成新的维护负担？
这些问题，现在都还没有标准答案。
但大方向已经清楚了：
过去我们习惯把能力押在模型上，现在越来越多的价值出现在模型外面那一层。
那些原本交给模型猜的东西，正在被重新拿回到工程系统里，变成可以设计、可以约束、可以验证的东西。
我们认为，这才是Harness Engineer真正值得讨论的地方。
它提醒我们，AI编程接下来比拼的，是谁更早搭出了一套真正能跑、能控、能持续演进的系统。
当越来越多企业开始认真给自己的 AI 搭缰绳时，谁来帮他们把这套系统真正搭起来，也会成为一个现实的问题。
我们希望，极客上线能成为这个答案里的一部分。
