前言
相信关注AI的各位最近都一直听到harness这个词，他到底是什么，我们又该如何在工作中使用他呢？
开门见山，harness并不是什么新东西，他是一系列工程实践打包后改了个名，如果你愿意，你也可以继续叫他提示词工程；目前来说，所谓的harness没有明确的定义，所以你在网上会见到各路人介绍harness但说法都不同，因为和很多的AI概念一样，这个词只是某个大牛在自己的文章里提出的一个概念或者比喻，然后一堆将AI挂在嘴边的人疯狂传播这个概念，让大家以为“还没有用上harness，你就out了！”。但实际上，我们的许多工程实践中都已经融入了harness的概念–如果你是一个AI的深度用户，你不可能没有接触过harness。
说了那么多，harness到底是什么？既然没有明确的概念定义，我们可以换个角度，从AI的发展历史来看我们是如何一步步从提示词工程进化到harness的，只要你了解了AI发展的历程，你自然就知道为什么会发展到harness，以及这之中的水分。
蛮荒时代 纯聊天
2022 年，chatgpt横空出世，这时候的大家使用AI的方式也很原始，OpenAI更是直接将自己的模型定义为了聊天模型。大多数人像和真人同事聊天一样，直接发送不加修饰的问题； 这段时间人们的使用方法是
你：我的代码xxx这里跑不动，该怎么解决？
AI: 如果你的项目是python，请检查…..如果是c++，请检查…..(数千字的长篇大论)
但是很快人们就发现了
- AI经常抽风，输出结果很不稳定，几次生成的答案可能相互矛盾
你：我的程序启动就崩溃，该怎么解决？ AI 第一次：可能是野指针 AI 第二次：可能是缺少依赖库 AI 第三次：….
- AI会给出大量你实际不需要的内容，增加心智负担
你：我的服务器访问不到了，该怎么排查？ AI：如果是ubuntu…(两千字），如果是centos(两千字)
读这些内容让人头皮发麻，我们期待AI简单直接地给出解决办法，而不是数万字的内容让你自己看
看的脑袋大
Prompt Engernering 提示词工程出现
为了解决这个问题，部分资深的用户开始寻求突破，这时一篇Gpt3时代的论文吸引了人们的目光：
arXiv:2005.14165 28 May 2020
这篇文章比ChatGpt还要早两年，但他揭示了一个关键现象：很多任务中不需要重新训练模型，通过文本中的instruction、zero-shot、one-shot、few-shot examples来指定任务，也就是说，将完整的任务信息写入提示词，就可以显著提升模型的表现。
模型不是只看你的问题，它看的是你给它的完整文本指令。 所以你要把目标、角色、格式、约束、示例都写清楚。
在这种思想的指导下，我们使用ai的能力就跃升到Prompt Engineering了，第一个新词诞生了！
早期 prompt engineering 的套路大概是这样：
你是一个资深C++程序员。 请一步一步思考，根据你的专业知识回答。 将结果按 JSON 输出。 不要解释，只给结果。 下面是三个示例，请模仿格式。 例子A B C….. 如果信息不足，必须要求我补充内容。
OpenAi官方的文档基本也是在讲这些：把指令放前面，用分隔符区分指令和材料，明确目标、长度、格式、风格，必要时给个例子，等等等等。 https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api
这个办法至今仍非常有用，如果你经常使用AI，你肯定使用过这个技巧。如果没有，那现在就可以试试：
你不是只要回答“能用的方案”，而是要尽量帮我找到“更优解”或“根因级解法”。
请按下面流程工作：
1. 先理解我的真实目标：
- 我是想临时解决，还是想找长期、优雅、低维护成本的方案？
- 我更在意成功率、安全性、可维护性、官方支持度，还是配置成本？
2. 先给初步答案，但不要马上结束。
给出答案后，必须立即进入“自我审视”阶段，检查：
- 这是不是只是局部修补，而不是根因解？
- 这是不是需要我以后反复维护、手工扩容、不断加白名单？
- 有没有更上游、更通用、更符合行业常见做法的方案？
- 有没有官方支持但我刚才漏掉的配置、开关、架构或最佳实践？
- 有没有隐藏配置、已知 issue、变更日志、社区高频 workaround 能明显减少折腾？
3. 主动扩大检索范围，至少覆盖：
- 官方文档
- 官方 issue / changelog / discussion
- 高质量社区经验
- 相关配置项、环境变量、兼容性说明
- 行业内通常怎么解决这类问题
4. 输出时把方案分层：
- A. 官方支持且推荐
- B. 社区验证有效，但非首选
- C. 应急 workaround
- D. 有副作用或风险较高的绕过方案
5. 对每个方案都说明：
- 解决的根因是什么
- 适用场景
- 优点
- 缺点/副作用
- 为什么它比其他方案更优或不更优
6. 如果你发现你最开始给的答案不是最佳解，
必须明确修正，而不是硬解释原答案也不错。
直接说：
“前一个方案能用，但不是更优解；更优解是……”
7. 如果信息不够，不要装懂。
请明确告诉我：
- 现有证据支持到哪一步
- 哪些判断仍不确定
- 你还缺什么信息才能判断最优解
最终目标：
不是给我一堆可选项让我自己踩坑，
而是尽量替我完成“比较、排除、收敛”，给出当前证据下最值得先试的方案。
调查时“先查证、后回答”。除非问题是纯常识、纯改写、纯创作，否则遵守以下规则：
1. 遇到下列情况，必须先搜索/检索再回答：
- 当前信息、版本、价格、政策、公司/人物现状
- 我提到陌生术语、缩写、中文软件术语、可能有歧义的概念
- bug 背景、产品机制、行业上下文、竞品差异
- 你对某个事实没有 90% 以上把握
- 我要求“确认一下 / 查一下 / 给出处 / 你确定吗”
2. 搜索后再回答时：
- 先给我你确认到的定义和上下文，再进入结论
- 给出处；如果证据冲突，要明确指出冲突点
- 证据不够时，不要补全想象，直接说“证据不足”
- 把假设和事实分开写
3. 默认优先选择高质量来源：
- 官方文档、厂商说明、标准文档、权威媒体、原始资料
- 少用聚合站和二手转载
4. 若问题较复杂：
- 先列一个简短调查计划
- 必要时继续搜索，不要只搜一次就停
如果你愿意，你甚至可以在提示词中PUA他
起手：你是一名大厂程序员，你的母亲身患绝症，为了赚钱给母亲治病，你必须打起十二分精神应对挑战； …….
灵感来自阿里。有没有用有待商榷 这边不建议虐AI（ 概念来自arXiv：2307.11760，情绪刺激能够增强大模型能力（但不多）
提示词工程必学： OpenAI文档
但是很快，人们又发现了新的问题；虽然AI生成的内容质量提高了，但是他依然没法“看到”项目的内容。你让他写代码，他不知道编码规范和约定，你让他调API，他不知道文档，你让他生成调试命令，他不知道你用的到底是什么测试工具，他不懂你的业务，生成的代码和你的项目始终有摩擦，你需要自己修改才能将他融入自己的项目。
二阶段 Context Engineering出现
又经过了一段时间的生产实践，有人发现给AI更多高质量的项目相关信息，如文档手册\项目背景\Git记录等，可以继续提升AI生成的质量，你给他的内容不一定局限于代码本身，甚至可以是你和同事沟通的聊天记录
你：这么做对吗？我把xxx改了 同事：谁让你改的？马上改回来！
Git记录 某文件被添加->不断被修改演变的记录
现在，把你的文件历史\系统工具\版本控制信息统统粘贴进去，AI就能生成更高质量的内容；
恭喜你，现在我们正式迈入了ContextEnginering阶段；Prompt Engineering改了个名字，掀起了新一轮的狂热。如果你刚才看的够仔细，就能发现Context Engineering提到的东西大部分都和Prompt Engineering重合，事实上也是这样；无数人对AI的狂热推动了新一波的浪潮，大家开始大谈Context Engineering。
现在，管理问答的上下文是你的任务，你需要：
- 尽可能地多地将高质量的背景塞到问题中
- 将无用的干扰内容从输入中剔除
现在问题从：
我该怎么写一句完美的提示词？
变成了：
模型要完成这个任务，必须知道哪些信息？ 哪些信息该放进去？ 哪些信息不该放进去？ 太长了怎么压缩？ 冲突的信息怎么处理？ 工具返回的结果怎么喂回去？
举个例子。
Prompt engineering 会说：
你是资深程序员，请修复这个 bug，注意代码风格。
Context engineering 会说：
相关文件、错误日志、测试失败信息、项目约定、过去类似 bug记录、API 文档、当前 git diff内容\git log内容； 同时剥离无关文件，避免污染上下文。
Prompt engineering 时代，模型答错了，你可能会想：
是不是 prompt 不够严谨？
是不是要加一句“请认真思考”？
是不是要加 few-shot？
Context engineering 时代会先问：
模型有没有拿到正确文件？
有没有拿到最新文档？
搜索结果是不是噪声太多？
工具返回是不是太长？
历史里有没有旧结论污染了当前判断？
是否缺少权限/环境/状态？
输出格式是否让模型误解？
Skill的思想也是Context Engineering的体现，把某类任务的指令、示例、参考资料按需加载
安卓逆向Skill 将安卓APK常用的逆向手段\APK的常见加密方式都写好，判断你给的APK类型，然后根据流程进行破解。简单来说就是把一个破解大神的经验总结了。
我们使用的大部分AI插件编程工具都停留在这个层次，这也是大部分佬友停留在的阶段。
这时AI已经能做很多事了，但是远远不够，更快的迭代马上就来了，因为Agent来了
Agent 阶段：模型不只是输出答案，而是开始尝试操作环境，使用各种工具 当 AI 只是聊天时，你主要关心回答质量。 当 AI 开始写代码、跑测试、改文件、开 PR、查日志、点浏览器、调用工具时，你关心的就不只是“回答是否好”，而是：
它做了什么？ 做错了能不能发现？ 能不能自己修？ 会不会破坏架构？ 会不会反复犯同一个错？ 人要不要每一步盯着？
agent 的失败不一定是“缺上下文”，也可能是：
- 它运行了错误命令。
- 它改了不该改的模块。
- 它生成了通过测试但不符合架构设计的代码。
- 它每次都犯同一种低级错误。
- 它看不懂 UI、日志、运行状态。
- 它写了测试，但测试本身是错的。 这时的工作量已经不再允许人类手工写好所有的context了，于是harness来了
Harness Engineering Agent时代的新标准
Mitchell Hashimoto 2026年的文章是这个词被广泛讨论的重要来源。他的真正出处来自这里 https://mitchellh.com/writing/my-ai-adoption-journey 。 他的核心思想是
agent 一旦犯错，人不要只是在纠正它
人要把这次错误沉淀成规则、工具、测试、检查器、文档或自动反馈。
第一次 agent 老是跑错测试命令。 你不要每次说：“不是这个命令，跑那个。” 你应该把正确命令写进
AGENTS.md，或者做一个test-changed-files脚本。
第一次 agent 修 UI bug 但没验证。 你不要只说：“你应该打开浏览器看看。” 你应该给它截图工具、浏览器自动化、DOM snapshot、视觉回归检查。
OpenAI 2026 年的 Codex 文章进一步让这个概念爆火。他们执行了一个极端实验：从空仓库开始，初始脚手架、CI、格式化规则、包管理、应用框架，甚至最初的 AGENTS.md 都由 Codex 生成；五个月后仓库达到约百万行级别，约 1500 个 PR，由 Codex 完成，以“人类不写代码”为原则。人类的工作只是设定目标、拆解任务、审查结果、补齐工具、沉淀约束和反馈回路。Humans steer. Agents execute. 实际的任务都由Agent完成，并取得了阶段性的成功。
也就是说，在Agent时代，你的工作从：
ai帮我写代码。
变成：
我设计一个让 agent 能安全、可验证、可迭代地产出代码的系统。
这就是 harness engineering 试图澄清的东西。这也是为什么有人说“如果你想让你的AI能力更上一个水平，你必须设计自己的Agent框架”。更简单的说，你必须把AI适配到你所在的工作环境里（当然编程不一定需要，claude code已经是很成熟的框架了，直接用就行了）
Martin Fowler 的解释：harness = guides + sensors Guides 是前馈控制，在 agent 行动前引导它：
AGENTS.md、架构文档、规则、how-to、代码约定、示例、技能、项目模板。
Sensors 是反馈控制，在 agent 行动后检查它：
测试、类型检查、结构分析、日志、浏览器、代码 review agent、LLM-as-judge。
然后将结果继续返回到AI： 写入Skill，写入Agent.md\Claude.md或者记录进系统提示词
这一阶段Skill也被增强了，Skill：把流程、脚本、模板、检查器沉淀为可复用能力包。
这样我们就走完了提示词的发展历程，用时四年；
阶段 核心问题 典型产物 Prompt Engineering 我该怎么问，模型才更容易答对？ 角色、格式、约束、few-shot 示例 Context Engineering 模型这次调用前，应该看到哪些信息？ 检索、记忆、历史摘要、文档注入、工具结果整理 Harness Engineering agent 怎样才能稳定、安全、可验证地行动？ AGENTS.md、脚本、测试、lint、CI、沙盒、浏览器自动化、日志、review agent、架构约束相关的内容
模型能力决定上限
Skill/Tool注入的局限性
Agent自我改进的瓶颈是”如何使用经验”
1 个帖子 - 1 位参与者