Сомневаюсь что такие решения могут быть прям универсальным (а иначе всё и везде уже было бы автоматизировано), максимум покрывать какой-либо набор наиболее частых сценариев. В плане универсальности возможен разве что подход как в упомянутом n8n (построй всё сам, вот тебе кирпичики-лего и станок для производства своих кирпичиков (возможность писать свои скрипты)). А так это появилось до агентских систем, в данном случае триггером является не модель, да и сама она как правило ничего не вызывает. Ну и из этого стоит понимать, что это тоже не для всех сценариев удобно/подходит. (Это всегда должны быть строго повторяемые задачи, эпизодические, например фикс/поиск багов тут не развернуть, слишком много вариантов развития событий, общая траектория если есть, то строгой последовательности действий - нет. В данном случае как ни крути, а свободу нейронке давать надо. Но вот если говорить про документирование - более чем возможно, это вполне повторяемая задача, со строгой последовательностью действий. И да, можно построить через n8n).
Если модель не шибком умная, то там какие бы ограничения не городили вокруг неё, она один хрен по своему будет до талого пытаться делать. По опыту в ответ на жёсткие ограничения из вне они реагируют крайне неадекватно: "мне вернулся отказ, с чётко расписанной причиной и инструкцией как это преодолеть?! В мусор его! Попробую другой способ `bash rm -rf`". В целом слабую модель вот изначально как запустил, так её лучше после этого не трогать и не дышать в её сторону, как правило то как она сама сделает - выйдет лучше, чем если её наставлять на путь истинный. Любую правку поведения она либо вообще не вдупляет потом, либо ставит в абсурдистский абсолют.
Если рассматривать жёсткий сценарий - лучше запускать разными сессиями с абсолютно разными задачами и промптами под этот конкретный сценарий, тогда да, такое имеет место быть. Это в целом достаточно легко, что обычными скриптами делается, что через систему суб-агентов. Но надёжнее всё же кодом. Запускаешь 1 раз, потом хоть той же нейронке с чистым контекстом на валидацию ответ даёшь, потом пихаешь дальше.
Тут дело не в том, что они умеют, а в том сказал ли ты им что надо делать; По умолчанию они тупо генерируют наиболее вероятное продолжение, а bisect - это крайне невероятное продолжение в большинстве сценариев, так как банально оно очень редко появляется в обучающих выборках.
Чтобы агенты самостоятельно испозовали его - напишите короткий skill говорящий в таких-то ситуациях использовать bisect в таких-то не использовать. Многие подобные задачки довольно удобно решать таким способом, да и на контекст - минимальное внимание оказывает. Тем же способом можно и подключение пакетов и тд организовывать (у меня так например взаимодействие с nuget построено, модели сами по себе тоже ни в какую не хотят смотреть ни актульную версию пакета, ни ставить .net пакеты специализированной для этого командой, всегда предпочитают редактировать сам csproj файл. Скилы решают эту проблему)
Сомневаюсь что такие решения могут быть прям универсальным (а иначе всё и везде уже было бы автоматизировано), максимум покрывать какой-либо набор наиболее частых сценариев. В плане универсальности возможен разве что подход как в упомянутом n8n (построй всё сам, вот тебе кирпичики-лего и станок для производства своих кирпичиков (возможность писать свои скрипты)). А так это появилось до агентских систем, в данном случае триггером является не модель, да и сама она как правило ничего не вызывает. Ну и из этого стоит понимать, что это тоже не для всех сценариев удобно/подходит. (Это всегда должны быть строго повторяемые задачи, эпизодические, например фикс/поиск багов тут не развернуть, слишком много вариантов развития событий, общая траектория если есть, то строгой последовательности действий - нет. В данном случае как ни крути, а свободу нейронке давать надо. Но вот если говорить про документирование - более чем возможно, это вполне повторяемая задача, со строгой последовательностью действий. И да, можно построить через n8n).
Если модель не шибком умная, то там какие бы ограничения не городили вокруг неё, она один хрен по своему будет до талого пытаться делать. По опыту в ответ на жёсткие ограничения из вне они реагируют крайне неадекватно: "мне вернулся отказ, с чётко расписанной причиной и инструкцией как это преодолеть?! В мусор его! Попробую другой способ `bash rm -rf`". В целом слабую модель вот изначально как запустил, так её лучше после этого не трогать и не дышать в её сторону, как правило то как она сама сделает - выйдет лучше, чем если её наставлять на путь истинный. Любую правку поведения она либо вообще не вдупляет потом, либо ставит в абсурдистский абсолют.
Если рассматривать жёсткий сценарий - лучше запускать разными сессиями с абсолютно разными задачами и промптами под этот конкретный сценарий, тогда да, такое имеет место быть. Это в целом достаточно легко, что обычными скриптами делается, что через систему суб-агентов. Но надёжнее всё же кодом. Запускаешь 1 раз, потом хоть той же нейронке с чистым контекстом на валидацию ответ даёшь, потом пихаешь дальше.
Тут дело не в том, что они умеют, а в том сказал ли ты им что надо делать; По умолчанию они тупо генерируют наиболее вероятное продолжение, а bisect - это крайне невероятное продолжение в большинстве сценариев, так как банально оно очень редко появляется в обучающих выборках.
Чтобы агенты самостоятельно испозовали его - напишите короткий skill говорящий в таких-то ситуациях использовать bisect в таких-то не использовать. Многие подобные задачки довольно удобно решать таким способом, да и на контекст - минимальное внимание оказывает. Тем же способом можно и подключение пакетов и тд организовывать (у меня так например взаимодействие с nuget построено, модели сами по себе тоже ни в какую не хотят смотреть ни актульную версию пакета, ни ставить .net пакеты специализированной для этого командой, всегда предпочитают редактировать сам csproj файл. Скилы решают эту проблему)