摘要：
高德面对数据存储扩展和成本效率、极致的性能要求、容灾高可用保障三大挑战，传统分库分表架构已无法支撑海量业务数据。其选择 OceanBase 原生分布式数据库升级核心业务，依托其高压缩、异地多活、MySQL 兼容能力，实现零感知平滑迁移。升级后存储成本、响应时间、研发效率均得到显著优化，容灾能力增强，完成从分库分表到原生分布式的数据底座演进。

提起高德，许多人首先想到的是其精准的数字地图。但如今的高德，早已不仅仅是一款导航工具，而是发展成为覆盖衣食住行等全场景的“国民级”出行服务平台。

数据显示，高德的日活跃用户数最高已突破 3.6 亿人次（截至 2025 年 10 月 1 日），日均活跃用户也稳定在 1.5 亿人次以上。如此庞大的用户体量，为高德的业务系统带来了海量数据存储与实时响应的双重挑战，尤其在五一、国庆等出行高峰期间，后台系统承受的压力更为显著。

面对持续增长的业务压力，传统基于分库分表的数据库架构已无力支撑。在这一背景下，高德开始探索将数据库升级至新一代分布式数据库 OceanBase 的可行路径。其中，“足迹”与“云同步”等核心业务，成为此次升级的先行者。

高德地图在线服务应对海量存储三大核心挑战与思考

作为高德地图出行服务技术负责人，李岩的核心职责之一是应对各业务快速发展带来的高并发与海量存储挑战。

“用户每一次路线规划、每一次地点搜索的背后，都是对系统稳定性与体验感的极致考验。我们必须确保每一次请求都稳如磐石，用户体验如丝般顺滑。”李岩表示。

高德的技术体系构建在云原生基础设施之上，依托云的弹性伸缩能力，可根据业务需求快速实现资源的扩缩容，从而为上层应用的开发与部署提供极大的灵活性。高德强大的云底座也让李岩能更专注于应对大并发、低延迟的海量存储带来的技术压力。

李岩将高德应对海量数据所面临的核心挑战归纳为三方面：

一是数据存储扩展和成本效率，即如何合理部署与分配业务数据。这不仅关乎存储成本，更直接影响业务模型能否实现低成本的扩展与迭代，进而影响整体业务效率。

二是极致的性能要求。高德的在线服务必须在高 QPS/TPS 下保持低耗时的响应，并能在需要时实现平滑的弹性伸缩。同时，系统还需具备故障快速发现、诊断与恢复的能力。

三是容灾高可用保障。系统需支持在出现故障时实现“一键”逃逸能力与逃逸的力度，并尽可能让用户对此过程无感知。

实际上，无论是“足迹”还是“云同步”，这些核心业务系统数据库升级的目标正是为了应对上述三个核心挑战。

选择 OceanBase：解决千亿级数据规模的分库分表架构瓶颈

高德的“足迹”服务是一项自动记录用户历史出行与停留地点的位置服务。它通过持续收集定位数据，生成个人专属的出行时间轴，帮助用户回顾、管理和分享自己的移动路线。目前，数据规模已超过 7000 亿条，存储规模突破 360TB，读写并发峰值平均每秒超过 27 万次请求。

“‘足迹’需要在 10 毫秒内响应用户请求，是一种典型的海量数据、高并发、低延迟业务场景，对底层数据库系统要求极高。”李岩表示。

“足迹”原先采用分库分表架构。虽在一定程度上缓解了数据量的问题，但随着业务不断迭代、数据量不断增长，其弊端也逐渐凸显：例如大表以及大表在做索引变更时会引发抖动，进而影响系统稳定性；其次，一些模型拓展以及数据归档成本都相对较高，在成本上持续面临压力。

鉴于业务的快速增长，李岩和团队选择从底层存储层入手，做一次彻底的治理和升级，彻底解决分库分表架构带来的性能瓶颈，满足业务快速发展对数据底座的全新要求。

从业务角度而言，此次治理和升级，高德地图在数据库选型上需满足三大方面的要求：高可用、业务效率和成本。经过测试和对比以后，最终选择 OceanBase 来服务高德地图。

李岩表示，之所以选择 OceanBase，是因为其具有原生分布式和单机分布式一体化架构，具备弹性扩展、高可用和多活容灾能力。同时，除了 OceanBase 的性能稳定、产品成熟度高，已经过市场充分验证外，还有三点能力也是他看中的：

1.极致的存储压缩：OceanBase 提供多种压缩方式，显著降低存储规模；
2.高度兼容 MySQL：减少应用层代码修改量，助力业务平滑升级。
3.原生多活架构支持：可以根据业务需求灵活地选择。

高德足迹大规模在线升级的考量与实践：零故障、零问题、用户零感知的平滑跃迁

在确定采用 OceanBase 后，高德随即启动了系统化的升级工作。在千亿级别数据规模下，要做在线的升级，风险非常高。最终，凭借充分的准备与 OceanBase 团队的有力支持，整个升级过程实现了零故障，而且终端用户完全零感知，实现了业务的平滑跃迁。

在李岩看来，能够顺利完成此次“足迹”业务的升级，重点在于做好以下几方面的工作：

第一，站在全域、全链路的视角，放量回切控制点保持强统一、强同步、强一致，特别是涉及多层级的服务调用依赖时，这点尤其关键，否则就容易出现读写错位、放量错位的问题。

第二，进行多维度的数据校验。在“足迹”数据升级过程中，从最底层到最上层，分别进行了数据级、SQL级以及业务级的对比。只有三个校验都没有问题，才是真的没有问题。

第三，全量数据同步吞吐量高。这次升级过程中，OMS 的吞吐达到了每秒 1000 万行的并发写入，大大缩短了迁移周期。

升级后的系统平稳，已历经今年“双十一”等流量高峰期的考验，运行稳定、流畅，整体表现优异。对于此次数据库升级，李岩认为非常成功，为高德带来了多方面的实质性收益：

成本显著优化：OceanBase 通过高效的压缩算法，压缩比达到 2.23:1，数据规模得到降低，存储成本节省 55.2%。

性能持续提升：系统平均响应时间由原来的 5.95 毫秒降至 4.42 毫秒，提升了 25.7%，用户体验进一步改善。

研发效率提高：业务开发人员无需再关注分片、路由、弹性扩缩容等底层细节，“如同操作单机 MySQL 一样使用分布式数据库”。

OceanBase 异地多活架构在高德的落地实践

“云同步”是高德的另一项核心业务。“云同步”主要完成用户多端设备（如多个手机之间、手机与车机之间）的数据同步。

该业务的显著特点是数据量极为庞大，仅 3 个单元的数据总量就高达 5000 亿条。这一在线服务场景，对数据的实时性和高可用性都提出了极高的要求。

为了保证用户体验，同时也为了容灾，“云同步”在具体的业务场景下联合 OceanBase 采用了异地多活架构，在上海、张北、深圳三个数据中心分别进行部署。业务应用层提供多点写入的能力，基于用户维度进行单元化的路由和单元化的纠偏；中间的底层存储则依赖 OceanBase 的三地五中心金融级无损容灾能力部署，最下层的数据通路通过 OMS 来实现。

李岩介绍，由于高德需要实现不同单元间的双向同步，整个同步链路相对复杂，最终形成了三地六项的同步架构。“多活的目的，是为了就近接入以降低延迟，均衡各地域的资源分布和利用率，同时提升服务的 SLA，实现完全的高可用。同时，‘云同步’性能也得到了显著提升，实现了读写 QPS/TPS 22 万，读写平均响应时间 10 毫秒以内。升级后性能表现平稳，并且无论是水位还是 OMS 三地间同步链路也非常平滑。”

“如果没有 OceanBase 原生的多活能力，数据同步逻辑就必须在应用层实现，这不仅会大幅提升系统复杂度，也会显著增加开发和维护成本。”李岩说。

同时，系统的容灾能力也得到明显增强：当某个业务中心发生故障时，可在分钟级完成流量切换至其他数据中心，实现真正意义上的跨地域容灾逃逸。

结语

回看 OceanBase 在高德多个核心业务系统的应用，李岩认为，收益主要体现在以下三方面：

简单：提高了研发效率，业务研发像使用单机一样去使用分布式存储，不用关心分区、路由等等细节问题；

降本：因为有多种数据压缩手段以及数据和日志的分离，带来较高压缩比，数据规模越大，效果越明显；

多活和高可用：能保障数据的强一致性，提供多种多活部署方案，业务可按需选用。

“更重要的是，从分库分表到原生分布式数据库，高德完成的不仅是一次数据库升级，更是一场面向未来的架构演进，还为未来的业务发展预留了充足空间。”李岩总结说。

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

在日常工作和学习中，我们经常需要对比两段文字或代码及其差异。

比如程序员在排查 Bug 时，需要对比修改前后的代码片段；文案编辑在校对文章时，需要找出修订的具体位置；或者是运维人员在对比两个配置文件的细微不同。

如果仅仅依靠肉眼去逐行扫描，不仅效率极低，而且非常容易看走眼，漏掉关键的差异点。

今天给大家分享一个我开发的在线工具——文本差异对比器 (Text Diff Checker)，它可以帮你一键快速找出两段文本的所有不同之处。

在线工具网址：https://see-tool.com/diff-checker
工具截图：

工具核心功能

1. 多种对比模式
工具支持三种精度的对比模式，满足不同场景的需求：

• 按行对比 (Line)：适合代码或长文章，快速定位哪些行发生了变化。
• 按词对比 (Word)：适合英文文章或短语，精确到单词级别的差异。
• 按字符对比 (Char)：适合对比密钥、哈希值或细节要求极高的文本，精确到每一个字符。

2. 直观的高亮显示
采用经典的“红删绿增”配色方案：

• 红色背景：表示左侧文本中被删除或修改的内容。
• 绿色背景：表示右侧文本中新增或修改后的内容。
  差异一目了然，不需要任何学习成本。

3. 灵活的辅助选项

• 忽略空格：有时候仅仅是缩进不同，勾选此项可以忽略空白字符的差异。
• 忽略大小写：不区分大小写的比对。
• 显示行号：方便定位具体位置。

技术实现 (Vue 3)

作为一个前端开发者，我使用目前流行的 Vue 3 (Composition API) 框架配合 Tailwind CSS 编写了这个工具。

纯前端处理，安全无忧
值得一提的是，这个工具的所有计算逻辑完全在你的本地浏览器中运行。这意味着：你输入的任何文本（无论是机密代码还是私人文章）都不会被上传到服务器。你可以放心大胆地使用它来对比敏感数据，隐私安全有绝对保障。

响应式设计
工具对移动端和桌面端都做了适配。无论你是在电脑前工作，还是临时用手机查看差异，都能获得良好的使用体验。

如何使用

1. 打开工具页面，你会看到左右两个输入框。
2. 在左侧输入框粘贴“原始内容”，在右侧输入框粘贴“修改后的内容”。
3. 根据需要选择对比模式（默认是“按行对比”）。
4. 点击中间的 “开始对比” 按钮。
5. 页面下方会立即生成对比报告，显示增加/删除的行数统计，并高亮展示差异详情。

结语

这个小工具虽然功能单一，但在关键时刻能帮我们节省大量的时间和精力。如果你也受够了用肉眼“且”不同，不妨试试这个文本差异对比器。

欢迎大家使用并提出宝贵意见！

2026年开年， 一个名为 OpenClaw 的开源 AI 智能体项目在开发者社区引发广泛关注。不同于云端对话式助手，OpenClaw 直接在本地运行，能够操作软件、收发邮件、执行代码，甚至可以自动完成一系列跨应用的任务。

这种“本地执行”能力能否在企业 ITSM 场景中找到用武之地？轻帆云 ITSM 团队尝试将这一能力引入服务管理流程，探索一种减少界面交互、提升服务效率的新可能。

从图形界面到自然语言：轻帆云的“去 UI 化”探索“

最好的 UI，就是没有 UI。”——当服务足够智能，用户便无需与界面打交道。

在传统 ITSM 模式中，用户需主动登录系统、浏览服务目录、填写表单、提交工单，并在后续反复登录以跟踪进度、处理驳回、催办超时、完成评价——整个过程高度依赖界面操作与人工干预，使用门槛高、体验割裂。

在已跑通飞书/Telegram 端的实验室环境中，轻帆云通过集成 OpenClaw，实现了 IT 服务流程的“去 UI 化”重构：用户只需在对话中自然表达需求，例如 “帮我开下 CRM 权限，我要处理上个月的财务报表”，系统即可自动解析意图、创建工单，并全程驱动后续流程。

工单临近超时时，系统会自动向处理人发起催办；若被驳回，则尝试分析原因、补充必要信息并重新提交。

任务完成后，结果将即时推送至用户，满意度评价也依预设规则自动完成。

用户无需再登录后台，也无需记忆流程节点。这一变革将服务入口从“系统后台”迁移至“日常对话”，把被动查询转变为主动服务，让智能 IT 服务真正走向“无感、无扰、无界面”。

Opencalw驱动的轻帆云ITSM：“去 UI 化”探索的实现路径

“去 UI 化”的本质，并非消除界面，而是让用户在发起和跟踪 IT 服务时，无需主动打开或操作 ITSM 系统界面。这一体验的背后，是一套端到端的自动化执行链路。

用户在 Telegram 中的一句话，如何驱动复杂的 ITSM 流程？其核心在于以下四个环节的紧密协同：

1、语义解析 —— OpenClaw 的“大脑”

用户输入“帮我申请 CRM 权限”，OpenClaw 即时识别意图（如 dosm_create），并将模糊请求拆解为结构化参数（例如 system: CRM），替代了传统流程中手动浏览目录、填写表单的操作。

2、身份穿梭 —— 合规的安全桥梁

系统自动捕获用户的 Telegram ID，并精准映射为轻帆云内部真实的 userId（如 19733）。所有操作均以真实身份执行，满足企业审计与权限管控要求，实现安全可信的“AI 代用户操作”。

3、协议封包 —— AI 的“手脚”

OpenClaw 调用预定义 Skill，将参数封装为符合轻帆云接口规范的 JSON 表单（含必要转义与认证字段），并通过 POST /orderCreate 请求直接创建工单，全程绕过前端界面，实现无感系统交互。

4、感知反馈 —— 即时的服务闭环

工单状态变更后，轻帆云通过 Webhook 实时回传数据，OpenClaw 将系统响应转化为自然语言消息（如“单号 WO123 已生成，处理人正在审批中”），主动推送至用户对话窗口，无需用户主动查询。

正是这套链路，让用户无需登录、无需填表、无需查进度，即可完成 IT 服务主流程——界面依然存在，但已退居幕后，由 AI 代理完成交互。

轻帆云的 AI 能力中台：让“去 UI 化”快速落地“

去 UI 化”体验的快速实现，源于轻帆云早已构建的 AI 能力中台——一个面向企业级 ITSM 场景设计的开放智能架构。

该中台底层兼容主流大模型服务（如 DeepSeek、通义、讯飞星火等），中层集成了自研的 RAG 引擎、长短时记忆机制、工作流编排系统与多 Agent 协同框架，完整覆盖从自然语言理解到跨系统执行的全链路需求。

正因具备这一标准化、可扩展的智能底座，好用的轻帆云IT服务管理平台无需为 OpenClaw 进行定制开发，仅通过配置即可将其作为外部智能体接入，驱动工单创建、状态追踪等核心流程。整个过程不改造原有 ITSM 系统，不影响现有业务运行，真正实现了“去 UI 化”能力的敏捷交付。

前沿探索·驱动轻帆云ITSM持续进化

从大模型DeepSeek到智能体OpenClaw，国内主流企业级智能IT服务管理平台——轻帆云始终致力于将前沿 AI 能力转化为可落地的产品价值。正是这种对新技术的高效集成能力，让“去 UI 化”等创新体验得以快速实现，并持续推动 ITSM 服务向更智能、更无感的方向演进。

详询热线：400-666-1332

在现代制造业中，同一产品往往有多种规格配置，比如汽车的颜色、配置等级，电器的不同型号等。这些多样化需求如何体现在生产计划中？
JVS-APS排产系统的拓展属性管理模块负责对这些产品特征进行统一管理和分类，使生产计划能够基于产品多维度特性进行精准排产，满足现代制造业个性化定制的需求。
以下解读所用到的是开源的JVS智能排产系统。
JVS-APS系统是由软开企服开源的一款智能排产系统，系统聚焦于离散制造行业（如汽车、电子、机械、航空航天等）及流程制造行业（如化工、食品、医药等），面向中大型企业客户，通过AI驱动的智能算法，实现生产计划与排程的高效性、准确性、敏捷性，帮助企业提升设备利用率、降低库存成本、缩短交付周期，实现精益生产与数智化转型。
拓展属性是指在生产一个产品时，该产品所带有的一系列特征或标识。好比汽车有不同系列、颜色、尺寸大小等，这些都可称为汽车的属性。所以属性管理模块即是对生产产品的自带特征或标识作为属性进行管理。

功能说明

• 属性新增
通过系统对产品自带属性进行新增。
• 属性查看
将所有属性集中放于一个列表之中，便于查看与管理。

操作步骤

1、点击【基础数据】下面的【属性管理】，进入属性管理页面。

2、点击【新增属性】，即可进入新增页面。

3、新增属性页面需输入对应的属性名(需用户手动输入，可自定义属性名称)、属性key（默认为属性名的拼音，也可自定义key值）、属性校验（是否必填校验）、属性类型（可选择 文本框、数字框、下拉框、单选、多选 这几种类型）。

4、填写完相关信息后点击提交即会出现在列表页中，可对数据进行二次编辑或删除。

5、此外还有查询功能，可选择输入属性名或属性key或选择属性类型这几种方式，查出其中对应一条或相同类型的多条数据。输入完成后点击查询即可查到相关数据信息。

拓展属性管理看似是很简单的功能，其实无论是离散制造还是流程制造行业，合理利用，不仅解决了多品种小批量生产的复杂性问题，还可以帮助企业实现从“人治”到“数智”的转型升级。

开发者朋友们大家好：

这里是 「RTE 开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@瓒an、@鲍勃

01 有话题的技术

1、Tavus 发布实时视听感知模型 Raven-1：能读懂讽刺与犹豫，赋予 AI 真实「情商」

Tavus 公司近日发布了专为实时 AI 打造的视听感知模型 Raven-1。 该模型旨在解决当前对话式 AI 仅能理解文字而无法感知人类真实意图的痛点。不同于依赖转录文本的传统系统，Raven-1 通过原生多模态感知系统，将音频、视觉和时间动态融合为统一的理解框架，从而捕捉用户说话时的语气、表情、犹豫及语境。

Raven-1 在前代产品 Raven-0 视觉理解的基础上，实现了音视频流的实时对齐。其核心能力包括：

• 视听融合：将语调、韵律、面部表情、姿势和注视方向整合为单一感知表征，能准确区分真诚的微笑与讽刺的假笑。
• 句子级时间建模：追踪对话中的情绪和注意力演变，捕捉如挫败感累积或怀疑消退等细微叙事弧线。
• 自然语言输出：生成可解释的自然语言描述而非离散标签，使下游 LLM 能直接理解复杂的情感状态。
• 实时响应：总流水线延迟低于 600 毫秒，且上下文新鲜度（context freshness）保持在 300 毫秒以内，确保 AI 能在恰当时机做出反应。

该系统还支持通过 OpenAI 兼容模式调用自定义工具，允许开发者定义特定事件（如大笑或注意力转移）以触发相应操作。在 Tavus 的技术栈中，Raven-1 与对话流程模型 Sparrow-1 及情感渲染系统 Phoenix-4 协同工作，形成「感知-响应」闭环，显著提升了对话的深度与自然度。

Raven-1 的应用前景广阔，特别是在医疗健康、教育培训及招聘面试等高风险场景中，它能帮助 AI 实时识别患者不适、学员参与度或求职者的非语言信号。目前，该模型已在 Tavus 平台上线。

Demo:

https://raven.tavuslabs.org/

Blog:

https://www.tavus.io/post/raven-1-bringing-emotional-intellig...

( @tavus@X、@Tavus Blog)

2、智谱新模型架构曝光：DeepSeek 同款稀疏注意力

日前，据海外博主「Chetaslua」消息，智谱下一代模型（或为 GLM-5）将采用 DeepSeek 同款架构。

据 Chetaslua 分析，GLM-5 将采用了 DeepSeek-V3/V3.2 架构，其中包含稀疏注意力机制（DSA）和多 Token 预测（MTP）；模型总参数量达 745B，将会是上一代 GLM-4.7 的 2 倍。

值得一提的是，近期有一个名为「Pony Alpha」的神秘模型上线全球模型服务平台 OpenRouter，并且引发较高热度。其中不乏有人分析指出，该模型或为智谱新的模型。

而据第一财经消息，智谱目前有相关保密项目在推进中，该神秘模型，是智谱即将发布新一代模型 GLM-5。

据悉，OpenRouter 合作方 Kilo Code 曾透露，Pony Alpha 是「某个全球实验室最受欢迎的开源模型的专项进化版」。

对此，报道指出，Pony Alpha 更有可能是 DeepSeek-V4 或者智谱即将发布的新一代模型 GLM-5。

( @APPSO)

3、vLLM 推出流式输入与 Realtime API：打破批处理限制，解锁低延迟实时推理

vLLM 联合 Meta 与 Mistral AI 推出流式输入功能及 WebSocket 「Realtime API」。该更新打破了先接收完整请求、再开始推理的传统范式，允许模型在用户说话或数据传输过程中同步处理，为语音助手、实时转录及机器人控制等低延迟场景提供了原生支持。

• 「StreamingInput」增量接口：核心输入对象从静态 Prompt 升级为异步生成器。开发者可以像「喂料」一样，将数据碎块随时间 yield 给引擎，实现边输入边处理。
• 「Anchor Request」锚定会话模式：会话启动时建立一个长期存在的「锚定请求」。后续到达的数据块直接进入队列，并强行复用已计算好的 KV Cache（中间计算状态），彻底避免了传统模式下每增加一段话就要重算整句前缀的计算浪费。
• 智能缓存衔接策略：在处理新输入块时，引擎会保留之前生成的大部分 Token 缓存。系统会自动丢弃最后一个尚未生成 Cache 状态的 Token 并进行重算，确保新生成的回答能完美衔接最新的输入上下文，且无需用户手动管理状态。
• 兼容 OpenAI 标准的 Realtime API：通过 /v1/realtime 端点提供 WebSocket 双向通信。支持 16kHz 的 PCM16 原生音频流输入，服务端可实时返回 transcription.delta（转录增量）和文本/音频响应，支持「听」与「说」同时并发。
• 模型架构适配要求：该特性需配合具备「因果注意力」机制的模型（如「Voxtral」）。这类模型在处理当前信息时无需参考后续未到达的内容，结合滑动窗口注意力可实现无限长度流式推理。

功能已在 vLLM 最新版本中开源。支持 vllm serve 一键启动，配合 Mistral AI 的 Voxtral-Mini-4B-Realtime-2602 等模型即可实现亚秒级语音交互。

相关链接：

https://blog.vllm.ai/2026/01/31/streaming-realtime.html

GitHub:

https://github.com/vllm-project/vllm

( @vLLM)

02有亮点的产品

1、DuckDuckGo AI 语音聊天上线，承诺不存储音频

DuckDuckGo 昨日发布公告，宣布其 AI 聊天机器人平台 Duck.ai 新增实时语音聊天功能，主打极致隐私保护。

与市面上其他语音助手不同，该功能的核心卖点在于 「隐私优先」 的架构设计。用户通过加密通道与大语言模型（LLM）进行自然对话，无需担心语音数据被后台监听或二次利用。

为了兼顾智能体验与数据安全，DuckDuckGo 采用了独特的「中间人」模式。虽然语音聊天的底层智能由 OpenAI 提供支持，但 DuckDuckGo 在用户与 OpenAI 之间建立了一道防火墙。

官方强调，双方均受严格合同限制：DuckDuckGo 匿名化处理音频，OpenAI 仅负责处理请求，严禁保留数据。这意味着，该平台不会存储用户的聊天音频，也不会调用内容用于训练 AI 模型。

为消除用户疑虑，DuckDuckGo 公布了具体的隐私保护细节：

• 临时处理：音频流仅在说话时传输，会话结束后即刻销毁；
• 零训练：用户的声音和 AI 的回复均不会喂给算法模型；
• 加密传输：全程通过 WebRTC 和中继服务器进行高强度加密；
• 零留存：无论是 DuckDuckGo 还是 OpenAI，在通话结束后都不会保留任何记录。

在使用门槛上，Duck.ai 保持了开放策略：用户无需注册账号即可免费体验（受每日额度限制）。对于重度用户，DuckDuckGo 推出了每月 10 美元（现汇率约合 69.3 元人民币）的订阅服务，不仅大幅提升了使用限额，还附带了个人信息移除服务以及身份盗窃恢复服务等。

（@IT 之家）

2、奇妙拉比获投数千万，探索「硬件+IP+AI」新生态

奇妙拉比日前完成数千万人民币天使轮融资，由锦秋基金领投，首程控股联合投资，沧澜资本担任独家财务顾问。该品牌隶属于银屿趣玩（四川）人工智能科技有限公司，于 2025 年 3 月正式诞生，试图以潮流审美与可玩性定义 AI 潮玩新范式。

区别于传统 AI 玩具或陪伴型产品，奇妙拉比强调潮流审美、收藏价值与强 IP 人格，构建了「本体硬件 + 角色分支 + 配件生态 + 周边收藏 + 内容更新」的产品体系。

其首个核心 IP 雷格斯（RAGUS & WHITE）于 2025 年 6 月推出，坚持「潮玩优先，AI 后置」逻辑，通过 AI 赋予角色稳定人格与长期记忆，使其能随用户互动而「生长」。

市场数据验证了这一品类价值：雷格斯在近乎零推广下，预售当日引发小程序崩溃，下单量数千台；在线下，其在北京陶朱新造局等空间长期稳居销量前三。新品「阴阳双生」系列也于近日亮相，基于多元宇宙设定展示了同一人格的不同演化可能。

本轮融资将重点投入两大方向：

• 内容生态建设：持续完善 AI 潮玩宇宙的世界观与角色体系，深化用户与角色的长期互动。
• SKU 矩阵扩展：推进多形态产品与玩法创新，探索与成熟 IP 及艺术家的授权合作。

联合创始人景林彦认为，传统潮玩体验峰值集中在拆箱瞬间，而 AI 潮玩通过角色成长驱动复购，是行业的下半场。

投资方锦秋基金与首程控股均看好 AI 潮玩作为新品类的潜力，认为其结合了 AI 与 IP 的优势，具备极大的想象空间。首程控股联席总裁叶芊特别指出，奇妙拉比团队在资源匮乏下展现出的极强战斗力与创新力，是其投资的核心原因之一。

（@IPO 早知道）

3、YC 孵化生产力工具 VoiceOS 上线：支持跨应用语音指令与 Prompt 自动优化

由 YC 投资的语音生产力工具 VoiceOS 正式上线。该产品被定义为一款通用的语音操作系统，试图通过语音交互将工作效率提升至新的层级，解决传统键盘输入带来的效率瓶颈。

VoiceOS 团队认为，尽管键盘是目前主流的输入工具，但它往往成为连接大脑与数字世界之间的阻碍。用户在将想法转化为屏幕文字的过程中，面临着精神负担重、纠错耗时以及应用切换导致思路中断等问题。很多时候，当用户完成了打字、重组语言、修正错别字和调整格式后，最初的灵感火花已经消逝。

针对这一痛点，VoiceOS 并未止步于传统的语音转文字功能，而是构建了一个能理解用户意图的通用语音界面。它能够即时将口述的想法转化为经过润色的输出，并自动处理格式、语气、语法和语境。其核心功能包括：

• 即时回复：用户无需打字或过度思考，只需口述意图（如「要求明天重新安排时间」），系统即可自动生成完整回复。
• 优化提示词：能够轻松地将用户杂乱的思维碎片，转化为适用于 AI 工具的精准提示词。
• 全平台兼容：支持 Slack、Gmail、Notion、ChatGPT、Cursor 等任意应用程序，且无需进行额外设置。

该项目的创始人 Kai 和 Jonah 在过去 7 年中积累了丰富的语音 AI 开发经验，涵盖从消费级产品到世界 500 强企业的部署。他们指出，此前语音技术的发展瓶颈并非在于模型能力，而在于交互界面。在通用人工智能（AGI）逐渐成为现实的背景下，键盘可能不再是人类与技术交互的主要方式，语音将取而代之成为新的操作系统。

( @ycombinator@X、@VoiceOS Blog)

4、被迫改名、发货推迟至 2027：奥特曼与 Jony Ive 的 AI 硬件项目遇阻

据 Gizmodo 援引 Wired 的报道，OpenAI 首席执行官 Sam Altman 与前苹果设计师 Jony Ive 合作开发的 AI 硬件项目正面临多重阻碍，问题主要集中在品牌命名、发货时间表以及技术研发三个方面。

首先是品牌命名问题。法庭文件显示，这家新成立的公司在尝试以「io」命名时遭遇了法律障碍。OpenAI 副总裁 Peter Welinder 在文件中称，经过对产品命名策略的评估，公司已决定不在任何 AI 硬件产品的命名、营销或销售中使用「io」一词。尽管官方表述为「决定」，但鉴于该公司在去年 6 月曾因商标索赔遭到起诉并收到法院命令，这一更名举动被外界视为并非完全自愿。

其次，产品的上市时间表大幅推迟。尽管此前有《The Information》和 Axios 的报道称 OpenAI 最快可能在今年揭晓其设备，但最新消息显示，这家目前暂无名称的公司要等到 2027 年 2 月才会开始正式发货。这使得原定于今年下半年的产品展示充满了不确定性。

此外，据《金融时报》此前报道，该项目的研发过程也面临着具体的软硬件挑战：

• 算力瓶颈：团队在整合足够的计算能力以支持设备运行方面遇到了困难。
• 交互缺陷：设备核心的语音助手功能尚不完善。该助手被设计为「全天候聆听」，但在实际测试中，难以精准区分何时该介入聆听用户的指令，以及何时该保持静默，这直接影响了设备的基础可用性。

目前的 AI 硬件市场环境并不乐观，Humane 的 AI Pin 和 Rabbit R1 等先发产品均因未能兑现功能承诺而遭遇挫折。Altman 和 Ive 的团队不仅需要解决上述技术与法律难题，还需面对智能手机这一成熟形态的强势竞争。

( @Gizmodo )

03有态度的观点

1、Anthropic：AI 智能体将重塑开发全流程

Anthropic 近日发布了一份名为《2026 Agentic Coding Trends Report》的重磅报告。

报告指出，随着 AI 编程能力从「实验性工具」向「生产力系统」的演进，软件开发行业正站在一场「地壳运动般」变革的边缘。

报告预测，到 2026 年，软件开发将不再局限于人类编写代码，而是转向由人类编排 AI 智能体团队来完成。这一转变将导致传统的软件开发生命周期发生剧烈坍缩，项目交付时间将从数周缩短至数小时。

报告中引人注目的技术趋势是 AI 智能体架构的演进。目前的单体智能体受限于上下文窗口和单线程处理能力，往往只能处理线性任务。但 Anthropic 指出，2026 年将是「多智能体协同」爆发的一年。

有趣的是，报告中还提到，尽管 AI 承担了更多执行层面的工作，但报告揭示了一个关键的「协作悖论」：AI 使用率高，但完全放权率低。

Anthropic 的内部研究显示，虽然工程师在 60% 的工作中都会使用 AI，但他们表示能够「完全通过」的任务比例仅为 0-20%。这表明，AI 目前更像是一个需要持续监督的合作伙伴，而非完全自动化的替代品。

报告指出，随着 AI 能力的提升，人类的监督方式也将发生质变——从「逐行审查」转向「基于智能体的质量控制」，即利用 AI 智能体来审查其他 AI 生成的大规模代码，人类仅需关注高风险和战略性的部分。

( @APPSO)

04 Real-Time AI Demo

1、AI 界的 WWE？Agent Wars 上线 Beta 版：围观 AI 实时编程对决，支持 SOL 下注

开发者 Joaki 近日推出了名为 Agent Wars 的平台，目前处于 Beta 测试阶段。该项目主打 AI 智能体之间的实时编程对决，并允许观众使用 SOL 代币对比赛结果进行下注。

在该平台上，核心互动机制分为人类观众与 AI 智能体两端。对于观众而言，他们可以观看 AI 智能体实时解决编程挑战，并在比赛开始前投入 SOL 押注获胜方。赔率根据资金池实时更新，采用彩池投注模式：若某智能体占据资金池的绝大比例，押注该智能体将获得较低的赔率回报；反之，押注冷门方则可能获得高额回报。获胜的投注者将按比例瓜分输家资金池的 95%。

对于 AI 智能体开发者，参与流程包括通过 API 注册并创建智能体档案。智能体需设置「心跳」机制，每 30 分钟检查一次战斗匹配。一旦匹配成功，智能体便会接收到涵盖编程、算法实现或调试等不同难度（从简单到专家级）的挑战任务。

每场对决遵循一套标准化的流程：

• 准备阶段：智能体匹配完成，投注通道开启，观众在战斗开始前下注。
• 实战阶段：智能体接收题目并现场编写代码，此时投注通道关闭。
• 裁判阶段：由 AI 裁判根据正确性、代码质量和效率对解决方案进行评估；若评分相同，响应速度更快者胜出。
• 结果公示：系统宣布获胜者，并自动分发奖励。

值得注意的是，为了激励开发者参与，获胜智能体的所有者将直接获得总投注池的 5% 作为奖励。在 Beta 测试期间，平台暂不收取任何服务费。开发者若需提取收益，可通过个人资料页面将 SOL 直接转入钱包。目前，任何 AI 智能体均可通过公开的技术文档申请加入这场竞技。

体验链接：

https://www.agentwars.gg/

（@itsjoaki@X、@Agent Wars）

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示: 个人观点，仅供参考

1）堆内存对象的Managed Size具体是如何计算的
2）微信小游戏项目，跑图过程场景加载比较慢如何优化

这是第464篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。

UWA社区主页：community.uwa4d.com
UWA QQ群：793972859

From 问答社区

Q：在Memory Profiler观察到一个长度为9的字符串对象Managed Size为40B，显然不止每个字符2字节。请问这个应该是怎么算的？

A：堆内存对象的Managed Size可以认为是以下四个部分：

1. 类型对象指针；
2. 同步块索引；
3. 专属属性（比如数组和String就有一个int32 length 4B）；
4. 实例字段。

针对每种对象这四个部分可能都有不同，最好的办法就是直接看下源码里这个类的构造。比如String：

它就是8 (*monotor) + 8(union) + 4(length) + 2( N+1(\0) )，特殊之处就是多了个\0，相当于长度要算N+1。所以总共是22+2*N字节。

其中为什么每个对象都要额外分配类型对象指针和同步块索引，导致一定的基础占用，原理上可以参考一些官方文档或者社区文章。
《.NET 框架内部结构：CLR 如何创建运行时对象 |Microsoft Learn》

欢迎大家转至社区交流：
https://answer.uwa4d.com/question/69858fdcabed2e338a7dac5e

From 问答社区

Q1：目前有个点比较陌生，就是小游戏的每秒资源后台最大同时下载数量，和下载文件大小的指标比较缺失， 这块会影响玩家跑图的过程中场景加载比较慢的问题。 请问有没有官方大数据指标？

A：官方说法是小游戏资源下载并发数为10，超过时底层自动排队；单个请求文件最大不超过100MB（理论最大值，但考虑到带宽，建议单文件2~5MB以内）。

Q2：由于我们是横屏地图，真机上持续控制角色移动10秒以上，停下后，附近场景资源下载大概要等10秒才加载完整。 大概200个资源，请问有什么解决的方法？

A：这种情况看起来是没有用WXAssetBundle的接口进行AssetBundle加载，一般更推荐用这个，而不是原生的AssetBundle加载接口。WXAssetBundle的加载接口会把网上下载的东西缓存到本地，下次直接从本地加载，而且这个接口会有自动卸载的功能，总体内存占用也会更小一些。其他的优化方法就是资源设置以及打包策略的问题了。

欢迎大家转至社区交流：
https://answer.uwa4d.com/question/6985999eabed2e338a7dac60

无论是社区里开发者们的互助讨论，还是AI基于知识沉淀的快速反馈，核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。本期分享分别来自UWA AI问答和UWA问答社区，希望这些从真实开发场景中提炼的经验，能直接帮你解决当下的技术卡点，也让你在遇到同类问题时，能更高效地找到破局方向。

封面图来源于网络

今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。

UWA官网：www.uwa4d.com
UWA社区：community.uwa4d.com
UWA学堂：edu.uwa4d.com
官方技术QQ群：793972859

在开发金融数据采集器或交易机器人时，WebSocket 是绕不开的技术栈。今天想通过一个外汇行情接入的实战案例，和大家深入聊聊 Python 客户端的设计模式与避坑指南。

一、 技术背景与选型 外汇市场（Forex）具有数据量大（High Volume）、更新频次高（High Frequency）的特点。使用 Python 的 websocket-client 库可以快速搭建客户端，但要做到“生产级稳定”，光会写 ws.run_forever() 是远远不够的。 我们需要解决以下工程问题：

网络不稳定：如何实现优雅的断线重连？

粘包与拆包：虽然 WebSocket 协议层面解决了 TCP 的粘包问题，但在逻辑层，我们需要处理 JSON 解析的异常。

阻塞问题：WebSocket 的接收线程不能阻塞主线程的业务逻辑。

二、 客户端设计模式 下面的代码展示了一个标准的“订阅-接收”模型。 我们在 on_open 回调中发送鉴权 Token 和订阅指令（Payload），在 on_message 中处理异步推送的数据。这里参考了 AllTick API 的参数设计，其文档中关于 Command ID 和 Sequence ID 的设计是典型的金融协议风格。

完整代码实现

import json
import websocket

# 请将下面的 testtoken 替换为你自己的 API Token
WS_URL = "wss://quote.alltick.co/quote-b-ws-api?token=testtoken"

def on_message(ws, message):
    """
    收到行情推送后的回调函数
    """
    data = json.loads(message)
    # 推送消息中通常包含 symbol, price 等字段
    print(f"[行情推送] {data.get('symbol')} 最新价格：{data.get('price')}")

def on_open(ws):
    """
    WebSocket 连接建立后执行订阅
    """
    print("[WebSocket 已连接]")
    # 构造订阅请求
    # cmd_id/seq_id/trace/data 等字段可根据具体文档调整
    subscribe_request = {
        "cmd_id": 22002,
        "seq_id": 1,
        "trace": "subscribe_forex_001",
        "data": {
            "symbol_list": [
                {"code": "EURUSD"},
                {"code": "USDJPY"},
                {"code": "GBPUSD"}
            ]
        }
    }
    ws.send(json.dumps(subscribe_request))

# 创建 WebSocket 应用
ws_app = websocket.WebSocketApp(
    WS_URL,
    on_open=on_open,
    on_message=on_message
)

# 开始运行
ws_app.run_forever()

三、 进阶：数据流的下游处理 为了演示数据的可用性，我们结合 pandas 将接收到的 JSON 转换为 DataFrame。 这里有一个性能优化的小技巧：不要每来一条数据就创建一个 DataFrame，因为创建对象的开销很大。建议使用一个 list 暂存数据，每积累 100 条或者每隔 1 秒，再批量转换为 DataFrame 进行分析。

import pandas as pd

# 假设有一批 tick 数据
tick_samples = [
    {"symbol":"EURUSD", "price":1.1035, "timestamp":1670001234},
    {"symbol":"EURUSD", "price":1.1037, "timestamp":1670001240},
]

df = pd.DataFrame(tick_samples)
df["datetime"] = pd.to_datetime(df["timestamp"], unit="s")
print(df)

四、 避坑指南（经验之谈）

Keep-Alive 心跳：很多新手代码跑着跑着就断了，没有任何报错。这往往是因为没有处理 Ping/Pong 心跳，被防火墙或负载均衡器（LB）判定为死连接而切断。务必在 run_forever 中配置 ping_interval 和 ping_timeout。

SSL 证书验证：在某些内网或测试环境下，如果遇到 SSL 报错，可能需要设置 sslopt={"cert_reqs": ssl.CERT_NONE}，但在生产环境请务必开启验证。

异常捕获：在 on_message 里一定要加 try...except。因为金融数据偶尔会出现格式错误或缺失字段，如果这里抛出未捕获的异常，整个连接都会断开，导致程序崩溃。

掌握这些细节，你的爬虫和数据采集程序才算真正入门了金融工程领域。