Урок 2.6. Reflection Memory: самоанализ и уроки

Цель лекции

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

Ожидаемый результат

Читатель понимает, как self-improvement связан с памятью, чем reflection memory отличается от episodic, semantic и procedural memory, почему нельзя сохранять скрытые рассуждения как память и где проходят границы безопасного самоанализа агента.

Зачем это нужно

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

Reflection memory нужна для другого поведения: после важного события агент делает короткий анализ результата и сохраняет проверяемый урок.

Например:

• "В прошлой задаче тесты упали, потому что агент изменил shared helper без targeted regression test."
• "При написании лекций курса полезно сначала читать соседний урок, иначе нарушается стиль."
• "Для задач с внешней документацией старые знания модели недостаточны, нужно проверять официальный источник."
• "Если пользователь просит только обзор, не начинать масштабную реализацию без явного запроса."

Это не просто история событий. История говорит, что произошло. Reflection пытается ответить: что из этого следует для будущего поведения?

Reflection memory особенно полезна в долгих агентских системах:

• coding agents, которые исправляют ошибки и учатся не ломать проект повторно;
• research agents, которые улучшают стратегию поиска источников;
• support agents, которые анализируют неудачные эскалации;
• personal assistants, которые уточняют рабочие привычки;
• multi-agent systems, где агенты делятся lessons learned после выполнения задач.

Но у reflection есть риск. Если сохранять каждую мысль, гипотезу или self-critique как память, система быстро станет шумной и может начать уверенно применять ошибочные выводы. Поэтому reflection memory должна быть короткой, проверяемой и привязанной к результату.

Основная идея

Reflection memory - это память выводов агента о собственных действиях, результатах, ошибках и стратегиях.

Она отвечает на вопрос: "какой урок стоит вынести из прошлого опыта?"

Reflection memory находится между episodic и procedural memory:

• episodic memory хранит событие;
• reflection memory объясняет, какой вывод из него можно сделать;
• procedural memory превращает устойчивый вывод в правило или workflow.

Не каждый reflection должен становиться процедурой. Иногда это просто предупреждение: "в похожих задачах проверить X". Иногда это hypothesis: "возможно, этот подход плохо работает для больших файлов". Иногда это post-task note, который будет использован только при будущей диагностике.

Качественная reflection memory не сохраняет длинные рассуждения. Она сохраняет compact lesson learned: что было сделано, какой результат получился, какая причина вероятна, что проверять или менять в следующий раз, насколько надежен вывод.

Ключевые термины

Отличие от других типов памяти

Reflection memory легко спутать с другими слоями, потому что она часто возникает из тех же событий.

Reflection memory не заменяет эти слои. Она связывает их.

Эпизод дает материал: действие, контекст, результат. Reflection выделяет причинно-следственный урок. Procedural memory может затем превратить повторяемый урок в правило.

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

Reflection vs chain-of-thought

Это одна из самых важных границ.

Reflection memory не должна быть архивом скрытых рассуждений модели.

Chain-of-thought - это внутренний процесс рассуждения модели при генерации ответа. Он может быть длинным, неполным, содержать промежуточные гипотезы, отброшенные варианты и неустойчивые ассоциации. Сохранять его как память вредно по нескольким причинам:

• он не является надежным источником фактов;
• он может содержать ошибочные промежуточные выводы;
• он часто слишком подробный и шумный;
• он может раскрывать внутренние reasoning traces, которые не предназначены для хранения;
• он плохо отделяет наблюдение от интерпретации;
• он может превратиться в self-reinforcing noise.

Reflection memory должна хранить не скрытый ход мыслей, а проверяемое резюме результата.

Плохая запись:

Я сначала подумал, что проблема в A, потом решил, что в B, потом вспомнил C,
потом сомневался между D и E, но выбрал E, потому что...

Хорошая запись:

Lesson:
When a failing test appears after changing a shared helper, inspect dependent modules
before assuming the failure is local to the edited file.

Evidence:
In task 2026-08-07, the edited helper affected two downstream tests.

Applicability:
Coding tasks involving shared utilities or cross-module helpers.

Разница принципиальная. Reflection memory сохраняет сжатый, проверяемый урок, а не поток размышлений.

Когда reflection полезна

Reflection нужна не после каждого действия. Если агент будет рефлексировать после каждой строки текста или каждого tool call, память быстро заполнится шумом.

Полезные моменты для reflection:

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

Reflection особенно ценна, когда есть observable outcome. Например, тесты прошли или упали, пользователь принял или отклонил ответ, tool вернул ошибку, источник оказался устаревшим.

Без результата reflection часто превращается в speculation. Такие записи можно сохранять только с низкой confidence и понятным scope, а чаще лучше не сохранять вовсе.

Когда reflection добавляет шум

Reflection вредна, если она:

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

Плохие lessons learned:

- Нужно быть внимательнее.
- Всегда запускать все тесты.
- Никогда не менять shared files.
- Пользователь любит подробности.
- RAG всегда лучше памяти модели.

Такие записи слишком общие. Они либо бесполезны, либо вредны. Хороший lesson learned указывает контекст, причину, действие и границы применимости.

Схема reflection loop

Главная точка в схеме - Worth reflecting?. Reflection memory должна быть selective. Агент не обязан сохранять урок после каждого шага.

Вторая важная точка - Validate scope and evidence. Урок должен быть связан с наблюдаемым результатом и иметь границы применения.

Как выглядит reflection record

Концептуальная запись reflection может выглядеть так:

id: refl_coding_001
type: reflection
summary: Shared helper changes require dependent test checks.
trigger:
  kind: failed_test
  task_id: task_2026_08_07_discount_bug
evidence:
  - changed file: src/pricing/discount_helper.ts
  - failing tests: pricing_rules.test.ts, invoice_totals.test.ts
lesson:
  When editing shared pricing helpers, run focused tests for pricing rules and invoice totals.
applicability:
  project: billing-service
  task_type: coding
  file_pattern: shared pricing helper
confidence: medium
status: active
created_at: 2026-08-07T14:20:00+03:00
review_after:
  after_uses: 3
  if_conflict_detected: true

Это не требование к конкретной базе данных. Это mental model: reflection должна быть не просто фразой "надо быть аккуратнее", а записью с trigger, evidence, lesson, applicability и confidence.

В простых системах reflection может храниться как Markdown-блок или JSON-запись. В более сложных - как отдельный тип MemoryRecord, связанный с task logs, test results, user feedback и procedural memory.

Post-task reflection

Post-task reflection выполняется после завершения задачи или важной попытки. Она отвечает на несколько практических вопросов:

• что было целью;
• что сделал агент;
• какой результат получился;
• что сработало;
• что не сработало;
• какая причина ошибки или успеха наиболее вероятна;
• что стоит проверить в следующий раз;
• нужно ли обновить semantic или procedural memory.

Пример post-task reflection для writing agent:

Task:
Write lesson 2.5 about procedural memory.

Outcome:
Lecture created successfully, but the first draft forgot to preserve SOUL.md from the lesson plan.

Lesson:
When expanding a lesson plan, check that every required bullet from the source plan appears
in the final lecture or is intentionally omitted.

Applicability:
Course-writing tasks based on short lesson plans.

Confidence:
High, because the issue was observed directly in the draft review.

Такой урок можно использовать в будущем при написании лекций. Он не раскрывает скрытый ход рассуждений. Он фиксирует наблюдаемую проблему и практический вывод.

Failure analysis

Failure analysis - один из самых полезных источников reflection memory.

В агентских системах ошибки часто повторяются:

• агент не проверил локальные инструкции;
• извлек нерелевантную память;
• доверился устаревшему факту;
• не запустил нужный тест;
• неправильно понял scope задачи;
• перепутал user preference с hard policy;
• применил старый workflow к новой ситуации;
• сделал слишком много без подтверждения;
• использовал RAG без проверки freshness.

Хороший failure analysis не должен искать виноватого. Он должен найти control point: где в системе можно было заметить риск и изменить действие.

Плохой разбор:

Ошибка произошла, потому что агент был невнимателен.

Полезный разбор:

Ошибка произошла после изменения shared helper. Агент запустил только тест измененного модуля,
но helper использовался еще в invoice flow. В будущем для shared helpers нужно искать dependents
или запускать focused tests по связанным доменам.

Reflection memory должна повышать качество будущего plan selection, а не просто фиксировать сожаление.

Lessons learned

Lesson learned - это короткий вывод, который можно применить в будущей похожей задаче.

Хороший lesson learned обычно содержит:

• контекст: где урок применим;
• сигнал: по какому признаку его извлекать;
• действие: что делать иначе;
• evidence: почему мы считаем урок надежным;
• confidence: насколько сильно ему доверять;
• expiration или review rule, если урок может устареть.

Примеры:

Lesson learned должен быть actionable. Если из записи нельзя понять, что изменить в будущем поведении, это не reflection memory, а заметка без операционной ценности.

Reflection как источник процедурной памяти

Reflection memory часто является промежуточным слоем на пути к procedural memory.

Сначала появляется эпизод:

Task failed because the agent edited a shared helper and ran too narrow a test set.

Затем reflection:

The failure was caused by missing downstream impact analysis.

После повторного подтверждения это может стать процедурой:

When editing shared helpers, inspect imports or run tests for dependent modules.

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

• повторялся ли pattern;
• есть ли reliable evidence;
• не слишком ли широкий вывод;
• не конфликтует ли он с project policy;
• применим ли он в конкретном scope;
• можно ли сформулировать его как короткий workflow rule.

Reflection - это черновик улучшения. Procedural memory - уже более сильное правило поведения.

Reflection и semantic memory

Иногда reflection порождает semantic memory.

Например, агент провел несколько задач в одном проекте и заметил:

Все лекции Module 02 используют один стиль: короткое введение, таблица терминов,
схема, мини-кейс, ошибки, резюме и вопросы.

Это может стать project fact:

Module 02 lectures follow a consistent explanatory Markdown structure.

Но нужно быть осторожным. Reflection может содержать интерпретацию, а semantic memory должна хранить проверяемое знание. Если вывод основан на одном наблюдении, лучше оставить его reflection note или сохранить с низкой confidence.

Проверка применимости старых уроков

Старый lesson learned не всегда подходит к новой задаче.

Пример:

Old reflection:
For frontend tasks, run the app and inspect screenshots before finishing.

New task:
Fix a typo in a Markdown-only documentation file.

Если агент применит старый урок буквально, он начнет искать dev server там, где его нет. Поэтому reflection retrieval должен учитывать applicability.

Перед применением старого урока агенту полезно проверить:

• совпадает ли тип задачи;
• совпадает ли проект или domain;
• актуален ли toolchain;
• не изменились ли инструкции;
• есть ли более приоритетная policy;
• не является ли урок слишком общим;
• подтверждался ли он в нескольких задачах.

Reflection memory не должна превращаться в набор автоматических привычек без контекста.

Reflection retrieval

Reflection memory полезна только тогда, когда нужный урок вспоминается в нужный момент.

Retrieval может учитывать:

• task type: coding, writing, research, support;
• failure mode: тесты, неверный источник, scope creep, конфликт инструкций;
• project или organization scope;
• tool или workflow stage;
• similarity к текущей задаче;
• recency;
• confidence;
• number of successful reuses;
• наличие user feedback;
• conflict with current instructions.

Пример: агент получает задачу "обнови урок из короткого плана". Релевантный reflection:

When expanding lesson plans, verify that each bullet from the source plan is represented
in the final lecture or intentionally omitted.

Нерелевантный reflection:

For frontend tasks, check Playwright screenshots on mobile and desktop.

Оба урока могут быть полезны в своих областях, но context assembly должен выбрать только первый.

Как не превратить reflection в шум

Для reflection memory полезны строгие write rules.

Записывать reflection стоит, если:

• был наблюдаемый outcome;
• результат неожиданен или важен;
• вывод может изменить будущие действия;
• есть понятный scope;
• lesson можно сформулировать коротко;
• запись не дублирует существующее правило;
• риск повторения достаточно высок.

Не стоит записывать reflection, если:

• вывод очевиден и неоперационален;
• нет evidence;
• это временное настроение текущей сессии;
• запись раскрывает скрытые рассуждения;
• урок слишком общий;
• он противоречит hard policy;
• он относится к чувствительным данным без необходимости.

Хорошая система может иметь отдельный reflection buffer: временное место для сырых выводов. Только часть из них проходит consolidation в долговременную память.

Мини-кейс: coding agent после failed test

Сценарий:

User asks:
"Fix the discount calculation bug."

Agent changes:
src/pricing/discount_helper.ts

Observed outcome:
pricing_rules.test.ts passes, but invoice_totals.test.ts fails.

Эпизодическая память:

At 2026-08-07, after changing discount_helper.ts, invoice_totals.test.ts failed.

Reflection memory:

Lesson:
Discount helper changes can affect invoice totals outside the pricing_rules test suite.

Evidence:
invoice_totals.test.ts failed after a helper change that looked local to pricing.

Future check:
For shared pricing helpers, include invoice total tests or inspect downstream imports.

Confidence:
Medium.

Procedural memory после повторного подтверждения:

When editing shared pricing helpers, run focused tests for pricing rules and invoice totals.

Видно, как один опыт проходит через несколько слоев. Reflection не обязана сразу становиться жестким workflow rule, но она делает будущий debugging умнее.

Мини-кейс: research agent и устаревший источник

Сценарий:

User asks:
"What is the current API behavior?"

Agent answers from old model knowledge.

User corrects:
"This changed last month. Check the docs."

Эпизодическая память:

User corrected the answer because API behavior had changed recently.

Reflection memory:

Lesson:
For questions about current API behavior, use official documentation instead of relying
on model memory.

Evidence:
User correction indicated that the remembered behavior was outdated.

Applicability:
Time-sensitive product, API, SDK, policy, pricing, and model capability questions.

Эта reflection может поддержать future retrieval policy: если вопрос зависит от свежести, агент должен проверить источник.

Риски reflection memory

Reflection memory опасна не потому, что самоанализ плох, а потому, что плохие выводы могут начать управлять будущим поведением.

Ошибочные причинные выводы

Агент может неправильно объяснить, почему что-то произошло.

Например, тест упал из-за неправильного fixture, а агент решил, что причина в архитектуре модуля. Если сохранить такой вывод, future retrieval будет подталкивать агента к неверным действиям.

Поэтому reflection должна ссылаться на evidence и иметь confidence.

Self-confirming loop

Если агент сохраняет свои предположения, а потом извлекает их как подтверждение, возникает self-confirming loop.

Hypothesis -> saved as reflection -> retrieved as evidence -> stronger belief

Чтобы этого избежать, нужно отделять observed outcome от interpretation и не повышать confidence без внешнего подтверждения.

Слишком общие уроки

"Всегда делать X" почти всегда опасно.

Reflection должна быть scoped:

• в каком проекте;
• для какого типа задач;
• при каком сигнале;
• с каким инструментом;
• при каком уровне риска.

Сохранение скрытых рассуждений

Сырые reasoning traces не являются хорошей памятью. Они шумные, длинные и могут содержать промежуточные ошибки.

Лучше сохранять короткий externalized lesson: результат, evidence, вывод, применимость.

Конфликт с политиками

Reflection может предложить удобную, но недопустимую стратегию.

Например:

Lesson:
To save time, skip permission requests for common external commands.

Такой урок должен быть отклонен, потому что learned reflection не может обходить hard policy.

Privacy и sensitive data

Reflection не должна сохранять лишние личные или чувствительные сведения.

Если пользователь в конкретной задаче упомянул приватный контекст, агент не должен делать обобщенный lesson вроде "пользователь всегда работает с такими-то медицинскими данными", если это не нужно, не разрешено и не безопасно.

Типичные ошибки

Ошибка 1: сохранять chain-of-thought как reflection memory.

Reflection должна быть итоговым уроком, а не архивом скрытых рассуждений.

Ошибка 2: делать вывод без evidence.

Если нет наблюдаемого результата, reflection должна быть либо временной гипотезой, либо не сохраняться.

Ошибка 3: превращать один эпизод в универсальное правило.

Один случай может дать lesson, но не обязательно policy или workflow.

Ошибка 4: не задавать applicability.

Старый урок без scope будет вспоминаться в неправильных задачах.

Ошибка 5: дублировать procedural memory.

Если правило уже есть в workflow, reflection должна либо ссылаться на него, либо не создавать копию.

Ошибка 6: не пересматривать старые уроки.

Reflection может устаревать вместе с проектом, инструментами и пользовательскими предпочтениями.

Ошибка 7: сохранять самокритику ради самокритики.

Self-critique полезна только тогда, когда меняет будущие действия или качество результата.

Краткое резюме

Reflection memory хранит lessons learned: короткие, проверяемые выводы агента о собственных действиях, ошибках, успехах и стратегиях.

Она отличается от episodic memory тем, что не просто фиксирует событие, а формулирует урок. Она отличается от procedural memory тем, что не всегда является готовым правилом поведения. Она отличается от semantic memory тем, что хранит не устойчивый факт о мире, а вывод из опыта агента.

Главная граница: reflection memory не должна сохранять chain-of-thought. Надежная запись содержит outcome, evidence, lesson, applicability, confidence и правило пересмотра. Такая память помогает агенту учиться, но не превращает систему в склад непроверенных рассуждений.

Вопросы для самопроверки

1. Чем reflection memory отличается от episodic memory?
2. Почему нельзя сохранять chain-of-thought как долговременную память?
3. Что должно быть в хорошем lesson learned?
4. Когда reflection стоит превратить в procedural memory, а когда оставить как заметку?
5. Какие риски возникают, если агент сохраняет ошибочные self-reflection выводы?

Что дальше

В следующей лекции мы перейдем к World Memory и RAG: внешним знаниям агента. После внутренних слоев памяти - событий, фактов, процедур и reflection - важно понять, как агент подключает документы, базы знаний, репозитории и другие источники, не путая retrieval по внешним данным с собственной памятью.