Почему автоматизация не работает без рецепта
После одного урока мне нужно было опубликовать пост с картинкой. Мелочь: текст, обложка, отправка.
В голове уже была красивая версия: агент берёт стабильные шаги, я смотрю результат. Почти пайплайн.
Но красивая версия появилась позже. Сначала мы с агентом прошли цепочку шаг за шагом, поймали ограничения платформы, записали рецепт и проверки. Только после этого стало понятно, что можно отдавать агенту, а что должно остаться отдельным контролем.
Ошибка: автоматизировать до рецепта
Я часто вижу один и тот же соблазн. Один раз задача доехала до результата, и сразу хочется сказать агенту: сделай так же завтра.
Проблема в словах «так же». Агент не видел вчерашние компромиссы. Он не знает, почему текст укоротили, почему картинка должна идти одним сообщением, почему правку надо делать через edit, почему после отправки нужно прочитать сообщение обратно.
Он ускоряет то, что описано.
Если описан хаос, он ускорит хаос.
У инженеров Google для похожей боли есть слово toil: ручная повторяемая работа, которая сама по себе не создаёт долгосрочной ценности. Но из этого не следует «сразу автоматизировать всё». В их же книге про автоматизацию мысль приземлённее: сначала процесс должен стать понятным.
Для меня это и есть первый шаг пайплайна: не код, не схема, не агент. Рецепт.
Как один пост стал runbook
На поверхности задача была простой: отправить пост после урока.
Внутри оказалось пять решений.
Источник текста. Не писать заново в интерфейсе отправки. Сначала должен быть один согласованный текст, который можно перечитать, править и использовать в следующем похожем случае.
Шаблон копии. У поста появилась форма: заголовок с артефактом, 1-2 абзаца сути, компактный блок «что сделали», два шага домашки, одна ссылка на материалы.
Репетиция. Перед живой отправкой нужен тестовый прогон. Не из недоверия к агенту. Просто сообщение в реальном интерфейсе почти всегда ведёт себя чуть иначе, чем текст в голове.
Dry-run. Перед действием агент должен показать, куда собирается отправлять, какой режим разметки использует, какой файл прикрепит и какой длины подпись.
Read-back. После отправки нужно прочитать результат обратно. Отправлено ещё не значит проверено.
В этот момент пост перестал быть разовой задачей. Он стал рабочей памяткой: как довести похожую операцию до зелёного состояния.
И вот тут агент наконец полезен.
Это уже не просьба «сделай красиво». Это управление процессом.
Лимит платформы полезнее красивой схемы
Поворотный момент случился на подписи к медиа. У Telegram для медиа-подписи есть жёсткий лимит. В моём прогоне длинный текст в него не проходил.
Самый простой хак: отправить картинку отдельно, а текст вторым сообщением.
Я его не выбрал. Формат задачи был другим: один media-post, картинка плюс полный смысл в подписи. Если молча разбить это на два сообщения, рецепт уже сломан. Следующий прогон начнёт наследовать обходной путь, который никто не принимал как решение.
Поэтому мы вернулись к источнику. Агент сжал caption до короткой версии: сохранил заголовок, четыре строки recap, два шага домашки и одну ссылку. Потом dry-run показал, что текст проходит.
Лимит победил красивую автоматизацию. И хорошо.
Именно ограничения делают runbook честным. Пока всё проходит с первого раза, кажется, что процесса нет. Как только платформа говорит «сюда не влезает», появляется развилка: менять исходник, менять формат или остановиться и спросить.
Эту развилку надо записывать.
Runbook в быту
Runbook звучит как скучный корпоративный документ. Для меня это проще: записанный ответ на вопрос «как я довёл операцию до зелёного состояния».
В такой записи должны быть не только шаги. Нужны условия старта, типичные сбои, критерий готовности и проверка результата. У Atlassian есть шаблон runbook для ITSM. Я не переношу его один в один, но сама идея полезная: держать архитектуру операции, известные ошибки и troubleshooting рядом.
Ещё ближе к моей практике цикл PDCA: спланировал, сделал, проверил, поправил. Без плаката на стене.
У меня это выглядит так:
- Один живой прогон с агентом.
- Рецепт в тексте.
- Тестовый прогон.
- Проверка результата.
- Правка рецепта.
После этого можно ускорять стабильные части.
Где тут агент
Агент не должен угадывать процесс из воздуха. Ему нужен слой памяти.
В одном случае это runbook. В другом это один JSON как слой данных для агентов. В третьем это хуки и GitHub Issues как память задач агента. Принцип один: агент работает лучше, когда не вытаскивает контекст из прошлого чата.
Проверку я держу отдельно. Для текста у меня уже есть детерминированный грейдер для черновиков: он не спорит о вкусе, он проверяет правила. Для YouTube-таймкодов я писал похожую мысль: модель отвечает за смысл, механика остаётся отдельно.
С runbook то же самое.
Агент может сжать текст, собрать список шагов, проверить длину подписи, подготовить dry-run, напомнить про read-back. Но критерий «готово» должен быть записан до того, как агент побежит выполнять.
Иначе он просто быстрее принесёт не тот результат.
Что я вынес
Пайплайн не появляется после красивого промпта. Он появляется после первого живого прогона, где стало видно: что повторяется, что ломается, что надо проверять и где человеку нужно принять решение.
Сначала рецепт. Потом агент.
Теперь, когда похожая задача повторится, мне не нужно снова объяснять всё с нуля. Есть текстовый источник, структура поста, dry-run, проверка, правило для картинки и финальный read-back.
Вот это и есть пайплайн.
Он рождается руками в смысле решений. А дальше его уже можно отдавать агентам по частям.
Подписаться на обновления — @sereja_tech