TNWS AI

Гайд · TNWS AI

Как собрать менеджера и подагента в smolagents через managed_agents

smolagentsPythonQwen#smolagents#Hugging Face#нейросети
4 мин—

Минимальная иерархия smolagents: именованный подагент, description, managed_agents, точная задача, проверка делегирования и ошибки доступа.

Задача и применимость

Актуальный поисковый запрос: «как создать многоагентную систему smolagents managed_agents». Делегировать менеджеру одну специализированную читающую задачу, не копируя все инструменты в главный агент. Официальная документация требует для управляемого агента name и description, а менеджер получает его в списке managed_agents. Это архитектурное разделение, но не автоматическая граница безопасности: полномочия дочернего tool определяет ваш код. Материал сверён 26 сентября 2026 года с официальной документацией Hugging Face smolagents. Документация прямо помечает API экспериментальным, поэтому перед производственным использованием закрепите версию пакета и повторите тесты. Примеры рассчитаны на Python 3.10+; доступ к конкретной модели и провайдеру проверяется в вашем аккаунте, а не предполагается этой инструкцией.

Пошаговая настройка

  1. Создайте узкий tool и дочерний ToolCallingAgent только для чтения.
  2. Задайте дочернему агенту уникальные name и description, понятные менеджеру.
  3. Создайте менеджера с пустым списком обычных tools и managed_agents=[child].
  4. Запустите один эталон и по памяти проверьте, что менеджер делегировал именно дочернему агенту.

До сетевого запуска установите smolagents, настройте HF_TOKEN или другой документированный способ аутентификации и вынесите идентификатор модели в HF_MODEL_ID. Не вставляйте действующий токен в код, prompt, скриншот или статью. Сначала выполните детерминированную часть примера без модели, затем интеграционный run. Так ошибка схемы или бизнес-логики не смешивается с изменчивым поведением LLM.

Готовый шаблон

import os
from smolagents import InferenceClientModel, ToolCallingAgent, tool

@tool
def read_status(code: str) -> str:
    """Читает учебный статус.

    Args:
        code: Код записи.
    """
    return {"R-7": "готово"}.get(code, "не найдено")

model = InferenceClientModel(model_id=os.environ.get("HF_MODEL_ID", "Qwen/Qwen3-Next-80B-A3B-Thinking"), token=os.getenv("HF_TOKEN"))
status_agent = ToolCallingAgent(tools=[read_status], model=model, max_steps=3,
    name="status_reader", description="Читает статус учебной записи по точному коду.")
manager = ToolCallingAgent(tools=[], model=model, managed_agents=[status_agent], max_steps=4)
print(manager.run("Узнай статус R-7 через специалиста."))

Конкретный вход и ожидаемые данные

Вход менеджера — «Узнай статус R-7 через специалиста». Ожидаемый фактический путь: вызов status_reader, внутри него read_status(code="R-7"), затем ответ «готово». Если менеджер отвечает «готово» без делегирования, совпадение не принимается: модель могла угадать. Для R-8 дочерний агент должен вернуть отсутствие записи, а не заменить код.

Почему схема работает

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

Фактическая проверка и пограничный случай

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

Протокол воспроизводимости

Для каждого прогона запишите четыре независимых артефакта: точный обезличенный вход, ожидаемое действие, фактическое действие и предметно правильный результат. Не ограничивайтесь снимком финального ответа: он не показывает, был ли вызван нужный инструмент. Повторите опыт не менее трёх раз на одной модели с одинаковыми настройками, затем отдельно после смены версии. В отчёте различайте ошибку маршрутизации, неверный аргумент, сбой Python-кода и неподтверждённую генерацию. Если результат нестабилен, не выбирайте удачный прогон вручную: укажите долю успеха на фиксированном наборе. Настройки температуры и провайдера фиксируйте только если они действительно переданы вашему model-клиенту. Такой протокол позволяет повторить вывод и не превращает единичный удачный ответ в обещание качества.

Синтаксис Python проверяется до публикации через ast.parse. Выполнение с реальной моделью здесь не заявляется: без учётных данных нельзя честно подтвердить доступность конкретного inference provider и поведение модели. Проверяемая часть примера выполняется локально там, где она не требует LLM. Для сетевой части заранее запишите модель, версию smolagents, вход, ожидаемый tool call и предметный эталон, затем сохраните обезличенную трассу.

Критерии приёмки

  1. У дочернего агента есть непустые уникальные name и description.
  2. Трасса показывает делегирование и точный аргумент R-7.
  3. Менеджер не получает прямой инструмент записи или лишние полномочия.

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

Типичные ошибки и чего не делать

  • Не создавайте двух managed agents с одинаковым именем.
  • Не давайте дочернему агенту инструменты, которые не нужны его роли.
  • Не считайте словесное описание роли механизмом авторизации.

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

FAQ

Что обязательно для подагента?

В текущей справке name и description обязательны, когда агент вызывается менеджером.

Как менеджер получает подагента?

Через список managed_agents при инициализации.

Нужен ли CodeAgent менеджеру?

Нет универсального требования; выбирайте по действиям и проверяйте сценарий.

Официальные источники

Частые вопросы

Что обязательно для подагента?

В текущей справке name и description обязательны, когда агент вызывается менеджером.

Как менеджер получает подагента?

Через список `managed_agents` при инициализации.

Нужен ли CodeAgent менеджеру?

Нет универсального требования; выбирайте по действиям и проверяйте сценарий.

Читайте также

ГайдыsmolagentsPython26 сентября 2026

Как ограничить число шагов агента smolagents через max_steps

Настройка max_steps в smolagents на читающем инструменте: что именно ограничивается, тест успешного запроса, исчерпание бюджета и критерии.

4 мин 
ГайдыsmolagentsPython26 сентября 2026

Как проверить финальный ответ smolagents через final_answer_checks

Финальная проверка ответа smolagents на обязательную ссылку на код: сигнатура callback, точный пример, пределы булевой проверки и ошибки.

4 мин 
ГайдыsmolagentsPython26 сентября 2026

Как разобрать ошибку агента smolagents через replay и память

Диагностика smolagents через replay, memory.steps и get_full_steps: что смотреть, как обезличить данные и почему трасса не доказывает качество.

4 мин 

Подбор

Какую нейросеть выбрать

Пройти опрос

Комментарии

Пока тихо. Скажите первое слово