Глава 10. Синтез: движок управления компанией — Движки миров и экономических симуляций

10.1. Что мы строим: определение через отличия

Движок управления компанией — это генеративная модель компании: симуляция, которая выращивает макропоказатели (выручку, маржу, загрузку, отток, настроение) из микроповедения агентов и механики процессов, а не отображает их из базы данных. Это критерий Эпштейна из главы 6, применённый как критерий продукта: если система не может вырастить P&L из поведения — это дашборд, сколь угодно красивый. Дашборд отвечает на вопрос «что происходит?», движок — на вопросы «что будет, если?», «почему получилось именно так?» и «где сломается?».

архитектурных решений — один взаимно обусловленный инвариант, а не меню

ступеней конвейера валидации: от ODD-спецификации до распределений по N прогонам

режима эксплуатации одного движка: зеркало, тренажёр, wargame, прескриптивный контур

этапов дорожной карты (0–4) — каждый производит самостоятельную ценность

традиций-доноров: игры, MMO, академия, бизнес-симуляции, двойники, LLM

тик — дискретный детерминированный шаг модельного времени команда — управленческое решение с меткой времени, журналируемое как событие mean-field — агрегаты SD как предел агентного слоя стилизованные факты — устойчивые паттерны компании, которые модель обязана воспроизводить эквифинальность — одну и ту же историю могут вырастить разные механизмы conformance checking — строгая сверка реального и синтетического логов гейм-мастер — арбитр, переводящий намерения LLM-агентов в события мира BOGSAT — «bunch of guys sitting around a table»: совещание, притворяющееся игрой

«Если система не может вырастить P&L из поведения — это дашборд, сколь угодно красивый».

Критерий Эпштейна (глава 6), применённый как критерий продукта

От бизнес-симулятора (глава 7) движок отличается тем, что модель не заморожена и не вымышлена: онтология мира редактируется, параметры калибруются на данных конкретной компании, время непрерывно, а не «год за ход». От цифрового двойника в узком смысле (глава 8) — тем, что он не только зеркалит и прогнозирует, но и служит песочницей: тренажёром для управленцев, полигоном wargame-сессий, средой верификации действий AI-агентов. От игры (главы 3, 5) — тем, что у него есть обязательство правды: калибровка и валидация — не опция, а часть контура. При этом именно игры дают ему то, чего нет ни у BI, ни у академических моделей: архитектуру живого мира и опыт удержания внимания человека.

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

10.2. Семь архитектурных решений

Из сорока с лишним инсайтов глав 2–9 складываются семь решений, которые определяют архитектуру. Они взаимно обусловлены — это один инвариант, а не меню.

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

Решение 1. Детерминированное headless-ядро с фиксированным тиком, командами и снапшотами (глава 2). Симуляция полностью отделена от представления и работает без интерфейса; время дискретно и детерминировано; вся случайность — от управляемых seed; все воздействия на мир — команды с меткой модельного времени, журналируемые в духе event sourcing. Из этого бесплатно следуют: реплей любого прогона, аудит («какие решения привели сюда»), сценарные ветки (снапшот + доигрыш с другой командой), сверка версий модели по контрольным суммам и «машина времени» для дебрифинга.

💡 Ключевой тезис

Управленческие решения = команды — главный перенос из lockstep-RTS: аудит и ветвление истории не надстраиваются потом, а следуют из архитектуры.

Решение 2. Слоистая парадигма: SD — стратегия, DES — операции, ABM — рынок и люди, LLM — персоны (главы 6, 9). Не выбирать школу моделирования, а назначать послойно: медленные агрегатные контуры (деньги, бренд, компетенции, техдолг) — резервуарами и потоками системной динамики; операционный слой (проекты, заявки, очереди, SLA) — дискретно-событийной механикой; рыночно-человеческий слой (клиенты, сотрудники, конкуренты) — агентами; ключевые фигуры — LLM-персонами. Слои связаны: агрегаты SD — это mean-field предел агентного слоя, что даёт естественный механизм масштабирования и проверки согласованности.

Решение 3. Агрегация по умолчанию, агентность точечно, LOD как модель внимания (главы 2, 3, 5). Тест GlassBox: агентная симуляция окупается только там, где агенту нужна персистентная идентичность — память, привязки, история. Анонимные сущности честнее моделировать когортами и потоками. Симуляционный LOD переносится на компанию буквально: то, на что сейчас смотрит руководитель и по чему принимаются решения, симулируется детально; остальное — агрегатами на редких тиках (шаблон RimWorld 1/250/2000). Обязательное условие из X4: уровни детальности должны давать статистически совпадающие исходы — иначе движок «врёт» на границе фокуса.

Решение 4. Экономика потоков: краны, стоки, формульные цены, честное устаревание (главы 4, 5). Внутренняя экономика компании — деньги, люди, знания, клиенты, а также KPI, бюджеты и грейды — проектируется по правилам виртуальных экономик: каждый кран (найм, продажи, обучение) имеет парный сток (отток, списание, устаревание), иначе ресурс инфлирует. Ценообразование — формульное, от дисбаланса спроса и предложения с демпферами и потолками (консенсус Victoria 3 и Offworld: ~80% выразительности рынка при линейной сложности и без катастрофических режимов). Разрушение — двигатель спроса: без честного закрытия проектов, амортизации активов и устаревания компетенций модель мадфлирует так же, как MMO без стоков. И урок «эры дефицита» EVE: цель движка — раннее обнаружение дисбалансов и безопасный полигон интервенций, а не автопилот.

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

Решение 5. Событийный лог — интерфейс между реальностью и движком; модель выращивается, а не пишется (глава 8). Универсальная стыковка с компанией — событийный лог (case, activity, timestamp) из ERP/CRM/трекеров. Конвейер SIMOD/AgentSimulator — образец: discovery структуры из лога → выучивание параметров → калибровка минимизацией расстояния между реальным и синтетическим логом. Если симуляция пишет свои прогоны в том же формате лога, валидация сводится к conformance checking — готовой строгой технике. Онтология компании (граф знаний: агенты × роли × знания × задачи × ресурсы — мета-матрица Карли) — схема данных этого слоя; данные первичны, код вторичен (урок data-oriented design из главы 2).

Решение 6. LLM-слой: каскад точности, персоны из первичных данных, SOP-дисциплина, гейм-мастер (глава 9). Поведение людей генерируется LLM-агентами с архитектурой памяти Generative Agents (memory stream / reflection / planning), но по каскаду стоимости: полные агенты — для ключевых фигур, дистиллированные модели и правила — для массовки. Персоны строятся из первичных данных компании (интервью, переписка, CRM), а не из демографии — иначе симулируется стереотип. Взаимодействие агентов дисциплинируется как в MetaGPT: артефакты и процедуры вместо свободного чата — «физика» организационного слоя. Свободные намерения агентов переводит в события мира арбитр-«гейм-мастер» (паттерн Concordia). И трезвость TheAgentCompany: LLM-агенты выполняют меньше трети реальных офисных задач — закладывать их некомпетентность в модель, а не предполагать сверхлюдей.

Рис. 10.3. LLM-слой движка: персоны выращиваются из первичных данных компании и разложены по каскаду стоимости; свободу агентов дисциплинируют SOP-артефакты, а намерения переводит в события мира гейм-мастер.

Решение 7. Драматургический контур и встроенный дебрифинг (главы 3, 7). Отдельный от честной симуляции модуль: генератор стресс-сценариев с настраиваемыми политиками (Cassandra/Phoebe/Randy из RimWorld — готовая типология режимов стресс-тестирования) и запросный слой, превращающий лог симуляции в причинную историю — «Legends mode» компании. Обучение и ценность возникают в дебрифинге (Крукалл, глава 7): автогенерация разбора — каузальная трассировка исхода до петель, задержек и конкретных решений — обязательная подсистема, и LLM впервые делают её дешёвой. Сюда же — жанр «MER компании» из главы 4: регулярный открытый отчёт о балансе кранов/стоков, скорости обращения ресурсов и внутренних индексах цен; аномалии потоков — первый детектор и злоупотреблений (закон Гудхарта), и сломанных процессов.

Рис. 10.4. Полная архитектура движка: детерминированное ядро несёт четыре модельных слоя (SD-стратегия связана с ABM как mean-field предел); реальность стыкуется через событийный лог снизу, четыре взаимозаменяемых клиента подают команды сверху, а сбоку — отделённые от честной модели драматургический контур и дебрифинг.

10.3. Конвейер валидации

Валидация — конвейер, работающий постоянно, а не приёмочный акт (глава 6). Последовательность переносится целиком: (1) спецификация модели по протоколу ODD — модель описана так, что её можно реплицировать и аудировать; (2) верификация инвариантов — балансы сходятся, деньги/люди не возникают из ниоткуда (двойная запись как встроенный тест — урок и Victoria 3, и бухгалтерии); (3) приёмка по стилизованным фактам (pattern-oriented modeling): движок обязан воспроизводить 5–10 устойчивых паттернов конкретной компании — сезонность, распределение длительностей проектов, воронку, кривую оттока; (4) калибровка на исторических данных, включая суррогатную ML-калибровку; (5) анализ чувствительности (Соболь/Моррис) — он же продукт: «карта рычагов» для CEO, показывающая, какие параметры реально двигают исходы; (6) бэктест ретро-прогонами реальных эпизодов истории компании (паттерн People Express); (7) для LLM-слоя — двойная валидация: believability-панель на уровне поведения отдельных персон плюс бэктест агрегатов; выводы всегда как распределения по N прогонам, никогда — по одному.

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

💡 Главный режим отказа жанра

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

10.4. Режимы эксплуатации

Один движок — четыре режима. Зеркало: непрерывная синхронизация с событийным потоком, «MER компании», детекция дрейфа реальности от модели. Тренажёр: раундовые сессии для команды в духе management flight simulator — с рассказчиком, стресс-сценариями и обязательным автодебрифингом. Wargame: состязательные сессии с думающим противником (конкурент, регулятор, ключевой клиент — живые люди или LLM-персоны); анти-паттерн BOGSAT из главы 7 — совещание, притворяющееся игрой. Прескриптивный контур: «оптимизатор предлагает — симулятор проверяет» (паттерн Amazon из главы 8); сюда же — верификация действий внешних AI-агентов компании: прежде чем агент сделает что-то в реальности, его действие проигрывается в двойнике.

Рис. 10.6. Четыре режима эксплуатации одного движка на осях «песочница ↔ синхронизация с реальностью» и «человек в контуре ↔ автономно». Оси — континуум: wargame может играться от свежесинхронизированного состояния, а зеркало — порождать песочничные ветки.

💡 Архитектурное условие всех четырёх режимов

Архитектурное условие всех четырёх режимов — из главы 7: ядро мира отдельно от способа участия; человек, скрипт и LLM — взаимозаменяемые клиенты одного ядра.

10.5. Дорожная карта

Этап 0 — онтология и лог (4–6 недель). Мета-матрица компании (роли × задачи × ресурсы × знания), экстракторы событийного лога из 2–3 систем, первый descriptive-слой. Уже полезно: process-mining-картина как побочный продукт.

Этап 1 — стилизованный движок (6–10 недель). Детерминированное ядро (тик, команды, снапшоты), SD-контур финансов + DES-контур ключевого потока создания ценности + когортный рынок с формульными ценами. Приёмка по стилизованным фактам. Уже полезно: тренажёрные сессии на стилизованной модели (ценность по Стерману возникает до всякой калибровки).

Этап 2 — калиброванный движок (8–12 недель). SIMOD-подобное выращивание операционного слоя из лога, калибровка, sensitivity-карта рычагов, бэктест на 2–3 исторических эпизодах. Уже полезно: честные «что-если» по портфелю/найму/ценам с доверительными интервалами.

Этап 3 — населённый движок. LLM-персоны ключевых фигур и клиентских сегментов (из интервью — паттерн agent bank), SOP-дисциплина взаимодействий, гейм-мастер, wargame-режим. Этап 4 — двойник с прескриптивным контуром. Непрерывная синхронизация, оптимизатор внутри симуляционного цикла, песочница для AI-агентов компании.

Рис. 10.7. Дорожная карта: пять этапов от онтологии до живого двойника. Под каждым этапом — самостоятельная ценность, которую он производит: движок строится не «большим взрывом», а лестницей полезных промежуточных состояний.

💡 Принцип дорожной карты

Каждый этап производит самостоятельную ценность — движок не должен быть «большим взрывом».

10.6. Анти-паттерны: чего не делать

Симулировать всё поагентно

анти-паттерн 01 · GlassBox

Не строить поагентную симуляцию всего (провал GlassBox: цена агентности без её выгод).

LODагрегация

Обещать точечный прогноз

анти-паттерн 02 · центробанки

Не обещать точечный прогноз — только распределения, сравнение политик и стресс-тесты (мандат центробанков).

распределения

Заморозить онтологию

анти-паттерн 03 · учебные симы

Не замораживать онтологию (главное ограничение учебных симуляторов — мир, в котором нельзя создать новую сущность).

редактируемый мир

Подтверждать любимую стратегию

анти-паттерн 04 · wargaming

Не подтверждать любимую стратегию заказчика — состязательность и красная команда встроены в жанр wargaming не случайно.

red team

Доверить LLM экономику

анти-паттерн 05 · свободный чат

Не доверять LLM-агентам экономику без явной механики (свободный чат агентов не сходится; детерминированное ядро — обязательный скелет).

механика прежде чата

Игнорировать закон Гудхарта

анти-паттерн 06 · метрики и бонусы

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

игра против модели

Пропустить дебрифинг

анти-паттерн 07 · Крукалл

И не пропускать дебрифинг: симуляция без разбора — дорогая игрушка.

разбор обязателен

10.7. Ориентиры по стеку

Ядро — на языке с хорошей производительностью и детерминизмом (Rust/C#/Go или дисциплинированный Python), архитектурно — ECS-стиль хранения состояния (глава 2) с журналом команд; для быстрых прототипов слоёв — Mesa/Agents.jl (ABM), SimPy (DES), PySD (SD). Данные — событийный лог (стандарт OCEL 2.0 для объектно-центричных событий) плюс граф знаний онтологии. LLM-слой — через шлюз с кэшированием, температурным контролем и логированием всех вызовов (воспроизводимость); каскад моделей по важности персон. Визуализация — отдельным клиентом поверх headless-ядра: дашборд состояния, Legends-запросы, режим сессий. Инструменты дизайна экономики — балансировочные таблицы и Machinations-диаграммы (глава 5) до кода. И открытые формулы для пользователей движка: мод-сообщества Victoria 3 показывают, что прозрачность механики выращивает экспертов, а не убивает доверие.

10.8. Куда двигаться дальше

Три направления, где фронтир открыт прямо сейчас (глава 9): интервью-персоны сотрудников и клиентов с валидацией на реальных решениях (метод agent bank, ~85% точности на социологических опросниках — но для бизнес-решений никем не воспроизведено); гибрид «LLM-поведение поверх калиброванной ABM-механики» — самая перспективная и самая незрелая связка; и симуляция как песочница верификации для автономных агентов — по мере того как агенты получают права действия в реальных системах компании, двойник становится их обязательной средой проверки, и это, возможно, самый сильный стратегический аргумент за то, чтобы строить движок уже сейчас.

Интервью-персоны

фронтир 01 · agent bank

Персоны сотрудников и клиентов из интервью с валидацией на реальных решениях: ~85% точности на социологических опросниках — для бизнес-решений никем не воспроизведено.

открытая ниша

LLM поверх ABM

фронтир 02 · гибрид

LLM-поведение поверх калиброванной агентной механики — самая перспективная и самая незрелая связка жанра.

перспективнонезрело

Песочница для AI-агентов

фронтир 03 · верификация

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

стратегический аргумент

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

Рис. 10.8. Шесть традиций-доноров и что каждая отдаёт движку. По отдельности всё это уже существует; собранное вместе — ещё нет. Преимущество получит тот, кто умеет переносить между традициями.