DeepSeek Harness + WebMCP + Builder = Efficient Computer Use

[jo32]

中文 · English

中文

我在 DeepDeck（基于 DeepSeek Harness 的社区非官方桌面客户端） 中实现了一个支持 WebMCP 的浏览器。它可以调用网站已有的工具，也可以让 Agent 为没有 WebMCP 的网站构建工具。

用户描述任务目标，Agent 自己尝试网站操作、检查结果，并把验证过的操作写成可复用的 WebMCP 工具。后续任务可以调用这些工具，不必由用户逐步编写网站操作教程。工具的源码和版本保存在本地，可以查看、修改和重新验证。

WebMCP 是什么

WebMCP 是一项提议中的 Web API。网站可以将 JavaScript 功能或 HTML 表单声明为工具，提供名称、自然语言描述和结构化参数。Agent 据此了解可用功能、传入参数并调用工具，与用户共享当前网页和浏览器上下文。

例如，搜索工具的描述说明能搜索什么，参数结构说明需要提供哪些输入。模型可以直接使用这些信息。WebMCP 在网页中提供工具，可以与后端 MCP 集成配合使用。

与普通 Computer Use 的区别

	普通 Computer Use	WebMCP
理解功能	从截图或页面结构推断控件含义和操作流程	从工具名称、描述和参数结构了解可用功能
执行任务	观察页面、定位控件、点击或输入，再检查页面	选择工具、传入参数、读取执行结果
复用操作	通常仍沿界面逐步操作；复用需要另行保存脚本或流程	DeepDeck 将验证过的操作保存为工具，后续任务可以调用
时间与 token	多轮页面读取和模型决策会增加开销	工具覆盖的任务可以减少页面读取和模型决策，降低执行时间与 token 消耗

以搜索关键词为例，Computer Use 通常需要找到搜索框、输入、提交、重新读取页面，再提取结果。有对应的 WebMCP 工具时，Agent 可以调用搜索工具并读取返回结果，必要时再调用结果读取工具。

DeepDeck 使用浏览器操作来探索网站和验证工具，后续任务复用已保存的工具。工具未覆盖的操作仍由浏览器完成。

构建工具需要额外的探索和验证，工具描述本身也占用上下文。节省多少时间和 token，取决于网站、任务和工具设计，需要实际测量。

1. 调用网站已有的 WebMCP

打开网站后，DeepDeck 在 Site Agent → WebMCP → Website 下列出发现的工具。切到 Use 并描述任务，Agent 可以调用这些工具。

图中，DeepDeck 在 openai.com 发现了 search_openai。

2. 为没有 WebMCP 的网站构建工具

打开 WebMCP Builder，或把 Site Agent 切到 Builder，描述需要的功能。例如：

为这个网站构建 WebMCP，让我可以搜索、读取帖子、编辑并检查草稿。

Agent 在真实页面上尝试操作，检查结果，并将可行的流程写成工具。生成的代码保存在 DeepDeck 中，按网站加载，无需修改目标网站的源码或另行部署 MCP 服务。

以下是 X 上的构建和使用过程。

构建与验证。 Builder 列出生成的工具及验证结果，包括搜索、页面读取和草稿编辑。

查看工具。 这个示例生成了 23 个工具，包括读取账户状态、帖子、个人资料和搜索状态等。工具显示在 Built with DeepDeck 下，与网站提供的工具区分来源。启用后，再次访问会自动加载，也支持查看源码、禁用和回退版本。

调用工具。 切回 Use，输入 compose a hello world x post，Agent 调用 WebMCP 准备 Hello, world! 👋 草稿。图中没有发布帖子；填写草稿与提交发布是分开的操作。

这些工具保存了 Agent 已经验证过的网站操作，供后续任务复用。现有网站因此可以提供 Agent 可调用的功能。网站变化后，相应工具可能需要重新验证和修改。

对 Harness 浏览器插件的建议

社区已有一条 Support webMCP 的讨论。结合 DeepDeck 的实现，我建议浏览器类插件支持以下功能：

• 发现和调用当前页面的 WebMCP 工具，标明工具来源及所属页面。
• 允许 Agent 探索页面、生成工具，并通过实际调用检查结果。
• 按网站保存工具源码和版本，支持启停、回退和重新验证。

DeepDeck 的浏览器界面和 Host 服务通过 Cordis 插件接入，复用 Harness 的会话与 Composer。Electron 提供原生浏览器窗口和页面执行桥接。当前实现需要 DeepDeck 的桌面浏览器环境。

大家有哪些需要反复操作的网站流程？哪些工具发现、构建或版本管理功能，适合由 Harness 的浏览器类插件共用？

DeepDeck 源码 · 图文介绍 · 下载最新版（Apple Silicon / Intel Mac）

---

English

I built a WebMCP browser in DeepDeck, an unofficial community desktop client based on DeepSeek Harness. It can call tools a website already provides and let an agent build tools for sites without WebMCP.

The user describes a goal. The agent tries the website's controls, checks the results, and writes verified operations as reusable WebMCP tools. Later tasks can call those tools without the user writing step-by-step website instructions. Source code and versions are stored locally for inspection, modification, and verification.

What WebMCP does

WebMCP is a proposed web API. Websites can expose JavaScript functions or HTML forms as tools with names, natural-language descriptions, and structured parameters. Agents use this information to discover capabilities and call tools in the current page, sharing the user's browser context.

For example, a search tool describes what it searches and which inputs it accepts. The model can use that information directly. WebMCP provides tools within a web page and can work alongside backend MCP integrations.

Compared with ordinary Computer Use

	Ordinary Computer Use	WebMCP
Understanding a site	Infer controls and workflows from screenshots or page structure	Read tool names, descriptions, and input schemas
Executing a task	Observe, locate controls, click or type, then inspect the page	Select a tool, supply arguments, and read the result
Reusing operations	Usually repeat UI steps; reuse requires separately saving a script or workflow	DeepDeck saves verified operations as tools for later tasks
Time and tokens	Repeated page reads and model decisions add overhead	For tasks covered by tools, fewer page reads and model decisions can reduce execution time and token use

A keyword search through Computer Use usually involves finding the search field, typing, submitting, reading the new page, and extracting results. With suitable WebMCP tools, the agent can call a search tool and read its result, calling a separate results-reading tool if needed.

DeepDeck uses browser interaction to explore websites and verify tools. Later tasks reuse saved tools, with browser interaction available for anything they do not cover.

Building tools takes additional exploration and verification, and tool descriptions consume context. Time and token savings depend on the site, task, and tool design and need to be measured.

1. Call existing WebMCP tools

After opening a website, DeepDeck lists discovered tools under Site Agent → WebMCP → Website. Switch to Use and describe the task so the agent can call them.

This screenshot shows search_openai discovered on openai.com.

2. Build tools for a site without WebMCP

Open WebMCP Builder, or switch the Site Agent to Builder, and describe the capabilities you need. For example:

Build WebMCP tools for this site so I can search, read posts, and edit and check drafts.

The agent tries operations on the live page, checks their results, and implements working workflows as tools. Generated code is saved in DeepDeck and loaded for the matching site. This requires no changes to the target website's source code or a separate MCP server.

The following screenshots show the process on X.

Build and verify. Builder reports the tools it created and the workflows it checked, including search, page reading, and draft editing.

Inspect the tools. This example produces 23 tools, including account-state, post, profile, and search-state readers. They appear under Built with DeepDeck, separately from website-provided tools. Enabled tools load on later visits. You can inspect their source, disable them, or roll back a version.

Call the tools. Switch back to Use and ask compose a hello world x post. The agent calls WebMCP to prepare a Hello, world! 👋 draft. The screenshot does not show a published post; filling a draft and submitting it are separate operations.

These tools preserve website operations the agent has verified so later tasks can reuse them. Existing websites can gain agent-callable functionality. When a website changes, its tools may need to be checked and updated.

Suggestions for Harness browser plugins

There is an existing Support webMCP discussion. Based on the DeepDeck implementation, I suggest browser plugins support:

• Discovering and calling the current page's WebMCP tools, with their source and page identity available.
• Letting the agent explore a page, generate tools, and check results through actual calls.
• Saving source code and versions per site, with enable, disable, rollback, and verification controls.

DeepDeck's browser UI and Host services integrate through Cordis plugins and reuse Harness sessions and Composer. Electron provides native browser windows and the bridge for page execution. The current implementation requires DeepDeck's desktop browser environment.

Which website workflows do you repeat? Which discovery, tool-building, or version-management features would be useful to share across Harness browser plugins?

DeepDeck source · Illustrated guide · Download the latest release (Apple Silicon / Intel Mac)

[argszero]

这个方向很扎实——"探索 → 验证 → 保存 → 复用"的学习回路在当前 Harness 生态里确实是空白：Harness 自带的 web 能力是 web_search/web_fetch（provider 在 ctx.web 后面，schema 对模型保持稳定），仓库里没有浏览器 computer-use 面（E2B 是沙箱 POC、inspector 在 experimental），所以 DeepDeck 的浏览器 + 页面执行桥是真正的增量，跟 #4971 的 WebMCP 讨论能接上。

几个从 Harness 插件接缝角度的观察，供你取舍：

1. WebMCP 工具该挂在哪一层
ctx.tools.register() 是通用且 merge-extensible 的注册面（core/tools），工具按 scope 可见。最贴合 Harness 惯例的形状是：一个"浏览器源工具 provider"——按 origin 键控注册 WebMCP 工具，仅当浏览器上下文停留在该站点时把工具挂进当前 session 的 scope（per-site 惰性激活）。这跟 tool-web 把 provider 选择藏在服务后面是同一个模式：模型可见的 schema 稳定，换 provider/换浏览器桥不影响会话层。你截图里 "Website" 和 "Built with DeepDeck" 的分组很好——建议把这个来源区分也做成模型可见的（工具描述或命名空间前缀），避免模型把生成的工具当成站点原生能力。

2. 与 skill 系统的分工
Harness 已有 skill provider 体系（@deepseek-ai/dsh-skill-provider + tool-skill），形态是"程序性知识文本 + resourceBase"；WebMCP 工具是"结构化参数 + 可执行实现"——两者互补而不是竞争。文本流程适合存 skill，可调用能力适合存 WebMCP。值得在 Harness 侧共用的一个面：让 WebMCP 目录也能被 tool-skill 这类通用读取工具发现（或反过来 skill 能引用 WebMCP 工具），这样"经验"不锁死在 DeepDeck 里。

3. 验证证据要可重放
你说"保存的是可查看、可执行、可再次验证的操作经验"——这是最有价值的一句。建议把每次验证运行的证据（断言结果/页面状态）作为结构化记录存下来，站点变更后的"重新验证"就变成重放 + diff，而不是重新探索。Harness 的 durable session 事件可以做这个载体，DeepDeck 侧也可以先自存。

4. 上下文成本
工具会累积，且工具描述本身占上下文。per-site 惰性激活能压住大部分成本；另外给工具描述设字节上限、让模型先"发现"再"调用"（两段式）都比全量注入省 token。你的表里"复用省 token"的前提是激活面收得住。

5. 插件形态
DeepDeck 已经是 Cordis 插件接入——如果把这个"浏览器源工具 provider + WebMCP 目录"抽成可 mount 的独立插件（dsh.bundle 声明），非 DeepDeck 宿主也能挂，会是最好的生态落点。上游 Issues/PRs 通道关闭，插件 + Discussion 是当前唯一贡献通道，你这个方向恰好是插件能完整承载的。

想看到你把验证回路再往前推一步——尤其是"网站改版后自动发现工具失效并触发重新验证"的检测，那会是 WebMCP 生命周期里最难的环节，也是最有复用价值的部分。