Кросс‑постинг в соцсети: как проблемы state, идемпотентности и кириллицы усложнили автоматизацию

Что требовалось

Отдел маркетинга компании запросил автоматизацию кросс‑постинга статей блога в несколько соцсетей. На входе – готовая статья, а на выходе – Google‑документ с коротким анонсом, вариантами рерайтов для разных площадок, прикреплённой картинкой, UTM‑метками и готовый к публикации набор постов.

Как выглядело решение

Автор статьи решил «отдать задачу агенту» – LLM‑агенту, который последовательно:

1. Извлекает заголовок и ключевые тезисы из оригинального текста.
2. Генерирует короткий анонс (≈140 символов) и несколько вариантов рерайта.
3. Подбирает изображение через API стоковых сервисов.
4. Добавляет UTM‑метки к ссылкам.
5. Формирует готовый Google‑Doc и, при необходимости, публикует посты через API соцсетей.

Проблемы, с которыми столкнулся автор

• State management – агенту нужно было помнить, какие посты уже созданы, чтобы не дублировать их при повторных запусках. Был реализован простой «ключ‑значение» кэш в базе DynamoDB, но без надёжного TTL‑механизма возникали «зависания» статуса.
• Idempotency – API большинства соцсетей не гарантируют идемпотентность запросов. При повторных попытках публикаций иногда получались дублирующие посты. Было решено использовать уникальные client_id в запросах и проверять статус публикации перед повтором.
• Битая кириллица – при передаче текста через несколько сервисов (LLM, Google Docs API, соцсети) иногда происходила потеря кодировки UTF‑8, в результате появлялись «????» вместо русских букв. Проблема оказалась в неверных заголовках Content-Type и была исправлена принудительным указанием charset=utf-8.

Итоги

После исправления всех «узких мест» автоматический кросс‑постинг стал работать стабильно: за сутки система генерирует и публикует более 200 постов без ручного вмешательства. Статья полностью доступна на Habr AI: https://habr.com/ru/articles/1070282/.