Comments 22
Я думал, именно в таком виде агенты и работают с IDE. Похоже, есть ещё много работы по нормальной интеграции и организации работы агентов.
Да, такой подход работает для любого софта, который позволяет собрать себя из исходников или расширить плагинами. Если у инструмента есть API — внутренний, плагинный, какой угодно — этого достаточно, чтобы вытянуть из него нити управления наружу и сделать доступным для агента. По сути, это универсальный рецепт пульта дистанционного управления для чего угодно.
Интересный подход. По сути это то же самое что MCP, только через CLI
Да, с обычным CLI не нужно сочинять и расписывать все эти фильтрующие/лимитирующие параметры для каждой команды с теоретически большим выводом -- агенты обычно сами подстраховывают tail/head-ами. С CLI не нужен MCP Inspector и т.п. отладочные инструменты. CLI есть у докера, авс, сентри, гитхаба и т.д. --- и агенты с ними прекрасно ладят. Просто MCP создан для немного для другого уровня интеграции (когда у агента нет баша), а когда терминал есть -- то CLI-утилита/скрипт это более подходящий способ расширения функционала агента: нет проблем с раздутым описанием инструментов -- не рассказал агенту - он и не знает ничего, а когда задача требует навыка -- то просто используешь скилл, в котором описано, как пользоваться твоими CLI/скриптами. Все просто.
Интересно, спасибо. Откликнулась мысль, что агент зря тратит контекст на то, что IDE уже умеет делать. Есть ли в планах поддержка безопасных рефакторингов через CLI, чтобы перед применением можно было посмотреть preview изменений?
А я вам больше скажу. Я даже вручную иногда прогроммировываю!
А почему бы не запустить Language Server (jdt или любой другой) и натравить агента на его API ?
Вот реально. Есть же куча Language Server. В том же VS Code сама IDE фактически через него работает. В чем проблема (если правда есть) его "дернуть"?
Да и насчет "грепает" несколько странно. Даже если не говорить про встроенные индексации (Antigravity и т.п.), даже сторонние расширения такое давно уж делают. В тот же RooCode уж больше года, мне кажется, я подключение к embedding (причем на домашней машине, ресурсов-то не тратится практически) и Qdrant активировал.
Неужто все равно катастрофически неэффективно? Или это особенность Eclipse?
Спросил гпт, говорил в зависимости от запроса использует разные техники. Попросил его найти использование метода в Swift и он искал грепом и вот что потом написал когда спросил про AST/LS
Tools actually used
• grep
• find
• nl
• sed
Not used
• SourceKit
• AST inspection
• compiler index / build system
I did not need SourceKit or AST here because the method name is specific enough that a repository-wide text search produced a complete, low-noise result set.
В Claude Code несмотря на буквальную формулировку в его системном промте: "Do NOT use the Bash to run commands when a relevant dedicated tool is provided" - я регулярно вижу, как модель скатывается к sed, awk, echo >, cat <<EOF и разным самопальным python-скриптам, когда внезапно нарывается на проблемы со вставкой своих патчей или вопросы с кодировками/переносами строк. Это очень раздражает ещё и потому, что клод код тогда требует явного подтверждения действия от пользователя. А с его однопотончной хук моделью это означает, что и другие агенты в это время ждут в очереди, что бы продолжить работу. Из-за этого невозможно отойти от монитора даже на пару минут. Один запутавшийся агент блокирует всех остальных.
Согласен, та же история - по логам постоянно юзает греп, ни разу не видел чтобы лез в анализ скомпилированного/промежуточного кода, всегда грепает. Мне понравилось, что сделал автор статьи, но у себя со Swift не смог повторить - очень сложно вытащить нужную информацию из SourceKit + нужно всегда синхронизировать/актуализировать индексацию при каждом запросе, хотел глянуть SLP так там вообще мрак самому всё писать и разбираться. Пет проект небольшой, пока и грепа хватает, но для большого видимо нужно прикручивать что-то помощнее что ниже писали про Serema MCP.
Serena mcp
Плюсанул. Это движение в правильном направлении, особенно, когда речь идет про полную автономность агентов.
Но для парной работы в специализированных средах -- и, особенно, когда вокруг все LLM-вендоры борются с тем, что бы их подписку не использовали в "самопальных" решениях и конкурентах (Opencode, OpenClaw и т.д.), когда уже начата открытая война с создатеями альтернативных агентных сред (зачастую гораздо более качественных, чем тот же Антигравити или Клод Код) -- не получится придумать ничего более естественного, чем CLI-шлюз к процессу твоей программы.
И дело ещё в cвободе, неохота оказаться в ситуации, как с ремонтом тракторов John Deere/заправкой картриджей HP -- когда ты, купив вещь, становишься рабом её дилера. И не можешь там даже лампочку поменять, без риска потери гарантии.
Спасибо за отзыв. LSP (или любой другой отдельный вычислительный процесс на стороне) был отброшен на ранней стадии — он не подходил под задачу. Мне нужно было вытаскивать информацию из процесса именно моей IDE. Нужны были именно её маркеры компиляции, её чекстайл, её тест-лаунчер и так далее. Отдельный Language Server — это отдельный индекс, отдельный build state, и он неизбежно рассинхронизируется с тем, что вы видите в IDE.
LSP — слишком низкоуровневая вещь, заточенная под редактор. Это протокол не для людей и не для агентов. textDocument/references с позиционными координатами в JSON-RPC — попробуйте это отдебажить руками. Даже если вы его как-то подключите — не факт, что ваша модель захочет этим пользоваться и не соскочит на свои фолбэки после первой же неудачи. Кто хоть немного поработал с кодинг-агентами — тот сразу поймёт, о чём речь. Модель нужно ещё убедить, что данный инструмент лучше и полезнее, чем то, на чём её тренировали. Агент обучен на grep/find, он к ним тянется рефлекторно. CLI с понятными командами (jdt refs, jdt err) имеет куда больше шансов быть подхваченным моделью, чем LSP JSON-RPC.
Интересный кейс. Как специалист по ИБ, сразу задумываюсь о поверхности атаки при такой глубокой интеграции агента с IDE через внешние API. Если агент получает доступ к управлению "извне", это создает дополнительные риски внедрения вредоносного кода через промпты или компрометацию самого канала управления. Кто-нибудь уже задумывался о песочницах для таких агентов внутри IDE?
https://code.claude.com/docs/en/discover-plugins
Есть же плагин jdtls-lsp
Разве его недостаточно?
jdtls-lsp -- полезная вещь для автономных сценариев, когда агент работает один, без IDE, с чистого листа. Но в парной работе, когда Eclipse уже запущен и настроен -- форматтер, чекстайл, тест-лаунчер, свои чекеры, плагины -- всё под проект. Поднимать рядом ещё один headless Eclipse с отдельным индексом потом избыточно. Это как третья нога при ходьбе.
Всё, что даёт LSP-плагин (диагностика, навигация), в IDE уже есть и работает точнее, потому что это ваш настроенный workspace. JDT CLI Bridge просто выставляет это наружу.
К слову, про jdtls-lsp -- типичная ситуация: https://github.com/anthropics/claude-code/issues/17643 — на Windows плагин не работает из-за обратных слешей в file:// URI. Баг открыт, подтверждён множеством пользователей, воспроизводится до последней версии -- и тишина. Один из комментаторов https://github.com/anthropics/claude-code/issues/17643: "These are not edge cases, these are basic smoke test type defects." При 5500+ открытых issues в репозитории Claude Code ждать починки можно долго — проще сделать самому.
jdt внутри Explore субагента был бы идеальной связкой. Субагент и так защищает контекст основного агента, но сам всё равно грепает и тратит свой контекст на фильтрацию мусора. С jdt субагент получает 8 точных результатов сразу и возвращает основному агенту сухой остаток
Есть ещё неочевидный, ускользающий от внимания большинства момент про стоимость. Каждый tool call агента отправляет в API весь накопленный контекст -- все предыдущие запросы и ответы. Первый вызов -- 3k токенов, десятый -- уже 30k, двадцать пятый -- 65k. Это арифметическая прогрессия, сумма растёт квадратично от числа итераций.
Prompt caching снижает стоимость пересчёта, но за передачу кэшированных токенов всё равно нужно платить. Квадратичность остаётся. O(n²) живёт в протоколе, это следствие stateless HTTP-API и накопления контекста. Чем больше итераций нужно инструменту -- тем дороже каждый следующий шаг.
Забить итерациями до отсечки окно 200к Opus-a обходится примерно в 30 у.е., а сделать то же самое в 1M окне -- это уже 700 у.е.. Разница по бюджету ×23, а не ×5. Просто сейчас вендоры активно субсидируют расходы пользователей. Но эта щедрость не вечна и не бесконечна.
Доброго дня, я не профессиональный программист но тоже хотел бы сэкономить токены на вайбкодинге пет проектах.
Облачные IDE вроде Google Antigravity избавлены от такой проблемы?
И какие есть ещё более оптимизированные инструменты без сложных настроек? Заранее благодарю!
IDE понимает ваш код. AI-агент — нет. Это можно исправить