如何加速我的 Agent？ - LangChain 博客

我经常被问到这个问题。开发者通常首先花时间让 Agent 正常工作，然后他们才会关注速度和成本。我们看到开发者通常会做以下几件事

确定延迟的来源
改变用户体验以减少“感知”延迟
减少 LLM 调用次数
加速 LLM 调用
并行进行 LLM 调用

确定延迟的来源

这听起来可能很简单，但你减少延迟的方法将完全取决于你的具体瓶颈。延迟是来自一次大型 LLM 调用，还是来自多次小型调用累积起来的？在尝试加速之前，你需要诊断这些问题。

LangSmith 是一个非常实用的工具，它可以完全可视化你的 Agent 交互过程。你可以跟踪 Agent 每个步骤的延迟，我们最近还引入了“瀑布”视图，可以轻松识别哪些步骤对整体延迟贡献最大。

改变用户体验以减少“感知”延迟

有时，减少延迟最简单的方法……是不减少延迟。

虽然乍一看可能违反直觉，但如果我们思考一下为什么延迟很重要——它通常很重要，因为人们担心如果 Agent 运行时间过长，用户会不喜欢使用它。这通常可以通过更新 Agent 的用户体验来解决。我们看到人们主要通过两种方式来实现这一点。

流式传输结果。 流式传输对于大多数 LLM 应用程序来说非常常见，但如果你还没有这样做，你绝对应该这样做。它可以向用户传达 LLM 正在工作，并且他们不太可能离开页面。除了流式传输响应令牌外，你还可以流式传输超出最终响应范围的内容。例如，你可以流式传输 Agent 正在采取的计划步骤、检索结果或思考令牌。Perplexity 在这方面做得非常出色，他们的搜索界面就是如此。他们发现，通过更改 UI 以显示这些中间步骤，用户满意度得到了提高——尽管总完成时间保持不变。
在后台运行 Agent。让 Agent 在后台运行。对于我的电子邮件助手，我无法看到电子邮件 Agent 需要多长时间。这是因为它是由事件（电子邮件）触发的，我只会在它卡住时收到通知。我向用户隐藏了所有延迟，Agent 只是在后台运行。

减少 LLM 调用次数

并非所有事情都需要 LLM 调用。如果你可以用非 LLM 调用的方式来完成事情 - 那就太好了！我们看到的正在构建的 Agent 是 LLM 调用和代码的组合。这种将代码与 LLM 调用相结合的混合方法是 LangGraph 的指导原则之一，也是 Replit、Uber、LinkedIn 和 Klarna 等公司采用它的核心原因。

我们看到的一个常见路径是“单次 LLM 调用” → “ReAct Agent” → “多 Agent” → “LangGraph”。

人们从单次 LLM 调用开始。他们遇到一些缺点，然后升级到 Agent。这工作正常，但随后他们尝试为其提供更多工具，并意识到单个 Agent 只能支持这么多工具。然后他们转向“多 Agent”设置，使用 supervisor 或 swarm 架构。

问题在于这些架构使用了大量的 LLM 调用。它们在不同 Agent 之间的通信效率不高。这是设计使然 - 它们是通用架构，因此没有针对你的用例进行优化。

这就是我们看到人们转向 LangGraph 的原因。LangGraph 是低级别的，允许你精确指定这些 Agent 应该如何相互通信（或者何时只是 LLM 调用）。通常，这会导致 LLM 调用次数显着减少，从而使 Agent 更快、更便宜（并且通常更可靠）。

加速 LLM 调用

我们通常看到开发者通过两种方式加速 LLM 调用。

更快的模型。有些模型比其他模型更快。谷歌提供了非常快速的 Gemini Flash。OpenAI 和 Anthropic 也提供了更小、更快的模型。像 Groq 和 Fireworks 这样的开源模型托管平台也在不断努力使最好的开源模型更快。注意：这通常会以使用更差的模型为代价，因为这些更快的模型通常更小，因此准确性较低。

更少的上下文。 LLM 响应所需的时间与输入的长度成正比。为了获得更快的结果，你可以传递更少的输入！这就是为什么你需要完全控制和可见性，了解确切是什么进入了每次 LLM 调用。模糊这一点（或不容易控制）的框架是不好的 - 这就是为什么 LangGraph 没有隐藏提示的原因——你拥有完全的控制权。如果你正在寻找一种方法来更好地了解进入 LLM 调用的内容 - 请查看 LangSmith。