Handoffs + Locks + Mailbox - по сути переизобрели Chubby/ZooKeeper на файлах. И это комплимент, не критика. Для координации параллельных сессий на одной машине файловая система - самый надежный транспорт.
У нас похожая задача, но другой масштаб: не сессии одного разработчика на одной машине, а разные люди в разных IDE (Claude Code, Cursor, Windsurf) на разных машинах. Файловые локи тут не работают, нужна сетевая координация.
Мы решили это через MCP-сервер с общей базой (CoAlly). Агент автоматически сохраняет контекст (что сделал, какие файлы тронул, почему так решил), другой агент находит это через семантический поиск. Не синхронная координация как у вас (агент A блокирует файл, агент B ждет), а асинхронная (агент A записал контекст, агент B прочитает когда понадобится).
Ваш подход с heartbeat для мертвых процессов правильный. Мы на это напоролись с другой стороны: если MCP-сессия падает посередине save_session_context, запись может остаться без эмбеддинга. Решили через async write - эмбеддинг генерируется в фоне, агент не ждет.
mclaude + CoAlly кстати могли бы хорошо дополнять друг друга: mclaude для синхронной координации сессий, CoAlly для долгосрочной памяти между ними.
Точно попали в больное место. У меня похожий опыт - агент без контекста тратит час на то, что с контекстом делается за пять минут. И самое обидное когда он повторяет решение, которое ты уже отбросил неделю назад.
Мы пошли чуть дальше memory bank файлов - сделали MCP-сервер (CoAlly), который автоматически сохраняет контекст работы агента в векторную базу. Семантический поиск вместо grep по плоским файлам. Работает с любыми агентами, контекст шарится между инструментами.
Но ваш подход с иерархической организацией знаний правильный. Мы тоже пришли к тому что просто кидать все в одну базу недостаточно - нужна структура. Сейчас добавляем knowledge scan, который сам находит ADR, memorybank, docs/decisions в репозитории и индексирует.
Все верно, 55K токенов на инициализацию MCP-инструментов - это реальная проблема, часто с этим сталкиваемся на разных проектах.
Мы делаем CoAlly (MCP для общей памяти агентов) и при проектировании специально ограничили количество инструментов (сейчас всего 5: индексация проекта, сохранение контекста, семантический поиск, обновление правил, настройка агента).
Подход с Agent Skills из статьи - правильный. По сути это то что мы делаем через rules-файлы, которые инструктируют агента когда и как использовать tools. Агент не загружает все инструменты сразу. Он знает правила и вызывает конкретный инструмент в конкретный момент.
Проблема “утопления в контексте” касается не только инструментов. Когда у агента доступ к тысячам записей памяти, он тоже может захлебнуться. Эту проблему решаем через механизм забывания - неиспользуемые записи должны терять вес.
Хранение в незашифрованном виде, доступ любой программе на компьютере, скриншоты на серверы OpenAI - набор проблем, который enterprise-клиент даже обсуждать не будет.
Мы делаем похожую штуку (CoAlly - память для агентов), но с другим подходом к безопасности. Текстовый контекст вместо скриншотов. Эмбеддинг-модель работает локально, данные не уходят наружу. API ключи хешируются, контент шифруется per-organization. Есть on-premise вариант - Docker Compose на своем сервере, никакого обмена с облаком.
Prompt injection через скриншоты - это вообще новый вектор атаки. Вредоносный текст на странице попадает в скриншот, оттуда в “память”, оттуда в контекст агента. С текстовой памятью этот вектор тоже существует, но хотя бы поддается валидации. Скриншот валидировать сложнее.
Chronicle как идея интересна. Что то похожее есть в Antigravity.
windsurf, например, недавно поменяли политику по тарификации и ввели дневные лимиты, что очень неудобно. Используя общую память вы сможете работать в любой среде и любым совместимым агентом закрывать задачи используя средства разработки сообща, а не по отдельности (каждый агент, который имеет доступ к общей памяти, продолжит работу с того места где остановился предыдущий). А также накапливать знания и навыки в общей базе (в т.ч. с командой), чтобы не тратить время и ресурсы на повторые объяснения и старые ошибки
мне, например, хотелось бы чтобы агентам не нужно было объяснять по 100500 раз одно и тоже, а можно было их научить один раз и использовать эти навыки в разных сессиях, агентах и средах разработки. Собственно об этом и статья) кейсов достаточно много, лично мне это экономит тонну времени, поэтому и Вас призываю попробовать
Handoffs + Locks + Mailbox - по сути переизобрели Chubby/ZooKeeper на файлах. И это комплимент, не критика. Для координации параллельных сессий на одной машине файловая система - самый надежный транспорт.
У нас похожая задача, но другой масштаб: не сессии одного разработчика на одной машине, а разные люди в разных IDE (Claude Code, Cursor, Windsurf) на разных машинах. Файловые локи тут не работают, нужна сетевая координация.
Мы решили это через MCP-сервер с общей базой (CoAlly). Агент автоматически сохраняет контекст (что сделал, какие файлы тронул, почему так решил), другой агент находит это через семантический поиск. Не синхронная координация как у вас (агент A блокирует файл, агент B ждет), а асинхронная (агент A записал контекст, агент B прочитает когда понадобится).
Ваш подход с heartbeat для мертвых процессов правильный. Мы на это напоролись с другой стороны: если MCP-сессия падает посередине save_session_context, запись может остаться без эмбеддинга. Решили через async write - эмбеддинг генерируется в фоне, агент не ждет.
mclaude + CoAlly кстати могли бы хорошо дополнять друг друга: mclaude для синхронной координации сессий, CoAlly для долгосрочной памяти между ними.
Точно попали в больное место. У меня похожий опыт - агент без контекста тратит час на то, что с контекстом делается за пять минут. И самое обидное когда он повторяет решение, которое ты уже отбросил неделю назад.
Мы пошли чуть дальше memory bank файлов - сделали MCP-сервер (CoAlly), который автоматически сохраняет контекст работы агента в векторную базу. Семантический поиск вместо grep по плоским файлам. Работает с любыми агентами, контекст шарится между инструментами.
Но ваш подход с иерархической организацией знаний правильный. Мы тоже пришли к тому что просто кидать все в одну базу недостаточно - нужна структура. Сейчас добавляем knowledge scan, который сам находит ADR, memorybank, docs/decisions в репозитории и индексирует.
Все верно, 55K токенов на инициализацию MCP-инструментов - это реальная проблема, часто с этим сталкиваемся на разных проектах.
Мы делаем CoAlly (MCP для общей памяти агентов) и при проектировании специально ограничили количество инструментов (сейчас всего 5: индексация проекта, сохранение контекста, семантический поиск, обновление правил, настройка агента).
Подход с Agent Skills из статьи - правильный. По сути это то что мы делаем через rules-файлы, которые инструктируют агента когда и как использовать tools. Агент не загружает все инструменты сразу. Он знает правила и вызывает конкретный инструмент в конкретный момент.
Проблема “утопления в контексте” касается не только инструментов. Когда у агента доступ к тысячам записей памяти, он тоже может захлебнуться. Эту проблему решаем через механизм забывания - неиспользуемые записи должны терять вес.
Хранение в незашифрованном виде, доступ любой программе на компьютере, скриншоты на серверы OpenAI - набор проблем, который enterprise-клиент даже обсуждать не будет.
Мы делаем похожую штуку (CoAlly - память для агентов), но с другим подходом к безопасности. Текстовый контекст вместо скриншотов. Эмбеддинг-модель работает локально, данные не уходят наружу. API ключи хешируются, контент шифруется per-organization. Есть on-premise вариант - Docker Compose на своем сервере, никакого обмена с облаком.
Prompt injection через скриншоты - это вообще новый вектор атаки. Вредоносный текст на странице попадает в скриншот, оттуда в “память”, оттуда в контекст агента. С текстовой памятью этот вектор тоже существует, но хотя бы поддается валидации. Скриншот валидировать сложнее.
Chronicle как идея интересна. Что то похожее есть в Antigravity.
windsurf, например, недавно поменяли политику по тарификации и ввели дневные лимиты, что очень неудобно. Используя общую память вы сможете работать в любой среде и любым совместимым агентом закрывать задачи используя средства разработки сообща, а не по отдельности (каждый агент, который имеет доступ к общей памяти, продолжит работу с того места где остановился предыдущий). А также накапливать знания и навыки в общей базе (в т.ч. с командой), чтобы не тратить время и ресурсы на повторые объяснения и старые ошибки
мне, например, хотелось бы чтобы агентам не нужно было объяснять по 100500 раз одно и тоже, а можно было их научить один раз и использовать эти навыки в разных сессиях, агентах и средах разработки. Собственно об этом и статья) кейсов достаточно много, лично мне это экономит тонну времени, поэтому и Вас призываю попробовать