解锁 AI 代理工作流程：关于使用 langgraph 可视化决策和成本分析的 5 个关键见解

用 LangGraph 的状态流来玩——不需要 LLM 或 API！纯代码和数据科学！

可以通过我的 GitHub 个人资料 这里 访问代码。

背景

这篇文章的想法是在学习 LangGraph 课程时突然冒出来的。当我研究前几个例子时，我完全沉浸在玩 Graph 工作流程中——实际上非常有趣。那时我突然意识到：这些有状态的图对于理解请求和查询如何在代理工作流程中移动非常有用。

所以我有一些有趣的见解，我想与你分享，希望你能一直看到最后！

——让我们开始吧！

本文的目标是深入研究一些最常见的代理工作流程的概率分析，特别是使用 LangGraph。

考虑一个一般的代理 AI 系统示例，该系统使用 LLM 作为决策者来执行以下任务：

代理 AI 系统的状态流

以下是此工作流程内部发生的事情的细分：

• 用户提出一个问题，并将其传递给 LLM 以执行 Refine Query
• 基于上下文，LLM 将响应路由到 Retrieve 或 Search for Online Articles，并且
• 最后，该过程以另一个 LLM Generate Summary 结束。

这是一个代理工作流程（又名 RAG）的一个非常简单的表示。在下文中，我将展示使用 LangGraph 对此过程的高级表示。

我将引导你完成一个使用蒙特卡洛模拟来生成大量样本路径的过程（假设有 10,000 个用户提出各种类型的问题）。

如果你不熟悉 蒙特卡洛模拟，这里是它的要点：这是一种方法，你从概率系统中生成大量随机样本，以了解事物在不同可能结果中的分布情况。

注意：你不需要调用任何 LLM 或 API 来运行此工作流程。这一切都基于假设的场景。

使用 LangGraph 设置一个模拟代理工作流程

我们使用以下场景对上述工作流程进行建模：

状态表示：

系统遵循一个字典 (TypedDictState) 来跟踪核心变量，包括：

• tools_called：工具调用的计数。
• condition：“good” 或 “bad”，表示工作流程状态。
• steps：工作流程中执行的步数。
• node_visits：一个字典，用于跟踪每个节点的访问计数。
• termination_reason：工作流程结束的原因。
• tool_1_count 和 tool_2_count：特定工具的使用计数器。
• token：表示查询度量。例如，用户可能会问一个大小为 100 个 token 的问题。

节点函数：

• node_1：记录访问并更新步数计数。
• tool_1：递增 tools_called，将 condition 设置为 “good”，并增加 token 计数。
• tool_2：递增 tools_called，将 condition 设置为 “bad”，并记录终止。
• node_2：最终决策节点，检查终止条件并更新指标。

决策函数：

• decide_condition：将 95% 的情况路由到 tool_1，将 5% 路由到 tool_2，确保积极结果的可能性更大。
• decide_condition_2：如果 tools_called 超过 55，则将其路由到 node_2 以进行终止；否则，它循环回到 node_1。

图构建：

• 工作流程使用 LangGraph 构建，定义节点之间的边并确保适当的转换。
• 执行从 START 开始，并通过不同的节点进行，直到达到一个吸收条件（node_2 用于超过工具限制或 tool_2 用于负终止）。

Token 成本模拟：

• token 计数器随机初始化为 100 到 400 之间。
• 每次访问节点都会将 token 增加一个随机量，介于 400 到 700 之间，这可以解释为 LLM 生成的响应或检索到的上下文 token。
• 在运行 10,000 次迭代后，我们分析了不同模型中的 token 成本。想象一下一个代理系统处理 10,000 个请求——这让我们能够分解 token 成本和其他关键指标。

终止：

• 当达到不良结果（tool_2 标签）或资源使用超过定义的限制（tools_called > 55）时，工作流程结束。

性能和决策效率使用可视化技术进行评估，例如分布图和 token 成本直方图。

这是一个简单的 Graph 工作流程（不需要 LLM 或任何昂贵的东西）。

供你参考，此表示的 GitHub 代码可在 这里 找到。

结果和分析

模拟运行相对较快，我使用了带有 8GB RAM 的 Macbook Pro M2 芯片，运行 10,000 次迭代大约需要 1.5 分钟。

图 1 — 10,000 次模拟运行达到 END 状态的运行长度分布

图 1 表明，工具调用过程，尤其是如果输出不令人满意，最终可能会运行更长时间（导致消耗更多 token）。

图 2 — 10,000 次迭代的终止原因比例

图 2 — 这很有趣！我们最初的计划是将 95% 的负载发送到工具 1，而只有 5% 发送到工具 2。大约 94% 的迭代从 node_2 结束，只有大约 6% 在最后达到工具上限。

图 3 — 所有 10,000 次运行中每个节点的访问次数

图 3 显示了对每个节点或工具的总访问次数，可以看出，对 node_1 和 tool_1 的访问次数最多。由于决策路由器在这两个节点之间保持运行，这是显而易见的。

在现实世界中，如果用户查询没有通过检索到的上下文找到其响应，那么 LLM 会在线搜索内容以找到资源。

分析 Token 的成本

我运行此模拟的主要原因之一是，当您评估不同的 LLM 模型时，了解运行一个智能体系统的成本。

因此，我查看了来自 OpenAI、Anthropic 和 Google 的 9 种不同的模型，并且我只考虑了每 100 万个 token 的价格成本。自本文发表以来，成本数字可能已经发生了变化。

它提供了一些关于成本如何分布的有趣见解，甚至暗示了您可能需要在哪里进行调整。

图 4 — 不同 LLM 模型每 100 万个 token 的成本

您可以在图 5 中查看生成的 token 总数的分布情况。一般来说，大约 80% 的请求可以使用大约 30,000 个生成的 token 完成。大约不到 10% 的请求可能达到 60,000 个 token。非常有趣的见解。

图 5 — 10,000 次迭代的生成 token 分布

结论

这只是一个简单的例子，您可以从中提取有意义的见解，并了解在大规模推出智能体系统时会发生什么。同样，当使用 LangGraph 时，这种类型的分析突然出现在我的脑海中，我希望这对您有意义，并给您一些思考的余地。

作为下一步，我认为找到成本函数与生成的 token 之间的可能性是对此分析的另一个有趣的补充。