[Bugfix] Fix DeepSeekV31ToolParser to correctly parse multiple tools in non-streaming output

[taohui]

…ming output

Purpose

Problem

In non-streaming output mode, DeepSeekV31ToolParser fails to correctly parse multiple tool calls.
For example, given the input:

<｜tool▁call▁begin｜>get_current_time<｜tool▁sep｜>{}<｜tool▁call▁end｜>
<｜tool▁call▁begin｜>big_number_add<｜tool▁sep｜>{"a": 923, "b": 24922}<｜tool▁call▁end｜>

The parser incorrectly extracts:

• function_name: "get_current_time<｜tool▁sep｜>{}<｜tool▁call▁end｜><｜tool▁call▁begin｜>big_number_add"
• function_arguments: '{"a": 923, "b": 24922}'

This merges two separate tool calls into one, breaking downstream processing.

Solution

• Update the regex and parsing logic to correctly identify each <｜tool▁call▁begin｜> ... <｜tool▁call▁end｜> block independently.
• Ensure that each tool call is parsed into its own function_name and function_arguments, even when multiple tools appear consecutively.

Result

Now, the same input correctly parses into:

1. function_name: "get_current_time", arguments: {}
2. function_name: "big_number_add", arguments: {"a": 923, "b": 24922}

Test Plan

I have added test cases in test_deepseekv31_tool_parser.py specifically covering the issue described above.
The tests verify that multiple tool calls in non-streaming output are parsed correctly,
ensuring each tool's function name and arguments are extracted independently.

Test Result

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[gemini-code-assist]

Code Review

This pull request effectively addresses a bug in DeepSeekV31ToolParser where multiple tool calls in non-streaming mode were parsed incorrectly. The change from a greedy (.*) to a non-greedy (.*?) quantifier in the regular expression is the correct and standard solution for this type of parsing issue. The addition of a new test file with specific unit tests for single and multiple tool calls is excellent, ensuring the fix is robust and preventing future regressions. The code is clean and the changes are well-scoped. Overall, this is a high-quality contribution.

[chaunceyjiang]

Thanks~

LGTM

/cc @aarnphm PTAL