飞书接入OpenClaw与阿里百炼：搭建团队AI问答机器人实战

如果你跟我一样，每天绝大部分工作都泡在飞书里——聊需求、传文档、对排期、收通知——那你一定遇到过这种烦躁瞬间：明明刚想起一个问题想问问AI，却要切出聊天窗口，打开浏览器，找到模型平台，把问题粘进去，再等它生成，最后把答案复制回来。来回折腾两三次，念头就没了。

所以前阵子我专门花了一个周末，把这样一套链路搭了起来：OpenClaw 作为接入网关，阿里百炼作为模型提供方，飞书机器人作为统一对话界面。装好之后，我在飞书里直接给机器人发消息，就是一次完整的AI问答体验，不用切窗口、不用记平台地址，连群里同事都能直接@机器人让它帮忙总结文档。整个过程没有想象中复杂，但坑也不少，这篇就完整记录一下我是怎么一步步装通、踩过哪些雷、以及最终稳定运行的配置方式。

1. 方案拆解：为什么是OpenClaw + 阿里百炼 + 飞书这三件套

1.1 需求原点：让AI待在聊天窗口里

先说清楚我到底想解决什么问题。我自己在团队里承担不少信息整理和沟通的工作，每天有大量碎片化需求：把一段会议纪要转成待办清单、把一篇长文档缩成三句话摘要、把聊天记录里的关键信息抽出来排期。这些事本质上是轻量级的文本处理，但真要每次开电脑、开网页、复制粘贴，效率反而很低。

真正舒服的交互方式只有一个：在飞书聊天框里，像找人聊天一样把需求丢过去，AI直接在对话框里回我。到这里需求就非常明确了——需要一个能跟飞书消息流对接的网关，以及一个能稳定提供问答能力的模型服务。飞书负责“界面”，模型负责“脑子”，中间需要一层胶水把两边粘起来。OpenClaw 就是这层胶水，也是整套链路的核心。

1.2 链路选型：三层各自承担什么职责

这套架构拆开来看非常简单，一共三层，每层都有明确边界。

第一层是模型服务，我选了阿里百炼。百炼是阿里云推出的模型服务平台，核心价值在于“开箱即用”：开通服务后就能拿到API密钥，直接调用通义千问系列模型，不需要自己部署推理环境，也没有GPU运维压力。它提供的模型覆盖不同档次和价位，从便宜的轻量模型到高智能的旗舰模型都有，方便后期按场景切换。

第二层是 OpenClaw 网关。它负责统一对接模型服务和IM平台，把飞书发来的消息转成模型调用，再把模型返回的文本送回飞书。为什么要多这一层而不直接用飞书机器人回调接口写死一个模型？因为OpenClaw把会话管理、上下文记忆、多模型切换、消息格式适配、重试和日志这些都封装好了。我把飞书应用的App ID和密钥填进去，把百炼的API Key和模型地址填进去，剩下的事情它帮我处理。

第三层是飞书机器人。飞书开放平台支持创建企业自建应用，应用可以拥有机器人能力。用户私聊机器人、或者在群里@机器人，消息通过长连接推给OpenClaw，处理完再回到飞书显示。对终端用户来说，AI就是一个普通的飞书联系人。

打个比方的话：飞书是整个办公区的广播系统，OpenClaw是总机前台，阿里百炼是公司外面请来的顾问团。消息从前台接进来，转给顾问团回答，答案再由前台送回广播。我这个搭建过程，实际上就是给总机配好顾问团的通讯录和广播系统的线路。

1.3 为什么不直接对API

可能有人会问：既然飞书机器人本身能配置回调URL，为什么不直接在服务端自己写一个中转，调用百炼API再返回飞书？真要这么干也不是不行，我最早也这么想过。但实际用下来，自己写有四个绕不开的麻烦。

第一，会话上下文要自己维护。飞书每次消息回调都是一次独立请求，想让AI记住你前面说了什么，就得自己存会话ID和消息历史，包括清理过期会话、控制上下文长度，这些工作量不小。第二，多模型切换和参数调整要自己造轮子。想换一个模型、调一下温度，就得改代码重新部署。第三，消息事件的处理细节很多，比如消息去重、重试、图片和@消息的文本提取，这些边界情况会吃大量时间。第四，可靠性和日志体系要重新搭建，出了问题排查起来很痛苦。

OpenClaw把这些都变成了配置项。部署一次之后，我在管理面板里改模型名、调参数就行，不需要改代码。这省下来的时间，够我多泡好几杯咖啡了。

2. 环境准备与OpenClaw安装

2.1 前置环境：一台能长期在线的机器

整个链路对硬件要求不高，但有一个硬性条件：需要一台能全天候在线的机器来跑OpenClaw。因为飞书消息随时会进来，如果机器关机，机器人就失联了。我建议用一台云服务器、家里的旧电脑、或者NAS上的容器都行，关键是不能经常关机。

操作系统以Linux为主，Windows和macOS也能跑，但我更推荐Linux，因为后续进程守护、日志查看、开机自启都很方便。内存方面2GB以上就够用，模型推理发生在阿里百炼那边，本地不承担计算，所以对CPU几乎没有特殊要求。磁盘预留20GB以上，主要是日志和可能的缓存数据会慢慢增长。

网络方面有两个点需要注意。一是服务器需要能访问阿里百炼的API域名，这样模型调用才能成功；二是飞书侧我强烈建议用长连接方式接收事件，而不是开放公网回调地址。长连接是OpenClaw主动连上飞书的服务器，出方向网络通就行，不需要在防火墙上开入站端口，这对没有固定公网IP的服务器特别友好。

2.2 安装步骤实录：二进制方式快速跑起来

OpenClaw的安装方式挺简单，核心就三步：下载、解压、执行初始化。我这次用的是二进制方式，适合想快速验证的场景。

# 进入安装目录 mkdir -p /opt/openclaw && cd /opt/openclaw # 下载对应平台的安装包（以Linux x64为例） wget https://download.openclaw.example.com/openclaw-latest-linux-amd64.tar.gz # 解压 tar -zxvf openclaw-latest-linux-amd64.tar.gz # 执行初始化向导 ./openclaw init

初始化向导会问几个问题：数据目录放在哪里、要不要设置管理员账号、是否开启自动更新。我第一次装的时候全选了默认值，后来发现数据目录最好单独放，方便备份。管理员账号和密码要记好，Web管理界面登录靠它。

初始化完成后，直接启动服务：

./openclaw start

看到日志输出openclaw service started类似的提示，就说明跑起来了。管理界面默认监听在本地回环地址的一个端口上，浏览器访问就能打开。如果服务器有公网IP，建议不要直接把管理端口暴露出去，用反向代理加HTTPS访问会更稳妥。我后面就吃了没给管理界面加访问控制的亏，被扫描工具盯上了，日志里全是异常请求，后来加了一层认证才消停。

如果想用Docker方式，其实更省事，一条命令就能拉起来：

docker run -d --name openclaw --restart=always \ -v /opt/openclaw/data:/data \ -p 18080:18080 \ openclaw/openclaw:latest

两种方式选一个就行，我个人更推荐Docker，因为升级和恢复都方便些，配置文件和数据都挂在外部卷上，容器随便换都行。

2.3 安装后的健康检查

服务起来之后别急着接模型，先做好三件事。

第一，确认进程或容器处于运行状态。二进制方式用./openclaw status查看，Docker方式用docker ps查看，重点看有没有反复重启的迹象。第二，检查日志有没有报错。OpenClaw的日志一般输出到控制台和日志文件两份，出现关键字ERROR、FATAL就说明环境有问题，常见的是端口被占用或数据目录无权限。第三，登录Web管理界面，确认侧边栏里的“平台”“渠道”“模型”等菜单能正常打开。管理界面加载正常，说明核心服务没问题，可以放心进行下一步配置。

我当时在健康检查阶段遇到的情况是：端口18080被另一个服务占了，导致OpenClaw一直启动失败。排查方法很简单，lsof -i:18080看一眼是什么进程占用的，换一个端口启动就好。这种低级坑，往往比后面的模型配置更费时间。

3. 阿里百炼模型接入：API Key与模型选择全解析

3.1 开通百炼服务并获取API Key

模型接入的第一步，是让OpenClaw能“证明自己有权限”调用百炼的模型。这个过程对应到百炼平台上就是创建一个API Key。

登录阿里云控制台，找到阿里百炼的入口，首次进入会要求开通服务。开通本身是免费的，实际费用按调用量结算，使用前可以看看模型定价页面确认成本。开通之后，在控制台左侧找到“API-KEY管理”，点创建密钥，会生成一串形如sk-开头的小写密钥。这里有个细节：密钥创建后只完整显示一次，之后再也看不到明文，所以创建完要立刻复制妥善保存。

我习惯的做法是把它直接填进OpenClaw的管理界面里，然后不再保存到任何地方。留在电脑本地的临时记事本，用完删掉；绝不放进Git仓库、不写进代码注释，也不发给别人。之前有个朋友就是把API Key提交到了项目仓库，结果被人扫到盗刷了不少额度，这种教训真的一次都不能有。

百炼平台还提供了额度管理功能，我建议创建一个专用的API Key给OpenClaw用，而不是用主账号的密钥，这样每天限额、月度限额都单独控制，就算泄露了也能及时止损。

3.2 在OpenClaw里添加模型渠道

拿到API Key之后，打开OpenClaw管理界面，找到模型或渠道配置的地方，新建一个模型渠道。类型选择 OpenAI 兼容协议，因为百炼对外提供了兼容OpenAI接口格式的访问端点，OpenClaw只要填对这个地址，就能无缝对接，不需要任何中间转换层。

需要填写的关键字段如下表所示：

表格里这个Base URL是关键，它本质上是一个适配层，把OpenClaw发出的OpenAI风格请求，转换成百炼平台原生API格式。IP访问或者域名访问都支持，但生产环境建议用域名，避免IP变更带来的配置失效。

填完之后别急着保存，先做一次连通性测试。OpenClaw一般会提供发送测试请求的功能，用一个最简单的ping或空对话验证能不能拿到模型响应。失败的话，检查API Key有没有多余的空格或换行符。我就是在这里栽过一次：复制密钥时把末尾的换行符也带进了配置框，导致一直401鉴权失败，肉眼根本看不出来，最后是逐字符对比才发现的问题。

3.3 关键参数与运行时配置

模型渠道创建好之后，还有几个参数值得花时间调一调，直接影响实际使用体验。

第一个是模型名，必须写百炼平台的模型ID，而不是中文展示名。比如你想用“通义千问-Turbo”，填进去的字符串是qwen-turbo，写成中文或者别名都会报找不到模型。我常用的几个模型ID如下表：

第二个是温度参数。不同任务类型差异很大，我一般在OpenClaw里给不同模型渠道设置不同的默认温度：摘要和文案类任务设为0.7到0.9，希望有一点发散和润色；代码审查、事实问答类任务设为0.2到0.3，严格控制确定性。OpenClaw如果支持按会话或按用户覆盖温度，那就更灵活了。

第三个是超时与重试。大模型推理本身耗时较长，超时阈值建议给到60秒以上，不要用默认的几秒短超时。重试次数设2到3次，百炼偶尔会有网络抖动，重试一次往往就好了。同时要注意并发上限，免费或低配账号并发很低，频繁调用会触发限流，OpenClaw里如果有限流配置就设置一个安全值，比如每秒不超过2次请求。

这些参数在管理界面里都有对应项，全部保存后，模型层就已经通了。到这一步，我用管理界面自带的测试功能已经能收到正确的模型回复，接下来才是重头戏——把飞书绑上。

4. 飞书机器人界面的搭建与绑定

4.1 创建飞书自建应用并开启机器人

飞书侧的工作需要去飞书开放平台完成。打开开发者后台，选择“企业自建应用”，创建应用。应用名称要和实际用途对齐，我开始时随手填了个“测试机器人”，后来同事看到根本不敢用，又改成明确的业务名才正常。应用图标也建议换掉默认的，小细节影响团队接受度。

创建完成后进入应用详情页，左侧菜单找到“应用能力”里的“机器人”，开启机器人能力。这一步开启后，应用在飞书里就拥有了机器人身份，后续它才能出现在用户搜索列表里。

紧接着要做权限配置。在“权限管理”页面，给应用申请必要的IM权限，至少要包含读取用户发给机器人的单聊消息、读取群消息中@机器人的消息、以及回复消息的权限。具体权限名称在飞书开放平台有完整列表，申请时要选择对应版本并发布。注意：企业自建应用的权限开通需要发布版本才会真正生效。我第一次配置时没发布，机器人虽然在通讯录里，但发消息完全没有响应，折腾了半天才发现是没点发布按钮。

4.2 获取凭证与配置长连接

权限准备好之后，返回应用详情页的“凭证与基础信息”，能看到App ID和App Secret两个字符串。App ID是应用的公开标识，App Secret是私有密钥，两者在后端配置里都要用到。

把这组凭证填进OpenClaw的IM平台配置里。平台类型选飞书，粘贴App ID和App Secret，保存后OpenClaw会尝试与飞书建立连接。事件订阅方式这里强烈建议选择“使用长连接接收事件”。飞书原本的事件订阅机制要求你提供一个公网HTTPS回调地址，还要通过URL校验，这对没有固定公网IP的自部署环境非常不友好。长连接模式则是飞书服务端主动推送事件到OpenClaw建立的长连接通道，不需要公网入站端口，配置简单，还在断线后自动重连。

在飞书开发者后台，事件订阅处选择长连接作为接收方式即可。注意不要同时开启旧的回调URL和长连接，否则会出现消息重复推送，OpenClaw会收到一模一样的消息两次，回复也会发两次。我实际验证过，同时开启时日志里全是重复事件，关掉回调URL后一切恢复正常。

4.3 绑定会话并完成端到端联调

配置完成后先别急着拉人进群，从最简单的私聊开始验证整体链路。

在飞书里搜索刚创建的机器人名称，点进去私聊窗口，发一句“你好”。正常流程下，这句话会通过长连接推送给OpenClaw，OpenClaw带上飞书会话标识调用百炼模型，拿到回复后通过机器人身份发回来。连招是：先发一句具体指令，比如“帮我总结这段话的三个要点：xxx”，然后紧接着说“那第二点能否给个例子”，如果第二问能结合上一轮的内容回答，说明上下文记忆中继正常。

我在这个阶段遇到了一个印象很深的细节：第一次发消息后迟迟没有回复，翻日志发现OpenClaw根本没有收到任何飞书事件。排查了一圈，发现是应用版本没有发布，导致机器人能力没有真正生效。在开发者后台点开“版本管理与发布”，创建版本并发布后，消息才正常流转起来。等私聊通了，再建一个测试群，拉机器人进群，@它提问。群里对话的表现和老老实实私聊略有不同，OpenClaw默认会解析@机器人的消息文本，所以提问时记得带上@，否则机器人不一定响应。

到这一步，OpenClaw + 阿里百炼 + 飞书这条链路就完全打通了。此时整条链路的状态是：用户在飞书发消息，飞书长连接推给OpenClaw，OpenClaw调百炼模型，模型返回文本由OpenClaw组织成飞书消息发回。看起来简单，但这里面每一层都可能有细微问题，下面集中列一下我实际踩过的坑。

5. 常见问题与排查技巧实录

5.1 模型调用异常排查

模型调用是整条链路里最容易出问题的一环，常见问题可以整理成速查表，按现象定位原因：

我最常碰到的是模型ID写错。百炼平台偶尔会有新模型版本，ID末尾带日期后缀，比如某个新模型在控制台显示名称和实际API ID不一致。遇到404时，不要只看控制台页面显示的名字，去模型列表页找到官方文档里标注的API模型名才是准的。

超时问题也要重视。默认的超时配置往往只有30秒左右，但复杂的模型推理加上弱网环境，很容易超过这个阈值。我在内网环境用4G热点调百炼的时候，经常60秒才返回结果，后来把超时统一改成90秒，重试次数设3次，就没再遇到过“明明模型返回了，但因为超时被判定失败”的情况。

5.2 飞书机器人不回复排查

链路通了之后，最让人头大的就是“机器人不回复”。下面是按出现频率排序的排查清单。

先看应用版本有没有发布。很多人在开发者后台把权限配好了、机器人能力开了，但没点“创建版本并发布”，导致所有配置都不生效。这一步作为第一排查项。

再看OpenClaw日志里有没有飞书连接成功的记录。如果日志一直显示重连，说明长连接没建起来，大概率是App ID或App Secret填错了。注意这两个字段别填反，App ID是cli_开头，App Secret是一串随机字符串，有些人在配置时会把ID和密钥位置弄混。

然后检查在群里发消息时有没有@机器人。飞书群的默认规则是，应用机器人只响应被@的消息。如果发的是纯文本@，事件里才会包含机器人相关信息；如果完全没@，机器人可以收到但不一定会处理。有些IM平台配置里有“响应所有群消息”的开关，我自己没开，因为群聊里全量响应会很吵。

最后看消息权限。私聊能收到回复而群聊不行，多半是群聊权限没单独开通。飞书的权限列表里，单聊和群聊的IM权限是分开的，只配了单聊权限会导致群里无响应。按最小权限原则，把需要的能力逐个开齐再测一次。

5.3 我踩过的坑与避坑心得

除了上面速查表里的问题，还有几个更隐蔽的坑，我单独拿出来讲。

第一个是历史角色混淆导致的串台。OpenClaw如果之前配置过其他IM平台，数据目录里可能有旧的会话映射，我在新环境接飞书时发现某个人发来的消息被当成另一个人，原因是配置迁移时没清理旧缓存。建议新环境从零初始化数据目录，不要复用太杂的历史数据。

第二个是上下文长度管理。百炼模型都有上下文窗口上限，如果OpenClaw默认把所有聊天历史都发给模型，一段长时间对话后请求会超长报错。解决办法是设置合适的历史轮数上限，比如OpenClaw里开启滑动窗口，只传最近20条消息，或者按token数截断。我自己排序出心得了：把会话上下文调成“最近对话轮次20轮、超出部分截断”，长聊不崩，团队测试下来反应很好。

第三个是回复延迟的心理预期。大模型响应天然比普通机器人慢，飞书端也没有“正在输入”的中间状态展示，所以同事第一次用会觉得“是不是死掉了”。我在测试群公告里写明了“思考中请稍等”，顺带汇报完延迟预期，团队接受度立刻高了。

第四个就是管理界面的暴露问题。一开始图方便把管理端口直接绑到公网IP上，结果第二天日志里全是陌生IP扫描记录。后来我用反向代理加访问认证把管理界面藏起来，并且只允许内网访问，风险才降到可接受程度。

6. 踩坑后的几点心得与扩展方向

6.1 链路跑通之后还能怎么玩

整套链路跑通之后，它就是一个可以承载很多自动化业务的基础设施了，我目前已经在玩的几个方向可以参考。

模型路由是按场景自动分流：日常闲聊和简单总结直接走qwen-turbo，便宜速度快；涉及代码审查、复杂数据分析和长文生成的请求，配置成自动切换qwen-max。OpenClaw管理界面里可以设置不同用户的默认模型，也可以按会话临时切换，这比固定一个模型死用灵活太多。

群内信息聚合是我的场景刚需：在项目群里@机器人让它把过去一小时所有消息总结成待办清单。实现思路是先把群消息导出成文本节点，再由OpenClaw汇总后调用模型生成结构化列表。说实话效果超出预期，团队现在每周五下午固定让机器人出一份项目周报草稿，人工改改错别字就能发。

定时任务也很实用。OpenClaw支持配置计划任务，比如每天早上9点让机器人给指定群发一条今日重点提醒，内容由模型根据前一天的聊天记录自动生成。以前这种功能要写单独的脚本，现在在管理面板里点几下就能配置，维护成本低得多。

后续如果要接内部知识库做检索增强，也可以在这一层继续扩展。把团队文档切片后存入向量库，OpenClaw接一个检索工具，飞书里问“我们上季度的复盘结论是什么”，机器人先检索再生成，比纯模型硬答要准确得多。

6.2 几条实在话

这套方案从头到尾折腾下来，最深的几个感触是：先跑通最小闭环，再追求花哨功能；配置尽量都收敛到管理界面里，脚本只负责启动服务；日志就是一切，遇到疑难杂症第一反应是翻OpenClaw的日志，而不是猜。

还有一条经验，是给别人搭这类系统时经常被忽略的——说明文档要写在机器人使用说明里。我花了大半天搭好的系统，不在飞书机器人说明页面写清楚“能做什么、不能做什么、怎么@”，同事压根不会主动用。后来我把示例指令直接贴在机器人名称备注里，使用率明显上去了。

如果你也在飞书上办公，又恰好每天有一堆重复的文本处理需求，这套三件套方案值得花一个周末试一遍。它不需要你写多少代码，更不需要管模型背后那些复杂的推理细节，要的只是静下心把每一层配置填对、把每一段日志看明白而已。等第一次在飞书里收到机器人完整的回答时，你会有一种“啊，工作流终于完整了”的踏实感。