1. 项目概述当会议室有了AI“大脑”最近在折腾一个挺有意思的项目我把它叫做RoomBot。简单来说就是给会议室装上一个AI“大脑”让它从一个被动的物理空间变成一个能主动感知、理解并协助会议进程的智能体系统。这听起来可能有点科幻但当你真正把一个AI Agent系统部署到会议室环境里你会发现它解决的痛点非常具体会议纪要整理得乱七八糟、会议室的设备开关和投屏永远需要有人去“伺候”、会议中的关键决策和待办事项总是散落在不同人的笔记里会后需要花大量时间对齐。RoomBot的核心就是通过一个集成了多模态感知摄像头、麦克风阵列、自然语言处理和大模型能力的本地化系统让会议室本身成为一个能“听”、能“看”、能“思考”、能“执行”的智能参与者。它不再是简单的语音助手升级版而是一个拥有明确目标如保障会议高效进行、能自主调用工具如控制设备、生成摘要、并与参会者进行上下文连贯交互的AI Agent。这个项目适合谁呢如果你是企业的IT负责人、行政或数字化部门的同事正在为提升会议效率发愁或者你是一位开发者、产品经理对AI Agent的落地场景充满好奇想了解如何将大模型能力与真实的物理世界、业务流程结合那么RoomBot的设计思路和踩坑经验或许能给你一些直接的参考。接下来我会从设计思路、技术选型、实操部署到问题排查完整拆解这个项目。2. 核心设计思路与架构选型给会议室设计一个AI系统首要问题不是堆砌最炫的技术而是想清楚它到底该以什么角色介入会议我们的答案是一个低调、可靠、专注的“协作者”或“书记员”而不是一个试图主导会议的“主持人”。这个定位直接决定了整个系统的架构设计。2.1 核心需求解析从“记录”到“理解与行动”传统的会议解决方案比如单独的录音笔或视频会议系统核心功能是“记录”和“传输”。RoomBot的目标是“理解”和“行动”。我们拆解出四个层次的需求环境感知与交互层系统必须能清晰捕捉会议室内的语音和视觉信息。这不仅仅是录音录像还包括识别说话人声纹识别、识别举手等肢体动作、看清白板或屏幕上的内容。同时它需要具备语音合成能力用自然的人声进行反馈和询问。语义理解与上下文管理这是AI Agent的核心。系统需要实时将语音流转换成文字并理解对话的上下文。例如当有人说“把刚才提到的三点总结一下发邮件”系统需要知道“刚才提到的三点”具体指什么以及“发邮件”这个动作的目标对象和内容。工具调用与自动化执行理解之后是行动。系统需要能调用一系列工具API例如控制会议室灯光、空调、投影仪将会议摘要和待办事项同步到公司的OA或项目管理工具如钉钉、飞书、Jira甚至是在获得授权后直接起草并发送会议纪要邮件。隐私、安全与可靠性会议室讨论的往往是商业机密。因此所有音频、视频数据的处理必须优先考虑本地化部署。大模型的调用也需要通过私有化部署或高度可信的API进行确保数据不出域。同时系统必须稳定不能频繁中断或误触发干扰会议。2.2 架构选型边缘计算中心大脑的混合模式基于以上需求我们放弃了纯云端方案延迟高、隐私风险大和纯端侧方案算力有限难以运行复杂模型。最终采用了“边缘计算节点 中心推理服务器”的混合架构。边缘节点部署在会议室硬件采用集成了高性能麦克风阵列和广角摄像头的专用设备我们选用了类似NVIDIA Jetson Orin NX这样的边缘AI计算盒。它的任务是完成所有原始数据的采集、预处理和轻量级AI任务。职责音频处理8麦克风阵列实现360度拾音、降噪、声源定位和说话人分离。视频处理实时视频流采集、人脸检测用于匿名化处理或签到、动作识别举手、以及白板/屏幕内容捕捉。实时语音转文字运行一个轻量化的本地ASR模型将语音实时转为文字流低延迟地发送给中心服务器。设备控制通过红外、蓝牙或局域网协议直接控制房间内的IoT设备。中心服务器可部署在企业机房或私有云硬件配备高性能GPU的服务器。职责大模型推理运行私有化部署的大型语言模型负责核心的语义理解、上下文管理、摘要生成和决策。多模态信息融合接收来自边缘节点的文字流、关键图像快照进行融合分析。例如结合语音“请翻到下一页”和捕捉到的PPT画面理解当前讨论的文档位置。工作流引擎根据LLM的决策调用具体的工具API。例如LLM判断需要生成会议纪要则触发纪要生成工作流调用模板引擎并最终通过邮件服务或OA接口发送。为什么选择这个架构主要权衡了延迟、隐私和成本。原始音视频数据在边缘预处理后只上传文本和关键元数据极大减少了带宽占用和隐私泄露风险。复杂的LLM推理放在中心服务器可以共享算力降低成本。实测下来从用户发出指令到系统响应端到端延迟可以控制在1.5秒以内体验流畅。注意在选型初期我们尝试过完全在边缘设备上运行7B参数左右的“小”模型。虽然隐私性最佳但面对复杂的会议场景其理解能力、上下文长度和工具调用准确性明显不足经常“答非所问”或“遗忘”之前的内容。因此对于要求高的商业场景中心化部署更强能力的模型是更务实的选择。3. 关键技术模块深度拆解RoomBot不是一个单一模型的应用而是多个技术模块的精密协作。下面我挑几个最有挑战性的模块讲讲我们的实现方案和踩过的坑。3.1 多模态信息感知与同步“听清”和“看清”是基础但更难的是“对齐”。会议室里人们说的话和屏幕上展示的图表、白板上画的草图是紧密相关的。我们的方案是建立一个基于时间戳的同步机制。音频流水线麦克风阵列处理我们使用了开源项目REAPER的算法进行语音增强和分离它能有效抑制空调噪音、键盘声并将重叠的语音分开。这是后续声纹识别和转写准确的基础。说话人日志采用pyannote-audio工具包进行说话人分离和聚类。这里的关键是我们不仅区分不同人还为每个说话人生成一个临时ID并与企业通讯录的声纹库需提前授权录制进行匹配从而在会议纪要中直接显示“张三说...”而不是“说话人A说...”。实时语音转写边缘设备上运行Faster-Whisper模型。选择它是因为它在精度和速度间取得了很好的平衡并且支持流式传输。我们将音频流切成500ms的片段进行实时转写生成带时间戳的文字流。视频流水线视觉焦点识别使用YOLO模型实时检测画面中的关键区域人脸、白板、投影屏幕、手势如举手。我们不是持续分析整个视频流而是当音频流检测到特定关键词如“看白板”、“请看屏幕”或检测到举手动作时才触发高分辨率截图并上传分析。白板/屏幕内容识别这是一个亮点也是难点。我们训练了一个自定义的PaddleOCR模型专门针对会议室场景下的白板手写体和屏幕字体进行了优化。当系统判定当前讨论焦点是白板时会自动矫正透视变形、去除反光然后进行OCR识别将识别出的文本与当前时间点的语音文本进行关联。同步与关联 所有音频、视频事件都打上高精度的时间戳毫秒级。中心服务器的上下文管理模块维护着一个“时空上下文缓冲区”。当LLM需要理解“这个图表”时系统会检索前后5秒内识别出的视觉内容将其作为上下文提供给LLM。这相当于给了AI一双能回顾刚才所见场景的“眼睛”。3.2 基于LLM的智能体核心引擎这是RoomBot的“大脑”。我们将其设计为一个具有分层决策能力的智能体。指令识别与意图分类 并非所有语音都需要LLM处理。我们首先设置了一个轻量级的“触发词过滤器”。当语音转写文本中包含“RoomBot”、“小R”、“总结一下”等预设触发词或检测到明显的疑问句语调时才会将这段文本及其上下文送入LLM。这避免了LLM持续运行带来的算力浪费和误触发。上下文管理 LLM的“记忆力”是关键。我们采用了一种“滑动窗口关键信息提取”的混合策略。滑动窗口LLM的对话上下文始终保持最近10分钟的完整对话文本。关键信息提取同时一个独立的“信息萃取”模块会实时运行从对话中提取结构化信息决策项如“决定采用A方案”、待办事项如“张三下周提交报告”、问题点如“接口性能未达标”。这些结构化信息被存入一个数据库不受上下文窗口长度限制随时可供LLM查询。 这样即使会议开了2小时当用户问“我们刚才定了哪些TODO”LLM可以去查询结构化的待办数据库而不是在几十页的对话历史里大海捞针。工具调用 我们为LLM定义了一套清晰的工具集并用Function Calling的方式实现。工具包括control_light(state)控制灯光。generate_summary(topic)根据指定话题生成摘要。create_task(title, assignee, deadline)在OA系统创建任务。send_email(summary, recipients)发送邮件。 LLM在理解指令后会自主判断是否需要调用工具、调用哪个工具并生成符合工具要求的参数。例如用户说“RoomBot把刚才讨论的推广方案要点发给李四和王五。” LLM会先调用generate_summary(“推广方案”)生成摘要再调用send_email工具发送。实操心得在定义工具时一定要把工具的“能力边界”和“参数格式”描述得极其清晰。初期我们定义control_device工具过于笼统LLM有时会试图用它去“打开咖啡机”会议室并没有。后来我们把工具拆解为control_light,control_air_conditioner,control_projector等具体工具并严格限定参数枚举值准确率大幅提升。3.3 隐私安全与数据合规设计这是企业客户最关心的问题没有妥协余地。我们的设计原则是“数据最小化”和“处理本地化”。音频/视频数据流原始音视频数据永不离开边缘设备。在设备上完成降噪、转写、特征提取后只有文本流和经脱敏处理的元数据如“说话人ID张三”而非声纹特征被加密传输至中心服务器。视频流仅传输经检测后的关键帧截图如白板区域且截图可配置在边缘进行人脸模糊化处理。模型部署核心LLM采用私有化部署。我们对比了多个开源模型最终选择了Qwen-14B-Chat的INT4量化版本在保证足够理解能力的同时单卡GPU即可流畅运行。所有微调和推理均在客户内网完成。传输与存储所有数据传输使用TLS 1.3加密。服务器上的对话文本日志在会议结束后24小时自动删除可配置保留期。结构化信息决策、TODO在加密后存入客户自有的数据库。权限与唤醒设备默认处于“监听但休眠”状态只有被唤醒词可自定义或物理按钮触发后才会进入主动录音和交互状态。会议桌显眼处设有指示灯明确显示当前是否处于活跃录音状态。4. 系统部署与集成实操指南理论讲完说说怎么把它真正跑起来。部署RoomBot可以分为硬件准备、软件安装、业务集成三步。4.1 硬件准备与边缘设备配置我们推荐以下硬件配置作为起点组件规格要求备注边缘计算盒NVIDIA Jetson Orin NX 16GB算力足够功耗低适合长期运行。AGX Orin性能更强但成本也高。麦克风阵列环形8麦克风阵列USB套件确保拾音半径覆盖整个会议室通常5-8米。摄像头4K超广角USB摄像头带自动对焦广角需能覆盖白板、屏幕和主要座位区。控制中枢支持红外/蓝牙/Wi-Fi的智能网关如BroadLink用于统一控制会议室内的非智能电器。网络千兆有线网络连接必须使用有线网络Wi-Fi的延迟和波动无法接受。边缘设备软件配置步骤刷写基础系统在Jetson设备上刷写JetPackSDK包含Ubuntu和CUDA。安装核心依赖# 安装Python环境及基础包 sudo apt-get update sudo apt-get install python3-pip python3-venv python3 -m venv roombot_env source roombot_env/bin/activate # 安装PyTorch (for Jetson) pip3 install --pre torch torchvision torchaudio --index-url https://download.pytorch.org/whl/nightly/cu121 # 安装音频处理库 pip3 install numpy scipy webrtcvad librosa # 安装REAPER语音增强 git clone https://github.com/google/REAPER.git cd REAPER mkdir build cd build cmake .. make部署边缘服务将我们编写的边缘服务程序包含音频采集、ASR、设备控制等模块克隆到设备。git clone your-roombot-edge-repo cd roombot-edge pip install -r requirements.txt配置与校准声学校准运行校准脚本让设备在空会议室环境下采集环境底噪并测试每个麦克风的灵敏度。摄像头标定调整摄像头位置确保画面覆盖关键区域并运行一个简单的标定程序建立屏幕/白板区域的坐标映射便于后续OCR定位。设备控制学习使用智能网关学习空调、投影仪、灯光遥控器的红外信号并给每个设备定义一个友好的别名如“主灯”、“投影仪”。4.2 中心服务器部署与模型服务中心服务器建议配置双路Intel Xeon Silver或AMD EPYC处理器至少128GB内存一张RTX 4090或A100 GPU1TB NVMe SSD。部署LLM API服务我们使用vLLM或FastChat作为推理引擎它们对开源模型的支持好推理效率高。# 使用vLLM部署Qwen模型示例 pip install vllm python -m vllm.entrypoints.openai.api_server \ --model /path/to/Qwen-14B-Chat-Int4 \ --served-model-name roombot-llm \ --api-key your-api-key-here \ --port 8000这样就启动了一个兼容OpenAI API格式的LLM服务。部署RoomBot核心服务这是一个用Python FastAPI编写的服务包含上下文管理、工具调用、工作流引擎等所有逻辑。git clone your-roombot-core-repo cd roombot-core pip install -r requirements.txt # 修改配置文件 config.yaml填入LLM API地址、数据库连接、各工具API密钥等 uvicorn main:app --host 0.0.0.0 --port 8080配置反向代理与SSL使用Nginx将服务暴露到内网并配置HTTPS证书。4.3 与企业现有系统集成这是体现价值的关键一步。RoomBot需要与企业的“生产力流”打通。与会议管理系统集成在OA或日历系统如Outlook、飞书日历中创建会议时可以勾选“启用RoomBot”。系统会自动将会议主题、时间、参会人列表同步给RoomBotRoomBot会提前“知晓”会议背景。与即时通讯工具集成通过机器人webhook将会议中生成的实时摘要、待办事项同步到会议群聊中。例如在飞书群里RoomBot可以每隔一段时间自动发送一条“当前讨论要点”的消息。与项目管理工具集成这是杀手级功能。当会议中产生“TODO”时RoomBot通过API直接在Jira、Teambition或飞书任务中创建任务并负责人。我们定义了一套任务模板LLM会从对话中提取任务标题、描述、负责人和截止日期并自动填充。会后纪要自动归档会议结束后RoomBot生成最终版会议纪要格式美观包含讨论要点、决策、待办并自动上传到企业的知识库如Confluence、语雀指定目录或发送邮件给所有参会者。集成配置示例以飞书任务为例在config.yaml中配置tools: feishu_task: app_id: your_app_id app_secret: your_app_secret default_task_list_id: 任务清单ID在工具调用层实现一个create_feishu_task函数接收LLM解析出的参数调用飞书开放平台API创建任务。5. 实战问题排查与优化经验在实际部署和试运行中我们遇到了无数问题。这里分享几个最具代表性的以及我们的解决方案。5.1 音频问题听不清与回声啸叫问题描述在较大会议室或多人同时发言时转写准确率骤降。有时系统还会产生刺耳的回声或啸叫。排查与解决拾音距离问题麦克风阵列的拾音范围是有限的。对于超过8米的大型会议室我们增加了第二个麦克风阵列部署在会议室另一端通过软件进行音频流同步和融合。回声消除当RoomBot通过音箱播放语音反馈时声音会被麦克风再次采集形成回声。我们启用了边缘设备上的WebRTC AEC算法并进行了精细的参数调优。关键技巧在调试时播放一段特定的测试音录制回声然后调整AEC的滤波器长度直到回声在频谱图上基本消失。啸叫抑制当麦克风和音箱形成声学反馈环路时产生啸叫。除了调整设备位置我们在音频流水线中加入了一个简单的限幅器和自适应陷波滤波器实时检测并抑制特定频率的峰值。5.2 LLM“幻觉”与指令误解问题描述LLM有时会“捏造”会议中没出现过的内容或者错误理解指令例如把“把空调调低点”理解成“调低灯光亮度”。优化策略提示词工程这是最重要的环节。我们设计了系统化的提示词模板你是一个专业的会议室助理RoomBot。请严格遵守以下规则 1. 你的知识仅限于本次会议对话内容如下文和已定义的工具。 2. 如果用户请求的信息不在会议记录中请直接回答“根据会议记录未提及该信息”。 3. 调用工具时必须严格使用提供的JSON格式。 会议记录[此处插入最新的上下文] 可用工具[工具列表及格式] 用户指令{user_input}通过反复强调“基于给定上下文”能有效减少幻觉。工具调用规范化为每个工具提供大量示例。在LLM的微调数据中加入大量“用户指令-正确工具调用”的配对样本进行有监督微调。后处理校验对于“创建任务”、“发送邮件”这类高风险操作增加一个后处理确认环节。例如当LLM生成一个任务创建请求后系统会语音播报“我将为张三创建任务‘完成市场分析报告’下周五前提交确认吗”用户回答“确认”后才真正执行。5.3 系统延迟与稳定性问题描述用户感觉指令发出后反应慢或者在长时间会议后期系统响应变慢甚至卡住。性能优化点上下文窗口管理这是影响延迟和内存占用的主要因素。我们实现了动态上下文窗口。对于普通的问答只提供最近3分钟上下文。当检测到“总结”、“回顾”等关键词时才加载更长的上下文或从结构化数据库中检索。异步处理与流水线将音频接收、转写、LLM推理、语音合成等步骤设计成异步流水线。当LLM在处理上一个请求时新的音频已经在被转写而不是排队等待。边缘模型量化将边缘设备上运行的Faster-Whisper模型转换为INT8精度在几乎不损失精度的情况下推理速度提升近一倍。健康检查与看门狗部署独立的监控进程定期检查各服务状态。如果某个服务如ASR无响应看门狗会自动重启它并记录日志。我们在边缘设备上设置了一个硬件看门狗如果系统完全死机会自动断电重启。5.4 常见问题速查表问题现象可能原因排查步骤与解决方案无法唤醒麦克风静音或故障唤醒词不匹配1. 检查麦克风物理连接和系统录音设置。2. 重新进行唤醒词训练在会议室不同位置测试。3. 适当降低唤醒词检测的阈值。转写文字全是乱码或空白ASR服务未启动或模型路径错误音频格式不对1. 检查边缘设备上ASR服务进程状态。2. 检查音频采样率必须为16kHz和编码格式PCM。3. 运行一个简单的音频录制和本地转写测试脚本。LLM回复“我不知道”或无关内容提示词被破坏上下文丢失网络超时1. 查看发送给LLM的完整提示词日志确保格式正确。2. 检查上下文管理服务确认最新的对话已正确注入。3. 检查中心服务器与LLM API之间的网络连接和超时设置。设备控制失败智能网关离线红外码库不对权限问题1. 检查智能网关的网络连接和电源。2. 重新学习该设备的红外信号。3. 检查RoomBot服务是否有调用控制API的权限。会议纪要未发送邮件服务配置错误收件人列表为空被反垃圾邮件拦截1. 检查邮件服务的SMTP配置和密码。2. 检查会议参会人列表是否同步成功。3. 查看邮件服务商日志检查是否被拒信。6. 效果评估与未来迭代方向部署了几套系统并运行一段时间后我们收集了一些数据和反馈。最直接的收益是会后行政工作时间平均减少了约40%因为纪要整理和任务分发自动化了。参会者也反馈因为有AI实时记录他们更能专注于讨论本身而不是忙着记笔记。从技术指标看在标准会议室环境下15人以内正常环境噪音我们的系统达到了语音唤醒准确率98%指令理解与执行准确率92%端到端平均响应延迟1.8秒会议纪要关键信息抽取完整率85%当然还有很长的路要走。接下来的迭代方向很明确多模态理解的深化目前对白板草图、复杂图表的内容理解还比较初级。下一步计划集成多模态大模型让RoomBot真正能“看懂”手绘流程图、架构图并理解其含义。个性化与自适应系统可以学习不同团队的会议习惯。例如技术评审会更关注“风险”和“阻塞项”而创意脑暴会则更关注“点子”。我们可以让LLM针对不同类型的会议自动调整摘要的侧重点和模板。主动式介入现在的RoomBot主要还是“被动响应”。我们正在试验一些轻度主动介入的功能比如在检测到会议偏离主题时间过长时轻声提醒“我们已就XX话题讨论了15分钟是否需要回到原议程”或者在检测到所有人沉默一段时间后主动询问“是否需要我复述一下刚才达成的共识”。这个度需要非常小心地把握避免引起反感。做这个项目的过程中我最大的体会是AI Agent要真正落地技术实现只占一半另一半是对业务场景的深度理解和打磨。每一个工具的定义、每一个提示词的调整、每一个异常情况的处理都需要反复在真实的会议场景中去测试、去感受。它不是做一个炫酷的演示而是打造一个默默工作、切实提升效率的“数字同事”。