先交代一下背景我做这个对接不是因为老板拍脑袋而是每周的例会整理实在把人逼疯了。会议开完一小时纪要整理两小时参会人要单独发消息表格要重新誊一遍。后来我发现腾讯会议的接口能拿到会议数据飞书的开放平台能把文档、消息、表格都自动化那干脆把它们串起来。这篇文章就是我把这套流程从零跑通的全过程包括踩过的坑和最终的落地方案给同样被会议记录折磨的朋友一个参考。这个方案的适用面其实很广小团队想省掉人工整理会议纪要中大型企业想把会议数据沉淀进飞书知识库甚至想用大模型自动出纪要给到飞书文档做知识沉淀的都可以参考。我这边最终采用的是“腾讯会议 API 飞书开放平台 API Dify 低代码编排”的组合既照顾了开发成本又保留了后续扩展 AI 能力比如自动总结纪要的空间。下面按我实际执行的顺序把每一步拆开讲清楚。1. 先想清楚对接到底解决什么问题1.1 常见对接场景与价值飞书和腾讯会议一个是办公协同平台一个是视频会议工具表面上看各管各的但实际业务里它们的交叉点特别多。我总结下来最常见的三类诉求第一类是会议数据自动归档。会议结束以后系统自动把会议主题、时间、参会人、会议号、录制链接整理成结构化数据写入飞书云文档或者多维表格再推送给相关人员。这个场景解决的是“信息分散”的问题不用再手动从腾讯会议后台导出数据再粘贴到飞书。第二类是会议纪要自动生成与分发。结合大模型能力把腾讯会议的转写文本交给 AI 生成结构化会议纪要然后通过飞书机器人发到群里同时存进云文档作为知识库条目。很多团队把这个过程叫“会议知识沉淀”本质上是用自动化替代重复劳动。第三类是会议相关审批/预约联动。比如在飞书上发起一个会议申请流程审批通过后自动创建腾讯会议并把会议链接同步给参会人。这类场景更偏流程自动化需要两边接口都有比较完整的权限体系支持。我这次做的项目以第一类和第二类为主重点打通“腾讯会议 → 飞书文档 → 飞书机器人”这条链路。做完以后最直观的感受是每周例会从“开完会还要整理半小时”变成了“开完会自动归档”人力成本基本降到了零。对于经常有外部客户会议、需要留存会议记录的团队这套东西的价值会更大。1.2 两条技术路线怎么选开始动手之前我先对比了几种实现方式这也是你在做类似对接时第一步要想清楚的事。第一种是全代码直连。直接用 Python 或 Node.js 调腾讯会议 OpenAPI 和飞书 OpenAPI中间加一个定时任务或者 Webhook 触发。优势是完全可控逻辑可以做得非常细比如自定义字段映射、异常重试、分布式多会议室支持等。缺点是开发成本高要求两边接口文档都比较熟而且腾讯会议的鉴权逻辑和飞书的鉴权逻辑还不一样代码里要同时维护两套 token。第二种是低代码编排典型工具就是 Dify。把腾讯会议的数据抓取做成工具节点把飞书文档创建和机器人发送做成另外的工具节点通过向量数据库或者知识库把它们串成一条工作流。优势是界面化逻辑调整快还能很方便地接入大模型做纪要总结。缺点是对接口的依赖没有被消除你还是得处理授权、凭证、数据格式转换这些事。第三种是纯手工半自动比如用飞书多维表格的自动化规则配合腾讯会议导出文件手动上传。这个基本不叫对接我直接放弃了。我最终选择的是“代码 Dify”混合方案核心的数据抓取和文档写入用代码实现方便调试纪要总结和知识库沉淀放到 Dify 里做利用它的 AI Agent 能力自动把会议转写文本变成长文纪要再写回飞书云文档。很多人一上来就想着全自动化动不动就要做成一键直连实际上先跑通最小闭环、再逐步加 AI 能力才是效率最高的路。2. 正式开工前的准备工作2.1 飞书侧创建应用、拿凭证、开权限飞书这边的对接核心是“自建应用”。你需要先到飞书开放平台创建一个企业自建应用创建完成后会拿到 App ID 和 App Secret这两个凭证是后续所有 API 调用的基础。创建应用的位置在飞书开放平台后台的“开发者后台”进去之后选“创建企业自建应用”填好应用名称和描述。这里有一个容易忽略的点应用名称直接决定机器人在飞书里显示的名字建议起一个一眼能认出用途的名字比如“会议归档助手”不要用“测试应用”这种。应用创建好之后真正的重点在权限配置。飞书的权限控制颗粒度很细每一个 API 都对应一个权限点。我做这个项目用到的权限包括docx:document系列创建和编辑云文档im:message系列发送机器人消息drive:drive系列读写云空间文件contact:user.base系列读取用户基本信息用于把会议参会人和飞书用户对应起来这些权限在“权限管理”页面逐个开通开通后还需要发布应用版本让管理员审核通过。这里特别注意如果你只是在开发者后台创建了应用但没有发布版本权限是不会真正生效的调用接口时会报权限错误。还有一个很多人踩过坑的点凭证的获取。在“凭证与基础信息”页面能看到 App ID 和 App Secret。App Secret 只显示一次如果没保存好就只能重置。实际调用时你需要用 App ID App Secret 去换取 tenant_access_token这个 token 时效一般是 2 小时需要在代码里做缓存和自动刷新。我习惯把凭证放到环境变量里而不是写死在代码文件中因为这类项目后续大概率要部署到服务器写死凭证既不安全也不方便多环境切换。在本地调试时我一般用一个.env文件真正部署时再换成服务器的环境变量。2.2 腾讯会议侧企业自建应用、密钥、回调配置腾讯会议的开放能力和飞书不太一样它的接口主要面向“企业自建应用”开放。你用个人账号登录腾讯会议开放平台基本只有创建会议、查询会议这类基础权限真正要拿到参会人明细和录制文件信息必须走企业认证。具体操作是在腾讯会议开放平台注册开发者账号创建一个企业自建应用然后申请对应的接口权限。审核通过后你会得到一个“会议号加密密钥”和一个“企业 ID”。这两个东西很重要一个用于接口鉴权一个用于标识你的企业身份。腾讯会议新版的鉴权方式是 OAuth 2.0拿到 access_token 后调用业务接口token 有效期大概是一个小时同样需要做自动刷新。这里还要特别说明一下腾讯会议的回调配置。回调和飞书的 Webhook 类似开会结束、录制完成、成员入会等事件都会以 HTTP POST 的方式推送到你配置的回调地址。我做对接时优先用回调来触发后续流程而不是定时轮询因为回调是实时触发的不会因为接口调用频率限制导致数据拉取不及时。回调配置里比较关键的是“事件订阅”和“加密密钥”。事件订阅决定你能收到哪些事件加密密钥用于校验回调消息的签名防止伪造请求。这一块官方文档写得比较散我当时的做法是先用一个简单的 Flask 服务把回调地址跑起来确认能收到事件后再逐步补充后续逻辑。2.3 Dify 桥接时的授权凭证获取细节如果你和我一样打算引入 Dify 作为 AI 纪要总结的编排层那“飞书云文档授权凭证”这个点尤其要留意。很多人在配置 Dify 的飞书工具时卡住其实卡住的位置几乎都是同一个获取飞书的刷新令牌refresh token。Dify 对接飞书云文档走的通常是飞书的第三方授权模式也就是需要用户手动授权然后换取一个长期有效的 refresh token。这个流程我实际操作下来是这样的第一步在飞书开放平台创建一个应用开启“网页应用”能力配置好重定向 URL。这个重定向 URL 必须和 Dify 里填写的回调地址完全一致否则授权时会报redirect_uri不匹配。第二步用浏览器访问授权 URL用户登录后飞书会跳转到重定向地址并在 URL 参数里带上一个临时的 code。这个 code 只能用一次用它去调用飞书的接口换取 access_token 和 refresh_token。refresh_token 的有效期比较长通常几个月之后用它刷新 access_token 即可。第三步把拿到的 refresh_token 填到 Dify 工具的授权配置里。注意Dify 的飞书云文档工具一般要求的是 refresh_token不是 access_token。如果你填了 access_token当时看起来能用但过期之后就会报 401排查半天还以为是网络问题。另外一个细节是权限范围Dify 访问飞书云文档时应用必须具备文档读写权限而且授权的用户必须有对应文档的访问权限。我一开始用管理员账号授权的 token部署后业务同学用自己的账号访问文档时就报权限不足后来统一改成用机器人身份调用才稳定。3. 核心流程实现会议数据自动沉淀到飞书3.1 拿会议列表与会议详情整个对接流程的第一步是从腾讯会议侧拉取会议数据。这里分两种情况如果是“会议结束事件”触发回调里会直接带上会议 ID你只需要拿这个 ID 去查详情如果是定时任务全量同步就需要调用查询会议列表的接口然后逐个获取详情。我实际用的是回调触发模式所以代码逻辑很清晰import requests import json # 腾讯会议接口地址 BASE_URL https://api.meeting.qq.com/v1 def get_access_token(app_id, secret, secret_id): url https://api.meeting.qq.com/v1/oauth2/access_token params { app_id: app_id, secret: secret, grant_type: client_credentials, secret_id: secret_id } resp requests.post(url, datajson.dumps(params), headers{Content-Type: application/json}) return resp.json().get(access_token) def get_meeting_detail(meeting_id, access_token): url f{BASE_URL}/meetings/{meeting_id} headers {Authorization: fBearer {access_token}} resp requests.get(url, headersheaders) return resp.json()这里有个细节腾讯会议新版的 token 获取接口需要同时传secret和secret_id很多旧教程只写 secret导致 401 调不通。secret_id在企业自建应用详情页里能看到不是我们通常理解的“应用 ID”别搞混。会议详情接口返回的数据里最常用的是这几个字段会议主题subject、开始时间start_time、结束时间end_time、会议号meeting_id、主持人host信息、入会链接join_url。录制信息一般不在详情接口里需要单独调录制文件列表接口或者在录制完成回调里拿。3.2 飞书云文档创建与内容写入拿到会议数据以后接下来就是把数据变成飞书文档。这里有两种做法一种是直接创建一篇 docx 文档往里写入标题和正文段落另一种是写入多维表格的字段适合把大量会议记录做成结构化台账。我这边两种都做了。文档形式用于“每次会议的完整纪要”多维表格形式用于“月度会议汇总看板”。先说文档创建的实现def create_feishu_doc(app_token, open_id): url fhttps://open.feishu.cn/open-apis/docx/v1/documents headers { Authorization: fBearer {tenant_access_token}, Content-Type: application/json } body { title: 会议纪要, folder_token: 可选指定云空间文件夹 } resp requests.post(url, headersheaders, jsonbody) doc resp.json().get(data, {}).get(document, {}) return doc.get(document_id)创建文档本身不难真正麻烦的是往文档里写内容。飞书 docx 接口往文档里添加块block时需要传block_id作为父节点而且文档结构是嵌套的标题、段落、表格都是不同类型的 block。第一次用的时候很容易对着 JSON 报文发懵。我这里给你一个简单的思路文档创建后正文内容位于文档根节点的children列表里。你可以在列表末尾添加新块用一个“定位块”法先往文档末尾插入一个空段落拿到 block_id再用新块替换它或者直接在末尾的 children 数组里追加。官方文档里这个说法比较绕实际操作时我直接用 SDK 方法create_block传父节点 ID 为文档根节点实测可以追加成功。如果你要插入的不是纯文本而是表格比如参会人名单可以用table类型的 block。表格块的构造比普通段落复杂需要先定义表格宽、行数、列数再逐格填入内容。我后来更推荐的一种做法是先把表格数据整理成 CSV再调用飞书的导入接口生成电子表格比在 docx 里拼表格省事得多。3.3 机器人推送卡片与表格附件文档创建完以后最后一步是把信息推给需要的人。飞书机器人发消息有两种常见形式一种是普通文本消息一种是消息卡片。消息卡片的展示效果好得多支持按钮、状态标签、分栏等我强烈建议你用卡片而不是纯文本。如果你只想快速把结构化数据发到群里最省事的方式是发一条 JSON 格式的富文本消息把会议名、时间、参会人数、链接都列在消息里。但如果你想把一整份表格推送到群里就需要先生成表格附件再上传到飞书最后用 file 类型的消息发送。这里有一个“飞书机器人发送表格”的经典套路我拆解一下第一步用 pandas 或其他工具把数据生成 xlsx 或 CSV 文件。第二步调用飞书云盘的upload接口把文件上传到指定文件夹拿到file_token。上传时注意飞书对文件大小和类型有校验CSV 文件需要注意编码xlsx 则最好用小工具库生成避免格式损坏。第三步调用im/v1/messages发送消息消息类型为file内容就是{file_key: xxx}。这条消息就会以文件附件形式出现在群里同事点开就能下载。如果你用的是消息卡片还可以在卡片里放一个“查看纪要”按钮点击后跳转到我们刚创建的飞书文档。实现上就是在 card 的elements里加一个buttonurl指向文档链接。这个体验比直接把文档链接贴在文本里强得多。3.4 多线程与速率控制的取舍做对接的时候如果只是单次会议数据跑一次脚本几秒钟就完事了。但如果你有几十个会议室、每天几十场会议就会遇到接口速率限制的问题。腾讯会议和飞书对接口 QPS 都有限制超了会返回 429 或者too many requests。我的处理方式是加一层简单的速率控制用一个队列把待处理任务串起来固定每秒只放行 N 个请求。如果你需要更高的并发可以用 Python 的threading或asyncio但要特别注意 token 的并发刷新问题。访问令牌的刷新一定得加锁不能让多个线程同时去刷同一个 token否则会有一个请求拿到失效 token直接报 401。3.5 完整的编排流程到这里一条完整的链路就通了。我用代码做了一个简单的调度器逻辑是这样的监听腾讯会议 Webhook收到会议结束事件后先查会议详情和录制列表把录制转写文本如果有传给 Dify 的 AI Agent生成结构化会议纪要调用飞书文档接口创建云文档写入会议信息和 AI 纪要把文档链接和关键字段组装成消息卡片通过飞书机器人发送到指定群同时把会议数据追加到飞书多维表格用于月度汇总和统计。这个流程跑起来以后每周例会的归档工作基本就是全自动的。唯一需要人工介入的是 AI 生成的纪要偶尔会有细节偏差需要负责人扫一眼。4. 实操现场一次完整对接的踩坑记录4.1 飞书 network unavailable 的排查与修复最近不少人在问“飞书报错 network unavailable, please go to feishu network diagnosis to find the problem”我这次也遇到过。表面看是网络问题实际原因五花八门。最常见的情况是调用接口时没有走对网络环境。飞书开放平台的接口域名是open.feishu.cn如果你在本地调试时公司网络做了域名白名单限制请求就会超时。我当时在公司内网调试时一直报 network unavailable换了手机热点就通了排查了一圈才发现是内网代理把飞书域名过滤了。处理方式是把open.feishu.cn加进白名单或者走企业网关的代理。第二种情况是本地开发者工具的问题。如果你用 Postman 或 Apifox 调试有时候代理设置不对也会出现 network unavailable。建议先直接用 Pythonrequests库跑一个最简单的get请求排除工具层面的问题。第三种情况是服务器防火墙。部署到云服务器后如果安全组没放行出站请求或者服务器时间不准确导致 HTTPS 握手失败也会出现类似的报错。尤其是服务器时间错误会导致飞书 token 校验失败表现也是网络异常。排查时第一件事不是抓包而是先看服务器时间和时区对不对。飞书官方提供的“network diagnosis”工具能帮你检测本机到飞书服务器的连通性报错时先用它确认网络层没问题再查代码和权限能省很多时间。4.2 摄像头问题的真相热搜词里有一条“腾讯会议不能使用电脑自带摄像头吗”看起来跟对接没关系但在实际交付时我遇到过类似的问题而且很容易让人误判成对接代码的问题。情况是这样我发布对接系统后有同事反馈说用微信扫码登录腾讯会议时摄像头调用异常以为是我们的机器人抢占了摄像头权限。排查到最后发现是腾讯会议客户端的隐私设置里“摄像头权限”被系统禁用了。Windows 系统设置里把腾讯会议的相机权限关掉客户端里自然用不了自带摄像头。这不属于 API 对接的问题但我想提醒大家如果对接后的自动化流程要触发本地的腾讯会议客户端比如自动入会、自动开启摄像头千万要注意系统级权限和客户端权限两层设置。否则线上跑得好好的线下同事一用就翻车人家第一反应就是你的对接脚本有问题。4.3 授权过期与 token 刷新这类对接项目上线后出问题最多的就是 token 过期。飞书的tenant_access_token有效期 2 小时腾讯会议的access_token有效期更短。如果你的程序不维护 token 刷新逻辑跑一个晚上就会开始报 401。我在代码里写了一个统一的 token 管理器用文件缓存 token记录过期时间每次请求前先检查是否过期过期则自动刷新。同时加了一个“token 刷新锁”保证多线程环境下只有一个线程执行刷新其他线程等待新 token 生效后再继续。这里有一个很容易踩的坑飞书刷新后旧的 token 并不会立刻失效会有一小段过渡期。如果你在过渡期内没拿到新 token 就使用了旧 token可能偶尔成功偶尔失败排查起来非常恶心。最好的做法是一旦发现 401强制刷新一次 token 并重试当前请求重试不超过两次。4.4 接口文档与沙箱环境的配合最后分享一个经验腾讯会议开放平台提供了沙箱环境飞书也提供了一系列测试工具但沙箱环境和生产环境的返回结果不一定完全一致。我在沙箱里测试通过后上生产还是踩了一个字段差异的坑——腾讯会议沙箱返回的录制字段是record_files生产环境里同一个字段嵌套层级更深。所以建议你正式上线前一定要用生产环境的接口做一次全链路测试并且把关键返回值的结构打印出来做一份字段映射表。很多对接项目的返工不是因为不会调接口而是因为环境差异导致的数据结构错位。我个人的体会是工具链和接口能力都在快速迭代但“数据从哪来、到哪去、中间怎么转换”这个思路是通用的。先把一条最小的链路跑通再逐步加权限、加 AI、加通知是性价比最高的方式。至于更复杂的场景比如对接多维表格做动态看板、用飞书审批流联动腾讯会议预约、把历史会议记录灌入知识库做智能问答都是在这个基础上扩展出来的思路完全一致。最后再分享一个小技巧日志一定要打全。接口入参、出参、token 获取结果、权限校验结果每一步都留下结构化日志。这些日志在你排查“到底哪一环断了”的时候就是救命稻草。