Рубрика: "малоизвестные фичи IDEA".

В меню "File" можно найти такой пункт как "Remote Development". Сразу скажу - только в Ultimate версии.
Два основных вопроса - что это и зачем это?

Начнем с первого.
Это клиент-серверная IDEA. На вашем компе поднимается компонент Gateway - тонкий клиент IDEA с идентичным интерфейсом, являющийся, как следует из его названия, шлюзом к серверу.
К серверу можно обращаться по 3 протоколам:
1) ssh - удаленный сервер
2) WSL - для тех, кому нужен полноценный Linux на Windows, как бы странно это не звучало
3) Dev Containers - если нужна изолированная среда локально. Про Dev Containers, к слову, стоит написать отдельно, эта штука менее популярна, чем те же Test Containers.
У Gateway к слову отдельный бинарник и отдельный файл настроек (vmoptions).

Что за сервер?
Это по сути полноценная инсталляция IDEA на Linux. При настройке подключения в родительской IDEA нужно выбрать версию remote IDEA, она должна совпадать с версией на рабочем месте. Там опять же свои настройки (idea.properties и vmoptions). Занимает порядка 3 Гб.
Перед инсталляций будет проверка на системные требования, из важного - минимум 4 Гб ОЗУ должно быть свободно. В вылетающием warning есть слово "рекомендовано", но по факту при несоблюдении этого требования инсталляция падает.
Это логично, т.к. основная работа будет на сервере, при оценке требуемой ОЗУ нужно отталкиваться от ресурсов, требуемых при обычной локальной разработке по вашим проектам.

По функционалу - из того, что заметил работает все. Плагины, рефакторинги, генерация, поиск, переходы между классами, run configurations, встроенные linter-ы (вкладка Problems), полноценная работа с git, консоль (естественно, доступны те консоли, что есть на удаленном сервере)...
Т.к. это разные бинарники с обычной IDEA - это разные окна, причем открыть новое окно Remote Development можно только из основной IDEA или прямым запуском.

Теперь главный вопрос - зачем это нужно?
Для начала зачем нужно было до эры AI - ага, не опять, а снова))):
1) запуск сборки на полноценном Linux если рабочий комп на Win
2) разработка на слабом ноуте - монитор правда все равно нужен нормальный, как и клавиатура с мышью
3) запуск сборки в песочнице (чтобы не ставить серверное ПО на рабочий комп)

Ну а в настоящий момент к этому всему добавляется одно важное применение - запуск AI агента на зарубежном сервере с постоянным IP, без VPN (но с регистрацией), что дает нам:
а) уменьшение вероятности блокировки
б) не нужно постоянно перещелкивать VPN для доступа к ресурсам разработки, к которым нет доступа из-за санкций и\или VPN
в) AI агента можно запуска в yolo режиме (без подтверждений), предварительно настроив запрет force push и удаления master ветки
г) в такой схеме можно вести "non-stop" разработку в 2 режимах: полное погружение (анализ и ревью кода) с компа в IDE и контроль работы агента в остальное время - переписка с агентом с телефона, например, в дороге или на прогулке.
Можно даже голосовухи агенту записывать, если мобильный клиент позволяет)

Важное условие - чтобы сессия агента не рвалась при закрытии крышки ноута нужно запускать ее в tmux (очень полезная штука, рекомендую).

Подводные камни:
а) коннект по ssh, который обычно режут в корпоративной сети
б) местонахождение удаленного сервера стоит синхронизировать с VPN, используемым для оплаты подписки и локального доступа
в) сервер стоит денег, но небольших, сравнимых со стоимостью базовой подписки на AI.

#idea #ai

Минутка удивления способностям AI.

Сегодня при работе с Claude Code и Opus 5 стал замечать одну интересную штуку.

Задача - написать сложный тест. В ответе модели в CLI:

Мутационно проверен — обе попытки «сдать» тест валят его:
- убрать финальный пулл → live metric lost points;
- оставить метрику ingest_enabled=false после apply → onboarded metric is not being pulled after the flip.

Первая версия ассертов, кстати, мутацию пережила (точки новой метрики приходили от backfill'а) — отсюда шаг 4.

Кто из вас включил в CI пайплайн фреймворк для мутационного тестирования (PITest, например)?
Кто пытается сломать свои тесты перед коммитом?
А AI агент делает.
Причем в требованиях к проекту в контексте этого нет - да, позор на мою седую голову)))

P.S. Причем раньше я периодически замечал, что assert-ов в написанных AI тестах не хватает.

P.P.S. В context конечно требования стоит добавить, это часть Evals.

#ai #ai_agents #unit_tests

Агент работает по TDD, но делает ли он это с уважением правильно?

Недавно говорил с коллегой по поводу superpowers и TDD, и возник интересный вопрос.
Формально да, процесс идет по TDD - red-green-refactor - пишется тест, он падает, пишется код, тест зеленеет.
Но становится ли такой код качественнее, ведь LLM всегда может подогнать код под результат?

Давайте посмотрим на основные аргументы в пользу TDD.

1) TDD гарантирует нам, что тесты точно будут, покрытие растет, регрессионные баги находятся на этапе разработки.
С AI тесты точно будут, если поставить ей такую цель - через контекст, субагента или навык.
Скорость кодирования вырастает, агенту не важно что писать - код или тесты.
В этом плане точное следование TDD мало что дает - достаточно явных требований агенту и процедуры их валидации.

2) т.к. тесты пишутся до кода, то код гарантированно выставляет более согласованное и более тестируемое API.
Тут TDD помогает, с двумя ремарками:
а) модель может смухлевать и подогнать тесты под существующий код. Как с этим бороться - отдельная тема
б) если говорить про superpowers - он пишет сразу план с тестами и кодом.
Поэтому тот факт, что вначале идет тест, важен, но не так критичен.
AI работает в одной сессии, а при разработке человеком - сессии разные, между написанием кода и тестов могут пройти дни.
А т.к. сроки ограниченны => плохое API остается навсегда.

3) короткий цикл разработки, быстрая обратная связи, как итог - правильная декомпозиция задач.
Это очень важно, и TDD в исполнении AI агента тут помогает собственно AI разработке.
Если подзадачи мелкие - на них проще сделать evals (приемочные тесты), не забыть ничего.
Некоторые задачи можно распараллелить, если агент это поддерживает
И т.об. снизить время ревью человеком и превратить преимущество в скорости кодирования агента в уменьшение Lead Time.
Ремарка - блокер тут не только время ревью, но это оно оказывает существенное влияние.

4) благодаря TDD тесты становятся документацией.
Исходя из моего опыта с superpowers - "из коробки" это не так, нужно дополнительно настраивать контекст, чтобы тесты были читаемы.
И второй ключевой момент - задание evals со стороны разработчика на этапе проектирования.
Именно тесты, являющиеся приемочными - лучшая документация.

Вывод: да, с AI важность TDD меньше, чем без нее.
Но все равно TDD остается полезен если не забывать про evals (приемочные тесты) и донастроить обвязку под читаемость тестов и запрет хаков со стороны модели.
Главные плюсы: тесты как документация на основе заданных evals и короткие контролируемые циклы разработки.
Т.е. само написание тестов до кода тут не так важно, как качество тестов и написание их в одной сессии с кодом.
И да, при таком подходе тесты можно было бы писать после кода в одной сессии. Но зачем?)

#ai #ai_agents #tdd

Рубрика - приколы с AI агентами.
Есть шанс, что станет постоянной.

И сразу преамбула - да, агенты часто смешно косячат. Даже самые сильные, типа Claude Code с Claude моделью.
Но это не значит, что они бесполезны.
Правильный подход - понимать причины этих косяков и нивелировать их правилами в контексте и evals-ами.

Так вот, AI очень любит нарушать принцип DRY - Don't Repeat Yourself.
Вот прямо хлебом не корми.
При создании новой фичи с большой вероятностью там появится копия существующего инфраструктурного кода.
Или даже несколько - в каждом новом классе\файле.

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

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

Что вы думаете?

В скиле эти примеры появились в 3 местах!)))

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

Что касается причин такого поведения.
Мне видится такая: для LLM дублирование - это сигнал. Сигнал, повышающий важность информации.
Даже есть такая техника промтинга.
Т.е. пока ей явно не скажешь, что это проблема - LLM это проблемой не считает.
Есть еще идеи, почему они так работают?

#ai #ai_agents #dry #ai_fuckup

Сколько на самом деле стоит AI coding agent?

Вот тут интересные цифры сравнения стоимости подписки и доступа по API https://habr.com/ru/news/1046644/

Разрыв конечно впечатляет. Можно сказать, что по подписке нам дают AI практически бесплатно.
Возможно это так, но себестоимость мы не знаем.

Но это не так важно, основной вопрос - не закроют ли подписки, раз это так не выгодно для провайдеров LLM моделей.

На мой взгляд нет. Почему? Конкуренция.
Claude vs ChatGPT vs Gemini vs Grok.
Да, последние двое пока проигрывают, но сдаваться не собираются. И если один из них подписку отменит, то люди уйдут к конкуренту.

Но. Есть же ещё Китай.
Как минимум это Kimi, Qwen, GLM, Deepseek, Minimax.
Это ещё 5 конкурентов. Итого 9. У большинства есть подписки.

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

Чему лично я буду очень рад)))

P.S. А что насчёт окупаемости? Мне видится, что все оплатят инвесторы - те, кто сейчас покупает акции Anthropic, Tesla и т.д

#ai

Когда я впервые увидел embedded Kafka, то подумал: Круто, жаль, что такого же нет для PostgreSQL.
И был не прав, спасибо, коллега просветил.
Встречаем Zonky Embedded Postgres https://github.com/zonkyio/embedded-postgres

Подключается как Java зависимость. Можно управлять версией PostgreSQL. Поддерживает ОС Darwin, Windows, Linux, Alpine Linux и Intel и ARM архитектуры. Легко подключается в тесты и утилиты миграции БД через rules.

@Rule
public SingleInstancePostgresRule pg = EmbeddedPostgresRules.singleInstance();

@Rule
public PreparedDbRule db =
EmbeddedPostgresRules.preparedDatabase(
LiquibasePreparer.forClasspathLocation("liqui/master.xml"));

Также можно работать напрямую с объектом БД:

try (EmbeddedPostgres pg = EmbeddedPostgres.start();
             Connection c = pg.getPostgresDatabase().getConnection()) {
...
}

Как по мне - крутая штука, и вот почему. Рассмотрим альтернативы:
1) обычная инсталляция PostgreSQL - есть момент с правами, плюс единая инсталляция на компьютере разработчика - это shared ресурс на несколько проектов и риск поломки БД
2) Docker - опять же может не быть необходимых прав, плюс Docker - это тонкая, но все же прослойка. Которую нужно запустить и которая немножко жрет ресурсы.

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

Ну и отсюда к следуют минусы - на скачивание и распаковку в папку target нужно время.
Ну и время жизни такой инсталляции ограничено.
Поэтому идеальный кейс - тесты на живой БД.

#db #postgrrsql #integration_tests

Два факта про безопасность AI.

Первый - есть исследование, где говорится, что 45% сгенерированного AI кода содержит классические программные уязвимости из OWASP Top 10 https://www.veracode.com/blog/genai-code-security-report/ Причем за 2 года с 23 по 25 год ситуация практически не изменилась. В отличие, например, от процента компилируемого кода.

Второй факт - сообщение агента вчера при работе с Claude Opus, процитирую:

Напоминаю по факту: я запустил sudo cat /etc/gitlab-runner/config.toml, чтобы проверить extra_hosts, и в выводе целиком приехала строка token = "glrt-X…". Надо было сразу grep -v token — дальше я так и делал, но эту строку уже не отменить.

Итог: токен в 2 файлах транскрипта сессий (~/.claude/projects/**.jsonl) плюс в бэкапе /etc/gitlab-runner/config.toml.bak.20260810, который создал я.

Главное, а не файлы на диске: он был в моём контексте, то есть ушёл в API Anthropic. Локальной утечкой это уже не назвать.

Дайте новый токен — впишу и перезапущу, privileged/volumes не тронув. Или сделайте сами, если не хотите гонять его через меня второй раз — что, учитывая причину ротации, разумнее.

Что меня удивило?
1) я не спрашивал агента про уязвимость
2) он понимает, что утечка токена на сервера Anthropic (не в репозиторий с кодом) - это все равно утечка
3) в сообщении мне секрет был замаскирован
4) он предлагает заменить токен мне самому

Лед тронулся)
А ведь тот же SAST\DAST и сканирование на секреты в CI pipeline никто не отменял.
Плюс скилы на проверку безопасности кода.

P.S. Я в посте немного сгустил краски, есть менее известное, но более новое исследование, где процент уязвимого кода у лучших моделей снизился до 24 - https://aclanthology.org/2026.acl-long.1107/
Что лишь подчеркивает мою мысль. Т.е статистика подтверждает изменения к лучшему.

P.P.S. Как бы не прийти к тому, что основной задачей разработчика станет получение и подстановка токенов)

#ai #security

Новости стандартизации AI агентов

Я уже писал про плагины, они же расширения https://t.me/javaKotlinDevOps/614
И из этого поста видно, что стандартизации особой не было. Даже названия два.

И вот, стандарт появился - https://agent-plugins.org/

Стандартизируется структура папок и файлов, структура предлагается такая:

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/
    └── hooks/

Есть возможность добавить в плагин скилы, MCP и описание.

Стандарт можно расширять: настройками в plugin.json и скриптами в com.example.client - хуки, например.
Расширения опциональны, AI агент может игнорировать, если не понимает формат.

Почему стандартизировали только skills и MCP?
Это уже зрелые стандарты, в отличие от хуков, субагентов, команд.
Хотя AGENTS.md тоже стандартизирован, но его поддержки почему-то нет.

И определились наконец с названием - все же плагины. Буду теперь их так называть)

Вот список поддерживающих стандарт AI агентов https://agent-plugins.org/compatible-clients
Из известных для разработки - Cursor, Codex, VSCode и Copilot.
Не хватает Claude Code, Gemini, Qwen.

Резюме - стандартизация неизбежна.

P.S. Но это не решает проблему - как одновременно пользоваться разными AI агентами. Папки то у них разные, и внутри не все стандартизировано. Но тут тоже есть наработки.

#ai #ai_agents

Тренды агентостроения.

Уже был пост про общие команды у топовых coding агентов https://t.me/javaKotlinDevOps/603

Так вот, на примере Claude Code и Codex появился новый кандидат на унификацию.

Встречаем ... /import

Что именно импортируется?
Оба умеют импортировать скилы, файлы контекста (напомню, Claude еще не поддерживает AGENTS.md, поэтому импорт пока актуален), MCP, команды и субагенты.
Codex еще умеет импортировать хуки, настройки, плагины, проекты и чаты. В общем практически все.
Импортируют у друг друга, а еще Claude у Gemini, а Codex у Cursor. Видимо, именно их считают основными конкурентами.
Другие агенты импортировать не умеют, пока что, и я уверен, скоро подтянутся)

Почему решил обратить внимание на эту команду.
1) конкуренция между агентами и стоящими за ними LLM моделями усиливается. Покупка Grok-ом Cursor-а в эту же копилку.
2) стандартизации пока нет - субагенты, команды, хуки, настройки, проекты и история чатов - явные кандидаты
3) как решение для одновременной работы в нескольких агентах - лучше, чем ничего, но не идеально. Т.к. при любом изменении в любом из агентов нужен новый ручной импорт и не факт, что он ничего не поломает.
4) ну а переход от одного агента к другому конечно же сильно облегчается

#ai #ai_agents

Можно ли чему-то научиться у AI?

Базовый ответ - да, т.к. в LLM в процессе обучения попало множество документации и кода, который я, например, никогда не видел.
Да, в сжатом виде, возможно искаженном, но в любом случае это огромный объем знаний.

Но я сейчас про более конкретные вещи.

Например, тесты.
Ключевой момент, что агент пишет десятки тестов на каждую фичу.
Кроме стандартных unit и интеграционных я заметил парочку новых типов.

1) тесты на миграцию БД - включая откат миграции. Простые, накатывают миграцию, проверяют, что новый объект появился\исчез в БД. Польза не то, чтобы большая, но есть. Ломаться часто не должны, т.к. каждый такой тест проверяет свою версию БД.

2) AST тесты - т.е. тесты с синтаксическим анализатором кода, проверяющие, что в методе не делается что-то лишнее. Или делается что-то обязательное. Часто такие тесты можно реализовать передачей в тестируемый метод spy-объекта. Но не всегда. Для меня было открытием. Самому такие тесты писать сложно, AI - примерно также, как и другие. Тесты скорее всего будут хрупкими, т.к. зависят от структуры кода. Но для проверки отдельных ключевых инвариантов проекта, над которым работает множество людей - это лучше, чем JavaDoc.

3) тесты, проверяющие документацию, генерация которой - тоже функция приложения. Например, admin guide. Наличие, формат. Тоже свежая мысль, IMHO. Самому - точно руки бы не дошли до таких тестов, а с AI - почему бы и нет.

Последний кейс пограничный - то же самое можно сделать и скилом. И такие приемочные скилы (они же evals) - это тоже своего рода тесты, просто реализованные в другой форме. Просто они могут не просто вызвать скрипт, а еще и проверять требования к проекту с помощью LLM. И даже в случае LLM, которая недетермирована, это лучше, чем просто пару строк в README.md.

#ai #ai_agents #testing

Заметки про LiteLLM.

Во-первых - это не LLM) Это SDK, предоставляющий унифицированный доступ к LLM провайдерам - типа Spring AI - и AI прокси.

Вот второй use case и рассмотрим.

Для чего нужна прокси?

1) независимый от провайдера подсчет токенов. В теории и стоимости токенов, если это API тарифы. Т.к. у подписок свои абстрактные единицы измерения. Даже если они называются одинаково - кредиты - они не равны между собой и не переводимы в токены.
2) конвертация API, например, Anthropic-OpenAI, для тех провайдеров, кто не поддерживает Anthropic API нативно. На всякий случай - единого API к разным LLM нет, несмотря на некую похожесть. Ну и OpenAI API наиболее распространен сейчас, т.к. они были первые.
3) единая точка для настройки различных провайдеров LLM - URL, секреты, список доступных моделей. И, соответственно, легкое переключение между провайдерами.

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

Теперь собственно заметки:
1) поддерживает подписки Anthropic и вроде бы OpenAI. Ну и API ключи, но это опция по умолчанию. Важно отметить, что все китайцы дают доступ к своим подпискам по API ключу - Qwen, Kimi, GLM. А вот у Claude и OpenAI подписка = OAuth авторизация, которую несколько сложнее проксировать из-за наличия нескольких ключей и их постоянной ротации. А подписки - это наше все, цена в 4-10 раз дешевле, чем при оплате за токены у одного и того же провайдера.
2) документация - отстой
3) есть UI, там можно смотреть логи, статистику, настраивать модели, проверять их доступность. Логировать может как в формате access logs, так и с данными - последнее включается отдельно
4) есть своя база моделей и провайдеров, но ориентация на американский рынок, китайских провайдеров мало
5) большая часть проблем возникает на стыке агента и прокси. Хотя этот момент в документации постарались раскрыть - вот пример отдельная статья по подключению Claude с подпиской https://docs.litellm.ai/docs/tutorials/claude_code_max_subscription

Ну и на примере этой же статьи можно разобрать ряд проблем:
1) в заголовке статьи явно указана Claude Max, что сразу вызывает вопрос о Pro подписке. А она работает)
2) названия моделей. Они устаревшие, при этом они подаются как список поддерживаемых моделей. На самом деле поддерживаются все актуальные, это же обычный прокси.
3) LITELLM_MASTER_KEY - что это, зачем, как генерировать? Генерировать, к слову, также, как и другие виртуальные ключи - из консоли или в UI. Но виртуальные ключи - это способ разделения трафика от разных агентов в отчетах, а зачем нужен мастер ключ?
4) судя по статье для Anthropic - как преднастроенного провайдера - API endpoint указывать не нужно... Это собственно была главная проблема. Пока я не указал url явно - прокся отправляла запросы по подписке сама на себя, выдавала ошибку аутентификации 401, т.к. второй запрос шел с кредами Anthropic, а не со своими. А ошибка аутентификации вводила в заблуждение, т.к. говорила, что не найден ключ для LiteLLM. И более того, эта ошибка была обвернута в (видимо) стандартную ошибку - что-то типа выбранная модель не настроена. Что еще больше вводило в заблуждение, т.к. она же настроена по инструкции) Еще больше ввела в заблуждение весенняя новость о запрете использования подписки Claude в сторонних агентах и контроле агента на стороне сервера. Я уже начал думать, что и прокси зарубили, но нет)

Ну и самое главное на стыке агента и прокси, в моем случае Claude Code:
1) у Claude Code есть 2 режима работы - OAuth и API токены. Переключает их наличие переменной среды ANTHROPIC_AUTH_TOKEN. В целом понятно, но об этом нужно помнить. Секрет LiteLLM либо в ANTHROPIC_AUTH_TOKEN (API), либо в ANTHROPIC_CUSTOM_HEADERS (OAuth). Рабочая схема - завести отдельный shell скрипт для API режима.
2) у Claude Code есть model discovery (включается CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1) - запрос доступных моделей у провайдера, прокси в нашем случае. Но агент запоминает только модели, начинающиеся с claude. Зачем, почему - хз. Но пришлось заводить claude-deepseek и т.д)
3) discovery запускается только для API режима. Это логично. И сохраняет список моделей при дальнейшей работе в любом режиме
4) агент не умеет запрашивать характеристики модели, в частности размер контекстного окна. А от его размера зависит в какой момент запустится автосжатие. А для неизвестных агенту моделей (всех в нашем случае) агент считает размер контекста равным 200к токенов. Все способы настройки выглядят как костыли https://code.claude.com/docs/en/model-config#correct-the-window-for-a-gateway-or-custom-model-id Я завел каждую модель с контекстом более 1m в 2 экземплярах - с суффиксом [1m] и без. Первая удобнее, вторая - дешевле. Отображаются в агенте они криво, но главное - работает.

Stay tuned, об остальном позже.

#ai #ai_agents

Заметки по LiteLLM - вторая часть.

1) в лучших традициях open-source из коробки LiteLLM запускается на 0:0:0:0 - т.е. доступна снаружи. Решается параметром --host 127.0.0.1

2) логирование ошибок на троечку - вместо одного конкретного сообщения они логируют исключения на нескольких уровнях, в итоге часть сообщений об ошибках нужно просто игнорировать. В debug режиме много дублирования - одно и тоже http сообщение появляется в логах несколько раз. Справедливости ради, как раз debug режим позволил мне найти причину ошибки с зацикливанием запроса на прокси.

3) очевидно, чтобы хранить статистику - нужна БД. В инструкции по инсталляции об этом сказано вскользь. Как и том, что кроме отдельной database еще нужно ставить Prisma - Node.js ORM с функционалом миграции БД. Это при том, что приклад написан на Python. И более того - из исходников Prisma нужно собрать бинарь для накатывания миграции. Как это сделать - я выяснил с AI-шкой.

4) цену запросов для неизвестных для системы провайдеров LLM можно вбить прямо в config.yaml - файл настроек. Это хорошо. Плохо то, что после этого LiteLLM все равно будет ругаться на отсутствующие тарифы. Т.е. понять что все работает можно запустив агента и посмотрев статистику по тарифам

5) для подписки Anthropic стоимость считается по тарифам API. На первый взгляд странно. Но с другой стороны - у подписки вообще нет стоимости токена, вместо этого есть оставшийся лимит. А видеть стоимость полезно для оценки насколько выгодна подписка.

6) LiteLLM смешивает понятие формат API и провайдер. Т.е. невозможно задать провайдер Deepseek и формат API Anthropic. В данном примере:

  - model_name: deepseek-v4-flash
    litellm_params:
      model: anthropic/deepseek-v4-flash
      api_base: https://api.deepseek.com/anthropic

оба этих параметра определяются по model: anthropic/
Т.е. либо преобразуем формат в OpenAI (как нативный формат Deepseek) и есть раздельный учет по провайдерам в статистике, либо без преобразований, но все сидят на одном провайдере.

7) есть важная настройка

general_settings:
  forward_client_headers_to_llm_api: true

Она позволяет пробрасывать к провайдеру клиентские заголовки, начинающиеся с x-.
Нужна, например, для пробрасывания заголовков Claude Code со списком поддерживаемых клиентом фичей.
Вроде бы все хорошо, штука полезная.
Но как выяснилось при разборе логов - в процессе пробрасывания есть фильтрация (вырезание) неизвестных для LiteLLM заголовков.
Как я понял, это нужно, чтобы резать заголовки с секретами, которые клиент шлет, а в LLM провайдер передавать нельзя по каким-то (каким?) причинам.
Резали бы только свои заголовки, типа x-litellm-api-key - ключ для аутентификации в LiteLLM.
Это еще пол-беды. Плохо то, что ни отключить, ни настроить эту фильтрацию нельзя.
Сейчас у меня все работает, но учитывая борьбу того же Anthropic с не-родными клиентами - потенциально опасная штука.

Получилось как список проблем, но конечно же есть и плюсы)

#ai #ai_agents

Еще про стандартизацию AI.

Как говорил ранее - стандарта для настроек агентов сейчас нет.
.claude, .codex, .qwen, .gigacode, и внутри структура немножко отличается, как минимум название файла с контекстом и расположение настроек MCP.

Когда же наступит счастье, в смысле стандартизация?
Точно не скажу, но процесс идет)

Пока идет в разных направлениях, увы.
1) https://agentsstandard.com
2) https://dotagentsprotocol.com/
3) https://github.com/jackby03/agentic-collaboration-standard
4) https://github.com/bgreenwell/dotagents

И это я особо не искал)

у всех папка называется .agents, у всех внутри есть папка skills. Далее - разнообразие.

Из интересного - поддержка .agents есть в Kilo Code и Codex.
Из практических рекомендаций - вполне можно уже сейчас хранить скилы в .agents/skills тем более, что и сам формат скилов стандартизирован.
И делать симлинки на родные папки для несовместимых агентов.

#ai #ai_agents

И снова рубрика "Находки из Python".

Как вы думаете, что делает вот такая конструкция?

@pytest.mark.xfail(strict=True, reason = "будет исправлено в задаче TASK-100") 
def test_function():

Она "фэйлит" прогон, если тест пройден)
Зачем это нужно - если из-за частичного рефакторинга некий код перестал работать. И нужно отследить момент починки в следующих релизах.
Т.е. как только чиним код - тест начинает падать, мы снимаем xfail.
Если тест просто "скипнуть" - это можно забыть сделать. Плюс если упала группа тестов - то ее можно пометить одинаковым описанием и убедится, что починились все. Стандартного функционала для этого нет, но можно поиском по проекту.
Видится, что полезно в плане контроля тестов.
Есть конечно радикальный вариант - вообще избегать отключения тестов, но жизнь - сложная штука).

Отдельно про параметр strict.
Если его поставить в false - получаем тест, который не ломает запуск ни при успешном прогоне, ни при падении.
Зачем это может быть нужно?
Для flaky тестов, которые невозможно починить здесь и сейчас.
Тут конечно у меня вопросики, т.к. такое действие - прямой путь к тому, что про flaky тест мы просто забудем.
А в итоге контроль над тестовым набором, наоборот, ухудшится.

Я сразу стал искать - есть ли аналог в Java?

В JUnit из коробки нет, иначе бы этого поста не было)

Но есть в JUnit Pioneer:

@Test
@ExpectedToFail("будет исправлено в задаче TASK-100")
void testFunction() {

Это аналог strict режима. Не strict режима нет, что IMHO к лучшему.

Обе аннотации позволяют задать исключения, с которыми тест должен упасть.

Python вариант также позволяет задать condition:

@pytest.mark.xfail(condition="not config.getvalue('db')")
def test_function(): ...

В Python интерпретатор есть в runtime, в отличие от Java (там в runtime только компилятор из байт-кода в нативный), поэтому это проще сделать.

Мой вердикт - штука полезная.

#python #java #python_gems #unit_tests #junit