Задача простая: определить, движется ли машина к камере, или найти ближайший к столу объект. Для человека — мгновенно. Для Vision-Language Model (VLM) — головная боль. Современные модели вроде Qwen3.5 и Gemma4 справляются с фактическими вопросами, но пространственные задачи требуют составления геометрических аргументов из depth, camera pose и temporal correspondence — и здесь VLMs ломаются. Естественное решение: дать модели инструменты (детекторы, сегментаторы, depth-оценщики). Но исследователи из команды SpatialClaw обнаружили, что не инструменты решают всё, а интерфейс, через который они вызываются. Их фреймворк заменяет структурированные JSON-команды и одноразовые скрипты на Python-код в персистентном ядре — и получает +18.3% на видео-задачах и +14.3% на многовидовых сценариях без какого-либо дообучения модели.

Что такое SpatialClaw

SpatialClaw — это фреймворк для агентного пространственного рассуждения, который использует код как action interface. Вместо того чтобы вызывать заранее определённые команды через JSON или XML, агент пишет Python-код в персистентном ядре, исполняет его пошагово, видит промежуточные результаты (маски, depth-карты, графики) и корректирует стратегию на лету. Это меняет саму логику взаимодействия: агент не «заказывает» операции у внешнего API, а «мыслит» в пространстве программы, где визуальные данные — обычные переменные, доступные для инспекции и композиции.

Ключевой инсайт: способность tool-augmented агента зависит не только от набора инструментов, но и от action interface — способа их вызова, представления выходных данных и наблюдаемости промежуточных состояний. До SpatialClaw существовало два подхода. Первый — одноразовый код: агент пишет полную Python-программу, запускает её один раз и использует результат. Программа может выражать задачу-специфичные вычисления, но должна зафиксировать стратегию до того, как увидит любую промежуточную маску, depth-карту или ошибку выполнения. Механизм retry может починить синтаксис, но промежуточные визуальные данные не участвуют в цикле рассуждения. Второй — структурированные tool-calls: агент вызывает модули восприятия по имени, передавая типизированные входы и получая типизированные выходы через предопределённые команды (JSON, XML). Это даёт чистый интерфейс для вызова, но композиции, которые можно определить только во время тестирования — например, цепочки геометрических преобразований, зависящие от промежуточных результатов — требуют предвидения разработчиком интерфейса.

SpatialClaw предлагает третий путь: персистентное ядро с пошаговым исполнением. Агент пишет один исполняемый кодовый cell за раз. Каждый cell может создавать маски, реконструкции, графики или числовые summaries, и результирующее состояние программы остаётся доступным для последующих cells. Следующее действие обусловлено текстовым выводом, summaries переменных и отрендеренными промежуточными изображениями из предыдущих шагов. Это создаёт замкнутый цикл: планирование → генерация кода → исполнение → обратная связь → коррекция.

Три action interface: сравнение подходов

Исследователи формализуют три подхода к вызову инструментов для пространственного рассуждения. Без интерфейса — VLM генерирует chain-of-thought на естественном языке прямо над входными изображениями, без внешних вычислений и промежуточных данных. Это работает для простых задач, но проваливается при необходимости точной геометрической композиции. Одноразовый код — агент пишет полную программу, запускает её один раз, получает результат. Гибкость есть, но нет возможности адаптироваться к промежуточным данным: если depth-карта показывает неожиданную структуру, агент этого не увидит до финального ответа. Структурированные tool-calls — агент вызывает предопределённые операции через JSON/XML. Чистый интерфейс, но ограниченная выразительность: всё, что не предусмотрено разработчиком, сделать невозможно.

SpatialClaw объединяет гибкость кода с наблюдаемостью промежуточных состояний. Агент пишет Python-код в персистентном ядре, предзагруженном входными кадрами и набором примитивов: perception-модули (depth estimation, segmentation) и scientific libraries (NumPy, SciPy, Matplotlib). Каждый cell создаёт объекты, которые остаются в памяти как обычные Python-переменные. Следующий cell видит stdout, summaries переменных и отрендеренные изображения из предыдущих шагов. Это позволяет агенту не просто «выполнить вычисление», а «исследовать пространство данных» — проверить гипотезу, увидеть результат, скорректировать подход.

Архитектура: персистентное ядро и пятиступенчатый цикл

SpatialClaw состоит из двух компонентов: персистентное ядро рабочего пространства и внешний агентный цикл, координирующий планирование, генерацию кода, сбор обратной связи и ответ.

Персистентное ядро инициализируется один раз для примера и уничтожается после завершения. Оно хранит все промежуточные результаты как обычные Python-переменные, так что любой объект, созданный во время выполнения, остаётся доступным для последующих cells. Это фундаментально отличается от одноразового подхода: в одноразовом коде переменные живут только внутри одной программы, а в SpatialClaw они персистируют между итерациями. Ядро предзагружено входными кадрами и perception-примитивами, включая SAM3 для сегментации и DA3 для depth estimation, а также scientific libraries. Агент не ограничен заранее определённым набором операций: любая композиция, которую можно выразить на Python, становится доступной — включая импровизированные алгоритмы, которые разработчики не могли предвидеть.

Внешний агентный цикл состоит из пяти стадий. Стадия I — Планирование: планировщик получает вопрос и документацию по инструментам, но не изображения, и производит аналитический план. Это отделяет стратегию от данных: планировщик думает о том, какие операции нужны, не будучи отвлечённым визуальным шумом. Стадия II — Генерация кода: основной агент генерирует Python-cell для исполнения в персистентном ядре. Стадия III — Исполнение: код выполняется, создавая маски, реконструкции, графики или числовые summaries. Стадия IV — Сбор обратной связи: stdout, summaries переменных и изображения, зарегистрированные через show(), добавляются к контексту модели. Стадия V — Ответ: цикл продолжается до тех пор, пока агент не подаст ответ через ReturnAnswer() или не исчерпает лимит шагов N_max = 30.

Ключевое ограничение: системный prompt требует дисциплинированного рассуждения. Агент не может просто «попробовать и посмотреть» — он должен следовать плану, документировать шаги и обосновывать каждую операцию. Это предотвращает блуждание в пространстве кода и гарантирует, что каждый шаг вносит измеримый вклад в решение.

Результаты: +18.3% на видео и +14.3% на многовидовых сценариях

Оценка проводилась на 20 бенчмарках пространственного рассуждения, охватывающих single-image spatial reasoning (ERQA, OmniSpatial, SPBench), multi-view spatial reasoning (MindCube, MMSI, SPAR-Bench), general spatial reasoning (BLINK, SpatialTree, ViewSpatial), video spatial & 4D reasoning (DSI-Bench, OSI-Bench, PAI-Bench) и general video understanding (CV-Bench, PerceptionComp, VideoMMEv2). Для сокращения вычислений большие бенчмарки сэмплировались до 1000 примеров; N_max = 30 для всех бенчмарков.

SpatialClaw последовательно улучшает no-tool baseline на всех шести backbone-моделях, с наиболее выраженными gains на video spatial & 4D reasoning (DSI-Bench, avg +18.3%p) и multi-view spatial reasoning (MindCube, avg +14.3%p) — категориях, которые больше всего выигрывают от итеративного многошагового геометрического вычисления через кадры и viewpoints. Эти gains сохраняются на моделях от 26B до 397B параметров без какой-либо модификации, что указывает на генерализуемость дизайна для будущих моделей без model-specific tuning.

Сравнение с альтернативными action interfaces (Tab. 3) показывает, что SpatialClaw последовательно превосходит и Structured tool-call, и Single-pass Code на всех бенчмарках, с наибольшими gains на задачах, требующих многошаговой геометрической композиции. Наибольший margin — над SpaceTools (+11.2%p в среднем). Среди baseline'ов SpaceTools занимает наивысшее место, что согласуется с предыдущими результатами. SpatialClaw дополнительно улучшает оба action interface на всех evaluated setups.

Сравнение с recent spatial agent methods (VADAR, pySpatial, SpaceTools) на одном и том же Gemma4-31B backbone показывает, что SpatialClaw превосходит все baseline'ы на всех бенчмарках. VADAR и pySpatial относятся к категории single-pass code, а SpaceTools использует structured tool-call interface. SpatialClaw достигает наибольшего margin над SpaceTools, что подтверждает: выразительный action interface важнее, чем просто «правильный» набор инструментов.

Почему это работает: три находки

Finding 1: генерализация без utility-функций. Абляционное исследование (Tab. 4) показывает, что SpatialClaw работает даже без предопределённых utility-обёрток (tools.Mask, tools.Geometry). В варианте (I) оставляют только core perception tools (SAM3/DA3) и scientific libraries (numpy, scipy) — и производительность остаётся на уровне полного SpatialClaw. Это означает, что персистентное ядро с scientific primitives может компенсировать отсутствие utility-функций: агент сам строит нужные операции из базовых блоков. В варианте (II) убирают даже perception tools, оставляя только code-as-action interface с scientific libraries — и получают +2.7%p над no-tool baseline. Это изолирует вклад самого action interface, независимо от perception tools.

Finding 2: спонтанная адаптация к типу вопроса. Анализ частоты использования primitives (numpy и scipy операций) показывает, что агент сам адаптирует композицию инструментов под тип вопроса: distance-вопросы предпочтительно вызывают KD-tree search и norm-операции, а direction-вопросы полагаются на dot products. Это не запрограммировано — агент сам «открывает» эти паттерны через использование. Heatmap использования primitives across 13 meta-категорий показывает чёткую специализацию: depth estimation использует одни операции, relative direction — другие, camera motion — третьи. Это подтверждает, что code-as-action interface позволяет агенту выражать задачу-специфичные вычисления, которые разработчики не могли предвидеть.

Finding 3: gains концентрируются там, где нужна цепочная геометрическая композиция. Сравнение SpatialClaw с Structured tool-call и Single-pass Code across 13 meta-категорий показывает, что наибольшие gains — в категориях, требующих cross-step composition и revision через кадры и viewpoints. Там, где gains меньше, bottleneck — качество perception: visual recognition задачи уже near-saturated backbone VLM, оставляя мало места для interface-level gains. Вместе это подтверждает, что выразительный action interface — primary driver производительности, а не model capacity или tool coverage.

Практические выводы

SpatialClaw меняет способ, которым мы думаем об агентных системах для пространственного рассуждения. Традиционный подход: «дай агенту больше инструментов и лучше API». SpatialClaw показывает, что интерфейс важнее инструментария: тот же набор perception-модулей через code-as-action interface даёт +11.2%p по сравнению с structured tool-call, и +2.7%p даже без perception tools вообще — только с numpy и scipy.

Это имеет прямое отношение к проектированию агентных систем. Если вы строите агента для работы с пространственными данными — не тратьте всё время на расширение меню tool-calls. Вместо этого дайте агенту персистентное вычислительное пространство, где он может компоновать, исследовать и корректировать. Python-код в ядре — не просто «еще один способ вызвать API», а принципиально другая парадигма: агент не заказывает операции, а мыслит в пространстве программы.

Для робототехники и автономного вождения это особенно важно. Существующие VLA-модели (о которых мы писали в постах о LaST-R1 и хрупкости VLA-рассуждений) страдают от статичного имитационного обучения и не могут адаптироваться к неожиданным сенсорным условиям. SpatialClaw показывает, что адаптивность может прийти не от более сложной модели, а от более гибкого интерфейса между моделью и миром. Если робот может «подумать» в пространстве кода, проверить гипотезу через исполнение и скорректировать траекторию на основе промежуточных данных — он становится устойчивее к неопределённости, чем робот с фиксированным pipeline perception → planning → control.

Часто задаваемые вопросы

Чем SpatialClaw отличается от одноразового Python-кода?

Одноразовый код фиксирует стратегию до исполнения: агент пишет полную программу, запускает её, получает результат. Если промежуточные данные неожиданны — например, depth-карта показывает другую структуру, чем ожидалось — агент этого не узнает до финального ответа. SpatialClaw исполняет код пошагово, видит промежуточные результаты (маски, графики, числовые summaries) и корректирует следующий шаг на их основе. Это замыкает цикл рассуждения на реальные данные, а не на предположения.

Нужны ли специальные tool-calls, если есть Python-код?

Абляционное исследование показывает, что SpatialClaw работает на уровне полной версии даже без предопределённых utility-функций (tools.Mask, tools.Geometry), оставляя только core perception tools (SAM3/DA3) и scientific libraries (numpy, scipy). Агент самостоятельно строит нужные операции из базовых блоков. Это означает, что предопределённые tool-calls полезны, но не критичны: гибкость code-as-action interface компенсирует отсутствие заранее заготовленных обёрток.

Работает ли это только для пространственных задач?

Исследование фокусируется на пространственном рассуждении, но принцип code-as-action interface применим к любой области, где требуется итеративная композиция промежуточных результатов. Scientific computing, data analysis, robot planning — везде, где агенту нужно «подумать», проверить гипотезу, увидеть результат и скорректировать подход, персистентное ядро с пошаговым исполнением даёт преимущество над одноразовыми скриптами и структурированными командами.

Итог

SpatialClaw доказывает, что в агентных системах интерфейс важнее инструментария. Тот же набор perception-модулей через code-as-action interface даёт +11.2%p по сравнению с structured tool-call, а персистентное ядро с numpy и scipy — без perception tools вообще — даёт +2.7%p над no-tool baseline. Это меняет экономику проектирования агентов: вместо того чтобы расширять меню API-вызовов, разработчики могут дать агенту вычислительное пространство и позволить ему самостоятельно открывать нужные композиции. Для робототехники, автономного вождения и любых систем, где агент взаимодействует с физическим миром через сенсоры, это означает переход от «заказных» pipeline'ов к «исследовательским» агентам, которые могут адаптироваться к неожиданным условиям, проверяя гипотезы в реальном времени.