【免费下载链接】open-scienceOpen Science Desktop — local-first, model-agnostic AI research workbench for macOS, Windows Linux. Open-source Claude Science desktop alternative built on Tauri MCP agent skills.项目地址https://gitcode.com/gh_mirrors/ope/open-science点击查看免费下载Open Science Desktop 是一个本地优先、模型无关的开源 AI 科研工作台基于 Tauri MCP agent skills支持 macOS / Windows / Linux。自 v0.4.0 起它通过ACPAgent Client Protocol协议实现了双向互通既能把Codex、Claude Code、Gemini CLI当作发动机驱动也能让Zed等外部编辑器反向驱动它自己。本文将用通俗的方式讲清 ACP 协议是什么、双向互通的原理、以及三步上手实践 。ACP 协议是什么一分钟看懂可以把 ACP 理解为Agent 界的 LSP语言服务器协议要素说明传输方式JSON-RPC 2.0 overstdio子进程的标准输入/输出按行分隔两个角色Client负责 UI渲染对话、diff、权限审批↔Agent负责干活处理消息、调用工具生命周期initialize协商版本能力→session/new建会话→session/prompt一轮提问→session/cancel取消流式输出Agent 在一轮中不断发送session/update通知文本块、工具调用、思考过程轮次结束才返回result权限控制Agent 可以反向请求权限Client 回复允许/拒绝它由 Zed 和 JetBrains 背书截至 2026 年已有 25 个 Agent 接入。协议细节在项目中的完整映射表见 docs/rfc/multi-agent-acp.md。为什么选 ACP而不是给每个 Agent 写适配器最直观的做法是写一个CodexAdapter、一个ClaudeCodeAdapter……但这条路扩展性很差每支持一个新 Agent 都要维护一套私有适配代码还要追着每个 Agent 的 API 破坏性变更跑。ACP 的思路是把支持 Agent X 变成配置一条 stdio 命令仓库里没有任何 per-agent 代码每个 Agent 只是一条命令 参数的配置条目社区想贡献新 Agent写一个标准 ACP server 即可无需学习本项目私有接口兼容性由 Agent 自己或其官方 ACP bridge负责而不是由本仓库承担。这个决策的完整论证含逐层改动清单与分阶段落地计划就在 docs/rfc/multi-agent-acp.md 中。双向互通架构一张图讲清原理Open Science Desktop 在内部定义了一个统一的AgentRuntime接口packages/sdk/src/runtime.tsUI、溯源provenance、实验记录runs全都只跟这个接口对话。ACP 的加入就是在这个接缝上加了第二个运行时且是双向的AgentRuntime统一接口 │ ┌──────────────────┴───────────────────┐ │ │ OpenCodeClient AcpRuntime客户端方向 内置默认运行时HTTPSSE JSON-RPC over stdio │ │ ▼ ┌─────────────────┼──────────────┐ 内置 OpenCode ▼ ▼ ▼ 默认 codex-acp gemini --acp claude-code-acp ……任何 ACP Agent ▲ │ 服务器方向编辑器把 Open Science 当 Agent 驱动 Zed / JetBrains / Neovim → acp-server.mjs客户端方向Open Science → 驱动 Codex 等Rust 侧的进程监管器 src-tauri/src/acp.rs 负责拉起 Agent 子进程——因为 Tauri 的 webview 里没有child_process必须由宿主进程监管并在应用退出时杀掉所有子进程否则一个活着的 Agent 进程会保留着你以为已关闭的模型访问权限子进程的 stdout 通过 Tauri 事件acp:line逐行转发到前端前端适配器 lib/acpTransport.ts 是这条管道的另一端packages/sdk/src/acp/AcpRuntime.ts 拿到这条行通道把它翻译成 UI 认识的会话、消息、权限事件。服务器方向Zed 等编辑器 → 驱动 Open Science外部编辑器在启动时 spawn 本项目打包产物中的 acp-server.mjs 子进程用 ACP 方言驱动 Open Science 的运行时。核心实现在 packages/sdk/src/acp/server.ts 与 serve-stdio.ts——它不重复实现任何会话、流式、权限逻辑只是把已归一化的AgentRuntime事件流翻译成 ACP 消息。而且它复用桌面应用已开启的网关gateway和令牌编辑器驱动的就是你在窗口里看到的同一批会话、同一个工作区、同一套审批。三步上手在 Open Science Desktop 中接入 ACP Agent第 1 步在 Settings → Runtime 选择 Agent打开Settings → Runtime界面卡片源码 components/settings/AcpAgentsCard.tsx你会看到两个选项OpenCode (bundled)内置默认运行时保留 providers、skills、plan 模式与会话同步等全部功能已配置的 ACP Agent由你选择后应用会结束旧进程并拉起新 Agent。第 2 步一键添加 Codex / Gemini CLI / Claude Code预设清单定义在 lib/acpAgents.ts每个预设都经过initialize实测、应答protocolVersion 1预设名命令参数Codexnpx-y agentclientprotocol/codex-acpGemini CLIgemini--acpClaude Codenpx-y zed-industries/claude-code-acp点击预设即可加入列表任何会说 ACP 的命令行工具都可以手动填入。第 3 步像平常一样使用 选中 ACP Agent 后整个界面不变——你照常输入 prompt流式回复、工具调用、权限审批全部照旧渲染只不过背后回答你的换成了 Codex 或 Claude Code。两个需要知道的行为差异界面里有明确提示ACP Agent拥有自己的模型、skills 和历史所以模型选择器、plan 模式、会话同步仍归属 OpenCode在 ACP Agent 上发起的会话只在应用运行期间可列出Agent 未登录时比如 Codex 需要先登录 ChatGPT应用会给出可读指引在终端运行该 Agent 自己的登录命令再回到 Settings 重连。深入一点互通背后的 4 个关键机制1️⃣ 能力协商绝不假设一切以 initialize 为准ACP 的可选能力session/list、session/load、session/resume等全部由 Agent 在initialize时自我声明。AcpRuntime.ts 对每项能力走有就走、没有就诚实降级的单一路径因此同一套代码可以驱动行为差异很大的 Agent。模型切换也走此机制session/set_config_option Agent 自己上报的configOptions类别包括model、model_config、thought_level、mode——输入框里的模型/推理档位选择器渲染的是Agent 自己的选项而不是本应用的内建模型目录。2️⃣ MCP 连接器随会话注入Open Code 的 MCP server 存在全局配置里而 ACP 要求按会话传入session/new的mcpServers参数。翻译逻辑在 packages/sdk/src/acp/mcp.ts你在 Open Science 里配置的科学数据库等连接器会被原样带给 ACP Agent且按 Agent 声明的mcpCapabilities过滤传输方式stdio 必选HTTP/SSE 可选。没有这一步Agent 会看不见你配置的数据库——表面上就像功能坏了。3️⃣ 权限审批跨边界往返ACP 是双向请求的Agent 会向 Client 发起session/permission请求Client 回复 allow/deny。protocol.ts 里的JsonRpcPeer同时处理我发的请求和对方发来的请求——如果只实现单向Agent 第一次需要审批时整轮对话就会卡死。审批弹窗因此对 Codex、Claude Code 一样好使且服务器方向下只在编辑器该会话的回合进行中才转发审批避免桌面窗口里的一次审批莫名弹到编辑器里。4️⃣ 会话比进程更长寿Agent 进程崩溃或被切换后屏幕上的对话还在。sendPrompt发现未知会话时会先尝试session/resume恢复上下文、不重放历史Agent 不支持时退回session/load。一个 Agent 进程还能同时服务多个工作区的会话——ACP 的cwd是按会话绑定的。Zed 视角编辑器如何驱动 Open Science在服务器方向Zed或 JetBrains、Neovim 等任何 ACP Client只需 spawn acp-server.mjs就会经历标准流程initialize→session/new→ 流式回合 →session/list/session/load。编辑器里看到的文本、工具调用、权限请求与桌面窗口完全同源。这里藏着一个容易被忽略的坑server.ts 注释里写得很直白本项目运行时发出的是全文当前值而 ACP 走的是**增量delta**流——若直接透传全文编辑器会把 ok 渲染成 ook。所以每个 chunk 都会先与已发送内容做差量。这套互通还通过了官方agentclientprotocol/sdk参考实现的逐消息 schema 解码验证过程记录见 PROGRESS.md。 前提服务器方向依赖已开启的远程访问网关设计文档 docs/rfc/remote-access-gateway.md令牌就是凭证未开启时会得到一条可读的连接错误而不是静默失败。总结与延伸阅读想解决什么ACP 给出的答案让 Open Science 用上 Codex / Claude Code配置一条 stdio 命令零 per-agent 代码让我在 Zed 里继续科研会话acp-server.mjs复用同一网关、同一批会话Agent 能力参差不齐怎么办initialize能力协商 诚实降级设计论证与路线图docs/rfc/multi-agent-acp.md运行时接口边界docs/rfc/agent-runtime.md整体技术设计docs/TECHNICAL_DESIGN.md产品定义docs/PRD.mdACP 的价值不止于多接几个 Agent它把支持一个 Agent从写代码降级为填配置并把 Open Science Desktop 本身也变成了协议公民——既是 Client也是 Agent。这正是本地优先 模型无关理念在架构层面的落地 ✨。赞分享【免费下载链接】open-scienceOpen Science Desktop — local-first, model-agnostic AI research workbench for macOS, Windows Linux. Open-source Claude Science desktop alternative built on Tauri MCP agent skills.项目地址https://gitcode.com/gh_mirrors/ope/open-science点击查看免费下载相关推荐读懂MindFS Agent接入原理Claude SDK、Codex SDK与ACP协议如何实现统一读懂MindFS Agent接入原理Claude SDK、Codex SDK与ACP协议如何实现统一 MindFS 是开源的 AI Agent 远程访问网关Kimi Code CLI 的 IDE 集成指南通过 ACP 协议在 Zed、JetBrains 与 Paseo 中运行Kimi Code CLI 的 IDE 集成指南通过 ACP 协议在 Zed、JetBrains 与 Paseo 中运行 Kimi Code CLI 通过 AAI Agent代码智能体人工智能大模型CLI在 Zed、JetBrains 与 Paseo 中集成 Kimi Code CLI基于 ACP 协议的 IDE 接入实战指南在 Zed、JetBrains 与 Paseo 中集成 Kimi Code CLI基于 ACP 协议的 IDE 接入实战指南 Kimi Code CLI 通过AI Agent代码智能体人工智能大模型CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考