Вайбкод для неискушенных

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

Важное условие эксперимента в использовании self-hosted моделей и opensource агентов. Плюс поскольку участники эксперимента специализируются не на разработке, а на решении проблем бизнеса нужна модель которая пусть и не супер кодит, но зато имеет широкий кругозор.

Поэтому мною были выбраны:
- агент Crush (в девичестве OpenCode) в качестве базового TUI, но важной его особенностью является поддержка Agent Client Protocol (ACP), что позволяет встроить его в любой совместимый клиент (например obsidian, drawio или pycharm)
- модели gpt-oss 20b и 120b, потому что они в себе идеально сочетают широкий кругозор, размер, скорость и поддержку function calling, что позволяет использовать их в качестве базы для агента

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

Сегодня канал преодолел 3000 подписчиков, удивительно с какой скоростью это произошло, ведь 2000 было всего навсего в ноябре прошлого года, а с тех пор прошло чуть больше 4 месяцев.

Спасибо, что вы здесь, постараюсь и дальше радовать вас своим ворчанием, феласофией и забористым контентом :)

Эксперимент (день 1)

Первая проблема с которой столкнулись участники оказалась в сложности установки консольного тула Crush, на виндовс нужна утилита winget, на макоси brew, я кстати пробежался по всем консольным тулам (типа курсора, клод кода, джемини и так далее) и эта общая проблема, вместо создания MSI/EXE пакетов для виндовс и DMG для макоси авторы большинства консольных тулов делают непонятно что, какие-то скрипты для PowerShell, какие-то curl | bash, ладно бы на линуксе только, мы тут все привычные к такому.

Вторая проблема в том, что Crush оказывается не поддерживает ACP, на эту тему есть PR у них, который открыт с февраля, вообще это очень странно, ведь Crush это форк OpenCode, почему эту часть не портировали не очень понимаю.

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

ACPBox - Agent Client Protocol (ACP) в формате OpenAI API

В последнее время много занимаюсь интеграцией агентов и в какой-то момент устал каждый раз заново собирать ReAct лупу под задачу, пришла идея взять уже готового агента по Agent Client Protocol (stdio, JSON-RPC) и не городить свой HTTP-слой, а выставить наружу привычный OpenAI-совместимый API - один base URL, те же /v1/models, /v1/chat/completions (стейтлесс), /v1/responses (стейтфул), чтобы подключались обычные клиенты и SDK, типа Open WebUI и аналогов.

За пару вечеров собрать проект ACPBox, под капотом там uvicorn, на каждый worker один долгоживущий процесс агента, запросы с OpenAI-формата переводятся в ACP и обратно, стриминг и список моделей из режимов агента поддерживаются.

Установка изолированно через pipx:

pipx install acpbox

Пример минимального config.yaml для OpenCode агента:

acp:
  command:
    - opencode
    - acp
  env: {}
  workspace: "./workspace"

gateway:
  host: "0.0.0.0"
  port: 8080
  workers: 1
  threads: 1

Для курсора вместо opencode acp задаём agent acp, аналогичная фичу можно использовать и для джемини, и для клод кода и так далее.

Запускаем так:

acpbox --config ./config.yaml

На http://localhost:8080/docs появится OpenAPI/Swagger UI, можно будет потыкать агента.

Репозиторий: https://github.com/EvilFreelancer/acpbox
PyPi пакет: https://pypi.org/project/acpbox/

PS. Важный нюанс, кодовый агент, типа того же OpenCode или Cursor нужно настраивать заранее и отдельно, так как ACPBox это просто обёртка для работы кодовым агентом и занимается только решение задачи проксирования запросов от пользователя к агенту и обратно.

За вчера порядочно прокачал проект Coddy, переделал подсистему которая пишет код на ACP, так что теперь её можно использовать с любым кодовым агентом.

В планах реализовать хук автоматического переключения на новую версию Docker-контейнера после мерджа PR и автоматического бампа версии.

"What I cannot create I do not understand" (c) Richard Feynman

Решил провести небольшой эксперимент чтобы узнать:

может ли кодовый агент создать кодовый агент?

Если кратко, то да, может, но обо всём по порядку.

В качестве кодогенератора взял Cursor, но не простой, а используя модельку Sonnet 4.6 от Antropic, при этом, поскольку Claude Code мне так и не удалось настроить нормально, пришлось юзать модельку через API.

Заранее написал и предоставил агенту подробные спецификации по разработке кодового агента, агент этот должен собираться в один бинарник (да да, выбрал golang), должен уметь работать в формате Agent Client Protocol (ACP) агента, приложил ссылки на документацию, спецификации ACP, примеры того как работает Cursor, Codex и Claude Code, информацию о том как работать со скилами и MCP-серверами, плюс информацию о разных протоколах общения с моделями (OpenAI, Antripic, Ollama, OpenAI-like) и что мне нужен агент способный работать в режиме агента и в режиме планировщика (два моих любимых режима), плюс нужен визард конфига для первичной настройки.

Флоу стандартный BDD, сначала модель должна изучить все документы что я предоставил, потом синтезировать спецификации того, что конкретно она будет делать, потом по слоям создавать решение, сначала тесты, потом класс и так далее. В финале она должна убедиться, что полученное решение проходит все тесты, собирается по инструкции и что его можно по ACP использовать. Моделька соннет 4.6 где-то полчаса пилила проект, составил документацию хорошую. потом итеративно реализовала код. Отскакивая в сторону могу сказать, что качество кода для one-shot в целом очень приемлемое, понимаю почему людям так нравится клод код и эти модельки.

Далее я попробовал через плагин obsidian-agent-client для Obsidian настроить созданный мой агент и о чудо, он работает, хотя конечно у меня есть вопросики к интерфейсу ACP-клиента в Obsidian (форкну@пофикшу, ага), но это пока что мелочи.

Исходники Coddy Agent тут: https://github.com/coddy-project/coddy-agent

Кстати, поскольку судьба Телеграм неизвестна, на всякий случай, чтобы не потерять связь, завёл страничку на Бусти:
https://boosty.to/evilfreelancer

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

Проблема долговременной памяти чатов

Хоть я и считаю себя сторонником памяти агентных систем, даже большой пост на эту тему писал, но работая с чатами в которых есть память истории всех сообщений периодически ловлю себя на мысли, что надо напилить какой-нибудь пост на тему того, что память эта частенько работает плохо, вносит искажения в ответы модели и единственный годный режим её работы это "off", то есть отключена.

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

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

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

Ловите мой новый пост на Бусти, в нём я рассказываю про модельку ruGPT3XL на 1.3B, которую мне удалось отреставрировать и заставить работать на современном железе.

upd. Пост на бусти так как ещё не всё готово, но всех кому интересно приглашаю принять участие в тестировании.

https://github.com/ggml-org/llama.cpp/pull/21011

Смерджили

Встречайте мой новый пост "Реставрация ruGPT-3 XL или как я вернул к жизни забытую русскую языковую модель" на Хабр, в нём я подробно рассказал о том как была реализована конвертация, как проводилось её тестирование, как запустить локально, как конвертировать в GGUF.

А вот ссылочки:
- evilfreelancer/ruGPT3XL - сконвертированная модель в формате HuggingFace (safetensors)
- evilfreelancer/ruGPT3XL-GGUF - квантизированные GGUF-веса для llama.cpp и Ollama
- evilfreelancer/rugpt3 - GGUF загруженные на Ollama
- EvilFreelancer/rugpt3xl-convert - исходники скриптов конвертации

Выгрузить модель на HuggingFace не так-то просто

Конвертировал тут новинку chromadb/context-1 в mxfp4 формат и пытаюсь загрузить веса на HuggingFace, но по какой-то причине huggingface-cli перестал подхватывать переменные прокси, в результате чего из моего контура запросы не уходят, пришлось лезть в исходники и оказалось, что авторы HF добавили в свой тул хранилища типа Xet включенные по умолчанию, а эта штука не использует httpx и как следствие игнорирует настройки прокси.

Короче чтобы решить эту проблему и из рабочего контура подключиться к проксику надо вырубить Xet переменной HF_HUB_DISABLE_XET, а дальше передать проксики и команду:

HF_HUB_DISABLE_XET=1 \
ALL_PROXY=socks5://192.168.1.21:1080 \
HTTPS_PROXY=socks5://192.168.1.21:1080 \
HTTP_PROXY=socks5://192.168.1.21:1080 \
huggingface-cli upload evilfreelancer/context-1-mxfp4 ./context-1-mxfp4 . --repo-type model

После этого загрузка начала работать.

Размышлял о памяти нейросетей и очень захотелось перечитать труд Марвина Мински про фреймы знаний.

Конвертация Chroma Context-1 в MXFP4 для домашней 4090

Позавчера Chroma выкатила техрепорт по своей модельке chromadb/context-1, прочёл я его сегодня и был крайне впечатлен.

Это 20B параметров, MoE-архитектура на базе openai/gpt-oss-20b, модель натренирована на агентный поиск, делает декомпозицию сложных запросов на подзапросы, выполнняет итеративный поиск по корпусу документов, и самое интересное - self-editing context, когда модель сама решает какие из найденных документов оставить, а какие выкинуть чтобы не засорять контекстное окно. На бенчмарках показывает результаты сопоставимые с топовыми LLM при скорости как у gpt-oss-20b.

Естественно, захотелось потрогать руками, но... модель выложена в BF16, а это 39 ГБ только веса, ну а моя 4090 хоть и прокачана до 48 ГБ VRAM, но 39 ГБ чистых весов + KV-кеш + накладные расходы CUDA в неё не влезут, нужно минимум ~45-50 ГБ чтобы хоть что-то сгенерировать с минимальным контекстом, но нужен не минимальный, а хотя бы 30-60к токенов, агенты же.

Что делать? Смотрю на оригинальную gpt-oss-20b от OpenAI, она в формате MXFP4, это Microscaling FP4, хитрый 4-битный формат, где каждый вес хранится как E2M1 (2 бита экспонента, 1 бит мантиссы), а группа из 32 весов делит общий 8-битный масштаб (E8M0), нативно поддерживается в vLLM через Marlin-ядра и должно отлично работать на RTX 50xx серии, в таком формате модель занимает ~14 ГБ, на мою 4090 влезает с запасом.

Сформировал спеки для кодового агента в Cursor, говорю мол вот тебе веса модели gpt-oss-20b как референс, вот спецификация по методам сжатия MXFP4, вот веса модели context-1 в BF16 которую надо конвертировать, вот docker-compose.yaml с vLLM 0.18.0 на которой агент должен проверять модель.

Задача написать скрипт конвертации, конвертировать модель, запустить в vLLM, убедиться по HTTP что приходят адекватные ответы.

Агент написал скрипт, который читает safetensors, для MoE-экспертов (gate_up_proj и down_proj) транспонирует веса в layout который ожидает vLLM, квантует и пакует всё в MXFP4, по аналогии с gpt-oss-20b, а слои внимания, роутера и эмбеддингов копируются как есть в BF16. В результате 39 ГБ превращаются в ~14 ГБ.

Запустил на vLLM, всё работает, reasoning что-то там рефлексирует, ответы вроде адекватные, но при тестировании tool calling (function calling) выяснилась забавная штука - модель при вызове инструментов валится с ошибкой:

openai_harmony.HarmonyError: Unexpected token 12606 while expecting start token 200006

Покопавшись в конфигах gpt-oss-20b обнаружил, что в generation_config.json модели отсутствует токен <|call|> (id 200012) в списке eos_token_id, из-за этого модель не останавливает генерацию после вызова tool call и harmony ломается. По сути баг в vLLM, но фикс элементарный, добавить 200012 в eos_token_id в generation_config.json модели, после этого и обычный чат и tool calling заработали как надо.

Создал PR с фиксом в трекере оригинальной модели.

Ну а квантованную в MXFP4 версию загрузил на HuggingFace: evilfreelancer/context-1-mxfp4

PS. Поднял её на домашней видяшке и сделал доступной через мою апишку, пример как заюзать через openai-клиент добавил в комментарии.