Bug: Deep Research follow-up questions get hijacked by the earliest user prompt。
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 78/100
Direzione di ricerca
Inizia in api/services/research.py, funzione research_chat, nel blocco di gestione della continuazione che scorre request.messages dall'inizio per scegliere original_topic; l'issue include il diff esatto. Applicalo (itera con reversed e richiedi sia 'continue' sia 'research' per classificare un messaggio come continuazione), poi controlla api/tests (o la cartella dei test del repo) per eventuali test che coprano research_chat e aggiungine uno se fattibile. È completato quando, riproducendo il flusso Deep Research a due domande, ogni riga di log di continuazione mostra la domanda corrente anziché la prima.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Deep Research: a follow-up question is answered as the first question in the conversation
Summary
In Deep Research mode, after question A has been fully answered, asking a second question B (also in Deep Research mode, same session) returns an answer about A, not B. B's own research is effectively ignored.
Root cause is in the backend: when resolving the "original research topic" for continuation iterations, the code picks the first user message in the whole conversation history instead of the current question. Every follow-up therefore gets hijacked back onto the earliest question in the session.
Confirmed on latest main (d92819a). The buggy code is unchanged upstream.
Steps to reproduce
- Open any repo, open Ask, enable Deep Research.
- Ask question A (e.g. "How does Tesla integrate as a third party?"). Let all iterations finish.
- Keeping Deep Research on, in the same session ask a different question B (e.g. "How many Shelly plug types are there?").
- Expected: the answer is about B.
Actual: iteration 1 researches B, but iterations 2–5 (the bulk of the deep-research answer) research A, so the final answer is about A. B looks ignored.
Root cause
api/services/research.py, in research_chat, the continuation handling:
# Check if this is a continuation request
if (
"continue" in last_message.content.lower()
and "research" in last_message.content.lower()
):
# Find the original topic from the first user message
original_topic = None
for msg in request.messages: # <-- iterates from the START
if msg.role == "user" and "continue" not in msg.content.lower():
original_topic = msg.content.strip()
break
if original_topic:
last_message.content = original_topic
Deep Research works by sending the real question on iteration 1, then auto-sending "Continue the research" for iterations 2–5. On each continuation the backend rebuilds the topic by scanning request.messages from the beginning and taking the first non-continuation user message.
But the frontend sends the entire conversation history (all previously committed turns) plus the new question. Once question A has been committed, the history for B's continuations looks like:
[A_question, A_answer, B_question, "Continue the research"]
Scanning from the start, the first non-continuation user message is A_question, so iterations 2–5 of B are redirected to A's topic. The result is dominated by A, which is why B appears to be ignored / "never processed".
Log evidence (before the fix)
Asking B after A, every continuation iteration logs A's topic:
Deep Research request detected - iteration 2
Found original research topic: 当前项目存在第三方设备对接,其中Tesla是如何实现对接的 <-- this was question A
Using original topic for research: 当前项目存在第三方设备对接,其中Tesla是如何实现对接的
... (iterations 3,4,5 identical) ...
B's own text only reached iteration 1; iterations 2–5 all reverted to A.
Suggested fix
Pick the most recent real (non-continuation) user question by iterating from the end. Also tighten the "is continuation" filter to match both continue and research (so a legitimate question that merely contains the word "continue" is not skipped):
# Find the topic of the CURRENT research: the most recent real
# (non-continuation) user question. Iterating from the end avoids
# picking an earlier, already-answered question from the
# conversation history — otherwise a follow-up deep-research
# question gets hijacked back onto a previous topic, and every
# continuation iteration researches the old question instead.
original_topic = None
for msg in reversed(request.messages):
if msg.role == "user" and not (
"continue" in msg.content.lower()
and "research" in msg.content.lower()
):
original_topic = msg.content.strip()
logger.info(f"Found original research topic: {original_topic}")
break
Verified after the fix
Asking A, letting it complete, then asking a different B in the same Deep Research session — every continuation iteration now stays on B's topic:
Deep Research request detected - iteration 2
Found original research topic: system里面的能量守恒是怎么做的 <-- correctly the current question B
Using original topic for research: system里面的能量守恒是怎么做的
Patch
--- a/api/services/research.py
+++ b/api/services/research.py
@@ -125,10 +125,18 @@ async def research_chat(
"continue" in last_message.content.lower()
and "research" in last_message.content.lower()
):
- # Find the original topic from the first user message
+ # Find the topic of the CURRENT research: the most recent real
+ # (non-continuation) user question. Iterating from the end avoids
+ # picking an earlier, already-answered question from the
+ # conversation history — otherwise a follow-up deep-research
+ # question gets hijacked back onto a previous topic, and every
+ # continuation iteration researches the old question instead.
original_topic = None
- for msg in request.messages:
- if msg.role == "user" and "continue" not in msg.content.lower():
+ for msg in reversed(request.messages):
+ if msg.role == "user" and not (
+ "continue" in msg.content.lower()
+ and "research" in msg.content.lower()
+ ):
original_topic = msg.content.strip()
logger.info(f"Found original research topic: {original_topic}")
break
Environment
- Branch/commit:
main@d92819a - Backend:
api/services/research.py(research_chat) - Mode: Deep Research, multi-turn (second question onward)
- Lingua principale
- Python
- Stelle
- 18.1k
- Fork
- 2k
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
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 AsyncFuncAI/deepwiki-open
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
AsyncFuncAI/deepwiki-open#608 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
AsyncFuncAI/deepwiki-open#602 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
AsyncFuncAI/deepwiki-open#539 · 1 commento ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
AsyncFuncAI/deepwiki-open#610 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 20/100
AsyncFuncAI/deepwiki-open#609 ·
Tutte le issue di AsyncFuncAI/deepwiki-open
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
-
Harmony OPeNDAP SubSetter (HOSS) Geographic LARC_CLOUD PREFIRE_SAT2_AUX-SAT R01 production
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
nasa/harmony-autotester#245 ·
-
[FEATURE] - Add UTVD supportApertaenhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Deltares/imod-python#1928 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
feature
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100