Иногда лучше молчать, чем говорить - продолжение)

Я про auto complete в dev агентах в IDE, который не должен всегда выдавать хоть что-то. А должен выдавать что-то адекватное)

Чтд ... https://habr.com/ru/companies/tbank/articles/1012196/

Суть. Ребята из Т-банка сделали двойную фильтрацию подсказок с помощью LLM+ML с целью выбросить нерелевантные. И в итоге смогли сдвинуться с мертвой точки и улучшить процент принятых подсказок. Этот показатель у них вышел на плато и не двигался несколько лет.

Интересно, что им бизнес разрешил фильтровать не более 5% подсказок чтобы не ухудшить пользовательский опыт. Но даже в этом случае процент принятия увеличился на 5+%. И доверие к фиче, что более важно!

В статье достаточно много деталей реализации - кому интересно, почитайте.

P.S. Интересно, делают ли так другие агенты?)

P.P.S. часть первая https://t.me/javaKotlinDevOps/539

#ai #ai_agents

MCP - новая проблема.

Есть такой стандарт для стандартизированного добавления кастомных тулов - MCP.
Он позволяет разрабатывать тулы на любом языке и выставлять их наружу, для использования агентом, по протоколу JSON-RPS через http (независимый удаленный сервис) или stdio (дочерний процесс).
Вроде бы крутая штука. Если бы не детали реализации)

Главная проблема такая - по стандарту MCP сервер выставляет метод tools/list, возвращающий список тулов в формате name, description, inputSchema.
В чем проблема?
Предположим мы выставляем в MCP API какой-то серьезной системы. Например, Atlassian. Сколько там методов? А какого размера у них inputSchema?
А контекст не бесконечен, более того, после заполнения 50% контекста качество ответов ухудшается.
Т.е. подключив пару тяжелых MCP серверов есть шанс сразу же, с первого запроса, снизить качество работы LLM. А MCP могут и не пригодиться в данном сеансе работы.

Вторая проблема - агент подключается ко всем MCP при старте, вызывая ряд методов (initialize, tools/list) что требует времени.

Слышал по этому поводу мнения, что MCP нам вообще не нужны.
Я бы сказал - такие MCP - да, не нужны. А в целом идея хорошая, не все скилами можно реализовать из-за сложности и вопросов безопасности.

Что делать?

1) несколько профилей агента, с разным набором MCP серверов. Возможно даже lite версию вообще без MCP (Claude Code через --strict-mcp-config --mcp-config '{}', Gemini\Qwen Code через --allowed-mcp-server-names '{}').

2) переписать MCP на skill если это простая прокси к внешнему API. Скил может включать в себя Python скрипты. Агенты такие скилы неплохо пишут.
Скилы сделаны "по уму", там в контекст по умолчанию выставляется только name и description, содержимое SKILL.md и другие файлы добавляются по мере необходимости.
Этап подключения для скилов отсутствует, это просто специализированный промт.

3) lazy load описаний и схем тулов, сделанный на уровне агента. Claude Code, видимо по принципу "Я тебя породил, ..." реализовал это первым https://vc.ru/ai/2864901-claude-code-i-mcp-lazy-loading-uluchshaet-ai-agentov.
Итоги, цитата:

Контекст при старте: экономия до 95%. В одном реальном кейсе — с 51 000 токенов до 8 500.
Точность на Opus 4: с 49% до 74% на MCP-бенчмарках с большими библиотеками инструментов.
Точность на Opus 4.5: с 79,5% до 88,1%.
Максимальное описание инструмента: ограничено 2 КБ

Причем lazy load включается тоже lazy - когда описания MCP tools начинают занимать более 10% контекстного окна. Красиво)

Причем есть предложение дальнейших оптимизаций: https://github.com/anthropics/claude-code/issues/44536
Включая:
а) грузить description скилов тоже лениво. Тут видится противоречие, по стандарту именно description содержит информацию когда подгружать скил. Имя конечно тоже должно быть адекватным, но оно может быть очень коротким.
С другой стороны, если имена нескольких скилов лексически\семантически похожи - ленивая загрузка будет работать, т.к. агент загрузит оба скила и далее уже по описанию выберет правильный.
б) ленивое подключение к MCP - тут понятно
в) профили агентов - это стандартизация решения номер №1. Сейчас это несколько разных папок с агентами, а должны быть - несколько файлов профиля.
г) загрузка тулов\скилов по условию (только при написании тестов, например)
д) динамическая выгрузка
Ну в общем полноценное управление памятью, т.е контекстом)

Есть похожие issues и для других агентов, пока в статусе Open
https://github.com/openai/codex/issues/2335
https://github.com/anomalyco/opencode/issues/17482

4) решение на уровне стандарта MCP. Вот тут все плохо, идут обсуждения, но конкретных предложений нет.
Вот предложение https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1576
Вот еще одно https://github.com/orgs/modelcontextprotocol/discussions/532
Но до реализации дело не дошло.

Вывод - AI агенты активно развиваются.

#ai #ai_agents #mcp #ai_agent_context_management

Хочется добить тему с MCP, точнее о проблеме с загрязнением контекста тулами из MCP.
Схемами тулов, если уж быть точным.

Есть еще одно решение - MCP Progressive Discovery.
Т.е. MCP сервер не сразу объявляет все доступные тулы, а по мере необходимости.
Как это сделать?
Объявляем meta-tool, один.
В его описании указываем все, что умеет MCP.
Как только клиент его вызывает, возвращаем ему что-то типа: "подожди немного и вызови вот такой тул".
Бросаем событие list_changed - это часть протокола MCP, позволяющая динамически менять список объявляемых тулов и оповещать об этом клиентов.
А клиент, соответственно, получив данное событие обновляет список тулов и вызывает нужный.
Будет ли работать на всех агентах - думаю нет, надо тестить. Агент должен поддерживать событие list_changed.
К слову, если объявить у MCP сервера кастомное API слушателя событий, и бросать ему туда события о том, что происходит в агенте - можно даже не ждать, пока он вызовет Meta-tool.
Ну, например, начали работать с git - логично показать соответствующие тулы.

Еще вариант - тот же meta-tool, но заменяющий собой несколько атомарных тулов.
Например, за все операции с git.
Я тут вижу много проблем: теряем Single Responsibility, схемы становятся формальными (объявляем что-то типа response: object), валидация типов будет происходить в коде в рантайме.
Но в каких-то случаях может пригодится. Можно его переформулировать как упрощение API MCP сервера с целью уменьшения размер схем.

#ai #ai_agents #mcp #ai_agent_context_management

Прошла неделя и Auto Mode раскатили на все тарифные планы. Круто!

P.S. Интересно, что там за модель-классификатор для определения опасности команд работает. Есть подозрение - что Haiku, самая дешевая из тройки моделей Claude Haiku-Sonnet-Opus.

P.P.S. А еще одно радостное событие - аналогичная фича появилась в Qwen Code 0.16 https://github.com/QwenLM/qwen-code/releases/tag/v0.16.0

И раз уж заговорил про Qwen Code - они догоняют ведущих агентов (Claude Code и Codex) еще в нескольких моментах:
а) параллельная работа над подзадачами через worktree (там, где это возможно, конечно же)
б) Goal-driven workflow (/goal)
в) /rewind с восстановлением файлов

Причем если с /rewind отставание в 9 месяцев, Auto Mode - 2 месяца, а /goal - меньше месяца. В общем все агенты взаимно обогащаются фичами друг друга. И это хорошо!

#ai #ai_agents

Немножко про стандартизацию CLI агентов.

Сравнил слэш-команды у четверки наиболее популярных\актуальных: Claude\Codex\Gemini\Qwen.

Рабочий цикл:

/init - инициализация контекста - есть у всех
/plan - режим планирования, без выполнения - есть у всех
/goal - установка цели (evals или DoD) - 3 из 4, причем: фича появилась буквально месяц назад
//... тут идет разработка
/status, /context, /stats - просмотр информации о сессии - 4 из 4, но часто разделено на 2 команды - типа /status и /context. Как по мне - лучше слить в одну, я их путаю)
/compact (/compress) - ручное сжатие сессии - все, но терминология разделилась
/memory (/memories) - просмотр контекста проекта - 4 из 4, но Codex не смотрит на тренды)
/diff - просмотр незакоммиченных изменений - тут пока слабо, 2 из 4, но есть git и IDE
/resume - возобновление рабочей сессии - 4 из 4
/review - собственно ревью - 3 из 4, где-то есть 2 варианта - локально и на GitHub, где-то реализовано как скил с возможностью быстрого вызова
/clear (/new) - новая сессия - есть у всех

Итого - есть путаница с информацией о сессии, не везде есть /diff, дилемма /compact vs /compress. Т.е. 7 из 10 стандартизированы, по 3 наблюдаем.

Настройка оснастки (harness):

/model - выбор модели - у всех
/skills - просмотр и вызов скилов - у всех
/mcp - просмотр и включение MCP серверов - у всех
/agents - просмотр и добавление субагентов - 3 из 4, как ни странно Codex отстает, все работа с субагентами через конфиги
/hooks - просмотр и редактирование хуков - 3 из 4
/tools - список встроенных тулов - 2 из 3
/plugin(s) (/extensions) - работа с плагинами, включая установку из marketplace - 4 из 4, но терминология не выработалась. 3 разных варианта

Итого - практически стандарт, за исключением tools и терминологии plugin vs extension.

Безопасность:

/permissions - разрешения для тулов - 3 из 4

База:

/exit (/quit) - все
/theme - все
/vim - 3 из 4, для любителей Linux, но Claude его удалил, и это может стать трендом
/help - 3 из 4
/bug (/feedback) - все, Codex опять не в тренде)

Тут тоже все стандартизируется.

Удобство работы:

/copy - копировать последний ответ в буфер - все, и штука полезная, но малоизвестная. Claude даже n последних позволяет.
/btw (/side) - by the way или side вопрос - возможность что-то уточнить не открывая новое окно во время работы агента - 3 из 4
/recap - краткое резюме по сессии - 2 из 4
/statusline - настройка собственно statusline, как это принято в Linux - 3 из 4

Даже на таких мелочах и то стандартизация)

Передний край, развитие - фоновые задачи и ветвление:

/fork - создание параллельной сессии для исследования темы - 2 из 4
/rewind (/resume) - откат либо в рамках текущей сессии, либо убить форк - 3 из 4
/loop - запуск по расписанию в сессии, не путать с циклом - 2 из 4
/tasks (/bashed, /ps) - просмотр фоновых задач - 3 из 4

Общий итог - стандартизация явно вырисовывается.

#ai #ai_agents

Не могу пропустить новость про workflow в Claude Code.
Вот эту https://claude.com/blog/introducing-dynamic-workflows-in-claude-code

Для начала хотелось бы отметить некую иронию ситуации.
Принцип агентности в AI гласит, что система может считаться AI агентом, если сама принимает решение на основе полученных данных - от пользователя, RAG, тулов, собственно данных в модели.
А суть нововведения в том, что моделью при наличии в промте слова workflow создается стейт-машина, динамическая, под каждую задачу своя, в виде JS скрипта.
И в дальнейшем этот скрипт оркестрирует субагентов.

Т.е. забираем свободу у LLM, все контролирует скрипт)

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

Почему мы к ним пришли?
Я бы обратил внимание на два момента:
1) вот эта новость https://habr.com/ru/news/1041104/ Удивляет 500 млн $ и неизвестная компания. И упоминание Microsoft в следующем абзаце)
2) Фраза "Dozens to hundreds of agents per run".
Т.е. на больших задачах, если запускать десятки субагентов и никак их не контролировать - цена ошибки возрастает.
При этом и использование workflow потребует больше токенов, как собственно на реализацию state machine, так и на дополнительные контролирующие фазы.
Но видится, что на больших задачах это имеет смысл. Переплатить фиксированный X, чтобы не получить "большой ком грязи" стоимостью Y, который придется выкинуть.

Альтернативный вариант - бить на мелкие задачи и решать их последовательно - неплох, но трудозатратен по времени. Хотя все равно быстрее, чем без использования AI.

Ну и ключевой вызов для использования workflow - навыки многопоточности.
При разработке обычных бизнес-приложений они часто не нужны: веб-сервера, producer\consumer часто делают все за нас.
А тут навык нужен не для кода, а для создания для правильного промта агенту, чтобы эффективно распараллелить части workflow.
Такие дела.

P.S. Жаль пока только для Max+ тарифов. Ждем на Pro и в следующей версии Qwen Code)

P.P.S. Фича полезная, но не всегда. Не всегда есть достаточно большие задачи с понятным ТЗ, чтобы имело смысл проектировать под них workflow.

#ai #ai_agents

В AI разработке только и разговоров что об evals)

Что это за зверь такой?

По сути это приемочные тесты, наличие которых - базовое отличие разработки с AI от вайб-кодинга.
Что это на практике?

Если речь про архитектуру и аналитику:
1) проверки формата полученного артефакта - структура файлов, структура разделов внутри,
2) наличие обязательных элементов
3) единообразие терминов
4) ограничение по размеру
5) банально правильная нумерация разделов и ссылок

Если речь про разработку - сразу стоит подсветить важный нюанс.
Агент сам пишет тесты и даже следует TDD (см. предыдущие серии)
И поэтому рассматривать наличие тестов как eval - неправильно, мы их содержимым особо не управляем.
Но при этом тесты - лучшие eval.
Поэтому в самой постановке задачи должны быть проверяемые требования, которые превратятся в генерируемые агентом тесты.
unit или интеграционные - не критично, зависит от уровня, на котором можно проверить работу фичи.
И вот наличие таких приемочных тестов и их прохождение - это уже evals.

Также evals - это успешные проверки линтеров (Checkstyle к примеру) и внешних статических анализаторов кода (SonarQube, Checkmarx, ...).
Сюда же процент покрытия тестами нового кода из SonarQube.
С линтерами есть важный момент - агент в теории может поменять их настройки. Это запрещается через хуки, есть такой хук в ECC плагине https://t.me/javaKotlinDevOps/610
Можно втащить к себе в проект как часть плагина или просто позаимствовать адаптировав под свои файлы настроек.

Еще в качестве evals могут выступать:
- запрет на использование тех или иных библиотек\классов (по всему проекту или в отдельных модулях)
- запрет циклических ссылок (spring beans, ArchUnit)
- запрет на "ломающие" изменения в API или БД
- наличие JavaDoc в определенных местах
- требования к SQL скриптам, например, наличие CREATE INDEX CONCURRENTLY
- время выполнения вызова
...
В общем все, что выполняется достаточно быстро и без сложных интеграций, имеет смысл сделать evals и проверять пораньше.
Ну и один из самых важных evals - соответствие реализации постановке.
В целом все это уже должно было проверяться в CI pipeline с одним исключением, о котором ниже.

Как оформить evals? Как и все остальное - в виде скила.
И тут еще один важный нюанс.
Любую проверку можно выполнить 3 способами:
- запуск кода (тест или shell скрипт)
- просьба сделать проверку агенту
- запуск нового CLI агента в headless режиме

Всегда, когда это технически возможно, стоит использовать первый вариант.
Почему?
AI все-таки по природе своей ленив - любит быстро достигать результата.
Т.е. на явную просьбу что-то проверить в скиле он может сказать: "все ок"- ничего не проверяя. Или даже написать - проверь сам.
Да, он может "подшаманить" скрипт проверки, чтобы пройти дальше.
С последним нужно бороться хуками с запретом на редактирование.
А с первым как раз помогает "хардкод" проверки.
А еще вызов LLM всегда дороже по времени.

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

И вот как раз возможность проверки кода LLM моделью и есть важный бонус, которого ранее не было в CI pipeline.
Но, повторюсь, использовать с осторожностью)

У кого был опыт написания evals для агента - делитесь, что еще можно проверить?

#ai #harness #ai_agents

Расширим AI агента?)
Я про extension, они же plugins.

По сути это способ упаковки обвязки - скилов, команд, субагентов, промтов, хуков и MCP серверов.

Единого стандарта нет. Да что там, названия даже единого нет) Но делает плагин плагином по сути один файлик с метаданными. Структура папок задается в этом файле. Поэтому совместимость обеспечивается созданием N таких файликов под каждого агента.

Есть ещё нюансы по возможному содержимому. Рассмотрим на примере большой тройки агентов - Claude Code, Codex, Gemini CLI.
Скилы, MCP, хуки разрешают все.
У Codex нет субагентов.
Возможность упаковать файл контекста (AGENTS.md) есть только у Gemini CLI и его наследников.
А вот у Claude куча уникальных возможностей:
1) можно упаковать скрипты, которые будут добавлены в PATH для команд плагина,
2) добавить monitors https://code.claude.com/docs/ru/plugins-reference#monitors - интересная штука для наблюдения за внешним процессом, например, через логи, и выдачи сигналов в агента
3) указать тему. Да, у AI агентов тоже есть темы.
4) добавить LSP сервера (Language Server Protocol). По сути это протокол для работы с standalone AST парсером. Агент шлёт кусок кода и задачу, LSP сервер парсит код и возвращает ответ.

Может возникнуть вопрос - а как внутрь расширения запихнуть MCP сервер, это же не промт, а Node.js или Python пакет? Есть такие штуки, как npx (uvx) - скачивают и запускают пакет без инсталляции.

Но вернётся к главному - зачем использовать плагины?
1) единица деплоя для распространения связанного набора компонентов.
2) единый набор компонентов для нескольких проектов, например, всех проектов на Java
3) пакетное включение/выключение компонентов агента одним ключом командной строки
4) кладём все плагины в git - получаем версионирование своего harness. Если захотеть - всегда можно понять с какой обвязкой написана та или иная строчка кода

Итог: использую сторонние (superpowers), создаю свои и всем рекомендую

#ai #ai_agents

Пару слов про хуки в AI агентах.

Набор событий у каждого агента свой.
При этом тут тоже идет унификация и базовый набор хуков, кажется, определился:
* PreToolUse
* PostToolUse
* SessionStart
* UserPromptSubmit - начало обработки пользовательского запроса агентом
* Stop - его завершение.
Я про большую тройку (Claude, Codex, Gemini и примкнувшего к ним Qwen Code).
Тут надо отметить, что PreToolUse/PostToolUse вызываются на любой tool, включая вызов bash, редактирование файла и даже TodoWrite.

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

Для чего можно использовать?
Мои варианты:
1) свой механизм разрешений (PreToolUse)
2) блокировка сессии после проверки среды (SessionStart, только у Codex\Claude)
3) подгрузка контекста в сессию, в т.ч. после ее сжатия (SessionStart)
4) телеметрия, аудит (PostToolUse, Stop)
5) валидация промта пользователя (UserPromptSubmit)
6) валидация ответа модели с возможностью его перегенерации (Stop)
7) замена тула при неправильном ответе (PostToolUse)
8) проверка формата данных, например, при записи в файл (PreToolUse)
9) запуск любых линтеров при окончании работы агента (Stop, SubagentStop)
10) запрет на изменение определенных файлов (PreToolUse)
11) просьба агенту обосновать, зачем он выполняет то или иное действие (PreToolUse)
12) запрет на переход к следующему шагу если не выполнены необходимые действия на текущем, реализация state machine (Stop, SubagentStop)
13) вывод информации о текущей сессии, подсказки о сжатии или начале новой (Stop)
14) кэширование результата работы тулов, включая MCP (PreToolUse)
15) обогащение промта пользователя (UserPromptSubmit)
16) независимое хранилище истории диалогов (PostToolUse, Stop)
и наверняка многое другое, что мне не пришло в голову)

В общем мощный механизм.
Можно использовать готовые хуки из плагинов, а также есть поле для их доработки и создания своих.

#ai #ai_agents

compact vs clear

Я снова про AI-шку и две типовые команды у большинства агентов /compact vs /clear.
Первая сжимает контекст, вторая начинает новую сессию.
По сути это два способа борьбы с энтропией - раздутием размера контекста и последующим ухудшением качества ответов агента.
А ухудшается оно по статистике где-то в районе 50% контекста.
Ну и борьбы со стоимостью тоже, если вы сами платите за модель)
Т.к. весь контекст при каждом запросе уходит на сервер, хоть и считается по особому тарифу (cashed).

Если запустить /compact в Claude Code - удивляет (неприятно) скорость его работы. У меня это обычно более минуты, ближе к 2.
Почему так - сжатие стало умным, т.е. вся история сессии скармливается LLM, и она выбирает важное. Можно указать это важное, явно передав текстом /compact "сохрани план работ и архитектурные требования".
Для сжатия похоже используется та же модель, что и сейчас в сессии - по крайней никакой другой информации я не вижу.
Это точно есть в Claude Code, и думаю скоро будет у всех)
К слову, есть готовые хуки, определяющие оптимальную точку для /compact с простой, я бы даже сказал "наивной" реализацией: создается PreToolUse hook для операций Edit|Write, счетчик, как только число вызовов превышает порог (50 по умолчанию) - пишем в контекст рекомендацию вызвать /compact.

Но вернемся к сжатию. Умное - это хорошо, но вместе с этим долгое и более дорогое. Плюс что-то важное все равно может пропасть из контекста.

К чему я веду - /compact видится костылем, помогающим, если вы неправильно декомпозировали задачу (story). Или пошли на поводу у модели, когда она предложила добавить в план работ еще А, Б, С... Решив, что раз это дешево - почему бы не сделать сразу)
А ведь преждевременную оптимизацию и YAGNI никто не отменял.

Итог: навык декомпозиции задач с AI остается таким же важным, как и был без нее. Бейте задачи на части, план работ и текущее состояние храните в файле (а SDD фреймворки так и делают), чаще вызывайте /clear.

#ai #ai_agents

Я не рассказал про ключевой вопрос по SDD - где находится source of truth?

До сих пор источником правды был код. По понятной причине - именно код работает на ПРОМе, не аналитика. Аналитика лежит в wiki и медленно, но верно расходится с кодом.
Сейчас мы этот разрыв пытаемся убирать, и кладем аналитику поближе к коду.

Но разрыв остается, т.к. LLM при разработке фичи условно правит 3 места:
1) спеки
2) код
3) документацию к коду
Тот факт, что правка идет в одной сессии (на одном контексте) увеличивает вероятность, что все три источника будут одинаковы.
Но не доводит ее до 100%.
А главное - зачем нам три источника?

Сложный вопрос.
Где спека точно нужна?
Спека на входе агента - да, т.е. в течение рабочей сессии.

Нужна ли она далее - вопрос?

Накину аргументы за спецификацию как источник правды:
1) спецификация упрощает совместную работу над фичей для ВП, аналитиков, разработчиков и тестировщиков. Тут наверное не поспоришь, пока в команде есть все эти роли.
Разве что тестировщики сейчас автоматизируются и идут "в код".
2) актуальная спецификация может дать возможность выкинуть код и переписать сервис с нуля. В целом да, но вообще говоря спеку можно вытянуть из кода и JavaDoc.
3) агенту (и человеку) проще дорабатывать проект. Под вопросом - при хорошо структурированном коде и наличии документации там, где она нужна. А еще индексаторы кода есть.

Про минусы я уже сказал - массовое нарушение DRY.
Почему массовое?
Потому что по факту источников больше, чем три. Новый реализуемый алгоритм появляется в:
1) коде
2) тестах
3) JavaDoc
4) spec.md
5) design.md (здесь и далее в терминологии OpenSpec)
6) proposal.md (верхнеуровнево)
7) tasks.md (на своем шаге реализации)
8) в файле с tasks от superpowers.md (при использовании superpowers)
9) AGENTS.md (такое возможно, если алгоритм влияет на требования к остальному коду. или в виде описания алгоритма как комментарий к параметрам вызова сервиса)
10) какой-нибудь скил валидации, проверяющий, что алгоритм вызывается там, где должен вызываться

И если мы поменяли название алгоритма - где его менять? Везде? Или исторические документы не трогаем? А если их кто-то прочитает?
Ясно, что это решается отдельным скилом синхронизации, но что делать с DRY?

Я пока окончательного ответа для себя не нашел, но точно понятно, что дублирование надо уменьшать.

code or not code, вот в чем вопрос?

#ai #ai_agents

Минутка удивления способностям 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 агентов

Я уже писал про плагины, они же расширения 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