В X мелькнул короткий, но показательный пример от Саймона Уиллисона (@simonw): несколько агентов ведут диалог, полностью обходясь без API, сокетов и брокеров сообщений. Вместо этого — обычная папка с файлами, где само имя файла и есть сообщение. Один агент кладёт файл с определённым именем, другой его читает и отвечает своим файлом, а порядок переписки поддерживается служебными префиксами вроде «zz», которые гарантируют, что новое сообщение окажется внизу списка при обычной алфавитной сортировке. Если нужно передать бинарные данные — скажем, изображение или документ — их просто кодируют в base64 и кладут содержимым того же текстового файла.
Коммуникация ai-агентов через файлы: как это устроено
На первый взгляд это похоже на самодельный костыль, но по сути перед нами полноценный протокол — просто предельно упрощённый. Файловая система здесь выполняет роль шины сообщений: имя файла кодирует метаданные (отправитель, тип сообщения, порядковый номер через префикс), а содержимое — полезную нагрузку, при необходимости в base64. Никакой схемы, никакого сервера очередей, никакой сериализации сложнее text/plain. Агенту, который умеет читать и писать файлы — а это умеет практически любой agent на базе LLM, включая subagent’ов Claude Code, — для участия в такой переписке не требуется вообще ничего дополнительного: ни MCP-сервер, ни отдельный tool, ни настройка транспорта.
Почему это не хак, а осмысленный выбор
Файловая система как универсальный интерфейс
У этого паттерна межагентного взаимодействия есть вполне unix-философская логика: файлы — самый низкоуровневый и самый совместимый интерфейс, какой только есть. Он одинаково доступен из Python-скрипта, из shell-команды, из другого LLM-агента и из человека с текстовым редактором. Не нужно поднимать инфраструктуру, беспокоиться о версиях протокола между разными фреймворками агентов или синхронизировать SDK — достаточно, чтобы оба участника имели доступ к одной директории.
Отладка «руками», без специальных инструментов
Второе, менее очевидное преимущество — прозрачность для отладки. Когда переписка агентов лежит открытым текстом в папке с говорящими именами файлов, весь диалог можно просмотреть глазами, отсортировать, отредактировать вручную и подсунуть агенту исправленную версию — без специального дебаггера для очереди сообщений или логов брокера. Для сценариев, где агенты работают асинхронно и не обязаны отвечать мгновенно, задержка файловой системы совершенно не критична, а зато инспектировать состояние диалога в любой момент — тривиально.
Кому пригодится такая архитектура агентного взаимодействия
Практическая ценность здесь в первую очередь для тех, кто собирает собственные мультиагентные системы поверх Claude Code или похожих инструментов: если задача — соединить два-три агента для обмена промежуточными результатами, разворачивать message broker или писать MCP-сервер часто избыточно. Файловый протокол с простой конвенцией именования закрывает 80% таких сценариев за пять минут, и его легко читать через полгода, когда придётся вспоминать, что вообще происходило в системе. Это особенно актуально для локальных экспериментов и pet-проектов, где cron-скрипты и агенты и так уже работают с файловой системой как с основным хранилищем состояния.
Вывод
Пример Уиллисона — хорошее напоминание, что для оркестрации агентов не всегда нужна тяжёлая инфраструктура. Иногда самое надёжное решение — то, которое можно объяснить одним предложением: «агенты договариваются, читая и создавая файлы в общей папке». Прежде чем городить очередь сообщений или отдельный API для связи между агентами, стоит спросить — а не хватит ли для этого обычной директории и понятной конвенции имён.
Добавить комментарий