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
Šiuo atveju, Codex greičiausiai paleistų šešis skirtingus papildomus agentus, kurių kiekvienas specializuotųsi viename iš išvardytų peržiūros punktų. Kai kiekvienas agentas užbaigtų savo analizę, Codex surinktų išvadas į vieną, struktūrizuotą ataskaitą, teikdamas išsamią traukimo užklausos apžvalgą. Tai iliustruoja efektyvumą, pasiektą paskirstant darbo krūvį tarp specializuotų DI subjektų.
## Papildomų agentų ekosistemos valdymas ir apsauga
Efektyvus valdymas ir patikima apsauga yra pagrindiniai aspektai, dirbant su papildomais agentais. Codex teikia įrankius ir mechanizmus, skirtus stebėti papildomų agentų veiklą ir užtikrinti saugias operacijas jų apsaugotose aplinkose.
Interaktyviose CLI sesijose kūrėjai gali naudoti `/agent` komandą, kad perjungtų aktyvias agentų gijas, tikrintų vykstančius procesus arba nukreiptų konkretų papildomą agentą. Šis smulkus valdymas leidžia realiuoju laiku koreguoti ir stebėti individualią agento eigą. Taip pat galite aiškiai paprašyti Codex sustabdyti veikiantį papildomą agentą arba uždaryti baigtas gijas, kad valdytumėte resursus ir susitelktumėte.
Saugumas yra svarbiausia, o papildomi agentai paveldi dabartinę apsaugos aplinkos politiką iš pagrindinės Codex sesijos. Tai užtikrina, kad jų operacijos atitiktų iš anksto nustatytas saugos ir prieigos taisykles. Kai neaktyvių agentų gijų patvirtinimo užklausos atsiranda, ypač interaktyviose CLI sesijose, Codex protingai jas parodo vartotojui. Patvirtinimo perdanga nurodys šaltinio giją, leidžiančią paspausti 'o', kad atidarytumėte ir patikrintumėte tą giją prieš priimdami pagrįstą sprendimą patvirtinti, atmesti ar atsakyti į užklausą. Tai apsaugo nuo aklų patvirtinimų ir palaiko kūrėjų priežiūrą.
Neinteraktyvioms eigoms arba situacijoms, kai negalima pateikti naujo patvirtinimo, bet kuris veiksmas, reikalaujantis naujo patvirtinimo, automatiškai nepavyks, o Codex praneš apie klaidą pagrindinei darbo eigai. Šis saugus mechanizmas apsaugo nuo neteisėtų veiksmų automatizuotuose kontekstuose. Be to, Codex pakartotinai taiko pagrindinio posūkio vykdymo laiko pakeitimus – tokius kaip pakeitimai, atlikti per `/approvals` arba `--yolo` vėliavą – sugeneruotiems vaikams, užtikrinant nuoseklias saugumo pozicijas visoje agentų hierarchijoje. Patyrusiems vartotojams taip pat yra galimybė pakeisti atskirų [pasirinktinių agentų](#defining-custom-subagents-for-tailored-tasks) apsaugos aplinkos konfigūraciją, leidžiant tiksliai valdyti jų leidimus, pavyzdžiui, pažymint agentą kaip 'tik skaityti'.
## Pasirinktinių papildomų agentų apibrėžimas pritaikytoms užduotims
Nors Codex teikia keletą integruotų agentų, tokių kaip `default` bendrosios paskirties atsarginis, `worker` vykdymui skirtoms užduotims ir `explorer` intensyviam kodų bazės skaitymui, tikra papildomų agentų sistemos galia slypi jos išplečiamume. Kūrėjai gali apibrėžti savo **pasirinktinius agentus**, kad atitiktų labai specializuotus reikalavimus, pritaikydami DI elgesį unikaliems projekto kontekstams.
Pasirinktiniai agentai apibrėžiami naudojant atskirus TOML failus. Šie failai gali būti patalpinti `~/.codex/agents/` asmeniniams agentams arba `.codex/agents/` projekto apimties agentams. Kiekvienas TOML failas iš esmės veikia kaip konfigūracijos sluoksnis, leidžiantis pasirinktiniams agentams pakeisti nustatymus, kurie kitu atveju būtų paveldimi iš pagrindinės sesijos. Tai apima kritinius parametrus, tokius kaip naudojamas DI modelis, jo argumentavimo pastangos, apsaugos aplinkos režimas ir net konkrečių įgūdžių konfigūracijos.
Kiekvienas atskiras pasirinktinio agento failas *privalo* apibrėžti šiuos laukus:
* **`name`**: unikalus agento identifikatorius, kurį Codex naudoja jį generuojant arba nurodant.
* **`description`**: žmogaus skaitomos gairės, padedančios Codex suprasti, kada įdiegti šį agentą.
* **`developer_instructions`**: pagrindinės instrukcijos, kurios nurodo agento elgesį ir veikimo logiką.
Taip pat gali būti įtraukti neprivalomi laukai, tokie kaip `nickname_candidates`, `model`, `model_reasoning_effort`, `sandbox_mode`, `mcp_servers` ir `skills.config`. Jei jie praleidžiami, šie nustatymai bus paveldimi iš pagrindinės sesijos, supaprastinant konfigūravimą, kai numatytosios reikšmės yra priimtinos. Geriausios praktikos raginimų inžinerijoje, kuri tiesiogiai įtakoja agento instrukcijas, rasite tokiuose šaltiniuose kaip [Codex raginimų gidas](/lt/codex-prompting-guide).
Laukas `name` yra galutinis pasirinktinio agento identifikatorius. Nors failo pavadinimo derinimas su agento pavadinimu yra įprasta ir rekomenduojama konvencija, `name` laukas TOML faile yra galutinis tiesos šaltinis. Laukas `nickname_candidates` yra naudingas papildymas vartotojo patirčiai, leidžiantis Codex priskirti labiau skaitomus rodymo pavadinimus sugeneruotiems agentams, o tai ypač naudinga sudėtinguose daugelio agentų scenarijuose.
## Globalūs nustatymai ir išplėstinė papildomų agentų konfigūracija
Be individualių pasirinktinių agentų apibrėžimų, Codex siūlo globalius konfigūracijos nustatymus, skirtus valdyti bendrą papildomų agentų darbo eigų elgesį. Šie nustatymai paprastai yra jūsų pagrindinio konfigūracijos failo `[agents]` skiltyje, suteikiant centralizuotą resursų paskirstymo ir veikimo parametrų valdymą.
Štai pagrindinių globalių papildomų agentų nustatymų apžvalga:
| Laukas | Tipas | Privalomas | Tikslas |
| :--------------------------- | :------ | :--------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `agents.max_threads` | skaičius | Ne | Ribojamas vienu metu atidarytų agentų gijų skaičius. Numatytasis '6', jei nenustatyta. |
| `agents.max_depth` | skaičius | Ne | Ribojamas sugeneruotų agentų įdėjimo gylis (šakninė sesija prasideda nuo 0). Numatytasis '1'. Apsaugo nuo rekursinio delegavimo už tiesioginių vaikų, siekiant valdyti ženklų naudojimą ir delsą. |
| `agents.job_max_runtime_seconds` | skaičius | Ne | Nustato numatytąjį laiko limitą vienam darbuotojui 'spawn_agents_on_csv' užduotyse. Jei nenustatyta, numatytasis '1800' sekundžių (30 minučių). |
Nustatymas `agents.max_threads`, kurio numatytoji reikšmė yra `6`, apsaugo nuo per didelio resursų eikvojimo, ribodamas vienu metu galinčių veikti papildomų agentų skaičių. Nustatymas `agents.max_depth`, kurio numatytoji reikšmė yra `1`, yra ypač svarbus. Nors gilesnis įdėjimas gali atrodyti patrauklus sudėtingam delegavimui, šios reikšmės padidinimas gali žymiai padidinti ženklų naudojimą, delsą ir vietinių resursų eikvojimą dėl pakartotinio išsišakojimo. Paprastai rekomenduojama išlaikyti numatytąją reikšmę, nebent konkretus rekursinio delegavimo modelis yra absoliučiai būtinas ir kruopščiai valdomas.
Pasirinktiniai agentų failai taip pat gali apimti kitus palaikomus `config.toml` raktus, išplečiant jų konfigūravimo galimybes ne tik privalomiems laukams. Šis modulinis ir sluoksniuotas konfigūravimo metodas užtikrina, kad kūrėjai turėtų tikslų savo DI agentų valdymą, leidžiantį jiems optimizuoti našumą, kaštus ir saugumą, pritaikytus konkretiems jų kūrimo poreikiams. Supratę ir išnaudoję šias galingas papildomų agentų galimybes, kūrėjai gali peržengti DI pagalbinio programavimo ribas ir žymiai pagerinti savo kūrimo darbo eigą.
Originalus šaltinis
https://developers.openai.com/codex/subagents/Dažniausiai užduodami klausimai
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ūkite informuoti
Gaukite naujausias AI naujienas el. paštu.