[Bug]:执行工具调用是，解析的参数发生异常（When executing the tool call, an exception occurred in the parsed parameters）

[junefsh]

Describe the [bug]
执行工具调用是，解析的参数发生异常（When executing the tool call, an exception occurred in the parsed parameters）
详细参考附件

To Reproduce
Steps to reproduce the behavior:
通过Langfuse 看到的信息,下面的一次tool_call因参数解析出问题，变成了两次tool_call，最终导致调用失败
（Based on the information obtained through Langfuse, the following issue occurred: due to a problem with parameter parsing, one tool_call was mistakenly executed twice, ultimately resulting in a failed call）
----------------------------trace info---------------------------
...
}
2: {4 Items
type: "tool_call"
id: "call_28281576ef7241a397970399"
name: "retrieveFromMemory"
arguments: "{"keywords": ["关注", "重点", "部类", "品牌", "偏好", "负责"]"
}
3: {4 Items
type: "tool_call"
id: "streaming_1776130606735"
name: "retrieveFromMemory"
arguments: "}"
}
]
finish_reason: "tool_calls"

----------------------------trace info---------------------------
Expected behavior
A clear and concise description of what you expected to happen.

Error messages
Error: Parameter validation failed for tool 'retrieveFromMemory': Schema validation error: Invalid input
Please correct the parameters and try again.

Environment (please complete the following information):

• AgentScope-Java Version: [e.g. 1.0.11, check your pom.xml dependency version or run mvn dependency:tree | grep agentscope-parent:pom(only mac/linux)]
• Java Version: [e.g. 17]
• OS: [e.g. macos, windows]

Additional context
Add any other context about the problem here.

[junefsh]

[LearningGp]

Seems like an ID mismatch is causing accumulation issues. Please share the model and formatter types.

[junefsh]

Seems like an ID mismatch is causing accumulation issues. Please share the model and formatter types.

AgentScope-Java Version: 1.0.11
Java Version: 21
OS: windows
model:qwen3.5-397b-a17b use stream use shortmem and longmem

[CarsonLay]

Summary

When using OpenAIChatModel with streaming mode, some LLM APIs (e.g., Qwen3.5-397B-A17B) intermittently return malformed tool_call chunks where the last arguments: "}" fragment incorrectly carries a non-null name field. This causes OpenAIChatFormatter to generate a streaming_ prefixed ID instead of treating it as a fragment, leading to tool parameter accumulation failure.

Environment

• AgentScope Java version: 1.0.11
• Model: Qwen3.5-397B-A17B (via OpenAI-compatible API)
• Formatter: OpenAIChatFormatter
• Streaming mode: enabled

---

Expected vs Actual Behavior

Expected Streaming Tool Call Format

According to OpenAI streaming API specification, tool_call chunks should follow this pattern:

Chunk	id	name	arguments	Purpose
#1	"call_xxx"	"tool_name"	""	First chunk with complete metadata
#2	null or absent	null or absent	"{"	Argument fragment
#3	null or absent	null or absent	"\"param\": value"	Argument fragment
#4	null or absent	null or absent	"}"	Last bracket fragment

Key rule: Fragments (chunks after the first) should NOT carry name field, or name should be null.

Actual (Malformed) Response

data: {"delta":{"tool_calls":[{"id":"call_d1e415084afd4d8791822187","type":"function","index":0,"function":{"name":"retrieveFromMemory","arguments":""}}]}}

data: {"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]}}

data: {"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"keywords\": [\"负责品牌\", \"职责\"]"}}]}}

data: {"delta":{"tool_calls":[{"id":null,"type":"function","index":0,"function":{"name":"retrieveFromMemory","arguments":"}"}}]}}  ← MALFORMED

Malformed chunk #4:

• id: null ✓ (expected for fragment)
• name: "retrieveFromMemory" ❌ Should be null or absent
• arguments: "}" ✓ (expected last bracket)

---

Problem Analysis

Where the Issue Occurs

In OpenAIResponseParser.java (around lines 464-528), the logic for distinguishing new tool_call vs fragment is:

// Lines 464-468: Generate streaming ID when id is null
if (toolCallId == null) {
    toolCallId = "streaming_" + System.currentTimeMillis();  // Generated ID
}
if (toolName == null) {
    toolName = "";  // Convert null to empty string
}

// Lines 484-528: Branch logic
if (!toolName.isEmpty()) {
    // Has name → Treat as NEW tool_call with streaming_ ID  ← WRONG PATH
    contentBlocks.add(ToolUseBlock.builder()
        .id(toolCallId)       // "streaming_xxx"
        .name(toolName)       // "retrieveFromMemory"  
        .content(arguments)   // "}"
        .build());
} else if (!arguments.isEmpty()) {
    // No name → Treat as fragment with __fragment__ placeholder  ← CORRECT PATH
    contentBlocks.add(ToolUseBlock.builder()
        .id("")
        .name("__fragment__")
        .content(arguments)
        .build());
}

Accumulation Failure in ToolCallsAccumulator

ToolCallsAccumulator.determineKey() uses ID as primary key for merging:

private String determineKey(ToolUseBlock block) {
    // Priority 1: Use tool ID if non-empty
    if (block.getId() != null && !block.getId().isEmpty()) {
        return block.getId();  // Different IDs → Different keys → No merge!
    }
    // ...
}

Chunk	Generated Block	Key in Accumulator
#1	id=call_xxx, name=retrieveFromMemory	call_xxx
#4	id=streaming_xxx, name=retrieveFromMemory	streaming_xxx

Result: Two different keys → No merging → Chunk #4's "}" not appended → Incomplete JSON "{"keywords": [..." missing closing } → Parameter parsing failure.

---

Impact

• Tool execution fails due to incomplete/unparseable JSON arguments
• User receives error instead of expected tool result
• Langfuse tracing shows two different tool_call IDs (call_xxx and streaming_xxx) for the same tool invocation

---

Root Cause

The issue originates from the API/model side: the streaming response incorrectly includes name field in a fragment chunk that should only contain argument content. This violates the OpenAI streaming tool_call format specification.

---

Reproduction

The issue can be reproduced with any OpenAI-compatible API endpoint when:

1. Streaming mode is enabled
2. The model decides to call a tool
3. The API intermittently returns malformed chunk

[Alexxigang]

I reproduced this locally by tracing OpenAIResponseParser and ToolCallsAccumulator. The malformed final arguments: "}" chunk is being treated as a new tool call when it arrives with a non-null name, so the closing fragment never merges back into the original call. I'm working on a fix that normalizes these malformed trailing chunks into fragments and I'll add regression coverage for the parser and end-to-end accumulation path.

[Alexxigang]

Opened PR: #1223

This normalizes the malformed named trailing fragment into a tool-call argument fragment and adds regression coverage across parser, formatter, and accumulation paths.