OpenAI 与软件仓库的新认知架构

Source: Dev.to

请提供您希望翻译的正文内容，我将按照要求保留源链接并进行简体中文翻译。

TL;DR

OpenAI 最新的 harness 工程报告显示，agentic 软件的真正瓶颈不再仅仅是模型，而是代码库本身。代码库必须从仅供人类维护的状态演变为语义可导航的计算环境，使得代理能够可靠地读取、解释和修正。

介绍

harness engineering 的概念已成为 AI 工程中的热门话题。公司们发现了一个简单的问题：一个代理在孤立执行时可能表现出色，但如果没有专为其设计的环境，代理很快会产生熵。正如早前文章 Harness Engineering: The Most Important Part of AI Agents 中讨论的那样，harness 是代理系统的关键层，这一基础设施在从原型转向生产时必须显著演进。

OpenAI 为这一难题增添了更重要的一环：我们需要为代理设计的首个对象可能不是模型本身，而是 repository。

OpenAI的 Agent‑First 仓库

在报告 “Harness engineering: leveraging Codex in an agent‑first world” 中，OpenAI 描述了一个内部 beta 项目，该项目约有一百万行代码，全部由 Codex 生成，零手工编写的代码行数，并且有超过 1,500 次 pull request 由一个非常小的团队处理。这个引人注目的数字令人印象深刻，但真正的信息却不同：

• 生产力的提升并不是因为 Codex 编写代码快。
• 生产力的提升是因为工程师不再把仓库视作简单的文件容器，而是把它当作可以被代理（agents）计算的环境。

换句话说，OpenAI 不仅在代码库中使用了编码代理，而是将代码库转变为代理能够读取、解释并可靠纠正的对象。

转化仓库的信号

OpenAI 确认至少有四个明确的信号表明仓库已被转变为对代理友好的环境：

1. 运营真相 – 仓库必须包含决定性的真相来源，包括：

   • 版本化的内部文档
   • 架构图谱
   • 决策历史
   • 类似 AGENTS.md 的文件，作为代理的语义入口点

   这不仅仅是“更多文档”；它使仓库成为 机器可查询的记忆，而不仅是供人类阅读的文本。

2. 确定性反馈回路 – 传统的 lint、格式化、边界检查、导入策略以及自动化验证不再只是秩序维护工具。它们形成反馈回路，持续教会代理哪些行为被允许、哪些不被允许。当代理出错时，CI 会阻止执行，返回带有原因的日志，任务随后再次迭代。质量控制因此成为执行时推理过程的一部分。

3. 可观测性作为认知表面 – OpenAI 在结构化日志、诊断追踪、可验证输出和检查工具上投入巨大。能够读取自身失败的代理可以自我调试，而盲目的代理只能盲目重新生成。可观测性因此从开发者仪表盘转变为 代理的认知接口。

4. 人类工作方式的转变 – 人类的努力从直接实现和手动修复转向：

   • 设计仓库结构
   • 定义架构边界
   • 构建反馈回路
   • 清理熵

   工程师编写的功能更少，而编写的可理解性条件更多。

超越提示的上游层

多年来，重点一直是改进：

• 提示
• 推理
• 工具使用

OpenAI 表明，在所有这些之上还有一个上游层：

• 一个 一般的代理 位于 可被代理读取的仓库 中仍然可以产生可用的工作。
• 一个 高度能力的代理 位于 不透明的仓库 中仍会产生熵。

因此，瓶颈不仅是模型本身，而是日益成为 环境的可计算性。

对工程的影响

OpenAI 在“驾驭工程”辩论中最引人注目的贡献是一个令人不安的事实：

代码仅仅能够被人类维护已不再足够；它必须能够被代理（agents）导航、验证，并且在语义上可读。

这彻底改变了工程工作的方式。我们不再仅仅设计应用程序——我们开始设计 能够被非确定性智能体所居住的代码库。