[llm] Gemini 3 tool loop fails with 400: thought signature is not sent back
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 76/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- python
- Ambito
- ai-infra-agents, backend-api-design
Direzione di ricerca
Start with the stream and non-stream parsers in ms_agent/llm/transport/openai_compat.py, then trace _merge_stream_message and Message.to_dict_clean. Keep extra_content through parsing, merging, and serialization; done means the thought signature survives the tool-call round trip. Run the relevant tests in tests/llm and tests/agent.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Found while testing LLM provider integrations in agent frameworks: an automated tool flags candidates and each one is reproduced before it is reported. Reproduced on 6d90d84 with a local stub that applies Google's documented rule, so the 400 below is mimicked, not from a live call.
Initial Checks
- I have searched related issues and docs but cannot get the expected help.
- The bug has not been fixed in the latest version.
A clear and concise description of what the bug is.
An agent on the built-in google provider with a Gemini 3 model (gemini-3.5-flash here) stops at its first tool result. On Gemini's OpenAI-compatible endpoint the signature comes on the tool call as extra_content.google.thought_signature. ms-agent does not keep that field, so the next request replays the call without it. Google's thought signatures page says: "If a required thought signature is not returned when using Gemini 3 models, the model will return a 400 error." The same message was reported from the real API on another project in shy3130/tick-stock-panel#452.
Repro against a local stub of that endpoint. Its first reply is a read_file call with a signature, and it answers 400 when the signature does not come back:
agent = LLMAgent(config=OmegaConf.create({
'llm': {'service': 'google', 'model': 'gemini-3.5-flash',
'google_api_key': 'test', 'google_base_url': STUB_URL},
'generation_config': {'stream': True},
'tools': {'file_system': {'mcp': False, 'include': ['read_file']}},
'output_dir': work_dir,
}))
asyncio.run(agent.run('read a.txt'))
openai.BadRequestError: Error code: 400 - Function call is missing a thought_signature in functionCall parts.
turn 1 reply signature: CsUBAY89a1_fake_signature_from_turn_1==
turn 2 request tool call: {"id": "call_1", "type": "function", "function": {"name": "file_system---read_file", "arguments": "{\"paths\": [\"a.txt\"]}"}}
Same result without streaming, and on the legacy OpenAI client with service: openai and a Gemini base URL. Expected: the tool call in the second request keeps its extra_content.
The parsers build ToolCall from id, index, type and function only (stream parser, and the non-stream one next to it), and Message.to_dict_clean rebuilds the wire tool call from those same keys. Thinking cannot be switched off on these models, so reasoning_effort: off does not avoid it.
Fix idea: keep extra_content on ToolCall in both parsers and in _merge_stream_message, and put it back in to_dict_clean. With that in the router transport and the legacy client the stub run finishes, the field survives the session log round trip, and the tests in tests/llm and tests/agent that I ran still pass.
Versions / Dependencies
ms-agent 1.6.0 at 6d90d84 (main), Python 3.12.4, openai 3.41.0, Linux.
- Lingua principale
- Python
- Stelle
- 4.4k
- Fork
- 544
- Merge medio
- 2g 12h
- PR unite (30g)
- 5
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di modelscope/ms-agent
-
Skill search returns stale results after all skills are disabled or removedForse già presa @AWUQAQ l’ha presa 63 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
modelscope/ms-agent#974 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
modelscope/ms-agent#1047 ·
I maintainer di solito rispondono entro 1 giorno
-
fetch_page web tool performs unrestricted server-side HTTP fetch of agent-supplied URLs (SSRF)Forse già presa @SiyuanChenToDo l’ha presa 27 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
modelscope/ms-agent#1018 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
modelscope/ms-agent#1011 ·
I maintainer di solito rispondono entro 1 giorno
-
[tool] Document authenticated Streamable HTTP MCP setupForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
modelscope/ms-agent#1003 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di modelscope/ms-agent
Issue simili
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
Sienna-Platform/SiennaSchemas#130 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
firedrakeproject/Irksome#293 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
ida-arbeitszeit/workers-control#1578 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
aws-samples/sample-per-model-bedrock#898 ·
I maintainer di solito rispondono entro 1 giorno