Worklife — AI job search

Worklife — MCP サーバーによる AI 求人検索

Worklife は、求職者向けのローカルファーストなModel Context Protocol（MCP）サーバー兼キャリアアシスタントです。 AI エージェントを接続すると、求人サイトや企業のウェブサイトを検索し、募集内容と自身の経験を比較し、事実に基づいた履歴書や CV を作成し、応募、メール、面接、内定を管理できます。

給与や求人市場の分析、ローカルの応募管理ツール、ブラウザーおよび API ツール、署名付きの企業情報を共有するネットワークを備えています。プロフィール、CV、やり取りの記録は個人用ワークスペースに保存され、共有ナレッジベースには企業情報が保存されます。エージェントは MCP クライアント内で動作し、組み込みモデルランナーも任意で利用できます。

ウェブサイト · PyPI · MCP レジストリ · エージェントのセットアップ · 検出とレジストリへの公開 · ロシア語ドキュメント

Python 3.12 以降と uvを使って、お使いのクライアントにキャリアエージェントをインストールします。

uvx --python 3.12 worklife-agent --target codex

セットアップコマンドは、Codex、Claude Code、Cursor、OpenCode 用のプロジェクトアダプターに対応しています。 --target genericを指定すると、手動セットアップ用の MCP 設定をエクスポートします。永続的なランタイムを作成し、Chromium をインストールして、~/worklife-careerを準備します。このフォルダーをクライアントで開き、次のように依頼してください。 「Worklife を使ってください。まずrecruiter_startを実行し、私の求職目標について尋ねてください。」 クライアントのサポートとセットアップの制限をご覧ください。

既存の stdio MCP クライアントでは、キャリアツールを PyPI から直接実行することもできます。

{
  "mcpServers": {
    "worklife_recruiter": {
      "command": "uvx",
      "args": ["--python", "3.12", "--from", "worklife-agent==0.5.2", "worklife-recruiter", "mcp"]
    }
  }
}

これにより、ローカルストレージとして~/.worklifeを使用する MCP サーバーが起動します。ブラウザー自動化には、追加でbrowserエクストラと Chromium が必要です。上記のセットアップコマンドで、両方がインストールされます。アカウントとコネクターは別途設定します。Worklife は、求人プラットフォームへの無制限のアクセスを提供するものではありません。

Worklife（ロシア語）

共有データベースは、専用の Telegram サービスグループを通じて同期できます。 署名付きブロック、見逃した履歴の読み込み、新しい空のコピーの接続に対応しています。 セットアップとグループの作成については、Telegram 同期をご覧ください。

コインや手数料のない新しいネットワーク：プロトコルと 公開テストの準備。 public-testnet-v1プロファイルでは、独立した genesis、25/18 ビットの PoW、6 回の承認を使用します。 以下にある GitHub relay の古い説明は、レガシーの提案に関するものです。

プロジェクトページ · ソースコード · エージェントの手順

自律型の求職ツールキットです。人が目標と条件を指定すると、エージェントは適切な求人を探し、条件を確認し、やり取りを管理し、CV を作成し、仮説を検証して、検証可能な署名付きの経験をほかの参加者と共有します。

バージョン 0.5：Telegram 同期と P2P 交換、オンボーディング、企業データベースの透明な状態表示、更新通知。 エージェントは検索ソースを自ら選択し、ブラウザーと API を使用して、登録、やり取り、実験を追跡します。 独自の MCP 環境に接続することも、組み込みエージェントの実行サイクル用にモデルを設定することもできます。 固定のプラットフォーム一覧はありません。組み込みアダプターに加え、ブラウザーと設定可能な API を利用できます。

Что работает

«Любая платформа» означает расширяемый доступ через API или доступный пользователю браузерный интерфейс. Универсального доступа без аккаунта, разрешений и ограничений самой платформы не существует. OAuth-токены настраиваются владельцем аккаунта; автоматическое OAuth-подключение ко всем сервисам не реализовано. Telegram-адаптер работает от бота, не от личного аккаунта. HH использует существующий resume_id. Greenhouse/Lever здесь читают вакансии; подача заявления — через браузер либо отдельно настроенный разрешённый API.

Быстрый запуск

Одна команда через uv

Установка и подключение выбранного AI-клиента из PyPI:

uvx --python 3.12 worklife-agent --target codex

Вместо codex доступны claude-code, cursor, opencode и другие поддерживаемые проектные адаптеры. generic подготавливает MCP JSON для ручного импорта. Выберите клиент на лендинге и скопируйте готовую команду. Если uv ещё не установлен, используйте официальную инструкцию.

Команда создаёт постоянное окружение в ~/.local/share/worklife, устанавливает текущую версию пакета и Chromium, подготавливает личные данные в ~/.worklife и агента в ~/worklife-career. Затем откройте эту папку в своём AI-клиенте и включите Worklife Recruiter. На Linux установка системных библиотек Chromium для Ubuntu/Debian может запросить пароль администратора.

MCP использует Python постоянного окружения: очистка временного кеша uvx не удаляет установленного агента. Повторная установка сохраняет личную базу и использует существующий установщик адаптеров с его правилами сохранения чужих настроек и резервного копирования. Дополнительные параметры: --destination, --install-dir, --home, --no-browser. --package-source предназначен для проверки конкретного локального wheel до публикации.

Релиз 0.5.2 опубликован в PyPI.

Запуск из исходников

Нужны Python 3.12+ и uv.

git clone https://github.com/dzenlotus/worklife-agent.git
cd worklife-agent
uv sync --extra dev --extra browser
uv run playwright install chromium
cp config.example.toml config.toml
cp .env.example .env
uv run --env-file .env worklife --config config.toml init

Настройте только нужные аккаунты в .env и параметры провайдеров в config.toml. *_env и headers_env содержат имена переменных, а не сами секреты. Личные данные находятся в .worklife/ рядом с конфигурацией; без конфигурации — в ~/.worklife. WORKLIFE_HOME/--home переопределяют расположение.

Демонстрация без аккаунтов и внешних отправок:

uv run worklife --home artifacts/demo demo
uv run worklife --home artifacts/demo call agent_brief '{}'
uv run worklife tools
uv run pytest -q

Демо создаёт профиль, два CV, вакансию, гипотезу, черновик, follow-up и вторую локальную копию общей базы; проверяет репликацию и отклонение подделанной записи. Демо-данные явно обозначены как синтетические.

Карьерный агент и установка в AI-клиент

worklife-recruiter устанавливает MCP, инструкции Worklife Recruiter и восемь предметных скиллов. Модель работает внутри вашего AI-клиента; дополнительный ключ модели для этого не нужен.

Первое поручение: «Используй worklife-onboarding. Быстро подключи всё нужное, включая Telegram». Скилл проверяет существующие условия и доступы, настраивает нужные площадки и почту, проводит через локальный вход Telegram и проверку синхронизации. Пароли, коды и сессия вводятся в вашем терминале. При повторном запуске он продолжает недостающие шаги.

Агент при начале разговора и локальное приложение проверяют новые стабильные версии Worklife в PyPI не чаще раза в сутки. При выходе релиза появляется уведомление со ссылкой и кнопкой копирования поручения агенту обновить Worklife. Закрытое уведомление не возвращается для той же версии; сведения о ней остаются в настройках. Обновление запускается отдельно и сохраняет прежние настройки MCP, доступы и личную базу. После обновления пакета обновите нативные инструкции/скиллы прежней командой worklife-recruiter install и перезапустите MCP/приложение. Для запуска через uvx --from worklife-agent==... также обновляется закреплённая версия в настройках запуска MCP: изменение временного окружения uvx само по себе недостаточно. В режиме WORKLIFE_NETWORK_OFFLINE=1 обращения к PyPI нет.

uv run worklife-recruiter targets
uv run worklife-recruiter install --target codex --destination ../worklife-career --config config.toml --env-file .env --dry-run
uv run worklife-recruiter install --target codex --destination ../worklife-career --config config.toml --env-file .env

Откройте созданную папку в выбранном клиенте. Установщик показывает созданные файлы и дальнейшие действия. --config указывает ту же личную базу, что и приложение; --env-file передаёт путь к окружению, без копирования секретов в настройки клиента. Без конфигурации и явного --home используется стандартная ~/.worklife. --all готовит конфигурации из каталога; установки в пользовательские настройки выполняются только явно. Подробности, команды для клиентов и границы поддержки: установка агента. Профиль Recruiter включает карьерные операции, recruiter_start и recruiter_skill; администрирование сети остаётся в полном MCP Worklife. Для клиента без нативных скиллов те же инструкции доступны через MCP.

ローカルアプリケーション

uv run --env-file .env worklife --config config.toml app

http://127.0.0.1:8877 を開きます。インターフェースは HeroUI 3、Magic UI コンポーネント、Apple/Codex をイメージしたダークテーマ、色分けされたナビゲーションを採用し、システムフォントを使用します。フォールバックにはローカルの Golos Text を使用します。 主な操作は MCP エージェントとのチャットで行います。ブラウザーにはツールの呼び出し、結果、設定が表示されます。エージェントがプラットフォーム、リソース、アカウント、スケジュール、実験を管理します。 アプリケーションには、エージェントのアクティビティ、市場、求人と応募ファネル、メッセージ、面接とオファー、スケジュール、実験、CV、リソース、 アカウント、リポジトリ、共有の雇用主データベースの状態といった実データが表示されます。データベースが空の場合は空のままです。プロジェクトページに表示されるデモ用の数値は反映されません。個人用インターフェースは loopback でのみ利用できます。 公開されている GitHub Pages はプロジェクトの紹介用であり、個人データを受け取りません。

外部 MCP エージェントを使用する場合、専用の Worklife モデルは必要ありません。 サイトとローカルインターフェースの言語は「Русский / English」メニューで切り替えられ、ブラウザーに保存されます。初回起動時にはブラウザーの言語が考慮されます。 「Мои условия → Дополнительно → Языки поиска」では、検索クエリの言語を個別に選択できます。エージェントは選択された各言語に合わせて職種名と類義語を調整し、求人の原文は保持します。選択が空の場合、検索言語は制限されません。 市場レポートでは、実行された検索クエリの言語とスキップされた言語を確認できます。 MCP では、これらは個人プロフィールの interface_language: "en" および search_languages: ["ru", "en"] フィールドです。languages は引き続き言語の習熟度を表します。profile_save はプロフィール全体を置き換えます。保存前に、新しい設定を既存のフィールドと統合してください。

組み込みの実行機能は「Настройки → Встроенный исполнитель」から任意で利用できます。サービスのアドレスを指定し、モデルを選択し、必要に応じてキーを設定してください。接続は保存されます。設定後、元の目標を続行できます。 デプロイ時の代替手段として、.env 変数を使用できます。

WORKLIFE_AGENT_BASE_URL=http://127.0.0.1:1234/v1
WORKLIFE_AGENT_MODEL=your-model-name
WORKLIFE_AGENT_API_KEY=

これはローカルの OpenAI-compatible サーバーの例であり、デフォルトで選択されるプロバイダーではありません。 リモート API を使用するには、その API のキーが必要です。プロジェクトが有料サービスを選択したり、設定なしで呼び出しを行ったりすることはありません。 組み込みの実行機能の展開セクションで目標を指定すると、モデルがツールを受け取り、実際の呼び出しと結果を記録しながら処理を繰り返します。ステップ数を制限したり、停止を要求したりできます。 登録時に、エージェントは browser_*、メールツール、account_save を使用します。 credential_create はシステムのキーリングにパスワードを生成し、browser_fill_credential は値をモデルに渡さずにブラウザーへ入力します。個人データベースには参照が保存されますが、共有レプリケーションの対象にはなりません。 システムストレージが利用可能である必要があります。暗号化されていないフォールバックはありません。active 状態は、実際に確認された後に記録されます。人間からの情報が必要な場合は、作り出さずに確認を求める必要があります。

Общая база без настройки реплик

Подключение включено по умолчанию. Приложение и worker автоматически получают общий снимок работодателей, проверяют каждое событие и сохраняют копию. Ввод адресов узлов, отпечатков ключей и ручной запуск синхронизации не нужны. Для чтения аккаунт GitHub не требуется. Для передачи уже опубликованных агентом сведений используется существующий вход gh auth либо WORKLIFE_NETWORK_GITHUB_TOKEN/GITHUB_TOKEN; общий секрет клиента не встроен.

GitHub служит транспортом и дополнительной копией. Авторские подписи остаются в данных, поэтому администратор транспорта не может незаметно переписать уже известное чужое событие. Приложения участников хранят свои копии. Подписанная контрольная точка запоминает принятую историю; повреждение записи, изменение индекса и удаление конца цепочки обнаруживаются. Сохранный архив или проверенная общая копия используются для автоматического восстановления, а повреждённые материалы остаются в локальном карантине. Подтверждённые записи, исчезнувшие из общей копии, повторно передаются; квитанция отправки не считается подтверждением сохранной удалённой копии.

В интерфейсе видны только понятное состояние, количество компаний и число последних подтверждённых копий. Новые записи синхронизируются в фоне, обычная проверка повторяется раз в пять минут. Во время отсутствия связи проверенные записи доступны, отправка ожидает восстановления доступа. Подпись доказывает происхождение, а не правдивость утверждения. Абсолютная сохранность при уничтожении всех независимых копий или компрометации ключей не обещается; распределённого консенсуса здесь нет.

Рынок, резюме и персональный подбор

market_collect собирает явно выбранные запросы, market_snapshot сохраняет неизменяемую выборку, market_report показывает покрытие зарплат, медианы и квантили, распределения и ограничения источников. Браузерные находки проходят через job_save и включаются в выборку по ID. Это статистика собранных объявлений, не оценка всего рынка. Валюта, период выплаты и gross/net не смешиваются; неизвестные суммы не домысливаются. Повторные наблюдения вакансий сохраняются отдельно от их текущего состояния.

Резюме загружается в разделе «Материалы → Резюме» (TXT/MD, PDF с текстовым слоем, DOCX). Исходный файл сохраняется локально и доступен для скачивания. Импортированные факты отмечаются как сообщённые пользователем; скан без текстового слоя требует распознавания вне этого импорта. recommendations_report проверяет условия и факты, cv_match сравнивает версии, а recommendation_save сохраняет смысловой вывод агента с реальными ссылками на факты. Изменение вакансии или профиля делает старый вывод устаревшим. Жёсткие ограничения не отменяются рекомендацией; приоритет не является вероятностью найма.

pipeline_update ведёт этап и следующий шаг, inbox_sync сохраняет входящие и точные связи ответов. Неопределённые сообщения остаются без вакансии; явную связь и локальную отметку прочтения меняет conversation_update. interview_brief готовит вопросы и материалы, interview_save фиксирует встречу, offer_save и offer_compare сохраняют и сравнивают полученные условия. Запись не отправляет приглашение и не принимает оффер. search_review сопоставляет наблюдаемые результаты с ещё незавершёнными ожиданиями. Личные данные этих инструментов не попадают в общую базу работодателей.

Расписания и мониторинг

В локальном приложении откройте Расписание → Автоматические проверки. Выберите период, обновление вакансий, входящие и проверку следующих шагов, затем включите автоматический запуск. «Проверить сейчас» выполняет выбранные проверки и сохраняет результаты в истории, даже если регулярный запуск выключен. Настройки и курсоры входящих сохраняются после перезапуска. Повторный поиск использует сохранённые запросы, источники и языки; параметры площадок и почтовых ящиков не угадываются. Недостающий доступ или отсутствие запросов видны в настройках. Для обычных проверок модель не нужна; отдельное поручение встроенному исполнителю требует его подключения.

Через MCP доступны automation_status, automation_configure и automation_run:

{"enabled":true,"interval_minutes":60,"refresh_search":true,"check_inbox":true,"review":true}

Передайте этот объект в automation_configure после настройки источников. App или worker подхватит доступные источники и поддержит расписания. Ручные задания сохраняют свои настройки; проверки, уже выполняемые ручным расписанием, повторно не запускаются автоматически. Остановка автопроверок не отключает отдельные ручные задания.

schedule_save сохраняет периодическое задание; оно переживает перезапуск. Поддерживаются agent_cycle, jobs_search, connector_read, peer_sync, repository_analyze, reminder, market_collect, market_report, recommendations_report, inbox_sync, search_review. Профиль Recruiter не запускает agent_cycle и peer_sync; эти операции доступны операторскому MCP. Пример для настроенного встроенного агента:

{"name":"Продолжать поиск","tool":"agent_cycle","arguments":{"goal":"Продолжи поиск по моим условиям и проверь входящие","max_steps":8},"interval_minutes":60}

Приложение выполняет due-задания каждые 5 секунд. Для фоновой работы без интерфейса: worklife --config config.toml worker --interval 60. Для одной личной базы используйте один исполнитель: app либо worker. Процесс должен оставаться запущенным; это не системный daemon и не расписание GitHub. Монитор сохраняет каждый запуск, но добавляет активность только при изменении содержимого результата или ошибки. Курсор входящих сохраняется после полного успешного чтения; повторный пустой проход не создаёт уведомление. Новые рассуждения после закрытия AI-клиента требуют автоматизации этого клиента либо настроенного встроенного исполнителя. Статистика разделяет черновики, отправленные действия, стадии отклика, завершённые окна экспериментов и реально измеренные затраты.

Тактики, сильные стороны и разные языки

repository_analyze исследует собственный локальный Git checkout, историю и ограниченный набор файлов, не выполняя код из репозитория. Результат — свидетельства и предложенные сильные стороны. strength_save требует источники и отдельный статус подтверждения. tactic_save хранит гипотезу, действия и критерий успеха; resource_save — площадки, материалы и бюджеты. cv_localize принимает код языка и переводы всех выбранных fact_id от агента, сохраняет оригиналы и источники. Новая языковая версия экспортируется тем же cv_export; скрытой подстановки английского нет.

Исключение работодателей

employer_block(domain,reason,evidence_url) задаёт личный блоклист компании. Известные совпадения исключаются из выдачи и оценки, а контакт блокируется перед постановкой и исполнением действия. Для связи действия с компанией агент указывает _employer_domain либо _job_id в payload; эти технические поля не отправляются провайдеру. Если источник скрывает компанию за агрегатором, агент сначала устанавливает её домен — домен агрегатора не считается доменом работодателя. Сам блоклист личный. Подтверждённые неперсональные наблюдения о компании можно отдельно опубликовать в общую базу.

Подключить к агенту

Старт MCP через stdio:

uv run --env-file .env worklife --config config.toml mcp

Для постоянного подключения используйте пример конфигурации MCP, заменив абсолютные пути. Передайте процессу переменные окружения с нужными секретами: пример JSON сам по себе их не загружает. --env-file /absolute/path/.env можно добавить в аргументы uv run, если harness не передаёт окружение. Изолированная установка без uv: pip install '.[browser]', playwright install chromium, worklife mcp.

Готовые инструкции агента: agent/INSTRUCTIONS.md. Начальная команда агенту:

Используй Worklife. Начни с agent_brief, уточни мои условия жизни и проверенные факты опыта. Найди подходящие вакансии, выясни неизвестные условия и подготовь CV и конкретные действия. Отправляй и публикуй только в рамках моего поручения. Сохраняй результаты и follow-up.

Все инструменты также доступны без MCP через worklife call TOOL '{"arg":"value"}'. Полные схемы аргументов выдаёт worklife tools.

Первый реальный поиск

uv run worklife --config config.toml call jobs_search '{"connector":"greenhouse","query":"Software"}'
uv run worklife --config config.toml call jobs_search '{"connector":"lever","query":"Engineer","parameters":{"limit":20}}'
uv run --env-file .env worklife --config config.toml call jobs_search '{"connector":"hh","query":"Python","parameters":{"page":0,"per_page":20}}'

HH требует корректной регистрации приложения, заголовка User-Agent и доступа к нужным методам. Из данной среды живой запрос HH вернул 403; доступ к HH не подтверждён. Ответ ошибки не превращается в пустую выдачу.

Подключение другой платформы

connector_configure сохраняет адаптер локально, без редактирования исходников:

{
  "name": "my_platform",
  "config": {
    "type": "http",
    "base_url": "https://api.example.org",
    "token_env": "MY_PLATFORM_TOKEN",
    "operations": {
      "inbox": {"method":"GET","path":"/messages","effect":"read"},
      "reply": {"method":"POST","path":"/threads/{thread_id}/messages","effect":"write"}
    }
  }
}

Чтение: connector_read(connector="my_platform", operation="inbox", parameters={...}). Запись: action_draft(connector="my_platform", operation="reply", payload={"thread_id":"123","text":"..."}, ...). Параметры URL кодируются; остальные становятся query-параметрами GET или JSON-телом записи. Для особых протоколов нужен отдельный адаптер. Шаблоны Slack и Brave Search уже есть в config.example.toml. Для операций с API всегда проверяйте не только HTTP-код, но и смысл квитанции: некоторые API возвращают ошибку в JSON с HTTP 200.

Браузерные платформы

Установите browser extra и Chromium. Для входа человека запустите MCP с WORKLIFE_HEADED=1. Сессия сохраняется в личном browser-profile/. Один профиль одновременно обслуживает один MCP-процесс.

browser_open → browser_inspect → browser_prepare(fill/select/check/upload). Клик/Enter — черновик действия с connector="browser", operation="click"/"press", payload={"selector":"...","expected_url":"..."} и при press — key. После действия агент проверяет страницу. browser_screenshot возвращает файл для визуальной проверки. Динамические страницы и вход через CAPTCHA иногда требуют участия человека. На отдельных сайтах даже ввод поля вызывает autosave.

Отправки и состояние

Путь: action_draft → action_approve → action_execute. Одобряет агент в пределах явного разового или постоянного поручения пользователя; отдельный вопрос на каждое письмо не требуется. Черновик показывает конкретные канал, действие и содержание. У одного idempotency_key содержание неизменно. Повторное выполнение уже отправленного действия возвращает сохранённый результат.

Если процесс или связь оборвались во время доставки, состояние остаётся sending/uncertain. Агент сначала проверяет провайдера и вызывает action_reconcile со свидетельством доставки/отсутствия доставки. Для повторной попытки после подтверждённого отсутствия доставки создаётся новый черновик с новым ключом. Exactly-once на стороне произвольной внешней платформы не обещается. sent означает выполнение операции, а SMTP receipt — принятие SMTP-сервером, не прочтение адресатом.

Входящие: почта connector_read(mail, inbox, {criteria,limit,folder}), конкретное письмо — message с uid. Ответ в ветку: email send с to,subject,body,in_reply_to,references,attachments. IMAP-письма читаются без изменения флага Seen. SMTP/IMAP-адаптер поддерживает password/app-password; если почтовый провайдер допускает только OAuth, используйте его HTTP API или добавьте соответствующую авторизацию. Telegram updates принимает offset; агент должен сохранить последний обработанный offset в своей заметке. HH: me,resumes,negotiations,messages для чтения; apply,reply для записи.

Отдельная почта агента: AgentMail

Коннектор agentmail входит в config.example.toml и работает через те же MCP-инструменты Worklife. Отдельный MCP-сервер или дополнительная библиотека не нужны. Создайте ключ в AgentMail Console и задайте AGENTMAIL_API_KEY в .env. Если config.toml создан раньше, скопируйте в него блок [connectors.agentmail] со всеми операциями из примера. Перезапустите MCP-процесс с --env-file .env; connectors_list покажет операции и наличие ключа.

Сначала проверьте существующие ящики:

{"connector":"agentmail","operation":"inboxes","parameters":{}}

Это аргументы connector_read. Если нужен новый адрес, вызовите action_draft:

{"connector":"agentmail","operation":"create_inbox","payload":{"display_name":"Worklife"},"idempotency_key":"agentmail-primary-inbox"}

Затем action_approve и action_execute с ID черновика в рамках поручения пользователя. Сохраните email и inbox_id из результата: email указывайте на сайтах, а inbox_id используйте в следующих вызовах. Повторно используйте существующий ящик, если новый не нужен. Без своего домена адрес создаётся на @agentmail.to.

Чтение через connector_read:

{"connector":"agentmail","operation":"messages","parameters":{"inbox_id":"RETURNED_INBOX_ID","labels":["received"],"limit":20}}
{"connector":"agentmail","operation":"message","parameters":{"inbox_id":"RETURNED_INBOX_ID","message_id":"RETURNED_MESSAGE_ID"}}

Список возвращает метаданные; полный текст и HTML запрашивайте операцией message. text может отсутствовать у HTML-писем. Для ожидаемого подтверждения передавайте в messages параметр after с временем начала операции и проверяйте отправителя, получателя и тему. Следующие страницы доступны через page_token из next_page_token ответа.

Отправка и ответ используют обычный путь действий: send с {inbox_id,to:["[email protected]"],subject,text}, либо reply с {inbox_id,message_id,text}. Здесь тело называется text, а не body, как у SMTP-коннектора. Письма принимаются сервисом постоянно; Worklife читает их при вызове инструмента. Автоматическое пробуждение агента по входящему письму требует отдельной настройки harness. Контракты: создание ящика, список писем, чтение письма.

仮説と CV

profile_save は {id,text,source} の事実を保存します。cv_create は ID でそれらを選択してスナップショットを保存するため、プロフィールを変更しても以前の CV は書き換わりません。見出しと summary は自由記述なので、内容の確認が必要です。形式によって内容の真実性が保証されるわけではありません。

応募の配信前に、バリアント、仮説、指標、観測期間を登録します。 experiment_assign は求人ごとに一貫したバリアントを割り当てます。手動での割り当ては別途記録されます。 測定期間の開始となるのは、applied イベントだけです。下書きや CV の割り当て自体は応募とはみなされません。 レポートの分母は、測定期間が終了した応募済みの求人、分子は、その期間内にあった目標とする返信です。 期間後の返信は保存されますが、事前に選択した指標は変更されません。Wilson 信頼区間とサンプルサイズのしきい値があります。 ここで頻度に大きな差があっても、それは記述統計であり、CV の因果効果が証明されたことにはなりません。 モデルはスキルを追加したり、同じ求人に重複して応募したり、実験のために架空の結果を記録したりしてはなりません。

ブロックチェーンを必須としない共有データベース

共有データベースに含まれるのは雇用主に関する情報のみです。エンティティは正規化されたドメインで識別される企業で、イベント種別は employer と retraction です。従業員のプロフィールや評価、CV、個人的な応募、個人の実験結果、従業員や採用担当者の氏名や連絡先は含まれません。作成者の暗号学的フィンガープリントは記録の技術的な出所を示すものであり、従業員のプロフィールではありません。 保存形式は、参加者がそれぞれ独立したコピーを保持する署名付きログの集合です。 各参加者は、受信した共有イベントの完全なローカルコピーを SQLite に保存します。

flowchart LR
    A[Агент A] --> PA[Личные данные A]
    A --> LA[Подписанный общий журнал A]
    B[Агент B] --> PB[Личные данные B]
    B --> LB[Подписанный общий журнал B]
    LA <-->|Проверка подписей и обмен событиями| LB
    LB <--> LC[Независимая реплика C]
    LA --> BA[Отдельный backup]

イベント ID は event_id = SHA-256(canonical JSON тела)、署名は event_id の 32 バイトに対する Ed25519 です。 本文には、作成者のフィンガープリント、公開鍵、シーケンス番号、前のイベントのハッシュ、種別、対象、payload、時刻が含まれます。作成者のフィンガープリントは、その公開鍵の SHA-256 です。 Canonical JSON v1：UTF-8、キーは順序どおり、区切り文字は ,／:, Unicode は ASCII エスケープせず、NaN／Infinity は使用しません。プロトコルは現時点では Python を優先しており、他の言語では数値／Unicode のエンコードを正確に再現する必要があります。

受信時には、スキーマ、サイズ、ハッシュ、署名、チェーンの連続性、同じ作成者と同じ番号を持つ別の記録が存在しないことを検証します。パッケージは一括で受け入れるか、拒否します。 すでに認識されているイベントの再送は安全です。分岐が検出された場合、エラーで同期を停止します。「正しい」ブランチを自動的に選択することはありません。 修正は、同じ対象を持つ自身のイベントを supersedes で指定した新しい記録として行います。 撤回は kind="retraction" で行います。元の記録はログに残り、通常の表示では撤回が反映されます。 参加者は他者の記録を書き換えたり、撤回したりすることはできません。

公開する payload は claim,source_url,observed_at,evidence_kind で、name,tags,metrics,supersedes は任意です。 証拠の種別は advertised、confirmed、observed、hypothesis です。 subject は小文字／IDNA 形式の企業ドメインです。指定する場合、name は企業名です。 許可される指標は response_days、hiring_stages、test_hours、weekly_hours、salary_delay_days です。 タグは雇用主に関するものに限られます：organization、vacancy、salary、remote、schedule、hiring_process、 test_task、communication、payment、working_conditions、benefits。任意の種別／対象／指標は、正しい署名があっても、公開時と他のノードからの受信時の両方で拒否されます。 スキーマによってプロフィール／CV の構造を直接渡すことは防げますが、それだけで自由記述内のあらゆる個人情報を検出できるわけではありません。 公開前に、エージェントはテキストが雇用主に関するものであり、個人情報を含まないことを確認します。すでに各所に拡散した個人情報をすべてのレプリカから取り戻すことはできません。 source_url は出典を示します。署名の対象は主張とリンクであり、変更可能なウェブページのスナップショットではありません。

Честные гарантии

Это проверяемое авторство и обнаружение подмены, не обещание «данные невозможно подделать вообще». Блокчейн не проверит правдивость работодателя или автора. Общий консенсус, комиссии, публичная публикация и управление валидаторами здесь не добавлены; для текущей задачи хватает подписей и независимых копий. Если понадобится публично доказывать существование истории к определённой дате, отдельный checkpoint-anchor можно спроектировать после выбора требуемой модели доверия.

uv run worklife --home /path/to/node init
export WORKLIFE_NETWORK_TOKEN='a-long-random-shared-secret'
uv run worklife --home /path/to/node serve --host 127.0.0.1 --port 8765

uv run --env-file .env worklife --config config.toml sync
uv run --env-file .env worklife --config config.toml worker --interval 300
uv run worklife --config config.toml verify
uv run worklife --config config.toml export shared.jsonl
uv run worklife --home /path/to/new-node import shared.jsonl

Резервное копирование

uv run worklife --config config.toml backup /path/to/new-backup-directory
uv run worklife restore /path/to/new-backup-directory /path/to/restored-state

Backup содержит личную базу и приватный ключ автора. Контрольные суммы выявляют случайную порчу, но не заменяют цифровую подпись backup или шифрование. Храните backup на отдельном носителе/в зашифрованном хранилище. При restore не запускайте исходный и восстановленный узлы на запись с одним ключом: это создаёт две ветки одного автора. Другому участнику нужна новая identity; общие данные передаются export/import, а не копированием приватного ключа. Пароли системной связки ключей, браузерные cookies, экспортированные файлы и конфигурация в SQLite backup не входят: при необходимости сохраните их отдельно.

Развёртывание и проверка

Сборка и проверки: uv sync --locked --extra dev --extra browser, uv run pytest -q, uv run ruff check src tests. Для разработки интерфейса нужны Node 22.12+ и исходники frontend/: npm ci, npm test, npm run build. Сборка использует настоящие @heroui/react/@heroui/styles и обновляет и приложение в Python-пакете, и GitHub Pages. Готовые браузерные файлы включены в репозиторий/пакет; для обычного запуска приложения Node не нужен. Docker-вариант сервера репликации — Dockerfile, compose.yaml. Постоянные тома обязательны; развёртывание в интернете, домен, TLS, реальные аккаунты и независимые узлы нужно настроить отдельно. Встроенная MCP-точка входа — stdio. HTTP-сервер в compose предназначен для репликации, не для удалённого управления личным агентом.

Приёмка карьерного сценария через настоящий MCP и отдельный worker с локальным тестовым провайдером: uv run --no-env-file python scripts/verify_career_workflow.py. Персональные данные и внешние отправки не используются.

Подробные результаты прежних версий: docs/verification.md. Официальные контракты: MCP Python SDK, HH API, Greenhouse, Lever, Telegram Bot API, Playwright, Ed25519.

Пользовательские сценарии и последующая переработка описаны в отчёте трёх агентских проходов.