555bbf546c
All checks were successful
CI Trade-In / changes (pull_request) Successful in 13s
CI Trade-In / backend-tests (pull_request) Has been skipped
CI Trade-In / browser-tests (pull_request) Has been skipped
CI Trade-In / frontend-checks (pull_request) Has been skipped
CI / changes (pull_request) Successful in 18s
CI / backend-tests (pull_request) Has been skipped
CI / frontend-tests (pull_request) Has been skipped
CI / openapi-codegen-check (pull_request) Has been skipped
Правила ссылались на механику удалённых ботов. Главное — не косметика: секция "Polling loop / Foreground fallback" безусловно предписывала парсить маркер <!-- gendesign-review-bot: ... -->, который писал auto-code-reviewer. Агента нет, маркера нет — соло-сессия опрашивала PR до Cap 30 iter × 60s в ожидании вердикта, которого не будет, и через полчаса пинговала человека. git-pr.md: - Polling loop: шаг 3 вместо маркера бота теперь merge по зелёному CI, добавлены ветки "checks красные" и "человеческий review с правками" - Refs #N -> Closes #N: обходной путь был нужен только потому, что issue закрывал qa-бот на status/done. Бота нет, иначе issue не закроется никогда - Auto-merge policy: убрано упоминание reviewer-окна и approve+SHA gate delegation.md: - снята ветка "bot-pipeline: label status/needs-analysis, снять claim" Что НЕ менялось: сам self-extending guard, пороги эвристик, Cap 30 iter.
57 lines
7.9 KiB
Markdown
57 lines
7.9 KiB
Markdown
# Delegation & task sizing
|
||
|
||
> Без `paths:` — загружается в каждой сессии. Канон лимитов делегирования (портировано из memory-фидбека 2026-06-27, routing/effort — из верифицированного ресёрча 2026-07-02).
|
||
|
||
## Routing (кому отдавать)
|
||
|
||
| Задача | Агент |
|
||
|---|---|
|
||
| Разведка: найти файлы / понять структуру | **Explore** (Haiku, read-only, дёшев) — НЕ general-purpose |
|
||
| Спроектировать подход | **Plan** |
|
||
| Код | доменный worker (backend/frontend/database/devops) + `isolation: "worktree"` |
|
||
| Проверить результат | отдельный агент **в fresh context** — видит только diff и критерии, без bias автора |
|
||
|
||
- Продолжение работы существующего агента → `SendMessage` по agentId (контекст цел), НЕ новый спавн с пересказом.
|
||
- Масштаб пачки: 1-3 независимых → параллельные Agent-вызовы одним сообщением; конвейер / 10+ агентов → Workflow (pipeline-default, `schema`-выход, adversarial verify находок). Caps на выборках — логируй отброшенное, молчаливое усечение читается как «покрыто всё».
|
||
|
||
## Бюджет одного сабагента (hard limits)
|
||
|
||
- **1 сабагент = 1 узкий deliverable.** Ориентиры: ~≤10 мин работы, ~≤20 tool-calls, ~≤150k токенов.
|
||
Эмпирика 2026-06-27: агент-аудитор на 186k tok / 33 calls упал на StructuredOutput; 5 мелких параллельных прошли.
|
||
- Поверхность больше бюджета → **дели на N узких сабагентов** (parallel при непересекающихся файлах, sequential при зависимостях). НЕ один большой.
|
||
- Промпт сабагенту: конкретный deliverable + формат ответа + границы («что НЕ делать»). Расплывчатый scope = дубли и мусор.
|
||
- **Бюджет живёт В ПРОМПТЕ, а не в голове оркестратора.** Знать лимит недостаточно — агент его не видит. Пиши в промпт явно: потолок вызовов (~20-25) и времени, список «строго запрещено» (типично: не читать исходники приложения, не ходить в git-историю, не диффать смежное), правило деградации «бюджет кончается → отдай что есть, допиши в notes что не успел».
|
||
Эмпирика 2026-08-24: два разведчика без потолка ушли на 157 и 178 ходов вместо инвентаризации — один вместо списка веток диффал SQL-миграции и разбирал Caddyfile.
|
||
- **`schema:` требует потолка РАЗМЕРА ответа, отдельно от токенов.** Payload `StructuredOutput` >~10k символов не парсится (`InputValidationError`) → повтор → вся работа агента теряется. В промпт: максимум N items, лимит символов на поле, весь ответ ≤~6000 символов, и прямым текстом «неполный ответ несравнимо лучше потерянного». Схему проектируй под краткость: длинные `detail`-поля провоцируют ровно этот отказ.
|
||
- Windows: очень длинный промпт субагенту может упасть на лимите командной строки (~8191 символ) — ещё один довод за компактность.
|
||
|
||
## Эскалация oversized-задачи (worker)
|
||
|
||
Issue/задача выглядит больше одного захода (эвристика: >5 файлов, ИЛИ >500 строк diff, ИЛИ >2ч) → **НЕ исполнять целиком**:
|
||
- вернуть main-сессии план сплита вместо результата
|
||
|
||
## Целость результата workflow
|
||
|
||
- **Завершившийся прогон ≠ успешный.** Читай `<failures>` в уведомлении и `journal.jsonl` (по строке `result` на агента). Упавшие агенты возвращают `null`, `parallel()` их молча проглатывает, а стадия синтеза всё равно выдаёт уверенный текст с числами. Прежде чем показывать такой вердикт пользователю — проверь его несущие числа сам.
|
||
- **Восстановление:** `TaskStop` → `Workflow({scriptPath, resumeFromRunId})`. Готовые агенты реплеятся из кэша бесплатно, перезапускаются только упавшие. Правка промпта перезапускает ЭТОТ агент и все последующие (правило префикса) — правь точечно, не переписывай скрипт целиком.
|
||
- **Диагностика зависшего агента:** возраст последней записи в `agent-*.jsonl` + тип последнего события. `assistant/tool_use` без ответа при неподвижном журнале = завис. Несколько агентов замолчали одновременно = обрыв соединения, обычно лечится сам повтором — не спеши убивать.
|
||
- **Windows: скрипт workflow писать только в LF.** Перезапись через python даёт CRLF → запуск отбивается `script contains control characters`. `io.open(..., 'w', newline='\n')`.
|
||
|
||
## Единые пороги дробления (analyst / main)
|
||
|
||
- Estimate S(<2h) / M(2-8h) / **L(>8h) → обязан дробиться дальше** (до S/M)
|
||
- Issue ≥1.5 дня → 3-4 sub-PR (Foundation → Schema → Workers → Integration), каждый ~200-500 строк — см. git-pr.md § Split big issues
|
||
- 1 sub-issue ≈ 1-2 worker-захода, single-scope (не смешивать backend+frontend в одном issue)
|
||
|
||
## Параллелизм
|
||
|
||
Default = parallel на непересекающихся файлах (per-task worktree). Sequential — только overlap / hot-files / зависимый стек (git-pr.md § Parallel vs sequential PRs).
|
||
|
||
**Усилие ∝ сложности**: простой факт-запрос = 1 агент / 3-10 tool-calls; сложный разбор = N узких параллельных. Ширина пачки дешева, толщина одного агента — дорога и хрупка. Параллельные сессии/окна: практический потолок 3-5 (bottleneck — review, не Claude).
|
||
|
||
## Effort / model per agent
|
||
|
||
- Наследовать по умолчанию; модель НЕ переопределять без нужды (Explore и так на Haiku).
|
||
- `effort: low/medium` — механика: точечные правки по списку, сбор данных, mass-grep, формат-конверсии.
|
||
- `effort: high+` — только verify/judge-этапы, архитектурный синтез, решения.
|
||
- Циклы/поллинг: prompt-cache живёт 5 мин — тик либо <~4.5 мин (кэш тёплый), либо сразу 20-30 мин; интервалы 5-15 мин = worst case (полный re-read контекста каждый тик без амортизации).
|