【人工智能】Agent Harness Engineering | Agent驾驭/管控工程 | 长时任务的缺陷 | 计算机的操作系统 | 通用型和垂直型 | 苦涩的教训 | 工程实践

大家好，这里是最佳拍档 2026年的AI领域正在发生一场静悄悄的革命 大家的焦点开始转移到了一个全新的赛道 如何让AI模型在真实世界的长时复杂任务中 稳定、可靠、高效地运行 过去几年 我们一直在为AI模型的智商买单 不断追逐排行榜上的数值提升 却忽略了一个关键问题

一个能在单轮测试中解出难题的模型 在执行数百次工具调用、持续几天的工作流时 可能会在第五十步的时候就开始出错 这种被称为模型漂移的现象 正在成为AI落地的最大障碍 而解决这个问题的核心答案 可能就在我们今天要聊的Agent Harness和Harness Engineering Harness这个词本来是指给马套上的工具

我觉得中文翻译成驾驭或者管控会比较好 今天我们就来结合网上几篇比较热门的相关文章 探讨一下什么是Agent Harness 如何通过Harness Engineering落地 以及它的发展趋势如何 首先 我们先梳理一下这个词出现的背景 当前AI发展存在一个核心的痛点 那就是静态排行榜的繁荣 掩盖了长时任务的能力缺陷

过去几年，整个AI行业的评价体系 都是围绕着静态排行榜和基准测试展开的 我们习惯性地用模型A是否击败模型B来衡量技术进步 各大实验室也在为了排行榜上的微小提升不断投入资源 但是一个不容忽视的事实是 顶级大模型在这些静态排行榜上的差距正在持续缩小 甚至不足1%。

而这1%的差距 在真实世界的复杂任务中毫无意义 因为它无法检测到模型的耐久性 也就是模型在执行几百次工具调用、处理多步骤逻辑时 能否始终遵循初始指令、正确完成中间推理 更关键的是 随着AI从单一的对话机器人 进化为能自主处理任务的Agent 我们需要的不再是能解决单点问题的模型

而是能执行多日工作流、完成端到端任务的系统 这就要求我们必须跳出唯模型论的思维 构建一套能支撑模型长时可靠运行的基础设施 而这套基础设施，就是Agent Harness 那么，到底什么是Agent Harness呢？

很多人会把它和Agent Framework混淆 甚至认为它就是Agent本身 这是完全错误的 菲尔·施密德在文章中给出了一个清晰的定义 Agent Harness是包裹在AI模型外围 专门用于管理长时运行任务的软件基础设施 它不是Agent本身 也不是单纯的开发框架 而是负责规范、引导、管控Agent运行全生命周期的系统

核心目标是保证Agent在长时任务中始终保持可靠、高效、可调控的状态 为了让大家更直观地理解它的定位 我们可以用经典的计算机架构做一个类比 这个类比也是目前行业内公认的、最能体现Agent Harness核心价值的解释 AI模型就像是计算机的CPU 提供最基础的原始处理能力 是整个系统的算力核心

模型的上下文窗口就像是计算机的Ram 是有限的、易失的工作内存 负责临时存储任务过程中的关键信息 而Agent Harness 就是计算机的操作系统 它负责管理和调度算力资源、优化内存使用、提供标准的驱动程序和运行环境 让上层应用能在稳定的基础上运行 而我们最终开发的各种AI Agent 就是运行在操作系统之上的具体应用

负责实现特定的业务逻辑 这个类比清晰地划分了四个层级的边界 也让我们明白 Agent Harness的核心价值 是为Agent提供一个标准化、稳定化的运行环境 让开发者无需重复构建基础能力 而是专注于Agent的业务逻辑设计 从能力层面来看 Agent Harness要比传统的Agent Framework高出一个维度

我们大概可以用积木和成品系统来形容二者的区别 Agent Framework只是提供了构建Agent的基础积木 比如工具调用的接口、推理循环的模板 开发者需要用这些积木自行搭建完整的系统 过程中需要解决上下文管理、工具调用异常、生命周期控制等一系列问题 而Agent Harness则可以看做是一个成品系统 它在框架的基础上

整合了全套的预设能力和最佳实践 包括提示预设、工具调用的确定性处理、生命周期钩子 还有规划、文件系统访问、子Agent管理这些开箱即用的核心能力 比如 当开发者基于Harness构建编程Agent时 无需自己编写文件读取、代码编辑、终端执行的整合逻辑 因为Harness已经提供了标准化的工具调用流程

也无需担心长时任务中的上下文溢出 对于开发者而言 这意味着开发效率的质的提升 你可以跳过构建操作系统的繁琐过程 直接专注于开发应用 也就是定义Agent的独特业务逻辑 目前整个行业的Agent Harness发展处于什么阶段呢？

答案是 通用型Agent Harness依然稀缺 垂直领域的专用型Harness开始萌芽 施密德在文章中指出 Claude Code是目前通用型Agent Harness的典型代表 它依托于Claude Agent SDK实现了标准化的Agent运行时 它并非是简单的API包装器 而是一个完整的Agent管控系统 内置了各种生产级工具

能让Agent自主完成文件操作、终端执行、代码编辑等核心动作 还能通过权限配置、系统提示词设定等方式 精准管控Agent的行为边界 除了Claude Code LangChain DeepAgents也是通用型Harness的重要探索 它在原有框架的基础上 增加了长时任务的状态管理、工具调用的异常重试、多Agent的协同调度等等能力

试图打造标准化的通用Agent运行环境 而在垂直领域，所有的编码CLI工具 其实都可以被看作是专用型的Agent Harness 因为它们针对编程这个特定场景 提供了标准化的工具调用流程、上下文管理策略和结果验证机制 本质上是为编程Agent打造的专属管控系统 从行业趋势来看

通用型Harness的标准化和垂直型Harness的精细化 将是2026年AI基础设施开发的核心方向 之前我们已经提到过 传统基准测试与真实世界需求的错位 也正是这些问题 让Agent Harness的必要性凸显出来 它从三个核心维度 搭建起了基准测试与用户体验之间的桥梁 第一个维度是验证真实世界的技术进步

Agent Harness能让用户将最新的模型 直接接入自己的实际用例和约束条件中 快速测试模型在真实工作流中的表现 第二个维度是赋能用户体验 一个模型的潜在能力再强 如果没有合适的Harness支撑 实际体验也会大打折扣 而Agent Harness通过整合成熟的工具和最佳实践 让开发者能构建出体验一致、性能稳定的Agent

确保用户能真正触达模型的潜在能力 第三个维度是通过真实世界的反馈实现持续优化 Agent Harness提供了一个共享、稳定的运行环境 能将Agent的多步骤工作流转化为结构化的运行数据 包括每一步的工具调用、推理过程、结果输出 开发者可以对这些数据进行记录、评分、分析 找到Agent的性能瓶颈和错误点

进而迭代优化基准测试和模型本身 形成从真实场景反馈到基准测试优化 再到模型能力提升的正向循环 简单来说 Agent Harness让AI系统的优化从凭经验变成了靠数据 这也是AI工程化的核心标志 在Agent Harness的开发过程中 有一个核心的理论支撑 那就是Rich Sutton提出的苦涩的教训（The Bitter Lesson）

这篇文章指出 使用通用计算方法的技术 最终总会击败那些依赖手工编码人类知识的技术 施密德在文章中列举了三个典型的行业案例 第一个，Manus团队在六个月内 对其开发的Harness进行了五次重构 核心目的就是移除其中的刚性假设 因为这些基于人类经验的手工设定 在新模型发布后完全失效

第二个，LangChain团队在一年内 三次重新架构了Open Deep Research Agent 原因是过度设计的控制流 无法适配模型能力的快速提升 第三个 Vercel团队更是直接移除了其Agent中80%的手工工具 结果反而实现了更少的执行步骤、更少的token消耗和更快的响应速度 这些案例都指向一个核心结论

Agent Harness的开发必须坚持轻量化原则 绝对不能过度工程化 开发者在构建Harness时 必须放弃用人类知识定义Agent行为的思维 转而打造一个灵活、可迭代、无刚性约束的基础设施 更重要的是 开发者要学会为删除而建 也就是让Harness的架构保持高度的模块化 因为每一个新模型的发布

都会带来全新的Agent结构设计方式 昨天你为Harness编写的智能逻辑 明天可能就会被一个简单的模型提示词替代 如果Harness的架构无法快速移除旧代码 就会被新模型的发展所淘汰 如果说Agent Harness是AI长时运行的基础设施 那么Harness Engineering就是让这个基础设施落地的核心工程实践

而OpenAI在2026年发布的内部实验报告 为我们提供了最具参考价值的真实案例 比尔吉塔·伯克尔在马丁福勒的博客中 对这个案例进行了深度解析 OpenAI的团队做了一个极具挑战性的实验 以完全不手动编写任何代码为强制要求 基于Codex构建一套管控框架 用来维护一个大型应用 而实验的结果令人震惊

5名工程师起步 最终扩展到7人 仅仅用了5个月的时间 就打造出了一个超百万行代码的实际产品 并且已经拥有外部Alpha测试用户 更关键的是 这个产品的应用逻辑、基础设施、工具链、文档全部由Codex Agent生成 人工仅参与高层的架构决策 团队的平均吞吐量 达到了每名工程师每日3.5个Pull Request的合并量

代码审查则通过Agent对Agent的循环 实现了大规模自动化 这个实验不仅证明了AIAgent在大规模软件开发中的潜力 更重要的是 它倒逼OpenAI团队构建出了一套成熟的Harness Engineering体系 而这套体系 正是未来AI工程化的核心方向 需要说明的是 open AI团队的这篇报告 标题虽然为Harness engineering

但是文中仅提到了一次harness这个词 伯克尔推测 这个术语可能是受米切尔·桥本近期博客的启发 是后期加入的 但是这并不影响我们从实验中提取Harness Engineering的核心逻辑 OpenAI构建的管控框架 核心融合了确定性方法和大语言模型方法 形成了三层核心组件 这三层组件相互配合

构成了Agent稳定运行的完整管控体系 第一层组件是上下文工程（Context Engineering） 这是对2025年行业主流的上下文工程理念的升级 不仅包括在代码库中构建持续增强的知识库 让Agent能随时获取最新的项目信息 还为Agent提供了对动态上下文的访问能力

比如可观测性数据、浏览器导航、终端运行结果等等 解决了Agent知道什么的问题 让Agent能在动态变化的环境中 始终掌握完整的任务上下文 第二层组件是架构约束（Architectural constraints） 这一层的核心是为Agent划定行为边界 避免Agent出现失控行为 它并非单纯依靠基于大语言模型的Agent进行监控

而是融合了确定性的自定义代码检查器和结构测试 比如通过ArchUnit等框架 强制要求Agent生成的代码遵循特定的架构模式、模块边界 一旦出现违规 系统会立即终止Agent的操作 并让其重新生成符合要求的代码 第三层组件是垃圾回收（Garbage collection） 这里的垃圾回收并不是指内存管理

而是指对抗系统的熵增和衰退 OpenAI团队开发了专门的监控Agent 这些Agent会定期运行 扫描整个代码库和文档体系 找出文档中的不一致性、代码中的架构约束违规、工具调用中的无效逻辑 并且自动完成修复 确保整个系统始终保持高质量、高一致性的状态 这一组件解决了AI生成系统长期维护的核心难题

OpenAI团队在实践中 还提出了一个极具价值的迭代理念 当Agent遇到困难、无法完成任务时 不要将它视为单纯的模型失败 而要将它视为一个重要的信号 然后将这些问题反馈到代码仓库中 并且让Codex自己编写修复代码 完成系统的自我迭代 这个理念让Harness Engineering成为了一个自驱的进化体系

系统能通过Agent的失败案例 不断完善自身的能力 让Agent的运行越来越稳定、越来越高效 当然 伯克尔也指出了OpenAI这个实践的明显缺口 整个管控框架只关注了系统的内部质量和可维护性 却缺乏对功能和行为的验证 也就是Agent生成的代码和功能 是否符合实际的业务需求 是否能在真实环境中正常运行

这是未来Harness Engineering需要弥补的一个核心方向 基于OpenAI的实践 伯克尔提出了四个关于Harness Engineering未来发展的核心思考 第一个思考，未来的Agent Harness 很可能会成为新一代的服务模板 这些Harness会针对常见的应用拓扑 整合自定义的代码检查器、结构测试、基础上下文知识库和动态上下文提供器

团队可以直接基于这些Harness开始开发 再根据应用的具体需求进行定制化调整 但是这也带来了一个潜在的问题 当前的服务模板在使用过程中 会出现团队贡献经验后 其他团队难以整合更新的情况 也就是分叉和同步问题 未来的Agent Harness是否会面临同样的挑战 如何建立标准化的更新和同步机制

将是一个需要解决的问题 第二个思考是，更高的AI自主化 可能需要以约束运行时为代价 OpenAI的实践证明 要想实现可信任、可维护的大规模AI生成代码 必须主动约束Agent的解决方案空间 比如指定特定的架构模式、强制划定模块边界、建立标准化的代码结构 这意味着 我们需要放弃让AI生成一切的灵活性

转而使用带有具体技术细节的提示词、规则和管控框架 为AI的运行划定清晰的边界 LangChain的编码Agent在Terminal Bench 2.0基准测试中 仅仅通过优化运行环境 没有修改底层模型的任何参数 排名就从全球第30位跃升到了第5位 得分从52.8%飙升到66.5%， 这也证明了

约束运行时不仅不会限制AI的能力 反而能让模型的潜力得到更充分的释放 第三个思考是 AI可能会推动技术栈和应用拓扑 向有限数量收敛 随着编码从手动编写转向引导AI生成 开发者的工作重心从编写代码本身 转移到引导AI生成正确的代码 这个转变会让技术栈的选择标准发生根本变化 未来

技术栈的AI友好性和是否有成熟的Agent Harness支撑 将成为核心的选择标准 这个趋势还会延伸到代码库结构和应用拓扑的设计中 未来的开发者会默认选择那些更易被AI维护、更易被Agent Harness管控的结构 OpenAI团队在实践中 也将这两点作为架构设计的核心

甚至要求Codex必须能解析模块边界处的数据形状 伯克尔还提出了一个有趣的问题 如果未来行业能广泛掌握管控代码库设计模式的方法 那么这些标准化的应用拓扑 是否会成为新的软件抽象层 取代自然语言成为AI开发的核心交互方式呢？

这个问题的答案 将决定未来AI开发的整体格局 第四个思考是，AI应用的维护 可能会形成前AI时代和后AI时代两个截然不同的世界 对于那些前AI时代开发的旧代码库 它们往往存在标准化程度低、系统熵增高、架构混乱等问题 要为它们适配Agent Harness 需要投入大量的改造成本 虽然AI能加速这个改造过程

但是改造后的效果可能并不理想 就像给一个从未做过静态代码分析的代码库运行分析工具 结果会被大量的告警信息淹没 反而影响开发效率 而后AI时代的新应用 如果从设计之初就融入了Harness Engineering的理念 让代码结构、架构模式、文档体系都符合AI的管控要求 就能充分发挥Agent Harness的优势

实现高效的AI辅助开发和维护 这意味着，未来的企业软件体系 可能会出现双轨制的局面 一部分是基于Agent Harness的高效AI原生应用 另一部分是难以改造、维持传统开发方式的旧应用 而如何平衡这两者的关系 将成为企业数字化转型的核心挑战 除了这些行业思考

伯克尔还为开发者提供了Harness Engineering落地的具体实践建议 核心观点是 Harness Engineering并非一蹴而就的工作 OpenAI团队花费5个月才构建出了一套成熟的管控框架 这意味着开发者需要从现有开发流程的微小改进入手 逐步搭建自己的管控体系 首先 开发者需要反思自己当前的管控体系 是否有预提交钩子（pre-commit hook）呢？

钩子中是否包含代码格式检查、架构约束验证等能力呢？

是否有开发自定义代码检查器的想法呢？

想对自己的代码库施加哪些具体的架构约束呢？

是否尝试过ArchUnit、Testcontainers等结构测试框架呢？

这些看似基础的开发流程 正是构建Agent Harness的核心基础 因为Agent Harness的本质 就是将这些人工的管控规则 转化为AI能理解和遵循的自动化规则 其次，开发者需要明确 Harness Engineering远不止生成和维护一堆Markdown规则文件这么简单 OpenAI团队在实践中 为管控框架的确定性部分构建了大量的工具

比如自定义的代码检查器、结构测试脚本、动态上下文访问接口 这些工具是管控框架能稳定运行的关键 同时 上下文工程也并非是单纯的知识库管理 代码设计本身就是上下文的重要组成部分 一个清晰、规范的代码结构 能让AI更易理解和管控 这也是Harness Engineering的核心内容之一

OpenAI团队在实践报告中说过一句话 我们目前最困难的挑战 集中在设计环境、反馈环和控制系统 这句话让整个行业意识到 AI的发展已经从追求更聪明的模型 转向追求更完善的运行体系 同时也呼应了查德·福勒近期关于重新定位严谨性的文章 过去 我们将AI开发的严谨性

寄托在模型的算法和参数优化上 希望更好的模型能神奇地解决所有的落地和维护问题 但是现在 行业终于开始探索严谨性的实际落地方式 那就是通过Harness Engineering 设计出能让AI稳定运行的环境、能实现持续优化的反馈环、能精准管控AI行为的控制系统 从2023年的提示词工程 到2025年的上下文工程

再到2026年的Harness Engineering 整个AI行业的认知正在完成三次重要的升级 提示词工程关注的是如何对AI说什么 解决的是单轮指令的设计问题 上下文工程关注的是如何让AI知道什么 解决的是多步骤任务的上下文管理问题 而Harness Engineering关注的是如何让AI在什么环境里做事 解决的是长时任务的运行管控问题

这三次升级 标志着AI开发从面向模型的思维 彻底转向了面向系统的思维，而这 正是人工智能从实验室走向真实世界的核心标志 最后 伯克尔在文章中表达了一个有趣的观点 她非常喜欢harness这个术语 认为它精准地描述了约束和引导AI Agent的核心内涵 尽管在她写作这篇文章时 这个术语才诞生两周

但是她也提出了一个担忧 未来可能会有开发者 将一个简单的、单提示词的代码审查Agent 也称作harness 这会稀释这个概念的核心内涵 让Harness Engineering沦为一个空洞的噱头 展望未来，随着模型能力的提升 我们会发现AI发展的瓶颈 已经从模型的推理能力 转变为了上下文的耐久性 也就是模型在长时任务中

能否始终保持对上下文的理解和指令的遵循 而解决这个瓶颈的核心工具 就是Agent Harness 未来 各大AI实验室会将Agent Harness作为模型训练的核心反馈工具 通过Harness捕捉模型在长时任务中的每一个漂移点 让训练过程能针对性地优化模型的长时推理能力 打造出在复杂任务中不会疲劳的模型

这种从训练到推理再到反馈的闭环 将让AI模型的能力提升从通用化走向场景化 从短时长优化走向长时长优化 而Agent Harness 就是这个闭环的核心枢纽 对于开发者而言，要跟上这个趋势 需要完成三个核心的思维转变 第一个转变是从简开始 放弃构建大规模的手工控制流 转而为Agent提供健壮的原子工具

让模型自主完成任务规划 开发者的核心工作 不再是告诉Agent每一步该做什么 而是定义Agent能用什么工具 工具的使用边界是什么 结果如何验证等等 也就是为Agent搭建护栏、实现重试机制和结果验证机制 让模型在安全的范围内自主决策 第二个转变是为删除而建

这也是我们前面提到的轻量化原则 开发者要让Harness的架构保持高度的模块化 每一个功能模块都能被快速移除和替换 因为新模型的发布 总会带来更高效的实现方式 只有这样 Harness才能跟上模型的发展速度 第三个转变是将Harness视为数据集 在过去 AI开发的竞争优势在于编写优秀的提示词 但是在未来

竞争优势将转移到Harness所捕捉的运行轨迹上 每一次Agent在工作流后期的指令失败、每一次模型漂移的发生、每一次工具调用的异常 这些数据都是最珍贵的训练素材 能够用来优化下一代模型和Harness本身 简而言之 谁能捕捉到更多的真实场景运行数据 谁就能在AI的工程化竞争中占据先机

回到视频开头的问题 2026年的AI革命 到底革的是什么命呢 答案是，革掉唯模型论的命 开启AI工程化的新时代 未来的人工智能竞争 不再是单一模型的智能比拼 而是整个管控体系的工程化能力较量 谁能构建出轻量化、模块化、可迭代的Agent Harness 谁能掌握Harness Engineering的核心实践 谁就能真正释放AI Agent的潜力

让人工智能从实验室的玩具 变成企业的核心生产力工具 对于开发者而言 这意味着需要完成从模型调优师到系统工程师的思维转变 不再仅仅关注模型的参数和提示词 而是开始关注AI的运行环境、管控体系、反馈环设计 而对于整个行业而言 这意味着人工智能终于走出了炫技的阶段

开始真正走向落地、走向实用、走向价值创造 这正是2026年AI发展最珍贵的变化 也是未来人工智能发展的一个核心方向 好了，以上就是今天关于Agent Harness和Harness Engineering的全部内容了 希望能对大家带来一些帮助 感谢收看本期视频，我们下期再见