AI Council и TeaRAGs-MCP: что умеет каждый

Коротко

AI Council — self-hosted платформа для команды разработчиков. Она сама разбирает репозитории в граф кода: стек, структуру, зависимости и циклы, вызовы, данные, архитектуру, DDD, паттерны, стиль, смеллы и качество по ISO 25010. Над графом лежит база знаний проекта — решения, заметки, диаграммы и журналы изменений; каждая запись привязана к месту в коде и к ветке и приходит агенту, когда он трогает нужный файл. Отдельно живут конвенции: правила трёх областей — к сущностям кода, к путям и ко всему проекту — с уровнями MUST/SHOULD, состояниями и проверкой перед правкой и по диффу. Вокруг этого собраны ревью с публикацией в MR, тикеты, задачи и компании с ролями и лицензией. Статический анализ кода модель не использует, но без модели остаётся только он: ревью, ревью знаний, AI-чат и рабочие пространства идут через хостовый воркер, бридж и вендорский CLI/OAuth. Модель живёт на хосте, а не в стеке Council.

Работать с Council можно двумя способами. На машине разработчика Claude Code подключается к нему через MCP и хуки: правила проекта приходят к каждому сообщению, контекст файла — на Read/Edit/Bash, а в конце — чек-лист. В рабочем пространстве задача идёт на VM в изолированном sysbox-контейнере, живёт днями и ведётся человеком из веб-интерфейса: от анализа и диффа до коммита, push и MR.

TeaRAGs — локальный MCP-сервер «Codebase Intelligence» для AI-агентов. Он индексирует репозиторий на машине пользователя и отвечает не «похожими строками», а досье на код по пяти слоям: что делает (семантика и гибридный поиск по AST-чанкам в Qdrant), как связано (граф вызовов и импортов в DuckDB), как жило (git-траектория: churn, bug-fix rate, ownership, возраст), правильно ли разложено (архитектурные детекторы: стабильные зависимости, утечки через фасады, молчаливая связанность, shotgun surgery, main sequence) и как проект называет вещи (лексикон имён и вердикты на новые имена). Есть review_changes — ревью диффа по пяти секциям, фоновый auto-update, working-tree delta и плагин Claude Code с навыками и правилами. Лицензия MIT.

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

1. Понимание кода

2. Знания и правила

3. Требования и задачи

4. Проверка и модели

5. Платформа

Вывод

TeaRAGs — самый близкий к Council по функциям из сравнённых проектов. Он тоже строит граф, читает git-историю, судит архитектуру, проверяет имена и ревьюит изменение. Но он локальный и не держит то, что Council держит над графом: базу знаний о решениях, авторитетные конвенции, ревью-сервис с публикацией в MR, задачи на VM и команду с правами.

Где сильнее TeaRAGs:

• пять слоёв в одном локальном сервере — ценность в связке, а не в числе: семантика, codegraph, git, архитектура, лексикон (каждый — прагматичный сигнал, не обязательно лучший в классе);
• архитектурные детекторы, которых у Council нет в явном виде: проверка SDP, silent coupling, shotgun surgery как отдельная метрика, role-pair norms и what-if restructure; у Council есть метрики Мартина (instability, abstractness, distance from main sequence), детекторы циклов, нарушений слоёв, god/hub-компонентов и scattered_functionality по co-change, но не эти конкретные детекторы и не пересчёт метрик на виртуальном графе;
• review_changes: дифф-скоупные детекторы, preExisting, remedy, гейт introduced=0, partial=false;
• лексикон имён и ontology report — вердикты на новые имена, которых не видит ни типизация, ни тесты;
• temporal co-change с нулевой гипотезой и поправкой на множественные сравнения;
• чтение working tree по базовому индексу + дельте, без переиндексации;
• SearchConfidence, пресеты и реранкер;
• компактная поверхность для агента: 28 MCP-инструментов, 9 ресурсов (два по коллекциям Qdrant и семь справочников tea-rags://schema/*), prime с живым состоянием индекса на старте сессии и search cascade как политика выбора инструмента; у Council 61 инструмент и шире охват, а MCP-ресурсов и отдельного prime-дайджеста нет — справочник живёт в схемах инструментов, skill и хуках, а выбор «сначала база, потом код» enforced гейтом;
• MIT, локальность, Ollama по умолчанию.

Где сильнее Council:

• знания привязаны к коду и веткам, а не только к индексу. Запись живёт на ветке, приходит агенту при касании файла, уходит на перепроверку при изменении кода под ней; ревьюер обязан привести цитату, итог — пометка, при слиянии веток запись переезжает. TeaRAGs строит отчёт об архитектуре и лексикон, но базы знаний о решениях и причинах у него нет.
• конвенции — авторитетные правила, а не наблюдённые нормы. Три области (сущности, пути, включая ещё не созданный файл, проект), MUST/SHOULD, состояния «черновик/отставлено/удалено», проверка перед правкой и по диффу; хуки доставляют правила к каждому сообщению и контекст файла на Read/Edit/Bash; гейт «сначала база» блокирует чтение кода до обращения к базе. У TeaRAGs role-pair norms и лексикон наблюдённые, редактировать их как правило нельзя.
• ревью кода и знаний — сервис, а не локальный гейт. Вердикт по каждому файлу, второй проход, публикация в MR без дублей (GitHub/GitLab/Bitbucket); отдельное ревью знаний проверяет утверждение против AST-позиции, требует дословную цитату и ведёт журнал/калибровку. review_changes TeaRAGs — детерминированный предкоммитный гейт в одном репозитории, без MR и без знаний.
• задачи на VM, тикеты, MR, команда. Задача в sysbox-контейнере живёт дни, человек ведёт из UI: анализ → дифф → коммит → push → MR; тикеты Jira/GitHub/Redmine с разбором в знания; компании → участники → роли (в т.ч. на проект) → права, лицензия и места. TeaRAGs — локальный сервер для одного пользователя, без задач, ролей и лицензии.
• шире слои качества и истории. DDD bounded contexts, паттерны, стиль, смеллы, ISO 25010, SonarQube, architecture_as_of и версионирование рёбер; TeaRAGs сильнее в отдельных архитектурных детекторах (SDP, silent coupling, shotgun surgery, norms, what-if), но не в этих слоях.
• общий граф на несколько репозиториев. Один проект может включать несколько репозиториев с общим графом; ask_question отдаёт выдержки с FQN, а не пересказ моделью. TeaRAGs держит реестр проектов и коллекцию на проект, общего графа между репозиториями нет.
• наблюдаемость и самовосстановление платформы. Телеметрия каждого вызова MCP и хука без PII, повторный поиск агента как сигнал, около 22 правил Prometheus, System Health, трассировка; сверка Temporal с базой, уборка осиротевших данных, бэкап с проверкой восстановления, ретенция. У TeaRAGs есть drift-мониторы и get_index_metrics, но не per-call наблюдаемость и не самовосстановление платформы.
• модель не лежит ключом в стеке. Статический анализ идёт без модели; ревью, ревью знаний, AI-чат и рабочее пространство — через хостовый воркер, бридж и вендорский CLI/OAuth. TeaRAGs использует локальные эмбеддинги Ollama и детерминированное ревью; это его сильная сторона по локальности, но глубокое ревью с моделью и публикацией в MR — ось Council.

Могут ли работать вместе. Да, и это разные слои. TeaRAGs даёт локальное досье на код и детерминированный предкоммитный гейт; Council — знания, правила, ревью с моделью и публикацией в MR, задачи и команду. Оба — MCP-серверы, один агент может подключить оба. Пересечение — архитектура и ревью: TeaRAGs судит введённые рёбра и имена детерминированно, Council ревьюит изменение моделью и публикует находки. Разумная связка: TeaRAGs — быстрый предфильтр перед коммитом, Council — глубокое ревью и знания. Автоматической интеграции нет.