Как я собрал skill для подключения хайпового OpenClaw к Битрикс24 и зачем это вообще маркетологу
Меня зовут Саша Вартанян, я занимаюсь маркетингом в Битрикс24. По профессии я не разработчик и даже не тестировщик. Из кода у меня - какие‑то давние попытки собрать компоненты для сайтов и смутное понимание того, как ходят запросы по REST API. Но в какой‑то момент захотелось не просто рассуждать о будущем AI-агентов, а руками сделать что‑то вполне прикладное.
Так родился skill, который позволяет подключать OpenClaw (и другие совместимые агенты) к Битрикс24 "по‑умному" - через REST, с нормальной структурой, а не через пару случайных хаков. Начиналось всё как вайб-кодинг на выходных, а в итоге превратилось в рабочий инструмент, который можно реально запускать в бою.
Честно: процентов на 90 код собирали Codex и Claude, а я выступал продакт-менеджером, интегратором и человеком, который знает, как живут пользователи Битрикс24 и что им от агента нужно. Но зато именно такой путь - без глубокого инженерного бэкграунда, зато с пониманием задач бизнеса - хорошо показывает, что подобные интеграции сегодня доступны не только "сеньорам с десятью годами бэкенда".
---
Зачем маркетологу вообще что-то кодить под OpenClaw
Последние пару лет я внимательно наблюдаю за темой AI-агентов: как обычный пользователь и как человек, который отвечает за продукт и маркетинг. Видно, что будущее - за системами, где агент не просто болтает, а реально работает внутри ваших инструментов: CRM, задач, чатов, документов.
Стратегически всё ясно:
- агент должен уметь ходить в данные,
- запускать бизнес-процессы,
- создавать и менять сущности в CRM,
- общаться с клиентами в привычных каналах.
Но пока у тебя нет живого, осязаемого сценария в своём рабочем окружении, это остаётся абстракцией. И вот здесь случился OpenClaw - модная, шумная платформа агентов, которую многие уже видели, а кто‑то успел потыкать.
Идея, которая меня зацепила: превратить OpenClaw в реального "виртуального сотрудника" внутри Битрикс24. Не отдельную игрушку, а участника бизнес-процессов. Чтобы можно было сказать ему человеческим языком:
- "Создай сделку на этого лида и привяжи контакт, если его ещё нет"
- "Проверь, у кого на следующей неделе просроченные задачи по крупным клиентам, сделай отчёт и разошли руководителям"
- "Поставь встречу завтра в 15:00 с Сергеем Рыжиковым в ближайшее свободное время и приложи туда последний коммерческий оффер"
Агент должен сам:
- понять запрос,
- найти нужные методы REST API,
- корректно выстроить цепочку вызовов,
- не забыть про авторизацию,
- и не накосячить с полями и сущностями.
Технически всё для этого есть:
- Битрикс24 даёт обширный REST API, вебхуки и OAuth;
- OpenClaw умеет работать с форматом skills.
Оставалась "мелочь": реализовать это так, чтобы агент не захлебнулся в сотнях методов API и не превратился в источник галлюцинаций.
---
Что такое skill в мире OpenClaw и зачем он нужен
Если говорить неформально, skill в экосистеме OpenClaw - это "расширение мозга" агента. По сути это папка с файлами, где:
- описано, какие у него есть способности;
- какие действия он может выполнять;
- какие есть ограничения;
- какие есть готовые шаблоны цепочек запросов.
Ключевой файл - `SKILL.md`. В нём:
- YAML-метаданные (название, версия, автор, поддерживаемые capability packs);
- текстовые инструкции на естественном языке;
- базовая логика: с чего начинать, какие файлы подгружать в каких случаях.
К skill можно прикрепить:
- справочные файлы с краткими описаниями методов REST;
- файлы с готовыми "цепочками" (chains), где расписано: сначала вызови метод А, потом Б, потом обработай ответ;
- вспомогательные скрипты, если агент умеет ими пользоваться.
Сценарий работы выглядит так:
1. Агент получает задачу от пользователя.
2. Смотрит в `SKILL.md`, понимает, какие вообще у него есть возможности.
3. Подгружает нужные capability packs / файлы.
4. Находит подходящую инструкцию или цепочку.
5. Выполняет действия через REST API, опираясь на проверенное описание, а не на память или поиск в интернете.
За счёт этого skill превращается в "рамки и рельсы", по которым агент едет, не проваливаясь в бессмысленные догадки, как называется метод или какой формат у полей.
---
Почему нельзя просто "скормить" агенту всю документацию REST
Полный REST API Битрикс24 - это сотни методов и тысячи строк документации. Если просто закинуть всё это в контекст агента, получится несколько проблем:
- Контекстное окно не бесконечное, а токены стоят денег.
- Чем больше мусора в памяти, тем выше риск, что модель начнёт путаться и "придумывать" названия методов или параметры.
- Агенту в конкретный момент времени нужно 5-10 методов, а не весь арсенал.
Мне нужно было решение, где агент:
- стартует с минимального, но полезного набора возможностей;
- может догружать нужные блоки знаний по мере необходимости;
- не сваливается в состояние "я знаю всё, но не помню, что именно".
Отсюда родилась идея разбить всё на capability packs - логические "модули" внутри skill.
---
Capability Packs: зачем резать всё на пакеты
Capability Pack - это самостоятельный блок возможностей, оформленный как отдельный файл или группа файлов. Каждый пакет описывает конкретную область работы Битрикс24, а агент подключает его только тогда, когда это реально нужно.
Основные пакеты у меня получились такими:
- core
- базовый CRM: лиды, сделки, контакты;
- задачи;
- пользователи;
- события;
- batch-запросы.
- comms
- чаты;
- чат-боты;
- сообщения;
- телефония.
- automation
- бизнес-процессы;
- роботы;
- шаблоны автоматизаций.
- collab
- рабочие группы;
- живая лента;
- внутренняя социальная активность.
- content
- диск;
- файлы;
- документы и договоры.
- boards
- скрам;
- канбан-доски;
- управление задачами на досках.
- commerce
- заказы, оплаты, доставки;
- каталог товаров и услуг.
- services
- бронирование;
- календарь;
- события и встречи.
Дальше можно расширять: делать пакеты под HR, контакт‑центр, кастомные приложения и т.д.
---
Как агент "подгружает мозги" по частям
Логика работы в моём skill такая:
1. Агент всегда начинает с `SKILL.md`.
2. Там он видит:
- краткое описание: "Ты умеешь работать с Битрикс24 через REST";
- список доступных capability packs и их назначение;
- инструкцию: "Сначала подключи core, потом по необходимости добирай остальное".
3. При первой попытке что‑то сделать в Битрикс24 агент:
- активирует `core` - чтобы иметь под рукой CRM, задачи, пользователей и batch;
- получает базовые паттерны: как авторизоваться, как формировать запрос, как обрабатывать ошибки.
4. Если пользователь говорит что‑то типа:
- "Напиши сообщение в рабочий чат отдела продаж" - подключается `comms`;
- "Запусти бизнес-процесс согласования договора по этой сделке" - подгружается `automation`;
- "Положи этот файл в общий диск и дай доступ всем участникам группы" - тянется `content` и `collab`.
Таким образом, агент всегда работает в режиме "минимально необходимого знания", а не таскает за собой весь справочник. Это резко снижает как расход токенов, так и количество дурацких ошибок.
---
Авторизация: вебхук против OAuth
Всё это красиво, пока не упираешься в базовый вопрос: а как вообще дать агенту доступ в конкретный Битрикс24?
Есть два понятных способа:
1. Вебхук
- Вы создаёте входящий вебхук в Битрикс24.
- Получаете URL вида `https://.../rest/1/XXXXXXXX/`.
- Агент просто добавляет к нему нужный метод и параметры.
Плюсы:
- быстро;
- просто;
- ideal для экспериментов и личного использования.
Минусы:
- вебхук жёстко привязан к конкретному пользователю и порталу;
- управление правами - на стороне Битрикс24, но если вебхук утечёт, придётся его отрубать и пересоздавать.
2. OAuth
- Регистрируется приложение в Битрикс24;
- агент получает токен через стандартный OAuth-флоу;
- дальше ходит в REST уже от имени приложения/пользователя с учётом всех прав.
Плюсы:
- удобно для продакшн‑решений;
- можно работать с разными порталами;
- лучше контролируется безопасность и управление доступом.
Минусы:
- сложнее в настройке;
- требует уже более серьёзной подготовки и инфраструктуры.
В своём skill я заложил обе опции:
- для быстрых тестов агент может использовать вебхук;
- для серьёзной эксплуатации - работать через OAuth, если админы всё настроили.
Раздел в `SKILL.md` и отдельные файлы описывают:
- как хранить и передавать ключи;
- как обновлять токены;
- как не логировать секреты в явном виде.
---
Пример из жизни: как это работает в реальных сценариях
Представим, что менеджер пишет агенту:
> "Посмотри новых лидов за сегодня из рекламы, проверь, есть ли у них заполненный телефон и город. Тем, у кого есть, создай задачи на прозвон на завтра ответственному менеджеру. Остальных пометь комментарием, что данных мало, и подготовь сводный отчёт по результатам".
Что делает агент, опираясь на skill:
1. Понимает, что речь про CRM и задачи → подключает `core`.
2. Из инструкций `core` берёт:
- методы для выборки лидов по фильтру (пример: по дате создания и источнику);
- методы для чтения полей лида;
- методы для создания задач и добавления комментариев.
3. Делит лиды на две группы по наличию телефона / города.
4. Для первой группы:
- создаёт задачи с нужным сроком;
- назначает ответственных;
- связывает задачи с лидами.
5. Для второй группы:
- оставляет комментарии в лидах, что данных недостаточно.
6. Собирает мини-отчёт:
- сколько лидов всего;
- сколько с полными данными;
- сколько с неполными;
- по кому созданы задачи.
7. Возвращает пользователю человеческий текст и, при необходимости, файл/таблицу.
Весь этот сценарий описан в виде цепочек (chains) внутри skill: какие методы в каком порядке дергать, что проверять и как обрабатывать ошибки. Агенту не нужно заново "изобретать" алгоритм - он следует готовому паттерну.
---
MCP vs Skill: зачем нужны оба уровня
Сегодня появился ещё один важный слой - MCP (Model Context Protocol). Это протокол, который позволяет подружить разные источники данных, инструменты и модели между собой.
Если очень упростить, MCP решает задачи уровня:
- "как вообще добраться до сервиса X";
- "как передать туда запрос и получить ответ";
- "как это всё стандартизировать для разных моделей".
Skill же отвечает за другое:
- доменную логику (как именно работать с Битрикс24);
- инструкции "на человеческом языке";
- конкретные цепочки действий в рамках задач пользователя.
Поэтому правильная связка выглядит так:
- MCP - транспорт, коннекторы, низкоуровневые возможности;
- Skill - доменная экспертиза, сценарии, бизнес-логика.
В моём случае skill можно использовать как:
- верхний уровень над любым MCP-коннектором к Битрикс24;
- "интеллектуальное описание": что можно делать в CRM, задачах, чатах;
- набор готовых шаблонов, которые MCP-инструменты будут дергать.
---
Безопасность: на что обязательно обратить внимание
Так как мы даём агенту реальный доступ в рабочий портал, безопасность - не формальный пункт в конце, а основа. Несколько принципов, которые я заложил в skill и рекомендую придерживаться:
1. Минимум прав
- Вебхуки и приложения должны иметь только те права, которые реально нужны для сценариев.
- Никаких "админских" прав ради удобства.
2. Отдельные учётки
- Лучше создать сервисного пользователя для агента, чем вешать всё на аккаунт реального сотрудника.
3. Логи без секретов
- Инструкции в skill явно запрещают агенту логировать токены, ключи и чувствительные данные.
- В логах - только технические статусы и обобщённые ошибки.
4. Ограничения по операциям
- Можно явно запретить агенту делать разрушительные действия (массовое удаление, изменение критичных полей) без дополнительного подтверждения.
5. Контроль активности
- Рекомендую завести отчёты/уведомления о действиях агента: что он создаёт, меняет, удаляет.
- В идеале - метить все сущности, созданные агентом, специальным полем.
Skill содержит текстовые инструкции для модели: что она имеет право делать, а чего нет. Да, это не "железная" защита, но на практике хорошо снижает риск некорректных действий.
---
Как к этому подойти, если вы тоже "не разработчик"
Самый частый внутренний стоп у гуманитариев - "я же не программист, значит, это не для меня". Вся эта история как раз показывает обратное.
Если у вас есть:
- понимание бизнес-процессов;
- базовый навык чтения технического текста;
- терпение объяснять модели, чего вы хотите,
то с современной генеративной AI-парой (типа Codex + Claude) вы можете:
- описать желаемые сценарии работы агента;
- вместе с моделью разложить их на шаги;
- по шагам собрать skill: от `SKILL.md` до chains и capability packs.
Модели помогают с:
- написанием фрагментов кода и YAML;
- конвертацией документации REST в понятные подсказки;
- генерацией шаблонов цепочек.
Ваша основная ценность - в том, чтобы сказать:
- "Как в реальности работает отдел продаж / поддержки / маркетинга";
- "Какие сценарии имеют смысл, а какие - нет";
- "Что можно автоматизировать без риска всё сломать".
То есть skill - это не столько про код, сколько про упаковку прикладочного опыта в формат, понятный агенту.
---
Что можно развивать дальше
Этот эксперимент - только первая итерация. Пространства для развития много:
1. Новые capability packs
- Отдельные модули под HR, обучение, контакт‑центр, склад, производство.
2. Готовые отраслевые сценарии
- Наборы цепочек для разных типов бизнеса: услуги, онлайн‑школы, e‑commerce, b2b‑продажи.
3. Глубокая интеграция с автоматизацией
- Чтобы агент не просто реагировал на команды, а сам предлагал запуск роботов и бизнес-процессов по триггерам.
4. Интерактивное обучение агента
- Когда сотрудник объясняет агенту один раз некий собственный внутренний процесс, а тот сохраняет его в виде новой цепочки и использует дальше.
5. Инструменты контроля и аудита
- Панели, где видно, что именно агент сделал в Битрикс24: какие сущности создал, какие изменил, где были ошибки.
---
Итог: зачем всё это бизнесу и вам лично
Интеграция OpenClaw с Битрикс24 через хорошо структурированный skill - это не про "ещё один модный AI", а про новый уровень интерфейса к вашему бизнесу.
Вместо того чтобы:
- учить людей десяткам экранов, фильтров и настройкам;
- писать километровые регламенты;
- вручную стыковать сервисы,
вы получаете "контекстного сотрудника", который:
- понимает вашу CRM и задачи;
- умеет дергать нужные методы REST;
- выполняет рутинные действия по инструкции;
- говорит с людьми на нормальном русском языке.
И главное - для старта вам не обязательно быть сильным разработчиком. Достаточно знать, как живёт ваш бизнес, и быть готовым потратить немного времени на то, чтобы вместе с моделью упаковать этот опыт в skill. Всё остальное - дело техники и упорства.
