https://openai.com/zh-Hans-CN/index/harness-engineering/ 这个文章主要是讲什么

回复 群友 716： 这篇主要讲：当代码交给 Agent 写，工程师应该怎样搭建环境，让它能持续、可靠地完成开发，而不是只生成一次看起来不错的代码。 先举文章里的实际场景：你告诉 Codex“修复这个页面的 bug”，它不只是改文件，而是能启动应用、操作浏览器复现问题、查看日志、修改代码、再次验证、提交 PR，并根据审查反馈继续修。遇到需要人判断的地方，再交给人。 让这套流程跑起来的工具、规则、文档和反馈机制，就是这里说的 Harness。可以理解为给 Agent 配齐工作台、操作规范和验收设施。 文章有五个重点。 一、不是不断优化提示词，而是补齐工作环境 Agent 卡住时，别只说“再试一次”。要检查：它是不是缺少业务背景、调试工具，或者不知道怎样才算完成？ 工程师的工作从“亲手实现”转向“让它具备实现和验证的条件”。 二、知识要能被 Agent 找到，而不是只存在人的脑子里 他们试过把所有规则塞进一个巨大的 AGENTS.md，结果不好：信息太多、重点不清、容易过时。 后来改成简短目录，把具体设计、业务规则和执行计划分类存进仓库，让 Agent 按需查阅。重点不是上下文越多越好，而是相关信息找得到、可信且不过时。 三、规则要能自动检查，不能只靠叮嘱 比如“不要跨层乱调用”，只写在文档里不够；要让自动检查发现违规，并告诉 Agent 怎么修。 人的要求变成可执行的约束，才不会每次都靠人工重复纠正。 四、Agent 必须能自己看到结果 写完代码不等于完成任务。它需要能看页面、查日志、跑测试，才能判断自己到底有没有修好。 这也是“会生成代码”和“能闭环完成工作”的关键区别。 五、还要持续清理它制造的技术债 Agent 会模仿仓库已有写法，包括坏写法。所以他们安排后台 Agent 定期检查重复实现、文档过时和架构偏移，小步修复，避免问题越积越多。 文章的实验背景是：OpenAI 团队用约五个月构建了一款内部 beta 产品，称代码全部由 Codex 编写，人工主要负责方向、环境和验收。但这不是“随便给一个 Agent 就能全自动开发”的证明；作者明确说，效果高度依赖他们为这个仓库搭建的配套设施，长期可维护性也仍在观察。 一句话理解：不是研究怎么让 AI 多写代码，而是研究怎么让 AI 写出来的东西能被验证、被约束，并且长期维护下去。