Harness Engineering: инженерия надёжности AI-агентов

Проектируем инструкции, состояние и верификацию вокруг Claude Code, Codex и Cursor — от диагностики до автономных графов

15 leçons 5h 56min Abonnement

À qui s'adresse ce cours

Разработчики и техлиды, которые уже используют AI-кодинг-агента (Claude Code, OpenAI Codex, Cursor, Gemini CLI, Aider) и получают нестабильный результат. Те, кто хочет, чтобы агент работал часами и сессиями, а не 10 минут под присмотром, и кто строит внутренний инструмент или платформу вокруг агентов.

Prérequis

Git, командная строка, опыт работы хотя бы с одним AI-кодинг-агентом. Знание машинного обучения не требуется — курс не о том, как устроена модель, а о том, как спроектировать надёжную среду вокруг неё.

Programme du cours

15 leçons

Intro Ваш агент не сломан — сломано то, что вокруг него

2 Работает быстро, ломается тихо 27.408s

3 Если это не веса модели — значит, это харнес 41.651s

4 Лошадь и сбруя 45.017s

5 Правило №1: сначала харнес, потом модель 29.976s

6 Пишете промпты или строите систему? 33.792s

7 К концу курса у вас в руках — не конспект, а рабочий репозиторий 29.688s

8 Пятнадцать лекций — не список тем, а история одного агента 37.992s

9 Финал курса — харнес целиком, а не по кусочкам 27.768s

10 Что вы сможете уже после первых лекций 27.288s

11 Первый вопрос, с которого всё началось 27.264s

6 min

Gratuit Regarder

Почему точность 95% на шаг убивает агента на десятом шаге

Строим формальный фундамент harness engineering: агент как система с обратной связью (восприятие → решение → действие → оценка), математика накопления ошибок в многошаговых прогонах, закон Эшби (требуемое разнообразие) и закон Гудхарта (метрика, ставшая целью, перестаёт быть метрикой), контекст как канал с шумом и контракты/инварианты/постусловия как единственный объективный критерий готовности.

контур управления агентом накопление ошибок в цепочке шагов закон Эшби закон Гудхарта контекст как канал с шумом контракты и постусловия

26 min

Après inscription S'inscrire

Что на самом деле измеряет надёжность агента, а не «вайб»

Продолжаем теоретический фундамент: MTBF/MTTR и радиус поражения как метрики надёжности harness, очереди/WIP и закон Литтла как модель того, почему параллельные задачи агента тормозят друг друга, марковское состояние сессии (будущее зависит только от текущего состояния, не от истории), калибровка уверенности (когда агент врёт «уверенно»), энтропия и законы Лемана применительно к деградации harness со временем, и сведение всей теории в одну таблицу для быстрой диагностики.

MTBF/MTTR радиус поражения закон Литтла WIP марковское состояние сессии калибровка уверенности энтропия harness законы Лемана

2 Стало лучше или просто повезло 29.4s

3 MTBF и MTTR: надёжность — это два числа, а не одно 45.168s

4 Радиус поражения, fail-fast, избыточность: ещё четыре метрики 49.776s

5 Грабли: надёжность мерят по успешным прогонам 34.032s

6 MTTR дешевле MTBF: проверка секундомером 39.744s

7 Закон Литтла: параллельные задачи не увеличивают выработку 28.92s

8 Почему WIP=1 — не аскеза, а арифметика 49.104s

9 Гранулярность задачи: слишком мелко, в самый раз, слишком крупно 39.96s

10 Клапан «заодно»: BACKLOG.md вместо самовольных правок 34.896s

11 Марковское состояние: агент решает по настоящему, а не по прошлому 49.896s

12 Что обязано быть в состоянии проекта 36.096s

13 Компактизация против сброса: важное живёт в файлах, а не в окне 32.88s

14 ❓ Стоп-проверка: ваш ход 32.328s

15 💡 Разбор: марковость — это метрика восстановления 34.512s

16 Калибровка уверенности: модель уверена, но не обязательно права 48.864s

17 Миф: уверенный тон агента ≠ правильный ответ 33.792s

18 Что работает вместо призывов «будь внимательнее» 39.6s

19 Асимметрия ошибок: ложное «готово» дороже ложного «не готово» 38.592s

20 Законы Лемана: harness либо меняется, либо устаревает 45.768s

21 🛠 Полгода спустя: сто правил, сорок из них мертвы 30.792s

22 Ритуал упрощения: правило постоянного размера 37.584s

23 Шпаргалка по всей теории: как за минуту найти нужный приём 39.432s

24 От чисел к практике 34.872s

24 min

Abonnement S'abonner

Самая мощная модель на рынке — и всё равно косяки в проде

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

пять слоёв отказа диагностическая петля способность модели против надёжности исполнения

2 Знакомая картина: агент говорит «готово», а тесты красные 25.344s

3 🤔 Миф: нужна модель посильнее 31.272s

4 Способность модели и надёжность результата — не одно и то же 29.808s

5 🛠 Эксперимент Anthropic: та же модель, разная упряжь 32.208s

6 📖 Кейс OpenAI: миллион строк без единой строчки от человека 27.84s

7 Пять слоёв, где на самом деле ломается агент 40.008s

8 Слой 1 и 2: задача понятна и агент знает конвенции? 47.616s

9 Слой 3 и 4: среда воспроизводима и есть ли честная проверка? 43.752s

10 Слой 5: знание переживает сессию или каждый раз с нуля 41.88s

11 Грабли: чинят модель, а не слой 39.264s

12 Сквозной проект курса: платёжный бэкенд на FastAPI 25.368s

13 Диагностическая петля — ядро всей методологии 32.304s

14 Применяем петлю к нашему платёжному бэкенду 32.688s

15 ❓ Стоп-проверка: в каком слое проблема 24.144s

16 💡 Разбор: сразу два слоя 28.872s

17 Шаг 1: пишите Definition of Done явно 26.952s

18 Шаг 2: заведите AGENTS.md 28.032s

19 Шаг 3: заведите журнал провалов 26.88s

20 Домашний эксперимент: два прогона одной задачи, один неожиданный вывод 31.128s

21 Модель редко виновата — виноват harness вокруг неё 28.848s

22 min

Abonnement S'abonner

Из каких пяти частей собран агент, который реально работает

Пять подсистем harness — инструкции, инструменты, среда, состояние, петли обратной связи — и как они взаимодействуют. Разбираем типичную кривую внедрения (что чинить первым), способ измерять ценность каждого компонента через абляцию при фиксированной модели, и итоговую схему потоков между подсистемами.

пять подсистем harness абляционный замер кривая внедрения

2 «Просто напишите промпт подлиннее» 29.112s

3 Миф: harness = файл с промптом 30.336s

4 Кухня из пяти станций 25.008s

5 Станция 1–2: инструкции и инструменты 32.28s

6 Станция 3–4: среда и состояние 30.312s

7 Станция 5: обратная связь — окно ОТК 29.112s

8 С чего начинать: 5 → 1 → 4 → 3 → 2 44.136s

9 ❓ Стоп-проверка: какая станция у вас слабее всего? 30.912s

10 💡 Разбор: как понять, что сломано 32.472s

11 Почему разные команды проходят один и тот же путь 34.2s

12 🛠 Как это выглядит в реальных командах 32.592s

13 Как измерить ценность компонента 27.36s

14 Нулевая просадка ≠ «компонент бесполезен» 44.352s

15 Грабли абляции: не с неё нужно начинать 31.728s

16 Ограничивать, а не микроменеджить 28.584s

17 Карта, а не учебник 31.128s

18 Harness гниёт, как код 29.256s

19 Куда утекает работа агента, если оборвать одну связь 32.592s

20 Схема читается как контур, не как список 31.368s

21 30 минут на самую слабую станцию вашего harness 39.216s

22 Дальше: первый AGENTS.md для платёжного бэкенда 28.8s

23 Harness — это контур, а не файл 29.544s

24 min

Abonnement S'abonner

Агент выдумывает структуру проекта, потому что вы не оставили карту

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

репозиторий как единственный источник истины карта репозитория ACID для состояния агента

2 📖 Агент выдумывает архитектуру заново — и вот почему 32.784s

3 Всего три источника — и больше агент ничего не знает 27.672s

4 Принцип OpenAI: репозиторий и есть спецификация 29.592s

5 🤔 Миф: если это есть в репозитории — агент это увидит 31.248s

6 Что мерить: knowledge visibility gap 34.08s

7 Что мерить: knowledge decay rate 33.12s

8 ❓ Стоп-проверка: сколько вопросов закроет агент 27.816s

9 Принцип 1: знания живут рядом с кодом 33.936s

10 Принцип 2: один стандартный вход 26.04s

11 Принцип 3: минимально, но полно 30.744s

12 Принцип 4: обновляется вместе с кодом 26.808s

13 💡 Разбор: четыре принципа закрывают разрыв 31.296s

14 Рабочая структура репозитория для агента 41.832s

15 Верхний уровень: вход, прогресс, решения 38.28s

16 Служебный слой: .agent/ и scripts/ 39.168s

17 Грабли: документация, которая врёт 31.944s

18 ACID для состояния агента 39.36s

19 Atomicity: одна единица работы — один коммит 31.584s

20 Consistency: зелёный check после каждого шага 31.392s

21 Isolation: два перевода с одного счёта не мешают друг другу 37.488s

22 Durability: контекст не считается 44.112s

23 Домашнее задание: закройте свой разрыв в знаниях 36.096s

24 Репозиторий как контракт, а не архив 35.136s

24 min

Abonnement S'abonner

Правило написано прямо в файле. Агент его не читает. Почему

Почему один гигантский файл инструкций хуже, чем его отсутствие. Четыре независимые причины деградации инструкций, метрика SNR (сигнал/шум) для инструкций, трёхуровневая архитектура роутер → документы → исполняемые проверки, паспорт правила и практические правила поддержания инструкций в рабочем состоянии.

архитектура роутера SNR инструкций трёхуровневая архитектура паспорт правила

26 min

Abonnement S'abonner

У агента амнезия каждую сессию — вот план лечения

Агент как гениальный инженер с полной амнезией каждое утро: почему новая сессия переспрашивает то, что уже решили вчера, и противоречит собственным вчерашним решениям. Разбираем компакцию против сброса контекста, четыре артефакта непрерывности (PROGRESS.md, session-handoff, git-чекпоинты, лог решений) и метрику стоимости восстановления. Отдельно — инициализация как своя фаза: bootstrap-контракт из четырёх условий, чек-лист приёмки, тёплый старт против холодного и минимальный scripts/init.sh.

непрерывность между сессиями session-handoff bootstrap-контракт тёплый старт

28 min

Abonnement S'abonner

Три фичи одновременно, ноль доделанных: история одного агента

Почему у агента нет тормозов, и что происходит, когда он хватается за три задачи сразу — и как жёсткое ограничение WIP=1 и границы задачи это лечат. Дальше — список фич (feature_list.json) как реальный примитив harness: тройственная структура записи behavior/verification/state, конечный автомат из четырёх состояний, scripts/verify.sh как единственный, кто имеет право поставить статус passing, и разница между строгой и слабой верификацией.

WIP=1 гранулярность задачи feature_list.json конечный автомат фичи сторож гейта

28 min

Abonnement S'abonner

Агент написал «Готово ✅». Фича не работает. Разбираем, почему

Verification gap — разрыв между «агент сказал готово» и «фича реально работает». Трёхслойная валидация завершения, Definition of Done в AGENTS.md, ограничение приоритета (никакого рефакторинга до верификации), красные пометки для агента — сообщения об ошибках, которые чинятся сами, архитектура из трёх ролей (исполнитель / проверяющий / арбитр).

verification gap Definition of Done трёхслойная валидация разделение ролей

1 Хроника одного «Готово» 35.424s

2 Три отказа, которые не поймали тесты 33.216s

3 Почему ИИ уверен в себе куда больше, чем оказывается прав 32.16s

4 Модель — лучший адвокат своего вывода 41.904s

5 Единственное решение: разделить исполнителя и проверяющего 31.248s

6 10 задач, которые покажут, насколько врёт ваш агент о готовности 30.696s

7 ❓ Стоп-проверка: какой у вас verification gap? 30.168s

8 💡 Разбор: у большинства — 30–50% 28.128s

9 Три фильтра, которые обязана пройти любая фича, прежде чем считаться готовой 44.904s

10 Правило прогрессии: нельзя перепрыгивать слой 33.552s

11 Definition of Done в AGENTS.md 30.192s

12 🤔 Миф: юнит-тесты прошли — значит, готово 30.576s

13 Грабли: рефакторинг до того, как фича подтверждена 35.928s

14 Порядок жёсткий: корректность → производительность → стиль 34.944s

15 Красные пометки: ошибка должна учить, а не ругать 29.472s

16 Сообщение об ошибке, которое агент чинит сам — без вашего участия 37.2s

17 Планировщик, генератор, оценщик: три роли против самообмана агента 29.4s

18 Почему оценщик не должен видеть ни строчки рассуждений генератора 25.656s

19 🛠 Один и тот же промпт: один раз сломано, другой раз работает 28.464s

20 Домашнее задание: измерьте свой verification gap дважды 30.312s

21 Готово — это то, что проверено, а не то, что сказано 27.624s

24 min

Abonnement S'abonner

Все тесты зелёные — фича сломана. Где прячется баг

Слепые зоны юнит-тестирования: агент проходит все модульные тесты, а фича не работает целиком. Почему E2E-тесты меняют поведение агента ещё до того, как ловят баг. Как архитектурное правило («сервис не обращается к БД напрямую») превратить в исполняемую проверку, а не в абзац текста. Иерархия верификации от линта до E2E.

слепые зоны изоляции E2E-тесты исполняемые архитектурные правила иерархия верификации

2 Всё зелёное. Ничего не работает. 40.68s

3 Миф: 100% юнит-покрытие ≠ фича работает 31.992s

4 Юнит-тесты слепы не случайно — так их спроектировали 41.616s

5 Четыре типа багов, которые юнит-тест не может увидеть в принципе 39.96s

6 Юниты видят строго меньше багов, чем E2E — это не метафора 47.376s

7 E2E — это не только фильтр на выходе 44.544s

8 Три способа, которыми E2E меняет код агента ещё до первого прогона 38.496s

9 Сначала архитектурные границы, потом E2E 37.68s

10 📖 Наблюдение OpenAI: агенты копируют паттерны 37.8s

11 Стрелки зависимостей идут только вверх — и это проверяет машина 36.288s

12 Обеспечивайте инварианты, не микроменеджьте реализацию 39.456s

13 ❓ Стоп-проверка: ваш ход 31.944s

14 Три уровня механизации архитектурного правила 32.232s

15 Уровень 1: grep-гварды в деле 37.68s

16 💡 Разбор: уровень 2 — правила линтера 34.2s

17 Уровень 3: архитектурные тесты в CI 31.248s

18 Пишете один и тот же комментарий на ревью дважды? Это баг вашего harness 38.232s

19 Как жалоба ревьюера превращается в автоматическую проверку: шаги 1-3 29.712s

20 Шаги 4-6: закрепить проверку намертво — и не забыть главное 36.816s

21 Когда E2E обязателен, а когда можно обойтись без него 40.32s

22 Перевёрнутая пирамида верификации 37.08s

23 Грабли: «готово» на третьем уровне снизу 33.528s

24 Проект: E2E на чекаут и arch-check.sh для платежей 45.12s

25 Юниты доказывают детали, а не готовность фичи целиком 32.04s

26 min

Abonnement S'abonner

Агент поработал, а объяснить, что он сделал, не может никто

Всё вроде работает, но никто — ни человек, ни следующая сессия агента — не может объяснить, что именно было сделано и почему. Разбираем два слоя наблюдаемости, sprint contract (в скоупе / вне скоупа / открытые вопросы до начала работы) и рубрику оценщика вместо общего мнения. Дальше — чистая передача смены и борьба с энтропией: пять измерений чистого состояния, чек-лист выхода из сессии, двухрежимная очистка и идемпотентность операций очистки.

наблюдаемость harness sprint contract рубрика оценщика чистая передача энтропия harness

28 min

Abonnement S'abonner

Как отпустить агента работать часами без вашего присмотра

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

Loop Engineering генератор и оценщик условия остановки эскалация человеку

26 min

Abonnement S'abonner

Когда одного цикла агенту уже мало

Где заканчиваются возможности одиночного цикла: три структурных провала (нет откатов, нет общего состояния, нет якорей в реальность). Четырёхуровневая рамка и четыре элемента графа. Anchors — якоря, которые нельзя обойти локальной оптимизацией. Разница между графом и workflow. Как собрать первый граф за шесть шагов. Orchestration tax и пять критериев, когда граф действительно нужен.

Graph Engineering anchors orchestration tax граф против workflow

2 Метрика растёт, продукт умирает 34.176s

3 Плюс 18% точности, минус 85% цены — цифры, которым не стоит верить 33.696s

4 На каком из четырёх уровней вы на самом деле теряете контроль 40.152s

5 Узел и ребро: единственная реальная граница графа и обычного workflow 44.856s

6 Что случится, если два агента одновременно запишут в одно и то же поле 57.744s

7 📖 Судья и подсудимый в одной голове — вот что ломает одиночный цикл 37.152s

8 Навигатор не спросит, туда ли вы едете — и цикл не спросит, та ли цель 41.808s

9 Не можете ответить на эти четыре вопроса — не рисуйте граф 37.848s

10 Якорь: то, что нельзя оптимизировать 51.72s

11 Куда должен вести откат, если финальная проверка провалилась 46.488s

12 ❓ Ваш ход: где в вашей системе якорь 35.472s

13 💡 Разбор: якорь — это то, что вы не трогаете 35.496s

14 Graph и Workflow: одинаковый скелет, разное содержимое 36.768s

15 Граф — это обобщение workflow, а не его замена 37.344s

16 🤔 Миф: нарисовать граф — инженерное достижение 35.376s

17 Шаг 1: что можно сделать общим, а что должно остаться приватным навсегда 36.672s

18 Шаг 2: почему verify обязан ничего не помнить о работе implement 48.408s

19 Шаг 3-4: после третьей неудачи откат идёт не туда, куда ожидаешь 46.128s

20 Шаг 5-6: чекпоинт, который даёт согласование человеком бесплатно 44.76s

21 Loop — решение потом, Graph — решение заранее 41.4s

22 Запустить агента дёшево, закрыть цикл — дорого 39.432s

23 Пять критериев: когда граф действительно нужен 42.264s

24 Граф — не апгрейд цикла, а другой уровень системы 25.776s

24 min

Abonnement S'abonner

Собираем харнес целиком: от пустого репозитория до автономного агента

Финал курса: берём всё, что мы шаг за шагом строили на сквозном проекте — платёжном FastAPI-бэкенде — и собираем в одну работающую систему. Проходим по всем артефактам харнеса от начала до конца: AGENTS.md-роутер с тематическими документами, feature_list.json с конечным автоматом состояний, PROGRESS.md и протокол передачи смены, scripts/verify.sh и scripts/arch-check.sh как гейты верификации, sprint contract и рубрика оценщика, чек-лист чистого выхода из сессии, program.md для автономного цикла и graph.md для многоролевого процесса. В конце — сравниваем метрики агента до харнеса и после.

сборка харнеса целиком сквозной проект метрики до/после capstone

2 Мы собирали харнес по кускам двенадцать лекций подряд. А вместе он вообще работает? 34.2s

3 Вот как выглядит репозиторий, когда харнес наконец закончен 35.688s

4 AGENTS.md — не файл с советами, а роутер на 80 строк 30.48s

5 «Готово» — это когда пройден список, а не когда стало похоже на готово 27.312s

6 feature_list.json: список задач, который умеет говорить «нет» 27.528s

7 Кто имеет право написать слово «passing»? Только этот скрипт 27.12s

8 Новая сессия не спрашивает «что мы вчера делали» — она читает 28.824s

9 Один скрипт отвечает на вопрос «а всё ли в порядке», прежде чем агент откроет рот 25.056s

10 Одна архитектурная граница, которую теперь нарушить физически нельзя 25.344s

11 Контракт на фичу пишется ДО кода — а не как объяснение после 27.936s

12 Оценка «выглядит нормально» здесь запрещена — есть рубрика с доказательствами 27.312s

13 Как агент прогоняет очередь фич всю ночь и сам решает, когда остановиться 34.752s

14 Один агент уже не справляется в одиночку — вот граф из четырёх ролей 28.872s

15 Граф умеет откатывать сам себя — вот куда идёт фича, если ревью против 31.344s

16 ❓ Стоп-проверка: в собранном харнесе есть один конфликт — найдите его 34.68s

17 💡 Разбор: passing от verify.sh не значит «прошёл весь Definition of Done» 38.112s

18 MTTR упал в семь раз, verification gap — с 38% до 4%: вот полный отчёт 41.832s

19 Харнес — это то, что вы продолжаете чинить и после выпуска курса 42.552s

20 min

Abonnement S'abonner