Внутри стремления к стандартизации связи между агентами искусственного интеллекта
7 августа 2025 г.Введение
Появление крупных языковых моделей (LLMS) в качестве автономных агентов потребовало создания протоколов для облегчения эффективного взаимодействия, координации и делегирования среди вычислительных сущностей. Поскольку агенты на основе LLM размножаются по доменам, отзываясь от научных сотрудников и апопилотов разработчиков до автономных рабочих процессов в корпоративных системах, ограничения экземпляров изолированных агентов становятся все более заметными. В частности, без общего протокола агентам не хватает способности к надежному обмену памяти, вызов инструмента, управлению персоной и безопасной межагентной связи.
Эта проблема привела к разработке протоколов взаимодействия агентов, предназначенных для обеспечения стандартизированного интерфейса и схемы, посредством которых несколько агентов могут обмениваться контекстным состоянием, запускать действия и создавать постоянную память между инструментами. Среди нихПротокол контекста модели (MCP)стал ведущей структурой, особенно для ее интеграции в рабочие процессы разработчиков, открытые спецификации и расширяемость. Наряду с MCP альтернативные протоколы, такие какПротокол связи агента (ACP)иПомощник-ассистостентный (A2A)Слои обмена сообщениями представляют параллельные попытки формализовать топологию общения агента.
Цель этой статьи -Осмотрите текущий ландшафтпротоколов взаимодействия агентов, оценивать их архитектуру, применение и использование и формулировать траекторию в отношении будущего объединения или дивергенции. Каждый протокол будет анализироваться через призму ее технической структуры, функциональных возможностей и специфичных для домена сильных сторон.
+----------------------+
| User Request |
+----------+-----------+
|
+---------▼--------+
| Controller / |
| Orchestrator AI |
+---------+--------+
|
+-------------------+-------------------+
| |
+-------▼-------+ +-------▼-------+
| MCP | | ACP |
| (Tool Use, | | (Intent Trees,|
| Context API) | | Dialog Flows)|
+-------+-------+ +-------+-------+
| |
+-------▼-------+ +-------▼-------+
| Agent A | | Agent B |
+---------------+ +---------------+
Проблема связи агента
По мере того, как переход систем AI от монолитных предикторов к агентским рамкам, способным рассуждать, делегирование и вызов инструментов, возникла проблема с фундаментальным системным уровнем:общение между автономными агентами нетривиально и в значительной степени нестандарноПолем В отличие от традиционных API или распределенных систем, агенты работают с нетерминированными результатами, развивающимися состояниями памяти и динамическими целями. В этом контексте эффективная совместимость - это не просто вопрос сериализации данных, а скорее оркестровка общей семантики, разрешений и временного контекста.
Отсутствие стандартизированных протоколов связи среди агентов приводит к многочисленным техническим вопросам:
- Фрагментация контекста: Агенты не имеют общего представления целей пользователя, истории или состояния задачи.
- Неоднозначность выполнения инструмента: Вызов внешних инструментов отличается в формате, модели безопасности и гранулярности.
- Отсутствие делегирования межагента: Агенты не могут беспрепятственно раздавать задачи или подгои из -за несовместимых схем обмена сообщениями.
- Рабочий процесс Бритлейс: Системы тесно связаны, что затрудняет их расширение, отладка или аудит.
Эти проблемы сильно ограничивают масштабируемость и композицию многоагентных систем, особенно в использовании, таких как автономные исследования, автоматизация поддержки клиентов, среда совместного развития и рабочие процессы с интенсивными знаниями.
+-----------+ +-------------+ +------------+
| Agent A | ??? | Agent B | ??? | Agent C |
+-----------+ <======>+-------------+ <======> +------------+
| | |
+--------▼--------+ +-------▼--------+ +-------▼--------+
| Tool Interface | | Context Buffer | | Local Tools |
+-----------------+ +----------------+ +----------------+
(Custom JSON) (Custom Mem) (Proprietary)
Рост протоколов, таких как MCP, ACP и A2A, является попыткойСистематизировать межагентное общениеОпределяя формальные схемы, грамматики действия и модели управления контекстом. Тем не менее, эти протоколы значительно различаются в целях и дизайне, что еще больше усложняет усыновление и совместимость между экосистемами.
Обзор основных протоколов
Стремление к совместимости агента привело к нескольким протоколам, каждый из которых рассматривает подмножество задачи связи, описанной ранее. Эти протоколы различаются по нескольким техническим измерениям: уровень абстракции, выразительность, детерминизм и открытость. В этом разделе мы анализируем четыре основные категории:
- Протокол контекста модели (MCP)
- Протокол связи агента (ACP)
- Помощник-ассистостентный (A2A)обмен сообщениями
- и коллекцияальтернативные или новые протоколыПолем
Протокол контекста модели (MCP)
АПротокол контекста модели (MCP)предназначено для того, чтобы позволить агентам на основе LLM поддерживать структурированную память, запустить использование инструмента и сохранить состояние через призывы. Он вводит формальную грамматику для трех основных элементов:
tools: Внешние API или функции, которые агент может вызвать.context: Сериализованная историческая информация для условий модели модели.persona: Модификаторы поведения на основе ролей для идентичности и тона агента.
Каждое взаимодействие MCP включает"Контекст пакет", который может быть передан на размещенный MCP -сервер для обработки или сохраняется локально. MCP все чаще используется плагинами IDE, автономными исследовательскими агентами и ботами GitHub.
+-------------+ [Context] +----------------+ [Tool Call] +------------+
| User Task | ---------------> | MCP Server | -----------------> | API/Plugin |
+-------------+ +----------------+ +------------+
| ▲
[Persona] | | [Memory, Role, Tools]
▼ |
+-----------+-----+
| LLM Agent |
+------------------+
Протокол связи агента (ACP)
АПротокол связи агента (ACP)мотивируется разложением целей и спецификацией поведения. Это позволяет декларативное программирование систем агентов с использованиемнамерения деревьяВГрафики возможностей, иПолитики исполненияПолем ACP превосходит в средах, где агенты должны:
- Договориться об использовании ресурсов
- Assert or retract intents
- Формировать цепочки делегирования
- Реагировать на сложные мировые модели
ACP является более выразительным, чем MCP, но менее стандартизированный и обычно используется в системах моделирования, робототехнике или двигателях планирования задач.
+-----------+ +-----------+ +------------+
| Agent 1 | -----> | Agent 2 | -----> | Agent 3 |
+-----------+ +-----------+ +------------+
| | |
|---- Intent: "Build Report" -----------> |
|<--- Confirm: "Gathering Data" ----------|
Помощник-помощник (A2A) протокол
АПомощник-ассистостентный (A2A)Протокол - это, прежде всего, слой абстракции, позволяющий нескольким запатентованным агентам LLM (например, экземпляры CHATGPT) для сотрудничества в выполнении задачи. В отличие от MCP или ACP, A2A оптимизирован дляПрохождение сообщенияиОбщие обновления царапина не использование инструментов или управление государством.
A2A используется в сценариях, где:
- Агенты имеют разные области опыта
- Координация эфемерна и не сохраняется
- Поведение системы должно оставаться непрозрачным для конечного пользователя
A2A остается в значительной степени недокументированным и рассматриваетсязакрытый спектрПолем
+------------+ +------------+ +------------+
| Agent GPT1 |<------->| Agent GPT2 |<------->| Agent GPT3 |
+------------+ +------------+ +------------+
\__________________ Shared Memory __________________/
[Conversation Thread + Notes]
Другие и появляющиеся протоколы
Появилось несколько легких или специфичных для домена протоколов, например:
- ANP (протокол переговоров агента): Сосредоточен на контрактном сотрудничестве между агентами.
- AGP (протокол управления агентом): Вводит на основе ролей контроль доступа и аудита.
- Пользовательские API: Собственные схемы, используемые стартапами или рамками с открытым исходным кодом.
Хотя эти протоколы предлагают на заказ решения, они часто страдают отЗаблокировка продавца, отсутствие общности или недостаточная документация.
Сравнительный анализ
На проектирование и принятие протоколов взаимодействия агентов влияют компромиссы между выразительностью, модульностью, детерминизмом исполнения и инструментами разработчика. Чтобы выяснить сильные стороны и ограничения каждого протокола - MCP, ACP, A2A и другие возникающие спецификации - мы представляем сравнительный анализ в пяти ключевых измерениях:
- Контекстная обработка: Насколько хорошо протокол управляет общей памятью, прошлым взаимодействием и постоянным состоянием.
- Призыв инструмента: Может ли агент надежно и надежно вызовать внешние функции или API.
- Многоагентная оркестровка: Поддержка распределенных рассуждений, делегирования или координации между несколькими агентами.
- Спецификация открытость: Степень, в которой протокол задокументирован, расширяется и заправлено сообществом.
- Модель безопасности: Встроенная поддержка контроля доступа, песочницы и аудитации.
Ниже приведена матрица совместимости протокола:
+--------------------------+------+-----+-----+--------+--------+
| Feature / Protocol | MCP | ACP | A2A | Others | Score* |
+--------------------------+------+-----+-----+--------+--------+
| Context Handling | ✅ | ⚠️ | ✅ | ⚠️ | 3.5 |
| Tool Invocation | ✅ | ✅ | ❌ | ⚠️ | 3.0 |
| Multi-Agent Orchestration| ⚠️ | ✅ | ✅ | ⚠️ | 3.0 |
| Specification Openness | ✅ | ❌ | ❌ | ⚠️ | 2.0 |
| Security Model | ⚠️ | ✅ | ❌ | ⚠️ | 2.5 |
+--------------------------+------+-----+-----+--------+--------+
Legend: ✅ = Full Support, ⚠️ = Partial/Custom, ❌ = Unsupported
Наблюдения
- MCPДемонстрирует силу в практических развертываниях из-за его простоты и дизайна первого инструмента. Тем не менее, ему не хватает надежной поддержки для многоагентных рассуждений и контроля доступа.
- АтмосфераПредоставляет наиболее выразительную структуру для координации агента, но страдает от ограниченной публичной документации и непоследовательных реализаций в экосистемах.
- A2Aпредлагает гибкие паттерны сотрудничества между агентами черного ящика, но не имеет стандартизированного метода использования инструмента или безопасной делегирования.
- Новые протоколыОбычно предлагает только узкие срезы возможностей, адаптированные к вертикальным приложениям (например, рыночные места агентов или робототехника).
Подразумеваемое
Неоднородность между протоколами отражает обаДивергентный дизайн философиииНеопределенность в отношении топологий развертывания агентовПолем В то время как MCP подчеркивает переносимость и быструю интеграцию, ACP и A2A приоритет рассуждениям и возникающей координации. Отсутствие унифицированного стека протоколов вызывает обеспокоенность у долгосрочной перспективысовместимостьВуправление, иРазработчик экосистема зрелостиПолем
Новые варианты использования включены взаимодействием
По мере развития архитектуры на основе агентов созревают спрос на сложную многоагентную координацию между рабочими процессами, приложениями и доменами данных усилился. Протоколы взаимодействия, такие какMCPВАтмосфера, иA2AВключить возможности, которые в противном случае были бы невозможными или хрупкими в изолированных развертываниях. В этом разделе описывается набор возникающих вариантов использования, когда совместимость с протоколом обеспечивает значительные функциональные или оперативные преимущества.
Посещение знаний межагента
В распределенных корпоративных системах агенты часто работают с неполной информацией. Финансовый агент может потребовать данных правовой политики; Агенту поддержки может понадобиться история CRM; Исследователь может запросить сторонние документы. Совместимые протоколы позволяют агентамЗапрос сверстников, не просто базы данных, как источники знаний.
- MCP: Позволяет агенту вызывать контекст памяти другого агента через хостированный сервер.
- Атмосфера: Поддерживает декларативные требования к данным с помощью запросов возможностей.
- A2A: Облегчает специальные обмены между экспертами, специфичными для домена.
Автономный состав рабочего процесса
В разработке программного обеспечения агенты могут выступать в качестве сотрудников, которые пишут код, запускают тесты, открывают запросы на вытяжение или анализируют телеметрию. Это невозможно без безопасного вызова инструмента, обмена памятью и распространения состояний между компонентами.
- MCP: Powers Github Copilot Agents и Claude Desktop с контекстной памятью и привязками инструментов.
- Атмосфера: Позволяет агентам вести переговоры о подзадатах и обязанностях (например, написание тестирования против развертывания).
- A2A: Полезно в сценариях обзора кода, включающих несколько помощников или ролей.
Ниже приведен пример запуска многоагентного продукта:
+-------------------+
| Product Manager |
+---------+---------+
|
[Delegates Goal]
▼
+-------------------+ +------------------+ +-------------------+
| Research Agent |<----->| Engineering AI |<----->| QA Agent |
+-------------------+ +------------------+ +-------------------+
| Context API | | Tool Calls | | Shared Logs |
+-------------+ +------------+ +--------------+
Безопасный агент делегация
Для критических рабочих процессов, таких как финансовая отчетность, юридический анализ или обеспечение облаков, должны быть прослеживаемые, разрешаемые и обратимые действия. Это требует поддержкиПрохождение проверки контекстаВограниченная делегация, ибезопасные пути вызоваПолем
- Атмосфера: Лучше всего подходит для намерения аудита и иерархического делегирования.
- MCP: Может быть расширен с API-интерфейсов на основе разрешений.
- Новые протоколы (например, AGP): Адрес RBAC и координация нулевого достопримечательности.
Оркэстрированное извлечение с аугментированным поколением (Rag)
Когда агенты координируются, чтобы ответить на сложные запросы, тряпичные трубопроводы получают выгоду от распределенного контроля:
- Один агент получает документы (ретривер)
- Другой синтезирует ответы (суммализатор)
- Третий фильтры или цитирует источники (валидатор)
Протоколы взаимодействияВключите разделение задач, непрерывность памяти и выходные ограничения по всему трубопроводу.
Сотрудничество в реальном времени в реальном времени
В поддержке клиентов и здравоохранения пользователи взаимодействуют с несколькими бэкэнд -агентами (диагностика, поиск знаний, планирование). Унифицированные протоколы позволяют разговорным агентам передать частичное понимание, оповещения и последующие вопросы через общую структуру-потерюКогерентные и персонализированные ответыПолем
Наблюдения
Совместимость - это не просто удобство - это архитектурная необходимость. Без координации на уровне протокола агенты становятся тесно связанными или дублируются по задачам, препятствуя масштабируемости системы, объяснения и расширяемости. Эти новые варианты использования иллюстрируют, как решения по проектированию протоколов влияют не только на технические показатели, но и наосуществимость целых классов приложенийПолем
Проблемы и ограничения
В то время как протоколы взаимодействия агентов позволили ранее неосуществимых многоагентных рабочих процессах, их принятие и надежность остаются ограниченными несколькими открытыми проблемами. Эти ограничения - не просто узкие места внедрения, аАрхитектурные, безопасность и проблемы с управлениемкоторые требуют скоординированного разрешения.
Отсутствие объединения протоколов
Текущая экосистема фрагментирована между конкурирующими спецификациями, оптимизированными для узкого варианта использования. MCP фокусируется на контексте и инструментах, ACP подчеркивает делегирование и планирование, в то время как A2A оптимизирован для эфемерного сотрудничества. Протокол в настоящее время не объединяетконтекст передачаВпризыв инструментаВпланирование намерений, иПостоянство памятив одном, формально определенном стеке.
- Разработчики сталкиваютсяЗаблокировка продавцаили должен построить хрупкие адаптеры.
- Проекты вынуждены выбирать между выразительностью и переносимостью.
- Отсутствие мета-протокола предотвращает динамические переговоры между агентами.
Границы безопасности и доверия
Агентные протоколы работают в конфиденциальных средах (например, финансы, юридические, здравоохранения), но модели безопасности не соответствуют или отсутствуют. Ключевые проблемы включают:
- Инструмент угон: Несанкционированные инструменты, вызванные манипулируемым контекстом.
- Отравление сервером: Злонамеренные агенты, вводящие в заблуждение воспоминания.
- Утечка контекста: Агенты непреднамеренно делятся историей пользователя или учетных данных.
ACLS (списки управления доступом), проверка идентификации и оценка доверия не поддерживаются в соответствии с текущими спецификациями протокола.
Ниже приведен пример модели оповещения об угрозах в агентских системах:
+-------------+
| User A |
+-------------+
|
▼
+--------------+ +-------------------+
| MCP Server |--------->| Malicious Agent |
+--------------+ +-------------------+
|
▼
[Context API Leak] — Agent B unintentionally consumes poisoned memory
Отсутствие спецификаций версии
В отличие от HTTP, GRPC или RESTFUL API, большинству протоколов агентов не хватаетУправление версиейВИзменить журналы, илитесты на соответствиеПолем Это создает:
- Хрупкие реализации, которые молча ломаются по обновлениям
- Плохая поддержка инструментов для обратной совместимости
- Высокие накладные расходы для агентов и SDK с открытым исходным кодом
Недостаточный инструмент разработчика
Принятие любого протокола требует надежной экосистемы:
- SDK на нескольких языках
- Инструменты валидации и снятия
- Среда живой песочницы
- Протокол Фуззоры и аудиты безопасности
В настоящее время MCP имеет наиболее активные инструменты, но он остается неформальным. ACP и A2A в значительной степени незарегистрированы или реализованы в частных условиях.
Отсутствие стандартизированной архитектуры памяти
В то время как агенты зависят от памяти для сохранения состояния по шагам, не существует общей спецификации для:
- Схема памяти (например, деревья сообщений, графики объектов)
- Местоположение памяти (централизованное против федерации)
- Синхронизация (политики толкания/тяги между агентами)
Это ограничивает перекрестные рабочие процессы и усложняет устранение версий, делеции или общие временные рамки.
Управление и фрагментация
Не существует рабочей группы в стиле IETF или W3C-эквивалентных контрольных протоколов. Как результат:
- Протоколы эволюционируют в бункерах (например, MCP Claude vs Meta's ACP)
- Лучшие практики редко используются
- Совместимость зависит от двусторонних усилий, а не соблюдения стандартов
В свете этих проблем, сплоченный путь вперед требует не только лучшей инженерии, но иСовместная спецификация управлениеВФормальные схемы протокола, иИнфраструктура инструментовПолем
К единому стандарту
Пролиферация протоколов взаимодействия агента, оптимизированных для различных абстракций, привело к разрушенной экосистеме, которая отражает раннюю сеть, до появления стандартов HTTP и Restful. Поскольку агенты берут на себя все более важную роль в инфраструктуре, принятии решений и автоматизации, отсутствие единого протокола связи становится ограничивающим фактором как для масштабируемости, так и для достоверности.
В этом разделе описывается концептуальная основа дляСтек протоколов единого агента (UAPS)- Компонируемая структура, интегрирующая память, делегирование и семантику выполнения инструментов в рамках общей схемы версии. Видение опирается на прецеденты в архитектуре интернет-протокола, сервис-ориентированных вычислительных системах и распределенных системах.
Плоховая философия дизайна
Надежный протокол агента должен разложить вЧетыре совместимых слоя, каждый с независимой эволюцией и инструментами:
- Транспортный слой: Обрабатывает маршрутизацию, гарантии доставки и шифрование (например, GRPC, http/2, websocket).
- Контекстная схема слой: Определяет сообщение, память и личность в формальной схеме (например, JSON-LD, Protobuf).
- Делегационный слой: Кодирует намерения деревьев, графиков возможностей и политики запасных.
- Выполнение слоя: Управляет инструментами, интерфейсами плагинов, ограничениями возврата значения и восстановлением ошибок.
Ниже приведено предложение о стеке протоколов единого агента:
+-------------------------------+
| Execution Layer | ← Tool Calls, Plugins, APIs
+-------------------------------+
| Delegation Layer | ← Intent Trees, Capability Graphs
+-------------------------------+
| Context Schema Layer | ← Message Format, Memory API
+-------------------------------+
| Transport Layer | ← gRPC / HTTP / WebSocket
+-------------------------------+
Формат спецификации и формальная семантика
Чтобы обеспечить долговечность и безопасность, унифицированный протокол должен быть:
- Машино читаемый: Определено в формальной схеме (например, схема JSON или буферы протокола).
- Контролируется версией: Каждый слой должен поддерживать независимую политику управления версиями и детективы.
- Композитный: Агенты должны иметь возможность динамически вести минимальные общие слои протокола.
- Тип-безопасность: Инструментальные вызовы и схемы памяти должны поддерживать строгое напечаток, чтобы уменьшить неопределенность времени выполнения.
Модель управления
Успешные усилия по объединению должны руководствоватьсяоткрытое управление, сродни IETF или W3C. Характеристики должны включать:
- Открытое участие: Исследователи, поставщики и независимые разработчики могут представлять проекты.
- Процесс на основе консенсуса: Стандарты проходят через этапы (например, проект, предлагаемый стандарт, RFC).
- Справочные реализации: Каждая версия спецификации должна сопровождаться SDK с открытым исходным кодом и тестовых люксов.
Совместные структуры, такие какРабочая группа протокола агента (APWG)или кросс-поставщикАгент Фондможет служить этой цели.
Роль крупных экосистемных актеров
Общины OpenAI, антроп, мета, Google DeepMind и OSS играют центральную роль в принятии протокола. Стратегическое выравнивание может начать с:
- Публикация внутренних характеристик для MCP, ACP и A2A
- Хостинг перекрестных тестов
- Совместное использование уроков из развертывания в прямом эфире (например, настольный компьютер Claude, агенты GitHub)
Совместимость с существующей работой
Вместо того, чтобы вытеснять текущие усилия, должен предложить единый стандарт:
- Адаптеры для MCP/ACP/A2A: Перевести устаревшие звонки в единую схему.
- Постепенное принятие: Позвольте агентам частично реализовать стек.
- Обертки безопасности: Интегрируйте существующие инструменты OAuth, RBAC и песочницы на уровне выполнения.
Хорошо указанный, модульный и управляемый сообществом стандарт может позволить будущее, когда агенты могут бесшовно разум, координировать и выполнять задачи между организациями, инструментами и областями, аналогичными, как HTTP, SMTP и TCP позволили сам Интернет.
Будущие направления исследований
В то время как текущие протоколы взаимодействия, такие как MCP, ACP и A2A, ведут в действие базовое сотрудничество с агентами, их архитектура по -прежнему в значительной степени формируется эвристикой, а не теорией. В поле не хватает тщательных фундаментов, которые характеризуют традиционные распределенные системы, протоколы связи и конструкцию компилятора. Следующий этап исследования должен продвигаться за пределы простой спецификации и изучениятеоретический, системный и этичныйпроблемы.
Формальная проверка поведения агента
Одним из наиболее важных областей исследований является обеспечение обеспеченияПравильность по делуВ сотрудничестве с агентом:
- Могут ли разговоры агента быть смоделированы с помощьюГосударственные машиныВпроцесс Calculi, илиТеория категории?
- Можно ли автоматически доказывать гарантии безопасности, жизнеобеспечения и увольнения для рабочих процессов агента?
- Можно ли расширить типы систем, чтобы включитьвременные ограниченияВраспространение возможностей, иИнварианты безопасности?
Ранние эксперименты с TLA+ для моделирования протокола являются многообещающими, но еще не распространены.
Намерение устранения неоднозначности и разрешения цели
Агенты часто работают в неявных целях. Совместимость разрушается, когда несколько агентов интерпретируют смутные намерения по -разному:
- Как могут быть намерения быть деревьяминормализованВранжированный, илиРешеноВ агентах с гетерогенными архитектурами?
- Какие стандарты могут представлятьсложные задачиВключая двусмысленность, терпимость к ошибкам или стохастическую политику?
Это требует пересечения исследования междумоделирование намеренийВвероятное планирование, иСемантическая абстракцияПолем
Децентрализованные доверительные модели
Сегодняшние агентские сети в значительной степени зависят от централизованного контроля (например, Openai, Anpropic, Meta). Долгосрочная жизнеспособность может зависеть отдостоверныйВпроверяемый, ифедеративныйАрхитектуры:
- Могут ли возможности агента подписаны и проверены с использованиемдоказательства нулевого знанияилиПроверенные учетные данные?
- Какая роль можетдецентрализованная идентичность (Do)иумные контрактыИграть в переговорах и аудиторских тропах?
Они соответствуют тенденциям вweb3ВSaaS Composability, иКрест-интерпротив ИИ рабочих процессовПолем
Переговоры о протоколе во время выполнения
Ограничением ядра тока протоколов является предположение, что все стороны имеют общую спецификацию. Требуется будущее, совместимое с форвардом:
- Переговоры на время выполнения поддерживаемых версий, плагинов и схем
- Поддержка длячастичное соответствиеиИзящная деградация
- Метапротоколы для описания того, как агенты могут адаптивно взаимодействовать
Эти концепции отражаютАльпнв http/2 илифункции флаговв распределенных системах, но зарождаются в пространстве агента.
Канонизация памяти и семантика на основе времени
По мере того, как агенты накапливают долгоживущую память, вызоввременная когерентностьВразрешение конфликта, иЭволюция схемыстановится срочным:
- Как многоагентные системы могут примириться непоследовательными воспоминаниями об общем событии?
- Есть ли необходимостьСообщениеВCRDTS, илиПротоколы слияния графикаДля воспоминаний агента?
- Может ли запрашивать памятьСемантические временные окна(например, «Последние 3 задачи с неудачными вызовами инструментов»)?
+-----------------------------+
| Formal Verification |
| - TLA+, Type Systems |
+-------------+---------------+
|
+-------------v---------------+
| Intent Resolution |
| - Semantic Trees, Planning |
+-------------+---------------+
|
+-------------v---------------+
| Decentralized Trust |
| - DIDs, ZKPs, Tokenized ACL |
+-------------+---------------+
|
+-------------v---------------+
| Runtime Negotiation |
| - Protocol Discovery, ALPN |
+-------------+---------------+
|
+-------------v---------------+
| Temporal Memory Models |
| - CRDTs, Event Graphs |
+-----------------------------+
Социальные и этические вопросы
Поскольку агенты координируются между компаниями и действуют автономно:
- Кто несет ответственность за сбои совместных агентов?
- Может ли возникающее поведение возникнуть из -за неправильного использования протокола?
- Должны ли агенты иметь разрешения на изменение или стирание памяти?
Это не просто инженерные вопросы, но затроляйтеВыравнивание ИИВуправление данными, ичеловеческие границыПолем
-
Поскольку агенты становятся инфраструктурой цифрового познания, протоколы, которые их связывают, должны быть надежными, интерпретируемыми и будущими. Создание таких стандартов потребует сотрудничества в разных дисциплинах: формальные методы, системная инженерия, HCI, этика и дизайн протокола. Дорога впереди открыта-но с правильными абстракциями, будущее агентского сотрудничества может бытьОсновной, как TCP/IP для ИнтернетаПолем
Оригинал