TL;DR
tok — построчная текстовая нотация и компилятор для стандартов бизнес-процессов BPMN 2.0.2 и таблиц решений DMN 1.5, созданные специально для того, чтобы человек, движок автоматизации и языковая модель работали с одним и тем же компактным текстом вместо громоздкого XML. Каждая строка в tok задаёт ровно один элемент процесса или поток (pool, lane, user, xor, flow a -> b), а движок сам расставляет координаты фигур на диаграмме, компилирует код в стандартный BPMN/DMN XML и проверяет схему через CLI или MCP-сервер.
Когда аналитик или разработчик просит LLM сгенерировать схему бизнес-процесса напрямую в формате BPMN XML, модель тратит львиную долю токенов на служебную разметку: уникальные идентификаторы, двусторонние ссылки между узлами и пиксельные координаты каждой стрелки и изгиба. Из-за этого модели часто выдают битый XML с «подвисшими» задачами без выхода, а в системе контроля версий любое мелкое изменение превращается в нечитаемую простыню из сотен поменявшихся координат.
Переход на компактный построчный синтаксис решает проблему в два шага: модели дают одностраничную шпаргалку синтаксиса tok прямо в промпте или скиле агента, а проверку отдают быстрому линтеру tok check, который возвращает ошибку с точным номером строки и именем узла. При этом исследование вскрыло важное правило проектирования агентных скилов: компактный скил со встроенной шпаргалкой обходится в разы дешевле по токенам, чем скил, который заставляет агента самому ходить за документацией через вызов инструмента.
Схема метода
В ОБЫЧНОМ ЧАТЕ (без инструментов):
ШАГ 1: Подать в промпт 1-страничную шпаргалку синтаксиса tok + текстовое описание процесса → [компактный код .tok в разы короче XML]
ШАГ 2: Скомпилировать .tok локально или в браузерном песочнице → [готовый BPMN 2.0.2 XML + DMN 1.5 + SVG-диаграмма]
В АГЕНТНОЙ СРЕДЕ (с MCP-сервером и скилом):
ШАГ 1: Подключить «тонкий скил» (Lean Skill) с правилами tok прямо в контекст (без чтения доков через тул) → [генерация черновика .tok]
ШАГ 2: Вызвать инструмент `tok check` через MCP → [локальная диагностика: код ошибки + строка + ID элемента]
ШАГ 3: Исправить ровно указанную строку и экспортировать → [100% валидный BPMN/DMN без потерянных связей]
Пример применения
Задача: Бизнес-аналитику в российском финтех-сервисе нужно быстро собрать из текстового регламента корректную схему процесса согласования возврата денег клиенту (с дорожками ролей, шлюзом проверки суммы и выходом на ручной разбор), чтобы загрузить её в Camunda 8 и показать бизнесу наглядную диаграмму без ручного рисования квадратиков.
Промпт:
Переведи описание бизнес-процесса в валидный документ нотации `tok 1.0`.
Шпаргалка по синтаксису `tok 1.0`:
- Первая строка: `tok 1.0 "Название процесса"` (добавь слово `executable`, если нужен профиль Camunda 8).
- Пулы и дорожки (отступы в 2 пробела задают вложенность):
`pool "Название пула"`
`lane "Название роли"`
- События: `start "Название"`, `end "Название"`, `catch "Название"`, `throw "Название"`.
- Задачи (по типу): `user`, `service`, `script`, `rule`, `send`, `receive`, `task`, `manual` + ` "Название"`.
- Шлюзы: `xor "Вопрос?"` (эксклюзивный), `and ` (параллельный), `or ` (неисключающий).
- Потоки управления (на уровне пула):
`flow -> -> `
Для развилок из шлюза: `flow -> "Подпись ветки"` (или условие `when=`, либо флаг `default`).
- Правила проверки: у каждого элемента должен быть уникальный ``, каждый путь от `start` обязан приходить в `end`, у каждого узла (кроме `start` и `end`) должен быть хотя бы один входящий и один исходящий поток.
Описание процесса для перевода:
Клиент подаёт заявку на возврат средств за подписку в личном кабинете. Менеджер первой линии поддержки проверяет историю списаний. Далее система автоматически проверяет условие: превышает ли сумма возврата 5 000 рублей? Если нет — сервис автоплатежей сразу оформляет возврат на карту Карта «Мир»/СБП, и процесс завершается статусом «Возврат выполнен автоматически». Если сумма больше 5 000 рублей — старший специалист антифрода вручную проверяет заявку на злоупотребление. Если нарушений нет — сервис автоплатежей проводит возврат («Возврат выполнен после проверки»). Если найден фрод — менеджер отправляет клиенту мотивированный отказ («В возврате отказано»).
Выдай только чистый код `tok 1.0`.
Результат:
Модель без единой строчки XML-мусора и геометрических координат выдаст компактный 20-строчный блок кода tok 1.0 с пулом, тремя дорожками ролей (первая линия, автоматический биллинг, антифрод), двумя шлюзами xor, тремя конечными событиями end и прозрачным списком связей flow a -> b. Этот текст сразу читается глазами в Git-диффе и одной командой tok bpmn / tok svg превращается в готовый файл для Camunda и векторную схему.
Почему это работает
Прямая генерация стандартных обменных форматов вроде BPMN XML бьёт по главному слабому месту языковых моделей — необходимости синхронизировать перекрёстные ссылки и геометрию в длинном выводе. В BPMN XML каждый узел должен перечислить ID всех входящих и исходящих стрелок, каждая стрелка — продублировать ID начала и конца, а внизу файла нужно выписать координаты x, y, width, height для каждого прямоугольника. Модель тратит до 80% выходных токенов на синтаксическую обвязку и неизбежно ошибается в идентификаторах.
Сильная сторона LLM — генерация плоского построчного кода с локальными связями (по принципу Python или Mermaid), где одна строка равна одному смысловому утверждению, а всю рутину (расчёт координат диаграммы, генерацию парных XML-тегов и проверку достижимости узлов) берёт на себя детерминированный компилятор. Поскольку в tok одна инструкция занимает ровно одну строку, любое исправление затрагивает только её.
В исследовании также проверены два важных рычага для работы с агентами:
- «Тонкий скил» (Lean Skill) против чтения документации через инструмент: если положить одностраничную шпаргалку по синтаксису прямо в текст скила агента, он решает задачу в 1,7–2,8 раза экономнее по токенам, чем когда скил короткий и отправляет агента читать справочник через отдельный вызов инструмента.
- Локализованная диагностика с номером строки и ID элемента: когда чекер вместо размытой ошибки схемы возвращает конкретную строку вида line 10: warning W042: path without an end event (element without outgoing flow) (locate), агент в цикле MCP чинит ровно одну строчку и доводит долю валидных моделей почти до 100%.
Шаблон промпта
Этот шаблон позволяет как генерировать сам формат tok, так и применить главный архитектурный приём статьи — Lean Skill + однострочная промежуточная нотация — для любых сложных схем и конфигураций:
Ты — архитектор бизнес-процессов. Составь модель процесса в построчной нотации `tok 1.0` по описанию ниже.
1. Заголовок: `tok 1.0 "{название_процесса}"` (добавь `executable` для Camunda 8).
2. Контейнеры (вложенность — 2 пробела):
`pool "Название"` -> внутри `lane "Роль"`.
3. Узлы внутри дорожки:
- События: `start "Текст"`, `end "Текст"`, `catch "Текст" [timer|message|error]`, `throw "Текст"`.
- Задачи: `user|service|script|rule|send|receive|manual|task "Текст"`.
- Подпроцессы: `sub "Текст"` (с вложенным блоком).
- Шлюзы: `xor|and|or|eventgw "Вопрос"`.
4. Связи (внутри пула):
- Цепочка: `flow -> -> `
- Ветвление: `flow <шлюз> -> <цель> "Подпись"` (или `when=`, или `default`).
- Межпуловые сообщения: `message <откуда> -> <куда> "Текст"`.
5. Решения DMN 1.5 (опционально): блок `decision "Название"` с таблицей правил и привязкой к `rule`-задаче.
Перед выводом кода проверь себя по правилам `tok check`:
- Каждый `` уникален и состоит из одного слова латиницей.
- Нет «висячих» узлов: каждый элемент лежит на пути от `start` к `end` (ошибки W041 / W042).
- У каждого развилочного шлюза `xor` / `or` подписаны исходящие ветки.
Входное описание процесса:
{описание_процесса_и_правил}
Что подставлять в плейсхолдеры:
- {название_процесса} — краткий заголовок регламента или услуги.
- {описание_процесса_и_правил} — текст регламента, список ролей, развилок, сроков и бизнес-правил.
🚀 Быстрый старт — вставь в чат:
Вот шаблон генерации бизнес-процессов в компактной нотации tok 1.0. Адаптируй под мой процесс: [кратко опиши свой процесс].
Задавай вопросы, чтобы уточнить роли, развилки и условия завершения.
[вставить шаблон выше]
LLM спросит, какие роли участвуют в процессе, в каких точках принимаются решения (развилки «да/нет») и чем именно должен заканчиваться каждый сценарий — потому что в стандарте BPMN каждая ветка обязана приходить в явное конечное событие end.
Ограничения
⚠️ Для конвертации в стандартный BPMN XML и SVG нужен движок
tok: В обычном чате модель напишет чистый и понятный человеку текст.tok, но чтобы загрузить его в Camunda, Stormbpmn или Miro как готовую XML-схему с раскладкой фигур, потребуется запустить CLI-утилиту, браузерный WebAssembly-плейграунд или MCP-серверtok.
⚠️ Узкая предметная область самой нотации: Синтаксис
tokзаточен строго под процессы BPMN 2.0.2 и таблицы решений DMN 1.5. Для произвольных архитектурных схем или UI-макетов он не предназначен (хотя принцип «построчный DSL + тонкий скил + локальный чекер» универсален).
⚠️ Автоматическая раскладка уступает ручной верстке сложных плакатов: Поскольку координаты фигур убраны из текста и считаются алгоритмом движка, на гигантских запутанных схемах пользователь не может вручную подвинуть отдельный кубик на пару пикселей прямо внутри
.tok-файла — геометрия вынесена во внешний слой.
Как исследовали
Автор из Ягеллонского университета проверил нотацию tok и её Rust-движок в шести измерениях, чтобы честно посчитать выгоду для всех трёх «читателей» схемы: человека, программы и языковой модели. Сначала взяли 893 реальных файла BPMN XML, экспортированных из 37 разных редакторов в эталонном наборе OMG: оказалось, что запись той же модели в tok занимает в 7,7 раза меньше токенов, чем исходный экспорт с координатами диаграммы, и в 2,2 раза меньше токенов, чем самый ужатый BPMN XML вообще без координат (например, процесс межбиблиотечного абонемента весит всего 134 токена в tok против 699 токенов в голом XML и 2 173 токенов в XML с геометрией). Затем на 1 411 искусственно внесённых ошибках моделирования проверили качество валидации: встроенный чекер tok check поймал 98,2% дефектов с указанием точной строки за ~20 миллисекунд, тогда как связка стандартной XML Schema и популярного линтера bpmnlint заметила только 85,8%.
Самый интересный для практиков эксперимент провели на четырёх языковых моделях из трёх разных семейств, которым дали 87 текстовых описаний процессов из двух публичных датасетов. Хотя модели впервые в жизни видели синтаксис tok (его не было в их обучающей выборке), по одной лишь одностраничной шпаргалке в промпте они с первой попытки написали полностью валидный tok для 85,7–100% описаний, а самая сильная модель потратила на генерацию на 25% и 19% меньше токенов, чем при написании BPMN XML. Когда же модели запустили в режиме агентов с одним инструментом проверки (tok check) и «тонким скилом», доля валидных моделей выросла до 97,6–100% при экономии 21% и 14% токенов относительно агента, пишущего XML. При этом сравнение двух дизайнов скила показало яркий антипаттерн: скил, который вместо встроенной шпаргалки заставлял агента вызывать инструмент для чтения документации по синтаксису, сжигал в 1,7–2,8 раза больше токенов, чем компактный самодостаточный скил.
Адаптации и экстраполяции
🔧 Техника: «Тонкий скил» (Lean Skill) со встроенной шпаргалкой вместо чтения доков через тул → экономия токенов в 1,7–2,8 раза
Этот вывод из работы напрямую переносится на написание любых скилов (
SKILL.md,CLAUDE.md) в Claude Code, Cursor и MCP-агентах. Разработчики часто делают скил-заглушку из 5 строк: «Когда нужно сгенерировать формат X, сначала вызови инструментread_docsи прочитай справочник». Исследование доказывает, что это ложная экономия: вызов инструмента и чтение большого справочника в истории диалога раздувают расход токенов почти втрое. Вместо этого сожми 80% используемых конструкций языка в одну страницу (до 150–200 строк) и положи её прямо в тело скила, а внешнему инструменту оставь только функциюcheck(валидацию с номером строки).
Экстраполяция: Формат ошибок чекера
Файл:Строка: Код: Смысл (ID элемента)для своих валидаторовЕсли ты пишешь скрипт проверки JSON, SQL или конфигов, который отдаёт обратную связь ИИ-агенту, не возвращай ему сырой стектрейс парсера. Оформи вывод строго по формуле прагматики
tok check:[Имя_файла]:[Номер_строки]: [error|warning] [Код]: [Что нарушено простыми словами] ([ID проблемного узла])Когда одна сущность занимает одну строку, а ошибка называет и строку, и ID узла, агент исправляет баг за одну итерацию без переписывания всего файла.
Ресурсы
Исследование: tok: a textual concrete syntax of BPMN and DMN for humans and AI agents (arXiv:2611.07945v1) Автор: Marek Deja (Jagiellonian University, Kraków, Poland)