面向 AI 代理的浏览器，目标并不是让页面“看起来更像 Chrome”，而是让模型能够稳定、快速、低成本地理解页面并执行操作。Kitesurf 这次更新聚焦三个直接影响代理执行效率的方向：加入 WebMCP 支持、改善 DOM 性能，以及提供基于终端的渲染方式。与此同时，它已经通过超过 73 万项 Web Platform 子测试，为处理复杂网站提供了更扎实的兼容性基础。
浏览器代理需要的不是更多像素，而是更清晰的操作面
传统浏览器围绕人类设计：页面通过颜色、布局、动画和视觉层级传递信息。AI 代理面对的任务则不同，它通常需要回答三个问题：
- 当前页面有哪些可操作对象？
- 哪个对象对应任务目标？
- 操作之后，页面状态发生了什么变化？
如果代理每一步都读取完整 DOM、样式树和截图，不仅上下文迅速膨胀，还可能被隐藏节点、重复导航、动态组件和装饰性元素干扰。
Kitesurf 的 DOM 性能改进因此不仅是浏览器跑分问题。对于代理工作流，它可能直接影响一次任务中的观察延迟、序列化成本以及模型需要处理的 token 数量。复杂站点里的节点越多，这类优化越重要。
终端渲染则提供了另一条路径：把页面压缩成更接近结构化文本的表示，让开发者和代理快速看到标题、链接、按钮、输入框及其状态。它不应被理解为完整视觉渲染的替代品，但很适合调试导航、表单填写和多步工作流。
WebMCP 让网站能力更接近“可调用工具”
WebMCP 支持值得关注，因为浏览器代理长期依赖一种脆弱的交互方式：在 DOM 中猜测按钮含义，再通过选择器或坐标完成点击。页面稍微改版，自动化流程就可能失效。
面向代理的机器可读接口可以把网站能力表达为更稳定的工具契约。例如，与其让模型寻找“查询订单”按钮，站点可以暴露一个语义明确的操作：
{
"name": "lookup_order",
"description": "Look up an order owned by the signed-in user",
"input": {
"order_id": "string"
}
}
这段 JSON 只是用于说明设计思路，并非 Kitesurf 的官方 WebMCP API。实际字段、发现方式和权限模型应以运行环境采用的 WebMCP 规范为准。
这种能力并不会消除网页交互。代理仍然需要处理登录、授权、没有工具接口的页面以及视觉任务，但它可以优先使用显式工具，将 DOM 点击作为回退路径。比较稳妥的执行顺序是：
- 检查页面是否提供可用的机器接口；
- 验证工具名称、参数和权限范围；
- 调用工具并保存结构化结果；
- 只有在没有对应工具时，才读取 DOM 并执行点击或输入；
- 对支付、删除和提交等高风险操作增加人工确认。
动手构建一个最小终端页面视图
Kitesurf 的具体调用接口没有出现在摘要中，因此下面不虚构它的 SDK。我们可以先用一个可运行的小工具体验终端渲染的核心思路：过滤脚本和样式，只输出代理通常关心的标题、链接、按钮与表单控件。
将下面内容保存为 terminal_view.py：
#!/usr/bin/env python3
from html.parser import HTMLParser
from pathlib import Path
import sys
INTERACTIVE = {"a", "button", "input", "select", "textarea"}
IGNORED = {"script", "style", "svg", "noscript"}
class TerminalView(HTMLParser):
def __init__(self):
super().__init__()
self.hidden_depth = 0
self.stack = []
self.items = []
self.title = []
self.in_title = False
def handle_starttag(self, tag, attrs):
attrs = dict(attrs)
if tag in IGNORED:
self.hidden_depth += 1
return
if self.hidden_depth:
return
if tag == "title":
self.in_title = True
if tag in INTERACTIVE:
item = {
"tag": tag,
"label": attrs.get("aria-label", ""),
"href": attrs.get("href", ""),
"name": attrs.get("name", ""),
"type": attrs.get("type", ""),
"text": [],
}
self.stack.append(item)
def handle_endtag(self, tag):
if tag in IGNORED:
self.hidden_depth = max(0, self.hidden_depth - 1)
return
if self.hidden_depth:
return
if tag == "title":
self.in_title = False
if self.stack and self.stack[-1]["tag"] == tag:
self.items.append(self.stack.pop())
def handle_data(self, data):
if self.hidden_depth:
return
text = " ".join(data.split())
if not text:
return
if self.in_title:
self.title.append(text)
if self.stack:
self.stack[-1]["text"].append(text)
if len(sys.argv) != 2:
raise SystemExit("Usage: python terminal_view.py page.html")
parser = TerminalView()
parser.feed(Path(sys.argv[1]).read_text(encoding="utf-8"))
print(f"PAGE: {' '.join(parser.title) or '(untitled)'}")
for index, item in enumerate(parser.items, start=1):
text = " ".join(item["text"])
label = item["label"] or text or item["name"] or "(unlabeled)"
details = []
if item["type"]:
details.append(f"type={item['type']}")
if item["href"]:
details.append(f"href={item['href']}")
suffix = f" [{' '.join(details)}]" if details else ""
print(f"{index:02d}. <{item['tag']}> {label}{suffix}")
再创建一个测试页面并运行：
cat > page.html <<'HTML'
<!doctype html>
<html lang="zh-CN">
<head><title>订单查询</title></head>
<body>
<nav><a href="/orders">我的订单</a></nav>
<main>
<label>订单号 <input name="order_id" type="text"></label>
<button aria-label="查询订单">查询</button>
</main>
<script>console.log('ignored')</script>
</body>
</html>
HTML
python3 terminal_view.py page.html
预期会得到类似结果：
PAGE: 订单查询
01. <a> 我的订单 [href=/orders]
02. <input> order_id [type=text]
03. <button> 查询订单
这个示例没有执行 JavaScript，也没有覆盖 iframe、Shadow DOM、可访问性树和动态状态，因此不能代替真正的浏览器运行时。它展示的是一种值得保留的工程原则：先给代理最小且语义明确的页面表示，需要时再请求完整 DOM、截图或视觉模型。
73 万项子测试意味着什么
通过超过 73 万项 Web Platform 子测试，是一个重要的兼容性信号。代理浏览器面对的并不只是静态 HTML，还包括导航、事件、表单、DOM API、网络行为以及现代 Web 平台的大量边界条件。更广的测试覆盖可以减少“页面在人类浏览器正常、在代理浏览器里却行为不同”的情况。
不过，测试数量不能简单等同于与主流浏览器完全一致。评估时仍应使用自己的目标网站和真实任务，尤其关注：
- 单页应用中的客户端路由和异步更新；
- iframe、Shadow DOM 与自定义元素；
- 文件上传、下载和弹窗；
- Cookie、会话、OAuth 与多因素认证；
- Canvas、复杂图表及其他视觉信息；
- 反自动化机制和站点服务条款。
接入代理工作流时的检查清单
如果准备评估 Kitesurf，可以从一组可重复的任务开始，而不是只测试首页是否能打开：
- 选择 10 至 20 条真实业务路径，记录成功率和完成时间；
- 分别测量页面加载、DOM 提取、模型决策和操作执行的耗时；
- 比较完整 DOM、终端表示和截图三种观察方式的 token 成本；
- 优先使用 WebMCP 暴露的语义化能力，并保留 DOM 回退方案；
- 对工具调用设置域名、参数、权限和重试限制；
- 为提交订单、发送消息、删除数据等不可逆操作设置确认门；
- 保存每一步观察与操作日志，以便复现失败。
Kitesurf 的这轮更新表明，代理浏览器正在从“能打开网页”走向“能高效理解并可靠操作网页”。WebMCP 提供更明确的能力边界，DOM 优化降低观察成本，终端渲染改善调试和机器读取体验。真正投入生产时，关键仍然是用真实站点验证兼容性，并把权限、审计与失败回退作为浏览器能力的一部分来设计。