Агент LangChain на Python: создание и tools

LangChain предоставляет готовый цикл агента: модель выбирает инструмент, framework выполняет его и добавляет результат в состояние. В актуальной ветке LangChain 1.x базовая точка входа — create_agent.

Минимальный агент

from langchain.agents import create_agent
from langchain.tools import tool

@tool
def get_order_status(order_id: str) -> str:
    """Возвращает статус заказа по его идентификатору."""
    demo = {"A-101": "передан в доставку"}
    return demo.get(order_id, "заказ не найден")

agent = create_agent(
    model="openai:gpt-5-mini",
    tools=[get_order_status],
    system_prompt=(
        "Ты помощник магазина. Не выдумывай статус заказа: "
        "используй get_order_status."
    ),
)

result = agent.invoke({
    "messages": [
        {"role": "user", "content": "Где заказ A-101?"}
    ]
})

Конкретные идентификаторы моделей и параметры интеграций меняются, поэтому перед запуском сверяйте документацию установленной версии.

Что делает create_agent

Функция собирает граф выполнения поверх LangGraph. Состояние содержит историю сообщений. Модель получает описания tools и может вернуть обычный ответ либо tool call. После tool call framework вызывает Python-функцию, добавляет ToolMessage и снова обращается к модели.

Декоратор @tool использует имя функции, type hints и docstring для схемы инструмента. Не пишите расплывчатое описание: модель должна отличать этот инструмент от соседних. Аргументы всё равно проверяются кодом — схема помогает модели, но не является системой авторизации.

Результат invoke — состояние, а не только строка. Финальный текст обычно находится в последнем сообщении, но в продакшене полезно сохранять и промежуточные tool calls для трассировки.

Если задача требует ветвлений, ручных checkpoint или human-in-the-loop, переходите к явному графу LangGraph. Для простого tool-calling агента create_agent уменьшает количество служебного кода.

Продакшен-ограничения

Framework не отменяет правила безопасности. Передавайте агенту только нужные tools. Проверяйте права пользователя внутри функции, а не в system prompt. На сетевые вызовы ставьте timeout; операции с побочным эффектом делайте идемпотентными и запрашивайте подтверждение.

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

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

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