Jag skulle vilja granska följande punkter på den aktuella PR (denna gren kontra huvudgren). Skapa en agent per punkt, vänta på att alla ska bli klara, och sammanfatta resultatet för varje punkt.
- Säkerhetsfråga
- Kodkvalitet
- Buggar
- Race conditions
- Testflakyhet
- Kodens underhållbarhet
I detta scenario skulle Codex sannolikt starta sex distinkta underagenter, var och en specialiserad på en av de listade granskningspunkterna. Efter att varje agent slutfört sin analys skulle Codex sammanställa resultaten till en enda, strukturerad rapport, som erbjuder en helhetsöversikt över pull-förfrågan. Detta exemplifierar den effektivitet som uppnås genom att fördela arbetsbördan bland specialiserade AI-enheter.
## Hantera och säkra ditt underagentekosystem
Effektiv hantering och robust säkerhet är nyckelfaktorer att beakta när man arbetar med underagenter. Codex tillhandahåller verktyg och mekanismer för att övervaka underagentaktiviteter och säkerställa säker drift inom deras sandlådemiljöer.
I interaktiva CLI-sessioner kan utvecklare använda kommandot `/agent` för att växla mellan aktiva agenttrådar, inspektera pågående processer eller styra en specifik underagent. Denna detaljerade kontroll möjliggör realtidsjusteringar och övervakning av individuella agentframsteg. Du kan också explicit be Codex att stoppa en körande underagent eller stänga slutförda trådar för att hantera resurser och fokus.
Säkerhet är av största vikt, och underagenter ärver den aktuella sandlådepolicyn från den huvudsakliga Codex-sessionen. Detta säkerställer att deras operationer följer fördefinierade säkerhets- och åtkomstregler. När godkännandeförfrågningar uppstår från inaktiva agenttrådar, särskilt i interaktiva CLI-sessioner, visar Codex intelligent dessa för användaren. Ett godkännandeöverlägg indikerar källtråden, vilket gör att du kan trycka på 'o' för att öppna och inspektera den tråden innan du fattar ett informerat beslut om att godkänna, avvisa eller svara på begäran. Detta förhindrar blinda godkännanden och bibehåller utvecklares översyn.
För icke-interaktiva flöden eller situationer där ett nytt godkännande inte kan visas, kommer varje åtgärd som kräver nytt godkännande automatiskt att misslyckas, med Codex som rapporterar felet tillbaka till det överordnade arbetsflödet. Denna felsäkra mekanism förhindrar obehöriga åtgärder i automatiserade sammanhang. Dessutom tillämpar Codex återigen den överordnade turens live runtime-åsidosättningar – som ändringar gjorda via `/approvals` eller `--yolo`-flaggan – till skapade barn, vilket säkerställer konsekventa säkerhetsställningar över agenthierarkin. För avancerade användare är det också möjligt att åsidosätta sandlådekonfigurationen för individuella [anpassade agenter](#definiera-anpassade-underagenter-för-skräddarsydda-uppgifter), vilket möjliggör finjusterad kontroll över deras behörigheter, till exempel genom att markera en agent som 'skrivskyddad'.
## Definiera anpassade underagenter för skräddarsydda uppgifter
Medan Codex tillhandahåller flera inbyggda agenter, såsom den `default` allmänna reserven, `worker` för exekveringsfokuserade uppgifter och `explorer` för läsintensiv kodbasutforskning, ligger den verkliga kraften i underagentsystemet i dess utbyggbarhet. Utvecklare kan definiera sina egna **anpassade agenter** för att hantera mycket specialiserade krav och skräddarsy AI-beteendet efter unika projektkontexter.
Anpassade agenter definieras med fristående TOML-filer. Dessa filer kan placeras i `~/.codex/agents/` för personliga agenter eller `.codex/agents/` för projektspecifika agenter. Varje TOML-fil fungerar i huvudsak som ett konfigurationslager, vilket gör att anpassade agenter kan åsidosätta inställningar som annars skulle ärvas från den överordnade sessionen. Detta inkluderar kritiska parametrar som den AI-modell som används, dess resonemangsinsats, sandlådeläge och till och med specifika färdighetskonfigurationer.
Varje fristående fil för anpassade agenter *måste* definiera följande fält:
* **`name`**: Agentens unika identifierare, som Codex använder när den skapas eller refereras.
* **`description`**: Mänskligt läsbar vägledning som hjälper Codex att förstå när denna agent ska användas.
* **`developer_instructions`**: Kärnan i instruktionerna som dikterar agentens beteende och operativa logik.
Valfria fält som `nickname_candidates`, `model`, `model_reasoning_effort`, `sandbox_mode`, `mcp_servers` och `skills.config` kan också inkluderas. Om dessa utelämnas ärvs inställningarna från den överordnade sessionen, vilket förenklar konfigurationen där standardvärden är acceptabla. För bästa praxis inom prompt-engineering, som direkt påverkar agentinstruktioner, se resurser som [Codex-promptguide](/sv/codex-prompting-guide).
Fältet `name` är den definitiva identifieraren för en anpassad agent. Även om det är vanligt och rekommenderat att matcha filnamnet med agentnamnet, är fältet `name` inom TOML-filen den slutgiltiga källan till sanning. Fältet `nickname_candidates` är ett användbart tillägg för användarupplevelsen, vilket gör att Codex kan tilldela mer läsbara visningsnamn till skapade agenter, vilket är särskilt användbart i komplexa scenarier med flera agenter.
## Globala inställningar och avancerad underagentkonfiguration
Utöver individuella anpassade agentdefinitioner erbjuder Codex globala konfigurationsinställningar för att hantera det övergripande beteendet hos underagenters arbetsflöden. Dessa inställningar finns vanligtvis under avsnittet `[agents]` i din huvudkonfigurationsfil och erbjuder centraliserad kontroll över resursallokering och driftsparametrar.
Här är en sammanställning av viktiga globala underagentinställningar:
| Fält | Typ | Obligatorisk | Syfte |
| :------------------------------ | :----- | :----------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `agents.max_threads` | number | Nej | Begränsar antalet samtidiga öppna agenttrådar. Standardvärdet är `6` om det inte är inställt. |
| `agents.max_depth` | number | Nej | Begränsar nästlingsdjupet för skapade agenter (rotsessionen startar på 0). Standardvärdet är `1`. Förhindrar rekursiv delegation bortom omedelbara underagenter för att hantera tokenanvändning och latens. |
| `agents.job_max_runtime_seconds`| number | Nej | Ställer in standardtidsgränsen per arbetare för `spawn_agents_on_csv`-jobb. Om det inte är inställt, är standardvärdet `1800` sekunder (30 minuter). |
Inställningen `agents.max_threads`, med standardvärdet `6`, utgör ett skydd mot överdriven resursförbrukning genom att begränsa antalet underagenter som kan arbeta samtidigt. Inställningen `agents.max_depth`, med sitt standardvärde `1`, är särskilt viktig. Även om djupare nästling kan verka tilltalande för komplex delegation, kan en ökning av detta värde leda till betydande ökningar i tokenanvändning, latens och lokal resursförbrukning på grund av upprepade utspridningar. Det rekommenderas generellt att behålla standardvärdet om inte ett specifikt rekursivt delegationsmönster är absolut nödvändigt och noggrant hanterat.
Anpassade agentfiler kan också inkludera andra stödde `config.toml`-nycklar, vilket utökar deras konfigurerbarhet utöver bara de obligatoriska fälten. Detta modulära och lagerindelade konfigurationssätt säkerställer att utvecklare har finjusterad kontroll över sina AI-agenter, vilket gör att de kan optimera för prestanda, kostnad och säkerhet anpassade efter deras specifika utvecklingsbehov. Genom att förstå och utnyttja dessa kraftfulla underagentfunktioner kan utvecklare tänja på gränserna för AI-assisterad kodning och avsevärt förbättra sina utvecklingsarbetsflöden.
Originalkälla
https://developers.openai.com/codex/subagents/Vanliga frågor
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.
Håll dig uppdaterad
Få de senaste AI-nyheterna i din inkorg.