用 CrewAI 构建研究与写作流程

Matthew Berman 欢迎 CrewAI 创始人兼首席执行官 João Moura 做客，一起扩展他们在上一期视频中开始构建的教育内容工作流。Berman 披露自己是 CrewAI 的投资人，并称它是自己最喜欢的智能体框架。他们的目标是研究 AI 主题，为教育内容门户生成有用的初稿。

Berman 最初的 crew 包含一位使用 Serper 搜索的研究员和一位根据研究结果写作的内容创作者。一份关于大语言模型微调的示例报告还算不错，但尽管他反复要求全面覆盖，篇幅和细节仍不如他希望的那样充分。他还在考虑加入审核智能体。

Berman 说，在他的实验中，OpenAI 的 o1 模型生成了更详细的报告，但成本和耗时都高得多。Moura 表示，根据他的经验，o1 在智能体工作流中有时会在使用可用工具之前推断答案，并产生幻觉。这些是两人的观察，不是对模型质量的受控比较。

Moura 建议把规划与写作分开：先研究主题，再创建大纲，说明各节及其重点，最后开始写作。末尾还可以安排审核员。对于更长的文档，他建议使用两个 crew：一个负责研究和规划，另一个按计划逐节撰写。

Berman 还用 Langtrace 查看追踪记录、成本和耗时；他表示 Langtrace 没有赞助这期视频。Moura 强调，可观测性是构建智能体系统的有用部分。接下来，他们将这个分工方案变成可以运行的 flow。

他们使用当时的 `crewai create flow` 命令启动新流程，并将现有 crew 移到 flow 的 crews 目录下作为参考。环境配置放在 flow 层。教程展示的是 2024 年版本的 CrewAI，因此读者应查看当前文档，确认命令和 API 是否有所变化。

Moura 将 flow 解释为连接 crew 和普通 Python 代码的轻量编排层。带有 `@start` 标记的函数启动工作，带有 `@listen` 标记的函数则在指定的前一个函数结束后运行。初始的写诗示例依次生成句子数量、生成诗歌并保存。

对于他们的内容系统，第一步将运行研究 crew 并生成计划。然后，监听步骤在循环中调用写作 crew，每个章节调用一次。这样可以明确结构和顺序，而不是要求一个智能体一次完成整篇长文的研究和写作。

他们重命名初始 flow 和函数，移除写诗专用的状态，并为两个阶段留下占位符。Moura 解释，空的 Python 函数需要 `pass` 之类的语句。随后他们运行 flow 绘图命令，查看各步骤的简单可视化表示。

flow 图可以进一步加入条件、路由器或监听器。Moura 举例说，后续可以用 Python 函数监听已完成的内容，再通过 API 推送到 CMS。Berman 认为这符合他打算建立的发布流程，但他们在本次演示中没有实现。

他们通过 CLI 帮助找到正确语法，为 flow 添加研究 crew 和内容写作 crew，并删除写诗示例 crew。每个新 crew 都用 YAML 定义智能体和任务。原有 crew 暂时保留，供他们参考 Berman 已写好的角色和提示词。

Moura 演示如何使用 Cursor 的行内编辑和聊天功能改写原有定义。研究 crew 将包含收集信息的研究员，以及将信息整理成大纲的规划员。两人把助手生成的修改当作建议，逐项检查和调整，而非盲目接受。

他们编辑研究任务，明确主题和目标受众，首先选择面向初学者的微调材料。Moura 建议给研究员一个目标，让其返回相关信息和参考来源，再由规划员决定如何呈现材料。他们打算通过测试逐步改进这些指令。

规划任务的预期输出是一系列章节，每节包含小标题、高层目标、该节为何重要以及来源。Berman 添加受众水平变量，让同一流程能够适配初级、中级或高级读者。他们没有要求计划采用 Markdown 格式，因为下一阶段需要使用结构化数据。

他们把研究 crew 导入 flow，并传入示例主题和受众作为输入。第一次启动因调用 crew 的方式错误而失败；调试后，他们先实例化对象，再调用其 crew 方法，最后调用 `kickoff`。他们还将 Serper 搜索工具接入研究员。

一次成功的研究运行找到参考来源，并生成面向初学者的大语言模型微调大纲，包括介绍、微调的含义、流程、技术和挑战。Berman 喜欢这个结构，而 Moura 指出，他们仍需要把计划转换成下一阶段可用的对象。

Moura 解释了 Pydantic 模型的作用：应用不必只传递一个长字符串，还可以要求返回名称和类型明确的字段。一个章节可以包含标题、目标、重要性、来源和提纲；一份教育内容计划则包含章节列表。普通 Python 代码随后就能遍历这个列表。

他们使用 Cursor 起草 Pydantic 类，并简化建议的结构。规划任务被配置为通过 `output_pydantic` 返回 `EducationalPlan`。flow 从研究步骤返回结构化结果，让监听该步骤的写作函数能够收到计划。

在写作步骤中，他们遍历 `plan.sections`，并准备一个集合存放最终内容。预期行为是针对每个章节运行写作 crew，并追加结果。之后，一个独立监听函数可以保存合并后的输出、将其发送到云服务，或传给其他系统。

他们为写作 crew 配置内容写手、编辑和质量审核员，并为每个角色添加任务。受众水平仍作为输入，使文章适合目标读者。他们用 Cursor 起草 YAML 和 Python 定义，但具体角色和任务指令仍需要细化。

他们导入写作 crew，开始将它接入循环。第一次尝试暴露了一个遗漏：写作 crew 同样需要主题和受众水平。他们把共享输入集中到一个地方，避免重复填写，然后再次运行，观察结构化计划结果的处理情况。

Berman 介绍自己偏好的开发策略：先使用能力强的模型，再在改进工作流后尝试较便宜的模型。他和 Moura 希望通过任务拆分，以更低成本和延迟获得高质量输出，但本次并没有进行受控的质量比较。实际节省多少取决于模型、工作负载和调用次数。

接下来的错误显示，内容写作 crew 仍在使用初始定义。Cursor 提出了修改，但 Moura 注意到其中有不必要的手动 YAML 加载，于是两人拒绝了这个过于复杂的建议。他们缩小要求，只让 Python crew 的智能体和任务名称与 YAML 定义对应，再补上缺失的审核员。

进一步测试发现，质量审核任务的名称及其关联智能体存在不一致。他们统一 YAML 和 Python 文件中的名称，确保每个任务都引用正确的智能体。这类调试很重要：如果配置不一致，智能体工作流可能在模型进行任何有用推理之前就失败。

第二个 crew 启动后，会为计划中的每一节单独运行。Berman 和 Moura 注意到一个重要遗漏：循环虽然传入了主题和受众，却没有传入当前章节。缺少这项信息时，每次调用可能不知道自己应该写文章的哪一部分。

他们在循环内部复制共享输入、加入当前章节，并在写作任务描述中引用该章节。他们尝试的一个 Pydantic 转换方法不正确；用 Cursor 查过后，改用 `model_dump_json`。为每次迭代传入实际章节计划，可以明确提供该任务所需的上下文。

Moura 提出未来可以增加的功能：给写作 crew 配备搜索或其他工具，以便查看参考资料和核实事实；还可以创建工具，检索以前批准过的内容作为示例。Berman 询问图形和示意图的生成方式，Moura 则介绍了另一个案例：编程智能体根据支持数据中的发现编写绘图代码。

两人还需要收集完整结果，而不是只查看最后一节。他们调整原始输出的处理方式，并添加监听函数，将返回的内容保存到文本文件。写作步骤返回合并后的结果，保存步骤才能接收并使用它。

Langtrace 显示调用使用了 GPT-4o，而 Berman 原本以为使用的是 GPT-4o mini。他们检查模型配置，为后续运行修改一个环境设置。Moura 还指出，研究员目前只能看到搜索结果，并没有抓取链接页面；添加抓取工具是建议中的改进，本次并未完成。

新的运行暴露了输出设计问题：最后一个智能体是质量审核员，因此它的质量评估报告被当成文章章节。Berman 打开输出文件，发现本应出现正文的地方是审核反馈。仅仅增加审核员并不能解决问题；最后一个任务必须返回流程实际需要的产物。

他们修改编辑任务的预期输出，要求只返回润色后的章节，不包含反馈。同样，他们要求质量审核员返回吸收反馈后的改进版本，而不是评估报告本身。写作任务也被限定为长篇文章中的一到两段。

随后的一次运行遇到 Langtrace 导入问题。他们检查示例代码后修正导入，并恢复追踪。两人计划利用追踪记录检查模型选择、运行成本和延迟，而不是凭猜测判断实际使用了哪个模型。

Moura 表示，GPT-4o mini 是他当时在智能体工作流中偏爱的模型，并认为设计良好的工作流在某些场景中可能达到或超过 o1 的质量。Berman 回忆说，之前一次简单的 o1 运行大约花了 50 至 60 美分。他们关于便宜模型能覆盖大多数使用场景的广泛判断是估计，并非本次演示的实测结果。

两人讨论了自行部署开放模型这一选项，适合希望数据留在自身基础设施中的组织。Berman 对小模型能够处理多少工作给出了推测性百分比；这些数字不应视为基准统计。选择模型仍需结合任务、质量要求、安全性和部署成本进行测试。

查看生成的章节时，Moura 建议不要处处强制使用项目符号，也不要在每个中间章节末尾都写一段结论。Berman 添加了这些指令，但表示在进一步修改之前，他会先检查内容的准确性、完整性和深度是否合适。单纯增加篇幅不是他的目标。

Moura 建议为研究 crew 添加网页抓取工具，也可以考虑给写作 crew 添加，以便更深入地核查参考来源。Berman 还提出，未来可以考虑用更快的推理方式进行优化。这些都是后续想法，并不能证明当前输出已经过事实核查，也不能证明会达到某个特定的加速幅度。

最终的文本文件包含微调文章的多个章节，Berman 认为初看很有希望。他计划更仔细地审核内容，继续迭代智能体和任务定义，并表示会在链接的代码库中分享代码。本次演示以一个可运行的原型结束，同时明确列出了尚待改进的质量问题。