AI时代软件研发脚手架:Harness

2026年2月，OpenAI公开了一份内部工程报告，记录了一支3人小团队的实验：5个月里，他们写下了近一百万行生产代码，提交了大约1500个Pull Request，而人类工程师全程没有手写一行代码。所有代码都由AI Agent生成，代码审查也交给AI来完成。算下来，平均每人每天能合并3.5个PR，而且随着团队扩大，效率还在持续提升。

这套方法论被他们称为Harness Engineering，可以理解为“驾驭工程”——就像马具不是为了让马更强壮，而是让马的力量能被引导到正确的方向上。

这份报告在工程师圈子里引发了广泛讨论，因为它证明了一件事：让AI系统性地接管软件开发的全流程，不再是科幻，而是可操作的现实。

随之而来的问题，比答案本身更令人不安：这套东西，其他团队能复制吗？

OpenAI的这支团队拥有对Codex模型的直接访问权限，能够影响模型本身的能力走向，而且他们是从一个完全空白的仓库开始的，不需要面对任何遗留代码的牵绊。他们花了大量时间，搭建了一套极为精密的配套系统：严格分层的代码架构、由AI自动生成的代码检查工具、持续运行的“垃圾回收”机制来清理AI积累的技术债，还有一套完整的文档体系作为AI Agent的知识索引。每一个环节都是深度定制的，都建立在对模型本身的理解之上，都需要相当大的工程投入才能落地。对大多数团队来说，这套体系的复杂程度，几乎相当于在现有研发流程之外再搭建一套同等体量的平行系统，风险之大，足以让绝大多数工程负责人望而却步。

OpenAI的报告发布后，开源社区反应很快。各种号称实现了“Harness”理念的框架和工具在短时间内涌现出来：有的专注于管理Agent loop，有的侧重于上下文工程，有的提供代码质量的自动反馈，有的尝试搭建多Agent协作的脚手架。

但如果仔细看看这些项目，会发现它们都有一个共同的局限：它们只解决了某一个具体问题，而不是提供一套完整的方法论。用文档描述项目背景是一个点，通过完善Agent loop来修复问题而不是手动调整prompt是另一个点，设定测试驱动开发让AI自动验证代码质量又是另一个点。这些实践本身都没错，但它们彼此之间并没有串成一条可以落地执行的线，更谈不上覆盖整个研发周期。

迄今为止，还没有一个开源项目，能像OpenAI的内部实践那样，真正把这些环节串联成一个自洽的体系。

这个局面，和20多年前敏捷开发刚刚兴起时非常相似。

2001年前后，敏捷宣言发布，一批工程师和管理者开始意识到迭代交付、持续反馈、小团队协作的价值。大家知道这个方向是对的，但怎么真正落地，却是另一回事。当时的实践工具非常原始——物理看板、便利贴、每日站会——团队得自己摸索着把这些碎片拼成一套能跑起来的流程。而这个摸索过程本身，就需要相当丰富的经验以及组织变革能力，不是每个团队都能走得通。

今天，AI驱动的软件研发也面临着同样的处境。每个在这条路上走得比较靠前的团队，都形成了自己独特的实践，但这些实践都是特定团队在特定条件下摸索出来的，迁移成本极高，更谈不上对外输出。

敏捷之所以能从少数先驱的实践变成行业的普遍工作方式，很大程度上要归功于Jira的出现。Jira不是对敏捷理念的简单包装，而是把敏捷的核心实践——用户故事、冲刺周期、看板流动、缺陷追踪——直接编码进了一个所有人都能上手的工具里。不懂敏捷理论的人，照着Jira操作，也能慢慢建立起敏捷的工作节奏；懂敏捷的人，则能借助Jira在更大规模的组织里推行这套方法论。工具承载了方法，方法借助工具得以传播。

而AI驱动研发的“Jira时刻”，直到最近，才刚刚开始浮现。

2026年4月8日，Anthropic发布了Claude Managed Agents。这不是一个新的AI模型，也不是一个聊天界面的升级版，而是一套面向生产环境的Agent基础设施，自带一个针对性能调优的Agent Harness系统（orchestration harness）。

在此之前，想要把一个AI Agent推向生产，开发团队得自己解决沙箱隔离、状态持久化、权限管控、工具调用的错误恢复，以及跨会话的上下文管理等一系列工程问题。这些问题的解决，少则几周，多则几个月，而且每换一个场景，几乎都得从头再来。更麻烦的是，底层模型一旦升级，围绕旧模型调试出来的agent loop往往需要重新适配，之前积累的工程成果很可能付诸东流。

Claude Managed Agents把这些工程复杂度整体托管了。开发者只需要定义Agent的目标、可用工具和约束边界，剩下的交给平台：沙箱执行环境由平台负责安全隔离，长达数小时的自主运行会话在断线后仍能保持状态，工具调用的中间决策和失败模式都会通过Claude Console完整记录下来，可以一步步追溯。对于更复杂的任务，平台还支持多Agent协作，一个主Agent可以动态拆解任务并调度子Agent并行执行。

内部测试数据显示，在结构化文件生成这类任务上，Managed Agents相比标准的prompt loop，能将任务成功率提升最多十个百分点，而且这个增益在最难的问题上最为明显。这正是Harness设计哲学的体现：不是让AI变得更聪明，而是让AI在一个更好的环境里工作。

已经有一批团队借助这套平台，把原本需要数月的工程工作压缩到了几天。Sentry的工程团队将AI故障诊断Agent和代码修复Agent串联起来，让开发者从收到错误报告到看到可合并的PR，全程无需手动干预，整个集成从立项到上线只用了短短几周。Asana在构建其AI Teammates功能时，借助Managed Agents跳过了大量底层基础设施的搭建，把工程资源集中到了用户体验的打磨上。法律科技公司General Legal的CTO描述了一个更有代表性的场景：他们的Agent现在能够根据用户提出的任意问题，实时编写所需的查询工具并执行，而不需要工程师提前预判所有可能的提问并逐一开发对应功能。这种动态生成工具的能力，把他们的开发周期缩短了十倍。

这一切都指向同一件事：软件工程师的核心工作，正在从“写代码”慢慢迁移到“设计一个能让AI写好代码的环境”。这两件事表面相似，实则要求完全不同的技能。前者需要对语言、算法和系统实现的掌握，后者则需要理解反馈回路、约束设计、任务分解和质量度量。

这种迁移，在OpenAI内部团队的案例中已经有了清晰的记录。当AI Agent遇到困难时，工程师的第一反应不再是修改prompt，而是问：环境的哪个部分设计得不够好，导致Agent没法自己解决这个问题？Harness系统的完善，取代了手工调试，成了工程迭代的主要内容。

这条路仍然处在起步阶段。工具已经开始把方法论变得可触及，就像Jira让敏捷从理念变成了日常操作一样。Claude Managed Agents只是一个开始，它需要证明了这条路是否可行。后面要看实践的效果，持续迭代，看看此类软件中能否有脱颖而出的产品，真正成为AI软件研发时代的脚手架。

📖 相关阅读：Harness engineering：以智能体为中心的软件开发实践

❤️ 喜欢本文内容？欢迎点赞、转发。关注公众号，了解更多Vibe Coding资讯。