很多 AI agent 系统最后并不是死在总耗时，而是死在 TTFT，也就是 time to first token。用户最先感知到的不是“这次任务 4 分钟完成”，而是“我发出请求后 20 秒完全没反应”。在这 20 秒里，哪怕系统其实正在努力 provision 环境、读取 session、组织上下文，用户也只会觉得它挂了。
这就是为什么 TTFT 和冷启动优化值得单独治理。它不是前端体验修饰，而是直接影响取消率、人工接管率和用户对 agent 是否“可用”的基本判断。
建议先结合 AI agent Deadline 与超时预算、AI agent Worker Lease 与心跳机制、AI agent Orchestrator 与 Sandbox 解耦 和 AI agent 多执行环境路由 一起看。
用户不是等不到结果才流失，而是等不到第一口反馈就离开
TTFT 通常由四段拼起来：
| 组成部分 | 常见来源 |
|---|---|
| 调度等待 | 队列排队、lease 竞争、admission policy |
| 上下文准备 | session slice、memory fetch、context packing |
| 环境准备 | sandbox、browser、VPC runner provision |
| 首次推理 | 模型握手、首轮 reasoning、首 token 返回 |
如果你只盯模型 latency，很容易把真正的冷启动瓶颈看漏掉。
真正有效的优化，通常是“延后重型准备”，不是“预热一切”
很多系统一收到请求，就先把最重的环境全拉起来：容器、浏览器、repo clone、私网 tunnel、依赖缓存。这样做确实能保证后面用得上时已经就绪，但代价是所有请求都先为可能用不到的能力买单。
更稳的优化方向通常是：
- 先由 orchestrator 在轻量上下文下完成任务分类
- 确认需要重环境后再 provision runner
- 首轮先返回“正在做什么”的心跳或结构化进度
这套思路的关键不是偷懒，而是把 TTFT 优化建立在任务分层上，而不是粗暴地把整套环境全预热。
失败案例：系统其实没挂，但因为 30 秒无输出，用户和上游都把任务取消了
某个代码 agent 在接到复杂任务后会先 provision sandbox、同步仓库、载入 session、读取相关文件，然后才开始首轮推理。整条链路虽然最终成功，但前 30 秒完全无输出。结果是：
- 用户以为系统没工作，主动取消
- 上游服务把任务判定为超时失败
- 团队误以为模型过慢，开始错误地换更快模型
真正的瓶颈其实是环境准备和上下文组织，而不是模型本身。修复后，团队做了三件事：
- 对重任务先发出“正在准备环境”的 heartbeat
- 把 repo hydrate 延后到确认需要代码执行后再做
- 把 session 全量读取改成按 slice 读取
最后总完成时长变化不大，但取消率明显下降。因为用户终于看到了系统在工作。
不要为了降 TTFT，把隔离和安全一并削掉
TTFT 优化最常见的错误，是把“更快”理解成“提前把一切打开”。例如：
- 让所有会话共享预热好的高权限环境
- 长期保活浏览器和私网连接，不区分租户
- 在首轮就把全部凭证和工具能力灌给 agent
这些做法短期会让首 token 更快，但会把隔离和权限边界一起削平。真正可接受的优化，应该优先来自：延迟 provisioning、轻量心跳、上下文切片、能力分级，而不是降低安全标准。
TTFT Checklist
- TTFT 是否被拆解为调度、上下文、环境和模型四段单独观测
- 轻任务是否不会被重型环境 provision 阻塞
- 系统是否在长冷启动阶段给出 heartbeat 或结构化进度
- session 和 context 是否按 slice 读取，而不是全量装载
- runner 是否只在确认需要时再启动，而不是默认全开
- TTFT 优化是否没有通过扩大共享权限或降低隔离来换取速度
应该优先优化哪一段
对 AI agent 来说，TTFT 优化最重要的不是“把模型换快一点”，而是先弄清首 token 之前到底花在了哪里。只有把调度、上下文和环境准备拆开看，你才会发现：很多“像挂了”的系统，其实不是推理慢，而是准备动作太重、太沉默、太不透明。
延伸阅读：
