Три критических пробела в OpenClaw для производственных ИИ-агентов

Основа OpenClaw против реальности продакшена

Разработчик OpenClaw, который создавал агентов для реальных систем, таких как CRM, Slack, электронная почта и базы данных, определил три пробела, которые отделяют демо-агентов от «настоящих ИИ-сотрудников». Источник отмечает, что хотя у OpenClaw есть правильная основа — инициатива, память и исполнение — эти пробелы мешают компаниям развертывать агентов на критически важных рабочих процессах.

1. Аудируемость

С текущими агентами OpenClaw действия происходят и результаты видны, но нет понимания, почему. Это проблематично в продакшен-сценариях, например, когда агент отправляет последующее сообщение потенциальному клиенту на $50 тыс. Разработчик утверждает, что без четкого аудиторского следа нельзя отладить сбои, улучшить поведение агента, объяснить решения своей команде или доверить агенту работу с более высокими ставками.

Что необходимо, согласно источнику:

• Журналы решений, а не только действий
• Следы рассуждений, доступные не инженерам
• Возможность запросить «Почему ты это сделал?» простым языком

2. Детальный контроль действий

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

Что необходимо, согласно источнику:

• Разрешения на уровне действий (например, агент может создавать черновики, но не отправлять)
• Контроль на основе пороговых значений (автоматическая отправка до $5 тыс., требование утверждения свыше $5 тыс.)
• Правила эскалации (если уверенность ниже X%, спросить человека)
• Эволюция разрешений со временем

3. Разрешение инструкций

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

Что необходимо, согласно источнику:

• Иерархия инструкций (политика компании > правила команды > индивидуальные предпочтения)
• Обнаружение конфликтов (агент определяет, когда две инструкции противоречат друг другу)
• Протокол уточнения (агент запрашивает разрешение вместо догадок)
• Наследование приоритета (в случае сомнений следовать инструкции более высокого авторитета)

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