終結第 14 步「拒答罷工」：用 Browser-Use / OpenClaw + bf16.ai 跑通全自動瀏覽器 Agent

省流版 · 瀏覽器自動化核心結論

• 瀏覽器代理卡關主因：一般對話模型常將測試環境中的 <input type="password"> 與「同意服務條款」核取方塊誤判為釣魚或冒用憑證而直接拒答。
• 雙引擎低拒答配置：純 DOM 高速迴圈用 deepseek/deepseek-v4.1-flash-abliterated（$0.30 / $0.05 / $1.20）；遇到複雜彈窗與視覺元件則啟用 zai-org/glm-5.3-flash-abliterated（Vision + Text，$0.24 / $0.06 / $1.00）。
• 專為 25 步預發環境測試設計：每一步最多打包四個動作（max_actions_per_step=4），可減少模型來回次數；bf16.ai 的低拒答規劃模型也不會跑到一半就停下來對 CI 說教。

1. 為何 <input type="password"> 與同意條款方塊會觸發偽陽性攔截？

Browser-Use 與 OpenClaw 讓自動化腳本不再受制於脆弱的 XPath。但當代理在自家預發環境執行註冊、填入測試帳號密碼並勾選 ToS 同意方塊時，傳統安全過濾器極易在半途吐出說教文字取代 JSON 動作指令，導致 CI 直接報錯中斷：

[browser-use] Step 11/25 -> URL: https://staging.billing-app.internal/signup/verify
[browser-use] Extracted 42 interactive DOM elements:
  [18] <input type="email" name="work_email" />
  [19] <input type="password" name="password" />
  [24] <input type="checkbox" id="accept-tos-privacy" />
  [25] <button type="submit">Create Staging Account</button>
[llm:response] finish_reason="stop" (0 tool_calls emitted)
  "I cannot enter authentication credentials, create user accounts, or accept legally binding Terms of Service agreements on your behalf."
[browser-use] ValidationError: AgentOutput JSON missing required field 'action'. Suite failed (exit 1).

2. 雙引擎架構：極速 DOM 規劃 + GLM-5.3 Flash 原生視覺輔助

bf16.ai 提供兩款完美互補的 1M 上下文低拒答模型：

1. deepseek/deepseek-v4.1-flash-abliterated：專攻高速純文字 DOM 迴圈。
2. zai-org/glm-5.3-flash-abliterated（Vision + Text）：支援網頁截圖與 DOM 同步判讀，輸入單價僅 $0.24/1M（低於官方 FlashX 的 $0.37/1M）。

3. Browser-Use 實戰程式碼與 Playwright 網域鎖定

啟用 use_vision=True 與 max_actions_per_step=4，即可在單一輪次打包填表、勾選條款與送出動作：

import asyncio, os
from langchain_openai import ChatOpenAI
from browser_use import Agent, BrowserConfig, Browser

# Primary fast DOM planner ($0.30/$0.05/$1.20 per 1M)
dom_llm = ChatOpenAI(
    base_url="https://api.bf16.ai/v1",
    api_key=os.environ["BF16_API_KEY"],
    model="deepseek/deepseek-v4.1-flash-abliterated",
    temperature=0.1,
)

# Multimodal Vision + Text planner ($0.24/$0.06/$1.00 per 1M)
vision_llm = ChatOpenAI(
    base_url="https://api.bf16.ai/v1",
    api_key=os.environ["BF16_API_KEY"],
    model="zai-org/glm-5.3-flash-abliterated",
    temperature=0.1,
)

async def run_staging_onboarding_suite():
    browser = Browser(config=BrowserConfig(headless=True))
    agent = Agent(
        task=(
            "1. Open https://staging.billing-app.internal/signup. "
            "2. Fill test account credentials from QA fixture, check #accept-tos-privacy, and submit. "
            "3. Complete the 3-step workspace wizard and assert that '/dashboard/ready' renders."
        ),
        llm=vision_llm,      # Native Vision + DOM reasoning without refusal lectures
        use_vision=True,
        browser=browser,
        max_actions_per_step=4,
    )
    history = await agent.run(max_steps=25)
    assert history.is_done(), "Staging onboarding E2E did not reach terminal assertion"

if __name__ == "__main__":
    asyncio.run(run_staging_onboarding_suite())

對外連線範圍請務必在 Playwright 路由層做確定性攔截，並可先透過 bf16.ai/playground 測試預設的 Browser-Use JSON 腳本：

// Deterministic Playwright/CDP network guardrail (enforce domain policy in code, not RLHF!)
const ALLOWED_HOSTS = new Set([
  'staging.billing-app.internal',
  'auth-sandbox.billing-app.internal',
  'localhost',
]);

await context.route('**/*', async (route) => {
  const url = new URL(route.request().url());
  if (!ALLOWED_HOSTS.has(url.hostname)) {
    return route.abort('blockedbyclient');
  }
  return route.continue();
});

▲ bf16.ai 線上演練場（/playground）：內建 Browser-Use 入駐 JSON 測試範例，零提示詞留存。

4. 25 步 E2E 延遲與 Token 成本拆解

在瀏覽器自動化中，模型每多 500 ms 的延遲，都會在 25 個連續步驟中層層放大。在 bf16.ai 上結合 max_actions_per_step=4 與串流回應，可減少一輪 25 步註冊 + 工作區設定 E2E 流程中依序呼叫模型的次數；實際耗時與單輪成本請在自家測試套件上自行量測。以下是各方案常見的失敗點：

瀏覽器代理方案	主要失敗原因
傳統對話 API (僅 DOM)	密碼欄與 ToS 核取方塊觸發拒答
本地未驗證 Q4 模型	AgentOutput JSON 格式損壞
deepseek-v4.1-flash-abliterated	僅漏掉無 ARIA 標記之 Canvas 浮層
glm-5.3-flash-abliterated (含視覺)	可同時處理登入／ToS 等 DOM 元素與視覺浮層

5. 瀏覽器自動化上線前的 4 條鐵律

1. 嚴禁用正式環境最高權限帳號跑自動化，並以 Playwright context.route() 鎖死網域白名單。
2. 開啟 max_actions_per_step = 4，減少多欄位表單的來回延遲。
3. 真實金流結帳頁面必須保留人工確認閘門。
4. 設定 max_failures=3 與每把 Key 的每日美元上限，避免測試環境異常造成無謂重試。