Підзадача — це контракт: як будувати AI-роботу без агентного хаосу

ai · 2026-10-13

Коли агент отримує велику задачу, проблема зазвичай не в тому, що модель «слабка». Проблема в нечіткій межі роботи: незрозуміло, що саме вона має зробити, які інструменти їй дозволені, коли робота завершена і як наступний виконавець перевірить результат.

Корисна одиниця автоматизації — не повідомлення в чаті, а підзадача-контракт. Вона має п’ять полів:

input — посилання на конкретний контекст, а не весь vault;
authority — дозволені інструменти та область запису;
done_when — спостережувальна умова завершення;
receipt — короткий результат, докази й невирішені питання;
idempotency_key — ідентифікатор, за яким повторний запуск не створює дубль.

Це змінює роль агента: він не «веде розмову до перемоги», а виконує обмежену роботу, після якої інший процес може безпечно продовжити.

Що відрізняється в Claude, Codex і OpenCode

У Claude Code для масштабніших задач є dynamic workflows: документація Anthropic про workflows описує скрипт, який сам тримає цикл, розгалуження та проміжні результати, а сесія отримує підсумок. Такий workflow можна повторно запустити й додати незалежну перевірку результатів. Це ближче до надійного worker-а, ніж один довгий prompt.

У Codex поділ добре видно на рівні SDK: документація OpenAI про Codex SDK описує thread, який можна продовжити або відновити за ідентифікатором, і sandbox-и read_only, workspace_write та full_access. Sandbox можна змінити для наступного turn. Отже, receipt має містити не тільки текст, а й thread_id, режим доступу та результат перевірки.

В OpenCode поділ явніший: команда може бути прив’язана до конкретного агента, а subtask: true примусово запускає її як підзадачу, щоб не забруднювати головний контекст. Документація OpenCode про commands показує також окремі шаблони команд і параметри. Це хороший орієнтир для OpenClaw: маршрут і межі роботи мають бути властивістю конфігурації, а не проханням у prompt.

Висновок спільний: підлеглий виконавець повинен мати менший контекст, меншу владу і формальний спосіб повернути результат. Різниця лише в тому, де саме це налаштовується — hooks, API-події чи конфігурація агента.

Мінімальний контракт для OpenClaw

Почніть із Markdown або JSON, але не залишайте формат усним. Наприклад, запис у vault/tasks/inbox/ може мати такий вигляд:

id: research-openclaw-routing-2026-10-13
input:
  - vault/research/openclaw-routing.md
  - vault/_shared/conventions.md
authority:
  tools: [read, web_search]
  write_scope: vault/tasks/outbox/
done_when:
  - 3 primary sources opened
  - 5 claims mapped to sources
  - receipt written
receipt: vault/tasks/outbox/research-openclaw-routing-2026-10-13.md
idempotency_key: research-openclaw-routing-2026-10-13
expires_at: 2026-10-14T11:00:00+01:00

Важливе правило: authority має бути технічним обмеженням, а не лише текстом. Якщо робітнику потрібен тільки пошук, не підключайте йому запис у vault, shell або Telegram. Якщо платформа не вміє тонко обмежити інструменти, компенсуйте це окремим процесом або контейнером із read-only монтуванням.

Receipt має бути коротким і придатним для машинного читання:

status: succeeded
task_id: research-openclaw-routing-2026-10-13
summary: Виявлено два способи маршрутизації; для бота рекомендовано чергу.
evidence:
- https://code.claude.com/docs/en/workflows — повторювана оркестрація та перехресна перевірка
- https://learn.chatgpt.com/docs/codex-sdk — thread і sandbox Codex
- https://opencode.ai/docs/commands/ — команда як окрема підзадача
changed: []
open_questions:
- Чи потрібен окремий retry для тимчасової помилки пошуку?

Батьківський агент читає receipt, а не вгадує результат із довгого логу. Якщо status не succeeded, він не публікує висновок автоматично.

Чотири робочі схеми

1. Vault як черга, а не як пам’ять

Розділіть tasks/inbox, tasks/working і tasks/outbox. Диспетчер створює файл із контрактом, worker атомарно переносить його в working, а після завершення пише receipt в outbox. Повторний запуск спочатку шукає idempotency_key серед завершених записів.

Це дешевше за постійну розмову в одному контексті: worker отримує лише потрібні сторінки, а історія виконання залишається перевірюваною. Ціна — потрібен простий прибиральник для прострочених working-файлів і блокування від двох worker-ів.

2. Telegram-бот як диспетчер, не виконавець

Для Telegram розділіть topology на три ролі:

router перевіряє chat ID, ставить задачу в чергу й повертає task_id;
worker читає контракт і виконує роботу без права відповідати в довільні чати;
reviewer читає receipt і вирішує, чи можна надіслати короткий результат.

Router не повинен мати доступу до всього vault, а worker — до токена адміністративних повідомлень. У повідомленні Telegram показуйте queued, running, succeeded або blocked, а не внутрішній лог інструментів. Так збій моделі не перетворюється на спам і не розкриває приватний контекст.

3. Планувальник із дедуплікацією

Для щоденного job формуйте ключ із дати, секції та типу роботи:

ai-article:2026-10-13:content/ai

Перед стартом worker перевіряє, чи існує вже успішний receipt із цим ключем. Після коміту receipt фіксує hash файлу, результат валідатора і статус Hugo build. Якщо job перезапустився після мережевої помилки, він продовжує з того самого ключа, а не створює другу статтю.

4. «Тіньовий редактор» із нульовим правом запису

Нестандартний, але корисний варіант: після кожної зміни запускати reviewer-agent у окремій сесії, який бачить diff і джерела, але не бачить токена публікації та не може редагувати робоче дерево. Він повертає лише список blockers і warnings.

Перевага — автор і критик мають різні контексти, тому критик не повторює помилкове припущення автора. Недолік — додаткова затримка й витрати; для малих змін це невигідно. Практичне правило: вмикати такий режим для зовнішніх публікацій, змін дозволів і міграцій, але не для перейменування локальної змінної.

Як не створити агентну рекурсію

У кожного worker-а мають бути явні межі:

максимум одна глибина делегування;
максимум N інструментальних кроків або часовий бюджет;
дозвіл на конкретний каталог і типи інструментів;
обов’язковий receipt навіть для blocked і failed;
retry лише для класифікованих тимчасових помилок.

Не просіть агента «продовжувати, поки не буде ідеально». Це не політика надійності, а необмежений цикл. Краще завершити підзадачу з blocked, зберегти докази і передати рішення людині або іншому, сильніше обмеженому reviewer-у.

Початковий playbook може бути таким: створити контракт → перевірити дедуплікацію → запустити read-only research → записати receipt → перевірити джерела й diff → лише потім дозволити worker-у зміну → запустити reviewer → опублікувати тільки після succeeded. Такий ланцюг трохи повільніший за один великий prompt, зате його можна повторити, виміряти і безпечно зупинити.