Как тестировать ИИ-прокси для разработки ПО

Автор: редакция

Если поместить ИИ-прокси (API-шлюз / агрегатор) на карту программной инженерии, он окажется прокси-сервером прикладного уровня (L7) с парсером на основе конечного автомата и планировщиком контекста.

Требования изменились, когда на смену однострочному автодополнению в IDE пришли терминальные агенты вроде Claude Code CLI и OpenAI Codex CLI, а вместе с ними — разработка на основе спецификаций (specification-driven development). Оставим в стороне общие метрики шлюзов, такие как стабильность сети и поведение под высокой параллельной нагрузкой. Для генерации кода главный вопрос в другом: ломает ли прокси синтаксис, прерывает ли конечный автомат агента, теряет ли зависимости в длинном контексте и не вырезает ли протокол оптимизации, который отправил клиент для программирования.

Ответить на этот вопрос помогают четыре инженерных параметра.

1. Целостность синтаксиса и экранирования

Сгенерированный код чувствителен к символам и форматированию. Это не обычная проза: в нём есть отступы, переводы строк, экранирование и вложенные JSON или XML.

1. Экранирование без потерь

• Почему ломается: SSE-фрагмент с кодом содержит \n, \t, \", регулярное выражение \\d или JSON-строку. Если прокси снимает экранирование или перекодирует текст при сборке фрагментов, многобайтовый символ UTF-8 может разрезаться, и клиент получит код, который не проходит разбор.
• Как проверить: запросите код с экстремальным экранированием: тяжёлое регулярное выражение, Python со вложенными JSON-строками и C++ с указателями и макросами.
• Критерий прохождения: запишите поток от прокси в файл и разберите его локальным линтером (eslint, flake8) или AST-парсером (Babel или Tree-sitter). Доля успешного разбора AST должна составлять 100%.

2. Пробелы и отступы

• Почему ломается: в Python и YAML отступы задают область видимости. \n вместо \r\n меняет diff в Git.
• Как проверить: отправьте рефакторинг глубоко вложенной логики, например функции на Python внутри 8 уровней циклов.
• Критерий прохождения: пробелы и табуляции в выводе прокси должны побайтово совпадать с выводом вышестоящего API, на 100%. Прокси не должен «украшать» или сжимать пробельные символы.

2. Вызовы инструментов и структурированный вывод

Агент для программирования выдаёт не только Markdown. Он вызывает инструменты, например read_file, edit_file и run_terminal_command.

1. Точное соблюдение JSON-схемы

• Почему ломается: локальная правка — это структурированный JSON с полями вроде path, old_str и new_str. Если прокси нарушает сериализацию или теряет вложенное поле, агент не может разобрать ответ и падает.
• Как проверить: запустите агентную задачу, которая правит несколько файлов сразу, например рефакторинг интерфейса в 5 файлах TypeScript, и перехватите тело пересланного вызова инструмента.
• Критерий прохождения: пересланный объект вызова инструмента должен совпадать с тем, что вернул вышестоящий официальный API. Никаких пропавших полей, смены типов вроде string на number и преждевременно оборванного JSON.

2. Состояние в многоходовом диалоге

• Почему ломается: на сложный баг часто уходит 10–30 ходов: прочитать файл, попробовать правку, запустить тесты, прочитать ошибку, снова править. Прокси должен пересылать tool_use в role: "assistant" и tool_result в role: "user" по всей цепочке.
• Как проверить: запустите настоящую отладку силами агента длиной более 10 ходов.
• Критерий прохождения: на ходе N прокси по-прежнему пересылает все ID вызовов инструментов и узлы состояния из предыдущих N−1 ходов. История и состояние не должны теряться или перемешиваться.

3. Длинный контекст кода и кэширование промптов

Контекст средней или крупной кодовой базы часто занимает 100–200 тыс. токенов.

1. Сквозная передача cache-control

• Почему ломается: спецификация архитектуры и общий базовый код не меняются. Агент помечает их cache_control, чтобы сервис модели мог переиспользовать KV-кэш. Если прокси вырезает эту метку, правка одной строки снова запускает prefill сотен тысяч токенов.
• Как проверить: многократно отправьте инженерный контекст на 100 тыс. токенов с cache_control.
• Критерий прохождения:
• В запросе: тело, уходящее к вышестоящему API, по-прежнему содержит cache_control.
• В ответе: usage возвращает cache_read_input_tokens.

2. Иголка в кодовой базе

• Почему ломается: ради экономии прокси может обрезать промпт с помощью RAG, сжать его или подменить модель на меньшую, и модель начинает хуже видеть репозиторий.
• Как проверить: в репозитории на 150 тыс. токенов спрячьте определение интерфейса в начале файла A, а место вызова — в конце файла B, заполните середину посторонним кодом и спросите, как изменить интерфейс.
• Критерий прохождения: сравните правку через прокси с прямым вызовом официального API. Если из-за урезанного контекста прокси упускает переменную или тип из другого файла, контекст повреждён.

4. Полный вывод и защита инструкций

Типичный сбой выглядит так: модуль на 500 строк обрывается на 300-й.

1. Предел максимального вывода

• Почему ломается: рефакторинг одного файла может потребовать 4, 8 или даже 16 тыс. токенов кода в одном ответе. Маленький буфер прокси или короткий таймаут режет файл пополам.
• Как проверить: запросите один длинный модуль без воды, например парсер с сотнями перечислений и преобразований.
• Критерий прохождения: прокси должен выдерживать максимальный max_tokens модели. Итоговый finish_reason должен быть "stop" или "length". Преждевременный EOF — это провал.

2. Целостность системного промпта

• Почему ломается: агент для программирования задаёт в системном промпте строгие правила, например строгий режим TypeScript или JSDoc для каждой функции. Некоторые прокси вставляют собственный глобальный промпт или обрезают системный.
• Как проверить: отправьте системный промпт с характерным ограничением на стиль кода и запросите код.
• Критерий прохождения: код соблюдает это ограничение, а перехват трафика показывает, что системный промпт не изменён ни на один байт.

Чек-лист