NullClaw как AI-агент: ветвление тем, IRC-транспорт и переключение моделей

NullClaw — ультралёгкая инфраструктура автономных AI-агентов, написанная на Zig¹. Бинарник занимает 678 КБ, потребляет около 1 МБ RAM и стартует менее чем за 2 мс². Проект позиционируется как минималистичная альтернатива OpenClaw для ресурсо-ограниченных окружений: от Raspberry Pi до облачных VPS за $7/месяц³. Данный обзор исследует, можно ли использовать NullClaw в режиме обычного AI-агента с ветвлением тем по каналам, какую роль играет IRC как транспорт, и как переключать модели в подобной архитектуре.

Архитектура NullClaw

Ядро NullClaw строится на трёх архитектурных паттернах⁴:

1. VTable-полиморфизм — каждая подсистема (провайдер LLM, канал связи, память, инструменты) определяется через vtable-интерфейс. Это обеспечивает подмену реализаций через конфигурацию без изменения кода⁴.

2. Event Bus — структура Bus развязывает продюсеров сообщений (каналы) от консюмеров (менеджер сессий) через две очереди: inbound (пользовательские сообщения → SessionManager) и outbound (ответы агента → каналы)⁴.

3. Daemon Supervisor — несколько супервизируемых потоков с exponential backoff управляют жизненным циклом подсистем: HTTP-гейтвей, heartbeat, планировщик, мониторинг каналов и диспетчер исходящих сообщений⁴.

Конфигурация хранится в ~/.nullclaw/config.json и совместима со структурой OpenClaw⁵. Инициализация выполняется командой nullclaw onboard --interactive⁵.

Режимы работы агента

NullClaw поддерживает три основных режима исполнения⁴:

• CLI Mode — одноразовое сообщение или интерактивный REPL (nullclaw agent -m "message")
• Daemon Mode — продакшн-режим с HTTP-гейтвеем и фоновыми каналами (nullclaw gateway)
• Onboarding Mode — мастер начальной настройки

Уровни автономии задаются через autonomy.level⁵:

• supervised — каждое исполнение инструмента требует одобрения оператора
• read_only — запрещены операции записи
• full — неограниченное исполнение
• yolo — агрессивная оптимизация с минимальными ограничениями

Для использования NullClaw как «обычного» AI-агента достаточно запустить Daemon Mode с одним или несколькими каналами связи. Агент обрабатывает входящие сообщения, поддерживает историю сессий, выполняет инструменты и отвечает в контексте разговора⁴.

Ветвление тем через каналы и bindings

NullClaw не реализует «ветвление разговоров» в стиле ChatGPT (дерево сообщений внутри одной сессии). Вместо этого разделение тем достигается через архитектурный паттерн: разные каналы или чаты маршрутизируются к разным агентам с помощью системы bindings⁶.

Механизм bindings

Конфигурация bindings связывает конкретный канал, аккаунт и peer (чат/группу/топик) с именованным агентом⁵:

{
  "bindings": [
    {
      "agent_id": "coder",
      "match": {
        "channel": "telegram",
        "account_id": "main",
        "peer": { "kind": "group", "id": "-1001234567890:thread:42" }
      }
    },
    {
      "agent_id": "orchestrator",
      "match": {
        "channel": "telegram",
        "account_id": "main",
        "peer": { "kind": "group", "id": "-1001234567890" }
      }
    }
  ]
}

В этом примере топик 42 направляется к агенту coder, а остальные топики группы — к orchestrator⁶. Каждый именованный агент может иметь собственную модель, системный промпт и даже изолированное рабочее пространство⁵:

{
  "agents": {
    "list": [
      {
        "id": "coder",
        "model": { "primary": "ollama/qwen2.5-coder:14b" },
        "system_prompt": "Focus on implementation and tests.",
        "workspace_path": "agents/coder"
      },
      {
        "id": "researcher",
        "model": { "primary": "openrouter/openai/gpt-4.1" },
        "system_prompt": "Focus on investigation and synthesis."
      }
    ]
  }
}

Каждый агент получает изолированное пространство памяти с namespace agent:<agent-id> и собственными файлами AGENTS.md, SOUL.md, IDENTITY.md, MEMORY.md⁵.

Slash-команды для управления привязками

Оператор может динамически перепривязывать агентов прямо из чата⁶:

• /bind <agent> — привязать текущий чат к агенту
• /bind status — показать текущий маршрут
• /bind clear — удалить привязку, откат к fallback

Топик-специфичные привязки имеют приоритет над fallback-привязкой группы⁶.

Субагенты

Помимо bindings, NullClaw поддерживает делегирование задач через субагенты⁷. Команда /subagents spawn --agent <id> запускает одноразовый субагент, а для персистентных сессий используется sessions_spawn с thread: true⁷. Субагенты исполняются в изолированных сессиях с ограниченными политиками инструментов⁷. Однако вложенные субагенты (субагент создаёт субагента) на текущий момент не поддерживаются⁷.

IRC как канал связи

Почему IRC

IRC-протокол (RFC 1459, 1993) оказывается неожиданно удачным транспортом для AI-агентов. George Larson, разработавший систему «Digital Doorman» на базе NullClaw, описывает причины выбора IRC³:

IRC — протокол 1988 года, который оказался идеальным транспортом для AI-агента: никакого SDK, никакого API-версионирования, никакой привязки к вендору — только сообщения в канале.

Преимущества IRC как транспорта:

• Полный контроль стека — собственный IRC-сервер, никаких зависимостей от сторонних платформ
• Минимальный overhead — текстовый протокол без JSON, REST или WebSocket-оболочек
• Стабильность — протокол не менялся десятилетиями
• Мультиканальность — нативная поддержка множества каналов для разных тем

Конфигурация IRC в NullClaw

IRC является одним из 18 встроенных каналов NullClaw⁸. Конфигурация выглядит следующим образом⁴:

{
  "channels": {
    "irc": {
      "enabled": true,
      "servers": [
        {
          "server": "irc.example.com",
          "port": 6667,
          "tls": true,
          "nick": "botname",
          "user": "username",
          "channels": ["#general", "#dev"]
        }
      ]
    }
  }
}

IRC-канал реализует polling-паттерн: супервизируемый поток активно получает сообщения через raw socket + TLS, а health check выполняется через PING/PONG⁴. Поддерживается подключение к нескольким серверам и каналам одновременно (multi-account)⁴.

Ветвление тем через IRC-каналы

В IRC каждый канал (#channel) — это изолированное пространство сообщений. NullClaw создаёт отдельную сессию для каждого chat_id (в случае IRC — для каждого канала)⁴. Это означает, что разные IRC-каналы автоматически получают раздельные контексты разговора.

Для реализации ветвления тем через IRC достаточно:

1. Создать отдельные IRC-каналы для каждой темы (#coding, #research, #devops)
2. Через bindings привязать каждый канал к соответствующему агенту с нужной моделью
3. Каждый канал будет иметь независимую сессию и историю

Пример конфигурации для ветвления:

{
  "channels": {
    "irc": {
      "enabled": true,
      "servers": [{
        "server": "localhost",
        "port": 6697,
        "tls": true,
        "nick": "assistant",
        "channels": ["#coding", "#research", "#general"]
      }]
    }
  },
  "bindings": [
    {
      "agent_id": "coder",
      "match": { "channel": "irc", "peer": { "id": "#coding" } }
    },
    {
      "agent_id": "researcher",
      "match": { "channel": "irc", "peer": { "id": "#research" } }
    }
  ]
}

Практический пример: Digital Doorman

Реальный кейс IRC-деплоя NullClaw описан George Larson³. Архитектура «Digital Doorman» использует двухуровневую модель:

• NullClaw (публичный агент) — на VPS за $7/месяц, обрабатывает публичные запросы через IRC-канал #lobby
• IronClaw (приватный агент) — на изолированном оборудовании, управляет чувствительными данными

Коммуникация между агентами происходит через приватный IRC-канал #backoffice, а сетевая изоляция обеспечивается через Tailscale³. Публичный агент никогда не имеет прямого доступа к приватному контексту.

Стек: Ergo (IRC-сервер на Go, 2.7 МБ RAM) + Gamja (web-клиент IRC, 152 КБ) + NullClaw (678 КБ)³.

Переключение моделей

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

Уровень 1: Статическое назначение через конфигурацию

Модель по умолчанию задаётся в agents.defaults.model.primary в формате provider/vendor/model⁵:

{
  "agents": {
    "defaults": {
      "model": { "primary": "openrouter/anthropic/claude-sonnet-4" }
    }
  }
}

Каждый именованный агент может переопределить модель⁵:

{
  "agents": {
    "list": [
      {
        "id": "coder",
        "model": { "primary": "openrouter/qwen/qwen3-coder" }
      },
      {
        "id": "researcher",
        "model": { "primary": "openrouter/openai/gpt-4.1" }
      }
    ]
  }
}

Уровень 2: Автоматическая маршрутизация через model_routes

Секция model_routes определяет таблицу маршрутизации для автоматического выбора модели на каждом turn⁵⁹:

{
  "model_routes": [
    {
      "hint": "fast",
      "provider": "groq",
      "model": "llama-3.3-70b",
      "cost_class": "free",
      "quota_class": "unlimited"
    },
    {
      "hint": "balanced",
      "provider": "openrouter",
      "model": "anthropic/claude-sonnet-4",
      "cost_class": "standard"
    },
    {
      "hint": "deep",
      "provider": "anthropic",
      "model": "claude-opus-4",
      "cost_class": "premium"
    },
    {
      "hint": "vision",
      "provider": "anthropic",
      "model": "claude-sonnet-4",
      "cost_class": "standard"
    }
  ]
}

Распознаваемые route hints⁵⁹:

Route metadata (cost_class, quota_class) влияет на скоринг, но не определяет маршрут однозначно: неоднозначные промпты остаются на balanced, а fast срабатывает только при высокой уверенности в дешёвой задаче⁹. Команда /model показывает последнее решение авто-роутера⁹.

Уровень 3: Провайдерный стек

Архитектура провайдеров в NullClaw — трёхслойная⁴:

ReliableProvider (retry/backoff)
    ↓
RouterProvider (выбор backend)
    ↓
Concrete Provider (OpenAI, Anthropic, Gemini...)

ReliableProvider автоматически деградирует маршрут после ошибок квоты или rate-limit и пропускает его до истечения cooldown⁹. NullClaw поддерживает 22+ провайдеров⁸, организованных в тиры⁴:

• Tier 1 (гейтвеи): OpenRouter, Anthropic, OpenAI, Azure
• Tier 2 (облако): Gemini, DeepSeek, Groq, Vertex
• Tier 3 (OAI-совместимые): Mistral, Together AI, Fireworks
• Tier 9 (локальные): Ollama, LM Studio

Для кастомных провайдеров формат: custom:<url> с переменной окружения для API-ключа⁴.

Уровень 4: Переключение через переменные окружения

Быстрое переопределение без редактирования конфига⁵:

NULLCLAW_PROVIDER=anthropic
NULLCLAW_MODEL=claude-opus-4

Комбинирование с ветвлением тем

В контексте ветвления тем переключение моделей выглядит органично. Bindings связывают каналы/топики с агентами, а каждый агент определяет свою модель. Таким образом:

• #coding → агент coder → qwen3-coder (быстрая, специализированная на коде)
• #research → агент researcher → gpt-4.1 (аналитика и синтез)
• #general → агент по умолчанию → claude-sonnet-4 с авто-роутингом

Внутри каждого агента model_routes дополнительно оптимизирует выбор модели по сложности конкретного turn.

Каналы связи: сравнение поддержки тредов

NullClaw поддерживает 18 каналов связи⁸. Однако возможности threading и изоляции сессий кардинально различаются между платформами. Ниже — анализ каждого канала с точки зрения ветвления тем.

Каналы с нативной поддержкой тредов

Telegram Forum Topics

Telegram — наиболее зрелый канал для ветвления тем в NullClaw. Форумные группы Telegram предоставляют нативные топики, и NullClaw добавляет :topic:<threadId> к ключу сессии, обеспечивая полную изоляцию контекста¹⁰. Каждый топик — это отдельная сессия, сообщения из одного топика не попадают в контекст другого¹⁰.

Ключевое преимущество — per-topic agent binding. Через конфигурацию bindings с <chat_id>:thread:<topic_id> каждый топик направляется к своему агенту с собственной моделью⁶. Команда /bind позволяет перепривязывать агентов динамически, без редактирования конфига⁶.

Telegram также поддерживает rich media (изображения, файлы, голосовые сообщения), что делает доступным route hint vision для моделей с поддержкой изображений¹⁰.

Slack

Slack-интеграция NullClaw автоматически обнаруживает и поддерживает контекст тредов¹¹. Сообщения внутри треда получают ответы в том же треде, а метаданные треда сохраняются между обменами¹¹. Для явной маршрутизации в конкретный тред используется формат channel_id:thread_ts¹¹.

Ключи сессий для Slack-тредов формируются по схеме agent:<agentId>:slack:channel:<channelId>:thread:<threadTs>¹². Это обеспечивает полную изоляцию: параллельные треды в одном канале ведут независимые разговоры.

Slack поддерживает три модели доступа¹¹:

• allowlist — только указанные пользователи
• mention_only — DM по allowlist, в каналах — по упоминанию
• open — без ограничений (не рекомендуется для продакшна)

Соединение через Socket Mode обеспечивает real-time доставку событий¹¹.

Discord

Discord-треды получают собственный session key: agent:<agentId>:discord:channel:<threadId>¹³. Тред использует свой ID как компонент ключа канала, а не наследует ID родительского канала¹³. Конфигурация (allowlist, requireMention, skills, prompts) наследуется от родительского канала, если не переопределена явно для конкретного треда¹³.

Discord также поддерживает slash-команды с изолированными сессиями (agent:<agentId>:discord:slash:<userId>)¹³ и настройку autoArchiveDuration для автоматической архивации тредов¹⁴.

Каналы с ограниченной поддержкой тредов

Matrix

Matrix поддерживает threading через m.thread relation type¹⁵. Однако на момент написания обзора в экосистеме Claw-семейства реализация thread-level изоляции сессий для Matrix находится в процессе разработки¹⁵. По умолчанию все сообщения в одной комнате (включая треды) попадают в общую сессию, что приводит к «загрязнению контекста» параллельными разговорами¹⁵.

Планируемое решение включает настройки channels.matrix.thread с опциями historyScope ("thread" для per-thread или "room" для общей истории), inheritParent и initialHistoryLimit¹⁵. Slack и Telegram уже реализуют per-thread изоляцию, которая станет образцом для Matrix¹⁵.

IRC

IRC не имеет нативного threading внутри канала. Каждый IRC-канал (#channel) — это единая сессия. Для разделения тем требуется создание отдельных каналов, что подробно описано выше в секции «Ветвление тем через IRC-каналы».

Каналы без поддержки тредов

Signal, iMessage и WhatsApp поддерживают только базовые операции: отправка, чтение и реакции¹⁴. Threading в этих каналах не реализован ни на уровне протокола, ни на уровне интеграции. Агентный слой NullClaw учитывает возможности канала и не пытается использовать функции, которых канал не поддерживает¹⁴.

Сравнительная таблица

Для задачи «отдельные темы — отдельные контексты с разными моделями» Telegram Forum Topics — наиболее рекомендуемый канал благодаря полной per-topic изоляции, нативным bindings и визуальной навигации. Slack — лучший выбор для рабочих команд, уже использующих его как основной мессенджер. IRC — осознанный выбор для тех, кому важен полный контроль инфраструктуры и минимальный overhead³.

Ограничение длины сообщений IRC: история и современность

Происхождение лимита в 512 байт

Утверждение о 512-байтном лимите IRC-сообщений — не приблизительная оценка, а точная цитата из спецификации. RFC 2812 (секция 2.3) формулирует это однозначно¹⁶:

“IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages SHALL NOT exceed 512 characters in length, counting all characters including the trailing CR-LF.”

С учётом 2 байт на CR-LF, доступный объём для команды и параметров составляет 510 байт¹⁶. Это ограничение присутствует уже в RFC 1459 (май 1993)¹⁷ и сохранено в RFC 2812 (апрель 2000)¹⁶.

Почему именно 512 байт

RFC не содержит явного обоснования выбора числа 512. Однако из имплементационных заметок в RFC 1459 можно извлечь контекст¹⁷:

“A buffer size of 512 bytes is used so as to hold 1 full message, although, this will usually hold several commands.”

Число 512 — степень двойки (2⁹), стандартный размер дискового сектора и типичный размер буфера в системах конца 1980-х годов. IRC был создан Jarkko Oikarinen в августе 1988 года в Университете Оулу (Финляндия) как замена программы MUT (MultiUser Talk)¹⁸. В контексте сетей 1988 года — когда IRC-серверов было единицы, а к середине 1989 года их насчитывалось около 40 по всему миру¹⁸ — фиксированный буфер в 512 байт был практичным выбором: достаточным для текстового сообщения и удобным для аллокации памяти на серверах с ограниченными ресурсами.

Важно отметить: 512 байт — это полная длина IRC-сообщения, включая префикс отправителя, команду и параметры. После вычитания overhead протокола (:nick!user@host PRIVMSG #channel :) для полезной нагрузки текста остаётся существенно меньше — как правило, 350–400 байт в зависимости от длины никнейма, хоста и имени канала.

Изначально длинные сообщения не поддерживались

Нет — протокол IRC с самого начала (1988, формализован в RFC 1459 в 1993) определял жёсткий лимит в 512 байт на сообщение¹⁷. Это не было ограничением конкретной реализации — это фундаментальный параметр протокола, влияющий на другие его элементы. Как отмечает RFC 2812¹⁶:

“Such restriction is necessary because IRC messages are limited to 512 characters in length.”

Серверы, получающие сообщения длиннее 512 байт, должны либо вернуть ошибку ERR_INPUTTOOLONG (код 417), либо обрезать сообщение на 510-м байте и добавить \r\n¹⁹.

Современные расширения: IRCv3

Спецификация IRCv3 вводит несколько механизмов преодоления исторического лимита.

maxline

Capability oragono.io/maxline-2 позволяет серверу и клиенту согласовать увеличенный лимит²⁰. Значение должно быть не менее 512 и рекомендуется не менее 2048 байт²⁰. Ergo (IRC-сервер на Go, используемый в кейсе Digital Doorman) поддерживает эту capability нативно²⁰.

При отправке длинного сообщения клиенту, не поддерживающему maxline, сервер автоматически разбивает его на стандартные 512-байтные фрагменты с разрывом по пробелам, не разделяя UTF-8 символы²⁰. Тег oragono.io/truncated сигнализирует о произошедшей обрезке²⁰.

Multiline Messages

Спецификация draft/multiline (в стадии черновика) позволяет отправлять сообщения, которые содержат переносы строк и превышают обычный лимит²¹. Механизм основан на batch-отправке: несколько PRIVMSG/NOTICE объединяются в один логический блок²¹.

Сервер объявляет параметры²¹:

• max-bytes — максимальный суммарный объём полезной нагрузки
• max-lines — максимальное число строк в batch

Ergo поддерживает multiline с настраиваемыми параметрами²²:

multiline:
  max-bytes: 4096  # 0 — отключено
  max-lines: 100   # 0 — без лимита

При доставке клиенту без поддержки multiline сервер разворачивает batch в отдельные сообщения²¹.

Message Tags

IRCv3 Message Tags расширяют формат сообщения метаданными с лимитом 8191 байт на теги²³. Теги не входят в основной лимит 512 байт и позволяют передавать дополнительную информацию (ID сообщения, timestamps, клиентские данные) без влияния на полезную нагрузку²³.

Практические следствия для NullClaw

При использовании Ergo как IRC-сервера (рекомендуемый стек для NullClaw³) ограничение в 512 байт фактически снято: maxline позволяет увеличить лимит до 2048+ байт, а multiline — отправлять структурированные многострочные ответы. Таким образом, заявление об «ограничении IRC в 512 байт» в контексте NullClaw + Ergo является устаревшим — при условии, что клиент поддерживает IRCv3-расширения.

Однако если пользователь подключается стандартным IRC-клиентом без поддержки maxline/multiline, он получит автоматически фрагментированные сообщения. Это не проблема для машинного взаимодействия (агент → агент), но может быть неудобно для чтения человеком.

Альтернативы NullClaw/OpenClaw для работы с тредами

NullClaw и OpenClaw — не единственные варианты для AI-агента с разделением тем по тредам. Экосистема 2026 года предлагает широкий спектр альтернатив: от минималистичных Claw-семейств до полноценных chat-интерфейсов и фреймворков оркестрации.

Claw-семейство

Все «клешни» (Claw-*) разделяют общую архитектурную идею — автономный AI-агент с multi-channel доставкой — но отличаются языком реализации, ресурсными требованиями и зрелостью threading.

ZeroClaw (Rust)

ZeroClaw — реимплементация на Rust, где каждая подсистема — swappable trait²⁴. Потребляет менее 5 МБ RAM и стартует за менее чем 10 мс²⁴. Поддержка Telegram Forum Topics реализована: :topic:<threadId> добавляется к ключу сессии, обеспечивая изоляцию контекста между топиками²⁵. Memory auto-save также скопирован по topic ID, исключая утечку воспоминаний между темами²⁵. Однако в текущей версии нет per-topic конфигурации системных промптов или переопределения моделей — все топики используют одного агента²⁵.

PicoClaw (Go)

PicoClaw написан на Go, занимает менее 10 МБ RAM и поддерживает экзотические архитектуры: x86_64, ARM64, MIPS, RISC-V, LoongArch²⁴. Поддержка Telegram Topics добавлена через PR #202: функция parseTelegramChatID разбирает формат chatID:threadID, а MessageThreadID включается в исходящие сообщения²⁶. Каналы: Telegram и Discord из коробки²⁴.

NanoClaw (Python/Anthropic SDK)

NanoClaw — контейнеризированный агент, построенный на Anthropic Agents SDK²⁷. Каждая группа получает изолированный контейнер, файловую систему, IPC namespace и Claude-сессию²⁷. Группы не имеют доступа к данным друг друга. В Telegram поддерживаются multi-agent группы, где каждый субагент может иметь собственную bot-идентичность²⁷. Каналы: WhatsApp, Telegram, Slack, Discord, Gmail, Signal²⁷.

Moltis (Rust)

Moltis — Rust-нативный агент из 46 модульных crates (~196K строк)²⁸. Поддерживает voice, memory, scheduling, browser automation и MCP-серверы²⁸. Каналы: Telegram, Discord, web-интерфейс²⁸. Архитектура основана на trait-based provider system с 56 trait-определениями и 160 точками инъекции Arc<dyn ...>²⁸. Детальная информация о per-thread изоляции сессий в публичной документации отсутствует.

IronClaw (Rust)

IronClaw фокусируется на безопасности: каждый инструмент исполняется внутри WebAssembly-песочницы, credentials никогда не экспонируются инструментам²⁴. Набор каналов ограничен — осознанный выбор для минимизации attack surface²⁴. Threading-функциональность не документирована.

Nanobot (Python)

Nanobot — ультралёгкий AI-агент из ~4 000 строк Python с 26 800+ звёздами на GitHub²⁹. Интегрируется с Telegram, Discord, WhatsApp, Slack, Feishu, QQ и DingTalk²⁹. Поддерживает Slack thread isolation и Discord threading²⁹. Для Discord в group policy open рекомендуется создавать приватные треды и упоминать бота в них²⁹. Архитектура: пятислойная (User Interfaces → Gateway с MessageBus → Core Agent Engine → LLM Provider Layer → Tool Layer)²⁹. Multi-model: OpenAI, Anthropic, Gemini, DeepSeek, Groq, OpenRouter, Ollama²⁹.

Chat-интерфейсы с ветвлением

В отличие от multi-channel агентов, chat-интерфейсы предлагают ветвление как UI-функцию внутри веб-приложения.

LibreChat

LibreChat реализует полноценное forking разговоров³⁰. Fork создаёт новый разговор, начинающийся от выбранного сообщения, с тремя режимами включения контекста³⁰:

• Visible messages only — копирует только прямой путь к целевому сообщению
• Include related branches — прямой путь плюс ответвления вдоль него
• Include all to/from here — все сообщения, включая соседние ветки

Опция «Start fork here» позволяет продолжить fork от выбранного сообщения вперёд, а не назад к началу³⁰. Ветки сохраняются при шаринге разговоров³⁰.

TypingMind

TypingMind создаёт отдельный тред при каждом редактировании или регенерации сообщения³¹. Навигация между ветками через стрелки ← →. Можно возобновить разговор из любой предыдущей версии без потери других веток³¹. Применения: сравнение разных подходов к решению задачи, тестирование альтернативных формулировок³¹.

LobeChat

LobeChat поддерживает fork разговора от любого сообщения для исследования альтернативного хода мысли без потери оригинального контекста³².

Open WebUI

Open WebUI предоставляет «Reply in Thread» для создания вложенных разговоров и multi-model conversations, где модели общаются в round-robin или group chat режиме³³. Функция conversation branching (клик по слову для создания sub-conversation) находится в стадии feature request³³.

Фреймворки оркестрации

LangGraph

LangGraph (LangChain) использует thread_id как ключ сессии: при смене thread_id агент начинает с чистого контекста³⁴. Два типа памяти³⁴:

• In-thread memory — история сообщений внутри одной сессии, сохраняемая через checkpointer
• Cross-thread memory — пользовательские или application-level данные, доступные во всех тредах

Checkpointers поддерживают PostgreSQL, Redis, MongoDB и другие бэкенды³⁴. LangGraph не предоставляет каналы связи (Telegram, Discord) из коробки — это фреймворк для построения агентов, а не готовое решение.

CoPaw (Alibaba)

CoPaw — open-source workstation от команды Tongyi (Alibaba Cloud), выпущенный в феврале 2026³⁵. Построен на AgentScope и поддерживает DingTalk, Feishu, Discord, QQ, iMessage и Slack как CLI-плагины³⁵. Каждый канал добавляется или удаляется без изменения логики агента³⁵.

Обработка сообщений включает session-aware batching: пока сессия обрабатывается, новые сообщения той же сессии попадают в pending-словарь и мержатся при завершении обработки³⁵. Per-session locks предотвращают race conditions³⁵. Persistent memory через ReMe обеспечивает сохранение контекста между сессиями и платформами³⁵.

Сравнительная таблица альтернатив

Вывод: для полноценного per-thread agent binding с разными моделями на разные темы OpenClaw и NullClaw остаются наиболее зрелыми вариантами. ZeroClaw и PicoClaw догоняют по Telegram-тредам, но пока без per-topic переопределения модели. Chat-интерфейсы (LibreChat, TypingMind) предлагают ветвление как UI-функцию, но не multi-channel агентность. LangGraph — мощный фреймворк для custom-решений, но требует самостоятельной реализации каналов.

Дискуссионные вопросы и противоречия

Ветвление vs. отдельные каналы/треды

Настоящее ветвление разговоров (fork/merge внутри одной сессии) — активно обсуждаемая тема как в экосистеме OpenClaw, так и в Claude Code³⁶. NullClaw не реализует эту функциональность нативно. Использование отдельных каналов или тредов — это архитектурное решение для разделения контекстов, а не полноценная замена tree-based branching: нет механизма слияния контекстов из разных тредов обратно в одну сессию. Если ветвление нужно именно для «исследования идеи с возможностью вернуться к развилке», текущая модель этого не обеспечивает.

Зрелость экосистемы

NullClaw — молодой проект с ~2 600 звёздами на GitHub³⁷ и ограниченной документацией по сравнению с OpenClaw. Некоторые критики отмечают³⁷:

• Меньше plug-and-play агентов по сравнению с крупными платформами
• Продвинутые интеграции требуют ручной настройки
• Edge-ориентированность не подходит для крупномасштабных enterprise-задач

IRC vs. Telegram vs. Slack: выбор канала

Выбор канала для ветвления тем — это компромисс между контролем и удобством:

• IRC даёт полный контроль инфраструктуры, минимальный overhead и независимость от вендоров, но лишён нативных тредов, rich media и удобного UI
• Telegram предоставляет лучшую поддержку per-topic bindings, визуальную навигацию и rich media, но привязывает к инфраструктуре Telegram
• Slack оптимален для рабочих команд с существующим Slack-workflow, но зависим от подписки и API Slack

Matrix: обещание без реализации

Matrix — единственный канал с открытым протоколом, поддержкой E2E-шифрования и нативными тредами на уровне протокола (m.thread), но при этом per-thread изоляция сессий в NullClaw/OpenClaw ещё не реализована¹⁵. Для пользователей, которым важны одновременно открытость протокола и ветвление тем, Matrix остаётся перспективным, но пока незавершённым вариантом.

Quality Metrics