2026/9/16 2:02:51
FEATURED · 精选文章 
先说个场景上周行政同事又来找我说每天晨会前要手动复制腾讯会议链接发到飞书群还要一个个补写会议号既慢又容易漏。我听完第一反应是这事明明可以全自动——飞书群里发一句指令机器人调用腾讯会议接口把会建好再把会议号、入会链接、密码一键甩回群聊。说干就干从拉通两边开放平台到上线跑了三天今天把完整对接过程整理出来希望能帮到同样在飞书和腾讯会议之间来回切换的团队。这篇内容面向的是有基础开发能力、需要把飞书机器人和腾讯会议API串联起来的同学也适合想给团队做会议自动化的运维或业务同学参考。你会看到完整的方案设计、平台配置、后端代码示例、常见踩坑点以及我基于这次实践总结出来的几条经验。核心思路就一句话让飞书当入口后端当大脑腾讯会议API当执行者。1. 对接思路飞书和腾讯会议到底怎么“接”才不别扭1.1 先想清楚你真正想要的是什么很多人一上来就问“飞书和腾讯会议怎么对接”其实“对接”这个词太模糊了。你要先想清楚这个对接是为了解决什么具体问题。我这边真实的需求归纳下来无非三类第一类是“创建会议太麻烦”。以前建一个腾讯会议要去客户端点新建、设置主题、选时间、复制链接然后回到飞书群里粘贴全程至少两分钟。如果一天有三五场会时间成本和工作负担都很明显。第二类是“提醒总是漏”。会议约好了但没人记得提前五分钟提醒大家进入总有人迟到。第三类是“没有会议台账”。过去开了什么会、谁参加的、会议号是多少都没地方查月底统计无从下手。所以对接的本质是用一条自动化链路把这三件事一次做完用户在飞书触发动作后端自动调腾讯会议API创建会议再把结果回写到飞书群和飞书文档里。想明白这一点后面的方案设计就顺了。1.2 两条主流对接链路机器人指令驱动与表格事件驱动我调研下来目前大家常用的对接方式主要有两种。一种是机器人指令驱动。用户在飞书群里机器人输入类似“创建会议 14:00 产品周会”飞书事件订阅把这条消息推给后端服务后端解析指令、调用腾讯会议开放接口建会然后把会议链接和会议号发回群里。这种方式最直观适合临时、高频的建会需求也是我最终采用的方案。另一种是表格事件驱动。在飞书多维表格里建一张“会议申请表”用户在里面填一行会议主题、开始时间、参会人。通过飞书开放平台的监听能力当表格新增记录时触发后端服务后端自动创建会议并把生成的会议号写回表格。这种方式适合有固定预约流程、需要留痕的团队比如对外接待、客户沟通会议。两种方式不冲突甚至可以并联。我建议先做机器人指令驱动因为它见效最快、最能直观感受到自动化的价值表格驱动可以放到第二阶段再做。1.3 方案选型为什么我选“飞书机器人后端服务腾讯会议API”可能有人会问飞书不是有“飞书会议”吗为什么还要绕一圈去对接腾讯会议这个问题我犹豫过但实际团队里大家用腾讯会议的习惯已经固定很多外部客户、合作伙伴也只认腾讯会议入口。与其强制迁移工具不如把两个生态打通让用户停留在飞书界面就能完成腾讯会议的操作。具体到技术实现有三个可选路径一是纯手工操作彻底out不做讨论。二是用飞书自带的应用或集成市场里的现成应用。我试过几个要么只能单向跳转、要么配置自由度太低对自定义指令、自定义提醒、自定义台账这些需求支持得很差。三是自建后端服务通过两边开放平台的API做中间桥接。我选了第三种。虽然不是最省事的但胜在完全可控指令格式可以自己定、会议属性可以自己拼、后续要加提醒或写台账也有基础。整个链路就是一个标准的事件驱动架构飞书事件订阅 - 后端服务 - 腾讯会议API - 回写飞书群/多维表格。后端用什么语言不重要Python、Java、Node都行关键是理解两边的认证方式和核心接口。2. 环境准备两边开放平台的账号与应用配置2.1 飞书开放平台侧企业自建应用、机器人、事件订阅与权限飞书这边的准备工作核心是在飞书开放平台创建一个企业自建应用。打开 open.feishu.cn用管理员账号登录进入开发者后台点击“创建企业自建应用”填好应用名称和描述后你会拿到两个关键凭证App ID 和 App Secret。这两个值后面获取访问令牌时要用建议直接放到后端的环境变量里不要硬编码在代码中。创建完应用后第一件事是开启“机器人”能力。在应用功能里找到“机器人”开启后这个应用就有了在群聊中收发消息的权限。然后配置“事件订阅”这一步是飞书把群聊消息推送给后端服务的通道你需要填一个后端可公网访问的请求地址比如 https://yourdomain.com/feishu/callback同时设好 Encrypt Key 和 Verification Token。我踩过的第一个坑就在这里——事件订阅的URL必须能公网访问本地调试阶段可以用内网穿透工具临时暴露一个地址但生产环境一定要用正式域名。权限申请是整个飞书配置里最容易卡壳的环节。机器人接收消息需要开通im:message相关权限发送消息需要im:message:send_as_bot读取用户基本信息需要contact:user.base:readonly。这些权限可以在“权限管理”里搜索对应英文标识并申请管理员审核通过后才会生效。我当时漏了发送消息的权限导致机器人能收到消息但回复不出去排查了很久才发现是权限问题。所以建议在开始写代码前就把下面这些权限一次性都申请好im:message接收群聊中机器人的消息im:message:send_as_bot以机器人身份发送消息contact:user.base:readonly读取用户基础信息用于成员bitable:app读写多维表格后面做台账会用到docx:document读写云文档涉及ai工具时要授权2.2 腾讯会议开放平台侧企业应用、凭证与API权限腾讯会议这边需要进入腾讯会议开放平台。用企业管理员账号登录后在“应用管理”里创建一个“企业应用”创建完成后会得到 Client ID 和 Client Secret这两项相当于腾讯会议侧的密钥。跟飞书类似也需要配置服务器的公网IP白名单只有白名单内的IP才能调用腾讯会议的接口。应用创建后需要申请调用会议相关API的权限。我当时用的是企业级应用鉴权方式也就是通过 Client ID 和 Client Secret 换取 access_token这种方式适合服务端调用不需要每个用户单独授权。创建会议对应的API是“创建会议”申请权限后可以在开放平台的“API文档”里看到完整的请求参数和示例代码。有一点要特别注意腾讯会议的开放平台文档经常更新不同版本的字段名可能会有调整。比如创建会议接口在某个版本里主题字段叫topic在另一个版本里可能叫subject时间字段有的用秒级时间戳有的用毫秒级。我建议正式开发前先打开最新版的API文档把所有要用到的字段名核对一遍再开始写代码。另外腾讯会议的接口调用有频次限制如果短时间内高频创建会议会被限流后面上线时一定要考虑重试机制。2.3 理解两边的Token体系token有效期与刷新机制飞书和腾讯会议的Token体系都有一个共同点都是通过密钥换取短期有效的访问令牌过期后需要重新获取。飞书侧有两类Token一类是tenant_access_token代表应用身份适合服务端调用另一类是user_access_token代表某个用户的身份需要走OAuth授权流程适合代替用户发起操作。做机器人和会议对接基本上用tenant_access_token就够了。获取方式很简单拿 App ID 和 App Secret 请求飞书的/open-apis/auth/v3/tenant_access_token/internal接口返回的tenant_access_token有效期通常是2小时不同版本可能不同过期后重新请求即可。腾讯会议侧的 access_token 是通过 Client ID 和 Client Secret 换取的系统级Token有效期比较短我记得当时实现时大概是几十分钟到一小时。所以代码里要做成“获取前先检查是否过期”的缓存策略而不是每次请求都重新获取。我见过有人每调一次接口就换一次Token既浪费请求次数又容易被限流。3. 核心实现从“群里发指令”到“自动创建会议并回发链接”3.1 整体调用流程先用一句话讲清楚整个调用流程可以拆成六步每一步都不复杂串起来就形成了一个完整的自动化闭环用户在飞书群聊中机器人并发送指令例如“创建会议 15:00 项目评审”。飞书开放平台将这条消息通过事件订阅推送给后端服务。后端解析消息内容提取会议主题、时间等参数。后端携带腾讯会议 access_token调用创建会议接口。腾讯会议返回会议号、入会链接等信息。后端将这些信息通过飞书机器人API发送回群聊。这里需要提醒的是第1步“机器人”是触发前提——机器人默认只会收到被的消息。如果希望机器人响应群里所有消息需要在事件订阅配置里开启相应选项但这个容易误触发不建议默认开启。3.2 获取飞书令牌与接收消息事件的代码示例先来看飞书侧的两个基础能力获取tenant_access_token和接收事件回调。下面的代码基于Python的 requests 库核心逻辑就是一个HTTP请求加一个JSON解析非常简单。我先写一个获取飞书访问令牌的函数import requests import json import time APP_ID your_feishu_app_id APP_SECRET your_feishu_app_secret FEISHU_TOKEN_URL https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal token_cache { token: None, expire_at: 0 } def get_feishu_tenant_token(): now time.time() if token_cache[token] and now token_cache[expire_at] - 60: return token_cache[token] resp requests.post(FEISHU_TOKEN_URL, json{ app_id: APP_ID, app_secret: APP_SECRET }) data resp.json() if data.get(code) ! 0: raise Exception(f获取飞书token失败: {data}) token_cache[token] data[tenant_access_token] token_cache[expire_at] now data[expire] return token_cache[token]这个函数用了简单的内存缓存避免每次请求都去换取令牌。缓存时间上留了60秒余量防止令牌刚好在请求途中过期。然后是接收飞书消息事件的回调。飞书会把事件以POST请求推送到你配置的URL请求体里包含事件类型和消息内容。对于im.message.receive_v1事件核心字段在event.message.content里内容是JSON字符串里面包含消息文本。from flask import Flask, request, jsonify app Flask(__name__) app.route(/feishu/callback, methods[POST]) def feishu_callback(): body request.json # 飞书事件订阅验证首次配置URL时需要响应 challenge if body.get(type) url_verification: return jsonify({challenge: body.get(challenge)}) # 处理消息事件 if body.get(header, {}).get(event_type) im.message.receive_v1: event body.get(event, {}) message event.get(message, {}) content message.get(content, {}) chat_id message.get(chat_id) # content 是JSON字符串需要解析 import json as json_lib content_data json_lib.loads(content) text content_data.get(text, ) # 在这里解析指令调用腾讯会议API创建会议然后回复消息 handle_message(chat_id, text) return jsonify({code: 0})3.3 获取腾讯会议Token并创建会议代码实战拿到飞书消息后下一步就是解析指令并调用腾讯会议API。先写获取腾讯会议 access_token 的函数。腾讯会议开放平台的Token接口可以用 GET 或 POST 获取关键参数是 Client ID 和 Client Secret我当时用的形式是TENCENT_CLIENT_ID your_tencent_client_id TENCENT_CLIENT_SECRET your_tencent_client_secret TENCENT_TOKEN_URL https://api.meeting.qq.com/v1/oauth2/access_token tencent_token_cache { token: None, expire_at: 0 } def get_tencent_access_token(): now time.time() if tencent_token_cache[token] and now tencent_token_cache[expire_at] - 60: return tencent_token_cache[token] resp requests.post(TENCENT_TOKEN_URL, json{ client_id: TENCENT_CLIENT_ID, client_secret: TENCENT_CLIENT_SECRET, grant_type: client_credentials }) data resp.json() if data.get(code) ! 0: raise Exception(f获取腾讯会议token失败: {data}) tencent_token_cache[token] data[access_token] tencent_token_cache[expire_at] now data[expires_in] return tencent_token_cache[token]创建腾讯会议的接口是/v1/meetings请求方式为POST需要在请求头加上Authorization: Bearer {access_token}。请求体里常见的参数有会议主题、开始时间、结束时间、会议密码等。当时我用到的核心参数如下def create_tencent_meeting(topic, start_time_ts, end_time_ts, password): token get_tencent_access_token() url https://api.meeting.qq.com/v1/meetings headers { Authorization: fBearer {token}, Content-Type: application/json } payload { topic: topic, type: 0, # 0表示预约会议1表示立即开会 start_time: start_time_ts, # 注意单位通常是毫秒时间戳 end_time: end_time_ts, password: password } resp requests.post(url, jsonpayload, headersheaders) data resp.json() if data.get(code) ! 0: raise Exception(f创建腾讯会议失败: {data}) meeting_info data.get(meeting_info_list, [{}])[0] return { meeting_id: meeting_info.get(meeting_id), meeting_code: meeting_info.get(meeting_code), join_url: meeting_info.get(join_url) }创建成功后接口会返回类似meeting_code入会号码、meeting_id会议唯一标识、join_url入会链接这些字段。我在实际调用时发现有的字段名在不同接口版本里有差异所以拿到返回结果后建议先打印一遍完整JSON核对字段名再继续写下游逻辑。3.4 把会议信息回写到飞书群文本消息与卡片消息怎么选腾讯会议创建成功后剩下最后一步把结果发回飞书群。飞书机器人发送消息的接口是POST /open-apis/im/v1/messages需要传接收对象ID、消息类型和消息内容。具体有两个选择。最简单的是发送文本消息msg_type为textcontent 是普通文本。优点是实现快缺点是会议链接、会议号、密码都挤在一起阅读体验一般。我当时上线第一版用的就是文本消息群里长这样会议已创建成功 主题产品周会 时间15:00 会议号123456789 入会链接https://meeting.tencent.com/dm/xxxx 入会密码123456另一种是发送交互卡片msg_type为interactive卡片支持标题、字段、按钮用户可以直接点击链接入会体验好很多。缺点是构造JSON比较繁琐卡片格式要先在飞书开放平台的“消息卡片搭建工具”里调试好再套进代码。我的建议是第一版先用文本消息把流程跑通跑通之后再升级成卡片不要一上来就纠结UI。发送消息的代码大致长这样def send_feishu_message(chat_id, text): token get_feishu_tenant_token() url https://open.feishu.cn/open-apis/im/v1/messages?receive_id_typechat_id headers { Authorization: fBearer {token}, Content-Type: application/json } payload { receive_id: chat_id, msg_type: text, content: json.dumps({text: text}, ensure_asciiFalse) } resp requests.post(url, jsonpayload, headersheaders) data resp.json() if data.get(code) ! 0: raise Exception(f发送飞书消息失败: {data})3.5 参数与边界时间戳、时区、入会密码、重复会议创建会议看似简单参数里其实藏着不少坑。第一个是时间戳单位。飞书传入的消息里如果带时间可能是“15:00”这种可读格式也可能是标准时间但腾讯会议API通常要求毫秒级时间戳。我当时的做法是先让用户在指令里写“15:00”后端解析成当天的datetime再转成毫秒时间戳传给腾讯会议。如果解析失败或者时间早于当前时间就直接报错并提示用户重新输入。第二个是时区。腾讯会议API对时区敏感如果你传的是一个不带时区信息的本地时间接口可能会按UTC处理导致创建出来的会议时间差八个小时。我的处理方式是在创建会议的请求体里显式加上timezone字段一般填“Asia/Shanghai”这样无论服务器部署在哪里会议时间都以北京时间计算。第三个是入会密码。腾讯会议可以自动生成入会密码也可以在创建时指定。我建议在创建时传一个六位数字密码方便后续把密码和会议号一起发给参会人。如果不传接口也会返回一个随机密码但你得在返回结果里多取一个字段。第四个是重复会议。腾讯会议支持按天、按周重复的周期性会议创建时传recurrence_rule相关参数即可。但这个功能我这次没有实现到指令里因为指令解析多做一层复杂度收益有限真要排重复例会走表格驱动的链路更合适。4. 进阶玩法对接之后的自动化与数据闭环4.1 用多维表格当会议台账创建记录自动入库基础链路跑通后你会发现新问题会议信息只存在于聊天记录里想查历史会议还是要翻群消息效率很低。这时候就可以引入飞书多维表格把所有创建过的会议沉淀为结构化数据。具体的做法是在飞书里提前建一张多维表格字段包括会议主题、开始时间、会议号、入会链接、创建人、状态等。后端在创建腾讯会议成功后同时调用飞书多维表格的API往表格里追加一条记录。这样每次开会前、开会后你都可以到表格里查看所有历史会议甚至可以按日期筛选、按创建人统计。飞书多维表格的API看着复杂其实本质就是往指定数据表里插入记录。需要用到多维表格的 App Token 和 Table ID这两个值可以在多维表格的URL里找到。插入记录用POST /open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records请求体里放你要写入的字段值。我当时还做了一个小优化创建会议失败时也在表格里插一条记录但状态标记为“失败”后面排查问题有据可查。4.2 定时任务会议前15分钟自动提醒会议建好了台账也有了下一步是解决“忘记开会”的问题。做法是用一个定时任务每分钟扫描多维表格里未来24小时内的会议记录如果发现某场会议距开始时间还有15分钟就在对应群聊里发一条提醒消息。这个功能实现起来并不复杂难的是“这个会议应该提醒谁、提醒到哪个群”这个关系怎么建立。我当时在创建会议的指令里加了一个可选的名单字段比如“创建会议 15:00 产品周会 张三”解析指令时识别出被的用户会议记录里就保存这些用户ID。定时任务触发提醒时调用飞书API直接通过open_id发单聊消息给参会人比在群里全体提醒更精准。还有一点值得注意定时任务本身要考虑时区问题。服务器如果部署在国外一定要用北京时间来比较时间。我当初就因为这个吃过亏提醒总是提前八小时触发后来统一用Asia/Shanghai时区做时间比较才解决。4.3 审批流触发飞书审批通过后自动建会如果你的团队开会需要走审批流程比如对外接待会议、大型会议需要领导批准那可以把这个对接再升级一层把“创建会议”这个动作从用户主动发起改成审批通过后自动触发。飞书有审批应用审批通过后可以通过事件订阅把结果推送给后端。后端收到审批通过事件后解析审批里的会议主题、时间、参会人字段调用腾讯会议创建接口再把会议信息发回发起人。这样就实现了“申请 - 审批 - 自动建会 - 通知到位”的完整闭环。这个方案的配置工作量主要在飞书审批侧你要设计一个审批表单加好“会议主题”“开始时间”“结束时间”这些字段然后在审批设置里配置Webhook或事件订阅。后端代码逻辑本身和前面的机器人指令驱动大同小异主要区别是数据来源从消息内容变成了审批表单字段。如果你团队已经重度使用飞书审批我非常推荐这个进阶方案。4.4 顺带解决的问题Dify等AI工具如何获得飞书云文档授权凭证对接过程中还有个小插曲团队当时正在试Dify做AI知识库想把飞书云文档作为知识源但Dify配置飞书云文档授权时一直卡在凭证环节。其实原理和前面讲的完全一样——Dify需要的是飞书开放平台里某个应用的 App ID 和 App Secret并且这个应用必须开通云文档相关的读取权限。如果你遇到了同样的问题操作路径是在飞书开放平台创建一个应用权限管理里申请docx:document云文档读取相关的权限审核通过后把 App ID 和 App Secret 填到Dify的知识库或工具配置里。注意Dify走的是应用身份读取文档所以文档要对该应用可见或至少授予该应用访问权限。我当时是把这个应用加到了云文档的协作者列表里才解决了“有凭证但读不到文档”的问题。这个经验放在这里算是对接飞书生态时的一个附赠福利。5. 上线前必须知道的坑常见问题与排查实录5.1 常见问题速查表先收藏再看我把实际运行中遇到的问题整理成了表格每个问题都标了现象、原因和解决方案方便你直接照着排查。问题现象可能原因排查方向与解决方案飞书收不到机器人消息机器人能力未启用或未授予发消息权限检查应用功能里机器人开关权限管理里确认 im:message:send_as_bot 已审批通过机器人能收消息但无法回复发送消息权限缺失申请并等待im:message:send_as_bot权限审核通过飞书事件订阅一直验证失败回调URL公网不可访问或 Encrypt Key 不匹配确认URL能从公网访问用Postman手动请求回调地址检查Verification Token 与 Encrypt Key腾讯会议接口返回鉴权失败access_token 过期或未正确传入请求头检查Token是否缓存过期确认请求头格式为 Bearer {token}创建会议时间差8小时未显式设置时区接口按UTC处理创建会议请求参数里显式加 timezone 字段值为 Asia/Shanghai创建会议接口报权限不足应用未申请创建会议API权限到腾讯会议开放平台检查应用API权限重新提交申请机器人提示未知指令指令解析逻辑不匹配打印收到的原始消息内容核对文本里的空格、符号、大小写5.2 排查事件回调的三个环节飞书事件回调是整条链路里最容易出问题的环节一旦消息推不过来后面全卡住。按照我排查的经验事件回调出问题就查三个地方。第一看请求是否到达服务器。配置好事件订阅后先在后端日志里打印所有POST请求。如果一条都没进来说明飞书根本没把消息推到你服务器上问题在回调地址配置或公网访问层面。这时候检查域名解析、端口、HTTPS证书三项是否正常。第二看请求是否通过校验。飞书事件订阅有URL验证机制首次配置时会发一个带 challenge 的验证请求服务器必须原样返回 challenge 才能通过验证。很多新手卡在这里原因是返回的JSON结构不对或者没有正确取出 challenge 字段。第三看消息事件是否被正确处理。飞书推送的消息事件类型是im.message.receive_v1但如果机器人没有被这个事件可能压根不会推送。我调试时曾以为代码写错了折腾半天才发现是没在群里机器人。事件回调联调阶段建议先创建一个只有机器人和你的测试群避免干扰。5.3 时间与权限相关的几个隐蔽坑除了表格里列的常见问题还有几个隐蔽坑我写在最后提醒一下。第一个是权限生效时间。飞书的权限申请通过后不一定立刻生效。我遇到过权限状态显示“已通过”但调用接口还是报权限错误偶尔要等几分钟甚至重新发布应用版本才生效。所以不要刚通过权限就急着上线先在测试环境验证一遍再说。第二个是接口频控。腾讯会议API有调用频次限制单次创建会议还好但如果你写了一个循环批量创建会议很容易触发限流。建议在代码里加重试机制当接口返回限流错误时退避一段时间再试。第三个是日志的重要性。两边接口的返回结构都比较标准出问题时响应里通常有 code 和 message 字段。务必在代码里把每一步的请求URL、请求参数、返回结果都打印出来尤其是生产环境。很多问题靠看日志一眼就能定位省去反复猜测的时间。第四个是关于IP白名单。腾讯会议开放平台通常要求配置服务器公网IP白名单如果你在公司内网开发IP会经常变动导致调试时频繁出现鉴权失败。我当时的方法是开发阶段用公司出口IP上线前再切换成生产服务器IP两边都加到白名单里避免来回改。写在最后的一点体会这次飞书和腾讯会议的对接技术上并不算高深但整个过程中让我最深的体会是企业工具之间的“打通”难点从来不在API本身而在于对业务场景的理解和对细节的耐心。从“群里发指令”到“自动建会”再到“台账沉淀”每一步都不难但串起来之后对整个团队会议效率的提升是实实在在的。最后再分享一个实用小技巧如果你和我一样用Python写这个对接建议把所有外部接口调用都封装成独立函数并把Token获取统一加一个缓存装饰器。这样后续无论是加提醒功能、加审批触发还是换一个会议服务商改动成本都会小很多。代码跑通不是终点能稳定维护才是。
飞书机器人对接腾讯会议API：从群指令到自动建会全流程实践
先说个场景上周行政同事又来找我说每天晨会前要手动复制腾讯会议链接发到飞书群还要一个个补写会议号既慢又容易漏。我听完第一反应是这事明明可以全自动——飞书群里发一句指令机器人调用腾讯会议接口把会建好再把会议号、入会链接、密码一键甩回群聊。说干就干从拉通两边开放平台到上线跑了三天今天把完整对接过程整理出来希望能帮到同样在飞书和腾讯会议之间来回切换的团队。这篇内容面向的是有基础开发能力、需要把飞书机器人和腾讯会议API串联起来的同学也适合想给团队做会议自动化的运维或业务同学参考。你会看到完整的方案设计、平台配置、后端代码示例、常见踩坑点以及我基于这次实践总结出来的几条经验。核心思路就一句话让飞书当入口后端当大脑腾讯会议API当执行者。1. 对接思路飞书和腾讯会议到底怎么“接”才不别扭1.1 先想清楚你真正想要的是什么很多人一上来就问“飞书和腾讯会议怎么对接”其实“对接”这个词太模糊了。你要先想清楚这个对接是为了解决什么具体问题。我这边真实的需求归纳下来无非三类第一类是“创建会议太麻烦”。以前建一个腾讯会议要去客户端点新建、设置主题、选时间、复制链接然后回到飞书群里粘贴全程至少两分钟。如果一天有三五场会时间成本和工作负担都很明显。第二类是“提醒总是漏”。会议约好了但没人记得提前五分钟提醒大家进入总有人迟到。第三类是“没有会议台账”。过去开了什么会、谁参加的、会议号是多少都没地方查月底统计无从下手。所以对接的本质是用一条自动化链路把这三件事一次做完用户在飞书触发动作后端自动调腾讯会议API创建会议再把结果回写到飞书群和飞书文档里。想明白这一点后面的方案设计就顺了。1.2 两条主流对接链路机器人指令驱动与表格事件驱动我调研下来目前大家常用的对接方式主要有两种。一种是机器人指令驱动。用户在飞书群里机器人输入类似“创建会议 14:00 产品周会”飞书事件订阅把这条消息推给后端服务后端解析指令、调用腾讯会议开放接口建会然后把会议链接和会议号发回群里。这种方式最直观适合临时、高频的建会需求也是我最终采用的方案。另一种是表格事件驱动。在飞书多维表格里建一张“会议申请表”用户在里面填一行会议主题、开始时间、参会人。通过飞书开放平台的监听能力当表格新增记录时触发后端服务后端自动创建会议并把生成的会议号写回表格。这种方式适合有固定预约流程、需要留痕的团队比如对外接待、客户沟通会议。两种方式不冲突甚至可以并联。我建议先做机器人指令驱动因为它见效最快、最能直观感受到自动化的价值表格驱动可以放到第二阶段再做。1.3 方案选型为什么我选“飞书机器人后端服务腾讯会议API”可能有人会问飞书不是有“飞书会议”吗为什么还要绕一圈去对接腾讯会议这个问题我犹豫过但实际团队里大家用腾讯会议的习惯已经固定很多外部客户、合作伙伴也只认腾讯会议入口。与其强制迁移工具不如把两个生态打通让用户停留在飞书界面就能完成腾讯会议的操作。具体到技术实现有三个可选路径一是纯手工操作彻底out不做讨论。二是用飞书自带的应用或集成市场里的现成应用。我试过几个要么只能单向跳转、要么配置自由度太低对自定义指令、自定义提醒、自定义台账这些需求支持得很差。三是自建后端服务通过两边开放平台的API做中间桥接。我选了第三种。虽然不是最省事的但胜在完全可控指令格式可以自己定、会议属性可以自己拼、后续要加提醒或写台账也有基础。整个链路就是一个标准的事件驱动架构飞书事件订阅 - 后端服务 - 腾讯会议API - 回写飞书群/多维表格。后端用什么语言不重要Python、Java、Node都行关键是理解两边的认证方式和核心接口。2. 环境准备两边开放平台的账号与应用配置2.1 飞书开放平台侧企业自建应用、机器人、事件订阅与权限飞书这边的准备工作核心是在飞书开放平台创建一个企业自建应用。打开 open.feishu.cn用管理员账号登录进入开发者后台点击“创建企业自建应用”填好应用名称和描述后你会拿到两个关键凭证App ID 和 App Secret。这两个值后面获取访问令牌时要用建议直接放到后端的环境变量里不要硬编码在代码中。创建完应用后第一件事是开启“机器人”能力。在应用功能里找到“机器人”开启后这个应用就有了在群聊中收发消息的权限。然后配置“事件订阅”这一步是飞书把群聊消息推送给后端服务的通道你需要填一个后端可公网访问的请求地址比如 https://yourdomain.com/feishu/callback同时设好 Encrypt Key 和 Verification Token。我踩过的第一个坑就在这里——事件订阅的URL必须能公网访问本地调试阶段可以用内网穿透工具临时暴露一个地址但生产环境一定要用正式域名。权限申请是整个飞书配置里最容易卡壳的环节。机器人接收消息需要开通im:message相关权限发送消息需要im:message:send_as_bot读取用户基本信息需要contact:user.base:readonly。这些权限可以在“权限管理”里搜索对应英文标识并申请管理员审核通过后才会生效。我当时漏了发送消息的权限导致机器人能收到消息但回复不出去排查了很久才发现是权限问题。所以建议在开始写代码前就把下面这些权限一次性都申请好im:message接收群聊中机器人的消息im:message:send_as_bot以机器人身份发送消息contact:user.base:readonly读取用户基础信息用于成员bitable:app读写多维表格后面做台账会用到docx:document读写云文档涉及ai工具时要授权2.2 腾讯会议开放平台侧企业应用、凭证与API权限腾讯会议这边需要进入腾讯会议开放平台。用企业管理员账号登录后在“应用管理”里创建一个“企业应用”创建完成后会得到 Client ID 和 Client Secret这两项相当于腾讯会议侧的密钥。跟飞书类似也需要配置服务器的公网IP白名单只有白名单内的IP才能调用腾讯会议的接口。应用创建后需要申请调用会议相关API的权限。我当时用的是企业级应用鉴权方式也就是通过 Client ID 和 Client Secret 换取 access_token这种方式适合服务端调用不需要每个用户单独授权。创建会议对应的API是“创建会议”申请权限后可以在开放平台的“API文档”里看到完整的请求参数和示例代码。有一点要特别注意腾讯会议的开放平台文档经常更新不同版本的字段名可能会有调整。比如创建会议接口在某个版本里主题字段叫topic在另一个版本里可能叫subject时间字段有的用秒级时间戳有的用毫秒级。我建议正式开发前先打开最新版的API文档把所有要用到的字段名核对一遍再开始写代码。另外腾讯会议的接口调用有频次限制如果短时间内高频创建会议会被限流后面上线时一定要考虑重试机制。2.3 理解两边的Token体系token有效期与刷新机制飞书和腾讯会议的Token体系都有一个共同点都是通过密钥换取短期有效的访问令牌过期后需要重新获取。飞书侧有两类Token一类是tenant_access_token代表应用身份适合服务端调用另一类是user_access_token代表某个用户的身份需要走OAuth授权流程适合代替用户发起操作。做机器人和会议对接基本上用tenant_access_token就够了。获取方式很简单拿 App ID 和 App Secret 请求飞书的/open-apis/auth/v3/tenant_access_token/internal接口返回的tenant_access_token有效期通常是2小时不同版本可能不同过期后重新请求即可。腾讯会议侧的 access_token 是通过 Client ID 和 Client Secret 换取的系统级Token有效期比较短我记得当时实现时大概是几十分钟到一小时。所以代码里要做成“获取前先检查是否过期”的缓存策略而不是每次请求都重新获取。我见过有人每调一次接口就换一次Token既浪费请求次数又容易被限流。3. 核心实现从“群里发指令”到“自动创建会议并回发链接”3.1 整体调用流程先用一句话讲清楚整个调用流程可以拆成六步每一步都不复杂串起来就形成了一个完整的自动化闭环用户在飞书群聊中机器人并发送指令例如“创建会议 15:00 项目评审”。飞书开放平台将这条消息通过事件订阅推送给后端服务。后端解析消息内容提取会议主题、时间等参数。后端携带腾讯会议 access_token调用创建会议接口。腾讯会议返回会议号、入会链接等信息。后端将这些信息通过飞书机器人API发送回群聊。这里需要提醒的是第1步“机器人”是触发前提——机器人默认只会收到被的消息。如果希望机器人响应群里所有消息需要在事件订阅配置里开启相应选项但这个容易误触发不建议默认开启。3.2 获取飞书令牌与接收消息事件的代码示例先来看飞书侧的两个基础能力获取tenant_access_token和接收事件回调。下面的代码基于Python的 requests 库核心逻辑就是一个HTTP请求加一个JSON解析非常简单。我先写一个获取飞书访问令牌的函数import requests import json import time APP_ID your_feishu_app_id APP_SECRET your_feishu_app_secret FEISHU_TOKEN_URL https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal token_cache { token: None, expire_at: 0 } def get_feishu_tenant_token(): now time.time() if token_cache[token] and now token_cache[expire_at] - 60: return token_cache[token] resp requests.post(FEISHU_TOKEN_URL, json{ app_id: APP_ID, app_secret: APP_SECRET }) data resp.json() if data.get(code) ! 0: raise Exception(f获取飞书token失败: {data}) token_cache[token] data[tenant_access_token] token_cache[expire_at] now data[expire] return token_cache[token]这个函数用了简单的内存缓存避免每次请求都去换取令牌。缓存时间上留了60秒余量防止令牌刚好在请求途中过期。然后是接收飞书消息事件的回调。飞书会把事件以POST请求推送到你配置的URL请求体里包含事件类型和消息内容。对于im.message.receive_v1事件核心字段在event.message.content里内容是JSON字符串里面包含消息文本。from flask import Flask, request, jsonify app Flask(__name__) app.route(/feishu/callback, methods[POST]) def feishu_callback(): body request.json # 飞书事件订阅验证首次配置URL时需要响应 challenge if body.get(type) url_verification: return jsonify({challenge: body.get(challenge)}) # 处理消息事件 if body.get(header, {}).get(event_type) im.message.receive_v1: event body.get(event, {}) message event.get(message, {}) content message.get(content, {}) chat_id message.get(chat_id) # content 是JSON字符串需要解析 import json as json_lib content_data json_lib.loads(content) text content_data.get(text, ) # 在这里解析指令调用腾讯会议API创建会议然后回复消息 handle_message(chat_id, text) return jsonify({code: 0})3.3 获取腾讯会议Token并创建会议代码实战拿到飞书消息后下一步就是解析指令并调用腾讯会议API。先写获取腾讯会议 access_token 的函数。腾讯会议开放平台的Token接口可以用 GET 或 POST 获取关键参数是 Client ID 和 Client Secret我当时用的形式是TENCENT_CLIENT_ID your_tencent_client_id TENCENT_CLIENT_SECRET your_tencent_client_secret TENCENT_TOKEN_URL https://api.meeting.qq.com/v1/oauth2/access_token tencent_token_cache { token: None, expire_at: 0 } def get_tencent_access_token(): now time.time() if tencent_token_cache[token] and now tencent_token_cache[expire_at] - 60: return tencent_token_cache[token] resp requests.post(TENCENT_TOKEN_URL, json{ client_id: TENCENT_CLIENT_ID, client_secret: TENCENT_CLIENT_SECRET, grant_type: client_credentials }) data resp.json() if data.get(code) ! 0: raise Exception(f获取腾讯会议token失败: {data}) tencent_token_cache[token] data[access_token] tencent_token_cache[expire_at] now data[expires_in] return tencent_token_cache[token]创建腾讯会议的接口是/v1/meetings请求方式为POST需要在请求头加上Authorization: Bearer {access_token}。请求体里常见的参数有会议主题、开始时间、结束时间、会议密码等。当时我用到的核心参数如下def create_tencent_meeting(topic, start_time_ts, end_time_ts, password): token get_tencent_access_token() url https://api.meeting.qq.com/v1/meetings headers { Authorization: fBearer {token}, Content-Type: application/json } payload { topic: topic, type: 0, # 0表示预约会议1表示立即开会 start_time: start_time_ts, # 注意单位通常是毫秒时间戳 end_time: end_time_ts, password: password } resp requests.post(url, jsonpayload, headersheaders) data resp.json() if data.get(code) ! 0: raise Exception(f创建腾讯会议失败: {data}) meeting_info data.get(meeting_info_list, [{}])[0] return { meeting_id: meeting_info.get(meeting_id), meeting_code: meeting_info.get(meeting_code), join_url: meeting_info.get(join_url) }创建成功后接口会返回类似meeting_code入会号码、meeting_id会议唯一标识、join_url入会链接这些字段。我在实际调用时发现有的字段名在不同接口版本里有差异所以拿到返回结果后建议先打印一遍完整JSON核对字段名再继续写下游逻辑。3.4 把会议信息回写到飞书群文本消息与卡片消息怎么选腾讯会议创建成功后剩下最后一步把结果发回飞书群。飞书机器人发送消息的接口是POST /open-apis/im/v1/messages需要传接收对象ID、消息类型和消息内容。具体有两个选择。最简单的是发送文本消息msg_type为textcontent 是普通文本。优点是实现快缺点是会议链接、会议号、密码都挤在一起阅读体验一般。我当时上线第一版用的就是文本消息群里长这样会议已创建成功 主题产品周会 时间15:00 会议号123456789 入会链接https://meeting.tencent.com/dm/xxxx 入会密码123456另一种是发送交互卡片msg_type为interactive卡片支持标题、字段、按钮用户可以直接点击链接入会体验好很多。缺点是构造JSON比较繁琐卡片格式要先在飞书开放平台的“消息卡片搭建工具”里调试好再套进代码。我的建议是第一版先用文本消息把流程跑通跑通之后再升级成卡片不要一上来就纠结UI。发送消息的代码大致长这样def send_feishu_message(chat_id, text): token get_feishu_tenant_token() url https://open.feishu.cn/open-apis/im/v1/messages?receive_id_typechat_id headers { Authorization: fBearer {token}, Content-Type: application/json } payload { receive_id: chat_id, msg_type: text, content: json.dumps({text: text}, ensure_asciiFalse) } resp requests.post(url, jsonpayload, headersheaders) data resp.json() if data.get(code) ! 0: raise Exception(f发送飞书消息失败: {data})3.5 参数与边界时间戳、时区、入会密码、重复会议创建会议看似简单参数里其实藏着不少坑。第一个是时间戳单位。飞书传入的消息里如果带时间可能是“15:00”这种可读格式也可能是标准时间但腾讯会议API通常要求毫秒级时间戳。我当时的做法是先让用户在指令里写“15:00”后端解析成当天的datetime再转成毫秒时间戳传给腾讯会议。如果解析失败或者时间早于当前时间就直接报错并提示用户重新输入。第二个是时区。腾讯会议API对时区敏感如果你传的是一个不带时区信息的本地时间接口可能会按UTC处理导致创建出来的会议时间差八个小时。我的处理方式是在创建会议的请求体里显式加上timezone字段一般填“Asia/Shanghai”这样无论服务器部署在哪里会议时间都以北京时间计算。第三个是入会密码。腾讯会议可以自动生成入会密码也可以在创建时指定。我建议在创建时传一个六位数字密码方便后续把密码和会议号一起发给参会人。如果不传接口也会返回一个随机密码但你得在返回结果里多取一个字段。第四个是重复会议。腾讯会议支持按天、按周重复的周期性会议创建时传recurrence_rule相关参数即可。但这个功能我这次没有实现到指令里因为指令解析多做一层复杂度收益有限真要排重复例会走表格驱动的链路更合适。4. 进阶玩法对接之后的自动化与数据闭环4.1 用多维表格当会议台账创建记录自动入库基础链路跑通后你会发现新问题会议信息只存在于聊天记录里想查历史会议还是要翻群消息效率很低。这时候就可以引入飞书多维表格把所有创建过的会议沉淀为结构化数据。具体的做法是在飞书里提前建一张多维表格字段包括会议主题、开始时间、会议号、入会链接、创建人、状态等。后端在创建腾讯会议成功后同时调用飞书多维表格的API往表格里追加一条记录。这样每次开会前、开会后你都可以到表格里查看所有历史会议甚至可以按日期筛选、按创建人统计。飞书多维表格的API看着复杂其实本质就是往指定数据表里插入记录。需要用到多维表格的 App Token 和 Table ID这两个值可以在多维表格的URL里找到。插入记录用POST /open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records请求体里放你要写入的字段值。我当时还做了一个小优化创建会议失败时也在表格里插一条记录但状态标记为“失败”后面排查问题有据可查。4.2 定时任务会议前15分钟自动提醒会议建好了台账也有了下一步是解决“忘记开会”的问题。做法是用一个定时任务每分钟扫描多维表格里未来24小时内的会议记录如果发现某场会议距开始时间还有15分钟就在对应群聊里发一条提醒消息。这个功能实现起来并不复杂难的是“这个会议应该提醒谁、提醒到哪个群”这个关系怎么建立。我当时在创建会议的指令里加了一个可选的名单字段比如“创建会议 15:00 产品周会 张三”解析指令时识别出被的用户会议记录里就保存这些用户ID。定时任务触发提醒时调用飞书API直接通过open_id发单聊消息给参会人比在群里全体提醒更精准。还有一点值得注意定时任务本身要考虑时区问题。服务器如果部署在国外一定要用北京时间来比较时间。我当初就因为这个吃过亏提醒总是提前八小时触发后来统一用Asia/Shanghai时区做时间比较才解决。4.3 审批流触发飞书审批通过后自动建会如果你的团队开会需要走审批流程比如对外接待会议、大型会议需要领导批准那可以把这个对接再升级一层把“创建会议”这个动作从用户主动发起改成审批通过后自动触发。飞书有审批应用审批通过后可以通过事件订阅把结果推送给后端。后端收到审批通过事件后解析审批里的会议主题、时间、参会人字段调用腾讯会议创建接口再把会议信息发回发起人。这样就实现了“申请 - 审批 - 自动建会 - 通知到位”的完整闭环。这个方案的配置工作量主要在飞书审批侧你要设计一个审批表单加好“会议主题”“开始时间”“结束时间”这些字段然后在审批设置里配置Webhook或事件订阅。后端代码逻辑本身和前面的机器人指令驱动大同小异主要区别是数据来源从消息内容变成了审批表单字段。如果你团队已经重度使用飞书审批我非常推荐这个进阶方案。4.4 顺带解决的问题Dify等AI工具如何获得飞书云文档授权凭证对接过程中还有个小插曲团队当时正在试Dify做AI知识库想把飞书云文档作为知识源但Dify配置飞书云文档授权时一直卡在凭证环节。其实原理和前面讲的完全一样——Dify需要的是飞书开放平台里某个应用的 App ID 和 App Secret并且这个应用必须开通云文档相关的读取权限。如果你遇到了同样的问题操作路径是在飞书开放平台创建一个应用权限管理里申请docx:document云文档读取相关的权限审核通过后把 App ID 和 App Secret 填到Dify的知识库或工具配置里。注意Dify走的是应用身份读取文档所以文档要对该应用可见或至少授予该应用访问权限。我当时是把这个应用加到了云文档的协作者列表里才解决了“有凭证但读不到文档”的问题。这个经验放在这里算是对接飞书生态时的一个附赠福利。5. 上线前必须知道的坑常见问题与排查实录5.1 常见问题速查表先收藏再看我把实际运行中遇到的问题整理成了表格每个问题都标了现象、原因和解决方案方便你直接照着排查。问题现象可能原因排查方向与解决方案飞书收不到机器人消息机器人能力未启用或未授予发消息权限检查应用功能里机器人开关权限管理里确认 im:message:send_as_bot 已审批通过机器人能收消息但无法回复发送消息权限缺失申请并等待im:message:send_as_bot权限审核通过飞书事件订阅一直验证失败回调URL公网不可访问或 Encrypt Key 不匹配确认URL能从公网访问用Postman手动请求回调地址检查Verification Token 与 Encrypt Key腾讯会议接口返回鉴权失败access_token 过期或未正确传入请求头检查Token是否缓存过期确认请求头格式为 Bearer {token}创建会议时间差8小时未显式设置时区接口按UTC处理创建会议请求参数里显式加 timezone 字段值为 Asia/Shanghai创建会议接口报权限不足应用未申请创建会议API权限到腾讯会议开放平台检查应用API权限重新提交申请机器人提示未知指令指令解析逻辑不匹配打印收到的原始消息内容核对文本里的空格、符号、大小写5.2 排查事件回调的三个环节飞书事件回调是整条链路里最容易出问题的环节一旦消息推不过来后面全卡住。按照我排查的经验事件回调出问题就查三个地方。第一看请求是否到达服务器。配置好事件订阅后先在后端日志里打印所有POST请求。如果一条都没进来说明飞书根本没把消息推到你服务器上问题在回调地址配置或公网访问层面。这时候检查域名解析、端口、HTTPS证书三项是否正常。第二看请求是否通过校验。飞书事件订阅有URL验证机制首次配置时会发一个带 challenge 的验证请求服务器必须原样返回 challenge 才能通过验证。很多新手卡在这里原因是返回的JSON结构不对或者没有正确取出 challenge 字段。第三看消息事件是否被正确处理。飞书推送的消息事件类型是im.message.receive_v1但如果机器人没有被这个事件可能压根不会推送。我调试时曾以为代码写错了折腾半天才发现是没在群里机器人。事件回调联调阶段建议先创建一个只有机器人和你的测试群避免干扰。5.3 时间与权限相关的几个隐蔽坑除了表格里列的常见问题还有几个隐蔽坑我写在最后提醒一下。第一个是权限生效时间。飞书的权限申请通过后不一定立刻生效。我遇到过权限状态显示“已通过”但调用接口还是报权限错误偶尔要等几分钟甚至重新发布应用版本才生效。所以不要刚通过权限就急着上线先在测试环境验证一遍再说。第二个是接口频控。腾讯会议API有调用频次限制单次创建会议还好但如果你写了一个循环批量创建会议很容易触发限流。建议在代码里加重试机制当接口返回限流错误时退避一段时间再试。第三个是日志的重要性。两边接口的返回结构都比较标准出问题时响应里通常有 code 和 message 字段。务必在代码里把每一步的请求URL、请求参数、返回结果都打印出来尤其是生产环境。很多问题靠看日志一眼就能定位省去反复猜测的时间。第四个是关于IP白名单。腾讯会议开放平台通常要求配置服务器公网IP白名单如果你在公司内网开发IP会经常变动导致调试时频繁出现鉴权失败。我当时的方法是开发阶段用公司出口IP上线前再切换成生产服务器IP两边都加到白名单里避免来回改。写在最后的一点体会这次飞书和腾讯会议的对接技术上并不算高深但整个过程中让我最深的体会是企业工具之间的“打通”难点从来不在API本身而在于对业务场景的理解和对细节的耐心。从“群里发指令”到“自动建会”再到“台账沉淀”每一步都不难但串起来之后对整个团队会议效率的提升是实实在在的。最后再分享一个实用小技巧如果你和我一样用Python写这个对接建议把所有外部接口调用都封装成独立函数并把Token获取统一加一个缓存装饰器。这样后续无论是加提醒功能、加审批触发还是换一个会议服务商改动成本都会小很多。代码跑通不是终点能稳定维护才是。 
