最近两年,做 AI Agent 项目的团队在聊需求时,总会反复提到一个词——"harness"。这个词在英文工程语境里出现频率极高,但在国内的中文资料里几乎找不到一个能让一线工程师点头的翻译。直译"挽具"显然不对,有人翻译成"框架"又和 framework 撞车,有人叫"执行器"但只覆盖了其中一个组件。本文想做一件事:用真实工程语言,把这个被严重低估的概念讲清楚。 一、问题的起点:为什么不能只谈模
最近两年,做 AI Agent 项目的团队在聊需求时,总会反复提到一个词——"harness"。这个词在英文工程语境里出现频率极高,但在国内的中文资料里几乎找不到一个能让一线工程师点头的翻译。直译"挽具"显然不对,有人翻译成"框架"又和 framework 撞车,有人叫"执行器"但只覆盖了其中一个组件。本文想做一件事:用真实工程语言,把这个被严重低估的概念讲清楚。
一、问题的起点:为什么不能只谈模型
很长一段时间,业内谈 AI Agent 能力,默认谈的是模型。Claude 4 比 3.5 强在哪,Gemini 在某个基准上多了 2.3 个百分点,OpenAI 的 o3 又把数学题做对了——所有讨论都围绕模型本身的能力图谱展开。这种叙事有一个隐含假设:模型是 Agent 能力的上限,工程只能"别把它用坏"。
但 2026 年的工程现实正在系统性地推翻这个假设。Tom Roderick 在 8 月 28 日发表的一篇文章《Obsessing over AI agent harnesses》里,把这件事讲得很直白:A model is only one component of an AI agent(模型只是 AI Agent 的一个组件)。模型之外,围绕它的整个工程化系统——prompt、tools、memory、context、model routing、retries、evaluators、sub-agents、permissions、orchestration——这些才是真正决定 Agent 能跑多远、跑多稳的部分。
这一整套围绕模型的工程化外壳,就是 harness。
为了把概念钉死,这里给出一个工程可用的定义:**Harness 是把一个大语言模型包装成一个能在真实业务场景里持续运行、可靠交付任务的全部工程化外壳,包括但远不限于模型调用本身。** 这个外壳负责模型无法为自己做的所有事:解析目标、组装上下文、调度工具、保存记忆、容错重试、调度子任务、决定什么时候让模型再想想、什么时候必须停下来让人看一眼。
这一定义的关键在于"工程化外壳"四个字。它不是一个 Python 包,不是 LangChain 也不是 LlamaIndex,它是一种职责的集合,任何把这套职责做扎实的代码——无论叫什么名字——都是 harness。
二、Harness 不是一个静态系统,它是会自己进化的
把 harness 理解成"工程化外壳"之后,有一种偷懒的解法是把它当成一个静态配置文件:Prompt 写好、工具挂上、模型选好,然后跑就完了。这种理解在 Demo 阶段勉强能用,但一旦进入生产,马上会撞上一类问题——模型本身的版本更替、工具的 API 变更、业务场景的演化,任何一项都会让这个静态配置快速过时。
但这只是麻烦的开始。真正让 harness 这个概念变得棘手的,是它正在变得**动态**。Roderick 在文章里列出了一个清单,描述一个 Harness 在生产中可能自发做出的改变:
- 修改自己的 prompt 或操作指令;
- 写入、修改、合并或删除记忆;
- 改变工作上下文中保留哪些信息;
- 为某个子任务选择不同的模型;
- 用其它模型创建子 Agent;
- 改变任务路由或结果评估的策略。
读到这里,一个训练有素的工程师应该会停下来想一下这意味着什么。这意味着 Harness 自身变成了 Agent 的一个**可观察、可修改的状态**。Agent 不只是在 Harness 上跑任务,Agent 在跑的过程中,Harness 的某些部分正在被 Agent 自己改写。
这件事之所以重要,是因为它直接挑战了软件工程几十年来一个最基本的假设:**被测对象和测试基础设施是分离的。** 我们写一个排序算法,然后用一堆测试用例验证它是否正确。这里的关键是,排序算法自己不会修改测试套件。但 Harness 化后的 Agent 系统正在破坏这种分离:被测的"对象"——即 Agent 的行为——越来越有能力修改决定它行为的基础设施。
三、为什么这件事突然变得紧迫
Harness 概念的紧迫性来自三股压力的叠加。
第一股压力是**真实工程部署的反馈**。到 2026 年,把 Agent 接入生产流程的团队越来越多,踩的坑越来越具体。一个常见的故事是:Agent 在某个内部基准上从 82 分提升到了 87 分,所有人很兴奋地上线,结果两周后客服部门投诉某个长尾场景的错误率从 1.2% 暴涨到 9%。查日志发现,新版本为了追求基准分数,对记忆做了一次"激进压缩",刚好把那条长尾场景依赖的上下文给丢了。
这个故事不是假设。Roderick 的文章里给出了一个几乎一模一样的假设:Imagine an agent changes its memory strategy and improves benchmark performance by 5%... But what if it also forgets information that allowed it to handle a class of problems the benchmark did not happen to sample?(想象一下,一个 Agent 改了记忆策略,基准性能提升了 5%……但如果它恰好忘了处理某类问题时需要的信息呢?)
第二股压力是**主流 Agent 框架已经把 Harness 作为一个一等公民来组织代码**。一个直接的证据是 LangChain 在 9 月 11 日仍在积极维护的 deepagents 仓库,这个仓库的自我描述只有一句话:**"The batteries-included agent harness"(开箱即用的 Agent Harness)**。29.3k stars、4.1k forks、280 个 release、过去一个月仍在高频率合并 PR——这个量级说明它不再是一个研究项目,而是大量真实生产 Agent 的底层依赖。
deepagents 仓库的 README 还透露了另一件重要的事:它明文标注"Inspired by Claude Code: an attempt to identify what makes it general-purpose, and push that further"(受 Claude Code 启发,目标是识别是什么让它变得通用,并把这一点推到更远)。换句话说,Anthropic 的 Claude Code 是整个 2026 年工业界 Agent Harness 的事实标杆,而 LangChain 的 deepagents 是把这件事开源复刻、社区化迭代的代表。
这件事对一个长期用框架写业务的人意义重大:LangChain 不是把它叫 framework,而是叫 harness——这个命名选择不是营销,而是承认 Agent 系统的复杂度已经超过"框架"这个词能承载的边界。
第三股压力是**安全模型的根本性变化**。deepagents 仓库的安全章节给出了一个非常坦诚的说明:**"Deep Agents follows a 'trust the LLM' model. The agent can do anything its tools allow. Enforce boundaries at the tool/sandbox level, not by expecting the model to self-police."**(深度 Agent 采用"信任大模型"模式,Agent 能做其工具允许的任何事,边界要在工具/沙箱层强制执行,而不能指望模型自律。)
这句话翻译成工程语言就是:Harness 的安全责任完全落在工具实现和沙箱配置上,模型层的"自我约束"被认为不可靠。这和传统软件工程里"输入校验、权限隔离、操作审计"的范式完全一致,但在 Agent 场景里,这种范式被推到了极致——因为模型层的输出本质上是不可完全预测的自然语言,任何指望"模型会拒绝恶意请求"的安全模型都是脆弱的。
四、Harness 的真实工程结构:七个核心组件
把上面这些抽象讨论落回工程实现,Harness 大致由七个核心组件组成。每个组件都有明确的职责边界,任何一项缺失都会让 Agent 在某个场景里失效。
**第一个组件是 Prompt 编排**。这是最容易被低估的一项。一个生产可用的 Prompt 不是单段系统提示,而是一个分层结构:角色定义、任务约束、工具调用规范、输出格式要求、失败处理协议、安全边界声明。Prompt 编排还要支持动态拼装——不同任务、不同上下文、不同模型,拼出来的 Prompt 应该不一样。
**第二个组件是工具注册与调用层**。这是 Harness 的手脚。每个工具需要明确的 schema、参数校验、调用权限、超时配置、重试策略、错误分类(可重试 vs 不可重试)。deepagents 的目录里有一个 `.mcp.json`,说明它已经把 MCP(Model Context Protocol)作为工具接入的标准化协议——这在 2026 年已经是工业共识。
**第三个组件是记忆系统**。这里的"记忆"至少分三层:短期工作记忆(当前任务的上下文)、长期事实记忆(跨任务持久化的知识)、情景记忆(历史任务的成功/失败案例)。每一层的存储介质、检索方式、淘汰策略都不同。一个 Harness 必须明确回答:什么时候记、记到哪里、什么时候忘、怎么检索。Roderick 文章里那个"基准提升 5% 但长尾场景崩了"的故事,根因就是这一层没有做好隔离。
**第四个组件是上下文管理**。和记忆不同,上下文关注的是当前这一次会话内窗口里的内容。Harness 必须决定:上下文满了之后怎么截断?是按 token 数截断、按消息时间截断、按语义重要性截断、还是按任务相关性截断?截断后的关键信息是否需要提前持久化到记忆层?这件事在长任务场景里几乎决定了 Agent 的可用性。
**第五个组件是模型路由**。同一个 Agent 内部,不同子任务可能需要不同的模型:简单分类用小模型、复杂推理用大模型、长文本处理用支持大窗口的模型、成本敏感的批处理用便宜模型。Harness 必须有能力在运行时做这种调度——这正是 Roderick 列出的"动态行为"之一。
**第六个组件是评估器(Evaluator)**。这是 Harness 的质检部门。它对 Agent 的中间输出和最终输出做检查,判断是否达标。Evaluator 可能是基于规则的(格式校验、必填字段校验),也可能是基于模型的(用另一个 LLM 评判输出质量)。一个生产级 Harness 必须有完善的 Evaluator,因为没有评估,Harness 的自我修改就是黑盒演化。
**第七个组件是权限与沙箱**。这是 Harness 的最后一道防线。deepagents 的安全章节把这件事讲得很清楚:边界不在模型层,在工具/沙箱层。一个生产 Harness 必须实现:工具级权限(哪些 Agent 能调哪些工具)、操作级审批(关键操作是否需要人工二次确认)、资源级配额(每个 Agent 能消耗多少 token、多少时间、多少磁盘)、审计日志(所有操作可追溯)。
把这七个组件画一张图,大致就是:Prompt 在最外层定义行为边界,工具层负责执行,记忆和上下文负责信息存取,模型路由负责智力调度,Evaluator 负责质量校验,权限沙箱负责安全保障。少任何一个,Agent 在生产里都会出某种特定的毛病。
五、一个绕不开的工程问题:Harness 自己怎么度量
Harness 的动态化特性引出了一个看似哲学、实则工程的硬问题:**当 Harness 自己也在改变时,你怎么判断它变得更好,而不是只是变得不一样?**
传统软件工程的回答很干脆:跑回归测试。Regression test 是软件工程几十年的结晶,它解决的是"我新提交的代码有没有把以前能跑的东西搞坏"这个基本问题。但这套范式在 Harness 化后的 Agent 系统里遇到了根本性挑战——前面提过,被测的"对象"和测试基础设施的边界正在模糊。
Roderick 在文章里给出了一个很有意思的度量框架,核心是把"提升"和"只是优化"区分开来。他建议把每一次 Harness 的改变拆解成三个独立维度来评估:
- **Retention(保留度)**:改完之后,原来能做的事情现在还能做吗?
- **Loss(损失度)**:改完之后,原来能观察到的某些行为是否消失了?
- **Gain(增益度)**:改完之后,出现了哪些原来不可能出现的新行为?
这个框架的精妙之处在于,它把"平均分数提升"这个单维度指标分解成了一个三维向量。一个 Harness 改动可能 Retention 高(大部分能力保留)、Loss 中等(某个边缘能力退化)、Gain 高(获得新能力)——这时候总体评价是"值得上";另一个改动可能 Retention 低(大面积能力丧失)、Loss 低(没丢什么)、Gain 极高(某项基准暴涨)——这时候就要警惕,这是经典的"优化了指标但丢了能力"模式。
Roderick 还提到了这个框架的理论基础:Blackwell 的信息经济学理论(Blackwell's theory of information),它能严格地比较两个信息结构在保留有用区分度方面的优劣。这个理论本来用于经济学中的决策比较,Roderick 认为它可以被改造来评估 Harness 状态的改变是否真的"信息更丰富",而不是"形式上更优"。
这套度量框架对企业级 AI 部署的实际意义在于:**它把"AI 治理"从一个政策问题重新定位成了一个工程问题。** 当组织里有 AI 系统在持续自主调整它的运行时行为时,治理不再是"冻结版本、严格审批",而是要回答:这次自主调整是变好了还是变坏了?有没有悄悄破坏我们关心的某些行为?我们能否解释为什么当前配置优于之前那个?这些问题的答案,只能从一个工程化的 Harness 度量框架里来,不能从一份治理手册里来。
六、deepagents 仓库的工程启示
把 deepagents 这个具体的开源项目作为解剖样本,可以看到工业界目前是如何组织一个 Harness 的代码结构的。
仓库主目录分了几个明显的大块:`libs/` 是核心库,包括 `deepagents` 主包和 `talon`(终端 Agent 运行时);`examples/` 是用例;`openwiki/` 是文档系统;.agents/skills/ 是 Agent 的"技能"机制;.mcp.json 显式声明 MCP 集成;.github/workflows 是 CI/CD。
最值得说的是 `.agents/skills/textual-screenshot` 这种目录结构。它说明在 deepagents 的设计里,**技能(skill)是一等公民**,每个技能是一个有自己目录、文档、可能还有自己代码的模块。这和传统框架里"函数"的概念完全不同——技能不仅是可调用的代码,它还可以有自己的配置、自己的依赖、自己的 Prompt 模板、自己的文档,甚至自己的测试。
这种"技能即模块"的设计在工程上有一个直接的好处:**Harness 的可组合性大幅提升。** 不同的业务场景可以挑选不同的技能组合,不需要从零搭建一个完整的 Agent。这种设计也直接回应了"动态 Harness"的挑战——技能可以被运行时发现、加载、卸载,而不需要重新部署整个系统。
talon 这个子模块的存在也值得注意。它专门负责"终端 Agent 运行时",说明 deepagents 已经把"Agent 在终端环境里怎么跑"这件事作为一个独立的子系统来对待。这呼应了 Claude Code 的核心定位——终端是 Agent 最自然的接口之一,因为所有开发工具、运维工具、数据处理工具最终都可以通过命令行访问。一个好的 Harness 必须把终端作为一等公民来支持,而不是把它当成"附加功能"。
七、Harness Engineering 作为一门新工程学科
把上面的讨论放在一起,可以得出一个结论:**Harness 不是 Agent 系统的某个组件,Harness 正在成为一种新的工程学科。** Roderick 在文章标题里用复数"harnesses",而不是单数"a harness",这个用词是有意为之的——他想要强调,未来组织里会同时存在多个 Harness,它们各自承载不同的业务场景,需要被独立地设计、度量、治理。
deepagents 仓库的 topics 标签里有 "harness-engineering" 这个词——这是 GitHub 的官方标签系统,意味着已经有相当数量的工程师开始把 Harness Engineering 作为一种独立的技术身份来认同。这是一个信号:这件事已经过了"少数先行者在做"的阶段,正在进入"形成共同话语"的阶段。
对企业里的 AI 工程团队来说,这件事的直接含义是:**评估一个 Agent 项目是否成熟,不应该只看模型选得多好、Prompt 写得多么精妙,更应该看 Harness 本身是不是被当作工程对象来对待。** 一个生产级的 Agent 项目,应该有:清晰的 Prompt 版本管理、可观测的工具调用链、结构化的记忆系统、明确的上下文策略、可量化的评估器、严格的权限沙箱、可解释的回归度量。这七项加起来,就是 Harness Engineering 的最小完备集合。
八、写在最后
回到本文最初的问题——Harness 到底是什么?
一句话总结:**Harness 是把一个大语言模型变成一个能在生产里持续干活、不出大乱子的工程系统的全部外壳。** 它不是某个具体的产品,不是 LangChain,不是 Claude Code,而是一类工程职责的集合,任何把这套职责做扎实的代码——无论叫什么名字——都是 Harness。
这件事对中国 AI 工程界的含义在于,过去两年大量团队的精力被吸到了"哪个模型更强"这个维度上,但 2026 年的工业现实已经清楚显示:**模型能力的天花板已经被多家公司同时顶到差不多的位置,真正的差异化正在向 Harness 层迁移。** 一个团队对 Harness 的工程化理解深度,将直接决定它在下一轮 Agent 落地竞争中能跑多远。
理解 Harness,不是理解一个新名词,而是理解 AI Agent 工程的真实工作界面。
