飞书与腾讯会议自动化对接指南：从API集成到AI知识库的会议闭环

1. 为什么要把飞书和腾讯会议打通很多团队现在的办公现状是内部沟通、审批、文档全在飞书但开会用的却是腾讯会议。两边系统各自封闭导致一个特别常见又特别烦人的场景——明天上午十点要开周会负责拉会的人先要去飞书拉一个日程再跑到腾讯会议里创建一个会议拿到会议号和密码之后回到飞书群里复制粘贴给大家。会议开完纪要散落在腾讯会议的云录制里飞书文档里什么都没有下次想搜一下上次讨论的结论翻半天找不到。这种“双系统割裂”的问题本质上不是工具不好用而是缺少一座桥。把飞书和腾讯会议对接起来其实就是解决三件事一是把会议信息自动送达到位二是让飞书日程和腾讯会议互相联动三是把会后产生的录制、转写、文档沉淀回知识库。整个过程做下来团队可以少干大量重复劳动管理者也能把会议资产真正留存下来。这篇文章适合谁看如果你是企业内部的技术负责人、IT运维、数字化专员或者是独立开发者想帮自己的团队或者客户解决飞书和腾讯会议的联动问题那这篇文章刚好适合你。内容会从最简单的一条路讲起逐步深入到应用级API对接再讲到如何把腾讯会议的转写记录喂给AI知识库。每一条都有可以直接抄走的代码和步骤。需要提前说明的是飞书和腾讯会议的开放能力都在持续迭代文中的权限名称、API地址、回调格式以官方文档为准。实操时如果遇到字段对不上优先看官方开放平台的最新说明思路和排查方法是一样的。2. 先落地最轻的一条路飞书机器人推送会议通知不要一上来就想着把所有系统全部打通。对接的第一步优先解决“会议通知靠人肉复制”的痛点。最轻量、成本最低的做法就是通过飞书群机器人把会议信息自动推送到群里。2.1 飞书机器人从这里入手飞书群机器人本质上就是一个Webhook地址往这个地址发POST请求消息就会出现在群里。进入飞书群打开群设置找到“群机器人”添加一个自定义机器人飞书会给你一个形如https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxx的地址。建议添加机器人时把“签名校验”打开。开启后请求里需要带上根据时间戳和密钥算出来的签名飞书那边收到之后会做同款校验能防止别人拿你的Webhook地址乱发消息。签名算法的原理是取当前时间戳秒级拼上密钥字符串用HMAC-SHA256算法做哈希再把结果做Base64编码。Python实现如下import base64 import hashlib import hmac import time def gen_sign(timestamp: str, secret: str) - str: string_to_sign f{timestamp}\n{secret} hmac_code hmac.new( string_to_sign.encode(utf-8), digestmodhashlib.sha256 ).digest() return base64.b64encode(hmac_code).decode(utf-8) timestamp str(int(time.time())) secret 你的加签密钥 sign gen_sign(timestamp, secret)拿到签名后把timestamp和sign拼进请求体里再带上消息内容就能成功推送到群里。2.2 会议信息从哪来飞书机器人只负责“把消息送出去”会议信息本身还需要一个来源。这里有两条路如果公司已经开通了腾讯会议的企业版API权限就可以通过接口自动创建会议拿到会议号、密码、入会链接然后拼成消息发给机器人。这样完全不需要人工干预。如果暂时没有API权限退而求其次可以给团队配一个固定的个人会议号。约定好每周例会、每日站会都用这个会议号然后把会议号、密码、入会链接写死在消息模板里。这样虽然做不到“自动创建新会议”但也比每次开会前复制粘贴强得多。2.3 组合起来的效果把上面两块拼起来一个完整的“自动会议通知”流程就出来了某个定时任务比如每星期一早上九点触发脚本脚本调用腾讯会议API创建一场新会议或者直接读取固定会议号的配置然后组装成飞书消息卡片POST到群机器人的Webhook地址。我用的是飞书的“卡片消息”格式结构类似这样{ timestamp: 1715152000, sign: 生成的签名值, msg_type: interactive, card: { config: { wide_screen_mode: true }, header: { title: { tag: plain_text, content: 本周项目例会 }, template: blue }, elements: [ { tag: div, text: { tag: lark_md, content: **会议时间**2024-05-10 10:00\n**会议号**123 456 789\n**入会链接**[点击入会](https://meeting.tencent.com/dm/xxxx) } }, { tag: hr }, { tag: note, elements: [ { tag: plain_text, content: 消息由飞书-腾讯会议对接服务自动发送 } ] } ] } }消息发出后群成员直接在卡片里点链接就能入会不需要再在聊天记录里翻会议号。这个方案大概一个下午就能搞定建议作为所有对接工作的起点。3. 进阶通过应用级API实现双向联动群机器人解决的是“单向通知”但真正的办公闭环需要“双向联动”用户在飞书日程里创建一个日程系统自动创建腾讯会议并把会议链接写回日程会议结束时飞书自动收到通知把纪要归档。这一步就需要用到飞书开放平台的应用级能力和腾讯会议的云API能力了。3.1 准备飞书自建应用登录飞书开放平台创建一个企业自建应用。整个过程需要管理员权限这也是很多人在企业内部推不动的主要原因建议提前和IT管理员确认好权限范围。创建应用之后最关键的环节是申请权限。以“日程创建后触发创建会议”为例你需要申请这些权限calendar:calendar读取和写入日历信息calendar:calendar_event读取和写入日程事件contact:user.base:readonly读取用户基础信息用于拿到发消息的对象im:message发送消息到群或用户权限申请完之后在“事件订阅”里添加回调事件。这里要注意飞书的事件订阅地址必须是一个公网可以访问的HTTPS接口。本地调试推荐用内网穿透工具把本地服务暴露出去生产环境则建议部署在云函数或自己的服务器上。以“日程创建事件”为例飞书会在用户创建日程后向你的回调地址推送一个事件结构核心内容大致如下{ schema: 2.0, header: { event_id: xxxx, event_type: calendar.calendar_event.created, token: 校验令牌 }, event: { calendar_id: calendar_id_xxx, event_id: event_id_xxx, summary: 产品评审会, start_time: { timestamp: 1715152000 }, end_time: { timestamp: 1715155600 }, creator: { user_id: user_id_xxx } } }你的服务收到推送后先校验token再解析事件类型然后调用腾讯会议API创建会议最后把会议信息更新回这个日程的description字段里或者直接给创建人发一条私聊消息。3.2 准备腾讯会议云API接入腾讯会议的开放接口叫做“腾讯会议API”需要在腾讯会议官网的“高级服务-API接入”里申请。申请通过后你会拿到三类凭证会议商户IDapp_id、API Secret ID、API Secret Key。调用腾讯会议API时需要通过JWT进行认证。JWT的生成逻辑不难但坑比较多我在这里把完整的代码写出来import time import jwt import requests app_id 你的app_id secret_id 你的secret_id secret_key 你的secret_key def generate_jwt(): now int(time.time()) payload { app_id: app_id, iat: now, exp: now 600, jti: f{now}_{app_id}, } headers { alg: HS256, typ: JWT } token jwt.encode(payload, secret_key, algorithmHS256, headersheaders) return token def create_meeting(subject: str, start_time: int, end_time: int, user_id: str): jwt_token generate_jwt() url https://api.meeting.qq.com/v1/meetings headers { X-TC-Key: secret_id, X-TC-Token: jwt_token, Content-Type: application/json, X-TC-Registered-UserID: user_id, } body { subject: subject, type: 0, start_time: str(start_time), end_time: str(end_time), } resp requests.post(url, jsonbody, headersheaders) return resp.json()上面这段代码里X-TC-Registered-UserID是操作者身份。腾讯会议的API要求每次调用都要传一个注册用户的ID这个ID需要在腾讯会议企业里提前配置好。如果不传很多接口会直接返回“缺少用户信息”的错误。3.3 飞书日程一键拉起腾讯会议当飞书日程创建事件推送到你的回调服务后对应“飞书日程创建”事件完整的处理逻辑是拿到日程的标题、开始时间、结束时间、创建人信息调用腾讯会议API创建会议再把返回的会议号、入会链接追加到飞书日程的描述里并且给创建人发一条私聊卡片消息告诉他“会议已自动创建”。伪代码逻辑如下def handle_calendar_event_created(event): # 1. 解析日程信息 calendar_id event[calendar_id] event_id event[event_id] summary event[summary] start_ts int(event[start_time][timestamp]) end_ts int(event[end_time][timestamp]) creator_user_id event[creator][user_id] # 2. 调用腾讯会议API创建会议 meeting_info create_meeting( subjectsummary, start_timestart_ts, end_timeend_ts, user_idcreator_user_id ) if meeting_info.get(Error) is not None: # 创建失败发告警消息 send_error_message(creator_user_id, meeting_info) return meeting_id meeting_info[meeting_info_list][0][meeting_id] join_url meeting_info[meeting_info_list][0][join_url] # 3. 更新飞书日程描述 update_calendar_event(calendar_id, event_id, join_url, meeting_id) # 4. 私聊通知创建人 send_success_message(creator_user_id, summary, meeting_id, join_url)这个流程跑通之后用户只需要在飞书里建一个日程所有会议准备工作自动完成。这里有个小细节值得注意调用飞书API更新日程时需要拿到日程对应的user_access_token。如果是企业管理员场景可以用tenant_access_token代替但前提是应用授予了对应权限。3.4 腾讯会议状态回调到飞书另一层“联动”是反向的腾讯会议发生状态变化时把消息推回飞书。腾讯会议支持配置“Webhook回调”可以在会议开始、会议结束、参会人入会/离会等事件发生时向指定URL发起POST请求。具体配置路径是腾讯会议控制台-API接入-Webhook配置。配置时填上你自己的回调地址再设置一个回调的验证Token。腾讯会议向这个地址发起请求时会在Header里带一个验证字段你需要返回对应的应答才能完成握手。收到回调事件后最典型的应用场景是“会议结束自动归档”解析事件里的会议ID、会议主题、结束时间然后去腾讯会议API拉取本次会议的转写记录和录制文件存到飞书云文档里再往项目群里推送一条“会议已结束纪要和录制已归档”的消息。这种方式特别适合例会场景整个流程从开会到归档全员没有一个人手动参与。4. 会后收尾会议纪要进飞书云文档再喂给AI知识库会议开完真正的价值在于沉淀。腾讯会议的付费版提供了云录制和AI转写功能转写结果可以导出为文本或生成智能纪要。把这些内容同步到飞书云文档再接入AI知识库整个会议资产就能被检索、复用、问答这是很多团队落到一半就停住的地方也是整个对接方案里最有价值的一步。4.1 把转写记录转成飞书文档腾讯会议API里有一个“获取会议转写记录”的接口调用后会返回转写的文本内容。拿到文本后你可以直接调用飞书的“创建文档”API用内容创建一个新文档并把它放进指定的知识库文件夹。飞书创建文档的API路径是https://open.feishu.cn/open-apis/docx/v1/documents创建之后再通过/docx/v1/documents/{document_id}/blocks接口在文档里逐段添加内容。飞书文档的内容以block为单位每种block类型对应不同的渲染效果比如heading1是一级标题paragraph是正文段落bulletin是项目符号列表。这块在实现时有一个比较烦的点转写记录通常是整段对话文本没有结构。直接塞进飞书文档里就是一坨长文字可读性很差。建议在写入飞书文档之前先用简单的规则或者大模型把文本切成“议题-结论-待办”的结构再逐段写入。这一步做得好不好直接决定后面知识库的检索效果。4.2 dify首次使用飞书云文档的授权凭证怎么拿dify是一款开源的AI应用开发平台很多团队用它做知识库问答机器人。dify支持把飞书云文档作为知识库的数据源这也是网上提问最多的地方首次使用飞书云文档作为数据源时那个授权凭证到底去哪拿先说流程dify不是通过账号密码直接读取飞书文档的而是通过飞书开放平台的OAuth授权机制。你需要先在飞书开放平台创建应用可以复用前面创建的那个应用然后开启“云文档”相关的权限比如docx:document读取文档内容、drive:drive读取云空间文件。具体凭证获取步骤如下第一步在飞书开放平台找到你的应用进入“凭证与基础信息”页面记录下App ID和App Secret。第二步在“安全设置”里配置重定向URL。dify的知识库数据源页面会提供一个重定向地址通常类似https://你的dify域名/console/api/oauth/feishu/callback把它填到飞书的重定向URL里。第三步在dify的知识库-数据源页面选择“飞书云文档”页面会跳转到飞书的授权页你用自己的飞书账号登录确认授权。授权成功后飞书会把一个授权码code通过重定向URL传给difydify再用这个code去换token。第四步拿到token后dify会把它保存下来。之后你在dify里选择“按文档同步”或“按文件夹同步”就能把飞书云文档里的内容拉取到知识库里了。这个过程中最容易出错的两个地方一是重定向URL配置不一致浏览器地址栏里的URL和飞书后台配置的URL必须一模一样不能有末尾斜杠的差异二是权限范围不足如果应用只申请了“读取文档内容”权限没有申请“读取云空间文件列表”权限按文件夹同步时就会报403。4.3 搭一个基于AI大模型的全栈知识库当会议纪要进入飞书云文档后配合dify可以把整个知识库做成一个“会议问答机器人”。团队成员在飞书群里机器人问一句“上周客户评审会结论是什么”机器人会在知识库里检索相关内容再调用大模型生成回答。这是目前很多团队在实践的“AI大模型全栈知识库”落地方式。实现路径很简单在dify里创建一个知识库应用数据源选择飞书云文档设置好索引方式建议开启向量索引也就是语义检索然后再接入一个飞书机器人作为发布渠道把应用绑定到目标群里。整体架构是这样的飞书云文档作为会议纪要的统一存储层腾讯会议的转写记录作为文档内容的生产来源dify的“飞书云文档”数据源定时把新增文档同步到向量数据库大模型负责根据用户问题检索并生成回答飞书机器人作为最终的交互入口这里有个细节dify的“定时同步”频率不要太低也不要太高。文档数量多的团队建议一小时同步一次如果知识库只有几十份文档可以手动触发没必要占用系统资源。同步到dify后会议纪要从“存放”升级为“可以回答问题”你能直接用自然语言从历史会议里提取信息。5. 踩坑实录几个最常翻车的地方对接过程中踩坑是必然的关键是踩完之后要能总结出一套排查方法。下面这几个问题几乎每个做飞书-腾讯会议对接的团队都会遇到建议大家先收藏。5.1 腾讯会议不能使用电脑自带摄像头吗这个热搜词说明很多人在用腾讯会议时都遇到过摄像头打不开的问题。对接场景下这个问题通常出现在回调服务自动启动腾讯会议客户端时摄像头权限没被正确授予。排查思路是这样的先确认腾讯会议客户端本身的摄像头设置——进入设置-视频看是否能预览到画面如果预览正常再看操作系统层面是否禁止了腾讯会议使用摄像头Windows和macOS都需要检查。如果是通过API创建的会议与会者从入会链接进入会议后摄像头没画面多数情况是浏览器权限问题。用Chrome入会时要确保浏览器弹窗允许使用摄像头而且不能有别的应用程序比如另一个会议客户端占用了摄像头。这个排查顺序基本能覆盖大多数“摄像头打不开”的场景如果是企业内部批量推送安装的腾讯会议建议检查一下系统级权限策略。5.2 飞书机器人加签消息报“签名校验失败”这个报错的原因主要有两个。第一是时间戳不准确飞书校验时会取服务器当前时间和你传的timestamp做对比误差超过一定范围会直接拒绝所以确保生成签名用的time.time()和请求发出的时间间隔不要太大。第二是密钥本身填错了签名用的不是Webhook地址里的那串而是加签设置里独立生成的密钥不要搞混。还有一个小坑有些语言在计算HMAC-SHA256时直接把string_to_sign传成bytes会翻车要先编码成UTF-8。这个错误报出来的现象各不相同Java和Go里都会出现签名不一致但Python里很少遇到因为hmac.new会自动处理编码。如果签名校验一直失败先把最终发送的timestamp、sign打印出来用官方提供的调试工具比对一下基本五分钟内能定位。5.3 飞书事件订阅一直收不到推送飞书的事件订阅回调要求你的服务端必须在收到请求后的3秒内返回HTTP 200否则飞书会认为推送失败然后按照重试策略再次推送。如果你在回调逻辑里同步调用了腾讯会议API创建会议而腾讯会议API响应缓慢就可能超过3秒导致飞书判定失败。解决办法是引入消息队列。回调接口收到事件后先把事件内容放进队列立刻返回200然后由后台Worker异步处理后续业务。这样做还有个好处即使腾讯会议API临时不可用事件数据留在队列里等系统恢复后还能重试不丢消息。另外事件订阅里有一个“请求地址”的校验机制配置回调地址时飞书会发一个带有challenge字段的验证请求你的服务端必须原样返回这个challenge配置才能保存成功。很多人在这里就卡住了返回了JSON但格式不对飞书会提示“校验失败”。5.4 腾讯会议API返回401或403401表示认证失败优先检查JWT是否正确。JWT的iat和exp必须覆盖当前时间时间偏差不要超过5分钟jti虽然是可选字段但官方建议加上有些接口会校验它的唯一性。403表示权限不足常见情况是X-TC-Registered-UserID指定的用户没有购买API服务或者没有开启某个接口对应的功能。换一个有权限的用户ID试试。5.5 dify授权飞书云文档后仍然报错配置好授权凭证后dify同步飞书文档时报错的常见原因有两个。一个是按文件夹同步时文件夹里包含了一些权限受限的文件飞书API在遍历文件列表时会返回403dify会把这个错误直接抛出来。解决办法是把需要同步的文档统一挪到一个权限开放的文件夹里避免混装。另一个是文档本身是评论区的、或者其他人共享过来的你的应用没有该文档的权限。可以在飞书云文档里右键文档把它分享给你的应用管理员账号再重新触发同步。6. 几个实际操作中的经验建议整个对接流程走下来有几个建议值得单独说一说。第一个建议是分层推进不要毕其功于一役。先做群机器人通知跑通之后再做应用级API最后再做知识库闭环。每一步都要让团队真实用起来用出效果再往前走下一步。很多项目失败不是因为技术方案不行而是因为一次引入太多变化团队接受不了。第二个建议是权限最小化。无论是飞书应用还是腾讯会议API给应用授予的权限越少越好。原则上只申请业务必须的权限不要图省事直接勾选全部。权限越大安全上的风险就越高尤其是飞书的云文档权限一旦泄露意味着整个知识库内容都能被外部读取这个代价是任何团队都承受不起的。第三个建议是幂等性设计。飞书事件订阅、腾讯会议Webhook都有重试机制如果你的回调处理逻辑没有做幂等可能会出现同一个日程被创建了多个腾讯会议、同一个会议被归档了两次的情况。幂等的一般做法是在业务表里维护一个唯一键比如飞书日程的event_id处理前先查一下是否已经处理过处理过就直接跳过。第四个建议是真机上一定要测异常链路。别只测顺利流程重点测腾讯会议API超时、飞书文档权限失效、Webhook重复推送这些边界情况。我在实际项目里遇到过一次腾讯会议API上午还好好的下午就一直超时原因是腾讯会议那边在升级好在当时做了超时重试和异常消息推送否则用户会以为自己的日程创建逻辑出了问题实际上服务端已经降级处理了。最后一个建议是关于文档同步频率的。飞书云文档数据源刚接入dify时不要同步得太频繁建议先同步全部文档然后设置每日增量同步。如果团队每天产生的会议纪要超过几十份还可以把同步时间放在晚上避开办公高峰这样也不会影响到正常使用飞书的体验。对接飞书和腾讯会议这件事本质上不是在写代码而是在梳理团队的协作流程。先把“通知-开会-归档-检索”这条链路想清楚再动手写代码你会发现每一步其实都没有想象中那么复杂。做出来的东西哪怕只是省掉了每天复制粘贴会议号这一步对团队来说也已经是肉眼可见的效率提升。