Чему AI-агенты могут научиться у C++
Мы недавно поняли, что давая агенту слишком много инструкций, мы его "тупим" — буквально ограничиваем, а не помогаем. А недавно Jeff Dean, Chief Scientist в Гугле, опубликовал их гайд по оптимизации C++ и там несколько забавных параллелей c AI агентами (в том числе на тему делать тупее):
1) Оптимизации, потерявшие актуальность
В C++ оптимизации под старое железо начинают вредить на новом. Inline assembly из 2008 года сегодня медленнее нативного кода, потому что компилятор стал умнее.
В агентах имхо похожее. К примеру, системный промпт Codex сократился на 66% при переходе с o3 на GPT-5: убрали инструкции как планировать, как работать с гитом, как валидировать, поскольку модель уже это знает.
В ту же тему Anthropic в гайде по eval-ам пишет, что лучше оценивать, достиг ли агент цели, а не конкретный путь, которым он шёл. Цели > пошаговые инструкции.
Кстати, сегодня выложили классный скилл по эвалам - рекомендую!
2) Односторонние двери решения
В уже упомянутом гайде от Anthropic выделяется 2 типа эвалов:
- pass@k (хотя бы одна из k попыток успешна —> как генерация кода пока тесты не пройдут)
- pass^k (каждая из k попыток должна быть успешной —> как отправка писем клиентам).
Пример: агент шлёт 5 холодных сообщений, каждое с 90% шансом быть адекватным. Вероятность, что ВСЕ 5 ок: 0.9⁵ = 59%, то есть надёжность падает экспоненциально.
Отсюда правило: необратимое действие (email, перевод денег) должно проверяться или человеком (human-in-the-loop) или детерминистически. Обратимое (черновик, анализ) - можно особо не париться, пусть фейлит тесты, пока не справится.
3) Агент "падает" до уровня своего harness-а
Помните James Clear: "Вы не поднимаетесь до уровня своих целей. Вы падаете до уровня своих систем."
В C++ совет звучит так: не полагайтесь на чеклисты, закодируйте проверки в автоматизацию. Проверки до запуска (compile-time) > проверки после (runtime).
По аналогии, агент не поднимается до уровня своего системного промпта, он падает до уровня своих "подпорок" (harness-а). В условном Claude Code можно настроить хуки - детерминистические проверки до и после каждого tool call:
pre_tool_call:
if tool == "send_email" and not draft_mode:
reject("Requires human approval")
Это compile-time проверки для агентов, которые не зависят от их "настроения" сегодня.
4) Numbers Every AI Engineer Should Know
Jeff Dean когда-то составил таблицу временных затрат "Numbers Every Programmer Should Know". Я подумал, что прикольно будет ее адаптировать для AI агентов, что-то в стиле:
Локальная БД: ~10 мс
Чтение файла: ~50 мс
Поиск по коду (grep): ~100 мс
Vector/embedding поиск: ~100 мс
Облачная БД: ~100 мс
LLM (Haiku/Flash): ~1 с / ~$0.001
LLM (Sonnet 4.6 / GPT-5.2): ~3 с / ~$0.005
Web search API: ~2 с / ~$0.005
Web page fetch: ~3 с / ~$0.01
LLM (Opus 4.6): ~4 с / ~$0.01
LLM (Sonnet 4.6 + reasoning): ~15-30 с / ~$0.03
LLM (Opus 4.6 + extended thinking): ~30-60 с / ~$0.10
Мульти-агент (10 turns, Sonnet 4.6): ~3 мин / ~$0.50
Ревью человеком: минуты-часы / $
Диапазон: от 10мс до часов ~6 порядков. И тот же вывод, что у Dean-а: знай, где твоё узкое место: если агент делает 10 вызовов Opus, когда хватило бы 1 Opus + 9 Haiku — ты переплачиваешь 10x и по времени, и по деньгам. Особенно, если ретрай допустим (см. pass@k пункт выше)
===
Итого:
- С каждым апгрейдом модели - (потенциально) подчищаем промпты
- Выделяем действия агента на обратимые vs необратимые, ставим human in the loop в последних
- Добавляем детерминистические проверки, чтобы не дать агенту делать ненужные ошибки
- В голове и на бумажке прикидываем стоимость операций - не используем ли мы условный Opus там, где хватит Haiku? Кстати, надо сделать skill на эту тему наверное, м?
Подписывайтесь на Telegram EDU.