9.6.5 CrewAI

本节定位

如果说有些框架更像“状态流引擎”，那 CrewAI 的第一感觉通常是：

像在搭一个有分工的小团队。

它特别强调：

• 角色
• 目标
• 任务
• 协作顺序

所以它很适合那些天然就像“多人协作”的任务。

学习目标

• 理解 CrewAI 最核心的抽象对象
• 理解为什么它特别适合团队式多 Agent 场景
• 看懂一个最小 crew 工作流
• 理解它的优势与局限分别在哪

---

CrewAI 最本质的抽象是什么？

不是先画状态图，而是先定义角色

CrewAI 的思维入口很像现实团队管理：

• 谁负责调研
• 谁负责写作
• 谁负责审查

也就是说，它不是先问：

• 节点怎么连

而是先问：

• 这支团队由谁组成

一个很直观的类比

CrewAI 更像：

“先组建团队，再把任务派下去”。

这和 LangGraph 那种“先定义状态和边”的思路非常不一样。

---

三个最重要的概念

智能体（Agent）

一个成员。 它通常有：

• 角色
• 目标
• 能力倾向

任务（Task）

一项具体工作。 它通常有：

• 任务内容
• 负责人
• 输出预期

团队（Crew）

一个围绕共同目标协作的小团队。

一句话先记：

Agent 是人，Task 是活，Crew 是团队。

---

一个最小 crew 示例

crew = [
    {"role": "researcher", "goal": "检索退款政策"},
    {"role": "writer", "goal": "整理成总结"},
    {"role": "reviewer", "goal": "检查是否遗漏条件"}
]

tasks = [
    {"owner": "researcher", "task": "查找退款政策"},
    {"owner": "writer", "task": "撰写总结"},
    {"owner": "reviewer", "task": "检查总结"}
]

print(crew)
print(tasks)

预期输出：

[{'role': 'researcher', 'goal': '检索退款政策'}, {'role': 'writer', 'goal': '整理成总结'}, {'role': 'reviewer', 'goal': '检查是否遗漏条件'}]
[{'owner': 'researcher', 'task': '查找退款政策'}, {'owner': 'writer', 'task': '撰写总结'}, {'owner': 'reviewer', 'task': '检查总结'}]

这个例子真正表达了什么？

它表达的是：

多 Agent 系统可以先按“角色和任务”来组织，而不一定先按底层状态流组织。

这正是 CrewAI 最容易让人上手的原因。

---

为什么这种抽象特别适合内容型协作任务？

很多任务天然就长得像一个小团队在干活：

• 先收集材料
• 再写草稿
• 再做审查

例如：

• 研究报告
• 政策总结
• 内容生产
• 代码文档

CrewAI 的抽象和这类任务非常贴合，所以它常常会让人感觉：

“这比底层图工作流更像真实协作过程。”

---

一个更完整的小型 Crew 工作流

def researcher_agent(topic):
    return f"资料：{topic} 的关键条件包括 7 天内和学习进度限制。"

def writer_agent(material):
    return f"总结稿：{material}"

def reviewer_agent(draft):
    if "学习进度限制" in draft:
        return {"approved": True, "comment": "关键信息较完整"}
    return {"approved": False, "comment": "缺少学习进度信息"}

topic = "退款政策"
material = researcher_agent(topic)
draft = writer_agent(material)
review = reviewer_agent(draft)

print("material:", material)
print("draft   :", draft)
print("review  :", review)

预期输出：

material: 资料：退款政策 的关键条件包括 7 天内和学习进度限制。
draft   : 总结稿：资料：退款政策 的关键条件包括 7 天内和学习进度限制。
review  : {'approved': True, 'comment': '关键信息较完整'}

这个例子说明：

• 角色分工清楚
• 输入输出清晰
• 协作链也很自然

---

CrewAI 的优势在哪里？

易理解

比起复杂状态图，“团队角色”更贴近很多人的直觉。

易展示

做演示、讲架构、讲协作时，非常好解释。

适合角色分工明确的任务

尤其适合：

• 调研
• 写作
• 审核
• 汇总

这种“谁做什么”特别清楚的场景。

---

CrewAI 的局限也要看清

它不自动替你解决复杂状态流

如果你的系统有：

• 分支很多
• 回路很多
• 中间状态复杂

那单纯靠“角色抽象”可能不够。

角色抽象有时会掩盖底层工程复杂度

看起来像：

• researcher
• 撰写者
• 审核者

很清楚，但真正上线时你仍然要处理：

• 超时
• 重试
• 日志
• 追踪
• 权限

所以它更像一种“表达方式”和“组织方式”，而不是万能解法。

---

什么时候更适合选 CrewAI？

如果你的任务非常像：

• 团队协作
• 角色分工
• 内容生产链

那 CrewAI 往往很自然。

例如：

• “一人找资料，一人写，一人审”

这种任务你用 CrewAI 思维通常会很顺。

但如果任务更像：

• 复杂状态图
• 精细控制回路

那图式框架可能会更稳。

---

初学者最常踩的坑

角色很多，但职责不清

看起来像一支团队，实际只是很多模糊角色堆在一起。

以为角色抽象就等于系统就稳了

角色只是组织形式，不会替你自动补齐工程能力。

为了“像团队”而强行上多 Agent

如果任务本身不需要分工，多 Agent 反而是负担。

---

留下的证据

学完这一页，至少保留这张证据卡：

问题形态

工作流图、检索应用、角色团队或实验

框架选择

它增加了什么抽象，以及隐藏了什么控制

追踪记录

状态、节点、tool 调用、消息或运行 id

失败检查

框架魔法隐藏状态、重试或权限问题

决策

只有在单代理循环清晰后才选择框架

小结

这一节最重要的不是学会某个框架的类名，而是理解：

CrewAI 的核心价值，在于它把多 Agent 问题优先表达成“角色 + 任务 + 团队”的协作结构。

这在角色清晰的内容型任务里特别有吸引力，但也不是所有系统的最佳抽象。

---

练习

1. 用你自己的一个任务，设计一个 3 角色 crew。
2. 想一想：为什么“角色数量变多”不代表系统质量就会更高？
3. 用自己的话解释：CrewAI 和 LangGraph 的抽象入口有什么不同？
4. 如果你的任务里有很多回路和条件分支，你还会优先选 CrewAI 吗？为什么？

解题思路与讲解

1. 一个有用的三角色 crew 可以是 researcher、writer、reviewer。每个角色都应该有窄职责、清晰产物，以及交给下一个角色的交接点。
2. 角色越多不一定越好。职责重叠、消息噪声变大、没人负责最终判断时，质量反而会下降。只有当新角色能消除真实瓶颈时才添加。
3. CrewAI 的入口是角色协作：谁做事、任务如何在角色之间流动。LangGraph 的入口是显式状态和转移：哪个节点下一步运行、在什么条件下运行。
4. 如果任务有很多循环和条件分支，不一定优先选 CrewAI。graph 或 workflow 取向通常更容易检查控制流、重试上限和失败处理。