Transcription
Если вы занимались разработкой с использованием Langchain или Langraph, забудьте все, что вы знаете. Pyantic AI только что изменил правила игры. Никаких графов, никакой сложной оркестровки, только функции Python, которые на самом деле имеют смысл. В ближайшие 15 минут я покажу вам, почему Pantic AI — это фреймворк, используемый для создания производственных агентских систем в масштабе. Это другое. Поехали.
Pantic AI — это не просто еще одна обертка вокруг OpenAI. Это полное переосмысление того, как должны работать агенты. В то время как Langchain предоставляет вам цепочки, а Langraph заставляет вас использовать графы, pedantic AI дает вам нечто радикальное — просто Python.
Ключевая идея заключается в следующем. Агенты — это функции. Они принимают входные данные. Они могут вызывать инструменты и возвращать структурированные выходные данные. Вот и все. Никаких DSL, никаких визуальных конструкторов, никаких конфигураций YML.
Четыре вещи отличают Pyantic AI. Агенты — это функции, а не графы. Выходные данные — это типобезопасные модели Pydantic. Цикл выполнения управляется за вас. И вы пишете в 10 раз меньше кода, чем в Langchain.
Все начинается с конструктора агента. Это не просто синтаксический сахар. Это создание состояния среды выполнения, которая управляет циклом диалога за вас. Одна строка кода обеспечивает управление историей сообщений, автоматические повторные попытки, парсинг структурированных выходных данных, оркестровку вызовов инструментов и типобезопасность. В Langchain это заняло бы 50 строк кода. Вы передаете строку модели и параметр инструкций, и все. Агент готов к работе.
Вот ментальная модель, которая все расставит по местам. Каждый запуск агента — это цикл. Шаг первый: возьмите сообщение пользователя и историю диалога. Шаг второй: отправьте все в LLM с вашим системным промптом. Шаг третий: LLM отвечает либо обычным текстом, либо вызовами инструментов. Шаг четвертый: если есть вызовы инструментов, выполните их, добавьте результаты в историю и вернитесь к шагу второму. Шаг пятый: если это обычный текст, проверьте его на соответствие вашему типу вывода и верните результат. Pedantic AI управляет всем этим циклом. Вы никогда не пишете его сами. Это вся ментальная модель.
Вот где начинается красота. Ваши агенты возвращают реальные объекты Python, а не строки. Вы определяете модель Pydantic, скажем, `CityInfo` с полями `name`, `country`, `population` и `founded_year`. Вы передаете `output_type=CityInfo` вашему агенту. Затем, когда вы вызываете `run_sync`, вы получаете реальный объект `CityInfo`. `result.output.population` — это реальное целое число. `result.output.name` — это реальная строка. Больше никакого парсинга JSON. Больше никаких `try-except` вокруг `json.loads`. Больше никакого упования на то, что LLM вернула действительный JSON. Pyantic AI позаботится обо всем этом за вас.
Каждый запуск агента возвращает объект `AgentRunResult`, который содержит все, что вам нужно. `result.output` предоставляет типизированное значение ответа. `result.usage` предоставляет количество токенов: запрошенные токены, токены ответа, общие токены. `result.all_messages` предоставляет полную историю диалога, готовую для передачи в следующий запуск. `result.new_messages` предоставляет только сообщения этого запуска для построения продолжений.
Это встроенная наблюдаемость. В продакшене вы можете регистрировать использование на запрос, отслеживать диалоги от начала до конца и отлаживать сбои, проверяя полную историю сообщений. Никакой внешней настройки трассировки не требуется.
Давайте построим что-нибудь реальное: агент для исследования бизнеса, который возвращает типизированные данные. Мы определяем модель `CityResearch` с полями `name`, `country`, `population`, `key_industries` (список) и `business_score` от 1 до 10. Мы создаем агента с `output_type=CityResearch` и системным промптом, который говорит ему действовать как аналитик бизнес-исследований. Затем мы вызываем `run_sync` с запросом вроде "исследуй Леон, Франция, для расширения рынка", и получаем `business_score=7.8`, `industries=['manufacturing', 'biotech', 'logistics']`, `population=516000` и количество токенов для отслеживания затрат. Типизированные, проверенные, готовые к продакшену данные менее чем за 30 строк Python.
Что происходит, когда LLM возвращает недействительные данные? В большинстве фреймворков вы получите загадочную ошибку парсинга JSON и сломанный пайплайн. В Pyantic AI вы устанавливаете `retries=3`, и фреймворк обрабатывает это автоматически. Вот что происходит. LLM возвращает выходные данные. Pyantic проверяет их на соответствие вашей схеме. Если проверка не удалась, ошибки проверки отправляются обратно в LLM в качестве контекста. LLM понимает, что допустила ошибку, исправляет выходные данные и повторяет попытку. Это повторяется до трех раз. Если все повторные попытки не удались, вы получаете чистое исключение `ValidationError`, которое можно перехватить и обработать. Ноль скрытых сбоев, ноль сломанных пайплайнов.
Позвольте мне представить это в перспективе. В Langchain вы строите цикл самостоятельно. 300-500 строк кода оркестровки. Сложные определения цепочек, пользовательские колбэки, многословная конфигурация. В Langraph вы определяете граф с узлами и ребрами. Лучше, чем Langchain, но вы все равно думаете в терминах графов, а не функций. В Pydantic AI вы пишете функцию. 50 строк, типизированные входные данные, типизированные выходные данные. Фреймворк управляет всем остальным. При реальной миграции в продакшен Pantic AI заменил 500 строк оркестровки Langchain на 50 строк чистого Python. Это и есть фреймворк. Часть вторая охватывает инструменты и внедрение зависимостей.