演讲背景与浏览器代理基础

本次工作坊由 Browserbase 销售工程团队的 Shubhankar Srivastava 主讲，核心议题是如何在不改写模型权重的前提下提升 Agent（智能体）的技能。演讲者首先简要介绍了浏览器代理的概念：即通过 CLI、MCP 或其他控制接口，让 Agent 能够执行点击按钮、截图或获取无障碍树快照等底层操作的工具。Browserbase 提供了构建和运行这些代理所需的基础设施、SDK 及技能库。浏览器代理的核心挑战在于可靠性，而非单纯的智能水平。尽管 Opus 和 Fable 等最新模型在短期内表现出极高的智商，但在生产环境中，Agent 经常因陷入反爬虫机制、忘记任务或无法处理复杂交互而失败。可靠性本质上是一个工程问题，取决于赋予 Agent 的工具链和特定技能。

当前浏览器代理的可靠性痛点与根因分析

为了说明现状，演讲者列举了两个典型失败案例。首先是 Google Flights 场景：Agent 试图拖动时间过滤器，但由于不理解 HTML 元素结构或所需的 JavaScript 操作逻辑，导致无法完成拖拽动作并卡住。其次是 OpenTable 场景：Agent 在尝试预订餐厅时遭遇反爬虫拦截，直接返回“Access Denied”。这些问题的根源在于 Agent 是“从不学习的天才”。每次运行都从零开始，缺乏从生产痕迹中学习的能力。虽然有人建议针对特定网站（如餐厅预订）进行微调，但这不具备可扩展性。正如演讲者所言：> “Every agent run is a start from scratch run and it's not learning from its production traces.” 这种缺乏累积学习机制的现状，导致计算机使用（Computer Use）领域的进展缓慢。

引入 Auto Research 循环与现场演示思路

针对上述痛点，演讲者引入了 Karpadi 提出的 Auto Research 概念。这是一个自我改进的循环机制：Agent 面对一个可验证的问题陈述，通过反复尝试、检查自身运行痕迹（traces）并据此优化策略来提升表现。如何将这一概念应用于非确定性、每日变化且带有反爬虫机制的复杂网页工作流？ 演讲者计划通过现场演示来回答这一问题。他设定了一个具体任务：使用浏览器代理在 Google Flights 上查找本周六从旧金山到纽约的商务舱航班，要求包含一个随身行李且为早班机。演示将展示远程浏览器启动、导航至目标网站，以及 Agent 实时推理和应用商务舱过滤器的过程。这一演示旨在揭示 Auto Research 循环背后的架构，展示如何通过技能迭代解决复杂的浏览器交互问题。

双智能体协作架构：执行者与教师

该演示的核心在于一种名为“自动浏览循环”（Auto Browse Loop）的架构，它结合了 Auto Research 和 Browsing 技术。这一循环本质上由两个智能体 SDK 组成：一个是“执行者”（Doer Agent），另一个是“教师”（Teacher Agent）。执行者的职责是直接操作浏览器，通过 CLI 访问工具、点击按钮并分析截图以获取信息。而教师的任务则是审查执行者的操作轨迹，判断哪些步骤正确、哪些错误。这两个智能体持续协作，直到找到收敛的最佳解决方案。

"We don't tell it how many loops you need to go for... We just give it a broad prompt and we let the bitter lesson."

系统不预设循环次数、成功率阈值或 Token/时间限制，而是给予宽泛提示并拥抱“痛苦教训”（Bitter Lesson），让智能体自主探索最优路径。这种机制避免了人为设定僵化规则，允许系统在无约束环境下自我进化。

策略文件驱动的知识沉淀：strategy.md

迭代过程中的关键产出是一个名为 strategy.md 的文件，它作为跨多次运行的持久化工件存在。每次迭代后，教师会分析截图和日志，将新发现的技巧写入该文件。例如，在第一次迭代中，系统发现手动操作日历表单浪费了大量 Token 和时间，于是学习到“应跳过整个表单小部件，直接使用查询参数”。这一洞察被记录在 strategy.md 中，并在后续迭代中被执行者复用。

这种机制使得智能体能够积累 JavaScript 黑客技巧、绕过 UI 限制的方法等。最终目标是生成一个 skill.md 文件，其中包含所有从先前运行中习得的“黑客”或技巧集合。这些持久化的学习成果为未来的智能体提供了巨大的性能、可靠性和成本优势，使其无需重复试错即可高效完成任务。

案例实证：Google Flights 任务的性能跃升

在 Google Flights 任务的演示中，迭代效果显著。第二次迭代成功通过测试，成本从第一次的 $12 降至 $3（约 4x 节省），且使用的模型均为 Opus。第三次迭代进一步减少了轮次并降低了延迟，尽管随后出现了一次过度校正导致的失败，但系统仍在持续学习。在另一个针对 AI Engineers 网站的案例中，尽管所有迭代均通过测试，成本仍实现了 7.4x 的优化。skill.md 中记录了诸如“直接前往日程页面”、“遇到错误不要盲目重试”等具体技巧，体现了知识的精细化沉淀。

突破环境限制：从 Access Denied 到高效查询

最引人注目的案例是解决“Access Denied”错误。初始迭代中，智能体因访问被拒而失败。教师分析后意识到这是环境层面的封锁，因为网站试图阻止此类自动化操作。在后续迭代中，智能体发现通过构造包含经纬度和 Metro ID 的查询参数，可以直接获取可用的 UI，从而绕过被封锁的路径（如 /r 和 /s）。这一策略使成本从 $6.22 骤降至 $0.51，耗时从 189 秒缩短至 27 秒。系统甚至生成了包含旧金山已知 Metro ID 和日期计算逻辑的详细步骤，证明了智能体在无人工干预下发现复杂绕过技巧的能力。

"These are the kind of learnings where a human could never have done... you just sort of embrace the bitter lesson and let agents do the job."

这种通过自动化探索获得的深层洞察，远超人类手动编写脚本的效率与深度。

生产环境中的可靠性与成本优势

在将代理（Agents）投入生产环境的场景中，销售只有在浏览器代理成功完成任务时才真正达成。因此，对于演讲者而言，可靠性是至关重要的核心指标。他向客户推荐的关键工具是让代理自主执行自动研究任务，从而确保其在生产环境中的成功率。这种方法的商业价值体现在显著的成本降低上：根据不同任务类型，成本可降低高达16倍、12倍或3倍。当然，由于每个任务的瓶颈不同，具体数值会有所波动，但核心思路是利用这些技术进行“爬山”（Hill-Climbing）式的优化迭代。

实时演示：自动技能生成的“神话时刻”**

演讲者回顾了关于旧金山至纽约单程商务舱机票预订的实时演示。代理成功应用了端到端的技能，无需进一步学习即可正确输出结果：7月4日、含一件手提行李、早上8点出发，票价649美元。代理通过分析整个流程并生成技能，甚至将查询编码进URL以优化路径。演讲者称这是浏览器代理的“神话时刻”（mythos moment），因为客户不再需要为每个网站编写脚本或花费大量工程时间进行逆向工程。

“当我第一次看到这些结果时，那是我的‘神话时刻’……客户们简直惊呆了。”

这种技术使得客户能够构建动态生成的技能管道，自动创建拉取请求。如果在生产环境中出现故障，代理会自动介入并修复技能，从而实现了工程上的自动化闭环。

Browse.sh：浏览器代理的“黄色 Pages”**

为了推广这一技术，演讲者推出了名为 browse.sh 的产品。这被比喻为浏览器代理时代的“黄色 Pages”，提供了在任何网站上执行任何任务的详细信息和技能库。用户可以使用免费的 browse CLI 安装并使用这些技能，演讲者团队已承担相关的令牌成本。例如，用户可以直接调用 Amazon 的技能来搜索产品、查看价格和可用性。

该工具与 OpenClaw 等代理集成，能够自动判断何时调用特定技能（如 AllTrails.com 或 Weather.gov）。此外，用户还可以请求生成针对特定任务的技能（如查找旧金山本周活动），系统会通过邮件发送生成的技能供代理使用。这种后端自动研究循环使得跨网站的任务执行变得极其简便。

通用化挑战与可验证性机制**

演讲者探讨了将此技术应用于其他领域（如代码代理、研究代理和内部运营）的可能性。核心痛点在于代理不应从零开始重新学习任务或仓库规范。要使自动研究循环有效，必须满足两个条件：一是拥有可重放的环境以运行迭代循环；二是具备某种形式的可验证结果或量化指标，以便评估循环的收敛性。

针对如何确保自动研究循环准确性的疑问（即代理声称“好”或“坏”时是否真实），演讲者指出，虽然神经网络的训练可以通过日志损失（log loss）轻松验证，但在浏览器代理场景中（如是否找到最佳航班），结果往往较为模糊。因此，循环设计必须具备韧性以抵御失败。即使某些迭代出现错误或导致损失爆炸（exploding loss），良好的设计也能防止代理过度依赖之前的失败，从而保护整体流程的正确性。

可验证结果与可重放环境是迭代优化的基石

在构建能够自我改进的智能体（Agent）时，核心在于设计具备可验证结果或量化指标的循环机制。演讲者指出，只要存在明确的评估标准，就可以设计出高效的优化回路。可重放环境（Replayable Environment）虽然常被讨论不足，但在此过程中至关重要。如果智能体无法在失败中反复磨练（Grind），就难以通过多次迭代实现自我修复。例如，编码类智能体拥有良好的可重放性，因为它们可以从 Docker 镜像或特定的 EC2 实例启动，并从栈的不同部分进行重放。相比之下，知识工作往往难以重放，因为其中包含大量需要人类介入的操作，使得从特定时间点恢复变得异常困难。因此，投资于环境的构建和可重放性设计，对于提升智能体的鲁棒性和迭代效率具有极高的回报。

"As long as you have a verifiable outcome or some quantifiable metric, I think you should be able to design a good loop here."

成本效益分析：长迭代与廉价模型的权衡

关于优化收敛性的一个关键问题是高成本的考量。许多人直觉认为，更长的迭代周期会导致成本随时间线性甚至指数级增长。然而，通过实际的评估实验（Evals），演讲者发现了一种更具成本效益的策略：使用廉价模型进行更多次迭代，往往比使用昂贵模型进行少量迭代更能以更低总成本完成任务。例如，将 Sonnet 模型投入更多次数的运行，虽然单次成本低，但通过增加迭代次数来弥补能力差距，整体花费反而低于使用 Opus 模型进行少数几次运行。这种成本是摊薄（Amortized）的，一个典型的 Auto Browse 循环在复杂情况下成本约为 $30-$40，极端情况不超过 $100。只要这些成本在部署到生产环境时是合理的，这种策略就非常值得采用。

从“人肉逆向工程”到自动化循环的演进路径

Auto Browse 的设计灵感来源于 Karpathi提出的自动研究概念，但其具体实现过程紧密结合了实际业务痛点。演讲者描述了一个从手动逆向工程到自动化循环的转化过程：最初，面对客户的可靠性问题，演讲者作为“教师智能体”亲自介入客户办公室，通过暴力破解和逆向工程来寻找解决方案。随后，他尝试将这一过程自动化，借鉴 Karpathi 的思路构建了一个循环系统。教师智能体（Teacher Agent）负责在每次迭代中发现新的学习点，并将其写入策略文件；执行者智能体（Doer Agent）则负责具体操作。这种机制允许系统在不断试错中积累知识，例如在 OpenTable 预订案例中，教师智能体通过分析截图和可访问性树快照（Accessibility Tree Snapshot），逐步修正了关于日期格式、页面点击等错误，并将这些经验固化到 strategy.md 中。

基础设施与反对抗场景下的技术实现细节

在浏览器代理的实际部署中，基础设施的质量直接决定了智能体在面对反爬虫和反机器人机制时的成功率。Auto Browse 支持多种登录状态管理方式，包括通过代理服务器访问特定 IP（如住宅 IP），以及利用 Browserbase 基础设施保存和复用 Cookie，从而避免每次运行都重新登录。这种设计极大地简化了真实工作流的复制过程。在技术实现层面，评估脚本（如 evaluate.mjs）列出了完整的循环逻辑。在每次迭代中，教师智能体分析执行者的输出（包括截图和步骤追踪），识别成功与失败之处，并生成新的策略指令。这种基于痕迹（Traces）的反馈循环确保了智能体能够从具体的执行细节中学习，而不仅仅是依赖最终的成败结果。

"A lot of success is definitely how good your infrastructure and environment is, especially in these adversarial scenarios."

实时演示与社区互动机制

为了展示 Auto Browse 的实际效果，演讲者提供了 GitHub 仓库和具体的技能指令。用户可以通过扫描二维码获取代码库，并在 Claude Code 或 Codex 中通过输入 /auto browse 命令来生成特定的浏览器操作技能。演讲者还展示了具体的迭代日志，例如在 OpenTable 预订任务中，系统从最初的“打开裸页面并点击浪费三个回合”到后来能够正确解析日期和定位元素，展示了教师智能体在每次迭代中不断修正策略文件（strategy.md）的过程。这种透明的反馈机制不仅有助于开发者调试，也为社区提供了直接测试和优化智能体的途径。

"In every iteration the teacher is learning something new and putting this back into the strategy.md."

技能工程与Harness设计的权衡

提升Agent可靠性的核心在于工程设计而非模型本身的改变。在技能（Skills）的分配策略上，存在两种主要路径：一是为每个特定任务设计专属技能（One skill for each task），二是构建一个能应对所有潜在任务的通用技能（One skill for all）。这种选择完全取决于用例的具体需求以及Harness工程的架构设计。演讲者指出，关键在于通过运行评估（Evals）来测试不同策略的效果。例如，如果Harness具备足够的智能，它能够从OpenTable、Resi或Google Reservations等多个来源动态引入技能，从而自主决定预订约会晚餐的最佳方式。因此，Harness应当具备根据用户常见用例选择最佳Scale Files、Prompt和工具的能力。无论是采用通用还是专用技能，最终都应通过全面的评估让Harness自行决策最优解。

"Reliability is an engineering problem. You can design your harness to sort of go for one skill for each task or you can be like hey one skill for every task that you will ever see."

技能的存储、检索与生产环境部署

在技能的管理层面，数据存储方式需根据使用场景灵活调整。对于本地开发或实验环境，技能文件通常存储在本地的skills文件夹中；而在生产环境中，则需要考虑规模化存储与按需调用。以Browserbase的公开技能库为例，他们采用Vercel Blob Storage来存储所有技能文件，确保能够随时按需获取。此外，演讲者提到与Microsoft合作发布的关于构建Agent验证器（Verifiers）的研究论文，这些研究成果也被应用于当前的技能管理中。虽然运行评估本身并不复杂，但如何验证评估结果的有效性（Eval your eval）是一个更深层的问题。这涉及到是否需要人工介入验证，或者构建自动化的验证器来确保Agent运行的准确性。

网站变更监控与自动化修复策略

鉴于网站结构频繁变化，保持技能的时效性是工程中的重大挑战。目前的核心理论是避免无意义地每日运行自动研究（Auto Research）以浪费Token，而是采取基于生产环境故障的触发机制。当系统在运行中遇到失败时，会启动一个自动研究循环来诊断问题、生成修复方案并创建Pull Request。该请求直接提交给人类工程师，由其进行最终确认和合并，从而更新技能。这是一种在准确性与成本之间的权衡：除了故障触发外，也可以设置定时任务（如每2-3小时运行一次）来检查技能的准确性。目前，演讲者正在与客户合作实施这一自动化修复流程，以解决网站变动导致的技能失效问题。

"As soon as we run into any production failure, we run an auto research loop to see what went wrong to heal it... The skill gets updated."

优化目标与WebMCP的支持现状

在自动研究循环中，优化指标的选择直接决定了Agent的行为模式。如果仅关注成功率（Success），系统可能会快速返回结果；但如果优化目标是延迟最小化（Latency），Agent甚至可能发现无需浏览器操作，直接逆向工程网站API即可在毫秒级完成任务。例如，有案例显示Agent能在500毫秒内找到解决方案。若优化目标是减少对话轮次（Turns），则会尽量压缩上下文循环。演讲者个人更关注可靠性而非成本，因此允许Agent持续运行直到达到收敛标准。关于WebMCP（网页可编程接口），这是一种让网站提供类似API功能的新概念，虽目前Auto Research Loop尚未原生支持，但Browserbase的SDK已提供相关工具。未来有望通过集成WebMCP进一步提升Agent与网站交互的效率。

"People want to minimize on latency... sometimes these auto research loops are so smart they realize that browsers are not needed at all and they just reverse engineer the API."

Web MCP 的采用现状与评估哲学

在探讨大规模部署网页 MCP（Model Context Protocol）时，Speaker 指出目前该领域的实际采用率并不高。对于任务完成的评估标准（Ground Truth），核心在于结果导向而非过程监控，例如在 Google Flights 找到最便宜航班或在 OpenTable 成功预订即视为通过。这种评估通常是二元的，且 Speaker 完全拥抱“痛苦教训”（Bitter Lesson）理念。这意味着在评估过程中，应尽量减少人为设置的护栏或限制，让代理模型通过大规模试错自我进化。虽然有人提议建立“验证即服务”（Verifier as a Service）以模拟副作用（如购买行为），但 Speaker 对此持保留态度，认为这并非当前主流做法。

“I fully embrace the bitter lesson. I try not to put many guardrails in uh these evaluations.”

Speaker 强调，Browserbase 倾向于尽可能模仿真实世界，利用其对互联网大部分网站的访问权限来捕获求解器等数据。尽管市场上存在许多针对 Salesforce 或 SAP等特定平台优化的 RL（强化学习）环境，但 Browserbase 坚持在真实门户网站上进行训练，以确保代理具备处理复杂、非标准化网页的能力。这种策略虽然增加了难度，但能培养出更具泛化能力的浏览器代理。

边缘捕获处理与技能迭代机制

关于网站反爬虫措施（如 Edge Captures/ReCAPTCHA），Speaker 澄清这并非通过 AI Token 激励来解决的任务。这类验证通常在基础设施层，即 Chrome 二进制层面解决。Browserbase 默认提供开箱即用的解决方案，无需消耗 AI 模型的推理资源去“猜”验证码。在技能（Skill）的迭代优化方面，系统通过读取每次迭代的 Trace 日志文件夹中的 JSON 文件来评估“执行者”（Doer）的表现。系统包含一个 Clawed Agent SDK 循环，能够分析代理的行为轨迹。

技能的进化依赖于策略文件（strategy.md）的注入。在每次迭代中，系统会将当前的 system prompt 和之前的策略文件结合，由“教师”代理评估执行者的工作成果。基于这些痕迹数据，“教师”会生成更优的策略并反馈给“执行者”。这种机制使得技能成为一种可移植的工件（Portable Artifact），不仅限于 Browserbase 或 Stagehand SDK，也可以嵌入到任何支持 Markdown 的 Agent 代码中。例如，用户可以直接在 Cloud Code 中使用技能查询特定日期的事件，而无需依赖特定的浏览器代理工具。

多层级安全防护与防注入策略

鉴于浏览器的开放性带来的巨大安全风险，Speaker 详细阐述了 Browserbase 构建的三层安全防护体系。第一层是基础设施层的网络防火墙和浏览器沙箱。通过 Browserbase Safe Mode，用户可以严格控制代理可以访问的 URL 范围以及在不同网站上允许执行的动作类型。这种限制在查询进入系统表面区域时即生效，从源头阻断恶意行为。

第二层是技能层面的安全审查。在将生成的技能发布到 Browser.sh 之前，系统会运行一个专门的安全审查代理（Security Reviewer Agent）对技能进行预检，确保其未被恶意网站诱导。第三层则是针对最终用户的护栏建议。Speaker 指出，如果用户将代理暴露给消费者（C端），必须建立足够的提示注入护栏。例如，当自动化访问 Amazon 时，需防止恶意卖家在商品描述中隐藏指令诱导代理执行危险操作。为此，系统允许用户配置类似 CodeEx 或 PlotCode 的权限策略（如始终允许、仅允许一次或完全禁止），从而在指令到达代理核心之前进行过滤。Speaker 强调，浏览器是一个极其危险的威胁向量，必须从提示注入的角度严肃对待这些安全措施。

“I think I would put like three layers here. One is as the query is even entering our surface area we control that at the skill layer... and at the infrastructure layer we have network restrictions.”

长期运行的稳定性与故障恢复

针对自动化任务在长时间运行中可能遇到的网站结构变化或反爬策略更新，Speaker 分享了基于 Cron Job 的自愈循环（Healing Loop）方案。通过定期调度托管代理执行特定技能，并设置成功/失败的通知机制，系统可以自动检测任务异常。一旦检测到失败（例如因网站改版导致技能失效），通知机制会触发自愈循环，重新优化或更新策略。这种检查与平衡（Checks and Balances）机制确保了自动化流程在面对外部不可控因素时的鲁棒性。Speaker 表示，这种基于事件驱动的反馈闭环是维持长期稳定运行的关键。

“if this is a failure send me a notification here that will trigger a healing loop so that's how I sort of can bake in uh checks and balances around websites changing antibbots”

Speaker 在会议期间将继续参与讨论，并欢迎有兴趣的用户通过现场二维码或 Browserbase 展台进一步交流技术细节。

结论

本方案证实，在不修改模型权重的前提下，通过“执行者-教师”双智能体协作与Auto Research循环，可显著提升浏览器代理的可靠性并大幅降低成本。实证数据显示，Google Flights任务成本降低4倍至16倍不等，OpenTable案例优化7.4倍，Access Denied场景耗时缩短近90%。其核心优势在于利用持久化的strategy.md和skill.md沉淀JavaScript技巧与绕过策略，实现知识的跨运行复用。

该机制适用于具备可重放环境和明确验证指标的场景，如网页自动化。其成功依赖于强大的基础设施以应对反爬机制及提示注入风险。尽管存在环境不可重放（如知识工作）的局限，但通过基于生产故障触发的自愈循环和廉价模型长迭代策略，该工程化路径为构建高鲁棒性、低成本的通用浏览器代理提供了可行范式。