扣子飞书机器人集成与协同办公实战指南

先说几个核心要点：要将扣子（Coze）机器人顺利接入飞书并实现消息自动回复、多轮对话乃至审批协同，官方文档里那些没明说的坑——比如签名验证陷阱和事件路由冲突——才是最需要留神的。整个流程，本质上就是在飞书创建一个自建应用，再把Coze作为连接器挂上去，但中间有几个关键步骤，顺序错了、配置差了，都会导致全盘失败。

创建飞书自建应用并获取凭证

打开飞书开放平台，进入【开发者后台】，在【应用管理】下创建新应用，选择“企业自建应用”，取个名字比如“Coze-Office-Bot”，点击确认就行了。

进入新应用的详情页，左侧菜单里找到【凭证与基础信息】，把

和复制下来。这两个值在后续Coze侧配置时必须完全一致，字母大小写都不能错——很多第一次上手的人就是栽在这里，排查半天才发现是大小写没对上。

然后在【权限管理】中勾选这几个：获取单聊消息、获取群消息、发送消息（群/单聊）、读取用户基本信息。注意，这里不要勾选“机器人权限”，那是旧版接口，Coze现在走的是用户代入模式，勾了反而容易出问题。

在Coze中配置飞书Bot连接器

打开Coze Bot编辑页，进入【Bot Settings】→【Connectors】，点击【+ Add Connector】，选择【Feishu】。把上一步复制的App ID和App Secret粘贴进去，点击Sa ve保存。

此时Coze会自动生成一个Webhook URL和一个Verification Token。先别急着复制——先回到飞书开放平台，在【事件订阅】页面，把这个URL填进去，同时在“Token”字段填入Verification Token。这一步的顺序不能颠倒：必须先在Coze里保存生成，再回飞书去填，否则飞书校验会直接返回400错误。

关键的验证动作来了：在飞书【事件订阅】页面点击【启用】之前，务必先点击【测试】按钮。如果提示“验证失败”，大概率是Coze侧尚未完成内部路由注册，等上大约90秒再重试。如果持续失败，检查一下飞书端的IP白名单是否已经添加了Coze云服务的出口IP段——官方文档没公开，但实测需要放行103.117.128.0/17和103.117.160.0/19这两个网段。

配置消息路由与意图分发逻辑

这里有两种方式可以选择。

方法一：使用Coze内置的“飞书消息触发器”节点。在Bot工作流中添加【Trigger】→选择【Feishu Message】→设置触发条件为“群消息”或“私聊消息”→连接后续的Bot逻辑节点。这个方式适合轻量级的问答场景，但缺点是不支持消息撤回、富文本卡片回调这类高级交互。

方法二：手动接入飞书事件回调，这个方法推荐用于审批类场景。在Coze中新建一个【HTTP Server】节点，把飞书事件订阅的URL指向这个节点地址，然后在节点内用JSON Path提取event.message.text字段，再用Switch节点判断关键词（比如“请假”“报销”“查工单”），分别路由到不同的Skill处理流。这个方法可以捕获飞书原生事件的全字段，包括sender.id、chat_id、msg_id，便于做幂等控制和状态追踪。

这里有个容易忽略的细节：飞书事件体中的text字段是base64编码的，而Coze的HTTP Server节点默认不会自动解码。你必须在后续的第一个Script节点中手动执行Buffer.from(event.message.text, ‘base64’).toString()，否则所有关键词匹配都会失效。

部署审批协同流程（含状态同步）

第一步：在飞书的多维表格中创建一张审批表，字段至少要包括：申请人、事由、开始时间、结束时间、状态（待审批/已通过/已拒绝）、审批人ID。

第二步：在Coze中创建一个“审批提交”Skill，接收用户的自然语言输入（比如“我要请三天假，从6月10号到12号”），用LLM抽取结构化参数，然后调用飞书API写入多维表格，拿到record_id。

第三步：配置飞书的【审批事件订阅】。在Coze中新增一个HTTP Server监听/approval/event，收到飞书推送的approval_result后，解析approval_result.status字段——如果是“approved”，就调用飞书API向申请人发送一张带绿色对勾图标和“已通过”文字的卡片消息；如果是“rejected”，就发送红色叉号卡片，并附上拒绝理由字段。

第四步：这里有个关键的补丁。飞书的审批事件默认不带申请人的飞书ID，只返回一个open_id。你必须在审批表中预先用飞书API查出申请人的user_id并写入辅助字段，否则后续的消息推送会因ID类型不匹配而直接失败。