每天一个开源项目#99 OpenResearch：2.2K星的本地研究Agent工作台

Trending rank: #11 | 日期: 2026-09-14 | Stars: 2,284 | Forks: 151 | 语言: Rust | License: MIT | 仓库: github.com/alphaXiv/Op...

做 AI 研究的人现在有一个很别扭的工作流：论文在浏览器里，实验代码在 Git 仓库里，GPU 作业在另一台机器上，Claude Code 或 Codex 的对话又散在各自的客户端里。Agent 能写代码、跑命令、读日志，但它很难天然知道"这一次实验是哪个假设的分支""这份日志对应哪个 commit""跑完以后该唤醒哪个会话继续分析"。

OpenResearch 解决的正是这条断裂的链路。它不是再造一个模型，也不是简单给论文搜索包一层 UI，而是把本地编码 Agent、论文检索、实验树、运行日志、远程算力和结果归档放进同一个本地工作台。它的核心命令叫 orx，用 Rust 写，默认在 127.0.0.1:4791 起一个本地 dashboard。Claude Code、Codex、OpenCode、Cursor 仍然用各自原生能力，OpenResearch 负责把它们纳入研究流程。

我看这个项目时最在意两件事：第一，它有没有真正的执行控制面，而不只是 README 里的"研究 Agent"概念；第二，它会不会把本地代码、token、日志、实验产物随手推到云端。源码给出的答案比较克制：默认路径是本地 SQLite 加 Git worktree，远程和托管算力是显式能力，官方 release 构建有匿名粗粒度 telemetry，但 README 明确说不采集代码、prompt、文件内容、路径、仓库名、token、邮箱、项目和实验 ID。

📋 项目概览

项目	内容
项目名	alphaXiv/OpenResearch
一句话	面向研究 Agent 的本地优先工作台，把编码 Agent、论文检索、实验树和运行日志接到一起
Stars	2,284
Forks	151
语言	Rust 68.4%、TypeScript 26.4%、JavaScript 4.0%、Python 0.4%
License	MIT
版本	GitHub Release v0.2.1，源码 Cargo.toml 版本 0.2.1
默认分支	main
最新核验提交	5d7042640f13e043dbd068b2783439819658488b，2026-09-14 04:44 UTC
安装入口	openresearch.sh/install.sh
本地入口	orx up，默认打开 http://127.0.0.1:4791

🔥 为什么值得关注

很多 Agent 产品喜欢把"自动研究"讲成一个端到端故事：丢一个目标进去，等它自己读论文、写代码、跑实验、出报告。听起来很顺，真正落地时最麻烦的却是状态管理。研究不是一次性问答，它更像一棵不断分叉的树：baseline、变体、失败日志、复现实验、下一轮假设，每一步都需要可追溯。

OpenResearch 的切入点比较务实。它没有把模型调用藏进黑盒，而是承认开发者已经在用 Claude Code、Codex、OpenCode、Cursor，然后用 Harness 抽象把这些工具接入同一个会话、权限、日志和实验系统。源码里的 src/local/harness/mod.rs 明确把能力拆成 detection、chat、skill install 三类。也就是说，一个 Agent 后端可以只负责检测和安装技能，不必强行支持完整聊天；能聊天的后端再实现 run_turn、steering、prompt resume 这些更细的行为。

这类设计的价值在于边界清楚。OpenResearch 本身不是"更聪明的模型"，它更像研究流程的本地控制层：谁在运行、在哪个 worktree、对应哪个实验节点、日志写到哪里、结束后要不要唤醒当前会话。这些东西不性感，但研究自动化要可靠，靠的就是这些脏活。

🏗️ 核心特性

1. 本地 dashboard 和 SQLite 状态库

src/commands/up.rs 里把 orx up 写得很直白：一个 Axum 进程绑定 127.0.0.1，提供嵌入式 SPA、JSON API 和 SSE 事件流。默认端口是 4791。启动时会打开本地 store，恢复未完成 turn，给仍在运行的实验补 supervisor。

orx up
  -> bind 127.0.0.1:4791
  -> serve embedded UI
  -> expose /api/* over local SQLite + log files
  -> stream /api/events through SSE
  -> host Claude/Codex/OpenCode/Cursor sessions

这不是纯前端壳子。/api/projects、/api/runs、/api/chat/sessions、/api/settings/*、/api/papers/* 都在同一个本地服务下，状态写入本地数据目录。远程模式另有 bearer token 和路由限制，源码里把数据目录迁移、更新、SSH 主连接等本机敏感操作排除在远程 workspace 外。

2. 用 Git 实验树替代"聊天记录即研究记录"

src/local/projects.rs 显示，创建项目时 OpenResearch 要求本地 Git 仓库。没有仓库时可以初始化；已有未提交仓库也会生成一个初始提交。它会把第一个无 parent 的 experiment 当作 baseline，后续实验作为子节点挂上去。

一个常见流程大概是这样：

orx up
orx projects
orx create-experiment <project-id> --title "baseline" --run-command "pytest -q"
orx exp run <experiment-id> --backend local
orx exp wait <experiment-id> --timeout 1800
orx logs <run-id> --head

这些命令和参数已用当前源码编译出的 orx 0.2.1 的 --help 核过：create-experiment 支持 --title、--run-command，exp run 支持 --backend，exp wait 支持 --timeout，logs 支持 --head。

3. 多 Agent harness，不把适配逻辑写死到一个供应商

OpenResearch 的 harness registry 目前包含四类后端：Claude Code、Codex、OpenCode、Cursor。接口层没有假设每个后端都支持同样的交互方式。比如 Claude Code 的某些权限确认是"结束当前 turn，再用新消息 resume"，而 OpenCode 可以对运行中的 serve 会话直接 inline 回复。

源码里对应的是 ResumeAction：

ResumeAction	适用交互	含义
SendMessage	Claude Code 这类结束 turn 的模式	把用户回答作为新消息继续 native session
Handled	OpenCode 这类在线协议	已经把回答 POST 回运行中的进程
Nothing	无需继续	关闭卡片或拒绝权限后不再续跑

这比"统一封装成一个 ask/answer"麻烦，但它保留了各家 CLI 的真实语义。Agent 工具一旦牵涉权限、计划确认和用户提问，这个差异很关键。

4. 远程实验不是把本地 UI 暴露出去

README 提到的远程入口是：

orx up --remote user@host

orx up --help 显示 --remote <HOST> 支持 SSH config alias 或 user@host:PORT，会在远端启动服务，并在本地打开一个 presentation gateway。README 也写了一个限制：远端服务绑定 loopback，但没有应用层认证时，同一台 host 上的其他用户可能访问。这句话有点刺眼，反而是好事，至少它没有把 SSH 转发包装成无条件安全。

5. 运行 backend 覆盖本地、SSH、Slurm、Kubernetes、Ray、Modal、Hugging Face Jobs

orx exp run --help 列出的后端包括 hf、modal、k8s、ssh、slurm、ray、openresearch、tinker、local。源码目录也能对应上：src/jobs/modal.rs、src/jobs/kubernetes.rs、src/jobs/ssh.rs、src/jobs/slurm.rs、src/jobs/ray.rs 等。

这里的重点不是"支持多少云"，而是 run lifecycle。src/commands/exp.rs 中 spawn_detached_supervise 会启动独立的 orx supervise <runId>，stdin/stdout/stderr 全部置空，Unix 下独立进程组。这样一次实验不会因为发起命令的终端断开就立刻失联。取消也不是直接杀进程就完事，代码会先在 store 里持久化 cancel intent，并在 supervisor 缺失时尝试恢复。

机制	源码证据	实际作用
detached supervisor	src/commands/exp.rs	跟踪 run 状态和日志，尽量脱离发起终端生命周期
local store polling	orx exp wait	Agent 可以阻塞等待某个 experiment 或项目内任一 run 完成
backend descriptor	src/jobs/*	不同算力后端用各自提交/查询/取消协议
run wake-up	orx exp wake	run 结束后恢复发起它的 Agent 会话

🔬 技术架构深度解析

OpenResearch 可以拆成五层看：

开发者 / 研究者
  |
  v
orx CLI + 本地 dashboard (Axum, SSE, embedded UI)
  |
  +-- ChatHost：统一会话、消息、prompt card、工具输出截断
  |     |
  |     +-- Harness: Claude Code / Codex / OpenCode / Cursor
  |
  +-- Local project store：SQLite + Git repository + worktree
  |     |
  |     +-- experiment tree：baseline / child variants / run records
  |
  +-- Job backends：local / ssh / slurm / k8s / ray / modal / hf / openresearch
  |     |
  |     +-- detached supervisor：状态、日志、取消、结果回写
  |
  +-- Literature layer：alphaXiv / OpenAlex / bioRxiv search and fetch

控制面：orx up 是本地服务，不是远程 SaaS 前端

src/commands/up.rs 的模块注释写得很明确：普通 dashboard 路径完全本地；/api/papers 会代理 alphaXiv 的公开无 token 接口，主要是绕过浏览器 CORS。真正的 OpenResearch API 用于账号和托管算力，不在普通本地项目流里默认接管所有数据。

它还有几个工程细节值得看：

细节	为什么重要
绑定 127.0.0.1	本地默认不对局域网开放
/api/events SSE	UI 能跟日志和会话状态实时同步，不需要轮询所有接口
DefaultBodyLimit::max(64 * 1024 * 1024)	支持把 PDF、图片等附件随聊天消息走 JSON body
TOOL_TEXT_CAP = 16_000	工具输出按头尾截断，避免长日志让每次 SSE 刷新变成 O(完整输出)
turn lease reconciliation	进程崩溃或刷新后能处理未完成 turn，而不是永远卡 busy

Agent 层：统一 UI，不抹平原生差异

ChatHost 的注释说得很清楚：SQLite 是 transcript 的系统记录，每个 harness 仍保留自己的 native session，用于上下文和 resume。这一点挺关键。很多所谓"多 Agent 平台"会把所有后端降级成一次性 prompt 调用，最后失去 Claude Code、Codex 这类工具自己的上下文和权限机制。

OpenResearch 采取的是中间路线：

POST /api/chat/sessions/<built-in function id>/message
  -> ChatHost 持久化 user message
  -> 为本 turn 启动 harness adapter
  -> adapter 解析原生事件流
  -> 归一化为 text/tool/prompt parts
  -> 每 75ms 批量 flush 到 SQLite 和 SSE
  -> 结束后保留 native session id，供下一 turn resume

这套机制也解释了它为什么有那么多看似琐碎的代码：工具输出要限长，run id / experiment id 要能绑定到具体工具调用，权限卡片要能回答，分叉会话要保住 parent，子 Agent 的 transcript 不能被下一次 flush 覆盖。研究工作流如果要长跑，这些边角不是锦上添花。

实验层：Git 是可复现边界

项目导入时，OpenResearch 会围绕 Git 做很多防呆。比如源码测试里覆盖了这些场景：

场景	行为
空目录创建项目	初始化 Git 仓库并生成 baseline branch
未提交仓库	用当前工作树生成初始提交
大文件达到阈值	不把 checkpoint 这类大文件纳入初始 commit
嵌套仓库	保持 gitlink 或独立项目边界
symlinked .gitignore	尽量不破坏用户已有忽略规则

这说明它把"实验快照"当成一等对象，而不是让 Agent 在脏工作区里随便跑。对 ML 研究尤其重要：没有 commit，日志和结果就很难回到某个确定代码状态。

运行层：后端多，但语义收敛到 run

不同后端的控制协议差异很大。Modal 用 Python launcher 调 modal.Sandbox；Kubernetes 要校验 Job manifest，要求容器命令引用注入的 $ORX_SCRIPT；OpenResearch 托管后端先创建 sandbox，再通过 SSH 跑 clone-and-run payload，结束后删除 box。OpenResearch 没有把这些差异藏掉，而是把它们收敛成本地 run record。

experiment node
  -> choose backend and flavor
  -> create run record
  -> submit job / spawn local process
  -> detached supervisor polls status and logs
  -> write terminal state: done / failed / cancelled
  -> optional wake-up resumes chat session

从源码看，orx exp wait --project 不是简单等某个固定 run，而是"项目内任一 run 进入终态就返回"。这适合 Agent 批量探索多个实验方向：一个槽位空出来，就重新列 run，再决定下一步。

代码规模和验证结果

我用浅克隆在提交 5d7042640f13e043dbd068b2783439819658488b 上做了源码统计，文件数来自 git ls-files -z 的落盘解析，避免终端输出截断导致少算。

指标	数值
tracked files	500
Rust 文件	109
TS/TSX 文件	133
test-like files	31
统计到的文本行数	144,409
Rust 行数	89,786
TypeScript/TSX 行数	31,980
UI 目录文件数	248
src 目录文件数	109
agent-skills 目录文件数	29

本地验证也跑过：

命令	结果
cargo build --locked	通过，生成 orx 0.2.1
./target/debug/orx --version	输出 orx 0.2.1
cargo test --locked	815 passed，0 failed，2 ignored，耗时约 8.29s

这组测试量不算小。需要补一句边界：我没有真实连 Slurm、Kubernetes、Modal、Ray 或远程 GPU 跑端到端实验，所以上面对这些后端的判断来自源码、CLI parser 和单元测试，不等于生产环境压测。

📖 README 核心内容摘要

README 给 OpenResearch 的定位是 "local-first workspace for research agents and autoresearch"。它支持把 Claude Code、Codex、OpenCode、Cursor 变成研究 Agent，用来做论文阅读、假设发展、实验运行和研究产物生成。

它主打的工作方式可以概括成几条：

README 能力	技术含义
Parallel exploration	每个研究方向可以有独立 Agent session 和隔离 worktree
Reproducible experiments	实验变体挂在 Git-native experiment tree 上，每次 run 绑定提交快照
Evidence in context	日志、diff、文件、结果和 artifact 与产生它们的工作绑定
Choice of agent	不是只支持一个模型客户端，而是接入多个本地编码 Agent
Choice of compute	本地、SSH、自有基础设施、托管 OpenResearch compute 都可作为运行位置
Local ownership	项目、会话、实验、日志、代码和 artifact 默认留在本机

README 中最容易被忽略的是 telemetry 段落。官方 release 构建会发送可关闭的粗粒度 usage events，随机 installation ID 绑定；但它声明不包含代码、prompt、文件内容或路径、仓库名、token、邮箱、项目和实验标识。对研究代码来说，这个边界比"本地优先"四个字更具体。

常用命令 README 列了这些：

orx projects
orx project view <project-id>
orx runs <project-id>
orx logs <run-id>
orx exp run <experiment-id>
orx discover keyword <query>
orx paper <arxiv-id-or-doi>

discover 和 paper 两组命令值得单独看。CLI parser 显示，discover 支持 keyword、embedding、openalex、biorxiv，查询参数里有 --published-after、--published-before、--prioritize、--limit；paper 可以按 arXiv id、DOI、OpenAlex id 自动识别来源，也可以用 --source 指定，还支持 alphaXiv 的 --full 全文提取。

🚀 快速上手

macOS 或 Linux 上，README 给出的安装方式是：

curl -LsSf https://openresearch.sh/install.sh | sh
orx up

orx up 会打开本地 dashboard。默认地址：

http://127.0.0.1:4791

如果你想先把 OpenResearch skill 装进已有编码 Agent：

orx install-skills
orx install-skills --agent claude
orx install-skills --agent codex

install-skills --help 显示 --agent 可选 claude、codex、opencode、cursor、all，默认会安装到本机已设置过的 Agent。还有一个 --full，会把完整模块化技能集装进去；README 和源码注释都更建议普通环境先用轻量 shim，避免全局技能过多。

一个最小研究实验流程可以这样组织：

orx up
orx projects
orx create-experiment <project-id> --title "baseline" --run-command "pytest -q"
orx exp run <experiment-id> --backend local
orx exp wait <experiment-id> --timeout 1800
orx runs <project-id>
orx logs <run-id> --head

如果实验要放到远端机器：

orx up --remote user@host

远程模式依赖 SSH。--remote 的 help 文案写得很细：可以用 SSH config alias，也可以用 user@host:PORT。自定义 key、jump host 等仍交给 ~/.ssh/config，这比 CLI 自己发明一套 SSH 配置更稳。

本地模型方面，README 提到可以通过 OpenCode 接 LM Studio、oMLX、Ollama 或自定义 endpoint。这个路径适合不想把论文、代码和实验上下文交给云模型的团队。不过模型质量会直接影响研究 Agent 的上限，OpenResearch 只负责组织流程，不替模型保证推理能力。

📊 增长速度与社区热度

OpenResearch 创建于 2026-06-07，按 2026-09-14 的 2,284 Stars 粗算，公开仓库年龄约 99 天，生命周期平均约 23 Stars/天。这个数只能当可见度基线，不能当当天增长。预运行快照保留了 Trending 排名和仓库列表，但没有保留每个仓库的今日新增 Stars，所以这里不编造日增数据。

社区活跃度更有参考价值：最新提交在 2026-09-14，最近 release 是 v0.2.1，发布时间 2026-09-12，并带 18 个 release assets。GitHub API 搜索显示当前 open issues 5 个、open PRs 6 个、merged PRs 286 个。贡献者集中度较高，前几名提交数分别是 sox8502 197、rehaanahmad2013 65、myles332 63，后面贡献者数量明显少。这类早期工具常见，不是问题，但团队要在关键研究流程里采用时，最好锁定版本。

近几次提交也能看出项目还在高速变动：

提交	时间	摘要
5d70426	2026-09-14	Improve README download buttons and badges
8875585	2026-09-13	fix: preserve experiment tree viewport
cf4baa7	2026-09-12	Move managed repositories from cache to persistent storage
19f91fd	2026-09-12	Add Cursor as a first-class orx up harness
91dce7b	2026-09-12	Collapse work traces across all three chat harnesses

完整 Trending leaderboard 如下。排名来自 2026-09-14 快照；Stars、Forks、语言为同日 GitHub API 复核值；今日新增 Stars 未在快照中保留。

Rank	Repository	Language	Stars	Forks	今日 Stars
1	JustVugg/colibri	C	30,586	3,294	快照未保留
2	ever-co/ever-gauzy	TypeScript	5,484	959	快照未保留
3	bilawalsidhu/gods-eye-view	JavaScript	32,574	6,506	快照未保留
4	tech-leads-club/agent-skills	TypeScript	5,831	504	快照未保留
5	melgarafael/DeskcommCRM	TypeScript	2,368	608	快照未保留
6	calesthio/OpenMontage	Python	58,798	7,384	快照未保留
7	asgeirtj/system_prompts_leaks	JavaScript	66,331	10,830	快照未保留
8	vxcontrol/pentagi	Go	24,227	3,115	快照未保留
9	multimodal-art-projection/YuE	Python	7,971	880	快照未保留
10	yuliskov/SmartTube	Java	33,548	2,039	快照未保留
11	alphaXiv/OpenResearch	Rust	2,284	151	快照未保留
12	debpalash/VoiceStudio	Python	27,712	3,414	快照未保留
13	SnailSploit/Claude-Red	Python	4,341	605	快照未保留
14	alibaba/open-code-review	Go	23,967	1,768	快照未保留
15	jihe520/MathModelAgent	Python	5,480	414	快照未保留
16	tonhowtf/omniget	Rust	12,055	1,043	快照未保留
17	jiji262/douyin-downloader	Python	11,601	1,768	快照未保留
18	Swordfish90/cool-retro-term	QML	26,322	1,020	快照未保留
19	huggingface/transformers	Python	165,722	34,566	快照未保留

🎯 适用场景

场景	适合程度	原因
论文复现实验	高	Git 实验树、运行日志、commit 快照和 Agent 会话能绑在一起
多方向探索	高	exp wait --project 这类命令适合并行跑多个变体后回收槽位
本地优先研究工作流	高	默认 SQLite、本地 Git、本地 dashboard，云能力显式启用
远程 GPU 调度	中高	后端覆盖 SSH、Slurm、K8s、Ray、Modal、HF Jobs，但仍要看团队现有基础设施
编码 Agent 统一入口	中高	支持 Claude Code、Codex、OpenCode、Cursor，但每个后端能力不完全一样
严格隔离的安全执行	中	源码证明了进程和权限控制面，但没有证明完整 OS 级沙箱；处理不可信代码时仍应放进容器或 VM
非技术用户科研写作	中	UI 友好度在提升，但概念仍围绕 Git、run、worktree、backend

我会把它放在"研究流程操作系统"的早期形态，而不是单纯 Agent IDE。它真正有用的地方，是把实验从聊天窗口里拉回工程系统：代码有 commit，实验有节点，日志有归属，Agent 有可恢复的上下文。

💡 总结

OpenResearch 的亮点不在模型能力，而在研究流程的骨架。它把本地编码 Agent 接进一个可追踪的实验系统：项目是 Git 仓库，实验是树，运行是 record，日志和 diff 可以回溯，会话能在结果回来后继续。这套结构对 ML、系统、论文复现这类长周期工作有现实意义。

它也还在早期。v0.2.1 的 release 节奏很快，很多能力刚刚完成 Rust port 或新增后端支持。团队如果要试用，我建议从一个小型、可回滚的项目开始：先用本地 backend 跑 baseline，再接入 SSH 或自有集群；先让 Agent 做日志整理和下一步建议，再逐步放开实验提交权限。别一上来就让它独自管理昂贵 GPU 作业。

对我来说，它最值得借鉴的是分层：Agent 负责推理和代码操作，OpenResearch 负责状态、证据、实验和运行生命周期。自动研究如果要从 demo 走向日常工具，最终拼的可能不是单次回答有多聪明，而是谁能把每一步留下可复查的轨迹。