Everything is Harness： 从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering
内容提要
文章梳理了从Prompt Engineering、Context Engineering到Harness Engineering的演进，指出Harness指模型之外的环境、工具、状态管理与验证反馈，其价值在于降低任务对模型单次推理正确性的依赖，将不确定的模型能力转化为可验证、可恢复的任务交付。作者区分Base Harness与Domain Harness，认为后者更具机会，并建议通过定义验收标准、分析失败轨迹、补充验证与状态机制来构建领域Harness。
延伸解读
Harness 的本质：把不确定性交给工程系统
文章将 Agent 拆解为 Model + Harness，强调 Harness 是模型之外一切可主动设计的执行机制、上下文管理、工具调用、状态管理与验证反馈。其核心价值不是提升模型单次推理的正确率，而是降低任务成功对模型单次正确性的依赖。通过外部工具、状态管理和验证反馈，把模型不确定的推理能力转化为可验证、可恢复的任务交付能力，从而提高端到端成功率。
Base Harness 与 Domain Harness 的生态位差异
作者区分 Base Harness 和 Domain Harness：前者是模型公司抽象出的最小集合，后者封装特定领域的知识、工具、流程和验收标准。对 Base Harness 的生态位悲观，因为模型公司会优先适配自家 Harness，开源第三方 Harness 若不够薄、不够可替换，容易被官方产品挤压。而对 Domain Harness 更乐观，因为领域知识深且杂，模型公司难以全部覆盖，更可能开放能力让领域专家构建。
构建 Domain Harness 的实践路径
文章建议先定义领域真问题和成功标准，选择熟悉且定制方便的 Base Harness（如 Pi 或 Deepseek Harness），然后让 Agent 尝试任务，失败时分析轨迹。若失败源于缺乏验证机制，应提供验证脚本或 Linter 并要求 Agent 查看结果；若源于缺乏外部状态，应设计状态跟踪机制；若纯粹缺信息，才补充工具或上下文。修改 Prompt 虽是低成本手段，但不应成为默认选项。
从优化表达、信息到优化过程
文章总结三个阶段：Prompt Engineering 优化表达，Context Engineering 优化信息，Harness Engineering 优化完成任务的整个过程。其价值不是让模型永不犯错，而是让系统能发现、修复错误并持续改进。当模型能力提升，真正需要积累的不再是某个 Prompt 或框架技巧，而是可验证、可执行、可复用的工程经验与业务判断，即如何定义正确、验证结果并把经验沉淀为系统。
Q&A
Harness Engineering 到底是什么意思？它和 Prompt Engineering、Context Engineering 有什么不同？
Harness Engineering 指改进围绕模型的一切环境、产物和工具，而非改进模型本身。Prompt Engineering 优化的是表达，Context Engineering 优化的是信息，而 Harness Engineering 优化的是完成任务的整个过程，目标是让系统能发现错误、修复错误并持续改进。
为什么说 Harness 能降低对模型单次推理正确性的依赖？
Harness 通过外部工具、状态管理、验证反馈与错误恢复，把原本需要模型独立完成的部分工作交给工程系统。这样即使模型某次推理或执行出错，系统也能发现问题、提供反馈并引导修复，从而将模型不确定的推理能力转化为可验证、可恢复的任务交付能力，提高端到端成功率。
Base Harness 和 Domain Harness 有什么区别？为什么作者更看好 Domain Harness？
Base Harness 是模型公司基于 Agent 能力抽象出的最小集合；Domain Harness 是将特定领域的知识、工具、业务流程和验收标准封装成 Agent 可执行、可验证的工程系统。作者对 Base Harness 生态位悲观，因为模型公司会优先适配自己的 Base Harness，开源 Base Harness 可能被抛下；而领域知识深且杂，模型公司难以全部覆盖，因此 Domain Harness 机会更大。
为什么不同模型公司要搞自己的 Harness？这对 Benchmark 分数有什么影响？
Harness 存在的目标是帮助模型获得更好的结果。各模型公司训练环境不同，倾向于通过优化 Harness 来帮助自己获得更好的结果和智能。因此很多模型的 Benchmark 必须说清楚用的是什么 Harness 得到的分数，因为 Harness 会影响最终模型的结果。
如何构建一个 Domain Harness？具体步骤是什么？
步骤包括：1）定义领域的真问题和对应的成功标准、验收条件；2）选择一个喜欢/熟悉/定制方便的 Base Harness（推荐 Pi 或 Deepseek Harness，Codex 因 Open Core 也可改造）；3）让 Agent 尝试完成任务，失败时分析 Trajectory，判断是缺乏验证机制、缺乏外部状态，还是缺乏信息输入，并针对性补充验证脚本、状态管理或上下文；4）修改后重新跑回归测评，对比成功率、成本、耗时与副作用。
在分析 Agent 失败轨迹时，如何判断是缺少验证机制还是缺少外部状态？
如果 Agent 无法判断对错最终做错了，说明缺乏验证机制，需要提供验证脚本或 Linter 等方案，并要求 Agent 查看验证结果再推进；如果模型在长程任务中迷失自我，说明缺乏外部状态，需要定义长程任务中必须完成的工作，让 Agent 自己跟进状态（如 Todolist 或 Dynamic workflows）。若两者都不是，才考虑补充信息或设计新工具。
