Рабочие области и проекты

Из этой страницы вы узнаете:

как вложены друг в друга аккаунт, проект и рабочая область;
как ключ ограничивает агента одним проектом;
когда заводить отдельную рабочую область и что делать с ошибками доступа.

Пример на всю страницу: вы ведёте два проекта — backend и mobile. Агенту в репозитории backend незачем видеть заметки по мобильному приложению, а архитектурные решения и журнал инцидентов хочется держать раздельно.

Как всё вложено

  Аккаунт (личное пространство)        Организация (отдельное пространство)
  │                                      │
  ├── Проект default  ◀── ключ без привязки
  │     └── workspace default
  ├── Проект backend  ◀── ключ «backend»
  │     ├── workspace default
  │     ├── workspace decisions
  │     └── workspace incidents
  └── Проект mobile   ◀── ключ «mobile»
        └── workspace mobile-notes

Аккаунт — ваше личное пространство. Аккаунты полностью изолированы друг от друга.
Проект — граница доступа для ключа. Лимит записей тарифа считается на проект.
Рабочая область (workspace) — именованная коллекция записей внутри проекта. По умолчанию — default.

Проекты и ключи

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

Ключ можно привязать к проекту в кабинете. Агент с таким ключом читает и пишет только записи этого проекта: search не вернёт записи соседнего проекта, forget не сможет их удалить. Это настоящая граница доступа, в отличие от ярлыка scope.

Для нашего примера: выпустите два ключа — «backend» и «mobile» — и пропишите каждый в конфигурацию MCP соответствующего репозитория или клиента. Подробнее о ключах — Ключи и OAuth.

Рабочие области

Рабочая область создаётся сама при первой записи в неё: достаточно вызвать remember с новым workspace.

{
  "content": "Решили хранить сессии пользователей в Redis, а не в PostgreSQL: нужен TTL",
  "workspace": "decisions",
  "fact_key": "backend.sessions.storage"
}

Что важно знать:

Поиск идёт в одной области. search ищет только в переданном workspace (по умолчанию default). Если агент сохранил решение в decisions, а ищет в default — он его не найдёт. Пропишите имена областей в инструкции агенту (см. Правила для агентов).
Поиск не создаёт область. Если области ещё нет, search вернёт ошибку workspace '…' is not active. Сначала нужна хотя бы одна запись.
Конфликты считаются внутри области. Две записи с одним fact_key в разных областях не конфликтуют.
Имя области уникально в аккаунте. Область принадлежит проекту, в котором она создана. Если decisions создана ключом проекта backend, ключ проекта mobile получит 403 Forbidden: workspace access denied for project. Для mobile выберите другое имя, например mobile-decisions.
Удалённое имя не используется повторно. После удаления области её имя занять снова нельзя: workspace '…' was deleted and cannot be reused.

Когда заводить отдельную область

Заводите, если у записей разный жизненный цикл или разный читатель:

Область	Что в ней	Зачем отдельно
`default`	Текущие факты проекта: как собрать, как выкатить, где что лежит	Основное место поиска
`decisions`	Архитектурные решения с причинами	Не тонут среди мелких фактов
`incidents`	Разборы инцидентов	Можно периодически чистить через `forget` по `source_id`
`docs`	Факты, извлечённые из документов с `source_id`	Удобно проверять свежесть через `validate_memory`

Не заводите по области на каждую задачу или день — агенту станет сложно понять, где искать.

Лимиты

Лимиты зависят от тарифа: число записей на проект (Free — 250, Starter — до 5 000 на проект, Pro — до 100 000, Enterprise — до 1 000 000) и число вызовов в минуту. Кроме того, ограничено число записей в одной рабочей области и в аккаунте в целом. Когда лимит достигнут, remember отклоняется с понятной ошибкой, а чтение продолжает работать. Подробно — Лимиты.

Организации

Организация — отдельное пространство со своими проектами и записями. У человека один логин, личное пространство и любое число организаций; переключатель — в кабинете. Организация никогда не становится пространством по умолчанию.

Сотрудник выпускает ключ для работы в организации сам; администратор видит и может отозвать ключи, но не раскрыть их. Внутри организации, помимо проекта, действует видимость записи (автор, отдел, проект, вся организация). См. Организации и Видимость.

Что дальше

Основные понятия Поля записи, статусы и связи.

Ключи и OAuth Как выпустить ключ и привязать его к проекту.

Правила для агентов Готовая инструкция с именами рабочих областей.