Bug: Deep Research follow-up questions get hijacked by the earliest user prompt。
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 78/100
Hướng nghiên cứu
Bắt đầu trong api/services/research.py, hàm research_chat, ở khối xử lý continuation quét request.messages từ đầu để chọn original_topic; issue bao gồm diff chính xác. Áp dụng nó (duyệt bằng reversed và yêu cầu cả 'continue' lẫn 'research' để phân loại một tin nhắn là continuation), sau đó kiểm tra api/tests (hoặc thư mục test của repo) tìm test nào bao phủ research_chat và thêm một cái nếu khả thi. Xong khi, khi tái hiện luồng Deep Research hai câu hỏi, mọi dòng log continuation đều hiển thị câu hỏi hiện tại thay vì câu hỏi đầu tiên.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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)
- Ngôn ngữ chính
- Python
- Star
- 18.1k
- Fork
- 2k
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của AsyncFuncAI/deepwiki-open
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
AsyncFuncAI/deepwiki-open#608 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
AsyncFuncAI/deepwiki-open#602 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
AsyncFuncAI/deepwiki-open#539 · 1 bình luận ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
AsyncFuncAI/deepwiki-open#610 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 20/100
AsyncFuncAI/deepwiki-open#609 ·
Tất cả issue của AsyncFuncAI/deepwiki-open
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement good first issue Stellar Wave trivial
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
StellarCanary/ProtocolCanary-Fixtures#258 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
IBM/ai-atlas-nexus#295 ·
Maintainer thường phản hồi trong vòng 6 ngày
-
github_actions
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Hochfrequenz/aibap.mcp#578 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
mishraprafful/multihull#150 ·
Maintainer thường phản hồi trong vòng 1 ngày