Literature Review Council

多 Agent 文献综述流水线

一个使用 Google ADK（Agent Development Kit）构建的多 Agent 文献综述流水线。它根据 YAML 配置协调专门的 Agent，迭代研究各个子主题。对于每个主题，它从学术和实践者视角进行搜索，通过同行评审集成评估相关工作，并综合生成一份依据充分的报告。

作为 Kaggle “AI Agents: Intensive Vibe Coding Capstone”的结业项目提交。

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

动机

文献综述令人窒息：数百篇论文、相互矛盾的论点，以及纷乱信息中难以辨识的有效信号。Andrej Karpathy 的 LLM Council 展示了多 Agent 辩论比单个提示词能得出更精确的答案。本项目将这一思路应用于研究领域。

大模型研究复杂主题时会面临两个问题：缺乏多元依据，以及自我偏好偏差（偏袒自身输出）。

本流水线通过以下方式解决这两个问题：

1. 分层编排：规划 Agent 将配置的研究主题拆分为多波次执行图。基础概念（第 1 波）并行运行，依赖综合结果的主题（第 2 波）则按顺序运行，并使用从第 1 波提炼出的上下文。
2. 来源隔离：每个主题设有两条独立路径，各自配备探索 Agent（搜索）和报告 Agent（撰写）。学术路径搜索 ArXiv、OpenAlex 和学术出版商；实践者路径搜索 GitHub 和工程文档。
3. 同行评审集成：三位评审者（研究员、工程师、中立评审者）对匿名报告进行评估。使用 Borda 计数投票汇总排名，避免任何单一评审者占据主导。
4. 防幻觉护栏：综合 Agent 的输出会经过解析和验证。诸如 (Author, Year) 或 [1] 这样的无对应来源引用会被拒绝。最终报告中的每个 URL 都必须存在于原始来源引用中，否则将重试（最多 2 次）。当超过 50% 的来源属于博客／论坛级别时，博客级别占比检查会发出警告。

设置与安装

已发布到 PyPI 和 MCP Registry。无需克隆或手动配置。

1. MCP Registry（推荐，一条命令）

该服务已列入 MCP Registry，只需一条命令即可安装。无需编辑 JSON，也无需配置文件。

Claude Code：

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： 在 MCP Registry 中搜索“lit-review-council”，然后点击 Install。也可以打开 MCP Registry 条目，点击 Install in VS Code。

其他 MCP 客户端： 请参阅下方第 2 节。

连接后，即可使用 lit_review_council_instructions 提示词，引导任何 AI Agent 完成完整的综述工作流。

2. 手动配置（Claude Desktop、Cursor 等）

将以下内容添加到客户端的 MCP 服务配置中：

{
  "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"
      }
    }
  }
}

客户端	配置路径
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. 本地开发者设置

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

环境变量

变量	用途	必需
OPENROUTER_API_KEY	通过 OpenRouter 访问大模型	是
GITHUB_TOKEN	实践者路径（GitHub 搜索）	是
TAVILY_API_KEY	搜索两条路径中的网页	是
OPENALEX_API_KEY	学术路径（OpenAlex API）	否
ENG_MODEL	工程师 Agent 使用的模型	否（默认值：openrouter/moonshotai/kimi-k2.6）
RESEARCH_MODEL	研究 Agent 使用的模型	否（默认值：openrouter/z-ai/glm-5.1）
JUDGE_MODEL	评审者和综合 Agent 使用的模型	否（默认值：openrouter/deepseek/deepseek-v4-pro）

架构

流水线分为 四个阶段，主题分两 轮 执行，以兼顾并行处理与顺序依赖。

为什么分两轮？

并非所有研究主题都相互独立。有些主题（例如“真值维护系统”这类基础概念）可以并行研究，而另一些主题（例如“使用 TMS 进行多 Agent 协调”）则依赖对前面主题的综合理解。

规划器 Agent 读取 topics.yaml，并将主题划分为：

• 第 1 轮 — 并行且相互独立的主题。本轮所有主题都会同时经过完整的第 1→2→3 阶段流水线。
• 第 2 轮 — 顺序执行且存在依赖关系的主题。这些主题需要先获得从第 1 轮提炼出的上下文，才能准确开展研究。

通过提炼器交接轮次

第 1 轮完成后，提炼器 Agent 会使用第 1 轮的主题文件，生成一份基础研究结果的精简摘要。提炼后的上下文会作为补充背景注入第 2 轮每个主题的提示词，确保第 2 轮的探索者和报告撰写者能够基于经验证的第 1 轮结论继续工作，而不是从头开始。

这样可以避免重复搜索，并提升最终 OKF 整体内容的一致性。

阶段细分

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)

搜索提供方

提供方	域名	使用方
ArXiv API	arxiv.org	学术探索者
OpenAlex API	openalex.org	学术探索者
Tavily（学术）	acm.org, ieee.org, springer.com, sciencedirect.com, nature.com, science.org, wiley.com	学术探索者
GitHub API	github.com	实践者探索者
Tavily（工程）	github.com, docs.microsoft.com, aws.amazon.com, cloud.google.com, medium.com, dev.to	实践者探索者

所有提供方在遇到 429/5xx 错误时，都会使用 tenacity 重试并采用指数退避策略。

来源分级

每条参考资料都会归入以下四个级别之一：

• peer_reviewed：ArXiv 预印本、ACM/IEEE 论文、会议论文集
• established_project：具有一定采用度的 GitHub 仓库（星标数较高、维护活跃）
• vendor_doc：公司或项目的官方文档
• blog_or_forum：Medium、个人博客、Stack Overflow、Reddit

如果引用来源中超过一半属于 blog_or_forum 级别，综合步骤会发出警告。

输出

流水线会为每个主题运行所有阶段，并尽可能分轮执行。完成后，它会在指定的输出目录中生成一个相互关联的 Markdown 包（OKF 格式），其中包含一个 index.md，用于链接到各个主题文件。