DeepSeek Harness 实战：Web UI 与多端协同——你的 Agent 不止活在终端里

DeepSeek Harness 实战：Web UI 与多端协同------你的 Agent 不止活在终端里

系列导航：概念 / 教程 / 架构 / 插件 / 编码实战 / 框架对比 / 会话日志 / Headless·CI / 自定义工具 / 模型适配 / 本文（Web UI 与多端协同） / 安全沙箱 / 多 Agent / 二次开发

前面我们把 Agent 当"命令行里的同事"用了很久：编码、接 CI、写工具、换模型。但 DSH 真正让人"眼前一亮"的入口，其实是它的 Web UI------一个开箱即用、浏览器里就能和 Agent 协作的图形界面。

很多人有一个误区：以为 Agent 框架都是"终端里敲命令"的极客玩具。DSH 偏不。它把 Web UI 当成一等公民：默认启动就开界面、支持文件引用、历史会话引用、多模态输入、任务轨迹面板、子代理任务面板。更关键的是，Web UI、Headless 命令行、ACP 远程接入，三者共享同一套会话内核------你在浏览器里开的会话，换个端也能接着聊。

这篇我们就把"界面这一层"和"多端如何协同"讲透：Web UI 长啥样、怎么用、为什么它刻意只监听本地、怎么和 Headless/ACP 配合、多端之间会话怎么同步。看完你会明白：DSH 不是"只有一个终端入口"，而是一个多端可达的 Agent 运行时。

一、一句话定位：Web UI 是默认入口

先说最省事的事实：装好 DSH 后，启动 Web UI 只需要一条命令：

bash 复制代码

npx @deepseek-ai/dsh web

默认它就把界面服务在 http://127.0.0.1:3080。注意端口是 3080（社区多篇实测都确认了这一点，比如 atomicbot 的文档梳理）。而且从 2026-08 中旬的提交记录看，官方已经改成"默认打开就绪的 Web UI"------也就是你启动后浏览器界面会自动就绪，不用再手动找地址。

所以对新手最友好的路径就是：装好 → dsh web → 浏览器开 127.0.0.1:3080 → 开聊。模型配置、工具开关、会话管理，全在界面里点。这比一上来啃 CLI 参数友好得多。

二、为什么端口是 3080，又为什么只听本地

两个问题分开讲，因为第二个关乎安全，很重要。

为什么 3080？ 没啥玄学，就是官方选定的默认端口（类似于很多本地开发服务器挑 3000、8080）。你不用记它，启动日志会告诉你确切地址；真要改，也走配置，别硬记数字。

为什么只听 127.0.0.1（loopback）？ 这是刻意的安全设计。Web UI 背后是一个能执行 Shell、读写文件的 Agent------也就是说，这个界面一旦暴露到公网，就等于把"能在你机器上跑命令"的能力直接交给了全网。官方连这个风险都写进设计里：CLI 会直接拒绝你绑定全网卡：

bash 复制代码

# 这一行会被 CLI 拒绝
dsh web --host 0.0.0.0

为什么拒绝？因为 0.0.0.0 表示"监听所有网络接口"，把本地 Agent 变成了一个网络可达的远程代码执行面（RCE surface）。官方宁可你报错，也不让这个隐患悄悄打开。这条红线，请务必尊重------Web UI 只该待在 127.0.0.1。

三、Web UI 底下是什么：host 与 client 两个包

我们讲架构时提过"一切皆插件"。Web UI 在代码层面，对应仓库里的两个包：

packages/host ：负责"服务端"。里面又分 host/webserver（真正起 HTTP 服务、和前端通信的那层）和 host/frontend-static（打包好的静态前端资源）。简单说，host 是"把 Agent 运行时暴露成 Web 服务"的那一半。
packages/client ：负责"前端与连接"。它下面拆得很细：client/connection（和 host 建立连接，底层其实就是 ACP 那套通信）、client/ui-conversation（对话区组件）、client/ui-primitives（基础 UI 原子组件）、client/ui-sidebar（侧边栏）、client/ui-workspace（工作区视图）。

这种"host 管服务、client 管界面"的拆分，本身就是"一切皆插件"的体现：界面不是写死在内核里，而是一组可替换的前端模块。你甚至可以基于 client 的连接协议，自己做一个完全不同的界面（比如终端 TUI、IDE 插件），只要它走同样的通信协议。

四、界面里能干什么：从对话到引用

讲完底层，回到你每天会用到的界面功能。DSH 的 Web UI 不是"一个聊天框"那么简单，它把 Agent 协作需要的上下文操作都做进了界面：

1. @ 菜单：把文件和会话拽进上下文

RC.8 之后，@ 菜单新增了文件引用和历史会话引用。你写任务时，可以 @ 一个本地文件，把它作为上下文喂给 Agent；也可以 @ 一段历史会话，让 Agent 基于"之前聊过什么"继续。这解决了 Agent 协作里一个老大难：复杂任务往往依赖大量背景资料，手动粘贴又慢又丢信息------@ 引用让"带上下文"变得点几下就成。

2. 多模态输入：/goal、/plan 支持图文混合

RC.8 起，DeepSeek 模型适配器支持原生图片请求，你可以通过 /goal、/plan 等核心指令做图文混合输入。也就是说，你截一张报错图、贴一张设计稿，@ 进去或者直接图文一起发给 Agent，它就能"看图说话"。这背后要求底层 provider 声明了 input: [text, image]（呼应我们模型适配那篇），UI 只是把多模态能力暴露成了好用的入口。

3. 任务轨迹面板（Trajectory Panel）

我们在编码实战那篇讲过，DSH 把"模型看到的一切、做的每一步"都记进会话日志。Web UI 把这些日志可视化成了轨迹面板：你能逐条回看系统提示词、模型推理过程、工具调用的参数与返回、文件修改、终端命令。调试 Agent 时，这个面板就是你的"黑匣子回放"------哪一步模型想错了、哪个工具返回异常，一目了然。

4. 子代理任务面板（Job Panel）

RC.7 起，子代理（比如委派给 Codex、Claude Code 的任务）接入了 Job Panel，你可以在界面里直接看这些子 Agent 的执行过程、状态、结果。这让"多 Agent 协作"不再是黑盒，而是看得见、管得着的面板操作。

五、Settings 页：模型与配置的图形入口

Web UI 里最重要的"后台"是 Settings 页，尤其是 Settings → Models 。我们模型适配那篇讲的 llm-pi-ai 配置，在界面里就是在这里操作的：

点 "Add a custom provider"，填 Provider ID、Base URL、API protocol、API Key，就能接一家新模型。
点 "Fetch available models" 自动从 GET /models 拉模型列表勾选。
界面填的 key 会存到 $DSH_HOME/.credentials.yaml，界面只保留脱敏引用、不回显明文。

所以"配模型"这件事，Web UI 和 yaml 是两条等价路径：界面点出来的，本质就是写进 settings.yaml 和 .credentials.yaml 那几行。喜欢可视化的用界面，喜欢版本管理/团队纳管的用 yaml------两者互不冲突，因为 ultimately 是同一份配置。

六、多端协同的基石：会话内核是共享的

现在进入本篇的核心命题------多端协同。

DSH 最妙的设计之一是：Web UI、Headless 命令行、ACP 远程接入，三者共享同一套会话内核 。具体说，会话的状态（消息、工具调用、文件修改、Shell 进程）都存在 session_root 指向的持久化目录里（我们会话日志那篇讲过，是 JSONL + SQLite）。无论你从哪个端发起，只要指向同一个 session_root 和同一个 session_id，你看到的就是同一段会话。

这意味着什么？举几个真实场景：

早上在浏览器里开了个会话，下午想用脚本批量跑同任务 ：用 Headless 指向同一个 session_root，会话历史还在。
你的主 Agent 在本地 Web UI 跑，子 Agent 通过 ACP 跑在另一台机器：两者通过会话协议对齐，子 Agent 的结果回到主会话的轨迹面板。
CI 里 Headless 跑完，你想在界面里复盘 ：打开 Web UI 指向那个 session_root，把日志可视化回看。

这就是"多端可达的 Agent 运行时"------入口可以有很多个，但会话只有一份真相（source of truth）。

七、Web UI 与 Headless：一个用于人，一个用于机

把两个入口对比着看，理解更深：

维度	Web UI	Headless
使用者	人（交互式）	程序/脚本/CI
界面	图形，可视化轨迹、面板	无界面，只进退出码和最终文本
启动	`dsh web`	`dsh --profile headless "任务"`
适合	探索、调试、复杂协作	自动化、批量、门禁
会话	同一 `session_root` 可续	同一 `session_root` 可续

关键认知：两者不是替代关系，是互补关系。Web UI 让你"和 Agent 一起想"，Headless 让 Agent "替你跑完"。而因为它们共享会话内核，你可以在 Web UI 里起头、Headless 里收尾，或者反过来。这种"人机各取所长"的协作流，是 DSH 区别于纯 CLI 框架的地方。

八、ACP：让 DSH 能被"远程召唤"

再上一层，是 ACP（Agent Client Protocol）。我们 Headless 那篇讲过，ACP 是一套"客户端---服务端"通信协议，而 Web UI 底层的 client/connection 走的就是它。

ACP 的价值在于：它让 DSH 能嵌入别人的系统。比如另一个程序（IDE 插件、自有平台、别的 Agent）想"召唤"一个 DSH 会话，不用自己实现整套 Agent 逻辑，只要按 ACP 和它对话即可。DSH 作为 ACP 服务端暴露工具、注册适配器、启动进程、管理任务、收集结果。

所以"多端协同"的终局是：你的 DSH 不只是一个本地 app，而是一个可被任意客户端接入的 Agent 服务。Web UI 只是官方给的一个客户端实现，你完全可以写自己的客户端------只要它讲 ACP。

九、session_id 与 session_root 的协同细节

多端协同要玩得转，得懂两个参数怎么配合（尤其你用 SDK 或 Headless 时）：

session_root ：会话文件的存放根目录。Web UI 默认有一个，Headless/SDK 你可以显式指定。想让多端共享会话，就让他们指向同一个 session_root。
session_id ：具体某个会话的 ID。同一 session_root 下，不同 session_id 是不同会话。

有个 SDK 层面的细节值得记：复用同一个 harness 实例 + 同一个 session_id，会保留该会话拥有的 Bash 进程 （工作目录、已导出变量、shell 函数都还在）；独立任务要用新的 session_id，否则会串台。这在多端场景里同样成立------你在 Web UI 用 abc-123 这个 id 开了会话、跑了命令、导出了变量，之后用 Headless 指向同一个 session_root + abc-123，那些 shell 状态还在。

十、为什么 Web UI 刻意"不加 TLS、不加登录"

前面讲"只听本地"时埋了个伏笔：Web 服务本身没有通用的 TLS/认证层。也就是说，它生来就是为"本机环路"设计的，不是为"暴露在网上的多用户服务"设计的。

官方文档说得很直白：

不自带认证，因为假设使用者就是本机那个人。
如果非要暴露在反向代理后面，光套一层反代不足以构成安全边界------除非你同时设计了底层的 API 信任与认证模型。
CLI 直接拒绝 --host 0.0.0.0，就是为了防止有人"图省事"把 Agent 变成公网 RCE。

这给团队部署提了个醒：别把 Web UI 当 SaaS 用。多人共用，请走"每人本机一个 DSH"或者"DSH 作为后端服务、前端用你自己的鉴权层包一层"的架构，而不是把官方 Web UI 直接绑公网。尊重它的定位，安全边界才清晰。

十一、实战：浏览器里完成一次"带上下文"的排错

讲个具体用法，让你感受 Web UI 的价值。假设线上报了个诡异 bug，你手里有报错截图和出问题的源码文件：

打开 127.0.0.1:3080，新会话。
在输入框 @ 出那个源码文件，把它的内容作为上下文。
直接把报错截图拖进 /goal（RC.8 多模态支持），写："复现这个报错，定位根因，给出修复。"
Agent 读文件、看图、跑测试、改代码，每一步在轨迹面板实时可见。
你发现它某步推理跑偏，直接在审批弹窗拒绝，让它换思路------这就是"人在回路"的协作。

换成纯 CLI，你要手动贴文件内容、描述截图，信息损耗大得多。Web UI 把"带上下文协作"的成本压到了最低。

十二、实战：Web UI 起头，Headless 收尾

再一个常见组合：

白天在 Web UI 里和 Agent 搭出一个任务框架，会话 id 是 feature-x，session_root 是默认的。
晚上你想让它"跑完整个测试套件并把结果写进报告"，但不想一直开着浏览器。
用 Headless 指向同一个 session_root + feature-x（或新 id 但共享 root），让它无人值守跑完。
第二天回 Web UI，打开那个会话，轨迹面板里已经躺好了完整的执行记录。

这种"人机接力"之所以顺，全靠"共享会话内核"。你不必把上下文从一端搬到另一端------它一直在那。

十三、前端模块拆解给你看（二次开发彩蛋）

如果你是开发者、想改界面，记住 packages/client 的拆分：

ui-conversation：对话气泡、消息流。想改消息展示样式，动这里。
ui-sidebar：侧边栏（会话列表、文件树等）。
ui-workspace：工作区视图（文件、终端、面板布局）。
ui-primitives：按钮、输入框等原子组件，全站统一用。
connection：和 host 的通信层，封装 ACP 细节。

这种细粒度拆分意味着：你想换皮肤改 ui-primitives，想加面板加 ui-workspace，想换通信协议改 connection------彼此不打架。这又是"一切皆插件"在前端的投影。下一篇（二次开发）我们会讲怎么自己写插件，但你可以先记住：界面也是可插拔的。

十四、多模态与 `@` 引用的工程意义

表面看 @ 引用和多模态是"体验优化"，工程上它解决的是 Agent 协作的上下文带宽问题。

传统 CLI 里，你给 Agent 的上下文基本是"一段文字 prompt"。但真实任务里，上下文是文件、截图、历史对话、报错日志的混合体。@ 引用让你把这些"非文本上下文"结构化地喂进去；多模态让你直接发图。两者叠加，Agent 拿到的信息保真度大幅提升，瞎猜的概率下降。

对团队尤其有用：新人接手项目，直接 @ 历史会话"看前辈怎么处理的类似问题"；排查线上问题，直接 @ 日志文件 + 截图。知识不再散落在聊天记录里，而是能被"引用"地复用。

十五、Job Panel 与多 Agent 的界面化

前面提了 Job Panel，这里补一句它和后续"多 Agent"篇的衔接。

当主 Agent 把任务委派给子 Agent（比如 Claude Code、Codex），这些子任务不再是"黑盒里跑完给个结果"，而是在 Job Panel 里可见、可管 。你能看到哪个子 Agent 在跑、跑到哪、成败如何。RC.8 还加了 reportDelivery 机制：子 Agent 完成任务可实时反馈、自动唤醒父任务。

界面化多 Agent 协作的意义在于：编排不再只是代码层的事，也是可观测、可干预的事。你能在面板里发现"某个子 Agent 卡住了"，及时介入。这把"多 Agent"从炫技变成了可控的工程实践------这也是下一篇（多 Agent）要展开的主线。

十六、和封闭产品的界面对比

横向看，Claude Code 主要是终端 TUI + 自有界面；DSH 的 Web UI 走的是"浏览器图形界面 + 开放通信协议"路线。差异背后是哲学：

封闭产品：界面是产品的一部分，你用它的界面，接受它的形态。
DSH：Web UI 只是官方给的一个客户端实现，通信协议（ACP）开放，你完全可以替换界面。

所以如果你觉得官方界面不够用，别忍着------理论上你能基于 client/connection 的协议写自己的前端。当然，对大多数人，官方 Web UI 已经足够好用且开箱即用。

十七、部署边界的再提醒

把安全那条再强调一次，因为它和多端协同强相关：

Web UI 默认只听 127.0.0.1，别强行 --host 0.0.0.0。
它没有内置认证，不当 SaaS 用。
真要远程用，正确做法是"本机跑 DSH，通过你自己的安全通道（如 SSH 隧道）访问 127.0.0.1:3080"，而不是把服务绑公网。
多人团队，优先考虑"每人本地一个实例"或"自建带鉴权的前端层"。

这些不是"限制"，是"把危险面控制在本机"的自觉。Agent 能执行命令，它的入口就必须被当成一扇门来守。

十八、给新手的 Web UI 上手清单

如果你是第一次用，照这个清单走：

npx @deepseek-ai/dsh web，等浏览器自动打开或手动访问 127.0.0.1:3080。
在 Settings → Models 确认默认 DeepSeek 模型已就位（或加自定义 provider）。
新会话，先用纯文字任务试水（"读一下 README，写个概要"）。
试 @ 一个文件，感受"带上下文"的协作。
打开轨迹面板，看 Agent 每一步怎么想的、怎么做的。
想自动化时，切到 Headless（参考我们那篇），指向同一个 session_root。

别一上来就追求"最牛用法"。先把对话、引用、轨迹这三个基础玩顺，Web UI 的价值自然就出来了。

十九、一句话总结 Web UI 的定位

如果只留一句：Web UI 是 DSH 给"人"准备的那个入口------它把会话、上下文、轨迹、子任务都可视化成了点几下就成的事；而它和 Headless、ACP 共享同一套会话内核，让你能在"人交互"和"机自动化"之间自由切换，而不丢任何一个字节的上下文。

二十、下一篇预告

本篇讲了"界面与多端"。但界面再漂亮，Agent 能读写文件、能执行命令，安全问题就绕不开。下一篇我们钻进安全与沙箱：三档权限（read-only / workspace-write / danger-full-access）底层怎么用操作系统能力把你 Agent 圈起来，审批流怎么"失败即拒绝"，凭据怎么只写不回显，web_fetch 为什么默认被禁。那是把 Agent 放心用起来的必修课。

二十一、Web UI 与 session 持久化的深入关系

我们反复说"共享会话内核"，这里把机制讲透一点。Web UI 启动时，背后会有一个 session_root（默认在 $DSH_HOME 下某处，或你指定的目录）。所有会话以"追加写入"的方式存在那里------消息、工具调用、文件改动、Shell 进程状态，逐条落盘成 JSONL，元信息进 SQLite。Web UI 只是这些数据的"可视化阅读器 + 写入器"。

这带来一个反直觉但重要的特性：关掉浏览器，会话没丢 。你第二天打开 Web UI，会话列表里还是那些会话，轨迹还在。因为真相在磁盘上，不在内存里、不在某个进程里。这也是"多端协同"能成立的根------无论 Web UI、Headless 还是 ACP，只要指向同一个 session_root，读写的就是同一份真相。把"会话当文件"这个认知立住，你对 DSH 的所有多端玩法就通了。

二十二、真实团队的多端拓扑长啥样

抽象讲完，给个具体的团队拓扑，让你看到"多端协同"在团队里怎么落地：

开发者本机 ：每个人装 DSH，dsh web 起本地界面，日常交互式编码、调试。所有会话在本机 session_root。
CI 机器 ：流水线里用 Headless，指向一个共享存储上的 session_root（或每次新建临时 root），把自动化任务的轨迹留痕。
编排层：团队自建一个调度服务，通过 ACP 召唤 DSH 子 Agent 做特定子任务，结果回主会话。
复盘端 ：任何人想看某个会话，只要能访问对应的 session_root，用 Web UI 或工具打开即可，无需原机器在线。

这个拓扑的核心纪律是：会话真相集中在 session_root，入口随意分散。这比"会话锁在某个人终端里"的协作模式先进太多------知识不再随人走、随进程死。

二十三、Web UI 里的审批流体验

我们在安全篇（下一篇）会细讲审批机制，这里先从界面视角看它怎么呈现。

当 Agent 想做超出当前权限的事（比如写工作区外的文件、执行敏感命令），Web UI 会弹出一个审批卡片：告诉你"它想做什么、影响什么路径/命令"，你点允许或拒绝。这不是后台静默判断，而是明晃晃地拦在你和 Agent 的越界动作之间。

界面化审批的价值在于：决策可见、可追责。你拒绝的那一刻，这个决策写进会话日志（approval/decided），日后审计能看清"谁、何时、拒绝了什么"。这和"无脑点允许"的体验天差地别------它逼你做一次有意识的确认。所以请用 Web UI 时，认真对待每一个审批弹窗，别养成肌肉记忆式点同意。

二十四、Web UI 与权限档的配合

Web UI 里你能选/看到当前会话的权限档（read-only / workspace-write / danger-full-access，下篇详讲）。界面和权限是联动的：

选了 read-only，界面上 Agent 的写操作会被拦，你看到的是"只读分析"形态。
选了 workspace-write，日常开发够用，越界写被拒并提示。
danger-full-access 是"危险模式"，界面通常会让你二次确认才切过去------因为它没有文件系统围栏了。

界面在这里的作用是把"抽象权限"变成"可感知的状态"。你不用记底层沙箱机制，只要看当前档位、看审批弹窗，就知道 Agent 现在能碰哪、碰不了哪。这是图形界面的红利：把安全边界"显示"出来。

二十五、界面里的工具开关与预设（Preset）

Web UI 通常和"预设（Preset）"配合。预设是能力组合包------同一模型挂不同工具集，承担不同岗位（标准/代码/极简/创造）。在界面里切换预设，本质是在 cordis.yml 这套插件组合上做overlay。

对多端协同来说，预设保证了一件事：无论你从哪个端进来，只要预设一致，Agent 的能力面就一致。你在 Web UI 用"标准模式"开的会话，Headless 用同一预设跑，行为可预期。这避免了"界面里能用的工具、脚本里却没挂"的割裂。所以团队落地建议：把预设也纳入统一配置，别让每人自定义一套导致行为漂移。

二十六、轨迹面板的高阶调试法

轨迹面板不只是"好看"，它是调试 Agent 的主工具。给你几招实战用法：

看工具返回：某步结果不对，展开那一行的工具调用，看参数和返回值，往往能定位是"模型传错参"还是"工具本身返回异常"。
看推理过程：模型为什么走弯路？展开 reasoning，看它当时的假设，常能发现"它误以为 X"的源头。
对比两次跑：同一任务跑两遍结果不同？把两个会话的轨迹并排看，哪一步分叉一目了然。
定位卡死：任务卡住不动？看最后一条事件是什么类型，是等审批、等工具返回、还是模型超时。

这些用法在 Headless 里也能做（因为日志在磁盘），但 Web UI 把它们可视化了，调试效率高出一截。所以"重交互调试用 Web UI，重批量自动化用 Headless"，是效率最优解。

二十七、Web UI 与凭据管理界面

前面提过 key 存 $DSH_HOME/.credentials.yaml、界面只回显脱敏。Web UI 的 Settings 里填 key，就是往那个文件写。这里有个安全要点：界面从不显示明文 key ，你看到的是 sk-...**** 这类脱敏串。截图、录屏、别人瞄一眼屏幕，都拿不到真实密钥。

但反过来，你自己要守住一条：别把 ~/.dsh（或你的 $DSH_HOME）同步到云盘、别提交进仓库。那个目录里既有配置也有脱敏前的 .credentials.yaml。同步/提交 = 把私钥一起带走。Web UI 帮你"不回显"，但"不泄露"的最后一道关，在你自己的文件管理习惯上。

二十八、Web UI 对大会话的处理

当会话很长（几百轮、大量文件改动），Web UI 怎么不卡？这涉及前端的分页/虚拟化，以及后端把"完整日志"和"投影缓存"分开（仓库里有 session-projection-cache 这个包，就是做"快速展示用投影"的）。简单说：完整真相在磁盘，界面读的是"轻量投影"，所以刷起来不卡。

这对你意味着：会话再长也别怕界面崩。实在卡，多半是投影缓存没跟上，清一下或重启 Web UI 即可，不影响磁盘上的真实日志。理解"投影≠真相"这个分层，你就不会因为界面卡而怀疑数据丢了。

二十九、常见 Web UI 问题与排查

整理了几个高频问题：

打不开 127.0.0.1:3080 ：先看启动日志有没有报错（端口被占？权限问题？）；确认没手贱加 --host 0.0.0.0 被拒。
界面空白/卡在加载 ：多半是前端资源没加载全，检查 host/frontend-static 是否就位；开发者预览偶尔有构建问题，可重装或等更新。
模型列表拉不出来 ：对方没暴露 GET /models，去 yaml 手动列 models ID（模型适配篇讲过）。
会话不见了 ：确认 session_root 指对了；Headless 和 Web UI 要用同一个 root 才能互相看到。
审批弹窗不出现就执行了 ：检查权限档是不是 danger-full-access（那个档不拦）；正常应该是 workspace-write + ask。

三十、Web UI 在企业里的正确打开方式

企业想把 DSH 用起来，Web UI 的定位建议是：

个人工作端 ：开发者本机 dsh web，自管 session_root。
不要在公网裸跑官方 Web UI：无认证、无 TLS，绑定公网 = RCE 风险。
集中审计靠日志不靠界面 ：把 session_root 落到团队可访问的存储，审计从日志走，不从"谁开着界面"走。
前端可自研 ：如果真要多人 Web 访问，基于 ACP（client/connection 协议）自己包一层带登录的前端，比裸暴露官方 UI 安全。

一句话：把 Web UI 当"本机交互器"，把"多用户服务"当"需要你自己加安全层"的工程问题------别混淆这两件事。

三十一、和 IDE 插件的协同想象

虽然官方主推 Web UI，但 ACP 开放意味着 IDE 插件也是顺理成章的客户端。想象一下：你在 VS Code 里装个 DSH 插件，它走 ACP 连你本机的 DSH 运行时，对话面板嵌在侧边栏，文件引用直接取当前编辑器内容------这体验和 Web UI 殊途同归，只是入口在 IDE 里。

这说明了 DSH 架构的延展性：入口可以是浏览器、可以是 IDE、可以是 CI 脚本、可以是别的 Agent，只要讲 ACP、指向同一个 session_root。"多端协同"的"端"，边界由你定义。

三十二、Web UI 的局限性（客观说）

客观讲，开发者预览阶段的 Web UI 也有局限，别神话它：

它是为"本机单用户"设计的，多用户并发不是它的强项。
界面功能随版本快速迭代，今天有的面板明天可能重构（rc.7 到 rc.8 就大改了多模态和 Job Panel）。
深度定制界面需要懂 packages/client 的前端栈，门槛不低。
没有内置的"团队共享会话"的权限模型，共享靠你自己的存储/访问设计。

知道局限，你才不会在错误场景硬上 Web UI。它是优秀的本机交互器，不是现成的多租户 SaaS。

三十三、一个关于"入口自由"的体会

用了一阵 DSH 后，我最大的体会是"入口自由"带来的心智变化：以前用封闭 Agent 产品，我被它的界面形态绑住；用 DSH，我可以在浏览器里想、在脚本里跑、在别的系统里召唤，而上下文始终连贯。这种"Agent 不再被困在某个 App 里"的感觉，才是它最打动人的地方。

Web UI 是这自由的第一个、也是最友好的入口。但它只是入口之一------记住这一点，你就站在了"用 Agent 而非被 Agent 产品绑定"的这边。

三十四、最后的提醒

把安全那条刻进习惯：Web UI 再方便，也只该在 127.0.0.1。它身后是一个能跑命令的 Agent，把门开到公网等于把钥匙插在门上。本机用、SSH 隧道远程用、或自建带鉴权层------这三选一，别选"裸绑 0.0.0.0"。

三十五、Web UI 与二次开发的交汇点

本篇是"界面篇"，下一篇是"安全篇"，再下一篇是"二次开发篇"------其实三者在这里交汇。你想给 Web UI 加个自定义面板（比如展示你们内部系统的状态），本质上就是写一个前端插件，挂到 packages/client 的对应模块下，再通过 ACP 和 host 通信。也就是说，"改界面"和"写工具/写插件"走的是同一套可插拔哲学。

这给了团队一个清晰的演进路径：先用官方 Web UI 跑通业务，发现界面不够用时，基于开放协议自己补一块，而不是等官方。界面也是可插拔的------这句话值得在二次开发那篇再展开，但你可以先建立这个预期：DSH 没有"不可改的界面"，只有"你还没去改的界面"。

三十六、给团队的一份"多端协同规范"草案

把前面散落的纪律汇总成一份可落地的团队规范草稿，建议按需取用：

session_root 集中存：落到团队可访问的存储，别散落各人笔记本；会话真相集中，审计才可行。
Web UI 只本机用 ：禁止 --host 0.0.0.0，远程访问走 SSH 隧道或个人本机。
预设统一纳管：标准/代码/极简等预设团队对齐，别每人一套导致行为漂移。
Headless 用于自动化：CI、定时任务走 Headless，和交互式 Web UI 共享同一 root。
凭据不进仓库 ：.credentials.yaml 在 .gitignore，密钥走环境变量注入。
审批不无脑同意：Web UI 的审批弹窗认真对待，拒绝决策也写进日志可追溯。
多用户需求自建前端：如需多人 Web 访问，基于 ACP 自研带鉴权层，不裸暴露官方 UI。

这份草案不复杂，但每条都对应一个我们讲过的坑。团队落地 DSH，先立这几条，能少踩大半雷。

三十七、本篇一句话收尾

当你能在浏览器里和 Agent 协作、在脚本里让它跑、在别处召唤它，而所有上下文始终连贯------你就体会到了 DSH "多端协同"的真正含义：Agent 不再是某个 App 里的囚徒，而是你随时可达、上下文永不失联的协作者。

三十八、从一个细节看设计成熟度：默认打开 UI

顺带提一个容易被忽略、但很能说明团队取向的细节。早期版本你需要手动确认要不要开界面；而 2026-08 中旬的提交把行为改成了"默认打开就绪的 Web UI"。这看似一个小改动，背后的取向是：官方把"人能用起来"放在很高优先级------他们赌你大部分时候就是想要个界面，而不是在终端里敲。

这种"默认对人友好"的取向，和 DSH 整体"开发者预览、快速迭代"的节奏是一致的。作为使用者，你该享受这种友好，但也该保持清醒：预览版意味着界面形态会变，别把工作流过度绑定某个面板的某个按钮。把"会话真相在磁盘"这条立住，界面怎么变你都不慌。

三十九、给本篇的最后一个提醒

如果只能给你一条离开本篇的建议，那就是：先把 Web UI 用熟，再谈多端编排 。太多人一上来就想搞"多 Agent 编排、跨机协同"，结果连单端会话、轨迹面板、审批弹窗都没摸透，复杂玩法自然玩不转。Web UI 是离你最近、反馈最快的那层，把它的对话、@ 引用、轨迹、Job Panel 玩顺，你对 DSH 的整体心智模型就立起来了------之后无论是接 Headless、玩 ACP、还是编排多 Agent，都只是"在这个稳固模型上叠加新入口"而已。

结语

Web UI 与多端协同，是 DSH 把"Agent 运行时"从极客终端拉进普通人工作流的关键一跃。它用图形界面降低了协作门槛，又用共享会话内核和开放协议（ACP）保住了"可编排、可替换、可远程"的灵活性。对团队来说，这意味着 Agent 不再是一个人终端里的玩具，而是多端可达、上下文连贯的协作者。把入口交还给使用者，把真相留在磁盘上，这正是一个成熟 Agent 运行时该有的样子。

如果这篇帮你把 DSH 的 Web UI 跑起来、并看清了多端协同的门道，点个关注。实战系列持续更新（概念 / 教程 / 架构 / 插件 / 编码 / 框架对比 / 会话日志 / Headless / 自定义工具 / 模型适配 / Web 协同 / 安全沙箱 / 多 Agent / 二次开发）。你的 Agent 平时在哪用、怎么和团队协同，评论区聊聊。先把一个端用透，再去谈多端，这是把 DSH 用稳的最短路。下一篇，我们聊最该被认真对待的安全与沙箱。

本文基于 deepseek-ai/deepseek-harness 官方仓库结构（packages/host、packages/client）、官方文档、社区实测（atomicbot、jb51、ITBear 等）整理，截至 2026-08。dsh 处于开发者预览阶段，端口/命令以你安装版本为准。

DeepSeek Harness 实战：Web UI 与多端协同——你的 Agent 不止活在终端里