基于人机协作的 AI 研发新体系架构：从 Harness 工程到 Loop 工程实践

在企业级 AI Coding 的落地过程中，有两个概念正在成为技术团队讨论的焦点：Harness 工程与 Loop 工程。它们不是互斥的两套方案，而是同一套人机协作体系在不同成熟阶段的表现形态。理解两者的区别与联系，能够帮助团队避免在错误的时间投入错误的工程能力，也能更清晰地规划从“引入模型能力”到“建立可持续研发体系”的演进路径。

本文将从定义、架构定位、工程化方式、人机协作模式、适用阶段与落地成本等维度，对 Harness 工程与 Loop 工程进行系统对比，并说明在企业实际场景中如何组合使用。

一、为什么要比较 Harness 工程与 Loop 工程

大模型进入研发流程后，团队面临的问题不再只是“模型能力够不够强”，而是“模型智能如何在真实工程环境中稳定产生价值”。一个常见的现象是：同样使用主流大模型，不同团队的 AI Coding 效果差异巨大。这个差异往往不是模型本身造成的，而是团队在模型外围构建的工程能力不同。

Harness 工程和 Loop 工程正是描述这种外围能力的两个层级：

• Harness 工程回答的是：如何让一个模型变成可用的智能体；
• Loop 工程回答的是：如何让多个智能体在持续任务中稳定协作并自动推进。

两者共同构成了企业级 AI 研发体系的骨架，但它们的侧重点、设计目标与落地方法存在明显差异。

二、Harness 工程：把模型约束成可用智能体

2.1 核心定义

Harness 工程的核心可以用一个公式概括：

Agent = Model + Harness

其中，Model 提供通用智能，Harness 负责将这种智能约束、引导、组装到具体业务场景中。简单来说，如果你不是模型本身，那你做的工作大概率就是 Harness。

在企业场景中，Harness 不是单一的“提示词模板”或“工具调用层”，而是一组工程模块的集合。一个面向企业研发场景的 Harness 通常包括以下能力：

• 业务规则注入：将合规、安全、编码规范等要求转化为模型可执行的约束；
• 上下文管理：控制模型在生成代码时能看到什么，不能看到什么；
• 工具与接口适配：让模型能够调用组织内部已有的代码仓库、需求系统、构建系统；
• 输出校验与质量门禁：对模型生成结果进行静态检查、单测验证、安全扫描；
• 记忆与状态管理：在多轮交互中保持任务目标的一致性；
• 权限与审计：确保模型在组织授权范围内行动，并留下可追溯记录。

2.2 Harness 解决的问题

Harness 工程要解决的核心问题是：模型很强，但模型“不知道你的业务”。 一个通用大模型可以生成很漂亮的代码，但不一定符合企业内部的架构规范、安全基线或领域约束。Harness 的作用就是把这些“组织知识”转化为模型能够感知和遵守的约束条件，让智能变得可用。

2.3 Harness 的局限

Harness 工程本质上是“人定义规则，模型执行规则”。它适合任务边界清晰、单次交互即可完成的场景。但当任务链条变长、需要多个步骤连续推进时，单纯靠 Harness 就会暴露出两个问题：

第一，人工介入过多。每次模型输出后，人都需要检查、修正、重新输入，效率提升有限；
第二，上下文容易断裂。多轮交互中，模型可能偏离最初目标，Harness 本身不负责“任务推进”，只负责“单次约束”。

三、Loop 工程：从“单次驾驭”到“循环推进”

3.1 核心定义

Loop 工程的核心理念是：不再由人来写提示词驱动智能体，而是由循环来驱动智能体。

这里的“循环”指的是设计一组自动化的任务流转机制，让智能体在完成一步后，根据预设的反馈条件自动进入下一步骤，直到任务结束或触发人工介入。换句话说，Loop 工程关注的不再是“怎么跟模型说一句话”，而是“怎么让模型在一系列步骤中自己走下去”。

Loop 工程可以看作 Harness 工程之上的一个层级：

• Harness 保证每一步的输出质量；
• Loop 保证多步骤之间的推进和反馈闭环。

3.2 Loop 的六大构建模块

从工程实践角度看，Loop 工程通常包含以下六个构建模块：

1. 任务分解与规划：将复杂研发任务拆解为可执行、可验证的子任务；
2. 状态管理：在循环过程中维护当前进度、已完成项和待处理项；
3. 反馈信号定义：明确什么情况算“通过”，什么情况算“需要重试”；
4. 重试与纠错策略：当生成结果不符合要求时，自动调整上下文并重新生成；
5. 人工检查点：在关键节点插入人工审批，保证可控性；
6. 终止条件：定义循环何时结束，避免失控消耗资源或偏离目标。

3.3 Loop 解决的问题

Loop 工程解决的是 Harness 工程解决不了的问题：多步骤任务的自动化推进。

举例来说，一个“根据需求生成代码并修复单测失败”的任务，在 Harness 模式下需要人工完成以下步骤：输入需求 → 检查生成代码 → 运行测试 → 把失败信息贴回模型 → 再次检查。而在 Loop 模式下，这个过程可以被设计成一个循环：模型生成代码 → 自动运行测试 → 如果失败则自动将失败日志反馈给模型 → 模型修复 → 再次运行测试，直到通过或触发人工检查点。

人的角色从“操作者”变成了“监督者”和“循环设计者”。

四、Harness 工程与 Loop 工程的核心差异

4.1 定位差异

维度	Harness 工程	Loop 工程
核心目标	让单次模型输出可用	让多步骤任务自动推进
关注对象	模型与业务约束之间的适配	智能体与任务流程之间的闭环
人的角色	规则定义者 + 操作者	循环设计者 + 监督者
输出粒度	单次生成结果	完整任务结果

4.2 工程化方式差异

Harness 工程的交付物通常是：提示词模板库、工具调用配置、业务规则集、输出校验规则等。这些交付物以“配置 + 规则”为主，强调对模型行为的约束。

Loop 工程的交付物则更接近“流程定义”：任务分解逻辑、状态机、反馈路由、重试策略、人工审批节点等。这些交付物以“流程 + 状态”为主，强调对任务推进的控制。

可以用一个通用伪代码示意两者的差异：

# Harness 模式：每一步都需要人参与
while user_is_available:
    prompt = user.compose_prompt(task)
    result = model.generate(prompt)
    user.review(result)
    if user.accepts(result):
        break
    else:
        user.refine_prompt(task, result)
# Loop 模式：人工只在关键节点介入
state = decompose(task)
while not state.terminated():
    result = model.generate(state.current_context())
    feedback = validator.evaluate(result)
    if feedback.passed():
        state.advance()
    elif state.retry_count() < max_retry:
        state.add_feedback(feedback)
        state.increment_retry()
    else:
        state.trigger_human_checkpoint()

4.3 人机协作模式差异

在 Harness 模式下，人机协作节奏是同步的：模型输出后，人立即介入、判断、反馈。这种模式下，人的认知负担仍然较高，因为人需要理解模型的每一次输出，并决定下一步怎么做。

在 Loop 模式下，人机协作节奏是异步的：人先设计好循环规则和检查点，然后让循环自动运转，人只在异常、关键节点或最终验收时介入。这种模式下，人的注意力从“过程管理”转向“规则设计”和“结果验收”。

4.4 落地难度与适用阶段

Harness 工程是 Loop 工程的基础。没有良好的单次输出质量约束，任何循环都只会加速错误。

从落地顺序上看：

• 阶段一：先做 Harness。把业务规范、上下文管理、输出检查做扎实，保证单次生成结果可靠；
• 阶段二：再做 Loop。在 Harness 稳定后，针对高频、多步骤的任务设计循环，逐步替代人工操作；
• 阶段三：Harness 与 Loop 协同。在复杂任务中，外层由 Loop 控制流程，内层由 Harness 保证每个节点的输出质量。

五、相同点分析

尽管存在上述差异，Harness 工程与 Loop 工程在以下方面是一致的：

目标一致：两者都是为了让模型在企业研发场景中产生可用价值，而不是“用模型生成一段看起来不错的代码”。

依赖共同基础：两者都依赖模型能力的基础水平。如果模型本身完全无法理解任务，Harness 和 Loop 都无法弥补基础能力的缺陷。

工程属性一致：两者都不是模型本身的能力，而是组织围绕模型构建的工程能力。这意味着它们可以被设计、被优化、被复用，也会随业务变化而演进。

都服务于“降低人的认知负担”：Harness 通过规则约束降低人在单次交互中的判断成本，Loop 通过流程自动化降低人在多步骤任务中的操作成本。

六、典型场景选择

6.1 适合优先投入 Harness 的场景

• 团队刚开始引入 AI Coding，处于试点阶段；
• 任务以单次生成为主，例如单元测试生成、代码补全、简单脚本编写；
• 业务规则复杂且频繁变化，需要人工持续调整约束条件；
• 模型输出需要大量人工审查，团队尚未建立自动化质量门禁。

6.2 适合优先投入 Loop 的场景

• 团队已经积累了稳定的 Harness 能力，单次生成质量基本可控；
• 任务具有明确的多步骤结构，例如“需求 → 设计 → 编码 → 测试 → 修复”；
• 任务重复性高，人工介入的边际成本明显；
• 团队有能力和精力设计反馈信号、终止条件与人工检查点。

6.3 需要两者协同的场景

在企业实际研发中，大多数高价值任务都属于这一类。例如一个完整的缺陷修复任务：外层 Loop 负责“定位 → 修改 → 验证 → 提交”的循环推进，内层 Harness 保证每一步生成的代码符合组织规范、安全基线和技术栈约束。

七、选型建议

从组织成熟度出发，而不是从模型能力出发。

如果团队目前还处于“模型生成后人工大幅修改”的阶段，说明 Harness 还不够成熟，此时直接跳到 Loop 大概率只会得到“自动化的错误”。正确顺序是：先打磨 Harness，让单次输出的可用率达到组织可接受的水平，再针对高频多步骤任务设计 Loop。

从任务类型出发，而不是一刀切。

不是所有任务都需要 Loop。对于一次性、探索性、边界模糊的任务，人工参与反而更高效。Loop 的价值在重复性、结构化的任务中才能最大化。判断标准很直接：如果团队已经能清晰写出“这个任务有哪些步骤、每步怎么算完成、失败了该怎么办”，那么这个任务就具备 Loop 化的基础。

八、迁移与使用注意事项

从“Harness 为主”迁移到“Harness + Loop 协同”时，需要注意以下几点：

第一，不要抛弃 Harness。 Loop 不是 Harness 的替代品，而是上层建筑。Harness 的质量决定了 Loop 的稳定性。迁移过程中必须持续维护和完善 Harness 的能力。

第二，循环设计要从简单任务开始。 先用小范围、低风险的任务验证 Loop 的反馈机制和终止条件，再逐步扩展到复杂任务。直接在高风险生产任务上尝试复杂循环，容易让团队失去信心。

第三，人工检查点必须显式定义。 Loop 不等于“无人值守”。在企业场景中，关键节点必须保留人工审批，尤其是在涉及生产环境变更、权限操作或不可逆行为时。

第四，关注上下文与状态的一致性。 Loop 的反馈循环可能带来上下文膨胀、状态漂移、任务目标偏移等问题。需要在循环设计中加入上下文压缩策略、状态校验机制和定期的人工对齐。

第五，成本结构会发生变化。 Harness 阶段的人的成本主要花在“写提示词和检查输出”上，Loop 阶段的人的成本转向“设计循环流程、分析失败原因、优化反馈信号”。这是两种不同的工作量，需要重新评估资源配置。

九、总结

Harness 工程与 Loop 工程是企业级 AI 研发体系演进的两个连续阶段。Harness 回答“如何让模型输出可用”，Loop 回答“如何让任务自动推进”。前者关注单次交互中的规则约束与经验注入，后者关注多步骤任务中的循环设计与反馈闭环。

两者的关系可以概括为：没有 Harness 的 Loop 是加速失败，没有 Loop 的 Harness 是有限提效。 只有将两者结合，才能在保证输出质量的前提下，把人的精力从重复操作中释放出来，真正发挥大模型在研发流程中的价值。

对于技术团队而言，核心决策不是“选 Harness 还是选 Loop”，而是判断当前团队处于哪个阶段、任务是否具备循环化的结构基础、以及如何有节奏地投资工程能力。理解这两个概念的区别与联系，比急于落地某一套工具更加重要。