很多 AI Agent 讨论只盯着模型，但真正能落地的 Agent 应用，通常还需要一层 harness：把模型、工具、状态、记忆、权限和观测组织起来。
你可以把 agent harness 理解为 Agent 的运行承载层。
截至 2026-06-13，AgentClaw 把这个词当作方法论使用，而不是把它限定为某一个产品。Hermes、OpenClaw、Harness AI、coding agent harness 工具都能从这个角度理解：模型只是推理核心，harness 决定它能在什么边界内行动、如何恢复、如何被审计。
一个 Agent Harness 通常包含什么
| 组成 | 解决的问题 |
|---|---|
| Model | 负责推理、规划、生成 |
| Tools | 让 Agent 能读写文件、访问网页、调用 API |
| State | 保存当前任务进度和上下文 |
| Memory | 保存跨会话的长期事实和偏好 |
| Permissions | 限制哪些动作能自动执行 |
| Guardrails | 防止越权、误操作和高风险输出 |
| Observability | 记录任务、日志、调用和失败原因 |
| Human-in-the-loop | 在关键动作前要求人工确认 |
这张表的重点不是“组件越多越好”，而是帮你判断一个 Agent 应用是否已经进入真实环境。一个 demo 可以只有 model 和 tools；一个要长期运行的 Agent，通常还需要 state、memory、permissions、observability 和人工确认。
用这个框架看 OpenClaw、Hermes、Harness
- OpenClaw：重点在渠道、Gateway、审批、安全和多入口工作流。
- Hermes：重点在 memory、skills、messaging gateway、cron 和长期运行。
- Harness AI：重点在 DevOps 平台内的 pipeline、code、MCP、worker agents 和企业工作流。
这三类内容不是同一层级，但都能放进 agent harness 的评估框架。
| 维度 | OpenClaw | Hermes | Harness AI |
|---|---|---|---|
| 主要入口 | 自托管工作台、渠道、Gateway | CLI、messaging gateway、cron、API Server | Harness 平台、DevOps Agent、MCP、IDE |
| 更强的问题 | 个人/团队助手的渠道与控制 | 长期记忆、skills、定时任务 | pipeline、部署、策略、代码与平台工程 |
| 风险重点 | 密钥、审批、多渠道误触发 | 记忆污染、skill 越权、cron 自动执行 | 平台权限、生产变更、审计与回滚 |
| 适合先验证 | 一个低风险 channel + 审批流 | 一个 memory/skill/cron 小场景 | pipeline 解释或草稿生成 |
所以，agent harness 不是又一个品牌名。它更像一个透镜：用同一组问题观察不同 Agent 系统，避免只凭功能名做选择。
选型时问 7 个问题
- Agent 能调用哪些工具？
- 工具权限是否可控？
- 失败时能否看日志和回滚？
- 是否有长期记忆，记忆是否可审查？
- 能否接入真实入口，比如消息、API、pipeline？
- 高风险动作是否需要人工确认？
- 是否有官方文档和稳定更新？
这 7 个问题可以进一步拆成一张执行清单：
| 检查项 | 低风险答案 | 高风险信号 |
|---|---|---|
| 工具调用 | 工具按用途分组，默认只读或需确认 | 工具权限过宽，写操作默认放行 |
| 状态管理 | 任务进度、输入、输出和失败原因可追踪 | 失败后只能靠聊天记录猜测发生了什么 |
| 记忆 | 只保存长期有价值事实，可审查、可清理 | 把临时内容、敏感信息或错误结论写入长期记忆 |
| 权限 | secrets、token、账号和渠道入口分层管理 | 所有环境共用同一组密钥 |
| Guardrails | 高风险动作前有审批、回滚和日志 | Agent 能直接改生产配置或发布代码 |
| 观测 | 有日志、事件、退出状态和人工复盘入口 | 成功/失败只有一段自然语言描述 |
如果一个 Agent 系统在这些问题上没有答案，说明它还停留在 demo 或个人实验阶段，不适合直接承接团队工作流。
从官方资料倒推能力边界
官方资料通常不会直接说“这是一个 harness”，但你可以从它强调的能力倒推系统边界。
- Hermes 官方资料强调 Quickstart、memory、skills、messaging、cron、profiles、API server 和从 OpenClaw 迁移，说明它的 harness 重心在长期运行与多入口助手。
- OpenClaw 官方资料强调 gateway、security、control UI、skills 和 channels，说明它的 harness 重心在自托管控制、渠道接入和人工治理。
- Harness AI 官方资料强调 DevOps Agent、Worker Agents、Harness Skills、MCP Server、VS Code Extension 和 Code Agent，说明它的 harness 重心在平台工程和 DevOps 工作流。
这比单看产品宣传更有用。一个产品说自己是 Agent，不代表它适合所有 Agent 场景；它的官方文档结构，往往已经暗示了它真正优化的运行环境。
什么时候不需要完整 harness
并不是所有 AI 功能都需要复杂 harness。
如果你的任务只是：
- 让模型解释一段日志。
- 生成一次性文案或代码片段。
- 在本地临时运行一个小脚本。
- 用聊天窗口做一次性头脑风暴。
那你可能只需要模型和少量工具。完整 harness 的成本包括配置、权限、日志、记忆治理和维护成本。只有当任务会重复、会影响真实系统、需要跨会话延续，或者要进入团队协作时，harness 才开始变成必要条件。
常见误区
- 只看模型，不看工具权限。
- 只看 demo，不看失败处理。
- 只看 memory，不看记忆清理。
- 只看自动化，不看人工确认。
- 只看功能列表，不看能否进入已有工作流。
还有一个常见误区，是把 agent harness 理解成“把多个 agent 接在一起”。编排多个 agent 只是可能的一种结果，不是核心定义。更关键的是：每个 agent 是否在可控环境里运行，是否知道自己能做什么，是否留下可追踪证据，是否能在出错时回到安全状态。
上线前风险边界
如果你准备把某个 Agent 应用放进真实流程，至少先定 6 条边界：
- 哪些工具是只读，哪些工具能写入。
- 哪些写操作必须人工确认。
- 哪些 secrets 永远不进入长期记忆。
- 哪些渠道入口可以触发任务，哪些只能接收通知。
- 失败后如何停止任务、回滚状态和通知负责人。
- 日志保留多久，谁可以查看，是否包含敏感信息。
这些边界听起来不像“AI 功能”，但它们决定了 Agent 是否能从 demo 进入真实工作。越靠近生产系统、客户数据、支付、部署和账号权限，越不能省略这部分。
完成检查
- 你能用 model / tools / state / memory / permissions / observability 来描述一个 Agent 应用。
- 你知道 OpenClaw、Hermes、Harness 各自更强的层面。
- 你能用同一张清单评估未来新的 Agent 应用。
- 你能识别一个 Agent 是否只有 demo 能力，还是已经具备运行、审计和回滚条件。
- 你知道什么时候应该保持简单，不必为了小任务引入完整 harness。