Automation
Постоянные распоряжения
Постоянные поручения предоставляют вашему агенту постоянные полномочия на выполнение определённых программ. Вместо того чтобы давать агенту указание для каждой задачи, вы определяете программы с чёткой областью действия, триггерами и правилами эскалации, а агент автономно выполняет их в заданных границах: «Ты отвечаешь за еженедельный отчёт. Составляй его каждую пятницу, отправляй и эскалируй только в случае, если что-то выглядит неправильно».
Зачем нужны постоянные поручения
Без постоянных поручений: вы даёте агенту указание для каждой задачи, рутинная работа забывается или откладывается, а вы становитесь узким местом.
С постоянными поручениями: агент автономно действует в заданных границах, рутинная работа выполняется по расписанию, а вы подключаетесь только в исключительных случаях и для утверждений.
Как они работают
Постоянные поручения определяются в файлах рабочего пространства агента. Рекомендуется включать их непосредственно в AGENTS.md (этот файл автоматически внедряется в каждый сеанс), чтобы они всегда находились в контексте агента. Для более крупных конфигураций их также можно поместить в отдельный файл, например standing-orders.md, и сослаться на него из AGENTS.md.
В каждой программе указываются:
- Область полномочий — что агенту разрешено делать
- Триггеры — когда выполнять программу (по расписанию, событию или условию)
- Этапы утверждения — для каких действий требуется предварительное одобрение человеком
- Правила эскалации — когда следует остановиться и обратиться за помощью
Агент загружает эти инструкции в каждом сеансе через загрузочные файлы рабочего пространства (полный список автоматически внедряемых файлов см. в разделе Рабочее пространство агента) и выполняет их, используя задания Cron для запуска по времени.
Структура постоянного поручения
## Программа: еженедельный отчёт о состоянии **Полномочия:** собирать данные, формировать отчёт, доставлять его заинтересованным сторонам**Триггер:** каждую пятницу в 16:00 (запуск обеспечивается заданием Cron)**Этап утверждения:** для стандартных отчётов отсутствует. Отмечать аномалии для проверки человеком.**Эскалация:** если источник данных недоступен или показатели выглядят необычно (>2σ от нормы) ### Этапы выполнения 1. Получить показатели из настроенных источников2. Сравнить их с предыдущей неделей и целевыми значениями3. Создать отчёт в Reports/weekly/YYYY-MM-DD.md4. Доставить сводку через настроенный канал5. Записать сведения о завершении в Agent/Logs/ ### Чего НЕ следует делать - Не отправлять отчёты внешним сторонам- Не изменять исходные данные- Не пропускать доставку, если показатели выглядят плохо, — сообщать о них точноПостоянные поручения и задания Cron
Постоянные поручения определяют, что агенту разрешено делать. Задания Cron определяют, когда это происходит. Они работают совместно:
Постоянное поручение: «Ты отвечаешь за ежедневную сортировку входящих сообщений» ↓Задание Cron (ежедневно в 8:00): «Выполни сортировку входящих сообщений согласно постоянным поручениям» ↓Агент: читает постоянные поручения → выполняет этапы → сообщает результатыВ запросе задания Cron следует ссылаться на постоянное поручение, а не дублировать его:
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: контент и социальные сети (еженедельный цикл)
## Программа: контент и социальные сети **Полномочия:** готовить черновики материалов, планировать публикации, составлять отчёты о вовлечённости**Этап утверждения:** в течение первых 30 дней все публикации требуют проверки владельцем, после чего действует постоянное разрешение**Триггер:** еженедельный цикл (проверка в понедельник → черновики в середине недели → сводка в пятницу) ### Еженедельный цикл - **Понедельник:** проверить показатели платформ и вовлечённость аудитории- **Вторник–четверг:** подготовить черновики публикаций для социальных сетей и материалы для блога- **Пятница:** составить еженедельную маркетинговую сводку → доставить владельцу ### Правила работы с контентом - Стиль должен соответствовать бренду (см. SOUL.md или руководство по стилю бренда)- Никогда не представляться как ИИ в общедоступных материалах- Включать показатели, когда они доступны- Сосредоточиться на пользе для аудитории, а не на саморекламеПример 2: финансовые операции (запуск по событию)
## Программа: обработка финансовых данных **Полномочия:** обрабатывать данные транзакций, формировать отчёты, отправлять сводки**Этап утверждения:** для анализа отсутствует. Рекомендации требуют одобрения владельца.**Триггер:** обнаружен новый файл данных ИЛИ наступил запланированный ежемесячный цикл ### При поступлении новых данных 1. Обнаружить новый файл в назначенном входном каталоге2. Разобрать и классифицировать все транзакции3. Сравнить их с целевыми значениями бюджета4. Отметить необычные позиции, превышения пороговых значений и новые регулярные списания5. Создать отчёт в назначенном выходном каталоге6. Доставить сводку владельцу через настроенный канал ### Правила эскалации - Отдельная позиция > $500: немедленное оповещение- Категория превышает бюджет на 20%: отметить в отчёте- Нераспознанная транзакция: запросить у владельца категорию- Ошибка обработки после 2 повторных попыток: сообщить об ошибке, не делать предположенийПример 3: мониторинг и оповещения (непрерывно)
## Программа: мониторинг системы **Полномочия:** проверять состояние системы, перезапускать службы, отправлять оповещения**Этап утверждения:** перезапускать службы автоматически. Эскалировать, если перезапуск дважды завершился неудачей.**Триггер:** каждый цикл Heartbeat ### Проверки - Конечные точки проверки состояния служб отвечают- Свободное место на диске выше порогового значения- Ожидающие задачи не устарели (>24 часов)- Каналы доставки работают ### Матрица реагирования | Условие | Действие | Эскалировать? || ----------------------- | ----------------------------------------- | --------------------------------- || Служба недоступна | Перезапустить автоматически | Только если 2 перезапуска неудачны || Свободное место < 10% | Оповестить владельца | Да || Задача устарела > 24 ч | Напомнить владельцу | Нет || Канал недоступен | Записать в журнал и повторить в следующем цикле | Если недоступен > 2 часов |Схема «выполнить — проверить — сообщить»
Постоянные поручения работают лучше всего в сочетании со строгой дисциплиной выполнения. Каждая задача в постоянном поручении должна проходить следующий цикл:
- Выполнить — сделать фактическую работу (а не просто подтвердить получение инструкции)
- Проверить — убедиться, что результат верен (файл существует, сообщение доставлено, данные разобраны)
- Сообщить — рассказать владельцу, что было сделано и что было проверено
### Правила выполнения - Каждая задача следует схеме «Выполнить — проверить — сообщить». Без исключений.- «Я это сделаю» не является выполнением. Сначала сделайте, затем сообщите.- «Готово» без проверки неприемлемо. Предоставьте доказательства.- Если выполнение завершилось неудачей: повторите попытку один раз, скорректировав подход.- Если повторная попытка также неудачна: сообщите об ошибке и её причине. Никогда не скрывайте ошибку.- Никогда не повторяйте попытки бесконечно — не более 3 попыток, затем эскалация.Эта схема предотвращает наиболее распространённый сбой в работе агента: подтверждение задачи без её выполнения.
Архитектура с несколькими программами
Для агентов, управляющих несколькими направлениями, организуйте постоянные поручения как отдельные программы с чёткими границами:
## Программа 1: [Область A] (еженедельно) ... ## Программа 2: [Область B] (ежемесячно + по запросу) ... ## Программа 3: [Область C] (по мере необходимости) ... ## Правила эскалации (все программы) - [Общие критерии эскалации]- [Этапы утверждения, применимые ко всем программам]У каждой программы должны быть:
- Собственная периодичность триггеров (еженедельно, ежемесячно, по событию, непрерывно)
- Собственные этапы утверждения (некоторые программы требуют более строгого контроля, чем другие)
- Чёткие границы (агент должен понимать, где заканчивается одна программа и начинается другая)
Рекомендации
Следует
- Начинать с узких полномочий и расширять их по мере укрепления доверия
- Определять явные этапы утверждения для действий с высоким риском
- Включать разделы «Чего НЕ следует делать» — границы так же важны, как и разрешения
- Сочетать постоянные поручения с заданиями Cron для надёжного выполнения по времени
- Еженедельно проверять журналы агента, чтобы убедиться в соблюдении постоянных поручений
- Обновлять постоянные поручения по мере изменения потребностей — это живые документы
Не следует
- Предоставлять широкие полномочия в первый же день («делай всё, что считаешь лучшим»)
- Пропускать правила эскалации — каждой программе требуется условие, определяющее, когда следует остановиться и обратиться за помощью
- Предполагать, что агент запомнит устные инструкции, — записывайте всё в файл
- Смешивать направления в одной программе — используйте отдельные программы для отдельных областей
- Забывать обеспечивать запуск с помощью заданий Cron — постоянные поручения без триггеров превращаются в рекомендации
См. также
- Автоматизация: краткий обзор всех механизмов автоматизации.
- Задания Cron: запуск постоянных поручений по расписанию.
- Перехватчики: сценарии, запускаемые событиями жизненного цикла агента.
- Веб-перехватчики: триггеры входящих событий HTTP.
- Рабочее пространство агента: место хранения постоянных поручений, включая полный список автоматически внедряемых загрузочных файлов (
AGENTS.md,SOUL.mdи т. д.).