1. 文献检索与文献管理#

项目内置了面向学术文献的接口能力，包括：

• arXiv：适合快速发现预印本和新方向；
• Semantic Scholar：适合围绕论文、作者、引用关系做进一步探索；
• OpenAlex：适合更开放的学术元数据检索；
• Zotero Web API：把检索和个人文献库连接起来。

这部分能力的意义在于：AI 助手不只是“凭印象总结文献”，而是可以围绕实际检索结果、元数据和已有 Zotero 记录来组织信息。

对科研来说，这一点非常关键。因为文献工作最怕的不是慢，而是来源混乱、引用不可追溯、记录无法复用。

2. PDF 解析与论文内容抽取#

论文 PDF 是科研信息的核心载体，但 PDF 对机器来说并不总是友好。

research-mcp-aggregator 集成了 MinerU 相关的 PDF 解析能力，可以把 PDF 提取为更适合 AI 处理的结构化内容，例如：

• Markdown；
• 页面文本；
• 标题层级；
• 表格；
• 公式；
• 图注和说明文本。

这类能力很适合用在论文精读、方法复现、公式整理、表格对比、综述素材提取等场景里。

相比单纯把 PDF 丢给模型，结构化解析更利于后续的检索、引用、分段总结和跨论文对比。

3. 本地长期记忆与 RAG#

项目里我比较看重的一块是 Memory / RAG。

科研不是一次性问答。很多经验都来自重复试错：某个模型为什么不收敛、某个边界条件后来怎么改了、某篇论文的实验假设是否可靠、某次 Web 检索有哪些可用线索。

research-mcp-aggregator 提供了基于本地 SQLite 的长期记忆能力，可以记录和检索：

• 通用研究笔记；
• 仿真运行记录；
• 错误案例；
• 文献笔记；
• Web 来源草稿；
• 反馈后的检索结果。

我希望它承担的角色不是“聊天记录存档”，而是一个可被 AI 助手主动检索的研究经验库。

当这些内容积累起来，AI 助手就不再只是每次从零开始，而是可以带着过往项目的经验继续工作。

4. 工程仿真软件的辅助控制面#

这是项目比较有工程特色的一部分。

research-mcp-aggregator 面向 COMSOL、ANSYS Fluent、PFC、MATLAB 等本地软件提供了一组辅助工具，包括：

• 配置检查；
• 仿真工作流模板；
• batch 命令预检查；
• 文件检查；
• 导出表格解析；
• 日志或结果整理；
• MATLAB 脚本创建、检查、执行与结果解析；
• PFC 文档和命令查询。

这里要强调一点：它不是替代仿真软件本身，也不是替代研究者判断。

更准确地说，它是给 AI 助手准备的“控制面”和“整理层”：帮助助手看文件、生成脚本、预检查命令、解析结果、整理输出，并把过程变得更可复现。

真正的模型设置、材料参数、边界条件、网格无关性、收敛判断和物理解释，仍然必须回到专业软件和研究者审查中完成。

这个边界非常重要。科研工具可以自动化重复劳动，但不能把物理判断外包给自动化。

5. 绘图、OriginLab 与论文资产#

工程科研最后通常要落到结果表达：图、表、引用、LaTeX、Word 文档。

项目提供了绘图与写作相关能力，例如：

• 使用 Matplotlib 从数组或 CSV 列生成 SVG / PNG / PDF 图；
• OriginLab / OriginPro 的工作表导入、图表创建、样式设置和图片导出；
• BibTeX 格式化、citation key 生成和 BibTeX 解析；
• LaTeX 编译与校验；
• docx 文档创建与编辑；
• Nature 风格论文资产整理相关工具。

这些功能看起来很杂，但放在科研流程里其实很自然：

文献进入 Zotero，PDF 被解析，仿真输出变成表格，表格生成图片，图片和引用进入论文资产包。

research-mcp-aggregator 想做的就是让这条链路不要每一步都手工断开。

工程仿真方向的研究者#

如果你的日常工作里经常出现 COMSOL、Fluent、PFC、MATLAB、OriginLab 这类工具，那么你一定知道科研流程里有多少重复劳动。

这个项目不负责替你判断物理问题，但可以帮助你把脚本、表格、日志、图片和文献整理得更系统。

想把 AI 助手接入科研流程的人#

很多 AI 工具停留在“聊天框”阶段，但科研需要的是能进入文件、数据、文献库和本地软件环境的助手。

MCP 的价值就在这里：它让 AI 不只是回答问题，还能通过明确的工具接口参与工作流。

想沉淀个人研究记忆的人#

科研经验如果不记录，很容易变成“我好像之前踩过这个坑”。

项目里的本地记忆能力，适合把仿真经验、错误案例、文献判断和检索结果变成可复用资产。

第一，聚合而不是割裂#

科研流程本来就是连续的，但工具往往是割裂的。

research-mcp-aggregator 尝试把“文献 — PDF — 记忆 — 仿真 — 绘图 — 写作”放在同一个 MCP 入口后面，让 AI 助手可以在同一套上下文里调度这些能力。

第二，重视本地环境#

很多工程科研软件都依赖本地安装、许可证、特定平台或 GUI 环境。

项目没有假装这些复杂性不存在，而是把它们作为现实约束来处理：能 dry-run 的先 dry-run，能解析导出结果的先解析结果，能通过本地命令或桥接方式接入的再接入。

这种思路比“云端一键解决所有问题”更务实。

第三，承认自动化边界#

项目文档里明确把仿真工具定位为 assistant-facing control surface，而不是 COMSOL、Fluent、PFC 或专家验证的替代品。

我很喜欢这个边界感。

科研 AI 工具最应该做的是增强研究者，而不是制造一种“模型已经替你验证过”的错觉。