Code Velocity
Narzędzia deweloperskie

Podagenci Codex: Usprawnianie procesów rozwoju AI

·7 min czytania·OpenAI·Źródło oryginalne
Udostępnij
Diagram ilustrujący wiele podagentów AI pracujących równolegle, orkiestrowanych przez głównego agenta Codex, ze strzałkami wskazującymi przepływ danych i dystrybucję zadań.

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.

  1. Security issue
  2. Code quality
  3. Bugs
  4. Race conditions
  5. Test flakiness
  6. Maintainability of the code

W tym scenariuszu Codex prawdopodobnie uruchomi sześć różnych podagentów, z których każdy specjalizuje się w jednym z wymienionych punktów przeglądu. Po zakończeniu analizy przez każdego agenta, Codex skompiluje wyniki w jeden, ustrukturyzowany raport, oferując całościowy przegląd żądania ściągnięcia (pull request). To pokazuje efektywność uzyskiwaną poprzez rozłożenie obciążenia między wyspecjalizowane jednostki AI.

## Zarządzanie i zabezpieczanie ekosystemu podagentów

Skuteczne zarządzanie i solidne bezpieczeństwo to kluczowe kwestie podczas pracy z podagentami. Codex udostępnia narzędzia i mechanizmy do nadzorowania działań podagentów i zapewnienia bezpiecznych operacji w ich środowiskach sandboksowych.

W interaktywnych sesjach CLI deweloperzy mogą używać komendy `/agent` do przełączania się między aktywnymi wątkami agentów, przeglądania bieżących procesów lub kierowania konkretnym podagentem. Ta szczegółowa kontrola pozwala na dostosowywanie w czasie rzeczywistym i monitorowanie postępów poszczególnych agentów. Możesz również wyraźnie poprosić Codex o zatrzymanie działającego podagenta lub zamknięcie zakończonych wątków, aby zarządzać zasobami i skupiać się na zadaniu.

Bezpieczeństwo jest najważniejsze, a podagenci dziedziczą bieżącą politykę sandboxu z głównej sesji Codex. Zapewnia to, że ich operacje są zgodne z predefiniowanymi zasadami bezpieczeństwa i dostępu. Kiedy żądania zatwierdzenia pojawiają się z nieaktywnych wątków agentów, zwłaszcza w interaktywnych sesjach CLI, Codex inteligentnie prezentuje je użytkownikowi. Nakładka zatwierdzenia wskaże wątek źródłowy, umożliwiając naciśnięcie klawisza 'o', aby otworzyć i zbadać ten wątek przed podjęciem świadomej decyzji o zatwierdzeniu, odrzuceniu lub udzieleniu odpowiedzi na żądanie. Zapobiega to ślepym zatwierdzeniom i utrzymuje nadzór dewelopera.

W przypadku przepływów nieinteraktywnych lub sytuacji, w których nie można wyświetlić nowego zatwierdzenia, każda akcja wymagająca nowego zatwierdzenia automatycznie się nie powiedzie, a Codex zgłosi błąd do nadrzędnego procesu pracy. Ten mechanizm bezpieczeństwa zapobiega nieautoryzowanym działaniom w kontekstach zautomatyzowanych. Ponadto, Codex ponownie stosuje bieżące przesłonięcia w czasie wykonania z nadrzędnego obrotu — takie jak zmiany wprowadzone za pomocą `/approvals` lub flagi `--yolo` — do tworzonych dzieci, zapewniając spójne postawy bezpieczeństwa w całej hierarchii agentów. Dla zaawansowanych użytkowników możliwe jest również nadpisanie konfiguracji sandboxu dla pojedynczych [niestandardowych agentów](#defining-custom-subagents-for-tailored-tasks), co pozwala na precyzyjną kontrolę nad ich uprawnieniami, na przykład poprzez oznaczenie agenta jako 'tylko do odczytu'.

## Definiowanie niestandardowych podagentów do zadań specjalnych

Chociaż Codex udostępnia kilka wbudowanych agentów, takich jak `default` (ogólnego przeznaczenia), `worker` (do zadań skupionych na wykonaniu) i `explorer` (do eksploracji kodu o dużym obciążeniu odczytem), prawdziwa siła systemu podagentów leży w jego rozszerzalności. Deweloperzy mogą definiować własnych **niestandardowych agentów** w celu sprostania wysoce wyspecjalizowanym wymaganiom, dostosowując zachowanie AI do unikalnych kontekstów projektowych.

Niestandardowi agenci są definiowani za pomocą samodzielnych plików TOML. Pliki te mogą być umieszczone w katalogu `~/.codex/agents/` dla agentów osobistych lub `.codex/agents/` dla agentów o zasięgu projektowym. Każdy plik TOML zasadniczo działa jako warstwa konfiguracyjna, umożliwiając niestandardowym agentom nadpisywanie ustawień, które w przeciwnym razie zostałyby odziedziczone z sesji nadrzędnej. Obejmuje to krytyczne parametry, takie jak używany model AI, jego wysiłek rozumowania, tryb sandboxu, a nawet specyficzne konfiguracje umiejętności.

Każdy samodzielny plik niestandardowego agenta *musi* definiować następujące pola:

*   **`name`**: Unikalny identyfikator agenta, którego Codex używa podczas jego tworzenia lub odwoływania się do niego.
*   **`description`**: Czytelne dla człowieka wskazówki, które pomagają Codex zrozumieć, kiedy należy wdrożyć tego agenta.
*   **`developer_instructions`**: Podstawowy zestaw instrukcji, które określają zachowanie agenta i logikę operacyjną.

Można również uwzględnić opcjonalne pola, takie jak `nickname_candidates`, `model`, `model_reasoning_effort`, `sandbox_mode`, `mcp_servers` i `skills.config`. Jeśli zostaną pominięte, te ustawienia zostaną odziedziczone z sesji nadrzędnej, co upraszcza konfigurację, gdy domyślne wartości są akceptowalne. Aby uzyskać najlepsze praktyki w inżynierii podpowiedzi, która bezpośrednio wpływa na instrukcje agenta, zapoznaj się z zasobami takimi jak [Przewodnik po podpowiedziach Codex](/pl/codex-prompting-guide).

Pole `name` jest ostatecznym identyfikatorem niestandardowego agenta. Chociaż dopasowanie nazwy pliku do nazwy agenta jest powszechną i zalecaną konwencją, pole `name` w pliku TOML jest ostatecznym źródłem prawdy. Pole `nickname_candidates` jest użytecznym dodatkiem dla wygody użytkownika, pozwalając Codex przypisywać bardziej czytelne nazwy wyświetlania utworzonym agentom, co jest szczególnie pomocne w złożonych scenariuszach wieloagentowych.

## Ustawienia globalne i zaawansowana konfiguracja podagentów

Oprócz indywidualnych definicji niestandardowych agentów, Codex oferuje globalne ustawienia konfiguracyjne do zarządzania ogólnym zachowaniem procesów pracy podagentów. Ustawienia te zazwyczaj znajdują się w sekcji `[agents]` w głównym pliku konfiguracyjnym, oferując centralną kontrolę nad alokacją zasobów i parametrami operacyjnymi.

Oto przegląd kluczowych globalnych ustawień podagentów:

| Pole | Typ | Wymagane | Cel |
| :--------------------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `agents.max_threads`         | number | Nie       | Ogranicza liczbę jednocześnie otwartych wątków agentów. Domyślnie `6`, jeśli nieustawione.                                                                                                                         |
| `agents.max_depth`           | number | Nie       | Ogranicza głębokość zagnieżdżenia tworzonych agentów (sesja główna zaczyna się od 0). Domyślnie `1`. Zapobiega rekurencyjnemu delegowaniu poza bezpośrednie dzieci, aby zarządzać zużyciem tokenów i opóźnieniami. |
| `agents.job_max_runtime_seconds` | number | Nie       | Ustawia domyślny limit czasu na pracownika dla zadań `spawn_agents_on_csv`. Jeśli nieustawione, domyślnie `1800` sekund (30 minut).                                                                             |

Ustawienie `agents.max_threads`, domyślnie `6`, stanowi zabezpieczenie przed nadmiernym zużyciem zasobów poprzez ograniczenie liczby podagentów, które mogą działać jednocześnie. Ustawienie `agents.max_depth`, z wartością domyślną `1`, jest szczególnie ważne. Chociaż głębsze zagnieżdżanie może wydawać się atrakcyjne dla złożonego delegowania, zwiększenie tej wartości może prowadzić do znaczącego wzrostu zużycia tokenów, opóźnień i lokalnego zużycia zasobów z powodu powtarzającego się rozgałęziania (fan-out). Zazwyczaj zaleca się utrzymanie wartości domyślnej, chyba że konkretny wzorzec rekurencyjnego delegowania jest absolutnie konieczny i starannie zarządzany.

Pliki niestandardowych agentów mogą również zawierać inne obsługiwane klucze `config.toml`, rozszerzając ich konfigurowalność poza jedynie obowiązkowe pola. To modułowe i warstwowe podejście do konfiguracji zapewnia deweloperom szczegółową kontrolę nad swoimi agentami AI, umożliwiając im optymalizację wydajności, kosztów i bezpieczeństwa, dostosowaną do ich specyficznych potrzeb rozwojowych. Dzięki zrozumieniu i wykorzystaniu tych potężnych możliwości podagentów, deweloperzy mogą przesuwać granice kodowania wspomaganego przez AI i znacząco usprawnić swoje procesy pracy rozwojowej.

Często zadawane pytania

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.

Bądź na bieżąco

Otrzymuj najnowsze wiadomości o AI na swoją skrzynkę.

Udostępnij