AI 圈都在谈 Harness，它到底是什么？

最近，在大模型和 AI Agent 领域，经常能看到一个词：

Harness。

有人把它称为“智能体框架”，有人把它理解为“大模型外壳”，还有人认为，未来 AI 产品之间真正的差距，可能不再只是模型，而是 Harness。

那么，Harness 到底是什么？

先说结论：

Harness 是包裹在大模型外面，负责让模型真正执行任务的一整套运行系统。

大模型负责理解、推理和生成，Harness 则负责给模型提供工具、记忆、上下文、权限、反馈和执行流程。

可以用一个简单公式理解：

AI Agent = 大模型 + Harness + 工具与运行环境

如果把大模型比作大脑，Harness 就像人的身体、感官、工作台以及行动规则。

只有大脑，没有这些外部能力，模型再聪明，也只能坐在那里聊天。

一、为什么突然开始强调 Harness？

过去几年，大模型行业最关心的是模型本身。

参数有多大？

上下文有多长？

推理能力有多强？

代码能力怎么样？

于是，我们不断比较 GPT、Claude、Gemini、DeepSeek、Qwen 等模型。

但当人们真正开始开发 AI Agent 时，逐渐发现了一个问题：

模型能力强，不代表 Agent 就一定好用。

同一个模型，放在不同的 AI 编程工具里，表现可能完全不同。

例如，同样使用一个能力很强的大模型：

在普通聊天窗口中，它只能给你一段代码建议；

在 AI 编程工具中，它却可以读取整个项目、搜索文件、修改代码、运行测试、查看报错，然后继续修复问题。

模型可能是同一个模型，为什么结果差别这么大？

差别就在模型外面的 Harness。

现在越来越多的行业讨论，把 Harness 简化理解为：

除了模型之外，智能体系统剩下的所有关键能力。

例如 Claude Code、Codex CLI、Aider、Cline 和 OpenHands，真正决定使用体验的，不只是底层接入了哪个模型，还包括它们如何管理上下文、调用工具、执行命令和验证结果。

二、Harness 这个词是什么意思？

Harness 原本有“马具”“挽具”的含义。

马本身有力量，但需要缰绳、鞍具和控制结构，才能把力量转化为稳定、可控的行动。

在软件工程中，也早已有“Test Harness”，即测试支撑系统。

它负责准备测试环境、输入数据、执行测试、记录结果并判断程序是否通过。

到了大模型时代，Harness 的含义被进一步扩展。

它指的是：

围绕大模型搭建的一套运行、控制和执行机制。

它负责告诉模型：

现在的任务是什么；
可以读取哪些信息；
可以使用哪些工具；
应该先做什么、后做什么；
操作失败后怎么办；
怎样判断任务已经完成；
哪些操作可以执行；
哪些危险操作必须禁止。

因此，Harness 不是模型，也不等同于一个提示词。

它更像是一个面向 AI Agent 的“操作系统”。

三、一个最简单的例子

假设你对一个大模型说：

帮我检查这个 Android 项目，找到导致应用闪退的问题，并修复它。

如果只有大模型，它其实什么也做不了。

因为它看不到你的项目代码，也无法运行程序，更无法查看崩溃日志。

它只能回答：

请提供错误日志和相关代码，我可以帮你分析。

但如果这个模型拥有一套完善的 Harness，情况就完全不同了。

Harness 可以帮助模型：

读取项目目录；
搜索相关 Kotlin 文件；
查找崩溃日志；
分析调用链；
修改代码；
执行 Gradle 编译；
运行单元测试；
读取测试失败信息；
再次修改代码；
最后生成修改说明。

在这个过程中，大模型负责分析和决策，Harness 负责连接模型与真实的软件环境。

所以，真正完成任务的并不是模型单独的能力，而是：

模型、Harness 和运行环境共同组成的系统。

近期关于 AI Harness Engineering 的研究，也开始把能力归因从“模型能不能生成代码”，转向“模型、Harness 与环境组成的系统，能不能产生可验证、可维护的结果”。

四、Harness 主要包含哪些能力？

一个完整的 Agent Harness，通常包含下面几个核心部分。

1. 上下文管理

大模型并不是知道得越多越好。

如果一次性把整个项目、所有聊天记录和几十份文档全部塞给模型，不仅成本很高，还容易让模型抓不住重点。

Harness 需要判断：

哪些文件与当前任务有关；
哪些历史记录需要保留；
哪些内容已经过期；
哪些信息应该放进当前上下文；
上下文过长时应该删除什么。

好的 Harness 不只是“给模型更多内容”，而是给模型刚好需要的内容。

这就是为什么有些 AI 编程工具能够快速找到相关代码，而有些工具即使读取了整个项目，仍然会答非所问。

2. 工具调用

大模型本身只能生成文字或结构化内容。

要真正完成任务，它必须使用外部工具。

例如：

搜索网页；
查询数据库；
读取文件；
修改代码；
执行 Shell 命令；
调用企业接口；
发送邮件；
操作浏览器；
创建日程；
运行测试。

Harness 负责把这些工具以模型能够理解的方式提供出来。

它还要处理很多现实问题：

工具需要什么参数？

调用失败后是否重试？

返回结果太长怎么办？

工具之间是否存在先后依赖？

模型能不能连续调用多个工具？

工具调用并不是简单地开放几个 API，而是需要完整的调度机制。

3. 任务循环

普通聊天通常是一问一答。

但复杂的 Agent 任务往往需要多轮执行：

观察环境 → 制定计划 → 调用工具 → 获取结果 → 判断问题 → 再次行动。

例如，AI 修复一个 Bug 时，不可能只执行一次。

它可能先修改代码，然后发现编译失败；根据编译错误继续修改，再运行测试；测试通过以后，还要检查是否影响其他功能。

Harness 负责维持这个循环。

它要决定：

什么时候继续执行；
什么时候重新规划；
什么时候回退；
什么时候向用户提问；
什么时候可以宣布任务完成。

没有任务循环，大模型只能给出建议。

有了任务循环，它才开始像一个真正的执行者。

4. 记忆与状态

大模型每次调用，本质上都更像一次新的计算。

如果没有外部系统保存状态，它很容易忘记之前做过什么。

Harness 通常需要记录：

当前任务进展；
已经读取过哪些文件；
已经执行过哪些命令；
哪些方案失败过；
用户有哪些长期偏好；
上一次任务停在什么位置。

这里的记忆不只是聊天记录。

真正有价值的记忆，应该经过筛选、分类和更新。

否则，记忆越多，错误信息和过期信息也可能越多。

5. 权限与安全控制

如果给 AI Agent 文件权限、网络权限和命令执行权限，它的能力会大幅提升。

风险也会随之增加。

例如，模型可能：

删除重要文件；
执行危险命令；
泄露敏感信息；
调用成本过高的接口；
修改生产数据库；
向错误的人发送邮件。

因此，Harness 必须控制模型能够做什么。

常见机制包括：

只读权限；
文件目录隔离；
沙箱执行；
高风险操作确认；
命令白名单和黑名单；
密钥隔离；
操作日志；
成本和次数限制。

模型负责提出行动，Harness 负责判断这个行动是否允许发生。

6. 结果验证

这是 Harness 中非常关键，却经常被忽略的一部分。

大模型说“我已经完成了”，不代表任务真的完成了。

例如，大模型修改完代码后，可能自信地说：

问题已经解决。

但实际上代码可能根本无法编译。

因此，Harness 需要提供验证机制。

例如：

修改代码后自动编译；
修复 Bug 后运行测试；
创建网页后检查页面能否打开；
修改接口后执行真实请求；
生成文件后检查格式；
操作数据库后核对数据结果。

好的 Agent 不是只会执行，更要会验证。

执行和验证形成闭环，才是真正可靠的自动化。

五、Harness 和 Agent Framework 有什么区别？

很多人容易把 Harness 和 LangChain、AutoGen、CrewAI 等 Agent Framework 混在一起。

两者确实有重叠，但关注点不同。

Agent Framework 更像开发工具箱。

它提供模型调用、工作流、工具注册、多智能体协作等基础能力，帮助开发者搭建 Agent。

Harness 更关注 Agent 实际运行时的完整支撑环境。

它不仅包括框架代码，还可能包括：

上下文选择；
文件系统；
沙箱；
权限控制；
命令执行；
状态保存；
错误恢复；
测试验证；
运行日志；
人工介入机制。

因此可以简单理解为：

Framework 帮助你开发 Agent，Harness 负责让 Agent 真正稳定地工作。

在实际产品里，两者的边界并不绝对。

有些框架逐渐加入了 Harness 能力，而一些成熟的 Harness 本身也提供开发框架。

六、Harness 和 MCP 又是什么关系？

MCP 是 Model Context Protocol，即模型上下文协议。

它解决的主要问题是：

如何用统一方式，把外部工具和数据源连接给大模型。

例如，开发者可以通过 MCP，让模型访问 GitHub、数据库、文件系统或企业系统。

但 MCP 本身通常不会完整解决：

任务如何规划；
工具应该按什么顺序调用；
上下文如何裁剪；
状态如何持续；
失败后怎样恢复；
任务怎样验证完成；
高风险操作如何审批。

这些通常属于 Harness 的职责。

所以可以这样理解：

MCP 像统一插座，Harness 像管理所有设备运行的控制系统。

MCP 可以是 Harness 中非常重要的一部分，但它并不等于 Harness。

七、Harness 和工作流有什么区别？

工作流一般是提前定义好的。

例如：

收到邮件 → 提取附件 → 识别内容 → 写入表格 → 发送通知。

每一步通常比较明确。

Harness 支撑的 Agent 则更加动态。

它可以根据运行结果，临时决定下一步做什么。

例如：

先搜索代码；
找不到问题，再读取日志；
日志信息不足，再运行测试；
测试失败后，根据错误修改代码；
如果风险较高，再请求人工确认。

工作流更像一条提前铺设好的铁路。

Harness 则像一套能够导航、判断路况、调整路线并处理意外的驾驶系统。

当然，在真实应用中，二者经常结合。

确定性强的部分使用工作流，复杂、模糊的部分交给 Agent 决策。

八、为什么 Harness 可能比模型更重要？

大模型之间的能力差距仍然存在。

但随着主流模型能力不断提高，很多产品的差异已经不完全取决于模型。

例如，两款 AI 编程工具使用同一个大模型，最终体验仍可能完全不同。

原因可能是：

一款工具能够准确找到相关代码，另一款总是读取无关文件；

一款工具会自动运行测试，另一款只修改代码；

一款工具能够记住项目结构，另一款每次都要重新理解；

一款工具失败后会自动恢复，另一款遇到报错就停止；

一款工具能够控制权限，另一款可能直接执行危险命令。

这些差异大多不是模型本身带来的，而是 Harness 的差异。

因此，未来 AI 产品的竞争可能逐渐从：

谁接入了更强的模型？

转向：

谁能把模型组织得更好、控制得更稳、验证得更可靠？

关于 Agentic AI 的一些最新研究，也开始提出“系统扩展”而不仅是“模型扩展”：未来的能力提升不仅依赖更强的基础模型，也依赖上下文治理、长期记忆、工具路由、编排和验证机制共同组成的 Harness。

九、普通开发者该如何理解 Harness？

对于普通开发者来说，不需要一开始就搭建一套非常复杂的 Harness。

可以先从最小结构开始。

例如，要开发一个代码检查 Agent，可以给它提供：

一个大模型；
项目文件读取工具；
代码搜索工具；
编译和测试工具；
一个简单的任务循环；
一套命令权限规则；
一个完成验证条件。

这已经是一个基础 Harness。

随着任务越来越复杂，再逐步增加：

长期记忆；
上下文压缩；
错误重试；
多 Agent 协作；
人工审批；
日志追踪；
成本控制；
安全隔离。

关键不是一次性做出一个“万能 Agent”。

而是先想清楚：

模型要完成这件事，还缺少哪些外部条件？

把这些外部条件组织起来，就是在设计 Harness。

十、Harness 不是越复杂越好

Harness 很重要，但并不代表功能越多越好。

复杂的 Harness 也可能带来新的问题：

上下文规则太多；
工具数量太多；
执行链路难以排查；
模型不知道该调用哪个工具；
自动重试导致成本失控；
记忆中混入错误信息；
多 Agent 互相重复工作；
系统行为难以预测。

一个好的 Harness，不是把所有能力都交给模型。

而是合理划分确定性与不确定性。

可以由普通代码解决的问题，不一定要让模型决定；

可以用固定规则验证的问题，不应该只相信模型判断；

涉及高风险的操作，不应该让 Agent 完全自主执行。

Harness 的价值不是让 AI 获得无限自由，而是让 AI 在合理边界内发挥能力。

结语

大模型解决的是“会不会思考和生成”的问题。

Harness 解决的是“能不能真正行动”的问题。

模型可以理解需求，Harness 则帮助它读取信息、调用工具、执行任务、保存状态、控制风险并验证结果。

没有 Harness，大模型只是一个很聪明的聊天机器人。

有了 Harness，它才有可能成为一个真正能工作的 AI Agent。

所以，未来我们评价一个 AI 产品时，可能不能只问：

它使用了什么模型？

还要继续问：

它给这个模型配了一套怎样的 Harness？