deepresearch-patterns.md

Архитектуры Deep Research систем

Паттерн: Полиморфный LLM-адаптерный слой для агентных рантаймов

Описание

Паттерн отделяет агентную логику от конкретного LLM-провайдера через слой адаптеров, фабрик и prompt-style профилей. Один и тот же агентный runtime может переключаться между backend-моделями без переписывания бизнес-логики инструментов.

Паттерн решает задачи переносимости, отказоустойчивости и A/B-сравнения моделей в production/research контурах. Он особенно важен при смешении function-calling диалектов и разных API-контрактов.

Характерные черты

• Базовый интерфейс LLM и набор provider-адаптеров.
• Выделенные prompt templates под разные function-calling режимы.
• Конфигурируемое переключение backend на уровне рантайма.
• Изоляция агентного planning/tool-слоя от API-специфики провайдера.

Типичная структура

flowchart TD
    AG[Agent Runtime] --> LINT[LLM Interface]
    LINT --> A1[Provider Adapter A]
    LINT --> A2[Provider Adapter B]
    LINT --> A3[Provider Adapter C]
    A1 --> API1[Model API A]
    A2 --> API2[Model API B]
    A3 --> API3[Model API C]

Loading

Проекты

• Alibaba-NLP-DeepResearch: в ветке WebWatcher использует qwen_agent/llm/* с базовым интерфейсом, provider-адаптерами и function-calling prompt styles.
• OpenDeepResearcher: применяет единый async-адаптер call_openrouter_async для всех когнитивных этапов (query generation, relevance check, extraction, replanning, final synthesis), сохраняя изоляцию orchestration-слоя от API-вызова модели.
• open_deep_research: централизует выбор моделей по стадиям через Configuration (model slots для research/compression/final), что позволяет менять backend-профили без изменения оркестратора.
• SkyworkAI-DeepResearchAgent: использует ModelManager и семейство адаптеров (LiteLLMModel, OpenAIServerModel, Restful*) с единым MessageManager, что позволяет переключать провайдеры в одном агентном runtime и конфиг-профилях.
• Tencent-CognitiveKernel-Pro: использует общий model.py интерфейс для нескольких backend-ов и MessageTruncator, чтобы удерживать длинный stateful-контекст в лимитах токенов без изменения агентной логики.
• btahir-open-deep-research: использует generateWithModel как централизованный dispatcher между Gemini/OpenAI/Anthropic/DeepSeek/Ollama/OpenRouter, сохраняя неизменный контракт API-стадий при смене провайдера.
• deep-research: реализует getModel как provider facade с переключением между custom endpoint, Fireworks DeepSeek R1 и OpenAI o3-mini, сохраняя единый оркестрационный слой.
• deep-searcher: реализует BaseLLM с множеством провайдеров и провайдерный выбор через Configuration/ModuleFactory из YAML без изменения агентной логики.
• fdarkaou-open-deep-research: применяет минимальный адаптерный слой createModel с переключением между gpt-4o, gpt-4o-mini и o3-mini при общей orchestration-логике.
• gpt-researcher: использует provider-agnostic LLM abstraction с широким набором провайдеров и семействами промптов (PromptFamily) для совместимости режимов.
• local-deep-research: использует auto-discovery и registry провайдеров (OpenAI/Anthropic/Google/OpenRouter/Ollama/LMStudio/...) для переключения LLM без изменения core-оркестрации.
• smolagents: реализует общий интерфейс Model и набор провайдеров (OpenAI/Azure/LiteLLM/Transformers/VLLM/MLX/Bedrock) с единым runtime-контрактом.
• starpig1129-DATAGEN: использует LanguageModelManager + ProviderFactory с набором провайдеров (OpenAI/Anthropic/Google/Ollama/Azure/Groq) и назначает модель по роли агента.

Варианты и гибриды

В минимальном варианте есть один адаптер и один prompt style. В полном варианте добавляются профили под разные семьи моделей и fallback-цепочки при сбоях конкретного провайдера. OpenDeepResearcher демонстрирует минимальную конфигурацию этого паттерна: один провайдерный адаптер без полиморфного переключения, но с полной централизацией LLM-вызовов. Skywork реализует конфигурируемый middle-вариант: полиморфный слой есть, а специализация поведения достигается сочетанием профиля режима и prompt/tool binding. Tencent дополняет паттерн встроенным truncation-слоем как частью адаптера, а не внешней постобработкой prompt. btahir добавляет product-oriented вариацию: capability matrix одновременно управляет UI-доступностью моделей и backend-валидацией разрешенных провайдеров.

---

Паттерн: Гетерогенный tool mesh для research-агента

Описание

Паттерн объединяет несколько классов инструментов в одном агентном контуре: веб-поиск, чтение страниц, академический поиск, вычислительный sandbox и файловый парсинг. Вместо моноканального retrieval система использует tool mesh с единым протоколом вызова.

Архитектура нужна для задач, где ответ требует одновременно evidence из интернета, структурированных документов и локальных вычислений. Она уменьшает число handoff между специализированными пайплайнами и повышает полноту исследования.

Характерные черты

• Единый интерфейс tool calling для разнородных каналов.
• Сочетание retrieval и execution-инструментов.
• Возможность переключать инструмент по ходу multi-turn reasoning.
• Нормализация ответов инструментов в общий trace-формат.

Типичная структура

flowchart TD
    AG[ReAct Agent] --> S[Search Tool]
    AG --> V[Visit Tool]
    AG --> SC[Scholar Tool]
    AG --> PY[Python Tool]
    AG --> F[File Tool]
    S --> AG
    V --> AG
    SC --> AG
    PY --> AG
    F --> AG

Loading

Проекты

• Alibaba-NLP-DeepResearch: в базовом inference-контуре объединяет search, visit, scholar, python, file под единым агентным lifecycle.
• OpenDeepResearcher: использует минимальный mesh из специализированных внешних сервисов: SerpAPI для discovery, Jina Reader для page-reading и LLM для relevance/synthesis в едином итеративном контуре.
• open_deep_research: строит единый реестр инструментов (search + MCP + think_tool) и выбирает backend поиска конфигурационно, сохраняя общий tool-calling путь.
• SkyworkAI-DeepResearchAgent: использует расширенный mesh (WebSearcher, WebFetcher, DeepResearcher, DeepAnalyzer, FileReader, AutoBrowser, PythonInterpreter, Planning) и вызывает часть возможностей через managed-agents в общем tool-calling пути.
• Tencent-CognitiveKernel-Pro: строит двухдоменный mesh через WebAgent + WebEnv(Playwright) и FileAgent + FileEnv(MarkdownConverter); оркестратор делегирует подзадачи специализированным агентам и объединяет результаты в общей сессии.
• btahir-open-deep-research: строит прикладной mesh из Bing/Google/Exa (discovery), Jina.ai (content fetch), officeparser (локальные документы) и LLM-генерации отчета в едином API-оркестраторе.
• gpt-researcher: использует широкий набор retrievers (поиск/академика/MCP) и scraper-стек (включая browser и PDF), объединяя их в один research-пайплайн.
• local-deep-research: реализует retrieval-mesh через Search Engine Factory (множество web/academic движков) и встроенную Library RAG, объединенные в общий research pipeline.
• smolagents: предоставляет schema-first Tool/ToolCollection и набор default tools (search/visit/выполнение кода), расширяемые через MCP, под единым tool-calling контрактом.
• starpig1129-DATAGEN: комбинирует локальные tools (код, файлы, команды) и интернет-инструменты (google_search, scrape, arxiv) с MCP-интеграциями через ToolFactory и mcp_tools.
• zamalali-DeepGit: фиксированный tool-chain комбинирует GitHub ingestion, hybrid retrieval (ColBERT+BM25), cross-encoder rerank и LLM-парсинг/фильтры как единый mesh внутри пайплайна.

Варианты и гибриды

Базовый вариант ограничивается search + visit. Расширенный гибрид добавляет scholar для научных источников, python для проверяемых вычислений и file-toolchain для пользовательских документов. В OpenDeepResearcher базовый вариант дополнен stage-gate логикой fetch -> usefulness(Yes/No) -> extract, что уменьшает лишнюю обработку нерелевантных страниц. Skywork добавляет иерархическую вариацию mesh-подхода: специализированные роли инкапсулированы как инструменты, что упрощает делегирование и повторное использование execution path. Tencent фиксирует прикладной подвариант «web+file dual-channel»: web-наблюдения приоритетно берутся из accessibility-tree, а документы обрабатываются в текстовом и визуальном режимах через единый file-env API. btahir реализует конфигурационный подвариант: состав mesh выбирается через capability matrix (CONFIG) и динамически ограничивается rate-limit слоем. В отдельном подварианте mesh формально разделен на retriever и scraper слои с нормализованным форматом документов, что упрощает расширение источников (пример — gpt-researcher). open_deep_research демонстрирует MCP-расширяемый mesh: инструменты подгружаются динамически и оборачиваются auth/error handling, сохраняя единый формат вызова и результатов.

---

Паттерн: ReAct-траектории с реальными инструментами

Описание

Паттерн строит reasoning-траектории в формате agent loop, где шаги модели включают внешние tool-вызовы и обработку их результатов. Ключевая цель — обучающие трассы, отражающие реальную инструментальную работу, а не имитацию поиска внутри одного ответа.

Такой подход нужен, когда модель должна быть обучена на проверяемом взаимодействии с вебом/API и устойчивой последовательности think -> tool_call -> tool_response -> answer. Паттерн применим в задачах research automation и browser/search-ассистентов.

Характерные черты

• Агентный runtime с итеративными decision/tool шагами.
• Инструменты подключаются через унифицированный менеджер.
• Траектория содержит полную историю промежуточных действий.
• Batch orchestration и ограничения параллелизма для throughput.

Типичная структура

flowchart TD
    IN[Question + reasoning_path] --> AG[Reasoning Agent]
    AG --> TC[tool_call]
    TC --> TM[Tool Manager]
    TM --> TS[Search / Visit]
    TS --> TR[tool_response]
    TR --> AG
    AG --> ANS[Final answer]
    ANS --> TRACE[Trajectory Trace]

Loading

Проекты

• AQ-MedAI-MedResearcher-R1: реализует LangGraphReasoningAgent и RunReasoning с инструментами search/visit и сохранением детализированных tool-augmented траекторий.
• Alibaba-NLP-DeepResearch: использует базовый react_agent.py и агентные варианты в WebAgent/*, расширяя цикл до search/visit/scholar/python/file с унифицированным ReAct-протоколом.
• OpenDeepResearcher: реализует облегченный async agent loop в notebook-формате: generate queries -> search -> fetch -> usefulness -> extract -> replan, где остановка задается через <done> или iteration_limit.
• open_deep_research: использует stateful LangGraph loop с разделением supervisor -> researcher, где researcher выполняет tool-calling шаги (search/MCP/think_tool) и возвращает сжатые результаты в общий контур.
• SkyworkAI-DeepResearchAgent: реализует AsyncMultiStepAgent для single- и hierarchical multi-agent режимов; шаги включают planning, tool calling, обработку ошибок, final_answer_tool и параллельное выполнение независимых вызовов через asyncio.gather.
• Tencent-CognitiveKernel-Pro: использует общий MultiStepAgent с циклом plan -> action -> end для CKAgent, WebAgent и FileAgent; action выражается исполняемым кодом, а шаги фиксируются в AgentSession для последующей оценки и обучения.
• btahir-open-deep-research: реализует прикладной agent loop как API-декомпозицию стадий optimize -> search/fetch -> analyze -> report с follow-up шагами; это production-вариант ReAct без отдельного trace-dataset контура.
• dCaples-AutoDidact: использует локальный ReAct-контур в rl_helpers.py, где вызовы search_corpus исполняются прямо внутри RL-генерации, а остановка задается лимитами агентного цикла.
• smolagents: реализует базовый ReAct-цикл в MultiStepAgent с разными action-парадигмами (ToolCallingAgent, CodeAgent) и шаговой памятью, фиксирующей tool/exec наблюдения.

Варианты и гибриды

Облегченный вариант использует один инструмент (только search). В R1 применен двухинструментный контур search + visit с общим ToolManager; в Alibaba-варианте паттерн расширен до мультитулового long-horizon контура. OpenDeepResearcher занимает промежуточный вариант: двухинструментный web-контур (SerpAPI + Jina) без отдельного trace-storage, но с LLM-управляемым планированием следующего шага. Skywork показывает иерархический вариант паттерна, где planner и специализированные sub-agents работают в том же ReAct/tool-calling контуре, а план поддерживается как stateful lifecycle-объект. Tencent реализует code-as-action подвариант: вместо фиксированного списка команд агент генерирует исполняемый Python-action, который выполняется в рантайме и возвращает observation в следующий шаг. btahir показывает UI-оркестрируемый подвариант: агентный цикл нарезан на API-stage контракты и может исполняться как в линейном Home, так и в графовом Flow режиме. dCaples фиксирует train-time подвариант: агентный ReAct-loop используется не только для инференса, но и как источник rollout-сэмплов для GRPO-оптимизации. open_deep_research демонстрирует supervisor/researcher подвариант: стратегический узел делегирует параллельные tool-loop задачи, а исследовательский подграф возвращает сжатые артефакты в общий контрольный цикл.

---

Паттерн: Единый контракт формата reasoning-трейсов

Описание

Архитектура вводит унифицированный сериализуемый формат трейс-данных, где каждый пример содержит строгие сегменты (<think>, <tool_call>, <tool_response>, <answer>). Формат используется сквозным образом в генерации, постобработке, обучении и оценке.

Паттерн решает проблему несовместимости между этапами pipeline и снижает стоимость интеграции новых моделей/рантаймов. Он особенно важен в системах, где несколько контуров обмениваются одними и теми же reasoning-артефактами.

Характерные черты

• Стабильная схема записи промежуточных и финальных шагов reasoning.
• Контрактная валидация структуры перед публикацией датасета.
• Повторное использование формата в training и evaluation.
• Поддержка selective-rewrite без изменения структуры записи.

Типичная структура

flowchart TD
    GEN[Generation] --> FMT[Trace Formatter]
    FMT --> PP[Postprocessing]
    PP --> TRAIN[Training Dataset]
    TRAIN --> EVAL[Evaluation Input]

Loading

Проекты

• AQ-MedAI-MedResearcher-R1: использует единый тегированный формат <think>/<tool_call>/<tool_response>/<answer> в контурах генерации и оценки.
• Alibaba-NLP-DeepResearch: использует ReAct-теги <tool_call>/<tool_response>/<answer> и JSONL как операционный формат для batch rollout и последующей judge-оценки.
• SkyworkAI-DeepResearchAgent: использует типизированный контракт шагов (TaskStep/PlanningStep/ActionStep) в AgentMemory и стабильный финальный формат через prepare_response()/JSONL для benchmark-режимов.
• Tencent-CognitiveKernel-Pro: хранит шаговый контракт в AgentSession (план, действие, observation, ошибки, финальный ответ) и напрямую конвертирует те же траектории в SFT через convert_sft.py с rejection sampling.
• btahir-open-deep-research: применяет prompt-as-contract c обязательным JSON-извлечением (extractAndParseJSON) между API-стадиями, что стабилизирует межмодульный обмен при мультипровайдерной LLM-маршрутизации.
• dCaples-AutoDidact: использует schema-driven контракт для search_corpus и парсинг JSON tool-call из свободного текста (extract_json_objects), а затем переводит agent-output в токены/маски (AgenticOutputs, get_mask) для RL-тренера.
• smolagents: фиксирует шаговую структуру в AgentMemory (типизированные Task/Planning/Action/Final шаги) и использует ее как переносимый execution-trace между режимами агента.
• starpig1129-DATAGEN: использует единый TypedDict-контракт состояния для маршрутизации, ревизий и узлов human-in-the-loop; это state-centric подвариант контракта, обслуживающий межузловой обмен в графе.

Варианты и гибриды

Вариант с JSON-структурой вместо тегов упрощает парсинг, но усложняет переносимость в prompt-oriented пайплайнах. В R1 сохранен теговый формат как межконтурный стандарт; в Alibaba он совмещен с JSONL-конвейером для масштабного инференса. Skywork реализует объектно-типизированный подвариант контракта памяти с последующей нормализацией в экспортный формат. Tencent занимает state-centric вариант: основной контракт живет в объектной сессии выполнения и затем преобразуется в учебный формат без повторной генерации reasoning. btahir демонстрирует API-centric JSON-контракт: строгая структура ответа модели валидируется на каждом шаге pipeline и используется как интерфейс между UI, роутами и report-консолидацией. dCaples показывает train-oriented подвариант контракта: trace-представление ориентировано не на внешнюю сериализацию, а на формирование корректных supervision-масок для GRPO. DATAGEN демонстрирует workflow-centric подвариант: единый State контракт обслуживает маршрутизацию, quality-review и human-gate узлы в LangGraph.

---

Паттерн: Разделенные контуры генерации и оценки

Описание

Паттерн разделяет runtime генерации synthetic data и runtime benchmark-оценки на независимые контуры с собственными точками запуска и конфигурацией. Это позволяет независимо масштабировать, обновлять и валидировать оба процесса.

Паттерн нужен для предотвращения coupling между data-generation логикой и экспериментальной оценкой качества модели. Особенно полезен в исследовательских циклах с частыми итерациями датасета и метрик.

Характерные черты

• Отдельные пайплайны, конфиги и CLI для generation и evaluation.
• Возможность повторного использования tool-слоя при независимом оркестрировании.
• Разные профили LLM и параметров под этапы генерации/оценки.
• Явный handoff через стандартизированный формат трейсов/ответов.

Типичная структура

flowchart TD
    GEN[Generation Runtime] --> DATA[Training Traces]
    DATA --> FT[Fine-tuned Model]
    FT --> EVAL[Evaluation Runtime]
    EVAL --> MET[Benchmark Metrics]

Loading

Проекты

• AQ-MedAI-MedResearcher-R1: отделяет TrajectoryGenerationPipeline от EvaluationPipeline, сохраняя независимый reasoning runtime и CLI для benchmark-режимов.
• Alibaba-NLP-DeepResearch: держит отдельные контуры inference/* и evaluation/*, включая независимые judge/prompts и скрипты официальной оценки.
• Ayanami0730-deep_research_bench: использует тот же принцип развязки контуров в benchmark-only виде: независимые пайплайны RACE и FACT запускаются отдельными этапами из shell-оркестратора и пишут артефакты в разные директории.
• open_deep_research: отделяет runtime графа от eval-тура через тестовый набор evaluators и сравнительные сценарии, которые запускаются независимо от основного контурa.
• SkyworkAI-DeepResearchAgent: разделяет production-like runtime (run_general/run_oai_deep_research) и benchmark-контур (run_gaia/run_hle) через отдельные конфиг-профили, datasets/scorers и JSONL-экспорт результатов.
• dCaples-AutoDidact: разделяет контур подготовки synthetic QA (generate_data.py) и контур RL/eval (autodidact.ipynb, simple_qa.py), сохраняя общий retrieval/tool слой как точку handoff.
• deep-searcher: держит отдельный evaluation-harness (evaluation/evaluate.py) для сравнения Deep vs Naive режимов, изолированный от online runtime.

Варианты и гибриды

В компактных системах возможен единый runtime с флагами режимов. В R1 выбран раздельный вариант для изоляции экспериментов и повторяемости; в Alibaba это дополнено отдельными official evaluators для разных наборов задач. Skywork демонстрирует гибрид: единое агентное ядро переиспользуется, но запуск и формат артефактов развязаны по benchmark-профилям. dCaples демонстрирует notebook-first вариант: контуры разведены логически и по модулям, но оркеструются из одного entry-point для локального single-GPU цикла.

---

Паттерн: Контекстная компрессия как подсистема агентного цикла

Описание

Архитектура выделяет управление длиной контекста в отдельную подсистему, которая работает внутри или рядом с ReAct-циклом. Компрессия применяется проактивно, до достижения жестких лимитов, и влияет на дальнейшую стратегию поиска/чтения.

Паттерн предназначен для long-horizon сценариев, где накапливаются большие истории шагов и evidence-блоков. Он позволяет сохранять релевантный контекст и снижать деградацию качества при длинных траекториях.

Характерные черты

• Отдельные модули summary/compression в runtime.
• Триггеры компрессии по длине, этапу или типу evidence.
• Сохранение опорных фактов при сжатии истории.
• Совместимость с продолжением tool-итераций после компрессии.

Типичная структура

flowchart TD
    LOOP[ReAct Loop] --> MEM[Context Buffer]
    MEM --> LIM[Length / Budget Check]
    LIM -->|exceeded| CMP[Compression Module]
    CMP --> MEM2[Compressed Memory]
    MEM2 --> LOOP
    LIM -->|ok| LOOP

Loading

Проекты

• Alibaba-NLP-DeepResearch: реализует две стратегии сжатия в AgentFold (проактивная компрессия) и WebResummer (summary loop) для long-context траекторий.
• deep-research: применяет trimPrompt и RecursiveCharacterTextSplitter для token-aware сокращения контекста перед LLM-вызовами при извлечении learnings и генерации follow-up.
• fdarkaou-open-deep-research: использует token-aware trimming и RecursiveCharacterTextSplitter в LLM-провайдерах для контроля длины контекста при извлечении learnings и генерации отчета.
• gpt-researcher: использует ContextCompressor/VectorstoreCompressor/WrittenContentCompressor как отдельную подсистему сжатия перед генерацией отчета.
• open_deep_research: включает compress_research в цикл researcher и применяет trimming истории/поэтапное усечение findings при переполнении контекста.

Варианты и гибриды

Один вариант выполняет только экстрактивное сжатие, другой только абстрактивное суммирование. Гибридный вариант совмещает оба режима, переключаясь по фазе rollout и текущему budget.

---

Паттерн: Единое ядро с многоканальными интерфейсами и streaming-доставкой

Описание

Архитектура выделяет единую оркестрационную логику исследования и подключает к ней несколько интерфейсов доставки: CLI, REST, WebSocket и web-frontend. Все каналы используют единый core, а транспортные адаптеры отвечают только за прием запроса и потоковую выдачу статусов/результатов.

Паттерн решает проблему дублирования бизнес-логики между интерфейсами и обеспечивает одинаковое поведение при разных точках входа. Он особенно полезен для long-running задач, где нужен streaming прогресса и частичных артефактов.

Характерные черты

• Один оркестратор для всех интерфейсов запуска.
• Транспортные адаптеры без дублирования логики.
• Streaming-first выдача логов/частичных результатов.
• Единый формат артефактов для UI и API.

Типичная структура

flowchart TD
    U[User / Client] --> CLI[CLI]
    U --> API[REST API]
    U --> WS[WebSocket]
    U --> WEB[Web Frontend]
    CLI --> ORCH[Core Orchestrator]
    API --> ORCH
    WS --> ORCH
    WEB --> ORCH
    ORCH --> PIPE[Research Pipeline]
    PIPE --> OUT[Artifacts / Reports]
    OUT --> WS
    OUT --> API
    OUT --> WEB

Loading

Проекты

• gpt-researcher: единый GPTResearcher используется в CLI, FastAPI и WebSocket; Next.js фронтенд работает через proxy и получает streaming-выдачу.
• local-deep-research: единый ResearchService/AdvancedSearchSystem обслуживает web UI, REST API, Python API и SocketIO-стриминг прогресса.
• smolagents: использует общий MultiStepAgent runtime для CLI и Gradio UI, сохраняя единый оркестратор и формат артефактов.
• zamalali-DeepGit: общий LangGraph-оркестратор запускается из CLI и Gradio UI; UI слой только стримит логи и рендерит HTML-таблицу.

Варианты и гибриды

Минимальный вариант ограничивается CLI+REST без streaming. В расширенном варианте добавляются WebSocket и фронтенд-обертки с прогрессивной выдачей отчета.

---

Паттерн: Трехфазный quality gate для synthetic traces

Описание

Архитектура вводит обязательную постобработку с фазами eval -> filter -> rewrite, где каждая фаза отвечает за отдельный класс дефектов. Сначала оценивается валидность и качество ответа, затем отбрасываются неподходящие траектории, затем корректируется reasoning-представление без разрушения структурного контракта.

Паттерн решает проблему шумных synthetic traces и уменьшает долю ошибочных/необучаемых примеров. Подходит для конвейеров, где генерация быстрая, но неоднородная по качеству.

Характерные черты

• Quality gate встроен как обязательный, а не опциональный этап.
• Разделение ролей evaluator/filter/rewriter.
• Фильтрация по структуре, токенам, следам инструментов и качеству ответа.
• Поддержка нескольких evaluator-профилей под разные бенчмарки.

Типичная структура

flowchart TD
    RAW[Raw Trajectories] --> EVAL[Evaluate]
    EVAL --> FILT[Filter]
    FILT --> REW[Rewrite]
    REW --> OUT[Training-ready Traces]

Loading

Проекты

• AQ-MedAI-MedResearcher-R1: использует PostProcessingPipeline с Evaluator, TrajectoryFilter и ThinkRewriter; поддерживает профили оценивания base, gaia, browsecomp, medbrowsecomp.
• Tencent-CognitiveKernel-Pro: использует inference-time Evaluator с retry/ensemble как встроенный quality loop поверх AgentSession; это online-вариант quality gate без отдельной офлайн-фазы rewrite.
• starpig1129-DATAGEN: реализует quality-review узел в LangGraph с возвратом к адресному агенту, далее NoteAgent и Refiner с human review; это online gate внутри графа без отдельного eval/filter/rewrite контура.

Варианты и гибриды

Вариация с высоким recall может ослаблять фильтрацию и усиливать rewrite. В R1 сделан акцент на строгий отбор перед перезаписью и безопасный подвариант think-only rewrite, где переписывается только <think> при неизменном tool trace. Tencent показывает гибрид, где eval -> retry -> aggregate встроены в inference-контур на уровне шага/эпизода и работают как механизм повышения надежности до сохранения финальной траектории. DATAGEN демонстрирует адресный quality loop в графе: откат на конкретного агента и последующая human-gate проверка вместо офлайн-фазы.

---

Паттерн: Rollout-first batch оркестрация агентных прогонов

Описание

Архитектура строит исполнение вокруг множества rollout-итераций и split/parallel планировщика, а не вокруг одного «идеального» прогона. Scheduler управляет пакетами задач, повторными попытками и записью промежуточных результатов как first-class механикой надежности.

Паттерн подходит для long-horizon research-задач с нестабильными внешними сервисами и высокой вариативностью траекторий. Он повышает устойчивость и throughput за счет управляемого параллелизма и итеративной агрегации результатов.

Характерные черты

• Центральный scheduler для split/parallel rollout.
• Итеративная запись артефактов и чекпоинтов.
• Встроенные retry/fallback механики для внешних инструментов.
• Масштабирование через batch execution вместо одиночного синхронного цикла.

Типичная структура

flowchart TD
    IN[Dataset Split] --> SCH[Rollout Scheduler]
    SCH --> R1[Rollout Workers]
    R1 --> TOOLS[External Tools / APIs]
    TOOLS --> R1
    R1 --> BUF[Partial Outputs JSONL]
    BUF --> AGG[Aggregation / Merge]
    AGG --> OUT[Stable Batch Results]

Loading

Проекты

• Alibaba-NLP-DeepResearch: run_multi_react.py реализует split/parallel rollout-оркестрацию с итеративной записью результатов и поддержкой больших batch-прогонов.
• Tencent-CognitiveKernel-Pro: поддерживает step-level multi-run/aggregation внутри CKAgent, где несколько кандидатов шага оцениваются и агрегируются перед продолжением траектории.

Варианты и гибриды

В lightweight-варианте используется только параллелизм без агрегации частичных rollout. В расширенном варианте (как у Alibaba) добавляются partial rollout стратегии и последующая компрессия/сведение рассуждений. Tencent демонстрирует микро-rollout вариант: агрегация выполняется не на уровне всего датасета, а на уровне отдельного агентного шага для локальной стабилизации решения.

---

Паттерн: Browser-native MCP расширение агента

Описание

Паттерн дополняет стандартный ReAct-контур браузерным execution-слоем через MCP/automation toolkit. Агент переходит от текстового retrieval к интерактивным действиям в веб-интерфейсах: навигации, кликам, чтению динамических страниц.

Архитектура полезна для задач, где нужная информация недоступна через простой search API и требует stateful browser-взаимодействия. Она расширяет покрытие сценариев без смены базового агентного контракта.

Характерные черты

• Асинхронный browser loop как отдельный execution-канал.
• MCP-клиент и toolkit для управления браузерными действиями.
• Согласование browser-наблюдений с общим trace-форматом агента.
• Возможность смешивать browser steps и стандартные tools.

Типичная структура

flowchart TD
    AG[ReAct Agent] --> DEC[Action Decision]
    DEC -->|web ui required| MCP[MCP Browser Client]
    MCP --> BR[Browser Toolkit]
    BR --> OBS[DOM / Page Observations]
    OBS --> AG
    DEC -->|api retrieval| TOOLS[Standard Tools]
    TOOLS --> AG

Loading

Проекты

• Alibaba-NLP-DeepResearch: в NestBrowse подключает async browser loop, mcp_client и browser toolkit как нативное расширение агентного цикла.
• SkyworkAI-DeepResearchAgent: интегрирует MCPAdapt/AsyncToolAdapter и локальный MCP server с JSON-реестром инструментов, совмещая MCP-канал с AutoBrowserUseTool и обычным tool layer в одном runtime.

Варианты и гибриды

Вариант «browser-only» редко масштабируется по стоимости. Практичный гибрид включает browser-MCP только для сложных страниц, оставляя обычные шаги на стандартном tool layer. В Skywork MCP используется шире browser-задач как first-class слой расширяемости, а не только как fallback для динамических страниц.

---

Паттерн: Граф-управляемая синтетика reasoning-данных

Описание

Архитектура строит промежуточный граф знаний и использует его как источник структуры для генерации обучающих задач и траекторий. Вместо прямой генерации из плоских текстовых промптов система сначала формирует связный набор сущностей, связей и подграфов, после чего порождает QA и reasoning-path.

Паттерн решает проблему управляемости сложности и покрытий при создании synthetic data для reasoning-моделей. Он особенно подходит для доменов, где важны multi-hop переходы, контролируемая композиция фактов и воспроизводимость генерации.

Характерные черты

• Граф знаний как обязательный промежуточный слой между источниками и датасетом.
• Декомпозиция на build/link/sample/generate этапы.
• Переиспользование sampled subgraph для разных режимов QA-генерации.
• Явное отделение генерации структуры задачи от генерации финального ответа.

Типичная структура

flowchart TD
    SRC[Entities / Sources] --> BUILD[Graph Build]
    BUILD --> LINK[Entity Linking]
    LINK --> SAMPLE[Subgraph Sampling]
    SAMPLE --> QA[QA + reasoning_path]
    QA --> DATA[Synthetic Training Data]

Loading

Проекты

• AQ-MedAI-MedResearcher-R1: реализует полный цикл через GraphRagBuilder с поисковым расширением графа, EntityLinker и топологическим семплингом перед генерацией QA.

Варианты и гибриды

Вариант с минимальным графом может ограничиваться только extraction/linking без продвинутого sampling. В R1 применен расширенный вариант с несколькими алгоритмами семплинга для управления сложностью задач.

---

Паттерн: Топологически контролируемая генерация сложности

Описание

Архитектура задает сложность reasoning-задач не только промптом, а формой sampled subgraph и правилами обхода. Сложность становится функцией топологии: длины цепей, числа мостов между кластерами, плотности связей и смешанных шаблонов.

Паттерн полезен для построения градуированных датасетов и контролируемых экспериментов по способности модели к multi-hop reasoning. Он снижает зависимость от ручной курации сложных вопросов.

Характерные черты

• Набор алгоритмов семплинга с различной структурной нагрузкой.
• Явное маппирование «тип подграфа -> ожидаемая сложность».
• Возможность балансировать корпус по классам сложности.
• Использование reasoning_path как производной от структуры графа.

Типичная структура

flowchart TD
    KG[Knowledge Graph] --> S1[Chain Sampler]
    KG --> S2[Bridge Sampler]
    KG --> S3[Community Sampler]
    S1 --> RP[reasoning_path]
    S2 --> RP
    S3 --> RP
    RP --> QA[Difficulty-aware QA]

Loading

Проекты

• AQ-MedAI-MedResearcher-R1: использует EnhancedGraphSampler (augmented_chain, dual_core_bridge, community_core_path, max_chain, mixed) для явного контроля multi-hop сложности.

Варианты и гибриды

В гибридном варианте топологический контроль комбинируется с тематическим или временным контролем (фильтры домена/эпохи). В R1 основной управляющий сигнал именно топологический.

---

Паттерн: Двухконтурный benchmark с ортогональными метриками

Описание

Паттерн разделяет оценку Deep Research-системы на два независимых контура, где каждый измеряет отдельную ось качества. Типичный разрез: «качество аналитического отчета» и «фактическая подтверждаемость утверждений по источникам». Контуры запускаются независимо и дают отдельные артефакты.

Архитектура решает проблему смешивания сигналов, когда один агрегированный score маскирует провал по важной метрике. Подходит для офлайн-бенчмарков, где нужна диагностичность и возможность донастраивать систему по отдельным аспектам качества.

Характерные черты

• Два независимых evaluation-контура с разными входами и метриками.
• Общий orchestrator запускает контуры последовательно или параллельно.
• Раздельные output-контракты и директории результатов.
• Возможность отдельного перезапуска и отладки каждого контура.

Типичная структура

flowchart TD
    IN[Benchmark Inputs] --> ORCH[Run Orchestrator]
    ORCH --> C1[Quality Contour]
    ORCH --> C2[Factuality Contour]
    C1 --> O1[results/quality/*]
    C2 --> O2[results/factuality/*]

Loading

Проекты

• Ayanami0730-deep_research_bench: реализует отдельные контуры RACE и FACT; первый сравнивает отчеты с reference, второй валидирует citation-факты через extract -> deduplicate -> scrape -> validate -> stat.

Варианты и гибриды

Частый гибрид добавляет третий контур для process-метрик (стоимость, latency, tool-efficiency). В минимальном варианте остаются только два ортогональных контура качества и фактичности.

---

Паттерн: Relative LLM-as-Judge с динамическими критериями

Описание

Паттерн строит judge-оценку не на фиксированном rubric, а на критериях, генерируемых под конкретную задачу. Оценка выполняется в относительном режиме, где target сравнивается с reference в одном акте судейства, а итог нормализуется как функция двух оценок.

Паттерн снижает калибровочный сдвиг между отдельными вызовами judge-модели и улучшает переносимость между темами запросов. Особенно полезен для heterogeneous benchmark-наборов, где статический набор критериев системно теряет релевантность.

Характерные черты

• Task-specific генерация критериев и весов перед judge-оценкой.
• Relative scoring (target против reference) вместо абсолютного single-score.
• Многократный sampling критериев/весов с усреднением для стабилизации.
• Поддержка fail-soft парсинга judge-ответов в структурированный формат.

Типичная структура

flowchart TD
    Q[Task Prompt] --> CG[Criteria Generator]
    CG --> RW[Weight Averaging]
    T[Target Report] --> J[LLM Judge]
    R[Reference Report] --> J
    RW --> J
    J --> P[Robust JSON Parse]
    P --> S[Relative Score Calculator]

Loading

Проекты

• Ayanami0730-deep_research_bench: генерирует критерии и веса под задачу, усредняет веса по нескольким sampling и считает итог через relative нормализацию target/(target+reference).

Варианты и гибриды

Вместо полного relative режима может использоваться pairwise rank без числовой нормализации. Также встречается гибрид с фиксированным «core rubric» и динамическими доменными критериями как дополнительным слоем.

---

Паттерн: Файлово-идемпотентный batch pipeline с restart-by-id

Описание

Паттерн организует офлайн-обработку как цепочку файловых стадий с append-friendly артефактами и строгим идентификатором записи. Каждый этап читает входные JSONL/текстовые файлы, записывает промежуточный результат и может быть безопасно перезапущен без потери уже обработанных элементов.

Паттерн решает проблему долгих и хрупких batch-прогонов при внешних API-зависимостях. Он обеспечивает воспроизводимость, контроль прогресса и операционную устойчивость при сетевых или форматных сбоях.

Характерные черты

• Файловые контракты между стадиями вместо in-memory orchestration.
• Resume/skip логика по id как механизм идемпотентности.
• Промежуточные артефакты как first-class чекпоинты.
• Retry/fallback в API и парсерах для fail-soft поведения.

Типичная структура

flowchart TD
    IN[Input JSONL] --> ST1[Stage N]
    ST1 --> ART1[Intermediate Artifact]
    ART1 --> CK[Processed ID Index]
    CK -->|resume| ST1
    ART1 --> ST2[Stage N+1]
    ST2 --> OUT[Final Result Files]

Loading

Проекты

• Ayanami0730-deep_research_bench: строит RACE/FACT как цепочки файловых шагов с resume по id, промежуточными JSONL-артефактами в results/* и fail-soft обработкой API/JSON-ответов.

Варианты и гибриды

Гибридный вариант совмещает file-checkpoints с очередями задач и worker-пулами. В lightweight-режиме достаточно последовательного CLI-скрипта с limit/force/resume флагами.