Flows emit a Rich console message when they start ('Flow started with
ID: …') but produce no further log line until the next significant
event. When a flow appears to hang, this makes it hard to tell which
@start/@listen method is currently running.
Add a single INFO log at the entry of _execute_method that surfaces
the active method name. This works for both @start methods and
listeners since both paths funnel through _execute_method.
Adds typed containers for wire payloads, literal aliases for HTTP method
and log type, and Ffnal markers on resource constants. Updates
upstream returns in project_utils.py and deploy/main.py to match
the new contracts.
## Overview
Prettier-inserted bare `{" "}` lines between sibling `<Step>` elements caused Mintlify's `<Steps>` to crash with "Cannot read properties of undefined (reading 'stepNumber')", leaving the page body blank.
### Affected pages (en/ar/ko/pt-BR):
- enterprise/guides/enable-crew-studio
- learn/llm-selection-guide
* fix(docs/pt-BR): replace untranslated code block placeholders
Replace all `# (O código não é traduzido)` and `# código não traduzido`
placeholder comments in the PT-BR docs with the actual code from the
English source files.
Files fixed:
- docs/pt-BR/concepts/flows.mdx (~15 placeholders → real code)
- docs/pt-BR/guides/flows/mastering-flow-state.mdx (~17 placeholders → real code)
Code itself is kept in English per i18n conventions. Inline # comments
within code blocks have been translated to Portuguese.
* fix(docs/pt-BR): address CodeRabbit review comments
- flows.mdx: add missing load_dotenv() call after imports
- mastering-flow-state.mdx: fix PersistentCounterFlow second-run example
to pass inputs={"id": flow1.state.id} to kickoff(), matching the
documented resume pattern; update comment accordingly
* Add Tavily Research and get Research
- Added tavily research with docs to crew AI
- Added tavily get research with docs to crew AI
* Update `tavily-python` installation instructions and adjust version constraints
- Changed installation command from `pip install` to `uv add` for `tavily-python` in multiple documentation files.
- Updated version constraint for `tavily-python` in `pyproject.toml` from `>=0.7.14` to `~=0.7.14`.
- Modified the `exclude-newer` date in `uv.lock` to `2026-04-23T07:00:00Z`.
* Add Tavily Research Tool documentation in multiple languages
- Introduced `TavilyResearchTool` documentation in English, Arabic, Korean, and Portuguese.
- Updated `docs.json` to include paths for the new documentation files.
- The `TavilyResearchTool` allows CrewAI agents to perform multi-step research tasks and generate cited reports using the Tavily Research API.
* Fix Tavily research CI failures
* added getResearchTool docs
- Added docs for getResearchTool
---------
Co-authored-by: lorenzejay <lorenzejaytech@gmail.com>
Co-authored-by: Evan Rimer <evan.rimer@tavily.com>
Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>
## Summary
- Add a new docs page at `docs/en/guides/flows/inputs-id-deprecation.mdx` that explains the deprecation of `inputs.id` as a `@persist` hydration mechanism and walks users through migrating to `restoreFromStateId` (available in CrewAI **v1.14.5 and later**).
- Wire the page into `docs.json` next to `mastering-flow-state` in all 13 version blocks across all 4 languages (52 nav inserts).
- Add translations for `ar`, `ko`, `pt-BR`
* fix(docs): restore missing code block in pt-BR first-flow guide
The pt-BR translation of the 'Build Your First Flow' guide had a
placeholder comment '# [CÓDIGO NÃO TRADUZIDO, MANTER COMO ESTÁ]'
instead of the actual Python code in Step 5. This restores the full
main.py code block from the English source, matching the original
since code should not be translated.
* Translate code comments to pt-BR in first-flow guide
Code comments in the tutorial should be in Portuguese for the pt-BR
audience, since they are part of the guide's educational content.
* docs: add OSS upgrade & crew-to-flow migration guide
* docs: add upgrading-crewai guide and installation note
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* docs: consolidate upgrade & migration guide into single page
Merge the broader root-level upgrade-crewai.mdx into the canonical
en/guides/migration/upgrading-crewai.mdx so there is one comprehensive
upgrade & migration page covering: project venv vs global CLI, why
crewai install alone won't bump versions, breaking changes, and the
Crew-to-Flow migration. Removes the orphaned root-level file (which
was not referenced in docs.json nav).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* docs: add pt-BR, ar, ko translations of upgrade/migration guide
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* docs: reduce upgrade guide scope to package upgrade + breaking changes only
* docs: soften intro tone — releases ship features, not breaking changes
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* fix: resolve CodeRabbit review comments
- Add space between Arabic conjunction and `uv.lock` code span (ar)
- Add explicit {#memory-embedder-config} anchors to localized headings
so in-page links resolve correctly (ar, ko, pt-BR, en)
Co-authored-by: Lucas Gomide <lucaslg200@gmail.com>
---------
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Co-authored-by: Lucas Gomide <lucaslg200@gmail.com>
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* chore(deps): use 3-day exclude-newer window
Aligns the root workspace with the per-package pyprojects, which
already use `exclude-newer = "3 days"`. The fixed 2026-04-27 cutoff
blocks legitimate dependency bumps (e.g. daytona ~=0.171 in #5740)
without adding meaningful protection — the relative window still
includes the security patches that motivated the original pin.
* fix(deps): bump gitpython and python-multipart for new advisories
- gitpython >=3.1.49 for GHSA-v87r-6q3f-2j67 (newline injection in
config_writer().set_value() enables RCE via core.hooksPath).
- python-multipart >=0.0.27 for GHSA-pp6c-gr5w-3c5g (DoS via
unbounded multipart part headers).
Both surfaced via pip-audit on this branch.
In `_execute_task_with_a2a` and its async variant, the try body
sets `task.output_pydantic = None` before returning an A2A
response. The finally block then checks
`if task.output_pydantic is not None` before restoring the
original value — but since it was just set to None, the condition
is always False and the original value is never restored. This
permanently mutates the Task object.
Remove the guard so `output_pydantic` is unconditionally restored,
matching the unconditional restoration of `description` and
`response_model` in the same block.
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
When a tool with result_as_answer=True raises an exception, the agent
was receiving result_as_answer=True and returning the error string as
the final answer. Now we set result_as_answer=False when an error event
is emitted, allowing the agent to reflect and retry.
FixescrewAIInc/crewAI#5156
---------
Co-authored-by: NIK-TIGER-BILL <nik.tiger.bill@github.com>
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
## Summary
- Reverts `b0e2fda` ("fix(flow): add execution_id separate from state.id", COR-48): removes `Flow.execution_id` and points `current_flow_id` / `current_flow_request_id` back at `flow_id` (i.e. `state.id`). The separate per-run tracking id was no longer the right abstraction once `restore_from_state_id` reshapes how `state.id` is assigned;
- Adds an optional `restore_from_state_id` kwarg to `Flow.kickoff` / `Flow.kickoff_async` that hydrates state from a previously-persisted flow's latest snapshot
- Reassigns `state.id` to a fresh value (or `inputs["id"]` if pinned) so the new run's `@persist` writes don't extend the source's history
- Existing `inputs["id"]` resume, `@persist`, and `from_checkpoint` paths are unchanged
## Problem
`@persist` only supports *resume* today: `kickoff(inputs={"id": <uuid>})` hydrates state and continues writing under the same `flow_uuid`. There's no way to **fork** — hydrate from a snapshot but persist under a separate key, leaving the source's history intact. This PR adds that.
| | `state.id` after kickoff | `@persist` writes land under |
|---|---|---|
| `inputs["id"]` (resume) | supplied id | supplied id (extends history) |
| `restore_from_state_id` (fork) | fresh id, or `inputs["id"]` if pinned | new id (source preserved) |
## Behavior
| `inputs.id` | `restore_from_state_id` | Effect |
|---|---|---|
| — | — | Fresh kickoff |
| set | — | Existing resume |
| — | UUID | Fork — new `state.id`, hydrated from source |
| set | UUID | Fork into a pinned `state.id`, hydrated from source |
- Source not found → silent fallback (mirrors existing resume)
- Both `from_checkpoint` and `restore_from_state_id` set → `ValueError`
- `restore_from_state_id=None` → byte-identical to current main
## Design
Fork hydration runs before the existing `inputs` block in `kickoff_async`. On a hit, it calls the same `_restore_state` primitive used by resume, then overwrites `state.id` with a fresh UUID (or `inputs["id"]`). A `fork_succeeded` flag gates the existing `inputs["id"]` path so we don't double-load. `_completed_methods` / `_is_execution_resuming` are intentionally untouched — skip-completed-methods remains the territory of `apply_checkpoint` and `from_pending`.
## Test plan
- [ ] `pytest tests/test_flow_persistence.py` — 5 new tests (four-row matrix, not-found fallback, default no-op, conflict raise) + 6 existing as regression
- [ ] `pytest tests/test_flow.py` — broader flow suite
- [ ] Manual end-to-end against an HITL `@persist` flow
* feat(crewai-tools): add highlights to ExaSearchTool, rename from EXASearchTool
- Add a highlights init param so agents can get token-efficient excerpts instead of full pages
- Rename EXASearchTool to ExaSearchTool; keep EXASearchTool as a deprecated alias so existing imports keep working
- Update the docs and example to use highlights as the recommended option
- Add a small note that says Exa is the fastest and most accurate web search API
- Add tests for the new highlights param and the deprecation alias
* fix(crewai-tools): import order and module-level Exa for tests
- Reorder std-lib imports so ruff is happy with force-sort-within-sections.
- Import Exa at module level (with a fallback) so the existing test mocks resolve.
The lazy install prompt still works if exa_py is missing.
- Allow content and summary to be a dict, matching highlights.
- Trim test file to the cases this PR introduces (highlights param and the
EXASearchTool deprecation alias). Existing init-shape tests stay.
Co-Authored-By: ishan <ishan@exa.ai>
* chore(crewai-tools): drop self-explanatory comment on schema alias
Co-Authored-By: ishan <ishan@exa.ai>
* docs(crewai-tools): default highlights to True, drop summary from examples
Co-Authored-By: ishan <ishan@exa.ai>
* docs(crewai-tools): simplify highlights examples to highlights=True
Co-Authored-By: ishan <ishan@exa.ai>
* feat(crewai-tools): add x-exa-integration header for usage tracking
Co-Authored-By: ishan <ishan@exa.ai>
* docs(crewai-tools): add Exa MCP section and resources links
Co-Authored-By: ishan <ishan@exa.ai>
---------
Co-authored-by: ishan <ishan@exa.ai>
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>
* feat(azure): forward credential_scopes to Azure AI Inference client
Adds a credential_scopes field to the native Azure AI Inference
provider and a matching AZURE_CREDENTIAL_SCOPES env var
(comma-separated). The value is forwarded to ChatCompletionsClient /
AsyncChatCompletionsClient when set, letting keyless / Entra-based
callers target a specific Azure AD audience (e.g.
https://cognitiveservices.azure.com/.default) without subclassing the
provider. Matches the upstream azure.ai.inference SDK kwarg of the
same name.
Lazy build re-reads the env var so an LLM constructed at module
import (before deployment env vars are set) still picks up scopes —
same pattern as the existing AZURE_API_KEY / AZURE_ENDPOINT lazy
reads. to_config_dict round-trips the field.
* refactor(azure): tighten credential_scopes env handling
Address review feedback:
- Move os.getenv into the helper so AZURE_CREDENTIAL_SCOPES appears once
- Match the surrounding api_key/endpoint `or` style in the validator
- Drop the list() defensive copy in to_config_dict — every other field
in that method (and the base class's `stop`) is assigned by reference
* feat(flow): add optional key param to @persist decorator
Allows users to specify which state attribute to use as the
persistence key instead of always defaulting to state.id.
Usage: @persist(key='conversation_id')
Falls back to state.id when key is not provided (no breaking change).
Raises ValueError if the specified key is missing or falsy on state.
* docs(flow): document @persist key parameter for custom persistence keys
* fix(flow): use explicit None check for persist key to avoid empty-string fallback
---------
Co-authored-by: iris-clawd <iris-clawd@anthropic.com>
Co-authored-by: iris-clawd <iris@crewai.com>
Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>
Document the new E2BExecTool, E2BPythonTool, and E2BFileTool — agent
tools that run shell commands, Python, and filesystem ops inside
isolated E2B remote sandboxes. Adds the page under tools/ai-ml/ and
wires it into the navigation in docs.json.
Co-authored-by: iris-clawd <iris@crewai.com>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
CrewAgentExecutor is reused across sequential tasks but invoke/ainvoke
only appended to self.messages and never reset self.iterations, so
task 2 inherited task 1's history and iteration count.
Adds docs for DaytonaExecTool, DaytonaPythonTool, and DaytonaFileTool
introduced in PR #5530. Covers installation, lifecycle modes, examples,
and full parameter reference. Registered in docs.json nav for all
languages and versions.
Co-authored-by: iris-clawd <iris@crewai.com>
* docs: add Vertex AI workload identity setup guide
Walks SaaS customers through configuring CrewAI AMP to authenticate to
Google Vertex AI via GCP Workload Identity Federation, eliminating the
need for long-lived service account keys.
* docs: restrict Vertex WI guide to v1.14.3+ navigation
The guide requires `crewai>=1.14.3`, so registering it under older
version snapshots is misleading. Keep the entry only in the v1.14.3
English nav.
* docs: clarify crewai-vertex SA name is an example
* docs: add You.com MCP integration documentation for crewAI
Add documentation pages for integrating You.com's remote MCP server
with crewAI agents, covering web search, research, and content
extraction tools via the MCP protocol.
Pages added:
- Overview with DSL and MCPServerAdapter integration approaches
- you-search: web/news search with advanced filtering
- you-research: multi-source research with cited answers
- you-contents: full page content extraction
- Security considerations (prompt injection, API key management)
Co-authored-by: factory-droid[bot] <138933559+factory-droid-oss@users.noreply.github.com>
* docs: add You.com MCP search, research, and content extraction guides
Add two documentation pages for integrating You.com's remote MCP server
with crewAI agents:
- search-research/youai-search.mdx: you-search (web/news search)
and you-research (synthesized cited answers) via DSL or MCPServerAdapter.
Includes free tier support (100 queries/day, no API key).
- web-scraping/youai-contents.mdx: you-contents (full page content
extraction) via MCPServerAdapter with schema patching helpers.
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
* fix: add tool_filter to DSL search agent in youai-contents combo example
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
---------
Co-authored-by: factory-droid[bot] <138933559+factory-droid-oss@users.noreply.github.com>
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>
* Add Tavily Research and get Research
- Added tavily research with docs to crew AI
- Added tavily get research with docs to crew AI
* Update `tavily-python` installation instructions and adjust version constraints
- Changed installation command from `pip install` to `uv add` for `tavily-python` in multiple documentation files.
- Updated version constraint for `tavily-python` in `pyproject.toml` from `>=0.7.14` to `~=0.7.14`.
- Modified the `exclude-newer` date in `uv.lock` to `2026-04-23T07:00:00Z`.
* Add Tavily Research Tool documentation in multiple languages
- Introduced `TavilyResearchTool` documentation in English, Arabic, Korean, and Portuguese.
- Updated `docs.json` to include paths for the new documentation files.
- The `TavilyResearchTool` allows CrewAI agents to perform multi-step research tasks and generate cited reports using the Tavily Research API.
* Fix Tavily research CI failures
---------
Co-authored-by: lorenzejay <lorenzejaytech@gmail.com>
Co-authored-by: Evan Rimer <evan.rimer@tavily.com>
Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>
GitHub doesn't expose repo secrets to pull_request events from forks, so
${{ secrets.CREWAI_TOOL_SPECS_APP_ID }} resolves to an empty string and
tibdex/github-app-token@v2 errors with "Input required and not supplied:
app_id". The job also tries to push commits to the PR branch, which it
can't do on a fork regardless. Skip it for cross-repo PRs and keep it
for same-repo PRs and manual dispatch.
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* fix(flow): add execution_id separate from state.id (COR-48)
When a consumer passes `id` in `kickoff(inputs=...)`, that value
overwrites the flow's state.id — which was also being used as the
execution tracking identity for telemetry, tracing, and external
correlation. Two kickoffs sharing the same consumer id ended up
with the same tracking id, breaking any downstream system that
joins on it.
Introduces `Flow.execution_id`: a stable per-run identifier stored
as a `PrivateAttr` on the `Flow` model, exposed via property +
setter. It defaults to a fresh `uuid4` per instance, is never
touched by `inputs["id"]`, and can be assigned by outer systems
that already have an execution identity (e.g. a task id).
Switches the `current_flow_id` / `current_flow_request_id`
ContextVars to seed from `execution_id` so OTel spans emitted by
`FlowTrackable` children correlate on the stable tracking key.
`state.id` keeps its existing override semantics for
persistence/restore — consumers resuming a persisted flow via
`inputs["id"]` work exactly as before.
Adds tests covering default uniqueness per instance, immunity to
consumer `inputs["id"]`, context-var propagation, absence from
serialized state, and parity for dict-state flows.
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
Enables keyless Azure auth (OIDC Workload Identity Federation, Managed
Identity, Azure CLI, env-configured Service Principal) without any
crewAI-specific configuration. Customers whose deployment environment
already sets the standard azure-identity env vars get keyless auth for
free; the existing API-key path is unchanged.
Linear: FAC-40
* perf: defer MCP SDK import by fixing import path in agent/core.py
- Change 'from crewai.mcp import MCPServerConfig' to direct path
'from crewai.mcp.config import MCPServerConfig' to avoid triggering
mcp/__init__.py which eagerly loads the full mcp SDK (~300-400ms)
- Move MCPToolResolver import into get_mcp_tools() method body since
it's only used at runtime, not in type annotations
Saves ~200ms on 'import crewai' cold start.
* perf: lazy-load heavy MCP imports in mcp/__init__.py
MCPClient, MCPToolResolver, BaseTransport, and TransportType now use
__getattr__ lazy loading. These pull in the full mcp SDK (~400ms) but
are only needed at runtime when agents actually connect to MCP servers.
Lightweight config and filter types remain eagerly imported.
* perf: lazy-load all event type modules in events/__init__.py
Previously only agent_events were lazy-loaded; all other event type
modules (crew, flow, knowledge, llm, guardrail, logging, mcp, memory,
reasoning, skill, task, tool_usage) were eagerly imported at package
init time. Since events/__init__.py runs whenever ANY crewai.events.*
submodule is accessed, this loaded ~12 Pydantic model modules
unnecessarily.
Now all event types use the same __getattr__ lazy-loading pattern,
with TYPE_CHECKING imports preserved for IDE/type-checker support.
Saves ~550ms on 'import crewai' cold start.
* chore: remove UNKNOWN.egg-info from version control
* fix: add MCPToolResolver to TYPE_CHECKING imports
Fixes F821 (ruff) and name-defined (mypy) from lazy-loading the
MCP import. The type annotation on _mcp_resolver needs the name
available at type-check time.
* fix: bump lxml to >=5.4.0 for GHSA-vfmq-68hx-4jfw
lxml 5.3.2 has a known vulnerability. Bump to 5.4.0+ which
includes the fix (libxml2 2.13.8). The previous <5.4.0 pin
was for etree import issues that have since been resolved.
* fix: bump exclude-newer to 2026-04-22 for lxml 6.1.0 resolution
lxml 6.1.0 (GHSA fix) was released April 17 but the exclude-newer
date was set to April 17, missing it by timestamp. Bump to April 22.
* perf: add import time benchmark script
scripts/benchmark_import_time.py measures import crewai cold start
in fresh subprocesses. Supports --runs, --json (for CI), and
--threshold (fail if median exceeds N seconds).
The companion GitHub Action workflow needs to be pushed separately
(requires workflow scope).
* new action
* Potential fix for pull request finding 'CodeQL / Workflow does not contain permissions'
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
---------
Co-authored-by: Joao Moura <joaomdmoura@gmail.com>
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
* fix: merge execution metadata on duplicate batch initialization in TraceBatchManager
- Updated TraceBatchManager to merge execution metadata when a batch is initialized multiple times.
- Enhanced logging to reflect the merging of metadata during duplicate initialization.
- Added a test case to verify that execution metadata is correctly merged when initializing a batch after a lazy action.
* drop env events emitting from traces listener
* docs: add Build with AI page for coding agents and AI assistants
* docs: add Build with AI section to README
* docs: trim README Build with AI section to skills install only
* docs: add skills.sh reference link for npx install
* docs: add coding agent logos to Build with AI page
---------
Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>
Task fields that store class references (output_pydantic, output_json,
response_model, converter_cls) caused PydanticSerializationError when
RuntimeState serialized Crew entities during checkpointing. Serialize
to model_json_schema() and hydrate back via create_model_from_schema.
The guardrail retry path passed a Pydantic object directly to
TaskOutput.raw (which expects a string), causing a ValidationError
when output_pydantic is set and a guardrail fails. Mirror the
BaseModel check from the initial execution path into both sync
and async retry loops.
Closes#5544 (part 1)
* feat: add Daytona sandbox tools for enhanced functionality
- Introduced DaytonaBaseTool as a shared base for tools interacting with Daytona sandboxes.
- Added DaytonaExecTool for executing shell commands within a sandbox.
- Implemented DaytonaFileTool for managing files (read, write, delete, etc.) in a sandbox.
- Created DaytonaPythonTool for running Python code in a sandbox environment.
- Updated pyproject.toml to include Daytona as a dependency.
* chore: update tool specifications
* refactor: enhance error handling and logging in Daytona tools
- Added logging for best-effort cleanup failures in DaytonaBaseTool and DaytonaFileTool to aid in debugging.
- Improved error message for ImportError in DaytonaPythonTool to provide clearer guidance on SDK compatibility issues.
* linted
* addressing comment
* pinning version
* supporting append
* chore: update tool specifications
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Gemini thinking models (2.5+, 3.x) require thought_signature on
functionCall parts when sent back in conversation history. The streaming
path was extracting only name/args into plain dicts, losing the
signature. Return raw Part objects (matching the non-streaming path)
so the executor preserves them via raw_tool_call_parts.
Add fork classmethod, _restore_runtime, and _restore_event_scope
to BaseAgent. Fix from_checkpoint to set runtime state on the
event bus and restore event scopes. Store kickoff event ID across
checkpoints to skip re-emission on resume. Handle agent entity
type in checkpoint CLI and TUI.
The test_older_than tests in both JSON and SQLite prune suites used
hardcoded 2026-04-17 timestamps for the 'new' checkpoint. Once that
date passes, the checkpoint is older than 1 day and gets pruned along
with the 'old' one, causing assert count >= 1 to fail (count=0).
Use 2099-01-01 for the 'new' checkpoint so tests remain stable.
Co-authored-by: Joao Moura <joaomdmoura@gmail.com>
- Move _update_all_versions inside each dry-run branch so output order matches actual execution
- Switch to main before deleting the stale local branch in create_or_reset_branch
Add three new CLI subcommands to improve checkpoint UX:
- `crewai checkpoint resume [id]` skips the TUI and resumes from the
latest or specified checkpoint directly
- `crewai checkpoint diff <id1> <id2>` compares two checkpoints showing
changes in metadata, inputs, task status, and outputs
- `crewai checkpoint prune --keep N --older-than Xd` removes old
checkpoints from JSON dirs or SQLite databases
Also writes a resume hint to stderr after every checkpoint save so
users discover the command without needing to know it exists.
Concurrent streaming runs registered handlers on the singleton event bus
that received all LLMStreamChunkEvent emissions, causing chunks to fan
out across unrelated queues. Introduces a ContextVar-based stream scope
ID so each handler only accepts events from its own execution context.
Closes#5376
* fix: update broken enterprise link on installation page (OSS-36)
The 'Explore Enterprise Options' card on the installation page linked to
https://crewai.com/enterprise which returns a 404. Updated the href to
https://crewai.com/amp across all locales (en, pt-BR, ko, ar).
* fix: use HubSpot form link for enterprise options card
Updated per team feedback — the enterprise card should link to the
HubSpot demo form instead of crewai.com/amp.
---------
Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>
* feat: add template management commands for project templates
- Introduced command group to browse and install project templates.
- Added command to display available templates.
- Implemented command to install a selected template into the current directory.
- Created class to handle template-related operations, including fetching templates from GitHub and managing installations.
- Enhanced telemetry to track template installations.
* linted
* adressing comments
* comment addressed
Branch-aware checkpoint storage writes under subdirectories (e.g.
main/, fork/exp1/) but _list_json and _info_json_latest used flat
globs that missed them.
resolve_refs now returns type-preserving stubs instead of {} for
circular $refs, and create_model_from_schema catches JsonRefError
to fall back to lazy top-level-only inlining.
Forwarding strict and sanitizing tool schemas for strict mode causes
Bedrock Converse requests to hang until timeout. Drop strict forwarding
and schema sanitization from the Bedrock provider.
Add crewai deploy validate to check project structure, dependencies, imports, and env usage before deploy
Run validation automatically in deploy create and deploy push with skip flag support
Return structured findings with stable codes and hints
Add test coverage for validation scenarios
refactor: defer LLM client construction to first use
Move SDK client creation out of model initialization into lazy getters
Add _get_sync_client and _get_async_client across providers
Route all provider calls through lazy getters
Surface credential errors at first real invocation
refactor: standardize provider client access
Align async paths to use _get_async_client
Avoid client construction in lightweight config accessors
Simplify provider lifecycle and improve consistency
test: update suite for new behavior
Update tests for lazy initialization contract
Update CLI tests for validation flow and skip flag
Expand coverage for provider initialization paths
func_info.get('arguments', '{}') returns '{}' (truthy) when no
'function' wrapper exists (Bedrock format), causing the or-fallback
to tool_call.get('input', {}) to never execute. The actual Bedrock
arguments are silently discarded.
Remove the default so get('arguments') returns None (falsy) when
there's no function wrapper, allowing the or-chain to correctly
fall through to Bedrock's 'input' field.
Fixes#5275
Pydantic schemas intermittently fail strict tool-use on openai, anthropic,
and bedrock. All three reject nested objects missing additionalProperties:
false, and anthropic also rejects keywords like minLength and top-level
anyOf. Adds per-provider sanitizers that inline refs, close objects, mark
every property required, preserve nullable unions, and strip keywords each
grammar compiler rejects. Verified against real bedrock, anthropic, and
openai.
Substring checks like `'0.1' not in json_str` collided with timestamps
such as `2026-04-10T13:00:50.140557` on CI. Round-trip through
`model_validate_json` to verify structurally that the embedding field
is absent from the serialized output.
- Rewrite TUI with Tree widget showing branch/fork lineage
- Add Resume and Fork buttons in detail panel with Collapsible entities
- Show branch and parent_id in detail panel and CLI info output
- Auto-detect .checkpoints.db when default dir missing
- Append .db to location for SqliteProvider when no extension set
- Fix RuntimeState.from_checkpoint not setting provider/location
- Fork now writes initial checkpoint on new branch
- Add from_checkpoint, fork, and CLI docs to checkpointing.mdx
The OpenAI-format tool schema sets strict: true but this was dropped
during conversion to Anthropic/Bedrock formats, so neither provider
used constrained decoding. Without it, the model can return string
"None" instead of JSON null for nullable fields, causing Pydantic
validation failures.
Accept CheckpointConfig on Crew and Flow kickoff/kickoff_async/akickoff.
When restore_from is set, the entity resumes from that checkpoint.
When only config fields are set, checkpointing is enabled for the run.
Adds restore_from field (Path | str | None) to CheckpointConfig.
Write the crewAI package version into every checkpoint blob. On restore,
run version-based migrations so older checkpoints can be transformed
forward to the current format. Adds crewai.utilities.version module.
* fix: harden NL2SQLTool — read-only by default, parameterized queries, query validation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: address CI lint failures and remove unused import
- Remove unused `sessionmaker` import from test_nl2sql_security.py
- Use `Self` return type on `_apply_env_override` (fixes UP037/F821)
- Fix ruff errors auto-fixed in lib/crewai (UP007, etc.)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: expand _WRITE_COMMANDS and block multi-statement semicolon injection
- Add missing write commands: UPSERT, LOAD, COPY, VACUUM, ANALYZE,
ANALYSE, REINDEX, CLUSTER, REFRESH, COMMENT, SET, RESET
- _validate_query() now splits on ';' and validates each statement
independently; multi-statement queries are rejected outright in
read-only mode to prevent 'SELECT 1; DROP TABLE users' bypass
- Extract single-statement logic into _validate_statement() helper
- Add TestSemicolonInjection and TestExtendedWriteCommands test classes
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* ci: retrigger
* fix: use typing_extensions.Self for Python 3.10 compat
* chore: update tool specifications
* docs: document NL2SQLTool read-only default and DML configuration
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: close three NL2SQLTool security gaps (writable CTEs, EXPLAIN ANALYZE, multi-stmt commit)
- Remove WITH from _READ_ONLY_COMMANDS; scan CTE body for write keywords so
writable CTEs like `WITH d AS (DELETE …) SELECT …` are blocked in read-only mode.
- EXPLAIN ANALYZE/ANALYSE now resolves the underlying command; EXPLAIN ANALYZE DELETE
is treated as a write and blocked in read-only mode.
- execute_sql commit decision now checks ALL semicolon-separated statements so
a SELECT-first batch like `SELECT 1; DROP TABLE t` still triggers a commit
when allow_dml=True.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: handle parenthesized EXPLAIN options syntax; remove unused _seed_db
_validate_statement now strips parenthesized options from EXPLAIN (e.g.
EXPLAIN (ANALYZE) DELETE, EXPLAIN (ANALYZE, VERBOSE) DELETE) before
checking whether ANALYZE/ANALYSE is present — closing the bypass where
the options-list form was silently allowed in read-only mode.
Adds three new tests:
- EXPLAIN (ANALYZE) DELETE → blocked
- EXPLAIN (ANALYZE, VERBOSE) DELETE → blocked
- EXPLAIN (VERBOSE) SELECT → allowed
Also removes the unused _seed_db helper from test_nl2sql_security.py.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* chore: update tool specifications
* fix: smarter CTE write detection, fix commit logic for writable CTEs
- Replace naive token-set matching with positional AS() body inspection
to avoid false positives on column names like 'comment', 'set', 'reset'
- Fix execute_sql commit logic to detect writable CTEs (WITH + DELETE/INSERT)
not just top-level write commands
- Add tests for false positive cases and writable CTE commit behavior
- Format nl2sql_tool.py to pass ruff format check
* fix: catch write commands in CTE main query + handle whitespace in AS()
- WITH cte AS (SELECT 1) DELETE FROM users now correctly blocked
- AS followed by newline/tab/multi-space before ( now detected
- execute_sql commit logic updated for both cases
- 4 new tests
* fix: EXPLAIN ANALYZE VERBOSE handling, string literal paren bypass, commit logic for EXPLAIN ANALYZE
- EXPLAIN handler now consumes all known options (ANALYZE, ANALYSE, VERBOSE) before
extracting the real command, fixing 'EXPLAIN ANALYZE VERBOSE SELECT' being blocked
- Paren walker in _extract_main_query_after_cte now skips string literals, preventing
'WITH cte AS (SELECT '\''('\'' FROM t) DELETE FROM users' from bypassing detection
- _is_write_stmt in execute_sql now resolves EXPLAIN ANALYZE to underlying command
via _resolve_explain_command, ensuring session.commit() fires for write operations
- 10 new tests covering all three fixes
* fix: deduplicate EXPLAIN parsing, fix AS( regex in strings, block unknown CTE commands, bump langchain-core
- Refactor _validate_statement to use _resolve_explain_command (single source of truth)
- _iter_as_paren_matches skips string literals so 'AS (' in data doesn't confuse CTE detection
- Unknown commands after CTE definitions now blocked in read-only mode
- Bump langchain-core override to >=1.2.28 (GHSA-926x-3r5x-gfhw)
* fix: add return type annotation to _iter_as_paren_matches
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
resume_async() was missing trace infrastructure that kickoff_async()
sets up, causing flow_finished to never reach the platform after HITL
feedback. Add FlowStartedEvent emission to initialize the trace batch,
await event futures, finalize the trace batch, and guard with
suppress_flow_events.
Launch a Textual TUI via `crewai checkpoint` to browse and resume
from checkpoints. Uses run_async/akickoff for fully async execution.
Adds provider auto-detection from file magic bytes.
The spec generator previously used a hardcoded list of field names to
exclude from init_params_schema. Any new field or computed_field added
to BaseTool (like tool_type from 86ce54f) would silently leak into
tool.specs.json unless someone remembered to update that list.
Now _extract_init_params() dynamically computes BaseTool's fields at
import time via model_fields + model_computed_fields, so any future
additions to BaseTool are automatically excluded.
Fields from intermediate base classes (RagTool, BraveSearchToolBase,
SerpApiBaseTool) are correctly preserved since they're not on BaseTool.
TDD:
- RED: 3 new tests confirming BaseTool field leak, intermediate base
preservation, and future-proofing — all failed before the fix
- GREEN: Dynamic allowlist applied — all 10 tests pass
- Regenerated tool.specs.json (tool_type removed from all tools)
Wrapping sys.stdout and sys.stderr at import time with a
threading.Lock is not fork-safe and adds overhead to every
print call. litellm.suppress_debug_info already silences the
noisy output this was designed to filter.
Replace the Protocol with a BaseModel + ABC so providers serialize and
deserialize natively via pydantic. Each provider gets a Literal
provider_type field. CheckpointConfig.provider uses a discriminated
union so the correct provider class is reconstructed from checkpoint JSON.
* fix: add SSRF and path traversal protections
CVE-2026-2286: validate_url blocks non-http/https schemes, private
IPs, loopback, link-local, reserved addresses. Applied to 11 web tools.
CVE-2026-2285: validate_path confines file access to the working
directory. Applied to 7 file and directory tools.
* fix: drop unused assignment from validate_url call
* fix: DNS rebinding protection and allow_private flag
Rewrite validated URLs to use the resolved IP, preventing DNS rebinding
between validation and request time. SDK-based tools use pin_ip=False
since they manage their own HTTP clients. Add allow_private flag for
deployments that need internal network access.
* fix: unify security utilities and restore RAG chokepoint validation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* refactor: move validation to security/ package + address review comments
- Move safe_path.py to crewai_tools/security/; add safe_url.py re-export
- Keep utilities/safe_path.py as a backwards-compat shim
- Update all 21 import sites to use crewai_tools.security.safe_path
- files_compressor_tool: validate output_path (user-controlled)
- serper_scrape_website_tool: call validate_url() before building payload
- brightdata_unlocker: validate_url() already called without assignment (no-op fix)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* refactor: move validation to security/ package, keep utilities/ as compat shim
- security/safe_path.py is the canonical location for all validation
- utilities/safe_path.py re-exports for backward compatibility
- All tool imports already point to security.safe_path
- All review comments already addressed in prior commits
* fix: move validation outside try/except blocks, use correct directory validator
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: use resolved paths from validation to prevent symlink TOCTOU, remove unused safe_url.py
---------
Co-authored-by: Alex <alex@crewai.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: add path and URL validation to RAG tools
Add validation utilities to prevent unauthorized file reads and SSRF
when RAG tools accept LLM-controlled paths/URLs at runtime.
Changes:
- New crewai_tools.utilities.safe_path module with validate_file_path(),
validate_directory_path(), and validate_url()
- File paths validated against base directory (defaults to cwd).
Resolves symlinks and ../ traversal. Rejects escape attempts.
- URLs validated: file:// blocked entirely. HTTP/HTTPS resolves DNS
and blocks private/reserved IPs (10.x, 172.16-31.x, 192.168.x,
127.x, 169.254.x, 0.0.0.0, ::1, fc00::/7).
- Validation applied in RagTool.add() — catches all RAG search tools
(JSON, CSV, PDF, TXT, DOCX, MDX, Directory, etc.)
- Removed file:// scheme support from DataTypes.from_content()
- CREWAI_TOOLS_ALLOW_UNSAFE_PATHS=true env var for backward compat
- 27 tests covering traversal, symlinks, private IPs, cloud metadata,
IPv6, escape hatch, and valid paths/URLs
* fix: validate path/URL keyword args in RagTool.add()
The original patch validated positional *args but left all keyword
arguments (path=, file_path=, directory_path=, url=, website=,
github_url=, youtube_url=) unvalidated, providing a trivial bypass
for both path-traversal and SSRF checks.
Applies validate_file_path() to path/file_path/directory_path kwargs
and validate_url() to url/website/github_url/youtube_url kwargs before
they reach the adapter. Adds a regression-test file covering all eight
kwarg vectors plus the two existing positional-arg checks.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: address CodeQL and review comments on RAG path/URL validation
- Replace insecure tempfile.mktemp() with inline symlink target in test
- Remove unused 'target' variable and unused tempfile import
- Narrow broad except Exception: pass to only catch urlparse errors;
validate_url ValueError now propagates instead of being silently swallowed
- Fix ruff B904 (raise-without-from-inside-except) in safe_path.py
- Fix ruff B007 (unused loop variable 'family') in safe_path.py
- Use validate_directory_path in DirectorySearchTool.add() so the
public utility is exercised in production code
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* style: fix ruff format + remaining lint issues
* fix: resolve mypy type errors in RAG path/URL validation
- Cast sockaddr[0] to str() to satisfy mypy (socket.getaddrinfo returns
sockaddr where [0] is str but typed as str | int)
- Remove now-unnecessary `type: ignore[assignment]` and
`type: ignore[literal-required]` comments in rag_tool.py
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: unroll dynamic TypedDict key loops to satisfy mypy literal-required
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* test: allow tmp paths in RAG data-type tests via CREWAI_TOOLS_ALLOW_UNSAFE_PATHS
TemporaryDirectory creates files under /tmp/ which is outside CWD and is
correctly blocked by the new path validation. These tests exercise
data-type handling, not security, so add an autouse fixture that sets
CREWAI_TOOLS_ALLOW_UNSAFE_PATHS=true for the whole file. Path/URL
security is covered by test_rag_tool_path_validation.py.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* test: allow tmp paths in search-tool and rag_tool tests via CREWAI_TOOLS_ALLOW_UNSAFE_PATHS
test_search_tools.py has tests for TXTSearchTool, CSVSearchTool,
MDXSearchTool, JSONSearchTool, and DirectorySearchTool that create
files under /tmp/ via tempfile, which is outside CWD and correctly
blocked by the new path validation. rag_tool_test.py has one test
that calls tool.add() with a TemporaryDirectory path.
Add the same autouse allow_tmp_paths fixture used in
test_rag_tool_add_data_type.py. Security is covered separately by
test_rag_tool_path_validation.py.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* chore: update tool specifications
* docs: document CodeInterpreterTool removal and RAG path/URL validation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: address three review comments on path/URL validation
- safe_path._is_private_or_reserved: after unwrapping IPv4-mapped IPv6
to IPv4, only check against IPv4 networks to avoid TypeError when
comparing an IPv4Address against IPv6Network objects.
- safe_path.validate_file_path: handle filesystem-root base_dir ('/')
by not appending os.sep when the base already ends with a separator,
preventing the '//'-prefix bug.
- rag_tool.add: path-detection heuristic now checks for both '/' and
os.sep so forward-slash paths are caught on Windows as well as Unix.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: remove unused _BLOCKED_NETWORKS variable after IPv4/IPv6 split
* chore: update tool specifications
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* refactor: remove CodeInterpreterTool and deprecate code execution params
CodeInterpreterTool has been removed. The allow_code_execution and
code_execution_mode parameters on Agent are deprecated and will be
removed in v2.0. Use dedicated sandbox services (E2B, Modal, etc.)
for code execution needs.
Changes:
- Remove CodeInterpreterTool from crewai-tools (tool, Dockerfile, tests, imports)
- Remove docker dependency from crewai-tools
- Deprecate allow_code_execution and code_execution_mode on Agent
- get_code_execution_tools() returns empty list with deprecation warning
- _validate_docker_installation() is a no-op with deprecation warning
- Bedrock CodeInterpreter (AWS hosted) and OpenAI code_interpreter are NOT affected
* fix: remove empty code_interpreter imports and unused stdlib imports
- Remove empty `from code_interpreter_tool import ()` blocks in both
crewai_tools/__init__.py and tools/__init__.py that caused SyntaxError
after CodeInterpreterTool was removed
- Remove unused `shutil` and `subprocess` imports from agent/core.py
left over from the code execution params deprecation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: remove redundant _validate_docker_installation call and fix list type annotation
- Drop the _validate_docker_installation() call inside the allow_code_execution
block — it fired a second DeprecationWarning identical to the one emitted
just above it, making the warning fire twice.
- Annotate get_code_execution_tools() return type as list[Any] to satisfy mypy
(bare `list` fails the type-arg check introduced by this branch).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* ci: retrigger
* fix: update test_crew.py to remove CodeInterpreterTool references
CodeInterpreterTool was removed from crewai_tools. Update tests to
reflect that get_code_execution_tools() now returns an empty list.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* chore: update tool specifications
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* feat: add guardrail_type to distinguish between hallucination, function, and LLM
* feat: introduce guardrail_name into guardrail events
* feat: propagate guardrail type and name on guardrail completed event
* feat: remove unused LLMGuardrailFailedEvent
* fix: handle running event loop in LLMGuardrail._validate_output
When agent.kickoff() returns a coroutine inside an already-running event loop, asyncio.run() fails
* docs: update quickstart and installation guides for improved clarity
- Revised the quickstart guide to emphasize creating a Flow and running a single-agent crew that generates a report.
- Updated the installation documentation to reflect changes in the quickstart process and enhance user understanding.
* translations
- Pass RuntimeState through the event bus and enable entity auto-registration
- Introduce checkpointing API:
- .checkpoint(), .from_checkpoint(), and async checkpoint support
- Provider-based storage with BaseProvider and JsonProvider
- Mid-task resume and kickoff() integration
- Add EventRecord tracking and full event serialization with subtype preservation
- Enable checkpoint fidelity via llm_type and executor_type discriminators
- Refactor executor architecture:
- Convert executors, tools, prompts, and TokenProcess to BaseModel
- Introduce proper base classes with typed fields (CrewAgentExecutorMixin, BaseAgentExecutor)
- Add generic from_checkpoint with full LLM serialization
- Support executor back-references and resume-safe initialization
- Refactor runtime state system:
- Move RuntimeState into state/ module with async checkpoint support
- Add entity serialization improvements and JSON-safe round-tripping
- Implement event scope tracking and replay for accurate resume behavior
- Improve tool and schema handling:
- Make BaseTool fully serializable with JSON round-trip support
- Serialize args_schema via JSON schema and dynamically reconstruct models
- Add automatic subclass restoration via tool_type discriminator
- Enhance Flow checkpointing:
- Support restoring execution state and subclass-aware deserialization
- Performance improvements:
- Cache handler signature inspection
- Optimize event emission and metadata preparation
- General cleanup:
- Remove dead checkpoint payload structures
- Simplify entity registration and serialization logic
* fix: exclude embedding vector from MemoryRecord serialization
MemoryRecord.embedding (1536 floats for OpenAI embeddings) was included
in model_dump()/JSON serialization and repr. When recall results flow
to agents or get logged, these vectors burn tokens for zero value —
agents never need the raw embedding.
Added exclude=True and repr=False to the embedding field. The storage
layer accesses record.embedding directly (not via model_dump), so
persistence is unaffected.
* test: validate embedding excluded from serialization
Two tests:
1. MemoryRecord — model_dump, model_dump_json, and repr all exclude
embedding. Direct attribute access still works for storage layer.
2. MemoryMatch — nested record serialization also excludes embedding.
* fix: bump litellm to >=1.83.0 to address CVE-2026-35030
Bump litellm from <=1.82.6 to >=1.83.0 to fix JWT auth bypass via
OIDC cache key collision (CVE-2026-35030). Also widen devtools openai
pin from ~=1.83.0 to >=1.83.0,<3 to resolve the version conflict
(litellm 1.83.0 requires openai>=2.8.0).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: resolve mypy errors from litellm bump
- Remove unused type: ignore[import-untyped] on instructor import
- Remove all unused type: ignore[union-attr] comments (litellm types fixed)
- Add hasattr guard for tool_call.function — new litellm adds
ChatCompletionMessageCustomToolCall to the union which lacks .function
* fix: tighten litellm pin to ~=1.83.0 (patch-only bumps)
>=1.83.0,<2 is too wide — litellm has had breaking changes between
minors. ~=1.83.0 means >=1.83.0,<1.84.0 — gets CVE patches but won't
pull in breaking minor releases.
* ci: bump uv from 0.8.4 to 0.11.3
* fix: resolve mypy errors in openai completion from 2.x type changes
Use isinstance checks with concrete openai response types instead of
string comparisons for proper type narrowing. Update code interpreter
handling for outputs/OutputImage API changes in openai 2.x.
* fix: pre-cache tiktoken encoding before VCR intercepts requests
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Alex <alex@crewai.com>
Co-authored-by: Greyson LaLonde <greyson@crewai.com>
* chore: update uv.lock with new dependency groups and versioning adjustments
- Added a new revision number and updated resolution markers for Python version compatibility.
- Introduced a 'dev' dependency group with specific versions for various development tools.
- Updated sdist and wheels entries to include upload timestamps for better tracking.
- Adjusted numpy dependencies to specify versions based on Python version markers.
* feat: bump versions to 1.14.0a1
The `save_content` method wrote to `output/post.md` without ensuring the
`output/` directory exists, causing a FileNotFoundError when the directory
hasn't been created by another step.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* docs: add AMP Training Tab guide for enterprise deployments
* docs: add training guide translations for ar, ko, pt-BR
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Alex <alex@crewai.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* ci: add vulnerability scanning with pip-audit and Snyk
Add a new GitHub Actions workflow that runs on PRs, pushes to main, and weekly:
- pip-audit: scans all Python dependencies (direct + transitive) against
PyPI Advisory DB and OSV for known CVEs. Outputs JSON report as artifact
and posts results to the job summary.
- Snyk: optional enterprise-grade scanning (gated behind SNYK_ENABLED
repo variable and SNYK_TOKEN secret). Runs on high+ severity and
monitors main branch.
This addresses the need for automated pre-release vulnerability scanning
to catch dependency CVEs before cutting releases.
* ci: pin Snyk action to @v1 tag and remove continue-on-error
- Pin snyk/actions/python from @master to @v1 to prevent supply chain
risk from mutable branch references (matches convention of other
actions in the repo using versioned tags)
- Remove continue-on-error on the Snyk check step so high+ severity
vulnerabilities actually fail the build
* ci: fail build when pip-audit crashes without producing a report
If pip-audit exits abnormally without writing pip-audit-report.json,
the Display Results step now emits an error annotation and exits 1
instead of silently passing.
* ci: fix pip-audit failing on local packages
Replace --strict with --skip-editable to avoid pip-audit failing when
it encounters local/private packages (e.g. crewai-devtools) that are
not published on PyPI. The --skip-editable flag tells pip-audit to
skip packages installed in editable/development mode while still
auditing all published dependencies.
* fix: bump vulnerable dependencies and ignore unfixable CVEs
Dependency upgrades (via uv lock --upgrade-package):
- aiohttp 3.13.3 → 3.13.5 (fixes 10 CVEs)
- cryptography 46.0.5 → 46.0.6 (fixes CVE-2026-34073)
- pygments 2.19.2 → 2.20.0 (fixes CVE-2026-4539)
- onnx 1.20.1 → 1.21.0 (fixes 6 CVEs)
- couchbase 4.5.0 → 4.6.0 (fixes PYSEC-2023-235)
Temporarily ignored CVEs (cannot be fixed without upstream changes):
- CVE-2025-69872 (diskcache): no fix available, latest version
- CVE-2026-25645 (requests): needs 2.33.0, blocked by crewai-tools pin
- CVE-2026-27448/27459 (pyopenssl): needs 26.0.0, blocked by
snowflake-connector-python pin
- PYSEC-2023-235 (couchbase): advisory not yet updated for 4.6.0
* chore: remove accidentally committed egg-info files
* ci: remove Snyk job, pip-audit is sufficient
pip-audit covers Python dependency CVE scanning against PyPI Advisory DB
and OSV, which is all we need for pre-release checks. Snyk adds
complexity (account setup, token management) without meaningful
additional coverage for this use case.
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* fix: add tool repository credentials to crewai install
crewai install (uv sync) was failing with 401 Unauthorized when the
project depends on tools from a private package index (e.g. AMP tool
repository). The credentials were already injected for 'crewai run'
and 'crewai tool publish' but were missing from 'crewai install'.
Reads [tool.uv.sources] from pyproject.toml and injects UV_INDEX_*
credentials into the subprocess environment, matching the pattern
already used in run_crew.py.
* refactor: extract duplicated credential-building into utility function
Create build_env_with_all_tool_credentials() in utils.py to consolidate
the ~10-line block that reads [tool.uv.sources] from pyproject.toml and
calls build_env_with_tool_repository_credentials for each index.
This eliminates code duplication across install_crew.py, run_crew.py,
and cli.py, reducing the risk of inconsistent bug fixes.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: add debug logging for credential errors instead of silent swallow
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* fix: add tool repository credentials to uv build in tool publish
When running 'uv build' during tool publish, the build process now has access
to tool repository credentials. This mirrors the pattern used in run_crew.py,
ensuring private package indexes are properly authenticated during the build.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: add env kwarg to subprocess.run mock assertions in publish tests
The actual code passes env= to subprocess.run but the test assertions
were missing this parameter, causing assertion failures.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
security_context was being injected into tool arguments by
_add_fingerprint_metadata(), causing Pydantic validation errors
(extra_forbidden) on MCP and integration tools with strict schemas.
Move fingerprint data to the `config` parameter that invoke/ainvoke
already accept, keeping it available to consumers without polluting
the tool args namespace.
Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>
- Added telemetry spans for various skill events: discovery, loading, activation, and load failure.
- Introduced telemetry spans for memory events: save, query, and retrieval completion.
- Updated event listener to include new MCP tool execution and connection events with telemetry tracking.
* docs: Add coding agent skills demo video to getting started pages
Add Loom demo video embed showing how to build CrewAI agents and flows
using coding agent skills. Added to introduction, quickstart, and
installation pages across all languages (en, ko, pt-BR, ar).
* docs: update coding skills description with install instructions
Replace demo description text with actionable install copy across
all languages (en, ko, pt-BR, ar) in introduction, quickstart, and
installation pages.
Introduce the A2UI extension for declarative UI generation, including
support for both v0.8 and v0.9 protocol specs. Add A2UI content type
integration in A2A utils, along with schema definitions, catalog models,
and client extension improvements.
Enhance models with explicit defaults, field descriptions, and ConfigDict,
and improve typing and instance state handling across the extension.
Add schema conformance tests and align test structure.
Add and register A2UI documentation, including extension guide and
navigation updates.
* perf: reduce framework overhead for NVIDIA benchmarks
- Lazy initialize event bus thread pool and event loop on first emit()
instead of at import time (~200ms savings)
- Skip trace listener registration (50+ handlers) when tracing disabled
- Skip trace prompt in non-interactive contexts (isatty check) to avoid
20s timeout in CI/Docker/API servers
- Skip flush() when no events were emitted (avoids 30s timeout waste)
- Add _has_pending_events flag to track if any events were emitted
- Add _executor_initialized flag for lazy init double-checked locking
All existing behavior preserved when tracing IS enabled. No public APIs
changed - only conditional guards added.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: address PR review comments — tracing override, executor init order, stdin guard, unused import
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* style: fix ruff formatting in trace_listener.py and utils.py
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Iris Clawd <iris@crewai.com>
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
- Apps run locally (with CREWAI_PLATFORM_INTEGRATION_TOKEN env var), not remotely
- Apps auth is an integration token, not OAuth
- Updated comparison tables and card descriptions in en, pt-BR, ko, ar
* docs: add Agent Capabilities overview page and improve Skills docs
- New 'Agent Capabilities' page explaining all 5 extension types (Tools, MCPs, Apps, Skills, Knowledge) with comparison table and decision guide
- Rewrite Skills page with practical examples showing Skills + Tools patterns, common FAQ, and Skills vs Knowledge comparison
- Add cross-reference callout on Tools page linking to the capabilities overview
- Add agent-capabilities to Core Concepts navigation (after agents)
* docs: add pt-BR and ko translations for agent-capabilities and updated skills/tools
* docs: add Arabic (ar) translations for agent-capabilities and updated skills/tools
lancedb 0.30.1 dropped the win_amd64 wheel, breaking installation on
Windows. Pin to <0.30.1 so uv resolves to a version that still ships
Windows binaries.
* refactor: replace InstanceOf[T] with plain type annotations
InstanceOf[] is a Pydantic validation wrapper that adds runtime
isinstance checks. Plain type annotations are sufficient here since
the models already use arbitrary_types_allowed or the types are
BaseModel subclasses.
* refactor: convert BaseKnowledgeStorage to BaseModel
* fix: update tests for BaseKnowledgeStorage BaseModel conversion
* fix: correct embedder config structure in test
This commit cleans up the class by removing the and methods, which are no longer needed. The changes help streamline the code and improve maintainability.
GPT-5.x models reject the `stop` parameter at the API level with "Unsupported parameter: 'stop' is not supported with this model". This breaks CrewAI executions when routing through LiteLLM (e.g. via
OpenAI-compatible gateways like Asimov), because the LiteLLM fallback path always includes `stop` in the API request params.
The native OpenAI provider was unaffected because it never sends `stop` to the API — it applies stop words client-side via `_apply_stop_words()`. However, when the request goes through LiteLLM (custom endpoints, proxy gateways),
`stop` is sent as an API parameter and GPT-5.x rejects it.
Additionally, the existing retry logic that catches this error only matched the OpenAI API error format ("Unsupported parameter") but missed
LiteLLM's own pre-validation error format ("does not support parameters"), so the self-healing retry never triggered for LiteLLM-routed calls.
* Exporting tool's metadata to AMP - initial work
* Fix payload (nest under `tools` key)
* Remove debug message + code simplification
* Priting out detected tools
* Extract module name
* fix: address PR review feedback for tool metadata extraction
- Use sha256 instead of md5 for module name hashing (lint S324)
- Filter required list to match filtered properties in JSON schema
* fix: Use sha256 instead of md5 for module name hashing (lint S324)
- Add missing mocks to metadata extraction failure test
* style: fix ruff formatting
* fix: resolve mypy type errors in utils.py
* fix: address bot review feedback on tool metadata
- Use `is not None` instead of truthiness check so empty tools list
is sent to the API rather than being silently dropped as None
- Strip __init__ suffix from module path for tools in __init__.py files
- Extend _unwrap_schema to handle function-before, function-wrap, and
definitions wrapper types
* fix: capture env_vars declared with Field(default_factory=...)
When env_vars uses default_factory, pydantic stores a callable in the
schema instead of a static default value. Fall back to calling the
factory when no static default is present.
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
After PyPI publish, clones crewAIInc/crew_deployment_test, bumps the
crewai[tools] pin to the new version, regenerates uv.lock, and pushes
to main. Includes retry logic for CDN propagation delays.
- Add --skip-to-enterprise flag to resume just Phase 3 after a failure
- Add --prerelease=allow to uv sync for alpha/beta/rc versions
- Retry uv sync up to 10 times to handle PyPI CDN propagation delay
- Update pyproject.toml [project] version field (fixes apps/api version)
- Print PR URL after creating enterprise bump PR
- Add full feature permissions matrix (11 features × permission levels)
- Document Owner vs Member default permissions
- Add deployment guide: what permissions are needed to deploy from GitHub or Zip
- Document entity-level permissions (deployment permission types: run, traces, manage_settings, HITL, full_access)
- Document entity RBAC for env vars, LLM connections, and Git repositories
- Add common role patterns: Developer, Viewer/Stakeholder, Ops/Platform Admin
- Add quick-reference table for minimum deployment permissions
Addresses user feedback that RBAC was too restrictive and unclear:
members didn't know which permissions to configure for a developer profile.
* fix: preserve method return value as flow output for @human_feedback with emit
When a @human_feedback decorated method with emit= is the final method in a
flow (no downstream listeners triggered), the flow's final output was
incorrectly set to the collapsed outcome string (e.g., 'approved') instead
of the method's actual return value (e.g., a state dict).
Root cause: _process_feedback() returns the collapsed_outcome string when
emit is set, and this string was being stored as the method's result in
_method_outputs.
The fix:
1. In human_feedback.py: After _process_feedback, stash the real method_output
on the flow instance as _human_feedback_method_output when emit is set.
2. In flow.py: After appending a method result to _method_outputs, check if
_human_feedback_method_output is set. If so, replace the last entry with
the stashed real output and clear the stash.
This ensures:
- Routing still works correctly (collapsed outcome used for @listen matching)
- The flow's final result is the actual method return value
- If downstream listeners execute, their results become the final output
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* style: ruff format flow.py
* fix: use per-method dict stash for concurrency safety and None returns
Addresses review comments:
- Replace single flow-level slot with dict keyed by method name,
safe under concurrent @human_feedback+emit execution
- Dict key presence (not value) indicates stashed output,
correctly preserving None return values
- Added test for None return value preservation
---------
Co-authored-by: Joao Moura <joao@crewai.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* feat: add request_id to HumanFeedbackRequestedEvent
Allow platforms to attach a correlation identifier to human feedback requests so downstream consumers can deterministically match spans to their corresponding feedback records
* feat: add request_id to HumanFeedbackReceivedEvent for correlation
Without request_id on the received event, consumers cannot correlate
a feedback response back to its originating request. Both sides of the
request/response pair need the correlation identifier.
---------
Co-authored-by: Alex <alex@crewai.com>
- Delegate supports_function_calling() to parent (handles o1 models via OpenRouter)
- Guard empty env vars in base_url resolution
- Fix misleading comment about model validation rules
- Remove unused MagicMock import
- Use 'is not None' for env var restoration in tests
Co-authored-by: Joao Moura <joao@crewai.com>
## Summary
### Core fixes
<details>
<summary><b>Fix silent 404 cascade on trace event send</b></summary>
When `_initialize_backend_batch` failed, `trace_batch_id` was left populated with a client-generated UUID never registered server-side. All subsequent event sends hit a non-existent batch endpoint and returned 404. Now all three failure paths (None response, non-2xx status, exception) clear `trace_batch_id`.
</details>
<details>
<summary><b>Fix first-time deferred batch init silently skipped</b></summary>
First-time users have `is_tracing_enabled_in_context() = False` by design. This caused `_initialize_backend_batch` to return early without creating the batch, and `finalize_batch` to skip finalization (same guard). The first-time handler now passes `skip_context_check=True` to bypass both guards, calls `_finalize_backend_batch` directly, gates `backend_initialized` on actual success, checks `_send_events_to_backend` return status (marking batch as failed on 500), captures event count/duration/batch ID before they're consumed by send/finalize, and cleans up all singleton state via `_reset_batch_state()` on every exit path.
</details>
<details>
<summary><b>Sync <code>is_current_batch_ephemeral</code> on batch creation success</b></summary>
When the batch is successfully created on the server, `is_current_batch_ephemeral` is now synced with the actual `use_ephemeral` value used. This prevents endpoint mismatches where the batch was created on one endpoint but events and finalization were sent to a different one, resulting in 404.
</details>
<details>
<summary><b>Route <code>mark_trace_batch_as_failed</code> to correct endpoint for ephemeral batches</b></summary>
`mark_trace_batch_as_failed` always routed to the non-ephemeral endpoint (`/tracing/batches/{id}`), causing 404s when called on ephemeral batches — the same class of endpoint mismatch this PR aims to fix. Added `mark_ephemeral_trace_batch_as_failed` to `PlusAPI` and a `_mark_batch_as_failed` helper on `TraceBatchManager` that routes based on `is_current_batch_ephemeral`.
</details>
<details>
<summary><b>Gate <code>backend_initialized</code> on actual init success (non-first-time path)</b></summary>
On the non-first-time path, `backend_initialized` was set to `True` unconditionally after `_initialize_backend_batch` returned. With the new failure-path cleanup that clears `trace_batch_id`, this created an inconsistent state: `backend_initialized=True` + `trace_batch_id=None`. Now set via `self.trace_batch_id is not None`.
</details>
### Resilience improvements
<details>
<summary><b>Retry transient failures on batch creation</b></summary>
`_initialize_backend_batch` now retries up to 2 times with 200ms backoff on transient failures (None response, 5xx, network errors). Non-transient 4xx errors are not retried. The short backoff minimizes lock hold time on the non-first-time path where `_batch_ready_cv` is held.
</details>
<details>
<summary><b>Fall back to ephemeral on server auth rejection</b></summary>
When the non-ephemeral endpoint returns 401/403 (expired token, revoked credentials, key rotation), the client automatically switches to ephemeral tracing instead of losing traces. The fallback forwards `skip_context_check` and is guarded against infinite recursion — if ephemeral also fails, `trace_batch_id` is cleared normally.
</details>
<details>
<summary><b>Fix action-event race initializing batch as non-ephemeral</b></summary>
`_handle_action_event` called `batch_manager.initialize_batch()` directly, defaulting `use_ephemeral=False`. When a `DefaultEnvEvent` or `LLMCallStartedEvent` fired before `CrewKickoffStartedEvent` in the thread pool, the batch was locked in as non-ephemeral. Now routes through `_initialize_batch()` which computes `use_ephemeral` from `_check_authenticated()`.
</details>
<details>
<summary><b>Guard <code>_mark_batch_as_failed</code> against cascading network errors</b></summary>
When `_finalize_backend_batch` failed with a network error (e.g. `[Errno 54] Connection reset by peer`), the exception handler called `_mark_batch_as_failed` — which also makes an HTTP request on the same dead connection. That second failure was unhandled. Now wrapped in a try/except so it logs at debug level instead of propagating.
</details>
<details>
<summary><b>Design decision: first-time users always use ephemeral</b></summary>
First-time trace collection **always creates ephemeral batches**, regardless of authentication status. This is intentional:
1. **The first-time handler UX is built around ephemeral traces** — it displays an access code, a 24-hour expiry link, and opens the browser to the ephemeral trace viewer. Non-ephemeral batches don't produce these artifacts, so the handler would fall through to the "Local Traces Collected" fallback even when traces were successfully sent.
2. **The server handles account linking automatically** — `LinkEphemeralTracesJob` runs on user signup and migrates ephemeral traces to permanent records. Logged-in users can access their traces via their dashboard regardless.
3. **Checking auth during batch setup broke event collection** — moving `_check_authenticated()` into `_initialize_batch` caused the batch initialization to fail silently during the flow/crew start event handler, preventing all event collection. Keeping the first-time path fast and side-effect-free preserves event collection.
The auth check is deferred to the non-first-time path (second run onwards), where `is_tracing_enabled_in_context()` is `True` and the normal tracing pipeline handles everything — including the 401/403 ephemeral fallback.
</details>
### Manual tests
<details>
<summary><b>Matrix</b></summary>
| Scenario | First run | Second run |
|----------|-----------|------------|
| Logged out, fresh `.crewai_user.json` | Ephemeral trace created, URL returned | Ephemeral trace created, URL returned |
| Logged in, fresh `.crewai_user.json` | Ephemeral trace created, URL returned | Trace batch finalized, URL returned |
| Flow execution | Tested with `poem_flow` | Tested with `poem_flow` |
| Crew execution | Tested with `hitl_crew` | Tested with `hitl_crew` |
</details>
Fix: Add a remember_many() method to the MemoryScope class that delegates to self._memory.remember_many(...) with the scoped path, following the exact same pattern as the existing remember() method.
Problem: When you pass memory=memory.scope("/agent/...") to an Agent, CrewAI's internal code calls remember_many() after every task to persist results. But MemoryScope never implemented remember_many() — only the parent Memory class has it.
Symptom: [ERROR]: Failed to save kickoff result to memory: 'MemoryScope' object has no attribute 'remember_many' — memories are silently never saved after agent tasks.
When a method has both @listen and @human_feedback(emit=[...]),
the FlowMeta metaclass registered it as a router but only used
get_possible_return_constants() to detect paths. This fails for
@human_feedback methods since the paths come from the decorator's
emit param, not from return statements in the source code.
Now checks __router_paths__ first (set by @human_feedback), then
falls back to source code analysis for plain @router methods.
This was causing missing edges in the flow serializer output —
e.g. the whitepaper generator's review_infographic -> handle_cancelled,
send_slack_notification, classify_feedback edges were all missing.
Adds test: @listen + @human_feedback(emit=[...]) generates correct
router edges in serialized output.
Co-authored-by: Joao Moura <joao@crewai.com>
The litellm optional dependency had a wide upper bound (<3) that allowed
any future litellm release to be installed automatically. This means
breaking changes in new litellm versions could affect customers immediately.
Pins the upper bound to <=1.82.6 (current latest known-good version).
When newer litellm versions are tested and validated, bump this bound
explicitly.
* feat: add native OpenAI-compatible providers (OpenRouter, DeepSeek, Ollama, vLLM, Cerebras, Dashscope)
Add a data-driven OpenAI-compatible provider system that enables
native support for multiple third-party APIs that implement the
OpenAI API specification.
New providers:
- OpenRouter: 500+ models via openrouter.ai
- DeepSeek: deepseek-chat, deepseek-coder, deepseek-reasoner
- Ollama: local models (llama3, mistral, codellama, etc.)
- hosted_vllm: self-hosted vLLM servers
- Cerebras: ultra-fast inference
- Dashscope: Alibaba Qwen models (qwen-turbo, qwen-max, etc.)
Architecture:
- Single OpenAICompatibleCompletion class extends OpenAICompletion
- ProviderConfig dataclass stores per-provider settings
- Registry dict makes adding new providers a single config entry
- Handles provider-specific quirks (OpenRouter headers, Ollama
base URL normalization, optional API keys)
Usage:
LLM(model="deepseek/deepseek-chat")
LLM(model="ollama/llama3")
LLM(model="openrouter/anthropic/claude-3-opus")
LLM(model="llama3", provider="ollama")
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: add is_litellm=True to tests that test litellm-specific methods
Tests for _get_custom_llm_provider and _validate_call_params used
openrouter/ model prefix which now routes to native provider.
Added is_litellm=True to force litellm path since these test
litellm-specific internals.
---------
Co-authored-by: Joao Moura <joao@crewai.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
- Token counting: Make TokenCalcHandler standalone class that conditionally
inherits from litellm.CustomLogger when litellm is available, works as
plain object when not installed
- Callbacks: Guard set_callbacks() and set_env_callbacks() behind
LITELLM_AVAILABLE checks - these only affect the litellm fallback path,
native providers emit events via base_llm.py
- Feature detection: Guard supports_function_calling(), supports_stop_words(),
and _validate_call_params() behind LITELLM_AVAILABLE checks with sensible
defaults (True for function calling/stop words since all modern models
support them)
- Error types: Replace litellm.exceptions.ContextWindowExceededError catches
with pattern-based detection using LLMContextLengthExceededError._is_context_limit_error()
This decouples crewAI's internal infrastructure from litellm, allowing the
native providers (OpenAI, Anthropic, Azure, Bedrock, Gemini) to work without
litellm installed. The litellm fallback for niche providers still works when
litellm IS installed.
Co-authored-by: Joao Moura <joao@crewai.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Add `crewai logout` command that clears auth tokens and user settings.
Supports `--reset` flag to also restore all CLI settings to defaults.
Add missing type annotations to all CLI command functions, DeployCommand
and TriggersCommand __init__ methods, and create_flow to resolve all
mypy errors. Remove unused assignments of void telemetry return values.
introduce the agent skills standard for packaging reusable instructions that agents can discover and activate at runtime.
- skills defined via SKILL.md with yaml frontmatter and markdown body
- three-level progressive disclosure: metadata, instructions, resources
- filesystem discovery with directory name validation
- skill lifecycle events (discovery, loaded, activated, failed)
- crew-level skills resolved once and shared across agents
- skill context injected into both task execution and standalone kickoff
* feat: automatic root_scope for hierarchical memory isolation
Crews and flows now automatically scope their memories hierarchically.
The encoding flow's LLM-inferred scope becomes a sub-scope under the
structural root, preventing memory pollution across crews/agents.
Scope hierarchy:
/crew/{crew_name}/agent/{agent_role}/{llm-inferred}
/flow/{flow_name}/{llm-inferred}
Changes:
- Memory class: new root_scope field, passed through remember/remember_many
- EncodingFlow: prepends root_scope to resolved scope in both fast path
(Group A) and LLM path (Group C/D)
- Crew: auto-sets root_scope=/crew/{sanitized_name} on memory creation
- Agent executor: extends crew root with /agent/{sanitized_role} per save
- Flow: auto-sets root_scope=/flow/{sanitized_name} on memory creation
- New utils: sanitize_scope_name, normalize_scope_path, join_scope_paths
Backward compatible — no root_scope means no prefix (existing behavior).
Old memories at '/' remain accessible.
51 new tests, all existing tests pass.
* ci: retrigger tests
* fix: don't auto-set root_scope on user-provided Memory instances
When users pass their own Memory instance to a Crew (memory=mem),
respect their configuration — don't auto-set root_scope.
Auto-scoping only applies when memory=True (Crew creates Memory).
Fixes: test_crew_memory_with_google_vertex_embedder which passes
Memory(embedder=...) to Crew and expects remember(scope='/test')
to produce scope '/test', not '/crew/crew/test'.
* fix: address 6 review comments — true scope isolation for reads, writes, and consolidation
1. Constrain similarity search to root_scope boundary (no cross-crew consolidation)
2. Remove unused self._root_scope from EncodingFlow
3. Apply root_scope to recall/list/info/reset (true read isolation)
4. Only extend agent root_scope when crew has one (backward compat)
5. Fix docstring example for sanitize_scope_name
6. Verify code comments match behavior
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Joao Moura <joao@crewai.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* feat: add flow_structure() serializer for Flow class introspection
Adds a new flow_serializer module that introspects a Flow class and returns
a JSON-serializable dictionary describing its complete graph structure.
This enables Studio UI to render visual flow graphs (analogous to how
crew_structure() works for Crews).
The serializer extracts:
- Method metadata (type, triggers, conditions, router paths)
- Edge graph (listen and route edges between methods)
- State schema (from Pydantic model if typed)
- Human feedback and Crew reference detection
- Flow input detection
Includes 23 comprehensive tests covering linear flows, routers,
AND/OR conditions, human feedback, crew detection, state schemas,
edge cases, and JSON serialization.
* fix: lint — ruff check + format compliance for flow_serializer
* fix: address review — PydanticUndefined bug, FlowCondition tuple handling, dead code cleanup, inheritance tests
1. Fix PydanticUndefined default handling (real bug) — required fields
were serialized with sentinel value instead of null
2. Fix FlowCondition tuple type in _extract_all_methods_from_condition —
tuple conditions now properly extracted
3. Remove dead get_flow_inputs branch that did nothing
4. Document _detect_crew_reference as best-effort heuristic
5. Add 2 inheritance tests (parent→child method propagation)
---------
Co-authored-by: Joao Moura <joao@crewai.com>
When a flow with @human_feedback(llm=create_llm()) pauses for HITL and
later resumes:
1. The LLM object was being serialized to just a model string via
_serialize_llm_for_context() (e.g. 'gemini/gemini-3.1-flash-lite-preview')
2. On resume, resume_async() was creating LLM(model=string) with NO
credentials, project, location, safety_settings, or client_params
3. OpenAI worked by accident (OPENAI_API_KEY from env), but Gemini with
service accounts broke
This fix:
- Stashes the live LLM object on the wrapper as _hf_llm attribute
- On resume, looks up the method and retrieves the live LLM if available
- Falls back to the serialized string for backward compatibility
- Preserves _hf_llm through FlowMethod wrapper decorators
Co-authored-by: Joao Moura <joao@crewai.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* fix: add base_dir path containment to FileWriterTool
os.path.join does not prevent traversal — joining "./" with "../../../etc/cron.d/pwned"
resolves cleanly outside any intended scope. The tool also called os.makedirs on
the unvalidated path, meaning it would create arbitrary directory structures.
Adds a base_dir parameter that uses os.path.realpath() to resolve the final path
(including symlinks) before checking containment. Any filename or directory argument
that resolves outside base_dir is rejected before any filesystem operation occurs.
When base_dir is not set the tool behaves as before — only use that in fully
sandboxed environments.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: make directory relative to base_dir for better UX
When base_dir is set, the directory arg is now treated as a subdirectory
of base_dir rather than an absolute path. This means the LLM only needs
to specify a filename (and optionally a relative subdirectory) — it does
not need to repeat the base_dir path.
FileWriterTool(base_dir="./output")
→ filename="report.txt" writes to ./output/report.txt
→ filename="f.txt", directory="sub" writes to ./output/sub/f.txt
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: remove directory field from LLM schema when base_dir is set
When a developer sets base_dir, they control where files are written.
The LLM should only supply filename and content — not a directory path.
Adds ScopedFileWriterToolInput (no directory field) which is used when
base_dir is provided at construction, following the same pattern as
FileReadTool/ScrapeWebsiteTool.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: prevent path traversal in FileWriterTool without interface changes
Adds containment check inside _run() using os.path.realpath() to ensure
the resolved file path stays within the resolved directory. Blocks ../
sequences, absolute filenames, and symlink escapes transparently —
no schema or interface changes required.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: use Path.is_relative_to() for path containment check
Replaces startswith(real_directory + os.sep) with Path.is_relative_to(),
which does a proper path-component comparison. This avoids the edge case
where real_directory == "/" produces a "//" prefix, and is safe on
case-insensitive filesystems. Also explicitly rejects the case where
the filepath resolves to the directory itself (not a valid file target).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* test: fix portability issues in path traversal tests
- test_blocks_traversal_in_filename: use a sibling temp dir instead of
asserting against a potentially pre-existing ../outside.txt
- test_blocks_absolute_path_in_filename: use a temp-dir-derived absolute
path instead of hardcoding /etc/passwd
- test_blocks_symlink_escape: symlink to a temp "outside" dir instead of
/etc, assert target file was not created
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* Fix lock_store crash when redis package is not installed
`REDIS_URL` being set was enough to trigger a Redis lock, which would
raise `ImportError` if the `redis` package wasn't available. Added
`_redis_available()` to guard on both the env var and the import.
* Simplify tests
* Simplify tests #2
* fix: enhance LLM response handling and serialization
* Updated the Flow class to improve error handling when both structured and simple prompting fail, ensuring the first outcome is returned as a fallback.
* Introduced a new function, _serialize_llm_for_context, to properly serialize LLM objects with provider prefixes for better context management.
* Added tests to validate the new serialization logic and ensure correct behavior when LLM calls fail.
This update enhances the robustness of LLM interactions and improves the overall flow of handling outcomes.
* fix: patch VCR response handling to prevent httpx.ResponseNotRead errors (#4917)
* fix: enhance LLM response handling and serialization
* Updated the Flow class to improve error handling when both structured and simple prompting fail, ensuring the first outcome is returned as a fallback.
* Introduced a new function, _serialize_llm_for_context, to properly serialize LLM objects with provider prefixes for better context management.
* Added tests to validate the new serialization logic and ensure correct behavior when LLM calls fail.
This update enhances the robustness of LLM interactions and improves the overall flow of handling outcomes.
* fix: patch VCR response handling to prevent httpx.ResponseNotRead errors
VCR's _from_serialized_response mocks httpx.Response.read(), which
prevents the response's internal _content attribute from being properly
initialized. When OpenAI's client (using with_raw_response) accesses
response.content, httpx raises ResponseNotRead.
This patch explicitly sets response._content after the response is
created, ensuring that tests using VCR cassettes work correctly with
the OpenAI client's raw response handling.
Fixes tests:
- test_hierarchical_crew_creation_tasks_with_sync_last
- test_conditional_task_last_task_when_conditional_is_false
- test_crew_log_file_output
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Joao Moura <joaomdmoura@gmail.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: alex-clawd <alex@crewai.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* fix: replace os.system with subprocess.run in unsafe mode pip install
Eliminates shell injection risk (A05) where a malicious library name like
"pkg; rm -rf /" could execute arbitrary host commands. Using list-form
subprocess.run with shell=False ensures the library name is always treated
as a single argument with no shell metacharacter expansion.
Adds two tests: one verifying list-form invocation, one verifying that
shell metacharacters in a library name cannot trigger shell execution.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: use sys.executable -m pip to satisfy S607 linting rule
S607 flags partial executable paths like ["pip", ...]. Using
[sys.executable, "-m", "pip", ...] provides an absolute path and also
ensures installation targets the correct Python environment.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* feat(a2a): add plus api token auth
* feat(a2a): use stub for plus api
* fix: use dynamic separator in slugify for dedup and strip
* fix: remove unused _DUPLICATE_SEPARATOR_PATTERN, cache compiled regex in slugify
* feat: introduce PlanningConfig for enhanced agent planning capabilities (#4344)
* feat: introduce PlanningConfig for enhanced agent planning capabilities
This update adds a new PlanningConfig class to manage agent planning configurations, allowing for customizable planning behavior before task execution. The existing reasoning parameter is deprecated in favor of this new configuration, ensuring backward compatibility while enhancing the planning process. Additionally, the Agent class has been updated to utilize this new configuration, and relevant utility functions have been adjusted accordingly. Tests have been added to validate the new planning functionality and ensure proper integration with existing agent workflows.
* dropping redundancy
* fix test
* revert handle_reasoning here
* refactor: update reasoning handling in Agent class
This commit modifies the Agent class to conditionally call the handle_reasoning function based on the executor class being used. The legacy CrewAgentExecutor will continue to utilize handle_reasoning, while the new AgentExecutor will manage planning internally. Additionally, the PlanningConfig class has been referenced in the documentation to clarify its role in enabling or disabling planning. Tests have been updated to reflect these changes and ensure proper functionality.
* improve planning prompts
* matching
* refactor: remove default enabled flag from PlanningConfig in Agent class
* more cassettes
* fix test
* refactor: update planning prompt and remove deprecated methods in reasoning handler
* improve planning prompt
* Lorenze/feat planning pt 2 todo list gen (#4449)
* feat: introduce PlanningConfig for enhanced agent planning capabilities
This update adds a new PlanningConfig class to manage agent planning configurations, allowing for customizable planning behavior before task execution. The existing reasoning parameter is deprecated in favor of this new configuration, ensuring backward compatibility while enhancing the planning process. Additionally, the Agent class has been updated to utilize this new configuration, and relevant utility functions have been adjusted accordingly. Tests have been added to validate the new planning functionality and ensure proper integration with existing agent workflows.
* dropping redundancy
* fix test
* revert handle_reasoning here
* refactor: update reasoning handling in Agent class
This commit modifies the Agent class to conditionally call the handle_reasoning function based on the executor class being used. The legacy CrewAgentExecutor will continue to utilize handle_reasoning, while the new AgentExecutor will manage planning internally. Additionally, the PlanningConfig class has been referenced in the documentation to clarify its role in enabling or disabling planning. Tests have been updated to reflect these changes and ensure proper functionality.
* improve planning prompts
* matching
* refactor: remove default enabled flag from PlanningConfig in Agent class
* more cassettes
* fix test
* feat: enhance agent planning with structured todo management
This commit introduces a new planning system within the AgentExecutor class, allowing for the creation of structured todo items from planning steps. The TodoList and TodoItem models have been added to facilitate tracking of plan execution. The reasoning plan now includes a list of steps, improving the clarity and organization of agent tasks. Additionally, tests have been added to validate the new planning functionality and ensure proper integration with existing workflows.
* refactor: update planning prompt and remove deprecated methods in reasoning handler
* improve planning prompt
* improve handler
* linted
* linted
* Lorenze/feat/planning pt 3 todo list execution (#4450)
* feat: introduce PlanningConfig for enhanced agent planning capabilities
This update adds a new PlanningConfig class to manage agent planning configurations, allowing for customizable planning behavior before task execution. The existing reasoning parameter is deprecated in favor of this new configuration, ensuring backward compatibility while enhancing the planning process. Additionally, the Agent class has been updated to utilize this new configuration, and relevant utility functions have been adjusted accordingly. Tests have been added to validate the new planning functionality and ensure proper integration with existing agent workflows.
* dropping redundancy
* fix test
* revert handle_reasoning here
* refactor: update reasoning handling in Agent class
This commit modifies the Agent class to conditionally call the handle_reasoning function based on the executor class being used. The legacy CrewAgentExecutor will continue to utilize handle_reasoning, while the new AgentExecutor will manage planning internally. Additionally, the PlanningConfig class has been referenced in the documentation to clarify its role in enabling or disabling planning. Tests have been updated to reflect these changes and ensure proper functionality.
* improve planning prompts
* matching
* refactor: remove default enabled flag from PlanningConfig in Agent class
* more cassettes
* fix test
* feat: enhance agent planning with structured todo management
This commit introduces a new planning system within the AgentExecutor class, allowing for the creation of structured todo items from planning steps. The TodoList and TodoItem models have been added to facilitate tracking of plan execution. The reasoning plan now includes a list of steps, improving the clarity and organization of agent tasks. Additionally, tests have been added to validate the new planning functionality and ensure proper integration with existing workflows.
* refactor: update planning prompt and remove deprecated methods in reasoning handler
* improve planning prompt
* improve handler
* execute todos and be able to track them
* feat: introduce PlannerObserver and StepExecutor for enhanced plan execution
This commit adds the PlannerObserver and StepExecutor classes to the CrewAI framework, implementing the observation phase of the Plan-and-Execute architecture. The PlannerObserver analyzes step execution results, determines plan validity, and suggests refinements, while the StepExecutor executes individual todo items in isolation. These additions improve the overall planning and execution process, allowing for more dynamic and responsive agent behavior. Additionally, new observation events have been defined to facilitate monitoring and logging of the planning process.
* refactor: enhance final answer synthesis in AgentExecutor
This commit improves the synthesis of final answers in the AgentExecutor class by implementing a more coherent approach to combining results from multiple todo items. The method now utilizes a single LLM call to generate a polished response, falling back to concatenation if the synthesis fails. Additionally, the test cases have been updated to reflect the changes in planning and execution, ensuring that the results are properly validated and that the plan-and-execute architecture is functioning as intended.
* refactor: enhance final answer synthesis in AgentExecutor
This commit improves the synthesis of final answers in the AgentExecutor class by implementing a more coherent approach to combining results from multiple todo items. The method now utilizes a single LLM call to generate a polished response, falling back to concatenation if the synthesis fails. Additionally, the test cases have been updated to reflect the changes in planning and execution, ensuring that the results are properly validated and that the plan-and-execute architecture is functioning as intended.
* refactor: implement structured output handling in final answer synthesis
This commit enhances the final answer synthesis process in the AgentExecutor class by introducing support for structured outputs when a response model is specified. The synthesis method now utilizes the response model to produce outputs that conform to the expected schema, while still falling back to concatenation in case of synthesis failures. This change ensures that intermediate steps yield free-text results, but the final output can be structured, improving the overall coherence and usability of the synthesized answers.
* regen tests
* linted
* fix
* Enhance PlanningConfig and AgentExecutor with Reasoning Effort Levels
This update introduces a new attribute in the class, allowing users to customize the observation and replanning behavior during task execution. The class has been modified to utilize this new attribute, routing step observations based on the specified reasoning effort level: low, medium, or high.
Additionally, tests have been added to validate the functionality of the reasoning effort levels, ensuring that the agent behaves as expected under different configurations. This enhancement improves the adaptability and efficiency of the planning process in agent execution.
* regen cassettes for test and fix test
* cassette regen
* fixing tests
* dry
* Refactor PlannerObserver and StepExecutor to Utilize I18N for Prompts
This update enhances the PlannerObserver and StepExecutor classes by integrating the I18N utility for managing prompts and messages. The system and user prompts are now retrieved from the I18N module, allowing for better localization and maintainability. Additionally, the code has been cleaned up to remove hardcoded strings, improving readability and consistency across the planning and execution processes.
* Refactor PlannerObserver and StepExecutor to Utilize I18N for Prompts
This update enhances the PlannerObserver and StepExecutor classes by integrating the I18N utility for managing prompts and messages. The system and user prompts are now retrieved from the I18N module, allowing for better localization and maintainability. Additionally, the code has been cleaned up to remove hardcoded strings, improving readability and consistency across the planning and execution processes.
* consolidate agent logic
* fix datetime
* improving step executor
* refactor: streamline observation and refinement process in PlannerObserver
- Updated the PlannerObserver to apply structured refinements directly from observations without requiring a second LLM call.
- Renamed method to for clarity.
- Enhanced documentation to reflect changes in how refinements are handled.
- Removed unnecessary LLM message building and parsing logic, simplifying the refinement process.
- Updated event emissions to include summaries of refinements instead of raw data.
* enhance step executor with tool usage events and validation
- Added event emissions for tool usage, including started and finished events, to track tool execution.
- Implemented validation to ensure expected tools are called during step execution, raising errors when not.
- Refactored the method to handle tool execution with event logging.
- Introduced a new method for parsing tool input into a structured format.
- Updated tests to cover new functionality and ensure correct behavior of tool usage events.
* refactor: enhance final answer synthesis logic in AgentExecutor
- Updated the finalization process to conditionally skip synthesis when the last todo result is sufficient as a complete answer.
- Introduced a new method to determine if the last todo result can be used directly, improving efficiency.
- Added tests to verify the new behavior, ensuring synthesis is skipped when appropriate and maintained when a response model is set.
* fix: update observation handling in PlannerObserver for LLM errors
- Modified the error handling in the PlannerObserver to default to a conservative replan when an LLM call fails.
- Updated the return values to indicate that the step was not completed successfully and that a full replan is needed.
- Added a new test to verify the behavior of the observer when an LLM error occurs, ensuring the correct replan logic is triggered.
* refactor: enhance planning and execution flow in agents
- Updated the PlannerObserver to accept a kickoff input for standalone task execution, improving flexibility in task handling.
- Refined the step execution process in StepExecutor to support multi-turn action loops, allowing for iterative tool execution and observation.
- Introduced a method to extract relevant task sections from descriptions, ensuring clarity in task requirements.
- Enhanced the AgentExecutor to manage step failures more effectively, triggering replans only when necessary and preserving completed task history.
- Updated translations to reflect changes in planning principles and execution prompts, emphasizing concrete and executable steps.
* refactor: update setup_native_tools to include tool_name_mapping
- Modified the setup_native_tools function to return an additional mapping of tool names.
- Updated StepExecutor and AgentExecutor classes to accommodate the new return value from setup_native_tools.
* fix tests
* linted
* linted
* feat: enhance image block handling in Anthropic provider and update AgentExecutor logic
- Added a method to convert OpenAI-style image_url blocks to Anthropic's required format.
- Updated AgentExecutor to handle cases where no todos are ready, introducing a needs_replan return state.
- Improved fallback answer generation in AgentExecutor to prevent RuntimeErrors when no final output is produced.
* lint
* lint
* 1. Added failed to TodoStatus (planning_types.py)
- TodoStatus now includes failed as a valid state: Literal[pending, running, completed, failed]
- Added mark_failed(step_number, result) method to TodoList
- Added get_failed_todos() method to TodoList
- Updated is_complete to treat both completed and failed as terminal states
- Updated replace_pending_todos docstring to mention failed items are preserved
2. Mark running todos as failed before replan (agent_executor.py)
All three effort-level handlers now call mark_failed() on the current todo before routing to replan_now:
- Low effort (handle_step_observed_low): hard-failure branch
- Medium effort (handle_step_observed_medium): needs_full_replan branch
- High effort (decide_next_action): both needs_full_replan and step_completed_successfully=False branches
3. Updated _should_replan to use get_failed_todos()
Previously filtered on todo.status == failed which was dead code. Now uses the proper accessor method that will actually find failed items.
What this fixes: Before these changes, a step that triggered a replan would stay in running status permanently, causing is_complete to never
return True and next_pending to skip it — leading to stuck execution states. Now failed steps are properly tracked, replanning context correctly
reports them, and LiteAgentOutput.failed_todos will actually return results.
* fix test
* imp on failed states
* adjusted the var name from AgentReActState to AgentExecutorState
* addressed p0 bugs
* more improvements
* linted
* regen cassette
* addressing crictical comments
* ensure configurable timeouts, max_replans and max step iterations
* adjusted tools
* dropping debug statements
* addressed comment
* fix linter
* lints and test fixes
* fix: default observation parse fallback to failure and clean up plan-execute types
When _parse_observation_response fails all parse attempts, default to
step_completed_successfully=False instead of True to avoid silently
masking failures. Extract duplicate _extract_task_section into a shared
utility in agent_utils. Type PlanningConfig.llm as str | BaseLLM | None
instead of str | Any | None. Make StepResult a frozen dataclass for
immutability consistency with StepExecutionContext.
* fix: remove Any from function_calling_llm union type in step_executor
* fix: make BaseTool usage count thread-safe for parallel step execution
Add _usage_lock and _claim_usage() to BaseTool for atomic
check-and-increment of current_usage_count. This prevents race
conditions when parallel plan steps invoke the same tool concurrently
via execute_todos_parallel. Remove the racy pre-check from
execute_single_native_tool_call since the limit is now enforced
atomically inside tool.run().
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
Co-authored-by: Greyson LaLonde <greyson@crewai.com>
* [SECURITY] Fix sandbox escape vulnerability in CodeInterpreterTool (F-001)
This commit addresses a critical security vulnerability where the CodeInterpreterTool
could be exploited via sandbox escape attacks when Docker was unavailable.
Changes:
- Remove insecure fallback to restricted sandbox in run_code_safety()
- Now fails closed with RuntimeError when Docker is unavailable
- Mark run_code_in_restricted_sandbox() as deprecated and insecure
- Add clear security warnings to SandboxPython class documentation
- Update tests to reflect secure-by-default behavior
- Add test demonstrating the sandbox escape vulnerability
- Update README with security requirements and best practices
The previous implementation would fall back to a Python-based 'restricted sandbox'
when Docker was unavailable. However, this sandbox could be easily bypassed using
Python object introspection to recover the original __import__ function, allowing
arbitrary module access and command execution on the host.
The fix enforces Docker as a requirement for safe code execution. Users who cannot
use Docker must explicitly enable unsafe_mode=True, acknowledging the security risks.
Security Impact:
- Prevents RCE via sandbox escape when Docker is unavailable
- Enforces fail-closed security model
- Maintains backward compatibility via unsafe_mode flag
References:
- https://docs.crewai.com/tools/ai-ml/codeinterpretertool
Co-authored-by: Rip&Tear <theCyberTech@users.noreply.github.com>
* Add security fix documentation for F-001
Co-authored-by: Rip&Tear <theCyberTech@users.noreply.github.com>
* Add Slack summary for security fix
Co-authored-by: Rip&Tear <theCyberTech@users.noreply.github.com>
* Delete SECURITY_FIX_F001.md
* Delete SLACK_SUMMARY.md
* chore: regen cassettes
* chore: regen more cassettes
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: Rip&Tear <theCyberTech@users.noreply.github.com>
Co-authored-by: Greyson LaLonde <greyson@crewai.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* fix: remove exclusive locks from read-only storage operations to eliminate lock contention
read operations like search, list_scopes, get_scope_info, count across
LanceDB, ChromaDB, and RAG adapters were holding exclusive locks unnecessarily.
under multi-process prefork workers this caused RedisLock contention triggering
a portalocker bug where AlreadyLocked is raised with the exceptions module as its arg.
- remove store_lock from 7 LanceDB read methods since MVCC handles concurrent reads
- remove store_lock from ChromaDB search/asearch which are thread-safe since v0.4
- remove store_lock from RAG core query and LanceDB adapter query
- wrap lock_store BaseLockException with actionable error message
- add exception handling in encoding_flow/recall_flow ThreadPoolExecutor calls
- fix flow.py double-logging of ancestor listener errors
* fix: remove dead conditional in filter_and_chunk fallback
both branches of the if/else and the except all produced the same
candidates = [scope_prefix] result, making the get_scope_info call
and conditional pointless
* fix: separate lock acquisition from caller body in lock_store
the try/except wrapped the yield inside the contextmanager, which meant
any BaseLockException raised by the caller's code inside the with block
would be caught and re-raised with a misleading "Failed to acquire lock"
message. split into acquire-then-yield so only actual acquisition
failures get the actionable error message.
* feat(devtools): add release command and fix automerge on protected branches
Replace gh pr merge --auto with polling-based merge wait that prints the
PR URL for manual review. Add unified release command that chains bump
and tag into a single end-to-end workflow.
* feat(devtools): trigger PyPI publish workflow after GitHub release
* refactor(devtools): extract shared helpers to eliminate duplication
Extract _poll_pr_until_merged, _update_all_versions,
_generate_release_notes, _update_docs_and_create_pr,
_create_tag_and_release, and _trigger_pypi_publish into reusable
helpers. All three commands (bump, tag, release) now compose from
these shared functions.
threading.Thread() does not inherit the parent's contextvars.Context,
causing ContextVar-based state (OpenTelemetry spans, Langfuse trace IDs,
and any other request-scoped vars) to be silently dropped in async tasks.
Fix by calling contextvars.copy_context() before spawning each thread and
using ctx.run() as the thread target, which runs the function inside the
captured context.
Affected locations:
- task.py: execute_async() — the primary async task execution path
- utilities/streaming.py: create_chunk_generator() — streaming execution path
Fixes: #4822
Related: #4168, #4286
Co-authored-by: Claude <noreply@anthropic.com>
* fix(bedrock): group parallel tool results in single user message
When an AWS Bedrock model makes multiple tool calls in a single
response, the Converse API requires all corresponding tool results
to be sent back in a single user message. Previously, each tool
result was emitted as a separate user message, causing:
ValidationException: Expected toolResult blocks at messages.2.content
Fix: When processing consecutive tool messages, append the toolResult
block to the preceding user message (if it already contains
toolResult blocks) instead of creating a new message. This groups
all parallel tool results together while keeping tool results from
different assistant turns separate.
Fixes#4749
Signed-off-by: Giulio Leone <6887247+giulio-leone@users.noreply.github.com>
* Update lib/crewai/tests/llms/bedrock/test_bedrock.py
* fix: group bedrock tool results
Co-authored-by: João Moura <joaomdmoura@gmail.com>
---------
Signed-off-by: Giulio Leone <6887247+giulio-leone@users.noreply.github.com>
Co-authored-by: Giulio Leone <6887247+giulio-leone@users.noreply.github.com>
Co-authored-by: João Moura <joaomdmoura@gmail.com>
Co-authored-by: Cursor Agent <cursoragent@cursor.com>
* fix: allow hyphenated tool names in MCP references like notion#get-page
The _SLUG_RE regex on BaseAgent rejected MCP tool references containing
hyphens (e.g. "notion#get-page") because the fragment pattern only
matched \w (word chars)
* fix: create fresh MCP client per tool invocation to prevent parallel call races
When the LLM dispatches parallel calls to MCP tools on the same server, the executor runs them concurrently via ThreadPoolExecutor. Previously, all tools from a server shared a single MCPClient instance, and even the same tool called twice would reuse one client. Since each thread creates its own asyncio event loop via asyncio.run(), concurrent connect/disconnect calls on the shared client caused anyio cancel-scope errors ("Attempted to exit cancel scope in a different task than it was entered in").
The fix introduces a client_factory pattern: MCPNativeTool now receives a zero-arg callable that produces a fresh MCPClient + transport on every
_run_async() invocation. This eliminates all shared mutable connection state between concurrent calls, whether to the same tool or different tools from the same server.
* test: ensure we can filter hyphenated MCP tool
* feat: add dedicated Brave Search tools for web, news, image, video, local POIs, and Brave's newest LLM Context endpoint
* fix: normalize transformed response shape
* revert legacy tool name
* fix: schema change prevented property resolution
* Update tool.specs.json
* fix: add fallback for search_langugage
* simplify exports
* makes rate-limiting logic per-instance
* fix(brave-tools): correct _refine_response return type annotations
The abstract method and subclasses annotated _refine_response as returning
dict[str, Any] but most implementations actually return list[dict[str, Any]].
Updated base to return Any, and each subclass to match its actual return type.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Joao Moura <joaomdmoura@gmail.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* refactor(memory): convert Memory, MemoryScope, and MemorySlice to BaseModel
* fix(test): update mock memory attribute from _read_only to read_only
* fix: handle re-validation in wrap validators and patch BaseModel class in tests
ThreadPoolExecutor threads do not inherit the calling thread's contextvars
context, causing _event_id_stack and _current_celery_task_id to be empty
in worker threads. This broke OTel span parenting for parallel tool calls
(missing parent_event_id) and lost the Celery task ID in the enterprise
tracking layer ([Task ID: no-task]).
Fix by capturing an independent context copy per submission via
contextvars.copy_context().run in CrewAgentExecutor._handle_native_tool_calls,
so each worker thread starts with the correct inherited context without
sharing mutable state across threads.
* feat: enhance memory recall limits and update documentation
- Increased the memory recall limit in the Agent class from 5 to 15.
- Updated the RecallMemoryTool to allow a recall limit of 20.
- Expanded the documentation for the recall_memory feature to emphasize the importance of multiple queries for comprehensive results.
* feat: increase memory recall limit and enhance memory context documentation
- Increased the memory recall limit in the Agent class from 15 to 20.
- Updated the memory context message to clarify the nature of the memories presented and the importance of using the Search memory tool for comprehensive results.
* refactor: remove inferred_categories from RecallState and update category merging logic
- Removed the inferred_categories field from RecallState to simplify state management.
- Updated the _merged_categories method to only merge caller-supplied categories, enhancing clarity in category handling.
* refactor: simplify category handling in RecallFlow
- Updated the _merged_categories method to return only caller-supplied categories, removing the previous merging logic for inferred categories. This change enhances clarity and maintains consistency in category management.
* fix(gemini): group parallel function_response parts in a single Content object
When Gemini makes N parallel tool calls, the API requires all N function_response parts in one Content object. Previously each tool result created a separate Content, causing 400 INVALID_ARGUMENT errors. Merge consecutive function_response parts into the existing Content instead of appending new ones.
* Address change requested
- function_response is a declared field on the types.Part Pydantic model so hasattr can be replaced with p.function_response is not None
* fix(telemetry): skip signal handler registration in non-main threads
When CrewAI is initialized from a non-main thread (e.g. Streamlit, Flask,
Django, Jupyter), the telemetry module attempted to register signal handlers
which only work in the main thread. This caused multiple noisy ValueError
tracebacks to be printed to stderr, confusing users even though the errors
were caught and non-fatal.
Check `threading.current_thread() is not threading.main_thread()` before
attempting signal registration, and skip silently with a debug-level log
message instead of printing full tracebacks.
Fixes crewAIInc/crewAI#4289
* fix(test): move Telemetry() inside signal.signal mock context
Refs: #4649
* fix(telemetry): move signal.signal mock inside thread to wrap Telemetry() construction
The patch context now activates inside init_in_thread so the mock
is guaranteed to be active before and during Telemetry.__init__,
addressing the Copilot review feedback.
Refs: #4289
* fix(test): mock logger.debug instead of capsys for deterministic assertion
Replace signal.signal-only mock with combined logger + signal mock.
Assert logger.debug was called with the skip message and signal.signal
was never invoked from the non-main thread.
Refs: #4289
pypdf <6.7.4 has multiple DoS vulnerabilities via crafted PDF streams
(FlateDecode, LZWDecode, RunLengthDecode, XFA, TreeObject, outlines).
Only basic PdfReader/PdfWriter APIs are used in crewai-files, none of
which changed in the 5.0 or 6.0 breaking releases.
* docs: update Composio tool docs across locales
Align the Composio automation docs with the new session-based example flow and keep localized pages in sync with the updated English content.
Made-with: Cursor
* docs: clarify manual user authentication wording
Refine the Composio auth section language to reflect session-based automatic auth during agent chat while keeping the manual `authorize` flow explicit.
Made-with: Cursor
* docs: sync updated Composio auth wording across locales
Propagate the latest English wording updates for CrewAI provider initialization and manual user authentication guidance to pt-BR and ko docs.
Made-with: Cursor
* refactor: update step callback methods to support asynchronous invocation
- Replaced synchronous step callback invocations with asynchronous counterparts in the CrewAgentExecutor class.
- Introduced a new async method _ainvoke_step_callback to handle step callbacks in an async context, improving responsiveness and performance in asynchronous workflows.
* chore: bump version to 1.10.1b1 across multiple files
- Updated version strings from 1.10.1b to 1.10.1b1 in various project files including pyproject.toml and __init__.py files.
- Adjusted dependency specifications to reflect the new version in relevant templates and modules.
- Introduced lazy imports for the Memory and EncodingFlow classes to optimize import time and reduce initial load, particularly beneficial for deployment scenarios like Celery pre-fork.
- Updated the Memory class to include new configuration options for aggregation queries, enhancing its functionality.
- Adjusted the __getattr__ method in both the crewai and memory modules to support lazy loading of specified attributes.
* chore(deps): update lancedb version and add lance-namespace packages
- Updated lancedb dependency version from 0.4.0 to 0.29.2 in multiple files.
- Added new packages: lance-namespace and lance-namespace-urllib3-client with version 0.5.2, including their dependencies and installation details.
- Enhanced MemoryTUI to display a limit on entries and improved the LanceDBStorage class with automatic background compaction and index creation for better performance.
* linter
* refactor: update memory recall limit and formatting in Agent class
- Reduced the memory recall limit from 10 to 5 in multiple locations within the Agent class.
- Updated the memory formatting to use a new `format` method in the MemoryMatch class for improved readability and metadata inclusion.
* refactor: enhance memory handling with read-only support
- Updated memory-related classes and methods to support read-only functionality, allowing for silent no-ops when attempting to remember data in read-only mode.
- Modified the LiteAgent and CrewAgentExecutorMixin classes to check for read-only status before saving memories.
- Adjusted MemorySlice and Memory classes to reflect changes in behavior when read-only is enabled.
- Updated tests to verify that memory operations behave correctly under read-only conditions.
* test: set mock memory to read-write in unit tests
- Updated unit tests in test_unified_memory.py to set mock_memory._read_only to False, ensuring that memory operations can be tested in a writable state.
* fix test
* fix: preserve falsy metadata values and fix remember() return type
---------
Co-authored-by: lorenzejay <lorenzejaytech@gmail.com>
Co-authored-by: Greyson LaLonde <greyson@crewai.com>
* fix: preserve null types in tool parameter schemas for LLM
Tool parameter schemas were stripping null from optional fields via
generate_model_description, forcing the LLM to provide non-null values
for fields.
Adds strip_null_types parameter to generate_model_description and passes False when generating tool
schemas, so optional fields keep anyOf: [{type: T}, {type: null}]
* Update lib/crewai/src/crewai/utilities/pydantic_schema_utils.py
Co-authored-by: Gabe Milani <gabriel@crewai.com>
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
Co-authored-by: Gabe Milani <gabriel@crewai.com>
Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>
* fix: map output_pydantic/output_json to native structured output
* test: add crew+tools+structured output integration test for Gemini
* fix: re-record stale cassette for test_crew_testing_function
* fix: re-record remaining stale cassettes for native structured output
* fix: enable native structured output for lite agent and fix mypy errors
* feat: enhance JSON argument parsing and validation in CrewAgentExecutor and BaseTool
- Added error handling for malformed JSON tool arguments in CrewAgentExecutor, providing descriptive error messages.
- Implemented schema validation for tool arguments in BaseTool, ensuring that invalid arguments raise appropriate exceptions.
- Introduced tests to verify correct behavior for both valid and invalid JSON inputs, enhancing robustness of tool execution.
* refactor: improve argument validation in BaseTool
- Introduced a new private method to handle argument validation for tools, enhancing code clarity and reusability.
- Updated the method to utilize the new validation method, ensuring consistent error handling for invalid arguments.
- Enhanced exception handling to specifically catch , providing clearer error messages for tool argument validation failures.
* feat: introduce parse_tool_call_args for improved argument parsing
- Added a new utility function, parse_tool_call_args, to handle parsing of tool call arguments from JSON strings or dictionaries, enhancing error handling for malformed JSON inputs.
- Updated CrewAgentExecutor and AgentExecutor to utilize the new parsing function, streamlining argument validation and improving clarity in error reporting.
- Introduced unit tests for parse_tool_call_args to ensure robust functionality and correct handling of various input scenarios.
* feat: add keyword argument validation in BaseTool and Tool classes
- Introduced a new method `_validate_kwargs` in BaseTool to validate keyword arguments against the defined schema, ensuring proper argument handling.
- Updated the `run` and `arun` methods in both BaseTool and Tool classes to utilize the new validation method, improving error handling and robustness.
- Added comprehensive tests for asynchronous execution in `TestBaseToolArunValidation` to verify correct behavior for valid and invalid keyword arguments.
* Potential fix for pull request finding 'Syntax error'
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
---------
Co-authored-by: lorenzejay <lorenzejaytech@gmail.com>
Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
* fix: bedrock region was always set to "us-east-1" not respecting the env
var.
code had AWS_REGION_NAME referenced, but not used, unified to
AWS_DEFAULT_REGION as per documentation
* DRY code improvement and fix caught by tests.
* Supporting litellm configuration
* Implement user input handling in Flow class
- Introduced `FlowInputRequestedEvent` and `FlowInputReceivedEvent` to manage user input requests and responses during flow execution.
- Added `InputProvider` protocol and `InputResponse` dataclass for customizable input handling.
- Enhanced `Flow` class with `ask()` method to request user input, including timeout handling and state checkpointing.
- Updated `FlowConfig` to support custom input providers.
- Created `input_provider.py` for default input provider implementations, including a console-based provider.
- Added comprehensive tests for `ask()` functionality, covering basic usage, timeout behavior, and integration with flow machinery.
* Potential fix for pull request finding 'Unused import'
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
* Refactor test_flow_ask.py to streamline flow kickoff calls
- Removed unnecessary variable assignments for the result of `flow.kickoff()` in two test cases, improving code clarity.
- Updated assertions to ensure the expected execution log entries are present after the flow kickoff, enhancing test reliability.
* Add current_flow_method_name context variable for flow method tracking
- Introduced a new context variable, `current_flow_method_name`, to store the name of the currently executing flow method, defaulting to "unknown".
- Updated the Flow class to set and reset this context variable during method execution, enhancing the ability to track method calls without stack inspection.
- Removed the obsolete `_resolve_calling_method_name` method, streamlining the code and improving clarity.
* Enhance input history management in Flow class
- Introduced a new `InputHistoryEntry` TypedDict to structure user input history for the `ask()` method, capturing details such as the question, user response, method name, timestamp, and associated metadata.
- Updated the `_input_history` attribute in the Flow class to utilize the new `InputHistoryEntry` type, improving type safety and clarity in input history management.
* Enhance timeout handling in Flow class input requests
- Updated the `ask()` method to improve timeout management by manually managing the `ThreadPoolExecutor`, preventing potential deadlocks when the provider call exceeds the timeout duration.
- Added clarifications in the documentation regarding the behavior of the timeout and the underlying request handling, ensuring better understanding for users.
* Enhance memory reset functionality in CLI commands
- Introduced flow memory reset capabilities in the `reset_memories_command`, allowing for both crew and flow memory resets.
- Added a new utility function `_reset_flow_memory` to handle memory resets for individual flow instances, improving modularity and clarity.
- Updated the `get_flows` utility to discover flow instances from project files, enhancing the CLI's ability to manage flow states.
- Expanded test coverage to validate the new flow memory reset features, ensuring robust functionality and error handling.
* LINTER
* Fix resumption flag logic in Flow class and add regression test for cyclic flow persistence
- Updated the logic for setting the `_is_execution_resuming` flag to ensure it only activates when there are completed methods to replay, preventing incorrect suppression of cyclic re-execution during state reloads.
- Added a regression test to validate that cyclic router flows complete all iterations when persistence is enabled and an 'id' is passed in inputs, ensuring robust handling of flow execution in these scenarios.
---------
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
- Added tests to verify self-loop behavior in HITL routers, ensuring they can handle multiple rejections and immediate approvals.
- Implemented `test_hitl_self_loop_routes_back_to_same_method`, `test_hitl_self_loop_multiple_rejections`, and `test_hitl_self_loop_immediate_approval` to validate the expected execution order and outcomes.
- Updated the `or_()` listener to support looping back to the same method based on human feedback outcomes, improving flow control in complex scenarios.
* better DevEx
* Refactor: Update supported native providers and enhance memory handling
- Removed "groq" and "meta" from the list of supported native providers in `llm.py`.
- Added a safeguard in `flow.py` to ensure all background memory saves complete before returning.
- Improved error handling in `unified_memory.py` to prevent exceptions during shutdown, ensuring smoother memory operations and event bus interactions.
* Enhance Memory System with Consolidation and Learning Features
- Introduced memory consolidation mechanisms to prevent duplicate records during content saving, utilizing similarity checks and LLM decision-making.
- Implemented non-blocking save operations in the memory system, allowing agents to continue tasks while memory is being saved.
- Added support for learning from human feedback, enabling the system to distill lessons from past corrections and improve future outputs.
- Updated documentation to reflect new features and usage examples for memory consolidation and HITL learning.
* Enhance cyclic flow handling for or_() listeners
- Updated the Flow class to ensure that all fired or_() listeners are cleared between cycle iterations, allowing them to fire again in subsequent cycles. This change addresses a bug where listeners remained suppressed across iterations.
- Added regression tests to verify that or_() listeners fire correctly on every iteration in cyclic flows, ensuring expected behavior in complex routing scenarios.
* chore: update memory management and dependencies
- Enhance the memory system by introducing a unified memory API that consolidates short-term, long-term, entity, and external memory functionalities.
- Update the `.gitignore` to exclude new memory-related files and blog directories.
- Modify `conftest.py` to handle missing imports for vcr stubs more gracefully.
- Add new development dependencies in `pyproject.toml` for testing and memory management.
- Refactor the `Crew` class to utilize the new unified memory system, replacing deprecated memory attributes.
- Implement memory context injection in `LiteAgent` to improve memory recall during agent execution.
- Update documentation to reflect changes in memory usage and configuration.
* feat: introduce Memory TUI for enhanced memory management
- Add a new command to the CLI for launching a Textual User Interface (TUI) to browse and recall memories.
- Implement the MemoryTUI class to facilitate user interaction with memory scopes and records.
- Enhance the unified memory API by adding a method to list records within a specified scope.
- Update `pyproject.toml` to include the `textual` dependency for TUI functionality.
- Ensure proper error handling for missing dependencies when accessing the TUI.
* feat: implement consolidation flow for memory management
- Introduce the ConsolidationFlow class to handle the decision-making process for inserting, updating, or deleting memory records based on new content.
- Add new data models: ConsolidationAction and ConsolidationPlan to structure the actions taken during consolidation.
- Enhance the memory types with new fields for consolidation thresholds and limits.
- Update the unified memory API to utilize the new consolidation flow for managing memory records.
- Implement embedding functionality for new content to facilitate similarity checks.
- Refactor existing memory analysis methods to integrate with the consolidation process.
- Update translations to include prompts for consolidation actions and user interactions.
* feat: enhance Memory TUI with Rich markup and improved UI elements
- Update the MemoryTUI class to utilize Rich markup for better visual representation of memory scope information.
- Introduce a color palette for consistent branding across the TUI interface.
- Refactor the CSS styles to improve the layout and aesthetics of the memory browsing experience.
- Enhance the display of memory entries, including better formatting for records and importance ratings.
- Implement loading indicators and error messages with Rich styling for improved user feedback during recall operations.
- Update the action bindings and navigation prompts for a more intuitive user experience.
* feat: enhance Crew class memory management and configuration
- Update the Crew class to allow for more flexible memory configurations by accepting Memory, MemoryScope, or MemorySlice instances.
- Refactor memory initialization logic to support custom memory configurations while maintaining backward compatibility.
- Improve documentation for memory-related fields to clarify usage and expectations.
- Introduce a recall oversample factor to optimize memory recall processes.
- Update related memory types and configurations to ensure consistency across the memory management system.
* chore: update dependency overrides and enhance memory management
- Added an override for the 'rich' dependency to allow compatibility with 'textual' requirements.
- Updated the 'pyproject.toml' and 'uv.lock' files to reflect the new dependency specifications.
- Refactored the Crew class to simplify memory configuration handling by allowing any type for the memory attribute.
- Improved error messages in the CLI for missing 'textual' dependency to guide users on installation.
- Introduced new packages and dependencies in the project to enhance functionality and maintain compatibility.
* refactor: enhance thread safety in flow management
- Updated LockedListProxy and LockedDictProxy to subclass list and dict respectively, ensuring compatibility with libraries requiring strict type checks.
- Improved documentation to clarify the purpose of these proxies and their thread-safe operations.
- Ensured that all mutations are protected by locks while reads delegate to the underlying data structures, enhancing concurrency safety.
* chore: update dependency versions and improve Python compatibility
- Downgraded 'vcrpy' dependency to version 7.0.0 for compatibility.
- Enhanced 'uv.lock' to include more granular resolution markers for Python versions and implementations, ensuring better compatibility across different environments.
- Updated 'urllib3' and 'selenium' dependencies to specify versions based on Python implementation, improving stability and performance.
- Removed deprecated resolution markers for 'fastembed' and streamlined its dependencies for better clarity.
* fix linter
* chore: update uv.lock for improved dependency management and memory management enhancements
- Incremented revision number in uv.lock to reflect changes.
- Added a new development dependency group in uv.lock, specifying versions for tools like pytest, mypy, and pre-commit to streamline development workflows.
- Enhanced error handling in CLI memory functions to provide clearer feedback on missing dependencies.
- Refactored memory management classes to improve type hints and maintainability, ensuring better compatibility with future updates.
* fix tests
* refactor: remove obsolete RAGStorage tests and clean up error handling
- Deleted outdated tests for RAGStorage that were no longer relevant, including tests for client failures, save operation failures, and reset failures.
- Cleaned up the test suite to focus on current functionality and improve maintainability.
- Ensured that remaining tests continue to validate the expected behavior of knowledge storage components.
* fix test
* fix texts
* fix tests
* forcing new commit
* fix: add location parameter to Google Vertex embedder configuration for memory integration tests
* debugging CI
* adding debugging for CI
* refactor: remove unnecessary logging for memory checks in agent execution
- Eliminated redundant logging statements related to memory checks in the Agent and CrewAgentExecutor classes.
- Simplified the memory retrieval logic by directly checking for available memory without logging intermediate states.
- Improved code readability and maintainability by reducing clutter in the logging output.
* udpating desp
* feat: enhance thread safety in LockedListProxy and LockedDictProxy
- Added equality comparison methods (__eq__ and __ne__) to LockedListProxy and LockedDictProxy to allow for safe comparison of their contents.
- Implemented consistent locking mechanisms to prevent deadlocks during comparisons.
- Improved the overall robustness of these proxy classes in multi-threaded environments.
* feat: enhance memory functionality in Flows documentation and memory system
- Added a new section on memory usage within Flows, detailing built-in methods for storing and recalling memories.
- Included an example of a Research and Analyze Flow demonstrating the integration of memory for accumulating knowledge over time.
- Updated the Memory documentation to clarify the unified memory system and its capabilities, including adaptive-depth recall and composite scoring.
- Introduced a new configuration parameter, `recall_oversample_factor`, to improve the effectiveness of memory retrieval processes.
* update docs
* refactor: improve memory record handling and pagination in unified memory system
- Simplified the `get_record` method in the Memory class by directly accessing the storage's `get_record` method.
- Enhanced the `list_records` method to include an `offset` parameter for pagination, allowing users to skip a specified number of records.
- Updated documentation for both methods to clarify their functionality and parameters, improving overall code clarity and usability.
* test: update memory scope assertions in unified memory tests
- Modified assertions in `test_lancedb_list_scopes_get_scope_info` and `test_memory_list_scopes_info_tree` to check for the presence of the "/team" scope instead of the root scope.
- Clarified comments to indicate that `list_scopes` returns child scopes rather than the root itself, enhancing test clarity and accuracy.
* feat: integrate memory tools for agents and crews
- Added functionality to inject memory tools into agents during initialization, enhancing their ability to recall and remember information mid-task.
- Implemented a new `_add_memory_tools` method in the Crew class to facilitate the addition of memory tools when memory is available.
- Introduced `RecallMemoryTool` and `RememberTool` classes in a new `memory_tools.py` file, providing agents with active recall and memory storage capabilities.
- Updated English translations to include descriptions for the new memory tools, improving user guidance on their usage.
* refactor: streamline memory recall functionality across agents and tools
- Removed the 'depth' parameter from memory recall calls in LiteAgent and Agent classes, simplifying the recall process.
- Updated the MemoryTUI to use 'deep' depth by default for more comprehensive memory retrieval.
- Enhanced the MemoryScope and MemorySlice classes to default to 'deep' depth, improving recall accuracy.
- Introduced a new 'recall_queries' field in QueryAnalysis to optimize semantic vector searches with targeted phrases.
- Updated documentation and comments to reflect changes in memory recall behavior and parameters.
* refactor: optimize memory management in flow classes
- Enhanced memory auto-creation logic in Flow class to prevent unnecessary Memory instance creation for internal flows (RecallFlow, ConsolidationFlow) by introducing a _skip_auto_memory flag.
- Removed the deprecated time_hints field from QueryAnalysis and replaced it with a more flexible time_filter field to better handle time-based queries.
- Updated documentation and comments to reflect changes in memory handling and query analysis structure, improving clarity and usability.
* updates tests
* feat: introduce EncodingFlow for enhanced memory encoding pipeline
- Added a new EncodingFlow class to orchestrate the encoding process for memory, integrating LLM analysis and embedding.
- Updated the Memory class to utilize EncodingFlow for saving content, improving the overall memory management and conflict resolution.
- Enhanced the unified memory module to include the new EncodingFlow in its public API, facilitating better memory handling.
- Updated tests to ensure proper functionality of the new encoding flow and its integration with existing memory features.
* refactor: optimize memory tool integration and recall flow
- Streamlined the addition of memory tools in the Agent class by using list comprehension for cleaner code.
- Enhanced the RecallFlow class to build task lists more efficiently with list comprehensions, improving readability and performance.
- Updated the RecallMemoryTool to utilize list comprehensions for formatting memory results, simplifying the code structure.
- Adjusted test assertions in LiteAgent to reflect the default behavior of memory recall depth, ensuring clarity in expected outcomes.
* Potential fix for pull request finding 'Empty except'
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
* chore: gen missing cassette
* fix
* test: enhance memory extraction test by mocking recall to prevent LLM calls
Updated the test for memory extraction to include a mock for the recall method, ensuring that the test focuses on the save path without invoking external LLM calls. This improves test reliability and clarity.
* refactor: enhance memory handling by adding agent role parameter
Updated memory storage methods across multiple classes to include an optional `agent_role` parameter, improving the context of stored memories. Additionally, modified the initialization of several flow classes to suppress flow events, enhancing performance and reducing unnecessary event triggers.
* feat: enhance agent memory functionality with recall and save mechanisms
Implemented memory context injection during agent kickoff, allowing for memory recall before execution and passive saving of results afterward. Added new methods to handle memory saving and retrieval, including error handling for memory operations. Updated the BaseAgent class to support dynamic memory resolution and improved memory record structure with source and privacy attributes for better provenance tracking.
* test
* feat: add utility method to simplify tools field in console formatter
Introduced a new static method `_simplify_tools_field` in the console formatter to transform the 'tools' field from full tool objects to a comma-separated string of tool names. This enhancement improves the readability of tool information in the output.
* refactor: improve lazy initialization of LLM and embedder in Memory class
Refactored the Memory class to implement lazy initialization for the LLM and embedder, ensuring they are only created when first accessed. This change enhances the robustness of the Memory class by preventing initialization failures when constructed without an API key. Additionally, updated error handling to provide clearer guidance for users on resolving initialization issues.
* refactor: consolidate memory saving methods for improved efficiency
Refactored memory handling across multiple classes to replace individual memory saving calls with a batch method, `remember_many`, enhancing performance and reducing redundancy. Updated related tools and schemas to support single and multiple item memory operations, ensuring a more streamlined interface for memory interactions. Additionally, improved documentation and test coverage for the new functionality.
* feat: enhance MemoryTUI with improved layout and entry handling
Updated the MemoryTUI class to incorporate a new vertical layout, adding an OptionList for displaying entries and enhancing the detail view for selected records. Introduced methods for populating entry and recall lists, improving user interaction and data presentation. Additionally, refined CSS styles for better visual organization and focus handling.
* fix test
* feat: inject memory tools into LiteAgent for enhanced functionality
Added logic to the LiteAgent class to inject memory tools if memory is configured, ensuring that memory tools are only added if they are not already present. This change improves the agent's capability to utilize memory effectively during execution.
* feat: add synchronous execution method to ConsolidationFlow for improved integration
Introduced a new `run_sync()` method in the ConsolidationFlow class to facilitate procedural execution of the consolidation pipeline without relying on asynchronous event loops. Updated the EncodingFlow class to utilize this method for conflict resolution, ensuring compatibility within its async context. This change enhances the flow's ability to manage memory records effectively during nested executions.
* refactor: update ConsolidationFlow and EncodingFlow for improved async handling
Removed the synchronous `run_sync()` method from ConsolidationFlow and refactored the consolidate method in EncodingFlow to be asynchronous. This change allows for direct awaiting of the ConsolidationFlow's kickoff method, enhancing compatibility within the async event loop and preventing nested asyncio.run() issues. Additionally, updated the execution plan to listen for multiple paths, streamlining the consolidation process.
* fix: update flow documentation and remove unused ConsolidationFlow
Corrected the comment in Flow class regarding internal flows, replacing "ConsolidationFlow" with "EncodingFlow". Removed the ConsolidationFlow class as it is no longer needed, streamlining the memory handling process. Updated related imports and ensured that the memory module reflects these changes, enhancing clarity and maintainability.
* feat: enhance memory handling with background saving and query analysis optimization
Implemented a background saving mechanism in the Memory class to allow non-blocking memory operations, improving performance during high-load scenarios. Added a query analysis threshold to skip LLM calls for short queries, optimizing recall efficiency. Updated related methods and documentation to reflect these changes, ensuring a more responsive and efficient memory management system.
* fix test
* fix test
* fix: handle synchronous fallback for save operations in Memory class
Updated the Memory class to implement a synchronous fallback mechanism for save operations when the background thread pool is shut down. This change ensures that late save requests still succeed, improving reliability in memory management during shutdown scenarios.
* feat: implement HITL learning features in human feedback decorator
Added support for learning from human feedback in the human feedback decorator. Introduced parameters to enable lesson distillation and pre-review of outputs based on past feedback. Updated related tests to ensure proper functionality of the learning mechanism, including memory interactions and default LLM usage.
---------
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
Update documentation to use underscore instead of hyphen in the `--skip_provider` flag across all CLI command examples for consistency with actual CLI implementation.
* docs: add missing integration actions from OAuth config
Sync enterprise integration docs with crewai-oauth apps.js config.
Adds ~96 missing actions across 9 integrations:
- Google Contacts: 4 contact group actions
- Google Slides: 14 slide manipulation/content actions
- Microsoft SharePoint: 27 file, Excel, and Word actions
- Microsoft Excel: 2 actions (get_used_range_metadata, get_table_data)
- Microsoft Word: 2 actions (copy_document, move_document)
- Google Docs: 27 text formatting, table, and header/footer actions
- Microsoft Outlook: 7 message and calendar event actions
- Microsoft OneDrive: 5 path-based and discovery actions
- Microsoft Teams: 8 meeting, channel, and reply actions
* docs: add missing integration actions from OAuth config
Sync pt-BR enterprise integration docs with crewai-oauth apps.js config.
Adds ~96 missing actions across 9 integrations, translated to Portuguese:
- Google Contacts: 2 contact group actions
- Google Slides: 14 slide manipulation/content actions
- Microsoft SharePoint: 27 file, Excel, and Word actions
- Microsoft Excel: 2 actions (get_used_range_metadata, get_table_data)
- Microsoft Word: 2 actions (copy_document, move_document)
- Google Docs: 27 text formatting, table, and header/footer actions
- Microsoft Outlook: 7 message and calendar event actions
- Microsoft OneDrive: 5 path-based and discovery actions
- Microsoft Teams: 8 meeting, channel, and reply actions
* docs: add missing integration actions from OAuth config
Sync Korean enterprise integration docs with crewai-oauth apps.js config.
Adds ~96 missing actions across 9 integrations, translated to Korean:
- Google Contacts: 2 contact group actions
- Google Slides: 14 slide manipulation/content actions
- Microsoft SharePoint: 27 file, Excel, and Word actions
- Microsoft Excel: 2 actions (get_used_range_metadata, get_table_data)
- Microsoft Word: 2 actions (copy_document, move_document)
- Google Docs: 27 text formatting, table, and header/footer actions
- Microsoft Outlook: 7 message and calendar event actions
- Microsoft OneDrive: 5 path-based and discovery actions
- Microsoft Teams: 8 meeting, channel, and reply actions
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* fix(security): bump regex from 2024.9.11 to 2026.1.15
Address security vulnerability flagged in regex==2024.9.11
* bump mcp from 1.23.1 to 1.26.0
Address security vulnerability flagged in mcp==1.16.0 (resolved to 1.23.3)
asynchronous human-in-the-loop handling and related fixes.
- Extend human_input provider with async support: AsyncExecutorContext, handle_feedback_async, async prompt helpers (_prompt_input_async, _async_readline), and async training/regular feedback loops in SyncHumanInputProvider.
- Add async handler methods in CrewAgentExecutor and AgentExecutor (_ahandle_human_feedback, _ainvoke_loop) to integrate async provider flows.
- Change PlusAPI.get_agent to an async httpx call and adapt caller in agent_utils to run it via asyncio.run.
- Simplify listener execution in flow.Flow to correctly pass HumanFeedbackResult to listeners and unify execution path for router outcomes.
- Remove deprecated types/hitl.py definitions.
- Add tests covering chained router feedback, rejected paths, and mixed router/non-router listeners to prevent regressions.
* fix: add current task id context and flow updates
introduce a context var for the current task id in `crewai.context` to track task scope. update `Flow._execute_single_listener` to return `(result, event_id)` and adjust callers to unpack it and append `FlowMethodName(str(result))` to `router_results`. set/reset the current task id at the start/end of task execution (async + sync) with minor import and call-site tweaks.
* fix: await event futures and flush event bus
call `crewai_event_bus.flush()` after crew kickoff. in `Flow`, await event handler futures instead of just collecting them: await pending `_event_futures` before finishing, await emitted futures immediately with try/except to log failures, then clear `_event_futures`. ensures handlers complete and errors surface.
* fix: continue iteration on tool completion events
expand the loop bridge listener to also trigger on tool completion events (`tool_completed` and `native_tool_completed`) so agent iteration resumes after tools finish. add a `requests.post` mock and response fixture in the liteagent test to simulate platform tool execution. refresh and sanitize vcr cassettes (updated model responses, timestamps, and header placeholders) to reflect tool-call flows and new recordings.
* fix: thread-safe state proxies & native routing
add thread-safe state proxies and refactor native tool routing.
* introduce `LockedListProxy` and `LockedDictProxy` in `flow.py` and update `StateProxy` to return them for list/dict attrs so mutations are protected by the flow lock.
* update `AgentExecutor` to use `StateProxy` on flow init, guard the messages setter with the state lock, and return a `StateProxy` from the temp state accessor.
* convert `call_llm_native_tools` into a listener (no direct routing return) and add `route_native_tool_result` to route based on state (pending tool calls, final answer, or context error).
* minor cleanup in `continue_iteration` to drop orphan listeners on init.
* update test cassettes for new native tool call responses, timestamps, and ids.
improves concurrency safety for shared state and makes native tool routing explicit.
* chore: regen cassettes
* chore: regen cassettes, remove duplicate listener call path
* feat: add started_event_id and set in eventbus
* chore: update additional test assumption
* fix: restore event bus handlers on context exit
fix rollback in crewai events bus so that exiting the context restores
the previous _sync_handlers, _async_handlers, _handler_dependencies, and _execution_plan_cache by assigning shallow copies of the saved dicts. previously these
were set to empty dicts on exit, which caused registered handlers and cached execution plans to be lost.
Introduce ContextVar-backed hooks and small API/behavior changes to improve extensibility and testability.
Changes include:
- agents: mark configure_structured_output as abstract and change its parameter to task to reflect use of task metadata.
- tracing: convert _first_time_trace_hook to a ContextVar and call .get() to safely retrieve the hook.
- console formatter: add _disable_version_check ContextVar and skip version checks when set (avoids noisy checks in certain contexts).
- flow: use current_triggering_event_id variable when scheduling listener tasks to keep naming consistent.
- hallucination guardrail: make context optional, add _validate_output_hook to allow custom validation hooks, update examples and return contract to allow hooks to override behavior.
- agent utilities: add _create_plus_client_hook for injecting a Plus client (used in tests/alternate flows), ensure structured tools have current_usage_count initialized and propagate to original tool, and fall back to creating PlusAPI client when no hook is provided.
Refactor agent executor to delegate human interactions to a provider: add messages and ask_for_human_input properties, implement _invoke_loop and _format_feedback_message, and replace the internal iterative/training feedback logic with a call to get_provider().handle_feedback.
Make LLMGuardrail kickoff coroutine-aware by detecting coroutines and running them via asyncio.run so both sync and async agents are supported.
Make telemetry more robust by safely handling missing task.output (use empty string) and returning early if span is None before setting attributes.
Improve serialization to detect circular references via an _ancestors set, propagate it through recursive calls, and pass exclude/max_depth/_current_depth consistently to prevent infinite recursion and produce stable serializable output.
Allow hook registration to accept both typed hook types and plain callables by importing and using After*/Before*CallHookCallable types; add explicit LLMCallHookContext and ToolCallHookContext typing in crew_base. Introduce a post-initialize crew hook list and invoke hooks after Crew instance initialization. Refactor filtered hook factory functions to include precise typing and clearer local names (before_llm_hook/after_llm_hook/before_tool_hook/after_tool_hook) and register those with the instance. Update CrewInstance protocol to include _registered_hook_functions and _hooks_being_registered fields.
When a tool raises an error, both ToolUsageErrorEvent and
ToolUsageFinishedEvent were being emitted. Since both events pop the
event scope stack, this caused the agent scope to be incorrectly popped
along with the tool scope.
Enable dynamic extension exports and small behavior fixes across events and flow modules:
- events/__init__.py: Added _extension_exports and extended __getattr__ to lazily resolve registered extension values or import paths.
- events/event_bus.py: Implemented off() to unregister sync/async handlers, clean handler dependencies, and invalidate execution plan cache.
- events/listeners/tracing/utils.py: Added Callable import and _first_time_trace_hook to allow overriding first-time trace auto-collection behavior.
- events/types/tool_usage_events.py: Changed ToolUsageEvent.run_attempts default from None to 0 to avoid nullable handling.
- events/utils/console_formatter.py: Respect CREWAI_DISABLE_VERSION_CHECK env var to skip version checks in CI-like flows.
- flow/async_feedback/__init__.py: Added typing.Any import, _extension_exports and __getattr__ to support extensions via attribute lookup.
These changes add extension points and safer defaults, and provide a way to unregister event handlers.
* refactor: extract hitl to provider pattern
- add humaninputprovider protocol with setup_messages and handle_feedback
- move sync hitl logic from executor to synchuman inputprovider
- add _passthrough_exceptions extension point in agent/core.py
- create crewai.core.providers module for extensible components
- remove _ask_human_input from base_agent_executor_mixin
* feat: enhance AnthropicCompletion to support available functions in tool execution
- Updated the `_prepare_completion_params` method to accept `available_functions` for better tool handling.
- Modified tool execution logic to directly return results from tools when `available_functions` is provided, aligning behavior with OpenAI's model.
- Added new test cases to validate the execution of tools with available functions, ensuring correct argument passing and result formatting.
This change improves the flexibility and usability of the Anthropic LLM integration, allowing for more complex interactions with tools.
* refactor: remove redundant event emission in AnthropicCompletion
* fix test
* dry up
Dependabot's uv updater defaults to Python 3.14.2, which is incompatible
with the project's requires-python constraint (>=3.10, <3.14). Adding
.python-version pins the Python version to 3.13 for dependency updates.
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* limit to 0.5.9 due breaking changes + add env vars requirements
* fix tool spec extract that was ignoring with default
* original tool spec
* update spec
When monitoring LLM events, consumers need to know which events belong
to the same API call. Before this change, there was no way to correlate
LLMCallStartedEvent, LLMStreamChunkEvent, and LLMCallCompletedEvent
belonging to the same request.
* feat: add server-side auth schemes and protocol extensions
- add server auth scheme base class and implementations (api key, bearer token, basic/digest auth, mtls)
- add server-side extension system for a2a protocol extensions
- add extensions middleware for x-a2a-extensions header management
- add extension validation and registry utilities
- enhance auth utilities with server-side support
- add async intercept method to match client call interceptor protocol
- fix type_checking import to resolve mypy errors with a2aconfig
* feat: add transport negotiation and content type handling
- add transport negotiation logic with fallback support
- add content type parser and encoder utilities
- add transport configuration models (client and server)
- add transport types and enums
- enhance config with transport settings
- add negotiation events for transport and content type
* feat: add a2a delegation support to LiteAgent
* feat: add file input support to a2a delegation and tasks
Introduces handling of file inputs in A2A delegation flows by converting file dictionaries to protocol-compatible parts and propagating them through delegation and task execution functions. Updates include utility functions for file conversion, changes to message construction, and passing input_files through relevant APIs.
* feat: liteagent a2a delegation support to kickoff methods
* fix: improve output handling and response model integration in agents
- Refactored output handling in the Agent class to ensure proper conversion and formatting of outputs, including support for BaseModel instances.
- Enhanced the AgentExecutor class to correctly utilize response models during execution, improving the handling of structured outputs.
- Updated the Gemini and Anthropic completion providers to ensure compatibility with new response model handling, including the addition of strict mode for function definitions.
- Improved the OpenAI completion provider to enforce strict adherence to function schemas.
- Adjusted translations to clarify instructions regarding output formatting and schema adherence.
* drop what was a print that didnt get deleted properly
* fixes gemini
* azure working
* bedrock works
* added tests
* adjust test
* fix tests and regen
* fix tests and regen
* refactor: ensure stop words are applied correctly in Azure, Gemini, and OpenAI completions; add tests to validate behavior with structured outputs
* linting
* no need post tool reflection on native tools
* refactor: update prompt generation to prevent thought leakage
- Modified the prompt structure to ensure agents without tools use a simplified format, avoiding ReAct instructions.
- Introduced a new 'task_no_tools' slice for agents lacking tools, ensuring clean output without Thought: prefixes.
- Enhanced test coverage to verify that prompts do not encourage thought leakage, ensuring outputs remain focused and direct.
- Added integration tests to validate that real LLM calls produce clean outputs without internal reasoning artifacts.
* dont forget the cassettes
- add gemini 2.0 schema support using response_json_schema with propertyordering while retaining backward compatibility for earlier models
- refactor llm completions to return validated pydantic models when a response_model is provided, updating hooks, types, and tests for consistent structured outputs
- extend agentfinish and executors to support basemodel outputs, improve anthropic structured parsing, and clean up schema utilities, tests, and original_json handling
* feat: implement before and after tool call hooks in CrewAgentExecutor and AgentExecutor
- Added support for before and after tool call hooks in both CrewAgentExecutor and AgentExecutor classes.
- Introduced ToolCallHookContext to manage context for hooks, allowing for enhanced control over tool execution.
- Implemented logic to block tool execution based on before hooks and to modify results based on after hooks.
- Added integration tests to validate the functionality of the new hooks, ensuring they work as expected in various scenarios.
- Enhanced the overall flexibility and extensibility of tool interactions within the CrewAI framework.
* Potential fix for pull request finding 'Unused local variable'
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
* Potential fix for pull request finding 'Unused local variable'
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
* test: add integration test for before hook blocking tool execution in Crew
- Implemented a new test to verify that the before hook can successfully block the execution of a tool within a crew.
- The test checks that the tool is not executed when the before hook returns False, ensuring proper control over tool interactions.
- Enhanced the validation of hook calls to confirm that both before and after hooks are triggered appropriately, even when execution is blocked.
- This addition strengthens the testing coverage for tool call hooks in the CrewAI framework.
* drop unused
* refactor(tests): remove OPENAI_API_KEY check from tool hook tests
- Eliminated the check for the OPENAI_API_KEY environment variable in the test cases for tool hooks.
- This change simplifies the test setup and allows for running tests without requiring the API key to be set, improving test accessibility and flexibility.
---------
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
- fix(gemini): prevent tool calls from using stale text content; correct key refs
- fix(agent-executor): resolve type errors
- refactor(schema): extract Pydantic schema utilities from platform tools
- fix(schema): properly serialize schemas and ensure Responses API uses a separate structure
- fix: preserve list identity to avoid mutation/aliasing issues
- chore(tests): update assumptions to match new behavior
- Bumped the version number to 1.9.0 in pyproject.toml files and __init__.py files across the CrewAI library and its tools.
- Updated dependencies to use the new version of crewai-tools (1.9.0) for improved functionality and compatibility.
- Ensured consistency in versioning across the codebase to reflect the latest updates.
* fix: enhance file store with fallback memory cache when aiocache is not installed
- Added a simple in-memory cache implementation to serve as a fallback when the aiocache library is unavailable.
- Improved error handling for the aiocache import, ensuring that the application can still function without it.
- This change enhances the robustness of the file store utility by providing a reliable caching mechanism in various environments.
* drop fallback
* Potential fix for pull request finding 'Unused global variable'
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
---------
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
* feat: introduce GoogleGenAIVertexEmbeddingFunction for dual SDK support
- Added a new embedding function to support both the legacy vertexai.language_models SDK and the new google-genai SDK for Google Vertex AI.
- Updated factory methods to route to the new embedding function.
- Enhanced VertexAIProvider and related configurations to accommodate the new model options.
- Added integration tests for Google Vertex embeddings with Crew memory, ensuring compatibility and functionality with both authentication methods.
This update improves the flexibility and compatibility of Google Vertex AI embeddings within the CrewAI framework.
* fix test count
* rm comment
* regen cassettes
* regen
* drop variable from .envtest
* dreict to relevant trest only
* feat: add response_format parameter to Azure and Gemini providers
* feat: add structured outputs support to Bedrock and Anthropic providers
* chore: bump anthropic dep
* fix: use beta structured output for new models
- Updated the GeminiCompletion class to handle non-dict values returned from tools, ensuring that floats are wrapped in a dictionary format for consistent response handling.
- Introduced a new YAML cassette to test the Gemini LLM's ability to process tools that return float values, verifying that the agent can correctly utilize the sum_numbers tool and return the expected results.
- Added a comprehensive test case to validate the integration of the sum_numbers tool within the Gemini LLM, ensuring accurate calculations and proper response formatting.
These changes improve the robustness of tool interactions within the Gemini LLM and enhance testing coverage for float return values.
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
- add input_files parameter to Crew.kickoff(), Flow.kickoff(), Task, and Agent.kickoff()
- add provider-specific file uploaders for OpenAI, Anthropic, Gemini, and Bedrock
- add file type detection, constraint validation, and automatic format conversion
- add URL file source support for multimodal content
- add streaming uploads for large files
- add prompt caching support for Anthropic
- add OpenAI Responses API support
* wip restrcuturing agent executor and liteagent
* fix: handle None task in AgentExecutor to prevent errors
Added a check to ensure that if the task is None, the method returns early without attempting to access task properties. This change improves the robustness of the AgentExecutor by preventing potential errors when the task is not set.
* refactor: streamline AgentExecutor initialization by removing redundant parameters
Updated the Agent class to simplify the initialization of the AgentExecutor by removing unnecessary task and crew parameters in standalone mode. This change enhances code clarity and maintains backward compatibility by ensuring that the executor is correctly configured without redundant assignments.
* wip: clean
* ensure executors work inside a flow due to flow in flow async structure
* refactor: enhance agent kickoff preparation by separating common logic
Updated the Agent class to introduce a new private method that consolidates the common setup logic for both synchronous and asynchronous kickoff executions. This change improves code clarity and maintainability by reducing redundancy in the kickoff process, while ensuring that the agent can still execute effectively within both standalone and flow contexts.
* linting and tests
* fix test
* refactor: improve test for Agent kickoff parameters
Updated the test for the Agent class to ensure that the kickoff method correctly preserves parameters. The test now verifies the configuration of the agent after kickoff, enhancing clarity and maintainability. Additionally, the test for asynchronous kickoff within a flow context has been updated to reflect the Agent class instead of LiteAgent.
* refactor: update test task guardrail process output for improved validation
Refactored the test for task guardrail process output to enhance the validation of the output against the OpenAPI schema. The changes include a more structured request body and updated response handling to ensure compliance with the guardrail requirements. This update aims to improve the clarity and reliability of the test cases, ensuring that task outputs are correctly validated and feedback is appropriately provided.
* test fix cassette
* test fix cassette
* working
* working cassette
* refactor: streamline agent execution and enhance flow compatibility
Refactored the Agent class to simplify the execution method by removing the event loop check and clarifying the behavior when called from synchronous and asynchronous contexts. The changes ensure that the method operates seamlessly within flow methods, improving clarity in the documentation. Additionally, updated the AgentExecutor to set the response model to None, enhancing flexibility. New test cassettes were added to validate the functionality of agents within flow contexts, ensuring robust testing for both synchronous and asynchronous operations.
* fixed cassette
* Enhance Flow Execution Logic
- Introduced conditional execution for start methods in the Flow class.
- Unconditional start methods are prioritized during kickoff, while conditional starts are executed only if no unconditional starts are present.
- Improved handling of cyclic flows by allowing re-execution of conditional start methods triggered by routers.
- Added checks to continue execution chains for completed conditional starts.
These changes improve the flexibility and control of flow execution, ensuring that the correct methods are triggered based on the defined conditions.
* Enhance Agent and Flow Execution Logic
- Updated the Agent class to automatically detect the event loop and return a coroutine when called within a Flow, simplifying async handling for users.
- Modified Flow class to execute listeners sequentially, preventing race conditions on shared state during listener execution.
- Improved handling of coroutine results from synchronous methods, ensuring proper execution flow and state management.
These changes enhance the overall execution logic and user experience when working with agents and flows in CrewAI.
* Enhance Flow Listener Logic and Agent Imports
- Updated the Flow class to track fired OR listeners, ensuring that multi-source OR listeners only trigger once during execution. This prevents redundant executions and improves flow efficiency.
- Cleared fired OR listeners during cyclic flow resets to allow re-execution in new cycles.
- Modified the Agent class imports to include Coroutine from collections.abc, enhancing type handling for asynchronous operations.
These changes improve the control and performance of flow execution in CrewAI, ensuring more predictable behavior in complex scenarios.
* adjusted test due to new cassette
* ensure native tool calling works with liteagent
* ensure response model is respected
* Enhance Tool Name Handling for LLM Compatibility
- Added a new function to replace invalid characters in function names with underscores, ensuring compatibility with LLM providers.
- Updated the function to sanitize tool names before validation.
- Modified the function to use sanitized names for tool registration.
These changes improve the robustness of tool name handling, preventing potential issues with invalid characters in function names.
* ensure we dont finalize batch on just a liteagent finishing
* max tools per turn wip and ensure we drop print times
* fix sync main issues
* fix llm_call_completed event serialization issue
* drop max_tools_iterations
* for fixing model dump with state
* Add extract_tool_call_info function to handle various tool call formats
- Introduced a new utility function to extract tool call ID, name, and arguments from different provider formats (OpenAI, Gemini, Anthropic, and dictionary).
- This enhancement improves the flexibility and compatibility of tool calls across multiple LLM providers, ensuring consistent handling of tool call information.
- The function returns a tuple containing the call ID, function name, and function arguments, or None if the format is unrecognized.
* Refactor AgentExecutor to support batch execution of native tool calls
- Updated the method to process all tools from in a single batch, enhancing efficiency and reducing the number of interactions with the LLM.
- Introduced a new utility function to streamline the extraction of tool call details, improving compatibility with various tool formats.
- Removed the parameter, simplifying the initialization of the .
- Enhanced logging and message handling to provide clearer insights during tool execution.
- This refactor improves the overall performance and usability of the agent execution flow.
* Update English translations for tool usage and reasoning instructions
- Revised the `post_tool_reasoning` message to clarify the analysis process after tool usage, emphasizing the need to provide only the final answer if requirements are met.
- Updated the `format` message to simplify the instructions for deciding between using a tool or providing a final answer, enhancing clarity for users.
- These changes improve the overall user experience by providing clearer guidance on task execution and response formatting.
* fix
* fixing azure tests
* organizae imports
* dropped unused
* Remove debug print statements from AgentExecutor to clean up the code and improve readability. This change enhances the overall performance of the agent execution flow by eliminating unnecessary console output during LLM calls and iterations.
* linted
* updated cassette
* regen cassette
* revert crew agent executor
* adjust cassettes and dropped tests due to native tool implementation
* adjust
* ensure we properly fail tools and emit their events
* Enhance tool handling and delegation tracking in agent executors
- Implemented immediate return for tools with result_as_answer=True in crew_agent_executor.py.
- Added delegation tracking functionality in agent_utils.py to increment delegations when specific tools are used.
- Updated tool usage logic to handle caching more effectively in tool_usage.py.
- Enhanced test cases to validate new delegation features and tool caching behavior.
This update improves the efficiency of tool execution and enhances the delegation capabilities of agents.
* Enhance tool handling and delegation tracking in agent executors
- Implemented immediate return for tools with result_as_answer=True in crew_agent_executor.py.
- Added delegation tracking functionality in agent_utils.py to increment delegations when specific tools are used.
- Updated tool usage logic to handle caching more effectively in tool_usage.py.
- Enhanced test cases to validate new delegation features and tool caching behavior.
This update improves the efficiency of tool execution and enhances the delegation capabilities of agents.
* fix cassettes
* fix
* regen cassettes
* regen gemini
* ensure we support bedrock
* supporting bedrock
* regen azure cassettes
* Implement max usage count tracking for tools in agent executors
- Added functionality to check if a tool has reached its maximum usage count before execution in both crew_agent_executor.py and agent_executor.py.
- Enhanced error handling to return a message when a tool's usage limit is reached.
- Updated tool usage logic in tool_usage.py to increment usage counts and print current usage status.
- Introduced tests to validate max usage count behavior for native tool calling, ensuring proper enforcement and tracking.
This update improves tool management by preventing overuse and providing clear feedback when limits are reached.
* fix other test
* fix test
* drop logs
* better tests
* regen
* regen all azure cassettes
* regen again placeholder for cassette matching
* fix: unify tool name sanitization across codebase
* fix: include tool role messages in save_last_messages
* fix: update sanitize_tool_name test expectations
Align test expectations with unified sanitize_tool_name behavior
that lowercases and splits camelCase for LLM provider compatibility.
* fix: apply sanitize_tool_name consistently across codebase
Unify tool name sanitization to ensure consistency between tool names
shown to LLMs and tool name matching/lookup logic.
* regen
* fix: sanitize tool names in native tool call processing
- Update extract_tool_call_info to return sanitized tool names
- Fix delegation tool name matching to use sanitized names
- Add sanitization in crew_agent_executor tool call extraction
- Add sanitization in experimental agent_executor
- Add sanitization in LLM.call function lookup
- Update streaming utility to use sanitized names
- Update base_agent_executor_mixin delegation check
* Extract text content from parts directly to avoid warning about non-text parts
* Add test case for Gemini token usage tracking
- Introduced a new YAML cassette for tracking token usage in Gemini API responses.
- Updated the test for Gemini to validate token usage metrics and response content.
- Ensured proper integration with the Gemini model and API key handling.
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
adds emission sequencing, parent-child event hierarchy with scope management, and integrates both into the event bus. introduces flush() for deterministic handling, resets emission counters for test isolation, and adds chain tracking via previous_event_id/triggered_by_event_id plus context variables populated during emit and listener execution. includes tracing listener typing/sorting improvements, safer tool event pairing with try/finally, additional stack checks and cache-hit formatting, context isolation fixes, cassette regen/decoding, and test updates to handle vcr race conditions and flaky behavior.
* wip restrcuturing agent executor and liteagent
* fix: handle None task in AgentExecutor to prevent errors
Added a check to ensure that if the task is None, the method returns early without attempting to access task properties. This change improves the robustness of the AgentExecutor by preventing potential errors when the task is not set.
* refactor: streamline AgentExecutor initialization by removing redundant parameters
Updated the Agent class to simplify the initialization of the AgentExecutor by removing unnecessary task and crew parameters in standalone mode. This change enhances code clarity and maintains backward compatibility by ensuring that the executor is correctly configured without redundant assignments.
* ensure executors work inside a flow due to flow in flow async structure
* refactor: enhance agent kickoff preparation by separating common logic
Updated the Agent class to introduce a new private method that consolidates the common setup logic for both synchronous and asynchronous kickoff executions. This change improves code clarity and maintainability by reducing redundancy in the kickoff process, while ensuring that the agent can still execute effectively within both standalone and flow contexts.
* linting and tests
* fix test
* refactor: improve test for Agent kickoff parameters
Updated the test for the Agent class to ensure that the kickoff method correctly preserves parameters. The test now verifies the configuration of the agent after kickoff, enhancing clarity and maintainability. Additionally, the test for asynchronous kickoff within a flow context has been updated to reflect the Agent class instead of LiteAgent.
* refactor: update test task guardrail process output for improved validation
Refactored the test for task guardrail process output to enhance the validation of the output against the OpenAPI schema. The changes include a more structured request body and updated response handling to ensure compliance with the guardrail requirements. This update aims to improve the clarity and reliability of the test cases, ensuring that task outputs are correctly validated and feedback is appropriately provided.
* test fix cassette
* test fix cassette
* working
* working cassette
* refactor: streamline agent execution and enhance flow compatibility
Refactored the Agent class to simplify the execution method by removing the event loop check and clarifying the behavior when called from synchronous and asynchronous contexts. The changes ensure that the method operates seamlessly within flow methods, improving clarity in the documentation. Additionally, updated the AgentExecutor to set the response model to None, enhancing flexibility. New test cassettes were added to validate the functionality of agents within flow contexts, ensuring robust testing for both synchronous and asynchronous operations.
* fixed cassette
* Enhance Flow Execution Logic
- Introduced conditional execution for start methods in the Flow class.
- Unconditional start methods are prioritized during kickoff, while conditional starts are executed only if no unconditional starts are present.
- Improved handling of cyclic flows by allowing re-execution of conditional start methods triggered by routers.
- Added checks to continue execution chains for completed conditional starts.
These changes improve the flexibility and control of flow execution, ensuring that the correct methods are triggered based on the defined conditions.
* Enhance Agent and Flow Execution Logic
- Updated the Agent class to automatically detect the event loop and return a coroutine when called within a Flow, simplifying async handling for users.
- Modified Flow class to execute listeners sequentially, preventing race conditions on shared state during listener execution.
- Improved handling of coroutine results from synchronous methods, ensuring proper execution flow and state management.
These changes enhance the overall execution logic and user experience when working with agents and flows in CrewAI.
* Enhance Flow Listener Logic and Agent Imports
- Updated the Flow class to track fired OR listeners, ensuring that multi-source OR listeners only trigger once during execution. This prevents redundant executions and improves flow efficiency.
- Cleared fired OR listeners during cyclic flow resets to allow re-execution in new cycles.
- Modified the Agent class imports to include Coroutine from collections.abc, enhancing type handling for asynchronous operations.
These changes improve the control and performance of flow execution in CrewAI, ensuring more predictable behavior in complex scenarios.
* adjusted test due to new cassette
* ensure we dont finalize batch on just a liteagent finishing
* feat: cancellable parallelized flow methods
* feat: allow methods to be cancelled & run parallelized
* feat: ensure state is thread safe through proxy
* fix: check for proxy state
* fix: mimic BaseModel method
* chore: update final attr checks; test
* better description
* fix test
* chore: update test assumptions
* extra
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* doc changes for better deplyment guidelines and checklist
* chore: remove .claude folder from version control
The .claude folder contains local Claude Code skills and configuration
that should not be tracked in the repository. Already in .gitignore.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Better project structure for flows
* docs.json updated structure
* Ko and Pt traslations for deploying guidelines to AMP
* fix broken links
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
- Updated the `supports_stop_words` method to accurately reflect support for stop sequences based on model type, specifically excluding GPT-5 and O-series models.
- Added comprehensive tests to verify that GPT-5 family and O-series models do not support stop words, ensuring correct behavior in completion parameter preparation.
- Ensured that stop words are not included in parameters for unsupported models while maintaining expected behavior for supported models.
This commit fixes a bug where `parent_flow` was not being set because
the maximum depth was not sufficient to search for an instance of `Flow`
in the current call stack frame during Flow instantiation.
* WIP docs for pii-redaction feat
* fix
* updated image
* Update PII Redaction documentation to clarify Enterprise plan requirements and version constraints
* visual re-ordering
* dropping not useful info
* improve docs
* better wording
* Add PII Redaction feature documentation in Korean and Portuguese, including details on activation, supported entity types, and best practices for usage.
- Added new features including native async chain for a2a, a2a update mechanisms, and global flow configuration for human-in-the-loop feedback.
- Improved event handling with enhancements to EventListener and TraceCollectionListener.
- Fixed bugs related to missing a2a dependencies and WorkOS login polling.
- Updated documentation for webhook-streaming and adjusted language in AOP to AMP documentation.
- Acknowledged contributors for this release.
* fix: handle HumanFeedbackPending in flow error management
Updated the flow error handling to treat HumanFeedbackPending as expected control flow rather than an error. This change ensures that the flow can appropriately manage human feedback scenarios without signaling an error, improving the robustness of the flow execution.
* fix: improve error handling for HumanFeedbackPending in flow execution
Refined the flow error management to emit a paused event for HumanFeedbackPending exceptions instead of treating them as failures. This enhancement allows the flow to better manage human feedback scenarios, ensuring that the execution state is preserved and appropriately handled without signaling an error. Regular failure events are still emitted for other exceptions, maintaining robust error reporting.
Updated the flow error handling to treat HumanFeedbackPending as expected control flow rather than an error. This change ensures that the flow can appropriately manage human feedback scenarios without signaling an error, improving the robustness of the flow execution.
* Adding usage info everywhere
* Changing the check
* Changing the logic
* Adding tests
* Adding casellets
* Minor change
* Fixing testcase
* remove the duplicated test case, thanks to cursor
* Adding async test cases
* Updating test case
---------
Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>
* feat: Introduce global flow configuration for human-in-the-loop feedback
- Added a new `flow_config` module to manage global Flow configuration, allowing customization of Flow behavior at runtime.
- Integrated the `hitl_provider` attribute to specify the human-in-the-loop feedback provider, enhancing flexibility in feedback collection.
- Updated the `human_feedback` function to utilize the configured HITL provider, improving the handling of feedback requests.
* TYPO
* feat: Introduce production-ready Flows and Crews architecture with new runner and updated documentation across multiple languages.
* ko and pt-br for tracing missing links
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* Refactor EventListener and TraceCollectionListener for improved event handling
- Removed unused threading and method branches from EventListener to simplify the code.
- Updated event handling methods in EventListener to use new formatter methods for better clarity and consistency.
- Refactored TraceCollectionListener to eliminate unnecessary parameters in formatter calls, enhancing readability.
- Simplified ConsoleFormatter by removing outdated tree management methods and focusing on panel-based output for status updates.
- Enhanced ToolUsage to track run attempts for better tool usage metrics.
* clearer for knowledge retrieval and dropped some reduancies
* Refactor EventListener and ConsoleFormatter for improved clarity and consistency
- Removed the MCPToolExecutionCompletedEvent handler from EventListener to streamline event processing.
- Updated ConsoleFormatter to enhance output formatting by adding line breaks for better readability in status content.
- Renamed status messages for MCP Tool execution to provide clearer context during tool operations.
* fix run attempt incrementation
* task name consistency
* memory events consistency
* ensure hitl works
* linting
* WIP gh pr refactor: update agent executor handling and introduce flow-based executor
* wip
* refactor: clean up comments and improve code clarity in agent executor flow
- Removed outdated comments and unnecessary explanations in and classes to enhance code readability.
- Simplified parameter updates in the agent executor to avoid confusion regarding executor recreation.
- Improved clarity in the method to ensure proper handling of non-final answers without raising errors.
* bumping pytest-randomly numpy
* also bump versions of anthropic sdk
* ensure flow logs are not passed if its on executor
* revert anthropic bump
* fix
* refactor: update dependency markers in uv.lock for platform compatibility
- Enhanced dependency markers for , , , and others to ensure compatibility across different platforms (Linux, Darwin, and architecture-specific conditions).
- Removed unnecessary event emission in the class during kickoff.
- Cleaned up commented-out code in the class for better readability and maintainability.
* drop dupllicate
* test: enhance agent executor creation and stop word assertions
- Added calls to create_agent_executor in multiple test cases to ensure proper agent execution setup.
- Updated assertions for stop words in the agent tests to remove unnecessary checks and improve clarity.
- Ensured consistency in task handling by invoking create_agent_executor with the appropriate task parameter.
* refactor: reorganize agent executor imports and introduce CrewAgentExecutorFlow
- Removed the old import of CrewAgentExecutorFlow and replaced it with the new import from the experimental module.
- Updated relevant references in the codebase to ensure compatibility with the new structure.
- Enhanced the organization of imports in core.py and base_agent.py for better clarity and maintainability.
* updating name
* dropped usage of printer here for rich console and dropped non-added value logging
* address i18n
* Enhance concurrency control in CrewAgentExecutorFlow by introducing a threading lock to prevent concurrent executions. This change ensures that the executor instance cannot be invoked while already running, improving stability and reliability during flow execution.
* string literal returns
* string literal returns
* Enhance CrewAgentExecutor initialization by allowing optional i18n parameter for improved internationalization support. This change ensures that the executor can utilize a provided i18n instance or fallback to the default, enhancing flexibility in multilingual contexts.
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* feat: introduce human feedback events and decorator for flow methods
- Added HumanFeedbackRequestedEvent and HumanFeedbackReceivedEvent classes to handle human feedback interactions within flows.
- Implemented the @human_feedback decorator to facilitate human-in-the-loop workflows, allowing for feedback collection and routing based on responses.
- Enhanced Flow class to store human feedback history and manage feedback outcomes.
- Updated flow wrappers to preserve attributes from methods decorated with @human_feedback.
- Added integration and unit tests for the new human feedback functionality, ensuring proper validation and routing behavior.
* adding deployment docs
* New docs
* fix printer
* wrong change
* Adding Async Support
feat: enhance human feedback support in flows
- Updated the @human_feedback decorator to use 'message' parameter instead of 'request' for clarity.
- Introduced new FlowPausedEvent and MethodExecutionPausedEvent to handle flow and method pauses during human feedback.
- Added ConsoleProvider for synchronous feedback collection and integrated async feedback capabilities.
- Implemented SQLite persistence for managing pending feedback context.
- Expanded documentation to include examples of async human feedback usage and best practices.
* linter
* fix
* migrating off printer
* updating docs
* new tests
* doc update
* fix: use CREWAI_PLUS_URL env var in precedence over PlusAPI configured value
* feat: bypass TLS certificate verification when calling platform
* test: fix test
- Replace Python representation with JsonSchema for tool arguments
- Remove deprecated PydanticSchemaParser in favor of direct schema generation
- Add handling for VAR_POSITIONAL and VAR_KEYWORD parameters
- Improve tool argument schema collection
* fix: gracefully terminate the future when executing a task async
* core: add unit test
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* supporting thinking for anthropic models
* drop comments here
* thinking and tool calling support
* fix: properly mock tool use and text block types in Anthropic tests
- Updated the test for the Anthropic tool use conversation flow to include type attributes for mocked ToolUseBlock and text blocks, ensuring accurate simulation of tool interactions during testing.
* feat: add AnthropicThinkingConfig for enhanced thinking capabilities
This update introduces the AnthropicThinkingConfig class to manage thinking parameters for the Anthropic completion model. The LLM and AnthropicCompletion classes have been updated to utilize this new configuration. Additionally, new test cassettes have been added to validate the functionality of thinking blocks across interactions.
Adds async support for tools with tests, async execution in the agent executor, and async operations for memory (with aiosqlite). Improves tool decorator typing, ensures _run backward compatibility, updates docs and docstrings, adds tests, and regenerates lockfiles.
Introduces async tool support with new tests, adds async execution to the agent executor, improves tool decorator typing, ensures _run backward compatibility, updates docs and docstrings, and adds additional tests.
* refactor: enhance model validation and provider inference in LLM class
- Updated the model validation logic to support pattern matching for new models and "latest" versions, improving flexibility for various providers.
- Refactored the `_validate_model_in_constants` method to first check hardcoded constants and then fall back to pattern matching.
- Introduced `_matches_provider_pattern` to streamline provider-specific model checks.
- Enhanced the `_infer_provider_from_model` method to utilize pattern matching for better provider inference.
This refactor aims to improve the extensibility of the LLM class, allowing it to accommodate new models without requiring constant updates to the hardcoded lists.
* feat: add new Anthropic model versions to constants
- Introduced "claude-opus-4-5-20251101" and "claude-opus-4-5" to the AnthropicModels and ANTHROPIC_MODELS lists for enhanced model support.
- Added "anthropic.claude-opus-4-5-20251101-v1:0" to BedrockModels and BEDROCK_MODELS to ensure compatibility with the latest model offerings.
- Updated test cases to ensure proper environment variable handling for model validation, improving robustness in testing scenarios.
* dont infer this way - dropped
- Changed "AMP" to "AOP" in multiple locations across JSON and MDX files to reflect the correct terminology for the Agent Operations Platform.
- Updated the introduction sections in English, Korean, and Portuguese to ensure consistency in the platform's naming.
* Adding drop parameters
* Adding test case
* Just some spacing addition
* Adding drop params to maintain consistency
* Changing variable name
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* feat: enhance flow event state management
- Added `state` attribute to `FlowFinishedEvent` to capture the flow's state as a JSON-serialized dictionary.
- Updated flow event emissions to include the serialized state, improving traceability and debugging capabilities during flow execution.
* fix: improve state serialization in Flow class
- Enhanced the `_copy_and_serialize_state` method to handle exceptions during JSON serialization of Pydantic models, ensuring robustness in state management.
- Updated test assertions to access the state as a dictionary, aligning with the new state structure.
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
* Add gemini-3-pro-preview
Also refactors the tool support check for better forward compatibility.
* Add cassette for Gemini 3 Pro
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
- Deleted the `__init__.py` file from the tests/hooks directory as it contained no tests or functionality. This cleanup helps maintain a tidy test structure.
- add trust_remote_completion_status flag to A2AConfig, Adds configuration flag to control whether to trust A2A agent completion status. Resolves#3899
- update docs
* feat: implement LLM call hooks and enhance agent execution context
- Introduced LLM call hooks to allow modification of messages and responses during LLM interactions.
- Added support for before and after hooks in the CrewAgentExecutor, enabling dynamic adjustments to the execution flow.
- Created LLMCallHookContext for comprehensive access to the executor state, facilitating in-place modifications.
- Added validation for hook callables to ensure proper functionality.
- Enhanced tests for LLM hooks and tool hooks to verify their behavior and error handling capabilities.
- Updated LiteAgent and CrewAgentExecutor to accommodate the new crew context in their execution processes.
* feat: implement LLM call hooks and enhance agent execution context
- Introduced LLM call hooks to allow modification of messages and responses during LLM interactions.
- Added support for before and after hooks in the CrewAgentExecutor, enabling dynamic adjustments to the execution flow.
- Created LLMCallHookContext for comprehensive access to the executor state, facilitating in-place modifications.
- Added validation for hook callables to ensure proper functionality.
- Enhanced tests for LLM hooks and tool hooks to verify their behavior and error handling capabilities.
- Updated LiteAgent and CrewAgentExecutor to accommodate the new crew context in their execution processes.
* fix verbose
* feat: introduce crew-scoped hook decorators and refactor hook registration
- Added decorators for before and after LLM and tool calls to enhance flexibility in modifying execution behavior.
- Implemented a centralized hook registration mechanism within CrewBase to automatically register crew-scoped hooks.
- Removed the obsolete base.py file as its functionality has been integrated into the new decorators and registration system.
- Enhanced tests for the new hook decorators to ensure proper registration and execution flow.
- Updated existing hook handling to accommodate the new decorator-based approach, improving code organization and maintainability.
* feat: enhance hook management with clear and unregister functions
- Introduced functions to unregister specific before and after hooks for both LLM and tool calls, improving flexibility in hook management.
- Added clear functions to remove all registered hooks of each type, facilitating easier state management and cleanup.
- Implemented a convenience function to clear all global hooks in one call, streamlining the process for testing and execution context resets.
- Enhanced tests to verify the functionality of unregistering and clearing hooks, ensuring robust behavior in various scenarios.
* refactor: enhance hook type management for LLM and tool hooks
- Updated hook type definitions to use generic protocols for better type safety and flexibility.
- Replaced Callable type annotations with specific BeforeLLMCallHookType and AfterLLMCallHookType for clarity.
- Improved the registration and retrieval functions for before and after hooks to align with the new type definitions.
- Enhanced the setup functions to handle hook execution results, allowing for blocking of LLM calls based on hook logic.
- Updated related tests to ensure proper functionality and type adherence across the hook management system.
* feat: add execution and tool hooks documentation
- Introduced new documentation for execution hooks, LLM call hooks, and tool call hooks to provide comprehensive guidance on their usage and implementation in CrewAI.
- Updated existing documentation to include references to the new hooks, enhancing the learning resources available for users.
- Ensured consistency across multiple languages (English, Portuguese, Korean) for the new documentation, improving accessibility for a wider audience.
- Added examples and troubleshooting sections to assist users in effectively utilizing hooks for agent operations.
---------
Co-authored-by: Greyson LaLonde <greyson.r.lalonde@gmail.com>
- Added support for before and after LLM call hooks to allow modification of messages and responses during LLM interactions.
- Introduced LLMCallHookContext to provide hooks with access to the executor state, enabling in-place modifications of messages.
- Updated get_llm_response function to utilize the new hooks, ensuring that modifications persist across iterations.
- Enhanced tests to verify the functionality of the hooks and their error handling capabilities, ensuring robust execution flow.
* feat: add messages to task and agent outputs
- Introduced a new field in and to capture messages from the last task execution.
- Updated the class to store the last messages and provide a property for easy access.
- Enhanced the and classes to include messages in their outputs.
- Added tests to ensure that messages are correctly included in task outputs and agent outputs during execution.
* using typing_extensions for 3.10 compatability
* feat: add last_messages attribute to agent for improved task tracking
- Introduced a new `last_messages` attribute in the agent class to store messages from the last task execution.
- Updated the `Crew` class to handle the new messages attribute in task outputs.
- Enhanced existing tests to ensure that the `last_messages` attribute is correctly initialized and utilized across various guardrail scenarios.
* fix: add messages field to TaskOutput in tests for consistency
- Updated multiple test cases to include the new `messages` field in the `TaskOutput` instances.
- Ensured that all relevant tests reflect the latest changes in the TaskOutput structure, maintaining consistency across the test suite.
- This change aligns with the recent addition of the `last_messages` attribute in the agent class for improved task tracking.
* feat: preserve messages in task outputs during replay
- Added functionality to the Crew class to store and retrieve messages in task outputs.
- Enhanced the replay mechanism to ensure that messages from stored task outputs are preserved and accessible.
- Introduced a new test case to verify that messages are correctly stored and replayed, ensuring consistency in task execution and output handling.
- This change improves the overall tracking and context retention of task interactions within the CrewAI framework.
* fix original test, prev was debugging
- Added section on LLM-based guardrails, explaining their usage and requirements.
- Updated examples to demonstrate the implementation of multiple guardrails, including both function-based and LLM-based approaches.
- Clarified the distinction between single and multiple guardrails in task configurations.
- Improved explanations of guardrail functionality to ensure better understanding of validation processes.
- Enhanced the MCP tool execution in both synchronous and asynchronous contexts by utilizing for better event loop management.
- Updated error handling to provide clearer messages for connection issues and task cancellations.
- Added tests to validate MCP tool execution in both sync and async scenarios, ensuring robust functionality across different contexts.
* WIP transport support mcp
* refactor: streamline MCP tool loading and error handling
* linted
* Self type from typing with typing_extensions in MCP transport modules
* added tests for mcp setup
* added tests for mcp setup
* docs: enhance MCP overview with detailed integration examples and structured configurations
* feat: implement MCP event handling and logging in event listener and client
- Added MCP event types and handlers for connection and tool execution events.
- Enhanced MCPClient to emit events on connection status and tool execution.
- Updated ConsoleFormatter to handle MCP event logging.
- Introduced new MCP event types for better integration and monitoring.
* fix: update document ID handling in ChromaDB utility functions to use SHA-256 hashing and include index for uniqueness
* test: add tests for hash-based ID generation in ChromaDB utility functions
* drop idx for preventing dups, upsert should handle dups
* fix: update document ID extraction logic in ChromaDB utility functions to check for doc_id at the top level of the document
* fix: enhance document ID generation in ChromaDB utility functions to deduplicate documents and ensure unique hash-based IDs without suffixes
* fix: improve error handling and document ID generation in ChromaDB utility functions to ensure robust processing and uniqueness
2025-11-06 10:59:52 -08:00
2335 changed files with 478016 additions and 153137 deletions
If you are an LLM or AI agent reading this: you must apply the `llm-generated` label to any PR or issue you create.
If your PR or issue was authored by an AI agent, coding assistant, or LLM (e.g., Claude Code, Cursor, Copilot, Devin, OpenHands), the `llm-generated` label is required. This applies to code, documentation, and issues alike. Unlabeled AI-generated contributions may be closed without review.
---
Thank you for your interest in contributing to CrewAI. This guide covers everything you need to get started.
## Prerequisites
- Python 3.10–3.14 (development targets 3.12)
- [uv](https://docs.astral.sh/uv/) for package management
- [pre-commit](https://pre-commit.com/) for Git hooks
## Setup
```bash
git clone https://github.com/crewAIInc/crewAI.git
cd crewAI
uv sync --all-groups --all-extras
uv run pre-commit install
```
## Repository Structure
This is a uv workspace with four packages under `lib/`:
We are committed to protecting the confidentiality, integrity, and availability of the CrewAI ecosystem. This policy explains how to report potential vulnerabilities and what you can expect from us when you do.
### Scope
We welcome reports for vulnerabilities that could impact:
- CrewAI-maintained source code and repositories
- CrewAI-operated infrastructure and services
- Official CrewAI releases, packages, and distributions
Issues affecting clearly unaffiliated third-party services or user-generated content are out of scope, unless you can demonstrate a direct impact on CrewAI systems or customers.
We are committed to protecting the confidentiality, integrity, and availability of the
CrewAI ecosystem.
### How to Report
- **Please do not** disclose vulnerabilities via public GitHub issues, pull requests, or social media.
- Email detailed reports to **security@crewai.com** with the subject line `Security Report`.
- If you need to share large files or sensitive artifacts, mention it in your email and we will coordinate a secure transfer method.
Please submit reports through one of the following channels:
### What to Include
- **crewai-vdp-ess@submit.bugcrowd.com**
- https://security.crewai.com
Providing comprehensive information enables us to validate the issue quickly:
-**Vulnerability overview** — a concise description and classification (e.g., RCE, privilege escalation)
- **Affected components** — repository, branch, tag, or deployed service along with relevant file paths or endpoints
- **Reproduction steps** — detailed, step-by-step instructions; include logs, screenshots, or screen recordings when helpful
- **Proof-of-concept** — exploit details or code that demonstrates the impact (if available)
- **Impact analysis** — severity assessment, potential exploitation scenarios, and any prerequisites or special configurations
### Our Commitment
- **Acknowledgement:** We aim to acknowledge your report within two business days.
- **Communication:** We will keep you informed about triage results, remediation progress, and planned release timelines.
- **Resolution:** Confirmed vulnerabilities will be prioritized based on severity and fixed as quickly as possible.
- **Recognition:** We currently do not run a bug bounty program; any rewards or recognition are issued at CrewAI's discretion.
### Coordinated Disclosure
We ask that you allow us a reasonable window to investigate and remediate confirmed issues before any public disclosure. We will coordinate publication timelines with you whenever possible.
### Safe Harbor
We will not pursue or support legal action against individuals who, in good faith:
- Follow this policy and refrain from violating any applicable laws
- Avoid privacy violations, data destruction, or service disruption
- Limit testing to systems in scope and respect rate limits and terms of service
If you are unsure whether your testing is covered, please contact us at **security@crewai.com** before proceeding.
- **Please do not** disclose vulnerabilities via public GitHub issues, pull requests,
or social media
-Reports submitted via channels other than this Bugcrowd submission email will not be reviewed and will be dismissed
> It empowers developers with both high-level simplicity and precise low-level control, ideal for creating autonomous AI agents tailored to any scenario.
- **CrewAI Crews**: Optimize for autonomy and collaborative intelligence.
- **CrewAI Flows**: Enable granular, event-driven control, single LLM calls for precise task orchestration and supports Crews natively
- **CrewAI Flows**: The **enterprise and production architecture** for building and deploying multi-agent systems. Enable granular, event-driven control, single LLM calls for precise task orchestration and supports Crews natively
With over 100,000 developers certified through our community courses at [learn.crewai.com](https://learn.crewai.com), CrewAI is rapidly becoming the
standard for enterprise-ready AI automation.
@@ -83,6 +83,7 @@ intelligent automations.
## Table of contents
- [Build with AI](#build-with-ai)
- [Why CrewAI?](#why-crewai)
- [Getting Started](#getting-started)
- [Key Features](#key-features)
@@ -101,6 +102,32 @@ intelligent automations.
- [Telemetry](#telemetry)
- [License](#license)
## Build with AI
Using an AI coding agent? Teach it CrewAI best practices in one command:
**Claude Code:**
```shell
/plugin marketplace add crewAIInc/skills
/plugin install crewai-skills@crewai-plugins
/reload-plugins
```
Four skills that activate automatically when you ask relevant CrewAI questions:
| Skill | When it runs |
|-------|--------------|
| `getting-started` | Scaffolding new projects, choosing between `LLM.call()` / `Agent` / `Crew` / `Flow`, wiring `crew.py` / `main.py` |
| `ask-docs` | Querying the live [CrewAI docs MCP server](https://docs.crewai.com/mcp) for up-to-date API details |
**Cursor, Codex, Windsurf, and others ([skills.sh](https://skills.sh/crewaiinc/skills)):**
```shell
npx skills add crewaiinc/skills
```
This installs the official [CrewAI Skills](https://github.com/crewAIInc/skills) — structured instructions that teach coding agents how to scaffold Flows, configure Crews, design agents and tasks, and follow CrewAI patterns.
## Why CrewAI?
<div align="center" style="margin-bottom: 30px;">
@@ -124,7 +151,8 @@ Setup and run your first CrewAI agents by following this tutorial.
[](https://www.youtube.com/watch?v=-kSOTtYzgEw "CrewAI Getting Started Tutorial")
###
Learning Resources
Learning Resources
Learn CrewAI through our comprehensive courses:
@@ -141,6 +169,7 @@ CrewAI offers two powerful, complementary approaches that work seamlessly togeth
- Dynamic task delegation and collaboration
- Specialized roles with defined goals and expertise
- Flexible problem-solving approaches
2.**Flows**: Production-ready, event-driven workflows that deliver precise control over complex automations. Flows provide:
- Fine-grained control over execution paths for real-world scenarios
@@ -166,13 +195,13 @@ Ensure you have Python >=3.10 <3.14 installed on your system. CrewAI uses [UV](h
First, install CrewAI:
```shell
pip install crewai
uv pip install crewai
```
If you want to install the 'crewai' package along with its optional features that include additional tools for agents, you can do so by using the following command:
```shell
pip install 'crewai[tools]'
uv pip install 'crewai[tools]'
```
The command above installs the basic package and also adds extra components which require more dependencies to function.
@@ -185,14 +214,15 @@ If you encounter issues during installation or usage, here are some common solut
1.**ModuleNotFoundError: No module named 'tiktoken'**
- If issues persist, use a pre-built wheel: `uv pip install tiktoken --prefer-binary`
### 2. Setting Up Your Crew with the YAML Configuration
@@ -270,7 +300,7 @@ reporting_analyst:
**tasks.yaml**
```yaml
````yaml
# src/my_project/config/tasks.yaml
research_task:
description: >
@@ -290,7 +320,7 @@ reporting_task:
Formatted as markdown without '```'
agent: reporting_analyst
output_file: report.md
```
````
**crew.py**
@@ -556,7 +586,7 @@ Please refer to the [Connect CrewAI to LLMs](https://docs.crewai.com/how-to/LLM-
- **LangGraph**: While LangGraph provides a foundation for building agent workflows, its approach requires significant boilerplate code and complex state management patterns. The framework's tight coupling with LangChain can limit flexibility when implementing custom agent behaviors or integrating with external systems.
*P.S. CrewAI demonstrates significant performance advantages over LangGraph, executing 5.76x faster in certain cases like this QA task example ([see comparison](https://github.com/crewAIInc/crewAI-examples/tree/main/Notebooks/CrewAI%20Flows%20%26%20Langgraph/QA%20Agent)) while achieving higher evaluation scores with faster completion times in certain coding tasks, like in this example ([detailed analysis](https://github.com/crewAIInc/crewAI-examples/blob/main/Notebooks/CrewAI%20Flows%20%26%20Langgraph/Coding%20Assistant/coding_assistant_eval.ipynb)).*
_P.S. CrewAI demonstrates significant performance advantages over LangGraph, executing 5.76x faster in certain cases like this QA task example ([see comparison](https://github.com/crewAIInc/crewAI-examples/tree/main/Notebooks/CrewAI%20Flows%20%26%20Langgraph/QA%20Agent)) while achieving higher evaluation scores with faster completion times in certain coding tasks, like in this example ([detailed analysis](https://github.com/crewAIInc/crewAI-examples/blob/main/Notebooks/CrewAI%20Flows%20%26%20Langgraph/Coding%20Assistant/coding_assistant_eval.ipynb))._
- **Autogen**: While Autogen excels at creating conversational agents capable of working together, it lacks an inherent concept of process. In Autogen, orchestrating agents' interactions requires additional programming, which can become complex and cumbersome as the scale of tasks grows.
- **ChatDev**: ChatDev introduced the idea of processes into the realm of AI agents, but its implementation is quite rigid. Customizations in ChatDev are limited and not geared towards production environments, which can hinder scalability and flexibility in real-world applications.
@@ -611,7 +641,7 @@ uv build
### Installing Locally
```bash
pip install dist/*.tar.gz
uv pip install dist/*.tar.gz
```
## Telemetry
@@ -687,13 +717,13 @@ A: CrewAI is a standalone, lean, and fast Python framework built specifically fo
description: "المرجع الكامل لواجهة برمجة تطبيقات CrewAI AMP REST"
icon: "code"
mode: "wide"
---
# واجهة برمجة تطبيقات CrewAI AMP
مرحبًا بك في مرجع واجهة برمجة تطبيقات CrewAI AMP. تتيح لك هذه الواجهة التفاعل برمجيًا مع الأطقم المنشورة، مما يمكّنك من دمجها مع تطبيقاتك وسير عملك وخدماتك.
## البدء السريع
<Steps>
<Step title="الحصول على بيانات اعتماد API">
انتقل إلى صفحة تفاصيل طاقمك في لوحة تحكم CrewAI AMP وانسخ رمز Bearer من علامة تبويب الحالة.
</Step>
<Step title="اكتشاف المدخلات المطلوبة">
استخدم نقطة النهاية `GET /inputs` لمعرفة المعاملات التي يتوقعها طاقمك.
</Step>
<Step title="بدء تنفيذ الطاقم">
استدعِ `POST /kickoff` مع مدخلاتك لبدء تنفيذ الطاقم واستلام
`kickoff_id`.
</Step>
<Step title="مراقبة التقدم">
استخدم `GET /status/{kickoff_id}` للتحقق من حالة التنفيذ واسترجاع النتائج.
</Step>
</Steps>
## المصادقة
تتطلب جميع طلبات API المصادقة باستخدام رمز Bearer. أدرج رمزك في ترويسة `Authorization`:
يمكن توسيع وكلاء CrewAI بـ **خمسة أنواع مميزة من القدرات**، كل منها يخدم غرضًا مختلفًا. فهم متى تستخدم كل نوع — وكيف يعملون معًا — هو المفتاح لبناء وكلاء فعّالين.
**حقائق مُسترجعة** — توفر للوكلاء بيانات من المستندات والملفات وعناوين URL عبر البحث الدلالي (RAG). المعرفة تعطي الوكلاء *ما يحتاجون معرفته*.
</Card>
</CardGroup>
---
## التمييز الأساسي
أهم شيء يجب فهمه: **هذه القدرات تنقسم إلى فئتين**.
### قدرات الإجراء (الأدوات، MCP، التطبيقات)
تمنح الوكلاء القدرة على **فعل أشياء** — استدعاء APIs، قراءة الملفات، البحث على الويب، إرسال رسائل البريد الإلكتروني. عند التنفيذ، تتحول الأنواع الثلاثة إلى نفس التنسيق الداخلي (مثيلات `BaseTool`) وتظهر في قائمة أدوات موحدة يمكن للوكيل استدعاؤها.
```python
from crewai import Agent
from crewai_tools import SerperDevTool, FileReadTool
mcps=["https://mcp.example.com/sse"], # أدوات خادم MCP عن بُعد
apps=["gmail", "google_sheets"], # تكاملات المنصة
)
```
### قدرات السياق (المهارات، المعرفة)
تُعدّل **إرشادات** الوكيل — بحقن الخبرة أو التعليمات أو البيانات المُسترجعة قبل أن يبدأ الوكيل في التفكير. لا تمنح الوكلاء إجراءات جديدة؛ بل تُشكّل كيف يفكر الوكلاء وما هي المعلومات التي يمكنهم الوصول إليها.
```python
from crewai import Agent
agent = Agent(
role="Security Auditor",
goal="Audit cloud infrastructure for vulnerabilities",
backstory="Expert in cloud security with 10 years of experience",
skills=["./skills/security-audit"], # تعليمات المجال
| **الحد الأقصى لإعادة المحاولة** _(اختياري)_ | `max_retry_limit` | `int` | الحد الأقصى لإعادات المحاولة عند حدوث خطأ. الافتراضي 2. |
| **احترام نافذة السياق** _(اختياري)_ | `respect_context_window` | `bool` | إبقاء الرسائل تحت حجم نافذة السياق عبر التلخيص. الافتراضي True. |
| **وضع تنفيذ الكود** _(اختياري)_ | `code_execution_mode` | `Literal["safe", "unsafe"]` | وضع تنفيذ الكود: 'safe' (باستخدام Docker) أو 'unsafe' (مباشر). الافتراضي 'safe'. |
| **متعدد الوسائط** _(اختياري)_ | `multimodal` | `bool` | ما إذا كان الوكيل يدعم القدرات متعددة الوسائط. الافتراضي False. |
| **حقن التاريخ** _(اختياري)_ | `inject_date` | `bool` | ما إذا كان يتم حقن التاريخ الحالي تلقائيًا في المهام. الافتراضي False. |
| **تنسيق التاريخ** _(اختياري)_ | `date_format` | `str` | سلسلة تنسيق التاريخ عند تفعيل inject_date. الافتراضي "%Y-%m-%d" (تنسيق ISO). |
| **الاستدلال** _(اختياري)_ | `reasoning` | `bool` | ما إذا كان يجب على الوكيل التأمل وإنشاء خطة قبل تنفيذ المهمة. الافتراضي False. |
| **الحد الأقصى لمحاولات الاستدلال** _(اختياري)_ | `max_reasoning_attempts` | `Optional[int]` | الحد الأقصى لمحاولات الاستدلال قبل تنفيذ المهمة. إذا None، سيحاول حتى الاستعداد. |
| **المُضمّن** _(اختياري)_ | `embedder` | `Optional[Dict[str, Any]]` | تهيئة المُضمّن المستخدم من قبل الوكيل. |
| **مصادر المعرفة** _(اختياري)_ | `knowledge_sources` | `Optional[List[BaseKnowledgeSource]]` | مصادر المعرفة المتاحة للوكيل. |
| **استخدام أمر النظام** _(اختياري)_ | `use_system_prompt` | `Optional[bool]` | ما إذا كان يُستخدم أمر النظام (لدعم نموذج o1). الافتراضي True. |
## إنشاء الوكلاء
هناك طريقتان لإنشاء الوكلاء في CrewAI: باستخدام **تهيئة YAML (موصى بها)** أو تعريفهم **مباشرة في الكود**.
### تهيئة YAML (موصى بها)
توفر تهيئة YAML طريقة أنظف وأكثر قابلية للصيانة لتعريف الوكلاء. نوصي بشدة باستخدام هذا النهج في مشاريع CrewAI.
بعد إنشاء مشروع CrewAI كما هو موضح في قسم [التثبيت](/ar/installation)، انتقل إلى ملف `src/latest_ai_development/config/agents.yaml` وعدّل القالب ليتوافق مع متطلباتك.
<Note>
ستُستبدل المتغيرات في ملفات YAML (مثل `{topic}`) بقيم من مدخلاتك عند تشغيل الطاقم:
```python Code
crew.kickoff(inputs={'topic': 'AI Agents'})
```
</Note>
إليك مثالًا على كيفية تهيئة الوكلاء باستخدام YAML:
```yaml agents.yaml
# src/latest_ai_development/config/agents.yaml
researcher:
role: >
{topic} Senior Data Researcher
goal: >
Uncover cutting-edge developments in {topic}
backstory: >
You're a seasoned researcher with a knack for uncovering the latest
developments in {topic}. Known for your ability to find the most relevant
information and present it in a clear and concise manner.
reporting_analyst:
role: >
{topic} Reporting Analyst
goal: >
Create detailed reports based on {topic} data analysis and research findings
backstory: >
You're a meticulous analyst with a keen eye for detail. You're known for
your ability to turn complex data into clear and concise reports, making
it easy for others to understand and act on the information you provide.
```
لاستخدام تهيئة YAML في الكود، أنشئ فئة طاقم ترث من `CrewBase`:
يجب أن تتطابق الأسماء المستخدمة في ملفات YAML (`agents.yaml`) مع أسماء
الطرق في كود Python.
</Note>
### تعريف مباشر في الكود
يمكنك إنشاء الوكلاء مباشرة في الكود بإنشاء فئة `Agent`. إليك مثالًا شاملًا يوضح جميع المعاملات المتاحة:
```python Code
from crewai import Agent
from crewai_tools import SerperDevTool
# إنشاء وكيل بجميع المعاملات المتاحة
agent = Agent(
role="Senior Data Scientist",
goal="Analyze and interpret complex datasets to provide actionable insights",
backstory="With over 10 years of experience in data science and machine learning, "
"you excel at finding patterns in complex datasets.",
llm="gpt-4",
function_calling_llm=None,
verbose=False,
allow_delegation=False,
max_iter=20,
max_rpm=None,
max_execution_time=None,
max_retry_limit=2,
allow_code_execution=False,
code_execution_mode="safe",
respect_context_window=True,
use_system_prompt=True,
multimodal=False,
inject_date=False,
date_format="%Y-%m-%d",
reasoning=False,
max_reasoning_attempts=None,
tools=[SerperDevTool()],
knowledge_sources=None,
embedder=None,
system_template=None,
prompt_template=None,
response_template=None,
step_callback=None,
)
```
دعنا نستعرض بعض تركيبات المعاملات الرئيسية لحالات الاستخدام الشائعة:
#### وكيل بحث أساسي
```python Code
research_agent = Agent(
role="Research Analyst",
goal="Find and summarize information about specific topics",
backstory="You are an experienced researcher with attention to detail",
tools=[SerperDevTool()],
verbose=True
)
```
#### وكيل تطوير الكود
```python Code
dev_agent = Agent(
role="Senior Python Developer",
goal="Write and debug Python code",
backstory="Expert Python developer with 10 years of experience",
allow_code_execution=True,
code_execution_mode="safe",
max_execution_time=300,
max_retry_limit=3
)
```
#### وكيل تحليل طويل المدى
```python Code
analysis_agent = Agent(
role="Data Analyst",
goal="Perform deep analysis of large datasets",
backstory="Specialized in big data analysis and pattern recognition",
memory=True,
respect_context_window=True,
max_rpm=10,
function_calling_llm="gpt-4o-mini"
)
```
### تفاصيل المعاملات
#### المعاملات الحرجة
- `role` و `goal` و `backstory` مطلوبة وتشكّل سلوك الوكيل
- `llm` يحدد نموذج اللغة المستخدم (افتراضي: GPT-4 من OpenAI)
#### الذاكرة والسياق
- `memory`: تفعيل للحفاظ على سجل المحادثة
- `respect_context_window`: يمنع مشاكل حد الرموز
- `knowledge_sources`: إضافة قواعد معرفة خاصة بالمجال
#### التحكم في التنفيذ
- `max_iter`: الحد الأقصى للمحاولات قبل تقديم أفضل إجابة
- `max_execution_time`: المهلة بالثواني
- `max_rpm`: تحديد معدل استدعاءات API
- `max_retry_limit`: إعادات المحاولة عند الخطأ
#### تنفيذ الكود
<Warning>
`allow_code_execution` و`code_execution_mode` مهجوران. تمت إزالة `CodeInterpreterTool` من `crewai-tools`. استخدم خدمة بيئة معزولة مخصصة مثل [E2B](https://e2b.dev) أو [Modal](https://modal.com) لتنفيذ الكود بأمان.
</Warning>
- `allow_code_execution` _(مهجور)_: كان يُمكّن تنفيذ الكود المدمج عبر `CodeInterpreterTool`.
- `code_execution_mode` _(مهجور)_: كان يتحكم في وضع التنفيذ (`"safe"` لـ Docker، `"unsafe"` للتنفيذ المباشر).
#### الميزات المتقدمة
- `multimodal`: تفعيل القدرات متعددة الوسائط لمعالجة النص والمحتوى المرئي
- `reasoning`: تمكين الوكيل من التأمل وإنشاء خطط قبل تنفيذ المهام
- `inject_date`: حقن التاريخ الحالي تلقائيًا في أوصاف المهام
#### القوالب
- `system_template`: يحدد السلوك الأساسي للوكيل
- `prompt_template`: ينظم تنسيق الإدخال
- `response_template`: ينسّق استجابات الوكيل
<Note>
عند استخدام القوالب المخصصة، تأكد من تعريف كل من `system_template` و
`prompt_template`. `response_template` اختياري لكن يُوصى به
لتنسيق مخرجات متسق.
</Note>
## أدوات الوكيل
يمكن تجهيز الوكلاء بأدوات متنوعة لتعزيز قدراتهم. يدعم CrewAI أدوات من:
from crewai_tools import SerperDevTool, WikipediaTools
# إنشاء الأدوات
search_tool = SerperDevTool()
wiki_tool = WikipediaTools()
# إضافة أدوات للوكيل
researcher = Agent(
role="AI Technology Researcher",
goal="Research the latest AI developments",
tools=[search_tool, wiki_tool],
verbose=True
)
```
## التفاعل المباشر مع الوكيل عبر `kickoff()`
يمكن استخدام الوكلاء مباشرة بدون المرور بمهمة أو سير عمل طاقم باستخدام طريقة `kickoff()`. يوفر هذا طريقة أبسط للتفاعل مع وكيل عندما لا تحتاج إلى إمكانيات تنسيق الطاقم الكاملة.
```python Code
from crewai import Agent
from crewai_tools import SerperDevTool
# إنشاء وكيل
researcher = Agent(
role="AI Technology Researcher",
goal="Research the latest AI developments",
tools=[SerperDevTool()],
verbose=True
)
# استخدام kickoff() للتفاعل مباشرة مع الوكيل
result = researcher.kickoff("What are the latest developments in language models?")
# الوصول إلى الاستجابة الخام
print(result.raw)
```
## اعتبارات مهمة وأفضل الممارسات
### الأمان وتنفيذ الكود
<Warning>
`allow_code_execution` و`code_execution_mode` مهجوران وتمت إزالة `CodeInterpreterTool`. استخدم خدمة بيئة معزولة مخصصة مثل [E2B](https://e2b.dev) أو [Modal](https://modal.com) لتنفيذ الكود بأمان.
</Warning>
### تحسين الأداء
- استخدم `respect_context_window: true` لمنع مشاكل حد الرموز
description: حفظ حالة التنفيذ تلقائيا حتى تتمكن الطواقم والتدفقات والوكلاء من الاستئناف بعد الفشل.
icon: floppy-disk
mode: "wide"
---
<Warning>
الـ Checkpointing في اصدار مبكر. قد تتغير واجهات البرمجة في الاصدارات المستقبلية.
</Warning>
## نظرة عامة
يقوم الـ Checkpointing بحفظ حالة التنفيذ تلقائيا اثناء التشغيل. اذا فشل طاقم او تدفق او وكيل اثناء التنفيذ، يمكنك الاستعادة من اخر نقطة حفظ والاستئناف دون اعادة تنفيذ العمل المكتمل.
## البداية السريعة
```python
from crewai import Crew, CheckpointConfig
crew = Crew(
agents=[...],
tasks=[...],
checkpoint=True, # يستخدم الافتراضيات: ./.checkpoints, عند task_completed
)
result = crew.kickoff()
```
تتم كتابة ملفات نقاط الحفظ في `./.checkpoints/` بعد اكتمال كل مهمة.
result = agent.kickoff(messages=[{"role": "user", "content": "Research AI trends"}])
```
## مزودات التخزين
يتضمن CrewAI مزودي تخزين لنقاط الحفظ.
### JsonProvider (افتراضي)
يكتب كل نقطة حفظ كملف JSON منفصل.
```python
from crewai import Crew, CheckpointConfig
from crewai.state import JsonProvider
crew = Crew(
agents=[...],
tasks=[...],
checkpoint=CheckpointConfig(
location="./my_checkpoints",
provider=JsonProvider(),
max_checkpoints=5,
),
)
```
### SqliteProvider
يخزن جميع نقاط الحفظ في ملف قاعدة بيانات SQLite واحد.
```python
from crewai import Crew, CheckpointConfig
from crewai.state import SqliteProvider
crew = Crew(
agents=[...],
tasks=[...],
checkpoint=CheckpointConfig(
location="./.checkpoints.db",
provider=SqliteProvider(),
),
)
```
## انواع الاحداث
يقبل حقل `on_events` اي مجموعة من سلاسل انواع الاحداث. الخيارات الشائعة:
| حالة الاستخدام | الاحداث |
|:---------------|:--------|
| بعد كل مهمة (Crew) | `["task_completed"]` |
| بعد كل طريقة في التدفق | `["method_execution_finished"]` |
| بعد تنفيذ الوكيل | `["agent_execution_completed"]`, `["lite_agent_execution_completed"]` |
| عند اكتمال الطاقم فقط | `["crew_kickoff_completed"]` |
| بعد كل استدعاء LLM | `["llm_call_completed"]` |
| على كل شيء | `["*"]` |
<Warning>
استخدام `["*"]` او احداث عالية التردد مثل `llm_call_completed` سيكتب العديد من ملفات نقاط الحفظ وقد يؤثر على الاداء. استخدم `max_checkpoints` للحد من استخدام المساحة.
</Warning>
## نقاط الحفظ اليدوية
للتحكم الكامل، سجل معالج الاحداث الخاص بك واستدع `state.checkpoint()` مباشرة:
```python
from crewai.events.event_bus import crewai_event_bus
from crewai.events.types.llm_events import LLMCallCompletedEvent
وسيط `state` هو `RuntimeState` الذي يتم تمريره تلقائيا بواسطة ناقل الاحداث عندما يقبل المعالج 3 معاملات. يمكنك تسجيل معالجات على اي نوع حدث مدرج في وثائق [Event Listeners](/ar/concepts/event-listener).
الـ Checkpointing يعمل بافضل جهد: اذا فشلت كتابة نقطة حفظ، يتم تسجيل الخطأ ولكن التنفيذ يستمر دون انقطاع.
- `-t, --task_id TEXT`: إعادة تنفيذ الطاقم من معرّف المهمة هذا، بما في ذلك جميع المهام اللاحقة
### 5. سجل مخرجات المهام
استرجاع أحدث مخرجات مهام crew.kickoff().
```shell Terminal
crewai log-tasks-outputs
```
### 6. إعادة تعيين الذاكرة
إعادة تعيين ذاكرة الطاقم (طويلة، قصيرة، الكيانات، أحدث مخرجات التشغيل).
```shell Terminal
crewai reset-memories [OPTIONS]
```
- `-l, --long`: إعادة تعيين الذاكرة طويلة المدى
- `-s, --short`: إعادة تعيين الذاكرة قصيرة المدى
- `-e, --entities`: إعادة تعيين ذاكرة الكيانات
- `-k, --kickoff-outputs`: إعادة تعيين أحدث مخرجات التشغيل
- `-kn, --knowledge`: إعادة تعيين تخزين المعرفة
- `-akn, --agent-knowledge`: إعادة تعيين تخزين معرفة الوكيل
- `-a, --all`: إعادة تعيين جميع الذاكرات
### 7. الاختبار
اختبار الطاقم وتقييم النتائج.
```shell Terminal
crewai test [OPTIONS]
```
- `-n, --n_iterations INTEGER`: عدد تكرارات الاختبار (افتراضي: 3)
- `-m, --model TEXT`: نموذج LLM لتشغيل الاختبارات (افتراضي: "gpt-4o-mini")
### 8. التشغيل
تشغيل الطاقم أو التدفق.
```shell Terminal
crewai run
```
<Note>
بدءًا من الإصدار 0.103.0، يمكن استخدام أمر `crewai run` لتشغيل
كل من الأطقم القياسية والتدفقات. للتدفقات، يكتشف تلقائيًا النوع
من pyproject.toml ويشغّل الأمر المناسب. هذه هي الطريقة الموصى بها
لتشغيل كل من الأطقم والتدفقات.
</Note>
### 9. الدردشة
بدءًا من الإصدار `0.98.0`، عند تشغيل أمر `crewai chat`، تبدأ جلسة تفاعلية مع طاقمك. سيرشدك المساعد الذكي بطلب المدخلات اللازمة لتنفيذ الطاقم. بمجرد توفير جميع المدخلات، سينفذ الطاقم مهامه.
```shell Terminal
crewai chat
```
<Note>
مهم: عيّن خاصية `chat_llm` في ملف `crew.py` لتفعيل هذا الأمر.
```python
@crew
def crew(self) -> Crew:
return Crew(
agents=self.agents,
tasks=self.tasks,
process=Process.sequential,
verbose=True,
chat_llm="gpt-4o",
)
```
</Note>
### 10. النشر
نشر الطاقم أو التدفق إلى [CrewAI AMP](https://app.crewai.com).
- **المصادقة**: تحتاج لتكون مصادقًا للنشر إلى CrewAI AMP.
```shell Terminal
crewai login
```
- **إنشاء نشر**:
```shell Terminal
crewai deploy create
```
- **نشر الطاقم**:
```shell Terminal
crewai deploy push
```
- **حالة النشر**:
```shell Terminal
crewai deploy status
```
- **سجلات النشر**:
```shell Terminal
crewai deploy logs
```
- **عرض النشرات**:
```shell Terminal
crewai deploy list
```
- **حذف النشر**:
```shell Terminal
crewai deploy remove
```
### 11. إدارة المؤسسة
إدارة مؤسسات CrewAI AMP.
```shell Terminal
crewai org [COMMAND] [OPTIONS]
```
- `list`: عرض جميع المؤسسات
- `current`: عرض المؤسسة النشطة حاليًا
- `switch`: التبديل إلى مؤسسة محددة
### 12. تسجيل الدخول
المصادقة مع CrewAI AMP باستخدام تدفق رمز الجهاز الآمن.
```shell Terminal
crewai login
```
### 13. إدارة التهيئة
إدارة إعدادات تهيئة CLI لـ CrewAI.
```shell Terminal
crewai config [COMMAND] [OPTIONS]
```
- `list`: عرض جميع معاملات التهيئة
- `set`: تعيين معامل تهيئة
- `reset`: إعادة تعيين جميع المعاملات إلى القيم الافتراضية
### 14. إدارة التتبع
إدارة تفضيلات جمع التتبع لعمليات الطاقم والتدفق.
```shell Terminal
crewai traces [COMMAND]
```
- `enable`: تفعيل جمع التتبع
- `disable`: تعطيل جمع التتبع
- `status`: عرض حالة جمع التتبع الحالية
#### كيف يعمل التتبع
يتم التحكم في جمع التتبع بفحص ثلاثة إعدادات بترتيب الأولوية:
description: كيفية تمكين الوكلاء من العمل معًا وتفويض المهام والتواصل بفعالية داخل فرق CrewAI.
icon: screen-users
mode: "wide"
---
## نظرة عامة
يُمكّن التعاون في CrewAI الوكلاء من العمل معًا كفريق عن طريق تفويض المهام وطرح الأسئلة للاستفادة من خبرات بعضهم البعض. عندما يكون `allow_delegation=True`، يحصل الوكلاء تلقائيًا على أدوات تعاون قوية.
## البدء السريع: تفعيل التعاون
```python
from crewai import Agent, Crew, Task
# تفعيل التعاون للوكلاء
researcher = Agent(
role="Research Specialist",
goal="Conduct thorough research on any topic",
backstory="Expert researcher with access to various sources",
allow_delegation=True, # الإعداد الرئيسي للتعاون
verbose=True
)
writer = Agent(
role="Content Writer",
goal="Create engaging content based on research",
backstory="Skilled writer who transforms research into compelling content",
allow_delegation=True, # يُمكّن طرح الأسئلة على الوكلاء الآخرين
verbose=True
)
# يمكن للوكلاء الآن التعاون تلقائيًا
crew = Crew(
agents=[researcher, writer],
tasks=[...],
verbose=True
)
```
## كيف يعمل تعاون الوكلاء
عندما يكون `allow_delegation=True`، يوفر CrewAI تلقائيًا للوكلاء أداتين قويتين:
### 1. **أداة تفويض العمل**
تسمح للوكلاء بتعيين مهام لزملاء الفريق ذوي الخبرة المحددة.
```python
# يحصل الوكيل تلقائيًا على هذه الأداة:
# Delegate work to coworker(task: str, context: str, coworker: str)
```
### 2. **أداة طرح الأسئلة**
تُمكّن الوكلاء من طرح أسئلة محددة لجمع المعلومات من الزملاء.
```python
# يحصل الوكيل تلقائيًا على هذه الأداة:
# Ask question to coworker(question: str, context: str, coworker: str)
```
## التعاون في الممارسة
إليك مثالًا كاملًا يوضح تعاون الوكلاء في مهمة إنشاء المحتوى:
```python
from crewai import Agent, Crew, Task, Process
# إنشاء وكلاء تعاونيين
researcher = Agent(
role="Research Specialist",
goal="Find accurate, up-to-date information on any topic",
backstory="""You're a meticulous researcher with expertise in finding
reliable sources and fact-checking information across various domains.""",
allow_delegation=True,
verbose=True
)
writer = Agent(
role="Content Writer",
goal="Create engaging, well-structured content",
backstory="""You're a skilled content writer who excels at transforming
research into compelling, readable content for different audiences.""",
allow_delegation=True,
verbose=True
)
editor = Agent(
role="Content Editor",
goal="Ensure content quality and consistency",
backstory="""You're an experienced editor with an eye for detail,
ensuring content meets high standards for clarity and accuracy.""",
allow_delegation=True,
verbose=True
)
# إنشاء مهمة تشجع التعاون
article_task = Task(
description="""Write a comprehensive 1000-word article about 'The Future of AI in Healthcare'.
The article should include:
- Current AI applications in healthcare
- Emerging trends and technologies
- Potential challenges and ethical considerations
- Expert predictions for the next 5 years
Collaborate with your teammates to ensure accuracy and quality.""",
expected_output="A well-researched, engaging 1000-word article with proper structure and citations",
agent=writer # الكاتب يقود، لكن يمكنه تفويض البحث إلى الباحث
)
# إنشاء طاقم تعاوني
crew = Crew(
agents=[researcher, writer, editor],
tasks=[article_task],
process=Process.sequential,
verbose=True
)
result = crew.kickoff()
```
## أنماط التعاون
### النمط 1: بحث ← كتابة ← تحرير
```python
research_task = Task(
description="Research the latest developments in quantum computing",
expected_output="Comprehensive research summary with key findings and sources",
agent=researcher
)
writing_task = Task(
description="Write an article based on the research findings",
expected_output="Engaging 800-word article about quantum computing",
agent=writer,
context=[research_task] # يحصل على مخرجات البحث كسياق
)
editing_task = Task(
description="Edit and polish the article for publication",
expected_output="Publication-ready article with improved clarity and flow",
agent=editor,
context=[writing_task] # يحصل على مسودة المقال كسياق
)
```
### النمط 2: مهمة واحدة تعاونية
```python
collaborative_task = Task(
description="""Create a marketing strategy for a new AI product.
Writer: Focus on messaging and content strategy
Researcher: Provide market analysis and competitor insights
Work together to create a comprehensive strategy.""",
expected_output="Complete marketing strategy with research backing",
agent=writer # الوكيل القائد، لكن يمكنه التفويض إلى الباحث
)
```
## التعاون الهرمي
للمشاريع المعقدة، استخدم عملية هرمية مع وكيل مدير:
```python
from crewai import Agent, Crew, Task, Process
# وكيل المدير ينسق الفريق
manager = Agent(
role="Project Manager",
goal="Coordinate team efforts and ensure project success",
backstory="Experienced project manager skilled at delegation and quality control",
allow_delegation=True,
verbose=True
)
# وكلاء متخصصون
researcher = Agent(
role="Researcher",
goal="Provide accurate research and analysis",
backstory="Expert researcher with deep analytical skills",
allow_delegation=False, # المتخصصون يركزون على خبرتهم
verbose=True
)
writer = Agent(
role="Writer",
goal="Create compelling content",
backstory="Skilled writer who creates engaging content",
allow_delegation=False,
verbose=True
)
# مهمة يقودها المدير
project_task = Task(
description="Create a comprehensive market analysis report with recommendations",
expected_output="Executive summary, detailed analysis, and strategic recommendations",
agent=manager # المدير سيفوّض إلى المتخصصين
)
# طاقم هرمي
crew = Crew(
agents=[manager, researcher, writer],
tasks=[project_task],
process=Process.hierarchical, # المدير ينسق كل شيء
manager_llm="gpt-4o", # تحديد LLM للمدير
verbose=True
)
```
## أفضل ممارسات التعاون
### 1. **تحديد الأدوار بوضوح**
```python
# جيد: أدوار محددة ومتكاملة
researcher = Agent(role="Market Research Analyst", ...)
description: فهم واستخدام الأطقم في إطار عمل CrewAI مع خصائص ووظائف شاملة.
icon: people-group
mode: "wide"
---
## نظرة عامة
يمثل الطاقم في CrewAI مجموعة تعاونية من الوكلاء يعملون معًا لتحقيق مجموعة من المهام. يحدد كل طاقم استراتيجية تنفيذ المهام وتعاون الوكلاء وسير العمل العام.
| **المهام** | `tasks` | قائمة المهام المعيّنة للطاقم. |
| **الوكلاء** | `agents` | قائمة الوكلاء الذين يشكلون جزءًا من الطاقم. |
| **العملية** _(اختياري)_ | `process` | تدفق العملية (مثل تسلسلي، هرمي) الذي يتبعه الطاقم. الافتراضي `sequential`. |
| **الوضع المفصل** _(اختياري)_ | `verbose` | مستوى التفصيل في التسجيل أثناء التنفيذ. الافتراضي `False`. |
| **LLM المدير** _(اختياري)_ | `manager_llm` | نموذج اللغة المستخدم بواسطة وكيل المدير في العملية الهرمية. **مطلوب عند استخدام العملية الهرمية.** |
| **LLM استدعاء الدوال** _(اختياري)_ | `function_calling_llm` | إذا مُرر، سيستخدم الطاقم هذا LLM لاستدعاء دوال الأدوات لجميع الوكلاء. يمكن لكل وكيل أن يكون له LLM خاص يتجاوز LLM الطاقم. |
| **LLM التخطيط** *(اختياري)* | `planning_llm` | نموذج اللغة المستخدم بواسطة AgentPlanner في عملية التخطيط. |
| **مصادر المعرفة** _(اختياري)_ | `knowledge_sources` | مصادر المعرفة المتاحة على مستوى الطاقم، يمكن لجميع الوكلاء الوصول إليها. |
| **البث** _(اختياري)_ | `stream` | تفعيل مخرجات البث لتلقي تحديثات في الوقت الفعلي. الافتراضي `False`. |
<Tip>
**الحد الأقصى لـ RPM للطاقم**: تعيّن خاصية `max_rpm` الحد الأقصى للطلبات في الدقيقة التي يمكن للطاقم تنفيذها لتجنب حدود المعدل وستتجاوز إعدادات `max_rpm` الفردية للوكلاء إذا عيّنتها.
</Tip>
## إنشاء الأطقم
هناك طريقتان لإنشاء الأطقم في CrewAI: باستخدام **تهيئة YAML (موصى بها)** أو تعريفها **مباشرة في الكود**.
### تهيئة YAML (موصى بها)
توفر تهيئة YAML طريقة أنظف وأكثر قابلية للصيانة لتعريف الأطقم وتتسق مع كيفية تعريف الوكلاء والمهام في مشاريع CrewAI.
```python code
from crewai import Agent, Crew, Task, Process
from crewai.project import CrewBase, agent, task, crew, before_kickoff, after_kickoff
from crewai.agents.agent_builder.base_agent import BaseAgent
from typing import List
@CrewBase
class YourCrewName:
"""Description of your crew"""
agents: List[BaseAgent]
tasks: List[Task]
agents_config = 'config/agents.yaml'
tasks_config = 'config/tasks.yaml'
@before_kickoff
def prepare_inputs(self, inputs):
inputs['additional_data'] = "Some extra information"
فئة `CrewBase`، مع هذه المزيّنات، تؤتمت جمع الوكلاء والمهام، مما يقلل الحاجة للإدارة اليدوية.
### تعريف مباشر في الكود (بديل)
بدلاً من ذلك، يمكنك تعريف الطاقم مباشرة في الكود بدون ملفات تهيئة YAML.
## مخرجات الطاقم
تُغلّف مخرجات الطاقم في فئة `CrewOutput`. توفر هذه الفئة طريقة منظمة للوصول إلى نتائج تنفيذ الطاقم، بما في ذلك تنسيقات متنوعة مثل السلاسل النصية الخام وJSON ونماذج Pydantic.
description: "الاستفادة من أحداث CrewAI لبناء تكاملات مخصصة ومراقبة"
icon: spinner
mode: "wide"
---
## نظرة عامة
يوفر CrewAI نظام أحداث قوي يتيح لك الاستماع والتفاعل مع الأحداث المختلفة التي تحدث أثناء تنفيذ طاقمك. تُمكّنك هذه الميزة من بناء تكاملات مخصصة وحلول مراقبة وأنظمة تسجيل أو أي وظائف أخرى تحتاج للتشغيل بناءً على أحداث CrewAI الداخلية.
## كيف يعمل
يستخدم CrewAI بنية ناقل أحداث لإرسال الأحداث طوال دورة حياة التنفيذ. يُبنى نظام الأحداث على المكونات التالية:
1. **CrewAIEventsBus**: ناقل أحداث فريد يدير تسجيل الأحداث وإرسالها
2. **BaseEvent**: الفئة الأساسية لجميع الأحداث في النظام
3. **BaseEventListener**: فئة أساسية مجردة لإنشاء مستمعي أحداث مخصصين
عندما تحدث إجراءات محددة في CrewAI (مثل بدء تنفيذ طاقم، أو إكمال وكيل لمهمة، أو استخدام أداة)، يرسل النظام أحداثًا مقابلة. يمكنك تسجيل معالجات لهذه الأحداث لتنفيذ كود مخصص عند حدوثها.
<Note type="info" title="تحسين المؤسسات: تتبع الأوامر">
يوفر CrewAI AMP ميزة تتبع أوامر مدمجة تستفيد من نظام الأحداث لتتبع وتخزين وتصور جميع الأوامر والاستكمالات والبيانات الوصفية المرتبطة.
description: تمرير الصور وملفات PDF والصوت والفيديو والنصوص إلى وكلائك للمعالجة متعددة الوسائط.
icon: file-image
---
## نظرة عامة
يدعم CrewAI مدخلات الملفات متعددة الوسائط الأصلية، مما يتيح لك تمرير الصور وملفات PDF والصوت والفيديو والنصوص مباشرة إلى وكلائك. يتم تنسيق الملفات تلقائيًا وفقًا لمتطلبات API لكل مزود LLM.
<Note type="info" title="اعتمادية اختيارية">
يتطلب دعم الملفات حزمة `crewai-files` الاختيارية. ثبّتها بـ:
```bash
uv add 'crewai[file-processing]'
```
</Note>
<Note type="warning" title="وصول مبكر">
واجهة معالجة الملفات حاليًا في مرحلة الوصول المبكر.
</Note>
## أنواع الملفات
يدعم CrewAI خمسة أنواع ملفات محددة بالإضافة إلى فئة `File` العامة التي تكتشف النوع تلقائيًا:
<Note type="info" title="Gemini لأقصى دعم للملفات">
تدعم نماذج Google Gemini جميع أنواع الملفات بما في ذلك الفيديو (حتى ساعة واحدة، 2 جيجابايت). استخدم Gemini عندما تحتاج لمعالجة محتوى الفيديو.
</Note>
<Note type="warning" title="أنواع الملفات غير المدعومة">
إذا مررت نوع ملف لا يدعمه المزود (مثل الفيديو إلى OpenAI)، ستتلقى خطأ `UnsupportedFileTypeError`. اختر مزودك بناءً على أنواع الملفات التي تحتاج لمعالجتها.
</Note>
## كيف تُرسل الملفات
يختار CrewAI تلقائيًا الطريقة المثلى لإرسال الملفات إلى كل مزود:
| الطريقة | الوصف | متى تُستخدم |
|:-------|:------------|:----------|
| **Inline Base64** | الملف مضمّن مباشرة في الطلب | ملفات صغيرة (< 5 ميجابايت عادة) |
| **File Upload API** | الملف يُرفع بشكل منفصل، يُشار إليه بمعرّف | ملفات كبيرة تتجاوز العتبة |
| **URL Reference** | عنوان URL مباشر يُمرر إلى النموذج | مصدر الملف هو عنوان URL بالفعل |
لا تحتاج لإدارة هذا بنفسك. يستخدم CrewAI تلقائيًا الطريقة الأكثر كفاءة بناءً على حجم الملف وقدرات المزود. المزودات بدون واجهات رفع الملفات تستخدم inline base64 لجميع الملفات.
</Note>
## أوضاع معالجة الملفات
تحكم في كيفية معالجة الملفات عندما تتجاوز حدود المزود:
description: الاستفادة من نظام الذاكرة الموحد في CrewAI لتعزيز قدرات الوكلاء.
icon: database
mode: "wide"
---
## نظرة عامة
يوفر CrewAI **نظام ذاكرة موحد** -- فئة `Memory` واحدة تستبدل أنواع الذاكرة المنفصلة (قصيرة المدى، طويلة المدى، ذاكرة الكيانات، والخارجية) بواجهة برمجة تطبيقات ذكية واحدة. تستخدم الذاكرة LLM لتحليل المحتوى عند الحفظ (استنتاج النطاق والفئات والأهمية) وتدعم الاسترجاع متعدد العمق مع تسجيل مركب يمزج بين التشابه الدلالي والحداثة والأهمية.
يمكنك استخدام الذاكرة بأربع طرق: **مستقلة** (سكربتات، دفاتر ملاحظات)، **مع فرق Crew**، **مع Agents**، أو **داخل التدفقات**.
## البدء السريع
```python
from crewai import Memory
memory = Memory()
# Store -- the LLM infers scope, categories, and importance
memory.remember("We decided to use PostgreSQL for the user database.")
from crewai import Crew, Agent, Task, Process, Memory
# Option 1: Default memory
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, writing_task],
process=Process.sequential,
memory=True,
verbose=True,
)
# Option 2: Custom memory with tuned scoring
memory = Memory(
recency_weight=0.4,
semantic_weight=0.4,
importance_weight=0.2,
recency_half_life_days=14,
)
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, writing_task],
memory=memory,
)
```
عند استخدام `memory=True`، ينشئ الفريق مثيل `Memory()` افتراضيًا ويمرر إعداد `embedder` الخاص بالفريق تلقائيًا. يشترك جميع الوكلاء في الفريق في ذاكرة الفريق ما لم يكن لدى الوكيل ذاكرته الخاصة.
بعد كل مهمة، يستخرج الفريق تلقائيًا حقائق منفصلة من مخرجات المهمة ويخزّنها. قبل كل مهمة، يسترجع الوكيل السياق ذا الصلة من الذاكرة ويحقنه في موجّه المهمة.
### مع Agents
يمكن للوكلاء استخدام ذاكرة الفريق المشتركة (افتراضيًا) أو تلقي عرض محدد النطاق للسياق الخاص.
```python
from crewai import Agent, Memory
memory = Memory()
# Researcher gets a private scope -- only sees /agent/researcher
researcher = Agent(
role="Researcher",
goal="Find and analyze information",
backstory="Expert researcher with attention to detail",
memory=memory.scope("/agent/researcher"),
)
# Writer uses crew shared memory (no agent-level memory set)
writer = Agent(
role="Writer",
goal="Produce clear, well-structured content",
backstory="Experienced technical writer",
# memory not set -- uses crew._memory when crew has memory enabled
)
```
يمنح هذا النمط الباحث نتائج خاصة بينما يقرأ الكاتب من ذاكرة الفريق المشتركة.
### مع التدفقات
كل تدفق يحتوي على ذاكرة مدمجة. استخدم `self.remember()` و `self.recall()` و `self.extract_memories()` داخل أي دالة تدفق.
```python
from crewai.flow.flow import Flow, listen, start
class ResearchFlow(Flow):
@start()
def gather_data(self):
findings = "PostgreSQL handles 10k concurrent connections. MySQL caps at 5k."
انظر [وثائق التدفقات](/concepts/flows) لمزيد من المعلومات حول الذاكرة في التدفقات.
## النطاقات الهرمية
### ما هي النطاقات
يتم تنظيم الذكريات في شجرة هرمية من النطاقات، مشابهة لنظام الملفات. كل نطاق هو مسار مثل `/` أو `/project/alpha` أو `/agent/researcher/findings`.
```
/
/company
/company/engineering
/company/product
/project
/project/alpha
/project/beta
/agent
/agent/researcher
/agent/writer
```
توفر النطاقات **ذاكرة تعتمد على السياق** -- عند الاسترجاع ضمن نطاق، تبحث فقط في ذلك الفرع من الشجرة، مما يحسّن كلًا من الدقة والأداء.
### كيف يعمل استنتاج النطاق
عند استدعاء `remember()` دون تحديد نطاق، يحلل LLM المحتوى وشجرة النطاقات الحالية، ثم يقترح أفضل موضع. إذا لم يكن هناك نطاق حالي مناسب، ينشئ واحدًا جديدًا. بمرور الوقت، تنمو شجرة النطاقات عضويًا من المحتوى نفسه -- لا تحتاج إلى تصميم مخطط مسبقًا.
```python
memory = Memory()
# LLM infers scope from content
memory.remember("We chose PostgreSQL for the user database.")
# -> might be placed under /project/decisions or /engineering/database
# You can also specify scope explicitly
memory.remember("Sprint velocity is 42 points", scope="/team/metrics")
- **ابدأ بشكل مسطح، ودع LLM ينظّم.** لا تبالغ في هندسة تسلسل النطاقات مسبقًا. ابدأ بـ `memory.remember(content)` ودع استنتاج النطاق في LLM ينشئ الهيكل مع تراكم المحتوى.
- **استخدم أنماط `/{entity_type}/{identifier}`.** تنشأ التسلسلات الطبيعية من أنماط مثل `/project/alpha` و `/agent/researcher` و `/company/engineering` و `/customer/acme-corp`.
- **حدد النطاق حسب الاهتمام، وليس حسب نوع البيانات.** استخدم `/project/alpha/decisions` بدلاً من `/decisions/project/alpha`. هذا يبقي المحتوى ذا الصلة معًا.
- **حافظ على العمق ضحلًا (2-3 مستويات).** النطاقات المتداخلة بعمق تصبح متفرقة جدًا. `/project/alpha/architecture` جيد؛ `/project/alpha/architecture/decisions/databases/postgresql` عميق جدًا.
- **استخدم النطاقات الصريحة عندما تعرف، ودع LLM يستنتج عندما لا تعرف.** إذا كنت تخزّن قرار مشروع معروف، مرّر `scope="/project/alpha/decisions"`. إذا كنت تخزّن مخرجات وكيل حرة الشكل، اترك النطاق ودع LLM يحدده.
# Shared product docs are accessible to all agents
memory.remember("Rate limit is 1000 req/min on enterprise plan", scope="/product/docs")
```
## شرائح الذاكرة
### ما هي الشرائح
`MemorySlice` هو عرض عبر نطاقات متعددة، ربما متباعدة. على عكس النطاق (الذي يقيّد على شجرة فرعية واحدة)، تتيح لك الشريحة الاسترجاع من عدة فروع في وقت واحد.
### متى تستخدم الشرائح مقابل النطاقات
- **النطاق**: استخدمه عندما يجب تقييد وكيل أو كتلة كود على شجرة فرعية واحدة. مثال: وكيل يرى فقط `/agent/researcher`.
- **الشريحة**: استخدمها عندما تحتاج إلى دمج السياق من عدة فروع. مثال: وكيل يقرأ من نطاقه الخاص بالإضافة إلى معرفة الشركة المشتركة.
### شرائح القراءة فقط
النمط الأكثر شيوعًا: منح وكيل إمكانية القراءة من فروع متعددة دون السماح له بالكتابة في المناطق المشتركة.
```python
memory = Memory()
# Agent can recall from its own scope AND company knowledge,
3. **استخراج الذكريات** -- `extract_memories(content)` يقسم النص الخام (مثل مخرجات المهمة) إلى عبارات ذاكرة منفصلة. يستخدم الوكلاء هذا قبل استدعاء `remember()` على كل عبارة حتى يتم تخزين حقائق ذرية بدلاً من كتلة كبيرة واحدة.
جميع التحليلات تتدهور بسلاسة عند فشل LLM -- انظر [سلوك الفشل](#سلوك-الفشل).
## توحيد الذاكرة
عند حفظ محتوى جديد، يتحقق خط أنابيب الترميز تلقائيًا من وجود سجلات مماثلة في التخزين. إذا كان التشابه أعلى من `consolidation_threshold` (الافتراضي 0.85)، يقرر LLM ما يجب فعله:
- **keep** -- السجل الحالي لا يزال دقيقًا وغير مكرر.
- **update** -- يجب تحديث السجل الحالي بمعلومات جديدة (يوفر LLM المحتوى المدمج).
- **delete** -- السجل الحالي قديم أو تم استبداله أو تناقضه.
- **insert_new** -- ما إذا كان يجب إدراج المحتوى الجديد أيضًا كسجل منفصل.
هذا يمنع تراكم النسخ المكررة. على سبيل المثال، إذا حفظت "CrewAI ensures reliable operation" ثلاث مرات، يتعرف التوحيد على النسخ المكررة ويحتفظ بسجل واحد فقط.
### إزالة التكرار داخل الدفعة
عند استخدام `remember_many()`، تتم مقارنة العناصر داخل نفس الدفعة مع بعضها البعض قبل الوصول إلى التخزين. إذا كان تشابه جيب التمام >= `batch_dedup_threshold` (الافتراضي 0.98)، يتم إسقاط العنصر الأحدث بصمت. هذا يلتقط النسخ المكررة الدقيقة أو شبه الدقيقة داخل دفعة واحدة دون أي استدعاءات LLM (رياضيات متجهات خالصة).
```python
# Only 2 records are stored (the third is a near-duplicate of the first)
memory.remember_many([
"CrewAI supports complex workflows.",
"Python is a great language.",
"CrewAI supports complex workflows.", # dropped by intra-batch dedup
])
```
## الحفظ غير الحاجب
`remember_many()` **غير حاجب** -- يقدم خط أنابيب الترميز إلى خيط خلفي ويعود فورًا. هذا يعني أن الوكيل يمكنه المتابعة إلى المهمة التالية بينما يتم حفظ الذكريات.
```python
# Returns immediately -- save happens in background
# recall() automatically waits for pending saves before searching
matches = memory.recall("facts") # sees all 3 records
```
### حاجز القراءة
كل استدعاء `recall()` يستدعي تلقائيًا `drain_writes()` قبل البحث، مما يضمن أن الاستعلام يرى دائمًا أحدث السجلات المستمرة. هذا شفاف -- لا تحتاج أبدًا إلى التفكير فيه.
### إيقاف الفريق
عند انتهاء الفريق، يستنزف `kickoff()` جميع عمليات حفظ الذاكرة المعلقة في كتلة `finally` الخاصة به، لذا لا تُفقد أي عمليات حفظ حتى لو اكتمل الفريق بينما عمليات الحفظ الخلفية قيد التنفيذ.
### الاستخدام المستقل
للسكربتات أو دفاتر الملاحظات حيث لا توجد دورة حياة فريق، استدعِ `drain_writes()` أو `close()` صراحة:
```python
memory = Memory()
memory.remember_many(["Fact A.", "Fact B."])
# Option 1: Wait for pending saves
memory.drain_writes()
# Option 2: Drain and shut down the background pool
memory.close()
```
## المصدر والخصوصية
يمكن لكل سجل ذاكرة أن يحمل علامة `source` لتتبع المصدر وعلامة `private` للتحكم في الوصول.
### تتبع المصدر
يحدد معامل `source` من أين جاءت الذاكرة:
```python
# Tag memories with their origin
memory.remember("User prefers dark mode", source="user:alice")
هذا مفيد بشكل خاص في النشرات متعددة المستخدمين أو المؤسسية حيث يجب عزل ذكريات المستخدمين المختلفين.
## RecallFlow (الاسترجاع العميق)
يدعم `recall()` عمقين:
- **`depth="shallow"`** -- بحث متجهي مباشر مع تسجيل مركب. سريع (~200 مللي ثانية)، بدون استدعاءات LLM.
- **`depth="deep"` (افتراضي)** -- يشغل RecallFlow متعدد الخطوات: تحليل الاستعلام، اختيار النطاق، بحث متجهي متوازٍ، توجيه قائم على الثقة، واستكشاف متكرر اختياري عندما تكون الثقة منخفضة.
**تخطي LLM الذكي**: الاستعلامات الأقصر من `query_analysis_threshold` (الافتراضي 200 حرف) تتخطى تحليل LLM للاستعلام بالكامل، حتى في الوضع العميق. الاستعلامات القصيرة مثل "ما قاعدة البيانات التي نستخدمها؟" هي بالفعل عبارات بحث جيدة -- تحليل LLM يضيف قيمة قليلة. هذا يوفر ~1-3 ثوانٍ لكل استرجاع للاستعلامات القصيرة النموذجية. فقط الاستعلامات الأطول (مثل أوصاف المهام الكاملة) تمر عبر تقطير LLM إلى استعلامات فرعية مستهدفة.
```python
# Shallow: pure vector search, no LLM
matches = memory.recall("What did we decide?", limit=10, depth="shallow")
# Deep (default): intelligent retrieval with LLM analysis for long queries
matches = memory.recall(
"Summarize all architecture decisions from this quarter",
limit=10,
depth="deep",
)
```
عتبات الثقة التي تتحكم في موجّه RecallFlow قابلة للإعداد:
```python
memory = Memory(
confidence_threshold_high=0.9, # Only synthesize when very confident
confidence_threshold_low=0.4, # Explore deeper more aggressively
exploration_budget=2, # Allow up to 2 exploration rounds
query_analysis_threshold=200, # Skip LLM for queries shorter than this
)
```
## إعداد المُضمِّن
تحتاج الذاكرة إلى نموذج تضمين لتحويل النص إلى متجهات للبحث الدلالي. يمكنك إعداده بثلاث طرق.
# Pass a pre-configured LLM instance with custom settings
llm = LLM(model="gpt-4o", temperature=0)
memory = Memory(llm=llm)
```
يتم تهيئة LLM **بشكل كسول** -- يتم إنشاؤه فقط عند الحاجة لأول مرة. هذا يعني أن `Memory()` لا يفشل أبدًا في وقت الإنشاء، حتى لو لم تكن مفاتيح API مُعيّنة. تظهر الأخطاء فقط عند استدعاء LLM فعليًا (مثلاً عند الحفظ بدون نطاق/فئات صريحة، أو أثناء الاسترجاع العميق).
للتشغيل المحلي/الخاص بالكامل، استخدم نموذجًا محليًا لكل من LLM والمُضمِّن:
- **الافتراضي**: LanceDB، مخزّن تحت `./.crewai/memory` (أو `$CREWAI_STORAGE_DIR/memory` إذا تم تعيين متغير البيئة، أو المسار الذي تمرره كـ `storage="path/to/dir"`).
memory.list_categories() # Category names and counts
memory.list_records(scope="/project/alpha", limit=20) # Records in a scope, newest first
```
## سلوك الفشل
إذا فشل LLM أثناء التحليل (خطأ شبكة، حد معدل، استجابة غير صالحة)، تتدهور الذاكرة بسلاسة:
- **تحليل الحفظ** -- يتم تسجيل تحذير ولا يزال يتم تخزين الذاكرة مع النطاق الافتراضي `/`، فئات فارغة، وأهمية `0.5`.
- **استخراج الذكريات** -- يتم تخزين المحتوى الكامل كذاكرة واحدة حتى لا يُفقد شيء.
- **تحليل الاستعلام** -- يتراجع الاسترجاع إلى اختيار نطاق بسيط وبحث متجهي حتى تستمر في الحصول على نتائج.
لا يتم رفع أي استثناء لفشل التحليل هذه؛ فقط فشل التخزين أو المُضمِّن سيرفع استثناءً.
## ملاحظة حول الخصوصية
يتم إرسال محتوى الذاكرة إلى LLM المُعدّ للتحليل (النطاق/الفئات/الأهمية عند الحفظ، تحليل الاستعلام والاسترجاع العميق الاختياري). للبيانات الحساسة، استخدم LLM محليًا (مثل Ollama) أو تأكد من أن مزودك يلبي متطلبات الامتثال الخاصة بك.
## أحداث الذاكرة
جميع عمليات الذاكرة تُصدر أحداثًا مع `source_type="unified_memory"`. يمكنك الاستماع للتوقيت والأخطاء والمحتوى.
| الحدث | الوصف | الخصائص الرئيسية |
| :---- | :---------- | :------------- |
| **MemoryQueryStartedEvent** | بداية الاستعلام | `query`, `limit` |
| **MemoryQueryCompletedEvent** | نجاح الاستعلام | `query`, `results`, `query_time_ms` |
| **MemoryQueryFailedEvent** | فشل الاستعلام | `query`, `error` |
| **MemorySaveStartedEvent** | بداية الحفظ | `value`, `metadata` |
| **MemorySaveCompletedEvent** | نجاح الحفظ | `value`, `save_time_ms` |
| **MemorySaveFailedEvent** | فشل الحفظ | `value`, `error` |
| **MemoryRetrievalStartedEvent** | بداية استرجاع الوكيل | `task_id` |
from crewai.events import BaseEventListener, MemoryQueryCompletedEvent
class MemoryMonitor(BaseEventListener):
def setup_listeners(self, crewai_event_bus):
@crewai_event_bus.on(MemoryQueryCompletedEvent)
def on_done(source, event):
if getattr(event, "source_type", None) == "unified_memory":
print(f"Query '{event.query}' completed in {event.query_time_ms:.0f}ms")
```
## استكشاف المشاكل
**الذاكرة لا تستمر؟**
- تأكد من أن مسار التخزين قابل للكتابة (الافتراضي `./.crewai/memory`). مرّر `storage="./your_path"` لاستخدام مجلد مختلف، أو عيّن متغير البيئة `CREWAI_STORAGE_DIR`.
- عند استخدام فريق، تأكد من تعيين `memory=True` أو `memory=Memory(...)`.
**الاسترجاع بطيء؟**
- استخدم `depth="shallow"` لسياق الوكيل الروتيني. احتفظ بـ `depth="deep"` للاستعلامات المعقدة.
- زد `query_analysis_threshold` لتخطي تحليل LLM لمزيد من الاستعلامات.
**أخطاء تحليل LLM في السجلات؟**
- لا تزال الذاكرة تحفظ/تسترجع بإعدادات افتراضية آمنة. تحقق من مفاتيح API وحدود المعدل وتوفر النموذج إذا كنت تريد تحليل LLM كاملاً.
**أخطاء حفظ خلفية في السجلات؟**
- عمليات حفظ الذاكرة تعمل في خيط خلفي. تُصدر الأخطاء كـ `MemorySaveFailedEvent` لكنها لا تعطل الوكيل. تحقق من السجلات للسبب الجذري (عادة مشاكل اتصال LLM أو المُضمِّن).
**تعارضات الكتابة المتزامنة؟**
- عمليات LanceDB مُتسلسلة بقفل مشترك وتُعاد تلقائيًا عند التعارض. هذا يتعامل مع مثيلات `Memory` المتعددة التي تشير إلى نفس قاعدة البيانات (مثل ذاكرة وكيل + ذاكرة فريق). لا حاجة لإجراء.
**تصفح الذاكرة من الطرفية:**
```bash
crewai memory # Opens the TUI browser
crewai memory --storage-path ./my_memory # Point to a specific directory
description: تعرّف على كيفية إضافة التخطيط إلى طاقم CrewAI وتحسين أدائه.
icon: ruler-combined
mode: "wide"
---
## نظرة عامة
تتيح لك ميزة التخطيط في CrewAI إضافة قدرة التخطيط إلى طاقمك. عند تفعيلها، قبل كل تكرار للطاقم،
يتم إرسال جميع معلومات الطاقم إلى AgentPlanner الذي يخطط للمهام خطوة بخطوة، ويُضاف هذا المخطط إلى وصف كل مهمة.
### استخدام ميزة التخطيط
البدء بميزة التخطيط سهل جدًا، الخطوة الوحيدة المطلوبة هي إضافة `planning=True` إلى طاقمك:
<CodeGroup>
```python Code
from crewai import Crew, Agent, Task, Process
# تجميع طاقمك مع قدرات التخطيط
my_crew = Crew(
agents=self.agents,
tasks=self.tasks,
process=Process.sequential,
planning=True,
)
```
</CodeGroup>
من هذه النقطة فصاعدًا، سيكون التخطيط مفعّلًا في طاقمك، وسيتم تخطيط المهام قبل كل تكرار.
<Warning>
عند تفعيل التخطيط، سيستخدم CrewAI `gpt-4o-mini` كنموذج LLM افتراضي للتخطيط، مما يتطلب مفتاح API صالحًا من OpenAI. نظرًا لأن وكلاءك قد يستخدمون نماذج LLM مختلفة، فقد يسبب ذلك ارتباكًا إذا لم يكن لديك مفتاح OpenAI API مهيأ أو إذا كنت تواجه سلوكًا غير متوقع متعلقًا باستدعاءات LLM API.
</Warning>
#### LLM التخطيط
يمكنك الآن تحديد نموذج LLM الذي سيُستخدم لتخطيط المهام.
عند تشغيل مثال الحالة الأساسية، سترى شيئًا مشابهًا للمخرجات أدناه، والتي تمثل مخرجات `AgentPlanner`
المسؤول عن إنشاء المنطق التدريجي لإضافته إلى مهام الوكلاء.
<CodeGroup>
```python Code
from crewai import Crew, Agent, Task, Process
# تجميع طاقمك مع قدرات التخطيط ونموذج LLM مخصص
my_crew = Crew(
agents=self.agents,
tasks=self.tasks,
process=Process.sequential,
planning=True,
planning_llm="gpt-4o"
)
# تشغيل الطاقم
my_crew.kickoff()
```
```markdown Result
[2024-07-15 16:49:11][INFO]: Planning the crew execution
**Step-by-Step Plan for Task Execution**
**Task Number 1: Conduct a thorough research about AI LLMs**
**Agent:** AI LLMs Senior Data Researcher
**Agent Goal:** Uncover cutting-edge developments in AI LLMs
**Task Expected Output:** A list with 10 bullet points of the most relevant information about AI LLMs
**Task Tools:** None specified
**Agent Tools:** None specified
**Step-by-Step Plan:**
1. **Define Research Scope:**
- Determine the specific areas of AI LLMs to focus on, such as advancements in architecture, use cases, ethical considerations, and performance metrics.
2. **Identify Reliable Sources:**
- List reputable sources for AI research, including academic journals, industry reports, conferences (e.g., NeurIPS, ACL), AI research labs (e.g., OpenAI, Google AI), and online databases (e.g., IEEE Xplore, arXiv).
3. **Collect Data:**
- Search for the latest papers, articles, and reports published in 2024 and early 2025.
- Use keywords like "Large Language Models 2025", "AI LLM advancements", "AI ethics 2025", etc.
4. **Analyze Findings:**
- Read and summarize the key points from each source.
- Highlight new techniques, models, and applications introduced in the past year.
5. **Organize Information:**
- Categorize the information into relevant topics (e.g., new architectures, ethical implications, real-world applications).
- Ensure each bullet point is concise but informative.
6. **Create the List:**
- Compile the 10 most relevant pieces of information into a bullet point list.
- Review the list to ensure clarity and relevance.
**Expected Output:**
A list with 10 bullet points of the most relevant information about AI LLMs.
---
**Task Number 2: Review the context you got and expand each topic into a full section for a report**
**Agent:** AI LLMs Reporting Analyst
**Agent Goal:** Create detailed reports based on AI LLMs data analysis and research findings
**Task Expected Output:** A fully fledged report with the main topics, each with a full section of information. Formatted as markdown without '```'
**Task Tools:** None specified
**Agent Tools:** None specified
**Step-by-Step Plan:**
1. **Review the Bullet Points:**
- Carefully read through the list of 10 bullet points provided by the AI LLMs Senior Data Researcher.
2. **Outline the Report:**
- Create an outline with each bullet point as a main section heading.
- Plan sub-sections under each main heading to cover different aspects of the topic.
3. **Research Further Details:**
- For each bullet point, conduct additional research if necessary to gather more detailed information.
- Look for case studies, examples, and statistical data to support each section.
4. **Write Detailed Sections:**
- Expand each bullet point into a comprehensive section.
- Ensure each section includes an introduction, detailed explanation, examples, and a conclusion.
- Use markdown formatting for headings, subheadings, lists, and emphasis.
5. **Review and Edit:**
- Proofread the report for clarity, coherence, and correctness.
- Make sure the report flows logically from one section to the next.
- Format the report according to markdown standards.
6. **Finalize the Report:**
- Ensure the report is complete with all sections expanded and detailed.
- Double-check formatting and make any necessary adjustments.
**Expected Output:**
A fully fledged report with the main topics, each with a full section of information. Formatted as markdown without '```'.
- **هرمي**: ينظم المهام في تسلسل إداري هرمي، حيث يتم تفويض المهام وتنفيذها بناءً على سلسلة أوامر منظمة. يجب تحديد نموذج لغة المدير (`manager_llm`) أو وكيل مدير مخصص (`manager_agent`) في الطاقم لتفعيل العملية الهرمية، مما يسهّل إنشاء وإدارة المهام من قبل المدير.
- **العملية التوافقية (مخطط لها)**: تهدف إلى اتخاذ القرارات بشكل تعاوني بين الوكلاء حول تنفيذ المهام، وتقدم هذه العملية نهجًا ديمقراطيًا لإدارة المهام داخل CrewAI. وهي مخطط لها للتطوير المستقبلي وغير مطبقة حاليًا في قاعدة الكود.
## دور العمليات في العمل الجماعي
تُمكّن العمليات الوكلاء الأفراد من العمل كوحدة متماسكة، مما يبسّط جهودهم لتحقيق أهداف مشتركة بكفاءة وتناسق.
## تعيين العمليات للطاقم
لتعيين عملية لطاقم، حدد نوع العملية عند إنشاء الطاقم لتعيين استراتيجية التنفيذ. للعملية الهرمية، تأكد من تحديد `manager_llm` أو `manager_agent` لوكيل المدير.
```python
from crewai import Crew, Process
# مثال: إنشاء طاقم بعملية تسلسلية
crew = Crew(
agents=my_agents,
tasks=my_tasks,
process=Process.sequential
)
# مثال: إنشاء طاقم بعملية هرمية
# تأكد من توفير manager_llm أو manager_agent
crew = Crew(
agents=my_agents,
tasks=my_tasks,
process=Process.hierarchical,
manager_llm="gpt-4o"
# أو
# manager_agent=my_manager_agent
)
```
**ملاحظة:** تأكد من تعريف `my_agents` و `my_tasks` قبل إنشاء كائن `Crew`، وللعملية الهرمية، يُعد `manager_llm` أو `manager_agent` مطلوبًا أيضًا.
## العملية التسلسلية
تعكس هذه الطريقة سير عمل الفريق الديناميكي، وتتقدم عبر المهام بطريقة مدروسة ومنهجية. يتبع تنفيذ المهام الترتيب المحدد مسبقًا في قائمة المهام، حيث يعمل ناتج مهمة واحدة كسياق للمهمة التالية.
لتخصيص سياق المهمة، استخدم معامل `context` في فئة `Task` لتحديد المخرجات التي يجب استخدامها كسياق للمهام اللاحقة.
## العملية الهرمية
تحاكي التسلسل الهرمي المؤسسي، حيث يسمح CrewAI بتحديد وكيل مدير مخصص أو إنشاء واحد تلقائيًا، مما يتطلب تحديد نموذج لغة المدير (`manager_llm`). يشرف هذا الوكيل على تنفيذ المهام، بما في ذلك التخطيط والتفويض والتحقق. لا يتم تعيين المهام مسبقًا؛ يخصص المدير المهام للوكلاء بناءً على قدراتهم، ويراجع المخرجات، ويقيّم اكتمال المهام.
## فئة Process: نظرة عامة مفصلة
تم تنفيذ فئة `Process` كتعداد (`Enum`)، مما يضمن أمان الأنواع ويقيّد قيم العملية على الأنواع المحددة (`sequential`، `hierarchical`). العملية التوافقية مخطط لإدراجها مستقبلاً، مما يؤكد التزامنا بالتطوير والابتكار المستمر.
## الخلاصة
التعاون المنظم الذي تسهّله العمليات داخل CrewAI ضروري لتمكين العمل الجماعي المنهجي بين الوكلاء.
تم تحديث هذه الوثائق لتعكس أحدث الميزات والتحسينات والتكامل المخطط للعملية التوافقية، مما يضمن وصول المستخدمين إلى أحدث المعلومات وأكثرها شمولاً.
description: أفضل الممارسات لبناء تطبيقات ذكاء اصطناعي جاهزة للإنتاج مع CrewAI
icon: server
mode: "wide"
---
# عقلية التدفق أولاً
عند بناء تطبيقات ذكاء اصطناعي إنتاجية مع CrewAI، **نوصي بالبدء بتدفق (Flow)**.
بينما يمكن تشغيل أطقم أو وكلاء فرديين، فإن تغليفهم في تدفق يوفر الهيكل اللازم لتطبيق متين وقابل للتوسع.
## لماذا التدفقات؟
1. **إدارة الحالة**: توفر التدفقات طريقة مدمجة لإدارة الحالة عبر مراحل مختلفة من تطبيقك. هذا ضروري لتمرير البيانات بين الأطقم والحفاظ على السياق ومعالجة مدخلات المستخدم.
2. **التحكم**: تتيح لك التدفقات تحديد مسارات تنفيذ دقيقة، بما في ذلك الحلقات والشرطيات ومنطق التفريع. هذا أساسي لمعالجة الحالات الاستثنائية وضمان سلوك تطبيقك بشكل متوقع.
3. **المراقبة**: توفر التدفقات هيكلًا واضحًا يسهّل تتبع التنفيذ وتصحيح الأخطاء ومراقبة الأداء. نوصي باستخدام [تتبع CrewAI](/ar/observability/tracing) للحصول على رؤى تفصيلية. ما عليك سوى تشغيل `crewai login` لتفعيل ميزات المراقبة المجانية.
## البنية
يبدو تطبيق CrewAI الإنتاجي النموذجي هكذا:
```mermaid
graph TD
Start((Start)) --> Flow[Flow Orchestrator]
Flow --> State{State Management}
State --> Step1[Step 1: Data Gathering]
Step1 --> Crew1[Research Crew]
Crew1 --> State
State --> Step2{Condition Check}
Step2 -- "Valid" --> Step3[Step 3: Execution]
Step3 --> Crew2[Action Crew]
Step2 -- "Invalid" --> End((End))
Crew2 --> End
```
### 1. فئة التدفق
فئة `Flow` هي نقطة الدخول. تحدد مخطط الحالة والطرق التي تنفذ منطقك.
```python
from crewai.flow.flow import Flow, listen, start
from pydantic import BaseModel
class AppState(BaseModel):
user_input: str = ""
research_results: str = ""
final_report: str = ""
class ProductionFlow(Flow[AppState]):
@start()
def gather_input(self):
# ... منطق الحصول على المدخلات ...
pass
@listen(gather_input)
def run_research_crew(self):
# ... تشغيل طاقم ...
pass
```
### 2. إدارة الحالة
استخدم نماذج Pydantic لتعريف حالتك. يضمن هذا أمان الأنواع ويوضح البيانات المتاحة في كل مرحلة.
- **اجعلها بسيطة**: خزّن فقط ما تحتاجه للاستمرار بين المراحل.
- **استخدم بيانات منظمة**: تجنب القواميس غير المنظمة قدر الإمكان.
### 3. الأطقم كوحدات عمل
فوّض المهام المعقدة إلى الأطقم. يجب أن يكون الطاقم مركّزًا على هدف محدد (مثل "البحث في موضوع"، "كتابة مقال مدونة").
- **لا تبالغ في هندسة الأطقم**: اجعلها مركّزة.
- **مرر الحالة بشكل صريح**: مرر البيانات الضرورية من حالة التدفق إلى مدخلات الطاقم.
```python
@listen(gather_input)
def run_research_crew(self):
crew = ResearchCrew()
result = crew.kickoff(inputs={"topic": self.state.user_input})
self.state.research_results = result.raw
```
## عناصر التحكم الأولية
استفد من عناصر التحكم الأولية في CrewAI لإضافة المتانة والتحكم إلى أطقمك.
### 1. حواجز المهام
استخدم [حواجز المهام](/ar/concepts/tasks#task-guardrails) للتحقق من مخرجات المهام قبل قبولها. يضمن هذا أن وكلاءك ينتجون نتائج عالية الجودة.
return (False, "Content is too short. Please expand.")
return (True, result.raw)
task = Task(
...,
guardrail=validate_content
)
```
### 2. المخرجات المنظمة
استخدم دائمًا المخرجات المنظمة (`output_pydantic` أو `output_json`) عند تمرير البيانات بين المهام أو إلى تطبيقك. يمنع هذا أخطاء التحليل ويضمن أمان الأنواع.
```python
class ResearchResult(BaseModel):
summary: str
sources: List[str]
task = Task(
...,
output_pydantic=ResearchResult
)
```
### 3. خطافات LLM
استخدم [خطافات LLM](/ar/learn/llm-hooks) لفحص أو تعديل الرسائل قبل إرسالها إلى LLM، أو لتنقية الاستجابات.
```python
@before_llm_call
def log_request(context):
print(f"Agent {context.agent.role} is calling the LLM...")
```
## أنماط النشر
عند نشر تدفقك، ضع في اعتبارك ما يلي:
### CrewAI Enterprise
أسهل طريقة لنشر تدفقك هي استخدام CrewAI Enterprise. تتعامل مع البنية التحتية والمصادقة والمراقبة نيابة عنك.
للمهام طويلة التشغيل، استخدم `kickoff_async` لتجنب حظر واجهتك البرمجية.
### الاستمرارية
استخدم مزيّن `@persist` لحفظ حالة تدفقك في قاعدة بيانات. يتيح لك هذا استئناف التنفيذ إذا تعطلت العملية أو إذا كنت بحاجة لانتظار مدخلات بشرية.
```python
@persist
class ProductionFlow(Flow[AppState]):
# ...
```
افتراضيًا، يستأنف `@persist` تدفقًا عند توفير `kickoff(inputs={"id": <uuid>})`، مما يمدّ نفس تاريخ `flow_uuid`. لـ **تفرع** تدفق مستمر إلى نسبٍ جديد — ترطيب الحالة من تشغيل سابق ولكن الكتابة تحت `state.id` جديد — مرّر `restore_from_state_id`:
يحصل التشغيل الجديد على `state.id` جديد (مولّد تلقائيًا، أو `inputs["id"]` إذا تم تثبيته) لذا لا تمتد كتابات `@persist` الخاصة به إلى تاريخ المصدر. الجمع مع `from_checkpoint` يطلق `ValueError`؛ اختر مصدر ترطيب واحدًا.
description: "تعرّف على كيفية تفعيل واستخدام استدلال الوكيل لتحسين تنفيذ المهام."
icon: brain
mode: "wide"
---
## نظرة عامة
استدلال الوكيل هو ميزة تتيح للوكلاء التأمل في المهمة وإنشاء خطة قبل التنفيذ. يساعد هذا الوكلاء على التعامل مع المهام بشكل أكثر منهجية ويضمن استعدادهم لأداء العمل المطلوب.
## الاستخدام
لتفعيل الاستدلال لوكيل، ما عليك سوى تعيين `reasoning=True` عند إنشاء الوكيل:
```python
from crewai import Agent
agent = Agent(
role="Data Analyst",
goal="Analyze complex datasets and provide insights",
backstory="You are an experienced data analyst with expertise in finding patterns in complex data.",
reasoning=True, # تفعيل الاستدلال
max_reasoning_attempts=3 # اختياري: تعيين حد أقصى لمحاولات الاستدلال
)
```
## كيف يعمل
عند تفعيل الاستدلال، قبل تنفيذ المهمة، سيقوم الوكيل بما يلي:
1. التأمل في المهمة وإنشاء خطة مفصلة
2. تقييم ما إذا كان مستعدًا لتنفيذ المهمة
3. تحسين الخطة حسب الحاجة حتى يصبح مستعدًا أو يصل إلى max_reasoning_attempts
4. حقن خطة الاستدلال في وصف المهمة قبل التنفيذ
تساعد هذه العملية الوكيل على تقسيم المهام المعقدة إلى خطوات يمكن إدارتها وتحديد التحديات المحتملة قبل البدء.
صُممت عملية الاستدلال لتكون متينة، مع معالجة أخطاء مدمجة. إذا حدث خطأ أثناء الاستدلال، سيتابع الوكيل تنفيذ المهمة بدون خطة الاستدلال. يضمن هذا إمكانية تنفيذ المهام حتى في حالة فشل عملية الاستدلال.
إليك كيفية التعامل مع الأخطاء المحتملة في الكود الخاص بك:
```python
from crewai import Agent, Task
import logging
# إعداد التسجيل لالتقاط أي أخطاء في الاستدلال
logging.basicConfig(level=logging.INFO)
# إنشاء وكيل مع تفعيل الاستدلال
agent = Agent(
role="Data Analyst",
goal="Analyze data and provide insights",
reasoning=True,
max_reasoning_attempts=3
)
# إنشاء مهمة
task = Task(
description="Analyze the provided sales data and identify key trends.",
expected_output="A report highlighting the top 3 sales trends.",
agent=agent
)
# تنفيذ المهمة
# إذا حدث خطأ أثناء الاستدلال، سيتم تسجيله وسيستمر التنفيذ
result = agent.execute_task(task)
```
## مثال على مخرجات الاستدلال
إليك مثالًا على شكل خطة الاستدلال لمهمة تحليل البيانات:
```
Task: Analyze the provided sales data and identify key trends.
Reasoning Plan:
I'll analyze the sales data to identify the top 3 trends.
1. Understanding of the task:
I need to analyze sales data to identify key trends that would be valuable for business decision-making.
2. Key steps I'll take:
- First, I'll examine the data structure to understand what fields are available
- Then I'll perform exploratory data analysis to identify patterns
- Next, I'll analyze sales by time periods to identify temporal trends
- I'll also analyze sales by product categories and customer segments
- Finally, I'll identify the top 3 most significant trends
3. Approach to challenges:
- If the data has missing values, I'll decide whether to fill or filter them
- If the data has outliers, I'll investigate whether they're valid data points or errors
- If trends aren't immediately obvious, I'll apply statistical methods to uncover patterns
4. Use of available tools:
- I'll use data analysis tools to explore and visualize the data
- I'll use statistical tools to identify significant patterns
- I'll use knowledge retrieval to access relevant information about sales analysis
5. Expected outcome:
A concise report highlighting the top 3 sales trends with supporting evidence from the data.
READY: I am ready to execute the task.
```
تساعد خطة الاستدلال هذه الوكيل على تنظيم نهجه تجاه المهمة، والنظر في التحديات المحتملة، وضمان تقديم المخرجات المتوقعة.
description: حزم المهارات المبنية على نظام الملفات التي تحقن خبرة المجال والتعليمات في إرشادات الوكلاء.
icon: bolt
mode: "wide"
---
## نظرة عامة
المهارات هي مجلدات مستقلة توفر للوكلاء **تعليمات وإرشادات ومواد مرجعية خاصة بالمجال**. تُعرّف كل مهارة بملف `SKILL.md` يحتوي على بيانات وصفية YAML ومحتوى Markdown.
عند التفعيل، يتم حقن تعليمات المهارة مباشرة في إرشادات مهمة الوكيل — مما يمنح الوكيل خبرة دون الحاجة لأي تغييرات في الكود.
<Note type="info" title="المهارات مقابل الأدوات — التمييز الأساسي">
**المهارات ليست أدوات.** هذه هي نقطة الارتباك الأكثر شيوعًا.
- **المهارات** تحقن *تعليمات وسياق* في إرشادات الوكيل. تخبر الوكيل *كيف يفكر* في مشكلة ما.
يجب أن يتطابق اسم المجلد مع حقل `name` في `SKILL.md`. مجلدات `scripts/` و `references/` و `assets/` متاحة في مسار المهارة `path` للوكلاء الذين يحتاجون للإشارة إلى الملفات مباشرة.
---
## المهارات المحمّلة مسبقًا
للمزيد من التحكم، يمكنك اكتشاف المهارات وتفعيلها برمجيًا:
```python
from pathlib import Path
from crewai.skills import discover_skills, activate_skill
# اكتشاف جميع المهارات في مجلد
skills = discover_skills(Path("./skills"))
# تفعيلها (تحميل محتوى SKILL.md الكامل)
activated = [activate_skill(s) for s in skills]
# تمرير إلى وكيل
agent = Agent(
role="Researcher",
goal="Find relevant information",
backstory="An expert researcher.",
skills=activated,
)
```
---
## كيف يتم تحميل المهارات
تستخدم المهارات **الكشف التدريجي** — تحمّل فقط ما هو مطلوب في كل مرحلة:
| التفعيل | نص محتوى SKILL.md الكامل | `activate_skill()` |
أثناء التنفيذ العادي للوكيل (تمرير مسارات المجلدات عبر `skills=["./skills"]`)، يتم اكتشاف المهارات وتفعيلها تلقائيًا. التحميل التدريجي مهم فقط عند استخدام الواجهة البرمجية.
---
## المهارات مقابل المعرفة
كلا المهارات والمعرفة تُعدّل إرشادات الوكيل، لكنهما يخدمان أغراضًا مختلفة:
يعتمد على حالة الاستخدام. المهارات والأدوات **مستقلتان** — يمكنك استخدام أيّ منهما أو كليهما أو لا شيء.
- **مهارات فقط**: عندما يحتاج الوكيل خبرة لكن لا يحتاج إجراءات خارجية (مثال: الكتابة بإرشادات أسلوبية)
- **أدوات فقط**: عندما يحتاج الوكيل إجراءات لكن لا يحتاج منهجية خاصة (مثال: بحث بسيط على الويب)
- **كليهما**: عندما يحتاج الوكيل خبرة وإجراءات (مثال: تدقيق أمني بقوائم تحقق محددة وقدرة على فحص الكود)
</Accordion>
<Accordion title="هل توفر المهارات أدوات تلقائيًا؟">
**لا.** حقل `allowed-tools` في SKILL.md هو بيانات وصفية تجريبية فقط — لا يُنشئ أو يحقن أي أدوات. يجب عليك دائمًا تعيين الأدوات بشكل منفصل عبر `tools=[]` أو `mcps=[]` أو `apps=[]`.
</Accordion>
<Accordion title="ماذا يحدث إذا عيّنت نفس المهارة على كل من الوكيل والطاقم؟">
المهارة على مستوى الوكيل لها الأولوية. يتم إزالة التكرار حسب الاسم — مهارات الوكيل تُعالج أولاً، لذا إذا ظهر نفس اسم المهارة في كلا المستويين، تُستخدم نسخة الوكيل.
</Accordion>
<Accordion title="ما الحجم الأقصى لمحتوى SKILL.md؟">
هناك تحذير ناعم عند 50,000 حرف، لكن بدون حد صارم. حافظ على تركيز المهارات وإيجازها للحصول على أفضل النتائج — الحقن الكبيرة في الإرشادات قد تُشتت انتباه الوكيل.
description: تعرّف على كيفية اختبار طاقم CrewAI وتقييم أدائه.
icon: vial
mode: "wide"
---
## نظرة عامة
يُعد الاختبار جزءًا حيويًا من عملية التطوير، ومن الضروري التأكد من أن طاقمك يعمل كما هو متوقع. مع CrewAI، يمكنك اختبار طاقمك وتقييم أدائه بسهولة باستخدام إمكانيات الاختبار المدمجة.
### استخدام ميزة الاختبار
أضفنا أمر CLI `crewai test` لتسهيل اختبار طاقمك. سيقوم هذا الأمر بتشغيل طاقمك لعدد محدد من التكرارات وتوفير مقاييس أداء مفصلة. المعاملات هي `n_iterations` و `model`، وهي اختيارية وتكون قيمها الافتراضية 2 و `gpt-4o-mini` على التوالي. حاليًا، المزود الوحيد المتاح هو OpenAI.
```bash
crewai test
```
إذا أردت تشغيل المزيد من التكرارات أو استخدام نموذج مختلف، يمكنك تحديد المعاملات هكذا:
```bash
crewai test --n_iterations 5 --model gpt-4o
```
أو باستخدام الصيغة المختصرة:
```bash
crewai test -n 5 -m gpt-4o
```
عند تشغيل أمر `crewai test`، سيتم تنفيذ الطاقم للعدد المحدد من التكرارات، وستُعرض مقاييس الأداء في نهاية التشغيل.
سيظهر جدول الدرجات في النهاية لعرض أداء الطاقم من حيث المقاييس التالية:
<center>**درجات المهام (1-10 الأعلى أفضل)**</center>
| المهام/الطاقم/الوكلاء | التشغيل 1 | التشغيل 2 | المجموع المتوسط | الوكلاء | معلومات إضافية |
description: فهم واستخدام الأدوات ضمن إطار عمل CrewAI لتعاون الوكلاء وتنفيذ المهام.
icon: screwdriver-wrench
mode: "wide"
---
## نظرة عامة
تُمكّن أدوات CrewAI الوكلاء بقدرات تتراوح من البحث على الويب وتحليل البيانات إلى التعاون وتفويض المهام بين الزملاء.
توضح هذه الوثائق كيفية إنشاء هذه الأدوات ودمجها والاستفادة منها ضمن إطار عمل CrewAI، بما في ذلك التركيز على أدوات التعاون.
<Note type="info" title="الأدوات هي أحد أنواع قدرات الوكيل الخمسة">
الأدوات تمنح الوكلاء **دوال قابلة للاستدعاء** لاتخاذ إجراءات. تعمل جنبًا إلى جنب مع [MCP](/ar/mcp/overview) (خوادم أدوات عن بُعد) و[التطبيقات](/ar/concepts/agent-capabilities) (تكاملات المنصة) و[المهارات](/ar/concepts/skills) (خبرة المجال) و[المعرفة](/ar/concepts/knowledge) (حقائق مُسترجعة). راجع نظرة عامة على [قدرات الوكيل](/ar/concepts/agent-capabilities) لفهم متى تستخدم كل نوع.
</Note>
## ما هي الأداة؟
الأداة في CrewAI هي مهارة أو وظيفة يمكن للوكلاء استخدامها لأداء إجراءات مختلفة.
يشمل ذلك أدوات من [مجموعة أدوات CrewAI](https://github.com/joaomdmoura/crewai-tools) و[أدوات LangChain](https://python.langchain.com/docs/integrations/tools)،
مما يُمكّن كل شيء من عمليات البحث البسيطة إلى التفاعلات المعقدة والعمل الجماعي الفعال بين الوكلاء.
goal='Provide up-to-date market analysis of the AI industry',
backstory='An expert analyst with a keen eye for market trends.',
tools=[search_tool, web_rag_tool],
verbose=True
)
writer = Agent(
role='Content Writer',
goal='Craft engaging blog posts about the AI industry',
backstory='A skilled writer with a passion for technology.',
tools=[docs_tool, file_tool],
verbose=True
)
# تعريف المهام
research = Task(
description='Research the latest trends in the AI industry and provide a summary.',
expected_output='A summary of the top 3 trending developments in the AI industry with a unique perspective on their significance.',
agent=researcher
)
write = Task(
description='Write an engaging blog post about the AI industry, based on the research analyst\'s summary. Draw inspiration from the latest blog posts in the directory.',
expected_output='A 4-paragraph blog post formatted in markdown with engaging, informative, and accessible content, avoiding complex jargon.',
agent=writer,
output_file='blog-posts/new_post.md'
)
# تجميع طاقم مع تفعيل التخطيط
crew = Crew(
agents=[researcher, writer],
tasks=[research, write],
verbose=True,
planning=True,
)
# تنفيذ المهام
crew.kickoff()
```
## أدوات CrewAI المتاحة
- **معالجة الأخطاء**: جميع الأدوات مبنية بقدرات معالجة الأخطاء، مما يسمح للوكلاء بإدارة الاستثناءات بسلاسة ومتابعة مهامهم.
- **آلية التخزين المؤقت**: جميع الأدوات تدعم التخزين المؤقت، مما يُمكّن الوكلاء من إعادة استخدام النتائج المحصلة سابقًا بكفاءة، مما يقلل الحمل على الموارد الخارجية ويسرّع وقت التنفيذ. يمكنك أيضًا تحديد تحكم أدق في آلية التخزين المؤقت باستخدام خاصية `cache_function` على الأداة.
| **YoutubeVideoSearchTool** | أداة RAG للبحث في مقاطع فيديو YouTube، مثالية لاستخراج بيانات الفيديو. |
## إنشاء أدواتك الخاصة
<Tip>
يمكن للمطورين إنشاء `أدوات مخصصة` مصممة خصيصًا لاحتياجات وكلائهم أو
استخدام الخيارات الجاهزة.
</Tip>
هناك طريقتان رئيسيتان لإنشاء أداة CrewAI:
### الوراثة من `BaseTool`
```python Code
from crewai.tools import BaseTool
from pydantic import BaseModel, Field
class MyToolInput(BaseModel):
"""Input schema for MyCustomTool."""
argument: str = Field(..., description="Description of the argument.")
class MyCustomTool(BaseTool):
name: str = "Name of my tool"
description: str = "What this tool does. It's vital for effective utilization."
args_schema: Type[BaseModel] = MyToolInput
def _run(self, argument: str) -> str:
# منطق أداتك هنا
return "Tool's result"
```
## دعم الأدوات غير المتزامنة
يدعم CrewAI الأدوات غير المتزامنة، مما يتيح لك تنفيذ أدوات تجري عمليات غير حاجبة مثل طلبات الشبكة وعمليات الإدخال/الإخراج على الملفات أو عمليات async أخرى بدون حجب مسار التنفيذ الرئيسي.
### إنشاء أدوات غير متزامنة
يمكنك إنشاء أدوات غير متزامنة بطريقتين:
#### 1. استخدام مزيّن `tool` مع دوال Async
```python Code
from crewai.tools import tool
@tool("fetch_data_async")
async def fetch_data_async(query: str) -> str:
"""Asynchronously fetch data based on the query."""
# محاكاة عملية غير متزامنة
await asyncio.sleep(1)
return f"Data retrieved for {query}"
```
#### 2. تنفيذ طرق Async في فئات الأدوات المخصصة
```python Code
from crewai.tools import BaseTool
class AsyncCustomTool(BaseTool):
name: str = "async_custom_tool"
description: str = "An asynchronous custom tool"
async def _run(self, query: str = "") -> str:
"""Asynchronously run the tool"""
# تنفيذك غير المتزامن هنا
await asyncio.sleep(1)
return f"Processed {query} asynchronously"
```
### استخدام الأدوات غير المتزامنة
تعمل الأدوات غير المتزامنة بسلاسة في كل من سير عمل الطاقم القياسي وسير عمل التدفق:
"""Useful for when you need to multiply two numbers together."""
return first_number * second_number
def cache_func(args, result):
# في هذه الحالة، نخزّن النتيجة مؤقتًا فقط إذا كانت من مضاعفات 2
cache = result % 2 == 0
return cache
multiplication_tool.cache_function = cache_func
writer1 = Agent(
role="Writer",
goal="You write lessons of math for kids.",
backstory="You're an expert in writing and you love to teach kids but you know nothing of math.",
tools=[multiplication_tool],
allow_delegation=False,
)
#...
```
## الخلاصة
الأدوات محورية في توسيع قدرات وكلاء CrewAI، مما يمكّنهم من تنفيذ مجموعة واسعة من المهام والتعاون بفعالية.
عند بناء حلول مع CrewAI، استفد من كل من الأدوات المخصصة والموجودة لتمكين وكلائك وتعزيز نظام الذكاء الاصطناعي البيئي. فكّر في استخدام معالجة الأخطاء وآليات التخزين المؤقت ومرونة معاملات الأدوات لتحسين أداء وقدرات وكلائك.
E --> F["Append to training_data.pkl<br/>by agent_id and iteration"]
end
B --> C
F --> G{"More iterations?"}
G -- "Yes" --> C
G -- "No" --> H["Evaluate per agent<br/>aggregate iterations"]
H --> I["Consolidate<br/>suggestions[] + quality + final_summary"]
I --> J["Save by agent role to trained file<br/>(default: trained_agents_data.pkl)"]
J --> K["Normal (non-training) runs"]
K --> L["Auto-load suggestions<br/>from trained_agents_data.pkl"]
L --> M["Append to prompt<br/>for consistent improvements"]
```
### أثناء تشغيلات التدريب
- في كل تكرار، يسجل النظام لكل وكيل:
- `initial_output`: الإجابة الأولى للوكيل
- `human_feedback`: ملاحظاتك المضمّنة عند الطلب
- `improved_output`: إجابة المتابعة للوكيل بعد الملاحظات
- تُخزن هذه البيانات في ملف عمل باسم `training_data.pkl` مفهرس بمعرّف الوكيل الداخلي والتكرار.
- أثناء نشاط التدريب، يُلحق الوكيل تلقائيًا ملاحظاتك البشرية السابقة بأمره لتطبيق تلك التعليمات في المحاولات اللاحقة ضمن جلسة التدريب.
التدريب تفاعلي: تُعيّن المهام `human_input = true`، لذا سيتوقف التشغيل في بيئة غير تفاعلية بانتظار مدخلات المستخدم.
### بعد اكتمال التدريب
- عند انتهاء `train(...)`، يقيّم CrewAI بيانات التدريب المجمعة لكل وكيل وينتج نتيجة موحدة تحتوي على:
- `suggestions`: تعليمات واضحة وقابلة للتنفيذ مستخلصة من ملاحظاتك والفرق بين المخرجات الأولية/المحسنة
- `quality`: درجة من 0-10 تعكس التحسن
- `final_summary`: مجموعة خطوات عمل تفصيلية للمهام المستقبلية
- تُحفظ هذه النتائج الموحدة في اسم الملف الذي تمرره إلى `train(...)` (الافتراضي عبر CLI هو `trained_agents_data.pkl`). تُفهرس الإدخالات بدور الوكيل `role` لتطبيقها عبر الجلسات.
- أثناء التنفيذ العادي (غير التدريب)، يحمّل كل وكيل تلقائيًا `suggestions` الموحدة ويلحقها بأمر المهمة كتعليمات إلزامية. يمنحك هذا تحسينات متسقة بدون تغيير تعريفات الوكلاء.
بينما يتضمن CrewAI تحسينات للنماذج الصغيرة، توقع نتائج تقييم أقل موثوقية ودقة قد تتطلب تدخلاً بشريًا أكبر أثناء التدريب.
</Warning>
</Tab>
</Tabs>
### نقاط مهمة يجب ملاحظتها
- **متطلب العدد الصحيح الموجب:** تأكد من أن عدد التكرارات (`n_iterations`) هو عدد صحيح موجب. سيرمي الكود `ValueError` إذا لم يتحقق هذا الشرط.
- **متطلب اسم الملف:** تأكد من أن اسم الملف ينتهي بـ `.pkl`. سيرمي الكود `ValueError` إذا لم يتحقق هذا الشرط.
- **معالجة الأخطاء:** يتعامل الكود مع أخطاء العمليات الفرعية والاستثناءات غير المتوقعة، ويوفر رسائل خطأ للمستخدم.
- يُطبق التوجيه المدرّب في وقت الأمر؛ لا يعدّل تهيئة وكيل Python/YAML.
- يحمّل الوكلاء تلقائيًا الاقتراحات المدربة من ملف باسم `trained_agents_data.pkl` الموجود في مجلد العمل الحالي. إذا درّبت إلى اسم ملف مختلف، أعد تسميته إلى `trained_agents_data.pkl` قبل التشغيل، أو اضبط المحمّل في الكود.
- يمكنك تغيير اسم ملف المخرجات عند استدعاء `crewai train` بـ `-f/--filename`. المسارات المطلقة مدعومة إذا أردت الحفظ خارج CWD.
من المهم ملاحظة أن عملية التدريب قد تستغرق بعض الوقت، اعتمادًا على تعقيد وكلائك وستتطلب أيضًا ملاحظاتك في كل تكرار.
بمجرد اكتمال التدريب، سيكون وكلاؤك مجهزين بقدرات ومعرفة محسّنة، وجاهزين لمعالجة المهام المعقدة وتقديم رؤى أكثر اتساقًا وقيمة.
تذكر تحديث وإعادة تدريب وكلائك بانتظام لضمان بقائهم على اطلاع بأحدث المعلومات والتطورات في المجال.
description: 'تعرّف على كيفية استخدام مستودعات الوكلاء لمشاركة وإعادة استخدام وكلائك عبر الفرق والمشاريع'
icon: 'people-group'
mode: "wide"
---
تتيح مستودعات الوكلاء لمستخدمي المؤسسات تخزين ومشاركة وإعادة استخدام تعريفات الوكلاء عبر الفرق والمشاريع. تُمكّن هذه الميزة المؤسسات من الاحتفاظ بمكتبة مركزية من الوكلاء الموحدين، مما يعزز الاتساق ويقلل من ازدواجية الجهود.
1. **اصطلاح التسمية**: استخدم أسماء واضحة ووصفية لوكلاء المستودع
2. **التوثيق**: أدرج أوصافًا شاملة لكل وكيل
3. **إدارة الأدوات**: تأكد من توفر الأدوات المشار إليها بواسطة وكلاء المستودع في بيئتك
4. **التحكم في الوصول**: أدر الصلاحيات لضمان أن أعضاء الفريق المصرّح لهم فقط يمكنهم تعديل وكلاء المستودع
## إدارة المؤسسة
للتبديل بين المؤسسات أو عرض مؤسستك الحالية، استخدم واجهة سطر أوامر CrewAI:
```bash
# عرض المؤسسة الحالية
crewai org current
# التبديل إلى مؤسسة مختلفة
crewai org switch <org_id>
# عرض جميع المؤسسات المتاحة
crewai org list
```
<Note>
عند تحميل الوكلاء من المستودعات، يجب أن تكون مصادقًا ومتحولًا إلى المؤسسة الصحيحة. إذا تلقيت أخطاء، تحقق من حالة المصادقة وإعدادات المؤسسة باستخدام أوامر CLI أعلاه.
description: "إدارة ونشر ومراقبة أطقمك المباشرة (الأتمتة) في مكان واحد."
icon: "rocket"
mode: "wide"
---
## نظرة عامة
الأتمتة هي مركز العمليات المباشرة لأطقمك المنشورة. استخدمها للنشر من GitHub أو ملف ZIP، وإدارة متغيرات البيئة، وإعادة النشر عند الحاجة، ومراقبة حالة كل أتمتة.
يعكس اللوح سير العمل كعُقد وأسهم مع ثلاث لوحات داعمة تتيح لك تهيئة سير العمل بسهولة بدون كتابة كود؛ ما يُعرف بـ "**البرمجة الحدسية لوكلاء الذكاء الاصطناعي**".
يمكنك استخدام وظيفة السحب والإفلات لإضافة الوكلاء والمهام والأدوات إلى اللوح أو استخدام قسم الدردشة لبناء الوكلاء. يتشارك كلا النهجين الحالة ويمكن استخدامهما بالتبادل.
- **أفكار AI (يسار)**: الاستدلال المتدفق أثناء تصميم سير العمل
description: "مراجعة بشرية بمستوى المؤسسات للتدفقات مع إشعارات البريد الإلكتروني أولاً وقواعد التوجيه وإمكانيات الاستجابة التلقائية"
icon: "users-gear"
mode: "wide"
---
<Note>
تتطلب ميزات إدارة Flow HITL مزيّن `@human_feedback`، المتاح في **CrewAI الإصدار 1.8.0 أو أحدث**. تنطبق هذه الميزات تحديدًا على **التدفقات (Flows)**، وليس الأطقم (Crews).
</Note>
يوفر CrewAI Enterprise نظامًا شاملًا لإدارة الإنسان في الحلقة (HITL) للتدفقات يحوّل سير عمل الذكاء الاصطناعي إلى عمليات تعاونية بين الإنسان والذكاء الاصطناعي. تستخدم المنصة **بنية البريد الإلكتروني أولاً** التي تمكّن أي شخص لديه عنوان بريد إلكتروني من الرد على طلبات المراجعة — بدون الحاجة لحساب على المنصة.
يمكن للمستجيبين الرد مباشرة على رسائل الإشعار لتقديم الملاحظات
</Card>
<Card title="توجيه مرن" icon="route">
توجيه الطلبات إلى بريد إلكتروني محدد بناءً على أنماط الطرق أو حالة التدفق
</Card>
<Card title="استجابة تلقائية" icon="clock">
تهيئة استجابات احتياطية تلقائية عندما لا يرد أي شخص في الوقت المحدد
</Card>
</CardGroup>
### الفوائد الرئيسية
- **نموذج ذهني بسيط**: عناوين البريد الإلكتروني عالمية؛ لا حاجة لإدارة مستخدمين أو أدوار المنصة
- **مستجيبون خارجيون**: يمكن لأي شخص لديه بريد إلكتروني الرد، حتى غير مستخدمي المنصة
- **تعيين ديناميكي**: سحب بريد المعيّن مباشرة من حالة التدفق (مثل `sales_rep_email`)
- **تهيئة مخفضة**: إعدادات أقل للتهيئة، وقت أسرع للقيمة
- **البريد الإلكتروني كقناة رئيسية**: يفضل معظم المستخدمين الرد عبر البريد الإلكتروني بدلاً من تسجيل الدخول إلى لوحة التحكم
## إعداد نقاط المراجعة البشرية في التدفقات
هيّئ نقاط تفتيش المراجعة البشرية داخل تدفقاتك باستخدام مزيّن `@human_feedback`. عندما يصل التنفيذ إلى نقطة مراجعة، يتوقف النظام ويُخطر المعيّن عبر البريد الإلكتروني وينتظر الاستجابة.
```python
from crewai.flow.flow import Flow, start, listen, or_
from crewai.flow.human_feedback import human_feedback, HumanFeedbackResult
class ContentApprovalFlow(Flow):
@start()
def generate_content(self):
return "Generated marketing copy for Q1 campaign..."
@human_feedback(
message="Please review this content for brand compliance:",
description: "منع واكتشاف هلوسات الذكاء الاصطناعي في مهام CrewAI"
icon: "shield-check"
mode: "wide"
---
## نظرة عامة
حاجز الهلوسة هو ميزة مؤسسية تتحقق من المحتوى المولّد بالذكاء الاصطناعي لضمان أنه مبني على الحقائق ولا يحتوي على هلوسات. يحلل مخرجات المهام مقابل سياق مرجعي ويوفر ملاحظات مفصلة عند اكتشاف محتوى محتمل الهلوسة.
## ما هي الهلوسات؟
تحدث هلوسات الذكاء الاصطناعي عندما تولّد نماذج اللغة محتوى يبدو معقولاً لكنه غير صحيح من الناحية الواقعية أو غير مدعوم بالسياق المقدم. يساعد حاجز الهلوسة في منع هذه المشكلات من خلال:
- مقارنة المخرجات مع السياق المرجعي
- تقييم الأمانة للمادة المصدرية
- توفير ملاحظات مفصلة حول المحتوى المشكل
- دعم عتبات مخصصة لصرامة التحقق
## الاستخدام الأساسي
### إعداد الحاجز
```python
from crewai.tasks.hallucination_guardrail import HallucinationGuardrail
from crewai import LLM
# الاستخدام الأساسي - سيستخدم expected_output للمهمة كسياق
guardrail = HallucinationGuardrail(
llm=LLM(model="gpt-4o-mini")
)
# مع سياق مرجعي صريح
context_guardrail = HallucinationGuardrail(
context="AI helps with various tasks including analysis and generation.",
llm=LLM(model="gpt-4o-mini")
)
```
### الإضافة إلى المهام
```python
from crewai import Task
# إنشاء مهمتك مع الحاجز
task = Task(
description="Write a summary about AI capabilities",
expected_output="A factual summary based on the provided context",
agent=my_agent,
guardrail=guardrail # إضافة الحاجز للتحقق من المخرجات
)
```
## التهيئة المتقدمة
### التحقق بعتبة مخصصة
للتحقق الأكثر صرامة، يمكنك تعيين عتبة أمانة مخصصة (مقياس 0-10):
```python
# حاجز صارم يتطلب درجة أمانة عالية
strict_guardrail = HallucinationGuardrail(
context="Quantum computing uses qubits that exist in superposition states.",
llm=LLM(model="gpt-4o-mini"),
threshold=8.0 # يتطلب درجة >= 8 لاجتياز التحقق
)
```
### تضمين سياق استجابة الأدوات
عندما تستخدم مهمتك أدوات، يمكنك تضمين استجابات الأدوات لتحقق أكثر دقة:
```python
# حاجز مع سياق استجابة الأدوات
weather_guardrail = HallucinationGuardrail(
context="Current weather information for the requested location",
llm=LLM(model="gpt-4o-mini"),
tool_response="Weather API returned: Temperature 22°C, Humidity 65%, Clear skies"
)
```
## كيف يعمل
### عملية التحقق
1. **تحليل السياق**: يقارن الحاجز مخرجات المهمة مع السياق المرجعي المقدم
2. **تسجيل الأمانة**: يستخدم مقيّمًا داخليًا لتعيين درجة أمانة (0-10)
3. **تحديد الحكم**: يحدد ما إذا كان المحتوى أمينًا أو يحتوي على هلوسات
4. **التحقق من العتبة**: إذا تم تعيين عتبة مخصصة، يتحقق مقابل تلك الدرجة
5. **توليد الملاحظات**: يوفر أسبابًا مفصلة عند فشل التحقق
### منطق التحقق
- **الوضع الافتراضي**: يستخدم التحقق المبني على الحكم (FAITHFUL مقابل HALLUCINATED)
- **وضع العتبة**: يتطلب أن تلبي درجة الأمانة العتبة المحددة أو تتجاوزها
"feedback": "Content appears to be hallucinated (score: 4.2/10, verdict: HALLUCINATED). The output contains information not supported by the provided context."
}
```
### خصائص النتيجة
- **valid**: قيمة منطقية تشير إلى ما إذا اجتازت المخرجات التحقق
- **feedback**: شرح مفصل عند فشل التحقق، يتضمن:
- درجة الأمانة
- تصنيف الحكم
- أسباب محددة للفشل
## التكامل مع نظام المهام
### التحقق التلقائي
عند إضافة حاجز إلى مهمة، يتحقق تلقائيًا من المخرجات قبل اعتبار المهمة مكتملة:
```python
# تدفق التحقق من مخرجات المهمة
task_output = agent.execute_task(task)
validation_result = guardrail(task_output)
if validation_result.valid:
# المهمة تكتمل بنجاح
return task_output
else:
# المهمة تفشل مع ملاحظات التحقق
raise ValidationError(validation_result.feedback)
```
### تتبع الأحداث
يتكامل الحاجز مع نظام أحداث CrewAI لتوفير المراقبة:
- **بدء التحقق**: عند بدء تقييم الحاجز
- **اكتمال التحقق**: عند انتهاء التقييم بالنتائج
- **فشل التحقق**: عند حدوث أخطاء تقنية أثناء التقييم
## أفضل الممارسات
### إرشادات السياق
<Steps>
<Step title="توفير سياق شامل">
أدرج جميع المعلومات الواقعية ذات الصلة التي يجب أن يبني عليها الذكاء الاصطناعي مخرجاته:
```python
context = """
Company XYZ was founded in 2020 and specializes in renewable energy solutions.
They have 150 employees and generated $50M revenue in 2023.
Their main products include solar panels and wind turbines.
"""
```
</Step>
<Step title="الحفاظ على صلة السياق">
أدرج فقط المعلومات المرتبطة مباشرة بالمهمة لتجنب الارتباك:
```python
# جيد: سياق مركّز
context = "The current weather in New York is 18°C with light rain."
# تجنب: معلومات غير ذات صلة
context = "The weather is 18°C. The city has 8 million people. Traffic is heavy."
```
</Step>
<Step title="تحديث السياق بانتظام">
تأكد من أن السياق المرجعي يعكس معلومات حالية ودقيقة.
</Step>
</Steps>
### اختيار العتبة
<Steps>
<Step title="البدء بالتحقق الافتراضي">
ابدأ بدون عتبات مخصصة لفهم الأداء الأساسي.
</Step>
<Step title="الضبط بناءً على المتطلبات">
- **محتوى عالي الأهمية**: استخدم عتبة 8-10 للدقة القصوى
- **محتوى عام**: استخدم عتبة 6-7 للتحقق المتوازن
- **محتوى إبداعي**: استخدم عتبة 4-5 أو التحقق الافتراضي المبني على الحكم
</Step>
<Step title="المراقبة والتكرار">
تتبع نتائج التحقق واضبط العتبات بناءً على الإيجابيات/السلبيات الكاذبة.
</Step>
</Steps>
## اعتبارات الأداء
### التأثير على زمن التنفيذ
- **عبء التحقق**: يضيف كل حاجز حوالي 1-3 ثوانٍ لكل مهمة
- **كفاءة LLM**: اختر نماذج فعالة للتقييم (مثل gpt-4o-mini)
### تحسين التكلفة
- **اختيار النموذج**: استخدم نماذج أصغر وفعالة لتقييم الحاجز
- **حجم السياق**: اجعل السياق المرجعي موجزًا لكن شاملًا
- **التخزين المؤقت**: فكّر في تخزين نتائج التحقق مؤقتًا للمحتوى المتكرر
## استكشاف الأخطاء وإصلاحها
<Accordion title="فشل التحقق دائمًا">
**الأسباب المحتملة:**
- السياق مقيّد جدًا أو غير مرتبط بمخرجات المهمة
- العتبة معينة عالية جدًا لنوع المحتوى
- السياق المرجعي يحتوي على معلومات قديمة
**الحلول:**
- مراجعة وتحديث السياق ليتطابق مع متطلبات المهمة
- خفض العتبة أو استخدام التحقق الافتراضي المبني على الحكم
- التأكد من أن السياق حالي ودقيق
</Accordion>
<Accordion title="إيجابيات كاذبة (محتوى صالح يُعلّم كغير صالح)">
**الأسباب المحتملة:**
- العتبة عالية جدًا للمهام الإبداعية أو التفسيرية
- السياق لا يغطي جميع الجوانب الصالحة للمخرجات
- نموذج التقييم محافظ بشكل مفرط
**الحلول:**
- خفض العتبة أو استخدام التحقق الافتراضي
- توسيع السياق ليشمل محتوى مقبول أوسع
- الاختبار مع نماذج تقييم مختلفة
</Accordion>
<Accordion title="أخطاء التقييم">
**الأسباب المحتملة:**
- مشكلات في الاتصال بالشبكة
- نموذج LLM غير متاح أو محدود المعدل
- مخرجات مهمة أو سياق غير صالح
**الحلول:**
- التحقق من الاتصال بالشبكة وحالة خدمة LLM
- تنفيذ منطق إعادة المحاولة للأعطال المؤقتة
- التحقق من تنسيق مخرجات المهمة قبل تقييم الحاجز
</Accordion>
<Card title="هل تحتاج مساعدة؟" icon="headset" href="mailto:support@crewai.com">
تواصل مع فريق الدعم للمساعدة في تهيئة حاجز الهلوسة أو استكشاف الأخطاء وإصلاحها.
description: "إخفاء البيانات الحساسة تلقائياً من تتبعات تنفيذ الطواقم والتدفقات"
icon: "lock"
mode: "wide"
---
## نظرة عامة
إخفاء البيانات الشخصية (PII Redaction) هو ميزة في CrewAI AMP تكتشف تلقائياً وتُقنّع معلومات التعريف الشخصية (PII) في تتبعات تنفيذ الطواقم والتدفقات. يضمن ذلك عدم كشف البيانات الحساسة مثل أرقام بطاقات الائتمان وأرقام الضمان الاجتماعي وعناوين البريد الإلكتروني والأسماء في تتبعات CrewAI AMP. يمكنك أيضاً إنشاء مُعرّفات مخصصة لحماية البيانات الخاصة بمؤسستك.
<Info>
إخفاء البيانات الشخصية متاح في خطة Enterprise.
يجب أن يكون إصدار النشر 1.8.0 أو أعلى.
</Info>
<Frame>

</Frame>
## أهمية إخفاء البيانات الشخصية
عند تشغيل وكلاء الذكاء الاصطناعي في بيئة الإنتاج، غالباً ما تمر معلومات حساسة عبر طواقمك:
- بيانات العملاء من تكاملات CRM
- معلومات مالية من معالجات الدفع
- تفاصيل شخصية من إرسالات النماذج
- بيانات الموظفين الداخلية
بدون إخفاء مناسب، تظهر هذه البيانات في التتبعات، مما يجعل الامتثال للوائح مثل GDPR وHIPAA وPCI-DSS أمراً صعباً. يحل إخفاء البيانات الشخصية هذه المشكلة عن طريق إقناع البيانات الحساسة تلقائياً قبل تخزينها في التتبعات.
## كيف يعمل
1. **الاكتشاف** - مسح بيانات أحداث التتبع بحثاً عن أنماط PII المعروفة
2. **التصنيف** - تحديد نوع البيانات الحساسة (بطاقة ائتمان، SSN، بريد إلكتروني، إلخ.)
3. **الإقناع/الإخفاء** - استبدال البيانات الحساسة بقيم مُقنّعة بناءً على تهيئتك
```
Original: "Contact john.doe@company.com or call 555-123-4567"
Redacted: "Contact <EMAIL_ADDRESS> or call <PHONE_NUMBER>"
```
## تفعيل إخفاء البيانات الشخصية
<Info>
يجب أن تكون على خطة Enterprise وأن يكون إصدار النشر 1.8.0 أو أعلى لاستخدام هذه الميزة.
</Info>
<Steps>
<Step title="الانتقال إلى إعدادات الطاقم">
في لوحة تحكم CrewAI AMP، اختر طاقمك المنشور وانتقل إلى أحد عمليات النشر/الأتمتة، ثم انتقل إلى **Settings** → **PII Protection**.
</Step>
<Step title="تفعيل حماية البيانات الشخصية">
فعّل **PII Redaction for Traces**. سيؤدي ذلك إلى تفعيل المسح والإخفاء التلقائي لبيانات التتبع.
<Info>
تحتاج إلى تفعيل إخفاء البيانات الشخصية يدوياً لكل عملية نشر.
</Info>
<Frame>

</Frame>
</Step>
<Step title="تهيئة أنواع الكيانات">
اختر أنواع البيانات الشخصية التي تريد اكتشافها وإخفاءها. يمكن تفعيل أو تعطيل كل كيان بشكل فردي.
- **Entity Type**: تسمية الكيان التي ستظهر في المخرجات المُخفاة (مثل `EMPLOYEE_ID`، `SALARY`)
- **Type**: اختر بين Regex Pattern أو Deny List
- **Pattern/Values**: نمط Regex أو قائمة نصوص للمطابقة
- **Confidence Threshold**: الحد الأدنى للنتيجة (0.0-1.0) المطلوبة لتفعيل الإخفاء عند المطابقة. القيم الأعلى (مثل 0.8) تقلل الإيجابيات الخاطئة لكن قد تفوّت بعض المطابقات. القيم الأقل (مثل 0.5) تلتقط المزيد من المطابقات لكن قد تُفرط في الإخفاء. القيمة الافتراضية هي 0.8.
- **Context Words** (اختياري): كلمات تزيد ثقة الاكتشاف عند وجودها بالقرب
</Step>
<Step title="الحفظ">
احفظ المُعرّف. سيكون متاحاً للتفعيل في عمليات النشر الخاصة بك.
</Step>
</Steps>
### فهم أنواع الكيانات
يحدد **Entity Type** كيفية ظهور المحتوى المُطابق في التتبعات المُخفاة:
```
Entity Type: SALARY
Pattern: salary:\s*\$\s*\d+
Input: "Employee salary: $50,000"
Output: "Employee <SALARY>"
```
### استخدام كلمات السياق
تحسّن كلمات السياق الدقة عن طريق زيادة الثقة عند ظهور مصطلحات محددة بالقرب من النمط المُطابق:
```
Context Words: "project", "code", "internal"
Entity Type: PROJECT_CODE
Pattern: PRJ-\d{4}
```
عندما تظهر كلمة "project" أو "code" بالقرب من "PRJ-1234"، يكون لدى المُعرّف ثقة أعلى بأنها مطابقة حقيقية، مما يقلل الإيجابيات الخاطئة.
## عرض التتبعات المُخفاة
بمجرد تفعيل إخفاء البيانات الشخصية، ستعرض تتبعاتك قيماً مُخفاة بدلاً من البيانات الحساسة:
```
Task Output: "Customer <PERSON> placed order #12345.
Payment processed for card ending in <CREDIT_CARD>."
```
القيم المُخفاة مُعلّمة بوضوح بأقواس زاوية وتسمية نوع الكيان (مثل `<EMAIL_ADDRESS>`)، مما يسهّل فهم البيانات التي تمت حمايتها مع السماح لك بتصحيح الأخطاء ومراقبة سلوك الطاقم.
## أفضل الممارسات
### اعتبارات الأداء
<Steps>
<Step title="فعّل الكيانات المطلوبة فقط">
كل كيان مُفعّل يضيف عبء معالجة. فعّل فقط الكيانات ذات الصلة ببياناتك.
</Step>
<Step title="استخدم أنماطاً محددة">
للمُعرّفات المخصصة، استخدم أنماطاً محددة لتقليل الإيجابيات الخاطئة وتحسين الأداء. أنماط Regex هي الأفضل عند تحديد أنماط معينة في التتبعات مثل الرواتب ومعرّفات الموظفين ورموز المشاريع وغيرها. مُعرّفات قائمة الحظر هي الأفضل عند تحديد نصوص بعينها في التتبعات مثل أسماء الشركات والأسماء الرمزية الداخلية وغيرها.
</Step>
<Step title="استفد من كلمات السياق">
تحسّن كلمات السياق الدقة عن طريق تفعيل الاكتشاف فقط عندما يتطابق النص المحيط.
</Step>
</Steps>
## استكشاف الأخطاء وإصلاحها
<Accordion title="البيانات الشخصية لا تُخفى">
**الأسباب المحتملة:**
- نوع الكيان غير مُفعّل في التهيئة
- النمط لا يتطابق مع تنسيق البيانات
- المُعرّف المخصص يحتوي على أخطاء في الصياغة
**الحلول:**
- تحقق من أن الكيان مُفعّل في Settings → Security
- اختبر أنماط Regex مع بيانات نموذجية
- تحقق من السجلات بحثاً عن أخطاء التهيئة
</Accordion>
<Accordion title="إخفاء بيانات أكثر من اللازم">
**الأسباب المحتملة:**
- أنواع كيانات واسعة جداً مُفعّلة (مثل `DATE_TIME` تلتقط التواريخ في كل مكان)
- أنماط المُعرّف المخصص عامة جداً
**الحلول:**
- عطّل الكيانات التي تسبب إيجابيات خاطئة
- اجعل الأنماط المخصصة أكثر تحديداً
- أضف كلمات سياق لتحسين الدقة
</Accordion>
<Accordion title="مشاكل الأداء">
**الأسباب المحتملة:**
- عدد كبير جداً من الكيانات المُفعّلة
- الكيانات القائمة على NLP (مثل `PERSON` و`LOCATION` و`NRP`) مكلفة حسابياً لأنها تستخدم نماذج تعلم الآلة
**الحلول:**
- فعّل فقط الكيانات التي تحتاجها فعلاً
- فكّر في استخدام بدائل قائمة على الأنماط حيثما أمكن
- راقب أوقات معالجة التتبعات في لوحة التحكم
</Accordion>
---
## مثال عملي: مطابقة نمط الراتب
يوضح هذا المثال كيفية إنشاء مُعرّف مخصص لاكتشاف وإقناع معلومات الرواتب في تتبعاتك.
### حالة الاستخدام
يعالج طاقمك بيانات موظفين أو بيانات مالية تتضمن معلومات رواتب بتنسيقات مثل:
- `salary: $50,000`
- `salary: $125,000.00`
- `salary:$1,500.50`
تريد إقناع هذه القيم تلقائياً لحماية بيانات التعويضات الحساسة.
| `(\.\d{2})?` | يطابق اختيارياً السنتات (مثل ".00"، ".50") |
### أمثلة على النتائج
```
Original: "Employee record shows salary: $125,000.00 annually"
Redacted: "Employee record shows <SALARY> annually"
Original: "Base salary:$50,000 with bonus potential"
Redacted: "Base <SALARY> with bonus potential"
```
<Tip>
إضافة كلمات سياق مثل "salary" و"compensation" و"pay" و"wage" و"income" تساعد في زيادة ثقة الاكتشاف عند ظهور هذه المصطلحات بالقرب من النمط المُطابق، مما يقلل الإيجابيات الخاطئة.
</Tip>
### تفعيل المُعرّف لعمليات النشر
<Warning>
إنشاء مُعرّف مخصص على مستوى المؤسسة لا يفعّله تلقائياً لعمليات النشر. يجب عليك تفعيل كل مُعرّف يدوياً لكل عملية نشر تريد تطبيقه عليها.
</Warning>
بعد إنشاء المُعرّف المخصص، فعّله لكل عملية نشر:
<Steps>
<Step title="الانتقال إلى عملية النشر">
انتقل إلى عملية النشر/الأتمتة وافتح **Settings** → **PII Protection**.
</Step>
<Step title="اختيار المُعرّفات المخصصة">
تحت **Mask Recognizers**، سترى المُعرّفات المحددة على مستوى مؤسستك. حدد المربع بجانب المُعرّفات التي تريد تفعيلها.
احفظ تغييراتك. سيكون المُعرّف نشطاً في جميع عمليات التنفيذ اللاحقة لعملية النشر هذه.
</Step>
</Steps>
<Info>
كرر هذه العملية لكل عملية نشر تحتاج فيها إلى المُعرّف المخصص. يمنحك ذلك تحكماً دقيقاً في المُعرّفات النشطة في البيئات المختلفة (مثل بيئة التطوير مقابل بيئة الإنتاج).
| **Owner** | وصول كامل لجميع الميزات والإعدادات. لا يمكن تقييده. |
| **Member** | وصول للقراءة لمعظم الميزات، وصول إدارة لمتغيرات البيئة واتصالات LLM ومشاريع Studio. لا يمكنه تعديل إعدادات المؤسسة أو الإعدادات الافتراضية. |
| `default_settings` | Manage | No access | Manage / No access | تعديل الإعدادات الافتراضية على مستوى المؤسسة |
| `organization_settings` | Manage | No access | Manage / No access | إدارة الفوترة والخطط وتهيئة المؤسسة |
| `studio_projects` | Manage | Manage | Manage / No access | إنشاء وتعديل المشاريع في Studio |
<Tip>
عند إنشاء دور مخصص، يمكن ضبط معظم الميزات على **Manage** أو **Read** أو **No access**. ومع ذلك، فإن `environment_variables` و`llm_connections` و`default_settings` و`organization_settings` و`studio_projects` تدعم فقط **Manage** أو **No access** — لا يوجد خيار للقراءة فقط لهذه الميزات.
</Tip>
---
## النشر من GitHub أو Zip
من أكثر أسئلة RBAC شيوعاً: _"ما الصلاحيات التي يحتاجها عضو الفريق للنشر؟"_
### النشر من GitHub
لنشر أتمتة من مستودع GitHub، يحتاج المستخدم إلى:
1. **`crews_dashboards`**: على الأقل `Read` — مطلوب للوصول إلى لوحة الأتمتات حيث يتم إنشاء عمليات النشر
2. **الوصول إلى مستودع Git** (إذا كان RBAC على مستوى الكيان لمستودعات Git مفعلاً): يجب منح دور المستخدم الوصول إلى مستودع Git المحدد عبر صلاحيات مستوى الكيان
3. **`studio_projects`: `Manage`** — إذا كان يبني الطاقم في Studio قبل النشر
### النشر من Zip
لنشر أتمتة من ملف Zip، يحتاج المستخدم إلى:
1. **`crews_dashboards`**: على الأقل `Read` — مطلوب للوصول إلى لوحة الأتمتات
2. **تفعيل نشر Zip**: يجب ألا تكون المؤسسة قد عطلت نشر Zip في إعدادات المؤسسة
### عمليات النشر المحددة النطاق (مؤسسات متعددة المستخدمين)
يمكنك تحديد نطاق كل تكامل لمستخدم معين. على سبيل المثال، طاقم يتصل بـ Google يمكنه استخدام حساب Gmail لمستخدم محدد.
{" "}
<Tip>مفيد عندما تحتاج فرق/مستخدمون مختلفون للحفاظ على فصل الوصول إلى البيانات.</Tip>
استخدم `user_bearer_token` لتحديد نطاق المصادقة للمستخدم الطالب. إذا لم يكن المستخدم مسجل الدخول، فلن يستخدم الطاقم التكاملات المتصلة. وإلا فسيعود إلى رمز الحامل الافتراضي المهيأ لعملية النشر.
description: "استخدام بث Webhook لإرسال الأحداث إلى webhook الخاص بك"
icon: "webhook"
mode: "wide"
---
## نظرة عامة
يتيح لك بث أحداث Enterprise تلقي تحديثات webhook في الوقت الفعلي حول طواقمك وتدفقاتك المنشورة على CrewAI AMP، مثل استدعاءات النماذج واستخدام الأدوات وخطوات التدفق.
## الاستخدام
عند استخدام Kickoff API، أضف كائن `webhooks` إلى طلبك، على سبيل المثال:
إذا تم تعيين `realtime` إلى `true`، يتم تسليم كل حدث بشكل فردي وفوري، على حساب أداء الطاقم/التدفق.
## تنسيق Webhook
يرسل كل webhook قائمة بالأحداث:
```json
{
"events": [
{
"id": "event-id",
"execution_id": "crew-run-id",
"timestamp": "2025-02-16T10:58:44.965Z",
"type": "llm_call_started",
"data": {
"model": "gpt-4",
"messages": [
{ "role": "system", "content": "You are an assistant." },
{ "role": "user", "content": "Summarize this article." }
]
}
}
]
}
```
يختلف هيكل كائن `data` حسب نوع الحدث. راجع [قائمة الأحداث](https://github.com/crewAIInc/crewAI/tree/main/lib/crewai/src/crewai/events/types) على GitHub.
نظراً لأن الطلبات تُرسل عبر HTTP، لا يمكن ضمان ترتيب الأحداث. إذا كنت تحتاج الترتيب، استخدم حقل `timestamp`.
## الأحداث المدعومة
يدعم CrewAI كلاً من أحداث النظام والأحداث المخصصة في بث أحداث Enterprise. تُرسل هذه الأحداث إلى نقطة نهاية webhook المُهيأة أثناء تنفيذ الطاقم والتدفق.
### أحداث التدفق:
- `flow_created`
- `flow_started`
- `flow_finished`
- `flow_plot`
- `method_execution_started`
- `method_execution_finished`
- `method_execution_failed`
### أحداث الوكيل:
- `agent_execution_started`
- `agent_execution_completed`
- `agent_execution_error`
- `lite_agent_execution_started`
- `lite_agent_execution_completed`
- `lite_agent_execution_error`
- `agent_logs_started`
- `agent_logs_execution`
- `agent_evaluation_started`
- `agent_evaluation_completed`
- `agent_evaluation_failed`
### أحداث الطاقم:
- `crew_kickoff_started`
- `crew_kickoff_completed`
- `crew_kickoff_failed`
- `crew_train_started`
- `crew_train_completed`
- `crew_train_failed`
- `crew_test_started`
- `crew_test_completed`
- `crew_test_failed`
- `crew_test_result`
### أحداث المهام:
- `task_started`
- `task_completed`
- `task_failed`
- `task_evaluation`
### أحداث استخدام الأدوات:
- `tool_usage_started`
- `tool_usage_finished`
- `tool_usage_error`
- `tool_validate_input_error`
- `tool_selection_error`
- `tool_execution_error`
### أحداث LLM:
- `llm_call_started`
- `llm_call_completed`
- `llm_call_failed`
- `llm_stream_chunk`
### أحداث حواجز LLM:
- `llm_guardrail_started`
- `llm_guardrail_completed`
### أحداث الذاكرة:
- `memory_query_started`
- `memory_query_completed`
- `memory_query_failed`
- `memory_save_started`
- `memory_save_completed`
- `memory_save_failed`
- `memory_retrieval_started`
- `memory_retrieval_completed`
### أحداث المعرفة:
- `knowledge_search_query_started`
- `knowledge_search_query_completed`
- `knowledge_search_query_failed`
- `knowledge_query_started`
- `knowledge_query_completed`
- `knowledge_query_failed`
### أحداث الاستدلال:
- `agent_reasoning_started`
- `agent_reasoning_completed`
- `agent_reasoning_failed`
تتطابق أسماء الأحداث مع ناقل الأحداث الداخلي. راجع GitHub للقائمة الكاملة للأحداث.
يمكنك إصدار أحداثك المخصصة الخاصة، وسيتم تسليمها عبر تدفق webhook جنباً إلى جنب مع أحداث النظام.
description: "فهم كيفية عمل مشغلات CrewAI AMP وكيفية إدارتها وأين تجد أدلة التكامل الخاصة بكل خدمة"
icon: "face-smile"
mode: "wide"
---
تربط مشغلات CrewAI AMP أتمتاتك بالأحداث الفورية عبر الأدوات التي تستخدمها فرقك بالفعل. بدلاً من الاستعلام المتكرر عن الأنظمة أو الاعتماد على التشغيل اليدوي، تستمع المشغلات للتغييرات — رسائل بريد إلكتروني جديدة، تحديثات التقويم، تغييرات حالة CRM — وتطلق فوراً الطاقم أو التدفق الذي تحدده.
<Frame>

</Frame>
### أدلة التكامل
تقدم الأدلة المفصلة شرحاً لعملية الإعداد وأمثلة على سير العمل لكل تكامل:
<CardGroup cols={2}>
<Card title="مشغل Gmail" icon="envelope">
<a href="/ar/enterprise/guides/gmail-trigger">فعّل الطواقم عند وصول رسائل بريد إلكتروني أو تحديث سلاسل المحادثات.</a>
</Card>
{" "}
<Card title="مشغل Google Calendar" icon="calendar-days">
description: "تهيئة Azure OpenAI مع Crew Studio لاتصالات LLM المؤسسية"
icon: "microsoft"
mode: "wide"
---
يرشدك هذا الدليل خلال ربط Azure OpenAI مع Crew Studio لعمليات الذكاء الاصطناعي المؤسسية السلسة.
## عملية الإعداد
<Steps>
<Step title="الوصول إلى Azure AI Foundry">
1. في Azure، انتقل إلى [Azure AI Foundry](https://ai.azure.com/) > اختر نشر Azure OpenAI الخاص بك.
2. في القائمة اليسرى، انقر على `Deployments`. إذا لم يكن لديك نشر، أنشئ واحداً بالنموذج المطلوب.
3. بمجرد الإنشاء، اختر النشر وحدد موقع `Target URI` و`Key` على الجانب الأيمن من الصفحة. أبقِ هذه الصفحة مفتوحة، حيث ستحتاج هذه المعلومات.
<Frame>
<img src="/images/enterprise/azure-openai-studio.png" alt="Azure AI Foundry" />
</Frame>
</Step>
<Step title="تهيئة اتصال CrewAI AMP">
4. في علامة تبويب أخرى، افتح `CrewAI AMP > LLM Connections`. سمِّ اتصال LLM، واختر Azure كمزود، واختر نفس النموذج الذي اخترته في Azure.
5. في نفس الصفحة، أضف متغيرات البيئة من الخطوة 3:
- واحد بالاسم `AZURE_DEPLOYMENT_TARGET_URL` (باستخدام Target URI). يجب أن يبدو الرابط هكذا: https://your-deployment.openai.azure.com/openai/deployments/gpt-4o/chat/completions?api-version=2024-08-01-preview
- آخر بالاسم `AZURE_API_KEY` (باستخدام Key).
6. انقر على `Add Connection` لحفظ اتصال LLM.
</Step>
<Step title="ضبط التهيئة الافتراضية">
7. في `CrewAI AMP > Settings > Defaults > Crew Studio LLM Settings`، عيّن اتصال LLM والنموذج الجديدين كافتراضيين.
</Step>
<Step title="تهيئة الوصول إلى الشبكة">
8. تأكد من إعدادات الوصول إلى الشبكة:
- في Azure، انتقل إلى `Azure OpenAI > اختر النشر`.
- انتقل إلى `Resource Management > Networking`.
- تأكد من تفعيل `Allow access from all networks`. إذا كان هذا الإعداد مقيداً، فقد يُحظر وصول CrewAI إلى نقطة نهاية Azure OpenAI.
</Step>
</Steps>
## التحقق
أنت جاهز! سيستخدم Crew Studio الآن اتصال Azure OpenAI الخاص بك. اختبر الاتصال بإنشاء طاقم أو مهمة بسيطة للتأكد من أن كل شيء يعمل بشكل صحيح.
## استكشاف الأخطاء وإصلاحها
إذا واجهت مشكلات:
- تحقق من أن تنسيق Target URI يتطابق مع النمط المتوقع
- تحقق من صحة مفتاح API وأنه يملك الصلاحيات المناسبة
- تأكد من تهيئة الوصول إلى الشبكة للسماح باتصالات CrewAI
- تأكد من أن نموذج النشر يتطابق مع ما هيأته في CrewAI
description: "تصدير التتبعات والسجلات من عمليات نشر CrewAI AMP إلى مجمّع OpenTelemetry الخاص بك"
icon: "magnifying-glass-chart"
mode: "wide"
---
يمكن لـ CrewAI AMP تصدير **التتبعات** و**السجلات** من OpenTelemetry من عمليات النشر مباشرة إلى مجمّعك الخاص. يتيح لك ذلك مراقبة أداء الوكلاء وتتبع استدعاءات LLM وتصحيح الأخطاء باستخدام مجموعة المراقبة الحالية.
تتبع بيانات القياس [اتفاقيات OpenTelemetry GenAI الدلالية](https://opentelemetry.io/docs/specs/semconv/gen-ai/) بالإضافة إلى سمات خاصة بـ CrewAI.
## المتطلبات المسبقة
<CardGroup cols={2}>
<Card title="حساب CrewAI AMP" icon="users">
يجب أن يكون لدى مؤسستك حساب CrewAI AMP نشط.
</Card>
<Card title="مجمّع OpenTelemetry" icon="server">
تحتاج إلى نقطة نهاية مجمّع متوافقة مع OpenTelemetry (مثل OTel Collector الخاص بك أو Datadog أو Grafana أو أي واجهة خلفية متوافقة مع OTLP).
</Card>
</CardGroup>
## إعداد مجمّع
1. في CrewAI AMP، انتقل إلى **Settings** > **OpenTelemetry Collectors**.
2. انقر على **Add Collector**.
3. اختر نوع التكامل — **OpenTelemetry Traces** أو **OpenTelemetry Logs**.
4. هيّئ الاتصال:
- **Endpoint** — نقطة نهاية OTLP لمجمّعك (مثل `https://otel-collector.example.com:4317`).
- **Service Name** — اسم لتعريف هذه الخدمة في منصة المراقبة.
description: "اربط خوادم MCP الخاصة بك بـ CrewAI AMP مع وصول عام أو مصادقة بمفتاح API أو OAuth 2.0"
icon: "plug"
mode: "wide"
---
يدعم CrewAI AMP الاتصال بأي خادم MCP يُنفّذ [Model Context Protocol](https://modelcontextprotocol.io/). يمكنك إحضار خوادم عامة لا تتطلب مصادقة، وخوادم محمية بمفتاح API أو رمز حامل، وخوادم تستخدم OAuth 2.0 للوصول المفوّض الآمن.
## المتطلبات المسبقة
<CardGroup cols={2}>
<Card title="حساب CrewAI AMP" icon="user">
تحتاج إلى حساب [CrewAI AMP](https://app.crewai.com) نشط.
</Card>
<Card title="رابط خادم MCP" icon="link">
رابط خادم MCP الذي تريد الاتصال به. يجب أن يكون الخادم متاحاً من الإنترنت ويدعم نقل Streamable HTTP.
</Card>
</CardGroup>
## إضافة خادم MCP مخصص
<Steps>
<Step title="فتح الأدوات والتكاملات">
انتقل إلى **Tools & Integrations** في الشريط الجانبي الأيسر لـ CrewAI AMP، ثم اختر علامة تبويب **Connections**.
</Step>
<Step title="بدء إضافة خادم MCP مخصص">
انقر على زر **Add Custom MCP Server**. سيظهر مربع حوار مع نموذج التهيئة.
</Step>
<Step title="ملء المعلومات الأساسية">
- **Name** (مطلوب): اسم وصفي لخادم MCP (مثل "My Internal Tools Server").
- **Description**: ملخص اختياري لما يقدمه خادم MCP هذا.
- **Server URL** (مطلوب): الرابط الكامل لنقطة نهاية خادم MCP (مثل `https://my-server.example.com/mcp`).
</Step>
<Step title="اختيار طريقة المصادقة">
اختر إحدى طرق المصادقة الثلاث المتاحة بناءً على كيفية تأمين خادم MCP. راجع الأقسام أدناه لتفاصيل كل طريقة.
</Step>
<Step title="إضافة رؤوس مخصصة (اختياري)">
إذا كان خادم MCP يتطلب رؤوساً إضافية في كل طلب (مثل معرّفات المستأجر أو رؤوس التوجيه)، انقر على **+ Add Header** وقدم اسم الرأس وقيمته. يمكنك إضافة رؤوس مخصصة متعددة.
</Step>
<Step title="إنشاء الاتصال">
انقر على **Create MCP Server** لحفظ الاتصال. سيظهر خادم MCP المخصص الآن في قائمة الاتصالات وستكون أدواته متاحة للاستخدام في طواقمك.
</Step>
</Steps>
## طرق المصادقة
### بدون مصادقة
اختر هذا الخيار عندما يكون خادم MCP متاحاً للجمهور ولا يتطلب أي بيانات اعتماد. هذا شائع للخوادم مفتوحة المصدر أو الخوادم الداخلية العاملة خلف VPN.
### رمز المصادقة
استخدم هذه الطريقة عندما يكون خادم MCP محمياً بمفتاح API أو رمز حامل.
| **Client Secret** | لا | سر عميل OAuth. غير مطلوب للعملاء العامين باستخدام PKCE. |
| **Scopes** | لا | قائمة نطاقات مفصولة بمسافات للطلب (مثل `read write`). |
| **Token Auth Method** | لا | كيفية إرسال بيانات اعتماد العميل عند تبادل الرموز — **Standard (POST body)** أو **Basic Auth (header)**. الافتراضي هو Standard. |
| **PKCE Supported** | لا | فعّل إذا كان مزود OAuth يدعم Proof Key for Code Exchange. موصى به لتحسين الأمان. |
<Info>
**اكتشاف تهيئة OAuth**: إذا كان مزود OAuth يدعم OpenID Connect Discovery، انقر على رابط **Discover OAuth Config** لملء نقاط نهاية التفويض والرمز تلقائياً من رابط `/.well-known/openid-configuration` الخاص بالمزود.
</Info>
#### إعداد OAuth 2.0 خطوة بخطوة
<Steps>
<Step title="تسجيل رابط إعادة التوجيه">
انسخ **Redirect URI** المعروض في النموذج وأضفه كرابط إعادة توجيه مصرّح به في إعدادات تطبيق مزود OAuth.
</Step>
<Step title="إدخال نقاط النهاية وبيانات الاعتماد">
اختر **Token Auth Method** المناسبة. معظم المزودين يستخدمون الافتراضي **Standard (POST body)**. بعض المزودين القدامى يتطلبون **Basic Auth (header)**.
</Step>
<Step title="تفعيل PKCE (موصى به)">
حدد **PKCE Supported** إذا كان مزودك يدعمه. يضيف PKCE طبقة أمان إضافية لتدفق رمز التفويض وموصى به لجميع التكاملات الجديدة.
</Step>
<Step title="الإنشاء والتفويض">
انقر على **Create MCP Server**. سيتم توجيهك إلى مزود OAuth لتفويض الوصول. بمجرد التفويض، سيخزن CrewAI الرموز ويحدّثها تلقائياً حسب الحاجة.
</Step>
</Steps>
## استخدام خادم MCP المخصص
بمجرد الاتصال، تظهر أدوات خادم MCP المخصص جنباً إلى جنب مع الاتصالات المدمجة في صفحة **Tools & Integrations**. يمكنك:
- **تعيين الأدوات للوكلاء** في طواقمك تماماً كأي أداة CrewAI أخرى.
- **إدارة الرؤية** للتحكم في أعضاء الفريق الذين يمكنهم استخدام الخادم.
- **تعديل أو إزالة** الاتصال في أي وقت من قائمة الاتصالات.
<Warning>
إذا أصبح خادم MCP غير قابل للوصول أو انتهت صلاحية بيانات الاعتماد، ستفشل استدعاءات الأدوات التي تستخدم ذلك الخادم. تأكد من استقرار رابط الخادم وتحديث بيانات الاعتماد.
يمكنك أيضاً نشر طواقمك أو تدفقاتك مباشرة عبر واجهة ويب CrewAI AMP بربط حساب GitHub. لا يتطلب هذا النهج استخدام CLI على جهازك المحلي. تكتشف المنصة تلقائياً نوع مشروعك وتتعامل مع البناء بشكل مناسب.
<Steps>
<Step title="الدفع إلى GitHub">
تحتاج لدفع طاقمك إلى مستودع GitHub. إذا لم تكن قد أنشأت طاقماً بعد، يمكنك [اتباع هذا الدليل](/ar/quickstart).
</Step>
<Step title="ربط GitHub بـ CrewAI AMP">
1. سجّل الدخول إلى [CrewAI AMP](https://app.crewai.com)
## الخيار 3: إعادة النشر باستخدام API (تكامل CI/CD)
لعمليات النشر الآلية في خطوط أنابيب CI/CD، يمكنك استخدام CrewAI API لتشغيل إعادة نشر الطواقم الحالية. هذا مفيد بشكل خاص لـ GitHub Actions وJenkins أو سير عمل الأتمتة الأخرى.
<Steps>
<Step title="الحصول على رمز الوصول الشخصي">
انتقل إلى إعدادات حساب CrewAI AMP لإنشاء رمز API:
1. انتقل إلى [app.crewai.com](https://app.crewai.com)
2. انقر على **Settings** → **Account** → **Personal Access Token**
3. أنشئ رمزاً جديداً وانسخه بأمان
4. خزّن هذا الرمز كسر في نظام CI/CD
</Step>
<Step title="إيجاد UUID الأتمتة">
حدد موقع المعرّف الفريد لطاقمك المنشور:
1. انتقل إلى **Automations** في لوحة تحكم CrewAI AMP
description: "تشغيل الطواقم عند إنشاء أو تحديث أو إلغاء أحداث Google Calendar"
icon: "calendar"
mode: "wide"
---
## نظرة عامة
استخدم مشغل Google Calendar لإطلاق الأتمتات كلما تغيرت أحداث التقويم. تشمل حالات الاستخدام الشائعة إحاطة الفريق قبل اجتماع، وإخطار أصحاب المصلحة عند إلغاء حدث هام، أو تلخيص الجداول اليومية.
<Tip>
تأكد من ربط Google Calendar في **Tools & Integrations** وتفعيله
لعملية النشر التي تريد أتمتتها.
</Tip>
## تفعيل مشغل Google Calendar
1. افتح عملية النشر في CrewAI AMP
2. انتقل إلى علامة تبويب **Triggers**
3. حدد موقع **Google Calendar** وبدّل مفتاح التبديل للتفعيل
<Frame>
<img
src="/images/enterprise/calendar-trigger.png"
alt="تفعيل أو تعطيل المشغلات بالتبديل"
/>
</Frame>
## مثال: تلخيص تفاصيل الاجتماع
المقتطف أدناه يعكس مثال `calendar-event-crew.py` في مستودع المشغلات. يحلل الحمولة، ويحلل الحاضرين والتوقيت، وينتج ملخصاً للاجتماع للأدوات اللاحقة.
```python
from calendar_event_crew import GoogleCalendarEventTrigger
crew = GoogleCalendarEventTrigger().crew()
result = crew.kickoff({
"crewai_trigger_payload": calendar_payload,
})
print(result.raw)
```
استخدم `crewai_trigger_payload` تماماً كما يتم تسليمه من المشغل حتى يتمكن الطاقم من استخراج الحقول المناسبة.
## الاختبار المحلي
اختبر تكامل مشغل Google Calendar محلياً باستخدام CrewAI CLI:
```bash
# عرض جميع المشغلات المتاحة
crewai triggers list
# محاكاة مشغل Google Calendar بحمولة واقعية
crewai triggers run google_calendar/event_changed
```
سينفذ أمر `crewai triggers run` طاقمك بحمولة Calendar كاملة، مما يتيح لك اختبار منطق التحليل قبل النشر.
<Warning>
استخدم `crewai triggers run google_calendar/event_changed` (وليس `crewai run`) لمحاكاة
تنفيذ المشغل أثناء التطوير. بعد النشر، سيتلقى طاقمك
حمولة المشغل تلقائياً.
</Warning>
## مراقبة عمليات التنفيذ
تتبع قائمة **Executions** في لوحة تحكم النشر كل عملية تشغيل مُشغّلة وتعرض بيانات الحمولة الوصفية وملخصات المخرجات والأخطاء.
<Frame>
<img
src="/images/enterprise/list-executions.png"
alt="قائمة عمليات التنفيذ المُشغّلة بواسطة الأتمتة"
/>
</Frame>
## استكشاف الأخطاء وإصلاحها
- تأكد من ربط حساب Google الصحيح وتفعيل المشغل
- اختبر محلياً بـ `crewai triggers run google_calendar/event_changed` لرؤية هيكل الحمولة بالضبط
- تأكد من أن سير عملك يتعامل مع أحداث اليوم الكامل (الحمولات تستخدم `start.date` و`end.date` بدلاً من الطوابع الزمنية)
- تحقق من سجلات التنفيذ إذا كانت التذكيرات أو مصفوفات الحاضرين مفقودة — قد تحد صلاحيات التقويم من الحقول في الحمولة
- تذكر: استخدم `crewai triggers run` (وليس `crewai run`) لمحاكاة تنفيذ المشغل
description: "الاستجابة لأحداث ملفات Google Drive بطواقم آلية"
icon: "folder"
mode: "wide"
---
## نظرة عامة
شغّل أتمتاتك عند إنشاء أو تحديث أو حذف ملفات في Google Drive. تشمل سير العمل النموذجية تلخيص المحتوى المُحمّل حديثاً، وتطبيق سياسات المشاركة، أو إخطار المالكين عند تغيير ملفات هامة.
<Tip>
اربط Google Drive في **Tools & Integrations** وتأكد من تفعيل المشغل
للأتمتة التي تريد مراقبتها.
</Tip>
## تفعيل مشغل Google Drive
1. افتح عملية النشر في CrewAI AMP
2. انتقل إلى علامة تبويب **Triggers**
3. حدد موقع **Google Drive** وبدّل مفتاح التبديل للتفعيل
description: "تشغيل طواقم CrewAI مباشرة من سير عمل HubSpot"
icon: "hubspot"
mode: "wide"
---
يقدم هذا الدليل عملية خطوة بخطوة لإعداد مشغلات HubSpot لـ CrewAI AMP، مما يتيح لك بدء الطواقم مباشرة من سير عمل HubSpot.
## المتطلبات المسبقة
- حساب CrewAI AMP
- حساب HubSpot مع ميزة [HubSpot Workflows](https://knowledge.hubspot.com/workflows/create-workflows)
## خطوات الإعداد
<Steps>
<Step title="ربط حساب HubSpot بـ CrewAI AMP">
- سجّل الدخول إلى `حساب CrewAI AMP > Triggers` - اختر `HubSpot` من
قائمة المشغلات المتاحة - اختر حساب HubSpot الذي تريد ربطه
بـ CrewAI AMP - اتبع التعليمات على الشاشة لتفويض وصول CrewAI AMP
إلى حساب HubSpot - ستظهر رسالة تأكيد بمجرد
ربط HubSpot بنجاح مع CrewAI AMP
</Step>
<Step title="إنشاء سير عمل HubSpot">
- سجّل الدخول إلى `حساب HubSpot > Automations > Workflows > New workflow`
- اختر نوع سير العمل المناسب لاحتياجاتك (مثل Start from scratch) -
في منشئ سير العمل، انقر على أيقونة Plus (+) لإضافة إجراء جديد. -
اختر `Integrated apps > CrewAI > Kickoff a Crew`. - اختر الطاقم الذي
تريد تشغيله. - انقر على `Save` لإضافة الإجراء إلى سير عملك
<Frame>
<img
src="/images/enterprise/hubspot-workflow-1.png"
alt="سير عمل HubSpot 1"
/>
</Frame>
</Step>
<Step title="استخدام نتائج الطاقم مع إجراءات أخرى">
- بعد خطوة Kickoff a Crew، انقر على أيقونة Plus (+) لإضافة
إجراء جديد. - على سبيل المثال، لإرسال إشعار بريد إلكتروني داخلي، اختر
`Communications > Send internal email notification` - في حقل Body،
انقر على `Insert data`، اختر `View properties or action outputs from > Action
outputs > Crew Result` لتضمين بيانات الطاقم في البريد الإلكتروني
<Frame>
<img
src="/images/enterprise/hubspot-workflow-2.png"
alt="سير عمل HubSpot 2"
/>
</Frame>
- هيّئ أي إجراءات إضافية حسب الحاجة - راجع خطوات
سير عملك للتأكد من إعداد كل شيء بشكل صحيح - فعّل سير العمل
<Frame>
<img
src="/images/enterprise/hubspot-workflow-3.png"
alt="سير عمل HubSpot 3"
/>
</Frame>
</Step>
</Steps>
لمزيد من المعلومات المفصلة حول الإجراءات المتاحة وخيارات التخصيص، راجع [وثائق HubSpot Workflows](https://knowledge.hubspot.com/workflows/create-workflows).
description: "تعلم كيفية تنفيذ سير عمل Human-In-The-Loop في CrewAI لتعزيز اتخاذ القرار"
icon: "user-check"
mode: "wide"
---
Human-In-The-Loop (HITL) هو نهج قوي يجمع بين الذكاء الاصطناعي والخبرة البشرية لتعزيز اتخاذ القرار وتحسين نتائج المهام. يوضح هذا الدليل كيفية تنفيذ HITL داخل CrewAI Enterprise.
## نهجا HITL في CrewAI
يقدم CrewAI نهجين لتنفيذ سير عمل Human-In-The-Loop:
| النهج | الأفضل لـ | الإصدار |
|-------|-----------|---------|
| **قائم على التدفق** (مُزخرف `@human_feedback`) | الإنتاج مع واجهة Enterprise، سير عمل البريد الإلكتروني أولاً، ميزات المنصة الكاملة | **1.8.0+** |
| **قائم على Webhook** | التكاملات المخصصة، الأنظمة الخارجية (Slack، Teams، إلخ.)، الإعدادات القديمة | جميع الإصدارات |
## HITL القائم على التدفق مع منصة Enterprise
<Note>
يتطلب مُزخرف `@human_feedback` **إصدار CrewAI 1.8.0 أو أعلى**.
</Note>
عند استخدام مُزخرف `@human_feedback` في تدفقاتك، يوفر CrewAI Enterprise **نظام HITL يعتمد على البريد الإلكتروني أولاً** يمكّن أي شخص لديه عنوان بريد إلكتروني من الاستجابة لطلبات المراجعة:
بمجرد إتمام الطاقم للمهمة التي تتطلب إدخالاً بشرياً، ستتلقى إشعار webhook يحتوي على:
- **معرّف التنفيذ**
- **معرّف المهمة**
- **مخرجات المهمة**
</Step>
<Step title="مراجعة مخرجات المهمة">
سيتوقف النظام في حالة `Pending Human Input`. راجع مخرجات المهمة بعناية.
</Step>
<Step title="إرسال التغذية الراجعة البشرية">
استدعِ نقطة نهاية الاستئناف لطاقمك بالمعلومات التالية:
<Frame>
<img src="/images/enterprise/crew-resume-endpoint.png" alt="نقطة نهاية استئناف الطاقم" />
</Frame>
<Warning>
**هام: يجب تقديم روابط Webhook مرة أخرى**:
**يجب** تقديم نفس روابط webhook (`taskWebhookUrl`، `stepWebhookUrl`، `crewWebhookUrl`) في استدعاء الاستئناف التي استخدمتها في استدعاء التشغيل. لا تُنقل تهيئات Webhook تلقائياً من التشغيل — يجب تضمينها صراحة في طلب الاستئناف لمواصلة تلقي الإشعارات لاكتمال المهام وخطوات الوكيل واكتمال الطاقم.
description: "تشغيل الطواقم من نشاط محادثات Microsoft Teams"
icon: "microsoft"
mode: "wide"
---
## نظرة عامة
استخدم مشغل Microsoft Teams لبدء الأتمتات كلما أُنشئت محادثة جديدة. تشمل الأنماط الشائعة تلخيص الطلبات الواردة وتوجيه الرسائل العاجلة لفرق الدعم أو إنشاء مهام متابعة في أنظمة أخرى.
<Tip>
تأكد من ربط Microsoft Teams تحت **Tools & Integrations** و
تفعيله في علامة تبويب **Triggers** لعملية النشر.
</Tip>
## تفعيل مشغل Microsoft Teams
1. افتح عملية النشر في CrewAI AMP
2. انتقل إلى علامة تبويب **Triggers**
3. حدد موقع **Microsoft Teams** وبدّل مفتاح التبديل للتفعيل
<Frame caption="اتصال مشغل Microsoft Teams">
<img
src="/images/enterprise/msteams-trigger.png"
alt="تفعيل أو تعطيل المشغلات بالتبديل"
/>
</Frame>
## مثال: تلخيص سلسلة محادثة جديدة
```python
from teams_chat_created_crew import MicrosoftTeamsChatTrigger
crew = MicrosoftTeamsChatTrigger().crew()
result = crew.kickoff({
"crewai_trigger_payload": teams_payload,
})
print(result.raw)
```
يحلل الطاقم بيانات المحادثة الوصفية (الموضوع، وقت الإنشاء، قائمة الأعضاء) وينشئ خطة عمل للفريق المستقبل.
## الاختبار المحلي
اختبر تكامل مشغل Microsoft Teams محلياً باستخدام CrewAI CLI:
```bash
# عرض جميع المشغلات المتاحة
crewai triggers list
# محاكاة مشغل Microsoft Teams بحمولة واقعية
crewai triggers run microsoft_teams/teams_message_created
```
سينفذ أمر `crewai triggers run` طاقمك بحمولة Teams كاملة، مما يتيح لك اختبار منطق التحليل قبل النشر.
<Warning>
استخدم `crewai triggers run microsoft_teams/teams_message_created` (وليس `crewai
run`) لمحاكاة تنفيذ المشغل أثناء التطوير. بعد النشر، سيتلقى
طاقمك حمولة المشغل تلقائياً.
</Warning>
## استكشاف الأخطاء وإصلاحها
- تأكد من أن اتصال Teams نشط؛ يجب تحديثه إذا سحب المستأجر الصلاحيات
- اختبر محلياً بـ `crewai triggers run microsoft_teams/teams_message_created` لرؤية هيكل الحمولة بالضبط
- تأكد من أن اشتراك webhook في Microsoft 365 لا يزال صالحاً إذا توقفت الحمولات عن الوصول
- راجع سجلات التنفيذ لعدم تطابق شكل الحمولة — قد تحذف إشعارات Graph حقولاً عندما تكون المحادثة خاصة أو مقيدة
- تذكر: استخدم `crewai triggers run` (وليس `crewai run`) لمحاكاة تنفيذ المشغل
ابدأ الأتمتات عند تغيير الملفات داخل OneDrive. يمكنك إنشاء ملخصات تدقيق وإخطار فرق الأمان بشأن المشاركة الخارجية أو تحديث أنظمة الأعمال اللاحقة ببيانات المستندات الوصفية الجديدة.
<Tip>
اربط OneDrive في **Tools & Integrations** وبدّل المشغل لعملية
النشر.
</Tip>
## تفعيل مشغل OneDrive
1. افتح عملية النشر في CrewAI AMP
2. انتقل إلى علامة تبويب **Triggers**
3. حدد موقع **OneDrive** وبدّل مفتاح التبديل للتفعيل
<Frame caption="اتصال مشغل Microsoft OneDrive">
<img
src="/images/enterprise/onedrive-trigger.png"
alt="تفعيل أو تعطيل المشغلات بالتبديل"
/>
</Frame>
## مثال: تدقيق صلاحيات الملفات
```python
from onedrive_file_crew import OneDriveFileTrigger
crew = OneDriveFileTrigger().crew()
crew.kickoff({
"crewai_trigger_payload": onedrive_payload,
})
```
يفحص الطاقم بيانات الملف الوصفية ونشاط المستخدم وتغييرات الصلاحيات لإنتاج ملخص متوافق مع متطلبات الامتثال.
## الاختبار المحلي
اختبر تكامل مشغل OneDrive محلياً باستخدام CrewAI CLI:
```bash
# عرض جميع المشغلات المتاحة
crewai triggers list
# محاكاة مشغل OneDrive بحمولة واقعية
crewai triggers run microsoft_onedrive/file_changed
```
سينفذ أمر `crewai triggers run` طاقمك بحمولة OneDrive كاملة، مما يتيح لك اختبار منطق التحليل قبل النشر.
<Warning>
استخدم `crewai triggers run microsoft_onedrive/file_changed` (وليس `crewai run`)
لمحاكاة تنفيذ المشغل أثناء التطوير. بعد النشر، سيتلقى طاقمك
حمولة المشغل تلقائياً.
</Warning>
## استكشاف الأخطاء وإصلاحها
- تأكد من أن الحساب المتصل لديه صلاحية قراءة بيانات الملف الوصفية المضمنة في webhook
- اختبر محلياً بـ `crewai triggers run microsoft_onedrive/file_changed` لرؤية هيكل الحمولة بالضبط
- إذا كان المشغل يعمل لكن الحمولة تفتقد `permissions`، تأكد من أن إعدادات المشاركة على مستوى الموقع تسمح لـ Graph بإرجاع هذا الحقل
- للمستأجرين الكبار، صفّ الإشعارات مسبقاً حتى يعمل الطاقم فقط على المجلدات ذات الصلة
- تذكر: استخدم `crewai triggers run` (وليس `crewai run`) لمحاكاة تنفيذ المشغل
description: "إطلاق الأتمتات من رسائل Outlook وتحديثات التقويم"
icon: "microsoft"
mode: "wide"
---
## نظرة عامة
أتمت الاستجابات عندما يسلّم Outlook رسالة جديدة أو عند إزالة حدث من التقويم. تقوم الفرق عادة بتوجيه التصعيدات وإنشاء تذاكر أو تنبيه الحاضرين بالإلغاءات.
<Tip>
اربط Outlook في **Tools & Integrations** وتأكد من تفعيل المشغل
لعملية النشر.
</Tip>
## تفعيل مشغل Outlook
1. افتح عملية النشر في CrewAI AMP
2. انتقل إلى علامة تبويب **Triggers**
3. حدد موقع **Outlook** وبدّل مفتاح التبديل للتفعيل
<Frame caption="اتصال مشغل Microsoft Outlook">
<img
src="/images/enterprise/outlook-trigger.png"
alt="تفعيل أو تعطيل المشغلات بالتبديل"
/>
</Frame>
## مثال: تلخيص رسالة بريد إلكتروني جديدة
```python
from outlook_message_crew import OutlookMessageTrigger
crew = OutlookMessageTrigger().crew()
crew.kickoff({
"crewai_trigger_payload": outlook_payload,
})
```
يستخرج الطاقم تفاصيل المرسل والموضوع ومعاينة النص والمرفقات قبل إنشاء استجابة منظمة.
## الاختبار المحلي
اختبر تكامل مشغل Outlook محلياً باستخدام CrewAI CLI:
```bash
# عرض جميع المشغلات المتاحة
crewai triggers list
# محاكاة مشغل Outlook بحمولة واقعية
crewai triggers run microsoft_outlook/email_received
```
سينفذ أمر `crewai triggers run` طاقمك بحمولة Outlook كاملة، مما يتيح لك اختبار منطق التحليل قبل النشر.
<Warning>
استخدم `crewai triggers run microsoft_outlook/email_received` (وليس `crewai run`)
لمحاكاة تنفيذ المشغل أثناء التطوير. بعد النشر، سيتلقى طاقمك
حمولة المشغل تلقائياً.
</Warning>
## استكشاف الأخطاء وإصلاحها
- تحقق من أن موصل Outlook لا يزال مفوّضاً؛ يجب تجديد الاشتراك دورياً
- اختبر محلياً بـ `crewai triggers run microsoft_outlook/email_received` لرؤية هيكل الحمولة بالضبط
- إذا كانت المرفقات مفقودة، تأكد من أن اشتراك webhook يتضمن علامة `includeResourceData`
- راجع سجلات التنفيذ عندما تفشل الأحداث في المطابقة — حمولات الإلغاء تفتقد قوائم الحاضرين حسب التصميم ويجب أن يأخذ الطاقم ذلك في الاعتبار
- تذكر: استخدم `crewai triggers run` (وليس `crewai run`) لمحاكاة تنفيذ المشغل
| **Azure DevOps Artifacts** | `https://pkgs.dev.azure.com/{org}/_packaging/{feed}/pypi/simple/` | أي نص غير فارغ (مثل `token`) | Personal Access Token (PAT) بنطاق Packaging Read |
| **GitHub Packages** | `https://pypi.pkg.github.com/{owner}/simple/` | اسم مستخدم GitHub | Personal Access Token (classic) بنطاق `read:packages` |
| **GitLab Package Registry** | `https://gitlab.com/api/v4/projects/{project_id}/packages/pypi/simple/` | `__token__` | Project أو Personal Access Token بنطاق `read_api` |
| **AWS CodeArtifact** | استخدم الرابط من `aws codeartifact get-repository-endpoint` | `aws` | رمز من `aws codeartifact get-authorization-token` |
| **Google Artifact Registry** | `https://{region}-python.pkg.dev/{project}/{repo}/simple/` | `_json_key_base64` | مفتاح حساب الخدمة بتشفير Base64 |
| **JFrog Artifactory** | `https://{instance}.jfrog.io/artifactory/api/pypi/{repo}/simple/` | اسم المستخدم أو البريد الإلكتروني | مفتاح API أو رمز الهوية |
| **مستضاف ذاتياً (devpi، Nexus، إلخ.)** | رابط Simple API لسجلك | اسم مستخدم السجل | كلمة مرور السجل |
<Tip>
لـ **AWS CodeArtifact**، تنتهي صلاحية رمز التفويض دورياً.
ستحتاج لتحديث قيمة `UV_INDEX_*_PASSWORD` عند انتهاء صلاحيتها.
فكّر في أتمتة هذا في خط أنابيب CI/CD.
</Tip>
## تعيين متغيرات البيئة في AMP
يجب تهيئة بيانات اعتماد السجل الخاص كمتغيرات بيئة في CrewAI AMP.
لديك خياران:
<Tabs>
<Tab title="واجهة الويب">
1. سجّل الدخول إلى [CrewAI AMP](https://app.crewai.com)
2. انتقل إلى أتمتتك
3. افتح علامة تبويب **Environment Variables**
4. أضف كل متغير (`UV_INDEX_*_USERNAME` و`UV_INDEX_*_PASSWORD`) مع قيمته
راجع خطوة [النشر على AMP — تعيين متغيرات البيئة](/ar/enterprise/guides/deploy-to-amp#set-environment-variables) للتفاصيل.
</Tab>
<Tab title="النشر عبر CLI">
أضف المتغيرات إلى ملف `.env` المحلي قبل تشغيل `crewai deploy create`.
description: "تشغيل طواقم CrewAI من سير عمل Salesforce لأتمتة CRM"
icon: "salesforce"
mode: "wide"
---
يمكن تشغيل CrewAI AMP من Salesforce لأتمتة سير عمل إدارة علاقات العملاء وتعزيز عمليات المبيعات.
## نظرة عامة
Salesforce هي منصة رائدة لإدارة علاقات العملاء (CRM) تساعد الشركات على تبسيط عمليات المبيعات والخدمة والتسويق. من خلال إعداد مشغلات CrewAI من Salesforce، يمكنك:
- أتمتة تسجيل وتأهيل العملاء المحتملين
- إنشاء مواد مبيعات مخصصة
- تعزيز خدمة العملاء بردود مدعومة بالذكاء الاصطناعي
1. **تواصل مع الدعم**: تواصل مع دعم CrewAI AMP للمساعدة في إعداد مشغل Salesforce
2. **مراجعة المتطلبات**: تأكد من أن لديك صلاحيات Salesforce اللازمة والوصول إلى API
3. **تهيئة الاتصال**: اعمل مع فريق الدعم لإنشاء الاتصال بين CrewAI ومثيل Salesforce الخاص بك
4. **اختبار المشغلات**: تحقق من عمل المشغلات بشكل صحيح مع حالات الاستخدام المحددة
## حالات الاستخدام
سيناريوهات Salesforce + CrewAI الشائعة تشمل:
- **معالجة العملاء المحتملين**: تحليل وتسجيل العملاء المحتملين الوافدين تلقائياً
- **إنشاء العروض**: إنشاء عروض مخصصة بناءً على بيانات الفرص
- **رؤى العملاء**: إنشاء تقارير تحليلية من سجل تفاعلات العملاء
- **أتمتة المتابعة**: إنشاء رسائل متابعة وتوصيات مخصصة
## الخطوات التالية
للحصول على تعليمات الإعداد المفصلة وخيارات التهيئة المتقدمة، يرجى التواصل مع دعم CrewAI AMP الذي يمكنه تقديم إرشادات مخصصة لبيئة Salesforce واحتياجات عملك المحددة.
- صلاحيات الوصول للنشر أو التثبيت في مؤسسة CrewAI AMP
## تثبيت الأدوات
لتثبيت أداة:
```bash
crewai tool install <tool-name>
```
يثبّت هذا الأداة ويضيفها إلى `pyproject.toml`.
يمكنك استخدام الأداة باستيرادها وإضافتها إلى وكلائك:
```python
from your_tool.tool import YourTool
custom_tool = YourTool()
researcher = Agent(
role='Market Research Analyst',
goal='Provide up-to-date market analysis of the AI industry',
backstory='An expert analyst with a keen eye for market trends.',
tools=[custom_tool],
verbose=True
)
```
## إضافة حزم أخرى بعد تثبيت أداة
بعد تثبيت أداة من مستودع أدوات CrewAI AMP، تحتاج لاستخدام أمر `crewai uv` لإضافة حزم أخرى لمشروعك.
استخدام أوامر `uv` المباشرة سيفشل لأن المصادقة لمستودع الأدوات يتم التعامل معها عبر CLI. باستخدام أمر `crewai uv`، يمكنك إضافة حزم أخرى لمشروعك دون القلق بشأن المصادقة.
يمكن استخدام أي أمر `uv` مع أمر `crewai uv`، مما يجعله أداة قوية لإدارة اعتماديات مشروعك دون عناء إدارة المصادقة عبر متغيرات البيئة أو طرق أخرى.
لنفرض أنك ثبّت أداة مخصصة من مستودع أدوات CrewAI AMP تسمى "my-tool":
```bash
crewai tool install my-tool
```
والآن تريد إضافة حزمة أخرى لمشروعك، يمكنك استخدام الأمر التالي:
```bash
crewai uv add requests
```
أوامر أخرى مثل `uv sync` أو `uv remove` يمكن أيضاً استخدامها مع أمر `crewai uv`:
```bash
crewai uv sync
```
```bash
crewai uv remove requests
```
سيضيف هذا الحزمة لمشروعك ويحدّث `pyproject.toml` وفقاً لذلك.
## إنشاء ونشر الأدوات
لإنشاء مشروع أداة جديد:
```bash
crewai tool create <tool-name>
```
يولّد هذا مشروع أداة مُهيكل محلياً.
بعد إجراء التغييرات، أنشئ مستودع Git وارفع الكود:
```bash
git init
git add .
git commit -m "Initial version"
```
لنشر الأداة:
```bash
crewai tool publish
```
افتراضياً، تُنشر الأدوات كخاصة. لجعل الأداة عامة:
```bash
crewai tool publish --public
```
لمزيد من التفاصيل حول بناء الأدوات، راجع [إنشاء أدواتك الخاصة](/ar/concepts/tools#creating-your-own-tools).
## تحديث الأدوات
لتحديث أداة منشورة:
1. عدّل الأداة محلياً
2. حدّث الإصدار في `pyproject.toml` (مثل من `0.1.0` إلى `0.1.1`)
3. ارفع التغييرات وانشر
```bash
git commit -m "Update version to 0.1.1"
crewai tool publish
```
## حذف الأدوات
لحذف أداة:
1. انتقل إلى [CrewAI AMP](https://app.crewai.com)
2. انتقل إلى **Tools**
3. اختر الأداة
4. انقر على **Delete**
<Warning>
الحذف نهائي. لا يمكن استعادة أو إعادة تثبيت الأدوات المحذوفة.
</Warning>
## فحوصات الأمان
كل إصدار منشور يخضع لفحوصات أمان آلية، ولا يكون متاحاً للتثبيت إلا بعد اجتيازها.
description: "قم بتدريب طواقمك المنشورة مباشرة من منصة CrewAI AMP لتحسين أداء الوكلاء بمرور الوقت"
icon: "dumbbell"
mode: "wide"
---
يتيح لك التدريب تحسين أداء الطاقم من خلال تشغيل جلسات تدريب تكرارية مباشرة من علامة تبويب **Training** في CrewAI AMP. تستخدم المنصة **وضع التدريب التلقائي** — حيث تتولى العملية التكرارية تلقائياً، على عكس تدريب CLI الذي يتطلب ملاحظات بشرية تفاعلية لكل تكرار.
بعد اكتمال التدريب، يقوم CrewAI بتقييم مخرجات الوكلاء ودمج الملاحظات في اقتراحات قابلة للتنفيذ لكل وكيل. يتم بعد ذلك تطبيق هذه الاقتراحات على تشغيلات الطاقم المستقبلية لتحسين جودة المخرجات.
<Tip>
للحصول على تفاصيل حول كيفية عمل تدريب CrewAI، راجع صفحة [مفاهيم التدريب](/ar/concepts/training).
</Tip>
## المتطلبات الأساسية
<CardGroup cols={2}>
<Card title="نشر نشط" icon="rocket">
تحتاج إلى حساب CrewAI AMP مع نشر نشط في حالة **Ready** (نوع Crew).
</Card>
<Card title="صلاحية التشغيل" icon="key">
يجب أن يكون لحسابك صلاحية تشغيل للنشر الذي تريد تدريبه.
</Card>
</CardGroup>
## كيفية تدريب طاقم
<Steps>
<Step title="افتح علامة تبويب Training">
انتقل إلى **Deployments**، انقر على نشرك، ثم اختر علامة تبويب **Training**.
</Step>
<Step title="أدخل اسم التدريب">
قدم **Training Name** — سيصبح هذا اسم ملف `.pkl` المستخدم لتخزين نتائج التدريب. على سبيل المثال، "Expert Mode Training" ينتج `expert_mode_training.pkl`.
</Step>
<Step title="املأ مدخلات الطاقم">
أدخل حقول إدخال الطاقم. هذه هي نفس المدخلات التي ستقدمها للتشغيل العادي — يتم تحميلها ديناميكياً بناءً على تكوين طاقمك.
</Step>
<Step title="ابدأ التدريب">
انقر على **Train Crew**. يتغير الزر إلى "Training..." مع مؤشر دوران أثناء تشغيل العملية.
خلف الكواليس:
- يتم إنشاء سجل تدريب للنشر الخاص بك
- تستدعي المنصة نقطة نهاية التدريب التلقائي للنشر
- يقوم الطاقم بتشغيل تكراراته تلقائياً — لا حاجة لملاحظات يدوية
</Step>
<Step title="راقب التقدم">
تعرض لوحة **Current Training Status**:
- **Status** — الحالة الحالية لجلسة التدريب
- **Nº Iterations** — عدد تكرارات التدريب المُهيأة
- **Filename** — ملف `.pkl` الذي يتم إنشاؤه
- **Started At** — وقت بدء التدريب
- **Training Inputs** — المدخلات التي قدمتها
</Step>
</Steps>
## فهم نتائج التدريب
بمجرد اكتمال التدريب، سترى بطاقات نتائج لكل وكيل تحتوي على المعلومات التالية:
- **Agent Role** — اسم/دور الوكيل في طاقمك
- **Final Quality** — درجة من 0 إلى 10 تقيّم جودة مخرجات الوكيل
- **Final Summary** — ملخص لأداء الوكيل أثناء التدريب
في بطاقة نتائج أي وكيل، انقر على زر **Edit** بجوار الاقتراحات.
</Step>
<Step title="عدّل الاقتراحات">
حدّث نص الاقتراحات ليعكس التحسينات التي تريدها بشكل أفضل.
</Step>
<Step title="احفظ التغييرات">
انقر على **Save**. تتم مزامنة الاقتراحات المُعدّلة مع النشر وتُستخدم في جميع التشغيلات المستقبلية.
</Step>
</Steps>
## استخدام بيانات التدريب
لتطبيق نتائج التدريب على طاقمك:
1. لاحظ **Training Filename** (ملف `.pkl`) من جلسة التدريب المكتملة.
2. حدد اسم الملف هذا في تكوين kickoff أو التشغيل الخاص بنشرك.
3. يقوم الطاقم تلقائياً بتحميل ملف التدريب وتطبيق الاقتراحات المخزنة على كل وكيل.
هذا يعني أن الوكلاء يستفيدون من الملاحظات المُنشأة أثناء التدريب في كل تشغيل لاحق.
## التدريبات السابقة
يعرض الجزء السفلي من علامة تبويب Training **سجل جميع جلسات التدريب السابقة** للنشر. استخدم هذا لمراجعة التدريبات السابقة، ومقارنة النتائج، أو اختيار ملف تدريب مختلف للاستخدام.
## معالجة الأخطاء
إذا فشل تشغيل التدريب، تعرض لوحة الحالة حالة خطأ مع رسالة تصف ما حدث خطأ.
الأسباب الشائعة لفشل التدريب:
- **لم يتم تحديث وقت تشغيل النشر** — تأكد من أن نشرك يعمل بأحدث إصدار
- **أخطاء تنفيذ الطاقم** — مشاكل في منطق مهام الطاقم أو تكوين الوكيل
- **مشاكل الشبكة** — مشاكل الاتصال بين المنصة والنشر
## القيود
<Info>
ضع هذه القيود في الاعتبار عند التخطيط لسير عمل التدريب الخاص بك:
- **تدريب نشط واحد في كل مرة** لكل نشر — انتظر حتى ينتهي التشغيل الحالي قبل بدء آخر
- **وضع التدريب التلقائي فقط** — لا تدعم المنصة الملاحظات التفاعلية لكل تكرار مثل CLI
- **بيانات التدريب خاصة بالنشر** — ترتبط نتائج التدريب بمثيل وإصدار النشر المحدد
description: "أتمتة سير عمل CrewAI AMP باستخدام webhooks مع منصات مثل ActivePieces وZapier وMake.com"
icon: "webhook"
mode: "wide"
---
يتيح لك CrewAI AMP أتمتة سير عملك باستخدام webhooks. ستوجهك هذه المقالة خلال عملية إعداد واستخدام webhooks لبدء تنفيذ طاقمك، مع التركيز على التكامل مع ActivePieces، وهي منصة أتمتة سير العمل مشابهة لـ Zapier وMake.com.
## إعداد Webhooks
<Steps>
<Step title="الوصول إلى واجهة البدء">
- انتقل إلى لوحة تحكم CrewAI AMP
- ابحث عن قسم `/kickoff`، الذي يُستخدم لبدء تنفيذ الطاقم
في قسم محتوى JSON، ستحتاج إلى تقديم المعلومات التالية:
- **inputs**: كائن JSON يحتوي على:
- `company`: اسم الشركة (مثال: "tesla")
- `product_name`: اسم المنتج (مثال: "crewai")
- `form_response`: نوع الاستجابة (مثال: "financial")
- `icp_description`: وصف موجز لملف العميل المثالي
- `product_description`: وصف قصير للمنتج
- `taskWebhookUrl`، `stepWebhookUrl`، `crewWebhookUrl`: عناوين URL لنقاط نهاية webhook المختلفة (ActivePieces أو Zapier أو Make.com أو منصة أخرى متوافقة)
</Step>
<Step title="التكامل مع ActivePieces">
في هذا المثال سنستخدم ActivePieces. يمكنك استخدام منصات أخرى مثل Zapier وMake.com
**ملاحظة:** أي كائن `meta` مُقدم في طلب البدء الخاص بك سيتم تضمينه في جميع حمولات webhook، مما يتيح لك تتبع الطلبات والحفاظ على السياق عبر دورة حياة تنفيذ الطاقم بالكامل.
<Tabs>
<Tab title="Step Webhook">
`stepWebhookUrl` - رد نداء يتم تنفيذه عند كل فكرة داخلية للوكيل
```json
{
"prompt": "Research the financial industry for potential AI solutions",
"thought": "I need to conduct preliminary research on the financial industry",
"tool": "research_tool",
"tool_input": "financial industry AI solutions",
"result": "**Preliminary Research Report on the Financial Industry for crewai Enterprise Solution**\n1. Industry Overview and Trends\nThe financial industry in ....\nConclusion:\nThe financial industry presents a fertile ground for implementing AI solutions like crewai, particularly in areas such as digital customer engagement, risk management, and regulatory compliance. Further engagement with the lead is recommended to better tailor the crewai solution to their specific needs and scale.",
`taskWebhookUrl` - رد نداء يتم تنفيذه عند انتهاء كل مهمة
```json
{
"description": "Using the information gathered from the lead's data, conduct preliminary research on the lead's industry, company background, and potential use cases for crewai. Focus on finding relevant data that can aid in scoring the lead and planning a strategy to pitch them crewai.",
"name": "Industry Research Task",
"expected_output": "Detailed research report on the financial industry",
"summary": "The financial industry presents a fertile ground for implementing AI solutions like crewai, particularly in areas such as digital customer engagement, risk management, and regulatory compliance. Further engagement with the lead is recommended to better tailor the crewai solution to their specific needs and scale.",
"agent": "Research Agent",
"output": "**Preliminary Research Report on the Financial Industry for crewai Enterprise Solution**\n1. Industry Overview and Trends\nThe financial industry in ....\nConclusion:\nThe financial industry presents a fertile ground for implementing AI solutions like crewai, particularly in areas such as digital customer engagement, risk management, and regulatory compliance.",
"result": "**Final Analysis Report**\n\nLead Score: Customer service enhancement and compliance are particularly relevant.\n\nTalking Points:\n- Highlight how crewai's AI solutions can transform customer service\n- Discuss crewai's potential for sustainability goals\n- Emphasize compliance capabilities\n- Stress adaptability for various operation scales",
"result_json": {
"lead_score": "Customer service enhancement, and compliance are particularly relevant.",
"talking_points": [
"Highlight how crewai's AI solutions can transform customer service with automated, personalized experiences and 24/7 support, improving both customer satisfaction and operational efficiency.",
"Discuss crewai's potential to help the institution achieve its sustainability goals through better data analysis and decision-making, contributing to responsible investing and green initiatives.",
"Emphasize crewai's ability to enhance compliance with evolving regulations through efficient data processing and reporting, reducing the risk of non-compliance penalties.",
"Stress the adaptability of crewai to support both extensive multinational operations and smaller, targeted projects, ensuring the solution grows with the institution's needs."
- تأكد من أن مدخلات CrewAI AMP مربوطة بشكل صحيح من رسالة Slack.
- اختبر Zap الخاص بك جيدًا قبل تفعيله لاكتشاف أي مشاكل محتملة.
- فكر في إضافة خطوات معالجة الأخطاء لإدارة حالات الفشل المحتملة في سير العمل.
باتباع هذه الخطوات، ستكون قد أعددت بنجاح مشغلات Zapier لـ CrewAI AMP، مما يتيح سير عمل آلي يتم تشغيله بواسطة رسائل Slack وينتج عنه إشعارات بالبريد الإلكتروني مع مخرجات CrewAI AMP.
description: "تنسيق مهام الفريق والمشاريع مع تكامل Asana لـ CrewAI."
icon: "circle"
mode: "wide"
---
## نظرة عامة
مكّن وكلاءك من إدارة المهام والمشاريع وتنسيق الفريق عبر Asana. أنشئ المهام وحدّث حالة المشروع وأدر التعيينات وبسّط سير عمل فريقك مع الأتمتة المدعومة بالذكاء الاصطناعي.
## المتطلبات الأساسية
قبل استخدام تكامل Asana، تأكد من أن لديك:
- حساب [CrewAI AMP](https://app.crewai.com) مع اشتراك نشط
- حساب Asana مع الأذونات المناسبة
- ربط حساب Asana الخاص بك عبر [صفحة التكاملات](https://app.crewai.com/crewai_plus/connectors)
## إعداد تكامل Asana
### 1. ربط حساب Asana الخاص بك
1. انتقل إلى [تكاملات CrewAI AMP](https://app.crewai.com/crewai_plus/connectors)
2. ابحث عن **Asana** في قسم تكاملات المصادقة
3. انقر على **ربط** وأكمل تدفق OAuth
4. امنح الأذونات اللازمة لإدارة المهام والمشاريع
5. انسخ رمز Enterprise الخاص بك من [إعدادات التكامل](https://app.crewai.com/crewai_plus/settings/integrations)
### 2. تثبيت الحزمة المطلوبة
```bash
uv add crewai-tools
```
### 3. إعداد متغير البيئة
<Note>
لاستخدام التكاملات مع `Agent(apps=[])`, يجب تعيين متغير البيئة
`CREWAI_PLATFORM_INTEGRATION_TOKEN` برمز Enterprise الخاص بك.
- `task` (string, مطلوب): معرف المهمة - معرف المهمة التي سيُضاف إليها التعليق. سيُنسب التعليق للمستخدم المصادق عليه حاليًا.
- `text` (string, مطلوب): النص (مثال: "This is a comment.").
</Accordion>
<Accordion title="asana/create_project">
**الوصف:** إنشاء مشروع في Asana.
**المعاملات:**
- `name` (string, مطلوب): الاسم (مثال: "Stuff to buy").
- `workspace` (string, مطلوب): مساحة العمل - استخدم إعدادات سير عمل بوابة الاتصال للسماح للمستخدمين باختيار مساحة العمل لإنشاء المشاريع فيها. الافتراضي هو أول مساحة عمل للمستخدم إذا تُرك فارغًا.
- `team` (string, اختياري): الفريق - استخدم إعدادات سير عمل بوابة الاتصال للسماح للمستخدمين باختيار الفريق لمشاركة هذا المشروع معه. الافتراضي هو أول فريق للمستخدم إذا تُرك فارغًا.
- `notes` (string, اختياري): ملاحظات (مثال: "These are things we need to purchase.").
</Accordion>
<Accordion title="asana/get_projects">
**الوصف:** الحصول على قائمة المشاريع في Asana.
**المعاملات:**
- `archived` (string, اختياري): مؤرشف - اختر "true" لعرض المشاريع المؤرشفة، "false" لعرض المشاريع النشطة فقط، أو "default" لعرض كليهما.
- الخيارات: `default`, `true`, `false`
</Accordion>
<Accordion title="asana/get_project_by_id">
**الوصف:** الحصول على مشروع بواسطة المعرف في Asana.
- `name` (string, مطلوب): الاسم (مثال: "Task Name").
- `workspace` (string, اختياري): مساحة العمل - استخدم إعدادات سير عمل بوابة الاتصال للسماح للمستخدمين باختيار مساحة العمل لإنشاء المهام فيها. الافتراضي هو أول مساحة عمل للمستخدم إذا تُرك فارغًا.
- `project` (string, اختياري): المشروع - استخدم إعدادات سير عمل بوابة الاتصال للسماح للمستخدمين باختيار المشروع لإنشاء هذه المهمة فيه.
- `notes` (string, اختياري): ملاحظات.
- `dueOnDate` (string, اختياري): تاريخ الاستحقاق - التاريخ الذي تستحق فيه هذه المهمة. لا يمكن استخدامه مع Due At. (مثال: "YYYY-MM-DD").
- `dueAtDate` (string, اختياري): الاستحقاق في - التاريخ والوقت (طابع زمني ISO) الذي تستحق فيه هذه المهمة. لا يمكن استخدامه مع Due On. (مثال: "2019-09-15T02:06:58.147Z").
- `assignee` (string, اختياري): المُكلف - معرف مستخدم Asana الذي سيتم تعيين هذه المهمة له. استخدم إعدادات سير عمل بوابة الاتصال للسماح للمستخدمين باختيار المُكلف.
- `gid` (string, اختياري): معرف خارجي - معرف من تطبيقك لربط هذه المهمة به. يمكنك استخدام هذا المعرف لمزامنة التحديثات لهذه المهمة لاحقًا.
</Accordion>
<Accordion title="asana/update_task">
**الوصف:** تحديث مهمة في Asana.
**المعاملات:**
- `taskId` (string, مطلوب): معرف المهمة - معرف المهمة التي سيتم تحديثها.
- `completeStatus` (string, اختياري): حالة الإكمال.
- الخيارات: `true`, `false`
- `name` (string, اختياري): الاسم (مثال: "Task Name").
- `notes` (string, اختياري): ملاحظات.
- `dueOnDate` (string, اختياري): تاريخ الاستحقاق - التاريخ الذي تستحق فيه هذه المهمة. لا يمكن استخدامه مع Due At. (مثال: "YYYY-MM-DD").
- `dueAtDate` (string, اختياري): الاستحقاق في - التاريخ والوقت (طابع زمني ISO) الذي تستحق فيه هذه المهمة. لا يمكن استخدامه مع Due On. (مثال: "2019-09-15T02:06:58.147Z").
- `assignee` (string, اختياري): المُكلف - معرف مستخدم Asana الذي سيتم تعيين هذه المهمة له.
- `gid` (string, اختياري): معرف خارجي - معرف من تطبيقك لربط هذه المهمة به.
</Accordion>
<Accordion title="asana/get_tasks">
**الوصف:** الحصول على قائمة المهام في Asana.
**المعاملات:**
- `workspace` (string, اختياري): مساحة العمل - معرف مساحة العمل لتصفية المهام عليها.
- `project` (string, اختياري): المشروع - معرف المشروع لتصفية المهام عليه.
- `completedSince` (string, اختياري): مكتملة منذ - إرجاع المهام غير المكتملة فقط أو التي اكتملت منذ هذا الوقت (طابع زمني ISO أو Unix). (مثال: "2014-04-25T16:15:47-04:00").
</Accordion>
<Accordion title="asana/get_tasks_by_id">
**الوصف:** الحصول على قائمة المهام بواسطة المعرف في Asana.
**المعاملات:**
- `taskId` (string, مطلوب): معرف المهمة.
</Accordion>
<Accordion title="asana/get_task_by_external_id">
**الوصف:** الحصول على مهمة بواسطة المعرف الخارجي في Asana.
**المعاملات:**
- `gid` (string, مطلوب): المعرف الخارجي - المعرف الذي ترتبط أو تتزامن به هذه المهمة، من تطبيقك.
</Accordion>
<Accordion title="asana/add_task_to_section">
**الوصف:** إضافة مهمة إلى قسم في Asana.
**المعاملات:**
- `sectionId` (string, مطلوب): معرف القسم - معرف القسم لإضافة هذه المهمة إليه.
- `beforeTaskId` (string, اختياري): معرف المهمة السابقة - معرف مهمة في هذا القسم سيتم إدراج هذه المهمة قبلها. لا يمكن استخدامه مع After Task ID. (مثال: "1204619611402340").
- `afterTaskId` (string, اختياري): معرف المهمة التالية - معرف مهمة في هذا القسم سيتم إدراج هذه المهمة بعدها. لا يمكن استخدامه مع Before Task ID. (مثال: "1204619611402340").
</Accordion>
<Accordion title="asana/get_teams">
**الوصف:** الحصول على قائمة الفرق في Asana.
**المعاملات:**
- `workspace` (string, مطلوب): مساحة العمل - إرجاع الفرق في مساحة العمل هذه المرئية للمستخدم المصرح له.
</Accordion>
<Accordion title="asana/get_workspaces">
**الوصف:** الحصول على قائمة مساحات العمل في Asana.
**المعاملات:** لا توجد معاملات مطلوبة.
</Accordion>
</AccordionGroup>
## أمثلة الاستخدام
### إعداد وكيل Asana الأساسي
```python
from crewai import Agent, Task, Crew
# Create an agent with Asana capabilities
asana_agent = Agent(
role="Project Manager",
goal="Manage tasks and projects in Asana efficiently",
backstory="An AI assistant specialized in project management and task coordination.",
apps=['asana'] # All Asana actions will be available
)
# Task to create a new project
create_project_task = Task(
description="Create a new project called 'Q1 Marketing Campaign' in the Marketing workspace",
agent=asana_agent,
expected_output="Confirmation that the project was created successfully with project ID"
)
# Run the task
crew = Crew(
agents=[asana_agent],
tasks=[create_project_task]
)
crew.kickoff()
```
### تصفية أدوات Asana محددة
```python
from crewai import Agent, Task, Crew
# Create agent with specific Asana actions only
task_manager_agent = Agent(
role="Task Manager",
goal="Create and manage tasks efficiently",
backstory="An AI assistant that focuses on task creation and management.",
apps=[
'asana/create_task',
'asana/update_task',
'asana/get_tasks'
] # Specific Asana actions
)
# Task to create and assign a task
task_management = Task(
description="Create a task called 'Review quarterly reports' and assign it to the appropriate team member",
agent=task_manager_agent,
expected_output="Task created and assigned successfully"
)
crew = Crew(
agents=[task_manager_agent],
tasks=[task_management]
)
crew.kickoff()
```
### إدارة المشاريع المتقدمة
```python
from crewai import Agent, Task, Crew
project_coordinator = Agent(
role="Project Coordinator",
goal="Coordinate project activities and track progress",
backstory="An experienced project coordinator who ensures projects run smoothly.",
description: "تخزين الملفات وإدارة المستندات مع تكامل Box لـ CrewAI."
icon: "box"
mode: "wide"
---
## نظرة عامة
مكّن وكلاءك من إدارة الملفات والمجلدات والمستندات عبر Box. ارفع الملفات، ونظّم هياكل المجلدات، وابحث في المحتوى، وبسّط إدارة مستندات فريقك باستخدام الأتمتة المدعومة بالذكاء الاصطناعي.
## المتطلبات الأساسية
قبل استخدام تكامل Box، تأكد من توفر ما يلي:
- حساب [CrewAI AMP](https://app.crewai.com) مع اشتراك فعّال
- حساب Box بالصلاحيات المناسبة
- ربط حساب Box الخاص بك عبر [صفحة التكاملات](https://app.crewai.com/crewai_plus/connectors)
## إعداد تكامل Box
### 1. ربط حساب Box الخاص بك
1. انتقل إلى [تكاملات CrewAI AMP](https://app.crewai.com/crewai_plus/connectors)
2. ابحث عن **Box** في قسم تكاملات المصادقة
3. انقر على **Connect** وأكمل عملية OAuth
4. امنح الصلاحيات اللازمة لإدارة الملفات والمجلدات
5. انسخ رمز المؤسسة من [إعدادات التكامل](https://app.crewai.com/crewai_plus/settings/integrations)
### 2. تثبيت الحزمة المطلوبة
```bash
uv add crewai-tools
```
### 3. إعداد متغير البيئة
<Note>
لاستخدام التكاملات مع `Agent(apps=[])`, يجب تعيين متغير البيئة
`CREWAI_PLATFORM_INTEGRATION_TOKEN` برمز المؤسسة الخاص بك.
- `file` (string, مطلوب): عنوان URL للملف - يجب أن يكون حجم الملفات أقل من 50 ميجابايت. (مثال: "https://picsum.photos/200/300").
</Accordion>
<Accordion title="box/save_file_from_object">
**الوصف:** حفظ ملف في Box.
**المعاملات:**
- `file` (string, مطلوب): الملف - يقبل كائن ملف يحتوي على بيانات الملف. يجب أن يكون حجم الملفات أقل من 50 ميجابايت.
- `fileName` (string, مطلوب): اسم الملف (مثال: "qwerty.png").
- `folder` (string, اختياري): المجلد - استخدم إعدادات سير عمل بوابة الاتصال للسماح للمستخدمين باختيار وجهة مجلد الملف. يستخدم المجلد الجذري افتراضياً إذا تُرك فارغاً.
</Accordion>
<Accordion title="box/get_file_by_id">
**الوصف:** الحصول على ملف بواسطة المعرّف في Box.
**المعاملات:**
- `fileId` (string, مطلوب): معرّف الملف - المعرّف الفريد الذي يمثل ملفاً. (مثال: "12345").
</Accordion>
<Accordion title="box/list_files">
**الوصف:** عرض قائمة الملفات في Box.
**المعاملات:**
- `folderId` (string, مطلوب): معرّف المجلد - المعرّف الفريد الذي يمثل مجلداً. (مثال: "0").
- `filterFormula` (object, اختياري): فلتر بصيغة التعبير العادي المنفصل - OR لمجموعات AND من شروط فردية.
```json
{
"operator": "OR",
"conditions": [
{
"operator": "AND",
"conditions": [
{
"field": "direction",
"operator": "$stringExactlyMatches",
"value": "ASC"
}
]
}
]
}
```
</Accordion>
<Accordion title="box/create_folder">
**الوصف:** إنشاء مجلد في Box.
**المعاملات:**
- `folderName` (string, مطلوب): الاسم - اسم المجلد الجديد. (مثال: "New Folder").
- `folderParent` (object, مطلوب): المجلد الأصلي - المجلد الأصلي الذي سيُنشأ فيه المجلد الجديد.
```json
{
"id": "123456"
}
```
</Accordion>
<Accordion title="box/move_folder">
**الوصف:** نقل مجلد في Box.
**المعاملات:**
- `folderId` (string, مطلوب): معرّف المجلد - المعرّف الفريد الذي يمثل مجلداً. (مثال: "0").
- `folderName` (string, مطلوب): الاسم - اسم المجلد. (مثال: "New Folder").
- `folderParent` (object, مطلوب): المجلد الأصلي - وجهة المجلد الأصلي الجديد.
```json
{
"id": "123456"
}
```
</Accordion>
<Accordion title="box/get_folder_by_id">
**الوصف:** الحصول على مجلد بواسطة المعرّف في Box.
**المعاملات:**
- `folderId` (string, مطلوب): معرّف المجلد - المعرّف الفريد الذي يمثل مجلداً. (مثال: "0").
description: "إدارة المهام والإنتاجية مع تكامل ClickUp لـ CrewAI."
icon: "list-check"
mode: "wide"
---
## نظرة عامة
مكّن وكلاءك من إدارة المهام والمشاريع وسير عمل الإنتاجية عبر ClickUp. أنشئ المهام وحدّثها، ونظّم المشاريع، وأدر تعيينات الفريق، وبسّط إدارة إنتاجيتك باستخدام الأتمتة المدعومة بالذكاء الاصطناعي.
## المتطلبات الأساسية
قبل استخدام تكامل ClickUp، تأكد من توفر ما يلي:
- حساب [CrewAI AMP](https://app.crewai.com) مع اشتراك فعّال
- حساب ClickUp بالصلاحيات المناسبة
- ربط حساب ClickUp الخاص بك عبر [صفحة التكاملات](https://app.crewai.com/crewai_plus/connectors)
## إعداد تكامل ClickUp
### 1. ربط حساب ClickUp الخاص بك
1. انتقل إلى [تكاملات CrewAI AMP](https://app.crewai.com/crewai_plus/connectors)
2. ابحث عن **ClickUp** في قسم تكاملات المصادقة
3. انقر على **Connect** وأكمل عملية OAuth
4. امنح الصلاحيات اللازمة لإدارة المهام والمشاريع
5. انسخ رمز المؤسسة من [إعدادات التكامل](https://app.crewai.com/crewai_plus/settings/integrations)
### 2. تثبيت الحزمة المطلوبة
```bash
uv add crewai-tools
```
### 3. إعداد متغير البيئة
<Note>
لاستخدام التكاملات مع `Agent(apps=[])`, يجب تعيين متغير البيئة
`CREWAI_PLATFORM_INTEGRATION_TOKEN` برمز المؤسسة الخاص بك.
**الوصف:** الحصول على المهام في قائمة محددة في ClickUp.
**المعاملات:**
- `listId` (string, مطلوب): القائمة - اختر قائمة للحصول على المهام منها. استخدم إعدادات المستخدم في بوابة الاتصال للسماح للمستخدمين باختيار قائمة ClickUp.
- `taskFilterFormula` (string, اختياري): البحث عن المهام التي تطابق الفلاتر المحددة. مثال: name=task1.
</Accordion>
<Accordion title="clickup/create_task">
**الوصف:** إنشاء مهمة في ClickUp.
**المعاملات:**
- `listId` (string, مطلوب): القائمة - اختر قائمة لإنشاء هذه المهمة فيها.
- `name` (string, مطلوب): الاسم - اسم المهمة.
- `description` (string, اختياري): الوصف - وصف المهمة.
- `status` (string, اختياري): الحالة - اختر حالة لهذه المهمة.
- `assignees` (string, اختياري): المكلّفون - اختر عضواً (أو مصفوفة من معرّفات الأعضاء) ليتم تعيينهم لهذه المهمة.
- `dueDate` (string, اختياري): تاريخ الاستحقاق - حدد تاريخ استحقاق لهذه المهمة.
- `additionalFields` (string, اختياري): حقول إضافية - حدد حقولاً إضافية لتضمينها في هذه المهمة بصيغة JSON.
</Accordion>
<Accordion title="clickup/update_task">
**الوصف:** تحديث مهمة في ClickUp.
**المعاملات:**
- `taskId` (string, مطلوب): معرّف المهمة - معرّف المهمة المراد تحديثها.
- `listId` (string, مطلوب): القائمة - اختر قائمة لإنشاء هذه المهمة فيها.
- `name` (string, اختياري): الاسم - اسم المهمة.
- `description` (string, اختياري): الوصف - وصف المهمة.
- `status` (string, اختياري): الحالة - اختر حالة لهذه المهمة.
- `assignees` (string, اختياري): المكلّفون - اختر عضواً (أو مصفوفة من معرّفات الأعضاء) ليتم تعيينهم لهذه المهمة.
- `dueDate` (string, اختياري): تاريخ الاستحقاق - حدد تاريخ استحقاق لهذه المهمة.
- `additionalFields` (string, اختياري): حقول إضافية - حدد حقولاً إضافية لتضمينها في هذه المهمة بصيغة JSON.
</Accordion>
<Accordion title="clickup/delete_task">
**الوصف:** حذف مهمة في ClickUp.
**المعاملات:**
- `taskId` (string, مطلوب): معرّف المهمة - معرّف المهمة المراد حذفها.
</Accordion>
<Accordion title="clickup/get_list">
**الوصف:** الحصول على معلومات القائمة في ClickUp.
**المعاملات:**
- `spaceId` (string, مطلوب): معرّف المساحة - معرّف المساحة التي تحتوي على القوائم.
description: "إدارة المستودعات والمشكلات مع تكامل GitHub لـ CrewAI."
icon: "github"
mode: "wide"
---
## نظرة عامة
مكّن وكلاءك من إدارة المستودعات والمشكلات والإصدارات عبر GitHub. أنشئ المشكلات وحدّثها، وأدر الإصدارات، وتتبع تطور المشاريع، وبسّط سير عمل تطوير البرمجيات باستخدام الأتمتة المدعومة بالذكاء الاصطناعي.
## المتطلبات الأساسية
قبل استخدام تكامل GitHub، تأكد من توفر ما يلي:
- حساب [CrewAI AMP](https://app.crewai.com) مع اشتراك فعّال
- حساب GitHub بصلاحيات المستودع المناسبة
- ربط حساب GitHub الخاص بك عبر [صفحة التكاملات](https://app.crewai.com/crewai_plus/connectors)
## إعداد تكامل GitHub
### 1. ربط حساب GitHub الخاص بك
1. انتقل إلى [تكاملات CrewAI AMP](https://app.crewai.com/crewai_plus/connectors)
2. ابحث عن **GitHub** في قسم تكاملات المصادقة
3. انقر على **Connect** وأكمل عملية OAuth
4. امنح الصلاحيات اللازمة لإدارة المستودعات والمشكلات
5. انسخ رمز المؤسسة من [إعدادات التكامل](https://app.crewai.com/crewai_plus/settings/integrations)
### 2. تثبيت الحزمة المطلوبة
```bash
uv add crewai-tools
```
### 3. إعداد متغير البيئة
<Note>
لاستخدام التكاملات مع `Agent(apps=[])`, يجب تعيين متغير البيئة
`CREWAI_PLATFORM_INTEGRATION_TOKEN` برمز المؤسسة الخاص بك.
- `assignees` (string, اختياري): المكلّفون - حدد اسم (أسماء) تسجيل الدخول في GitHub للمكلّفين كمصفوفة من السلاسل النصية لهذه المشكلة. (مثال: `["octocat"]`).
</Accordion>
<Accordion title="github/update_issue">
**الوصف:** تحديث مشكلة في GitHub.
**المعاملات:**
- `owner` (string, مطلوب): المالك - حدد اسم مالك الحساب للمستودع المرتبط بهذه المشكلة. (مثال: "abc").
- `repo` (string, مطلوب): المستودع - حدد اسم المستودع المرتبط بهذه المشكلة.
- `issue_number` (string, مطلوب): رقم المشكلة - حدد رقم المشكلة المراد تحديثها.
- `title` (string, مطلوب): عنوان المشكلة - حدد عنوان المشكلة المراد تحديثها.
- `assignees` (string, اختياري): المكلّفون - حدد اسم (أسماء) تسجيل الدخول في GitHub للمكلّفين كمصفوفة من السلاسل النصية لهذه المشكلة. (مثال: `["octocat"]`).
- `state` (string, اختياري): الحالة - حدد الحالة المحدّثة للمشكلة.
- الخيارات: `open`, `closed`
</Accordion>
<Accordion title="github/get_issue_by_number">
**الوصف:** الحصول على مشكلة بواسطة الرقم في GitHub.
**المعاملات:**
- `owner` (string, مطلوب): المالك - حدد اسم مالك الحساب للمستودع المرتبط بهذه المشكلة. (مثال: "abc").
- `repo` (string, مطلوب): المستودع - حدد اسم المستودع المرتبط بهذه المشكلة.
- `issue_number` (string, مطلوب): رقم المشكلة - حدد رقم المشكلة المراد جلبها.
</Accordion>
<Accordion title="github/lock_issue">
**الوصف:** قفل مشكلة في GitHub.
**المعاملات:**
- `owner` (string, مطلوب): المالك - حدد اسم مالك الحساب للمستودع المرتبط بهذه المشكلة. (مثال: "abc").
- `repo` (string, مطلوب): المستودع - حدد اسم المستودع المرتبط بهذه المشكلة.
- `issue_number` (string, مطلوب): رقم المشكلة - حدد رقم المشكلة المراد قفلها.
- `lock_reason` (string, مطلوب): سبب القفل - حدد سبب قفل محادثة المشكلة أو طلب السحب.
- `owner` (string, مطلوب): المالك - حدد اسم مالك الحساب للمستودع المرتبط بهذا الإصدار. (مثال: "abc").
- `repo` (string, مطلوب): المستودع - حدد اسم المستودع المرتبط بهذا الإصدار.
- `tag_name` (string, مطلوب): الاسم - حدد اسم وسم الإصدار المراد إنشاؤه. (مثال: "v1.0.0").
- `target_commitish` (string, اختياري): الهدف - حدد هدف الإصدار. يمكن أن يكون اسم فرع أو SHA لعملية إيداع. الافتراضي هو الفرع الرئيسي. (مثال: "master").
- `body` (string, اختياري): المحتوى - حدد وصفاً لهذا الإصدار.
- `draft` (string, اختياري): مسودة - حدد ما إذا كان الإصدار المُنشأ يجب أن يكون مسودة (غير منشور).
- الخيارات: `true`, `false`
- `prerelease` (string, اختياري): إصدار تجريبي - حدد ما إذا كان الإصدار المُنشأ يجب أن يكون إصداراً تجريبياً.
- الخيارات: `true`, `false`
- `discussion_category_name` (string, اختياري): اسم فئة المناقشة - إذا حُدد، يتم إنشاء مناقشة من الفئة المحددة وربطها بالإصدار.
- `generate_release_notes` (string, اختياري): ملاحظات الإصدار - حدد ما إذا كان يجب إنشاء ملاحظات الإصدار تلقائياً.
- الخيارات: `true`, `false`
</Accordion>
<Accordion title="github/update_release">
**الوصف:** تحديث إصدار في GitHub.
**المعاملات:**
- `owner` (string, مطلوب): المالك - حدد اسم مالك الحساب للمستودع المرتبط بهذا الإصدار. (مثال: "abc").
- `repo` (string, مطلوب): المستودع - حدد اسم المستودع المرتبط بهذا الإصدار.
- `tag_name` (string, اختياري): الاسم - حدد اسم وسم الإصدار المراد تحديثه. (مثال: "v1.0.0").
- `target_commitish` (string, اختياري): الهدف - حدد هدف الإصدار. يمكن أن يكون اسم فرع أو SHA لعملية إيداع. الافتراضي هو الفرع الرئيسي. (مثال: "master").
- `body` (string, اختياري): المحتوى - حدد وصفاً لهذا الإصدار.
- `draft` (string, اختياري): مسودة - حدد ما إذا كان الإصدار يجب أن يكون مسودة (غير منشور).
- الخيارات: `true`, `false`
- `prerelease` (string, اختياري): إصدار تجريبي - حدد ما إذا كان الإصدار يجب أن يكون إصداراً تجريبياً.
- الخيارات: `true`, `false`
- `discussion_category_name` (string, اختياري): اسم فئة المناقشة - إذا حُدد، يتم إنشاء مناقشة من الفئة المحددة وربطها بالإصدار.
- `generate_release_notes` (string, اختياري): ملاحظات الإصدار - حدد ما إذا كان يجب إنشاء ملاحظات الإصدار تلقائياً.
- الخيارات: `true`, `false`
</Accordion>
<Accordion title="github/get_release_by_id">
**الوصف:** الحصول على إصدار بواسطة المعرّف في GitHub.
**المعاملات:**
- `owner` (string, مطلوب): المالك - حدد اسم مالك الحساب للمستودع المرتبط بهذا الإصدار. (مثال: "abc").
- `repo` (string, مطلوب): المستودع - حدد اسم المستودع المرتبط بهذا الإصدار.
description: "إدارة البريد الإلكتروني وجهات الاتصال مع تكامل Gmail لـ CrewAI."
icon: "envelope"
mode: "wide"
---
## نظرة عامة
مكّن وكلاءك من إدارة رسائل البريد الإلكتروني وجهات الاتصال والمسودات عبر Gmail. أرسل رسائل البريد الإلكتروني، وابحث في الرسائل، وأدر جهات الاتصال، وأنشئ المسودات، وبسّط اتصالات البريد الإلكتروني باستخدام الأتمتة المدعومة بالذكاء الاصطناعي.
## المتطلبات الأساسية
قبل استخدام تكامل Gmail، تأكد من توفر ما يلي:
- حساب [CrewAI AMP](https://app.crewai.com) مع اشتراك فعّال
- حساب Gmail بالصلاحيات المناسبة
- ربط حساب Gmail الخاص بك عبر [صفحة التكاملات](https://app.crewai.com/crewai_plus/connectors)
## إعداد تكامل Gmail
### 1. ربط حساب Gmail الخاص بك
1. انتقل إلى [تكاملات CrewAI AMP](https://app.crewai.com/crewai_plus/connectors)
2. ابحث عن **Gmail** في قسم تكاملات المصادقة
3. انقر على **Connect** وأكمل عملية OAuth
4. امنح الصلاحيات اللازمة لإدارة البريد الإلكتروني وجهات الاتصال
5. انسخ رمز المؤسسة من [إعدادات التكامل](https://app.crewai.com/crewai_plus/settings/integrations)
### 2. تثبيت الحزمة المطلوبة
```bash
uv add crewai-tools
```
### 3. إعداد متغير البيئة
<Note>
لاستخدام التكاملات مع `Agent(apps=[])`, يجب تعيين متغير البيئة
`CREWAI_PLATFORM_INTEGRATION_TOKEN` برمز المؤسسة الخاص بك.
description: "إدارة الأحداث والجداول الزمنية مع تكامل Google Calendar لـ CrewAI."
icon: "calendar"
mode: "wide"
---
## نظرة عامة
مكّن وكلاءك من إدارة أحداث التقويم والجداول الزمنية والتوفر عبر Google Calendar. أنشئ الأحداث وحدّثها، وأدر الحضور، وتحقق من التوفر، وبسّط سير عمل الجدولة باستخدام الأتمتة المدعومة بالذكاء الاصطناعي.
## المتطلبات الأساسية
قبل استخدام تكامل Google Calendar، تأكد من توفر ما يلي:
- حساب [CrewAI AMP](https://app.crewai.com) مع اشتراك فعّال
- حساب Google مع إمكانية الوصول إلى Google Calendar
- ربط حساب Google الخاص بك عبر [صفحة التكاملات](https://app.crewai.com/crewai_plus/connectors)
## إعداد تكامل Google Calendar
### 1. ربط حساب Google الخاص بك
1. انتقل إلى [تكاملات CrewAI AMP](https://app.crewai.com/crewai_plus/connectors)
2. ابحث عن **Google Calendar** في قسم تكاملات المصادقة
3. انقر على **Connect** وأكمل عملية OAuth
4. امنح الصلاحيات اللازمة للوصول إلى التقويم
5. انسخ رمز المؤسسة من [إعدادات التكامل](https://app.crewai.com/crewai_plus/settings/integrations)
### 2. تثبيت الحزمة المطلوبة
```bash
uv add crewai-tools
```
### 3. إعداد متغير البيئة
<Note>
لاستخدام التكاملات مع `Agent(apps=[])`, يجب تعيين متغير البيئة
`CREWAI_PLATFORM_INTEGRATION_TOKEN` برمز المؤسسة الخاص بك.
description: "إدارة جهات الاتصال والدليل مع تكامل Google Contacts لـ CrewAI."
icon: "address-book"
mode: "wide"
---
## نظرة عامة
مكّن وكلاءك من إدارة جهات الاتصال ومعلومات الدليل عبر Google Contacts. يمكنك الوصول إلى جهات الاتصال الشخصية، والبحث في أشخاص الدليل، وإنشاء معلومات الاتصال وتحديثها، وإدارة مجموعات جهات الاتصال باستخدام الأتمتة المدعومة بالذكاء الاصطناعي.
## المتطلبات الأساسية
قبل استخدام تكامل Google Contacts، تأكد من توفر ما يلي:
- حساب [CrewAI AMP](https://app.crewai.com) مع اشتراك فعّال
- حساب Google مع إمكانية الوصول إلى Google Contacts
- ربط حساب Google الخاص بك عبر [صفحة التكاملات](https://app.crewai.com/crewai_plus/connectors)
## إعداد تكامل Google Contacts
### 1. ربط حساب Google الخاص بك
1. انتقل إلى [تكاملات CrewAI AMP](https://app.crewai.com/crewai_plus/connectors)
2. ابحث عن **Google Contacts** في قسم تكاملات المصادقة
3. انقر على **Connect** وأكمل عملية OAuth
4. امنح الصلاحيات اللازمة للوصول إلى جهات الاتصال والدليل
5. انسخ رمز المؤسسة من [إعدادات التكامل](https://app.crewai.com/crewai_plus/settings/integrations)
### 2. تثبيت الحزمة المطلوبة
```bash
uv add crewai-tools
```
### 3. إعداد متغير البيئة
<Note>
لاستخدام التكاملات مع `Agent(apps=[])`, يجب تعيين متغير البيئة
`CREWAI_PLATFORM_INTEGRATION_TOKEN` برمز المؤسسة الخاص بك.
- `pageSize` (integer, اختياري): عدد النتائج المراد إرجاعها. الحد الأدنى: 1، الحد الأقصى: 30
- `pageToken` (string, اختياري): رمز يحدد صفحة النتائج المراد إرجاعها.
- `sources` (array, اختياري): المصادر المراد البحث فيها. الخيارات: READ_SOURCE_TYPE_CONTACT, READ_SOURCE_TYPE_PROFILE. الافتراضي: READ_SOURCE_TYPE_CONTACT
**الوصف:** عرض قائمة الأشخاص في دليل المستخدم المصادق عليه.
**المعاملات:**
- `sources` (array, مطلوب): مصادر الدليل المراد البحث فيها. الخيارات: DIRECTORY_SOURCE_TYPE_DOMAIN_PROFILE, DIRECTORY_SOURCE_TYPE_DOMAIN_CONTACT. الافتراضي: DIRECTORY_SOURCE_TYPE_DOMAIN_PROFILE
- `pageSize` (integer, اختياري): عدد الأشخاص المراد إرجاعهم. الحد الأدنى: 1، الحد الأقصى: 1000
- `pageToken` (string, اختياري): رمز يحدد صفحة النتائج المراد إرجاعها.
description: "إنشاء المستندات وتحريرها مع تكامل Google Docs لـ CrewAI."
icon: "file-lines"
mode: "wide"
---
## نظرة عامة
مكّن وكلاءك من إنشاء وتحرير وإدارة مستندات Google Docs مع معالجة النصوص والتنسيق. أتمت إنشاء المستندات، وأدرج النصوص واستبدلها، وأدر نطاقات المحتوى، وبسّط سير عمل المستندات باستخدام الأتمتة المدعومة بالذكاء الاصطناعي.
## المتطلبات الأساسية
قبل استخدام تكامل Google Docs، تأكد من توفر ما يلي:
- حساب [CrewAI AMP](https://app.crewai.com) مع اشتراك فعّال
- حساب Google مع إمكانية الوصول إلى Google Docs
- ربط حساب Google الخاص بك عبر [صفحة التكاملات](https://app.crewai.com/crewai_plus/connectors)
## إعداد تكامل Google Docs
### 1. ربط حساب Google الخاص بك
1. انتقل إلى [تكاملات CrewAI AMP](https://app.crewai.com/crewai_plus/connectors)
2. ابحث عن **Google Docs** في قسم تكاملات المصادقة
3. انقر على **Connect** وأكمل عملية OAuth
4. امنح الصلاحيات اللازمة للوصول إلى المستندات
5. انسخ رمز المؤسسة من [إعدادات التكامل](https://app.crewai.com/crewai_plus/settings/integrations)
### 2. تثبيت الحزمة المطلوبة
```bash
uv add crewai-tools
```
### 3. إعداد متغير البيئة
<Note>
لاستخدام التكاملات مع `Agent(apps=[])`, يجب تعيين متغير البيئة
`CREWAI_PLATFORM_INTEGRATION_TOKEN` برمز المؤسسة الخاص بك.
description="In document 'your_document_id', insert the text 'Executive Summary: ' at the beginning, then replace all instances of 'TODO' with 'COMPLETED'.",
agent=text_editor,
expected_output="Document updated with new text inserted and TODO items replaced."
)
crew = Crew(
agents=[text_editor],
tasks=[edit_content_task]
)
crew.kickoff()
```
### عمليات المستندات المتقدمة
```python
from crewai import Agent, Task, Crew
# Create an agent for advanced document operations
document_formatter = Agent(
role="Document Formatter",
goal="Apply advanced formatting and structure to Google Docs",
backstory="An AI assistant that handles complex document formatting and organization.",
description="In document 'your_document_id', insert a page break at position 100, create a named range called 'Introduction' for characters 1-50, and apply batch formatting updates.",
agent=document_formatter,
expected_output="Document formatted with page break, named range, and styling applied."
)
crew = Crew(
agents=[document_formatter],
tasks=[format_doc_task]
)
crew.kickoff()
```
## استكشاف الأخطاء وإصلاحها
### المشاكل الشائعة
**أخطاء المصادقة**
- تأكد من أن حساب Google الخاص بك لديه الصلاحيات اللازمة للوصول إلى Google Docs.
- تحقق من أن اتصال OAuth يتضمن جميع النطاقات المطلوبة (`https://www.googleapis.com/auth/documents`).
**مشاكل معرّف المستند**
- تحقق جيداً من صحة معرّفات المستندات.
- تأكد من وجود المستند وإمكانية الوصول إليه من حسابك.
- يمكن العثور على معرّفات المستندات في عنوان URL لـ Google Docs.
**عمليات إدراج النص والنطاقات**
- عند استخدام `insert_text` أو `delete_content_range`، تأكد من صحة مواضع الفهرس.
- تذكر أن Google Docs يستخدم فهرسة قائمة على الصفر.
- يجب أن يحتوي المستند على محتوى في مواضع الفهرس المحددة.
**تنسيق طلبات التحديث الدفعي**
- عند استخدام `batch_update`، تأكد من صحة تنسيق مصفوفة `requests` وفقاً لتوثيق Google Docs API.
- تتطلب التحديثات المعقدة هياكل JSON محددة لكل نوع طلب.
**عمليات استبدال النص**
- لـ `replace_text`، تأكد من مطابقة معامل `containsText` تماماً للنص المراد استبداله.
- استخدم معامل `matchCase` للتحكم في حساسية حالة الأحرف.
description: "تخزين الملفات وإدارتها مع تكامل Google Drive لـ CrewAI."
icon: "google"
mode: "wide"
---
## نظرة عامة
مكّن وكلاءك من إدارة الملفات والمجلدات عبر Google Drive. ارفع الملفات وحمّلها ونظّمها وشاركها، وأنشئ المجلدات، وبسّط سير عمل إدارة المستندات باستخدام الأتمتة المدعومة بالذكاء الاصطناعي.
## المتطلبات الأساسية
قبل استخدام تكامل Google Drive، تأكد من توفر ما يلي:
- حساب [CrewAI AMP](https://app.crewai.com) مع اشتراك فعّال
- حساب Google مع إمكانية الوصول إلى Google Drive
- ربط حساب Google الخاص بك عبر [صفحة التكاملات](https://app.crewai.com/crewai_plus/connectors)
## إعداد تكامل Google Drive
### 1. ربط حساب Google الخاص بك
1. انتقل إلى [تكاملات CrewAI AMP](https://app.crewai.com/crewai_plus/connectors)
2. ابحث عن **Google Drive** في قسم تكاملات المصادقة
3. انقر على **Connect** وأكمل عملية OAuth
4. امنح الصلاحيات اللازمة لإدارة الملفات والمجلدات
5. انسخ رمز المؤسسة من [إعدادات التكامل](https://app.crewai.com/crewai_plus/settings/integrations)
### 2. تثبيت الحزمة المطلوبة
```bash
uv add crewai-tools
```
### 3. إعداد متغير البيئة
<Note>
لاستخدام التكاملات مع `Agent(apps=[])`, يجب تعيين متغير البيئة
`CREWAI_PLATFORM_INTEGRATION_TOKEN` برمز المؤسسة الخاص بك.
description: "مزامنة بيانات جداول البيانات مع تكامل Google Sheets لـ CrewAI."
icon: "google"
mode: "wide"
---
## نظرة عامة
مكّن وكلاءك من إدارة بيانات جداول البيانات عبر Google Sheets. اقرأ الصفوف، وأنشئ إدخالات جديدة، وحدّث البيانات الموجودة، وبسّط سير عمل إدارة البيانات باستخدام الأتمتة المدعومة بالذكاء الاصطناعي. مثالي لتتبع البيانات وإعداد التقارير وإدارة البيانات التعاونية.
## المتطلبات الأساسية
قبل استخدام تكامل Google Sheets، تأكد من توفر ما يلي:
- حساب [CrewAI AMP](https://app.crewai.com) مع اشتراك فعّال
- حساب Google مع إمكانية الوصول إلى Google Sheets
- ربط حساب Google الخاص بك عبر [صفحة التكاملات](https://app.crewai.com/crewai_plus/connectors)
- جداول بيانات بترويسات أعمدة مناسبة لعمليات البيانات
## إعداد تكامل Google Sheets
### 1. ربط حساب Google الخاص بك
1. انتقل إلى [تكاملات CrewAI AMP](https://app.crewai.com/crewai_plus/connectors)
2. ابحث عن **Google Sheets** في قسم تكاملات المصادقة
3. انقر على **Connect** وأكمل عملية OAuth
4. امنح الصلاحيات اللازمة للوصول إلى جداول البيانات
5. انسخ رمز المؤسسة من [إعدادات التكامل](https://app.crewai.com/crewai_plus/settings/integrations)
### 2. تثبيت الحزمة المطلوبة
```bash
uv add crewai-tools
```
### 3. إعداد متغير البيئة
<Note>
لاستخدام التكاملات مع `Agent(apps=[])`, يجب تعيين متغير البيئة
`CREWAI_PLATFORM_INTEGRATION_TOKEN` برمز المؤسسة الخاص بك.
تواصل مع فريق الدعم للحصول على المساعدة في إعداد تكامل Google Sheets
أو استكشاف الأخطاء وإصلاحها.
</Card>
Loaded 100 of 2335 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.