Skip to content

Capstone: эволюция системы

Этот документ — spine курса. Вместо девяти оторванных задач вы развиваете одну и ту же систему от Week 1 до Week 9: agent, который безопасно решает issue в Python-репозитории. Каждая неделя меняет решение, а не заменяет Capstone.

Skill Lab ≠ Capstone. Специализированные лаборатории (Taskboard, Repo Triage, RAG Lab, Integration Lab) учит механику изолированно. Capstone показывает, зачем эта механика нужна в реальной системе.


Архитектурная эволюция

%%{init: {"flowchart": {"useMaxWidth": false, "nodeSpacing": 20, "rankSpacing": 40}, "themeVariables": {"fontSize": "13px"}}}%%
flowchart TD
  W1["Week 1\nbaseline + issue"] --> W2["Week 2\nplanner → analyst → implementer\n+ handoff contract"]
  W2 --> W3["Week 3\n+ State\n+ evidence path:line\n+ role context"]
  W3 --> W4["Week 4\n+ ModelClient\n(provider abstraction)"]
  W4 --> W5["Week 5\n+ Runtime\n+ RunPolicy\n+ HumanGate"]
  W5 --> W6["Week 6\n+ Tools\n+ Policy\n+ Approval\n+ external integration"]
  W6 --> W7["Week 7\n+ Eval\n+ Trace"]
        W7 --> W8["Week 8\nBusiness automation\n+ solution design"]
        W8 --> W9["Week 9\nFastAPI service\n+ PostgreSQL\n+ Docker\n+ delivery"]
  classDef week fill:#f5faf9,stroke:#0d9488,stroke-width:2px;
        class W1,W2,W3,W4,W5,W6,W7,W8,W9 week;

Таблица эволюции

Week Capstone change Student artifact
1 baseline + candidate task problem-definition.md, baseline, acceptance criteria, issue set
2 topology + handoff capstone graph, handoff contract schema
3 context + state State struct, path:line evidence, role templates
4 ModelClient ModelClient, structured output validation, mock provider
5 runtime + policy Workflow, RunPolicy, HumanGate, budget
6 tools + external integration Tool registry, allowlist, approval gate, external API
7 evaluation + tracing Eval report baseline vs workflow, trace of 2 runs
8 business automation + solution design AS-IS / TO-BE, automation candidate, architecture choice, human boundary, measurable goals
9 production service FastAPI, PostgreSQL, Docker, observability, CI, KPI report

Week 1 → Week 2

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

Change: заменяем "один промпт" на цепочку ролей с фиксированным контрактом handoff: planner → read-only analyst → implementer → review.

Reason: каждая роль видит только то, что явно передано в контракте — а не всю историю переписки.

Result: student builds capstone graph с указанием read-only / write / human approval узлов.


Week 2 → Week 3

Problem: агент видит либо слишком мало контекста (баг не воспроизводится), либо слишком много (история за 40 шагов теряет релевантное).

Change: вводим State — структурированный факты о прогрессе, path:line evidence вместо пересказа, JIT-контекст и role-specific шаблоны.

Reason: контекст — это внимание, а не объём. State передаётся между ролями вместо истории переписки.

Result: before/after:

Week 2: agent receives issue
        → planner returns free text

Week 3: agent receives issue
        → planner fills State
        + repo_evidence with path:line
        + role-specific context
        + JIT context from read-only analyst

Week 3 → Week 4

Problem: workflow завязан на конкретный provider SDK. Смена провайдера = переписывание бизнес-логики.

Change: выносим model call за ModelClient — тонкий адаптер. Workflow видит только generate(messages, schema=...) и generate_with_tools(...).

Reason: модель становится заменяемой частью системы, а не частью бизнес-логики.

Result: student swaps provider (cloud → local) без изменения workflow кода; mock provider в тестах.


Week 4 → Week 5

Problem: между вызовами теряется состояние, лимиты не соблюдаются, опасное действие выполняется сразу.

Change: формализуем runtime: State → Role → Transition → RunPolicy → HumanGate. RunPolicy задаёт конечный budget (calls, time, retries). HumanGate останавливает side effects.

Reason: без конечных retry-лимитов цикл «попробовать ещё раз» превращается в зависший процесс.

Result: student runs workflow с конечным бюджетом на mock; исчерпание retry после invalid schema → failed; policy rejection до tool execution → blocked; разрешённый side effect ждёт needs_approval.

В Week 9 Production Layer needs_approval — non-terminal persisted snapshot остановленного execution на HumanGate с completed_at = null. Сервис не предоставляет resume endpoint, поэтому это не полноценное возобновляемое состояние очереди.


Week 5 → Week 6

Problem: модель может предложить запись, и промпт её не остановит — правило «не трогай чужие файлы» в тексте не работает.

Change: добавляем Tool registry с narrow schema, Policy check (allowlist путей/команд), Permission (least privilege per role), HumanGate для side effects.

Reason: разрешения реально применяет runtime и policy, а не текст промпта.

Result: Integration Lab учит механику изолированно, затем student переносит pattern в Capstone — тот же Tool → Policy → Approval → Trace, но уже в свой workflow.


Week 6 → Week 7

Problem: два workflow выглядят одинаково убедительно, но один выполняет критерии приёмки, а другой нет. Разница видна только в измерении.

Change: запускаем Eval: ground truth, метрики (quality, cost, latency, human intervention), trace двух прогонов — baseline vs Week 6 system.

Reason: без измерения нельзя сравнить архитектуры. Каждое изменение должно иметь измеримую пользу.

Result: student produces eval report с разницей baseline vs multi-agent, root-cause из trace одного неудачного запуска.


Week 7 → Week 8

Problem: качество workflow уже можно измерить, но неясно, какая часть процесса действительно заслуживает автоматизации и какой результат считать ценным.

Change: описываем AS-IS, находим pain points, сравниваем automation candidates, выбираем один участок и фиксируем TO-BE, уровень автономности, human boundary и KPI-цели.

Reason: сначала выбираем, что именно автоматизировать и почему выбранный механизм подходит; более сложная архитектура не является целью сама по себе.

Result: solution design Capstone обоснован и имеет измеримые цели; допустимый результат анализа — отказаться от агента, если надёжнее обычный код или workflow.


Week 8 → Week 9

Problem: обоснованное решение пока остаётся workflow, который сложно вызвать извне, пережить между запросами и наблюдать как сервис.

Change: productionize тот же Capstone: FastAPI, PostgreSQL persistent state, external integration, async execution, secrets/config, Docker, observability, error handling и CI.

Reason: поставка не должна менять выбранную в Week 8 границу автоматизации и архитектуру; она делает решение доступным и проверяемым как production-like сервис.

Result: студент запускает сервис через docker compose up, проверяет его поведение и вручную сопоставляет измеренный outcome с KPI-целями Week 8. Отчёт time saved, success rate, automation rate, quality и cost не генерируются автоматически из Compose.


Источники заимствований

Skill Lab Механика Где применяется в Capstone
Taskboard handoff contract, baseline test Week 1-2
Repo Triage repository evidence, path:line Week 3
RAG Lab JIT context, retrieval as tool Week 3 (extension)
Integration Lab Tool → Policy → Approval → Trace, external API Week 6 → 9