Bret Taylor曾提出：知识工作的未来将由Agent来对接。Browserbase完全认同这个判断——他们把公司内部的几乎所有流程都交给了一个叫bb的通用Agent：Slack里的每一个支持工单、每一次会议记录、每一次数据查询、乃至大量PR，都由bb处理。

这不是一堆垂直Bot，而是一个通用Agent，"懒加载"两种东西：技能手册（Skills）和权限范围（Permissions）。

核心架构：沙箱隔离执行

Agent运行需要一个隔离的执行环境——能够读写文件、执行命令、调用API，但不能碰生产设施，也不能泄露凭证。

Browserbase的方案是云端沙箱：每次Agent会话启动时，都会获得一个独立的临时Linux VM，有自己的文件系统、网络栈和进程树。简单说，就是"秒级启动、用完即弃"。沙箱闲置30分钟后自动释放，会话之间不保留任何状态，除非显式快照。

沙箱启动时会预装一个"快照"——每30分钟重建一次，包含：

  • 关键代码库克隆到/knowledge/，让Agent无需网络请求就能grep和推理任何代码
  • Agent monorepo完整构建，依赖已安装
  • Runtime预启动，本地端口就绪
  • 系统工具：bun、git、GitHub CLI、ripgrep、prettier、pdftotext、TypeScript LSP、Tailscale

Agent只有6个工具：read、write、edit、exec、safebash、skill。其中exec是通往所有外部系统的网关——CRM、生产日志等——统一通过一个无服务器代理。

快照30分钟刷新一次，意味着沙箱最多比main分支落后30分钟代码。新沙箱启动时只拉取增量（通常是几笔commit），所以启动几乎是即时的。

关键趋势：Anthropic的Managed Agents和OpenAI的新Agent SDK都把执行环境（沙箱/文件系统）和Agent逻辑分开。Browserbase也在迁移到这种架构——将各组件做成独立的、可组合的积木块，这样能快速适应SOTA变化。

三种运行模式

bb同时跑在三种模式，切换非常平滑：

交互模式（Deployed/Slack）：有人在Slack频道输入指令，Slack事件处理器分发到一个内部端点，创建一个以Slack thread ID为key的沙箱（或复用已有沙箱）。Agent流式返回SSE事件，实时更新Slack消息。同一个thread的后续消息命中同一个沙箱，保持完整上下文。

后台模式（Background/Webhooks）：外部事件触发——比如支持工单关闭，或会议记录到达——Webhook处理器分发到同一个沙箱基础设施，但以"后台"模式运行。Agent完成工作（检测功能请求、记录到HubSpot、发送摘要到Slack），然后沙箱关闭。

Web UI模式：任何人都能随时通过界面访问bb，看到推理轨迹、工具调用和沙箱状态。

安全架构：凭证代理 + 权限分级

这是最关键的部分。Agent运行任意代码，LLM决定执行什么——如果把API密钥作为环境变量传入，Agent完全可能echo $API_KEY或把凭证写到文件里提交。

Browserbase的解法是把"访问"分成两层：凭证代理和安全集成代理。

沙箱启动时不携带真实凭证，只有三种东西：

  1. BB_PROXY_URL——集成代理的URL
  2. BB_SESSION_TOKEN——轮换会话令牌（在KV存储中有TTL）
  3. AUTOMATION_BYPASS_TOKEN——特定第三方自动化流程所需的第二个令牌

大多数第三方访问都通过集成代理。流程如下：

  1. Agent的exec工具构造请求：POST /api/proxy { token, service, method, args }
  2. 代理验证会话令牌，从KV存储获取该会话的权限范围
  3. 检查请求的service.method是否在允许列表中
  4. 若允许，调用真实服务包（凭证只存在无服务器函数内部），返回结果
  5. 若拒绝，返回403

对于少数集成（模型提供商和代码托管），在网络层做真正的凭证代理：沙箱的出站HTTP请求被防火墙拦截，在离开沙箱前注入真实API密钥。沙箱环境变量只是一个占位符，SDK初始化时不报错，但实际密钥在请求发出前就被透明注入了。

即便如此，凭证代理也不是银弹——Agent仍能生成任意HTTP请求。所以他们还加了请求拦截和域名白名单，对敏感内部API强制限制浏览器工具能访问的域名。

每个代理会话还携带一个PermissionConfig，包含两个维度：

  • services：允许调用的服务和方法（glob模式，如"crm.*"、"support.getIssue"）
  • tools：允许使用哪些OpenCode工具（read、write、edit、exec、safebash、skill）

技能系统：让Agent像资深工程师一样工作

Skill是bb最强大的部分。每个Skill编码了一个" playbook"——相当于资深工程师做某类任务时会遵循的标准流程。

以"会话调查"Skill为例：

1. 查询Tinybird获取会话记录 2. 查询Loki获取浏览器服务日志、连接服务日志、API网关日志 3. 关联诊断：映射会话生命周期（create → connect → browser_ready → page_load → action → close） 4. 识别生命周期在哪一步断裂，检查已知模式

Agent不需要自己想"查哪些日志"或"会话生命周期是什么样"，Skill直接告诉它。

Skill路由表在系统提示里：

- 会话调查、调试、错误分析 → load investigate-session - PR、代码变更、Linear工单 → load create-pr - 客户数据、使用趋势、账户问题 → load snowflake + customer-intelligence - 功能请求记录或分类 → load log-feature-request - HubSpot交易或联系人问题 → load hubspot-crm

对于交互式Slack会话，Agent自主选择Skill；对于后台Webhook会话，权限系统会硬限制——即使路由表建议加载某个Skill，Agent也只能在授权范围内行事。

效果：100%覆盖，零人工

这是最终验证：

  • 功能请求管道：100%覆盖，零人工介入。每个关闭的支持工单和每次会议记录都会自动扫描，功能请求自动记录到HubSpot
  • 首次响应时间：从99%人工处理降至<24小时自动响应
  • 会话调查：从30-60分钟人工翻日志，变成Slack里发一条消息
  • 代码审查：大量工程师从手动写大多数PR，变成只做审查

最终，Slack变成了主要工作界面——人们不再自己做所有事，而是"频道管理员"，管理运行在Slack频道里的Agent。

四个构建块

作者认为，要复制这个架构，只需要四样东西：

  1. 沙箱：任何支持快照和快速冷启动的隔离执行环境
  2. 代理：持有真实凭证、以作用域权限代理访问的无服务器函数
  3. Agent逻辑：任何带Server API的Agent循环
  4. 交互界面：Slack是最好的起点，因为那是团队已经在线协作的地方

核心结论：一个Agent配合正确的抽象，胜过一群垂直Bot。 架构足够简单，可以复制——关键是把执行（沙箱）、访问（凭证代理+权限分级）、可重复性（技能系统）这三件事做对。