Как собрать командную базу знаний с AI-агентом

Зачем команде общая база знаний

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

Дальше начинается знакомое.

Последний пункт встречается чаще остальных. База знаний у компании обычно есть, проблема в том, что до нужной страницы никто не доходит.

Здесь и появляется разница. В командной базе на агенте вход один, и это чат. Человек спрашивает словами, как спросил бы коллегу, а агент идет по материалам команды и отвечает по ним. Вместо вас в базу приходит стажер и задает свой вопрос ровно так же, как вы задаете вопрос своему агенту.

Если агент ответа не нашел, скорее всего этой информации там правда нет. И тогда тот, кто спрашивал, задумается, как ее туда положить. Задача перестает быть проблемой одного эксперта и становится веткой изменений от человека, который в нее уперся.

---

Чем командная база отличается от личной

Механика та же самая. Папка с текстовыми файлами, корневой файл с правилами, роли, поиск, скиллы. Если вы уже собирали личный Second Brain, половина этого гайда будет вам знакома. Отличия начинаются там, где к системе получают доступ другие люди.

Слой	Личный Second Brain	Командный Team OS
Кто пользуется	Вы один	Команда с разными уровнями доступа
Где живет	Папка на компьютере	Приватный репозиторий на GitHub или GitLab
Как вносятся правки	Пишете сразу	Ветка, merge request, ревью, слияние
Память агента	Корневой файл правил	Тот же файл плюс файл с доступами
Что внутри	Ваш личный контекст и проекты	Знания отделов, шаблоны, гайдлайны, скиллы
Кто отвечает	Вы	Владельцы направлений по своим зонам
Что держит систему живой	Ваша привычка	Ритуалы команды и регулярные аудиты

Из таблицы видно главное. Личная база держится на одном человеке, командная держится на договоренностях. Технически собрать репозиторий можно за день. Работать он начинает тогда, когда понятно, кто принимает изменения, кто отвечает за содержимое направления и что происходит с материалом после встречи.

---

Из чего состоит Team OS

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

1. Хранилище. Приватный репозиторий с папками и Markdown-файлами.
2. Правила. Корневой файл памяти, который агент читает в начале каждой сессии.
3. Скиллы. Библиотека процедур, по которым агент выполняет повторяющиеся задачи.
4. Интерфейсы. Чат в редакторе, дашборды, бот в Telegram.
5. Права. Роли участников и правила, по которым материал попадает в основную ветку.
6. Ритуалы. Регулярные действия, которые наполняют и чистят базу.

Нумерация с шагом в десять оставляет воздух. Между 20 и 30 всегда влезет новое направление, и переименовывать весь ряд не придется.

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

В каждой папке лежит свой маленький README. Он работает как маршрут для агента. Тот читает корневой файл, понимает общую структуру, проваливается в нужное направление, читает файл там и идет дальше. Такой лесенкой агент доходит до нужного документа, не перечитывая соседние папки и не сжигая на этом токены.

---

Права и доступы в командной базе

Это та часть, из-за которой командная база живет или превращается в кашу через две недели. Если выдать всем участникам одинаковые права, произойдет предсказуемое. Люди начнут писать в главную ветку одновременно, изменения станут конфликтовать, и через месяц никто не сможет сказать, какая версия гайдлайна настоящая.

Основа архитектуры Team OS выглядит так. Один общий репозиторий, разные права доступа внутри и обязательное ревью перед тем, как изменение попадет в основную ветку.

Четыре уровня доступа

Названия ролей в GitHub и GitLab отличаются, смысл одинаковый.

Роль	Кто это	Что может
Владелец репозитория	Один человек, максимум двое	Все функции целиком, настройка прав, структура, удаление
Владелец направления	Руководитель группы или отдела	Ревьюит и мержит изменения в своей зоне, отвечает за содержимое
Участник	Специалисты команды	Читает базу, создает ветки, отправляет merge request
Гость	Стажер, подрядчик, новичок на испытательном	Видит ограниченный набор материалов, заводит задачи на себя

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

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

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

Ветки и merge request простыми словами

Термины из мира разработки пугают, механика за ними простая.

Основная ветка называется main. Это текущее состояние базы, то, что видит вся команда. Ветка это копия базы с вашими изменениями, которая пока живет отдельно и никому не мешает. Merge request дословно означает запрос на слияние, то есть просьбу перенести ваши изменения в main. В GitHub он называется pull request, смысл тот же.

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

Команды агенту звучат словами. Заведи ветку под гайдлайн по презентациям. Сделай merge request. Технику агент выполняет сам.

Живой пример. Специалист поресерчил и понял, что для регулярной задачи получается собрать быстрый процесс. Раньше это делалось руками: искали авторов в одном месте, заводили карточку в другом, создавали шаблон, заполняли его. Специалист собирает скилл, тестирует его на трех своих задачах, видит, что работает, и говорит агенту сделать merge request.

Руководителю направления приходит уведомление. Такой-то человек протестировал скилл, вот на каких задачах, вот сколько времени экономит. Ответственный раз в какое-то время приходит, смотрит накопившиеся запросы, при необходимости задает вопросы, тестирует сам и мержит в основную ветку. С этого момента протестированный скилл становится достоянием всей команды.

---

Что кладем в базу и чего не кладем

Хороший признак материала для общей базы простой. Один и тот же вопрос задают повторно. Джуниор третий раз спрашивает, как оформляется бриф. Значит, ответ пора положить в базу, и он же станет основой для онбординга следующего человека.

Общий знаменатель у всего списка один, это повторяется. Разовое сюда не кладут.

Обратная сторона важнее. В общий репозиторий не уезжают пароли, токены и ключи доступа. Не уезжают персональные данные сотрудников и клиентов, здесь работает 152-ФЗ и внутренние регламенты. Не уезжает финансовая и коммерческая информация, закрытая NDA. Секреты живут в отдельном хранилище компании, а база хранит описание, кто и как получает к ним доступ.

Отдельная ошибка выглядит безобидно. В базу сливают весь контекст подряд, лишь бы он был. Черновики, которые никому не понадобятся, обсуждения давно закрытых тем, дубли одного документа в трех версиях. Кроме того, что это замусоривает поиск, агент начинает читать лишнее и тратить на это токены. В базу попадает то, к чему команда вернется.

---

Скиллы как главная ценность командной базы

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

Скилл становится чем-то вроде попугая на плече у пирата. Он не заменяет специалиста и никого не увольняет. Он сидит рядом, подсказывает и часть работы делает сам.

Библиотека накапливается сама из удачных сессий. Через полгода она становится внутренним продуктом команды.

Часть скиллов можно взять готовыми, их выкладывают в открытых репозиториях, и я собирал подборку рабочих наборов. Любой готовый скилл дообучается под вас: берете его как основу, даете фидбек по результату, рассказываете, чем сделанное отличается от того, как эту работу делают у вас. Скилл запоминает и дальше работает по вашим правилам.

Как скилл попадает в общую библиотеку

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

1. Автор замечает повторяемость. Задача делается руками третий раз, ее пора описать.
2. Собирает скилл и тестирует. Обязательно на нескольких реальных задачах.
3. Отправляет merge request. В описании то, на каких кейсах проверял и что скилл экономит.
4. Владелец направления ревьюит. Смотрит, задает вопросы, прогоняет на своей задаче.
5. Мержит и анонсирует. Команда узнает, что в библиотеке появился новый специалист.

---

Встречи как топливо для базы

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

Цепочка выглядит так. Встречу записывают, запись расшифровывается в текст, агент разбирает транскрипт по заданному промпту и раскладывает результат по базе. Часть уходит в протокол встречи, часть дополняет базу знаний конкретного проекта, часть становится карточкой человека или партнера. Иногда из такого разбора вырастает целый скилл, особенно когда на созвоне обсуждали процесс.

Расшифровка стоит ноль, если пользоваться локальной моделью распознавания речи. Отдельно этот же прием разобран в гайде про разбор рабочих чатов.

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

Дальше из этого же материала собирается еженедельная сводка изменений по базе. Механика сборки такой сводки разобрана в гайде про дайджест с AI-агентом, для команды он делается тем же способом.

---

Онбординг как первая точка входа

Онбординг снимает больше всего головной боли, поэтому он же становится удобной точкой входа для всей системы. Новый человек приходит в команду, и вместо недели дерганья коллег его за руку проводит агент.

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

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

---

Поиск и подключение внешних сервисов

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

Лечится это семантическим поиском с векторизацией. Агент получает задачу проиндексировать базу и проставлять в шапке каждого нового файла теги. После этого поиск идет по смыслу и тегам скриптом, вместо чтения всех документов подряд. Ответы становятся точнее, а расход контекста заметно ниже.

Второй слой это коннекторы. MCP работает мостиком между агентом и внешними сервисами: таблицами, календарями, трекерами задач, внутренними системами компании. Через них база подтягивает то, что регулярно обновляется, и агент остается в курсе без ручного переноса данных.

---

Ритуалы, без которых база умирает

Я знаю несколько команд, у которых такой подход прижился и продержался долго. И знаю заметно больше тех, у кого он не пошел. Разница между ними в ритуалах.

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

Ритуал	Частота	Кто отвечает
Дежурный по карточке на встрече	Каждая встреча	Переходящая роль внутри группы
Дайджест изменений по базе	Раз в неделю	Владелец репозитория
Разбор запросов на слияние	Раз в неделю	Владельцы направлений
Аудит скиллов и правил	Раз в месяц	Небольшая группа стратегов
Ревью доступов	Раз в квартал	Владелец репозитория

Аудит нужен, потому что часть материала отмирает. Какими-то скиллами перестают пользоваться, какие-то правила устарели вместе с процессом. Небольшая группа людей раз в месяц смотрит на базу стратегически: какие изменения были последними, какие рабочие группы принесли новые скиллы, пользуются ли ими. Если скилл перестали брать, стоит спросить почему. Сначала было полезно, теперь нет, значит, его пора либо доработать, либо убрать.

Ревью доступов делают редко и обычно оно ничего не находит. Но иногда выясняется, что доступ случайно достался стажеру или остался у человека, который давно ушел из отдела. Ошибки такого рода допускают все, поэтому раз в квартал список просматривают глазами.

---

Запуск за четыре недели

Быстрым этот процесс не бывает. Разделение по неделям у всех получается свое, ориентир выглядит так.

Каркас на первой неделе

• Договориться о структуре: какие направления, какие проекты внутри системы.
• Распределить роли и выставить права в репозитории. Здесь удобно позвать технического специалиста.
• Написать корневой файл памяти и файл с доступами.
• Положить README в каждую папку, чтобы у агента появился маршрут.

Первый контекст на второй и третьей неделе

• Подключить рабочие группы, посмотреть, что им важно обсуждать и хранить.
• Залить первые материалы: шаблоны, чек-листы, гайдлайны, tone of voice.
• Начать сливать транскрипты созвонов и разбирать их на карточки.
• Собрать и протестировать первые скиллы, провести их через ревью.

Ритм с четвертой недели

• Запустить еженедельный дайджест и разбор запросов на слияние.
• Прогнать через базу первого новичка по протоколу онбординга.
• Снять первые метрики и посмотреть, что работает.

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

---

Как понять, что система работает

Пользу видно примерно через месяц регулярного использования. Мерить можно по четырем признакам.

• К эксперту стали обращаться реже. Самый честный показатель. Если конкретного человека перестали дергать одними и теми же вопросами, база отвечает вместо него.
• Онбординг стал проще. Меньше вопросов от новичка, быстрее выход на задачи, есть результат прохождения в файле.
• Запросы на слияние приходят от всей команды. Пока их шлют только владельцы направлений, инициативы нет. Когда изменения предлагают рядовые участники, система стала общей.
• Библиотека скиллов растет. Новые скиллы появляются сами, из удачных сессий и разборов встреч.

---

Пять ошибок, на которых команды спотыкаются

Ошибка	Чем оборачивается	Что делать
Сливают в базу все подряд	Поиск замусорен, агент читает лишнее и жжет токены	Класть только то, к чему команда вернется
Роли не разграничены, все пишут в main	Конфликты изменений, непонятно, какая версия настоящая	Выставить четыре уровня прав и запретить прямую запись в main
У направлений нет ответственных	Никто не ревьюит, база стоит без движения	Назначить владельца на каждое направление
Секреты лежат в репозитории	Ключи утекают вместе с историей изменений	Хранить секреты отдельно, в базе только описание доступа
Непротестированный скилл в библиотеке	Плохой результат у следующего человека, недоверие ко всей базе	Тестировать на нескольких реальных задачах до merge request

Шестая ошибка стоит отдельно, потому что она случается до всех остальных. Команда начинает строить корпоративную систему, ни разу не собрав личную. Получается красивая структура, в которую никто не верит, потому что никто внутри не пережил момент, когда агент впервые ответил по твоим же материалам и сэкономил вечер. Сначала личные базы у нескольких человек, потом общая.

---

Частые вопросы

Что такое командная база знаний на AI-агенте?

Это общий репозиторий команды с текстовыми файлами, к которому подключен AI-агент. Внутри лежат знания отделов, шаблоны, гайдлайны, договоренности и библиотека скиллов. Любой участник открывает базу у себя и спрашивает словами, агент находит ответ по материалам команды и работает по общим правилам. Отличие от личного второго мозга в том, что добавляются права доступа, ревью изменений и ответственные за содержимое.

Чем командная база знаний отличается от Confluence или Notion?

В обычной базе знаний человек ищет страницу сам и часто до нее не доходит, поэтому идет с вопросом к коллеге. Здесь вход один, это чат с агентом, который читает материалы команды и отвечает по ним. Второе отличие в том, что рядом с текстами живут скиллы, поэтому агент не только рассказывает, как делается задача, но и делает ее по вашим гайдлайнам. Третье в том, что репозиторий дает версии, ветки и ревью, поэтому у каждого изменения есть автор и тот, кто его принял.

Где хранить командную базу знаний, на GitHub или GitLab?

Подходит любая система контроля версий с приватными репозиториями и настраиваемыми правами, чаще всего это GitHub или GitLab. Выбор обычно диктует то, что уже стоит у команды и с чем работает технический отдел. Механика везде одинаковая, это ветки, запрос на слияние и ревью перед тем, как изменение попадет в основную ветку. В GitHub такой запрос называется pull request, в GitLab merge request.

Как разграничить права доступа в командной базе знаний?

Уровней обычно четыре. Владелец репозитория, один или два человека, настраивает права и отвечает за систему целиком. Владельцы направлений ревьюят и принимают изменения в своей зоне. Участники читают базу и предлагают изменения через отдельную ветку и merge request. Гости и стажеры видят ограниченный набор материалов и заводят задачи на себя. Если выдать всем одинаковые права, изменения польются в главную ветку без проверки и база быстро превратится в свалку.

Кто должен отвечать за командную базу знаний?

Владелец репозитория, один человек или двое, отвечает за систему целиком и за настройку прав. Дальше по владельцу на каждое направление, они ревьюят изменения и следят за содержимым своей зоны. Хорошо, если это те же люди, которые уже собрали личный второй мозг. Они понимают ценность и объясняют ее команде на своем опыте.

Что нельзя хранить в командной базе знаний?

Пароли, токены и ключи доступа. Персональные данные сотрудников и клиентов, здесь работает 152-ФЗ. Финансовую и коммерческую информацию, закрытую внутренним регламентом или NDA. Черновой контекст, к которому никто не вернется. Секреты живут в отдельном хранилище компании, а база хранит описание, кто и как получает к ним доступ.

Сколько времени занимает запуск командной базы знаний?

Рабочий каркас собирается примерно за четыре недели. Первая неделя на архитектуру, роли и структуру. Вторая и третья на первый контекст, рабочие группы и первые скиллы. Четвертая на ритуалы и замеры. Пользу видно примерно через месяц регулярного использования, дальше система растет сама, если у нее есть ответственные и еженедельный ритм.

Можно ли начать сразу с командной базы, минуя личную?

Технически можно, на практике так почти не взлетает. Внутри команды сначала нужны несколько человек, которые собрали личный второй мозг и увидели пользу. Именно они становятся владельцами направлений и объясняют остальным, зачем тратить время на карточки и скиллы. Команды, которые начинали с корпоративного внедрения без такого ядра, обычно останавливались на этапе красивой структуры без содержимого.

Нужно ли программировать, чтобы это собрать?

Нет. Структуру папок, файлы памяти и скиллы агент создает сам по вашему описанию словами. Единственное место, где пригодится технический человек, это настройка прав в репозитории, и она делается один раз за пару часов. Дальше команда работает с базой через чат.