最近聊到一个很有意思的概念：harness engineering，或者说 harness agent。相比单纯研究 prompt，它更关心如何给 AI agent 搭建一个可靠的运行环境：工具、权限、验证、记忆、任务流、失败恢复和多 agent 协作。

我的理解是：prompt engineering 是告诉模型怎么想；harness engineering 是设计模型能做什么、怎么做、做错了怎么发现和纠正。

什么是 Harness？

在 AI agent 语境里，harness 可以理解为 agent 外面的一层执行框架，也可以理解为 agent 的运行时环境。

它通常负责这些事情：

  • 提供工具：读写文件、运行测试、查网页、操作浏览器、调用 API。
  • 控制权限：哪些命令可以自动执行，哪些操作必须让用户确认。
  • 管理上下文：任务列表、长期记忆、历史压缩、计划状态。
  • 约束行为：不能随便删文件，不能跳过测试，不能强推代码。
  • 观察结果：测试是否通过，页面是否真的可用，日志是否报错。
  • 失败恢复：命令失败后如何诊断、重试、换路径。
  • 多 agent 协作：主 agent 负责决策，子 agent 负责搜索、评审、验证。

所以 harness engineering 更像是在设计一个 agent operating system：模型负责推理，harness 负责工具、权限、流程、验证和恢复。

什么是 Harness Agent？

我觉得 harness agent 可以从两个角度理解。

第一种，是 运行在 harness 里的 agent。

例如 Claude Code 这类 coding agent，不只是聊天模型。它可以读取本地文件、修改代码、运行 shell 命令、调用浏览器、管理任务列表、委托子 agent、遵守权限系统。它的很多能力并不完全来自模型本身，而是来自外部 harness 提供的运行环境。

第二种，是 专门管理 harness 的 agent。

这类 agent 不一定直接写业务代码，而是负责让其他 agent 更好工作，比如：

  • 自动配置权限；
  • 扫描常见命令并减少权限弹窗；
  • 管理 hooks；
  • 监控 CI；
  • 自动运行测试；
  • 维护长期 memory；
  • 协调多个 agent 的分工。

也就是说，harness agent 更像是 AI agent 系统里的“调度员、守门员和运维”。

为什么这个方向越来越重要？

因为大模型本身已经足够强，单纯改 prompt 的边际收益正在变小。真正决定 agent 是否好用的，经常是这些问题：

  • 它有没有合适的工具？
  • 工具调用失败时会不会恢复？
  • 会不会误删文件？
  • 会不会没验证就声称完成？
  • 会不会污染 git 状态？
  • 会不会无限循环？
  • 会不会记住用户偏好？
  • 会不会把复杂任务拆给合适的子 agent？
  • 会不会在危险操作前请求确认？

这些问题不是单靠 prompt 能彻底解决的。它们需要 harness 层面的工程设计。

一个简单例子是：让 coding agent 修一个前端 bug。

差一点的流程可能是：

  1. 读代码；
  2. 猜一个改法；
  3. 改文件；
  4. 说“应该好了”。

更可靠的 harness 流程应该是：

  1. 定位相关文件；
  2. 建任务列表；
  3. 读取最小必要上下文；
  4. 修改代码；
  5. 跑类型检查和测试；
  6. 启动 dev server；
  7. 用浏览器实际点击页面；
  8. 检查 console error 和 network error；
  9. 如果失败，回到诊断路径；
  10. 最后只报告已经验证过的结果。

这里的核心不是“模型更聪明”，而是 harness 强迫它经过可靠流程。

Harness Engineering 和 Agent Engineering 的区别

可以粗略这样区分：

类型 关注点
Prompt engineering 怎么写指令让模型回答更好
Agent engineering 让模型能规划、调用工具、完成任务
Harness engineering 设计 agent 的运行环境、权限、工具、验证、状态和安全边界
Eval engineering 衡量 agent 是否真的变好

实际项目里，这几个方向经常混在一起。但如果要做一个真正能落地的 agent 产品，harness engineering 往往比继续微调 prompt 更关键。

一个好的 Harness 应该具备什么？

我会重点看这些特征：

  1. 工具边界清晰
    读文件用读文件工具，搜代码用搜索工具，跑测试用 shell，而不是让模型用自然语言假装完成。

  2. 有权限模型
    本地读写可以相对自动，但推送代码、删除文件、发布内容、调用外部服务这类操作应该确认。

  3. 有验证闭环
    不是“我改了”，而是“我改了，并通过了哪些验证”。

  4. 能处理失败
    测试失败后应该定位原因，而不是盲目重试。

  5. 上下文经济
    不把整个 repo 塞给模型，而是搜索、读取、压缩、委托子 agent。

  6. 可观察性好
    用户应该知道 agent 在做什么、卡在哪里、为什么换方案。

  7. 支持多 agent 分工
    主 agent 不需要亲自做所有事，可以让 explore agent 查代码、review agent 审查风险。

  8. 有记忆但不盲信记忆
    可以记住用户偏好，但涉及当前代码状态时仍然要重新验证。

GitHub 上值得看的相关项目

下面这些项目适合从不同角度理解 harness engineering。项目状态变化很快，具体活跃度、star 数和 API 细节建议以 GitHub 页面为准。

1. Browser Harness / Browser Use

如果你关心 browser agent，可以看：

它们适合研究浏览器 agent 的运行环境：Chrome/CDP、DOM 观察、网页任务执行、自愈式浏览器操作等。

Browser agent 的难点不只是“点击按钮”，而是如何让 agent 在网页结构变化、弹窗、加载延迟、表单异常、网络错误中仍然可靠完成任务。这正是 harness engineering 很典型的场景。

2. Inspect AI

Inspect AI 是 UK AI Security Institute 开源的评测框架。

它适合研究 eval harness 的基本结构：

  • task；
  • solver；
  • tool use；
  • scorer；
  • 日志；
  • 可复现实验。

如果想系统理解“如何评测一个 agent 是否真的可靠”，Inspect AI 是很好的入口。

3. SWE-bench

SWE-bench 是 coding agent 领域绕不开的 benchmark。

它的价值不只是排行榜，而是提供了一套非常重要的评测思路：

1
2
3
4
真实 GitHub issue
  -> agent 生成 patch
  -> 在真实仓库环境里运行测试
  -> 根据测试结果判断是否解决问题

这套流程本身就是很典型的 coding-agent evaluation harness。

4. hal-harness

princeton-pli/hal-harness 更偏研究型，和 SWE-bench、BrowserGym、Inspect 这类 eval/harness 生态有关。

它适合看如何把不同 benchmark 或 environment 包装成统一的评测 harness。

5. AutoHarness

aiming-lab/AutoHarness 从名字上就很贴近 “Automated Harness Engineering for AI Agents”。

这类项目适合关注新方向：如何自动生成、治理或演化 agent 的 harness。由于方向比较新，成熟度和适用场景需要自己进一步验证。

6. LangGraph

LangGraph 是做生产级 agent orchestration 时很值得看的框架。

它的核心价值在于：

  • 状态图；
  • 长期任务；
  • 可恢复流程；
  • 明确的节点和边；
  • human-in-the-loop；
  • checkpoint；
  • durable workflows。

如果要把 agent 从“聊天脚本”变成“可控流程”，LangGraph 是很好的参考。

7. Pydantic AI

Pydantic AI 更适合 Python 工程里的类型安全 agent harness。

它强调：

  • schema；
  • dependency injection；
  • tool typing；
  • provider-agnostic；
  • 可测试性；
  • production app 结构。

如果你喜欢工程结构清晰、类型约束明确的 agent 应用，它值得研究。

8. CrewAI

CrewAI 更偏 multi-agent workflow 和 role-based agents。

它适合研究多个 agent 如何分工、协作、顺序执行任务。但如果要用于严肃生产环境，仍然需要自己补上 eval、权限、观测和失败恢复机制。

9. Microsoft AutoGen / Agent Framework

AutoGen 是比较经典的 multi-agent 项目。现在 Microsoft 也有新的 Agent Framework。

这两个项目适合研究 multi-agent conversation、tool call 和 agent collaboration 的设计演进。

10. OpenHands

OpenHands 更像完整 coding agent 产品。

如果想理解 Claude Code、Devin、OpenHands 这一类 coding agent 的系统结构，可以从它看到很多完整模块：

  • 代码执行环境；
  • 文件系统；
  • 终端；
  • 浏览器；
  • 任务循环；
  • sandbox；
  • UI；
  • API；
  • evaluation。

它适合从“完整产品”角度理解 harness 是如何组合起来的。

推荐阅读路径

如果目标是系统学习 harness engineering，我建议按这个顺序看：

  1. Browser Harness / Browser Use
    先理解 browser agent 的环境控制、自愈机制和真实网页交互。

  2. Inspect AI
    学 eval harness 怎么组织 task、solver、scorer 和日志。

  3. SWE-bench
    学 coding agent 如何用真实 repo issue 做可验证评测。

  4. LangGraph 或 Pydantic AI
    学生产 agent runtime 怎么组织状态、工具和流程。

  5. OpenHands
    看完整 coding agent 产品的工程化组合。

总结

我对 harness engineering 的一句话总结是：

好的 harness engineering，是把“聪明的模型”变成“可靠的工作系统”。

未来 agent 产品的差距，很可能不只来自模型能力，而是来自模型外面的运行系统：工具是否合适，权限是否清晰，验证是否充分，失败是否可恢复，状态是否可追踪，人是否能在关键节点介入。

也就是说，模型负责推理，harness 负责让推理进入真实世界，并且尽量不把事情搞坏。