Урок 2.8. Shared Memory: память в multi-agent системах

Цель лекции

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

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

Читатель понимает, что shared memory - это governance-проблема, а не только storage-проблема: нужно проектировать права доступа, ownership, правила записи, conflict resolution, приватные зоны памяти и защиту от распространения ошибок.

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

До этого мы рассматривали память в основном с точки зрения одного агента. У него есть working memory, session memory, episodic memory, semantic facts, procedures, reflection и доступ к world memory через RAG.

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

• planner строит план;
• researcher собирает источники;
• coder меняет код;
• reviewer ищет риски;
• tester запускает проверки;
• support agent ведет клиента;
• supervisor следит за политиками и качеством;
• memory manager обновляет долгосрочную память.

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

Для этого нужна shared memory: общее пространство состояния, через которое агенты координируются.

Но shared memory опасна. Если ошибочный вывод попал в общую память, другие агенты могут начать использовать его как факт. Если права доступа не настроены, приватная память одного пользователя может оказаться видимой другому агенту. Если нет ownership, несколько агентов могут одновременно перезаписать важное решение.

Shared memory помогает агентам работать как команда, но требует правил команды.

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

Shared memory - это память, доступная нескольким агентам, ролям или процессам для координации работы.

Она отвечает на вопрос: "что должно быть известно группе агентов, чтобы они могли действовать согласованно?"

Это может быть:

• текущее состояние задачи;
• общий план;
• найденные источники;
• принятые решения;
• артефакты;
• статусы подзадач;
• зависимости;
• открытые вопросы;
• shared facts о проекте;
• результаты инструментов;
• warnings и risks;
• handoff notes между агентами.

Главная особенность shared memory: запись одного агента может повлиять на поведение другого. Поэтому shared memory нельзя проектировать как простой общий блокнот. Нужны правила: кто может читать, кто может писать, кто подтверждает, кто удаляет, что считается draft, что считается verified, как решаются конфликты и как предотвращаются утечки.

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

Shared memory не равна всем данным подряд

Не все, что знает один агент, должно становиться общим.

Примеры данных, которые могут быть общими:

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

Примеры данных, которые не стоит автоматически делать общими:

• скрытые рассуждения агента;
• временные гипотезы без evidence;
• приватные предпочтения пользователя вне нужного scope;
• sensitive data;
• credentials;
• raw tool logs с лишними данными;
• непроверенные self-reflection заметки;
• черновики, которые могут быть приняты за final decision.

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

Private, shared и public memory

Для multi-agent систем полезно разделять уровни видимости.

Проблемы начинаются, когда эти уровни смешиваются. Например, агент берет private note пользователя и записывает его в team memory. Или временный draft становится organization policy. Или internal support note попадает в публичный ответ.

Blackboard pattern

Blackboard pattern - классическая модель координации: есть общая доска, а разные агенты читают из нее и добавляют свои результаты.

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

Blackboard удобен, когда:

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

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

Global workspace

Global workspace похож на blackboard, но обычно обозначает не всю долговременную память, а текущую общую рабочую область.

В global workspace попадает то, что прямо сейчас важно для координации:

• текущая цель;
• выбранный план;
• active constraints;
• последние observations;
• blocked items;
• pending decisions;
• ссылки на ключевые артефакты;
• next actions.

Это ближе к shared working memory, чем к long-term memory. Global workspace должен быть компактным. Если он разрастается, агенты начинают терять фокус, а context assembly перегружается.

Полезное правило: global workspace хранит "что команда агентов должна видеть прямо сейчас", а long-term shared memory хранит "что команда должна помнить между задачами".

Team memory

Team memory - это более долговременный слой общего знания команды агентов.

Он может хранить:

• решения;
• статусы;
• артефакты;
• зависимости;
• known risks;
• accepted assumptions;
• task history;
• validated facts;
• reusable workflows;
• postmortems;
• handoff summaries.

Пример team memory для software project:

Project: billing-service
Decision:
  Discount calculation happens before tax calculation.
Source:
  ADR-014 and pricing_rules.test.ts
Status:
  verified
Owner:
  pricing team
Last confirmed:
  2026-08-07
Used by:
  planner, coder, reviewer, tester

Такая запись не является просто документом. Она направляет поведение нескольких агентов: coder учитывает ее при изменениях, reviewer проверяет нарушения, tester выбирает тесты, planner оценивает impact.

Handoff memory

В multi-agent workflow часто один агент передает работу другому.

Плохой handoff:

Я посмотрел, вроде все понятно. Продолжай.

Хороший handoff:

Goal:
Fix discount rounding bug.

Current state:
- Root cause likely in discount_helper.ts rounding after tax.
- pricing_rules.test.ts covers base discounts.
- invoice_totals.test.ts still failing.

Important constraints:
- Do not change tax calculation order.
- Check ADR-014 before changing pricing semantics.

Next suggested action:
Inspect invoice_totals expected values and compare rounding stage.

Handoff memory должна быть короткой, structured и actionable. Она не обязана включать все детали прошлого агента. Она должна передать то, что следующему агенту нужно для продолжения.

Ownership: кто читает, пишет и изменяет

Shared memory требует ownership.

Для каждой важной записи полезно понимать:

• кто создал запись;
• на основе какого источника;
• кто может ее читать;
• кто может ее изменять;
• кто может подтверждать;
• кто может удалить или архивировать;
• какой статус у записи: draft, proposed, verified, deprecated;
• что делать при конфликте.

Без ownership общая память быстро теряет доверие. Если неизвестно, кто записал факт и можно ли ему доверять, агенты будут либо слепо принимать все, либо игнорировать shared memory полностью.

Пример статусов:

Conflict resolution

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

Примеры:

Research agent:
- Docs say feature export is available on Pro plan.

CRM agent:
- Customer account has Pro plan but export flag is disabled.

Это не обязательно конфликт фактов. Возможно, есть feature flag, regional restriction или stale entitlement.

Другой пример:

Planner:
- We should refactor the shared helper.

Reviewer:
- Refactor is risky; current task asks only for a bug fix.

Здесь конфликт между стратегиями.

Еще пример:

Agent A:
- User prefers detailed explanations.

Agent B:
- User asked for concise final answers in this project.

Здесь нужен scope: возможно, пользователь хочет подробные архитектурные объяснения, но краткие финальные отчеты.

Стратегии conflict resolution:

Shared memory должна уметь хранить сам факт конфликта. Иногда лучше записать conflicted, чем молча выбрать одну сторону.

Consensus и review

В некоторых системах один агент не должен единолично записывать важные shared facts.

Примеры, где полезен review:

• изменение policy;
• обновление canonical project fact;
• вывод по high-risk incident;
• customer-facing commitment;
• security-sensitive decision;
• long-term procedural rule;
• shared reflection после серьезной ошибки.

Consensus не всегда означает голосование. Это может быть:

• подтверждение supervisor agent;
• проверка источника;
• approval от пользователя;
• passing tests;
• совпадение двух независимых retrieval results;
• review от специализированного агента.

Важно не перегрузить систему бюрократией. Для low-risk записей достаточно provenance и статуса draft. Для high-risk записей нужен review.

Shared memory record

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

id: shared_task_042_decision_003
type: decision
scope:
  project: billing-service
  task: discount-rounding-fix
visibility:
  read: [planner, coder, reviewer, tester]
  write: [planner, reviewer]
status: verified
owner: pricing-reviewer-agent
summary: Discount rounding must happen after applying discount and before tax.
source:
  - ADR-014
  - pricing_rules.test.ts
created_by: researcher-agent
verified_by: reviewer-agent
created_at: 2026-08-07T15:40:00+03:00
last_updated_at: 2026-08-07T15:55:00+03:00
conflicts_with: []
ttl: until_task_closed

Это не обязательная схема базы данных. Это mental model: shared memory должна хранить не только текст, но и scope, visibility, owner, status, provenance и правила жизни записи.

Риск распространения ошибки

Главный риск shared memory - ошибка размножается.

Если один агент записал неверный факт в private scratchpad, ущерб ограничен. Если он записал его в shared memory как verified, другие агенты могут:

• строить план на неверной основе;
• выбирать неправильные инструменты;
• повторять ошибку в ответах;
• обновлять procedural memory;
• передавать ошибку пользователю;
• закреплять ее в long-term team memory.

Пример:

Research agent writes:
- Customer has Enterprise plan. Status: verified.

Support agent uses it:
- Tells customer they should have export access.

CRM check later:
- Customer has expired Enterprise trial, not active Enterprise plan.

Проблема не только в неправильном факте, а в том, что статус verified был назначен без достаточной проверки.

Защита:

• source attribution;
• confidence;
• verified vs draft status;
• scope;
• access control;
• review для high-impact records;
• staleness checks;
• audit trail;
• easy correction and invalidation.

Shared memory и privacy

Shared memory расширяет поверхность утечек.

В single-agent системе privacy уже сложна. В multi-agent системе сложность выше, потому что данные проходят через несколько ролей, tools и промежуточных записей.

Особенно опасны:

• customer data;
• private user preferences;
• медицинские, финансовые и юридические сведения;
• credentials и tokens;
• internal comments;
• HR или performance notes;
• security findings;
• private reflections агента;
• raw logs.

Правило: shared memory должна хранить минимально необходимый контекст для координации.

Если reviewer agent должен знать, что "есть privacy constraint", ему не всегда нужно видеть сам чувствительный фрагмент. Если support agent должен знать, что "клиент требует escalation", ему не всегда нужны все внутренние заметки sales team.

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

Представим систему из четырех агентов:

• planner agent;
• coder agent;
• tester agent;
• reviewer agent.

Пользователь просит:

"Исправь баг в расчете скидки и проверь, что invoice totals не ломаются."

Shared memory может выглядеть так:

Task state:
- Goal: fix discount calculation bug.
- Constraint: invoice totals must remain stable.
- Current hypothesis: rounding stage is wrong.
- Open question: should discount round before or after tax?

Artifacts:
- Modified file: src/pricing/discount_helper.ts
- Relevant tests: pricing_rules.test.ts, invoice_totals.test.ts

Decisions:
- Do not change tax calculation order without ADR review.

Status:
- Planner done.
- Coder in progress.
- Tester waiting for patch.
- Reviewer blocked until test results.

Planner пишет план и constraints. Coder читает их и добавляет patch summary. Tester добавляет результаты тестов. Reviewer добавляет risks и final approval.

Если shared memory структурирована, система работает как команда. Если это просто поток сообщений, agents могут пропустить constraint или принять гипотезу за факт.

Мини-кейс: research team agents

Research multi-agent system может включать:

• query planner;
• source finder;
• evidence extractor;
• fact checker;
• summarizer;
• citation reviewer.

Shared memory:

Research question:
- What changed in API behavior in version 2026-07?

Sources:
- Official API changelog, updated 2026-07-14.
- Migration guide, updated 2026-07-18.
- Blog post, updated 2026-07-10.

Findings:
- Deprecated parameter X.
- New limit for batch update: 100 objects.

Conflicts:
- Blog says old limit is 50.
- API reference says current limit is 100.

Decision:
- Use API reference as canonical source.

Здесь shared memory помогает не потерять evidence и conflicts. Но она должна сохранять source priority: blog post не должен случайно перебить официальный API reference.

Shared memory в связи с другими типами памяти

Shared memory не является девятым независимым "видом данных". Это способ разделения памяти между агентами.

Она может содержать разные типы записей:

То есть shared memory - это вопрос scope and governance: кому доступна запись и как она управляется.

Когда shared memory не нужна

Не каждая система должна становиться multi-agent.

Shared memory может быть лишней, если:

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

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

Multi-agent architecture добавляет coordination overhead. Shared memory оправдана, когда специализация и параллельность действительно дают выигрыш.

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

Ошибка 1: считать shared memory просто общей vector database.

Общая база поиска не решает ownership, права доступа, статусы, conflicts, provenance и review.

Ошибка 2: записывать все private notes в общий контекст.

Shared memory должна содержать только то, что нужно группе агентов.

Ошибка 3: не различать draft и verified.

Если гипотеза выглядит как факт, другие агенты начнут строить на ней действия.

Ошибка 4: не хранить provenance.

Без информации о том, кто и на основе чего сделал запись, conflict resolution почти невозможен.

Ошибка 5: применять access control после чтения.

Как и в RAG, permissions нужно проверять до retrieval и context assembly.

Ошибка 6: не назначать owner.

Запись без владельца трудно обновлять, подтверждать и удалять.

Ошибка 7: не поддерживать conflict state.

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

Ошибка 8: превращать shared memory в бесконечный лог.

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

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

Shared memory - это общая память нескольких агентов, ролей или процессов. Она нужна для координации: хранить план, статусы, решения, артефакты, handoff notes, conflicts и team-level facts.

Главная сложность shared memory не в storage. Сложность в governance: кто читает, кто пишет, кто подтверждает, кто владеет записью, как задается scope, как решаются конфликты, как защищается private memory и как предотвращается распространение ошибок.

Shared memory может содержать episodic, semantic, procedural, reflection и world-memory references. Ее отличает не тип содержимого, а то, что запись становится доступной нескольким агентам и влияет на их совместное поведение.

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

1. Зачем multi-agent системе shared memory?
2. Чем blackboard pattern отличается от private memory отдельных агентов?
3. Почему shared memory требует ownership и статусов вроде draft или verified?
4. Как ошибка одного агента может распространиться через общую память?
5. Почему shared memory - это governance-проблема, а не только storage-проблема?

Что дальше

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