OpenClaw 配置多个飞书账号实战指南：TaoToken 统一 Key 接入与 config.toml 骨架

1. 多飞书账号接入 OpenClaw 到底难在哪

OpenClaw 从 v2.4 开始支持多飞书账号，这件事本身不复杂，真正让人头疼的是「配置分散」和「Key 管理混乱」。我见过不少团队的做法是：每个飞书机器人单独跑一个 OpenClaw 实例，每个实例配一份大模型 Key，结果就是三五个账号下来，配置文件散落在不同目录，改一个参数要登录三台机器，日志还得分开看。

多账号体系的价值其实很明确。账号隔离让不同业务线的消息互不干扰；多 Agent 分工可以把代码助手、知识问答、值班机器人拆到不同飞书应用上；环境分离则让测试账号和生产账号在同一套框架里各跑各的。但前提是，你得有一套统一的配置骨架，而不是每个账号复制粘贴一份。

这篇要解决的核心问题有两个：第一，用一份config.toml骨架把多个飞书账号的 Agent 路由关系写清楚；第二，所有账号背后调用的大模型统一走 TaoToken 的 Key，避免每个 Agent 各配一个 Key、各记一个额度。目标是一次配置，稳定跑多个飞书账号。

适合谁看：已经在用 OpenClaw 接飞书单账号、想扩展到多账号的开发者；或者正准备给团队搭一套多机器人协作体系、不想被 Key 分散拖住的人。下面从环境准备开始，一步步给出可复制的配置。

2. 前置准备：TaoToken 统一 Key 与 OpenClaw 环境

在动config.toml之前，先把两件事准备好：一个能覆盖所有 Agent 的模型 Key，以及确认 OpenClaw 版本支持多账号。

2.1 为什么用 TaoToken 统一 Key

多账号场景下，如果每个飞书 Agent 都单独配一个大模型 Key，会出现三个问题：额度分散不好统计、某个 Key 失效要逐个排查、新增账号时又要申请新 Key。TaoToken 的做法是提供一个统一入口，多个 Agent 共用同一个 Key，调用走同一个 API 地址，额度在一个地方看。

对 OpenClaw 来说，你只需要在模型配置里填一次 base URL 和 Key，所有 Agent 都引用这份配置。新增飞书账号时，模型侧完全不用动。

2.2 获取 Key 与确认接入信息

登录 TaoToken 控制台，在 API Keys 页面创建一个 Key。建议按用途命名，比如openclaw-feishu-multi，方便以后区分。创建后复制保存，页面关闭后不再完整显示。

接入信息记两个：

• API 地址：https://taotoken.net/api
• Key：控制台生成的那串

如果你对模型对话效果想先验证一下，可以到模型对话页面直接试跑；如果是要长期跑编码类 Agent，可以了解下 Coding Plan 的额度方式。这两个入口在排障阶段也用得上，后面会再提。

2.3 OpenClaw 版本与目录约定

确认版本不低于 v2.4：

openclaw --version

低于这个版本先升级。然后确认两个核心目录存在：

ls ~/.openclaw/agents/ ls ~/.openclaw/workspace/

agents/下放每个 Agent 的配置，workspace/下放每个 Agent 的工作区。多账号场景里，一个飞书账号对应一个 Agent，对应一个工作区，这个映射关系后面会在config.toml里写死。

3. 可复制的 config.toml 骨架与多账号配置

这一节是全文的核心。我会先给出完整的config.toml骨架，再逐段解释每个字段为什么这么写，尤其是多账号路由和统一 Key 的引用方式。

3.1 完整 config.toml 骨架

下面这份骨架假设你有两个飞书账号：一个默认账号default，一个新增的note账号。模型侧统一走 TaoToken。

# ~/.openclaw/config.toml [model] provider = "openai-compatible" base_url = "https://taotoken.net/api" api_key = "sk-你的TaoToken统一Key" default_model = "gpt-4o-mini" [channels.feishu] enabled = true domain = "feishu" connection_mode = "websocket" # 默认账号凭证必须留在顶层，兼容旧逻辑 app_id = "cli_default_xxx" app_secret = "default_secret_xxx" default_account = "default" [channels.feishu.accounts.note] app_id = "cli_note_xxx" app_secret = "note_secret_xxx" [[agents.list]] id = "main" workspace = "~/.openclaw/workspace" default = true [[agents.list]] id = "note" workspace = "~/.openclaw/workspace/note" [[bindings]] type = "route" agent_id = "main" [bindings.match] channel = "feishu" account_id = "default" [[bindings]] type = "route" agent_id = "note" [bindings.match] channel = "feishu" account_id = "note"

这份骨架的关键点有三个：[model]段只写一次，所有 Agent 共用；default账号的app_id/app_secret留在[channels.feishu]顶层，不放进accounts；新增账号才写进[channels.feishu.accounts.xxx]。bindings段把每个飞书账号路由到对应 Agent。

3.2 模型段：统一 Key 只写一次

[model]段是整个配置里唯一出现 Key 的地方。base_url填 TaoToken 的 API 地址，api_key填你创建的那把 Key。default_model可以按你的 Agent 用途选，代码类 Agent 可以换成更强的模型。

这里有个容易踩的坑：有些教程会让你在每个 Agent 下单独写模型配置。多账号场景下不要这么做，一旦 Key 要轮换，你得改 N 个地方。统一写在[model]段，Agent 侧只引用不覆盖。

3.3 飞书账号段：default 与 accounts 的边界

这是多账号配置最容易出错的地方。default账号的凭证必须留在[channels.feishu]顶层，这是为了兼容旧版本的读取逻辑。新增账号才放进[channels.feishu.accounts.<name>]。

如果你把 default 的凭证也挪进accounts.default，启动后状态检查会显示not configured。这个坑我在迁移时踩过，排查了半天才发现是凭证位置的问题。

新增账号时，复制[channels.feishu.accounts.note]这一段，改名字和凭证即可。比如再加一个hr账号：

[channels.feishu.accounts.hr] app_id = "cli_hr_xxx" app_secret = "hr_secret_xxx"

3.4 Agent 与 bindings：路由关系写清楚

[[agents.list]]定义每个 Agent 的 id 和工作区。[[bindings]]定义路由规则：哪个飞书账号的消息，交给哪个 Agent 处理。

bindings的match里，channel固定是feishu，account_id对应账号名。default账号的account_id就是default，新增账号就是你在accounts里起的名字。这个对应关系必须一一对上，写错了消息就会路由到错误的 Agent，或者干脆没响应。

3.5 创建 Agent 与工作区

配置写好后，用命令创建对应的 Agent 和工作区：

openclaw agents add note --workspace ~/.openclaw/workspace/note

执行后会生成~/.openclaw/agents/note/agent/配置目录和~/.openclaw/workspace/note/工作区。如果你有多个新账号，逐个执行，把note换成对应名字。

4. 验证请求与多账号切换实测

配置写完不代表能跑。这一节给出验证步骤，确认每个飞书账号都能正常收发消息，并且路由到了正确的 Agent。

4.1 重启服务与状态检查

改完config.toml后重启 OpenClaw 服务，然后跑两条检查命令：

openclaw agents list --bindings openclaw channels status --probe

期望输出里，每个飞书账号都应该显示为就绪：

- Feishu default: enabled, configured, running, works - Feishu note: enabled, configured, running, works

如果某个账号显示not configured，回去检查凭证位置；如果显示running但works没出现，多半是权限或网络问题，看下一节的排查。

4.2 多账号切换验证动作

状态检查通过后，做一次真实的消息验证。给default账号的机器人发一条私聊，再给note账号的机器人发一条。然后看日志：

tail -f ~/.openclaw/logs/openclaw.log

配置正确的话，每次发消息会按顺序打印：

feishu[note]: received message ... feishu[note]: dispatching to agent session=agent:note:feishu:direct:...

这三行分别对应：账号收到消息、准备分发、成功路由到 note agent。如果只看到第一行没有后两行，说明路由配置有问题；如果三行都有但机器人没回复，说明是发送权限或模型调用的问题。

4.3 用模型对话快速验证 Key

如果怀疑是 TaoToken 的 Key 或模型配置有问题，可以先用模型对话页面单独测一下，确认 Key 本身可用。这样能把「模型侧问题」和「飞书侧问题」分开，排查效率高很多。

5. 本篇常见错误排查

多账号配置的报错集中在几个固定位置。下面按现象列出来，对照排查。

5.1 机器人能收消息但无法回复

先检查飞书开放平台的权限。必须开通im:message:send_as_bot，这是以应用身份发消息的关键权限。如果日志里出现code: 99991672，基本可以确定是权限不足。注意，添加权限后必须发布新版本才会生效，光在后台勾选不算。

5.2 首条私聊消息没反应

这是 pairing 配对审批机制在拦截。首条消息会被拦下生成配对请求，需要手动批准：

openclaw pairing list --channel feishu --account note openclaw pairing approve feishu <CODE> --account note

把<CODE>换成列表里拿到的实际代码。批准后该用户的消息才会正常进入 Agent。

5.3 Default Bot 显示 not configured

回头检查config.toml。大概率是把 default 的app_id和app_secret放进了accounts.default。把它们提取回[channels.feishu]顶层即可。这是多账号迁移里最高频的错误。

5.4 路由到了错误的 Agent

检查bindings里的account_id是否和accounts里的名字完全一致。大小写、拼写都要对上。另外确认agents.list里的id和bindings里的agent_id一致。

5.5 排查顺序 Checklist

遇到机器人无响应，按这个顺序走，不要跳步：

1. 在线状态：WebSocket 连接是否建立
2. Inbound：OpenClaw 是否收到飞书消息事件
3. 拦截器：是否被 pairing 或白名单拦截
4. 路由：消息是否按 bindings 分发到正确 Agent
5. Agent：目标 Agent 是否生成了回复
6. Outbound：调用飞书发送 API 是否成功

90% 的无响应问题集中在三点：路由配置错位、未授权配对、飞书 API 权限缺失。按这个顺序排查，基本能定位到具体环节。

6. 长期运行与 Key 管理建议

多账号跑起来之后，真正影响稳定性的往往是 Key 和配置的维护方式。

统一 Key 的好处在这里体现得最明显：所有飞书账号背后的 Agent 共用一把 TaoToken Key，轮换时只改[model]段一处，重启服务即可，不用逐个账号改配置。额度也在一个地方看，哪个 Agent 消耗大一目了然。

如果你后续要加更多飞书账号，流程是固定的：飞书开放平台建应用拿凭证、config.toml里加accounts段、加agents.list和bindings、跑openclaw agents add建工作区、重启验证。模型侧完全不用动。

长期跑编码类或高频 Agent 的话，可以了解下 Coding Plan 的额度方式，避免按量计费在高峰期超出预期。接入文档里有完整的参数说明，遇到配置字段不确定时对照查一下比猜快。

最后提醒一句：config.toml改完一定要重启服务再验证，热加载在多账号场景下不一定生效。每次新增账号后，先跑channels status --probe确认就绪，再发消息测试，能省掉很多来回排查的时间。