Doco

别再靠记忆切机器：dsh-alpha 把多机多 Agent 变成一个控制面

别再靠记忆切机器：dsh-alpha 把多机多 Agent 变成一个控制面

一个主控、一份全局目录、一条可恢复的任务链路。dsh-alpha 让 DSH 能在 Codex、Claude Code、Kimi Code、ZCode、OpenCode、Qoder 与 WorkBuddy 之间做可见、可控的跨机器派发。

当编码 Agent 只有一个、代码仓库只有一份时，工作流很简单：打开终端，进入目录，发出任务。

但真实工程通常不是这样。笔记本上有产品代码，构建机上有完整工具链，GPU 主机适合视觉任务，某个内网环境才连得上测试服务。与此同时，不同 Agent 擅长的任务、可用模型、审批方式和额度也不同。真正困难的不是“再启动一个 Agent”，而是回答四个问题：任务应该去哪台机器？应该交给谁？它能在什么目录工作？执行中断后如何继续？

dsh-alpha 为此提供了一个轻量控制面。

从机器列表，升级为全局工作区

dsh-alpha 不把主控机上的绝对路径当成项目真相。每台 Worker 只上报自己 allowed roots 内的工作区，主控再按 Git 仓库身份聚合：同一个仓库即使位于不同机器、不同路径，也会呈现为一个逻辑项目。

这件事看似简单，却解决了跨机器派发最容易踩中的坑：把 A 机器的路径原样发给 B 机器。现在，用户选择的是“哪个项目”，Worker 解析的是“这个项目在我这里对应哪个安全路径”。如果目标 Worker 尚未持有仓库，也只能在它显式允许的根目录下按需 clone。

让选择保持可见

Alpha 主控目录集中展示机器、项目和 Agent。你可以为机器写下限制，为项目补充分派原则，也可以为不同 Agent 类型记录擅长场景。这些信息不是隐藏的调度魔法，而是会进入主控决策上下文的可见依据。

每一轮任务还可以单独指定 Worker Agent、模型、推理强度与权限模式。需要自动化时保持自动；需要确定性时明确锁定。选择发生在当前对话里，不必在多个终端和窗口之间来回切换。

一条真正能恢复的任务链路

派发不是一次性 RPC。dispatch_task 先返回持久化任务 ID，wait_task 再通过事件流等待进度和结果。等待被打断并不等于取消任务；重新使用同一个任务 ID即可继续。只有显式停止才会向 Worker 传播取消。

审批也沿着同一条链路返回。Worker 请求权限时，Alpha 会把待决审批交回当前会话，由用户批准或拒绝，避免远端任务在看不见的地方永久挂起。Worker 暂时断线后会自动重连，并补回缺失事件。

安全边界不是附录

dsh-alpha 的默认策略是故障关闭：Gateway 开启却没有 token 时拒绝启动；本机和远程路径都必须通过 allowed roots；健康检查不暴露机器身份或密钥；Worker doctor 只读检查配置且不打印 token。

它也不会替代各 provider CLI 的安全模型。Codex、Claude Code、Kimi Code 等 runtime 仍需在实际执行机器上独立安装、登录和维护权限。dsh-alpha 负责把选择、路由、事件和恢复串起来，而不是绕过任何已有控制。

适合什么团队

  • 同时使用多种编码 Agent，希望按任务匹配擅长项；

  • 开发环境分布在个人电脑、远程主机和专用构建机；

  • 同一仓库在多台机器上有不同路径；

  • 需要把审批、取消、断线恢复留在一个会话里；

  • 希望先用 Web 可视化控制，再逐步接入 headless 自动化。

从一个 Worker 开始

不需要一次搭建庞大集群。先在 DSH Web 安装 dsh-alpha，把一台远程机器配置为 Worker，为它限定 allowed root，再用 Worker doctor 做只读检查。确认目录、Agent 能力和任务回传都正常后，再添加下一台机器。

dsh-alpha 仍处于快速演进阶段，但核心闭环已经形成：发现、选择、派发、审批、恢复。它试图回答的不是“哪个 Agent 最强”，而是更工程化的问题——怎样让不同 Agent 在正确的机器、正确的项目和明确的权限边界里协同工作。

项目主页：https://songofhawk.github.io/dsh-alpha/

GitHub：https://github.com/songofhawk/dsh-alpha