Harness 工程过去很长一段时间里大家一提到“大模型怎么用好”第一反应往往是Prompt 怎么写于是Prompt Engineering 成了很多人学习大模型的第一站。我们学习如何提问如何给角色如何写任务如何给示例如何让模型一步一步思考。但随着大模型从“聊天工具”逐渐变成“能写代码、能调用工具、能执行任务的 Agent”问题开始变得更复杂了。你会发现一个 Agent 做得好不好已经不只是 Prompt 写得好不好。它还取决于它能看到什么上下文它能调用什么工具它有没有记忆它有没有自动验证机制它犯错之后系统能不能让它不再犯同样的错这就引出了三个非常重要的概念Prompt Engineering、Context Engineering、Harness Engineering。它们不是互相替代的关系而是一层一层往外扩展的关系Prompt Engineering 研究怎么提问题。Context Engineering 研究怎么给信息。Harness Engineering 研究怎么搭系统。下面我们就从这三个概念开始系统梳理一下大模型 Agent 背后的工程方法论一、Prompt Engineering研究怎么提问题怎么把发给大模型的话说得更清楚、更准确让大模型更容易理解你的真实意图然后给出理想的结果。常用的Prompt Engineering 范式Instruction Prompting 指令式提示词核心是告诉模型你要做什么例如1写一个函数实现两个整数的加法输入两个整数输出它们的和。 2你是一个专业的代码审核员你需要审核这段代码是否符合规范。 这里已经包含了几个Prompt 的重要元素Role、Task、Input、Output。Example-driven 示例式提示词 LLM 最大的特点就是通过例子学习核心是给模型举几个例子让它理解你要做什么。例如英文hello 中文你好 英文goodbye 中文再见 英文thank you 中文Chain-of-ThoughtCoT范式核心是通过提示词强制模型显式展开中间推理而不是直接给出答案。让模型先分析再给结论。例如一个商品100块打8折再减少10块问最终价格是多少 普通prompt直接回答结果模型说70块。 Cot Prompt 请一步一步思考并给出最终答案。 模型会这样输出 原价100 打8折100*0.880 减少10块80-1070 最终价格70块。ReAct 范式核心是在思考的基础上让模型可以调用工具去行动。例如东京今天天气怎么样是不是和跑步 普通prompt直接回答结果模型说天气是晴的适合跑步。 ReAct Prompt 请一步一步思考并给出最终答案。 模型会这样输出 Thought:我需要获取东京今天的天气。 Action:调用天气API获取东京今天的天气。 Observation:返回天气数据 Thought:根据天气数据判断是否适合跑步。 Final Answer:适合跑步。二、Context Engineering研究的是怎么给信息具体来说就是怎么把最合适的内容在最合适的时机放到模型的Context 中。Context里面的内容不仅包括Prompt还有工具列表、对话历史等等。上下文工程的方法1.上下文压缩大模型的上下文窗口再大也不是无限的。如果把所有项目规则、历史对话、设计文档、代码片段一股脑全部塞进去结果往往并不好。因为信息太多时模型可能会抓不住重点忽略关键约束引用过时内容被无关信息干扰输出变得不稳定。所以上下文压缩非常重要。上下文压缩不是简单地“删短”而是把大量信息整理成更高密度的结构。比如把一段长长的会议记录压缩成项目目标 关键决策 未解决问题 接口约定 风险点 下一步行动这样模型看到的是“结构化知识”而不是一堆散乱文本。2.动态检索外部资料很多信息不需要每次都塞进上下文。更好的方式是用到的时候再检索。比如你有一个大型代码仓库不可能每次都把所有代码发给模型。正确做法是让模型根据当前任务动态检索相关文件。要改登录逻辑就检索登录模块。要查接口定义就检索 API 文档。要修数据库问题就检索 Repo 层代码和 schema。这就是 RAG、代码检索、文档检索背后的思路。模型需要的不是“所有信息”而是“当前任务最相关的信息”。3.渐进式披露渐进式披露的意思是不要一开始就把所有复杂信息都丢给模型而是随着任务推进逐步提供信息。比如做一个复杂功能时可以先让模型看需求文档产出设计方案。确认方案后再让它看相关代码。写完代码后再给它测试结果。如果测试失败再把错误日志给它。这个过程就像人类工程师工作一样先理解需求 再阅读代码 再动手修改 再运行验证 再根据反馈修复渐进式披露可以让模型始终聚焦在当前阶段而不是被所有信息同时轰炸。三、Harness EngineeringHarness 原意是马具用来控制大模型的系统。既然是控制大模型那么Harness 就不包含大模型。所以Harness Agent - Model。Agent 除了大模型剩下的所有部分都是Harness。Agent Model Harness五个组件Tools 工具是模型的手脚 Read、Write、Edit、Bash、Grep检索命令这些工具赋予模型予文件系统、终端、网络交互的能力没有工具模型就只能说不能做。Context上下文模型的记忆加载器 CLAUDE.md、系统提示词、对话历史、工具定义这些上下文在每一轮循环被注入模型决定模型看到什么、知道什么。上下文管理的精妙在于它不仅是被动的信息传递还包括主动的压缩和重新注入策略成长。Memory记忆模型的长期存储。跨会话的记忆持久化让模型能记住你的偏好、项目规划和历史决策。CLAUDE.md 显示记忆自动记忆 ~/.claude/memory 存下你的操作习惯没有memory每次对话都从0开始。Hooks 钩子模型的神经反射。事件驱动的自动化机制在工具执行前后发出自定义逻辑。在工具执行前后触发自定义逻辑。比如每次保存文件自动格式化每次提交代码自动测试代码。不需要模型主动决策某些行为会自动发生。Permissions 权限模型的权限管理。模型的安全围栏哪些工具可以自由使用哪些需要人工审核哪些完全禁止。harness 的安全底线。你希望Agent 足够自主以提高效率但又不希望它自主到失控。用Claude 来举例所有不属于Claude 模型的部分都是Harness。比如说写在CLAUDE.md 里面的规则可以使用的工具定时调度机制都是属于Harness 的一部分。Harness 知道了那么Harness Engineering 就是一门专门构建和设计Harness 的技术。换而言之就是除了大模型本身不研究其他什么都研究。具体来说就是研究如何围绕着大模型搭建一个完整可靠的Agent。核心理念就是只要Agent 犯了错你就去改造系统让它不再犯同样的错误。Harness Engineering 实战 来源于OpenAI文章来源https://openai.com/index/harness-engineering/具体内容大概如下。2025年8月OpenAI 内部启动了一项实验完全依靠 AI 从零到一开发一款真实软件产品全程不允许工程师手写一行代码。 依托 AI 自主开发这款产品最终规模达到100万行代码整体耗时约5个月团队仅7人整体开发效率约为传统人工开发的10倍。但这项实验初期进展并不顺利问题不在于大模型不够聪明而是Harness 工程体系没有搭建完善。工程师发现 Agent 很容易偏离目标方向还会反复犯同类错误。 想要让 Agent 稳定、可靠地工作真正的核心关键在于设计完善的 Harness 体系。为此团队做了大量优化工作并撰写专业文章完整记录整个落地过程文中梳理了大量 Harness Engineering 的优化要点。 所有优化方向大致归为三大类上下文管理、验证与反馈、技术债清理。1.上下文管理。如果把所有的项目规范和相关信息都塞进一个 AGENTS.md 文件这个文件体量会变得极其庞大并且会随着用户提问一同发送给大模型。这样会造成两个核心问题。第一个内容冗余过多实际使用效果反而变差。大模型容易淹没在海量信息里陷入迷失只能抓取零散碎片真正关键的核心内容反而被冗余信息覆盖埋没。第二个文件会逐步腐化失效。项目是持续迭代演进的但文件内的规范和信息无法同步及时更新久而久之就会沦为堆满过时信息的垃圾堆Agent 也无法甄别判断哪些内容真实有效。解决办法是把 AGENTS.md 精简压缩到 100 行左右只作为索引目录使用把各类配套规范、相关文档拆分出来和精简后的 AGENTS.md 放在同一目录下做到用到哪一块再单独给 Agent 读取对应板块内容精准度和执行效果会大幅提升。还有一个关键问题项目里很多重要信息其实并不在代码仓库内而是零散存放在历史对话记录、外部文档甚至只留存于个人认知里。但对 Agent 而言只能识别代码仓库内的内容仓库之外的所有信息对它都是不可见、不生效的。所以 OpenAI 强制要求必须把项目所有重要决策、团队约定、规范标准全部纳入代码仓库让代码仓库成为项目唯一的事实来源。2.验证和反馈。做好上下文管理Agent 就具备了编写代码的基础能力。后续核心重点是让 Agent 在写完代码后能够自主验证成果是否正确。如果只能生成代码却无法自我校验就根本没法保证输出正确率。OpenAI 的思路是给 Codex 配置足够完善的工具tools与技能SKILLs。依托这两者Codex 在执行任务的过程中可以随时对自己的输出做自检验证。比如将 Chrome DevTools 接入 Codex 运行环境Codex 就能自主截图、查看 DOM 结构、模拟用户交互操作以此校验 UI 表现是否符合需求。一旦发现问题可就地自查自纠、即时修复全程无需人工介入。同时 OpenAI 还为 Codex 接入了完整可观测性工具栈支持读取日志、追踪运行链路自主定位和排查运行异常。另外OpenAI 把待开发系统做了分层设计并制定严格的单向依赖规则。自上而下依次为UI视图层、Runtime运行时层、Service业务逻辑层、Repo数据访问层、Config配置层、Type类型定义层。上层只能依赖下层严禁反向依赖并通过 Linter 测试机制强制守住架构规范。整套形成闭环流程Agent 生成代码 ➜ Linter / 自动化测试检测 ➜ 发现违规或问题 ➜ 抛出报错 ➜ 把错误信息回传给 Agent 重新修改循环迭代往复直至检测无报错确认代码完全符合架构与编码规范全程自动化闭环无需人工干预。3.技术债务清理。Agent 在大规模生成代码时难免会引入糟糕的设计模式比如重复代码、命名不一致、偏离架构的写法等。这类问题长期累积会直接导致代码仓库变得混乱不堪。OpenAI 的解决方案是对技术债进行定期 “垃圾回收”为 Codex 设置后台定时任务定期扫描整个代码库自动识别偏离规范的代码自动修复并提交持续保证代码质量维持在较高水准。同时对项目文档执行相同机制通过定时任务扫描文档库自动清理过时内容、修正与实际代码不一致的文档保持文档时效性与准确性。结语大模型本身当然重要。模型越强Agent 的上限越高。但在真实工程场景里决定 Agent 是否可靠的往往不是模型一个因素而是整个 Harness 系统。Prompt 写得好可以让模型更懂你的需求。Context 管得好可以让模型更懂当前任务。Harness 设计得好才能让模型稳定、可控、可验证地完成复杂工作。未来的大模型工程不会只停留在“怎么写 Prompt”。它会越来越像软件工程、系统工程和自动化工程的结合。一个成熟的 AI Agent不应该只是“会回答问题”而应该是有工具的执行者有上下文的协作者有记忆的长期伙伴有权限边界的安全系统有反馈闭环的自我修复机器。