WebRTC 搞定了音视频流的传输。谁有权建房谁有权加入谁有权踢人旁观和发言有什么区别断线了怎么处理这些是信令服务器的活。这套自研协议只有 10 条左右信令，覆盖了远程帮办的全部业务场景。所有状态变更必须经过服务器——不是性能最优的方案，但状态一致性最高。政务场景不需要百万人并发，但绝对不能在通话中丢了状态。信令层的代码不复杂。复杂的是想清楚"每个状态下谁可以做什么"。这个想清楚了，代码是自然推导

本项目通过Ollama本地Embedding + Milvus向量检索 + DeepSeek推理零Embedding API成本的语义检索基于知识库的准确回答（减少幻觉）流式输出 + 语音交互的良好用户体验整套方案技术栈开源、部署简单，适合政府、企业等有私有知识库的智能客服场景。相关技术文档Milvus官方文档：https://milvus.io/docsOllama官方文档：https://ol

政务远程帮办要在政务网络环境中部署，而政务网络和互联网是物理隔离的。如何实现：关键问题：WebRTC 在政务网络里怎么跑？关键节点互联网区（老百姓端）a机（代理服务器）网闸摆渡政务外网（业务系统）为什么a机很重要？问题：WebRTC P2P直连在政务网络里走不通原因：解决方案：a机必须中转最初的想法：把视频流转发到政务外网后来认为不行：摆渡是个麻烦事政务外网和互联网是物理隔离的，网闸摆渡有：折中方

前两天跟 AI 聊天，我丢过去两个互联网老故事。一个是雷军 1998 年 15 万收购 Foxmail，被员工一句"这东西我们一两个月就能做出来"给搅黄了；另一个是马化腾想把 QQ 50 万卖给搜狐，对方说"几个大学生几个月就搞出来了"。我问他：“这个剧本有没有熟悉的味道。他开始表演了。长篇大论地分析"逆袭爽文模板"，什么"错失的贵人"“极致的低谷”“绝境翻盘的高光”，列了七八条，还主动问我要不要

本文介绍了社保智能客服Agent在多模态交互与完整业务流程中的实现方案。主要内容包括： 两种业务流程设计： 字段流（fields）：适用于纯信息收集类业务，如社保转移需收集4个字段 步骤流（steps）：适用于需要多模态交互的业务，如养老金认证需身份证OCR和人脸核验 关键技术实现： 身份证OCR采用PaddleOCR解析，通过正则提取关键信息并自动填充表单 人脸核验实现活体检测+1:1比对，与上

Agent 不是替代 RAG，是 RAG 的**上层建筑**。它基于 OpenAI 兼容的 Function Calling，**根据用户当前所处的状态，给 LLM 提供不同的工具集**。- **步骤流（steps）**：需要拍照或人脸的业务（如养老金资格认证），先走身份证 OCR，再走人脸核验，最后确认提交。对话历史也在上下文里。状态机的好处是**任何时候用户说"取消"，都能从任意状态跳回 id

Agent 不是替代 RAG，是 RAG 的**上层建筑**。它基于 OpenAI 兼容的 Function Calling，**根据用户当前所处的状态，给 LLM 提供不同的工具集**。- **步骤流（steps）**：需要拍照或人脸的业务（如养老金资格认证），先走身份证 OCR，再走人脸核验，最后确认提交。对话历史也在上下文里。状态机的好处是**任何时候用户说"取消"，都能从任意状态跳回 id

摘要：本文记录了一位20年老程序员与AI协作，仅用2-3小时搭建社保智能客服系统的实战过程。系统从单轮问答升级为多轮Agent，实现了12项社保业务办理功能。开发采用真/假服务分层策略，核心功能使用真实服务，非关键模块用桩模拟。文章详细记录了14个关键问题的解决过程，包括字段校验、上下文处理、语音集成等挑战。最终系统支持多业务配置化扩展、敏感信息后置采集、移动端语音交互等特性，展示了AI辅助开发的

摘要：本文记录了一位20年老程序员与AI协作，仅用2-3小时搭建社保智能客服系统的实战过程。系统从单轮问答升级为多轮Agent，实现了12项社保业务办理功能。开发采用真/假服务分层策略，核心功能使用真实服务，非关键模块用桩模拟。文章详细记录了14个关键问题的解决过程，包括字段校验、上下文处理、语音集成等挑战。最终系统支持多业务配置化扩展、敏感信息后置采集、移动端语音交互等特性，展示了AI辅助开发的

摘要：SRAM与HBM在AI计算中的性能对比分析 研究对比了8GB片上SRAM与160GB HBM在AI推理和训练中的表现。关键发现： 推理场景：在≤4K序列长度时，SRAM方案凭借30TB/s的权重访问带宽（HBM的9倍），延迟降低2.5-3倍；超过8K序列后HBM才显现优势 训练场景：256卡并行时，SRAM方案因优化器状态需通过DDR交换（800GB/s），训练步时比HBM慢约15%，但通过