团队真正缺的是入口，还是边界？

搜「DeepSeek Harness 团队使用」「共用实例」「Web 部署」的人，多半不是想再看一遍 npx 命令，而是想解决：几个人怎么共用同一套 Agent、能不能挂一台机器给全组点开浏览器就用。这两件事听起来省事，却正好踩在 Harness 当前产品形态的边界上。

DeepSeek Harness 是开源 Agent 运行时（开发者预览），官方入口在 deepseek.com/harness/，源码在 github.com/deepseek-ai/deepseek-harness。常见本机体验是 npx @deepseek-ai/dsh web，Web UI 默认常见地址 http://127.0.0.1:3080，以终端输出为准。它擅长把模型、工具、技能、会话、沙箱等按插件组合；它不是给团队开箱即用的多租户 SaaS。

OpeClaw 站在另一条线上：本机个人 AI 助手工作流入口，把提示词、检查清单和可重复任务沉淀下来。团队若把「日常写作/SEO 流程」和「Agent 运行时试验」混成一台共享 Web，后面排错会一起糊掉。下面按 Web 部署、共用实例风险、团队约定，以及和 OpeClaw 的分工写清楚。

Web 部署：本机听环回，远程走隧道

个人本机：装好 Node 后跑官方一键体验即可。启动后确认监听地址是环回，不要为了「方便同事」随手改成对全网卡开放。公开第三方运维笔记写过：部分版本的 CLI 会拒绝把 host 绑到 0.0.0.0——即便你自己的版本还能绑，也不等于可以安全对公网开放。

人在公司外、实例在自己电脑或一台受控 VPS：优先用 SSH 本地转发。服务器侧 Harness 仍只听 127.0.0.1:3080（或你实际打印的端口）；你在自己笔记本上建隧道，浏览器访问本机转发端口。这样流量走 SSH，而不是把无登录的 Web 直接晾出去。

需要「固定 URL、全天在线」时，才考虑反向代理。代理本身不算登录：没有鉴权的 Nginx/Caddy 只是换了个更长的地址。团队场景应在代理层加 SSO / 基础认证 / 互认证书等，并且工作区目录、API Key 文件权限按最小授权收紧。预览版迭代快，具体参数以当前官方文档为准，本站不替代 README。

npx @deepseek-ai/dsh web
  • 本机：确认监听在 127.0.0.1，端口以终端为准（常见 3080）。
  • 远程：SSH -L 转发到本机，再开浏览器；不要默认公网映射 3080。
  • 长期服务：反向代理 + 真实鉴权；无鉴权代理不等于安全。
  • 预览版：破坏性变更可能发生，团队要约定升级窗口与回滚人。

共用实例为什么容易出事

社区讨论里反复提到一点：dsh web 对 API/UI 默认没有「账号密码」这一层；环回端口在共享多用户 Linux 主机上，往往是整台机器共享的，而不是「只有你这个 Unix 用户能碰」。实验室、跳板机、多人登录的开发机上，另一个本地账号有可能连到同一端口，进而碰到工作区路径、会话与以启动用户身份跑的 shell 能力。

所以「全组合用一台 Harness」和「每人各自启动一份」不是成本差一点点的问题。共用意味着：Key 落在哪、workspace 指到哪、谁能改文件、事故发生后日志归谁——全绑在同一进程身份上。排错时你会分不清是插件坏了，还是同事开了另一个会话改了目录。

若短期必须共用（演示机、评审机）：单独机器或单独系统账号、工作区只放演示数据、Key 用可撤销的短时额度、演示结束立刻停进程并清理。不要把生产仓库、个人邮件导出、未脱敏客户稿挂进这台演示实例的 workspace。

做法适合别误以为
每人本机 npx / 源码起一份日常开发与插件试验等于浪费，必须共用一台
SSH 隧道访问自己的实例出差、远程改自己的 Agent等于已对公网开放
一台演示机、短时共用评审、现场演示等于团队正式协作环境
无鉴权反向代理直出 3080几乎不适合等于「公司内网就安全」

安全边界以官方文档与当前版本行为为准；上表是团队落地时的分流，不是漏洞披露清单。

团队技巧：密钥、工作区与变更节奏

API Key 不要塞进群聊截图，也不要写进所有人都能读的共享盘明文文件。按人发放可撤销密钥；谁离职、谁泄露，就先废 Key 再查会话。Harness 能执行工具与命令时，Key 落盘目录的权限应默认只有启动用户可读。

工作区按任务拆，而不是「整盘 Documents 扔进去」。写作仓库、实验沙箱、只读资料可以分开挂；需要 shell 的任务单独目录，并约定：改生产配置、跑 rsync --delete、动机器人 token 必须人工确认。插件从哪装、能不能装来路不明的 dsh-plugin，写进内部 README，比事后对日志更省事。

预览版要接受兼容性断裂。团队约定：谁负责跟 GitHub Releases / Discussions、升级前谁备份配置、出问题谁有权回滚。周五下午全员升级、周一早上集体无法开工，是最常见的失败剧本。

  • 密钥：可撤销、可溯源；截图与明文共享盘默认禁止。
  • 工作区：演示 / 实验 / 生产稿分离；生产路径不进演示实例。
  • 插件：只装约定来源；未知包当不可信代码。
  • 升级：有窗口、有备份、有回滚人；不把预览版当零维护 SaaS。

和 OpeClaw 怎么自然分工

Harness 适合：试验 Agent 插件组合、回放会话轨迹、在本机 Web UI 里调试「模型 + 工具」链路。它回答的是「运行时怎么拼」。团队里真正天天重复的——SEO 初稿、去 AI 味、FAQ/内链核对、发布前清单——更适合落在 OpeClaw 这类本机工作流入口，而不是让全组挤进同一个无登录 Web 会话。

可串联：某人在 Harness 里试出一段可用的检查脚本或提示词结构，再把稳定下来的步骤沉淀进 OpeClaw 模板；日常发布仍走个人本机流程。需要装 OpeClaw 时，先看本站下载页核对发布状态，不要和「装不上 Harness」混成一件事。产品选型对照见 DeepSeek Harness 与 OpeClaw 怎么选。

合规未批的公司电脑：两边都可能触及本机文件与命令能力。未审批先别装；更别把未审批的共享实例挂在跳板机上「先用起来再说」。

团队上线前自检

下面这份清单不替代官方安全模型，只帮你在「已经想共用」时把关键决策摊开。任何一项答不上来，就先回到每人本机实例，而不是硬上共享 Web。

检查项通过标准不过就怎样
监听地址确认在环回，未对公网裸奔停进程，改隧道或加鉴权
鉴权有 SSH 隧道或代理层登录不要发群「直接打开 http://…」
工作区无生产密钥与未脱敏客户数据换目录或换演示机
Key可撤销、权限收紧、有负责人先废旧 Key 再继续
职责Harness=试验；OpeClaw=日常工作流别用共享 Web 当写作门户

需要核对 OpeClaw 安装入口时，打开下载页看当前发布状态；Harness 细节以官方仓库为准。

Harness 团队与 Web常见问题

DeepSeek Harness 的 Web UI 能直接挂到公网给团队用吗？

不建议。公开资料与社区讨论都指出 dsh web 默认无登录；监听在本机环回时，共享多用户主机上其他本地账号仍可能访问。更稳的做法是每人本机实例，或经 SSH 隧道 / 带鉴权的反向代理后再访问。

「共用实例」和「每人各跑一份」差在哪？

共用一份进程意味着工作区、会话轨迹、API Key 落盘位置和 shell 权限都绑在同一用户身份上；谁先连上 Web，谁就可能动到同一套文件与命令能力。分人分实例能把边界拆开，排错也更容易。

团队用 Harness，还要不要装 OpeClaw？

看任务。要改插件、看会话轨迹、在本机起 Agent Web UI 调试，用 Harness；要把写作、去 AI 味、发布前检查等日常流程做成可重复入口，更贴近 OpeClaw。两边可并存，不要把 Web UI 当成个人助手成品客户端。

远程同事怎么安全打开本机 3080？

常见做法是本机只听 127.0.0.1，再用 SSH 本地转发把端口映射到同事自己的电脑，而不是把 3080 暴露到 0.0.0.0 或公网。具体端口以终端打印为准。

把这套方法放进 OpeClaw 工作流

先核对 OpeClaw 当前下载状态，再把本文模板保存成自己的写作、改写和发布前检查流程。

查看 OpeClaw 下载状态 对照 Harness vs OpeClaw