Harness Engineering 是一种围绕 AI 模型构建运行环境的工程方法旨在解决 Agent 在长链路任务中常出现的失忆、重复劳动、误用工具等问题。通过设计模型周围的运行环境包括系统提示词、工具描述、文件系统、沙箱、状态管理、Lint、测试和恢复逻辑等让 Agent 能够规划、执行、观察、验证、恢复并将每次失败沉淀为下一次可复用的系统能力。关键步骤包括将仓库知识转化为可读取、可验证的事实库将规则从“建议”升级为“机械约束”建立“写完—运行—观察—修复”的自验证闭环以及设计状态机进行失败恢复。最终目标是持续优化 Harness让模型在复杂任务中稳定输出高质量结果。Harness Engineering为什么模型很强Agent 还是经常做不稳过去大家遇到 AI 输出不理想第一反应是把提示词再写长一点Agent 出现后工程师又开始研究怎样把检索结果、记忆和工具说明塞进上下文。可到了真正的长链路任务里提示词和上下文都没有明显问题Agent 依然会忘目标、重复劳动、提前宣布完成、误用工具甚至把错误模式一遍遍复制进代码库。Harness Engineering 解决的正是这一层问题它不再只优化模型“看到什么”而是设计模型周围的运行环境让 Agent 能够规划、执行、观察、验证、恢复并把每次失败沉淀为下一次可复用的系统能力。一句话理解 模型像一名能力很强、但每次上班都会失忆的新同事Harness 则是任务系统、公司文档、开发环境、测试平台、权限制度、交接记录和质量管理的总和。图 1 Prompt、Context 与 Harness 的控制范围逐层扩大一、这个概念从哪里来2026 年 2 月Mitchell Hashimoto 在《My AI Adoption Journey》中把自己长期使用编码 Agent 的方法称为“harness engineering”。他的核心做法很直接每当 Agent 犯一次错误就花时间把解决方案工程化让同类错误以后不再依赖人类临时提醒。可能是补一条仓库规则也可能是新增 Lint、自动化测试、Git Hook 或验证工具。几天后OpenAI 发布 Codex 团队的官方复盘把 Harness Engineering 推向更广泛的工程讨论。OpenAI 报告称一个小团队从空仓库开始让 Codex 生成应用代码、测试、CI、文档、可观测性和内部工具五个月后仓库规模约 100 万行期间约有 1,500 个 PR 被创建并合并。这里真正重要的不是“AI 写了多少行代码”而是人类工程师把工作重心转向了环境设计、意图描述和反馈回路。图 2 OpenAI Codex 团队公开的 Harness 实验数据二、Harness 到底是什么LangChain 给出了一个很容易记住的表达Agent Model Harness。模型负责推理和生成模型之外的系统提示词、工具描述、文件系统、沙箱、浏览器、状态管理、子 Agent 编排、上下文压缩、Lint、测试和恢复逻辑都属于 Harness。图 3 模型只是 Agent 的“大脑”Harness 才让它真正拥有工作能力因此Harness 不是某一个 SDK也不是把 ReAct 循环写出来就结束。它更像是一套运行时决定 Agent 在哪里执行、能访问什么、怎样找到知识、如何保存进度、什么时候重试、如何证明任务完成以及什么情况下必须停下来找人。图 4 生产级 Harness 的八层工程能力三、Harness Engineering 的核心不是“约束 AI”而是“让错误形成复利”最容易犯的错误是每次都只修当前结果。例如 Agent 漏跑测试人类提醒一句“下次记得测试”Agent 又违反架构边界再补一句“请遵循分层设计”。这些提醒只能影响当前会话一旦上下文结束团队又回到原点。Harness 的思路是把失败变成系统改造信号漏跑测试就把测试纳入完成门槛误用 API就提供可搜索的版本化文档越权访问就通过权限层直接拒绝重复产生同类坏代码就把规则写成结构测试或 Lint。这样每一次失败都会增强环境。图 5 从“修一次结果”转向“永久修复环境”四、第一块地基把仓库知识变成可读取、可验证的事实库OpenAI 最早也尝试过把所有规范都写进一个巨大的 AGENTS.md但很快发现四个问题它挤占任务上下文规则太多后没有重点内容容易过时单个大文件很难做完整性和新鲜度检查。他们后来把 AGENTS.md 控制在大约 100 行让它承担“目录”的作用真正的架构、产品规格、执行计划、质量标准、安全要求和生成式事实都放进结构化 docs/ 目录并把仓库内版本化文档视为 System of Record。Agent 先读短入口再根据任务按需深入。图 6 AGENTS.md 做地图docs/ 做事实库图 7 渐进式披露只把当前任务真正需要的信息送进上下文AGENTS.md 应该写什么一个实用的 AGENTS.md 不需要复制 README、代码风格手册和所有框架文档。它更适合保留仓库入口、强制命令、核心边界、资料索引和高风险禁区。能够被格式化工具或 Lint 自动检查的内容不要再用长篇自然语言重复。# AGENTS.md## 开始工作前- 先阅读 docs/ARCHITECTURE.md 和相关 product-spec- 使用 make test-fast 验证本地改动- 涉及数据库变更时先阅读 docs/DB-MIGRATION.md## 强制边界- controller 不得直接访问 repository- 所有外部输入必须经过 schema 校验- 禁止在日志中输出 token、手机号和身份证号## 完成标准- 相关测试通过- 新行为补充验收用例- 复杂任务更新 docs/exec-plans/active/ 下的进度记录最新研究带来的提醒 2026 年关于 AGENTS.md 的研究结论并不完全一致有研究观察到精简指导可降低运行时间和 Token也有研究发现不必要的仓库规则会降低任务成功率并增加成本。共同结论很清楚指导文件要短、相关、可验证不能把所有经验都塞进去。五、第二块地基规则必须从“建议”升级为“机械约束”文档可以解释为什么这样设计却不能保证 Agent 每次都遵守。OpenAI 的实践是把关键边界写进自定义 Lint 和结构测试例如限制依赖方向、统一结构化日志、约束 Schema 命名、限制文件大小并对平台可靠性要求做静态检查。更值得学习的是错误信息设计一个面向 Agent 的 Lint 不只返回“校验失败”还会告诉它违反了哪条不变量、应该阅读哪份文档、建议怎样修复。错误输出本身也成为下一轮上下文的一部分。图 8 文档解释意图机械约束守住边界六、第三块地基建立“写完—运行—观察—修复”的自验证闭环Agent 最危险的状态不是不会写而是无法看到真实结果。没有测试、日志、浏览器和截图它只能根据代码外观猜测任务是否完成。生产级 Harness 应当让 Agent 使用与工程师相同的工具执行测试、启动应用、操作页面、读取日志、查看截图、复现 Bug并在结果不符合验收标准时继续修复。图 9 自验证闭环让 Agent 从“生成答案”升级为“交付结果”OpenAI 的 Codex 实验中一个成熟运行可以复现 Bug、录制失败视频、实现修复、驱动应用验证、录制修复后视频、创建 PR、回应 Review、修复构建失败并只在需要主观判断时升级给人类。官方同时强调这种自治能力高度依赖仓库已有的结构和工具不能简单复制到一个没有 Harness 投资的新项目。七、长任务最大的敌人上下文耗尽和“接班失忆”复杂项目通常无法在一个上下文窗口里完成。Anthropic 把这个问题比作工程师轮班每位新工程师上岗时都不记得上一班发生了什么。如果状态只存在聊天记录里下一轮 Agent 就会重复探索、误判进度甚至把未完成的项目提前宣布为完成。Anthropic 提出的基础方案由两类会话组成第一次由 Initializer Agent 创建运行脚本、功能清单、进度文件和 Git 初始状态后续 Coding Agent 每轮只选一个尚未通过的功能完成实现与测试后提交代码并把进度写成结构化交接。图 10 用文件、Git 和功能清单跨上下文接力功能清单不要只写“完成 / 未完成”好的功能清单应当描述用户能观察到的行为、验证步骤和当前状态。Anthropic 的示例会先把所有功能标为 failing只有在 Agent 真正执行测试后才能改为 passing从而避免“代码写了所以功能完成了”的假验收。{ category: functional, description: 用户可以新建一段对话, steps: [ 打开主页面, 点击新建对话, 确认出现空白会话, 确认侧边栏新增记录 ], passes: false, evidence: [ ]}Context Compaction 和 Context Reset 不要混为一谈Compaction 是在同一个会话里压缩早期历史让模型继续工作Reset 则彻底启动一个干净的新上下文并通过交接文件、Git、任务状态和证据恢复进度。Anthropic 的测试认为某些模型在长任务后期会出现急于收尾的倾向仅做压缩不一定能消除这种状态而 Reset 能让下一轮干净起跑但会增加编排、Token 和延迟成本。图 11 压缩保留连续性重置提供干净上下文八、复杂任务可以拆成 Planner、Generator、Evaluator当任务既需要长时间实现又有主观质量或复杂验收要求时一个 Agent 既规划、又实现、又给自己打分容易出现自我确认。Anthropic 在长时间应用开发实验中使用了 Planner、Generator、Evaluator 三种职责Planner 生成任务与验收条件Generator 负责执行Evaluator 按明确标准检查结果并反馈差距。图 12 规划、生成和验收分离减少一个 Agent 自说自话不要为了“多智能体”而多智能体 角色拆分只有在上下文隔离、并行执行、独立验收或权限隔离能够带来明确收益时才值得。否则多一次模型调用就多一份成本、延迟和失败概率。九、失败恢复要成为状态机而不是无限重试真实工具会超时浏览器会崩溃API 会限流代码执行可能半途失败。Harness 需要区分可重试错误、需要回滚的错误、权限不足和必须由人判断的情况并为任务保存检查点。重试要有限次、有退避、有幂等保护超过阈值后应保留现场并升级而不是让 Agent 在同一个坑里消耗 Token。图 13 生产级失败恢复状态机一个最小的编排循环def run_task(task, harness):state harness.load_checkpoint(task.id)while not state.finished:context harness.build_context(task, state)action harness.model.decide(context)result harness.tools.execute(action, sandboxTrue)verdict harness.verify(task, result)harness.trace.record(action, result, verdict)if verdict.passed:state harness.advance(state, verdict)harness.save_checkpoint(task.id, state)elif verdict.retryable and state.retry_count 3:state harness.retry_from_checkpoint(state, verdict)else:return harness.escalate(task, state, verdict)return harness.publish(task, state)十、Agent 产出越快技术债治理越要自动化Agent 会模仿仓库已经存在的模式。好的模式会被快速复制坏的 helper、命名习惯和临时绕过也会指数扩散。OpenAI 早期每周拿出一天人工清理所谓“AI slop”相当于 20% 的工作周但这种方式跟不上 Agent 的产出速度。后来团队把“什么是好代码”沉淀为 Golden Principles再由定时 Agent 扫描仓库、识别偏离、生成修复 PR文档也由 doc-gardening Agent 检查是否过时。这里的关键不是完全消灭技术债而是让技术债检测和修复速度跟上代码生成速度。图 14 Harness 还要负责持续的熵管理和垃圾回收十一、评测对象应该是“模型 Harness”的完整系统同一个模型放进不同 Harness任务成功率、Token 消耗、工具调用次数、恢复能力和人工升级率都可能不同。GitHub 在 2026 年公开的多模型 Harness 对比也强调评价编码 Agent 不能只看底层模型而要同时看任务解决率、每任务成本和运行方差。图 15 Harness 评测 Scorecard每次修改系统提示词、工具描述、上下文策略、子 Agent 结构、重试次数或模型路由都应在固定基准集上做回归。否则团队很容易只看到某个案例变好却没有发现另一类任务的成本翻倍或成功率下降。十二、生产级架构拆开状态、执行、凭证与评测演示项目常把聊天记录、模型调用、工具执行、文件系统和密钥放进一个进程。长时间运行后这种结构很难恢复、扩容和审计。更稳妥的方式是让 Harness 作为控制面会话事件与检查点单独持久化上下文由 Context Builder 动态组装工具通过路由层调用不可信代码在沙箱执行凭证由代理或 Vault 管理Trace 和 Eval 贯穿整个过程。图 16 生产级 Agent Harness 参考架构OpenAI 2026 年更新的 Agents SDK 同样强调受控沙箱和“Harness 与计算分离”这使长任务在执行环境重启后仍能恢复也便于按任务弹性创建环境。安全上需要坚持最小权限、网络白名单、凭证不落入沙箱以及删除数据、发款、发布生产等高风险动作必须人工确认。十三、从 0 到 1 怎么落地不要一开始就堆多智能体、长期记忆和复杂反思。最有效的路线是先选一类可以明确验收的任务建立最小执行与验证闭环再根据真实失败逐步加固 Harness。图 17 Harness Engineering 的四周起步路线与持续迭代落地检查清单上线前问题任务是否有机器可判定或人工可复核的验收标准Agent 能否读取架构、规格、版本和运行命令而不是依赖团队口头知识强制边界是否由 Lint、Schema、权限和 CI 执行Agent 是否能运行测试、观察日志、操作页面并查看结果任务是否支持检查点、幂等、有限重试、回滚和人工升级长任务的状态是否外化到 Git、事件日志或结构化进度文件每次失败是否有归因并转化为规则、工具、测试或评测样本是否持续监控成功率、成本、延迟、人工升级率和回归模型升级后是否重新验证旧的规划器、评估器和多 Agent 结构仍然值得十四、面试中怎么回答 Harness Engineering建议回答框架 Harness Engineering 是围绕模型构建运行环境的工程方法。Prompt 解决任务表达Context 解决信息供给Harness 进一步管理工具、状态、沙箱、编排、约束、验证、恢复和评测。核心不是让模型“更努力”而是把每次失败沉淀成可版本化、可自动执行的环境能力让 Agent 在长链路任务中持续做对。项目例子可以按“问题—Harness 改造—可量化结果”展开。例如Agent 经常调用错接口于是将最新 API 文档接入检索增加参数 Schema 校验和失败后的纠错提示再用固定用例评测工具调用成功率、平均重试次数和 Token 成本。这样比只说“优化了 Prompt”更能体现工程能力。写在最后模型能力会继续提升但模型越强Harness 并不会自动消失。新的模型可能让某些旧策略失去价值例如过去必须存在的 Planner、上下文重置或多轮反思在下一代模型上可能只是额外成本与此同时更高自治也会放大权限、恢复、技术债和评测问题。因此Harness Engineering 不是不断增加模块而是持续做实验保留真正提高成功率、降低成本和风险的能力删除已经不再“赚回成本”的复杂度。最终竞争力不只来自使用哪个模型而来自团队能否把知识、约束、反馈和失败快速编码进系统。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取
