Skills чи агенти: де зберігати повторювану роботу OpenClaw

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

• постійне правило живе в інструкціях проєкту;
• повторюваний процес — у skill;
• ізольована робота з власним контекстом, інструментами або правами — в agent.

Це не лише питання зручності. Неправильна межа збільшує контекст, витрати токенів і blast radius помилки.

Що означають ці межі у Claude, Codex та OpenCode

У Claude Code файл CLAUDE.md призначений для фактів, стандартів і команд, які потрібні в кожній сесії. Процедуру, що стала довшою за коротке правило, документація радить переносити в skill: його тіло завантажується лише під час використання. Skills у Claude Code додають повторне використання, ресурси та автоматичний виклик. Для жорстких обмежень цього недостатньо: hooks Claude Code можуть блокувати tool call на етапі PreToolUse.

Subagent у Claude — інша абстракція: окреме контекстне вікно, власний system prompt і обмежений набір інструментів. Він корисний, коли пошук, логи чи масив сирих даних лише засмічать головну розмову. Це не безкоштовне розгалуження: робота subagent рахується в тих самих лімітах використання. Офіційний опис subagents Claude Code.

У Codex skill — це упакований повторюваний workflow з інструкціями та ресурсами, а plugin може додати до нього MCP-сервери й інші інструменти. Документація OpenAI про skills і plugins. Subagent workflow призначений для незалежних частин роботи: дослідження, тестів, тріажу. OpenAI окремо застерігає, що паралельні агенти споживають більше токенів, а паралельні зміни файлів збільшують ризик конфліктів. Документація OpenAI про subagents.

OpenCode має дуже схожу, але явно конфігуровану модель. Skill — це SKILL.md, який агент завантажує через skill tool лише за потреби. Agent має режим, prompt, модель і permissions; primary веде діалог, subagent виконує спеціалізовану підзадачу. Для меж доступу OpenCode дозволяє allow, deny або ask на рівні tool, включно з skill і MCP; це описано в документації про permissions OpenCode та довіднику tools.

Отже, назви трохи різняться, але практичне правило спільне:

Робоча схема для OpenClaw

1. Тримайте довгоживуче знання у vault, а не в agent prompt

У vault зручно розділити decisions/, patterns/, runbooks/ і sessions/. Agent отримує лише сторінки, потрібні для конкретної задачі, а наприкінці записує короткий результат у відповідний runbook або decision. Так наступний запуск не мусить отримувати всю історію Telegram.

Для кожної сторінки корисно мати однаковий мінімум:

---
description: Як перевіряти щоденні AI-публікації
status: active
owner: devsecops
---

## Контекст
...

## Перевірки
1. ...

## Ознака завершення
...

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

2. Перетворіть повторювану процедуру на skill-контракт

Skill повинен описувати не «будь розумним», а вхід, кроки, заборони і формат виходу. Наприклад, skill для дослідження джерел може бути таким:

---
name: source-check
description: Перевірити офіційні джерела, дати й працездатність URL перед публікацією
---

## Вхід
- тема;
- дата публікації;
- список уже використаних URL.

## Процес
1. Знайди первинні джерела.
2. Відкрий кожен URL і відкинь сторінки з помилкою.
3. Перевір, що джерело справді підтверджує твердження.
4. Не повторюй URL або тему без нового кута.

## Вихід
Поверни JSON з полями `claim`, `source`, `checked_at`, `evidence`.
Якщо джерела не підтверджують твердження, поверни `status: blocked`.

У OpenClaw це дає спільний контракт для ручного запуску, cron і Telegram-команди. Skill не повинен сам отримувати широкі права лише тому, що йому потрібен один API: доступ до сервісу краще залишити окремому tool або plugin.

3. Виділяйте agent тоді, коли потрібна межа виконання

Створюйте agent, якщо хоча б одна з умов правдива:

• підзадача дає багато шуму: логи, web-пошук, сканування репозиторію;
• її можна виконати паралельно з іншими;
• їй потрібна інша модель або інший рівень reasoning;
• їй потрібні окремі дозволи — наприклад, read-only або approval перед записом;
• помилку треба локалізувати, не заражаючи головний діалог.

Для OpenClaw це може бути researcher без write-інструментів і publisher з доступом лише до каталогу публікацій. Перший повертає докази та невизначеності, другий формує файл тільки після перевірки контракту. Один універсальний agent із доступом до vault, shell, Telegram і production API — погана оптимізація: він зручний на старті, але має надто великий blast radius.

4. Розділіть Telegram на маршрутизатор і виконавців

Практична топологія для одного бота:

telegram:
  router:
    receives: ["/research", "/draft", "/publish", "free_text"]
    writes: false
  workers:
    research:
      skills: [source-check]
      tools: [web_search, web_fetch, vault_read]
      writes: ["vault/research/**"]
    draft:
      skills: [article-draft]
      tools: [vault_read, vault_write]
      writes: ["blog/content/ai/**"]
    publish:
      skills: [publish-gate]
      tools: [validator, build, git_commit]
      approval: required

Це псевдоконфігурація, а не готовий файл OpenClaw. Її сенс — зафіксувати потік: router класифікує запит, research повертає докази, draft готує артефакт, publish має окремий approval. У приватному чаті можна дозволити детальні логи, а в групу повертати лише короткий результат і посилання на vault.

Нестандартний варіант: skill як контракт, агент як одноразовий worker

Для нестабільних або дорогих задач можна не робити постійного «дослідницького агента». Замість цього router щоразу запускає одноразовий read-only worker з одним skill-контрактом:

1. worker читає тему, список дублікатів і потрібний формат;
2. виконує пошук та перевірку URL у власному контексті;
3. записує evidence bundle у vault;
4. повертає router лише ідентифікатор bundle і коротке резюме;
5. окремий draft agent читає bundle та створює текст.

Перевага — чистий головний контекст, короткі журнали й простіша форензика: видно, який worker створив які докази. Недоліки — додатковий запуск, більше токенів на orchestration і затримка між кроками. Для короткої відповіді це надмірність; для щоденного research-to-publish контуру з web-пошуком, vault і Git це розумний компроміс.

Короткий operating playbook

1. Якщо правило потрібне майже в кожній сесії — поклади його в інструкції проєкту.
2. Якщо одна й та сама процедура повторилася двічі — зроби з неї skill із чітким виходом.
3. Якщо робота шумна, паралельна або має інші права — винеси її в agent.
4. Якщо agent пише або викликає зовнішній сервіс — дай мінімальні permissions і окрему перевірку результату.
5. Раз на місяць видаляй невикористані skills, стискай інструкції та перевіряй, що назви й описи справді допомагають маршрутизації.

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