type
Post
status
Published
date
May 24, 2026
slug
agent49
summary
tags
Agent
category
icon
password
0. 先给结论：Agent 慢，通常不是“模型慢”一个问题
Agent 的总耗时来自一条闭环：
用户请求 → 规划 → LLM 决策 → 工具调用 → 工具结果回填 → 再次 LLM 决策 → 继续工具调用 → 最终生成
所以优化 Agent 延迟不能只盯模型 API 的响应时间，而要拆成：
总耗时 ≈ 模型排队时间 + 首 token 时间 + 输出 token 时间 + 工具 I/O 时间 + 工具串行等待 + RAG 检索/重排时间 + 上下文膨胀成本 + 重试/纠错成本
工程侧主要优化“少走弯路、少串行、少传 token、少重试”；基座侧主要优化“模型本身推理更快、缓存命中更高、吞吐更稳、长上下文更便宜”。
1. 先建立耗时观测：不要凭感觉优化
一个生产级 Agent 至少要采集这些指标：
指标 | 含义 | 常见问题 |
steps_count | Agent 循环轮数 | ReAct 无上限，越想越久 |
tool_calls_count | 工具调用次数 | 工具描述不清、重复搜索 |
tool_latency_p50/p95 | 工具耗时 | 浏览器、数据库、代码沙箱慢 |
llm_ttft | 首 token 时间 | 上下文过长、缓存未命中、排队 |
llm_output_tps | 输出速度 | 模型大、解码慢、输出太长 |
input_tokens/output_tokens | 输入/输出 token | 历史消息、工具结果、RAG chunk 塞太多 |
rag_retrieval_ms | 检索耗时 | 向量库索引、过滤、网络慢 |
rerank_ms | 重排耗时 | Cross-Encoder 或 LLM rerank 太重 |
cache_hit_rate | prompt/语义缓存命中 | 动态内容放在 prompt 前缀，破坏缓存 |
retry_count | 失败重试次数 | 工具 schema、权限、沙箱、超时策略差 |
OpenClaw 的公开仓库也把
/trace、/usage off|tokens|full、/compact、/think <level> 这类运维命令放在 operator quick refs 中，本质上就是让操作者能观察 token、压缩上下文、调节思考强度，而不是黑盒等待。(GitHub)2. 图解：原始串行 Agent 为什么慢？
这个流程的问题是：RAG、工具、LLM 决策都串在一起；每次工具结果又会膨胀上下文；如果模型没有明确停止条件，就会持续“再查一下、再验证一下、再调用一次”。
优化后的目标是：
3. 工程侧优化一：限制 Agent 迭代次数，避免“无限自嗨”
很多 Agent 变慢，不是因为单步慢，而是因为循环次数不可控。OpenCode 文档里专门提供了
steps 配置，用于控制 agentic iterations 的最大次数；达到限制后，Agent 会被要求总结已完成工作和剩余建议。(OpenCode)参考配置：给不同 Agent 设置不同 step budget
OpenCode 文档还支持按 agent 配置模型、权限、prompt 和步骤数；Plan Agent 可使用更快模型，Build Agent 使用更强模型。(OpenCode)
工程落地时可以把 step budget 做成策略：
任务类型 | 建议 step budget | 退出条件 |
FAQ / 简单 RAG | 1–2 | 检索命中且答案置信度足够 |
代码解释 | 3–5 | 找到目标文件和关键引用 |
Bug 修复 | 8–15 | 测试通过或定位失败原因 |
大型重构 | 20+ | 分阶段 checkpoint，而不是一次跑到底 |
深度研究 | 10–30 | 达到证据覆盖率或时间预算 |
核心原则：
Agent 不是越自主越好，而是要“有预算地自主”。
4. 工程侧优化二：把串行工具调用改成 DAG 并行
OpenAI Function Calling 文档说明，模型可能在一轮里调用多个函数，也可以通过
parallel_tool_calls=false 限制为最多一个工具调用；这意味着工程侧可以显式区分“可并行工具”和“有依赖工具”。(OpenAI开发者) LangChain 前端工具调用文档也强调，Agent 可以同时出现多个 pending tool calls，UI 应该支持部分完成、独立更新，而不是等所有工具完成才显示。(LangChain 文档)错误做法：所有工具都串行
正确做法：无依赖工具并行，有依赖工具串行
典型可并行任务：
同时查多个文档库、同时读多个文件、同时跑 lint 和单测、同时请求多个只读 API、同时让多个 read-only subagent 探索不同目录。
典型不能并行任务：
先登录再查询、先创建资源再写入、先生成迁移再跑数据库、先安装依赖再运行测试、多个工具会写同一个状态字段。
LangChain 工具文档提到，如果并行工具会更新同一个状态字段，需要 reducer 来解决并发状态冲突。(LangChain 文档)
5. 工程侧优化三：Plan / Build / Explore 分工，不要一个 Agent 干到底
OpenCode 内置 Build 和 Plan 两类 primary agent：Build 默认全工具，适合开发执行；Plan 是受限 agent，默认文件编辑和 bash 都需要确认，适合分析和计划。它还提供 General、Explore、Scout 等 subagent，其中 Explore 是快速只读代码库探索，Scout 用于外部文档和依赖研究。(OpenCode)
这对耗时优化非常重要：
Agent | 模型 | 工具权限 | 目标 |
Router | 小模型 | 无工具或少量分类工具 | 判断任务类型 |
Plan | 快模型 | 只读 | 产出执行计划 |
Explore | 快模型 | grep/read/list | 快速定位上下文 |
Build | 强模型 | edit/bash/test | 真正修改和验证 |
Reviewer | 中等模型 | read-only | 检查结果 |
Summary/Compaction | 小模型 | 无写权限 | 压缩上下文 |
Claude Code 的实践也类似：官方文档建议用 subagents 处理隔离任务，每个 subagent 有自己的上下文和允许工具集，适合读取很多文件或处理专门任务，避免污染主对话上下文。(Claude Code) Anthropic 还在 Claude Code 更新中强调 subagents、hooks、background tasks 可以支持更自主的长任务；其中 background tasks 可让 dev server 这类长进程不阻塞 Claude Code 继续工作。(Anthropic)
典型调度图
注意：多 Agent 不是越多越快。LangChain 多 Agent 文档明确指出，多 Agent 适合单 Agent 工具太多、专业上下文很长、或需要强约束顺序的场景；核心是 context engineering，即每个 Agent 只看到完成当前任务所需的信息。(LangChain 文档)
6. 工程侧优化四：减少上下文膨胀，优先压缩“工具结果”和“历史轨迹”
Agent 慢的一个隐性杀手是上下文越来越长。每一次工具结果、搜索结果、代码片段、错误日志都会被塞回下一轮 LLM 请求，导致 TTFT 和成本持续上升。
OpenCode 有隐藏的 compaction agent，会在需要时把长上下文压缩成较小摘要；它还有 summary/title 等隐藏系统 agent。(OpenCode) OpenClaw 也把
/compact 放进常用操作命令，说明长会话压缩是 Agent 产品里的基本能力。(GitHub)上下文压缩策略
内容 | 是否保留原文 | 压缩方式 |
用户最终目标 | 必须原文保留 | 放入 pinned context |
工具调用参数 | 保留结构化摘要 | JSON 摘要 |
工具大结果 | 不保留全文 | 摘要 + 引用 ID |
代码 diff | 保留关键 patch | 大文件只保留路径和片段 |
测试日志 | 只保留失败摘要 | 错误类型、堆栈首尾、失败用例 |
RAG chunk | 只保留引用和关键句 | 最终回答阶段再取原文 |
压缩器示例
更好的做法是让工具返回结构化结果，而不是把日志原样扔给模型：
7. 工程侧优化五：RAG 不要无脑全流程跑，按置信度分层触发
RAG 里的耗时通常来自：
查询改写 → 多路召回 → 向量检索 → BM25 → 融合 → rerank → chunk 压缩 → 引用生成
LlamaIndex 的两阶段检索思路是：第一阶段用 embedding top-k 扩大召回，第二阶段用更昂贵但更精确的 rerank 过滤候选。它也明确指出 LLM-powered retrieval / reranking 能提升相关性，但代价是更高 latency 和成本。(llamaindex.ai) Zilliz 也强调 reranker 能增强 RAG 相关性，但会带来额外延迟和计算成本，高流量场景不一定适合全量 rerank。(zilliz.com)
RAG 延迟优化决策
Redis 的 RAG 优化文章也建议先建立 baseline，再按指标逐步优化；混合检索、HNSW 参数、chunking、语义缓存、query transform、rerank 都是可选层，而不是每个请求都必须全开。(Redis)
动态 RAG Pipeline 示例
8. 工程侧优化六：利用 Prompt Cache，但不要破坏缓存前缀
OpenAI 文档说明 Prompt Caching 对重复系统提示、通用指令等内容有帮助；缓存命中依赖 exact prefix match，因此静态内容应放在 prompt 前部，用户变量和动态内容放后部。OpenAI 文档还称 prompt caching 可将 latency 最高降低 80%、输入 token 成本最高降低 90%。(OpenAI开发者) Anthropic 的 Claude API 支持 automatic caching 和 explicit cache breakpoints，适合多轮对话、长上下文、重复指令等场景，默认缓存生命周期是 5 分钟，也提供 1 小时缓存选项。(Claude API Docs)
错误 prompt 结构：动态内容放前面，缓存难命中
正确 prompt 结构：稳定前缀放前面，动态内容放后面
OpenAI Function Calling 文档还提到，可以用
allowed_tools 限制当前可用工具，而不是每次改变传入工具列表，这样有助于保持 prompt caching 的收益。(OpenAI开发者)9. 工程侧优化七：工具描述要减少误调用和重试
工具调用慢，很多时候是因为模型第一次调用错了，然后被迫重试。优化点：
工具描述写清楚“什么时候用 / 什么时候不用”；参数 schema 严格；错误信息结构化；工具结果短而可判断；高风险工具需要 dry-run；工具超时要返回可恢复错误。
OpenAI 文档建议为 function calling 开启 strict mode，以让函数调用更可靠地遵循 schema；它也说明 strict mode 对 schema 有要求，例如 object 需要
additionalProperties=false，字段需要标记 required。(OpenAI开发者)工具错误返回不要这样
应该这样
这样模型不需要再猜：“是参数错？权限错？网络错？要不要重试？”
10. 工程侧优化八：长任务要 checkpoint，不要一次性跑到底
Claude Code 在 2025 年发布的更新中引入 checkpoints，用于在复杂开发任务中保存代码状态，并允许回退到之前版本；同一篇更新还把 subagents、hooks、background tasks 放在长任务自主执行能力里说明。(Anthropic)
工程上可以这样设计：
这样用户不会等 30 分钟后才看到“失败了”。每个阶段都能产出可检查结果：
阶段 1：定位问题阶段 2：修改代码阶段 3：运行测试阶段 4：生成 PR / 总结风险
11. 基座侧优化一：模型路由，小模型做便宜步骤，大模型做关键步骤
不要让最强模型处理所有子任务。OpenCode 文档明确支持在 agent 配置中覆盖模型，并举例说明可以用更快模型做 planning，用更强模型做 implementation。(OpenCode)
推荐路由：
子任务 | 推荐模型 |
意图分类 | 小模型 |
是否需要 RAG | 小模型 |
查询改写 | 小模型或 embedding 模型 |
粗规划 | 快模型 |
代码实现 | 强模型 |
安全审查 | 强模型或专门 reviewer |
总结压缩 | 小模型 |
最终高质量回答 | 中/强模型 |
Claude Code 产品页也显示其支持 Opus、Sonnet、Haiku 等不同模型，并介绍了 fast mode：面向 Opus 4.6 的高速配置，速度更快但 token 成本更高。(Claude)
核心策略：
延迟敏感任务优先小模型；质量敏感任务才升级大模型；失败重试时再升级，而不是默认最强。
12. 基座侧优化二：控制输出长度、推理强度和采样参数
很多 Agent 慢在输出太长，尤其是模型每轮都输出完整推理、完整计划、完整日志解释。
工程侧可以设置：
OpenAI Agents SDK 的
ModelSettings 暴露了 temperature、tool_choice、parallel_tool_calls、max_tokens、reasoning、verbosity、prompt_cache_retention 等模型调用配置。(OpenAI)经验建议：
场景 | 参数倾向 |
分类 / 路由 | 低 temperature、短输出 |
工具参数生成 | strict schema、低 temperature |
规划 | 中等 max tokens |
代码生成 | 较高 max tokens，但限制轮数 |
总结 | 低 verbosity |
深度推理 | 明确开启 reasoning，但只在必要时触发 |
13. 基座侧优化三：Prompt / Prefix / KV Cache
Prompt cache 是 hosted API 最容易获得收益的基座能力；KV cache / prefix cache 是自托管推理服务的重要能力。
OpenAI 的 prompt caching 自动启用在近期模型上，并要求相同 prompt 前缀才容易命中；Anthropic 则支持自动缓存和显式 cache breakpoint。(OpenAI开发者)
Agent 里最适合缓存的内容：
系统提示词、工具定义、企业规则、代码规范、少量稳定示例、项目 README 摘要、稳定技能说明、固定输出格式。
最容易破坏缓存的内容：
当前时间、随机 request id、用户画像、工具结果、检索结果、临时 scratchpad、动态可用工具列表。
14. 基座侧优化四：Continuous Batching、PagedAttention、Chunked Prefill
如果是自托管模型，推理引擎会直接决定吞吐和尾延迟。
vLLM 的公开仓库说明其优化包括 PagedAttention、continuous batching、chunked prefill、prefix caching、CUDA/HIP graphs、量化、优化 attention kernels、speculative decoding、分离 prefill/decode 等。(GitHub) TensorRT-LLM 文档也列出 In-Flight Batching、Paged Attention、KV Cache、Chunked Prefill、Speculative Decoding、Advanced Quantization、Disaggregated Serving 等生产优化能力。(NVIDIA GitHub)
推理服务优化图
这些优化解决的是不同瓶颈：
技术 | 主要优化 |
Continuous Batching / In-flight Batching | 高并发下减少 GPU 空转 |
PagedAttention / Paged KV Cache | 降低 KV cache 内存碎片 |
Chunked Prefill | 长上下文 prefill 不阻塞其他请求 |
Prefix Cache | 重复前缀少算一次 |
CUDA Graph / optimized kernels | 降低 kernel launch 和算子开销 |
Quantization | 减少显存和计算 |
Tensor / Pipeline / Expert Parallelism | 多卡分布式推理 |
Disaggregated Prefill/Decode | 分离长上下文处理和解码资源 |
15. 基座侧优化五：Speculative Decoding 加速解码
Speculative decoding 的核心是：用小 draft model 先猜多个 token，再让大 target model 一次验证多个 token。TensorRT-LLM 文档解释，speculative sampling 目标是在一个 forward pass iteration 中生成多个 token，从而降低平均 per-token latency；它的收益依赖任务，代码补全、摘要、文档问答、多轮聊天等高 n-gram overlap 场景更容易受益。(GitHub) NVIDIA 技术博客给出的内部测量中，TensorRT-LLM speculative decoding 在 Llama 3.1 405B / 70B 目标模型实验里带来 2x–3x 以上的 token throughput 提升。(NVIDIA Developer)
适合 speculative decoding 的 Agent 场景
场景 | 适合度 |
代码补全 | 高 |
文档总结 | 高 |
代码 patch 生成 | 中高 |
严格 JSON 工具参数 | 中 |
高创造性写作 | 不稳定 |
每步都很短的分类任务 | 收益有限 |
16. 工程侧 vs 基座侧：一张排查表
症状 | 优先看工程侧 | 再看基座侧 |
每次任务都跑十几轮 | step budget、退出条件、计划质量 | 小模型路由、reasoning budget |
首 token 很慢 | prompt 长度、缓存前缀、RAG chunk | prompt cache、chunked prefill、KV cache |
输出阶段很慢 | max_tokens、verbosity、答案模板 | speculative decoding、量化、推理引擎 |
工具等待很久 | 并行工具、timeout、连接池、沙箱预热 | 无 |
RAG 很慢 | 减少 topK、条件 rerank、语义缓存 | embedding/rerank 模型加速 |
经常重试 | strict schema、错误结构化、权限策略 | tool calling 模型能力 |
高并发下变慢 | 队列、限流、异步、缓存 | continuous batching、autoscaling |
长会话越来越慢 | compaction、工具结果摘要 | prompt cache、长上下文优化 |
多 Agent 反而更慢 | 减少 handoff，只并行独立任务 | 模型路由和并发资源 |
17. 一套可落地的优化顺序
第一阶段：低成本立刻见效
- 加 trace：记录每轮 LLM、工具、RAG、token、重试。
- 设置
steps上限和超时。
- 限制
max_tokens和输出格式。
- 工具结果结构化，日志不要全文进上下文。
- 简单任务跳过 RAG 和多 Agent。
- 给 RAG 加语义缓存和 topK 限制。
第二阶段：Agent 编排优化
- Router → Plan → Execute 分层。
- 只读 Explore/Scout 并行查找。
- 有依赖工具走 DAG，无依赖工具并发。
- 长任务 checkpoint。
- 失败重试升级模型，而不是默认大模型。
- Prompt 前缀稳定化，提高 cache hit rate。
第三阶段：推理与基座优化
- Hosted API：开启/利用 prompt caching、合理设置 cache retention。
- 自托管：vLLM / TensorRT-LLM 类推理引擎。
- 开启 continuous batching、prefix cache、chunked prefill。
- 针对生成类任务试 speculative decoding。
- 对低风险场景使用量化模型。
- 高并发场景做 autoscaling、队列隔离、请求分级。
18. 最后总结
Agent 耗时过长，本质上是“循环控制 + 工具编排 + 上下文管理 + 推理服务”共同作用的结果。
工程侧的核心是：
少走步骤、少传上下文、少串行等待、少无效重试、少用大模型。
基座侧的核心是：
更高缓存命中、更快 prefill、更快 decode、更高吞吐、更稳尾延迟。
成熟 Agent 产品的共同趋势也很清晰：Claude Code 强调 hooks、subagents、background tasks 和 checkpoints；OpenCode 强调 Plan/Build 分工、权限、模型覆盖和 step 限制；OpenClaw 强调 gateway、多通道、多 agent routing、sandbox、compact/trace/usage 等运维控制。(Anthropic)
真正生产级的优化不是把模型换大，而是把 Agent 做成一个可观测、可预算、可并行、可缓存、可回退的执行系统。
分享