Перейти к содержанию

Часть III. Память и знания

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

Короткий маршрут по этой части

Если тебе нужен быстрый проход, иди так:

  • Глава 5: понять, почему память вообще опасна;
  • Глава 6: развести типы памяти по ролям;
  • Глава 7: решить, как эти записи безопасно возвращаются обратно в подсказку.

Вместе эти три шага дают слой памяти, который можно обсуждать как инженерную систему, а не как абстрактное “добавим памяти”.

Маршруты канонических сценариев

В слое памяти и поиска три канонических сценария проверяют разные риски. Разбор обращений поддержки проверяет временное состояние тикета, контекст дубля и поиск по утвержденным инструкциям. Внутренний ассистент знаний проверяет привязку к источникам, окно свежести, границу арендатора и происхождение записей памяти. Координация инцидентов проверяет шкалу времени инцидента, сводки передачи владельцу, статус эскалации и уроки после инцидента.

Обложка части про память

Что решает эта часть

Это правильный шаг, но именно здесь многие системы начинают тихо накапливать долг. Тот же агент поддержки легко превращает полезное состояние в постоянный источник ошибок, если память не спроектирована как управляемый слой.

  • сохраняют в память все подряд;
  • не различают профильную память и рабочий контекст;
  • тащат недоверенный текст обратно в подсказку без проверки;
  • пишут в память прямо в горячем контуре, где ошибка мгновенно становится постоянной.

В этой части мы разберем, как сделать память полезной, но не превратить ее в долговременный источник инъекций, утечек и странного поведения.

В этой части

Куда она ведет дальше

После этой части естественный следующий шаг — Часть IV: как тот же агент уже не только помнит контекст, но и действует через контролируемые инструменты, песочницу и контракты исполнения.