Загрузка 0
ПОДЕЛИТЬСЯ

Мой блог

Листай вниз

Сопровождение форка OpenResearch: три недели работы с Claude

Сопровождение форка OpenResearch: три недели работы с Claude

Продолжение работы над интеграцией кодинг-агентов в OpenResearch показывает, как происходило дальнейшее развитие проекта. После первоначального релиза с тремя новыми агентами потребовалось несколько недель регулярного сопровождения, исправления ошибок авторизации и адаптации под обновления ZCode.

Сопровождение форка OpenResearch: три недели работы с Claude
Сопровождение форка OpenResearch: три недели работы с Claude — изображение 15
Сопровождение форка OpenResearch: три недели работы с Claude — изображение 16
Сопровождение форка OpenResearch: три недели работы с Claude — изображение 17
Сопровождение форка OpenResearch: три недели работы с Claude — изображение 18
Сопровождение форка OpenResearch: три недели работы с Claude — изображение 19
Сопровождение форка OpenResearch: три недели работы с Claude — изображение 20

За трехнедельный период с конца сентября по середину октября было выпущено восемь промежуточных версий форка. За это время ассистент выполнил десятки коммитов, добавил новые тесты и синхронизировал изменения с репозиторием upstream, преодолевая технические препятствия на стыке работы десктопных рантаймов и веб-интерфейса.

Хронология восьми релизов форка с 28 сентября по 16 октября
График выхода релизов форка OpenResearch

Хронология релизов и общая статистика

В течение девятнадцати дней активной фазы разработки кодинг-агент потратил чуть более одиннадцати часов чистой работы, которая распределилась по множеству сессий. За этот период кодовая база пополнилась новыми тестами и изменениями в десятках файлов, не считая пересборки статических элементов интерфейса.

Реклама
Диаграмма причин сбоев после первой публикации
Анализ сбоев по пяти различным источникам
Блок-схема определения входа в ZCode 3.15 по записи auth-source
Алгоритм определения параметров авторизации рантайма

Релизы выходили последовательно, начиная с версии v0.3.3, где появилась базовая обработка ошибок входа для ZCode, и вплоть до v0.3.10, включившей исправления по результатам автоматических ревью. Процесс строился на постоянной проверке сборок в рабочей операционной системе с использованием реальных учетных записей, что позволяло вовремя отлавливать нестыковки между изолированным контейнером и десктопным окружением.

Схема работы ZCode через app-server от выбора модели до подтверждения
Порядок обмена сообщениями при работе через app-server

Технические трудности и интеграция ZCode

Основной массив проблем был связан с изменениями в самом агенте ZCode, который обновлялся быстрее, чем проект успевал адаптироваться. Первые трудности проявились в ошибках выбора модели, возникающих из-за особенностей авторизации в командной строке и десктопном приложении.

Схема режимов host и standalone для учетных данных Coding Plan
Источники учетных данных для рантайма Coding Plan

Проблемы авторизации и работы с моделями

Стандартный вход в приложение ZCode не передавал необходимые данные рантайму, из-за чего интерфейс выдавал требования выбрать модель. Для решения этой проблемы в настройки добавили специальную кнопку вызова авторизации без браузера. Дополнительно выяснилось, что бесплатный тариф Start Plan требует прохождения капчи через графический интерфейс и не функционирует в автономном режиме, а ключи от чужих учетных записей вызывают сбои при совпадении идентификаторов.

Путь от ошибки app-server до рабочего процесса на Windows
Сравнение путей отладки в разных окружениях
Пикер ZCode с меню провайдеров и режимов
Выбор провайдера и режима работы агента

Выход версии ZCode 3.15 принес изменения в протоколе авторизации, где вместо привычного ключа плана стал использоваться OAuth-токен. Поскольку стандартный инструмент запускал графическое приложение в псевдоконсоли Windows, вывод команд терялся, а длинные ссылки обрезались. Разработчикам пришлось перенастроить запуск через PowerShell для корректного перехвата вывода.

Карточка ZCode в настройках приложения
Отображение статуса входа и подключенных провайдеров

Переход на app-server и устранение ошибок

Отказ от простого режима печати в пользу полноценного протокола JSON-RPC через стандартный ввод-вывод позволил задействовать канал подтверждений, выбор моделей для каждого чата и реальный режим планирования. Однако официальный рантайм работал в режиме host, ожидая учетные данные от управляющего приложения, в то время как платформа запускала его автономно.

Схема хода через print-режим по результатам первого ревью Greptile
Особенности выполнения запросов в режиме печати

Для преодоления этого ограничения потребовался специальный JavaScript-загрузчик, который вносил необходимые изменения в минифицированный код в памяти процесса. Потребовалось также учитывать истекшие токены авторизации и особенности хранения ключей доступа, чтобы диагностика ошибок выдавала понятные пользователю сообщения вместо абстрактных сбоев.

Цикл сопровождения форка при обновлениях upstream
Последовательность шагов при синхронизации с upstream
Чат ZCode в режиме Ask с карточкой подтверждения
Интерфейс подтверждения действий агента в чате

Взаимодействие с upstream и ревью кода

Все изменения были оформлены в виде отдельных запросов на слияние в основной репозиторий проекта. Автоматический бот Greptile провел два раунда проверки кода, выявив ряд логических недочетов, включая проблемы с потерей контекста сессий при сбое и блокировку редактирования файлов после одобрения плана.

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

Оценка по ценам API и реальные затраты по периодам
Сравнение расчетных и реальных расходов на разработку
01.