大家好，我是贾克斯。

这篇文章会稍微硬核一点。

但我会尽量写得让非研发同学也能看懂。

如果最近你关注 AI Coding ，应该会经常听到一个词。

Harness Agent 。

或者更完整一点，叫 Harness Engineering 。

这个词听起来很工程，很抽象。

但你可以先把它理解成一句话。

大模型很强，但它不能裸奔。

它像一匹跑得很快的马。

你不能只是拍拍它的屁股，然后说，兄弟，冲！

你得给它方向、边界、工具、反馈。

给它一个跑偏以后能被拉回来的机制。

这套东西，就是 Harness(哈尼斯)

它不是为了限制 AI ，而是为了让 AI 的能力变得更稳定、可控、可复用。

这套概念现在已经在 Claude Code 、Codex 、Qoder 这类 AI Coding Agent 里逐步落地。

类似 OpenAI 、Anthropic 这些团队，也都在讲同一件事：那就是：人类掌舵，智能体执行。

这句话听起来很帅，但问题是，很多人听完以后，还是不知道怎么落地。

今天，我们就把这个 Harness Coding 在企业场景中如何运用的具体实践给分享一下。

/什么是 Harness/

在此之前，请允许我先用一个真实的小案例，给大家讲清楚，到底什么是 Harness 。

如果这个概念前面不对齐，后续则无法深入到企业场景内的 Harness 实践，越到后面大家只会更加懵逼。

假设我们现在让 AI 去做一个媒体账号。

给它的前置系统提示词是：

“你的人设是宝妈，目标是涨粉，核心指标是每篇帖子的阅读量、互动量和关注转化。”

AI 收到这个提示词以后，就开始干活。

它很快发布了一篇帖子：

💬 “我家孩子 3 个月，但是不爱吃母乳怎么办？”

然后配了两张图。

到这里，AI 已经完成了两个动作：

前置，执行。

接下来进入第三步：

反馈。

帖子发出去 1 小时后，AI 去看数据，发现阅读量很低。

按照新账号起号的逻辑，一篇正常内容至少应该有上百阅读，但这篇只有几十。

于是 AI 开始复盘。

它发现，这篇内容太平了，没有足够强的吸引点。然后它把这个经验写进自己的经验库：“内容过于平淡，容易导致阅读量偏低。”

下一次发帖时，这条经验会重新进入它的前置说明里。

于是 AI 的新提示词就变成了：

“你的人设是宝妈，你的任务是发布帖子吸引用户关注和评论。你的核心指标是涨粉量和每篇帖子的阅读量。

历史经验：上一篇帖子因为内容过于平淡，阅读量很差。下次需要提高标题和内容的吸引力。”

然后 AI 又开始执行。

这次它发了一篇更夸张的：

💬 “天塌啦！我家孩子每天能吃一头牛怎么办！快养不起了，呜呜。”

这篇发出去以后，数据确实很好。

1 小时内有 1 万阅读。

但是问题来了。

1 小时后，帖子被封了。

原因是：传播夸大事实的信息。

这时候 AI 又开始复盘。它发现，夸张标题确实能带来流量，但如果夸大事实，就很容易被平台判违规。

于是经验库里又多了一条：

夸张表达可以提升点击，但不能脱离事实，否则容易被封。

现在，AI 的经验库里已经有两条经验：

第一，内容太平淡，没有流量。

第二，夸大事实虽然有流量，但容易违规。

于是第三次发帖时，AI 开始调整策略。

它不再写平淡内容，也不再硬夸张，而是换成真诚路线：

💬 “做辣妈的第三年，我是如何一边带娃，一边保持状态的？”

这篇内容戳中了很多宝妈的真实痛点。

结果，帖子爆了。

AI 看到数据以后，发现这条路线有效，于是继续把经验写回去：

真诚表达真实痛点，更容易获得稳定流量。

到这里，一个很小的运营闭环就出现了。

前置、执行、反馈、经验沉淀，再回到前置。

这就是 Harness 的核心。

它不是让 AI 单次完成一个任务，而是让 AI 在一个系统里持续变好。

当然，刚才这个例子只是为了方便理解，真实系统要复杂得多。

比如：

AI 拉到帖子数据以后，怎么判断这篇帖子是正常、偏差，还是爆了？

AI 复盘的时候，怎么对标同类账号，而不是只看自己的感觉？

AI 发现某个策略有效以后，怎么判断它是长期有效，还是只是碰巧踩中了流量？

这些问题，才是搭建 Harness 系统真正难的地方。

也就是说，Harness 的关键不只是“让 AI 干活”。

而是要给 AI 搭一套闭环：

任务怎么定义，过程怎么执行，结果怎么评估，经验怎么沉淀，下次怎么复用？

这才是 Harness 的核心。

/企业级 Harness 实战/

能看到这里的，想必已经对什么是 Harness 已经没有异议了。

那么接下来我们开始介绍本文的重点：企业级的 Harness Coding 实战应该怎么去做？

在真实的开发任务里，这个闭环会复杂很多。

因为写代码不是发一条帖子。

真实开发里有需求理解、架构边界、代码规范、接口契约、测试验证、日志排查、评审验收、多人协作。

任何一个环节没管住，AI 都可能开始偏航。

所以，如果我们想让 AI 真的参与企业级开发，不能只写一句：

“你是一个资深研发工程师，请帮我完成这个需求。”

这不叫 Harness 。

这叫把一个非确定性的模型，直接扔进生产代码里裸奔。

真正的 Harness Coding 系统，至少要回答几个问题：

1. AI 开始写代码前，它从哪里理解需求？

2. 它依据什么项目规则做判断？

3. 它能不能自己查架构规范，而不是反手问人？

4. 它写完以后，谁来验证？

5. 验证失败以后，怎么回到正确轨道？

6. 这次踩过的坑，下次怎么不再踩？

这才是 Harness 架构要解决的问题。

而对于 AI Coding 的场景，这套架构则最少要有如下三层：

1. 人类需求层。

2. 工程契约层。

3. 代码执行层。

/第一层，人类需求层/

这一层解决的是：人类到底想要什么。

很多 AI Coding 失败，不是模型写不出代码，而是一开始需求就没有被说清楚。

人类在聊天窗口里随口说一句“帮我加个 X 接口”，AI 就开始实现。它看起来很勤奋，实际上很危险。

因为它不知道这个接口的业务边界是什么，不知道哪些字段必须兼容旧系统，不知道异常场景怎么处理，也不知道验收标准是什么。

所以在我们的 Harness 里，第一步不是让 AI 写代码。

第一步是让人类先把需求落成一个可以被交接的文档。

这个文档不需要写得像论文，但必须说清楚几件事：

这个需求为什么要做。

这次到底做什么，不做什么。

输入输出是什么。

业务流程是什么。

验收标准是什么。

这一步非常关键。

因为 Harness 的第一条原则就是：

人类负责想清楚方向，AI 负责把方向翻译成工程动作。

如果人类自己都没想清楚，AI 只会把不确定性放大。

/第二层，工程契约层/

当人类需求写清楚以后，也不能马上进入代码实现。

中间还需要一层翻译。

因为人类需求通常是业务语言，而代码实现需要工程语言。

比如人类说：

新增一个校验能力，失败时要给前端异常提示。

这句话对业务方来说够了，但对工程实现来说还不够。

AI 需要继续把它翻译成：

改哪个模块、新增什么接口、错误码怎么定义。

测试要覆盖哪些场景、哪些架构规则不能破坏、做到什么程度才算完成。

这一层，就是工程契约层。

在这一层里，AI 可以起草设计方案、任务拆分、接口契约和验收标准，但人类必须 Review 。

注意，这里不是人类逐行写设计文档，而是人类把关：方向对不对、边界有没有漏、验收标准是否可验证。

这个阶段的核心产物，不是代码，而是一份“写代码前的工程合同”。

它告诉后面的实现 Agent：你要交付什么、不能越过什么边界、交付后用什么证据证明完成。

/第三层，代码执行层/

只有前两层都对齐以后，AI 才能进入代码实现。

这一层才是真正的 Coding Agent 干活区。

但即使到了这里，也不是让一个 Agent 从头写到尾，然后自己宣布“完成了”。

我们需要把角色拆开。

一个负责规划。

一个负责实现。

一个负责评估。

并且还要有两个不同维度的评估器。

为什么？

因为同一个 AI 自己写、自己测、自己夸自己，很容易护短。

它会觉得：差不多了、应该没问题、这个边界场景可以不测。

这在真实工程里很危险。

所以我们要让实现者和评估者隔离。

实现 Agent 负责写代码和测试。

评估 Agent 负责站在外部视角审查它。

机器检查负责跑编译、单测、静态扫描、覆盖率。

人类负责最后看方向和关键证据。

这套分工听起来复杂，但本质很简单：不要让一个非确定性模型同时当运动员和裁判。

到了这里，一个企业级 Harness Coding 系统的基本骨架就出来了。

它不是一个 Prompt 。

它是一条流水线：

人类先写清楚需求。

AI 把需求翻译成工程契约。

人类审批契约。

AI 按契约实现。

机器跑自动化检查。

独立 Evaluator Agent 做审计。

审计到的偏航记录下来，沉淀回下一轮规则。

人类基于证据验收。

如果把上面这套链路压缩成一张图，大概是这样：

这张图看起来节点很多，但其实就一句话：需求先由人类想清楚，执行交给 AI ，结果必须被 Harness 验证。

该架构运行起来后的整套流程效果则是：

1. 团队先内部评审需求文档，确保团队内针对复杂需求是完全认知对齐的。

2. 把评审后的需求文档直接丢给 AI ，告诉它让他基于这套文档来实现。

3. AI 基于当前项目已有的前置架构和需求规范审核该文档并和人类基于该需求达成目标一致。

4. 人类批准开始干活后，AI 基于 Spec 驱动来把该需求转换为可执行的工程文档。

5. 人类审核该 Spec 文档是否对齐原始需求，审核完毕则开始允许 AI Coding

6. AI 基于 Spec 文档开发完毕后，开始自主调度 Harness Check 脚本验证当前代码变更是否符合测试覆盖率 80% 的标准、静态代码扫描是否存在 Bug 。

7. Harness Check 脚本执行不通过，则打回重新修改代码，审核通过则开始调度测试 Agent 和架构 Agent 进行需求验证。

8. 测试 Agent 基于 Spec 文档来检查 Coding 代码是否符合验收标准。

9. 架构 Agent 检查 AI 基于此次需求开发，是否破坏了项目架构的基本原则，比如：错误码规范、跨包调用等规范。

10. 双 Agent 验收通过，则最终呈现结果给到人类确认，验收失败，则打回让 AI 重新修复，只到 Agent 审核通过为止。

这就是目前我们团队内在用的开发方式。

如果硬要聊，这里面还有很多细节，比如：

你如何定义你的项目架构规范。

如何让双 Agent 打回次数过多时，把 AI 偏航记录给沉淀到文档中。

如何将上述的整个流程串联为一个自动化的流程，实现最终人类只要丢进去一个需求文档，其他的后续流程就全部自动化执行等等。

但其实上面这些问题都是非常小的问题，你只要能搞懂上述 Harness 架构的执行逻辑。

其他的单点问题则都是小问题，甚至于你完全可以把这些问题交给 AI 来帮你解决。

等你把这套流程给固化下来后，你会发现，企业级 Coding 竟然也如此简单。

事实上，企业级 Coding 未来也只会越来越简单。

不是因为代码本身变简单了。

而是因为越来越多复杂的执行过程，会被压进一套更清晰的工程流水线里。

到那个时候，真正重要的能力，就不再是“我能不能亲手写完这段代码”。

而是：

我能不能把一个模糊想法，变成一份清晰需求。

我能不能把需求，变成可执行的工程契约。

我能不能设计一套反馈系统，让 AI 犯错以后，下次永不再犯。

这才是 AI Coding 后半场真正要拼的东西。

以上。

如果觉得这篇文章还不错，欢迎一起探讨交流。

作者：贾克斯的平行世界。