fix: 修复 v2 流式事件中 THINKING_BLOCK_END / MODEL_CALL_END / AGENT_END 的收尾顺序

[guslegend0510]

关联 Issue

• Closes [Bug]:v2 中流式出来的数据顺序有问题 #1634

变更内容

• 修复 v2 流式事件中 THINKING_BLOCK_END、MODEL_CALL_END、AGENT_END 顺序延后的问题。
• 在模型流中遇到非 ThinkingBlock 时立即结束 thinking block，确保 THINKING_BLOCK_END 早于正文流开始。
• 同步修正 summary 流的收尾顺序。
• 补充事件顺序测试，防止回归。

验证

• 已完成针对性编译验证。
• 新增测试覆盖 THINKING_BLOCK_END -> TEXT_BLOCK_START 的顺序约束。

[codecov]

Codecov Report

❌ Patch coverage is 82.05128% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...e/src/main/java/io/agentscope/core/ReActAgent.java	82.05%	2 Missing and 5 partials ⚠️

📢 Thoughts on this report? Let us know!

[AgentScopeJavaBot]

🤖 AI Review

This PR fixes the ordering issue of THINKING_BLOCK_END, MODEL_CALL_END, and AGENT_END events in v2 streaming. The core problem was that ThinkingBlockEndEvent was only emitted in the stream's finalization phase (endEvents), causing it to appear after subsequent block events (e.g., TextBlockStartEvent) instead of immediately when the model transitions away from thinking. The fix introduces a thinkingEnded guard flag and an emitThinkingBlockEndIfNeeded() helper that closes the thinking block eagerly — both when a non-thinking block arrives mid-stream and at stream finalization. The same pattern is applied symmetrically to the summary stream. A targeted test validates the corrected event ordering.

[alexsand1]

还是有问题 事件还是乱序的 工具调用 还是乱序的 主要问题是代码
Flux endEvents =
Flux.defer(
() -> {
List events = new ArrayList<>();
if (textStarted.get()) {
events.add(new TextBlockEndEvent(replyId, "text"));
}
if (thinkingStarted.get()) {
events.add(new ThinkingBlockEndEvent(replyId, "thinking"));
}
for (String toolId : startedToolCalls) {
events.add(new ToolCallEndEvent(replyId, toolId));
}
events.add(new ModelCallEndEvent(replyId, context.getChatUsage()));
return Flux.fromIterable(events);
});

最后兜底导致的乱序，应该在前面的代码中void emitBlockEvents 中处理掉，总体逻辑是 遇到一个block 就因该强制发送非同类事件的结束event

[guslegend0510]

@LearningGp 麻烦看一下，谢谢您

[chickenlj]

Thanks for the contribution! This issue has been fixed by #1829 (ModelCallBlockLifecycle refactor).