复盘一次把对话"首字延迟"从两秒压到六百毫秒的过程。先把关键认知摆这：用户对Agent快不快的感受，几乎全在"按下回车到第一个字蹦出来"这段时间，后面字快不快反而没那么敏感。所以优化首token,性价比最高。

先解释流式为啥重要。 不开流式，模型得把整段答案生成完才一次性返回，用户盯着空白等三五秒，体感极差。开了流式，生成一个字就推一个字，用户看到光标在动、字在往外冒，哪怕总时长一样，等待焦虑小很多。这是第一刀，必须开。但开了流式还慢，就是首token本身的问题了。

我们对话助手早期首字延迟实测稳定在两秒上下，用户反馈"反应迟钝"。拆开测,时间花在这几处，按耗时排：

1. 前置RAG检索太重。 每次回答前都去知识库召回,而且我贪心召回了Top10块,检索加上把十大段塞进prompt,光这步就吃掉七八百毫秒。改成Top3,够用,这步省了一半多。不是所有问题都需要那么多上下文。

2. prompt太长,首token自然慢。 模型得先把超长的system和历史读进去才开始吐第一个字。我把啰嗦的system提示精简了三分之一,无关示例删掉,首token明显提前。输入越短,第一个字越快。

3. 不必要的前置节点串太长。 我原来在出字前还串了意图分类、敏感词过滤好几个节点,全是同步阻塞,累加起来又是几百毫秒。把能并行的并行,能后置的后置（比如敏感词改成边流式边检），关键路径缩短。

4. 模型选型也有讲究。 同样的问题,小一点、快一点的模型首token明显更早。我把简单对话路由给快模型,复杂的才上大模型,平均首字延迟又降一截。不是每句话都值得用最大的模型。

四刀下来,首字延迟从约2秒到约600毫秒,用户那边"卡顿"的反馈基本没了。

得说个没解决干净的：高峰期模型服务本身排队,首token还是会偶发抖到一秒多。这部分是上游的事,我能做的是加个"正在思考"的占位动效先顶住,体感上糊弄过去——治标。真实情况就是,客户端优化有天花板,撞上服务端拥塞我也只能缓和。

这套优化是在一个零代码、还能发布成API的智能体平台上调的,流式开关、召回数量、节点编排都可视化配,改完即时看效果,省了反复改代码发版。它的流式默认就开,这点省心,但召回数量、节点顺序这些影响首token的细节,平台不会替你判断该怎么取舍,得自己测。

收尾一句:优化对话性能,先盯首token,再谈别的。用户的耐心,大半耗在第一个字之前。

（模型API我接的讯飞 MaaS,现成多档调用,快慢模型按需切,没自己部署推理。）