Literature Review Council

io.github.Ravicha2由 GitHub 账号 Ravicha2 发布v0.1.4更新于 Oct 24, 2026

Multi-agent literature review: research, peer review, and synthesize grounded reports.

发布方自己的服务:Review Expert

概览

AI 生成的概览

运行多智能体文献综述流程,研究主题、进行同行评审,并生成有来源依据的 Markdown 报告合集。

可以做什么
协调多个专用智能体,从学术与工程实践两个角度研究配置好的主题,使用 ArXiv、OpenAlex、Tavily 和 GitHub 搜索。三个评审智能体对匿名化报告进行排序,并用 Borda 计票选出优胜报告。随后综合智能体生成最终简报,进行引用校验,拒绝悬空引用以及不在原始来源中的网址,并写出带索引文件的互联 Markdown 合集。
适用场景
适合让助手针对一个或多个研究主题生成结构化、有来源依据的文献综述,尤其是需要同时兼顾学术与工程视角并带有自动同行评审步骤的场景。它更适合研究规划与报告撰写,而非快速单问题查询。
运行要求
通过 uvx 从 PyPI 包 lit-review-council 在本地运行,需要 Python/uv 运行时。需要 OPENROUTER_API_KEY、GITHUB_TOKEN 和 TAVILY_API_KEY;OPENALEX_API_KEY 为可选。可选模型覆盖变量为 ENG_MODEL、RESEARCH_MODEL 和 JUDGE_MODEL。需要能访问搜索与 LLM 服务商的网络。
安装前请注意
需要三个密钥:OPENROUTER_API_KEY、GITHUB_TOKEN 和 TAVILY_API_KEY,其中 GitHub 令牌会以你的账号身份访问 GitHub 搜索。研究主题与查询会发送给第三方搜索和 LLM 服务商,相关账号可能产生费用。该流程会在你机器上的输出目录写入报告文件。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Literature Review Council,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

Multi-Agent Literature Review Pipeline

[alt text]

A multi-agent literature review pipeline built with the Google ADK (Agent Development Kit). It coordinates specialized agents to iteratively research sub-topics based on a YAML configuration. For each topic, it searches from academic and practitioner perspectives, evaluates the work through a peer review ensemble, and synthesizes a well-grounded report.

Built as a capstone submission for the Kaggle "AI Agents: Intensive Vibe Coding Capstone".

mcp-name: io.github.Ravicha2/lit-review-council

Motivation

Literature reviews are suffocating: hundreds of papers, conflicting claims, and no obvious signal in the noise. Andrej Karpathy's LLM Council showed that multi-agent debate surfaces sharper answers than a single prompt. This project takes that insight into the research domain.

LLMs researching complex topics suffer from two problems: lack of diverse grounding and self-preference bias (favoring their own outputs).

This pipeline addresses both:

  1. Tiered Orchestration: A Planner agent splits configured research topics into a multi-wave execution graph. Foundational concepts (Wave 1) run in parallel, and synthesis-dependent topics (Wave 2) run sequentially with distilled context from Wave 1.
  2. Source Isolation: Two independent tracks per topic, each with its own explorer (search) and reporter (write) agent. The academic track searches ArXiv, OpenAlex, and scholarly publishers. The practitioner track searches GitHub and engineering docs.
  3. Peer Review Ensemble: Three reviewers (Researcher, Engineer, Neutral) evaluate anonymized reports. Borda-count voting aggregates rankings so no single reviewer dominates.
  4. Anti-Hallucination Guardrails: The Synthesis agent's output is parsed and validated. Dangling citations like (Author, Year) or [1] are rejected. Every URL in the final report must exist in the original source references, or the run is retried (up to 2 times). A blog-tier ratio check warns when over 50% of sources are blog/forum tier.

Setup & Installation

Published to PyPI and the MCP Registry. No clone or manual config needed.

1. MCP Registry (Recommended, one command)

The server is listed on the MCP Registry, so installing is a single command. No JSON editing, no config files.

Claude Code:

bash
claude mcp add lit-review-council \  -e OPENROUTER_API_KEY=sk-or-your-key \  -e GITHUB_TOKEN=ghp_your-token \  -e TAVILY_API_KEY=tvly_your-key \  -- uvx lit-review-council

VS Code: Search for "lit-review-council" in the MCP Registry and click Install. Or open the MCP Registry listing and click Install in VS Code.

Any other MCP client: See section 2 below.

Once connected, the lit_review_council_instructions prompt is available to guide any AI agent through the full review workflow.

2. Manual Config (Claude Desktop, Cursor, etc.)

Add this to your client's MCP server config:

json
{  "mcpServers": {    "lit-review-council": {      "command": "uvx",      "args": ["lit-review-council"],      "env": {        "OPENROUTER_API_KEY": "sk-or-your-key",        "GITHUB_TOKEN": "ghp_your-token",        "TAVILY_API_KEY": "tvly_your-key",        "OPENALEX_API_KEY": "your-key"      }    }  }}
ClientConfig path
Claude Desktop (Mac)~/Library/Application Support/Claude/claude_desktop_config.json
Claude Desktop (Win)%APPDATA%\Claude\claude_desktop_config.json
Cursor.cursor/mcp.json

3. Local Developer Setup

bash
git clone https://github.com/Ravicha2/lit-review-council && cd lit-review-councilcp .env.example .env   # fill in your keysuv run python main.py --config topics.yaml --output okf_output --question "Your Research Question"

Environment Variables

VariablePurposeRequired
OPENROUTER_API_KEYLLM access via OpenRouterYes
GITHUB_TOKENPractitioner track (GitHub search)Yes
TAVILY_API_KEYWeb search across both tracksYes
OPENALEX_API_KEYAcademic track (OpenAlex API)No
ENG_MODELModel for engineer agentsNo (default: openrouter/moonshotai/kimi-k2.6)
RESEARCH_MODELModel for research agentsNo (default: openrouter/z-ai/glm-5.1)
JUDGE_MODELModel for reviewers & synthesisNo (default: openrouter/deepseek/deepseek-v4-pro)

Architecture

[Pipeline Architecture]

The pipeline is organized into four stages, with topics executed across two waves to balance parallelism and sequential dependency.

Why Two Waves?

Not all research topics are independent. Some topics (e.g., foundational concepts like "truth maintenance systems") can be researched in parallel, while others (e.g., "multi-agent coordination using TMS") depend on the synthesized understanding of earlier topics.

The Planner agent reads topics.yaml and partitions topics into:

  • Wave 1 — parallel, independent topics. All topics in this wave run simultaneously through the full Stage 1→2→3 pipeline.
  • Wave 2 — sequential, dependent topics. These topics require the distilled context from Wave 1 before they can be researched accurately.

Wave Handoff via the Distiller

After Wave 1 completes, the Distiller agent consumes the Wave 1 topic files and produces a compact summary of the foundational findings. This distilled context is injected into every Wave 2 topic's prompt as additional background, ensuring Wave 2 explorers and reporters build on top of verified Wave 1 conclusions rather than starting from scratch.

This prevents redundant searches and improves coherence across the final OKF bundle.

Stage Breakdown

ini
Stage 0 (Orchestration)├── Planner agent organizes YAML topics into Wave 1 (parallel) and Wave 2 (sequential)└── Distiller agent summarizes completed Wave 1 topics to provide prior context to Wave 2
Stage 1 (Parallel Fan-out per Topic)├── Academic Track (SequentialAgent)│   ├── academic_explorer  → searches ArXiv, OpenAlex, Tavily (scholarly domains)│   └── academic_reporter  → writes Researcher report with structured references└── Practitioner Track (SequentialAgent)    ├── practitioner_explorer → searches GitHub, Tavily (engineering domains)    └── practitioner_reporter → writes Engineer report with structured references
Stage 2 (Peer Review Ensemble per Topic)├── researcher_reviewer  → ranks anonymized reports (Researcher perspective)├── engineer_reviewer    → ranks anonymized reports (Engineer perspective)└── technical_reviewer   → ranks anonymized reports (Neutral perspective)    → Borda-count tally → winning report selected
Stage 3 (Synthesis & Persistence)├── synthesis agent → condensed final brief with YAML frontmatter│   → citation validation loop (rejects hallucinated/dangling URLs, retries up to 2x)└── Writes out to an interconnected Markdown OKF bundle (index.md and topic files)

Search Providers

ProviderDomainsUsed By
ArXiv APIarxiv.orgAcademic explorer
OpenAlex APIopenalex.orgAcademic explorer
Tavily (scholarly)acm.org, ieee.org, springer.com, sciencedirect.com, nature.com, science.org, wiley.comAcademic explorer
GitHub APIgithub.comPractitioner explorer
Tavily (engineering)github.com, docs.microsoft.com, aws.amazon.com, cloud.google.com, medium.com, dev.toPractitioner explorer

All providers use tenacity retry with exponential backoff for 429/5xx errors.

Source Tiers

Every reference is classified into one of four tiers:

  • peer_reviewed: ArXiv preprints, ACM/IEEE papers, conference proceedings
  • established_project: GitHub repos with meaningful adoption (stars, active maintenance)
  • vendor_doc: Official documentation from a company/project
  • blog_or_forum: Medium, personal blogs, Stack Overflow, Reddit

The synthesis step warns when more than half of cited sources are blog_or_forum tier.

Output

The pipeline runs all stages for each topic, executing them in waves where possible. On completion, it generates an interconnected Markdown bundle (OKF format) in the specified output directory, including an index.md linking to each specific topic file.

来源:README.md,提交 40c4c19

工具

0
SourceWeft 尚未在沙箱中启动过该软件包,因此其工具未知。

版本历史

1
  1. v0.1.4最新Sep 16, 2026

评分

已满足适用检查项的 40%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分

    请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。

  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分

    请在仓库或注册中心条目中声明许可证。

其他 Review 集成