Problem / 问题
EN: Agents today are bound to a single filesystem root — one local directory, or one SSH host. Real projects often span several machines at once: a Linux box where the services actually build and run, a Windows machine holding the working copy (because some editors and tooling are Windows-only), plus one or more remote target servers on different branches or environments.
The agent only ever sees one side. Reading anything on the other machine means manual copy/scp, so cross-machine search, diff, and “edit here → verify there” can’t happen inside one task.
The same logical file has different absolute paths per machine, so the agent rebuilds that mapping every session and frequently hallucinates paths or edits the wrong copy.
The toolchain is split by OS and by role (edit and VCS operations on one host, build/run/debug on another), with no way to route a command to the right host and keep the result in context.
Teams work around this with ad-hoc sync scripts plus written rules the agent must remember. That discipline lives outside the agent — easy to bypass, and with no permission, revision-consistency or conflict guarantees.
中文： 目前 agent 的上下文被绑死在单一文件系统根上——要么一个本地目录，要么一台 SSH 主机。真实项目经常同时横跨多台机器：服务实际构建与运行所在的 Linux 机、持有工作副本的 Windows 机（因为部分编辑器和工具链只有 Windows 版），外加一台或多台处于不同分支/环境的远端目标服。
agent 只能看见其中一侧，另一侧的文件要靠人肉 copy/scp，于是「跨机搜索 / 跨机 diff / 在这台改、去那台验证」无法在一个任务里完成。
同一份逻辑代码在各机上的绝对路径不同，agent 每次都要重建这层映射，因此经常出现幻觉路径、改错副本。
工具链按 OS 和角色分裂（一台上做编辑与版本库操作，另一台上构建/运行/调试），却没有办法把命令路由到指定主机、并把结果留在同一上下文里。
现有绕行方案是自建同步脚本 + 写文档约定让 agent 遵守。这套纪律游离在 agent 之外，很容易被绕过，也没有权限、版本一致性与冲突保障。
Solution / 方案
EN: A first-class cross-machine workspace pack: one declarative, committable unit that groups N directory roots living on different devices, each carrying a host binding and a role.
中文： 引入一个一等公民抽象——跨机器工作区 pack：一个可声明、可提交的单元，把分布在多台设备上的 N 个目录根聚合在一起，每个根携带自己的主机绑定与角色。
// .qoder/workspace.pack.json
{
“name”: “my-project”,
“roots”: [
{ “id”: “dev”, “host”: “local”, “path”: “D:/work/repo”, “role”: “source” },
{ “id”: “build”, “host”: “ssh:linux-aone”, “path”: “~/repo”, “role”: “runtime” },
{ “id”: “st1”, “host”: “ssh:server-a”, “path”: “/srv/repo”, “role”: “mirror”, “access”: “read” }
],
“mirrors”: [{ “from”: “dev:src”, “to”: “build:src” }]
}
EN — required capabilities:
Unified addressing — every file tool (read/write/edit/grep/glob) accepts pack:///; relative-path resolution is driven by the pack, not by a single cwd.
Cross-root search/index — one search spans all roots (local instant, remote over the existing SSH channel), results tagged by root.
Path mapping & drift detection — explicit “this path on A == that path on B”, with ahead/behind/conflict status, so the agent knows which copy is authoritative before writing.
Per-root execution — bash/exec can target a specific host, and its output stays in the same context as the file operations.
Safety boundaries — per-root read/write permission, git/svn awareness, confirmation for destructive cross-machine writes.
Context injection — the pack description is visible to the model, so “what lives where” is known natively instead of re-explained each session.
An incremental version is acceptable: read-only multi-host roots + unified search + explicit per-root exec first, then write mapping and drift detection.
中文 — 需要的能力：
统一寻址 — 所有文件工具（read/write/edit/grep/glob）接受 pack:///；相对路径解析由 pack 驱动，而不是单一的 cwd。
跨根搜索/索引 — 一次检索覆盖全部根（本地即时、远端走已有 SSH 通道），结果带来源根标签。
路径映射与漂移检测 — 显式声明「A 机这个路径 == B 机那个路径」，并给出领先/落后/冲突状态，让 agent 在写入之前就知道哪份是权威。
按根执行 — bash/exec 可以指定在哪个主机上跑，输出与文件操作共享同一上下文。
安全边界 — 每个根独立的读/写权限、git/svn 状态识别、破坏性跨机写入需要确认。
上下文注入 — pack 描述对模型可见，「什么东西在哪台机器」是天然已知，而不是每次会话重新解释一遍。
渐进式落地也可接受：先做「多主机只读根 + 统一搜索 + 显式按根执行」，再加写入映射与漂移检测。
Use Case / 使用场景
EN:
Dev-on-one-host / run-on-another: a very common server-side setup — a developer’s desktop or laptop holds the working copy and the editors, while the actual build, boot, debug and hot-reload all happen on a remote Linux machine. A single task like “change this logic, then verify it end to end” requires the agent to edit on one host, build and run on another, read the resulting log, and write the conclusion back to a doc. Today a human shuttles the files between the two sides. Some domains add OS-specific tooling on top (asset/config editors that only ship for Windows), but the shape is the same.
Multi-environment / multi-branch comparison: compare a suspect config or log across several target servers running different branches or environments in one pass, instead of reconnecting host by host.
Multi-device workflow: laptop + desktop + build machine on the same repo, with the agent knowing which root is source of truth and which is a mirror.
中文：
「一台改、另一台跑」：服务端开发里非常普遍的形态——工作副本和编辑器在开发者本地机器上，而真正的构建、启动、调试、热更全在远端 Linux 上。一个「改这段逻辑，然后端到端验证一次」的任务，就需要 agent 在一台主机上编辑、在另一台上构建运行、读产出的日志、再把结论写回文档。如今中间的文件搬运全靠人。部分领域还会额外叠加 OS 专属工具（比如只有 Windows 版的资产/配表编辑器），但结构形态是一样的。
多环境 / 多分支对比：一次动作就横跨多台处于不同分支或环境的目标服务器，比对可疑配置或日志，而不是逐台重连。
多设备开发：笔记本 + 台式机 + 构建机同用一个仓库，希望 agent 明确知道哪个根是唯一真源、哪个只是镜像。
Priority / 优先级
EN: 
Medium — important improvement. For teams whose work is inherently split across machines/OSes — server-side development in particular, where “develop locally, run remotely” is the norm — this is effectively blocking: it’s the reason long multi-step tasks can’t be handed to the agent as a whole and must be chopped into per-machine pieces.
中文： 中 —— 重要改进。对于工作天然分布在多机/多 OS 的团队——尤其是服务端开发这一常态即「本地开发、远端运行」的场景——这实际是阻塞项：正因为缺它，长链路的多步任务无法整体交给 agent，只能被人工按机器切成一段一段。
Additional Info / 补充信息
EN:
VS Code Remote’s multi-root workspace solves multiple folders on one machine; it isn’t host-aware. This request is essentially “make multi-root cross-device.”
Qoder already speaks SSH, so the transport layer exists — what’s missing is the workspace-level abstraction and the agent-side unified addressing/routing on top of it.
Our current workaround: hand-written sync scripts on each side (Linux + Windows) that transfer by VCS status and check revision/URL consistency before copying, plus a written rule telling the agent which path maps where. It works, but every new project re-implements it and the agent can silently violate it.
中文：
VS Code Remote 的 multi-root workspace 只解决同一台机器上的多目录，它不感知主机。本请求本质上是「把 multi-root 做成跨设备的」。
Qoder 已经具备 SSH 连接能力，通信底座是现成的——缺的是 workspace 层抽象，以及建在其上的 agent 侧统一寻址与执行路由。
我们现在的绕行方案：两侧各写一份同步脚本（Linux + Windows），按版本库状态传输、复制前校验 revision/URL 一致性，再配一份文档规则告诉 agent 路径如何映射。能用，但每个新项目都要重写一遍，而且 agent 随时可能在无感知的情况下违反它。