Agent为何这么慢？五个工程优化思路

一个用于绩效评估的 Agent 应用，每次查询都要等待很久。问题不在模型本身，而在工具调用架构。本文基于一场技术访谈中的真实排查过程，梳理 Agent 延迟的常见根因与可落地的优化路径。

先定位：你的 Agent 属于哪种架构

排查性能问题的第一步不是看代码，而是确认架构类型。访谈中，提问者一开始把系统描述为「AI」，受访者 Tanishq 追问了一个关键问题：这是 RAG 聊天机器人，还是 Agent 应用？

答案很明确：这是一个单 Agent 系统，用户不直接对话，而是通过 prompt 驱动，背后调用了约 5 个工具——GitHub、员工数据（通过 MCP 暴露）、文档查询等。系统使用 API 调用而非自托管 LLM，且没有独立的记忆层，所有上下文都放在 Agent 的 context 里。

这个画像决定了优化方向。Tanishq 的总结是：这套系统本质上做的是 context engineering（上下文工程），没有额外的记忆架构。这意味着上下文窗口的每一分浪费，都会直接转化为延迟和成本。

单 Agent 够不够用

访谈后段讨论到多 Agent 方案时，Tanishq 给出了明确判断：对于绩效评估这类场景，单 Agent 加一组固定工具「绰绰有余」。引入多 Agent 会带来记忆管理的复杂度——短期记忆、长期记忆都要维护，投入产出比并不划算。这个观点值得记下来：多 Agent 不是性能银弹，反而常常是延迟的新来源。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底提出并开源的协议，用于标准化 LLM 应用与外部工具、数据源之间的连接方式。它把工具暴露抽象为「Server」，客户端（Agent）通过统一接口发现并调用工具，避免为每个数据源写定制集成。MCP Server 可以挂载任意数量的工具，但协议本身不规定调用是同步还是异步——这取决于 Server 的具体实现和底层传输方式（如 stdio 或 HTTP/SSE）。因此在使用 MCP 时，必须核查 Server 端是否真正支持并发处理，否则即使 Agent 框架支持异步，实际调用仍会退化为串行等待。

Context engineering（上下文工程） 指在有限上下文窗口内，精心选择、组织并注入模型所需信息的实践。与 RAG 依赖检索增强不同，纯 Agent 架构没有独立记忆层，所有工具描述、历史结果和指令都挤在同一个上下文窗口里。上下文越长，推理延迟和 token 成本越高，因此减少冗余工具描述、预存静态数据等操作，本质上都是在做上下文工程。

根因一：同步工具调用是最大瓶颈

访谈中最直接的发现是同步（sync）与异步（async）的问题。提问者承认团队没有考虑过 async，大概率全在用同步调用。

Tanishq 解释了后果：假设有 5 个工具，某个用例需要全部调用，同步模式下 T2 必须等 T1 返回才能开始，T3 再等 T2……等待时间线性累加。对于绩效评估这种需要同时拉取员工数据、代码提交记录、文档等多个来源的场景，这是最典型的延迟放大器。

优化方向清楚：如果工具之间没有输出依赖，就应该走异步并行；只有在后一个工具依赖前一个结果时，才需要顺序执行。这是 P1 级问题，优先改。

同步与异步工具调用的区别在于控制流是否阻塞。同步调用下，Agent 发起工具请求后必须等待响应返回才能继续，多个无依赖工具只能串行执行，总延迟等于各工具延迟之和。异步调用则允许同时发起多个请求，由事件循环或并发框架调度，总延迟约等于最慢那个工具的延迟。实现异步的前提是工具之间没有数据依赖，且 Agent 框架和工具服务端都支持并发。在 LangChain、LlamaIndex 等主流框架中，异步工具需要显式使用 async 函数或 ainvoke 接口，否则默认走同步路径。

根因二：MCP Server 暴露了过多工具

这套系统用 MCP Server 暴露工具能力。Tanishq 提醒了一个容易被忽视的细节：MCP Server 本身不保证异步，需要确认具体实现是否支持 async。

更隐蔽的问题是工具数量膨胀。一个公司级 MCP Server 可能挂载 10 个工具，但某个部门实际只需要其中 5 个。如果不做过滤就直接调用，会产生双重代价：一是多出来的工具调用增加延迟，二是工具描述占用的上下文变多，而由于系统没有独立记忆层，上下文膨胀会直接拖慢推理。Tanishq 的说法是「一个方案解决两个问题」——在调用 MCP Server 之前做工具筛选。

根因三：该缓存的数据在实时拉取

并非所有工具都值得调用。以员工数据为例，Tanishq 指出这类数据并不是每天都变，只有部分字段会更新。像剩余假期天数这种模式固定的信息，完全可以在调用工具之前就存在后端，直接注入系统提示或作为额外指令传给 Agent。

这引出一个更普遍的判断标准：某些工具做的事情很「平庸」，其输出完全可以提前放进模型上下文，不值得走一遍完整的工具调用—响应链路。减少一次往返，就少一段延迟。

工具本身能不能砍

顺带需要回答的问题是：真的需要 5 个工具吗？Tanishq 建议在架构设计阶段就审视工具集合，把可以由上下文直接提供的能力从工具列表中移除。工具越少，Agent 的决策空间越小，调用路径也越短。

工具调用的往返开销不仅包含网络传输，还包括模型生成工具调用参数、解析响应、将结果重新注入上下文并再次推理的完整循环。每一次工具调用都意味着至少一次额外的 LLM 推理步骤，而 LLM 推理本身是延迟大头。因此，把变化频率低的数据预存到后端并直接注入系统提示，相当于用一次上下文写入替代了「生成调用→网络请求→解析→再推理」的完整链路，节省的延迟往往数倍于单纯的网络时间。判断标准可以简化为：如果某工具的输出在一段时间内对同一用户基本不变，且体积可控，就应优先考虑预注入而非实时调用。

优化思路：工具合并与批处理

访谈中提问者提出了两个来自软件工程直觉的方案，Tanishq 分别给出了判断。

工具合并（compose）：如果两个工具的任务有大量交集——比如都从同一个服务器拉取员工相关数据——可以把它们合并成一个工具，一次完成两件事。适用条件是有高交集；如果工具之间完全独立，那正确做法是异步而非合并。

批处理（batching）：这个思路在传统后端很常见——多个请求合并成一批处理。但 Tanishq 指出，对 Agent 而言「多个 Agent 调用同一工具」意味着多 Agent 架构，随之而来的是记忆维护等复杂度。对当前这个单 Agent 的绩效评估场景，不建议为此引入多 Agent。

一张可执行的优化清单

把访谈中的判断整理成行动项：

• 检查所有工具调用是否为同步，把无依赖的工具改为异步并行（优先级最高）
• 确认 MCP Server 的实现是否支持异步，而非默认假设
• 在调用前过滤 MCP Server 的工具列表，只保留当前场景需要的工具
• 把变化频率低的数据（如假期余额）预存到后端，直接注入上下文
• 审视工具集合，砍掉输出可由上下文直接提供的工具
• 对有高任务交集的两个工具考虑合并
• 除非确有必要，不引入多 Agent 架构

这套思路的核心逻辑是一致的：Agent 慢，往往不是模型慢，而是架构里存在不必要的串行等待、冗余调用和上下文浪费。先测量，再按依赖关系重排调用图，延迟通常会有明显改善。

访谈结尾有一段轻松的对话——提问者问有没有「绩效评估后涨薪」的工具，得到的回答是「降薪的工具倒是有」。这个玩笑之外，真正值得带走的是那句追问：先搞清楚你面对的是 RAG 还是 Agent，再谈优化。