English简体中文繁體中文日本語EspañolPortuguês (BR)한국어DeutschFrançaisالعربيةItalianoTiếng ViệtNederlandsTürkçeУкраїнськаBahasa IndonesiaPolskiفارسیไทย

Automation

Постійні вказівки

Edit source

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

Це різниця між тим, щоб щоп’ятниці казати своєму асистенту «надішли щотижневий звіт», і наданням постійного повноваження: «Ти відповідаєш за щотижневий звіт. Готуй його щоп’ятниці, надсилай і ескалюй лише тоді, коли щось виглядає неправильно».

Навіщо потрібні постійні доручення

Без постійних доручень:

  • Ви маєте давати агенту запит для кожного завдання
  • Агент простоює між запитами
  • Рутинна робота забувається або затримується
  • Ви стаєте вузьким місцем

З постійними дорученнями:

  • Агент виконує роботу автономно в межах визначених правил
  • Рутинна робота виконується за розкладом без запитів
  • Ви залучаєтеся лише для винятків і затверджень
  • Агент продуктивно заповнює час простою

Як вони працюють

Постійні доручення визначаються у файлах вашого робочого простору агента. Рекомендований підхід - включати їх безпосередньо в AGENTS.md (який автоматично додається до кожної сесії), щоб агент завжди мав їх у контексті. Для більших конфігурацій ви також можете розмістити їх в окремому файлі, наприклад standing-orders.md, і посилатися на нього з AGENTS.md.

Кожна програма визначає:

  1. Область дії - що агент уповноважений робити
  2. Тригери - коли виконувати (розклад, подія або умова)
  3. Шлюзи затвердження - що потребує підтвердження людини перед дією
  4. Правила ескалації - коли зупинитися й попросити допомоги

Агент завантажує ці інструкції в кожній сесії через bootstrap-файли робочого простору (повний список автоматично доданих файлів див. у робочому просторі агента) і виконує їх у поєднанні з завданнями Cron для часової примусової перевірки.

Анатомія постійного доручення

markdown
## Program: Weekly Status Report **Authority:** Compile data, generate report, deliver to stakeholders**Trigger:** Every Friday at 4 PM (enforced via cron job)**Approval gate:** None for standard reports. Flag anomalies for human review.**Escalation:** If data source is unavailable or metrics look unusual (>2σ from norm) ### Execution steps 1. Pull metrics from configured sources2. Compare to prior week and targets3. Generate report in Reports/weekly/YYYY-MM-DD.md4. Deliver summary via configured channel5. Log completion to Agent/Logs/ ### What NOT to do - Do not send reports to external parties- Do not modify source data- Do not skip delivery if metrics look bad - report accurately

Постійні доручення плюс завдання Cron

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

Code
Standing Order: "You own the daily inbox triage"    ↓Cron Job (8 AM daily): "Execute inbox triage per standing orders"    ↓Agent: Reads standing orders → executes steps → reports results

Підказка завдання 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 "Execute daily inbox triage per standing orders. Check mail for new alerts. Parse, categorize, and persist each item. Report summary to owner. Escalate unknowns."

Приклади

Приклад 1: контент і соціальні мережі (щотижневий цикл)

markdown
## Program: Content & Social Media **Authority:** Draft content, schedule posts, compile engagement reports**Approval gate:** All posts require owner review for first 30 days, then standing approval**Trigger:** Weekly cycle (Monday review → mid-week drafts → Friday brief) ### Weekly cycle - **Monday:** Review platform metrics and audience engagement- **Tuesday-Thursday:** Draft social posts, create blog content- **Friday:** Compile weekly marketing brief → deliver to owner ### Content rules - Voice must match the brand (see SOUL.md or brand voice guide)- Never identify as AI in public-facing content- Include metrics when available- Focus on value to audience, not self-promotion

Приклад 2: фінансові операції (запускаються подією)

markdown
## Program: Financial Processing **Authority:** Process transaction data, generate reports, send summaries**Approval gate:** None for analysis. Recommendations require owner approval.**Trigger:** New data file detected OR scheduled monthly cycle ### When new data arrives 1. Detect new file in designated input directory2. Parse and categorize all transactions3. Compare against budget targets4. Flag: unusual items, threshold breaches, new recurring charges5. Generate report in designated output directory6. Deliver summary to owner via configured channel ### Escalation rules - Single item > $500: immediate alert- Category > budget by 20%: flag in report- Unrecognizable transaction: ask owner for categorization- Failed processing after 2 retries: report failure, do not guess

Приклад 3: моніторинг і сповіщення (безперервно)

markdown
## Program: System Monitoring **Authority:** Check system health, restart services, send alerts**Approval gate:** Restart services automatically. Escalate if restart fails twice.**Trigger:** Every heartbeat cycle ### Checks - Service health endpoints responding- Disk space above threshold- Pending tasks not stale (>24 hours)- Delivery channels operational ### Response matrix | Condition        | Action                   | Escalate?                || ---------------- | ------------------------ | ------------------------ || Service down     | Restart automatically    | Only if restart fails 2x || Disk space < 10% | Alert owner              | Yes                      || Stale task > 24h | Remind owner             | No                       || Channel offline  | Log and retry next cycle | If offline > 2 hours     |

Шаблон «виконати-перевірити-звітувати»

Постійні доручення працюють найкраще, коли поєднані зі строгою дисципліною виконання. Кожне завдання в постійному дорученні має дотримуватися цього циклу:

  1. Виконати - Зробити фактичну роботу (а не просто підтвердити інструкцію)
  2. Перевірити - Підтвердити, що результат правильний (файл існує, повідомлення доставлено, дані розібрано)
  3. Звітувати - Повідомити власнику, що було зроблено і що було перевірено
markdown
### Execution rules - Every task follows Execute-Verify-Report. No exceptions.- "I'll do that" is not execution. Do it, then report.- "Done" without verification is not acceptable. Prove it.- If execution fails: retry once with adjusted approach.- If still fails: report failure with diagnosis. Never silently fail.- Never retry indefinitely - 3 attempts max, then escalate.

Цей шаблон запобігає найпоширенішому режиму відмови агента: підтвердженню завдання без його завершення.

Архітектура з кількома програмами

Для агентів, які керують кількома напрямами, організуйте постійні доручення як окремі програми з чіткими межами:

markdown
## Program 1: [Domain A] (Weekly) ... ## Program 2: [Domain B] (Monthly + On-Demand) ... ## Program 3: [Domain C] (As-Needed) ... ## Escalation Rules (All Programs) - [Common escalation criteria]- [Approval gates that apply across programs]

Кожна програма повинна мати:

  • Власну каденцію тригерів (щотижнева, щомісячна, подієво-керована, безперервна)
  • Власні шлюзи затвердження (деякі програми потребують більшого нагляду, ніж інші)
  • Чіткі межі (агент має знати, де закінчується одна програма й починається інша)

Найкращі практики

Рекомендовано

  • Починайте з вузьких повноважень і розширюйте їх зі зростанням довіри
  • Визначайте явні шлюзи затвердження для високоризикових дій
  • Додавайте розділи «Чого НЕ робити» - межі так само важливі, як і дозволи
  • Поєднуйте із завданнями Cron для надійного часового виконання
  • Щотижня переглядайте журнали агента, щоб перевіряти, що постійні доручення виконуються
  • Оновлюйте постійні доручення зі зміною ваших потреб - це живі документи

Уникайте

  • Надавати широкі повноваження в перший день («роби все, що вважаєш найкращим»)
  • Пропускати правила ескалації - кожній програмі потрібен пункт «коли зупинитися й запитати»
  • Припускати, що агент запам’ятає усні інструкції - внесіть усе у файл
  • Змішувати напрями в одній програмі - окремі програми для окремих доменів
  • Забувати примусове виконання через завдання Cron - постійні доручення без тригерів стають рекомендаціями

Пов’язане

  • Автоматизація: усі механізми автоматизації в одному огляді.
  • Завдання Cron: примусове виконання за розкладом для постійних доручень.
  • Hooks: подієво-керовані сценарії для подій життєвого циклу агента.
  • Webhooks: вхідні тригери HTTP-подій.
  • Робочий простір агента: де зберігаються постійні доручення, включно з повним списком автоматично доданих bootstrap-файлів (AGENTS.md, SOUL.md тощо).
Was this useful?