Plugins 导读

Agent Harness 不是 Provider,也不是 Channel——它是模型原生运行时的执行器

当你有一个模型家族自带会话运行时(比如 coding-agent 服务器、本地 CLI),且 OpenClaw 的标准 Provider 传输不适用时,才需要注册一个 Agent Harness。最容易搞错的是:不要为了接入一个新 LLM API 就写 Harness——那是 Provider 插件的事。注册前先确认你的场景是否真的需要接管整个 turn 的执行,否则用内置 PI 即可。

先讲这一页到底在解决什么

Agent Harness 不是 Provider,也不是 Channel——它是模型原生运行时的执行器

当你有一个模型家族自带会话运行时(比如 coding-agent 服务器、本地 CLI),且 OpenClaw 的标准 Provider 传输不适用时,才需要注册一个 Agent Harness。最容易搞错的是:不要为了接入一个新 LLM API 就写 Harness——那是 Provider 插件的事。注册前先确认你的场景是否真的需要接管整个 turn 的执行,否则用内置 PI 即可。

原文共 14 节,先看 Start Here 路径:/plugins/sdk-agent-harness 查看官方原文

第一站

什么时候需要 harness

普通 provider 不够用

如果对方只是 HTTP 模型 API,用 provider 就好,不要搬出 harness。

原生会话很强

如果模型家族自带完整 session runtime、工具事件和任务状态,harness 才有意义。

Codex 是典型例子

Codex 有自己的线程、工具、媒体结果和 transcript,所以需要更原生的接法。

实验边界

参数类型贴着当前 embedded runner,未来可能会变,所以不适合随便给外部插件依赖。

第二站

Core 仍然握着方向盘

注册 harness 不代表插件接管整个 OpenClaw。核心系统仍然负责很多共同规则。

1

选择策略

什么时候用哪个 harness,由核心选择政策决定。

2

上下文准备

核心负责把 turn 准备好,再交给执行器。

3

结果分类

终端结果要被分成成功、失败、取消等可理解状态。

4

严格模式

运行时边界要检查清楚,避免插件越界。

第三站

Provider 加 harness,像“大脑”和“驾驶舱”配对

Provider

告诉 OpenClaw 这个模型家族存在,可以怎样被选择。

Harness

真正跑这一轮 agent turn,处理原生会话和工具流。

Tool-result middleware

像工具结果进驾驶舱前的检查口,可以整理、转换或拒绝不合适的结果。

Transcript mirror

原生运行时里的对话和工具事件,需要能映射回 OpenClaw 可追踪的记录。