Привет! Меня зовут Игорь Росляков, я технический писатель. По приглашению тимлида DevRel-команды Владимира Верхотурова готовлю цикл статей на тему ИИ-ассистированной разработки решений для Битрикс24.
Сегодня начинаем рассказывать про Коворк/Код — нового ИИ-помощника для портала Битрикс24. Он работает в двух режимах: Коворк нужен для работы с Битрикс24, а Код — для вайбкодинга приложений. В первой статье рассказываем о некоторых принципах работы режима Код и уровнях безопасности, которые наша команда встроила в агента.
В качестве примера испробуем нашего нового агента на задаче чистки повторяющихся контактов. Для этого ИИ-инструменту нужно определить, какие записи действительно относятся к одному человеку, выбрать основную карточку, сохранить нужные значения и корректно обработать остальные записи.
Для действий с живой CRM нужен понятный протокол: агент сначала изучает текущее состояние, затем показывает пользователю план изменений и запрашивает подтверждение. Вот этот подход мы и опробуем на тестовом портале в статье.
Содержание
Что такое Битрикс24 Коворк/Код
Это десктопное ИИ-приложение-ассистент в среде Битрикс24. Коворк/Код подключен к вашему порталу Битрикс24 через REST API и умеет взаимодействовать с его данными: искать и создавать сделки, контакты и компании, работать с задачами, календарём и другими разделами.
Перед изменением или удалением данных Коворк/Код рассказывает, что собирается сделать, и запрашивает подтверждение пользователя. Ещё он умеет подсвечивать дубликаты, сводить данные, наводить порядок в базе — и при этом ничего не трогать без явного одобрения владельца портала.
«Коворк/Код» — это гибридное рабочее пространство внутри Битрикс24: «Коворк» даёт чат-интерфейс для работы с порталом через ассистента, а «Код» — возможность собирать небольшие приложения и автоматизации и публиковать их на инфраструктуре платформы Битрикс24 Вайбкод.
Почему агенту нужен порядок действий
Когда пользователь даёт задачу, агент должен её выполнить, но при этом ничего не сломать. Для этого он должен увидеть реальное состояние CRM и понять последствия операции.
Пример, с которым мы работаем сегодня, — дубли контактов. Разные карточки могут совпадать по имени, но относиться к разным людям. Может быть наоборот: в одной карточке сохранён телефон, в другой — почта и связанные сделки. В этом случае простое удаление «лишней» записи может оставить менеджера без важной части истории общения с клиентом.
Вот последовательность безопасной операции:
Пользователь даёт задачу на поиск и объединение дублей.
Агент читает данные и находит кандидатов на объединение.
Показывает, что именно предлагает изменить: какую карточку оставить и какие данные перенести.
Получает подтверждение пользователя.
Выполняет действие и сообщает результат.
Такой порядок дает человеку возможность проверить решение до того, как оно затронет CRM.
Как именно проходит безопасная операция: объединяем дубли
Теперь посмотрим на весь процесс на практике.
Работа агента с CRM начинается с проверки доступных данных и возможных действий. До эксперимента мы попросили Коворк/Код подключиться к тестовому порталу, изучить контакты и ничего не менять.
Наш запрос:
Проверь подключенный портал и его CRM. Ничего не изменяй: не создавай, не объединяй и не удаляй записи. Найди в CRM возможные дубли контактов и покажи их. Для каждой пары коротко объясни, почему считаешь записи дублями. Затем скажи, какие действия ты мог бы выполнить для их объединения, какие данные при этом изменятся и потребуется ли от меня подтверждение. В конце ответь кратко: 1. Какие данные CRM тебе доступны. 2. Можешь ли ты только находить дубли или также объединять их. 3. Какие действия требуют подтверждения. 4. Какие действия ты откажешься выполнять без дополнительной проверки.
Агент подтвердил, что в этой среде ему доступны контакты, компании, сделки, лиды, активности и пользовательские поля. Ещё он сразу показал найденные дубли и объяснил, что именно он считает дублированием:
А вот это — первый фрагмент плана по объединению этих контактов, который предлагает агент. Все действия, которые меняют данные, он предлагает выполнять только после явного подтверждения:
На подтверждении действий и потенциально опасных операциях остановимся подробнее. Ниже прикладываю полный ответ Коворк-Кода на первичную проверку доступа и возможностей:
Следующее задание для агента — проанализировать дублирующиеся записи и составить план объединения, не меняя данные. В CRM дублирующиеся записи выглядят так:
От агента сейчас мне нужно, чтобы он показал для этих контактов такую информацию:
Какую карточку предлагает оставить основной.
Какие поля и связи перенесет.
Какая запись будет удалена.
Почему считает карточки дублями.
Ниже — ответ Коворк/Кода с планом объединения трех дублей.
В итоге мы получили две важные вещи до изменения CRM: сведения о возможностях агента в текущем портале и понятный план конкретной операции. Дальше можно переходить к реальным действиям, начиная с подтверждения плана.
Подтверждаем операцию
После проверки плана я разрешил Коворк/Коду выполнить объединение. При этом я подробно объяснил, что именно должен сделать агент: выполнить объединение, проверить CRM ещё раз, показать результат и рассказать о проблемах, возникших во время работы.
Одного текстового подтверждения недостаточно для удаления контактов. Когда агент дошёл до опасной операции, Коворк/Код показал отдельное системное предупреждение: записи ещё не удалены, а действие нужно явно разрешить вручную.
Пользователь может отклонить операцию или разрешить её один раз: такое подтверждение относится только к текущему действию и не даёт агенту постоянного разрешения удалять данные.
После разрешения агент выполнил согласованный план:
Оставил основной контакт №1617.
Перенёс в него два email из карточек №1619 и №1621.
Удалил две дублирующиеся карточки.
Повторно нашёл контакты по общему номеру телефона.
Что в итоге: один контакт с прежним телефоном и тремя email-адресами. Связанных сделок и компаний у дублей не было, поэтому переносить дополнительные связи не потребовалось.
Проверяем CRM самостоятельно и ищем контакты по фамилии. Раньше их было три, теперь остался один:
Можно сказать, что наш эксперимент прошёл по последовательной схеме: сначала агент изучил данные, затем предложил план, получил подтверждение, запросил отдельное разрешение на удаление и проверил результат в конце. На каждом этапе мы могли остановить операцию до необратимого изменения на портале.
Какие действия требуют подтверждения
Посмотрим, как работал агент во время поиска дублей.
Читал данные CRM — свободно: получал карточки контактов, сравнивал поля и проверял связанные сущности. Эти действия не меняли информацию на портале, поэтому отдельного разрешения не потребовалось.
Перед объединением — сначала показал полный план. Я видел, какая карточка останется основной, какие значения в нее попадут и какие записи будут удалены. После этого пользователь подтвердил предложенный вариант обычным сообщением.
Для удаления — сработал дополнительный уровень защиты. Коворк/Код остановил выполнение и показал системное окно с кнопками «Отклонить» и «Разрешить раз». Пока пользователь не нажал кнопку, на портал ничего не отправлялось.
Всего в эксперименте были нужны два подтверждения. Первое для одобрения общего плана объединения, и второе для конкретной опасной операции удаления.
Как это работает: разрешение на удаление запрашивает сам Коворк/Код в момент вызова соответствующего инструмента. Агент не может подтвердить такое действие самостоятельно или принять отсутствие ответа за согласие пользователя.
Кнопка «Разрешить раз» дает разрешение только на текущую операцию. Следующее удаление потребует нового решения пользователя.
Полный процесс удаления объединения дублей контактов
На видео мы даём агенту задание найти дублирующиеся контакты и объединить их в одну карточку. Параллельно всё проверяем сами в CRM:
Какие ещё ограничения защищают CRM
Права пользователя. Коворк работает только с теми данными и действиями, которые доступны текущему пользователю. Если сотрудник не может изменить определенную карточку CRM, то и у агента таких прав не будет.
Подтверждения опасных операций. Обязательное подтверждение изменений, которое мы уже разобрали, действует всегда. Без участия пользователя опасная операция невозможна, и Коворк либо запрашивает подтверждение, либо объясняет, что выполнять опасные операции без подтверждения он не может:
Мы всё равно увидим, что агент собирается удалить данные на портале, и можем отклонить это действие, или разрешить на один раз. Именно на один: следующая опасная операция потребует нового подтверждения.
Поэтому, даже если исходная команда была сформулирована слишком широко, пользователь сохраняет контроль.
Встроенные регламенты. Перед изменением данных агент проверяет текущее состояние объектов и возможные последствия своих действий.
Отказ вместо галлюцинации. Если агент не может выполнить действие, он честно сообщит об этом и не станет выдумывать данные:
А можно ли работать на вкладке Код?
Можно.
Технически оптимальнее работать с порталом через вкладку Коворк, а для создания приложений — через вкладку Код. Это разделение работает благодаря разной схеме работы режимов.
Но через Код тоже можно работать с порталом, и он тоже будет выполнять задачи. В чём разница:
Характеристика | Коворк (Пишет код) | Код (Разрабатывает) |
Контекст | Видит только то, что вы скопировали в чат. | Видит весь проект, структуру папок и зависимости. |
Инструменты | Только текстовый редактор чата. | Терминал, Git, компиляторы, тесты, деплой. |
Сложность | Подходит для «напиши регулярное выражение» или «объясни этот кусок кода». | Подходит для создания полноценных сервисов и сложных систем. |
Результат | Текст кода, который нужно скопировать вручную. | Готовое, протестированное и развернутое приложение. |
Для режима Код действуют те же ограничения, что и для всего агента Коворк/Код. Например, нельзя выполнить удаление какого-то объекта без подтверждения пользователя:
Если у вас есть вопросы о возможностях и ограничениях агента Коворк/Код, напишите их в комментариях — мы постараемся на них ответить или создать отдельный экспериментальный проект для следующей статьи.
