AI Council и agent-memory-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.

agent-memory-mcp — один Go-бинарник, который работает и как MCP-сервер, и как CLI. Он даёт агенту три вещи: типизированную долговременную память в SQLite, RAG-поиск по документам репозитория (docs, ADR, RFC, changelog, runbook, postmortem, CI, Helm, Terraform, K8s) и слой обслуживания знаний — консолидацию сессий, стюард-сканы, верификацию, канонический слой, временную модель и граф знаний. 50 MCP-инструментов, при группировке — 8; три хука Claude Code; сессионный трекер; два SQLite-файла и ноль внешних БД. MIT.

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

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

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

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

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

5. Платформа

Вывод

agent-memory-mcp — самый близкий к слою знаний Council из сравнённых проектов. У него есть то, чего нет у большинства локальных инструментов: доверие, канонический слой с provenance-гейтом, очередь ревью, стюард со сканерами и inbox, drift scan, верификация, временная валидность, осаждение и граф знаний. Но он не понимает код: графа символов нет, RAG читает документацию и конфиги, конвенций и ревью диффа нет, задач на VM и команды нет.

Где сильнее agent-memory-mcp:

• банк знаний проекта с инженерными типами, trust-метаданными, каноническим слоем и project bank;
• очередь ревью как записи памяти, а не отдельная таблица; resolve_review_item и steward_inbox_resolve;
• стюард: дубликаты, конфликты, структурные противоречия, stale, expired working, canonical health, drift, verification candidates;
• временная модель: valid_from/valid_until, superseded_by, replaces, recall_as_of, knowledge_timeline;
• осаждение surface → episodic → semantic → character;
• граф триплов и multihop recall;
• консолидация сессии extract → plan → apply без LLM-переписывания, с Jaccard-дедупом и review-гейтом;
• RAG по документам и конфигам: semantic + BM25, weighted fusion/RRF, per-document cap, ExpandSection, source-aware бусты;
• 50 MCP-инструментов и групповой режим 8;
• три хука Claude Code и session tracker;
• local-first два SQLite-файла, Go-бинарник, MIT;
• измеренные дефолты и 692 теста.

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

• понимает код, а не только текст о нём. Граф L0–L10: стек, структура, зависимости и циклы, вызовы, данные, архитектура и запрещённые зависимости, паттерны, стиль, DDD, co-change, смеллы, ISO 25010 и диаграммы. Статический анализ модель не вызывает и не тратит токены; agent-memory читает документы и конфиги, но не строит граф символов и не видит архитектуру.
• знания привязаны к позиции в коде и к ветке. Запись живёт на ветке, приходит агенту, когда он трогает нужный файл, а когда код под ней меняется — уходит на перепроверку: ревьюер обязан привести цитату, итог — пометка. При слиянии веток запись переезжает; merge_knowledge/supersede_knowledge сохраняют историю. У agent-memory есть trust-метаданные и temporal validity, но привязки к позиции в коде и проверки против кода нет.
• конвенции — авторитетные правила, а не наблюдённые нормы. Три области: сущности кода, пути (включая ещё не созданный файл) и весь проект; MUST/SHOULD, состояния «черновик», «отставлено», «удалено»; проверка перед правкой и по диффу. Хуки доставляют правила к каждому сообщению, контекст файла — на Read/Edit/Bash, а гейт «сначала база» не даёт агенту читать код, пока он не спросил базу. Это enforcement, а не запись в bank.
• ревью кода и знаний — отдельный сервис. По каждому файлу — вердикт, второй проход, публикация в MR без дублей; ревью знаний проверяет утверждение против AST-позиции, требует дословную цитату и ведёт журнал/калибровку. У agent-memory есть очередь ревью записей, но нет ревью диффа и публикации в MR.
• задача живёт на VM в sysbox-контейнере. Дни, человек ведёт из веб-интерфейса: анализ → дифф → коммит → push → MR; одноразовые креды на push, изоляция, RBAC и защита от SSRF. agent-memory — локальный банк знаний, задач и рабочего пространства у него нет.
• платформа вокруг кода. Тикеты Jira/GitHub/Redmine с разбором в знания и советом по графу; трассировка тестов к требованиям; компании → участники → роли (в т.ч. на проект) → права; лицензия и места; self-hosted/офлайн или SaaS. Этого слоя у agent-memory нет.
• общий граф на несколько репозиториев и история архитектуры. architecture_as_of показывает архитектуру на дату, рёбра версионируются после каждого прогона; SonarQube забирается как внешний анализатор. agent-memory хранит знания, но не архитектуру проекта.
• наблюдаемость и самовосстановление. Телеметрия каждого вызова MCP и хука без PII, повторный поиск агента виден как сигнал плохого первого ответа; около 22 правил Prometheus с тестами, System Health, трассировка; сверка Temporal с базой, уборка осиротевших данных, ночной бэкап с проверкой восстановления и ретенция. Для локального банка знаний это не нужно; для командной платформы — обязательный слой.
• модель не лежит ключом в стеке. Статический анализ идёт без модели; ревью, ревью знаний, AI-чат и рабочее пространство — через хостовый воркер, бридж и вендорский CLI/OAuth. Это не «работа без модели»: без модели остаётся только статический анализ, но ключ и квоты не хранятся в Council.

Могут ли работать вместе. Да, и это разные слои. agent-memory-mcp — банк знаний проекта и RAG по документам для агента; Council — граф кода, конвенции, ревью и задачи. Оба являются MCP-серверами, поэтому один агент может подключить оба. Пересечение — знания и очередь ревью: agent-memory хранит решения, runbook'и и уроки сессий, Council — знания, привязанные к позициям в коде, и правила команды. Автоматической интеграции нет; практическая связка — agent-memory для «что мы знаем и что обсудили», Council для «где это в коде, какие правила действуют и что говорит ревью». Дублировать очередь ревью в двух системах не стоит: у каждой должен быть свой предмет.