Deep Research Agents 2026 - Kiến trúc Multi-step Web Research với Claude, Tavily, Firecrawl, Redis và ClickHouse cho Multi-Agent Production

Posted on: 4/14/2026 7:10:53 PM

1. Deep Research Agent - Khi AI "ngồi xuống" nghiên cứu hàng giờ thay bạn

Trước 2025, hầu hết các hệ thống AI trả lời câu hỏi theo mô hình "một cú đánh" (single-shot): nhận câu hỏi, gọi một lần retrieval, sinh câu trả lời. Đến 2026, khi Claude Research, OpenAI Deep Research, Perplexity Deep Research, Gemini Deep Research lần lượt ra mắt, cách tiếp cận đã thay đổi hoàn toàn. Một Deep Research Agent không trả lời ngay - nó lên kế hoạch, tìm kiếm lặp đi lặp lại, đọc hàng chục tới hàng trăm nguồn, đối chiếu chéo, rồi mới viết báo cáo có trích dẫn đầy đủ. Quá trình này có thể kéo dài 5 tới 30 phút cho một câu hỏi phức tạp, và đó chính là điểm khác biệt: thời gian suy nghĩ đổi lấy chất lượng.

Bài viết này đi sâu vào kiến trúc một Deep Research Agent ở cấp production năm 2026: từ vòng lặp Planner - Researcher - Writer, tầng truy xuất web với Tavily/Firecrawl/Exa, citation graph đảm bảo tính xác thực, cho tới lớp cache bằng Redis và observability bằng ClickHouse. Phần cuối là blueprint triển khai và những cạm bẫy thực tế khi đưa hệ thống lên production.

2. Tại sao RAG thông thường không đủ?

Nếu bạn đã đọc các bài trước của mình về RAG và GraphRAG, bạn biết rằng cả hai đều hoạt động trên một kho tri thức đã đóng khung (closed corpus): các tài liệu được index trước, truy vấn bằng vector similarity, rồi LLM tổng hợp kết quả. Mô hình này có ba điểm yếu khi gặp câu hỏi nghiên cứu thực tế:

• Corpus tĩnh: Dữ liệu mới sau khi index không xuất hiện. Với câu hỏi "xu hướng AI quý 1 năm 2026", RAG truyền thống bất lực.
• Không tự điều chỉnh truy vấn: Nếu kết quả lượt đầu nghèo nàn, RAG không biết cách hỏi lại tốt hơn. Nó chỉ có một cơ hội.
• Không kiểm chứng chéo: Thông tin có mâu thuẫn giữa các nguồn thì sao? RAG sẽ đưa ra một câu trả lời trung bình, không flag mâu thuẫn.

Deep Research Agent giải quyết cả ba điểm trên bằng cách biến việc nghiên cứu thành một agentic workflow: có mục tiêu, có bộ nhớ làm việc, có khả năng quyết định "tôi đã đủ thông tin chưa?" và tự điều chỉnh chiến lược.

flowchart LR
    Q[Câu hỏi nghiên cứu] --> P[Planner tạo research plan]
    P --> LOOP{Research loop}
    LOOP -->|Tìm kiếm| S[Web Search Tavily/Exa]
    S --> R[Reader trích xuất nội dung]
    R --> M[Working memory]
    M --> REF[Reflector đánh giá gaps]
    REF -->|Đã đủ| W[Writer tổng hợp báo cáo]
    REF -->|Còn thiếu| LOOP
    W --> CITE[Citation validator]
    CITE --> OUT[Báo cáo có trích dẫn]
    

3. Kiến trúc tham chiếu Deep Research Agent 2026

Một hệ thống Deep Research Agent production thường gồm năm tầng. Các thành phần có thể được triển khai như microservices độc lập hoặc đóng gói trong một orchestrator như LangGraph, Temporal hay AWS Strands Agents.

graph TB
    subgraph CLIENT[Client Layer]
        UI[Web UI / Mobile]
        API[REST / SSE API]
    end
    subgraph ORCH[Orchestration Layer]
        ROUTER[Task Router]
        PLANNER[Planner Agent]
        EXECUTOR[Research Executor]
        WRITER[Writer Agent]
        JUDGE[Evaluator/Judge]
    end
    subgraph TOOLS[Tool Layer]
        SEARCH[Tavily / Exa / Brave]
        CRAWL[Firecrawl / Jina Reader]
        ACAD[Semantic Scholar / ArXiv]
        CODE[Code Interpreter]
        BROWSER[Computer Use / Playwright]
    end
    subgraph STATE[State Layer]
        REDIS[(Redis
Session + Cache)]
        VECTOR[(Vector DB
Working Memory)]
        CH[(ClickHouse
Traces/Evals)]
        S3[(Object Store
Artifacts)]
    end
    UI --> API
    API --> ROUTER
    ROUTER --> PLANNER
    PLANNER --> EXECUTOR
    EXECUTOR --> SEARCH
    EXECUTOR --> CRAWL
    EXECUTOR --> ACAD
    EXECUTOR --> CODE
    EXECUTOR --> BROWSER
    EXECUTOR --> REDIS
    EXECUTOR --> VECTOR
    EXECUTOR --> WRITER
    WRITER --> JUDGE
    JUDGE --> API
    EXECUTOR -.trace.-> CH
    WRITER -.trace.-> CH
    JUDGE -.trace.-> CH
    EXECUTOR -.artifact.-> S3
    

3.1 Phân tách trách nhiệm giữa các agent con

Điểm mấu chốt của kiến trúc multi-agent này là tách các vai trò có mục tiêu khác nhau thành các agent con chuyên biệt. Cách làm này theo đúng pattern Supervisor - Worker mà Anthropic mô tả trong bài viết về Multi-Agent Research System của họ.

4. Vòng lặp Plan - Search - Reflect chi tiết

Trái tim của Deep Research Agent là vòng lặp ba bước. Mỗi iteration được gọi là một "research step" và hệ thống cần có budget control nghiêm ngặt để tránh chạy vô hạn.

stateDiagram-v2
    [*] --> Plan
    Plan: Tạo research plan\n(sub-questions + budget)
    Plan --> Search
    Search: Gọi search tools\n(song song 3-10 queries)
    Search --> Read
    Read: Extract relevant facts\n(streaming)
    Read --> Memorize
    Memorize: Ghi vào working memory\n(vector + KG)
    Memorize --> Reflect
    Reflect: Đánh giá gaps\nvs research plan
    Reflect --> Decision
    Decision --> Search: Còn gap + trong budget
    Decision --> Replan: Kế hoạch không còn phù hợp
    Decision --> Write: Đủ thông tin
    Decision --> Stop: Hết budget
    Replan --> Search
    Write --> Judge
    Judge --> [*]: Pass
    Judge --> Write: Fail (feedback loop)
    

4.1 Planner - phân rã câu hỏi

Planner nhận câu hỏi gốc, ví dụ "So sánh chiến lược đi vào thị trường AI của Anthropic và OpenAI trong 2025-2026", và phân rã thành sub-questions có cấu trúc. Một plan tốt thường có 5-15 sub-question được nhóm theo chủ đề, kèm research budget (số tool call tối đa, số token tối đa, deadline wall-clock).

4.2 Researcher - song song hóa tìm kiếm

Điểm khác biệt lớn của Deep Research Agent so với một chatbot tool-use thông thường là parallel tool calls. Thay vì tìm kiếm tuần tự, Researcher phát 3-10 query song song cho các sub-question khác nhau, sau đó đợi tất cả trả về trước khi reflect. Cách này khai thác tốt latency của search API (thường 300-800ms) và giảm thời gian tổng thể hàng chục lần.

Anthropic đã công bố trong bài viết về multi-agent research rằng kiến trúc orchestrator-worker của họ dùng trung bình 15 lần token so với một chat session thông thường, nhưng chất lượng kết quả tăng 90% trên benchmark nội bộ BrowseComp. Token cost là cái giá phải trả cho chiều sâu.

4.3 Reflector - biết khi nào dừng

Reflector đánh giá working memory theo hai trục: độ bao phủ (đã trả lời được bao nhiêu sub-question?) và độ chắc chắn (mỗi claim có ít nhất N nguồn độc lập không?). Nếu cả hai trục đạt ngưỡng, agent chuyển sang Write. Nếu không, Reflector sinh query mới để lấp gap - và đây là chỗ nhiều hệ thống bị lỗi: Reflector thường sinh query lặp lại nếu không được buộc phải sinh query khác biệt về mặt ngữ nghĩa. Mẹo thực tế: đưa list query đã dùng vào prompt Reflector kèm yêu cầu "query mới phải khác phương diện với 3 query gần nhất".

5. Tool Layer - Tầng tương tác với web

Web search và web crawling là xương sống của Deep Research Agent. Năm 2026, một số công cụ đã nổi lên như lựa chọn mặc định cho các agent builder.

5.1 Pattern Adaptive Tool Selection

Thay vì hard-code một công cụ cho mọi query, các hệ thống production 2026 dùng pattern Adaptive Tool Selection: Researcher được cho một tool registry và tự chọn tool dựa trên loại sub-question. Câu hỏi học thuật? Dùng Semantic Scholar. Tin tức thời gian thực? Dùng Brave + Tavily. Cần nội dung trang cụ thể? Dùng Firecrawl. LLM tự học quy tắc này qua few-shot examples trong system prompt.

6. Citation Graph - đảm bảo tính xác thực

Điểm yếu chết người của một research agent là citation hallucination: model sinh ra fact có vẻ đúng nhưng gán nhầm nguồn, hoặc tạo nguồn không tồn tại. Cách duy nhất để xử lý triệt để là không để LLM tự gán citation. Thay vào đó, mỗi fact được ghi vào working memory phải kèm source_id không đổi, và Writer chỉ được tham chiếu bằng id đó.

graph LR
    subgraph RAW[Raw sources]
        U1[url1: techcrunch.com/...]
        U2[url2: anthropic.com/news/...]
        U3[url3: arxiv.org/abs/2603.xxx]
    end
    subgraph FACTS[Facts extracted]
        F1["fact: Claude Opus 4.6
launched 2026-03"]
        F2["fact: 200K context window"]
        F3["fact: 15x token multi-agent"]
    end
    subgraph CLAIMS[Claims in report]
        C1["claim: Anthropic ra Opus 4.6
đầu Q2 2026"]
        C2["claim: Multi-agent tốn token cao"]
    end
    U1 --> F1
    U2 --> F1
    U2 --> F2
    U3 --> F3
    F1 --> C1
    F2 --> C1
    F3 --> C2
    

6.1 Thuật toán Extract-then-Cite

Quy trình chuẩn cho mỗi tài liệu crawl được:

1. Canonicalize URL: Loại bỏ tracking param, chuẩn hóa scheme, giữ lại canonical URL. Hash thành source_id.
2. Extract facts: Reader trích xuất các fact dưới dạng {fact_text, source_id, confidence, page_anchor}. Fact không có anchor (không trỏ về đoạn văn cụ thể) bị loại.
3. Dedupe + cluster: Các fact cùng nghĩa từ các nguồn khác nhau được cluster. Cluster càng nhiều source càng đáng tin.
4. Write with IDs: Writer được buộc trích dẫn bằng [src:abc123] thay vì tự đặt tên.
5. Validate: Sau khi Write xong, một validator riêng check mỗi citation có thật sự nằm trong source bundle hay không.

7. Cache Layer - Tối ưu chi phí với Redis

Mỗi search/crawl call đều tốn tiền và tốn latency. Với budget 60 tool call cho một research task, một hệ thống không có cache sẽ đốt tiền khủng khiếp. Redis đóng vai trò cache đa tầng trong kiến trúc Deep Research Agent.

7.1 Ba tầng cache chính

7.2 Tính toán ROI thực tế

Trên một hệ thống production mình tham gia, cache hit rate các tầng như sau sau 2 tuần warm-up:

Điểm tinh tế: semantic cache hit rate chỉ 18% nhưng tiết kiệm gấp đôi chi phí so với L1/L2 vì nó cắt được toàn bộ vòng lặp research, không chỉ một tool call.

8. Observability - ClickHouse cho research traces

Một Deep Research Agent tạo ra hàng nghìn events mỗi task: tool call, LLM call, reflection step, cache hit/miss, citation validation. ClickHouse là lựa chọn lý tưởng để lưu các event này nhờ khả năng ingest hàng trăm nghìn event/giây, compress tốt và query analytical nhanh.

Schema tối thiểu cho bảng research events:

8.1 Các query operation hay dùng

• P95 latency từng agent role: phát hiện bottleneck giữa planner/researcher/writer
• Cost per task theo người dùng: alerting khi một user đốt quá nhiều token
• Tool error rate theo provider: detect khi Tavily hay Firecrawl đang xuống
• Query dedup hit rate: đánh giá chất lượng reflector
• Citation validation failure rate: chỉ báo chất lượng writer

9. So sánh các Deep Research Agent thương mại 2026

10. Cạm bẫy thực tế khi đưa lên Production

10.1 Query drift - agent đi lạc khỏi câu hỏi gốc

Sau 20-30 bước search, working memory có thể phình to và kéo Reflector sinh ra các query chỉ liên quan gián tiếp. Giải pháp: luôn giữ original question trong prompt mỗi vòng lặp, và Judge cuối cùng phải kiểm tra "báo cáo này có trả lời được câu hỏi gốc không?" - không phải "báo cáo này có đủ thông tin không?".

10.2 Context window bloat

Research agent tích lũy nhiều tài liệu rất nhanh. Một crawl có thể trả về 30-50K token. Nếu để tất cả vào context của Writer, bạn sẽ nhanh chóng chạm giới hạn. Cách xử lý: Reader luôn trích xuất thành fact ngắn (30-100 token) với source pointer. Writer không bao giờ thấy raw page, chỉ thấy facts + metadata. Pattern này cũng đã được mô tả trong bài Context Engineering.

10.3 Source quality - rác vào, rác ra

Không phải mọi kết quả search đều đáng tin. Content farm, SEO spam, AI-generated blog hàng loạt có thể làm nhiễm working memory. Cần một source allowlist/denylist tối thiểu, và lý tưởng là một source quality classifier (LLM hoặc ML nhỏ) chạy trên metadata trước khi đọc chi tiết.

10.4 Long-running task failure recovery

Task chạy 10 phút, đang ở bước 45/60 thì crash? Nếu không có checkpoint, user phải chạy lại từ đầu và trả tiền lần hai. Dùng Temporal, Inngest hoặc AWS Step Functions để checkpoint sau mỗi research step. Working memory ghi vào Redis hoặc Postgres, không giữ trong RAM. Xem chi tiết trong bài Event-Driven Multi-Agent Orchestration.

10.5 Cost blowup do vòng lặp

Không có hard budget là con đường nhanh nhất tới hóa đơn sốc. Bắt buộc ba loại budget: max_tool_calls, max_tokens, deadline_seconds. Bất kỳ cái nào chạm là dừng và yêu cầu user confirm có muốn tiếp tục không. Kết hợp với per-user rate limit ở API gateway.

11. Blueprint triển khai từ A tới Z

Dưới đây là một lộ trình 6 tuần để đưa một Deep Research Agent từ idea lên production cho team 2-3 người.

12. Roadmap công nghệ 2026-2027

13. Kết luận

Deep Research Agent không chỉ là "chatbot có search tốt hơn". Nó là một workflow nhiều tác nhân với vòng lặp Plan - Search - Reflect, trả giá bằng token và thời gian để đổi lấy chất lượng câu trả lời. Sự khác biệt lớn nhất so với RAG truyền thống không phải ở tool, mà ở khả năng tự điều chỉnh chiến lược - agent biết khi nào cần tìm thêm, khi nào đủ, khi nào nên replan.

Để đưa hệ thống này lên production, bốn yếu tố không thể thiếu: budget control nghiêm ngặt để kiểm soát chi phí, cache đa tầng bằng Redis để giảm tool call, citation graph để tránh hallucination, và observability bằng ClickHouse để debug và tối ưu. Với kiến trúc tham chiếu và blueprint trong bài, một team 2-3 người hoàn toàn có thể dựng phiên bản v1 trong 6 tuần.

Năm 2026 là thời điểm vàng để thử nghiệm Deep Research Agent. Các công cụ đã trưởng thành, chi phí token giảm một nửa so với 2024, và các best practice đã rõ ràng. Câu hỏi không còn là "có nên dùng không" mà là "dùng thế nào cho hiệu quả kinh tế nhất trong domain của bạn".

14. Nguồn tham khảo