Цель лекции
Показать, как память используется для координации нескольких агентов.
Ожидаемый результат
Читатель понимает, как память поддерживает координацию в multi-agent system: где нужен shared workspace, где приватная память роли, зачем нужен event log и почему conflict resolution становится частью memory design.
Зачем это нужно
В single-agent системе память отвечает на вопрос:
Что агент должен знать, чтобы лучше выполнить задачу?
В multi-agent системе появляется новый вопрос:
Что должны знать разные агенты друг о друге, чтобы не мешать работе?
Несколько агентов могут:
- делить одну задачу;
- выполнять разные роли;
- работать параллельно;
- передавать артефакты;
- спорить о решении;
- использовать общие источники;
- записывать результаты в один workspace.
Если shared memory не спроектирована, агенты начинают дублировать работу, перезаписывать решения, распространять ошибки и спорить с устаревшим контекстом.
Основная идея
Multi-agent memory должна разделять общее рабочее состояние, приватную память ролей и журнал событий, иначе агенты начнут мешать друг другу.
В такой архитектуре нужны минимум три слоя:
- shared workspace: текущее общее состояние задачи;
- private role memory: знания и conventions конкретных агентов;
- event log: append-only история действий, решений и наблюдений.
Поверх этого нужны policies: кто может читать, кто может писать, кто может подтверждать, кто может отменять.
Ключевые термины
| Термин | Короткое определение |
|---|---|
Multi-agent system |
Система, где несколько агентов совместно выполняют задачу или workflow. |
Shared workspace |
Общее пространство артефактов, задач, статусов и решений. |
Blackboard |
Паттерн общей доски, куда агенты пишут промежуточные результаты. |
Private memory |
Память конкретного агента или роли, не всегда доступная всем. |
Coordination memory |
Память о том, кто что делает, что завершено, что заблокировано. |
Event log |
Последовательный журнал действий и решений как источник истины. |
Conflict resolution |
Правила разрешения противоречивых записей, решений и действий. |
Memory governance |
Политики чтения, записи, владения, удаления и подтверждения памяти. |
Архитектура multi-agent memory
Shared workspace показывает текущее рабочее состояние. Event log объясняет, как это состояние возникло. Private memories помогают ролям работать эффективно, не загрязняя общий контекст.
Shared workspace и blackboard
Shared workspace хранит то, что всем участникам нужно видеть.
Примеры:
- goal;
- task breakdown;
- current plan;
- artifacts;
- open questions;
- blockers;
- decisions;
- constraints;
- status;
- ownership;
- final deliverables.
Blackboard pattern работает так:
Planner writes task plan.
Researcher adds sources.
Writer drafts section.
Reviewer adds findings.
Planner updates status.
Преимущество: агенты не должны держать всю историю в prompt. Они читают structured shared state.
Риск: если писать туда все подряд, workspace превращается в шум. Нужны schemas, ownership и cleanup.
Приватная память ролей
Не вся память должна быть общей.
Private memory может хранить:
- role-specific heuristics;
- прошлые решения конкретного агента;
- specialized checklists;
- tool preferences;
- internal notes;
- draft reasoning artifacts;
- quality rubrics.
Пример:
Reviewer private memory:
- check unsupported claims
- check stale sources
- check privacy issues
- prefer concise findings with file references
Эта память полезна reviewer agent, но не обязана загрязнять shared workspace.
Важно: private memory не должна обходить global policy. Если агент нашел sensitive data, он не может спрятать ее в private memory без правил.
Coordination memory
Coordination memory отвечает на вопросы:
- кто что делает;
- что уже завершено;
- что заблокировано;
- кто владеет артефактом;
- какое решение принято;
- какая версия актуальна;
- какие conflicts открыты;
- что нужно проверить дальше.
Пример structured state:
task_id: module_10
owner: writer_agent
status: in_progress
completed:
- lesson_10_01
- lesson_10_02
blocked: []
next:
- lesson_10_03
- lesson_10_04
Без coordination memory агенты легко начинают параллельно править один и тот же файл или повторять уже сделанную работу.
Event log как источник истины
Event log хранит события:
- task created;
- agent assigned;
- source read;
- tool called;
- artifact created;
- decision made;
- conflict detected;
- review approved;
- memory updated;
- task completed.
Пример:
10:00 Planner: created outline
10:03 Researcher: added source summary
10:10 Writer: drafted section A
10:15 Reviewer: found unsupported claim
10:18 Writer: revised section A
10:20 Supervisor: approved final
Почему event log важен:
- можно восстановить историю;
- можно отладить ошибку;
- можно replay workflow;
- можно строить summaries;
- можно проверять accountability;
- можно разрешать conflicts по timestamps and authority.
Event log особенно полезен, когда agents работают асинхронно.
Conflict resolution
В multi-agent memory conflicts неизбежны.
Типы конфликтов:
- два агента изменили один artifact;
- один агент считает задачу done, другой нашел ошибку;
- sources противоречат друг другу;
- role memories дают разные recommendations;
- current user instruction противоречит старому plan;
- automated decision требует human approval.
Нужны правила:
| Конфликт | Возможное правило |
|---|---|
| User instruction vs agent plan | User instruction wins. |
| Reviewer finding vs writer draft | Draft blocked until resolved. |
| Two simultaneous writes | Versioning + merge or lock. |
| Source conflict | Prefer authoritative/current source, mark uncertainty. |
| Policy conflict | Higher-priority policy wins. |
| High-risk action | Escalate to human. |
Conflict resolution должен быть явной частью memory design, а не случайной импровизацией модели.
Memory governance между агентами
Governance определяет:
- кто может читать shared memory;
- кто может писать;
- кто может редактировать чужие записи;
- кто подтверждает final decisions;
- какие records требуют approval;
- какие records auto-expire;
- какие records private;
- какие records inherited by future tasks;
- как удалить или исправить memory.
Пример:
Research agent may add source summaries.
Writer agent may create draft artifacts.
Reviewer agent may block finalization.
Planner agent may update task status.
Only supervisor may approve final output.
Такие правила делают multi-agent system предсказуемой.
Пример команды агентов
Задача:
Подготовить внутренний аналитический отчет по новой функции.
Роли:
- planner: разбивает задачу;
- researcher: собирает источники;
- analyst: выделяет claims and metrics;
- writer: пишет отчет;
- reviewer: проверяет факты и риски.
Shared workspace:
Goal:
Internal report on feature X.
Artifacts:
- source list
- claim table
- draft report
- review findings
Open questions:
- Is metric A approved for external use?
- Which customers are included?
Private memories:
- researcher remembers search strategies;
- writer remembers report style;
- reviewer remembers compliance checklist.
Event log:
- кто добавил источник;
- кто изменил claim;
- кто подтвердил метрику;
- кто одобрил финальную версию.
Так memory превращается в coordination substrate, а не просто в архив сообщений.
Риски
| Риск | Как проявляется | Защита |
|---|---|---|
| Распространение ошибки | Один агент записал неверный факт, другие его усилили. | Source labels, review, trust levels. |
| Гонки записей | Два агента меняют одно состояние. | Locks, versioning, event log. |
| Конфликт целей | Agents optimize different objectives. | Shared goal, supervisor policy. |
| Memory pollution | Workspace заполнен черновиками и noise. | Schemas, cleanup, artifact lifecycle. |
| Hidden private state | Агент действует на основе невидимой памяти. | Explainable handoffs, policy-bound private memory. |
| Permission leakage | Shared memory раскрывает данные не всем ролям. | Access control by role and scope. |
Метрики
Multi-agent memory оценивается не только по final answer.
| Метрика | Что показывает |
|---|---|
| Task completion rate | Система завершает задачи. |
| Coordination overhead | Сколько действий ушло на согласование. |
| Duplicate work rate | Повторяют ли агенты работу друг друга. |
| Conflict rate | Как часто возникают противоречия. |
| Conflict resolution time | Как быстро conflicts закрываются. |
| Error propagation rate | Насколько часто ошибка одного агента заражает других. |
| Handoff quality | Достаточно ли контекста получает следующий агент. |
| Shared memory relevance | Не засорен ли workspace. |
Хорошая multi-agent memory уменьшает coordination cost без потери контроля.
Мини-кейс: writing pipeline
Pipeline:
Planner -> Writer -> Reviewer -> Editor
Shared workspace:
lesson_title
required_sections
current_draft_path
open_issues
review_status
Event log:
Planner created outline.
Writer drafted lecture.
Reviewer flagged missing self-check questions.
Editor added questions and summary.
Reviewer approved.
Bad design:
Each agent keeps its own copy of task state.
No one knows which version is final.
Reviewer comment is lost.
Writer overwrites editor changes.
Good design:
Shared state has one current draft.
Review findings are structured.
Writes are versioned.
Final approval is explicit.
Типичные ошибки
Ошибка 1: делать одну общую память для всего.
Shared workspace, private memories и event log имеют разные роли.
Ошибка 2: не определять ownership.
Если все могут менять все, conflicts станут нормой.
Ошибка 3: хранить только итоговое состояние.
Без event log невозможно понять, как возникла ошибка.
Ошибка 4: не ограничивать private memory.
Приватная память роли не должна обходить policies.
Ошибка 5: не чистить shared workspace.
Старые черновики и устаревшие notes мешают coordination.
Ошибка 6: игнорировать human approval.
Некоторые decisions должны подтверждаться человеком или supervisor policy.
Краткое резюме
В multi-agent system память становится механизмом координации. Нужны shared workspace, private role memories, coordination memory, event log, conflict resolution и governance rules. Без этого агенты будут дублировать работу, распространять ошибки и спорить с разными версиями состояния.
Главная мысль: multi-agent memory должна управлять совместной работой, а не просто хранить больше контекста.
Вопросы для самопроверки
- Чем shared workspace отличается от private role memory?
- Почему event log важен для multi-agent systems?
- Какие conflicts чаще всего возникают между агентами?
- Какие правила governance нужны для shared memory?
- Какие метрики показывают, что память улучшает координацию?
Что дальше
Следующий модуль закрепит общий язык курса. Мы соберем ключевые термины: agent, memory, context window, working memory, episodic/semantic/procedural/reflection memory, retrieval, context assembly, consolidation, memory poisoning и multi-tenancy.