# RFC-020：IM 平台兼容层（接入飞书 / WhatsApp / 企业微信 / Slack）

| 字段 | 内容 |
|---|---|
| 状态 | **Final（v3.1）** —— 通信牛 APPROVE WITH NITS + 通信IM牛 APPROVE；§12 决策已由主笔自决（per Vincent telegram 5947 delegate + 通信龙 ack），可进入 P0 实施 |
| 提出 | 2026-05-22 |
| 作者 | 通信IM马（RFC 主笔）· 通信IM牛（四平台 API 深度调研 co-research + review） |
| 派单 | 通信龙（Vincent 追加 scope：飞书优先 / 方案先 review 不跳步） |
| 关联 issue | [#179](https://github.com/sleep2agi/agent-network/issues/179) IM 兼容层（本 RFC 跟踪 issue）· [#162](https://github.com/sleep2agi/agent-network/issues/162) Dashboard IM workspace（互补） |
| 关联 RFC | RFC-002 节点接入 Telegram（**直接前身** —— 本 RFC 把其 bridge 抽象泛化到多 IM）· RFC-003 节点遥测层（Dashboard 状态）· RFC-010 节点生命周期（bridge 进程监督）· RFC-001 双 Token 体系（bridge 身份）· RFC-017 Dashboard 组织架构视图 |
| 目标版本 | 待 Vincent 拍板后定（Phase 1 飞书 MVP 建议下个正式版本） |

---

## 0. 摘要

让 anet agent 能原生接入飞书 / WhatsApp / 企业微信 / Slack 等 IM 平台 —— IM 用户能直接跟 agent 对话、agent 也能往 IM 主动推送。

当前 anet 的人机交互只有 **Telegram** 一条原生通道（RFC-002），飞书 / 微信现有实现是**社区外部 MCP channel 插件**（`claude-code-feishu-channel` 等），既不进 commhub、也不 anet-aware（配置落在 `~/.claude/channels/` 而非 `.anet/nodes/<node>/channels/`，单会话、无 commhub 任务生命周期映射）。

本 RFC 给出三件事：

1. **统一 IM Adapter 抽象层** —— 一套与平台无关的 `IMAdapter` 接口 + 入站/出站归一化数据模型，新增一个 IM 平台 = 写一个 adapter，不动核心。
2. **IM Bridge = commhub-gateway** —— 关键架构决策：IM 消息归一化后以 **commhub task** 形式派发给绑定 agent，复用 commhub 既有的 task/reply 投递语义。因此对 `claude-code-cli` / `claude-agent-sdk` / `codex-sdk` 三种 runtime 的 **agent 侧全部免改**，无需为任何 runtime 单独写 channel plugin。代价是 commhub **协议侧**有一组 P0 必需增量（task/inbox 加 `meta_json`、`send_task` 透传 `meta`、SSE/Dashboard 透传）—— 见 §2.9，落地前必须先做，不是"零改动"。
3. **分期落地** —— Phase 1 = **飞书 MVP**（WebSocket 长连接、零公网门槛），Slack 紧随 Phase 2，WhatsApp / 企微后置。架构层保持通用，飞书只是首个 adapter 实现，不为飞书写死。

本 RFC 是**纯设计文档**，不含实施动作。§12 决策项待 Vincent 拍板。

---

## 1. 背景与动机

### 1.1 现状

anet 的人机入口现状（截至 2026-05-22）：

| 通道 | 状态 | 接入路径 |
|---|---|---|
| Telegram | ✅ 原生（RFC-002 P0 已 ship） | `anet channel add telegram` → `.anet/nodes/<node>/channels/telegram/{.env,access.json}`；token 本地 chmod 600；`allowFrom` 白名单；不热加载 |
| 飞书 / 微信 | ⚠️ 仅社区外部插件 | `claude-code-feishu-channel` / `claude-code-wechat-channel` —— 走 Claude Code 的 MCP Channel 协议，配置在 `~/.claude/channels/`，**不进 commhub、不 anet-aware、单会话** |
| WhatsApp / 企微 / Slack | ❌ 无 | —— |

> ⚠️ **澄清**：commhub **没有**原生支持飞书 / 微信。docs-site 明确说明飞书 / 微信是外部插件方案。本 RFC 的工作正是把 IM 接入纳入 anet 的**原生 channel 主路径**。

RFC-002 的核心经验（本 RFC 直接继承）：

- `claude-code-cli` runtime 可加载官方 Channel plugin（如 `plugin:telegram@claude-plugins-official`），由 `claude` 进程自带的 plugin 协议把外部事件 push 进会话。
- `claude-agent-sdk` / `codex-sdk` 走编程式 SDK 调用，**没有** plugin/channels hook —— 外部事件必须由 **agent-node 包装层**的 bridge worker 自己做 polling/webhook/socket，再调 `think()`。
- 结论：新 IM adapter **应沿用 bridge 抽象，不绑定 Claude Code channel plugin**。本 RFC 把这一点推到极致（见 §2.1）。

### 1.2 价值

- **覆盖主流办公 IM** —— 飞书 / 企微覆盖国内团队，Slack 覆盖国际团队，WhatsApp 覆盖 C 端触达。anet agent 从"终端里的 agent"变成"IM 里随时能找到的同事"。
- **双向** —— IM 用户发消息给 agent（入站）；agent 把进度 / 结果 / 告警推回 IM（出站）。
- **可扩展** —— 统一 adapter 抽象让新增平台成本可控、可插拔。
- **可视化** —— IM 来源消息进入 commhub 任务流，自然出现在 Dashboard 拓扑 / Chat（呼应 #162）。

### 1.3 非目标

- ❌ **不做官方托管 IM 网关** —— 符合产品方向（纯 local + 无官方托管）。所有 IM 凭证、连接均 user 自持、自部署。
- ❌ **不把 IM token 上传 commhub hub** —— hub 保持 channel-agnostic（延续 RFC-002 §7"hub 不管 channel"）。
- ❌ **不做 IM 平台的全功能客户端** —— 只覆盖 agent 协作必需的消息能力（文本 / 图片 / 文件 / @提及 / 线程），不做日历 / 审批 / 音视频。
- ❌ **不在本 RFC 锁定 webhook-mode 平台的公网入口最终方案** —— WhatsApp / 企微回调需要公网 HTTPS，这是 Phase 3+ 的独立设计题（§5.3 给出选项，§12 决策项③ 留给后续 RFC）。

---

## 2. 架构设计 —— 统一 IM Adapter 抽象层

### 2.1 整体分层

核心架构决策：**IM Bridge 做成 commhub-gateway，不是 per-runtime channel。**

```
┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
│  飞书 / Lark     │   │  Slack          │   │  WhatsApp Cloud │   │  企业微信 WeCom  │
└────────┬────────┘   └────────┬────────┘   └────────┬────────┘   └────────┬────────┘
         │ WebSocket           │ Socket Mode         │ Webhook             │ Webhook(回调)
         ▼                     ▼                     ▼                     ▼
┌──────────────────────────────────────────────────────────────────────────────────┐
│                        IM Adapter 层（per-platform）                               │
│  FeishuAdapter   SlackAdapter   WhatsAppAdapter   WeComAdapter   …(可插拔)         │
│  职责：平台 SDK 收发 / 鉴权 / 签名校验 / 事件订阅 → 归一化                            │
└──────────────────────────────────────┬───────────────────────────────────────────┘
                                        │  NormalizedIMEvent ▲ / NormalizedIMMessage ▼
┌──────────────────────────────────────▼───────────────────────────────────────────┐
│                        IM Bridge（commhub-gateway）                                │
│  • 以 ntok_ 作为 commhub 客户端身份接入网络                                          │
│  • 入站：NormalizedIMEvent → commhub task（派给绑定 agent）                          │
│  • 出站：监听该 agent 的 task reply → adapter.send() 回 IM                           │
│  • 幂等 / access 白名单 / 会话↔task 映射 / 限流 / 重试 / dead-letter                 │
└──────────────────────────────────────┬───────────────────────────────────────────┘
                                        │  commhub task / message / reply（既有协议）
┌──────────────────────────────────────▼───────────────────────────────────────────┐
│                        commhub 投递层（既有；协议侧 P0 增量见 §2.9）                                │
│  claude-code-cli ← commhub-channel MCP server                                       │
│  claude-agent-sdk / codex-sdk ← commhub client（agent-node 内）                      │
└────────────────────────────────────────────────────────────────────────────────────┘
```

**为什么走 commhub-gateway 而不是 per-runtime channel：**

| 维度 | per-runtime channel（RFC-002 Telegram 模型） | commhub-gateway（本 RFC） |
|---|---|---|
| claude-code-cli | 需要一个 IM MCP channel server 注入 `claude` 进程 | 复用 `commhub-channel` MCP server（已有） |
| claude-agent-sdk / codex-sdk | 需要 agent-node bridge worker 调 `think()` | 复用 commhub client（已有） |
| 新增一个 IM 平台 | 每 runtime ×每平台 都要适配 | 只写一个 adapter，三 runtime 白拿 |
| Dashboard 可见性 | IM 消息不在 commhub，需额外打通 | IM 消息天然是 commhub task，拓扑/Chat 直接显示 |
| agent 主动推 IM | 各 runtime 各自实现 | agent 发 commhub message → bridge 转出 |

Telegram 当初保留 plugin 路径，是因为 Anthropic 有**官方** Telegram channel plugin。飞书 / WhatsApp / Slack / 企微 **没有官方 channel plugin**，社区插件又不 anet-aware。因此本 RFC 不为任何 runtime 单独做 IM channel plugin —— IM 消息一律先归一化成 commhub task，借既有投递层送达，runtime 无关性是免费的。

> **IM Bridge 是什么**：一个 commhub 客户端进程，一端连 IM 平台、一端连 commhub 网络，做双向翻译。它不含任何 LLM 逻辑。
>
> **Bridge 是独立的 commhub 身份** —— 以**专属 alias + 专属 `ntok_`**注册，**不复用、不冒充**目标 agent 的身份。建议 gateway alias = `<bound-agent>-im-<connectionName>`（连接级唯一），ntok_ 的 token name 随之为 `node:<该 alias>`（贴合 commhub 现有 caller-alias 派生规则，见 §2.9）；task `from_session` 即该 gateway alias，派单 `target` 仍是 agent 原 alias。审计链路因此始终清晰：`IM 用户 → IM Bridge(gateway) → 绑定 agent`，每一跳可追溯。
>
> Bridge 可由 agent-node 在节点启动时拉起（socket-mode 平台，agent-local），也可独立部署（webhook-mode 平台，见 §5.3）。

### 2.2 `IMAdapter` 接口定义

每个平台实现一个 adapter，对 Bridge 暴露统一接口。adapter 只负责"平台 SDK ↔ 归一化数据"，不碰 commhub。

```typescript
/** 接入模式 —— 决定 adapter 能否 agent-local 运行 */
type IMIngressMode =
  | "socket"   // 长连接 / WebSocket（飞书 WSClient、Slack Socket Mode）—— 无需公网 IP
  | "webhook"  // HTTP 回调（WhatsApp Cloud API、企微回调）—— 需公网 HTTPS 入口
  | "polling"; // 主动轮询 —— 仅开发 / 兜底，生产不推荐

interface IMAdapter {
  /** 平台标识："feishu" | "slack" | "whatsapp" | "wecom" */
  readonly platform: string;
  /** 该 adapter 支持/使用的接入模式 */
  readonly ingressMode: IMIngressMode;

  /** 用凭证初始化平台 SDK 客户端（不建立连接） */
  init(config: IMChannelConfig): Promise<void>;

  /** 开始接收：socket 模式建立长连接；webhook 模式注册路由 + 校验器 */
  start(onEvent: (e: NormalizedIMEvent) => Promise<void>): Promise<void>;

  /** 停止接收、释放连接 */
  stop(): Promise<void>;

  /** 出站：把归一化消息发到目标会话 */
  send(msg: NormalizedIMMessage): Promise<{ messageId: string }>;

  /** 可选：编辑已发消息（飞书/Slack 支持；用于"处理中"占位转正式回复） */
  edit?(target: IMConversationRef, messageId: string, msg: NormalizedIMMessage): Promise<void>;

  /** webhook 模式必需：校验入站请求签名 / 解密 payload。socket 模式可省 */
  verifyWebhook?(headers: Record<string, string>, rawBody: Buffer): boolean;

  /** 健康探针 —— 供 Dashboard 显示连接状态 */
  health(): IMAdapterHealth;
}

interface IMAdapterHealth {
  connected: boolean;
  lastEventAt: number | null;
  lastError: string | null;
  rateLimitRemaining?: number;
}
```

### 2.3 入站归一化事件 `NormalizedIMEvent`

所有平台的入站消息统一归一化成同一结构（co-research：通信IM牛）。Bridge 只认这一个结构，与平台彻底解耦。

```typescript
interface NormalizedIMEvent {
  platform: string;             // "feishu" | "slack" | "whatsapp" | "wecom"
  connectionId: string;         // 该 channel 绑定标识（= node + platform）
  tenantId?: string;            // 飞书 tenant / Slack team / 企微 corp / WhatsApp WABA id

  conversation: {
    id: string;                 // 会话 id（飞书 chat_id / Slack channel / WhatsApp wa_id）
    type: "dm" | "group" | "channel" | "thread";
  };
  threadRootId?: string;        // 线程根消息 id（Slack thread_ts / 飞书 root_id）

  sender: { id: string; name?: string };
  messageId: string;            // 平台消息 id —— 同时作幂等键的核心
  mentioned: boolean;           // 本 bot 是否被 @ 提及（群聊触发判定用）

  content: {
    text?: string;
    images?: string[];          // 已下载到本地的路径
    files?: { name: string; path?: string; url?: string }[];
  };

  raw?: unknown;                // 原始 payload —— 默认不持久化全量（见下方注）
  receivedAt: number;
  idempotencyKey: string;       // = `${platform}:${connectionId}:${messageId}`
}
```

> **`raw` 持久化策略**：IM 原始 payload 常含 PII（用户 ID / 手机号 / 文件 URL / 头像 URL）。默认**只在内存中临时持有用于解析**，不落盘、不进 commhub `meta_json`。如需审计，由 `config.auditRaw` 显式开启，且必须脱敏（手机号 / token / URL 打码）后写**本地** audit log，永不上传 hub。

### 2.4 出站归一化消息 `NormalizedIMMessage`

```typescript
interface IMConversationRef {
  platform: string;
  conversationId: string;
  conversationType: "dm" | "group" | "channel" | "thread";
  threadRootId?: string;        // 在线程内回复
}

interface NormalizedIMMessage {
  target: IMConversationRef;
  text?: string;                // 纯文本（默认；超长自动分片，见 §4.2）
  markdown?: string;            // 富文本（平台支持时；飞书 post / Slack mrkdwn）
  card?: unknown;               // 交互卡片（飞书 interactive / Slack Block Kit，后期）
  imagePath?: string;           // 本地图片路径
  files?: { name: string; path: string }[];
  replyToMessageId?: string;    // 回复指定消息
  ephemeral?: boolean;          // 仅发送者可见（仅 Slack 强支持，其余忽略）
  correlation: {                // 关联 commhub 生命周期，供 Dashboard / 审计串联
    taskId: string;
    inReplyTo?: string;
  };
}
```

### 2.5 IM Bridge worker —— 承接并泛化 RFC-002

RFC-002 §2.2 已设计过一个 `telegram-bridge` worker；本 RFC 把它泛化为**平台无关的 IM Bridge**。Telegram 在落地后亦可作为又一个 adapter 收编进同一抽象（不强制，见 §10）。

Bridge 工作流：

```
启动：
  1. 读 .anet/nodes/<node>/channels/<platform>/{config.json,.env,access.json}
  2. 实例化对应 adapter，adapter.init(config)
  3. 以 Bridge 专属 ntok_ 接入 commhub（独立 gateway 身份，from_session = gateway alias，见 §2.1）
  4. adapter.start(onEvent)

入站 onEvent(NormalizedIMEvent):
  5. webhook 校验（webhook 模式）：adapter.verifyWebhook() 不过 → 拒绝，绝不进 commhub
  6. 幂等检查：idempotencyKey 命中近期窗口 → 对平台返回成功(200)，但不重复建 task / 不重复派单
  7. access 校验：sender.id ∉ allowFrom 且 conversation.id ∉ allowChats → ignore + audit
  8. 群聊触发判定：conversation.type ∈ {group,channel} 且 !mentioned 且无 command 前缀
       → 按连接绑定 triggerPolicy（§2.8）决定 observe / ignore（群档默认 mention，见 §4.3）
  9. 映射成 commhub task → commhub_send_task(target=绑定 agent)；
     归一化元数据写入 task metadata（不塞进 content 纯文本，见 §4.1）
  10. 写 IMCorrelationStore：task_id ↔ {会话, threadRootId, messageId}（出站回包用，见 §4.4）

出站（Bridge 订阅自己派出的 task 的 reply / 绑定 agent 的 message）:
  11. 收到 reply → 用 task_id 查 IMCorrelationStore 还原 IMConversationRef → adapter.send() 回原会话/线程
  12. agent 主动推 IM：P1.5+ 能力，需明确协议（§4.2 / §12⑨ 拍板）—— P1 不做，不在此隐式扩展 send_message
```

进程监督沿用 RFC-010 节点生命周期：Bridge 由 agent-node 启动时拉起、崩溃指数退避重启（3s→60s，与 SSE 重连一致）。

### 2.6 三种接入模式

| 模式 | 平台 | 是否需公网 | 用途 |
|---|---|---|---|
| `socket` | 飞书（WebSocket）、Slack（Socket Mode） | ❌ 不需要 | **生产首选**（无公网门槛），Phase 1/2 主路径 |
| `webhook` | WhatsApp Cloud API、企微回调 | ✅ 需公网 HTTPS | 生产路径，需公网入口方案（§5.3） |
| `polling` | 兜底 | ❌ | 仅开发 / 调试，生产不推荐 |

飞书与 Slack 都提供长连接模式 → **Phase 1/2 完全 agent-local，零公网门槛**，与 RFC-002 Telegram polling 的"开发友好"思路一致。webhook-mode 平台的公网入口推迟到 Phase 3。

### 2.7 跨 runtime 一致性

因为 IM 消息一律先变成 commhub task，**三种 runtime 的 agent 侧对 IM 的支持零改动**：

| Runtime | IM 消息如何送达 agent | runtime / agent 侧新增代码 |
|---|---|---|
| `claude-code-cli` | commhub task → `commhub-channel` MCP server push 进 `claude` 进程 | 0 |
| `claude-agent-sdk` | commhub task → agent-node 内 commhub client → `think()` | 0 |
| `codex-sdk` | 同上 | 0 |

"零改动"**仅限 runtime / agent 侧**。新增代码集中在 adapter 层 + Bridge；此外 commhub **协议侧**有一组 P0 必需增量（task metadata 透传等），见 §2.9 —— 这是 commhub-gateway 模型的真实成本，不被"零改动"掩盖。

### 2.8 连接绑定模型（Connection Binding）

一条 IM「连接」是一份**显式绑定记录**，把一个平台连接绑到网络里的一个目标。Bridge 启动时读取它作为派单依据 —— 派单路径不靠猜：

```
IM Connection Binding
  platform        : feishu | slack | whatsapp | wecom
  connectionName  : 人类可读名（如 "feishu-research-team"）
  network         : 绑定的 anet network（ntok_ 作用域）
  target          : 目标 agent alias（私聊默认目标）/ 或目标 group
  triggerPolicy   : { dm: "always", group: "mention" }
                    // group 档即 §4.3 的 groupPolicy，可选 mention(默认) / command / all / observe
  allow           : { allowFrom: [...], allowChats: [...] }
```

绑定落在 `.anet/nodes/<node-id>/channels/<platform>/config.json`（见 §5.2）。**一个连接 = 一个 Bridge 实例**。同一平台应用可配多个连接（不同 `connectionName`）绑到不同 agent / 群。

### 2.9 commhub 协议与持久化增量（P0 必需）

> review 核对源码确认：commhub 当前 `tasks` 表（`server/src/db.ts`）只有 `content / result / in_reply_to / context(inbox) …`，**没有结构化 metadata 字段**；`send_task` MCP 工具（`server/src/tools.ts`）只有 `task / context / from_session / parent_task_id …`，**没有 `meta` 参数**。因此 commhub-gateway 模型**不是**对 commhub 零改动 —— 以下是 P0 落地前必须先做的增量：

| # | 增量 | 说明 |
|---|---|---|
| ① | `tasks.meta_json` + `inbox.meta_json` 新列 | 持久化 `meta.im`（platform / conversation / sender / thread / messageId）。**推荐新列**；MVP 兜底可暂塞进既有 `context` JSON，但 Dashboard / Bridge 回查会退化成 parse 文本 → 技术债（§12 决策项⑧）|
| ② | `send_task`（MCP）+ REST `/api/task`（及后续任务 API）加 `meta` 参数 | Bridge 派单时把归一化元数据透传进 ①，不污染 `content` |
| ③ | SSE / Dashboard 透传 `meta_json` | Dashboard 拿到 IM 来源字段（§6）；reply 链路把 `meta` 带回 |
| ④ | Bridge 侧 **持久化** correlation / idempotency store | channel 目录下轻量 sqlite / jsonl，见 §4.4。Bridge 重启后幂等与回包不丢 |

①②③ 属 commhub-server + dashboard 改动，④ 属 Bridge 自身。四项都在 **P0 抽象层**范围内，不能推迟 —— 否则 §4 出站回包、§6 Dashboard 无法实现。

---

## 3. 各平台接入方式

### 3.1 飞书 / Lark —— Phase 1 MVP

**接入模型**：飞书**开放平台「企业自建应用」+ 机器人能力**，事件订阅走 **WebSocket 长连接模式**。

> ⚠️ 飞书有两种"机器人"，本 RFC 用的是后者：
> - **自定义机器人**（群里加的 webhook 机器人）—— 偏单向通知，能力弱，**不用**。
> - **开放平台应用机器人 + 事件订阅** —— 能收能发、能进群、能 @、有完整 OpenAPI，**本 RFC 采用**。

| 项 | 内容 |
|---|---|
| 凭证 | App ID + App Secret（应用级）。API 调用用 `tenant_access_token`（由 SDK 自动用 App ID/Secret 换取并缓存） |
| 入站 | 事件订阅 `im.message.receive_v1`，WebSocket 长连接（`@larksuiteoapi/node-sdk` 的 `WSClient`）—— 无需公网；也支持 HTTP 事件回调（webhook），MVP 不用 |
| 出站 | OpenAPI `im.message.create`，`receive_id_type` = `open_id`（私聊）/ `chat_id`（群聊） |
| 编辑 | 支持消息编辑，**单条最多 20 次** —— "处理中"占位转正式回复要计次 |
| 群聊 | 机器人需在群内且有发言权限；群消息默认需 @机器人 才触发 |
| 图片/文件 | `im.image.create`（上传得 `image_key`）/ `im.messageResource.get`（下载，无加密） |
| 必需权限 | `im:message:send_as_bot`、`im:message`、`im:resource` |
| 限流 | 发送/编辑约 1000/min、50/s（以平台文档为准） |
| 多用户 | 原生多用户，每条消息带 `sender.open_id` |

> ⚠️ 上表权限 scope 名与限流数字（约 1000/min、50/s、编辑 ≤20 次/条）来自现有调研与社区实现，**实施前须对飞书开放平台最新官方文档逐项复核** —— 飞书 API 配额、权限名随版本调整。

**Prior art**：社区 `claude-code-feishu-channel`（`feishu-channel.ts`，已验证可用）覆盖了 WSClient 连接、`im.message.receive_v1` 事件解析、`im.message.create` 发送、图片上下行、p2p/group 回复路由。本 RFC 复用其 **Feishu SDK 调用层**，但重新挂到 `FeishuAdapter` + commhub-gateway 之下（替换其 MCP Channel 协议出口）。

### 3.2 Slack —— Phase 2

**接入模型**：Slack App + **Bolt 框架 + Events API**，入站推荐 **Socket Mode**（无需公网）。

| 项 | 内容 |
|---|---|
| 凭证 | Bot Token `xoxb-…`（OAuth scopes）+ App-Level Token `xapp-…`（Socket Mode）+ Signing Secret |
| 入站 | Events API。两种入口：HTTP Request URL（需公网，**3 秒内 ack**）或 **Socket Mode**（长连接，无公网，本 RFC 首选）|
| 出站 | `chat.postMessage`；线程回复用 `thread_ts` |
| 安全 | HTTP 模式必须用 Signing Secret 校验 `X-Slack-Signature`（v0 HMAC + timestamp 防重放）|
| 关键约束 | **3 秒 ack 规则** —— HTTP Events API 收到 event 须 3 秒内回 200；**Socket Mode 同理** —— envelope 也要先 ack 再处理。两种模式都是"先 ack/入队、LLM 异步处理"，绝不阻塞 ack（阻塞 → Slack 重试 → 重复事件，靠 §4.4 幂等兜底）|
| 群聊语义 | 最强：channel / DM / MPIM / private / shared channel / thread / @mention 全覆盖 |
| 限流 | Events API 约 30,000 events/app/workspace/60min；`chat.postMessage` 约 1 msg/sec/channel + workspace 级上限 |
| 可见性 | 支持 ephemeral 消息（仅发送者可见）|

**为什么 Slack 是 Phase 2**：Socket Mode 与飞书 WebSocket 同属 socket-mode → 复用 §2.6 的 agent-local 模式，无新增公网基建；group/thread/@ 语义最完整，能充分验证抽象层的群聊设计。

### 3.3 WhatsApp Business Cloud API —— Phase 3

**接入模型**：Meta App + WABA（WhatsApp Business Account）+ `phone_number_id`，入站**只有 Webhooks**。

| 项 | 内容 |
|---|---|
| 凭证 | Bearer access token + `phone_number_id` + WABA id；webhook 验证用 `verify_token` + App Secret |
| 入站 | **仅 Webhooks**（`messages` / `statuses` 事件）—— **无长连接、无轮询**，必须有公网 HTTPS 入口 |
| 出站 | Graph API `POST /{phone-number-id}/messages` |
| 安全 | `X-Hub-Signature-256`（HMAC-SHA256，App Secret）；接入时 `hub.challenge` 验证 |
| **会话模型** | **只有 1:1**（business ↔ 用户手机号 `wa_id`），**没有群聊语义** |
| **24h 客服窗口** | 用户最近一条消息起 24h 内可自由回复；窗口外只能发**预审模板消息**（template）|
| 合规门槛 | 需 business verification、模板审核、质量评级、messaging limits 分级 |

> ⚠️ **WhatsApp 不是群聊平台**。它适合做**通知 / 客服型** adapter（agent → 用户 1:1 触达），**不适合做多 agent 群聊协作 MVP**。24h 窗口 + 模板审核使其工程与合规成本最高 → 排 Phase 3。

### 3.4 企业微信 / WeCom —— Phase 4

**接入模型**：企微**自建应用**（不是群机器人 webhook）。

> ⚠️ 企微也有两条路线，本 RFC 用前者：
> - **自建应用** —— corpId/agentId/secret + 回调，能收发应用消息，**本 RFC 采用**。
> - **群机器人 webhook** —— 仅内部群单向推送，约 20 条/min/机器人，能力弱，不用。

| 项 | 内容 |
|---|---|
| 凭证 | `corpId` + `agentId` + 应用 `secret`（换 `access_token`）|
| 入站 | 回调模式：配置 `Token` + `EncodingAESKey` + 回调 URL；接入时 URL 验证，消息 **AES-CBC 加密**，需解密 |
| 出站 | `message/send` 应用消息 API |
| 安全 | 回调签名 `msg_signature`（SHA1）+ AES-CBC 加解密 |
| 会话 | 更稳的语义是「**成员→应用发消息** + **应用消息推送到成员/部门/标签**」；普通企业内部群聊的收发语义不如飞书/Slack 明确，**实施前须二次验证**；客户联系 / 外部客户群有强合规限制，后置 |

> ⚠️ 企微 MVP 聚焦**自建应用的成员会话 / 应用消息推送**；内部群聊收发能力**实施前二次验证**再定范围，客户联系 / 外部客户群涉合规边界、后置。回调模式需公网入口（同 WhatsApp，§5.3）。AES 加解密是额外工程量 → 排 Phase 4。

### 3.5 平台能力对照表

| 维度 | 飞书 | Slack | WhatsApp Cloud | 企微（自建应用）|
|---|---|---|---|---|
| 接入模式 | socket（WS）/ webhook | socket / webhook | **仅 webhook** | webhook（回调）|
| 需公网入口 | ❌ | ❌（Socket Mode）| ✅ | ✅ |
| 群聊语义 | ✅ 群 + @ | ✅ 最强（channel/thread/@）| ❌ 仅 1:1 | ⚠️ 成员会话为主；内部群待验证、非 P4 MVP |
| 线程 | root_id | thread_ts | —— | —— |
| 入站签名/加密 | 长连接免；回调需 Encrypt Key | Signing Secret | HMAC-SHA256 | AES-CBC + 签名 |
| 出站编辑 | ✅（≤20 次/条）| ✅ | ❌ | 有限 |
| 特殊约束 | 编辑次数上限 | 3 秒 ack | 24h 窗口 + 模板审核 | AES 加解密 + 合规 |
| 凭证 | App ID + Secret | xoxb + xapp + Signing Secret | access token + phone_id | corpId + agentId + secret |
| 本 RFC 阶段 | **Phase 1** | Phase 2 | Phase 3 | Phase 4 |

---

## 4. 消息映射 —— IM ↔ commhub 生命周期

### 4.1 入站映射

| IM 场景 | commhub 映射 |
|---|---|
| 私聊（dm）一条消息 | `commhub_send_task`(target = 绑定 agent)，建立 task 生命周期 |
| 群聊 / 频道，**@了 bot** 或 slash 前缀 | `commhub_send_task`(target = 被 @ 的 agent) |
| 群聊 / 频道，**未 @** | 按 `groupPolicy`：`ignore`（默认丢弃）/ `observe`（作为 message，不建 task）|
| 线程内回复 | task 带 `parent_task_id` / `in_reply_to`，绑到原线程的 task |
| webhook 重试（同 `messageId`）| 幂等键命中 → 丢弃，不重复建 task |

IM 用户在 commhub 内表示为 **virtual participant**（虚拟参与者）—— task `meta_json`（§2.9①）携带：

```jsonc
{
  "im": {
    "platform": "feishu",
    "connectionId": "node-xxx#feishu",
    "conversation": { "id": "oc_abc", "type": "group" },
    "threadRootId": "om_root",
    "sender": { "id": "ou_user", "name": "张三" },
    "messageId": "om_msg123"
  }
}
```

agent 收到的 task 文本里，群聊消息加 `[群聊消息]` 前缀（与现有飞书插件一致），让 agent 能区分语境。

> **结构化数据进 metadata，不进 content** —— `meta.im` 是出站回包、Dashboard 展示、审计的唯一可靠来源；`content` 只放给 agent 读的自然语言。task `from_session` = Bridge 的 gateway alias（`<agent>-im-<connectionName>`，§2.1），raw sender 在 `meta.im.sender` —— Bridge 不冒充 IM 用户、也不冒充目标 agent。
>
> **注意**：`meta.im` 落地依赖 §2.9① 的 `meta_json` 持久化列 —— commhub 当前 task schema 无此字段，是 P0 必须先补的增量。

### 4.2 出站映射

| 时机 | 动作 |
|---|---|
| Bridge 收到 task（建任务后）| 立即 `adapter.send()` 一条"⏳ 处理中…"占位（可选，`config.ackPlaceholder`）|
| agent 完成 → commhub reply（status=completed）| Bridge 定位 `IMConversationRef` → `adapter.send()` 正式回复（支持 `edit` 的平台把占位编辑成正式内容）|
| agent 主动推送（P1.5+）| 见下方「agent 主动推 IM」—— **P1 不做**，P1.5/P2 加明确协议 |
| 输出超长 | 按平台单条上限自动**分片**发送（飞书/Slack 有长度上限）|
| 含附件 | 图片：`adapter.send({imagePath})`；其它文件：先 metadata + 本地路径 / 临时 URL |
| 线程语境 | reply 带 `threadRootId` → 回到原线程，不污染主频道 |

**agent 主动推 IM（P1 不做任意主动推）**：现有 `commhub_send_message` **没有结构化 `meta` 参数**，agent 也未必知道 `conversationId` —— RFC **不假装现有工具够用**。分档：

- **P1**：只保证「IM 入站 task → agent reply → 回到 IM 原会话」。agent 对 IM 用户的回应一律走 reply 链路，出站关联表（§4.4）保证回到原 thread。
- **P1.5 / P2**：支持 agent **任意主动推** IM。需新增明确协议，二选一（§12 决策项⑨）：① 新 CLI / 工具 `anet im send --connection <name> --to <conv-id>`；② 给 Bridge gateway alias 发 message，content 用固定 JSON envelope（`{im:{connectionName,conversationId,…},text}`）由 Bridge 解析。**不在现有 `send_message` 上隐式扩展**。

### 4.3 群聊 / @提及 / 多 agent 语义

- **触发**：群聊 / 频道里**默认只有 @bot 或 slash 前缀**才触发 task（避免 agent 抢话、刷屏、烧 quota）。`groupPolicy` 可配 `mention`（默认）/ `all`（全部触发，慎用）/ `observe`（不触发但入 message 流）。
- **多 agent 同群**：一个 IM 群里可以有多个 anet agent（各自的 Bridge 监听同一群）。@提及谁，谁的 Bridge 触发 task；@all 或无 @ 时按各自 `groupPolicy`。这天然支持"IM 群 = 多 agent 协作房间"。
- **回复路由**：reply 必须回到来源 `conversation.id`（私聊回私聊、群聊回群、线程回线程）—— 由 §4.1 的 `conversation`↔`task_id` 映射表保证。
- **去重**：多 agent 同群且都被 @ 时，各自独立建 task、独立回复（符合预期）；同一 agent 不对同一 `messageId` 重复建 task（幂等键）。

### 4.4 会话连续性 / 并发 / 幂等 / 出站关联

- **会话连续性（P1 务实降级）**：commhub task 派到同一 agent alias **不等于** per-conversation session 隔离 —— 同一 agent 上的多个飞书群会共享同一 runtime 上下文。**P1 只保证** `conversation.id → task 关联 + 同会话串行队列`（顺序、不串台）；**per-conversation 独立记忆 / resume key 是后续目标**（需 agent 侧 session 隔离机制配合，超出本 RFC，记 backlog）。RFC **不承诺**"已有同 session 记忆"。
- **并发**：同一 `conversation.id` 的 task **串行**处理；跨会话可并发，并发度受节点 `maxTurns` / budget 约束。
- **幂等键**：`idempotencyKey = ${platform}:${connectionId}:${messageId}`（或平台 `event_id`）。命中 → **对平台返回成功（webhook 回 200），但不重复建 task、不重复派单**。一个 IM 事件最多对应一个 commhub task。
- **状态 store 必须持久化（P0，§2.9④）**：幂等记录与出站关联**不能只放内存** —— Bridge 重启会导致重复事件去重失效、agent reply 找不到 IM 会话、占位消息无法 edit。每个 channel 目录下维护一份轻量持久化 store（sqlite 或 jsonl）：

  ```
  .anet/nodes/<node>/channels/<platform>/state.db   (或 state.jsonl)
    idempotencyKey  →  taskId
    taskId          →  { conversationRef, threadRootId, sourceMessageId,
                         placeholderMessageId, status, createdAt }
  ```

  Bridge 作为 commhub 客户端**订阅自己派出的 task 的 reply**，收到时按 `taskId` 查 store 还原目标会话 / 线程 / 占位消息，再 `adapter.send()` 或 `adapter.edit()`。表项随 task 终态 + TTL（如 24h）GC。

### 4.5 可靠性与失败处理

commhub-gateway 模型**继承 commhub 当前 task/reply 的可靠性边界** —— 尤其 issue #168（silent-lost：task 长期停在 `delivered` / `started` 不进终态）。IM 用户不像 agent 能容忍静默，**Bridge 必须主动兜底**：

- **任务超时**：Bridge 为每个派出的 task 设超时（`config.taskTimeout`，默认 5min）。超时仍无终态 reply → 给 IM 用户发"⚠️ 处理超时，请重试或联系人工"，并把该 correlation 标 `failed`。
- **DLQ / 重试**：出站 `adapter.send()` 失败（限流 / 网络）→ 退避重试；多次失败进 dead-letter，计数上报 Dashboard（§6）。
- **依赖**：长期依赖 RFC-016（codex-sdk reply 可靠性）/ #168 修复收敛 commhub 投递可靠性；短期 **Bridge 自带 timeout + DLQ，不等上游**。
- 此项是 commhub-gateway 模型的已知风险，**P0 抽象层即需内建 task timeout 钩子**，不留到后面。

---

## 5. 鉴权与配置

### 5.1 `anet channel add` 扩展

沿用 RFC-002 已有的 `anet channel add <type> <node-id>` 入口，新增 IM 平台子命令：

```bash
# 飞书（Phase 1）
anet channel add feishu <node-id> \
  --app-id <App ID> --app-secret <App Secret> \
  --allow <open-id>            # 私聊白名单
  [--allow-chat <chat-id>]     # 群白名单

# Slack（Phase 2）
anet channel add slack <node-id> \
  --bot-token xoxb-… --app-token xapp-… --signing-secret <ss> \
  --allow <user-id> [--allow-chat <channel-id>]

# WhatsApp（Phase 3）
anet channel add whatsapp <node-id> \
  --phone-id <id> --access-token <tok> --verify-token <vt> --app-secret <as> \
  --allow <wa-id>

# 企微（Phase 4）
anet channel add wecom <node-id> \
  --corp-id <id> --agent-id <id> --secret <s> \
  --callback-token <t> --aes-key <k> --allow <user-id>

# 交互式（不带 flag 时逐项询问）
anet channel add feishu <node-id>

# 查看 / 删除
anet channel ls [node-id]
anet channel rm <type> <node-id>
```

### 5.2 配置文件落盘结构

延续 RFC-002：写 `.anet/nodes/<node-id>/channels/<platform>/`，**non-secret 与 secret 分离**：

```
.anet/nodes/<node-id>/channels/feishu/
├── config.json     非密配置 + adapter 参数（可进 git，含 ingressMode/groupPolicy 等）
├── .env            密钥（chmod 600，.gitignore 排除）—— APP_SECRET 等
└── access.json     白名单 { allowFrom: [...], allowChats: [...] }
```

`config.json` 示例：

```jsonc
{
  "platform": "feishu",
  "ingressMode": "socket",
  "appId": "cli_xxx",
  "groupPolicy": "mention",
  "ackPlaceholder": true,
  "secretRef": ".env"        // 密钥引用，明文密钥不在此文件
}
```

节点 `config.json` 的 `channels` 数组新增条目 `bridge:feishu`（与现有 `server:commhub` / `plugin:telegram@…` 并列）。agent-node 启动节点时见到 `bridge:<platform>` → 拉起对应 IM Bridge worker。

> 与 RFC-002 一致：`anet channel add` 落盘后**不热加载**，需 `anet node stop && start` 生效（文档明示）。热加载留作后续（参考 RFC-013 rename-hot-reload 思路）。

### 5.3 webhook 校验与密钥管理

**密钥管理**：

- 所有 IM secret（App Secret / access token / AES Key / Signing Secret）只落 `channels/<platform>/.env`，chmod 600，`.gitignore` 已含 `.anet/`。
- **IM secret 绝不上传 commhub hub** —— hub 保持 channel-agnostic（延续 RFC-002 §7 / RFC-001）。Bridge 在 agent 本机读密钥。
- Bridge 接入 commhub 用节点的 `ntok_`（RFC-001 双 Token 体系），与 IM 凭证完全隔离。

**webhook 签名校验**（webhook-mode 平台必需，由各 adapter 的 `verifyWebhook()` 实现）：

| 平台 | 校验方式 |
|---|---|
| 飞书（回调模式）| Verification Token + Encrypt Key 解密；socket 模式免 |
| Slack（HTTP 模式）| `X-Slack-Signature` v0 HMAC-SHA256 + timestamp 防重放；Socket Mode 免 |
| WhatsApp | `X-Hub-Signature-256` HMAC-SHA256（App Secret）；接入 `hub.challenge` |
| 企微 | `msg_signature` SHA1 + AES-CBC 解密 |

**webhook 公网入口**（Phase 3+ 的设计题，本 RFC 不锁定 —— §12 决策项③）。候选：

1. **commhub-server 内置路由** —— 用户把 commhub-server 部署在公网时，它额外暴露 `/im/webhook/:platform`，校验签名后把事件经既有 SSE 通道转发给绑定节点。优点：无新组件；缺点：让 hub 沾了 channel 逻辑（与 RFC-002 §7 张力）。
2. **独立 `anet im-gateway`** —— 一个轻量公网入口组件，只做"收 webhook → 校验 → 转 commhub task"，不持 LLM、不持出站 token。优点：职责单一、hub 干净；缺点：多一个要部署的东西。
3. **隧道**（cloudflared / ngrok）—— 把 agent-local 的 Bridge 暴露公网。优点：零额外组件；缺点：依赖第三方隧道、不适合长期生产。

→ **建议**：Phase 1/2（飞书 + Slack）走 socket-mode 完全规避此题；Phase 3 启动时单独出 RFC 定 webhook 入口方案。

---

## 6. Dashboard 展示

呼应 issue #162（Dashboard IM workspace）。分三块，复用 RFC-003 节点遥测层上报。

**① IM Connections 面板**（节点详情页新增）：

| 列 | 来源 |
|---|---|
| Platform | adapter.platform |
| 绑定节点 | connectionId |
| 状态 | `IMAdapterHealth.connected` → 🟢 connected / 🔴 disconnected / 🟡 error |
| Last event | `lastEventAt` |
| Last error | `lastError` |
| 限流余量 | `rateLimitRemaining` |
| Dead-letter / retry | Bridge 计数 |

**② Chat 视图来源徽标**：IM 来源的消息在 Dashboard Chat 视图带平台徽标（飞书 / Slack / WhatsApp / 企微图标）+ `conversation.id` / `threadRootId`，与 agent-to-agent 消息区分。

**③ 拓扑视图**：IM virtual participant 作为入站边显示 —— 每个活跃 IM 会话以"IM 用户"节点形态连到绑定 agent；可按 platform 聚类（呼应 RFC-017 组织架构视图的分组思路）。本期只读展示，不在拓扑里编辑 IM 绑定。

> Dashboard 详细交互设计归 #162 / 后续 Dashboard RFC，本 RFC 只定**数据契约**（`IMAdapterHealth` + task `meta.im`）—— 保证 Dashboard 拿得到该显示的字段。

---

## 7. 优先级与里程碑

**总原则**：架构层（adapter 抽象 + commhub-gateway Bridge）一次做通用，平台 adapter 一个一个叠（前一个 ship 后再推下一个）。**飞书优先**（Vincent 定）。

| Phase | 范围 | 关键交付 | 公网门槛 |
|---|---|---|---|
| **P0 抽象层** | `IMAdapter` 接口 + `NormalizedIMEvent/Message` + IM Bridge（commhub-gateway）骨架 + `anet channel add` 框架扩展 + **§2.9 commhub 增量**（`meta_json` 列 / `send_task` `meta` 参数 / SSE 透传）+ **持久化 correlation/idempotency store** + **task timeout 钩子** | mock adapter 跑通：mock 入站事件 → commhub task（带 meta）→ agent → reply → mock 出站；Bridge 重启后幂等/回包不丢 | ❌ |
| **P1 飞书 MVP** | `FeishuAdapter`（WebSocket）+ `anet channel add feishu` + access 白名单 + 私聊/群@/线程映射 + "处理中"占位 + Dashboard 连接状态 | 飞书用户私聊 bot → agent 回复；群里 @bot → agent 回复（回原 thread）| ❌ |
| **P1.5 主动推** | agent 主动推 IM 的明确协议（§4.2 / §12⑨）—— `anet im send` 或 JSON envelope | agent 能主动往指定飞书会话推送 | ❌ |
| **P2 Slack** | `SlackAdapter`（Socket Mode，先 ack/入队）+ thread 语义 + 签名校验（HTTP 模式备用）| Slack channel/DM/thread 收发跑通 | ❌ |
| **P3 WhatsApp** | webhook 公网入口方案（单独 RFC）+ `WhatsAppAdapter` + 24h 窗口 / 模板处理 | WhatsApp 1:1 收发 + 模板消息 | ✅ |
| **P4 企微** | `WeComAdapter`（自建应用 + AES 回调）+ 复用 P3 公网入口 | 企微成员会话 / 应用消息推送 | ✅ |
| **P5 Dashboard IM workspace** | 完整 IM workspace（呼应 #162）：Connections 面板 / Chat 徽标 / 拓扑 IM 节点 / dead-letter 可视化 | —— | —— |

**MVP 范围定义（P0+P1）**：飞书单平台，socket 模式零公网，覆盖私聊 + 群@ + 线程 + 入站收发（IM→agent→回 IM 原会话）+ access 白名单 + Dashboard 连接状态。agent **任意主动推** IM 列 P1.5（需明确协议，§4.2）。WhatsApp / 企微 / Slack 列后续分期，但 P0 抽象层保证它们是"加 adapter"而非"改架构"。

> 通信IM牛 调研建议 MVP 为 Slack + 飞书并列（二者都有清晰 group/thread/@ 语义）。本 RFC 依 Vincent「飞书优先」定为飞书单平台先行，Slack 作为紧随的 Phase 2 —— 二者技术路径（socket-mode、agent-local）同构，P1 打磨好的抽象 P2 直接复用。

---

## 8. 边界 case 与已知问题

| 场景 | 处理 |
|---|---|
| webhook 重复投递 | 幂等键去重（§4.4）|
| socket 断线重连 | adapter 内指数退避重连；Bridge 监督；重连后可能补发历史事件 → 幂等键兜底 |
| Bridge 进程崩溃 | agent-node 监督重启（RFC-010），退避 3s→60s |
| 同一会话并发消息 | 同 `conversation.id` 串行处理（§4.4）|
| LLM 处理慢 | "⏳ 处理中"占位，正式回复时编辑（飞书/Slack）或追加（WhatsApp 不支持编辑）|
| agent 输出超平台长度上限 | 自动分片发送 |
| 群里被无关消息刷屏 | `groupPolicy: mention` 默认只 @bot 触发，烧 quota 可控 |
| 同 IM 应用绑定多节点 | 各节点各自 Bridge；socket 模式各自独立长连接（飞书/Slack 允许）；webhook 模式需入口按 connectionId 路由（Phase 3 处理）|
| WhatsApp 24h 窗口外 | 只能发预审模板；窗口状态在 Dashboard 标注，超窗回复降级为模板或排队 |
| 节点 rename | IM 绑定随 connectionId 走，rename 不丢绑定（参考 RFC-018 跨 runtime 身份）|
| IM 用户撤回消息 | MVP 不处理（task 已建则照常）；后期可监听撤回事件标注 |
| 富文本 / 卡片 | MVP 纯文本 + 图片；交互卡片（飞书 interactive / Slack Block Kit）后期 |

---

## 9. 测试计划

每平台一套独立 Docker 测试套件（符合团队测试规则：分层、Docker 隔离、mock 不碰生产）。

**P0 — `test-im-abstraction`**（mock adapter）：

```
L0 环境：mock-im-server 容器内起来
L1 配置：anet channel add（mock 平台）落盘 config.json/.env/access.json
L2 启动：agent-node 起，IM Bridge worker 拉起，接入 mock commhub
L3 入站：mock 发归一化事件 → Bridge 建 commhub task → mock agent 回 reply → Bridge adapter.send() → mock 收到出站
L4 白名单：not-allowed sender → ignore + audit
L5 幂等：同 messageId 重发 → 只建一个 task
L6 群聊触发：未 @ → ignore；@bot → 建 task
```

**P1 — `test-im-feishu`**：mock 飞书 WSClient + OpenAPI，验私聊 / 群@ / 线程 / 图片上下行 / "处理中"占位编辑 / 多用户 `open_id` 区分。

**P2/P3/P4** 各自套件，复用 P0 框架替换 adapter 与平台 mock。

测试由测试号执行、通信牛 review（团队规则）；所有测试在 Docker 内，mock 平台 API，不接真实 IM、不碰生产 hub。

---

## 10. 不在本 RFC 范围

- webhook-mode 平台的公网入口最终方案 —— Phase 3 启动时单独 RFC（§5.3 给候选）。
- Telegram 收编进 IM adapter 抽象 —— 可选优化，不强制；现有 RFC-002 路径继续可用。
- IM 富交互（飞书审批卡片 / Slack Block Kit 交互、按钮回调、斜杠命令系统）—— MVP 后迭代。
- IM 平台的非消息能力（日历 / 文档 / 音视频 / 群管理）。
- channel 配置热加载 —— 沿用 RFC-002「stop+start 生效」，热加载参考 RFC-013 后续做。
- 社区个人微信（ClawBot / ilink 方案）—— 本 RFC「企微」指**企业微信 WeCom 官方 API**；个人微信非官方方案不纳入。

---

## 11. 关联 RFC / Issue

- **RFC-002**（节点接入 Telegram）—— 直接前身。本 RFC 把其 `telegram-bridge` worker 泛化为平台无关的 IM Bridge，并把"claude-code-cli 走 plugin / SDK 走 bridge"统一收敛为"全走 commhub-gateway"。
- **RFC-001**（双 Token 体系）—— Bridge 用 `ntok_` 接入 commhub。
- **RFC-003**（节点遥测层）—— `IMAdapterHealth` 经遥测上报 Dashboard。
- **RFC-010**（节点生命周期）—— Bridge worker 的拉起 / 监督 / 重启。
- **RFC-017**（Dashboard 组织架构视图）—— IM virtual participant 在拓扑里的分组复用其思路。
- **issue [#179](https://github.com/sleep2agi/agent-network/issues/179)** —— 本 RFC 跟踪 issue。
- **issue [#162](https://github.com/sleep2agi/agent-network/issues/162)** —— Dashboard IM workspace，与本 RFC §6 / P5 互补。

---

## 12. 决策（Final，per Vincent 5947 delegate + 通信龙 ack）

Vincent telegram 5947 把 §12 拍板权下放给主笔（通信IM马），通信龙 ack。以下决策即生效，P0 实施与后续 PR 直接据此进行。

### 12.1 ⭐ IM 接入架构地基
**Decision**：采用 **commhub-gateway** 模型 —— IM 消息归一化后以 commhub task 形式派给绑定 agent，复用既有投递层；不为任何 runtime 单独做 IM channel plugin。
**Rationale**：runtime / agent 侧零适配（claude-code-cli + claude-agent-sdk + codex-sdk 三 runtime 都不动），Dashboard 天然可见，新增平台 N 只写一个 adapter。一次抽象长期受益。
**Risk**：成本推到 commhub 协议侧（§2.9 P0 增量 = `meta_json` 列 + SSE 透传 + Bridge 持久化 store）；选定后回不去 per-runtime channel。已评估成本可接受（`server/src/db.ts:127` 已有 ALTER TABLE 增量 migration 先例）。

### 12.2 飞书入站模式
**Decision**：WebSocket 长连接（`@larksuiteoapi/node-sdk` 的 `WSClient`）。
**Rationale**：零公网门槛，开发到生产用同一套，匹配 RFC-002 Telegram polling 的开发友好思路。
**Risk**：NAT 漂移 / 网络抖动可能断连，Bridge 自带指数退避重连（§2.5）兜底。HTTP 事件回调留作后期可选 fallback。

### 12.3 webhook 平台公网入口方案
**Decision**：本 RFC 不锁定；Phase 3（WhatsApp）启动时单独 RFC。
**Rationale**：P1 飞书 + P2 Slack 走 socket 模式不碰公网，公网入口决策无迫切性，提前定容易盲选。
**Risk**：Phase 3 启动可能需要回头补 RFC；但那时 IM gateway 模型已验证，公网入口是收口工程问题、不阻塞 MVP。

### 12.4 群聊默认触发策略
**Decision**：`groupPolicy: mention`（仅 @bot / slash command 才触发；`all` / `observe` 可配）。
**Rationale**：防群噪音打爆 agent + 控 LLM quota + 避免 agent 抢话。
**Risk**：用户可能误以为 bot 没在听（其实未 @），需文档 + 群欢迎语强调；可接受。

### 12.5 ⭐ MVP 范围
**Decision**：飞书单平台先行（P1），Slack 紧随 P2。
**Rationale**：Vincent 已定飞书优先；一次 ship 一个平台能集中精力打磨抽象层；飞书覆盖国内办公主战场、用户基数大；Slack 与飞书技术同构（都 socket-mode），P1 抽象做好 P2 几乎免费。
**Risk**：国际用户要等 P2 才能用 —— 但抽象层就是为让 P2 落地快而存在，不是阻塞。通信IM牛 调研倾向并列，二者技术同构故串行 ship 风险更低、抽象更稳。

### 12.6 是否复用社区 `claude-code-feishu-channel` 代码
**Decision**：复用其 Feishu SDK 调用层（WSClient 连接 / `im.message.receive_v1` 解析 / `im.message.create` 发送 / 图片上下行），重新挂在 `FeishuAdapter` + commhub-gateway 之下；不复用其 MCP Channel 协议出口。
**Rationale**：SDK 层已被 vansin 验证可用，省 1-2 周工程 + 减少 SDK 踩坑面。
**Risk**：未来 Feishu SDK 升级时维护成本归 anet；但 `@larksuiteoapi/node-sdk` 是官方 npm 包，社区代码只是薄壳调用，可控。

### 12.7 IM Bridge 的 commhub 身份
**Decision**：专属 alias `<bound-agent>-im-<connectionName>` + 专属 `ntok_`，token name `node:<该 alias>`（贴合 commhub 现有 caller-alias 派生规则）。
**Rationale**：审计链路清晰（IM 用户 → Bridge → agent，每跳可追溯）+ Bridge bug 不污染 agent 主身份。
**Risk**：多一组 ntok_ 要管理；RFC-001 双 Token 体系已能 handle，`anet channel add` 落配置时一并签发即可。

### 12.8 ⭐ `meta.im` 持久化方式
**Decision**：新增 `tasks.meta_json` + `inbox.meta_json` 列（一次 ALTER TABLE ADD COLUMN，向后兼容）。
**Rationale**：替代方案（塞进现有 `context` JSON）会让 Dashboard / Bridge 退化成 parse 文本 → 长期技术债 + 性能差 + 类型不安全；现在省的几小时改动，后面要花数倍偿还。
**Risk**：动 commhub schema 影响所有 anet 用户（升级时 DB migration）；但 `server/src/db.ts:127` 已有成熟的 ALTER TABLE 增量 migration 机制（inbox 表加列就是先例），不是从零设计。

### 12.9 ⭐ agent 主动推 IM 的时机 + 协议
**Decision**：时机 = P1 不做、P1.5 再加；协议 = 新工具 `anet im send --connection <name> --to <conv-id>`。
**Rationale**：P1 先把"IM 入站 → reply"链路打磨稳；P1.5 加主动推用显式工具，语义清晰；替代方案（Bridge alias + JSON envelope 走 send_message）等于把 send_message 变成"魔法 channel"，参考 commhub 早期 from_session 隐式推断踩坑教训，不在现有工具上隐式扩展。
**Risk**：多一个 CLI / 工具表面积；但只是 thin wrapper over Bridge 现有 send 路径，实现量很小。

### 12.10 IM `raw` payload 留存策略
**Decision**：默认不落盘（只在内存临时持有用于解析）；`config.auditRaw` 显式开关 + 强制脱敏（手机号 / token / URL 打码）+ 仅本地 audit log + 永不上传 hub。
**Rationale**：raw 含 PII（手机号 / wa_id / 文件 URL / 用户名 / 头像）；默认留存是隐私 + 合规风险，对 P1 无用。
**Risk**：调试时 raw 不在 → auditRaw 临时开 + §2.5 step 5 webhook 校验时的 audit 兼顾；非阻塞。

---

> **变更**：
> - v2 — 合入 通信牛 + 通信IM牛 双 review（REQUEST CHANGES，架构方向获双方 approve）：① 去除"commhub 零改动"过度承诺，新增 §2.9 协议增量；② Bridge 独立 alias + ntok_ 命名（§2.1）；③ correlation/idempotency 持久化到 channel-dir store（§4.4）；④ agent 主动推 IM 降级到 P1.5 + 明确协议（§4.2）；⑤ per-conversation session 务实降级（§4.4）；⑥ 新增 §4.5 可靠性/失败处理（依赖 RFC-016 / #168）；⑦ 企微内部群语义降级（§3.4）；⑧ 飞书数字加实施前复核脚注（§3.1）；⑨ Slack Socket Mode 同样 3s ack（§3.2）；⑩ `raw` 默认不落盘（§2.3）。
> - v3 — 双 review 复核 APPROVE 后 nit 修订：§2.5 `from_session` 统一为 gateway alias、§2.9 REST 路径更正为 `/api/task`、§2.5 主动推步骤与 §4.2 对齐（P1.5+）、§3.5 企微群聊语义降级为待验证。
> - v3.1（Final）— Vincent telegram 5947 把 §12 拍板权 delegate 给主笔；§12 inline 为 Final Decision（每条 Decision / Rationale / Risk），状态 Draft v3 → Final。通信龙 ack。RFC 进入 P0 实施。
>
> **流程**：本草稿 → 通信牛 + 通信IM牛 双 review → v2 fold → v3 复核 **双 APPROVE** → **Vincent delegate 主笔自决（v3.1 Final）→ commit → P0 实施启动**。
