OODA-петля

Observe → Orient → Decide → Act: цикл быстрее среды — ты задаёшь условия.

Происхождение: Джон Бойд и воздушный бой

┌──────────────────────────────────────┐
│  Observe → Orient → Decide → Act    │
│      ↑                       │       │
│      └───────────────────────┘       │
│          (результат Act =             │
│           новое наблюдение)          │
└──────────────────────────────────────┘

Четыре фазы

ReAct-петля агента = OODA

Паттерн ReAct (Reason + Act), используемый в LLM-агентах, изоморфен OODA:

OODA фаза    │  ReAct шаг           │  Конкретика у агента
─────────────┼──────────────────────┼──────────────────────────────────────
Observe      │  Observe (perception)│  Читает tool-result, ошибки, env-state
Orient       │  Think / Reason      │  Системный промпт + контекст + память
Decide       │  Plan next action    │  Выбирает инструмент и аргументы
Act          │  Act (tool call)     │  Вызывает инструмент → результат идёт
             │                      │  обратно в Observe следующей итерации

Контекст-инжиниринг (что попадает в системный промпт, что в рабочий контекст, что в retrieval) — это прямая настройка фазы Orient. Именно поэтому он является главным рычагом качества агента.

Темп (Tempo): кто быстрее и точнее

Скорость петли — не единственная метрика. Бойд подчёркивал два условия одновременно:

• Быстрее — цикл завершается быстрее, чем меняется среда (advantage ≥ 1).
• Точнее — Orient адекватен реальности (контекст актуален, память не засорена).

🎛 Интерактив: темп петли против среды

Среда меняется с характерным временем T_env = 10 сек. Двигайте слайдер — увидите, как меняется «преимущество петли».

Формула: advantage = T_env / T_loop = 10 / T_loop

Антипаттерны OODA у агентов

Практика: OODA в проектировании агента

Implicit vs explicit Orient: где живёт «модель мира»

У агента фаза Orient реализуется двумя способами — это ключевой архитектурный выбор:

Критерий остановки: когда петля должна закончиться

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

• Критерий успеха достигнут — результат прошёл проверку (мост к Check/eval из M4 и Measurable из M7).
• Бюджет исчерпан — лимит шагов / токенов / времени.
• Нет прогресса — N итераций подряд без улучшения наблюдений → выйти и эскалировать.

Граница OODA: хаотический домен

OODA предполагает, что наблюдение информативно. Но если данных ещё нет — среда новая и непредсказуемая — «наблюдать» нечего. В хаотическом домене порядок переворачивается: сначала действуй, чтобы создать информацию (act → sense → respond), а не застревай в Observe. Это часть более общей рамки Cynefin — «какой режим решения для какой ситуации»; полную карту доменов разберём в M8.

Проверь себя

Модуль 3: GTD — Getting Things Done

Дэвид Аллен · «Ум как вода» · Пять шагов от хаоса к действию · Перенос на AI-агентов

Почему мозг плохо хранит задачи

Пять шагов GTD

Перенос GTD на AI-агентов

Антипаттерны

Интерактив: GTD-воронка обработки инбокса

Пройдите по шагам — так работает Clarify в GTD и так должен рассуждать агент при обработке входящего элемента.

Контексты GTD для агента: машинные триггеры

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

• @has_tool — нужный инструмент доступен в текущем состоянии (иначе это не next-action, а «waiting-for»).
• @context_fits — нужные данные влезают в окно (иначе сначала retrieval/суммаризация).
• @needs_verify — результат требует проверки перед фиксацией (мост к Check из M4).
• @budget_left — остался лимит токенов/времени на это действие.

Engage by context у агента = выбрать из очереди действие, у которого все триггеры зелёные.

WIP-лимит: capture без потолка = бесконечный инбокс

GTD говорит «собери всё», но без ограничения на число одновременно активных задач (work-in-progress) агент перегружает контекст и распыляет внимание — это та же болезнь overreach. Приём из Kanban: жёсткий потолок на параллельные задачи (часто WIP = 1 для агента — одна активная задача за раз), остальное ждёт в очереди.

Проверьте себя

Модуль 4: PDCA — Спираль улучшения

Plan → Do → Check → Act: как агент учится на ошибках между прогонами

Происхождение и суть

Цикл PDCA придумал Уолтер Шухарт (Walter Shewhart) в 1930-х, а Уильям Эдвардс Деминг (W. Edwards Deming) популяризировал его в послевоенной Японии как инструмент кайдзен — непрерывного улучшения. Это не разовый проект, а спираль: каждый завершённый цикл начинает следующий с более высокой базы.

PDCA против OODA: две разные петли

Оба цикла — механизмы обратной связи, но работают на разных временны́х горизонтах и решают разные задачи.

Перенос на AI-агентов

Каждый шаг PDCA читается напрямую в терминах агентной разработки:

«Уверенно неправый» агент = PDCA без Check

Агент может стабильно выдавать уверенные ответы, которые фактически неверны. Если после каждого прогона нет честной проверки результата — нет сигнала для Act, нет коррекции для следующего Plan. Цикл разомкнут.

Verification gap — разрыв между тем, что агент утверждает о своём выводе, и тем, что реально верифицировано через eval. Закрывается только через Check.

Спираль улучшения — интерактивная модель

Модель: error_n = error_0 · (1 − r)^n, где error_0 — начальная частота ошибок (%), r — доля ошибок, устраняемых за один цикл PDCA (эффективность Check+Act), n — номер цикла.

Поставьте r = 0 — увидите горизонтальную линию: без Check улучшений нет.

Практическое применение: чеклист цикла

1. Plan. Сформулируй конкретную гипотезу: «Если я изменю [X] в промпте, то частота ошибок на задаче [Y] снизится с [A%] до [B%]».
2. Do. Запусти агента на фиксированном тестовом наборе с изменённым промптом. Не меняй несколько переменных сразу.
3. Check. Прогони eval. Сравни цифры с гипотезой. Не интерпретируй субъективно — смотри на метрику.
4. Act. Если гипотеза подтвердилась — зафиксируй изменение (обнови system-промпт, добавь few-shot пример, обнови CLAUDE.md / AGENTS.md). Если нет — откати и сформулируй новую гипотезу.

Single-loop vs double-loop: улучшать способ ИЛИ менять цель

Крис Аргирис различил два уровня обучения, и PDCA по умолчанию работает только на первом:

Для агента это критично: single-loop честно оптимизирует прокси-метрику — и упирается прямо в закон Гудхарта (M7). Если eval измеряет не то, single-loop будет старательно улучшать «не то». Double-loop — периодический шаг назад: «правильную ли цель проверяет наш Check?»

Квиз

Модуль 5: Первые принципы

First Principles Thinking — разобрать до фундамента, собрать заново

Что такое рассуждение от первых принципов

Аристотель определял первопринцип как «первую основу, из которой вещь познаётся». Декарт возвёл методическое сомнение в метод: отбрось всё, в чём можно усомниться, — и строй знание заново на том, что устоит. Современный популяризатор — Илон Маск: «думать физикой», а не аналогией.

Кейс: батареи (иллюстративный аргумент)

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

Калькулятор первопринципной стоимости

Введи стоимости компонентов и рыночную цену готового пакета. Калькулятор покажет «первопринципный пол» (сумма материалов) и зазор между ним и рынком.

Числа иллюстративные (в духе аргумента Маска про батареи), не точная историческая бухгалтерия. Смысл — показать зазор между «рыночной аналогией» и «первопринципным полом».

Перенос на AI-агентов

1. Анти-cargo-cult промптинг

Cargo-cult — копировать «магические» формулировки, не понимая механизма. Первопринципный вопрос: какой фундаментальный механизм заставляет это работать?

«Ты гениальный эксперт мирового уровня.
У других работает → копируем.»

1. Что реально влияет на качество?
   → контекст, инструкции, примеры, eval.
2. Проверь A/B: с фразой и без.
3. Оставь только то, что подтверждено.

2. Декомпозиция до атомарных проверяемых утверждений

Сложная задача агента → разложи до atomic verifiable claims: утверждений, каждое из которых можно проверить независимо. Это прямой мост к eval из Модуля 4: каждый claim становится тест-кейсом.

Задача: «Суммируй новости корректно»
↓ декомпозиция
├── Claim 1: факты из источника сохранены
├── Claim 2: нет добавленных утверждений
├── Claim 3: тон нейтральный
└── Claim 4: длина в заданных пределах

Каждый claim = отдельный eval-тест.

3. Оценка снизу вверх: «слишком дорого / слишком много токенов»

Прежде чем принять «невозможно» — посчитай из фундаментальных составляющих.

«Это слишком дорого по токенам» — аналогия.

Первые принципы:
1. Сколько токенов занимает каждая часть промпта?
2. Что из этого несёт информацию? Что балласт?
3. Где реальный bottleneck: контекст, стоимость, latency?
→ Считаем, а не предполагаем.

4. Связь с SMART / OKR (Модуль 7)

Практика: применение метода

Задача: [описание]

1. РАЗЛОЖЕНИЕ
   Из каких фундаментальных элементов состоит задача?
   → [элемент 1], [элемент 2], ...

2. ДОПУЩЕНИЯ ПОД ВОПРОСОМ
   Что «принято» считать ограничением?
   → Допущение X: можно ли его проверить?

3. ПРОВЕРЯЕМЫЕ ИСТИНЫ
   Что можно измерить / вывести напрямую?
   → Факт 1: [число / результат эксперимента]

4. СБОРКА СНИЗУ ВВЕРХ
   Исходя из п.3, какое решение следует?
   → [вывод]

Агент-нативный пример: бюджет на модели снизу-вверх

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

Числа иллюстративные. Смысл: «дорого и иначе никак» — это аналогия; первопринципный расчёт почти всегда вскрывает зазор (здесь — роутинг дешёвой модели на простые задачи).

Проверь себя

Теория ограничений (TOC)

Элияху Голдратт, «The Goal» (1984) — любая система ограничена одним узким местом, которое определяет пропускную способность всей цепи.

1. Ключевая идея: цепь не прочнее слабейшего звена

Элияху Голдратт сформулировал принцип, который изменил производственный менеджмент: в любой системе есть хотя бы одно ограничение (constraint, bottleneck) — самое медленное звено, через которое проходит весь поток работы. Это ограничение и определяет throughput — пропускную способность всей системы.

Классическая ловушка: команда тратит месяц на оптимизацию самой быстрой стадии, гордится ускорением в 2×, но итоговый throughput не меняется вообще. Это называют «локальная оптимизация не на узком месте».

2. Пять фокусирующих шагов

3. TOC в агентских пайплайнах

Агентский пайплайн — это тот же конвейер стадий, каждая со своей производительностью:

4. Интерактив: Throughput конвейера = min(стадий)

Настрой скорости четырёх стадий (запросов/мин). Система покажет узкое место и итоговый throughput. Попробуй: подними Retrieval со 100 до 200 — throughput не сдвинется (останется 20). Потом подними Reasoning с 20 до 40 — throughput вырастет до 40, и узкое место переедет на Verify.

🎮 Мини-игра: расшей конвейер за бюджет

У тебя 14 очков апгрейда. Одно очко поднимает выбранную стадию на +5 req/мин. Цель — выжать максимальный throughput (= минимум по стадиям). Подсказка: лить очки в стадию быстрее текущего узкого места бесполезно. Оптимум достижим — найди его.

5. Связь с другими инструментами курса

6. RICE / WSJF: какую из многих задач делать первой

TOC отвечает «где узкое место в одном конвейере». Но часто перед агентом — бэклог из десятков независимых улучшений, и единого узкого места нет: задачи надо ранжировать. Здесь работает скоринг ценности.

Для агента: Reach = сколько запросов/задач затронет улучшение; Impact = насколько помогает каждому; Confidence = насколько уверены (бери из данных eval, а не из ощущений); Effort = стоимость в агенто-/человеко-времени. Считаешь RICE для каждого кандидата → делаешь сначала тот, у кого выше.

Связь линз: RICE/WSJF дополняют TOC. TOC — приоритет внутри потока (расшей ограничение); RICE — приоритет между независимыми задачами бэклога.

7. Проверь себя

Модуль 7: SMART и OKR

От расплывчатых намерений к измеримым целям — и как это работает для AI-агентов

SMART: анатомия проверяемой цели

Аббревиатуру SMART предложил Джордж Доран в 1981 году как инструмент превращения туманных намерений в конкретные, проверяемые цели. Пять критериев образуют контрольный список:

Пример: расплывчатая цель → SMART

OKR: цели и ключевые результаты

OKR (Objectives and Key Results) — система постановки целей, разработанная Энди Гроувом в Intel в 1970-х на основе MBO Питера Друкера. Джон Дорр принёс её в Google в 1999 году; с тех пор OKR используют тысячи компаний.

История и грейдинг 0..1

В Google каждый Key Result оценивается по шкале 0.0 — 1.0 в конце периода. Норма Google: ~0.7 = «хорошо». Это не случайно:

• Стабильные 1.0 означают, что цели слишком лёгкие — система не растягивает команду.
• Результаты близко к 0 сигнализируют: цель была недостижима или непонята.
• Зона 0.6–0.8 — «амбициозно, но реально»: команда старалась, достигла большего, чем без OKR, но ещё есть куда расти.

Ключевое различие: исход vs. активность

Перенос на AI-агентов

SMART и OKR — это не просто HR-инструмент. Для агентных систем они задают архитектуру проверки.

Интерактив: OKR-грейдер агента

Выставьте текущий балл по каждому Key Result (0.0 — не достигнуто, 1.0 — полностью). Среднее и вердикт пересчитываются автоматически.

Guardrail-метрики: антидот к закону Гудхарта

Раз агент оптимизирует ровно то, что измеряют (закон Гудхарта), один-единственный KR опасен: агент «выиграет» его, сломав что-то незамеренное. Лекарство — guardrail-метрики (counter-metrics): к каждой оптимизируемой метрике добавляют страхующую, которая не должна ухудшиться.

Для agent-eval это значит: набор тестов всегда включает не только «прошёл задачу», но и «не наврал / не превысил бюджет / не сломал прежнее поведение». Это прямое применение double-loop из M4: guardrail ловит момент, когда оптимизация прокси начала вредить настоящей цели.

🎮 Мини-игра: сломай метрику (закон Гудхарта)

Агент оптимизирует одну метрику — % пройденных тестов. Но настоящая цель — реальная польза. Выбирай действия и смотри, как расходятся два показателя. Потом включи guardrail и попробуй те же хаки снова.

Committed vs aspirational: два типа OKR

Гибридной аудитории важно: агент обычно получает цели, а не ставит их сам. И цели бывают двух сортов:

Квиз

Модуль 8: Синтез — операционная система агента

Собираем все шесть методик в единый рабочий стек: две петли, три линзы, один когерентный процесс.

Три линзы управленческого цикла

Каждая методика из модулей 2–7 закрывает свою часть цикла. Упорядочим их по трём вопросам, которые задаёт агент на каждой итерации.

Центральная идея: две вложенные петли

OODA крутится много раз внутри одного «Do» цикла PDCA. SMART/OKR задаёт цель, к которой обе петли сходятся. TOC говорит, какую стадию петли нужно чинить. GTD держит внешнюю память чистой. Первопринципы не дают петлям оптимизировать ерунду.

Сквозной сценарий: агент-ассистент по коду

Таблица-гайд: симптом → методика → место в стеке

Запуск ОС агента: пошаговый алгоритм

Методики применяют не «все сразу», а в определённом порядке — от постановки цели к её достижению. Вот рабочий runbook на один цикл задачи:

🩺 Диагност методики

Выберите симптом — получите рекомендацию с объяснением и ссылкой на нужный модуль.

Cynefin: какой режим решения для какой ситуации

До сих пор мы изучали инструменты. Cynefin (Дэйв Сноуден) — мета-рамка над ними: она классифицирует ситуацию и подсказывает, какой тип реакции уместен. «Применять всё подряд» неэффективно — сначала определи домен.

Все методики на одной странице

Ложные друзья: одно слово — разный смысл

Методики из разных школ переиспользуют термины. Не путай:

• Act в OODA (выполнить решение в моменте) ≠ Act в PDCA (закрепить или откатить изменение процесса после Check).
• Check в PDCA (измерить результат против ожидания, обучение) шире, чем «Verify» одного инструмента; в M7 это Measurable/eval.
• Objective в OKR (качественная цель) ≠ Key Result (количественный исход) ≠ задача/активность.
• Orient (OODA) ≠ просто «контекст»: это контекст + модель мира + прошлый опыт.

Когда методики конфликтуют

«Применяй всё сразу» невозможно — иногда рекомендации спорят. Конфликт разрешается разделением по времени и критичности, а не «правилом на все случаи».

Проверьте себя

3 действия на завтра

Готово 🎉

8 модулей пройдены. Что теперь у тебя в инструментарии управления агентами:

• Видеть агента как самоуправляющуюся систему: цель → петля решений → приоритизация.
• OODA: строить быструю петлю Observe-Orient-Decide-Act и понимать, что Orient (контекст/мир-модель) — главный рычаг.
• GTD: разгружать «рабочую память» агента во внешнюю память; правило 2 минут, контексты, регулярный review.
• PDCA: медленная петля улучшения через verification gate; учиться на ошибках между прогонами.
• Первые принципы: декомпозировать задачу до проверяемых аксиом вместо рассуждения по аналогии (cargo-cult-промпты).
• Theory of Constraints: находить узкое место конвейера и не оптимизировать всё подряд.
• SMART / OKR: превращать расплывчатую цель в измеримую спецификацию и eval.
• Синтез: собрать всё в «операционную систему агента» — две петли (быстрая OODA + медленная PDCA) поверх целей и приоритетов.

Что читать дальше

• John Boyd — «Patterns of Conflict» / R. Coram «Boyd». Первоисточник OODA loop.
• David Allen — «Getting Things Done». Каноничный GTD.
• W. Edwards Deming — «Out of the Crisis». Цикл PDCA / Шухарта и kaizen.
• Eliyahu Goldratt — «The Goal». Theory of Constraints на производственном кейсе.
• John Doerr — «Measure What Matters». OKR от Intel/Google (Andy Grove → Google).
• Anthropic — инженерные заметки про агентов, контекст и eval. Перенос этих методик на LLM-агентов.

▶ Пройти курс заново