浙大 Polaris 科研自动化实测

　　当一个团队把"让 AI 做科研"从口号变成可以本地部署的系统，最该问的不是它有多炫，而是它怎么解决"环节之间怎么衔接"这个真正难的问题。浙大 ZJU-REAL 团队开源的 Polaris（北极星） 就是这样一个尝试：它把从追踪文献到写成论文的整条链路，组织成一条 AI 能自主推进、但关键决策仍留给人的协作流程。

　　我没有停留在它的介绍文案上，而是去翻了它的 GitHub 仓库——文档、提交记录、技术栈——来判断它到底是真东西，还是又一个 PPT（仓库名是 ZJU-REAL/Polaris，不是被截断的 Polari）。下面是我看到的东西。

六段闭环：难的不是单点，是衔接

　　Polaris 把一次研究循环拆成六个阶段，首尾相连。六个阶段本身不算新鲜，新鲜的是它们之间的回流方式：

　　- 文献调研：每日自动抓取 arXiv，生成中文导读，可导出 Obsidian、生成 PPT，建立可检索的文献库。 　　- 想法生成：在已有文献基础上提出研究假设与方案。 　　- 想法评审：用 AI 正反辩论 + Elo 排名，模拟学术同行对立观点，筛掉站不住脚的方向。 　　- 实验：实验智能体连上 GPU 服务器，自己写码、训练、迭代，中途暂停等待人工批准。 　　- 论文写作：把实验结果落成文稿，且带硬约束——数字必须来自真实实验、引用必须真实存在，发现编造引用直接打回。 　　- 论文评审：对成稿做评审，再回到上一轮决定投稿与否。

　　这个结构的聪明之处在于：每一段都不是孤立的脚本，而是一条会回流的流水线。想法被评审筛过才进实验，写作受实验数据约束，评审又把成稿推回决策点。它要解决的不是"某一个环节能不能自动化"，而是"环节之间怎么衔接"。

人在回路：把判断权留给人

　　“AI 自主推进，人在关键节点决策"是这套系统的灵魂。AI 可以一路向前跑，但遇到几个真正的分叉口——要不要继续投入、要不要动用算力、要不要对外发布——必须停下来等人拍板，而不是让模型一口气跑到黑。

　　这背后是对当前大模型能力边界的清醒认识：科研里最难的问题定义、创造性直觉、对异常现象的敏锐判断，远不是一条流水线能替代的。Polaris 的定位是"高完成度的科研助理”，而不是"合作研究者"。它的价值在于把体力活自动化，把研究者从重复劳动里解放出来，去做只有人能做的判断。

　　仓库里有一句话很能说明态度——“Polaris is not a chatbot wrapper”。抓取、解析、去重、指标解析、引用匹配这些重活是确定性代码，LLM 只承担判断性工作。这和"套壳聊天机器人"有本质区别，也是它可信度的底座。

反幻觉的硬约束：科研 AI 的底线

　　科研场景对"编造"零容忍，而幻觉恰恰是大模型最危险的短板。Polaris 在写作阶段设了硬约束：数字必须来自真实实验、引用必须真实存在，一旦检测到编造引用直接打回重做。

　　这不是靠 prompt 里的"请勿编造"就能保证的，而是把约束做成了流程里的强制关卡。对科研工具来说，这条规定比"写得更流畅"重要得多——一个会伪造实验数据的助手，再聪明也是危险品。

工程成色：能跑，且认真

　　判断一个开源项目是不是 PPT，最直接的办法是看它能不能跑、文档和代码是不是真的在迭代。

　　文档体量大得反常。 docs/ 下二十多篇文档，单篇最大 task-system.md 有 50KB，wiki-and-concepts.md 43KB，覆盖架构、概念、实验、文献管理、MCP、技能系统、论文评审、部署、桌面端。绝大多数蹭热点的项目绝不会下这种苦工。

　　开发活跃且规范。 仓库 PR 编号已排到 400 多，最新一条是给实验智能体加"可观测的命令生命周期 / 断线恢复 / 超时诊断"，带测试、截图、checklist，遵循 conventional commit 与 rebase 流程。这是真实协作开发该有的样子。

　　技术栈是工程量。 React 18 + TypeScript + Vite 前端，FastAPI 全异步后端，SQLAlchemy、ARQ（Redis）任务队列、PostgreSQL 16 + pgvector、Redis 7、asyncssh 连 GPU、tectonic 编译 LaTeX、Electron 桌面端、Docker Compose 一键部署。它提供 Live Demo 只读账号与 Compose 部署，说明它确实能跑，是冲着"实验室多人协作平台"去做的。

仍要清醒看待的地方

　　- 它仍是 v0 早期。 桌面端未签名 / 未公证、guest 账号只读、文档也强调"快速迭代中"。 　　- 运维门槛不低。 本地部署要自备 LLM key 与 GPU 环境，并非开箱即用。 　　- 赛道层面的隐忧。 自动化文献与想法生成一旦被大规模使用，可能加剧选题同质化，让学科陷入"AI 读 AI 写"的自我循环，这需要在应用层面被认真对待。 　　- 能力上限待验证。 它能否真正产出可投稿的科研结果，还需要真实案例，而非 demo 截图来证明。

小结

　　Polaris 把"环节自动流转 + 关键节点留人 + 反幻觉硬约束"这套设计落到了代码里，方向务实、工程扎实、开发活跃。它不是一个能替你想出伟大问题的黑箱，而是一套把科研体力活系统化、可监督地交给 AI 的框架。

　　它最值得借鉴的，不是"AI 做科研"的叙事，而是那种克制：知道哪些事该让机器跑，也知道哪些决定必须等人点头。如果你关心科研自动化的真实形态，去 GitHub 跑通它的官方 demo，会比读任何介绍都更直观。

　　项目地址：https://github.com/ZJU-REAL/Polaris，文档：https://zju-real.github.io/Polaris/。