Тоже использую диспетчеров, но думаю оба способа друг друга дополняют. Диспетчеру сжатие может быть и не нужно, он принимает стратегические решения и мусорный контекст ест редко, а вот модель-разработчик вполне себе может в процессе диагностики чего-то лишнего набраться. Всё конечно зависит от типа задач и композиции, но по сути выдать дополнительный инструмент “compact” тем агентам, которым он может пригодиться лишним не будет.
А что за автоматизации? У меня во всех проектах Justfile с разными часто-повторяемыми рецептами. Чтобы все проверки качества запустить, модели нужно вызвать лишь just check, который в параллель уже 50 команд запускает. На подготовку git workgree и ветки тоже свои рецепты. Но, честно говоря этого не хватает. Хочется прикрутить какой-то честный движок запуска workflow. Присматриваюсь к microsoft/conductor, но не хочется, чтобы движок сам запускал модели. Скорее, чтобы модель имела опорный механизм в виде движка и знала что дальше делать и чтобы некоторые шаги запускались автоматически после перехода процесса в новый узел выполнения. Возможно получится siemens/wfx как-то приспособить. Все сейчас пилят столько нового инструментария вокруг ИИ-агентов, что едва успеваешь за всем этим следить, не то чтобы попробовать.
Смысл плагина как раз в том, чтобы дать модели самой вызывать компактизацию, причём не всей переписки, а только её части. Допустим после полезной ориентациина было 30к, а потом модель начала диагностику и наелась логов, но оказалось, что это был тупиковый путь, а контекста уже 100к. Перед тем как переходить к следующей попытке модель вызывает сама компактизацию части нижних сообщений и после этой компактизации она будет видеть изначальные 30к + столько, сколько напишет сама в суммаризации.
Интересно, насколько в борьбе с этим может помочь плагин, который даёт модели возможность суммаризировать часть контекста. Модель делает запрос к логам, понимает, что там мусор и ничего полезного и сразу суммаризирует результат этого “хода” и продолжает уже с этими знаниями. Какое-то время использовал opencode-dynamic-context-pruning, но ничего не замерял и не добавлял инструкции убирать из контекста подобный мусор. Надо будет попробовать.
А что если вместо PHP-миграции просто сделать mysql < result.sql? Побыстрее должно быть и за лимиты беспокоиться не нужно. Вот бы какой-то готовый скрипт под вычистку SQL иметь, а ещё автоматизировать сбор SQL через консольную утилитку вроде, чтобы не заниматься скучным переключением DBDebugToFile и нажатием кнопки в админке. С таким инструментарием и на проектах поменьше подход вполне сработает.
Звучит как будто подключить на Битрикс проект phpstan экстремально просто, но если вы в коде используете, скажем, метод add наследника DataManager, то можете упасть с ошибкой от phpstan говорящей о том что он не знает этого DataManager. Потом окажется, что в ядре этот DataManager не настоящий, а class_alias'нутый. В итоге приходится через bootstrap-файл phpstan'а вызывать все эти alias'ы после classmap'инга всех нужных модулей.
Ещё одной большой болью является тот факт, что в ядре масса методов, phpdoc'кументация которых врёт. Вот прямо врёт - говорит что возвращает один тип, а по факту возвращает всегда другой. phpstan поддерживает stub-файлы. Ура? Нет.
Why is PHPStan complaining about “Class not found” in a stub file?
Stub files are analysed independently from the rest of your codebase. This means that any type they’re referencing must also be present as a stub, even if you don’t want to override any of its PHPDocs.
В редком случае можно разместить один файл в stub'ы и всё. В реальности, одно за другое целпяется и чуть ли не всё ядро надо описывать. Для решения этой проблемы можно воспользоваться php-stubs/generator, но там тоже начинают возникать проблемы одна за другой, в итоге так это и не поборол.
А что касается pre-commit хука, это только на первый взгляд кажется хорошей идеей. А вот если phpstan думает 5 минут, то становится как-то печально. К тому же, для многих типовой сценарий - коммитить через некий GUI, например в PhpStorm и там рассматривать большие полотна отчёта об ошибках не так уж и удобно.
Тоже использую диспетчеров, но думаю оба способа друг друга дополняют. Диспетчеру сжатие может быть и не нужно, он принимает стратегические решения и мусорный контекст ест редко, а вот модель-разработчик вполне себе может в процессе диагностики чего-то лишнего набраться. Всё конечно зависит от типа задач и композиции, но по сути выдать дополнительный инструмент “compact” тем агентам, которым он может пригодиться лишним не будет.
А что за автоматизации? У меня во всех проектах Justfile с разными часто-повторяемыми рецептами. Чтобы все проверки качества запустить, модели нужно вызвать лишь
just check, который в параллель уже 50 команд запускает. На подготовку git workgree и ветки тоже свои рецепты. Но, честно говоря этого не хватает. Хочется прикрутить какой-то честный движок запуска workflow. Присматриваюсь к microsoft/conductor, но не хочется, чтобы движок сам запускал модели. Скорее, чтобы модель имела опорный механизм в виде движка и знала что дальше делать и чтобы некоторые шаги запускались автоматически после перехода процесса в новый узел выполнения. Возможно получится siemens/wfx как-то приспособить. Все сейчас пилят столько нового инструментария вокруг ИИ-агентов, что едва успеваешь за всем этим следить, не то чтобы попробовать.Смысл плагина как раз в том, чтобы дать модели самой вызывать компактизацию, причём не всей переписки, а только её части. Допустим после полезной ориентациина было 30к, а потом модель начала диагностику и наелась логов, но оказалось, что это был тупиковый путь, а контекста уже 100к. Перед тем как переходить к следующей попытке модель вызывает сама компактизацию части нижних сообщений и после этой компактизации она будет видеть изначальные 30к + столько, сколько напишет сама в суммаризации.
Интересно, насколько в борьбе с этим может помочь плагин, который даёт модели возможность суммаризировать часть контекста. Модель делает запрос к логам, понимает, что там мусор и ничего полезного и сразу суммаризирует результат этого “хода” и продолжает уже с этими знаниями. Какое-то время использовал opencode-dynamic-context-pruning, но ничего не замерял и не добавлял инструкции убирать из контекста подобный мусор. Надо будет попробовать.
А что если вместо PHP-миграции просто сделать
mysql < result.sql? Побыстрее должно быть и за лимиты беспокоиться не нужно. Вот бы какой-то готовый скрипт под вычистку SQL иметь, а ещё автоматизировать сбор SQL через консольную утилитку вроде, чтобы не заниматься скучным переключением DBDebugToFile и нажатием кнопки в админке. С таким инструментарием и на проектах поменьше подход вполне сработает.Разработчик jscpd уже сам его переписал на Rust: https://github.com/kucherenko/jscpd/tree/master/rust Crate: https://crates.io/crates/jscpd
Звучит как будто подключить на Битрикс проект phpstan экстремально просто, но если вы в коде используете, скажем, метод add наследника DataManager, то можете упасть с ошибкой от phpstan говорящей о том что он не знает этого DataManager. Потом окажется, что в ядре этот DataManager не настоящий, а class_alias'нутый. В итоге приходится через bootstrap-файл phpstan'а вызывать все эти alias'ы после classmap'инга всех нужных модулей.
Ещё одной большой болью является тот факт, что в ядре масса методов, phpdoc'кументация которых врёт. Вот прямо врёт - говорит что возвращает один тип, а по факту возвращает всегда другой. phpstan поддерживает stub-файлы. Ура? Нет.
В редком случае можно разместить один файл в stub'ы и всё. В реальности, одно за другое целпяется и чуть ли не всё ядро надо описывать. Для решения этой проблемы можно воспользоваться php-stubs/generator, но там тоже начинают возникать проблемы одна за другой, в итоге так это и не поборол.
А что касается pre-commit хука, это только на первый взгляд кажется хорошей идеей. А вот если phpstan думает 5 минут, то становится как-то печально. К тому же, для многих типовой сценарий - коммитить через некий GUI, например в PhpStorm и там рассматривать большие полотна отчёта об ошибках не так уж и удобно.