网易二面：LLM 流式响应怎么逐 token 处理？三层管道与工具调用的坑
文章目录
- 前言
- 一、三层管道：字节流 → 事件流 → 状态机 → 业务逻辑
- 二、第一层：字节流 → 事件流
- 三、第二层：事件流 → 状态机
- 四、关键原则：只有块结束才能保证完整
- 五、第三层：状态机 → 业务逻辑
- 六、工具调用参数为什么不能中途 parse
- 七、从架构师视角看流式处理的几个工程取舍
- 八、面试话术：考官想听的是什么
- 总结
前言
前几天有个同事去面网易的 Agent 开发岗,一面聊得挺顺利,二面面试官问了一个看起来很基础的问题:
👔 开发 Agent 的时候,LLM 返回的是流式响应,你应该用什么方式逐 token 处理输出?
他想都没想就答:“用 stream 接口嘛,for 循环遍历 text_stream,每个 token 到了就处理。”
面试官点点头,又问:
👔 那工具调用的参数也是流式返回的,你也是每个 token 到了就 parse 吗?
他愣了一下:“工具调用……不也是文本吗?应该差不多吧?”
面试官没直接说对不对,又问:
👔 那如果 JSON 只来了一半,你 parse 会怎样?
他挠了挠头说会报错。面试官接着问:
👔 那你怎么办?等它来完?怎么判断它来完了?
他突然意识到自己从来没认真想过这个问题——stream 接口天天用,但底层到底发生了什么,他其实不清楚。
读完这篇文章,你能搞明白:
- 流式处理的三层管道——字节流→事