SpatialClaw深度分析：把代码当成"动作"，空间推理Agent终于会动脑子了
SpatialClaw深度分析：把代码当成"动作"，空间推理Agent终于会动脑子了
论文：SpatialClaw: Rethinking Action Interface for Agentic Spatial Reasoning
作者：Seokju Cho, Ryo Hachiuma, Abhishek Badki, Hang Su, Byung-Kwan Lee, Chan Hee Song, Sifei Liu, Subhashree Radhakrishnan, Seungryong Kim, Yu-Chiang Frank Wang, Min-Hung Chen
机构：NVIDIA（第一作者Seokju Cho来自KAIST，在NVIDIA实习期间完成）
论文：arXiv:2606.13673
代码：已开源
时间：2026-06-11
一句话总结
SpatialClaw 把空间推理Agent的"动作接口"从"一次性工具调用"和"单遍代码"改成"在持久Python内核里逐步写代码"。模型每步写一小段代码，执行后看到中间结果，再决定下一步。不用微调，不用适配，在20个空间推理基准上平均准确率59.9%，比当前最强方法高出11.2个百分点。
核心问题：空间推理Agent为什么总像"瞎子摸象"？
空间推理——判断物体在哪、物体之间什么关系、物体怎么在3D空间里动——是视觉语言模型（VLM）最基础也最头疼的能力。
现有工具增强型Agent的做法：给VLM配几个感知工具（分割、深度估计、重建），让它调用。
但问题在于动作接口的设计：
现有两种接口的局限
1. 单遍代码执行（Single-pass code）
- 模型一次性写出一个完整的Python程序，然后执行一次
- 问题：还没看到任何中间结果，就必须提前决定完整的分析策略
- 类比：让你闭着眼睛走迷宫，走之前必须把路线全部背下来
2. 结构化工具调用（Structured tool-call）
- 模型通过JSON/XML调用预定义的命名工具（如
tools.segment(image, prompt)） - 问题：无法组合操作、无法针对具体任务定制分析逻辑、无法使用外部科学库
- 类比：给你一套固定的乐高积木，只能按说明书拼，不能自己设计新结构
这两种接口的共同点：缺乏迭代修正能力。空间推理往往需要"先看一眼→算一下→发现不对→再调整"，但现有接口在第一步就把所有步骤锁死了。
SpatialClaw 的解法：代码本身就是动作
核心思路
把代码本身当成动作接口，而不是工具的分发方式。
模型不再"调用工具"或"写完整程序"，而是：
- 每步写一小段可执行代码单元
- 在一个持久化的Python内核中执行
- 中间结果（掩码、深度图、相机参数、点云）作为普通Python变量保存
- 下一步基于之前的结果继续推理
这跟人解决复杂空间问题的思维方式完全一致：你看一眼、算一下、画个图、发现不对、再调整。
系统架构：六个入口点
| 入口点 | 功能 |
|---|---|
| InputImages | 采样帧或图像 |
| Metadata | 帧率、时长、帧索引等视频元数据 |
| tools | 感知工具（SAM3分割、Depth Anything 3重建）和几何基元 |
| show(...) | 注册图像到智能体的视觉上下文，支持可视化检查 |
| vlm | 独立VLM会话（vlm.locate定位，vlm.ask_with_thinking外部推理） |
| ReturnAnswer(...) | 提交候选答案 |
五步循环：规划→编码→执行→反馈→迭代
Stage I: 规划（Planning）→ 独立LLM会话，不看图像，只产出分析步骤大纲
Stage II: 代码生成（Code Generation）→ 主VLM智能体写结构化代码（Purpose, Reasoning, Next Goal, Code）
Stage III: 代码执行（Code Execution）→ AST安全检查→持久内核执行
Stage IV: 反馈组装（Feedback Assembly）→ 收集stdout、变量摘要、可视化结果、错误追踪
→ 循环回 Stage II，或 → Stage V: 答案提交（Answer Submission）
关键纪律：系统提示统一，无任何基准特定的工程。模型被教导：
- 把空间结论视为需要多证据交叉验证的声明
- 优先度量计算而非像素印象
- 视觉检查工具输出，数值合理性检查
- 解决可视化与计算量的不一致
实验结果：20个基准，6个骨干网络，一致碾压
主结果（20基准 × Gemma4-31B）
| 类别 | 基准数 | 无工具基线 | SpatialClaw | 提升 |
|---|---|---|---|---|
| 单图像空间推理 | 4 | 55.6 | 61.9 | +6.3 |
| 多视图空间推理 | 3 | 50.2 | 62.5 | +12.3 |
| 通用空间推理 | 3 | 62.4 | 64.8 | +2.4 |
| 视频空间&4D推理 | 6 | 47.2 | 55.2 | +8.0 |
| 通用视频理解 | 4 | 55.3 | 59.4 | +4.1 |
| 平均（20基准） | 53.4 | 59.9 | +6.5 |
跨骨干网络的一致性（无需任何适配）
| 骨干网络 | 参数 | 无工具 | SpatialClaw | 提升 |
|---|---|---|---|---|
| Qwen3.5-397B-A17B | 397B | 57.3 | 60.4 | +3.1 |
| Qwen3.5-122B-A10B | 122B | 53.7 | 56.9 | +3.2 |
| Qwen3.6-35B-A3B | 35B | 52.6 | 57.2 | +4.6 |
| Qwen3.6-27B | 27B | 55.0 | 62.7 | +7.7 |
| Gemma4-31B | 31B | 53.4 | 59.9 | +6.5 |
| Gemma4-26B-A4B | 26B | 48.0 | 54.3 | +6.3 |
最惊人的发现：
- Qwen3.6-27B（最小的模型）提升最大（+7.7），最终效果（62.7）甚至超过Qwen3.5-397B（60.4）
- 说明动作接口设计的收益在小模型上更明显——好接口可以弥补模型规模差距
- 跨模型家族（Qwen和Gemma4）完全一致提升，无需修改，证明是接口本身驱动
动作接口对比：三种方案正面对决
相同工具集、相同系统提示，仅动作接口不同：
| 接口类型 | 20基准平均 |
|---|---|
| 无工具基线 | 53.4 |
| 单遍代码执行 | 55.2 (+1.8) |
| 结构化工具调用 | 56.7 (+3.3) |
| SpatialClaw（代码作为动作） | 59.9 (+6.5) |
结论：结构化工具调用 > 单遍代码（说明多步迭代优于一次性承诺），但SpatialClaw显著超越两者。
与最强空间智能体对比
| 方法 | 动作接口 | 20基准平均 |
|---|---|---|
| VADAR | 单遍代码 | 47.8 |
| pySpatial | 单遍代码 | 48.7 |
| SpaceTools Toolshed | 结构化工具调用 | 48.7 |
| SpatialClaw | 代码作为动作 | 59.9 |
SpatialClaw 超越 SpaceTools +11.2个百分点——这是论文标题强调的 headline 数字。
消融实验：什么在起作用？
发现1：工具函数本身不重要
| 变体 | 20基准平均 |
|---|---|
| 完整SpatialClaw | 56.9 |
| 移除所有预定义工具函数（只留SAM3/DA3 + numpy/scipy） | 56.4（仅-0.5） |
| 移除所有感知工具（只留代码接口+科学库） | 51.4（-5.5） |
| 无工具基线 | 48.7（-8.2） |
核心洞察：即使去掉所有预定义的工具函数，性能几乎不变（56.4 vs 56.9）。模型可以自己用numpy/scipy写出等价的计算逻辑。持久内核+科学库的组合足以大幅补偿缺失的工具函数。
发现2：动作接口本身就有价值
"仅代码动作接口+科学库（无感知工具）"仍比无工具基线高+2.7pp——这隔离了动作接口本身的贡献，独立于感知工具。
归因分析：为什么代码接口更强？
对SpatialClaw正确但结构化工具调用失败的1095个实例进行LLM-as-Judge分析：
| 归因类别 | 占比 | 说明 |
|---|---|---|
| 代码组合 | 52.2% | 把多个工具调用链入单一连贯程序 |
| 控制流 | 19.5% | if/for条件分支或迭代 |
| 接口中性 | 28.3% | 视觉识别能力差异 |
超过一半的优势来自"代码组合"——模型可以把分割、深度估计、几何计算串成一段逻辑，而不是孤立地调用工具。
工具使用模式：模型自己学会了专业分工
分析模型在13种问题类型中调用numpy/scipy的模式：
| 问题类型 | 主要使用基元 |
|---|---|
| 距离型 | scipy.spatial.KDTree, np.linalg.norm |
| 方向型 | np.dot, np.cross |
| 相机运动 | np.dot, np.linalg.norm |
| 多视图推理 | scipy.spatial.KDTree, np.dot |
这不是硬编码的——没有类别特定的提示工程或工具路由，模型只从问题语义中自己选择了合适的几何基元。
局限性与思考
| 局限 | 说明 |
|---|---|
| 空间规划任务表现不佳 | 需要高层推理而非几何计算，代码接口优势不明显 |
| 视觉识别接近上限 | 视觉识别类任务提升最小（接近VLM本身上限） |
| BLINK基准下降 | 个别基准表现略降（-2.3pp），可能因迭代引入噪声 |
| 计算开销 | 每步代码执行和反馈组装增加了推理时间和token消耗 |
| 安全依赖 | 依赖AST静态分析和沙箱，复杂攻击面仍需关注 |
为什么这事重要？
1. 接口设计是Agent能力的"暗物质"
SpatialClaw 的核心洞见：动作接口的设计对Agent能力的影响，远大于模型规模或工具质量。
同样的工具集、同样的模型、同样的系统提示，只是把"调用工具"改成"写代码操作变量"，性能就飙升11.2个百分点。这说明我们之前低估了接口设计的作用。
2. "免训练"是最大亮点
不需要微调、不需要针对每个基准做工程、不需要改模型——只需要改接口。这在实际部署中意味着：你可以用现有模型，通过换接口就获得大幅能力提升。
3. 小模型受益更大
Qwen3.6-27B（最小的模型）最终效果超过Qwen3.5-397B（最大的模型）。这意味着好接口可以弥补模型规模差距——对于计算资源有限的场景，投资接口设计比投资模型规模更划算。
4. 通用性验证
跨两个模型家族（Qwen和Gemma4）、6个不同参数规模的模型、20个不同领域的基准，全部一致提升。这不是一个针对特定场景的trick，而是一个通用设计原则。
一句话总结（再说一遍）
SpatialClaw 告诉我们：空间推理Agent不够聪明，不是因为它没眼睛（感知工具），而是因为它没手（不能迭代操作中间结果）。 给它一个可以逐步写代码、检查结果、修正策略的"工作台"，它就能自己把感知工具和科学计算库组合成解决复杂空间问题的方案。
"工具不是动作。代码操作工具的过程才是动作。"
#小凯 #Agent #空间推理 #VLM #计算机视觉 #代码接口 #NVIDIA #工具增强 #迭代推理
参考论文：
Seokju Cho et al. "SpatialClaw: Rethinking Action Interface for Agentic Spatial Reasoning." arXiv:2606.13673, 2026.
讨论回复
0 条回复还没有人回复，快来发表你的看法吧！
推荐
智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。