最近一直在折腾内部效率工具其中一个需求就是把手头的飞书和腾讯会议串起来。公司里飞书管协作、腾讯会议管线上音视频每天开会的人在群里发会议号、复制链接约一场会要来回改好几轮散会之后纪要又经常散落在各个文档里找不着。于是我们做了个小项目在飞书群里输一条命令机器人自动调腾讯会议API把会建好入会信息和会议链接直接回传到群里会议结束之后通过回调把录制链接、纪要材料自动归档到飞书云文档。整个过程跑下来最大的感触是开放平台之间的对接本身不复杂真正卡人的全是权限、Token、回调验签这些细节。这篇文章把从零到一的完整实践过程写出来包含配置步骤、核心代码和踩坑记录适合正在做飞书或腾讯会议二次集成的同学参考。1. 对接前先把场景想清楚飞书和腾讯会议到底能怎么玩1.1 90%的团队需要的是这三条链路在动手之前先花一天时间把实际使用场景理清楚比直接去翻API文档重要得多。我们调研完同事的反馈发现日常开会最痛的点基本集中在三条链路第一条是一键建会。以前在飞书群里约会议靠人工把会议主题、时间、参会人整理好再去腾讯会议客户端里创建一个会议然后把会议号、入会链接复制回群。整个过程重复性极高还容易漏人。现在做的是在飞书群里机器人输入“开会 主题 时间”机器人直接调腾讯会议API把预定会议建好返回一个富文本卡片成员点卡片里的链接就能入会。第二条是会议信息同步。会议一旦建好会议号、入会链接、会议时间、创建人这些信息都要在飞书侧留痕。用飞书消息卡片承载会变得非常直观——卡片上把会议主题、开始时间、腾讯会议链接都排好版比纯文本消息清楚得多。这里牵扯到飞书消息API和卡片JSON的组装。第三条是会议结束后的自动归档。腾讯会议支持配置会议结束事件的回调会议结束后我们把会议录制地址、参会人列表、会议开始结束时间这些信息抽出来调用飞书云文档API写进一份归档文档里再在群里发一条“会议纪要已归档”的卡片通知。这一条最受leader欢迎因为周会、复盘会的资料终于不用再手动整理了。除了这三条还有一些高阶玩法比如在飞书审批通过后自动创建腾讯会议或者用飞书多维表格记录所有会议台账。但这些都建立在基础链路跑通的基础上前期不建议一上来就全做。1.2 技术路线选型自建应用还是Webhook机器人很多第一次接触这类对接的朋友会纠结一个问题飞书那边到底应该用“群自定义机器人”还是“企业自建应用”这个选择直接决定后面能做多少事情。飞书的群自定义机器人Webhook机器人使用门槛极低在群里添加一个机器人拿到Webhook地址用POST发一串JSON就能向群里推消息。但它只能“发”不能“收”也没法调用飞书开放平台上的API更拿不到事件回调。也就是说用Webhook机器人做单向通知没问题像每天定时推送会议提醒、日报汇总够用但要做“用户在群里发指令机器人去腾讯会议建会”这种双向交互就完全不够了。企业自建应用才是完整对接的正路。创建应用后拿到App ID和App Secret既可以用机器人身份发消息也能订阅飞书事件比如收到消息事件、审批通过事件还能调用通讯录、云文档、日历等API。缺点就是配置环节多一些权限申请要走一遍审核。不过一旦跑通后面的扩展空间完全不在一个量级。腾讯会议侧其实没有太多选择余地它就是一套标准REST API加回调事件。要对接就得去腾讯会议开放平台注册应用拿到身份凭证。注意腾讯会议的开放接口一般需要企业版账号才有接口权限个人免费版基本调不了API这个在立项前就要跟管理员确认清楚。1.3 对接方案的整体架构我把整个系统的数据流描述为飞书负责“入口”和“出口”腾讯会议负责“会议本体”中间用一个自己的后端服务做翻译和搬运。用户在飞书群里输入的消息通过飞书事件订阅推送给我们部署在后端的服务。后端解析出意图和参数带着用户的身份发起创建会议请求到腾讯会议的REST API。腾讯会议返回会议号和入会链接后后端再调用飞书消息API组装一张会议卡片发回群里。会议结束的那一刻腾讯会议把结束事件POST到我们配置的回调地址后端拿到事件后去拉取会议详情和录制文件信息再调飞书云文档API把结构化内容写入文档。整个链路里飞书侧我们用了一个自建应用后端服务起了Flask后面会上Python代码腾讯会议侧就是一个标准企业应用。服务部署在普通云服务器上就行唯一的要求是公网可访问或者至少能用长连接方式收发飞书事件。如果没有公网IP飞书事件订阅可以用长连接WebSocket代替Webhook回调这招对于个人开发者和内网部署特别友好后面会具体讲。2. 飞书侧准备应用创建、权限申请与Token体系2.1 创建企业自建应用并开通权限飞书侧的准备工作核心是在飞书开放平台open.feishu.cn上创建一个“企业自建应用”。登录管理员账号后进入开发者后台选择创建企业自建应用填上应用名称和描述然后进入应用详情页。创建完成之后首先要做的是在“应用能力”里添加一个“机器人”能力。很多初学者会忽略这一步后面调用消息API的时候报“bot not found”之类的错误其实就是因为应用没有启用机器人能力。启用了机器人之后应用在飞书里就有了一个机器人身份可以被添加到群聊里也才能以机器人身份发送消息。接下来是权限管理这是飞书开放平台上最容易绕晕的地方。飞书的权限控制做得非常细应用每调用一类资源都需要申请对应的权限点。比如你要在群里发消息需要申请“获取与发送单聊、群组消息”权限im:message和“以应用的身份发消息”权限im:message:send_as_bot要读写云文档需要申请“查看、评论、编辑和管理云文档”权限docx:document和“查看、评论、编辑和管理云空间文件”权限drive:drive要读取用户发给机器人的消息内容需要申请“接收群聊中机器人消息事件”权限im:message.group_at_msg和“接收用户发给机器人的单聊消息事件”权限im:message.p2p_msg。权限申请提交之后不是马上生效的。飞书的机制是修改完权限配置后需要创建应用版本并发布等企业管理员在管理后台审核通过新增的权限才会真正生效。这个点经常坑到人——本地调试时调一个接口返回权限不足查半天发现是应用版本没有重新发布。所以建议流程是先一次性把可能用到的权限都申请好再发布版本避免来回折腾。2.2 理解两套Tokentenant_access_token与user_access_token飞书的Token体系是新手最容易卡住的地方。它有两套凭证虽然都叫Token但使用场景和权限边界完全不同。第一套叫tenant_access_token意思是“应用身份凭证”代表“这个应用”在飞书里的身份。你用App ID和App Secret调用一个固定的接口POST /open-apis/auth/v3/tenant_access_token/internal就可以获取。拿到它之后可以用应用的身份发消息、建文档、读通讯录。它的有效期是两小时过期后需要重新获取。第二套叫user_access_token意思是“用户身份凭证”代表“某个具体的用户在授权之后”授予应用的临时通行证。这套Token的获取要复杂一些需要走OAuth流程先在浏览器里打开一个授权链接让用户登录同意腾讯返回一个授权码用授权码换Token。用户身份Token能访问用户私有空间的数据比如用户自己的云文档、多维表格记录很多文档类接口必须用它才能调通。结合本文场景如果你只是想用机器人往群里推会议卡片tenant_access_token就够了。但如果你要做“会议纪要写进某个用户的云文档”这种操作大概率需要user_access_token。很多人第一次配置Dify这类AI工具访问飞书云文档时卡在授权凭证上拿不到数据本质就是没搞明白以用户身份去开别人的文档必须走OAuth拿到用户的Token而不是拿一个应用身份的Token硬闯。获取tenant_access_token的Python代码非常简单如下import requests def get_tenant_access_token(app_id: str, app_secret: str) - str: url https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal payload { app_id: app_id, app_secret: app_secret } resp requests.post(url, jsonpayload, timeout5) data resp.json() if data.get(code) ! 0: raise RuntimeError(f获取tenant_access_token失败: {data}) return data[tenant_access_token]这个Token建议做缓存不要每次请求都重新获取。飞书侧对获取Token的接口有限流短期频繁调用会直接报错。实际操作中我用了一个内存字典加过期时间或者直接存Redis逻辑很简单距离过期时间还剩5分钟时就主动刷新。2.3 事件订阅接入方式长连接优先Webhook兜底飞书把用户消息推给我们后端服务靠的是“事件订阅”机制。在自建应用的“事件与回调”页面里可以添加事件类型比如“接收消息”事件im.message.receive_v1。添加之后飞书会在消息发生时把事件内容推送到我们配置的地址。这里有一个非常重要的选择Webhook方式和长连接WebSocket方式。Webhook方式要求你有一个公网可访问的HTTPS地址飞书会把事件POST到这个地址。它的优点是稳定、可控适合生产环境缺点是你得有一台能暴露公网的服务器还要配置域名和证书开发调试阶段比较麻烦。长连接方式就不需要公网回调地址。飞书自建应用的事件订阅里有一个“使用长连接接收事件”的选项启用后用飞书官方SDK在你的后端服务里跑一个WebSocket客户端飞书会主动建立连接往下推事件。这种方式对本地开发、内网部署特别友好开发和测试阶段几乎零成本我自己在项目前期就是靠这个方式把流程跑通的。配置长连接也很简单飞书官方提供了Python SDKlark-oapi核心代码大致是from lark_oapi.ws import Client as WSClient def handle_message(data): # 处理收到的消息事件 print(data) ws_client WSClient( app_idyour_app_id, app_secretyour_app_secret, event_handlerhandle_message, ) ws_client.start()需要注意无论Webhook还是长连接如果启用了加密Encrypt Key推送过来的事件内容就是加密的。长连接模式下SDK会帮忙解密Webhook模式就需要自己处理解密逻辑。我在项目里用了一个简单的AES解密函数来解开飞书的加密报文逻辑不复杂但拼错一个Key或初始向量就会全盘乱码这个后面排查章节会专门讲。3. 腾讯会议侧准备开发者认证、应用创建与鉴权签名3.1 开启开发者权限并创建应用腾讯会议开放平台的准备工作和飞书侧大同小异但有一个门槛要提前确认腾讯会议开放API目前主要面向企业版和商业版的用户开放个人免费版账号大概率申请不到接口权限。所以第一步不是写代码而是先让企业管理员确认自己所在的企业版套餐是否包含“开放平台”权限如果不包含需要先联系商务开通不然应用创建页面都进不去。确认之后登录腾讯会议开放平台meeting.tencent.com的开发者板块或者企业管理员后台创建一个企业级应用。创建成功后开放平台会给你生成一串关键凭证App ID也叫Secret ID和App Secret也叫Secret Key。这两个值后面调用API时做签名要用务必妥善保存不要硬编码到前端代码或者提交到Git仓库里。腾讯会议开放平台的应用不像飞书那样区分“企业自建应用”和“商店应用”它就是个单纯的应用凭证。你需要重点关注的是应用权限范围。有的企业会限制应用只能调用某些API比如只允许创建会议、不允许修改会议或获取录制文件。申请应用之后对照你的需求清单在开放平台里把你的应用权限勾选完整。3.2 腾讯会议API的鉴权原理与签名计算腾讯会议的API鉴权和飞书不太一样飞书是一个Authorization: Bearer token搞定腾讯会议要求请求头里带一堆自定义Header还要做一次SHA256签名。我用的版本要求这些HeaderX-TC-Key应用的App ID。X-TC-Nonce随机字符串每次请求都不同用来防重放攻击。X-TC-Timestamp发起请求的Unix时间戳单位是秒。X-TC-Signature签名值具体算法是把app_id timestamp nonce secret_key按固定顺序拼接之后做SHA256再转成十六进制字符串。Authorization: Bearer userid这个Header写的是调用者对应的腾讯会议用户ID一般是企业里的某个成员腾讯会议API会把这个请求看作是该成员发起的操作。签名串拼接顺序这一点谨记以你当前版本开放平台文档为准。我一开始就是照着一个老版本的博客文章写的结果签名一直验证失败后来才发现新版要求的拼接顺序里timestamp和nonce换了位置。所以最稳妥的做法是到你自己的开放平台应用详情页里找到“接口鉴权说明”或者“签名算法”文档对照着拼一遍。如果签名计算正确构造请求头就会像下面这样import hashlib import time import random import string import requests def build_headers(app_id: str, app_secret: str, user_id: str): timestamp str(int(time.time())) nonce .join(random.choices(string.ascii_letters string.digits, k8)) raw f{app_id}{timestamp}{nonce}{app_secret} signature hashlib.sha256(raw.encode(utf-8)).hexdigest() return { X-TC-Key: app_id, X-TC-Nonce: nonce, X-TC-Timestamp: timestamp, X-TC-Signature: signature, Authorization: fBearer {user_id}, Content-Type: application/json, }每个请求头缺一不可Content-Type漏掉会导致接口返回415。另外注意时间戳一定要用服务器当前时间误差太大容易被拒绝nonce每次请求都要重新生成如果复用同一个nonce腾讯会议服务器会认为是重复请求直接拒绝。3.3 回调事件配置验证与解密腾讯会议的会议结束事件、创建事件等都是通过回调通知来推送的。在开放平台的应用配置页里有一个“回调地址”的配置项。配置完成后腾讯会议会立刻发一个验证请求到你的地址你需要按规定的格式返回验证才算通过。这个验证机制很多第一次对接的人会卡住。腾讯会议回调的验证流程大体是腾讯会议POST一个JSON到你的回调地址JSON里包含一个check_value字段或者一个加密后的验证串你的回调服务收到后需要按文档要求解密并算出一个respond_value返回给腾讯会议腾讯会议确认无误之后才会把验证置为成功。如果配置了加密推荐开启回调事件的body就是一个AES加密串。我实际使用的解密过程是先用Base64解码密文再用AES-ECB模式密钥取应用的Secret Key注意对齐长度最后得到JSON明文。解出来的内容类似{ event_type: meeting.ended, meeting_id: 1234567890, meeting_info: { meeting_code: 123456789, subject: 周会, start_time: 1621044000, end_time: 1621047600, host_user_id: host001, ... } }这里有一个经验腾讯会议的Webhook回调对响应时间要求比较紧建议回调服务收到请求后先立刻返回约定响应再异步去处理业务逻辑比如拉取录制文件、写飞书文档。如果同步处理耗时超过几秒腾讯会议那边可能直接判定回调失败之后的重试策略也会让人头疼。我在实际项目里把回调处理放进了一个任务队列响应速度稳定在500毫秒以内效果很好。4. 核心功能实现在飞书里发起会议在文档里沉淀纪要4.1 飞书机器人接收命令并创建腾讯会议场景打通之后核心功能的实现就顺理成章了。我先说最常用的一条用户或群成员给飞书机器人发一条消息机器人解析出会议主题和时间然后去腾讯会议创建预定会议。在飞书事件订阅里我订阅了im.message.receive_v1事件。在后端收到消息事件之后先判断聊天类型是单聊还是群聊然后取event.message.content字段里的文本内容。飞书推送的文本消息content其实是一段JSON字符串里面有一个text字段才是真正的消息文本。解析之后用正则或者简单的关键词匹配识别出会议主题和时间。比如我定义了命令格式/book 周会 2025-06-20 15:00。解析出主题和时间之后把时间字符串转成UTC时间戳然后调用腾讯会议的创建会议接口。腾讯会议创建会议的API是POST /v1/meetings请求体里核心字段有meeting_info_list会议信息列表一次可以创建多个会议。我们场景里一次只创建一个。subject会议主题。type会议类型0表示立即会议1表示预定会议。我们这里用1。start_time会议开始时间的Unix时间戳秒。注意一定要转成UTC时间腾讯会议API是按照UTC时间戳来理解的。我曾经直接把本地时间的datetime.timestamp()传过去结果会议开始时间整整错了8个小时。duration会议时长单位分钟。media_type媒体类型1代表视频会议。settings一些会议设置比如入会是否静音、是否允许成员发言等。创建成功的返回里有两个关键字段meeting_id是会议的唯一ID后面查详情、拉录制都靠它meeting_code是9位或10位的入会号码join_url是入会链接。把它们存下来备用。4.2 会议信息卡片回传与入会引导拿到腾讯会议返回的会议信息之后下一步就是把信息组装成一张飞书消息卡片发回给用户或群。飞书消息接口是POST /open-apis/im/v1/messagesreceive_id_type可以是open_id、user_id、chat_id等。单聊场景用用户的open_id当接收人群聊场景用群的chat_id。msg_type我用的是interactive也就是消息卡片卡片内容是一段JSON。卡片JSON里我用了一个div模块放会议主题和时间一个link模块放入会链接再把meeting_code用醒目字号展示出来。一个精简版卡片大概是这样的{ msg_type: interactive, receive_id: oc_xxxxxxxxxxxx, content: {\config\:{\wide_screen_mode\:true},\header\:{\title\:{\tag\:\plain_text\,\content\:\会议预约成功\}},\elements\:[{\tag\:\div\,\text\:{\tag\:\lark_md\,\content\:\**主题**周会\\n**时间**2025-06-20 15:00\\n**会议号****123456789**\}},{\tag\:\action\,\actions\:[{\tag\:\button\,\text\:{\tag\:\plain_text\,\content\:\点击入会\},\type\:\primary\,\url\:\https://meeting.tencent.com/dm/xxxx\}]}]} }这里有一个细节content字段是一个字符串里面嵌套了JSON所以外层要用json.dumps把字典转成字符串。很多同学第一次写这个接口会忘记这个嵌套层级直接传了个字典对象导致飞书报错。卡片发出去之后用户在群里就能看到完整的会议信息点按钮直接入会不需要再去找会议号复制链接了。人在收到信息时的注意力是有限的一张排版清晰的卡片比一段纯文本的会议信息要好懂得多。4.3 会议结束回调自动把纪要写进飞书云文档会议结束后腾讯会议会触发meeting.ended事件到我们配置的回调地址。我在回调处理函数里做了这么几件事第一步解析事件类型。因为同一个回调地址可能收到创建会议、结束会议、录制完成等多种事件所以要先判断event_type。第二步如果事件类型是会议结束用事件里的meeting_id去调用腾讯会议的“获取会议详情”接口和“获取录制文件”接口。会议详情接口返回参会人列表、开始结束时间录制文件接口返回录制地址、录制文件大小等。第三步把这些信息整理成结构化数据调用飞书云文档API创建一份归档文档。飞书文档的创建接口是POST /open-apis/docx/v1/documents创建成功后会返回一个document_id然后可以用POST /open-apis/docx/v1/documents/{document_id}/blocks/{block_id}/children往文档里追加标题和段落块。实际写文档时我推荐先创建一个空文档再分段写入。写入内容的顺序是一级标题会议主题。信息段落会议时间、主持人、会议号。列表参会人。链接段落录制回放地址。这一套流程跑通之后真正的收益才体现出来以前会议结束信息丢失的开始现在会议结束归档文档自动出现在飞书里链接自动发到群里谁想看回放、谁要补纪要都有据可查。4.4 关于“飞书机器人发送表格”的落地姿势网上经常有人搜“飞书机器人发送表格”这个需求在对接场景里其实是个高频点。比如你可能希望会议结束后把一张参会人名单表格推送到群里。这里我给出几种实测有效的方案按推荐程度排序。第一种是写云文档再把链接推到群里。这也是我最推荐的方式。先用飞书电子表格API或者多维表格API把结构化数据写入然后调用飞书消息接口发送一个包含文档链接的卡片消息。好处是数据可筛选、可协作、可回看不用每次重新生成。第二种是渲染成图片再发。适合那种一次性查看、不需要二次编辑的场景。你可以用服务端工具把HTML表格渲染成PNG或者JPEG然后调用飞书图片消息接口发送。稳定性和兼容性都不错但生成过程多了一道渲染步骤。第三种是纯文本等宽排版。最省事但体验一般。飞书消息里用空格对齐表格列一旦中英文混排列就全歪了只适合临时的调试场景不建议作为正式方案。这里要注意飞书消息卡片本身对表格的原生支持有限不同版本的客户端渲染效果差异也大。与其在卡片里硬塞表格不如用“链接到云端表格”的思路体验和可维护性都好得多。我后来把会议台账直接放到了多维表格里机器人建会之后自动新增一条记录会议编号、时间、入会链接都是独立字段后续做统计分析非常方便。5. 常见问题与排查技巧实录5.1 鉴权失败HTTP 200但业务code非0对接这种开放平台最迷惑人的一种情况是HTTP状态码是200请求也发出去了但返回的JSON里业务code是一个非0的错误码。很多人习惯先看HTTP状态一看200就以为成功了结果解析数据时发现是空的。飞书的返回结构一般是{code: 0, msg: success, data: {...}}code为0才代表成功。腾讯会议的结构也类似只不过字段名可能不同但思路一致先校验业务码再取数据。排查时把完整响应体打印出来看根据错误码去查对应文档常见的几种原因是Token过期或无效检查获取Token的时间看是否超过了有效期。权限点没生效重新发布应用版本等几分钟再试。参数格式错误比如时间戳用了毫秒而API要求的是秒。签名错误检查签名串拼接顺序和密钥是否匹配。我还在服务里做了一个统一的响应日志中间件每次调用飞书或腾讯会议API都会把URL、请求体、响应体完整记录到本地日志文件。排查问题的时候这条日志能节省大量时间。5.2 回调验证失败或收不到回调腾讯会议回调验证失败我遇到的情况有几种一是回调地址响应太慢。腾讯会议的验证请求有超时限制建议回调服务先返回一个固定success再异步处理业务。配置回调地址的时候可以先在本地起一个最简单的Flask服务只返回固定JSON确认验证通过后再逐步加业务逻辑。二是加密配置问题。如果开启了AES加密但解密逻辑有问题腾讯会议的验证请求会一直失败。排查方法很简单先临时关闭加密看验证是否通过如果通过说明加密环节出了问题。三是公网地址没有配置证书。腾讯会议的回调要求是HTTPS如果用IP地址或者没证书的域名大概率验证不通过。这种情况可以先用内网穿透工具把本地服务暴露出去做验证但正式环境还是建议上正规域名和证书。飞书Webhook回调也有一套验证机制首次配置的时候飞书会往你的地址发一个包含challenge的验证请求你要原样把challenge字段返回配置才能保存成功。如果用的是长连接模式这个验证步骤就省掉了。5.3 权限不足、找不到文档、不能访问对应空间对接飞书云文档这类API时报错最常见的是“permission denied”或者“document not found”。遇到这个错误第一步检查应用是否申请了对应权限点比如docx:document和drive:drive第二步检查应用版本是否已经发布并且被审核通过第三步检查你用的Token是应用身份还是用户身份——调用云文档相关接口时如果文档在用户的私人空间或者分享范围受限就必须用user_access_token。腾讯会议侧也有类似的权限问题。比如创建会议成功后想查录制文件但返回“没有权限”很可能是你的应用没有申请录制文件相关的接口权限。如果确定权限没问题再看调用者对应的用户ID是否真的参加了会议腾讯会议的权限模型里应用不能越权获取其他用户创建的会议。5.4 腾讯会议摄像头、麦克风、录制设置问题有同事问过“腾讯会议不能使用电脑自带摄像头吗”这个问题。先说结论这大概率不是API的问题而是客户端本机的权限设置。用腾讯会议API创建会议时API可以在settings里控制一些行为比如mute_enable_join控制在入会时静音allow_unmute_self控制成员能否自己解除静音但API没法强制打开某个参会者的摄像头。参会者入会之后摄像头能否使用取决于他自己的设备权限、浏览器权限、腾讯会议客户端的设置。如果遇到无法使用自带摄像头的情况排查顺序是检查操作系统是否给了腾讯会议摄像头权限Windows看“隐私设置”里的相机访问macOS看“系统设置”里的隐私与安全性再检查电脑上是否有多个摄像头设备腾讯会议当前选中的是不是那一个最后看会议设置里是否被主持人设为了“关闭摄像头”。API层面能做的是尽量在创建会议时把设置项配好减少与会者进入后的操作成本。5.5 请求限流与生产环境稳定性上线之后还要面对一个现实问题开放平台都有接口限流。飞书和腾讯会议不会在文档里把每一条QPS写得面面俱到但你如果一次性大量调用一定会触发限流。飞书的常见限流策略是应用维度和用户维度。我处理的方法是把tenant_access_token做缓存避免每个请求都去获取一次Token同时在调用写操作时做小批量的并发控制比如发消息接口一次只发一条不要用多线程并发刷。腾讯会议的限流触发后一般会返回特定的错误码或HTTP 429。我的方案是做一个简单的重试机制遇到限流错误退避1秒、2秒、4秒依次重试最多重试3次。如果多次重试还是失败就把任务放到队列里缓存等服务空闲了再补执行。另外生产环境的稳定性不光靠重试还要靠监控。我给整个服务加了一个心跳接口用定时任务每5分钟调用一次如果连续几次没有心跳就告警。告警渠道直接用了飞书机器人发到运维群里。这样对接服务即使挂了也能第一时间被发现不会出现会议都建好了、卡片迟迟没弹出的诡异情况。回头总结一下这次实践最想分享的一条经验是这种跨平台对接项目架构上没有难度难点全在细节。Token的有效期、鉴权签名的拼接顺序、时间戳的单位、回调验签的格式任何一个地方没对上排查起来都可能耗费大半天。所以动手前先把两边权限模型和Token模型理清楚再决定功能的实现顺序。先跑通一条最简单的链路比如“飞书发消息→创建腾讯会议→回传卡片”然后再逐步加会议归档、主动通知这些复杂功能。后面我们还计划把会议录制转写后的文本接给大模型做纪要摘要再把摘要自动写回飞书文档等跑通了再来分享。