“Agent Harness”这个概念在 AI 工程圈突然火了起来。它是一系列技术与部件的组合负责把“桀骜不驯”的大模型驯化成真正可长期运行、受控制、可治理的 Agent 系统。Harness 不会让 LLM 变得更聪明但会让它更像一个系统。正如给发动机配上变速箱、底盘、外壳等 — 它无法让发动机本身变得更强劲但能让这辆车平稳、受控地跑起来。我们将分两篇为大家深入拆解与展望 Harness 这套“系统外壳”。本篇内容为什么我们开始在意 Harness从 Test Harness 到 Harness EngineeringAnthropic Harness 实践长程任务的“脚手架”与“指挥官”OpenAI Harness 实践百万行代码后的“自动驾驶系统”LangChain Harness 实践DeepAgents 编码能力的跃升从散装 Agent 到标准化的 Harness 组件01为什么我们开始在意 Harness现在人人都在谈论 Agent但你是不是还在把 Agent 当作一个“更聪明的聊天机器人”给点 Prompt给几个工具和技能就能自动化地跑完整个任务流程。或许在一些简单场景下它工作得还算不错比如整理个最新行业资讯并发送到邮箱。但当你真正开始面临“生产化”落地你才会意识到问题的严重性。我们以较成熟、效能最显著的Coding Agent编程智能体为例。如果你只是需要写一个算法函数、一个“贪吃蛇”游戏、个人 Todo 管理甚至带有前后端的小型文档管理系统只需要简单地给点提示和要求AI 的完成度就会很高。但是当你面临以下情况时复杂的长程任务任务不再是一个孤立的函数或工具而是跨越多个系统与模块、涉及复杂调用链路、独有的设计要求、私有技术栈的上百个步骤的工程。Agent 或许能写出语法正确的片段却难以端到端地交付高质量成果。庞大的遗留代码库 AI 瞬间会淹没在上万个源代码文件、复杂的层次与依赖关系、晦涩的业务逻辑中 — 每一行新代码都可能触动隐藏的回归风险。从生成到交付的断裂 特别是在企业级软件中代码生成只是一个环节。更多的挑战还包括环境搭建、依赖安装、测试覆盖以及 CI/CD。一个断掉的链路只会让 Agent 退化成一个需要人类频繁“擦屁股”的半成品。确定性与安全性的考验 在很多企业环境中我们不能接受“幻觉”带来的逻辑漏洞也不能容忍随意的敏感信息泄露。那么如何在一个受控、安全且可重复的环境中来运行 Agent然后问题就会接踵而至不稳定相同的任务今天能跑通明天可能就会发现它调用了错误的工具但它总是会很“自信”地告诉你已经完成不可控你很难控制 Agent 完整地按照你的意图行事并在过程中不会“跑偏”特别是当你的任务有上百个步骤时。难治理出了问题你很难去追溯AI 为什么这么做哪些是幻觉生成推理依据是什么为什么不听我的指令大部分时候你可能会抱怨“这个模型太差了我需要更厉害的模型”但事实上这并非总能奏效。强大的基础模型或许能让任务完成度从 30 分提高到 60 分但很多时候企业生产需要的是 90 分甚至满分。这就是为什么我们需要 Agent Harness —你需要一套用来驾驭马匹Model的马具Harness它关注的不是让马变得更聪明而是驯服它、约束它让它不跑偏。事实上围绕如何构建能完成更复杂任务、更受控的 Agent行业内一直有大量的实践与产品在展开。可以认为“Harness”只是给我们一直在死磕的很多 Agent 工程化工作取了一个贴切的统称。02从 Test Harness 到 Harness Engineering在软件工程领域Harness 可以追溯到为测试而搭建的一套模拟基础设施Test Harness用 Stubs/Drivers等把被测组件包起来在一个可控环境里驱动它、观察它、校验它。Agent Harness 将这个逻辑平移到了 AI Agent 上由于大模型就像一个不可预测的“被测件”为了让它可以长期稳定、可预测地运行并完成任务必须给它一个控制“外壳”把它真正转化为工作引擎Agent。而构建这个外壳的工作就是“Harness Engineering”。借助 LangChain 的观点来简化 HarnessAgent Model智能 Harness系统外壳LangChain 认为在一个 Agent 的组成部分中如果它不是 Model模型那么它就属于 Harness。理解了基本概念后现在我们来回顾主流大厂的一些 Harness 实践与方法在这个演进时间线里我认为最重要的几篇工程实践披露推荐阅读Anthropic发布了两篇针对 Long-running Agents长任务 Agent的实践方法主要针对编程智能体。OpenAI2月份发布了一篇关于 Codex 的 Harness 工程实践 — 揭秘 Agent 如何自主构建了一个百万行代码的应用。LangChain剖析了其深度智能体 DeepAgents 在 Harness 上的实践方法。通过对这些文章中 Harness 工程实践的深入理解非常有助于我们理解 Harness 的内涵、方法与工具组合。借鉴这些普遍来自 Coding Agent 的实践更好地实施 AI Coding。为未来构建真正可用的“生产就绪”的 Agent 系统打下基础。下面我们来逐个解析这三家的 Harness 工程实践建立更直观的认识。03Anthropic Harness实践长程任务的“脚手架”与“指挥官”在 Anthropic 的 Harness 工程实践中其核心任务是挑战 AI Coding 中最棘手的长程任务Long-running tasks。他们主要解决了两个痛点当 Agent 需要在多次上下文窗口中处理长时任务时会面临上下文割裂 —就像工程师轮班却不做交接。在“评估 - 迭代 - 完善”的工作流中单个 Agent 会过于“自我感觉良好”从而影响最终交付质量。Anthropic 采用的核心 Harness 实践包括1.任务拆分 - 增量式完成 - 做好交接为了解决任务间“不交接”导致失忆的问题其采用的方法是把长程编码任务拆分成多个功能列表然后做增量式开发并在此过程中强制做好任务之间的“交接”。初始化 Agent负责初始化环境制定详尽的任务计划并准备进度表。执行 Agent 一次只专注完成一个子任务完成后更新进度、任务摘要等。通过这种方式每当一个子任务一次会话完成Agent 都会留下清晰的“痕迹”进度、摘要、Git 日志。从而在下一次子任务会话启动时能够快速了解之前的工作状态消除“换班失忆”并通过上下文重置节约 Token 空间。2. 独立评估器让 Agent 跳出“当局者迷”为了解决执行 Agent 自我感觉良好的问题其采用的方法是引入一个与执行 Agent 隔离的评估 Agent让其“批判”前者并反馈意见。简单来说就是执行者负责干活而评估者负责“挑刺”两者会在 Harness 的框架下协商一份完成标准。如果评估 Agent 发现工作成果没有通过标准检测则会生成一次具体的反馈并交给执行 Agent 开启下一次迭代。通过这种由 Harness 编排的外部反馈机制形成的闭环能让长程任务的成功率实现极大的提升。小结Anthropic 设计的这套增量任务推进、独立评估 Agent 以及反馈闭环机制是典型的 Harness 工程。其使命是与模型一起构建出一套容错、纠错并自动化的复杂任务系统让大模型在预设的轨道上高质量地工作。04 OpenAI Harness 实践百万行代码后的“自动驾驶系统”如果说 Anthropic 关注的是如何让 Agent 在长任务中不迷路那么 OpenAI 在《Harness engineering: leveraging Codex in an agent-first world》这篇文章中披露的实践则展示了如何通过严谨的 Harness 约束实现0 行人工代码构建出百万行规模的企业应用。在这个实践中OpenAI 从一个空的 Git 仓库开始由 Codex 在五个月内完成了一个百万行代码的内部软件产品。不仅是代码包括仓库内的各种文档、CI/CD 工具、配置都由 Agent 生成。人类被禁止参与具体的代码编写其核心职责转变为明确需求、设计环境、设计反馈/迭代回路、优化控制等。— 这正是 Harness Engineering 的核心范畴。在这个项目中OpenAI 的 Harness 实践可以总结为以下几点1.上下文工程基于“动态地图”的注入OpenAI 放弃了早期“给 Agent 塞一个 1000 页的规则文档AGENTS.md”的粗暴做法因为巨大的指令会挤占有限的上下文窗口导致模型注意力涣散。他们的解法是构建一个“Agent-first 的层次化知识库”目录索引化AGENTS.md 仅保留约 100 行仅作为上下文的“地图”指向深层次的架构、设计与参考文档。知识库检修 Agent 专门设置一个后台 Agent定期扫描文档。如果发现过时或与代码偏离会自动提交 PR 修正文档确保上下文的新鲜度。2. 执行闭环让 Agent 能持续自我驱动OpenAI 构建了一套让 Agent 可以独立完成开发闭环的执行环境。在这套沙箱中Codex 不仅能写代码还可以自主启动应用、操作浏览器、查看日志与指标、复现开发中的 Bug并验证修复效果。在这种环境下一个任务可以持续运行数小时在无人干预的情况下完成从问题定位到修复提交的全过程。这与Anthropic 的评估器机制类似自我验证并迭代完善。3. 架构约束用“刚性外壳”防止系统失控在百万行代码的体量下Agent 极易产生架构与设计漂移。OpenAI 的做法不是依靠人工 Review而是施加可执行的架构约束规则固定系统分层架构严格限制代码的层次与依赖方向。自定义 Linter静态检查工具和结构测试禁止非法依赖。强制执行数据边界校验、日志规范、命名规则等。 核心思想是不依赖于人的肉眼检查而是让系统自己保证 Agent “不乱写”。4. 垃圾回收持续的自我质量维护在长期的编码任务中Agent 可能会在后续工作中复制早期质量不佳的代码模式随着时间的推移会导致整个系统架构退化。OpenAI 引入了一种持续自动化的代码治理机制 他们定义了一系列“黄金原则”比如优先使用标准库并通过后台定期的自动任务来扫描代码库识别不好的代码模式并主动发起重构。这种类似于编程语言中“垃圾回收GC”的机制让代码库能够持续、小步、自动地进行自我质量维护。小结OpenAI 的 Harness 工程的一个重要思想是 —想要获得极高的 Agent 自主权就必须极大地限制其自由度。这套由上下文、反馈闭环、物理约束与持续治理组成的 “Harness”让模型能在约束下持续构建百万行级系统的执行体。05LangChain Harness实践DeepAgents 编码能力的跃升LangChain 提供了一个极具说服力的定量案例在底层模型GPT-5.2-Codex完全不变的情况下仅仅通过优化 Harness 工程就让他们的 DeepAgents 在 Terminal Bench 2.0 测试集上的得分排名从 Top 30 直冲 Top 5。LangChain 认为大模型的能力是“参差不齐”的。Harness 工程的目的就是通过重塑外部环境将这种不稳定的模型智能塑造成面向目标的可靠系统。考虑到 LangChain 并非底层模型厂商其实践对于广大的 Agent 开发者/应用层企业更具普遍的借鉴意义1.Trace追踪分析技能持续改进的基础LangChain 将对运行轨迹Trace的错误分析本身做成了一个 Agent Skill。 它会自动抓取 LangSmith 记录的 Trace 信息诊断模型是在推理、工具调用还是超时上失败并生成诊断建议。在人类工程师的辅助下对 Agent 系统的中间件或提示词作针对性的修改避免盲目试错。本图片来自Langchain官方2. 强制“构建-验证-改进”闭环打破模型的懒惰最初的 Coding Agent 存在一个通病写完代码自己看一眼觉得不错就直接结束任务了。为了让其能够自我提升LangChain 采用了“强制拦截”策略在系统提示中强制规定了“规划-构建-验证-修复”的闭环步骤。利用 LangChain 的 Middleware中间件机制在 Agent 企图结束任务前设置“退出钩子” 强制要求智能体回答编写测试了吗覆盖边缘情况了吗只有跑通测试并对比原始需求无误才允许任务结束。3. 退后一步打断思考“死循环”在开发 Agent 的过程中我们经常会遇到这种情况Agent 在尝试自我修复时会陷入“局部修改-报错-再局部修改”的死循环。LangChain 的防卡死方案是当一个 Middleware 检测到模型反复修改同一个文件达到阈值如 10 次却依然报错时会强制向上下文注入提示类似于“你已经在这里卡了很久了请退一步重新考虑你的整体方案。”4. 推理算力的“三明治”分配策略在有严格时间限制Timeout的任务中如果把模型的推理能力一直开到最大如全部使用 gpt 模型xhigh模式会导致频繁超时失败。LangChain 实施了一种动态的算力调度策略在任务规划阶段和最终的代码验证阶段设置使用最高推理而在中间的执行构建阶段使用常规模式。这种精细化的预算调度可以提高长任务的成功率。本图片来自Langchain官方当然如果你是在多模型环境下也可以采用动态的模型调度策略比如规划与验证使用强模型而实施使用一般的模型。小结从 LangChain 的实践中可以看出Harness 工程的价值就是设计出能够包容、检测并纠正模型自身缺陷的脚手架 — 不指望模型自己变聪明而是要为其准备并交付足够的上下文与控制流使其真正能够自主地完成工作。06从散装 Agent 到标准化的 Harness 组件纵观这几家行业头部披露的工程实践我们可以清晰体会到 Agent Harness 的核心内涵即用系统工程来兜底模型能力的不足。同时也能看到尽管各家的切入点不同但还是能提炼出 Harness 工程中的一些通用实践比如精细化的上下文工程、基于验证与测试的闭环等。在实际应用中不同类型的业务场景也需要调整不同的 Harness 策略比如 Coding Agent借助“测试驱动”的反馈闭环来动态纠正行为是可行的但在其他生产任务中你可能就无法“测试驱动”。而对于拥有庞大代码库和领域知识的大型行业软件Harness 的重心则需要考虑如何将企业私有的架构、代码的理解注入。对于处理内部敏感业务流程的通用 AgentHarness 则又需要倾斜于安全边界、权限管控与人工审批拦截等。没有放之四海而皆准的 Harness只有最契合你业务形态的 Harness。不过我们仍然可以把 Harness 拆解成标准化组件以便按需组装。结合前文的一些实践与方法论这里将 Harness 划分为以下 7 大核心组件其中每个组件都有它针对的问题与实践方法后续我们将深入这层“系统外壳”的内部拆解这些核心组件 —探讨每个组件存在的原因、在真实场景中的实践与避坑指南以及常见工具与框架助你拼装你的专属 Harness。同时我们也需要系统性地厘清当下令人眼花缭乱的工程术语Harness Engineering 、Agent Engineering、Prompt Engineering、Context Engineering 到底有什么区别与联系