MongoDB VFS для LangChain Deep Agents: файловая система с возможностью поиска для агентов

От современных ИИ-агентов больше не ожидается просто ответов на вопросы. От них требуется выполнение реальной работы: планирование многоэтапных задач, изучение исходных материалов, создание промежуточных артефактов и передача частей проблемы другим агентам, что позволяет сократить работу, занимавшую раньше дни, до нескольких часов. Этот сдвиг повышает требования к тому, что находится «под капотом» агента. Агент может планировать и выполнять задачи с такой скоростью только в том случае, если он может надежно перемещаться, искать, читать и обновлять файловую систему, с которой он работает.

Виртуальная файловая система (VFS) MongoDB для LangChain Deep Agents связывает работу с файловой системой с MongoDB Atlas и базовым объектным хранилищем (например, S3 bucket). Она предоставляет Deep Agents привычную виртуальную файловую систему, обеспечивая агентов рабочим пространством с возможностью поиска, которое сохраняется между сессиями, развертываниями и под-агентами. Разработчики, создающие решения на базе Deep Agents, теперь могут использовать MongoDB Atlas в качестве платформы данных для своих агентов, включая MongoDB Search, Vector Search и гибридный поиск, не меняя при этом способ чтения или записи файлов в коде агента. Эта архитектура позволяет агенту планировать, изучать исходные материалы, создавать промежуточные артефакты и возвращаться к работе, которая может длиться часами или днями, не загружая весь корпус данных в контекстное окно.

В этой статье объясняется, что такое Deep Agents и виртуальная файловая система, как работает интеграция бэкенда MongoDB в агентском приложении и где этот шаблон может быть полезен в корпоративных агентских системах.

Как LangChain Deep Agents используют виртуальную файловую систему

Что такое LangChain Deep Agents?

LangChain Deep Agents — это агентская обвязка, построенная на базе LangChain и LangGraph для сложных многоэтапных задач. Они добавляют такие возможности, как планирование, под-агенты и инструменты для работы с файловой системой, чтобы агент мог разбивать большую задачу на более мелкие действия, а не пытаться решить все в рамках одного контекстного окна.

Deep Agent может выполнять такие операции, как:

• ls для понимания структуры каталогов

ls для понимания структуры каталогов

• glob для поиска файлов по шаблону пути

glob для поиска файлов по шаблону пути

• grep для поиска содержимого файлов

grep для поиска содержимого файлов

• read для извлечения файла

read для извлечения файла

• write и edit для создания или изменения артефактов

write и edit для создания или изменения артефактов

• upload_files и download_files для массового перемещения файлов

upload_files и download_files для массового перемещения файлов

Эти инструменты предоставляются через контракт бэкенда. Агенту не нужно знать, находятся ли файлы в локальной файловой системе, в хранилище LangGraph, в объектном хранилище или за другим уровнем персистентности. Он вызывает один и тот же интерфейс файловой системы, а настроенный бэкенд предоставляет данные.

Для получения информации об интеграции LangChain с MongoDB см. документацию Integrate MongoDB with LangChain - Atlas.

Что такое виртуальная файловая система?

Виртуальная файловая система — это логическое представление данных на основе путей, физическое хранение которых абстрагировано. Агент может видеть пути, такие как docs/, reports/ или projects/customer-a/, даже если базовые байты находятся в объектном хранилище, а представление для поиска хранится в базе данных.

Эта абстракция важна для агентов, поскольку навигация по файловой системе по своей природе является инкрементальной. Вместо того чтобы загружать весь корпус данных в промпт, агент может сначала просмотреть каталог, сузить поиск по шаблону имени файла, найти концепцию, прочитать соответствующий файл, а затем записать свои выводы в виде артефакта. Это помогает агентам оставаться в рамках ограничений контекста и сокращать расходы, поскольку каждый шаг извлекает только ту часть корпуса, которая действительно нужна, а не весь корпус целиком.

Таким образом, виртуальная файловая система — это нечто большее, чем абстракция хранилища. Это интерфейс управления контекстом для агентской работы.

Что такое виртуальная файловая система MongoDB для LangChain Deep Agents?

Пакет langchain-mongodb-deepagents-vfs является готовой реализацией BackendProtocol для Deep Agents. Он представляет корпус данных, поддерживаемый объектным хранилищем, как файловую систему для агента и направляет операции в систему, которая лучше всего подходит для них:

• Операции, ориентированные на поиск: grep, glob и ls выполняются с помощью MongoDB Atlas.

Операции, ориентированные на поиск: grep, glob и ls выполняются с помощью MongoDB Atlas.

• Операции с байтами файлов: read, write, edit, upload_files и download_files направляются непосредственно в ваше объектное хранилище.

Операции с байтами файлов: read, write, edit, upload_files и download_files направляются непосредственно в ваше объектное хранилище.

• Фоновый уровень синхронизации поддерживает соответствие представления MongoDB Search вашему объектному хранилищу.

Фоновый уровень синхронизации поддерживает соответствие представления MongoDB Search вашему объектному хранилищу.

Результатом является четкое разделение между источником истины и поисковым индексом. Ваше объектное хранилище владеет исходными документами. MongoDB Atlas хранит поисковые фрагменты, эмбеддинги и метаданные путей, необходимые для того, чтобы сделать корпус данных доступным для поиска.

Стоит задаться вопросом, почему поисковая плоскость должна быть отдельной системой, такой как Atlas, а не S3-совместимой платформой, которая также предлагает поиск, векторный поиск и гибридный поиск по тем же данным. Разделение на две плоскости — это не ограничение, а суть решения. Объектное хранилище оптимизировано для долговечного, недорогого и долгосрочного хранения байтов файлов; оно не предназначено для поддержания «живых» индексов, ранжирования гибридных запросов или одновременного обслуживания структурированных запросов к метаданным с низкой задержкой. Atlas создан как операционная база данных с Search, Vector Search и гибридным ранжированием в качестве первоклассных индексируемых возможностей, поэтому поисковая плоскость работает на системе, разработанной именно для этой задачи, в то время как объектное хранилище продолжает делать то, в чем оно уже хорошо.

Гибридный поиск для агентских запросов

Пакет использует MongoDB Search и MongoDB Vector Search вместе для grep. Полнотекстовый поиск хорош для точных терминов, идентификаторов, имен файлов и редких строк. Векторный поиск хорош для перефразирований и вопросов на естественном языке. Объединение обоих сигналов позволяет агенту искать как буквальный токен, например MAX_RETRIES, так и концептуальный вопрос, например «где настроено поведение повторных попыток?», через один и тот же интерфейс.

Пакет объединяет полнотекстовые и векторные результаты с помощью этапа агрегации $rankFusion в MongoDB. Это сохраняет ранжирование на стороне базы данных и позволяет избежать отдельного уровня переранжирования на стороне клиента, что добавило бы лишний обмен данными между агентом и отдельным шагом переранжирования. Это также отражает более широкий компромисс в том, как строится поисковая плоскость. Получение полнотекстового, векторного и гибридного ранжирования на S3-совместимой платформе обычно означает объединение отдельных специализированных систем: поисковой системы для полнотекстового поиска, векторной базы данных для эмбеддингов и уровня переранжирования для объединения этих двух, каждая из которых имеет свой собственный конвейер индексации для синхронизации с исходными данными. Atlas запускает все три в одном движке, поэтому $rankFusion может объединять полнотекстовые и векторные результаты нативно в одном запросе, вместо того чтобы координировать результаты между системами, которые ничего не знают друг о друге.

Текущая реализация использует конвейер разбиения на фрагменты с учетом токенов. Поддерживаемые форматы документов включают обычный текст и Markdown, PDF, DOCX, XLSX, XLS, PPTX и PPT. Фрагменты сохраняют позиционные метаданные, такие как путь к источнику, номер страницы, смещения символов и информацию о строках, поэтому результаты могут быть возвращены в строко-ориентированном формате, совместимом с Deep Agents.

Путь встраивания по умолчанию использует эмбеддинги Amazon Bedrock, с опцией OpenAI, доступной через дополнительные пакеты. Приложения также могут внедрять реализацию эмбеддингов, совместимую с LangChain, напрямую.

Типичная интеграция выглядит следующим образом:

Python

Фрагмент кода

Теперь агент может использовать свои обычные инструменты файловой системы без специальных инструментов MongoDB или S3 в своем цикле рассуждений.

Как бэкенд MongoDB VFS разделяет хранение и поиск

Архитектуру можно представить как двухплоскостную систему: объектное хранилище является плоскостью данных для байтов файлов, в то время как MongoDB Atlas служит плоскостью управления и поиска для метаданных, фрагментов и индексов извлечения.

Рисунок 1. Как бэкенд LangChain Deep Agents VFS направляет байты файлов через объектное хранилище, а операции поиска — через MongoDB Atlas.

Как бэкенд загружает файлы в MongoDB Atlas

Когда создается MongoFilesystemBackend, инициализация начинается в фоновом режиме. Подготовка индексов, начальная синхронизация и запуск наблюдателя выполняются в потоке демона. Сквозные файловые операции можно использовать немедленно, в то время как операции поиска ожидают завершения начальной синхронизации.

Путь загрузки данных:

• Перечисление объектов в настроенном бакете S3 и префиксе.

Перечисление объектов в настроенном бакете S3 и префиксе.

• Загрузка каждого подходящего объекта.

Загрузка каждого подходящего объекта.

• Извлечение текста с помощью парсера, специфичного для формата.

Извлечение текста с помощью парсера, специфичного для формата.

• Разбиение текста на фрагменты с позиционными метаданными.

Разбиение текста на фрагменты с позиционными метаданными.

• Генерация эмбеддингов.

Генерация эмбеддингов.

• Upsert (обновление или вставка) фрагментов и метаданных в MongoDB Atlas.

Upsert (обновление или вставка) фрагментов и метаданных в MongoDB Atlas.

• Подготовка или проверка индексов MongoDB Search и Vector Search.

Подготовка или проверка индексов MongoDB Search и Vector Search.

Текущая стратегия разбиения использует фрагменты по 512 токенов с перекрытием в 64 токена. ETag делают начальную синхронизацию и загрузку наблюдателем идемпотентными: неизмененные объекты можно пропускать, а не загружать и встраивать заново.

Как бэкенд направляет файловые операции и операции поиска

Когда агент вызывает ls, бэкенд запрашивает у Atlas метаданные пути и группирует результаты как записи каталога. Когда он вызывает glob, бэкенд применяет стандартную семантику шаблонов путей для поиска соответствующих файлов. Когда он вызывает grep, Atlas комбинирует полнотекстовый и векторный поиск по корпусу фрагментов и возвращает ранжированные совпадения.

Когда агент вызывает read, бэкенд извлекает текущие байты из объектного хранилища, а не из поискового индекса. Это различие важно: результаты поиска оптимизированы для обнаружения, в то время как чтение возвращает исходный документ.

Как наблюдатели поддерживают поисковый индекс MongoDB в актуальном состоянии

Пакет поддерживает два режима наблюдателя:

• Наблюдатель опроса (Polling watcher): периодически проверяет объектное хранилище и не требует дополнительной инфраструктуры событий AWS.

Наблюдатель опроса (Polling watcher): периодически проверяет объектное хранилище и не требует дополнительной инфраструктуры событий AWS.

• Наблюдатель SQS: потребляет уведомления о событиях S3 через Amazon SQS и предназначен для производственной синхронизации с низкой задержкой.

Наблюдатель SQS: потребляет уведомления о событиях S3 через Amazon SQS и предназначен для производственной синхронизации с низкой задержкой.

Архитектура намеренно является согласованной в конечном счете для поиска. Успешная запись сначала достигает S3; затем наблюдатель обнаруживает изменение, перефрагментирует и перевстраивает объект, а также обновляет поисковые индексы. В результате чтение немедленно отражает состояние S3, в то время как grep, glob и ls могут отставать до завершения синхронизации и обновления поисковых индексов.

Для совместных рабочих процессов это предполагает практическое правило: используйте прямое чтение для «горячего» общего состояния, используйте редактирование для оптимистичного параллелизма в общих файлах и используйте поиск для обнаружения по всему устоявшемуся корпусу. Использование пространств имен для вывода агента, например, shared/outputs//, также может уменьшить конфликты между параллельными рабочими процессами.

Корпоративные варианты использования бэкенда виртуальной файловой системы

Агенты кодирования с пониманием кодовой базы

Агент кодирования может исследовать большой репозиторий постепенно, а не получать огромный дамп кода. Он может перечислить структуру проекта, найти файлы с помощью glob, найти концепцию или идентификатор с помощью гибридного grep, прочитать конкретный файл и применить редактирование, защищенное ETag.

Этот шаблон полезен для:

• Онбординга в репозиторий и навигации по коду

Онбординга в репозиторий и навигации по коду

• Расследования инцидентов

Расследования инцидентов

• Анализа зависимостей и конфигураций

Анализа зависимостей и конфигураций

• Обнаружения тестов и целевого исправления

Обнаружения тестов и целевого исправления

• Генерации документации из исходного кода

Генерации документации из исходного кода

Интеллектуальная работа с частными документами

Организации часто имеют большие коллекции политик, контрактов, процедур, руководств, документов по продуктам и клиентских артефактов, хранящихся в объектном хранилище. Бэкенд предоставляет агенту интерфейс, похожий на файловую систему, для работы с этим корпусом.

Например, агент по документам может искать «политику возврата для корпоративных клиентов», находить соответствующие отрывки, даже если формулировки различаются, читать исходный PDF или DOCX и записывать готовый к цитированию сводный отчет или артефакт обзора в отдельный путь.

Это естественным образом подходит для генерации с дополнением поиска (RAG), где агенту необходимо перемещаться, а не просто выполнять один шаг поиска.

Мультиагентные исследования и анализ

Координатор может делегировать целенаправленную работу специализированным субагентам, которые используют общий корпус:

• Агент безопасности ищет опасные шаблоны кода.

Агент безопасности ищет опасные шаблоны кода.

• Агент документации находит шаги развертывания и ссылки на конфигурации.

Агент документации находит шаги развертывания и ссылки на конфигурации.

• Агент тестирования находит соответствующие файлы тестов и создает заметки о покрытии.

Агент тестирования находит соответствующие файлы тестов и создает заметки о покрытии.

• Агент синтеза читает результаты и пишет сводный отчет.

Агент синтеза читает результаты и пишет сводный отчет.

Общая файловая система предоставляет каждому субагенту согласованное пространство имен, а MongoDB обеспечивает интеллектуальный уровень обнаружения по корпусу.

Длительный мониторинг изменяющихся данных

Корпоративные хранилища документов не статичны. Появляются новые отчеты, меняются политики, обновляются операционные артефакты. Наблюдатель поддерживает представление MongoDB Search в соответствии с базовым объектным хранилищем, поэтому агент, вызванный позже, может искать по текущему корпусу без перестроения индекса для каждого запуска.

Это может поддерживать:

• Помощников по операционным руководствам

Помощников по операционным руководствам

• Мониторинг соответствия требованиям и политик

Мониторинг соответствия требованиям и политик

• Научных помощников по постоянно обновляемым наборам данных

Научных помощников по постоянно обновляемым наборам данных

• Поддержка агентов с помощью документации по продукту и устранению неполадок

Поддержка агентов с помощью документации по продукту и устранению неполадок

• Помощники по партнерским решениям на основе общих артефактов внедрения

Помощники по партнерским решениям на основе общих артефактов внедрения

Постоянные рабочие пространства для агентских приложений

Deep Agents могут создавать планы, промежуточные заметки, сводки и генерируемые результаты в виде файлов. Сохранение этих артефактов в объектном хранилище с одновременной индексацией в Atlas предоставляет приложению постоянное рабочее пространство, которое сохраняется после перезапуска процессов и может быть просмотрено людьми или другими агентами.

Для производственных систем требования к контролю доступа, изоляции арендаторов, месту хранения данных, хранению и аудиту должны обеспечиваться через приложение, конфигурацию хранилища и модель метаданных. Основными задачами текущего пакета являются контракт файловой системы, совместимый с Deep Agents, и путь поиска от Object Store к Atlas.

Как внести свой вклад в интеграцию LangChain MongoDB

Пакет находится в репозитории langchain-mongodb, и мы приветствуем любой вклад. Начните с руководства по внесению вклада в репозиторий, затем изучите тесты пакета и существующие границы бэкенда.

Потенциальные области для внесения вклада включают:

• Дополнительные бэкенды объектного хранилища, такие как Azure Blob Storage или Google Cloud Storage

Дополнительные бэкенды объектного хранилища, такие как Azure Blob Storage или Google Cloud Storage

• Новые провайдеры эмбеддингов и настраиваемые стратегии эмбеддинга

Новые провайдеры эмбеддингов и настраиваемые стратегии эмбеддинга

• Дополнительные парсеры документов и оптимизация процесса приема данных

Дополнительные парсеры документов и оптимизация процесса приема данных

• Улучшение надежности наблюдателя (watcher), заполнения данных и актуальности

Улучшение надежности наблюдателя (watcher), заполнения данных и актуальности

• Улучшение качества поиска, фильтрации, ранжирования и метаданных

Улучшение качества поиска, фильтрации, ранжирования и метаданных

• Более качественные примеры, документация, бенчмарки и руководство по развертыванию

Более качественные примеры, документация, бенчмарки и руководство по развертыванию

Полезный принцип проектирования заключается в том, чтобы скрывать специфическое поведение хранилища за интерфейсом объектного хранилища. Это позволяет компонентам разбиения на части (chunker), эмбеддеру, логике синхронизации и поисковому маршрутизатору сосредоточиться на путях, байтах, метаданных и поиске, а не на конкретном API облачного хранилища.

Основные выводы: Постоянная виртуальная файловая система для LangChain Deep Agents

LangChain Deep Agents предоставляют агентно-ориентированный способ планирования, делегирования, навигации по файлам и создания долговечных результатов работы. Виртуальная файловая система MongoDB для LangChain Deep Agents связывает этот опыт с удобным для корпоративного использования шаблоном хранения: ваше объектное хранилище остается источником истины для байтов файлов, в то время как MongoDB Atlas предоставляет метаданные, полнотекстовый поиск, векторный поиск и гибридное ранжирование, необходимые агентам для поиска нужного контекста.

Самая важная идея — это разделение ответственности. Агенты видят одну простую виртуальную файловую систему. Приложения могут хранить большие, разнородные документы в объектном хранилище. Atlas превращает эти документы в доступную для поиска базу знаний, а уровень синхронизации поддерживает актуальность обнаружения в соответствии с текущим корпусом данных.

megaphone