Все ноды/AI/Conversation Memory
Буферная память
Хранит полную историю диалога без ограничений. Подключается к AI Agent или LLM Response через link_memory. Область хранения: thread (между сообщениями), session (в рамках выполнения) или call (разово).
Тип в графе: buffer_memory
ExecStateful
Можно включить ветку ошибки (expose_error_output) и обработать сбой отдельным путём.
Как попробовать
Агент, который помнит весь диалог
Память подключается к ИИ-агенту связью link_memory — собственного входа Run у неё нет.
- Исполнение + данные
- LLM
- Память
Запускается сразу Перед запуском укажите: модель в ноде LLM.
Как применять
Буферная память отдаёт агенту весь диалог целиком: ничего не обрезается и не сжимается. Берите её, пока разговор короткий и предсказуемый — справочный бот на пару реплик, пошаговый опрос, отладка нового графа. Как только тред живёт долго, контекст растёт вместе с ним, и каждый следующий ход стоит дороже предыдущего: тогда переходите на Оконную память (фиксированный хвост) или Суммаризирующую (сжатие старого в текст).
Как это работает
Нода не исполняется сама по себе — входа Run у неё нет. Её «тянет» потребитель по связи
link_memory, и такой потребитель один: порт Memory у ИИ-агента.
У Ответа LLM входа памяти нет вовсе — там историю включает
собственная опция «Использовать историю чата» или нода История чата.
После каждого хода агент дописывает в память весь раунд: сообщение пользователя, ответы модели, вызовы инструментов и их результаты. Поэтому «двадцать сообщений» у агента с инструментами — это часто два-три обмена репликами.
Хранилище адресуется тройкой «id ноды + тред + тип памяти». Отсюда два следствия: две памяти в одном графе не видят историю друг друга, а замена буферной памяти на оконную на том же месте начинает историю заново — прежние сообщения остаются в базе, но уже под другим ключом.
Поле «Область» решает, сколько живёт запись: thread — история переживает сообщения чата и
лежит в базе; session — только текущий запуск; call — пустая при каждом обращении.
Частые ошибки
- Нода на холсте, но не связана с агентом. Сама по себе она не делает ничего: связь рисуется от выхода Memory к порту Memory агента.
- Ждать историю там, где нет треда чата. При запуске по вебхуку, по расписанию или кнопкой
«Запустить» треда нет, и
thread-память привязывается к идентификатору запуска — то есть ведёт себя какsession. - Путать память с историей чата. В панели чата видно то, что сохранил канал; память агента — отдельное хранилище со своим ключом. Удалили ноду или сменили ей id — агент забыл диалог, хотя переписка в панели осталась на месте.
- Включать «Задать историю из входа» ради чтения. Порт
messages_inперезаписывает хранилище целиком. Чтобы просто посмотреть текущее состояние, включите «Вывод сообщений».
Входы
| Порт | Провод | Данные | Примечания |
|---|---|---|---|
Set historymessages_in | Исполнение + данныеexecute_data | messages | показывается, когда overwrite_from_input = true |
Выходы
| Порт | Провод | Данные | Примечания |
|---|---|---|---|
Memoryoutput | Памятьlink_memory | — | |
Messagesmessages_out | Данныеdata | messages | показывается, когда expose_messages_output = true |
Настройки
| Поле | Тип | По умолчанию | Описание |
|---|---|---|---|
Вывод сообщенийexpose_messages_output | boolean | false | Показать data-порт вывода, который отдаёт текущие сохранённые сообщения. |
Задать историю из входаoverwrite_from_input | boolean | false | Показать входной порт Messages (ED), срабатывание которого полностью перезаписывает сохранённую историю, плюс exec-выход «History set», срабатывающий после записи истории. |
Областьscope | string | thread | thread: сохраняется между сообщениями чата · session: живёт одно выполнение · call: заново каждый раз Варианты: |
Общие поля
Эти три поля есть у каждой ноды: платформа добавляет их сама, а не автор ноды.
expose_error_output— Если включено, показывает выход выполнения для подключения нод, которые запускаются при сбое этого шага.