为什么说 Agent = Model + Harness？

眼睛：让 Agent 能看到外部信息
双手：让 Agent 能调用工具和执行操作
记忆：让 Agent 知道之前做过什么
规则：告诉 Agent 什么能做、什么不能做
工作台：让 Agent 可以读写文件、运行命令
测试系统：检查 Agent 的结果是否正确
安全边界：防止 Agent 做出高风险操作

所以，Agent = Model + Harness 这句话的意思是：

Model 负责智能
Harness 负责让智能变得可用

没有 Model，Agent 没有智能。

没有 Harness，Agent 的智能很难稳定地落地到真实任务里。

三、为什么光有 Model 不够？

我们可以先看一个简单例子。

假设你让一个 AI 帮你开发一个登录页面。

如果它只是一个普通聊天模型，它最多能做这些事：

给你一段代码
解释代码怎么运行
告诉你可能需要哪些依赖

但它无法真正知道：

代码是否已经写入项目
依赖是否安装成功
页面是否真的能打开
接口是否能正常请求
按钮点击后有没有报错
测试是否通过

也就是说，它只能“说”，不能真正“做”。

如果我们给它加上 Harness，情况就不一样了。

它可以：

读取项目目录
理解已有代码结构
修改对应文件
运行 npm install
启动本地服务
查看终端报错
根据报错修复代码
运行测试
确认页面是否正常
最后再告诉你结果

这时候，它就不只是一个会回答问题的模型，而更像一个可以执行任务的 Agent。

这就是 Harness 的价值。

它把模型从“会说”变成了“能做”。

四、Prompt、Context 和 Harness 有什么区别？

很多人刚开始理解 Harness 时，容易把它和 Prompt Engineering、Context Engineering 混在一起。

它们确实相关，但关注点不同。

可以简单理解为：

Prompt Engineering：解决“怎么问”的问题
Context Engineering：解决“给模型什么信息”的问题
Harness Engineering：解决“让模型在什么系统里工作”的问题

举个例子。

你想让 Agent 修改一个项目里的 bug。

Prompt 是你对它说的话：

请修复登录接口 500 的问题。

Context 是你提供给它的信息：

项目结构
报错日志
接口文档
相关代码文件
历史修改记录

Harness 则是它完成任务时依赖的整个工作系统：

文件读取能力
代码编辑能力
终端执行能力
测试命令
Git diff
沙箱环境
权限控制
日志记录
失败重试机制
人工审批机制

所以可以这样概括：

Prompt 是任务说明，Context 是参考资料，Harness 是工作环境。

这也是为什么只优化 Prompt 不够。

Prompt 可以让模型“回答得更好”，但 Harness 才能让 Agent “工作得更稳”。

五、Harness 通常包含哪些部分？

一个完整的 Agent Harness 可能会很复杂，但从通俗角度看，可以拆成几个核心模块。

1. 工具系统

Agent 不能只靠语言完成任务。

它需要工具。

比如：

搜索工具
浏览器工具
数据库工具
代码编辑工具
终端命令工具
文件系统工具
第三方 API 工具

对于编程 Agent 来说，工具可能是：

读取文件
修改代码
运行测试
查看日志
提交 Pull Request
执行 lint
调用 CI

对于音乐 Agent 来说，工具可能是：

搜索歌曲
播放歌曲
收藏歌曲
点赞歌曲
创建歌单
读取用户偏好
调用 QQ 音乐或网易云音乐 API

模型负责判断“下一步该做什么”，工具系统负责让它真的做出来。

2. 上下文管理

Agent 做复杂任务时，不能一次性把所有信息都塞给模型。

因为信息太多会导致两个问题：

上下文窗口不够
模型抓不住重点

所以 Harness 需要负责上下文管理。

它要决定：

当前任务需要哪些文件？
哪些历史记录是重要的？
哪些文档应该被检索？
哪些信息可以压缩？
哪些信息不应该给模型？

简单来说：

上下文管理决定了 Agent 看见什么，而 Agent 看见什么，很大程度上决定了它会做出什么。

3. 状态记录

人类工程师做复杂任务时，通常会记录：

已经做了什么
还剩什么没做
当前卡在哪里
哪些方案试过但失败了
下一步应该做什么

Agent 也一样。

如果没有状态记录，Agent 很容易出现这些问题：

重复做同一件事
忘记前面已经修过的 bug
不知道任务进展到哪一步
中断后无法恢复

所以 Harness 通常需要某种状态记录机制。

它可以是：

任务清单
进度文件
日志
记忆系统
数据库记录
中间结果缓存

状态记录的价值在于：

让 Agent 不只是“单轮回答”，而是可以持续推进一个任务。

4. 沙箱环境

当 Agent 开始调用工具、运行代码、操作文件时，风险就会变大。

比如它可能：

误删文件
执行危险命令
修改不该修改的配置
访问敏感数据
调用高成本 API

所以 Harness 需要提供沙箱环境。

沙箱的作用是：让 Agent 可以执行操作，但把风险控制在可接受范围内。

比如：

只能访问指定目录
不能直接操作生产数据库
高风险命令需要人工确认
网络访问受限
敏感信息不可见
执行结果可回滚

这就像给 Agent 一个安全的实验室。

它可以在里面工作、尝试、犯错、修复，但不会轻易影响真实生产环境。

5. 测试与验证

这是 Harness 最关键的价值之一。

很多 Agent 最大的问题不是不会生成答案，而是不会可靠地验证答案。

比如它写完代码后，可能会说：

问题已经修复。

但实际上：

测试没跑
页面没打开
接口还是报错
类型检查失败
构建无法通过

这时候，我们不能只相信模型的“自我判断”。

Harness 要做的是把结果验证系统化。

比如：

写完代码后自动运行测试
修改接口后自动检查类型
提交前自动执行 lint
页面完成后自动截图对比
调用工具后检查返回结果
失败后把错误重新反馈给模型

这就形成了一个闭环：

生成结果 → 执行验证 → 发现问题 → 反馈给模型 → 再次修复

也就是说：

Prompt 依赖模型自觉，Harness 依赖系统验证。

这就是 Agent 从 Demo 走向生产可用的关键。

6. 日志与可观测性

Agent 的执行过程不能是黑盒。

如果它失败了，我们需要知道：

它看到了什么信息？
它调用了哪些工具？
每一步为什么这么做？
哪一步开始跑偏？
失败原因是什么？
成本消耗在哪里？

所以 Harness 需要日志和可观测性。

这对开发者非常重要。

因为只有看得见 Agent 的行为，我们才能调试它、优化它、约束它。

否则 Agent 出错时，我们只能得到一句：

任务失败了。

但不知道为什么失败。

一个好的 Harness 应该让开发者能看到 Agent 的工作轨迹。

7. 权限与人工审批

Agent 越强，越需要边界。

有些操作可以让 Agent 自动完成，比如：

读取文件
运行测试
搜索文档
生成草稿
修改临时代码

但有些操作最好需要人工确认，比如：

删除数据
发送邮件
支付费用
发布版本
修改生产配置
提交重要 PR
调用高风险接口

所以 Harness 里通常需要权限控制和人工审批机制。

这不是为了限制 Agent，而是为了让 Agent 更适合真实环境。

因为生产环境里的问题不是“能不能做”，而是：

能不能安全地做？
能不能可控地做？
能不能出了问题后追踪和回滚？

六、为什么 Harness 这么重要？

理解了 Harness 包含什么之后，我们再来看它的核心价值。

价值一：让 Agent 从“会回答”变成“能执行”

大模型本身主要输出文本。

但真实任务往往不是只要一段文本。

比如：

修复一个 bug
整理一份报告
更新一个数据库
完成一套页面
分析一批日志
自动处理一封邮件

这些任务都需要执行动作。

Harness 给了模型执行动作的能力。

所以它的第一个价值是：

把模型的语言能力转化为真实世界里的任务执行能力。

价值二：让 Agent 可以完成更长、更复杂的任务

简单问题可以一次回答。

复杂任务不行。

复杂任务通常需要：

拆解目标
制定计划
收集信息
分步骤执行
处理异常
验证结果
更新状态
继续下一步

如果没有 Harness，Agent 很容易在长任务中失控。

所以 Harness 的第二个价值是：

让 Agent 可以像工程师一样，分步骤、可追踪地推进复杂任务。

价值三：让结果更可靠

这是最重要的一点。

很多时候，我们不缺一个“能生成答案”的 AI。

我们缺的是一个“结果可信”的 AI。

比如写代码场景里，真正重要的不是 Agent 说它写好了，而是：

代码能不能运行？
测试能不能通过？
有没有破坏旧功能？
有没有安全问题？
是否符合项目规范？

所以 Harness 的第三个价值是：

把“模型认为对”变成“系统验证通过”。

这也是 Agent 能否进入生产环境的关键区别。

价值四：让 Agent 更安全

Agent 如果只能聊天，风险相对有限。

但如果 Agent 能调用工具，风险就会变大。

它可能误操作数据库，可能删除文件，可能发出错误请求，也可能泄露敏感信息。

Harness 可以通过这些方式降低风险：

沙箱隔离
权限限制
敏感信息过滤
高风险操作审批
操作日志记录
结果回滚机制
成本限制

所以 Harness 不只是提高效率，也是在给 Agent 加安全边界。

一个没有 Harness 的强 Agent，可能很聪明，但也可能很危险。

一个有 Harness 的 Agent，才更容易被放进真实业务流程里。

价值五：让人类经验沉淀成系统规则

很多时候，人类工程师会不断提醒 Agent：

不要改这个目录
提交前先跑测试
不要跳过类型检查
接口变更要同步文档
数据库操作必须先确认
不要把密钥写进代码

这些提醒如果只写在 Prompt 里，很容易丢失。

更好的方式是把它们沉淀进 Harness。

比如：

项目规则文件
代码规范
lint 规则
测试用例
CI 流程
权限策略
工具调用限制
Evaluator 评估标准

换句话说：

Harness 的本质，是把人类的工程经验编码进系统里。

这比每次都口头提醒 Agent 更可靠。

七、一个简单例子：音乐 Agent 为什么也需要 Harness？

假设你正在做一个音乐 Agent。

用户说：

帮我收藏周杰伦的《晴天》。

如果只有模型，它可能只能理解这句话的意思：

用户想收藏一首歌。

但真正完成这个任务，需要很多额外能力。

比如：

识别歌曲名称和歌手
确认用户绑定了哪个音乐平台
搜索对应歌曲
判断搜索结果里哪一个是正确版本
调用收藏 API
检查收藏是否成功
失败时返回原因
必要时让用户确认
记录操作日志

这些能力都不属于模型本身。

它们属于 Harness。

所以一个音乐 Agent 实际上不是：

大模型 + 一个聊天框

而是：

大模型
+ 音乐平台 API
+ 用户身份系统
+ 工具调用逻辑
+ 歌曲搜索与匹配
+ 操作确认机制
+ 错误处理
+ 日志记录
+ 结果验证

这就是典型的 Model + Harness。

Model 负责理解用户想做什么。

Harness 负责把这个意图变成真实操作，并确保操作安全、正确、可追踪。

八、再看一遍：为什么说 Agent = Model + Harness？

现在我们可以重新理解这个公式：

Agent = Model + Harness

它不是一个数学公式，而是一种工程视角。

它提醒我们：

Agent 不是单纯的大模型
Agent 是大模型和外部工作系统的组合

Model 决定了 Agent 的智能上限。

Harness 决定了 Agent 的落地能力。

可以这样对比：

能力	Model 负责	Harness 负责
理解需求	是	辅助提供上下文
推理方案	是	提供任务结构
生成代码/文本	是	提供文件和工具
调用外部系统	决策	执行和约束
记录进度	部分依赖上下文	负责持久化
验证结果	可以判断	负责测试和检查
控制风险	能遵守指令	负责权限和沙箱
失败恢复	可以重新推理	负责反馈闭环