用 CrewAI 框架造 AI Agent

CrewAI 是入门多 agent 最快的一条路，因为它的心智模型很像人的团队：一群有角色的 agent，各领任务，协作完成目标。

四个概念

用 YAML 写角色是它的招牌做法：

researcher:
  role: 资深行业研究员
  goal: 找出 {topic} 最近三个月的关键变化
  backstory: 你读了十年行业报告，习惯先看数据再看观点

好处是角色定义和代码分开了 —— 改职责不用动 Python，diff 里一眼看得出改了什么。

但要认清 YAML 里装的是什么

那是提示词。

role、goal、backstory 写得再漂亮，模型照做与否没有任何东西拦得住。给一个 agent 写上「你严谨、绝不编造」，它照样会编造。

提示词是请求，代码才是约束。 真正的约束在两个地方：

• 工具 —— 它只能做你给它的那些动作
• 校验 —— 它的产出必须通过你写的检查

这个区分对新手特别重要，因为 YAML 那套写法看起来很像在编程，实际上更接近在写角色扮演的设定。

顺序还是层级

Process 有两种，正好对应第一篇那条判据：

• sequential（顺序） —— 任务按你写的顺序走。这是工作流。
• hierarchical（层级） —— 有个 manager agent 决定派谁去干。这才越过了线。

建议从 sequential 开始。 不是因为它简单，是因为它可复现 —— 你能比较两次运行，能定位是哪一步出的问题。

等你确实遇到「顺序不确定、要看中间结果才知道下一步派谁」的场景，再换 hierarchical。

角色该怎么划分

新手最常见的错误是按阶段硬切：调研 agent、写作 agent、审校 agent —— 听起来合理，实际上每个 agent 都需要上一个的全部上下文，那还不如一个 agent 干完。

好的划分判据是两条：

一、每个 agent 有独立的输入。 不需要把上一个的全部产出都塞给它。

二、每个 agent 的产出可判定。 能说清楚「它干得对不对」。

第二条尤其重要，而且有一个必须遵守的推论：写东西的和审东西的必须是两个 agent。

理由不是分工，是同一个 agent 审自己会夸自己。有实践把「把干活的和判活的分开」称为一个强杠杆；反过来，让一个 agent 既写实现又写测试，它写出的测试会精确覆盖它已经想到的情况 —— 通过只证明它自洽，不证明它对。

错误会沿着链路传染

这是我自己踩过的：多步骤流水线里，第一步让模型抽出一个结构，它编造了一个源材料里根本不存在的东西；第二步直接读那个结构去生成，从它铺出来的每一条产出都继承了这个错。

传染率是 100%，因为每一步的产物是下一步唯一的输入。

所以多 agent 系统有一条必须的规矩：在交接处校验契约。下游不能默认上游给的东西是对的，尤其不能把上游的产物当作事实的来源 —— 出处只认原始材料。

边界与代价

有主张的框架，代价是它的主张可能不是你的。 角色、backstory 这套在「模拟一个团队」的任务上很顺；在一条确定的流水线上就是绕路。

多 agent 的调试成本是超线性的。 一个 agent 出错你看它的输出；四个出错你得先定位是谁，而它的输入是别人的输出。所以上第二个 agent 之前，先确认一个真的不够。

记忆功能要当心。 共享记忆的代价是一次误判被固化成事实，后面所有 agent 都跟着错。所以进记忆最好有门槛（被独立观察到几次才算），出记忆最好有期限。