Все ноды/AI/Conversation Memory

Буферная память

Хранит полную историю диалога без ограничений. Подключается к AI Agent или LLM Response через link_memory. Область хранения: thread (между сообщениями), session (в рамках выполнения) или call (разово).

Буферная памятьS
Set historyMemory
Messages

Тип в графе: buffer_memory

ExecStateful

Можно включить ветку ошибки (expose_error_output) и обработать сбой отдельным путём.

Как попробовать

Агент, который помнит весь диалог

Память подключается к ИИ-агенту связью link_memory — собственного входа Run у неё нет.

Вход
LLM
Буферная памятьS
ИИ-агент
Выход
  • Исполнение + данные
  • LLM
  • Память
Нажмите «Скопировать ноды», откройте редактор и нажмите Ctrl+V на холсте.

Запускается сразу Перед запуском укажите: модель в ноде LLM.

Как применять

Буферная память отдаёт агенту весь диалог целиком: ничего не обрезается и не сжимается. Берите её, пока разговор короткий и предсказуемый — справочный бот на пару реплик, пошаговый опрос, отладка нового графа. Как только тред живёт долго, контекст растёт вместе с ним, и каждый следующий ход стоит дороже предыдущего: тогда переходите на Оконную память (фиксированный хвост) или Суммаризирующую (сжатие старого в текст).

Как это работает

Нода не исполняется сама по себе — входа Run у неё нет. Её «тянет» потребитель по связи link_memory, и такой потребитель один: порт Memory у ИИ-агента. У Ответа LLM входа памяти нет вовсе — там историю включает собственная опция «Использовать историю чата» или нода История чата.

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

Хранилище адресуется тройкой «id ноды + тред + тип памяти». Отсюда два следствия: две памяти в одном графе не видят историю друг друга, а замена буферной памяти на оконную на том же месте начинает историю заново — прежние сообщения остаются в базе, но уже под другим ключом.

Поле «Область» решает, сколько живёт запись: thread — история переживает сообщения чата и лежит в базе; session — только текущий запуск; call — пустая при каждом обращении.

Частые ошибки

  • Нода на холсте, но не связана с агентом. Сама по себе она не делает ничего: связь рисуется от выхода Memory к порту Memory агента.
  • Ждать историю там, где нет треда чата. При запуске по вебхуку, по расписанию или кнопкой «Запустить» треда нет, и thread-память привязывается к идентификатору запуска — то есть ведёт себя как session.
  • Путать память с историей чата. В панели чата видно то, что сохранил канал; память агента — отдельное хранилище со своим ключом. Удалили ноду или сменили ей id — агент забыл диалог, хотя переписка в панели осталась на месте.
  • Включать «Задать историю из входа» ради чтения. Порт messages_in перезаписывает хранилище целиком. Чтобы просто посмотреть текущее состояние, включите «Вывод сообщений».

Входы

ПортПроводДанныеПримечания
Set historymessages_inИсполнение + данныеexecute_datamessages

показывается, когда overwrite_from_input = true

Выходы

ПортПроводДанныеПримечания
MemoryoutputПамятьlink_memory
Messagesmessages_outДанныеdatamessages

показывается, когда expose_messages_output = true

Настройки

ПолеТипПо умолчаниюОписание
Вывод сообщенийexpose_messages_outputbooleanfalse

Показать data-порт вывода, который отдаёт текущие сохранённые сообщения.

Задать историю из входаoverwrite_from_inputbooleanfalse

Показать входной порт Messages (ED), срабатывание которого полностью перезаписывает сохранённую историю, плюс exec-выход «History set», срабатывающий после записи истории.

Областьscopestringthread

thread: сохраняется между сообщениями чата · session: живёт одно выполнение · call: заново каждый раз

Варианты: thread — Тред, call — Вызов, session — Сессия

Общие поля

Эти три поля есть у каждой ноды: платформа добавляет их сама, а не автор ноды.

  • expose_error_output — Если включено, показывает выход выполнения для подключения нод, которые запускаются при сбое этого шага.