为什么只谈 Agent 还不够？——一文讲清楚 Agent 和 Harness 到底分别是什么

前言

这两年，大家聊 AI 系统时，最容易被反复提起的一个词就是：

Agent

好像只要系统会调用工具、会拆任务、会自己往下执行，它就已经是一个“高级 AI Agent”了。

但如果你真的开始做这类系统，很快就会发现一个问题：

• 模型会思考，不代表系统能稳定执行
• 模型会调用工具，不代表工具调用是安全的
• 模型能往下做几步，不代表整条链路可控、可审计、可复现

这时候你会意识到：

真正把一个 Agent 系统跑起来的，从来不只是 Agent 本身。

在 Agent 外面，通常还包着一层更底层、但经常被忽略的东西：

Harness

很多人第一次听到这个词，会觉得它像个“包装器”或者“运行壳”。
但从工程角度看，它远不只是一个外壳。

如果说 Agent 负责“怎么想、下一步做什么”，
那么 Harness 负责的其实是：

• 能不能做
• 怎么做
• 在什么边界里做
• 做错了怎么办
• 整个过程如何被观测、限制和治理

也就是说：

Agent 决定系统有没有“智能感”，Harness 决定系统有没有“工程性”。

所以，真正成熟的 AI 系统，几乎从来不是单独一个 Agent，
而是：

Agent + Harness

一、为什么很多人会把 Agent 和 Harness 搞混？

1. 因为在 Demo 里，它们经常被包成一个东西

很多人第一次接触 Agent，看到的都是类似这样的演示：

• 用户输入一个任务
• 模型开始分析
• 模型调用工具
• 模型读文件、写代码、查网页
• 模型继续推进任务
• 最后给出结果

从表面看，好像整个系统就是“Agent 在工作”。

但实际上，这里面往往已经隐含了一大堆非 Agent 的能力：

• 工具接口是谁提供的？
• 工具参数是谁校验的？
• 哪些目录能读写是谁限制的？
• 网络能不能访问是谁控制的？
• 高风险命令是否需要确认是谁决定的？
• 整个执行过程的日志是谁记录的？
• 失败重试和超时中断是谁处理的？

这些东西，很多并不属于 Agent 本身，
而是属于它外面的执行与控制层。

只是 Demo 里通常不会把这层单独讲出来，于是很多人会误以为：

“会调工具的模型” = “完整 Agent 系统”

其实中间还差了很重要的一层，就是 Harness。

2. 因为 Agent 更显眼，Harness 更像“幕后系统”

从直觉上讲，人们更容易注意到“会思考、会调用工具、会执行任务”的部分。

因为那一层看起来最像“智能”。

而 Harness 做的事，往往更偏工程基础设施：

• 上下文拼装
• 工具暴露
• 权限控制
• 沙箱隔离
• 状态管理
• 预算限制
• 日志和 trace
• 中断与审批
• 回放与审计

这些能力虽然不如 Agent 那么“炫”，
但系统一旦要进入真实环境，它们的重要性反而会急剧上升。

所以才会出现一个很典型的误区：

很多人以为 Agent 是主角，Harness 只是配角。
但在真正可落地的系统里，Harness 往往决定了这个 Agent 能不能真正工作。

二、什么是 Agent？

1. Agent 的本质，是“决策层”

如果一定要用一句话概括 Agent，它更接近的是：

负责决定下一步做什么的那一层。

它的核心任务通常包括：

• 理解用户目标
• 拆分任务
• 判断当前状态
• 选择下一步动作
• 决定是否调用工具
• 根据反馈调整策略
• 在多步执行中持续推进任务

换句话说，Agent 不只是“生成一段回答”，
它更像是在做一个持续循环：

1. 看目标
2. 看当前状态
3. 想下一步
4. 执行动作
5. 读取反馈
6. 再决定下一步

这个循环，就是很多 Agent 系统最核心的“智能感”来源。

2. Agent 最像什么？最像“大脑”或“驾驶员”

一个比较直观的比喻是：

• Agent 像大脑
• 或者说，Agent 像驾驶员

它决定方向、判断局势、规划动作。

比如用户说：

“帮我定位这个线上回归 bug，并修掉它。”

一个 Agent 可能会这样想：

• 先看报错信息
• 再查最近提交记录
• 再找相关模块
• 先读配置文件
• 如果是测试失败，先跑测试
• 如果定位到代码改动，再生成修复方案

这些“先做什么、后做什么、要不要换路径”的事情，
基本都属于 Agent 的范畴。

所以可以说：

Agent 负责的是意图到动作之间的决策。

3. 但 Agent 本身并不等于整个系统

这点非常关键。

Agent 可以知道“应该去读文件”，
但它本身未必负责这些问题：

• 读哪个目录被允许？
• 能不能读系统敏感文件？
• 读文件这个动作的超时时间是多少？
• 失败后是否重试？
• 这次读文件有没有被记录下来？
• 如果这个动作危险，是否需要人工确认？

也就是说，Agent 可以提出动作意图，
但动作如何被允许、被限制、被执行，往往不是 Agent 单独决定的。

这就引出了另一半：

Harness

三、什么是 Harness？

1. Harness 的本质，是“执行控制层”

如果说 Agent 是“做决策的那层”，
那么 Harness 更像是：

让这些决策变成可执行、可约束、可观测系统行为的那一层。

它不是负责“替模型思考”，
而是负责把模型的思考结果接进真实世界。

所以 Harness 干的通常是这些事：

• 给 Agent 提供工具
• 给 Agent 注入上下文
• 限制 Agent 的操作边界
• 管理状态和会话
• 控制权限、预算和超时
• 记录日志和执行轨迹
• 处理失败、中断、审批和回滚

换句话说：

Harness 不是智能层，而是运行层。

2. Harness 最像什么？最像“操作系统”或“驾驶舱”

如果继续沿用刚才的类比：

• Agent 像驾驶员
• Harness 更像车辆 + 仪表盘 + 限速器 + 安全带 + 护栏 + 交通规则

驾驶员决定往哪走，
但：

• 车能不能启动
• 时速能不能超过限制
• 能不能开进某条路
• 哪些操作会触发警报
• 发生风险能不能紧急制动

这些并不是驾驶员一个人说了算，
而是由整套运行和安全机制共同决定。

这就是 Harness 的角色。

它不是“替你开车”，
而是：

让开车这件事，变得可控、可观察、可治理。

3. 一个成熟的 Harness，通常至少承担这几类职责

（1）上下文装配

Harness 负责决定：

• 给 Agent 哪些系统提示
• 注入哪些历史消息
• 暴露哪些记忆
• 提供哪些文件或任务状态
• 当前轮次到底看到什么上下文

也就是说，Agent 并不是“直接面对世界”，
而是先通过 Harness 看到一个被组织过的环境。

（2）工具与环境暴露

Harness 负责把工具接给 Agent，例如：

• 文件系统
• shell
• 浏览器
• 数据库
• HTTP
• 内部 API
• 搜索与检索工具

同时也负责定义：

• 工具长什么样
• 输入参数怎么校验
• 返回结果如何格式化
• 哪些工具可用，哪些不可用

（3）权限与安全边界

这是 Harness 特别核心的一部分。

例如它需要决定：

• 哪些目录可读可写
• 是否允许联网
• 是否允许执行高危命令
• 是否能访问生产环境
• 是否需要审批才能继续
• 是否必须在沙箱里执行

很多团队以为“安全”是 Agent 自己学会谨慎，
但真正的系统安全，通常是 Harness 提供的。

（4）状态、预算与生命周期管理

Harness 还要管理很多运行时问题，比如：

• 这次任务持续多久
• token / 成本预算是多少
• 哪些中间状态需要保存
• 哪些结果需要回传给下一轮
• 任务失败后是否重试
• 会话什么时候结束

这些也往往不是 Agent 本身最擅长处理的，
而更适合放在外部运行层。

（5）观测、审计与中断

一个真正能上线的系统，必须知道：

• Agent 做了什么
• 为什么做这一步
• 调了哪些工具
• 哪一步失败了
• 哪一步超时了
• 哪一步被人类中断了
• 最终结果是怎么来的

这些能力很大程度上也属于 Harness。

可以说：

没有观测能力的 Agent，更像演示；有观测能力的 Agent，才更像系统。

四、Agent 和 Harness 到底怎么分工？

1. 一个最简洁的区分方式

如果要做一个非常直接的划分，可以这样理解：

Agent 负责回答：

• 现在目标是什么？
• 我下一步应该做什么？
• 要不要调用工具？
• 结果看起来对不对？
• 要不要换个策略？

Harness 负责回答：

• 这一步能不能做？
• 这个工具怎么调？
• 这个动作权限够不够？
• 这一步是否要审批？
• 这次执行是否超时？
• 这个结果怎么记录和传递？

所以两者的差别可以浓缩成一句话：

Agent 决定“做什么”，Harness 决定“怎么安全、稳定、可控地做”。

2. 一个 coding agent 场景，会更容易看清楚

假设用户说：

“帮我修复这个测试失败问题，并补上缺失测试。”

这时，Agent 可能负责：

• 理解用户目标
• 判断需要先跑测试
• 读取测试输出
• 猜测可能相关文件
• 决定先修实现还是先修测试
• 生成修改计划
• 根据反馈继续推进

而 Harness 可能负责：

• 提供 run_test、read_file、edit_file 等工具
• 限制只能操作当前工作区
• 禁止访问系统敏感目录
• 限制网络权限
• 对危险写操作做审批
• 记录每一步命令和文件改动
• 控制执行超时
• 保存 patch 和日志
• 在用户中断时安全停机

你会发现：

Agent 很重要，但它只是“决策者”；
真正让整个过程变成一个可运行系统的，是外面的 Harness。

3. 没有 Harness，Agent 往往只能停留在“会想”

这是很多人容易忽略的一点。

如果一个系统只有 Agent，没有 Harness，它通常会出现两种情况：

第一种：它只能“建议”，不能真正“执行”

也就是它会说：

• 你可以去读这个文件
• 你应该跑这个命令
• 你可能要改这里
• 你最好再查一下日志

听起来像个顾问，但不是执行体。

第二种：它能执行，但行为不可控

也就是它可以真的去做事，
但：

• 没权限边界
• 没审批机制
• 没日志
• 没中断
• 没预算
• 没回滚
• 没沙箱

这种系统短期可能很惊艳，
长期通常很危险。

所以真正可用的系统，不是“只有 Agent”，而是：

Agent 必须运行在一个设计良好的 Harness 之上。

五、为什么说 Harness 往往比 Agent 更决定系统能不能落地？

1. 因为模型能力越来越强，但系统治理不会自动出现

未来更强的模型会越来越多，
Agent 的基础决策能力也会逐渐变强。

但这并不意味着系统会自动变得可上线。

因为这些能力不会自动从模型里长出来：

• 沙箱隔离
• 权限控制
• 工具网关
• 日志追踪
• 成本治理
• 超时中断
• 人类审批
• 审计与回放

这些东西，本质上更像基础设施问题，
而不是模型问题。

也就是说：

模型进步会提升 Agent 的大脑，
但 Harness 决定这个大脑能不能接进真实世界。

2. 因为很多所谓“Agent 失控”，本质上是 Harness 设计不完善

现实里很多问题，看起来像 Agent 不够聪明，
其实更接近 Harness 没设计好。

例如：

• 任务越做越偏：可能是状态管理差
• 工具乱调：可能是工具暴露太宽
• 改动越界：可能是权限边界太弱
• 成本爆炸：可能是预算控制缺失
• 出错无法追踪：可能是日志与 trace 不完整
• 风险动作没人拦：可能是审批链没接

所以很多工程问题，最后并不只是“换更强模型”能解决的。

真正该补的，往往是：

Harness 这层系统能力

3. 因为真正的产品护城河，经常不在 Agent，而在 Harness

从产品视角看，很多团队会把精力大量投入到：

• prompt 怎么写
• agent loop 怎么设计
• tool use 怎么提示
• planner 怎么做

这些当然都重要。
但如果只看 Agent 层，你会发现大家很容易越来越趋同。

真正能拉开差距的地方，很多时候反而在 Harness：

• 你的权限模型设计得怎么样
• 你的工具治理做得怎么样
• 你的沙箱和工作区隔离做得怎么样
• 你的观测、评估、审计是否完整
• 你的中断与人类协作机制是否顺畅

这些地方看起来不如“Agent 很聪明”那么显眼，
但它们往往更决定一个系统能不能长期跑、敢不敢上线、能不能进企业流程。

六、那什么才叫“好的 Agent + Harness 设计”？

1. Agent 保持专注：负责决策，不要背太多系统责任

一个常见错误是，把太多运行时责任都塞给 Agent 本身。

比如让 Agent 自己负责：

• 记所有状态
• 自己判断权限
• 自己决定是否危险
• 自己做审计记录
• 自己约束成本

这样做的问题是：

• prompt 会越来越重
• 规则会越来越乱
• 模型负担越来越大
• 系统行为越来越不稳定

更合理的方式通常是：

让 Agent 专注在决策，
把权限、治理、观测、边界这些系统职责下沉到 Harness。

2. Harness 要最小暴露，而不是默认全开

一个好的 Harness，通常不是“把所有工具都给 Agent，再告诉它谨慎使用”。

而是：

• 默认只暴露必要工具
• 默认只给最小权限
• 默认在沙箱环境中执行
• 默认高风险动作要确认
• 默认可观测、可审计、可中断

这会带来一个很重要的效果：

就算 Agent 偶尔判断错了，出错半径也会比较小。

3. 两者之间要有清晰接口，而不是互相污染

成熟系统里，Agent 和 Harness 之间最好有清晰边界：

• Agent 通过定义良好的工具接口提需求
• Harness 通过统一规则执行动作
• 中间状态通过结构化方式传递
• 风险策略由 Harness 统一托管
• Agent 不直接“裸奔式”接触外部环境

这样做的好处是：

• 更容易调试
• 更容易替换模型
• 更容易替换工具
• 更容易做权限治理
• 更容易做版本迭代

换句话说：

Agent 和 Harness 的关系，不应该是混成一团，
而应该像“决策层”和“运行层”一样清晰协作。

总结

很多人讨论 AI 系统时，最容易把注意力集中在 Agent 上：

• 它会不会拆任务
• 它会不会用工具
• 它会不会自主执行
• 它是不是越来越像数字员工

这些当然都重要。

但如果只盯着 Agent，你会很容易漏掉真正把系统变成“工程产品”的另一半：

Harness

因为一个系统能不能工作，不只是看它会不会想，
还要看它：

• 能不能安全执行
• 能不能被限制边界
• 能不能被观测和审计
• 能不能处理中断、失败和回滚
• 能不能稳定接进真实环境

所以，从工程角度看：

• Agent 是智能核心
• Harness 是运行基础设施

前者决定“它会不会做事”，
后者决定“它能不能在真实世界里把事做好”。

这也是为什么，只谈 Agent 往往是不够的。

真正成熟的 AI 系统，几乎都不是单独一个 Agent，
而是：

Agent + Harness 共同构成的执行系统。

如果说 Agent 决定的是系统的“思考能力”，
那么 Harness 决定的，就是系统的“落地能力”。

而后者，往往才是真正把 Demo 变成产品的那一层。

一句话结论

Agent 负责决定下一步做什么，Harness 负责让这一步可执行、可约束、可观测、可治理。