| English | 中文 |
HCP: Harness Communication Protocol
概述
HCP (Harness Communication Protocol) 是一个开放的、基于消息队列的协议,定义了 AI agent harness 之间的通信方式。它提供了一种标准化的方法来提交任务、验证执行安全性、管理会话生命周期,以及在 harness 之间交换事件和结果。
什么是 Harness?
Harness 是包裹 AI 模型 (LLM) 的运行时环境,负责编排模型与工具、资源和执行环境之间的交互。一个 harness 包含:
- Agent 循环 — 调用 LLM 并路由其决策的核心推理循环
- 工具与能力 — MCP 服务器、本地工具、沙箱、特定领域的工具
- 上下文管理 — 会话历史、记忆、上下文工程
- 自主迭代 — 能够自主决定执行策略并持续迭代直到任务完成
Harness 是一个能力的超集。与被动地接收参数并返回结果的工具不同,harness 具有自主推理能力 — 它决定的是如何完成任务,而不仅仅是执行什么。
核心概念:Harness 即技能
当一个 harness 将自身暴露为远程服务时,对于调用方 harness 而言,它表现为一个技能 (skill) — 一个具有名称、描述和输入/输出契约的能力单元。与传统工具或 MCP 服务器的关键区别在于,被调用方 harness:
- 接收的是意图 (要达成什么),而非命令 (要执行什么)
- 通过自身的 agent 循环自主决定执行计划
- 独立迭代,可能进行多次 LLM 调用和工具调用
- 通过事件协议向调用方流式传输进度
- 当任务完成、失败或中止时返回结果
┌─────────────────────────┐ ┌─────────────────────────┐
│ Caller Harness │ HCP │ Callee Harness │
│ │ │ │
│ LLM + Agent Loop │ Task / Events / Result│ LLM + Agent Loop │
│ Local Tools (MCP) │◄──────────────────────►│ Specialized Tools │
│ Skills (incl. remote) │ │ Domain Knowledge │
│ │ │ Physical Instruments │
└─────────────────────────┘ └─────────────────────────┘
HCP 与 MCP 的区别
| 维度 | MCP (Model Context Protocol) | HCP (Harness Communication Protocol) |
|---|---|---|
| 调用模型 | 确定性:使用参数调用工具 → 获取结果 | 自主式:提交带意图的任务 → harness 自主迭代 |
| 步骤数 | 单步 | 多步,步数不可预测 |
| 被调用方 | 被动工具 | 具有推理能力的 agent |
| 发现机制 | list_tools / list_resources |
无需发现;被调用方是已知的能力集 |
| 可见性 | 同步返回,无中间状态 | 包含进度、警告和中间结果的事件流 |
| 生命周期 | 无状态,调用即返回 | 有状态会话,可能持续数小时或数天 |
| 安全性 | 无 — 调用方负责安全调用 | 强制性 L3 安全门控:风险评估 (R1–R5)、权限审计、安全包络强制执行,在任何执行开始之前完成 |
| 契约 | 隐式 — 工具 schema 定义参数 | 显式 — 能力声明包含输入/输出 schema、风险上限、危害类别和操作约束 |
| 数据治理 | 无 | 数据分级 (T1–T4),具有敏感度感知的处理要求 |
| 授权 | 协议层无授权 | L3 签发 Session Token,限定和约束整个执行会话的范围 |
| 检查点与恢复 | 不适用(单步,无状态) | 长期运行任务的检查点机制;会话可在被调用方故障后存活并从最后一个检查点恢复 |
| 中止 | 不适用 | 调用方可以中止正在运行的会话;被调用方执行优雅清理 |
| 传输层 | Stdio / HTTP+SSE | AMQP 0-9-1,支持持久化投递、消息持久化和内置重连 |
| 作用域 | 在 harness 内部用于调用工具 | 在 harness 之间用于委托自主工作 |
MCP 和 HCP 是互补的,而非竞争关系。MCP 作为工具调用协议在 harness 内部运作。HCP 作为任务委托协议在 harness 之间运作。
设计原则
1. 单向调用模型
通信遵循严格的调用方 → 被调用方方向。被调用方在任务执行期间不会回调调用方。这使协议保持简洁,避免了复杂的双向状态管理。简洁性促进生态系统的采用。
2. 安全性作为核心层
安全验证不是可选的。每次任务提交都必须在执行开始前通过安全契约层。该层评估风险、验证权限、执行安全包络,并签发约束执行范围的 session token。这对于涉及物理设备、危险物质或敏感数据的场景至关重要。
3. 协议简洁性
核心协议覆盖最常见的交互模式。高级特性如任务粒度级别、子任务分解和多方协调通过扩展而非核心规范来解决。简洁的核心协议鼓励实现和采用。
4. 标准化传输
HCP 将 AMQP 0-9-1 标准化为其传输协议。通过固定传输层,每个符合 HCP 的 harness 都使用相同的线路协议 — 被调用方 harness 只需一种实现,任何调用方都可以通过共享的 AMQP broker 与任何被调用方通信。这避免了不同被调用方需要不同传输适配器所导致的生态系统碎片化。
5. Harness 自主性
协议尊重被调用方 harness 的自主性。调用方描述应该达成什么(意图、约束、预期输出),但不规定如何实现。被调用方的内部执行 — 使用哪个 LLM、调用哪些工具、执行多少次迭代 — 对协议而言是不透明的。
协议栈
HCP 组织为四层协议栈:
| 层级 | 名称 | 职责 |
|---|---|---|
| L4 | 任务层 (Task Layer) | 任务提交、意图描述、约束条件、结果交换 |
| L3 | 安全与契约层 (Safety & Contract Layer) | 能力声明、风险评估、权限审计、session token 签发 |
| L2 | 会话与生命周期层 (Session & Lifecycle Layer) | 会话状态机、事件流协议、检查点、中断/恢复 |
| L1 | 传输与编码层 (Transport & Encoding Layer) | 消息信封格式、AMQP 拓扑、通道规范 |
数据在任务提交时向下流过协议栈 (L4 → L3 → L2 → L1),事件在执行时向上流动 (L1 → L2 → L4)。
详见 architecture.md 了解详细的层级架构和交互模型。