LLMOS — детерминированная основа, СПРОЕКТИРОВАННАЯ под каждый процесс движка Forge . Она описана и специфицирована, но ещё не реализована — см. раздел «Состояние». Сегодня воспроизводимость обеспечивается снимком на каждый ход на уровне сессий.
Почему рантайм, а не журнал чата
Вызовы модели вероятностны. Задайте один и тот же вопрос дважды — можете получить два разных ответа. Для чат-бота это нормально. Для многоагентного конвейера, выпускающего продакшен-код, — нет.
LLMOS заимствует у баз данных то, что базы данных заимствовали у бухгалтеров: неизменяемый журнал событий. Каждый промпт, каждый ответ, каждое изменение состояния — пронумерованное событие в потоке, доступном только на добавление. «Текущее состояние» любого процесса — просто свёртка этого потока. Отсюда:
- Воспроизведение тривиально — подайте события функции проекции по порядку.
- Ветвление дёшево — скопируйте указатель потока, дописывайте расходящиеся события.
- Аудит точен — каждое решение ссылается на породившее его событие.
- Воспроизводимость структурна — на тех же событиях вы всегда получаете то же состояние.
Вероятностная часть (вызов модели) заключена внутри отдельных событий. Оркестрация вокруг них полностью детерминирована.
Язык .llmos
Процессы LLMOS пишутся на небольшом языке, который компилируется в типизированное дерево и исполняется на движке с журналом событий.
agent pm {
model = "claude-sonnet-4-6"
temperature = 0.2
max_tokens = 8000
}
agent architect {
model = "claude-opus-4-7"
temperature = 0.1
}
workflow design_session {
use pm
message system "You are a product manager writing acceptance criteria."
message user from input.issue_body
if tokens > 12k {
compress history using extract_facts(max=600)
}
snapshot pm_done
use architect
message system "You are a staff engineer designing the technical solution."
message context structured.goals, structured.constraints
emit
}
Слоистая память
LLMOS смотрит на память как на стопку проекций над журналом событий:
| Слой | Что | Где | Зачем |
|---|---|---|---|
| L0 — сырые события | Каждый токен, вызов инструмента, решение | Таблица PostgreSQL только на добавление | Источник истины, неизменяемый |
| L1 — активный контекст | То, что модель видит прямо сейчас | Вычисляется на каждый ход | Проекция с учётом бюджета токенов |
| L2 — структурированное состояние | Цели, ограничения, решения, факты, открытые вопросы | Сохраняется, обновляется событиями | Переживает сжатие |
| L3 — векторный индекс | Эмбеддинги сообщений | pgvector | Семантический поиск по истории |
Когда сессия подходит к бюджету контекста, LLMOS не обрезает, а проецирует. Структурированное состояние в L2 (решения, цели, ограничения) сохраняется в точности. Сырая переписка в L1 сжимается, дедуплицируется или заменяется извлечёнными фактами. Ничего не уничтожается: события L0 остаются на месте для воспроизведения.
Стратегии сжатия
Четыре политики сжатия, выбираются на процесс:
summary— сгенерированный моделью нарратив, сжимающий диалог в одно системное сообщение. Дёшево и быстро, теряет детали.extract_facts— извлечение структурированного JSON (цели/ограничения/решения/факты/вопросы). Рекомендуемое умолчание. Обновляет L2 напрямую.semantic— дедупликация по эмбеддингам, без вызова модели. Отбрасывает сообщения с косинусной близостью выше порога.structured— самое агрессивное: extract_facts вместе с semantic. Для очень длительных конвейеров.
Сжатие проверяется: извлечённые факты сверяются с исходными событиями, чтобы не появилось галлюцинированное состояние. Конфликты решений (одна тема, разные значения в разных кругах сжатия) разрешаются по порядку — побеждает последнее событие.
Ветвление
fork microservices_path {
use architect
message user "Design as separate microservices"
emit
}
fork monolith_path {
use architect
message user "Design as a modular monolith"
emit
}
compare microservices_path monolith_path
using judge(model="claude-opus-4-7")
select best
Ответвление создаёт изолированный поток событий, расходящийся с текущего порядкового номера. Обе ветки идут независимо. compare вызывает агента-судью, чтобы оценить их по заданным вами критериям. select best вливает победившую ветку обратно в основной поток.
Ветки не влияют на основной поток до слияния. Их можно сохранить для воспроизведения или отбросить.
API перемещения во времени
| |
Когда агент-разработчик выдал ошибочную реализацию на ходу 47, не нужно перезапускать весь конвейер — можно сделать ForkFrom(stream, 46, "v2") и исследовать альтернативы начиная с последнего хорошего состояния.
Состояние
LLMOS сейчас — исследовательская и проектная работа. Спецификация языка, типы дерева, модель исполнения, схема событий, конвейер сжатия и API перемещения во времени спроектированы и описаны. Реализация не начата — текущий конвейер Forge использует более простой подход на машине состояний ролей, который работает уже сегодня.
Когда LLMOS появится, Forge перенесёт на него многоагентный конвейер ради более сильной воспроизводимости и простого ветвления. До тех пор конвейер получает воспроизводимость через снимок на каждый ход на уровне сессий.
Почему это важно
Цена вероятностных систем — часто цена отладки. Когда сегодня в многоагентном конвейере что-то идёт не так, вы листаете журналы чата, пытаясь понять, какое решение было неверным. С LLMOS вы воспроизводите до проблемного события, сравниваете состояние до и после и либо детерминированно перезапускаете, либо ответвляетесь в исправленную ветку.
Инфраструктурное мышление, применённое к оркестрации ИИ. Такова ставка.