1. duplicate plugin id 与 missing --app-id 同时出现，问题其实有两个
在 macOS 上给 OpenClaw 配飞书 channel 时，终端里突然冒出一行 duplicate plugin id 警告，紧接着你发现openclaw channels add --channel feishu根本不认--app-id/--app-secret这两个参数。这大概是原文第 9 步最容易卡住的一环。很多人会误以为是命令写错了，于是到处翻 help、换参数名，结果越查越乱。实际上这里藏着两个独立的问题：一个是 OpenClaw 的插件注册表里已经把 feishu 注册过一次，另一个是模型通道还没指向一个能用的 API 地址。插件身份和模型身份是两个维度，前者在~/.openclaw的配置里，后者由 Base URL 和 Key 决定。这次我把两个问题拆开处理，插件侧按原文openclaw config unset plugins.entries.feishu清理，模型侧到 TaoToken 建号领 Key，再把 OpenClaw 的 Base URL 填成https://taotoken.net/api（注意不要带/v1）。两条线互不干扰，反而一次就通了。
1.1 报错现场：它发生在哪一步
回到原文的完整流程：macOS 上先装 Node.js v24.14.0 或更新版本，然后sudo npm install -g openclaw@latest，接着openclaw onboard --install-daemon把后台守护进程装上，再依次做飞书配对、提权、装 clawhub 工具。到第 9 步重新配置飞书参数时，如果你之前已经跑过一次openclaw channels add --channel feishu，第二次再执行同样命令，OpenClaw 会在加载插件阶段发现 feishu 这个 plugin id 已经被注册过了，于是打出 duplicate plugin id 警告。注意看警告出现的时间点：它发生在命令真正开始引导你输入 App ID 之前，属于插件加载阶段的拦截。
1.2 为什么没有 --app-id / --app-secret 参数
openclaw channels add的设计是交互式向导，不是纯命令行参数模式。它没有暴露--app-id、--app-secret这类 flag，是因为这俩值通常很长，直接敲在终端里既容易出错，也可能被 shell history 记录下来。正确做法是让命令弹出提示，你逐项输入。如果你在-h里看不到这两个参数，不用怀疑命令坏了，它只是把参数收集放到了交互环节。真正需要修的，是那个阻止向导启动的重复插件条目。
1.3 先把两个问题分开记录
我的建议是拿一张纸或一个临时文件，把当前遇到的报错分成两行：第一行写duplicate plugin id，归属 OpenClaw 本地插件配置；第二行写「模型调用 401 / 模型不存在 / 通道不通」，归属模型 API 配置。后面每一步操作都先问一句「我在修哪个问题」。插件问题修完不会让模型自动通，模型通道改完也不会消掉插件警告，这两件事必须分别验证。
2. 清理重复的 feishu plugin 条目：openclaw config unset 是正解
原文给的修复起点很明确：先执行openclaw config unset plugins.entries.feishu。这条命令的作用是删除配置里plugins.entries下面名为feishu的键，而不是把整个 OpenClaw 配置清空。它保留了channels、tools、models等其他所有设置，所以不用担心误伤之前配好的东西。
2.1 执行清理并确认结果
打开终端，直接跑：
openclaw config unset plugins.entries.feishu正常情况下没有任何输出，命令静默结束。然后用openclaw config get plugins.entries看一眼当前插件注册表里还有没有 feishu：
openclaw config get plugins.entries如果返回{}或者列表里已经没有 feishu，说明清理成功。如果返回结果里还有feishu，最可能的原因是权限问题——你之前用sudo npm install -g openclaw@latest安装，可能导致部分配置目录的属主是 root。先执行原文里的权限修复命令，再重新 unset：
sudo chown -R $(whoami) ~/.npm chmod -R u+w ~/.openclaw 2>/dev/null2.2 清理后不要急着重新 add
很多人在 unset 之后立刻又跑openclaw channels add --channel feishu，然后发现还是有警告。这是因为 OpenClaw 的 daemon 还在内存里保留着旧插件列表。干净的做法是先把 daemon 停掉再启动：
openclaw daemon stop openclaw daemon start如果你在openclaw daemon stop时看到「command not found」或「no daemon running」，不用管，继续往下走。daemon 状态本身不干净才需要重启，如果它压根没在跑，反而是好事。
3. 交互式重新录入飞书 App ID / App Secret
插件条目清掉之后，再次执行：
openclaw channels add --channel feishu这次不会再被 duplicate plugin id 拦截。命令会启动一个交互式向导，逐个提示你输入 App ID、App Secret，以及是否启用某些附加能力。输入 App ID 时直接粘贴飞书开放平台里那个cli_xxxxxxxx开头的值，App Secret 是你在飞书后台创建应用时生成的密钥。注意飞书后台有两个容易混淆的值：App ID 和 App Secret 是一对，另一个叫「Verification Token」的东西用不上。
3.1 如果向导没有出现
极少数情况下，交互式向导会因为终端类型或 locale 设置没有正常启动，命令直接退回 shell。这时手动写配置兜底：
openclaw config set channels.feishu.appId "你的AppID" openclaw config set channels.feishu.appSecret "你的AppSecret"双引号里替换成你自己的值。写完之后再用openclaw config get channels.feishu核对，确认 appId 和 appSecret 都在。
3.2 配完飞书后重新配对
如果你之前跑过openclaw pairing approve feishu，重新配置 channel 后建议再 approve 一次，否则飞书侧的应用可能还停留在旧的授权状态。用你飞书后台生成的新二维码或配对码重新执行：
openclaw pairing approve feishu原文里这一步使用的是飞书机器人返回的配对码，不同版本可能格式不同，以你飞书后台看到的实际内容为准。配对成功后，飞书 channel 这条线就修好了，跟模型通道一点关系都没有。接下来才轮到处理模型 API。
4. 模型侧到 TaoToken 建号：拿 Key 和确认模型 ID
飞书插件的问题和模型通道的问题既然要分开处理，那模型侧该做什么？原文走的是 OpenRouter，这次我们把通道换成 TaoToken 的统一 API 接入。TaoToken 的作用是把你手里的模型调用统一收口到一个兼容通道里，让你用一个 Key 管理多个模型的调用，而不必在 OpenClaw、飞书、命令行之间来回切换不同的密钥体系。
4.1 注册并创建 API Key
打开 TaoToken，注册登录后进入控制台，在 API Keys 页面创建一个新 Key。创建后把 Key 复制下来，暂时存在安全的地方。这个 Key 就是YOUR_API_KEY的实际值，后面填到 OpenClaw 配置里用。
注意官网地址和 API 地址是两回事：你在浏览器里打开的是https://taotoken.net/?utm_source=taotoken_aicg_blog_end，负责注册、看用量、管理 Key；而待会儿填进 OpenClaw 的 Base URL 是https://taotoken.net/api，末尾不要加/v1。这两者一旦混用，最典型的表现是官网能打开但接口一直连接失败。
4.2 在模型广场确认当前可用的 Gemini ID
原文使用的模型是google/gemini-3.1-pro-preview，但模型 ID 会随平台更新而调整。到模型广场看当时列表为准，不要照抄旧文章里的 ID。如果广场上仍然有google/gemini-3.1-pro-preview，直接用它；如果没有，选一个当前可用的 Gemini 版本，把 ID 完整记下来。模型 ID 填错时 OpenClaw 一般不会立刻报错，而是等调用时才返回「model not found」，所以提前确认能省不少时间。
4.3 确认 Key 的归属
在控制台把 Key 和当前模型绑定关系的页面截个图，或者至少记下创建时间。后面验证阶段如果调用成功，你可以回到控制台看这一次调用是否被记账，这能直接证明「OpenClaw 调 Gemini 确实由 TaoToken 通道供 Key」，而不是走了别的路径。
5. 把 OpenClaw 的 Base URL 指到 https://taotoken.net/api
OpenClaw 读取模型配置的方式和 Claude Code 类似，都是通过环境变量或配置文件里的env块。这里我们要把三样东西填进去：Base URL、API Key、模型 ID。Base URL 填https://taotoken.net/api，不追加/v1；Key 填YOUR_API_KEY；模型 ID 以模型广场为准，下面的示例沿用原文的模型名。
5.1 编辑配置文件
打开~/.openclaw/config.json，在根级env块里加入三段配置。如果这个文件里还没有env，手动加一个：
{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY", "ANTHROPIC_MODEL": "google/gemini-3.1-pro-preview" } }把YOUR_API_KEY替换成你在 TaoToken 控制台创建的真实 Key。模型 ID 如果模型广场上的名称和上面不同，改成实际值。保存文件后，daemon 会在下次启动时读取它。
5.2 用命令设置同样生效
有些版本 OpenClaw 对 config.json 的结构校验比较严格，直接改文件可能会被格式化规则覆盖。也可以用命令逐条设置：
openclaw config set env.ANTHROPIC_BASE_URL "https://taotoken.net/api" openclaw config set env.ANTHROPIC_AUTH_TOKEN "YOUR_API_KEY" openclaw config set env.ANTHROPIC_MODEL "google/gemini-3.1-pro-preview"两种方式选一种即可，不要同时改文件又跑命令，免得互相覆盖。设置完之后用openclaw config get env.ANTHROPIC_BASE_URL确认值没被截断，尤其检查有没有多一个/v1或结尾斜杠。
5.3 重跑 onboard 让 daemon 重新加载
配置写入后，让后台守护进程重新读取一次。原文里有一条命令正好派上用场：
openclaw onboard --install-daemon这条命令会重新检查 macOS 上的 LaunchAgent 配置，并用最新的 env 设置刷新 daemon。跑完之后不要急着关终端，继续做验证。
6. 验证：飞书 channel 和 Gemini 调用一起打通
配置改完，验证要分两层走：先确认 daemon 活着，再实际发一条消息触发模型调用。
6.1 查看 gateway 状态
openclaw gateway status输出里应该显示 daemon 在运行，channel 列表里有 feishu 的字样。如果 gateway 没起来，先openclaw daemon start再查。这里常见的问题是改了配置但没有重启 daemon，导致旧进程仍然拿着旧的 Base URL 和空 Key。
6.2 在飞书里发一条测试消息
给飞书机器人发一句「你好，用 Gemini 回复这句话」。正常情况下，OpenClaw 会接收到事件，触发器把它交给模型，模型生成的回复再由飞书 channel 发回聊天窗口。如果飞书能收到回复，说明两条链路同时通：飞书 channel 配好了，模型通道也配好了。
如果消息发出去后没有任何回应，按顺序排查：网关日志里有没有模型调用记录；日志里有没有报401 Unauthorized（Key 不对）或404 Not Found（Base URL 的路径不对）；模型 ID 是否存在。这三项只要一项有问题，飞书这边就收不到回复。
6.3 回控制台核对这次调用
收到回复之后，登录 https://taotoken.net/?utm_source=taotoken_aicg_blog_end ，进入用量页面刷新一下。如果刚才的对话被记了一笔，说明调用确实经过了 TaoToken 通道。这一步能堵住一个隐蔽问题：有时候你以为配好了，实际走的还是 OpenClaw 内置的默认 Provider，Key 只是摆设。用控制台的用量记录来对账，比任何日志都准。
静下来想你大概率会遇到的另一个坑卡在「临时对话能用，但过一会儿又断」。这种多数是 daemon 在后台被 macOS 挂起，重新跑一遍openclaw onboard --install-daemon或者直接重启机器就能恢复。
7. 排障复盘：插件注册表与模型通道各修各的
回到最开始的场景，把整个排查过程重新捋一遍，你会发现 duplicate plugin id 和模型调不通之间根本没有因果关系，只是恰好被同一条命令撞到了一起。
7.1 两条修复路径的时间线
插件侧的修复路径是：openclaw config unset plugins.entries.feishu清理重复注册 → 重新执行openclaw channels add --channel feishu交互式录入 → 重新配对飞书。模型侧的修复路径是：到 TaoToken 建号 → 创建 Key → 把 Base URL 填成https://taotoken.net/api→ 重跑onboard --install-daemon→ 发消息验证。两条路径唯一的重合点是「重新启动 daemon」，除此之外没有任何共享操作。如果你把时间浪费在「是不是飞书配好了模型就通了」的猜想上，反而会把两个问题搅在一起。
7.2 最容易踩的三个坑
第一个坑：只清理插件，不重启 daemon。内存里的旧插件列表还在，看起来像没清干净。第二个坑：把官网链接填进了 Base URL。在浏览器里访问https://taotoken.net/?utm_source=taotoken_aicg_blog_end打开的是控制台，但 OpenClaw 需要的接口地址是https://taotoken.net/api，二者完全不同。第三个坑：在 Base URL 末尾加了/v1。很多 API 服务要求带/v1，但 TaoToken 的接口要求不带，多一个/v1会让模型调用直接 404。
7.3 后续可以顺手做的事
如果你打算长期用 OpenClaw 写代码或做自动化，有几个值得提前准备的动作。先到 TaoToken 模型对话 里用同一把 Key 发一条测试消息，确认这个 Key 本身没问题，这能把「配置问题」和「Key 问题」彻底隔离。用量大的话，可以考虑 Coding Plan 看看套餐是否更划算。Key 的管理和轮换在 控制台 API Keys 页面完成，下次再遇到 401，先去那里查 Key 是否被误删或过期。如果你后面要从 OpenClaw 切到 Claude Code，环境变量的对应关系可以参考 Claude Code 接入文档。不管切到哪个工具，记住原则：插件配置只管插件，模型通道只管 Base URL 和 Key，出了事各查各的表，别让一条警告带偏整晚。
