Harness工程之后：智能体的下一个工程手段

一、先把概念说清：Harness 是模型之外的一切

过去两年，智能体（Agent）开发的关注点经历了一次明显的迁移：从“哪个模型更强”转向“怎样让模型稳定干活”。支撑这次迁移的，是一个被业界越来越多人接受的等式：

Agent = Model + Harness

其中 Harness 指包裹在模型之外的一整套运行环境与控制结构：系统提示词、工具调用协议、文件系统与沙箱环境、编排逻辑、钩子中间件、反馈回路以及各类约束机制。模型只负责“推理与决策”这一跳，而 Harness 决定这一跳发生在怎样的上下文中、能调用哪些能力、出错之后如何被拉回正轨。

Harness 一词的本义是马具——缰绳、马鞍、嚼子，一整套用来驾驭“强大但不可预测的动物”的完整装备。这个类比相当精准：驾驭工程的目标不是削弱 AI 的能力，而是为它配上一副合身的“黄金缰绳”，让它跑得又快又稳。也有人更喜欢另一个类比：模型是 CPU，Harness 是操作系统——CPU 决定算力上限，但用户真正体验到的稳定性、安全性与易用性，几乎全部由操作系统决定。

需要厘清它与两个常被混用的概念的本质区别：

• 提示工程：局部优化，针对单次交互调整措辞与格式，收益存在明显的边际递减；
• 模型选择：更换“引擎”，决定能力上限的原材料质量；
• Harness 工程：系统工程，不优化模型本身，而是优化模型运行的环境。

三者共同作用，才能构建真正可用的智能体：前两者决定“能不能做到”，Harness 决定“能不能每次都做到”。

二、三层架构：引导、传感器与数据上下文

国际软件工程领域有资深专家提出将 Harness 组件划分为“引导”与“传感器”两大类，这一分类法已迅速成为行业事实标准。从控制论的视角看，它恰好对应前馈控制与反馈控制；再补上一层“数据上下文层”，就得到一个完整的三层控制系统。

1. 引导层：前馈控制

在动作发生之前，把约束“喂”给模型。典型组件包括系统提示词、维护在仓库根目录下的智能体行为规范文档、工具描述与使用白名单、任务边界声明等。前馈控制的优点是成本低、延迟低；局限在于覆盖不了所有情况——模型仍可能在长任务的几十个步骤之后逐渐偏离初衷。

2. 传感器层：反馈控制

在动作发生之后，度量结果并纠偏。典型组件包括评测集、验证回路（例如“改完代码必须运行测试”）、运行时监控与断言门禁。反馈控制的核心价值，是把“不可靠的模型输出”转化为“可生产级别的行为”：单次输出允许出错，但回路必须能接住错误、暴露错误、阻止错误扩散到生产环境。

3. 数据上下文层

包括状态管理、工作区文件系统、检索增强与记忆机制。它回答的问题是“模型此刻能看到什么”。上下文喂得准，普通模型也能给出高质量推理；上下文失控（过期、冗余、超限、污染），再强的模型表现也会严重打折。

三层合起来，一个示意性的运行主循环可以写成：

while not task.done:
    observation = sensors.observe(state)     # 感知：收集环境反馈
    action = model.plan(observation)         # 决策：模型推理
    action = guides.constrain(action)        # 前馈：注入约束与边界
    result = sandbox.execute(action)         # 执行：在隔离环境中落地
    state = context.update(state, result)    # 更新：维护数据上下文
    if not sensors.assert_ok(result):       # 反馈：验证与纠偏
        state.inject(correction)

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

一个反直觉、却被大量工程实践反复验证的判断是：模型质量如今已成为基本门槛，Harness 才是真正的差异化因素。因为在多数垂直任务上，头部模型之间的能力差距，已经小于“工程做得好与不好”带来的表现差距。有业界观察认为，约八成智能体项目走不出原型阶段，其共性根因很少是“模型不够聪明”，而几乎全部落在 Harness 的缺位上：

• 不可复现：同一输入两次运行的输出差异过大，缺少固化上下文与运行参数的手段；
• 长任务漂移：多步骤任务中目标逐渐偏移，缺少阶段性验证回路；
• 工具误用：模型拿到了过宽的工具权限，缺少沙箱与白名单约束；
• 上下文失控：状态在多轮之间丢失或被污染，缺少统一的数据上下文层；
• 缺少验收标准：没有评测集，就无法回答“这次改动到底是变好了还是变坏了”。

这些问题没有一个能靠换更大的模型解决。这也正是 Harness 工程的核心哲学，八个字：人类掌舵，智能体执行（Human Steer, Agent Execute）。人的职责从“亲自驾驶”转变为“设计缰绳、设定路标、审核关键节点”；智能体则在约束之内自主完成执行。智能体的天花板不由引擎单独决定，而由整套驾驭系统决定。

四、下一个工程手段：五个正在成形的方向

回到标题的问题。如果说 Harness 工程解决的是“让智能体稳定可控”，那么它的下一个工程手段，大概率围绕以下方向展开——它们共同指向一个目标：让 Harness 本身也成为被工程化的对象。

方向一：评测驱动开发，给智能体补上“CI”这一课

评测将从“上线前的一次性测试”升级为“开发流程的主轴”：每一次修改提示词、调整工具描述、更换模型，都必须跑一遍评测流水线，用数据决定是否合入。没有评测的 Harness 调优是玄学，靠感觉改提示词等于在黑暗中调参；有评测的调优才是工程。可以预见，“评测驱动开发”会像测试驱动开发之于传统软件工程一样，成为智能体团队的基础纪律。

方向二：声明式 Harness——“缰绳即代码”

未来的 Harness 更可能以声明式配置来描述：引导内容、工具与权限清单、传感器门禁、上下文策略，全部作为代码纳入版本管理，可评审、可回滚、可组合复用。示意如下：

agent:
  guides:
    system_prompt_file: prompts/reviewer.md
    repo_rules_file: ./agent-rules.md      # 仓库级行为规范文档
  tools:
    - name: read_file
      allow: ["./repo/**"]
    - name: run_tests
      sandbox: true
  sensors:
    evals:
      dataset: evals/code_review.jsonl
      gate: { metric: pass_rate, min: 0.9 }
    guardrails:
      max_steps: 20
      require_approval: [push_code, delete_file]
  context:
    workspace: ./workspace
    retrieval: repo_index

声明式化带来三个直接收益：配置变更可追溯、团队协作有共同语言、同一套缰绳可以在不同模型之间迁移复用。

方向三：运行时治理与可观测性工程

智能体需要自己的“应用性能管理系统”：全链路轨迹（每一步的输入、决策依据、工具调用与耗时）、成本与令牌计量、异常告警、权限审计。对象存储、容器平台、日志服务、监控告警等通用云基础设施——例如百度智能云提供的对应产品类目——是搭建这类观测与治理体系的常见底座选择。治理的本质，是把“对模型的一次性信任”拆解为“对每一次工具调用的权限校验”：默认最小权限，高危动作强制审批，越界即熔断。

方向四：多智能体 Harness——从“一根缰绳”到“编队规则”

当任务规模超出单智能体的能力半径，工程重心会从“单体的缰绳”升级为“缰绳之间的编队”：智能体间的编排协议、共享上下文的读写边界、任务分派与结果聚合规则、跨智能体的审批链与责任划分。这一层的成熟度，决定了大规模智能体协作究竟呈现为“有序的流水线”还是“失控的接力赛”。

方向五：自适应与自我进化——让缰绳自己变紧或变松

更进一步，Harness 可以根据评测与运行的统计数据自动调整自己：哪一版系统提示词在哪个任务分布上通过率更高、哪类工具描述容易引发误用、哪一步最常触发人工干预——由数据驱动配置的自动优化，而不是依赖工程师的手工直觉。与此同时，人的角色会从“在环中”（逐步审批每个动作）逐步演进为“在环上”（设定策略、处理异常、周期审计），把宝贵的人工干预留给真正高风险的节点。

五、从零搭建 Harness：一份行动清单

如果你正准备从零搭建一套 Harness，建议按以下顺序推进：

1. 定义任务边界与成功标准。写清楚智能体“必须做什么、绝不能做什么”，并把它转化为可度量的评测数据集——这一步做扎实，后面所有调优才有抓手。
2. 搭建引导层。系统提示词 + 仓库级行为规范文档 + 工具使用白名单。原则是宁可保守：先让智能体在窄约束下跑通，再逐步放开。
3. 建设工具与沙箱。工具描述要“窄而清晰”，一个工具只做一件事；执行一律进沙箱，权限默认最小化。
4. 铺设传感器。为关键动作挂上验证回路（如改代码必跑测试），设置步数、成本与时间上限，越界即熔断并上报。
5. 构建数据上下文层。固化工作区与状态结构；检索结果与记忆附带时间戳与来源信息，防止上下文过期与污染。
6. 接入工程流程。评测进 CI，配置变更走评审与灰度发布，出问题可一键回滚到上一个“缰绳版本”。

六、结语

从提示工程到 Harness 工程，行业的注意力完成了从“模型”到“环境”的第一次转移；而下一个工程手段，是完成从“环境”到“环境的工程化”的第二次转移——评测驱动、声明式配置、运行时治理与自适应进化，本质上都是在给 Harness 本身装上缰绳。

驾驭工程的终局，不是让缰绳消失，而是让它精细到让人几乎感觉不到它的存在：智能体在约束之内获得最大的自由，人类在约束之上保留最终的掌舵权。引擎会不断更迭，但“人类掌舵，智能体执行”这八个字，会一直是这套工程体系的压舱石。