Codex в бизнесе: как передавать агенту повторяющиеся задачи

Codex — это режим ChatGPT и агент, то есть программа, которая может работать с файлами проекта. Например, он может раз в неделю собирать отчёт, разбирать отзывы клиентов, проверять текст перед публикацией или готовить черновик письма. Для этого ему нужны сами материалы и понятное задание: что сделать и в каком виде сохранить. Перед использованием результат проверяет человек.

Если результат нельзя сразу использовать, его придётся перепроверить и переделать. Например, заново сверить цифры в отчёте, поправить текст или исправить код. Тогда Codex не экономит время.

1. Что такое Codex в рабочем процессе

Обычный чат отвечает на отдельный вопрос. Codex работает с папкой проекта: читает заданные файлы, находит связанные с задачей строки или части программы, вносит изменения, запускает тесты (автоматические проверки), линтер (автоматическую проверку кода) или сборку (проверку, что из кода получается рабочая программа) и возвращает перечень изменённых файлов, diff (список всех изменений), результаты проверок и список того, что ещё нужно проверить человеку.

Codex стоит оценивать не по отдельному ответу, а по всей переданной работе. Для неё нужны:

• исходные материалы;
• правила проекта;
• конкретная задача;
• место для черновика или результата;
• способ проверки;
• человек, который принимает работу.

Когда входных данных не хватает, агент начинает угадывать. Иногда угадывает удачно, а иногда выбирает не тот формат, обращается не к тому источнику или делает лишний шаг.

Codex можно использовать для конкретных задач:

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

Большинство этих задач можно проверить на локальной копии — папке проекта на вашем компьютере. Расписание и внешние действия подключайте позже, когда понятны входы и порядок проверки.

Где работает Codex

Один и тот же агент доступен в нескольких местах:

• в приложении ChatGPT — самый простой старт, с папкой проекта и наглядным diff;
• в командной строке (CLI — окне, где команды вводят текстом) — для быстрых операций и повторяющихся запусков;
• в редакторе кода — когда правки нужно видеть рядом с файлами;
• в облаке — на сервере, то есть на удалённом компьютере, когда задача может выполняться без вашего компьютера;
• в GitHub — онлайн-сервисе, где хранят код и историю изменений, — когда нужны версии, обсуждение изменений и pull request (предложение принять изменения).

Для первых задач хватит приложения. Терминал — окно для ввода команд текстом — и редактор понадобятся, если работа связана с кодом или повторяющимися командами. Облако и GitHub подключайте, когда проект уже хранится в репозитории, то есть в папке с кодом и историей изменений, и есть понятный процесс согласования.

Локальная и облачная работа

При локальной работе агент видит папку на вашем компьютере, а изменения появляются рядом с исходниками. Это удобно для закрытых материалов, пробных версий и первых запусков.

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

Для облачной задачи полезна отдельная рабочая копия проекта — git worktree (отдельная папка с тем же проектом, где изменения не смешиваются с основной копией). Это особенно пригодится для задач по расписанию: пока команда работает днём, агент ночью собирает отчёт в своей копии.

Сколько работы отдавать сразу

Работу можно передавать в трёх режимах.

Анализ. Агент читает материалы, собирает карту источников, ищет расхождения и предлагает варианты. Файлы не меняются.

Черновик. Агент создаёт документ, таблицу, код или ответ. Человек смотрит результат и решает, что с ним делать.

Ограниченные изменения. Агент меняет разрешённые файлы, запускает проверки или создаёт pull request. Заранее определите папку и список действий; старую версию можно вернуть.

Публикация, отправка письма, платежи, удаление и изменение рабочего сайта или сервиса остаются отдельными действиями. Даже удачный черновик не означает, что эти действия стоит автоматизировать.

2. Первый час с Codex

Начать проще всего с приложения ChatGPT. В новом чате выберите режим Codex и откройте папку проекта. Если проекта ещё нет, создайте пустую папку с понятным названием. В приложении есть разные режимы: Chat — обычный разговор, Work — работа с документами и таблицами, Codex — работа с папкой и файлами.

Режимы легко перепутать: Chat нужен для обычного разговора, Work — для документов и таблиц, Codex — для работы с папкой и файлами.

Не начинайте с большой переделки. Сначала проверьте, что агент видит нужную папку:

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

Ищите в ответе точку входа — файл или команду, с которой начинается запуск проекта, — а также важные папки, команды запуска, тесты, настройки и найденные пробелы. Не ограничивайтесь списком файлов.

Если агент видит не ту папку, старые файлы или не может понять, как проверить результат, выясните это до первой правки.

Правила проекта (AGENTS.md) и первая сохранённая версия

После чтения можно попросить:

Сделай черновик AGENTS.md по тому, что узнал о проекте. Покажи файл и отдельно укажи, что нужно поправить руками.

Команда /init осматривает папку и создаёт заготовку файла правил. Проверьте в ней команды, пути и ограничения: заготовка может ошибаться.

До первой задачи сохраните исходное состояние. Если проект ещё не использует Git — систему, которая сохраняет историю изменений, — можно попросить агента:

Включи Git в этой папке и сделай первую сохранённую версию проекта. Ничего больше не меняй.

Git — система, которая сохраняет историю изменений проекта. Коммит — одна сохранённая версия проекта. Если агент внёс лишние правки, можно вернуться к состоянию до задачи, а не восстанавливать всё вручную.

Что посмотреть после задачи

Перед тем как принять результат, откройте diff — список строк, которые добавились, изменились или удалились, — и проверьте три вещи:

1. какие файлы изменились и не залез ли агент в соседние папки;
2. нет ли удалённых строк там, где вы ничего не просили удалять;
3. не появились ли в файлах пароли, ключи или другие секреты.

Читать весь код необязательно. Достаточно понять, какие файлы затронуты и что изменилось.

3. Выберите задачу, которую можно измерить

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

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

У такого процесса есть повторяющиеся шаги и результат, который можно посмотреть. На первых этапах должна оставаться возможность отменить изменения.

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

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

Что измерить до старта

Запишите хотя бы пять вещей:

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

Ориентир — время до приемлемого результата. Скорость ответа сама по себе ничего не значит: черновик за десять минут, после которого час восстанавливают логику отчёта, времени не экономит.

Разложите материалы

Минимальная структура папки:

project/
├── sources/       # исходные документы и данные
├── examples/      # примеры хорошего результата
├── work/          # промежуточные материалы
├── outputs/       # результаты для проверки
├── AGENTS.md      # постоянные правила
└── README.md      # краткое описание проекта

Названия папок не так важны. Главное, чтобы оригиналы не смешивались с черновиками. Git — система, которая сохраняет историю изменений кода. Для документов подойдут копии, история версий или отдельные папки.

Определите главный источник

В отчёте главным источником может быть одна таблица, в исследовании — набор исходных материалов, в контенте — подтверждённые материалы или расшифровка.

Если источники расходятся, правило лучше написать прямо:

Не выбирать значение по догадке. Показать оба варианта, указать источники и вынести вопрос на ручное решение.

Такое правило объясняет, что делать при расхождении. Просьба «будь внимательным» не говорит, какое действие нужно выполнить.

4. Как ставить задачу

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

Результат

Что должно появиться в конце: файл, таблица, список решений, пробная версия, diff или черновик сообщения.

«Разберись с клиентами» — направление.

«Подготовь таблицу с активными сделками, рисками и вопросами к следующему созвону» — результат.

Входы

Назовите папки, файлы, ссылки или системы, которые разрешено использовать. Если материалов много, укажите набор и период.

«Используй sources/sales/ и заметки последней недели. Старые отчёты смотри только для сравнения» лучше, чем «изучи всё».

Ограничения

Напишите, чего агент не должен делать:

• менять оригиналы;
• добавлять цифры без источника;
• добавлять новые библиотеки (готовые компоненты для программы);
• отправлять сообщения;
• подключаться к внешнему сервису;
• менять рабочий сайт или сервис.

Ограничения должны объяснять, какой риск они закрывают. Список из двадцати запретов только усложнит задачу.

Как принять результат

Нужны признаки, по которым можно сказать «готово»:

• каждый вывод связан с источником;
• пропуски вынесены отдельно;
• файл лежит в нужной папке;
• приложение запускается локально;
• проверки для изменённого участка прошли;
• места для ручного просмотра перечислены.

Если данных не хватает

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

Шаблон задачи

Результат:
Что должно появиться в конце:

Используй:
Какие папки, файлы и источники доступны:

Не делай:
Что запрещено менять, отправлять или додумывать:

Готово, когда:
Как я приму результат:

Если данных не хватает:
Что показать вместо самостоятельной догадки:

Плохая и хорошая формулировка

Плохо:

Сделай выгрузку заказов.

Хорошо:

Добавь команду /export, которая сохраняет заказы за последний месяц в CSV — обычный табличный файл, который открывается в Excel. Файлы, отвечающие за команды, лежат в handlers/, запрос к базе — в db/orders.py. Новые библиотеки не добавляй, структуру базы не меняй. Готово, когда файл открывается в Excel без искажений кириллицы, текущие автоматические проверки проходят и для новой команды есть отдельная проверка.

Хорошая постановка заняла несколько строк, но убрала вопросы про период, формат, файлы, библиотеки и проверку.

Когда нужен план

Если задача большая, размытая или вы сами ещё не определились, сначала попросите план:

Изучи проект и составь план работы. Код и документы пока не меняй. Покажи входы, предположения, риски, критерии готовности и порядок проверки. После плана остановись.

Есть и другой полезный режим — интервью:

Задай мне вопросы про эту идею, оспорь мои предположения и собери из ответов короткое ТЗ (техническое задание — описание работы для исполнителя). После этого остановись.

Для работы на несколько дней план можно хранить в PLANS.md. Тогда он не исчезнет вместе с историей конкретного чата.

5. Первый запуск и проверка

Первый запуск проведите по шагам:

1. прочитать и понять, что находится в папке;
2. согласовать план — список шагов до начала работы;
3. дать небольшой участок работы;
4. посмотреть изменения и проверки;
5. сохранить версию.

Не начинайте с «почини всё». Для документа возьмите один раздел, для кода — один сценарий, для отчёта — одну неделю или один сегмент клиентов.

В конце попросите агента перечислить:

• какие файлы изменились;
• что именно было сделано;
• какие проверки прошли;
• что осталось непроверенным;
• где нужно ваше решение.

Фраза «готово» сама по себе ничего не подтверждает.

Если результат не подходит

Чаще всего причина одна из пяти.

1. Неправильные входы. В папке старая версия, не тот период или неполный набор файлов.
2. Неясный формат. В задаче не сказано, что должно быть на выходе.
3. Пропущено правило. Агент столкнулся с исключением, о котором никто не договорился.
4. Не хватает доступа. Для действия нужна внешняя система или отдельное подтверждение.
5. Нет проверки. Результат выглядит убедительно, но его не сверяют с источником или ожидаемым поведением.

Если результат не подходит, не переписывайте весь запрос. Сначала найдите причину и измените только соответствующую часть задачи.

Команды, которые пригодятся

Названия команд и их поведение могут меняться. На практике чаще всего пригодятся:

• /plan — составить план до изменений;
• /init — создать черновик AGENTS.md;
• /review — проверить ветку (отдельную линию изменений), несохранённые правки или сохранённую версию проекта;
• /skills — посмотреть доступные инструкции;
• /compact — сжать раннюю часть длинного чата;
• /status — посмотреть состояние текущего запуска и лимитов;
• /fork — продолжить работу в отдельном чате-копии;
• /resume — вернуться к задаче, которую сохранили для продолжения.

/review можно использовать не только перед объединением изменений в общий код. Пусть агент проверит конкретную инструкцию: например, «найди неподтверждённые цифры и места, где нарушен заданный стиль».

Список команд и их поведение лучше сверять с актуальной документацией по командной строке Codex: интерфейс и названия со временем меняются.

6. Четыре безопасных сценария для первого запуска

Еженедельный отчёт

Вход: таблица продаж, заметки отдела, отчёт прошлой недели.

Результат: черновик с изменениями, рисками и вопросами.

Проверка: ключевые цифры сверены с главным источником, пропуски отмечены, исходные файлы не менялись.

Собери черновик отчёта за текущую неделю из sales/ и заметок встреч. Сравни показатели с прошлой неделей. Не объясняй изменение цифры, если в источниках нет причины. Отдельно покажи новые сделки, сделки в риске и вопросы, требующие решения. Сохрани результат в outputs/weekly-report.md. Перед сохранением перечисли расхождения.

Агент здесь не решает, почему стало меньше покупок. Он экономит время на сборе материала, но решение требует информации о ситуации, которой нет в папке.

Исследование и контент

Вход: статьи, интервью, расшифровки, заметки, ссылки.

Результат: список источников, структура материала или первый черновик.

Проверка: факты связаны с источниками, наблюдения отделены от выводов, неизвестные места вынесены отдельно.

Из материалов в research/ собери карту источников по теме повторных правок в видеопроизводстве. Для каждого материала укажи источник, дату, основную мысль и возможное применение. Не добавляй цифры, которых нет в файлах. В конце выдели темы, для которых недостаточно подтверждений.

Сначала разберите источники, потом просите написать статью. Так в текст не попадут случайные выводы из неразобранной папки.

Обратная связь клиентов

Вход: отзывы, заявки в поддержку, заметки продаж, расшифровки разговоров.

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

Проверка: каждая тема подтверждается исходными фрагментами или помечена как единичная; предложения не выдаются за факты.

Разложи отзывы из feedback/ по темам. Сохрани исходные формулировки рядом с каждой темой. Отдельно выдели частые проблемы, единичные сигналы и вопросы, на которые нет данных. Предложи возможные действия, но не ранжируй их по приоритету без критериев.

Это помогает подготовить обсуждение продукта, но не решает, какую функцию строить первой.

Внутренний инструмент

Вход: описание операции, пример данных, ограничения по доступу.

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

Проверка: приложение запускается, основной сценарий проходит, ошибки ввода понятны, изменённые файлы перечислены.

Собери локальный экран для загрузки CSV. Пользователь выбирает файл, видит первые десять строк и получает понятное сообщение, если нет обязательного столбца. Авторизацию, платежи, публикацию и внешние сервисы не подключай. Готово, когда приложение запускается локально, основной сценарий проверен, а изменённые файлы перечислены.

Ограничение оставляет пробную версию простой и не даёт ей незаметно обрасти лишними библиотеками.

7. Правила проекта (AGENTS.md), которые не нужно повторять

Файл AGENTS.md хранит постоянные правила проекта: где лежат исходники, куда сохранять результат, что нельзя менять, как запускать проверки и что считать готовым.

Команда /init может создать черновик автоматически. После этого его всё равно нужно проверить руками: агент может неверно определить команду запуска или принять временный файл за важный.

Минимальный пример:

# Проект

- Исходники находятся в `sources/`.
- Черновики — в `work/`.
- Результаты для проверки — в `outputs/`.

# Правила

- Оригиналы не перезаписывать.
- Неподтверждённые факты отмечать отдельно.
- Не публиковать и не отправлять материалы без подтверждения.
- Не менять доступы, платежи и рабочий сайт или сервис.

# Проверка

- В конце перечислять изменённые файлы.
- Для текста указывать источники и сомнительные места.
- Для кода запускать проверки, связанные с изменением.

Сколько правил писать

Записывайте в файл только то, что должно быть верно почти всегда. Если правило пришлось повторить в задании дважды, его стоит перенести в AGENTS.md. Если оно относится к одной процедуре, оставьте его в отдельной инструкции.

Длинный список запретов может мешать работе. Новая модель читает инструкции буквально. Фраза «ничего не делай без моего разрешения» способна превратить простую задачу в серию вопросов о каждом безопасном шаге.

Если агент останавливается там, где может действовать безопасно, правило лучше сформулировать точнее:

## Инициатива

- Читай файлы, проводи проверку и выполняй обратимые действия в папке проекта без отдельного разрешения.
- Перед необратимыми действиями, внешней отправкой, удалением, платежами и изменением рабочего сайта или сервиса остановись и попроси подтверждение.
- Не останавливайся только на плане, если задача уже разрешена к выполнению.

Так контроль остаётся на рискованных действиях, а чтение каждого файла не превращается в отдельный запрос разрешения.

Правила могут быть вложенными

Общие инструкции можно хранить в корне проекта, а узкие — рядом с конкретной папкой. Временный AGENTS.override.md может заменить обычные правила на своём уровне. Такая схема удобна, когда у кода, контента и данных разные ограничения. Подробности есть в официальной документации OpenAI по AGENTS.md.

8. Отдельные инструкции (Skills) для повторяющихся процедур

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

1. найти новые материалы за нужный период;
2. проверить дату и источник;
3. отделить наблюдения от выводов;
4. разложить материалы по категориям;
5. вынести противоречия и пробелы;
6. сохранить обзор и вопросы для решения.

Skill в Codex хранится в виде файла SKILL.md — текстового файла с правилами процедуры; рядом могут быть шаблоны, справочные материалы и скрипты. Описание формата есть в документации OpenAI по таким инструкциям.

Короткий пример:

---
name: weekly-report
description: Собирает черновик еженедельного отчёта из папки sales.
---

1. Прочитай правила проекта и материалы за текущую неделю.
2. Сверь данные с главным источником.
3. Не заполняй пропуски догадками.
4. Сохрани черновик в `outputs/`.
5. Отдельно перечисли расхождения и вопросы.

В хорошем описании должно быть ясно, когда нужна инструкция. «Помогает работать с базой» слишком широко: такая инструкция подойдёт и для чтения, и для отчёта, и для переноса данных. «Использовать при изменении структуры базы и проверке переноса данных» задаёт границу точнее.

Не нужно писать пошаговый рецепт на каждую мелочь. Для новой версии Codex часто достаточно цели, границ и способа проверки. Жёсткий сценарий оставляйте там, где порядок шагов действительно важен.

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

Практичный запрос для проверки:

Проверь AGENTS.md и отдельные инструкции на правила, которые приводят к лишней работе, конфликтам или ненужным вопросам. Объясни, что именно мешает, и предложи минимальные изменения. Файлы пока не меняй.

9. Git, diff и обратимость

Работа с файлами должна оставлять возможность вернуться к прежнему состоянию.

Для кода Git даёт несколько контрольных точек:

• рабочие изменения до фиксации;
• diff для просмотра;
• сохранённая версия проекта;
• pull request для обсуждения и проверки.

Для документов действует тот же принцип: оригинал, черновик, версия на проверке и утверждённый результат не должны быть одним файлом.

Перед большой задачей делайте коммит. После задачи смотрите diff. В нём важнее всего не цвет строк, а границы: какие файлы затронуты, что исчезло, не появились ли секреты и соответствует ли изменение исходной просьбе.

Pull request можно воспринимать как короткий отчёт о работе: что изменилось, зачем, какие проверки прошли и что осталось посмотреть. В небольшой команде по нему проще быстро понять, что именно принимается.

10. Как выбрать режим работы и следить за лимитом

Даже сильная версия ИИ (искусственного интеллекта) не исправит неясную задачу. Она не определит, какую дату считать отчётной, какой источник главный и что делать с расхождениями.

Уровень рассуждений — это настройка, которая определяет, сколько времени и вычислений программа потратит на задачу. Выбирайте его по сложности работы:

• Low — простой режим для коротких правок, преобразований, сортировки и форматирования;
• Medium — средний режим для отладки, то есть поиска и исправления ошибок, когда причина не видна сразу;
• High — более тщательный режим для незнакомого кода, сложной ошибки и задач со многими связанными частями;
• самые высокие режимы — для длинных задач, где нужно проверить много связанных частей.

Начинайте с Low или Medium. Если агент не справился, сначала проверьте входы, формулировку и критерий готовности. Повышение уровня не добавит отсутствующий файл и не угадает нужный формат.

Уровень рассуждений влияет на время ответа и расход лимита. Лимит — это доступный объём использования Codex. Лимиты и доступные режимы меняются, поэтому перед большой задачей смотрите раздел Usage (экран с расходом лимита) в настройках. Смотрите на стоимость всей работы:

ручная работа + проверка + исправления + цена задержки

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

Новая версия Codex может задавать больше уточняющих вопросов, читать правила буквально и тщательнее проверять мелкие изменения. Это полезно, пока правила точные. Если в AGENTS.md написано слишком общее «ничего не делать без разрешения», программа будет останавливаться на каждом безопасном шаге.

Названия версий, лимиты и тарифы я намеренно не зафиксировал. Актуальные рекомендации по выбору модели лучше смотреть в документации OpenAI.

11. Длинные чаты и настройки

В длинном чате накапливаются ваши сообщения, открытые файлы, ответы агента и промежуточные решения. Когда истории становится слишком много, ранние детали могут потеряться.

Один чат — одна связная задача

Для команды в боте заведите один чат, для ошибки на сайте — другой. Продолжайте в том же чате, если новая задача относится к той же проблеме и старый контекст полезен. Ветвите разговор через /fork, когда работа действительно разошлась.

Когда чат становится слишком большим, используйте /compact — команду, которая сжимает старую часть переписки, — или начните новый запуск на основе файлов проекта. Сводка помогает не потерять решения, но не заменяет исходные материалы.

Важные решения лучше переносить в файлы:

• правила — в AGENTS.md;
• процедуру — в отдельной инструкции;
• исходные данные — в sources/;
• решения и открытые вопросы — в короткий рабочий документ;
• удачные примеры — в examples/.

Если следующий запуск не может продолжить работу без чтения старого чата, пора вынести часть информации в проект.

config.toml

Настройки, которые действуют между запусками, можно хранить в обычном файле config.toml. Там задаются версия Codex по умолчанию, уровень рассуждений, правила подтверждений и подключения к внешним сервисам. В приложении те же параметры обычно доступны через раздел Settings (настроек).

Обычно есть общий файл настроек ~/.codex/config.toml, настройки внутри проекта .codex/config.toml и разовые параметры для запуска из командной строки. Настройки проекта относятся к конкретной рабочей папке, а общие — ко всей среде. Описание задачи и правила проверки держите в AGENTS.md и отдельных инструкциях: настройки отвечают за среду, а не за смысл работы.

Профили — это готовые наборы настроек. Они удобны, когда нужен осторожный режим для чужого проекта и более свободный — для своего. Если агент ведёт себя странно, сначала проверьте: ту ли папку открыли, есть ли права на запись, та ли выбрана модель, подключён ли нужный инструмент и не переполнен ли контекст.

12. Доступы, безопасность и подключения к внешним сервисам

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

На первых этапах не давайте агенту самостоятельный доступ к:

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

В Codex это две разные настройки. Подтверждения определяют, когда агент должен спросить разрешение. Песочница — ограничение, которое определяет, в какие папки он может писать и какие файлы видит. Оставьте осторожные значения по умолчанию и ослабляйте их только для понятного проекта и конкретной задачи. О том, как это работает, рассказано в документации OpenAI по безопасности.

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

Подключения к внешним сервисам (MCP)

Агент видит папку проекта. CRM — система учёта клиентов и продаж, таск-трекер — сервис для ведения задач, база данных и аналитика — рабочая информация. Codex не увидит эти системы, пока вы не передадите данные или не подключите внешний инструмент.

MCP — это способ подключить к Codex внешний сервис. Для начала достаточно одного подключения, которое убирает конкретный ручной шаг: например, каждый день переносит данные из таблицы в отчёт.

Перед подключением нужно решить:

• какой источник главный;
• какие поля и действия разрешены;
• как сверять данные;
• кто разбирает исключения;
• что делать после сбоя или повторного запуска.

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

Расписание

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

Если днём в проекте работают люди, задачу по расписанию лучше запускать в отдельной рабочей копии проекта. Иначе ночной отчёт может столкнуться с незавершёнными ручными изменениями.

13. Один агент или несколько

Одного агента обычно хватает для последовательной задачи с общей информацией о проекте.

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

• исследователь собирает исходные материалы;
• редактор делает простые повторяющиеся правки;
• отдельный помощник проверяет основные и необычные варианты;
• основной исполнитель собирает результаты и принимает решение.

На несколько исполнителей удобно делить чтение, поиск, сравнение и проверки. Одновременная запись в один документ обычно создаёт конфликты и размывает ответственность.

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

1. результаты действительно независимы;
2. их нужно сравнивать;
3. основному исполнителю понятно, как разбираться с противоречиями.

Если ответы на эти вопросы отрицательные, лучше поручить работу одному агенту: так будет проще и дешевле.

Сложные роли можно хранить в проекте отдельно, например в .codex/agents/. Но новичку достаточно разделить работу в самом запросе и дать одному исполнителю собрать итог.

14. Неделя первого эксперимента

День 1. Приложение и папка

Откройте приложение ChatGPT, выберите Codex и рабочую папку. Попросите описать проект, ничего не меняя.

День 2. Git и правила

Сделайте первый коммит. Запустите /init или создайте короткий AGENTS.md вручную. Поправьте команды запуска и проверки.

День 3. Одна реальная задача

Сформулируйте задачу через результат, входы, ограничения и критерий готовности. Посмотрите diff и проверьте работу руками.

День 4. Режим плана

Возьмите задачу побольше и попросите план через /plan. Уточните только вопросы, без которых работу нельзя продолжить, а затем поручите её выполнение.

День 5. Расход лимита

Откройте раздел Usage (экран с расходом лимита) в настройках утром и вечером. Посмотрите, сколько лимита уходит на простые и сложные задачи. Не используйте высокий уровень рассуждений для любой мелкой правки.

День 6. Первый skill

Возьмите процедуру, которую уже дважды объясняли агенту, и оформите её короткой инструкцией. Не пытайтесь описать все исключения сразу.

День 7. Облако или второй skill

Если проект уже лежит на GitHub, отдайте одну безопасную задачу в облачный Codex и примите результат через pull request. Если GitHub пока не нужен, вместо этого закрепите вторую повторяемую процедуру.

В конце недели сравните процесс с исходной точкой:

• сколько времени прошло до первого пригодного результата;
• сколько правок внёс человек;
• какие ошибки агент заметил сам;
• что пришлось объяснять заново;
• какая часть риска всё ещё требует ручной проверки.

Если быстрее стал только первый черновик, а принятие работы заняло больше времени, значит, экономии времени нет.

15. Что чаще всего ломается

Правила приходится повторять в каждом задании

Постоянные правила перенесите в AGENTS.md, а отдельную процедуру — в отдельную инструкцию.

Агент не видит, как проверить результат

Добавьте команды запуска и проверки в правила проекта. Попросите перечислить, какие проверки выполнены.

Большая задача начинается без плана

Используйте /plan, интервью или PLANS.md до первой правки.

Полный доступ выдан с первого дня

Начните с чтения и черновика. Доступ к отправке, удалению и публикации выдавайте отдельно.

Две задачи меняют одну папку

Разделите чаты и рабочие копии. Для параллельной или ночной задачи используйте отдельную рабочую копию проекта.

Расписание включили слишком рано

Проведите несколько ручных запусков, оформите процедуру в отдельной инструкции и только потом включайте автоматический черновик. Отправку оставьте на следующий уровень.

Руководитель смотрит каждый шаг

Проверяйте то, что связано с риском: входы, diff, результат и внешнее действие. Иначе ручная работа почти не меняется, а сверху добавляется контроль каждого шага.

Один чат используется для всего проекта

Контекст разрастается, старые решения мешают новым. Разделяйте связные задачи, используйте /compact и переносите важное в файлы.

Старые запреты мешают новой модели

Если агент спрашивает разрешение на каждый безопасный шаг или создаёт лишние проверки и отчёты, проверьте AGENTS.md и отдельные инструкции. Не добавляйте ещё одну инструкцию поверх старой — сначала найдите конфликт.

Высокий уровень рассуждений используется всегда

Для мелкой правки дополнительное время на рассуждение редко меняет результат. Начните с Low или Medium и повышайте уровень только по результату.

16. Шаблоны для старта

Бриф задачи

Результат:
Входные материалы:
Ограничения:
Критерии готовности:
Что делать при пропуске или противоречии:
Что показать перед сохранением или отправкой:

Запрос на план

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

Запрос на завершение

Перечисли изменённые файлы.
Покажи, какие проверки прошли.
Отдельно укажи, что не проверено.
Составь список вопросов, которые требуют моего решения.
Не отправляй и не публикуй результат без подтверждения.

Проверка перед передачей результата

[ ] Оригиналы сохранены.
[ ] Источники и спорные места указаны.
[ ] Изменения можно увидеть и отменить.
[ ] Проверки связаны с изменённым участком.
[ ] Внешняя отправка или публикация подтверждены отдельно.
[ ] Следующий запуск сможет начать работу из файлов проекта.

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

Начните с приложения и одной безопасной задачи. Сохраните исходное состояние, разложите материалы, запишите правила и проведите несколько запусков с ручной проверкой. После этого оформите устойчивые шаги в отдельной инструкции.

Подключения к внешним сервисам, расписание, облако, дополнительные агенты и более дорогие режимы подключайте, когда ясно, какой ручной шаг они уберут.

Агент берёт на себя часть рутины. Решения, для которых нужны контекст и ответственность, остаются у человека.