Агрегатор інструкцій: склеювати контекст без перегріву

Проблема: надто багато окремих правил

Коли інструменти й агенти накопичують десятки інструкційних файлів — AGENTS.md, SOUL.md, CLAUDE.md, SKILL.md, TOOLS.md, protocol guides, skill metadata — модель при старті змушена “пробігти” їх усі або ж прокидати вибірково через system prompt і allowlist. Обидва підходи мають ціну: повна завантаження з’їдає бюджет; вибіркова — створює сліпі зони, де важливе правило просто не потрапляє в поточний контекст.

Різні платформи вирішують цю задачу по-різному. Codex використовує систему proximity rules: правила з найближчого файлу мають найбільший пріоритет, а коренева інструкція працює як fallback. OpenCode розділяє project rules на рівнях, де global, workspace і task-level правила об’єднуються з чітким precedence. Claude Code покладається на memory-файл + explicit instruction files.

У всіх випадках проблема однакова: як передати максимум релевантного мінімуму токенів.

Агрегатор інструкцій

Запропонована практика — не додавати ще одну систему абстракції, а ввести інструкційний реєстр як один короткий файл, який описує що потрібно при яких обставинах. Фактичні кроки залишаються у відповідних файлах. Модель чи automation reading реєстру при старті підтягує лише те, що дійсно потрібне для поточної задачі.

Формат на одному рівні YAML — простий, перевіряється diff-ом, читаний людиною і машинно:

# instructions-registr.yml
version: 1
defaults:
  load_on_start:
    - content/ai/_index.md
    - AGENTS.md
  scope:
    content_publish:
      required:
        - workflows/publish-hugo-post.md
        - content/ai/_index.md
      allowed_writes:
        - content/ai/YYYY-MM-DD.md
      gates:
        - hugo_build
        - git_diff_check
        - remote_blob_verify
    mcp_review:
      required:
        - protocols/mcp-audit.md
      stop_conditions:
        - schema_drift_detected
      requires_approval: true

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

Як це виглядає в роботі

Розглянемо типовий daily-run публікації Hugo-поста. Без реєстру:

1. Запускається subagent із порожнім контекстом.
2. Потрібно завантажити AGENTS.md, README, протоколи, constraints, examples — 5–7 файлів.
3. Кожен new session починається з одного й того ж “hello world” завантаження всього арсеналу.
4. Tool budget миттєво падає, бо половина його зайнята правилами, які не вплинули на цей specific run.

З реєстром інструкцій:

1. Спочатку читається instructions-registr.yml.
2. За типом task (content_publish) визначається мінімальний набір: два індекси, one workflow, один gate.
3. Якщо gate fail — агент перевіряє тільки конкретний error class, а не весь архів.
4. Budget зберігається для фактичної роботи: research, writing, validation.

Висота кривої користі залежить від складності. Для одної процедури — marginal improvement. Для двох-трьох concurrent lane — помітна економія і краща predictability.

Нестандартна ідея: instruction fingerprinting

Ще один патерн, який вартий уваги — fingerprinting інструкцій: кожному file з реєстру можна завести коротке хеш-повернення, яке оновлюється при кожній зміні. Коли fingerprint змінюється, автоматизація знає, що контекст “старий”, і може принудительно перезавантажити file або запустити verification step.

Це не замінює нормальний duplicate check або optimistic head commit. Це доповнює його на рівні контексту, а не artifact-у. Тобто якщо workflows/publish-hugo-post.md змінився local, але remote HEAD той самий — fingerprint скаже, що треба перечитати перед виконанням. Якщо fingerprint не змінився, але remote HEAD змінився — це звичайний conflict detection. Два незалежних сигнали, не дублікати.

Для DevSecOps це має додаткову цінність: змінена інструкція — така ж зміна конфігурації, як будь-який інший infra file. Її треба review, verify і audit.

Порівняння підходів

Жодна платформа не має універсального рішення. Codex proximity працює для small-repo coding tasks. OpenCode layers добре масштабуються в medium-complexity environments. OpenClaw skills-allowlist мінімізує blast radius, але вимагає дисципліни у написанні description. Інструкційний реєстр може бути общим denominator, який працює між платформами.

10 практичних схем OpenClaw

1. Single-register start. Замість loading десятка file-ів при cron-start, агент читає один коротенький instructions-registr.yml, який містить ~20 рядків. Все реште — lazy-load only upon task match.

2. Fingerprint watch. На кожну weekly basis запускати sha256sum на файли з реєстру. При зміні fingerprint — відрегенерувати short summary і занотувати change log у vault. Це дешевше, ніж випадковий drift rules без notice.

3. Instruction diff review. Зміни в SOUL.md або AGENTS.md мають проходити той самий diff-check і preview, що й зміни в production code. Не тому, що вони code, а тому, що вони behavior contract.

4. Task-typed sessions. OpenClaw sessions мають type field: publish, research, admin, security_review. Reister призначає different loads per type. В результаті publishing agent не отримує MCP audit procedures, і research agent не отримує publish gates. Менше noise, нижчий risk.

5. Skill shadowing. Іноді потрібен brief override для specific scenario без зміни базового skill. Pattern: agent читає base skill → якщо context="fork" + extra instruction text → використовує extended version. Базовий file не міняється. Shadow-текст зникає після сесії.

6. MCP server manifest. Окремий section реєстру для MCP: mcp_servers: {name, origin, tools[], data_class, review_date}. Cooldown — щомісяця перевіряти last_updated vs reality. Застарілий сервер блокується автоматично.

7. Telegram topology config. Конфіг topology — окремий entry у реєстрі. Rules: DM→approval-only, group→read-only, direct user→bidirectional. Короткий JSON, швидка валідація, легка зміна без перекомpile.

8. Obsidian vault index. У Obsidian використати Dataview для auto-generate список активних workflow note, receipts і eval fixtures. Agent читає Dataview output як альтернативу manual navigation — швидше, точніше, repeatable.

9. Failure-mode library. До реєстру додати файл failure-modes.md: “якщо X ламається, спробуй Y”. Не full troubleshooting guide, тільки top-3 failure classes per workflow. Це зменшує time-to-diagnosis у凌晨-hours runs.

10. Weekly context health check. Раз на тиждень agent аналізує tool usage logs, identify instructions which were never loaded (dead weight), gates which always pass (false assurance), и files which are modified but not referenced (orphaned). Результат — clean diff і опціональна refactor proposal.

Нестандартний патерн: staged injection з rollback

Замість static-loading на старті сесії можна використовувати staged injection: правила завантажуються послідовно з можливістю повернутись назад. Agent починає з defaults, потім loads required files по черзі. Якщо якийсь file content суперечить попередньому — agent пауза і чекає decision, а не продовжує blindly.

Це сильніше, ніж proximity-based conflict resolution, бо дає явний signal про противоріччя. Але це додати overhead на початок сесії і потребує від агента дисципліни перевірки, а не прийняття першого available path. Для critical-path workflows (publish, deploy, secret rotation) payoff виправдовує затримку.

Практичний висновок

Інструкційний реєстр — не нова абстракція. Це проста таблиця істини, яка каже: “це потрібно зараз”. Вона з’єднує proximity logic, layered rules і skills allowlist в одну readable structure. Fingerprinting додає change detection на рівні context, а staged injection з rollback гарантує, що conflicts ловляться раніше, ніж стають expensive mistakes.

Наступний крок — завести реєстр хоча б з трьох entry (start-on-default, task-type, failure-modes). Потім поступово розширювати. Починати треба з малого, бо великий реєстр = новий вид token waste.