1. 项目概述让会议记录“活”起来你有没有经历过这样的场景一场长达两小时的头脑风暴会议结束你看着录音笔和笔记本上密密麻麻的、不成体系的记录感觉头都大了。把录音转成文字动辄就是上万字的文稿里面夹杂着“嗯”、“啊”、重复的句子和跑题的讨论整理起来简直是一场噩梦。更别提后续还要提炼要点、生成待办事项、同步给相关同事了。这个繁琐、耗时且容易出错的过程正是传统会议记录的最大痛点。“当会议记录学会‘开口说话’”这个项目标题精准地戳中了这个痛点。它描绘的不是一个简单的语音转文字工具而是一个能理解、能思考、能行动的智能办公助手。其核心是通过一条完整的“语音链路”将原始的会议音频转化为结构化的知识、可执行的任务甚至是一份带有语音播报的智能摘要。这背后串联的是自动语音识别、自然语言理解、文本到语音合成等一系列AI技术最终落地为一个能够自主完成特定办公流程的“智能体”。简单来说这个项目要做的是构建一个“智能办公 Agent”。它能够监听会议自动生成精炼的纪要提取关键决策和待办事项并可能通过语音向你“汇报”结果。这不仅仅是效率工具更是工作流的智能化重构。无论是产品评审会、技术方案讨论还是每周例会这个Agent都能成为你的“第二大脑”帮你从信息处理的苦力中解放出来专注于更有价值的思考和决策。2. 核心思路与架构设计拆解“语音链路”智能体要实现让会议记录“开口说话”我们不能把它看作一个单一功能而是一个由多个智能模块串联而成的自动化流水线。这条“语音链路”的每一个环节都对应着特定的技术挑战和设计决策。2.1 从声音到行动的完整链路解析一条理想的智能会议处理链路大致可以分为四个核心阶段我将其称为“感知-理解-决策-反馈”闭环感知耳朵这是链路的起点。我们需要一个高精度的“耳朵”即自动语音识别模块将会议中的多人语音流实时或离线地转换为文本。这里的关键在于处理多人对话、背景噪音、专业术语和口语化表达如“这个那个”、“然后呢”。理解大脑获得文本后需要“大脑”进行深度理解。这远不止于分词和句法分析。核心任务包括角色分离判断“谁在什么时候说了什么”。这通常需要结合声纹识别或基于文本内容的说话人转换点检测。语义提炼与摘要从冗长的对话中提取核心议题、达成的共识、存在的分歧以及最终结论。这需要文本摘要和关键信息抽取技术。意图识别与结构化识别对话中的“动作指令”例如“小张你下周一把方案发出来”这需要被识别为一条待办事项责任人小张内容发方案截止时间下周一。同样会议决定的“项目A延期至月底”需要被提取为关键决策。决策小秘书基于理解的结果智能体需要做出“决策”或“行动”。这就是Agent的核心能力。例如自动将提取出的待办事项创建到团队的项目管理工具如飞书任务、Teambition、Jira中并分配给对应责任人。将会议摘要和决策点整理成标准格式的纪要文档保存到云端知识库如Notion、语雀或发送至群聊。根据会议内容自动检索相关的历史文档或数据作为附件补充到纪要中。反馈嘴巴最后让记录“开口说话”。通过文本到语音合成技术将生成的会议摘要、今日待办清单等用清晰、自然的语音朗读出来。用户可以在通勤路上“听”会议重点或者让智能助手在每天早晨语音播报今日关联任务。这一步极大地提升了信息的接收效率和体验。2.2 技术栈选型与核心考量面对琳琅满目的开源模型和云服务如何为每个环节选择合适的技术组件我的选型逻辑始终围绕四个核心精度、成本、延迟和可控性。ASR语音识别选型云端方案像科大讯飞、阿里云、腾讯云提供的商用ASR API在通用场景下识别准确率高无需考虑部署和运维适合快速验证和轻量级应用。但需考虑持续调用成本、数据隐私性以及网络依赖性。本地/离线方案这是追求数据安全和可控性的必然选择。开源模型如OpenAI Whisper特别是large-v3版本在多语言和长音频转录上表现惊艳。对于中文场景FunASR、Paraformer等模型是更垂直的选择。最新的热点如Nemotron-3.5-ASR-Streaming-0.6B代表了流式、低参数量、高性能的端侧ASR方向非常适合需要实时反馈的会议场景。选型时必须测试模型在带有会议室混响、多人交叉发言的录音上的表现。NLP理解与Agent框架这是项目的“智慧”所在。简单的关键词匹配已经不够用了。我们需要借助大语言模型的能力。可以直接调用ChatGPT、DeepSeek等云端LLM的API通过精心设计的提示词让其完成摘要、提取事项等工作。提示词的质量直接决定效果。如果要构建更复杂、能执行多步骤操作如先查日历再创建任务的Agent就需要一个框架来管理其推理和行动循环。LangChain、LlamaIndex是经典选择它们提供了连接工具、管理记忆的模块。而Hermes Agent、CrewAI等新兴框架则更侧重于多智能体协作你可以设计一个“纪要员”Agent和一个“任务管理员”Agent来分工合作。选择框架时要权衡其学习曲线、社区活跃度和与现有工具的集成能力。TTS语音合成选型让语音反馈自然动听是关键。云端TTS如微软Azure的神经语音、阿里云的智能语音交互效果非常出色且稳定。对于离线或隐私要求高的场景端侧TTS是必由之路。ONNX Runtime作为一个高性能推理引擎可以高效部署诸如VITS、FastSpeech2等开源TTS模型。像VoxSherpa TTS这类项目提供了开箱即用的高质量语音合成方案。在安卓端集成时可能会遇到类似“安卓11使用科大讯飞TTS为啥需要进入设置点击一下才能使用”这样的系统权限或引擎初始化问题这需要在开发时特别注意。整体架构模式中心化流水线所有模块ASR, NLP, TTS顺序调用逻辑简单但单点故障影响全局。事件驱动架构会议音频上传作为一个事件触发后续一系列处理函数。ASR完成后发布“文本就绪”事件NLP模块订阅该事件进行处理以此类推。这种架构松耦合易于扩展和维护更适合生产环境。可以使用消息队列如Redis Pub/Sub, RabbitMQ或云函数来实现。实操心得从Demo到产品的关键一跃很多团队在POC阶段用云端API快速搭出效果但一旦考虑产品化就必须直面成本、数据安全和响应速度的问题。我的经验是早期用云端API验证核心逻辑和用户体验同时并行评估和测试本地化替代方案。例如用Whisper离线版替代部分ASR调用用ONNX部署的TTS模型替代云端合成。这样能在控制成本的前提下逐步构建自主可控的技术栈。3. 核心模块实现细节与踩坑实录有了架构蓝图接下来就是动手搭建。每个模块的实现都有不少细节和“坑”这里我分享一些关键环节的实操经验。3.1 高精度会议语音转写实战会议场景的ASR难点在于“鸡尾酒会效应”——如何从混杂的声音中分离出清晰的语音。单纯依赖一个通用模型往往不够。我的实战方案是“预处理领域模型后处理”三板斧音频预处理降噪与增强使用诸如noisereduce或speex这样的库进行噪声抑制。对于有多个麦克风源的会议室录音可以尝试使用盲源分离算法如IVA来提升语音清晰度。语音活动检测在送入ASR前先用VAD切分出只有人声的片段能显著减少模型处理无关噪音的负担提升整体效率和准确率。# 示例使用 webrtcvad 进行简单的VAD检测 import webrtcvad vad webrtcvad.Vad(2) # 设置灵敏度级别0-3 # 将音频按帧例如30ms一帧送入vad.is_speech()判断ASR模型选择与部署对于中文会议我测试后倾向于使用FunASR的“Paraformer-流式-长音频”模型。它在针对中文场景优化、支持实时流式识别和离线文件识别之间取得了很好的平衡。部署时使用其提供的服务化部署方案可以启动一个本地HTTP服务方便其他模块调用。关键是要配置好模型热词公司名、产品名、专业术语这是提升专有名词识别率的利器。文本后处理ASR输出的原始文本通常没有标点、分段且存在同音错误。这里需要接入一个标点恢复与文本纠错模型。例如可以用一个基于BERT的序列标注模型来恢复逗号、句号、问号并根据上下文纠正“视力”和“示例”这类错误。说话人分离如果音频是单声道混合了所有人声音这是一个挑战。可以尝试使用 pyannote-audio 这样的工具进行说话人日志分析。更实用的方案是如果会议系统能提供多轨录音每人一个音频流那问题就简单多了。踩坑记录流式与离线识别的权衡项目初期为了追求实时体验我们全力攻坚流式ASR。但在实际会议室环境中网络波动、多人抢话导致的语音重叠使得流式识别的中间结果频繁跳动、修正反而干扰了与会者的观感如果实时投屏字幕。后来我们调整为“准实时”模式会议结束后立即用离线模型对完整音频进行高精度转写这个过程通常在会议结束几分钟内完成。对于“实时性”需求我们改为提供“实时关键词高亮”功能即流式ASR只用于检测如“同意”、“反对”、“截止”等关键意图词并实时提示而非全文转录。体验反而更好。3.2 基于LLM的智能理解与信息抽取拿到完整的会议文本后就轮到LLM大显身手了。直接扔给LLM一句“请总结会议纪要”是远远不够的。我设计了一套结构化的提示词工程流程角色设定与任务分解首先给LLM赋予一个明确的角色比如“你是一位资深秘书擅长从混乱的对话中提炼核心”。然后将复杂的纪要生成任务分解为多个步骤第一步对话清洗。删除语气词、无意义的重复句子。第二步话题分段。根据内容转折将长对话划分为几个核心议题。第三步信息抽取。针对每个议题分别提取“背景讨论”、“各方观点”、“达成共识”、“存在分歧”、“最终决策”、“待办事项含责任人、截止时间、内容”。第四步格式整合。将上述信息按照固定的Markdown模板进行组织。提供示例在提示词中提供1-2个高质量的纪要范例让LLM学会你想要的格式和风格。这比单纯描述有效得多。要求结构化输出强制要求LLM以JSON格式输出。这样后端程序可以直接解析而无需处理不稳定的自然语言。例如{ meeting_topic: Q3产品上线计划评审, summary: 会议确定了..., decisions: [ {item: 上线时间推迟一周, reason: 测试环节发现重大性能瓶颈} ], action_items: [ {owner: 张三, task: 完成性能优化方案, deadline: 2023-10-27} ] }迭代与评估需要人工审核初期LLM生成的结果找出系统性错误如总是漏掉某个责任人的任务然后反过来优化提示词。这是一个持续的过程。注意事项成本与延迟的控制使用GPT-4这类顶级模型效果最好但成本也高。对于内部会议纪要可以尝试使用性能优秀的开源模型如 DeepSeek、Qwen-Max 或特定微调过的模型。另一个技巧是“摘要的摘要”先让一个较小的、快速的模型对每个议题进行初步摘要然后再将这些摘要交给更大的模型进行全局整合和润色这样能平衡速度和效果。3.3 任务自动化与多工具联动信息抽取出来后如何让Agent自动“干活”这就需要用到Agent框架的工具调用能力。以自动创建飞书任务为例一个健壮的实现需要处理以下环节工具封装将“创建飞书任务”这个操作封装成一个标准的工具函数。这个函数需要处理飞书开放平台的认证、API调用格式和错误处理。def create_feishu_task(task_title, description, owner_user_id, deadline): # 1. 获取 tenant_access_token # 2. 构造API请求体 # 3. 发送POST请求到飞书任务API # 4. 处理响应返回任务ID或错误信息Agent决策逻辑在LangChain或Hermes Agent中你需要定义工具的description让LLM知道什么时候该调用它。例如工具描述可以是“当会议中产生一项有待办人、明确内容和截止时间的任务时调用此工具在飞书任务中创建一条新待办。”信息匹配与补全LLM提取的“责任人”可能是“老王”但飞书API需要的是用户的user_id。这里需要一个用户映射表或一个通过姓名查询用户ID的辅助工具。对于模糊的时间表述如“下周五”需要有一个时间解析模块将其转换为具体的日期“2023-11-03”。确认与回退机制全自动创建任务存在风险比如LLM理解错了。更好的模式是“人机协同”Agent生成任务草稿通过飞书机器人发送给相关责任人确认责任人回复“确认”后任务才被正式创建。这增加了可靠性。同理可以封装“写入Confluence文档”、“发送邮件”、“创建日历事件”等一系列工具让Agent成为一个真正的办公自动化枢纽。3.4 自然语音反馈的TTS集成最后一步让Agent“开口说话”。我们追求的是清晰、自然、低延迟的语音反馈。端侧TTS集成方案模型选择与转换选择一款开源TTS模型如VITS。首先需要找到合适的、音质较好的中文预训练模型。然后为了提升推理速度通常需要将模型PyTorch格式转换为ONNX格式。ONNX Runtime 支持CPU/GPU推理并且有针对移动端的优化。# 示例使用官方工具或自定义脚本将PyTorch模型导出为ONNX # python export_to_onnx.py --model_path your_vits_model.pth --onnx_path model.onnx服务化部署将ONNX模型加载到ONNX Runtime中封装成一个简单的HTTP服务使用FastAPI或Flask。提供API接口接收文本返回生成的音频流如WAV格式。客户端播放前端或移动端应用调用这个TTS服务获取音频流并进行播放。对于移动端可以直接集成ONNX Runtime库将模型打包进App实现完全离线的语音合成避免网络延迟。避坑指南安卓端TTS的权限问题文中提到的“安卓11使用科大讯飞TTS为啥需要进入设置点击一下才能使用”这个问题非常典型。这通常是因为Android系统对后台服务启动的限制电源优化、后台限制。对于离线TTS引擎解决方案不是让用户去设置而是在代码中做到在App启动或需要初始化TTS时尝试创建前台服务来启动TTS引擎或者引导用户授予“忽略电池优化”的权限。更根本的方案是使用像onnxruntime-android直接推理VITS模型完全绕过系统TTS引擎实现应用内自有的、可控的语音合成从而杜绝此类系统级兼容性问题。4. 系统集成、部署与性能优化当各个模块开发完毕如何将它们可靠地集成并交付给用户是另一个维度的挑战。4.1 构建事件驱动的微服务流水线我推荐使用事件驱动架构来串联整个流程。以下是一个基于消息队列的简化设计事件生产者用户上传会议录音文件后一个“文件上传服务”将其存储到对象存储如MinIO、阿里云OSS并向消息队列如Redis Streams、RabbitMQ发布一个事件{event_type: audio_uploaded, file_path: meetings/20231101.wav, meeting_id: 123}。事件消费者 - ASR服务ASR服务订阅上述事件。收到事件后从对象存储下载音频进行转写。完成后发布新事件{event_type: transcription_completed, meeting_id: 123, text: ...}。事件消费者 - NLP Agent服务NLP服务订阅转录完成事件。调用LLM进行处理提取结构化的纪要和任务。完成后发布事件{event_type: summary_generated, meeting_id: 123, actions: [...]}。事件消费者 - 任务执行服务订阅摘要生成事件解析其中的actions调用对应的工具飞书、Confluence等去创建任务或文档。事件消费者 - TTS服务可选如果需要语音摘要可以再订阅摘要生成事件将文本摘要合成语音存储并通知用户。这种架构的好处是解耦。任何一个服务失败或需要升级都不会直接影响其他服务消息会在队列中等待重试。也方便横向扩展例如可以启动多个ASR服务实例来并发处理大量录音。4.2 性能、成本与监控考量性能ASR/TTS模型推理加速使用ONNX Runtime时开启会话选项优化如enable_cpu_mem_arena对于TTS可以考虑模型量化INT8来进一步减少模型大小和提升推理速度。LLM调用优化对于摘要生成可以采用异步调用避免阻塞主线程。缓存频繁使用的提示词模板和示例。考虑对LLM的响应进行流式接收让用户感知上更快。成本云服务成本如果使用云端ASR/TTS/LLM API成本是主要考量。需要设置用量监控和告警。对于内部使用可以设置月度预算和单次调用成本阈值。自建服务成本自建服务的主要成本是GPU服务器用于运行LLM或大型ASR模型。可以考虑使用CPU推理较小的模型或使用按需启动的GPU实例。监控与可观测性在每个关键服务节点埋点记录处理耗时、成功/失败状态。监控消息队列的堆积情况及时发现处理瓶颈。对于LLM调用需要记录其输入提示词和输出以便在出现问题时进行追溯和优化。5. 典型问题排查与效果评估指南在实际运行中你一定会遇到各种问题。这里整理了一份快速排查清单和效果评估方法。5.1 常见问题速查表问题现象可能原因排查步骤与解决方案ASR转写结果乱码或大量错误1. 音频编码格式或采样率不符。2. 背景噪音过大或多人同时说话。3. 模型未针对领域术语优化。1. 统一将音频预处理为模型要求的格式如16kHz, 单声道, PCM。2. 加强音频预处理降噪、VAD或尝试使用支持说话人分离的ASR模型。3. 为ASR引擎添加热词列表包含公司、产品、人名等专有名词。LLM生成的纪要遗漏重要决策1. 提示词不够明确未强调“决策”和“待办”。2. 会议文本过长超出LLM上下文窗口。3. LLM能力不足。1. 在提示词中明确要求“列出所有决策点”和“提取所有待办事项”并给出清晰示例。2. 采用“分而治之”策略先将长文本按话题切分再分别总结最后合并。3. 升级到能力更强的LLM或对领域数据进行微调。自动创建的任务责任人错误1. LLM将昵称识别为责任人。2. 用户映射表不完整或未更新。3. 任务描述模糊LLM无法确定责任人。1. 在提示词中要求输出全名并在后端维护一个“昵称-全名-用户ID”的映射字典。2. 实现一个“用户查询”工具当Agent不确定时可以主动查询或列出候选人让用户选择。3. 对于无法明确责任人的任务降级处理为“待确认”状态通过机器人通知会议发起人手动分配。TTS语音不自然或存在杂音1. TTS模型本身音质问题或训练数据不足。2. 推理参数如速度、音高设置不当。3. 文本中有异常符号或未处理的缩写。1. 尝试更换或微调TTS模型。对于中文关注基频建模和韵律预测好的模型。2. 调整推理时的参数如speed、pitch并进行A/B测试找到最佳听感。3. 在TTS前增加文本规范化步骤将“2023.11.01”转为“二零二三年十一月一日”将“AI”转为“人工智能”等。整体流程耗时过长1. 某个模块如ASR或LLM处理慢。2. 网络延迟高调用云端API时。3. 服务间同步调用导致阻塞。1. 为ASR/LLM服务进行性能剖析优化模型或升级硬件。2. 考虑将云端API替换为本地部署模型或使用离用户更近的云区域。3. 将整个流程改为完全异步。用户上传音频后立即返回通过WebSocket或轮询通知用户处理进度和最终结果。5.2 如何评估你的智能办公Agent除了排查问题我们还需要一套标准来衡量这个Agent是否真的“智能”和“有用”。转写准确率这是基础。随机抽取若干段会议录音对比人工转写和ASR转写的结果计算字错误率。目标是将WER控制在5%以下针对清晰录音。信息抽取完整性与准确性这是核心。评估LLM生成的纪要完整性人工标注的会议关键决策和待办事项有多少被Agent成功提取出来了召回率准确性Agent提取出的信息有多少是正确无误的精确率格式规范性生成的纪要是否符合预设的模板要求任务自动化成功率对于Agent自动创建的任务有多少是无需人工修正即可直接执行的有多少出现了责任人错误、时间错误或内容偏差用户体验与效率提升这是最终目的。可以通过用户访谈和问卷了解使用Agent后整理一份会议纪要的平均时间减少了多少用户对语音摘要功能的接受度和满意度如何自动创建的任务是否真正融入了他们的工作流我个人在实际操作中的体会是技术指标的优化永无止境但产品的成功关键在于是否切中了用户“懒”的痛点和“忙”的刚需。最初我们追求极致的ASR准确率后来发现用户对95%和97%的准确率感知并不明显但他们对于“能否自动把‘下周五前给方案’这句话变成我日历里的一条待办”却异常敏感。因此后期我们把更多精力放在了LLM的意图理解准确率和工具执行的可靠性上这才是让用户觉得“这东西真聪明”的关键。另一个小技巧是在项目初期提供一个“人工审核”的开关让用户可以看到Agent生成的草稿并进行编辑确认这极大地降低了用户的试用门槛和信任成本收集到的修正数据反过来又成为我们优化Agent的最佳训练材料。 构建智能会议Agent：从语音识别到任务自动化的完整实践
1. 项目概述让会议记录“活”起来你有没有经历过这样的场景一场长达两小时的头脑风暴会议结束你看着录音笔和笔记本上密密麻麻的、不成体系的记录感觉头都大了。把录音转成文字动辄就是上万字的文稿里面夹杂着“嗯”、“啊”、重复的句子和跑题的讨论整理起来简直是一场噩梦。更别提后续还要提炼要点、生成待办事项、同步给相关同事了。这个繁琐、耗时且容易出错的过程正是传统会议记录的最大痛点。“当会议记录学会‘开口说话’”这个项目标题精准地戳中了这个痛点。它描绘的不是一个简单的语音转文字工具而是一个能理解、能思考、能行动的智能办公助手。其核心是通过一条完整的“语音链路”将原始的会议音频转化为结构化的知识、可执行的任务甚至是一份带有语音播报的智能摘要。这背后串联的是自动语音识别、自然语言理解、文本到语音合成等一系列AI技术最终落地为一个能够自主完成特定办公流程的“智能体”。简单来说这个项目要做的是构建一个“智能办公 Agent”。它能够监听会议自动生成精炼的纪要提取关键决策和待办事项并可能通过语音向你“汇报”结果。这不仅仅是效率工具更是工作流的智能化重构。无论是产品评审会、技术方案讨论还是每周例会这个Agent都能成为你的“第二大脑”帮你从信息处理的苦力中解放出来专注于更有价值的思考和决策。2. 核心思路与架构设计拆解“语音链路”智能体要实现让会议记录“开口说话”我们不能把它看作一个单一功能而是一个由多个智能模块串联而成的自动化流水线。这条“语音链路”的每一个环节都对应着特定的技术挑战和设计决策。2.1 从声音到行动的完整链路解析一条理想的智能会议处理链路大致可以分为四个核心阶段我将其称为“感知-理解-决策-反馈”闭环感知耳朵这是链路的起点。我们需要一个高精度的“耳朵”即自动语音识别模块将会议中的多人语音流实时或离线地转换为文本。这里的关键在于处理多人对话、背景噪音、专业术语和口语化表达如“这个那个”、“然后呢”。理解大脑获得文本后需要“大脑”进行深度理解。这远不止于分词和句法分析。核心任务包括角色分离判断“谁在什么时候说了什么”。这通常需要结合声纹识别或基于文本内容的说话人转换点检测。语义提炼与摘要从冗长的对话中提取核心议题、达成的共识、存在的分歧以及最终结论。这需要文本摘要和关键信息抽取技术。意图识别与结构化识别对话中的“动作指令”例如“小张你下周一把方案发出来”这需要被识别为一条待办事项责任人小张内容发方案截止时间下周一。同样会议决定的“项目A延期至月底”需要被提取为关键决策。决策小秘书基于理解的结果智能体需要做出“决策”或“行动”。这就是Agent的核心能力。例如自动将提取出的待办事项创建到团队的项目管理工具如飞书任务、Teambition、Jira中并分配给对应责任人。将会议摘要和决策点整理成标准格式的纪要文档保存到云端知识库如Notion、语雀或发送至群聊。根据会议内容自动检索相关的历史文档或数据作为附件补充到纪要中。反馈嘴巴最后让记录“开口说话”。通过文本到语音合成技术将生成的会议摘要、今日待办清单等用清晰、自然的语音朗读出来。用户可以在通勤路上“听”会议重点或者让智能助手在每天早晨语音播报今日关联任务。这一步极大地提升了信息的接收效率和体验。2.2 技术栈选型与核心考量面对琳琅满目的开源模型和云服务如何为每个环节选择合适的技术组件我的选型逻辑始终围绕四个核心精度、成本、延迟和可控性。ASR语音识别选型云端方案像科大讯飞、阿里云、腾讯云提供的商用ASR API在通用场景下识别准确率高无需考虑部署和运维适合快速验证和轻量级应用。但需考虑持续调用成本、数据隐私性以及网络依赖性。本地/离线方案这是追求数据安全和可控性的必然选择。开源模型如OpenAI Whisper特别是large-v3版本在多语言和长音频转录上表现惊艳。对于中文场景FunASR、Paraformer等模型是更垂直的选择。最新的热点如Nemotron-3.5-ASR-Streaming-0.6B代表了流式、低参数量、高性能的端侧ASR方向非常适合需要实时反馈的会议场景。选型时必须测试模型在带有会议室混响、多人交叉发言的录音上的表现。NLP理解与Agent框架这是项目的“智慧”所在。简单的关键词匹配已经不够用了。我们需要借助大语言模型的能力。可以直接调用ChatGPT、DeepSeek等云端LLM的API通过精心设计的提示词让其完成摘要、提取事项等工作。提示词的质量直接决定效果。如果要构建更复杂、能执行多步骤操作如先查日历再创建任务的Agent就需要一个框架来管理其推理和行动循环。LangChain、LlamaIndex是经典选择它们提供了连接工具、管理记忆的模块。而Hermes Agent、CrewAI等新兴框架则更侧重于多智能体协作你可以设计一个“纪要员”Agent和一个“任务管理员”Agent来分工合作。选择框架时要权衡其学习曲线、社区活跃度和与现有工具的集成能力。TTS语音合成选型让语音反馈自然动听是关键。云端TTS如微软Azure的神经语音、阿里云的智能语音交互效果非常出色且稳定。对于离线或隐私要求高的场景端侧TTS是必由之路。ONNX Runtime作为一个高性能推理引擎可以高效部署诸如VITS、FastSpeech2等开源TTS模型。像VoxSherpa TTS这类项目提供了开箱即用的高质量语音合成方案。在安卓端集成时可能会遇到类似“安卓11使用科大讯飞TTS为啥需要进入设置点击一下才能使用”这样的系统权限或引擎初始化问题这需要在开发时特别注意。整体架构模式中心化流水线所有模块ASR, NLP, TTS顺序调用逻辑简单但单点故障影响全局。事件驱动架构会议音频上传作为一个事件触发后续一系列处理函数。ASR完成后发布“文本就绪”事件NLP模块订阅该事件进行处理以此类推。这种架构松耦合易于扩展和维护更适合生产环境。可以使用消息队列如Redis Pub/Sub, RabbitMQ或云函数来实现。实操心得从Demo到产品的关键一跃很多团队在POC阶段用云端API快速搭出效果但一旦考虑产品化就必须直面成本、数据安全和响应速度的问题。我的经验是早期用云端API验证核心逻辑和用户体验同时并行评估和测试本地化替代方案。例如用Whisper离线版替代部分ASR调用用ONNX部署的TTS模型替代云端合成。这样能在控制成本的前提下逐步构建自主可控的技术栈。3. 核心模块实现细节与踩坑实录有了架构蓝图接下来就是动手搭建。每个模块的实现都有不少细节和“坑”这里我分享一些关键环节的实操经验。3.1 高精度会议语音转写实战会议场景的ASR难点在于“鸡尾酒会效应”——如何从混杂的声音中分离出清晰的语音。单纯依赖一个通用模型往往不够。我的实战方案是“预处理领域模型后处理”三板斧音频预处理降噪与增强使用诸如noisereduce或speex这样的库进行噪声抑制。对于有多个麦克风源的会议室录音可以尝试使用盲源分离算法如IVA来提升语音清晰度。语音活动检测在送入ASR前先用VAD切分出只有人声的片段能显著减少模型处理无关噪音的负担提升整体效率和准确率。# 示例使用 webrtcvad 进行简单的VAD检测 import webrtcvad vad webrtcvad.Vad(2) # 设置灵敏度级别0-3 # 将音频按帧例如30ms一帧送入vad.is_speech()判断ASR模型选择与部署对于中文会议我测试后倾向于使用FunASR的“Paraformer-流式-长音频”模型。它在针对中文场景优化、支持实时流式识别和离线文件识别之间取得了很好的平衡。部署时使用其提供的服务化部署方案可以启动一个本地HTTP服务方便其他模块调用。关键是要配置好模型热词公司名、产品名、专业术语这是提升专有名词识别率的利器。文本后处理ASR输出的原始文本通常没有标点、分段且存在同音错误。这里需要接入一个标点恢复与文本纠错模型。例如可以用一个基于BERT的序列标注模型来恢复逗号、句号、问号并根据上下文纠正“视力”和“示例”这类错误。说话人分离如果音频是单声道混合了所有人声音这是一个挑战。可以尝试使用 pyannote-audio 这样的工具进行说话人日志分析。更实用的方案是如果会议系统能提供多轨录音每人一个音频流那问题就简单多了。踩坑记录流式与离线识别的权衡项目初期为了追求实时体验我们全力攻坚流式ASR。但在实际会议室环境中网络波动、多人抢话导致的语音重叠使得流式识别的中间结果频繁跳动、修正反而干扰了与会者的观感如果实时投屏字幕。后来我们调整为“准实时”模式会议结束后立即用离线模型对完整音频进行高精度转写这个过程通常在会议结束几分钟内完成。对于“实时性”需求我们改为提供“实时关键词高亮”功能即流式ASR只用于检测如“同意”、“反对”、“截止”等关键意图词并实时提示而非全文转录。体验反而更好。3.2 基于LLM的智能理解与信息抽取拿到完整的会议文本后就轮到LLM大显身手了。直接扔给LLM一句“请总结会议纪要”是远远不够的。我设计了一套结构化的提示词工程流程角色设定与任务分解首先给LLM赋予一个明确的角色比如“你是一位资深秘书擅长从混乱的对话中提炼核心”。然后将复杂的纪要生成任务分解为多个步骤第一步对话清洗。删除语气词、无意义的重复句子。第二步话题分段。根据内容转折将长对话划分为几个核心议题。第三步信息抽取。针对每个议题分别提取“背景讨论”、“各方观点”、“达成共识”、“存在分歧”、“最终决策”、“待办事项含责任人、截止时间、内容”。第四步格式整合。将上述信息按照固定的Markdown模板进行组织。提供示例在提示词中提供1-2个高质量的纪要范例让LLM学会你想要的格式和风格。这比单纯描述有效得多。要求结构化输出强制要求LLM以JSON格式输出。这样后端程序可以直接解析而无需处理不稳定的自然语言。例如{ meeting_topic: Q3产品上线计划评审, summary: 会议确定了..., decisions: [ {item: 上线时间推迟一周, reason: 测试环节发现重大性能瓶颈} ], action_items: [ {owner: 张三, task: 完成性能优化方案, deadline: 2023-10-27} ] }迭代与评估需要人工审核初期LLM生成的结果找出系统性错误如总是漏掉某个责任人的任务然后反过来优化提示词。这是一个持续的过程。注意事项成本与延迟的控制使用GPT-4这类顶级模型效果最好但成本也高。对于内部会议纪要可以尝试使用性能优秀的开源模型如 DeepSeek、Qwen-Max 或特定微调过的模型。另一个技巧是“摘要的摘要”先让一个较小的、快速的模型对每个议题进行初步摘要然后再将这些摘要交给更大的模型进行全局整合和润色这样能平衡速度和效果。3.3 任务自动化与多工具联动信息抽取出来后如何让Agent自动“干活”这就需要用到Agent框架的工具调用能力。以自动创建飞书任务为例一个健壮的实现需要处理以下环节工具封装将“创建飞书任务”这个操作封装成一个标准的工具函数。这个函数需要处理飞书开放平台的认证、API调用格式和错误处理。def create_feishu_task(task_title, description, owner_user_id, deadline): # 1. 获取 tenant_access_token # 2. 构造API请求体 # 3. 发送POST请求到飞书任务API # 4. 处理响应返回任务ID或错误信息Agent决策逻辑在LangChain或Hermes Agent中你需要定义工具的description让LLM知道什么时候该调用它。例如工具描述可以是“当会议中产生一项有待办人、明确内容和截止时间的任务时调用此工具在飞书任务中创建一条新待办。”信息匹配与补全LLM提取的“责任人”可能是“老王”但飞书API需要的是用户的user_id。这里需要一个用户映射表或一个通过姓名查询用户ID的辅助工具。对于模糊的时间表述如“下周五”需要有一个时间解析模块将其转换为具体的日期“2023-11-03”。确认与回退机制全自动创建任务存在风险比如LLM理解错了。更好的模式是“人机协同”Agent生成任务草稿通过飞书机器人发送给相关责任人确认责任人回复“确认”后任务才被正式创建。这增加了可靠性。同理可以封装“写入Confluence文档”、“发送邮件”、“创建日历事件”等一系列工具让Agent成为一个真正的办公自动化枢纽。3.4 自然语音反馈的TTS集成最后一步让Agent“开口说话”。我们追求的是清晰、自然、低延迟的语音反馈。端侧TTS集成方案模型选择与转换选择一款开源TTS模型如VITS。首先需要找到合适的、音质较好的中文预训练模型。然后为了提升推理速度通常需要将模型PyTorch格式转换为ONNX格式。ONNX Runtime 支持CPU/GPU推理并且有针对移动端的优化。# 示例使用官方工具或自定义脚本将PyTorch模型导出为ONNX # python export_to_onnx.py --model_path your_vits_model.pth --onnx_path model.onnx服务化部署将ONNX模型加载到ONNX Runtime中封装成一个简单的HTTP服务使用FastAPI或Flask。提供API接口接收文本返回生成的音频流如WAV格式。客户端播放前端或移动端应用调用这个TTS服务获取音频流并进行播放。对于移动端可以直接集成ONNX Runtime库将模型打包进App实现完全离线的语音合成避免网络延迟。避坑指南安卓端TTS的权限问题文中提到的“安卓11使用科大讯飞TTS为啥需要进入设置点击一下才能使用”这个问题非常典型。这通常是因为Android系统对后台服务启动的限制电源优化、后台限制。对于离线TTS引擎解决方案不是让用户去设置而是在代码中做到在App启动或需要初始化TTS时尝试创建前台服务来启动TTS引擎或者引导用户授予“忽略电池优化”的权限。更根本的方案是使用像onnxruntime-android直接推理VITS模型完全绕过系统TTS引擎实现应用内自有的、可控的语音合成从而杜绝此类系统级兼容性问题。4. 系统集成、部署与性能优化当各个模块开发完毕如何将它们可靠地集成并交付给用户是另一个维度的挑战。4.1 构建事件驱动的微服务流水线我推荐使用事件驱动架构来串联整个流程。以下是一个基于消息队列的简化设计事件生产者用户上传会议录音文件后一个“文件上传服务”将其存储到对象存储如MinIO、阿里云OSS并向消息队列如Redis Streams、RabbitMQ发布一个事件{event_type: audio_uploaded, file_path: meetings/20231101.wav, meeting_id: 123}。事件消费者 - ASR服务ASR服务订阅上述事件。收到事件后从对象存储下载音频进行转写。完成后发布新事件{event_type: transcription_completed, meeting_id: 123, text: ...}。事件消费者 - NLP Agent服务NLP服务订阅转录完成事件。调用LLM进行处理提取结构化的纪要和任务。完成后发布事件{event_type: summary_generated, meeting_id: 123, actions: [...]}。事件消费者 - 任务执行服务订阅摘要生成事件解析其中的actions调用对应的工具飞书、Confluence等去创建任务或文档。事件消费者 - TTS服务可选如果需要语音摘要可以再订阅摘要生成事件将文本摘要合成语音存储并通知用户。这种架构的好处是解耦。任何一个服务失败或需要升级都不会直接影响其他服务消息会在队列中等待重试。也方便横向扩展例如可以启动多个ASR服务实例来并发处理大量录音。4.2 性能、成本与监控考量性能ASR/TTS模型推理加速使用ONNX Runtime时开启会话选项优化如enable_cpu_mem_arena对于TTS可以考虑模型量化INT8来进一步减少模型大小和提升推理速度。LLM调用优化对于摘要生成可以采用异步调用避免阻塞主线程。缓存频繁使用的提示词模板和示例。考虑对LLM的响应进行流式接收让用户感知上更快。成本云服务成本如果使用云端ASR/TTS/LLM API成本是主要考量。需要设置用量监控和告警。对于内部使用可以设置月度预算和单次调用成本阈值。自建服务成本自建服务的主要成本是GPU服务器用于运行LLM或大型ASR模型。可以考虑使用CPU推理较小的模型或使用按需启动的GPU实例。监控与可观测性在每个关键服务节点埋点记录处理耗时、成功/失败状态。监控消息队列的堆积情况及时发现处理瓶颈。对于LLM调用需要记录其输入提示词和输出以便在出现问题时进行追溯和优化。5. 典型问题排查与效果评估指南在实际运行中你一定会遇到各种问题。这里整理了一份快速排查清单和效果评估方法。5.1 常见问题速查表问题现象可能原因排查步骤与解决方案ASR转写结果乱码或大量错误1. 音频编码格式或采样率不符。2. 背景噪音过大或多人同时说话。3. 模型未针对领域术语优化。1. 统一将音频预处理为模型要求的格式如16kHz, 单声道, PCM。2. 加强音频预处理降噪、VAD或尝试使用支持说话人分离的ASR模型。3. 为ASR引擎添加热词列表包含公司、产品、人名等专有名词。LLM生成的纪要遗漏重要决策1. 提示词不够明确未强调“决策”和“待办”。2. 会议文本过长超出LLM上下文窗口。3. LLM能力不足。1. 在提示词中明确要求“列出所有决策点”和“提取所有待办事项”并给出清晰示例。2. 采用“分而治之”策略先将长文本按话题切分再分别总结最后合并。3. 升级到能力更强的LLM或对领域数据进行微调。自动创建的任务责任人错误1. LLM将昵称识别为责任人。2. 用户映射表不完整或未更新。3. 任务描述模糊LLM无法确定责任人。1. 在提示词中要求输出全名并在后端维护一个“昵称-全名-用户ID”的映射字典。2. 实现一个“用户查询”工具当Agent不确定时可以主动查询或列出候选人让用户选择。3. 对于无法明确责任人的任务降级处理为“待确认”状态通过机器人通知会议发起人手动分配。TTS语音不自然或存在杂音1. TTS模型本身音质问题或训练数据不足。2. 推理参数如速度、音高设置不当。3. 文本中有异常符号或未处理的缩写。1. 尝试更换或微调TTS模型。对于中文关注基频建模和韵律预测好的模型。2. 调整推理时的参数如speed、pitch并进行A/B测试找到最佳听感。3. 在TTS前增加文本规范化步骤将“2023.11.01”转为“二零二三年十一月一日”将“AI”转为“人工智能”等。整体流程耗时过长1. 某个模块如ASR或LLM处理慢。2. 网络延迟高调用云端API时。3. 服务间同步调用导致阻塞。1. 为ASR/LLM服务进行性能剖析优化模型或升级硬件。2. 考虑将云端API替换为本地部署模型或使用离用户更近的云区域。3. 将整个流程改为完全异步。用户上传音频后立即返回通过WebSocket或轮询通知用户处理进度和最终结果。5.2 如何评估你的智能办公Agent除了排查问题我们还需要一套标准来衡量这个Agent是否真的“智能”和“有用”。转写准确率这是基础。随机抽取若干段会议录音对比人工转写和ASR转写的结果计算字错误率。目标是将WER控制在5%以下针对清晰录音。信息抽取完整性与准确性这是核心。评估LLM生成的纪要完整性人工标注的会议关键决策和待办事项有多少被Agent成功提取出来了召回率准确性Agent提取出的信息有多少是正确无误的精确率格式规范性生成的纪要是否符合预设的模板要求任务自动化成功率对于Agent自动创建的任务有多少是无需人工修正即可直接执行的有多少出现了责任人错误、时间错误或内容偏差用户体验与效率提升这是最终目的。可以通过用户访谈和问卷了解使用Agent后整理一份会议纪要的平均时间减少了多少用户对语音摘要功能的接受度和满意度如何自动创建的任务是否真正融入了他们的工作流我个人在实际操作中的体会是技术指标的优化永无止境但产品的成功关键在于是否切中了用户“懒”的痛点和“忙”的刚需。最初我们追求极致的ASR准确率后来发现用户对95%和97%的准确率感知并不明显但他们对于“能否自动把‘下周五前给方案’这句话变成我日历里的一条待办”却异常敏感。因此后期我们把更多精力放在了LLM的意图理解准确率和工具执行的可靠性上这才是让用户觉得“这东西真聪明”的关键。另一个小技巧是在项目初期提供一个“人工审核”的开关让用户可以看到Agent生成的草稿并进行编辑确认这极大地降低了用户的试用门槛和信任成本收集到的修正数据反过来又成为我们优化Agent的最佳训练材料。