![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/3c5fc673fc0e221572ac28e604a300df.png)


## 摘要
OpenAI发布的Harness Engineering文章记录了一种agent-first研发实验：团队让Codex承担代码、测试、CI、文档和内部工具的实现，人负责设计环境、明确意图并建立反馈环。本文核对公开数字的性质，分析这对测试角色的启发、不能推出的结论和团队可落地的试验方式。

一个研发任务交给Agent后，代码很快出现，单测也跟着生成，CI还显示通过。此时测试工程师真正要回答的，可能已经不是“它有没有写测试”，而是“测试覆盖的风险是不是由一个独立标准定义的”。当同一个Agent既写实现、又写测试、再按自己生成的标准解释结果，速度的确可能提升，质量判断也可能在无意中失去独立性。

OpenAI发布的《Harness engineering: leveraging Codex in an agent-first world》分享了一项公开工程实验。文章称，一个由Agent承担代码、测试、CI配置、文档、可观测性和内部工具实现的团队，先从空仓库起步，约五个月后代码规模达到约百万行；期间约1500个PR被打开并合并，最初由三名工程师驱动Codex，后来团队扩展到七人。文章还写明，“约为手写所需时间的十分之一”是团队估算，不是独立对照实验或通用生产效率保证。这里的数字是OpenAI对自身实验的公开描述，不能直接外推到任何公司的交付速度。

这个案例适合测试工程师关注，因为它把问题从“AI能不能补全代码”推到了“研发团队主要工作是否会转向环境、规格、反馈和治理”。本文将围绕四件事展开：公开文章真正披露了什么；哪些流行解读超出了证据；当Agent负责实现和自测时，独立质量判断怎么保留；小团队怎样做一轮可回滚的试验。核心判断是：代码生产比例可以变化，但系统的验收权、风险边界和责任归属不能因为产出速度上升而变模糊。

### 从“人写代码”到“人设计工作环境”

过去的软件工程任务大致围绕需求、设计、编码、测试和发布展开。代码是最可见的工作产物，测试往往在代码形成后检查行为是否符合需求。Agent-first流程把一部分实现交给模型，人的时间开始更多花在组织仓库知识、说明约束、构造工具、配置反馈机制和决定何时停止。OpenAI文章用“Humans steer. Agents execute.”概括其经验，但这个口号是团队对自身实践的总结，不应被理解成所有工程师都已退出编码。

如果把研发活动拆成五个部分，可以看到变化并非简单的“人少做、AI多做”。

| 工作部分 | Agent可承担的工作 | 人仍要负责的判断 | 质量证据 |
|---|---|---|---|
| 目标定义 | 将任务转成计划与改动清单 | 目标是否正确、边界是否遗漏 | 需求与验收条件 |
| 实现 | 生成代码与配置 | 设计是否符合业务和系统约束 | 差异审查、架构检查 |
| 自测 | 生成并运行测试 | 测试是否独立覆盖失败风险 | 反例、变异测试、人工样本 |
| 集成 | 调用CI、修复失败 | 是否允许重试、合并或部署 | 运行记录、状态、权限日志 |
| 运营 | 生成文档和监控工具 | 事故责任、回滚与用户影响 | 可观测性、审计、回滚验证 |

这张表是本文的岗位分析框架，不是OpenAI公开团队的角色表。它表达的重点是：Agent接手某些操作后，人类工作会向“定义目标、选择证据、批准风险”迁移，而不是工作消失。


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/af03201ae851d7b4986c0122456308ee.png)



### 这份公开材料能证明什么，不能证明什么

能核验的事实包括：OpenAI公布了一个Agent承担多类工程产物的实验；文章给出时间、PR、代码规模和团队人数等自报信息；团队强调仓库结构、测试、CI、文档、可观测性和内部工具共同构成工作环境。文章还展示了他们如何把约束写进代码库、用自动化检查保护结构，并在开发中持续修复问题。

不能从中直接推出：所有团队都能以相同比例提速；百万行代码天然代表产品质量；小团队不再需要测试；人类审查可以完全去掉；或Agent生成的测试已经独立证明了实现正确。尤其“十分之一时间”是团队自己的估计，比较对象和工作量边界依赖原文口径，不能在标题里包装成客观行业基准。百万行和1500个PR也只是规模信号，不是用户价值或缺陷率指标。

因此更值得分析的是机制。Agent能够连续工作，依赖的不是单个模型，而是仓库上下文、可调用工具、任务约束、自动反馈和人类判断组成的Harness。提示词不足时，Agent可能做出看似合理但与系统约定冲突的改动；工具权限过大时，错误可能被执行；反馈不完整时，测试通过也不能排除关键路径没有被覆盖。所谓生产力变化，来自任务拆解、信息准备、并行执行和快速反馈共同作用。

### 最容易被忽略的反常识：Agent越会自测，越要检查谁定义了“通过”

一条最简单的风险链是：Agent看到需求，写实现；同一Agent根据需求写单测；它运行单测并修改实现直到通过；最后再生成测试报告。如果测试只覆盖Agent已经理解到的需求，它可能把同一个误解同时写进实现与测试。结果是“测试通过”只说明二者相互一致，不说明业务目标被正确理解。

这与传统开发里开发者写测试并非完全不同，但Agent的生成速度会让同源偏差更快扩大：需求遗漏可以被复制到多个文件，假设不清会被传播到mock、断言、文档和验收说明中。因此“代码通过测试”需要回答：测试断言来自哪里？是否有独立的业务规则来源？是否保留了能够击中错误实现的反例？数据与环境是否真实？关键断言是否能在实现发生错误时失败？

#### 一份独立质量证据清单

- **需求证据**：由产品规则、监管要求或业务负责人确认的约束，不由Agent自行补全后当成事实。
- **测试证据**：至少有一部分样本由不同角色或不同机制制定；对高风险条件加入边界值、反例和状态迁移。
- **运行证据**：保留具体提交、环境、测试版本、工具调用、失败信息和重试次数。
- **结果证据**：检查业务状态和外部副作用，不以进程退出码或Agent自述替代。
- **责任证据**：标记哪些操作由模型建议、哪些由人批准、哪些由自动化执行，确保出现问题时能够回溯。

### 小团队怎么做一次低风险Agent-first试验

不必先把整个项目交给Agent。选一个边界清楚、可回滚、失败代价可控的任务，例如生成一个只读API的测试适配层，或为已有CLI补一组文档和测试。先明确试验不是“看模型能不能写代码”，而是比较工作流：哪些步骤交给Agent后能减少等待，哪些步骤仍需要工程师判断，哪些新错误是由权限、上下文或反馈不足导致。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/a78fbb5e5d23ce043e1032a332293dfb.png)



**试验准备**：给Agent只读仓库、创建分支、运行测试的权限；将生产密钥、生产写权限和部署凭证隔离。仓库里放清晰的目录说明、测试命令、编码约定和“不允许改变的业务不变量”。任务开始前由工程师写出可观察的验收条件和至少一个负例。

**执行过程**：Agent每次改动应关联任务目标和验证结果。限制并行工作范围，避免两个Agent同时修改同一核心文件。出现失败时，先保留首次失败的输出，再让Agent修复，防止最终通过结果掩盖中间发生过的破坏。测试人员不需要逐行复述所有代码，但要能追问改动影响了哪些状态、外部调用和异常路径。

**验收对照**：不只看平均耗时。记录人类审查时间、无效改动、遗漏的业务条件、测试有效性、回滚难度、Agent重试次数和新增工具风险。速度变快但审查负担翻倍，可能只是把瓶颈从编码转移到了验收；生成了更多测试但反例变少，也不等于覆盖更好。

| 观察项 | 需要保留的证据 | 怎样解读 |
|---|---|---|
| 交付速度 | 从任务开始到满足验收条件的用时 | 同时记录等待、返工和人工审查时间 |
| 测试独立性 | 需求来源、断言来源、负例来源 | 若都来自同一Agent，不能当作独立验证 |
| 变更风险 | 无效改动、越权动作、重试和回滚记录 | 速度提升不能抵消高后果副作用 |
| 结果可信度 | 业务状态、CI记录、Trace与人工复核 | 说明“为什么通过”，而非只报通过率 |

这张表是本文建议的试验记录模板，不是OpenAI公布的内部指标。把每个判断对应到一条证据，试验复盘才有机会区分真正提效与把工作量转移到验收端。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/cb26a54a9a4cb6b45429302aae955b37.png)



**结束条件**：出现未授权写操作、无法解释的测试删除、测试仅通过修改断言实现、关键状态不可观测、重复副作用无法控制时，立即停止并回滚。试验成果可以是失败模式清单，不必强行宣布Agent-first成功。

### 角色变化不是“少写代码”，而是把边界和证据设计清楚

OpenAI原文没有提出一个新的职称。它提供的是一次特定团队实践：随着Agent承担更多实现工作，工程师把更多精力放在设计环境、拆分目标、设定可执行约束和构建反馈机制。对测试工程师而言，可迁移的变化不是换一个头衔，而是更早参与验收标准、独立证据和风险边界的设计。

这里也有反方边界。Agent持续依赖模型能力、上下文窗口、工具生态、权限治理和组织流程；对于复杂需求、隐性业务规则、物理设备、法规责任等场景，人类判断仍然关键。某个内部项目的效率数据不等同于外部团队可复现结果。即便实现成本下降，产品方向错误、权限过宽、质量证据不足和运维责任缺位，造成的损失也不会自动变小。

未来6—18个月，测试团队可以观察几类可验证信号：Agent改动是否能稳定通过独立验收；跨仓库任务是否更少依赖人工补上下文；测试缺陷是否因同源生成而增多；审查时间是否随代码产量同步上升；工具调用是否具有可审计、可撤销和最小权限控制；生产问题是否能从Trace还原到具体动作。这些信号比“团队说效率提高了”更能说明研发方式是否真的改变。

### 测试工程师的具体行动

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/702dc166ef33433cc08f671934de9531.png)


先把你负责的一条业务流程写成四列：目标、允许动作、禁止动作、结果证据。再选一个Agent可以安全执行的子任务，让它在隔离环境里跑，记录每一步工具调用。最后，单独设计一条“实现和自测都可能一起错”的反例，用来检查验收是否独立。这个练习不要求先学会训练模型，却能让你看清Agent到底替代了什么、扩大了什么风险，以及团队还缺哪种质量证据。

OpenAI这篇文章值得测试工程师读，不是因为它证明所有公司都应照搬，而是因为它把研发工作的稀缺资源说得很具体：人的时间和注意力。当编码动作变得更容易，选择做什么、如何验证、何时停止反而变成更重要的工程判断。测试不一定消失，但只检查“功能有没有跑”可能不够；能定义验收边界并证明结果可信的人，会更接近研发决策的中心。

>本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。




OpenAI发布的Harness Engineering文章记录了一种agent-first研发实验：团队让Codex承担代码、测试、CI、文档和内部工具的实现，人负责设计环境、明确意图并建立反馈环。本文核对公开数字的性质，分析这对测试角色的启发、不能推出的结论和团队可落地的试验方式。

测开必看｜可落地实操：用独立验收和反例检查 AI 自测

人工智能

测试

职业发展

OpenAI实验显示Codex承担代码、测试、CI，5个月产出百万行代码。核心风险：同一Agent生成实现与测试，可能导致同源偏差。质量判断独立性比产出速度更重要，验收权、风险边界和责任归属不能模糊。测试工程师应转向定义验收标准、独立证据和风险边界，而非只关注代码产出。

软件工程

软件测试

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

测开必看｜可落地实操：用独立验收和反例检查 AI 自测-腾讯云开发者社区-腾讯云

测开必看｜可落地实操：用独立验收和反例检查 AI 自测

测开必看｜可落地实操：用独立验收和反例检查 AI 自测

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐