CrewAI 与 adk-python、embabel 怎么选

让多个 AI 智能体分工干一件复杂任务，麻烦的地方是角色怎么分、步骤怎么串、失败了怎么重试。CrewAI 把这些拆成两层原语：Crews 管角色制协作，Flows 管事件驱动的流程控制，两者可以互相嵌套使用。

CrewAI 是一套用 Python 写的多智能体编排框架，输入角色、任务与流程定义，输出由多个 AI 智能体协作完成的工作流结果。

具体写起来，一个 Crew 里的 agent 要填 role、goal、backstory，task 描述要做什么、依赖哪个前序任务、输出走 output_pydantic 还是 output_json，跑完之后结果能落到你指定的输出结构里。README 的示例覆盖写职位描述、做旅行规划、股票分析，以及把 Crews 和 Flows 拼在一起用。

这几个项目分别在解决什么

CrewAI 仓库创建于 2023 年 10 月 27 日，MIT 协议，Python 占 99.4%，目前 59232 star、8616 fork、399 watcher，开放 issue 513 个。它把「多智能体怎么协作」和「流程怎么被精确控制」拆成两套 API：Crews 让 agent 之间自治分工，Flows 提供事件驱动的编排，流程里能嵌单次 LLM 调用，也能把整个 Crew 当一个节点用。README 提到社区课程已认证超过 10 万名开发者。

围绕这两套 API，仓库里能直接看到的能力包括：

• 角色制智能体：agent 的 role、goal、backstory、tools、LLMs、memory、guardrails 都写在配置层，官方技能包会教编码 agent 怎么把这套配置生成出来。
• 结构化输出：task 可以指定 output_pydantic 或 output_json，把结果收敛成固定格式。
• 失败重试：max_retry_limit 控制任务重试次数，配合异常处理划定重试边界。
• 工具体系：内置 WebSearchTool、SerperDevTool、CodeInterpreterTool 等，也支持自定义工具；MCP Server 上的工具与资源可以被 agent 发现并调用。
• 多模型接入：支持 Google Gemini API，1.15.23 加入原生 Gemini 3.8 Flash；1.15.22 引入 llm_overlay 上下文变量，把不同 agent 路由到不同模型。
• 记忆与追踪：memory=True 打开记忆存储；AMP 平台记录每次运行，crewai eval 会留下最近一次被追踪的运行记录。
• 编码 agent 集成：Claude Code 里用下面三条命令装官方技能，其它编辑器走 npx 那条。

/plugin marketplace add crewAIInc/skills
/plugin install crewai-skills@crewai-plugins
/reload-plugins

npx skills add crewaiinc/skills

获取方式上，项目以 crewai 这个名字发布在 PyPI，仓库用 uv 管理依赖，uv.lock 有 1.7 MB 左右，包定义在 pyproject.toml 里。README 目录中列有 Installation、Setting Up Your Crew、Running Your Crew 三节，本次拿到的节选只到 Learning Resources，没有展开这三节的具体命令，所以这里不抄未经核实的安装步骤。README 提到的 CrewAI AMP Suite 是商业控制面，提供托管部署、可观测、治理和企业支持，开源仓库本身不含这部分。

google/adk-python 是另一个 Python 方向的同类项目，21688 star，官方描述把自己定位成 code-first 的工具集，覆盖 agent 的构建、评估与部署三个阶段。它在素材里的信息只有这些，具体 API 形态和上手难度没有给出。

embabel/embabel-agent 把落点放在 JVM 上，4480 star，名字读作 Em-BAY-bel。团队本来就在 Java 或 Kotlin 技术栈里，不希望为跑 agent 再引一套 Python 服务时，它才进入比较范围。素材同样没有给出它的配置方式与部署细节。

逐项对照

差距出现在哪

三个项目真正拉开距离的地方，在抽象层次怎么切。CrewAI 明确给了两层：Crews 让 agent 自己分工，Flows 让开发者用事件驱动的方式卡住关键步骤，两种需求不用换框架。adk-python 和 embabel 的描述里没有出现这种双层拆分，素材也没给出它们的流程控制方式，所以这一点只能停在 crewAI 自己的定位上。

第二处差距出在工程可靠性。crewAI 的开放 issue 有 513 个，其中评论数最高的一批集中在工具调用的授权与重试上：Tool re-execution on task retry has no idempotency guard 这条有 172 条评论，状态是待解决，讲的是任务重试时工具有可能被重复执行，重复付款、重复发邮件、重复下单都可能发生；Governance middleware hook for tool call authorization 有 143 条评论，同样是待解决；Runtime release-control mediation layer before agent/tool execution 有 119 条评论，也没关。这三条指向同一块缺口：agent 调工具之前缺少一道授权与放行机制。相比之下，367 条评论的 GuardrailProvider 接口已经解决，说明这条线在推进，只是还没补齐。

同类项目在这一点上是否更好，素材没有给出可以对照的信息，不能替它们下结论。能确定的是 crewAI 自身在治理层还不成体系。

风险点也出现在工具调用本身。早期有用户反馈 agent 并不真正调用工具，只模拟一遍并编造输出（已解决，66 条评论）；CodeInterpreterTool 不执行代码、只让 agent 空回答（已解决，40 条评论）；用 llama2、openhermes、starling、Mistral 这些本地模型时会撞上 Invalid Format: Missing 'Action:' after 'Thought'（已解决，40 条评论，作者反馈只有某个模型没触发）。SerperDevTool._run() missing 1 required positional argument: 'search_query'（已解决，64 条评论）和 Invalid response from LLM call - None or empty（已解决，59 条评论）也属于同类问题——工具契约和模型输出格式对不齐时，报错信息通常不会直接指向真正的原因。

评估与部署这一环，crewAI 起步偏晚。1.15.23 才加入通过 AMP 评估最近一次被追踪运行的能力，而 adk-python 的官方定位里构建、评估、部署是一开始就并列的三个阶段。模型厂商偏好 Google 技术栈、又需要开箱即用的评估部署工具链的团队，adk-python 在这个维度上更直接。

embabel 的落点 crewAI 完全没有覆盖。Java 或 Kotlin 团队要跑同样的多 agent 编排，用 crewAI 意味着额外维护一套 Python 服务、一套依赖和一条跨语言调用链，这部分成本在两边对照时是实打实的。

什么情况下选它

团队主力语言是 Python，任务又确实需要多个 agent 按角色分工，Crews 的抽象对得上，配置字段写清 role、goal、backstory、tools 就能跑起来。

流程里有明确的先后与分支，需要事件驱动的精确控制，同时又想在某几步保留 agent 的自治空间，Flows 可以嵌单次 LLM 调用，也能把 Crew 当节点，不用换框架。

手上已经有一批模型和工具要接，希望用 llm_overlay 把不同 agent 路由到不同模型，或者通过 MCP 复用现成工具，这时 crewAI 的接入面比较宽。

反过来，三种情况不该选它。团队主栈是 Java 或 Kotlin、不愿意多引一套 Python 服务的，去看 embabel/embabel-agent。需要现成的工具调用授权、审批与重试幂等保证的，crewAI 这几项目前还是开放 feature 请求，得自己在应用层补。任务只是单次 LLM 调用或者一两条固定步骤，多 agent 分工解决不了你真正的问题，这一层框架只会增加调试面。

crewAI 内置了搜索与抓取类工具，WebSearchTool、SerperDevTool 以及 Oxylabs 集成都会实际发起网络请求。这类能力只能用在自有资产或已获得明确授权的目标上，未经授权去抓取、探测第三方站点，可能触及平台服务条款，也可能带来法律风险。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.9 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。