Прямое мобильное документирование в OpenClaw: Рабочий процесс передачи данных о здоровье с iOS на Raspberry Pi

Разработчик на r/openclaw задокументировал экспериментальный подход для прямой отправки документов с мобильного клиента iOS в локальный экземпляр OpenClaw, работающий на Raspberry Pi. Цель — сканировать документы, такие как результаты анализов или рецепты, на телефоне и передавать их в OpenClaw для последующей обработки без облачных посредников или ручной загрузки.

Обзор архитектуры

Система использует двухуровневый подход: телефон выступает в качестве уровня захвата, а OpenClaw служит уровнем обработки. Мобильный клиент спроектирован полностью локальным и ориентированным на конфиденциальность, без зависимости от облака и внешних AI-сервисов. Он использует Apple OCR (Vision) и локальный интеллект для извлечения и поиска, сохраняя исходные документы и извлечённый контент на устройстве, если явно не отправлено в OpenClaw.

Сопряжение и настройка

QR-сопряжение позволяет избежать ручной настройки. Полезная нагрузка QR — это blob JSON в кодировке base64, сгенерированный на машине OpenClaw со следующей структурой:

{ "url": "wss://", "bootstrapToken": "", "hooksToken": "", "agentId": "", "hookPath": "/hooks/rkive" }

hooksToken хранится в iOS Keychain, нечувствительные настройки — в локальном хранилище, а URL wss:// преобразуется в https:// для push-запросов.

Поток данных

Мобильный клиент iPhone отправляет POST-запрос на /hooks/rkive с Bearer-токеном ({hooksToken}) и JSON-полезной нагрузкой, содержащей PDF в кодировке base64. Это попадает в экземпляр OpenClaw (Raspberry Pi, в локальной сети или VPN), который запускает скрипт преобразования ingest_rkive.py. Этот скрипт сохраняет исходный PDF в health-records/originals/, обновляет запись индекса в health-records/index.jsonl и обрабатывает сборку фрагментов и очистку прерываний. Затем выделенный агент здоровья управляет последующей обработкой: OCR → проверка → структурированный вывод.

Ключевые проектные решения

• Выделенный агент в OpenClaw: Мультиагентная настройка включает выделенного агента здоровья, ответственного за приём документов, проверку и последующую структуризацию, изолируя рабочие процессы, связанные со здоровьем.
• Выделенная конечная точка: Использование фиксированной конечной точки, такой как /hooks/rkive, вместо динамической маршрутизации через agentId, обеспечивает детерминированную маршрутизацию, избегает случайной неправильной классификации и упрощает серверную логику.

Последующий рабочий процесс и открытые вопросы

Последующий рабочий процесс находится в стадии разработки. Поскольку Apple OCR не обеспечивает 100% точность, план включает повторное извлечение текста в чистый markdown в OpenClaw с использованием доверенного AI-процесса пользователя, за которым следует этап ручной проверки для верификации контента, структурированного извлечения в ресурсы в стиле FHIR, добавления в долгосрочный набор данных и предоставления медицинских инсайтов.

Автор задаёт два открытых вопроса для обратной связи сообщества: 1) Насколько этот подход полезен на практике для регулярного использования, не создавая лишних сложностей, и 2) Что люди хотели бы, чтобы OpenClaw делал с личными медицинскими записями после приёма, предлагая идеи, такие как долгосрочные временные линии событий, обнаружение пробелов (например, пропущенных последующих действий) и периодические сводки.