实用说明：Hyperbrowser AI——专为智能体设计的托管浏览器层

可将此内容作为《Hyperbrowser AI：为需要真实网页的智能体提供的托管浏览器层》中理念面向操作员的简化版本：清晰的阶段划分、有序的代码模块以及可在交接时保留的恢复说明。 将“概览”阶段视为可度量的界面使用效果最佳。在扩大范围之前，先记录一份理想的操作日志、一个故障案例以及回滚说明。 将配置信息置于应用程序代码之外。环境文件、密钥存储和功能开关应集中存放于一个位置，以便操作员无需查看整个架构即可进行审计。

render pages
manage sessions
follow links
handle consent and login state
extract data
retry failures
capture evidence
close every browser cleanly

Hyperbrowser是一个平台，而非单一的浏览器智能体

对于属于平台阶段的 Hyperbrowser，应在修改代码之前明确输入参数、该步骤的负责人以及退出标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的功能。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接配置并不等同于业务功能的完整性。

Web API

在 Web API 阶段，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。相比冗长的脚本，更应采用小型且可测试的单元。当某个步骤失败时，故障原因应能指向单一责任点，而非复杂的流程链。对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。

Hyperbrowser MCP

在 Hyperbrowser MCP 阶段中，修改代码之前需先明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 应将此阶段视为输入与已验证输出之间的契约。为相关成果命名，设定成功检测标准，并拒绝默许的半完成状态。 在网关处进行身份验证，在数据层面重新授权。仅凭承载令牌并不足以界定租户边界。 在 Hyperbrowser MCP 阶段中，修改代码之前需先明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，以便操作人员无需查看整个系统结构即可进行审计。

HyperAgent

在处理 HyperAgent 阶段时，首先需明确相关约定：所需的输入参数、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 同时记录正常流程与异常恢复路径。重试机制、人工审核环节以及错误消息处理都是产品功能的一部分，而非后续需要补充的内容。 在调整提示词之前，先使用固定的问题集来评估检索效果。仅仅更换提示词很难解决检索能力不足的问题。

浏览器代理后端

在处理浏览器-代理后端阶段时，首先需明确相关约定：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 优先选择小型且可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 在耗时的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。

配置文件

在处理“配置文件”阶段时，首先需明确相关契约：所需输入、成功标志以及部分失败时的处理方式。这份清单能确保后续的代码修改始终符合约定。 将此阶段视为输入与验证后输出之间的契约。为相关成果命名，定义成功检测标准，并杜绝无声的半完成状态。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。 在处理“配置文件”阶段时，首先需明确相关契约：所需输入、成功标志以及部分失败时的处理方式。这份清单能确保后续的代码修改始终符合约定。 将配置信息置于应用程序代码之外。环境文件、密钥存储及功能开关应集中存放于一个位置，以便操作员无需查看整个流程即可进行审计。

最实用的模式是逐步升级

最实用的流程设计应在被视为可度量的结构时才能发挥最佳效果。在扩大范围之前，先记录一个成功的用例、一个失败案例以及回滚说明。同时将正常流程与恢复流程记录下来。重试机制、人工审核环节以及错误处理都是产品本身的一部分，而非后续需要补充的内容。要保持图表状态简洁且具有类型定义，嵌套的数据结构会掩盖具体是哪个节点设置了哪个字段的信息，还会在流程中断后导致无法继续执行。

Known URL
  -> Fetch or scrape

Several linked pages
  -> Bounded crawl

Known output contract
  -> Structured extraction

One predictable interaction
  -> HyperAgent granular action

Unknown multi-step stateful workflow
  -> Browser agent

实用的定价与区域管理流程

将定价与区域配置的工作流程视为可度量的对象来处理，效果最佳。在扩大范围之前，先记录一份优秀的配置示例、一个故障案例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某个步骤出现故障时，故障应能指向具体的责任主体，而非复杂的流程链。 保持图表状态简洁且具有类型定义。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在流程中断后导致无法继续执行。

{
  "vendor": "Example Cloud",
  "plan": "Business",
  "monthly_price": 99,
  "currency": "USD",
  "supported_regions": ["US", "EU"],
  "usage_limit": "10,000 requests/month",
  "source_urls": ["https://example.com/pricing"]
}

第一步：通过MCP连接Hyperbrowser

将“第一步：连接 Hyperbrowser”阶段视为可度量的工作面，效果最佳。在扩大范围之前，需记录一份理想状态示例、一个失败案例以及回滚说明。 将该阶段视为输入与已验证输出之间的契约。为相关成果命名，明确成功标准，杜绝默许的半完成状态。 使用具有严格结构定义且带有明确副作用标签的工具。主机需要在自动批准之前知道哪些调用会改变系统状态。 将“第一步：连接 Hyperbrowser”阶段视为可度量的工作面，效果最佳。在扩大范围之前，需记录一份理想状态示例、一个失败案例以及回滚说明。 将配置信息置于应用程序代码之外。环境文件、密钥存储和功能开关应集中存放，以便操作人员无需查看整个系统结构即可进行审计。

{
  "mcpServers": {
    "hyperbrowser": {
      "command": "npx",
      "args": ["-y", "hyperbrowser-mcp"],
      "env": {
        "HYPERBROWSER_API_KEY": "${HYPERBROWSER_API_KEY}"
      }
    }
  }
}

第二步：查找或获取已知证据

在第二步的“发现”或“阶段化”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的内容。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的逻辑连接并不等同于业务功能的完整性。

第三步：转换为固定架构

在第三步“提取到阶段”中，修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。相比冗长的脚本，更应采用小型且可测试的单元。当某一步骤失败时，故障原因应能指向单一责任主体，而非复杂的流程链。对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的逻辑连接并不等同于业务功能的完整性。

第四步：仅在需要状态时才升级处理

在仅用于升级的第四阶段中，应在修改代码之前明确输入参数、该阶段的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该阶段，而无需猜测隐藏状态。 将此阶段视为输入与已验证输出之间的契约。为相关成果命名，定义成功检测标准，并拒绝默许的半完成状态。 对于涉及资金支出或更改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务上的完整性。 在仅用于升级的第四阶段中，应在修改代码之前明确输入参数、该阶段的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该阶段，而无需猜测隐藏状态。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个操作人员可以审核的位置，无需阅读整个系统结构。

open the pricing page
select Germany
wait for the price table to update
extract the Business plan

第5步：仅在需要保持连续性时附加配置文件

在执行第5步“附加阶段”时，首先写下相关契约：所需的输入参数、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都属于产品功能的一部分，而非后续的优化工作。 在成本较高的步骤之后设置检查点。当操作员重新尝试某个后续节点时，恢复流程不应再次调用相同的LLM服务。

第6步：返回证据，而不仅仅是答案

在执行第6步“提供证据”阶段时，首先写下合同细节：所需的输入参数、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 建议使用小型、可测试的单元，而非庞大的脚本。当某一步骤失败时，故障应指向单一的责任模块，而非复杂的流程链。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的LLM接口。

Hyperbrowser最具价值的应用场景

在处理 Hyperbrowser 创建阶段的流程时，首先需列出相关契约：所需输入、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将此阶段视为输入与验证后输出之间的契约。为相关成果命名，明确成功判定标准，并杜绝无声的半完成状态。 在耗时较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。

动态研究与竞争情报

在处理动态研究与竞争阶段时，首先写下合同条款：所需输入、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持透明。 在功能结果旁记录执行时间以及令牌或查询成本。提前明确成本有助于避免从演示环境过渡到共享环境时出现意外账单。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次收取相同的LLM调用费用。

RAG与从现代网络获取知识

在处理RAG与知识摄取阶段时，首先明确相关规范：所需输入、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改始终符合要求。 将配置信息与应用程序代码分开。环境文件、密钥存储以及功能开关应集中存放，以便操作人员无需查看整个系统结构即可进行审计。 在调整提示词之前，先使用固定的问题集来测试召回率。仅仅更换提示词往往无法解决检索效果不佳的问题。

经过身份验证的操作工作流

在处理“已认证操作工作流”阶段时，首先需列出相关规范：所需输入、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程与异常恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的功能。 在成本较高的步骤之后设置检查点。当操作员重新尝试某个节点时，恢复流程不应再次调用相同的大型语言模型接口。

浏览器代理评估与实验

在进行浏览器代理的评估与实验阶段时，首先需明确相关约定：所需的输入参数、成功标志，以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改始终符合预期。 建议采用小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 在成本较高的操作之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。

不愿使用 Chromium 的代理产品

在处理具有阶段划分的 Agent 产品时，首先需明确相关契约：所需输入、成功标志以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 将这一阶段视为输入与验证后输出之间的契约。为相关成果命名，定义成功检测标准，并杜绝无声的半完成状态。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的 LLM 接口。 在处理具有阶段划分的 Agent 产品时，首先需明确相关契约：所需输入、成功标志以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 将配置信息置于应用程序代码之外。环境文件、密钥存储及功能开关应集中存放于一个位置，以便操作员无需查看整个流程即可进行审计。

优势与成本

当将其视为可测量的界面时，这些优势与流程才能发挥最佳作用。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。同时记录正常流程与恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的一部分，而非后续需要补充的内容。保持图表状态简洁且具有类型定义。嵌套的数据块会掩盖哪个节点编写了哪个字段的信息，还会在中断后导致流程无法继续。

托管浏览器会话与扩展性

将“托管浏览器会话”与“阶段处理”视为可度量的对象来管理，效果最佳。在扩大范围之前，先记录一份完美的操作日志、一个故障案例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某一步骤出错时，故障应能指向单一责任模块，而非复杂的流程链。 保持图表状态简洁且具有类型定义。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在流程中断后导致无法继续执行。

同一平台实现获取、爬取、搜索、提取及智能代理功能

将“获取-爬取-搜索”提取阶段视为可度量的对象时，其效果最佳。在扩大范围之前，需记录一份理想案例、一个失败案例以及回滚说明。 应将此阶段视为输入与已验证输出之间的契约。为相关成果命名，明确成功标准，绝不允许出现无声的半完成状态。 需保持图结构简洁且类型明确。嵌套的数据块会掩盖哪个节点编写了哪个字段的信息，还会在中断后导致无法继续处理。 将“获取-爬取-搜索”提取阶段视为可度量的对象时，其效果最佳。在扩大范围之前，需记录一份理想案例、一个失败案例以及回滚说明。 配置应置于应用程序代码之外。环境文件、密钥存储及功能开关应集中存放于一处，以便操作人员无需查看整个图结构即可进行审计。

JavaScript渲染以及可选的代理或验证码支持

对于 JavaScript 渲染及可选阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程与异常恢复路径。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的功能。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的配置并不等同于业务功能的完整性。

现有代理主机的 MCP 集成

对于现有阶段的MCP集成，在修改代码之前需明确输入参数、该步骤的负责人以及结束条件。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。相比冗长的脚本，更应采用小型且可测试的单元。当某个步骤失败时，故障原因应能指向单一责任主体，而非复杂的流程链。应在网关处进行身份验证，在数据层再次授权——仅凭承载令牌并不足以界定租户边界。

具备Playwright风格应用控制的HyperAgent

对于采用 Playwright 风格应用阶段的 HyperAgent，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 应将此阶段视为输入与经过验证的输出之间的契约。为相关成果命名，定义成功判定标准，并拒绝默许的半完成状态。 需引用实际作为答案依据的段落。没有引用的话，操作员就无法区分是幻觉内容还是索引缺失导致的错误。 对于采用 Playwright 风格应用阶段的 HyperAgent，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 将配置信息置于应用代码之外。环境文件、密钥存储以及功能开关都应集中在操作员可访问的统一位置。

无需查看完整图表即可进行审计。

重复性认证工作流的配置文件

在处理重复性认证阶段的配置文件时，首先需记录下相关约定：所需输入、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程与异常恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的功能，而非后续需要补充的内容。 在成本较高的操作之后设置检查点。当操作员重新尝试某个节点时，恢复流程不应再次调用相同的大型语言模型接口。

SMCP应属于控制层

在处理 SMCP 阶段任务时，首先需写下合同规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 相比冗长的脚本，应优先选择小型且可测试的单元。当某个步骤失败时，故障应能指向单一责任模块，而非复杂的流程链。 需为每次调用记录工具名称、参数哈希值、延迟时间以及执行结果。没有这些记录，调试过程将会浪费大量时间。

{
  "identity": "procurement-agent",
  "tenant": "enterprise-a",
  "purpose": "vendor-pricing-research",
  "allowed_tools": ["scrape_webpage", "crawl_webpages", "extract_structured_data"],
  "allowed_domains": ["vendor.example"],
  "profile": null,
  "max_pages": 20,
  "max_cost_usd": 2.0,
  "approval_required_for": ["form_submit", "purchase", "account_change"]
}

我们应该做出的决定

在处理“我们应当分阶段执行的决策”时，首先需写下相关契约：所需的输入参数、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持透明可溯。 将这一阶段视为输入与已验证输出之间的契约。为相关产物命名，明确成功判定标准，杜绝默许的半完成状态。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型接口。 在处理“我们应当分阶段执行的决策”时，首先需写下相关契约：所需的输入参数、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持透明可溯。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，以便操作员无需查看整个流程即可进行审计。

注意

将“笔记”阶段视为可度量的对象来处理时效果最佳。在扩大范围之前，先记录一份理想状态下的完整日志、一个故障案例以及回滚说明。 同时记录正常流程与恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的一部分，而非后续需要补充的内容。 保持图结构的状态扁平且具有类型约束。嵌套的数据块会掩盖是哪个节点修改了哪个字段，还会导致在中断后无法继续执行。

参考资料

将“参考资料”阶段视为可度量的对象来处理时效果最佳。在扩大范围之前，先记录一份理想状态下的完整日志、一个故障案例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某个步骤出现故障时，故障应指向单一的责任主体，而非复杂的流程链。 保持图结构的状态扁平且具有类型约束。嵌套的数据块会掩盖是哪个节点修改了哪个字段，还会导致在中断后无法继续执行。

操作检查清单

在处理操作检查清单阶段时，首先写下相关合同条款：所需输入、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。

在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免从演示环境过渡到共享环境时出现意外账单。

在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，系统不应再次收取相同的LLM调用费用。

锁定依赖项的版本，并记录用于运行演示的镜像摘要。可重复性比个人经验更为可靠。