Harness：智能体的运行时基座
软件工程能力不再只由模型决定，而是由 Model–Harness–Environment 联合决定。
什么是 Harness
在智能体系统中，Harness（运行时基座）指的是介于模型与应用之间的那一层基础设施——它负责将模型的推理能力转化为可执行、可观测、可恢复、可治理的实际行为。
如果把大模型比作引擎，那么 Harness 就是底盘：引擎提供动力，底盘负责转向、制动、悬挂和传动。没有底盘的引擎无法上路，没有 Harness 的模型也无法可靠地完成实际任务。
Harness 的正式定义可以概括为：
Harness 是一个运行时基座（Runtime Substrate），负责 mediates observation / action / feedback / completion——即中介观察、行动、反馈与完成。
这一概念在 2025–2026 年间迅速获得关注，学术研究已把 Claude Code、OpenAI Codex、Hermes Agent、OpenClaw 等产品统一归类为 CLI Harness，标志着智能体工程正在形成新的共识层。
Harness 的三层定位
在智能体系统的架构中，Harness 处于一个关键的中间层位置：
- 模型层：提供 LLM 推理引擎和工具调用能力
- Harness 层：单 Agent 的运行时基座，负责观察、行动、反馈、验证、权限与记忆
- Agent Runtime 层：更上层，负责多会话、多租户、调度、持久化、治理与控制面
Harness 的核心职责
一个完整的 Harness 需要承担以下六项核心职责：
1. 观察（Observation）
Harness 负责从环境中采集信息并组装成模型可理解的上下文。这包括：
- 文件系统状态与变更追踪
- 进程输出与日志收集
- 用户输入与意图解析
- 外部 API 响应的结构化处理
2. 行动（Action）
Harness 将模型的工具调用决策转化为受控的实际行动：
- 工具调用的审批与门控
- 执行环境的沙箱隔离
- 并发工具调用的调度
- 副作用的追踪与记录
3. 反馈（Feedback）
Harness 为模型提供执行结果的反馈回路：
- 工具执行结果的结构化回写
- 错误处理与重试策略
- 上下文压缩与摘要
- 多步推理的中间状态维护
4. 验证（Completion）
Harness 确保任务完成的质量和可信度：
- 输出的结构化校验
- 测试执行与结果判定
- 副作用的审计追踪
- 证据包的生成与存档
5. 权限（Permission）
Harness 管理智能体的操作权限边界：
- 破坏性操作的审批流程
- 能力的 Allowlist 与 Blocklist
- 文件/网络/进程级别的访问控制
- 操作日志与审计追踪
6. 记忆（Memory）
Harness 维护智能体的状态持续性：
- 会话状态的持久化存储
- 跨会话的长期记忆管理
- 检查点（Checkpoint）的创建与恢复
- Session Lineage 的维护
从框架到 Harness 的范式转变
| 维度 | 框架范式 | Harness 范式 |
|---|---|---|
| 核心抽象 | Chain / Graph / Pipeline | Episode / Session / Task Graph |
| 状态模型 | 无状态或单次请求状态 | 持久化会话、检查点、Lineage |
| 执行环境 | 调用方进程内 | 独立 Sandbox、Gateway、Cron |
| 错误处理 | 抛异常、Retry | Checkpoint、Rollback、Session Resume |
| 安全模型 | Prompt Guardrails | 权限审批、能力隔离、审计追踪 |
| 可观测性 | Print / Logging | 结构化日志、证据包、审计追踪 |
这场转变的核心驱动力是：Agent 从一次性任务执行走向长期自治运行。当 Agent 需要持续运行数小时甚至数天，传统的无状态框架范式就不再适用——你需要检查点来恢复、审计来追查、权限来约束、记忆来延续。
Harness 的产品化实践
2026 年，多个代表性产品已经在不同形态下实现了 Harness 的核心理念：
Hermes: Always-on Harness
Hermes Agent 是一个 Productized Harness 的典型案例。它的核心能力包括：
- Shadow Git 检查点——破坏性操作前快照工作目录，支持
/rollback回退 - FTS5 会话检索——基于全文索引的会话历史快速查找
- 跨会话记忆与技能——支持 Agent 在多次会话间保持能力连续性
- Gateway 架构——通过统一入口连接 20+ 消息平台
- 危险命令审批——破坏性操作的权限门控
Claude Code：开发者 Harness
Claude Code 展示了面向开发者的 Harness 形态：
- 终端、IDE、桌面、Web 共享同一底层引擎
- Auto Memory 自动管理上下文窗口
- Skills 系统支持能力扩展
- Background Agents 支持后台长任务
- 文件编辑级别的权限门控
OpenAI Codex：云端异步 Harness
OpenAI Codex 代表了云端异步的 Harness 形态：
- 每个任务在独立隔离环境中运行
- 可读写仓库、跑测试与 Harness
- 通过日志和测试结果提供可验证证据
- 完全异步的提交 - 审查模式
Harness 与智能体运行时的关系
Harness 和 Agent Runtime 是两个互补的概念，理解它们的关系对于构建完整的智能体系统至关重要：
- Harness 是单 Agent 的运行时基座，负责个体 Agent 的执行质量
- Agent Runtime 是多 Agent 的运营平台，负责系统级的调度与治理
- 一个 Agent Runtime 可以管理多个 Harness 实例
这与本书「智能体运行时概览」中描述的"把 Agent 当 Workload 运营"的思路一脉相承：Harness 是 Workload 的执行层，Agent Runtime 是 Workload 的管理层。
安全考量
Harness 的设计必须正视 Always-on Agent 带来的新安全挑战：
- Prompt Injection 风险：消息、记忆、技能、调度和 Shell 折叠进同一 Authority Boundary，会形成新的注入攻击面
- Confused Deputy 问题：Agent 可能被欺骗以合法权限执行非预期操作
- 权限逃逸：仅靠 Shell 级 Permission Gate 不足以覆盖文件编辑等操作的风险
- 检查点安全：Shadow Git 快照可能包含敏感信息，需要访问控制
总结
Harness 概念的兴起，标志着智能体工程正在从"如何编写 Agent 逻辑"转向"如何为 Agent 提供可靠的运行时基座"。这一转变有三个关键含义：
- 工程质量决定上限：模型能力不再是唯一瓶颈，Harness 的完整性直接影响 Agent 的实际表现
- 标准化势在必行：随着 Claude Code、Hermes、Codex 等产品的收敛，Harness 的核心职责正在形成共识
- 层次分离是趋势：Harness（执行基座）与 Agent Runtime（调度治理）的分离，使得系统可以在不同尺度上独立演进
理解 Harness，是理解「智能体作为 Workload」和「自治闭环」的前提——因为 Harness 正是把 Workload 的抽象和 Control Loop 的自治，落地为可运行、可治理的工程系统。
参考链接
- Agentic Harness Engineering: A Survey of the Emerging Paradigm — Harness 工程综述论文，系统梳理了 Harness 的定义、ETCLOVG 七层分类法与代表性产品
- SemaClaw: Semantic Analysis of CLI Agent Workflows — CLI Agent 工作流的语义分析，将 Claude Code、Codex、Hermes、OpenClaw 统一归类为 CLI Harness
- NLAH: A New Lens on Agent Harness — 从新视角分析 Agent Harness 的安全与工程挑战
- Hermes Agent GitHub 仓库 — Hermes 开源代码与架构文档
- Hermes Agent 官方文档 — 包含 Agent Loop、Session Storage、Security 等详细说明