对比

Swarms 与 CrewAI 对比：多智能体框架该选哪一个？

一次框架层面的对比，附可运行代码：先用 CrewAI 和 Swarms 搭同一条流水线，再看 Swarms 有而 CrewAI 没有的能力。拓扑是一个参数、15+ 种结构、一次编译的图引擎、把五十个工具压成一份 schema 的动态工具加载、内置 16 个工具的自主智能体框架、一等公民的 MCP、按智能体选择模型，以及让多智能体上下文保持正确的类型化对话轮次。

Swarms 团队2026年9月22日9 分钟阅读

两者都是用来构建智能体团队的 Python 框架。都用 pip 安装，都跑在你自己的进程里，也都能让一个两智能体的原型在今天下午跑起来。本文要回答的是之后的事：当原型变成一个需要你长期维护的系统时会发生什么。

先把该给的肯定给足。CrewAI 的 role、goal、backstory 和 expected_output 这套词汇读起来很顺，新同事不看教程也能读懂一份 crew 定义。把业务流程映射成角色和任务，确实是一个很好的入门坡道，而对于三个智能体的线性流水线，它在可读性上很难被超越。

这篇对比关心的是你会成长进去的那个框架。下面的一切都是 pip install swarms，在本地运行，不需要任何托管服务。

Shell

pip install -U swarms

同一条流水线的两种写法

一个研究智能体顺序地把工作交给一个分析智能体。

CrewAI

Python

from crewai import Agent, Task, Crew, Process

researcher = Agent(
    role="Researcher",
    goal="Gather the facts on the given market",
    backstory="A thorough analyst who cites sources.",
)

analyst = Agent(
    role="Analyst",
    goal="Turn research into a decision-ready brief",
    backstory="A skeptical reviewer who flags weak claims.",
)

research_task = Task(
    description="Research the EV battery supply chain in 2026.",
    expected_output="A factual summary with sources.",
    agent=researcher,
)

analysis_task = Task(
    description="Write a decision brief from the research.",
    expected_output="A one-page brief with a recommendation.",
    agent=analyst,
    context=[research_task],
)

crew = Crew(
    agents=[researcher, analyst],
    tasks=[research_task, analysis_task],
    process=Process.sequential,
)

print(crew.kickoff())

Swarms

Python

from swarms import Agent, SequentialWorkflow

researcher = Agent(
    agent_name="Researcher",
    system_prompt="Research thoroughly and cite sources.",
    model_name="claude-sonnet-5",
    max_loops=1,
)

analyst = Agent(
    agent_name="Analyst",
    system_prompt="Write a one-page brief. Flag weak claims.",
    model_name="gpt-4.1",
    max_loops=1,
)

workflow = SequentialWorkflow(agents=[researcher, analyst])
print(workflow.run("Assess the EV battery supply chain in 2026."))

篇幅相当，智能体在两边也是同一个概念。但已经能看到两处差别：智能体自带模型，而不是继承整个 crew 的统一配置；流水线是一个你把智能体传进去的结构，而不是靠 context 连接起来的一组任务对象。

第二点差别会越滚越大。

拓扑是一个参数，不是一次重写

在 CrewAI 里，系统的形状由任务、任务之间的 context 关联，以及 crew 的 Process 共同表达。改变形状就意味着编辑这些关系。

在 Swarms 里，智能体与运行它们的结构是分开的，因此同一套阵容只要换一个类，就能在另一种拓扑下运行：

Python

from swarms import Agent, SequentialWorkflow
from swarms.structs.concurrent_workflow import ConcurrentWorkflow

agents = [researcher, analyst, risk_reviewer]

# 一个接一个，每个都能看到上一个的输出
SequentialWorkflow(agents=agents).run(task)

# 三个同时处理同一个任务
ConcurrentWorkflow(agents=agents).run(task)

或者保留一个统一入口，用 SwarmRouter 按名称选择拓扑：

Python

from swarms.structs.swarm_router import SwarmRouter

router = SwarmRouter(
    name="research-swarm",
    agents=agents,
    swarm_type="ConcurrentWorkflow",  # 也可以是 SequentialWorkflow、MajorityVoting……
)

print(router.run("Assess the EV battery supply chain in 2026."))

这个目录里有 15 种以上的结构，而且它们不是顺序与层级的变体。MajorityVoting 让多个智能体处理同一个任务并对答案进行归并。CouncilAsAJudge 按给定标准为输出打分。MixtureOfAgents 把众多意见聚合成一份综述。DebateWithJudge 组织一场对抗式交锋，由第三个智能体裁决。HeavySwarm、GroupChat、RoundRobinSwarm、AgentRearrange、HierarchicalSwarm 和 AutoSwarmBuilder 各自编码了一种不同的协作模式。在 CrewAI 里，这些大多需要你用任务和回调亲手搭出来。

下面是一个只需四行的质量门禁，因为结构本身已经存在：

Python

from swarms.structs.majority_voting import MajorityVoting

vote = MajorityVoting(agents=[analyst_a, analyst_b, analyst_c])
print(vote.run("Is this contract clause enforceable? Answer yes or no, then justify."))

一张真正的图，只编译一次

顺序和并发能覆盖很多场景，但分支加汇聚需要一张图。GraphWorkflow 是一等结构，包含节点、边和编译步骤：

Python

from swarms.structs.graph_workflow import GraphWorkflow

workflow = GraphWorkflow(name="market-analysis")

workflow.add_node(collector)
workflow.add_node(macro_analyst)
workflow.add_node(credit_analyst)
workflow.add_node(risk_analyst)
workflow.add_node(synthesizer)

# 从一个节点扇出到三个，再汇聚回来
workflow.add_edges_from_source("collector", ["macro", "credit", "risk"])
workflow.add_edges_to_target(["macro", "credit", "risk"], "synthesizer")

workflow.compile()
print(workflow.run("Assess the EV battery supply chain in 2026."))

compile() 是值得理解的那部分。它从节点度数推断入口与出口，计算拓扑分层，一次遍历物化邻接关系，校验可达性，并固化一份逐层执行计划，其中每个节点都已预先解析。之后的重复运行只是扫过这份固化的计划，而不是重新推导顺序；任何变更都会让缓存失效，因此过期的计划不可能被执行。这个引擎有一篇公开发表的系统论文，附带开放的测试工具和原始数据，你可以在自己的硬件上重跑。

结构之间还可以组合。图里的一个节点可以是一整个工作流：

Python

triage = ConcurrentWorkflow(agents=[macro_analyst, credit_analyst, risk_analyst])

workflow.add_node(collector)
workflow.add_node(triage)        # 一整个并发工作流作为一个节点
workflow.add_node(synthesizer)

真实系统很少从头到尾都是单一模式，它们通常是一张图，而图的节点本身是小的顺序或并发工作流，这正是上面这段代码表达的东西。

动态工具加载：五十个工具，一份 schema

这是 CrewAI 没有对应物的能力，而在大型工具集上，它决定了一个智能体是能用，还是既昂贵又困惑。

工具定义是提示词的一部分。它们在每次调用时重新发送，并且位于缓存前缀中，因此大型工具集是被持续付费的。仅内置的 16 个框架工具每次请求就约 2,600 个 token，而一个 MCP 服务器还能再加四十个。选择准确率也随列表长度下降：在 80 个工具里挑选的模型，表现不如在 8 个里挑选的。

Swarms 把它们延迟加载。工具保持注册且可执行，但不出现在发送给模型的 schema 列表里，通过一个 tool_search 工具即可发现：

Python

from swarms import Agent

agent = Agent(
    agent_name="Researcher",
    model_name="gpt-4.1",
    max_loops="auto",
    tools=[...],          # 注册了五十个工具
    dynamic_tools=True,   # 只发送一份 schema，其余可搜索
)

智能体在需要时搜索目录，加载找到的工具，并在下一轮调用它。已加载的工具在本次运行的剩余时间里保持加载。控制流工具被固定住、从不延迟，因为一个需要搜索自己 complete_task 的智能体根本无法收尾。搜索未命中时会回退到关键词匹配，并返回一份有上限的目录清单而不是沉默，这样一次失败的查找就变成了一次有效的重试。

在没有这项能力的框架里，五十个工具意味着整个运行期间每一次请求都要带上五十份 schema。

一个自主执行框架，而不只是一个循环

max_loops="auto" 是一个能干活的智能体框架，内置 16 个工具，覆盖文件、shell、grep、子智能体和控制流：

Python

agent = Agent(
    agent_name="Engineer",
    system_prompt="You fix failing tests in the repository you are given.",
    model_name="claude-sonnet-5",
    max_loops="auto",
)

agent.run("The auth test suite is failing. Find the cause and fix it.")

智能体会制定计划、执行、修订计划，并在工作完成时停下来。它拿到的是结构化的执行记录和可变的计划，而不是一个被压平的字符串，因此它对进度的认知和模型对进度的认知是同一个对象。子智能体是内置工具之一，所以一个自主智能体可以为子任务派生助手，而不需要你再接一个结构。

MCP 是构造函数参数

Model Context Protocol 的支持内建在 Agent 类里，而不是外挂上去的：

Python

agent = Agent(
    agent_name="MCP-Agent",
    model_name="gpt-4.1",
    mcp_url="http://localhost:8000/mcp",
    max_loops=1,
)

也可以同时接入多个服务器，带认证、请求头和超时：

Python

agent = Agent(
    agent_name="Multi-MCP-Agent",
    model_name="gpt-4.1",
    mcp_urls=[
        "http://localhost:8000/mcp",
        "https://tools.internal.example.com/mcp",
    ],
    mcp_authorization_token="Bearer ...",
    mcp_headers={"X-Tenant-Id": "acme"},
    mcp_timeout=30,
)

对于需要 OAuth 的服务器，框架支持 OAuth 流程和令牌存储。配合动态工具加载，一个智能体可以接入多个暴露了数百个工具的 MCP 服务器，而每次请求仍然只发送一份工具 schema。

按智能体选模型，跨供应商

每个智能体都用一个普通字符串指定自己的模型，而框架与供应商无关：OpenAI、Anthropic、Google、DeepSeek、Mistral、Together、OpenRouter、AWS Bedrock、Azure OpenAI、Hugging Face，以及通过 LM Studio 或 Ollama 运行的本地模型。

Python

writer = Agent(agent_name="Writer", model_name="gpt-4.1", system_prompt="...")
critic = Agent(agent_name="Critic", model_name="claude-sonnet-5", system_prompt="...")

SequentialWorkflow(agents=[writer, critic]).run(task)

把批评者放到与写作者不同的厂商上，并不是猎奇。一个与写作者同属一个模型家族的批评者，同时也共享它的盲区和典型失效模式，因此它恰恰会在最该提出异议的地方连连点头。跨厂商审阅是"审阅"唯一真正具备对抗性的版本，而在这里它的代价只是一个字符串。

保持正确的多智能体上下文

这一点在踩到之前完全看不见。当一个结构把会话交给下一个智能体时，最朴素的实现会把整段记录压平成一个字符串，作为下一个任务传过去。这一下子付出三重代价：角色归属被摧毁，因为智能体分不清哪些是自己先前的输出、哪些是同伴的；提示词缓存永远不会命中，因为每一轮都产生一条不同的单条消息，没有任何一次请求是下一次的前缀；上下文超线性增长，因为每个智能体的记录又被折回到共享记录里。

Swarms 传递的是类型化的对话轮次。每个结构交付的都是真正的 [{role, content}] 消息列表，智能体自己的输出作为 assistant 轮次到达，每个同伴则作为带标注的 user 轮次到达。角色归属得以保留，缓存前缀能跨轮次保持，记录保持线性增长。在一个实测结构上，压平写法到第六轮时上下文已经涨到 1,157 个字符，而正确值是 116。

这一点不需要你配置。它就是框架里每个结构交接的方式，也正是那种只会在你的 token 账单上显形的正确性工作。

执行模式与可观测性

这些结构自带了你原本要自己写的运行模式：

Python

workflow = SequentialWorkflow(agents=agents)

workflow.run(task)                  # 同步
await workflow.run_async(task)      # 异步
workflow.run_stream(task)           # token 流式输出
workflow.run_batched([t1, t2, t3])  # 多个任务走同一条流水线
workflow.run_concurrent([t1, t2])   # 多个任务同时走这条链

ConcurrentWorkflow 接受 show_dashboard=True，提供每个智能体进度的实时视图，在多件事同时发生时这一点尤其重要。output_type 决定返回什么，从最终字符串到按智能体名称组织的字典都可以。自动保存在整个框架里统一为一个 WorkspaceManager，失败不阻塞主流程，写入是原子的，因此崩溃不会在磁盘上留下损坏的状态。遥测默认开启，用 SWARMS_TELEMETRY_ON=false 关闭。

而当你还不知道该配什么阵容时，AutoSwarmBuilder 会根据任务描述设计一套：

Python

from swarms.structs.swarm_router import SwarmRouter

router = SwarmRouter(name="auto", agents=[], swarm_type="AutoSwarmBuilder")
print(router.run("Produce a competitive analysis of the EV battery supply chain."))

并排对比

	CrewAI	Swarms
编排形态	顺序与层级两种流程	15+ 种结构，换类或换 `swarm_type` 即可
分支与汇聚	靠任务 context 手工接线	`GraphWorkflow`，含节点、边与 `compile()`
已编译的执行计划	每次运行重新推导	编译一次并缓存，变更时失效
投票、评审、辩论	自己搭	`MajorityVoting`、`CouncilAsAJudge`、`DebateWithJudge`、`MixtureOfAgents`
结构可组合	crew 套 crew	任意结构都能作为图中的一个节点
大型工具集	每次请求发送全部 schema	`dynamic_tools=True`，一份 schema 加 `tool_search`
自主智能体框架	未提供	`max_loops="auto"`，内置 16 个工具
MCP	外部集成	`mcp_url` / `mcp_urls`，支持认证、请求头、OAuth
按智能体选模型	通常整个 crew 一套配置	每个智能体各自的 `model_name`，任意供应商
多智能体上下文	压平的记录	带角色归属的类型化对话轮次
运行模式	kickoff	`run`、`run_async`、`run_stream`、`run_batched`、`run_concurrent`
公开的性能工作	无	系统论文加开放测试工具
托管选项	厂商平台	同样的结构在 Swarms Cloud 上以 API 提供

CrewAI 仍然合适的场景

如果你的系统就是一条由三四个智能体组成的线性流水线、形态不会再变，而你选择框架的理由是让非专业同事也能读懂，那么继续用 CrewAI 的角色词汇是合理的。上面的一切都不会让这个选择变成错误。

选择 Swarms 的理由，在下列任何一条成立时开始生效：你想在不重写的前提下改变拓扑、你需要分支与汇聚、你的工具数量超过一小把、你想让智能体跑在不同供应商上、你需要投票或对抗式评审，或者你已经开始注意到框架替你拼装的那些上下文在 token 上的开销。

如何开始

Shell

pip install -U swarms
python -c "import swarms; print(swarms.__version__)"

先迁一个 crew。把每个角色的文字提到 system_prompt 里，用角色名给智能体命名，去掉任务对象，然后把智能体传给 SequentialWorkflow，通常一个下午就够了。然后把结构换一次，改成 ConcurrentWorkflow 或 MajorityVoting，你会发现智能体本身一处都不用改。

再往后，智能体编排的三种形态讲了每种拓扑分别适用于什么场景，而 Swarms v15 Akira 是上文提到的动态工具加载、自主执行框架和类型化轮次的完整技术记录。

框架在 github.com/kyegomez/swarms 开源；如果你不想自己运行它们，同样的结构也可以在 Swarms Cloud 上通过 API 使用 🦾

分享本文

X LinkedIn Facebook Reddit Hacker News Telegram WhatsApp Email

Swarms 与 CrewAI 对比：多智能体框架该选哪一个？

同一条流水线的两种写法

拓扑是一个参数，不是一次重写

一张真正的图，只编译一次

动态工具加载：五十个工具，一份 schema

一个自主执行框架，而不只是一个循环

MCP 是构造函数参数

按智能体选模型，跨供应商

保持正确的多智能体上下文

执行模式与可观测性

并排对比

CrewAI 仍然合适的场景

如何开始

分享本文

更多文章

什么是 Swarms Cloud？多智能体系统的终极控制平面

Swarms