Как ограничить число вызовов модели в LangChain-агенте

1. Определите ожидаемое число шагов агента на положительном и ошибочном пути.
2. Подключите ModelCallLimitMiddleware с небольшим run_limit, а для thread_limit — checkpointer.
3. Прогоните короткую задачу, которая завершится до границы.
4. Смоделируйте повторяющиеся неуспешные вызовы read-only tool и проверьте поведение end или error.
5. Добавьте мониторинг счётчика фактических model calls и причину раннего завершения.

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

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

from langchain.agents import create_agent
from langchain.agents.middleware import ModelCallLimitMiddleware
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(model="openai:gpt-5.5", tools=[],
    checkpointer=InMemorySaver(), middleware=[
        ModelCallLimitMiddleware(
            run_limit=3, thread_limit=8, exit_behavior="end")])
config = {"configurable": {"thread_id": "limit-demo-1"}}
result = agent.invoke({"messages": [{"role": "user", "content":
    "Объясни, зачем нужен RAG, в одном предложении."}]}, config=config)
print(result["messages"][-1].content)

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

Вход: простой вопрос про RAG обычно может закончиться одним вызовом; тестовый agent с повторяющимся read-only tool способен превысить run_limit=3. Ожидается, что число вызовов не выйдет за заданную границу, а приложение отличит лимит от обычного полезного ответа. Конкретный текст после exit_behavior=end зависит от исполнения, поэтому тестируйте факт завершения и статус, не придумывая ответ.

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

Диагностика и границы решения

Контроль циклов важен для агентов с инструментами: модель может повторять один и тот же поиск, если результат пустой или неоднозначный. Лимит вызовов делает такое поведение конечным, но не объясняет его причину. Снимайте трассы: какой инструмент возвращал ошибку, какие аргументы повторялись и на каком вызове прервался run. Если вы поставили run_limit=1 для задачи, которая закономерно делает tool call и затем второй модельный ответ, получится ложный отказ даже при здоровом поведении. Поэтому сначала измерьте нормативный путь и оставьте осмысленный запас. thread_limit позволяет ограничивать накопление вызовов в одном разговоре; для него нужен устойчивый checkpointer. При выборе exit_behavior=end лучше явно показать пользователю, что задача не закончена, а не превращать техническое завершение в уверенный результат. При error обрабатывайте исключение на уровне API и не допускайте бесконечного внешнего retry. Контроль расходов требует ещё и лимитов токенов, квот провайдера, времени исполнения и числа вызовов инструментов: только модельный счётчик не ограничивает всё.

Контрольный эксперимент

Проверьте три независимые метрики на контрольном наборе: долю успешно завершённых задач, число model calls и полноту полезного ответа. Слишком низкий лимит уменьшит вызовы, но создаст больше бесполезных остановок; слишком высокий не остановит runaway на практике. Поставьте тест, где инструмент два раза возвращает одно и то же «ничего не найдено», и наблюдайте, предложит ли агент альтернативный путь или будет повторять вопрос. Сам инструмент должен быть read-only и дешёвым, чтобы тест не вызвал реальной массовой операции. Для thread_limit выполните несколько отдельных invoke с одним ID и отдельный вызов с другим ID, чтобы проверить границу и изоляцию. При перезапуске InMemorySaver счётчик может не сохраняться: для production используйте постоянный saver и внешнюю политику расхода.

Дополнительный проверочный сценарий

Принцип «максимум три вызова» должен вытекать из конкретного сценария. Для агента, который делает один поиск и одну проверку статуса, могут понадобиться промежуточные модельные вызовы; измерьте их на реальной выборке прежде, чем ставить порог. Добавьте алерт, если значительная доля запросов упирается в run_limit: это признак деградации источника или неудачного маршрута, а не только защита расходов. Не настраивайте внешний cron на бесконечный перезапуск ошибочного run: он обойдёт смысл лимита. При достижении границы предложите пользователю узкое действие — уточнить вопрос или посмотреть найденные документы, — но не сочиняйте полный ответ. Учёт затрат отдельно учитывает длинные prompts и tool usage.