最近我在整理一个更偏“科研生产力底座”的开源项目：Engineering Research MCP，仓库名是 research-mcp-aggregator。

项目地址：https://github.com/loLollipop/research-mcp-aggregator

它的目标很直接：把工程科研里那些分散、重复、容易断上下文的工具，收敛到一个本地 MCP Server 里，让 AI 助手可以围绕同一套研究工作流调用它们。

这篇文章主要是介绍项目本身，不写成安装教程，也不做“照着点按钮”的操作指南。更想聊的是：它解决什么问题、把哪些能力放在一起，以及我为什么觉得这类工具会成为科研 AI 工作流里很重要的一块拼图。

为什么要做这样一个项目？#

现在 AI 助手已经很擅长写代码、改文档、解释论文，但真正进入工程科研场景时，问题往往不是“模型不会回答”，而是：

文献检索在一个地方，PDF 解析在另一个地方；
Zotero 里有文献库，但 AI 助手未必能顺手读取和整理；
COMSOL、Fluent、PFC、MATLAB、OriginLab 这些软件各有自己的生态；
仿真结果、表格、图片、LaTeX、Word 文稿，又散落在不同目录和格式里；
一次失败的仿真经验、一次调参记录、一次文献笔记，如果没有沉淀，很快就被下一轮工作覆盖。

所以很多时候，AI 并不是缺“智能”，而是缺一个能够稳定连接科研上下文的工具层。

research-mcp-aggregator 想做的，就是这个工具层。

它不是把某一个功能做到极致的单点工具，而是更像一个“工程科研工作台接口”：AI 助手通过 MCP 连接它，然后围绕文献、PDF、记忆、仿真、绘图和写作资产进行组合式调用。

一句话介绍#

Engineering Research MCP 是一个面向工程科研工作流的本地 MCP Server。

它把常见科研环节接到同一个入口里：

查论文；
读 PDF；
管理 Zotero 记录；
保存长期研究记忆；
驱动或辅助本地仿真软件；
解析仿真输出；
生成图表；
整理论文写作资产。

换句话说，它关注的不是“让 AI 单次回答更漂亮”，而是让 AI 更像一个能长期参与研究流程的助手。

它把哪些能力聚合在一起？#

从项目设计上看，research-mcp-aggregator 覆盖了工程科研里很常见的几类任务。

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 工具最应该做的是增强研究者，而不是制造一种“模型已经替你验证过”的错觉。

当前成熟度：能用，但仍在演进#

从项目功能分层来看，它已经覆盖了不少稳定能力，比如：

本地文件、解析器、绘图、BibTeX、LaTeX、docx、导出表格处理；
arXiv、OpenAlex、Semantic Scholar、Zotero、MinerU 等 API 支持；
能力发现和工作流模板。

同时，一些依赖商业软件和本地状态的能力仍然更偏实验性，例如：

COMSOL MPh；
PyFluent；
PFC bridge；
MATLAB 本地执行；
OriginLab 自动化。

这些能力是否稳定，取决于本机软件、许可证、系统环境和实际项目文件。也正因为如此，它更适合作为“可审查的辅助层”，而不是黑盒自动执行器。

项目在我心里的定位#

如果用一句更偏个人化的话来讲：

research-mcp-aggregator 是我对“AI 如何真正进入工程科研桌面”的一次尝试。

不是再造一个聊天机器人，也不是做一个只会包装 API 的小工具，而是把研究者已经在用的东西连接起来：

文献库；
PDF；
仿真软件；
本地脚本；
数据表格；
图表软件；
论文写作资产；
长期经验记忆。

AI 助手真正有价值的地方，可能不在于它某一次回答有多惊艳，而在于它能不能稳定参与一个长期项目：记住背景、找到资料、整理证据、减少重复劳动，并在关键节点提醒你回到专业判断。

这也是这个项目想探索的方向。

写在最后#

Engineering Research MCP 目前还是一个持续演进中的开源项目，但它已经有了比较清晰的方向：

用一个本地 MCP Server，把工程科研工作流里分散的工具连接起来。

如果你也在做 AI + 科研、AI + 工程仿真、AI + 文献管理，或者正在尝试把 MCP 接入自己的工作流，可以关注一下这个项目：

https://github.com/loLollipop/research-mcp-aggregator

后面我也会继续围绕它迭代更多能力，让 AI 助手不只是“会聊天”，而是真的能成为科研桌面上的长期协作者。

Hello, I'm Lollipop!

目录