first commit

This commit is contained in:
2026-02-28 23:01:30 +08:00
commit 3956ee4806
415 changed files with 74538 additions and 0 deletions

424
content/refactor/clawnet.md Normal file
View File

@@ -0,0 +1,424 @@
---
read_when:
- 规划节点 + 操作者客户端的统一网络协议
- 重新设计跨设备的审批、配对、TLS 和在线状态
summary: Clawnet 重构:统一网络协议、角色、认证、审批、身份
title: Clawnet 重构
x-i18n:
generated_at: "2026-02-03T07:55:03Z"
model: claude-opus-4-5
provider: pi
source_hash: 719b219c3b326479658fe6101c80d5273fc56eb3baf50be8535e0d1d2bb7987f
source_path: refactor/clawnet.md
workflow: 15
---
# Clawnet 重构(协议 + 认证统一)
## 嗨
嗨 Peter — 方向很好;这将解锁更简单的用户体验 + 更强的安全性。
## 目的
单一、严谨的文档用于:
- 当前状态:协议、流程、信任边界。
- 痛点审批、多跳路由、UI 重复。
- 提议的新状态:一个协议、作用域角色、统一的认证/配对、TLS 固定。
- 身份模型:稳定 ID + 可爱的别名。
- 迁移计划、风险、开放问题。
## 目标(来自讨论)
- 所有客户端使用一个协议mac 应用、CLI、iOS、Android、无头节点
- 每个网络参与者都经过认证 + 配对。
- 角色清晰:节点 vs 操作者。
- 中央审批路由到用户所在位置。
- 所有远程流量使用 TLS 加密 + 可选固定。
- 最小化代码重复。
- 单台机器应该只显示一次(无 UI/节点重复条目)。
## 非目标(明确)
- 移除能力分离(仍需要最小权限)。
- 不经作用域检查就暴露完整的 Gateway 网关控制平面。
- 使认证依赖于人类标签(别名仍然是非安全性的)。
---
# 当前状态(现状)
## 两个协议
### 1) Gateway 网关 WebSocket控制平面
- 完整 API 表面:配置、渠道、模型、会话、智能体运行、日志、节点等。
- 默认绑定loopback。通过 SSH/Tailscale 远程访问。
- 认证:通过 `connect` 的令牌/密码。
- 无 TLS 固定(依赖 loopback/隧道)。
- 代码:
- `src/gateway/server/ws-connection/message-handler.ts`
- `src/gateway/client.ts`
- `docs/gateway/protocol.md`
### 2) Bridge节点传输
- 窄允许列表表面,节点身份 + 配对。
- TCP 上的 JSONL可选 TLS + 证书指纹固定。
- TLS 在设备发现 TXT 中公布指纹。
- 代码:
- `src/infra/bridge/server/connection.ts`
- `src/gateway/server-bridge.ts`
- `src/node-host/bridge-client.ts`
- `docs/gateway/bridge-protocol.md`
## 当前的控制平面客户端
- CLI → 通过 `callGateway``src/gateway/call.ts`)连接 Gateway 网关 WS。
- macOS 应用 UI → Gateway 网关 WS`GatewayConnection`)。
- Web 控制 UI → Gateway 网关 WS。
- ACP → Gateway 网关 WS。
- 浏览器控制使用自己的 HTTP 控制服务器。
## 当前的节点
- macOS 应用在节点模式下连接到 Gateway 网关 bridge`MacNodeBridgeSession`)。
- iOS/Android 应用连接到 Gateway 网关 bridge。
- 配对 + 每节点令牌存储在 Gateway 网关上。
## 当前审批流程exec
- 智能体通过 Gateway 网关使用 `system.run`
- Gateway 网关通过 bridge 调用节点。
- 节点运行时决定审批。
- UI 提示由 mac 应用显示(当节点 == mac 应用时)。
- 节点向 Gateway 网关返回 `invoke-res`
- 多跳UI 绑定到节点主机。
## 当前的在线状态 + 身份
- 来自 WS 客户端的 Gateway 网关在线状态条目。
- 来自 bridge 的节点在线状态条目。
- mac 应用可能为同一台机器显示两个条目UI + 节点)。
- 节点身份存储在配对存储中UI 身份是分开的。
---
# 问题/痛点
- 需要维护两个协议栈WS + Bridge
- 远程节点上的审批:提示出现在节点主机上,而不是用户所在位置。
- TLS 固定仅存在于 bridgeWS 依赖 SSH/Tailscale。
- 身份重复:同一台机器显示为多个实例。
- 角色模糊UI + 节点 + CLI 能力没有明确分离。
---
# 提议的新状态Clawnet
## 一个协议,两个角色
带有角色 + 作用域的单一 WS 协议。
- **角色node**(能力宿主)
- **角色operator**(控制平面)
- 操作者的可选**作用域**
- `operator.read`(状态 + 查看)
- `operator.write`(智能体运行、发送)
- `operator.admin`(配置、渠道、模型)
### 角色行为
**Node**
- 可以注册能力(`caps``commands`、permissions
- 可以接收 `invoke` 命令(`system.run``camera.*``canvas.*``screen.record` 等)。
- 可以发送事件:`voice.transcript``agent.request``chat.subscribe`
- 不能调用配置/模型/渠道/会话/智能体控制平面 API。
**Operator**
- 完整控制平面 API受作用域限制。
- 接收所有审批。
- 不直接执行 OS 操作;路由到节点。
### 关键规则
角色是按连接的,不是按设备。一个设备可以分别打开两个角色。
---
# 统一认证 + 配对
## 客户端身份
每个客户端提供:
- `deviceId`(稳定的,从设备密钥派生)。
- `displayName`(人类名称)。
- `role` + `scope` + `caps` + `commands`
## 配对流程(统一)
- 客户端未认证连接。
- Gateway 网关为该 `deviceId` 创建**配对请求**。
- 操作者收到提示;批准/拒绝。
- Gateway 网关颁发绑定到以下内容的凭证:
- 设备公钥
- 角色
- 作用域
- 能力/命令
- 客户端持久化令牌,重新认证连接。
## 设备绑定认证(避免 bearer 令牌重放)
首选:设备密钥对。
- 设备一次性生成密钥对。
- `deviceId = fingerprint(publicKey)`
- Gateway 网关发送 nonce设备签名Gateway 网关验证。
- 令牌颁发给公钥(所有权证明),而不是字符串。
替代方案:
- mTLS客户端证书最强运维复杂度更高。
- 短期 bearer 令牌仅作为临时阶段(早期轮换 + 撤销)。
## 静默批准SSH 启发式)
精确定义以避免薄弱环节。优选其一:
- **仅限本地**:当客户端通过 loopback/Unix socket 连接时自动配对。
- **通过 SSH 质询**Gateway 网关颁发 nonce客户端通过获取它来证明 SSH。
- **物理存在窗口**:在 Gateway 网关主机 UI 上本地批准后,允许在短窗口内(例如 10 分钟)自动配对。
始终记录 + 记录自动批准。
---
# TLS 无处不在(开发 + 生产)
## 复用现有 bridge TLS
使用当前 TLS 运行时 + 指纹固定:
- `src/infra/bridge/server/tls.ts`
- `src/node-host/bridge-client.ts` 中的指纹验证逻辑
## 应用于 WS
- WS 服务器使用相同的证书/密钥 + 指纹支持 TLS。
- WS 客户端可以固定指纹(可选)。
- 设备发现为所有端点公布 TLS + 指纹。
- 设备发现仅是定位器提示;永远不是信任锚。
## 为什么
- 减少对 SSH/Tailscale 的机密性依赖。
- 默认情况下使远程移动连接安全。
---
# 审批重新设计(集中化)
## 当前
审批发生在节点主机上mac 应用节点运行时)。提示出现在节点运行的地方。
## 提议
审批是 **Gateway 网关托管的**UI 传递给操作者客户端。
### 新流程
1. Gateway 网关接收 `system.run` 意图(智能体)。
2. Gateway 网关创建审批记录:`approval.requested`
3. 操作者 UI 显示提示。
4. 审批决定发送到 Gateway 网关:`approval.resolve`
5. 如果批准Gateway 网关调用节点命令。
6. 节点执行,返回 `invoke-res`
### 审批语义(加固)
- 广播到所有操作者;只有活跃的 UI 显示模态框(其他显示 toast
- 先解决者获胜Gateway 网关拒绝后续解决为已结算。
- 默认超时N 秒后拒绝(例如 60 秒),记录原因。
- 解决需要 `operator.approvals` 作用域。
## 好处
- 提示出现在用户所在位置mac/手机)。
- 远程节点的一致审批。
- 节点运行时保持无头;无 UI 依赖。
---
# 角色清晰示例
## iPhone 应用
- **Node 角色**用于:麦克风、相机、语音聊天、位置、一键通话。
- 可选的 **operator.read** 用于状态和聊天视图。
- 可选的 **operator.write/admin** 仅在明确启用时。
## macOS 应用
- 默认是 Operator 角色(控制 UI
- 启用"Mac 节点"时是 Node 角色system.run、屏幕、相机
- 两个连接使用相同的 deviceId → 合并的 UI 条目。
## CLI
- 始终是 Operator 角色。
- 作用域按子命令派生:
- `status``logs` → read
- `agent``message` → write
- `config``channels` → admin
- 审批 + 配对 → `operator.approvals` / `operator.pairing`
---
# 身份 + 别名
## 稳定 ID
认证必需;永不改变。
首选:
- 密钥对指纹(公钥哈希)。
## 可爱别名(龙虾主题)
仅人类标签。
- 示例:`scarlet-claw``saltwave``mantis-pinch`
- 存储在 Gateway 网关注册表中,可编辑。
- 冲突处理:`-2``-3`
## UI 分组
跨角色的相同 `deviceId` → 单个"实例"行:
- 徽章:`operator``node`
- 显示能力 + 最后在线。
---
# 迁移策略
## 阶段 0记录 + 对齐
- 发布此文档。
- 盘点所有协议调用 + 审批流程。
## 阶段 1向 WS 添加角色/作用域
-`role``scope``deviceId` 扩展 `connect` 参数。
- 为 node 角色添加允许列表限制。
## 阶段 2Bridge 兼容性
- 保持 bridge 运行。
- 并行添加 WS node 支持。
- 通过配置标志限制功能。
## 阶段 3中央审批
- 在 WS 中添加审批请求 + 解决事件。
- 更新 mac 应用 UI 以提示 + 响应。
- 节点运行时停止提示 UI。
## 阶段 4TLS 统一
- 使用 bridge TLS 运行时为 WS 添加 TLS 配置。
- 向客户端添加固定。
## 阶段 5弃用 bridge
- 将 iOS/Android/mac 节点迁移到 WS。
- 保持 bridge 作为后备;稳定后移除。
## 阶段 6设备绑定认证
- 所有非本地连接都需要基于密钥的身份。
- 添加撤销 + 轮换 UI。
---
# 安全说明
- 角色/允许列表在 Gateway 网关边界强制执行。
- 没有客户端可以在没有 operator 作用域的情况下获得"完整"API。
- *所有*连接都需要配对。
- TLS + 固定减少移动设备的 MITM 风险。
- SSH 静默批准是便利措施;仍然记录 + 可撤销。
- 设备发现永远不是信任锚。
- 能力声明通过按平台/类型的服务器允许列表验证。
# 流式传输 + 大型负载(节点媒体)
WS 控制平面对于小消息没问题,但节点还做:
- 相机剪辑
- 屏幕录制
- 音频流
选项:
1. WS 二进制帧 + 分块 + 背压规则。
2. 单独的流式端点(仍然是 TLS + 认证)。
3. 对于媒体密集型命令保持 bridge 更长时间,最后迁移。
在实现前选择一个以避免漂移。
# 能力 + 命令策略
- 节点报告的 caps/commands 被视为**声明**。
- Gateway 网关强制执行每平台允许列表。
- 任何新命令都需要操作者批准或显式允许列表更改。
- 用时间戳审计更改。
# 审计 + 速率限制
- 记录:配对请求、批准/拒绝、令牌颁发/轮换/撤销。
- 速率限制配对垃圾和审批提示。
# 协议卫生
- 显式协议版本 + 错误代码。
- 重连规则 + 心跳策略。
- 在线状态 TTL 和最后在线语义。
---
# 开放问题
1. 同时运行两个角色的单个设备:令牌模型
- 建议每个角色单独的令牌node vs operator
- 相同的 deviceId不同的作用域更清晰的撤销。
2. 操作者作用域粒度
- read/write/admin + approvals + pairing最小可行
- 以后考虑每功能作用域。
3. 令牌轮换 + 撤销 UX
- 角色更改时自动轮换。
- 按 deviceId + 角色撤销的 UI。
4. 设备发现
- 扩展当前 Bonjour TXT 以包含 WS TLS 指纹 + 角色提示。
- 仅作为定位器提示处理。
5. 跨网络审批
- 广播到所有操作者客户端;活跃的 UI 显示模态框。
- 先响应者获胜Gateway 网关强制原子性。
---
# 总结TL;DR
- 当前WS 控制平面 + Bridge 节点传输。
- 痛点:审批 + 重复 + 两个栈。
- 提议:一个带有显式角色 + 作用域的 WS 协议,统一配对 + TLS 固定Gateway 网关托管的审批,稳定设备 ID + 可爱别名。
- 结果:更简单的 UX更强的安全性更少的重复更好的移动路由。

View File

@@ -0,0 +1,323 @@
---
read_when:
- 设计 exec 主机路由或 exec 批准
- 实现节点运行器 + UI IPC
- 添加 exec 主机安全模式和斜杠命令
summary: 重构计划exec 主机路由、节点批准和无头运行器
title: Exec 主机重构
x-i18n:
generated_at: "2026-02-03T07:54:43Z"
model: claude-opus-4-5
provider: pi
source_hash: 53a9059cbeb1f3f1dbb48c2b5345f88ca92372654fef26f8481e651609e45e3a
source_path: refactor/exec-host.md
workflow: 15
---
# Exec 主机重构计划
## 目标
- 添加 `exec.host` + `exec.security` 以在**沙箱**、**Gateway 网关**和**节点**之间路由执行。
- 保持默认**安全**:除非明确启用,否则不进行跨主机执行。
- 将执行拆分为**无头运行器服务**,通过本地 IPC 连接可选的 UImacOS 应用)。
- 提供**每智能体**策略、允许列表、询问模式和节点绑定。
- 支持*与*或*不与*允许列表一起使用的**询问模式**。
- 跨平台Unix socket + token 认证macOS/Linux/Windows 一致性)。
## 非目标
- 无遗留允许列表迁移或遗留 schema 支持。
- 节点 exec 无 PTY/流式传输(仅聚合输出)。
- 除现有 Bridge + Gateway 网关外无新网络层。
## 决定(已锁定)
- **配置键:** `exec.host` + `exec.security`(允许每智能体覆盖)。
- **提升:** 保留 `/elevated` 作为 Gateway 网关完全访问的别名。
- **询问默认:** `on-miss`
- **批准存储:** `~/.openclaw/exec-approvals.json`JSON无遗留迁移
- **运行器:** 无头系统服务UI 应用托管 Unix socket 用于批准。
- **节点身份:** 使用现有 `nodeId`
- **Socket 认证:** Unix socket + token跨平台如需要稍后拆分。
- **节点主机状态:** `~/.openclaw/node.json`(节点 id + 配对 token
- **macOS exec 主机:** 在 macOS 应用内运行 `system.run`;节点主机服务通过本地 IPC 转发请求。
- **无 XPC helper** 坚持使用 Unix socket + token + 对等检查。
## 关键概念
### 主机
- `sandbox`Docker exec当前行为
- `gateway`:在 Gateway 网关主机上执行。
- `node`:通过 Bridge 在节点运行器上执行(`system.run`)。
### 安全模式
- `deny`:始终阻止。
- `allowlist`:仅允许匹配项。
- `full`:允许一切(等同于提升模式)。
### 询问模式
- `off`:从不询问。
- `on-miss`:仅在允许列表不匹配时询问。
- `always`:每次都询问。
询问**独立于**允许列表;允许列表可与 `always``on-miss` 一起使用。
### 策略解析(每次执行)
1. 解析 `exec.host`(工具参数 → 智能体覆盖 → 全局默认)。
2. 解析 `exec.security``exec.ask`(相同优先级)。
3. 如果主机是 `sandbox`,继续本地沙箱执行。
4. 如果主机是 `gateway``node`,在该主机上应用安全 + 询问策略。
## 默认安全
- 默认 `exec.host = sandbox`
- `gateway``node` 默认 `exec.security = deny`
- 默认 `exec.ask = on-miss`(仅在安全允许时相关)。
- 如果未设置节点绑定,**智能体可以定向任何节点**,但仅在策略允许时。
## 配置表面
### 工具参数
- `exec.host`(可选):`sandbox | gateway | node`
- `exec.security`(可选):`deny | allowlist | full`
- `exec.ask`(可选):`off | on-miss | always`
- `exec.node`(可选):当 `host=node` 时使用的节点 id/名称。
### 配置键(全局)
- `tools.exec.host`
- `tools.exec.security`
- `tools.exec.ask`
- `tools.exec.node`(默认节点绑定)
### 配置键(每智能体)
- `agents.list[].tools.exec.host`
- `agents.list[].tools.exec.security`
- `agents.list[].tools.exec.ask`
- `agents.list[].tools.exec.node`
### 别名
- `/elevated on` = 为智能体会话设置 `tools.exec.host=gateway``tools.exec.security=full`
- `/elevated off` = 为智能体会话恢复之前的 exec 设置。
## 批准存储JSON
路径:`~/.openclaw/exec-approvals.json`
用途:
- **执行主机**Gateway 网关或节点运行器)的本地策略 + 允许列表。
- 无 UI 可用时的询问回退。
- UI 客户端的 IPC 凭证。
建议的 schemav1
```json
{
"version": 1,
"socket": {
"path": "~/.openclaw/exec-approvals.sock",
"token": "base64-opaque-token"
},
"defaults": {
"security": "deny",
"ask": "on-miss",
"askFallback": "deny"
},
"agents": {
"agent-id-1": {
"security": "allowlist",
"ask": "on-miss",
"allowlist": [
{
"pattern": "~/Projects/**/bin/rg",
"lastUsedAt": 0,
"lastUsedCommand": "rg -n TODO",
"lastResolvedPath": "/Users/user/Projects/.../bin/rg"
}
]
}
}
}
```
注意事项:
- 无遗留允许列表格式。
- `askFallback` 仅在需要 `ask` 且无法访问 UI 时应用。
- 文件权限:`0600`
## 运行器服务(无头)
### 角色
- 在本地强制执行 `exec.security` + `exec.ask`
- 执行系统命令并返回输出。
- 为 exec 生命周期发出 Bridge 事件(可选但推荐)。
### 服务生命周期
- macOS 上的 Launchd/daemonLinux/Windows 上的系统服务。
- 批准 JSON 是执行主机本地的。
- UI 托管本地 Unix socket运行器按需连接。
## UI 集成macOS 应用)
### IPC
- Unix socket 位于 `~/.openclaw/exec-approvals.sock`0600
- Token 存储在 `exec-approvals.json`0600中。
- 对等检查:仅同 UID。
- 挑战/响应nonce + HMAC(token, request-hash) 防止重放。
- 短 TTL例如 10s+ 最大负载 + 速率限制。
### 询问流程macOS 应用 exec 主机)
1. 节点服务从 Gateway 网关接收 `system.run`
2. 节点服务连接到本地 socket 并发送提示/exec 请求。
3. 应用验证对等 + token + HMAC + TTL然后在需要时显示对话框。
4. 应用在 UI 上下文中执行命令并返回输出。
5. 节点服务将输出返回给 Gateway 网关。
如果 UI 缺失:
- 应用 `askFallback``deny|allowlist|full`)。
### 图示SCI
```
Agent -> Gateway -> Bridge -> Node Service (TS)
| IPC (UDS + token + HMAC + TTL)
v
Mac App (UI + TCC + system.run)
```
## 节点身份 + 绑定
- 使用 Bridge 配对中的现有 `nodeId`
- 绑定模型:
- `tools.exec.node` 将智能体限制为特定节点。
- 如果未设置,智能体可以选择任何节点(策略仍强制执行默认值)。
- 节点选择解析:
- `nodeId` 精确匹配
- `displayName`(规范化)
- `remoteIp`
- `nodeId` 前缀(>= 6 字符)
## 事件
### 谁看到事件
- 系统事件是**每会话**的,在下一个提示时显示给智能体。
- 存储在 Gateway 网关内存队列中(`enqueueSystemEvent`)。
### 事件文本
- `Exec started (node=<id>, id=<runId>)`
- `Exec finished (node=<id>, id=<runId>, code=<code>)` + 可选输出尾部
- `Exec denied (node=<id>, id=<runId>, <reason>)`
### 传输
选项 A推荐
- 运行器发送 Bridge `event``exec.started` / `exec.finished`
- Gateway 网关 `handleBridgeEvent` 将这些映射到 `enqueueSystemEvent`
选项 B
- Gateway 网关 `exec` 工具直接处理生命周期(仅同步)。
## Exec 流程
### 沙箱主机
- 现有 `exec` 行为Docker 或无沙箱时的主机)。
- 仅在非沙箱模式下支持 PTY。
### Gateway 网关主机
- Gateway 网关进程在其自己的机器上执行。
- 强制执行本地 `exec-approvals.json`(安全/询问/允许列表)。
### 节点主机
- Gateway 网关调用 `node.invoke` 配合 `system.run`
- 运行器强制执行本地批准。
- 运行器返回聚合的 stdout/stderr。
- 可选的 Bridge 事件用于开始/完成/拒绝。
## 输出上限
- 组合 stdout+stderr 上限为 **200k**;为事件保留**尾部 20k**。
- 使用清晰的后缀截断(例如 `"… (truncated)"`)。
## 斜杠命令
- `/exec host=<sandbox|gateway|node> security=<deny|allowlist|full> ask=<off|on-miss|always> node=<id>`
- 每智能体、每会话覆盖;除非通过配置保存,否则非持久。
- `/elevated on|off|ask|full` 仍然是 `host=gateway security=full` 的快捷方式(`full` 跳过批准)。
## 跨平台方案
- 运行器服务是可移植的执行目标。
- UI 是可选的;如果缺失,应用 `askFallback`
- Windows/Linux 支持相同的批准 JSON + socket 协议。
## 实现阶段
### 阶段 1配置 + exec 路由
-`exec.host``exec.security``exec.ask``exec.node` 添加配置 schema。
- 更新工具管道以遵守 `exec.host`
- 添加 `/exec` 斜杠命令并保留 `/elevated` 别名。
### 阶段 2批准存储 + Gateway 网关强制执行
- 实现 `exec-approvals.json` 读取器/写入器。
-`gateway` 主机强制执行允许列表 + 询问模式。
- 添加输出上限。
### 阶段 3节点运行器强制执行
- 更新节点运行器以强制执行允许列表 + 询问。
- 添加 Unix socket 提示桥接到 macOS 应用 UI。
- 连接 `askFallback`
### 阶段 4事件
- 为 exec 生命周期添加节点 → Gateway 网关 Bridge 事件。
- 映射到 `enqueueSystemEvent` 用于智能体提示。
### 阶段 5UI 完善
- Mac 应用:允许列表编辑器、每智能体切换器、询问策略 UI。
- 节点绑定控制(可选)。
## 测试计划
- 单元测试允许列表匹配glob + 不区分大小写)。
- 单元测试:策略解析优先级(工具参数 → 智能体覆盖 → 全局)。
- 集成测试:节点运行器拒绝/允许/询问流程。
- Bridge 事件测试:节点事件 → 系统事件路由。
## 开放风险
- UI 不可用:确保遵守 `askFallback`
- 长时间运行的命令:依赖超时 + 输出上限。
- 多节点歧义:除非有节点绑定或显式节点参数,否则报错。
## 相关文档
- [Exec 工具](/tools/exec)
- [执行批准](/tools/exec-approvals)
- [节点](/nodes)
- [提升模式](/tools/elevated)

View File

@@ -0,0 +1,92 @@
---
description: Track outbound session mirroring refactor notes, decisions, tests, and open items.
title: 出站会话镜像重构Issue
x-i18n:
generated_at: "2026-02-03T07:53:51Z"
model: claude-opus-4-5
provider: pi
source_hash: b88a72f36f7b6d8a71fde9d014c0a87e9a8b8b0d449b67119cf3b6f414fa2b81
source_path: refactor/outbound-session-mirroring.md
workflow: 15
---
# 出站会话镜像重构Issue #1520
## 状态
- 进行中。
- 核心 + 插件渠道路由已更新以支持出站镜像。
- Gateway 网关发送现在在省略 sessionKey 时派生目标会话。
## 背景
出站发送被镜像到*当前*智能体会话(工具会话键)而不是目标渠道会话。入站路由使用渠道/对等方会话键,因此出站响应落在错误的会话中,首次联系的目标通常缺少会话条目。
## 目标
- 将出站消息镜像到目标渠道会话键。
- 在缺失时为出站创建会话条目。
- 保持线程/话题作用域与入站会话键对齐。
- 涵盖核心渠道加内置扩展。
## 实现摘要
- 新的出站会话路由辅助器:
- `src/infra/outbound/outbound-session.ts`
- `resolveOutboundSessionRoute` 使用 `buildAgentSessionKey`dmScope + identityLinks构建目标 sessionKey。
- `ensureOutboundSessionEntry` 通过 `recordSessionMetaFromInbound` 写入最小的 `MsgContext`
- `runMessageAction`(发送)派生目标 sessionKey 并将其传递给 `executeSendAction` 进行镜像。
- `message-tool` 不再直接镜像;它只从当前会话键解析 agentId。
- 插件发送路径使用派生的 sessionKey 通过 `appendAssistantMessageToSessionTranscript` 进行镜像。
- Gateway 网关发送在未提供时派生目标会话键(默认智能体),并确保会话条目。
## 线程/话题处理
- SlackreplyTo/threadId -> `resolveThreadSessionKeys`(后缀)。
- DiscordthreadId/replyTo -> `resolveThreadSessionKeys``useSuffix=false` 以匹配入站(线程频道 id 已经作用域会话)。
- Telegram话题 ID 通过 `buildTelegramGroupPeerId` 映射到 `chatId:topic:<id>`
## 涵盖的扩展
- Matrix、MS Teams、Mattermost、BlueBubbles、Nextcloud Talk、Zalo、Zalo Personal、Nostr、Tlon。
- 注意:
- Mattermost 目标现在为私信会话键路由去除 `@`
- Zalo Personal 对 1:1 目标使用私信对等方类型(仅当存在 `group:` 时才使用群组)。
- BlueBubbles 群组目标去除 `chat_*` 前缀以匹配入站会话键。
- Slack 自动线程镜像不区分大小写地匹配频道 id。
- Gateway 网关发送在镜像前将提供的会话键转换为小写。
## 决策
- **Gateway 网关发送会话派生**:如果提供了 `sessionKey`,则使用它。如果省略,从目标 + 默认智能体派生 sessionKey 并镜像到那里。
- **会话条目创建**:始终使用 `recordSessionMetaFromInbound``Provider/From/To/ChatType/AccountId/Originating*` 与入站格式对齐。
- **目标规范化**:出站路由在可用时使用解析后的目标(`resolveChannelTarget` 之后)。
- **会话键大小写**:在写入和迁移期间将会话键规范化为小写。
## 添加/更新的测试
- `src/infra/outbound/outbound-session.test.ts`
- Slack 线程会话键。
- Telegram 话题会话键。
- dmScope identityLinks 与 Discord。
- `src/agents/tools/message-tool.test.ts`
- 从会话键派生 agentId不传递 sessionKey
- `src/gateway/server-methods/send.test.ts`
- 在省略时派生会话键并创建会话条目。
## 待处理项目 / 后续跟进
- 语音通话插件使用自定义的 `voice:<phone>` 会话键。出站映射在这里没有标准化;如果 message-tool 应该支持语音通话发送,请添加显式映射。
- 确认是否有任何外部插件使用内置集之外的非标准 `From/To` 格式。
## 涉及的文件
- `src/infra/outbound/outbound-session.ts`
- `src/infra/outbound/outbound-send-service.ts`
- `src/infra/outbound/message-action-runner.ts`
- `src/agents/tools/message-tool.ts`
- `src/gateway/server-methods/send.ts`
- 测试:
- `src/infra/outbound/outbound-session.test.ts`
- `src/agents/tools/message-tool.test.ts`
- `src/gateway/server-methods/send.test.ts`

View File

@@ -0,0 +1,221 @@
---
read_when:
- 定义或重构插件架构
- 将渠道连接器迁移到插件 SDK/运行时
summary: 计划:为所有消息连接器提供一套统一的插件 SDK + 运行时
title: 插件 SDK 重构
x-i18n:
generated_at: "2026-02-01T21:36:45Z"
model: claude-opus-4-5
provider: pi
source_hash: d1964e2e47a19ee1d42ddaaa9cf1293c80bb0be463b049dc8468962f35bb6cb0
source_path: refactor/plugin-sdk.md
workflow: 15
---
# 插件 SDK + 运行时重构计划
目标:每个消息连接器都是一个插件(内置或外部),使用统一稳定的 API。
插件不直接从 `src/**` 导入任何内容。所有依赖项均通过 SDK 或运行时获取。
## 为什么现在做
- 当前连接器混用多种模式:直接导入核心模块、仅 dist 的桥接方式以及自定义辅助函数。
- 这使得升级变得脆弱,并阻碍了干净的外部插件接口。
## 目标架构(两层)
### 1插件 SDK编译时稳定可发布
范围:类型、辅助函数和配置工具。无运行时状态,无副作用。
内容(示例):
- 类型:`ChannelPlugin`、适配器、`ChannelMeta``ChannelCapabilities``ChannelDirectoryEntry`
- 配置辅助函数:`buildChannelConfigSchema``setAccountEnabledInConfigSection``deleteAccountFromConfigSection`
`applyAccountNameToChannelSection`
- 配对辅助函数:`PAIRING_APPROVED_MESSAGE``formatPairingApproveHint`
- 新手引导辅助函数:`promptChannelAccessConfig``addWildcardAllowFrom`、新手引导类型。
- 工具参数辅助函数:`createActionGate``readStringParam``readNumberParam``readReactionParams``jsonResult`
- 文档链接辅助函数:`formatDocsLink`
交付方式:
-`openclaw/plugin-sdk` 发布(或从核心以 `openclaw/plugin-sdk` 导出)。
- 使用语义化版本控制,提供明确的稳定性保证。
### 2插件运行时执行层注入式
范围:所有涉及核心运行时行为的内容。
通过 `OpenClawPluginApi.runtime` 访问,确保插件永远不会导入 `src/**`
建议的接口(最小但完整):
```ts
export type PluginRuntime = {
channel: {
text: {
chunkMarkdownText(text: string, limit: number): string[];
resolveTextChunkLimit(cfg: OpenClawConfig, channel: string, accountId?: string): number;
hasControlCommand(text: string, cfg: OpenClawConfig): boolean;
};
reply: {
dispatchReplyWithBufferedBlockDispatcher(params: {
ctx: unknown;
cfg: unknown;
dispatcherOptions: {
deliver: (payload: {
text?: string;
mediaUrls?: string[];
mediaUrl?: string;
}) => void | Promise<void>;
onError?: (err: unknown, info: { kind: string }) => void;
};
}): Promise<void>;
createReplyDispatcherWithTyping?: unknown; // adapter for Teams-style flows
};
routing: {
resolveAgentRoute(params: {
cfg: unknown;
channel: string;
accountId: string;
peer: { kind: RoutePeerKind; id: string };
}): { sessionKey: string; accountId: string };
};
pairing: {
buildPairingReply(params: { channel: string; idLine: string; code: string }): string;
readAllowFromStore(channel: string): Promise<string[]>;
upsertPairingRequest(params: {
channel: string;
id: string;
meta?: { name?: string };
}): Promise<{ code: string; created: boolean }>;
};
media: {
fetchRemoteMedia(params: { url: string }): Promise<{ buffer: Buffer; contentType?: string }>;
saveMediaBuffer(
buffer: Uint8Array,
contentType: string | undefined,
direction: "inbound" | "outbound",
maxBytes: number,
): Promise<{ path: string; contentType?: string }>;
};
mentions: {
buildMentionRegexes(cfg: OpenClawConfig, agentId?: string): RegExp[];
matchesMentionPatterns(text: string, regexes: RegExp[]): boolean;
};
groups: {
resolveGroupPolicy(
cfg: OpenClawConfig,
channel: string,
accountId: string,
groupId: string,
): {
allowlistEnabled: boolean;
allowed: boolean;
groupConfig?: unknown;
defaultConfig?: unknown;
};
resolveRequireMention(
cfg: OpenClawConfig,
channel: string,
accountId: string,
groupId: string,
override?: boolean,
): boolean;
};
debounce: {
createInboundDebouncer<T>(opts: {
debounceMs: number;
buildKey: (v: T) => string | null;
shouldDebounce: (v: T) => boolean;
onFlush: (entries: T[]) => Promise<void>;
onError?: (err: unknown) => void;
}): { push: (v: T) => void; flush: () => Promise<void> };
resolveInboundDebounceMs(cfg: OpenClawConfig, channel: string): number;
};
commands: {
resolveCommandAuthorizedFromAuthorizers(params: {
useAccessGroups: boolean;
authorizers: Array<{ configured: boolean; allowed: boolean }>;
}): boolean;
};
};
logging: {
shouldLogVerbose(): boolean;
getChildLogger(name: string): PluginLogger;
};
state: {
resolveStateDir(cfg: OpenClawConfig): string;
};
};
```
备注:
- 运行时是访问核心行为的唯一方式。
- SDK 故意保持小巧和稳定。
- 每个运行时方法都映射到现有的核心实现(无重复代码)。
## 迁移计划(分阶段,安全)
### 阶段 0基础搭建
- 引入 `openclaw/plugin-sdk`
-`OpenClawPluginApi` 中添加带有上述接口的 `api.runtime`
- 在过渡期内保留现有导入方式(添加弃用警告)。
### 阶段 1桥接清理低风险
-`api.runtime` 替换每个扩展中的 `core-bridge.ts`
- 优先迁移 BlueBubbles、Zalo、Zalo Personal已经接近完成
- 移除重复的桥接代码。
### 阶段 2轻度直接导入的插件
- 将 Matrix 迁移到 SDK + 运行时。
- 验证新手引导、目录、群组提及逻辑。
### 阶段 3重度直接导入的插件
- 迁移 Microsoft Teams使用运行时辅助函数最多的插件
- 确保回复/正在输入的语义与当前行为一致。
### 阶段 4iMessage 插件化
- 将 iMessage 移入 `extensions/imessage`
-`api.runtime` 替换直接的核心调用。
- 保持配置键、CLI 行为和文档不变。
### 阶段 5强制执行
- 添加 lint 规则 / CI 检查:禁止 `extensions/**``src/**` 导入。
- 添加插件 SDK/版本兼容性检查(运行时 + SDK 语义化版本)。
## 兼容性与版本控制
- SDK语义化版本控制已发布变更有文档记录。
- 运行时:按核心版本进行版本控制。添加 `api.runtime.version`
- 插件声明所需的运行时版本范围(例如 `openclawRuntime: ">=2026.2.0"`)。
## 测试策略
- 适配器级单元测试(使用真实核心实现验证运行时函数)。
- 每个插件的黄金测试:确保行为无偏差(路由、配对、允许列表、提及过滤)。
- CI 中使用单个端到端插件示例(安装 + 运行 + 冒烟测试)。
## 待解决问题
- SDK 类型托管在哪里:独立包还是核心导出?
- 运行时类型分发:在 SDK 中(仅类型)还是在核心中?
- 如何为内置插件与外部插件暴露文档链接?
- 过渡期间是否允许仓库内插件有限地直接导入核心模块?
## 成功标准
- 所有渠道连接器都是使用 SDK + 运行时的插件。
- `extensions/**` 不再从 `src/**` 导入。
- 新连接器模板仅依赖 SDK + 运行时。
- 外部插件可以在无需访问核心源码的情况下进行开发和更新。
相关文档:[插件](/tools/plugin)、[渠道](/channels/index)、[配置](/gateway/configuration)。

View File

@@ -0,0 +1,100 @@
---
read_when:
- 设计或实现配置验证行为
- 处理配置迁移或 doctor 工作流
- 处理插件配置 schema 或插件加载门控
summary: 严格配置验证 + 仅通过 doctor 进行迁移
title: 严格配置验证
x-i18n:
generated_at: "2026-02-03T10:08:51Z"
model: claude-opus-4-5
provider: pi
source_hash: 5bc7174a67d2234e763f21330d8fe3afebc23b2e5c728a04abcc648b453a91cc
source_path: refactor/strict-config.md
workflow: 15
---
# 严格配置验证(仅通过 doctor 进行迁移)
## 目标
- **在所有地方拒绝未知配置键**(根级 + 嵌套)。
- **拒绝没有 schema 的插件配置**;不加载该插件。
- **移除加载时的旧版自动迁移**;迁移仅通过 doctor 运行。
- **启动时自动运行 doctordry-run**;如果无效,阻止非诊断命令。
## 非目标
- 加载时的向后兼容性(旧版键不会自动迁移)。
- 静默丢弃无法识别的键。
## 严格验证规则
- 配置必须在每个层级精确匹配 schema。
- 未知键是验证错误(根级或嵌套都不允许透传)。
- `plugins.entries.<id>.config` 必须由插件的 schema 验证。
- 如果插件缺少 schema**拒绝插件加载**并显示清晰的错误。
- 未知的 `channels.<id>` 键是错误,除非插件清单声明了该渠道 id。
- 所有插件都需要插件清单(`openclaw.plugin.json`)。
## 插件 schema 强制执行
- 每个插件为其配置提供严格的 JSON Schema内联在清单中
- 插件加载流程:
1. 解析插件清单 + schema`openclaw.plugin.json`)。
2. 根据 schema 验证配置。
3. 如果缺少 schema 或配置无效:阻止插件加载,记录错误。
- 错误消息包括:
- 插件 id
- 原因(缺少 schema / 配置无效)
- 验证失败的路径
- 禁用的插件保留其配置,但 Doctor + 日志会显示警告。
## Doctor 流程
- 每次加载配置时都会运行 Doctor默认 dry-run
- 如果配置无效:
- 打印摘要 + 可操作的错误。
- 指示:`openclaw doctor --fix`
- `openclaw doctor --fix`
- 应用迁移。
- 移除未知键。
- 写入更新后的配置。
## 命令门控(当配置无效时)
允许的命令(仅诊断):
- `openclaw doctor`
- `openclaw logs`
- `openclaw health`
- `openclaw help`
- `openclaw status`
- `openclaw gateway status`
其他所有命令必须硬失败并显示:"Config invalid. Run `openclaw doctor --fix`."
## 错误用户体验格式
- 单个摘要标题。
- 分组部分:
- 未知键(完整路径)
- 旧版键/需要迁移
- 插件加载失败(插件 id + 原因 + 路径)
## 实现接触点
- `src/config/zod-schema.ts`:移除根级透传;所有地方使用严格对象。
- `src/config/zod-schema.providers.ts`:确保严格的渠道 schema。
- `src/config/validation.ts`:未知键时失败;不应用旧版迁移。
- `src/config/io.ts`:移除旧版自动迁移;始终运行 doctor dry-run。
- `src/config/legacy*.ts`:将用法移至仅 doctor。
- `src/plugins/*`:添加 schema 注册表 + 门控。
- `src/cli` 中的 CLI 命令门控。
## 测试
- 未知键拒绝(根级 + 嵌套)。
- 插件缺少 schema → 插件加载被阻止并显示清晰错误。
- 无效配置 → Gateway 网关启动被阻止,诊断命令除外。
- Doctor dry-run 自动运行;`doctor --fix` 写入修正后的配置。