Разделение контекста

Две независимые оси

Ребро задаёт, кто может искать. Federation-ребро: направленная связь A → B, которая даёт агенту A право искать у B. Направление важно: A → B не даёт B права искать у A. Каждое ребро состоит из KB-заметки на стороне A (mcp_federation_kb_url указывает на B) и пары секретов с заданным scope, которыми стороны обмениваются один раз.

Подграф задаёт, что видно при поиске. Каждая заметка может нести метку subgraph:. Секрет ребра привязан к одному или нескольким подграфам, и пир возвращает только заметки из них. Заметка в подграфе, которого ребро не выдаёт, не вернётся никогда, даже по валидной аутентифицированной связи.

Оси ортогональны, и в этом весь смысл. Вы даёте право на поиск, но открываете только выбранный срез, а остальное запечатываете.

Пример. Дайте партнёру ребро к вашей базе и привяжите его секрет к подграфу shared-research. Партнёр может искать у вас и видит ваши исследовательские заметки, и больше ничего.

Антипример. Тот же партнёр запускает поиск, который совпал бы с заметкой client-contracts. Заметка в приватном подграфе, который его ребро не включает. Партнёр получает пустой результат. Ребро валидно; заметка остаётся на месте.

Ребро определяет, кто может искать. Подграф определяет, что видно при этом поиске.

Разбор на примере организации

Возьмём организацию из двух компаний под общим владельцем. Десять баз знаний, одиннадцать направленных рёбер. Каждая база является отдельным инстансом trip2g с собственным эндпоинтом /_system/mcp, заметками и администрированием.

Роли:

Стрелки указывают направление поиска: A → B означает «A может искать у B».

flowchart TD
    owner([HQ]) --> chA[Хаб компании A]
    owner --> chB[Хаб компании B]
    bossA([Глава компании A]) --> chA
    bossB([Глава компании B]) --> chB
    chA --> dA[Хаб отдела A]
    chA --> dB[Хаб отдела B]
    chB --> site[Общий сайт]
    chB --> sB[Команда B-прямая]
    dA --> sA[Команда A1]
    dB --> sB
    site --> sA

Легенда. Стрелка A → B означает «A может искать у B». Каждая база держит 🔒 приватный контекст, в который не заходит ни одна стрелка.

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

Что доступно каждой роли

Читайте таблицу сверху вниз. Одна закономерность повторяется в каждой строке: ничей приватный контекст недостижим. Охват меняется по роли; приватная граница не сдвигается.

Что показывает эта топология

Боковой вход даёт частичную видимость по замыслу. Глава компании A входит в граф через одно ребро в хаб компании A. Оттуда он достаёт всю компанию A и ничего из компании B. Запрет на компанию B вы не настраивали: там просто нет ребра. Видимость определяется тем, что вы выдаёте, а не тем, что явно запрещаете.

Ромбы показывают, что база может принадлежать нескольким контекстам. Команда A1 достижима двумя путями: через хаб отдела A и через общий сайт. Команда B-прямая достижима через хаб отдела B и через хаб компании B. Одна база входит в несколько контекстов без копирования ни в один из них.

Направление поиска одностороннее, пока вы не сделаете его двусторонним. HQ ищет у компаний; компании у HQ не ищут. Каждое ребро даёт ровно одно направление. Чтобы ребёнок запрашивал родителя, добавьте отдельное обратное ребро со своим секретом. Большинство организационных границ односторонние, и это поведение по умолчанию.

Приватная изоляция гарантирована на уровне scope. Каждая база хранит приватную заметку, которую не вернёт ни одно ребро. Родитель с валидным аутентифицированным ребром к ребёнку всё равно не видит приватный контекст ребёнка. Ребро открывает публичный подграф; приватный в scope не входит, и поиск проходит мимо приватной заметки. Хаб отдела A может искать у команды A1 сколько угодно и никогда не увидит её приватную заметку.

Каждая база остаётся автономной: свои заметки, своё администрирование, свой приватный контекст. Федерация работает как роутинг с заданным scope: общего индекса нет, между базами ничего не копируется.

Как это настроить

Приём одинаков для каждого ребра A → B:

1. На стороне B добавьте входящий секрет и привяжите его scope только к публичному подграфу, приватный оставьте за рамками. Этот выбор запечатывает приватный контекст B.
2. На стороне A добавьте парный исходящий секрет и KB-заметку, где mcp_federation_kb_url указывает на /_system/mcp базы B.
3. Пометьте приватные заметки B подграфом, который входящий секрет не выдаёт.

Повторите для каждого из одиннадцати рёбер. Для ромбов у листа просто два входящих секрета, по одному на каждого родителя. Для обратного направления пройдите те же три шага в обратную сторону.

Точные шаги в администрировании, обмен секретами и панель scope смотрите в ru/user/federation: там пошаговая инструкция. Эта страница даёт общую картину.

Дополнительно

• ru/user/federation: механика: KB-заметки, секреты, scope подграфов, панель графа федерации
• ru/user/mcp: как работает локальный MCP-сервер и контроль доступа по подграфам
• ru/user/advanced: подграфы и управление доступом в продукте в целом