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 الرئيسية. وهذا يضمن أن عملياتهم تلتزم بقواعد الأمان والوصول المحددة مسبقًا. عندما تنشأ طلبات الموافقة من سلاسل وكلاء غير نشطة، خاصة في جلسات واجهة سطر الأوامر التفاعلية، يعرضها 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](/ar/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.
ابقَ على اطلاع
احصل على آخر أخبار الذكاء الاصطناعي في بريدك.