1. 为什么要把 AI 塞进飞书而不是继续开网页聊天先说结论网页版大模型是“你问一句它答一句”而 OpenClaw 这类 Agent 网关是“你不在它也在跑”。这两者的差别就像临时工和常驻同事。临时工你得每次交代任务常驻同事知道项目上下文、能自己翻日志、能在群里主动同步进度。我自己的触发点很具体团队里每天有人在飞书问“这个接口为什么 500”“昨天那个发布任务成功没”“帮我看下 gateway 日志”。这些问题答案都在机器上但每次都要人去查、去贴。于是我想能不能让一个长期在线的 Agent 住在飞书里谁问它都能接接完还能自己动手查。OpenClaw 解决的正是这件事。它是一个长期运行的 Agent 网关把三类能力拼在一起消息入口Channels支持飞书、Slack、Telegram 等、会话与记忆Sessions Memory让它知道你是谁、聊到哪了、技能化执行Skills Tools Scripts让它能跑命令、调 API、读文件。你可以把它理解成一层“可编程胶水”把大模型的推理能力接到真实工作系统里。适合谁跟做有台常开机器本地主机、内网服务器都行、团队主用飞书、愿意花一个下午把消息通道和技能跑通的开发者。不适合只想在网页里问几句、不打算长期维护的人。这篇我会按真实落地顺序写先讲清楚 OpenClaw 的 gateway 怎么接飞书消息再给可复制的配置然后讲 Skill 技能化怎么把“踩过的坑”变成“可复用能力”最后用一条飞书消息触发 Agent 并核对响应日志完成验证。模型调用这一层我用 TaoToken 统一 Key 通道来管省得每个技能里散落不同厂商的 Key。2. TaoToken 前置统一 Key 通道别让每个 Skill 各管各的模型在讲 gateway 配置之前先把模型调用这层理清楚。原因很现实OpenClaw 里会有多个 Skill每个 Skill 可能调不同模型——有的用便宜模型做意图识别有的用强模型做代码分析。如果每个 Skill 各自配 Key、各自记 Base URL维护起来就是灾难。我的做法是走 TaoToken 统一 Key 通道。它对外提供一套兼容常见协议风格的 API 入口OpenClaw 里所有模型调用都指向同一个 Base URL 和同一个 Key换模型只改 Model ID不动其他配置。具体入口我列一下后面配置里会用到官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基址https://taotoken.net/api这个不加 UTM直接填进配置模型对话页https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentCoding Plan长期编码/Agent 场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content操作顺序建议这样先去 API Keys 页面创建一个 Key命名成openclaw-gateway方便区分然后在模型对话页确认你要用的 Model ID 拼写最后把 Base URL 和 Key 填进 OpenClaw 的模型配置。这里有个细节Base URL 填https://taotoken.net/api就行不要自己加/v1之类的后缀具体路径以接入文档为准填错会直接 404。为什么强调“统一”二字因为 OpenClaw 的 Skill 是动态加载的你后面加一个新 Skill它读的是同一份模型配置。如果 Key 散在各处加 Skill 时又要复制一遍时间久了必然出现“这个 Skill 能用那个不能用”的排查地狱。统一通道之后模型层只有一个变量排障范围直接缩小一半。另外提醒一句Key 不要写进会提交到 Git 的文件里。OpenClaw 的配置目录一般在~/.openclaw/这个目录本身不该进版本库。我习惯用环境变量注入配置里引用变量名这样即使配置文件被看到Key 也不泄露。3. 可复制配置gateway 接飞书 模型通道 Skill 注册这一节是全文最该照着抄的部分。我按“模型配置 → 飞书 gateway 配置 → Skill 注册”三段给路径和字段名尽量贴近 OpenClaw 的实际结构你对照自己的版本微调。3.1 模型通道配置openclaw.json 片段OpenClaw 的主配置在~/.openclaw/openclaw.json。模型这块我抽成一个 provider所有 Skill 共用{ models: { defaultProvider: taotoken, providers: { taotoken: { baseUrl: https://taotoken.net/api, apiKey: ${TAOTOKEN_API_KEY}, models: { fast: gpt-4o-mini, strong: claude-sonnet-4-20250514 } } } } }这里apiKey用${TAOTOKEN_API_KEY}引用环境变量启动 gateway 前先export TAOTOKEN_API_KEY你的Key。fast和strong是两个别名Skill 里按需引用换底层模型只改这里一处。Model ID 的具体拼写以模型对话页和接入文档为准别凭记忆写。3.2 飞书 gateway 配置飞书接入这块配置项集中在channels.feishu。我踩过的坑基本都在权限和事件订阅上配置如下{ channels: { feishu: { enabled: true, appId: ${FEISHU_APP_ID}, appSecret: ${FEISHU_APP_SECRET}, connectionMode: websocket, dmPolicy: pairing, events: [im.message.receive_v1] } } }几个关键点解释一下。connectionMode选websocket比 webhook 稳定、延迟低也不用暴露公网回调地址。dmPolicy设成pairing意思是陌生人私聊需要配对确认否则你的 Agent 等于公开服务谁都能来消耗你的模型额度。events里im.message.receive_v1是接收消息的事件必须订阅否则飞书那边消息根本不会推过来。飞书开放平台侧要做的创建自建应用拿到 App ID 和 App Secret开通机器人能力订阅im.message.receive_v1事件如果要用“以用户身份发消息”还得让管理员开通im:message.send_as_user权限这个权限普通配置里没有缺了会直接卡住。3.3 Skill 注册示例Skill 是 OpenClaw 的生产力核心。一个 Skill 本质是一份带 schema 的清单告诉 Agent“这个能力叫什么、什么时候用、需要什么参数”。我拿“gateway 诊断”这个 Skill 举例文件放~/.openclaw/skills/gateway-doctor/SKILL.md--- name: gateway-doctor description: 诊断 OpenClaw gateway 启动失败、插件不兼容、飞书收不到消息等问题 tools: - name: read_gateway_log description: 读取 gateway 错误日志尾部 parameters: type: object properties: lines: type: integer default: 100 - name: check_plugin_manifest description: 校验插件 manifest 是否符合当前版本规范 parameters: type: object properties: pluginPath: type: string --- 当用户反馈 gateway 起不来或飞书无响应时 1. 先调用 read_gateway_log 读取 ~/.openclaw/logs/gateway.err.log 尾部 2. 若日志出现 plugin manifest requires configSchema调用 check_plugin_manifest 3. 输出根因 止血步骤 防复发建议注册完在openclaw.json里加白名单把加载面锁死{ plugins: { allow: [gateway-doctor, csdn-publish] } }plugins.allow这个白名单非常重要。我遇到过最典型的事故某个目录里多了个不合规插件gateway 怎么重启都起不来。加了白名单之后只有列表里的插件会被加载系统稳定性直接上一个台阶。4. 验证请求一条飞书消息触发 Agent 并核对日志配置写完不算完得跑通一条完整链路。验证分三步启动 gateway、发飞书消息、核对响应日志。4.1 启动并自检先跑自检OpenClaw 的 doctor 会把缺的权限、配置项直接报出来export TAOTOKEN_API_KEY你的Key export FEISHU_APP_ID你的AppID export FEISHU_APP_SECRET你的AppSecret openclaw doctordoctor 输出里重点看三类飞书权限是否齐全、模型通道是否可达、插件 manifest 是否合规。有报错先按提示修别急着启动。自检通过后启动 gatewayopenclaw gateway start openclaw gateway statusstatus显示running且飞书通道connected说明消息入口通了。4.2 发一条飞书消息在飞书里给机器人发帮我查一下为什么 gateway 起不来预期链路是飞书推事件 → gateway 收到 → 进 session → 命中gateway-doctorSkill → 调read_gateway_log读日志 → 模型分析 → 回到飞书。4.3 核对响应日志响应回来后去日志里核对每一步是否真的执行了tail -f ~/.openclaw/logs/gateway.log正常日志里应该能看到feishu event received、session created、skill matched: gateway-doctor、tool call: read_gateway_log、model request via taotoken、reply sent to feishu。这几行齐了说明从消息入口到模型调用到技能执行到回复整条链路是通的。如果模型调用那行报错大概率是 Key 或 Base URL 的问题回到第 2 节检查。如果skill matched没出现说明 Skill 没被加载检查plugins.allow白名单和 SKILL.md 的 frontmatter 格式。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth这一节按真实报错来都是我或身边人实际撞过的。401 Unauthorized。模型调用返回 401九成是 Key 问题。先确认环境变量TAOTOKEN_API_KEY在当前 shell 里真的存在echo $TAOTOKEN_API_KEY看有没有值再确认配置里引用的是变量名而不是写死的旧 Key。还有一种情况是 Key 被删了或过期去 API Keys 页面重新生成一个。注意 Base URL 别自己加后缀https://taotoken.net/api就是完整基址。local proxy failed。这个报错通常出现在 gateway 启动阶段意思是本地代理层没起来。常见原因是端口被占用或者上一个 gateway 进程没退干净。处理顺序openclaw gateway stop停掉残留进程lsof -i :端口看谁占着清掉再启动。如果配置里写了本地代理地址确认那个地址是可达的别指向一个不存在的服务。Cannot read properties of undefined (reading choices)。这个报错看着吓人本质是模型返回体结构不符合预期代码去读choices时对象是 undefined。根因通常是 Base URL 或路径拼错请求打到了一个返回非标准结构的地址。回到模型配置确认baseUrl是https://taotoken.net/apiModel ID 拼写和模型对话页一致。改完重启 gateway 再试。OAuth 相关报错。如果日志里出现 OAuth 字样多半是飞书应用授权或某个 Skill 里的第三方授权没走完。飞书侧检查应用是否已发布、权限是否已管理员审批Skill 侧检查它依赖的授权流程是否完成。这类问题不会自己好必须把授权链路走完。插件导致 gateway 起不来。典型报错plugin manifest requires configSchema本质是 OpenClaw 版本升级后插件 manifest 规范变了。处理顺序先openclaw doctor --fix定位看~/.openclaw/logs/gateway.err.log再止血把问题插件改名.bak从plugins.allow和plugins.entries里移除最后防复发把plugins.allow白名单维护好只放确认合规的插件。排障这块如果卡住接入文档里有更细的字段说明API Keys 页面可以重新生成 Key 排除凭证问题。模型本身的行为异常可以去模型对话页单独测一下同一个 Model ID确认是模型层还是 gateway 层的问题。6. 把踩坑变成 Skill让 Agent 真正长期在线走到这里你已经有一条能用的链路了飞书发消息Agent 接住调模型执行技能回消息。但要让 AI 真正变成“长期在线同事”还差一步——把重复的排查动作固化成 Skill。我自己的经验是踩过一次坑如果只记在脑子里那等于还会踩第二次写成 Skill它就变成可重复执行的能力。比如“飞书收不到消息”“gateway 起不来”“插件不兼容”都可以固化成一套 checklist读配置 → 读日志 → 输出修复建议。下次谁在飞书问Agent 自己就跑完了。再往前一步是记忆系统。如果 Agent 每次都从零开始它永远只能当客服机器人。把记忆落到本地向量检索 文件数据不出内网检索更贴近你的实际语境还能把你自己的排查经验沉淀下来。OpenClaw 支持本地向量库方案配合本地模型做 embedding整条记忆链路可以完全在内网闭环。最后给一个最小可行行动清单照着做就能跑起来先把飞书接入打通能收能发把两个高频场景做成 Skill一个发布类、一个诊断类给 Agent 一台常开机器当工作台让它持续在线。模型调用这层用 TaoToken 统一 Key 通道管住换模型只改一处。长期编码或 Agent 场景如果调用量大可以看下 Coding Plan按需选日常验证模型行为去模型对话页接入细节和字段说明在接入文档Key 管理在 API Keys 页面。把“踩坑 → 固化 → 复用”这条链路跑通你的 Agent 才算真正住进了工作流里而不是又一个需要你盯着的网页。