Здорово, солнышки!😎
За время своих экспериментов с агентами я для себя вывел несколько правил. Возможно, кому-то, кто только начинает собирать свою первую шайтан-коробку, они сэкономят немного времени, нервов и токенов.
🟠 Сначала «карта» и архитектура, потом реализация
Перед тем как заставлять агента что-то писать, обсудите с ним будущую архитектуру проекта или навыка. На старте гораздо проще один раз собрать общее представление о том, как будет работать ваша шайтан-коробка, чем потом несколько раз переделывать фундамент уже в процессе разработки.
Можно прямо сказать агенту:
«Проведи со мной максимально подробную ревью-сессию по моему будущему проекту. Задавай вопросы до тех пор, пока не соберёшь все необходимые сведения для составления целостной картины проекта, а затем оформи всё в виде документа».
Полученный документ потом становится той самой «картой», по которой можно двигаться дальше.
🟠Надо обмазаться тестами
Если вы хотите получать стабильный результат работы от своей шайтан-коробки, необходимо максимально подробно описать проверки для каждого важного шага и заранее определить, где могут возникнуть проблемы.
На старте тестов может быть очень много. Потом часть из них можно убрать, оставив проверки на критически важных узлах.
Например:
«Сформируй набор проверочных тестов, оформленных в виде исполняемого кода, для оценки отказоустойчивости проекта, выявления ошибок и проверки критических сценариев».
А дальше уже не «кажется, оно работает», а вот тесты, вот результат, вот проблема.
🟠Отчёту агента не верь — проверяй сам
У принимающей стороны должны быть собственные тесты, которых агент не видит, а по возможности ещё и документы или данные, к которым он не имеет доступа.
Иначе возникает забавная ситуация: ты просишь агента проверить себя, он сам придумывает критерии, сам себя проверяет и сообщает, что всё прекрасно.
А нам нужно понять, действительно ли решение работает, а не насколько убедительно агент умеет рассказывать, что оно работает.
🟠Веди журнал
План, текущие статусы пакетов и правок, замечания, найденные проблемы и разрешённые отступления лучше хранить в одном месте.
Через день, неделю или после сброса контекста это позволит быстро понять, где вы остановились и почему приняли то или иное решение.
Особенно это полезно, когда над проектом работает несколько агентов или один агент постоянно начинает работу с чистого контекста.
🟠Создай вредного помощника
Если самостоятельно постоянно проверять работу нет желания или навыка, создайте отдельного агента-критика.
Его задача — получить результат другого агента и попытаться его сломать: найти уязвимость, ошибку, противоречие, пограничный случай или вообще предложить более удачное решение.
Причём у критика должен быть собственный контекст и собственная цель.
Не «проверь, всё ли хорошо», а примерно:
«Твоя задача — до*баться до решения другого агента. Ищи ошибки, слабые места, нарушения требований, неучтённые сценарии и альтернативные способы решения. Считай решение неправильным, пока не докажешь обратное».
В результате у вас появляется условная пара «создатель → вредный ревьюер», которая зачастую даёт гораздо более качественный результат, чем один агент, который сам себя хвалит
🟠Лучшее — враг хорошего
Сколько бы нам ни рассказывали, что ИИ — это мана небесная, LLM всё-таки остаётся системой, которая генерирует наиболее вероятное продолжение на основе контекста. Поэтому там, где поведение можно зафиксировать обычным кодом, надёжнее будет обычный код. Код не проснётся однажды с настроением сегодня я интерпретирую это условие немного иначе. Код можно запустить, протестировать и получить предсказуемый результат. А вот если у вашей модели закончились лимиты, контекст, токены или внезапно изменилось поведение — курите бамбук.
Поэтому я бы использовал ИИ там, где он действительно добавляет гибкости, а критически важную логику по возможности оставлял зафиксированной.
И, пожалуй, это главное правило из всех: агент должен быть вашим инструментом, а не единственным источником истин
Всем SUP! #ai