飞书与腾讯会议API对接实战：从Webhook到自动化会议管理

每天早上打开飞书，第一件事就是把前一天群里讨论的会议需求汇总起来，然后切到腾讯会议客户端，一个一个手动创建会议，再把会议号、入会链接复制回飞书群。这个动作看起来只要几分钟，但会议一多就很容易翻车：链接贴错、时间记差、偏偏还有人追问“会议号是多少”。后来我干脆把飞书和腾讯会议通过API打通，在飞书群里发一条指令就能创建腾讯会议，机器人自动把会议卡片推给所有人，会后纪要直接回传到飞书云文档。这篇文章就把这套对接实践的完整链路拆开讲清楚，从选型、凭证、代码到避坑，适合正在做办公自动化、企业应用集成，或者想给团队搞一套“飞书内一键开会”工具的开发者参考。

1. 先想清楚：飞书和腾讯会议打通，到底解决什么问题

很多人在动手之前容易犯一个错：看到“对接”两个字就急着去查API文档，结果调了两天接口，发现团队根本用不上。我自己的经验是，动手之前先花半小时把场景捋清楚，这半小时能省后面好几天的返工。

1.1 每天多出的三分钟，就是最典型的对接需求

先说最普遍的场景。一个几十人的团队，日常沟通几乎都在飞书群里完成，但正式会议用的是腾讯会议。于是每次开会都要经历一套固定流程：在群里讨论出时间 → 打开腾讯会议客户端 → 创建会议 → 复制会议号和链接 → 切回飞书 → 粘贴到群里 → 再手动@所有人。

单次操作三分钟，听起来不多，但每周十几次会议，就是半小时，而且每次复制粘贴都有出错风险。更麻烦的是，很多员工记不住会议号，开会当天还得翻聊天记录。用我团队的话说，这不是技术问题，是每天重复劳动的消耗。

对接之后，这套流程变成：在飞书群里@机器人，发一条“下午3点创建需求评审会”，机器人自动调腾讯会议API创建会议，拿到会议号后通过飞书消息卡片推送到群里，参会人点卡片里的链接就能入会。人工重复操作被彻底拿掉，出错率也降下来了。

1.2 三类高频需求：通知同步、纪要回传、审批联动

我把实际接触到的对接需求归纳成三类，你可以对照自己团队的情况对号入座。

第一类需求最容易落地，也是本文的重点；第二类涉及腾讯会议的录制文件获取，部分能力需要企业版账号才有权限；第三类属于事件驱动的高级玩法，需要用到飞书的事件订阅和审批回调，本质上是把“人工创建会议”变成“系统自动创建会议”。

我建议第一次做对接的团队，先盯住第一类需求跑通全链路，把底层凭证、回调、发消息这些基础能力建好，后面再往上加纪要回传和审批联动就顺手多了。

2. 两条路线怎么选：Webhook机器人还是自建应用全量API

飞书和腾讯会议的对接，技术路线上有两条主流选择。很多人一上来就问我“用哪种好”，我通常反问一句：你只需要单向推送，还是需要双向交互？答案不同，选型完全不同。

2.1 轻量路线：自定义机器人Webhook，十分钟跑通

飞书群里可以直接添加“自定义机器人”，创建之后会拿到一个Webhook地址。往这个地址POST一段JSON，机器人就会把消息发到群里。

curl -X POST https://open.feishu.cn/open-apis/bot/v2/hook/你的Webhook地址 \ -H "Content-Type: application/json" \ -d '{ "msg_type": "text", "content": { "text": "会议通知：下午3点需求评审会\n会议号：123456789\n入会链接：https://meeting.tencent.com/dm/xxxx" } }'

这是最简单粗暴的对接方式，适合的场景是：你只需要一个“会议通知推送机器人”，不需要用户和机器人对话，也不需要程序读取群里的消息。

它的优点非常明显：不需要在飞书开放平台创建应用、不需要审核、不需要配置事件订阅回调地址，拿一个Webhook地址就能上线。我之前用这种方式帮一个销售团队做过会议提醒，从写代码到部署完不到半小时。

但缺点同样明显：自定义机器人只能主动推送，不能接收群消息，不能读取群成员列表，也不能上传文件。如果你希望用户在群里@机器人创建会议，那Webhook这条路直接堵死，必须走自建应用。

2.2 完整路线：自建应用+事件订阅+腾讯会议API

完整路线是在飞书开放平台创建一个“企业自建应用”，给应用开启机器人能力，然后通过API收发消息、上传文件、订阅群聊事件。同时，在腾讯会议开放平台创建一个应用，获得腾讯会议API的调用凭证。

这套组合能做到的事情就多很多：

• 用户在群里@机器人，机器人通过事件订阅接收到消息内容；
• 后端解析用户指令，调用腾讯会议API创建会议；
• 创建完成后，调用飞书API发送消息卡片，甚至直接把参会名单生成xlsx文件发到群里；
• 还可以把云文档读写能力打开，将会议纪要自动写入飞书云文档。

我目前生产环境里跑的就是这条路线。虽然前期配置步骤多一些，但能力边界完全不一样，后续扩展AI Agent、审批联动都依赖这套完整链路。

2.3 选型对比：什么时候选哪个，一次说清

我的建议很简单：如果只是“把会议链接推送到飞书群”，用Webhook就行，别给自己加戏；如果要做成“在飞书里管理腾讯会议”，一步到位选自建应用，别走弯路。

3. 凭证和权限：卡住九成新手的三大关口

对接过程中最难的不是写代码，而是搞定各种凭证和权限。我自己第一次做飞书对接的时候，光是在开发者后台里找权限点就找了半天，还因为漏发应用版本导致接口一直报权限错误。下面把三个关键凭证一一讲清楚。

3.1 飞书自建应用：app_id、app_secret与权限点

在飞书开放平台后台创建一个企业自建应用之后，你会拿到两个最关键的值：App ID和App Secret。所有调用飞书开放API的请求，都要先拿这两个值去换tenant_access_token（应用身份令牌）。

换token的接口很简单，POST方式调用：

import requests resp = requests.post( "https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal", json={ "app_id": "你的App ID", "app_secret": "你的App Secret" } ) token = resp.json()["tenant_access_token"]

拿到token之后，调用消息、云文档等接口时，在请求头带上Authorization: Bearer $TOKEN即可。

这里有个新手必踩的坑：你需要在“权限管理”里把用到的权限点全部开启，并且重新发布应用版本，让管理员审核通过，权限才会真正生效。很多人改完权限直接去调用接口，发现还是报权限错误，就是漏了发布这一步。

常用的权限点有这些，可以对照勾选：

• im:message:send_as_bot：机器人发送消息
• im:chat:readonly：读取群信息
• docx:document：读写云文档
• drive:drive：访问云盘文件
• contact:user.base:readonly：读取用户基础信息

3.2 腾讯会议开放平台的OAuth凭证：从注册到拿到access_token

腾讯会议这边需要在腾讯会议开放平台（应用市场 → 开放平台）注册为开发者，创建一个企业应用。创建后你会拿到Client ID和Client Secret。

腾讯会议API走的是OAuth 2.0授权流程，简单说分三步：

1. 把用户引导到授权页，用户同意后拿到授权码（code）；
2. 用code加Client ID/Secret换取access_token；
3. 之后调用创建会议等接口时，在请求头带上access_token。

换token的请求大概是这样的：

resp = requests.post( "https://api.meeting.qq.com/v1/oauth/access_token", json={ "client_id": "你的Client ID", "client_secret": "你的Client Secret", "code": "授权码", "grant_type": "authorization_code" } ) access_token = resp.json()["access_token"]

需要注意，access_token的有效期大约两个小时，过期后需要用refresh_token续期。所以对接代码里一定要做token缓存和自动刷新，这个我在第5章展开讲。

3.3 飞书云文档授权凭证：Dify等AI工具首次接入的通用解法

很多人在用Dify这类AI应用平台时，第一次配置飞书云文档数据源就被“授权凭证”卡住了。其实这个凭证的本质和上面讲的OAuth流程一模一样。

Dify要读取你的飞书云文档，必须以某个飞书用户的身份去访问文档，这就需要一个user_access_token（用户身份令牌）。获取方式还是在飞书开发者后台创建一个应用，开启云文档相关权限，然后走OAuth 2.0授权流程：

• 授权页面让用户点击“同意授权”；
• 拿到授权码后，通过/open-apis/authen/v1/oidc/access_token接口换取user_access_token；
• 将这个token配置到Dify的“飞书云文档”数据源中即可。

这里最容易出问题的地方是权限点不全。Dify需要至少打开以下权限点：

docx:document:readonly drive:drive:readonly drive:file:readonly

如果配置后Dify提示“无权限访问文档”，先检查两件事：一是授权时勾选的权限范围里有没有包含目标文档；二是这个文档是否把对应应用或用户加到了共享列表里。飞书的权限模型里，光有token还不够，文档本身必须有访问权限，两者缺一不可。

4. 动手落地：会议创建、群通知、表格消息一条龙

凭证搞定之后，接下来就是真正动手写对接逻辑。我以Python为例，把整条调用链拆开，每一段都能直接抄作业。

4.1 整体调用链：一句话讲清服务端设计

对接的服务端本质上是一个“中转调度器”，它同时对接飞书和腾讯会议两个系统。我用的整体设计是这样：

用户从飞书群发消息 → 飞书事件订阅服务把消息内容POST到我的回调服务器 → 服务端解析消息里的指令 → 调用腾讯会议API创建会议 → 拿到会议号/入会链接 → 调用飞书API发消息卡片 → 会议结束后，触发回调把纪要写入飞书云文档。

实际部署时，我建议把这三块拆成独立模块：一个模块负责飞书消息的接收和解析，一个模块负责腾讯会议API调用，一个模块负责飞书消息/文件发送。这样任何一个环节出问题，排查起来都很快。

4.2 飞书机器人发通知：从文本到富文本“表格”

先看最简单的文本通知。拿到tenant_access_token后，调用飞书消息接口：

import requests def send_feishu_message(chat_id, text): resp = requests.post( "https://open.feishu.cn/open-apis/im/v1/messages?receive_id_type=chat_id", headers={ "Authorization": "Bearer " + access_token, "Content-Type": "application/json" }, json={ "receive_id": chat_id, "msg_type": "text", "content": json.dumps({"text": text}) } ) return resp.json()

如果只是发一段文字，msg_type用text就够了。但很多会议通知需要把“会议主题、时间、主持人、会议号、入会链接”逐行排列，这时候用post富文本消息效果更好。飞书post消息的content是一个二维数组，每个元素是一行，可以用它模拟出表格的排版感：

{ "msg_type": "post", "content": { "post": { "zh_cn": { "title": "会议通知", "content": [ [{"tag": "text", "text": "会议主题：需求评审会"}], [{"tag": "text", "text": "时间：今天 15:00 - 16:00"}], [{"tag": "text", "text": "会议号：123456789"}], [{"tag": "a", "text": "点击入会", "href": "https://meeting.tencent.com/dm/xxxx"}] ] } } } }

这是轻量场景下的最优解，不需要任何额外权限，自定义机器人Webhook都能直接发。

4.3 自建应用发真实表格文件：上传xlsx到群里

如果会议参会人数多、信息量大，纯文本排版就不好用了。比如你有一份几十人的参会名单，或者一张周会议计划表，最合适的做法是直接把Excel文件发到群里。

自建应用可以通过飞书im/v1/files接口先把文件上传到飞书，拿到file_key后发送到群聊：

# 第一步：上传文件 with open("会议安排.xlsx", "rb") as f: resp = requests.post( "https://open.feishu.cn/open-apis/im/v1/files", headers={"Authorization": "Bearer " + access_token}, data={"file_type": "xlsx", "file_name": "会议安排.xlsx"}, files={"file": f} ) file_key = resp.json()["data"]["file_key"] # 第二步：把文件发送到群 requests.post( "https://open.feishu.cn/open-apis/im/v1/messages?receive_id_type=chat_id", headers={ "Authorization": "Bearer " + access_token, "Content-Type": "application/json" }, json={ "receive_id": chat_id, "msg_type": "file", "content": json.dumps({"file_key": file_key}) } )

在服务端生成Excel文件，可以直接用pandas或者openpyxl，比如把会议信息列表写入DataFrame再导出xlsx。实测下来，im/v1/files接口对常见办公场景足够用，文件大小上限30MB，一般会议表格根本触不到这个限制。

一个小提示：上传文件前先检查文件后缀和file_type是否匹配，传错了会报错。xlsx对应xlsx，docx对应docx，图片对应jpg/png这种。

4.4 调用腾讯会议API创建会议：参数与回调处理

创建会议是腾讯会议API的核心操作，接口为POST /v1/meetings。关键参数包括：会议主题、开始时间、结束时间、会议类型，以及主持人配置。

import requests resp = requests.post( "https://api.meeting.qq.com/v1/meetings", headers={ "Authorization": "Bearer " + access_token, "Content-Type": "application/json" }, json={ "topic": "需求评审会", "start_time": "1704261600", # Unix 时间戳 "end_time": "1704265200", "meeting_type": 0, "settings": { "mute_enable": 1, # 入会静音 "allow_unmute_self": 0 # 禁止自己解除静音 } } ) meeting = resp.json()["meeting_info_list"][0] meeting_id = meeting["meeting_id"] join_url = meeting["join_url"]

创建成功后，把meeting_id和join_url拼到飞书消息里，就完成了整个闭环。

这里我建议把创建会议和发送通知拆成两步：先创建会议，保存返回结果到数据库，再发送飞书通知。如果腾讯会议创建成功了但飞书消息发送失败，至少会议是真实存在的，手动补发一条通知就行，不会出现“群里说开会但会议没建成”的情况。

5. 踩坑实录：这些问题我都是在生产环境里遇到的

接口文档看着都很简单，真正跑起来才会遇到各种“意外”。这一章挑四个最有代表性的坑，全部是我实际踩过的。

5.1 事件订阅URL校验失败：challenge和encrypt_key的坑

飞书事件订阅要求你提供一个回调URL，配置的时候飞书会往这个URL发送一条验证请求。如果你在应用里开启了加密（Encrypt Key），验证请求体是加密过的，要先用AES解密，再取出challenge字段原样返回。

我当时第一次配置，没开加密，直接返回challenge就通过了。后来为了安全开启Encrypt Key，结果验证一直失败，排查了半天才发现是解密后字段结构对不上。处理逻辑大概是这样：

from flask import Flask, request, jsonify import json app = Flask(__name__) @app.route("/webhook/feishu", methods=["GET", "POST"]) def feishu_callback(): body = request.get_json() # URL校验 if body.get("type") == "url_verification": return jsonify({"challenge": body["challenge"]}) # 如果开启encrypt_key，这里要先解密 # decrypt_data = decrypt(body["encrypt"]) # 再解析解密后的JSON，业务逻辑处理 return jsonify({"code": 0})

需要注意，返回challenge时响应头里的Content-Type必须正确，有些框架默认返回text/html会导致校验失败。建议显式声明application/json。

5.2 明明加了权限点，接口还是报权限错误

这个问题我遇到不下三次，每次原因各不相同。最常见的是改了权限后没有发布新版本，tenant_access_token仍然对应旧权限。其次是权限点选错，比如飞书机器人发消息有两类权限：im:message:send_as_bot（机器人发消息）和im:message:p2p_msg（机器人接收单聊消息），用法完全不一样，选错了报的错也让人摸不着头脑。

排查这类问题的标准流程是：先看错误码，飞书开放平台的错误码文档能定位到大部分问题；然后用飞书开放平台的“API Explorer”实测，它带真实token调一遍接口，很容易暴露是权限问题还是参数问题；最后确认当前应用是测试版还是已发布版本，测试版只有应用开发者和管理员能看到，如果要用到正式环境，必须发布。

5.3 token过期与并发刷新：一个容易忽视的竞态问题

飞书的tenant_access_token和腾讯会议的access_token都有有效期，大约两小时。很多人的第一版代码是每次调用前都去换一次token，结果发现接口响应慢，还容易被限流。正确的做法是缓存token，快过期时再刷新。

但缓存也有坑：如果服务是多实例部署的，两个实例同时检测到token过期，同时发起刷新请求，后刷新成功的token会把先刷新成功的顶掉，导致先拿到的那个实例后续请求全部鉴权失败。

我的解决方案是给token刷新逻辑加一个分布式锁，或者用一个简单的Redis缓存加过期时间。代码结构大概是这样：

cache_key = "feishu_tenant_access_token" token = redis.get(cache_key) if not token: with redis.lock("feishu_token_lock"): token = redis.get(cache_key) # 双重检查 if not token: token = fetch_feishu_token() redis.set(cache_key, token, ex=7000) # 比2小时短一点

这个细节在生产环境非常重要，否则每到token过期的时间点，线上就会莫名其妙报一批401错误。

5.4 一个无关但高频的误解：摄像头问题是客户端的事

在对接过程中，我收到最多的提问反而不是API问题，而是“腾讯会议不能使用电脑自带摄像头吗”“能不能通过接口强制开启参会人摄像头”。这里必须明确一个边界：腾讯会议API能控制的，是会议的创建、成员入会、录制等管理能力，参会人本地的摄像头、麦克风权限属于客户端和设备系统管理，接口层面根本没有这个能力。

如果有人在腾讯会议里发现摄像头用不了，排查方向应该是：

1. 系统隐私设置：Windows的“设置 → 隐私和安全性 → 相机”，macOS的“系统设置 → 隐私与安全性 → 相机”，确认已允许腾讯会议访问；
2. 腾讯会议客户端设置：检查视频设置里是否选择了正确的摄像头设备；
3. 驱动和外设：外接摄像头在设备管理器里是否正常识别，驱动是否需要更新。

对接开发时，遇到这类问题可以直接把排查清单丢给提问的人，比让他们翻来覆去找设置快得多。

6. 扩展方向：把对接交给AI Agent

聊完基础对接，再说说现在很火的方向：把飞书和腾讯会议的对接能力交给AI Agent。网上常看到的“Dify如何对接飞书”“Codex CLI接入飞书”“AI大模型全栈知识库-飞书云文档”这些话题，本质上都是在复用本文讲的这套凭证和API链路。

AI Agent的典型玩法是：在飞书群里@机器人，用自然语言说“明天下午3点和大客户开个需求评审会，帮我创建腾讯会议并通知参会人”，大模型解析出意图和时间，调用已经封装好的腾讯会议创建函数，再调用飞书发消息函数，完成整个操作。飞书云文档则可以作为Agent的知识库，让它能读取历史会议纪要，回答“上次评审会结论是什么”这类问题。

我在实际项目里的体会是，API对接是地基，AI Agent只是把“人调接口”变成了“大模型理解意图后再调接口”。底层凭证、权限、回调链路一点都不会变。所以如果你想做AI Agent方向，别急着接大模型，先把本文这套基础的飞书-腾讯会议对接跑通，后面加AI能力就顺理成章了。

对接本身不复杂，复杂度全在“把边界划清楚”这件事上：哪些能力由飞书提供，哪些由腾讯会议提供，哪些只能靠人工操作。把这几个边界想明白了，工具链再变都不慌。