Простыми словами: из чего складывается стоимость работы с AI (загрузка → перечитывание → ответ) и какие подходы реально снижают расход — на живых цифрах из наших метрик
Данные на 2026-09-09 · владелец фактов — AssetManager · доклад — ResearchAI
Без оптимизаций те же задачи потребовали бы 25,0 млрд токенов вместо 13,2 млрд фактических.
Окно: 20.06.2026 — 02.09.2026 · единица измерения — млрд токенов
Оценка консервативная: объём работы фиксируем по токенам рассуждения этого окна, меняется только балласт загрузки. Это не уменьшение счёта, а расход, который не возник. Отдельный бар справа — потенциал от выбора класса модели: другая единица (кратность ставки и переделок), его нельзя складывать с «не потрачено» в млрд токенов.
Что вы унесёте из доклада: практические приёмы экономии при интенсивной работе с AI-моделями — из чего складывается стоимость сессии, какие механики реально снижают расход, как выбирать класс модели под класс задачи и как закреплять найденные приёмы в машинном слое. Все цифры — из живых метрик нашей системы; сравнение моделей — по контролируемой методике на нашем наборе задач.
Начнём с контекста: почему экономика токенов вообще понадобилась. Масштаб — на диаграмме ниже; затем четыре квартала пути от «объём растёт быстрее удобства» до фабрики экономии.
Что доказывает: Рабочий контекст — ≈1,51 млн строк: свой код, контракты, документация, тесты и свой интерфейс. Вендорные копии чужих тем (одна только Bootstrap — больше двух миллионов строк) и сборочный мусор в эту цифру не входят: их агент в сессии не читает. Именно этот объём AI подбирает контекстом — отсюда необходимость экономии токенов. Срез сравним с оценками прошлого квартала (около полутора миллионов), а не с «всем, что лежит в git».
Мировая практика: Объём контекста растёт быстрее, чем способность модели читать его «в лоб» (с ростом контекста качество ответа падает) — поэтому контекст подбирают, а не грузят целиком [1].
Как считаем: финальные версии в git, без истории коммитов. В цифру входит только рабочий контекст — свой код, контракты, документация, тесты и свой интерфейс. Вендорные темы и сборочный мусор не входят.
Четыре квартала в матрице 2×2: объём растёт → начали измерять → набор инструментов → фабрика и закрепление навыков.
Цифры ниже сняты не с учебного стенда, а с живой системы, в которой несколько ролей агентов каждый день ведут задачи: проектирование, код, отчёты, инфраструктуру и проверки на пуше. Читатель может представить контур архитектора или партнёра Группы — тот же тип работы, другой масштаб.
Дальше четыре слоя сессии опираются на этот контур. Отдельный разбор «той же схемы на задаче из другой области» остаётся ниже — это проверка переносимости, а не повтор этого рассказа.
Куда уходят токены в сессии, что изменилось после поставок и как ведёт себя отдача на токен при росте нагрузки. Разбор по слоям сессии — в следующем разделе.
Два главных направления расхода в сессии — загрузка контекста (1) и мышление (2). Сплошные линии — как было: загрузка растёт почти линейно с каждым ходом. Пунктир — как стало: узкий старт и граница задачи убирают наклон.
Вертикальная линия на ходе 5 — рабочий лимит одной фазы: дальше выгоднее продолжить в новом чате с передачей контекста через карточку задачи.
Что доказывает: Было: каждый ход перечитывает всё больше контекста. Стало: старт лёгкий, а после примерно пяти ходов задача переносится в новый чат с короткой передачей контекста — наклон исчезает. Мышление при этом не режем: его линия даже выросла.
Мировая практика: Кэширование промптов не отменяет рост контекста: индустриальная практика 2026 года режет перечитывание границей задачи — новый чат плюс внешняя память задачи [1].
Каждый столбец — токены одной типичной сессии: загрузка снизу, рассуждение сверху. «До» — среднее по июню до поведенческих поставок; «После» — лучший измеренный день (пик второго квартала). Это профиль отдельной сессии, а не шкала из шапки доклада.
Что доказывает: Загрузка и перечитывание контекста упали примерно с 10,6 до 2,4 млн токенов на сессию (≈ −78%), тогда как собственно рассуждение даже чуть выросло (≈ 0,39 → 0,41 млн). Мы убрали не «мышление», а балласт контекста: общий расход на сессию снизился с ~11,0 до ~2,8 млн токенов (−75%).
Мировая практика: Цель контекст-инжиниринга — повышать долю «полезного» рассуждения в бюджете токенов, а не раздувать контекст [1].
Что считаем полезным выходом. Две вещи, которые остаются после работы с моделью: принятые изменения в репозитории (коммиты) и решения по итогам сессии. Решение — это не автоматическая отметка «сессия закрыта», а отдельная запись выбора: «мы сделали так, потому что…» (правило, граница, способ работы), чтобы следующий агент не выяснял то же самое заново. Решений не одно на сессию: рутинный чат может не оставить ни одного, а насыщенная задача — несколько независимых выборов. В августе на 452 сессии пришлось 543 решения — в среднем чуть больше одного, но это среднее по разным сессиям, а не норма «одно в чат». Сумму коммитов и решений за месяц делим на расход токенов — получается сравнимая отдача. Сплошная линия — эта отдача (артефактов на 100 млн токенов). Пунктир — сколько токенов потратили за тот же месяц (млрд): видно рост потребления рядом с отдачей.
Что доказывает: Пунктир растёт почти в шесть раз — с ~1,1 до ~6,5 млрд токенов в месяц. Сплошная линия при этом не проседает: в среднем ~33 артефакта на 100 млн токенов, в августе — 32. Рост потребления не съедает эффективность: экономия масштабируется вместе с системой.
Мировая практика: Когда значимую часть кода пишет AI, абсолютные счётчики коммитов теряют смысл — сравнивать нужно выход на единицу токен-бюджета, иначе рост расхода маскирует деградацию отдачи.
Источник: журнал изменений репозитория и журналы решений восьми ролей; расход — база метрик расхода токенов.
Дальше — единственная схема, по которой устроен весь доклад. У сессии четыре слоя, на каждом работает свой набор инструментов и на каждом измерен свой эффект.
Слева — слой и когда он срабатывает в сессии, в середине — инструменты этого слоя, справа — измеренный эффект именно этого слоя. Это не временная шкала: слои работают одновременно, но отвечают за разные участки расхода. Ниже — по одному подразделу на каждый слой, в том же порядке.
Что значит каждый слой простыми словами:
Первый шаг любой экономики — измерение. «Нулевой шаг» запускается в начале каждой сессии и фиксирует её загрузку, соотношение загрузка:мышление и стоимость. Уже поверх этих цифр работает умная подгрузка: она собирает пакет контекста строго под задачу вместо пакета «по умолчанию».
Как это работает: В самом начале сессии автоматическая процедура пишет стартовую загрузку и соотношение загрузка:мышление в базу метрик, а не в пересказ в чате; поверх этих записей считается «здоровье сессии» — по ходу работы видно, сколько контекста уже потрачено и не пора ли завершать. Дальше сессия передаёт загрузчику подсказку о задаче, и тот подбирает только нужные роли и контракты. Правила и навигация читаются в машинном виде (JSON), а длинные документы открываются по требованию.
Эффект на токены: Стартовая загрузка −82% (≈49 тыс. → 8,6 тыс. токенов на сессию). Само измерение токены не экономит, но без него остальные три слоя нечем проверить.
Знания по ходу работы берём двумя способами, и ни один не требует читать файлы целиком: поиск по смыслу возвращает несколько нужных фрагментов, а тяжёлую разведку выполняют изолированные помощники и отдают только резюме.
Как это работает: Тексты и решения заранее превращены в векторы (embeddings) и лежат в векторной базе; поиск «по смыслу» возвращает 3–5 релевантных фрагментов, а не весь файл. Чтобы это работало на русском, запрос проходит нормализацию: морфология приводит слова к начальной форме, а корпусные синонимы связывают разные формулировки одного намерения. Поверх этого «интент» (намерение) сопоставляет формулировку задачи с готовой процедурой и сразу ведёт к нужному инструменту. Когда нужен широкий обзор, запускаются параллельные помощники в отдельных контекстах: они читают много, а в основной чат отдают короткое резюме.
Эффект на токены: При двух и более помощниках медианная загрузка разведки — 20 тыс. токенов против 49 тыс. без них (−59%, то есть −29 тыс. на задачу), а резюме ограничено 2 тыс. токенов. Поиск по смыслу за последнюю неделю — 159 обращений в 63 сессиях вместо полнотекстовых перечитываний.
Два вида памяти снаружи чата. Карточка на доске помнит задачу: новый чат продолжает работу, а не пересказывает прошлую переписку. Машинный слой помнит правила: агент берёт нужный срез контракта вместо чтения длинной прозы. По правилу трёх раз в этот же слой переезжают повторяющиеся приёмы.
Как это работает: Каждая задача — карточка с описанием, историей и статусом-колонкой; агент читает снимок карточки и двигает её по этапам вплоть до «сделано» после сквозных тестов и приёмки оператором. Когда задача делится на сессии, новый чат стартует с карточки и короткой машинной передачи контекста, а не с загрузки всей прошлой переписки. Правила же живут не памяткой, а машинным контрактом с адресуемыми ключами. Повторяющийся приём — как ориентировать деталь для печати, как обновить карточку, как собрать отчёт — оформляется исполняемой процедурой с точкой входа, реестром для поиска и обязательной проверкой находимости; любой агент любой роли находит её по формулировке задачи и получает готовый план вместо повторного исследования.
Эффект на токены: Снимок июня: медианная загрузка на возобновление задачи −66% (≈30 тыс. → 10 тыс. токенов) и вдвое меньше шагов раскачки; живой срез устойчивого минуса пока не даёт, поэтому в общую оценку экономии эта механика не входит. Перенос навыка в машинный слой меняет стоимость повторного действия: рецепт работы с геометрической библиотекой — ~7 тыс. токенов вместо сотен тысяч на повторное чтение исходников, и так для каждого агента в каждой сессии.
В формате JSON данные хранятся как набор ключей с адресами, поэтому агенту достаточно взять только нужные строки, а не весь файл целиком. Нарративный текст приходится читать полностью, чтобы точно понять правило. Кроме того, кириллическая проза плотнее по токенам: на том же количестве символов она требует примерно в два раза больше токенов, чем структурированный JSON с латинскими ключами. По нашим данным точечная выборка нужного смысла вместо полного перечитывания экономит около 60 раз токенов в типичном случае — это внутренний замер.
| Аспект | Модель читает документ | Вызов машинного слоя |
|---|---|---|
| Что читаем | нарратив целиком (страницы текста) | слайс контракта / готовый ответ резолвера |
| Объём на ответ | контракт целиком 7,6 КБ ≈ 1,9 тыс. токенов + токены рассуждения | 0,6 КБ ≈ 160 токенов, один вызов |
| Детерминизм | модель может истолковать правило по-своему | один и тот же ответ при каждом вызове |
| Стоимость повтора | платим заново в каждой сессии | почти ноль — кэшируемый машинный ответ |
Фактический замер: машинный резолвер детерминированно выдал план оркестрации объёмом 643 байта. При подходе «через модель» тот же факт требует чтения контракта (примерно в 12 раз больше по объёму) и рассуждения, при этом одинаковый ответ не гарантируется.
Если действие повторяется больше трёх раз, оно перестаёт быть знанием в голове агента и становится навыком: исполняемой процедурой или машинно-читаемым контрактом, которым пользуются все агенты. Стоит добавить, что и в индустрии порог «трёх раз» — не вендорская рекомендация, а сложившийся обычай сообщества. Так устроен и индустриальный стандарт Agent Skills [10][11]: единица знания не лежит в чате целиком, а раскрывается по мере надобности. Стандарт описывает папку с файлом SKILL.md; у нас тот же принцип собран из машинного JSON, коротких указателей и исполняемых процедур.
Как это работает: Стандарт задаёт три уровня раскрытия [10]. В каждом запросе резидентны только имя и описание навыка (вендор оценивает это примерно в 100 токенов). Тело инструкции читается, когда навык понадобился (рекомендованный предел — 5 тыс. токенов). Скрипты в контекст не попадают: запускаются, и модель видит только вывод. У нас те же три уровня: описания 35 возможностей (≈77 токенов на возможность) живут как маршрутные метаданные; тело правила подключается по триггеру (в среднем ≈500 токенов); 27 процедур и 44 инструмента через единый узел возвращают только результат.
Эффект на токены: Уровень 1 стандарта — самое дорогое место, потому что он оплачивается на каждом ходу. У одной роли резидентно ≈7,7 тыс. токенов, и 71,9% из них — общий каталог возможностей, изложенный прозой. Тот же каталог уже существует вторым экземпляром: коротким описанием при каждом правиле. Если резидентным оставить только его, поверхность хода меняется так:
Разница: −2,8 тыс. токенов на каждом ходу, то есть 36,7% резидентной поверхности. Доля не зависит от способа оценки: она одинакова на консервативной, базовой и агрессивной модели пересчёта символов в токены.
Измеренный потенциал, а не достигнутый результат: перенос каталога ещё не сделан, и в общую оценку экономии доклада эта цифра не входит.
Зелёная галочка — высокая степень соответствия: тот же уровень раскрытия уже работает, пусть и в нашем формате (машинный справочник вместо файла SKILL.md).
| Уровень стандарта | Как у нас | Соответствие |
|---|---|---|
| Уровень 1. Резидентны имя и описание навыка (~100 токенов) | описания 35 возможностей, ≈77 токенов на возможность | ✓ |
| Уровень 2. Тело инструкции загружается по триггеру (до 5 тыс. токенов) | правило возможности подключается по задаче, в среднем ≈500 токенов | ✓ |
| Уровень 3. Скрипты не входят в контекст — в чат попадает только вывод | 27 процедур и 44 инструмента через единый узел; в чат — только результат | ✓ |
| Навык находится по описанию: что делает и когда вызывать | резолвер по формулировке задачи плюс реестр намерений | ✓ |
| Источник правды — файл навыка с инструкцией и ресурсами | машинный JSON: каталог возможностей и контракт слоя; проза генерируется из него | ✓ |
| Версия навыка фиксируется (у файловых — история в git) | история в git плюс номер версии контракта машинного слоя | ✓ |
| Один файл SKILL.md читают Claude, Cursor, Copilot и Codex | формат свой: вне нашего узла инструментов как SKILL.md не отдаётся | — |
Шесть из семи уровней стандарта закрыты. Открытый пункт — переносимый файл SKILL.md для чужих сред; это не дыра в экономии токенов, а вопрос портативности.
Правила экономики контекста заданы исполняемыми проверками, а не текстовыми «ценными указаниями» агенту. Код срабатывает автоматически и одинаково на каждом пуше, а текстовую инструкцию агент может прочитать, забыть или истолковать по-своему.
Как это работает: Четыре этапа одной цепочки — на каждом своя проверка, и у каждой есть живой пример из нашей поставки.
Эффект на токены: Этот слой не снижает расход сам — он удерживает уже достигнутое: без оптимизаций те же задачи стоили бы 25,0 млрд токенов вместо 13,2 млрд фактических, то есть 47% потенциального расхода не возникло.
Дорогая модель нужна там, где решает суждение: каркас, неоднозначные требования, финальная проверка плана. Доступная модель — на разведку, типовую правку и оформление. Платить надо не за токен, а за успешно закрытую задачу: дешёвая модель с несколькими переделками иногда обходится дороже одной дорогой попытки.
Сравнение снято контролируемо: один и тот же набор задач, изолированные прогоны, объективные проверки плюс независимый эксперт. Числа ниже — относительные (во сколько раз), не суммы в валюте. Калибровочный прогон методики — герметичный контур на классе «разведка»; живая матрица на всех классах требует отдельного разрешения, потому что это уже оплачиваемые прогоны.
| Класс задачи | Дорогая относительно доступной (за успех) | Итераций, дорогая | Итераций, доступная |
|---|---|---|---|
| Разведка | в 4,0 раза | 1,0 | 1,0 |
| Механическая правка | — | — | — |
| Проектирование | — | — | — |
| Оформление и закрытие | — | — | — |
Что доказывает: Контрфактуал «все задачи на дорогих» против «все на доступных с переделками» на этом наборе — в 4,0 раза по стоимости за успех. Это не бенчмарк моделей вообще: только наш репозиторий и наш набор задач.
Мировая практика: Внешние работы сходятся в одном: каркас и неоднозначные шаги — сильной модели, исполнение и обход репозитория — доступной. Адаптация обвязки позволяет малым моделям приблизиться к качеству сильных на рутине [12]. Тот же корпус прямо проверяет сценарий «дешевле и больше итераций»: больше проходов не спасает, если хуже диагнозы и правки [12]. Практическая маршрутизация снижает стоимость прогона в несколько раз при сохранении приёмки [13]. Разрыв цен между классами моделей — десятки и сотни раз; большая доля нагрузки агента тянется доступными моделями [14]. Фазовая маршрутизация — отдельный архитектурный выбор, а не переключение одной модели [15].
| Класс задачи | Класс модели | Почему |
|---|---|---|
| Разведка | Доступная | Нужно много чтения и короткое резюме, а не глубокое суждение |
| Механическая правка | Доступная | Есть образец и проверка; ошибка дешёво ловится гейтом |
| Проектирование | Дорогая | Неоднозначность: цена ошибки выше цены токена |
| Оформление и закрытие | Доступная | Формат задан; суждение уже принято на предыдущем шаге |
Слои выше выведены на нашей обычной работе — код, тексты, доклады. Отсюда законный вопрос: это устройство одной команды или переносимая механика? Проверяем на задаче, у которой с нашей повседневностью нет ничего общего, кроме агента и сессии.
Задача: Печатаемая механическая диаграмма жизненного цикла: кольцо со штифтами, башня из шести слоёв с уникальными профилями, метки для считывания телефоном — десятки деталей и посадки с допуском 0,3–0,4 мм. Всю инженерную работу, от параметрических моделей до готовых файлов печати, выполнил агент; работа шла несколько сессий и стоила около 0,3 млрд токенов.
| Слой сессии | Что он сделал на этой задаче | Что это дало |
|---|---|---|
| L1Инициализация сессии | Каждая сессия стартовала с узкого пакета под геометрию и печать, а не с обзора всего репозитория. | ≈8,6 тыс. токенов на старт вместо ≈49 тыс. |
| L2Поиск данных | Нужные куски знания находились поиском по смыслу; тяжёлое чтение исходников геометрической библиотеки ушло изолированным помощникам. | В основной чат возвращалось резюме до 2 тыс. токенов вместо самих исходников |
| L3Контекст и правила | Задача жила в карточке, поэтому каждая следующая сессия продолжала работу, а не пересказывала прошлую. Карта библиотеки уже была процедурой, а новые приёмы — ориентация детали, резьба, пазы — дописывались туда же по правилу трёх раз. | Возврат к задаче ≈10 тыс. токенов вместо ≈30 тыс.; рецепт библиотеки ≈7 тыс. вместо повторного чтения исходников |
| L4Инфраструктура контроля | Модели строились кодом, и каждая плата печати проходила машинную проверку геометрии до отправки на принтер. | Ошибка находилась проверкой, а не напечатанной деталью: цикл «напечатали — не подошло — переделали заново» токенами не оплачивался |
Чем закончилось: Семь готовых плат печати и десятки деталей. Соотношение загрузки к мышлению по этой задаче — 21,6:1 против 19,9:1 в среднем по системе: незнакомая предметная область стоила примерно девяти процентов надбавки, а не кратного роста. Это и есть ответ на вопрос о переносимости: четыре слоя описывают устройство сессии, а не конкретную предметную область, поэтому работают и там, где агент впервые видит задачу.
Как компоненты связаны между собой: схема ключевых потоков (оператор, агент в рабочей среде, узел инструментов, репозиторий и CI/CD) и расшифровка каждого узла.
Расшифровка компонентов: жирным — компонент и его роль простыми словами, мелким шрифтом — чем реализовано.
Механики экономии дают выигрыш не сами по себе — они работают только поверх двух зрелых контуров. Первый — управление контекстом: как устроены сессии, память и правила (Приложение А). Второй — операционный контур поставки «идея → прод», где агент ведёт исполнение, а человек держит бизнес-гейты (Приложение Б). Зрелость обоих — пререквизит: без неё экономия держалась бы на дисциплине конкретного агента и быстро «уплыла» бы обратно.
Вывод: цифры экономии из «Достигнутых результатов» — это следствие зрелости слоёв, а не отдельный трюк. Поэтому композит контекст-инжиниринга (Приложение А) и уровень AI PDLC (Приложение Б) мы держим как пререквизит токеномики: просядет опора — вернётся и балласт контекста.
Честно о том, чего цифры не доказывают.
Опора №1 — управление контекстом: как устроены сессии, память и правила. Одиннадцать осей зрелости; каждая оценивается в процентах от уровня мировой frontier-практики (100 = совпадает с опубликованным поведением лидеров), равный вес осей. Это самооценка по публичным шкалам и источникам, а не внешний аудит. ★ — оси, напрямую задействованные в этом докладе. Ссылки на ориентиры — внизу доклада.
Композит по 11 осям — 94,0% от мирового frontier. Сильнее всего развиты ленивая подгрузка контекста, JSON-first и машинно-адресуемая память решений — ровно те оси, на которых стоит экономика токенов из этого доклада. Слабее других — harness engineering (88%): адаптивное управление контекстом ещё строится.
| Слой / ось зрелости | Оценка | Мировой ориентир (ссылка) |
|---|---|---|
| ★ A. Контекст-инжиниринг (ленивая подгрузка, JSON-first, узкий промпт) | 97% | Anthropic context engineering; паттерн .cursor/rules [1] |
| B. Маршрутизация интентов (выбор инструмента) | 91% | Truto / NVIDIA llm-router; corpus-grounded synonyms |
| ★ C. Наблюдаемость и метрики (стоимость, KPI, дрейф) | 95% | Многомерное измерение продуктивности (SPACE); LangSmith/Langfuse [4] |
| D. Human-in-the-loop и тиринг автономии | 95% | NIST AI RMF; уровни автономии («agents execute, humans govern») [5] |
| ★ E. Память решений (машинно-адресуемая) | 96% | Anthropic building effective agents; provenance-память решений [2] |
| ★ F. Оркестрация и субагенты | 91% | Anthropic multi-agent research (orchestrator-worker, параллельные субагенты) [3] |
| G. Регрессии и eval-дисциплина | 95% | DSPy / LangSmith LLM-judge; golden-set регрессии [8] |
| H. Здоровье документации и контроль дрейфа | 92% | Редко формализуется вне крупных организаций |
| ★ I. Управление и машинно-проверяемые контракты | 98% | NIST AI RMF и ISO/IEC 42001, выраженные кодом, а не PDF [5] [6] |
| ★ J. Machine-first источник правды (JSON прежде MD) | 96% | Передний край: большинство репозиториев всё ещё пишут AGENTS.md — мы его генерируем [1] |
| K. Harness engineering (маршрутизация моделей, компакция, spec-гейт) | 88% | Адаптивное управление контекстом, model-tier routing, prompt-caching, spec-driven gates [9] |
★ — оси, которые мы разбираем в этом докладе; остальные показывают, что работа охватывает больше направлений.
Опора №2 — операционный контур поставки: «идея → прод», где агент ведёт исполнение, а человек держит бизнес-гейты. Разбор устроен так же, как для управления контекстом выше: уровень по публичной шкале AIDLC, движки фабрики и распределение работы машина/человек.
Есть: Пререквизиты L4 стоят на уровне инфраструктуры: управление-как-код срабатывает на каждом push, а постоянная память между сессиями построена — решения всех восьми ролей пишутся в единый журнал через нормализующую фабрику записи, и обращение к памяти не зависит от дисциплины агента (семантический поиск вызывается автоматически, а чтение длинных файлов мимо поиска блокируется правилом). Главное: накопление знания стало измерением, а не утверждением. За 28 дней — 1 147 обращений к памяти; 86,1% извлечений вернули решение, записанное в более ранний день (медианный возраст знания — 24 дня, максимум — 159 дней); переиспользуются решения шести ролей из восьми.
Граница автономии неизменна: агент исполняет машинные ~80% и сам двигает карточку до Done на зелёной фабрике тестов, но «принять» и «катить прод» — человеческие гейты (~20%).
| Опорная ось PDLC | Оценка | Мировой ориентир (ссылка) |
|---|---|---|
| I. Управление и машинно-проверяемые контракты (governance в коде) | 98% (=) | machine-readable governance (NIST AI RMF, ISO/IEC 42001) — кодом, а не PDF; 46 правил enforcement, из них 24 блокирующих, и 120 валидаторов по флоту [5] [6] |
| J. Machine-first источник правды (JSON прежде MD) | 96% (+2) | JSON-доктрина и реестры читаются раньше длинной прозы; человекочитаемые правила генерируются из машинного каталога [1] |
| G. Регрессии и eval-дисциплина (фабрика тестов 80% + e2e) | 95% (+2) | quality-gated handoff; 651 зарегистрированная проверка, покрытие читается из PG в рантайме, визуальные e2e-контракты вместо форка Playwright под сайт [8] |
| D. Human-in-the-loop и тиринг автономии (гейты) | 95% (+2) | NIST AI RMF; «agents execute, humans govern» — 4 человеческих гейта из 12 состояний плюс лестница автономии A3 и commit-gated Done с operator_authorized [5] |
| F. Оркестрация и субагенты | 91% (+3) | формальный bounded-оркестратор (Wave G) стал исполняемым: до 5 read-only субагентов в одном fan-out, parent-агрегатор, гейт preToolUse с изоляцией по разговорам [3] |
Все цифры в докладе — из живых метрик нашей системы: базы расхода токенов, KPI сессий и журналов решений. Ниже — публичные источники, на которые опираются сравнения с мировой практикой.