- Что такое агентный воркфлоу?
- Чем агентный воркфлоу отличается от ИИ-агента?
- Каковы ключевые компоненты агентного воркфлоу?
- Почему планирование важно при создании агентных воркфлоу
- Как должна работать работа с инструментами в агентном воркфлоу?
- Почему выполнение кода требует песочницы?
- Как оценивать агентный воркфлоу?
- Практичная архитектура для создания агентных воркфлоу
- Пример: контроллер агентного воркфлоу на Python
- Какую модель выбрать в качестве планировщика?
- Частые сценарии отказов в агентных воркфлоу
- Когда не стоит использовать агентный воркфлоу?
- Часто задаваемые вопросы
- Рекомендуемые статьи
Агентный воркфлоу — это многошаговая система, в которой языковая модель не просто отвечает один раз: она планирует, выбирает инструменты, выполняет действия, проверяет результат и решает, что делать дальше, пока задача не будет выполнена. На практике это означает объединение уровня рассуждений LLM с вызовом инструментов, реальной средой выполнения и циклом оценки. Если вы создаёте агентов для написания кода, исследовательских агентов или внутреннюю автоматизацию, которая должна адаптироваться по ходу задачи, обычно вы строите именно такую архитектуру.
Что такое агентный воркфлоу?
Агентный воркфлоу — это паттерн, лежащий в основе ИИ-систем, которые могут продвигаться по задаче, а не останавливаться на генерации текста. Вместо того чтобы запрашивать у модели один ответ и возвращать его пользователю, вы позволяете модели действовать внутри контролируемого цикла:
- Прочитать цель и текущее состояние.
- Спланировать следующий шаг.
- Вызвать инструмент или запустить код.
- Наблюдать результат.
- Оценить, завершена ли задача.
- Повторить при необходимости.
Это отличается от фиксированного воркфлоу, где каждый шаг заранее прописан в коде. В фиксированном воркфлоу вы заранее определяете путь. В агентном воркфлоу модель решает, какое действие выполнить следующим, в заданных вами границах.
Это различие важно, потому что многие реальные задачи разработчика не линейны. Агенту для написания кода может понадобиться изучить файлы, прежде чем он узнает, какой тест запускать. Исследовательский агент может поискать дважды, потому что первый источник оказался неполным. Браузерный агент может столкнуться с ошибкой входа или изменённым макетом страницы. Это проблемы воркфлоу, но они требуют адаптации.
Чем агентный воркфлоу отличается от ИИ-агента?
Люди часто используют эти термины как взаимозаменяемые, но полезнее их разделять:
- Агентный воркфлоу — это паттерн выполнения.
- ИИ-агент — это продукт или система, построенная поверх этого паттерна.
У вас может быть узконаправленный агентный воркфлоу, который только обрабатывает тикеты поддержки, или более широкий ИИ-агент, координирующий планирование, использование инструментов, память и контрольные точки согласования в множестве задач.
Если вам нужно практическое правило, используйте воркфлоу, когда говорите об архитектуре и потоке управления, и агент, когда говорите о системе, обращённой к пользователю.
Каковы ключевые компоненты агентного воркфлоу?
Большинство продакшн-систем в итоге состоят из одних и тех же пяти частей.
1. Планировщик
Планировщик превращает общую инструкцию в следующее конкретное действие. Иногда это явный шаг планирования, который выводит список задач. Иногда он неявный и происходит внутри каждого хода вызова инструмента. В любом случае модели нужно достаточно контекста, чтобы решить, стоит ли читать, писать, искать, выполнять или остановиться.
Хорошее планирование не означает генерацию длинного плана для каждого запроса. Это означает сохранение понятности следующего шага. Для коротких задач достаточно одношагового планирования. Для более длинных задач, таких как рефакторинг репозитория, автоматизация браузера или проверка документов, явный план снижает метания.
2. Слой инструментов
Инструменты — это интерфейс воркфлоу с внешним миром. Сильный слой инструментов, как правило, узкий и предсказуемый. Например:
read_file(path)write_file(path, content)search_files(query)run_command(cmd)fetch_url(url)
Маленькие инструменты модели проще вызывать корректно, их проще логировать и защищать. Большие инструменты «делают всё» поначалу выглядят удобно, но становятся сложными в отладке, потому что невозможно понять, пришли ли сбои от решения модели, реализации инструмента или внешней системы за ним.
3. Среда выполнения
Как только модель решает действовать, кто-то должен выполнить действие. Для любого воркфлоу, который записывает файлы, устанавливает пакеты, запускает код или открывает сессии браузера, эта среда должна быть изолированной.
Здесь на помощь приходит песочница. Novita Agent Sandbox создан именно для этого слоя выполнения: отдельная среда, где действия агента могут выполняться, не затрагивая напрямую хост-систему. Это разница между «модель предложила команду» и «воркфлоу безопасно выполнил эту команду».
4. Состояние и память
Агентному воркфлоу нужна рабочая память между шагами. Обычно она включает:
- состояние диалога
- результаты инструментов
- промежуточные файлы
- журналы выполнения
- черновик или краткий план
Без состояния каждый шаг превращается в беспамятный инжиниринг промптов, и система разваливается, как только задача охватывает более одного действия.
5. Цикл оценки
Это та часть, которую многие команды добавляют слишком поздно. Воркфлоу должен уметь оценивать, успешен ли шаг и завершена ли задача. В воркфлоу для кода это может означать, что тесты проходят. В исследовательском воркфлоу — что ответ ссылается на достаточно надёжные источники. В браузерном воркфлоу — что ожидаемое состояние интерфейса видно.
Без оценки «агентность» часто превращается в «постоянно вызывает инструменты до тайм-аута».
Почему планирование важно при создании агентных воркфлоу
Самая большая ошибка при создании агентных воркфлоу — предполагать, что модель должна импровизировать всё с нуля на каждом шаге.
Обычно это создаёт три проблемы:
- модель многократно возвращается к одним и тем же файлам или URL
- использование инструментов становится шумным и дорогим
- воркфлоу теряет чёткое условие остановки
Лучший паттерн — лёгкое планирование плюс обоснованное выполнение. Позвольте модели решать следующее действие, но пусть она делает это на основе явной задачи, видимого текущего состояния и небольшого набора разрешённых инструментов. Это сохраняет гибкость там, где она полезна, и убирает её там, где нет.
В воркфлоу для кода планирование часто выглядит так:
- Определить задействованные файлы.
- Прочитать текущую реализацию.
- Определить минимальное изменение.
- Внести правку.
- Запустить проверку.
- Остановиться или исправить.
Это по-прежнему агентный подход, потому что модель может ответвиться, когда репозиторий ведёт себя неожиданно. Но это не бесцельное блуждание.
Как должна работать работа с инструментами в агентном воркфлоу?
Использование инструментов должно быть явным, типизированным и наблюдаемым.
Если ваша модель поддерживает вызов функций, используйте это. LLM API от Novita предоставляет OpenAI-совместимую конечную точку и напрямую документирует вызов функций — это самый чистый способ позволить модели выбирать между инструментами, не полагаясь на хрупкий разбор строк.
Несколько правил делают использование инструментов гораздо надёжнее:
- Держите имена инструментов конкретными.
- Используйте схемы с обязательными полями.
- Возвращайте полные результаты, включая ошибки.
- Логируйте каждый вызов, аргумент и вывод.
- Делайте деструктивные действия редкими и легко контролируемыми.
Слой инструментов также должен отражать реальные границы. Например, не давайте агенту для кода один мега-инструмент под названием edit_repo_and_run_tests. Разделите шаги чтения, записи и выполнения, чтобы модель могла восстановиться при сбое.
Почему выполнение кода требует песочницы?
Агентный воркфлоу, который ничего не выполняет, часто может оставаться внутри обычного сервера приложения. Как только он начинает запускать команды оболочки, устанавливать зависимости, обрабатывать загруженные файлы или просматривать открытый веб, вам нужна изоляция.
Песочница решает две разные задачи:
- Безопасность: сгенерированный код и результаты инструментов могут быть ошибочными, враждебными или просто непредсказуемыми.
- Состояние: многошаговым задачам нужно постоянное рабочее пространство, где файлы, пакеты и история выполнения сохраняются между шагами.
Для многих команд второй момент так же важен, как и первый. Воркфлоу, который редактирует код, запускает тесты, исправляет сбой и повторяет проверку, невозможен, если каждый шаг начинается с чистой машины.
Именно поэтому практичная архитектура обычно выглядит так:
- LLM API для планирования и выбора инструментов
- Песочница как среда выполнения и сохранения состояния
Novita естественно подходит под такое разделение: LLM API работает как слой планирования и вызова инструментов, а Agent Sandbox обеспечивает реальную среду выполнения.
Как оценивать агентный воркфлоу?
Оценка должна происходить на двух уровнях.
Оценка шага
Сработало ли последнее действие?
Примеры:
- Команда завершилась успешно?
- API вернул корректный JSON?
- Ожидаемый файл был создан?
- Страница браузера содержала целевой элемент?
Оценка задачи
Решил ли воркфлоу проблему пользователя?
Примеры:
- Тесты проходят после изменения кода?
- Сводка отвечает на исследовательский вопрос с подтверждениями?
- Автоматизация завершила транзакцию без ручной очистки?
Сильные воркфлоу используют оба уровня. Если оценивать только конечный результат, вы пропускаете очевидные сигналы сбоев во время выполнения. Если оценивать только шаги, воркфлоу может выполнить длинную серию локально корректных действий и всё равно не справиться с реальной задачей.
Практичная архитектура для создания агентных воркфлоу
Вот архитектура, с которой большинству команд стоит начать:
- Пользовательский запрос попадает в ваше приложение.
- Ваш контроллер отправляет цель, состояние и доступные инструменты в LLM.
- LLM возвращает либо прямой ответ, либо вызов инструмента.
- Ваш контроллер выполняет инструмент внутри песочницы или другой контролируемой среды.
- Результат инструмента добавляется к состоянию диалога.
- Оценщик проверяет завершение, сбой или контрольные точки согласования.
- Цикл продолжается, пока воркфлоу не будет завершён или заблокирован.
Этот цикл контроллера может быть простым. Во многих случаях достаточно одного процесса-оркестратора. Не нужна мультиагентная система с первого дня. Начните с одного планировщика, нескольких хорошо определённых инструментов, одной песочницы и понятного оценщика.
Пример: контроллер агентного воркфлоу на Python
Пример ниже показывает форму цикла управления. Он использует OpenAI-совместимый API Novita для вызова инструментов. Функции выполнения вы реализуете сами для своей среды или песочницы.
import json
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.novita.ai/openai",
api_key=os.environ["NOVITA_API_KEY"],
)
tools = [
{
"type": "function",
"function": {
"name": "read_file",
"description": "Read a file from the workspace",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "run_command",
"description": "Run a shell command in the sandbox",
"parameters": {
"type": "object",
"properties": {"cmd": {"type": "string"}},
"required": ["cmd"],
},
},
},
]
def read_file(path: str) -> str:
# Implement this against your own workspace or sandbox filesystem.
raise NotImplementedError
def run_command(cmd: str) -> str:
# Implement this against your sandbox runtime.
raise NotImplementedError
dispatch = {
"read_file": read_file,
"run_command": run_command,
}
def run_workflow(task: str, model: str) -> str:
messages = [
{
"role": "system",
"content": (
"You are a workflow controller. Use tools when needed, "
"check results after each action, and stop when the task is complete."
),
},
{"role": "user", "content": task},
]
while True:
response = client.chat.completions.create(
model=model,
messages=messages,
tools=tools,
tool_choice="auto",
)
message = response.choices[0].message
messages.append(message)
if not message.tool_calls:
return message.content
for call in message.tool_calls:
fn = dispatch[call.function.name]
args = json.loads(call.function.arguments)
result = fn(**args)
messages.append(
{
"role": "tool",
"tool_call_id": call.id,
"content": result,
}
)
Этот пример намеренно минимален. В продакшене стоит также добавить:
- политику повторов для временных ошибок
- тайм-ауты и лимиты бюджета
- согласование с человеком для чувствительных действий
- структурированные журналы шагов
- оценщик уровня задачи перед финальным завершением
Какую модель выбрать в качестве планировщика?
Для агентного воркфлоу модели-планировщику нужен не только высокий интеллект. Ей нужна правильная форма:
- надёжный вызов инструментов
- стабильное поведение на длинном контексте
- хорошее следование инструкциям
- предсказуемая задержка на многошаговой глубине
Если вам нужна стартовая точка с открытыми весами на Novita, Qwen3 Coder 30B A3B Instruct — практичный вариант для планирования воркфлоу и работы с инструментами для кода. На текущей странице моделей Novita указаны OpenAI-совместимый доступ, поддержка вызова функций, поддержка структурированного вывода и размещённое контекстное окно 160K. Для многих задач внутренней автоматизации и написания кода этого достаточно, чтобы создать серьёзную первую версию, прежде чем переходить на более крупного или более специализированного планировщика.
Правильная модель по-прежнему зависит от задачи. Для широких воркфлоу с большим количеством рассуждений в первую очередь выбирайте качество планирования. Для автоматизации с высоким объёмом задержка и стоимость могут значить не меньше, чем сила бенчмарков.
Частые сценарии отказов в агентных воркфлоу
Большинство отказов не драматичны. Они повторяются и обходятся дорого.
Чрезмерное использование инструментов
Если каждая возможность становится собственной удалённой зависимостью, воркфлоу тратит больше времени на координацию, чем на полезную работу.
Слабые правила остановки
Если система никогда не знает, когда «готово» истинно, она продолжает генерировать ещё один шаг.
Плохая обработка ошибок
Если инструменты возвращают расплывчатые сообщения вроде «failed» вместо полезного результата, модель не может восстановиться.
Отсутствие границы песочницы
Воркфлоу может работать в разработке, но становится небезопасным, как только касается реальных файлов, учётных данных или внешних систем.
Отсутствие оценщика
Агент выглядит занятым, но никогда не доказывает, что задача выполнена корректно.
Когда не стоит использовать агентный воркфлоу?
Не создавайте его только потому, что термин популярен.
Вероятно, вам не нужен агентный воркфлоу, если:
- задача — это разовая генерация
- путь фиксирован и редко меняется
- традиционная программа может дёшево решить каждый шаг
- нет необходимости в использовании инструментов или выполнении
Например, если ваше приложение всегда принимает данные формы, вызывает один промпт и возвращает отформатированное письмо, обычный LLM-воркфлоу проще и лучше.
Агентные воркфлоу окупаются, когда среда может преподнести системе сюрприз, а система при этом должна продолжать работать.
Если вам нужна стартовая точка с моделью длинного контекста, сравните Macaron V1 Tall Quick Start на Novita AI и Qwen3.8-Max на Novita AI.
Часто задаваемые вопросы
Одинаковы ли агентный воркфлоу и вызов функций?
Нет. Вызов функций — это один из механизмов внутри воркфлоу. Полноценный воркфлоу также требует потока управления, состояния, выполнения и оценки.
Нужно ли несколько агентов для создания агентных воркфлоу?
Нет. Большинству команд стоит начать с одного цикла контроллера и нескольких инструментов. Мультиагентные архитектуры полезны позже, но это не стартовая точка по умолчанию.
Какой самый важный контроль безопасности?
Для воркфлоу, которые запускают код или взаимодействуют с внешними системами, самый важный контроль — это изолированная среда выполнения в сочетании с узкими правами инструментов.
Какой самый простой продакшн-стек?
Хороший первый стек: OpenAI-совместимый LLM API, небольшой реестр инструментов, песочница как среда выполнения и оценщик, который может определить, когда задача действительно выполнена.
