CrewAI
「用角色分工和业务流程来组织多 agent 协作」 —— 官方自述: > Framework for orchestrating role-playing, autonomous AI agents. 「role-playing」这个词容易让人低估它—— 同一份 README 里也写着 production-grade,并明确承诺 "Move from experiment to production without changing frameworks"。
适合与不适合
适合:任务能被表述成「一支有角色分工的团队」;需要业务逻辑留在普通 Python 里 并显式控制执行路径;想在本地模型上跑;需要 MCP 与 A2A。 不适合:需要官方明确的沙箱或文件/网络权限边界;需要把工作记忆与长期记忆分开管理; 需要 checkpointing 开箱即用。
固定坐标系
8 个维度,与同赛道其他对象逐项可比。
- 模型与开放条件
- 官方给了明确的默认与本地路径,是本站编排框架里对模型接入说得最具体的。 README「Connecting Your Crew to a Model」原文: "CrewAI supports using various LLMs through a variety of connection options. By default your agents will use the OpenAI API when querying the model. However, there are several other ways to allow your agents to connect to models. For example, you can configure your agents to use a local model via the Ollama tool." README FAQ 补充:LM Studio 也能接("Tools like Ollama and LM Studio allow seamless integration")。 这一条对本站读者特别有价值:本地量化模型在这三个编排框架里, 只有 CrewAI 在 README 首屏级别点名了具体工具。 ⚠ 未核验:完整 provider 清单(官方文档
learn/llm-connections本次未取到正文)、 换 provider 后工具调用与 structured output 的可靠性。 - 运行位置
- 纯库,官方口径是「从原型到生产不用换框架」。 安装是 pip 包(README Getting Started 走 pip install + crewai CLI), 无托管服务。README「When to Use CrewAI」里的一句值得引用作为定位依据: "Move from experiment to production without changing frameworks." 它对状态持久化是「随系统成长再加」的定位(README 两处原文): "Add tools, memory, checkpointing, and async execution as your system grows"、 "Add deterministic steps, human input, structured outputs, and checkpointing as your system grows"。 ⚠ 未核验:checkpointing 的落盘粒度与后端(对比 LangGraph 的 "save graph state at every superstep" 有明确说明,本条 README 未给)。
- 本地文件
- ⚠ 不在它职责范围内。 README 里文件系统不是一项能力,没有给默认的文件访问边界或沙箱机制。 ⚠ 未核验:容器部署时的默认权限(README 未涉及部署形态)、 本地运行时 agent 对文件系统的访问范围。
- 关机后的任务
- Flow 的 state management 是官方明文,checkpointing 的定位是「按需添加」。 README 里 Flow 的描述包含 "event-driven workflows with state, branching, routing", FAQ 进一步说 Flow 适合 "detailed execution paths and secure state management"。 示例代码(README「Using Crews and Flows Together」段)显示状态是结构化 Pydantic 模型:
class MarketState(BaseModel),Flow[MarketState] 里直接读写self.state.sentiment等字段, 并按self.state.confidence的数值阈值分支。 这就是本站要找的「状态」 —— 显式、结构化、可分支判断。 ⚠ 但落盘与跨进程恢复本站未核验:README 说 checkpointing 是 "as your system grows" 才加的进阶项,没说默认有没有。 - 工具与扩展
- 官方明确列了 MCP 与 A2A 两项,这是它的一个强项。 README Key Features 原文:"Use tools, memory, knowledge, checkpointing, async execution, and MCP/A2A support for more capable production agents." 另外 README 里CrewAI 自己托管了一个文档 MCP server(
docs.crewai.com/mcp), 可供 AI 编程助手查询它的 API 细节(README「Build with AI」段提到的ask-docs)。 ⚠ 未核验:MCP 是核心依赖还是可选 extra(README 未说明; 对比 OpenAI Agents SDK 把mcp>=1.19.0放在dependencies里)。 A2A(Agent-to-Agent) 是本站首次出现的协议名,其规范与实践本站未研究。 - 上下文与记忆
- ⚠ memory 与 knowledge 出现了,但压缩/摘要策略未核验。 README 出现的与记忆相关的表述有两处,均无机制细节: Key Features 里的 "memory, knowledge, checkpointing"、 以及「Build with AI」段展示的 agent 配置项清单 "Configuring agents — role, goal, backstory, tools, LLMs, memory, guardrails"。 官方没有区分「工作记忆」与「长期记忆」(这一点与 LangGraph 明确区分 working memory / persistent memory across sessions 形成对照)。 ⚠ 未核验:memory 的作用域(单 agent / 单 crew / 全局)、 存储后端、裁剪或摘要策略、知识(knowledge)与记忆的关系。
- 权限与限制
- ⚠ 本维度是本站最明显的缺口:只有 guardrails 一项,且机制未核验。 README 出现 guardrails 的唯一位置是 agent 配置项清单 ("role, goal, backstory, tools, LLMs, memory, guardrails"), 没有任何机制说明 —— 是输出校验、是权限边界、还是人工确认,均未说明。 对照本站其它对象:OpenAI Agents SDK 的 guardrails 明确分 input/output 双向校验 + human-in-the-loop;Google ADK 的 Tool Confirmation 明确是「执行前确认」; LangGraph 的 interrupts 明确是「改状态」。CrewAI 这一项三样都不是。 ⚠ 未核验:guardrails 的类型与强度、沙箱机制、文件与网络访问控制。
- 适合什么任务
- 适合:任务能被表述成「一支有角色分工的团队」(Crews); 需要业务逻辑留在普通 Python 里并显式控制执行路径(Flows); 想在本地模型上跑(官方点名 Ollama / LM Studio); 需要 MCP 与 A2A 接入;Python 栈。 不适合:需要官方明确的沙箱或文件/网络权限边界(本站未核验其机制); 需要把「工作记忆」与「跨会话长期记忆」分开管理(LangGraph 有明确表述); 需要 checkpointing 开箱即用(官方把它定位为「随系统成长再加」的进阶项)。
头号误解
- 以为是「角色扮演玩具」—— 官方定位是 production-grade,README 明写 Move from experiment to production without changing frameworks
- 把 Crew Control Plane 的能力当成开源版自带 —— tracing / 集中管控 / 企业安全 / 24×7 支持 /本地与云部署都是 CrewAI AMP 的卖点
- 以为 memory 和 knowledge 是两套持久化 —— README 只并列了名词,没有任何机制说明
- 把 guardrails 当权限护栏 —— README 只在配置项清单里列了这个名字,机制未说明
- 以为 checkpointing 默认就有 —— 官方两处都写成 as your system grows,是进阶项
- 以为开了 Flow 就有状态持久化 —— Flow 给的是 state management,落盘与跨进程恢复未核验
价格
| 月度入口 | OSS 框架免费(MIT,自托管不限次数);AMP 托管平台 Basic $0 / Enterprise 定制 |
|---|---|
| 月度数值 | $0 |
| 额度说明 | 开源部分与商业部分要分清。 核验依据:仓库 MIT(经license API)、README 的 pip 安装路径、官方定价页(核验 2026-10-01)。 商业线是 README 单列一节的 Crew Control Plane(对外称 CrewAI AMP)。 ⚠ 官方定价页当前只列两档,且这一条本身就是个坑: Basic $0(Visual editor + AI copilot、GitHub 集成、 每月 50 次 workflow executions,且上限就是 50 次, 官方对比表里 Basic 的「Additional executions」一栏写的是「—」, 即没有自助加购通道)与Enterprise 定制(SSO / RBAC / workload identity / PII redaction / policies;部署可选 CrewAI 云、你的自有 VPC、或你自己的基础设施; 45 天 onboarding;forward deployed engineering 与培训按需另购)。 Enterprise 的执行次数是 "Sized to workflow" + Flexible overage,即按实际用量谈。 ⚠ 第三方定价站上的数字与官方页不一致,本站不采信:抓取时多个来源分别给出 Professional ~$25/mo、Basic $99/mo、Standard $6K/yr、Ultra $120K/yr 等, 官方定价页上不存在这些档位(只有 Basic 与 Enterprise 两档), 应属旧制或臆测。本站只写官方页面上能读到的两档。 另一条要读出来的事实:Enterprise 明确写部署可落在 CrewAI 云 / 客户自有 VPC / 客户自有基础设施 —— 即 README 说的 "On-premise and Cloud Deployment Options" 在商业侧确实兑现, 也没有强制必须联网授权的表述。 |
不同币种不做折算。优惠、地区、税费与登录后报价可能变化,购买前请到官方页面确认。
未知项清单
- guardrails 的类型、强度与拦截范围
- 沙箱机制、文件与网络访问控制的默认值
- memory 的作用域、存储后端、裁剪与摘要策略
- knowledge 与 memory 的关系
- checkpointing 的落盘粒度、后端与跨进程恢复语义
- 完整 provider 清单与换provider 的能力对齐度
- MCP 是核心依赖还是可选 extra
- A2A(Agent-to-Agent)规范与生态现状
- AMP Enterprise 的具体报价(官方仅标 Custom)
- Basic 档50 次/月上限之后,除Enterprise 洽谈外是否有自助加购路径(官方对比表该栏为「—」)
- MCP/A2A 接入的实际使用门槛
证据来源
判断可回到以下一手源复核。本站核验日 2026-10-01,内容更新日 2026-10-01。
| 类型 | 名称 | 链接 |
|---|---|---|
| repo | crewAIInc/crewAI · 仓库(59,246★,MIT,核验 2026-10-01) | https://github.com/crewAIInc/crewAI |
| docs | 主 README(Crews/Flows 双抽象、七项 Key Features、Crew Control Plane 商业段、模型接入、FAQ) | https://github.com/crewAIInc/crewAI/blob/main/README.md |
| docs | 官方文档 · Connect CrewAI to LLMs(README 指向,完整 provider 清单) | https://docs.crewai.com/en/learn/llm-connections |
| docs | CrewAI AMP(商业控制面,本次未取到页面) | https://crewai.com |
| changelog | Releases(1.15.23 @ 2026-09-28) | https://github.com/crewAIInc/crewAI/releases |
| repo | crewAI-examples · 官方示例集 | https://github.com/crewAIInc/crewAI-examples |
| docs | CrewAI 文档 MCP server(README「Build with AI」段提到) | https://docs.crewai.com/mcp |
实测记录
本站尚未完成实测。测试协议见 tasks/_protocol.md。 实测建议(按编排框架 + 角色抽象维度定制): | # | 测什么 | 为什么值得测 | |:--:|---|---| | 1 | 同一需求用 Crew 实现 vs 用 Flow 实现,代码量与可读性差多少 | 验证双抽象是否真的各有用处 | | 2 | 用 Ollama 接本地量化模型跑完一个 Crew | 官方点名支持,值得验证真实可行性 | | 3 | guardrails 到底拦什么(输出校验?工具调用?文件访问?) | 本站最大的缺口,选型前必须清 | | 4 | checkpointing 开箱状态:默认有没有、开箱在哪 | 官方写「随系统成长再加」,要确认默认行为 | | 5 | Crew 之间传递信息的开销(角色扮演的 token 成本) | 角色协作通常吃 token,要量 | | 6 | Flow 的 state 在崩溃后能否恢复 | 与 LangGraph 的 superstep 落盘对比 |
相关条目
- Google ADK编排家族对照:同为图/流程编排,ADK 用 Workflow Runtime 的节点与路由,CrewAI 用 Crew(角色协作)+ Flow(事件驱动)两套抽象。CrewAI 另给了 MCP/A2A 支持。
- LangGraph状态持久化路线的差别最大的一条:LangGraph 明确给出「每 superstep 落盘 checkpoint」,CrewAI 把 checkpointing 定位成「随系统成长再加」的进阶项,粒度与后端均未核验。
- Deep Agents同属「快速起步」一侧,但抽象不同:Deep Agents 是 batteries-included harness,CrewAI 是 Crew/Flow 双抽象的编排框架。
- OpenAI Agents SDK反面对照:那个是单 agent 原语 + 明确的 guardrail 机制;CrewAI 的权限维度目前只有 guardrails 一个未说明机制的名词。
本页由 ai-agent-guide 数据层生成(CC BY 4.0)。
方法论与坐标系定义见仓库内 METHODOLOGY.md。