精读笔记

Problem Setting

这篇论文真正处理的是 LLM-based embodied agent 的 runtime problem，而不是单个 planning algorithm problem。机器人已经有一批可调用 skill，LLM 也能把自然语言目标翻译成 skill sequence；真正卡住的是当这个过程进入真实执行闭环后，模型调用延迟、物理资源互斥、多任务抢占、快速安全反应之间彼此冲突。

以前路线的核心瓶颈很清楚：monolithic plan-and-execute 把计划质量押在一次调用上，first action 慢，而且环境变化后容易失效；ReAct / step-by-step planning 有闭环，但每个动作之间都要等一次模型，机器人会出现显著停顿；VLA 或 learned policy 可以降低低层控制延迟，但并不自然解决多个 high-level goals 争抢同一身体的问题。

这里的关键矛盾是：高质量语义规划需要慢模型和较长上下文，真实 embodied execution 需要连续控制、可抢占、低延迟反馈。TypeGo 的问题设定因此更接近“如何给 LLM agent 做一个实时、多任务、资源受控的 runtime”，而不是“如何让 LLM 更会规划”。

Motivation

作者的核心观察是：把 LLM 放在 critical path 上，本质上和实时 embodied control 不相容。即便未来单次推理更快，机器人仍然会面对多任务、资源互斥、安全反应和长期运行状态管理，这些不是单纯模型加速能解决的问题。

已有路线缺的是 runtime 层抽象。机器人系统里低层 skill 往往已经是工程上可用的，问题是如何把这些 skill 组织成持续运行的行为系统：什么时候开始执行、什么时候预取下一步、什么时候丢弃旧计划、谁能抢占谁、抢占后是否恢复、哪些规则必须绕过 LLM 直接触发。

因此 TypeGo 不是从“更聪明的 planner”出发，而是从 OS analogy 出发：把 task 看成 program，把运行中的 task 看成 process，把身体资源看成 devices，把 reflex 看成 interrupt handler。这一动机是合理的，因为 embodied agent 的困难很大部分确实是 scheduling / arbitration / isolation，而不是单个 prompt 的表达能力。

Core Idea

TypeGo 的核心思想是把 LLM planning 从同步的问答式控制改造成持续运行的异步 runtime。LLM 不再是每一步动作前必须等待的 oracle，而是在不同时间尺度上持续产生、修正和仲裁行为意图；执行层则消费这些意图，并通过 Skill Kernel 管理物理资源。

这个建模方式引入了一个很强的 inductive bias：慢语义决策和快物理执行应该解耦。S2/S3 可以慢慢更新任务分解和调度策略，S1 可以提前流式生成少量候选 skill，S0 则完全绕过 LLM 处理低延迟 reflex。信息流从“observe -> prompt -> act -> wait”变成“observe 被多个 cadence 的 loop 异步消费，action queue 持续供应执行”。

它和 prior 的本质区别不是层级规划本身，而是 runtime 化：计划不是一次性 artifact，也不是每步重新生成的 transient output，而是一个可被暂停、恢复、替换、预取和抢占的过程状态。这个改变使系统更 scalable 的原因在于，它把 latency hiding、resource arbitration 和 task lifecycle 变成统一机制，而不是每个 demo 里手写控制逻辑。

Method

1. Speculative skill streaming：解决 step-by-step LLM planner 的动作间停顿。S1 在当前 skill 执行时提前生成一个 bounded queue 的后续 skill calls，执行器消费队列，streamer 后台补齐。bounded lookahead 是关键，因为它在 latency hiding 和 closed-loop adaptivity 之间折中：看得太远会退化成 open-loop plan，看得太近又会重新暴露 LLM latency。

2. Multi-cadence planning：解决单一 planner 同时承担长期语义、局部动作和快速反应时的 cadence mismatch。S3 慢速做 process-level scheduling，S2 做 task decomposition，S1 做 action streaming，S0 做 reflex。核心变化是每类决策只在它能承受的延迟范围内发生，而不是把所有决策都塞进同一个 LLM loop。

3. Skill Kernel：解决多个 process 竞争同一物理身体的问题。它把 skill 绑定到 typed subsystems，例如 movement、sound、default，并用 exclusive/shared/parallel policy 控制是否能并发。这个机制的必要性在于 embodied agent 的资源不是抽象 token，而是有物理互斥和安全后果的 actuator。

4. Source-dependent scheduling：解决 flat priority 不能表达“抢占后是否恢复”的问题。用户新任务通常替换旧用户任务，reactive process 则 interrupt-and-return。这里的贡献不是复杂调度算法，而是指出 embodied runtime 需要把 preemption semantics 显式编码进 task lifecycle。

5. Natural-language reflex compilation：解决低延迟安全规则不能等待 LLM 的问题。reflex 由自然语言离线编译成 Python condition/action，在 S0 高频执行。这个设计把用户可编程性和实时性分开：自然语言用于 authoring，不用于 reaction path。

Key Insight / Why It Works

TypeGo 有效的主要原因不是 LLM 更会推理，而是系统性地把 LLM latency 从 critical path 上移走。动作执行本身通常持续数百毫秒到数秒，这段时间可以用来生成后续动作；只要 skill duration 大于或接近 LLM planning latency，speculative queue 就能显著减少动作间空转。这是典型的 test-time compute overlap，而不是模型能力突破。

最核心贡献可能是“bounded speculation + runtime preemption”的组合。单纯提前生成 plan 会损失闭环，单纯每步闭环会损失实时性；TypeGo 的 bounded queue 让系统只向前承诺很短一段，并允许 S2/S3/S0 打断。这给 LLM planner 加了一个很实用的 operating envelope：它可以错，但错的影响范围被 queue length、skill boundary 和 preemption policy 限制。

Skill Kernel 的价值在于把 embodied concurrency 从 prompt problem 变成 resource management problem。让 LLM 判断两个任务能否同时执行并不可靠；把 skill 的 subsystem requirement 显式声明出来，runtime 就可以用结构化约束过滤掉一类明显危险的并发。这是 better inductive bias，不是 scaling。

S3 semantic scheduling 则是更脆弱的一环。它试图用 LLM 的场景理解做调度策略，这在 demo 任务中很自然，但没有形式化保证。这里的“semantic scheduling”可能更多是 prompt-level policy execution，而不是一个可验证 scheduler。文中未充分说明当多个用户、长期目标、安全规则、模糊优先级冲突时，S3 如何稳定决策。

S1P fast first-action path 的收益需要谨慎看待。它带来明显 TTFA 改善，但论文也承认 first action 只在约 60% 情况下匹配最终计划。也就是说它部分是在优化 perceived responsiveness，而不一定是优化 task optimality。对于社交机器人或 quadruped demo 这可能很有价值，但在高风险 manipulation 中可能不可接受。

总体上，这篇的有效性来自 runtime architecture、latency hiding、结构化资源约束和额外 token budget。不是 retrieval，不是 memory reuse，也不是训练出新的 representation；也不能说证明了 LLM 具备更强长期 planning。它更像把已有 LLM planning 能力放进一个更合适的执行组织方式里。

Relation To Prior Work

最接近的谱系有三条：经典三层机器人架构、LLM-based robot planning、LLM agent OS。TypeGo 的新意在于把这三条线接在一起，而不是单独在某一条线上推进。

相对经典 deliberator-sequencer-controller 架构，TypeGo 并不新在层级本身；新在每层由 LLM/prompt 驱动，并且多个层不是严格串行，而是异步并行运行。同时它加入了 S0 reflex 和 S3 scheduler，使系统从单任务层级控制扩展到多任务 runtime。

相对 SayCan / ReAct / Inner Monologue 这类 step-by-step planner，TypeGo 的本质差异是 decouple planning latency from action boundary。ReAct 的闭环发生在每个动作前，因此机器人停顿不可避免；TypeGo 试图在动作执行期间完成下一步推理。相对 Code-as-Policies / TypeFly / PAE，TypeGo 又避免完全 open-loop，把 lookahead 限制在短队列并允许上层改写。

相对 AIOS / MemGPT 这类软件 agent OS，TypeGo 的不同点在 embodied workload：资源不是上下文窗口或 API slot，而是 actuator、传感器、身体姿态和安全边界。这个差异是实质性的，因为 physical preemption 有真实后果，不能只靠请求队列管理。

看似新的部分里，OS analogy、process/PCB、interrupt handler 都是已有概念迁移；实质创新在于把这些概念落到 LLM-controlled embodied agent 的 latency 和 resource arbitration 上，并给出一个能在真机上运行的最小闭环。

Dataset / Evaluation

评估是小规模真机 prototype validation，而不是强 benchmark。任务覆盖显式命令、开放搜索、失败报告、并发插入、memory query 和 reflex 触发，能覆盖论文 claim 的几个关键路径：responsiveness、closed-loop failure handling、resource contention 和 preemption。

优点是真机部署在 Unitree Go2 上，不是纯模拟；baseline 共享 skill library，因此部分隔离了低层能力差异。结果支持一个有限结论：在 skill duration 足够长、任务结构较简单、资源类型较少的 embodied setting 中，异步流式规划可以降低等待时间，OS-style arbitration 可以管理简单并发。

但 evaluation 没有充分验证 generality。任务只有 10 trials per task，环境复杂度有限，主要 exclusive resource 是 movement；这对 Skill Kernel 是最友好的情况。T4 中 PAE 反而更好，暴露了局部 step planner 的 greedy bias，也说明 S1/S2 split 并没有真正解决 long-horizon global planning。

并发实验更像机制 sanity check：T6/T7/T8 分别测试串行抢占、并行查询、S0 reflex，但没有压力测试多 process、多资源、多冲突、多轮恢复。baseline 不能处理中途任务，所以并发部分缺少强对照。文中 claim “admitting concurrent tasks at low overhead”在这个范围内成立，但不能外推到复杂多机器人或 humanoid manipulation。

Limitation

第一，系统强依赖 developer-authored skills。TypeGo 只在 skill 已经可靠、可中断、语义描述清楚、subsystem 声明正确时成立。真正困难的低层控制、安全 envelope、failure detection 被转移到 skill authoring 和 observation pipeline 中。

第二，bounded interruption 是关键前提，但文中没有充分说明如何系统验证每个 skill 的 interrupt latency 和 interruption correctness。对 quadruped 的 move/rotate/search 这类 skill 尚可处理；对 manipulation、tool use、接触丰富任务，暂停和恢复可能本身就是难题。

第三，semantic scheduling 缺少可验证性。S3 通过 LLM 和 prompt guideline 判断任务冲突与优先级，这在开放场景中容易受 wording、observation serialization、模型随机性影响。这里把调度问题从 hard-coded priority 转成 LLM judgment，并不等于解决了调度正确性。

第四，增益归因不清。TypeGo 使用多个异步 LLM loop、更多 token、更复杂 runtime、快速 first-action path；相比 ReAct/PAE 的优势可能主要来自更多 test-time compute 和 latency overlap。论文没有做足够 ablation 来分离 S1 queue、S2 decomposition、S3 scheduling、S1P fast path 各自贡献。

第五，长期状态建模仍然不足。论文把 memory 放到 future work，当前 memory 更像 queryable service，不是 OS primitive。没有强 memory 层时，所谓 long-lived embodied agent 还停留在短任务 runtime，而不是跨小时/跨天的持续 agent。

第六，规划能力可能仍然是局部的。T4 失败模式说明 TypeGo 会被当前可见线索吸引，未必形成全局搜索策略。这里的“planning”更像短视 action streaming 加周期性修正，不应被解读为解决了 LLM long-horizon planning。

Takeaway

• 1. 对 embodied LLM agent，真正值得优化的不只是单次模型调用，而是 planner 与 execution 的时序关系。
• 把慢规划 overlap 到动作执行期间，是比单纯换更快模型更通用的系统杠杆。
• 2. 物理资源应该结构化暴露给 runtime，而不是让 LLM 在自然语言里隐式理解“哪些动作能并发”。
• typed subsystem / skill declaration 是一个可迁移 insight，尤其适合 mobile manipulation、multi-tool agent 和具身多任务系统。

一句话总结

TypeGo 是一篇把 LLM 机器人规划从 prompt-level planner 推向 OS-style embodied runtime 的早期系统论文，真正贡献在于用异步多时间尺度、短视 speculative execution 和结构化资源仲裁重组了 LLM 与物理执行之间的信息流。