feat: allow manual endpoint type configuration and add qwen3.5-plus support#824
feat: allow manual endpoint type configuration and add qwen3.5-plus support#824uuuyuqi wants to merge 5 commits intoagentscope-ai:mainfrom
Conversation
…upport Change-Id: I117c4adee6f8372691f9186e14b7dc26839a0528
Change-Id: I40f87398172d9330db09dccebf1fe8ab0516c51a
Summary of ChangesHello @uuuyuqi, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the DashScope integration by providing more control over endpoint selection and adding support for new models. It introduces an Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request successfully introduces the EndpointType enum, allowing for explicit configuration of DashScope API endpoint types. This enhances flexibility by enabling manual override of the automatic model name-based detection, which is particularly useful for models like qwen3.5-plus that might not fit existing auto-detection patterns. The changes are well-integrated across DashScopeRequest, DashScopeChatModel, and DashScopeHttpClient, with clear documentation and appropriate handling of default values. The introduction of the isMultimodalModel helper method also improves code organization and maintainability.
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
Change-Id: I122cae15d91cc685cccc4b2387eac707f17245bf
There was a problem hiding this comment.
Pull request overview
This PR introduces manual endpoint type configuration for DashScope models and adds support for the qwen3.5-plus model to resolve multimodal API routing issues reported in #817. Previously, qwen3.5-plus users encountered "url error" when attempting multimodal calls because the model name didn't match the auto-detection patterns (qvq prefix or -vl pattern). The solution adds both explicit endpoint control via a new EndpointType enum and automatic detection for qwen3.5-plus models.
Changes:
- Added
EndpointTypeenum (AUTO, TEXT, MULTIMODAL) to allow explicit API endpoint selection - Extended auto-detection logic to recognize qwen3.5-plus as a multimodal model
- Updated DashScopeChatModel, DashScopeHttpClient, and DashScopeRequest to support endpoint type configuration while maintaining backward compatibility
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
EndpointType.java |
New enum defining three endpoint types with comprehensive documentation |
DashScopeHttpClient.java |
Updated endpoint selection logic to support explicit type override; added qwen3.5-plus pattern detection |
DashScopeChatModel.java |
Added endpointType field with builder support and backward-compatible constructor overloading |
DashScopeRequest.java |
Added JsonIgnore endpointType field with proper default initialization |
DashScopeHttpClientTest.java |
Comprehensive test coverage for new endpoint type routing and qwen3.5-plus detection |
DashScopeChatModelTest.java |
Tests for builder and constructor patterns with endpointType parameter |
| * <p>Use this when the model name doesn't match the auto-detection patterns but | ||
| * you need to use a specific API. For example, qwen3.5-plus is a multimodal-capable | ||
| * model but its name doesn't match the auto-detection patterns. | ||
| * | ||
| * <p>Example: | ||
| * <pre>{@code | ||
| * DashScopeChatModel model = DashScopeChatModel.builder() | ||
| * .apiKey("sk-xxx") | ||
| * .modelName("qwen3.5-plus") | ||
| * .endpointType(EndpointType.MULTIMODAL) // Force multimodal API for image inputs |
There was a problem hiding this comment.
The documentation is inconsistent with the actual implementation. The comment states "qwen3.5-plus is a multimodal-capable model but its name doesn't match the auto-detection patterns", however the code in DashScopeHttpClient.isMultimodalModel() (line 380) explicitly checks for "qwen3.5-plus" with lowerModelName.startsWith("qwen3.5-plus"), which means it DOES match the auto-detection patterns.
This documentation should be corrected to reflect that qwen3.5-plus is already auto-detected as multimodal. The purpose of the endpointType parameter is to allow manual override when needed, not specifically for qwen3.5-plus.
| * <p>Use this when the model name doesn't match the auto-detection patterns but | |
| * you need to use a specific API. For example, qwen3.5-plus is a multimodal-capable | |
| * model but its name doesn't match the auto-detection patterns. | |
| * | |
| * <p>Example: | |
| * <pre>{@code | |
| * DashScopeChatModel model = DashScopeChatModel.builder() | |
| * .apiKey("sk-xxx") | |
| * .modelName("qwen3.5-plus") | |
| * .endpointType(EndpointType.MULTIMODAL) // Force multimodal API for image inputs | |
| * <p>Use this when the model name does not match the auto-detection patterns or | |
| * when you need to override the automatically selected endpoint for a specific use | |
| * case. For example, qwen3.5-plus is a multimodal-capable model that is already | |
| * detected as multimodal, but you can still explicitly set the endpoint type when | |
| * you know you will provide image inputs. | |
| * | |
| * <p>Example: | |
| * <pre>{@code | |
| * DashScopeChatModel model = DashScopeChatModel.builder() | |
| * .apiKey("sk-xxx") | |
| * .modelName("qwen3.5-plus") | |
| * .endpointType(EndpointType.MULTIMODAL) // Explicitly use multimodal API for image inputs |
| * <p>The model name determines which API is used when apiType is AUTO: | ||
| * <ul> | ||
| * <li>Vision models (qvq* or *-vl*) → MultiModal API</li> | ||
| * <li>Text models → Text Generation API</li> | ||
| * </ul> |
There was a problem hiding this comment.
The documentation is incomplete and outdated. It lists "Vision models (qvq* or -vl) → MultiModal API" but omits the newly added qwen3.5-plus pattern which is also auto-detected as multimodal. The documentation should be updated to include all three patterns that trigger multimodal API routing: qvq prefix, -vl pattern, and qwen3.5-plus prefix.
| * <li>If endpointType is {@link EndpointType#MULTIMODAL} → multimodal API</li> | ||
| * <li>If endpointType is {@link EndpointType#AUTO}: | ||
| * <ul> | ||
| * <li>Models starting with "qvq" → multimodal API</li> |
There was a problem hiding this comment.
The documentation in selectEndpoint is incomplete. It lists the AUTO mode routing logic but only mentions "Models starting with 'qvq'" and "Models containing '-vl'" patterns. It should also document the "Models starting with 'qwen3.5-plus'" pattern that was added in this PR to fix the issue with qwen-3.5-plus model routing.
| * <li>Models starting with "qvq" → multimodal API</li> | |
| * <li>Models starting with "qvq" → multimodal API</li> | |
| * <li>Models starting with "qwen3.5-plus" → multimodal API</li> |
| } | ||
| String lowerModelName = modelName.toLowerCase(); | ||
| return lowerModelName.startsWith("qvq") | ||
| || lowerModelName.contains("-vl") |
There was a problem hiding this comment.
Since the Qwen 3.5 family (e.g., qwen3.5-flash, qwen3.5-35b-a3b) is entirely multimodal, should we consider using prefix-based matching for detection?
| * Automatically determine endpoint type based on model name. | ||
| * | ||
| * <p>This is the default behavior. The routing logic: | ||
| * <ul> |
There was a problem hiding this comment.
Routing logic isn't managed in this module. Let's skip the duplicate comments to keep the code clean.
| * | ||
| * <p>This allows explicit control over which DashScope API endpoint to use: | ||
| * <ul> | ||
| * <li>{@link EndpointType#AUTO} - Automatic detection based on model name (default)</li> |
There was a problem hiding this comment.
Use a direct reference for EndpointType to avoid redundant descriptions.
|
There are other multimodal models, such as qwen3-asr-flash. Should we consider accounting for them as well? |
Change-Id: I11d18dfb4adc57a38f123a7a966704da9fafa64b
AgentScope-Java Version
1.0.10-SNAPSHOT
Description
Allow manual endpoint type configuration and add qwen3.5-plus support.
Closes #817
Checklist
Please check the following items before code is ready to be reviewed.
mvn spotless:applymvn test)