1. 从“OpenResearch”说起一个被低估的科研工作流重构命题第一次看到“OpenResearch”这个标题加上旁边一串 Claude Code、Codex、OpenCode、Cursor 的热搜词我脑子里蹦出来的第一个判断是这大概率不是一个单纯的“开源科研工具”而是一套把AI 编程助手能力迁移到科研工作流里的实践方案。为什么这么判断因为热搜词里几乎全是当下最主流的 AI 编码代理工具而“Research”这个词又明确指向了文献调研、实验记录、数据分析、论文写作这条链路。把这两组词放在一起答案就很清楚了——有人想用 AI 编码代理那套“读文件、改文件、跑命令、迭代验证”的机制去解决科研过程中那些重复、琐碎、容易断片的环节。我自己做科研工具链折腾了七八年从最早的 Jupyter Notebook 手动管理到后来用各种脚本串起文献抓取、数据清洗、图表生成再到这两年深度使用 Claude Code 和 Codex 这类代理工具最大的体会是科研的真正瓶颈从来不是“想不出问题”而是“想出的问题被大量机械劳动拖死”。你有一个假设要验证它得先找二十篇文献、整理成表格、跑三组对照实验、画五张图、写一段讨论——中间任何一步断了思路就凉了。OpenResearch 这个命题的价值恰恰在于它试图用 AI 代理的“持续在场”能力把这条链路粘起来。这篇文章我想聊的不是某个具体产品的使用手册而是如何用 Claude Code、Codex、OpenCode、Cursor 这几类工具搭出一套真正能跑起来的 OpenResearch 工作流。适合谁看如果你是研究生、科研助理、独立研究者或者任何需要“查资料—做实验—写报告”闭环的人并且你已经听说过这些工具但不知道怎么把它们串起来那这篇就是写给你的。我会从整体设计思路讲到具体配置再到踩过的坑尽量让你看完能直接抄作业。2. 整体设计思路为什么是“代理式科研”而不是“聊天式科研”2.1 聊天式科研的死穴在哪里大部分人用 AI 做科研停留在“聊天式”阶段打开一个对话框问“帮我总结这篇论文”“帮我写一段引言”“这个统计方法怎么选”。这种方式的问题非常致命——上下文是断的。你上一轮让它总结的文献下一轮它就不记得了你让它改的代码它不知道你本地的数据文件长什么样你让它写的讨论它没看过你的实验结果表。每次对话都像找一个失忆的顾问你得把背景重新讲一遍。我早期也这么干结果是单次输出看着挺像样但拼到一起就散架。文献综述里引用的观点和后面实验设计对不上代码里的变量名和论文里的符号不一致图表编号和正文引用错位。科研最怕的就是这种“局部合理、全局崩坏”。2.2 代理式科研的核心机制Claude Code、Codex、OpenCode 这类工具的本质区别在于它们不是“聊天机器人”而是能读写你本地文件、能执行命令、能持续迭代的代理。你给它一个任务它会自己去读相关文件、理解项目结构、修改代码、运行验证、根据报错再改直到任务完成。这个机制迁移到科研上就变成了文献调研代理去读你下载的 PDF 和笔记生成结构化综述而不是凭空编数据分析代理去读你的原始数据文件写清洗脚本跑统计输出结果表论文写作代理去读你的实验记录和结果表生成初稿保持符号和编号一致复现验证代理去读你的代码仓库按 README 跑一遍报告哪里断了关键差异在于“文件系统作为共享记忆”。所有工具都围绕你的项目目录工作上下文不再依赖对话历史而是依赖磁盘上的真实文件。这就解决了聊天式科研的断片问题。2.3 工具选型的取舍逻辑热搜词里四个工具各有定位我按自己的使用经验给个判断工具核心优势适合的科研环节主要限制Claude Code长上下文理解强文件操作稳文献综述、论文写作、复杂重构需要稳定的 API 接入Codex代码生成与执行闭环好数据分析脚本、实验代码对非代码文件理解稍弱OpenCode开源可自托管免费额度轻量任务、隐私敏感数据免费层有使用范围限制Cursor编辑器集成好交互直观边写边改、调试重度使用需订阅我的建议是不要只用一个。科研工作流天然分阶段调研阶段用 Claude Code 读文献分析阶段用 Codex 跑脚本写作阶段回到 Claude Code 统稿日常编辑用 Cursor 兜底。OpenCode 作为开源备选适合处理不方便外传的数据。这套组合的逻辑是“让每个工具干它最擅长的事”而不是强行用一个工具包打天下。提示工具选型没有绝对优劣关键是看你的数据敏感度、预算和任务类型。如果数据涉及未发表的核心结果优先考虑可本地部署的方案。3. 核心细节解析OpenResearch 工作流的四个支柱3.1 支柱一项目目录即知识库代理式科研的第一个前提是把你的科研项目组织成一个代理能理解的结构。我试过很多种目录布局最后稳定下来的方案是这样的project/ ├── literature/ # 文献 PDF 和笔记 │ ├── pdfs/ │ └── notes/ ├── data/ # 原始数据只读 │ ├── raw/ │ └── processed/ ├── analysis/ # 分析脚本 │ ├── scripts/ │ └── outputs/ ├── manuscript/ # 论文稿件 │ ├── sections/ │ └── figures/ ├── CLAUDE.md # 给代理的项目说明 └── README.md # 给人看的项目说明这个结构的关键在于职责分离data/raw永远只读代理不能改analysis/outputs是脚本产物可以随时重建manuscript是最终交付物。代理在这个结构里工作时边界非常清晰不会误删原始数据也不会把中间产物当成最终结果。CLAUDE.md这个文件是 Claude Code 的约定用来告诉代理项目的背景、约定和禁忌。我一般会写清楚数据文件格式、变量命名规范、图表输出路径、哪些目录不能动。这个文件相当于给代理的“入职培训”写得好能省掉大量重复解释。3.2 支柱二文献的结构化处理文献调研是科研最耗时的环节。我的做法是先用代理把 PDF 批量转成结构化笔记再基于笔记做综述。具体流程把 PDF 放进literature/pdfs/让代理逐个读取提取研究问题、方法、数据、主要结论、局限性输出成统一的 Markdown 笔记存到literature/notes/基于所有笔记生成综述初稿这里有个细节很重要不要让代理直接总结整篇 PDF 然后写综述。那样它会丢失细节而且不同论文的总结格式不一致后面没法对比。正确做法是先定义笔记模板让每篇论文都按同一模板输出这样后续做对比表、找研究空白才有依据。我用的笔记模板大致是# 论文标题 - 作者/年份 - 研究问题 - 方法 - 数据 - 主要结论 - 局限性 - 与我的研究的关系最后一行“与我的研究的关系”是灵魂。代理在读每篇论文时会结合CLAUDE.md里的项目背景判断这篇论文和你的研究有什么关联。这样生成的笔记不是孤立的摘要而是已经带上了你的研究视角。3.3 支柱三分析脚本的可复现性数据分析环节代理式工作流的最大价值是可复现。传统做法是你手动跑一堆命令跑通了就完事过两个月自己都忘了怎么跑的。代理式做法是让代理把每一步都写成脚本脚本里包含完整的参数和注释输出结果自动存到指定目录。我的一般流程是把原始数据放进data/raw/告诉代理数据格式和分析目标代理写清洗脚本到analysis/scripts/01_clean.py代理运行脚本输出到data/processed/代理写分析脚本到analysis/scripts/02_analyze.py代理运行输出结果表和图表到analysis/outputs/代理写一个run_all.sh把所有步骤串起来这个流程的好处是任何时候你想复现结果只要跑run_all.sh就行。而且代理在写脚本时会自动加注释说明每个参数为什么这么选。我实测下来这套流程让我的分析复现时间从“半天回忆调试”压缩到“跑一个脚本”。注意代理写脚本时容易“过度工程化”加一堆你不需要的抽象层。我的经验是明确告诉它“写最直白的脚本不要用类不要用复杂设计模式”科研脚本可读性比优雅性重要。3.4 支柱四写作与数据的一致性维护论文写作阶段最容易出问题的是符号、编号、数据引用的一致性。你正文里写“如图 3 所示”结果图 3 是另一个东西你方法里说“使用 α0.05”结果代码里是 0.01。这种错误人工检查很累代理检查很轻松。我的做法是让代理在写作前先做一次“一致性审计”读所有分析脚本提取实际使用的参数读所有结果表提取实际数值读论文初稿提取所有引用的符号、编号、数值对比三者报告不一致的地方这个审计步骤我强烈建议每个科研项目都做。它抓出来的问题往往是你自己反复看都看不出来的因为人脑会自动“脑补”成正确的。4. 实操过程从零搭一套 OpenResearch 工作流4.1 环境准备与工具安装先说安装。Claude Code 和 Codex 都是命令行工具安装方式类似一般通过包管理器。OpenCode 是开源方案可以自托管。Cursor 是编辑器下载安装包即可。安装完成后第一件事是配置项目级的说明文件。Claude Code 读CLAUDE.mdCodex 读AGENTS.mdOpenCode 有自己的配置约定。我一般会写一个通用的项目说明然后软链接到各个工具约定的文件名避免重复维护。项目说明里我必写的几项项目背景一句话说清研究问题目录结构每个目录放什么数据约定格式、编码、缺失值处理命名规范变量、文件、图表的命名规则禁忌哪些目录不能改哪些操作不能做这个文件写一次后面所有代理任务都受益。我踩过的坑是早期没写清楚代理把data/raw里的原始数据“顺手”清洗了覆盖了原文件差点酿成大祸。从那以后我养成了习惯原始数据目录设为只读并且在项目说明里用大写加粗标注“禁止修改”。4.2 文献调研的完整实操假设你要做一个新课题第一步是文献调研。我的实操步骤在数据库检索下载 30-50 篇相关 PDF放进literature/pdfs/启动 Claude Code进入项目目录输入任务“读取 literature/pdfs 下所有 PDF按 literature/notes 下的模板生成结构化笔记每篇一个文件”代理逐个处理遇到读不了的 PDF 会报告处理完后输入“基于所有笔记生成一份综述初稿按主题分组标注每篇论文的贡献和局限”代理生成综述存到manuscript/sections/literature_review.md这个过程我实测下来30 篇论文大约需要 20-30 分钟取决于 PDF 质量和代理速度。人工做同样的事至少两天。而且代理生成的笔记格式统一后面做对比表、找研究空白非常方便。有个细节要注意PDF 质量参差不齐。扫描版 PDF 代理读不了需要先做 OCR。我的做法是先用一个脚本批量检测 PDF 是否含文本层不含的单独处理。这个预处理步骤能省掉代理大量无效尝试。4.3 数据分析的完整实操数据分析环节我以一个典型的“清洗—统计—可视化”流程为例第一步让代理读原始数据报告数据概况读取 data/raw/experiment.csv报告 - 行数、列数 - 每列的数据类型 - 缺失值比例 - 数值列的分布概况第二步让代理写清洗脚本写一个清洗脚本到 analysis/scripts/01_clean.py - 删除缺失值超过 20% 的列 - 对数值列做异常值检测标记但不删除 - 输出清洗后数据到 data/processed/clean.csv - 输出清洗日志到 analysis/outputs/clean_log.txt第三步让代理写分析脚本写分析脚本到 analysis/scripts/02_analyze.py - 读 data/processed/clean.csv - 做描述性统计输出到 analysis/outputs/descriptive.csv - 做组间比较用 t 检验输出到 analysis/outputs/comparison.csv - 画箱线图输出到 manuscript/figures/boxplot.png第四步让代理写run_all.sh把所有步骤串起来。这套流程的关键是每一步都有明确的输入输出代理不会“自由发挥”。我试过让代理“自己决定怎么分析”结果它选了一个我完全不熟悉的方法虽然能跑通但审稿人一问就露馅。所以我的经验是分析方法必须你自己定代理只负责实现。4.4 论文写作的完整实操写作阶段我的流程是让代理读所有分析输出生成“结果”部分的初稿让代理读文献笔记生成“讨论”部分的初稿让代理读项目说明和结果生成“方法”部分的初稿我自己写“引言”和“结论”因为这两部分最需要个人判断让代理做一致性审计检查符号、编号、数值这里有个技巧让代理写初稿时明确要求它标注每个论断的来源。比如“根据 analysis/outputs/comparison.csv组间差异显著p0.05”这样你审稿时能快速核对不会出现“代理编了一个数”的情况。我踩过的坑是早期让代理直接写“讨论”它写得头头是道但引用的文献根本不存在。后来我强制要求讨论部分每个引用必须来自 literature/notes 里已有的笔记不允许引入新文献。这个约束一加幻觉问题基本消失。5. 常见问题与排查技巧实录5.1 代理读不了文件怎么办最常见的问题是 PDF 读不了、编码不对、文件太大。排查顺序现象可能原因解决方法PDF 读出来是乱码扫描版无文本层先做 OCRCSV 读出来列错位分隔符或编码问题指定 encoding 和 sep文件太大超时超出上下文限制分块处理或抽样路径找不到相对路径问题用绝对路径或确认工作目录我的经验是先让代理报告它能读到什么再决定怎么处理。不要一上来就让它做复杂任务先做一次“环境探测”确认它能正常访问所有需要的文件。5.2 代理改错文件怎么办这是最危险的问题。我的防护措施有三层第一层原始数据目录设为只读操作系统层面禁止写入。第二层项目说明里明确标注禁忌让代理知道哪些不能动。第三层用版本控制所有文件纳入 git改错了能回滚。我强烈建议科研项目也用 git哪怕你只有一个人。代理改错文件时git diff一眼就能看出改了什么git checkout一键回滚。这个习惯救过我很多次。5.3 代理输出质量不稳定怎么办代理输出质量波动是常态原因通常是任务描述不够具体。我的改进方法把大任务拆成小任务每个任务只做一件事给每个任务明确的输入输出格式提供示例让代理照着做要求代理在输出前自检报告不确定的地方我实测下来任务描述越具体输出质量越稳定。比如“写一个清洗脚本”就不如“写一个清洗脚本删除缺失值超过 20% 的列输出到 data/processed/clean.csv日志输出到 analysis/outputs/clean_log.txt”来得可靠。5.4 免费额度用完怎么办OpenCode 的免费层有使用范围限制Codex 和 Claude Code 也有额度限制。我的应对策略把重任务安排在额度充足时做轻任务用免费方案兜底本地能跑的分析不要用代理批量任务先小规模测试确认可行再全量跑提示不要把所有任务都交给代理。代理适合“需要理解上下文”的任务纯计算任务用本地脚本更快更省。6. 我个人的实操心得与几个关键取舍折腾这套工作流一年多最大的心得是代理是放大器不是替代品。你自己的研究判断、方法选择、结果解读代理替代不了。它能做的是把你从机械劳动里解放出来让你有更多时间做真正需要人脑的事。几个关键取舍我想单独说。第一不要追求全自动化。我试过让代理从文献到论文全自动跑结果是一堆看似完整但经不起推敲的产物。后来改成“代理做初稿我做审核和定稿”质量立刻上来了。第二不要省项目说明的功夫。CLAUDE.md写得好后面每个任务都省事写得差每个任务都要重复解释。第三不要忽视版本控制。代理改文件是常态没有 git 你迟早会哭。最后分享一个小技巧我习惯在每天结束前让代理生成一份“今日工作日志”记录改了哪些文件、跑了哪些分析、有什么待办。第二天开始时让代理读这份日志恢复上下文。这个习惯让我的科研工作流从“每天重新找状态”变成“每天接着昨天干”效率提升非常明显。
` 与 `t.try()` 只能用于测试)
