Skip to main content
Запускайте кілька ізольованих агентів в одному процесі Gateway, кожен із власним робочим простором, каталогом стану (agentDir) та історією сеансів у SQLite, а також кілька облікових записів каналів (наприклад, два номери WhatsApp). Вхідні повідомлення спрямовуються до відповідного агента через прив’язки. Агент — це повна область окремої персони: файли робочого простору, профілі автентифікації, реєстр моделей і сховище сеансів. Прив’язка зіставляє обліковий запис каналу (робочий простір Slack, номер WhatsApp тощо) з одним із цих агентів.

Що таке один агент

Кожен агент має власні:
  • Робочий простір: файли, AGENTS.md/SOUL.md/USER.md, локальні нотатки, правила персони.
  • Каталог стану (agentDir): профілі автентифікації, реєстр моделей, конфігурація окремого агента.
  • Сховище сеансів: історія чатів і стан маршрутизації в ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite.
Профілі автентифікації належать окремим агентам і зчитуються з:
sessions_history — безпечніший спосіб відновлення контексту між сеансами: він повертає обмежене, відредаговане подання, а не повний необроблений дамп транскрипту. Він вилучає сигнатури блоків міркувань, подробиці корисного навантаження результатів інструментів, службову структуру <relevant-memories>, XML-теги викликів інструментів (<tool_call>, <function_call> та їхні множинні/понижені форми) і XML викликів інструментів MiniMax, після чого скорочує та обмежує виведення за розміром у байтах.
Ніколи не використовуйте agentDir повторно для різних агентів — це спричиняє колізії стану автентифікації та сеансів. Коли локальні облікові дані OAuth другорядного агента прострочені або їх оновлення не вдається, OpenClaw звертається до облікових даних типового/головного агента для того самого ідентифікатора профілю та приймає найновіший токен, не копіюючи токен оновлення до сховища другорядного агента. Якщо потрібен повністю незалежний обліковий запис OAuth, увійдіть у нього від імені цього агента. Якщо копіюєте облікові дані вручну, копіюйте лише переносні статичні профілі api_key або token — матеріали оновлення OAuth типово не є переносними (copyToAgents дає змогу явно дозволити це для профілю).
Skills завантажуються з робочого простору кожного агента та зі спільних коренів, як-от ~/.openclaw/skills, а потім фільтруються за чинним списком дозволених навичок агента. Використовуйте agents.defaults.skills для спільної базової конфігурації та agents.list[].skills для заміни на рівні агента (явні записи замінюють типові, а не об’єднуються з ними). Див. Skills: для окремих агентів і спільні та Skills: списки дозволів агентів. Сховище, яким володіє Plugin, відповідає конфігурації цього Plugin; додавання другого агента не розділяє автоматично кожне глобальне сховище Plugin. Наприклад, налаштуйте сховища Memory Wiki для окремих агентів, коли персони не повинні спільно використовувати скомпільовані знання вікі.
Примітка про робочий простір: робочий простір кожного агента є типовим cwd, а не жорсткою пісочницею. Відносні шляхи визначаються в межах робочого простору, але абсолютні шляхи можуть надавати доступ до інших розташувань на хості, якщо пісочницю не ввімкнено. Див. Пісочниця.

Шляхи

Режим одного агента (типовий)

Якщо нічого не налаштовувати, OpenClaw запускає одного агента:
  • agentId типово має значення main.
  • Ключ сеансів має вигляд agent:main:<mainKey> (типовий mainKeymain).
  • Робочий простір типово має значення ~/.openclaw/workspace (або workspace-<profile>, коли OPENCLAW_PROFILE має значення, відмінне від default).
  • Стан типово зберігається в ~/.openclaw/agents/main/agent.

Допоміжний засіб для агентів

Додайте нового ізольованого агента:
Прапорці: --workspace <dir>, --model <id>, --agent-dir <dir>, --bind <channel[:accountId]> (можна повторювати), --non-interactive (потребує --workspace). Додайте bindings, щоб маршрутизувати вхідні повідомлення (майстер запропонує зробити це), а потім перевірте:

Швидкий початок

1

Створіть робочий простір для кожного агента

Кожен агент отримує власний робочий простір із SOUL.md, AGENTS.md та необов’язковим USER.md, а також окремий agentDir і сховище сеансів у ~/.openclaw/agents/<agentId>.
2

Створіть облікові записи каналів

Створіть по одному обліковому запису для кожного агента у вибраних каналах:
  • Discord: окремий бот для кожного агента; увімкніть Message Content Intent і скопіюйте кожен токен.
  • Telegram: окремий бот для кожного агента через BotFather; скопіюйте кожен токен.
  • WhatsApp: прив’яжіть окремий номер телефону до кожного облікового запису.
Див. посібники з каналів: Discord, Telegram, WhatsApp.
3

Додайте агентів, облікові записи та прив’язки

Додайте агентів у agents.list, облікові записи каналів у channels.<channel>.accounts і з’єднайте їх за допомогою bindings (приклади нижче).
4

Перезапустіть і перевірте

Кілька агентів, кілька персон

Кожен налаштований agentId є окремою межею персони для основного стану агента:
  • Різні облікові записи для кожного каналу (за accountId).
  • Різні особистості (AGENTS.md/SOUL.md для кожного агента).
  • Окремі автентифікація та сеанси; міжагентний доступ вмикається лише через явно визначені функції або конфігурацію Plugin.
Це дає змогу кільком людям спільно використовувати один Gateway, зберігаючи основний стан агентів розділеним.

Сховища Memory Wiki для окремих агентів

Memory Wiki типово використовує одне глобальне сховище. Щоб зберігати скомпільовані знання агента підтримки окремо від знань маркетингового агента, установіть для plugins.entries.memory-wiki.config.vault.scope значення agent:
Налаштований шлях є батьківським каталогом. OpenClaw додає нормалізований ідентифікатор агента, утворюючи такі шляхи, як ~/.openclaw/wiki/support і ~/.openclaw/wiki/marketing. Операції CLI та Gateway в області агента потребують явного зазначення агента, коли налаштовано кількох агентів. Докладніше про фільтрацію мосту, міграцію та межі довіри див. у розділі Сховища Memory Wiki для окремих агентів.

Міжагентний пошук у пам’яті QMD

Щоб один агент міг шукати в транскриптах сеансів QMD іншого агента, додайте додаткові колекції в agents.list[].memorySearch.qmd.extraCollections. Використовуйте agents.defaults.memorySearch.qmd.extraCollections, коли всі агенти повинні спільно використовувати ті самі колекції.
Шлях додаткової колекції може бути спільним для кількох агентів, але його name залишається явним, коли шлях розташований поза робочим простором агента. Шляхи в межах робочого простору залишаються прив’язаними до агента, щоб кожен агент мав власний набір пошуку транскриптів.

Один номер WhatsApp, кілька людей (розподіл особистих повідомлень)

Спрямовуйте різні особисті повідомлення WhatsApp до різних агентів в одному обліковому записі WhatsApp, зіставляючи відправника E.164 (+15551234567) за допомогою peer.kind: "direct". Відповіді все одно надходять із того самого номера WhatsApp — окремої ідентичності відправника для кожного агента немає.
Типово особисті чати об’єднуються в ключ головного сеансу агента, тому для справжньої ізоляції потрібен окремий агент для кожної людини.
Керування доступом до особистих повідомлень (сполучення/список дозволених) є глобальним для облікового запису WhatsApp, а не окремим для кожного агента. Для спільних груп прив’яжіть групу до одного агента або використовуйте Групи трансляції.

Правила маршрутизації

Прив’язки детерміновані, і перемагає найконкретніша. Повний порядок рівнів (точний співрозмовник, батьківський співрозмовник, шаблон співрозмовника, сервер+ролі, сервер, команда, обліковий запис, канал, типовий агент) див. у розділі Маршрутизація каналів. Тут варто окремо зазначити кілька правил:
  • Якщо в межах одного рівня збігається кілька прив’язок, перемагає перша в порядку конфігурації.
  • Якщо прив’язка задає кілька полів зіставлення (наприклад, peer + guildId), усі зазначені поля мають збігатися (семантика AND).
  • Прив’язка без accountId відповідає лише типовому обліковому запису, а не всім обліковим записам. Використовуйте accountId: "*" як резервний варіант для всього каналу або accountId: "<name>" для одного облікового запису. Повторне додавання тієї самої прив’язки з явним ідентифікатором облікового запису оновлює наявну прив’язку лише до каналу, а не дублює її.

Кілька облікових записів / номерів телефонів

Канали, які підтримують кілька облікових записів (наприклад, WhatsApp), використовують accountId для ідентифікації кожного входу. Кожен accountId спрямовується до власного агента, тому один сервер може обслуговувати кілька номерів телефонів без змішування сеансів. Встановіть channels.<channel>.defaultAccount, щоб вибрати обліковий запис, який використовується, коли accountId не вказано. Якщо значення не задано, OpenClaw використовує default, якщо він наявний, інакше — ідентифікатор першого налаштованого облікового запису (після сортування). Канали з підтримкою кількох облікових записів: discord, feishu, googlechat, imessage, irc, line, mattermost, matrix, nextcloud-talk, nostr, signal, slack, telegram, whatsapp, zalo, zalouser.

Поняття

  • agentId: один «мозок» (робочий простір, автентифікація окремого агента, сховище сеансів окремого агента).
  • accountId: один екземпляр облікового запису каналу (наприклад, обліковий запис WhatsApp personal на відміну від biz).
  • binding: спрямовує вхідні повідомлення до agentId за (channel, accountId, peer) і, за потреби, за ідентифікаторами гільдії/команди.
  • Особисті чати зводяться до agent:<agentId>:<mainKey> («основного» для окремого агента; див. session.mainKey).

Приклади для платформ

Кожен обліковий запис бота Discord зіставляється з унікальним accountId. Прив’яжіть кожен обліковий запис до агента й ведіть окремі списки дозволених значень для кожного бота.
  • Запросіть кожного бота до гільдії та ввімкніть Message Content Intent.
  • Токени зберігаються в channels.discord.accounts.<id>.token (обліковий запис за замовчуванням може використовувати DISCORD_BOT_TOKEN).
  • Створіть окремого бота для кожного агента за допомогою BotFather і скопіюйте кожен токен.
  • Токени зберігаються в channels.telegram.accounts.<id>.botToken (обліковий запис за замовчуванням може використовувати TELEGRAM_BOT_TOKEN).
  • Якщо в одній групі Telegram є кілька ботів, запросіть кожного з них і згадайте того, який має відповісти.
  • Вимкніть Privacy Mode у BotFather для кожного групового бота (/setprivacy -> Disable), а потім видаліть і повторно додайте бота, щоб Telegram застосував налаштування.
  • Дозволяйте групи за допомогою channels.telegram.groups або використовуйте groupPolicy: "open" лише для розгортань у довірених групах.
  • Додайте ідентифікатори користувачів-відправників до groupAllowFrom. Ідентифікатори груп і супергруп слід додавати до channels.telegram.groups, а не до groupAllowFrom.
  • Виконайте прив’язування за accountId, щоб кожен бот спрямовував повідомлення до свого агента.
Зв’яжіть кожен обліковий запис перед запуском Gateway:
~/.openclaw/openclaw.json (JSON5):

Поширені шаблони

Розділіть за каналами: спрямовуйте WhatsApp до швидкого агента для повсякденних завдань, а Telegram — до агента Opus.
У цих прикладах використовується accountId: "*", тому прив’язки продовжать працювати, якщо згодом додати облікові записи. Щоб спрямувати один особистий чат або групу до Opus, залишивши решту на агенті чату, додайте прив’язку match.peer для цього співрозмовника — збіги за співрозмовником завжди мають пріоритет над правилами для всього каналу.

Налаштування пісочниці та інструментів для кожного агента

Кожен агент може мати власну пісочницю й обмеження інструментів:
setupCommand міститься в sandbox.docker і виконується один раз під час створення контейнера. Перевизначення sandbox.docker.* для окремих агентів ігноруються, якщо визначена область — "shared".
Це надає:
  • Ізоляцію безпеки: обмеження інструментів для недовірених агентів.
  • Керування ресурсами: запуск окремих агентів у пісочниці, тоді як інші працюють на хості.
  • Гнучкі політики: різні дозволи для кожного агента.
tools.elevated має як глобальну перевірку (tools.elevated.enabled/allowFrom), так і перевірку для окремого агента (agents.list[].tools.elevated.enabled/allowFrom). Перевірка для окремого агента може лише додатково обмежити глобальну — обидві мають дозволяти відправника, щоб команди з підвищеними привілеями могли виконуватися. Для вибору агента в групі використовуйте agents.list[].groupChat.mentionPatterns, щоб @згадки однозначно зіставлялися з потрібним агентом.
Докладні приклади див. у розділі Пісочниця та інструменти для кількох агентів.

Пов’язані матеріали