Неделя 1. Переносим coding-agent практику в проверяемый процесс

Что уже умеем: Python, Git, pytest, вызов модели по одному промпту.
Какую проблему решаем: По готовому ответу не видно, где агент ошибся, и не с чем сравнивать.
Что нового появится: Роль / агентный runtime / оркестрация и первый baseline.
Что получится в конце: Baseline и workflow-кандидат на 3–5 issue с критериями.

🧭 Где мы: [LLM] → Context / State → Tools → Runtime / Orchestration → Policy / Permissions → Evaluation / Observability.

Что меняем в Capstone

Week 1. Создаём единый Capstone: problem-definition.md, baseline workflow и набор issue. Это первая версия системы, которую будем развивать еженедельно до Week 9.

Материал

🤔 Predict

В workflow порядок шагов задан кодом, а агент может выбирать следующий шаг во время работы. Если обе системы получили одну и ту же задачу, какая из них сможет изменить порядок действий после неожиданного результата?

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

%%{init: {"flowchart": {"useMaxWidth": false, "nodeSpacing": 28, "rankSpacing": 22, "wrappingWidth": 460}, "themeVariables": {"fontSize": "14px"}}}%%
flowchart TD
  subgraph WF["Workflow: порядок задан кодом"]
    direction TD
    A1["issue"] --> A2["planner"] --> A3["analyst"] --> A4["implementer"] --> A5["tests"] --> A6["отчёт"]
  end
  subgraph AG["Agent: шаг выбирается в runtime"]
    direction TD
    B1["наблюдаю"] --> B2["решаю"] --> B3["действую"] --> B1
  end

Два похожих на первый взгляд варианта делят код на роли:

%%{init: {"flowchart": {"useMaxWidth": false, "nodeSpacing": 28, "rankSpacing": 22, "wrappingWidth": 460}, "themeVariables": {"fontSize": "14px"}}}%%
flowchart TD
  subgraph SA["Single-agent"]
    direction TD
    S1["задача"] --> S2["один промпт + инструменты"]
  end
  subgraph MA["Multi-agent"]
    direction TD
    O["оркестратор"] --> M1["planner"] --> M2["worker: только чтение"] --> M3["reviewer"]
  end

Разница не в числе промптов, а в том, кто принимает решения. В single-agent варианте переходы заданы кодом заранее. В multi-agent варианте отдельный компонент — оркестратор, то есть код, который по состоянию запуска решает, какая роль следующая, проверяет её входные данные и решает, что делать при отказе.

Три свойства, которые в разговорах смешивают, но в системе разделяют:

роль — какая задача поручена модели и что она должна вернуть;
агентный runtime (среда выполнения агента) — как модель получает инструменты, историю и разрешения: она видит только то, что среда ей передала;
оркестрация — кто и по каким правилам вызывает следующую роль.

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

Проверьте разницу на знакомой задаче кодинга: опишите её как контракт, а не как промпт.

Задача/issue:
Критерии приёмки:
Какие файлы можно читать:
Какие файлы можно менять:
Разрешённые команды:
Запрещённые действия:
Кто принимает план:
Кто проверяет diff:
Условие остановки:

Если этот список нельзя заполнить, задача пока не готова к автоматизации — независимо от того, какая модель будет выполнять её.

Практика

Возьмите 3–5 issue из подготовленного учебного набора. Для обязательного ядра:

зафиксируйте результат обычного одиночного coding agent на этих issue;
реализуйте минимальный процесс «planner → read-only analyst → implementer → проверка»;
повторите на том же issue и с теми же критериями, сравнив итоговый diff, тесты и время ручной проверки.

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

Расширение: сравнить с «planner → implementer → reviewer» или распараллелить двух независимых read-only аналитиков.

Результат недели

baseline на 3–5 подготовленных задачах;
выбранная задача для capstone;
список измеряемых критериев;
аргумент, почему выбранная задача выигрывает от multi-agent подхода.

Обязательное ядро: baseline и один кандидатный workflow.

Расширение: сравнение нескольких топологий на всём наборе.

🎉 What you can do now

Вы можете сравнить агентный workflow с простым baseline по результату и обосновать, оправдана ли дополнительная оркестрация.

Rule

Сравнение с baseline — общий метод для любого workflow: сначала самый простой работающий вариант, потом измерение, и только затем усложнение.

Capstone checkpoint

Week 1. Baseline готов: problem-definition, acceptance criteria и один workflow-кандидат на 3–5 issue.

Проверь себя

Чем workflow отличается от agent?
В каком случае multi-agent решение избыточно?
Что именно ты будешь сравнивать со своим Capstone workflow?

✅ Definition of Done

Объяснить, чем фиксированный workflow отличается от агента, и когда multi-agent не нужен.
Выбрать issue Capstone и задать для него проверяемые критерии приёмки.
Запустить baseline и workflow на одинаковой задаче, затем сравнить критерии, diff, тесты и время проверки.
Найти возможное нарушение scope или лишнее ручное вмешательство и решить, оправдывает ли workflow свою сложность.


←	Курс: обзор
→	Week 2: Workflows / Handoff