Agent = Model + Harness

如果你不是模型本身，那你就是 harness。

harness 指的是除了模型之外的所有代码、配置以及执行逻辑。一个裸模型并不是智能体，只有当 harness 为它提供状态管理、工具执行、反馈循环以及可约束的执行环境时，它才真正成为一个 agent。

具体来说，harness 通常包括：

• System Prompt（系统提示词）
• 工具、技能、MCP 以及它们的描述
• 配套基础设施（文件系统、沙箱、浏览器等）
• 编排逻辑（子代理调度、任务交接、模型路由）
• 用于确定性执行的 Hook / 中间件（如上下文压缩、续写、lint 检查等）

当然，模型和 harness 的边界可以有很多不同的划分方式，但我认为这种定义最清晰，因为它迫使我们从“如何围绕模型智能构建系统”的角度来思考问题。

接下来，我们会从“模型本身的能力边界”出发，反向推导为什么需要这些 harness 组件。

我们希望智能体完成很多事情，但模型本身并不具备这些能力，这正是 harness 的作用所在。

模型本质上只是接收输入（文本、图像、音频、视频等），输出文本。仅此而已。它原生无法做到：

• 在多轮交互中持续保存状态
• 执行代码
• 获取实时信息
• 搭建运行环境、安装依赖来完成任务

这些全部都是 harness 层的能力。LLM 的结构决定了，必须有一层“外部系统”来包裹它，才能让它真正做事。

举个简单例子：为了实现“聊天”这种产品体验，我们会用一个循环不断追加历史消息并传给模型。这本质上就是最基础的 harness。核心思想是：把我们期望的 agent 行为，转化为 harness 中的具体功能。

Harness Engineering 的作用，是帮助人类向模型注入有效的先验，从而引导其行为。随着模型能力提升，harness 也在被用来“精细化补强”模型，让它完成原本做不到的任务。

我们不打算罗列所有功能，而是遵循一个思路来推导：

想要的行为（或需要修正的问题） → 对应的 harness 设计

我们希望智能体具备持久存储能力，能处理真实数据，能把超出上下文的信息卸载出去，并跨会话保留工作成果。

模型只能处理当前上下文窗口内的信息。没有文件系统之前，用户只能手动复制粘贴数据，这种方式既低效，也不适用于自动化 agent。

现实世界本来就是通过文件系统来组织工作的，而模型在训练中也接触了大量相关数据，因此一个自然的方案就是：

在 harness 中内置文件系统抽象，并提供文件操作工具。

文件系统是最基础的 harness 原语之一，因为它带来了：

• 智能体可以读取数据、代码和文档
• 可以逐步存储和卸载信息，而不是全部塞进上下文
• 能保存中间结果，实现跨会话状态
• 成为协作载体：多个 agent 和人类可以通过共享文件协同工作

再加上 Git，就可以实现版本控制、回滚错误、分支实验等能力。

我们希望智能体能自主解决问题，而不是事先为每个动作都设计工具。

当前主流模式是 ReAct：模型思考 → 调用工具 → 观察结果 → 循环。但 harness 只能执行预先定义好的工具。

更好的方式是提供一个通用工具——比如 bash：

让模型通过写代码并执行代码，自主解决问题。

这相当于给模型一台计算机。它可以动态创建工具，而不是受限于固定接口。

虽然 harness 仍然会提供其他工具，但“代码执行”已经成为默认的通用解法。

智能体需要一个安全、默认配置良好的环境来执行任务、观察结果并持续推进。

我们已经给了模型存储和执行能力，但这些必须运行在某个环境中。直接在本地执行不安全，也难以扩展。

沙箱（sandbox）提供了隔离、安全的执行环境。

harness 可以连接到沙箱来：

• 执行代码
• 查看文件
• 安装依赖
• 完成任务

还可以通过白名单命令、网络隔离等方式增强安全性。同时，沙箱支持按需创建、并行扩展、任务完成后销毁。

好的环境还需要好的默认工具：

• 语言运行时和依赖
• Git、测试工具 CLI
• 浏览器（用于网页交互与验证）

这些工具让 agent 能够：

• 查看日志、截图、运行测试
• 构建“自验证循环”：写代码 → 跑测试 → 修复错误

这些能力全部由 harness 决定，而不是模型本身。

我们希望智能体能记住经验，并访问训练后才出现的信息。

模型的知识只来自参数和当前上下文。无法修改权重时，“增加知识”的唯一方式就是——把信息注入上下文。

文件系统再次成为核心：

• harness 会加载类似 AGENTS.md 的记忆文件到上下文
• agent 可以持续更新这个文件
• 下次启动时再注入

这就是一种“持续学习”。

对于实时信息，则需要：

• Web 搜索
• MCP 工具（如 Context7）

这些让模型获取训练截止之后的新知识。

智能体在长时间运行中不应该性能下降。

Context Rot 指的是：随着上下文变长，模型推理能力下降。

上下文是稀缺资源，因此 harness 必须管理它。

本质上，harness 是“上下文工程”的执行系统。

关键策略包括：

1. 上下文压缩（Compaction） 当上下文接近上限时，对历史内容进行总结和卸载，让任务继续进行。

2. 工具调用结果卸载 大体量输出只保留头尾，完整内容存入文件系统，避免污染上下文。

3. Skills（渐进式加载） 避免一开始加载过多工具，通过“按需暴露”减少上下文负担。

我们希望智能体能在长时间内，自主、正确地完成复杂任务。

但现实中模型会：

• 过早停止
• 难以分解复杂问题
• 跨上下文窗口时失去连贯性

因此需要 harness 设计来弥补。

关键机制包括：

文件系统 + Git 记录长期任务进度，支持多 agent 协作。

Ralph Loop（持续执行机制） 拦截模型“结束”行为，重新注入任务目标，在新上下文中继续执行。

规划与自验证

• 先拆解任务（planning）
• 每步完成后进行验证（测试、日志、评估）

harness 可以通过 hook 自动运行测试，并将错误反馈给模型。

像 Claude Code、Codex 这样的系统，已经是在“模型 + harness”共同参与的环境中进行后训练的。

这带来一个循环：

• 发现有用的 harness 原语
• 加入系统
• 用它们训练下一代模型

但这也带来副作用，比如对特定工具过拟合（例如 apply_patch）。

但这不意味着模型自带的 harness 就是最优的。

例如在 Terminal Bench 2.0 上，仅通过优化 harness，就能显著提升模型表现。

随着模型能力提升，一些能力会被“内化”进模型，比如：

• 规划能力
• 自验证能力
• 长任务一致性

这似乎意味着 harness 重要性下降。但实际上不会。

就像 prompt engineering 依然重要一样，harness engineering 仍然是构建优秀智能体的关键。

因为它不仅是“补模型短板”，更是在：

• 提供更好的运行环境
• 提供合适的工具
• 管理状态
• 构建验证机制

这些都会提升任何模型的效率。

当前一些值得探索的方向包括：

• 协调数百个 agent 并行协作
• 让 agent 分析自身执行轨迹，修复 harness 层问题
• 动态按需组装工具和上下文，而不是预先配置

本文的核心目的，是说明 harness 是什么，以及它如何由“我们希望模型完成的任务”所决定。

模型提供智能，而 harness 让智能真正发挥作用。

期待更多更好的 harness、更强的系统，以及更强大的智能体。