openclaw настройка: пошаговое руководство

Материал основан на разборе freecodecamp.org. Ниже — главное и практические шаги, которые можно быстро применить в работе.

---

OpenClaw представляет интерес как решение, позволяющее реализовать концепцию ИИ в виде самостоятельного инструмента. Вместо необходимости открывать новые вкладки в браузере, вы запускаете Gateway на своем компьютере или сервере и связываете его с вашими коммуникационными инструментами.

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

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

Важно отметить, что интеграция A2A в этой статье представлена не как стандартная функция OpenClaw, а как альтернативное архитектурное предложение, основанное на уже существующих точках расширения.

Предварительные требования

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

Прежде чем продолжить, вы должны быть знакомы со следующим:

• Базовый JavaScript или Node.js (чтение и запуск скриптов)
• Принципы работы HTTP API (запросы, ответы, JSON-данные)
• Использование терминала для выполнения команд
• Высокоуровневые концепции, такие как сервисы, API или микросервисы

Предварительный опыт работы с OpenClaw или A2A не требуется. Шаги по настройке охватывают всё необходимое для начала работы.

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

По этой теме полезно отдельно посмотреть Создание динамических форм в React и Next.js, чтобы расширить контекст и сравнить подходы.

Что такое OpenClaw

Согласно официальным источникам, OpenClaw — это саморазмещаемый шлюз (Gateway), предназначенный для интеграции таких мессенджеров, как WhatsApp, Telegram, Discord, iMessage, а также браузерной панели управления с ИИ-агентами.

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

Если вы новичок в этом проекте, вот практический способ думать о нём:

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

Это одна из причин, по которой OpenClaw ощущается иначе, чем обычный браузерный ассистент.

Почему разработчики обращают внимание на OpenClaw

OpenClaw привлекает много внимания по нескольким причинам.

Первая причина — контроль. Документация позиционирует OpenClaw как саморазмещаемый и многоканальный инструмент, что позволяет запускать его на своем собственном компьютере или сервере, а не полагаться на полностью управляемые решения.

Вторая причина заключается в том, что OpenClaw уже представляет собой агентную платформу. Документация охватывает сессии, плагины, инструменты, навыки, многоагентную маршрутизацию и внешние среды разработки на базе ACP, что гораздо более интересно, чем просто «задать вопрос модели на сайте».

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

За этим ажиотажем стоит и более широкая отраслевая тенденция. Разработчики активно ищут способы соединить несколько агентов и несколько инструментов, не теряя видимости происходящего. OpenClaw находится прямо в центре этого разговора.

Что такое протокол A2A

A2A, сокращение от Agent2Agent, — это открытый протокол для взаимодействия между агентными системами. Спецификация A2A гласит, что его цель — помочь независимым агентным системам обнаруживать друг друга, согласовывать режимы взаимодействия, управлять совместными задачами и обмениваться информацией, не раскрывая внутреннюю память, инструменты или проприетарную логику.

Последний момент важен. A2A — это об интероперабельности между агентными системами, а не о раскрытии всех внутренних компонентов одного агента другому.

A2A вводит несколько ключевых концепций, которые стоит изучить заранее:

• Agent Card — JSON-описание удалённого агента, его URL, навыков, возможностей и требований к аутентификации
• Task (задача) — основная единица удалённой работы
• Artifact (артефакт) — результат выполнения задачи
• Context ID (идентификатор контекста) — стабильная граница взаимодействия для нескольких связанных обменов

Документация A2A также поясняет, что A2A и MCP являются взаимодополняющими, а не конкурирующими. A2A предназначен для взаимодействия агент-агент. MCP — для взаимодействия агент-инструмент.

Это различие полезно при сравнении A2A с OpenClaw, поскольку OpenClaw уже имеет развитые локальные концепции инструментов и сессий.

Как соотносятся OpenClaw и A2A

OpenClaw и A2A — это не одно и то же, но они совпадают в интересных точках.

OpenClaw уже документирует несколько функций, указывающих в направлении многоагентности:

• многоагентная маршрутизация для нескольких изолированных агентов в одном запущенном Gateway
• инструменты сессий, такие как sessions_send и sessions_spawn
• система плагинов, которая может регистрировать инструменты, HTTP-маршруты, методы Gateway RPC и фоновые сервисы
• поддержка ACP и openclaw acp bridge для внешних клиентов разработки

Однако здесь важно сохранять точность.

OpenClaw документирует ACP, плагины и локальную многоагентную координацию на сегодняшний день. Документация, которую я изучил, не описывает нативную поддержку A2A как первоклассную встроенную возможность.

Это означает, что честное утверждение звучит так: OpenClaw теоретически может быть осмысленно подключён к A2A, поскольку архитектурные компоненты совпадают, однако мост A2A всё равно нужно построить.

ACP в сравнении с A2A: в чём разница

ACP и A2A решают разные задачи.

ACP в OpenClaw сегодня — это о подключении IDE или клиента разработки к сессии, поддерживаемой Gateway.

A2A — это о том, как одна агентная система общается с другой агентной системой через границу протокола.

Это различие является одной из причин, по которой я предпочитаю здесь фразу «мост плагинов» вместо «нативная поддержка A2A».

Что нужно перед началом работы

Для первого запуска не требуются WhatsApp, Telegram или Discord.

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

Перед началом вам понадобится:

• Node 24, если возможно, или Node 22.16+ для совместимости
• API-ключ для провайдера модели, которого вы хотите использовать
• Если вы работаете в Windows, WSL2 является рекомендуемым путём для полноценного опыта. Нативный Windows работает для основных потоков CLI и Gateway, однако документация указывает на оговорки и позиционирует WSL2 как более стабильную настройку
• Около пяти минут для первого запуска на основе панели управления

Шаг 1: Установка и настройка OpenClaw

Официальная страница быстрого старта рекомендует использовать скрипт установщика.

На macOS, Linux или WSL2 выполните:

curl -fsSL https://openclaw.ai/install.sh | bash

На Windows PowerShell документация показывает следующее:

iwr -useb https://openclaw.ai/install.ps1 | iex

Если вы работаете на Windows, документация платформы рекомендует сначала установить WSL2:

wsl --install

Затем откройте Ubuntu и продолжайте там с командами для Linux.

Шаг 2: Запуск мастера первоначальной настройки

После установки CLI запустите мастер первоначальной настройки (onboarding wizard):

openclaw onboard --install-daemon

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

Наиболее дружелюбный для новичков выбор — сохранить первый запуск простым. Пока не беспокойтесь о чат-приложениях. Сначала добейтесь работы локального Gateway.

Шаг 3: Проверка Gateway и открытие Agent Dashboard

После первоначальной настройки убедитесь, что Gateway работает:

openclaw gateway status

Затем откройте dashboard:

openclaw dashboard

Документация называет это самым быстрым первым чатом, поскольку он позволяет избежать настройки каналов. Это также самый безопасный способ начать работу, потому что dashboard является локальным, а документация OpenClaw прямо указывает, что Control UI — это административная поверхность, которую не следует открывать публично.

Если вы можете общаться в dashboard, значит ваша начальная настройка работает.

Шаг 4: Использование OpenClaw как приватного помощника по программированию

Лучший первый сценарий использования — не добавлять OpenClaw в публичный групповой чат.

Используйте его как приватного помощника по программированию в dashboard. Например, попробуйте такой промпт:

I am building a small Node.js utility that reads Markdown files and generates a table of contents. Turn this idea into a project plan, a README outline, and the first five implementation tasks.

Такой промпт идеален для первого запуска, потому что он сразу даёт вам что-то конкретное в ответ.

Вы также можете использовать его для того, чтобы:

• превратить черновые заметки в план
• обобщить отчёт об ошибке в список задач
• составить README
• предложить структуру папок
• написать безопасный первоначальный чеклист реализации

Этого уже достаточно, чтобы сделать OpenClaw полезным, прежде чем вы приступите к какой-либо продвинутой работе с протоколами.

Шаг 5: Многоагентная маршрутизация и Agent Swarm в OpenClaw

Как только базовая настройка заработает, полезно разобраться в локальной модели мультиагентности OpenClaw.

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

Это означает, что можно представить себе такие конфигурации:

• персональный ассистент
• помощник по программированию
• исследовательский ассистент
• ассистент для оповещений

Вам не нужно настраивать это в первый день. Но это важно для обсуждения A2A, потому что как только вы поймёте, как работают маршруты OpenClaw между локальными агентами, станет намного проще думать о маршрутизации задач к удалённым агентам через такой протокол, как A2A.

Как A2A plugin встраивается в архитектуру OpenClaw

A2A может вписаться в OpenClaw двумя широкими способами.

Вариант 1: OpenClaw как A2A-клиент

В этой модели OpenClaw остаётся вашим персональным граничным ассистентом.

Он получает запрос из dashboard или чат-приложения, решает, что задача требует специалиста, обнаруживает удалённого A2A-агента через Agent Card, отправляет задачу, ожидает обновлений или артефактов и переводит результат обратно в обычный ответ OpenClaw.

Это более чистая история для персонального ассистента. OpenClaw остаётся парадным входом, а A2A становится путём делегирования за кулисами.

Вариант 2: OpenClaw как A2A-сервер

В этой модели OpenClaw открывает часть своих собственных возможностей другим агентам.

Плагин теоретически мог бы публиковать A2A Agent Card, рекламировать узкий набор навыков, принимать A2A-задачи и сопоставлять эти задачи с сессиями OpenClaw или запусками под-агентов.

Это технически осуществимо, поскольку система плагинов может регистрировать HTTP-маршруты, инструменты, методы Gateway и фоновые сервисы.

Это также более рискованное направление для персонального ассистента, именно поэтому я считаю, что правильной отправной точкой является подход «клиент прежде всего».

Предлагаемая архитектура плагина-моста OpenClaw — A2A

Этот раздел является моим оригинальным вкладом в статью.

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

Цель дизайна проста: повторно использовать OpenClaw для пользовательских разговоров и доступа к локальным инструментам, но использовать A2A только тогда, когда удалённый агент-специалист является лучшим местом для выполнения работы.

Почему этот дизайн хорошо подходит для OpenClaw

Это предложение основано на точках расширения, которые OpenClaw уже документирует.

Плагин может регистрировать:

• инструмент агента для делегирования
• метод Gateway для проверки работоспособности и диагностики
• HTTP-маршрут для будущих обратных вызовов или верификации вебхуков
• фоновый сервис для прогрева кэша, подписок на задачи или очистки

Это означает, что мост не должен модифицировать ядро OpenClaw, чтобы быть жизнеспособным.

Таблица сопоставления

Наиболее важное решение в дизайне — это то, как сопоставить модель сессий OpenClaw с моделью задач A2A.

Концепция OpenClaw	Концепция A2A	Примечание
Session	Context ID	Долгоживущая разговорная граница
Ход агента	Task	Одно делегированное выполнение
Ответ агента	Artifact	Нормализованный результат
Плагин-инструмент	Agent Card	Точка обнаружения удалённого агента

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

Дизайн в одном предложении

Инструмент a2a_delegate должен:

• разрешать удалённый Agent Card из списка разрешённых
• повторно использовать существующий A2A contextId для текущего sessionKey, когда это возможно
• создавать новую удалённую Task для нового делегированного хода
• нормализовывать удалённые артефакты обратно в простой локальный ответ
• никогда не открывать весь Gateway OpenClaw напрямую в публичный интернет

Мне нравится этот дизайн, потому что он инкрементален, тестируем и согласуется с моделью доверия OpenClaw как персонального ассистента.

Создание демонстрационного ретранслятора

Чтобы сделать архитектуру конкретной, я собрал небольшой демонстрационный ретранслятор.

https://github.com/natarajsundar/openclaw-a2a-secure-agent-runtime

Он намеренно небольшой. Он не пытается стать полноценным production-плагином. Вместо этого он доказывает самую сложную концептуальную часть моста: как сопоставить одну сессию OpenClaw с повторно используемым контекстом A2A, создавая при этом новую задачу A2A для каждого делегированного хода.

Вот структура репозитория:

openclaw-a2a-secure-agent-runtime/
├── README.md
├── package.json
├── examples/
│ └── openclaw-plugin-entry.example.ts
├── src/
│ ├── a2a-client.mjs
│ ├── agent-card-cache.mjs
│ ├── demo.mjs
│ ├── mock-remote-agent.mjs
│ ├── openclaw-a2a-relay.mjs
│ ├── session-task-map.mjs
│ └── utils.mjs
└── test/ └── relay.test.mjs

Доказательство концепции (PoC) выполняет шесть действий:

1. получает удалённую карточку агента (Agent Card) из /.well-known/agent-card.json
2. кэширует её с простой ревалидацией по ETag
3. записывает сопоставления локального sessionKey с удалённым contextId
4. отправляет запрос A2A SendMessage
5. опрашивает GetTask до завершения задачи
6. преобразует удалённый артефакт в локальный текстовый ответ

Запуск демонстрации

Репозиторий использует только встроенные модули Node.js:

cd openclaw-a2a-secure-agent-runtime
npm run demo

Демонстрация запускает мок-сервер удалённого A2A, делегирует одну задачу, делегирует вторую задачу из той же локальной сессии и показывает, что один и тот же удалённый contextId используется повторно.

Основная идея ретранслятора

Вот важная логика простыми словами:

• найти последнее удалённое сопоставление для текущего sessionKey OpenClaw
• повторно использовать старый contextId, если он существует
• создать новую задачу A2A для нового запроса
• опрашивать до тех пор, пока задача не перейдёт в состояние TASK_STATE_COMPLETED
• преобразовать возвращённый артефакт в обычный текстовый результат, который OpenClaw может отправить обратно пользователю

Это делает мост предсказуемым. Вот сокращённая версия логики ретранслятора:

const previous = await sessionTaskMap.latestForSession(sessionKey, remoteBaseUrl);
const contextId = previous?.contextId ?? crypto.randomUUID();
const sendResult = await client.sendMessage({ text, contextId, metadata: { openclawSessionKey: sessionKey, requestedSkillId: skillId, },
});
let task = sendResult.task;
while (!isTerminalTaskState(task.status?.state)) { await sleep(pollIntervalMs); task = await client.getTask(task.id);
}
return { contextId, taskId: task.id, answer: taskArtifactsToText(task),
};

Это и есть сердце дизайна.

Почему этот репозиторий является полезным доказательством концепции

Многие статьи об «интеграции» остаются слишком абстрактными. Этот репозиторий избегает этой проблемы тремя способами.

Во-первых, он делает сопоставление сессии с контекстом явным.

Во-вторых, он включает мок-агент удалённого A2A, чтобы можно было протестировать поток без необходимости в большой внешней инфраструктуре.

В-третьих, он включает тест, который проверяет наиболее важный инвариант: повторные делегирования из одной локальной сессии OpenClaw повторно используют один и тот же контекст A2A.

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

Как доказательство концепции соотносится с реальным плагином OpenClaw

Доказательство концепции — это ядро ретранслятора.

Реальный плагин OpenClaw обернул бы этот ретранслятор четырьмя поверхностями расширения, которые уже описаны в документации OpenClaw.

1: Инструмент делегирования

Это основная точка входа.

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

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

2: Метод шлюза для диагностики

Метод вроде a2a.status позволил бы проверить, работает ли ретранслятор нормально, какие удалённые карточки кэшированы и отслеживаются ли ещё какие-либо задачи.

Это намного лучше, чем просить модель «сказать мне, работает ли мост нормально».

3: HTTP-маршрут плагина

Возможно, это не понадобится в первый день.

Но как только вы выйдете за рамки опроса и захотите обратные вызовы в стиле push или верификацию вебхуков, маршрут плагина даёт вам правильную границу для этой работы.

4: Фоновый сервис

Небольшой сервис — это чистое место для прогрева кэша, очистки или последующей обработки подписок.

Это позволяет пути инструмента сосредоточиться на делегировании, а не на обслуживании.

Если бы я превращал это в реальный пакет плагина, я бы выстроил работу в следующем порядке:

1. обернуть ретранслятор в registerTool
2. добавить небольшую схему конфигурации с белым списком удалённых агентов
3. добавить a2a.status
4. оставить опрос в качестве первой асинхронной модели
5. добавить маршрут обратного вызова только если реальный сценарий использования потребует этого

Это наиболее практичный путь от теории к реальному расширению.

Я протестировал поток ретранслятора локально с мок-агентом удалённого сервера и подтвердил, что повторные делегирования из одной и той же локальной сессии повторно использовали один и тот же удалённый contextId.

Замечания по безопасности, которые нельзя пропустить

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

Это напрямую влияет на A2A.

A2A разработан для коммуникации между агентными системами и организационными границами. Это мощно, но это также иная модель угроз по сравнению с единым приватным развёртыванием OpenClaw.

Поэтому менее безопасный дизайн выглядит так:

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

Более безопасный дизайн предполагает две отдельные границы доверия.

Слева — ваше приватное развёртывание OpenClaw. Оно включает ваш Gateway, ваши сессии, ваше рабочее пространство и любые учётные данные или инструменты, к которым может обращаться ваш агент. Эта граница рассчитана на единственного доверенного оператора.

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

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

Такое разделение позволяет экспериментировать с интероперабельностью агентов, сохраняя при этом безопасность среды персонального ассистента.

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

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

Почему именно такой дизайн, а не другой

Закономерный вопрос: почему в этой статье сначала предлагается мост A2A только для исходящих запросов, а не сразу строится полная двунаправленная или серверная интеграция.

Краткий ответ: текущий дизайн OpenClaw ориентирован на границу доверия персонального ассистента, где один оператор контролирует Gateway, сессии и инструменты. Введение внешних агентов в эту среду требует тщательного контроля над тем, что открывается.

Начало с исходящего делегирования даёт более безопасный и постепенный путь.

Подход «только исходящие запросы» сначала означает:

• сохранение границы доверия персонального ассистента, так что ваше локальное развёртывание OpenClaw остаётся приватным и подконтрольным оператору
• отказ от открытия OpenClaw Gateway как публичного A2A-сервера до тех пор, пока не будут обеспечены надёжная аутентификация, политики и мониторинг
• возможность тестировать паттерны удалённого делегирования (Agent Cards, задачи, артефакты) без принятия на себя всей сложности полной интероперабельности
• сохранение OpenClaw в роли пользовательской плоскости управления, тогда как удалённые агенты выступают в роли опциональных специалистов

Этот подход следует распространённому паттерну проектирования систем: начать с контролируемой исходящей интеграции, проверить поведение и ограничения, и только затем рассматривать расширение до входящей или двунаправленной коммуникации.

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

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

Простейший путь для начинающих по-прежнему остаётся правильным:

1. установить его
2. запустить онбординг
3. проверить Gateway
4. открыть dashboard
5. попробовать один приватный рабочий процесс

Это уже полноценная сквозная настройка.

A2A заслуживает упоминания, потому что даёт вам реальный способ подключить OpenClaw к удалённым агентам-специалистам в дальнейшем.

Но самое важное в этой статье — не модное слово. Это дизайн границ.

Если вы сохраняете OpenClaw как приватный пользовательский край и используете узкий мост-плагин для исходящего делегирования, модель сессий OpenClaw и модель задач A2A могут органично сочетаться друг с другом.

Это та архитектурная идея, которую я хотел сделать конкретной здесь.

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

Нужно ли настраивать WhatsApp или Telegram, чтобы начать работу с OpenClaw?

Нет. Документация OpenClaw прямо указывает, что самый быстрый первый чат — это встроенная панель управления (dashboard). Чат-каналы можно подключить позже, когда базовая настройка уже работает.

Чем A2A отличается от MCP в контексте OpenClaw?

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

Безопасно ли открывать OpenClaw Gateway публично для приёма A2A-запросов?

Документация OpenClaw явно предупреждает, что Control UI не следует открывать публично, а сам проект рассчитан на модель доверия единственного оператора. Поэтому рекомендуемый подход — начинать с исходящего делегирования через контролируемый ретранслятор, а не открывать Gateway как публичный A2A-сервер.

Что такое Context ID в протоколе A2A и зачем его повторно использовать?

Context ID — это стабильная граница взаимодействия для нескольких связанных обменов. Повторное использование одного Context ID для задач из одной сессии OpenClaw позволяет удалённому агенту сохранять контекст разговора между делегированиями, что делает поведение моста предсказуемым.

Можно ли запустить демонстрационный ретранслятор без внешней инфраструктуры?

Да. Репозиторий включает мок-агент удалённого A2A и использует только встроенные модули Node.js. Достаточно выполнить npm run demo — демонстрация запустит мок-сервер локально и покажет полный цикл делегирования без необходимости в реальных внешних агентах.