第 1 章 · 多智能体与 CrewAI 概述
本章目标:理解"为什么一个 Agent 不够用",掌握 CrewAI 的五大核心概念(Agent / Task / Crew / Process / Flow)以及 Crews 与 Flows 的选型框架,为后续动手编码建立全局地图。
1.1 为什么需要"多"智能体
单个 LLM 调用擅长回答问题,但真实业务往往是一条流水线:调研 → 分析 → 撰写 → 审校。让一个模型在一次对话里全包,会遇到三个经典问题:
- 上下文污染:角色混乱。模型一边当研究员一边当审稿人,提示词互相打架,输出质量下降;
- 工具过载:把搜索、抓取、数据库、文件读写全部塞给一个 agent,工具选择错误率显著上升;
- 不可控的执行路径:单 agent 的步骤顺序由模型自由发挥,流程无法审计、无法复现。
多智能体(Multi-Agent)的思路是把流水线拆成多个职责单一的 agent,每个 agent 有自己的角色设定、工具集和任务,由框架负责编排它们的协作。这就像公司里不会让同一个人既写代码又做财务审计——专业化分工 + 明确接口,是工程化 LLM 应用的基础。
与"链式调用"的区别
你可以手写 llm1(prompt) → llm2(llm1_out) 的函数链,但 CrewAI 在此之上提供了:角色记忆、任务间上下文传递、委派协作、重试与限流、token 计量、可回放(replay)等运行时能力。这些正是框架的价值所在。
1.2 CrewAI 核心概念地图
CrewAI 的世界由五个核心组件构成,先记住这张关系图:
┌─────────────────────────────────────────────────┐
│ Flow(事件驱动的精确编排层,可选) │
│ └── 编排一个或多个 Crew / 函数 │
│ ┌─────────────────────────────────────┐ │
│ │ Crew(团队:一次完整的执行单元) │ │
│ │ ├── Process(协作模式: │ │
│ │ │ sequential / hierarchical) │ │
│ │ ├── Agent × N(角色化成员) │ │
│ │ └── Task × N(任务清单,绑定 agent) │ │
│ └─────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘| 组件 | 角色 | 一句话理解 |
|---|---|---|
| Agent | 自主的工作成员 | 有 role/goal/backstory 的"员工",可带工具 |
| Task | 具体工作项 | 有 description 和 expected_output 的"工单",绑定某个 agent |
| Crew | 团队 | agents + tasks + process 组成的一次完整执行 |
| Process | 协作模式 | 任务如何流转:顺序执行 or 分层委派 |
| Flow | 精确编排层 | 用事件(@start/@listen)串联多个 crew 和普通函数 |
数据流向:Task 的输出默认自动传给下一个 Task 作为上下文;也可以用 context=[...] 显式声明依赖。整个 Crew 跑完后返回一个 CrewOutput 对象。
把这张地图翻译成代码骨架,五个组件各就各位(先混个眼熟,后续章节逐一展开):
from crewai import Agent, Task, Crew, Process, LLM
llm = LLM(model="openai/deepseek-chat",
base_url="https://api.deepseek.com/v1",
api_key="sk-xxx")
agent = Agent(role="研究员", goal="整理要点", backstory="十年研究经验", llm=llm)
task = Task(description="调研某主题", expected_output="5 条要点", agent=agent)
crew = Crew(agents=[agent], tasks=[task], process=Process.sequential)
# Flow 的写法在第 15 章出现,它用 @start / @listen 装饰器编排多个 crew1.3 Crews vs Flows:官方选型框架
这是初学者最容易纠结的问题。CrewAI 官方给出的判断标准很清晰:
选 Crews,当你需要"协作智能":
- 多个不同专长的 agent 需要互相配合;
- 解决方案无法预先写成确定性的步骤(需要 agent 自己决策下一步);
- 典型场景:深度研究、创意内容生产、头脑风暴。
选 Flows,当你需要"精确控制":
- 工作流要求严格的执行顺序和状态管理;
- 需要确定性的事件编排、条件路由、断点恢复;
- 典型场景:ETL 流水线、审批流、多阶段批处理。
两者组合是常态:用 Flow 做总控和状态管理,在关键环节调用 Crew 处理需要创造性的子任务。例如内容工厂:Flow 负责"选题 → 生产 → 发布"三阶段的状态推进,"生产"阶段内部是一个 researcher + writer + editor 的 Crew。
本课程第 15–16 章会系统讲 Flow;前 14 章聚焦 Crews。
1.4 不用框架 vs 用框架:同一个需求两种写法
需求:先让模型列要点,再让模型把要点写成短文。手写链式调用版本:
# 裸写函数链:能用,但一切都要自己管
import os
from openai import OpenAI
client = OpenAI(api_key=os.getenv("DEEPSEEK_API_KEY"),
base_url="https://api.deepseek.com/v1")
def chat(prompt):
resp = client.chat.completions.create(
model="deepseek-chat",
messages=[{"role": "user", "content": prompt}],
)
return resp.choices[0].message.content
points = chat("围绕 AI Agent 列出 5 条核心要点")
article = chat(f"把以下要点扩写成 300 字短文:\n{points}")这段代码能跑,但重试、限流、token 计量、任务回放、角色记忆、多 agent 委派……全都要自己造轮子。同样的需求用 CrewAI 表达(完整可运行版本见第 2 章):
# CrewAI 版本:框架接管执行循环、上下文传递与计量
from crewai import Agent, Task, Crew
researcher = Agent(role="研究员", goal="产出 5 条要点",
backstory="行业研究专家", llm=llm)
writer = Agent(role="作者", goal="扩写成短文",
backstory="科技专栏作者", llm=llm)
crew = Crew(
agents=[researcher, writer],
tasks=[
Task(description="列出 5 条要点", expected_output="编号列表", agent=researcher),
Task(description="扩写成 300 字短文", expected_output="Markdown 文章", agent=writer),
],
)
result = crew.kickoff() # 自动完成两次调用与上下文传递1.5 典型应用场景
- 研究与情报:竞品监控周报——searcher 找资料、analyst 提炼观点、reporter 写摘要;
- 内容营销:从关键词到成稿的 SEO 文章流水线(第 23 章完整实战);
- 数据分析:自然语言转 SQL → 校验 → 解读结果的多 agent 审核链(第 24 章实战);
- 客服工单:分类 → 检索知识库 → 起草回复 → 合规审查;
- 代码工程辅助:需求分析 → 方案设计 → 代码生成 → 测试评审。
共同特征:多角色、多步骤、中间产物可检查。如果你的场景只是"一问一答",直接调 LLM API 就够了,不必上多智能体。
1.6 学习路线与环境预告
本教程基于 CrewAI 1.15.x(要求 Python >=3.10 且 <3.14)。按四个阶段展开:
| 阶段 | 章节 | 目标 |
|---|---|---|
| 入门 | 01–05 | 核心概念、第一个跑通的 Crew、三大件参数详解 |
| 进阶 | 06–12 | 三方模型接入、工具体系、分层流程、记忆与知识库 |
| 高级 | 13–19 | 规划容错、事件回调、Flow 工作流、工程化项目结构 |
| 生产实践 | 20–25 | 评估测试、MCP、可观测性、部署与综合实战 |
按课程约定,全书所有示例统一使用 OpenAI 兼容的三方模型(以 DeepSeek 为例),不依赖 OpenAI 官方 API:
import os
from crewai import LLM
# 全书统一的模型接入方式:openai/ 前缀 + 自定义 base_url
llm = LLM(
model="openai/deepseek-chat", # provider/model 格式
base_url="https://api.deepseek.com/v1", # 三方 OpenAI 兼容端点
api_key=os.getenv("DEEPSEEK_API_KEY"), # 密钥永远走环境变量
temperature=0.7,
)1.7 本章小结
- 单 agent 的三大痛点:角色混乱、工具过载、路径不可控;多智能体通过专业分工解决;
- 五大组件:Agent(员工)、Task(工单)、Crew(团队)、Process(协作模式)、Flow(精确编排层);
- Crews 适合需要协作智能的开放性问题,Flows 适合需要精确控制的确定性流程,复杂应用二者组合;
- CrewAI 1.x 要求 Python >=3.10 且 ❤️.14;本书统一用
LLM(model="openai/deepseek-chat", base_url=...)接入三方模型。
🧪 随堂测验
点击你认为正确的选项。答错时会展示正确答案与原因解析。
1. 在 CrewAI 中,负责"定义任务如何流转(顺序或分层)"的组件是?
2. 按照官方选型框架,下列哪个场景最适合用 Flow 而不是 Crew?
3. 关于本书统一的三方模型接入写法,正确的是?
4. CrewAI 1.x 对 Python 版本的要求是?
🛠️ 动手实践
- 用一段话描述你工作中一个可以被拆成 3 个角色的自动化流程,标出每个 agent 的 role/goal/backstory 草稿。
- 画出 1.2 节关系图的变体:假设你要做一个"每日新闻简报"系统,标注哪些部分用 Crew、哪些部分用 Flow 编排。
- 检查本机 Python 版本(
python3 --version),确认是否满足 CrewAI 安装要求;不满足则记录你准备采用的版本管理方案(如 uv / pyenv)。
概念地图建好了,下一章我们装好环境并跑通第一个 Crew。