什么是 Harness 工程：从提示词到智能体驾驭系统

当一个团队把大模型接入业务、跑通第一个演示之后，往往会遭遇同一个落差：演示惊艳，生产拉胯。模型在开放对话里表现聪明，但在真实任务中会漏步骤、编造事实、重复劳动、忽略约束，甚至在长流程中逐渐偏离目标。很多团队的第一反应是换更强的模型，但换完之后发现，问题只是变得不那么频繁，并没有消失。

这正是 Harness 工程要回答的问题：决定智能体表现天花板的，到底在哪里？

一、概念界定：Harness 优化的是环境，不是模型

Harness Engineering（驾驭工程）是围绕 AI 智能体设计与构建约束机制、反馈回路、工作流控制与持续改进循环的系统工程实践。它不修改模型权重，不优化推理算法，而是优化模型运行时所处的那个”环境”——包括它能看见什么信息、被允许采取哪些动作、如何判断自己做得对不对、失败之后如何修正。

这个命名借自马具：缰绳、马鞍、嚼子，是一整套引导强大但不可预测的动物的装备。这个隐喻非常准确地传达了两层含义：

• 不削弱能力：马具不是为了把马变慢，而是为了让马的力气能被安全、可控地使用。Harness 同样不是给模型加限制让它变笨，而是让它的能力可以被稳定地导向目标。
• 系统性：马具不是一根绳子，而是一套协同工作的组件。Harness 也不是一段提示词，而是提示、校验、编排、数据供给共同构成的控制系统。

由此可以给出一个简洁的工程等式：

Agent = Model + Harness

模型提供原始能力，Harness 提供可控性。二者是乘法关系——模型再强，Harness 缺失，乘积依然接近于零。这也解释了一个常见现象：同一模型在不同产品中的表现差异巨大，差异的来源往往不在模型，而在 Harness 的成熟度。

需要明确区分的是 Harness 工程与提示词工程。提示词工程关注”如何把话说清楚”，是 Harness 的一个子集；Harness 工程关注的是完整的控制闭环，包括前馈（事前引导）、反馈（事后校验）、状态管理与持续迭代。模型选型同理，它决定了能力的上限区间，但决定不了在这个区间内能稳定拿到多少。

二、控制系统模型：引导与传感器

把 Harness 当作控制系统来看，组件可以按控制论的标准划分为两类，这一分类方式已成为业界描述 Harness 结构的通用语言：

Guides（引导，前馈控制）：在智能体行动之前介入，塑造它的行为倾向。典型形态包括系统提示词、项目级约定文件（如仓库根目录下的 AGENTS.md 之类的上下文说明文件）、工具使用规范、输出格式模板、任务分解策略。前馈控制的价值在于成本低、生效快——它不需要执行就能约束行为。但它的固有缺陷是开环：引导写得再好，也无法保证模型一定遵守，因为缺少对结果的检验。

Sensors（传感器，反馈控制）：在智能体行动之后介入，观测输出并判断是否符合预期。典型形态包括自动化评测（Evals）、单元测试与集成测试、静态检查与类型校验、schema 校验、事实一致性核查、人工评审节点。反馈控制能捕获前馈漏掉的问题，但成本更高，且依赖”可判定”——只有当正确性能够被某种机制检验时，传感器才有效。

一个健壮的 Harness 必须同时具备两者，形成闭环：

目标 → [Guides: 提示/规范/模板] → 智能体执行 → [Sensors: 测试/校验/评测]
                                                          ↓
                                              不通过 → 反馈信息回注 → 重试或修正
                                                          ↓
                                                      通过 → 输出

只有 Guides 的系统是”祈祷式”的：写得漂亮，但不知道是否奏效。只有 Sensors 的系统是”打地鼠式”的：问题出了才发现，且缺少预防。两者结合，才有稳定的产出。

三、架构分层：Harness 到底包含什么

把 Harness 落到代码结构上，它通常由三个层次构成，缺一不可。

3.1 引导层

引导层负责把”做什么、怎么做、不许做什么”编码成模型可消费的输入。它不只是系统提示词，还包括任务上下文、可用工具清单、输出契约。工程实践中，引导层常见的问题是”信息过载”与”规则冲突”：把所有规范堆进一段超长提示，模型反而会忽略关键约束。

更可取的写法是分层组织：稳定的角色与全局约束、与当前任务相关的局部规则、与具体工具绑定的调用约定，分级注入。

def build_guidance(task, repo_conventions, tool_specs):
    return {
        # 稳定不变的部分，可缓存
        "system": GLOBAL_ROLE_AND_POLICY,
        # 与仓库/项目相关，随代码库演进而更新
        "conventions": repo_conventions,
        # 与任务相关，按需检索注入
        "task_context": retrieve_context(task),
        # 工具契约，明确参数与副作用
        "tools": tool_specs,
    }

3.2 传感器层

传感器层负责把”做得对不对”变成一个可执行的判定。设计的核心是判定标准的可自动化程度。代码生成类任务天然友好：编译、类型检查、测试用例都是现成的传感器。而开放式生成任务则需要构造评测集、规则校验或引入评审模型。

一个实用的做法是分层校验，从便宜到昂贵逐级升级：

def validate(output, spec):
    checks = [
        syntax_check,        # 最便宜，先拦截低级错误
        schema_validate,     # 结构是否符合输出契约
        unit_tests,          # 行为是否正确
        llm_judge,           # 语义质量评估，成本最高
    ]
    for check in checks:
        result = check(output, spec)
        if not result.passed:
            return result  # 早失败，早回注
    return PASSED

早失败原则在这里尤其重要：让最便宜的检查先跑，能显著降低整体反馈成本。

3.3 数据上下文层

第三层常被忽视，却往往是效果差异的真正来源。模型在每一步决策时能看到什么信息，直接决定了它能做出什么判断。这一层负责组织检索、记忆、历史轨迹、工具返回结果，并决定在什么时机把什么信息送入上下文。

关键设计点在于上下文的选择与压缩。把整个代码库、全部历史对话无差别塞进窗口，效果通常不如精准检索少量高相关片段。上下文层本质上是 Harness 的”感知系统”，它决定了控制回路能观测到多大的世界。

四、为什么 Harness 决定成败

关于智能体落地难，业界流传的”大多数项目无法投产”的说法，其成因很少是模型能力不足，而更多集中在几类工程缺失：

• 缺少判定标准：团队无法定义”做对了”是什么，于是也无法自动化检验，只能靠人工抽查，规模上不去。
• 缺少失败恢复：一次工具调用失败、一次格式错误就让流程中断，没有重试、降级或回滚策略。
• 缺少状态管理：长流程中丢失中间结果，重复执行已完成步骤，上下文膨胀直至失控。
• 缺少可观测性：出问题时无法定位是哪一步、哪条引导、哪次检索导致的偏差。

这四类问题全部属于 Harness 范畴，与模型无关。反过来，补齐这些机制，就能把一个”有时很聪明”的模型，转化为”稳定可用”的生产组件。这也是为什么模型质量正在成为基本门槛——当基线能力普遍达标后，差异化只能来自控制系统。

五、落地路径：从最小闭环开始

Harness 的建设不建议一步到位，而应按”先闭环、再增强”的顺序推进。

第一步，建立最小可判定闭环。 选定一个边界清晰的任务，定义可自动化的成功标准，先让传感器跑起来。没有传感器，后续所有优化都失去依据。

第二步，把引导结构化。 将全局策略、项目约定、任务上下文分离，避免单点膨胀。为每一条约束标注它对应哪个传感器——如果一条规则无法被任何传感器检验，它大概率只是装饰。

第三步，引入反馈回注机制。 让校验失败的信息以结构化形式返回给模型，而不是简单重试。反馈质量决定重试效率。

第四步，加上持续改进循环。 收集失败样本，沉淀为评测集，把反复出现的失败模式转化为新的引导规则或新的传感器。Harness 因此具备自我演进能力。

def agent_loop(task, harness, max_turns=8):
    state = init_state(task)
    for turn in range(max_turns):
        guidance = harness.build_guidance(task, state)
        action = model.decide(guidance)
        observation = harness.execute(action, state)   # 工具执行 + 状态更新
        verdict = harness.validate(observation, task.spec)
        if verdict.passed:
            return observation
        state = state.with_feedback(verdict.feedback)  # 反馈回注
    return escalate_to_human(state)                    # 超限则升级

这段示意代码体现了 Harness 的几个核心特征：引导每轮重建（感知当前状态）、校验与执行分离（传感器独立于模型）、失败带信息回注（而非盲目重试）、有明确的人工升级出口（人类掌舵）。

六、结语：人类掌舵，智能体执行

Harness 工程的核心哲学可以用八个字概括：人类掌舵，智能体执行。掌舵不是替智能体划桨，而是设定航向、铺设航道、设立检查点，并在必要时接管。这要求工程团队把注意力从”如何让模型更聪明”转向”如何让系统更可控”——前者收益递减且不可控，后者是可积累的工程资产。

对于正在构建智能体应用的团队，一个值得反复自问的问题是：你的智能体在失败时，系统知道吗？如果答案是否定的，那么当前最该补的不是模型，而是 Harness。