Памяти агентов нужен свой OpenTelemetry
Agent memory needs its OpenTelemetry moment
Автор перечисляет форматы памяти, которые сегодня используют инструменты для кодинга: AGENTS.md, CLAUDE.md, правила Cursor, файлы Anthropic в /memories, факты Copilot, графы MCP-серверов. Их уже десятки, и ни один не читает другой. Проблема не в отсутствии инструмента, а в отсутствии договорённости. По аналогии с OpenTelemetry, где вендоры сошлись на модели данных, семантических конвенциях и протоколе, автор призывает сообщество согласовать общий формат записи памяти агента, а конкурировать уже на хранении и поиске.
Проблема не в отсутствии инструмента. Это отсутствие договорённости, а она появляется только тогда, когда сообщество работает над этим вместе.
- armchairhacker
Это действительно серьёзная проблема? Кажется, на каждую проблему AI с «текстовым форматом» есть по 15 решений, но все они — лишь структура поверх скармливания AI неформального английского, структура, которую, как я полагаю, модель-«трансформер» специально способна свести к общей форме (именно так и сработало обучение на всём интернете).
AI действительно выигрывает от обучения использованию навыков и от инструкций с хорошими структурами (вроде «сохраняй [конкретный важный вид деталей] в памяти» и «планируй перед тем, как что-то реализовывать»). Но ни одно из этих решений для памяти не кажется лучше любого другого, по сути это просто разные папки. Ваш CLAUDE.md может говорить «см. AGENTS.md», а AGENTS.md может говорить «записывай воспоминания в .agent/memories/», и мне была бы интересна оценка, но я предполагаю, что это работает почти точно так же, как нативные CLAUDE.md и .claude/memories.
Одна вещь, которую я заметил: AI справляется гораздо лучше меня с тем, чтобы не страдать ОКР по поводу «идеального» решения.
- speedping
Весь пост в блоге разит LLM.
Если бы существовал достаточно надёжный способ определять текст от LLM, я бы сделал браузерное расширение, которое просто отфильтровывало бы его полностью.
- Fordec
По общей предпосылке я согласен. Но не думаю, что этот момент наступил сегодня, во всяком случае пока. Я не думаю, что мы понимаем правильный подход к контексту и памяти или как долго они должны существовать, не говоря уже о преждевременной стандартизации на абстракции, которая в итоге окажется чем-то вроде SOAP или SGML.
- Dirak
Нет, не нужен. В пространстве LLM всё ещё происходит масса инноваций и изменений, и ни одно решение не подходит на все случаи. Насколько я понимаю, решения должны идти на компромисс по трём основным параметрам: скорость, точность и стоимость. Я даже не думаю, что память в виде файлов уже устоялась. В этой области предстоит ещё столько инноваций и прогресса.
- baalimago
Нам это действительно нужно..? LLM хорошо справляются с интерпретацией естественного языка. Так что это губка для любого формата, используемого в конкретном проекте: предопределённый формат на самом деле не нужен.
Кроме того, разве мы действительно хотим, чтобы память агентов пользователя A сосуществовала с памятью пользователя B? Вовсе нет. Так что аргумент в пользу сотрудничества и обмена довольно слаб, по крайней мере для агентов-программистов. Контекст, специфичный для репозитория, можно закодировать в каталоге docs/ или architecture/, как это делалось и до эпохи агентов.
Для мониторинга развёрнутых агентов: возможно. Для этого я сделал (ещё один) инструмент управления памятью slivingdoc.dev, с его помощью можно вытянуть долговременный контекст всех агентов. Но здесь проблема из области распределённых систем, а не формата воспоминаний.
- imgyuri
Потребность в едином формате или спецификации сильно снижается в случае памяти агентов, потому что по определению её читают агенты, а агенты уже проинструктированы / запрограммированы читать файлы памяти разных форматов. Даже если бы таких инструкций не было, агенты чрезвычайно хорошо умеют обходить файлы, чтобы получить необходимый контекст.
- palijer
Слишком рано выступать за стандартизацию для этой проблемы. Otel появился после десятилетий опыта в этой области, мы исследовали бесчисленное множество решений и опирались на них при разработке Otel.
Утверждать, что мы уже достаточно исследовали решения для памяти агентов, чтобы стандартизировать её и добавить трения любым дальнейшим экспериментам, было бы, я думаю, ошибкой.
- mmasu
Мне любопытно, что люди делают в наши дни и как они решают эту проблему. На уровне репозитория можно обойтись AGENTS.md и, возможно, подобранным набором дополнительных документов с историей проекта, но как только вы выходите за его пределы и хотите иметь дополнительный контекст, доступных решений слишком много — Hindsight, Graphiti и многие другие; или просто развернуть своё собственное? Мне хотелось бы что-то, что я могу поднять с Postgres или с S3-бакетом и что пишет мне .md-файлы, сохраняя при этом некую связь между разными сущностями — однако, похоже, «простого» решения пока нет, и многие существующие реализации слишком замысловаты и/или требуют экзотических БД. Было бы очень интересно услышать, если кто-то знает о минималистичном решении, которое я могу подключить к любому агенту.