Что здесь на самом деле означает рабочий процесс
Большинство «процессных» инструментов в области ИИ — это цепочки промптов с тонкой надстройкой. Конструктор ToRun — это направленный ациклический граф (DAG) типизированных шагов: вы связываете вызовы моделей, вызовы инструментов, условные ветвления, циклы и подпроцессы в граф, а движок выполняет их в порядке зависимостей, параллельно там, где граф это позволяет.
Каждый шаг — полноценная сущность со своей настройкой: тип шага (вызов LLM, веб-поиск, выполнение кода, генерация изображения, извлечение, преобразование и т. д.), схема входа, политика ошибок (быстрый отказ, повтор с задержкой, переход к альтернативе), потолок бюджета выполнения на шаг и предельное время.
Маршрутизация модели внутри каждого шага LLM идёт через тот же конвейер возможностей, что и всё остальное в ToRun. Вы объявляете, что нужно — структурированный вывод, зрение, использование инструментов, рассуждение, окно контекста не менее N токенов — и исполнитель разрешает наиболее подходящую модель среди доступных на тот момент поставщиков. Если предпочитаемый поставщик вернёт 5xx, цепочка резерва подхватит автоматически.
Исполнители с приоритетом качества и что это даёт на практике
Когда вы запускаете процесс, исполнитель намеренно выбирает модели качественного уровня, а не самый дешёвый вариант. Две причины: автоматизации создают артефакты (отчёты, сгенерированный контент, код), которые никто не проверяет сразу, поэтому огрехи качества копятся молча; а при умеренных объёмах разница в стоимости меньше цены плохого результата, из-за которого приходится перезапускать или править вручную.
На практике это значит, что процесс «обобщить исследование и составить отчёт» предпочтёт крепкую модель рассуждения для обобщения и качественную текстовую модель для написания, а не побежит к ценовому дну. Вы можете переопределить это на конкретном шаге, если знаете, что там достаточно лёгкой модели.
Биллинг следует остальному ToRun: каждый вызов модели внутри процесса пишет ровно одну запись с замороженным снимком тарифа. Прогон, вызывающий три разные модели на пяти шагах, даёт пять записей. Вы можете проверить точную стоимость каждого прогона, разбитую по шагам, постфактум — даже спустя месяцы, когда тарифы поставщиков уже сдвинутся.
Разбор прогона
Каждый прогон процесса даёт структурированную трассировку. Трассировка показывает DAG с аннотацией каждого узла: время начала, время окончания, разрешённая модель, число входных и выходных токенов, выполненные вызовы инструментов и ошибка, если она была. На шагах LLM можно развернуть точный отправленный промпт и полученный сырой ответ.
Если шаг падает, трассировка говорит, пришла ли ошибка от вызова модели (ошибка поставщика, переполнение контекста, отказ по политике контента), от инструмента ниже по потоку (тайм-аут сети, сбой проверки схемы) или от вашей собственной условной логики. Вам не нужно добавлять журналирование: оно фиксируется на уровне инфраструктуры при каждом прогоне.
Любой прогон можно повторить с тем же входом, что делает воспроизведение сбоя прямым.
Небольшой пример: еженедельный процесс конкурентной разведки
Представьте процесс, который вы запускаете каждый понедельник утром:
- Шаг веб-поиска — ищет свежие публикации по набору конкурентных ключевых слов и возвращает список адресов и выдержек.
- Шаг извлечения — поднимает последние четыре отчёта из базы знаний, чтобы задать исходный контекст.
- Шаг обобщения (LLM) — сводит результаты поиска в структурированные наблюдения: новые функции, изменения цен, заметные анонсы.
- Шаг написания (LLM) — пишет краткую внутреннюю записку в едином фирменном стиле, опираясь на обобщённые наблюдения.
- Шаг доставки — публикует записку в настроенную веб-точку.
У графа естественная зависимость: шаг 3 зависит от 1 и 2 (которые могут идти параллельно), шаг 4 — от 3, шаг 5 — от 4. Исполнитель делает это без всякой явной настройки параллелизма: он читает рёбра.