QUOTE
可靠性来自一整套可以检查的工程系统。
— Harness Engineering 主视觉
过去两年，AI 编程最常见的讨论几乎都围着模型转。
哪个模型写代码更强，哪个模型上下文更长，哪个模型一次能改更多文件。每次新模型发布，开发者都要重新跑一轮测试，普通用户也会跟着更新自己的工具清单。
可当模型越来越强，一个更现实的问题开始冒出来。
AI 写出的代码，谁来判断能不能用？它改坏了项目，谁能及时发现？它拿到了不该碰的文件，谁能拦住？如果每一步都要人守在屏幕前检查，所谓自动编程，不过是把敲键盘换成了盯进度。
今年 2 月，OpenAI 公布了一次很有意思的内部实验。一个工程团队用了五个月，从空仓库开始搭建产品，最后交付了一个拥有内部日常用户和外部测试者的软件。应用逻辑、测试、持续集成配置、文档、监控和内部工具，全由 Codex 生成。团队估计，整个项目只用了传统手写方式约十分之一的时间。
0
人工手写代码行数
1／10
团队估算所用时间
这件事最容易被记住的是一句话，零行人工手写代码。
我更在意另一件事。人类工程师并没有退出项目。他们把大量时间用在设计环境、描述目标、建立反馈循环，以及制定代码必须遵守的规则上。AI 负责执行，人负责让执行可以被检查、被纠正、被停止。
这套工作正在被越来越多人称为 Harness Engineering。
本文看点
01
Harness 是什么
02
可靠系统三要素
03
普通人如何应用
01
CONCEPT
### Harness 到底是什么
Harness 原本可以理解为马具，也可以指把一个强大系统约束、连接起来的装置。放到 AI Agent 里，它指围绕模型搭建的确定性环境。
模型负责理解任务、做判断和生成内容。Harness 管理它可以看什么、能调用什么工具、在哪个范围内行动、怎样保存状态、出错后如何得到反馈，以及达到什么标准才算完成。
在普通聊天窗口里，人经常亲自承担这些工作。AI 给出一段代码，你复制到编辑器里运行。程序报错，你再把报错贴回对话框。AI 修改以后，你重新运行。如果它连续几次修不好，你决定停下来换个办法。
「整个过程中，你就是那个 Harness。」
当任务只有十分钟，这样做没有什么问题。任务持续几个小时，需要访问真实项目、调用多个工具，或者同时处理几十个事项时，人肉接力很快就会成为最慢的一环。
软件化的 Harness 接过这些动作。它让 Agent 在限定环境里工作，自动运行测试，把错误日志送回去，允许 Agent 继续修改。测试通过，任务结束。重试次数超过上限，系统停止执行并通知人类。
Agent 因此获得了更长时间的自主工作能力。人也不用陪它来回复制报错信息。
02
SYSTEM
### 一个好 Harness 至少要解决三件事
第一件事是边界
能力越强的 Agent，越需要清楚的权限范围。它可以读哪些目录，可以写哪些文件，能否访问网络，能否接触生产数据库，都应该由系统直接限制。只在提示词里写一句“请小心”，约束力很弱。沙箱和权限策略才能在 Agent 判断失误时拦住它。
Google 的 Agent Development Kit 文档也把沙箱化执行列为代码 Agent 的重要能力。生成的代码在隔离环境中运行，代码和数据还可以跨多次请求保留。这让多轮调试成为可能，也降低了错误影响真实系统的风险。
第二件事是反馈
Agent 生成代码以后，系统要给出可验证的结果。单元测试、类型检查、代码规范、安全扫描和性能指标都可以成为反馈来源。失败信息越清楚，Agent 下一次修改越有方向。
反馈还要进入循环。执行一次、检查一次、把结果送回去、再次执行。Google AI 那篇介绍 Harness Engineering 的文章展示了一个简单流程。Agent 写完代码后进入测试节点。测试失败，错误信息返回 Agent。测试通过，流程结束。系统还设置了最大迭代次数，防止 Agent 在错误里反复打转。
— Agent 执行、检查、反馈与修复循环
第三件事是可理解的上下文
很多人使用 AI 的第一反应，是写一份越来越长的说明书，把所有规则一次塞进去。OpenAI 团队试过这种方式。他们发现巨大的指令文件会占据上下文，规则也很容易过时。最后，他们把简短的 AGENTS.md 当作目录，再让 Agent 按需读取架构文档、设计记录和执行计划。
这个经验很重要。Agent 需要一张能够逐步展开的地图。项目的知识如果散落在聊天记录、在线文档和某位老员工脑中，运行中的 Agent 就很难找到。知识被整理成可访问、可追踪版本的文件以后，它才能据此行动。
03
COMPETITION
### 为什么换模型已经不够了
更强的模型当然有价值。它能理解更复杂的任务，也能减少一些低级错误。但软件开发的结果从来不只取决于某一次生成。
同一个模型放进两个项目，表现可能相差很远。一个项目结构混乱，文档过时，没有自动测试，权限也没有边界。另一个项目目录清楚，规则可以被机器检查，每次修改都会触发测试，失败后还有完整日志。
前一个项目只能期待 AI 每次都猜对。后一个项目允许 AI 犯错，也有办法及时发现和修正。
「这就是 Harness 带来的差距。」
它并不要求模型永远正确。它承认模型会犯错，随后把发现错误和处理错误的过程做进系统。可靠性由许多可以检查的小环节共同提供。
对团队来说，这也会改变工程师的工作。过去，很多时间花在亲自完成代码实现。Agent 接走一部分执行工作以后，人要把需求写得更清楚，定义什么结果可以验收，整理项目知识，并把经验变成测试和规则。
代码能力依然重要。只有理解系统的人，才知道哪些边界必须守住，哪种测试能证明结果，哪处失败可能伤到用户。只是代码不再是工程师唯一的产出。
一个清晰的任务、一条可执行的约束、一个能抓住真实问题的测试，都可能比亲手补上几十行代码更有价值。
04
APPLICATION
### 这和普通人有什么关系
Harness Engineering 最早在 AI 编程领域受到重视，它不会只留在程序员的工作里。
今天很多人已经在搭建自己的 AI 工作流。有人让 AI 搜集资料、写公众号文章、检查事实、生成配图，再发布到不同平台。有人让 AI 整理客户线索、写跟进邮件、更新表格。
流程一长，同样的问题就会出现。
AI 能访问哪些资料？引用的事实怎样核对？生成内容达不到标准时，谁负责退回？连续失败几次以后要不要停？发布之前是否需要人确认？
「这些问题都属于 Harness。」
拿公众号写作举例。只给 AI 一句“写一篇文章”，得到的质量很不稳定。如果系统同时提供可靠材料、读者定位、语言规则和事实检查，并在成稿后检查标题长度、引用链接、敏感表达与作者署名，结果会稳定得多。
检查失败以后，文章自动退回修改。达到标准以后，再交给人做最后确认。
这时，你拥有的已经不只是一个会写字的模型。你开始拥有一套能够重复交付的内容生产流程。
一人公司尤其应该关注这件事。大公司可以靠岗位分工和层层审核控制质量。一个人带着多个 Agent 工作，没有那么多人可以兜底。权限、资料、验收和停止条件如果没有提前设计好，Agent 越多，混乱也会越快。
未来一段时间，我们仍然会看到更强的模型。模型榜单也会继续刷新。但当基础能力逐渐普及，真正难复制的部分会转向模型周围的系统。
谁能把业务经验写成清楚的规则，谁能让结果自动接受检查，谁能给 Agent 足够的行动空间又守住风险边界，谁就更有机会把 AI 从偶尔好用的助手，变成长期稳定的生产能力。
AI 编程的下一段竞争，已经从提示框外面开始了。
05
REFERENCES
### 参考资料
Google AI
Harness Engineering 介绍
OpenAI
Harness Engineering 实验记录
Google ADK
沙箱代码执行文档
END
我是星阙运营小助手，星阙是一个专注于 OPC（一人公司／超级个体）的投资与孵化平台。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。