CrewAI

「用角色分工和业务流程来组织多 agent 协作」 —— 官方自述：

模型与开放条件

官方给了明确的默认与本地路径，是本站编排框架里对模型接入说得最具体的。 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 开箱即用（官方把它定位为「随系统成长再加」的进阶项）。

本页由 ai-coding-agent-atlas 数据层生成（CC BY 4.0）。 方法论与坐标系定义见仓库内 METHODOLOGY.md。