什么是 Harness Engineering？OpenAI Codex 团队亲自给出答案

过去五个月OpenAI 的一个团队做了一件听起来有点疯狂的事从零开始交付一款软件产品的内测版本全程没有一行代码是人手写的。这不是玩具项目。这个产品有真实的内部日活用户和外部 Alpha 测试者经历了完整的交付、部署、故障和修复流程。从应用逻辑、测试、CI 配置、文档、可观测性到内部工具每一行代码全都出自 Codex 之手。据估算完成这些工作只花了手工编码所需时间的1/10。人类掌舵智能体干活。这是团队刻意选择的限制——正是为了搞清楚当工程师不再写代码而是去设计环境、明确意图、构建反馈回路的时候软件工程会变成什么样。从一个空仓库开始2025 年 8 月底第一次 commit 推进了一个空的 Git 仓库。初始架构——仓库结构、CI 配置、格式化规则、包管理器设置和应用框架——全部由 Codex CLI 配合 GPT-5 在一套现有模板的指导下生成。就连那份告诉智能体怎么在这个仓库里干活的AGENTS.md文件也是 Codex 自己写的。五个月后这个仓库已经积累了大约一百万行代码涵盖应用逻辑、基础设施、工具链、文档和内部开发者工具。期间大约合并了 1500 个 Pull Request背后只有三名工程师在推动 Codex 运转。平均算下来每人每天处理 3.5 个 PR——而且随着团队扩充到七人这个吞吐量还在增加。更重要的是这不是为了刷数字产品已经在数百名内测用户中跑起来了其中不乏每天都在用的重度用户。整个开发过程中人类从未直接贡献过任何代码。这成了团队的核心信条不手写代码。工程师的角色变了没有手工编码这回事之后工程师的注意力全部转向了系统设计、架构决策和杠杆效应。早期进展比预想的慢但原因不是 Codex 能力不行而是环境描述不够清晰。智能体缺少推进高层目标所需的工具、抽象层和内部结构自然就卡住了。这时候工程师的主要任务就变成了帮智能体把活干起来。实操起来这是一种深度优先的工作方式把大目标拆成小模块设计、编码、评审、测试等提示智能体逐个构建再用这些模块去解锁更复杂的任务。遇到卡点解法几乎从来不是再试一次而是反问自己还缺什么能力怎么让这个能力对智能体来说既清晰又可执行人类和系统的交互几乎全靠 Prompt工程师描述任务跑起智能体等它开 PR。为了推动 PR 走完流程会让 Codex 在本地自审自己的改动请求其他智能体做专项评审响应人类或智能体给出的反馈循环往复直到所有评审方都满意这实际上就是一个 Ralph Wiggum 循环。Codex 直接调用标准开发工具gh、本地脚本、内嵌技能来收集上下文不需要人工手动粘贴内容进 CLI。人类可以审 PR但不是必须的。随着时间推移绝大多数评审工作已经切换成智能体对智能体的模式来处理了。让应用本身变得可读随着代码产出越来越多人工 QA 成了新的瓶颈。人类的时间和注意力是固定的所以团队一直在想办法让应用的 UI、日志、指标这些东西直接对 Codex 可读从而扩大智能体的自主能力。比如让应用支持基于 git worktree 启动这样 Codex 就能为每次变更单独跑一个实例。再比如把 Chrome DevTools 协议接入智能体运行时并封装了处理 DOM 快照、截图和导航的技能。这让 Codex 能够自己复现 Bug、验证修复直接对 UI 行为进行推理。Codex 使用 Chrome DevTools MCP 驱动应用程序以验证其工作可观测性工具也做了同样的事。日志、指标和追踪数据通过一个本地可观测性栈暴露给 Codex这个栈对每个 worktree 来说都是临时的任务完成后连同日志和指标一起销毁。Codex 可以用 LogQL 查日志用 PromQL 查指标。有了这些上下文确保服务启动在 800ms 内完成或这四个关键用户旅程中任何 span 都不得超过两秒这类 Prompt 就真的能落地了。单次 Codex 运行在一个任务上持续工作超过六个小时的情况很常见通常都是趁人睡觉的时候跑的。把代码仓库当成记录系统上下文管理是让智能体在大型复杂任务中有效运转的最大挑战之一。团队学到的最早的一条经验很直接给 Codex 的应该是一张地图而不是一本 1000 页的说明书。他们试过一个巨大的AGENTS.md方案结果可想而知——失败了原因有好几个上下文本来就是稀缺资源一个巨型指令文件会挤掉任务、代码和相关文档当什么都重要的时候智能体最终会在局部做模式匹配而不是有意识地导航而且这种文件会迅速腐烂变成陈旧规则的坟场人类一旦停止维护它就悄悄成了麻烦的来源。所以AGENTS.md不再是百科全书而是目录。仓库的知识库存放在一个结构化的docs/目录里作为记录系统使用。一份简短的AGENTS.md大约 100 行被注入上下文主要充当地图指向其他地方更深层的真实信息来源。AGENTS.mdARCHITECTURE.mddocs/├── design-docs/│ ├── index.md│ ├── core-beliefs.md│ └── ...├── exec-plans/│ ├── active/│ ├── completed/│ └── tech-debt-tracker.md├── generated/│ └── db-schema.md├── product-specs/│ ├── index.md│ ├── new-user-onboarding.md│ └── ...├── references/│ ├── design-system-reference-llms.txt│ ├── nixpacks-llms.txt│ ├── uv-llms.txt│ └── ...├── DESIGN.md├── FRONTEND.md├── PLANS.md├── PRODUCT_SENSE.md├── QUALITY_SCORE.md├── RELIABILITY.md└── SECURITY.md设计文档有索引和目录包括验证状态和一套核心理念。架构文档提供域和包分层的顶层地图。一份质量评分文档对每个产品领域和架构层打分并持续追踪差距。计划被当成一等公民来对待。小变更用轻量临时计划复杂工作则记录在执行计划里附带进度和决策日志全部提交进仓库。活跃计划、已完成计划和已知技术债务都做了版本控制并集中存放智能体不依赖外部上下文就能独立运转。这实现了渐进式披露智能体从一个小而稳定的入口开始被引导着去找下一步需要的信息而不是一上来就被淹没。这套规则被严格执行。专属 linter 和 CI 任务会验证知识库的更新状况、交叉链接和结构正确性。一个定期运行的文档园丁智能体会扫描那些不再反映真实代码行为的过时内容并发起修复用的 PR。为智能体的可读性优化随着代码库增长Codex 的设计决策框架也在演变。由于整个仓库都由智能体生成团队首先针对 Codex 的可读性做优化。就像工程团队会努力让代码对新入职的工程师友好一样人类工程师的目标是让智能体能够直接从仓库推理出完整的业务领域。从智能体的视角看它在运行时上下文里访问不到的东西对它来说就不存在。存在 Google Docs、聊天记录或人脑里的知识系统根本看不到。仓库本地的、经过版本控制的产物——代码、Markdown、Schema、可执行计划——才是它能看到的全部。智能体知识的局限性Codex看不到的东西就不存在团队意识到需要把越来越多的上下文推进仓库。那次让团队在架构模式上达成共识的 Slack 讨论如果智能体找不到它那它对这件事的了解程度就跟一个迟到三个月入职的新员工一样——什么都不知道。这个框架也明确了很多取舍。团队倾向于选择那些可以完全内化在仓库推理中的依赖和抽象。对智能体来说通常被称为无聊的技术——因为其可组合性、API 稳定性和在训练集中的出现频率——往往更容易建模。有时候让智能体重新实现部分功能子集比绕过公共库里不透明的上游行为要便宜得多。比如团队没有引入通用的p-limit风格包而是用上了自己的带并发的 map 辅助函数与 OpenTelemetry 仪表紧密集成100% 测试覆盖率行为完全在掌控之中。用架构约束代替微观管理光靠文档撑不起一个完全由智能体生成的代码库的连贯性。通过强制执行不变量而不是对实现过程微观管理才能让智能体快速交付而不动摇基础。比如要求 Codex 在边界处解析数据形状但不规定具体用哪个库模型似乎偏好 Zod但没有强制指定。智能体在有严格边界和可预测结构的环境里效率最高所以团队围绕一个严格的架构模型来构建应用。每个业务域被划分为一组固定的层依赖方向严格验证只允许有限的几条边。这些约束通过自定义 linter当然也是 Codex 生成的和结构测试来机械地强制执行。规则如下在每个业务领域内比如应用设置代码只能向前依赖于一组固定的层Types → Config → Repo → Service → Runtime → UI。横切关注点认证、连接器、遥测、功能标志通过单一的显式接口进入Providers。其他任何方式都不被允许并通过自动化来强制执行。具有明确交叉界限的分层领域架构这种架构通常要等团队扩张到数百人时才会认真推进。对于编码智能体来说它是一个早期的先决条件有了约束速度才不会下降架构才不会漂移。在实践中还有一小组品味不变式作为补充。比如通过自定义 lint 静态强制执行结构化日志记录、命名约定、文件大小限制以及特定平台的可靠性要求。由于这些 lint 是定制的错误信息里可以直接注入修复指令方便智能体理解。在以人为主的工作流里这些规则可能显得迂腐。有了智能体它们就变成了倍增器一旦编码进去就能立刻应用到所有地方。团队也清楚地划出了哪里要管、哪里不用管。类似于领导一个大型工程平台组织在中央层面强制执行边界在本地层面允许自主权。边界内智能体可以在解决方案的表达方式上有很大自由。生成的代码不总是符合人类的风格偏好这没关系。只要输出是正确的、可维护的对未来的智能体运行而言也清晰易读就算过关。人类的品味会持续反馈进系统。评审评论、重构 PR 和面向用户的 Bug会被记录为文档更新或直接编码进工具。文档不够用时规则就转化为代码。吞吐量改变了合并理念随着 Codex 的吞吐量上来了很多传统工程规范变得不再适用。这个仓库运行时尽量减少阻塞性合并门。PR 生命周期很短。测试的偶发失败通常通过后续重跑解决而不是无限期地卡住进展。在一个智能体吞吐量远超人类注意力的系统里纠错成本低等待成本高。低吞吐量环境下这样做是不负责任的。在这里这通常是正确的选择。智能体生成到底意味着什么说整个代码库由 Codex 智能体生成这里说的是真正意义上的整个代码库。智能体产出的东西包括产品代码与测试、CI 配置和发布工具、内部开发者工具、文档和设计历史、评估框架、评审评论和回复、管理仓库本身的脚本以及生产仪表板定义文件。人类始终在场但工作的抽象层次和过去完全不同。团队优先处理工作、把用户反馈转化为验收标准并对结果做验证。当智能体卡住时这被视为一个信号识别缺失的东西——工具、指导与约束、文档——然后反馈进仓库修复依然由 Codex 自己来写。智能体可以直接使用标准开发工具会拉取评审反馈、行内回复、推送更新经常还会自己压缩并合并自己的 PR。自主程度在不断提升随着越来越多的开发环节被直接编码进系统——测试、验证、评审、反馈处理和恢复——这个仓库最近跨过了一个重要门槛让 Codex 可以端到端地驱动一个新功能。给定一个 Prompt智能体现在可以完成整套流程验证代码库当前状态、复现已报告的 Bug、录制一段演示故障的视频、实施修复、运行应用验证修复、录制第二段视频展示解决方案、开 PR、响应智能体和人类反馈、检测并修复构建故障、仅在需要判断时才交由人工处理、最后合并变更。这个能力在很大程度上依赖这个仓库特定的结构和工具不应该假设它能无条件泛化到其他场景——至少现在还不行。学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%免费】