Перейти к основному содержимому

Роям агентов нужен контракт обнаружения, а не общая база данных

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

Studio shot of a humanoid robot with glowing eyes against a dark background, offering ample copyspace.

Общее хранилище — не узкое место

Когда рой вырастает с нескольких агентов до тысяч, инстинкт подсказывает обратиться к общей базе данных. Сложить каждый факт в одно место, позволить каждому агенту читать и писать — и координация превращается в задачу хранения. Этот инстинкт ошибочен. Хранение дёшево и хорошо изучено. Режим отказа в масштабе роя — это не ёмкость, а согласие: у агентов нет общего определения того, что такое факт, когда он актуален и кому позволено утверждать, что он существует.

Общее хранилище без контракта обнаружения превращается в свалку, доступную только на запись. Каждый агент может дописать, немногие способны интерпретировать, и никто не может вывести из обращения. Результат — не база знаний, а груда утверждений, связи между которыми не определены.

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

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

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

Без правил именования дубликаты выглядят как независимые свидетельства

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

Дубликат-как-свидетельство — это тихое искажение. Оно не поднимает ошибку, оно поднимает оценку уверенности. Рои, полагающиеся на подсчёт подтверждений без дисциплины именования, измеряют собственную избыточность и называют это согласием.

Контракт обнаружения

A detailed close-up of an illuminated audio mixer showcasing controls and displays.

Контракт обнаружения — это набор правил, определяющих, как факты именуются, версионируются и выводятся из обращения до того, как попадут в любое хранилище. Это протокол, а не схема. Схема описывает, как выглядит запись; контракт описывает, что она означает и когда перестаёт означать.

Три свойства несут нагрузку.

Канонический ключ, идентичность производителя, метка времени

Каждый факт должен нести канонический ключ, производный от его содержимого, а не от агента, который его записал. Ключ вида sensor:temperature:celsius:station-7:2024-06-01T12:00Z может быть выведен любым агентом, наблюдающим тот же факт. Два агента, записывающие одно и то же наблюдение, порождают один и тот же ключ, и хранилище может свернуть их в одну запись с двумя подтверждениями вместо двух записей.

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

Чтения объявляют версию, от которой зависят

Читатель, потребляющий факт, должен указать, от какой версии он зависит. Это превращает устаревшие чтения из тихой угрозы в явный выбор. Агент, который прочитал версию 3 и действовал по ней, может быть проверен позже: он зависел от версии 3, а версия 5 её вытеснила. Без этого читатель, потребивший вытесненный факт, выглядит неотличимо от того, кто потребил текущий факт, и возникшую ошибку невозможно атрибутировать.

Объявление версии не бесплатно. Оно заставляет читателей нести состояние, а писателей — публиковать переходы версий. Компромисс реален: системы, пропускающие объявление версии, выигрывают в пропускной способности и теряют способность объяснять собственные выводы. Для роёв, принимающих решения с накоплением, объяснение стоит дороже пропускной способности.

Вывод из обращения — операция первого класса

Вытесненные факты должны перестать цитироваться. Это требует операции вывода из обращения, столь же явной, как запись. Факт не удаляется; он помечается выведенным из обращения, со ссылкой на факт, который его вытеснил, и причиной. Нижестоящие читатели, объявившие зависимость от версии выведенного из о

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

Rows of wine bottles on a production line in an industrial setting.

Происхождение как несущее свойство

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

Практическое следствие — правило времени записи: факты без атрибуции отклоняются. Не фильтруются во время чтения, не помещаются в карантин на потом, а отклоняются. Фильтр времени чтения — это политика, которую каждый потребитель должен реализовать корректно и единообразно. Отклонение во время записи — это свойство системы. Первое отказывает тихо, когда потребитель забывает; второе отказывает громко на границе.

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

Последствия для оценки

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

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

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

Сначала постройте контракт

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

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

ПоделитьсяXLinkedInПостоянная ссылка5 мин чтения

Связанное чтение

На какие вопросы это отвечает

What is a discovery contract in a multi-agent system?

It is the set of rules governing how facts are named, versioned and retired before they reach any shared store. It defines canonical keys, producer identity, version dependencies and retirement semantics, so agents agree on what a fact is rather than only where it is stored.

Why does a shared database fail at swarm scale?

Because storage is not the bottleneck. Concurrent writers produce conflicting records that no single agent can adjudicate, and without naming rules the same fact written by different agents looks like independent evidence. Stronger transactions order writes but do not interpret them.

Why should unattributed facts be rejected at write time?

A read-time filter is a policy each consumer must implement correctly and consistently, and it fails silently when one forgets. A write-time rejection is a property of the system and fails loudly at the boundary, keeping the corpus traceable and auditable.

How should swarm quality be evaluated?

Not on task completion alone. Evaluation should include fact-level metrics: agreement rate on canonical keys, contradiction rate between facts sharing a key, and the proportion of cited facts that are current rather than retired.