执行摘要

本 PR 修复了 vLLM Rust 前端中 DeepSeek V4 模型的对话渲染 bug。原渲染器无法正确处理相邻的用户消息和工具响应，导致生成多个连续的 <｜User｜> 角色 token，与模型参考编码不一致。修复通过重构合并逻辑，将所有构成用户内容的消息统一处理，并引入高效的工具调用排序跟踪，确保生成 prompt 的格式正确。

功能与动机

根据 PR body 描述，DeepSeek V4 模型的参考编码会将相邻的工具响应和用户消息合并到一个 <｜User｜> 轮次中，内容用双换行连接。之前的 Rust 实现只合并连续工具响应，当工具响应后紧跟用户消息时，会产生如下非规范编码：

<｜User｜><tool_result>result</tool_result><｜User｜>follow-up

<｜User｜><tool_result>result</tool_result>

follow-up

实现拆解

1. 统一用户内容类型判断：引入 is_user_content_entry 函数，抽象判断一个消息是否为构成用户内容块的类型（User 或 ToolResponse）。该函数被用于 render_request 主循环的跳过逻辑（is_following_user_content）、用户内容块范围计算（user_content_block_bounds）以及助手转换判断（next_rendered_entry_is_assistant_or_end），替代了之前分散且不完整的条件判断。
2. 合并渲染入口：在 render_request 的消息循环中，将原本分开处理 User 和 ToolResponse 的分支合并，统一调用新的 render_user_content_block 函数。此函数负责将一段连续的用户内容消息作为一个整体渲染。
3. 重写用户内容块渲染函数：render_user_content_block 函数取代了原 render_user_message 和 render_tool_response_block。它首先计算当前块的边界，然后按顺序遍历块内消息，输出用户文本或经排序的工具结果（使用传入的 tool_call_order 参数）。
4. 优化工具调用顺序跟踪：在 render_request 中引入 last_tool_call_order 变量，在处理助手消息时更新。该变量被传递给 render_user_content_block，避免了每次渲染时遍历历史消息查找顺序的 O(n) 开销，确保整体渲染为 O(n)。排序函数 sorted_tool_response_indices 内部也增加了快速返回路径。
5. 补充测试用例：在 tests.rs 中新增了三个测试，分别验证“工具响应+用户”、“用户+用户”以及“混合内容（工具与用户交错）且带排序”的场景，确保渲染输出格式完全正确。

rust/src/chat/src/renderer/deepseek_v4/encoding.rs

核心渲染逻辑所在文件。本次变更重构了消息合并与排序的整个流程，是修复 bug 的主体。

关键源码片段

rust/src/chat/src/renderer/deepseek_v4/encoding.rs

核心渲染逻辑所在文件。本次变更重构了消息合并与排序的整个流程，是修复 bug 的主体。

// 重构后的用户内容块渲染函数
// 将相邻的 User 和 ToolResponse 消息合并输出为一个 <｜User｜> 轮次
fn render_user_content_block(
    out: &mut String,
    messages: &[ChatMessage],
    message_index: usize,
    tool_call_order: &HashMap<String, usize>, // 传入最新的工具调用顺序
) -> Result<()> {
    // 计算当前连续用户内容块的起止范围
    let (block_start, block_end) = user_content_block_bounds(messages, message_index);
    // 预先过滤并准备排序后的工具响应索引（如果需要）
    let mut sorted_tool_indices =
        sorted_tool_response_indices(messages, block_start, block_end, tool_call_order).into_iter();
​
    out.push_str(USER_SP_TOKEN);
    // 按顺序遍历块内的每一条消息
    for (offset, message_index) in (block_start..block_end).enumerate() {
        if offset > 0 {
            out.push_str("
​
"); // 相邻内容用双换行连接
        }
        match &messages[message_index] {
            // 直接输出用户文本
            ChatMessage::User { content } => write_chat_content(out, content)?,
            // 工具响应则按排序后的顺序输出
            ChatMessage::ToolResponse { .. } => {
                let sorted_index = sorted_tool_indices
                    .next()
                    .expect("tool response block should include this tool message");
                let ChatMessage::ToolResponse { content, .. } = &messages[sorted_index] else {
                    unreachable!("sorted tool response index should reference a tool message");
                };
                write_tool_result(out, content)?;
            }
            _ => unreachable!("user content block should only contain user content messages"),
        }
    }
    Ok(())
}

评论区精华

本次 PR 的讨论集中在一个自动化的性能风险提示上，形成了高效的协作修复闭环：

Codex Review (自动化工单): "For long conversations containing many separate user turns, this now invokes sorted_tool_response_indices even when the block contains no tool responses; that function calls last_tool_call_order_before, which walks the entire preceding history. An alternating user/assistant history therefore regresses from linear to quadratic rendering time."

BugenZhao (维护者): "This seems valid. Would you add a commit to improve this?"

BugenZhao: "I've added that! https://github.com/vllm-project/vllm/pull/53281/changes/134f111b6438d22a4babd51fa7f718a0b1613e64"

reidliu41 (作者): "Sorry for the late reply — I just saw this. Thanks for following up and fixing it!"

风险与影响

1. 回归风险（中）：render_request、is_following_user_content 等核心函数的逻辑被修改，虽然新增了测试，但复杂的对话历史组合（如多个工具调用后跟多个用户消息）的边缘情况可能仍有未覆盖的盲点。
2. 性能风险（低，已修复）：原始实现存在二次时间复杂度风险，但合并的最终版本已包含优化，确保渲染过程为线性复杂度。
3. 兼容性风险（低，可接受）：修复后生成的 prompt 格式与旧格式不同，但这是向正确规格的对齐。对于依赖旧（错误）格式的下游处理可能产生影响，但这属于必要的修正。

关联脉络

本 PR 属于 vLLM Rust 前端（vllm-chat 库）对 DeepSeek V4 模型支持的一部分，专注于解决工具调用场景下的 prompt 格式合规性问题。它与近期的 PR#54633（修复 MiniCPM-V 的路由问题）同属前端渲染逻辑修复，体现了团队对渲染正确性的持续关注。其优化思路（在主循环中跟踪状态避免重复计算）也可能为其他渲染器的性能优化提供参考。