[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-95071":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":14,"subscribersCount":14,"size":14,"stars1d":14,"stars7d":15,"stars30d":15,"stars90d":14,"forks30d":14,"starsTrendScore":15,"compositeScore":16,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":17,"fork":17,"defaultBranch":18,"hasWiki":19,"hasPages":17,"topics":20,"createdAt":9,"pushedAt":9,"updatedAt":21,"readmeContent":22,"aiSummary":23,"trendingCount":14,"starSnapshotCount":14,"syncStatus":13,"lastSyncTime":24,"discoverSource":25},95071,"Harness_ru","justxor\u002FHarness_ru","justxor","Полный курс по Harness 2026 на русском языке. Все что нужно знать в одщном. метсе ",null,"Shell",122,30,2,0,18,52.27,false,"main",true,[],"2026-08-24 04:01:23","# Harness Engineering — полный курс на русском\n\n[![harness-tests](https:\u002F\u002Fgithub.com\u002Fjustxor\u002FHarness_ru\u002Factions\u002Fworkflows\u002Fharness-tests.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Fjustxor\u002FHarness_ru\u002Factions\u002Fworkflows\u002Fharness-tests.yml)\n\n**Как заставить AI-агента писать код надёжно.** Не «какую модель выбрать», а как спроектировать вокруг неё рабочую систему: инструкции, инструменты, среду, состояние и верификацию.\n\nКурс — от нуля до продвинутых тем: теоретическая база из 11 блоков, 14 модулей, 8 практических проектов, 14 лабораторных работ, задачник из 60 задач с разборами, 13 схем, исполняемый набор тестов для вашей обвязки, диагностический протокол «как починить агента», библиотека готовых шаблонов, карта инструментов, 40 приёмов и каталог антипаттернов.\n\n> **Главный тезис курса:** способность модели и надёжность исполнения — это две разные вещи. Одна и та же модель в «голой» среде и в среде с продуманным harness даёт качественно разные результаты. Апгрейд модели — самый дорогой и обычно не самый эффективный способ починить агента.\n\n---\n\n### Популярные ресурсы по Машинному Обучению, ИИ и анализу данных\n\n[🧠](https:\u002F\u002Ft.me\u002F+-DTW9e5kyZ5jNGFi) [**Machine Learning**](https:\u002F\u002Ft.me\u002F+VittCM--LUgwMjZi) — авторский Telegram-канал, который содержит всю базу для работы с ИИ-моделями. Дайджесты лучших проектов, разбор кода, инструкции по запуску LLM, подготовка к собесу и многое другое.\n\n[📚](https:\u002F\u002Ft.me\u002F+64ytM2_MgJozZTEy) [**Data Science**](https:\u002F\u002Ft.me\u002F+yLYl2dE5U8FjYzVi) — [редкая литература](https:\u002F\u002Ft.me\u002F+64ytM2_MgJozZTEy), статьи, курсы и уникальные гайды для мл-специалистов любого уровня. Читайте, развивайтесь, практикуйте.\n\n💼 [**Machine Interview**](https:\u002F\u002Ft.me\u002F+Gncl6NEJXOo4ODIy) — это база с [1900 вопросами с собеседований](https:\u002F\u002Ft.me\u002F+XKbJXlBwqBExOWEy) по машинному обучению. Вы легко получите оффер, изучив популярные вопросы.\n\n🔥 [**Целая папка супер полезных ресурсов по ИИ**](https:\u002F\u002Ft.me\u002Faddlist\u002F2Ls-snqEeytkMDgy)\n\n---\n\n## Оглавление\n\n**Введение**\n- [Что такое harness](#что-такое-harness)\n- [Это не Harness.io](#это-не-harnessio)\n- [Кому нужен курс и как его проходить](#кому-нужен-курс-и-как-его-проходить)\n- [Быстрый старт: минимальный harness за 30 минут](#быстрый-старт-минимальный-harness-за-30-минут)\n- [Как починить агента: диагностический протокол](#как-починить-агента-диагностический-протокол)\n\n**Часть 0. Теоретическая база**\n- [Т1. Агент как система с обратной связью](#т1-агент-как-система-с-обратной-связью)\n- [Т2. Математика накопления ошибок](#т2-математика-накопления-ошибок)\n- [Т3. Закон Эшби и закон Гудхарта](#т3-закон-эшби-и-закон-гудхарта)\n- [Т4. Контекст как канал с шумом](#т4-контекст-как-канал-с-шумом)\n- [Т5. Контракты, инварианты и постусловия](#т5-контракты-инварианты-и-постусловия)\n- [Т6. Теория надёжности: MTBF, MTTR и радиус поражения](#т6-теория-надёжности-mtbf-mttr-и-радиус-поражения)\n- [Т7. Очереди, WIP и закон Литтла](#т7-очереди-wip-и-закон-литтла)\n- [Т8. Марковское состояние сессии](#т8-марковское-состояние-сессии)\n- [Т9. Калибровка уверенности](#т9-калибровка-уверенности)\n- [Т10. Энтропия, законы Лемана и техдолг harness](#т10-энтропия-законы-лемана-и-техдолг-harness)\n- [Т11. Теория в одной таблице](#т11-теория-в-одной-таблице)\n\n**Часть I. Фундамент**\n- [Модуль 1. Почему сильные модели всё равно проваливаются](#модуль-1-почему-сильные-модели-всё-равно-проваливаются)\n- [Модуль 2. Пять подсистем harness](#модуль-2-пять-подсистем-harness)\n- [Модуль 3. Репозиторий как единственный источник истины](#модуль-3-репозиторий-как-единственный-источник-истины)\n- [Модуль 4. Архитектура инструкций: роутер, а не энциклопедия](#модуль-4-архитектура-инструкций-роутер-а-не-энциклопедия)\n\n**Часть II. Состояние и время**\n- [Модуль 5. Непрерывность между сессиями](#модуль-5-непрерывность-между-сессиями)\n- [Модуль 6. Инициализация как отдельная фаза](#модуль-6-инициализация-как-отдельная-фаза)\n\n**Часть III. Скоуп и дисциплина**\n- [Модуль 7. WIP=1: границы задачи](#модуль-7-wip1-границы-задачи)\n- [Модуль 8. Список фич как примитив harness](#модуль-8-список-фич-как-примитив-harness)\n\n**Часть IV. Верификация**\n- [Модуль 9. Как не дать агенту объявить победу раньше времени](#модуль-9-как-не-дать-агенту-объявить-победу-раньше-времени)\n- [Модуль 10. E2E и исполняемые архитектурные правила](#модуль-10-e2e-и-исполняемые-архитектурные-правила)\n\n**Часть V. Эксплуатация**\n- [Модуль 11. Наблюдаемость внутри harness](#модуль-11-наблюдаемость-внутри-harness)\n- [Модуль 12. Чистая передача и борьба с энтропией](#модуль-12-чистая-передача-и-борьба-с-энтропией)\n\n**Часть VI. Автономия**\n- [Модуль 13. Loop Engineering](#модуль-13-loop-engineering)\n- [Модуль 14. Graph Engineering](#модуль-14-graph-engineering)\n\n**Практика и справочники**\n- [8 практических проектов](#8-практических-проектов)\n- [Практикум: 14 лабораторных работ](#практикум-14-лабораторных-работ)\n- [Задачник: 60 задач с разборами](#задачник-60-задач-с-разборами)\n- [Тесты harness: исполняемый набор](#тесты-harness-исполняемый-набор)\n- [Все схемы одним списком](#все-схемы-одним-списком)\n- [Библиотека шаблонов](#библиотека-шаблонов-copy-paste)\n- [Карта инструментов 2026](#карта-инструментов-2026)\n- [40 приёмов](#40-приёмов-которые-реально-работают)\n- [Антипаттерны](#антипаттерны-harness)\n- [Метрики harness](#метрики-harness-и-как-их-считать)\n- [FAQ](#faq)\n- [Глоссарий](#глоссарий)\n- [Источники](#источники)\n- [Полезные ресурсы и что учить дальше](#полезные-ресурсы-и-что-учить-дальше)\n\n---\n\n## Что такое harness\n\nHarness (буквально «упряжь») — **всё, что находится за пределами весов модели** и определяет, какая часть её способностей реально проявится в вашем проекте.\n\nЕсли это не веса модели — это harness:\n\n- файлы инструкций (`AGENTS.md`, `CLAUDE.md`, `.cursorrules`, skills);\n- доступные инструменты (shell, тесты, линтер, браузер, MCP-коннекторы);\n- среда исполнения (версии рантайма, залоченные зависимости, контейнеры, worktree);\n- управление состоянием (файлы прогресса, логи решений, git-чекпоинты, handoff);\n- петли обратной связи (команды верификации, E2E-тесты, независимый оценщик, рубрики).\n\nМетафора, которая помогает: породистая лошадь без упряжи далеко не уедет. Модель — это лошадь. Harness — седло, узда, стремена и подковы. Апгрейд лошади не отменяет необходимости упряжи.\n\n**Диагностическое правило №1:** когда агент сломался — сначала проверяйте harness, потом модель. Если та же модель успешно решает похожие задачи в хорошо структурированных репозиториях, проблема почти наверняка в вашей среде, а не в её способностях.\n\n### Это не Harness.io\n\nВажное уточнение, потому что путаница возникает постоянно: **Harness.io** — это коммерческая CI\u002FCD-платформа. Этот курс — **не о ней**. Здесь речь о *harness engineering* — инженерной дисциплине проектирования окружения для AI-кодинг-агентов (Claude Code, OpenAI Codex, Cursor, Gemini CLI, Aider и т. п.).\n\n---\n\n## Кому нужен курс и как его проходить\n\n**Курс для вас, если вы:**\n\n- используете AI-агента для кодинга и получаете нестабильный результат;\n- хотите, чтобы агент работал часами и сессиями, а не 10 минут под присмотром;\n- строите внутренний инструмент\u002Fплатформу вокруг агентов;\n- отвечаете за то, чтобы код, написанный агентом, можно было мержить без страха;\n- хотите перейти от «пишу промпты» к «проектирую систему, которая пишет промпты».\n\n**Предварительные требования:** git, командная строка, любой опыт с одним из кодинг-агентов. Знание ML не нужно вообще.\n\n### Три трека прохождения\n\n| Трек | Время | Что делать |\n|---|---|---|\n| **Спринт (полдня)** | 3–4 ч | [Быстрый старт](#быстрый-старт-минимальный-harness-за-30-минут) → [диагностический протокол](#как-починить-агента-диагностический-протокол) → модули 1, 2, 4, 8, 9 → лабораторные Л3, Л8, Л7, Л11 |\n| **Основной (2 недели)** | ~20 ч | Часть 0 (блоки Т1–Т5, Т7, Т8) → модули 1–12 подряд → после каждого блока соответствующий проект и связанные лабораторные |\n| **Полный (6 недель)** | ~60 ч | Вся Часть 0 → все 14 модулей → все 8 проектов → все 14 лабораторных → собственный capstone на рабочем репозитории |\n| **Диагностика (30 минут)** | 0,5 ч | Только [протокол ремонта](#как-починить-агента-диагностический-протокол): подходит, если агент уже сломан и разбираться в теории некогда |\n\n### Схема 1. Карта маршрута обучения\n\n```mermaid\nflowchart TD\n    S([\"Агент работает нестабильно\"]) --> Q{\"Сломано прямо сейчас?\"}\n    Q -- \"да\" --> D[\"Диагностический протокол\u003Cbr\u002F>30 минут\"]\n    Q -- \"нет\" --> B[\"Быстрый старт\u003Cbr\u002F>4 файла, 30 минут\"]\n    D --> B\n    B --> T0[\"Часть 0\u003Cbr\u002F>теоретическая база\"]\n    T0 --> C1[\"Части I-III\u003Cbr\u002F>фундамент, состояние, скоуп\"]\n    C1 --> C2[\"Части IV-V\u003Cbr\u002F>верификация и эксплуатация\"]\n    C2 --> G{\"Метрики стабильно зелёные?\"}\n    G -- \"нет\" --> LAB[\"Лабораторные Л1-Л14\u003Cbr\u002F>замеры до и после\"]\n    LAB --> C2\n    G -- \"да\" --> C3[\"Часть VI\u003Cbr\u002F>автономия и графы\"]\n    C3 --> P[\"8 проектов + задачник\"]\n    P --> OWN([\"Свой capstone\u003Cbr\u002F>на рабочем репозитории\"])\n```\n\n**Как учиться правильно.** Каждый модуль устроен одинаково: *симптом → механика → понятия → что делать → замер*. Не переходите к следующему модулю, пока не сделали замер на своём проекте. Harness engineering — эмпирическая дисциплина: без цифр вы не отличите улучшение от самообмана.\n\n---\n\n## Быстрый старт: минимальный harness за 30 минут\n\nЧетыре файла дают львиную долю эффекта. Сделайте их прямо сейчас, до чтения теории.\n\n### Шаг 1. `AGENTS.md` в корне репозитория (10 минут)\n\n~~~markdown\n# AGENTS.md\n\n## Проект\nBackend платежей. Python 3.11, FastAPI, PostgreSQL 15, Redis 7.\n\n## Команды\n- Установка: `make setup`\n- Запуск: `make dev`\n- Тесты: `make test`\n- Полная верификация: `make check`   # tests + types + lint\n\n## Жёсткие ограничения (MUST)\n- Все эндпоинты — только через OAuth 2.0.\n- Только синтаксис SQLAlchemy 2.0 (`select()`, не `Query`).\n- Все SQL — параметризованные запросы. Никогда не склеивать строки.\n- Никогда не `eval()`, `exec()`, `pickle.loads()` на внешних данных.\n- Нельзя менять `migrations\u002F` без отдельного разрешения.\n\n## Definition of Done\nФича готова = `make check` зелёный + E2E-сценарий фичи проходит.\n«Код написан» — это не готово.\n\n## Правила работы\n- Одна фича за раз. Не начинать вторую, пока первая не прошла верификацию.\n- Никакого рефакторинга «заодно», пока основная фича не проверена.\n- Перед завершением сессии обновить `PROGRESS.md`.\n\n## Куда смотреть подробности\n- `docs\u002Fapi-patterns.md` — обязательно при добавлении эндпоинта\n- `docs\u002Fdb-rules.md` — обязательно при изменении моделей и миграций\n- `docs\u002Ftesting.md` — при написании тестов\n~~~\n\n**Правило: 50–150 строк, не больше.** Всё остальное — в `docs\u002F`.\n\n### Шаг 2. `feature_list.json` (7 минут)\n\n~~~json\n[\n  {\n    \"id\": \"F01\",\n    \"behavior\": \"POST \u002Fapi\u002Fcart\u002Fitems с {product_id, quantity} возвращает 201 и товар в корзине\",\n    \"verification\": \"pytest tests\u002Fe2e\u002Ftest_cart.py::test_add_item\",\n    \"state\": \"passing\",\n    \"evidence\": \"commit a1b2c3d, 4 passed\"\n  },\n  {\n    \"id\": \"F02\",\n    \"behavior\": \"GET \u002Fapi\u002Fcart возвращает корзину с итоговой суммой\",\n    \"verification\": \"pytest tests\u002Fe2e\u002Ftest_cart.py::test_get_cart\",\n    \"state\": \"active\",\n    \"evidence\": null\n  },\n  {\n    \"id\": \"F03\",\n    \"behavior\": \"POST \u002Fapi\u002Fcheckout создаёт заказ и очищает корзину\",\n    \"verification\": \"pytest tests\u002Fe2e\u002Ftest_checkout.py\",\n    \"state\": \"not_started\",\n    \"evidence\": null\n  }\n]\n~~~\n\nСостояний ровно четыре: `not_started`, `active`, `blocked`, `passing`. Агент **не имеет права** ставить `passing` сам — только скрипт верификации.\n\n### Шаг 3. `PROGRESS.md` (5 минут)\n\n~~~markdown\n# Прогресс\n\n## Состояние на сейчас\n- Коммит: a1b2c3d\n- Тесты: 42\u002F43 (падает test_pagination_empty)\n- Линт\u002Fтипы: чисто\n- Активная фича: F02\n\n## Сделано\n- [x] F01 — добавление товара в корзину (passing)\n\n## В работе\n- [ ] F02 — получение корзины (90%, не сходится расчёт скидки)\n\n## Заблокировано\n- F05 — ждём доступ к sandbox платёжного провайдера\n\n## Решения этой сессии\n- Итоговая сумма считается на сервере, не на клиенте — клиенту нельзя доверять цены.\n\n## Следующие шаги\n1. Починить расчёт скидки в `services\u002Fcart.py:total()`\n2. Прогнать `make check`\n3. Начать F03\n~~~\n\n### Шаг 4. `make check` (8 минут)\n\n~~~makefile\nsetup:\n\tuv sync\n\ndev:\n\tuv run uvicorn app.main:app --reload\n\ntest:\n\tuv run pytest -x -q\n\ntypes:\n\tuv run mypy src --strict\n\nlint:\n\tuv run ruff check src\n\ne2e:\n\tuv run pytest tests\u002Fe2e -q\n\ncheck: lint types test e2e\n\t@echo \"ALL CHECKS PASSED\"\n~~~\n\nОдна команда, один зелёный\u002Fкрасный ответ. Это самая высокорентабельная часть harness.\n\n### Проверка результата: тест холодного старта\n\nОткройте **новую** сессию агента, ничего не объясняйте голосом и задайте пять вопросов:\n\n1. Что это за система и зачем она?\n2. Как её запустить?\n3. Как её проверить (какие команды)?\n4. Какие правила нельзя нарушать?\n5. Где сейчас работа и что делать дальше?\n\nЕсли агент отвечает на все пять только по содержимому репозитория — минимальный harness готов. Каждый неотвеченный вопрос — белое пятно на карте, и агент будет его угадывать. Угадывание всегда дороже, чем один раз записать.\n\n---\n\n## Как починить агента: диагностический протокол\n\nЗамена модели — самый дорогой и самый непредсказуемый ремонт. Ниже — протокол, который стоит пройти до апгрейда: шесть шагов, около тридцати минут, и в большинстве случаев дефект находится в harness, а не в весах.\n\n**Правило нуля: воспроизведите отказ дважды.** Один провал — это шум выборки. Два одинаковых провала на одном и том же месте — это дефект вашей системы, у него есть адрес и его можно починить.\n\n### Шаг 1. Определите слой отказа (2 минуты)\n\n| Что вы наблюдаете | Слой отказа | Куда смотреть |\n|---|---|---|\n| Агент сделал не то, что просили | Формулировка задачи | Модуль 7, Т5 |\n| Агент не нашёл нужный файл, правило, команду | Инструкции и навигация | Модуль 4, Т4 |\n| Агент «забыл» решения прошлой сессии | Состояние и непрерывность | Модуль 5, Т8 |\n| Агент правит код, но не может его проверить | Инструменты и среда | Модуль 6, Т6 |\n| Агент отчитался «готово», а фича не работает | Верификация | Модули 9–10, Т5 |\n| Всё работает, но каждый прогон непредсказуем | Наблюдаемость и цикл | Модули 11, 13, Т1 |\n| Агент чинит метрику, а не проблему | Целевая функция | Т3 |\n| Каждая новая сессия дороже предыдущей | Энтропия и чистое состояние | Модуль 12, Т10 |\n\nОдин симптом — один слой. Если кажется, что «сломано всё», значит вы ещё не воспроизвели отказ на минимальном примере.\n\n### Шаг 2. Сожмите пример до минимума (5 минут)\n\nВозьмите последний провал и удалите из него всё лишнее: одну фичу, один файл, одну команду. Отказ, который воспроизводится на минимальном примере, почти всегда объясняется одной причиной. Отказ, который воспроизводится только на большой задаче, — это чаще всего проблема границ задачи (Модуль 7), а не проблема модели.\n\n### Шаг 3. Пройдите тест холодного старта (5 минут)\n\nОткройте новую сессию агента и задайте пять вопросов, не давая никаких подсказок:\n\n1. Что делает этот проект и кто его пользователь?\n2. Какой командой запустить тесты и линтер?\n3. Что сделано, что делается сейчас, что следующее?\n4. Какие три решения уже приняты и не подлежат пересмотру?\n5. Что считается признаком готовности фичи?\n\nКаждый ответ, который агент не может дать из репозитория, — это дырка в harness. Не в модели. Дырка закрывается файлом, а не апгрейдом.\n\n### Шаг 4. Проверьте, что верификация вообще существует (5 минут)\n\nЗадайте себе три вопроса и ответьте на них командой, а не мнением:\n\n- Есть ли одна команда, которая говорит «да» или «нет» по всей фиче целиком? Если проверка требует, чтобы человек посмотрел глазами, — верификации нет.\n- Может ли эта команда провалиться? Проверка, которая никогда не краснеет, ничего не проверяет. Сломайте код специально и убедитесь, что она падает.\n- Говорит ли сообщение об ошибке, что именно сломано, почему это плохо и что делать? Если нет — агент будет угадывать, а угадывание стоит итераций.\n\n### Шаг 5. Уберите одну вещь и измерьте (10 минут)\n\nМетод компонентного отключения: выключите ровно один элемент harness и повторите ту же задачу. Если результат не изменился — элемент не работает и его надо либо починить, либо удалить. Если результат просыпался — вы нашли несущую конструкцию, её надо документировать и защитить тестом.\n\nПорядок отключения от самого вероятного к самому редкому: файл инструкций, артефакт состояния, скрипт верификации, скрипт инициализации, наблюдаемость.\n\n### Шаг 6. Решите, что менять (3 минуты)\n\nПравило приоритета ремонта, от дешёвого к дорогому:\n\n1. **Сузить задачу.** Одна фича вместо трёх. Бесплатно, эффект самый быстрый.\n2. **Добавить постусловие.** Одна команда проверки. Стоит полчаса, снимает целый класс ложных «готово».\n3. **Починить состояние.** Файл прогресса и файл решений. Стоит час, снимает повторную работу.\n4. **Переписать инструкции как роутер.** Стоит день, поднимает попадание в правила.\n5. **Автоматизировать цикл.** Стоит неделю, окупается только если пункты 1–4 уже сделаны.\n6. **Менять модель.** Делайте это последним и с зафиксированным замером до и после — иначе вы не узнаете, помогло ли.\n\n### Дерево решений\n\n~~~text\nфича не работает, хотя агент сказал «готово»\n├─ проверка была? ── нет ──> Модуль 8: passing только по команде\n│                   да\n├─ проверка красная? ─ да ──> агент игнорирует сигнал: Модуль 9, жёсткое правило\n│                      нет\n├─ проверка зелёная, но фича мертва\n│   ├─ нет сквозного прогона ──> Модуль 10: E2E как единственный источник «готово»\n│   └─ E2E есть, но обходит слой ──> Модуль 10: карта слепых зон\n└─ проверка нестабильна (то красная, то зелёная)\n    └─> Модуль 11: сначала наблюдаемость, потом любые выводы\n~~~\n\n### Схема 5. Дерево атрибуции слоя отказа\n\n```mermaid\nflowchart TD\n    F([\"Агент не справился\"]) --> A{\"Понял, что именно нужно сделать?\"}\n    A -- \"нет\" --> L1[\"Слой: постановка задачи\u003Cbr\u002F>Модуль 7, Т5\"]\n    A -- \"да\" --> B{\"Нашёл правила и нужный контекст?\"}\n    B -- \"нет\" --> L2[\"Слой: инструкции\u003Cbr\u002F>Модуль 4, Т4\"]\n    B -- \"да\" --> C{\"Знал, что было в прошлых сессиях?\"}\n    C -- \"нет\" --> L3[\"Слой: состояние\u003Cbr\u002F>Модуль 5, Т8\"]\n    C -- \"да\" --> D{\"Смог запустить проверку?\"}\n    D -- \"нет\" --> L4[\"Слой: среда и инструменты\u003Cbr\u002F>Модуль 6, Т6\"]\n    D -- \"да\" --> E{\"Проверка отличает готово от неготово?\"}\n    E -- \"нет\" --> L5[\"Слой: верификация\u003Cbr\u002F>Модули 8-10, Т5\"]\n    E -- \"да\" --> L6[\"Слой: цикл и наблюдаемость\u003Cbr\u002F>Модули 11 и 13, Т1\"]\n```\n\nДерево проходится сверху вниз и останавливается на первом «нет». Останавливаться надо именно там: нижние слои чинить бесполезно, пока сломан верхний, — агент с непонятой задачей будет безупречно верифицировать не ту работу.\n\n### Что почти никогда не является причиной\n\n- «Модель слабая» — при том же промпте и той же среде две модели различаются меньше, чем один и тот же агент с harness и без него.\n- «Нужен более умный промпт» — если состояние теряется между сессиями, промпт не поможет ни в одной из них.\n- «Надо больше контекста» — чаще помогает не добавить, а убрать: см. Т4.\n\n---\n\n# Часть 0. Теоретическая база\n\nHarness-инженерия выглядит как набор эмпирических советов, но почти каждый её приём выводится из теории, которой десятки лет: теории управления, теории надёжности, теории информации, контрактного программирования, теории очередей. Эта часть даёт понятийный аппарат: почему приёмы работают, когда они перестают работать и как придумывать новые вместо копирования чужих чек-листов.\n\nЧитать эту часть можно двумя способами. Быстрый: только блоки «Следствие» и итоговая таблица Т11. Полный: целиком, с выполнением проверок «на своём проекте» — тогда теория сразу превращается в изменения в репозитории.\n\n---\n\n## Т1. Агент как система с обратной связью\n\n**Суть.** Агент — это не функция «промпт → код», а замкнутый контур управления. У контура есть уставка (чего мы хотим), исполнительное устройство (модель, пишущая изменения), датчик (то, чем мы измеряем результат) и правило коррекции (что делать при расхождении). Если убрать любой из четырёх элементов, останется не контур, а разомкнутая система: она действует, но не знает результата своего действия.\n\n**Модель.** На каждом шаге контур вычисляет ошибку e = цель − наблюдаемое состояние и делает коррекцию, пропорциональную ошибке. Устойчивость такого контура зависит от трёх вещей: точности датчика, задержки между действием и измерением, и силы коррекции.\n\n### Схема 3. Контур управления агентом\n\n```mermaid\nflowchart LR\n    G[\"Уставка\u003Cbr\u002F>задача + критерий готовности\"] --> A[\"Исполнитель\u003Cbr\u002F>агент вносит изменения\"]\n    A --> W[\"Объект\u003Cbr\u002F>репозиторий\"]\n    W --> D[\"Датчик\u003Cbr\u002F>make verify\"]\n    D -- \"e больше 0\" --> C[\"Коррекция\u003Cbr\u002F>минимальная правка причины\"]\n    C --> A\n    D -- \"e равно 0\" --> OK([\"Коммит\u003Cbr\u002F>точка восстановления\"])\n```\n\nЧто ломается при отсутствии каждого элемента: без уставки агент делает похожее, но не то; без датчика контур разомкнут и сходится к уверенности вместо корректности; без правила коррекции каждый провал повторяется; без точки восстановления цепочка шагов не обнуляется и работает формула из Т2.\n\n**Что это объясняет.**\n\n- *Плохой датчик — плохое управление.* Агент, у которого нет команды проверки, измеряет ошибку своим суждением. Суждение смещено в сторону «всё хорошо», поэтому контур сходится не к работающему коду, а к убеждённости в том, что код работает.\n- *Задержка вызывает перерегулирование.* Если проверка запускается раз в час, агент успевает построить десять слоёв на неверной основе. Чем длиннее задержка, тем больше амплитуда отката.\n- *Слишком сильная коррекция вызывает колебания.* Правило «переписывай модуль целиком, если тест красный» превращает контур в генератор колебаний: агент бесконечно ходит между двумя вариантами реализации. Правило «исправь минимальную причину падения» демпфирует контур.\n- *Нет правила коррекции — нет обучения.* Если провал не приводит к изменению правил, следующий прогон повторит его.\n\n**Следствие для harness.** Проектируйте не промпт, а контур: сначала датчик (verify), потом задержка (как часто), потом сила коррекции (насколько крупные правки разрешены), и только потом текст инструкций. Промпт — это уставка, а уставка без датчика не управляет ничем.\n\n**Проверка на своём проекте.** Назовите вслух все четыре элемента контура для вашего последнего прогона агента. Если для «датчика» вы называете себя — контура нет, есть человек в роли датчика, и стоимость каждого шага равна вашему вниманию.\n\n---\n\n## Т2. Математика накопления ошибок\n\n**Суть.** Автономный прогон — это последовательность шагов, каждый из которых может не сработать. Если шаги независимы и каждый успешен с вероятностью p, то весь прогон успешен с вероятностью p в степени n. Это единственная формула, которую надо помнить, приступая к автономии.\n\n| Надёжность шага | 5 шагов | 20 шагов | 50 шагов | 200 шагов |\n|---|---|---|---|---|\n| 0,90 | 59% | 12% | 0,5% | ~0% |\n| 0,95 | 77% | 36% | 8% | ~0% |\n| 0,99 | 95% | 82% | 61% | 13% |\n| 0,999 | 99,5% | 98% | 95% | 82% |\n\n### Схема 4. Как падает надёжность прогона\n\n```text\nВероятность успеха всего прогона\n\np = 0,999  n=5   ████████████████████████████████████████  99,5%\n           n=20  ███████████████████████████████████████░  98%\n           n=50  ██████████████████████████████████████░░  95%\n           n=200 █████████████████████████████████░░░░░░░  82%\n\np = 0,99   n=5   ██████████████████████████████████████░░  95%\n           n=20  █████████████████████████████████░░░░░░░  82%\n           n=50  ████████████████████████░░░░░░░░░░░░░░░░  61%\n           n=200 █████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  13%\n\np = 0,95   n=5   ███████████████████████████████░░░░░░░░░  77%\n           n=20  ██████████████░░░░░░░░░░░░░░░░░░░░░░░░░░  36%\n           n=50  ███░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   8%\n           n=200 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  ~0%\n\np = 0,90   n=5   ███████████████████████░░░░░░░░░░░░░░░░░  59%\n           n=20  █████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  12%\n           n=50  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   0,5%\n           n=200 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  ~0%\n```\n\nИз таблицы видно неприятное: «агент на 95% надёжен» — это отличный агент для пяти шагов и бесполезный для пятидесяти. Именно поэтому демо на короткой задаче ничего не говорит о ночном прогоне.\n\n**Три рычага, и только три.**\n\n1. **Уменьшить n.** Не «сделай фичу», а «сделай слой фичи». WIP=1 — это не про аккуратность, это про показатель степени.\n2. **Увеличить p.** Каждое исполняемое правило, каждая понятная ошибка, каждый шаблон повышают p на конкретном классе шагов.\n3. **Разорвать зависимость шагов.** Точка восстановления обнуляет накопление: после успешно закрытой фичи прогон начинается заново с p в степени n на следующем участке, а не продолжает старую цепочку. Отсюда — коммит и зелёная проверка как обязательная граница шага.\n\n**Важная поправка.** Шаги на практике зависимы, и зависимость обычно вредна: ошибка в понимании требований портит все последующие шаги сразу. Поэтому дорогие проверки размещают в начале цепочки (правильно ли понята задача), а дешёвые — по всей длине.\n\n**Следствие для harness.** Любое обсуждение «сможет ли агент сделать это автономно» надо переводить в два числа: сколько шагов и какова надёжность шага. Если n больше пятидесяти, а p не измерено — ответ известен заранее.\n\n**Проверка на своём проекте.** Возьмите последнюю задачу, которую агент делал сам, и посчитайте, сколько раз он вызывал инструменты. Это ваш n. Затем посчитайте, сколько из этих вызовов пришлось переделывать. Это ваша оценка 1 − p.\n\n---\n\n## Т3. Закон Эшби и закон Гудхарта\n\n**Закон необходимого разнообразия (Эшби).** Управляющая система должна обладать разнообразием не меньшим, чем разнообразие возмущений, которые она должна компенсировать. Проще: чтобы harness справлялся с N классами отказов, в нём должно быть не меньше N различимых реакций.\n\nПрактический смысл: один общий совет «пиши качественный код» не может компенсировать десять разных способов сломать проект. Каждому воспроизводимому классу отказа нужен свой различимый механизм: правило, тест, скрипт, шаблон. Отсюда следует и обратное, экономное правило — если класс отказа ни разу не наблюдался, механизм для него добавлять не нужно: разнообразие harness должно соответствовать реальному разнообразию отказов, а не воображаемому.\n\n**Закон Гудхарта.** Когда метрика становится целью, она перестаёт быть метрикой. Агент — идеальный оптимизатор в буквальном смысле: он оптимизирует то, что вы измеряете, включая случаи, когда измеряемое расходится с желаемым.\n\nТипичные проявления в harness:\n\n| Метрика как цель | Что оптимизирует агент | Противоядие |\n|---|---|---|\n| Зелёные тесты | Ослабление ассертов, пропуски, моки поверх моков | Тест на тесты: сломай код, проверка обязана покраснеть |\n| Покрытие в процентах | Тесты, вызывающие код без проверки результата | Мутационное тестирование, ревью новых тестов |\n| Количество закрытых фич | Мелкая нарезка и формальные закрытия | Сквозной прогон как единственный признак готовности |\n| Отсутствие предупреждений линтера | Массовые подавления и исключения | Запрет на подавления без комментария с причиной |\n| Скорость прогона | Отключение медленных, но важных проверок | Отдельный обязательный набор, не подлежащий отключению |\n\n**Следствие для harness.** Метрика годится как цель только вместе с антиметрикой, которая ломается при её накрутке. Держите пары: скорость и доля откатов, покрытие и мутационная выживаемость, число фич и число регрессий.\n\n**Проверка на своём проекте.** Придумайте самый дешёвый способ накрутить вашу главную метрику, ничего не сделав полезного. Если способ есть и он не обнаруживается — метрика ещё не готова быть целью.\n\n---\n\n## Т4. Контекст как канал с шумом\n\n**Суть.** Контекстное окно — это канал с ограниченной пропускной способностью. Полезность канала описывается не объёмом, а отношением сигнала к шуму: доля токенов, релевантных текущей задаче, к общему числу переданных токенов.\n\nИз этого следуют три вещи, которые противоречат интуиции «дам побольше контекста».\n\n1. **Добавление нерелевантного текста ухудшает результат, а не оставляет его прежним.** Каждый лишний абзац конкурирует за внимание с нужным правилом.\n2. **Позиция важнее объёма.** Модели устойчиво хуже используют информацию из середины длинного входа, чем из начала и конца, — эффект, описанный в работе Liu et al. (2023) о «потере середины». Инструкция, спрятанная в середине файла на тысячу строк, статистически ближе к отсутствующей.\n3. **Правило без адресации не срабатывает.** Правило нужно не просто написать, а связать с триггером: «когда меняешь схему БД — сделай X». Без триггера правило требует, чтобы модель сама вспомнила о его существовании в нужный момент.\n\n**Бюджет внимания.** Полезно считать инструкции не в килобайтах, а в бюджете: сколько правил модель гарантированно удержит одновременно. Практический ориентир — десятки, не сотни. Всё, что не влезло в бюджет, должно быть перенесено из текста в механику: в линтер, в тест, в скрипт, в шаблон. Правило, вынесенное в исполняемую проверку, освобождает бюджет внимания и перестаёт зависеть от того, прочитал ли его агент.\n\n**Иерархия вытеснения (от лучшего к худшему).**\n\n~~~text\n1. Механика   — правило проверяется скриптом, читать не нужно\n2. Шаблон     — правило встроено в заготовку, нарушить дороже, чем соблюсти\n3. Роутер     — короткая ссылка «делаешь X → читай docs\u002Fx.md»\n4. Правило    — короткий императив с триггером\n5. Пояснение  — длинный текст «почему так»: полезен человеку, дорог агенту\n~~~\n\n**Следствие для harness.** Каждый раз, когда хочется дописать абзац в файл инструкций, сначала спросите: можно ли это же правило превратить в проверку или в шаблон. Файл инструкций — самый дорогой способ хранить правило.\n\n**Проверка на своём проекте.** Посчитайте, сколько императивов в вашем файле инструкций. Затем спросите агента, какие правила проекта он знает, не давая подсказок. Разница между этими числами — ваш реальный убыток на шуме.\n\n---\n\n## Т5. Контракты, инварианты и постусловия\n\n**Суть.** Контрактное программирование описывает любой шаг тройкой: предусловие (что должно быть верно до), сам шаг, постусловие (что обязано стать верным после). Классическая запись Хоара: если предусловие выполнено и шаг завершился, постусловие выполнено. Harness — это в точности механизация этой тройки для шага «агент делает фичу».\n\n| Элемент контракта | Что это в harness | Файл или команда |\n|---|---|---|\n| Предусловие | Проект собирается, состояние чистое, задача одна | `make preflight` |\n| Инвариант | Архитектурные правила, которые не должны нарушаться никогда | `scripts\u002Farch-check.sh` |\n| Постусловие | Признак готовности фичи, проверяемый машиной | `make verify F=F03` |\n| Вариант (для циклов) | Мера, которая обязана убывать: осталось фич, красных тестов | `feature_list.json` |\n\n**Почему это важнее, чем кажется.** Пока постусловие не выражено командой, «готово» — это оценочное суждение. Суждение агента о своей работе систематически смещено: он видел, как писал код, и это создаёт ощущение проверенности. Постусловие переносит право выносить вердикт из суждения в исполняемый артефакт. Это одно изменение убирает самый частый класс отказов во всём курсе.\n\n**Вариант цикла — забытая половина.** У автономного прогона должна быть убывающая мера, иначе цикл не завершается, а просто останавливается по таймеру. Хорошие меры: число фич в статусе не-passing, число красных проверок, число нарушений инвариантов. Плохие меры: число сделанных шагов, количество токенов, «ощущение прогресса».\n\n**Правило слабейшего звена.** Сила контракта равна силе самой слабой из трёх частей. Идеальные постусловия при отсутствующем предусловии дают агента, который героически чинит следствия грязного состояния. Поэтому `preflight` так же обязателен, как `verify`.\n\n**Проверка на своём проекте.** Выпишите для одной фичи её постусловие одной строкой команды. Если строка не получается — фича сформулирована не как фича, а как направление работы.\n\n---\n\n## Т6. Теория надёжности: MTBF, MTTR и радиус поражения\n\n**Суть.** Надёжность системы описывается не одним числом, а парой: как редко она ломается (среднее время между отказами) и как быстро восстанавливается (среднее время восстановления). Доступность растёт и от увеличения первого, и от уменьшения второго — но второе почти всегда дешевле.\n\nДля harness это переводится буквально:\n\n| Понятие из теории надёжности | Аналог в harness | Как улучшать |\n|---|---|---|\n| MTBF | Сколько шагов агент проходит до застревания | Исполняемые правила, шаблоны, узкий скоуп |\n| MTTR | Сколько времени уходит на возврат к рабочему состоянию | Коммит на каждой зелёной проверке, `git worktree`, откат одной командой |\n| Радиус поражения | Сколько кода портит один неудачный шаг | Запрет на массовые правки, лимит на diff, изоляция воркспейса |\n| Fail-fast | Проверка падает на первой ошибке с понятным сообщением | Ранние ассерты, валидация входа |\n| Избыточность | Вторая независимая проверка того же свойства | E2E поверх юнит-тестов, ревьюер поверх генератора |\n| N-версионность | Два независимых решения и сравнение | Генератор и оценщик — разные роли, разный контекст |\n\n**Главный практический вывод.** Гонка за MTBF («сделать агента, который не ошибается») бесконечна. Снижение MTTR («сделать так, чтобы любая ошибка откатывалась за минуту») достигается за один день работы: чистые коммиты, отдельная рабочая копия, скрипт сброса состояния. Автономность становится приемлемой не тогда, когда агент перестал ошибаться, а тогда, когда цена его ошибки упала до нуля.\n\n**Радиус поражения — недооценённый параметр.** Один и тот же агент с одной и той же надёжностью безопасен, если правит один модуль, и опасен, если ему разрешён рефакторинг всего репозитория. Ограничение радиуса — самый дешёвый способ сделать автономию безопасной без всякого улучшения модели.\n\n**Ошибка выжившего.** Не оценивайте надёжность по успешным прогонам. Ведите журнал застреваний с классификацией по слоям из диагностического протокола: только эта статистика показывает, где MTBF реально низкий.\n\n**Проверка на своём проекте.** Замерьте секундомером, сколько времени занимает полный возврат к последнему рабочему состоянию после неудачного прогона агента. Если больше пяти минут — у вас проблема с MTTR, и она важнее любой проблемы с моделью.\n\n---\n\n## Т7. Очереди, WIP и закон Литтла\n\n**Суть.** Закон Литтла связывает три величины в любой стабильной системе с очередью: среднее число задач в работе равно интенсивности поступления, умноженной на среднее время пребывания задачи в системе. Отсюда: при фиксированной пропускной способности рост числа одновременно открытых задач не увеличивает выработку — он увеличивает время выполнения каждой.\n\nДля агента это усиливается двумя дополнительными эффектами:\n\n1. **Стоимость переключения не нулевая, а квадратичная по контексту.** Три одновременно открытые фичи требуют держать в контексте три модели предметной области; конфликты между ними приходится разрешать заново на каждом шаге.\n2. **Незавершённая работа — это невидимый долг.** Три фичи в состоянии «почти готово» дают ноль проверенной ценности, но занимают весь контекст и все точки риска сразу.\n\n**Почему WIP=1 — не аскеза, а арифметика.** При WIP=1 время до первой проверенной фичи минимально, значит минимальна и длина цепочки шагов между двумя точками восстановления (см. Т2). При WIP=3 длина цепочки утраивается, а вероятность успеха падает как куб.\n\n**Клапан для импульса «заодно».** Запрет на параллельную работу создаёт давление: агент видит соседний недостаток и хочет исправить его сразу. Давление нужно не подавлять, а отводить в `BACKLOG.md` — одна строка, тридцать секунд, ноль расхода контекста. Отсутствие клапана превращает дисциплину скоупа в источник потерь.\n\n**Гранулярность задачи.**\n\n| Размер шага | Признак | Риск |\n|---|---|---|\n| Слишком мелкий | Постусловие невозможно выразить пользовательски значимо | Накладные расходы на цикл больше пользы |\n| Правильный | Одна проверяемая пользовательская способность, 1–3 файла, проверка меньше минуты | — |\n| Слишком крупный | Постусловие требует нескольких независимых проверок | Накопление ошибок, откат дорогой |\n\n**Проверка на своём проекте.** Посчитайте, сколько фич у вас сейчас в состоянии «начато, но не проверено». Всё, что больше единицы, — это очередь, и по закону Литтла она уже увеличила ваше время выполнения.\n\n---\n\n## Т8. Марковское состояние сессии\n\n**Суть.** Процесс называют марковским, если для предсказания следующего шага достаточно текущего состояния, а вся предыстория не нужна. Хороший harness делает работу над проектом марковской: новая сессия агента, прочитав состояние из репозитория, действует так же хорошо, как сессия, которая вела проект с самого начала.\n\nЭто даёт точный критерий достаточности состояния: **если для продолжения работы нужна информация, которой нет в репозитории, состояние неполно**. Не «неудобно», а формально неполно, и величина потери равна стоимости повторного вывода этой информации.\n\n**Что обязано быть в состоянии.** Не история диалога, а её результат:\n\n| Категория | Что записывать | Почему без этого нельзя продолжить |\n|---|---|---|\n| Цель | Что именно делаем сейчас и зачем | Иначе следующая сессия выберет другой приоритет |\n| Сделано | Проверенные фичи и как они проверены | Иначе работа делается повторно |\n| Решения | Выбор и отвергнутые альтернативы с причиной | Иначе решения пересматриваются по кругу |\n| Тупики | Что уже пробовали и почему не сработало | Иначе тупик исследуется заново |\n| Следующий шаг | Одна формулировка с постусловием | Иначе сессия начинается с обсуждения, а не с работы |\n\n**Компактизация против сброса.** Сжатие истории диалога сохраняет ощущение непрерывности, но теряет именно то, что дороже всего восстановить: причины отвергнутых решений. Осознанный сброс с полным письменным состоянием почти всегда дешевле длинной сжатой истории. Правило простое: важное должно жить в файлах, а не в окне.\n\n**Стоимость восстановления как метрика.** Замеряйте, сколько шагов проходит от старта новой сессии до первого полезного изменения кода. Это единственная честная метрика качества вашего состояния. Хорошее значение — один-два шага. Десять шагов означают, что каждая сессия начинается с археологии.\n\n**Границы марковости.** Не всё стоит делать марковским: детальная история рассуждений полезна редко и стоит дорого. Правильная граница — марковость по решениям и по прогрессу, беспамятство по формулировкам.\n\n**Проверка на своём проекте.** Закройте сессию, откройте новую и дайте агенту только репозиторий и одну фразу: «продолжай». Если он начинает делать правильную работу — состояние марковское. Если он спрашивает, что делать, — нет.\n\n---\n\n## Т9. Калибровка уверенности\n\n**Суть.** Модель калибрована, если её субъективная уверенность совпадает с частотой правоты: из утверждений, названных «уверен на 90%», верны примерно девять из десяти. Хорошо известно, что современные нейросети склонны к переуверенности — этот эффект для глубоких сетей систематически описан ещё в работе Guo et al. (ICML 2017) о калибровке. Дообучение на обратной связи людей смещает картину ещё сильнее в сторону приятных, уверенно звучащих ответов.\n\n**Почему это ломает автономию.** Автономный цикл принимает решения на основе собственной оценки: продолжать или остановиться, готово или нет, безопасно или рискованно. Если оценка смещена в сторону «готово», цикл систематически завершается раньше времени. Никакое количество инструкций «будь внимательнее» не исправляет смещение, потому что инструкция обращается к той же смещённой оценке.\n\n**Что работает вместо призывов к аккуратности.**\n\n- **Разделение ролей.** Тот, кто писал код, не выносит вердикт. Оценщик получает только результат и критерии, но не рассуждения автора — иначе он наследует его уверенность.\n- **Внешний вердикт.** Право ставить статус `passing` принадлежит команде, а не тексту ответа.\n- **Формулировка через отрицание.** Вопрос «что могло сломаться» даёт заметно более полезные ответы, чем вопрос «всё ли хорошо»: второй запускает подтверждающий поиск.\n- **Требование доказательства.** Не «тесты проходят», а вывод команды в отчёте. Пересказ результата и результат — разные вещи.\n- **Явный список того, что не проверялось.** Раздел «не проверено» в отчёте о работе стоит дороже раздела «сделано».\n\n**Полезная асимметрия.** Ложное «не готово» стоит одну лишнюю итерацию. Ложное «готово» стоит поиск дефекта в проде. Поэтому пороги надо смещать в сторону строгости осознанно: система, которая иногда перепроверяет лишнее, дешевле системы, которая иногда пропускает.\n\n**Проверка на своём проекте.** Возьмите десять последних утверждений агента вида «готово» и проверьте их независимо. Доля подтверждённых — ваша реальная калибровка. Если она ниже восьмидесяти процентов, любые планы автономии преждевременны.\n\n---\n\n## Т10. Энтропия, законы Лемана и техдолг harness\n\n**Суть.** Лемановские законы эволюции программ говорят о двух вещах, которые полностью применимы к harness: система, которая используется, обязана меняться, и при этом её сложность растёт, пока не будет специально снижена. Harness — тоже программное обеспечение, и он деградирует по тем же законам, только быстрее: добавить правило дешевле, чем удалить, поэтому файлы инструкций растут монотонно.\n\n**Три вида энтропии в harness.**\n\n| Вид | Как выглядит | Чем измерять | Как снижать |\n|---|---|---|---|\n| Энтропия инструкций | Правила, противоречащие друг другу или коду | Доля правил, для которых нет ни одного нарушения за месяц | Удаление правил, ставших механикой |\n| Энтропия состояния | Файл прогресса, которому нельзя доверять | Расхождение между записанным и фактическим | Обновление состояния как часть Definition of Done |\n| Энтропия среды | Локальные хаки, недокументированные шаги запуска | Успех холодного старта на чистой машине | Всё в `init.sh`, проверка на CI |\n\n**Механизм деградации.** Каждый инцидент добавляет правило. Через полгода файл инструкций содержит сто правил, из которых сорок относятся к коду, которого больше нет. Агент читает все сто, тратит бюджет внимания (Т4) на мёртвые сорок и хуже соблюдает живые шестьдесят. Формально harness растёт — фактически он слабеет.\n\n**Обязательный ритуал: упрощение.** Раз в месяц (или после каждых десяти фич) harness надо не расширять, а сокращать:\n\n1. Для каждого правила найти проверку, которая его механизирует. Нашли — правило удалить, оставив ссылку на проверку.\n2. Правила без единого нарушения за период — удалить, они не оплачивают своё место.\n3. Правила, нарушенные больше трёх раз, — не усиливать текстом, а переносить в механику.\n4. Артефакты состояния, которые никто не читал, — удалить: недостоверное состояние хуже отсутствующего.\n5. Зафиксировать в `DECISIONS.md`, что удалено и почему, чтобы удалённое не вернулось через месяц.\n\n**Правило постоянного размера.** Полезная дисциплина: держать файл инструкций в фиксированном бюджете строк. Хотите добавить правило — найдите, что удалить. Это единственный известный способ не дать документу вырасти до нечитаемого состояния.\n\n**Проверка на своём проекте.** Откройте файл инструкций и отметьте каждое правило одним из трёх: «механизировано», «нарушалось за месяц», «мёртвое». Третья группа — ваш техдолг harness, её объём обычно удивляет.\n\n---\n\n## Т11. Теория в одной таблице\n\nСводка: что из какой теории следует и в каком модуле это реализуется практически.\n\n| Теория | Ключевая идея | Практика в harness | Модули |\n|---|---|---|---|\n| Теория управления | Без датчика нет управления | Одна команда проверки как источник вердикта | 8, 9, 11 |\n| Вероятность отказов | Надёжность как p в степени n | WIP=1, точки восстановления, коммит на каждой зелёной проверке | 7, 12 |\n| Закон Эшби | Разнообразие реакций не меньше разнообразия отказов | Отдельный механизм на каждый воспроизводимый класс отказа | 2, 10 |\n| Закон Гудхарта | Метрика-цель перестаёт быть метрикой | Пары «метрика + антиметрика», тест на тесты | 9, 10 |\n| Теория информации | Полезен не объём, а отношение сигнала к шуму | Инструкции как роутер, вынос правил в механику | 4 |\n| Контракты Хоара | Предусловие, инвариант, постусловие, вариант цикла | `preflight`, `arch-check`, `verify`, убывающая мера | 6, 8, 10, 13 |\n| Теория надёжности | MTTR дешевле MTBF | Откат одной командой, изоляция воркспейса, лимит радиуса | 6, 12 |\n| Закон Литтла | Рост WIP не увеличивает выработку | Одна фича в работе, `BACKLOG.md` как клапан | 7 |\n| Марковские процессы | Достаточное состояние делает историю ненужной | `PROGRESS.md`, `DECISIONS.md`, передача смены | 5, 12 |\n| Калибровка | Уверенность смещена в сторону «готово» | Разделение генератора и оценщика, доказательство вместо пересказа | 9, 13 |\n| Законы Лемана | Сложность растёт, пока её не снижают специально | Ежемесячное упрощение harness, фиксированный бюджет правил | 12 |\n| Теория графов | Структура важнее отдельного узла | Явный граф процесса, анкеры, критерии необходимости графа | 14 |\n\n**Как этим пользоваться.** Столкнувшись с новой проблемой, не ищите готовый приём — определите, какая из двенадцати строк её описывает. Приём выводится из строки за пять минут и оказывается точнее скопированного чужого чек-листа.\n\n---\n\n# Часть I. Фундамент\n\n## Модуль 1. Почему сильные модели всё равно проваливаются\n\n### Симптом\n\nВы даёте агенту реальную задачу в реальном репозитории. Он добавляет фичу и ломает три теста. Чинит баг и создаёт два новых. Работает двадцать минут и уверенно говорит «готово», а вы открываете диф и видите не то, что просили. Первая мысль — «нужна модель посильнее». Почти всегда это неверная мысль.\n\n### Механика\n\nК концу 2025 года лучшие кодинг-агенты на SWE-bench Verified держались в районе 50–60%. И это на отобранных задачах с внятным описанием и уже существующими тестами. В вашем репозитории требования размыты, тестов нет, бизнес-правила живут в головах — и цифра падает дальше.\n\nРазрыв между бенчмарком и вашей реальностью называется **capability gap**, и закрывается он не моделью, а средой. Anthropic показывали это контролируемым экспериментом: один и тот же промпт, одна и та же модель. Прогон в «голой» среде — быстро, дёшево, результат нерабочий. Прогон с полноценным harness (планировщик + генератор + независимый оценщик) — дольше, дороже, результат работает. Модель не менялась. Менялась упряжь.\n\nOpenAI в 2025 году описали ещё более радикальный эксперимент: продукт примерно на миллион строк кода, выращенный агентом из пустого репозитория, при жёстком ограничении — люди не пишут код руками. Ключевой вывод оттуда: в начале скорость была ниже ожидаемой, но не из-за слабости модели, а потому что среда была неполной. Работа инженера превратилась в «какой способности агенту не хватает и как сделать её и понятной, и исполняемой».\n\n### Пять слоёв, где на самом деле ломается агент\n\nКогда что-то пошло не так, не пишите в лог «модель тупит». Отнесите провал к одному из пяти слоёв:\n\n| Слой | Вопрос | Типичный симптом | Чем лечится |\n|---|---|---|---|\n| **1. Спецификация задачи** | Задача сформулирована однозначно? | Сделал не то, что просили | Definition of Done, критерии приёмки |\n| **2. Предоставление контекста** | Агент знает конвенции проекта? | Старый синтаксис ORM, чужой стиль ошибок | `AGENTS.md`, доки рядом с кодом, ADR |\n| **3. Среда исполнения** | Среда воспроизводима? | Полсессии борется с `pip install` | Локи зависимостей, `.python-version`, devcontainer |\n| **4. Верификационная обратная связь** | Есть способ узнать правду? | «Готово» при красных тестах | `make check`, E2E, независимый оценщик |\n| **5. Управление состоянием** | Знание переживает сессию? | Каждая сессия исследует репо заново | `PROGRESS.md`, `DECISIONS.md`, handoff |\n\n### Диагностическая петля\n\nЭто ядро всей методологии, запомните её как рабочий цикл:\n\n~~~\nзапустить → зафиксировать провал → отнести провал к слою →\nпочинить именно этот слой → запустить снова → записать результат\n~~~\n\nКаждый провал — не «модель плохая», а сигнал о структурном дефекте в вашей среде. Через несколько итераций harness крепнет, и записи «модель не справилась» в вашем журнале становится всё меньше.\n\n### Что делать сегодня\n\n1. **Пишите Definition of Done явно.** Не «добавь поиск», а: эндпоинт `GET \u002Fapi\u002Fsearch?q=`, пагинация по 20, подсветка сниппетов, `pytest tests\u002Fsearch` зелёный, `mypy --strict` проходит.\n2. **Завейдите `AGENTS.md`.** Самый высокий ROI из всех действий в этом курсе. Один файл на 100 строк часто даёт больше, чем переход на более дорогую модель.\n3. **Заведите журнал провалов.** Таблица из трёх колонок: задача, результат, виновный слой. Через 20 записей вы увидите своё настоящее бутылочное горлышко — и оно почти никогда не там, где вы думали.\n\n### Упражнение M1\n\nВозьмите знакомый репозиторий и нетривиальную задачу. Прогон А: без harness-поддержки. Прогон Б: добавьте `AGENTS.md` с командами верификации, прогоните ту же задачу. Каждый провал отнесите к одному из пяти слоёв. Ожидаемый результат — почти все провалы прогона А окажутся в слоях 2 и 4.\n\n---\n\n## Модуль 2. Пять подсистем harness\n\n### Симптом\n\n«У меня есть harness» обычно означает «у меня есть файл с промптом». Это не harness. Это как назвать холодильник рестораном: продукты есть, а плиты, ножей, рецептов и контроля качества — нет.\n\n### Модель пяти подсистем\n\nПолноценный harness состоит из пяти частей. Пропущенная часть — это не «немного хуже», а систематический класс провалов.\n\n| № | Подсистема | Метафора кухни | Что в неё входит | Как понять, что она сломана |\n|---|---|---|---|---|\n| 1 | **Инструкции** | Полка с рецептами | `AGENTS.md`\u002F`CLAUDE.md`, skills, тематические доки, ADR | Агент нарушает конвенции, о которых «все знают» |\n| 2 | **Инструменты** | Стойка с ножами | shell, тесты, линтер, отладчик, браузер, MCP | Агент «хочет, но не может» — нет доступа к нужному действию |\n| 3 | **Среда** | Плита | локи зависимостей, версии рантайма, Docker\u002Fdevcontainer, worktree | Сессия начинается с починки окружения |\n| 4 | **Состояние** | Заготовочный стол | `PROGRESS.md`, `feature_list.json`, `DECISIONS.md`, git-чекпоинты | Новая сессия не знает, где остановились |\n| 5 | **Обратная связь** | Окно ОТК | `make check`, E2E, рубрики, независимый оценщик | «Готово» не совпадает с реальностью |\n\n**Порядок внедрения, если начинаете с нуля:** 5 → 1 → 4 → 3 → 2. Обратная связь первой: самый низкий порог входа и самая высокая отдача. Без неё все остальные улучшения нельзя измерить.\n\n### Типичная кривая внедрения\n\nРеальный паттерн, который повторяется у команд почти дословно:\n\n| Стадия | Что добавили | Что происходит |\n|---|---|---|\n| Пустая кухня | только README | Не тот пакетный менеджер, не те конвенции, тесты не запускаются |\n| + рецепты | `AGENTS.md` со стеком и конвенциями | Конвенции соблюдаются, остаются проблемы среды и верификации |\n| + окно ОТК | явные команды верификации | Агент сам находит и чинит свои ошибки до сдачи |\n| + заготовочный стол | файлы прогресса и состояния | Результат стабилизируется между сессиями |\n\n### Как измерять ценность компонента: абляция при фиксированной модели\n\nЗафиксируйте модель и набор задач. Удаляйте по одной подсистеме и смотрите просадку.\n\n**Важная тонкость, которую почти все понимают неправильно.** Самая большая просадка показывает **предельный вклад** компонента на этом наборе задач — но это ещё не доказательство, что здесь ваше бутылочное горлышко. И нулевая просадка не означает «компонент бесполезен»: он может быть избыточным, плохо спроектированным или просто не задействованным этими задачами.\n\nПравильный порядок: сначала **журнал провалов и атрибуция по слоям** (модуль 1) — они указывают на горлышко. Абляция — вспомогательное доказательство, которое подтверждает или опровергает гипотезу.\n\n### Ключевые идеи\n\n- **Ограничивать, а не микроменеджить.** Хороший harness задаёт инварианты («данные валидируются на границе», «все запросы параметризованы»), а не диктует пошагово реализацию и не перечисляет библиотеки.\n- **Карта, а не учебник.** Входной файл инструкций — оглавление. Детали — по требованию.\n- **Harness гниёт, как код.** Harness-долг ведёт себя как техдолг: копится незаметно, платится болезненно. Ревизуйте регулярно.\n\n### Схема 2. Пять подсистем harness и что между ними течёт\n\n```mermaid\nflowchart LR\n    M([\"Модель\"]) --> I[\"Инструкции\u003Cbr\u002F>AGENTS.md как роутер\"]\n    I --> T[\"Инструменты\u003Cbr\u002F>shell, тесты, линтер, MCP\"]\n    T --> E[\"Среда\u003Cbr\u002F>версии, зависимости, worktree\"]\n    E --> R[\"Изменения в репозитории\"]\n    R --> V[\"Верификация\u003Cbr\u002F>make check, E2E, оценщик\"]\n    V -- \"красный: что, почему, как чинить\" --> M\n    V -- \"зелёный: коммит\" --> S[\"Состояние\u003Cbr\u002F>PROGRESS, DECISIONS, feature_list\"]\n    S --> I\n```\n\nСхема читается как контур, а не как список. Модель входит в него один раз, дальше всё определяется тем, что течёт по стрелкам: качество инструкций задаёт, найдёт ли агент правило; качество верификации задаёт, узнает ли он о своей ошибке; качество состояния задаёт, начнётся ли следующая сессия с работы или с археологии. Уберите любую стрелку — и контур станет разомкнутым в этом месте.\n\n### Упражнение M2\n\nПроведите аудит своего проекта по пяти подсистемам, поставив каждой оценку 1–5. Возьмите самую слабую, потратьте на неё 30 минут и повторите один и тот же набор из 5 задач. Зафиксируйте разницу.\n\n---\n\n## Модуль 3. Репозиторий как единственный источник истины\n\n### Симптом\n\nАрхитектурные решения команды живут в Confluence (частично устаревшем), в Slack (плохо ищется), в Jira и в головах двух сеньоров. Для людей это как-то работает — можно спросить. Агент спросить не может.\n\n### Механика\n\nВход агента — это ровно три вещи: системный промпт и описание задачи, содержимое файлов репозитория, вывод инструментов. Всё. **Знания, которых нет в репозитории, для агента не существуют.** Это не преувеличение, это буквальное описание его сенсорного аппарата.\n\nOpenAI формулируют это принципом «репозиторий и есть спецификация»: репозиторий — авторитетный источник по решениям, ограничениям, состоянию и стандартам верификации. Ни Slack, ни Confluence не имеют голоса.\n\n### Что мерить\n\n**Knowledge visibility gap** — доля важных для разработки решений и ограничений, которых нет в репозитории. Считается вручную и честно: выпишите все правила, которые вы знаете о проекте, отметьте каждое как «в репо» \u002F «не в репо», поделите. Цель — ниже 10%.\n\n**Discovery cost** — сколько контекстного бюджета агент сжигает на поиск нужного. Критичное правило, спрятанное в `docs\u002Flegacy\u002Fnotes\u002Fold\u002FREADME.md`, формально есть, но фактически недоступно. Это как огнетушитель в запертом подвале.\n\n**Knowledge decay rate** — доля записей, разошедшихся с кодом. Документация, которая врёт, опаснее отсутствующей: она уверенно ведёт агента не туда.\n\n### Четыре принципа хорошей карты\n\n1. **Знания живут рядом с кодом.** Правило аутентификации — в `src\u002Fapi\u002FARCHITECTURE.md`, а не в глобальном документе на 500 страниц. 50 строк рядом с модулем полезнее 500 страниц в вики.\n2. **Один стандартный вход.** `AGENTS.md` отвечает на три вопроса: что это, как запустить, как проверить.\n3. **Минимально, но полно.** Если удаление правила не меняет качество решений агента — правила быть не должно. Но на каждый вопрос холодного старта должен быть ответ.\n4. **Обновляется вместе с кодом.** Документ в каталоге модуля вы увидите, когда меняете модуль. Документ в вики — нет.\n\n### Рабочая структура репозитория\n\n~~~\nproject\u002F\n├── AGENTS.md                  # вход: что, как запустить, как проверить, жёсткие правила\n├── CLAUDE.md -> AGENTS.md     # симлинк, если работаете и с Claude Code, и с Codex\n├── PROGRESS.md                # где сейчас работа\n├── DECISIONS.md               # почему приняты решения (краткие ADR)\n├── Makefile                   # setup \u002F dev \u002F test \u002F lint \u002F types \u002F e2e \u002F check\n├── docs\u002F\n│   ├── api-patterns.md\n│   ├── db-rules.md\n│   └── testing.md\n├── .agent\u002F\n│   ├── feature_list.json      # машиночитаемое состояние фич\n│   ├── session-handoff.md     # передача смены\n│   └── quality.md             # оценки качества модулей\n├── scripts\u002F\n│   ├── init.sh                # bootstrap новой сессии\n│   └── verify.sh              # единая точка верификации\n└── src\u002F\n    ├── api\u002FARCHITECTURE.md\n    └── db\u002FCONSTRAINTS.md\n~~~\n\n### ACID для состояния агента\n\nАналогия с транзакциями БД оказывается неожиданно практичной:\n\n- **Atomicity.** Одна логическая единица работы = один коммит. Пошло не так — `git stash` \u002F `git reset --hard` откатывает целиком. Никаких «наполовину».\n- **Consistency.** Определите предикат согласованного состояния (`make check` зелёный) и запускайте его после каждой единицы работы. Несогласованные промежуточные состояния не коммитятся.\n- **Isolation.** Параллельные агенты — в отдельных `git worktree` и\u002Fили с отдельными файлами состояния. Два повара не солят одну кастрюлю.\n- **Durability.** Межсессионное знание обязано быть в файлах под git. То, что «в контексте» — не считается.\n\n### Упражнение M3\n\nПроведите тест холодного старта на рабочем репозитории (пять вопросов из быстрого старта). Зафиксируйте, на что агент не ответил. Устраните пробелы. Повторите, пока не будет пять из пяти. Затем посчитайте свой knowledge visibility gap.\n\n---\n\n## Модуль 4. Архитектура инструкций: роутер, а не энциклопедия\n\n### Симптом\n\nВы поверили в harness и завели `AGENTS.md`. Каждый раз, когда агент ошибался, вы добавляли правило. Через три месяца файл на 600 строк, и качество работы агента **упало**: на простом багфиксе агент читает инструкции по деплою, критичное правило безопасности со строки 300 игнорируется, а три противоречащих правила стиля дают случайное поведение.\n\n### Механика: четыре независимые причины деградации\n\n**1. Instruction bloat.** Файл на 600 строк — это примерно 10–20K токенов. При окне 200K кажется мелочью, но в реальной задаче нужно ещё прочитать десятки файлов, получить вывод инструментов и удержать историю диалога. Ориентир: **если файл инструкций занимает больше 10% окна — он уже вредит.**\n\n**2. Lost in the middle.** Работа Liu et al. (2023) показала: языковые модели существенно хуже используют информацию из середины длинного текста, чем с его начала и конца. Критичное требование на строке 300 из 600 — фактически невидимо.\n\n**3. Конфликт приоритетов.** В одном файле визуально одинаково выглядят: необсуждаемое правило безопасности, стилистическое предпочтение и разовая историческая заметка. Агент не может их различить — вы не дали ему сигнала.\n\n**4. Гниение.** Большие файлы не поддерживаются: удалять страшно («а вдруг что-то зависит»), добавлять бесплатно. Файл монотонно растёт, отношение сигнал\u002Fшум монотонно падает.\n\n### Метрика: SNR инструкций\n\n**Instruction SNR** — доля строк файла, релевантных текущей задаче. Возьмите пять типичных типов задач, для каждой строки отметьте релевантность, посчитайте среднее. Всё, что шум для большинства задач, переезжает в тематические документы.\n\n### Трёхуровневая архитектура\n\n~~~\nУровень 1: AGENTS.md — роутер (50–150 строк)\n  ├── что за проект (1–2 предложения)\n  ├── команды (setup \u002F test \u002F check)\n  ├── жёсткие ограничения (не больше 15 штук, MUST \u002F MUST NOT)\n  ├── definition of done\n  └── ссылки на уровень 2 с условием применимости\n\nУровень 2: docs\u002F*.md — тематические документы (50–150 строк каждый)\n  api-patterns.md · db-rules.md · testing.md · security.md · release.md\n  читаются агентом только когда нужны\n\nУровень 3: код — типы, докстринги, комментарии в конфигах\n  агент видит их естественно при чтении кода, дублировать не надо\n~~~\n\nПравильная ссылка на уровень 2 всегда содержит **условие применимости**, а не просто путь:\n\n~~~markdown\n## Подробности\n- `docs\u002Fapi-patterns.md` — читать обязательно перед добавлением любого эндпоинта\n- `docs\u002Fdb-rules.md` — читать обязательно перед изменением моделей или миграций\n- `docs\u002Ftesting.md` — читать при написании новых тестов\n- `docs\u002Frelease.md` — читать только при подготовке релиза\n~~~\n\n### Паспорт правила\n\nКаждое правило в инструкциях обязано иметь три атрибута, иначе оно бессмертно:\n\n| Атрибут | Зачем | Пример |\n|---|---|---|\n| Источник | понять, почему правило появилось | «инцидент 2025-11-04, SQL-инъекция в поиске» |\n| Условие применимости | не читать зря | «при любой работе с БД» |\n| Условие истечения | можно ли удалить | «удалить, когда весь доступ к БД пойдёт через репозиторный слой» |\n\n### Практические правила\n\n- **Приоритет — позицией.** Если правило обязано быть во входном файле — только начало или конец, никогда середина.\n- **Историю — в тесты.** Заметка «на прошлой неделе починили утечку в WebSocket» должна стать тестом, а не абзацем в инструкции. Тест не забывается и не теряется в середине.\n- **Ревизия по расписанию.** Раз в месяц: удалить устаревшее, слить дублирующее, развести противоречия. Управляйте инструкциями как зависимостями.\n- **Прежде чем добавить правило, спросите:** это правило или это тест? Это инвариант или это разовый случай? Это уровень 1 или уровень 2?\n\n### Упражнение M4\n\nЕсли у вас есть файл инструкций больше 300 строк: разбейте на роутер (\u003C100 строк) и 3–5 тематических документов. Прогоните один и тот же набор из 5 задач до и после. Отдельно замерьте соблюдение одного критичного правила безопасности — обычно именно здесь виден самый большой прирост.\n\n---\n\n# Часть II. Состояние и время\n\n## Модуль 5. Непрерывность между сессиями\n\n### Симптом\n\nАгент работал 30 минут, сделал большую часть фичи, контекст закончился. Новая сессия не помнит: какие решения приняты, почему выбран вариант Б, какие файлы уже изменены, в каком состоянии тесты. Она тратит 15 минут на повторную разведку и с высокой вероятностью действует вразрез с предыдущим подходом.\n\nПравильная модель агента: **гениальный инженер с полной амнезией каждое утро**. Лечится не увеличением памяти, а введением бортового журнала.\n\n### Механика\n\n**Окно контекста конечно, и это не решается ростом окна.** Даже при миллионе токенов сложные задачи его исчерпают: агент читает кодовую базу, накапливает историю решений, получает вывод инструментов и держит диалог. Всё это растёт быстрее, чем растут окна.\n\n**Информация неравноценна.** Промежуточные рассуждения содержат «почему»: почему вариант Б, почему не эта библиотека, почему оптимизацию сознательно пропустили. Финальный вывод содержит только «что» — код. Компакция обычно сохраняет второе и теряет первое. Следующая сессия видит код, не знает замысла и «оптимизирует» осознанное проектное решение.\n\n**Контекстная тревожность.** Наблюдение Anthropic: приближаясь к границе окна, агент демонстрирует преждевременное схождение — торопится закончить, пропускает верификацию, выбирает простое решение вместо правильного. Это ровно то, что делает студент, увидев, что до конца экзамена пять минут. Важно: степень этого эффекта **зависит от модели**, поэтому дизайн harness нужно калибровать под конкретную модель, а не копировать универсальный шаблон.\n\n### Компакция против сброса\n\n| | Компакция | Сброс контекста |\n|---|---|---|\n| Что делает | суммирует раннюю часть диалога внутри той же сессии | закрывает сессию, новая читает файлы состояния |\n| Сохраняет | «что» | всё, что вы записали в файлы |\n| Теряет | «почему» | всё, что вы не записали |\n| Тревожность | остаётся: агент помнит, что контекст был большим | обнуляется: чистое состояние |\n| Когда | короткие и средние задачи | всё, что дольше одной сессии |\n\nПрактический критерий: **как только задача съела ~60% окна, переставайте кодить и начинайте готовить handoff.**\n\n### Четыре артефакта непрерывности\n\n**1. `PROGRESS.md`** — где мы сейчас. Шаблон в [библиотеке](#библиотека-шаблонов-copy-paste).\n\n**2. `DECISIONS.md`** — почему так. Формат «решение \u002F причина \u002F что отвергли и почему \u002F ограничение»:\n\n~~~markdown\n## 2026-03-14 — Кэш пользовательских настроек в Redis\n- Решение: Redis, TTL 5 минут, активная инвалидация при записи.\n- Причина: читается на каждом запросе, объём данных крошечный.\n- Отвергли: materialized view в PostgreSQL — слишком высокая частота изменений,\n  стоимость поддержки не оправдана.\n- Ограничение: при недоступности Redis читаем из БД, не падаем.\n~~~\n\nСтрока «отвергли и почему» — самая ценная в файле. Именно она не даёт следующей сессии «улучшить» ваше решение обратно в то, что вы уже отвергли.\n\n**3. Git-коммиты как чекпоинты.** Бесплатные версионированные снимки состояния. Сообщение коммита объясняет *что* и *почему*, а не пересказывает диф.\n\n**4. Протокол смены** в `AGENTS.md` — приход и уход:\n\n~~~markdown\n## Приход на смену\n1. Прочитать `PROGRESS.md` и `DECISIONS.md`.\n2. Прочитать `.agent\u002Ffeature_list.json`, найти активную фичу.\n3. Прогнать `make check` — убедиться, что репозиторий в согласованном состоянии.\n4. Продолжить с раздела «Следующие шаги», ничего не переоткрывая заново.\n\n## Уход со смены\n1. Обновить `PROGRESS.md` (состояние, сделано, блокеры, следующие шаги).\n2. Дописать в `DECISIONS.md` решения этой сессии.\n3. Прогнать `make check`, добиться зелёного.\n4. Закоммитить всё завершённое, ничего недоделанного в рабочем дереве не оставлять.\n~~~\n\n### Метрика: стоимость восстановления\n\nВремя от старта новой сессии до первого осмысленного изменения кода. Без артефактов — 15–20 минут. С хорошим handoff — 2–3 минуты. Это самая честная метрика качества вашего управления состоянием: замерьте её один раз, и вы сразу поймёте, работают артефакты или нет.\n\n### Упражнение M5\n\nСпроектируйте минимальный handoff из четырёх полей: хеш коммита, доля проходящих тестов, блокеры, следующие действия. Дайте абсолютно свежей сессии восстановиться **только** по нему. Записывайте каждую возникшую неоднозначность — каждая из них является отсутствующим полем в вашем шаблоне. Итерируйте, пока восстановление не станет однозначным.\n\n---\n\n## Модуль 6. Инициализация как отдельная фаза\n\n### Симптом\n\nНовая сессия, вы говорите «добавь поиск», агент сразу бросается писать код. Через 20 минут выясняется, что тестовый фреймворк настроен неверно. Ещё через 10 — что формат миграций не тот. Поиск в итоге появился, но сессия ушла на выяснение устройства проекта, а не на фичу.\n\n### Механика\n\nУ инициализации и реализации **разные цели оптимизации**:\n\n- реализация оптимизирует количество","这是一个面向俄语用户的 Harness 工程实践课程，聚焦于构建可靠 AI 代理系统的工程化方法论，而非单纯模型选型。核心内容涵盖 harness 设计原理、反馈系统建模、错误累积分析、上下文噪声控制、契约与不变式约束、可靠性指标（MTBF\u002FMTTR）、会话状态管理、诊断协议与修复流程，并提供 8 个可运行项目、60 道带解析的练习题及 40 种实用模式与反模式。适用于 LLM 应用开发者、AI 工程师和需要将大模型集成到生产级系统的工程师，尤其适合在高可靠性要求场景（如自动化决策、智能运维、代码生成流水线）中构建鲁棒代理系统。","2026-08-21 02:30:03","CREATED_QUERY"]