by smallnest

Harness Engineering：当 AI Agent 变得足够强大，真正的工程才刚刚开始

Harness Engineering：当 AI Agent 变得足够强大，真正的工程才刚刚开始

2025年11月26日，Anthropic 的工程博客上发表了一篇文章。标题平淡得像一份内部备忘录："Effective harnesses for long-running agents"。作者 Justin Young 没有宣布新产品，没有展示基准测试的飞跃，只是描述了一件事：如何让 Claude 在跨越多个上下文窗口的长时间任务中不崩溃。

三个月后，OpenAI 发布了自己的版本。他们的团队用三个工程师、零行手写代码，在五个月内构建了一个百万行代码的生产级产品。GitHub 上一个名为 awesome-harness-engineering 的资源库在几周内成为行业里被引用最频繁的文档之一。LangChain 发布了 Deep Agents——一个被明确定义为"agent harness"的开源运行时。Martin Fowler 的网站上出现了专题文章。36氪、知乎、腾讯云开发者社区的中文解析文章接踵而至。

他们都在讨论同一件事。

只是这件事，还没有一个公认的中文翻译。有人叫它"驾驭工程"，有人叫它"约束工程"，有人干脆不翻译，就叫 Harness Engineering。

一个反直觉的前提

Harness Engineering 的起点是一个令很多人不适的观察：你的 Agent 效果不好，可能不是模型的问题，是你的问题。

更准确地说，是你围绕模型搭建的那层基础设施——或者更准确地说，那层基础设施的缺失。

HumanLayer 的博客用了一个刻薄的标题："Skill Issue: Harness Engineering for Coding Agents"。文章的核心论点是：大多数人对 AI Agent 的失望，本质上是一种 skill issue——不是模型的 skill，而是使用者的 skill。你没有给 Agent 足够的上下文，没有设置正确的约束，没有提供验证手段，没有建立反馈回路。Agent 失败了，你归咎于模型，但实际上是你的 harness 不够好。

这个论点之所以有说服力，是因为它解释了一个广泛存在的矛盾：同一个模型，在不同人手里表现出天壤之别。有人在 Claude Code 里三天搭出一个全栈应用，有人连一个 CRUD 接口都生成不明白。差异不在模型，在 harness。

LangChain 的创始人 Harrison Chase 给出了一个更简洁的公式：Agent = Model + Harness。 裸模型什么都做不了。提示词、工具、中间件、编排、运行时基础设施——这些才是让模型变成 Agent 的东西。

三次范式迁移

要理解 Harness Engineering，需要先看清楚过去四年的完整轨迹。

2023年，Prompt Engineering。 核心问题：如何跟模型说话。提示词模板、少样本学习、思维链（Chain-of-Thought）、角色扮演。工程师的主要工作是文字匠——精心措辞，反复调试，在"你是一个专业的…"和"请扮演一个…"之间寻找微妙的效果差异。

2024-2025年，Context Engineering。 核心问题：给模型看什么。当 Agent 开始处理真实任务，人们发现提示词只是冰山一角。真正决定 Agent 表现的是上下文窗口里装了什么：代码库的结构、依赖关系、最近的修改历史、相关的文档、执行结果、错误信息。Anthropic 的指南把上下文窗口比作"工作记忆预算"——它不是垃圾桶，不能什么都往里塞。Manus 的团队详细描述了 KV-cache 局部性、工具掩码和文件系统记忆的实践。Thoughtworks 把这称为"context engineering for coding agents"——塑造任务环境，让编码 Agent 保持专注和高效。

2026年，Harness Engineering。 核心问题：如何让 Agent 在真实世界中持续可靠地工作。上下文工程解决了"喂什么"的问题，但没解决"怎么管"的问题。当 Agent 开始连续工作数小时甚至数天，当多个 Agent 协作完成一个复杂项目，当 Agent 需要跨越上下文窗口恢复工作——你需要的不只是正确的上下文，你需要一整套约束系统、验证机制、恢复策略和反馈回路。

这就是 harness。

从 Prompts 到 Contexts 再到 Harnesses，每一次迁移都意味着工程师的工作重心上移一层：从写文字，到管理信息，到设计系统。

Anthropic 的发现：两个 Agent，一份特性清单

Anthropic 的文章之所以成为这个领域的奠基文献，是因为它诚实地描述了一个失败。

他们让 Claude Opus 4.5 在 Claude Agent SDK 上持续工作，目标是用多个上下文窗口构建一个生产级 Web 应用。结果是：Agent 要么试图一次性完成所有事情，耗尽上下文后留下一个半成品；要么工作到一半，看看之前的成果，然后宣布项目已完成。

这两个失败模式——"一口气做太多"和"过早宣布胜利"——精确地指向了长时运行 Agent 的核心挑战。上下文窗口是有限的，compaction（压缩）机制不能完美地将指令传递给下一个窗口，而 Agent 在每个新窗口开始时，本质上是一个失忆的工程师。

他们的解决方案出人意料地简单：用两个 Agent。

第一个是初始化 Agent（Initializer Agent）。它只运行一次，负责搭建环境：写一个 init.sh 脚本来启动开发服务器，创建一个 claude-progress.txt 文件来记录工作进度，最重要地——基于用户的原始需求生成一份详尽的特性清单（feature list）。在 claude.ai 克隆的例子中，这份清单包含超过200个特性，每一个都有具体的验证步骤，全部标记为"failing"。

第二个是编码 Agent（Coding Agent）。它每次启动时遵循严格的流程：先读 git 日志和进度文件了解当前状态，运行 init.sh 启动服务器，用 Puppeteer MCP 做端到端测试确认基本功能正常，然后从特性清单中选择优先级最高的未完成特性，一次只做一个，完成后用浏览器自动化验证，更新清单状态，提交代码，写进度更新。

关键细节：Anthropic 选择用 JSON 而非 Markdown 来存储特性清单，因为模型倾向于不恰当地修改 Markdown 文件，但对 JSON 的修改更加谨慎。他们还发现，必须明确要求 Agent "作为人类用户那样测试"，否则 Claude 会满足于单元测试和 curl 命令，而忽略端到端的实际体验。

这个方案的精妙之处不在于它的复杂性，而在于它的克制。没有多 Agent 编排框架，没有复杂的管道，只是一个初始化 Agent、一个编码 Agent、一份特性清单、一个进度文件和一套标准化的启动流程。

OpenAI 的实验：零行手写代码，一百万行 Agent 生成代码

如果说 Anthropic 的文章是理论，OpenAI 的文章就是实战报告。

2025年8月，OpenAI 的一个团队从一个空的 Git 仓库开始，做了一个实验：构建并发布一个内部产品，团队不写任何手写代码。 所有代码——应用逻辑、测试、CI 配置、文档、可观测性、内部工具——全部由 Codex 生成。

五个月后，仓库里有一百万行代码。1500个 Pull Request 被提交和合并。三个工程师驱动 Codex，平均每人每天产出 3.5 个 PR。产品有内部日常用户和外部 Alpha 测试者。它上线、部署、出 bug、被修复——和任何正常的软件产品一样。

这篇文章的核心洞察是关于工程师角色重新定义的。当人类不再写代码，工程工作的重心转移到了"系统、脚手架和杠杆"上。OpenAI 的工程师们发现，早期进度比预期慢，不是因为 Codex 不行，而是因为环境定义不足。Agent 缺乏必要的工具、抽象和内部结构来推进目标。

他们的解决方式形成了一套完整的 harness 设计哲学：

知识即系统记录。 他们最初给 Codex 一个庞大的 AGENTS.md 文件，里面塞满了规则。结果是：上下文被挤占，Agent 要么遗漏关键约束，要么开始优化错误的约束。他们的教训是——"给 Agent 一张地图，而不是一本1000页的说明书。" AGENTS.md 被压缩到约100行，充当目录而非百科全书。详细的知识存在于结构化的 docs/ 目录中，由专门的 linter 和 CI 任务验证其时效性和一致性。一个"文档园艺"Agent 定期扫描过时文档并提交修复 PR。

架构强制执行。 每个业务领域被划分为固定的层次，依赖方向严格验证，只允许有限的跨层引用。这些约束不是写在文档里靠人遵守的，而是通过自定义 linter 和结构性测试机械执行的。一旦编码，就自动应用于所有未来的代码。OpenAI 的团队发现，"这类架构通常在团队达到数百人时才被建立。但在 Agent 编码的世界里，它是早期的先决条件。"

熵增与垃圾回收。 全 Agent 自治带来了新问题：Codex 会复制仓库中已有的模式——包括不好的模式。一开始，人类每周五花20%的时间清理"AI 混乱"。后来他们把"黄金原则"编码进仓库，建立了定期清理流程：后台 Codex 任务扫描偏差、更新质量评级、提交针对性的重构 PR。大多数可以在一分钟内审查并自动合并。这就像垃圾回收：技术债务是高息贷款，持续小额偿还总比积累后痛苦清算要好。

渐进式披露。 Agent 从一个小而稳定的入口点开始，被教会"去哪里找更多信息"，而不是一开始就被淹没。设计文档被编目和索引，带有验证状态和核心信念。架构文档提供顶层领域映射。质量文档对每个产品领域和架构层进行评分。

Aaron Levie，Box 的 CEO，在 X 上总结道："Agent harness 的力量倍增效应现在是疯狂的。"

Thoughtworks 的视角：从控制论出发

当 Anthropic 和 OpenAI 从实战中提炼经验时，Thoughtworks 走了一条不同的路。他们不是在构建产品，而是在观察数十个内部项目后总结模式。

2026年4月，Martin Fowler 的网站上发表了 Birgitta Böckeler 的文章"Harness Engineering for Coding Agent Users"。这是该概念首次出现在软件工程领域最具影响力的博客之一上，标志性的时刻。

Thoughtworks 把 harness 工程拆解为三个维度：

上下文工程（Context Engineering）——管理 Agent 能看到什么。不只是"给正确的信息"，还包括结构化地组织知识库，让 Agent 能渐进式地发现上下文。

架构约束（Architectural Constraints）——划定 Agent 不能做什么。通过代码层面的强制机制——linter、结构性测试、依赖规则——而非文档层面的建议，来确保 Agent 的输出符合架构标准。

熵增垃圾回收（Garbage Collection Against Entropy）——对抗 Agent 工作中不可避免的质量退化。定期扫描、自动修复、持续重构，不让技术债务积累。

Thoughtworks 的另一个独特贡献是把控制论（Cybernetics）引入了讨论。在"Human-on-the-Loop"的框架中，他们借鉴了 Ross Ashby 的"必要变异度定律"（Law of Requisite Variety）：一个控制系统必须拥有与被控制系统相当的变异度，才能有效控制它。AI Agent 的行为变异度极高——它能生成无限多种可能的输出。Harness 的作用就是衰减（attenuate）不需要的变异度，放大（amplify）需要的变异度。

这个框架解释了为什么 harness 不是可选的。没有 harness 的 Agent 就像没有刹车的跑车——动力十足，但不可控。

工具链的成熟

Harness Engineering 的讨论不再停留在理论层面。2026年初，一批具体的工具和框架已经投入生产使用。

LangChain Deep Agents——2026年3月发布，被明确定义为"agent harness"。它提供了开箱即用的任务规划、多 Agent 编排、基于文件系统的上下文管理和长时运行任务的内存处理。它不是又一个 Agent 框架，而是一个有主见的、可以直接运行的 Agent 封装——开发者不再需要手动连接提示词、工具和上下文管理。

HumanLayer 的 12-Factor Agents——一个开源项目，建立了生产级 Agent 的12条操作原则。核心主张包括：显式提示词优于隐式行为、Agent 必须拥有自己的状态、系统必须支持干净的暂停-恢复行为、以及结构化的上下文纪律。它不是一个工具，而是一套可审计的设计规范。

Inngest 的 AgentKit——TypeScript 工具包，用于在事件驱动基础设施上构建持久的、工作流感知的 Agent。它的核心论点是："你的 Agent 需要的不是另一个框架，而是状态管理、重试、追踪和并发控制作为一等公民。"

Citadel——一个面向 Claude Code 和 OpenAI Codex 的 harness，支持隔离的 Git worktree、多 Agent 协调和持久化的记忆与活动状态。

Harbor——一个通用的评估和改进 Agent 的 harness，与 Terminal-Bench 2.0 一同发布，用于大规模 Agent 评估。

Harness Evolver——一个 Claude Code 插件，使用多 Agent 提案者、LangSmith 支持的评估和 Git worktree 隔离，自主演化 LLM Agent 的 harness。基于 Meta-Harness（Lee et al., 2026）的研究。

Uni-CLI——一个通用 CLI 集线器，通过711个声明式 YAML 管道连接134个站点和桌面应用。它内建了八阶段 Karpathy 式自修复循环、评估 harness、每次调用的成本账本、硬编码的敏感路径拒绝列表，以及自动注册 MCP 工具的功能。每次调用约消耗80个 token。

这些工具的共同特征是：它们都不试图让模型更聪明，而是让模型周围的环境更可靠。

中国社区的解读

中文技术社区对 Harness Engineering 的反应同样热烈，但解读角度有所不同。

知乎上阅读量最高的一篇文章将其命名为"驾驭工程"——"设计和实现系统来约束、引导、验证和修正 AI 智能体的行为，让强大但不可预测的 AI 模型能够可靠地工作。"另一篇万字长文拆解了 Agent Harness 的十二个独立模块，综合了 Anthropic、OpenAI、LangChain 和更广泛实践社区的研究。

腾讯云开发者社区的文章以"2026年 AI 编程 Agent 的真正分水岭"为标题，强调 Harness 是 Agent 竞争的关键差异化因素。36氪的综述从14篇工程文章中提取线索，试图找到"那个让 AI 不出错的答案"。

NxCode 的中文全指南则提供了面向实践者的完整路径，从 Anthropic 的两 Agent 架构到 OpenAI 的零手写代码实验，再到具体的工具选型和部署建议。

一个有趣的共同观察是：中文社区普遍比英文社区更激进地将 Harness Engineering 定位为"新学科"或"新范式"，而非仅仅是"一组最佳实践"。这种定位的差异可能反映了不同社区对 AI 工程成熟度的不同期待。

学术界的回应

学术界也开始认真对待这个概念。

一篇发表在 arXiv 上的论文"Natural-Language Agent Harnesses"将 Anthropic 和 OpenAI 的工作作为关键引用，试图建立 Agent Harness 的形式化描述框架。

另一篇来自 Preprints.org 的综述"Agent Harness for Large Language Model Agents: A Survey"指出，OpenAI 在2026年正式命名了"Harness Engineering"这一学科，报告了3-7人团队构建生产 harness 的实践。该综述尝试建立 harness 设计的系统化分类法。

还有一篇立场论文提出了控制-代理-运行时（CAR）分解框架，将 harness 层视为一等研究对象，并引入了 HarnessCard——一种用于结构化报告 harness 设计和评估的方法。

这些学术努力试图回答一个根本性问题：harness 设计是否可以系统化、可重复、可教学——而不仅仅是依赖个别工程师的直觉和经验？

争议：新的银弹还是旧酒新瓶？

并非所有人都认为 Harness Engineering 是一个真正的新概念。

批评者的核心论点是：它不过是软件工程的旧原则——关注点分离、防御性编程、自动化测试、持续集成——在 AI Agent 语境下的重新包装。"架构约束"就是架构约束，"反馈回路"就是 CI/CD，"熵增管理"就是技术债务管理。换了一个名字，并不意味着换了一门学科。

另一种批评指向了概念的模糊性。到底什么算 harness，什么不算？AGENTS.md 算不算 harness？算。自定义 linter 算不算？算。上下文管理算不算？算。那还有什么不算？如果一切围绕 Agent 的基础设施都是 harness，那这个概念就失去了区分度。

对此，支持者的回应是：新概念的价值不在于它引入了全新的技术组件，而在于它改变了思考的出发点。传统软件工程的约束是面向人类开发者的——人类的习惯、记忆、判断力。Harness Engineering 的约束是面向 AI Agent 的——Agent 的上下文窗口限制、失忆倾向、过早优化倾向、幻觉问题。同样的原则，应用在一个行为模式完全不同的"开发者"身上，需要完全不同的设计决策。

一个具体的例子：在人类团队中，代码审查是关于沟通和知识共享的。在 Agent harness 中，代码审查（包括 Agent 对 Agent 的审查）是关于机械验证和防止模式退化的。形式相似，但功能和设计考量截然不同。

一个正在成形的领域

Harness Engineering 在2026年初的状态，很像2015年前后的 DevOps：概念已经清晰，实践已经展开，工具已经开始成熟，但标准化的方法论、可复用的模式和成熟的教育体系尚未建立。

Walking Labs 维护的 awesome-harness-engineering 资源库是目前最全面的索引。它涵盖了课程与学习资源、基础理论、上下文与工作状态管理、约束与安全自治、规范与工作流设计、评估与可观测性、基准测试，以及运行时和参考实现。这个资源库的存在本身就说明了一个事实：harness 的知识体系已经大到需要专门的索引了。

评估（Evals）是这个领域中最关键但最不被重视的部分。OpenAI 的指南展示了如何将 Agent 轨迹转化为可重复的评估，Anthropic 探讨了当 Agent 有多条可能的成功或失败路径时应该测量什么。LangChain 的证据表明，仅凭 harness 的改进就能显著提升基准测试表现——模型不变。

基准测试也在快速演化。从 SWE-bench（软件工程 Agent）到 OSWorld（桌面 Agent），从 WebArena（Web Agent）到 AppWorld（交互式编码 Agent），从 Agent Arena（ELO 排名）到 ClawBench（综合能力），这些基准测试越来越多地衡量的是 harness 的质量而非模型的原始能力。

回到那个简单的前提

在所有这些复杂性背后，Harness Engineering 的核心洞察可以用一句话概括：2025年证明了 Agent 能工作，2026年要解决的是如何让 Agent 可靠地工作。

OpenAI 的团队用三个工程师和一个 harness 构建了百万行代码的产品。他们的结论是："构建软件仍然需要纪律，但纪律越来越多地体现在脚手架而非代码中。"

Anthropic 的团队用两个 Agent 和一份特性清单让 Claude 持续工作。他们的结论是：让 Agent 有效工作的关键，是"从人类工程师的日常实践中寻找灵感"。

Thoughtworks 用控制论的框架解释了为什么 harness 不是可选的。他们的结论是：没有 harness 的 Agent 是不可控的，而不可控的系统是不可部署的。

这些结论指向同一个方向：AI 的下一个前沿不是更聪明的模型，而是更可靠的系统。模型是引擎，harness 是底盘、方向盘和刹车。没有引擎的车跑不了，但没有刹车的车会杀人。

2026年，我们开始学会造刹车了。

附录：关键资源

基础理论

上下文工程

  • Anthropic：Effective context engineering for AI agents：docs.anthropic.com
  • Manus：Context Engineering for AI Agents: Lessons from Building Manus
  • OpenHands：Context Condensation for More Efficient AI Agents

规范与标准

工具与框架

资源索引

基准测试

  • SWE-bench Verified：软件工程 Agent 基准
  • Agent Arena：ELO 排名的 Agent 对决
  • OSWorld：桌面 Agent 基准
  • WebArena / WebArena-Verified：Web Agent 基准
  • ClawBench / WildClawBench：综合能力基准
  • AppWorld：交互式编码 Agent 基准

中文资源

深度分析