11. Автоматизация, плагины и hooks

← Предыдущий модуль · Оглавление · Следующий модуль →

Если сейчас только читаете: русский разбор ситуации без запуска программ. После него ответьте на вопросы самопроверки модуля; практическое упражнение можно отложить.

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

Skill описывает способ работы. Плагин распространяет skills и, при необходимости, подключения и ресурсы. Hook запускает обработчик в определённой точке работы Codex. Плановая задача возвращается к работе по расписанию. codex exec запускает неинтерактивное задание из CLI. Эти механизмы можно сочетать, но они не заменяют друг друга.

Что изменилось с момента исходного руководства

Актуальная документация описывает переносимый пакет Agent Plugins с plugin.json в корне и mcp.json для подключений. Прежний .codex-plugin/plugin.json остаётся совместимым вариантом. Поэтому утверждение «у любого плагина обязательно только .codex-plugin/plugin.json» уже слишком узкое. Поддержка локальных marketplace и отдельных возможностей зависит от поверхности. Package your plugin.

Hooks официально документированы. В частности, описаны события PreToolUse, PostToolUse и Stop; их семантика различается. Нелокальные и локальные источники не следует считать взаимоисключающими: подходящие обработчики из нескольких слоёв могут выполняться вместе. Пользовательские hooks требуют проверки и доверия к текущему определению; CLI предоставляет /hooks. Меняющиеся схемы нельзя без проверки брать из ветки main исходников. Hooks.

Для учебника безопаснее начать с чтения определения hook, а не с установки. Выпишите точную команду, рабочую директорию, используемый интерпретатор, доступ к сети, возможную запись и поведение при ошибке. Hook после выполнения инструмента не может отменить уже произошедший побочный эффект. Не используйте такое событие как единственную защиту от удаления данных.

Неинтерактивный запуск в PowerShell

Перед модельным запуском можно прочитать локальную справку:

codex --version
codex exec --help

Пример ниже обращается к модели и предназначен только для учебной копии проекта:

$taskPrompt = @'
Только прочитай README.md и AGENTS.md текущего проекта.
Сопоставь описанные команды проверки. Файлы не меняй.
Верни расхождения и ограничения исследования.
'@
codex exec --sandbox read-only $taskPrompt
$taskExitCode = $LASTEXITCODE
Write-Output $taskExitCode

codex exec — сценарий CLI; он не создаёт запись в интерфейсе Scheduled. Текущая документация описывает read-only как режим по умолчанию и предупреждает, что --full-auto больше не поддерживается. На установленном старом CLI сверяйте локальный --help перед переносом новых параметров. Non-interactive mode.

Плановая задача

В desktop-приложении задания с локальными файлами требуют работающего компьютера и приложения. Веб-задание не получает прямого доступа к папке на ноутбуке. CLI и IDE не предоставляют интерфейс управления Scheduled. Доступность зависит от плана и настроек. Scheduled tasks.

Учебный текст будущей задачи: «Раз в неделю сопоставляй утверждения руководства с указанными официальными источниками. Ничего не редактируй и не публикуй. Для подтверждённого изменения укажи локальное место, официальный URL и предлагаемую правку. Если источник недоступен, сообщи об этом. Уведомляй только о содержательном изменении, ошибке или необходимости моего действия».

Упражнение

Не устанавливая расширений и не создавая расписание, подготовьте карточку автоматизации: входы, выход, права, частота, предел времени, критерий успеха, обработка недоступного источника и способ отключения. Выполните запрос вручную в обычном чате. Если результаты слишком широкие или непроверяемые, исправьте процесс до автоматизации.

Готово, когда: механизм выбран по назначению; нет скрытых публикаций; результат можно проверить; ошибка не превращается в ложный успех; определён способ отключения; новые глобальные настройки не требуются для упражнения.

Самопроверка:

Почему успешный ручной запрос ещё не означает готовность к запуску по расписанию?
Может ли PostToolUse отменить уже отправленный запрос внешнему сервису?
Чем неинтерактивный CLI-запуск отличается от задания в Scheduled?

← Предыдущий модуль · Оглавление · Следующий модуль →