把 AI 编码助手接入飞书/钉钉：两种路径的实际操作对比

预计阅读时间：7 分钟

想把 AI 编码助手接到飞书或钉钉，第一步不是调模型、不是写 Prompt——是让 IM 通道跑通。这一步卡住，后面全白搭。最近对比了 OpenClaw 和 SolonCode Web 两条路，差距比预想的要大：SolonCode 内置 IM 通道，填两个凭证、发一条消息就完事；OpenClaw 要装插件、改 JSON、重启网关、处理配对，步骤多出两三倍。下面把两条路拆开看。

SolonCode：两个凭证，一条消息

SolonCode Web 把飞书和钉钉的 IM 通道做进了框架本身，不需要额外装插件。整个流程可以压缩到三步：

在飞书/钉钉开放平台创建应用，拿到 App ID 和 App Secret。
把这两个值填进 SolonCode 的配置文件。
在 IM 里给应用发一条消息，通道自动激活。

配置文件长这样：

# soloncode-web.yml — 飞书通道配置
im:
  feishu:
    appId: "cli_a3x9k2m5n7p"
    appSecret: "dF8gH2jK4lN6pQ8rS0tU2vW4xY6z"
    # 可选：指定事件回调地址，默认用框架内置路由
    callbackPath: "/feishu/event"

钉钉同理，换一组凭证和前缀：

# soloncode-web.yml — 钉钉通道配置
im:
  dingtalk:
    appId: "ding_abc123xyz"
    appSecret: "A1b2C3d4E5f6G7h8I9j0"
    callbackPath: "/dingtalk/event"

填完之后启动服务，在飞书/钉钉里找到你的应用，随便发一句"你好"，日志里出现事件回调记录，通道就通了。没有插件安装、没有 JSON 手写、没有重启等待。

OpenClaw：插件 + JSON + 重启 + 配对

OpenClaw 的 IM 通道不是内置的，需要走一套完整的插件安装流程。以飞书为例，实际操作步骤如下：

第一步：安装飞书插件

# 在 OpenClaw 网关目录下执行
openclaw plugin install feishu-adapter
# 输出类似：
# Downloading feishu-adapter-1.2.0.tar.gz ... done
# Extracting to plugins/feishu-adapter ...
# Plugin registered, requires gateway restart

第二步：手写 JSON 配置

插件装完不会自动生效，需要在网关配置里加一段 JSON：

{
  "plugins": {
    "feishu-adapter": {
      "enabled": true,
      "appId": "cli_a3x9k2m5n7p",
      "appSecret": "dF8gH2jK4lN6pQ8rS0tU2vW4xY6z",
      "eventCallback": "https://your-gateway-host:8080/feishu/callback",
      "verificationToken": "token_from_feishu_platform",
      "encryptKey": "encrypt_key_from_feishu_platform"
    }
  }
}

注意这里比 SolonCode 多了 verificationToken 和 encryptKey——飞书开放平台确实要求这两个字段做事件校验，SolonCode 在框架层自动处理了，OpenClaw 需要你手动填。

第三步：重启网关

openclaw gateway restart
# 等待 10~30 秒，取决于插件数量和网关规模

第四步：处理配对

重启后，飞书端发消息可能不会立刻响应。需要确认插件与网关的配对状态：

openclaw plugin status feishu-adapter
# 如果输出 "pairing: pending"，需要手动触发配对：
openclaw plugin pair feishu-adapter --gateway main

配对完成后再发消息测试。如果中途某个字段填错，就要改 JSON → 重启 → 重新配对，循环往复。

步骤对比：数字说话

把两条路的关键操作列出来：

操作	SolonCode	OpenClaw
安装插件	不需要	1 次
编辑配置	填 2 个字段	填 4~6 个字段
重启服务	不需要（热加载）	1 次
配对/激活	发消息即激活	手动配对命令
回调地址	框架内置路由	手动填 URL
事件校验	框架自动处理	手动填 token/key

总步骤数：SolonCode 3 步，OpenClaw 6~8 步。差距不是一点。

为什么 SolonCode 能少这么多？

核心原因只有一个：IM 通道是框架的一部分，不是外挂。

SolonCode Web 把飞书和钉钉的消息接收、事件校验、回调路由全部做进了框架核心。开发者只需要提供身份凭证（App ID / App Secret），框架自动完成：

注册回调路由（/feishu/event、/dingtalk/event）
处理飞书的 verificationToken 和 encryptKey 校验逻辑
解析事件体，分发到对应的 handler

OpenClaw 的架构是"网关 + 插件"，IM 通道作为插件挂载，每个插件要独立声明配置、独立注册路由、独立处理校验。灵活，但每多一个通道就多一套安装配置流程。

实际接入时的选择建议

如果你只是想把 AI 编码助手接到飞书或钉钉，让团队在群里用起来，选择逻辑很清晰：

选 SolonCode 的场景： - 只需要飞书/钉钉，不需要其他 IM - 团队没有专职运维，开发者自己搞定接入 - 追求"今天下午就能用"

选 OpenClaw 的场景： - 需要同时接入多个 IM（飞书 + 钉钉 + 企业微信 + Slack） - 已有 OpenClaw 网关在运行，不想引入第二个框架 - 有运维同学能维护插件配置和重启流程

一个快速判断方法：数一下你要接入的 IM 数量。如果 ≤ 2，SolonCode 的内置通道几乎总是更省事；如果 ≥ 3 且需要统一网关管理，OpenClaw 的插件体系虽然前期麻烦，但后续扩展更一致。

最后给一个实操检查清单，不管选哪条路，接入前都建议逐项确认：

✅ 飞书/钉钉开放平台应用已创建，App ID 和 App Secret 已拿到
✅ 应用已开通"接收消息"权限（飞书叫"事件订阅"，钉钉叫"消息接收"）
✅ 服务器公网可达，回调 URL 能被 IM 平台访问到
✅ 如果用 OpenClaw，提前确认网关版本与插件版本兼容
✅ 接入后先发一条测试消息，确认日志有回调记录再往下走

通道跑通，才是真正的起点。