如何用 DeepSeek Harness 控制浏览器

DeepSeek Harness 可以控制真实浏览器，但本地 DSH Web UI 本身不是浏览器控制器。它需要插件与浏览器运行时。Tabbit 发布的开源 DSH bundle 会加载 tabbit-browser Skill，再由 tabbit-cli 操作本机 Tabbit Browser。

一位 r/DeepSeek 用户写道：“I have created so many plugins, that's crazy”，随后列出了 Git、计划、worktree、通知和界面插件。浏览器控制也符合这个思路：为 agent 增加环境能力，而不是重写 agent loop。查看 Reddit 原评论。如果你想先理解大类，可以从浏览器自动化与只回答问题的助手之间的区别开始。

重点结论

• DeepSeek Harness 是 DeepSeek AI 推出的开源开发者预览版 agent harness，核心设计是“everything is a plugin”。

• Tabbit 插件提供一个 DSH Skill。Skill 调用本机 tabbit-cli，再连接 Tabbit 的 Browser-owned Runtime Service。

• 当前要求是稳定版 Tabbit Browser 1.9.0+，并与 DSH shell 位于同一台主机。

• 命名 task space 会隔离不同任务的页面、状态与回执；同一非无痕配置文件中的现有登录态可以复用。

• 这是能力接入，不是权限绕过。优先 API、先做只读任务、不可逆操作需确认，遇到验证码或网站限制应停止。

浏览器控制链路

公式可以写成：

DSH agent + Tabbit Skill + tabbit-cli + 本地 Tabbit runtime = 浏览器操作

它把 agent harness 与浏览器环境连接起来，但不会让远程 shell 自动变成本地浏览器智能体。

DeepSeek Harness 是什么

DeepSeek 官方发布页将 harness 定义为帮助模型理解环境、使用工具并在真实任务中持续工作的层。DSH 基于 Cordis，模型、工具、skills、sessions、sandboxes、storage、loops、scheduling 和 UI 都能作为插件挂载。

官方快速启动命令是：

npx @deepseek-ai/dsh web

它启动目前文档所示的 http://127.0.0.1:3080 本地界面。需要区分三件事：浏览器中的 DSH 界面、公开网页检索工具、以及能导航、点击、填写并验证实时页面的浏览器控制。Tabbit bundle 解决第三种需求，因此属于浏览器智能体能力层，DSH 仍负责调度。

DSH 仍处于 developer preview。官方仓库明确说明可能发生破坏兼容性的变化。一位早期用户也评价 “DSH is still pretty rough in a lot of places”。后者是个人观点，preview 状态则是官方事实。查看原评论。

Tabbit 插件如何工作

公开的 Tabbit-Browser/dsh-plugin 仓库包含 Cordis bundle、安装工具和完整 tabbit-browser Skill。安装后可用 skill({ name: "tabbit-browser" }) 或 /tabbit-browser 加载。

首次任务会检查国际稳定版 Tabbit 或国内稳定版 Tabbit Browser，至少一个达到 1.9.0。开发版会被忽略。若缺失或版本过低，DSH 会创建后台下载任务，按地区选择官方安装包并保存至 Downloads，但不会替用户运行 .dmg 或 .exe。

如果浏览器满足要求但运行时缺失，Skill 会要求重启一次 Tabbit，而不会静默切换 Chrome、云浏览器、原始 CDP 或其他后端。准备完成后，tabbit-cli 在命名 task space 中执行代码；相同任务名可以复用页面、JavaScript globals、回执与当前浏览器代际的登录状态。这让它更接近持续工作的浏览器自动化智能体，而不是互不相关的网页抓取。

在本次提供的源码上，npm test 的 15 项单元测试全部通过，npm pack --dry-run 也成功生成预期文件清单。这验证的是该提交的代码与打包逻辑，不代表所有网站或 DSH 版本都已端到端测试。

安装 Tabbit 的 DSH 浏览器插件

先按 DSH 官方文档准备 Node.js 与依赖，然后执行：

dsh --version
dsh plugin --profile web add github:Tabbit-Browser/dsh-plugin
dsh web

若 DSH 已运行，应重启并刷新页面。Tabbit 1.9.0+ 稳定版需要与 DSH shell 位于同一台机器。若提示 runtime 未运行，重启 Tabbit 一次再重试。

Windows 的受限 DSH sandbox 可能无法访问 named pipe。插件只有在确认浏览器、launcher 与 runtime 进程存在但仍收到 BROWSER_RUNTIME_UNAVAILABLE 时，才建议 Full Permission；它不应是默认起点。

第一次可以使用边界明确的提示词：

使用 tabbit-browser skill。打开这个项目的公开 GitHub 仓库，阅读 README，
用表格返回安装命令、最低 Tabbit 版本和已知限制。
不要登录、提交表单，也不要关闭我已有的标签页。

能做什么，不能做什么

Skill 通过 CLI 提供 Playwright 风格流程，可导航页面、检查可见状态、点击与填写、处理多页面、提取结构化数据、截图、下载并验证结果。推荐循环是：

检查相关状态 → 执行一组连贯操作 → 验证结果

这能支持AI 智能体浏览器自动化中的公开资料研究、仪表盘检查和受监督的重复流程，但存在明确限制：

• DSH 必须能访问浏览器主机的 Runtime Service，远程 E2B 或容器不会自动连接回笔记本。

• 开发版 Tabbit 不在检测范围内；插件也不会自行启动 runtime。

• 安装器只下载安装包，不会代替用户安装。

• 真实会话仍会遇到登录过期、页面改版、权限、验证码与网站政策。

• task/profile 中的持久状态既方便，也会放大误操作影响。

如果还不熟悉产品，可先看什么是 Tabbit Browser和Tabbit AI 浏览器完整介绍。

一个低风险实践方式

可以先让 DSH 查看三个公开项目页，收集最新版本号与系统要求，并返回带来源的表格。DSH 负责目标、模型对话、权限模式与最终答案；Tabbit Skill 准备浏览器环境；tabbit-cli 在同一 task space 打开来源并逐行核对。

一位讨论日常网页与 ERP agent 的社区成员得到的建议是：优先 API，把浏览器自动化作为工具，并在 submit、pay、delete 前设置人工批准。查看 Reddit 原讨论。研究任务应保持只读并返回来源；表单可以先填写，但在提交前停止。这也是面向研究者的 AI 浏览器更稳妥的用法。

按任务选择浏览器后端

dsh-better-browser 公开仓库记录的是另一种架构：DSH 适配 Kimi WebBridge。选择应依据要操作的浏览器环境，而不是工具数量。

一位社区用户认为真实机器与真实浏览器会话更可靠，同时也指出它不易扩展且增加硬件维护成本。查看原评论。这是个人经验，不是绕过检测的许可。出现验证码或网站拒绝自动化时，应把控制权交回用户。

安全边界与选择建议

信任模型包含四层：DSH 权限、插件范围、浏览器会话、网站动作。先用只读或工作区权限，只给任务所需的最小权限；不要在提示词中放密码、API key、支付资料或无关私密标签页；不要提取 cookie 或浏览器存储；发送消息、上传敏感文件、改权限、购买和删除前必须再次确认。

生产流程应保留 prompt、来源 URL、动作、结果与确认记录，并先用可恢复的 sandbox 或测试账户。所有智能体 AI 浏览器都适用这些规则：会话上下文越有用，权限越需要克制。

如果你已经在与 DSH 同机的环境中使用 Tabbit，需要真实浏览器而非公开网页检索，并能监督操作，这个插件值得尝试。如果 agent 只运行在远程容器、今天就需要生产级稳定接口，或任务已有可靠直接集成，应等待或选择其他后端。

实际下一步很小：从公开仓库安装 bundle，用低风险独立 profile，让 DSH 只读一个公开页面并返回带来源的结果。当环境检查、浏览器动作和验证都清晰可见时，再逐个扩展流程。这才是AI 浏览器有价值的方向：不是无限制点击，而是从意图到可核验动作的清晰链路。

Secholar.L

Tabbit 增长与内容

Secholar.L 专注 AI 浏览器与 Agent 工作流的实操写作,基于真实调研对比工具,引用可验证的一手来源。