03 / ПРОЕКТИНЖЕНЕРНЫЙ КЕЙС · 2026

AI-агент для
проверяемых
правок кода

AI Integration · Agent Tooling · Local LLM Systems

Спроектировал локальную среду, в которой AI-агент работает с PHP- и Python-проектами: находит нужный код, выполняет команды в изолированном окружении, вносит ограниченную правку и проверяет результат перед завершением задачи.

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

2PHP И PYTHON: ПРОВЕРЕННЫЕ СЦЕНАРИИ ПРАВОК
7ДОКУМЕНТИРОВАННЫХ ВНУТРЕННИХ СЦЕНАРИЕВ PASS
4,91×РОСТ ПРОТЕСТИРОВАННОГО КОНТЕКСТА

Результаты внутренних испытаний 13–14 сентября 2026 года.

01 / ЗАДАЧА И РЕЗУЛЬТАТ

От запроса до проверенной правки

Мне нужна была локальная среда, в которой модель может работать с реальным репозиторием, но её действия ограничены рабочей папкой и инструментами проверки. Я связал локальный inference, доступ к коду, выполнение команд в Docker sandbox и проверку результата в один рабочий процесс для PHP и Python. Это внутренний инженерный проект.

02 / МОЙ ВКЛАД

Что я спроектировал и интегрировал

Архитектура и доступ

Связал Proxmox VE, LXC, Docker и постоянную рабочую папку. Агент выполняет команды в sandbox без прямого shell-доступа к хосту.

Правила работы с кодом

Настроил целевое чтение файлов и правки по актуальному состоянию; запретил полную перезапись существующих файлов и бесконечные повторные попытки.

Проверка результата

Встроил PHP/Python lint, статический анализ и тесты в завершение задачи. После повторно отклонённой правки агент останавливает изменения.

Настройка и маршрутизация

Профилировал Qwen3.6-35B-A3B на CPU/GPU и добавил llama-router: GPU загружает нужную модель по запросу, фоновые задачи идут через CPU-модель.

03 / РАБОЧИЙ СЦЕНАРИЙ

Как агент доводит задачу до результата

Зафиксированный PHP-сценарий проходит от чтения релевантного участка репозитория до правки, проверок и завершения. Для Python отдельно проверено восстановление повреждённого файла.

  1. 1

    Находит нужный участок кода и читает актуальную версию файла.

  2. 2

    Изменяет связный фрагмент, не перезаписывая весь существующий файл.

  3. 3

    Запускает проверки проекта: lint, статический анализ и тесты для PHP; compile/Ruff для Python.

  4. 4

    Фиксирует результат после PASS. При повторно отклонённой правке останавливает дальнейшие изменения.

Внутренние сценарии с документированным PASS

  • Native tool calls и JSON-аргументы
  • DFlash и сериализация вызовов инструментов
  • Read-only анализ репозитория
  • PHP: правка → lint/static/tests → finalize
  • Python: recovery → compile/Ruff → finalize
  • Остановка после исчерпания бюджета правок
  • Regression suite Workspace Tool 1.4.16

04 / ИЗМЕРЕНИЯ

Что показали тесты

Измерения двух внутренних конфигураций от 13–14 сентября 2026 года. Результаты benchmark и наблюдения в coding-запросах указаны отдельно.

Показатель До Результат Условия измерения
Контекст28 672 токена140 800 токенов (4,91×)Протестированный запрос; на 143 872 токенах возник CUDA OOM.
Cold prefill111,05 tok/s · uBatch 128~274,6–276,2 tok/s · uBatch 512~275,6 tok/s на cold request из 8 117 токенов; 2,48× в этом sweep.
Decode26,11 tok/s · без DFlash32,20 tok/s · DFlash n=2Выигрыш ~23% в benchmark; скорость не гарантируется для каждого запроса.
Coding turns—~30–33 tok/sНаблюдалось после настройки в репрезентативных запросах.
Prefix cache—~97–98% reuseТолько в representative final passes; зависит от сессии и переключения модели.

05 / АРХИТЕКТУРА

Как связаны компоненты

Архитектура: Open WebUI, llama-router, GPU-модель, Workspace Tool, Docker sandbox и постоянная рабочая папка; отдельно CPU-модель
  1. Open WebUI
  2. llama-router
  3. Qwen / Impish
  4. Workspace Tool
  5. Docker sandbox · PHP / Python
  6. Persistent workspace
Open WebUI направляет запрос через llama-router к нужной GPU-модели. Workspace Tool ограничивает операции с репозиторием; команды выполняются в Docker sandbox. Одновременно на GPU находится одна модель, отдельная CPU-модель обслуживает фоновые задачи.

06 / ИНЖЕНЕРНЫЕ РЕШЕНИЯ

Как выбирал рабочую конфигурацию

Контекст и память

Сохранил q8_0 K/V и протестированный предел 140 800 токенов. Запрос на 143 872 токена выявил границу по памяти.

Batch и MoE placement

uBatch 512 ускорил prefill; значения 544/576 не дали значимого выигрыша. n-cpu-moe=36 использует меньше VRAM без потери скорости относительно 34.

Speculative decoding

DFlash n=2 улучшил decode в серии тестов; n=4 и n=8 оказались хуже в зафиксированных измерениях.

07 / МАТЕРИАЛЫ

Как проверить этот кейс

PDF содержит схему, конфигурацию, измерения и результаты внутренних сценариев от 13–14 сентября 2026 года. Обезличенный ход выполнения задачи и результаты проверок могу показать на интервью.

Технический кейс (PDF, RU · 220 КБ) ↗

Отдельный пример AI-функции в коммерческом продукте — RAG FAQ для поддержки X-BOT. Смотреть X-BOT →

08 / ПРИМЕНЕНИЕ ОПЫТА

Где полезен мой опыт

AI/LLM integration · Agent tooling · Workflow automation · PHP/Python verification · Local inference · Model routing

Связаться по поводу роли →