Первый веб-нативный каркас для ИИ-агентов

peerd — это первая универсальная среда выполнения агентов, построенная непосредственно на браузерных примитивах: Workers, origins, sandboxing, OPFS, WASM/WASI, WebRTC, WebAuthn и WebExtensions. Он полностью работает внутри Chrome и Firefox, с вашими вкладками, авторизованными сессиями, веб-приложениями и локальными вычислениями.

В то время как агентные платформы пытаются втянуть браузер в каркас, peerd втягивает каркас в браузер.

Для непосредственного инференса можно выбрать поддерживаемого хостинг-провайдера моделей, локальную модель через localhost или ознакомиться с предварительной поддержкой локальных WebGPU-моделей (мы также присматриваемся к WebNN).

Учётная запись peerd, размещённый браузер или подключение к серверу инструментов не требуются. Текущие сборки не отправляют в peerd телеметрию продукта.

Установка · peerd.ai · Архитектура · Безопасность

Возможности

• Работает в браузере, которым вы уже пользуетесь. Агент может читать ваши вкладки, веб-приложения, авторизованные сессии и содержимое страниц и управлять ими.
• Создаёт переиспользуемые клиенты сайтов. Веб-актор может один раз изучить сайт и использовать этот клиент в последующих задачах.
• Выполняет код в границах браузера. Скрипты, запечатанные JavaScript-ноутбуки, скомпилированные WASI-инструменты, браузерные Apps и Linux WebVM дают агенту локальные вычисления без доступа к хост-операционной системе.
• Делегирует отдельным акторам. Каждая страница и вычислительная среда получает собственного актора без ключей с инструментами, ограниченными этой средой.
• Сохраняет полезный контекст. Сессии, память, навыки, цели, проверки и контрольные точки хранятся в расширении.
• Использует выбранную вами модель. Актуальный перечень провайдеров определён в registry.js, включая облачные адаптеры BYOK и локальные варианты без ключей.
• Соединяет браузеры напрямую. Preview-сборки добавляют подписанную идентичность, взаимное обнаружение браузеров, dwapp и связь между агентами через WebRTC; магазинные пакеты полностью это вырезают.

Почему браузер

Локальные агенты могут получить доступ ко всему вашему компьютеру. Удалённые агенты живут в чужой системе. Браузер — это альтернатива: локальные возможности за границами безопасности, закалёнными за три десятилетия.

peerd использует эти границы. Работа со страницами передаётся отдельным акторам, у которых есть только инструменты для этой вкладки или среды. Учётные данные, сетевые правила, подтверждения и аудит остаются в расширении. Его эшелонированная защита исходит из того, что небезопасное содержимое рано или поздно пройдёт через фильтр.

Поддержка браузеров

peerd поддерживает Chromium и Firefox. Firefox запускает акторов в выделенных воркерах и использует видимые ноутбуки для JavaScript-вычислений. Возможности, которым нужен offscreen-хост документов Chrome, перед использованием удаляются из элементов управления Firefox и инструментов моделей. Preview-сборки Firefox не включают dweb, пока в Firefox не появится mesh-хост.

Apps и WebVM работают в Chrome. У Apps нет фонового доступа к сети. Удалённые ресурсы, fetch-запросы, WebRTC, формы и внешняя навигация по документам заблокированы. Внешние HTTP- и HTTPS-ссылки требуют подтверждения пользователя.

Конкретные пробелы в возможностях браузеров, связанные с ними upstream-проблемы и тесты, необходимые для снятия каждой защиты, отслеживаются в docs/BROWSER-COMPATIBILITY.md.

Код — источник истины о текущем поведении. Начните с CLAUDE.md, затем прочитайте соответствующий модуль в extension/.

Модель безопасности

peerd использует изоляцию браузера, узкую область действия инструментов, шлюзы политик в service-worker и явный контроль исходящего трафика. Главный агент делегирует работу со средой акторам без ключей. В Chrome и Firefox циклы агентов, не являющихся оркестраторами, выполняются в отдельных выделенных кучах воркеров. Если браузер не может доказать эту границу, запрос актора не выполняется и не совершает никакой работы над своей целью.

Сетевое поведение зависит от операции. Вызовы моделей, чтение веб-ресурсов, загрузка ресурсов среды выполнения, трафик песочницы и dweb-трафик preview-сборок используют разные ограниченные пути и политики. Текущие границы и известные ограничения см. в SECURITY.md и модели угроз.

Установка

Chrome из исходников

1. Клонируйте репозиторий.
2. Откройте chrome://extensions.
3. Включите режим разработчика.
4. Выберите Загрузить распакованное расширение и укажите каталог extension/.

После изменений исходников перезагрузите расширение на странице chrome://extensions.

Firefox из исходников

Firefox требует пакет, собранный специально для Firefox. Не загружайте включённый в репозиторий Chrome-манифест для разработки. Используйте Firefox версии не ниже минимальной, указанной в патче канала в manifests/. Этот минимум соответствует поддержке скриптов, привязанных к документу, которую используют браузерные инструменты.

Откройте about:debugging#/runtime/this-firefox, выберите Загрузить временное дополнение и укажите artifacts/peerd-preview-firefox.xpi. Временные дополнения нужно загружать заново после перезапуска Firefox. Преобразования для браузеров и каналов определяются скриптами упаковки.

Пакеты релизов

Актуальные артефакты см. в GitHub Releases. Store- и preview-сборки различаются. Store-сборки не включают dweb. Preview-сборки включают его и могут активировать дополнительные возможности автоматизации. Код упаковки — авторитетный источник для каждого браузера и канала.

Первый запуск

1. Откройте peerd на панели инструментов браузера.
2. Создайте и разблокируйте локальное хранилище. Разблокировка парольной фразой доступна всегда. Разблокировка passkey зависит от поддержки WebAuthn PRF в браузере и на устройстве.
3. Завершите короткую первичную настройку профиля.
4. Откройте «Настройки», затем добавьте ключ провайдера или выберите поддерживаемого локального провайдера.
5. Выберите модель и начните чат.

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

Архитектура

Расширение состоит из пяти основных модулей. Каждый модуль предоставляет свой публичный API через index.js.

Каркас расширения находится в background/, offscreen/, sidepanel/, engine-tabs/, permissions/, shared/ и связанных вспомогательных каталогах. Размещение хостов и правило холодного воркера описаны в docs/EXTENSION-HOSTS.md.

Разработка

Исходное расширение — это ванильный JavaScript с ES-модулями, который запускается напрямую при загрузке распакованным. Здесь нет dev-бандлера, транспилятора, вотчера или генерируемого дерева рантайма. Упаковка релизов использует Bun только на своей одноразовой staging-копии, чтобы удалить пробелы и комментарии из авторских модулей в статическом service-worker и холодных offscreen-графах Chrome. Она сохраняет границы модулей, имена привязок, ленивые импорты и каждый вендоренный байт. Передавайте --no-minify в bun run package -- ..., когда нужен читаемый диагностический артефакт.

Есть три уровня тестирования:

• Тесты Bun для чистой логики.
• Внутрибраузерные тесты для интеграции расширения и браузера. Они выполняются в headless-режиме в Chrome и, шардированно, в Gecko против установленного магазинного пакета Firefox. Каждая полоса выполняет все тесты, которые регистрирует; итоговые числа немного различаются, потому что некоторые тесты регистрируются только там, где отвечает живой service worker.
• Живые E2E-тесты в Chrome и визуальная проверка полных сценариев.

Наряду с ними red-team-набор в tests/red-team/ прогоняет каждого противника из модели угроз против реального защитного кода и фиксирует, был ли заблокирован каждый враждебный зонд. Его матрица находится в docs/security/RED-TEAM-RESULTS.md.

Каждая полоса публикует свой счётчик в виде бейджа выше. JSON бейджей в badges/ генерируется CI-задачей, которая запускала полосу, а затем сверяется по диффу, поэтому число на этой странице — всегда свидетельство реально состоявшегося запуска, а не введённая кем-то цифра. Перегенерируйте нужный бейдж командой bun run gen:badge:functional, bun run gen:badge:red-team, bun run gen:badge:inbrowser, bun run gen:badge:gecko (нужны Firefox и geckodriver) или bun run gen:badge:e2e, и закоммитьте результат. bun run check:badges проверяет корректность формата endpoints без запуска браузера.

При изменениях в UI запустите bun run e2e:verify, изучите scripts/cdp/artifacts/result.json и просмотрите сгенерированные скриншоты.

Сгенерированные файлы нельзя редактировать вручную. В частности, extension/manifest.json и extension/shared/channel-config.js создаются из исходников манифеста и упаковки. CI проверяет их на расхождения.

Прежде чем менять код, прочитайте CONTRIBUTING.md.

Документация

• CLAUDE.md: структура проекта, соглашения и текущее состояние
• SECURITY.md: политика безопасности и порядок сообщений об уязвимостях
• docs/security/THREAT-MODEL.md: границы доверия и остаточные риски
• docs/security/LIFECYCLE-CONTRACT.md: поведение при прерывании и ограничения восстановления
• docs/security/RED-TEAM-RESULTS.md: покрытие red-team
• docs/APP-ACTORS.md: App-акторы, определяемые манифестом, живые семантические адаптеры и UX со-пилота во вкладке
• docs/DWAPP-BUNDLE.md: сжатый транспорт dwapp, декодированные рабочие деревья и бинарные ресурсы
• docs/store/: упаковка для магазина, разрешения, конфиденциальность и заметки для рецензентов
• scripts/cdp/states.mjs: E2E- и визуальные состояния

Зависимости и лицензия

Поставляемое расширение не имеет npm-зависимостей времени выполнения. package.json не объявляет ни одной, а упаковка никогда не разрешает путь node_modules в подготавливаемом артефакте, поэтому дерево инструментов разработки не может дотянуться до установленного браузера. Вместо этого сторонний код времени выполнения вендорится в extension/vendor/. Его исходники, версия и лицензия находятся в соседних файлах SOURCE.txt, а каждый вендоренный байт закреплён SHA-256 в extension/vendor/vendor.lock.json, который bun run check:vendor проверяет в CI и preflight.

Ещё две позиции цепочки поставок имеют собственные бейджи выше; обе перегенерируются командой bun run gen:dev и проверяются на расхождения в CI. Каждый сторонний GitHub Action выполняется по полному SHA коммита под контролем check:actions: старший тег — это изменяемая ссылка, которую издатель может переместить, а это означало бы произвольный код в задаче, содержащей этот чек-аут, а в release-воркфлоу — и секреты подписи. Недавно добавленные зависимости также выдерживают карантинный период, прежде чем попасть в lock; его длительность задаётся параметром minimumReleaseAge в bunfig.toml, а при установке выполняется сканирование на вредоносное ПО.

peerd распространяется по лицензии Apache License 2.0. Вендоренные компоненты сохраняют собственные лицензии. CheerpX — это проприетарная среда выполнения от Leaning Technologies, на которую не распространяется Apache-лицензия peerd.