CrewAI 是一个基于 Python 的开源多智能体编排框架,由 João Moura 于 2023 年创立,2024 年 1 月正式开源发布。它采用"团队作为编排"的设计哲学,通过角色(Role)、任务(Task)和团队(Crew)三层声明式抽象,让开发者能够以类似组建人类团队的方式构建多智能体协作系统。每个智能体拥有明确的角色定位、目标、背景故事和工具集,通过任务依赖关系自动协调执行顺序与上下文传递。截至 2026 年 7 月,CrewAI 在 GitHub 上已获得约 56,000 颗星标;据厂商自称,被约 60% 的财富 500 强企业采用(官方不同页面亦出现 63% 的口径,尚无独立第三方审计);月均智能体执行次数超过 4.5 亿次,2026 年 4 月官方披露的年化执行量约为 20 亿次。
CrewAI 的核心定位是"角色驱动的多智能体编排框架"(Role-Based Multi-Agent Orchestration Framework)。与传统的单智能体模式不同,CrewAI 将复杂的 AI 任务分解为由多个专业化智能体组成的虚拟团队来协作完成。每个智能体就像团队中的一名成员,拥有明确的岗位职责、工作目标和专属工具,通过声明式的方式定义协作流程,而无需编写底层的通信和协调代码。
CrewAI 从零构建,不依赖 LangChain 等外部抽象层,采用轻量级 Python 核心,具有启动速度快、内存占用低、调试简单等特点。它支持 OpenAI、Anthropic、Google Gemini、AWS Bedrock、Azure OpenAI 以及任何 LiteLLM 兼容的模型,实现模型无关的灵活部署。
Agent 是 CrewAI 的基本执行单元,代表一个具备特定专业能力的 AI 实体。每个 Agent 由以下核心要素定义:
Task 是交给智能体执行的具体工作单元,包含以下关键属性:
output_json 或 output_pydantic 指定结构化输出格式Crew 是将多个 Agent 和 Task 组织在一起的编排容器,负责统一管理任务的执行流程。它定义了:
Crew 层是一个"中心化"的编排核心,由它统一决定哪个 Agent 应该在什么时候执行哪个任务,将"流程控制逻辑"从"业务角色定义"中完全分离出来。
CrewAI 支持三种流程类型:
与 AutoGen 等"去中心化"的对话式协作模式不同,CrewAI 采用"中心化"编排。Crew 层作为内置编排器,统一集中控制所有模块交互——所有的模块交互都通过任务上下文的单向传递来实现,开发者不需要编写任何通信级别的代码。框架根据任务的依赖关系自动决定不同 Agent 之间的执行顺序,并将前序任务的输出结果作为后续任务的输入自动传递。
CrewAI 的编排核心是通过任务的依赖关系来决定执行顺序。当 Task A 的输出被 Task B 和 Task C 同时引用时,B 和 C 会自动并行执行。每个任务执行前,框架会自动将输入上下文、工具调用日志、模型输入输出存入数据库,支持任意时刻回溯。
当 allow_delegation=True 时,CrewAI 自动为智能体提供两种协作工具:
这两种工具使智能体能够像人类团队成员一样自然地沟通、协商和协作,无需开发者硬编码每一步交互。
在层级模式下,经理智能体(Manager Agent)扮演类似"团队主管"的角色:它评估每个工作智能体的输出,可以重新分配任务或请求修订,在标记任务完成前检查是否达到预期输出。这种模式适用于拥有 4 个以上智能体、任务边界模糊或需要质量把关的复杂工作流。
CrewAI 的通信机制以任务上下文传递为核心。智能体之间不直接"对话",而是通过任务依赖链实现信息流动:前序任务的输出自动注入后续任务的提示词中。这种设计使信息流清晰可追溯,当输出出现问题时,可以精确定位到是哪个智能体的哪个环节出现了故障。
启用 allow_delegation 后,智能体可以主动发起跨角色协作:
这种机制使 CrewAI 的协作更接近人类团队的自然交互模式,而非预定义的固定流程。
CrewAI 提供统一的记忆系统,所有智能体可以共享团队记忆(除非显式设置了私有作用域)。记忆系统使用 LLM 在保存时自动分析内容、推断作用域和重要性,在检索时通过复合评分(语义相似度 + 时间衰减 + 重要性权重)返回最相关的上下文。此外,知识源(Knowledge Sources)允许智能体通过语义搜索从文件、文档、URL 等来源检索相关事实。
CrewAI 已原生支持模型上下文协议(MCP)和智能体间通信协议(A2A)。自 v1.10(2026 年 3 月)起,任何符合 MCP 标准的工具服务器(数据库、工单系统、内部 API)都可以暴露给 CrewAI 智能体,无需编写自定义适配器;A2A 支持则使 CrewAI 智能体能够与其他平台(如 Amazon Bedrock)构建的智能体进行互操作通信。
CrewAI 开箱即提供 100 余种内置工具,覆盖常见的智能体能力需求:
开发者可以将任何 Python 函数包装为自定义工具。CrewAI 底层使用标准的 LLM 函数调用机制,自动管理调用/响应循环和错误处理。自定义工具可以访问外部 API、查询数据库、执行特定业务逻辑,实现无限扩展。
通过原生 MCP 支持,CrewAI 智能体可以直接调用符合 MCP 标准的外部工具服务器。这带来三个核心优势:
在生产环境中,CrewAI 支持为不同智能体分配不同的工具集,遵循最小权限原则。例如,分析师智能体可以拥有网络搜索权限,而写手智能体只负责内容生成,不直接访问搜索工具——写手通过委托机制请求分析师协助查询。这种设计减少了错误表面,使输出更加可预测,并让工作流可以逐步审计。
Flows 是 CrewAI 在 Crew 之上提供的事件驱动编排层。如果说 Crew 是"执行工作的员工",那么 Flow 就是"知道工作按什么顺序完成、失败时如何处理、上次发生了什么的管理者"。Flows 解决了纯 Crew 的三大局限:默认无状态、无分支逻辑、无编排级错误恢复。
Flows 通过三个装饰器构建工作流:
维度 | 传统图编排(如 LangGraph) | CrewAI Flows |
|---|---|---|
思维模型 | 节点、边、状态字典 | 事件、方法、装饰器 |
拓扑定义 | 显式构建有向图 | 装饰器注解自动推导 |
状态管理 | 需手动定义 TypedDict 状态 | Pydantic BaseModel 共享状态 |
持久化 | 需额外配置 Checkpointer | 内置记忆(LanceDB 支持) |
代码量 | 相同功能需要更多样板代码 | 据 DocuSign 案例,代码量减少约 14 倍 |
在生产实践中,大多数严肃的 CrewAI 系统结合两者:Flows 处理确定性的骨干逻辑(获取数据 → 验证 → 分支 → 通知),Crews 则在需要自主多智能体推理的地方嵌入。一个 Flow 可以调用单个 LLM 做快速决策,也可以启动整个 Crew 作为更大管道中的一个步骤。
CrewAI AMP(Agent Management Platform)是 CrewAI 的商业化企业级平台,建立在开源框架之上。它为组织提供从发现自动化机会、构建智能体、部署到生产环境、再到持续优化的全生命周期管理能力。AMP 的核心价值在于将开源框架的灵活性与企业级治理需求相结合。
AMP 提供三种部署模式:
开源 CrewAI 框架提供最大灵活性,适合原型设计和高度定制化需求;AMP 则添加生产级特性,包括 SOC 2、HIPAA、FedRAMP High 等安全认证,SSO、RBAC、审计追踪,以及托管基础设施和专属支持。两者保持 API 兼容,大多数智能体代码只需极少修改即可迁移。
CrewAI 提供统一的 Memory 类,将传统的短期、长期、实体和外部记忆整合为单一智能 API。记忆系统使用 LLM 在保存时自动分析内容、推断作用域(scope)、分类和重要性,在检索时支持自适应深度的复合评分召回。
记忆检索采用复合评分机制,融合三个维度:
用户可以根据项目特点调整权重配置,例如快速迭代的项目可以提高时间衰减权重。
记忆系统支持分层作用域(scope)管理,类似文件系统的目录树结构:
self.remember() 和 self.recall()CrewAI 在每次任务执行后自动从任务输出中提取离散事实并存储,在每次任务执行前自动召回相关上下文并注入任务提示词。系统还支持从长文本中提取原子事实(extract_memories),以及通过非阻塞写入和自动去重降低冗余。当 LLM 出现故障时,记忆系统会优雅降级,保障基础存取功能。
CrewAI 支持对互不依赖的独立任务进行并行执行。通过设置 async_execution=True,多个任务可以同时运行,显著缩短数据收集阶段的总耗时。当 Task A 的输出被 Task B 和 Task C 同时引用时,框架会自动并行执行 B 和 C。
流程模式 | 并发能力 | 适用场景 |
|---|---|---|
Sequential | 无并发,任务顺序执行 | 固定线性管道,如研究 → 分析 → 报告 |
Hierarchical | 经理智能体动态分配,支持一定程度的并行 | 复杂自适应工作流,4 个以上智能体 |
Parallel | 独立任务同时执行 | 独立数据收集任务,2-6 个智能体 |
当多个任务竞争同一工具(如共享的浏览器实例或 API 配额)时,CrewAI 内置公平队列按优先级和等待时间分配资源,避免任务饥饿。开发者可以通过 max_rpm(每分钟最大请求数)限制 API 调用速率,防止超出第三方服务的限流阈值。
timeout 参数,实现快速失败CrewAI 原生支持多种文件类型的输入处理,通过 crewai-files 包提供专门的类:
文件可以通过本地路径、URL 或字节流三种方式传入,支持在 Crew、Task、Flow 和单独 Agent 四个层级传递,更具体的层级具有更高优先级。
CrewAI 自动根据 LLM 提供商的 API 要求格式化文件:
对于没有文件上传 API 的提供商,CrewAI 自动使用内联 base64 编码;当文件超过提供商限制时,支持 strict、auto、warn 和 chunk 等处理模式。
开发者可以在任务描述中使用文件的键名引用文件,智能体会自动理解并处理:
task = Task(
description="""
分析提供的材料:
1. 审查 {sales_chart} 中的图表
2. 与 {quarterly_report} 中的数据进行交叉验证
3. 总结主要发现
""",
input_files={
"sales_chart": ImageFile(source="chart.png"),
"quarterly_report": PDFFile(source="report.pdf"),
}
)需要注意的是,图像和 PDF 的端到端验证已经较为成熟,但音频、视频和文档目前可能通过图像通道路由,在严格模式下可能被某些提供商拒绝。原生按类型的映射仍是一个已知差距,而非完全发布的功能。
每次 crew.kickoff() 调用都会生成一个唯一的追踪 ID,将智能体思想、工具调用、LLM 提示词、Token 使用和成本关联在一起。追踪记录包括:
CrewAI AMP 提供不可变的审计日志,记录谁在何时运行了什么、使用了哪些输入和输出。这对于受监管行业和内部安全审查越来越重要。追踪数据支持导出功能,可用于进一步分析和合规存档。
Flows 支持检查点机制,保存执行状态使中断的工作可以从中断点恢复,而非从头开始。这对于长时间运行的生产工作流尤为关键,确保即使发生系统故障,已完成的工作也不会丢失。
每个任务可以配置护栏验证规则,在输出被接受前检查结构、长度、必填字段和业务规则。验证失败时,系统会要求智能体重试,确保输出符合预定义的质量标准。这种机制使执行结果更加可预测和可复现。
verbose=True 模式下打印完整的执行日志,便于问题定位和复现三智能体团队(研究员 → 分析师 → 写手)协作完成信息收集、数据分析和报告撰写。例如,每周自动生成竞争对手动态简报:研究员智能体使用搜索工具获取最新新闻,分析师智能体识别模式和威胁评分,写手智能体生成 200 字的高管摘要。整个流程约 90 秒完成,单次运行成本约 0.15-0.40 美元。
四智能体团队处理传入的合同、RFP 或合规文档:文档提取器使用 FileReadTool 摄取 PDF 或 DOCX 文件并提取结构化数据,风险审查员识别非标准条款和监管冲突,摘要员生成结构化的一页摘要,QA 验证员在输出前交叉核对摘要与提取数据的准确性。这类工作流可将后台处理时间减少超过 60%。
CrewAI 在销售团队中用于线索丰富化、账户评分、个性化外联邮件生成。智能体从多个内部系统提取、整合和评估线索数据,自动补充公司规模、基础设施和收入估算等信息。DocuSign 通过 CrewAI 将首次联系线索的时间缩短了 75%。
多智能体系统处理客户咨询:一个智能体负责意图分类,另一个检索知识库,第三个起草回复,协调智能体编排整个对话。敏感案例可升级至人工处理。Piracanjuba 通过用 CrewAI 替代遗留 RPA 工具,将客户支持工单响应准确率提升至 95%。
CrewAI 可用于代码审查、现代化改造和测试生成:代码分析师智能体扫描代码库,安全审查员检查漏洞,重构智能体提出修复建议。PwC 利用 CrewAI 将代码生成准确率从 10% 提升至 70%,大幅缩短周转时间。
从研究、大纲、起草、优化到审核的完整内容生产管道。每个环节由专门的智能体负责,支持博客、LinkedIn、邮件等多渠道内容生成。General Assembly 通过 CrewAI 将课程设计开发时间减少了 90%。
合规运营团队使用 CrewAI 收集证据、比较政策、标记异常并请求人工批准。金融服务机构使用它进行欺诈检测、风险评估、监管合规监控和自动化财务分析,平台的安全特性和审计能力满足严格的监管要求。