“Ask HN: When will the AI version of 911 happen?” 这问题挂在 Hacker News 首页的时候讨论重点根本不在“预测”而在工程现在的 LLM、实时语音识别、地图定位、工单系统、多级调度到底能不能拼出一个“AI 版 911”与其等预言不如先把这件事拆成技术问题。AI 版 911本质上不是一个大模型而是一条实时链路电话或 App 接入语音ASR 转写LLM 理解意图和抽取信息决策引擎判断紧急程度再自动生成工单或拉起调度。这里每一步都有现成组件可用但每一步也都有坑。这篇文章就按 CSDN 读者最关心的顺序来写先看这套系统由哪些模块组成硬件和软件门槛是什么然后给一套可以落地的架构、部署示例、功能测试方法、API 批量任务思路以及最容易出问题的环节。如果你正在做智能呼叫中心、应急指挥、社区告警、政务热线、企业服务台这篇可以直接当参考框架用。1. AI 版 911 核心能力速览先说结论AI 版 911 不是一个单一模型而是一个“实时语音 多模态大模型 位置感知 工单调度”的事件响应系统。从技术栈角度看它和智能客服、AI Agent 工作流、实时音视频处理是同一个底座。能力项说明系统类型AI 应急呼叫中心 / 智能事件响应系统核心输入电话语音、App 上报、文字消息、位置信息、图片/视频AI 能力语音转写、意图识别、事件分级、槽位抽取、多轮对话、工单生成关键门槛实时语音链路、低延迟推理、可靠调度而不是单一模型精度硬件要求电话接入网关可用 CPU大模型推理建议 GPU显存按模型规模实测推荐架构接入层 会话层 AI 理解层 决策层 调度层 数据层是否支持批量任务支持批量运行工单、批量外呼、批量演练都需要队列机制是否支持 API支持语音网关、LLM 服务、工单系统均通过 API 集成适合场景智能客服、应急热线、社区告警、企业内部服务台、活动保障不适合场景完全替代人类调度员、涉及责任判定的医疗/消防决策、无授权录音分析从材料看HN 热帖里讨论的“AI 版 911”更多是概念展望还没有出现统一的公共开源项目。所以下文提供的是一套基于行业通用组件的实现方案不是某个现成开源仓库的安装教程。实际落地时需要根据你所在地区的电话号码段、呼叫平台、地图服务、大模型 API 做替换。2. 适用场景与使用边界AI 版 911 的落地场景可以分成三段来看。第一段是“信息收集型”场景最适合现在做。用户打电话进来AI 在接通后完成标准化问询发生了什么、几个人受伤、具体位置在哪、现场是否安全。这个过程信息密度高、重复性高正好是 LLM 加 ASR 的强项。系统把结构化信息实时推给后方调度员调度员只需要做最终判断。这种模式不追求 AI 直接出警而是把人的重复劳动减掉。第二段是“分流引导型”场景也就是可预测问题的自动处理。例如电力故障报修、水管爆裂、噪音投诉、紧急避险指引。AI 判定事件类型后直接推送对应的处置指引或自动创建工单。这类场景风险更低适合先灰度上线。第三段是“完全自动决策型”场景例如 AI 直接派警、AI 指挥救援。这个阶段目前不建议做。原因不是模型能力不够而是责任边界不清晰。一次误判可能导致严重后果目前没有成熟的法律和技术标准支撑全自动闭环。使用边界必须明确涉及录音、人脸、位置、身份信息时一定要先做用户授权和隐私评估涉及医疗、消防、警务等公共安全决策时人类调度员必须在环模型输出只能作为建议不能直接作为执法或医疗依据。合规不是上线后的补丁而是架构的一部分。3. 系统架构与核心模块设计一套可落地的 AI 应急呼叫系统建议分成六层接入层负责电话呼叫、App 上报、网页客服的接入。常用组件包括 Asterisk、FreeSWITCH、Twilio、腾讯云/阿里云呼叫中心以及自建 WebRTC 网关。会话层维护通话状态、会话 ID、上下文记忆负责和 ASR/TTS 组件双向流式传输。这里需要一个会话管理服务通常用 Redis 存短期状态用数据库存最终记录。理解层ASR 将语音转为文本LLM 理解用户意图、抽取事件信息TTS 负责回复用户。这个层是 AI 版 911 的核心也是延迟的大头。决策层根据事件类型、严重程度、重复投诉次数、位置信息决定走自动处置、人工介入还是转交工单。调度层把决策结果落到具体动作例如创建工单、发送短信定位链接、通知值班人员、召唤志愿者、启动批量外呼。数据层存储通话音频、转写文本、工单记录、处置结果。数据层要支持回放、统计、模型微调和事后复盘。这里最容易犯的错误是想用一个 Agent 干所有事。实际项目中语音识别、意图理解、工单生成、地图解析最好拆成独立服务。原因有三一是不同模块的更新频率不同耦合在一起会导致上线困难二是故障隔离ASR 挂了不应该影响工单生成三是压测和容量规划更简单哪个模块并发不够单独加机器就行。下面给出一份最小架构组合按 50 并发的应急呼叫中心估算硬件可按实际负载调整模块推荐组件说明呼叫接入Asterisk / FreeSWITCH / Twilio负责电话进线和媒体流语音识别Whisper 系列或云 ASR流式转写延迟敏感对话理解GPT 类 API 或本地 LLM意图分类 信息抽取语音回复Edge TTS / CosyVoice 等 TTS支持流式播放任务队列Redis Celery / Kafka批量任务、异步处理业务数据库PostgreSQL / MySQL工单、通话记录地图定位高德/百度/Google 地图 API地址解析、围栏判断值班通知Webhook / 短信 / IM 机器人通知调度员这个组合里LLM 部分可以用 API也可以用本地模型。本地部署的优势是数据不出内网劣势是 GPU 成本和运维复杂度。应急类业务通常涉及敏感录音很多机构会考虑本地部署开发阶段先用云端 API 跑通流程上线前再换本地模型是更稳妥的推进方式。4. 本地部署与开发环境准备开发一套 AI 版 911 的最小环境不需要完整的电话交换机。先用模拟音频文件和 WebSocket 打通链路后面再接真实呼叫平台。建议准备以下环境一台 Linux 服务器或开发机推荐 16GB 以上内存。Python 3.10用于 ASR、LLM 调用脚本。Docker 和 Docker Compose用于启动数据库、Redis、队列服务。一个可用的 LLM API Key或一个本地模型服务如 Ollama / vLLM。ASR 服务可以先用本地 Whisper也可以接云厂商 API。一个支持 Webhook 的 IM 或短信服务用来模拟调度通知。下面是基础服务编排示例直接保存为docker-compose.ymlversion: 3.8 services: redis: image: redis:7-alpine container_name: ai911-redis ports: - 6379:6379 postgres: image: postgres:15-alpine container_name: ai911-postgres environment: POSTGRES_USER: ai911 POSTGRES_PASSWORD: ai911_password POSTGRES_DB: ai911 ports: - 5432:5432 volumes: - pg_data:/var/lib/postgresql/data worker: build: . command: celery -A app.tasks worker --loglevelinfo environment: REDIS_URL: redis://redis:6379/0 DATABASE_URL: postgresql://ai911:ai911_passwordpostgres/ai911 depends_on: - redis - postgres volumes: pg_data:这个编排只演示了状态存储和任务队列实际项目的 ASR、LLM、TTS 服务需要根据你选的组件单独添加。启动命令docker compose up -d docker compose logs -f worker第一次开发时不建议直接接电话线。先用一段 mp3 录音做离线测试再通过 WebSocket 做流式模拟最后接入真实呼叫网关。这样每一层的错误都能单独定位。5. 核心流程与提示词设计AI 版 911 的对话流程和普通客服机器人最大的不同在于“确定性输出”。普通客服可以自由回话应急系统必须稳定抽取事件信息并输出结构化 JSON。先定义事件信息 Schema{ event_type: fire|medical|police|traffic|utility|other, location: { address: 北京市朝阳区XX路XX号, lat: 39.9042, lng: 116.4074, accuracy: user_description }, injured_count: 0, fire_or_smoke: false, danger_description: 现场有明火烟雾较大, caller_safety: safe|danger, need_ambulance: false, need_police: false, emergency_level: low|medium|high }LLM 的系统提示词可以按这个模板设计你是一个应急呼叫中心智能助手。你的任务是 1. 用自然、稳定、不慌乱的语气和报警人对话。 2. 每次回答必须以 JSON 形式返回字段提取和确认话术。 3. 如果信息缺失只询问缺失字段不要重复询问已确认字段。 4. 如果报警人情绪激动先安抚再询问关键问题。 5. 判断紧急程度。有人伤、明火、暴力威胁时直接标记 high。 6. 不要承诺出警时间不要给出医疗或法律建议。 7. 对话结束时输出完整事件 JSON。提示词里加入“不要承诺出警时间”“不要给医疗建议”是为了在技术层面阻止模型越权。LLM 在应急场景里最危险的行为不是答错而是替人类做本不该它做的决定。这些约束必须写死在提示词里并且上线前用测试集单独验证。下面是一个简化版的对话调度状态机接通后 AI 播报这里是智能应急呼叫助手请描述发生了什么。ASR 转写用户发言。LLM 提取槽位判断缺失字段。缺失则继续追问完整则确认高价值字段。调用地图 API 解析地址。生成事件 JSON推给决策引擎。根据 emergency_level 决定自动建单或人工接管。这个流程里的“确认高价值字段”很关键。例如用户说“我在XX小区”系统要追问“具体几栋几单元”因为地址精度直接决定调度是否有效。这类追问规则不一定要靠 prompt 硬控也可以写一段槽位校验逻辑只要 location.address 为空或缺少门牌号就必须回到追问状态。6. 功能测试与效果验证AI 版 911 项目最需要测试的不是“模型能不能聊天”而是“链路稳不稳定、信息抽取准不准、误报高不高”。建议按以下维度建测试集。6.1 语音转写测试目的验证 ASR 对噪声、口音、专有名词的识别率。准备 50 到 100 条带噪音的应急场景音频包含地址、人名、车牌号。跑完后计算字错率CER和关键字段识别率。如果关键地址老错可以在 ASR 服务里挂热词表把本地路名、小区名、单位名加进去。6.2 意图与槽位抽取测试目的验证 LLM 是否稳定输出事件 JSON。准备一组典型对话文本调用 LLM 后做字段比对。判断标准事件类型、地址、受伤人数、紧急程度四个字段与标注一致。import json import requests url http://127.0.0.1:8000/parse payload { conversation: [ {role: user, content: 我家楼下着火了有烟冒出来地址是幸福路12号。目前没有看到人受伤。} ] } response requests.post(url, jsonpayload, timeout30) result response.json() required_fields [event_type, location, emergency_level] for field in required_fields: assert field in result, fmissing field: {field} print(json.dumps(result, ensure_asciiFalse, indent2))这个测试脚本可以扩展到整批测试集把输出存成 JSON 文件再用自动化脚本统计准确率。建议至少覆盖火灾、医疗急救、交通事故、噪音投诉、纠纷、重复骚扰电话六类场景。6.3 多轮对话完整性测试目的验证 AI 不会陷入死循环或重复询问。模拟用户不配合、口齿不清、情绪激动的情况。判断标准AI 在 5 轮内拿到完整 JSON如果用户一直不配合AI 能自动转人工而不是无限追问。失败时优先检查两处一是 prompt 里是否缺少“信息缺失则追问完整则停止追问”的约束二是状态机里是否对追问次数做了上限。LLM 对话再强也必须有硬性轮次上限兜底。6.4 全链路压测目的验证 50 路并发时的系统稳定性。压测时重点观察三个指标首响延迟、ASR 转写延迟、工单创建成功率。不要只看平均延迟要观测 P95 和 P99。应急系统里某一次 20 秒超时可能会导致通话重拨或信息丢失所以延迟分布比平均值更重要。7. 接口 API 与批量任务设计AI 版 911 不只是一个对话系统它要对接大量外部系统呼叫平台、地图服务、IM、短信、工单系统。这些对接都靠 API。下面给出两个最关键接口的设计思路。7.1 事件解析接口将一段对话文本解析为结构化事件curl -X POST http://127.0.0.1:8000/parse \ -H Content-Type: application/json \ -d { conversation: [ {role: user, content: 我在建设路附近的公园里看到一个老人摔倒了他有意识一直在说膝盖疼。} ] }返回 JSON{ event_type: medical, location: { address: 建设路附近公园, lat: null, lng: null, accuracy: user_description }, injured_count: 1, emergency_level: high, report: 报警人称在建设路附近公园发现一名老人摔倒意识清醒主诉膝盖疼痛。 }地址坐标为空时系统调用地图服务补全。这个接口要设计成幂等的同一段通话被重放时返回的 JSON 字段结构必须一致避免重复建单。7.2 批量外呼与批量任务队列应急场景里有很多批量需求向某区域用户发送预警、批量回访工单、例行演练。这类任务不能同步执行要进队列。建议用 Redis 加 Celery 实现任务队列。任务体示例{ task_id: b8f1-7d2a, batch_type: broadcast, caller_number: 10086, target_list: [138****1234, 139****5678], message_template: 您所在区域发生XX事件请勿靠近注意安全。, max_retry: 3 }Python 伪代码from celery import Celery app Celery(ai911_tasks, brokerredis://redis:6379/0) app.task(max_retries3, default_retry_delay5) def batch_call(target_list, message_template): for number in target_list: try: call_gateway.send_tts_call(number, message_template) except Exception as exc: batch_call.retry(excexc, args[number, message_template])批量任务最大的坑是重复发送。Celery 默认在任务超时后可能重新执行如果只发送但没有标记“已发送”用户会收到多条相同信息。解决方式是在 Redis 里维护一个任务状态表发送前先检查key: task_id:number是否存在已存在则跳过。8. 资源占用与性能观察AI 版 911 的资源消耗集中在 ASR 和 LLM 两个环节电话接入层本身开销很小。关于显存占用这里不给一个死数字因为不同模型、不同上下文长度、不同并发数差异很大。更稳妥的判断是如果使用 Whisper 系列做本地语音识别建议准备 6GB 以上显存的 GPU如果使用本地 7B 到 14B 量级的 LLM建议 12GB 到 24GB 显存。如果完全使用云端 API本机只需要运行业务服务CPU 和内存压力主要来自并发请求处理。性能观察建议走三个层面基础设施层用nvidia-smi看 GPU 显存和利用率用docker stats看容器 CPU/内存。应用层在 API 增加耗时日志分别记录 ASR 耗时、LLM 耗时、地图解析耗时。业务层统计从用户开始说话到工单落库的总时长。并发增加时最可能先扛不住的是 LLM 推理服务而不是数据库。因为电话呼叫天然有音频流ASR 是流式推理LLM 反而可能是串行处理。容量规划的时候要把 LLM 服务单独拆出去支持多副本部署。降低资源占用的常用手段ASR 开启流式转写而不是等整句话说完再识别。LLM 回复控制在 100 字以内减少生成时间。大模型换小模型。应急场景的信息抽取任务7B 模型通常够用。对高并发时段做任务排队而不是无限拉起新进程。9. 常见问题与排查方法AI 版 911 系统上线初期事故大概率出在链路集成上而不是模型效果上。下面的排查表可以直接用于故障定位。问题现象可能原因排查方式解决方案电话打进后没有声音呼叫网关和 ASR 媒体流断开检查网关日志、WebSocket 连接状态重启媒体服务确认端口别被防火墙拦截用户说完话识别为空音频采样率不匹配或噪音过大查看 ASR 服务日志回放录音统一采样率到 16kHz开启降噪LLM 一直追问已确认字段提示词缺少终止逻辑在测试集回放对话流程增加状态机硬性轮次限制地址解析错误用户描述含糊或地图 API 被限流查看地图 API 返回码提示词里加“逐级询问省市区、道路、门牌号”工单重复创建事件 POST 请求重放检查幂等键逻辑用通话 ID 做唯一约束重复请求直接返回原单批量外呼重复发送Celery 任务重试查看任务日志和 Redis 状态发送前检查任务状态键高并发时 LLM 响应变慢推理服务无队列或副本不足观察 P95 延迟和 GPU 利用率加副本、做限流、排队用户情绪激动 AI 答非所问模型缺少安抚话术回放语料检查系统提示词提示词加入安抚步骤检测到 high 级事件直接转人工最容易被忽略的是“转人工”机制。AI 必须能判断自己处理不了并且把当前的完整上下文无缝交给人类调度员。这个机制建议在第 1 版就实现而不是后期加。因为没有人能保证 LLM 在真实通话中 100% 成功转人工是安全兜底。10. 最佳实践与合规建议AI 版 911 这类系统Engineering 之外最重要的事情是合规。以下几条建议可以在项目一开始就写进架构文档所有通话录音在进入 AI 链路前必须做用户知情告知。可以在接通后由 TTS 播报“本次通话可能被录音”。录音文件、转写文本、位置信息分开存储不进入同一个无权限数据库。敏感字段做脱敏。姓名、身份证号、手机号在日志和 LLM 对话中要用掩码显示。LLM 输出必须经过结构化校验。宁可系统报错也不能让格式错误的工单进入调度流程。设置 AI 置信度阈值。低置信度事件强制转人工不追求 100% 自动化。事件处置结果必须留痕。每一单 AI 生成的结论、人工复核结果、最终处置状态都要可追溯。涉及人脸识别或声纹识别时必须单独评估生物识别风险不建议和应急对话链路混在一起。从工程实践看这个系统最值得先验证的不是 LLM 能不能听懂用户而是“整条链路能不能在 30 秒内把一次通话变成一条带定位、带事件分级、带人工接续能力的工单”。最容易踩的坑也不是模型不准而是刚开始就把所有能力堆在一个 Agent 里。我建议先按“语音接入 - ASR - LLM 结构化抽取 - 地图补全 - 工单落库 - 人工复核”的简化链路跑通一次再逐步加入多轮追问、批量外呼、自动通知。第一次演示给业务方看的时候只跑通 30 秒内完成一次结构化事件上报比展示十个模型能力更有说服力。下一步可以扩展的方向有三个一是接入真实 VoIP 网关把模拟链路换成真实电话二是训练一份应急领域专用的小模型替代通用大模型做槽位抽取三是把历史工单数据回流到模型评估集建立持续回归测试。对应急类业务来说稳定、可预测、可回放比模型大小更重要。