从 Vibe Coding 到 AI Harness：大模型的工程化底座

一、概念定义：什么是 AI Harness

Harness 一词原意是“马具、挽具”，在传统软件测试领域，“测试脚手架（test harness）”指为了运行和验证被测程序而搭建的一整套支撑设施——包括驱动程序、桩模块、测试数据与执行环境。把这个概念迁移到 AI 编码场景，可以给出如下定义：

AI Harness 是围绕大模型构建的一整套工程化支撑体系。它负责向模型持续供给正确的上下文、执行模型的动作意图、以机器可执行的方式验证产出正确性，并把验证结果回灌给模型，最终将模型能力“套”进团队真实的研发流程中，跑完从需求受理到可上线交付的完整闭环。

同一个概念，可以从三个视角理解：

• 技术视角：一组工具、脚本、沙箱与自动化检查的集合，是模型的“手、脚和眼睛”；
• 流程视角：把需求单、方案文档、代码仓、测试、评审、合并请求串联起来的执行框架；
• 协作视角：人与 AI 的分工契约——AI 负责执行与迭代，Harness 负责约束与验证，人负责关键决策与最终兜底。

一句话概括：模型决定能力上限，Harness 决定交付下限。

二、背景与价值：为什么模型够强了，还需要 Harness

2.1 一个普遍现象

现在开发者手里都有越来越强的模型，但如果尝试让 AI 独立完成一个完整的产品需求——从项目协作平台上的需求工单开始，到技术方案落地、代码修改完成、接口跑通、代码评审通过、最后提交合并请求——大概率会中途夭折。原因并不在于模型不会写代码，而在于整条链路上大部分工作根本不是“写代码”本身，而是四类经常被低估的事：

• 协作：需求信息散落在需求系统、文档知识库、历史代码里，模型默认拿不到，只能靠人搬运；
• 流程：改完代码只是开始，后面还有静态检查、单元测试、集成测试、评审等多道门禁要过；
• 信任：AI 生成的代码不能默认可信，必须有机器可执行的验证手段兜底，否则没人敢合入；
• 收口：状态要回写、文档要更新、相关方要同步，这些“杂活”恰恰是交付的一部分，漏掉任何一环都不算完成。

2.2 Vibe Coding 的边界

Vibe Coding 指开发者以对话方式驱动模型即兴生成代码的工作方式。它的典型特征是：上下文局部、验证靠人、产出片段。这种方式适合写原型、写脚本、写局部函数，但在跨模块、强约束、需要真实集成验证的业务工程中，会迅速暴露三个短板：生成结果缺乏全局一致性、正确性判断完全依赖人工、与团队既有流程脱节。Vibe Coding 是一种“使用方式”，而 Harness 是让这种方式升级为“交付能力”的支撑设施。

2.3 大仓场景的放大效应

以某企业内部一个典型的 A/B 实验平台类业务为例：三十余个微服务、十余个前端微应用、多套 SDK 库，统一在一个大仓中管理；验证一个功能不是“能跑起来就行”，而是要拉起沙箱、初始化数据库表结构、准备缓存等中间件依赖、运行真实接口测试；信息输入输出也横跨需求管理系统、文档知识库、代码托管平台、评审与知识管理等多套外部系统。在这种工程形态下，一次改动可能同时跨越多个子模块，模型单打独斗几乎必然失败——这正是 Harness 存在的价值。

三、核心组成：Harness 的五层结构

一个可落地的 Harness，通常可以拆解为五层：

1. 上下文供给层：把任务相关的信息结构化地喂给模型，来源包括需求工单、方案文档、代码检索结果、相关历史变更。关键不是“给得多”，而是“给得准”——按任务裁剪上下文，控制噪声、成本与延迟。
2. 工具执行层：把模型的意图变成真实动作。代码检索、文件编辑、测试执行、接口调用等能力被封装为模型可调用的工具，并有明确的输入输出协议，避免模型“说得到做不到”。
3. 环境层：可复制、可一键拉起的执行环境，包括沙箱、依赖服务、数据初始化脚本。没有稳定环境，AI 的每次尝试都不可复现，反馈循环就无从建立。
4. 验证门禁层：把团队规范与上线标准沉淀为脚本化检查——静态扫描、单元测试、接口测试、评审规则校验。门禁是 Harness 的心脏，它把“人的信任”翻译成“机器的判定”。
5. 流程收口层：与需求系统、代码托管、评审系统对接：提交合并请求、回写需求状态、更新方案文档，让 AI 的工作融入团队既有协作，而不是游离在流程之外。

四、工作原理：行动—验证—修正的闭环

Harness 的运行核心是一个持续迭代的反馈闭环，示意如下：

# Harness 驱动模型完成任务的主循环（示意）
task = load_requirement()             # 从需求系统拉取工单
ctx  = build_context(task)            # 注入方案文档、相关代码、接口约定
while not done:
    actions = model.plan(ctx)         # 模型产出动作计划
    result  = harness.exec(actions)   # 执行：改代码、拉沙箱、跑测试
    report  = gates.check(result)     # 门禁：lint/单测/接口测试/规范校验
    if report.passed:
        harness.submit(result)        # 提交合并请求并回写需求状态
        done = True
    else:
        ctx.append(report)            # 失败信息回灌，驱动下一轮修正

背后有三条设计原则：

• 反馈闭环优先于一次性生成：真正收益不来自“一次生成完美代码”，而来自“失败信息可回灌”的迭代循环；
• 约束前置：与其事后靠人工评审拦截问题，不如把团队约束写成模型执行前就能感知的规则与脚本检查；
• 状态可追溯：每一步动作、每一次验证结果都留痕，出问题能定位、能回滚、能复盘。

五、典型场景与适用边界

Harness 适合以下场景：

• 多模块大仓：一次需求可能横跨多个子模块甚至多个子仓库，需要统一的验证与提交策略；
• 前后端联动的业务平台：如实验平台、配置中心、运营后台类系统，接口契约多、集成验证重；
• 需要真实集成测试的功能：涉及数据库结构变更、中间件依赖、真实接口调用的需求；
• 多外部系统协作的研发流程：需求、文档、代码、评审分散在多个平台，需要 Harness 做粘合与收口；
• 遗留系统改造与批量重构：在门禁兜底下，让 AI 承担高强度、大体量的机械性改造。

相应的，它并不适合：纯探索性原型（Vibe Coding 足够）、缺乏测试保护的代码库（应先补门禁再引入）、以及以人工创意设计为核心的工作。

六、与相关概念的区别

• 与 Vibe Coding：前者是人机对话式的即兴编程，产出片段、验证靠人；后者是工程化体系，目标是完整交付、验证靠机器门禁。
• 与智能体框架：智能体框架解决“模型如何规划与调用工具”，只是 Harness 的组成部分；Harness 还包括环境、门禁、流程收口等更宽的工程面。
• 与 CI/CD：CI/CD 面向“已提交的代码”做自动化构建与部署，触发点在提交之后；Harness 把门禁前移到模型产出代码的过程中，反馈更快、更贴近生成现场。二者互补而非替代。
• 与传统测试脚手架：传统 harness 服务于“被测程序”，AI Harness 服务于“正在干活的模型”，验证对象从代码扩展到“模型 + 代码 + 环境”的整体行为。

七、使用注意事项

1. 门禁先行，再谈放权：没有可执行的验证，就不要让 AI 直接改动主分支；先补测试与静态检查，再逐步扩大 AI 的活动范围。
2. 环境可复制是硬前提：沙箱一键拉起、依赖服务可控、数据可初始化，做不到这一点，反馈闭环就是空谈。
3. 上下文治理决定成本与质量：外部系统信息应结构化接入，避免把整个文档库塞给模型；按任务裁剪，控制成本与延迟。
4. 权限最小化与全程审计：模型使用的凭证按最小权限发放，合并、发布等关键操作保留人工确认，所有动作可审计。
5. 渐进式授权：从单模块小需求起步，先验证 Harness 判定的可信度，再扩展到跨模块改动。
6. 成本与延迟要设预算：多轮闭环意味着多次模型调用与多次测试执行，应为不同任务设置迭代轮数与超时策略。
7. 工具链可自建也可复用云上能力：无论自研，还是使用百度智能云等云平台提供的模型服务、容器、流水线、监控告警等通用能力，关键都在于门禁与环境两个环节是否扎实，而不是工具本身多先进。

八、总结

回到定义本身：AI Harness 是围绕大模型构建的上下文供给、工具执行、环境支撑、验证门禁与流程收口体系。它回答的问题是——当模型能力已经够强，如何让 AI 在真实的多人协作、多系统耦合、多门禁约束的工程现实中，独立跑完一个完整需求。模型决定能力上限，Harness 决定交付下限。对多数团队而言，比追逐更强模型更务实的路径，是先把门禁、沙箱和流程收口这三件事做扎实——这往往才是“AI 能不能真正干活”的分水岭。