Harness Engineering 详解

一、定义与核心价值

Agent 可靠性的瓶颈不在模型，而在模型周围的系统。模型是引擎，Harness 是方向盘。

以 LangChain Coding Agent 为例，在 Terminal Bench 排行榜中，通过仅优化 Harness（系统提示、工具配置、中间件钩子），模型未更换的情况下，排名从 30 名开外提升至前五。

Harness 源自马具（缰绳、马鞍等）的比喻：

• 模型如马（强大但无方向）
• 人类工程师如骑手（提供方向）
• Harness 是连接两者的控制系统

核心定义：通过设计解决方案避免 Agent 重复犯错。

公式：Agent = Model + Harness —— 模型提供智能，Harness 让智能变得有用。

二、与 Context Engineering 的区别

维度	Context Engineering	Harness Engineering
关注点	给 Agent 看什么信息、何时看	系统预防了什么、测量了什么、修复了什么
范围	管理上下文窗口	更广：架构约束、自验证循环、熵治理、系统可演进性等

两者互相包含，Harness 范围更广。

三、Harness 的六个核心组件

1. 上下文架构

Agent 性能在上下文利用率超过 40% 后会下降，关键是提供「地图」而非「百科全书」。

示例：

• OpenAI：将 AGENTS.MD 控制在约 100 行作为目录，指向深层文档
• Anthropic：采用 Skill 渐进式加载理念，避免信息过载

2. 架构约束

仅靠 Prompt 约束 Agent 行为不可靠（模型可不听从），前沿团队用确定性工具（如自定义 linter、结构化测试）机械执行约束。

示例：Vercel 移除 80% 冗余工具后，Agent 因解空间受限反而更快更可靠。

3. 自验证循环

解决 Agent 死循环（反复编辑同一文件）和跳过验证问题。

中间件钩子：

• 跟踪文件编辑次数（超阈值提醒重新审视）
• 退出前强制执行验证

「推理三明治」策略：

• 规划阶段：最高推理强度理解问题
• 执行阶段：降为高等保证速度
• 验证阶段：拉回最高捕获错误

避免全程高推理强度导致超时。

4. 上下文隔离

多 Agent 协作时，父 Agent 仅看到给子 Agent 的指令和最终结果，中间工具调用和产物被隔离，保持各执行单元上下文干净，避免无关信息污染。

5. 熵治理

Agent 运行时间越长，系统混乱度越高（文档过时、架构漂移等）。

示例：OpenAI 引入后台文档梳理 Agent，定期扫描并自动修复过时文档，形成自维护闭环。

6. 可拆卸性

Harness 需模块化、可拆卸，以适应模型演进。

示例：LangChain 中间件架构，各组件独立添加/移除，不影响其他部分，避免未来模型进步使现有组件成为瓶颈。

四、投资回报与实践原则

复利效应

• 添加 linter 规则可预防所有会话中的同类错误
• 验证中间件提升所有任务交付质量
• 投入越早累积收益越大

避免过度工程化

原则：只在 Agent 确实犯过的错误上投入 Harness，不解决未出现的问题。

总结

Harness Engineering 核心主张：Agent 可靠性瓶颈不在模型，而在模型周围的系统。模型是引擎，Agent 是整辆车，Harness 是方向盘和刹车；没有 Harness，再强的引擎也无法到达目的地。