Важнее не количество инструментов, а восстанавливаемое состояние, предсказуемые паузы и измеримые побочные эффекты. Когда согласованы thread_id, checkpoint, interrupt и квоты каталогов, один и тот же граф уверенно крутится в ноутбуке и на удалённом Mac много часов подряд.

Инференс, RAG и шлюзы удобно сопоставить с материалами про локальный LLM и llama.cpp/Ollama, чанки, эмбеддинги и векторные квоты, а также OpenClaw: JSON Schema и таймауты и IDE-мост, песочница и health. Контекст сервиса — на главной; каталог аренды и регионы — на странице покупки (просмотр без входа в аккаунт). Ниже — матрица решений, чек-лист приёмки и краткий HowTo.

Оркестрация агента на Mac в 2026 году почти всегда многослойна: сверху — политики модели и маршрутизация узлов LangGraph, ниже — детерминированные инструменты и побочные эффекты на диске. Если разделить «что считается одним разговором» (thread_id), «где лежит снимок состояния» (checkpoint) и «где разрешена запись» (песочница), команда получает повторяемый контракт: любой инженер может поднять тот же граф на другой машине и продолжить с того же места. Обратная сторона — рост объёма checkpoint при длинных цепочках и неожиданные задержки subprocess; поэтому матрица ниже связывает хранилище, прерывания и таймауты с наблюдаемостью на удалённом узле.

Измерение Суть проектирования Удалённый Mac: длительный прогон
thread_id Один ключ на логическую сессию; связь с пользователем и аудитом; запрет параллельной записи в один thread Выдавайте идентификатор на шлюзе, не доверяйте произвольной строке клиента — избегайте коллизий и гонок
checkpoint Совпадение единицы деплоя с пространством имён и миграциями; версия графа при обновлении Усиление записи: БД, файл SQLite, WAL; планируйте окна VACUUM и мониторинг роста
SQLite / Postgres Низкая параллельность и быстрый старт: SQLite + WAL на локальном SSD Несколько воркеров и центральный аудит: Postgres + пул. Файл SQLite не кладите на сетевой том или синхронизируемую папку
interrupt Останов на узле одобрения; сохранение текста ожидания и ссылки на checkpoint Тайм-аут ожидания человека: иначе воркер занят «тихим» interrupt; предусмотрите безопасный выход по умолчанию
tool timeout Жёсткий лимит на инструмент + бюджет подграфа + отдельно время до первого токена LLM Заложите RTT и p95; согласуйте с политиками шлюза OpenClaw и логами
Квоты каталогов Раздельно workspace, checkpoint, артефакты и временные загрузки; мягкий и жёсткий потолок Следите за inode и «штормом» мелких файлов; период очистки и дифф — см. IDE-мост

Checkpoint: SQLite или Postgres

SQLite уместен при одном процессе, умеренной конкуренции за запись и WAL на быстром локальном диске; держите путь вне iCloud и сетевых томов. Долгие прогоны увеличивают файл и журнал — следите за блокировками и местом. PostgreSQL выбирайте, когда несколько воркеров пишут состояние, нужен общий аудит или резервное копирование на уровне кластера: пул соединений, миграции и autovacuum становятся обязательной дисциплиной. Если граф на удалённом Mac, а БД центральная, включите в регрессию проверку смещения часов и обрывов соединения при возобновлении.

При смене версии графа фиксируйте номер схемы состояния в метаданных checkpoint и держите скрипт миграции для старых снимков — иначе «тихий» дрейф полей приведёт к ошибкам на узлах инструментов после деплоя. Для команд с раздельными средами разумно иметь отдельное пространство имён checkpoint на окружение (dev/stage/prod), чтобы тестовые прогоны не пересекались с боевыми thread_id.

Чек-лист приёмки квот песочницы

  • thread_id и префиксы файлов в scratch согласованы; при удалении сессии каскадно очищается песочница.
  • Каталоги checkpoint и загрузок пользователя разделены — случайное «заливание» не раздувает таблицы состояния.
  • На каждый инструмент заданы лимиты размера файла, числа файлов и порог по inode с оповещением.
  • В состоянии interrupt очередь и воркер не бесконечны: заданы TTL очереди или переназначение задачи.
  • После tool timeout цепочка SIGTERM → SIGKILL не оставляет зомби-процессов.
  • После аварийного завершения восстановление с последнего checkpoint проверяет инварианты (хэши артефактов, счётчики).

Кратко: HowTo

Зафиксировать thread_id → выбрать бэкенд checkpoint и миграции → описать контракт interrupt / resume → ввести уровни таймаутов → квоты и скрипты уборки в CI → на выделенном удалённом Mac прогнать многочасовую нагрузку и кривую диска.

Контракт interrupt стоит оформить явно: какие поля состояния видит оператор, какой идентификатор checkpoint считается «ожидающим», и что происходит при отмене или тайм-ауте (возврат к безопасной ветке, запись в лог причины, без повторного вызова инструмента с побочным эффектом). Тогда одна и та же схема работает при ручном одобрении и при автоматическом эскалационном правиле.

Долгие прогоны на удалённом Mac

Под launchd или контейнером храните логи, checkpoint и scratch на одном локальном томе, чтобы алерты по диску срабатывали раньше исчерпания квоты. Избегайте одновременной записи в один thread_id с двух клиентов; при переподключении клиента продолжайте с последнего известного checkpoint. Ночные джобы индексации и эмбеддингов пересекаются с темой локального RAG; тяжёлый инференс — с матрицей llama.cpp/Ollama.

Для «марафона» заведите сценарий регрессии: несколько часов типичного трафика, искусственные обрывы сети, длительный interrupt без ответа человека и повторный старт процесса воркера. Снимайте метрики размера БД checkpoint, задержки хвоста инструментов и скорость роста scratch; сравнивайте с базовой линией после изменения политик таймаутов. Так вы отделяете регрессию оркестрации от шума модели и заранее видите, когда выделенный удалённый Mac окупается стабильностью длинных задач.

# Пример путей (подставьте префикс команды) CHECKPOINT_DIR="$HOME/agent-state/checkpoints" SANDBOX_WORKSPACE="$HOME/agent-state/scratch/$THREAD_ID"

Связанные материалы: вызовы инструментов OpenClaw · главная · покупка