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, після чого скорочує та обмежує виведення за розміром у байтах.~/.openclaw/skills, а потім фільтруються за чинним списком дозволених навичок агента. Використовуйте agents.defaults.skills для спільної базової конфігурації та agents.list[].skills для заміни на рівні агента (явні записи замінюють типові, а не об’єднуються з ними). Див. Skills: для окремих агентів і спільні та Skills: списки дозволів агентів.
Сховище, яким володіє Plugin, відповідає конфігурації цього Plugin; додавання другого агента не розділяє автоматично кожне глобальне сховище Plugin. Наприклад, налаштуйте сховища Memory Wiki для окремих агентів, коли персони не повинні спільно використовувати скомпільовані знання вікі.
Примітка про робочий простір: робочий простір кожного агента є типовим cwd, а не жорсткою пісочницею. Відносні шляхи визначаються в межах робочого простору, але абсолютні шляхи можуть надавати доступ до інших розташувань на хості, якщо пісочницю не ввімкнено. Див. Пісочниця.
Шляхи
Режим одного агента (типовий)
Якщо нічого не налаштовувати, OpenClaw запускає одного агента:agentIdтипово має значенняmain.- Ключ сеансів має вигляд
agent:main:<mainKey>(типовийmainKey—main). - Робочий простір типово має значення
~/.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, Telegram, WhatsApp.
- Discord: окремий бот для кожного агента; увімкніть Message Content Intent і скопіюйте кожен токен.
- Telegram: окремий бот для кожного агента через BotFather; скопіюйте кожен токен.
- WhatsApp: прив’яжіть окремий номер телефону до кожного облікового запису.
3
Додайте агентів, облікові записи та прив’язки
Додайте агентів у
agents.list, облікові записи каналів у channels.<channel>.accounts і з’єднайте їх за допомогою bindings (приклади нижче).4
Перезапустіть і перевірте
Кілька агентів, кілька персон
Кожен налаштованийagentId є окремою межею персони для основного стану агента:
- Різні облікові записи для кожного каналу (за
accountId). - Різні особистості (
AGENTS.md/SOUL.mdдля кожного агента). - Окремі автентифікація та сеанси; міжагентний доступ вмикається лише через явно визначені функції або конфігурацію Plugin.
Сховища Memory Wiki для окремих агентів
Memory Wiki типово використовує одне глобальне сховище. Щоб зберігати скомпільовані знання агента підтримки окремо від знань маркетингового агента, установіть дляplugins.entries.memory-wiki.config.vault.scope значення agent:
~/.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 — окремої ідентичності відправника для кожного агента немає.
Типово особисті чати об’єднуються в ключ головного сеансу агента, тому для справжньої ізоляції потрібен окремий агент для кожної людини.
Правила маршрутизації
Прив’язки детерміновані, і перемагає найконкретніша. Повний порядок рівнів (точний співрозмовник, батьківський співрозмовник, шаблон співрозмовника, сервер+ролі, сервер, команда, обліковий запис, канал, типовий агент) див. у розділі Маршрутизація каналів. Тут варто окремо зазначити кілька правил:- Якщо в межах одного рівня збігається кілька прив’язок, перемагає перша в порядку конфігурації.
- Якщо прив’язка задає кілька полів зіставлення (наприклад,
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: один екземпляр облікового запису каналу (наприклад, обліковий запис WhatsApppersonalна відміну відbiz).binding: спрямовує вхідні повідомлення доagentIdза(channel, accountId, peer)і, за потреби, за ідентифікаторами гільдії/команди.- Особисті чати зводяться до
agent:<agentId>:<mainKey>(«основного» для окремого агента; див.session.mainKey).
Приклади для платформ
Боти Discord для кожного агента
Боти Discord для кожного агента
Кожен обліковий запис бота Discord зіставляється з унікальним
accountId. Прив’яжіть кожен обліковий запис до агента й ведіть окремі списки дозволених значень для кожного бота.- Запросіть кожного бота до гільдії та ввімкніть Message Content Intent.
- Токени зберігаються в
channels.discord.accounts.<id>.token(обліковий запис за замовчуванням може використовуватиDISCORD_BOT_TOKEN).
Боти Telegram для кожного агента
Боти Telegram для кожного агента
- Створіть окремого бота для кожного агента за допомогою 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, щоб кожен бот спрямовував повідомлення до свого агента.
Номери WhatsApp для кожного агента
Номери WhatsApp для кожного агента
Зв’яжіть кожен обліковий запис перед запуском Gateway:
~/.openclaw/openclaw.json (JSON5):Поширені шаблони
- WhatsApp для щоденних завдань і Telegram для поглибленої роботи
- Той самий канал, один співрозмовник для Opus
- Сімейний агент, прив’язаний до групи WhatsApp
Розділіть за каналами: спрямовуйте 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, щоб @згадки однозначно зіставлялися з потрібним агентом.Пов’язані матеріали
- Агенти ACP — запуск зовнішніх середовищ для програмування
- Маршрутизація каналів — як повідомлення спрямовуються до агентів
- Присутність — присутність і доступність агента
- Сеанс — ізоляція та маршрутизація сеансів
- Підагентів — запуск фонових виконань агентів