Engineering

Harness Engineering：OpenAI 智能体工程总结 [!abstract] 这篇文章真正讨论的重点，不是“AI 会不会写代码”，而是“怎样搭建一个让智能体持续稳定地产出代码、测试、文档与修复的工程系统”。 [!note] 这是一份基于原文的整理版总结，偏重方法论提炼，不是逐段直译。 标题怎么理解 Harness Engineering 如果直译并不自然。结合全文语境，我更倾向把它理解为： 面向智能体的工程编排 为智能体设计工作环境、约束和反馈回路的工程实践 也就是说，重点已经不只是“让模型写代码”，而是让它在一个可读、可测、可验证、可修复的系统里持续工作。 一句话总结 OpenAI 用一个很小的工程团队，在几个月内做出了一个已经有真实用户使用的内部产品；在这个过程中，人类几乎不直接写代码，而是把主要精力放在搭建代码仓库结构、文档体系、工具链、架构约束、可观测性和自动反馈回路上，让 Codex 能稳定地产生、验证、修复并合并变更。 文章的核心信息 1. 人类从“写代码”转向“设计系统” 文章里最关键的一句话可以概括为：人类掌舵，智能体执行。 工程师的主要职责不再是亲手补实现，而是： 把目标拆成智能体能完成的任务 提供足够清晰的上下文和约束 设计反馈回路，让智能体自己发现问题并修复 当智能体做不好一件事时，重点不是“再提示一次”，而是追问：是不是缺工具、缺文档、缺规则、缺可观察性。 2. AGENTS.md 应该是地图，不该是百科全书 他们早期试过写一个超大的 AGENTS.md，结果失败了。原因很直接： 上下文窗口是稀缺资源 规则太多以后，模型会丢失重点 大而全的说明很快就会过期 单文件很难机械检查和持续维护 所以更好的做法是： 用简短的 AGENTS.md 充当导航地图 把真正的知识沉淀到结构化的 docs/ 中 给设计文档、执行计划、产品规格、架构说明和质量评分做索引 这本质上是在做渐进式披露：先给入口，再按需深入，而不是一次性把所有东西塞给模型。 3. 代码仓库要成为唯一可信的记录系统 对智能体来说，拿不到上下文就等于不存在。 所以那些只存在于聊天记录、口头讨论、Google Docs 或人脑里的决策，实际上都无法被智能体可靠地复用。文章强调，应该把越来越多的重要上下文沉淀回仓库，包括： 架构原则 产品约束 设计决策 执行计划 技术债状态 代码质量标准 这样智能体才能基于版本化的、可检索的材料持续工作。 4. 不只是代码要可读，应用本身也要对智能体可读 他们做了很多“让智能体自己看得见系统状态”的建设，比如： 支持基于 git worktree 启动独立应用实例 把浏览器调试能力接入智能体运行时 提供 DOM 快照、截图、导航等能力 把日志、指标、链路追踪也暴露给智能体查询 这样智能体就不只是“改代码”，还可以： ...