Мультипачка ботов без хаоса: роли, границы и порядок запуска
Несколько ботов сами по себе не дают систему. Они дают шум: дубли ролей, разные форматы «готово», параллельные запуски и вопрос «кто виноват, если ушло наружу». Пачка — это конвейер с границами, а не коллекция ассистентов с красивыми именами.
Сначала карта процесса, потом боты. Иначе вы размножите хаос быстрее, чем получите пользу. База: как создать своего, первый час, кейсы. Официально: x.ai/bot, Grok Bot 101. Старт — /start.
Почему пачка быстро становится шумом
Типичные симптомы первой недели:
- два бота делают «сводку» в разном формате;
- никто не владеет финальным артефактом;
- инструкции конкурируют в одном треде;
- запуски идут параллельно без критерия завершения;
- доступы выданы «всем на всё»;
- названия ролей совпадают, а мандаты — нет.
Хаос лечится не третьим ботом, а картой: вход → этапы → точки человека → финальный файл. Если финал «красивый чат», процесса ещё нет — есть разговор.
Спроектируйте процесс до создания ботов
Вход и финальный артефакт
Запишите одной строкой: что приходит на вход и что лежит на столе в конце. Пример: «вход — папка inbox за день; выход — один markdown со сводкой и списком рисков». Пока строка не ясна — ботов не плодите.
Независимые этапы
Режьте работу так, чтобы этап можно было проверить отдельно: сбор → черновик → проверка → редактура. Смешанные этапы («собери и сразу опубликуй») размножают ошибки и делают approval бессмысленным.
Точки человека и approval
Публикация, письма клиентам, платежи, смена прав, прод, удаление — только после подтверждения владельца. Бот готовит, человек выпускает. Это же правило для любой внешней интеграции.
Полезный соседний материал по границам — безопасный первый контур и мандат как ТЗ.
Четыре роли, которых обычно достаточно
- Диспетчер — принимает задачу, назначает маршрут, не делает работу сам.
- Исполнитель — собирает черновик артефакта по контракту.
- Проверяющий — ищет дыры, противоречия, пропуски полей.
- Редактор — приводит к формату сдачи.
Часто хватает исполнителя и проверяющего. Диспетчер нужен только при ясных маршрутах. Если роль не добавляет артефакт — уберите её. Лишняя роль — это лишний контекст, лишний расход и новая точка путаницы.
Живые примеры смотрите в кейсах и в плейбуке команды из пяти ботов. Для узких контуров полезны также бот для контента и бот для фриланса — там видно, как одна роль закрывает один артефакт.
Контракт между ботами
Договоритесь заранее и положите в одну заметку:
- формат входа и выхода (файл, поля, статусы: draft / needs-fix / ready);
- обязательные поля и что делать при пустоте;
- запрет молча менять исходник — только копия плюс комментарий или diff;
- кто принимает финал (человек-владелец процесса);
- язык и объём.
Без контракта «пачка» обменивается мнениями, а не артефактами. С контрактом вы можете заменить исполнителя и не ломать проверяющего.
Доступы и безопасность
Минимальные права на роль. Свои контролируемые аккаунты и официальные интеграции. Не передавайте чужие сессии, пароли и токены в промпты. Не покупайте и не используйте чужие аккаунты — это ломает и безопасность, и ответственность.
Личный Telegram не автоматизируем: только официальный бот/API под вашим контролем — подробнее в Telegram и осторожный контур. Если бот работает с кодом — отдельные правила ветки и PR: код с ботом.
Поэтапный запуск
- Один исполнитель на одной задаче до стабильного артефакта.
- Проверяющий на копии результата, не на прод-исходнике.
- Связка двух ролей с единым шаблоном полей.
- Только потом — диспетчер или редактор.
- Фиксируйте, что сломалось: формат, доступ, критерий, а не «бот тупит».
Не запускайте всех сразу «на пробу». Параллельный хаос дороже последовательной настройки. Если лимит уже горел от широких запусков — см. сжёг лимиты за день и недельные лимиты.
Когда смотреть на Heavy
Heavy — это ФОТ многорукого: дополнительные руки на объём и параллель, а не «подписка на более умный чат». Сначала докажите, что одна связка ролей закрывает задачу без хаоса. Затем решайте про мощность: цена Heavy — не подписка.
Не включайте Heavy «на всякий случай», пока роли и контракты сырые: вы оплатите размножение шума.
Операционный чеклист
- Реестр ролей и владелец каждой
- Вход и финальный артефакт описаны одной строкой
- Контракт полей и статусов
- Минимальные доступы на роль
- Approval на внешнее
- Журнал ошибок и правило остановки
- Не запускать пачку «все сразу» в первый день
- Есть тестовый вход без секретов
Мини-пример: одна связка за день
Утро: описываете вход и финальный файл одной строкой. Создаёте только исполнителя. Полдень: на копии результата запускаете проверяющего с чеклистом полей. Вечер: сверяете два артефакта, правите контракт (добавили статус `needs-fix`), сохраняете шаблон. Завтра — тот же конвейер на новом входе, без новых ролей.
Так пачка растёт из рабочей связки, а не из желания «собрать оркестр». Если команда уже ведёт несколько процессов, заведите реестр: роль → владелец → артефакт → доступы → дата последней проверки. Пустая строка в реестре значит роль ещё не готова к запуску.
Перед масштабированием на пять ролей убедитесь, что две уже закрывают задачу без повторных прогонов. Иначе вы скопируете шум. Сравните также, не хватает ли вам скорее ясного мандата, чем нового бота: мандат как ТЗ.
FAQ
Сколько ботов нужно? Минимум независимых ролей. Начните с одной связки и мерьте пользу артефактами, не количеством агентов.
Нужен ли диспетчер? Только если маршруты ясны и полномочия ограничены. Иначе диспетчер станет ещё одним шумом.
Как не запутаться? Единый шаблон артефакта, статусы и один человек-владелец решения.
Можно ли дать боту чужой аккаунт? Нет. Только свои контролируемые доступы.
Нужен ли Heavy сразу? Нет. При доказанном объёме считайте его как ФОТ многорукого.
Кто отвечает за ошибку? Владелец процесса и человек, утвердивший внешнее действие. Бот не подписывает прод.
Что сделать сейчас
- Нарисуйте карту одной задачи и создайте роль по гайду.
- Проверьте связку на примере из кейсов.
- Для объёма прочитайте Heavy как зарплату и откройте /start.