title: Harness Engineering概述
date: 2026-05-04 19:55:01
tags: []
categories:
- 人工智能

引子：从”让模型说对话”到”让模型真的干活”

过去两年，Agent 开发的关注点经历了一次安静却彻底的迁移。

  • Prompt Engineering：精心打磨每一次的单轮指令；
  • Context Engineering：在每个决策点动态拼装上下文；
  • Harness Engineering：设计一整套把模型”包起来”的控制系统。

前两者仍在追问”怎么让模型输出得更好”，而 Harness Engineering 问的是另一个问题——怎么让这个并不稳定的智能体，真的能稳定、可靠、长时间地完成复杂任务。

LangChain 团队把它凝练成一条公式：

Agent = Model + Harness

Model 负责”思考”，Harness 负责”让它真的能干活，而且别出大事”。

一、模型的”先天缺陷”

要理解为什么需要 Harness，先要承认 LLM 本质上有一组绕不开的缺陷。LLM 本质上是 stateless（无状态）的——它不记得上一次对话，不知道自己刚才做过什么，每次请求都是一次崭新的”失忆”。

由此派生出四类经典问题：

  1. Context Rot（上下文腐烂）：对话越长，上下文窗口被无关噪声污染得越厉害，模型的判断质量随之下降。
  2. Hallucinated Tool Calls（工具调用幻觉）：调用不存在的工具、传错参数、编造返回值。
  3. Lost State on Failure（失败时状态丢失）：某一步工具执行失败，整个任务链就可能彻底断裂。
  4. Early Stopping（过早停止）：任务还没做完，模型却以为自己完成了，提前收手。

这些缺陷不是”把模型再练强一点”就能解决的——它们是”工程问题”，需要”工程方案”。

二、Harness 到底是什么

Harness 在英文里是”马具、缰绳”的意思。用在这里很传神：模型是那匹有灵性但不稳定的马，Harness 是让它能拉车、能听指令、不狂奔的全套装备。

具体来说，一个 Harness 通常包括：

  • System Prompts：系统提示词；
  • Tools / Skills / MCPs：工具、技能包及其描述（包括 MCP 协议）；
  • Bundled Infrastructure：捆绑的基础设施——文件系统、沙盒、浏览器等；
  • Orchestration Logic：编排逻辑——子智能体生成、任务交接、模型路由；
    • 模型路由：给智能体配置多个模型，根据任务复杂度动态选择，以在 Token 成本与推理性能之间取得平衡；
  • Hooks / Middleware：用于确定性执行的钩子和中间件——上下文压缩、任务延续、代码检查等。

核心职责

Harness 要扛下来的事情包括：

  • 工具执行
  • 内存管理
  • 状态持久化
  • 错误恢复
  • 上下文编排
  • 评估与度量：任务成功率、效率、成本、鲁棒性、安全性、一致性
  • 日志记录与可复现性

一句话总结：

不是模型的能力不够，而是你没有驾驭它的能力。

三、七项核心能力

判断一个 Agent 是否真正采用了 Harness 架构，看的不是它用了哪个框架，而是它是否具备以下七项能力：

1. 规划能力

显式的任务分解与待办管理，而不是让模型”边想边做”。

2. 虚拟文件系统

对抗上下文腐烂的核心手段。把中间结果、长文档、工具产出写入文件而非塞进 Prompt，需要时再按需读取。上下文窗口从此不再是”垃圾桶”，而是”工作台”。

3. 任务委托 / 子智能体

通过派生子智能体，实现上下文隔离和算力分配——主智能体保持宏观视角，子智能体处理细节，互不污染。

4. 上下文管理

这是 Harness 工程中最精密的部分，可以拆成四层：

  • 输入上下文：系统提示词、待办列表、记忆、技能、文件系统工具说明等，在智能体启动时注入；
  • 运行时上下文压缩：把体积过大的工具输入/输出卸载到外部存储；
  • 摘要化：长对话历史定期归纳成摘要；
  • 长期记忆：跨会话保留的用户偏好与历史决策。

5. 代码执行与安全沙箱

遵循 “Trust the LLM” 的哲学——不要过度限制模型的行动，但要把它关在隔离的执行环境里。自由与安全靠沙箱边界来平衡，而不是靠禁止。

6. 人工介入（Human-in-the-loop）

关键决策点暂停、请求人类审批。对生产级系统，这几乎是必选项。

7. 技能包加载与管理（Skills）

按需动态加载技能，而不是一次性把所有能力塞进系统提示词里。

四、什么叫”采用了 Harness 架构”

回到最朴素的判断标准：

  • 架构是一种思想，不是一个库；
  • 只要你的系统具备上述七项能力，无论用 LangChain、LangGraph、自研还是裸写，它就是 Harness 架构。

反过来说，哪怕用了最时髦的框架，如果规划缺位、文件系统缺位、子智能体缺位——那还是在做 Prompt Engineering 的延伸，不是 Harness Engineering。

结语

从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering，本质上是工程重心的三次外移：

  1. PE：优化”这一次说什么”；
  2. CE：优化”这一刻带什么上下文”；
  3. HE：优化”整个系统如何让模型持续地干活”。

真正能把 Agent 从 Demo 推到 Production 的，从来不是某个”更神奇的提示词”，而是那套不起眼的、但稳稳托住模型的 Harness。

模型是发动机，Harness 才是车。