На этой странице
На этой странице
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и т. д.).