为什么 Prompt Engineering 之后是 Harness
在只有问答的时代,AI 的用法是打磨提示词、用 RAG 精心投喂上下文。当时模型能力弱,必须精心包装输入才能得到好答案。如今的模型不同:聪明、能做的事很多,但放任自流就会跑偏。
因此重心从「包装输入」转向「设计行为」:允许智能体使用哪些工具(读写文件、搜索、终端),按什么顺序工作,禁止做什么。这就是 Harness Engineering,正在成为 Prompt Engineering 之后的下一阶段。
同一模型,不同表现 — Harness 决定什么
有趣的是,不换模型,仅靠 harness 就能改变表现。一个开源智能体只是改变了 AI 输出代码修改方案的格式,编码性能就显著提升。智能体如何定位修改位置、如何验证结果,这些运行结构与模型智能同样重要。
这在成本上意义重大。换更贵的模型是最省事的选择,但调整 harness 往往更便宜、更有效。「试过 AI,不怎么样」的评价,多数源于缺少 harness,而非模型的局限。
不写代码也能做 Harness Engineering
直接修改智能体代码需要开发知识,但入门门槛远低于此。在 AGENTS.md、SKILL.md 这类 markdown 文件里写下「不要做这个」「项目结构是这样」「按此格式输出」,同样是 Harness Engineering。智能体在工作前会读取这些文档并照做。
这与训犬类似:比起换一只更好的狗,训练方法更能决定结果。同样地,指令又长又复杂就听不懂——规则要短、要清晰,拆成小文档来维护。
AX 视角:先文档化规则,再引入工具
SH Consulting 在 AX(AI Transformation)培训中重视 Harness Engineering 的原因正在于此。组织首先需要的不是新工具,而是把业务规则、禁忌、判断标准写成 AI 可读文档的习惯。文档积累起来后,接入任何智能体,它都会按你组织的方式工作。