1. 项目概述当会议遇上“对话式AI”如果你和我一样每天要开好几个会那你肯定对“会前约人、会中记录、会后跟进”这一套繁琐流程深恶痛绝。光是协调一个多方会议的时间就能在聊天软件里来来回回发几十条消息。更别提会后整理纪要、分配任务经常是会议一结束热情就消退任务就搁置。所以当我看到“腾讯会议Skill”这个概念时第一反应是这玩意儿要是真能做好绝对是生产力的一次大解放。简单来说腾讯会议Skill你可以把它理解为一个内嵌在腾讯会议里的“智能会议助手”。它不是一个独立的应用而是一个基于自然语言交互NLP的模块化能力。它的核心目标就是让你能用“说人话”的方式去管理会议的全生命周期。想象一下你不用再在复杂的菜单里点来点去而是直接对会议软件说“帮我约一下老王、老李和小张下周二下午三点讨论Q3产品规划记得提前把需求文档发给他们。” 然后这个Skill就能自动解析你的意图创建会议、发送邀请、附加文档一气呵成。这背后是“Skill”这个概念的兴起。最近在AI圈特别是围绕大型语言模型LLM的应用开发中“Skill”或“插件”模式非常火热。它本质上是一种让AI模型获得“调用外部工具能力”的标准化接口。比如一个“天气查询Skill”让AI能调用天气API一个“邮件发送Skill”让AI能操作你的邮箱。腾讯会议Skill就是专门为“会议管理”这个垂直场景打造的一套标准化能力集合。它把创建会议、邀请成员、录制会议、生成纪要、创建待办等一系列离散的操作封装成了一个个可以被自然语言指令触发的“技能”。这个项目的价值远不止是“语音控制开会”那么简单。它触及了协同办公最深层的痛点流程中断和信息孤岛。传统的会议管理工具日历、IM、文档、任务列表是割裂的操作是手动的信息是碎片化的。而一个设计良好的Skill模块能够以对话为纽带串联起这些工具和流程实现真正的“一句话办事”让组织者从机械操作中解脱出来更专注于会议内容本身。2. 核心设计思路从“功能罗列”到“意图驱动”开发这样一个Skill最忌讳的就是把腾讯会议现有的所有功能按钮简单地用语音指令重新实现一遍。那只是换了一种操作方式并没有创造新价值。真正的智能在于理解用户的意图并自动完成一连串关联操作。2.1 意图识别听懂用户的“弦外之音”这是整个Skill的“大脑”。用户的自然语言指令往往是模糊、省略甚至包含歧义的。例如“跟团队同步一下进度”这句话背后至少包含几个关键信息需要补全会议主题“项目进度同步”。参会人“团队”具体指谁需要关联组织架构或常用联系人分组。时间没说时间那可能是“尽快”或“找一个大家都有空的时间”。议程是否需要提前准备材料我们的设计思路是建立一个“意图-槽位”填充模型。意图用户想要完成的核心动作如ScheduleMeeting安排会议、SummarizeMeeting总结会议、CreateActionItem创建待办。槽位完成该意图所必需的参数。例如对于ScheduleMeeting槽位包括topic主题、participants参与者、start_time开始时间、duration时长、agenda议程等。系统的工作流程是首先通过NLP模型识别用户语句的意图然后像侦探一样从语句中提取或通过多轮对话询问补全所有必需的槽位信息。这里的一个关键技术点是上下文理解。如果用户先说“明天下午三点开会”然后说“把需求文档加进去”系统需要能理解“加进去”指的是附加到刚才提到的那个会议里。实操心得槽位设计的颗粒度槽位不是越细越好。初期我们曾把location地点设计为必填槽位但发现超过90%的线上会议地点都是“腾讯会议”这导致了大量不必要的确认对话。后来我们将其改为可选槽位并默认填充为“线上会议”只有当用户明确说“线下会议室”时才触发询问体验流畅度大幅提升。经验是用真实对话数据去反推槽位设计默认值是你的好朋友。2.2 技能编排让多个Skill像乐团一样协作一个复杂的用户指令往往需要调用多个基础Skill协同完成。这就是“技能编排”或“工作流引擎”负责的事。例如用户指令“刚才的会议很棒把纪要发给没来的人并给我们几个分配一下任务。”这个指令会被拆解成以下工作流识别意图这是一个复合意图包含SendSummary和AssignTasks。执行序列首先触发SummarizeMeetingSkill基于刚才会议的录音和转录生成结构化纪要。然后触发GetAbsenteesSkill对比会议邀请列表和实际参会人名单找出未参会者。接着触发SendEmailSkill将纪要通过邮件发送给未参会者。同时解析指令中的“给我们几个分配任务”触发ParseActionItemsSkill从会议转录中提取出诸如“张三负责下周更新PRD”、“李四需要联系客户确认需求”这样的任务项。最后触发CreateTodoSkill将这些任务项同步到腾讯会议待办或关联的腾讯文档、TAPD等任务管理工具并指派给对应责任人。这个编排引擎需要解决几个问题顺序执行还是并行执行发邮件和创建任务可以并行如何传递数据纪要内容需要从Skill A传递给Skill B和C某个Skill执行失败怎么办需要有错误处理和回滚机制。我们采用了一种基于有向无环图DAG的工作流设计每个Skill是一个节点节点间通过共享的上下文数据池传递信息。2.3 个性化与记忆让你的助手更懂你一个冷冰冰的、每次都要重复询问相同信息的助手是令人沮丧的。因此Skill必须具备“记忆”和“个性化”能力。用户偏好记忆比如用户总是喜欢在会议开始前10分钟设置提醒那么当他说“开会”时系统可以自动补上“提前10分钟提醒所有参会人”这个动作。上下文记忆在同一个会话中用户提到的实体如项目名、人名需要被记住。例如用户说“为‘火星计划’项目创建一个评审会”之后又说“把刚才说的材料加进去”系统需要知道“材料”关联的是“火星计划”项目的文档。团队习惯学习如果某个团队开会总是习惯先过一下“上周待办”那么为该团队创建会议时Skill可以建议将“回顾上周待办”作为默认议程项。实现这一点需要在架构上设计一个独立的“用户状态与画像”服务持久化存储这些偏好和上下文并在每次意图识别时作为输入信息提供给模型。3. 关键技术模块拆解与实现3.1 自然语言理解模块这是入口我们采用了“预训练大模型 微调 业务规则”的混合架构。基础模型选用在中文理解和指令跟随方面表现优秀的开源或商用大模型作为基座。它负责将用户输入转换成结构化的语义表示。意图识别微调使用大量标注好的对话数据用户query 意图标签对基座模型进行有监督微调。这部分数据质量至关重要需要覆盖各种口语化、省略式的表达。# 伪代码示例意图分类模型调用 def recognize_intent(user_query, conversation_history): # 将历史对话和当前query拼接 prompt f 历史对话 {conversation_history} 用户最新输入{user_query} 请判断用户的意图是什么选项安排会议、查询会议、修改会议、总结会议、创建待办、其他。 只输出意图名称。 response call_llm_api(prompt) return response.strip()槽位填充与实体识别对于识别出的关键意图我们训练了专门的命名实体识别模型用于抽取时间、人名、项目名等槽位值。同时会与腾讯会议的后台数据通讯录、日历事件进行联动校验和补全。例如识别出“老王”会去通讯录中查找并确认唯一ID。避坑指南NLU的冷启动问题项目初期最头疼的就是没有足够的标注数据来训练意图识别模型。我们的解决方案是“规则引擎兜底主动学习”。先人工编写一批核心意图的正则表达式和关键词规则确保基础功能可用。然后将所有未被规则覆盖的用户query归类为“其他”意图记录下来由标注团队快速审核和标注每周迭代注入到训练集中。这样模型的智能边界就像滚雪球一样不断扩大。3.2 会议上下文感知模块这是Skill的“眼睛”让它知道“刚才”、“下周”、“我们部门的会”具体指什么。实时会议上下文当用户在会议中说“把刚才说的那条记下来”Skill需要接入会议的实时语音转写ASR流能够定位“刚才说的那条”大致对应的时间段和文本内容。这涉及到语音流的分段、索引和语义检索技术。日历与历史上下文Skill需要有权读取用户的日历信息。当用户说“把我明天的第一个会推迟半小时”它要能查询到用户明天第一个会议的具体信息。这需要与腾讯会议日历API深度集成并处理好权限和隐私问题。文档与项目上下文当用户说“把Q3规划文档附上”Skill需要能访问用户关联的云文档如腾讯文档、微盘并能通过文档标题或内容语义搜索找到“Q3规划文档”。这里涉及文档权限的鉴权和文档内容索引技术。我们构建了一个统一的“上下文检索服务”它聚合了日历、会议录制、文档、聊天记录等多种数据源并建立了统一的索引。当Skill需要理解一个指代性短语时就向这个服务发起查询。3.3 技能执行与集成模块这是Skill的“手和脚”负责将解析好的意图转化为实实在在的操作。技能API封装将腾讯会议的核心功能创建/修改/删除会议、邀请成员、开始录制、云录制管理、设置联席主持人等封装成一个个纯净的、功能单一的API。这些API就是最基本的“原子Skill”。外部系统连接器为了实现全流程管理必须集成外部系统。我们为腾讯文档、企业微信、TAPD、腾讯待办等开发了标准的连接器。这些连接器负责身份认证、API调用和数据格式转换。例如CreateTodoSkill内部就是调用了腾讯待办的创建任务API。执行引擎接收来自编排引擎的工作流DAG按顺序调用各个原子Skill或连接器。它需要管理任务队列、处理超时和重试、记录执行日志并将最终结果汇总返回。一个创建会议并发送预读材料的复合技能执行流程示例用户输入“下周一10点和产品团队开需求评审会记得把PRD发给大家看看。”NLU模块输出意图ScheduleMeetingWithMaterial槽位time下周一10:00,participants产品团队,topic需求评审,materialPRD。编排引擎生成工作流Step 1:ResolveTeamSkill- 将“产品团队”解析为具体的成员列表。Step 2:SearchDocumentSkill- 在用户的腾讯文档中搜索标题或内容包含“PRD”的最新文档。Step 3:ScheduleMeetingSkill- 使用时间、成员、主题创建会议。Step 4:AttachMaterialSkill- 将找到的文档链接附加到会议描述中。Step 5:SendCalendarInviteSkill- 向所有成员发送日历邀请内含会议链接和文档链接。执行引擎按序执行任何一步失败都会触发预定义的错误处理如通知用户“未找到PRD文档是否继续创建会议”。4. 典型应用场景与实操对话示例光讲原理可能有点干我们来看几个具体的、你明天就能想象自己会用到的场景。4.1 场景一复杂会议的轻松安排用户语音或文字输入“帮我约上海的王经理和北京研发部的张工、李工下周三或周四下午用1小时时间讨论一下‘天枢’项目下一阶段的接口联调方案。会议标题就叫‘天枢项目接口联调方案讨论’。提前把技术方案文档发给他们并设置会后10分钟提醒我写纪要。”Skill处理过程与回复解析识别意图为ScheduleMeeting。槽位提取参会人跨地域多成员、时间范围下周三或周四下午、时长1小时、主题、预读材料、会后任务。查询与确认Skill会查询“王经理”、“张工”、“李工”在企业通讯录中的具体信息并检查他们下周三、周四下午的忙闲状态。智能建议Skill回复“找到三位参会人。他们下周三下午2-4点均有空周四下午3-5点均有空。建议定在下周三下午2:00-3:00。已在你的腾讯文档中找到最新版的‘天枢项目技术方案V2.3’将作为预读材料附加。确认创建吗”用户“确认就用这个时间。”Skill执行创建会议发送带文档链接的邀请并自动在用户的腾讯待办中创建了一条“下周三下午3:10 - 撰写‘天枢项目接口联调方案讨论’会议纪要”的任务。4.2 场景二会议中的即时协作会议中用户说“刚才我们决定的由小李负责跟进客户反馈这个记一下。另外把白板上画的这个架构图保存下来放到会议纪要里。”Skill处理过程上下文捕捉Skill实时转写会议语音。当听到“刚才我们决定的”它结合语音流的时间戳回溯前30秒的对话内容提取出关键决策“小李负责跟进客户反馈”。任务创建自动触发CreateActionItemSkill生成一条待办“【负责人】小李 - 【任务】跟进客户反馈 - 【来源会议】当前会议”。内容提取对于“白板上的架构图”Skill需要调用腾讯会议的“智能白板”API获取当前白板页面的截图或矢量图形。纪要更新将“决策事项”和“白板架构图”作为增量内容实时更新到本次会议的临时纪要中。所有参会者可以在侧边栏实时看到这些更新。4.3 场景三会后自动化闭环会议刚结束用户说“把今天的会议纪要和待办事项发到我们的项目群里并相关责任人。”Skill处理过程素材整合触发SummarizeMeetingSkill结合完整的会议录音、转写文本、聊天记录、共享屏幕截图、白板内容生成一份结构化的最终纪要包含会议主题、参会人、时间、议程、讨论要点、决策项、待办事项。待办同步将会议中标记的所有待办事项同步到团队使用的TAPD或腾讯文档项目计划表中并自动指派给责任人。消息推送触发SendGroupMessageSkill将纪要和待办列表摘要一键发送到指定的企业微信群并自动待办的责任人。消息格式清晰可直接点击跳转到详细纪要和任务详情页。5. 开发与集成中的挑战与解决方案在实际构建这样一个Skill模块时我们遇到了不少坑这里分享一些核心的挑战和我们的应对之策。5.1 挑战一语义理解的模糊性与容错性用户的语言是灵活多变的。“快点搞个会”和“请紧急召集一次会议”表达同一个意图。更麻烦的是错误输入比如“帮我约一下昨天下午三点的会”时间矛盾。我们的解决方案多模型融合不单纯依赖一个LLM。我们结合了基于规则的快速匹配处理高频、固定句式、传统机器学习分类模型处理常见变体和大语言模型处理长尾、复杂句式。形成一个决策漏斗兼顾速度和精度。置信度与澄清机制为每次意图识别的结果输出一个置信度分数。当分数低于阈值如0.7时Skill不会盲目执行而是会发起澄清式询问。例如用户说“取消会议”Skill会问“您是想取消今天下午3点的‘项目周会’还是明天上午10点的‘客户沟通会’” 这比直接操作错误安全得多。强大的时间/实体归一化我们投入了大量精力构建一个鲁棒的时间表达式解析器能将“下礼拜一”、“三天后”、“国庆节后第一个工作日”准确转换为具体的日期时间。对于人名、项目名等实体则与企业通讯录、项目管理系统做实时联动查询和消歧。5.2 挑战二系统集成的复杂度与安全性Skill要调用腾讯会议内部API和多个外部系统文档、邮件、任务如何保证集成的稳定、高效和安全我们的解决方案面向Skill的API网关我们不是让Skill直接调用各个业务系统的原始API而是建立了一个统一的“Skill API网关”。这个网关负责协议转换将内部不同的API协议HTTP/gRPC/等统一成Skill模块易于调用的RESTful格式。认证鉴权集中处理OAuth 2.0等复杂的授权流程。Skill只需持有一次用户授权后的令牌网关会负责令牌的刷新和向下游系统的传递。限流熔断防止某个Skill的异常调用打垮下游业务系统。日志与监控统一收集所有调用链路的日志便于问题排查。权限最小化原则每个Skill在申请权限时都必须明确声明其需要的数据和操作范围例如“读取会议日历”、“创建腾讯文档任务”。并向用户透明展示。Skill无法越权访问它不需要的数据。异步化与队列对于耗时的操作如生成长达一小时的会议摘要Skill不会同步等待而是提交任务到队列后立即返回“任务已受理摘要生成后将通知您”。这保证了对话交互的即时性。5.3 挑战三用户体验的流畅度如果用户每说一句话都要等待好几秒才能得到响应那么这个功能注定失败。延迟是体验杀手。我们的解决方案流式响应与渐进式理解对于语音交互我们采用流式ASR用户一边说系统一边转写和进行初步的意图识别。可能用户还没说完系统已经猜到了他要“安排会议”并开始准备时间选择器的UI。这种“预加载”极大地减少了感知延迟。本地轻量模型与边缘计算将简单的意图识别如“取消会议”、“静音”模型部署到终端设备或边缘节点实现毫秒级响应。复杂的、需要上下文的理解才上送云端大模型处理。UI与非语音交互的补充并非所有操作都适合语音。例如从100个联系人里选择10个参会人用语音念名字效率极低。因此我们的Skill模块是“多模态”的。当识别到“邀请一些人”这个意图时会在屏幕上弹出一个联系人选择器让用户快速勾选。语音、文字、图形界面GUI三者有机结合才是最佳体验。6. 未来展望从“管理会议”到“赋能协作”目前这个Skill模块还主要集中在会议流程本身的自动化管理上。但这只是一个起点。在我看来它的未来进化方向是成为一个真正的“团队协作智能体”。1. 从“执行者”到“建议者”未来的Skill不仅能听令行事还能主动提出建议。例如分析历史会议数据后它可能会在每周一早上提醒你“根据过往记录每周三下午是团队效率最高的‘深度讨论时间’建议将重要的方案评审会安排在那个时段。” 或者在会议开始前自动提示“本次会议参会人中有两位是新加入项目的同事建议将项目背景文档提前发给他们。”2. 深度融入知识管理会议是组织知识产生的重要场所。Skill可以自动将会议中的决策、待办、分享的文档片段结构化地沉淀到团队的知识库或Wiki中并打好标签。下次有新成员加入项目他可以通过询问Skill快速了解项目历史和关键决策。3. 跨工具工作流自动化现在的Skill主要串联腾讯系产品。未来通过更开放的插件生态或标准化API如OpenAI的Function Calling它可以连接更多工具。比如用户说“根据刚才讨论的方案更新一下Jira上的产品需求状态并在Slack的#产品频道发个公告”Skill可以自动编排跨越多个国内外主流SaaS工具的工作流。4. 情感与参与度分析通过分析会议中的语音语调、发言时长、互动频率Skill可以为主持人提供隐性的反馈“本次会议后半段有两位成员发言显著减少可能参与度下降建议适当提问互动。” 这能帮助提升远程会议的质量。实现这些愿景需要我们在自然语言理解、多模态感知、工作流自动化、数据隐私与伦理等多个技术领域持续深耕。但核心思想不变技术应该隐藏于无形服务于人。最好的智能会议管理就是让你感觉不到“管理”的存在所有繁琐的流程都在你专注讨论时被安静、准确地完成了。回过头看开发这样一个Skill模块最大的收获不是我们实现了多少酷炫的功能而是我们更深刻地理解了一个道理真正的智能化不在于让机器模仿人的所有操作而在于让机器理解人的核心意图并补全那些人类不擅长或不愿做的“连接性”工作。从这个角度看我们写的每一行代码设计的每一次对话都是在为更流畅、更聚焦的人与人之间的协作铺平道路。这条路还很长但每一次看到用户因为少点了几次鼠标、少发了几条提醒消息而露出轻松的表情时我就觉得这事儿做得值。