Harness工程：从对话到环境构建的AI工程新范式

一、一个被忽视的瓶颈

2025年前后，业界对智能编程工具的讨论几乎都集中在一个问题上：怎么把话说清楚。提示词模板、思维链、角色设定、少样本示例——大量精力被投入到”如何与模型对话”这件事上。

但一个反直觉的现象逐渐浮现：当模型能力以季度为单位跃升时，很多团队的实际交付效率并没有同步提升。模型能写出漂亮的函数，却无法独立完成一个跨模块的需求；能修复单个bug，却理不清代码库中的隐式依赖；能生成代码片段，却无法保证其在真实工程约束下可运行、可测试、可维护。

问题不在模型。问题在于我们只给了模型一张嘴，却没给它一双手、一双眼睛和一套工具。

这正是Harness工程要解决的核心命题。

二、Harness概念的诞生背景

Harness一词，原意是”马具”或”束具”——把动力源与执行机构连接起来，让力量可以被有效地导向目标。在AI工程语境下，它被引申为：围绕智能体构建的、使其能够自主完成复杂任务的完整运行环境。

这个概念真正进入行业视野，源于一次大规模实验的公开。某前沿研究团队组建了一个极小规模的工程小组（初期仅3人，后扩展至7人），在约5个月的时间里，借助智能编程工具生成了超过100万行生产级代码，合并了约1500个代码合并请求，且几乎没有人工手写代码。

这个结果本身足够震撼，但更有价值的是实验过程中暴露的问题：早期进展远低于预期。团队复盘后发现，瓶颈并非模型能力不足，而是运行环境定义得不够充分——智能体缺少实现高层目标所需的工具、抽象和内部结构。

换句话说，模型不缺智力，缺的是让它能施展智力的工作台。

三、三次范式跃迁

从”提示词工程”到”Harness工程”，AI工程化范式经历了三次清晰的跃迁。

第一次跃迁：从”提问”到”指令”

早期实践聚焦于如何构造更好的输入。核心假设是：只要提示词足够精确，模型就能给出正确答案。这一阶段的代表性技术包括结构化提示、思维链、约束解码等。

局限在于：它把模型当作一个无状态的函数，忽略了任务执行的连续性和环境依赖性。

第二次跃迁：从”指令”到”流程”

随着智能体概念的成熟，工程重点转向任务编排。开发者开始设计多步骤工作流、工具调用链、状态机与回滚机制。模型不再是”回答问题的引擎”，而是”执行流程中的一个决策节点”。

这一阶段的关键词是：工具调用、记忆管理、任务分解、反思循环。

但新的问题出现了：流程可以设计，但流程运行的环境依然脆弱。工具接口不稳定、上下文丢失、错误无法自愈、权限边界模糊——这些工程问题无法靠提示词或流程图解决。

第三次跃迁：从”流程”到”环境”

Harness工程正是在这一背景下提出的。它的核心主张是：智能体的效能上限，由其所处运行环境的完备程度决定。

一个完备的Harness环境通常包含以下层次：

层次	作用	关键要素
工具层	提供可调用的原子能力	文件读写、命令执行、网络请求、数据库访问
抽象层	屏蔽底层复杂度	领域特定接口、类型系统、配置管理
反馈层	让智能体感知结果	日志、测试输出、编译错误、运行时异常
约束层	定义安全边界	权限控制、沙箱隔离、资源配额
结构层	组织长期任务	任务图、上下文存储、进度追踪

缺少任何一层，智能体的表现都会显著退化。这正是实验中”早期进展缓慢”的根本原因——团队最初只提供了基础工具，却没有构建足够的抽象和反馈机制。

四、Harness工程的核心原则

原则一：环境即接口

不要指望智能体”理解”你的意图。要把意图编码进环境。例如，与其在提示词中反复强调”请遵循项目的代码规范”，不如在环境中提供一个自动格式化和静态检查的钩子，让不合规的代码无法通过。

# 反例：把规则写在提示词里
prompt = "请确保所有函数都有类型注解，且行宽不超过88字符..."
# 正例：把规则编码进环境
def validate_code(file_path):
    result = run_linter(file_path, config="strict")
    if result.errors:
        return {"status": "rejected", "feedback": result.errors}
    return {"status": "accepted"}

后者的优势在于：规则可执行、可验证、可迭代，且不依赖模型对自然语言的理解稳定性。

原则二：反馈必须即时且结构化

智能体需要知道”我做对了没有”。模糊的反馈等于没有反馈。理想的反馈应当是结构化的、机器可读的错误信息，包含位置、类型、严重程度和修复建议。

{
  "status": "error",
  "location": {"file": "src/service.py", "line": 42},
  "type": "type_mismatch",
  "message": "Expected int, got str",
  "suggestion": "Cast input using int() or update the type annotation"
}

原则三：抽象层次要对齐任务粒度

工具太底层，智能体需要大量步骤才能完成简单任务；工具太高层，智能体失去灵活性。好的Harness设计应当提供多粒度工具集：既有原子的文件操作，也有领域级的”创建一个符合规范的服务模块”。

原则四：约束不是限制，而是引导

沙箱、权限、配额这些约束，表面上限制了智能体的行为，实际上是在缩小搜索空间，让智能体更快找到可行解。没有约束的环境，智能体容易陷入无效探索或危险操作。

五、一个最小可用的Harness示例

以下是一个简化但完整的Harness骨架，用于说明各层如何协作：

class Harness:
    def __init__(self, workspace, tools, validators, feedback):
        self.workspace = workspace      # 结构层：工作区
        self.tools = tools              # 工具层：可调用能力
        self.validators = validators    # 约束层：规则校验
        self.feedback = feedback        # 反馈层：结果感知
    def execute(self, task):
        plan = self.decompose(task)              # 任务分解
        for step in plan:
            action = self.select_tool(step)      # 工具选择
            result = action.run(self.workspace)  # 执行
            check = self.validate(result)        # 校验
            if not check.passed:
                self.feedback.report(check)      # 反馈
                return self.retry(step, check)   # 重试或回滚
        return self.summarize(plan)
    def validate(self, result):
        for validator in self.validators:
            outcome = validator.check(result)
            if not outcome.passed:
                return outcome
        return Passed()

这个骨架的关键不在于代码本身，而在于它体现的思想：把智能体的行为放进一个可观测、可约束、可反馈的闭环中。

六、对开发者的实践建议

1. 先建环境，再调提示。在优化提示词之前，先检查工具是否够用、反馈是否清晰、约束是否明确。

2. 把重复的提示词转化为环境能力。如果一条规则需要反复提醒，说明它应该被编码进工具或校验器。

3. 从最小闭环开始。不必一开始就构建完整的五层结构，可以先从”工具+反馈”这个最小闭环做起，逐步补充抽象和约束。

4. 度量环境而非度量模型。当任务失败时，先问”环境缺了什么”，而不是”模型怎么了”。

5. 为智能体设计，而非为人设计。人类友好的界面未必是智能体友好的接口。结构化、确定性、可解析，比美观和直觉更重要。

七、结语

Harness工程的本质，是把AI工程化的重心从”如何表达意图”转移到”如何构建让意图得以实现的环境”。这不是对提示词工程的否定，而是它的升维。

当模型能力不再是瓶颈时，真正的竞争力在于：你为智能体搭建了一个怎样的世界。这个世界越完备、越清晰、越有反馈，智能体就越能接近它自身的上限。

而这，正是Harness工程要回答的问题。