使用 Langtrace 追踪 CrewAI 智能体工作流

在这期 2024 年 11 月的教程中，我构建一个小型 CrewAI 应用并接入 Langtrace，以查看智能体执行过程、token 用量和成本。本视频与 Langtrace 合作制作。展示的命令、界面和模型可用性反映的是 2024 年所用版本，复现前请查看当前文档。

在 VS Code 中，我用 `pip install crewai` 安装 CrewAI，用 `pip install "crewai[tools]"` 安装其工具。接着运行 `crewai create crew demo`，在设置提示中选择 OpenAI 和 GPT-4o，并提供服务商 API 密钥。请安全使用自己的密钥，避免将其提交到源代码仓库，并撤销任何意外暴露的凭据。

我打开生成的项目并检查 `config/agents.yaml`。入门团队包含一名研究员，其角色和目标围绕指定主题；还有一名报告分析师，将研究整理成报告。任务配置分别描述研究和报告任务；`crew.py` 则把智能体与任务连接起来。

我在 `main.py` 中把主题设为 AI LLMs。视频随后在项目中运行 `crewai install` 和 `crewai run`，测试生成的项目框架。研究员为报告分析师提供材料，最终结果写入 `report.md`；这只能验证基本流程运行成功，不能证明其中的事实主张正确。

我创建一个托管版 Langtrace 项目，选择 CrewAI 和 OpenAI 作为集成，并安装 `langtrace-python-sdk`。Langtrace 应用可依据 AGPL-3.0 自行托管，视频使用的是托管服务；请根据自己的部署方式检查适用许可和当前价格。

我生成 Langtrace API 密钥，并在应用中初始化 Python SDK。SDK 文档要求在导入需要追踪的组件之前进行初始化。应将密钥存入环境变量或密钥管理器，而不是把真实密钥写进源代码；还要考虑追踪记录可能包含发送给所选服务的提示词和输出。

编辑器最初无法解析 SDK。我选择包含该包的 Python 解释器，再次运行团队。实际项目中，要确保 SDK 安装在 `crewai run` 使用的同一环境中，并加入项目依赖；仅在编辑器中选择解释器可能无法修复独立的运行时环境。

新的 Langtrace 项目显示了这次运行的追踪记录。它显示调用实际使用了 GPT-4o mini，尽管我在设置时选择了 GPT-4o。当框架默认值或配置与预期不一致时，检查追踪记录中的实际模型很有用；默认值也可能随版本变化。

我打开追踪详情，查看团队启动、任务和智能体执行，以及通过 LiteLLM 和 OpenAI 发起的调用。跨度图显示每个阶段的耗时。我筛选调用栈，重点关注 CrewAI 和 OpenAI，并比较这次运行中约 26 秒的团队启动与约 7 秒的单个任务。

指标视图按时间显示输入、输出和总 token 用量，以及估算成本和追踪记录数量。这个 2024 年的小型示例运行成本不到一美分；实际成本取决于模型、用量和价格，并非每次运行都有固定费率。

我将项目类型切换为 CrewAI，以使用专用仪表盘并在不同会话间切换。视图汇总了运行耗时、智能体和任务详情以及执行时间线。示例没有使用记忆或工具，但在存在这些内容时仪表盘有对应区域。

我再次运行团队。第二条追踪记录出现，指标在多次运行间累计，因此可以比较耗时、token 数和成本。这些观察有助于定位昂贵或缓慢的阶段，但单凭追踪记录无法确定答案是否准确或有用。

为了比较模型，我在 `crew.py` 中将研究员设为 GPT-4o，将报告分析师设为 o1-mini。Langtrace 随后在新的追踪记录中显示两个模型名称。示例运行耗时约 45 秒，成本高于此前的 GPT-4o mini 运行；单次运行只是示例，不能确立普遍的速度或质量排名。

这个练习的目的，是通过观察每个智能体实际做了什么，在质量、延迟和成本之间取得平衡。评估质量仍需要适当的测试或审查。我感谢 Langtrace 与我合作制作视频，并指出读者可以选择自行托管的应用或托管服务。