llm-wiki: правила компании, которые агенты читают, а люди утверждают

Сегодня я начал новый проект, и он получился самым «взрослым» из всех. llm-wiki — это база знаний и правил компании, из которой ИИ-агенты берут инструкции.

Проблема

Когда в команде несколько ИИ-агентов (код-ревьюер, помощник по документации, ассистент для поддержки), у каждого свой CLAUDE.md или AGENTS.md. Через месяц они расходятся: в одном написано «используем poetry», в другом «используем uv», в третьем правило про логирование устарело ещё в августе. Агенты добросовестно следуют противоречащим друг другу инструкциям.

Идея

Одно место, где живут все правила, и сборка, которая превращает их в инструкции для конкретного агента:

wiki/                  # отдельный Git-репозиторий с контентом
├── AGENTS.md
├── inbox/             # сырьё, не индексируется
├── raw/               # небольшие исходники
├── wiki/              # страницы знаний и правил
└── schema/            # типы, связи, области, профили

wikisvc хранит Markdown в Git, индексирует его и компилирует инструкции по профилям: агенту для бэкенда — одни правила, агенту поддержки — другие. Сервис детерминированный и сам не вызывает LLM. Отдаёт всё по HTTP API и по MCP.
wikiagent — отдельный клиент с LLM. Он разбирает сообщения, готовит предложения правок, вытаскивает кандидатов в правила из книг и ищет несостыковки.

Путь правки: от агента через человека в вики и обратно к агентам.

Главный принцип

Решения принимает человек. Агент может предложить новое правило или правку, но принять её может только человек, и не автор предложения. В коде это жёстко: у токена есть тип kind=agent или kind=human, и решения ревьюера требуют human.

Почему так строго? Потому что правила — это то, что потом исполняют другие агенты. Если агент может сам себе написать правило «можно удалять продакшен-базу», вся система рушится.

Сегодняшний день

Сегодня я реализовал спецификацию сервиса целиком, этапы с 0 по 7: хранилище, индекс, авторизацию, извлечение. Вечером прогнал ревью и исправил найденное в записи, авторизации, извлечении и индексации. Плюс упакованные тесты и smoke-проверку инициализированной вики.

Стек: Python 3.12+, FastAPI, SQLite FTS5 для поиска и Git worktrees для изоляции правок. Про FTS5 и worktrees будут отдельные разборы.

Откуда идея

Сама мысль «пусть LLM ведёт вики вместо поиска по сырым документам» витает в воздухе с весны, когда Андрей Карпати опубликовал свою заметку. Разбор — в соседнем посте. Моё главное отличие: у Карпати вики принадлежит LLM, а у меня — людям, а LLM только предлагает.