19 мая 2026 г.9 мин. чтенияЧитать на английском

Реестр дополнительных расходов — как AI-агент возвращает деньги, которых не видит человек-продюсер

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

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

Механизм маленький, но дисциплинированный. Производственный процесс студии разбит на именованные стадии утверждения (Input Files → Modeling → Texturing → Variations → Positioning → Camera → Lighting → Rendering). У каждой стадии — опубликованный прайс: базовая цена, цена за вариацию, цена за переделку после утверждения. Каждое входящее сообщение от клиента классифицируется агентом: это фидбек на неудовлетворённую спецификацию (бесплатно) или новое требование после утверждения (тарифицируется)? Если тарифицируется, агент пишет строку в реестре: модель, затронутая стадия, цена по таблице и предложение контекста с указанием породившего сообщения. Реестр копится непрерывно. К моменту выставления счёта это CSV — а не реконструкция.

Почему утечка структурна, а не от лени

Стандартное объяснение невозвращённого размыва скоупа — ошибка продюсера: продюсер не настоял, не отследил, не выставил. Реальная причина — структурная. Продюсер на живом проекте сталкивается с четырьмя ограничениями, которые никакая дисциплина не преодолевает:

Когнитивный объём. Живой проект 3D-рендеринга часов проходит 3000+ сообщений в двух чатах за четыре недели. Прочитать каждое сообщение и спросить это расширение скоупа? для каждого — самостоятельная full-time-работа.
Непоследовательные критерии. Один и тот же тип изменения — «поправить цвет ремня» — регистрируется как in-scope утром и как out-of-scope в полночь, в зависимости от энергии, температуры отношений и параллельной загрузки.
Давление отношений. Продюсер, который хочет держать клиента в тёплом контакте, спишет мелкие добавления и будет push-back-ить только на крупных. Десятки мелких позиций складываются в значительную потерю маржи, отданной даром, потому что каждая по отдельности казалась слишком мелкой, чтобы биться.
Невозможность обратного восстановления. Через три недели реконструкция полного списка расширений скоупа из истории чата — задача того же масштаба, что и сам проект. Цена восстановления превышает возвращаемую выручку.

Ничего из этого не чинится «постараться лучше». Ограничения реальные. Утечка происходит независимо от компетентности продюсера; она происходит потому что продюсер компетентен достаточно, чтобы понять, что биться за каждую мелкую переделку нанесёт engagement бо́льший ущерб, чем абсорбировать. Утечка — не провал дисциплины, это рациональное поведение человека на полной загрузке. У агента есть то, чего у продюсера нет: свободная ёмкость.

Пайплайн стадий-утверждений как разделитель

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

Input Files — старт проекта после брифинга и ревью вводных.
Modeling — создание 3D-модели, утверждается по OBJ/скриншотам.
Texturing — UV-маппинг и текстуры, утверждается до продолжения.
Variations — варианты ремней/циферблатов после утверждения текстур.
Positioning — позиционирование модели и ригов.
Camera — утверждение камер.
Lighting — свет на утверждённой модели и камерах.
Rendering — финальный GPU-рендеринг после утверждения света.

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

Это предложение — весь интеллектуальный контент реестра. Оно не требует искусственного интеллекта; оно требует последовательного применения, в чём искусственный интеллект и силён. Работа агента на каждом входящем сообщении — задать три вопроса: какая модель, какая стадия, по какую сторону разделителя? Когда ответ «тарифицируется», lookup в прайсе даёт стоимость, и в реестре появляется новая строка.

Проработанный фрагмент реестра

Двадцать две строки получились за одно четырёхнедельное engagement. Три из них иллюстрируют категории:

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

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

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

Полный реестр за engagement содержал:

| Модель | Строк | Доля от общего | |---|---|---| | Модель A | 11 | ~31% | | Модель B | 3 | ~12% | | Модель C | 3 | ~6% | | Модель D | 3 | ~45% | | Сессии рендер-фермы | 1 | ~6% | | Всего | 22 | 100% |

Модель D — каскадный кейс. Три строки, почти половина общей выручки. Это тот уровень детализации, который человеческая память продюсера через три недели надёжно не воспроизведёт.

Что агент делает, чего не может продюсер

Пять способностей всплывают как несущие в этой работе:

Равномерное внимание на объёме. Каждое сообщение получает одинаковую классификацию. Сообщение в 23:47 разбирается так же, как сообщение в 10:00. 3000+ сообщений engagement'а получают 3000+ классификаций.
Идентичные критерии во времени. Правило разделения применяется к сообщению 1 так же, как к сообщению 3000. Нет утренне-вечернего дрейфа, усталости, смягчения от отношений. Та же мелкая переделка биллится в первую неделю и в четвёртую с одинаковой логикой.
Предзагруженный контекст. Агент помнит, какие файлы были исходными вводными, какие стадии утверждены, в каких сообщениях содержалось утверждение. Кросс-референсинг, который человеку пришлось бы добывать прокручиванием, для агента — просто чтение памяти.
Логирование в реальном времени. Строка реестра пишется в момент расширения скоупа, не реконструируется при выставлении счёта. Контекст свежий, сообщение идентифицируемо, расход естественно категоризирован до того, как его размоют последующие события.
Аудируемость. Каждая строка реестра несёт предложение контекста с указанием породившего сообщения. Если возникает спор о счёте, строка верифицируема по чату — продюсер не аргументирует памятью, а указывает на зафиксированное доказательство.

От реактивного к проактивному биллингу

Стандартная биллинг-модель в продакшн-студиях реактивна: команда делает работу, потом при выставлении счёта пытается восстановить, что было скоупом, а что размывом. Реконструкция неполная (работа теряется), неверифицируема (нет контекста для якоря) и медленная (дни прокрутки чата). Реактивная модель — это то, что производит структурную утечку маржи.

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

Есть вторичный эффект на поведение клиента, который наблюдала студия: когда расширения скоупа отслеживаются прозрачно и поднимаются до начала работ, клиент становится более dеlibеrate в формулировке требований. «А ещё можно поменять…» становится предложением с видимым ценником. Цель реестра не в том, чтобы наказывать, — а в том, чтобы делать стоимость добавлений читаемой в момент их появления. Какие-то добавления всё равно стоит делать; клиент платит, студия получает маржу, обе стороны знают, что куплено. Система снижает конфликт, а не порождает его.

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

В более широком развёртывании OpenClaw, описанном в openclaw-autonomous-agent-paper, агент делает много — координирует, мониторит, составляет черновики, эскалирует, документирует. Большинство этого лучше человека по объёму или непрерывности, но эквивалентно человеку по типу. Квалифицированный продюсер с бесконечным временем мог бы в принципе делать то же.

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

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

Как развернуть паттерн

Паттерн переносится на любую продакшн-работу, где:

Производственный процесс разложим на стадии-утверждения (modeling → texturing → rendering; концептинг → ключевой арт → финал; outlining → drafting → polishing; и т.д.).
У каждой стадии есть опубликованный прайс, включая стоимость переделки после утверждения.
Клиентский фидбек идёт через чат-канал, который агент может читать.
Есть чёткое правило разграничения между in-spec-исправлениями и новыми требованиями.

Без этих четырёх частей у реестра нет якоря; он будет генерировать шум, а не billable-документ. С ними конструкция механическая:

Прайс-таблица. Документ, который агент читает при старте: базовые цены, цены за вариации, цены за переделку после утверждения по стадиям, инфраструктурные надбавки. Живое обновление по ходу проекта.
Правило разграничения. Одно предложение, применяемое агентом к каждой классификации. Конкретное правило может варьироваться по студии; форма — X бесплатно, Y тарифицируется.
Схема реестра. Пять колонок: модель / стадия / описание / сумма / контекст. Колонка контекста — то, что делает строку защитимой.
Логирование в реальном времени. Агент пишет строку, когда видит сообщение о расширении скоупа, а не в конце проекта.
Ревью оператора. Строки всплывают оператору в очередь по мере появления, чтобы оператор мог одобрить, переписать или эскалировать до того, как строка войдёт в инвойс-регистр.

Два режима отказа

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

См. также

openclaw-autonomous-agent-paper — полный кейс; этот концепт вытаскивает sub-результат § 5 в отдельный документ
tiered-agent-autonomy — реестр сидит в автономном уровне (логирование без одобрения оператора); поднятие на биллинг — в согласуемом (каждая строка ревьюится до инвойса)
agent-file-memory-as-asset — реестр — канонический пример паттерна «память как организационный актив»; та же память, что поддерживает day-to-day, производит документ для счёта
context-before-action — классификатор читает контекст чата до классификации, не только входящее сообщение