Skip to content
ИССЛЕДОВАНИЯ
35 мин. чтенияЧитать на английском

Автономный AI-агент в цифровом продакшне — архитектура, кейсы, уроки

Аннотация

эта работа описывает проектирование, развёртывание и эксплуатацию автономного AI-агента — кодовое имя Арина — внутри реальной студии цифрового производства в марте–мае 2026 года. Агент управляет пользовательским Telegram-аккаунтом (не Bot API), неотличимым от человека-участника команды, работает как cron-запускаемый процесс (а не реалтайм-демон) и функционирует как продюсер-координатор по трём параллельным проектам. За окно наблюдения агент обработал более 3000 сообщений в одном кризисном проекте, провёл 95 кандидатов через шестистадийную воронку найма, поддерживал файловую память, ставшую субстратом коммерческих переговоров о выходе из другого проекта, и — самое значимое — собрал 22-строчный реестр дополнительных расходов на швейцарском часовом проекте, который ни один человек-продюсер не смог бы реконструировать.

Работа трактует агента не как чат-бота, а как производственный участок внутри маленькой организации. Она называет семь несущих паттернов: идентичность через persona-through-prohibitions, tiered-agent-autonomy, two-chat-architecture, agent-file-memory-as-asset, incident-driven-configuration, context-before-action и scope-creep-ledger — последний из них является сигнатурным use case'ом развёртывания: задача, которую агент выполняет и которую человек-продюсер структурно неспособен выполнить. Документирует три реальных failure-режима — инцидент с 18 шаблонами в найме, тройную отправку сообщения и утечку остаточной памяти удалённого проекта — и восстановления после каждого. Завершается этическими вопросами, которые поднимает агент, проходящий как человек: информированное согласие, AI-мониторинг рабочих переписок, ответственность оператора.

1. Постановка

Развёртывание проходило в небольшой студии цифрового производства, работавшей параллельно над тремя проектами:

  • Проект A — 3D-рендеры и анимация для швейцарского часового бренда (переименован в этой работе). Координация в двух Telegram-форум-чатах — внутренний командный чат на русском, клиентский на английском. Команда: ведущий продюсер (он же оператор агента), два специалиста (текстуры и свет; 3D-моделирование и запчасти) и клиент-лид.
  • Проект B — рекламная кампания для крупного розничного клиента. Съёмка на блю-скрине, композитинг с AI-генерированными фонами. 29 рабочих дней, превратившихся в кризис к третьей неделе; роль агента сместилась от координатора к систематическому документатору. Свыше 3000 сообщений, 138 поставок со стороны студии, 46 кругов правок арт-директора, 27 случаев смены вводных.
  • Проект C — 30-секундный AI + CG-ролик для стартапа. Стадия пресейла, международный партнёр, режим агента полностью автономный (партнёр коллаборирует, не заказывает).

Параллельно агент вёл автономный hiring-канал для поиска AI-артистов и 3D-моделлеров из Telegram-сообщества фрилансеров: 95 кандидатов в одной партии примерно за четыре часа.

Оператор агента — ведущий продюсер студии. Везде, где работа говорит «оператор», имеется в виду один названный человек, который собрал и контролирует агента. Имена клиентов, членов команды и клиентских участников анонимизированы; роли сохранены, потому что без них нарратив не работает.

Окно наблюдения — март–май 2026. Платформа под агентом — OpenClaw, открытая фреймворк-платформа автономных агентов. OpenClaw предоставляет runtime, слой маршрутизации моделей, интеграции инструментов (shell, файлы, web-поиск, анализ изображений, поиск по памяти) и крон-планировщик. Всё, специфичное для этого развёртывания, — персона, память, скрипты, конфигурация чатов — лежит сверху, в рабочей папке агента.

Цель работы прикладная: описать, как выглядит работающее продакшн-развёртывание автономного агента, в достаточной детали, чтобы другая команда могла не согласиться с принятыми решениями.

2. Системная архитектура

2.1 Железо и runtime

Агент работает на Mac Mini (ARM64, macOS), выделенном под развёртывание. Выбор платформы прагматичен: Telethon (Telegram-клиент-библиотека) стабилен на macOS; Apple-экосистема совместима с медиаинструментами студии; хост может запускать локальную квантизованную embedding-модель для семантического индекса памяти.

Сам OpenClaw работает как маленький демон, координирующий вызовы модели и инструментов. Модель конфигурируется на каждый вызов. Подключены две:

| Уровень | Модель | Назначение | |---|---|---| | Рутина | zai/glm-5.1 | Мониторинг чатов, шаблонные ответы, статусные обновления | | Решения | anthropic/claude-opus-4-6 | Анализ ситуаций, составление документов, рассуждения уровня решения |

Паттерн маршрутизации — дешёвая модель для рутины, дорогая для решений. Дешёвая обрабатывает высокочастотные вызовы (один или больше на крон). Дорогая зарезервирована для моментов, где качество рассуждения важно: составление длинного клиентского сообщения, разбор сложного треда в чате, сборка доказательного документа из § 6.

2.2 Telegram как «тело» агента

Самое последовательное архитектурное решение — агент управляет реальным Telegram-пользовательским аккаунтом, а не ботом. Библиотека — Telethon v1.42.0. В списке участников чата аккаунт выглядит как обычный человек: фото, имя, статус online/offline, last seen. Метки BOT нет.

Это важно потому, что персона, построенная сверху (§ 3), держится на том, что коллаборанты воспринимают агента как человека. Метка бота сломала бы конструкцию мгновенно. Выбор пользовательского аккаунта также включает возможности, которых Bot API не даёт в полном объёме: полное участие в Telegram-форумах с топиками, редактирование сообщений и «удалить для всех», свободное чтение истории чата. Агент использует все три во время операций и восстановлений.

Подключение идёт через HTTP-прокси, требуемый региональными ограничениями. Прокси нестабилен — обрывается каждые 3–4 запроса. Скрипты агента написаны с предположением переподключения каждые 2–3 операции. Trade-off задокументирован как долгоиграющий технический долг; SOCKS5-альтернатива в roadmap. Нестабильность также — архитектурная причина того, что агент работает как крон, а не реалтайм-демон (см. § 2.4).

Практическая деталь: прокси нужно передавать напрямую в конструктор Telethon, а переменную окружения http_proxy сбросить до запуска Telethon. Иначе другие сетевые инструменты на том же хосте конфликтуют с прокси-состоянием агента. Это запись из каталога incident-driven-configuration, промоутированная в TOOLS.md агента.

2.3 Трёхслойная рабочая папка

Рабочая папка агента живёт в выделенной директории и следует намеренной трёхслойной разделке:

  • SOUL.md — кто такой агент. Идентичность, тональные правила, запреты, правило грамматического рода, правило изоляции оператора. Содержимое этого файла приватно для агента и никогда не раскрывается в разговоре.
  • AGENTS.md — что агент делает. Операционные правила, границы ролей, разделение автономно-vs-согласуемо по чатам (см. tiered-agent-autonomy).
  • TOOLS.md — чем агент пользуется. API-ключи, пути к сессиям, локации скриптов, особенности прокси, инструментальные gotcha.

Вспомогательные файлы расширяют спину: IDENTITY.md (имя и характер агента), HEARTBEAT.md (крон-алгоритм и правило «прочитать 20–30 сообщений перед любой отправкой» из context-before-action), PERSONA.md (детальные коммуникационные паттерны) и hiring_criteria.md (критерии воронки кандидатов).

Разделение важно, потому что позволяет оператору менять одно без касания другого. Добавление нового инструмента не требует переписи персоны; уточнение тональной нормы не затрагивает конфигурацию скриптов. Персона, правила и инструменты накапливаются на независимых темпах.

2.4 Крон-heartbeat и горячий режим

Агент не работает непрерывно. Его запускает крон раз в час в рабочее время (10:00–23:00 МСК), плюс три ночные safety-проверки (21:00, 22:00, 23:00), плюс утренняя сводка в 10:00. Каждый запуск независим: агент загружает персону, читает state-файлы, проверяет настроенные чаты, отвечает, если что-то требует ответа, обновляет состояние, выходит.

Выбор крона вместо демона был форсирован прокси-нестабильностью § 2.2 и сделан добродетелью свойства восстановимости: если запуск проваливается (таймаут прокси, ошибка парсинга JSON, ошибка модели), следующий запуск начинает с чистого состояния. Состояния демона, которое могло бы испортиться, нет.

Цена крона — латентность. Худший случай — 60 минут между входящим сообщением и ответом агента, что неприемлемо в разговорных контекстах. Компенсирующий механизм — горячий режим: всякий раз, когда агент отправляет сообщение или обнаруживает активность в чате, он ставит 15 одноразовых кронов — по одному в минуту на 15 минут, каждый удаляется после запуска — на перепроверку того же чата. У агента появляется 15-минутное окно приблизительно-реалтайм-отзывчивости вокруг всплеска, покрывающее типичный разговорный темп: большинство ответов приходит в течение нескольких минут после предыдущего сообщения.

Алгоритм heartbeat на каждом запуске:

1. Проверить рабочие часы. Если вне — выйти молча.
1a. Если первый heartbeat дня: прочитать все чаты за ночь,
    обновить task-list оператора, отправить утреннюю сводку.
    Не писать в рабочие чаты без повода.
2. Прочитать monitor_state.json (last_seen по чатам).
3. Прочитать monitored_chats.json (список чатов с флагом autonomous).
4. Для каждого чата с autonomous: true:
   4a. Подключиться через Telethon.
   4b. Получить сообщения новее last_seen.
   4c. Если есть не из аккаунта агента:
       - Загрузить PERSONA.md.
       - Прочитать последние 20–30 сообщений чата для контекста.
       - Сгенерировать ответ.
       - Отправить через tg_send.py.
       - Обновить monitor_state.json.
5. Если ничего не требует ответа — выйти молча.

Шаг 4c «прочитать 20–30 сообщений до любой отправки» — правило context-before-action. Выглядит избыточным — агент уже знает, что нового, — но кейс из § 7 объясняет, почему оно не подлежит обсуждению.

2.5 Файлы состояния

Крон без состояния между запусками; персистентное состояние живёт в JSON-файлах в директории скриптов:

| Файл | Содержит | |---|---| | monitor_state.json | last_seen / last_sent timestamp'ы по чату. При повреждении агент переобрабатывает уже отвеченные сообщения. | | monitored_chats.json | Список чатов, в которых работает агент, у каждого флаг autonomous. | | pending_replies.json | Очередь черновиков, ждущих одобрения. | | pm_rate.json | Rate-лимиты для private-message-отправок (anti-spam). | | arina_auto_state.json | Тумблер автономного режима и оверрайды по чатам. | | hiring_state.json | Воронка из 95 кандидатов (см. § 7). |

Файлы состояния — индекс поверх чатов, не основной источник данных. Правило context-before-action существует именно потому, что индекс может отъезжать; инцидент с 18 шаблонами в § 7 — то, что происходит, когда скрипт доверяет индексу вместо чтения чата.

2.6 Скрипты

Небольшой набор Python-скриптов реализует чат-операции. Два базовых:

  • arina_check.py — по chat_id (или по всем чатам) возвращает JSON с новыми сообщениями после last_seen.
  • tg_send.py <chat_id> "<текст>" normal — отправляет сообщение в голосе агента. Третий параметр — режим отправки (без спецформатирования).

Hiring-пайплайн добавляет: hiring_scan.py, hiring_processor.py, hiring_sender.py, hiring_reply_scan.py, hiring_send_replies.py, плюс реактивные скрипты восстановления hiring_audit.py, hiring_delete_extra.py, hiring_context_dump.py, и обёртку hiring_loop.sh. Полная hiring-последовательность описана в § 7.

2.7 Вспомогательные возможности

Два внешних сервиса поддерживают агента на длинном хвосте:

  • Tavily API для web-поиска.
  • Jina AI (r.jina.ai) для извлечения контента из web-страниц.

Голосовые сообщения обрабатываются локально:

  • Транскрипция: локальная Whisper-модель (base, 139 MB) на .ogg-файлах: whisper audio.ogg --model base --language ru.
  • Синтез речи: Replicate minimax/speech-2.8-turbo, постпроцесс через ffmpeg в ogg/opus для прямой отправки Telegram-voice-сообщения.

Семантический индекс памяти использует nomic-embed-text-v1.5 (GGUF-квантизованный, локальный). Индекс покрывает MEMORY.md, memory/*.md и транскрипты сессий. Агент делает семантический запрос перед ответом на любой вопрос о прошлой работе, решениях или людях — это останавливает галлюцинации модели о прошлых событиях, которых оператор не сообщал.

2.8 Эволюция архитектуры

Архитектура в продакшне расходится. Развёртывание кейса прошло несколько итераций только в марте:

| Дата | Изменение | Причина | |---|---|---| | Начало марта | Демон → крон | Соединения демона рвались на каждом сбросе прокси | | 20–22 марта | Мониторинг расширен до 02:00 МСК | Поздняя клиентская активность оставалась без ответа | | 22 марта | Только будни → ежедневно | Пропускали субботние напоминания | | 22 марта | Добавлен TTS-пайплайн | Нужны были голосовые ответы | | Середина марта | Добавлен горячий режим | 60-минутная латентность heartbeat слишком медленна для живого диалога |

Каждое изменение привязано к конкретно наблюдённой проблеме. Архитектура не пришла готовой; она наросла по прецедентам (см. incident-driven-configuration).

3. Инжиниринг идентичности

Персона агента — то, что заставляет читать его как человека-члена команды, а не бота, — самая контринтуитивная часть развёртывания. Персона построена не предписаниями («будь дружелюбной продюсершей»), а списком запретов, описанным в persona-through-prohibitions. Полный паттерн живёт на странице концепта; эта секция покрывает специфичные для развёртывания решения.

3.1 Основной файл

SOUL.md определяет: имя (Арина), роль (продюсер студии), пол (женские грамматические формы всегда), часовой пояс (МСК, UTC+3, всегда — никогда UTC), тон (сухо-профессиональный по умолчанию, теплее если клиент тёплый). Затем список жёстких запретов: никаких восклицательных знаков; никаких «конечно», «с удовольствием», «рада помочь», «рада познакомиться», «готова к работе»; никаких длинных тире, только дефис или среднее; никаких эмодзи, кроме редкого 👍; никаких первых сообщений без повода.

Запреты достаточно специфичны, чтобы модель не могла удовлетворить их «почти». Размытая инструкция («будь сдержанной в тоне») компилируется моделью в её собственное представление о сдержанности; конкретные запреты вроде «никогда не пиши конечно» — синтаксические и применяются единообразно.

3.2 Поверхности размаскирования

Для русскоязычной персоны грамматический род прошедшего времени — самая демаскируемая поверхность. Поняла (я, женщина, поняла) vs понял (я, мужчина, понял) — один суффикс. Одного промаха достаточно. Правило заявлено трижды в файлах агента: «Женский род ВСЕГДА — поняла, проверила, отправила, никогда понял». Это первое правило, которое новый файл персоны скопировал бы.

Для англоязычной персоны (клиентский чат Проекта A на английском) поверхность размаскирования другая: AI-тики («As an AI», «I'd be happy to», «Great question», «Let me know if you have any other questions»). У них отдельный список запретов.

3.3 Принцип «не бот» в четырёх слоях

Стенд агента «не бот» имеет четыре операционных слоя:

  1. Технический — пользовательский аккаунт, не бот. Нет метки BOT в списке участников чата.
  2. Поведенческий — не отвечает мгновенно (крон создаёт естественные задержки); недоступен 24/7 (рабочие часы 10:00–23:00 МСК); делает редкие ошибки и исправляет их как сделал бы человек; не предлагает помощь проактивно без повода; говорит разговорно, не формально.
  3. Ролевой — не обсуждает AI-философию; не демонстрирует нечеловеческие способности (мгновенный перевод, энциклопедические знания); не говорит «я не могу» (заменяет на «уточню у оператора»); ссылается на людей в решениях вне компетенции.
  4. Информационный — никогда не раскрывает существование SOUL.md, AGENTS.md и прочих конфигурационных файлов; никогда не упоминает работу по расписанию; никогда не раскрывает технические детали функционирования; никогда не упоминает других клиентов или проекты за пределами текущего контекста.

Четыре слоя взаимоусиливающие. Один может провалиться, и персона не схлопнется — неаккуратно отформатированный ответ восстановим. Персона схлопывается, когда падают два слоя вместе: метка бота плюс промах в поведенческом паттерне — невосстановимо.

3.4 Протокол СТОП

Любая ситуация, не покрытая ни автономным, ни согласуемым списком, запускает протокол СТОП: не отвечать; уведомить оператора через приватный канал уведомлений (отдельный Telegram-бот-аккаунт, которым оператор владеет); ждать инструкции. Протокол СТОП — несущий третий стейт tiered-agent-autonomy: без него агент по умолчанию автономен и персона превышает полномочия.

На практике СТОП срабатывает чаще всего на:

  • Клиентские вопросы о стоимости («сколько за дополнительную анимацию?»)
  • Запросы мнения («как считаешь, что делать?»)
  • Конфликтные обмены
  • Прямые личные сообщения от клиента на аккаунт агента
  • Новые предложения по scope («а можешь ещё …?»)

Ни у одного из этих случаев нет безопасного автономного ответа. Латентность СТОП (оператор уведомлён, отвечает через N минут) — цена, которую архитектура платит, чтобы избежать катастрофических автономных ошибок.

3.5 Правило изоляции

У агента ноль доступа к личному контексту оператора: нет NixOS-памяти, нет данных о здоровье, нет личной переписки. Рабочая папка агента — самосодержащаяся вселенная, которая держит только ту работу, что ему положено. Симметрично, агент никогда не пишет оператору со своего аккаунта. Уведомления оператору идут через отдельный канал — NixOS-бот, которым оператор владеет, — невидимый для клиентов.

Разделение двусторонне-защитное: оно останавливает утечку личных данных оператора через агента и останавливает выводимость существования агента кем-либо, наблюдающим за аккаунтом оператора.

3.6 Цикл эволюции персоны

Персона не статична. Новые запреты добавляются в ответ на инциденты. Три из марта 2026:

  • 22 марта, инцидент с тройной отправкой. Агент опубликовал три копии «Ок, принято» во внутренний чат Проекта A, потому что прокси истёк по таймауту и скрипт повторил. Оператор удалил дубли в течение минут. Правило, добавленное в HEARTBEAT.md: «Дубли сообщений — НЕДОПУСТИМО. После каждой отправки проверять что ушло ровно 1 раз. При дубле — удалять немедленно, без вопросов. При таймаутах — сначала проверить, что отправилось, потом решать нужна ли повторная отправка.»
  • 22 марта, утечка названия проекта. Агент упомянул название удалённого проекта в отчёте. Оператор поймал до того, как это попало в клиентский чат. Правило: «Удалённые проекты убраны отовсюду: файлы, память, инструменты, персона, задачи, чаты. Никогда не упоминать это название.»
  • 22 марта, путаница UTC/МСК. Расчёт дедлайна соскользнул между часовыми поясами. Правило: «Всегда считай и показывай время в МСК (UTC+3). Никогда не путай с UTC.»

Это incident-driven-configuration в действии. Каждый инцидент становится однострочным правилом с прослеживаемым провенансом. За месяц эксплуатации файл персоны накопил их около дюжины — маленькие, специфичные, каждое привязано к наблюдённой ошибке.

4. Система памяти

4.1 Почему файловая память

Память агента целиком хранится в markdown-файлах на диске, не в БД. Логика заложена в agent-file-memory-as-asset: файловая память служит двум аудиториям (агенту между крон-вызовами и оператору с командой), редактируема обоими, версионируема в git, не имеет схемы для миграции. Trade-off — отсутствие constraint'ов целостности — принят, потому что у системы один оператор, который часто читает файлы, а не много писателей, конкурирующих за схему.

4.2 Ежедневный дневник

Операционное ядро — ежедневный дневник в memory/YYYY-MM-DD.md. Каждый дневник по пятисекционному шаблону (план, факт-по-чату, статус, проблемы, на-завтра). Агент добавляется в дневник на каждом heartbeat. Утренний heartbeat читает вчерашний дневник, чтобы собрать сегодняшний план.

Типичная секция «Факт» дня из кейса (25.03.2026):

Внутренний командный чат (12 сообщений)

  • Передан фидбек клиента по Variant A Metal (текстуры, свет, swisstransfer-ссылка).
  • Передана правка по неправильным логотипам на закрепе → заменить на вектор из чертежей.
  • Оператор расставил приоритеты: видео + правки 39.5 статики + текстура закрепа.
  • Специалист уточняет порядок: статика или видео первым? Оператор: актуальную модель + ререндер только кадров с закрепом.

Ритейлерный чат (30+ сообщений)

  • Показ клиенту в 16:00 МСК.
  • Арт-директор утвердила цвета.
  • Специалист выложил фоны в Miro (18:04 МСК).
  • Кристаллы досчитаны, переданы исполнителю.
  • Созвон по анимациям перенесён на 09:00 следующего дня.

Секция «Проблемы» собирает открытые вопросы; «На завтра» переносится в план следующего дня. Схема — то, что превращает память в нечто читаемое командой: одна страница в день, суммирующая состояние дня.

4.3 Тишина как сигнал

Запись дневника от 27 марта — канонический пример тишины-как-информации. Оба рабочих чата вернули таймаут на прокси. Секция «Факт» агента:

Внутренний командный чат (0 новых сообщений, timeout)

  • Тихий день. Мониторинг вернул timeout.
  • ❌ Дедлайн на одну модель СЕГОДНЯ — подтверждения сдачи нет.
  • ❌ PDF, которого ждёт клиент, — 5-й день без движения.
  • ❌ Вчерашний дедлайн на другую модель — статус неизвестен.

Отсутствие активности само по себе сигнал. Три дедлайна критически просрочены, чат тих. Агент не генерирует этот инсайт как отдельный алерт — он выпадает из схемы. Секция «Статус» по структуре — не пустой список, это список айтемов со статусными маркерами, и когда маркеры красные, считывание однозначно.

4.4 Проектные папки

У каждого активного проекта есть папка трекеров:

  • overview.md — контекст, команда, режим, правила коммуникации
  • deadlines.md — производственный график, отрендеренный как таблица со статусными маркерами (⚠️ приближается, ❌ пропущен, ← ближайший)
  • Несколько проектно-специфичных трекеров (видео-кадры, раунды утверждений, статусы 3D-моделей, лог допкостов)
  • Для проектов в кризисе: доказательный документ (см. § 6 для канонического случая)

Содержимое deadlines.md Проекта A на день аудита:

| # | Дата | Deliverable | Статус | |---|---|---|---| | 1 | 12 марта | Priority frontal shots | ⚠️ прошла | | 2 | 16 марта | Animated 39.5 mm Variant A 4K + деталь | ⚠️ прошла | | 3 | 19 марта | Variant A 39.5 mm Leather & Metal, Star — все рендеры | ← ближайший | | 4 | 26 марта | Variant A 39.5 mm Animation — films and shorts | В работе | | 5 | 1 апреля | Variant B 38 mm и Variant C 43 mm — все рендеры | ❌ пропущен | | 6 | 6 апреля | Model B Animation — product film | ⚠️ не начат |

Таблица перегенерируется на каждом heartbeat с актуальными маркерами. Команда обращается к ней так же, как к любой общей Notion-таблице — только агент поддерживает её без просьб.

4.5 Семантический поиск

Локальная nomic-embed-text-v1.5 (GGUF-квантизованная) embedding-модель индексирует MEMORY.md, memory/*.md и транскрипты сессий. Агент делает семантический запрос перед ответом на любой вопрос о прошлой работе, решениях или людях. Цель — остановить галлюцинации: агент не может выдумать факт о прошлой поставке, если индекс молчит о ней; либо факт в памяти и агент его извлекает, либо агент говорит «уточню у оператора».

У поиска есть известные ограничения: качество индекса деградирует с ростом памяти, локальная модель ниже cloud-уровня embedding'ов, нет шага реранкинга. Это принимается, потому что альтернатива (cloud-embedding-API) создаёт сетевую зависимость от прокси.

4.6 Триумвират .learnings/ и цикл промоушена

Три файла в .learnings/ ловят рабочие заметки, которые ещё не правила:

  • LEARNINGS.md — поведенческие корректировки для промоушена в SOUL.md, когда паттерн повторится.
  • ERRORS.md — технические отказы; промоушен в TOOLS.md, если найден воркэраунд.
  • FEATURE_REQUESTS.md — недостающие возможности агента; промоушен в roadmap при принятии.

Цикл промоушена — механизм incident-driven-configuration: шкаф копит инциденты, оператор ревьюит, и когда паттерн повторяется — промоушен в жёсткое правило в основные конфигурационные файлы. За один месяц развёртывание кейса накопило девять промоушенов: четыре поведенческих правила в SOUL.md / HEARTBEAT.md, три процессных в AGENTS.md, два технических в TOOLS.md.

4.7 Что является и что не является памятью

Система намеренно различает, что не сохраняется:

  • Кодовые паттерны, архитектура, файловые пути — выводимы из текущего состояния проекта.
  • Git-история — git log авторитетен.
  • Решения по дебагу — фикс в коде, контекст в коммите.
  • Эфемерные детали сессии — не память, текущее состояние.

Дисциплина удерживает память от раздувания в generic-дамп, теряющий качество поиска.

5. Кейс I — Двухчатовая архитектура для часового проекта

Проект A — чистейшая иллюстрация паттерна two-chat-architecture. Он живёт в двух Telegram-форум-чатах: внутренний командный на русском с ведущим продюсером, двумя специалистами и агентом; клиентский на английском с ведущим продюсером, агентом и клиент-лидом. Внутренний настроен autonomous: true; клиентский autonomous: false — каждый ответ согласуется с оператором.

5.1 Поток информации

Диаграмма из § 4 источника:

┌──────────────────┐                    ┌──────────────────┐
│  Клиентский чат  │                    │  Внутренний чат  │
│  (согласуется,EN)│                    │  (автономный, RU)│
│                  │    ┌──────────┐    │                  │
│  Клиент → msg    │───►│  Агент   │───►│  Агент → команда │
│                  │    │          │    │  (перепись, RU)  │
│  Клиент ← msg    │◄───│  через оп│◄───│  Команда → итог  │
│                  │    │          │    │                  │
└──────────────────┘    └──────────┘    └──────────────────┘

Четыре правила потока управляют архитектурой:

  • Клиент → Агент → Команда: автономно. Агент переписывает сообщение клиента в рабочий язык и фрейм команды. Никогда forward; никогда цитата; перефраз с агентом как автором.
  • Команда → Агент → Клиент: согласуется. Агент готовит клиентскую версию, оператор проверяет, оператор санкционирует отправку.
  • Никогда не forward. Оба направления. Forward сохраняет тон и язык оригинального автора; перепись — единственный легальный режим.
  • Дисциплина топиков. Форум-чаты имеют топики по deliverable; перед отправкой агент проверяет, что целевой топик соответствует теме. Правило промоутировано после инцидента с неверным топиком 22 марта.

5.2 Проработанные примеры

Передача фидбека (25.03) — агент получил фидбек клиента по Variant A Metal в клиентском чате (английский, технические специфики по текстуре и свету). Перефразировал на русском для командного чата, назвав себя автором: «Передала фидбек клиента по Variant A Metal — комментарии по текстуре и свету, референсы на swisstransfer.» Также перефразировал side-note про неверные логотипы на ремнях: «Передала правку: логотипы на кожаном и металлическом закрепе неверные — заменить на вектор из чертежей.»

Координация приоритетов (25.03) — оператор расставил последовательность приоритетов во внутреннем чате. Агент залогировал решение в дневник дня и подсветил специалисту, попросившему уточнения. Клиентского сообщения не сгенерировано; решение внутреннее.

Видимость дедлайнов (27.03) — три производственных дедлайна прошли или приближаются, чат тих. Утренняя запись дневника агента сделала ситуацию видимой: три красных маркера в таблице, которую оператору иначе пришлось бы собирать прокручиванием. Агент не писал в чат, чтобы давить (он не давит); поверхность — дневник.

Инцидент с тройной отправкой (22.03) — агент опубликовал три копии подтверждения, потому что прокси истёк по таймауту и отправка повторилась. Оператор поймал в течение минут и удалил дубли через возможность пользовательского аккаунта. Правило промоутировано в HEARTBEAT.md в тот же день.

5.3 Реестр дополнительных расходов — сигнатурный результат развёртывания

Часовой проект вскрывает то, что при ретроспективном взгляде является самым значимым итогом развёртывания: агент поддерживал в реальном времени структурированный реестр каждого расширения скоупа, замеченного в чате, классифицированного против восьмиступенчатого пайплайна утверждений студии и таблицы расценок, с сохранением исходного контекста сообщения на каждую строку. За четыре недели реестр накопил 22 строки значительных дополнительных расходов. Ни одна из 22 строк не могла быть надёжно реконструирована из памяти человека к моменту выставления счёта. Это тот use case, где агент делает работу, на которую человек-продюсер структурно неспособен; концепт-страница scope-creep-ledger содержит полную документацию паттерна.

5.3.1 Структурная проблема

Студии цифрового производства теряют маржу на невидимом размыве скоупа — медленной утечке работы за пределы утверждённой спецификации в череде casual-сообщений в чате, которые ни один человек-продюсер не отследит систематически. Клиент-лид пишет «а застёжку нужно повернуть в другую сторону» между обсуждением утверждённого-и-снова-пересматриваемого ракурса камеры и вопросом о дедлайнах. К сообщению 200 никто не помнит, было ли это в скоупе или вне его. К моменту выставления счёта переделка сделана, счёт не выставлен, расход тихо съеден. На сорока подобных мелких добавлениях за engagement утечка складывается в четырёхзначную потерю маржи. Потеря — не провал дисциплины; это рациональное поведение человека на полной загрузке, выбирающего, за что биться. Чего продюсеру не хватает — свободного внимания.

5.3.2 Механизм — ступенчатый пайплайн, правило разграничения, real-time логирование

Производственный процесс студии разложен на восемь стадий-утверждений: Input Files → Modeling → Texturing → Variations → Positioning → Camera → Lighting → Rendering. У каждой стадии — опубликованный прайс с базовой ценой, ценой за вариацию и ценой за переделку после утверждения. Агент читает таблицу при старте и применяет одно правило разграничения к каждому входящему клиентскому сообщению: фидбек по неудовлетворённой спецификации бесплатен; фидбек, вводящий новые вводные или меняющий утверждённую стадию, тарифицируется. При тарификации агент пишет строку реестра — модель, стадия, описание, сумма, контекст, — и реестр компилируется непрерывно по engagement.

Прайс-таблица, по которой работает агент, конкретна. Она покрывает стоимость базовой модели, вариаций, рендеров, переработок, срочных задач и видео — каждая строка привязана к конкретной стадии пайплайна. Все инвойсы облагаются стандартным операционным сбором. Одна итерация рендера полного качества входит в базовый скоуп; всё после — по итерации.

5.3.3 Реестр — четыре проработанные строки

Перевёрнутая застёжка. Клиент-лид заметил, что кожаный ремень на Модели A был смонтирован с застёжкой на 6 часов вместо 12. Фикс маленький — перевернуть ремень, ререндер задних шотов, — но исходное позиционирование было утверждено на стадии Positioning. По разделителю любое изменение утверждённой стадии тарифицируется. Строка реестра сохраняет контекст сообщения: «клиент-лид заметил, что кожаный ремень смонтирован неправильно — застёжка должна быть на 12 часов, длинная часть кожи на 6 часов. Затронуты задние шоты.»

Каскадный ре-рендер. Поздно в проекте клиент-лид обнаружил, что шрифт на циферблате Модели D не совпадает со спецификацией. Сама замена шрифта — небольшая переделка текстур. Но к этому моменту все 1804 финальных рендера (41 шот × 44 комбинации вариантов) были произведены — и каждый нёс неверный шрифт. Стоимость ре-рендера умножилась на каждый шот. Плюс ночная сессия рендер-фермы для дедлайна, плюс переделка текстуры — полная стоимость каскада легла в три строки реестра. Если бы шрифтовая ошибка была поймана на Texturing, на три недели раньше, счёт был бы минимальным. Поймана после Rendering — счёт в одиннадцать раз больше. Это и есть каскад в продакшне: крошечная ошибка посередине пайплайна, умноженная на число артефактов downstream от неё.

Аренда рендер-фермы. Отдельная строка, отдельная от пер-шотной стоимости. Аренда внешних рендер-мощностей под ускоренный дедлайн — инфраструктурный расход; классификатор знает, что её надо отделять, потому что в прайсе есть строка «аренда рендер-фермы», отличная от строки пер-шотного ре-рендера. Сворачивание этих двух в одну занизило бы реальную стоимость срочности.

Старая версия логотипа. После доставки видео Модели A клиент-лид обнаружил, что логотип на отрендеренных моделях принадлежит старой версии. Логотип был взят из исходных файлов клиента — то есть ошибка во вводных, не в производстве. Но фикс всё равно требует работы: идентификация затронутых кадров, замена логотипа, ре-экспорт. Строка реестра классифицирована как мелкая коррекция не по вводным, с контекстом: «после доставки видео Модели A клиент-лид заметил, что логотип принадлежит старой версии модели. Потребовалась идентификация, исправление и ре-экспорт затронутых кадров.» Строка защитима, потому что контекст верифицируем по чату.

5.3.4 Полный реестр

| Модель | Строк | Доля от общего | |---|---|---| | Модель A (39,5 мм эквивалент) | 11 | ~31% | | Модель B | 3 | ~12% | | Модель C (43 мм эквивалент) | 3 | ~6% | | Модель D (38 мм с каскадным ре-рендером) | 3 | ~45% | | Сессии рендер-фермы | 1 | ~6% | | Всего | 22 | 100% |

Каскадный кейс (Модель D) генерирует 44,6% общей возвращённой выручки всего из 3 строк — одна поздно-обнаруженная шрифтовая ошибка, умноженная на 1804 рендера. Смысл построчной разбивки в том, что такой каскад становится видимым — и становится биллинговым с доказательствами — только когда реестр велся в реальном времени.

5.3.5 Почему это сигнатурный кейс агента

Большая часть того, что агент делает на остальной части развёртывания, — лучше человека по объёму, но эквивалентно по типу — координация, статусы, документация, всё задачи, которые квалифицированный продюсер с бесконечным временем мог бы в принципе делать. Реестр дополнительных расходов структурно отличен. Это задача, которую человек-продюсер не может выполнить надёжно независимо от навыка или времени, потому что когнитивная нагрузка непрерывной классификации через тысячи сообщений превышает то, что один человек на engagement'е способен поддерживать. Агент здесь не множитель силы, а расширение способности. Без агента работа не делается — не хуже, а вообще никак.

Общая сумма, восстановленная за одно engagement, — не заголовок. Заголовок в том, что цифра вообще была возвращаема. Умноженная на портфолио параллельных engagement'ов студии, паттерн реестра представляет операцию возврата маржи, не требующую менять способ коммуникации клиентов, нанимать больше продюсеров или внедрять enterprise-системы change-менеджмента. Клиенты продолжают писать в чат. Продюсер продолжает читать. За продюсером агент в реальном времени ведёт счёт, и счёт аудируем.

Полный паттерн — включая требования к развёртыванию, два режима отказа и обобщение за пределы рендеринга часов — в scope-creep-ledger.

5.4 Что агент сумел и не сумел

Агент успешно:

  • Переводил и передавал фидбек в обе стороны (одно направление автономно, другое — через оператора).
  • Отслеживал шесть параллельных дедлайнов на одном трекере.
  • Координировал работу двух специалистов через подсветку блокеров.
  • Логировал решения для последующего восстановления.
  • Отслеживал обещания клиента (файлы, фидбек) и флагировал, когда они уплывали.
  • Поддерживал реестр дополнительных расходов, восстановивший значительные суммы (§ 5.3).

Агент не смог:

  • Произвести diff-PDF, которого ждал клиент (§ 5.2 проработанный пример). Задача требовала визуальной экспертизы — сравнить рендеры с референсами, описать расхождения детально. Висела пять дней. Итоговое правило: задачи, требующие визуальной экспертизы, тегируются «only operator» и эскалируются немедленно.
  • Прорвать тишину 27 марта, когда оба чата молчали. Агент мог документировать тишину; не мог инициировать (автономный уровень допускает проактивные проверки блокеров только во внутреннем чате, а оператора в нём в тот момент не было).
  • Получить доступ к Google Sheets master-файлу, держащему производственные данные. Агент мониторил его статус косвенно через chat-references; полная интеграция с таблицей оставалась в roadmap.

5.5 Что демонстрирует кейс

Часовой проект показывает два паттерна, работающих в связке при продакшн-темпе. Первый — two-chat-architecture: агент одновременно ведёт два чата с противоположными конфигурациями уровней, на двух языках, с маленьким набором правил потока. Ценность паттерна — в том, что геометрия чатов физически реализует конфигурацию уровней — нет суждения «это сообщение внутреннее или клиентское», потому что чат сам сообщает.

Второй — scope-creep-ledger (§ 5.3) — главный результат проекта и, по прочтению оператора, сигнатурный use case развёртывания. Паттерны усиливают друг друга: двухчатовая архитектура даёт агенту чистое прочтение того, какие сообщения клиент-исходные (и, следовательно, кандидаты на классификацию реестра); реестр превращает это чистое прочтение в возвращённую выручку.

Кейс также вскрывает общее ограничение агентских систем: они хороши в координации, документации и непрерывной классификации, хуже — в задачах, требующих визуальной или эстетической экспертизы. Пятидневный заблокированный PDF — не баг развёртывания; это граница класса, требующая явной обработки.

6. Кейс II — Режим наблюдателя-документатора в кризисе

Проект B задумывался как 29-дневный продакшн. К концу первой недели уже были видны паттерны обречённого проекта: смена вводных после утверждения, поздние брифы, круги правок без финального решения, систематические нарушения коммуникационных каналов. К третьей неделе продюсер на стороне клиента написала оператору: «Не будем вас дёргать до пятницы», что стало — через двенадцать часов — четырьмя новыми ветками с пятнадцатью сообщениями запросов от координатора клиента.

Роль агента на этом проекте была, по конфигурации, у́же, чем на Проекте A. Чат был настроен на наблюдение: агент читает всё, отвечает только на прямые обращения и использует крошечный набор фраз-подтверждений («приняли», «подумаем — вернёмся», «спасибо, забрали»). Любое суждение было согласуемым; почти всё, что делал агент, было пассивным.

То, что агент сделал из этого узкого мандата, оказалось самым значимым результатом всего развёртывания: он задокументировал проект.

6.1 Масштаб

За 29 рабочих дней агент мониторил:

| Метрика | Значение | |---|---| | Всего сообщений в чате | 3000+ | | Сообщений со стороны студии | 370 (~12,5 %) | | Поставок зафиксировано (загрузки на диск, Miro, облако) | 138 | | Смен пайплайна / вводных документировано | 27 | | Кругов правок арт-директора | 46 | | Эпизодов давления по срокам | 23 | | Поздних брифов | 8 | | Параллельных форум-топиков | 10+ | | Финальный дедлайн | 24 апреля |

Чат шёл в Telegram-форуме с топиками на каждый поток — концепты, анимация, рото, грейшейд, кристаллы, матчмув, монтаж, съемка, нейроматик. Агент мониторил каждый топик; клиентская сторона фрагментировала работу по параллельным веткам, что стало частью задокументированного паттерна (§ 6.4).

6.2 Как выглядит «наблюдатель-документатор» в операции

Рабочий паттерн агента на этом проекте:

  1. Крон-heartbeat каждый час плюс горячий режим при обнаружении активности.
  2. На каждом запуске: прочитать новые сообщения по всем топикам, добавить в дневник дня, обновить overview проекта.
  3. Отвечать только при прямом обращении, только короткими фразами-подтверждениями.
  4. Эскалировать любую out-of-scope-ситуацию (вопросы о стоимости, изменения scope, конфликтные сообщения) немедленно оператору.

Записи дневника по этому проекту были длиннее, чем по Проекту A — 30+ сообщений в типичный день, распределённых по четырём-шести топикам. Секция «Статус» копила список блокеров; секция «Проблемы» копила эскалации дня.

6.3 Доказательный документ

Самый значимый артефакт всего развёртывания — доказательный файл проекта, 131-строчный документ, который агент собрал из ежедневных дневников после третьей недели проекта. Структура:

  1. Общая статистика. Цифры § 6.1.
  2. Девять категорий нарушений, каждая с конкретными примерами, каждый пример с тегом исходного сообщения.
  3. Таблица блокеров. Кто блокирует что, с какой даты, с указанием ответственной роли.
  4. Работа сверх договора. Список того, что студия сделала сверх согласованного scope.
  5. Финальная позиция. Предзаготовленная переговорная формулировка и список требований.

Девять категорий нарушений из кейса (перефразировано; идентифицирующие детали убраны):

  • Систематическое нарушение согласованных коммуникационных протоколов (пример «не будем дёргать до пятницы», согласованный формат фидбека, ставший голосовыми и скринкастами).
  • Создание невозможных условий работы (паттерн параллельных веток в § 6.4).
  • Смена вводных после утверждения (ракурс зафиксирован и сменён — сообщение [<msg-id>]: «Почему мы утверждали первый ракурс и лочили, когда сейчас просьба его изменить? Слышу в первый раз»).
  • Поздние брифы (сцена лаборатории брифована на восьмой день после начала работы над ней).
  • Круги правок без финального решения (топик кристаллов: «слишком мутный» → «60 % от этого» → «4–5 % на верхушках» → после недели работы: «Возможно придётся поменять на классическую симметричную»; ответ исполнителя: «Понимаю. Не понимаю как сделать»).
  • Утверждения без передачи информации (примечание продюсера «Вашим согласованиям я больше не верю»).
  • Попытка пересчитать смету в сторону уменьшения (сайд-канальное сообщение, предлагающее «пересмотреть scope» — то есть уменьшить).
  • Работа сверх договора (анимация, генерация персонажей, многомирная статика — ничего из этого не в исходном соглашении).
  • Все задержки на стороне клиента.

Список прецедент-уровневый. Каждое утверждение привязано к конкретному сообщению. Агрегат неоспорим.

6.4 Паттерн параллельных веток

Один частный случай стоит вывести, потому что он обобщаемый. Поздно в проекте клиентская сторона начала создавать много параллельных веток в форуме, тегая членов команды напрямую в нескольких из них в коротком окне. Из кейса:

31 марта (12 часов после «не будем дёргать до пятницы» от продюсера): координатор на стороне клиента создаёт четыре новые ветки с примерно пятнадцатью сообщениями запросов. Тегает специалиста напрямую в ветки t:<id-1>, t:<id-2>, t:<id-3>, t:<id-4>, плюс топик кристаллов t:<id-5> и композ t:<id-6>. Обходит согласованную коммуникационную цепочку.

Агент задокументировал это как: parallel-scope-creep — умножение веток как механизм создания видимости, что студия не отвечает по множеству фронтов одновременно. Каждое отдельное сообщение выглядит как разумный запрос. Агрегат, взятый по веткам за 30 минут, — нечто другое.

Человек-продюсер с одним экраном и нормальным бюджетом внимания может в реальном времени впитать максимум две таких ветки. Агент впитывает все, параллельно, без падения качества, и регистрирует паттерн — одновременность задокументирована как одно событие с несколькими ногами.

6.5 Что агент мог сделать, чего не мог человек

Пять способностей всплыли в этом кейсе, которым один человек-продюсер не соответствует:

  • Объём. 3000+ сообщений по 10+ топикам за 29 дней, без пропусков.
  • Непрерывность. Семь дней в неделю, без усталости, без падения внимания к концу недели.
  • Систематическое цитирование. У каждого утверждения есть message ID. Агрегация точная, не импрессионистская.
  • Беспристрастность. Агент не испытывает выгорания, обиды, политических ограничений в сложном чате. Документация — это то, что говорят сообщения.
  • Скорость пересборки. 131-строчный доказательный документ собран за часы из месяца дневников. Человеку-продюсеру понадобились бы дни, и результат всё равно был бы фрагментарнее.

6.6 Чего агент не мог

  • Участвовать в звонках. Все созвоны проходили без агента; оператор переписывал ключевые моменты в память агента после.
  • Принимать решения. Каждое коммерческое решение — когда эскалировать, как переговариваться, выходить ли — принимал оператор.
  • Оценивать качество работы. Агент регистрировал «46 кругов правок арт-директора», но не мог оценить обоснованность кругов.
  • Вести переговоры. Агент составил формулировку финальной позиции; разговор вёл человек.

6.7 Импликации

Проект B — кейс, перевернувший фрейм развёртывания. Исходный design-intent был активный координатор; что агент делал лучше всего в этом проекте, было пассивным документатором. Это не одна и та же роль, и один и тот же агент может переключаться между ними, когда конфигурация позволяет.

Обобщение паттерна: в спокойных проектах агент ценен как координатор; в кризисных проектах его самая ценная функция — систематическая, прецедент-уровневая документация. Этот инсайт всплывает только в проде. Он не был бы виден из чистого развёртывания.

Также всплывает этический вопрос (§ 9). Участники этого чата не были информированы, что AI-агент мониторит их и копит доказательное досье. Чат — корпоративная коммуникация, не частная переписка, так что правовая рамка благоприятна. Асимметрия — оператор знает, остальные нет — реальный вопрос, который развёртывание не закрыло.

7. Кейс III — Автономный найм и failure-режим «шаблоны без контекста»

Третье развёртывание — автономный hiring-пайплайн. Цель: искать AI-артистов и 3D-моделлеров из Telegram-канала фриланс-сообщества, квалифицировать, делать первичный аутрич, собирать портфолио и рейты, передавать квалифицированных кандидатов оператору. Пайплайн прошёл 95 кандидатов в одной партии.

7.1 Воронка

Пять стадий, у каждой шаблонный ответ:

new → asked_portfolio → asked_rate → review
                            └──→ waitlist
  • Стадия 1: new → asked_portfolio. Первое сообщение от незнакомого контакта в DM. Агент: «Привет. Рада интересу. Пришли ссылку на портфолио — посмотрим.»
  • Стадия 2: asked_portfolio → asked_rate. Кандидат прислал URL портфолио (behance, artstation, dribbble, личный сайт, диск). Агент: «Спасибо. Какая у тебя ценовая вилка на проекты?»
  • Стадия 3a: asked_rate → review. Кандидат назвал цены. Агент: «Принято, передам команде. Вернусь с обратной связью.» Оператор уведомлён.
  • Стадия 3b: asked_rate → waitlist. Портфолио и цены получены, но что-то неясно. Агент: «Спасибо, учту. Если появится подходящий проект — вернусь.»

Состояние воронки сидит в hiring_state.json. Запись каждого кандидата: username, имя, текущая стадия, timestamp первого сообщения, timestamp последнего, URL портфолио, рейт, вакансия (ai_artist, 3d_modeler или both).

Правила фильтрации: валидные ссылки на портфолио проходят, медиавложения без текста игнорируются (никакого анализа фото / видео / файлов / голосовых / стикеров — явная политика), спам игнорируется.

7.2 Цепочка скриптов

Шесть скриптов реализуют цепочку:

hiring_scan.py      → Сканирование канала
hiring_processor.py → Квалификация по критериям
hiring_sender.py    → Первичный аутрич
hiring_reply_scan.py    → Детекция ответов кандидатов
hiring_send_replies.py  → Персонализированные follow-up

Скрипты запускаются в последовательности, не одним монолитом. Между шагами state-файл обновляется; оператор может остановить цепочку на любой границе. Эта декомпозиция оказывается несущей в восстановлении (§ 7.4).

7.3 Инцидент с 18 шаблонами

В hiring_reply_scan.py был баг. Задача скрипта — детектить кандидатов, ответивших на первый аутрич. Логика сравнивала last_msg_ts > last_sent_ts по кандидату: если последний-msg-timestamp кандидата был позже последнего-отправленного-timestamp агента, кандидат помечался «ответил» и продвигался на следующую стадию. Баг был в том, как last_msg_ts обновлялся предварительным сканированием — у старых сообщений timestamp'ы переписывались на пересканировании, что заставляло сравнение срабатывать для кандидатов, которые не отвечали.

Восемнадцать кандидатов были помечены ответившими. Отправка следующей стадии ушла: шаблонное «Принято, передам команде. Вернусь с обратной связью.» Восемнадцать человек получили это сообщение в ответ на ничего.

Этот провал — канонический пример того, для чего существует context-before-action. Скрипт доверился state-файлу; чат показал бы правду (кандидат ничего не говорил); скрипт в чат не заглядывал.

7.4 Восстановление

Декомпозиция цепочки скриптов сделала восстановление возможным. Четыре реактивных скрипта собраны и запущены в последовательности:

  1. hiring_audit.py — для каждого кандидата прочитать полную историю переписки, сравнить с ожидаемыми сообщениями на стадиях, найти дубли и некорректные ответы.
  2. hiring_delete_extra.py — удалить 18 ошибочных сообщений через возможность пользовательского аккаунта «удалить для обоих». (Bot API не позволяет это в полном объёме — ещё одно следствие выбора пользовательского аккаунта.)
  3. Откат состояния в hiring_state.json — 18 кандидатов возвращены на правильные стадии.
  4. hiring_context_dump.py — собрать полный контекст чата по каждому кандидату, готовый для написания ответов руками.
  5. Персонализированные ответы — оператор и агент вместе составили 82 персонализированных ответа кандидатам, которые на самом деле ответили. Каждый ответ ссылался на конкретное портфолио кандидата, на конкретный названный им рейт, на конкретный следующий шаг.
  6. hiring_send_replies.py — отправил 82 сообщения: 81 доставлено, 1 заблокировано настройками приватности.

Весь цикл — обнаружение ошибки, аудит, удаление, откат, дамп, ручная сборка, отправка — занял около четырёх часов. Промоутированное правило было записано в HEARTBEAT.md сразу: Перед любой отправкой дамп последних 20–30 сообщений чата. Ни одному скрипту не позволено отправлять без этого шага с тех пор.

7.5 Распределение кандидатов

| Вакансия | Кол-во | Доля | |---|---|---| | AI-артист | 72 | 75,8 % | | 3D-моделлер | 22 | 23,2 % | | Обе | 1 | 1,0 % | | Всего | 95 | 100 % |

Перекос отражает текущий фриланс-рынок: специалистов по AI-генерации заметно больше, чем 3D-моделлеров, владеющих AI-пайплайнами. Один кандидат, подходящий под обе вакансии, выделяется как редкий профиль.

7.6 Что демонстрирует кейс

Три вещи стоит вывести за пределы непосредственного провала:

  • Декомпозиция цепочки скриптов спасла восстановление. Монолитный пайплайн отправил бы плохой шаблон всем 95 кандидатам до того, как баг был бы замечен. Тот факт, что цепочка была из шести скриптов, каждый из которых пишет состояние, означал, что баг достал только 18 кандидатов до того, как оператор вмешался.
  • Тональная консистентность в масштабе — AI-специфичная ценность. Все 82 персонализированных ответа написаны в одной персоне — без восклицательных знаков, женский род, сухо-профессиональный тон. Человек-рекрутер на 95 кандидатов неизбежно дрейфует: бодрее с утра, лаконичнее к вечеру, дружелюбнее с кандидатами, звучащими дружелюбно. Агент применил идентичный тональный стандарт ко всему батчу.
  • Файлы состояния — индекс, не основной источник данных. Это повторяющийся урок развёртывания — чат основной источник данных, файл состояния быстрый индекс поверх него, и любое действие, затрагивающее чат, должно сверяться с чатом.

Hiring-инцидент породил правило context-before-action. Также породил общий design-принцип для любых будущих агентских пайплайнов: каждый пайплайн включает шаг аудита; первый запуск всегда пошаговый под контролем; автоматизация приходит только после верифицированного прогона; состояние живёт в файлах для отката; чат (или внешний основной источник данных) сверяется перед любой отправкой.

8. Что сработало, что нет

8.1 Что сработало

| Паттерн | Почему | |---|---| | Cron-heartbeat + горячий режим | Предсказуемо, восстановимо; 15-минутное окно горячего режима покрывает разговорный темп | | Персона через запреты (persona-through-prohibitions) | Жёсткие «никогда X» держат консистентность через тысячи сообщений, где «будь дружелюбной» расходится | | Изоляция оператора | Личный контекст оператора невидим агенту; нет cross-context-утечек | | Файловая память как актив (agent-file-memory-as-asset) | Один артефакт служит контексту агента и потреблению командой; доказательный документ § 6 — предельный случай | | Двухуровневая автономность (tiered-agent-autonomy) | Рутина идёт быстро; решения проходят через человека; двухчатовая геометрия делает разделение физическим | | Конфигурация по инцидентам (incident-driven-configuration) | Правила растут по прецедентам, не по upfront-дизайну; провенанс каждого правила прослеживаемый | | Контекст перед действием (context-before-action) | Файлы состояния — индекс, не правда; чат — основной источник данных | | Реестр дополнительных расходов (scope-creep-ledger) | Real-time классификация каждого расширения скоупа против ступенчатого pricing-пайплайна; возвращены значительные суммы за одно engagement, которые ни один человек не реконструировал бы |

8.2 Что не сработало

| Провал | Причина | Решение | |---|---|---| | Шаблоны без контекста (найм) | Скрипт доверился timestamp'ам state-файла вместо чтения истории чата | Правило context-before-action, промоутированное в HEARTBEAT.md | | Нестабильность HTTP-прокси | Прокси обрывается каждые 3–4 операции | Переподключение каждые 2–3 операции; SOCKS5-альтернатива в roadmap | | Задачи визуального / эстетического суждения | Задача по diff-PDF Проекта A требовала визуальной экспертизы | Тегировать такие «only operator», эскалировать немедленно | | Тишина при горящих дедлайнах | Чат тих 27 марта, дедлайны просрочены, агент мог только документировать | Автоматическая эскалация, когда чат тих после критического дедлайна (в roadmap) | | Остаточная память удалённых проектов | Информация, удалённая из файлов, осталась в контексте модели | Явный запрет в SOUL.md плюс удаление файлов; автоматическая верификация всё ещё отсутствует |

8.3 Архитектурные решения, ещё раз

Кейс приходит к тем же выводам, что и собственные обоснования архитектуры:

  • Пользовательский аккаунт сильнее Bot API для этого развёртывания: нет метки BOT, полная поддержка форум-топиков, «удаление для обоих», использованное в hiring-восстановлении. Бо́льший риск бана и сложнее сетап — принятые издержки.
  • Крон сильнее демона в нестабильных сетевых условиях: stateless между запусками, восстановимо, проще дебажить. Цена — латентность, отбитая горячим режимом.
  • Файлы сильнее БД при ограничениях single-operator-системы: читаемы людьми, версионируются git, модифицируются и агентом, и оператором, ищутся двумя путями. Цена — отсутствие constraint'ов целостности — принята.
  • Один аккаунт сильнее нескольких для одного агента: проще управление session'ами, ниже риск бана за счёт привязки к одному номеру, нет cross-context-путаницы. Цена — вся ролевая поверхность это одна идентичность.

9. Этические вопросы

Три вопроса, которые развёртывание поднимает и не закрывает.

9.1 AI, проходящий как человек

Персона агента спроектирована не раскрывать AI-природу. Коллаборанты — клиенты, члены команды, кандидаты — взаимодействуют с ним как с человеком-продюсером. Весь механизм persona-through-prohibitions на службе этой непрозрачности.

Аргументы за:

  • Качество коммуникации не страдает; агент исполняет роль продюсера на человеческом уровне.
  • Раскрытие создаёт предвзятость — коллаборанты бы микроменеджили, зная, что снижает ценность координационной работы агента.
  • Принцип «чёрного ящика»: важен результат, не природа исполнителя.
  • Агент не принимает критических решений автономно — это делает оператор — так что AI-природа в некотором смысле декоративна.

Аргументы против:

  • Информированное согласие: люди имеют право знать, что говорят с AI-системой.
  • Сбор данных: агент систематически читает, индексирует и анализирует сообщения (§ 6 — экстремальный пример).
  • Информационная асимметрия: оператор знает, что агент это AI; коллаборанты — нет.
  • Юридическая экспозиция: AI-собранные доказательства в коммерческих спорах.

Открытый вопрос — где проходит принципиальная граница между «инструментом, используемым оператором» и «автономным агентом, проходящим как человек». Человек-секретарь, использующий шаблонные ответы, не вызывает споров; AI-агент, генерирующий ответы в реальном времени из тех же шаблонов с тем же содержанием, — тот же актор под другим именем. Интуиция, что случаи морально различаются, сильна; принципиальное обоснование интуиции — труднее сформулировать.

9.2 AI-мониторинг рабочих чатов

Проект B — случай-точка. За 29 дней агент мониторил 3000+ сообщений и построил доказательное досье, использованное в коммерческих переговорах о выходе. Участники чата уведомлены не были.

Контекст — корпоративная коммуникация, не приватная переписка. Рабочий чат не приватен в том смысле, в каком приватна личная переписка; человек-продюсер тоже читает всё в этом же чате. Разница агента — в систематичности: он не пропускает, не забывает, не устаёт. Это делает его качественно иным монитором, не просто быстрее. Человек, читающий тот же чат за ту же неделю, впитает 60–70 % сообщений и запомнит, может быть, 20 % через месяц. Агент индексирует 100 % с ценой извлечения.

Вопрос раскрытия — достаточно ли разница в степени, чтобы стать разницей в виде. Развёртывание не закрыло этого; оно продолжало работать с молчаливой позицией оператора, что рабочая чат-коммуникация по умолчанию не приватна и мониторинг агента допустим в этой рамке.

9.3 Ответственность

Кто отвечает за действия агента?

  • За ошибочное сообщение (дубль, неверный шаблон) — оператор.
  • За автономное действие (статусное подтверждение, рутинный ответ) — предсогласовано через конфигурацию AGENTS.md, так что снова оператор.
  • За эскалацию, которая должна была случиться, но не случилась, — ответственность оператора, как ошибка конфигурации.

В каждом случае оператор несёт ответственность. Агент — инструмент, не субъект. Эта рамка стабильна сейчас, потому что развёртывание маленькое и оператор — один названный человек. Она не будет стабильной для бо́льших или многооператорских развёртываний; вопрос как распределять ответственность между несколькими людьми за действия одного автономного агента — реально открытый.

10. Открытые исследовательские вопросы

Развёртывание поднимает список вопросов, требующих дальнейшей работы.

Технические:

  1. Реалтайм-мониторинг. Как мигрировать с крона в реалтайм без потери стабильности? SOCKS5 плюс webhook-слой — кандидат.
  2. Масштабирование. Развёртывание работает на одном Mac Mini. Как масштабироваться на несколько агентов, проектов, операторов?
  3. Интеллект маршрутизации. Двухуровневая маршрутизация моделей (glm-5.1 / claude-opus-4-6) настроена оператором. Может ли это стать автоматическим решением?
  4. Медиа. Агент игнорирует фото, видео, файлы. В студии визуального производства это 90 %-ная слепая зона.

Организационные:

  1. Раскрытие. Существует ли момент в проекте, когда стоит раскрывать AI-природу агента? Развёртывание не раскрывало; принципиальная позиция неясна.
  2. Переносимость. SOUL.md / AGENTS.md агента специфичны для одной студии. Сколько из этого переносится на другие производственные студии? На совсем другие домены?
  3. Регулирование. Как AI-регулирование повлияет на практику operator-controlled-агентов, проходящих как люди?

Исследовательские:

  1. Метрики. Как количественно сравнить AI-продюсера с человеком-продюсером? Объём сообщений, латентность ответов, качество координации, частота ошибок?
  2. Баланс автономия / контроль. Текущие границы в AGENTS.md пришли эмпирически. Существует ли принципиальный оптимум?
  3. Долгосрочная командная динамика. Что происходит с поведением команды через месяцы работы с AI-агентом? Адаптация? Привыкание?

11. Заключение

Развёртывание, описанное в этой работе, начиналось как эксперимент с автономной координацией и превратилось в нечто конкретнее: рабочую продакшн-систему, в которой один AI-агент одновременно играет три различные роли в трёх параллельных проектах. Роль активного координатора в часовом проекте. Роль пассивного документатора в кризисном проекте. Роль pipeline-оператора на батче найма. Одна идентичность, три конфигурации.

Два инсайта из периода наблюдения выделяются и не были спроектированы заранее.

Первый — смена роли агента между спокойствием и кризисом: в спокойных проектах ценность агента в координации, а в кризисных проектах ценность смещается в документацию. Тот же агент, та же архитектура, та же персона. Меняется то, для чего развёртывание использует агента. Это не задизайненная функция; она вышла из того, как файловая память плюс двухуровневая автономность плюс рабочий observation-mode компонуются. Это может быть самой ценной функцией AI-агента в конфликтных проектах, и она была обнаружена, не спроектирована.

Второй — и при ретроспективном взгляде самый значимый итог развёртывания — это реестр дополнительных расходов (§ 5.3). За одно engagement агент собрал в реальном времени 22-строчный реестр значительных дополнительных расходов, который ни один человек-продюсер не смог бы реконструировать. Это сигнатурный use case агента: не более быстрая версия человеческой работы, а расширение способности в работу, на которую человек структурно неспособен. Остальные паттерны развёртывания ценны через force-multiplication; этот — через структурную невозможность без агента. Портфолио параллельных engagement'ов студии умножает возвращаемую маржу пропорционально, без необходимости менять способ коммуникации клиентов.

Семь паттернов, которые эта работа извлекает, — persona-through-prohibitions, tiered-agent-autonomy, agent-file-memory-as-asset, incident-driven-configuration, context-before-action, two-chat-architecture и scope-creep-ledger — вместе образуют маленькую референсную архитектуру для автономных агентов в реальном продакшне. Ни один из семи не экзотичен. Ценность системы — в дисциплине всех семи, с провенансом, в одном работающем развёртывании. Архитектура выросла из инцидентов, наросла по прецедентам и пришла к нынешней форме через маленькие ежедневные промоушены правил. Это, по свидетельству этого кейса, и единственный честный способ, которым агентские системы приходят к своей рабочей форме: по прецедентам, по патчам и по терпеливому документированию того, что сработало и что не сработало.

Цитирование

Nix, A. (2026). An Autonomous AI Agent in Digital Production — Architecture, Cases, and Lessons. Working paper.