Harness工程的崛起
模型不是问题。包装模型的基础设施才是问题。
微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI工具导航 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
我在华盛顿大学科学软件工程中心的团队一直在构建 LLMaven —— 一个开源项目，旨在帮助研究人员和研究软件工程师访问和使用大语言模型。作为这项工作的一部分，我们花了很多时间思考脚手架（Harness） —— Claude Code、 Codex、 OpenCode 以及越来越多的工具，这些工具包装模型并将它们转化为可用的智能体。研究人员真正喜欢哪些脚手架？哪些对 AI 支持的研究工作流程效果更好？有些是否更适合特定学科？
几天前，我的同事 Don 在我们的一次对话中提到了一些引起我注意的内容。他说围绕这项工作正在形成一个新兴领域。他称之为脚手架工程（harness engineering）。
我去调查了一下。我挖掘得越多，越意识到这不仅仅是旧工作的新标签。就像之前的上下文工程一样，脚手架工程正在成为 AI 支持的工程和研究完成方式的真正转变。
让我告诉你我发现了什么。
在 Don 播下那颗种子的同一周，我正在调试一个 Claude Code 智能体，它在一个本应轻松完成的任务上反复失败。提示词很清晰。模型有能力。工具可用。然而，每三次运行中就有一次，它会忘记自己在哪里，重复已经完成的工作，或者静默地丢弃对话早期的上下文。
模型不是问题。包装模型的基础设施才是问题。
我花了两个小时调整系统提示词，重构上下文注入方式，调整长时间运行会话的压缩策略，并添加一个钩子，强制智能体在继续之前检查自己的进度文件。在那些更改之后 —— 相同的模型、相同的工具、相同的任务 —— 智能体从三分之一的时间失败变为每次运行都可靠完成。
我没有触碰模型。我修复了脚手架。
1、什么是脚手架？
让我从最简单的定义开始，因为这是一个听起来很抽象的概念，直到你具体看到它。
智能体脚手架是模型之外的一切。
它告诉模型它是谁以及应该做什么的系统提示词。它是模型可以调用的工具 —— 文件系统访问、bash 执行、网络搜索、MCP 服务器。它是代码安全运行的沙盒。它是让智能体回忆三个会话前学到内容的记忆系统。它是决定何时生成子智能体、何时路由到不同模型、何时停下来请求人类输入的编排逻辑。它是确定性地在模型调用之间运行的钩子和中间件 —— lint 检查、压缩触发器、继续逻辑。
如果模型是大脑，脚手架就是身体。神经系统、肌肉、感官、反射。没有身体的大脑可以思考，但它不能做任何事情。而在身体糟糕的情况下，聪明的大脑会被自己的脚绊倒。
LangChain 最近发表了一以这种方式框架的文章：Agent = Model + Harness。 这个方程是我发现思考当前 AI 工程中实际发生的事情最清晰的方式。它揭示了一些重要的东西 —— 模型是获得所有关注的部分。脚手架是决定模型是否真正起作用的部分。
2、为什么脚手架比你想象的更重要
这是当我第一次看到时让我停下来的数据点。
Terminal Bench 2.0 —— 一个在现实世界任务中评估编码智能体的基准测试 —— 在不同的脚手架中测试了 Opus 4.6。相同的模型。不同的包装基础设施。结果：在 Claude Code 内运行的 Opus 4.6 得分显著低于在另一个专门构建的脚手架中运行的 Opus 4.6。一个团队报告说，通过仅更改脚手架，他们的编码智能体从 Top 30 提升到了 Top 5。
让这个沉淀一下。相同的智能。相同的权重。相同的训练。Top 30 和 Top 5 之间的差异完全在于周围的系统。
这对大多数人思考 AI 的方式来说是反直觉的。默认假设是模型是关键。获得更好的模型，获得更好的结果。这是真的 —— 在某种程度上。但我们现在已经过了那个点。
OpenAI 最近发表了自己的看法。一个三人工程师团队使用脚手架工程 —— 而不是模型改进 —— 在五个月内产生了大约一百万行代码。这大约是每位工程师每天 3.5 个拉取请求，零手动输入代码。他们的角色不是编写代码。而是设计脚手架、指定意图并提供反馈。工程师成为了智能体环境的架构师，而不是代码的作者。当他们将团队扩展到七名工程师时，吞吐量上升了，而不是下降。
这不是关于更好模型的故事。这是关于更好脚手架的故事。
前沿模型现在都非常强大。区分有用智能体和令人沮丧的智能体的通常不是模型的智能。而是脚手架是否为该智能提供了成功所需的东西。
这样想一下。想象雇佣你见过的最聪明的人，给他们一台没有互联网、无法访问你的代码库、没有项目上下文、无法验证他们的工作、无法提出澄清问题的笔记本电脑。然后对他们产生的东西不符合要求感到失望。
这就是糟糕的脚手架加上好的模型。
3、脚手架的解剖
理解脚手架内部内容的最简单方法是思考模型自己不能做什么。
模型不能记住它昨天做了什么。它不能执行代码。它不能读取你的文件系统。它不能决定将子任务交给更适合的不同模型。它不能验证它刚刚编写的代码实际上能否运行。这些能力都必须来自某个地方 —— 那个地方就是脚手架。
它从系统提示词开始。这是身份层 —— 智能体是谁、它优先考虑什么、它如何处理歧义。我以前认为系统提示词是指令。我现在开始把它们视为行为契约。精心设计的系统提示词不仅仅告诉模型做什么。它塑造模型如何解释对话中的每条后续消息。把这个弄错了，无论工具有多好，下游的一切都无法正常工作。
工具也非常重要。智能体的能力 —— 文件系统访问、bash 执行、网络搜索、MCP 服务器 —— 只取决于它们的描述方式。工具描述成为模型上下文的一部分。描述不当的工具会被误用，就像文档不佳的 API 会导致集成错误一样。我调试过用错误参数调用正确工具的智能体，修复不在工具本身 —— 而是在模型在决定如何使用它之前阅读的三句描述中。
一旦智能体可以思考和行动，它就需要一个安全的地方来做这两件事。沙盒提供代码隔离运行的执行环境。但这里有一个我花了一段时间才愿意承认的细节:没有预装工具的裸沙盒迫使智能体在开始工作之前花费 token 安装依赖项。装备良好的沙盒 —— 正确的运行时、正确的包、正确的 CLI 已经就位 —— 让智能体专注于实际问题。环境的质量直接影响输出的质量。
然后是记忆。模型本身不会跨会话保留任何内容。脚手架提供持久性 —— 文件式记忆系统，如启动时注入的 CLAUDE.md 文件、进度日志、计划文档。几周前我写过关于这个的内容，当时我意识到我自己的 CLAUDE.md 让我的智能体变笨了，而不是变聪明了。记忆系统只有在其提供的信息是当前和相关的情况下才有用。过时的上下文比没有上下文更糟糕。
将一切联系在一起的是编排层 —— 什么时候一个智能体应该交给另一个？什么时候系统应该路由到更小、更快的模型？什么时候应该拉入人类？这些决定决定了工作的形态。而在所有这些之间的是钩子 —— 在模型调用之间运行的确定性检查点。钩子可能在每次代码生成步骤后运行 linter。它可能在上下文窗口填满时触发压缩。它可能拦截智能体停止的尝试并强制它针对原始目标重新评估。
钩子是你嵌入模型不能被信任自行维护的保证的地方。不是因为模型不好 —— 而是因为确定性行为需要确定性代码。这种区分是使这成为真正的工程学科而不仅仅是额外步骤的提示工程的核心。
4、脚手架工程师的出现
脚手架工程正在成为一个学科，就像二十年前 DevOps 出现的方式一样。没有人着手创建新角色。差距出现了，人们填补了它。
当容器和云基础设施成为默认时，必须有人弄清楚"应用程序在我的机器上运行"和"应用程序在生产中可靠运行"之间的空间。那个空间变成了 DevOps。它有自己的工具、自己的心智模型、自己的职业轨道。在它有名字之前，这项工作由碰巧关心基础设施的开发人员完成，或者碰巧理解代码的运维人员完成。
脚手架工程处于同样的早期阶段。这项工作正在由关心包装模型的系统的 AI 工程师完成。注意到仅靠提示是不够的提示工程师完成。意识到智能体的执行环境与它的指令一样重要的平台工程师完成。
Martin Fowler 的团队发表了一个我认为完美捕捉心态的框架。他们区分了"在循环中工作"——修复智能体产生的工件 —— 和"在循环上工作"——更改脚手架使智能体下次产生更好的工件。传统工程师修复代码。脚手架工程师修复生成代码的系统。
这在实践中是什么样子的？老实说，我能描述的最简单方式是：他们调试不在模型中的失败。当智能体失败时，脚手架工程师不会立即假设模型很笨。他们会问模型是否被给予了正确的上下文、正确的工具、正确的约束。他们将模型的性能失败视为系统失败 —— 而不是模型失败 —— 直到被证明并非如此。
这种诊断本能驱动其他一切。这是在看到智能体三次误解同一指令后重新设计系统提示词的原因。这是在看到智能体在两小时任务中迷失线索后构建压缩策略的原因。这是在智能体实际完成之前捕获它试图提前退出的钩子的原因。每一个修复都是脚手架级别的干预，它们积累成看起来很像学科的东西。
如果你一直在使用 AI 智能体 —— 即使是随意使用 —— 你可能已经做过这些了。每次你调整系统提示词、修改 CLAUDE.md 文件、添加 MCP 服务器、重构向智能体提供上下文的方式，你都在做脚手架工程。你只是没有这个名称。
5、上下文腐烂：定义领域的问题
这是真正变得困难的地方。有一个特定的挑战我认为比其他任何挑战都更能定义这个领域，如果你曾将智能体用于快速一次性任务之外的任何事情，你可能已经感受到了。
上下文腐烂。
每个模型都有一个上下文窗口 —— 它在任何给定时间可以在工作记忆中保存的有限信息量。随着对话的增长，早期的上下文开始变得不那么重要。不是因为模型以人类的意义忘记了它，而是因为注意力机制将权重分布在更多的 token 上，早期的信息被稀释了。对于长时间运行的任务 —— 多小时编码会话、复杂的研究工作流程、多步骤智能体管道 —— 这是一个基本约束。
脚手架工程师的工作是在不丢失关键信息的情况下对抗上下文腐烂。有一些已建立的策略。
压缩是最常见的。当上下文窗口接近容量时，脚手架总结早期的对话轮次，将全文卸载到文件系统，并在其位置注入摘要。智能体保留早期发生的事情的压缩版本，而不会完全丢失线索。设计挑战是决定压缩什么和保留什么 —— 压缩错误的东西，智能体会丢失关键细节。保留太多，你会推迟问题而不是解决它。
工具调用卸载更有针对性。脚手架不是将每个工具调用的完整输出保留在上下文窗口中，而是保留头部和尾部 —— 足以让模型知道发生了什么 —— 并将完整输出写入智能体需要时可以重新读取的文件。这对于生成大量代码或处理长文档的智能体特别有效。
渐进式披露是我花时间最多的方法，也是我认为最有潜力的一种。脚手架不是在启动时加载所有可用的上下文 —— 这会在智能体开始工作之前烧掉 token —— 而是按需提供上下文。技能、文档、参考材料在对话顶部简要描述，只有当智能体请求时才注入完整内容。这使得上下文窗口在任务早期、关键阶段保持清洁，此时智能体正在形成其计划。
这些策略都需要工程判断。我仍然不确定我找到了压缩和保真度之间的正确平衡 —— 我有智能体在压缩后丢失关键变量名并花二十分钟重新发现它。没有通用答案。实现的质量直接决定了智能体是能处理三十分钟任务还是三小时任务。
6、Ralph 循环和长时间视野工作
上下文腐烂是关于信息消退。但有一个相关的同样棘手的问题 —— 智能体在实际完成之前退出。
LangChain 文章中的一个模式让我印象深刻，因为它解决了我个人多次遇到的问题。
他们称之为 Ralph 循环。想法很简单，但执行很聪明。
当智能体决定它"完成"一个任务时，一个钩子拦截那个退出信号。脚手架不是让智能体停止，而是将原始提示词重新注入干净的上下文窗口，并问：你真的完成了吗？智能体根据自己的工作评估原始目标。如果发现差距，它继续。如果一切检查通过，它被允许退出。
这很重要，因为模型倾向于过早宣布胜利。它们会完成任务最明显的解释，生成听起来自信的摘要，然后停止 —— 即使实际目标还没有完全实现。我在编码智能体中见过这几十次了。代码编译。测试通过。但重构只触及了五个模块中的三个，或者边缘情况没有被覆盖，或者文档没有更新。
Ralph 循环捕获了这一点。它是针对模型级别倾向的脚手架级别解决方案。它之所以有效，正是因为它不试图改变模型的行为 —— 它将模型包装在一个补偿其自然局限性的系统中。
这就是一句话的脚手架工程。你不是在改进模型。你是在构建使模型的智能有用的系统。
7、如何现在开始探索这个
你不需要新的职位名称、新的技术栈来开始构建这些技能。你只需要开始关注模型和工作之间的空间。
如果你使用 Claude Code、Cursor 或任何编码智能体 —— 你已经在一个脚手架内部。开始注意它的形状。阅读 CLAUDE.md 文件。查看你设置的 MCP 服务器。思考在第一条消息甚至到达模型之前运行的系统提示词。大多数人使用这些工具而不检查包装他们的基础设施。检查它是第一步。
我建议的下一件事是运行长时间视野的任务，观察智能体在哪里开始退化。那种退化是上下文腐烂。一旦你看到它 —— 智能体重复自己、忘记已经做了什么、忘记二十分钟前的约束 —— 尝试添加一个智能体在每轮开始时读取的进度文件。我上个月在一个编码智能体上这样做，差异是立竿见影的。智能体停止重新发现它已经做出的决定。
如果你想更进一步，构建一个简单的钩子。在 Claude Code 中，钩子只是在特定生命周期点运行的 shell 命令。从基本的开始 —— 在每次代码编辑后运行测试套件的钩子，或者在每轮之前检查计划文件的钩子。这教会你的东西微妙但重要：如何沿着概率模型行为思考确定性保证。模型是随机的。钩子不是。组合是可靠性的来源。
认真地说 —— 阅读 LangChain 文章。"The Anatomy of an Agent Harness" 是我所见过的这些系统在底层是什么样子的最彻底的分解。它不是教程。它是一个概念框架，它会改变你思考智能体设计的方式。
起点总是同样的问题。每次智能体失败时你认为"模型应该知道更好" —— 停止。问失败是在模型的智能中还是在周围的系统中。那个问题是脚手架工程开始的地方。
8、名称之前的工作
我认为在未来几年将定义 AI 工程的进展正在形成。提示工程是关于在单个模型调用中制作正确的词。上下文工程 —— Anthropic 已经广泛撰写 —— 将其扩展到在多步骤交互中策划整个信息环境。脚手架工程是下一层：交付上下文、提供工具、管理记忆、强制约束、在长时间视野工作中保持智能体可靠的完整基础设施。
每一层都建立在前一层之上。每一层都将工程师的角色从编写代码进一步推向设计使智能智能体真正有用的系统。
现在，最好的脚手架工程师不这样称呼自己。他们是智能体团队的高级工程师、AI 公司的平台工程师、注意到模型不是瓶颈的独立构建者。他们在工作拥有名称之前就在做这项工作。就像 DevOps。就像 SRE。就像从没有人计划的差距中出现的其他十几门学科一样。
如果你一直在调整智能体配置、调试不在模型中的失败、构建包装 AI 系统的基础设施 —— 你可能已经是其中之一。你只是还没有这个名称。
你在 AI 智能体中遇到的最大脚手架级别问题是什么？
原文链接：The Rise of Harness Engineering: Your Agent Isn't Broken. Your Harness Is.
汇智网翻译整理，转载请标明出处
