Written with AI assistance from the source video. The video is the authority.
13:51AI LABS
Log in to leave a comment
No posts yet
对于独立开发者而言，Cursor 或 GrokBot 这类浏览器代理是非常有吸引力的选择。它们可以自动处理那些让人头疼、需要逐个点击检查的外部仪表盘或竞品监控。
问题在于，当把这个工具直接与宿主机的浏览器会话进行关联时，麻烦就来了。如果在抓取不可信的网页时遭遇间接提示词注入（Indirect Prompt Injection），残留在本地存储中的会话Cookie和认证令牌就会原封不动地被盗取并发送到外部服务器。如果再加上代理找不到DOM元素而开始无休止地重复发送同一请求，当你一觉醒来时，就会收到一张高达几百美元的API账单。
不要指望自然语言提示词会自动处理好各种异常。更好的办法是对运行时本身进行物理隔离，并设置好安全机制以防止金钱和时间的流失。
代理所使用的浏览器配置文件必须与你平时用于办公的环境完全隔离。从 Chromium 136 版本开始，针对默认用户数据目录（--user-data-dir）的远程调试连接已被阻断，隔离标准变得更加严格。
必须关闭操作系统的默认凭证子系统，并使用独立的目录启动浏览器：
`bash
google-chrome
--user-data-dir="/opt/grokbot/isolated_profiles/worker_01"
--profile-directory="AgentContext"
--disable-save-password-bubble
--disable-fill-on-account-select
--credentials_enable_service=false
--no-first-run
--no-default-browser-check
`
账号权限也需要进行调整。进入谷歌管理控制台（admin.google.com）的 安全 > 访问权限和数据控制 > Google 会话控制。创建一个专门供代理使用的辅助组织单位（Agent-Sandboxed-OU），并将Web会话持续时间从默认的 14 天缩短至 24 小时（1,440 分钟）进行保存。
在查看支付仪表盘时，如果使用拥有完全管理员权限的密钥（sk_live_...）也是很危险的。应该单独提取并传递仅包含 Charges: Read、Subscriptions: Read 权限的受限密钥（rk_live_...）。
| 关联服务 | 允许权限 | 禁止权限 | 注入方式 | 被拦截的风险 |
|---|---|---|---|---|
| Stripe | Charges: Read, Subscriptions: Read | Charges: Write, Payouts: Read/Write | rk_live_... (环境变量) |
擅自退款及更改结算账户 |
| Google Workspace | gmail.readonly, drive.metadata.readonly | gmail.send, gmail.modify | Scoped OAuth 2.0 Access Token | 发送冒充钓鱼邮件及篡改文件 |
| Vercel / AWS | Read-only Monitoring, Logs View | Deployments, Secrets Edit | Scoped Token / IAM Role | 任意终止生产实例 |
配置完成后，不妨让代理尝试访问 Stripe 结算账户管理地址（[https://dashboard.stripe.com/settings/payouts](https://dashboard.stripe.com/settings/payouts)）。如果浏览器画面弹出了重新认证窗口或报出 HTTP 403 错误，则说明隔离已经成功。
如果浏览器代理找不到某个按钮，它就会不断修改提示词陷入乒乓循环。当它拿着 128k 的上下文重复几十次重试时，令牌成本就会疯狂飙升。在提示词里写上一句“如果失败就停止”是远远不够的，大模型经常会忽略这一指令。
必须在代码级别设置能够强制终止进程的熔断器（Circuit Breaker）。首先，在编排配置文件（.cursorrules 或 GrokBot 环境变量）中写死重试上限。
`text
AGENT ORCHESTRATION CONSTRAINTS
Execution Thresholds:
MAX_RETRIES_PER_TASK = 2
PER_STEP_TIMEOUT_SECONDS = 300
DAILY_TOKEN_BUDGET_HARD_CAP_USD = 5.00
Deterministic Termination Rules:
同类型的DOM选择器连续2次失败记录后，立即终止进程。
不再尝试更改表述进行第3次重试。
当单次会话成本达到 $5.00 时，立即中断所有工作并返回退出代码。
`
通过Python脚本监控连续失败，一旦触及极限，便通过电报（Telegram）发送日志并立即终止进程。
`python
import os
import sys
import logging
import requests
TELEGRAM_BOT_TOKEN = os.getenv("TELEGRAM_BOT_TOKEN")
TELEGRAM_CHAT_ID = os.getenv("TELEGRAM_CHAT_ID")
class AgentCircuitBreaker:
def init(self, max_consecutive_failures=2):
self.consecutive_failures = 0
self.max_failures = max_consecutive_failures
def record_failure(self, task_name: str, error_trace: str, current_url: str):
self.consecutive_failures += 1
logging.warning(f"Task '{task_name}' failed ({self.consecutive_failures}/{self.max_failures})")
if self.consecutive_failures >= self.max_failures:
self.trigger_kill_switch(task_name, error_trace, current_url)
def record_success(self):
self.consecutive_failures = 0
def trigger_kill_switch(self, task_name: str, error_trace: str, current_url: str):
message = (
f"[CIRCUIT BREAKER TRIGGERED]\n"
f"Task: {task_name}\n"
f"URL: {current_url}\n"
f"Cause: Consecutive Failures >= {self.max_failures}\n"
f"Trace: {error_trace[:400]}"
)
api_url = f"https://api.telegram.org/bot{TELEGRAM_BOT_TOKEN}/sendMessage"
payload = {"chat_id": TELEGRAM_CHAT_ID, "text": message}
try:
requests.post(api_url, json=payload, timeout=5.0)
except Exception as e:
logging.error(f"Failed to post webhook: {e}")
sys.exit(1)
`
每个代理实例的检查对象限制在最多 50 个。一旦满 50 个，就彻底销毁浏览器上下文（context.close()）并重新打开。在批量任务之间留出大约 60 秒的休息间隙，也能避免触发 Stripe 的每秒请求限制（25 req/sec）导致账号被封。
为了验证其运作情况，可以给它抛下一个点击不存在的 DOM 选择器（#phantom-settlement-modal）的测试任务。如果在重试 1 次（总共尝试 2 次）后立即停止并收到电报通知，说明一天的支出就可以控制在 $5 以内。
用 React 或 Next.js 制作的仪表盘在加载 HTML 后，仍需解包 JavaScript 捆绑包并经历水合（Hydration）过程。如果代理只看 window.onload 事件就马上切入，就会把骨架屏（Skeleton Loader）误认为是实际数据并报错。然而，一味地设置 time.sleep(5) 又太浪费时间。
应当设置明确的锚点元素并运行轮询函数。
`python
import logging
from playwright.sync_api import Page, TimeoutError
def wait_for_dashboard_hydration(
page: Page,
anchor_selector: str,
max_attempts: int = 3,
interval_ms: int = 3000
) -> bool:
for attempt in range(1, max_attempts + 1):
try:
page.wait_for_selector(anchor_selector, state="visible", timeout=interval_ms)
if not page.locator(".dashboard-skeleton-loader").is_visible():
return True
except TimeoutError:
logging.info(f"Hydration waiting: Attempt {attempt}/{max_attempts}")
return False
`
通过无障碍树（Accessibility Tree）抓取目标节点的文本（Total Volume: $12,450.00），并将当前屏幕截图传递给多模态模型，与卡片UI中的数字进行比对。如果两个值不同，则认为渲染尚未结束，并在 3 秒后再次检查。
可以通过 Chrome 开发者工具协议（CDP）创建虚拟网络延迟环境来测试此逻辑。
`python
cdp_session = page.context.new_cdp_session(page)
cdp_session.send("Network.emulateNetworkConditions", {
"offline": False,
"latency": 500,
"downloadThroughput": 400 * 1024 / 8,
"uploadThroughput": 400 * 1024 / 8
})
`
即使在 RTT 500ms、下载 400kbps 的延迟状态下，只需确认代理不会过早地抛出失败，而是等待 3 次（总共 9 秒）并完整抓取到数据即可。
当代理在夜间工作时突然停止，没有什么比翻阅数千行文本日志更让人头疼的了。如果每周都要花三四个小时来收拾监控的烂摊子，自动化也就失去了意义。
每次所有子代理完成操作后，都让它们只把 timestamp、url、action 三样内容记录下来，并输出为单行 JSONL 文件。
`json
{"timestamp": "2026-03-31T08:15:02Z", "url": "https://dashboard.stripe.com/payments", "action": "CLICK", "target": "button[data-testid='filter']", "status": "SUCCESS"}
{"timestamp": "2026-03-31T08:15:05Z", "url": "https://dashboard.stripe.com/payments", "action": "WAIT_FOR", "target": "div[data-testid='metrics-card']", "status": "RETRY_1", "error": "Timeout 3000ms"}
{"timestamp": "2026-03-31T08:15:08Z", "url": "https://dashboard.stripe.com/payments", "action": "EXTRACT_TEXT", "target": "div[data-testid='metrics-card']", "status": "FAIL", "screenshot_path": "artifacts/errors/metrics_fail.png"}
`
任务结束后，主导机器人会挑出带有 FAIL 标签的项目，生成 Markdown 摘要（daily_failure_digest.md）。
`markdown
Total Jobs: 50 | Succeeded: 48 | Failed: 2 | Total Token Cost: $0.84
`
上班后打开摘要花 1 分钟确认失败数量，打开截图花 1 分钟确认修改后的选择器，再花 1 分钟点击修改批准复选框，就大功告成了。再也不用每天早上对着日志纠结了。
浏览器代理说到底只是应对非结构化环境的一种手段。对于官方 API 已经很完善的地方，完全没有必要投入浏览器代理。
| 分类 | 共享云端浏览器 | 隔离型无状态容器 | 官方 REST API |
|---|---|---|---|
| 初始设置 | 输入提示词即可直接运行 | 需要 Docker 镜像与网络隔离 | 需要端点认证与映射 |
| 安全隔离级别 | 必须配备 Chromium 配置文件及会话策略 | 任务完成后销毁容器 | 无浏览器Cookie被窃取风险 |
| 执行成本 | 由于视觉推理和 DOM 序列化而较高 | 产生托管成本及 LLM 推理成本 | 仅需 JSON 解析，成本极低 |
| UI 变更恢复力 | 可基于视觉信息进行绕过 | 需要部署选择器修改代码 | 完全不受 UI 变更影响 |
| 适合任务 | 无 API 的外部仪表盘检查 | 大规模网页抓取 | Stripe 支付确认、数据库更改 |
涉及资金往来的支付或更改账户操作，必须使用官方 API 才能保证安全。相反，对于诸如合作伙伴后台检查或屏幕监控等原本需要人工手动操作、且没有提供 API 的领域，浏览器代理则能大显身手。只要做好物理浏览器隔离并设置好熔断器，即便彻夜运行代理也能安心。