别再只改 Prompt 了：Harness Engineering 才是 AI Agent 可靠交付的关键
快速阅读
很多人面对一个频繁失败的 Agent，第一反应是改 Prompt、换模型、加大上下文窗口。但如果 Agent 仍然会忘记决策、误用工具、跳过验证、反复陷入同一循环，那么真正的问题往往不在模型智力，而在模型之外的运行环境。这个环境就是 Harness（运行脚手架 / 控制环境）。
Harness Engineering 的核心不是让模型“更聪明”，而是让模型在一个可观察、可验证、可恢复、可约束的系统中工作。它决定了 Agent 能看到什么、能做什么、哪些状态会被保留、什么算完成、什么时候必须停止。换句话说，Prompt 只定义了指令，Harness 才定义了执行条件。
如果你想快速抓住本文重点，只要记住三句话：
- Agent 反复失败，先别急着怪模型，先检查环境。
- 可靠性来自契约、工具、记忆、验证、权限和追踪，而不是一句更长的提示词。
- 真正能复利的优势，不在 Prompt，而在你为模型搭建的整个系统。
为什么只改 Prompt 往往不够？
模型本身只是一个推理引擎。它可以建议下一步动作，却无法单独构建一个稳定的操作环境。
同一个模型，放在不同环境里，会变成完全不同的 Agent：
- 放进聊天框，它只能回答问题。
- 放进代码仓库，并给它终端、测试、浏览器、项目记忆、隔离工作区和评审闭环，它就可能交付真实软件。
变化的不是模型权重，而是周围的系统。
所以，当 Agent 重复失败时，真正该检查的不是 Prompt 里的形容词，而是它所处的整个执行环境是否被设计清楚。
什么是 Harness Engineering？
Harness Engineering 指的是：围绕模型构建一套让任务能够稳定执行、持续验证、失败可恢复、风险可控制的外部系统。
它与 Prompt Engineering 的区别可以简单理解为：
- Prompt Engineering：告诉模型“该做什么”
- Context Engineering：决定模型“能看到什么”
- Harness Engineering：构建模型“在什么世界里行动”
一个生产级 Harness，真正负责的是把“会做题的模型”变成“能完成工作的 Agent”。
一个生产级 Harness 的七个目标
目标一：把请求变成契约，防止任务悄悄变形
在 Agent 开始行动之前，先把用户请求转换成一个有边界的任务契约。
这样做的意义是：
- 明确任务范围
- 固定完成标准
- 避免 Agent 中途偷偷改写目标
如果没有契约，Agent 很可能完成了另一个相似但不相同的任务，最后还自信宣布成功。
目标二：给 Agent 一张地图，而不是塞满一本手册
Agent 需要项目知识，但不需要一次性吞下所有文档。
更好的做法是提供一个小而清晰的“根指南”，告诉它：
- 需求文档在哪
- 架构说明在哪
- 测试约束在哪
- 不同类型问题应该去哪里查
地图能保留上下文预算，巨型说明书只会消耗它。详细规则应该贴近代码、工具或流程本身，按需加载，而不是全部提前塞进上下文。
目标三：提供正确的工具，并让工具结果可理解
工具不是“给模型几个按钮”这么简单。
它们是模型和现实世界之间的接口。
一个好的工具应该具备：
- 清晰的用途
- 稳定可预测的输出
- 明确的失败状态
- 清楚的权限边界
好工具会在模型开始推理之前就减少歧义；坏工具会逼模型猜测“刚才到底发生了什么”。
目标四：把记忆外置到持久状态里
对话记录不应该是系统的唯一记忆来源。
真正重要的内容应该被写入可持久保存的外部状态，例如：
- 已做出的关键决策
- 中间产物和工件
- 当前失败原因
- 未关闭的风险项
- 下一步待办
这样下一次会话继承的就不是一段模糊复述，而是工作的真实状态。这也是 Agent 能跨上下文重置、崩溃恢复和多人交接继续前进的前提。
目标五：先加传感器，再加自治权
Agent 无法修正它看不见的问题。
因此在增加自动化之前，必须先把质量信号暴露出来：
- 测试
- Lint
- 日志
- 截图
- 指标
- Schema 校验
模型负责产出工件，环境负责产出证据，Harness 负责判断这份证据是否足以继续前进。
目标六：把权限控制放在模型之外
模型可以提出建议，但不应该自己发明规则、自己审批风险、再自己执行副作用。
尤其当动作具有以下特征时，更应该外置授权：
- 成本高
- 不可逆
- 会影响真实用户
- 会修改共享资源
可靠系统会把“能不能做”交给 Harness，而不是交给同一个概率模型临场决定。
目标七：留下可追溯轨迹，并保证本地可恢复
每一次运行都应该留下可读的执行痕迹。
没有轨迹，失败只是谜团；
有了轨迹，失败才能转化为下一次 Harness 改进的输入。
一个好系统至少应保留：
- 任务输入
- 关键决策
- 工具调用结果
- 验证证据
- 失败位置
- 恢复入口
真正有效的做法：把规则写成基础设施
许多团队把重要规则写在文档里，期待 Agent 自觉遵守。结果往往是：它起初遵守，之后某次就忽略了。
更稳妥的做法是把规则编码两次：
- 先写成 Agent 能理解的指导
- 再写成 Agent 无法绕过的机械检查
前者负责解释原因，后者负责执行边界。
这意味着一次失败不只是修复当前输出，而是升级整个系统。
下一次相同类型的问题，不再依赖 Agent “记住教训”，而是由 Harness 替它记住。
循环应该属于 Harness，而不是属于运气
“一直试，直到成功”为止，不是一个真正的控制系统。
有效的迭代循环至少要包含：
- 明确证据
- 有界重试
- 成本预算
- 升级路径
模型可以决定如何修补局部问题，但是否允许继续尝试、还剩多少预算、何时需要人工介入，这些应该由 Harness 负责。
把大脑、双手和历史分开
一个可靠 Agent 更容易被理解和管理，前提是把三件事拆开：
- 大脑：负责推理的模型
- 双手：负责执行动作的工具与沙箱
- 历史：负责保存状态的记忆、工件与审计轨迹
这样做的好处是：
- 沙箱挂掉，历史仍然存在
- 模型升级，工具和权限策略仍然清晰可检查
- 任务恢复时，新会话可以从工件和轨迹重建状态
模型不应该同时兼任文件系统、权限系统、记忆数据库和审计日志。
每次交付都该有一张“变更回执”
当 Agent 结束时，不应该只保留最终答案，还应该留下一个紧凑的“变更回执”，说明结果是怎么得到的。
这能带来几个直接价值：
- 方便比较不同模型版本的行为差异
- 方便定位回归原因
- 方便审计与复盘
- 防止一个看似正确的最终答案掩盖一个失控的过程
从最小 Harness 开始，而不是先造平台
Harness Engineering 不等于一上来就搭一个庞大平台。
正确思路是：先构建一个足以形成闭环的最小系统，只解决当前任务真正暴露出来的失败面。
例如：
- 低风险短任务，可能只需要 Prompt + 人工评审
- 长时间运行、可改代码、可联网、可开 PR 的任务，就需要更完整的 Harness
关键原则是：Harness 的复杂度应该小于它要控制的失败面。
一份适合落地的检查清单
在把 Agent 用到真实工作前，可以先问自己这几个问题：
- 任务是否被转换成了清晰的完成契约？
- Agent 是否知道该去哪里查找正确文档？
- 工具输出是否稳定、可验证、遇错可识别？
- 关键决策和状态是否被持久化保存？
- 系统是否具备测试、日志、截图或其他质量传感器？
- 高风险动作是否由 Harness 而不是模型直接授权？
- 每次运行后，是否留下了可读轨迹与恢复入口？
- 重试是否有预算、边界和升级路径？
- 重要规则是否同时有“指导 + 机械校验”双重实现？
- 最终交付是否附带过程回执，而不只是结论？
如果其中很多问题的答案是否定的，那么换一个更强的模型，往往只会让失败变得更贵，而不会让系统更可靠。
结语
真正的变化正在发生：
- Prompt Engineering 关注模型该做什么
- Context Engineering 关注模型该看到什么
- Harness Engineering 关注模型行动的整个世界是否可靠
模型每个月都可能升级，但工具、测试、状态、策略和追踪系统会持续沉淀，并构成真正可复利的优势。
所以，构建可靠 Agent 的关键问题不再只是“哪个模型最聪明”，而是：
什么样的环境，能让这种智能稳定地产生正确结果？
这就是 Harness Engineering。
🔗 内容整理自用户提供的 X 帖子：Harness Engineering