Harness Engineering

1. 什么是 Harness Engineering

Harness Engineering 可以理解为：为 AI 系统搭一个稳定的“工作台”。

这个工作台要解决的不是模型本身够不够强，而是：

• 它是否拿得到正确上下文
• 它是否用得了正确工具
• 它做完后是否能被验证
• 它失败后是否能被定位和修复

所以它更偏工程基础设施，而不是提示词技巧。

2. Harness 主要包含什么

一个完整的 harness 通常包括：

• 输入组织
• 上下文注入
• 工具接线
• 状态管理
• 结果验证
• 日志与观测
• 权限与安全控制

3. 为什么需要 Harness

很多 AI 系统不稳定，不是因为模型太差，而是因为外围环境太差：

• 给模型的上下文不稳定
• 工具返回格式不统一
• 没有标准输出结构
• 失败后无法复现
• 没有自动验证环节

Harness 的目标就是把这些外围问题标准化。

4. 一个最小 Harness 的结构

输入
  -> 清洗与结构化
  -> 上下文注入
  -> 模型 / 工具执行
  -> 输出校验
  -> 日志记录
  -> 反馈回路

5. 上下文工程是 Harness 的核心

上下文不只是 prompt。

它通常包括：

• 任务说明
• 角色和边界
• 用户历史
• 业务规则
• 相关文档
• 工具说明
• 当前状态

Harness 需要决定：

• 哪些上下文必须始终存在
• 哪些上下文按需注入
• 哪些上下文要裁剪

6. 工具接入要标准化

工具混乱是很多系统失败的来源。

应尽量统一：

• 输入参数结构
• 返回结果格式
• 错误码
• 超时策略
• 重试策略

否则模型每换一个工具就要重新适应一遍。

7. 验证比生成更重要

一个工程可用的 AI 系统，不能只会生成，还要会被检查。

常见验证方式：

• JSON schema 校验
• 字段完整性校验
• 单元测试 / 集成测试
• 引用一致性校验
• 规则引擎校验
• 人工审核节点

8. 观测性必须前置

至少要看得到：

• 输入是什么
• 模型收到了什么上下文
• 调了哪些工具
• 每一步花了多少时间
• 哪一步失败
• 最终输出是什么

否则系统出了问题只能靠猜。

9. Harness 的常见落地形式

9.1 编码助手场景

Harness 可能包括：

• 仓库文件选择策略
• 测试命令
• lint 命令
• patch 应用方式
• 失败回滚或人工确认

9.2 知识助手场景

Harness 可能包括：

• 检索器
• 重排器
• 引用格式
• 答案模板
• 事实校验流程

9.3 业务自动化场景

Harness 可能包括：

• 审批流
• 权限系统
• 外部 API
• 失败重试
• 人工兜底

10. 好的 Harness 长什么样

好的 harness 往往具备这些特征：

• 输入稳定
• 输出可校验
• 工具可替换
• 行为可追踪
• 失败可复现
• 风险可隔离

11. 一句话总结

Harness Engineering 解决的是“怎么让 AI 稳定工作”，而不是“怎么让 AI 看起来更聪明”。