mcpField
G
generate-theories

generate-theories

github.com/allenai生产力4260 次安装1 天前更新
代码仓库

关于 generate-theories

generate-theories 是围绕 Theorizer 的科研理论生成技能,通过文献检索、证据提取、理论形成和新颖性评估处理研究问题。适用于需要从已发表论文探索证据与研究空白的科研工作。

主要功能

  1. 01检索论文并提取结构化证据
  2. 02从证据形成理论及依据
  3. 03评估理论主张的新颖性
  4. 04支持分阶段或端到端运行
  5. 05构建提取模式并补充论文

适用场景

  1. 01围绕研究问题生成文献支撑的理论
  2. 02寻找支持或反驳假设的论文证据
  3. 03评估理论主张是否已有研究确立

MCP 相关

README 未说明其与 MCP 的关系。

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/allenai/asta-plugins --skill generate-theories

安装后在 Claude Code 中输入/generate-theories确认已加载。

详细介绍

生成理论

使用 Theorizer Agent(通过 asta-gateway)查找论文、提取证据、撰写理论并评估新颖性。身份验证:asta auth login。

CLI 根据 Agent 卡片生成,涵盖所有子命令、标志和默认值。你可以自行查看可用内容:

  • asta generate-theories --help — 列出子命令。
  • asta generate-theories card — 查看完整 Agent 卡片。
  • asta generate-theories describe <skill-id> — 查看某项技能的输入架构。

这项技能分为两部分。第一部分介绍 Theorizer 是什么——它的三个可组合阶段、捆绑的端到端版本,以及独立子命令。第二部分介绍如何端到端处理 generate-theories 请求——选择模式、完善问题、分派任务、设置检查点、交接和处理错误。

这项技能适用的场景

  • 根据研究问题生成以文献为依据的科学理论(“X 如何影响 Y,通过什么机制,在什么领域中”)。
  • 在已发表的论文中寻找支持或反驳假设的证据。
  • 根据现有文献评估理论的新颖性。
  • 通过提取的变量和研究发现,调查某个研究领域中已知和未知的内容。

流程

Theorizer 的文献驱动理论生成由三个可组合阶段组成:

literature-theory-generation = find-and-extract → form-theory → evaluate-novelty
  • find-and-extract — 根据研究问题搜索论文,并通过提取架构从每篇论文中提取与理论相关的发现(实体、变量、结果),整理成结构化表格。输出:论文列表和提取的发现。此阶段尚不生成理论。
  • form-theory — 根据提取结果撰写一组精简的理论。每个理论由几条简短定律组成(例如 “X 导致 Y”),并附上支持和冲突的论文证据。可接受之前运行的 task_id,也可接受用户提供的提取结果。
  • evaluate-novelty — 根据检索到的文献为每条理论陈述评分,将每项主张标记为已有定论、可从已知研究推导,或确属新发现。可接受之前运行的 task_id,也可接受用户提供的理论。

literature-theory-generation 是捆绑的端到端版本,会连续运行全部三个阶段,不会暂停。适合用户希望一次获得结果的情况;如果用户希望在阶段之间检查或引导流程,则不太适用。

另外两个独立子命令补全了可用功能:

  • build-extraction-schema — 规范研究问题、起草论文搜索查询,并生成供 find-and-extract 使用的提取架构。适用于用户希望在运行流程前检查或整理架构的情况;将生成的架构通过 extraction_schema 参数传给 find-and-extract 或 literature-theory-generation。
  • resume-extraction — 向之前的运行添加更多论文,并从中提取发现。适用于论文下载失败后,或希望扩充之前运行的证据基础而不从头开始的情况。

如何运行

以下各节介绍处理 generate-theories 请求的步骤——要询问什么、要展示什么,以及何时展示。

两种模式:自动与分步

由于此流水线可组合,用户可以选择让它从头到尾自动运行,也可以逐阶段推进。

  • 自动 — 单次调用 literature-theory-generation。提交、等待并呈现结果。速度最快;用户无法在运行过程中介入。
  • 分步 — 分别调用三个阶段。每个阶段结束后,向用户展示结果,并询问是继续、停止还是编辑。速度较慢,但可控;用户可以筛选论文、优化查询,或在获得所需内容后停止。

在会话中用户首次请求生成理论时,在整理好问题后、提交之前,通过 AskUserQuestion 询问他们想用哪种模式,并将这两个选项作为选项提供。在每个选项的说明中简要解释其利弊。

用户回答后,在本次会话的剩余时间内记住他们的选择。如果他们之后表示想切换到另一种模式(“其实,直接运行吧”/“等等,我想先看看论文”),就按其要求执行,无需再次确认。

例外:如果用户最初的表述已经明确选择了某种模式(“直接运行吧”“使用默认设置”“我会在提取之前先审阅论文”),则跳过提问,并按其暗示的选择执行。

阶段之间

采用分步模式时,每个阶段完成后,先在聊天中提供清晰的摘要,帮助用户做出接下来的决定,然后提供三个选项:

选项后续操作
继续使用本次运行的输出执行下一阶段
停止在此结束。通过 Asta Artifacts 交接流程呈现已有结果
编辑继续之前进行修改(见下文)

摘要应简明扼要,并围绕决策展开,而不是罗列所有内容。

find-and-extract 之后:
  • 展示论文列表(标题 + 每篇论文提取内容的 1 行摘要)。
  • 编辑表示:用户可能想添加或移除特定论文、编辑用于收集证据的提取架构,或使用优化后的查询重新开始。
form-theory 之后:
  • 展示理论:名称 + 2-3 句核心观点 + 支持/反驳论文的数量。
  • 编辑表示:使用不同的 generation_objective(侧重准确性或新颖性)重新运行 form-theory,或使用部分提取结果重新运行。
evaluate-novelty 之后:
  • 这是最后一个阶段,没有“继续”选项。
  • 用通俗易懂的语言展示每个理论的新颖性标签。
  • 编辑表示:针对优化后的理论子集重新评估新颖性,或转入 find-literature,对特定观点进行质疑。

如果用户在任何阶段选择停止,请像往常一样移交给 Asta Artifacts,以导出并索引已生成的内容。不完整的提取结果和理论也都是有效的产物。

明确问题

这仅适用于下一次调用会生成或构建理论的情况——具体来说,是 literature-theory-generation(完整流程)或 form-theory(独立运行或继续运行)。如果下一次调用会触发 find-and-extract、evaluate-novelty 或 resume-extraction,不要调整查询。

Theorizer 既适用于宽泛问题,也适用于具体问题。 它的许多价值在于针对宽泛或探索性问题广泛检索文献,从中发掘用户没想到要提及的变量、机制和适用范围。用户已经清楚自己想要什么时,具体问题也很有用,但这并非运行的前提。不要把问题不够具体视为运行前必须解决的问题。

Theorizer 的理论问题可以涉及以下四个维度中的部分或全部;如果用户对这些维度已有想法,提供相关信息有助于 Agent 更精准地开展工作:

  1. 干预变量——被改变的自变量(例如,来源引用、响应延迟、拟人化措辞)。
  2. 结果变量——具体的因变量(例如,信任、留存率、任务完成情况)。
  3. 中介机制(可选)——假设的效应驱动因素(例如,感知透明度、认知负荷、锚定效应)。Theorizer 无需中介机制也能运行;只有用户提供了相关信息时才将其纳入。
  4. 适用范围——理论应适用的领域(例如,消费级聊天机器人、企业搜索、编码 Agent)。

以下是三个要素齐全的问题示例(第二个示例包含可选机制)——它们只是 Theorizer 接受的一种问题风格示例,并非每个问题都必须遵循的模板:

  • 构建一个理论,说明间隔提取练习如何影响本科 STEM 课程中的长期记忆保留。
  • 构建一个理论,说明间歇性禁食如何通过上调自噬影响患有代谢综合征的成年人的胰岛素敏感性。
  • 构建一个理论,说明计划性烧除如何影响北美温带草原的草地生物多样性。

像“人们为什么会信任 AI?”这样的宽泛问题本身就是完全有效的输入。提出缩小问题范围只是出于礼貌,并非门槛。

在同一会话中,除非用户实质性地更改问题,否则后续运行时不要再次调整问题。反复来回只会增加阻力。

如何处理用户的问题 — 先审查,再分流:

不要猜测用户没有明确说明的干预、结果和范围,也不要擅自缩小问题范围——这样会让整个流程都围绕用户从未选择的角度展开。如果你想以任何方式缩小或更改问题,请先询问;不要自行推断。

**先审查:**判断用户的问题是否已经说明干预、结果和范围,还是较宽泛/探索性的问题(其中一个或多个维度尚未明确)。

然后分流:

  1. 直接继续,不作说明:如果问题已明确包含这些维度,或者用户现在或此前已表示希望按现有问题继续。不要宣布审查结果,也不要告诉用户问题“格式完善”——直接进入下一步调度。如果问题本身已具备相关实质内容,就由你添加“构建关于……的理论”这一表述;否则按用户原样提交问题。
  2. 提供选项,不设门槛:如果问题较宽泛,或某个必要维度尚未明确,而且你还没有提供过选项,请在一条消息中说明问题看起来较宽泛/探索性,Theorizer 可以直接处理这类问题,并询问用户是想保持宽泛,还是想补充某个特定维度的细节。明确说明,如果用户不想花时间细化,默认会按现有问题直接运行——绝不要暗示必须等用户回答后才能开始。你也可以告知用户,先从宽泛的问题开始探索,之后再根据发现的理论逐步缩小关注范围或进一步完善,或许会更有帮助。
  3. 仅在以下情况拒绝:用户的问题不是可由科学文献回答的问题(例如“我的创业公司该取什么名字”“总结这篇论文”)。明确说明 Theorizer 专门生成以已发表证据为基础的科学理论,并提出可以将问题改写成这种形式,或转交给其他技能。只有此分流方式会暂停运行。
分流方式 2(提供缩小范围的选项):
**Your question:** What makes people trust AI?

That reads as a broad, exploratory question — Theorizer can work well with that; it'll dig through the literature and surface the variables and mechanisms that seem to matter. If you'd rather narrow it yourself first, I can factor in specifics like:

- **Intervention** — a variable you want to vary (e.g., source citations, response latency, anthropomorphic phrasing)
- **Scope** — a domain to focus on (e.g., consumer chatbots, medical AI, search assistants)

Want to keep it broad, or add some detail?  You can also start broad, then narrow later based on what Theorizer finds.

如果用户补充了细节,请改写并确认:

**Reshaped:**
Build a theory of how source citations affect user trust in consumer AI chatbots.

_Approve, edit, or keep the original broad question?_

如果用户表示要保持宽泛,或没有回应这一选项,请原样使用其最初的问题继续。

分流方式 3(拒绝):
**Your question:** What should I name my startup?

Theorizer generates scientific theories grounded in the published literature — questions like "how does X affect Y" that can be tested against evidence. Naming a startup isn't a testable hypothesis I can ground in papers.
其他背景信息与引导

用户可能会在核心研究问题之外提供其他引导信息。例如:“请围绕 X 构建理论。我尤其关注 Y 或 Z。其他背景信息:我对 A、B 和 C 感兴趣。”

这些附加信息有助于引导理论生成过程——请在提交的查询中逐字保留所有这些信息,不要只保留核心问题而删去其他内容。唯一的例外是问题尚未采用构建理论的表述方式:在这种情况下,你可以将查询改写为以“请围绕……构建理论”开头,但修改应尽量少,不要改变用户提供的实质内容或附加信息。

如何分发

  1. 分类用户的请求:

    • 明确要求基于研究问题提出理论 → 选择模式,然后使用 literature-theory-generation(自动模式)或三阶段流程(分步模式)。
    • 明确针对某个阶段的请求(例如“只找论文”“根据此前的运行结果重新构建理论”“检查这些理论的新颖性”)→ 使用匹配的单个子命令,跳过模式选择。
    • 延续此前的运行 → 使用 resume-extraction,或使用此前运行的 task_id 调用 form-theory / evaluate-novelty。
  2. 获取研究问题。 如果用户尚未提供,请向其询问。这是唯一普遍必需的输入。

  3. 调整问题——但仅限下一次调用会生成理论时(literature-theory-generation 或 form-theory)。以下情况跳过:

    • 单独使用 find-and-extract——直接传入文献主题。
    • evaluate-novelty、resume-extraction——无需查询输入。

    有关评估标准和不应调整的问题列表,请参阅 调整问题。

  4. 确定模式(仅限首次运行)。如果用户在请求中已明确选择模式,则跳过。

  5. 确定其他输入。 运行 asta generate-theories describe <skill-id> 查看必需字段和重要的可选字段。对于任何缺失的必需字段,以及影响最大的 2–3 个可选字段(论文、目标、新颖性),除非用户表示“使用默认值”,否则通过一个 AskUserQuestion 问题进行询问。

  6. 说明即将提交的内容。 用一行说明:“使用 N 篇论文,开启新颖性评估,侧重准确性。正在提交——回复‘调整’即可修改。” 这是默认值可见性模式中面向用户的部分。

  7. 提交。

    • 自动模式:调用一次 asta generate-theories literature-theory-generation。
    • 分步模式:先调用 asta generate-theories find-and-extract,然后展示结果并提供继续/停止/编辑选项,再依次运行 form-theory 和 evaluate-novelty,每一步都采用相同的确认模式。

    每个子命令都接受单个 JSON PAYLOAD 参数。较短的负载可直接内联 JSON;对于较长的查询,将内容写入文件并使用 @path/to.json。对象类型的输入也接受 URI(file://、s3://、https://)。

    CLI 会将进度流式输出到 stderr,并在任务终止时将最终 Task JSON 打印到 stdout。CLI 会处理轮询(5s/15s/60s 退避)——不要自行编写循环。只有用户明确要求后台提交且不等待结果时才使用 --no-wait。在交互会话中,使用 Bash(..., run_in_background=true) 执行提交,并等待完成通知。

默认值

架构默认值。分发步骤 6 中的运行时“Using: ...”行会展示实际解析出的值,以便用户在提交前进行调整。

设置默认值效果何时调整
max_papers_to_retrieve10运行约需 3–8 min中等规模运行时调至 30,全面覆盖时调至 100(15–25 min)
generation_objectiveaccuracy-focused优先生成有充分依据的理论用户强调新颖性或新理论时,设为 novelty-focused
do_qualified_novelty_evaluationtrue增加 30–60 min 和约 $5–10 的费用快速迭代时跳过。分步模式下无影响(新颖性评估阶段会单独运行)

任务完成后

交接给 Asta Artifacts 技能(asta-tools:artifacts),由它负责导出并索引结果——它负责路径约定、清单和 asta-documents 注册。将 generate-theories 作为调用技能,并使用根据理论查询派生的 YYYY-MM-DD-<short-query-slug> 格式的 slug。

在分阶段模式下,用户每次停止或完成一个阶段后,都要导出一次;不要等到整个流程结束。

然后按以下顺序在聊天中撰写:

  1. 存放位置——索引路径 + asta documents search 命令 + open <absolute path>。使用绝对路径。
  2. 一段式综合——2–4 个全新句子。理论整体主张什么?它们在哪些方面趋同/分歧?最重要的“所以呢”是什么?阅读理论内容;不要套用模板。
  3. 理论表格——每个理论一行:名称 + 2–3 句话概述核心观点。如果评估过新颖性,则添加 novelty 列。

结尾不要写“如果你还需要……”,搜索/打开链接已足够。

恢复/错误

  • state=input-required → CLI 会打印 Continue with: … 提示。将提示转达给用户;使用 asta generate-theories send-message --task-id <id> --context-id <ctx> '<reply>' 重新发送,并再次运行等待操作。
  • state=failed → 报告 status.message 并停止。
  • 网络/协议错误会以非零状态码退出,并在 stderr 中输出 JSON {error: …}。
  • 部分流程(分阶段)→ 用户之后随时可以将先前运行的 task_id 传给 form-theory 或 evaluate-novelty 以继续。

参考资料

评论

支持 Markdown