I would like to review the following points on the current PR (this branch vs main). Spawn one agent per point, wait for all of them, and summarize the result for each point.
- Security issue
- Code quality
- Bugs
- Race conditions
- Test flakiness
- Maintainability of the code
В этом сценарии Codex, скорее всего, запустит шесть отдельных субагентов, каждый из которых будет специализироваться на одном из перечисленных пунктов проверки. После того как каждый агент завершит свой анализ, Codex скомпилирует результаты в единый структурированный отчет, предлагая целостный обзор запроса на слияние. Это демонстрирует эффективность, достигаемую за счет распределения рабочей нагрузки между специализированными ИИ-сущностями.
## Управление и обеспечение безопасности экосистемы субагентов
Эффективное управление и надежная безопасность являются ключевыми аспектами при работе с субагентами. Codex предоставляет инструменты и механизмы для контроля активности субагентов и обеспечения безопасных операций в их изолированных средах.
В интерактивных сеансах CLI разработчики могут использовать команду `/agent` для переключения между активными потоками агентов, проверки текущих процессов или управления конкретным субагентом. Такой детальный контроль позволяет в режиме реального времени корректировать и отслеживать прогресс каждого агента. Вы также можете явно попросить Codex остановить работающий субагент или закрыть завершенные потоки для управления ресурсами и фокусировки.
Безопасность имеет первостепенное значение, и субагенты наследуют текущую политику песочницы от основной сессии Codex. Это гарантирует, что их операции соответствуют предопределенным правилам безопасности и доступа. Когда запросы на одобрение поступают от неактивных потоков агентов, особенно в интерактивных сеансах CLI, Codex интеллектуально выводит их пользователю. Наложение одобрения будет указывать исходный поток, позволяя нажать 'o', чтобы открыть и проверить этот поток, прежде чем принять обоснованное решение об одобрении, отклонении или ответе на запрос. Это предотвращает слепые одобрения и поддерживает контроль разработчика.
Для неинтерактивных потоков или ситуаций, когда новое одобрение не может быть выведено, любое действие, требующее нового одобрения, автоматически завершится ошибкой, и Codex сообщит об ошибке обратно в родительский рабочий процесс. Этот отказоустойчивый механизм предотвращает несанкционированные действия в автоматизированных контекстах. Кроме того, Codex повторно применяет динамические переопределения родительского хода — такие как изменения, внесенные через `/approvals` или флаг `--yolo` — к запущенным дочерним элементам, обеспечивая согласованные позиции безопасности по всей иерархии агентов. Для продвинутых пользователей также возможно переопределить конфигурацию песочницы для отдельных [пользовательских агентов](#определение-пользовательских-субагентов-для-конкретных-задач), что позволяет детально контролировать их разрешения, например, помечая агента как 'только для чтения'.
## Определение пользовательских субагентов для конкретных задач
Хотя Codex предоставляет несколько встроенных агентов, таких как `default` (общего назначения), `worker` (для задач, ориентированных на выполнение) и `explorer` (для исследования кодовой базы с интенсивным чтением), истинная мощь системы субагентов заключается в ее расширяемости. Разработчики могут определять свои собственные **пользовательские агенты** для удовлетворения высокоспециализированных требований, адаптируя поведение ИИ к уникальным контекстам проекта.
Пользовательские агенты определяются с использованием автономных файлов TOML. Эти файлы могут быть размещены в `~/.codex/agents/` для персональных агентов или `.codex/agents/` для агентов, ограниченных проектом. Каждый файл TOML по сути действует как слой конфигурации, позволяя пользовательским агентам переопределять настройки, которые в противном случае были бы унаследованы от родительской сессии. Это включает критически важные параметры, такие как используемая модель ИИ, ее усилия по рассуждению, режим песочницы и даже конфигурации конкретных навыков.
Каждый автономный файл пользовательского агента *должен* определять следующие поля:
* **`name`**: Уникальный идентификатор агента, который Codex использует при его запуске или упоминании.
* **`description`**: Человекочитаемое руководство, которое помогает Codex понять, когда следует развертывать этого агента.
* **`developer_instructions`**: Основной набор инструкций, которые диктуют поведение агента и его операционную логику.
Могут быть также включены необязательные поля, такие как `nickname_candidates`, `model`, `model_reasoning_effort`, `sandbox_mode`, `mcp_servers` и `skills.config`. Если они опущены, эти настройки будут унаследованы от родительской сессии, что упрощает конфигурацию, когда значения по умолчанию приемлемы. Для лучших практик в проектировании подсказок, которое напрямую влияет на инструкции агента, обратитесь к таким ресурсам, как [Руководство по созданию подсказок Codex](/ru/codex-prompting-guide).
Поле `name` является окончательным идентификатором для пользовательского агента. Хотя соответствие имени файла имени агента является общепринятой и рекомендуемой практикой, поле `name` в файле TOML является конечным источником истины. Поле `nickname_candidates` является полезным дополнением для удобства пользователя, позволяя Codex назначать более читабельные отображаемые имена запущенным агентам, что особенно полезно в сложных многоагентных сценариях.
## Глобальные настройки и расширенная конфигурация субагентов
Помимо определений отдельных пользовательских агентов, Codex предлагает глобальные настройки конфигурации для управления общим поведением рабочих процессов субагентов. Эти настройки обычно находятся в разделе `[agents]` вашего основного файла конфигурации, обеспечивая централизованный контроль над распределением ресурсов и операционными параметрами.
Ниже приведена разбивка ключевых глобальных настроек субагентов:
| Поле | Тип | Обязательно | Назначение |
| :------------------------------- | :----- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `agents.max_threads` | число | Нет | Ограничивает количество одновременно открытых потоков агентов. По умолчанию `6`, если не установлено. |
| `agents.max_depth` | число | Нет | Ограничивает глубину вложенности запущенных агентов (корневая сессия начинается с 0). По умолчанию `1`. Предотвращает рекурсивное делегирование за пределы непосредственных дочерних элементов для управления использованием токенов и задержкой. |
| `agents.job_max_runtime_seconds` | число | Нет | Устанавливает тайм-аут по умолчанию для каждого работника в задачах `spawn_agents_on_csv`. Если не установлено, по умолчанию `1800` секунд (30 минут). |
Настройка `agents.max_threads`, по умолчанию равная `6`, обеспечивает защиту от чрезмерного потребления ресурсов, ограничивая количество субагентов, которые могут работать одновременно. Настройка `agents.max_depth` с ее значением по умолчанию `1` особенно важна. Хотя более глубокая вложенность может показаться привлекательной для сложного делегирования, увеличение этого значения может привести к значительному увеличению использования токенов, задержки и потребления локальных ресурсов из-за многократного распараллеливания. Обычно рекомендуется сохранять значение по умолчанию, если только специфический шаблон рекурсивного делегирования не является абсолютно необходимым и тщательно управляемым.
Файлы пользовательских агентов также могут включать другие поддерживаемые ключи `config.toml`, расширяя их конфигурируемость за пределы обязательных полей. Такой модульный и многоуровневый подход к конфигурации гарантирует, что разработчики имеют детальный контроль над своими ИИ-агентами, позволяя им оптимизировать производительность, стоимость и безопасность в соответствии с их конкретными потребностями разработки. Понимая и используя эти мощные возможности субагентов, разработчики могут расширить границы кодирования с помощью ИИ и значительно улучшить свои рабочие процессы разработки.
Первоисточник
https://developers.openai.com/codex/subagents/Часто задаваемые вопросы
What are Codex subagents and how do they enhance AI development workflows?
Codex subagents are specialized AI agents that can be spawned in parallel by a primary Codex instance to tackle complex, multi-faceted tasks. They significantly enhance AI development workflows by enabling the division of labor across different agents, each focusing on a specific aspect of a task. This parallel processing capability is particularly beneficial for computationally intensive or intricate operations like comprehensive codebase exploration, implementing large-scale multi-step feature plans, or conducting extensive code reviews. By distributing the workload, subagents help in accelerating development cycles, improving the quality of outputs, and managing complexity more effectively than a single agent could.
How does Codex manage the orchestration of multiple subagents?
Codex excels at orchestrating subagent workflows by managing the entire lifecycle from spawning new agents to consolidating their results. When a complex task is initiated, Codex can intelligently route follow-up instructions to the appropriate subagents, monitor their progress, and await the completion of all requested tasks. Once all subagents have finished their assignments and returned their respective outputs, Codex then aggregates these results into a unified, consolidated response. This seamless orchestration ensures that even highly parallelized tasks remain coherent and deliver a comprehensive solution, simplifying complex project management for developers.
What are the security considerations and controls for Codex subagents?
Security for Codex subagents is a critical aspect, with several mechanisms in place to ensure safe operation. Subagents inherently inherit the current sandbox policy of the parent session, ensuring a consistent security posture. For interactive command-line interface (CLI) sessions, approval requests stemming from inactive agent threads can be surfaced to the user, allowing for informed decisions before actions are taken. In non-interactive environments or when immediate approval isn't feasible, actions requiring new approval will fail, preventing unauthorized operations. Developers can also apply runtime overrides for sandbox and approval choices, and even configure individual custom agents with specific sandbox modes, such as 'read-only', for fine-grained control over their operational scope and access.
How can developers create and utilize custom agents within Codex?
Developers can define custom agents in Codex to tailor AI behavior to specific needs. This is achieved by creating standalone TOML configuration files under `~/.codex/agents/` for personal agents or `.codex/agents/` for project-scoped ones. Each TOML file defines a single custom agent and acts as a configuration layer, allowing developers to override default settings like model choice, reasoning effort, or sandbox mode. Essential fields such as 'name', 'description', and 'developer_instructions' are mandatory, guiding the agent's identity and core behavior. This flexibility enables the creation of highly specialized agents for unique development tasks, further enhancing the adaptability of the Codex system.
What global settings are available for managing subagent behavior in Codex?
Codex provides several global settings to manage subagent behavior, primarily located under the `[agents]` section in the configuration file. Key settings include `agents.max_threads`, which controls the maximum number of concurrent open agent threads (defaulting to 6); `agents.max_depth`, which limits the nesting depth of spawned agents (defaulting to 1 to prevent excessive recursion and resource consumption); and `agents.job_max_runtime_seconds`, which sets a default timeout for workers in `spawn_agents_on_csv` jobs (defaulting to 1800 seconds if not specified). These settings are crucial for balancing performance, resource usage, and control over complex agent workflows, helping developers prevent unintended fan-out and manage token consumption effectively.
What are the primary advantages of using subagents for complex tasks?
The primary advantages of using subagents for complex tasks within Codex lie in their ability to parallelize and specialize operations. By breaking down a large task into smaller, manageable subtasks and assigning each to a specialized agent, development teams can achieve significant speed improvements and higher quality outcomes. For instance, in a large codebase review, one subagent might focus on security vulnerabilities, another on code quality, and a third on performance bottlenecks simultaneously. This concurrent processing not only accelerates the overall task but also allows for deeper, more focused analysis in each area, leading to more robust and comprehensive solutions than a single, monolithic AI agent could provide.
Будьте в курсе
Получайте последние новости ИИ на почту.