§9.02 Архитектура конечных автоматов
Время: 45 мин чтение + 30 мин
В одном предложении: Пилот думает, что агенты — это «умные чёрные ящики», которые сами разберутся, что делать, а на самом деле без чёткой архитектуры конечных автоматов поведение агентов становится непредсказуемым, неотлаживаемым и необъяснимым, и вместо усиления пилот получает хаос, который маскируется под интеллект.
Мем, который снимается. «FSM — это для программистов, я просто пользователь. Мои агенты понимают меня с полуслова, зачем мне какие-то состояния и переходы?» На самом деле вы уже используете конечные автоматы, просто неявно и плохо. Когда ваш РП «открыт», потом «в работе», потом «на проверке» — это состояния. Когда вы решаете «давайте отправим на ревью» — это переход. Разница между неявным и явным FSM в том, что в первом случае состояния живут в голове пилота и истории чатов, а во втором — зафиксированы, проверяемы и отлаживаемы. Неявный автомат работает, пока пилот помнит контекст. Когда контекст теряется — система ломается тихо и незаметно.
Понятия. FSM (Finite State Machine, конечный автомат) — модель управления состояниями, в которой система в каждый момент времени находится в одном из конечного числа состояний, а переходы между состояниями инициируются событиями и ограничены условиями. Состояние — дискретный режим функционирования агента, РП или протокола, характеризуемый чётким набором допустимых действий и выходных данных. Переход — смена состояния, triggered by событие и guarded by условие. В IWE FSM-архитектура применяется на трёх уровнях: жизненный цикл РП, режимы работы агентов и фазы протоколов.
Объяснение. FSM делает поведение предсказуемым и отлаживаемым на масштабе. На ступени 1–2 пилот помнит состояние всей системы в голове: «этот РП в работе, тот на паузе, агент занят». На ступени 4–5 такая память невозможна: десятки РП, несколько агентов, параллельные процессы. Без явных состояний пилот превращается в диспетчера, который тратит энергию на отслеживание, а не на творчество.
FSM работает на трёх уровнях IWE. Первый — жизненный цикл РП: «открыт» → «в работе» → «на проверке» → «закрыт». Каждое состояние имеет чёткие критерии входа и выхода. Переход «на проверку» возможен только если выполнен критерий приёмки. Второй — режимы агентов: «idle», «сбор контекста», «генерация», «ревью», «доставка». Агент в состоянии «сбор контекста» не генерирует ответ — он только читает. Это защита от преждевременных выводов. Третий — фазы протоколов: ОРЗ имеет состояния «Открытие», «Работа», «Закрытие», и переходы между ними невозможны без выполнения чеклиста.
Отладка в FSM-архитектуре сводится к трём вопросам: в каком состоянии система? Какое событие должно было вызвать переход? Почему условие перехода не выполнено? Вместо археологии истории чатов («почему агент сделал это?») вы проверяете состояние и лог переходов. Это разница между минутой и часом отладки.
На практике. Практика «FSM для одного процесса» (30 мин):
- Выберите один процесс в вашей IWE: жизненный цикл РП, workflow агента или протокол. (5 мин)
- Перечислите все состояния, которые процесс проходит от начала до конца. Не менее трёх, не более семи. (10 мин)
- Для каждого состояния определите: что можно делать в этом состоянии? что нельзя? (5 мин)
- Опишите переходы: из какого состояния в какое, что triggerит переход, какие условия должны выполниться. (7 мин)
- Зафиксируйте в Pack: схему, правила, пример. (3 мин)
Типичный кейс. Команда из пяти человек использовала агента для генерации архитектурных решений. Иногда агент выдавал блестящий результат, иногда — бессмысицу. Отладка занимала часы: приходилось читать всю историю переписки, чтобы понять, что пошло не так. После введения FSM-архитектуры агент получил четыре состояния: «idle», «сбор контекста», «генерация ADR», «ревью». Переход в «генерация» возможен только после подтверждения пилота, что контекст собран полностью. Переход в «ревью» — только после прохождения чеклиста качества. Когда результат оказался плохим, отладка заняла три минуты: агент перешёл в «генерация» из состояния «idle», пропустив «сбор контекста». Правило было исправлено, ошибка больше не повторялась.
Типичная ошибка. «FSM — это жёсткость, а моя работа творческая, мне нужна гибкость.» На самом деле FSM освобождает творчество, убирая неопределённость в структуре. Художник тоже работает в фазах: эскиз, подмалёвок, детализация, финал. Он не считает это жёсткостью — он считает это каркасом, внутри которого свобода. Другая ошибка: «Добавлю состояния потом, когда масштаб вырастет.» Потом не наступает, потому что неявный автомат накапливает ошибки быстрее, чем вы успеваете их исправлять. Чем раньше FSM явен, тем меньше техдолг.
Степени мастерства:
| Степень | Что происходит | Критерий перехода |
|---|---|---|
| 1. Объясняю | Могу назвать три состояния и два перехода для одного процесса в своей IWE | Один раз описал FSM для реального процесса и зафиксировал в Pack |
| 2. Умею | Для каждого нового РП или агента сразу проектирую FSM: состояния, переходы, триггеры | Три процесса подряд работают по явному FSM без деградации в неявный |
| 3. Навык | Системно использую FSM для отладки: при сбое первым делом проверяю состояние и лог переходов | Коллега или агент заметили, что «с вашими процессами всегда понятно, где искать ошибку» |
| 4. Мастерство | Проектирую FSM-фреймворк для всей агентной экосистемы: единые соглашения о состояниях, библиотека переходов, инструменты визуализации | Другая команда внедрила ваш FSM-фреймворк и сократила время отладки вдвое |
Проверка себя.
- Могу нарисовать схему состояний и переходов для своего текущего РП без заглядывания в Pack
- При сбое агента или процесса я сначала проверяю состояние, а не перечитываю всю историю
- У меня есть хотя бы один процесс в IWE, где состояния зафиксированы и проверяемы
- Я могу объяснить, чем отличается «состояние» от «статуса» в моей системе
- Мои агенты не генерируют выходные данные в состоянии «сбор контекста»
На практике. Возьмите текущий РП. Запишите его состояние прямо сейчас. Какое событие переведёт его в следующее состояние? Какие условия должны выполниться? Если ответ звучит как «когда будет готово» — у вас нет FSM, у вас надежда. Замените «когда будет готово» на проверяемое условие.
См. также: Проводник по траектории — PD.GUIDE.3.S9.SS1, Эпистемический граф — PD.GUIDE.3.S9.SS3.
Что дальше. Следующий подраздел — об эпистемическом графе: как связать знания в Pack так, чтобы понятия не лежали плоско, а образовывали структуру, через которую видно, почему мы знаем то, что знаем.