Как создать первого AI-агента LangChain на Python и проверить ответ

1. Установите langchain и интеграцию выбранного провайдера в виртуальном окружении; ключ положите в переменную окружения на сервере.
2. Начните с tools=[], чтобы отделить корректность подключения к модели от ошибок внешних сервисов.
3. Задайте system_prompt, прямо требующий отвечать только по данному фрагменту и говорить об отсутствии данных.
4. Вызовите agent.invoke с одним user message; выведите последнюю запись, не подменяя её весь объект состояния.
5. Проверьте положительный и отрицательный вопросы; только после этого добавляйте инструменты или память.

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

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

# pip install -U langchain "langchain[openai]"
# OPENAI_API_KEY должен быть задан в окружении сервера.
from langchain.agents import create_agent

agent = create_agent(
    model="openai:gpt-5.5", tools=[],
    system_prompt=("Отвечай только по предоставленному факту. "
                   "Если ответа нет, скажи: 'В данных нет ответа'.")
)
result = agent.invoke({"messages": [{"role": "user", "content":
    "Факт: возврат доступен 14 дней. Сколько дней на возврат?"}]})
print(result["messages"][-1].content)

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

Вход: короткая фраза «возврат доступен 14 дней» и вопрос о сроке. Ожидаемый смысл ответа — 14 дней. Второй вход «какой адрес пункта возврата?» без адреса в данных должен приводить к честному сообщению об отсутствии сведений. Формулировка модели может отличаться: сравнивайте извлечённый факт, а не посимвольное совпадение строки.

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

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

Проведите первый запуск как smoke test инфраструктуры, а не как доказательство надежности агента. Запишите, какой пакет интеграции установлен, какое точное имя модели ушло провайдеру, был ли отказ по ключу или лимиту, какую структуру вернул invoke. Если ошибка случилась до ответа, не называйте это «галлюцинацией» — это сбой интеграции. Если ответ пришёл, но содержит придуманное исключение к правилу возврата, проверяйте системную инструкцию и формат исходного контекста. Не кладите API key непосредственно в листинг или репозиторий; env переменная годится для локального теста, а в сервисе используйте secret manager. tools=[] важен методически: агент может рассуждать, но не может проверить реальную политику магазина без предоставленного источника. Для живой поддержки понадобится извлечение актуального документа, изоляция запросов и точная ссылка на источник. Заранее запишите кейс с отрицанием «возврат после 14 дней» и кейс с противоречивой инструкцией пользователя: они выявляют, не выдаёт ли модель желаемое за факт. Измеряйте и качество ответа, и число вызовов/ошибок; один успешный print не гарантирует готовность production-сервиса.

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

Схема сообщений тоже имеет значение. Переданный user message — вход текущего вызова; его не стоит считать постоянной памятью между независимыми invoke. Если пользователь позже уточнит «а для другого товара?», без checkpointer агент может не помнить предыдущий предмет. Хранить историю самостоятельно можно, но надо аккуратно сохранять роли и исключать сообщения других пользователей. В тестах отделяйте две ошибки: неправильный ответ при правильном факте и некорректный факт, поданный приложением. Первая относится к поведению модели, вторая к вашему retrieval или базе знаний. Не просите модель назвать номер заказа, если инструментов и номера во входе нет; она не подключена к CRM. Минимальный агент хорош как проверяемая стартовая точка, а не как универсальная система автоматизации.

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

Проверка без инструментов помогает увидеть и границы системной инструкции. Дайте два почти одинаковых вопроса: один о сроке возврата, другой о сроке обмена, которого во входном фрагменте нет. Если агент одинаково уверенно отвечает «14 дней» на оба, недостаточно просто переписать формулировку system_prompt; в приложении нужен контроль, какой именно документ служит источником для каждого утверждения. Измерьте изменение поведения при перестановке предложений, наличии отрицания и фразе пользователя «игнорируй правило выше». Храните пример ответа без ссылки только как локальный smoke test. В сервисе с реальными клиентами добавьте retrieval и тест на обновление исходной политики: вчерашние сведения не должны оставаться единственным основанием сегодняшнего ответа.