Моделирование процесса как Storyline — правильный подход

Превращение сложного процесса в Storyline — это упражнение в моделировании, а не транскрипция. Механика описана в Compile a flow into a Storyline; здесь же речь о том, как думать об этом, чтобы результат был надёжным, а не просто графом, который «в основном работает».

Начинайте с профиля, затем определяйте точки принятия решений

Прежде чем рисовать узлы, решите, что вы отслеживаете — это profile_schema (например, docs_ready, risk_flag, attempts). Затем сопоставьте реальные точки принятия решений, а не только счастливый путь. Каждое место, где разговор может разветвиться или завершиться неудачей, является узлом с выходами; поток, который моделирует только идеальный путь, ломается при первом же неожиданном действии пользователя.

Один узел = один согласованный шаг

Узел должен выполнять одно действие, которое человек мог бы назвать («собрать документы», «подтвердить личность»). Не пытайтесь впихнуть весь подпроцесс в task одного узла и надеяться, что модель выстроит его последовательно — вы теряете возможность ветвления, возобновления и измерения. Если в задаче узла есть «и затем, и затем», это несколько узлов.

Делайте ветвление детерминированным там, где результат должен быть надёжным

• Маршрутизируйте по rule (против измерений профиля) или user_choice, когда ветвление должно быть предсказуемым. Оставляйте выходы ai для реальной оценки («действительно ли они описали свою проблему?»).
• Выходы имеют приоритетный порядок — размещайте детерминированные выходы первыми, а ai по умолчанию — последним.
• Моделируйте цикл повторных попыток с помощью обратной связи и счётчика writes (op: "inc") и ограничения rule. Никогда не полагайтесь на решение модели о том, что цикл завершился достаточно раз.

Храните идентичность и безопасность на агенте, а не на узле

soul агента и границы безопасности постоянны на протяжении всей Storyline — в этом и есть смысл. Не пытайтесь повторно задавать персонаж или повторно применять безопасность для каждого узла; узлы только добавляют задачу/навыки/знания/инструменты и записывают измерения профиля.

Сохраняйте стабильность node_keys; проверяйте перед публикацией

node_key — это идентификаторы выходов и ссылка на воронку. При редактировании с помощью update_storyline сохраняйте их стабильными — переименование узла молча лишит его выходы привязки. Всегда вызывайте validate_storyline перед publish_storyline; это выявит недостижимые узлы, тупики и висячие выходы.

Не моделируйте излишне

Если задача — это один вопрос и ответ, это не Storyline — это агент с базой знаний. Обращайтесь к Storyline, когда есть реальное многошаговое состояние, которое нужно сохранять (сбор данных, обучение, пошаговое заполнение заявки). Моделирование одноразового Q&A в виде графа добавляет затраты и режимы отказа ни к чему.

Распространённые ошибки (избегайте их)

• Только счастливый путь — нет выхода для «пользователь запутался» или «не предоставил данные», поэтому поток зависает.
• Всё является выходом ai — маршрутизация становится лотереей; одни и те же входные данные приводят к разным путям.
• Мега-узел — task одного узла описывает весь процесс; ничего не может ветвиться или возобновляться.
• Неограниченные циклы — обратная связь без счётчика и без ограничения.
• Повторное описание безопасности для каждого узла — шум, конкурирующий с реальной границей агента.

Исправьте это, называя реальные состояния и перенося каждое решение на детерминированный выход.