什么是Harness工程：驾驭智能体的“控制系统

从提示词工程到上下文工程，再到今天被高频讨论的Harness工程，智能体开发的关注点正在经历一次清晰的迁移：从“对模型说什么”，到“让模型看到什么”，再到“模型在什么环境中运行”。本文将系统梳理Harness工程的概念、原理、架构与落地方法。

一、Harness是什么：模型之外的一切

1. 从“马具”说起

Harness一词的本义是马具，缰绳、马鞍、嚼子组成的整套装备。马的力量并不会因马具而增强，但正是马具让这股强大而不可预测的力量变得可控、可导航、可协作。把这个隐喻迁移到智能体开发中，含义非常清晰：Harness工程不去优化模型本身的参数与能力，而是去设计和优化模型运行的环境，让既有能力稳定地转化为可靠的生产行为。它不是削弱模型，而是为模型配上一套“黄金缰绳”。

2. 一个公式与一门学科

行业正在形成一个高度凝练的共识公式：

Agent = Model + Harness

据此，Harness Engineering可以定义为一门设计并维护控制系统的工程学科，该系统规范智能体如何感知环境、如何选择行动、如何验证输出。它的外延覆盖“模型之外的一切”：

• 系统提示词与角色设定；
• 项目级说明文件（仓库约定、构建命令、测试方式、代码规范）；
• 工具注册、调用协议与参数约束；
• 文件系统与沙箱执行环境；
• 编排逻辑、状态管理、重试与恢复；
• 钩子与中间件（如调用前审批、调用后审计）；
• 评测体系与反馈回路；
• 权限、日志、成本等治理机制。

3. 与提示词工程、上下文工程的关系

三者是递进与包含关系，而非替代关系：提示词工程解决“对模型说什么”；上下文工程解决“让模型看到什么”；Harness工程则回答“模型在什么环境中运行、如何被引导、如何被验证、出错怎么办”。前两者可以视为Harness中“引导”与“数据上下文”两个局部，而Harness把它们纳入一个带反馈回路的完整控制系统。

二、为什么瓶颈不在模型，而在Harness

1. 模型质量正在变成“基本门槛”

近两年基座模型的推理、代码与工具调用能力快速趋同，行业内的普遍判断是：模型质量已成为入场券，真正拉开智能体产品差距的，是围绕模型构建的运行环境与控制体系。同一代模型在不同团队手中表现迥异，差异主要来自Harness。

2. 接口与上下文组织能造成数量级差距

一个被反复引用的公开评测观察是：同一个模型，仅仅因为工具接口格式、返回结构与上下文组织方式的差异，在相同基准任务上的得分可以从个位数百分比跃升至六十个百分点以上，相差近十倍。模型没有变，变的是它“看到的世界”和“被允许的做事方式”。这说明相当一部分“模型不行”的结论，其实是Harness不行。

3. 投产难的三大根因

行业调研普遍显示，绝大多数智能体项目难以真正进入生产阶段（有统计称近九成）。拆开看，问题几乎都出在控制系统的缺失：

• 误差累积：多步任务中，单步95%的正确率，十步之后整体正确率已不足六成；没有纠错回路的链条越长越不可靠。
• 不可验证：输出没有客观校验标准，“看起来对”无法转化为“被证明对”，团队只能靠人工抽检，成本高且不可持续。
• 无界自主：智能体默认拥有过大的行动权限，一次误删除、一条错误指令就足以让业务方失去信任。

这三类问题的解药都不在模型里，而在Harness的设计里。

三、控制论视角：引导与传感器的双回路

业界逐渐形成一套标准化分类法，把Harness组件划分为前馈控制与反馈控制两类。

1. 引导（前馈控制）：在行动之前降低出错概率

• 系统提示词：定义角色、目标、边界与风格，是性价比最高的引导手段；
• 项目级说明文件：把仓库约定、构建与测试命令写成智能体启动即可读取的文档，相当于新员工手册；
• 工具描述与参数模式：工具说明、参数schema、返回示例直接决定模型能否正确选择和填充调用；
• 规则与策略：明确“禁止做什么”“什么需要人工确认”，把安全边界前置。

2. 传感器（反馈控制）：在行动之后发现并纠正错误

• 输出校验：结构校验（如JSON模式校验）、编译与静态检查、单元测试；
• 执行反馈：命令退出码、日志、测试报告回灌给模型，形成“观察—修正”循环；
• 评测与回归：离线评测集量化每次改动的影响，防止“修一个坏三个”；
• 运行监控：线上指标、告警与人工评审节点构成最后一道防线。

经验法则是：前馈决定下限，反馈决定上限。只有引导没有传感器，错误会静默累积；只有传感器没有引导，模型会反复试错、成本失控。

3. 数据上下文层：让感知不失真

智能体的“感知”由上下文决定。数据上下文层负责把检索结果、文件内容、执行观察做结构化、去噪与时效排序，确保模型每一步看到的都是相关、准确、精炼的信息。上下文污染与上下文膨胀是长任务失败的常见诱因，需要像管理内存一样管理上下文。

四、六层参考架构：让复杂度各就各位

一个可用于自查与排障的分层模型如下，每层职责单一、可独立演进：

1. 上下文层：环境感知与记忆，包括检索、历史管理、摘要压缩。典型问题：关键信息缺失、噪声淹没指令。
2. 引导层：系统提示、规则策略、项目说明。典型问题：指令冲突、边界模糊。
3. 工具与执行层：工具注册、参数校验、沙箱隔离、文件访问。典型问题：权限过大、副作用不可回滚。
4. 编排层：任务分解、循环控制、状态机、多智能体协作。典型问题：死循环、状态丢失。
5. 验证层：评测集、校验循环、错误恢复。典型问题：缺少客观验收标准。
6. 治理层：权限分级、审计日志、成本与延迟控制、灰度发布。典型问题：出事无法追溯、成本不可预测。

排查智能体故障时，自下而上逐层定位，往往比反复调整提示词更有效。

五、设计原则：人类掌舵，智能体执行

Harness工程的核心哲学可以浓缩为八个字：人类掌舵，智能体执行。它落地为几条可操作的原则：

• 确定性优先：凡是用普通代码能保证的环节（校验、重试、路由），不要交给模型概率性地处理；
• 最小权限：默认只读，写操作与外部副作用按风险分级审批；
• 全程可观测：每一步的输入、输出、工具调用、耗时与成本完整留痕；
• 失败可恢复：关键节点设置检查点，支持回滚与断点续跑；
• 明确的升级路径：连续失败或命中高风险规则时，优雅地把控制权交还人类。

六、从零搭建Harness的行动清单

按优先级排列，按需取用：

P0（先跑起来，且不出事故）

• 写清系统提示：目标、边界、输出格式；
• 梳理工具清单，补全每个工具的描述与参数模式；
• 对所有结构化输出做模式校验，失败即携带错误信息重试；
• 打通全链路日志，记录每次决策依据。

P1（稳定可用）

• 建立小型评测集，把线上坏例沉淀为回归用例；
• 引入沙箱执行环境，隔离文件与命令副作用；
• 实现上下文管理：裁剪、摘要、按需检索；
• 为高风险操作增加人工确认钩子；
• 设计错误恢复：重试上限、降级策略、检查点。

P2（规模化）

• 把评测接入持续集成，模型或提示变更自动跑回归；
• 建立成本、延迟、成功率的监控告警；
• 支持提示与策略的灰度对比发布；
• 沉淀多任务、多智能体的编排经验与知识库。

企业落地时，这些组件大多可由云平台的通用能力组装而成，例如模型服务、函数计算、容器与沙箱、日志服务、监控告警等，百度智能云等主流云平台均提供此类基础类目，团队可以把精力集中在控制逻辑本身而非基础设施。

七、一个最小Harness的代码骨架

用一段伪代码说明各层如何咬合：

SYSTEM_PROMPT = "你是代码修复智能体：只允许读写 /workspace，禁止联网……"
function run(task, max_steps = 10):
    ctx = [build_context(task)]              # 数据上下文层
    for step in 1..max_steps:                # 编排层：有界循环
        act = model(SYSTEM_PROMPT, ctx)      # 引导层 + 模型
        if act.type == "answer":
            if validate(act.payload):        # 传感器：验证
                return act.payload
            ctx.append(feedback(act.payload))  # 反馈回路
        else:
            obs = sandbox_exec(act.tool_call)  # 执行层：沙箱
            ctx.append(obs)                    # 观察回灌
    return escalate_to_human(task)         # 人类掌舵

这个骨架体现的正是Harness的本质：模型只负责“下一步做什么”的判断，其余的引导、约束、验证、恢复全部由确定性的工程代码兜底。

八、结语

提示词工程、上下文工程、Harness工程并非三个割裂的风口，而是智能体控制系统逐步完整的三个阶段。当模型能力逐渐趋同，决定智能体表现天花板的，不再是参数规模，而是那套看不见的运行环境，系统提示、工具协议、沙箱、评测与反馈回路。圈子里那句略带调侃的话值得每个从业者记住：在这场游戏里，如果你不是模型，那你就是Harness。