什么是 Harness Engineering？为什么 AI 团队正在从“写代码”转向“造环境”

很多人对 AI 编码的理解还停留在一个很朴素的阶段给模型一句需求让它吐一段代码。但如果你真的想把 Agent 用到工程生产里很快就会发现问题根本不在“模型会不会写代码”而在它有没有一个能稳定完成任务的运行环境。这也是为什么最近越来越多团队开始谈一个关键词Harness Engineering。它不是某个框架也不是某个协议而是一种新的工程方法。简单说当 Agent 开始承担越来越多的开发工作时工程团队的核心任务正在从“亲自写代码”转向“设计环境、表达意图、构建反馈回路”。这就是我理解的 Harness Engineering。一、Harness 到底是什么很多人第一次看到 harness会把它理解成“工具集”或者“脚手架”。这两个理解都只对了一半。在 Agent 工程语境里harness 更像是一个让 Agent 能可靠工作的可控运行框架。它至少包含下面几部分工具接入方式终端、浏览器、文件系统、数据库、知识库、CI任务边界Agent 能做什么不能做什么做到什么程度要停反馈机制测试、日志、指标、截图、review、lint、构建结果约束与规则代码规范、目录结构、提交要求、评审流程任务闭环失败时怎么重试成功时怎么验证什么时候升级给人如果没有这些东西所谓“AI 编码”通常只会变成一次性代码生成。如果这些东西搭好了Agent 才可能从“会写一点代码”升级到“能持续完成工程任务”。二、为什么现在工程师的工作正在变化OpenAI 在2026-02-11发布的《Harness engineering: leveraging Codex in an agent-first world》里讲得非常直白他们做了一个实验用 Codex 从空仓库开始构建产品所有代码、测试、CI、文档、观测与内部工具都由 Codex 写出人的主要职责不再是直接写代码而是设计环境、明确目标、建立反馈回路这里最值得注意的不是“0 手写代码”这个标题党卖点而是背后的工程结论当 Agent 真正进入主流程后瓶颈会从“代码产出速度”转移到“环境是否足够清晰、可见、可验证”。换句话说模型不再只是一个回答问题的系统而是一个需要被“驯化进工程闭环”的执行体。三、Harness Engineering 真正在解决什么问题1. 让 Agent 看得见Agent 最大的问题之一不是不会推理而是“看不见”。它看不见的东西基本就等于不存在。比如Slack 里的临时讨论人脑里的口头共识没有写进仓库的架构原则只能让人手工点开的监控系统所以 Harness Engineering 的第一件事不是加更多 prompt而是把信息变成 Agent 可见的对象仓库内文档可查询日志可访问指标可重放 UI 状态可执行的脚本可验证的规则这也是为什么越来越多团队开始重视AGENTS.mdskillsrepo 内设计文档execution plans本地观测栈浏览器自动化它们的共同目标都不是“文档更漂亮”而是让 Agent 真正能看懂系统。2. 让 Agent 能自证如果一个 Agent 只能写代码不能验证代码那它本质上还是高级补全。真正的工程 Agent必须能回答这几个问题我改了什么为什么这么改测试过没有UI 是否正常性能有没有退化构建是否通过review 意见有没有处理这就要求 harness 不只是“执行工具”还要提供反馈闭环。比如运行单测并读取结果拉起应用并自动做 UI 检查查询日志和指标根据 review comment 自动补改在失败后重试或转人工没有这一层Agent 的上限就很低。3. 让 Agent 在边界内自由最差的做法是一边想让 Agent 快一边靠人工在每一步死盯细节。最好的做法是把硬约束提前写进系统让 Agent 在约束内高速度运行。比如你不需要规定它每一行代码怎么写但你可以规定数据必须在边界校验PR 必须通过测试UI 修改必须经过截图对比文档变更要同步更新性能指标不能超过阈值这就是一个很重要的转变不是微操实现而是约束不变量。Harness Engineering 的核心不是让人干更多活而是让系统替人守住底线。四、为什么“写代码”正在让位于“造环境”以前优秀工程师的核心竞争力往往是抽象能力编码速度调试能力架构判断现在这些能力仍然重要但表达形式变了。在 Agent-first 团队里更值钱的能力正在变成你能不能把任务讲清楚你能不能把反馈机制搭出来你能不能把约束写进系统你能不能把隐藏知识沉淀进仓库你能不能把模糊目标变成可验证标准也就是说工程师没有消失只是工作的抽象层变高了。从这个角度看Harness Engineering 不是“工程师被替代”而是“工程师职责升级”。五、Harness、Skill、MCP 分别扮演什么角色这几个词经常一起出现但不要混为一谈。Harness负责运行环境、反馈闭环、约束机制和任务编排边界。它解决的是Agent 怎样稳定干活。Skill负责把具体任务经验封装成可复用能力单元。它解决的是Agent 遇到某类任务时应该怎么做。MCP负责把工具、资源和上下文能力接给模型或 Agent。它解决的是Agent 能连什么、怎么连。所以一个常见组合是Harness 定义运行框架 Skill 提供任务套路 MCP 提供工具接入这三者一起才更像一个能在生产里持续运转的 Agent 系统。六、做不好 Harness Engineering团队最容易踩的 4 个坑坑 1把 prompt 当成万能控制器很多团队遇到 Agent 出错第一反应就是“把 prompt 写得更长一点”。但如果日志不可见、测试不可跑、UI 不可验证、文档不可发现prompt 再长也只是补丁。坑 2只有执行没有验证Agent 改代码很快但没有验证链路时它只会更快地产生不确定性。速度不是问题无法证明对错才是问题。坑 3知识不进仓库如果关键知识还停留在聊天记录、会议口头结论和人脑里Agent 永远只能“半盲工作”。坑 4把 Agent 当实习生而不是系统组件实习生靠人盯系统靠机制跑。如果你的使用方式永远是“它写一点我补一点我再改一点”那你构建的不是 Agent 工程体系而只是更快的代码草稿器。七、我对 Harness Engineering 的一个直白判断未来 AI 编码团队的竞争力不会只取决于谁的模型更强。更关键的问题会变成谁的仓库更适合 Agent 理解谁的流程更适合 Agent 执行谁的反馈回路更适合 Agent 自证谁的约束系统更适合 Agent 持续演化从这个意义上说Harness Engineering 其实是在设计“Agent 的工作场所”。一个混乱、不可见、不可验证的工程环境再强的模型进去也会掉速、失真、乱改。一个结构清楚、反馈完整、约束明确的环境普通模型也能持续产出很高价值。八、结语下一代工程效率不只是 AI 写得快而是系统喂得好如果你还把 AI 编码理解成“让模型多写几段代码”那你看到的只是最表面的一层。真正的变化在更深处工程团队正在从代码生产者变成 Agent 运行系统的设计者。这也是为什么我越来越觉得未来最重要的问题不是这个模型能写多少代码而是你有没有给它一个足够好的 harness让它把代码写对、改对、验对并稳定交付这才是 Harness Engineering 真正值钱的地方。参考资料OpenAIHarness engineering: leveraging Codex in an agent-first world2026-02-11