Harness Engineering 是什么？AI Agent 工程化框架解析

个人主页杨利杰YJlio❄️个人专栏《Windows 疑难杂症与工单复盘案例库》 《Sysinternals实战教程》《WINDOWS教程》 《Windows PowerShell 实战》 《IOS插件分析测试》《超简单用Python让Excel飞起来》让复杂的事情更简单让重复的工作自动化Harness Engineering 是什么AI Agent 工程化框架解析前言最近 AI 编程工具越来越多相关概念也越来越密集提示词工程、上下文工程、AI Agent、ReAct、Claude Code、Cursor、Trae、CLAUDE.md、Spec-Kit以及本文要讲的 Harness Engineering。这些词看起来都和“让大模型更好地干活”有关但它们不是同一层概念。提示词工程解决的是“怎么问模型”上下文工程解决的是“给模型什么信息”而 Harness Engineering 更进一步关注的是如何把提示词、上下文、记忆层、执行层、反馈层、工具调用、规则文件和任务流程组合成一套可运行的 Agent 工程体系。换句话说Harness Engineering 不是单纯写好一段 Prompt也不是简单把资料塞进上下文而是给大模型搭一套“马具 / 鞍具 / 执行框架”让模型在真实工程任务里更稳定、更可控地工作。一、为什么叫 Harness Engineering视频开头引用了一篇关于 Harness Engineering 的文章标题里出现了“agent-first world”。这说明这个概念不是单纯围绕聊天模型展开而是和 Agent 化的开发方式有关。在传统使用大模型的方式里我们通常是写一段提示词让模型返回一段答案。到了 Agent 场景模型不只是回答问题还要读取文件、理解项目、调用工具、执行命令、接收反馈再继续下一步。“Harness”这个词可以理解为马具、缰绳、鞍具。放到 AI 语境里可以理解成给大模型套上一套工程结构让它不是自由发挥而是在可控范围内做事。说白了大模型本身像一匹能力很强的马但如果没有缰绳、路线、骑手和反馈机制它不一定能稳定到达目标。Harness Engineering 关注的就是这套控制和执行结构。从这张图可以看出提示词工程、上下文工程和 Harness Engineering 是逐层扩展的关系。提示词工程偏输入表达上下文工程偏信息组织Harness Engineering 则把模型、工具、记忆、执行和反馈都纳入同一个 Agent 体系里。二、先从大模型说起LLM 只是能力底座视频先把问题拉回大模型本身。现在很多 AI 编程工具看起来很强能读项目、写代码、改文件、跑命令但底层仍然离不开大模型。大模型可以粗略理解成一个模型文件例如 gpt-5.bin、claude-4.bin 这类模型权重。这个类比不一定对应真实部署细节但能帮助理解模型本身只是能力来源。用户并不是直接打开这个模型文件而是通过推理服务调用它。模型负责理解、推理和生成但它不会天然知道你的项目结构、代码规则、历史任务和当前执行状态。真正对外提供服务的是推理服务。用户把问题发给推理服务推理服务调用大模型生成结果再把答案返回。这说明 LLM 只是底座。它能生成文本和代码但真实工程任务需要的远不止生成能力。后面要解决的问题包括如何提问、给什么上下文、怎么调用工具、怎么读取文件、怎么运行命令、怎么根据反馈继续调整。三、提示词工程重点是“怎么问模型”提示词工程解决的第一个问题是怎么把用户需求写清楚让模型更容易理解。如果用户只是说“帮我优化一下项目”模型并不知道要优化性能、结构、代码风格还是修复 bug。更好的提示词应该说明项目背景、目标、限制条件、输出格式和验收标准。提示词会被提交到推理服务再交给大模型处理。这个过程中提示词相当于用户给模型的任务说明。说明越清楚模型越容易生成接近预期的结果。在实际使用中提示词可能会变得很复杂。例如要求模型扮演某个角色、按照固定格式输出、遵守某些规则、处理某类文件、避免修改某些内容。这些都属于提示词工程的范围。但提示词工程有明显边界。它主要解决“怎么表达请求”的问题不能自动解决模型不知道项目结构、拿不到代码文件、无法运行命令、无法验证结果这些问题。所以提示词工程是基础但不是 Agent 工程的全部。四、上下文工程重点是“给模型什么信息”接下来就是 Context Engineering也就是上下文工程。它和提示词工程经常被混在一起但两者不是一回事。提示词更像“我要模型做什么”上下文更像“模型做这件事前需要知道什么”。举个例子用户让模型修改一个 Python 项目提示词可以写“请帮我修复登录接口报错”。但上下文要包含报错日志、相关文件、接口实现、数据库字段、调用链路、最近修改记录等信息。如果模型只看到一句需求而不知道项目文件、历史代码、接口文档、业务规则和已有错误它就很难做出可靠判断。上下文工程要做的就是把对当前任务有用的信息找出来、整理好再交给模型。在更大的 Agent 系统里上下文工程只是其中一部分。它解决信息输入问题但并不直接解决执行问题。模型要真正完成任务还需要工具、执行层和反馈层配合。五、上下文工程怎么做召回、筛选、压缩、组织视频把上下文工程拆成几个动作。第一步是找到相关信息第二步是筛掉无关信息第三步是把剩下的信息整理成模型能理解的结构。召回的信息可能来自 RAG、记忆、代码文件、文档、网页、接口返回结果等。比如模型要修复一个 bug就需要先找到报错日志、相关代码、配置文件和最近修改记录。召回阶段的重点是“找得到”。如果相关信息没被召回模型后面再聪明也只能猜。但召回之后不能把所有东西都塞给大模型。信息越杂模型越容易跑偏。它可能把无关文件当成关键线索也可能在长上下文里忽略真正重要的内容。筛选和压缩就是把无关内容去掉把重要信息压缩成更适合模型读取的形式。例如只保留关键报错、相关函数、配置差异、测试结果而不是把整个仓库都丢进去。最后还要组织结构。把信息按照“任务目标、相关文件、错误现象、已有尝试、限制条件、期望输出”的顺序整理会比杂乱堆放更容易让模型正确处理。Cursor、Claude Code、Trae 这类工具本质上都在做类似的事情它们不仅接收用户提示词还会读取项目上下文、分析文件结构并把相关信息提供给模型。六、只有提示词和上下文还不够还需要执行层到这里系统已经有了大模型、提示词工程和上下文工程。但真实工程任务仍然没有完成。原因很简单很多任务不只是“回答”还需要“执行”。例如读取文件、搜索项目、运行命令、调用外部工具、修改代码、执行测试这些都不是模型单靠文本生成就能完成的。所以 Agent 系统需要加入工具层。例如 Bash、文件系统、MCP 工具、搜索工具、测试工具等。这些工具让模型可以从“生成建议”进一步走向“执行动作”。执行层负责把模型的计划变成真实操作。模型判断下一步要读取某个文件执行层就去读文件模型判断要运行测试执行层就去执行命令模型判断要修改代码执行层就把变更写入文件。没有执行层模型最多是“建议怎么做”。有了执行层Agent 才能真的推进任务。七、ReAct让模型进入“思考 行动”循环视频接着讲 ReAct。ReAct 可以理解成 Reasoning Acting也就是“思考 行动”。模型不是一次性输出答案而是先根据上下文推理下一步要做什么再调用工具执行动作拿到结果后继续判断下一步。这个结构让 Agent 不再只是聊天机器人而是一个能持续处理任务的系统。它可以分析当前状态执行动作读取反馈然后继续推进。一个典型流程是用户提出目标模型根据上下文制定下一步调用工具执行执行结果返回模型模型再决定是否继续、调整还是结束。这就是 AI Agent 和普通问答式大模型的重要区别。八、CLAUDE.md把项目规则写进上下文即使模型上下文窗口越来越大也不代表可以无限堆资料。上下文太大仍然会带来问题模型可能抓不住重点也可能误用过时信息。视频中提到 CLAUDE.md。它可以理解成给 Claude Code 或类似 Agent 工具看的项目规则文件。比如项目采用什么目录结构哪些文件不能改编码规范是什么运行测试命令是什么生成代码时要遵守什么约束都可以写进 CLAUDE.md。当模型执行任务时规则文件会成为上下文的一部分。这样 Agent 在修改项目时就不会完全依赖临时提示词而是能读取项目长期规则。这说明上下文工程不只是临时拼接材料也包括长期维护项目级规则。规则越清楚Agent 执行任务时越不容易跑偏。九、AI Agent 的完整结构记忆层、执行层、反馈层更完整的 Agent 不只包含大模型和上下文还会包含记忆层。记忆层负责保存任务历史、长期信息和中间状态。例如一个 Agent 正在重构项目它需要知道已经改了哪些文件、哪些测试已经跑过、哪些问题还没解决。这些信息都不能只靠一次提示词保存。一个成熟 Agent 不只是“模型 提示词”。它需要同时具备上下文管理、工具调用、执行反馈、任务分解和规则约束。反馈层只是其中一部分负责把执行结果、错误信息、测试结果再反馈给模型。如果测试失败模型需要知道失败原因如果命令报错模型需要读取错误输出如果文件修改不符合预期模型需要回退或重新生成。如果任务很大Agent 还需要把大任务拆成多个小任务逐步推进。比如先分析项目结构再定位模块再制定修改计划再改代码再跑测试再根据结果继续调整。视频里把编辑层、执行层、反馈层、记忆层放在一起说明一个成熟 Agent 不是单点能力而是多层协作。这已经明显超出了“写一段好提示词”的范围。十、Harness Engineering把整套 Agent 结构工程化到这里Harness Engineering 的位置就清楚了。它比提示词工程和上下文工程更上层。提示词工程解决如何提问上下文工程解决给模型什么信息Harness Engineering 解决的是如何把模型、提示词、上下文、记忆、执行、反馈、工具、规则和任务流程组织成一套完整工程结构。落地时不能只关注模型输出是否聪明还要看整个系统能否稳定运行。包括任务怎么拆资料怎么取工具怎么调结果怎么验失败后怎么回退。一个可落地的 Harness Engineering需要先写清楚项目背景、目标和规则。模型不是凭空工作它需要知道当前项目是什么、任务目标是什么、哪些规则不能破坏、哪些结果必须验证。可以把 Harness Engineering 理解成给大模型装上“马具”。模型是马提示词是指令上下文是资料工具是手脚反馈是方向修正Harness Engineering 就是把这些部件绑成一套可控系统。十一、CLAUDE.md、Spec-Kit 和任务流程CLAUDE.md 这类规则文件是 Harness Engineering 落地中的一个典型入口。它把项目规则变成模型可读取的长期上下文。如果每次都靠用户临时说明项目规则Agent 很容易遗漏。把规则沉淀到文件里可以让 Agent 每次执行任务时都遵守同一套约束。视频后半段还提到 Spec-Kit 和 Spec Driven Development。它们强调先把需求规格写清楚再拆任务、再实现。这类思路和 Harness Engineering 的目标一致减少模型自由发挥让 Agent 工作流更可控、更可验证。随着 AI 编程工具继续发展后续可能会出现更多工程化方案。它们的共同方向不是让模型随便写而是把需求、规则、上下文、工具、执行和验证组织成更稳定的流程。十二、最终总结Harness Engineering 到底解决什么Harness Engineering 可以理解成给大模型装上一套工程体系。它不是简单写一句 Prompt也不是无限堆上下文而是设计一套完整的 Agent 运行环境。把三者关系压缩一下概念核心问题典型作用提示词工程怎么问模型把任务目标、输出格式、约束条件说清楚上下文工程给模型什么信息召回、筛选、压缩、组织任务相关资料Harness Engineering怎么让模型稳定执行任务整合提示词、上下文、记忆、工具、执行层、反馈层和规则文件如果只是让模型回答一个问题提示词工程可能就够了。如果要让模型理解项目并基于资料回答就需要上下文工程。如果要让模型像 Agent 一样持续执行复杂工程任务就需要 Harness Engineering。所以它的核心价值不是“让模型更会说”而是让模型更能在真实工程环境里稳定做事。点击回到顶部