Archer

Archer —— 模型架构选型调研

把"领域专家想跟进最新模型架构"这件事从手工搜索整理，变成一条可复用的标准化工作流：定义领域 → 扫描时间窗内的多源候选 → 用领域视角做相关性判定 → 输出结构化清单。

When to Use This Skill

当用户提出以下需求时调用本技能：

• 想跟进特定领域（基因组 / 蛋白 / 单细胞 / 化学 / 材料 / 视觉 / 机器人 / RAG-Agent 等）最新可关注的模型架构
• 需要一份"可关注架构清单"用于内部分享、周报、季度汇报、技术选型讨论
• 想从最近的 arXiv / bioRxiv / Hugging Face / 中文技术源里系统性筛出与自己领域强相关的架构创新
• 想避免漏掉"非本领域但对本领域高相关"的通用 ML 进展（例如新的 SSM、tokenizer、长上下文、扩散 LM、MoE 路由等）
• 需要每个条目带有"为什么这个对我所在领域有价值"的判定理由（reason），而不仅是论文摘要

不适合的场景：

• 单篇论文深读（应使用 paper reading 类技能）
• 完整综述写作（应使用 research-assistant + 文档生成技能）
• 通用的网页搜索问答

输入与输出 / I/O

用户应提供的信息

调用前向用户确认以下信息（缺失即用默认值）：

字段	说明	默认值
domain	领域定位，越具体越好。例：「基因组基础模型 (gLM)，主要预训练在 DNA/RNA 序列」	必填
domain_scope	显式 inclusion / exclusion，例：「只关注 gLM，PLM 和 scFM 仅在与 gLM 联合建模时纳入」	与 domain 同步推断
time_window	时间窗，自然语言或日期范围	近 30 天
sources	来源范围	arXiv + bioRxiv + Hugging Face + 主流学术 + 中文技术源
relevance_axes	相关性判定维度，例：架构 / 预训练目标 / tokenization / 长上下文 / 评测基准	通用四类（见下）
output_formats	输出格式	JSON 必出，Markdown 可选
max_items	候选数量上限	12-15（精筛后）

输出

主输出：{date}.json，结构见下文「输出格式规范」。 可选输出：{date}.md，将 JSON 渲染为可读报告。

通用工作流 / Workflow

Step 0 — 锚定领域与 scope

1. 与用户确认 domain 描述、inclusion / exclusion 规则、时间窗、来源范围
2. 根据 domain 推断 4-6 个相关性判定轴（默认轴：架构骨干 / 预训练目标 / tokenization / 长上下文与效率 / 评测基准 / 跨模态）
3. 把 scope 写入工作笔记：/home/user/workspace/archer/{run_id}/scope.md

Step 1 — 多轮主题搜索（Round-Robin）

按下面 6 类发起并行搜索（每类 2-4 个 query），不要把多个领域塞进一个 query：

轮次	关注点	Query 模板（替换 {domain}）
R1	领域内直接论文	{domain} foundation model {year}-{month}、new {domain} architecture arxiv
R2	通用 ML 架构（SSM / Mamba / 注意力变体 / 混合架构）	Mamba SSM new architecture {date_range}、hybrid transformer state space {year}
R3	Tokenization / 长上下文	tokenizer-free dynamic chunking、long context million token attention {year}
R4	离散扩散 / 非自回归 LM	discrete diffusion language model {year}、non-autoregressive generation {date_range}
R5	MoE / 条件计算 / 路由	mixture of experts routing {year}、conditional computation {domain}
R6	中文技术源与 Hugging Face	中科院/北大/清华/上交/智源/字节/阿里达摩等机构博客 + Hugging Face 新模型 release

将每轮结果原始返回保存到 /home/user/workspace/archer/{run_id}/raw/，便于后续审查。

Query 写作纪律：

• 用自然语言短句，不要堆关键词
• 一个 query 一个主题
• 不在 query 中使用引号（会过度约束）
• 时间相关查询带年份/季度，如 2026 Q1、since March 2026

Step 2 — 候选收敛与去重

1. 合并所有原始结果，提取每条的 title / authors / venue / date / abstract / url
2. 去重（按 arXiv ID / DOI / 标题相似度）
3. 用 fetch_url 拿到关键候选（≥ 20 个）的完整摘要与日期，显式校验日期——不要把搜索片段里的日期当真，必须从论文页面 / OpenReview / bioRxiv 元数据确认
4. 保存到 /home/user/workspace/archer/{run_id}/candidates.json

日期校验失败处理：

• 如果日期超出用户指定的时间窗，仍可保留为「相邻窗口重要工作」，但需在 reason 字段说明
• 如果是 v2/v3 等版本更新落在窗口内，用 v 版本号注明

Step 3 — 相关性判定与 reason 撰写

这是 Archer 的核心差异化步骤。每个候选都要回答两个问题：

1. 它属于上面哪个相关性轴？（架构 / 预训练 / tokenization / 长上下文 / 评测 / 跨模态）
2. 它对用户的领域具体有什么价值？（不是泛泛的"可参考"，而是具体的"这个机制可以解决我们 X 任务上的 Y 痛点"）

reason 字段写作要求：

• 60-150 字
• 必须显式提到领域应用场景（例：「全基因组 1M-bp 上下文推理」「染色质 3D 结构 grounding」）
• 不要复述摘要——summary 字段已经做了这件事
• 如果是非本领域论文，必须解释「迁移到本领域的可行路径」

Step 4 — 精筛与排序

1. 按相关性轴均衡：每个轴至少 1-2 个，避免某一类过度集中
2. 按时效性排序（窗口内 > 相邻窗口）
3. 按重要性二次排序（核心方法创新 > 工程改进 > 基准评测）
4. 收敛到 max_items（默认 12-15）

Step 5 — 输出 JSON

按照 references/schema.json 的格式写入 /home/user/workspace/archer/{run_id}/{date}.json，并通过 share_file 发送给用户。

Step 6 — 可选 Markdown 报告

如果用户要求 Markdown，按 references/markdown-template.md 生成可读版本（包含分类表格、关键洞察小结）。

输出格式规范 / Output Schema

{
  "header": "🔬 {date_range} {domain} 可关注架构",
  "items": [
    {
      "title": "模型/方法名称（含一行点睛副标题）",
      "summary": "100-200 字客观摘要：核心思想、关键数字、与基线对比。来自论文，不掺评论。",
      "reason": "60-150 字领域价值判定：为什么对用户领域重要，具体应用路径或解决的痛点。带主观判断和迁移思路。",
      "link": "首选 arXiv / bioRxiv 链接，其次官方 blog 或 GitHub"
    }
  ]
}

完整 JSON Schema 见 references/schema.json，渲染示例见 assets/example-output.json。

领域适配指南 / Domain Playbooks

针对常见领域，相关性判定轴和搜索关键词有专门优化。详见 references/domain-playbooks.md，已内置：

• 基因组 / RNA 基础模型（gLM）
• 蛋白语言模型（PLM）
• 单细胞基础模型（scFM）
• 化学 / 材料 / 小分子 FM
• 视觉 / 多模态 FM
• 机器人 / 具身智能 FM
• RAG / Agent 架构

调用前应检查 domain 是否匹配某个 playbook，匹配则加载对应 axes 与 query templates。

质量自检清单 / QA Checklist

输出 JSON 前必须自检：

• 每个 item 的 link 已实际访问验证（不是搜索片段里推断的链接）
• 每个 item 的日期已通过页面元数据二次确认
• reason 字段不是 summary 的复述，明确提到领域应用
• 相关性轴覆盖均衡（不要全部集中在一类）
• 中英文混排时英文模型名/术语保持原文，不要翻译
• header 中的日期范围与 time_window 一致
• 不出现「source 1」「ref 2」式的占位引用——所有 link 都是真实 URL

Examples

触发示例 1：基因组领域专家

用户输入：「帮我做一份近两周的 gLM 可关注架构清单，scope 严格限定 DNA/RNA 序列预训练模型，PLM 和 scFM 不进主体。」

预期输出：JSON 文件，header 形如 🧬 2026.04.14–04.28 基因组基础模型可关注架构，items 包含 12-15 条，每条都带 reason 解释对 gLM 的具体价值（例如「Mamba-3 的复值 SSM 状态追踪能力可解决 gLM 在远程调控元件配对上的弱点」）。

触发示例 2：化学小分子领域

用户输入：「我做小分子生成模型，想跟一下最近一个月通用 ML 里有什么对分子图建模有启发的新架构。」

预期输出：以图神经网络新进展、几何深度学习、扩散生成模型为相关性轴的清单，reason 字段把 NLP/视觉里的进展映射到分子图场景。

触发示例 3：未指定领域

用户输入：「最近 AI 架构有什么新进展？」

响应：先用 ask_user_question 确认 domain（必填），不要直接跑通用清单——通用清单没有差异化价值，是这个 skill 要避免的反面用例。

常见错误与规避 / Common Pitfalls

错误	后果	规避
跳过 Step 0 直接搜	scope 不清，输出泛化	强制要求用户给 domain
reason 字段只是摘要复述	失去 Archer 的核心价值	写 reason 时必须显式提到领域应用
日期不二次校验	把过期论文当新工作	Step 2 必须 fetch_url 校验
把候选数量做到 30+	用户读不完，价值稀释	严格控制在 12-15，宁缺毋滥
相关性轴失衡	全是 SSM 或全是 MoE	Step 4 显式按轴均衡
中英混杂翻译	模型名被翻译失真	模型名 / 技术术语保留英文原文