先说结论

Agent 是任务中的“决策与行动主体”，Harness 是让这个主体能够在真实环境里安全、稳定、可观察地工作的工程系统。

换句话说：

  • Agent 负责判断下一步做什么。
  • Harness 负责决定它能看到什么、能调用什么，以及这些动作怎样被执行、约束、记录和恢复。

两者不是竞品，也不是二选一。一个可落地的 Agent 产品，通常需要运行在 Harness 之中。

为什么这两个词容易混

行业里对 Agent 的边界并没有完全统一。有些团队把模型、提示词、工具、记忆、调度器和界面全部称为 Agent；另一些团队只把其中负责循环决策的部分称为 Agent，把外围系统称为 Agent Harness。

因此，讨论之前最好先明确口径。本文采用一个适合工程协作的定义：

  • 模型：根据输入生成输出的智能能力。
  • Agent：围绕目标持续观察、推理、选择动作并判断何时停止的运行主体。
  • Harness：把 Agent 接入上下文、工具、权限、状态、运行时和监控体系的宿主与控制层。

这个划分的价值不在于争论名词，而在于帮助团队定位问题究竟发生在哪一层。

核心区别

维度 Agent Harness
关注点 当前任务下一步做什么 任务如何被安全、可靠地执行
核心职责 理解目标、推理、选工具、检查结果、决定停止 提供上下文与工具、执行调用、管理权限、状态和生命周期
生命周期 通常跟随一次任务或一次会话 通常长期存在，可承载许多任务和多个 Agent
状态 工作记忆、计划、当前假设、任务进度 会话记录、文件、数据库、检查点、重试与幂等信息
工具关系 决定是否以及何时调用工具 暴露工具、校验参数、执行调用、返回结果
安全边界 遵守目标和行为约束 强制鉴权、最小权限、审批、沙箱和审计
典型故障 理解偏差、规划失误、选错工具、过早结束 超时、重复执行、权限泄漏、状态丢失、日志不足
可替换性 可以替换模型、提示词或决策策略 尽量保持稳定，为不同 Agent 提供一致运行环境

一个简单判断方法是：如果问题在问“下一步该做什么”，它更接近 Agent；如果问题在问“这一步能不能执行、怎样执行、失败后怎么办”，它更接近 Harness。

用一次代码修复看清边界

假设用户说：“修复登录接口偶发的 500 错误，并运行测试。”

Agent 可能会完成这些决策：

  1. 阅读错误日志和相关代码。
  2. 推测异常来自空值处理或数据库超时。
  3. 选择要检查的文件和命令。
  4. 修改实现并运行测试。
  5. 根据测试结果继续修正，或者结束任务并汇报。

Harness 则负责提供和约束这段过程：

  1. 把仓库、用户要求和项目规范装入上下文。
  2. 向 Agent 暴露文件读取、补丁编辑和终端工具。
  3. 限制可访问目录与命令权限。
  4. 执行工具调用并把标准输出、错误和退出码返回给 Agent。
  5. 对危险操作要求确认，对超时调用执行终止或重试。
  6. 保存会话、变更记录、测试证据和审计日志。
  7. 在进程中断后恢复任务，避免重复提交或重复发布。

因此，同一个 Agent 放进不同的 Harness，实际表现可能差别很大。模型能力没有变化，但它得到的上下文质量、工具设计、权限边界、反馈速度和错误恢复能力都变了。

Harness 不只是一个循环

最小的 Agent 原型往往只是“调用模型—执行工具—把结果送回模型”的循环。这个循环是 Harness 的一部分，却远不是完整的生产级 Harness。

一个成熟 Harness 通常还要处理以下能力：

  • 上下文组装：系统规则、用户目标、仓库规范、历史状态和相关资料如何进入上下文。
  • 工具治理：工具描述、参数校验、返回结构、权限范围和错误语义是否清晰。
  • 运行控制：超时、重试、取消、并发、队列、检查点和停止条件。
  • 安全机制：沙箱、审批、凭据隔离、敏感信息过滤和最小权限。
  • 状态管理：会话、任务进度、文件变化、幂等键和中断恢复。
  • 可观察性：调用链、耗时、成本、失败原因、最终证据和用户可见进度。
  • 质量保障：回归评估、工具成功率、任务完成率以及人工接管机制。

如果这些能力缺失，Agent 即使偶尔表现惊艳，也很难稳定进入生产环境。

模型、Agent 与 Harness 的三层关系

可以把三者理解为一支在受控环境里工作的工程师：

  • 模型像思考能力，负责生成判断与候选方案。
  • Agent 像正在处理任务的工程师，围绕目标持续观察、决策和行动。
  • Harness 像工作台、权限系统、工具链和作业制度的集合，让行动真正发生并且可控。

模型升级不等于 Agent 设计自动变好，Agent 变聪明也不等于 Harness 自动可靠。三层需要分别设计和评估。

多 Agent 属于哪一层

多 Agent 往往横跨两层。

每个子 Agent 仍然负责自己的判断和行动；但谁来拆分任务、如何分配上下文、怎样限制并发、如何合并结果和处理冲突，通常属于 Harness 或编排层的职责。

因此，多 Agent 并不只是“多开几个模型调用”。如果缺少清晰的任务边界、共享状态和汇总规则，并行反而可能带来重复劳动、互相覆盖和成本失控。

设计时应该分别问什么

设计 Agent 时，重点回答：

  1. 目标如何表达，成功标准是什么？
  2. Agent 能观察到哪些信息？
  3. 它有哪些动作和工具可选？
  4. 每次工具返回后如何重新判断？
  5. 何时继续、何时求助、何时停止？
  6. 最终输出必须包含哪些证据？

设计 Harness 时，重点回答：

  1. 上下文从哪里来，怎样保持新鲜且不过载？
  2. 工具权限如何按任务最小化？
  3. 哪些动作可以自动执行，哪些必须审批？
  4. 调用超时、失败或中断后如何恢复？
  5. 怎样避免重复写入和不可逆操作？
  6. 如何记录决策链、工具结果与最终变更？
  7. 如何让用户随时看到进度并安全接管？

把这两组问题混在一起，常见结果是提示词越来越长，却依然解决不了权限、状态和可靠性问题。

评估也要分层

Agent 质量与 Harness 可靠性应该分开测量。

Agent 层可以关注：

  • 任务理解是否准确。
  • 计划和工具选择是否合理。
  • 结果是否满足目标。
  • 是否会识别不确定性并及时求助。

Harness 层可以关注：

  • 工具调用成功率与延迟。
  • 权限和审批是否正确生效。
  • 超时、重试和幂等是否可靠。
  • 中断恢复是否丢失状态。
  • 日志是否足以复盘问题。
  • 敏感数据是否得到隔离。

否则，工具接口返回含糊导致的失败，可能被误判为模型不聪明；而 Agent 的错误决策，也可能被错误地归咎于基础设施。

常见误区

工具越多，Agent 越强

工具数量不是关键。工具重名、描述含糊、参数复杂或返回不稳定，都会增加选择成本。少量、边界清楚、反馈明确的工具，往往更有效。

Harness 只是界面或 SDK

界面和 SDK 只是入口。真正的 Harness 还包括执行环境、状态、权限、工具协议、监控与恢复机制。

换更强模型就能修好系统

更强模型可以改善推理与工具选择，但无法替代鉴权、幂等、超时、审计和数据隔离。这些仍然是 Harness 的工程责任。

Agent 能自我约束，所以不需要强制边界

提示词约束很重要，但生产系统不能只依赖模型自觉。高风险动作需要由 Harness 用权限、审批和沙箱强制执行。

一条实用的落地原则

先把 Agent 当成可替换的决策核心，再把 Harness 当成长期演进的产品基础设施。

这样做有三个好处：

  1. 可以在不重写工具链的情况下替换模型或调整 Agent 策略。
  2. 可以把权限、状态、审计和可靠性能力复用于不同任务。
  3. 出现问题时更容易判断是“决策错了”还是“执行系统失效了”。

最终，Agent 决定系统是否聪明，Harness 决定这种聪明能否稳定、安全地变成结果。

延伸阅读

OpenAI 的模型指导把工具编排、自主权与审批边界、重试停止条件以及最终验证放在同一套工程实践中讨论。这些内容可以作为设计 Harness 时的检查清单：OpenAI Model guidance。