Harness Engineering：为什么最强的 AI 也需要一个操作系统

你以为瓶颈在模型数据说不是不换模型只改环境AI 编程准确率从 52.8% 跳到 66.5%。这不是假设是 LangChain 在 Terminal Bench 2.0 上做的控制实验。他们不换底层模型只改模型之外的部分——更好的上下文文件、结构化输出约束、自验证闭环、工具优化——准确率涨了 26 个百分点。部分任务场景更夸张从 42%代码生成类子任务跳到 78%几乎翻倍。同一匹马换一副缰绳成绩差了一倍。反过来看没有 Harness 的 Agent 是什么样OpenAI 的 Codex 团队在实验早期给了答案——Ryan Lopopolo 后来写道最初几周的产出几乎不可用。Agent 生成的 PR 反复被打回不是因为模型笨而是因为它没有架构地图、没有测试工具、没有验证自己输出的手段。工程师花大量时间人工审查和返工效率甚至不如手写。直到他们投入精力建设环境——给 Agent 造工具、定义约束、搭反馈闭环——产出质量才开始指数级跃升。这就是 2026 年 AI 工程界绕不开的一个公式Agent Model Harness模型提供智能。Harness 让智能变得可用。大多数时候一个更好的 Harness 比一个更好的模型管用得多。最终这个 Codex 团队的实验结果是3 名工程师5 个月全程不许手写一行代码合了 1500 个 PR产出约 100 万行可跑的代码做出了真有几百人在用的内测产品。效率大概是手动开发的 10 倍。但这个 10 倍不是模型给的——是 Harness 给的。Ryan Lopopolo 那句被到处引用的话值得每个用 AI 编程的人读一遍“Early progress was slower than we expected, not because Codex was incapable, but because the environment was underspecified.”早期进展比预期慢不是 AI 笨是我们没把环境定义好。你以为瓶颈在模型的智商其实瓶颈在你给它搭的工位。三代范式从教 AI 说话到给 AI 建操作系统Harness Engineering 不是凭空冒出来的概念。它是 AI 工程化走到第三阶段的产物——前两代范式各自啃下了一类问题也各自撞上了天花板。第一代Prompt Engineering2022 年兴起——教模型听话大多数人最熟的阶段。写更精确的指令、给示例、few-shot、Chain-of-Thought……核心是适配——让模型的输出格式和内容符合预期。Prompt Engineering 至今仍是基础功但它不再是全部。天花板在哪提示词太脆了。换个模型版本可能就废了同一个 prompt 今天好使明天翻车复杂任务靠堆提示词根本兜不住。第二代Context Engineering2024 年兴起——给模型补课提示词到了极限之后工程师开始往模型的视野里塞信息。RAG检索增强生成是代表——不改模型让它在回答前先翻一遍你的文档库。解决的问题是赋能——打破模型的知识围墙。但天花板也很快露头光补知识不补纪律。模型拿到了更多信息照样可能编造事实、越权操作、做到一半就丢了进度、同一个任务给出截然不同的结果。第三代Harness Engineering2026-——给模型建操作系统2026 年 2 月 5 日HashiCorp 联合创始人、Terraform 之父 Mitchell Hashimoto 写了一篇博文第一次给这个东西正了名Harness Engineering。6 天后OpenAI 发了那篇刷屏的报告——《Harness engineering: leveraging Codex in an agent-first world》拿 100 万行代码的实验结果给这个概念盖了章。三代范式的区别一张表就能看明白范式干什么类比Prompt Engineering教野马听口令适配Context Engineering给野马发地图和干粮赋能Harness Engineering装缰绳、上马鞍、修赛道驾驭换成程序员更熟的语言模型是 CPU上下文是 RAMHarness 是操作系统。谁会拿一颗裸 CPU 跑生产服务同理拿一个裸模型跑生产级 Agent就是把一台没装操作系统的电脑推上了生产线。大多数人只走了三步中的第一步“Harness Engineering现在是热词。社群里满屏缰绳工程”“马鞍比马重要”。但仔细一看大多数人在做的事——就是往 CLAUDE.md 里加了几行规则然后觉得自己掌握了 Harness。这跟买了双跑鞋就觉得自己是马拉松选手差不多一个意思。jimo.studio 做了一个很有价值的梳理把 Mitchell Hashimoto、OpenAI 和 Anthropic 三家的实践拆成了三个递进层次。大多数人卡在第一层真正的战斗力藏在后两层。第一层写规则Mitchell Hashimoto 对 Harness 有一句经典定义“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 犯错就花时间搞一个机制让它永远不再犯同样的错。他的开源项目 Ghostty 是这个原则的活标本。打开它的 AGENTS.md每一行规则背后都是一次真实的翻车记录。AI 编了一个不存在的经历加一条禁止编造困境。AI 乱改不该动的文件加一条只改指定文件。简单直接今天就能动手。但天花板也很明显规则是被动防御——AI 读到了才管用读不到就白搭。规则堆到几百行AI 反而更容易走神。OpenAI 团队对此有句大实话“Give Codex a map, not a 1,000-page instruction manual.”给它一张地图就行了别给一千页说明书。第二层造工具第一层是跟 AI 说一声别犯错。第二层是造一个工具让机器自动抓它犯没犯错。OpenAI 的 Codex 团队把这一层做到头了。他们发现早期进展慢不是 AI 能力问题是环境太简陋——AI 缺少完成任务的工具和验证手段。于是他们做了一个决定给 AI 造工具。• 让 AI 能启动应用、截屏、驱动浏览器来验证自己写的东西能不能用• 让 AI 能查日志、看监控指标来判断性能有没有达标• 让 AI 有一整套本地可观测性栈来自己排查问题工程师的活儿从写代码变成了让 AI 有能力验证自己的代码。他们管这叫角色重定义human codes → human steers, agent executes。人不再写代码人掌方向盘Agent 踩油门。这一层还包括一个关键动作把架构约束机械化。不靠跟 AI 说我们用分层架构而是造一个 linter违反分层规则的代码直接报错——连商量的余地都不给。我个人的判断是第二层是投入产出比最高的一步。大多数团队花 3-5 天配好 linter、CI 约束和基本的自动化测试就能感受到 Agent 输出质量的质变。不需要高深的架构设计不需要额外的模型开销——你已有的工程基建稍作改造就能用。如果你只能在三层里挑一层投入选这层。第三层分离评估Anthropic 的工程师 Prithvi Rajasekaran 捅破了一层窗户纸让 AI 自己检查自己的活儿它永远觉得自己干得不错。“Tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work.”让一个独立裁判变得苛刻远比让选手自我批评容易得多。这是结构性偏差。哪怕任务有客观标准代码能不能跑通AI 自我打分时依然倾向于放自己一马。Anthropic 的解法借鉴了生成-评估分离的思路类似 GAN 中 Generator 与 Discriminator 的角色分工不过这里是串行审查而非对抗训练生成和评估必须由不同角色完成。一个 AI 干活Generator另一个独立 AI 打分Evaluator。Evaluator 不是看 Generator 的自我报告而是拿 Playwright 去实际操作产品——点按钮、截屏、查功能——然后给出评分和具体改进意见。Generator 根据反馈迭代。差距有多大一个 4 分钟直出的网页跟一个经过 15 轮生成-评估迭代的网页视觉上就不像同一个物种。三层递进的脉络已经很清楚了层级代表干什么不够在哪第一层Mitchell Hashimoto写规则文件被动容易过载第二层OpenAI造自动化工具AI 仍可能自欺第三层Anthropic拆分生成器与评估器成本更高、架构更复杂你现在停在哪一层对照一下如果你只有 AGENTS.md你在第一层。如果你有 linter 和自动化测试在替 Agent 把关你在第二层。如果你有独立评估器在给 Agent 打分——恭喜你是少数派。七大组件一个完整的 Harness 长什么样三层方法论是设计理念七大组件是施工图纸。一个成熟的 Harness 不是七件东西摆在一起而是有优先级的。1. Context Engineering——地基所有 Harness 的起点。用CLAUDE.md或AGENTS.md给 Agent 画一张项目地图架构概览、编码规范、硬性规则。关键原则少就是好。OpenAI 建议核心规则文件控制在 60-100 行。把它当导航表“想做 X去看 Y 文件”不要当百科全书。详细规范丢到docs/目录里按需加载。2. Architectural Constraints——承重墙不指望 Agent 自觉守规矩用 linter 和结构性测试强制执行。ESLint 的no-restricted-imports能禁止组件直接导入数据库模块自定义脚本能验证分层架构没被破坏。思路很简单缩小解空间。可选方案越少翻车概率越低。3. Tools MCP Servers——工具箱Agent 得有趁手的工具。好的 Harness 通过 CLI 封装和 MCPModel Context Protocol服务器向 Agent 开放能力。一个值得记住的数据Harness.io 的 MCP v2 把工具从 130 多个砍到 11 个上下文占用从 token 窗口的 26% 降到 1.6%。工具不是多多益善是精才管用。优先挑 Agent 有海量训练数据的标准工具——git、npm、docker——别指望它用好你那个没文档的内部 CLI。4. Sub-agents Context Firewalls——隔离舱Agent 跑久了上下文越堆越多性能持续下滑——行话叫context rot上下文腐化。就像一个人同时处理 50 件事每件都记个大概但没一件记清楚。处方是拆任务、建防火墙每个子任务在独立会话中执行只传结构化结果不传原始对话。Anthropic 的做法是 Initializer Agent 负责规划Coding Agent 负责执行中间传的是 feature list 而不是对话记录——这样 Coding Agent 每次启动都是带着清晰指令的干净大脑。5. Hooks Back-Pressure——哨兵在错误扩散前拦住它。pre-commit hooks 做类型检查和 linting测试运行器每次改动后自动跑构建验证在部署前兜底。设计原则只有一条成功时安静失败时尖叫。别把冗长的成功日志灌进 Agent 的上下文——成功只需要一句PASS失败要大声喊出来并且带够调试信息。反过来做的团队会发现 Agent 被自己的成功日志淹死了几轮之后根本找不到关键信息。6. Self-verification Loops——验收关强制 Agent 在说我做完了之前验证跑测试、查构建、对比输出和规格、UI 任务截个屏看看。OpenAI 的做法是在完成度校验环节使用干净的上下文窗口重新注入原始目标——防止 Agent 在长对话中忘了自己要干什么然后随便交差。7. Progress Documentation——黑匣子任务超过 30 分钟就得有进度记录维护一个 progress.md、频繁 commit、用结构化列表而不是随手笔记。Agent 会话崩了、上下文耗尽了下一个会话看到进度文件就能从断点接上——没有这个就得从头来。对于跨天的长任务这是救命的组件。从个人到企业你该从哪一步开始理论到此为止。接下来是行动清单。一篇 Harness Engineering 最佳实践文章给出了一个三阶段路线图时间线非常务实阶段投入做什么回报入门信息层1-2 天写 AGENTS.md 结构化docs/Agent 输出一致性明显改善进阶约束层3-5 天linter CI 架构约束代码质量可控高阶自动化层1-2 周Agent 自验证闭环人工审查量大幅下降入门今天就能做。一份最小可用的 AGENTS.md 长这样# MyProject## 技术栈Next.js 14 TypeScript PostgreSQL Prisma## 目录导航| 想做什么 | 去哪里 ||---------|--------|| 改页面 | src/app/ (App Router) || 改组件 | src/components/ || 改API | src/lib/api.ts || 看规范 | docs/conventions/ |## 硬性规则CI 会检查- 组件中禁止直接导入 node_modules- 所有 API 调用走 src/lib/api.ts- 新功能必须有对应测试文件- 提交信息格式: feat|fix|refactor: 简要描述## 运行命令- 测试: npm test- 类型检查: tsc --noEmit- lint: npm run lint不到 30 行。够了。剩下的丢到docs/按需加载——别想一步到位先让 Agent 有张地图再说。进阶要几天但回报很实在把架构约束写成 linter 规则和测试脚本——不再靠跟 AI 说别这么做让工具自动拦。高阶是拉开差距的地方让 Agent 自己跑测试、验证结果、在干净上下文里重新检查任务完成度。到这一步你从逐行审查 AI 代码升级到只在 AI 搞不定时出手。企业视角Agent Sprawl 是下一个微服务蔓延把视角放大到企业层面还有一个绕不开的问题。htek.dev 的数据说2026 年企业平均跑着 12 个以上 AI Agent2027 年预计到 20 个。问题是只有 27% 被正确接入了更大的系统。剩下的 73% 是影子 Agent——有工具权限没人管没合规在体系外面野生运行。这跟 2018-2020 年微服务蔓延一模一样。当年每个团队各自起微服务起到最后发现没有统一的服务发现、没有链路追踪、出了问题不知道哪个服务挂了——后来靠 Service Mesh 治理。现在 Agent 蔓延走的是同一条路。解法也是同一个思路只不过治理对象从服务变成了 Agent•注册与准入新 Agent 上线必须走审批声明工具权限和资源需求•行为审计跨 Agent 的日志聚合谁在什么时间调了什么工具、改了什么文件全链路可追溯•成本管控全局 token 预算分配与实时告警防止一个 Agent 跑飞把月度预算烧光•标准化路径统一的 Harness 模板和护栏策略新 Agent 5 分钟可接入而不是从零搭建如果你是技术管理者这块比个人开发者的 AGENTS.md 优先级更高——一个没管好的影子 Agent 造成的破坏可能比十个没有 Harness 的个人 Agent 加起来还大。Harness Engineer这个岗位可能比你想的来得更快回头看 OpenAI 那个实验里的 3 名工程师——他们 5 个月没写过一行产品代码。他们干的是设计环境、定义约束、搭建反馈闭环、审查合并 Agent 生成的 PR。OpenAI 自己的说法是工程角色被重新定义了——从写代码的人变成造环境的人。这个新角色叫Harness Engineer。截至 2026 年 4 月这还不是一个被广泛使用的正式头衔——但打开 LinkedIn 搜一搜 “AI infrastructure engineer” 或 “platform engineer AI agent”你会发现越来越多的岗位描述里出现了这样的要求“设计 Agent 运行环境”“构建 AI 工具链和约束体系”“建立自动化代码审查流程”。这就是 Harness Engineer只是还没有被统一命名。不是传统后端也不是 DevOps是一个跨了两头又都不全沾的新物种。需要四样核心能力系统工程会搭分层架构、CI/CD 流水线、容器和沙箱——给 Agent 盖办公楼AI 工程化懂 LLM 的能力边界、Agent 的运行模式、上下文窗口怎么管系统思维不是修一个 bug而是想怎么让这类 bug 永远消失——Mitchell Hashimoto 那句话的工程化版本业务翻译把业务规则变成 Harness 里机器能执行的约束不是写进文档里祈祷 AI 自己看Y Build 有一句总结挺到位的2026 年最厉害的工程师不是写代码最多的那个是给 Agent 造环境造得最好的那个。软件工程正在分裂成两半一半是造环境工具、约束、闭环一半是管 Agent规划、审查、编排并行会话。代码还是有人写——只不过写的是 Agent工程师的活儿变成了让 Agent 写得又快又好又不惹祸。Harness 不是万能药在一头扎进 Harness 建设之前有几个现实得认清•标准化还没统一。Claude Code 的 CLAUDE.md、Codex 的 AGENTS.md、LangChain 的 agent config——每家有每家的规范跨平台迁移成本不低。你今天给 Claude Code 写的 Harness 规则换到 Codex 环境可能得重写一半。•多模态 Harness 还是空白。当前的 Harness 体系主要围绕文本和代码场景。针对图像生成、音频处理、视频编辑 Agent 的约束、校验和闭环机制行业还没有成熟方案。如果你的 Agent 涉及多模态很多校验手段得自己造。•多 Agent 协同是硬骨头。当一个项目里跑着 5 个以上 Agent角色冲突、任务死锁、记忆污染、成本失控这些问题会同时冒出来——目前的 Harness 架构还在追赶这个复杂度。•Harness 本身也可能变成技术债。规则写太多会过载工具搭太重会僵化校验层叠太厚会拖慢迭代。Harness 需要跟产品一样持续维护和瘦身——不是搭完就不管了。OpenAI 团队专门有一个GC Agent垃圾回收 Agent持续清理架构熵增说明即使是最佳实践者也在跟 Harness 膨胀做斗争。这些都是 2026 年正在被攻克的问题不是 Harness 的根本缺陷。但如果有人跟你说写个 CLAUDE.md 就能解决一切——你可以微笑着走开了。结语回到开头那个数字同一个模型换一副 Harness准确率差了 26%。部分场景差了近一倍。含义很直接没人只靠引擎赢比赛。如果你今天在用 AI 编程助手但还没投资 Harness大部分价值正在从指缝里漏出去。模型的能力已经够了——卡在你给它搭的环境上。四步走今天就能开始今天写一份 AGENTS.md。30 行就够地图不是百科。上面有模板复制粘贴改几个路径就行。这周每次 Agent 犯错花 5 分钟把修复写成规则或 linter。这叫错误零重复。这个月搭 Agent 自验证闭环——在 hook 里加入npm test和tsc --noEmit自动运行UI 任务用 Playwright 截图对比让 Agent 自己证明我真的做完了。之后别停在第一层。写规则只是起点自动化工具和独立评估才是真正拉开差距的东西。Mitchell Hashimoto 的那句话值得贴在工位上“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.”每修一次Harness 就强一分。这种强度是复利——不用升级模型Agent 自己就会越来越靠谱。不是未来的事。2026 年已经在发生了。而 2026 年最好的代码是你没写过的代码——因为你在造让 AI 替你写代码的系统。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】