帮助中心

可以。使用 Lexmount 后，网页加载和页面脚本在云端浏览器中执行，可以减轻这部分工作对本地 CPU、内存的压力，也省去自行部署浏览器服务器的步骤。 运行第一个云端浏览器任务。

你的 Agent 或业务程序通过远程连接操作浏览器。可以先迁移一条完整任务，确认页面操作和结果符合预期，再增加同时运行的任务数量。

Agent 或业务程序本身仍需要运行环境。如果希望关掉电脑后任务继续执行，也需要把控制程序放到持续在线的环境中。

主要调整浏览器的创建、连接和关闭，再逐步验证已有的页面操作。对于 Chromium，可以通过 Playwright 的 CDP 连接方式接入 Lexmount： 查看 Node.js 接入示例。

1. 创建一个 Lexmount Chromium 会话，取得连接地址。
2. 使用 chromium.connectOverCDP(session.connectUrl) 连接，将已有操作放到这个浏览器会话中执行。
3. 验证完整流程，并在成功、失败或取消后显式关闭云端会话。

建议先迁移一个任务，再扩大规模。CDP 与 Playwright 原生连接的能力存在差异，特殊 API、扩展和文件操作需要单独检查；云端下载的文件还需要通过下载接口取回。

可以同时运行多个云端浏览器。当前公开套餐的并发上限分别为 3、25、100 和 250 个浏览器会话，实际以价格页和当前项目显示为准。 查看并发套餐。

例如，有 500 个独立任务、项目支持 25 并发时，可以由你的程序同时启动最多 25 个会话，完成一项、释放名额后，再处理后面的任务。任务如何分配和接续，由你的程序或 Agent 安排。

选套餐时还要区分两个额度：并发数决定同一时间能运行多少个浏览器，Browser hours 是可使用的浏览器时长。 任务总量可以超过并发数；并发上限也不等于任务的提速倍数。

可以让每个并行任务使用独立的浏览器会话，由你的程序控制同时运行的数量，并在任务结束后释放名额。 查看会话创建与管理用法。

1. 将单任务流程整理为可重复调用的操作，每次调用创建自己的 Session。
2. 根据项目并发上限和已有活跃会话，限制本批任务的同时运行数量。
3. 每项任务记录结果，无论成功或失败都尝试关闭自己的会话，再接续后面的任务。

需要登录时，不同账号应使用各自的 Context；同一个 Context 的读写使用要依次进行。如果多个任务会修改网站里的同一条记录，还需要由程序协调操作顺序。

Browser hours 和并发名额是两个独立限制。有剩余时长，仍可能因为当前活跃会话已达到并发上限而无法新建浏览器。 查看当前活跃会话。

1. 确认查看的是同一个项目，核对并发上限和活跃会话。
2. 检查是否有任务已完成、但仍未关闭的会话，结束不再需要的会话。
3. 名额释放后重新创建。任务可以分批时，降低程序的并行数；确实需要更高同时运行量时，再选择并发上限更高的套餐。

例如，项目支持 25 并发，已有 25 个会话活跃时，即使 Browser hours 仍有剩余，也需要先释放名额。若活跃会话已低于上限但仍收到相同提示，请保留错误信息继续排查。

网站需要扫码、验证码或人工确认时，可以先由你完成登录，再让 Agent 在同一个云端浏览器中继续任务。配合持久化 Context，还可以把这次登录状态保存下来，供后续任务复用，减少反复登录和人工介入。 使用登录状态复用模板。

例如，你每天需要从一个已获授权的业务后台读取数据。首次运行时，你在实时页面完成登录，Agent 随后读取数据；任务结束后保存浏览器状态。第二天，Agent 用同一个 Context 创建新会话，先检查是否仍处于登录状态，再继续任务。

Session 是一次正在运行的浏览器会话，Context 用来保存可跨会话复用的 Cookie 和浏览器存储。这个流程需要使用 Chromium，并确认当前项目已开通持久化权限。

1. 创建一个持久化 Context，并在创建 Chromium Session 时以 readWrite 模式绑定它。保存 Context ID，后续任务需要复用同一个 Context。
2. 让 Agent 打开目标网站，然后暂停自动化操作并保持会话有效。打开该会话的实时页面（Remote View），由你完成扫码、验证码或其他登录步骤。
3. 确认页面已进入正确账号后，通知 Agent 继续操作这个 Session。人工操作与 Agent 操作依次进行，避免同时点击或输入。
4. 任务完成后，通过 SDK 或会话管理正常关闭云端 Session，让浏览器状态写回 Context。等待 Context 恢复可用，再启动下一次任务。
5. 下次创建 Chromium Session 时绑定相同的 Context ID，先检查目标网站是否仍已登录。状态有效就继续任务；如果登录过期或网站要求重新验证，再由你接管完成登录并恢复自动化。

这样，人工只需参与需要确认的步骤，Agent 可以继续完成后续网页操作；也不需要为了保留登录状态一直开着同一个浏览器会话。保存的是浏览器状态，下一次仍然需要创建新的 Session。

同一个 Context 不能同时供多个活跃会话读写，同一账号的任务应按顺序复用；不同账号使用各自的 Context。网站仍决定登录有效期和验证要求。当前 Browser 试验场不绑定持久化 Context，跨任务保存登录状态请按模板或 SDK 的 Context 用法接入。

可以在支持实时交互的 Chromium 会话中完成登录，再让 Agent 继续操作同一个会话。人工操作期间，Agent 或脚本需要配合等待，避免双方同时操作页面。 查看 Chromium 会话接入方法。

1. 创建 Chromium 会话，打开它的实时页面（Remote View）。
2. 暂停自动化操作并保持会话有效，由你完成网站登录或验证。
3. 确认登录完成后，让 Agent 在这个会话中继续任务。

如果希望下次任务继续复用登录状态，需要在创建会话时绑定持久化 Context，并在结束时正常关闭。当前 Browser 试验场不绑定持久化 Context，不能直接用它保存本次登录供下次任务使用；需要持久化时请按 SDK 的 Context 用法接入。

使用持久化 Context 后，可以在后续任务中复用已保存的登录状态，减少重复登录。这需要 Chromium 和当前项目的持久化权限。 了解登录状态保存方法。

1. 创建 Context，并在创建浏览器会话时绑定它。
2. 在该会话中完成登录和任务，结束后正常关闭，让状态写回 Context。
3. 等待 Context 恢复可用，再用它创建下一次会话。

Context 会保存 Cookie 和浏览器存储等状态。登录能否继续使用还取决于目标网站；登录过期或要求再次验证时，仍需重新登录。当前 Browser 试验场不自动保存可供下次复用的 Context。

为不同账号使用各自的 Context，为并行任务创建独立 Session，可以把浏览器状态和页面操作分开。 查看多账号 Context 用法。

例如，账号 A 的任务绑定 Context A，账号 B 的任务绑定 Context B。为 Context 使用清楚的名称或描述，运行任务前核对账号对应关系，结束后正常关闭会话以保存状态。

持久化需要 Chromium 和相应套餐权限。同一 Context 不能被多个活跃会话同时读写；同一账号的任务需要复用它时，应依次执行。目标网站自身的账号限制，以及多个任务对同一业务记录的修改，仍需要单独协调。

通常是某个活跃会话正在读写这个 Context。先检查占用它的会话，等它正常结束、Context 恢复可用后再使用。 检查占用 Context 的会话。

1. 根据占用提示检查对应会话，确认它是否还在执行任务。
2. 如果仍在工作，等待任务完成；如果已不再需要，由会话管理或程序正常关闭。
3. 等待 Context 显示为可用（available），再创建新会话。

如果需要独立副本，可以在 Context 离线且可用时通过 SDK 执行 fork。请勿对仍在使用的 Context 强制解锁；若占用会话已经结束但锁仍未释放，可联系支持人员继续排查。

先看浏览器当前停在哪个页面，再结合 Agent 或脚本的执行输出判断原因。会话仍在运行且实时画面可用时，可以从会话管理中打开查看。 查看会话运行情况。

1. 确认页面是否停在登录、验证、加载或某个操作步骤。
2. 对照执行输出、错误信息和最后一次操作，缩小排查范围。
3. 如果是已开启持久化回放的 Chromium 会话，结束后还可以在详情中查看成功生成的回放。

Moli 不提供持久化回放；Chromium 回放也可能仍在生成、生成失败或已超过保存期限。准备重试前，先确认上一轮操作是否已经生效，尤其是提交表单、创建记录等操作。

代码执行完成或连接断开后，云端浏览器会话可能仍然活跃，需要显式结束。在 Browser 试验场中，代码运行完成本身不会关闭会话；不再需要时应点击“停止”，并确认已结束。 检查仍在运行的会话。

在试验场运行： 不再需要查看或操作页面时，点击“停止”。

通过 SDK 运行： 将 session.close() 放在 finally 等清理路径中，任务成功、失败或取消后都尝试关闭。

程序意外退出： 登录后到会话管理中检查当前项目，关闭不再使用的会话，并确认它们已不再活跃。

如果关闭失败，先核对会话实际状态再重试。及时结束会话可以释放占用的并发名额。

把网页接入 RAG 知识库，首先需要拿到值得检索的正文。Lexmount WebFetch 可以从公开网页中提取正文、标题和来源网址，让你先验证内容质量，再接入自己的知识库，减少从零搭建网页抓取和解析流程的工作。 从网页转 JSON 模板开始。

例如，你想把产品文档、教程或行业文章接入问答助手。直接把整页 HTML 转成文本，可能会把导航、页脚和重复推荐一起带入知识库；只发普通请求，又可能漏掉由 JavaScript 加载的正文。可以先用 WebFetch 获取并提取页面内容，重点检查返回的 main_text 是否包含用户真正会提问的内容。

1. 选取几篇有代表性的公开页面，例如一篇长文章、一篇文档页和一篇动态加载内容的页面。先验证这些页面的提取效果，再接入更多网址。
2. 调用 POST /v1/extract，在 extract.url 中传入网页地址。读取 result.main_text 作为候选正文，同时保留 result.title 和 result.final_url 等来源信息；也可以先在 WebFetch 试验场运行同一个请求。
3. 入库前检查正文：关键段落是否完整、是否为空、是否混入导航或重复内容。如果结果异常，用 POST /v1/dom/dump 检查实际获取的页面及最终网址，确认是否遇到未加载的正文、跳转或登录页面。
4. 将检查后的正文按段落或章节分块，通过你的 RAG 流程生成向量并入库。给每个文本块保留来源网址和标题，方便回答时引用原文、排查错误以及后续更新。
5. 用几条真实问题试查，例如“这项功能有什么使用条件？”。对照检索出的文本和原网页，检查答案所需的内容是否已经提取并进入知识库，再逐步增加页面数量。

对于文档问答场景，一条完整流程可以是：公开文档网址 → WebFetch 提取正文 → 检查并分块 → 向量化与存储 → 检索并附上来源。下方的“网页转 JSON”模板可以作为提取这一步的起点，后续接入你已有的知识库。

WebFetch 负责网页获取与内容提取，分块、向量化、存储和检索由你的 RAG 系统处理。不同网站的提取效果会有差异，不能保证所有导航和广告都被去除；需要登录、点击或填写表单才能看到的内容，应先用 Cloud Browser 完成交互。

不需要先为每个网站编写解析规则。对于公开可访问的网页，向 WebFetch 提供网址，就可以尝试提取正文、标题等内容，省去自行搭建抓取和解析流程的工作。 用自己的网页试一下。

在试验场选择 POST /v1/extract，输入自己的网址，运行后查看 main_text 是否包含需要的正文。建议用几篇有代表性的页面检查效果，再接入批量任务。

不同页面的结构和可获取内容会影响结果，作者、发布时间等字段也可能缺失。如果需要检查实际获取的页面，可以切换到 POST /v1/dom/dump 查看 HTML。

可以先用 WebFetch 按需渲染公开页面，再尝试提取内容。有些网页会在打开后通过 JavaScript 加载正文，普通请求拿到的初始 HTML 里还没有这些内容。 查看动态页面抓取方法。

在试验场输入目标网址运行提取；如果内容仍然缺失，可以切换到 POST /v1/dom/dump，检查实际获取的 HTML。需要指定渲染引擎时，可以按文档通过 API 设置。

渲染结果仍受页面加载方式影响。如果必须先登录、点击按钮或填写表单才能看到内容，应使用云端浏览器完成交互。

拿到 HTML 后，仍可能因为目标正文尚未加载、页面发生跳转，或内容未能通过提取与校验而得到空结果。可以按下面的顺序排查： 按步骤排查提取问题。

1. 在试验场切换到 POST /v1/dom/dump，检查 HTML 是否包含目标正文，以及最终网址是否正确。
2. 如果正文已经存在，再查看提取响应中的错误信息。需要进一步定位时，可通过 API 开启 trace 查看处理步骤，或用 dom_id 对同一份页面快照重新提取。
3. 保留目标网址、request_id 和错误信息；问题仍未解决时，可将这些诊断信息提供给支持人员。分享前移除凭据和敏感页面内容。

先用一小批有代表性的真实任务试跑，查看实际浏览器用量，再结合预计任务量和需要的并发数选择套餐。 查看套餐与价格。

1. 选择能覆盖常见页面、登录和操作流程的任务，记录试跑前的 Browser hours 已用量。试跑期间尽量让项目只运行这批任务，避免混入其他任务的消耗。
2. 完成任务并关闭会话，待用量更新后比较消耗，同时记录失败和重试情况。
3. 根据预计任务规模估算所需时长，再检查套餐的并发上限和功能权限能否满足任务需要。

页面加载、登录等待和重试都会影响任务耗时，建议给预算留出余量。若使用自行配置的模型 API，也要把模型费用计入预算。

套餐内未用完的 Browser hours 会在周期结束时失效；单独购买的 WebFetch 余额可以保留到后续周期。价格和购买方式以所在地区页面为准。

WebFetch 加量包是为所选项目一次性购买的额外请求次数，费用与套餐分开，不是每月固定费用。请求先使用套餐内含次数，用完后再扣加量包余额；已购余额永久有效，不随套餐周期清零，切换到 Free 后仍可继续使用。 查看项目用量与加量包。

购买条件：当前为 Pro、Pro+ 或 Enterprise 的项目可以购买。Free 项目不能购买新的加量包，需要先升级到任一付费套餐。购买前请在“方案与用量”确认所选项目，完成支付且额度到账后，该项目即可使用新增次数。

价格规则：加量包价格按所选项目的当前套餐计算，具体规格和金额以购买页面的最新报价为准。切换套餐后，后续购买按新套餐定价；旧报价需要刷新并重新确认。

扣减顺序：每次成功完成的 WebFetch 调用优先消耗当前周期的套餐内含次数，内含次数用完后才消耗加量包余额。新周期有可用的内含次数时，仍先用内含次数，再用保留的加量余额。

余额有效期：未用完的加量次数永久有效，不会按月清零，也不随套餐周期重置，可以留到后续周期继续使用。付费套餐到期或降级、项目切回 Free 后，已有余额仍可使用；Free 只是不能购买新的加量包。

额度范围：加量包只增加 WebFetch 请求次数，不增加 Browser hours、浏览器并发数或套餐功能权限。套餐费用和加量包费用需要分别计算。

举例：一次购买 100,000 次，套餐内含次数用完后又从加量包使用了 24,000 次，剩余 76,000 次会保留到后续周期；即使项目切回 Free，也能继续使用这部分余额。

可以。你可以先在项目的免费额度内运行自己的真实任务，确认能否完成，再决定需要多少时长、并发和功能。 用自己的任务开始试跑。

当前公开 Free 套餐包含 1 Browser hour，支持最多 3 个并发浏览器，实际以当前项目显示为准。建议从一条完整流程开始，检查页面是否能打开、关键操作是否完成、结果是否符合预期，以及结束后会话是否正常关闭。

免费额度适合小规模验证。持久化 Context 等能力还需要对应的套餐权限；如果任务依赖这些功能，选套餐时也要检查能力范围。