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 یافتهها را در یک گزارش واحد و ساختاریافته جمعآوری میکند و یک نمای کلی جامع از درخواست پول (pull request) ارائه میدهد. این نمونهای از کارایی به دست آمده با توزیع حجم کار بین موجودیتهای هوش مصنوعی تخصصی است.
## مدیریت و ایمنسازی اکوسیستم زیرعامل شما
مدیریت مؤثر و امنیت قوی ملاحظات کلیدی هنگام کار با زیرعاملها هستند. Codex ابزارها و مکانیزمهایی را برای نظارت بر فعالیتهای زیرعامل و اطمینان از عملیات ایمن در محیطهای sandbox آنها فراهم میکند.
در جلسات CLI تعاملی، توسعهدهندگان میتوانند از دستور `/agent` برای جابجایی بین رشتههای عامل فعال، بازرسی فرآیندهای در حال انجام، یا هدایت یک زیرعامل خاص استفاده کنند. این کنترل دقیق امکان تنظیمات بلادرنگ و نظارت بر پیشرفت عاملهای فردی را فراهم میکند. شما همچنین میتوانید به صراحت از Codex بخواهید تا یک زیرعامل در حال اجرا را متوقف کند یا رشتههای تکمیل شده را ببندد تا منابع را مدیریت کرده و تمرکز را حفظ کند.
امنیت از اهمیت بالایی برخوردار است، و زیرعاملها سیاست sandbox فعلی را از جلسه اصلی Codex به ارث میبرند. این تضمین میکند که عملیات آنها به قوانین ایمنی و دسترسی از پیش تعریف شده پایبند است. هنگامی که درخواستهای تایید از رشتههای عامل غیرفعال، به ویژه در جلسات CLI تعاملی، مطرح میشوند، Codex به طور هوشمندانه آنها را به کاربر نشان میدهد. یک پوشش تایید، رشته منبع را نشان میدهد و به شما امکان میدهد 'o' را فشار دهید تا آن رشته را باز کرده و بازرسی کنید، قبل از اینکه تصمیم آگاهانهای برای تایید، رد یا پاسخ به درخواست بگیرید. این کار از تاییدهای کورکورانه جلوگیری میکند و نظارت توسعهدهنده را حفظ میکند.
برای جریانهای غیرتعاملی یا موقعیتهایی که نمیتوان یک تایید جدید را نمایش داد، هر عملی که نیاز به تایید جدید داشته باشد به طور خودکار شکست میخورد، و Codex خطا را به گردش کار والد گزارش میدهد. این مکانیسم ایمنی از اقدامات غیرمجاز در زمینههای خودکار جلوگیری میکند. علاوه بر این، Codex لغوهای زمان اجرای زنده چرخه والد – مانند تغییرات ایجاد شده از طریق `/approvals` یا پرچم `--yolo` – را به فرزندان ایجاد شده اعمال میکند و وضعیتهای امنیتی سازگار را در سراسر سلسلهمراتب عامل تضمین میکند. برای کاربران پیشرفته، همچنین امکان لغو پیکربندی sandbox برای [عوامل سفارشی](#تعریف-زیرعاملهای-سفارشی-برای-وظایف-خاص) فردی وجود دارد، که امکان کنترل دقیق بر مجوزهای آنها را فراهم میکند، برای مثال، با علامتگذاری یک عامل به عنوان 'فقط خواندنی'.
## تعریف زیرعاملهای سفارشی برای وظایف خاص
در حالی که Codex چندین عامل داخلی ارائه میدهد، مانند `default` برای جایگزین عمومی، `worker` برای وظایف متمرکز بر اجرا، و `explorer` برای کاوش پایگاه کد سنگین خواندنی، قدرت واقعی سیستم زیرعامل در قابلیت توسعه آن نهفته است. توسعهدهندگان میتوانند **عوامل سفارشی** خود را برای رفع نیازهای بسیار تخصصی تعریف کنند، و رفتار هوش مصنوعی را متناسب با زمینههای منحصر به فرد پروژه تنظیم کنند.
عوامل سفارشی با استفاده از فایلهای TOML مستقل تعریف میشوند. این فایلها میتوانند در `~/.codex/agents/` برای عوامل شخصی یا `.codex/agents/` برای عوامل محدود به پروژه قرار گیرند. هر فایل TOML اساساً به عنوان یک لایه پیکربندی عمل میکند و به عوامل سفارشی اجازه میدهد تنظیماتی را که در غیر این صورت از جلسه والد به ارث میرسید، لغو کنند. این شامل پارامترهای حیاتی مانند مدل هوش مصنوعی مورد استفاده، تلاش استدلال آن، حالت sandbox، و حتی پیکربندی مهارتهای خاص است.
هر فایل عامل سفارشی مستقل *باید* فیلدهای زیر را تعریف کند:
* **`name`**: شناسه منحصر به فرد عامل، که Codex هنگام ایجاد یا ارجاع به آن استفاده میکند.
* **`description`**: راهنمای قابل خواندن برای انسان که به Codex کمک میکند تا بفهمد چه زمانی این عامل را مستقر کند.
* **`developer_instructions`**: مجموعه اصلی دستورالعملها که رفتار و منطق عملیاتی عامل را دیکته میکنند.
فیلدهای اختیاری مانند `nickname_candidates`، `model`، `model_reasoning_effort`، `sandbox_mode`، `mcp_servers`، و `skills.config` نیز میتوانند گنجانده شوند. در صورت حذف، این تنظیمات از جلسه والد به ارث میرسند، که پیکربندی را در مواردی که پیشفرضها قابل قبول هستند، ساده میکند. برای بهترین روشها در مهندسی پرامپت، که مستقیماً بر دستورالعملهای عامل تأثیر میگذارد، به منابعی مانند [راهنمای پرامپت Codex](/fa/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` | عدد | خیر | مهلت زمانی پیشفرض برای هر worker را برای وظایف `spawn_agents_on_csv` تنظیم میکند. در صورت تنظیم نشدن، پیشفرض `1800` ثانیه (30 دقیقه) است. |
تنظیم `agents.max_threads`، با پیشفرض `6`، با محدود کردن تعداد زیرعاملهایی که میتوانند به طور همزمان عمل کنند، محافظی در برابر مصرف بیش از حد منابع فراهم میکند. تنظیم `agents.max_depth`، با پیشفرض `1`، از اهمیت ویژهای برخوردار است. در حالی که تو در تو شدن عمیقتر ممکن است برای واگذاری پیچیده جذاب به نظر برسد، افزایش این مقدار میتواند منجر به افزایش قابل توجهی در مصرف توکن، تأخیر و مصرف منابع محلی به دلیل گسترش مکرر شود. عموماً توصیه میشود که پیشفرض حفظ شود مگر اینکه یک الگوی واگذاری بازگشتی خاص کاملاً ضروری و با دقت مدیریت شده باشد.
فایلهای عامل سفارشی همچنین میتوانند کلیدهای `config.toml` پشتیبانی شده دیگر را شامل شوند، که قابلیت پیکربندی آنها را فراتر از فیلدهای اجباری گسترش میدهد. این رویکرد پیکربندی ماژولار و لایهای تضمین میکند که توسعهدهندگان کنترل دقیق بر عوامل هوش مصنوعی خود دارند و به آنها امکان میدهد عملکرد، هزینه و امنیت را متناسب با نیازهای توسعه خاص خود بهینه کنند. با درک و بهرهگیری از این قابلیتهای قدرتمند زیرعامل، توسعهدهندگان میتوانند مرزهای کدنویسی با کمک هوش مصنوعی را گسترش دهند و گردش کار توسعه خود را به طور قابل توجهی بهبود بخشند.
سوالات متداول
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.
بهروز بمانید
آخرین اخبار هوش مصنوعی را در ایمیل خود دریافت کنید.