Правила агента

Подключить MCP-эндпоинт — половина дела. Вторая половина в том, чтобы агент сам начинал работу с базы знаний, а не после вашего «сходи сначала в Notarium». Эта страница — про то, как это закрепить один раз.

Почему одного подключения мало

Какой инструмент вызвать — решает модель. Со стороны сервера Notarium делает всё, что может: при инициализации отдаёт instructions («позови start_session первым»), а описание самого инструмента прямо говорит, что он идемпотентен и безопасен для повторного вызова. Это заметно повышает вероятность, но гарантией не является — и по конструкции протокола быть не может.

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

Не вызвал — ничего не сломалось

Пропуск start_session не ломает работу: остальные инструменты самодостаточны, а границы доступа держит токен, а не дисциплина агента. Разница только в контексте — агент не увидит ваш профиль, дельту изменений и словарь принятых категорий, а значит с большей вероятностью заведёт дубль или назовёт вещи по-своему.

Куда это писать

Почти у каждого агентского клиента есть файл постоянных инструкций, который подмешивается в каждую сессию:

Клиент	Где обычно лежит
Claude Code	`CLAUDE.md` в корне репозитория (и глобальный — в домашнем каталоге)
Codex	`AGENTS.md` в корне репозитория
Cursor	правила проекта в `.cursor/rules`
Свой агент или API-интеграция	системный промпт

Формат и точные пути задаёт клиент и меняет их независимо от нас — сверяйтесь с его документацией. Notarium ничего не требует от файла: это обычный текст, который читает ваш агент.

Минимальный блок

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

## Notarium — база знаний проекта

- В начале новой сессии вызови `start_session(project: "acme/website")`
  на MCP-сервере `notarium` — профиль, доступные проекты, индекс этого
  проекта, дельта изменений с прошлого визита и словарь категорий.
- **Ищи перед записью:** `search("<тема>", project: "acme/website")` —
  поиск покрывает и твою собственную память, поэтому дубли ловятся.
- Долговечные факты о проекте пиши через `remember_about_project`,
  о владельце — `remember_about_user`, общее видимое знание — `create_note`.

Хэндл проекта подставьте свой. Обычно он имеет вид пространство/проект, но у корневого проекта пространства схлопывается до одного сегмента — просто пространство. Не выводите его по правилу: готовый список выдаёт get_my_projects, оттуда его и берите дословно. В файле правил лучше зафиксировать точное значение, чтобы агент не искал его каждый раз.

Один вызов вместо пяти

start_session собран как раз для этого: за один запрос он отдаёт то, на что иначе ушло бы несколько разведочных вызовов и лишний контекст. Он идемпотентен — перевызвать его после сжатия контекста безопасно, побочных эффектов не будет. Единственное, что не повторится, — дельта изменений: первый вызов по умолчанию сдвигает закладку «последнего визита», поэтому второй вернёт её уже пустой. Подсмотреть дельту, не сдвигая закладку, можно вызовом с acknowledge: false.

Расширенный блок: карта канона

Если у проекта есть заметки, которые нужно читать под конкретную роль или задачу, не заставляйте агента искать их заново каждую сессию — дайте карту. Точечная загрузка дешевле, чем «прочитай весь проект»:

## Notarium

- Первым вызовом — `start_session(project: "acme/website")`.
- Дальше грузись точечно, а не читай проект целиком:
  - конвенции разработки — `get_note("<id>")`;
  - чек-лист ревью — `get_note("<id>")`;
  - контекст вокруг темы — `recall("<тема>", project: "acme/website")`.
- Перед любой записью — `search("<тема>", project: "acme/website")`.
- Рабочий лог и решения по задаче веди в Notarium,
  а не в файлах репозитория.

Идентификаторы заметок стабильны: они переживают переименование и перенос, поэтому карта не протухает от реорганизации базы. Ссылку [[по заголовку]] тоже не сломает переименование — старый заголовок уходит в историю алиасов.

Два слоя правил

Разделяйте инструкции по времени жизни — так их не приходится дублировать в каждом репозитории:

Глобальный слой (общий файл правил или системный промпт) — то, что верно всегда: звать start_session первым, искать перед записью, куда писать факты о владельце. Хэндла проекта здесь нет.
Проектный слой (файл в репозитории) — хэндл конкретного проекта, карта канона, локальные договорённости.

Тогда подключение нового репозитория к базе — это несколько строк с одним хэндлом, а общие правила лежат в одном месте.

Чего в правилах быть не должно

Правила агента — не механизм безопасности

Файл правил — это подсказка, а не граница. Что агент может сделать, определяют права токена и набор инструментов: read-токен физически не видит пишущих инструментов, чужое пространство недостижимо в принципе. Не пытайтесь ограничить агента текстом там, где нужен scope токена — см. Безопасность и видимость.

Ещё две вещи, которые туда попадать не должны:

Токены. Файл правил обычно лежит в git. Персональный токен задаётся в конфигурации MCP-клиента, а не в инструкции.
Пересказ справочника инструментов. Имена и описания агент и так видит в tools/list, они статичны и всегда актуальны. Дублирование в файле правил быстро расходится с реальностью — пишите намерения и договорённости, а не копию документации.

Как это сочетается с курированием контекста

Две половины одной задачи, и они не заменяют друг друга:

Файл правил отвечает за то, что вызов start_session произойдёт.
Раздел Agents → Context отвечает за то, что именно этот вызов принесёт: пины always-load, контекст-наборы и приглушение шумных категорий памяти — всё под общий токен-бюджет.

Поэтому если агент стартует с контекстом, но не с тем, — правьте не файл правил, а контекст-наборы и пины.

Дальше

Подключение агента — токен, OAuth-коннектор, транспорт.
Контекст-наборы и пины — что попадает в start_session.
Интент-инструменты — полный набор и порядок вызовов.
Память агента — чем remember_* отличается от create_note.