Собираем LLM-агента на Python
- LangChain 1.0 вводит компонуемую архитектуру middleware вместо сложных pre/post-хуков, с которыми часто сталкивались в LangChain v0.
x. - Каждый middleware — изолированный компонент, который решает одну задачу, тестируется независимо и комбинируется через стандартный интерфейс.
- Выделены четыре категории middleware: Monitor, Modify, Control и Enforce.
- Разобраны пять компонентов: SummarizationMiddleware, PIIMiddleware, HumanInTheLoopMiddleware, TodoListMiddleware и LLMToolSelectorMiddleware.
- В демонстрации суммирования порог — 400 токенов и сохранение последних 5 сообщений; отдельно отмечено, что в продакшене обычно используют 4000 токенов и 20 сообщений.
- В примере диалога показано снижение входных токенов до 184 вместо оценочных 705 (−74%) после включения суммирования по порогу.
Почему это важно: Паттерн middleware переносит ключевые «обвязочные» функции агента в отдельные, проверяемые блоки и снижает связанность кода. Это упрощает сочетание подходов вроде суммирования истории, обработки чувствительных данных и контроля критичных действий в одном сценарии. В тексте это сопоставляется с веб-middleware подходам и практикам и подчёркивает переиспользуемость компонентов.
На что обратить внимание: В примерах значения порогов и настроек намеренно занижены для демонстрации, поэтому перенос в продакшен подразумевает подбор параметров под реальные диалоги и модели. Отдельно показано, что фильтрация чувствительных данных применяется до обработки сообщения моделью, а чувствительные действия могут требовать паузы и продолжения из сохранённого состояния. Как следующий шаг для более сложных сценариев в материале упоминается LangGraph для координации и работы с общим состоянием.
Коротко
- В материале агент собирается из независимых «прослоек», каждая закрывает одну функцию; это обычно облегчает замену частей без переписывания всего решения.
- Практический вопрос из таких примеров: как измеряется рост контекста и что считать приемлемой ценой/задержкой, когда диалог становится длинным.
- Отдельный слой безопасности в агенте поднимает тему границ: какие данные могут попадать в логи и какое «редактирование» считается достаточным в домене.
- Для чувствительных действий показан сценарий с остановкой потока; в реальной эксплуатации важно понимать, где хранится состояние и как возобновляется цепочка шагов.
- При большом наборе инструментов описан предварительный отбор; на практике это часто влияет на точность ответов и требует прозрачности, почему выбран этот инструмент.
FAQ
Зачем в LangChain 1.0 выделять middleware для LLM-агентов, и как это связано с тестируемостью, безопасностью и управлением стоимостью вызовов?
Материал показывает, что middleware берут на себя отдельные задачи (контекст, защита PII, контроль чувствительных действий), а значит агент проще масштабировать и тестировать. Также демонстрируются подходы к снижению расхода токенов и управлению набором инструментов.
Какие категории middleware описаны в материале и чем они отличаются по роли в выполнении агента: Monitor, Modify, Control и Enforce, и что каждая из них делает?
Monitor отвечает за наблюдение (логирование, аналитика, отладка), Modify — за преобразование промптов и выбор инструментов, Control — за поведение выполнения (повторы, запасные варианты, досрочное завершение), Enforce — за лимиты и защитные ограничения, включая обнаружение PII.
Как в примере устроено суммирование истории диалога и что именно остаётся несжатым, когда превышается заданный порог токенов?
SummarizationMiddleware отслеживает общий объём токенов и при превышении порога сжимает более старые сообщения, сохраняя последние N реплик полностью. В примере целиком остаются последние 5 сообщений.
Как PIIMiddleware и HumanInTheLoopMiddleware работают в примерах: где происходит редактирование PII и на каком этапе агент ставится на паузу перед действием?
PIIMiddleware применяется к входным сообщениям до обработки моделью и заменяет найденные email, телефоны и ID на безопасные маркеры или маску. HumanInTheLoopMiddleware прерывает выполнение перед вызовом чувствительного инструмента (например, process_refund) и продолжает после одобрения, сохраняя состояние через чекпойнтер.
Читайте также
- LangChain 1.0: middleware вместо pre/post-хуков для продакшен-агентов: В LangChain 1.0 предлагается компонуемая архитектура middleware, которая упрощает масштабирование и тестирование агента по сравнению с подходом pre/post-хуков в v0.x. Каждый middleware решает одну задачу, тестируется отдельно и комбинируется со стандартным интерфейсом.
[Инструменты и архитектура]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Команда Python for Devs перевела материал о том, как в LangChain 1.0 собирать продакшен-LLM-агентов через middleware. Главный вывод: отдельные прослойки для контекста, безопасности и контроля делают поведение агента более управляемым.