Чему AI-агенты могут научиться у C++

Мы недавно поняли, что давая агенту слишком много инструкций, мы его "тупим" — буквально ограничиваем, а не помогаем. А недавно Jeff Dean, Chief Scientist в Гугле, опубликовал их гайд по оптимизации C++ и там несколько забавных параллелей c AI агентами (в том числе на тему делать тупее):

1) Оптимизации, потерявшие актуальность

В C++ оптимизации под старое железо начинают вредить на новом. Inline assembly из 2008 года сегодня медленнее нативного кода, потому что компилятор стал умнее.

В агентах имхо похожее. К примеру, системный промпт Codex сократился на 66% при переходе с o3 на GPT-5: убрали инструкции как планировать, как работать с гитом, как валидировать, поскольку модель уже это знает.

В ту же тему Anthropic в гайде по eval-ам пишет, что лучше оценивать, достиг ли агент цели, а не конкретный путь, которым он шёл. Цели > пошаговые инструкции.

Кстати, сегодня выложили классный скилл по эвалам - рекомендую!

2) Односторонние двери решения

Безос разделяет решения на обратимые и необратимые ("односторонние двери"). Jeff Dean упоминает эту же идею в контексте разработки.

В уже упомянутом гайде от 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.

1
Начать дискуссию