Дайте двум агентам одну и ту же проверенную запись памяти

Хранилища памяти Managed Agents от Anthropic могут сохранять текст между сессиями. Для приложения, которому нужно передать двум агентам один проверенный факт, постоянное хранение — лишь первый шаг. Приложение должно определить владельца записи, проверить исходное доказательство, выбрать сохранённую редакцию и сохранить её точные байты до того, как любой агент их увидит. Руководство предназначено разработчикам с разрешённым доступом к бета-версии Managed Agents и контролем аутентификации приложения, выбора хранилищ и настроек агентов. Оно основано на актуальной документации Anthropic по памяти и справочниках API, проверенных 20 октября 2026 года; BIG CHANGE не проводила тесты аккаунта или модели.

Главное изменение

• Что изменилось: Проверенная типизированная JSON-память может постоянно храниться в Managed Agents. Приложение проверяет источник и точные сохранённые байты, фиксирует один закрытый снимок и отправляет те же одобренные байты двум отдельным разрешённым сессиям без подключения хранилища памяти.
• Почему это важно: Последующее изменение хранилища не может изменить входные данные, уже подготовленные для этих сессий.
• На что обратить внимание: Точность источника, права пользователя и качество ответов по-прежнему требуют отдельных проверок.

Перед началом

Подготовьте реальный факт, предпочтение или правило проекта с разрешённым к использованию оригиналом, стабильным ID источника и редакцией, а также владельцем, одобряющим хранение и раскрытие обеим ролям агентов. До проверки определите подходящий срок актуальности проверки этой записи. Подтвердите доступ к бета-версии Managed Agents, закрытый API-ключ, разрешённое рабочее пространство, два настроенных ID агентов, окружение и разрешённую в аккаунте модель. Изучите текущие использование и цены до разрешения четырёх ограниченных сессий-потребителей этого процесса. Не включайте ключ в запросы модели или подтверждающие записи.

Приложению нужно сопоставление аутентифицированного субъекта с областью доступа. В доверенном состоянии приложения свяжите субъекта с одобренным ownerScopeId, ID рабочего пространства, ID хранилища и двумя разрешёнными ID агентов. Разделяйте хранилища закрытых пользователей и проектов, если их правила доступа отличаются. API-ключ рабочего пространства не аутентифицирует конечного пользователя, путь не является границей арендатора, а запрос модели не удаляет инструмент или учётные данные. Убедитесь, что у обеих конфигураций потребителей нет подключения хранилища и никаких коннекторов, учётных данных окружения или путей через инструменты к изменяемому хранилищу. Если эту границу нельзя обеспечить, остановитесь до отправки записи.

1. Одобрите запись по её источнику

Используйте этот структурный шаблон, заменив каждое значение в угловых скобках настоящим одобренным доказательством. Это не пример факта и не заявленный результат. До одобрения сериализуйте заполненный объект в один точный текст JSON UTF-8. Валидатор должен принимать именно эти поля и типы, отклонять неизвестные поля, требовать непустые строки, состоящие не только из пробелов и корректные временные метки UTC, ограничивать kind значениями fact, preference или project_rule, а status — значениями active, disputed или superseded. Внедрять можно только записи active. Одобренное утверждение должно соответствовать указанному оригиналу, включая дату начала действия и область применения.

{
  "schemaVersion": "memory-record/v1",
  "recordId": "<opaque stable record ID>",
  "ownerScopeId": "<trusted mapped scope ID>",
  "kind": "<fact | preference | project_rule>",
  "claim": "<precise source-supported claim>",
  "sourceId": "<private original-source ID>",
  "sourceRevision": "<original revision or exact source hash>",
  "sourceQuoteOrPointer": "<minimal permitted quote or stable pointer>",
  "validFrom": "<UTC timestamp>",
  "checkedAt": "<UTC timestamp>",
  "status": "active",
  "reviewerId": "<approved human reviewer ID>",
  "reviewedAt": "<UTC timestamp>"
}

Закрытое подтверждение одобрения приложения должно указывать реального одобрившего, разрешение владельца, оригинальный источник и редакцию, область и разрешённых агентов, правило актуальности и SHA-256 этих точных байтов JSON UTF-8. Оно фиксирует решение человека о настоящем утверждении. Строка reviewerId в записи не является аутентификацией. Не сохраняйте запись с нерешённым противоречием или отсутствующим разрешением. Anthropic хранит текст, но не проверяет эту схему и не устанавливает истинность утверждения.

2. Сохраните и прочитайте повторно

Создайте или выберите узкое хранилище памяти в разрешённом рабочем пространстве и запишите его настоящий memstore_... ID. Используйте нечувствительный путь, например /records/{opaque-record-id}.json. До запроса запишите исполнителя, время UTC, редакцию источника, хеш одобренных байтов, хранилище и путь и состояние pending. Для прямых вызовов хранилища памяти используйте agent-memory-2026-07-22, а для вызовов сессий — managed-agents-2026-04-01. По словам Anthropic, сочетание этих бета-заголовков в запросе к хранилищу возвращает HTTP 400. Справочник создания и руководство по памяти показывают следующую форму SDK; сравните установленный SDK с актуальным справочником:

mem = client.beta.memory_stores.memories.create(
    store.id,
    path="/records/<opaque-record-id>.json",
    content=approved_json_text,
)

Создание не перезаписывает существующий путь. Сохраните возвращённый mem_... ID, затем перечислите /records/ в хранилище нужной области, используя каждый next_page как следующий page. Базовый список по умолчанию не включает содержимое. Получите выбранную память по ID для полного текста; сравните ID хранилища, ID памяти, путь, содержимое и content_sha256 с одобренными байтами. Запишите ответ и прямое повторное чтение в журнал и реестр. Один ответ создания не подтверждает завершение. При неопределённом ответе проверьте точный путь и прямую запись до вывода о результате; одного отсутствия поискового совпадения недостаточно для повторного создания.

3. Зафиксируйте выбранную редакцию

При каждом последующем запуске аутентифицируйте вызывающего и определите его область, хранилище и ID выбранной записи из доверенного реестра. Если нужен поиск, перечислите все страницы ограниченного префикса, затем напрямую получите выбранную mem_.... Вычислите SHA-256 от кодировки UTF-8 для возвращённого содержимого, сравните с content_sha256 поставщика и точным хешем байтов, одобренным человеком, затем снова проверьте JSON. Проверьте ID записи, область владельца, редакцию источника, статус active, текущую актуальность источника и заранее заданный срок. Если любая проверка не пройдена, ничего не отправляйте.

Запишите полученные точные байты один раз в закрытое хранилище с адресацией по хешу, используя исключительное создание, например open(path, "xb") в Python. Сразу повторно прочитайте файл и вычислите хеш, а также делайте это перед каждой отправкой. Никогда не перезаписывайте существующий снимок. Неполный файл или существующий файл с другими байтами по тому же адресу требуют приостановки и сверки. Храните первоначальное одобрение, ID хранилища, ID памяти, хеш поставщика, хеш снимка и решение по области в закрытом подтверждении получения. Такой однократно записываемый снимок — устройство приложения, а не подключение Anthropic, привязанное к версии.

4. Передайте одинаковые байты двум новым сессиям

Создайте новую сессию агента A с настоящими разрешёнными ID агента и окружения и без записи хранилища памяти в resources. Убедитесь, что ресурсы возвращённой сессии и фактические инструменты и учётные данные агента не оставляют иного пути к хранилищу. Руководство по сессиям Anthropic отдельно описывает создание и отправку user.message:

session = client.beta.sessions.create(
    agent=approved_agent_id,
    environment_id=approved_environment_id,
)
client.beta.sessions.events.send(
    session.id,
    events=[{"type": "user.message", "content": [{"type": "text", "text": message_text}]}],
)

До events.send повторно прочитайте закрытый снимок и вычислите его хеш. Сформируйте message_text детерминированно из явной метки «проверенные данные», идентификаторов записи, источника и проверки, неизменённого JSON-текста и его SHA-256, затем узкого вопроса, на который может ответить первоисточник. Показанные поля — это формат сообщения приложения, а не поля ответа поставщика. До отправки запишите все байты UTF-8 сообщения и хеш, хеш выбранного снимка, разрешённый ID агента, ID сессии и состояние отправки. Сохраните результат и настоящий ID отправленного события или повторное чтение списка событий, если доступно. Неизвестный исход отправки требует чтения событий, а не слепой повторной отправки.

Создайте вторую новую сессию для агента B с отдельно одобренным ID и таким же отсутствием доступа к хранилищу. Повторно прочитайте тот же однократно записанный снимок, проверьте хеш байтов, сформируйте и запишите полное сообщение B, затем отправьте. Вопросы задания или метаданные адресата могут отличаться; убедитесь, что встроенные байты JSON и одобренный хеш записи одинаковы. Проверьте каждый ответ и события инструментов по оригиналу. Правдоподобный ответ или цитата не доказывают внутреннюю опору модели на внедрённый текст; подтверждения сообщений и событий поставщика показывают, что предоставило приложение. Если у любой сессии есть активное подключение или другой путь к хранилищу, ничего ей не отправляйте.

5. Обновляйте только после новой проверки источника

При изменении оригинала напрямую получите текущую память и сравните старые и новые доказательства с владельцем. Пусть человек одобрит точные заменяющие байты JSON со стабильным ID записи, исправленным утверждением или указателем источника, новой редакцией источника и временем проверки и рассмотрения. Сохраните старое подтверждение и хеш. Запишите mem_... ID, текущий напрямую прочитанный content_sha256, планируемый хеш замены, исполнителя, одобрение и ожидающее состояние. Документированное условное обновление выглядит так:

client.beta.memory_stores.memories.update(
    memory_id=memory_id,
    memory_store_id=store_id,
    content=approved_replacement_json_text,
    precondition={"type": "content_sha256", "content_sha256": fresh_old_hash},
)

Поставщик хеширует точное содержимое UTF-8 без нормализации. Несовпадение возвращает HTTP 409 memory_precondition_failed_error. При таком ответе или неопределённом сетевом результате снова получите действующую память и при необходимости изучите историю версий. Сравните конфликтующие редакции источника и попросите владельца объединить, отклонить или одобрить новую точную замену; никогда вслепую не повторяйте устаревшую запись. При успехе прямое получение должно подтвердить путь, полный заменяющий текст, хеш и ID версии памяти до перехода журнала в confirmed.

Зафиксируйте новый одобренный снимок этой проверенной редакции. Создайте новые разрешённые сессии A и B без подключённого хранилища и повторите обе отправки и проверки источника. Не меняйте старые снимки и не утверждайте, что отправленные сообщения обновляются сами. Пометьте прежний снимок как непригодный для будущего внедрения. Если владелец отзывает запись, прекратите новые отправки и примените его правила хранения и удаления данных: удаление текущей памяти не обязательно удаляет сохранённые версии. Архивирование или удаление всего хранилища — отдельное решение.

Что считается завершением

Закрытые подтверждения должны связывать исходное разрешение и редакцию источника с точным одобренным JSON-хешем; настоящую идентичность рабочего пространства, хранилища, пути и mem_... и прямое чтение после создания; один неизменяемый снимок; два разных разрешённых ID сессий без подключения с хешами отправленных сообщений и ответами, сверенными с источником; одобренное условное обновление с новым прямым чтением и проверками новых сессий. При любой неизвестной связи отметьте всё упражнение как незавершённое и сохраните точную причину. Если выполняете его, запишите реальное использование сессий и инструментов и расходы конкретного аккаунта; это документальное руководство не измеряло экономию или качество модели.

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