Grep побеждает LSP: почему coding-агенты игнорируют ваши более точные инструменты
Grep beats LSP? Why coding agents ignore your fancier tools
Небольшое исследование сравнило, как coding-агенты используют grep (лексический поиск) и LSP-навигацию (семантический поиск). Оказалось, что агенты часто предпочитают grep, даже когда LSP возвращает более точные результаты. Принудительное использование семантического пути снижало успешность задач. Причина — не только в точности, но и в LLM-дружелюбности интерфейса: важно, чтобы результат содержал достаточно контекста и был в знакомом формате. Также имеет значение структура задачи (grep находит и текстовые вхождения, которые LSP пропускает) и возможное обучение модели на привычных паттернах. Вывод: инструменты нужно оценивать в контексте всего харнеса агента, а не изолированно.
Инструмент не является дружественным для модели только потому, что его результаты точны; он должен возвращать достаточно контекста для следующего шага и представлять этот контекст в интерфейсе и формате, который модель может использовать напрямую.
- tonyarkles
Наблюдаю интересную совместную эволюцию в работе с Claude Code. Прошу выполнить задачу, смотрю, что он делает (часто много find, grep и ripgrep), а после завершения спрашиваю, были ли инструменты, которые могли бы упростить работу. Так я узнал о fzf и других (например, notmuch для индексации почты). Затем я беру эти инструменты и разбираюсь, как встроить их в свой рабочий процесс — как в CLI, так и в Emacs.
Мы также совместно создали Python-инструмент, который берёт довольно медленный формат данных, с которым мне часто приходится работать и анализировать, индексирует весь корпус, и для анализа я могу (или Claude Code) выполнить однопроходное преобразование в Parquet, который затем можно запрашивать через DuckDB. Этот инструмент значительно сократил время выполнения разовых аналитических задач, а поскольку это Python CLI на Typer, интерфейс также удобно обнаруживается для LLM-обвязок.
- nomilk
Немного в сторону, но мой LSP-конфиг ломается каждые несколько месяцев. Я больше не утруждаюсь его чинить — открываю LLM в ~/dotfiles и жалуюсь, пока он не заработает, обычно через несколько минут.
Интересно наблюдать, сколько усилий это требует. (Это вызывает у меня гораздо больше сочувствия к себе прошлому; как неуклюжий человек должен был знать и понимать все эти вещи!? Особенно когда я не трогал конфиги несколько месяцев и почти полностью их забыл.)
Чаще всего 10–20 очень маленьких программ работают вместе, чтобы обеспечить желаемый опыт. Количество минут и токенов, необходимых для решения таких, казалось бы, простых проблем, как «Мой LSP не работает», иногда оказывается гораздо больше, чем ожидаешь.
- the_duke
У меня был большой успех с инструментом, который я написал и который может выводить разреженные AST для кода.
https://github.com/theduke/smartedit
С установленным навыком GPT 5.6 обычно автоматически использует его, и это значительно сокращает время исследования кода и расход токенов, например, просто выводя типы и функции в файле без тел и раскрывая их только при необходимости.
(Примечание: у него также есть функция редактирования, которая работает не так хорошо, поскольку модели сильно смещены в сторону распространённых инструментов редактирования при пост-обучении.)
- x-complexity
Настройка LSP опирается на два требования для корректной работы:
(а) Инструменты LSP должны быть компетентно реализованы и согласованы, и
(б) LLM, использующий его, должен быть должным образом обучен работе с LSP в целом.
Использование нативного инструмента, такого как grep, имеет те же два допущения, но
(а) удовлетворяется за счёт стабильности основных функций grep (это хорошо), и
(б) удовлетворяется дополнительно, потому что LLM можно обучить правильно использовать именно grep, а не «двадцатую вариацию grep, обёрнутую в LSP, но достаточно отличающуюся, чтобы создавать неожиданные проблемы».
Кроме того, grep почти всегда присутствует в стандартных окружениях Linux, поэтому его наличие предполагается и на него можно положиться при необходимости.
- brunoborges
Что хорошо сработало для меня, так это наличие SKILL, который предписывает использовать LSP чаще, чем не использовать.
LSP лучше всего работает с зависимостями, которые уже скомпилированы локально, но если весь исходный код доступен, то... да, у меня всё ещё нет однозначного ответа, какой подход лучше.
Но опять же, для уже скомпилированных зависимостей (например, байт-кода Java), без конфигураций LSP агент, скорее всего, попытается извлечь бинарники из JAR-файлов, использовать grep и javap и, возможно, попытаться декомпилировать .class-файлы.