DevSecOps Digest
Щоденний DevSecOps дайджест

AI без шуму: контекстний бюджет, Markdown-контракти і 10 робочих схем OpenClaw

ai · 2026-09-23

Головна ідея

Якість AI-роботи часто падає не через слабку модель, а через погано керований контекст. У довгій сесії накопичуються старі припущення, невдалі спроби, великі tool outputs і правила, які вже не стосуються поточної задачі. Модель витрачає токени на підтримку історії замість рішення.

Практичне правило: сесія — це робочий контекст із терміном придатності, а Markdown-файл — довготривалий контракт. Рішення, обмеження, команди перевірки й посилання треба виносити у файл. Сесію слід завершувати, коли змінюється задача, джерело істини або рівень ризику.

Коли починати нову сесію

Нова сесія дешевша за спробу “пояснити ще раз” у таких випадках:

  • змінився результат, якого треба досягти: від дослідження до публікації, від діагностики до виправлення;
  • у transcript зʼявилися невдалі підходи, які більше не треба наслідувати;
  • tool output займає більше місця, ніж рішення, яке з нього випливає;
  • змінюється permission boundary: read-only робота переходить у запис, зовнішню дію або production;
  • модель починає повторювати старі припущення або просить контекст, який уже був наданий;
  • одна тема розгалузилась на кілька незалежних deliverables.

Перед стартом нового run достатньо зберегти короткий handoff:

## Handoff
- Ціль: що має бути готово
- Вже перевірено: факти й посилання
- Не спрацювало: підходи, які не повторюємо
- Обмеження: файли, команди, permissions
- Наступний крок: одна конкретна дія
- Definition of done: як перевірити результат

Це краще за перенесення всього transcript: зберігається рішення, а не шум.

Compaction — це не резервна копія

Компресія контексту корисна, але її не слід сприймати як точне відновлення історії. Claude Code описує автоматичний і ручний /compact, перегляд витрат через /context та правила того, що переживає compaction. OpenClaw має окремі режими context inspection, compaction і session pruning: вони вирішують різні проблеми — summary стискає діалог, pruning прибирає старі tool results.

Безпечний протокол:

  1. перед compaction попросити модель сформувати state.md з рішеннями, відкритими питаннями, файлами та командами перевірки;
  2. після compaction перечитати тільки state.md і потрібні файли, а не весь архів;
  3. повторно перевірити критичні факти — commit, URL, API response, тест або checksum;
  4. якщо зникла важлива причина рішення, почати нову сесію з явним handoff.

Не варто покладати незворотне рішення тільки на summary. Summary — навігація; файл, тест і receipt — evidence.

Що винести в Markdown-інструкції

Добрий instruction file не є енциклопедією. Він задає порядок роботи й межі:

# Workflow: publish-hugo-post

## Scope
- Дозволено змінювати тільки `content/ai/YYYY-MM-DD.md`.
- Не змінювати remote без optimistic-head check.

## Procedure
1. Перевірити дублікати URL і заголовків.
2. Написати файл без повторного H1.
3. Запустити `hugo` і `git diff --check --`.
4. Опублікувати один файл.
5. Перевірити remote blob.

## Stop conditions
- target уже існує remote;
- build або diff check не пройшов;
- head змінився;
- verification не збігається з локальним файлом.

## Receipt
- target, commit, validation, sources, failure stage

Для repo-level правил корисно порівняти три підходи. Codex завантажує AGENTS.md і застосовує більш специфічні інструкції ближче до поточного файлу. OpenCode розділяє project rules, agents і on-demand SKILL.md, окремо документуючи agents та skills. Claude Code використовує CLAUDE.md та memory як повторно доступний project context.

Спільний принцип такий: короткі правила — завжди доступні, довгі процедури — завантажуються за потреби, а permissions і stop conditions не ховаються в загальному prompt.

Agent, skill, plugin чи MCP

Якщо процедура повторилась тричі, спочатку винесіть її в Markdown skill. Якщо вона має власний state, retry, approval і receipt — це вже workflow, а не просто skill. Якщо потрібні інші permissions або незалежний lifecycle — створюйте agent.

Нестандартний патерн: контекстний lease

Замість постійної “довгої памʼяті” можна видати кожній задачі context lease — маленький файл із TTL і бюджетом:

task: audit-mcp-tools
expires: 2026-09-24T09:00:00+01:00
max_tool_calls: 12
allowed_paths:
  - notes/mcp/
must_verify:
  - tool-schema-diff
  - source-origin
handoff: notes/mcp/2026-09-23-state.md

Агент читає lease на старті, зупиняється після TTL або ліміту викликів і записує receipt. Наступна сесія отримує тільки handoff та докази. Перевага — передбачувана ціна, менше context drift і простіший аудит. Компроміс — додаткова операційна дисципліна: lease треба оновлювати для довгих задач, а жорсткий ліміт може зупинити корисний run. Для cron, security review і контентної публікації це зазвичай вигідний обмін.

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

  1. Щоденний context budget. Для кожного cron-run задати max_tokens, max_tool_calls, список дозволених файлів і definition_of_done. У receipt записувати фактичні витрати; наступного тижня скоротити rules, які жодного разу не вплинули на результат.

  2. Obsidian vault як компільований knowledge base. Розділити sources/ (immutable captures), decisions/ (короткі висновки), workflows/ (процедури) і receipts/ (результати). Agent читає спочатку decision/workflow, а до великих source-файлів звертається тільки за citation.

  3. Handoff-команда для Telegram. Зробити команду /handoff: бот бере з поточної сесії ціль, рішення, blockers і next step, пише Markdown у vault і повертає короткий ID. Нова сесія стартує з ID, а не з пересланих сотень повідомлень.

  4. Тиха Telegram-топологія. DM використовувати для approvals і приватних receipts, group — для read-only запитів та коротких результатів, cron — для тихої роботи. Router перевіряє channel перед write/tool call; routine progress у Telegram не надсилається.

  5. Skill promotion queue. Після третього однакового run OpenClaw створює draft workflows/candidates/<name>.md із inputs, commands, gates і failure modes. Людина переглядає його, і лише потім процедура стає доступним skill.

  6. MCP schema canary. Раз на день зберігати tools/list у vault, порівнювати назви, schemas, descriptions і server origin. При зміні — блокувати write-capable agent, дозволяти тільки diff і вимагати review. Це спирається на MCP tools як контракт, але не довіряє контракту без перевірки.

  7. Два агенти для одного ризику. researcher збирає факти без write access, operator виконує вузьку дію тільки з receipt. Передача між ними — JSON/Markdown handoff із source links, не повний transcript. Так зменшується blast radius prompt injection і помилкових припущень.

  8. Context firewall для великих файлів. Перед передачею PDF, логів або web output агент спочатку запускає локальний extractor, який повертає лише потрібні рядки, checksum і provenance. Повний файл лишається на диску; у модель потрапляє мінімальний evidence slice.

  9. Failure replay pack. Кожен невдалий run зберігати як fixture: input class, tool result, очікуваний stop condition і правильний receipt. Після зміни skill або plugin проганяти fixtures локально; це дешевше, ніж чекати повторення production-помилки.

  10. Publish як state machine. Описати стани draft → validated → ready → committed → verified. Перехід дозволяє тільки конкретна перевірка: Hugo build, git diff --check, optimistic head або remote blob. Якщо verification не пройшов, статус лишається failed і новий run не маскує помилку повторною публікацією.

Робоче правило на щодень

Перед стартом запитайте: це та сама задача, той самий permission boundary і той самий source of truth? Якщо ні — нова сесія. На старті прочитайте короткий instruction file, а не весь архів. У процесі записуйте рішення у Markdown. Наприкінці залишайте receipt із перевіркою, а не фразу “готово”.

Так AI використовується ефективніше не завдяки нескінченному контексту, а завдяки коротким lease, точним інструкціям, on-demand skills і доказовим переходам між станами.