mirror of
https://github.com/crewAIInc/crewAI.git
synced 2026-07-05 06:59:23 +00:00
a237ebabba
* feat: adopt directory-based docs versioning with Edge channel Switch docs.crewai.com from navigation-only versioning (every version selector entry rendered the same docs/<lang>/* source files) to Mintlify's directory-based versioning so each version selector entry renders its own snapshot. Add an "Edge" channel under docs/edge/<lang>/* that always reflects main HEAD for unreleased work, eliminating pre-release leakage onto frozen release labels. External links to canonical /<lang>/* URLs are preserved via wildcard redirects that always land on the current default version. Layout: - docs/edge/<lang>/* rolling source (you edit here) - docs/edge/enterprise-api.*.yaml - docs/v<X.Y.Z>/<lang>/* frozen, immutable snapshots - docs/v<X.Y.Z>/enterprise-api.*.yaml - docs/images/ shared, append-only - docs/docs.json nav + redirects URLs follow the Mintlify-idiomatic shape: /edge/<lang>/<page> for Edge, /v<X.Y.Z>/<lang>/<page> for every frozen snapshot. The wildcard redirects /<lang>/:slug* -> /<default>/<lang>/:slug* keep stale links working, and every freeze rewrites them (plus all per-section/per-page redirects) so destinations always resolve to the current default without depending on a second redirect hop. Release flow integration (devtools release): - New module crewai_devtools.docs_versioning.freeze() materialises docs/v<X.Y.Z>/ from docs/edge/, rewrites openapi: refs inside the snapshot, inserts the version into every language block in docs.json, and refreshes all redirect destinations. - _update_docs_and_create_pr() in cli.py now calls that freeze during Phase 2 of devtools release. Edge changelogs are updated first (so the snapshot freeze picks them up), then the snapshot is staged alongside docs.json, branched as docs/freeze-v<X.Y.Z>, and the PR is titled [docs-freeze] docs: snapshot and changelog for v<X.Y.Z> — the title prefix the new CI guard reads. - The PR still gates tag, GitHub release, PyPI publish, and the enterprise release as before; no new PRs are added. - Pre-releases (1.X.YaN, 1.X.YbN, ...) skip the snapshot — they ride Edge — and the docs PR title omits the [docs-freeze] prefix. - docs_check (AI-generated docs scaffolding) writes to docs/edge/<lang>/* so newly-generated unreleased docs land in Edge and never accidentally touch a frozen snapshot. Migration scripts (one-shot): - scripts/docs/freeze_historical_versions.py reconstructs all 16 historical snapshots (v1.10.0 .. v1.14.7) from git tags via git archive | tar, rewriting openapi: MDX refs so each snapshot reads its own enterprise-api YAML rather than the live one. - scripts/docs/prefix_version_paths.py one-shot-migrates docs.json: rewrites every page path in 16 versioned blocks to point under docs/v<X.Y.Z>/, inserts a new Edge entry per language, tags v1.14.7 as Latest (default), prunes pages whose target file doesn't exist in the snapshot (e.g. docs/ar/ didn't exist before v1.12.0), and writes the wildcard + per-section redirects. - scripts/docs/freeze_current_edge.py is now a thin CLI wrapper around docs_versioning.freeze for manual one-off freezes (e.g. retroactively snapshotting a forgotten release). CI guards (.github/workflows/docs-snapshots.yml): - Frozen snapshots under docs/v[0-9]*/ are immutable; only PRs whose title contains [docs-freeze] (i.e. release-cut PRs generated by devtools release or the manual wrapper) may modify them. - Images under docs/images/ are append-only since snapshots share a single image directory. Deleting or renaming an image breaks every historical snapshot that still references it. Restored docs/images/crewai-otel-export.png from PR #3673; it was deleted in PR #4908 but v1.10.0 / v1.10.1 snapshots still reference it. Restoring instead of editing the snapshots preserves historical rendering fidelity and validates the new append-only rule retroactively. Tests: - lib/devtools/tests/test_docs_versioning.py covers the freeze: file copy, openapi rewrite, version insertion, default demotion, redirect upserts, per-section redirect rewriting, idempotency, and invalid inputs. Verified locally with mintlify broken-links: 0 broken links across the full site (Edge + 16 frozen versions, 4 locales). AGENTS.md (repo root) is the contributor guide for the new model; RELEASING.md is the release-cut runbook; README's Contribution section links to both. Co-authored-by: Cursor <cursoragent@cursor.com> * style: resolve linter issues --------- Co-authored-by: Cursor <cursoragent@cursor.com>
153 lines
12 KiB
Plaintext
153 lines
12 KiB
Plaintext
---
|
|
title: الأسئلة الشائعة
|
|
description: "الأسئلة المتكررة حول CrewAI AMP"
|
|
icon: "circle-question"
|
|
mode: "wide"
|
|
---
|
|
|
|
<AccordionGroup>
|
|
<Accordion title="كيف يتم التعامل مع تنفيذ المهام في العملية الهرمية؟">
|
|
في العملية الهرمية، يتم إنشاء وكيل مدير تلقائيًا ينسق سير العمل، ويفوض المهام ويتحقق من النتائج لتنفيذ مبسط وفعال. يستخدم وكيل المدير الأدوات لتسهيل تفويض المهام وتنفيذها بواسطة الوكلاء تحت إشراف المدير. يُعد نموذج اللغة الخاص بالمدير (LLM) أساسيًا للعملية الهرمية ويجب إعداده بشكل صحيح لضمان العمل السليم.
|
|
</Accordion>
|
|
|
|
<Accordion title="أين يمكنني الحصول على أحدث توثيق لـ CrewAI؟">
|
|
يتوفر أحدث توثيق لـ CrewAI على موقع التوثيق الرسمي: https://docs.crewai.com/
|
|
<Card href="https://docs.crewai.com/" icon="books">توثيق CrewAI</Card>
|
|
</Accordion>
|
|
|
|
<Accordion title="ما الاختلافات الرئيسية بين العمليات الهرمية والتسلسلية في CrewAI؟">
|
|
#### العملية الهرمية:
|
|
- يتم تفويض المهام وتنفيذها بناءً على سلسلة قيادة منظمة
|
|
- يجب تحديد نموذج لغة المدير (`manager_llm`) لوكيل المدير
|
|
- يشرف وكيل المدير على تنفيذ المهام والتخطيط والتفويض والتحقق
|
|
- لا يتم تعيين المهام مسبقًا؛ يقوم المدير بتخصيص المهام للوكلاء بناءً على قدراتهم
|
|
|
|
#### العملية التسلسلية:
|
|
- يتم تنفيذ المهام واحدة تلو الأخرى، مما يضمن إكمال المهام بتقدم منظم
|
|
- يُستخدم مخرج مهمة واحدة كسياق للمهمة التالية
|
|
- يتبع تنفيذ المهام الترتيب المحدد مسبقًا في قائمة المهام
|
|
|
|
#### أي عملية أفضل للمشاريع المعقدة؟
|
|
العملية الهرمية أنسب للمشاريع المعقدة لأنها تسمح بـ:
|
|
- **تخصيص وتفويض ديناميكي للمهام**: يمكن لوكيل المدير تعيين المهام بناءً على قدرات الوكلاء
|
|
- **التحقق والإشراف المنظم**: يراجع وكيل المدير مخرجات المهام ويضمن إكمالها
|
|
- **إدارة المهام المعقدة**: تحكم دقيق في توفر الأدوات على مستوى الوكيل
|
|
</Accordion>
|
|
|
|
<Accordion title="ما فوائد استخدام الذاكرة في إطار عمل CrewAI؟">
|
|
- **التعلم التكيفي**: تصبح الأطقم أكثر كفاءة بمرور الوقت، حيث تتكيف مع المعلومات الجديدة وتحسن نهجها في المهام
|
|
- **التخصيص المحسن**: تمكّن الذاكرة الوكلاء من تذكر تفضيلات المستخدم والتفاعلات السابقة، مما يؤدي إلى تجارب مخصصة
|
|
- **تحسين حل المشكلات**: يساعد الوصول إلى مخزن ذاكرة غني الوكلاء في اتخاذ قرارات أكثر استنارة، بالاعتماد على الدروس المستفادة والرؤى السياقية
|
|
</Accordion>
|
|
|
|
<Accordion title="ما الغرض من تعيين حد أقصى لعدد الطلبات في الدقيقة (RPM) للوكيل؟">
|
|
يمنع تعيين حد أقصى لعدد الطلبات في الدقيقة للوكيل من إجراء عدد كبير جدًا من الطلبات إلى الخدمات الخارجية، مما يساعد في تجنب حدود المعدل وتحسين الأداء.
|
|
</Accordion>
|
|
|
|
<Accordion title="ما الدور الذي يلعبه المدخل البشري في تنفيذ المهام داخل طاقم CrewAI؟">
|
|
يتيح المدخل البشري للوكلاء طلب معلومات إضافية أو توضيحات عند الحاجة. هذه الميزة ضرورية في عمليات صنع القرار المعقدة أو عندما يحتاج الوكلاء إلى مزيد من التفاصيل لإكمال مهمة بفعالية.
|
|
|
|
لدمج المدخل البشري في تنفيذ الوكيل، عيّن علامة `human_input` في تعريف المهمة. عند التفعيل، يطلب الوكيل من المستخدم إدخالًا قبل تقديم إجابته النهائية. يمكن أن يوفر هذا الإدخال سياقًا إضافيًا أو يوضح الغموض أو يتحقق من مخرجات الوكيل.
|
|
|
|
للحصول على إرشادات تنفيذ مفصلة، راجع [دليل الإنسان في الحلقة](/ar/enterprise/guides/human-in-the-loop).
|
|
</Accordion>
|
|
|
|
<Accordion title="ما خيارات التخصيص المتقدمة المتاحة لتكييف وتعزيز سلوك وقدرات الوكيل في CrewAI؟">
|
|
يوفر CrewAI مجموعة من خيارات التخصيص المتقدمة:
|
|
|
|
- **تخصيص نموذج اللغة**: يمكن تخصيص الوكلاء بنماذج لغوية محددة (`llm`) ونماذج لغوية لاستدعاء الدوال (`function_calling_llm`)
|
|
- **إعدادات الأداء والتصحيح**: ضبط أداء الوكيل ومراقبة عملياته
|
|
- **الوضع المفصل**: يتيح تسجيلًا مفصلًا لإجراءات الوكيل، مفيد للتصحيح والتحسين
|
|
- **حد RPM**: يحدد العدد الأقصى للطلبات في الدقيقة (`max_rpm`)
|
|
- **الحد الأقصى للتكرارات**: تسمح خاصية `max_iter` للمستخدمين بتحديد العدد الأقصى للتكرارات التي يمكن للوكيل تنفيذها لمهمة واحدة
|
|
- **التفويض والاستقلالية**: التحكم في قدرة الوكيل على التفويض أو طرح الأسئلة عبر خاصية `allow_delegation` (الافتراضي: True)
|
|
- **دمج المدخل البشري**: يمكن للوكلاء طلب معلومات إضافية أو توضيحات عند الحاجة
|
|
</Accordion>
|
|
|
|
<Accordion title="في أي سيناريوهات يكون المدخل البشري مفيدًا بشكل خاص في تنفيذ الوكيل؟">
|
|
يكون المدخل البشري مفيدًا بشكل خاص عندما:
|
|
- **يحتاج الوكلاء إلى معلومات إضافية أو توضيحات**: عندما يواجه الوكلاء غموضًا أو بيانات غير مكتملة
|
|
- **يحتاج الوكلاء إلى اتخاذ قرارات معقدة أو حساسة**: يمكن للمدخل البشري المساعدة في صنع القرارات الأخلاقية أو الدقيقة
|
|
- **الإشراف والتحقق من مخرجات الوكيل**: يمكن للمدخل البشري المساعدة في التحقق من النتائج ومنع الأخطاء
|
|
- **تخصيص سلوك الوكيل**: يمكن للمدخل البشري توفير ملاحظات لتحسين استجابات الوكيل بمرور الوقت
|
|
- **تحديد وحل الأخطاء أو القيود**: يساعد المدخل البشري في معالجة فجوات قدرات الوكيل
|
|
</Accordion>
|
|
|
|
<Accordion title="ما أنواع الذاكرة المختلفة المتاحة في CrewAI؟">
|
|
أنواع الذاكرة المختلفة المتاحة في CrewAI هي:
|
|
- **الذاكرة قصيرة المدى**: تخزين مؤقت للسياق الفوري
|
|
- **الذاكرة طويلة المدى**: تخزين دائم للأنماط والمعلومات المكتسبة
|
|
- **ذاكرة الكيانات**: تخزين مركز على كيانات محددة وخصائصها
|
|
- **الذاكرة السياقية**: ذاكرة تحافظ على السياق عبر التفاعلات
|
|
|
|
تعرف على المزيد حول أنواع الذاكرة المختلفة:
|
|
<Card href="https://docs.crewai.com/concepts/memory" icon="brain">ذاكرة CrewAI</Card>
|
|
</Accordion>
|
|
|
|
<Accordion title="كيف أستخدم Output Pydantic في مهمة؟">
|
|
لاستخدام Output Pydantic في مهمة، تحتاج إلى تعريف المخرج المتوقع للمهمة كنموذج Pydantic. إليك مثال سريع:
|
|
|
|
<Steps>
|
|
<Step title="تعريف نموذج Pydantic">
|
|
```python
|
|
from pydantic import BaseModel
|
|
|
|
class User(BaseModel):
|
|
name: str
|
|
age: int
|
|
```
|
|
</Step>
|
|
|
|
<Step title="إنشاء مهمة مع Output Pydantic">
|
|
```python
|
|
from crewai import Task, Crew, Agent
|
|
from my_models import User
|
|
|
|
task = Task(
|
|
description="Create a user with the provided name and age",
|
|
expected_output=User, # This is the Pydantic model
|
|
agent=agent,
|
|
tools=[tool1, tool2]
|
|
)
|
|
```
|
|
</Step>
|
|
|
|
<Step title="تعيين خاصية output_pydantic في الوكيل">
|
|
```python
|
|
from crewai import Agent
|
|
from my_models import User
|
|
|
|
agent = Agent(
|
|
role='User Creator',
|
|
goal='Create users',
|
|
backstory='I am skilled in creating user accounts',
|
|
tools=[tool1, tool2],
|
|
output_pydantic=User
|
|
)
|
|
```
|
|
</Step>
|
|
</Steps>
|
|
|
|
إليك درسًا تعليميًا حول كيفية الحصول على مخرجات منظمة بشكل متسق من وكلائك:
|
|
<iframe
|
|
className="w-full aspect-video rounded-xl"
|
|
src="https://www.youtube.com/embed/dNpKQk5uxHw"
|
|
title="المخرجات المنظمة في CrewAI"
|
|
frameBorder="0"
|
|
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
|
|
allowFullScreen
|
|
></iframe>
|
|
</Accordion>
|
|
|
|
<Accordion title="كيف يمكنني إنشاء أدوات مخصصة لوكلاء CrewAI؟">
|
|
يمكنك إنشاء أدوات مخصصة عن طريق إنشاء فئة فرعية من فئة `BaseTool` المقدمة من CrewAI أو باستخدام مُزخرف الأداة (tool decorator). ينطوي إنشاء الفئة الفرعية على تعريف فئة جديدة ترث من `BaseTool`، مع تحديد الاسم والوصف وطريقة `_run` للمنطق التشغيلي. يتيح لك مُزخرف الأداة إنشاء كائن `Tool` مباشرة مع الخصائص المطلوبة والمنطق الوظيفي.
|
|
|
|
<Card href="/ar/learn/create-custom-tools" icon="code">دليل أدوات CrewAI</Card>
|
|
</Accordion>
|
|
|
|
<Accordion title="كيف يمكنك التحكم في العدد الأقصى للطلبات في الدقيقة التي يمكن للطاقم بأكمله تنفيذها؟">
|
|
تحدد خاصية `max_rpm` العدد الأقصى للطلبات في الدقيقة التي يمكن للطاقم تنفيذها لتجنب حدود المعدل، وستتجاوز إعدادات `max_rpm` الفردية للوكلاء إذا قمت بتعيينها.
|
|
</Accordion>
|
|
|
|
</AccordionGroup>
|