Команда LangChain разработала новый чат‑бот на базе LangChain, LangGraph и LangSmith. У него две задачи: отвечать на вопросы о продукте (Product Q&A) и показывать клиентам, как создавать надёжные агенты (Customer Prototype).
Инженеры поддержки раньше не пользовались чат‑ботом LangChain для решения сложных вопросов — например, о проблемах с потоковой передачей в продакшене. Им не хватало данных из документации. Они выполняли трёхшаговый рабочий процесс: искали информацию в документации (docs.langchain.com), проверяли базу знаний (support.langchain.com) и открывали Claude Code, чтобы найти реализацию и проверить поведение кода.
Команда автоматизировала этот процесс: создала внутренний Deep Agent с тремя субагентами — для работы с документацией, базой знаний и поиском в кодовой базе. Субагенты задают уточняющие вопросы и фильтруют результаты, передавая данные главному агенту‑оркестратору. Главный агент синтезирует информацию и выдаёт развёрнутые ответы с ссылками на документацию, известные решения и строки кода. Например, он может ответить так: «Чтобы выполнить потоковую передачу из подграфов, установите subgraphs: true в конфигурации потока согласно LangGraph streaming docs.. Есть статья поддержки „Why is token streaming not working after upgrade“ (https://support.langchain.com/articles/7150806184-Why-is-token-by-token-streaming-not-working-after-upgrading-LangGraph?) — в ней объясняется, что нужно включить потоковую передачу подграфа, чтобы получать обновления на уровне токенов от вложенных агентов. Реализация находится в pregel/main.py lines 3373-3279,, где флаг subgraphs управляет включением выходных данных вложенного графа в поток».
Инженеры оценили решение: оно экономило им часы на отладку.
Публичный чат‑бот LangChain работал менее эффективно: он разбивал документы на фрагменты, генерировал вложения, сохранял их в векторной базе данных и требовал постоянной переиндексации при обновлении документации. Пользователи получали ответы, но цитаты нуждались в доработке, а контекст был фрагментирован.
При перестройке продукта нужно было объединить две архитектуры для ответов на разные категории вопросов: одни решаются с помощью документации и базы знаний, другие — через анализ кода.
Для простых вопросов по документации выбрали Create Agent (в createAgent / langchain / chat.langchain.com) как режим по умолчанию. Он обеспечивает высокую скорость — нет фазы планирования и накладных расходов на оркестрацию. Агент ищет информацию в документации, при необходимости проверяет базу знаний, уточняет запрос при неясных результатах и выдаёт ответ. Большинство вопросов по документации решается за 3–6 вызовов инструментов, Create Agent выполняет их за секунды.
Пользователям доступны модели: Claude Haiku 4.5, GPT-4o Mini, GPT-4o-nano. Haiku 4.5 отличается высокой скоростью вызова инструментов при сохранении точности. Комбинация createAgent и Haiku 4.5 даёт ответ менее чем за 15 секунд для большинства запросов.
Для оптимизации использовались LangSmith. С их помощью отслеживались разговоры, выявлялись ненужные вызовы инструментов и уточнялись промпты. Данные показали: если научить агента задавать более качественные уточняющие вопросы, большинство вопросов можно решить за 3–6 вызовов инструментов. LangSmith позволил провести A/B‑тестирование стратегий промптов и измерить улучшения скорости и точности.
Пример 30‑секундного трассирования включает 7 вызовов инструментов: 4 поиска в документации, поиск статьи в базе знаний, 2 чтения статей; 20 секунд уходит на потоковую передачу финального ответа (
, View Here).
Для ответов с использованием кода создали Deep Agent со специализированными подграфами: для поиска в документации, в базе знаний и в кодовой базе. Каждый субагент работает независимо: задаёт уточняющие вопросы, фильтрует информацию и извлекает наиболее релевантные данные, передавая их главному агенту‑оркестратору.
Субагент поиска в кодовой базе умеет искать в частных репозиториях с помощью сопоставления шаблонов, ориентироваться в структуре файлов, читать конкретные реализации с точностью до номера строки.
Архитектура Deep Agent работает дольше — для сложных запросов может потребоваться 1–3 минуты, но её тщательность оправдывает это. DeepAgent используют, когда первоначальный ответ не затрагивает суть вопроса. На старте режим доступен только части пользователей, через несколько дней станет общедоступным.
От векторных встраиваний отказались из‑за трёх проблем при работе со структурированной документацией:
* разбиение на фрагменты (500 токенов) нарушает структуру (теряются заголовки, подразделы, контекст);
* частые обновления документации (несколько раз в день) требуют постоянного реиндексирования, повторного встраивания и повторной загрузки;
* неточные ссылки — пользователи не могут проверить ответы и отследить источник информации.
Проблему решили иначе: вместо улучшения поиска предоставили агенту прямой доступ к существующей структуре данных (документации, базам знаний, кодовым базам).
Подход: прямой доступ через API и умные промпты.
* Для документации используется API Mintlify — возвращает полные страницы с заголовками, подразделами и примерами кода.
* Поиск в базе знаний: сначала запрос статей поддержки по заголовку, затем чтение наиболее перспективных статей полностью.
* Поиск в кодовой базе: кодовая база загружена в LangGraph Cloud, используется ripgrep для сопоставления шаблонов, обход каталогов для понимания структуры и чтение файлов для извлечения конкретных реализаций.
Агент ищет не по оценкам сходства, а как человек — по ключевым словам, уточняет запрос и задаёт дополнительные вопросы. Если результаты неоднозначны или неполны, агент уточняет запрос и ищет снова. Если в документации упоминается понятие без объяснения, агент ищет это понятие отдельно. Если возможны несколько интерпретаций, агент выбирает наиболее релевантную.
Например, пользователь спрашивает, как добавить память агенту. Агент ищет «memory», получает результаты по checkpointing, истории разговоров и Store API. Понимает неоднозначность вопроса (память может означать сохранение состояния разговора в потоке или хранение фактов в нескольких разговорах). Затем ищет «checkpointing», получает статью «How do I configure checkpointing in LangGraph?», понимает, что она не покрывает межпоточную память, ищет «store API». Итоговый ответ охватывает checkpointing для истории разговоров и Store API для долговременной памяти с точными ссылками на статьи поддержки и документацию.
Поиск в базе знаний (на базе Pylon) построен как двухэтапный процесс — так люди обычно используют базы знаний. Агент сначала получает заголовки статей (иногда десятки) и сканирует их, чтобы определить релевантные, затем читает только эти статьи полностью. Используются инструменты: searchsupportarticles (с параметрами collections: str = «all», limit: int = 50) для получения заголовков и getarticlecontent (с параметром article_ids: List[str]) для чтения содержания статей. Подход позволяет агенту отфильтровать 2–3 важные статьи вместо 30, тщательно их изучить и извлечь ключевые сведения.
Для поиска в кодовой базе агент использует три инструмента: searchpubliccode (с параметрами pattern: str, path: Optional[str] = None) — для поиска кода по шаблону; listpublicdirectory (с параметрами path: str, maxdepth: int = 2) — для изучения структуры файлов; readpublicfile (с параметрами filepath: str, startline: int = 1, numlines: int = 100) — для чтения конкретного файла. Процесс: поиск по шаблону с помощью ripgrep, вывод структуры директории, чтение нужного файла с указанием номеров строк.
Пример из практики: пользователь сообщил, что токены потоковой передачи зависают в продакшене. Subagent документации выяснил, что конфигурация потоковой передачи связана с настройками буфера; subagent базы знаний нашёл статью о проблемах с потоковой передачей токенов после обновлений; subagent кодовой базы нашёл реализацию — выполнил поиск «streaming buffer», перешёл к callbacks/streaming.py и вернул строки 47–83, где жёстко задан размер буфера по умолчанию.
Изначально Deep Agent возвращал все найденные данные (например, 5 страниц документации, 12 статей из базы знаний, 20 фрагментов кода), из‑за чего переполнялось контекстное окно — итоговый ответ либо содержал лишние детали, либо упускал ключевую информацию. Затем систему реструктурировали с использованием специализированных подграфов: каждый subagent работает независимо — ищет в своей области, задаёт уточняющие вопросы, фильтрует результаты и извлекает только необходимые данные. Главный агент‑оркестратор получает не сырые результаты поиска, а обработанные сведения от экспертов по каждой области.
Подагент документации может прочитать пять полных страниц, но вернуть только два ключевых абзаца. Подагент базы знаний может просканировать двадцать заголовков статей, но вернуть только три релевантных резюме. Подагент кодовой базы может искать пятьдесят файлов, но вернуть конкретную реализацию с номерами строк. Главный агент получает очищенную, отобранную информацию для формирования развёрнутого ответа.
Для подготовки к промышленной эксплуатации создали модульную структуру middleware: guardrailsmiddleware (фильтрация нерелевантных запросов), modelretrymiddleware (повтор запросов при сбоях API), modelfallbackmiddleware (переключение между моделями при недоступности одной из них), anthropiccache_middleware (кэширование затратных вызовов).
Для работы с потоковой передачей и управлением состоянием используется LangGraph SDK. При открытии Chat LangChain история разговоров пользователя извлекается с помощью client.threads.search({ metadata: { userid: userId }, limit: THREADFETCH_LIMIT }).
При отправке сообщения пользователем LangGraph SDK передаёт ответ в режиме потоковой передачи: const streamResponse = client.runs.stream(threadId, «docs_agent», { input: { messages: [{ role: «user», content: userMessage }] }, streamMode: [«values», «updates», «messages»], streamSubgraphs: true }).
Три режима потоковой передачи показывают весь процесс мышления агента: messages (токены появляются постепенно по мере написания), updates (вызовы инструментов показывают, что ищет агент), values (окончательное полное состояние после обработки).
Память разговора: передача одного и того же thread_id между сообщениями — checkpointer LangGraph обрабатывает остальное, сохраняет историю разговоров, извлекает контекст для каждого хода и поддерживает состояние между сессиями (установлен TTL 7 дней).
После запуска новых систем время ответа в публичном Chat LangChain — менее 15 секунд, есть точные цитаты и прямые ссылки на страницы документации или статьи базы знаний.
Внутренние инженеры поддержки используют Deep Agent для обработки сложных заявок: он ищет в документации, сопоставляет с известными проблемами и изучает частную кодовую базу.
Ключевые принципы разработки:
* следовать рабочему процессу пользователя: автоматизировать уже используемый успешный рабочий процесс (для LangChain — повторить трёхшаговый ритуал проверки документации, базы знаний и кодовой базы);
* оценивать уместность векторных вложений: для структурированного контента (документация по продукту, код) векторные вложения могут нарушать структуру документа, приводить к расплывчатым цитатам и требовать постоянной переиндексации; векторные вложения подходят для неструктурированного контента, коротких блоков или кластеризации;
* предоставлять агенту прямой доступ к структуре: агент получает прямой API-доступ к существующей структуре контента, может искать по ключевым словам и уточнять запрос;
* приоритезировать рассуждение над извлечением: проектировать инструменты по аналогии с рабочими процессами человека (просмотр заголовков статей, чтение контента, сопоставление шаблонов и навигация по каталогам для кода); побуждать агента задавать уточняющие вопросы и корректировать запрос при неоднозначных результатах;
* использовать Deep Agents и подграфы для управления контекстом: для сложных вопросов из нескольких областей Deep Agent со специализированными подграфами фильтрует и извлекает «золотые данные» из своей области, передавая уточнённые данные вверх;
* использовать производственную промежуточную среду: модульная промежуточная среда нужна для надёжности (фильтрация неуместных запросов, повторные попытки при сбоях API, переключение моделей, кэширование) — это обеспечивает надёжность, оптимизацию затрат и контроль качества в продакшене.
Запланирован поиск в публичных кодовых базах (запуск в ближайшие несколько дней): агент будет искать в публичных репозиториях, чтобы проверить реализации и указать точные номера строк. Попробовать можно в Chat LangChain (chat.langchain.com) с Claude Haiku 4.5 (для быстрых ответов), GPT-5 Mini и GPT-5 Nano (для сравнения производительности моделей). Присоединиться к сообществу LangChain можно через forum или следить за обновлениями через Twitter.
Подписаться в Макс
