Harness 工程:在 Agent First 世界里发挥 Codex 的杠杆

Sun Mar 01 · 原文链接

2026 年 2 月 11 日

作者:Ryan Lopopolo(技术团队成员)

过去五个月,我们团队做了一个实验:构建并交付一个内部测试版软件产品,且人工手写代码为 0 行

这个产品有内部日活用户,也有外部 alpha 测试者。它会发布、部署、出故障、再被修复。不同之处在于:从业务逻辑、测试、CI 配置、文档、可观测性到内部工具,所有代码都由 Codex 生成。我们的估算是,和手写相比,这样的构建速度大约是 10 倍。

人类负责掌舵,Agent 负责执行。

我们刻意采用这个约束,因为我们想逼迫自己去构建真正能把工程效率提升几个数量级的系统能力。

我们从一个空 Git 仓库开始

第一次提交发生在 2025 年 8 月下旬。最初的脚手架——仓库结构、CI、格式规则、包管理、应用框架——由 Codex CLI(GPT‑5)在少量模板引导下生成。甚至最早用于指导 Agent 协作的 AGENTS.md,也是 Codex 写的。

仓库从一开始就没有人类既有代码作为锚点,它天然是由 Agent 形塑出来的。

五个月后,仓库规模达到百万行量级,覆盖应用逻辑、基础设施、工具、文档和开发辅助能力。期间用一个很小的人类团队驱动了约 1,500 个 PR。整个过程里,人类不直接写代码成为团队的核心哲学。

工程师角色被重新定义

当人类不再“亲手编码”,工程工作本质就转向了:系统设计、脚手架建设和杠杆最大化。

早期进展慢,不是因为 Codex 不行,而是环境定义不充分。于是人类团队的主业变成了:不断补齐 Agent 缺失的能力,让它能稳定推进真实目标。

实践上,这意味着把大目标拆成可执行的小块(设计、编码、评审、测试等),并在失败时追问:

缺的能力到底是什么?如何把它变成 Agent 可见且可强制执行的规则?

让应用“对 Agent 可读”

当代码吞吐上来后,瓶颈转为人类 QA 产能。团队通过提升“可读性”给 Agent 扩能:让 UI、日志、指标都能被 Codex 直接消费。

例如:

把仓库知识变成“唯一事实来源”

核心经验之一:给 Codex 地图,而不是 1000 页说明书。

超大单体 AGENTS.md 会失败:

因此,AGENTS.md 只保留导航能力,真正知识沉淀进结构化的 docs/ 体系。计划(plans)也作为一等工件纳入版本管理:小变更用轻量计划,复杂变更用可追踪执行计划。

目标是 Agent 可理解性(legibility)

在全 Agent 生成仓库里,第一优化目标不是“人类审美”,而是“Agent 可推理性”。

从 Agent 视角看,运行时上下文里不可见的信息就等于不存在:

都必须被编码进仓库中的版本化工件,才能形成可复用能力。

用约束守住架构与风格

仅有文档还不够,需要可执行的结构约束。

团队采用“约束边界、不微管实现”的策略:为业务域定义固定分层和依赖方向,用自定义 lint + 结构化测试进行强制校验。对 Agent 来说,这类约束不是负担,而是速度倍增器。

吞吐变化会重塑合并哲学

在 Agent 吞吐远高于人类注意力时,很多传统流程会变成阻力:

在这种环境里,“快速纠偏”比“等待完美”更经济。

“Agent 生成代码库”到底意味着什么

Agent 产出的不只是产品代码,还包括:

人类依然在环,但工作重心上移到更高抽象层:设定优先级、定义验收标准、做结果判断。

自主性持续提升

在当前体系中,单一提示就可驱动 Agent 完成从状态检查、复现问题、修复验证、提交 PR、响应反馈到合并的大闭环。

这不是模型“天然会”,而是仓库结构、工具链和反馈回路共同训练出来的系统能力。

熵增与“垃圾回收”

完全自治也会带来模式漂移。团队曾经每周花大量时间清理“AI slop”,后来改为把“黄金原则”编码成机械规则,并由后台任务周期性扫描偏差、自动发起小型重构 PR。

技术债像高息贷款:持续小额偿还,远优于长期积累后一次性爆雷。

仍在学习的部分

当前方法在内部落地与扩展上有效,但仍有关键未知:

已经明确的是:软件工程的“纪律性”没有消失,只是更多转移到了脚手架、工具、反馈回路与控制系统的设计上。