执行摘要
本PR修复了vLLM项目中Responses API在流式处理多自动工具调用时，参数错误合并的bug。通过更新事件处理逻辑和增强测试覆盖，确保每个工具调用的参数独立处理，提升API正确性。影响范围限于非Harmony路径，推荐工程师关注流式状态管理设计。
功能与动机
PR旨在解决Responses API中一个具体问题：当使用tool_choice="auto"进行流式处理时，多个工具调用的function_call事件会将参数合并为一个function_call_arguments，导致数据错误。如PR body所述，修复后确保每个工具调用的参数独立，并已验证在Qwen和Gemma等模型上的兼容性。
实现拆解
变更集中在三个关键文件：
- tests/entrypoints/openai/responses/test_function_call.py：扩展现有测试，添加第二个工具
get_time，验证多个工具调用的参数独立处理。关键代码片段：
python
assert len(tool_call_items) >= 2
assert len(arguments_done_events) >= 2
assert len(completed_events) >= 2
- tests/entrypoints/openai/responses/test_serving_responses.py：新增
TestAutoToolStreaming测试类，模拟多工具调用流式事件序列，使用mock parser验证事件生成逻辑。
- vllm/entrypoints/openai/responses/serving.py：在
_process_simple_streaming_events函数中引入current_tool_call_index跟踪，当检测到新工具调用时（tool_call.index != current_tool_call_index），先关闭前一个工具调用事件再开始新的。关键逻辑包括：
- 收集前一个工具调用的参数并发送
ResponseFunctionCallArgumentsDoneEvent。
- 重置
previous_delta_messages以避免参数交叉污染。
- 增量更新
current_output_index和current_item_id。
评论区精华
review讨论中突出了几个技术要点：
- 内容丢失风险：gemini-code-assist[bot]指出，如果单个delta同时包含文本和工具调用，当前逻辑可能忽略文本内容，建议优化事件处理分支。
- assert语句风险：同一bot建议替换assert为错误处理，避免模型输出异常时服务器崩溃。
- 重构建议：sfeng33评论提到“I'm working on migration to the abstract_parser this week”，建议限制PR到bugfix而非扩展parse_delta，最终PR被简化为只处理auto工具选择，体现了在重构背景下的敏捷决策。
风险与影响
技术风险：
- 内容丢失：serving.py中事件处理逻辑可能遗漏delta中的文本内容，需后续监控或修复。
- assert使用：代码中assert语句在异常情况下可能引发未处理错误，建议在迭代中替换为更健壮的错误处理。
影响评估：修复显著提升了Responses API在多工具调用场景下的正确性，用户将获得独立的工具参数流。影响范围可控，仅限于流式处理和auto工具选择，不破坏向后兼容性。测试覆盖增强降低了回归风险。
关联脉络
本PR是vLLM工具调用和解析器演进线的一部分。历史PR如#39728（重构parse_delta）和#39446（迁移chat completion流式处理）显示团队正在统一解析器路径，本PR的简化修复与之协调。关联bugfix如#39679（Gemma4解析器）共享类似的测试模式和模块关注点。整体趋势指向frontend和tool-calling模块的持续优化，以提升流式处理可靠性。
参与讨论