Loop-engineering. Часть 2️⃣

Помимо очевидного, давайте еще зафиксируем важные решения, которые нужно принять, и аспекты, которые нужно учесть, проектируя луп:
1. Автоматизация. Лупы могут триггериться вами, могут запускаться по расписанию или триггериться событиями. Выбирайте подход под вашу цель.

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

3. Скиллы. Это способ сэкономить токены и контекстное окно, которые так ценны при работе через лупы. Сначала наделайте нужных скиллов, а потом уже навяливайте сверху лупы. Иначе каждый агент будет вновь исследовать ваш проект, вновь подбирать нужные комнады и тд.

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

5. Сплит саб-агентов. Если вы используете LLM-as-a-Judge, то вы обречены на то, что модель будет в восторге от собственного творения. Поэтому, чтобы в этом случае лупы реально работали — важно заранее сделать и провалидировать как минимум 3х агентов (в зависимости от задачи могут отличаться): исследователь — изучает кодовую базу или источники; имплементатор — пытается достичь цели; оценщик — оценивает полученный результат и решает, нужна ли еще итерация. От жесткости последнего зависит качество полученного результата.

6. State. Если цель сложная и требует длинного лупа — пройденные итерации должны записываться в какой-то MD файл. Его нужно либо заранее сделать и задать правила работы с ним, либо хотя бы указать в промпте к лупу, что он должен использоваться. Это поможет не сломаться лупу, когда контекстное окно закончится.

7. Правило минимального лупа. Старайтесь делать лупы как можно меньше — фокусируйте их на конкретных фичах / процессах / задачах. Не пытайтесь сделать "мега-луп".

8. Не допускайте формирование "долга понимания". Лупы будут писать код и документы в сотни раз быстрее, чем вы. Если вы не будете понимать на архитектурном уровне, что происходит — в один прекрасный день вы просто обнаружите баг, который невозможно исправить, тк перед вами тысячи строчек кода/страниц документов, в которых вы ничего не понимаете. Решение — по завершению лупа проанализируйте не только результат, но и путь, как агенты к нему пришли. Управляйте архитектурой решения сами, агентам отдавайте реализацию этой архитектуры.

Интересный взгляд на тему еще расписали ребята из LangChain. О том, что нужно делать луп вокруг лупов, который улучшает ваши лупы 🕶 Звучит забавно, но интересно — рекомендую.

#ИИученьесвет

Заместители