CodeAlive работает в продакшене с апреля 2025 года. Все это время мы были так увлечены продуктом, что просто не могли оторваться, чтобы поделиться с вами деталями о том, как мы его создаем и развиваем. Исправляемся.
Начинаем с CodeAlive 3.0. В этом релизе мы довели до стабильного состояния context engine, добавили собственного агента для исследования кода и RepoContextBench для объективной оценки качества, а также полностью переработали Tool API и MCP.
Что изменилось в context engine
Первые версии CodeAlive находили нужный контекст в репозитории, который целиком не помещается в промпт LLM.
В продакшене быстро выяснилось, сколько деталей скрывается за этой формулировкой. В одном репозитории могут быть смешаны несколько языков, сгенерированный код забивает выдачу, символы переезжают, провайдеры падают, а долгую обработку иногда приходится продолжать с середины. Последний год мы разбирались именно с такими случаями.
Сейчас CodeAlive строит несколько представлений репозитория:
- символы и их исходный код;
- Repository Ontology для ориентации;
- связи вызовов, ссылок и наследования;
- семантический и точный текстовый индексы;
- короткие описания того, что делает каждый артефакт.
Repository Processing работает инкрементально. Каждый этап можно повторить отдельно, не запуская весь процесс заново. Поиск сочетает семантический и точный подходы. Перед ответом агент может посмотреть карту репозитория, найти нужный символ, проверить его связи и прочитать исходный код.
За год мы увидели достаточно реальных сбоев, чтобы перестать полагаться на идеальный сценарий. Поэтому в продукте появились нормальное восстановление после ошибок, дополнительные тесты, телеметрия и инструменты для эксплуатации.
Собственный агент для исследования кода
Этой весной в CodeAlive появился ContextResearchAgent. Это read-only-агент, который отвечает на вопросы о коде.
Он работает с обработанным репозиторием, а не с рабочей копией через шелл. Его цикл исследования простой:
- Сориентироваться по Repository Ontology или ограниченному дереву файлов.
- Найти нужный код семантическим и точным поиском.
- Пройти по вызовам, ссылкам и наследованию.
- Прочитать исходники, которые пойдут в ответ.
Базовый цикл мы собрали быстро. Больше времени ушло на то, чтобы агент предсказуемо работал в продакшене. Мы ограничили количество итераций, вызовов инструментов и общее время работы. Агент замечает повторяющиеся вызовы и сжимает длинные трейсы исследования. Если запрос составлен неверно, инструмент объясняет, что именно нужно поменять, вместо пустого ответа.
Сейчас этот агент исследует код внутри CodeAlive и заодно ежедневно проверяет наши интерфейсы на практике. Если результат инструмента неудобен для модели, это становится заметно очень быстро.
RepoContextBench
На удачно подобранном демо почти любой агент выглядит убедительно. Нам этого было мало. Мы хотели видеть, стало ли качество действительно лучше после изменения поиска, промпта, модели или набора инструментов.
Так появился RepoContextBench, наша система воспроизводимой оценки работы с репозиториями.
Тесты задают практические вопросы о реальном репозитории, зафиксированном на конкретном коммите. Для каждого вопроса мы заранее указываем факты разного веса и ссылки на исходный код, который их подтверждает. Агент отвечает в обычном формате, а одна и та же модель-судья проверяет полноту ответа, работу с источниками, противоречия и неподтверждённые утверждения. Отдельно мы смотрим, нашёл ли поиск файлы, в которых лежал правильный ответ.
В одном чистом внутреннем прогоне на 20 вопросах режим deep research в CodeAlive с Qwen 3.6-35B-A3B набрал 77,6 из 100. Это единичный прогон на внутреннем датасете при фиксированных условиях судейства. Он полезен для отслеживания регрессий, но не годится для публичного лидерборда.
О RepoContextBench напишем отдельно. Покажем, как устроен датасет, как работает судейство, чем отличаются результаты моделей и какие ограничения нужно учитывать при чтении цифр.
Tool API v3 и MCP 3.0
11 июля мы выкатили Tool API v3, MCP 3.0 и третью версию скилла CodeAlive и плагина для Claude Code. В продакшене MCP сейчас работает maintenance-релиз 3.0.2.
В Tool API v3 одиннадцать read-only-операций. Через них агент может:
- найти доступные репозитории и воркспейсы;
- сориентироваться по онтологии и дереву файлов;
- выполнить семантический или точный текстовый поиск;
- прочитать артефакт или файл;
- пройти по связям между артефактами;
- запросить метаданные репозитория;
- делегировать исследование через stateless
chat.
Набор операций повторяет обычный ход исследования. Сначала агент находит подходящие участки кода, затем читает исходники и при необходимости проходит по связям между артефактами.
Для каждой операции генерируется OpenAPI-контракт. Ответ можно получить в виде структурированного JSON, компактного текста для агента или сразу в обоих форматах. Если запрос можно исправить, например уточнить путь или репозиторий, API возвращает инструкцию для следующей попытки. Ошибки аутентификации, квот, транспорта и неожиданные сбои сервера остаются обычными HTTP-ошибками.
Публичная операция chat не хранит состояние между вызовами. Вместе с вопросом нужно передать найденный контекст, идентификаторы артефактов и ограничения. Если у агента уже есть собственный цикл рассуждений, он может работать напрямую с низкоуровневыми инструментами.
Можно изучить справочник Tool API, подключить агента по гайду MCP или взять нашу референсную архитектуру агента для исследования кода.
Что дальше
У нас уже есть список следующих тем: поиск, RepoContextBench, дизайн инструментов для небольших моделей и технические решения, выросшие из реальных сбоев в продакшене. Что выйдет первым, пока не решили. Но ещё на год точно не пропадём.
