当会议记录学会“开口说话”：一条语音链路串起的智能办公 Agent 实践

从“翻录音”到“问纪要”，差的不是AI能力，而是编排

老实说，我最早对“AI Agent”这个概念是有些脱敏的。尤其是在办公场景下，看过太多“能听懂人话”的Demo，落地时却变成了一个昂贵的语音版Ctrl+F——能定位到第几分钟谁说了什么，但依然要我自己翻、自己归纳、自己整理待办。

直到上个月，团队成员扎扎实实用腾讯云AI Skills 搭了一条“会议旁听-结构化萃取-TTS语音简报”的完整链路，我才意识到：Agent 和工具的本质区别，不是它有多聪明，而是它能不能替你把闭环走完。

为什么要让会议记录“自己长出嘴巴”

我们团队每周有三次固定复盘会，每次大约40分钟。过去流程是：录制→通义听悟/腾讯云ASR跑文字→人工整理纪要→发群。问题不在识别准确率，而在于整理这个动作太“湿”了——谁负责、截止哪天、卡点是啥，全藏在对话流里，要人肉捞出来。

更隐性但更痛的一点是：整理出来的纪要往往是“存档型”的，而不是“触发型”的。它躺在飞书文档里，等着有人去翻。于是我们萌生了一个朴素愿望：能不能让这条流水线的终点，直接输出一段可听的、带重点标记的语音简报？开车去公司的路上听两分钟，就知道今天自己要跟进什么。

直观对比传统人工整理与Agent链路的总耗时

链路设计：不是堆砌Skill，是定义“交接协议”

我们拆解出的核心动作只有三个，但关键是它们之间传递的数据结构，而非单纯调用API：

1. ASR Skill（语音转写） —— 输入会议录音（单通道，16kHz），输出带时间戳的字幕级文本，以及按句子的置信度评分。这一步腾讯云 ASR 的表现很稳，中文夹杂英文术语（比如“Q3 roadmap”、“CR5”）的识别偏差在可接受范围内。
2. 自定义萃取中间层（非官方Skill，基于大模型Prompt编排） —— 这是最关键的“黏合剂”。我们不把 ASR 全文直接喂给 TTS，而是先做三件事：

• 角色分离：按声纹/语义将句子归给 Speaker A/B/C（会议室多人场景）。
• 决策与待办抽取：只抓“我来决定”“周五前给”“卡在法务”这类触发词，输出结构化 JSON，包含 action_item、owner、deadline、blocker。
• 摘要压缩：强制控制在 200 字以内，并按“背景-结论-下一步”三段式重写，去掉口头禅和重复争论。

JSON结构化数据示意图

这一步我们没有用官方 Skill，而是用腾讯云函数封装了一层 Prompt 模板，把 ASR 输出作为上下文传入。

3. TTS Skill（语音合成） —— 把上一步生成的 JSON 转成自然语言的简报脚本，再调用腾讯云 TTS，选择偏新闻播报风格的音色（我们选了“智美”），最终生成 2-3 分钟的 MP3 文件，自动推送至企业微信群。

数据流链路图

翻车与教训：置信度阈值和“谁负责”的歧义

第一次跑通时，萃取层把“这个可能得张罗一下”解析成了待办，owner 标给了说话人，但实际这句话是建议而非指派。我们后来加了一条硬规则：待办动词必须含“我来”“你来”“周五前”等显性指令，置信度低于 0.75 的直接丢弃，转为“待确认”字段，而非强行填充。

另一个教训是 TTS 脚本的“可听性”。直接把 JSON 拼成“待办一：负责人张三，截止日周四”非常生硬。我们改成了自然语言模板：“张总这边需要周四前确认供应商名单，目前卡在法务审核。”——听起来才像人在汇报。

展示不同置信度阈值下准确率与召回率的变化趋势

效果和可迁移性

这套轻量 Agent 跑通后，每周节省约 1.5 人/天的整理工时。更重要的是，它改变了团队对纪要的消费习惯——语音简报的打开率是图文纪要的 3 倍以上（企业微信后台数据）。

而我认为更具价值的是，这条链路里的“萃取中间层”完全可复用于合同抽取、财报勾稽等场景，只需替换 Prompt 模板和输出 Schema。腾讯云 AI Skills 的价值不在于某一个 Skill 有多强，而在于它提供了标准化的输入输出契约，让开发者能像搭乐高一样定义“交接协议”，而不是每次都在适配不同 API 的签名。

如果要说还有什么遗憾，那就是 TTS 目前还不支持在生成语音时插入“标记音效”（比如重要待办前加一声提示音），我们暂时用静音间隔来替代。但这已经是把 AI 能力从“辅助查看”推向“主动告知”的一小步了。

左侧对比每周工时消耗，右侧对比简报打开率

回过头看，这条“会议录音→结构化萃取→语音简报”的链路，技术门槛并不高，但它让我们团队第一次真切感受到：AI Agent 不是某个酷炫的对话框，而是一条能自动把信息加工成行动指令的“生产流水线”。腾讯云 AI Skills 提供的 ASR、TTS 等标准化能力，像乐高积木一样降低了搭建门槛，而真正决定 Agent 是“玩具”还是“工具”的，是中间那道精心设计的“萃取层”——它把模糊的对话，翻译成了机器和人都能理解的待办清单。

这个过程让我想起早期软件开发从“面向过程”走向“面向对象”的演变。今天的 Agent 实践，本质上是在面向“交接协议”编程——我们不再关心每个 Skill 内部如何实现，只关心输入什么、输出什么、传给谁。当这种思维成为习惯，办公自动化就不再是写死脚本，而是动态编排智能体，让它们像团队成员一样各司其职、接力协作。

当然，这条链路远未完美：多说话人角色分离仍有串音误差，待办抽取对隐含指令（如“这个最好有人跟一下”）依然力不从心，TTS 的情感韵律也还缺少“紧急感”的渐变。但正是这些不完美，指明了下一代 Agent 进化方向——从“听得清”到“听得懂”，从“说得出”到“说得对”。

而腾讯云 AI Skills 生态最迷人的地方在于，它允许我们随时替换或升级链路中的任意环节：比如把萃取层换成更专业的合同要素抽取模板，把 TTS 音色换成更亲切的客服声线，甚至接入生视频 Skill 生成可视化简报。这种“乐高式”的演化能力，让每个开发者都能在自己的业务土壤里，养出独一无二的“全能 Agent”。

最后，我想用一句话总结这段实践心得：Agent 的价值，不取决于它集成了多少 Skill，而取决于它替人走完了多少步“从信息到行动”的闭环。 而腾讯云 AI Skills，正是那条让闭环变得触手可及的“标准轨道”。

全流程场景图