企业官网建设流程全解析

给 OpenResearch 配编程助手：Claude Code、Codex、Cursor、OpenCode 怎么选

【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址: https://gitcode.com/GitHub_Trending/op/OpenResearch

科研工作流正在从"人肉搬砖"切换到"Agent 替你搬砖"。OpenResearch 的口号是Turn your coding agents into research agents——把成熟的编程智能体直接改造成科研代理。但问题随之而来：市面上主流编程助手不下四款，它们接入 OpenResearch 的方式、上下文管理、工具权限和计费逻辑各不相同，选错了组合，轻则多花几倍 token 钱，重则让实验记录、文献笔记这些敏感资产流到不该去的地方。

本文不搞空对空的"体验评测"，而是直接从 OpenResearch 源码里的 Harness 兼容层入手，逐条对比四款助手在上下文管理、工具调用、成本与隐私四个维度的真实差异，最后给出针对不同预算与隐私需求的选型结论。

一、先看懂 OpenResearch 的接入层：Harness

在 OpenResearch 中，所有编程助手的接入都收敛到一个统一的 trait 上。打开 src/local/harness/mod.rs 可以看到，每个助手是一个impl Harness，只暴露三个能力：

• detection（检测）：判断 CLI 是否安装、用户是否已登录、能列出哪些账号与模型——这是orx up启动时助手选择器的数据来源；
• chat（对话）：驱动一轮对话，把助手原生的事件流规整成统一的 wire 结构；
• skill install（技能安装）：把orx的 SKILL shim 丢进助手自己的 skills 目录，让 Agent 能自动发现并调用科研子技能。

新增一个助手只需"一个文件 + 一个 trait 实现 + 注册表里一行"。目前注册了 Claude Code、Codex、OpenCode、Cursor 与 Google Antigravity 五个 harness。这意味着"选哪款助手"并不会影响科研功能本身——文献检索、实验树、证据回溯都是同一套——真正不同的是每款助手在驱动方式、上下文注入和权限模型上的原生差异，而这三点恰恰决定了科研场景下的体验上限。

二、驱动方式：三套完全不同的架构

四款助手接入 OpenResearch 的方式代表了三种工程路线，这也解释了它们在不同场景下的性格差异。

Claude Code：常驻子进程 + 流式 JSON。在 src/local/harness/claude.rs 中，每个会话对应一个常驻的claude --print --input-format stream-json子进程，跨轮复用（session_id稳定、stdin 保持打开），把过去"每轮 spawn 一次"的开销折叠掉。配置变更、中断或崩溃时用--resume重启。它的权限模型最丰富：manual / acceptEdits / plan / auto / bypassPermissions五档，plan 甚至是原生权限模式之一。

Codex：JSON-RPC app-server。src/local/harness/codex.rs 走的是 codex ≥ 0.144 的 app-server 协议：每个会话一个长生命周期codex app-server子进程，thread/start、turn/start以 JSON-RPC 通知流式推事件，thread id 作为原生会话标识持久化。权限上引入sandboxPolicy（writable roots + network），Auto 模式可交给 Codex 内置的 approval reviewer，必要时以 permission card 的形式回抛给用户。

OpenCode：loopback serve + SSE。src/local/harness/opencode.rs 懒启动一个opencode serve子进程，一轮对话 = 订阅全局/eventSSE 流 + POSTsession.prompt。它的特色是内联审批：permission.asked/question.asked事件发出时 POST 还开着，会话是"暂停"而非"结束"，你在界面上作答后同一轮继续。配合opencode_config_json把edit / bash / webfetch等全部预置为allow，保证无头轮次不卡在 TUI 提示上。

Cursor：每轮一次agent --print。src/local/harness/cursor.rs 的实现最直白：每轮 spawn 一个agent --print --output-format stream-json，多轮通过--resume <session_id>续接，--workspace指向 OpenResearch 的隔离 worktree（不用 Cursor 自己的 worktree 标志，保证仪表盘看到的就是 Agent 改的那个 checkout）。权限只有ask / auto / full-access三档。

一个值得注意的工程细节：四款助手都要经历二进制探测。Windows 上每次 spawn 一个 Node CLI 可能耗时数秒，src/local/harness/detect.rs 用信号量把并发探测限制在 8 条车道内，并区分"未安装 / 安装但损坏 / 可用"三种状态。这类基础设施的打磨意味着：接入越成熟的助手，在orx up里的检测与恢复路径越顺滑。

三、上下文管理：Playbook 注入与"实验记忆"

科研与编程最大的不同是状态：文献读了哪些、假设改了几版、哪次实验失败过。OpenResearch 的上下文策略是"两条腿走路"。

一是统一的 Playbook 注入。根目录的 SYSTEM_PROMPT.md 是一份随会话持久注入的系统提示，但每款助手通过自己的原生通道接收：Claude Code 用--append-system-prompt-file，Codex 用developerInstructions（真正的指令通道，不是第一轮塞<system-context>文本），OpenCode 写入 config 的instructions列表（且 opencode serve 每一轮都会重读该文件，改写即重定向）。Playbook 里携带的只是每轮都需要的事实——项目 ID、实验树状态、产物目录、计算后端——具体任务过程则全部下沉到agent-skills/的原子技能里，按需加载。

二是实验记忆外置到本地存储。每轮对话的 token 再大也装不下科研全生命周期。OpenResearch 把每次实验记录进本地 SQLite，日志、代码、产物都留在本机，Agent 可以随时orx runs、orx logs去查"过去发生了什么"。上下文管理的结论因此清晰：四款助手在"会话内上下文"上拼的是各自的压缩能力，但科研的长程记忆由 OpenResearch 的外置存储统一兜底——谁的 CLI 更稳定、恢复路径更完整，谁的科研会话就更不容易"断片"。

四、工具调用与权限模型：科研场景的安全关键

科研 Agent 的工具调用比普通编程更敏感：要跑训练脚本、读写数据文件、访问 arXiv/PubMed、偶尔还要操作 SSH/Slurm。不同权限模型直接影响"无人值守程度"。

src/local/harness/options.rs 里定义了一个内部权限枚举PermissionMode（Ask / AcceptEdits / Plan / Auto / Bypass），并做了厂商间拼写的归一化映射：Claude 的manual、Cursor 的ask、Codex 的default统一解析为 Ask；bypassPermissions、full-access统一解析为 Bypass。但厂商的实际语义仍有差别：

• Claude Code五档权限 + Plan 作为原生模式，plan 门由 permission bridge 接管，在无头模式下把原本会"静默死掉"的审批提示变成可交互卡片；
• Codex用sandboxPolicy声明可写根与网络权限，Auto 模式走内置 reviewer，未决请求以 permission card 在同一条连接上内联回答；
• OpenCode的无头配置最激进——真实权限全部预批准，唯独把question工具 deny + 禁用，因为它在 serve 模式下会死锁（无人应答）；
• Cursor的 print 模式不能交互，Ask 就是--mode ask（只读），Full access 直接禁用沙箱。

科研建议很明确：首次跑通前用 Ask/Default 模式让 Agent 每步汇报，确认实验命令可信后再切 Auto-approve，真正需要全自动复现实验时才对特定项目开 Bypass/Full access。

五、成本与模型分层：token 花在刀刃上

四款助手的计费模型差异，在科研场景会被放大——文献综述动辄几十轮工具调用，token 消耗远超普通编码。

先看 OpenResearch 自己的省钱设计。src/local/harness/claude.rs 的claude_one_shot给会话生成标题等一次性请求时，明确用--model haiku/--model sonnet（Cheap / Standard 两档），并刻意禁用工具、替换掉默认的约 8.5k token 脚手架系统提示，用--no-session-persistence保证不污染真实会话历史——注释里直接写着"每个请求都更便宜"。Codex 侧则在 src/local/harness/codex.rs 完整记录inputTokens / outputTokens / cacheRead / cacheWrite / reasoningTokens，连子 Agent 的越期用量都单独记账，让成本可审计。

推理档位的控制同样被精细处理。src/local/harness/options.rs 指出，推理层级是按模型而非按 harness 统一的：Claude 的--effort（low→max 甚至 ultracode 模式）、Codex 的model_reasoning_effort（ultra仅 Sol/Terra 可用）、OpenCode 的variant（opencode models --verbose声明在模型目录里）三者语义并不相通。因此 OpenResearch 用REASONING_DEFAULT_ID = "default"作为哨兵：除非用户显式选择，否则不发送任何 override，以免悄悄覆盖用户在~/.codex/config.toml里配好的 effort。也就是说，你完全可以把"综述初筛用低档模型批量跑、关键假设推演用高档模型"的成本分层策略，直接映射到这四款助手的推理档位选择器上。

至于订阅制，社区里 Pro 200 额度下调的讨论（Codex 用量从 Plus 的 20 倍降到 10 倍、价格不变）提醒我们：云端订阅的"性价比"随时可能被厂商调整，Token 级别的计量在 OpenResearch 里反而是最可控的。

六、本地优先 vs 云端依赖：OpenCode 是唯一的"全离线"选项

如果你对数据主权敏感——比如处理未发表的实验数据、临床信息或企业合作项目——这一节是决定性的一节。

OpenResearch 的定位就是 local-first：README 明确写着We don't collect your code or agent traces. Your projects, conversations, experiments, logs, and artifacts stay on your machine, under your control.项目实验记录在本地 SQLite，Git worktree 承载版本，orx up的本地仪表盘跑在http://127.0.0.1:4791。但助手这一层的"本地化"程度却不同：

• Claude Code / Codex / Cursor的模型推理都依赖厂商云端（OAuth 或 API Key）：src/local/harness/claude.rs 检测claude auth status，Codex 检测$CODEX_HOME/config.toml的 active provider 与auth.json，Cursor 认agent status+CURSOR_API_KEY——三者都是"本地 CLI、云端模型"；
• OpenCode 是唯一的例外：它允许把整个推理层下沉到本机。src/local/local_models.rs 定义了Connection结构（name、baseUrl、apiKey、models），并且强制is_loopback_url校验——只能连localhost或回环 IP，从根上挡住把请求误发到公网的风险。

实操上，docs/local-models.md 给出完整闭环：LM Studio（默认http://127.0.0.1:1234/v1）、oMLX（Apple Silicon 的http://127.0.0.1:8000/v1）、Ollama（http://127.0.0.1:11434/v1）或任意 OpenAI 兼容端点。OpenResearch 把这些连接保存在自己的本地数据目录，而不是写进 OpenCode 的配置——这样你原有的云厂商 Provider 设置完全不受影响，本地模型与云端模型可以并存、按会话切换。文档还特别提示了两个边界：本地推理不代表整个科研流程离线（文献检索、GitHub 操作仍走网络）；本地模型服务器挂掉只会让该请求失败/重试，绝不会悄悄切换到云端模型。

七、选型结论：按预算与隐私画两条决策线

综合源码事实，选型建议可以收敛成一张决策表：

追求极致上下文与权限控制（不差钱，云端可接受）→ Claude Code。五档权限、Plan 原生模式、--resume会话恢复、常驻子进程零 spawn 开销，加上ultracode这类工作流编排模式，是四款中"Agent 能力上限"最高的一档。代价是订阅价格最高，且推理完全依赖 Anthropic 云端。

预算敏感、重度依赖 OpenAI 生态 → Codex。它自带 token 级用量通知与 reroute 记录，sandboxPolicy的权限表述最工程化；但推理档位依赖具体模型（ultra只限 Sol/Terra），订阅额度又可能随政策调整，适合对 token 计量要求精细的用户。

隐私第一、要完全本地推理 → OpenCode（配本地模型）。唯一支持"本地 CLI + 本地推理"全链路闭环的选项，还有 SSE 内联审批、每轮重读 playbook 等工程优势。代价是本地模型（尤其小显存机器）的推理质量与速度明显弱于云端旗舰，权限粒度也只有两档。

追求最低门槛的 IDE 内体验 → Cursor。每轮 spawn 的实现换取的是与编辑器的紧密耦合；三档权限中full-access会禁用沙箱，适合在隔离的科研环境里快速铺开，不适合在共享服务器上做敏感操作。

最后说一句贯穿全文的提醒：OpenResearch 把科研状态、实验证据和产物都收进了本地仓库——这意味着你随时可以换助手而不换科研。选型不是"终身绑定"，今天的 Claude Code 会话和明天的 OpenCode 本地会话，读的是同一个 SQLite、同一棵实验树、同一份 Git 历史。真正值得投入判断力的，只有"你的数据愿意交给哪家云端、你的预算愿意花在哪些推理档位上"这两件事。

【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址: https://gitcode.com/GitHub_Trending/op/OpenResearch