Worklife — AI job search

Worklife — 用于 AI 求职的 MCP 服务

Worklife 是一款本地优先的 Model Context Protocol（MCP）服务和职业助手，面向 求职者。将 AI Agent 连接到招聘网站和雇主网站，以搜索职位、根据你的经验比较职位空缺、 准备真实准确的简历，并跟踪申请、邮件、 面试和录用通知。

它提供薪资和就业市场分析、本地求职申请跟踪器、浏览器和 API 工具， 以及由签名雇主观察信息组成的共享网络。你的个人资料、简历和通信内容 存储在个人工作区中；共享知识库用于存放雇主信息。 Agent 在你的 MCP 客户端中运行，也可以选择使用内置模型运行器。

网站 · PyPI · MCP Registry · Agent 设置 · 发现与 Registry 发布 · 俄语文档

使用 Python 3.12+ 和 uv 为你的客户端安装职业 Agent：

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"]
    }
  }
}

这会启动 MCP 服务，并将本地数据存储在 ~/.worklife。浏览器自动化还需要 browser extra 和 Chromium；上面的设置命令会安装这两者。账户和连接器需单独配置。Worklife 不提供对招聘平台的无限制访问。

Worklife（俄语）

共享数据库可以通过专用的 Telegram 服务群组进行同步： 同步签名区块、读取遗漏的历史记录，并连接新的空白副本。 设置和创建群组请参阅 Telegram 同步。

无需代币和手续费的新网络：协议和 公开测试准备。 配置文件 public-testnet-v1 使用独立的 genesis、PoW 25/18 位和六次 确认。下文较早提及的 GitHub relay 描述属于 legacy 提案。

项目主页 · 源代码 · Agent 指南

自主求职工具包。由用户设定目标和条件； Agent 搜索合适的职位、了解工作条件、处理通信、准备 CV、 验证假设，并与其他参与者交流可验证签名的经验。

0.5 版：Telegram 同步与 P2P 交换、引导流程、雇主数据库状态透明化，以及更新通知。 Agent 自主选择搜索来源，使用浏览器和 API，跟踪注册、通信和实验。 你可以连接自己的 MCP 环境，也可以配置模型来运行内置 Agent 循环。 没有固定的招聘平台列表；内置适配器可与浏览器和可配置的 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 Agent 聊天中进行；浏览器显示工具调用、结果和设置。Agent 会自行管理平台、资源、账户、日程和实验。 应用会显示真实数据： Agent 活动、市场、职位和招聘漏斗、往来通信、面试和录用通知、日程、实验、简历、资源、 账户、代码仓库以及共享雇主数据库的状态。空数据库会保持为空——不会填入项目页面上的演示数字。个人界面仅可通过 loopback 访问； 公开的 GitHub Pages 页面用于介绍项目，不会接收个人数据。

通过外部 MCP Agent 使用时，不需要单独的 Worklife 模型。 网站和本地界面的语言可在“Русский / English”菜单中切换，并保存在浏览器中； 首次打开时会考虑浏览器语言。在“我的条件 → 更多 → 搜索语言”中，可以单独选择搜索查询所用语言。Agent 会为每种 所选语言匹配职位名称和同义词，同时保留原始职位信息。未选择任何语言时，搜索语言不受限制。 市场报告会显示已执行和跳过的查询语言。 通过 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 需要提供其密钥。项目不会选择付费服务，也不会在未配置时发起调用。 在展开的内置执行器部分中设定目标：模型会获得工具，并执行带有实际调用和结果日志的循环。可以限制步数并请求停止。 注册时，Agent 会使用 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]

对于事件，event_id = SHA-256(canonical JSON тела)；签名是对 32 字节 event_id 的 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 结构，但本身无法识别任意文本中的所有个人数据。 发布前，Agent 会检查文本是否与雇主有关且不包含个人信息。无法从所有副本中撤回已经传播的个人信息。 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.

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