这周外部素材跟语音 Agent 关系不大，HN 上全是 agent 编排、上下文管理、数学发现那类东西。我不打算硬凑。语音延迟预算这个事，值得单独聊透。
先划一个共识：语音对话里，用户能容忍的静默大概在几百毫秒到一秒出头这个区间，具体阈值取决于人、语境、还有刚才那句话是不是问句。这个数字如果你要写进论文，得自己跑实验测，不同团队测出来的方差很大。但工程上有个粗糙的经验值：超过 700 毫秒到 1 秒，用户就开始觉得"卡了"。别问我出处，这是我在多个语音产品里观察到的共同模糊区间，不是某个标准。
问题在于，这个预算要分三段花：自动语音识别（ASR）的尾点检测 + 推理、大模型首 token、语音合成（TTS）首帧。每段都吃延迟。
ASR 这块，流式识别已经把字延迟压到几百毫秒内了，但真正的坑是尾点检测——系统要等用户说完才能触发模型，VAD 太灵敏会把话截断，太迟钝就把预算吃光了。这里的优化空间比模型推理大。
LLM 首 token 延迟，受推理引擎、prompt 前缀长度、模型大小影响。语音场景通常用不了太重的模型，因为你要在预算内完成推理。本地小模型首 token 能到 100-200 毫秒，云端大模型可能 300-500 毫秒，但网络往返还要加几十到一百毫秒。
TTS 首帧，现在流式合成基本能做到 100-200 毫秒出第一帧。但注意，TTS 的"首帧"不代表句子第一个词已经开始说了，有些引擎会缓冲一小段再开口，防止卡顿。
把这三段加起来，理想情况 500-700 毫秒，勉强在阈值内。一旦工具调用进场，预算直接超支。你要让模型检索、调 API、查数据库，再等结果回来再决定说什么，这中间的延迟是秒级的，用户早就"喂？喂？"了。
于是业界有个说法：语音 Agent 里，工具调用要么先说话再干活，要么干脆异步。
先说话再干活，就是模型开口说"我查一下"。这句话本身就是在告诉用户"我没死，我在忙"。它把用户的等待心理时钟重置了。这个技巧在电话客服 IVR 里用了二十年，现在搬到 LLM 语音 Agent 里，依然有效。
异步方式，是模型说"查好了我会通知你"，然后挂断或转后台，之后通过推送、短信、回拨来交付结果。这更适合那些本来就不需要实时对话的场景，比如订餐、查快递、预约。
但大多数场景，你想要的是一个能在对话里完成任务的 Agent。那工具执行期间怎么办？
我的建议是插入自然填充语。不是"请稍候"，而是跟上下文相关的话。用户问"帮我看看这周跟老张的会"，你可以说"我看下日程"，然后边说边查。或者干脆用语气词："嗯……我记着周三好像有。"这种半句不完整的填充，让用户知道你在思考，不是死机。
填充语要看起来自然，不能每轮都一样。如果用户连续问三个问题你都回"让我想想"，用户会开始烦躁。可以变化："我查一下""稍等我看眼""这个我还得确认下"。
还有一个思路，是并行触发。用户的话还没说完，ASR 已经给了部分结果，你就可以让模型开始推理了。这叫 speculative execution，跟 CPU 分支预测一个思路。等尾点确认，推理大概率已经完成，TTS 马上接上。这个技术不是所有语音栈都支持，但它是压延迟的最大杠杆。
反过来看，这周 HN 上那个 "Agent Is Not the Model" 写得其实挺对路，但跟语音没关系。它讲的是 agent 的行为由 harness 决定，模型只是其中一个组件。放到语音场景更明显：你的延迟预算分配，本质上就是 harness 的设计问题。模型再快，VAD 切得烂、TTS 缓冲大、工具同步调用，体验照样烂。
我不信语音 Agent 会把工具调用做成同步阻塞还假装体验好。谁这么做谁用户跑光。
所以我的判断是：语音 Agent 的延迟预算，核心不是把三段延迟各自压到极致，而是设计一个不让用户感知到"系统在等待"的交互流。要么先说话，要么异步化，要么并行触发。这三招比任何模型优化都管用。
哦对了，如果你的应用本身就不要求低延迟，比如播客摘要、会议纪事这种非实时场景，当我没说。但那是另一码事。
说实话，这周外部没什么新料好引。OpenAI 那个 Cursor 决定，跟语音半毛钱关系没有。HN 上 400 多分的 agent.md 讲的是给 LLM 写说明文件，也挺远。唯一沾边的是 ArXiv 那篇 《Agentic Context Management》，讲记忆和成本当架构问题，但语音延迟不完全是 memory/cost 的问题，更多是 IO 和交互设计的问题。要硬引也能引一句"上下文管理会影响 agent 的响应时间"，但这是常识，没必要。
我宁愿把篇幅留给真正能落地的经验。
最后给个自查清单：如果你在做一个语音 Agent，打开延迟日志，按三个阶段分别测 p50 和 p95。如果 ASR 尾点平均超过 400 毫秒，先修 VAD；如果 LLM 首 token 超过 500 毫秒，要么换模型要么做 speculative；如果 TTS 首帧超过 300 毫秒，查是不是缓冲配置太保守。修完三段，再测整体端到端，大概率还是超 1 秒——这时候加填充语，用户体感立刻不一样。
我不信这个流程做下来还会卡。