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

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

Связка 1

Начальное состояние: Мультиагентные системы (сотни/тысячи агентов) работают параллельно с общим состоянием и общей памятью, что создаёт риск затирания и перезаписи данных разными агентами.
Преобразование: Внедрение областей разрешений доступа (read-only к одному хранилищу, read-write к другому) и механизма оптимистичной конкурентности, при котором агент использует хеш содержимого для проверки, не перезапишет ли он память другого агента перед обновлением.
Конечное состояние: Масштабирование мультиагентных систем в Cloud Code и корпоративной среде (Anthropic) становится возможным: агенты могут безопасно взаимодействовать с общим состоянием без потери данных, а разработчики и предприятия получают контроль над правами доступа в продакшн-среде.

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

Многие виб-кодеры запускают одновременно 10 или 15 сессий Cloud Code, и мы начинаем видеть это и в корпоративной среде, где компании, включая Anthropic, имеют сотни или даже тысячи агентов, работающих параллельно и взаимодействующих с одним и тем же общим состоянием и общей памятью. Из этого вытекает несколько свойств.

Первое: мы хотим дать агентам возможность комбинировать сессию и выполняемую работу с набором хранилищ памяти, к которым у них есть доступ. Одно из свойств памяти в управляемых агентах — это области разрешений доступа (read-only к одному хранилищу, read-write к другому). Возможность для одного агента иметь доступ только для чтения к одному хранилищу памяти (например, это может быть общеорганизационное знание, набор лучших практик, инструкция по выполнению типовых задач) и доступ для чтения и записи к другому хранилищу памяти. Например, это может быть рабочая память, которая гораздо более специфична и часто обновляется в зависимости от выполняемой работы.

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

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