Нова сесія дешевша за ще один /compact: як керувати контекстом AI

ai · 2026-10-04

Довгу розмову з AI легко сплутати з прогресом. Спочатку модель знає задачу, обмеження й рішення. Після десятків повідомлень вона вже носить у контексті журнали команд, невдалі гіпотези, старі вимоги та кілька версій плану. Навіть якщо сервіс автоматично стискає історію, наступний крок спирається на переказ, а не на повний робочий стан.

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

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

У Claude Code сесія є збереженою розмовою, привʼязаною до каталогу проєкту: її можна відновити, розгалузити або перемкнути (документація Claude про керування сесіями). Але новий контекст не означає автоматичного знання незавершеного рішення. Тому для переходу між фазами потрібен короткий handoff, а не сліпе продовження старого transcript.

У Codex межу контексту можна зробити операційною. Hooks підтримують SessionStart, SessionEnd, PreCompact і PostCompact; їх можна використати для запису підсумку, перевірки стану або додавання контексту після автоматичного стискання (офіційна документація Codex Hooks). Отже, compaction — це подія, яку можна обробити кодом, а не магічний момент, якого треба боятися.

У OpenCode розширення можуть перехопити experimental.session.compacting перед генерацією підсумку й додати доменний контекст, якого бракує стандартному переказу (документація OpenCode про plugins). Поведінку стискання можна налаштувати через конфігурацію, а конфіги з різних рівнів зливаються за визначеним пріоритетом (конфігурація OpenCode). Це зручно для командних правил, але підвищує ризик непомітного перевизначення: перед запуском слід знати, який рівень конфігурації переміг.

В OpenClaw вибір залежить від harness. Офіційний Codex harness передає низькорівневий стан сесії самому Codex: resume потоку, продовження викликів інструментів і native compaction; OpenClaw натомість відповідає за канали, файли сесій, дозволи та видимий transcript (документація OpenClaw про Codex harness). Практичний наслідок: канал Telegram може залишатися тим самим, а робоча сесія — змінюватися. Не треба робити історію чату єдиним сховищем стану.

Коли натискати `/compact`, а коли починати заново

Стискання доречне, коли:

наступний крок належить до тієї самої фази;
у розмові мало суперечливих гіпотез;
важливі рішення вже записані у файли або diff;
потрібна безперервність інструментів і поточного плану.

Нова сесія краща, коли:

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

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

Мінімальний handoff замість копіювання історії

Перед завершенням фази створіть один структурований запис. Він має містити не переказ розмови, а стан, який можна перевірити:

task: "підготувати зміну автентифікації"
phase: "implementation"
goal: "замінити локальну перевірку токена на перевірку через шлюз"
decisions:
  - "зберегти зворотну сумісність для старого заголовка до кінця місяця"
facts:
  - "тестовий шлюз повертає 401 без audience"
open_questions:
  - "чи потрібен окремий ліміт для внутрішніх клієнтів"
changed_artifacts:
  - "auth middleware"
checks_to_run:
  - "unit tests"
  - "integration test against gateway"
next_action: "додати тест на відсутній audience"
stop_conditions:
  - "не змінювати схему токена без окремого рішення"

Збережіть цей запис у vault як handoff поточної роботи. У наступній сесії дайте агенту лише мету, handoff та файли, потрібні для наступної дії. Не вставляйте повний transcript: він містить корисні докази, але також шум, який модель помилково сприймає за актуальну вимогу.

Чотири робочі схеми для OpenClaw

1. Vault як зовнішня памʼять, а не архів чатів

Розділіть у vault три типи записів: brief для незмінних вимог, handoff для поточного стану і decision для рішень, які переживуть одну задачу. У кожному handoff зберігайте phase, next_action, checks_to_run та updated_at. Новий запуск читає тільки brief + останній handoff; рішення підтягуються лише за посиланням.

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

2. Telegram як маршрутизатор сесій

Telegram-боту не потрібно тягнути весь діалог у кожен запуск. Нехай router створює роботу, worker отримує handoff, а verifier працює у новій сесії з read-only набором інструментів:

telegram_router:
  receives: [request, approval, status]
  sends: [job_id, short_receipt]

worker:
  session_policy: "one_phase_per_session"
  reads: [brief, latest_handoff]
  writes: [artifact, handoff]

verifier:
  session_policy: "fresh_session"
  reads: [artifact, acceptance_checks, sources]
  writes: [verification_report]

Router передає далі job_id і посилання на handoff, а не весь текст Telegram. Якщо робота переривається, її можна продовжити без відновлення випадкового стану чату. Ціна — більше явних записів і окрема маршрутизація; виграш — менший контекст і зрозумілий blast radius.

3. Agent для фази, skill для процедури

Не створюйте окремого агента для кожної дрібної інструкції. Агент — це межа контексту, роль і доступні інструменти. Skill — повторювана процедура всередині цієї ролі. Наприклад, researcher готує brief, writer створює статтю, а skill source-check однаково перевіряє URL для будь-якої з них.

У конфігурації зафіксуйте правило переходу: worker не викликає verifier у тій самій сесії. Він завершує handoff, після чого router запускає verifier з нуля. Така схема трохи повільніша, зате результат не перевіряється тією самою історією, яка його створила.

4. Нестандартний шаблон: «оренда» контексту

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

session_lease:
  max_phase_steps: 8
  max_repair_cycles: 2
  required_handoff_fields: [phase, decisions, next_action, checks_to_run]
  on_expiry: "write_handoff_then_stop"

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

Операційний playbook

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

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

Посилання перевірено 4 жовтня 2026 року: Claude sessions, Codex Hooks, OpenCode plugins, OpenCode config і OpenClaw Codex harness.