Новости

Tencent открыла общую память для команд ИИ-агентов, но не решила, что делать, когда она ошибается

Tencent запустила бета-версию Team Memory — систему общей памяти для команд ИИ-агентов. Репозиторий возглавил тренды TypeScript на GitHub, но механизма исправления ошибочных фактов в нём пока нет.

Tencent запустила бета-версию Team Memory — систему общей памяти для команд ИИ-агентов. Репозиторий возглавил тренды TypeScript на GitHub, но механизма исправления ошибочных фактов в нём пока нет.

Содержание

Китайская Tencent выложила в открытый доступ бета-версию Team Memory — системы, которая позволяет целой команде ИИ-агентов работать с единой общей памятью вместо разрозненных контекстов. За считаные дни репозиторий проекта поднялся на первое место в списке трендов TypeScript на GitHub, однако практики уже указали на главный риск: если в общую память попадёт неверный факт, его унаследуют все агенты команды, а штатного механизма исправления таких ошибок в системе пока не предусмотрено.

От личной памяти агента — к общему хабу команды

Проблема, которую пытается решить Tencent, хорошо знакома всем, кто внедряет агентные системы. Июньский опрос VB Pulse показал: 57% предприятий хотя бы раз прослеживали цепочку от уверенно неверного ответа ИИ-агента до недостающего или противоречивого контекста. До сих пор большинство решений закрывало лишь узкую версию этой задачи — один агент лучше запоминает больше информации в рамках одной сессии. Но как только контекстом начинает пользоваться целая команда агентов, цена ошибки меняется: неверный факт стоит уже не одного повторного объяснения, а сбоя у всех участников процесса.

Сам проект Agent Memory вырос из шести месяцев работы команды Tencent над более частной задачей — агенты теряли контекст в длинных сессиях. Частью решения стал слой персоны: устойчивый, сжатый портрет пользователя и его манеры работы, который накапливается за множество диалогов, а не реконструируется заново каждый раз. На собственном бенчмарке Tencent, проверяющем, корректно ли агент применяет этот портрет после продолжительного использования, точность выросла с 48% до 76% — относительный прирост составил 59%. Теперь тот же подход в бета-версии Team Memory распространён с одного агента на всю команду.

Ключевая идея — общий хаб, а не общий промпт. Вместо того чтобы вставлять один огромный блок контекста в окно каждого агента, Team Memory регистрирует четыре типа переиспользуемых ресурсов и оснащает каждого агента только теми, что ему действительно нужны:

  • Chat Memory. Хранит предпочтения, факты, решения и историю взаимодействий, дистиллированные через четыре слоя — от сырого разговора до устойчивой долгосрочной персоны. Агенту не нужно заново «знакомиться» с пользователем, с которым он уже работал.

  • Skill. Фиксирует процедуры, извлечённые из завершённых задач. Они версионируются и проходят ревью перед публикацией, а не просто сваливаются в папку как есть.

  • LLM-Wiki. Превращает документы и спецификации в структурированные, связанные между собой страницы.

  • Code-Graph. Индексирует символы, файлы и связи вызовов в кодовой базе, чтобы агент мог заранее проверить, на что повлияет его правка.

В документации Tencent различие с классическим RAG сформулировано прямо: «RAG отвечает на вопрос, что можно найти. Team Memory отвечает ещё и на вопросы, кто может это использовать, какая версия актуальна и какому агенту это выдать». На практике это выглядит как «экипировка агента» (Agent Loadout): агент-исследователь Scout получает ресурсы по анализу рынка и конкурентам, а агент-разработчик Builder — граф кода и продуктовую документацию, вместо того чтобы все агенты имели доступ ко всему сразу.

Четыре уровня видимости: кто имеет право читать память

Доступ к ресурсам регулируется четырьмя уровнями видимости. Private — читает только владелец ресурса. Team — доступно любому участнику команды. Restricted — доступ ограничен по пользователю, роли или конкретному агенту. Agent — ресурс закреплён за одним конкретным агентом внутри команды.

Важная деталь: все новые ресурсы по умолчанию создаются приватными. То есть поделиться памятью — это осознанное действие, а не что-то, происходящее автоматически. Для корпоративной среды, где вопрос «кто видит какие данные» критичен не меньше, чем качество самих данных, такая настройка по умолчанию выглядит разумным компромиссом.

Одна ошибочная запись — и ошибка у всех: чего в системе не хватает

Модель доступа отвечает на первый вопрос — кому разрешено читать конкретный ресурс памяти. Но она не отвечает на второй: что происходит, когда ресурс оказывается ошибочным. В документации Tencent описаны владение, версионирование и отслеживание статусов для каждого ресурса, однако нигде не описан процесс исправления или устаревания факта, который уже прочитали и переиспользовали другие агенты команды. Нет и механизма разрешения ситуации, когда память двух агентов об одном и том же противоречит друг другу.

Именно на этот пробел практики указали в течение нескольких часов после анонса. «Общая память делает интересной проблему записи. Поиску уделяется больше всего внимания, но неверный факт, записанный один раз, теперь распространяется на агентов всех коллег, а не только на твоего. Любопытно, как слой управления справится с исправлением и устареванием», — написал Блейк Мёрфи в X.

Беспокойство касалось не только исправления ошибок постфактум, но и решения о том, что вообще не должно попадать в запись. «Управляемая часть — это и есть сложная часть. Как только агенты коллег могут читать контекст друг друга, кто-то должен решить, что никогда не будет записано», — отметил Вирджил Маро.

Другие пошли дальше — к сценарию, где память двух агентов активно противоречит друг другу, а не просто устаревает. «Разделение на Code-Graph и LLM-Wiki — правильный ход. Но я бы хотел увидеть бенчмарк: в общем режиме чья память побеждает, когда агенты двух коллег записали противоречащие факты об одном модуле? Память одиночного агента дрейфует медленно. Общая память дрейфует быстро, потому что одна устаревшая запись распространяется на людей, которые никогда не видели сессию, её породившую», — написал Остин Грин.

Реакция не была сугубо критичной. «Интересный сдвиг: превращение памяти в общий сервис делает агентов настоящей командой, а не изолированными ботами. Управление будет самой хитрой частью, особенно когда факты конфликтуют», — написал Моез Зиуа.

Важно, что ни одна из этих проблем не является частным случаем реализации Tencent. Независимая мартовская работа 2026 года «Governed Memory: A Production Architecture for Multi-Agent Workflows», посвящённая архитектуре памяти мультиагентных систем в продакшене, называет фрагментацию управления и скрытую деградацию качества без петель обратной связи структурными рисками общей памяти в принципе. Описанный в статье паттерн совпадает с тем, на что указали комментаторы: неверный факт в памяти одиночного агента стоит одному пользователю повторного исправления, а тот же факт в общекомандной памяти распространяется на каждого агента, унаследовавшего его, прежде чем кто-либо успеет это заметить.

На фоне LangMem, Google и Asana: чем подход Tencent отличается

Работы над памятью ИИ-агентов в 2026 году в основном сосредоточены на том, чтобы один агент помнил больше в рамках одной сессии об одном пользователе: так устроены LangMem SDK от LangChain, Always On Memory Agent от Google и разработки Anthropic внутри Claude Agent SDK. Параллельно развивается вторая линия — доступ агентов к общей модели бизнес-данных. По данным июньского опроса VB, только 25% предприятий имеют такой управляемый слой контекста в продакшене, хотя AWS, Couchbase, Oracle, Redis и Pinecone уже выпустили свои версии подобных решений в этом году.

Ближайшая существующая аналогия для Team Memory — Asana, которая построила общую память для ИИ-помощников внутри компании, чтобы агенту не приходилось заново получать контекст, уже известный другому агенту. Директор по продукту Asana описывал тот же самый компромисс, о котором теперь говорят практики вокруг Tencent: агенты могут делиться памятью по всей компании, но не секретами.

Для российских команд, которые строят агентные системы в банках, ритейле и у ИТ-интеграторов, релиз Tencent интересен прежде всего тем, что это открытый проект: его можно развернуть на собственной инфраструктуре, не передавая корпоративный контекст внешним облакам — в условиях требований к локализации данных это немаловажно. Но вместе с кодом команды наследуют и нерешённый вопрос управления: механизм исправления, устаревания и разрешения конфликтов в общей памяти придётся проектировать самостоятельно. Судя по дискуссии вокруг запуска, именно этот слой — а не поиск и не хранение — станет следующим полем конкуренции в инфраструктуре ИИ-агентов.

Источник: VentureBeat