PROMTLY

Занятие 3 - Хуки, Субагенты

Опубликовано: 28 июня 2026 г.

0. Перед оркестрацией: три сюжета с разбора домашних работ

0.1. Два экстремума в работе с ИИ (и золотая середина)

Прежде чем уходить в технику, зафиксируем рабочую философию, потому что без неё все субагенты бесполезны.

Суть Есть два опасных полюса.

Полюс 1 — человек умеет работать с ИИ, но по привычке делает руками то, что давно пора делегировать («да я по старинке»). Полюс 2 (сейчас встречается всё чаще) — человек делает всё через ИИ, но не читает то, что ИИ произвёл: сгенерировал файл, не глядя переслал, не проверил. Здоровая середина: делегируй максимально много, но либо проверяй сам, либо строй систему агентов, которая проверит за тебя.

Это не лирика, а прямой мостик к теме урока: когда у вас на машине параллельно работают 3–4 агента и часть задач вы не можете провалидировать лично (не хватает экспертизы), вы выстраиваете отдельный слой агентов-валидаторов. Ровно это мы сегодня и научимся делать.

Метод Фейнмана Представьте завод с роботами-сборщиками.

Полюс 1 — мастер, который не доверяет роботам и точит каждую деталь напильником вручную. Полюс 2 — мастер, который запустил конвейер и ушёл пить кофе, не поставив на выходе ни одного контролёра ОТК; с ленты едет брак, а он не знает. Золотая середина — конвейер работает на полную, но в конце стоит робот-контролёр с лазерным сканером, который отбраковывает мусор. Сегодня мы собираем этого робота-контролёра.

0.2. Какие задачи идеально ложатся на skills (на примере разобранных работ)

Из десятков присланных учениками скиллов (skills) виден один общий паттерн, по которому стоит сверяться.

Когда задача создана для скилла Скилл идеален там, где есть

повторяющийся вход → повторяющийся выход. Примеры из разбора: подготовка тендерных документов в закупках, анализ юридических договоров, адаптация резюме под вакансию (CV Tailor), генерация QR-кодов под каждую новую группу курса, перевод узкоспециализированных текстов с сохранением терминологии, оценка DISC-профиля кандидата против профиля команды, диагностика проблем в Linux по выводу команды. Каждый раз: одинаковая форма запроса, одинаково качественная обработка.

Два практических нюанса, которые прозвучали:

  1. Скилл — это не «просто промпт». На старте кажется, что скилл = текстовая инструкция «сделай вот так». Но скилл умеет запускать код: профессиональные скиллы автора почти все дёргают Python-скрипты (python), а значит могут генерировать mp3, картинки, qr-коды, парсить таблицы — всё, что умеет код.
  2. Слабое место LLM — написание текста. Парадокс: «большие языковые модели» (large language models) хуже всего справляются именно с художественным/живым текстом. Самые сложные и так и не доведённые до идеала скиллы автора — те, что связаны с writing (написанием).
Определение: Skill (скилл, навык)

Skill — переиспользуемая упаковка из инструкции (Markdown), вспомогательных материалов и иногда рабочих скриптов, которую агент сам подхватывает, когда задача совпадает с описанием скилла. Минимально валидный скилл — это файл SKILL.md с обязательными полями name (имя) и description (описание) в строго заданном формате; всё остальное опционально.

0.3. Самоулучшающиеся скиллы (self-improving skills)

Прозвучала концепция от компании Cognee1: скиллы, которые сами себя чинят по результатам работы.

flowchart LR
    A["1️⃣ Загрузка всех скиллов<br/>в граф знаний<br/>(семантика + связи)"] --> B["2️⃣ Наблюдение<br/>задача · какой скилл выбран ·<br/>успех/ошибка · фидбэк юзера"]
    B --> C["3️⃣ Анализ<br/>прошлые запуски, ошибки,<br/>повторяющиеся слабые места"]
    C --> D["4️⃣ Создание изменений<br/>сужаем триггер · меняем шаги ·<br/>правим формат вывода"]
    D --> E["5️⃣ Ревью + эволюция тестами<br/>человек или авто-режим"]
    E -->|результат лучше| F["6️⃣ Обновление скилла<br/>до новой версии"]
    F -.->|цикл повторяется| B
Важно: не «дообновить» до поломки Многие наивные системы самоулучшения работают грубо: «раз в неделю прочитай мои сообщения и обнови скиллы». Опасность —

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

Метод Фейнмана Это

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

1. Микро-фича CLI: переключение между сессиями стрелкой влево

Маленькая, но удобная новинка именно в Claude Code CLI (терминальной версии).

Суть Когда у вас открыт пустой экран Claude в терминале, нажатие

стрелки влево (←) открывает меню всех параллельных сессий. Из одного окна терминала вы прыгаете в любую сессию и обратно, а сессии в это время продолжают работать в фоне. Вы дали задание одной, ушли в другую, вернулись — первая уже что-то сделала.

Важно Это

не управление агентами, а управление сессиями. И на момент лекции фича работала только в CLI (не в desktop-версии) и появилась буквально за неделю до занятия. Реальная польза — для тех, у кого одновременно крутится 6–8 сессий (так работают, например, сами разработчики Claude Code: восемь окон на двух мониторах). Если вы, как автор, держите «миксы» (одна сессия Claude Code в терминале + Codex в приложении + Cowork), эта фича вам почти не нужна.

Метод Фейнмана Вы — охранник перед стеной

CCTV-мониторов в киберпанк-небоскрёбе. Раньше у каждой камеры был свой пульт. Теперь — один джойстик и стрелка влево листает камеры. Пока вы смотрите на камеру №3, камеры №1, 2, 4 продолжают писать. Вы не управляете тем, что в кадре, — вы просто переключаете взгляд.

2. Субагенты (Subagents) — главный рабочий инструмент

2.1. Техническое погружение

Определение: Subagent (субагент)

Субагент — изолированный экземпляр Claude, которого запускает ваш главный агент-оркестратор (тот, с кем вы общаетесь). У субагента своё, чистое контекстное окно, свой системный промпт, свой набор инструментов и свои разрешения. Он уходит, делает узкую задачу в своём окне, и возвращает главному агенту только финальное сообщение — короткую выжимку. Вся «грязь» (прочитанные файлы, логи, результаты поиска) остаётся внутри субагента и никогда не попадает в ваш основной диалог.

Зачем это нужно — на конкретном примере. Допустим, вам надо: (а) проанализировать код, (б) поискать в интернете, как решается такая задача, (в) сходить в документацию.

Как было ДО субагентов:

flowchart TD
    M["🧠 Главный агент<br/>(одно контекстное окно)"]
    M --> R1["📖 читает код<br/>+50% окна забито"]
    R1 --> R2["🌐 ищет в интернете<br/>+30% окна забито"]
    R2 --> R3["📚 читает документацию<br/>окно почти полное"]
    R3 --> X["⚠️ срочно компактить контекст<br/>детали теряются"]

    style X fill:#ff6b6b,stroke:#c92a2a,color:#fff

Как стало С субагентами:

flowchart TD
    M["🧠 Главный агент<br/>(окно остаётся чистым)"]
    M -->|"задача: разберись в коде"| S1["🤖 Субагент A<br/>своё окно забивает кодом"]
    M -->|"задача: найди в вебе"| S2["🤖 Субагент B<br/>своё окно забивает поиском"]
    M -->|"задача: прочти доки"| S3["🤖 Субагент C<br/>своё окно забивает доками"]
    S1 -->|"короткий ответ"| M
    S2 -->|"короткий ответ"| M
    S3 -->|"короткий ответ"| M
    M --> OUT["✅ В окне главного:<br/>3 вопроса + 3 коротких ответа.<br/>Идеально эффективно."]

    style OUT fill:#51cf66,stroke:#2f9e44,color:#000

В окне главного агента вместо мегабайтов документации остаётся лишь «вопрос → короткий ответ». Это и есть суть изоляции контекста.

Когда субагенты включаются Чаще всего —

сами, без вашего ведома. Вы можете явно попросить («обязательно запусти субагентов»), но обычно главный агент додумывается сам. Классические триггеры: параллельное исследование нескольких тем, изучение большого кода, узкоспециализированные задачи (полазить в SQL-базе, прогнать security-проверку) — то, что нужно делать скрупулёзно и что «съест» кучу контекста.

2.2. Сильный приём: субагент как беспристрастный судья (LLM as a judge)

Суть Для многих скиллов нужна оценка результата — это паттерн

LLM as a judge (модель в роли судьи). Проблема: если результат оценивает ваш основной агент, он делает это с грузом всего своего контекста. Оценка получается предвзятой — не обязательно плохой, но точно не трезвой и не объективной.

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

Метод Фейнмана Представьте суд, где

судья — это подсудимый, который весь день сам с собой обсуждал дело. Он физически не может судить непредвзято. Поэтому вы вызываете присяжного из криокамеры (субагент с чистым контекстом): его только что разморозили, он не слышал ни слова из прений, ему показывают улики — и он выносит холодный, честный вердикт. Чистота контекста = беспристрастность.

2.3. Ограничения субагентов (с экспертными правками!)

Автор перечислил ограничения. Часть из них устарела — фиксируем актуальную картину.

Экспертная правка №1: субагенты ТЕПЕРЬ могут порождать субагентов В лекции прозвучало: «субагенты не могут порождать других субагентов».

На текущий момент это уже не так. Согласно официальной документации Claude Code, начиная с версии v2.1.172, субагент может запускать собственных субагентов, а вложенность поддерживается до пяти уровней в глубину. Используется это, когда делегированная задача сама распадается на параллельные подзадачи (например, агент-ревьюер раздаёт по верификатору на каждую найденную проблему), и промежуточный вывод не доходит до основного диалога. Так что историческое ограничение, на котором автор строил аргумент про тестирование, снято — хотя обходной приём через claude -p (см. ниже) по-прежнему рабочий и иногда удобнее.

Экспертная правка №2: Task tool → Agent tool Автор упоминает запуск субагента «массовым» вызовом (исторически — инструмент

Task). Уточнение: в версиях до v2.1.63 делегирование шло через инструмент Task, сейчас оно идёт через инструмент Agent. На поведение для вас это почти не влияет, но если читаете чужие старые гайды и видите Task tool — это он же, переименованный.

Остальные ограничения, которые автор назвал, — актуальны:

  • Субагенты не общаются друг с другом. Они докладывают только главному агенту, между собой связи нет. (Это ключевое отличие от Agent Team, см. раздел 3.)
  • Расход токенов ~ в 4–7 раз выше обычной сессии. ✅ Подтверждено: независимые источники называют ориентир «примерно ×7 токенов» для субагент-нагруженных воркфлоу, потому что каждый субагент держит своё контекстное окно и отдельного биллинга при этом нет — платите объёмом токенов. На не-Max плане лимиты выгорают быстро; 2 субагента — норм, 12 — уже больно.
  • Работают в фоне. Вы не видите «изнутри», что они делают.
  • Для простых задач не нужны. Не плодите субагентов на каждый чих.
Полезное дополнение: команда

/btw Для быстрого вопроса по тому, что уже есть в диалоге, субагент избыточен. В Claude Code есть лёгкая команда /btw (от «by the way»): она видит ваш полный контекст, но не имеет доступа к инструментам, а её ответ не добавляется в историю. Дёшево и чисто.

Метод Фейнмана Субагент — это

дрон-разведчик, посланный в токсичное болото данных. Он заходит по уши в жижу (забивает своё окно логами и файлами), выковыривает один золотой самородок, сжигает себя и отправляет вам самородок по запаянной пневмопочте. Ваши руки (контекст главного) остаются стерильными. Раньше у дрона был запрет «не клонировать себя» — теперь запрет сняли, и дрон может отрастить пять поколений дронов-внуков, чтобы прочесать болото параллельно.

3. Agent Team (Команды агентов) — экспериментальный режим

3.1. Чем команда агентов отличается от субагентов

Определение: Agent Team (команда агентов)

Agent Team — экспериментальный режим, где несколько полноправных, независимых сессий Claude Code работают вместе. В отличие от субагентов (которые «сходил-доложил-исчез»), участники команды — это самостоятельные агенты со своими контекстными окнами, общим списком задач и возможностью напрямую общаться друг с другом через общий «почтовый ящик» (mailbox).

flowchart TB
    subgraph TEAM["👥 AGENT TEAM — равноправная команда"]
        direction LR
        TL["🧭 Team Lead<br/>координирует, ставит задачи"]
        A1["🤖 Агент Frontend"]
        A2["🤖 Агент Backend"]
        A3["🤖 Агент QA"]
        A1 <-->|"переговоры:<br/>«подожди, я доделаю,<br/>чтоб не сломать тебе»"| A2
        A2 <-->|общий список задач| A3
        TL --> A1
        TL --> A2
        TL --> A3
    end

    subgraph SUB["🛰️ SUBAGENTS — подчинённые дроны"]
        direction LR
        M["🧠 Главный агент"]
        S1["🤖"] -->|доклад| M
        S2["🤖"] -->|доклад| M
        S3["🤖"] -->|доклад| M
        M --> S1
        M --> S2
        M --> S3
    end

    style TEAM fill:#e7f5ff,stroke:#1971c2
    style SUB fill:#fff4e6,stroke:#e8590c

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

3.2. Включение и стоимость

Как включить Это экспериментальная опция, её надо включить в

settings.json. Автор называет её как «claude code experimental agent teams».

Уточнение по факту: переменная окружения называется CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, и для работы требуется Claude Code v2.1.32+. По умолчанию режим выключен.

Важно: цена кусается особенно сильно Если субагенты — это «в несколько раз дороже», то Agent Team — это

сразу ×10 и больше по токенам. На Pro-плане нет смысла даже пробовать — лимит выгорит мгновенно.

3.3. Как это увидеть глазами (демо)

В обычной работе команда агентов выглядит никак: всё происходит в фоне, главный агент лишь периодически пишет «сейчас посмотрю, что они делают». Чтобы увидеть их в отдельных окнах, на Mac автор использует терминальный мультиплексор cmux2.

Ключ к демо — фраза «в сплит-окнах» Запрос строится так:

«Запусти команду из трёх agent-team, пусть каждый погуглит про X, и обязательно запусти их в сплит-окнах (split windows)». Без волшебной фразы «в сплит-окнах» агенты уйдут в фон, как обычные субагенты. С ней — Claude раскидывает по агенту на отдельное окно cmux (School Researcher, Teacher Researcher, Cross Researcher), они параллельно ищут, и по завершении главный их закрывает.

Важно: честная оценка автора Автор прямо признаёт:

в реальной работе он Agent Team не использует — «не было ещё ни одного проекта, где бы я его по-настоящему применил». Технология сырая и нестабильная (на занятии она ломалась). Когда доходит до по-настоящему сложных проектов, он идёт другим путём (см. раздел 6).

Экспертная правка №3: платформа уже «съела» ручную оркестрацию Контекст, которого в лекции не хватает: в конце мая 2026 Anthropic выкатила

Dynamic Workflows (динамические воркфлоу). Вместо того чтобы вручную городить cmux со сплит-окнами или писать bash-циклы, Claude сам пишет JavaScript-скрипт оркестрации, разворачивает десятки–сотни параллельных субагентов, валидирует и итерирует до сходимости. План оркестрации и промежуточные результаты живут в переменных скрипта, а не в контексте модели — это даёт масштаб без потери смысла. Иными словами, многие «эксперименты со сплит-окнами» сегодня — это скорее наглядная демонстрация, чем продакшен-инструмент: нативная оркестрация ушла вперёд.

Метод Фейнмана Субагенты — это

рой одноразовых дронов с одной королевой: слетали, отдали мёд, испарились. Agent Team — это команда взломщиков сейфа из киберпанк-боевика. Каждый — полноценный оперативник со своей рацией. Они переговариваются вживую: «Не вскрывай вентиляцию, пока я не вырублю сигнализацию». У них одна доска с задачами на всех. Свободы больше — но и топливо (токены) они жгут как реактивный ранец, а не как карманный фонарик.

4. Практика: скилл, который оркестрирует субагентов

Это сердцевина занятия и основа домашки. Делаем скилл-исследователь (research skill): он принимает запрос, дробит его и запускает трёх субагентов, каждый ищет в своём источнике.

4.1. Архитектура

flowchart TD
    U["👤 Пользовательский запрос<br/>(тема для ресёрча)"] --> SK["📜 Skill-оркестратор<br/>(SKILL.md)"]
    SK -->|декомпозиция на 3 подзапроса,<br/>параллельный запуск в одном сообщении| P{{"параллельно"}}
    P --> W["🌐 Web Researcher<br/>инструменты: Tavily MCP,<br/>Tavily CLI, WebFetch"]
    P --> H["📰 Hacker News Researcher<br/>инструменты: Hacker News API,<br/>Tavily"]
    P --> T["🐦 Twitter Researcher<br/>инструмент: Bird CLI"]
    W -->|JSON-структура| AGG["🧮 Главный агент:<br/>фильтрует · дедуплицирует ·<br/>кластеризует по темам"]
    H -->|JSON-структура| AGG
    T -->|JSON-структура| AGG
    AGG --> MD["📄 Итоговый Markdown-отчёт"]

    style SK fill:#e7f5ff,stroke:#1971c2
    style AGG fill:#fff3bf,stroke:#f08c00
    style MD fill:#d3f9d8,stroke:#2f9e44
Ключевая фишка архитектуры У

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

4.2. Из чего состоит субагент (файлово)

Субагенты лежат рядом со скиллом в папке agents/, каждый — отдельный Markdown-файл.

research/                 ← папка скилла
├── SKILL.md              ← главный скилл-оркестратор
└── agents/
    ├── web-researcher.md
    ├── hacker-news-researcher.md
    └── twitter-researcher.md

В настройках каждого субагента (в YAML-шапке файла) можно задать:

  • model — какую модель использует субагент: Haiku, Sonnet или Opus. Если модель не указана — субагент наследует модель главного (у автора это Opus). Для простого поиска часто разумно поставить Sonnet (дешевле/быстрее); для глубоких рассуждений — Opus.
  • tools — доступ только к нужным инструментам.
  • При желании — свои хуки (см. раздел 5) и доступы.
Определение: инструменты поиска из демо

Tavily — поисковый сервис/MCP для веба и тематических сайтов. WebFetch — стандартный веб-поиск/загрузка страниц. Hacker News API — доступ к обсуждениям на Hacker News. Bird CLI (в речи также «BERT CLI») — неофициальный command-line interface (интерфейс командной строки) для Twitter, работающий с вашими cookies (то есть от вашего авторизованного аккаунта). Apify (в речи «Epify») — мощный, но платный сервис парсинга/поиска.

Создавать субагентов вручную почти не нужно Технически есть команда

/agents (посмотреть установленных или create new agent). Но автор справедливо отмечает: проще попросить Claude создать субагента словами — он всё сделает сам. Ручное создание оправдано редко.

Важно про эвалы «Правильный» скилл с субагентами должен иметь

эвалы (evals) — но их прогон очень долгий. Автор честно говорит: создание хорошего скилла с тестами может занимать часы; сложные он иногда оставляет на ночь — Claude выжигает один 5-часовой лимит, утром получает «продолжай» и выжигает следующий. Это нормально: качественный комплексный скилл рождается долго.

Метод Фейнмана Скилл-оркестратор — это

диспетчер новостной редакции в день сенсации. Он не бежит сам по всем источникам. Он раздаёт трём репортёрам по заданию: один роет архив (Web), второй сидит на форумах (Hacker News), третий мониторит соцсети (Twitter). Каждый приносит уже отжатую заметку (JSON), а редактор сшивает их в одну полосу, вычёркивая повторы. Магия не в том, что один супер-журналист всё знает, а в том, что трое работают параллельно и каждый держит свою грязь при себе.

4.3. «У ИИ нет ограничений на объяснение»

Важная мета-мысль из практики: если вам что-то непонятно (код, архитектура, чужой скилл) — просто попросите агента объяснить. Он нарисует схему, разложит логику, покажет, как работает каждый субагент (какие у него инструменты, какой формат ответа). Не нужно стесняться «непонятных» мест — попросите визуализацию, и поймёте всё (см. также раздел 8 про HTML-артефакты).

5. Хуки (Hooks) — детерминированная автоматизация жизненного цикла

5.1. Техническое погружение

Определение: Hook (хук, перехватчик)

Hook — автоматическое действие (shell-команда, HTTP-endpoint или промпт к LLM), которое срабатывает на конкретное событие в жизненном цикле Claude Code: до/после использования инструмента, на отправку промпта пользователем, на старт сессии, до/после компакта контекста и т. д. В отличие от инструкций в промпте (которые модель может интерпретировать или проигнорировать), хук выполняет детерминированный код — он не может «нагаллюцинировать».

Хуки вызываются через /hooks. Автор сначала говорит «их пять… ой, больше», и это правда: событий несколько десятков (порядка двух-трёх десятков точек жизненного цикла). Их удобно сгруппировать вокруг ключевых моментов:

flowchart LR
    SS["SessionStart<br/>старт сессии"] --> UP["UserPromptSubmit<br/>юзер отправил промпт"]
    UP --> PRE["PreToolUse<br/>ПЕРЕД инструментом"]
    PRE --> TOOL["🛠️ Инструмент<br/>(напр. Bash)"]
    TOOL --> POST["PostToolUse<br/>ПОСЛЕ инструмента"]
    POST --> PC["PreCompact / PostCompact<br/>до/после сжатия контекста"]
    PC --> STOP["Stop / SubagentStop<br/>агент решил, что закончил"]

    style PRE fill:#ffe3e3,stroke:#e03131
    style STOP fill:#fff3bf,stroke:#f08c00

5.2. Реальные применения хуков

  • Блокировка опасных команд. PreToolUse перехватывает rm -rf (удаление всего с диска) до выполнения и блокирует её. Так строится «защита от себя».
  • Автоформатирование кода. После редактирования файла (PostToolUse) автоматически запускается Prettier или Ruff — код всегда отформатирован.
  • Уведомления и звуки. Claude закончил работу или кончаются токены — приходит push/голос/звук. (Фан-фаворит автора — звуки из Warcraft, «нужно больше золота», когда заканчиваются токены.)
  • Сканер безопасности. Можно встроить маленькие ML-модельки, проверяющие каждую команду на prompt injection (внедрение вредоносной инструкции).
  • Логирование и аудит. Каждая команда пишется в лог с временной меткой.
  • Проверка качества кода. Запуск ESLint, TypeChecker и подобных.
  • Stop Hook — «не дать остановиться». Claude решил, что закончил, → хук спрашивает LLM: «а тесты прошли? все задачи точно сделаны?» Если нет — Claude продолжает. ⚠️ Обязательно опишите условие выхода, иначе цикл не закончится никогда (это фундамент Ralph Loop — см. раздел 6).
  • Связь субагентов хуками — теоретически возможно, но автор честно называет это костылём.
Важно: кому это нужно Хуки — это уже

профессиональная разработческая история. Если вы строите весь рабочий процесс вокруг агентов, они незаменимы. Но автор (по собственному признанию — не профессиональный разработчик) использует их «совсем чуть-чуть». Если перечисленные термины (ESLint, Prettier, git hook) вам ничего не говорят — возможно, хуки вам пока просто не нужны. Хуки, кстати, появляются и в других инструментах (в Codex тоже).

Метод Фейнмана Хук — это

спинномозговой рефлекс, вшитый в нервную систему агента. Когда рука летит к раскалённой плите (rm -rf перед выполнением), мозг (LLM) ещё ничего не успел подумать — а рефлекторная дуга (хук) уже отдёрнула руку. Рефлекс не «думает» и потому не может ошибиться в интерпретации: он либо срабатывает, либо нет. Промпт — это уговор с мозгом («постарайся не трогать плиту»), а хук — это сухожилие, которое физически не даст её коснуться.

6. Автономная разработка: Ralph Loop → Ralphix → Compound Engineering

Это «другой путь», которым автор идёт для по-настоящему сложных проектов вместо Agent Team. Три уровня, от примитивного к мощному.

6.1. Ralph Loop — гениальная тупость

Определение: Ralph Loop (цикл Ральфа)

Ralph Loop — паттерн автономной разработки: один и тот же промпт подаётся агенту заново снова и снова, пока задача не будет выполнена. Назван в честь Ральфа Уиггама (Ralph Wiggum) из «Симпсонов»3 — потому что это не «умная» система, а брутфорс: не клевер, а упорство.

flowchart TD
    P["📝 Один и тот же prompt<br/>+ completion-promise<br/>+ max-iterations"] --> WORK["⚙️ Claude работает:<br/>пишет код, гоняет тесты"]
    WORK --> TRY["Claude думает, что закончил →<br/>пытается завершить сессию"]
    TRY --> SH{"🪝 Stop Hook:<br/>completion-promise<br/>выполнен?"}
    SH -->|"ДА"| DONE["✅ Задача завершена"]
    SH -->|"НЕТ"| P

    style DONE fill:#d3f9d8,stroke:#2f9e44
    style SH fill:#fff3bf,stroke:#f08c00

Запуск (после установки официального плагина):

/ralph-loop "<твой промпт>" --max-iterations 50 --completion-promise "DONE"

Каждая итерация — свежая сессия с чистым контекстом, но она видит изменённые файлы и git-историю прошлых прогонов. Память живёт не в окне модели, а во внешних файлах (progress.txt, git).

Экспертная правка №4: про надёжность и авторство Два уточнения, которых нет в лекции.

  1. --completion-promise ненадёжен сам по себе: он использует точное строковое совпадение, что легко срывается. Реальной страховкой является --max-iterations — всегда его ставьте, иначе цикл может крутиться бесконечно (и жечь токены/деньги).
  2. Автор техники — Geoffrey Huntley (он же придумал и название «Ralph Wiggum»). В лекции упомянут только мультяшный источник имени, но не сам изобретатель. Хантли же сформулировал девиз паттерна: «Лучше предсказуемо провалиться, чем непредсказуемо преуспеть» — то есть детерминированно-плохой подход в недетерминированном мире надёжнее, потому что ошибки становятся данными для следующей итерации.
Метод Фейнмана Ralph Loop — это

золотая рыбка с амнезией и бесконечным упрямством. Каждый круг по аквариуму она забывает всё (чистый контекст), читает стикеры на стекле (git и progress.txt), снова бьётся о задачу. Она не гениальна — она просто никогда не сдаётся. И именно тупая предсказуемость делает её надёжной: вы заранее знаете, что она будет долбить стену, пока та не рухнет (или пока не кончатся max-iterations).

6.2. Ralphix — Ralph Loop + взаимный код-ревью с Codex

На основе Ralph Loop работает то, что использует автор, — Ralphix4.

flowchart TD
    PLAN["📋 Фаза 0: Планирование<br/>подробный план задач"] --> CREATE["🏗️ Фаза 1: Создание<br/>git-ветка; по каждой задаче —<br/>свежая сессия → тесты/линтер → commit"]
    CREATE -->|все задачи готовы| INT["🔍 Фаза 2: Внутренний ревью<br/>Claude сам тестирует:<br/>качество, корректность"]
    INT --> EXT["🔁 Фаза 3: Внешний ревью<br/>Codex читает работу Claude,<br/>предлагает правки → диалог"]
    EXT -->|"Claude и Codex сошлись во мнении"| FIN["🏁 Финализация"]
    EXT -.->|"итерации правок"| EXT

    style FIN fill:#d3f9d8,stroke:#2f9e44

Ключевые особенности:

  • Вся схема — полностью автономна и работает в Docker-изоляции (изолированные виртуальные контейнеры), куда подключены и Claude Code, и Codex.
  • Codex как ревьюер — лучший инструмент для ревью кода (по мнению автора). Claude и Codex переговариваются, Claude правит замечания, пока оба не решат «всё ок» (или не упрутся в тупик — на практике у автора всегда сходились).
  • Рассчитано на часы автономной работы. Один из багфиксов в официальном Ralphix — авторства самого лектора: Claude Code в связке с Ralphix нашёл баг, а лектор попросил агента «по-человечески» написать о нём создателю проекта (Умпутуну).
Важно: топливо Это

гигантский расход токенов. Без Max 200 пробовать не рекомендуется. Это плата за «дал план — ушёл — вернулся к готовому коду».

6.3. Compound Engineering — приумножение знаний

Самый мощный фреймворк, который автор лично использует и которому учит профессиональных разработчиков. Сделан компанией Every5.

Определение: Compound (приумножение, наслоение) В русском нет точного перевода.

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

Шесть ключевых этапов (подключается через /plugins → compound-engineering):

flowchart TD
    I["1️⃣ Ideate /ce ideate<br/>критическая оценка сырой идеи →<br/>артефакт ranked ideation"] --> B["2️⃣ Brainstorm /ce brainstorm<br/>AI задаёт вопросы, вы отвечаете →<br/>ключевые концепции"]
    B --> P["3️⃣ Plan<br/>запускает 6–7 субагентов +<br/>субагент-перепроверщик плана<br/>🔥 токены начинают улетать"]
    P --> W["4️⃣ Work<br/>новый git worktree,<br/>пошаговая имплементация → pull request"]
    W --> R["5️⃣ Review<br/>28 ревью-агентов под разные языки<br/>(Python, TypeScript, Swift…)<br/>🔥 ещё больше токенов"]
    R --> C["6️⃣ Compound<br/>AI создаёт артефакты по всем находкам:<br/>проблемы, решения, архитектура"]
    C -.->|"следующий проект<br/>читает Compound-артефакты<br/>и стартует уже 'умным'"| I

    style C fill:#d0bfff,stroke:#7048e8
    style P fill:#ffe8cc,stroke:#f76707
    style R fill:#ffe8cc,stroke:#f76707

Разбор этапов:

  1. Ideate (/ce ideate) — для самой ранней стадии, когда есть лишь сырая идея. AI поможет её критически оценить. Результат — markdown-артефакт ranked ideation. Если идея уже есть — этап можно пропустить.
  2. Brainstorm (/ce brainstorm) — классический брейншторм: AI задаёт вопросы, вы отвечаете, рождаются ключевые концепции. Это ещё не план.
  3. Plan — здесь токены начинают улетать: запускается ~6–7 параллельных субагентов, плюс отдельный субагент перепроверяет ваш план. Дороже, но точнее.
  4. Work — создаётся новый git worktree, идёт пошаговая имплементация плана, результат — pull request.
  5. Review — 28 разных ревью-агентов под разные языки (Python, TypeScript, Swift) и аспекты (соответствие плану, схема БД, API-контракты). Каждый проверяет своё. Тут токены тоже улетают.
  6. Compound — финал, в честь которого назван фреймворк. AI анализирует все прошлые шаги и создаёт артефакты по находкам: с какими проблемами столкнулись, как решили, какие архитектурные решения приняли. В следующий раз AI прочитает эти артефакты и стартует, уже зная всю историю проекта.
Важно: реалистичные ожидания ~80% времени уходит на

планирование и review — это самые долгие этапы. Главный артефакт — сам план (очень продуманный, с правильной структурой папок). На Pro-плане пробовать бессмысленно: лимит кончится мгновенно. Чтобы это работало, нужно реально вкладываться в процесс.

Метод Фейнмана Compound Engineering — это

сложный процент, но для знаний. Обычная разработка: каждый проект начинаете с нуля, как Сизиф с пустыми руками. Здесь — каждый проект роняет в хранилище «кристаллы уроков» (артефакты Compound). Следующий проект ваш AI открывает это хранилище и начинает уже богатым: «ага, в прошлый раз мы напоролись вот на это и решили вот так». Это снежный ком, катящийся с горы и набирающий массу, — а не белка в колесе.

7. Тарификация: разделение interactive vs programmatic (с критической правкой!)

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

Определение: interactive vs programmatic use

Interactive use (интерактивное использование) — когда за пультом сидит человек и работает с агентом вживую (терминальный Claude Code, чат, Cowork). Programmatic use (программное использование) — когда процесс запускает код, а не человек: claude -p (headless-режим), Claude Agent SDK, Claude Code GitHub Actions, сторонние приложения на SDK. Простое правило: если человек жмёт Enter — это interactive; если Enter за вас жмёт робот — это programmatic.

Что было анонсировано на 15 июня 2026:

  • Programmatic-использование перестаёт расходовать вашу подписку и переезжает на отдельный месячный кредит, тарифицируемый по полным API-ценам.
  • Размер кредита: $20 на Pro, $100 на Max 5x, $200 на Max 20x (для Team — $20/$100 за место). Кредиты не переносятся на следующий месяц. После исчерпания — usage credits по API-ценам, которые можно включать/выключать.
  • Interactive-использование (терминальный Claude Code, чат, Cowork) — без изменений.
Экспертная правка №5 (КЛЮЧЕВАЯ): изменение БЫЛО ПРИОСТАНОВЛЕНО Лекция читалась

до 15 июня и подаёт это разделение как свершившийся факт. Но 15 июня 2026 Anthropic приостановила (paused) это изменение — прямо в день, когда оно должно было вступить в силу. На текущий момент claude -p, Agent SDK и GitHub Actions по-прежнему расходуют обычные лимиты вашей подписки; отдельный кредитный пул не активен. Help-страница Anthropic теперь открывается уведомлением о паузе.

⚠️ Что при этом всё же произошло 15 июня (и осталось в силе): были сняты с поддержки два старых ID моделей (запросы к ним возвращают ошибку), а сам SDK переименован: claude-code-sdk → claude-agent-sdk. Если у вас код на старом пакете или старых model-ID — это нужно обновить независимо от паузы по биллингу. Подробный разбор тарификации — тема следующего занятия курса.

Эмоциональная оценка автора (в контексте) Автор считает решение Anthropic

ошибочным — мол, они «отворачиваются от сообщества программистов». Он же отмечает, что Умпутун (создатель Ralphix, в прошлом огромный фанат Claude Code) переписывает Ralphix под Codex. С учётом правки №5 эта тревога оказалась преждевременной: на практике пул так и не включили, и для интерактивной работы (как у большинства слушателей) вообще ничего не поменялось.

Метод Фейнмана Представьте дом с

одной трубой воды, из которой пьёте и вы (interactive), и ваш автоматический поливальный робот в саду (programmatic). Робот по ночам качал воду часами и опустошал бак, рассчитанный на «человека с кружкой». Anthropic решила протянуть роботу отдельный счётчик с дорогим тарифом… а потом, в день запуска, перекрыла этот счётчик и оставила всё как было. Старая труба работает по-прежнему. Поменяли лишь бирку на самом роботе (claude-code-sdk → claude-agent-sdk) и отключили пару устаревших насосов (старые model-ID).

8. Бонус: HTML-артефакты как способ всё понять

Финальная практическая мысль, отвечающая на вопрос «как делать схемы со стрелочками и цветными ячейками».

Суть Сами разработчики Claude Code советуют

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

Это большой новый тренд: агент отвечает вам не «стеной текста», а красивым интерактивным HTML-артефактом, который объясняет что-то именно вам. Цель — не «лучше донести инфу до модели», а чтобы модель лучше объяснила вам. Не понимаете код — попросите визуализацию.

Метод Фейнмана Раньше эксперт объяснял вам «голосом» — стеной текста. Теперь у эксперта есть

голографический проектор: он на лету рисует в воздухе светящуюся 3D-схему вашего агента, со стрелками и цветными блоками. Та же информация, но теперь она влетает через глаза, а не пробивается через абзацы.

✅ Домашнее задание

Что нужно сделать Создать

скилл, который обязательно оркестрирует группу субагентов (хотя бы 2–3, не больше — берегите лимиты). Это может быть скилл комплексного исследования, сложной обработки документов или любая задача на ваш выбор. Загрузите его, как делали раньше, и обязательно опишите словами, что именно ваш скилл делает.

Смысл задания — потренироваться создавать субагентов, которые параллельно решают разные подзадачи. На следующем занятии будем встраивать Claude Code в другие инструменты и подробно разбирать новую тарификацию.

🧭 Карта занятия одним взглядом

flowchart LR
    CTX["🎯 Управление контекстом<br/>(суть всего)"]
    CTX --> SUB["🤖 Субагенты<br/>изоляция · доклад · судья"]
    CTX --> TEAM["👥 Agent Team<br/>переговоры · общий список<br/>(дорого, экспериментально)"]
    CTX --> HOOK["🪝 Хуки<br/>детерминированные рефлексы"]
    SUB --> SKILL["📜 Скилл-оркестратор<br/>3 субагента → отчёт"]
    HOOK --> RALPH["🔁 Ralph Loop<br/>брутфорс-цикл"]
    RALPH --> RX["🐳 Ralphix<br/>+ ревью Codex, Docker"]
    RX --> CE["📈 Compound Engineering<br/>6 этапов, накопление знаний"]
    CE --> BILL["💳 Тарификация<br/>interactive vs programmatic<br/>(пауза с 15 июня!)"]

    style CTX fill:#1971c2,color:#fff,stroke:#0b4884
    style BILL fill:#e8590c,color:#fff,stroke:#9c3a06

Footnotes

  1. Cognee — компания/опенсорс-проект, специализирующийся на «памяти» для ИИ-агентов через графы знаний (knowledge graph). Идея графа знаний — хранить факты не плоским списком, а сетью узлов и связей, чтобы по ней можно было эффективно семантически искать. В лекции название звучит на слух как «когни», а «когни-граф» — это их граф навыков/памяти. ↩

  2. cmux — терминальный мультиплексор (как tmux), адаптированный для одновременной работы с несколькими ИИ-агентами в сплит-панелях. Работает только на Mac/Unix. Не путать с tmux — классическим мультиплексором терминала, на идеях которого построено множество подобных инструментов. ↩

  3. Ральф Уиггам (Ralph Wiggum) — второстепенный персонаж «Симпсонов», добрый, но недалёкий сын шефа полиции. Имя стало нарицательным для «гениально-простого» решения: не за счёт ума, а за счёт упрямого повторения. Автор техники — инженер Geoffrey Huntley. ↩

  4. Ralphix — надстройка над паттерном Ralph Loop, добавляющая структурированные фазы (планирование → создание → внутренний ревью → внешний ревью силами Codex) и Docker-изоляцию. Создана разработчиком, известным в русскоязычном IT как Умпутун (давно живёт в США). В официальном репозитории Ralphix есть багфикс авторства самого лектора курса. ↩

  5. Every (EveryInc) — медиа- и продуктовая компания, одни из самых заметных людей в области AI-разработки. Их методология Compound Engineering распространяется как официальный плагин для Claude Code (compound-engineering-plugin) и используется ими в собственной разработке. ↩