1. 从“哑巴”记录到“会说话”的助手一个真实的需求场景想象一下这个场景你刚开完一个长达两小时的跨部门产品评审会。会议结束时你看着笔记软件里那几百条零散的、只有自己能看懂的速记要点以及手机里那个长达120分钟的录音文件感到一阵头疼。你知道这里面藏着大量的关键信息、待办事项和决策点但要把它们整理成一份结构清晰、可执行、可追溯的会议纪要至少需要再花上一个小时——而这通常是你最没有的“一小时”。这就是传统会议记录的“哑巴”状态它被动地记录却无法主动地“开口”告诉你它说了什么、谁说了什么、接下来要做什么。而“智能办公 Agent”要做的就是让这条记录“活”过来。它不再是一个静态的文件而是一个能听、能说、能理解、能行动的智能体。核心的魔法就藏在一条完整的“语音链路”里从麦克风捕捉声音到语音识别ASR将其转为文字再到大语言模型LLM理解、提炼、结构化这些文字最后通过语音合成TTS将关键信息“说”给你听或者驱动其他应用执行任务。这不仅仅是把录音转成文字那么简单。市面上很多“语音转文字”工具做完这一步就结束了产出的是一份需要你从头到尾校对、整理的“文字墙”。真正的价值在于后续的“理解”与“行动”。一个设计良好的智能办公 Agent应该能自动识别出会议中的“行动项”Action Items并关联到责任人能提炼出核心决策与待办事项甚至能根据讨论内容自动生成邮件草稿、更新项目看板或者在日历中创建提醒。而“开口说话”的能力则让交互变得自然——你可以直接问它“刚才关于预算部分李总最后是怎么定的”它就能用语音回答你而不是让你去翻找那份长长的文本。我最近就在团队内部实践搭建了这样一套原型系统。整个过程并非一蹴而就其中涉及到开源模型选型、链路延迟优化、上下文理解精度以及最后的“智能体”行为设计等多个环节的权衡与踩坑。接下来我就把这套从声音到文字再到理解与行动的完整链路拆解清楚分享其中关键的技术选型逻辑、具体的实现步骤以及那些只有亲手做过才会知道的“坑”。2. 语音链路核心四步采集、转写、理解与合成一条能用的语音智能链路核心离不开四个环节语音采集、语音识别ASR、自然语言理解通常由LLM承担和语音合成TTS。每个环节的选择都直接决定了最终Agent的体验、成本和可用性。2.1 语音采集不仅仅是“录下来”很多人会忽略第一步认为用设备自带的麦克风录音就行。但在真实的会议环境中这往往是体验崩塌的起点。手机放在会议桌中央录下的声音混杂着远处的发言、键盘声、咳嗽声、还有可怕的回声和背景噪声。这样的音频喂给ASR模型识别准确率会大打折扣。注意语音链路的质量遵循“垃圾进垃圾出”原则。前端音频质量差后续环节再强大也无力回天。因此在实践中有几个提升采集质量的策略专用设备与阵列麦克风如果会议场景固定如会议室投资一个USB会议麦克风是性价比最高的选择。这类麦克风通常具备波束成形技术能定向拾取特定方向的声音有效抑制环境噪声。我测试过几款千元级的产品其对远场语音的拾取效果远超任何高端手机或笔记本电脑。软件端预处理如果只能用普通设备可以在音频流送入ASR前进行简单的软件预处理。例如使用pydub这样的库进行噪声抑制noise reduction和增益标准化normalization。一个简单的实践是在会议开始前先录制几秒纯环境噪声用于后续的噪声样本扣除。多端同步与云端混流对于线上会议如腾讯会议、Zoom更优的方案是直接获取会议云端的混流音频。这通常需要通过官方API如果有的话或虚拟声卡捕获系统音频输出。这样获得的音频是经过服务端降噪、增益均衡后的高质量单声道流是ASR的理想输入。在我的实践中我选择了第三种方案作为重点因为线上会议已是主流。我使用了一个开源的虚拟音频路由工具如VB-Audio Virtual Cable在Windows上或BlackHole在macOS上将会议软件的音频输出虚拟到一个“麦克风”输入设备再让我自己编写的Agent程序从这个虚拟设备捕获音频流。这样我就拿到了最纯净的语音源。2.2 语音识别ASR在“快、准、省”之间做权衡ASR是整个链路的基石它的选择决定了后续LLM能拿到多“干净”的原材料。当前选择无非三条路商用API、开源大模型、轻量级端侧模型。商用API如阿里云、腾讯云、讯飞优点是开箱即用准确率高尤其在中文场景通常自带标点预测、说话人分离等高级功能。缺点是持续产生费用且有数据隐私考量。对于需要快速验证原型或对准确率要求极高的生产环境这是首选。开源大模型如 OpenAI Whisper, FunASR优点是免费、可私有化部署、数据可控。Whisper的通用性极强中英文混合场景表现不错。FunASR则针对中文做了深度优化并提供了流式版本适合实时转写。缺点是对计算资源有一定要求尤其是大参数版本实时流式处理的延迟需要精心优化。轻量级端侧模型如 Nemotron-3.5-ASR-Streaming-0.6B这是NVIDIA最近推出的一个亮点模型参数量仅6亿专为流式ASR设计可以在边缘设备甚至高端手机上实时运行。优点是延迟极低、完全离线、隐私无忧。缺点是识别精度特别是对于专业术语和复杂背景噪声可能仍逊于大型商用API或Whisper-large。我的选型逻辑是这样的追求极致效果和快速上线用商用API追求数据隐私和定制化用开源大模型追求低延迟和离线部署用轻量级端侧模型。在本次实践中我选择了FunASR的流式部署方案。原因有三第一完全私有化满足内部数据安全要求第二针对中文优化在团队的技术讨论中术语识别准确率比Whisper有明显感知上的提升第三其流式服务框架FunASR-server设计得比较完善易于集成。我将其部署在一台带GPU的云服务器上通过WebSocket协议向它发送音频流并实时接收识别出的文字片段。这里的一个关键参数是vad_model语音活动检测和punc_model标点预测的启用它们能显著提升转写结果的可读性。2.3 自然语言理解与提炼LLM是大脑拿到连续的转写文本流后真正的智能开始了。这里LLM扮演了“会议秘书”的角色。但直接抛给LLM一整场会议的文本然后说“总结一下”效果往往不好成本也高。我们需要更精巧的设计。1. 流式处理与增量总结我们不需要等会议结束才启动理解。可以设计一个“滑动窗口”机制。例如每识别出大约500字或静默超过30秒就将这段时间的文本连同之前几分钟的上下文摘要一起发送给LLM要求其进行“增量摘要”。这样LLM始终在维护一个滚动的、浓缩的会议记忆。最终会议结束时再让LLM基于所有增量摘要生成最终的总览。2. 结构化信息提取这是体现Agent价值的关键。我们不能只让LLM生成一段概括性文字。而应该通过精心设计的提示词Prompt引导它输出结构化的JSON数据。例如{ meeting_topic: “Q2产品上线评审”, key_decisions: [ {decision: “后端架构采用微服务B方案” “reason”: “可扩展性更强” “maker”: “张工”} ], action_items: [ {task: “完成用户权限模块的详细设计文档” “assignee”: “王工程师” “deadline”: “2023-10-27”} ], next_steps: [“原型设计组周三前输出修改版”], pending_issues: [“与第三方支付接口的费率尚未最终确认”] }通过这样的结构化输出Agent就可以自动创建任务卡片、发送提醒邮件、更新Confluence页面等。3. 模型选型与成本对于这一步闭源的GPT-4、Claude-3或开源的DeepSeek、Qwen等大模型都能胜任。关键在于提示词工程和上下文长度。我选择了Qwen-Max的API因为其在长上下文理解和指令跟随方面表现稳定且对中文支持友好。为了控制成本增量总结使用较小的上下文窗口如4K而最终总结和问答则可以使用更长的上下文。2.4 语音合成TTS让结果“听得见”最后一步让Agent“开口说话”。这适用于多种场景会议实时字幕的语音播报为听障同事提供便利、会后你向Agent语音查询时的语音回答、甚至是自动生成的待办事项的语音提醒。TTS的选择同样面临三条路商用TTS API质量高、音色自然但同ASR一样有费用和隐私问题。开源大模型如 VITS, VALL-E效果逼近商用但需要大量计算资源和数据训练直接使用预训练模型可能存在音色固定或需要微调的问题。轻量级端侧模型如 ONNX Runtime 端侧 TTS这是当前的一个热点。将TTS模型如FastSpeech2、VITS的小参数量版本转换为ONNX格式利用ONNX Runtime在CPU或边缘设备上高效推理。优点是离线、低延迟、隐私好。缺点是音质和自然度可能不如大型模型。我实践了ONNX Runtime端侧TTS的方案因为它与“智能体”的本地化、即时响应理念最契合。我选择了一个开源的、效果不错的轻量级VITS模型将其转换为ONNX格式。在应用中当需要语音输出时将LLM生成的文本送入这个ONNX模型在本地CPU上推理几秒钟内即可生成音频流通过扬声器播放。虽然音色不如顶级商用方案那么富有情感但清晰度完全满足信息传达的需求且零延迟、零费用。3. 智能体Agent的行为设计从理解到行动有了强大的感知ASR和认知LLM能力我们的智能体还需要“动手”的能力。这就是Agent框架要解决的问题。它负责规划、决策、调用工具。3.1 不是所有场景都需要LangChain提到Agent很多人会立刻想到LangChain。它是一个强大的框架提供了大量的工具集成和链式调用能力。但对于我们“会议秘书”这个相对垂直的场景LangChain可能显得有些重。它的抽象层较多在定制化非常高的场景下有时不如自己编写清晰的逻辑来得直接和可控。我的设计是一个“事件驱动工具调用”的轻量级Agent。事件ASR实时转写出的文本片段、LLM提炼出的结构化信息如检测到“创建一个任务”、用户的语音查询指令。工具Tools一组定义好的函数每个函数对应一个动作。create_task(title, assignee, due_date): 调用飞书/钉钉/Teambition的API创建任务。send_email(to, subject, body): 发送邮件。update_wiki(page_id, content): 更新Confluence或Notion页面。query_meeting_memory(question): 向向量数据库检索会议记忆并回答。speak_text(text): 调用本地TTS引擎播报。决策中枢一个轻量的LLM调用例如使用Qwen的Function Calling能力。当事件发生时将事件内容如“请帮我把‘优化登录页性能’这个任务指派给前端小组下周五前完成’”和可用工具的描述发送给LLM。LLM会判断是否需要调用工具以及调用哪个工具、参数是什么并返回一个结构化的调用指令。我的程序再执行这个指令。这种设计的好处是逻辑清晰、响应快、易于调试。例如当LLM从会议文本中提取出{task: “优化登录页性能” “assignee”: “前端小组” “deadline”: “下周五”}时这个JSON对象会作为一个“创建任务事件”触发Agent。Agent的决策中枢LLM会将其匹配到create_task工具并填充参数然后执行。3.2 记忆与检索让Agent拥有“长期记忆”一个只能记住单次会议的Agent是不够的。它需要知道“上次我们讨论这个问题时发生了什么”、“这个项目的历史决策是什么”。这就需要为Agent引入记忆系统。我采用了一种混合记忆策略短期记忆/会话记忆存储在内存中保存当前会议滚动的摘要和上下文用于连贯的增量理解和问答。长期记忆使用向量数据库如Chroma、Milvus。每场会议结束后其最终的结构化摘要关键决策、行动项等和完整的转写文本或分块后的文本会被嵌入Embedding成向量存入数据库。检索增强当用户后续提问时如“我们去年关于技术选型是怎么决定的”先将问题嵌入然后在向量数据库中检索最相关的历史会议片段将这些片段作为上下文提供给LLM让LLM生成基于历史记忆的答案。这样你的办公Agent就真正成了一个拥有“公司记忆”的智能助手而不仅仅是单次会议的转录员。4. 工程化落地把原型变成可靠的服务将以上所有模块串联起来并确保其稳定、低延迟、可维护是另一个层面的挑战。4.1 链路延迟与流式优化实时性是体验的核心。从你说话到字幕显示再到智能体做出反应这个延迟最好控制在2秒以内。优化点包括ASR流式处理务必使用ASR模型的流式版本并设置合理的chunk_size如每0.5秒发送一次音频块。FunASR等服务端模型需要关注网络往返延迟。LLM调用异步化增量总结、工具调用等LLM请求不能阻塞主音频流。必须使用异步编程如Python的asyncio将LLM调用放入独立的任务队列中处理。管道并行不要让流程是严格的串行录音 - ASR - 等待LLM总结 - TTS。而应该是并行的流水线。当ASR在转写第N句时LLM可以同时在处理第N-1句的总结而TTS可能在播报第N-2句的结果。这需要良好的状态管理和消息队列如Redis来协调。在我的架构中我使用了Redis Streams作为各模块间的消息总线。音频采集模块将音频块发布到audio_streamASR服务订阅该流将识别文本发布到text_streamLLM处理模块订阅文本流并进行处理将结果摘要、工具调用指令发布到action_stream。TTS模块或工具执行模块再订阅相应的流。这样实现了松耦合和水平扩展。4.2 上下文管理与幻觉应对LLM的“幻觉”在会议总结中可能是灾难性的比如编造一个从未达成过的决议。应对策略提供充足且准确的上下文给LLM的提示词中要明确其角色和边界“你是一个严谨的会议秘书只基于提供的转写文本进行总结绝不添加文本中不存在的信息。”关键信息回溯验证对于LLM提取出的关键决策和行动项特别是涉及人、时间、数字的可以设计一个简单的验证步骤。例如让另一个轻量级模型或规则系统在原始转写文本中搜索相关关键词确认该信息确实被提及过。保留原文引用在结构化输出中可以要求LLM为每个提炼出的要点标注出它在原始转写文本中的大致时间戳或段落索引。这为人工复核提供了入口。4.3 部署与资源考量ASR/TTS服务FunASR和ONNX TTS模型可以封装为Docker容器通过Kubernetes或简单的Docker Compose管理。FunASR GPU版本推理速度快但需要准备GPU服务器。如果对实时性要求不苛刻CPU版本也可用但延迟会增加。LLM服务如果使用开源模型如Qwen需要部署相应的推理服务如vLLM或TGIText Generation Inference它们对高并发和长上下文做了优化。这部分是资源消耗大户需要根据并发用户数评估GPU数量。Agent核心服务用PythonFastAPI/Flask编写负责协调所有模块、处理业务逻辑、提供WebSocket或HTTP API给前端。它应该是无状态的方便扩缩容。一个最小化的原型部署可能如下一台4核8G的云服务器跑Agent核心、Redis和轻量级TTS另一台带单卡GPU如RTX 4090的服务器跑FunASR和Qwen-7B的LLM服务。这足以支撑一个小团队内部试用。5. 避坑指南与实战心得在搭建这套系统的过程中我踩过不少坑也积累了一些在文档里不容易找到的经验。坑一ASR的实时性与准确率悖论为了追求低延迟我一开始将ASR的chunk_size设得非常小100ms。结果发现识别准确率显著下降特别是句子开头和结尾的字词错误率高。这是因为模型缺乏足够的上下文来进行判断。解决方案需要一个“流式但带一定回溯”的机制。我最终采用了200-300ms的块大小并且在发送当前音频块时附带上前一个块的最后50ms数据作为“前瞻”这样在牺牲极小延迟的情况下大幅提升了流式识别的准确率。坑二LLM的结构化输出“抽风”即使给出了完美的JSON Schema提示词LLM偶尔还是会输出格式错误、字段缺失或类型不对的JSON。这会导致后续程序解析崩溃。解决方案不要完全信任LLM的输出。在代码中必须加入鲁棒的解析层。我使用Python的pydantic库来定义严格的数据模型并使用json_repair这样的库尝试自动修复微小的JSON格式错误。如果修复失败则记录日志并采用降级策略例如忽略该条信息或使用默认值保证服务不中断。坑三背景噪声与多人同时发言这是ASR的经典难题。虽然专用麦克风和云端会议音频能解决大部分问题但线下会议中激动的讨论场景仍难避免。应对策略首先在会前提醒大家尽量轮流发言这本身也是好的会议习惯。其次在ASR后处理阶段可以引入一个简单的基于规则的过滤器例如过滤掉长度过短可能是不完整的词或置信度过低的识别片段。更高级的方案可以尝试集成说话人分离DIAR模型但这对算力要求更高。心得一提示词工程是“性价比”最高的优化在LLM处理环节多花一小时打磨提示词可能比换一个更强大的模型效果提升更明显。对于会议总结我发现的黄金提示词结构是“角色定义 严格指令 输出格式示例 当前上下文”。例如“你是一名专业的项目经理正在整理会议纪要。请严格只基于下方‘转写文本’中的内容提取出关键决策、行动项和待办事项。行动项必须包含明确的任务描述、责任人和截止时间。输出必须为合法的JSON格式如下{...} 转写文本 [这里放文本]”。心得二从“自动”到“人机协同”最初我想打造一个全自动的Agent后来发现在关键决策点引入轻量级的人机协同体验和可靠性更好。例如当Agent识别出一个行动项并准备创建任务时可以先通过一个简单的聊天界面或语音向用户确认“识别到行动项‘王工程师在下周五前提交设计文档’。确认创建任务吗(Y/N)” 用户一个简单的确认就避免了AI误判带来的混乱。这比事后去修正一个错误创建的任务成本低得多。让会议记录“开口说话”本质上是将我们从一个繁琐、重复的信息整理工作中解放出来把精力聚焦于真正的思考、讨论和决策。这条语音智能链路的搭建涉及从音频信号处理到自然语言理解再到智能体决策的多个技术栈。它不是一个遥不可及的概念利用现有的开源模型和云服务一个小的技术团队完全可以在短期内构建出可用的原型。关键在于不要追求一步到位的完美而是先打通核心链路再围绕真实的使用反馈逐个环节进行优化和迭代。当你第一次听到自己打造的Agent清晰地复述出会议要点并自动把任务派发到同事名下时那种感觉绝对比听一段录音要美妙得多。
1. 从“哑巴”记录到“会说话”的助手一个真实的需求场景想象一下这个场景你刚开完一个长达两小时的跨部门产品评审会。会议结束时你看着笔记软件里那几百条零散的、只有自己能看懂的速记要点以及手机里那个长达120分钟的录音文件感到一阵头疼。你知道这里面藏着大量的关键信息、待办事项和决策点但要把它们整理成一份结构清晰、可执行、可追溯的会议纪要至少需要再花上一个小时——而这通常是你最没有的“一小时”。这就是传统会议记录的“哑巴”状态它被动地记录却无法主动地“开口”告诉你它说了什么、谁说了什么、接下来要做什么。而“智能办公 Agent”要做的就是让这条记录“活”过来。它不再是一个静态的文件而是一个能听、能说、能理解、能行动的智能体。核心的魔法就藏在一条完整的“语音链路”里从麦克风捕捉声音到语音识别ASR将其转为文字再到大语言模型LLM理解、提炼、结构化这些文字最后通过语音合成TTS将关键信息“说”给你听或者驱动其他应用执行任务。这不仅仅是把录音转成文字那么简单。市面上很多“语音转文字”工具做完这一步就结束了产出的是一份需要你从头到尾校对、整理的“文字墙”。真正的价值在于后续的“理解”与“行动”。一个设计良好的智能办公 Agent应该能自动识别出会议中的“行动项”Action Items并关联到责任人能提炼出核心决策与待办事项甚至能根据讨论内容自动生成邮件草稿、更新项目看板或者在日历中创建提醒。而“开口说话”的能力则让交互变得自然——你可以直接问它“刚才关于预算部分李总最后是怎么定的”它就能用语音回答你而不是让你去翻找那份长长的文本。我最近就在团队内部实践搭建了这样一套原型系统。整个过程并非一蹴而就其中涉及到开源模型选型、链路延迟优化、上下文理解精度以及最后的“智能体”行为设计等多个环节的权衡与踩坑。接下来我就把这套从声音到文字再到理解与行动的完整链路拆解清楚分享其中关键的技术选型逻辑、具体的实现步骤以及那些只有亲手做过才会知道的“坑”。2. 语音链路核心四步采集、转写、理解与合成一条能用的语音智能链路核心离不开四个环节语音采集、语音识别ASR、自然语言理解通常由LLM承担和语音合成TTS。每个环节的选择都直接决定了最终Agent的体验、成本和可用性。2.1 语音采集不仅仅是“录下来”很多人会忽略第一步认为用设备自带的麦克风录音就行。但在真实的会议环境中这往往是体验崩塌的起点。手机放在会议桌中央录下的声音混杂着远处的发言、键盘声、咳嗽声、还有可怕的回声和背景噪声。这样的音频喂给ASR模型识别准确率会大打折扣。注意语音链路的质量遵循“垃圾进垃圾出”原则。前端音频质量差后续环节再强大也无力回天。因此在实践中有几个提升采集质量的策略专用设备与阵列麦克风如果会议场景固定如会议室投资一个USB会议麦克风是性价比最高的选择。这类麦克风通常具备波束成形技术能定向拾取特定方向的声音有效抑制环境噪声。我测试过几款千元级的产品其对远场语音的拾取效果远超任何高端手机或笔记本电脑。软件端预处理如果只能用普通设备可以在音频流送入ASR前进行简单的软件预处理。例如使用pydub这样的库进行噪声抑制noise reduction和增益标准化normalization。一个简单的实践是在会议开始前先录制几秒纯环境噪声用于后续的噪声样本扣除。多端同步与云端混流对于线上会议如腾讯会议、Zoom更优的方案是直接获取会议云端的混流音频。这通常需要通过官方API如果有的话或虚拟声卡捕获系统音频输出。这样获得的音频是经过服务端降噪、增益均衡后的高质量单声道流是ASR的理想输入。在我的实践中我选择了第三种方案作为重点因为线上会议已是主流。我使用了一个开源的虚拟音频路由工具如VB-Audio Virtual Cable在Windows上或BlackHole在macOS上将会议软件的音频输出虚拟到一个“麦克风”输入设备再让我自己编写的Agent程序从这个虚拟设备捕获音频流。这样我就拿到了最纯净的语音源。2.2 语音识别ASR在“快、准、省”之间做权衡ASR是整个链路的基石它的选择决定了后续LLM能拿到多“干净”的原材料。当前选择无非三条路商用API、开源大模型、轻量级端侧模型。商用API如阿里云、腾讯云、讯飞优点是开箱即用准确率高尤其在中文场景通常自带标点预测、说话人分离等高级功能。缺点是持续产生费用且有数据隐私考量。对于需要快速验证原型或对准确率要求极高的生产环境这是首选。开源大模型如 OpenAI Whisper, FunASR优点是免费、可私有化部署、数据可控。Whisper的通用性极强中英文混合场景表现不错。FunASR则针对中文做了深度优化并提供了流式版本适合实时转写。缺点是对计算资源有一定要求尤其是大参数版本实时流式处理的延迟需要精心优化。轻量级端侧模型如 Nemotron-3.5-ASR-Streaming-0.6B这是NVIDIA最近推出的一个亮点模型参数量仅6亿专为流式ASR设计可以在边缘设备甚至高端手机上实时运行。优点是延迟极低、完全离线、隐私无忧。缺点是识别精度特别是对于专业术语和复杂背景噪声可能仍逊于大型商用API或Whisper-large。我的选型逻辑是这样的追求极致效果和快速上线用商用API追求数据隐私和定制化用开源大模型追求低延迟和离线部署用轻量级端侧模型。在本次实践中我选择了FunASR的流式部署方案。原因有三第一完全私有化满足内部数据安全要求第二针对中文优化在团队的技术讨论中术语识别准确率比Whisper有明显感知上的提升第三其流式服务框架FunASR-server设计得比较完善易于集成。我将其部署在一台带GPU的云服务器上通过WebSocket协议向它发送音频流并实时接收识别出的文字片段。这里的一个关键参数是vad_model语音活动检测和punc_model标点预测的启用它们能显著提升转写结果的可读性。2.3 自然语言理解与提炼LLM是大脑拿到连续的转写文本流后真正的智能开始了。这里LLM扮演了“会议秘书”的角色。但直接抛给LLM一整场会议的文本然后说“总结一下”效果往往不好成本也高。我们需要更精巧的设计。1. 流式处理与增量总结我们不需要等会议结束才启动理解。可以设计一个“滑动窗口”机制。例如每识别出大约500字或静默超过30秒就将这段时间的文本连同之前几分钟的上下文摘要一起发送给LLM要求其进行“增量摘要”。这样LLM始终在维护一个滚动的、浓缩的会议记忆。最终会议结束时再让LLM基于所有增量摘要生成最终的总览。2. 结构化信息提取这是体现Agent价值的关键。我们不能只让LLM生成一段概括性文字。而应该通过精心设计的提示词Prompt引导它输出结构化的JSON数据。例如{ meeting_topic: “Q2产品上线评审”, key_decisions: [ {decision: “后端架构采用微服务B方案” “reason”: “可扩展性更强” “maker”: “张工”} ], action_items: [ {task: “完成用户权限模块的详细设计文档” “assignee”: “王工程师” “deadline”: “2023-10-27”} ], next_steps: [“原型设计组周三前输出修改版”], pending_issues: [“与第三方支付接口的费率尚未最终确认”] }通过这样的结构化输出Agent就可以自动创建任务卡片、发送提醒邮件、更新Confluence页面等。3. 模型选型与成本对于这一步闭源的GPT-4、Claude-3或开源的DeepSeek、Qwen等大模型都能胜任。关键在于提示词工程和上下文长度。我选择了Qwen-Max的API因为其在长上下文理解和指令跟随方面表现稳定且对中文支持友好。为了控制成本增量总结使用较小的上下文窗口如4K而最终总结和问答则可以使用更长的上下文。2.4 语音合成TTS让结果“听得见”最后一步让Agent“开口说话”。这适用于多种场景会议实时字幕的语音播报为听障同事提供便利、会后你向Agent语音查询时的语音回答、甚至是自动生成的待办事项的语音提醒。TTS的选择同样面临三条路商用TTS API质量高、音色自然但同ASR一样有费用和隐私问题。开源大模型如 VITS, VALL-E效果逼近商用但需要大量计算资源和数据训练直接使用预训练模型可能存在音色固定或需要微调的问题。轻量级端侧模型如 ONNX Runtime 端侧 TTS这是当前的一个热点。将TTS模型如FastSpeech2、VITS的小参数量版本转换为ONNX格式利用ONNX Runtime在CPU或边缘设备上高效推理。优点是离线、低延迟、隐私好。缺点是音质和自然度可能不如大型模型。我实践了ONNX Runtime端侧TTS的方案因为它与“智能体”的本地化、即时响应理念最契合。我选择了一个开源的、效果不错的轻量级VITS模型将其转换为ONNX格式。在应用中当需要语音输出时将LLM生成的文本送入这个ONNX模型在本地CPU上推理几秒钟内即可生成音频流通过扬声器播放。虽然音色不如顶级商用方案那么富有情感但清晰度完全满足信息传达的需求且零延迟、零费用。3. 智能体Agent的行为设计从理解到行动有了强大的感知ASR和认知LLM能力我们的智能体还需要“动手”的能力。这就是Agent框架要解决的问题。它负责规划、决策、调用工具。3.1 不是所有场景都需要LangChain提到Agent很多人会立刻想到LangChain。它是一个强大的框架提供了大量的工具集成和链式调用能力。但对于我们“会议秘书”这个相对垂直的场景LangChain可能显得有些重。它的抽象层较多在定制化非常高的场景下有时不如自己编写清晰的逻辑来得直接和可控。我的设计是一个“事件驱动工具调用”的轻量级Agent。事件ASR实时转写出的文本片段、LLM提炼出的结构化信息如检测到“创建一个任务”、用户的语音查询指令。工具Tools一组定义好的函数每个函数对应一个动作。create_task(title, assignee, due_date): 调用飞书/钉钉/Teambition的API创建任务。send_email(to, subject, body): 发送邮件。update_wiki(page_id, content): 更新Confluence或Notion页面。query_meeting_memory(question): 向向量数据库检索会议记忆并回答。speak_text(text): 调用本地TTS引擎播报。决策中枢一个轻量的LLM调用例如使用Qwen的Function Calling能力。当事件发生时将事件内容如“请帮我把‘优化登录页性能’这个任务指派给前端小组下周五前完成’”和可用工具的描述发送给LLM。LLM会判断是否需要调用工具以及调用哪个工具、参数是什么并返回一个结构化的调用指令。我的程序再执行这个指令。这种设计的好处是逻辑清晰、响应快、易于调试。例如当LLM从会议文本中提取出{task: “优化登录页性能” “assignee”: “前端小组” “deadline”: “下周五”}时这个JSON对象会作为一个“创建任务事件”触发Agent。Agent的决策中枢LLM会将其匹配到create_task工具并填充参数然后执行。3.2 记忆与检索让Agent拥有“长期记忆”一个只能记住单次会议的Agent是不够的。它需要知道“上次我们讨论这个问题时发生了什么”、“这个项目的历史决策是什么”。这就需要为Agent引入记忆系统。我采用了一种混合记忆策略短期记忆/会话记忆存储在内存中保存当前会议滚动的摘要和上下文用于连贯的增量理解和问答。长期记忆使用向量数据库如Chroma、Milvus。每场会议结束后其最终的结构化摘要关键决策、行动项等和完整的转写文本或分块后的文本会被嵌入Embedding成向量存入数据库。检索增强当用户后续提问时如“我们去年关于技术选型是怎么决定的”先将问题嵌入然后在向量数据库中检索最相关的历史会议片段将这些片段作为上下文提供给LLM让LLM生成基于历史记忆的答案。这样你的办公Agent就真正成了一个拥有“公司记忆”的智能助手而不仅仅是单次会议的转录员。4. 工程化落地把原型变成可靠的服务将以上所有模块串联起来并确保其稳定、低延迟、可维护是另一个层面的挑战。4.1 链路延迟与流式优化实时性是体验的核心。从你说话到字幕显示再到智能体做出反应这个延迟最好控制在2秒以内。优化点包括ASR流式处理务必使用ASR模型的流式版本并设置合理的chunk_size如每0.5秒发送一次音频块。FunASR等服务端模型需要关注网络往返延迟。LLM调用异步化增量总结、工具调用等LLM请求不能阻塞主音频流。必须使用异步编程如Python的asyncio将LLM调用放入独立的任务队列中处理。管道并行不要让流程是严格的串行录音 - ASR - 等待LLM总结 - TTS。而应该是并行的流水线。当ASR在转写第N句时LLM可以同时在处理第N-1句的总结而TTS可能在播报第N-2句的结果。这需要良好的状态管理和消息队列如Redis来协调。在我的架构中我使用了Redis Streams作为各模块间的消息总线。音频采集模块将音频块发布到audio_streamASR服务订阅该流将识别文本发布到text_streamLLM处理模块订阅文本流并进行处理将结果摘要、工具调用指令发布到action_stream。TTS模块或工具执行模块再订阅相应的流。这样实现了松耦合和水平扩展。4.2 上下文管理与幻觉应对LLM的“幻觉”在会议总结中可能是灾难性的比如编造一个从未达成过的决议。应对策略提供充足且准确的上下文给LLM的提示词中要明确其角色和边界“你是一个严谨的会议秘书只基于提供的转写文本进行总结绝不添加文本中不存在的信息。”关键信息回溯验证对于LLM提取出的关键决策和行动项特别是涉及人、时间、数字的可以设计一个简单的验证步骤。例如让另一个轻量级模型或规则系统在原始转写文本中搜索相关关键词确认该信息确实被提及过。保留原文引用在结构化输出中可以要求LLM为每个提炼出的要点标注出它在原始转写文本中的大致时间戳或段落索引。这为人工复核提供了入口。4.3 部署与资源考量ASR/TTS服务FunASR和ONNX TTS模型可以封装为Docker容器通过Kubernetes或简单的Docker Compose管理。FunASR GPU版本推理速度快但需要准备GPU服务器。如果对实时性要求不苛刻CPU版本也可用但延迟会增加。LLM服务如果使用开源模型如Qwen需要部署相应的推理服务如vLLM或TGIText Generation Inference它们对高并发和长上下文做了优化。这部分是资源消耗大户需要根据并发用户数评估GPU数量。Agent核心服务用PythonFastAPI/Flask编写负责协调所有模块、处理业务逻辑、提供WebSocket或HTTP API给前端。它应该是无状态的方便扩缩容。一个最小化的原型部署可能如下一台4核8G的云服务器跑Agent核心、Redis和轻量级TTS另一台带单卡GPU如RTX 4090的服务器跑FunASR和Qwen-7B的LLM服务。这足以支撑一个小团队内部试用。5. 避坑指南与实战心得在搭建这套系统的过程中我踩过不少坑也积累了一些在文档里不容易找到的经验。坑一ASR的实时性与准确率悖论为了追求低延迟我一开始将ASR的chunk_size设得非常小100ms。结果发现识别准确率显著下降特别是句子开头和结尾的字词错误率高。这是因为模型缺乏足够的上下文来进行判断。解决方案需要一个“流式但带一定回溯”的机制。我最终采用了200-300ms的块大小并且在发送当前音频块时附带上前一个块的最后50ms数据作为“前瞻”这样在牺牲极小延迟的情况下大幅提升了流式识别的准确率。坑二LLM的结构化输出“抽风”即使给出了完美的JSON Schema提示词LLM偶尔还是会输出格式错误、字段缺失或类型不对的JSON。这会导致后续程序解析崩溃。解决方案不要完全信任LLM的输出。在代码中必须加入鲁棒的解析层。我使用Python的pydantic库来定义严格的数据模型并使用json_repair这样的库尝试自动修复微小的JSON格式错误。如果修复失败则记录日志并采用降级策略例如忽略该条信息或使用默认值保证服务不中断。坑三背景噪声与多人同时发言这是ASR的经典难题。虽然专用麦克风和云端会议音频能解决大部分问题但线下会议中激动的讨论场景仍难避免。应对策略首先在会前提醒大家尽量轮流发言这本身也是好的会议习惯。其次在ASR后处理阶段可以引入一个简单的基于规则的过滤器例如过滤掉长度过短可能是不完整的词或置信度过低的识别片段。更高级的方案可以尝试集成说话人分离DIAR模型但这对算力要求更高。心得一提示词工程是“性价比”最高的优化在LLM处理环节多花一小时打磨提示词可能比换一个更强大的模型效果提升更明显。对于会议总结我发现的黄金提示词结构是“角色定义 严格指令 输出格式示例 当前上下文”。例如“你是一名专业的项目经理正在整理会议纪要。请严格只基于下方‘转写文本’中的内容提取出关键决策、行动项和待办事项。行动项必须包含明确的任务描述、责任人和截止时间。输出必须为合法的JSON格式如下{...} 转写文本 [这里放文本]”。心得二从“自动”到“人机协同”最初我想打造一个全自动的Agent后来发现在关键决策点引入轻量级的人机协同体验和可靠性更好。例如当Agent识别出一个行动项并准备创建任务时可以先通过一个简单的聊天界面或语音向用户确认“识别到行动项‘王工程师在下周五前提交设计文档’。确认创建任务吗(Y/N)” 用户一个简单的确认就避免了AI误判带来的混乱。这比事后去修正一个错误创建的任务成本低得多。让会议记录“开口说话”本质上是将我们从一个繁琐、重复的信息整理工作中解放出来把精力聚焦于真正的思考、讨论和决策。这条语音智能链路的搭建涉及从音频信号处理到自然语言理解再到智能体决策的多个技术栈。它不是一个遥不可及的概念利用现有的开源模型和云服务一个小的技术团队完全可以在短期内构建出可用的原型。关键在于不要追求一步到位的完美而是先打通核心链路再围绕真实的使用反馈逐个环节进行优化和迭代。当你第一次听到自己打造的Agent清晰地复述出会议要点并自动把任务派发到同事名下时那种感觉绝对比听一段录音要美妙得多。
