Кастомные моды и планировщик: как AI-агент работает по расписанию без участия человека

AI-агенты для кодинга перешли из разряда «автодополнение» в разряд «автономные работники». Но у большинства инструментов агент живёт только пока открыт чат. Закроешь IDE — и он исчезает. Мы в THINKING•OS AI Lab сделали иначе: в платформе Tao·Coder агент умеет работать по расписанию, переключаться между модами и выстраивать цепочки задач — от мониторинга сервера до публикации аналитических отчётов — полностью автономно.

Проблема: агент, который живёт только в чате

Большинство AI-агентов для разработки (Cursor, Copilot, Claude Code в базовом режиме) работают в синхронном режиме: ты пишешь промпт → агент отвечает → ты закрываешь чат. Это удобно для разовых задач, но не работает для системных.

Примеры задач, которые требуют автономности:

Ежечасная проверка состояния продакшен-сервера
Ежедневный аудит качества кода в репозитории
Еженедельный сбор новостей отрасли и подготовка дайджеста
Регулярная публикация статей в блоге и социальных сетях
Автоматическое устранение найденных проблем

Для таких задач нужен агент, который:

Работает по расписанию (cron)
Переключается между специализированными модами
Выстраивает цепочки задач (handoff)
Работает автономно, без участия человека

TAO·MODES: декларативная конфигурация внутри Tao·Coder

TAO·MODES — это механизм кастомных модов платформы Tao·Coder. Границы, инструменты, стадии и критерии выхода описаны в JSON-файлах. Агент не «угадывает», что делать — он следует формальной спецификации.

Ключевой принцип: каждый мод — это специализированный агент с чёткими границами. Мод определяет, какие инструменты доступны, какие стадии нужно пройти, и при каких условиях переходить к следующему этапу.

Структура кастомного мода

Каждый мод — это директория с конфигурационными файлами:

.taocoder/modes/<mode_id>/
├── mode.json              # Конфигурация мода
└── stages/
    └── <stage_id>.json    # Конфигурация стадии

mode.json определяет:

id — уникальный идентификатор мода
name — название для интерфейса
description — описание для пользователя
system_prompt — системный промпт агента
stages[] — список стадий (конвейер)
extends — наследование от другого мода

stage.json определяет:

id — идентификатор стадии
stage_prompt — промпт для этой стадии
allowed_tools[] — какие инструменты доступны
forbidden_tools[] — какие инструменты заблокированы
default_exit_criteria[] — критерии перехода на следующую стадию
hooks[] — хуки для бизнес-логики

Пример: мод для мониторинга сервера

{
  "id": "server_monitor",
  "name": "Server Monitor",
  "description": "Ежечасовая проверка состояния продакшен-сервера",
  "system_prompt": "Ты — ops-агент. Проверяй состояние сервера и логируй проблемы.",
  "stages": [
    {
      "id": "check_health",
      "stage_prompt": "Проверь CPU, RAM, disk usage. Если что-то выше 80% — создай таск.",
      "allowed_tools": ["execute_command", "read_file", "write_to_file"],
      "default_exit_criteria": [
        {
          "checkType": "all_metrics_below_threshold",
          "threshold": 80
        }
      ]
    }
  ]
}

Агент в этом моде:

Имеет доступ только к execute_command, read_file, write_to_file
Не может писать код или менять конфигурацию (нет apply_patch)
Не может общаться с пользователем (нет ask_followup_question)
Работает автономно, если запущен по расписанию

Не только для кода: моды для любых задач

TAO·MODES — это не только про программирование. Декларативная конфигурация модов подходит для любых задач, где нужна специализация и автономность. Мы сами используем моды для контент-работы и аналитики.

Пример: мод для написания статей в блог

{
  "id": "blog_writer",
  "name": "Blog Writer",
  "description": "Написание и публикация статей для блога",
  "system_prompt": "Ты — контент-райтер. Пиши статьи по спецификации, соблюдай стиль компании.",
  "stages": [
    {
      "id": "research",
      "stage_prompt": "Собери информацию по теме через web search. Найди факты, цифры, примеры.",
      "allowed_tools": ["web_search", "read_file", "write_to_file"],
      "forbidden_tools": ["apply_patch", "execute_command"]
    },
    {
      "id": "writing",
      "stage_prompt": "Напиши статью на русском и английском. Следуй шаблону, используй факты из research.",
      "allowed_tools": ["read_file", "write_to_file"],
      "forbidden_tools": ["apply_patch", "execute_command", "web_search"]
    },
    {
      "id": "publishing",
      "stage_prompt": "Опубликуй статью: создай astro-страницы, обнови индекс блога, запусти деплой.",
      "allowed_tools": ["read_file", "write_to_file", "execute_command"],
      "forbidden_tools": ["apply_patch"]
    }
  ]
}

Результат: агент проходит три стадии — исследование, написание, публикация. Каждая стадия имеет свои инструменты и критерии выхода. Агент не может публиковать, пока не закончит написание.

Пример: мод для сбора и анализа новостей

{
  "id": "news_analyst",
  "name": "News Analyst",
  "description": "Ежедневный сбор новостей отрасли и подготовка аналитического дайджеста",
  "system_prompt": "Ты — аналитик. Собирай новости, выделяй тренды, пиши краткий дайджест.",
  "stages": [
    {
      "id": "collection",
      "stage_prompt": "Собери новости за последние 24 часа из указанных источников.",
      "allowed_tools": ["web_search", "read_file", "write_to_file"],
      "forbidden_tools": ["apply_patch", "execute_command"]
    },
    {
      "id": "analysis",
      "stage_prompt": "Проанализи собранные новости. Выдели ключевые тренды, найди связи между событиями.",
      "allowed_tools": ["read_file", "write_to_file"],
      "forbidden_tools": ["apply_patch", "execute_command", "web_search"]
    },
    {
      "id": "report",
      "stage_prompt": "Напиши аналитический дайджест. Сохрани в формате markdown.",
      "allowed_tools": ["read_file", "write_to_file"],
      "forbidden_tools": ["apply_patch", "execute_command"]
    }
  ]
}

Результат: агент каждый день собирает новости, анализирует их и готовит дайджест. Можно настроить расписание — например, каждый будний день в 8:00.

Пример: мод для публикации в социальных сетях

{
  "id": "social_publisher",
  "name": "Social Publisher",
  "description": "Адаптация контента и публикация в социальных сетях",
  "system_prompt": "Ты — SMM-специалист. Адаптируй контент под каждую платформу, соблюдай лимиты символов.",
  "stages": [
    {
      "id": "adaptation",
      "stage_prompt": "Адаптируй статью под LinkedIn, Twitter, Telegram. Учитывай лимиты символов и стиль каждой платформы.",
      "allowed_tools": ["read_file", "write_to_file"],
      "forbidden_tools": ["apply_patch", "execute_command"]
    },
    {
      "id": "publishing",
      "stage_prompt": "Опубликуй посты через API социальных сетей.",
      "allowed_tools": ["read_file", "write_to_file", "execute_command"],
      "forbidden_tools": ["apply_patch"]
    }
  ]
}

Результат: агент берёт готовую статью, адаптирует её под каждую социальную сеть и публикует. Можно настроить цепочку: сначала публикация статьи → потом адаптация и постинг в соцсети.

Цепочка модов для контент-производства

Моды можно выстраивать в цепочки через механизм handoff:

Исследователь (research) → собирает информацию по теме ↓ handoff с артефактами: [“research-notes.md”, “sources.json”]
Писатель (blog_writer) → пишет статью на основе исследования ↓ handoff с артефактами: [“article-ru.md”, “article-en.md”]
Публикатор (publisher) → публикует статью в блоге ↓ handoff с артефактами: [“published-url.txt”]
SMM-специалист (social_publisher) → адаптирует и публикует в соцсетях

Вся цепочка работает автономно, без участия человека.

Система планирования: агент по расписанию

Tao·Coder имеет встроенный локальный планировщик, который работает в VS Code extension host. Это не серверный механизм — планировщик работает локально, без зависимости от облака.

Как это работает

Хранение расписаний:

.taocoder/schedules.json

Каждое рабочее пространство имеет свой schedules.json. Расписания не синхронизируются между проектами.

Модель расписания:

interface Schedule {
  schedule_id: string              // UUID
  task_template: {
    mode_id: string                // встроенный или кастомный мод
    role_mode: string              // developer, architect, ops, debug
    spec: string                   // спецификация задачи
    constraints: string[]          // ограничения
  }
  recurrence: RecurrencePattern
  next_run: string                 // ISO 8601 UTC
  last_run?: string                // ISO 8601 UTC
  status: "active" | "paused" | "completed" | "cancelled"
  timezone: string                 // часовой пояс IANA
}

interface RecurrencePattern {
  type: "simple" | "cron" | "custom"
  // simple: "every_hour" | "daily_at_09:00" | "weekly_thursday"
  // cron: "0 9 * * 4" (cron-выражение)
  // custom: { interval_ms: number } | { cron: string }
  pattern: string | { interval_ms: number } | { cron: string }
}

Механизм запуска:

setInterval с проверкой каждую минуту (60 000 мс)
Если next_run <= now → триггер выполнения
Создаётся новый task_id (не переиспользуется существующий)
Шаблон задачи клонируется в новый контекст
После выполнения вычисляется следующий next_run

Шаблон → множество запусков

Ключевой принцип: каждое запланированное выполнение создаёт новую задачу. Это означает:

Контекст задачи не раздувается от предыдущих запусков
Каждая задача изолирована — если одна упала, другие не пострадают
История запусков сохраняется в .taocoder/scheduled_runs/

Исключение: самозадержка

Если агент использует инструмент self-delay (отложить себя на N минут или часов), выполнение продолжается в том же task_id. Это не новый запланированный запуск, а продолжение текущей задачи.

Автономный режим: работа без участия человека

Когда задача запускается по расписанию, агент получает системное сообщение:

You are running autonomously. Solve the task without user feedback.
If you encounter an issue, attempt to resolve it independently.
Do not ask the user for clarification — proceed with best-effort solution.

Анализатор сбоев: что если агент застрял

Если агент пытается спросить пользователя (использует ask_followup_question), система перехватывает:

Автономный ответ: «Продолжай с лучшим решением на основе доступной информации»
Агент продолжает выполнение без обратной связи
Если агент не продвигается N шагов → эскалация (отмена задачи + уведомление пользователя)

Обнаружение пропущенных запусков

При старте VS Code планировщик проверяет пропущенные запуски:

Загружается schedules.json
Для каждого status === "active":
- Если next_run <now → обнаружен пропущенный запуск
Пользователю показывается диалог:

Расписание "Blog Writer" пропустило запуск в 2026-10-10T08:00:00Z.
[Запустить сейчас] [Пропустить] [Перенести]

Handoff: цепочка модов

Handoff — это механизм передачи задачи от одного мода к другому. Каждый handoff создаёт новую задачу с новым контекстом.

Как это работает

Критерий выхода для handoff:

{
  "checkType": "handoff_created",
  "targetMode": "developer",
  "artifactsRequired": ["architecture.md", "api-spec.yaml"]
}

Цепочка модов:

Архитектор → Разработчик → Тестировщик → Эксплуатация

Архитектор создаёт архитектуру и спецификацию
Разработчик реализует код по спецификации
Тестировщик проверяет качество и запускает тесты
Эксплуатация развёртывает изменения на продакшен

Каждый мод имеет свои:

Инструменты (разработчик может писать код, тестировщик — только запускать тесты)
Стадии (у архитектора — уточнение → проектирование → ревью, у разработчика — реализация → тестирование)
Критерии выхода (архитектор не может перейти к следующей стадии, пока не создана архитектура)

Пример: автоматическая цепочка для устранения проблем

Мониторинг сервера (ops) обнаруживает проблему: CPU > 90% ↓ handoff
Разработчик (developer) анализирует логи и создаёт исправление ↓ handoff
Тестировщик (qa) запускает тесты и проверяет исправление ↓ handoff
Эксплуатация (ops) развёртывает изменения на продакшен

Вся цепочка работает автономно, без участия человека.

Хуки стадий: бизнес-логика через конфигурацию

Хуки — это механизм добавления бизнес-логики в конфигурацию стадий. Хуки выполняются bridge-слоем и интегрируются в существующие обработчики инструментов.

Типы хуков

request_approval — запросить подтверждение пользователя:

{
  "name": "require_approval_for_deploy",
  "on": "tool_call",
  "action": "request_approval",
  "params": { "message": "Подтвердите развёртывание на продакшен" }
}

require_handoff — заблокировать переход, если handoff не завершён:

{
  "name": "require_handoff_before_exit",
  "on": "stage_exit",
  "action": "require_handoff",
  "params": { "targetMode": "qa" }
}

log — логирование без блокировки:

{
  "name": "log_stage_transition",
  "on": "stage_enter",
  "action": "log",
  "params": { "message": "Вход в стадию разработки" }
}

Интеграция в обработчики инструментов

Хуки вызываются в определённом порядке:

Обработчик команд:
- проверка безопасности → защита автоодобрения → хуки подтверждения → поток автоодобрения
Обработчик записи файлов:
- защита автоодобрения → хуки подтверждения → поток автоодобрения
Обработчик смены стадий:
- Хуки вызываются ПЕРЕД выполнением хука выхода из стадии
- Если хук возвращает cancel: true → переход стадии блокируется

Важно: хуки НИКОГДА не ломают среду выполнения. Ошибки перехватываются и логируются.

Практические примеры

Пример 1: Ежечасовой мониторинг сервера

Задача: проверять состояние продакшен-сервера каждый час и логировать проблемы.

Конфигурация:

{
  "schedule_id": "hourly-server-check",
  "task_template": {
    "mode_id": "server_monitor",
    "role_mode": "ops",
    "spec": "Проверить CPU, RAM, disk usage. Если что-то выше 80% — создать таск."
  },
  "recurrence": {
    "type": "cron",
    "pattern": "0 * * * *"
  },
  "timezone": "Asia/Novosibirsk"
}

Результат: агент каждый час проверяет сервер, логирует метрики в .taocoder/scheduled_runs/, создаёт задачи для проблемных случаев.

Пример 2: Ежедневная публикация статей

Задача: каждый будний день в 9:00 писать и публиковать статью в блоге.

Конфигурация:

{
  "schedule_id": "daily-blog-post",
  "task_template": {
    "mode_id": "blog_writer",
    "role_mode": "content-writer",
    "spec": "Написать статью по теме из контент-плана. Опубликовать на русском и английском."
  },
  "recurrence": {
    "type": "cron",
    "pattern": "0 9 * * 1-5"
  },
  "timezone": "Europe/Berlin"
}

Результат: агент каждый будний день исследует тему, пишет статью и публикует её в блоге.

Пример 3: Еженедельный аналитический дайджест

Задача: каждый понедельник в 8:00 собирать новости за неделю и готовить аналитический отчёт.

Конфигурация:

{
  "schedule_id": "weekly-news-digest",
  "task_template": {
    "mode_id": "news_analyst",
    "role_mode": "analyst",
    "spec": "Собрать новости за неделю, выделить тренды, написать аналитический дайджест."
  },
  "recurrence": {
    "type": "cron",
    "pattern": "0 8 * * 1"
  },
  "timezone": "Europe/Moscow"
}

Результат: агент каждый понедельник собирает новости, анализирует их и готовит дайджест с ключевыми трендами.

Пример 4: Автоматическое устранение проблем

Задача: если мониторинг обнаружил проблему, автоматически создать задачу для разработчика.

Цепочка:

Мониторинг сервера (ops) → обнаружил CPU > 90% ↓ handoff с артефактами: [“metrics.json”, “logs.txt”]
Разработчик (developer) → анализирует логи, создаёт исправление ↓ handoff с артефактами: [“fix.patch”, “test-results.json”]
Тестировщик (qa) → запускает тесты, проверяет исправление ↓ handoff с артефактами: [“qa-report.json”]
Эксплуатация (ops) → развёртывает изменения на продакшен

Вся цепочка работает автономно, без участия человека.

Сравнение с конкурентами

Аспект	Tao·Coder	Claude Code	Cursor	Devin
Планирование	Локальный планировщик в VS Code	CLI с флагом `-p`, внешний cron	Нет	Облачный
Кастомные моды	TAO·MODES (JSON-конфигурация)	CLAUDE.md (постоянные указания)	Cursor Rules	Нет
Автономный режим	Анализатор сбоев, самозадержка	Система хуков	Нет	Полная автономность
Handoff	Цепочка модов с артефактами	Нет	Нет	Нет
Хуки стадий	JSON-конфигурация	Нет	Нет	Нет
Привязка к проекту	Да	Да	Да	Нет
Не-coding задачи	Да (контент, аналитика, SMM)	Ограниченно	Нет	Нет

Ключевые отличия Tao·Coder:

Декларативная конфигурация — TAO·MODES дают формальные гарантии поведения агента через JSON Schema-валидацию
Локальный планировщик — работает в VS Code, не требует сервера
Handoff с артефактами — каждый handoff передаёт контекст через файлы, а не через раздутый диалог
Хуки стадий — бизнес-логика через конфигурацию, а не через хардкод
Универсальность — моды подходят не только для кодинга, но и для контент-работы, аналитики, SMM

Что дальше

TAO·MODES и система планирования в Tao·Coder — это фундамент для полностью автономных AI-агентов. Мы продолжаем развивать систему:

Серверное планирование — для платных функций, cron-выдача токенов запуска
Оркестрация множества агентов — координация нескольких агентов
Самоисцеляющийся CI/CD — автономные агенты для автоматического исправления ошибок в конвейере
Расширение экосистемы модов — готовые моды для типовых задач (контент, аналитика, мониторинг)

Если вам нужны AI-агенты, которые работают по расписанию и выстраивают цепочки задач — напишите нам. Мы поможем настроить систему под ваши задачи.

Ссылки:

Контакты:

Telegram: @thinkingos
Email: info@thinkingos.tech
Телефон: +7 (906) 950-66-95

Кастомные моды и планировщик: как AI-агент работает по расписанию без участия человека

Проблема: агент, который живёт только в чате

TAO·MODES: декларативная конфигурация внутри Tao·Coder

Структура кастомного мода

Пример: мод для мониторинга сервера

Не только для кода: моды для любых задач

Пример: мод для написания статей в блог

Пример: мод для сбора и анализа новостей

Пример: мод для публикации в социальных сетях

Цепочка модов для контент-производства

Система планирования: агент по расписанию

Как это работает

Шаблон → множество запусков

Автономный режим: работа без участия человека

Анализатор сбоев: что если агент застрял

Обнаружение пропущенных запусков

Handoff: цепочка модов

Как это работает

Пример: автоматическая цепочка для устранения проблем

Хуки стадий: бизнес-логика через конфигурацию

Типы хуков

Интеграция в обработчики инструментов

Практические примеры

Пример 1: Ежечасовой мониторинг сервера

Пример 2: Ежедневная публикация статей

Пример 3: Еженедельный аналитический дайджест

Пример 4: Автоматическое устранение проблем

Сравнение с конкурентами

Что дальше

Нужны автономные AI-агенты по расписанию?

Политика конфиденциальности

1. Сбор информации

2. Использование информации

3. Защита данных