Комментарии 3
Логично ожидать, что кто-нить таким же образом сделает ИИ-кандидата, в итоге ИИ-рекрутер будет общаться с ИИ-кандидатом... Похоже, тупичок намечается...
Очень мощный лонгрид. Особенно близка тема харнесса — обвязки, которая превращает разовый вызов LLM в управляемый процесс с проверкой результата.
Я как раз разрабатываю бота, который автоматически обновляет npm-зависимости и чинит сломанные тесты с помощью LLM. И я на практике убедился, что без жесткого «инженерного контура» агент быстро начинает галлюцинировать: может перезаписать конфиг, удалить нужную секцию в package.json или сгенерировать код, который выглядит правильно, но ломает всё.
Спасла меня только одна вещь: детерминированный валидатор. Мы никогда не доверяем диффу агента, пока тесты не позеленеют. То есть агент — это «исполнитель», а тесты — «ревьюер», которого невозможно обмануть.
Очень интересен ваш опыт с оркестрацией ролей. Как вы на практике решаете проблему переполнения контекстного окна, когда агент-ревьюер должен проверять код агента-исполнителя? Даете ли вы им общий контекст сессии, или общаетесь через промежуточный артефакт (дифф, лог тестов)?
В целом когда пишется план, у вас должен появиться в плане артефакт, через который вы производите общение двух агентов. Условно контракт. В контракте как раз и прописывается что проверять, например spec.md.. Я ранее разбирал уже агента ревьювера по SDD под Клауд. Но народу статья не зашла, поскольку слишком сложная, для простого прочтения. Агентам сознательно ограничивают контектстное окно, чтобы они экономили токены, меньше сбоили и можно было запускать на менее продвинутых моделях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Свой AI-харнесс: прод-движок для десятков моделей — единое окно, роутер и управляемые прогоны