Как QA-агенты сами пополняют базу знаний и сокращают поиск причины бага с 2 часов до 10 минут

Представьте: QA два часа выясняет, почему на самовывозе пустая витрина. Оказывается, это не баг. Кэш наличия обновляется раз в несколько минут, а мок остатков перебивал живой прокси с неверным приоритетом. Знание получено, но осело в голове одного человека или в чате, который через неделю никто не найдёт. Через месяц другой QA тратит на то же самое те же два часа. А у ИИ-агента памяти между сессиями нет вообще, так что он повторяет этот путь каждый раз.

Команда тестирования «ТехВилла» решила это отдельной платформой MKP (Multi knowledge platform). Ниже разбираем, как она устроена и что из неё можно забрать себе.

Что такое MKP и как она ищет

MKP — внутренняя платформа с базами знаний и умным поиском. Баз два типа: встроенная evawiki с корпоративной документацией (через MKP из неё можно только читать) и markdown-базы команд, где документы можно создавать, обновлять, удалять и искать по смыслу. Работать можно через веб-интерфейс, REST API и MCP-сервер для агентов в Cursor, Claude Code, Codex. У MCP всего пять инструментов: список баз, смысловой запрос, получение документа по номеру, создание или обновление, мягкое удаление.

Под капотом RAG, но не самый наивный. Hybrid dense/sparse retrieval сочетает смысловой поиск с поиском по ключевым словам. Для QA это критично: идентификаторы вроде GetExists, is_pickup или CMA-14699 чистый векторный поиск любит терять. Дальше идут multi-query (модель переформулирует вопрос), reranking и parent-child retrieve: ищем по мелким фрагментам, а отдаём контекст всего раздела. В ответе всегда есть текст, источники со score и snippet, а также trace_id для диагностики.

Агент пишет в базу сам

Главная идея в том, что документы руками никто не кладёт: иначе через полгода получится ещё одна заброшенная wiki. Вместо этого MKP встроена в QA-кит, репозиторий с правилами и skills для Cursor и Claude Code. Агент работает как редактор: отбирает из сессии проверенное знание, а не сливает в базу весь диалог.

На каждый домен (каталог, поиск, рекомендации и так далее) заведено четыре базы:

• wiki — устойчивые знания: архитектура, контуры, моки, «как правильно проверять»;
• outputs — полные тексты тест-планов, результатов и комментариев в Трекер;
• daily — записи по дням и оглавление index;
• artifacts — сырые доказательства: curl, SQL, JSON, моки.

Перед показом тест-плана агент обязан сделать четыре поиска: был ли ретест по точным номерам документов, что ловили на похожем в outputs, что команда знает о сервисе в wiki и что говорит продукт в eva-wiki. После тестирования он записывает план, результат и комментарий в outputs, день в daily, а новый устойчивый факт в wiki.

Что это даёт на практике

Пустая витрина: теперь вопрос к catalog-wiki возвращает чек-лист на девять пунктов за 24 секунды. Там кэш наличия, предзаказы, приоритет мока в WireMock, 403 от прокси поиска. QA проходит его за десять минут вместо двух часов. Этот чек-лист никто не писал как статью: он собран из разборов задач, куда агент по одному дописывал факты.

Задача на аналоги товаров: агент заранее поднимает результаты двух прошлых прогонов. Новый QA знает, какие фикстуры готовить, не заводит ложный DEFECT на недостижимый легаси-путь (коллега уже пометил его как QUESTION) и сразу добавляет проверку, не стоит ли на контуре старый код без фильтра. Лид по оглавлению daily видит, что делала команда, без отдельного статус-митинга.

Права и дисциплина

Доступ устроен строго. Ролей две: admin и user, а права read и write выдаются на каждую базу отдельно. Для каждого агента заводят отдельного пользователя с минимумом прав, а технического пользователя можно лишить входа в UI. Агент читает базы своего домена и eva-wiki, а пишет только в свои четыре. Автор документа определяется по API-ключу, команда видна в метаданных. Реестр доступа лежит в git.

Ограничения и вывод

В статье нет оценки качества записей и того, как отсекается ошибочное знание, попавшее в wiki, хотя агент пишет туда сам. Цифры экономии времени — внутренние и приведены на отдельных примерах. Новый документ ещё и ищется не сразу: сначала он проходит статус processing.

Практический вывод для команд, которые работают с агентами: не нужна ещё одна wiki, нужен цикл «вспомнить, поработать, записать». Минимальный набор: разделить устойчивые знания и результаты прогонов, обязать агента искать до работы, давать ему узкие права и хранить источники рядом с ответом. Тогда каждая задача делает следующую дешевле.