Harness Engineering是什么？为什么Harness来了，也得用混合检索？

最近不少工程师应该都被一个叫Harness Engineering的东西搞得一头雾水。是的大模型圈又出了新概念。它的起源是今年2月HashiCorp 和 Terraform的联合创始人 Mitchell Hashimoto 的一篇blog在文章中他表示“每当我发现 Agent 犯了一个错误我就花时间工程化一个解决方案让它永远不再犯同样的错误。我叫这个过程 Harness Engineering。”几天后OpenAI 与Anthropic也相继发布新播客采用了这个说法。然后 Harness Engineering 突然之间全球爆火。那么 Harness Engineering 到底是什么有什么创新又该如何用好它01Harness 是什么Harness字面意思是马具。在 AI 工程里它指的是包裹在 Agent 外层的整套执行框架——定义它能调用哪些工具从哪里获取信息如何验证自己的决策什么情况下应该停下来。理解它我们必须先分清它和另外两个常见概念的区别Prompt Engineering解决的是和模型说什么优化单次对话的输出质量Context Engineering解决的是往Context Window 里放什么管理模型能看见多少信息Harness Engineering解决的是给 Agent 造一个什么样的世界设计Agent 长时间自主运行的整个执行环境。简单来说前两层工程影响的是 Agent 单次对话的质量而Harness Engineering影响的是 Agent 在长任务、复杂场景中能否稳定、可靠地自主运行。三者是同一批工程师随着 Agent 能力提升必经的认知跃迁。02OpenAI如何三个人五个月产生100万行代码OpenAI 内部一个三人小组去年8月左右做了一个实验3 名工程师5 个月从空仓库开始不写一行代码全部交给 Codex最终能产生什么结果答案是100 万行生产级代码1,500 个 Pull Request。但复盘整个过程他们遇到了以下几个问题第一个问题Agent工作时完全不知道工作细节只能瞎猜。该用什么抽象层命名约定是什么上周的架构讨论结论写在哪没有这些Agent 只能猜然后把猜错的结果写进代码进度频繁被卡。团队最初的尝试是把所有规范、约定、历史决策都塞进一个巨大的 AGENTS.md 文件里让 Agent 随时查看但很快就失败了核心原因有四个Context 是稀缺资源臃肿的指令文件会直接挤掉任务和代码的空间导致 Agent 无法专注核心工作指导过多会失效——当所有内容都被标注为“重要”反而没有了重点Agent 无法判断优先级文档会快速“腐烂”随着项目推进旧的规则会失效但没人及时更新最终变成陈旧规则的坟场单个巨大的文档无法做机械验证没人知道里面哪条规则还能生效、哪条已经过时。针对这个问题团队给出了Harness层面的解决方案将 AGENTS.md 收缩到100行不包含具体规则只作为“地图”指向 docs/ 目录下按类型分好的真实文档——包括设计决策、执行计划、产品规格、参考手册。同时用 linter 和 CI 作业验证这些交叉链接的完整性确保 Agent 能通过这个“地图”快速找到自己需要的信息。背后的核心逻辑很简单运行时没有出现在 Context 里的内容对 Agent 来说就等于不存在。信息可见性的问题解决了下一个瓶颈随即出现吞吐量上去之后人工 QA 速度远远跟不上 Agent 生成代码的速度。团队把Chrome DevTools 协议直接接进了 CodexAgent 可以对 UI 路径截图、观察运行时事件同时接入本地可观测性堆栈让 Agent 能用 LogQL 查日志、用 PromQL 查指标。更关键的是他们给 Agent 设定了明确的“验证标准”服务启动必须在800ms 内完成才从愿望清单变成可被执行的提示。而且单次 Codex 任务可以连续工作超过六小时——通常是在人类休息、睡着的时间。但光靠文档和可观测性还不够第三个问题跟着来了。没有架构约束Agent 生成的代码会越跑越乱——它会复现仓库里已有的模式包括不够好的那些。针对这个问题团队在Harness中加入了“架构约束”整个应用基于严格分层架构依赖方向单向验证——Types → Config → Repo → Service → Runtime → UI关注点只能通过Providers接口进入。自定义 linter 机械地强制这些规则报错信息里直接嵌了修复指令。通常在实体公司这套约束通常要等团队扩展到数百人才会引入。但对编码Agent 来说它是早期先决条件——没有约束速度越快架构漂移越严重。除此之外团队还在Harness中加入了技术债务清理机制把项目的黄金原则编码进仓库建立后台清理循环定期让 Codex 任务扫描代码偏差、发送重构 PR大多数 PR 能在一分钟内自动合并。这就像持续小额还款远比积累大量债务后一次性清算要高效得多。03让Agent 给自己打分是个设计错误OpenAI 的实验验证了Harness框架在规范 Agent 行为、提升效率上的价值但在 Agent 的“自我评估”环节行业内又发现了新的问题。他盯着的是Agent对自己的评估偏差比很多人想的要大。最常见的两个失效模式与应对分别如下失效模式1Context Anxiety上下文焦虑随着 Context Window 逐渐填满Agent 会出现提前收尾任务的情况。不是因为任务完成了而是因为它感觉自己的上下文窗口快到上限了担心无法继续接收信息。行业内最常见的应对方式是 Compaction上下文压缩摘要历史对话和信息让同一个 Agent 在压缩后的 Context 里继续工作。这种方式能保住任务的连续性但无法消除 Agent 的焦虑感毕竟压缩的是历史信息没有压缩快撑不住了的心理预期。另一种解决方案是 Context Reset上下文重置彻底清空当前 Agent 的上下文启动一个全新的 Agent 实例用结构化的 handoff artifact交接文件传递前任的状态和待办事项。这种方式能消除焦虑但代价是交接文件必须足够完整否则新的 Agent 无法无缝衔接会导致任务中断。这两种策略本质上是在连续性和清醒度之间选边。Claude Opus 4.5 基本消除了 Context Anxiety 这个行为本身使得这个版本的 Harness 可以直接去掉 Context Reset交给 SDK 的自动 Compaction 处理。这个演变的含义放到最后一节再说。失效模式2自我评估偏差Agent 评估自己产出时倾向于给虚高分。这种情况在主观任务上最明显——UI 设计没有等价的单元测试可以客观验证。但即使是有明确正误标准的代码任务这个问题同样存在它会先发现问题然后说服自己这其实没那么严重最终通过了本不该通过的检查。Rajasekaran 从 GAN 里借了一个思路把做事的 Agent 和评判的 Agent 彻底拆开。调教一个独立的 Evaluator 让它保持怀疑远比让Generator 批判自己的作品容易得多。Evaluator 被单独调教为天生挑剔的审查者一旦外部评判存在Generator 就有了具体的迭代目标而不是在自我满足里原地打转。Rajasekaran 为了验证这套方案是否真的值那个成本在同一篇文章里跑了一个对比实验任务创建 2D 复古游戏制作器。分别用 Solo 单 Agent 和完整三Agent Harness 各跑一遍Planner接收 1-4 句提示扩展为完整产品规格故意不规定实现细节——早期细节定错了错误会级联到下游Generator按 Sprint 逐功能实现每个Sprint 开始前先和 Evaluator 签Sprint Contract——在任何代码写出之前先就完成的定义达成共识Evaluator配备 Playwright MCP像真实用户一样点击应用测试 UI、API、数据库任何一项不达标Sprint失败Generator 收到具体反馈结果如下可以看到Solo 版本的游戏虽然能启动但实体和运行时的连线在代码层面已经断裂界面没有任何提示只有挖开代码才能发现问题而 Harness 版本不仅能正常游玩还多出了 Solo 版本根本没尝试过的 AI 辅助关卡生成、精灵动画系统、音效等功能。当然有人会说三 Agent 架构的成本是 Solo 版本的 20 倍但这个成本是值得的——它实现了从不能用到能用的跨越这也是 Harness Engineering 的核心价值用框架约束换取 Agent 输出的可靠性。04关键支撑向量检索解决 Agent 的信息查找难题以上两套经验设计表面上解决的问题不同但有一个共同前提Agent 在需要时要能从docs/仓库里准确找到相关信息。这件事比看起来难。以 Generator 执行 Sprint 3——实现用户认证功能为例。在写代码之前它需要检索两类信息语义查询这个产品对用户会话的设计原则是什么设计文档里用的词可能是“会话管理”“访问控制”而不是“用户认证”本身需要语义理解才能匹配到相关文档精确匹配查询哪些文档提到过validateToken函数函数名是任意字符串没有语义嵌入向量无法把它和身份验证相关函数可靠关联。两类查询同时存在无法分开处理。纯向量检索无法做精确匹配传统 BM25 无法做语义理解更无法预知文档用了什么措辞。Milvus 2.4 之前只能维护两套独立的检索系统一套向量索引一套全文索引查询时并行调用结果融合逻辑自己写。对于docs/这种持续更新的活文档库两套索引还要保持同步每次文档更新两边都要触发重新索引还要担心数据不一致。而 Milvus 2.6 的 Sparse-BM25 功能彻底解决了这个问题——它把两套检索管道合成了一套实现了一次查询同时覆盖语义和精确匹配。文档入库时Milvus 内部同时生成两种表示dense embedding用于语义检索以TF 编码的稀疏向量用于 BM25 打分。全局 IDF 统计由 Milvus 自动维护随文档增删实时更新不需要手动触发重新索引。查询时用户输入自然语言文本Milvus 内部同时生成两种查询向量通过 Reciprocal Rank Fusion 融合排序返回统一结果集。调用方看到的就是一个接口。从性能来看在 BEIR 评测集上Milvus 的吞吐量比 Elasticsearch 高 3-4 倍召回率持平特定负载下 QPS 提升 7 倍。此外还可以通过 drop_ratio_search 参数裁剪低权重稀疏项用 dim_max_score_ratio 控制最高分维度的影响权重针对不同查询模式按需调节。这对 Generator 的 Sprint 场景来说意义重大一次查询既能找到与用户会话设计相关的决策语义路径也能找到所有提到 validateToken 的文档精确路径。Harness 里也不再需要再维护两套检索基础设施结果质量同样高于任何单路检索而且 docs/ 仓库持续更新时Milvus BM25 的 IDF 自动维护意味着新写入的文档能立刻参与下一次检索的打分不需要批量重建索引文档在哪里更新检索能力就在哪里跟上。05新模型发布先找哪些组件可以删看到这里我们已经梳理了 Harness Engineering 的核心定义、两个经典落地案例以及关键的技术支撑。但还有一个更重要的规律藏在这些案例背后Harness 里的每个组件都编码了一个模型自己做不到的假设——而这些假设会随着模型能力的提升逐渐失效。比如Sprint 分解结构在 Claude Opus 4.5 版本中是必要的因为当时的模型在长任务中会失去连贯性需要通过 Sprint 拆分来保证任务推进但到了 Opus 4.6 版本模型能力大幅提升这种分解结构就变成了多余的负担可以直接删除。再比如Context Reset 是针对早期模型Context Anxiety的补偿机制当模型本身消除了这种焦虑这个组件就可以从 Harness 中移除。这意味着Harness Engineering 不是一个固定不变的框架而是需要随模型能力持续重新校准的动态系统。每次新模型发布Harness Engineer 要做的第一件事就是重新审视整套 Harness 系统找出那些不再是承重墙的组件把它们拆掉——因为这些组件的存在反而会增加系统的冗余降低 Agent 的运行效率。这个逻辑同样适用于 Context Retrieval 这一层。随着模型长Context 能力增强检索-注入机制的粒度和时机都会变化。昨天必须精细管理的 Context Slice明天可能可以整页直接塞进去。说到底基础设施配置是和模型能力一起演化的变量。Harness 里任何一个必要的组件都在等待被更聪明的模型证明为多余。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】