SeimiRender V1.2.0：用 HAR 记录 AI 无屏浏览器的完整网络过程

2026-08-24 37 预计阅读时间: 1 分钟
来源: oschina.net AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：8 分钟

AI Agent 使用无屏浏览器完成搜索、登录、表单填写和网页操作时，真正难排查的往往不是页面截图，而是页面背后的网络行为：哪个请求失败了、接口返回了什么、响应耗时为何突然升高，以及某个资源是否被重定向。SeimiRender V1.2.0 新增 CDP 网络录制能力，可以在渲染过程中记录 HTTP 请求和响应，并导出标准 HAR 1.2 文件，让浏览器自动化调试进入更可观测的阶段。

HAR 记录了什么

这次功能面向渲染期间的网络流量，记录内容包括：

  • 请求和响应的 headers
  • HTTP 状态码
  • 响应体
  • 请求耗时
  • 全量 HTTP 请求/响应信息

生成的文件遵循 HAR 1.2 标准，可以直接导入 Chrome DevTools、Charles 等工具。相比只保存最终 HTML 或截图，HAR 能保留页面加载过程中的证据链：主文档如何返回、脚本加载是否失败、接口是否返回 401、静态资源是否发生重试或重定向。

这对 AI 浏览器尤其有价值。Agent 的一次任务可能经过多个页面、多个 API 和复杂的前端状态转换，最终结果不正确时，HAR 可以帮助开发者判断问题发生在导航、接口、鉴权还是页面脚本层。

启动时打开 CDP 端口

CDP 网络录制需要以 --remote-debugging-port 启动 SeimiRender。下面是一个按常见部署方式编写的示例命令；如果实际二进制名称或目标参数不同，只需要替换对应部分：

./seimirender \
  --remote-debugging-port=9222 \
  --url="https://example.com" \
  --output-har="./artifacts/example.har"

其中，--remote-debugging-port=9222 是启用 CDP 能力的关键。生产环境中不要把调试端口直接暴露到公网，建议只绑定在本机或受限网络接口，并通过容器网络、SSH 隧道或访问控制来保护它。

如果系统通过 MCP 驱动浏览器，MCP 侧同步提供了 get_har 工具。一个典型的调用流程可以抽象为：

{
  "name": "get_har",
  "arguments": {
    "session_id": "session-123"
  }
}

这里的 session_id 和参数结构应以当前 MCP 服务的工具定义为准。调用成功后，客户端可以把返回的 HAR 内容写入文件，再交给浏览器开发工具分析。

用 Python 快速检查 HAR

HAR 是 JSON 文件，适合在导入 DevTools 之前做自动化检查。例如，下面的脚本会统计请求数量、失败响应和最慢的请求，适合放进 Agent 任务的诊断流程：

#!/usr/bin/env python3
import json
import sys
from pathlib import Path


def inspect_har(filename: str) -> None:
    data = json.loads(Path(filename).read_text(encoding="utf-8"))
    log = data.get("log", {})
    entries = log.get("entries", [])

    failures = []
    for entry in entries:
        response = entry.get("response", {})
        status = response.get("status", 0)
        if status >= 400 or status == 0:
            failures.append((status, entry.get("request", {}).get("url", "")))

    slowest = sorted(
        entries,
        key=lambda item: item.get("time", 0),
        reverse=True,
    )[:5]

    print(f"HAR version: {log.get('version', 'unknown')}")
    print(f"Total requests: {len(entries)}")
    print(f"Failed responses: {len(failures)}")

    if failures:
        print("\\nFailures:")
        for status, url in failures:
            print(f"  {status} {url}")

    print("\\nSlowest requests:")
    for entry in slowest:
        request = entry.get("request", {})
        print(f"  {entry.get('time', 0):8.1f} ms  {request.get('method', '')} {request.get('url', '')}")


if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit(f"Usage: {sys.argv[0]} path/to/trace.har")
    inspect_har(sys.argv[1])

运行方式：

python inspect_har.py ./artifacts/example.har

这个检查器不依赖第三方库，可以作为 CI 任务的一部分。例如，可以对关键任务设置规则：登录接口不能返回 401，核心 API 不能出现 5xx，最慢请求不能超过预设阈值。具体阈值需要结合页面和网络环境确定，不应把一次偶发的慢请求直接视为系统故障。

从“结果不对”定位到具体请求

一套实用的排查流程可以这样组织：

  1. 让 Agent 在独立会话中执行任务，并确保启动参数包含 --remote-debugging-port。
  2. 任务结束后通过 get_har 或对应的 HAR 导出能力取得网络记录。
  3. 先按状态码筛选 4xx、5xx 和状态码为零的条目。
  4. 再检查重定向链、鉴权 headers、请求体和响应体。
  5. 对耗时排序，确认瓶颈是 DNS、接口服务、资源下载还是页面脚本等待。
  6. 将 HAR 导入 Chrome DevTools 或 Charles，结合时间线复现问题。

需要注意的是，HAR 不是只读的“最终结果快照”。它记录了大量可能包含业务数据的请求和响应，因此应当和日志、截图、浏览器存储一样纳入敏感信息管理。尤其要关注 Cookie、Authorization、表单字段、用户输入和响应体中的个人数据。共享 HAR 前应进行脱敏，生产环境也应限制文件保存周期和访问权限。

此外，全量记录会增加存储和处理成本。批量运行 Agent 时，建议按任务 ID 保存文件，控制单次任务的 HAR 大小，并在任务成功时只保留摘要、任务失败时保留完整记录。这样既能支持故障分析，也不会让诊断数据无限增长。

适合怎样采用

SeimiRender V1.2.0 的 HAR 能力适合三类场景：开发阶段分析网页兼容性，测试阶段验证关键接口和资源加载，生产阶段诊断偶发的 Agent 失败。启用它的前提是正确开启远程调试端口，并确认 MCP 客户端能够调用 get_har 或使用等价的导出方式。

落地时可以先从失败任务采集完整 HAR，再逐步增加自动化规则。对成功任务保留请求数量、错误数量、总耗时和最慢请求等摘要；对失败任务保存原始 HAR，并配合脱敏和权限控制。这样，网络录制就不只是一个调试开关，而是 AI 浏览器可观测性链路中的一部分。

# AI # 全栈 # 前端 # 开源 # 开源中国

相关推荐