1. 具身智能的“大脑”困局为什么一个大模型远远不够我们总说“大模型是机器人的大脑”但这句口号在实际部署时往往演变成一场灾难。你给了机器人一个高端的人形本体接入了开源或商用大模型结果它把“把杯子放在托盘上”理解成一次毫无控制的猛砸。命令执行了“理解”也完成了但物理世界里的结果完全不可用。这不是模型不够聪明而是我们忽略了一个关键事实具身智能真正需要的不只是 LLM、VLA、SLIM 这类“会思考的软件”更需要一套能扛住实时交互的物理感知底座。我从 2023 年入坑具身智能方向最初做的是纯大模型方案对话、规划、调 API。但当我把同样的架构搬到一台真实的机械臂身上时问题立刻暴露。语言模型天然存在延迟波动、幻觉输出和空间尺度失真它根本不知道自己的回答会被真实电机执行。后来我逐渐意识到一套稳定运行的具身智能系统本质上应该是一个分层架构感知层负责实时建立对世界的观测规划层负责生成任务意图控制层负责把意图转换成电机指令。而 LLM、VLA、SLIM 等模型只是这个架构里的“执行模块”最底层的实时音视频感知底座才是整个系统能否在物理世界里活下来的关键。这篇文章想把这条技术路线的底层逻辑拆开为什么我们绕不开实时感知底座LLM、VLA、LLA、SLIM 分别扮演什么角色它们之间是替代关系还是协作关系以及最重要的当你落地一个具身智能项目时最先应该动手做的是哪一部分。我会结合自己的实操记录、踩坑经历和对行业开源方案的观察尽量把每一层关系讲清楚希望给正在规划同类项目的人一点参考。1.1 一次“成功”的失败纯语言模型控制机械臂先说一个让我印象很深的测试。2024 年初我尝试用一套纯 LLM 方案驱动一台桌面级六轴机械臂完成“递螺丝”任务。流程很简单机器人通过语音接口接收指令用大模型分解步骤然后通过运动规划库执行轨迹。听起来没什么问题但真正跑起来之后问题出现在两个地方。第一个问题是时延。当用户说“拿左边第三颗螺丝”语音识别耗掉 300ms大模型推理耗掉 1 到 2 秒运动规划库再计算逆解总延迟接近 3 秒。这在“递螺丝”这种慢速任务里勉强能忍但一旦换成需要实时避障的动态场景机械臂的轨迹早就过时了。第二个问题是尺度失真。语言模型无法精确感知真实空间尺度“左边第三颗螺丝”这个描述在大模型的理解里没有任何几何意义。于是它只能输出一个粗糙的动作序列剩下的依赖视觉系统临时矫正而视觉系统返回的深度图像又需要额外的 200ms 处理时间整个系统就陷入了一种“规划—矫正—再规划”的恶性循环。这个项目最终被我判定为“技术上成功、工程上不可用”。因为规划链路里任何一环的误差都被运动控制系统如实放大了。1.2 分层架构才是真正的解药那次失败之后我开始放弃“一个大模型包打天下”的思路转向分层架构。简单来说就是让不同模型的定位变得清晰LLM负责语义理解、任务分解、多轮交互输出的是抽象任务序列例如“拿起螺丝—放到夹爪—靠近安装孔—松手”。VLAVision-Language-Action负责把当前视觉观测和语言指令联合编码直接输出机器人动作或动作参数替代传统的“感知规划控制”串联管线。LLALanguage-Latent-Action 或 Language-Level Action负责在语言和低层控制动作之间做映射尤其是从人类示教数据中学习“怎么做”而不是“做什么”。SLIM在这里有两个理解方向一是类似 “SLIMState-Language-Interaction Model” 的状态-语言-交互模型强调本体状态与语言指令的实时绑定二是轻量化基座模型Slim Base Model负责在边缘设备上提供低延迟推理。实时音视频感知底座则承担最基础的物理世界观测任务采集图像与音频、做时间戳同步、事件触发、状态缓存然后以低延迟喂给上述所有模型。这个分层设计最直接的收益是每一层都可以独立优化。如果你只需要“拿过来”就不必走一遍完整的语言规划和推理VLA 或 LLA 可以直接输出动作。如果你需要“理解用户意图”LLM 负责的规划层又不至于因为感知噪声而坍塌。感知底座负责把物理世界稳定、同步地数字化其余模型各自使用这份数据完成自己该完成的任务。2. LLM任务分解的“翻译官”但不是物理世界的执行器2.1 LLM 在具身智能里的真实分工很多同行一听到“具身智能”第一反应就是接入一个大语言模型让它直接生成机器人指令。这种想法有一定的合理性。LLM 在语义理解、常识推理、多轮对话、上下文记忆方面确实强得离谱尤其适合做“任务级”的指挥官。举个例子用户说“帮我热一杯牛奶然后放到餐桌上”。没有 LLM 的话你需要手写一个状态机来处理各种意图分支。有了 LLM系统可以直接推理出子任务序列取牛奶、倒到杯子里、放入微波炉加热、取出、放到餐桌。这个过程依赖的是语言模型预训练阶段积累的世界知识而不是某个特定场景的硬编码逻辑这是它最大的价值。但在具身智能场景里LLM 有个致命问题它不理解物理本体的实际约束。有一次我让 LLM 规划“把桌上的杯子拿起来”它输出“将机械臂移动到杯子位置闭合夹爪抬升手臂”。这听起来完全正确但当我把它翻译成机器人坐标时发现“杯子位置”这个描述根本没法落地。机械臂需要的是三维坐标、姿态、夹爪开合角度、运动速度而不是一句模糊的“杯子位置”。为了让 LLM 的规划真正可用你得自己写一套语义解析层把规划输出翻译成可执行的运动指令。这个翻译层不仅复杂而且极易出错。2.2 用“提示词工程API”快速验证方案我建议所有刚开始做具身智能的团队先不要急着训练 VLA而是用现成的 LLM API 快速验证任务规划链路。你只需要设计一套结构化提示词约定好 LLM 的输出格式例如 JSON 格式的子任务序列然后写一个解析模块将 JSON 里的“动词目标物体位置”映射为控制层的函数调用。这一步的核心价值不在于精确控制而在于让你快速理解语言模型在整个系统中的边界能做什么理解意图、分解复杂任务、生成异常处理分支。不能做什么无法感知真实世界中的实时变化无法保证时间约束无法输出稳定可靠的低级控制指令。所以在整套架构里LLM 的角色是“翻译官”和“指挥官”而不是“执行器”。让 LLM 直接生成电机指令就像让一个只会看地图的人开车他给你规划了路线却不知道方向盘应该转多少度。2.3 实操建议如何设计可靠的“LLM→任务序列”接口我在实际项目中常用这样一套接口设计指令用户输入: 把桌子上的蓝色杯子拿给我 LLM 输出JSON: { task_seq: [ {action: move_to, target: cup, coordinate: desk_surface, time_limit: 3.0}, {action: grasp, target: cup, force: 0.5, time_limit: 1.0}, {action: move_to, target: hand, coordinate: user_hand, time_limit: 3.0}, {action: release, target: cup, time_limit: 1.0} ], fallback: ask_user_for_confirm }解析模块拿到这个 JSON 之后再通过感知底座获取实时坐标数据将 “cup”、“desk_surface” 这些语义标签与视觉检测结果关联起来最终生成机械臂可执行的目标位置。这里有一个容易被忽略的细节LLM 输出 JSON 的稳定性和上下文长度。实测下来输出格式不稳定是常态尤其是当任务变复杂时JSON 可能出现字段缺失或参数偏差。解决办法是使用function calling或结构化输出约束并在解析时做严格的 schema 校验解析失败时强制重试。提示LLM 规划层一定要设置“人类介入确认”的节点。当任务涉及高风险动作例如夹持易碎品、靠近人体时规划器应返回“ask_user_for_confirm”而不是直接执行。这不是为了增加交互流程而是因为真实物理环境中的不确定性是 LLM 永远感知不到的。3. VLA 与 LLA从感知到动作的“原生通路”3.1 VLA 模型的本质视觉语言动作联合建模当我们从 LLM 往下走一层就到了 VLA。VLA 模型的核心思路很直接把视觉观测V、语言指令L和动作指令A放进同一个网络中训练模型直接从“看到的听到的”输出“要做的”。你可以把它理解为一种“多模态感知到动作”的端到端映射。传统方案是“视觉模块识别物体 → 规划模块决定动作 → 控制模块执行”每一步之间需要格式转换和数据对齐误差会逐渐积累。VLA 试图用一个大模型直接吃进图像和文本输出动作 token 或动作参数把中间过程全部省掉。这套思路在理论上非常诱人但工程落地时有一个关键争论VLA 到底是一个模型还是两个模型我的观点是严格意义上的工业级 VLA 是统一的、单一权重模型的端到端映射而不是“视觉模型语言模型”的拼接。你可以用两个预训练底座做初始化但在动作训练阶段它们必须联合在一起微调共享参数才能学习“看到这个场景—理解这句话—执行这个动作”的联合表征。如果只是把视觉模型的分类结果传给语言模型再让语言模型输出动作那你做的还是级联系统并不是真正的 VLA。3.2 动作表征设计离散化与连续回归的选择VLA 模型训练中最容易翻车的地方是动作表征设计。动作输出的大致有三种方案连续回归直接输出关节角度或末端位姿的浮点值例如theta1-15.2, theta242.8。方案最简单但回归任务容易收敛到平均值导致动作抖动和滑行。离散化动作 Token把每个关节的角度范围划分成 256 个离散区间模型输出区间 ID。做法参考了 LLM 的 Token 预测方式稳定性更好但表达精度受限需要配合机器人本体做动作平滑过滤。动作残差模型输出的是“在当前状态下增加多少运动”而不是绝对位置。这种方法更适合高精度控制但需要良好的状态初始化机制。我第一次训练 VLA 时选了连续回归结果模型输出的动作曲线有大量高频抖动末端执行器的轨迹像“帕金森患者”一样。后来改成离散化 Token 输出再在后处理阶段用低通滤波做平滑机械臂轨迹才稳定下来。注意VLA 模型对机器人本体的传感器标定非常敏感。视觉输入的画面如果存在畸变、色偏、景深误差模型输出的动作偏差会成倍放大。训练前一定要对相机做内参标定和手眼标定这是一项繁琐但绝对绕不开的工作。3.3 LLA语言与动作之间的“快捷方式”LLA 是一个比 VLA 更“轻”的方向。它不依赖视觉信息或者只在必要时使用视觉强调的是语言指令到低层动作原语的直接映射。我举一个很常见的场景机器人已经学会了“夹取”这个动作原语你通过语音命令“用手抓握”和“用手指捏住”希望机器人产生两种不同的动作表现。对 VLA 来说这需要视觉语言同时处理但 LLA 可以只关注“语言变体”和“动作特征”之间的关联输出更精细的动作参数调整。LLA 在数据收集上有明显优势。因为它的输入更简单不需要大量多模态对齐数据只需要“指令文本动作特征”的配对数据。你可以从真实人工示教中记录动作轨迹然后用自然语言给动作轨迹做标注形成一个“语言标签-动作序列”的数据集。这套流程在数据采集成本和模型训练效率上都比 VLA 划算很多。3.4 实操建议如何选择 VLA 还是 LLA选择哪种方案取决于你的任务形态任务特征推荐方案原因任务依赖视觉定位、需要操作未知物体VLA视觉信息是动作决策的核心输入任务动作固定、只变语言表达LLA减少了视觉噪音干扰训练数据更容易采集跨平台部署、有算力限制LLA 轻量化视觉特征模型体积小便于在边缘设备运行需要复杂操作技能擦拭、插拔、装配VLA 轨迹残差学习复杂操作需要视觉反馈闭环有一类特殊情况值得单独说如果机器人要操作的是完全已知的固定工件例如在流水线上安装螺丝视觉定位只是用来确认工件存在那么用 VLA 是浪费算力用 LLM 规划传统视觉LLA 更容易达到工业级稳定性。这也是我在工厂场景里的真实感受——端到端大模型在开放世界很好用但在封闭场景里暴力适用反而增加风险。4. SLIM 与轻量化模型边缘侧推理的现实选择4.1 SLIM 模型在具身智能里的两种定位SLIM 这个缩写稍微有点冷门但在具身智能圈子里越来越多见。它最少有两种理解第一种是State-Language-Interaction Model状态-语言-交互模型。这类模型强调“当前机器人本体的状态”关节角度、末端位姿、传感器读数与“语言指令”的联合建模。VLA 的重点是视觉观测LLA 的重点是语言映射而 SLIM 的重点是状态融合。它对机器人实时反馈的依赖非常强适合做那种“一边感知自身姿态一边响应语言指令”的交互任务。第二种是轻量化基座模型Slim Foundation Model。因为很多具身智能设备不可能在机身上搭载一块 A100更常见的组合是主板上插一块 Jetson Orin或者干脆用树莓派加推理棒。轻量化基座模型是指把 LLM/VLA 压缩到能在边缘设备上流畅运行的小模型通常采用参数量一两亿级别的小网络加上模型量化、知识蒸馏等手段。这两种定位并不矛盾。一个完整的具身系统里很可能用 SLIM 轻量化模型在本地做低延迟的状态理解再用云端的大模型做复杂推理。4.2 边缘侧量化与蒸馏的实操心得我在 Jetson Orin NX 上部署过一个轻量级视觉语言模型参数量 18 亿通过 INT8 量化后显存占用大约 2.2GB推理延迟在 30ms 左右。对于一个基础的“物体识别指令理解”任务这个性能完全够用。关键步骤是选择基座不要从零训练优先选择开源的小模型比如 InternVL2-1B、MiniCPM-V 2.6、Moondream 这类多模态小模型。蒸馏用一个大教师模型生成伪标注对小模型做微调让它模仿教师模型的输出分布。蒸馏后的小模型在专项任务上的表现通常能超过原始水平。量化使用权威推理库完成 INT8 量化。量化虽然能显著降低显存占用但会影响模型输出的稳定性因此量化后一定要做动作安全边界测试防止模型在高危任务中输出错误指令。缓存与预热边缘设备经常遇到首次推理耗时过长的问题。解决办法是提前做一次空输入预热让模型权重常驻显存避免频繁加载。SLIM 模型训练的另一个核心痛点是数据量的要求。行为克隆Behavior CloningBC需要比语言模型训练更多的样本因为动作轨迹的分布高维且连续。我见过很多团队在数据量不够的情况下强行训 VLA最后模型在训练集上表现完美但换一个新场景立即失效。后来我学到一个技巧先用少量数据的蒸馏结果生成大量“伪动作”再通过逆动力学模型筛选合理的伪动作将有效伪数据与真实示教数据混合训练。这个方法让模型的泛化性明显提升实测下来数据利用率至少翻了一倍。4.3 云边协同别把所有推理都压到边缘设备轻量化模型好用但千万不要迷信“全端侧部署”。具身智能系统里最合理的形态是云边协同。简单的规则是云上大模型负责复杂语义理解、跨场景规划、知识问答。边缘小模型负责毫秒级的感知、动作前馈、安全兜底。实时音视频感知底座负责把边缘和云之间的数据链路连起来同时做事件触发与降级策略。这套架构的好处在于即使云端网络断开、大模型服务不可用机器人还能依靠本地感知底座和轻量模型维持基础的安全运作比如停下来、回到安全位姿、播放提示音。在我的项目里这条“保底链”非常重要任何时刻都不能完全依赖远程服务。5. 实时音视频感知底座具身智能真正的“地基”5.1 为什么感知底座比模型本身更稀缺做具身智能的难点业界聊模型聊得非常多但很少有人谈论“数据是怎么喂到模型里的”。我自己的经验是真正的难点恰恰在感知底座。具身智能的感知与传统计算机视觉有本质区别传统视觉任务里模型输入一张静态图输出一个结果你可以随便等几秒种再给结果。具身智能的感知必须实时、循环、多模态同步。机器人的“眼睛”和“耳朵”需要以毫秒级的时间分辨率持续观测动态世界并把结果直接送到决策回路里。我这里要特别强调“实时音视频感知底座”的重要性。它指的是一套同时支持视频流、音频流、时间戳同步、事件触发、数据缓存与回放的基础设施换句话说它解决的是感知数据的采、传、同步、分发问题而不是单纯的“识别”问题。一个典型的流程是相机以 30FPS 采集 RGB 图像麦克风阵列以 16kHz 采集音频感知底座给每一帧图像、每一段音频打上高精度时间戳然后通过共享内存或消息队列分发给 VLA、LLM、SLIM 等模型。当检测到语音指令时感知底座立刻触发视觉抓帧将最近 200ms 内的高频图像与音频打包成一个事件片段送入模型。没有这套底座你在机器人上看到的每个模型都会像“一个硕大的大脑接在一个瘫痪的身体上”推理再快也难以形成闭环。5.2 关键设计音视频同步、事件触发与缓存回放设计实时感知底座时下面四个要素是最重要的。第一音视频硬件选型与时间戳同步。建议优先选用支持 PTP精确时间协议的工业摄像头与麦克风或者自己维护一套统一的时钟源。USB 摄像头和普通声卡的时间离散问题严重会有几十毫秒到上百毫秒的随机误差VLA 模型在训练和推理时最怕这种时间混乱。时间戳的误差会直接造成“看到画面”和“听到声音”对不上模型输出动作出现奇怪的延迟偏差。曾经有段时间我调试机械臂抓取每次都出现“拿早了”的错觉排查两天才发现是摄像头和麦克风的时间戳相差了 150ms。第二事件触发机制。具身智能场景里你不能让所有传感器数据都进入模型那样算力根本扛不住。合理设计是感知底座常驻运行低成本的音频事件检测器例如语音活动检测 VAD当检测到指令出现才触发视觉数据的高频抓取和多模态模型推理。这套事件的触发模式能够省掉大量背景帧和无效推理让系统负载降低一半以上。第三数据缓存与回放。感知底座还要提供一个环形缓冲区默认保留最近 5 到 10 秒的原始多模态数据。一旦系统出现异常操作员可以直接从缓存里导出成功或失败的时间段作为调试数据。这个功能在模型迭代中特别有用相当于给系统装上了一台“行车记录仪”。第四数据发布与订阅的隔离性。感知底座应该作为一个独立进程内部通过共享内存做视频流并发分发而不是逐个发送给模型。模型订阅数据时只申请自己需要的分辨率、帧率和格式避免每次感知推理都要复制一份全分辨率数据。实测下来同样的机器人端到端延迟可以缩减 30% 以上。5.3 架构示例一套可落地的感知底座我分享一套我自己验证过的轻量级感知底座设计技术栈可以根据团队熟悉度替换采集层实时流: - RGB 摄像头 30FPStopic: /sensor/rgb - 麦克风阵列 16kHztopic: /sensor/audio - 编码器/IMUtopic: /sensor/state 同步层: - 统一时间戳硬件时钟 or 主控时钟 - 音视频缓存池环形缓冲 10s - 事件检测VAD 运动检测 声音定位 推理接入层: - 共享内存分发零拷贝 - 模型订阅管理分辨率/帧率/格式协商 - 触发器检测到指令→抓取最近 500ms 多模态片段→送入 VLA 反馈层: - 回放与录制 - 日志与可视化这套底座的开发工作量远没有想象中那么大。按我的经验两个熟练工程师大概 2 到 3 周可以完成第一版但它的重要性远超同时间的模型训练。没有它任何上层模型都会变成无根之木、无源之水。5.4 降级策略感知出错时安全永远优先还有一个必须在感知底座设计里写进去的机制降级策略。当感知数据异常时比如相机被遮挡、音频流中断、时间戳漂移超过阈值系统不能“硬跑”。我的做法是设置一套感知健康度评分机制满分 100 分正常。低于 80 分减少高级模型推理频率。低于 50 分切换为纯本地基础感知 低速度模式。低于 20 分进入停止状态请求人工接管。现实中很多具身智能事故都源于对感知异常的忽略。模型输出还在继续但机器人已经“瞎了”这是最危险的组合。感知底座必须具备感知自己的能力的健康监控机制这比任何算法都重要。6. 常见问题与排查技巧实录6.1 VLA 模型输出动作抖动严重怎么办很多朋友跑通 VLA 训练后第一个遇到的坑就是动作输出抖动。模型输出正常但动作不平滑。我的解决顺序是先检查动作表征方式。如果用的是连续回归换成离散化 Token 或动作残差。再检查训练数据。收集动作数据时要注意在时间上对齐不要让同一个动作在相邻帧之间出现跳变。建议人工清洗掉所有示教过程中“犹豫”的数据段。最后在后处理层加滤波。我通常叠加一个均值滤波或卡尔曼滤波再做最小加速度约束。注意滤波不能太激进否则反应延迟会上升。6.2 LLM 规划正确但机器人执行失败这是典型的“语义层与物理层脱节”。我先检查 LLM 输出的任务序列中是否包含了机器人本体无法完成的动作描述。比如“把鸡蛋拿起来”但本体没有鸡蛋对应的夹爪类型这种情况下 LLM 规划的再正确执行器也做不到。建议在 LLM 的提示词中注入机器人的能力集描述包括可用夹爪类型、行程范围、速度上限让模型在规划阶段就排除掉不可能的任务。6.3 感知底座时间戳漂移排查当你发现模型的输出“总是慢半拍”或“对不上”优先排查时间戳。我用一个三步法录制一段连续运动的视频和音频后台同时记录时间戳。播放时观察音画同步偏差如果偏差是固定的直接做一次性偏移补偿。如果偏差是逐步变大的说明存在时钟漂移这时需要改用 PTP 同步或周期性地用主时钟校准。6.4 轻量化模型在边缘设备上推理首次加载缓慢这是边缘设备最常见的问题。由于模型权重要从磁盘加载到显存首次推理特别慢。解决办法是编写一个“预热脚本”系统启动后后台立即加载空数据过一遍推理让权重提前驻留显存。同时把常用模型的配置信息写在持久化配置里避免每次启动都重新扫描设备资源。6.5 数据采集成本过高训练数据不够很多团队的数据采集依赖于人工示教效率低且难以规模化。我的建议是构建一个“遥控自动扩充”的混合数据管道。先请一位熟练操作员通过遥操作完成 50 次高质量示教然后用这些示教数据训练一个简单的动作预测模型再用这个模型在高置信度区域自动生成候选动作。最后通过逆动力学模拟器和物理引擎筛选合法轨迹合并成训练集。实测数据量可以扩充 3 到 5 倍质量保持在可接受范围内。6.6 速查表常见问题与解决方案现象核心原因排障建议LLM 输出 JSON 解析失败提示词约束不足或模型版本过旧改用结构化输出/function calling升级模型增加重试机制VLA 动作抖动连续回归不稳定或数据标签噪声高改离散化 Token清理示教数据加平滑滤波音视频感知对不上时间戳同步缺失统一时钟源做偏移补偿周期校准边缘推理延迟高模型参数量过大或缓存未常驻量化蒸馏启动预热共享内存分发具身智能系统偶发“抽风”感知异常但上层模型继续运行加感知健康度评分降级策略强制人工接管训练集拟合但换场景失效数据分布单一真实感弱增加域随机化引入更丰富动作数据蒸馏伪数据6.7 关于 SLIM 训练的一个补充经验训练 SLIM 状态-语言-交互模型时我最常被问到的其实是“状态怎么定义”。每家机器人本体的状态空间差异很大有的用关节角度有的用末端笛卡尔坐标还有的配合力矩传感器。我的建议是SLIM 模型的状态输入不应该只包含单一表示。最不济也要同时接入关节角度和末端位姿让模型自己选择哪一组特征对当前任务更重要。更好的做法是把状态历史也拼进去例如过去 5 个时间步的状态序列让模型能感知到速度、加速度等隐含运动信息。这个调整让我训练的 SLIM 模型在复杂交互任务上的成功率从 62% 直接提升到了 81%。原因在于许多“下一步动作”只有结合当前运动趋势才能判断正确单独一帧的状态信息根本不充分。7. 这一整套技术路线的落地节奏建议聊了这么多如果你正打算进入具身智能方向我依据个人踩坑的经验给你一个落地顺序建议先搭建实时音视频感知底座这是根。没有它后面的所有模型都是空中楼阁。再把 LLM 规划层跑通用 API 快速验证任务分解效果。然后收集一批高质量示教数据尝试训练 LLA 或轻量化的 SLIM 模型。最后再上 VLA因为 VLA 对算力和数据质量要求最高放在最前端做是对资源的不合理消耗。在我实际做过的项目中这个顺序帮我在同样预算和同样时间里达到了更好的整体系统稳定性和模型泛化能力。如果你反过来一上来就找 VLA 开源模型、花大量算力微调大概率会在最后发现数据集采集链路和时间同步问题已经成了整套系统的短板而这块短板消耗的返工成本远超前期省下的那点时间。具身智能的研发太容易陷进模型参数的迷思但真正让系统能在物理世界稳定运转的往往是那些看起来“不性感”的底层模块。我自己的团队到现在仍然会频繁维护感知底座的采集、同步、缓存这套基础设施因为它是任何上层模型的“真实世界接入层”是由不计其数的细节组成的。这套东西前期打磨得越仔细后续模型迭代的步子才能迈得越大。