Перейти к содержимому
Модели принятия решений в OpenClaw: как ускорить работу AI-агентов
7 мин чтения

Модели принятия решений в OpenClaw: как ускорить работу AI-агентов

openclawdecision-modelsai-agentsai-automationplugin-development
Смотрите беседу с Джошем Леманом на YouTube

При разработке AI-агента постоянно всплывают мелкие, но важные развилки. Какой инструмент подходит для этого запроса? Какие сообщения стоит оставить при сжатии контекста? Нужно ли агенту вообще отвечать — или в данном случае лучше не лезть в разговор?

На каждый такой вопрос можно отправить запрос языковой модели. Вот только это добавляет задержку и расходы к работе, ради которой пользователь, собственно, и пришёл. Когда агент принимает десятки подобных микрорешений, цена «ещё одного вызова» перестаёт быть пустяком.

На прошлой неделе Jev заставил многих разработчиков заново взглянуть на этот компромисс. Сегодня Джош Леман, мейнтейнер OpenClaw, объясняет, чем его зацепили модели принятия решений, как команда внедряет их в OpenClaw и почему самые любопытные сценарии, вероятно, найдёт именно сообщество.

Не просто ещё одна модель для диалога

Магия начинается, когда Jev встраивают в обычный детерминированный код.

Josh Lehman мейнтейнер OpenClaw

Первый эксперимент Джоша выглядел логично: он сделал плагин, который давал агенту инструмент для вызова Jev. Работало. Но получалась немного странная матрёшка: медленная языковая модель рассуждает о том, когда вызвать быстрый API.

Куда интереснее оказалось обращаться к модели напрямую из кода приложения.

Модель принятия решений получает набор фактов и критериев, а на выходе возвращает типизированный результат: вариант выбора, оценку либо вероятность того, что условие истинно. Приложению не нужно заказывать абзац рассуждений, а затем пытаться угадать, что с ним делать. Оно получает ответ, пригодный для следующего шага. Ошибки, конечно, никуда по щелчку не исчезают — чудес не обещали, — зато у разработчика появляется более узкий и управляемый интерфейс.

Jev, созданный Диогу Алмейдой и командой TypeSafe, заметно подогрел интерес к этому подходу:

Суть не сводится к тому, чтобы ускорить привычный вызов модели. Если суждение становится быстрым и недорогим, его можно применять там, где раньше об ИИ вообще не думали. Система принимает более точное решение, не превращая каждую развилку в новый чат.

Дать разработчикам рычаг, а не готовый список ответов

Необязательно ждать, пока мейнтейнеры OpenClaw решат, куда именно в вашу среду выполнения встроить модель принятия решений.

Josh Lehman мейнтейнер OpenClaw

Джошу не требовалось заранее составить исчерпывающий каталог мест, где такие модели принесут пользу. Достаточно было дать людям возможность попробовать — а дальше посмотреть, что приживётся.

В OpenClaw уже можно выбирать диалоговые модели. Та же логика применяется и здесь: модель принятия решений настраивается отдельно, а пользоваться ею могут и сам OpenClaw, и плагины. Такая ориентированная на плагины архитектура не запирает решение у одного поставщика. Адаптер TypeSafe работает как с облачным Jev, так и с локальным сервером System One, например с Kev Джареда Палмера; такой контур с локальными моделями мы разворачиваем и сопровождаем на управляемом хостинге.

Для авторов плагинов важнее всего единый API. Через Plugin SDK плагин вызывает api.runtime.decisions.evaluate и использует модель принятия решений, выбранную владельцем агента. Не нужно самостоятельно собирать интеграции с каждым провайдером. И пользователю не придётся настраивать один и тот же выбор по кругу — согласитесь, занятие не из весёлых.

Интерфейс уже доступен в версии development-checkout с новой поддержкой моделей принятия решений. Пакеты провайдеров ещё ждут релиза с соответствующей поддержкой; в документации по настройке описано, что работает сейчас и как начать эксперимент. Это фундамент для проб, а не заявление, что все возможные сценарии уже аккуратно упакованы в продукт.

Интерес к эксперименту заметен. Vercel сообщила, что Jev появился в AI Gateway быстрее любой предыдущей модели:

Эксперимент, а не обязательное обновление

Если её не включать — ничего страшного. Всё продолжит работать, как работало.

Josh Lehman мейнтейнер OpenClaw

Пока это ранняя стадия. Jev вышел совсем недавно, число альтернатив растёт, а команда ещё разбирается, в каких частях OpenClaw этот подход даст наибольшую отдачу.

Поэтому модели принятия решений подключаются только по желанию. После настройки они становятся доступными поддерживаемым функциям и плагинам; они не заменяют чат-модель, не запускают фоновые процессы и не переделывают агента без спроса. Без них OpenClaw тоже прекрасно работает.

Важно и другое различие: доступ к модели из кода приложения — это не то же самое, что инструмент, который агент может вызвать сам. Инструмент оценки переносится в ядро OpenClaw под названием decision_evaluate, поэтому он не будет привязан только к TypeSafe или Jev. Первый подход Джоша с плагином не был ошибкой. Он просто показывал лишь часть картины.

Цель практичная: улучшить результаты, сократить ожидание, снизить стоимость и уменьшить число повторных попыток в задачах, где такие модели действительно уместны. Проверять это придётся на реальных процессах. Новая модель сама по себе ещё не делает каждое решение умнее — было бы слишком удобно.

Разумеется, лента уже довела идею до абсурда:

OpenClaw не заменяет McDonald’s. Команде будет достаточно агента, который вовремя понимает: пора помолчать.

Что может сделать сообщество

Агент Питера по имени Molty живёт в Discord-сервере OpenClaw. По словам Джоша, у Molty есть привычка вклиниваться в беседы людей, которые к нему вовсе не обращались. Сначала ему предлагают замолчать, а потом тот же разговор повторяется позднее. Неловко. И вполне узнаваемо для многих команд.

Один из вариантов — перед ответом спрашивать отдельную модель, стоит ли агенту говорить. Но тогда перед уже небыстрым вызовом основной модели появляется ещё один вызов, потенциально для каждого сообщения в активном канале.

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

На момент записи разговора Джоша и автора статьи сообщество уже предложило почти 15 запросов на включение изменений с местами, где модели принятия решений можно применить в OpenClaw. Один из примеров — отбор определений инструментов и навыков, чтобы основной модели не приходилось тратить контекст на возможности, которые ей сейчас не нужны.

Среди других обсуждаемых направлений:

  • Курирование навыков: сделать частый анализ и объединение освоенных навыков достаточно дешёвыми.
  • Управление контекстом: находить ценные сообщения при сжатии контекста и точнее искать по прошлым диалогам. Это напрямую связано с тем, как выстроена контекстная инженерия агента.
  • Выбор модели: подбирать для новой задачи наиболее подходящую модель из тех, что настроил пользователь.

Это не перечень готовых функций, а карта для исследований. В этом и весь интерес: мейнтейнеру не нужно заранее угадать каждое полезное применение, а контрибьютору — ждать, пока кто-то напишет идеальную дорожную карту. Можно взять одну конкретную боль и проверить гипотезу. Без церемоний.

Приглашение к участию

Сейчас важнее всего делать вещи лучше и быстрее. Пользователям при этом вообще не придётся о чём-то думать.

Graham McBain OpenClaw Foundation

Для пользователя лучший исход может выглядеть почти незаметно. Агент отвечает быстрее, точнее находит нужный контекст или перестаёт перебивать людей. Название модели остаётся где-то под капотом; важно, что работа стала проще.

У разработчиков, напротив, немало пространства для действий. Можно участвовать в развитии OpenClaw или написать плагин, использующий настроенную пользователем модель принятия решений. Общий интерфейс существует именно затем, чтобы команда могла сосредоточиться на конкретном улучшении, а не на бесконечной обвязке провайдеров.

Тем, кому эта идея откликается, стоит зайти в Discord OpenClaw, найти обсуждения контрибьюторов и принести свой сценарий. Где сегодня приходится платить за медленное суждение? Что можно было бы автоматизировать, если бы оно занимало доли секунды и не било по бюджету?

Команда пока не знает всех ответов. Собственно, поэтому возможность и открывают.

Если тот же выигрыш по скорости и стоимости нужен не в эксперименте, а в рабочем продукте — подберём и затюним модели принятия решений под ваши сценарии.

Источник: openclaw.ai