一个被质疑 炒概念 的新词到底是不是噱头2026 年AI 工程圈又冒出一个新名词 ——Harness Engineering驾驭工程。它出现得密集而迅猛很快就遍布技术博客、开源项目和一线团队的复盘文章。热度自然也带来了质疑。反对的声音主要分两派一派说它「新瓶装旧酒」用的全是被讲烂的老技术另一派更狠所有 Harness 迟早会被更强的模型吃干抹净今天费尽心思搭的约束系统明天可能就被模型自己吸收了。要判断这些说法成不成立得先把概念本身拆开看清楚。一、Harness 是什么一匹好马还需要一副好马具Harness 本义是马具—— 套在马身上用来控制马的那套装备缰绳、头套、挽具。这个比喻很妙马的力量惊人但若没有约束就是脱缰的野马会跑偏、会撞墙。大模型就是那匹马能力强但任其自由发挥就会发散、会幻觉、会在长任务中途迷路。于是行业形成了一个广泛引用的公式由 LangChain 的 Vivek Trivedy 在《The Anatomy of an Agent Harness》中给出经典表述Agent Model HarnessHarness 指模型之外的一切系统提示词、工具调用、文件系统、沙箱环境、编排逻辑、记忆机制、反馈回路、权限约束。说得直白点只要你做的不是模型本身那你搭的东西大概率就是 Harness。这个定义并不严格更像一种便于协作的共识模型只负责推理和生成Harness 负责把状态、工具、反馈、执行环境和安全边界串起来Agent 才能真正干活。一个贴切的类比是计算机 把模型看作 CPU把 Harness 看作操作系统。CPU 再强系统天天崩溃、驱动乱飞体验也好不了。这就解释了一个常见困惑为什么换了更贵的模型Agent 还是照样重复犯错、做到一半放弃、上下文一长就不稳定二、三代范式的递进从 怎么问 到 怎么搭系统Harness Engineering 有两位「前任」三者不是并列关系而是一层套一层、范围不断向外扩张。第一代Prompt Engineering提示词工程解决「怎么把话说清楚」。 比如让模型 帮我的猫起个名字它可能回你 花花 小白 但你家是橘猫于是你把提示词改成 帮我的橘色小猫起名两个字体现它活泼的性格 它就能给出更合适的结果。 今天它已很少被单独提及 —— 门槛不高且模型变强后不反复调提示词也能给出不错回答。第二代Context Engineering上下文工程解决「该让模型看到什么」。 你接着问 它平时吃什么好这个 它 指谁模型靠的是接收到的全部信息也就是上下文。上下文有容量上限于是需要精心设计。 经典技术之一是上下文压缩对话越堆越长超过阈值就把早期对话总结成摘要。还有动态检索、渐进式披露等方法。但人们很快发现上下文工程的效果也有天花板。于是有了今天的主角。第三代Harness Engineering驾驭工程研究如何围绕大模型搭建一套完整可靠的运行系统。除了模型本身不研究别的都管 —— 它站在系统层面设计环境让模型踏实做事。表格范式解决的问题通俗说法Prompt Engineering怎么把指令说清楚教 AI怎么想Context Engineering该给 AI 看什么教 AI看什么Harness Engineering系统怎么持续执行、纠偏、恢复规定 AI在什么环境工作时间线上行业普遍认同这个节奏2022—2024 提示词工程2024—2025 上下文工程2026 起驾驭工程。这不只是概念叠加而是 AI 工程重心的转移 ——从「调模型」转向「搭系统」。三、为什么瓶颈常常不在模型一个反直觉的结论很多 Agent 场景里卡住效果的不是模型智商而是基础设施。有个流传很广的对照实验开发者 Can Bölük 在 2026 年 2 月测试了 16 个模型、3 种代码编辑格式同一个模型只是把编辑接口从标准格式换成一种基于行哈希的新格式成功率就从 6.7% 跳到 68.3%——Grok Code Fast 1 提升近十倍。模型一行没动变的只是外面那套系统。作者一句话点破模型是护城河Harness 才是那座桥。类似地LangChain 通过优化运行环境 —— 重组文档、补上验证回路、接入追踪系统 —— 把 Terminal Bench 2.0 的排名从全球第 30 提升到第 5得分从 52.8% 涨到 66.5%。模型没换换的是 Harness。这背后还有一个易忽略的现象上下文并非越多越好。有人观察到「智能区 / 迟钝区」的分界 —— 上下文窗口用到约 40% 时输出质量就开始明显下滑幻觉增多、开始兜圈子、代码质量下降。 这也是团队热衷「渐进式披露」和「分层管理」的原因目标不是塞更多信息而是让 Agent 尽量待在干净、相关的上下文里。一句话总结Agent 的问题很多时候不是「模型行不行」而是「系统有没有把模型需要的东西准备好」。四、一个成熟 Harness 的六层骨架把 Harness 拆开看一个成熟的系统通常有清晰分层。一个便于理解的全景框架是六层表格层级名称解决什么问题L1信息边界层Agent 该知道什么、不该知道什么L2工具系统层Agent 怎么和外部世界交互L3执行编排层多步骤任务怎么串起来L4记忆与状态层长任务中间结果怎么管理L5评估与观测层Agent 怎么知道自己做对了没有L6约束、校验与恢复层出错了怎么办可以类比成给新员工搭工作环境L1 是岗位说明L2 是办公工具L3 是标准流程L4 是项目管理和笔记本L5 是质检L6 是红线规则和应急预案是整套闭环而非功能堆砌。 务实建议不要一上来就想搭齐六层优先落地L1 和 L6。先让 Agent 知道自己该干什么再设好出错后的拦截与恢复机制。这两层投入不高却最容易见效。五、一线团队怎么落地四个实战样本概念之外最有说服力的是真实案例。下面四家做法不同但踩的坑高度相似。OpenAI3 个人 5 个月100 万行代码0 行手写2025 年 8 月OpenAI 启动了一项实验从零写一个真实软件产品全程不允许工程师手写一行代码。业务逻辑、测试、CI 配置、文档全由 AI 生成。结果团队从 3 人扩到 7 人历时 5 个月产出约 100 万行代码手写 0 行效率约为传统模式的 10 倍。更值得看的是教训。实验初期进展不顺 —— 不是模型不够聪明而是Harness 没搭好Agent 经常走错方向、重复犯同一个错。他们由此总结几条核心经验给地图别塞手册。最初把所有规范塞进超大的 AGENTS.md反而抓不住重点文件还迅速腐化。后来把它压缩到约 100 行只当目录用指向深层设计文档按需加载 —— 这就是渐进式披露。架构约束必须机械执行。依赖方向被固定为Types → Config → Repo → Service → Runtime → UI靠自定义 Linter 和结构测试保证。违反时工具不只报错还告诉 Agent 怎么改。不能被机械执行Agent 迟早偏离。把可观测性交给 Agent。接入浏览器调试协议让 Agent 自己截屏、抓 DOM、模拟用户操作来验证 UI于是 把启动时间降到 800 毫秒内 不再是模糊要求而是可自测的目标。熵不会自己消失。生成越多重复逻辑、架构违规也越多团队改为用后台 Agent 定期扫描并自动提交清理 PR。仓库即唯一事实来源。散落在聊天记录、在线文档里的知识对 Agent 等于不存在于是强制把约定搬进代码仓库。这一切背后是 OpenAI 反复强调的理念Human steer, agents execute.——人类掌舵Agent 执行。软件工程并未消失而是演变成新形态工程师的核心职责变成了为 Agent 搭建稳定可靠的系统与支撑框架。Anthropic从上下文焦虑到三智能体架构Anthropic 的实践围绕两个核心问题任务规划、质量评估。任务规划早期 Agent 接到需求就开干急于求成结果上下文满了直接撂挑子接手者只能靠猜。 解法是引入负责初始化的 Agent拆解需求、写启动脚本、加进度文件把模糊需求拆成清晰的功能列表后续 Agent 逐个推进、做完标记一个。该角色被抽象为专门的Planner规划者。质量评估人工评估太慢让 Agent 自评又行不通很容易自我美化。 于是选择第三条路设立独立的评估 Agent作为第三方没有动机护短评价更客观还能单独优化。最终形成经典三角架构Planner规划者→ Generator执行者⇄ Evaluator评估者Planner把一两句话产品描述扩展成完整规格Generator逐个开发功能Evaluator用 Playwright 实际点击运行中的应用从产品设计、功能性、视觉设计、代码质量等维度打分。小细节设计质量 和 原创性 权重被故意调高。因为模型极易做出「功能齐全但长相平庸」的东西调高权重逼迫模型去往更难的方向探索。Anthropic 还发现关键现象 ——上下文焦虑上下文快满时模型变得犹豫甚至提前草草收工。 他们的解决方案是context resets上下文重置清空上下文但通过结构化交接文档保留关键状态再启动一个干净的新 Agent 接着做。两种配置成本与效果对照表格方案耗时花费效果Solo单 Agent 最少工具20 分钟$9跑不起来的半成品Full三 Agent 完整工具链6 小时$200完整可用的应用Stripe 与 Mitchell Hashimoto两种相反的路线Stripe Minions高度自动化、无人值守路线开发者发一条消息Agent 就从写代码、跑 CI 到提 PR 全部完成每周有超过 1300 个完全由 AI 生成、无人类手写代码的 PR 被合并。依赖一套成熟工程底座预装源码的开发环境、编排状态机拆分确定性节点与 Agent 节点、集中式工具服务、覆盖 300 万 测试的反馈回路。核心理念Whats good for humans is good for agents.过去为人类工程师投入的工具链在 Agent 身上会直接产生回报。Mitchell Hashimoto人机深度参与路线HashiCorp 联合创始人 Mitchell Hashimoto 选择相反思路一次只跑一个 Agent人类深度参与过程。 核心实践Agent 在真实可读写文件、运行程序、发起请求的环境干活不只局限聊天窗口Agent 每犯一次错就工程化一个方案让它不再犯同类错误下班前给 Agent 布置调研、探索类任务AGENTS.md 的每一行都对应一个过去的失败案例是持续迭代的防错系统。六、它到底是噱头还是终局回到开篇的质疑先梳理这个名词的来龙去脉Harness 本身并不是新词软件测试领域早有test harnessAI 领域有开源LM Evaluation HarnessAnthropic 在 2025‑11 就发布过《Effective Harnesses for Long‑Running Agents》。真正的转折点2026‑02‑05Mitchell Hashimoto 在博客提出「Harness Engineering」核心理念只要 Agent 犯错就去改造系统让它绝不再犯同样的错误。2026‑02‑11OpenAI 相关实验文章发布引爆行业讨论。2026‑02‑17Martin Fowler 网站发布《Harness Engineering: First Thoughts》做结构化拆解。2026‑03‑24Anthropic 公开 Planner / Generator / Evaluator 三智能体架构被业界视作 Harness 教科书案例。质疑一全是老技术属于新瓶装旧酒这个批评有一定道理Harness Engineering 用到的技术没有一项是全新的Linter、代码检查、任务拆解、质量评估早已存在。但它的价值不在于发明新技术而在于提供一套新的系统思维框架把零散的工具、方法收拢起来变成可设计、可迭代、可落地的工程范式。工程领域很多重要进步不是来自发明新技术而是把已有能力组织成一套可持续优化的体系。质疑二模型越来越强Harness 终会被模型吃掉现象客观存在部分过去必须靠 Harness 解决的问题随着模型升级会被缓解。比如部分场景下「上下文焦虑」会被新版本模型改善部分强制约束可以放宽。模型越强所需 Harness 越少但 Harness 只会变形不会消失。模型能力上限提升之后人类会给 Agent 分配更复杂、更长链路的任务又会诞生新一代系统约束需求。综合判断不是噱头但大概率不是终局✅不是噱头OpenAI、Anthropic、Stripe 都靠这套思路拿到可验证的工程结果显著提升 Agent 稳定性与生产力。⚠️不是终局随着模型持续进化今天大量用于约束、纠错、兜底的系统逻辑会逐步被模型自身能力吸收。定位Harness Engineering 是 AI Agent 发展过渡期的关键工程方法论。它未必是终极答案却是当下最现实的答案。谁能把 Harness 搭得更稳谁就能更早把大模型能力转化为真实生产力。七、落地指南从哪里开始搭建 Harness 不必上来就做宏大完整系统按优先级逐步推进。P0马上就可以落地创建并持续维护AGENTS.mdAgent 启动自动加载每一次 Agent 犯错就更新文档每一行对应真实失败案例参考 Mitchell Hashimoto。❗坑点不要把 AGENTS.md 写成超长超级系统提示词。OpenAI 实践控制在约 100 行作为索引目录不堆砌全部规则否则上下文膨胀Agent 反而更容易跑偏。构建自定义 Linter配套修复指令报错时直接告诉 Agent 应该怎么改而不是只抛出错误。将团队约定、业务知识沉淀进代码仓库聊天记录、在线文档中的信息对 Agent 属于不可见信息。P1P0 跑通之后再补充分层上下文管理建立进度文件、功能任务列表赋予 Agent 端到端自验证能力控制上下文窗口利用率尽量不超过 40%规避「迟钝区」。P2资源充裕再考虑Agent 专业化分工多智能体协作后台 Agent 做定期垃圾回收、架构巡检完整可观测性链路集成。结语Harness Engineering 最值得记住的不是名词本身而是一种思维姿态的转变从盯着模型本身转向设计模型所处的运行环境。过去两年我们大量精力花在「怎么问得更好」、「该让模型看到什么」。 但当 Agent 承接真实业务、长链路、低容错任务时决定表现上限的往往是模型之外整套系统约束、反馈、记忆、观测与故障恢复。它未必是技术终点但一定是当下非常值得投入的方向。 毕竟一匹好马也需要一副好马具一个强大的模型同样需要一个稳定运行的世界。最后说一句技术成长不只是写代码职业规划和自我包装同样重要。我整理了一份简历、面试和职业规划的学习资料适合想在职场上走得更远的朋友看看。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。