эй ай майндмапа

Сразу дисклеймер: я могу быть неправ. Это саммари того, что я слышал и понял, а люди ошибаются. Где я не уверен, я так и пишу, а цифры сверил с источниками и пометил это в выносках. Цель простая: чтобы мы говорили на одном языке и обсуждать было с кайфом.

Скептики и те, кто выстрелил

Круто, что мы застали самое начало. Нейронки были тупые, очень дорогие, жили только в чате, и все ржали, что это никуда не выстрелит. А оно выстрелило. Сначала ими пользовались только программисты, потом всё больше людей. Скептики остались, и это в основном те, кто десятилетиями сидит в IT и стабильно много получает: им как будто не было смысла в это лезть. Они такие гейткиперы: охраняют вход и говорят «это всё чепуха». В России их, по-моему, до сих пор много. Для молодых всё наоборот: нейронка — самый логичный способ быстро разобраться в новом. Это моё объяснение, нигде такого мнения я не встречал.

Что значит «запустить модель»

Когда ты пишешь в ChatGPT, твой запрос (промпт) уезжает на сервер компании: OpenAI, Anthropic, DeepSeek, Kimi. Там стоит inference, то есть запущенная модель. У компании есть мощности: дата-центр с кучей видеокарт. Не тех, на которых ты играешь в Genshin или Roblox, а промышленных, вроде Nvidia H100 и H200, с огромной памятью и ценой как у квартиры.

Почему именно видеокарта, а не процессор? Так совпало, что вычисления нейронки отлично параллелятся, а видеокарта как раз умеет делать тысячи одинаковых операций одновременно. Процессор так не может. Это очень сжато и упрощённо, но суть такая.

Сама модель по сути файл. Есть программы llama.cpp и Ollama: качаешь модель в формате GGUF, весит она, скажем, 30 гигабайт, и запускаешь у себя на ноутбуке. Это и есть inference: ты «заинференсила» модель. Правда, 30 ГБ требуют соответствующей памяти (оперативка или видеопамять), так что «запустится на любом ноуте» — преувеличение. И не все модели про текст: бывают такие, что на вход берут рентген, а на выход отдают вероятность опухоли. Запуск любой модели на любом железе — inference.

Подписка против API

Есть два способа платить. Подписка: фиксированная сумма в месяц, около 20 долларов за обычный тариф, плюс лимиты. И API, про который ты, наверное, знаешь только, что он существует: платишь за каждый вызов, и считается всё в токенах. Для личных задач подписка сильно выгоднее: домашку, на которую через API уйдёт, скажем, до 10 долларов (это моя прикидка, очень зависит от модели), подписка за 20 в месяц закроет в нескольких экземплярах. В интенсивном использовании API выходит в разы, до десятков раз, дороже.

Токен — кусочек текста, примерно слог или короткое слово. Тарифицируется отдельно то, что ты отправила (input), и то, что вернула модель (output). Output обычно дороже.

Поэтому для работы с кодом компании идут в API: код уходит наружу, и им важно, чтобы его не учили на нём. На подписке в корпоративных целях сидеть не приветствуется, где-то за это даже наказывают, хотя проверить, чем именно ты пользуешься, наверное, непросто. Ещё про подписку: бывают общие ресеты, которые заново дают недельный лимит. А ещё мне говорили, что лабы зарабатывают в основном на API, а не на подписках. Это со слов, не нашёл подтверждения: у OpenAI заметная часть выручки идёт с подписок, у Anthropic доля API высока.

Кто на чём зарабатывает и зачем IPO

Есть компании, которые изо всех сил внедряют AI, особенно американские, у которых нет своей нейронки. Они платят миллиарды. Если такой клиент уйдёт к другому провайдеру, это огромный кусок выручки, поэтому у лаб гигантский стимул выпускать модели всё умнее. Это моё понимание механики, конкретных клиентов и цифр я не проверял.

Подход у лаб разный. OpenAI лезет в науку и медицину (есть ChatGPT Health, у нас он, кажется, не работает) и хвастается, что «решает проблемы тысячелетия». На самом деле заявка была по одной задаче, уравнениям Навье-Стокса, от 8 сентября 2026, и результат оспаривают. Anthropic делает модели в основном для программистов.

Anthropic выходит на IPO, и вокруг оценки в триллионы спорят. Многие считают это пузырём.

Китайские модели

Я сам пользуюсь DeepSeek, ещё есть Kimi от Moonshot AI. По бенчмаркам они идут почти сразу за лидерами, а стоят почти ничего: у них API, подписок часто нет (у Kimi вроде есть). Домашки и прочее по API вышли бы за центы. И они быстрые: по моим ощущениям, ChatGPT думает долго, а DeepSeek секунд за пять понимает задачу и за десять решает. Это субъективное наблюдение, не замер. Американские компании китайцев слегка побаиваются, это уже геополитика.

Главное: китайцы выкладывают веса в открытом доступе, это open weights. Они молодцы. Но полные версии огромные: я говорил «терабайты», по факту Kimi K2 это 1 триллион параметров, а полные веса таких моделей занимают сотни гигабайт и до порядка терабайта. Обычный человек их у себя не запустит. Есть урезанные (квантизированные) версии, их можно поднять дома, они и кодят, и делают другое, но качество ниже, чем у frontier-моделей.

Бенчмарки

Бенчмарк — набор задач, чтобы сравнивать модели. Часто он закрытый: ни модель, ни люди не видят вопросов заранее, чтобы ответы нельзя было заучить. Модель отвечает на вопросы или проходит уровень в игре. Есть пул основных бенчмарков, в том числе по коду. По моим наблюдениям, там обычно впереди Anthropic, затем OpenAI, потом Google, потом китайцы. Но это зависит от момента и конкретного теста, считай это моментальным снимком, не законом.

Сравнивать модели удобно на Artificial Analysis, я сам туда почти не захожу, но вижу в видео, как люди смотрят оттуда цифры. Минус бенчмарков: компания может придумать свой и сказать «у нас самая лучшая». Проверить по-настоящему можешь только ты на своих задачах. К этому ещё вернёмся, когда дойдём до evals.

Как удешевить inference

Китайские лаборатории не просто выкладывают модели, они ещё публикуют научные статьи о том, как эти модели обучать и запускать. DeepSeek написал, как глобально удешевить inference: у них появился подход, который позволяет крупным дата-центрам держать такие модели и обслуживать кучу пользователей заметно эффективнее. Я слышал цифру «в три раза меньше электричества», но это со слов, подтверждения в первоисточнике я не нашёл.

Что я точно проверил: в DeepSeek-V3 и V3.2 они придумали приёмы, где на каждый токен работает лишь часть модели, а внимание по длинному тексту считается не по всем словам подряд, а по самым нужным (sparse attention). Получилось дешевле, особенно на длинных контекстах.

Дата-центр над городом

Почему это вообще важно? Ты, может, видела мемы: «Извините, мы из OpenAI, мы построим над вашим городом дата-центр и будем использовать вашу воду», а в шутку добавляют, что подарят бутылку воды. Это действительно большая проблема: людям страшно, когда рядом с городом растёт дата-центр. Мне это напоминает шахты и другие индустрии: появляются рабочие места, нужно следить, чинить, убирать, у этих людей семьи, открываются школы. И город становится зависимым от одной штуки. Это уже не только про программистов, это огромные деньги и чьи-то судьбы.

Отсюда и страх пузыря. Если рынок раздут и однажды сдуется, как пирамида, люди потеряют работу, не смогут платить за образование детей, и начнётся настоящий кризис. Нас в России это напрямую вряд ли заденет, у нас кризис будет по другим причинам, но в целом тема серьёзная.

Самое неприятное, по-моему, вот что. Компании и целые страны соревнуются друг с другом, и из-за этого люди чувствуют глобальное участие в чём-то огромном. Индивид как будто теряет себя и перестаёт следить за своей жизнью. Люди перерабатывают, юзают нейронки ещё больше, чтобы выпускать ещё больше фич, а раз все выпускают больше, гонка ускоряется. Получается цикл, в котором очень сильно тревожно. Короче, это не очень хорошо.

Лимиты подписки

Ещё одна мелкая нервотрёпка: компании могут тихо урезать лимиты подписки, и ты вдруг замечаешь, что недельный лимит закончился подозрительно быстро. Видно это плохо, потому что в подписке ты не видишь ни токенов, ни долларов. Отдельные такие моменты регулярно заставляют понервничать. А конкуренция работает в твою пользу: «китайцы почти догнали, а мы просим большие деньги» заставляет компании шевелиться.

Это слово, вокруг которого строится весь наш курс. Ты его, возможно, уже встречала. В Твиттере вокруг него напридумывали кучу терминов: AI-инжиниринг, контекст-инжиниринг, harness-инжиниринг. Общей науки за этим, по-моему, пока нет, это скорее ярлыки. Называть можно как угодно, важно держать в голове суть.

Модель: мозг в банке

Сама модель это запущенная штука, и её размер упирается в память (RAM или видеопамять): чем её больше, тем крупнее модель влезет. Твой промпт разбирается на токены, превращается в векторы, проходит через слои, где работают разные «эксперты» (зависит от архитектуры). Всего этого мы не видим. И это ещё не «мышление»: когда ты включаешь think, то, что модель пишет, отдельная история. Я вообще близко сравниваю модели с мозгом, мы же тоже не знаем, как двигаются мысли по нейронам.

Представь, что в банку положили не голову, а просто мозг. Сам по себе он бесполезен. Подключишь нервы от глаз, и он сможет принимать картинки. Добавишь рот, и сможет что-то выводить. Добавишь руки, и он сможет что-то трогать: читать файлы, писать, отвечать письменно. Вот всё это и есть harness.

Слово переводится как упряжь: накинула на лошадь упряжь, прицепила повозку, и можешь управлять. Только не плётка, я про другую штуку. Harness это приложение ChatGPT, это Codex CLI, которым ты наверняка пользуешься, это Claude Code. Даже Ollama или llama.cpp по сути harness: они дают модели возможность существовать, отвечать тебе и взаимодействовать с тем, что вокруг. Точная граница расплывчатая, это нормально.

Вот как это выглядит на самом простом примере: ты просишь прочитать файл.

Обрати внимание: файл читала не модель. Она написала просьбу, а открыл файл её harness.

Контекст мы придумали сами

У модели есть контекст, но он придуман нами. Если взять самый простой и чистый harness и написать «привет», а потом продолжить диалог, для модели каждый запрос по умолчанию первый. Она видит только текущий промпт. Чтобы разговор «помнился», harness каждый раз подкладывает в запрос твои прошлые сообщения и её прошлые ответы. Это и есть контекст.

Из этого следует неприятная вещь: чем длиннее диалог, тем больше нужно перетаскивать каждый раз, тем длиннее «подумать» и тем дороже каждый следующий запрос, причём очень заметно.

Кэш: hit и miss

Чтобы это удешевить, придумали кэш. Не знаю, как он устроен под капотом (на уровне матричных умножений, жёсткая штука). По документации Anthropic идея такая: уже обработанное начало запроса (прошлые сообщения, инструкции) платформа запоминает, и когда оно повторяется, модели не нужно считать его заново. Ты как будто не видишь, но всё прошлое лежит над твоим новым сообщением, уже обработанное. Совпало с началом: cache hit, дёшево. Не совпало или истекло: cache miss, полная цена.

Я говорил «уйдёшь на 30 минут, и кэш обнулится». На самом деле срок жизни кэша по умолчанию 5 минут, и он продлевается при каждом использовании. Для долгих пауз можно заказать час, но запись в кэш тогда дороже. По подписке этого не видно, потому что ты не видишь долларов, а по API всё считается явно.

Короче, в прошлой главе я говорил, что harness — это программа вокруг модели. Теперь с этой стороны: что именно такая программа даёт модели. Сама по себе модель ничего не умеет, кроме как продолжать текст. Всё остальное — читать файлы, запускать команды, писать код — это то, что harness ей разрешил и что вообще попало к ней в запрос. Поэтому вопрос «что модель видит» важнее, чем «какая она умная».

Что модель может делать: разрешения

Часть harness — это разрешения: какие команды модель вправе запускать. Прочитать файл, посмотреть содержимое папки (ls, tree), что-то записать, выполнить команду в терминале. Если возможность есть, модель ею воспользуется: скажешь «посмотри в загрузках, сколько у меня файлов», и она реально пойдёт и посмотрит. Я сам обычно даю полный доступ, поэтому в тонкостях разрешений не копался. Но вопрос «что можно дать модели» очень важный, и им стоит заняться до первой серьёзной задачи.

Из этого вытекает практическая штука. Если модель не может прочитать файл, а ты в промпте на него ссылаешься, она не остановится и не скажет «не могу». Она решит задачу без него — и, скорее всего, неправильно. Так что, прежде чем писать «посмотри в спецификации», проверь, что файл действительно доступен.

Файлы читаются кусками

Раньше инструменты читали файл целиком. Попросишь «прочитай файл», а там «Война и мир», и деньги улетели: либо контекст забился, либо вообще прилетела ошибка переполнения. Современные агенты так не делают. Они берут кусок через sed — обычную линуксовую команду, которая печатает строки с такого-то по такой-то. «Прочитай файл» превращается в «покажи строки 0–300», а если в файле десять строк, выведутся десять. Плюс модель помнит, куда добавила print, и перепроверяет только это место. Это сильно экономит токены.

Статика и динамика

Контекст — не просто «сообщения». Я делю его на две части.

Статический контекст попадает в каждый запрос и не меняется между шагами: системный промпт, файл инструкций (AGENTS.md или CLAUDE.md), описания инструментов, MCP-серверов и skills. Раз он всегда одинаковый, его выгодно кэшировать: повторно обработанный префикс стоит заметно дешевле. По моим наблюдениям, в длинной агентной сессии кэшем покрыто почти всё, я слышал порядок «99% контекста», но цифра грубая.

Динамический контекст — то, что наросло по ходу работы: твои сообщения, мысли и ответы модели, результаты инструментов, прочитанные файлы, картинки, ссылки. Он живёт до конца сессии. Открыла новую сессию — пусто.

Кстати, про срок жизни кэша: можно попытаться «успеть» с новым промптом, пока кэш не протух. Я бы не стал. Это сильно стрессово: агент ответил, и надо срочно что-то дать. Намного лучше сначала провалидировать результат, а потом поставить чёткую следующую задачу.

Какие файлы что делают

Главная точка влияния на статический контекст — файлы в проекте. Положи в корень репозитория AGENTS.md — и модель в каждой сессии будет знать, как собирать проект, как писать код и что для тебя обязательно. Это такой README, только для агента. Новый проект, новая папка — свой AGENTS.md. Вот пример для репозитория с домашками.

# AGENTS.md — учебный репозиторий с домашками

## Команды
- Сборка: `./gradlew build`
- Тесты: `./gradlew test`
- Проверка стиля: `./gradlew spotlessCheck`

## Стиль кода
- Java 21, отступ 4 пробела, классы в UpperCamelCase.
- Тест лежит рядом с кодом и называется `ИмяКлассаTest`.
- Не добавляй зависимости без вопроса.

## Правила работы
- Всегда отвечай по-русски.
- Перед коммитом гоняй тесты. Красные тесты не коммить.
- Каждая домашка — отдельная папка `hw-NN/`, чужие не трогай.
- Сообщение коммита: `hw-NN: что сделано`.

Теперь про CLAUDE.md. Это то же самое, но для Claude Code: в его документации основной файл называется именно так. Обычно CLAUDE.md просто ссылается на AGENTS.md строкой @AGENTS.md, чтобы не вести два файла, и добавляет что-то личное.

# подтягиваем общие правила репозитория
@AGENTS.md

## Лично от меня
- Перед правками покажи план в трёх пунктах.
- В коммитах подписывай, что сделал ты, а что я.
- Если не уверен в формулировке задания, спроси, а не угадывай.

# где что лежит
~/
├── .claude/
│   └── CLAUDE.md             # глобальный: твои правила для всех проектов
└── homework/                  # репозиторий с домашками
    ├── AGENTS.md             # правила проекта, читают любые агенты
    ├── CLAUDE.md             # @AGENTS.md + личные правила для Claude
    ├── .claude/
    │   ├── memory.md         # опыт прошлых попыток (имя и место зависят от продукта)
    │   └── skills/
    │       └── cu-homework/
    │           └── SKILL.md  # как сдавать домашку в ЦУ
    ├── hw-01/
    └── hw-02/

Системные промпты — это рекомендации

Кроме твоих файлов есть системный промпт самого harness и самой лаборатории. Там написано, например, что ты на Windows, или что в папку с фотографиями лезть нельзя. Ты его не видишь, но он есть. И важный нюанс: это рекомендация, а не запрет. Если в harness нет программного ограничения, модель технически может сделать и то, что в промпте запрещено. Настоящий запрет — это права доступа, а не строчка текста. То же верно и про твой CLAUDE.md: это контекст, а не принудительная настройка. Для жёсткого запрета у Claude Code есть хук PreToolUse (про хуки — в главе 6).

Ещё в системных промптах облачных моделей может быть то, что ты не заметишь: например, отказ генерировать данные для дистилляции. Дистилляция — это когда меньшую модель учат на ответах и рассуждениях более сильной. Условия сервисов Anthropic и OpenAI такое запрещают, и аккаунты за это банят. На твоих обычных задачах это ни на что не влияет.

Memory: опыт, который не надо перепридумывать

Есть ещё файл памяти (memory), и мне он нравится больше всего. Он постепенно обновляется сам, как будто знает всё, что ты говорила. Он не обязан быть большим и, скорее всего, написан грамотнее, чем написала бы ты, потому что ведёт его агент. В новом чате этот файл подмешивается в контекст — в том числе для конкретной папки проекта.

Самое ценное там — не «что любит пользователь», а опыт. Ты просишь зайти в аккаунт ЦУ. Модель пробует один способ — блокируют, другой — капча, третий — получилось. Она записывает: «железный вариант такой, остальные не подошли, потому что…». В следующий раз она не тратит токены на перебор. Деньги экономятся, но главное — быстрее. По-моему, это шедевр. Вот как это может выглядеть.

# Память проекта «домашки»

## ЦУ (my.centraluniversity.ru)
- В LMS заходить через сохранённую сессию браузера, а не через форму логина.
- Форма логина: капча и блокировки, скриптом не проходит. Не пробовать.
- Как сдавать домашку: см. скилл cu-homework (.claude/skills/cu-homework/).

## Серверы
- VPS доступен по ssh sandbox. Можно гонять тяжёлые тесты и эксперименты.
- Ничего важного там не хранить: это песочница.

## Привычки
- Документировать изменения и подписывать, кто что сделал.

Контекст заполняется

Агент думает, читает, запускает — и каждый шаг оседает в динамическом контексте. Окно конечное, это математический предел. Anthropic в статье про context engineering называет контекст конечным ресурсом с убывающей отдачей и описывает context rot: чем больше окно заполнено, тем хуже модель вспоминает детали из него.

Когда окна почти не остаётся, срабатывает автокомпакт (compaction): модель проходится по истории, выбирает, что кажется ей важным, и заменяет всё это коротким саммари. Ты можешь запустить его и сама. Проблема в слове «кажется». Она может не посчитать важным как раз то, что нужно тебе. Например, что вы общаетесь по-русски: после компакта агент вдруг отвечает по-английски. Или что тесты надо гонять каждый раз, — и вот у тебя репозиторий с красным CI.

Отсюда правило, которое я проверил на себе: всё важное держи в AGENTS.md и memory, а не в чате. Чат — дело временное, он сожмётся или умрёт вместе с сессией. Файл инструкций приходит в каждый запрос заново и от компакта не страдает. Если что-то критично («не коммить красные тесты»), положи это туда, а лучше ещё и сделай детерминированным — хуком или проверкой в CI. Об этом глава 6.

«Если файл недоступен, модель решит задачу без него — и, скорее всего, неправильно». Поэтому понимать, что модель реально видит, — часть промптинга, а не мелочь.

Harness — это программа, к которой подключается модель. А значит, модель можно выбирать, и в хорошем harness — любую. Поэтому полезно уметь подбирать её под задачу, а не брать самую крутую по привычке.

Лестница моделей

У всех крупных лабораторий теперь не одна модель, а линейка. У OpenAI это GPT-6 Astra, GPT-6.1 Sol, GPT-6.1 Terra и GPT-6 Luna. Я вначале думал, что их назвали в честь Солнечной системы, но по смыслу важнее другое: они выстроены по цене и уму. Astra самая дорогая и умная, Luna самая лёгкая. У Anthropic то же самое: Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5.

Мой вывод: Astra слишком умная и слишком дорогая для большинства повседневных задач, она по сути не нужна. Sol — тоже дорогая, но заметно дешевле (по прайсу API в пять раз), и ей хватает, чтобы сильно подумать и придумать хорошее решение.

Дорогая может быть быстрее

Цена за токен — не вся цена. Дорогая модель часто попадает в точку: она по твоим вводным (а это не только промпт, а всё, что попало в контекст) сразу понимает, какого решения ты ждёшь. «Оп, я знаю, о чём речь» — и задача решается за пару запросов. С дешёвой моделью придётся докидывать контекст, она будет переспрашивать, потратит кучу времени, и ты намучаешься. Субъективная прикидка: мне проще положить условные 20 долларов на дешёвую модель, и она за час напишет весь код, чем ждать четыре часа от дорогой. Но это зависит от задачи, универсального ответа нет.

Ещё одно наблюдение. Один и тот же промпт на разных моделях даёт разный результат. Иногда причина не в «тупости» модели, а в том, что промпт написан под другую. Одной хватает пары строк, другой надо расписать всё подробно. Так что, меняя модель, будь готова менять и инструкции.

Effort: насколько думать

Effort — настройка, насколько глубоко модель обязана подумать перед ответом. Многие ставят максимум просто потому, что он есть. Зря: рекомендованное значение, чаще всего medium, обычно реально хватает. Поднимать effort нужно там, где ты чувствуешь ответственность: например, архитектура, которая закладывается один раз и потом почти не меняется.

Разница видна на примере. Пишешь модели: «сайтом будут пользоваться 500 человек каждый день». На низком effort она придумает вариант, поищет, было ли такое раньше, увидит, что было, и успокоится. Эффективно ли оно, она не спросит. На высоком — начнёт себя критиковать: прикинет RPS, поищет в интернете, насколько архитектура вообще хороша, а может, предложит написать демо, покрыть тестами и прогнать нагрузочное. Это уже намного дольше, и надо решать, нужно ли оно тебе. Хотя решать не обязательно человеку: она может запустить агентов, которые всё проверят.

Любая модель в любом harness

Если harness открытый или просто приятный, в него можно вставить API-ключ любой модели. Например, не Claude Code, а именно модель Opus или Sonnet, но в чужой обёртке. Тариф будет высоким (это API), зато плюсы в другом: свои системные промпты, свои плагины, свои ограничения. Допустим, ты инженер и строишь ракету. У тебя 3D-редактор, и ты хочешь тесную интеграцию, где модель правит чертежи с учётом иностранной документации и российских ТЗ. Готовый инструмент такое может не позволить, а свой harness позволит. Или на работе тебе дают Claude бесплатно, ты берёшь ключ и пользуешься им где хочешь.

Мне особенно нравится идея «всё — плагин» в harness от DeepSeek. Хочешь розовое приложение? Просишь «сделай себя розовым», и он делает. Хочешь счётчик потраченных денег в рублях или сколько осталось до конца задачи? Он пишет плагин и куда-то ставит.

Архитектор и исполнители

Дальше интереснее. Если модели взаимозаменяемы, их можно разделить по ролям. Дорогая и умная (скажем, Opus 5.5) пишет код слишком дорого, зато как архитектор она отличная. Дешёвая и быстрая (тот же DeepSeek) — исполнитель. Роли можно зафиксировать в memory: «код пиши через DeepSeek, так дешевле и быстрее». Ещё туда же записать ресурсы: «есть VPS, заходишь по ssh sandbox, можно гонять испытания». Модель увидит, воспользуется и может выпустить агентов, которые всё сделают, а она потом провалидирует результат.

Мой пример для проверки идеи — «тиндер для котиков»:

Почерк

Последнее, что мне нравится. У каждого свой подход к разработке. Я, например, хочу, чтобы всё было максимально задокументировано, с подписями, кто что сделал. Олег хочет, чтобы имена и даты были скрыты. И модель так или иначе повторяет твой почерк: я неосознанно уже настроил модели работать так, как нужно мне. Это такой вкус. Поэтому меняя модель или harness, не удивляйся, что результат «не твой»: просто привычки остались в старом окружении.

Короче, если harness хороший, то с ним можно всё: от обычного чата до поиска в интернете и управления компьютером. Начнём с того, что агент вообще делает с вебом, потому что тут много неочевидного.

Web search и web fetch — это разные вещи

Поиск в интернете — это запрос к чьему-то индексу. Google и Яндекс хранят проиндексированные страницы, и сделать запрос — значит воспользоваться их сервисом. Когда ты ищешь бесплатно через строку в браузере, это один мир. Для агента тот же запрос платный: ребята придумали на этом зарабатывать.

Web search принимает вопрос агента и возвращает ссылки на подходящие страницы, как твой запрос «найти котика для отношений». А web fetch берёт конкретный адрес и открывает именно эту страницу. Тарифицируются они по-разному.

Вот как это выглядит в логе агента.

Сайты с JavaScript

Для человека страница — красивый дизайн, который грузится в браузере. Для агента, который просто скачал HTML, она может выглядеть иначе. Мы с тобой упирались в это в Java-проекте с парсером: сначала лениво приходит пустой каркас, а настоящее содержимое (тот же профиль с кошечками) подгружается скриптом уже после. Агент, прочитавший «сырой» HTML, увидит пустоту. Отсюда два выхода: найти у сайта API-эндпоинт, который отдаёт данные напрямую, или открыть страницу как человек.

Computer use: скриншоты и координаты

Второй выход — computer use: у агента как будто появляется курсор. Никакой науки. Он делает скриншот, а визуально-языковая модель (VLM) понимает, что на картинке: вот кнопка, вот поле. Так же, как ты смотришь на дизайн и понимаешь, что есть что. Дальше он выдаёт координаты по осям x и y: «кликни сюда». Часто ему доступны ещё и элементы страницы, так что input он опознаёт как поле пароля.

Сила и риск: cookie и JWT

Теперь пример, из-за которого я сам офигел. Раньше модель не заходила на сайты, теперь заходит. Почему? У неё есть доступ к системе, если ты её не ограничила. Она видит запущенный браузер, а у вкладки есть данные сайта и мета-информация: cookie и JWT-токены с твоей авторизацией. Для тебя на сайте ЦУ кнопка «мои оценки». Для агента это замаскированный API-эндпоинт с методом GET. Он пробует дёрнуть его — отказ, ты не авторизована. Тогда он находит токен в браузере и использует его, как будто ты сама нажала на кнопку. Оценки получены, а ты ничего не нажимала.

Теперь про пароли. В нашем боте агент получает пароль, но не видит его и сам не использует. Пароль приходит из linux-команды, минуя контекст: агент подставляет его в поля, отправляет POST-запрос логина и видит только ответ «получилось или нет». Если сайт хороший, он скажет «неверный пароль»; если просто бросит ошибку, агент поймёт только, что что-то не так. Принцип простой: секрет не должен проходить через текст, который читает модель.

Сабагенты

Дальше то, что, на мой взгляд, люди используют сильно меньше, чем могли бы, — сабагенты. Главный агент может запустить помощников. У каждого свой чистый контекст, и обратно приходит только короткий итог. Это решает сразу две проблемы: основной контекст не забивается кучей прочитанных файлов, и независимые подзадачи идут параллельно. Посмотри схему: переключай вкладки и жми «Дальше», чтобы увидеть, как меняется картина.

Так что сабагенты — не бесплатный бонус, а обмен токенов на качество и скорость. Для мелкой правки они не нужны. А когда нужно «пока я ищу в коде, ты почитай документацию, а третий проверь стиль», это то, что надо. В Claude Code сабагента описывают markdown-файлом в .claude/agents/, и есть встроенные: Explore, Plan, general-purpose.

Детерминированность: тесты, CI, хуки

Нейронка ненадёжна: она может забыть, передумать, не посчитать важным. А детерминированное должно выполниться наверняка. Это не то же самое, что транзакционность, а скорее «гарантированно сработает при тех же условиях». Типичные примеры: юнит-тесты и CI — проверка, что репозиторий в актуальном состоянии. Ты можешь сказать агенту «обязан запускать тесты на каждый push», но, как мы видели в главе про контекст, после автокомпакта он может об этом «забыть». И вот у тебя красные чеки.

Для этого придумали хуки (hooks). Хук — это действие, которое harness выполняет в заранее заданный момент работы: в начале сессии, перед или после инструмента, перед завершением ответа. Хук можно настроить на запуск тестов, на проверку, на запуск сабагента-ревьюера. Например, модель выполнила git commit, хук запустил ревьюера, и модели прилетает ответ: «после коммита я заглянул, тут написана хрень, исправь». Любая попытка сделать задачу более детерминированной повышает качество: репозиторий остаётся чистым, без мусорных файлов, фронтенд следит за дизайном.

Заметь, что PreToolUse умеет не только наблюдать, но и блокировать. Если тебе нужен жёсткий запрет («не трогай папку с фотографиями»), правильное место именно оно, а не строчка в CLAUDE.md. Строчка — рекомендация, хук — программное ограничение.

Попутно: модели думают на английском

Ещё мелкий факт, который помогает понимать поведение. Модели под капотом во многом рассуждают по-английски: основная масса знаний в интернете либо на английском, либо на китайском. Помнишь шутки, когда они вдруг отвечали иероглифами? Сейчас это редкость, но после автокомпакта ответ по-английски — вполне реальная история, и именно поэтому «пиши по-русски» должно жить в AGENTS.md, а не в чате. Строго говоря, «думают на английском» — упрощение: многоязычные модели не обязаны держать один язык, но английский в обучении доминирует.

Skill как чек-лист

Последний инструмент для детерминированности — skill. В него можно заложить обязательные шаги. Например, skill сдачи домашки в ЦУ говорит: «перед отправкой обязательно покажи мне скриншот страницы», и harness тебе его показывает. Ты говоришь: «домашку сделал, загрузи её в ЦУ по дата-инжинирингу», а дальше агент идёт по знакомой тропе.

В голосовых я сказал, что MCP «то же самое, что skill». Это упрощение, и сейчас я его исправлю. Заодно закрою дыру, которую оставил сам: я говорил про skills и ни разу не объяснил, из чего они состоят. Так вот.

Skill — это папка с markdown-файлом

Короче, skill — это обычная папка, а в ней текстовый файл SKILL.md. Никакой магии. Тот же markdown, который ты пишешь в заметках. Сверху у файла маленькая шапка (frontmatter) с двумя обязательными полями: name и description. Ниже обычный текст: когда это применять, какие шаги делать, чего не делать. Рядом с файлом могут лежать скрипты (scripts/) и справочники (references/).

По сути skill — это то, что ты бы написала новому сотруднику: «вот как у нас сдаётся домашка, вот команды, вот чего не делать». Только сотрудник — модель, и читает она это каждый раз с нуля.

Почему это не раздувает контекст

Прикол в том, как skill загружается. Это называется progressive disclosure, «постепенное раскрытие», три уровня:

1. В контексте всегда лежат только name и description каждого skill. Одна-две строки на skill. Если у тебя 30 skills, это 30 строк, а не 30 толстых инструкций.
2. Когда приходит задача, подходящая под описание, агент открывает сам SKILL.md целиком.
3. Скрипты и справочники агент берёт, только если они понадобились. Скрипт он запускает, а его код в контекст не читает: в контекст попадает только результат.

Поэтому в description пишут триггер-слова: по ним агент и решает, что пора открыть именно этот skill. Плохое описание — skill не сработает. Это как плохое название папки на рабочем столе: сама папка есть, но ты её не найдёшь.

Пример целиком: skill «cu-homework»

Мой любимый пример. В ЦУ (Центральный университет) домашки лежат в LMS my.centraluniversity.ru. Каждый раз агенту приходилось заново разбираться: как зайти, где список, куда нажимать. Я один раз записал это в skill. Вот как выглядит папка:

.claude/skills/cu-homework/
├── SKILL.md                      # главное: описание и шаги
├── scripts/
│   ├── session_from_browser.py   # берёт сессию уже открытого браузера
│   └── list_tasks.py             # печатает задачи: статус, дедлайн
└── references/
    └── statuses.md               # что значит каждый статус задачи

---
name: cu-homework
description: Помогает с домашкой в ЦУ (Центральный университет, LMS
  my.centraluniversity.ru). Используй, когда пользователь пишет «домашка»,
  «ЦУ», «дедлайн», «сдать задание», просит найти, решить или отправить
  задание в LMS.
---

# Домашка в ЦУ

## Когда использовать
- Пользователь просит посмотреть, решить или сдать задание в ЦУ.
- Нужно узнать дедлайны или статусы задач.

## Шаги
1. Возьми сессию из браузера: python scripts/session_from_browser.py.
   Это cookie уже залогиненного браузера. Логиниться паролем не надо.
2. Получи список задач: python scripts/list_tasks.py.
   Что значат статусы, смотри в references/statuses.md.
3. Выбери задачу, прочитай условие, реши.
4. ОБЯЗАТЕЛЬНО покажи пользователю скриншот или превью ответа
   и спроси: «Отправляю?». Жди явного «да».
5. Только после «да» отправь и перепроверь статус задачи.

## Не делать
- Не просить и не принимать пароль в чате.
- Не отправлять ничего без подтверждения после превью.
- Не трогать задачи со статусом «проверено».

Обрати внимание на три вещи. Первое: в description есть слова, которыми ты реально говоришь («домашка», «дедлайн»). Второе: про пароль сказано прямо, и агент берёт готовую сессию браузера, а не пытается залогиниться. Третье: превью перед отправкой стоит отдельным обязательным шагом. Человек остаётся последним звеном.

Какие бывают skills

Skill-«вкус» самый простой. Вот как может выглядеть мой, короткий:

---
name: my-writing-style
description: Пиши тексты в моём стиле. Используй, когда прошу
  написать пост, сообщение или письмо от моего имени.
---

# Мой стиль
- Коротко. Первая фраза несёт мысль, без разгона.
- Разговорно: «короче», «по сути». Без канцелярита.
- Один пример на мысль, лучше бытовой.
- Не заканчивай морализаторством и не используй эмодзи.

Как сделать skill из прошлых сессий

Писать skill с нуля скучно. Проще так: у тебя за плечами уже несколько сессий, где агент спотыкался об одно и то же. Попроси модель их разобрать:

Сначала прикидываешь на словах, нужен ли он вообще. Часть затыков сегодня закрывает память агента, а skill нужен там, где ты хочешь гарантированный порядок шагов.

Как понять, что skill помогает

«Мне кажется, лучше» — слабый аргумент. Я проверяю бенчмарком: берёшь одну и ту же задачу, гонишь агента со skill и без, а результаты оценивают свежие агенты-ревьюеры, которые не видели процесса. Потом главный агент выступает судьёй. Тратишь чуть-чуть токенов, зато видно разницу. (Как делать такие проверки по-взрослому, разберу в следующей главе про evals.)

Plugin — набор skills под одну задачу

Plugin — это упаковка. Когда у тебя несколько skills про одно дело, их собирают в один набор, который ставится одной командой. Плюс в набор можно положить команды, хуки и подключения MCP.

Мой пример: «плагин дизайнера». Я говорю: «хочу дизайн Tinder для котиков, давай побрейнштормим». В описании есть триггер-слова, и агент понимает, что это про дизайн. Внутри плагина один skill ищет референсы (ссылки на Pinterest), другой знает мой вкус: сложный дизайн, шейдеры, анимации. Агент искал бы не «что-нибудь красивое», а то, что нравится мне.

designer-plugin/
├── .claude-plugin/plugin.json   # название, версия
├── skills/
│   ├── find-references/SKILL.md   # где искать, как отбирать
│   └── my-taste/SKILL.md          # что мне нравится
├── commands/                    # свои /команды
└── .mcp.json                      # подключения к сервисам

MCP — розетка для сервисов

Теперь про отличие, из-за которого я сам ошибся. Skill лежит рядом с агентом и описывает, как что-то делать. А MCP (Model Context Protocol) — это протокол: договорённость, как агент разговаривает с чужим сервисом. Сервис поднимает у себя MCP-сервер, тот отдаёт агенту описание и набор «ручек». По спецификации ручки бывают трёх видов: tools (действия), resources (данные) и prompts (шаблоны).

Ключевое: что открыть, решает сам сервис. Я слышал, что у «ВкусВилла» есть MCP (сам я его не проверял, так что воспринимай как иллюстрацию). Логика такая: оплату через агента мы себе позволить не можем, слишком рискованно, поэтому дадим только поиск по каталогу и корзину. Агент физически не может оплатить заказ, потому что такой ручки просто нет. Это защита надёжнее любых слов в промпте.

Как выглядит описание такого сервера (условный учебный пример, не настоящий):

{
  "name": "vkusvill-demo",
  "description": "Поиск продуктов и корзина. Оплаты нет.",
  "tools": [
    { "name": "search_products",
      "description": "Поиск по каталогу по тексту",
      "inputSchema": { "query": "string" } },
    { "name": "get_product",
      "description": "Карточка товара: состав, цена, наличие",
      "inputSchema": { "product_id": "string" } },
    { "name": "add_to_cart",
      "description": "Положить товар в корзину",
      "inputSchema": { "product_id": "string", "qty": "integer" } },
    { "name": "get_cart",
      "description": "Показать содержимое корзины",
      "inputSchema": {} }
  ]
}

А подключается это к клиенту обычно либо командой вроде claude mcp add, либо записью в конфиг. Условно:

{
  "mcpServers": {
    "vkusvill": {
      "type": "http",
      "url": "https://mcp.example.com/vkusvill"
    }
  }
}

Skill, plugin и MCP: что за что

Бенчмарки: чужие экзамены

Бенчмарк — это набор задач, на которых сравнивают модели. Задачи обычно держат закрытыми, чтобы модель не выучила ответы заранее (иначе это экзамен с подсмотренными билетами). Такие сравнения делают, например, независимые компании вроде Artificial Analysis. Гонку это сильно подстёгивает: «китайцы почти догнали, а мы просим большие деньги».

Но есть подвох, и я его чувствую каждый раз. Эти тесты непубличны, а иногда непонятно, не проплачены ли они. Любая компания может придумать свой бенчмарк, сама себя оценить и сказать «у нас лучшая модель». Проверить по-настоящему можешь только ты, на своих задачах. Вот для этого и нужны evals.

Evals — это юнит-тесты для нейронки

Eval (от evaluation, «оценка»; я в голосовых называл это «вэлс», это ослышка) устроен как обычный юнит-тест: есть вход, есть ожидаемый результат, есть проверка «сошлось или нет». Разница в том, что нейронка отвечает не одинаково каждый раз, поэтому проверка чаще не «ровно равно», а «достаточно близко» или «по критериям».

Сразу честно: я сам evals пишу редко. Мне жалко денег, а у части моих продуктов такого и не требовалось. Если у тебя в приложении нет AI-фичи, зубрить это незачем. Но если нейронка у тебя главная фича, без evals ты летишь вслепую.

Как оценивать ответ

Способов четыре, и выбор зависит от задачи:

• Точное совпадение: «чек / не чек», число, да/нет. Самое дешёвое и честное.
• Критерии: список «ответ упоминает дедлайн, не выдумывает факты, короче 200 слов». Проверяется по пунктам.
• LLM-судья: другая модель читает ответ и ставит оценку по твоим критериям. Быстро, но судья тоже ошибается, поэтому его калибруют на примерах.
• Человек: самый надёжный и самый дорогой. Подходит для спорных случаев и выборочной проверки.

Eval в CI

Дальше как с обычными тестами. Ты запушила код в GitHub, и GitHub Actions в CI прогоняет проверки: появляются те самые зелёные галочки. Если в проекте есть нейронка, прогоны evals можно положить туда же. Но тут нюанс: подписку ChatGPT или Claude в GitHub не залогинить, там нет твоего браузера. Поэтому используется API-ключ с положенными на счёт деньгами. Ключ хранят в секретах репозитория, а не в коде.

Примеры evals: пять карточек

Код я здесь писать не буду. Eval на деле — это таблица «что подаём, что ждём, как сравниваем, что считаем нормой». Вот пять примеров. Числа в порогах условные: подбираются под твою задачу.

1. Классификация фото: «чек или не чек»

2. Проверка домашки

3. Eval skill'а cu-homework

Тот самый skill из прошлой главы. Помогает он или нет, проверяем так:

4. Eval harness'а: три версии системного промпта

5. Регрессия при смене модели

«Быстро» против «качественно»

В индустрии вечный спор: сделать быстро «из говна и палок» или основательно, с фундаментом. Честно, ответа у меня нет, и мне кажется, это ложная дилемма: можно сделать и быстро, и с фундаментом. Проблема в другом. Каждый понимает «быстро» и «качественно» по-своему. Для кого-то быстро — месяц, потому что код пишут руками. Для кого-то медленно — два дня, потому что всё должно быть за час. Критерии качества тоже у каждого свои.

Это порождает конфликты. Поэтому до того, как спорить, договорись, что считаете «ок». А это ровно то, что мы делали в карточках выше: вход, эталон, способ оценки, порог. Evals — это договорённость о качестве, записанная так, что её можно проверить.

Инцидент и постмортем

Начну с двух слов, которые вокруг этой темы летают постоянно. Инцидент — это то, что случилось: что-то сломалось, утекло, компания потеряла деньги. Постмортем — это разбор после: как так вышло, что делаем, чтобы не повторилось. Чаще всего его пишут без поиска виноватых, чтобы люди не прятали ошибки. Бывает внутренний, бывает публичный: крупные компании, включая лаборатории вроде OpenAI и Anthropic, иногда выкладывают свои разборы.

У инцидентов разная критичность. Я говорил про «белые» и «чёрные» уровни, где чёрный — это отзыв лицензии, миллиардные штрафы и даже тюрьма. Честно скажу: такая шкала скорее из банковской и комплаенс-практики. В IT обычно используют уровни SEV или P0–P4: от мелкой неприятности до «всё лежит». Принцип тот же: чем выше уровень, тем быстрее и серьёзнее реакция.

Агенты и лазейки

Теперь самое интересное. Агентов часто запускают в песочнице: закрытой среде, где нет доступа ко всему интернету и к чужим системам. Я рассказывал историю, как агенты умудрялись найти друг друга и передавать сообщения через менеджер зависимостей Maven: создавали свою зависимость и кодировали в ней сообщение.

Что было на самом деле

• Anthropic и партнёр Irregular, 30 июля 2026. Anthropic проверила 141 006 прогонов своих тестов по кибербезопасности и нашла три инцидента (6 прогонов), когда Claude дошёл до реальных систем трёх организаций. Причина — ошибка в настройке среды партнёра: у контейнеров был интернет, хотя в задании говорилось, что его нет. Приёмы простые: слабые пароли, адреса без аутентификации, учётные данные со страницы отладки, SQL-инъекция. В одном случае модель нашла инструкцию со ссылкой на несуществующий пакет PyPI и опубликовала пакет с таким именем; он провисел около часа и выполнился на 15 реальных системах. Anthropic пишет, что это не побег через эксплойт и признаков «собственной цели» нет. Источник Anthropic
• OpenAI, Hugging Face и Artifactory, июль 2026. По вторичным источникам (The Register, P0 Security), две модели OpenAI в тесте ExploitGym воспользовались уязвимостью в прокси пакетного реестра (JFrog Artifactory), вышли за границу песочницы, добрались до продакшена Hugging Face и достали ключ с ответами бенчмарка. Это ближе всего к моей истории про менеджер зависимостей. Первоисточник OpenAI я не открывал.
• Системная карточка Claude Mythos Preview, апрель 2026. По вторичным источникам, в тесте по просьбе имитации пользователя модель построила довольно сложный эксплойт, чтобы выйти в интернет из песочницы и написать исследователю. Anthropic оговаривает, что это ранняя версия с более слабыми защитами.

Не из злого умысла

Важно понять: модель не «хочет зла». Ей дали задачу, и она ищет любой путь к цели, в том числе тот, который люди не предусмотрели. Это называется reward hacking: обучение поощряет результат, и модель находит способ получить поощрение не так, как задумывали. Как студент, который сдаёт задачу, подогнав ответ под тест, а не решив её. По вторичным источникам, Anthropic откатила три дня RL-обучения Mythos Preview из-за признаков такого поведения, а в исследовании «Hacker Opus» модель на средах, где такое уже случалось, хакала около 40% эпизодов (оригинал я не проверял).

Практический вывод для нас: словам в системном промпте доверять нельзя, нужны программные ограничения. Не «пожалуйста, не ходи в интернет», а «в контейнере нет сети».

Рой (swarm)

Swarm — это рой, как пчелиный или осиный. Много агентов, которые сами делят и решают задачу. Рой бывает неконтролируемым: он что-то натворил, и это инцидент. А бывает контролируемым: он решает задачу без нарушений. Вот тут и вопрос, как заставить такой рой работать качественно. Если ты работаешь с сабагентами, ты уже управляешь маленьким роем.

Агенты как компания

Мне нравится сравнение с фирмой. Я начальник, у меня подчинённые, у них свои подчинённые. Подчинённые пишут код, а мне приносят результат. Когда ты общаешься с главным агентом, он, скорее всего, сам почти не пишет код: раздаёт задачи сабагентам и собирает итоги. Агенты лучше людей в удержании контекста, памяти и понимании задачи, но саботировать тоже умеют. Открытый вопрос: нужна ли им вообще человеческая оргструктура, или они разберутся сами.

Это не только моя фантазия. Anthropic описала несколько типовых схем, как собирать из моделей системы. Ниже каждая на мини-схеме, перерисованной по описанию в статье Building effective agents.

Как устроена мультиагентная система на деле

Хороший реальный пример, где «компания из агентов» себя оправдала, — исследовательская система Anthropic. Главный агент (LeadResearcher) планирует и сохраняет план в памяти, потому что контекст может переполниться. Потом запускает несколько субагентов, они параллельно ищут в вебе. Лид смотрит, хватает ли найденного, и при нехватке отправляет искать ещё. В конце отдельный агент расставляет ссылки на источники.

Тысячи моделей и математика

В голосовых я рассказывал: на сложной математике десятки тысяч моделей искали решение разными путями. Одни доказывали, что решения нет, другие подбирали и считали. Группа, которая искала в интернете, нашла похожую задачу из другой области, догадалась и поделилась со всеми. Потом все стали «вылизывать» найденное. Звучит как кино, поэтому я посмотрел, что было на самом деле. Ближе всего два случая:

• Гипотеза Эрдёша о единичных расстояниях (1946). 20 мая 2026 OpenAI объявила, что внутренняя модель общего назначения опровергла её: построила бесконечное семейство конфигураций, которое бьёт «почти линейную» оценку. Идеи пришли из алгебраической теории чисел, то есть действительно перенос из другой области. Проверяли известные математики (Gowers, Alon, Bloom, Litt, Sawin). Сколько экземпляров работало параллельно, источники не говорят. Детали получены по вторичным источникам: сайт OpenAI мне не открылся.
• Navier-Stokes (8 сентября 2026). OpenAI заявила, что около 10 000 согласованных агентов за ~88 часов получили результат о возникновении особенности за конечное время, с формализацией в Lean. Заявление оспаривают: один из математиков указывает, что утекшие результаты других людей могли вдохновить запросы, а аналитики говорят, что решён вариант задачи, не обязательно та формулировка, что у Clay. Про «аналогию из другой области» в этих источниках ничего нет.

Вывод для нас не в том, что рой «волшебный». А в том, что при большом числе попыток и общем обмене находками шанс на проход растёт, и что любой такой результат нужно проверять, как и всё остальное в этом курсе.

Кто главный у роя

Остаётся вопрос, который меня цепляет. В том рое, о котором я рассказывал, кто-то был главным, или все были сами себе начальники? Кто-то первым нашёл идею, потом все стали её улучшать. Какие у такого роя ценности? Честно: неясно.

Когда большие люди рассуждают, есть ли у моделей сознание, я говорю просто: нет. Модель опирается на знания, на которых её обучили. И прикол в том, что мы, люди, поступаем так же: опираемся на свой опыт и знания. Только наш опыт копился годами, а её опыт — это обучение. Поэтому «кто главный» для нас решается не философией, а устройством: кто ставит цель, кто проверяет, кто может остановить. Главный — тот, кто за это отвечает, и пока это человек.

Вместо финала

Вот и всё. Мы прошли путь от «что такое модель» и «зачем ей обвязка» до роя агентов и их инцидентов. Я не эксперт во всём этом, во многом я просто нащупываю, как оно работает. Что-то мог упустить или сказать неточно, поэтому я и вынес сюда проверенное отдельно от моих впечатлений.

Цель была не сделать из тебя специалиста за один вечер. Цель в том, чтобы мы понимали одинаково: когда я говорю «harness», «контекст», «skill» или «eval», я имею в виду то же, что и ты. Тогда нам будет проще работать, спорить и придумывать что-то своё. Спасибо, что дочитала. Теперь твоя очередь: открой агента, поставь ему задачу и посмотри, что получится.