Что такое агентный рабочий процесс? Как создать такой, который планирует, действует и оценивает

Агентный рабочий процесс — это многошаговая система, в которой языковая модель делает больше, чем просто однократный ответ: она планирует, выбирает инструменты, выполняет действия, проверяет результат и решает, что делать дальше, пока задача не будет завершена. На практике это означает объединение уровня рассуждений LLM с вызовом инструментов, реальной средой выполнения и циклом оценки. Если вы создаете агентов для кодирования, исследовательских агентов или внутреннюю автоматизацию, которая должна адаптироваться в процессе выполнения задачи, это обычно та архитектура, которую вы на самом деле строите.

Что такое агентный рабочий процесс?

Агентный рабочий процесс — это паттерн, лежащий в основе AI-систем, которые могут продвигаться по задаче, а не останавливаться на генерации текста. Вместо того чтобы запрашивать у модели один ответ и возвращать его пользователю, вы позволяете модели работать внутри контролируемого цикла:

1. Прочитать цель и текущее состояние.
2. Спланировать следующий шаг.
3. Вызвать инструмент или выполнить код.
4. Наблюдать результат.
5. Оценить, завершена ли задача.
6. Повторить при необходимости.

Это отличается от фиксированного рабочего процесса, где каждый шаг заранее прописан в коде. В фиксированном рабочем процессе вы определяете путь заранее. В агентном рабочем процессе модель решает, какое действие выполнить следующим, в рамках заданных вами границ.

Это различие важно, потому что многие реальные задачи разработчика не являются линейными. Агенту для кодирования может потребоваться просмотреть файлы, прежде чем он узнает, какой тест запускать. Исследовательскому агенту может потребоваться выполнить поиск дважды, потому что первый источник был неполным. Браузерному агенту может потребоваться восстановиться после сбоя входа в систему или изменившегося макета страницы. Это проблемы рабочего процесса, но они требуют адаптации.

Чем агентный рабочий процесс отличается от AI-агента?

Люди часто используют эти два термина как взаимозаменяемые, но полезнее их разделять:

• Агентный рабочий процесс — это паттерн выполнения.
• AI-агент — это продукт или система, построенная на основе этого паттерна.

У вас может быть узконаправленный агентный рабочий процесс, который только сортирует тикеты поддержки, или более широкий AI-агент, координирующий планирование, использование инструментов, память и контрольные точки утверждения для множества задач.

Если вам нужно практическое правило, используйте рабочий процесс, когда говорите об архитектуре и потоке управления, и агент, когда говорите о пользовательской системе.

Каковы основные части агентного рабочего процесса?

Большинство production-систем в итоге содержат одни и те же пять частей.

1. Планировщик

Планировщик превращает общую инструкцию в следующее конкретное действие. Иногда это явный шаг планирования, который выводит список задач. Иногда это неявно и происходит внутри каждого шага вызова инструмента. В любом случае модели нужно достаточно контекста, чтобы решить, следует ли ей читать, писать, искать, выполнять или остановиться.

Хорошее планирование не означает генерацию длинного плана для каждого запроса. Это означает сохранение следующего шага понятным. Для коротких задач достаточно одношагового планирования. Для более длинных задач, таких как рефакторинг репозитория, автоматизация браузера или проверка документов, явный план уменьшает хаотичность.

2. Уровень инструментов

Инструменты — это интерфейс рабочего процесса с внешним миром. Хороший уровень инструментов обычно узок и предсказуем. Например:

• read_file(path)
• write_file(path, content)
• search_files(query)
• run_command(cmd)
• fetch_url(url)

Маленькие инструменты легче вызывать модели правильно, легче логировать и легче защищать. Большие инструменты «делают всё» сначала кажутся удобными, но становятся трудными для отладки, потому что вы не можете определить, связаны ли сбои с решением модели, реализацией инструмента или внешней системой за ним.

3. Среда выполнения

Как только модель решает действовать, кто-то должен выполнить это действие. Для любого рабочего процесса, который записывает файлы, устанавливает пакеты, запускает код или открывает сессии браузера, эта среда выполнения нуждается в изоляции.

Здесь на помощь приходит песочница. Novita Agent Sandbox разработан для этого уровня выполнения: отдельная среда, в которой действия агента могут выполняться без прямого воздействия на хост-систему. Это разница между «модель предложила команду» и «рабочий процесс безопасно выполнил эту команду».

4. Состояние и память

Агентному рабочему процессу нужна рабочая память между шагами. Обычно это включает:

• состояние диалога
• результаты работы инструментов
• промежуточные файлы
• журналы выполнения
• черновик или краткий план

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

5. Цикл оценки

Это часть, которую многие команды добавляют слишком поздно. Рабочему процессу нужен способ оценить, успешен ли шаг и завершена ли задача. В рабочем процессе кодирования это может означать прохождение тестов. В исследовательском рабочем процессе это может означать, что ответ ссылается на достаточное количество надежных источников. В браузерном рабочем процессе это может означать, что ожидаемое состояние UI видимо.

Без оценки «агентный» часто превращается в «продолжает вызывать инструменты до тайм-аута».

Почему планирование важно при создании агентных рабочих процессов

Самая большая ошибка при создании агентных рабочих процессов — это предположение, что модель должна импровизировать всё с нуля на каждом шаге.

Обычно это создает три проблемы:

• модель многократно обращается к одним и тем же файлам или URL
• использование инструментов становится шумным и дорогим
• рабочий процесс теряет четкое условие остановки

Лучший паттерн — это легковесное планирование в сочетании с обоснованным выполнением. Позвольте модели решать следующее действие, но делайте это на основе явной задачи, видимого текущего состояния и небольшого набора разрешенных инструментов. Это сохраняет гибкость там, где она полезна, и убирает её там, где нет.

В рабочих процессах кодирования планирование часто выглядит так:

1. Определить задействованные файлы.
2. Прочитать текущую реализацию.
3. Определить минимальное изменение.
4. Внести правку.
5. Запустить проверку.
6. Либо остановиться, либо исправить.

Это всё ещё агентный подход, потому что модель может ответвляться, когда репозиторий преподносит сюрпризы. Но это не блуждание.

Как должно работать использование инструментов в агентном рабочем процессе?

Использование инструментов должно быть явным, типизированным и наблюдаемым.

Если ваша модель поддерживает вызов функций, используйте его. Novita LLM API предоставляет конечную точку, совместимую с OpenAI, и документирует вызов функций напрямую, что является самым чистым способом позволить модели выбирать между инструментами, не полагаясь на хрупкий разбор строк.

Несколько правил делают использование инструментов гораздо более надежным:

• Давайте инструментам конкретные имена.
• Используйте схемы с обязательными полями.
• Возвращайте полные результаты, включая ошибки.
• Логируйте каждый вызов, аргумент и результат.
• Делайте деструктивные действия редкими и легко блокируемыми.

Уровень инструментов также должен отражать реальные границы. Например, не давайте агенту кодирования один мега-инструмент под названием edit_repo_and_run_tests. Разделите шаги чтения, записи и выполнения, чтобы модель могла восстановиться, когда что-то пойдет не так.

Почему выполнение кода требует песочницы?

Агентный рабочий процесс, который никогда ничего не выполняет, часто может оставаться внутри обычного сервера приложений. Как только он начинает запускать shell-команды, устанавливать зависимости, обрабатывать загруженные файлы или просматривать открытый веб, вам нужна изоляция.

Песочница решает две разные проблемы:

• Безопасность: сгенерированный код и результаты работы инструментов могут быть ошибочными, враждебными или просто непредсказуемыми.
• Сохранение состояния: многошаговым задачам требуется постоянное рабочее пространство, где файлы, пакеты и журналы выполнения сохраняются между шагами.

Для многих команд второй пункт так же важен, как и первый. Рабочий процесс, который редактирует код, запускает тесты, исправляет ошибку и повторно запускает проверку, невозможен, если каждый шаг начинается с чистой машины.

Вот почему практическая архитектура обычно такова:

• LLM API для планирования и выбора инструментов
• Среда выполнения в песочнице для выполнения и сохранения состояния

Novita естественным образом вписывается в это разделение: LLM API выступает в роли планировщика и уровня вызова инструментов, а Agent Sandbox обрабатывает фактическую среду выполнения.

Как оценивать агентный рабочий процесс?

Оценка должна происходить на двух уровнях.

Оценка на уровне шага

Сработало ли последнее действие?

Примеры:

• Команда завершилась успешно?
• API вернул валидный JSON?
• Ожидаемый файл был создан?
• Страница браузера содержала целевой элемент?

Оценка на уровне задачи

Решил ли рабочий процесс проблему пользователя?

Примеры:

• Проходят ли тесты после изменения кода?
• Отвечает ли сводка на исследовательский вопрос с доказательствами?
• Завершила ли автоматизация транзакцию без ручной очистки?

Сильные рабочие процессы используют оба подхода. Если вы оцениваете только конечный результат, вы пропускаете очевидные сигналы сбоя во время выполнения. Если вы оцениваете только шаги, рабочий процесс может выполнить длинную серию локально корректных действий и всё равно провалить реальную задачу.

Практическая архитектура для создания агентных рабочих процессов

Вот архитектура, с которой большинству команд следует начинать:

1. Запрос пользователя поступает в ваше приложение.
2. Ваш контроллер отправляет цель, состояние и доступные инструменты в LLM.
3. LLM возвращает либо прямой ответ, либо вызов инструмента.
4. Ваш контроллер выполняет инструмент внутри песочницы или другой контролируемой среды.
5. Результат работы инструмента добавляется к состоянию диалога.
6. Оценщик проверяет завершение, сбой или контрольные точки утверждения.
7. Цикл продолжается, пока рабочий процесс не будет завершен или заблокирован.

Этот цикл контроллера может быть простым. Во многих случаях достаточно одного процесса-оркестратора. Вам не нужна мультиагентная система с первого дня. Начните с одного планировщика, нескольких хорошо определенных инструментов, одной среды выполнения в песочнице и четкого оценщика.

Пример: контроллер агентного рабочего процесса на 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,
                }
            )

Это намеренно минималистично. В production вы также добавите:

• политику повторных попыток для временных ошибок
• тайм-ауты и лимиты бюджета
• одобрение человека для чувствительных действий
• структурированные журналы шагов
• оценщик на уровне задачи перед окончательным завершением

Какую модель использовать в качестве планировщика?

Для агентного рабочего процесса модель-планировщик должна обладать не просто сырым интеллектом. Ей нужна правильная форма:

• надежный вызов инструментов
• стабильное поведение при работе с длинным контекстом
• сильное следование инструкциям
• предсказуемая задержка на многошаговой глубине

Если вы хотите начать с открытой весовой модели на Novita, Qwen3 Coder 30B A3B Instruct — практичный вариант для планирования рабочего процесса и использования инструментов, ориентированных на кодирование. Текущая страница моделей Novita перечисляет доступ, совместимый с OpenAI, поддержку вызова функций, поддержку структурированного вывода и хостинг контекстного окна на 160K. Для многих задач внутренней автоматизации и кодирования этого достаточно, чтобы создать серьезную первую версию, прежде чем переходить к более крупному или более специализированному планировщику.

Правильная модель всё ещё зависит от задачи. Для широких рабочих процессов, требующих рассуждений, в первую очередь выбирайте качество планирования. Для высокообъемной автоматизации задержка и стоимость могут быть так же важны, как и бенчмарки.

Типичные режимы сбоя в агентных рабочих процессах

Большинство сбоев не являются драматическими. Они повторяются и дорого обходятся.

Чрезмерное использование инструментов

Если каждая возможность становится собственной удаленной зависимостью, рабочий процесс тратит больше времени на координацию, чем на полезную работу.

Слабые правила остановки

Если система никогда не знает, когда «готово» истинно, она продолжает генерировать еще один шаг.

Плохая обработка ошибок

Если инструменты возвращают расплывчатые сообщения, такие как «failed», вместо действенного вывода, модель не может восстановиться.

Отсутствие границы песочницы

Рабочий процесс может работать в разработке, но становится небезопасным, как только касается реальных файлов, учетных данных или внешних систем.

Отсутствие оценщика

Агент выглядит занятым, но никогда не доказывает, что задача была выполнена правильно.

Когда не следует использовать агентный рабочий процесс?

Не создавайте его только потому, что термин популярен.

Вам, вероятно, не нужен агентный рабочий процесс, если:

• задача — это одноразовая генерация
• путь фиксирован и редко меняется
• традиционная программа может дешево принимать каждое решение
• нет необходимости в использовании инструментов или выполнении

Например, если ваше приложение всегда принимает ввод формы, вызывает один промпт и возвращает отформатированное письмо, обычный LLM-воркфлоу проще и лучше.

Агентные рабочие процессы окупаются, когда среда может преподнести системе сюрпризы, и системе всё равно нужно продолжать работу.

Часто задаваемые вопросы

Агентный рабочий процесс — это то же самое, что вызов функций?

Нет. Вызов функций — это один из механизмов внутри рабочего процесса. Полный рабочий процесс также требует потока управления, состояния, выполнения и оценки.

Нужно ли мне несколько агентов для создания агентных рабочих процессов?

Нет. Большинству команд следует начинать с одного цикла контроллера и нескольких инструментов. Мультиагентные конструкции полезны позже, но они не являются отправной точкой по умолчанию.

Какой самый важный контроль безопасности?

Для рабочих процессов, которые запускают код или взаимодействуют с внешними системами, самым важным контролем является изолированная среда выполнения в сочетании с узкими разрешениями инструментов.

Какой самый простой production-ready стек?

Хороший первый стек: совместимый с OpenAI LLM API, небольшой реестр инструментов, среда выполнения в песочнице и оценщик, который может решить, когда задача действительно выполнена.

Рекомендуемые статьи

• Что такое агенты для кодирования? Как они работают и как создать такого
• Что такое AI-песочница для агентов?
• Агент vs Рабочий процесс: ключевые различия и практические компромиссы