Главная тема недели — проверять агентные изменения на своих задачах. Посты про выбор модели, смену обвязки и объединение промптов сходятся в одном: один успешный запуск мало что доказывает. Для повторяемой работы предлагают skill, а для замены кода — сохранённые требования и проверки. Отдельная осторожность нужна с кэшем ответов: он может вернуть старый результат вместо новой генерации.
01
Что попробовать
01
Сравнить агентов на одинаковых задачах репозитория
Суть: Рейтинг на чужом наборе задач плохо предсказывает, какой агент примет патч именно в вашем проекте. Автор предлагает сравнить всю связку: модель, обвязку и условия запуска.
Почему важно: При выборе агента важны не только решённые задачи, но и стоимость принятого патча: повторные попытки, тесты, ревью и регрессии.
⚡ Как применить
Взять 2–3 агента и одинаковые реальные баги, изменения API и тесты. Зафиксировать версии, время и число попыток.
Запустить каждого на одних задачах; проверить патчи своими тестами и ревью.
Сравнить долю принятых патчей, затраты модели и время человека; повторить часть запусков.
Риск / ограничение: Это предложенная автором процедура. Небольшой пилот покажет крупные различия, но не докажет преимущество в пару процентов.
Суть: Перед заменой модели помощника автор советует сохранить реальные успешные и проваленные задачи. Этот набор нужен и после изменения контекста или обвязки.
Почему важно: Без собственных задач новая модель может улучшить демо и сломать сценарий, из-за которого люди используют помощника.
⚡ Как применить
Сохранить несколько успешных и неудачных обращений к агенту с исходными данными и ожидаемым результатом.
После смены модели или инструментов повторить те же задачи на тестовом окружении.
Сравнить успешность, ошибки и ручные исправления с прежней версией.
Риск / ограничение: Пост не даёт формат набора и критерий прохождения. Их придётся задать до повторного запуска.
Суть: Skill полезен, когда один процесс повторяется одинаково. Автор предлагает сначала выполнить его с агентом, затем упаковать шаги и проверить в новом чате.
Почему важно: Так можно перестать каждый раз заново объяснять правила репозитория и увидеть, переносится ли процесс между задачами.
⚡ Как применить
Выбрать повторяемую задачу, например проверку PR, и дать агенту выполнить её один раз.
Записать в skill последовательность шагов, входы и обязательные проверки.
Запустить skill в новом чате на другой задаче и сравнить полноту шагов с первым прогоном.
Риск / ограничение: В посте нет готового примера и измерения эффекта; оценку полезности придётся построить на своих задачах.
Суть: OpenRouter Response Caching возвращает прежний ответ на совпадающий запрос без нового вызова модели. Автор отделяет этот режим от кэша префикса, где генерация продолжается.
Почему важно: Без проверки кэш может тихо ломать повторную генерацию и возвращать устаревший ответ при смене температуры.
⚡ Как применить
Выделить повторяемые запросы тестового или CI-процесса, для которых один и тот же ответ допустим.
Включить response cache только для них и проверить повторную генерацию при неизменном теле запроса.
Измерить долю точных попаданий и экономию; отключить кэш там, где ответ должен обновляться.
Риск / ограничение: Автор не приводит hit rate или экономию на реальном трафике. Нельзя переносить предположение о выгоде на весь сервис.
Суть: Две команды меняют промпт агента от одной базовой версии, а после экспериментов должны объединить изменения. Зелёные тесты веток не подтверждают объединённую версию.
Почему важно: При раскатке нескольких вариантов агента проверять нужно именно итоговый промпт вместе с действующими инструментами.
⚡ Как применить
Сохранить версии промпта и описаний инструментов для каждой ветки эксперимента.
Объединить изменения в отдельной версии и запустить общую и обе веточные корзины задач.
Проверить провалы и нестабильные тесты до раскатки объединённого агента.
Риск / ограничение: Пост описывает конфликт промптов и повтор тестов, но не предлагает готовую систему совместного версионирования инструментов.
Суть: Если реализацию легко пересоздать агентом, знания о поведении системы должны пережить очередную замену. Автор предлагает вынести намерение, архитектурные границы и причины решений за пределы кода.
Почему важно: Иначе быстрый рефакторинг может стереть правила, которые годами накапливались в обработке ошибок и исключениях.
⚡ Как применить
Перед изменением модуля записать его внешнее поведение, ограничения и причины нетривиальных решений.
Добавить проверку критического сценария и заменить одну часть реализации.
Прогнать проверку и убедиться, что старый путь можно откатить.
Риск / ограничение: Это принцип без шаблона документа или готового кейса; список требований нужно подтвердить с владельцами системы.
Идея требовать источники и противоречия подходит для разбора документов. Пример относится к юридическим материалам, а замер токенов сделан поставщиком на небольшой выборке.
Автор обнаружил плохие решения в коде, к которому вернулся спустя месяцы. Нужен свой повторяемый критерий ревью, прежде чем делать из наблюдения общее правило.
