关联 Issue：https://github.com/openJiuwen-ai/sciencediscovery/issues/64

🚀 背景描述

ScienceDiscovery 今天的主入口是本机 serve + 浏览器 UI（默认 http://127.0.0.1:4310）。Agent 跑在产品自己的控制面里：Web 发任务、API 编排 Run、沙箱执行代码、MCP 接外部工具。用户如果已经在 Zed、VS Code、JetBrains 等编辑器里工作，无法把 ScienceDiscovery 当作一只标准编码 Agent 接进去，只能离开编辑器、打开浏览器。

Agent Client Protocol（ACP） 是编辑器（Client）与编码 Agent 之间的开放协议，由 Zed 于 2025 年发布，现为 Apache 2.0 开源标准。它用 JSON-RPC 2.0（通常走 stdio）约定初始化、会话、提示轮次、流式更新、权限与取消，目标类似 LSP：任意兼容 Client 可以驱动任意兼容 Agent，而不为每个编辑器写一份私有集成。当前稳定线协议是 ACP v1（initialize 时协商 protocolVersion）；v2 文档于 2026-07 以 Draft 发布，尚未作为本需求的默认目标。

ACP 与产品已有的 MCP 不在同一层、也不互相替代：

本仓库源码中没有 ACP 实现（无 agent-client-protocol、无 stdio JSON-RPC Agent 入口）。已有相关需求也不是这件事：

• GitCode #23：给已运行的 serve 做与网页对等的 HTTP CLI 客户端，不定义编辑器↔Agent 协议；
• GitCode #44：产品内部的可插拔能力与 Pending Mode，不是对外 ACP。

用户可观察结果：在兼容 ACP 的编辑器里选中 ScienceDiscovery，即可对当前工作区提问、看流式输出与工具调用、按 ACP 权限模型批准敏感操作，并走产品已有的沙箱、科研 Connector 与 Skill，而不必再开浏览器。

设计思路

默认角色：ScienceDiscovery 作为 ACP Agent（编辑器是 Client）。这与「让科研 Agent 进标准编辑器」一致。是否再做 ACP Client（用本产品 UI 去驱动 Claude Code / Gemini CLI 等其他 Agent）列为未拍板项，不阻塞第一期。

建议第一期对齐 ACP v1 基线方法（官方文档：https://agentclientprotocol.com/protocol/v1/overview）：

1. 传输：编辑器拉起本产品的 ACP 子进程，JSON-RPC 2.0 行分隔 JSON 走 stdin/stdout。不把 ACP 默认绑到现有 HTTP :4310 控制面。
2. 生命周期：initialize（版本与能力协商）→ 可选 authenticate → session/new（或有能力时 session/load）→ session/prompt / session/update / session/cancel。
3. 会话映射：一次 ACP session 对应产品内一个可恢复的 Project/Session/Run 上下文；工作区路径用 ACP 要求的绝对路径。
4. 权限与沙箱：Client 侧的 session/request_permission、可选 fs/* / terminal/* 与产品既有权限卡、Bubblewrap/Seatbelt 沙箱对齐。默认安全姿态不得比网页端更松；ACP 不得变成绕过沙箱的新通道。
5. 能力广告：在 initialize 里如实声明实际支持的 agentCapabilities（如 loadSession、prompt 图片、MCP 透传）。科研特有能力（文献 Connector、Artifact、Memory Graph）若 v1 schema 没有对应字段，走 ACP 的 _meta / _ 自定义方法，并在正文写清；不要为此另发明一套私有 JSON-RPC。
6. 可发现性（可后置）：提供编辑器能配置的启动命令与清单；是否登记 ACP Registry 未拍板。

不考虑或仅作备选：

• 只给现有 HTTP CLI（#23）加几个子命令、不实现 ACP 方法：编辑器生态接不上。
• 只做 ACP Client、自己不当 Agent：用户仍无法在标准编辑器里使用 ScienceDiscovery。
• 用产品私有事件流冒充 ACP：失去与 Zed / VS Code / JetBrains 等 Client 的互操作。
• 第一期就以 ACP v2 Draft 为唯一目标：v2 仍在草案期；实现时以当时已稳定的规范为准，v1 为默认验收线。

未拍板（实现前需确认）：

• 是否同期做 ACP Client；
• 第一期是否登记 ACP Registry（Registry 当前要求 Agent 支持认证）；
• ACP cwd / 工作区如何对应产品 Project，以及未 serve 时是否仍拉齐完整 Gateway/Runner；
• 权限批准以编辑器 ACP UI 为准，还是仍回落到产品权限卡。

涉及到的对外API

• ACP 线协议：对编辑器暴露 ACP v1 JSON-RPC（stdio）。这是新的对外契约，不是现有 REST/SSE 的别名。
• 现有 HTTP 控制面：可在本机复用 Project/Session/Run，但不得要求用户先开浏览器才能做 ACP。若 ACP 进程内嵌或附带启动控制面，对用户应是一条启动命令。
• MCP：保持 Agent↔工具层；不把 MCP stdio 与 ACP stdio 混成同一条管道。
• 无匿名公网 ACP 服务：默认仍是本机、受信任工作站，与产品「非多租户生产服务」定位一致。

与其他模块的相关性描述

• Launcher / CLI：新增 ACP Agent 入口，与 serve、#23 HTTP CLI 并列，不互相替代；
• Session / Run / 权限 / 沙箱：ACP prompt 轮次必须落到同一套执行与治理；
• MCP：ACP 会话内仍可使用已配置的 MCP Server；
• Web UI：不是本期必改表面；ACP 会话是否出现在网页会话列表未拍板；
• #44 内部能力框架：若实现时碰到装配层，可复用，但本 Issue 的验收是对外 ACP 互操作，不是内部插件协议。

测试设计与测试计划

协议符合性

• 与参考 ACP Client（或官方 schema / SDK）完成 initialize：协商到 v1（或实现时已稳定的版本），广告的能力与真实行为一致；
• session/new → session/prompt 能跑完一轮科学任务（至少：用户消息、流式 session/update、明确 stop reason）；
• session/cancel 能打断进行中的 prompt 轮次；
• 需要授权的工具调用走 session/request_permission，拒绝时不执行；
• 错误遵循 JSON-RPC 2.0 error 对象，通知无响应。

产品约束

• Python / Shell 执行仍在既有沙箱中，ACP 路径不能比网页端更宽松；
• token、API Key、会话正文不出现在 ACP 日志或未授权的 Client 回传中；
• 不占用本机试用 4310 端口或其固定数据目录做正式 E2E。

互操作 / 用户旅程

• 至少在一个真实 ACP Client（例如 Zed 或 VS Code ACP 扩展）里：配置启动命令 → 对打开的工作区提问 → 看到流式文本与至少一次工具调用；
• 定向单测覆盖 JSON-RPC 方法分发、版本协商失败、未认证（若启用 authenticate）；
• 文档给出 Client 配置示例（启动命令、工作区、认证）。

其他信息

规范与仓库（公开 HTTPS）：

• 协议总览：https://agentclientprotocol.com/protocol/v1/overview
• Schema / 参考实现：https://github.com/agentclientprotocol/agent-client-protocol
• Registry：https://agentclientprotocol.com/get-started/registry

产品当前入口仍是 ./ScienceDiscovery serve + 浏览器；本 Issue 要补的是编辑器可拉起的 ACP Agent 进程，而不是再做一个私有聊天协议。