什么是 Agent Harness：模型之外的 Agent 运行时

Agent Harness 是模型之外的运行时与控制系统，负责上下文、工具、状态、评估、恢复和多 Agent 编排。它决定 Agent 能否从一次性问答进入可靠执行。

Agent Harness 是 AI Agent 工程中的系统层概念。

它不是某一个单独模块，也不等同于 prompt、工具调用或上下文窗口。更准确地说，它是模型之外的运行时与控制系统，负责把模型的推理能力转化为可执行、可观测、可恢复、可评估的任务行为。

Agent = Model + Harness

Model 负责语言、推理、规划和生成。Harness 负责上下文、工具、状态、权限、反馈、恢复和编排。

这一区分很重要。许多 Agent 产品的真实差异，并不只来自底层模型，而来自模型外部系统如何组织任务、约束行为、处理失败并积累反馈。

核心结论

Agent Harness 是模型之外的控制平面与运行时系统。
同一个模型放在不同 Harness 中，任务完成率、稳定性和风险边界可能不同。
Harness Engineering 关注的不是“怎么提示模型”，而是“如何让模型在系统中可靠行动”。
长任务、多工具调用、多 Agent 协作尤其依赖 Harness。
Agent 产品的竞争会逐渐从模型接入，扩展到运行时、评估、状态管理和编排能力。

一个工作定义

Agent Harness 是围绕基础模型构建的运行时与控制系统，负责将模型能力转化为稳定的智能体行为。

这个定义包含四层含义：

Harness 位于模型外部，不属于模型权重本身。
Harness 管理模型如何获得上下文、调用工具和推进任务。
Harness 提供权限、审批、日志、恢复和评估机制。
Harness 的质量直接影响 Agent 在真实环境中的可靠性。

下面这张图可以概括 Model 与 Harness 的关系。

为什么模型本身不够

在一次性问答中，模型能力通常是主要变量。

Agent 面对的不是一次性回答，而是连续任务。任务执行过程中会出现状态变化、工具失败、权限风险、上下文丢失和结果验证问题。

以 Coding Agent 为例，它需要：

理解代码库结构；
检索相关文件；
判断修改位置；
调用编辑工具；
运行测试、类型检查和 linter；
处理报错；
保存进度；
在必要时请求审批；
从中断或失败中恢复。

模型可以提出下一步动作，但不能单独承担这些系统职责。

这也是为什么同一个模型在普通聊天界面、命令行 Agent、IDE Agent 和具备代码索引与测试反馈的 Agent 中表现不同。差异并不只来自模型，而来自 Harness 如何组织模型与环境之间的交互。

不同来源如何定义 Harness

几类公开资料对 Harness 的表述不同，但重点互补。

Martin Fowler

相关资料：Harness engineering for coding agent users
侧重点：将 Harness 定义为模型之外的所有组成部分，并提出 Guide / Sensor 框架。

OpenAI

相关资料：Harness engineering: leveraging Codex in an agent-first world、Unrolling the Codex agent loop、Unlocking the Codex harness
侧重点：将 Harness 视为模型周围的控制平面，强调 Agent Loop、工具路由、审批、追踪和恢复。

Anthropic

相关资料：Effective harnesses for long-running agents、Demystifying evals for AI agents
侧重点：强调长任务、状态外部化、评估和可靠性。

Cursor

相关资料：Continually improving our agent harness、Codex model harness、Long-running agents
侧重点：从产品工程角度讨论上下文管理、工具调用可靠性、模型适配和在线评估。

这些定义可以合并为一句话：

Harness 是模型外部的控制平面。它决定模型如何获得上下文、调用工具、执行任务、接受反馈并处理失败。

Harness 的核心组成

Agent Harness 可以拆成六个主要层次。这样拆分比列出大量功能更清楚，也更接近工程实现。

Instruction layer

Instruction Layer 定义 Agent 的行为边界。

它包括系统提示词、角色定义、工具使用规范、输出格式、权限策略和安全约束。它的作用是减少行为不确定性，但不能替代运行时控制。

Prompt 属于这一层，但 Harness 不等于 Prompt。

Context layer

Context Layer 决定模型在每一步看到什么。

Cursor 在 Continually improving our agent harness 中提到，Agent 上下文机制从静态上下文与护栏，逐渐演进为动态上下文。这个方向是合理的：Agent 不只是需要更多信息，而是需要在正确阶段获得正确信息。

常见能力包括代码库索引、检索、摘要压缩、长期记忆、任务状态注入和上下文裁剪。

Tool layer

Tool Layer 决定模型能够作用于哪些外部环境。

对于 Coding Agent，这通常包括文件系统、Shell、Git、测试框架、包管理器、浏览器、API、CI/CD 和 MCP 工具。

工具层的难点不只是“接入工具”，还包括工具 schema 设计、失败处理、重试策略、危险操作审批和工具结果压缩。

Runtime layer

Runtime Layer 是 Agent Loop 所在的位置。

一个典型循环包括：构造上下文、调用模型、解析输出、执行工具、收集结果、更新状态，并决定继续、暂停、审批或结束。

OpenAI 的 Unrolling the Codex agent loop 讨论的正是这一层。Agent 能力不是单次模型输出，而是模型调用与环境执行之间的循环。

Evaluation layer

Evaluation Layer 判断结果是否可靠。

它可以包含单元测试、类型检查、linter、benchmark、A/B 测试、代码保留率、用户反馈和 Judge Agent。

Martin Fowler 的 Guide / Sensor 框架适合描述这一层：Guide 在行动前引导，Sensor 在行动后反馈。成熟 Harness 需要同时具备这两类机制。

Orchestration layer

Orchestration Layer 处理复杂任务和多 Agent 协作。

Cursor 在 Self-driving codebases 中讨论了 Planner、Executor、Workers、Judge 等角色分工。Anthropic 的 Building a C compiler with a team of parallel Claudes 也展示了并行 Agent 协作的工程价值。

当 Agent 从单点助手变成自动化工作流平台，编排层会成为关键能力。

Guide 与 Sensor：一个实用框架

Martin Fowler 的文章提出了一个很实用的区分：Guide 与 Sensor。

类型	作用	示例
Guide	行动前约束和引导 Agent	系统提示词、项目规范、架构说明、任务计划、示例
Sensor	行动后观察结果并触发纠正	测试、linter、类型检查、review、benchmark、用户反馈

Guide 的目标是提高第一次做对的概率。

Sensor 的目标是在错误进入人类工作流之前发现并纠正。

这一区分比单纯讨论 prompt 更有用。因为真实 Agent 失败往往不是“没写好提示词”，而是缺少反馈闭环。

与 Prompt Engineering 的区别

Prompt Engineering、Context Engineering 和 Harness Engineering 关注不同层次的问题。

工程类型	核心问题	典型对象
Prompt Engineering	如何指示模型	系统提示词、few-shot、输出格式
Context Engineering	给模型什么信息	检索、摘要、记忆、上下文窗口
Harness Engineering	模型如何在系统中行动	Agent Loop、工具、状态、评估、权限、恢复

Prompt Engineering 解决表达与指令问题。

Context Engineering 解决信息选择问题。

Harness Engineering 解决系统执行问题。

三者不是替代关系。Prompt 和 Context 都是 Harness 的组成部分，但 Harness 的范围更大。

为什么 Harness 会成为产品竞争层

Agent 产品的竞争不会停留在“接入哪个模型”。

原因很直接：Agent 的真实任务依赖外部环境。模型需要读取文件、运行命令、调用 API、处理错误、保存状态、等待审批并验证结果。

这些能力都在 Harness 中。

一个成熟 Harness 至少要回答以下问题：

如何动态选择上下文，而不是简单堆叠历史？
如何稳定调用工具，并处理失败结果？
如何保存任务状态，使长任务可以恢复？
哪些操作需要审批？
如何限制 Agent 的权限？
如何评估结果质量？
如何针对不同模型做适配？
如何支持多 Agent 并行和结果合并？

这些问题比“模型是否足够聪明”更接近产品可靠性的核心。

结论

Agent Harness 的价值在于，它把模型能力与智能体能力区分开来。

模型提供推理和生成。Harness 提供上下文、工具、运行时、状态、权限、评估和编排。

从 Martin Fowler 的边界定义，到 OpenAI 的控制平面视角，再到 Anthropic 的长任务可靠性实践，以及 Cursor 的产品化优化，可以看到同一个方向：Agent 的关键工程对象正在从单一 prompt 转向完整运行时系统。

因此，Harness Engineering 会成为 Agent 时代的重要工程能力。

它要求开发者同时理解模型行为、上下文组织、工具协议、运行时控制、状态管理、评估体系和多 Agent 编排。缺少这些能力，Agent 很容易停留在演示层；具备这些能力，Agent 才有机会进入可靠生产环境。

参考资料

以下资料构成本文的主要来源。保留这些链接很重要，因为 Harness 的定义仍在形成中，不同机构的表述各有侧重。