superchat 是我写的一个实验性 chatbot，跑在 Emacs 里，接本地大模型。
老觉得它的回复特别缓慢，但没怎么发现。因为我一般是随口在里面问一句，然后就忙别的，等空了之后，再回头来看。
所以，我最近给它加了个 TTFT（首 token 时间）测量，想看看 LLM 响应速度到底怎么样。
第一个数字出来的时候我愣住了——首 token 要等 17 到 76 秒。
76 秒！够泡一杯手冲了，去一趟厕所，删 1000 行代码了！
第一反应是不是我的 Emacs 太慢了，加了几个观测函数，发现预处理只花了 0.008 秒。问题不在客户端
那肯定是 prompt 太长了。一查，164 到 596 tokens，3 到 7 条历史消息。也不长。
两个最大的嫌疑人都不对。我想了很久，决定还是再测一下 Ollama 真实的响应速度。
直接拿 curl 打 Ollama API，对比测试：
• think:true（默认） → TTFT 5.6 秒
• think:false → TTFT 0.31 秒
18 倍。qwen3.x 默认开 thinking，模型在 stream 之前把整条推理链跑完，在我这边看起来就是漫长的沉默。
修复只加了一行参数。修完之后同一场对话的 TTFT 降到了 2.78 到 2.95 秒。
但这整个过程让我想明白一件事。
如果我没有最开始加的那个打点，我可能现在还在怀疑 Emacs 太慢、prompt 太长、网络有问题。在完全错误的方向上消耗自己。
而这恰好是现在做 Agent 的人最缺的东西。
所有人都在讨论怎么让 Agent 更强——新的 model、新的 skill、新的工作流模式。但几乎没人问：**Agent 出了问题，你怎么知道它卡在哪？**
你的 Agent 烧了 200 万 token 完成一个任务，其中有多少是 thinking？有多少是 MCP 工具描述？有多少是重试？
你不知道。你只知道"好慢""好贵"。
Uber 刚把自己全年的 AI 预算在 4 个月内烧光。他们知道工程师的 token 花在哪吗？
Agent 需要更强的可观测性。
老觉得它的回复特别缓慢，但没怎么发现。因为我一般是随口在里面问一句，然后就忙别的，等空了之后，再回头来看。
所以，我最近给它加了个 TTFT（首 token 时间）测量，想看看 LLM 响应速度到底怎么样。
第一个数字出来的时候我愣住了——首 token 要等 17 到 76 秒。
76 秒！够泡一杯手冲了，去一趟厕所，删 1000 行代码了！
第一反应是不是我的 Emacs 太慢了，加了几个观测函数，发现预处理只花了 0.008 秒。问题不在客户端
那肯定是 prompt 太长了。一查，164 到 596 tokens，3 到 7 条历史消息。也不长。
两个最大的嫌疑人都不对。我想了很久，决定还是再测一下 Ollama 真实的响应速度。
直接拿 curl 打 Ollama API，对比测试：
• think:true（默认） → TTFT 5.6 秒
• think:false → TTFT 0.31 秒
18 倍。qwen3.x 默认开 thinking，模型在 stream 之前把整条推理链跑完，在我这边看起来就是漫长的沉默。
修复只加了一行参数。修完之后同一场对话的 TTFT 降到了 2.78 到 2.95 秒。
但这整个过程让我想明白一件事。
如果我没有最开始加的那个打点，我可能现在还在怀疑 Emacs 太慢、prompt 太长、网络有问题。在完全错误的方向上消耗自己。
而这恰好是现在做 Agent 的人最缺的东西。
所有人都在讨论怎么让 Agent 更强——新的 model、新的 skill、新的工作流模式。但几乎没人问：**Agent 出了问题，你怎么知道它卡在哪？**
你的 Agent 烧了 200 万 token 完成一个任务，其中有多少是 thinking？有多少是 MCP 工具描述？有多少是重试？
你不知道。你只知道"好慢""好贵"。
Uber 刚把自己全年的 AI 预算在 4 个月内烧光。他们知道工程师的 token 花在哪吗？
Agent 需要更强的可观测性。
