[Bug] kimi-k3 model returns HTTP 400 due to anyOf keyword in tool schema #946

Bug Description

The Volcengine kimi-k3 model configured on the platform always returns HTTP 400 error when used, while other models work fine.

Error Message

Task execution incomplete.
Error: Model provider rejected the request (HTTP 400).
Error code: model_call_failed

Trigger Condition

Any message sent to the agent triggers this error immediately (not intermittent).

Root Cause Analysis

After systematic debugging, the root cause has been identified:

Key Findings

1. Minimal request (1 tool) → kimi-k3 works fine
2. Full agent with 59 tools → kimi-k3 returns HTTP 400
3. Binary search narrowed down to 2 problematic tools:
   • update_trigger → FAIL
   • send_platform_message → FAIL

Root Cause

Both tools use the top-level anyOf keyword in their JSON Schema for conditional required parameters:

"parameters": {
  "type": "object",
  "properties": { ... },
  "anyOf": [
    { "required": ["config"] },
    { "required": ["reason"] }
  ]
}

Why Only kimi-k3 Fails

• anyOf is a full JSON Schema keyword, but OpenAI-compatible tool schemas only support a subset (type, properties, required, etc.)
• Volcengine's kimi-k3 performs strict schema validation and rejects anyOf with HTTP 400
• Other models like minimax-m3 and glm-5.2 have lenient validation and tolerate anyOf

This perfectly explains why "only kimi fails" and "every message triggers the error" (these two tools are always in the agent's tool list).

Code Location

These tool definitions are in builtin_tool_definitions.py. The schema is passed directly to the model without provider-specific sanitization.

Expected Behavior

The agent should work correctly with the kimi-k3 model, same as other models.

Suggested Solutions

1. Option A (Recommended): Sanitize schema before sending to Volcengine - remove anyOf and other unsupported keywords based on provider capabilities
2. Option B: Modify tool definitions to use alternative patterns that don't require anyOf (e.g., use oneOf with nullable fields, or split into separate optional parameters)
3. Option C: Add provider-specific schema transformations in the model adapter layer

Reporter

xiaoan (Platform User)