Agent 性能：先减少无效步骤，再优化模型、缓存和并行

很多人一看到 Agent 延迟高，第一反应就是换个更快的模型。但真实系统里的延迟，往往由几部分叠加：

• •模型推理时间
• •工具调用时间
• •检索或数据库访问时间
• •上下文整理时间
• •多步循环带来的总轮次

所以优化性能之前，最重要的不是“先换模型”，而是先把延迟拆开看。

如果不先做这一步，最后很容易出现一种假优化：

• •模型换小了
• •回答质量差了
• •总体延迟却没明显下降

因为真正的瓶颈根本不在模型上。

这是比“模型路由”更优先的一步。

Agent 变慢，经常是因为它做了太多本来不该做的事：

• •不必要的工具选择
• •不必要的模型轮次
• •太长的上下文
• •明明可以并行却串行执行

所以更合理的优化顺序应该是：

• •先减少无效步骤
• •再优化模型和缓存
• •最后再考虑更细的并发和流式体验

如果一个 agent 面前摆着十几个工具，它不仅更容易选错，通常也更慢，因为每一轮都要在更大的决策空间里做选择。

LangChain 当前的 prebuilt middleware 里提供了 LLMToolSelectorMiddleware，它的思路就很适合性能优化：先用一个更轻量的选择器，把当前真正 relevant 的工具筛出来，再让主模型决策。

这类优化的收益通常有两个：

• •降低工具选择复杂度
• •减少不必要的工具调用

对工具较多的 agent，这种“先减法”常常比继续调 prompt 更见效。

模型当然会影响性能，但更关键的是把不同类型任务送到合适模型，而不是所有请求都打到同一个大模型。

LangChain 的模型接口本身就支持你按任务类型初始化不同模型，因此比较稳妥的路由方式通常是：

• •分类、提取、排序：小模型
• •复杂推理、长链规划：大模型
• •子代理或辅助步骤：mini / nano

而不是让模型自己再调用一个模型帮你选模型。

一个简单示意：

from langchain.chat_models import init_chat_model


fast_model = init_chat_model("openai:gpt-5.4-mini")
cheap_model = init_chat_model("openai:gpt-5.4-nano")
strong_model = init_chat_model("openai:gpt-5.4")


def pick_model(task_type: str):
    if task_type in {"classification", "routing"}:
        return cheap_model
    if task_type in {"tool_loop", "drafting"}:
        return fast_model
    return strong_model

这类路由的前提是：你已经知道任务被分成了哪些阶段。否则所谓“动态模型选择”很容易重新变成不透明黑箱。

官方 middleware 文档里对 SummarizationMiddleware 和 ContextEditingMiddleware 的说明很值得直接吸收，因为它们解决的是 Agent 最典型的性能问题之一：上下文越来越长。

上下文过长会同时带来三件坏事：

• •延迟上升
• •成本上升
• •模型注意力被旧信息稀释

因此在长对话或长任务里，应该尽早引入上下文收缩策略，例如：

from langchain.agents import create_agent
from langchain.agents.middleware import SummarizationMiddleware


agent = create_agent(
    model="gpt-4.1",
    tools=[search_tool, calculator_tool],
    middleware=[
        SummarizationMiddleware(
            model="gpt-4.1-mini",
            trigger=("tokens", 4000),
            keep=("messages", 20),
        ),
    ],
)

这类策略的意义不只是“省 token”，更是在保护主模型不要被无关旧上下文拖慢。

OpenAI 当前的 prompt caching 官方文档给了一个非常清楚的结论：

• •缓存对 1024 tokens 以上的请求生效
• •依赖 exact prefix match
• •最佳情况下可把延迟降低到原来的约 20%
• •输入成本最高可降低 90%

这对 Agent 场景尤其重要，因为 Agent 很多请求都共享长前缀：

• •系统提示词
• •工具定义
• •固定工作流说明
• •一部分会话上下文

所以一个很实用的优化原则是：

• •把静态内容放在前面
• •把动态内容放在后面

如果你用的是 OpenAI API，还可以结合 prompt_cache_key 提高缓存命中稳定性。

很多人把 streaming 当成性能优化的全部，但它更准确的作用是改善 perceived latency，也就是用户“感觉多快看到东西”。

它适合：

• •长回答
• •多段输出
• •明显有等待感的交互

但它不会自动缩短整个 agent loop 的真实执行时间。真正的总延迟，仍然取决于：

• •模型调用次数
• •工具串行深度
• •外部 IO

所以 streaming 应该作为体验优化，而不是替代系统级性能治理。

Agent 一慢，另一个常见冲动是“全都并行化”。但并行只有在步骤彼此独立时才有意义。

比较适合并行的场景包括：

• •多个独立检索
• •多个互不依赖的 API 查询
• •多个子任务的预取

而不适合并行的场景包括：

• •当前步骤依赖上一步结果
• •高风险副作用动作
• •需要严格顺序语义的工作流

所以更好的问题不是“能不能并行”，而是“这几个步骤之间是否真的有数据依赖”。

LangChain 当前 models 文档明确提到，模型调用会返回 usage metadata，也可以通过 callback 聚合 token 使用情况。再加上 tracing，你至少可以回答这些问题：

• •哪类请求 token 最多
• •哪一步调用最慢
• •哪个工具最常拖慢全链路
• •哪个 workflow 平均轮次最高

没有这些数据，性能优化往往只会变成“换了个模型试试看”。

如果你现在要给 Agent 提速，我建议优先按这个顺序做：

• •看 trace，把总延迟拆成模型、工具、检索和循环轮次
• •删掉无效工具和无效步骤
• •对长上下文加 summarization / context editing
• •再做模型分层路由
• •再做 prompt caching 和并行化
• •最后补流式输出优化感知体验

这个顺序的好处是，你不会一上来就把问题归咎给模型。

Agent 性能优化最容易走偏的地方，是把所有问题都归结成“模型快不快”。但真正影响体验的，往往是整条执行链的结构：

• •步骤是不是太多
• •工具是不是太杂
• •上下文是不是太长
• •本来能并行的是否还在串行

先把这些结构性问题处理掉，再去做模型路由、缓存和流式输出，优化通常会更稳，也更符合真实工程收益。

• •LangChain Models
• •LangChain Middleware Overview
• •LangChain Prebuilt Middleware
• •OpenAI Prompt Caching