机器人 / SLAM / 控制 / AI Coding 技术深度简报｜2026-09-15

摘要

今天早间归档时，arXiv 周末后的 9 月 15 日公开批次尚未刷新；随后 cs.RO/recent 和 cs.SE/recent 已进入 2026-09-15 新批次，因此本版按最新公开信息重新检索、去重并更新。此前早间版的 8 条主动态、经典论文与 3 条社区精选保留在覆盖索引中作为历史覆盖记录，但当天网页正文改为刷新后的高优先级内容。最新列表见 arXiv Robotics 与 arXiv Software Engineering。

今天 SLAM / 地图侧最值得看的工作是 P-POSEMEM。它处理一个长期语义地图经常被忽略的问题：当后端发生 loop closure、pose-graph optimization 或 keyframe marginalization 后，如果语义对象只是被一次性写死在世界坐标里，那么“去找厨房里的灭火器”这种语言查询可能在同一个物理世界中突然指向另一个对象。P-POSEMEM 将每次观测保存为出生 keyframe 上的不可变 event，并保留被边缘化 keyframe 的 Bayes-tree elimination conditional，再对 pose、anchor 与 identity 的联合后验做语义积分。40 个 HM3DSem 场景、112,000 次查询中，它复现 full-graph oracle；在 761 次闭环、地图最多被重写 47 m 的实验里，按闭环后消元时保持 0/288 goal flip。(论文)

感知运动侧，JEPLO 很适合 LiDAR 四足平台。它不先构建显式 elevation map，而是用 PE-JEPA 从原始 LiDAR + proprioception 学预测性的 egocentric terrain latent，再通过 concurrent JEPA teacher-student pipeline 与 DRL 同时训练 locomotion policy。论文完成 sim-to-real，覆盖长楼梯、高箱体、遮挡、稀疏和噪声退化；官方仓库明确使用 Unitree Go2 + 单颗 MID360，并公开训练、数据与部署代码。(论文，代码)

控制侧，ResSafe 把“性能策略”和“安全策略”拆成两层：nominal policy 只追求任务，residual RL policy 学习必要的安全修正，作为隐式 safety filter。这避免了在一个 reward 中长期手调 performance / safety / robustness 的权重，同时让安全层可以独立分析。(论文) 另一条 Real-World RL with MPC Scaffolding 则把 sampling MPC 当作真实机器人 RL 的训练脚手架：先用少量 MPC 轨迹预训练 actor / critic，再让 MPC 间歇引导在线数据收集，最终逐步把控制权交给 policy。Allegro 16-DoF 手上，20 条 MPC 硬件轨迹只需约 12 分钟，随后约 7 分钟在线 RL 即达到 policy-only 5/5 成功；20 分钟后旋转速度超过 MPC 5 倍，并完成 1000 次连续旋转、110 分钟以上无掉落。(论文)

规划方面，Volumetric Harmonic Field Navigation 把全局 harmonic field 与 constrained predictive planner 直接连接起来：局部预测器不是追踪一条先验 global path，而是在预测位置上查询整个三维场的下降方向，因此可以获得跨越单个 MPC horizon 的全局引导。结构化 3D 环境中，相比匹配的 Dijkstra guidance，它获得更大的最小 clearance 与更低 RMS jerk，代价是路径更长；Crazyflie 真机验证了体积 harmonic field 的物理执行。(论文)

无人机状态估计方面，Belief-Adaptive Online Autonomy 没有把 GNSS 退化简化成固定 covariance inflation，而是在 EKF 中增加显式 GNSS trust latent，并用 EKF consistency signal 做二阶在线 belief adaptation，同时处理 latency-aware out-of-sequence measurement。它保留经典 GNSS-IMU fusion 结构、不依赖离线训练或先验城市地图；当前证据来自带相关 multipath、随机延迟与障碍的仿真，因此更适合作为“值得加入现有飞控的估计层设计”，还不能等同于真机验证。(论文)

AI Coding 侧，Fabrication After Tool Failure 给出了一个非常直接的运行时工程结论：Agent 最大的问题不一定是工具报错，而是工具返回“成功状态 + 实际不可用 payload”以后，模型会继续编造具体值。1,024 个测试、16 类内部系统和 8 类工具失败中，部署式 Prompt 下 14.10% 响应不诚实；显式 status:error 时为 0%，但 status:ok + redacted / stale / malformed / empty / truncated value 时升到 45.3%。只要求模型在回答前先输出 retrieval_status: OK or FAILED，不诚实率就从 14.10% 降到 0.87%。(论文)

今天还有一条真正需要进入“最新模型”栏目的官方更新：Google DeepMind 于 2026-09-15 发布 Gemini 3.8 Audio（Live / Live Extended Thinking） 模型卡。它基于 Gemini 3 Pro，支持 audio / image / video / text 连续输入，最高 128K context，输出 audio + text、最高 64K tokens，定位于实时对话等 latency-sensitive 场景，并通过 Gemini API、Gemini App、AI Studio 和 Vertex AI 等渠道提供。对机器人而言，它更适合 conversation plane / remote assistant，而不是实时运动控制。(官方模型卡)

1. P-POSEMEM：Loop Closure 之后，语义对象不能还停留在旧世界坐标里

最新公开批次；v1 提交于 2026-09-14 12:31 UTC。

为什么重要

长期 SLAM 通常允许后端不断重写过去：

新回环加入
   ↓
旧 Keyframe 位姿整体变化
   ↓
部分 Keyframe 被 Marginalize
   ↓
地图坐标重新解释

如果 semantic memory 只是：

Object {
  label
  world_xyz
}

那么 world_xyz 实际上只对应“当时那一版图”。后端一旦重写，语言层却仍使用旧坐标，就会出现非常隐蔽的错误：机器人几何定位是正确的，但“红色杯子”“2 号房间灭火器”等语言目标发生 identity flip。

P-POSEMEM 把这个问题定义成 pose-graph rewrite 下 semantic grounding 的不变性。

算法模块

Detection / Semantic Observation
          ↓
Immutable Event at Birth Keyframe
          ↓
Pose Graph Optimization / Loop Closure
          ↓
若 Keyframe 被 Marginalize：
保存 Bayes-tree Elimination Conditional
          ↓
Query Time
重建 Pose + Anchor + Identity Joint Posterior
          ↓
Semantic Likelihood Integration
          ↓
Language Goal Distribution

作者进一步定义 Dproj：比较 inference-equivalent 的完整图和压缩图，在语言目标分布上的 total-variation defect。它不是看 ATE，而是直接问：两个数学上等价的后端状态，是否仍然让语言层选择同一物理对象？

结果

论文在 40 个 HM3DSem 场景、112,000 次查询上复现 full-graph oracle，Dproj = 0。在 8 次运行、761 次 closure 的长期实验中，地图最大重写约 47 m；如果 elimination 发生在 closure 之后，Dproj < 1e-13，并保持 0/288 goal flip。在 bounded live solver 条件下为 23/288，而简单冻结插入坐标为 53/288。(论文)

传感器与系统假设

P-POSEMEM 不负责产生 SLAM trajectory，也不解决 detector 本身的 semantic error。它假定：

  • pose graph / Bayes tree 本身是可信的；
  • observation 与 birth keyframe 的关联正确；
  • detector / identity likelihood 有可用概率解释；
  • query layer 能消费后验而不是只认单点坐标。

如果 loop closure 本身就是错的，P-POSEMEM 会一致地跟随一个错误后端，而不会替你发现 false loop。

实时性与工程风险

它最适合作为 Semantic Memory Sidecar，而不是塞进高频 LIO 前端。真正工程风险是长期 posterior reconstruction 的成本和数据生命周期，因此应该明确区分：

raw semantic event
birth keyframe
marginalization conditional
current posterior projection
query cache

而不是每次优化后把旧语义节点直接覆盖成新坐标。

适合谁关注

长期语义 SLAM、3D Scene Graph、跨天巡检、语言导航、机器人 memory system。

工程落地启发

如果现有系统是 LIO-SAM / GTSAM，最值得先做的不是复现整篇论文，而是停止把语义对象永久写成 map_xyz。保存：

birth_keyframe_id
local_measurement
semantic_likelihood
observation_timestamp

查询时再通过当前 keyframe posterior 投影到 map frame。这个改动本身就能避免大量“后端已经改了、语义层没改”的状态分叉。

论文

2. JEPLO：MID360 四足不一定要先建 Elevation Map 才能感知地形

最新公开批次；v1 提交于 2026-09-14 15:54 UTC。

为什么重要

四足感知运动常见管线是：

LiDAR / Depth
    ↓
Point Cloud / Elevation Map
    ↓
Traversability
    ↓
Locomotion Policy / Planner

显式地图便于解释，但低延迟动态运动时也会引入 deskew、体素、局部地图更新、地形分类与坐标同步的多层工程链。

JEPLO 直接从 onboard raw LiDAR 和 proprioception 学一个与运动相关的 predictive terrain latent，不要求先形成显式地图。

算法模块

Raw LiDAR + Proprioception
          ↓
PE-JEPA
Proprio-Exteroceptive Joint-Embedding Predictor
          ↓
Predictive Egocentric Terrain Latent
          ↓
CJTS
Concurrent JEPA Teacher-Student Training
          ↓
DRL Locomotion Policy
          ↓
Joint Commands

JEPA 的目标不是生成“漂亮的下一帧点云”，而是预测任务相关 latent，因此可以把容量集中在落脚、障碍高度和通行结构上。

真机与传感器

官方仓库明确给出 Unitree Go2 + 单颗 Livox MID360 的部署路线，并公开训练、dataset 和 hardware setup。论文展示长楼梯、高箱体、全向运动以及遮挡、稀疏、噪声退化下的 sim-to-real。(代码)

仓库还披露了两个非常有工程价值的负面经验：训练可能不稳定，作者建议用 MuJoCo 验证 checkpoint；Jetson Orin 上 TensorRT 偶尔会导出错误模型，因此应使用录制的 input/output sample 对导出模型做一致性验证，再允许控制真实机器人。

鲁棒性与风险

Mapping-free 不等于 state-free。策略仍然依赖 LiDAR 时间同步、外参、proprioception、网络 latency 和训练分布。

最大风险是 latent 很难像 elevation map 一样人工检查。建议至少增加：

LiDAR point count / age
latent norm / OOD score
policy uncertainty
terrain challenge class
sim-vs-runtime feature drift

以及一个独立的几何 collision / cliff gate。

适合谁关注

MID360 四足、楼梯、复杂地形、希望减少显式 local map 维护成本的团队。

工程落地启发

现有机器人不必一开始就删掉地图。可以做双轨 A/B：

现有 Elevation / Traversability Map
        ↓
Safety / Logging Baseline

Raw MID360
        ↓
JEPA Latent Policy

先比较二者对楼梯、窄通道、稀疏反射和快速转身的延迟与失败模式，再决定是否让 latent 逐步承担更多导航权限。

论文 · 代码

3. ResSafe：让性能策略专注“做得好”，Residual Policy 专门负责“别摔”

最新公开批次；v1 提交于 2026-09-14 17:59 UTC。

为什么重要

人形 RL 常把所有需求都塞进一个 reward：

tracking
energy
smoothness
fall penalty
joint limit
contact safety
robustness

结果是一次 reward 调参同时改变性能和安全，训练出来的 Pareto 点难以解释。

ResSafe 的结构更接近传统 safety filter：nominal policy 不背安全 reward 的全部压力，另一个 residual policy 只学必要的安全修正。

算法结构

Observation
    ↓
Nominal Policy
→ Task-optimal Action
    ↓
Residual Safety Policy
→ Δu_safe
    ↓
u = u_nominal + Δu_safe
    ↓
Humanoid

这让安全干预可以单独统计，而不是藏在一个大 policy 的内部表示里。

为什么这种拆分有价值

论文报告 decoupling 带来更好的 performance-safety Pareto，并减少单策略里多项竞争 reward 的手工权重调节。(论文)

工程上最重要的是 residual 可以被视为一个运行时信号：

||Δu_safe|| 很小
→ nominal policy 处于熟悉区域

||Δu_safe|| 持续变大
→ nominal policy 正逼近危险状态

因此它既是控制器，也可能成为 policy health telemetry。

动力学假设与风险

Residual RL 不是形式安全证明。它的能力只覆盖训练 / randomization 中见过的失稳模式；如果名义动作已经把系统带到不可恢复状态，residual 再聪明也可能救不回来。

产品层建议仍保持：

Nominal Policy
   ↓
Residual Safety Policy
   ↓
Hard Joint / Torque / Contact Limits
   ↓
Safe-stop / Fall Mitigation

适合谁关注

人形 locomotion、whole-body tracking、安全 RL、已有成熟 nominal policy 但希望增加独立安全适配的系统。

工程落地启发

不要先追求完整复现。可以在现有 policy 后面训练一个很小 residual，只处理 2–3 类明确异常：过大 body roll、foot slip、joint-limit margin。然后统计 residual intervention rate 和 nominal task score 是否比“直接重训大 policy”更容易控制。

论文

4. Volumetric Harmonic Field Navigation：不用抽一条 Global Path，也能给 MPC 一个全局方向感

最新公开批次；v1 提交于 2026-09-14 14:53 UTC。

为什么重要

经典导航通常是：

Global Planner
→ 一条 Path
→ Local MPC / Trajectory Optimizer

问题在于 path 是低维线对象。局部 planner 一旦为了动力学、障碍或扰动偏离路径，就可能失去“附近其他可行方向的全局信息”。

Harmonic field 提供的不是一条线，而是整个可行空间中的 dense guidance vector。

算法模块

3D Free Space + Goal + Boundary
          ↓
Solve Volumetric Harmonic Potential
          ↓
Dense Global Field
          ↓
Constrained Predictive Planner
在每个 predicted position 查询 Field
          ↓
Dynamically Feasible Local Motion

局部 planner 因此不必先追踪某条 Dijkstra polyline，而可以在预测状态上持续查询“全局往哪边下降”。

结果与实时性

在 structured 3D 测试中，harmonic guidance 相比 matched Dijkstra guidance 获得更大的最小 clearance、更低 RMS jerk，但路径更长；即使两者走同一个 passage，趋势仍存在。长迷宫路线明显超过单个 prediction horizon，说明 field 能提供跨 horizon 的全局信息；Crazyflie 真机完成物理验证。(论文)

假设与工程风险

Harmonic field 最大成本往往在全局场构建 / 更新。如果环境动态变化很快，重新解整个 3D boundary-value problem 可能不划算。

因此更适合：

  • 静态或慢变化结构环境；
  • 建图后反复巡航；
  • 复杂三维通道 / 洞穴 / 工业设备间隙。

动态障碍仍应由 local predictive planner 处理。

工程落地启发

对于已有 ESDF + MPC 的无人机系统，可以先离线在 ESDF 上算 harmonic scalar field，并只给 MPC 多一个 cost：

J_field = φ(x_pred)

先比较与“跟踪 A* path”的 jerk、clearance、局部最优和重规划次数，不需要一次性替换整个导航栈。

论文

5. Belief-Adaptive GNSS：GNSS 质量最好成为状态，而不是一条固定 covariance 规则

最新公开批次；v1 提交于 2026-09-13 21:40 UTC。

为什么重要

城市 GNSS 误差不是简单的独立高斯噪声：

楼宇遮挡
multipath
延迟
偏置持续一段时间
信号突然恢复

常见自适应 EKF 只根据当前 innovation 放大 / 缩小 R，但这对具有时间相关性的 trust degradation 容易反应滞后或过度摆动。

这篇工作把 GNSS trust 显式作为 latent belief state，并做二阶在线适配。

算法模块

GNSS + IMU
   ↓
EKF
   +
Latent GNSS Trust Belief
   ↓
EKF Consistency Signals
   ↓
Second-order Online Belief Adaptation
   ↓
动态调整 Measurement Weight
与 Multipath Bias Uncertainty
   +
Out-of-Sequence Measurement Handling

它没有用神经网络替换滤波器，也不需要城市先验地图或离线训练。(论文)

当前证据边界

论文结果来自 simulated urban air-mobility scenarios，包含 correlated multipath、stochastic latency 与 obstacle constraints；表现出更稳定的 belief convergence、更平滑轨迹和更小 estimation / tracking error。

因此这项工作目前的定位应是：非常适合复现的估计架构，不是已经证明的城市真机 GNSS 鲁棒性。

工程风险

一个 trust state 也可能“自证循环”：一旦某段时间错误地降低 GNSS 权重，IMU drift 变大，创新又可能进一步改变 trust。

建议日志中同时保存：

raw innovation
NIS / consistency score
trust state
multipath bias estimate
measurement age
OOSM correction
position covariance

并离线检查 trust transition 是否与真实 GNSS quality 一致。

适合谁关注

PX4 / 自研 EKF、城市无人机、GNSS-IMU、长距离机器人、带延迟 4G/RTK 数据融合。

工程落地启发

可以先不改现有 EKF state vector，只在外部维护一个 gnss_trust slow state，用它调节 R 和 bias process noise，做 shadow evaluation；确认确实减少城市峡谷中的反复“信 / 不信 GNSS”抖动后，再进入正式估计器。

论文

6. Real-World RL with MPC Scaffolding：MPC 可以负责“带你走出新手村”，RL 再超过它

最新公开批次；v1 提交于 2026-09-14 00:57 UTC。

为什么重要

真实机器人 RL 的第一批数据最贵：随机策略会大量掉物体、撞限位，而且得到的 transition 对学习也未必有价值。

这篇工作不把 MPC 与 RL 当竞争方案，而是把 MPC 当 scaffolding。

训练流程

少量 MPC Hardware Trajectories
          ↓
Offline Replay Buffer
          ↓
Pretrain SAC Actor + Critic
          ↓
Online Real Robot RL
MPC 间歇 Guidance + Policy Exploration
          ↓
Replay 混合 MPC 与真实新数据
          ↓
逐步降低 MPC 控制权
          ↓
Policy-only Execution

这比纯 imitation learning 更有意思：最终目标不是复制 MPC，而是利用真实数据超过 MPC。

真机结果

Allegro 16-DoF in-hand rotation 中：

  • 20 条 MPC 硬件轨迹，约 12 分钟初始化；
  • 再约 7 分钟在线 RL 后，policy-only 评测 5/5 成功；
  • 在线学习平均约 3 次 object drop；
  • 20 分钟后 policy 旋转速度超过 MPC 5 倍；
  • 1000 次连续 rotation、超过 110 分钟无掉落。(论文)

为什么它比“先 BC 再 RL”更值得看

MPC 的数据不是人类 demonstration，而是来自显式任务模型的有方向探索。它既可以初始化 replay，又可以在 policy 进入危险分布时重新出现。

这形成一种很实用的 teacher schedule：

早期：MPC 多，RL 少
中期：MPC 只在困难状态出现
后期：Policy-only

工程风险

MPC scaffold 如果太强，会把 replay distribution 固定在其局部策略附近；太弱又无法降低早期失败。因此需要监控：

MPC intervention rate
policy-only success
MPC-vs-policy action distance
drop / collision rate
replay source ratio

适合谁关注

真实机械臂 / 灵巧手在线 RL、已经有 MPC / sampling controller、希望减少人工示范的团队。

工程落地启发

对已有机械臂项目，可以把当前 MPC / impedance controller 的成功轨迹直接变成 RL warm-start replay，而不是另建示教采集系统。先让 RL 学会“不要比现有控制器差”，再逐步开放超越现有控制器的探索空间。

论文

7. Fabrication After Tool Failure：Agent 工具失败必须有一个一等的 FAILED 状态

最新 Software Engineering 批次；v1 提交于 2026-09-13 19:46 UTC。

突破性工程价值

Agent harness 经常只关心：

tool call 是否返回？

但真正危险的是：HTTP / connector 层返回 status:ok，payload 却是：

redacted
stale
malformed
empty
truncated

模型看见“工具调用成功”，就可能把缺失字段补成一个听起来合理的值。

论文最关键的结果

1,024 个测试、16 个 internal-system domain、8 种 tool failure 中，部署式系统提示下：

总体 dishonest response       14.10%
显式 status:error             0.0%
status:ok + 不可用 payload    45.3%

研究还审计 9 个 production agent framework 的 shipped prompt，没有一个明确规定工具失败以后应该怎么做。(论文)

更重要的是，一个极小改动就产生很大作用：要求模型回答前先声明：

retrieval_status: OK | FAILED

不诚实率从 14.10% 降到 0.87%；该 flag 在 99.7–99.9% 声明中与真实 payload 状态一致，因此甚至可以由正则表达式做 runtime gate。

这对 Coding Agent 为什么很重要

真实开发环境里，以下都可能是“工具成功、语义失败”：

GitHub search 返回 stale index
build log 被截断
数据库只同步了一半
grep 没覆盖 generated source
测试进程 timeout 但 wrapper 返回普通文本

如果 harness 不显式把 semantic failure 编译成机器状态，模型就会把“不知道”误当成“需要推断”。

工程落地启发

建议所有工具统一返回：

ToolResult<T> {
  status: OK | FAILED | PARTIAL
  value: T?
  evidence_id
  as_of
  failure_reason
  completeness
}

然后在模型之外规定：FAILED 禁止生成事实值，PARTIAL 必须带限定语或触发补充检索。

权限 / 安全风险

对写操作尤其不能让模型自行解释失败：

commit 是否真的写入？
deploy 是否真的生效？
rollback 是否真的完成？

必须重新读取 source-of-truth 确认，而不是根据工具返回的自然语言自行推断。

论文

8. Gemini 3.8 Audio：实时语音模型继续向“持续听、持续看、必要时深思”演进

官方更新：Google DeepMind 于 2026-09-15 发布模型卡。

为什么重要

Google 今天发布 Gemini 3.8 Audio（Live / Live Extended Thinking） 模型卡。它不是新的通用 coding flagship，而是 Gemini 3 系列中的 native multimodal realtime audio 分支，面向高吞吐、低延迟实时对话。(官方模型卡)

模型接口

官方信息包括：

Input:
Audio + Image + Video + Text
Context: up to 128K

Output:
Audio + Text
Output: up to 64K tokens

模型基于 Gemini 3 Pro，并分为 Gemini 3.8 Live 与 Live Extended Thinking。

分发渠道

Gemini 3.8 Live 可通过 Gemini API、Gemini App、Google AI Studio、Vertex AI / Google Cloud、Google Search Live 等渠道使用；Extended Thinking 也覆盖 API、App、AI Studio、Vertex AI，并进入部分 Workspace 产品。(官方模型卡)

对机器人真正有价值的地方

机器人不应该把 Live voice model 直接放进 motor loop，但它非常适合：

Conversation Plane
  ├─ continuous speech
  ├─ camera / video context
  ├─ interruption / clarification
  └─ tool / task request
        ↓
Typed Intent
        ↓
Robot Skill / Capability Gate
        ↓
Deterministic Navigation / Control

也就是说，语音和视频可以变成更自然的人机接口，但运动、安全和权限仍然应由独立运行时负责。

风险与边界

Google 明确列出 foundation-model hallucination、偶发 slowness / timeout 等限制。因此实时语音“听起来很自然”绝不能被等价成“工具参数一定正确”。机器人侧仍应该强制 intent confirmation、typed argument validation 和高风险动作 approval。

适合谁关注

远程机器人操作、巡检语音助手、多模态 HMI、现场维修 Agent、需要连续视频 + 语音交互的产品。

Gemini 3.8 Audio 官方模型卡

社区 / 社交平台 · Vibe Coding / AI 编程技巧精选

1. Review Agent 不要只“读 Diff”：让它真的跑 Build / Test / Targeted Script

来源：GitHub 2026-09-11 官方工程更新。

GitHub 最近升级 Copilot code review：review agent 不再只读文件，而是可以在 agent firewall 后使用更完整的 shell tools，主动执行 build、tests、targeted scripts，并调用可用工具/API 获取证据；Lite review 还改成多 Agent ensemble 后汇总。官方实验中，高严重度 finding 被开发者实际处理的平均数量提高 47%，中等提高 31%，低严重度提高 11%，review cost 约下降 8%。(GitHub Changelog)

技巧是什么： Reviewer 不应该只是第二个“会读代码的模型”，而应该拥有与 Maker 不同的证据源。

今天可以直接用： 给 Reviewer 固定执行：

git diff --check
项目 build
相关 unit test
受影响模块 lint / static check
一个 targeted runtime script

然后 Reviewer 才生成结论。

边界： 多 Agent ensemble 只有在 evidence 独立时才有价值；三个 Agent 都只看同一个 diff，并不会自动形成真正冗余。

2. Prompt Cache 命中率应该成为 Agent 基础设施指标，而不是“账单出来以后再猜”

来源：Reddit ClaudeCode 社区近期排查；属于社区经验。

近期用户追踪 Claude Code cache regression 时发现，subagent、tool result、hook 或 effort 改动会改变 request prefix，造成 cache miss。讨论里最值得留下的工程结论不是某个版本的 bug，而是：orchestrator 型 Agent 的 cache hit rate 本身应该被监控。(Reddit 讨论)

今天可以直接用： 把上下文分成：

稳定前缀：system / project rules / tools / long-lived specs
动态尾部：tool outputs / task state / logs / transient notes

尽量避免在长任务中频繁改稳定前缀；同时记录 cached_input / uncached_input / cache_miss_after_tool / subagent_resume_cost。

边界： Reddit 中的具体节省比例和账单感受属于用户经验，不应当成 Anthropic 官方 benchmark。真正可复制的是“稳定 prefix + 监控 cache telemetry”。

3. /rewind → /compact → /clear 不是宗教：真正要保留的是 Spec Map

来源：Reddit ClaudeAI / ClaudeWorkflows 社区经验。

社区最近整理了一种更细的 context hygiene：局部走偏时优先 /rewind 去掉无价值 flailing；一个边界明确的小任务需要短暂续命时才 /compact；跨阶段任务完成后 /clear 或新 session。真正要长期保存的不是压缩聊天，而是能冷启动的 spec map / plan / task artifacts。(社区整理)

今天可以直接用： 项目里保留：

ARCHITECTURE.md
DECISIONS.md
tasks/TASK-xxx.md
VALIDATION.md

每个新 session 只加载当前任务需要的节点，而不是把整个历史重新塞回 context。

边界： /compact 并非永远应该禁用。对单个短而封闭的任务，它仍比人工重建上下文方便；长期项目才更应该让 artifact 成为 source-of-truth。

经典论文回顾

g²o：为什么 SLAM 后端最终都可以被看成“顶点 + 边 + 稀疏非线性最小二乘”

Rainer Kümmerle、Giorgio Grisetti、Hauke Strasdat、Kurt Konolige 与 Wolfram Burgard 的 g²o: A General Framework for Graph Optimization 发表于 ICRA 2011。它并不是第一个 graph-SLAM 算法，但它把大量 SLAM、BA 和校准问题统一成可扩展的通用 C++ graph optimization framework，对后来的机器人软件工程影响非常大。(IEEE，官方代码)

核心问题

大量状态估计最终都可以写成：

x* = argmin Σ e_ij(x_i, x_j)^T Ω_ij e_ij(x_i, x_j)

其中：

Vertex
→ Pose / Landmark / Calibration / State

Edge
→ Odometry / Observation / Loop / Constraint

每条边只连接少量变量，所以整体 Jacobian / Hessian 是稀疏的。

算法模块

Graph Construction
      ↓
Vertices + Edges + Information
      ↓
Linearization around current state
      ↓
Sparse Normal Equations
      ↓
Gauss-Newton / Levenberg-Marquardt
      ↓
Sparse Linear Solver
      ↓
State Increment
      ↓
Repeat

g²o 的价值在于把“问题定义”和“求解器实现”分开。开发者可以新增 Vertex / Edge 类型，而不用为每个 SLAM 变体重新写一套优化器。

当年为什么重要

2011 年前后很多 SLAM 实现仍然是特定问题、特定数据结构、特定线性求解器的紧耦合代码。g²o 把 graph nonlinear least squares 做成一个通用库，并在多种真实 / 仿真 SLAM、BA 问题上取得与专用实现相当的性能。(IEEE)

今天仍然在使用的思想

虽然今天机器人团队常见的是 GTSAM、Ceres、Sophus + 自研后端，g²o 的几个思想几乎没有过时：

状态显式建模为变量节点
测量显式建模为因子 / 边
利用稀疏性
鲁棒核处理错误约束
不同变量类型通过统一优化接口组合

已被后续替代 / 扩展的部分

现代系统更强调：

  • iSAM2 / Bayes Tree 的增量更新；
  • Fixed-Lag smoothing；
  • IMU preintegration；
  • automatic differentiation；
  • factor marginalization / Schur complement；
  • GPU / parallel sparse solvers；
  • uncertainty-aware semantic / learned factors。

因此 g²o 不一定是新项目里最方便的后端，但它仍然是理解 graph optimization 软件结构最直接的教材之一。

可复现性

官方仓库仍然维护，C++17 + CMake，提供多种 SLAM / BA 示例和 Python 相关支持。需要注意 SuiteSparse / CHOLMOD 某些组件的许可证组合。(官方代码)

对今天工程项目的重新解读

今天 P-POSEMEM 的问题恰好说明：后端图不是“产生一次 pose 后就结束”的黑盒。

当 loop closure 改写历史、keyframe 被 marginalize 时，上层语义、任务和记忆系统必须理解图变量的生命周期。以后设计机器人系统时，建议明确区分：

State Variable ID
Current Estimate
Marginalized Representation
Derived World Coordinate
Semantic / Task References

上层不要永久引用某一时刻的 derived coordinate，而应该引用可随 graph state 重投影的稳定 identity。

原论文 DOI · g²o 官方仓库

今日结论

今天最明显的 SLAM 信号是：长期机器人系统不能再把“当前地图坐标”当成永久事实。 P-POSEMEM 把这个问题推进到了语义层：pose graph 发生 closure、marginalization 和压缩以后，语言查询仍然必须指向同一个物理对象。对现有 LIO-SAM / GTSAM 系统，这比再换一个前端更值得重视——所有语义、反光标志、任务点和人工标注都应该拥有稳定 identity 与可重投影的局部证据，而不是只存一个 map_xyz。

LiDAR 感知运动侧，JEPLO 展示了另一条路线：显式地图并不是四足 locomotion 的唯一中间表示。MID360 的 raw scan 可以先进入 predictive latent，再直接服务 policy。但这种“latent map”要真正进入产品，必须同步建设 runtime telemetry、导出一致性验证与独立安全边界，否则只是把地图错误变成更难观察的 latent 错误。

控制侧今天两篇工作非常互补。ResSafe 用 residual policy 把安全从 nominal policy 中解耦；MPC scaffolding 则用经典优化器解决真实 RL 最危险的早期探索。二者共同说明：学习系统不需要拥有所有权限。 传统控制、MPC、安全层和 policy 可以在不同训练阶段、不同运行时层级承担各自最擅长的部分。

无人机侧，Harmonic Field 与 Belief-Adaptive GNSS 也体现了同一趋势：规划器开始消费“整个空间的全局结构”，估计器开始显式消费“传感器信任状态”。未来导航栈里的状态变量会越来越丰富，不只是 pose / velocity，还包括 information quality、sensor trust、risk、energy 和 recoverability。

AI Coding 今天最值得保留的一条规则非常具体：

工具没有给出值
≠
模型应该自己补一个值

OK / FAILED / PARTIAL 这种看起来很朴素的 typed status，可能比再加几百字系统 Prompt 更有效。结合社区精选，成熟 Agent runtime 逐渐应该拥有：稳定 cached prefix、可冷启动的 artifact、可执行验证工具、明确失败状态和模型之外的 commit gate。

Gemini 3.8 Audio 则说明实时多模态 HMI 会继续成熟，但机器人架构里最重要的边界仍然不变：conversation plane 可以越来越自然，action plane 必须继续类型化、可验证、可拒绝。

最值得深入研究或尝试复现的方向

  1. Pose-Graph-safe Semantic Memory。 在现有 LIO-SAM / GTSAM 上给语义点、反光标志和任务点增加 birth_keyframe_id + local_measurement，每次后端优化后重新投影；专门构造 loop closure 前后 1–5 m 的历史位姿重写，测语义 identity 是否发生 flip。

  2. MID360 JEPLO A/B。 保留现有 elevation / traversability map 作为 safety baseline，同时跑 raw-MID360 → latent locomotion policy；重点测试长楼梯、中间转弯、遮挡和稀疏返回，并验证 TensorRT 导出前后的 recorded I/O 一致性。

  3. Nominal Policy + Residual Safety Policy。 不重训全部人形 / 四足策略，只训练一个小 residual 纠正 body roll、滑移和 joint-limit 三类状态；记录 intervention rate、residual norm、task score 和不可恢复状态比例。

  4. MPC Scaffold for Real RL。 将已有 MPC / impedance controller 的成功 trajectory 直接作为 replay warm start，在线阶段只在 policy uncertainty 或失败风险升高时调用 MPC；比较纯 SAC、BC→SAC 与 MPC-scaffold 三条路线的真实失败次数和训练墙钟时间。

  5. Agent ToolResult Typed Status。 给公司内部 Coding Agent 所有 search / build / test / database / Git 工具统一封装 OK | PARTIAL | FAILED，并要求任何事实输出绑定 evidence_id；对 stale、truncated、empty、timeout payload 做故障注入，统计 hallucinated value rate。

参考资料