DeerFlow systematic-literature-review 技能详解：从 arXiv 检索到 APA / IEEE / BibTeX 报告的五阶段流水线

DeerFlow（deer-flow）是一个开源的长时程 SuperAgent 运行框架，其 skills/public/ 目录下内置了大量可直接加载的领域技能。其中 systematic-literature-review（SLR）技能 专门解决“对一个研究主题做跨多篇论文的学术综述”这一高频需求：给定一个主题，它检索 arXiv、并行抽取每篇论文的结构化元数据、跨论文合成主题与分歧点，最终产出符合 APA、IEEE 或 BibTeX 格式的正式综述报告。读完本文，你将掌握该技能五阶段工作流的完整执行细节、检索脚本 arxiv_search.py 的查询语法与参数含义、子代理并行抽取的轮次调度策略，以及三种引用模板的关键排版规则，从而能在 DeerFlow 中稳定复现一份带主题合成的文献综述。

1. 技能定位：广度优先的综合，而不是单篇同行评审

SKILL.md 的 frontmatter 中，description 字段明确划定了触发条件：

当用户想要针对某主题做跨多篇论文的系统性综述（systematic literature review / survey / synthesis）时使用本技能；也覆盖注释性书目（annotated bibliography）和跨论文比较。检索 arXiv，输出 APA、IEEE 或 BibTeX 格式报告。不用于单篇论文任务——评审单篇论文请使用 academic-paper-review。

这与另一个技能形成互补分工：academic-paper-review 对单篇论文做深度同行评审，本技能则对一批论文做广度优先的综合（breadth-first synthesis）。SKILL.md 给出了明确的判流规则——如果用户甩给你一个论文 URL 并说“review this paper”，应路由到 academic-paper-review，而不是本技能。

适用场景与排除场景

应当使用本技能的用户意图：

• 主题性文献调研（"survey transformer attention variants"、"review the literature on diffusion models"）；
• 跨论文综合（"what do recent papers say about X"、"compare methodologies across papers on Y"）；
• 要求统一引用格式的系统性综述（"do an SLR on Z in APA format"）；
• 某主题的注释性书目（annotated bibliography）；
• 某领域一段时间窗口内的研究趋势概览。

不应使用本技能的情形：

• 用户只给一篇论文并要求评审（路由到 academic-paper-review）；
• 用户问的是一个不需要多源综合的事实性问题（直接回答即可）；
• 用户想要普通网络调研、不需要学术严谨性（用标准网页搜索）。

仓库中还附有一套触发评测集 trigger_eval_set.json，包含 20 条样例查询及其 should_trigger 判定：正例包括 "What does the literature say about RLHF?"（没有 "systematic" 关键词，但 "the literature" 隐含多论文综合）、"Compare evaluation frameworks used across LLM hallucination detection papers" 等 10 条；反例包括单论文 URL 评审、"What is the capital of France?" 这类事实问题、调试请求、翻译任务，以及 "Find me the best paper on reinforcement learning"（单数 "best paper" 暗示只要一个结果，不是跨论文调研）等 10 条。这套正反例集合实质上界定了技能的路由边界。

2. 五阶段工作流总览

SKILL.md 将完整流程固化为五个阶段，必须按顺序执行：

阶段	名称	核心动作	产物
Phase 1	Plan	与用户确认主题、范围、引用格式、输出位置	四项确认参数
Phase 2	Search arXiv	调用捆绑脚本 arxiv_search.py 检索	JSON 论文元数据（留在上下文）
Phase 3	Extract in parallel	通过 task 工具委派子代理并行抽取元数据	每篇论文的结构化 JSON
Phase 4	Synthesize & format	跨论文主题合成 + 按模板排版引用	报告主体
Phase 5	Save & present	保存报告文件并调用 present_files 展示	slr-<topic-slug>-<YYYYMMDD>.md

整个工作流中唯一落盘的文件是 Phase 5 的最终报告；Phase 2 的检索结果只保留在上下文中供 Phase 3 使用，不得中途写入文件。

3. Phase 1（Plan）：先确认四项关键参数

在做任何检索之前，必须先与用户确认以下四项。若有不明确之处，只问一个能覆盖所有缺失项的澄清问题，不要逐个追问：

1. Topic（主题）：用平实英文描述的研究领域，例如 "transformer attention variants"。
2. Scope（范围）：论文数量——默认 20 篇，硬上限 50 篇；可选时间窗口（如 "last 2 years"）；可选 arXiv 分类（如 cs.CL、cs.CV）。
3. Citation format（引用格式）：APA、IEEE 或 BibTeX；用户未指定且看不出在为特定投稿点写作时，默认 APA。
4. Output location（输出位置）：默认 /mnt/user-data/outputs/。

关于规模上限，SKILL.md 特别要求：如果用户说 "50+ papers"，应礼貌地把规模压到 50 篇并解释——超过这个数量后综合质量会快速劣化，更大的调研应按子主题拆分进行。这一上限并非随意设定，它与 Phase 3 的并发策略（每轮最多 3 个子代理、每批约 5 篇、最多约 3 轮）严格挂钩，后文会展开。

4. Phase 2（Search arXiv）：唯一允许的检索入口

4.1 调用捆绑脚本，禁止自行抓库

SKILL.md 用粗体强调：只能调用捆绑的检索脚本，不得用其他方式抓取 arXiv，也不得自己写 HTTP 客户端——因为该脚本已经正确处理了 URL 编码、Atom XML 解析和 id 归一化。标准调用方式：

python /mnt/skills/public/systematic-literature-review/scripts/arxiv_search.py \
  "<topic>" \
  --max-results <N> \
  [--category <cat>] \
  [--sort-by relevance] \
  [--start-date YYYY-MM-DD] \
  [--end-date YYYY-MM-DD]

其中 /mnt/skills 是 DeerFlow 运行时将仓库 skills/ 目录挂载进沙箱的容器路径（见 backend/docs/ARCHITECTURE.md 中的挂载表，以及 backend/docs/CONFIGURATION.md 中 container_path: /mnt/skills 的配置项）。脚本参数与源码中 argparse 定义一一对应（见 arxiv_search.py）：

参数	默认值	说明
query（位置参数）	必填	自由文本检索主题
--max-results	20	返回论文数，被硬性钳制在 50 以内
--category	无	arXiv 分类过滤，如 cs.CL、cs.CV、stat.ML
--sort-by	relevance	可选 relevance / submittedDate / lastUpdatedDate
--start-date / --end-date	无	提交日期范围（含端点），YYYY-MM-DD

4.2 查询措辞：为什么只能传 2–3 个核心关键词

SKILL.md 中有一条标注为 IMPORTANT 的规则：检索前必须先把主题浓缩为 2–3 个核心关键词，不能把用户的完整描述直接当作 query。原因是脚本对多词 query 会整体加双引号做 arXiv 短语匹配——"diffusion models" 返回相关论文没问题，而 "diffusion models in computer vision" 会变成精确 5 词短语匹配，大概率返回 0 条结果。领域限定词（"in computer vision"、"for NLP"）应放进 --category，时间限定词（"recent"、"last 2 years"）应放进 --start-date，都不属于 query 字符串。文档给出的对照表：

用户说	好查询	坏查询
"diffusion models in computer vision"	"diffusion models" --category cs.CV	"diffusion models in computer vision"
"transformer attention variants"	"transformer attention"	"transformer attention variants in NLP"
"graph neural networks for molecules"	"graph neural networks" --category cs.LG	"graph neural networks for molecular property prediction"

4.3 排序策略：几乎总是 relevance

• 始终优先 relevance 排序：arXiv 的 BM25 风格评分保证结果真的与主题相关；submittedDate 排序返回的是该分类下最新提交的论文，与主题无关度很高，容易产出大量跑题结果。
• 用户要 "recent" 论文或给出时间窗口时，正确做法是 --sort-by relevance 配合 --start-date，例如 "recent diffusion model papers" 应译为 --sort-by relevance --start-date 2024-01-01，而不是 --sort-by submittedDate。
• 仅当用户明确要求按时间先后排列（"show me papers in the order they were published"）时才用 submittedDate，这种情况很少见。
• lastUpdatedDate 很少有用，除非用户主动要求，否则忽略。

4.4 输出结构与失败处理

脚本向 stdout 打印一个 JSON 数组，每篇论文包含 9 个字段：id、title、authors、abstract、published、updated、categories、pdf_url、abs_url。其中 id 是裸 arXiv id（如 1706.03762），不带 URL、不带版本后缀；完整地址在 abs_url / pdf_url 里。

围绕这次调用，SKILL.md 规定了一组纪律性规则：

• 只执行一次检索。 结果不够理想时不要换措辞重试——arXiv 的相关性排序就是它本来的样子，反复重试浪费工具调用次数且有触发递归上限的风险。
• 结果为 0 篇时，告知用户并建议放宽主题或去掉分类过滤。
• 返回数量少于请求数时，这就是该 query 在 arXiv 上的真实结果集规模，不要凑数，如实报告实际数量并继续。
• 脚本失败（网络错误、arXiv 返回非 200）时，告知用户具体错误并停止，严禁伪造论文元数据。
• 不要把检索结果存文件，JSON 留在上下文中供 Phase 3 使用。

5. Phase 3（并行抽取）：必须委派子代理，且受 3 路并发硬约束

这是整个工作流中最“反直觉”的一步。SKILL.md 用 “non-negotiable” 措辞要求：元数据抽取必须通过 task 工具委派给子代理，主代理自己不得做抽取。明确列出的三条禁区：

• ❌ 写 python -c "papers = [...]" 或任何 Python/bash 脚本来批量处理论文；
• ❌ 在自己的上下文里逐篇读摘要做内联抽取；
• ❌ 本阶段使用 task 以外的任何工具。

理由是 token 经济学：10–50 篇论文的抽取放在主上下文里会消耗过多 token，拖累 Phase 4 的合成质量；而每个子代理运行在隔离上下文中，只持有自己那批论文的文本，产出更干净的抽取结果。

5.1 为什么是“每轮 3 个”：运行时并发上限

文档指出：子代理批大小约 5 篇，每轮最多 3 个子代理，因为 DeerFlow 运行时强制 MAX_CONCURRENT_SUBAGENTS = 3，同一轮里多派发的子代理会被静默丢弃——LLM 不会收到任何提示。这一约束在源码中可以逐一验证：

• executor.py 中定义了 MAX_CONCURRENT_SUBAGENTS = 3；
• subagent_limit_middleware.py 的构造函数默认值即引用该常量，对超出限额的派发做拦截；
• 子代理能力本身由运行时配置 subagent_enabled 门控：lead_agent/agent.py 中 subagent_enabled 取自 config.configurable，为真且存在可用子代理时才会装载 task 工具。

因此 SKILL.md 要求在 Notes 中把 subagent_enabled=true 列为本技能的前置条件：若该配置为假，task 工具根本不会出现在可用工具列表里，Phase 3 无法按设计执行；此时应告知用户“完整工作流需要启用子代理”，或退化为缩小/拆分请求做人工审阅，而不得谎称执行了并行方案。

5.2 轮次决策表：不要自己心算分批

为避免主代理自行计算分批方案，SKILL.md 直接给出决策表——按论文数量查表即可：

论文数	批次数（每批约 5 篇）	轮数	每轮子代理数
1–5	1 批	1 轮	1
6–10	2 批	1 轮	2
11–15	3 批	1 轮	3
16–20	4 批	2 轮	3 + 1
21–25	5 批	2 轮	3 + 2
26–30	6 批	2 轮	3 + 3
31–35	7 批	3 轮	3 + 3 + 1
36–40	8 批	3 轮	3 + 3 + 2
41–45	9 批	3 轮	3 + 3 + 3
46–50	10 批	4 轮	3 + 3 + 3 + 1

规则要点：

• 同一轮绝不派发超过 3 个子代理。表中 "2 轮 (3 + 1)" 的含义是：第一轮并行派发 3 个子代理，等 3 个全部完成，第二轮再派发 1 个。轮与轮之间在主代理层面严格串行。
• 论文数落在两行之间时（例如 23 篇），向上取到下一行的布局，但只派发实际需要的批数——决策表给的是“形状”，不是死规定。
• 分批动作发生在主代理层：主代理已持有 Phase 2 的全部摘要文本，每个子代理收到的就是纯文本输入，返回结构化 JSON。子代理不需要也不应该访问网络或沙箱——尤其不要让它重跑 arxiv_search.py，那会浪费 token 并有触发限流的风险。

5.3 子代理提示词与结果解析

每个子代理收到的结构化提示词模板（文档原文）：

Execute this task: extract structured metadata and key findings from the
following arXiv papers.

Papers:
[Paper 1]
arxiv_id: 1706.03762
title: Attention Is All You Need
authors: Ashish Vaswani, Noam Shazeer, ...
published: 2017-06-12
abstract: <full abstract text>

[Paper 2]
arxiv_id: ...
...

For each paper, return a JSON object with these fields:
- arxiv_id (string)
- title (string)
- authors (list of strings)
- published_date (string, YYYY-MM-DD)
- research_question (1 sentence, what problem the paper tackles)
- methodology (1-2 sentences, how they tackle it)
- key_findings (3-5 bullet points, what they actually found)
- limitations (1-2 sentences, what they acknowledge or what is obviously missing)

Return the result as a JSON array, one object per paper, in the same
order as the input. Do not include any text outside the JSON — no
preamble, no markdown fences, just the array.

解析子代理结果时有一个必须处理的工程细节：task 工具返回的是带固定前缀的字符串，形如 Task Succeeded. Result: [...JSON...]。解析前必须先剥掉 Task Succeeded. Result: 前缀（失败时则是 Task failed. / Task timed out. 前缀）。若某一批失败或返回不可解析的 JSON，记录它、注明受影响论文，然后继续处理其余批次——单个坏批不允许拖垮整个综合。全部轮次完成后，把各批数组扁平化为一个保持顺序的论文元数据列表。

6. Phase 4（合成与排版）：主题合成 + 三套引用模板

6.1 跨论文合成：报告不能只是论文列表

报告必须超越“逐篇罗列”。最低限度要识别出四类内容：

• Themes（主题）：3–6 个在论文集合中反复出现的研究方向、方法或问题框架；
• Convergences（共识）：多篇论文一致支持的发现；
• Disagreements（分歧）：论文间结论不同或方法论互不兼容之处；
• Gaps（缺口）：现有文献整体尚未覆盖的问题（通常直接来自各篇 limitations 字段的模式）。

如果论文集合太小或过于异质（例如 5 篇论文分属完全不同的子方向）以至于支撑不起主题合成，必须在报告中明说，不要硬造主题——“找不到主题就坦白说找不到”，这是文档定义的失败模式判定标准：一份只把论文一篇篇罗列的报告即视为失败。

6.2 引用模板：只读匹配的那一份

用户要的格式决定读哪份模板，只读一份，不要三份全读：

• templates/apa.md — APA 第 7 版。社科与多数非 IEEE 计算机期刊的默认。用户请求 APA 或未指定格式时使用。
• templates/ieee.md — IEEE 数字引用。用户面向 IEEE 会议/期刊或明确指定 IEEE 时使用。
• templates/bibtex.md — BibTeX 条目。用户提到 BibTeX、LaTeX 或想要机器可读参考文献时使用。关键点：arXiv 论文必须写 @misc，不是 @article。

每份模板同时包含引用规则与完整报告结构（Executive Summary、Themes、Per-Paper Annotations、References、Methodology 章节），要求逐字遵循模板结构写报告正文，再用 Phase 3 的元数据填充内容。三份模板的共同报告骨架为：

# Systematic Literature Review: <Topic>
**Date** / **Papers surveyed** / **Scope** / **Citation format**
## Executive Summary          # 3–5 句，只综合、不列论文
## Methodology               # 检索日期、query、分类、时间窗、排序方式 + 局限性声明
## Themes                    # 3–6 个主题小节
## Convergences and Disagreements
## Gaps and Open Questions
## Per-Paper Annotations     # 每篇一节：Research question / Methodology / Key findings / Limitations
## References（或 BibTeX Bibliography）

三份模板结尾都带一个“定稿前质量检查清单”，APA 版例如要求：每篇论文同时出现在 Annotations 与 References 中；正文引用与参考条目一一对应、无悬空引用；作者格式为 LastName, FirstInitial.；标题用 sentence case；arXiv 链接使用 abs_url 而非 pdf_url；参考文献按第一作者姓氏字母排序。

三种格式的核心差异速览：

格式	正文引用形式	arXiv 著录形式	特殊规则
APA 7th	(Vaswani et al., 2017)，三作者起用 et al.	... (2017). Title. arXiv. https://arxiv.org/abs/1706.03762	21 位及以上作者：列前 19 位 + ... + 末位作者；≤20 位全列
IEEE	方括号数字 [1]，按首次出现顺序编号	[1] A. Vaswani, ... and I. Polosukhin, "Title," arXiv:1706.03762, 2017.	6 位以上作者可用 et al.；作者名反排为 FirstInitial. LastName
BibTeX	正文用 \cite{key}，文末 fenced 代码块输出全部条目	@misc{vaswani2017attention, ... eprint = {1706.03762}, primaryClass = {cs.CL}}	cite key 为 <firstauthorlast><year><title首词> 全小写；author 之间用字面词 and；eprint 用裸 id（无 arXiv: 前缀、无版本后缀）；含特殊字符的姓名需转义（Łukasz → {\L}ukasz）

BibTeX 模板对 @misc 与 @article 的区分给出了详细论证：@article 要求 journal 字段，而 arXiv 是预印本服务器不是期刊，journal = {arXiv} 在技术上就是错的，部分文献样式还会报错或渲染不一致；只有当论文已被同行评审正式发表且你持有发表元数据时才切换为 @article/@inproceedings，而本工作流只有 arXiv 元数据，因此一律输出 @misc。primaryClass 字段取论文 categories 列表的第一项（如 cs.CL、stat.ML），作为 eprint 的补充元数据。

7. Phase 5（保存与展示）：文件名约定与预览纪律

1. 保存：完整报告写入 /mnt/user-data/outputs/slr-<topic-slug>-<YYYYMMDD>.md，<topic-slug> 是主题的小写连字符化形式（例如 transformer-attention）。
2. 展示：调用 present_files 工具传入该路径，让用户可以下载。
3. 聊天中的预览只包含三部分：Executive Summary 原文（3–5 句段落）；主题清单（主题名 + 一行释义，不是完整主题章节）；论文数量 + 文件指针，例如 “Full report with 20 papers, per-paper annotations, and formatted references saved to slr-transformer-attention-20260409.md.”。
4. 禁止把 2000+ 字的完整报告整体倾倒进聊天——逐篇注释、参考文献、方法论都归文件所有，预览只负责让用户一眼判断是否值得打开文件。

8. 源码级剖析：arxiv_search.py 的工程细节

scripts/arxiv_search.py 约 300 行、零第三方硬依赖（requests 可用则用，否则回退到内置的 urllib 兼容 shim），直接查询 arXiv 公共 API http://export.arxiv.org/api/query，无需 API key。文件头部 docstring 自述了四项设计考量，与代码逐条对应：

（1）查询构造与短语匹配。 _build_search_query() 生成 arXiv 自有查询语法（ti:、abs:、cat:、all: 配合 AND/OR/ANDNOT）。用户主题用 all: 前缀（同时匹配标题、摘要、作者），可选 AND 上 cat: 分类过滤，以及 submittedDate:[YYYYMMDDHHMM TO YYYYMMDDHHMM] 日期区间（缺省端点为 19910101 / 29991231）。关键细节在第 107–114 行的注释：多词 query 会被整体包进双引号——不加引号时 all:diffusion model 会被 arXiv 的 Lucene 解析器读成 all:diffusion OR model，把只要提到 “model” 的无关论文全拉进来；加了引号才成为短语匹配。这正是 SKILL.md “2–3 个关键词”规则在代码层的直接原因。

（2）arXiv id 归一化。 arXiv Atom 响应中的 <id> 是完整 URL（如 http://arxiv.org/abs/1706.03762v5），而调用方通常要裸 id。_normalise_arxiv_id() 同时兼容现代格式（1706.03762v5 → 1706.03762）与旧式档案前缀格式（hep-th/9901001v1 → hep-th/9901001）。

（3）Atom 命名空间。 arXiv 的 Atom feed 用 atom: 承载核心字段、arxiv: 前缀扩展 primary_category 等元素。NS_MAP 把两个命名空间硬编码进常量——注释直言“忘记命名空间前缀是 arXiv API 解析的第一大 bug”。解析函数 _parse_entry() 还做了两处面向下游 LLM 的清理：ISO 8601 日期只保留日期部分；摘要的内部空白统一折叠为单空格，降低 LLM 消费成本。

（4）50 篇上限与超时。 search() 中 max_results 被 min(max_results, MAX_RESULTS_UPPER_BOUND) 钳制在 50，sortOrder 固定 descending，HTTP 超时 30 秒。CLI 失败路径（main()）把异常打印到 stderr 并以退出码 1 结束，与 SKILL.md “失败即停止、不得伪造元数据” 的纪律呼应。

脚本的 --category、--sort-by（choices 限定三个值）等参数约束，也与 SKILL.md 第 4 节的策略建议一一对应——文档层与代码层的纪律是同一套。

9. 评测体系：如何验证技能行为符合设计

该技能自带端到端评测 evals/evals.json，5 个用例把 SKILL.md 的关键规则转成了可断言的 expectations：

• 用例 1（10 篇 cs.CV / 近 2 年 / APA）：断言 query 是短关键词而非完整主题描述、用了 --category cs.CV、--sort-by relevance、只执行一次检索、抽取经 task 工具委派而非 python -c 内联处理、读了 templates/apa.md、文件名符合 slr-<topic-slug>-<YYYYMMDD>.md、调用了 present_files、报告含 Executive Summary、≥3 个带跨论文分析的主题、Convergences and Disagreements、Gaps and Open Questions、全部 10 篇的逐篇注释。
• 用例 2（5 篇 BibTeX）：断言读的是 bibtex.md 而非 apa/ieee 模板、条目全部是 @misc 且包含 eprint 与 primaryClass 字段。
• 用例 3（15 篇 IEEE）：断言 15 篇按 3 批 × 5 篇派发子代理、正文使用 [1]、[2] 式数字引用。
• 用例 4（单论文 URL）：断言 SLR 技能不被触发、不调用 arxiv_search.py、识别为单篇评审请求并路由 academic-paper-review。
• 用例 5（"What does the literature say about RLHF?"）：断言即便没有 "systematic"/"survey" 关键词也要触发，且应提出范围澄清或使用合理默认值。

配合 trigger_eval_set.json 的 20 条触发判定，这套评测完整覆盖了“何时触发、检索怎么调、抽取怎么委派、格式怎么落、边界怎么拒”五条行为轴，是理解该技能设计意图的第二份权威文档。

10. 实战前提与边界

汇总 SKILL.md Notes 章节的硬约束，落地前务必核对：

1. 前置条件 subagent_enabled=true：Phase 3 硬依赖 task 工具，该工具仅在运行时配置 config.configurable.subagent_enabled 为真时装载（见 lead_agent/agent.py 与 #L917-L920 的门控逻辑）。不可用时如实告知用户，或提供缩小/拆分的降级方案，不得声称执行了并行计划。
2. arXiv 单一来源是刻意设计：技能不查询 Semantic Scholar、PubMed、Google Scholar。arXiv 覆盖了 CS/ML/物理/数学预印本的大头，而这正是 DeerFlow 用户最常调研的范围；多源学术检索被明确划归“专门的 MCP server”的职责，不属于本技能。
3. 50 篇硬上限：与 Phase 3 的并发形状（3 子代理/轮 × 约 5 篇/批 × 最多约 3–4 轮）绑定，超限调研应按子主题拆分。
4. 子代理结果永远是字符串：解析前剥 Task Succeeded. Result: / Task failed. / Task timed out. 前缀。
5. id 是裸 arXiv id：引用格式中需要完整 URL 时使用 abs_url / pdf_url。
6. 合成而非罗列：最终报告必须给出主题与跨论文比较；只罗列即失败模式，找不到主题就明说。

端到端示例（文档 Examples 节）

• 典型请求：“Do a systematic literature review of recent transformer attention variants, 20 papers, APA format.” → Phase 1 确认主题/范围/格式（缺什么才问什么）→ Phase 2 执行 arxiv_search.py "transformer attention" --max-results 20 --sort-by relevance --start-date 2023-01-01 → Phase 3 第一轮 3 子代理 × 5 篇、第二轮 1 子代理 × 5 篇 → Phase 4 读 templates/apa.md 按其结构成文 → Phase 5 存为 slr-transformer-attention-20260409.md 并调用 present_files。
• 含糊的小集合请求：“Survey a few papers on diffusion models for me.” → “a few” 有歧义，问一个问题：“要 10、20 还是 30 篇？引用格式偏好？（默认 APA）” → 用户答 "10, BibTeX" → arxiv_search.py "diffusion models" --max-results 10 --category cs.CV → 单轮 2 子代理 × 5 篇 → 用 @misc 条目排版。
• 越界请求：“Here's one paper (https://arxiv.org/abs/1706.03762). Can you review it?” → 这是单篇评审，不触发本技能，路由 academic-paper-review。

小结

systematic-literature-review 技能的价值不在某一个单点，而在于把“文献综述”这件模糊任务固化成了一条可验证的流水线：四项参数确认 → 短语匹配检索（短关键词 + relevance + 日期窗）→ 受 MAX_CONCURRENT_SUBAGENTS = 3 约束的轮次化并行抽取 → 主题/共识/分歧/缺口四维合成 → 三选一引用模板排版落盘。所有关键纪律（查询措辞、单次检索、子代理委派、@misc 著录、文件命名）都能在 arxiv_search.py 的实现与 evals.json 的断言中找到对应证据，这使得它不仅是一份“提示词”，更是一套行为契约明确的工程化技能实现。