Claude Concilium: code review без ложного консенсуса

Два AI-reviewer могут удвоить уверенность, не добавив ни одного доказательства.

Это главный риск multi-model code review. Вторая модель действительно расширяет поиск: одна может проследить конкурентный доступ, другая — проверить авторизацию или совместимость. Но если обе получают один расплывчатый prompt, а затем голосуют, общая ошибка превращается в убедительный консенсус.

Claude Concilium полезен как небольшой набор адаптеров для Claude Code. Но это не oracle. Ниже я отделяю фактическое устройство репозитория от процесса review, который всё равно придётся спроектировать.

Что находится в репозитории

Я проверил публичный репозиторий на commit 970eef6 от 2 марта 2026 года. В исходниках три Node.js stdio MCP-сервера:

Claude Code
├── mcp-openai  → codex exec / codex review
├── mcp-gemini  → gemini -p
└── mcp-qwen    → qwen -p -

Вместе они публикуют пять tools:

Кроме них есть инструкции по настройке, пример MCP-конфигурации, Dockerfile, smoke test и skill ai-concilium. Кода немного — его реально прочитать до установки.

Здесь важны три уточнения.

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

Во-вторых, fallback не встроен в серверы. Файл skill предлагает host-agent вызвать Qwen, а затем DeepSeek после некоторых ошибок. Каждый сервер знает только своего провайдера.

В-третьих, DeepSeek не является четвёртым сервером этого репозитория. Пример конфигурации запускает отдельный npm-пакет через npx -y. Это отдельная dependency и отдельное решение о доверии.

Что на самом деле проверяет smoke test

Я установил заявленные dependencies во временный clone с отключёнными lifecycle scripts и выполнил:

node test/smoke-test.mjs

Все три сервера прошли MCP initialization и вернули списки tools. Для проверенного commit это подтверждает базовое protocol wiring.

Исходник test специально не вызывает provider CLI. Поэтому успешный результат не подтверждает, что:

• codex, gemini или qwen установлен;
• авторизация действует;
• нужная модель доступна аккаунту;
• распознавание quota errors соответствует текущему выводу CLI;
• провайдер видит нужный repository;
• замечания review корректны.

Для каждого включённого сервера нужен provider-level canary. Используйте безвредный fixture repository, попросите сообщить детерминированный факт об одном файле и проверьте working directory, timeout и обработку ошибки.

Поведение исходного кода и риски

OpenAI-адаптер передаёт prompt через stdin в codex exec, запрашивает ephemeral session и устанавливает read-only sandbox. Это разумный default. Текущая документация Codex подтверждает, что codex exec поддерживает неинтерактивный запуск и чтение prompt из stdin (CLI reference).

Qwen-адаптер также передаёт prompt через stdin. А Gemini-адаптер помещает весь prompt в аргумент командной строки. В некоторых операционных системах аргументы процесса видны другим локальным процессам или диагностическим инструментам. Не отправляйте в review prompts секреты, клиентские записи, access tokens и необработанные production data.

Все три сервера наследуют environment родительского процесса. Не храните credentials в project .env, который может прочитать дочерний CLI. Передавайте только необходимые переменные и запускайте адаптеры от пользователя с минимальными правами.

Есть ещё два эксплуатационных ограничения:

• ошибки классифицируются по фрагментам текста в CLI output, а формулировки провайдеров меняются;
• ненулевой exit code дочернего процесса не всегда считается ошибкой, если stdout непустой.

Это не повод списывать проект. Но returned status и доказательства нужно проверять, а оба пункта стоит исправить в собственном fork.

Как и у любого production MCP server, сам протокол не делает tool доверенным. Спецификация рекомендует host показывать inputs, запрашивать согласие пользователя, задавать timeouts и проверять результаты перед передачей модели (MCP tools: security considerations).

Устанавливайте как проверенный код

Не передавайте install script прямо в shell и не копируйте unpinned config из статьи. Начните с commit, который вы просмотрели:

git clone https://github.com/spyrae/claude-concilium.git
cd claude-concilium
git checkout 970eef6bb5c2267f10a16229cba161e154fd6221

git show --stat
find servers -maxdepth 2 -type f -print

Затем проверьте:

1. каждый server.js;
2. каждый package.json;
3. config/mcp.json.example;
4. skill, который решает, когда вызвать другого провайдера;
5. mounts с credentials и environment variables.

В проверенном commit нет lockfiles, поэтому npm install может разрешить более новые transitive versions, чем проверял автор. Если вы собираетесь пользоваться проектом регулярно, создайте и проверьте lockfiles в своём fork. Не добавляйте npx -y deepseek-mcp-server только ради полного совпадения с sample config: сначала отдельно зафиксируйте и изучите этот пакет.

Авторизуйте провайдеров по их текущим официальным инструкциям. Codex поддерживает вход через ChatGPT и API key, причём billing и data policies различаются (OpenAI authentication). У Gemini способ авторизации также определяет quota, pricing, terms и privacy (Gemini CLI authentication). Проверяйте эти страницы во время установки, а не переносите число запросов из старой статьи в постоянный config.

Используйте абсолютный working directory. Дайте reviewer read-only доступ только к нужной части repository. .env, production dumps, private keys и customer exports должны оставаться за пределами этой области.

Протокол review без голосования

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

1. Зафиксируйте baseline

До первого model call запустите детерминированные проверки проекта:

targeted tests
type checking
lint/static analysis
dependency или secret scan, когда это уместно

Запишите существующие failures. Reviewer не должен приписывать старый red новой правке.

2. Определите contract и риск

Передайте:

• ожидаемое поведение;
• точный diff или диапазон commits;
• релевантные interfaces и invariants;
• поддерживаемые платформы и требования совместимости;
• уже выполненные команды;
• файлы вне scope.

Не отправляйте весь monorepo лишь потому, что модель принимает большой context. Лишний материал создаёт шум и раскрывает больше данных.

3. Сохраните независимость первых проходов

Не показывайте reviewer B ответ reviewer A. Дайте им разные и конкретные задачи:

Reviewer A — correctness и concurrency:
Проследи изменённый control flow. Найди достижимый failure в state,
ordering, cancellation, retries или cleanup.

Reviewer B — security и boundary contracts:
Проверь authorization, trust boundaries входных данных, data exposure,
поведение dependencies и backward compatibility.

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

Исследования multi-agent debate дают смешанные результаты. В benchmark на ICML 2024 debate protocols без точной настройки не превосходили стабильно более простые prompting strategies (Smit et al.). Поэтому цель процесса — не консенсус.

4. Требуйте карточку замечания

Попросите каждого reviewer вернуть только проверяемые findings:

Для каждого finding:
- severity;
- file и line;
- нарушенный contract или threat;
- конкретный execution path;
- минимальный reproduction или test;
- uncertainty и недостающий context.

Не возвращай APPROVE только по впечатлению.
Не предлагай style changes, если они не скрывают defect.

Замечание без code path или проверяемого утверждения относится к вопросам, а не к багам.

5. Уберите дубликаты и проверьте

Группируйте findings по root cause, а не по формулировке. Две модели способны пересказать одну неверную мысль разными словами.

Для каждого существенного finding получите хотя бы одно подтверждение:

• failing regression test;
• результат static analysis;
• минимальное воспроизведение;
• требование protocol или framework из первичной документации;
• trace по реальному коду и переходам состояния.

Если проверить утверждение в рамках review budget нельзя, пометьте его как unresolved. Не превращайте совпадение мнений в severity.

6. Оставьте решение человеку

Автор или reviewer решает: исправить, отклонить, отложить или расследовать. Запишите основание. AI synthesis может упорядочить evidence, но не должен молча одобрять merge или ослаблять test.

Для финального прохода используйте чек-лист AI code review, а для доступа адаптеров к private repositories — меры из гайда по безопасности MCP.

Prompt, который требует доказательств

Проверь commit <sha> относительно этого contract:
<approved behavior и invariants>

Scope:
<files и diff>

Твоя зона:
только correctness, concurrency, cancellation и cleanup.

Baseline:
<commands и results>

Возвращай finding, только если можешь указать:
1. severity;
2. file:line;
3. достижимый execution path;
4. expected и actual behavior;
5. минимальный test или reproduction.

Недостающий context перечисли отдельно. Не делай вывод об уверенности
из мнения другого reviewer. Не редактируй файлы.

После двух независимых проходов передайте verification pass дедуплицированные claims, а не убедительную прозу.

Измерьте пользу второй модели

Не публикуйте catch rate по нескольким запомнившимся review. Соберите небольшой evaluation set из собственной разработки:

• ранее исправленные defects с известным root cause;
• чистые diffs, где findings быть не должно;
• seeded variants ошибок boundary, authorization, cleanup и concurrency;
• достаточно крупные changes для проверки context handling.

Сравните один и несколько reviewers по метрикам:

• найденные и подтверждённые defects;
• новые подтверждённые defects от второго reviewer;
• false positives;
• время проверки;
• latency и provider usage;
• нарушения политики sensitive data.

На время сравнения зафиксируйте prompts и commits. Повторяйте проверку после обновления model, CLI или adapter. Если второй reviewer приносит в основном дубликаты и непроверяемые замечания, исключите его для такого класса changes.

Multi-model review полезнее для рискованных diffs с несколькими независимыми failure surfaces. Для опечатки, механического rename или однострочной правки с хорошими tests целевые проверки и один дисциплинированный review обычно дешевле и понятнее.

Вывод

Claude Concilium — компактный и доступный для аудита мост от Claude Code к трём provider CLI. В проверенном commit это не автоматическая fallback-система, а согласие моделей не доказывает корректность.

Используйте проект, чтобы расширить поиск. Сохраняйте независимость reviewers, ограничивайте доступ, требуйте воспроизводимые доказательства и завершайте review тестами и человеческим решением, а не голосованием.