用途：为 LLM 智能体做延迟预算与工程化。核心观点是延迟是产品特性，应在构建前预算，而非事后测量；多数交互场景下 2 秒的 B+ 回答优于 12 秒的完美回答。
适用时机：构建面向用户的聊天、语音或智能体 UI；智能体“能用但慢”；选模型档位时准备默认用最大模型；新增子智能体、反思步骤或护栏并希望保持响应速度。
时间去向（按典型量级）：工具往返（网络加后端，串行循环常占 50–80% 墙钟时间）、首 token 时间 TTFT、token 生成（输出 token 数 × 每秒 token 数）、预检开销（鉴权、嵌入查询、缓存读取）、客户端渲染。不清楚哪项占主导就无法优化，需追踪。
决策流程：确定 p50 与 p95 延迟目标；面向用户且交互式则默认流式，TTFT 即感知延迟；循环内工具调用若相互独立则并行；按任务选合适模型档位，路由、分类、格式化通常小模型足够；有重规划或反思步骤则限制迭代次数；查询时 RAG 需单独测量检索延迟。
五条规则：按阶段分配预算，各阶段预算之和等于总预算；默认并行，仅在存在真实数据依赖时串行；流式输出，交互 UX 中 TTFT 比总时长更重要；模型按需选档，推理与综合用大模型，其余用小模型；缓存静态前缀，缓存命中常可减半 TTFT。
应警惕的反模式：默认串行、所有步骤用同一模型、非流式 UX、无可追踪的延迟分解、热路径中的反思、热路径上的长上下文窗口。
流式要点：模型一产出 token 就流式输出，不要为“整理”而缓冲；需要后处理时可先流占位再替换，或流入可容忍更新的结构化 UI；流中工具调用会打断 TTFT，需专门设计。
需向用户确认：p50/p95 目标毫秒数、等待时用户看到什么、哪些步骤可并行、各步骤模型档位及原因、最慢工具的 p95 延迟、延迟是否呈双峰。
硬性要求：没有延迟预算的步骤就是没有预算；总 p95 是结果而非目标，目标落在各阶段上。
限制：资料未提供具体实现代码、框架配置、安装命令或价格信息；相关参考文档（streaming.md、model-routing.md、parallel-tools.md）与关联技能（agent-cost-modeling、agent-architecture-patterns、prompt-caching、agent-observability、rag-vs-context-engineering）仅以名称列出，具体内容暂未提供。