CubePi vs CrewAI
CrewAI 围绕角色扮演的隐喻组织 Agent 系统 —— 团队（crew）、带有角色和背景故事的 Agent，以及分配给 Agent 的任务。CubePi 从不同的前提出发：Agent 是一个普通的异步 while 循环，调用模型、执行工具、循环往复。
如果角色抽象并不能解决你的问题，CubePi 直接省去这一层。以下是两者的详细对比。
并排对比
| CrewAI | CubePi | |
|---|---|---|
| 抽象层 | 具有角色、目标和背景故事的角色扮演 Agent 团队 | 普通的异步 while 循环 —— 五分钟内可从头读完 |
| 多 Agent | 一等公民：层次化或顺序化进程类型 | Subagent 中间件 —— 派生子 Agent，等待结果，自由组合 |
| 异步支持 | 默认同步；异步支持后来追加 | 异步优先 —— 每个入口都是 async |
| 流式输出 | 流式支持有限 | async for event in stream —— 统一模式，11 种事件类型 |
| Checkpointing | 无内置持久化层 | 追加式 —— O(1) DB I/O；后端：memory、SQLite、Postgres、MySQL |
| 依赖 | langchain-core + 大量传递依赖 | 3 个核心依赖：pydantic、anthropic、openai |
| 工具 | 需要编写 schema 样板代码的工具类 | 用 @tool 装饰任意 async 函数 —— schema 自动推导 |
| 可观测性 | 基础日志；无原生 OTel | 原生 OpenTelemetry —— GenAI 语义约定，OTLP / JSONL 导出器 |
| 测试 | 大多数测试需要真实 API 调用 | FauxProvider —— 确定性流式仿真，无需 API Key |
角色、目标、背景故事 —— 还是直接写 system prompt
CrewAI 的"角色"、"目标"和"背景故事"字段本质上是一种结构化写 system prompt 的方式。当你只有一个 Agent 做一件事时，角色隐喻增加的是仪式感而非能力。在 CubePi 中，`system_prompt` 就是你完全掌控的一个字符串 —— 没有框架词汇要学，没有结构要维护。
对于真正的多 Agent 场景，CubePi 提供 `SubagentsMiddleware`，可以派生子 Agent 并将其结果回传给父 Agent —— 无需 crew/process/task 对象模型。
开箱即用的持久化，无需自己接线
CrewAI 没有内置的 checkpointing 层。如果你希望对话在重启后依然存在，需要自己添加数据库逻辑。CubePi 的追加式 checkpointing 开箱即用 —— `SQLiteCheckpointer`、`PostgresCheckpointer` 和 `MySQLCheckpointer` 每轮只写入新消息，无论对话多长，写入成本保持 O(1)。
CrewAI 更适合的场景
如果你的工作流自然地映射到 crew 的隐喻 —— 一组专家 Agent 各自负责流水线中的一个离散任务 —— CrewAI 是合理的选择。如果你在构建单一的对话 Agent、有状态的助手，或任何需要生产级持久化或 OTel 可观测性的系统，CubePi 是更精简的路径。