Harness Engineering并非Prompt Engineering或Context Engineering的新名词，而是设计AI Agent外部控制系统的工程实践。它关注点在于如何让AI在真实环境中持续行动，看见事实、执行动作、接收反馈、保存进度，并在失败后修正行动。Harness Engineering通过构建一套包含目标、上下文、工具、权限、状态、验证、反馈和生命周期的闭环系统，使Agent不仅能生成合理答案，更能稳定完成真实任务。核心在于将经验转化为默认能力，实现AI从“聊天”到“行动”的转变，让AI Agent在真实世界中更高效、稳定地工作。

---

最近，“Harness Engineering”这个词被越来越频繁地提起。

有人把它理解成 Prompt Engineering 的新说法，有人说它是 Context Engineering 的升级版，也有人把它讲成一套 Agent 最佳实践。

但如果从李宏毅老师的课程出发，最值得抓住的不是术语本身，而是那条更朴素的主线：

有时候，语言模型不是不够聪明，它只是缺少人类为它设计好的行动环境。

一个模型会写代码，不代表它知道文件在哪里；一个测试脚本存在，不代表它会主动运行；一个规则写在文档里，不代表它会稳定遵守；一次任务成功，也不代表下一次不会在同一个地方跌倒。

所以，Harness 要解决的不是“怎样让模型回答得更漂亮”，而是另一个更工程化的问题：

当一个概率模型不再只是聊天，而是要读文件、调用工具、修改代码、运行测试、观察日志、操作浏览器、跨会话推进任务时，我们怎样让它持续看见事实、执行动作、接收反馈、保存进度，并在失败后修正下一轮行动？

从这个角度看，Harness 可以先被理解成：

模型外部的控制系统。

它把意图、上下文、工具、权限、状态、验证、反馈和生命周期组织成闭环，让 Agent 不只是“生成一个看起来合理的答案”，而是更稳定地把真实任务做完。

这篇文章想讨论的，就是 Harness 到底是什么，它和 Prompt、Context 有什么区别，以及为什么它会成为 Agent 时代越来越重要的一种工程能力。

一、问题从来不是“模型不够聪明”这么简单

李宏毅老师在课程里讲了一个很关键的例子：让一个小模型修复 email parser 的 bug。

任务本身并不复杂：目录里已经有 parser.py 和 verify.py，模型要修改 parser，然后让验证脚本通过。

但模型一开始失败了。它没有先看目录，也没有读真实文件，而是根据题目描述幻想了一个 parser.py，又幻想自己已经验证成功。表面上看，这很像“模型太弱”。

可是，当人类只补上几条工作原则：

• • 先 ls 看目录里有什么；
• • 再 cat 读取真实文件；
• • 修改后运行 verify.py；
• • 用验证结果判断任务是否完成；

同一个模型就能把任务做出来。

这件事重要的地方在于：模型并不是完全不会写代码，它缺的是一条可执行、可观察、可验证的行动链路。

很多 Agent 失败也是这样。问题不一定出在某一个瞬间，而是出在链路断了：

• • 文件在磁盘里，不等于模型已经看见；
• • 规则在团队脑子里，不等于模型已经知道；
• • 测试脚本存在，不等于模型会主动运行；
• • 输出看起来合理，不等于任务真的完成；
• • 上一轮留下的错误状态，还可能被下一轮继续继承。

所以，Agent 的失败经常不是一个点，而是一条链。

这也是 Harness 出现的根本原因。

当 AI 只是聊天时，我们主要优化 prompt：怎么问，怎么表达，怎么让它回答得更好。

但当 AI 要读文件、改代码、查日志、跑测试、开浏览器、跨会话推进任务时，只优化 prompt 就不够了。因为这时的关键问题已经不是“它会不会回答”，而是“它能不能在真实环境里持续行动，并且知道自己做对了没有”。

你需要一套外部系统，让它能看见事实、执行动作、接收反馈、保存进度，并在犯错后把经验写回下一轮默认存在的规则、工具或测试里。

这套系统，就是 Harness。

二、Prompt、Context、Harness 都是什么？

先用一个粗略的三层区分：

Prompt Engineering 关心的是提问：怎么去问。

Context Engineering 关心的是：给模型看什么。

Harness Engineering 关心的是：怎样设计一个多轮行动系统，让模型不只是回答，而是把任务真的做完。

Prompt 像一句指令。

Context 像模型眼前的材料。

Harness 则更像一整套工作环境：任务地图、状态文件、工具接口、权限边界、测试反馈、日志观测、交接机制、失败复盘。

李宏毅老师在课程里也用了类似区分：Prompt Engineering 更接近用语言影响模型输出；Context Engineering 是把完成任务所需的信息组织进模型上下文；而 Harness Engineering 要处理的是一个更大的问题：模型不再只是一次输入、一次输出，而是在多轮互动中调用工具、观察结果、继续行动，直到任务完成。

这也是为什么 Harness 不是 AGENTS.md。

AGENTS.md 很重要，但它只是 Harness 的一部分。它能告诉 Agent 应该怎么行动，却不能保证 Agent 一定照做。李宏毅老师也提醒过，自然语言规则可以影响模型的认知框架，但没有 100% 强制力。OpenAI 的实践也说明，AGENTS.md 更适合做地图，而不是百科全书。

真正可靠的 Harness，必须把尽可能多的“希望它这样做”，变成“系统默认会这样约束它”。

比如：

• • 不只是告诉它“要跑测试”，而是 completion 前检查测试结果；
• • 不只是告诉它“不要越权”，而是用工具权限、沙箱、人工审批拦住高风险动作；
• • 不只是告诉它“别忘了进度”，而是把 feature list、progress notes、handoff artifacts 写到磁盘；
• • 不只是告诉它“别破坏架构”，而是用 lint、结构测试、CI 把边界机械化。

自然语言规则是软控制，有概率性；系统约束、权限边界、状态持久化、测试反馈，才会让控制变硬。

Prompt 让模型知道“你要什么”，Context 让模型看见“它该依据什么”，Harness 则进一步规定：它能用什么工具、怎么验证自己、失败后怎么恢复、下一轮怎么接上，以及哪些动作必须被系统拦住。

三、Harness 的本质：控制回路

如果从第一性原理看，Harness 可以理解成一个控制回路。

李宏毅老师在课程里讲 Harness 时，核心不是在讲某个具体工具，而是在讲：人类如何通过语言规则、工具边界和工作流程，去驾驭一个会多轮行动的模型。

Martin Fowler 在《Harness engineering for coding agent users》里也用了类似框架：Guides 是行动前的前馈控制，Sensors 是行动后的反馈控制。OpenAI 的 Harness 文章最后也把难题落在了 environment、feedback loops 和 control systems 上。

所以 Harness 不是“多写几句 prompt”，而是把 Agent 放进一个可引导、可观察、可修正的系统里。

这个系统至少有七个环节：

1. 1. 人定义目标、边界和验收标准。
2. 2. Guides 在行动前预防错误，例如 AGENTS.md、架构文档、spec、示例、操作规范。
3. 3. Agent 在环境中执行 Reason -> Act -> Observe 循环。
4. 4. Tools 让模型能读文件、写文件、跑命令、查 API、操作浏览器。
5. 5. Sensors 捕捉偏差，例如 tests、lint、typecheck、e2e、logs、metrics、trace、review agent。
6. 6. State 保存跨会话真相，例如 feature_list.json、progress notes、handoff artifacts、git history。
7. 7. Harness update 把失败写回规则、工具、测试或文档，让同类错误以后更难重复发生。

这跟传统控制系统很像。

一个控制系统要有目标状态、当前状态、传感器、执行器、反馈信号和修正机制。Harness 也是一样：目标来自人，执行者是 Agent，执行器是工具，传感器是测试、日志、指标和评审，状态保存在文件和代码仓库里，反馈再反过来更新下一轮行动方式。

只不过这一次，被控制的不是蒸汽机转速，也不是 Kubernetes 集群副本数，而是一个能读写文件、调用工具、修改真实系统的 AI Agent。

这也是为什么 Harness Engineering 的核心动作不是“把 prompt 写得更抽象”，而是：

找到当前 Agent 行动链路中的断点，然后把断点工程化地补成下一轮默认存在的能力。

email parser 那个例子就是最小版本的 Harness：模型一开始不知道先看文件，于是幻想了一个文件；人类补上“先 ls、再 cat、修改后运行 verify.py”这些工作原则后，它就能从真实环境里观察、行动、验证，最后完成任务。

OpenAI 和 Anthropic 的实践，只是把这个最小回路扩展到了真实软件工程里：把知识放进结构化文档，把验证接到测试、浏览器、日志和指标，把进度写进外部状态，把失败再沉淀成新的规则和工具。

所以，Harness 不是让 Agent “更听话”的单点技巧。

Harness 是把一次偶然成功，改造成一个可以反复运行、持续修正、逐步变稳的系统。

四、为什么“更多上下文”不是答案？

很多人会把 Agent 犯错归因于“上下文不够”。

但 Harness Engineering 里一个很关键的判断是：问题通常不是“上下文越多越好”，而是上下文必须在正确时间、以正确粒度、以 Agent 能使用的形式出现。

OpenAI 在《Harness engineering: leveraging Codex in an agent-first world》中讲过一个很典型的经验：他们早期试过把大量规则塞进一个巨大的 AGENTS.md，后来发现这种做法会失败。原因不是规则本身没用，而是单体规则文件会挤占任务、代码和相关文档的上下文空间；当所有东西都被写成“重要规则”时，真正重要的信息反而失焦；而且这种文档会随着项目变化快速腐烂，也很难被自动检查。

所以他们后来的做法不是把 AGENTS.md 当百科全书，而是把它当目录。短小、稳定的入口文件负责告诉 Agent：你现在站在哪里、该去哪里找更深的事实。真正的系统知识，则沉淀在结构化的 docs/ 目录、执行计划、质量文档、架构文档、测试和可观测性工具里。

Harness 不是把上下文堆满，而是设计一种“渐进披露”的信息系统：

• • 常驻文件像地图，帮助 Agent 定位；
• • 细节文档按需读取，避免一上来淹没模型；
• • 测试、日志、指标要能被 Agent 直接观察；
• • 计划、进度、决策要变成磁盘上的状态工件；
• • 旧的、不再真实的文档要被清理和校验；
• • 已完成任务不要永远堆在主上下文里。

这也解释了为什么 Anthropic 在长任务 Harness 中强调 feature list、progress notes、handoff artifacts，以及每轮开始时的基础测试 / 启动检查。

长任务真正缺的不是无限上下文，而是可恢复、可交接、可验证的外部状态。

一个 Agent 会话结束了，下一轮不能靠“记忆力”接上，而要靠磁盘上的状态工件接上：哪些功能已完成、哪些还没测、当前代码能不能跑、上一轮留下了什么判断、下一轮应该从哪里开始。否则，上下文一旦重置，Agent 就会重新猜测。

这就是 Harness 和普通 Prompt 的关键差别之一。

Prompt 试图在一次对话里说清楚一切；Harness 则承认一次对话装不下真实世界，于是把真实世界拆成可读取、可验证、可恢复的外部结构。

五、Generator / Evaluator 有用，但不能神化

李宏毅老师的课程里讲到，很多 Harness 会把任务拆成 Planner / Generator / Evaluator 三个角色：

• • Planner 负责把目标拆成计划；
• • Generator 负责生成方案或实现代码；
• • Evaluator 负责检查结果、给出反馈。

这个模式很有价值。因为实现者往往会对自己的输出太宽容，尤其是在没有明确外部反馈时，模型很容易把“看起来差不多”误判成“已经完成”。把“做事的人”和“验收的人”拆开，本质上是在 Harness 里制造一个反馈回路：Generator 先产出，Evaluator 再根据标准检查，失败就把证据和反馈交回去继续迭代。

Anthropic 在《Harness design for long-running application development》里也用了类似结构：Planner 把一句话需求扩展成完整规格，Generator 按功能推进实现，Evaluator 则通过 Playwright MCP 操作真实应用，检查 UI、API 和数据库状态，并按产品深度、功能完整性、视觉设计、代码质量等标准打分。

但这里最容易被误解的一点是：

Evaluator 不是天然客观。

Anthropic 在同一篇文章里明确说过，Claude “开箱即用”并不是一个好的 QA agent。早期运行中，它会发现真实问题，但随后又说服自己这些问题“不重要”，最后仍然批准结果；它也会倾向于浅层测试，而不是主动探测边界情况。因此，Evaluator 不是换一个模型名字就自动可靠，它本身也需要被设计、校准和约束。

这意味着 Evaluator 也需要自己的 Harness：

• • 它要有明确的验收标准，而不是凭感觉说“好”或“不好”；
• • 它要能操作真实环境，例如打开页面、点击功能、调用接口、检查数据库；
• • 它要能看日志、跑测试、截屏、记录复现路径；
• • 它要把判断写成 evidence，而不是只给一句结论；
• • 它要知道哪些失败必须升级给人；
• • 它的提示词、评分标准和测试深度也要根据真实误判不断修正。

更重要的是，Evaluator 的价值不是固定不变的。

Anthropic 后来在同一篇文章的 harness 迭代中提到，随着模型能力提升，原来某些必要的脚手架可能会变成额外成本。比如新模型能更稳定地完成某些任务后，逐 sprint 检查、上下文重置、复杂分工就不一定都还划算。Evaluator 什么时候值得保留，取决于任务是否已经超出当前 Generator 单独可靠完成的边界。

所以，Planner / Generator / Evaluator 不是一套万能解法，而是一种工程化分工：用计划降低任务混乱，用生成推进产出，用验证制造反馈。

真正重要的不是“多放一个 Evaluator”，而是让验证流程本身变得可执行、可观察、可复盘。

不要用“另一个模型”替代验证，要用“另一个被约束的验证流程”提高可靠性。

六、结语：把经验变成默认能力

Harness Engineering 最值得关注的地方，不是它发明了一个新名词，而是它影响了我们使用 AI Agent 的方式。

过去，我们很容易把 AI 当成一个 chat 窗口来使用：思考怎么问得更清楚，怎么补充更多背景，怎么让它给出一个更好的答案。

但 Agent 时代的问题变了。

当 AI 开始读文件、改代码、跑测试、查日志、操作浏览器、跨会话推进任务时，关键不再只是“这一轮怎么问”，而是“怎样设计一个系统，让它每一轮都更不容易走偏”。

这就是 Harness 的意义：把一次次使用里的经验，沉淀成下一次默认存在的能力。

如果 Agent 总是忘记跑测试，就把测试接进完成条件。

如果 Agent 总是读不到关键背景，就把知识整理成地图和按需读取的文档。

如果 Agent 总是在长任务里丢失进度，就把 feature list、progress notes、handoff artifacts 写到磁盘。

如果 Agent 总是对自己的结果太宽容，就让验证流程变得更明确、更可观察、更可复盘。

Prompt 让模型回答得更好，Context 让模型看见更多事实，Harness 让 Agent 在真实世界里把事做完。

当 AI 从“聊天”走向“行动”，工程的重点就不再只是写一句更好的提示词，而是设计一个能持续校正它的系统。

结语：抓住大模型时代的职业机遇

AI大模型的发展不是“替代人类”，而是“重塑职业价值”——它淘汰的是重复性、低附加值的工作，却催生了更多需要“技术+业务”交叉能力的高端岗位。对于求职者而言，想要在这波浪潮中立足，不仅需要掌握Python、TensorFlow/PyTorch等技术工具，更要深入理解目标行业的业务逻辑（如金融的风险控制、医疗的临床需求），成为“懂技术、懂业务”的复合型人才。

无论是技术研发岗（如算法工程师、研究员），还是业务落地岗（如产品经理、应用工程师），大模型都为不同背景的职场人提供了广阔的发展空间。只要保持学习热情，紧跟技术趋势，就能在AI大模型时代找到属于自己的职业新蓝海。

最近两年大模型发展很迅速，在理论研究方面得到很大的拓展，基础模型的能力也取得重大突破，大模型现在正在积极探索落地的方向，如果与各行各业结合起来是未来落地的一个重大研究方向

大模型应用工程师年包50w+属于中等水平，如果想要入门大模型，那现在正是最佳时机

2025年Agent的元年，2026年将会百花齐放，相应的应用将覆盖文本，视频，语音，图像等全模态

如果你对AI大模型入门感兴趣，那么你需要的话可以点击这里大模型重磅福利：入门进阶全套104G学习资源包免费分享！

扫描下方csdn官方合作二维码获取哦！

给大家推荐一个大模型应用学习路线

这个学习路线的具体内容如下：

第一节：提示词工程

提示词是用于与AI模型沟通交流的，这一部分主要介绍基本概念和相应的实践，高级的提示词工程来实现模型最佳效果，以现实案例为基础进行案例讲解，在企业中除了微调之外，最喜欢的就是用提示词工程技术来实现模型性能的提升

第二节：检索增强生成（RAG）

可能大家经常会看见RAG这个名词，这个就是将向量数据库与大模型结合的技术，通过外部知识来增强改进提升大模型的回答结果，这一部分主要介绍RAG架构与组件，从零开始搭建RAG系统，生成部署RAG，性能优化等

第三节：微调

预训练之后的模型想要在具体任务上进行适配，那就需要通过微调来提升模型的性能，能满足定制化的需求，这一部分主要介绍微调的基础，模型适配技术，最佳实践的案例，以及资源优化等内容

第四节：模型部署

想要把预训练或者微调之后的模型应用于生产实践，那就需要部署，模型部署分为云端部署和本地部署，部署的过程中需要考虑硬件支持，服务器性能，以及对性能进行优化，使用过程中的监控维护等

第五节：人工智能系统和项目

这一部分主要介绍自主人工智能系统，包括代理框架，决策框架，多智能体系统，以及实际应用，然后通过实践项目应用前面学习到的知识，包括端到端的实现，行业相关情景等

学完上面的大模型应用技术，就可以去做一些开源的项目，大模型领域现在非常注重项目的落地，后续可以学习一些Agent框架等内容

上面的资料做了一些整理，有需要的同学可以下方添加二维码获取（仅供学习使用）