文章指出科技界过度关注AI模型本身如参数量、基准测试分数却忽视了脚手架Harness对AI Agent性能的决定性作用。脚手架是围绕模型构建的系统其重要性甚至超过模型选择。文章深入探讨了脚手架的概念、核心组件如文件系统、代码执行、沙盒环境等并对比了脚手架与框架的区别。通过多个真实案例和数据如Claude Opus 4.5在不同脚手架下的性能差异论证了脚手架优化对AI Agent性能的巨大提升。文章最后展望了脚手架工程的未来趋势认为其将发展为独立学科并成为AI公司的核心竞争力之一。所有人都在追逐更强大的模型但几乎没人谈论脚手架。这是我最近观察到的一个奇怪现象。每当有新模型发布科技圈就会沸腾大家讨论参数量、基准测试分数、上下文长度。但当我深入研究那些真正成功的 AI agent 产品时我发现了一个被严重忽视的真相决定 AI agent 性能的不是你用哪个模型而是你如何使用这个模型。同一个模型在不同的系统架构下性能可以相差一倍。Claude Opus 4.5 在一个脚手架下得分 42%换另一个脚手架后得分 78%。这不是模型的问题而是围绕模型构建的系统的问题。最近我读到三位开发者——Himanshu、Viv 和 Tony Kipkemboi——分别从不同角度深入分析了 agent harness 这个概念。他们的观点相互补充让我对 AI agent 的构建有了全新的理解。Himanshu 通过分析顶尖公司的实践证明了 harness 比模型更重要Viv 从第一性原理出发解释了为什么我们需要 harness 以及它应该包含什么Tony 则清晰区分了 harness 和 framework 的概念帮助我们理解它们各自的适用场景。这三个视角结合起来构成了一幅关于 AI agent 构建的完整图景。Harness 到底是什么在深入讨论之前我们需要先搞清楚 harness 这个概念。Tony Kipkemboi 曾在 CrewAI一个 agent framework工作他对这个概念有很清晰的定义。他把 agent 开发比作一个光谱最左边是原始代码你直接调用 API自己管理状态从零开始构建一切。中间是 agent framework代理框架给你提供结构和抽象但你仍然需要做很多决定。最右边是 agent harness代理脚手架这是最有观点的方案一切都已经内置好了。Viv 则从更技术的角度给出了定义Agent Model Harness。如果不是模型本身那就是 harness。换句话说harness 是所有不属于模型的代码、配置和执行逻辑。一个原始模型不是 agent但当 harness 给它提供状态、工具执行、反馈循环和可执行约束时它就变成了 agent。我很认同这个定义因为它迫使我们从系统的角度思考而不仅仅是从模型的角度。具体来说harness 包括系统提示、工具和技能及其描述、捆绑的基础设施文件系统、沙盒、浏览器、编排逻辑子 agent 生成、交接、模型路由、以及用于确定性执行的钩子和中间件压缩、续传、语法检查。这个列表乍看之下很技术化但每一项都对应着 agent 在实际工作中会遇到的具体问题。Framework vs Harness关键区别Tony 对 framework 和 harness 的区分让我豁然开朗。Framework 给你提供构建 agent 的抽象。你定义角色、任务、工具。你指定 agent 如何协作是顺序工作还是层次化工作。Framework 处理管道工作——调用 LLM、路由工具输出、管理执行循环。但你仍在做架构决策。Framework 对构建块的样子有观点它有内存抽象、工具接口、任务结构。但这些部分是可交换的。如果你不喜欢默认的内存实现可以插入自己的。如果想使用不同的 LLM 提供商可以配置它。Framework 给你标准接口但你仍在组装系统。这种模块化正是重点。Framework 是为想要构建 agent 的人设计的不仅仅是使用它们。你需要理解各部分如何组合因为你是决定使用哪些部分的人。相比之下harness 不给你构建块它给你一个完整的系统。Tony 举的例子是 OpenClaw几周前在网上很火。这是一个 harness。你下载它添加 API 密钥突然就有了一个可以在 WhatsApp、Telegram 和其他平台上聊天的 agent。内存已处理。上下文管理已处理。Agent 循环已处理。工具调用、权限、状态持久化全都内置了。你不是在配置内存系统不是在决定工具如何注册或 agent 如何从错误中恢复。这些决定已经由构建 harness 的人做出。你的工作是把它指向一个任务并让它运行。这就是权衡你得到了立即可用的东西但不能改变它内部的工作方式。Harness 对一切都有观点使用它时你就是在接受这些观点。我的理解是这个区别很像买家具和买宜家家具的区别。定制家具framework让你选择材料、尺寸、风格但你需要花时间设计和等待制作。宜家家具harness已经设计好了你买回家按说明书组装就能用但你不能改变它的基本设计。两者都有价值取决于你的需求和能力。从模型的视角理解为什么需要 HarnessViv 的文章有一个很有意思的角度从模型的视角出发推导出我们为什么需要 harness。这种自底向上的思考方式让我对 harness 的必要性有了更深的理解。模型本身能做什么它们接收文本、图像、音频、视频等数据输出文本。就这样。开箱即用它们无法维持跨交互的持久状态无法执行代码无法访问实时知识无法设置环境和安装包来完成工作。这些都是 harness 层面的功能。LLM 的结构决定了需要某种机制来包装它们才能做有用的工作。举个例子要实现聊天这样的产品体验我们需要把模型包装在一个 while 循环中跟踪之前的消息并添加新的用户消息。读这篇文章的每个人都已经使用过这种 harness。关键思想是我们想把期望的 agent 行为转化为 harness 中的实际功能。这个观点让我意识到harness 工程本质上是在弥合模型能力和实际需求之间的鸿沟。Harness 的核心组件基于 Viv 的分析我总结了 harness 必须包含的几个核心组件以及每个组件存在的理由。文件系统是最基础的 harness 原语。我们希望 agent 有持久存储来处理真实数据、卸载上下文窗口装不下的信息、并在会话间持久化工作。模型只能直接操作上下文窗口内的知识。在有文件系统之前用户必须复制粘贴内容给模型这体验很糟糕而且对自主 agent 不起作用。世界已经在使用文件系统工作所以模型自然在数十亿个 token 上训练了如何使用它们。自然的解决方案是harness 配备文件系统抽象和文件操作工具。文件系统的重要性怎么强调都不为过。它让 agent 有了工作空间来读取数据、代码和文档。工作可以增量添加和卸载而不是把所有东西都放在上下文中。Agent 可以存储中间输出并维护超越单个会话的状态。文件系统还是自然的协作界面多个 agent 和人类可以通过共享文件协调。Git 为文件系统添加版本控制这样 agent 可以跟踪工作、回滚错误、分支实验。Bash 和代码执行则是通用工具。我们希望 agent 自主解决问题而不需要人类预先设计每个工具。今天主流的 agent 执行模式是 ReAct 循环模型推理、通过工具调用采取行动、观察结果、在 while 循环中重复。但 harness 只能执行它有逻辑的工具。与其强迫用户为每个可能的动作构建工具更好的解决方案是给 agent 一个通用工具比如 bash。Bash 加代码执行是朝着给模型一台计算机让它自己搞定其余部分迈出的一大步。模型可以通过代码即时设计自己的工具而不是被限制在固定的预配置工具集中。Harness 仍然配备其他工具但代码执行已经成为自主问题解决的默认通用策略。我认为这是一个重要的设计哲学转变从提供足够的工具转向提供创建工具的能力。沙盒和执行环境也必不可少。Agent 需要一个有正确默认设置的环境这样它们可以安全行动、观察结果并取得进展。我们已经给了模型存储和执行代码的能力但这一切都需要在某个地方发生。在本地运行 agent 生成的代码有风险而且单个本地环境无法扩展到大量 agent 工作负载。沙盒给 agent 提供安全的操作环境。Harness 可以连接到沙盒来运行代码、检查文件、安装依赖并完成任务而不是在本地执行。这创造了代码的安全隔离执行。为了更高安全性harness 可以白名单命令并强制网络隔离。沙盒还能实现规模化因为环境可以按需创建、分散到多个任务工作完成后销毁。好的环境配备好的默认工具。Harness 负责配置工具这样 agent 可以做有用的工作。这包括预安装语言运行时和包、用于 git 和测试的 CLI、用于网页交互和验证的浏览器。浏览器、日志、截图和测试运行器等工具给 agent 提供了观察和分析工作的方法。这帮助它们创建自我验证循环在那里它们可以编写应用代码、运行测试、检查日志并修复错误。内存和搜索用于持续学习。Agent 应该记住它们见过的东西并访问训练时不存在的信息。模型除了权重和当前上下文中的内容外没有额外知识。在无法编辑模型权重的情况下添加知识的唯一方法是通过上下文注入。对于内存文件系统再次成为核心原语。Harness 支持像 AGENTS.md 这样的内存文件标准在 agent 启动时注入上下文。随着 agent 添加和编辑此文件harness 将更新后的文件加载到上下文中。这是一种持续学习形式agent 从一个会话持久存储知识并将该知识注入未来会话。知识截止日期意味着模型无法直接访问新数据比如更新的库版本除非用户直接提供。对于最新知识Web Search 和像 Context7 这样的 MCP 工具帮助 agent 访问超出知识截止日期的信息比如新库版本或训练停止时不存在的当前数据。对抗上下文腐烂也是关键挑战。Agent 性能不应该在工作过程中降低。上下文腐烂描述的是模型在上下文窗口填满时推理和完成任务的能力变差的现象。上下文是宝贵而稀缺的资源所以 harness 需要策略来管理它。今天的 harness 在很大程度上是良好上下文工程的交付机制。压缩解决的是当上下文窗口接近填满时该怎么办。没有压缩当对话超过上下文窗口会发生什么一个选项是 API 报错这不好。Harness 必须为这种情况使用某种策略。所以压缩智能地卸载和总结现有上下文窗口这样 agent 可以继续工作。工具调用卸载帮助减少大型工具输出的影响这些输出可能会嘈杂地堆满上下文窗口而不提供有用信息。Harness 保留超过阈值 token 数的工具输出的头部和尾部 token并将完整输出卸载到文件系统这样模型可以在需要时访问它。数据说话为什么 Harness 比模型更重要说到这里我想回到 Himanshu 提供的那些令人震撼的数据。这些数字最有说服力地证明了 harness 的重要性。CORE-Bench 的测试结果非常直接。Claude Opus 4.5 在一个脚手架下得分 42%换另一个脚手架后得分 78%。同样的模型性能几乎翻倍。Sonnet 4 的表现是 33% vs 47%。Sonnet 4.5 是 44% vs 62%。这不是小幅改进这是质的飞跃。唯一的变量是 harness模型完全相同基准测试完全相同。Cursor 的懒工具加载将 token 使用量削减了 46.9%。这是一个具有统计显著性的数字。同样的任务同样的模型只是改变了工具的加载方式就能节省近一半的 token。考虑到 token 成本和处理速度这种优化的商业价值是巨大的。更极端的案例来自 Vercel。他们删除了 agent 80% 的工具结果 agent 从失败任务变成了完成任务。这个案例特别有意思因为它挑战了我们的直觉。我们通常认为给 agent 更多工具会让它更强大但事实证明工具太多反而会降低性能。Token 从 145463 降到 67483步骤从 100 降到 19延迟从 724 秒降到 141 秒。这是全方位的改进而改变的只是 harness 设计。LangChain 的 deepagents-cli 在 TerminalBench 2.0 上的表现也很说明问题。仅通过改变 harness分数从 52.8% 提升到 66.5%提高了 13.7 个百分点。我反复强调这一点模型完全没变只是改变了围绕模型的脚手架。这些数据让我重新思考了 AI 行业的投资方向。我们看到无数公司花费数百万甚至数十亿美元训练更大更强的模型但可能只需要花一小部分精力优化 harness就能获得同等甚至更好的性能提升。这不是说模型不重要而是说我们严重低估了 harness 的价值。顶尖公司的 Harness 实践Himanshu 详细分析了几家顶尖公司的 harness 实现每家都有独特的设计哲学。Claude Code 采用模型控制循环的理念。它是一个简单的 while(tool_call) 循环没有复杂的 DAG 编排没有竞争的 agent 角色。模型接收消息和工具返回文本结束循环返回工具调用继续循环。Anthropic 明确称之为模型控制循环而不是代码控制模型。这个微妙的措辞差异体现了设计哲学给模型更大的自主权。Claude Code 只提供约 18 个原始工具分四类命令行发现、文件交互、网页访问和编排。设计哲学是原始工具优于集成。更有意思的是Anthropic 选择正则表达式ripgrep而不是向量数据库进行代码搜索理由是 Claude 的代码理解能力足够强可以构建复杂正则表达式而不需要搜索索引。Claude Code 还有一个巧妙设计TodoWrite 工具。从功能上讲它什么都不做纯粹是 harness 层面的技巧——一个无操作工具强制 agent 明确表达和跟踪计划让它在长时间运行中保持正轨。这种设计让我想到有时候最有效的工具不是执行复杂操作的而是帮助 agent 保持清晰思路的简单机制。Cursor 的核心决策是文件作为基本原语。为什么因为文件支持强大搜索、可自然分组、可版本化。他们针对每个前沿模型专门调优 harness。不同模型得到不同工具名称、提示指令和行为指导。这种精细化调优让我意识到通用方案往往不是最优方案。Cursor 的自定义语义搜索特别值得一提。他们的嵌入模型使用 agent 会话轨迹作为训练数据。当 agent 完成任务时Cursor 分析哪些文件本应更早被检索然后训练嵌入模型匹配这些模式。结果是搜索准确率平均提高 12.5%在大型代码库上的代码保留率提高 2.6%。这种从实际使用中学习的方法比任何理论优化都更有效。Manus 则走了另一个极端从推出以来已经重写了五次框架。他们最独特的做法是使用 logit masking 而不是动态移除工具。任何对上下文前端工具定义的更改都会使所有后续 token 的 KV-cache 失效。所以所有约 29 个工具永久加载每步可用性通过约束输出 token 概率控制。Manus 团队得出的最大教训是最大性能提升来自删除东西。复杂工具定义被 shell 执行替代管理 agent被简单交接替代。如果你的 agent harness 在模型变好的同时变复杂那就出问题了。这个观点让我深有感触真正的进步往往来自简化和精简。Progressive Disclosure关键但被忽视的模式Himanshu 特别强调了 progressive disclosure渐进式披露这个概念我认为这是整个 harness 设计中最被低估的模式。Progressive disclosure 借鉴自 UI/UX 设计1980 年代起源于 IBM Research 的 John Carroll1990 年代由 Jakob Nielsen 推广。核心原则只显示现在需要的内容按需揭示复杂性。这直接映射到 agent 设计。就像可折叠菜单减少人类认知负荷分层上下文加载减少 LLM 注意力分散。数据非常有说服力。Claude-Mem 文档显示静态加载注入 25000 个 token效率只有 0.8%。Progressive disclosure 只需 955 个 token效率 100%。这是约 26 倍改进。Cursor 的懒加载实现 46.9% token 削减。Vercel 删除 80% 工具后token 从 145463 降到 67483步骤从 100 降到 19延迟从 724 秒降到 141 秒agent 从失败变成功。各家公司实现方式不同但思路一致。Claude Code 的 SKILL.md 模式技能存储为 .claude/skills/ 文件不预加载到每次对话。与每次加载的 CLAUDE.md 不同技能只在 Claude 检测到相关性时加载。当项目有几十个技能时这防止上下文膨胀。为什么 progressive disclosure 如此重要Liu 等人在 TACL 2024 的论文证明LLM 性能遵循 U 型曲线——相关信息在输入开头或结尾时性能最高在中间时下降。即使长上下文模型也是如此。这就是为什么 harness 重要progressive disclosure 保持输入较小并将新检索信息放在末尾。我的理解是这从根本上挑战了给模型更多上下文总是更好的假设。上下文组织方式比数量更重要。这也解释了为什么同一模型在不同 harness 下性能差异如此巨大。Framework 与 Harness 的模糊边界Tony 指出framework 和 harness 的界限并不总是清晰的而且我认为它也不应该清晰。一些 framework 正在添加类似 harness 的功能。LangChain 是个好例子。他们发布了 Deep Agents明确称之为agent harness位于框架之上。它配备内置规划工具、用于上下文管理的文件系统访问、子 agent 生成和内存持久化。你仍在底层使用 LangChain但 Deep Agents 给你开箱即用的默认设置这样你不必自己把所有东西连接起来。LangChain 实际上在自己的技术栈中区分了三层。LangChain原始库是 framework。LangGraph 是他们称为agent runtime代理运行时的东西处理执行、状态管理和持久性。Deep Agents 是位于两者之上的 harness。这是一家公司跨越整个光谱。用于组合 agent 的 framework用于可靠执行的 runtime用于开箱即用的 harness。这是一家 framework 公司向光谱右侧移动。Deep Agents 仍然是模块化的。你可以交换后端、配置工具、调整提示。但它给你一个工作系统不需要你组装每一块。另一方面harness 也没有听起来那么锁定。拿 OpenClaw 来说开箱即用时最有观点但如果你下载源代码可以交换实现。你可以改变内存工作方式、调整 agent 循环、修改工具处理。只是大多数人不会这样做因为默认已经工作了。区别在于开始时已经决定了什么。Harness 配备内置决策。Framework 暴露选项。如果使用 harness你接受大多数决策并在边缘配置。如果使用 framework你自己做决策并组装系统。长时程自主执行的挑战Viv 特别强调了长时程自主执行的重要性和挑战。自主软件创建是编码 agent 的圣杯但今天的模型存在早期停止、复杂问题分解困难、以及工作跨越多个上下文窗口时的不连贯问题。好的 harness 必须围绕所有这些设计。这正是早期 harness 原语开始复合的地方。长时程工作需要持久状态、规划、观察和验证以在多个上下文窗口间持续工作。文件系统和 git 用于跨会话跟踪工作。Agent 在长任务中产生数百万 token文件系统持久捕获工作以随时间跟踪进展。添加 git 允许新 agent 快速了解最新工作和项目历史。对于多个 agent 协作文件系统也充当共享工作账本。Ralph Loop 是一个有意思的 harness 模式用于继续工作。它通过钩子拦截模型的退出尝试在干净的上下文窗口中重新注入原始提示强制 agent 针对完成目标继续工作。文件系统使这成为可能因为每次迭代从新上下文开始但从上一次迭代读取状态。规划和自我验证让 agent 保持正轨。规划是模型将目标分解为一系列步骤。Harness 通过良好提示和注入如何使用文件系统中计划文件的提醒来支持这一点。完成每一步后agent 从通过自我验证检查工作正确性中受益。Harness 中的钩子可以运行预定义测试套件在失败时循环回模型并带上错误消息或者可以提示模型独立自我评估代码。验证将解决方案建立在测试上并为自我改进创建反馈信号。Harness 的未来三位作者都对 harness 的未来有自己的看法我觉得他们的观点很有启发性。Himanshu 注意到模型训练和 harness 设计的耦合。今天的 agent 产品如 Claude Code 和 Codex 在模型后训练时将 harness 纳入循环。这帮助模型在 harness 设计者认为它们应该原生擅长的动作上改进如文件系统操作、bash 执行、规划或与子 agent 并行工作。这创造了一个反馈循环。有用的原语被发现、添加到 harness然后在训练下一代模型时使用。随着这个循环重复模型在训练时所在的 harness 中变得更有能力。但这种共同演化对泛化有有趣的副作用。它以改变工具逻辑导致模型性能下降的方式表现出来。一个真正智能的模型应该不难在补丁方法间切换但在循环中训练会创造这种过拟合。但这并不意味着对你任务最好的 harness 就是模型后训练时用的那个。Terminal Bench 2.0 排行榜是个好例子。Opus 4.6 在 Claude Code 中的得分远低于在其他 harness 中的 Opus 4.6。通过只改变 harness 可以榨取很多价值。Viv 认为随着模型变得更有能力今天存在于 harness 中的一些东西会被吸收到模型中。模型会在规划、自我验证和长时程连贯性上原生变好因此需要更少的上下文注入。这表明 harness 随时间会变得不那么重要。但就像提示工程今天继续有价值一样harness 工程可能会继续对构建好的 agent 有用。Harness 今天确实在修补模型缺陷但它们也围绕模型智能构建系统以使其更有效。配置良好的环境、正确的工具、持久状态和验证循环让任何模型更高效无论其基础智能如何。Viv 提到 harness 工程是 LangChain 用来改进其 harness 构建库 deepagents 的一个非常活跃的研究领域。一些开放和有趣的问题包括编排数百个 agent 在共享代码库上并行工作分析自己轨迹以识别和修复 harness 级别失败模式的 agent根据给定任务即时动态组装正确工具和上下文而不是预配置的 harness。我对 Harness 未来的思考读完这三位作者的分析后,我有一些自己的深度思考。我认为 harness 工程正在成为一门独立的学科。就像软件工程从计算机科学中分离出来,成为一个有自己方法论、最佳实践和工具链的领域一样,harness 工程也在经历类似的过程。我们已经看到了一些早期信号:专门的 harness 构建库(如 LangChain 的 Deep Agents)、harness 设计模式的总结(如 12 Factor Agents)、以及用于评估 harness 质量的基准测试(如 CORE-Bench、Terminal Bench)。这种专业化很重要,因为它降低了构建高质量 AI agent 的门槛。当 harness 工程成为一门成熟的学科时,开发者不需要从零开始摸索,可以借鉴已验证的模式和最佳实践。这会加速整个行业的创新速度。我也注意到一个有趣的悖论:虽然模型在变得更强大,但对 harness 的需求不会消失,只是会转变形式。早期的 harness 主要是在弥补模型的不足,比如给模型添加文件系统访问、代码执行能力等基础功能。但随着这些能力逐渐被模型原生支持,harness 的角色会从能力补充转向性能优化和可靠性保证。就像现代编程语言已经有了垃圾回收、类型系统等高级特性,但我们仍然需要框架和库来构建复杂应用一样,未来即使模型本身变得非常强大,我们仍然需要 harness 来优化性能、管理复杂性、确保可靠性。Progressive disclosure、上下文管理、错误恢复这些问题不会因为模型变强而消失。从商业角度看,我认为 harness 工程能力将成为 AI 公司的核心竞争力之一。模型本身正在快速商品化,任何公司都可以通过 API 访问最先进的模型。但如何有效利用这些模型、如何设计出让模型发挥最大效能的系统,这才是真正的护城河。这就像云计算时代,底层基础设施(AWS、Azure、GCP)是商品,但在这些基础设施上构建的应用和平台才是真正的价值所在。我还思考了 harness 设计的一个哲学问题:应该给模型多大的自主权?Claude Code 的模型控制循环代表了一个极端,给模型最大的自由度。而更传统的方法则倾向于用代码严格控制 agent 的每一步。我认为最佳平衡点会随着模型能力的提升而移动。当模型还比较弱时,需要更多的 harness 级别控制和约束。但随着模型变强,给它们更多自主权会带来更好的结果。这个平衡点的把握,需要深刻理解模型的能力边界和任务的复杂度。Tony 提出的你解决什么问题决定你需要 framework 还是 harness这个观点让我想到,也许我们需要一个更细粒度的分类。在 framework 和 harness 之间,可能还有很多中间状态。比如可配置的 harness、“模块化的 harness”、领域特定的 harness等等。未来可能会出现更多这样的中间形态,让开发者可以根据具体需求选择合适的抽象层次。最后,我想强调 Himanshu 提到的一个关键洞察:最好的团队一直在简化。Manus 五次重写,每次都删除东西。Anthropic 设计 Claude Code 是为了随模型改进而缩小。这个趋势告诉我们,harness 工程的终极目标不是构建一个功能齐全、无所不包的系统,而是找到最小必要集——那些真正不可或缺、无法被模型原生能力替代的部分。这需要持续的迭代、测试和勇于删除的决心。Agent Model Harness。这个简单的等式背后,是关于如何构建真正有用的 AI 系统的深刻洞察。模型提供智能,harness 让智能有用。在追逐更强大模型的同时,我们不应该忽视 harness 工程的价值。因为最终,没有人购买引擎,大家购买的是完整的汽车。假如你从2026年开始学大模型按这个步骤走准能稳步进阶。接下来告诉你一条最快的邪修路线3个月即可成为模型大师薪资直接起飞。阶段1:大模型基础阶段2:RAG应用开发工程阶段3:大模型Agent应用架构阶段4:大模型微调与私有化部署配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】