Poliy

有一位博导朋友，作为遥感领域某顶会主编，在冰岛举办该学术会议。我虽然目前研究方向与多模态地理信息不怎么相关，但毕竟接触过3、4个这方面的课题，因此对「Multimodal GeoAI for Urban Understanding」方向产生了一些想法，并在做关于「UrbanGeoMind」框架的初步设计……four page的limit可能让这个框架等陈述和证明会更加严谨吧…… 重新回忆并整理了日常导航软件的核心算法，想到可能大多数人对GeoAI的商业化叙事大多停留在自动驾驶。 嗯……期待能🈶不错的研究进展吧。

「知识驯化」和「行为驯化」，哪条路线，离真正的AGI更近，更快？欢迎交流。

信息来源：「金潮洞察」。 我梳理了一下OpenAI对外PR的硬件团队搭建体系，然后试图反推了OpenAI对「除手机形态外」的下一个入口级产品的可能定义。 两个与现有的大多数AI智能硬件的解决路径不一样的点： （1）一定要从系统底层和工程算法切入，更多的产品还是在顺着自己的工作流直觉来； （2）自然语言交互后，不一定通过CLI的形式来呈现，是一套自上而下遵守的逻辑。 关于「服务件」的相关结论、可落地思路与可行方案，我近几日发在Bonjour社区里，得到了一些AI Native、Agentics System等领域的伙伴的关心与探讨，后续会整理一些技术性的落地步骤。 一个暴论，OpenAI会把AI硬件的研发规范化，这里指的是后续所有Agent-Hardware User对产品约束性的定义。 简单来说就是，如果OpenAI的硬件研发体系做的非常成熟，那么以后，这只会成为一种非功能性需求。 所有的硬件开发都像App开发。 然后对供应链和外设把控到极致的团队才会长成所谓的「AI硬件大厂」 因为OpenAI这样严格要求了自己的产品形态，从底层到模型的「外界感知」，先弱化最不影响面向市场的「交互形态」，把安全放在高位。 至于交互形态，无论是戒指💍，还是眼镜👓，亦或者是某个可以抱着的娃娃，某个耳机（这个我个人判断比较大可能会是这个形态），都不影响最终的交付。 很赞同的一点是，OpenAI对底层OS的改写渴望到了几点，如果可以，他们情愿搓出一个全新的以Linux为内核，独立于Android、iQS、Harmony之外的操作系统。 （下文观点来自「金潮洞察」） 一、收购背景与产品形态 OpenAI 做硬件源于去年的一次收购。2025 年 5 月 21 日，OpenAI 宣布以约 65 亿美元股票价格收购硬件初创公司 Product；“这是立规笔”。该团队大约 55 人。收购之后，由他本人及支持团队负责 OpenAI 的创意和设计工作。在 OpenAI 内部，这个团队叫作 Consumer Device（消费设备）。 公开说法称 OpenAI 硬件可能“够年推出”。官方对产品形态的描述是：不显眼、便携、能全面感知周边环境和用户行为，并且明确表示不会取代手机。 在过去四个月里，OpenAI 硬件业务线放出了不同岗位。按技术栈把这些招聘岗位拆成五层，每一层对应这款设备的一类能力。 二、招聘岗位的五层拆解 第一层：算力和操作系统 核心岗位是实时操作系统方向的固件工程师，要求十年以上嵌入式系统量产经验，负责从底层板卡点亮一直做到量产。职责里写明要处理内存、功耗、延迟这三重约束。还有一个岗位是系统电源工程师，做嵌入式硬件的功耗测量和优化。这类岗位在手机和可穿戴设备的研发团队里是标配。 从招聘岗位的信息描述分析，操作系统的研发被拆成三个方向： 1. Linux 方向：所招聘的 Linux 内核方向操作系统工程师，要求候选人有内核子系统的深度经验，具备把内核改动带到用户空间层面的实际项目能力。 2. 端侧推理方向：这部分操作系统工程师的职责是和研究员配合，做量化处理、运行时集成、内存优化，让模型满足内存、算力、能耗的资源限制，并且要在延迟、内存、电池和散热四重约束条件下保持响应。 3. 连接与网络方向：这部分操作系统工程师做的是 Wi-Fi 和蓝牙框架、IP 网络连接管理和路由的落地工作。 整个系统层有负责整体把控的操作系统工程师，还有区分内核、端侧推理和连接三个方向的专职岗位，说明操作系统层是按三个专业方向来划分的。专门招一位 Linux 内核工程师和一位端侧推理工程师，就意味着这台设备一定在端侧做了很重的运算。这个场景已经远远超出把语音传到云端、再把语音处理结果拿回来的过程。 另外一个值得注意的是，固件岗位里分别写着“综合 Linux 内核”岗位的要求。推测下来，最底层的芯片架构大概是：一颗跑 Linux 的主芯片，专门负责算力处理；再配一颗跑实时操作系统的低功耗协处理器，负责常驻待机和低功耗唤醒。 这一层还有一个业务方向上的信号：一个招聘岗位叫安卓系统工程师，但这份岗位描述的开头写的是“我们在探索 AI 如何深度融入人们已经在用的设备，理解上下文，帮助用户完成任务，跨应用和服务做协同”。后面强调，这不是一个只做应用的安卓岗位，要用到系统级接口、设备能力、平台集成以及 OEM 特定功能。既然明确写了要融入其他设备，那么推测下来，OpenAI 希望获取到的是用户正在使用的设备的环境以及运行信息；或许这里还会有更深一步的合作，可能是把自己的 AI 能力完全嵌入到别人的设备里。 所以，对算力和操作系统这一层的判断是：OpenAI 从最底层的芯片架构开始定义，具备在本地运行 AI 模型的嵌入式软件能力；操作系统是 Linux 和实时操作系统并存的多层结构；算力、推理、连接这三件事各自有了专门的岗位；业务方向上，可能会存在“自己的设备”和“内嵌别人的设备”这两条路并行的局面。 第二层：感知 这一层对应这台设备如何识别周边环境。相机软件工程师的岗位描述里写着：在消费级硬件产品中，摄像头技术栈是一个关键的感知部件。这个岗位要从原型阶段做到量产，负责摄像模组的点亮、传感器驱动、供电、复位和时钟时序。但目前 OpenAI 的采购团队中一直没有看到负责摄像头模组的采购岗位，所以摄像头大概率用的是成熟供应链上的标准件。 这一层信息量最大的是多模态感知与身份验证方向的机器学习工程师：需要研究跨视觉、音频和其他传感器信号的多模态感知与身份验证方法，并在实时系统里做集成。核心能力验证岗位名称里的两个词值得重点品味：“多模态感知”和“身份验证”。多模态感知意味着用户需要同时使用到摄像头、麦克风和其他传感器；身份验证原文用的是 authentication，就意味着这台设备要认出是谁在用它。这可能会是一个多人共用的设备，也可能需要做本地认证的权限判断，家庭和随身携带的场景都符合以上判断。 这个岗位挂在“未来计算研究”这个团队下面，研究 AI 系统怎么感知人和环境，再把研究成果变成未来产品的能力。岗位描述里有一句特别说明：重点是做出能在非受控环境下工作的系统。也就是说，这台设备要工作的场景不是实验室里那种受控条件，而是用户真实的家庭、身上和路上。 未来计算研究这个团队还有一个岗位叫多模态智能体方向的研究科学家，做的是长期记忆、用户建模和个性化系统，研究的是能随着时间进行学习、适应单个用户、融入日常生活节奏的 AI 系统。所以推测下来，这个产品形态应该是一个可以伴随用户长时间生活的硬件产品。 深入解读这些岗位背后的含义：这款硬件设备需要把摄像头、麦克风和其他传感器融合成统一的感知输入，并且在设备本地通过摄像头做身份识别；它要工作的场景是真实的非受控的日常环境。而研究这一侧除了多模态感知，还在做能长期记住单个用户、适应用户生活节奏的 AI 系统。说白了，这个设备要更多适应用户所在的周边环境，把环境信息作为重要的输入，而不是等着用户主动激活设备后再使用。这是一个重要的交互方式的变化。 第三层：连接 最标准的岗位是连接软件工程师，职责列得很细：蓝牙、低功耗蓝牙和 Wi-Fi 的功能，内核驱动层和系统服务层两边都要做；配对、绑定和配网流程涉及 LE Audio 和 LC3；优化吞吐、延迟、抖动；蓝牙和 Wi-Fi 的共存以及功耗模式。LE Audio 和 LC3 是新一代蓝牙音频标准，主要用在无线耳机和助听设备上。一个岗位描述里写到这个颗粒度，说明音频传输在产品的优先级里排得非常靠前。除了协议层，还有一个连接与网络方向的操作系统工程师，明显是要把连接缩进操作系统这一层。最能说明硬件场景的是下面这个招聘岗位：电磁波吸收比方向的无线法规工程师。电磁波吸收比也就是 SAR，是无线设备射频能量相关的指标，这是各国监管机构对贴近人体使用的无线设备的强制认证项。如果研发的是一台放在桌子上的设备，通常不需要专门招一个人做这件事；但如果是一台挂在耳朵上、别在衣领上或者握在手里的设备，必须要过这一项认证。另外，这个岗位还暴露了一个研发进展：岗位职责包括制定和执行射频暴露的测试策略，协调外部实验室做测试和全球监管认证。一台设备要送去做射频认证，形态必须先定下来。所以这个岗位存在，说明产品形态已经收敛到可以送检的程度。 第四层：隐私和安全 这一层的岗位特点是覆盖非常完整，从芯片级的安全底座一直到运营侧的安全模型，说明安全是这个产品最底层的核心功能。在模型层，有一个私有计算软件工程师的岗位，团队使命显得很直接：提供世界级的安全功能，让用户的私密数据保持绝对私密，连 OpenAI 自己都看不到。用的技术是机密计算、可信执行环境和端到端加密，而且要实现在 ChatGPT 上实现跨多端的功能交付。 下面几个岗位直接补齐了底层安全能力： ·操作系统软件安全架构师：职责是定义下一代操作系统的安全架构、信任边界和特权模型。 ·硬件安全模块基础设施的安全工程师：做的是硬件支撑的安全底座，包括可执行环境、安全元件、硬件信任根，以及密钥签发和证书签发的策略边界。 ·消费设备安全与风险运营专员，以及消费设备安全运营高级项目经理：做的是为一个全新的消费硬件设备搭建安全运营模型的工作。 除了这些安全架构和实施岗位，还有一句话需要隔离敏感的上下文、建立护栏，让 AI 应用和智能体在安全、私密并且受控的环境下进行行动。“智能体”和“受用户控制”放在一起，说明这台设备上跑的不只是问答产品，还有能替用户干活的 agent 产品。想要让 agent 跑起来完成长程任务，就意味着它能够接触到用户的数据，所以安全架构必须成为产品定义的一部分。 在这一层可以判断的是：可信执行环境、硬件信任根和端到端加密，在硬件产品的架构定义阶段就已经给了足够的重视。 第五层：量产和运营 这一层直接负责产品从工程样机走到批量交付的完整过程。所以招聘的岗位和放出的时间也最能直接体现出这款硬件目前的业务进展。这里有五个信号，每一个都能直接定位到一个具体环节。 第一个信号：两个岗位“ASE”（原文如此）在新加坡，分别是硬件探索和运营探索，都属于 Consumer Device。岗位名称用“探索”这种写法，估计是为了在招聘页面上不暴露产品的具体形态，但岗位描述写得很具体。硬件探索的岗位工作内容跨越产品设计、原型、机械验证和电子系统验证，从早期开发一直到量产阶段，要求六年以上消费硬件工作经验，并且至少把一个消费产品从概念做到量产。运营探索的岗位需要负责把早期产品从概念变成可制造的量产方案，管理过供货计划、供应商关系以及供应、成本、进度的对齐。把硬件工程和量产运营两个职位同时放在新加坡，所以结论是：新加坡是 OpenAI 硬件（制造/运营）的重要节点。 第二个信号：来自产品生命周期管理与工程应用资深工程师。这个岗位暴露了一个叫“硬件工程体验”的新团队。岗位的具体工作是部署西门子的 NX 和 Teamcenter。NX 是工业和机械设计软件，Teamcenter 是产品生命周期管理系统。这套系统管的是设计数据、物料清单、工程变更和版本，解决的是连续迭代硬件产品时的协同和追溯问题。所以大概率现在已经开始为下一代产品的迭代做准备了。 第三个信号：来自系统集成和验证。有两个岗位：系统集成经理和系统集成方向的实验室运营经理。系统集成团队的职责写的是搭建让设备软件运行可靠、可测试、可发布的工具和验证系统，包括构建系统、持续集成流水线、自动化测试框架。实验室运营这个岗位要管的是消费设备实验室的日常运设备队列、测试工装、库存维护和物流。另外，有关集成和验证方面还有几个岗位：端到端验证方向的系统测试工程师，做的是跨越硬件、软件、连接、云服务和配件的端到端测试，把真实的使用场景变成可复现的测试流程；另一个岗位是系统集成方向的系统与集成工程师，负责基于 Bazel 和 Yacd（原文音译）的构建与测试流程。几个岗位合在一起，就是要把硬件产品从样机做到量产。 第四个信号：硬件与消费设备方向的数据工程师。职责是打通设备全生命周期的数据，把制造系统、工厂运行、设备

当AI在物理世界长出了“脊髓”： 聊聊RPEE-Spinal这个反共识的思路 最近在研究一个挺有意思的想法， 叫RPEE-Spinal （Recursive Precision Execution Engine via Spinal Architecture），直译是“基于脊髓架构的递归精度执行引擎”。名字有点绕，但核心隐喻特别直觉——人的脊髓反射弧。 一个场景先感受一下 你伸手去接一个飞过来的球。整个过程里，你的大脑其实根本没有“计算”出最佳接球轨迹——它只给了一个模糊的目标（“接住”）。真正完成实时修正、协调几十块肌肉、在毫秒级内不断纠错的，是脊髓层面的反射弧：感受器和效应器之间高速闭环，给出的每一拍指令都近乎最优。 现在的问题来了：大语言模型当“大脑”已经够强了，但它派发下来的指令到了物理实体（机械臂、无人机、机器人）这一层，靠谁来执行？让一个概率采样器去控制伺服电机，就像让哲学家去弹钢琴——思想很深刻，手指不听使唤。 RPEE-Spinal想干的就是这根“脊髓”。 它的核心主张：从“概率模仿”到“优化求解” 这是整个思路里最颠覆的一点： LLM 的本质是词序列概率分布上的采样器，输出是“看起来对”的序列，最优性无法保证，也没有对物理动力学（sₜ₊₁ = f(sₜ, aₜ)）的内嵌理解。 RPEE-Spinal的本质是一个分层递归优化器。它把指令生成建模成一个带约束的数值优化问题：在毫秒级时间内求解，输出满足物理约束集内的数学最优解。 形式上大概长这样： 每层求解 min Lₖ(Tₖ, aₖ, sₖ)，约束gₖ≤0 反射修正： aₙₑ𝓌 = a + J⁻¹(sₙₑ𝓌 − sₚᵣₑd)，雅可比矩阵预算缓存，O(1) 更新 关键区别在于“幻觉”的定义——在优化框架里，只要物理约束集是闭凸集、任务损失强凸，输出违反物理约束的概率就是 0。不是靠更多数据去“减少”幻觉，而是理论上不存在幻觉。 有人打了个比方：这套东西之于神经网络，相当于牛顿第二定律之于力学——确定、普适、每个决策都能用 KKT 条件解释。为什么叫“递归”和“分层”？借了一个很妙的物理类比：微分摆线/折射率。 任务从高层往下分解时，像光穿过不同折射率的介质——每层有一个折射率nₖ≥1+ε，保证信息可逆放大；理论上的最优解是等折射率分配。层数越多，每个子问题的搜索空间维度越低、条件数越好，收敛越快。 数学上有个漂亮的结果： 达到精度ε只需要O(log(1/ε)) 层， 而传统神经网络需要O(1/εᵈ) 的参数量。 这意味着一件事：准确率随算力单调收敛到理论极限。算力给够，精度封顶。这和Transformer即使无限算力也受模型偏差天花板限制，是根本性的区别。 其实它甚至不想跑在CUDA上。 更大胆的部分来了：既然计算语义从“执行固定计算图”变成了“在线求解优化问题”，那硬件也该变。设想中的专用单元包括： ①CSU（约束求解单元） 专用求解 QP/SDP ②RRU（实时反射单元） 亚毫秒级闭环控制 ③LIE（标签注入引擎） 动态添加约束标签 这相当于在说AlexNet当年证明了GPU 这条路可行，现在需要证明优化驱动架构本质上超越 CUDA。 在设计的验证实验中，如果理论成立，应该看到：凸QP最优性差距<10⁻⁶、机械臂1000条轨迹 0 次约束违反、无人机避障成功率 100%、多模态一致性99.7%。注意这些是理论预测或者仿真目标，不是已跑出来的实测——这一点必须诚实说清楚。 我的几点思考 1. “大脑-脊髓”分工让具身智能的架构分层一下子清晰了：LLM负责想，RPEE-Spinal负责动，各干各擅长的事。 2. 无幻觉定理的前提很重——闭凸约束集+强凸损失，真实物理世界的约束是否都能这样刻画，是最大问号。 3. 专用硬件是鸡生蛋问题。没有CSU/RRU，毫秒级QP求解在端侧能不能成立，直接决定整个故事是工程还是论文。 总之，不管最终落地多少，这个"给 AI 装脊髓"的方向值得持续关注。范式级别的想法，哪怕只对一半，也足够改写具身智能的技术路线图了。 大家对"优化驱动 vs 生成驱动"怎么看？欢迎评论区拍砖 🧱