Урок 2.5. Procedural Memory: навыки, политики и способы действия

Цель лекции

Показать, что агенту нужно помнить не только факты, события и состояние диалога, но и способы действия: какие процедуры применять, какие правила соблюдать, как пользоваться инструментами и какие рабочие привычки уже доказали свою полезность.

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

Читатель понимает отличие процедурной памяти от семантической и эпизодической, умеет распознавать навыки, политики и workflows как отдельный тип памяти и видит риски закрепления неправильных привычек.

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

В предыдущих лекциях мы разделили несколько типов памяти:

• working memory удерживает текущий контекст;
• session memory помогает не терять нить текущего диалога;
• episodic memory хранит события и опыт;
• semantic memory хранит факты, сущности и знания.

Но этих слоев недостаточно для долгоживущего агента. Агенту нужно не только знать, что в проекте есть файл guide/content_plan.md, но и понимать, как с ним работать: сначала сверять структуру, потом редактировать урок, затем проверять Markdown и только после этого кратко отчитываться пользователю.

Семантический факт отвечает на вопрос "что известно?". Процедурная память отвечает на вопрос "как действовать?".

Примеры процедурной памяти:

• перед редактированием кода прочитать соседние файлы и локальные conventions;
• для новых лекций использовать единый Markdown-шаблон;
• перед запуском команды с сетевым доступом запросить разрешение;
• не перезаписывать пользовательские черновики в intro/;
• при работе с pull request сначала смотреть diff, потом искать риски;
• для задач поиска документации использовать официальные источники;
• если тест упал из-за отсутствующей зависимости, не чинить это вслепую, а проверить окружение.

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

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

Procedural memory - это память навыков, политик, workflows и способов использования инструментов.

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

В простых системах procedural memory живет прямо в prompt: system instructions, developer instructions, policy blocks. В coding agents она часто хранится в файлах вроде AGENTS.md, CLAUDE.md, CONTRIBUTING.md, README.md, task templates и локальных инструкциях проекта. В более сложных системах она становится отдельным слоем: skill registry, workflow engine, policy service, tool-use planner или библиотека проверенных playbooks.

Ключевая особенность procedural memory: она влияет на порядок действий. Факт можно просто добавить в context. Процедура должна направлять поведение: что делать сначала, какие условия проверить, когда остановиться, какие действия запрещены, когда нужно спросить пользователя.

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

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

Отличие от semantic и episodic memory

Процедурную память легко спутать с семантической, потому что обе могут храниться в виде текста. Разница не в формате, а в функции.

Эпизод может стать источником процедуры. Если агент три раза ошибался из-за того, что не проверял локальные инструкции, reflection или consolidation процесс может сформулировать процедурное правило: "перед правками в новом репозитории прочитать AGENTS.md и соседние файлы".

Семантическая память тоже может поддерживать процедуру. Факт "в этом проекте нет build step" помогает не запускать несуществующую сборку. Но сама процедура звучит иначе: "для документационного репозитория проверять Markdown, структуру и TODO, а не искать runtime tests".

Fact vs skill vs policy

Один и тот же текст иногда можно записать по-разному. Это важно, потому что от типа записи зависит, как агент будет ее использовать.

Практический тест: если запись говорит, что истинно, это semantic memory. Если запись говорит, что нужно делать, это procedural memory. Если запись ограничивает допустимое поведение, это policy.

Где живет procedural memory

Процедурная память может быть распределена по нескольким слоям системы.

System и developer instructions

Самый сильный и прямой слой procedural memory - системные и developer-инструкции.

Они задают базовое поведение агента:

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

Такая память обычно не "выучена" агентом. Она задана разработчиком системы и имеет высокий приоритет. Ее задача - обеспечить надежные рамки поведения.

Project instruction files

В coding и writing agents procedural memory часто хранится в файлах проекта:

• AGENTS.md;
• CLAUDE.md;
• SOUL.md;
• CONTRIBUTING.md;
• README.md;
• .github/pull_request_template.md;
• архитектурные ADR;
• docs/ с internal playbooks;
• TODO-файлы и планы курса.

Эти документы превращают локальные правила проекта в доступную агенту память. Например, AGENTS.md может сказать: "не добавляй зависимости без обсуждения", "новые лекции храни в modules/", "сначала обновляй guide/content_plan.md при структурных изменениях".

Для агента это не просто справочная информация. Это procedural context: он определяет порядок и ограничения работы.

Policy files

Policy files описывают правила, которые важнее удобства и часто важнее learned preferences.

Примеры policy:

• нельзя раскрывать секреты и credentials;
• нельзя удалять пользовательские данные без явного запроса;
• нельзя выполнять destructive actions без подтверждения;
• нельзя давать медицинский диагноз вместо рекомендации обратиться к специалисту;
• нельзя изменять область задачи без согласия пользователя.

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

Skill libraries

Skill library - это набор процедур, которые агент может выбирать под задачу.

Примеры навыков:

• написать техническую Markdown-лекцию;
• провести code review;
• создать changelog;
• подготовить миграционный план;
• отладить failing test;
• обновить API documentation;
• собрать исследовательское резюме по официальным источникам.

Навык обычно содержит:

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

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

Workflow memory

Workflow memory описывает последовательность действий для типовых задач.

Например, workflow для написания лекции может выглядеть так:

1. Прочитать план урока.
2. Прочитать соседнюю лекцию для стиля и перехода.
3. Проверить content plan и writing todo.
4. Расширить план в полноценную структуру.
5. Добавить определения, схему, пример, ошибки, резюме и вопросы.
6. Проверить Markdown и отсутствие лишних структурных изменений.
7. Кратко сообщить, что изменено.

Это procedural memory, потому что она определяет порядок работы, а не просто хранит знания о курсе.

Tool usage memory

Агент с инструментами должен помнить не только доступные tool names, но и правила их применения.

Примеры:

• использовать rg для поиска по репозиторию;
• читать файлы перед редактированием;
• запускать targeted tests после узких изменений;
• не вызывать внешнюю сеть без необходимости;
• не использовать destructive git-команды без явного запроса;
• применять structured parser вместо ad hoc string manipulation, если это надежнее;
• проверять результат команды, а не считать ее успешной по намерению.

Tool usage memory особенно важна, потому что ошибки здесь имеют внешний эффект: агент может изменить файлы, запустить дорогостоящую операцию, раскрыть данные или сломать рабочее окружение.

Схема procedural memory в агенте

Схема показывает важный момент: procedural memory должна попадать в контекст до действия, а не после него. Если агент вспоминает правила только в финальном отчете, это уже не управление поведением.

Также видно, что procedural memory может обновляться после выполнения задачи. Но обновление должно быть осторожным: не каждый удачный или неудачный эпизод должен становиться новой процедурой.

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

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

id: proc_writing_lecture_001
type: workflow
name: write_markdown_lecture
scope:
  project: ai-agent-memory-guide
applies_when:
  - user asks to write or expand a lesson file
steps:
  - read target lesson plan
  - read adjacent lesson for style and continuity
  - preserve title, module number, and learning outcome
  - add terms, diagram, example, failure modes, summary, self-check questions
constraints:
  - write primarily in Russian
  - keep the guide broad and conceptual
  - do not overwrite drafts in intro/
source:
  kind: project_instruction
  reference: AGENTS.md
confidence: high
status: active
last_used_at: 2026-08-07

Это не обязательная схема базы данных. Это mental model. Хорошая процедурная запись содержит scope, условия применения, шаги, ограничения, источник и статус.

Без applies_when агент будет применять процедуру слишком широко. Без constraints он может выполнить шаги, но нарушить важные правила. Без source трудно понять, это жесткое требование проекта или эвристика, возникшая из одного эпизода.

Hard policy и learned preference

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

Hard policy - это правило, которое агент обязан соблюдать. Например: не раскрывать секреты, не удалять файлы без явного запроса, не выполнять опасные команды без подтверждения.

Learned preference - это знание о том, как пользователь обычно предпочитает работать. Например: краткие финальные ответы, русский язык для лекций, минимум лишних объяснений.

Learned procedure - это полезная привычка, которую агент вывел из опыта. Например: "после изменения Markdown-лекции проверить, что заголовки идут в логичном порядке".

Эти типы записей имеют разный приоритет:

Для надежного агента важно не только помнить правила, но и понимать их вес.

Spec-driven development как процедурная память проекта

В проектах procedural memory часто живет не в одном "memory store", а в спецификациях.

Примеры:

• content plan определяет структуру курса;
• TODO описывает порядок работ;
• acceptance criteria говорят, когда задача считается завершенной;
• ADR фиксируют принятые архитектурные решения;
• style guide задает оформление;
• test plan говорит, что проверять после изменений;
• release checklist задает порядок публикации.

Такой подход можно назвать spec-driven procedural memory: будущие действия агента направляются документами, которые описывают намерение проекта.

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

Важно: спецификация не всегда является истиной о текущем состоянии. Она может устареть. Поэтому агент должен уметь различать:

• "это правило проекта";
• "это план, который еще не выполнен";
• "это старая спецификация, которую нужно проверить";
• "это желание пользователя в текущей задаче".

Мини-кейс: coding workflow

Представим coding agent, который получил задачу: "исправь баг в расчете скидки".

Плохой агент действует так:

1. Открывает первый похожий файл.
2. Меняет формулу.
3. Запускает случайную команду.
4. Отвечает, что все готово.

У такого агента может быть semantic memory о проекте: язык, framework, структура директорий. Но без procedural memory он не соблюдает инженерный процесс.

Более зрелый workflow:

1. Прочитать локальные инструкции проекта.
2. Найти код расчета скидки и соседние тесты.
3. Понять текущую модель: типы скидок, округление, edge cases.
4. Воспроизвести или локализовать failing case.
5. Внести минимальное изменение.
6. Добавить или обновить focused test.
7. Запустить релевантные тесты.
8. Проверить diff на случайные изменения.
9. Сообщить пользователю, что изменено и что проверено.

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

Если после задачи выяснилось, что баг возник из-за специфического правила округления, это может породить разные записи:

• episodic memory: "в задаче от 2026-08-07 ошибка была связана с округлением скидки";
• semantic memory: "скидки в проекте округляются до целых центов после применения налога";
• procedural memory: "при изменениях скидок проверять тесты на округление, налоги и комбинированные промокоды";
• reflection memory: "агент пропустил edge case, потому что проверил только happy path".

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

Мини-кейс: writing workflow

Для writing agent процедурная память выглядит иначе.

Задача: "напиши лекцию по procedural memory".

Полезные процедуры:

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

Здесь нет компиляции или unit tests, но есть своя проверка качества: структура, связность, терминология, отсутствие лишней реализации, соответствие стилю курса.

Процедурная память всегда зависит от домена. Для coding agent важны diff, tests и tools. Для writing agent - структура, голос, план и редактура. Для support agent - tone policy, escalation workflow, customer status и safety constraints.

Как procedural memory выбирается в момент задачи

Агенту редко нужна вся procedural memory сразу. Как и semantic memory, ее нужно извлекать по контексту.

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

• тип задачи: writing, coding, support, research, planning;
• проект и его локальные инструкции;
• доступные инструменты;
• риск действия;
• user intent;
• stage текущего workflow;
• authority source: system, project, user, learned;
• свежесть инструкции;
• конфликт с другими правилами.

Пример: пользователь просит "проверь этот PR". Агенту нужны навыки code review, правила работы с git diff, policy по безопасности и формат ответа для review. Ему не нужны навыки написания лекций.

Процедуры должны быть маленькими и компонуемыми. Большой универсальный playbook быстро становится шумным: он занимает context window, конфликтует сам с собой и мешает агенту адаптироваться.

Обновление procedural memory

Процедурную память можно обновлять из нескольких источников:

• явная инструкция пользователя;
• изменение project instruction files;
• новый policy document;
• повторяющийся успешный workflow;
• post-task reflection;
• failure analysis;
• изменение доступных инструментов.

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

Перед сохранением новой процедуры полезны вопросы:

• Это правило должно применяться в будущих задачах?
• У него понятный scope?
• Есть ли надежный source?
• Это жесткая политика или мягкая эвристика?
• Есть ли условия, когда процедура не применима?
• Не конфликтует ли она с более приоритетными правилами?
• Можно ли сформулировать ее коротко и проверяемо?

Хорошая procedural memory похожа на аккуратную библиотеку инструкций, а не на дневник всех решений агента.

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

Процедурная память усиливает агента, но может закреплять плохое поведение.

Закрепление неправильных привычек

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

Пример:

"Для всех frontend задач достаточно изменить CSS и не запускать приложение."

Один раз это могло быть приемлемо. Как постоянная процедура это опасно.

Конфликт инструкций

Процедуры могут противоречить друг другу:

Project rule:
- Always run full test suite before final response.

User message:
- Do not run tests now, just patch the typo.

Система должна понимать приоритеты, scope и намерение. Иногда нужно выполнить просьбу пользователя и явно сказать, что тесты не запускались. Иногда project policy сильнее.

Процедурный overfitting

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

Например, использовать heavy research workflow для простого исправления опечатки. Или запускать длинный debugging playbook там, где достаточно прочитать одну строку.

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

Устаревшие инструменты

Tool usage memory устаревает, когда меняется стек:

• проект переходит с Jest на Vitest;
• команда заменяет Jira на Linear;
• CLI меняет флаги;
• API получает новую версию;
• репозиторий переезжает в monorepo.

Поэтому процедуры должны иметь source, дату подтверждения и признаки устаревания.

Policy bypass через "выученную" процедуру

Learned procedure никогда не должна обходить hard policy.

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

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

Ошибка 1: считать procedural memory просто длинным prompt.

Prompt может содержать процедуры, но сама идея шире: workflows, skills, policies, project files, tool rules и learned playbooks.

Ошибка 2: смешивать факты и процедуры.

"Проект использует Markdown" - факт. "При изменении лекции проверить структуру Markdown" - процедура.

Ошибка 3: не различать hard policy и preference.

Предпочтение можно адаптировать. Политику нужно соблюдать.

Ошибка 4: сохранять слишком общие правила из одного эпизода.

Одна удачная стратегия не всегда является универсальным навыком.

Ошибка 5: не задавать scope.

Workflow для одного проекта может быть вреден в другом. Процедурная память без scope быстро становится источником ошибок.

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

Процедуры, связанные с CLI, тестами, деплоем и API, требуют регулярного подтверждения.

Ошибка 7: извлекать слишком много процедур.

Если в context assembly попали все playbooks сразу, агент получает шум вместо помощи.

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

Procedural memory - это память о том, как агент должен действовать: навыки, workflows, policies, project rules, tool usage patterns и переиспользуемые playbooks.

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

Хорошая procedural memory имеет scope, source, условия применения, приоритет и ограничения. Она помогает агенту действовать последовательно, но не должна закреплять случайные ошибки, устаревшие привычки или конфликтующие инструкции.

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

1. Чем procedural memory отличается от semantic memory?
2. Почему tool usage rules относятся к procedural memory?
3. В чем разница между hard policy, workflow и learned preference?
4. Какие риски возникают, если сохранять процедуру после одного удачного эпизода?
5. Почему procedural memory должна иметь scope и source?

Что дальше

В следующей лекции мы разберем Reflection Memory: память самоанализа, ошибок и lessons learned. Она находится рядом с procedural memory, но решает другую задачу: не сразу задает workflow, а помогает агенту превращать опыт в проверяемые выводы для будущего поведения.