从 Agent 到 Harness：AI 进入研发流程，真正缺的是什么？

引言：会写代码，和能交付软件，是两回事

过去三年，研发团队讨论 AI 的方式变了三次。

最早问的是：“它能不能补全代码？”后来变成：“它能不能独立修 Bug、写测试、提 Pull Request？”到了 2026 年，真正值得问的问题已经是：

当 AI 能持续干活时，我们有没有能力让它稳定地做对、及时发现做错，并且不给生产环境添乱？

这就是从 Agent 走向 Harness 的分水岭。

Agent 可以理解为“会干活的 AI”。它能读文件、改代码、执行命令、跑测试、提交 PR。Harness 则是围在它外面的整套工作系统，包括任务说明、项目知识、工具权限、运行沙箱、测试门禁、审批规则、过程记录和失败后的改进机制。

说得直白一点：Agent 像一个执行力很强、速度很快，但不了解公司历史，也不用为事故背锅的新同事；Harness 就是让这位同事能够安全工作的组织环境。

真正稀缺的已经不是“再换一个更聪明的模型”，而是把模糊的人类经验，变成机器看得懂、执行得了、验证得出的研发系统。

一、现状：AI 已经进入研发主流程，但收益远没有想象中整齐

AI 编程早已不是少数人的尝鲜。

Google 的 2025 年 DORA 调研覆盖近 5000 名技术从业者，其中约 90% 已在工作中使用 AI，使用时长中位数约为每天两小时；超过 80% 的受访者认为个人生产力有所提升，59% 认为代码质量有所改善。但同一份报告也发现，AI 对交付吞吐量有正向作用，对交付稳定性却仍有负面影响。DORA 的结论很克制：AI 更像放大器，成熟团队被放大的是能力，混乱团队被放大的是混乱。（DORA 2025）

Stack Overflow 对 4.9 万多名开发者的调查呈现了类似矛盾：84% 已经使用或计划使用 AI 工具，约 51% 的职业开发者每天使用；但对结果准确性持不信任态度的人达到 46%，信任者只有约 33%。在 Agent 用户中，69% 认为个人生产力提高了，但只有17%认为团队协作得到改善。（Stack Overflow 2025）

这两个数字放在一起很有意思：个人觉得更快，不等于团队真的交付得更快。

Faros AI 对 1,255 个团队、超过 1 万名开发者的遥测分析发现，高 AI 使用团队完成的任务多了 21%，合并的 PR 多了 98%，但 PR 审查时间增加了 91%，平均 PR 规模增加了 154%，每名开发者对应的 Bug 数增加了 9%，最终在公司层面没有观察到显著的整体绩效提升。（Faros AI 2025）

其 2026 年后续报告扩大到 2.2 万名开发者、4000 个团队，继续观察到 PR 变大、审查变慢、返工和事故增加。不过这类数据属于观察性研究，只能说明现象同时发生，不能简单证明 AI 是唯一原因。（Faros AI 2026）

所以，AI 编程的真实状态不是“有效”或“无效”二选一，而是：

写代码的局部效率已经明显提高，但需求澄清、验证、评审、集成和发布没有同步提速，瓶颈只是向后移动了。

二、为什么各种生产力数据互相打架？

GitHub 早期的受控实验中，开发者使用 Copilot 完成一个明确的 JavaScript HTTP 服务任务，速度提高了 55.8%。这个结论是真的，但测试的是边界清晰、从零实现的小任务。（Microsoft Research）

在 Accenture 的企业实验中，使用 Copilot 的开发者人均 PR 数增加 8.69%，PR 合并率提高 15%，成功构建数增加 84%。不过该研究由 GitHub 与 Accenture共同开展，而且 PR、构建次数只是交付价值的替代指标，并不等于客户价值。（GitHub 与 Accenture）

另一边，METR 在 2025 年让16名资深开源开发者处理自己熟悉的大型项目，共记录246项真实任务，结果使用 AI 后平均慢了19%。更值得注意的是，开发者事前预计会快24%，事后仍觉得自己快了20%。（METR 2025）

但这也不能被解读成“AI 让开发者变慢”的永久结论。METR 在2026年续测57名开发者、143个仓库和800多个任务时，发现越来越多参与者不愿接“禁止使用 AI”的任务，30%至50%的人会主动避开那些不用 AI 很痛苦的工作，多 Agent 并行也让工时难以准确计算。因此研究方明确表示，新结果存在严重选择偏差，旧实验已不足以代表当前工具效果。（METR 2026）

这些研究并不真正冲突。它们只是测了不同的东西：

• 需求明确、容易验收的新项目，AI 往往很快。
• 熟悉的复杂旧系统，解释上下文和修正错误可能抵消收益。
• 个人编码速度可能上升，团队评审和发布速度却可能下降。
• 开发者的主观感受、代码产量和业务结果，是三套不同指标。

三、核心问题：研发真正缺的不是 Agent，而是四种确定性

1. 缺少“要做什么”的确定性

不少团队给 Agent 的输入仍是一句聊天记录：“把权限逻辑优化一下”“照这个页面做一个”“顺手补下测试”。

人类工程师会从会议、历史事故、同事经验和业务常识中补全缺失信息，Agent 不会。它只能把猜测包装成看起来合理的代码。

2026 年 Anthropic 对约 40 万次 Claude Code 会话的分析显示，人类平均承担约70%的规划决策，Agent 承担约80%的执行决策；用户的领域经验越强，Agent 每条指令能完成的工作越多，成功率也越高。（Anthropic 2026）

这说明人的价值没有消失，只是从“怎么写”转向了“为什么做、做到什么程度、什么不能碰”。

2. 缺少项目上下文的确定性

代码只是系统的一部分。真正决定改法的内容，往往藏在架构决策、接口约定、线上事故、灰度规则、聊天记录和少数资深员工脑子里。

很多团队所谓的“给 AI 上下文”，只是把更多文件一股脑塞进窗口。结果不是更聪明，而是信息过载、规则冲突和过期文档混在一起。

OpenAI 在内部 Harness 实验中得到的经验是：给 Agent 的应该是“地图”，不是一本1000页的说明书。他们把约100行的 AGENTS.md 作为目录，再链接到架构、产品规格、安全、可靠性和执行计划等版本化文档，同时用 CI 检查文档是否过期。（OpenAI Harness Engineering）

关键不在上下文有多少，而在于它是否准确、可发现、可追溯。

3. 缺少“怎样证明做对了”的确定性

AI 最危险的输出不是明显报错，而是“看起来没问题”。

Sonar 在2026年调查了1100多名职业开发者：96%的人并不完全信任 AI 代码，但只有48%会在提交前始终检查；38%认为审查 AI 代码比审查同事代码更费力，61%遇到过“看起来正确，实际不可靠”的代码。（Sonar 2026）

“安排一个人看一眼”并不等于可靠的人机协作。2026 年一项基于真实 GitHub 数据的研究发现，在样本中的33,596个 Agent PR 里，61.38%没有任何审查；有审查的 PR 中，58.77%只有其他自动化 Agent 参与。（EASE 2026 研究）

因此，验证不能主要依赖人的耐心，而要尽可能变成自动证据：类型检查、单元测试、契约测试、架构规则、安全扫描、界面截图、性能对比、运行日志和可回滚部署。

4. 缺少权限边界的确定性

补全工具只输出文本，Agent 却可能读取仓库、执行命令、访问网络、修改配置，甚至触发外部系统。它已经不是编辑器插件，而是供应链里的一个执行主体。

GitHub 的安全研究表明，恶意内容可以藏在 Issue、PR 或网页中，诱导 Agent 读取本地文件、泄露令牌或执行命令。GitHub 因此为 Copilot Coding Agent 加入了分支限制、网络限制、人工合并、会话审计和敏感信息扫描等防护。（GitHub Security）

权限设计必须按最坏情况考虑：不是假设 Agent 会不会犯错，而是假设它迟早会读到一条恶意或误导性指令。

四、几个最常见的认知误区

误区一：买了许可证，就完成了 AI 转型。
许可证解决的是工具可用性，不解决知识缺失、代码库混乱、测试薄弱和审批低效。

误区二：排行榜高，就能处理我们的生产项目。
2026年2月，OpenAI 因测试缺陷和训练数据污染停止使用 SWE-bench Verified；7月又发现 SWE-bench Pro 约30%的任务存在问题，并撤回此前的推荐。公共榜单可以看趋势，不能代替内部真实任务测试。（OpenAI 2月审计、7月审计）

误区三：代码写得更快，产品就能更快上线。
真正的交付周期还包括需求等待、环境准备、代码审查、测试、发布和故障恢复。只加速其中一段，工作只会堆到下一站。

误区四：Human in the loop 就天然安全。
如果一次生成几千行代码，再让一个疲惫的工程师点批准，这个人只是按钮，不是控制机制。

误区五：多开几个 Agent 就会线性提效。
没有任务边界、文件隔离和统一验收标准时，多 Agent 只会并行地产生冲突、重复修改和更多审查工作。

误区六：AI 会降低对资深工程师的需要。
现实更可能相反：实现成本下降后，需求判断、系统边界、风险识别和验收能力变得更值钱。真正危险的是减少初级岗位后，又没有设计新的培养路径，最终失去下一代能够监督 Agent 的资深工程师。

五、真实案例告诉我们：领先企业赢在底座，不只赢在模型

OpenAI 用三名工程师在五个月内推动 Codex 生成约100万行代码、合并约1500个 PR，自称耗时约为手写的十分之一。但这个项目从空仓库开始，并专门建设了文档索引、结构化架构、独立工作区、浏览器验证、日志指标、自动审查和持续清理机制。OpenAI 自己也明确提醒：没有同等投入，不能假设结果可以复制。

Spotify 的案例更有代表性。2026年，超过99%的工程师每周使用 AI，94%自报生产力提高，PR 频率增长76%。但 Spotify 在 Agent 出现前已经建设了 Backstage、统一技术栈、组件目录、Fleetshift 和自动化迁移能力，累计合并超过250万个自动维护 PR。其后台 Agent Honk 运行在隔离的 Kubernetes 环境中，只能调用受信工具，并通过多操作系统 CI 验证改动。最近一次 Java 迁移由一名工程师在三天内完成，而过去需要数百个团队投入数周甚至数月。（Spotify Engineering）

Rakuten 报告称，新功能平均上市周期从24个工作日降到5天；一次针对大型开源项目的复杂重构由 Agent 连续运行7小时完成，数值结果达到99.9%的参考精度。不过这是 Anthropic 发布的客户案例，属于厂商与客户联合口径，适合证明“在特定环境中可行”，不宜直接推算行业平均收益。（Rakuten 案例）

这些案例的共同点不是用了同一个模型，而是具备相似条件：任务范围清楚、系统结构统一、工具受控、反馈及时、结果能被验证。

六、解决方案：用90天搭出最小可用 Harness

第一阶段，先测基线，不急着扩席位。
选择20至50个真实任务，按文档、测试、简单修复、跨模块改动和高风险业务逻辑分类。记录从接单到上线的时间、人工投入、审查轮次、返工率、事故率和模型成本。没有基线，所谓“提效”只能靠感觉。

第二阶段，把项目知识变成可执行地图。
建立简短入口文件，指向架构说明、关键业务规则、测试命令、目录职责、接口契约和常见故障。每份规则要有负责人和更新时间。能由类型、Lint 或结构测试表达的规则，不要只写在文档里。

第三阶段，建立风险分级。
文档、测试补充、机械迁移可低风险自动执行；普通业务逻辑必须人工评审；鉴权、支付、数据库变更、生产配置和密钥操作应限制权限并要求多人审批。自主程度应由错误代价决定，而不是由模型能力决定。

第四阶段，把验证放进 Agent 的工作循环。
要求它先说明验收方式，再修改代码；每次退出前必须运行格式检查、类型检查和相关测试。测试失败就继续修，无法验证就明确退出，不允许用“看起来正确”代替证据。

第五阶段，控制改动批次。
限制单次任务涉及的模块、文件数和变更规模。大需求先拆成可独立验收的小 PR。DORA 的 AI 能力模型同样把小批次、强版本控制、内部平台和可访问的内部知识列为关键能力。（DORA AI Capabilities Model）

第六阶段，把权限和运行环境隔离。
默认使用临时沙箱、短期凭证、网络白名单和独立分支。读取权限与写入权限分开；提交、合并、部署、数据库操作分别授权；所有命令、工具调用、输入来源和审批过程必须留痕。

第七阶段，用失败反过来改 Harness。
不要只重新提示一次。每次重复错误都要归因：缺文档，就补知识；找错文件，就补代码地图；越界修改，就加结构规则；测试漏检，就补验收用例；权限过大，就收紧工具。LangChain 在保持同一模型不变的情况下，仅调整提示、工具和验证循环，就把 Terminal Bench 2.0 得分从52.8%提高到66.5%，说明外部工作系统本身就是能力的一部分。（LangChain 2026）

七、该看哪些指标？

不要把代码行数、调用次数或 PR 数当成核心成果。更有意义的是：

• 从需求就绪到生产可用的总周期；
• AI 产出中无需重大返工即可接受的比例；
• 首次验证通过率与平均修正轮次；
• 人工审查时间，以及其中资深工程师的投入；
• 合并后7天、30天的回滚、热修和代码重写比例；
• 每个成功交付任务的模型、计算和人工总成本；
• 线上缺陷、安全问题和稳定性变化；
• 团队是否交付了更多真实用户价值，而不只是更多代码。

最重要的指标可以浓缩成一句话：AI 省下的人类时间，是否大于它制造的验证、返工和事故成本。

未来展望：研发竞争将从“模型竞赛”转向“系统竞赛”

2026年8月19日，OpenAI 将 Codex 的 Harness 独立开放，明确把上下文管理、工具调用、沙箱、审批、过程状态和跨轮次执行视为可复用基础设施。这是一个很强的行业信号：Agent 的竞争边界正在从模型本身外移到完整工作系统。（OpenAI，2026-08-19）

接下来更可能发生三件事。

第一，模型会越来越像可替换的发动机。企业真正积累的资产将是内部任务集、验收标准、知识地图、工具接口、权限体系和失败数据。

第二，代码编写会逐渐退出主要瓶颈。真正稀缺的将是高质量需求、用户判断、架构约束、验证能力和决策速度。

第三，“完全自动研发”短期内不会成为主流，“有条件的自主执行”会先普及。低风险、可验证、易回滚的工作高度自动化；高风险工作由 Agent 调研和实施，人类负责目标、取舍与最终授权。

所以，从 Agent 到 Harness，并不是又多了一个时髦名词。它代表研发思路的一次转向：

过去，我们努力让 AI 写出更多代码；现在，我们需要建设一个系统，让它只在正确的范围内工作，持续拿到真实反馈，并用可以审计的证据证明结果。

AI 进入研发流程真正缺的，不是一个更勤快的“数字程序员”，而是一套能够承载速度、约束风险、积累组织知识的工程控制系统。谁先把这套系统建起来，谁才能把模型能力真正变成交付能力。