Постійні доручення надають вашому агенту постійні повноваження на виконання визначених програм. Замість того щоб давати агенту вказівку для кожного завдання, ви визначаєте програми з чіткою сферою дії, тригерами та правилами ескалації, а агент автономно виконує їх у цих межах: «Ви відповідаєте за щотижневий звіт. Готуйте його щоп’ятниці, надсилайте й ескалюйте лише тоді, коли щось виглядає неправильно».
Навіщо потрібні постійні доручення
Без постійних доручень: ви даєте агенту вказівку для кожного завдання, про рутинну роботу забувають або її виконання затримується, а ви стаєте вузьким місцем.
З постійними дорученнями: агент автономно працює у визначених межах, рутинна робота виконується за розкладом, а ви долучаєтеся лише у виняткових випадках і для надання схвалень.
Як вони працюють
Постійні доручення визначаються у файлах вашого робочого простору агента. Рекомендовано додавати їх безпосередньо до AGENTS.md (який автоматично додається до контексту кожного сеансу), щоб агент завжди мав їх у контексті. Для більших конфігурацій їх також можна розмістити в окремому файлі, наприклад standing-orders.md, і послатися на нього з AGENTS.md.
Кожна програма визначає:
Сферу дії — що агент уповноважений робити
Тригери — коли виконувати програму (за розкладом, подією або умовою)
Етапи схвалення — що потребує схвалення людиною перед виконанням
Правила ескалації — коли слід зупинитися й попросити допомоги
Агент завантажує ці інструкції в кожному сеансі через початкові файли робочого простору (повний список автоматично доданих файлів див. у розділі Робочий простір агента) і виконує їх разом із завданнями Cron, які забезпечують виконання за часом.
Структура постійного доручення
markdown
## Програма: Щотижневий звіт про стан**Повноваження:** Зібрати дані, сформувати звіт, доставити його зацікавленим сторонам**Тригер:** Щоп’ятниці о 16:00 (забезпечується завданням Cron)**Етап схвалення:** Для стандартних звітів не потрібен. Позначати аномалії для перевірки людиною.**Ескалація:** Якщо джерело даних недоступне або показники виглядають незвично (>2σ від норми)### Етапи виконання1. Отримати показники з налаштованих джерел2. Порівняти з попереднім тижнем і цільовими значеннями3. Створити звіт у Reports/weekly/YYYY-MM-DD.md4. Доставити підсумок через налаштований канал5. Записати відомості про завершення до Agent/Logs/### Чого НЕ робити- Не надсилати звіти зовнішнім сторонам- Не змінювати вихідні дані- Не пропускати доставлення, якщо показники виглядають погано, — звітувати точно
Постійні доручення та завдання Cron
Постійні доручення визначають, що агент уповноважений робити. Завдання Cron визначають, коли це відбувається. Вони працюють разом:
text
Постійне доручення: «Ви відповідаєте за щоденне сортування вхідних повідомлень» ↓Завдання Cron (щодня о 8:00): «Виконайте сортування вхідних повідомлень відповідно до постійних доручень» ↓Агент: Читає постійні доручення → виконує етапи → повідомляє результати
Запит завдання Cron має посилатися на постійне доручення, а не дублювати його:
bash
openclaw cron add \ --name daily-inbox-triage \ --cron "0 8 * * 1-5" \ --tz America/New_York \ --timeout-seconds 300 \ --announce \ --channel imessage \ --to "+1XXXXXXXXXX" \ --message "Виконайте щоденне сортування вхідних повідомлень відповідно до постійних доручень. Перевірте пошту на наявність нових сповіщень. Проаналізуйте, класифікуйте та збережіть кожен елемент. Повідомте власнику підсумок. Ескалюйте невідомі випадки."
Приклади
Приклад 1: вміст і соціальні мережі (щотижневий цикл)
markdown
## Програма: Вміст і соціальні мережі**Повноваження:** Готувати чернетки матеріалів, планувати публікації, складати звіти про залученість**Етап схвалення:** Протягом перших 30 днів усі публікації потребують перевірки власником, після цього діє постійне схвалення**Тригер:** Щотижневий цикл (перевірка в понеділок → чернетки в середині тижня → зведення в п’ятницю)### Щотижневий цикл-**Понеділок:** Перевірити показники платформ і залученість аудиторії-**Вівторок–четвер:** Підготувати чернетки дописів у соціальних мережах і створити матеріал для блогу-**П’ятниця:** Скласти щотижневе маркетингове зведення → доставити власнику### Правила щодо вмісту- Стиль має відповідати бренду (див. SOUL.md або настанови щодо стилю бренду)- Ніколи не представлятися ШІ в загальнодоступних матеріалах- Додавати показники, коли вони доступні- Зосереджуватися на цінності для аудиторії, а не на саморекламі
Приклад 2: фінансові операції (за подією)
markdown
## Програма: Обробка фінансових даних**Повноваження:** Обробляти дані транзакцій, формувати звіти, надсилати підсумки**Етап схвалення:** Для аналізу не потрібен. Рекомендації потребують схвалення власника.**Тригер:** Виявлено новий файл даних АБО настав запланований щомісячний цикл### Коли надходять нові дані1. Виявити новий файл у визначеному вхідному каталозі2. Проаналізувати й класифікувати всі транзакції3. Порівняти з цільовими показниками бюджету4. Позначити незвичні елементи, перевищення порогових значень і нові регулярні платежі5. Створити звіт у визначеному вихідному каталозі6. Доставити підсумок власнику через налаштований канал### Правила ескалації- Один елемент > $500: негайне сповіщення- Категорія перевищує бюджет на 20%: позначити у звіті- Нерозпізнана транзакція: попросити власника визначити категорію- Обробка не вдалася після 2 повторних спроб: повідомити про помилку, не робити припущень
Приклад 3: моніторинг і сповіщення (безперервно)
markdown
## Програма: Моніторинг системи**Повноваження:** Перевіряти стан системи, перезапускати служби, надсилати сповіщення**Етап схвалення:** Перезапускати служби автоматично. Ескалювати, якщо дві спроби перезапуску завершилися невдало.**Тригер:** Кожен цикл Heartbeat### Перевірки- Кінцеві точки стану служб відповідають- Обсяг вільного місця на диску перевищує порогове значення- Завдання, що очікують виконання, не є застарілими (>24 годин)- Канали доставлення працездатні### Матриця реагування| Умова | Дія | Ескалювати? || ----------------------- | ---------------------------------------- | ------------------------------------- || Служба не працює | Перезапустити автоматично | Лише якщо 2 перезапуски не вдалися || Вільне місце < 10% | Сповістити власника | Так || Завдання застаріло > 24 год | Нагадати власнику | Ні || Канал не працює | Записати в журнал і повторити в наступному циклі | Якщо не працює > 2 годин |
Шаблон «виконати — перевірити — повідомити»
Постійні доручення найкраще працюють у поєднанні із суворою дисципліною виконання. Кожне завдання в постійному дорученні має виконуватися за таким циклом:
Виконати — виконати фактичну роботу (а не просто підтвердити інструкцію)
Перевірити — підтвердити правильність результату (файл існує, повідомлення доставлено, дані проаналізовано)
Повідомити — розповісти власнику, що було зроблено і що було перевірено
markdown
### Правила виконання- Кожне завдання виконується за схемою «Виконати — перевірити — повідомити». Без винятків.- «Я це зроблю» не є виконанням. Виконайте, а потім повідомте.- «Готово» без перевірки неприйнятне. Надайте докази.- Якщо виконання не вдалося: повторіть спробу один раз, скоригувавши підхід.- Якщо знову не вдалося: повідомте про помилку з результатами діагностики. Ніколи не приховуйте помилку.- Ніколи не повторюйте спроби нескінченно — щонайбільше 3 спроби, потім ескалуйте.
Цей шаблон запобігає найпоширенішому режиму відмови агента: підтвердженню завдання без його завершення.
Архітектура з кількома програмами
Для агентів, що керують кількома напрямами, упорядковуйте постійні доручення як окремі програми з чіткими межами:
markdown
## Програма 1: [Напрям A] (Щотижня)...## Програма 2: [Напрям B] (Щомісяця + на вимогу)...## Програма 3: [Напрям C] (За потреби)...## Правила ескалації (усі програми)- [Спільні критерії ескалації]- [Етапи схвалення, що застосовуються до всіх програм]
Кожна програма повинна мати:
Власну періодичність тригерів (щотижневу, щомісячну, за подіями або безперервну)
Власні етапи схвалення (деякі програми потребують ретельнішого нагляду, ніж інші)
Чіткі межі (агент повинен знати, де закінчується одна програма й починається інша)
Рекомендації
Варто робити
Починайте з вузьких повноважень і розширюйте їх зі зростанням довіри
Визначте явні етапи схвалення для дій із високим ризиком
Додавайте розділи «Чого НЕ робити» — межі не менш важливі, ніж дозволи
Поєднуйте із завданнями Cron для надійного виконання за часом
Щотижня переглядайте журнали агента, щоб переконатися, що постійні доручення виконуються
Оновлюйте постійні доручення зі зміною ваших потреб — це живі документи
Слід уникати
Надання широких повноважень у перший день («робіть усе, що вважаєте найкращим»)
Пропуску правил ескалації — кожна програма потребує умови «коли зупинитися й запитати»
Припущення, що агент пам’ятатиме усні інструкції, — запишіть усе у файл
Змішування напрямів в одній програмі — створюйте окремі програми для окремих напрямів
Відсутності забезпечення виконання за допомогою завдань Cron — постійні доручення без тригерів стають лише рекомендаціями
