1. 为什么我要把浏览器自动化交给 Agent 来做Browser Agent 说白了就是让大模型自己开浏览器、点按钮、填表单、翻页找答案的智能浏览器代理。它适合谁适合那些每天要在后台系统里重复点几十次的人适合做自动化测试但不想写一堆脆弱选择器的团队也适合想把「帮我查一下某网站今天的数据」变成一句话就能跑通的开发者。我这次用的组合是 AgentScope 负责编排推理循环Playwright MCP 负责真正操控浏览器中间用 MCP 协议把工具层标准化。整个链路跑通之后你只需要在终端输入一句自然语言Chromium 就会自己动起来。但落地过程中有几个绕不开的坎MCP Server 怎么和 Python 侧的 Agent 通信、模型 Key 怎么统一管理、页面快照太长怎么分块、报错 Ref not found 到底该怪谁。这篇就按「一次跑通可复现的最小闭环」来写给出 config.toml 和 settings.json 的可复制骨架把 TaoToken 统一 Key 接进去最后用几个验证动作确认浏览器任务真的执行了。2. TaoToken 统一 Key 接入把模型通道先理顺在写 Agent 代码之前我建议先把模型调用通道固定下来。原因是 Browser Agent 的推理轮次很多任务分解、纯推理、带观察推理、子任务修正、最终总结每一步都要打模型如果 Key 散落在各个环境变量里调试时会非常痛苦。TaoToken 在这里的作用是提供一个统一的 API 通道OpenAI 兼容格式base_url 指向https://taotoken.net/api一个 Key 就能覆盖对话和后续的 coding 场景。你需要先去控制台创建一个 API Key。打开https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentbrowser_agent_console在 API Keys 页面新建一个复制出来。这个 Key 后面会同时写进 AgentScope 的模型配置和 MCP 侧的环境变量里。注意Key 只显示一次建议建完立刻存到本地.env或系统环境变量不要硬编码进 git 仓库。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentbrowser_agent_doc里面有 OpenAI 兼容端点的完整说明。如果你只是想先验证模型通不通可以直接用模型对话页面发一条消息试试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentbrowser_agent_models。确认能返回内容之后再往下配 Agent。环境变量这样设Linux/macOS 用 exportWindows PowerShell 用$env:export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api3. 可复制配置config.toml 与 settings.json 骨架AgentScope 的模型配置我习惯抽到一个config.toml里避免每次改模型都要动 Python。下面这份骨架可以直接复制把api_key换成你的环境变量引用方式即可。# config.toml [model] model_name qwen3-max base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY stream false max_tokens 8192 [agent] max_iters 50 start_url https://www.google.com max_memory_length 20 snapshot_chunk_size 80000 [mcp.playwright] command npx args [playwright/mcplatest] transport stdioPlaywright MCP 这边如果你用的是支持 MCP 配置文件的客户端可以写一份settings.json。这份配置的核心是告诉客户端去哪里启动 Playwright Server以及把模型通道指向 TaoToken。{ mcpServers: { playwright: { command: npx, args: [playwright/mcplatest], env: { TAOTOKEN_API_KEY: ${TAOTOKEN_API_KEY}, TAOTOKEN_BASE_URL: https://taotoken.net/api } } }, model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: ${TAOTOKEN_API_KEY}, model: qwen3-max } }Python 侧读取这份配置并创建 MCP 客户端关键代码是这样import os import tomllib from agentscope.mcp import StdIOStatefulClient from agentscope.tool import Toolkit with open(config.toml, rb) as f: cfg tomllib.load(f) toolkit Toolkit() browser_client StdIOStatefulClient( nameplaywright-mcp, commandcfg[mcp][playwright][command], argscfg[mcp][playwright][args], ) await browser_client.connect() await toolkit.register_mcp_client(browser_client)模型部分用 TaoToken 的 OpenAI 兼容端点AgentScope 里可以这样构造from agentscope.model import OpenAIChatModel model OpenAIChatModel( model_nameqwen3-max, api_keyos.environ[TAOTOKEN_API_KEY], client_args{base_url: os.environ[TAOTOKEN_BASE_URL]}, streamFalse, )这里有个坑我踩过base_url一定要带/api后缀写成https://taotoken.net会 404。另外stream在 Browser Agent 场景建议先关掉因为分块观察推理需要拿到完整 JSON 再解析流式反而增加处理复杂度。4. 验证请求让浏览器真的动起来配置写完先别急着跑完整任务做三步验证。第一步单独测 MCP Server 能不能启动npx playwright/mcplatest --help能打印出工具列表说明 Node 侧没问题。如果卡住不动多半是 npx 在下载包等几分钟或者换国内镜像。第二步测模型通道。用 curl 直接打 TaoToken 的兼容端点curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: qwen3-max, messages: [{role: user, content: 回复 OK}] }返回里有choices字段就说明 Key 和通道都正常。第三步跑最小 Agent 任务。启动主程序输入一句简单指令python main.py --start-url https://www.bing.com --max-iters 10然后在终端输入User: 搜索 AgentScope 的 GitHub 仓库地址并告诉我 star 数正常的话你会看到 Chromium 窗口自动打开地址栏跳到 Bing搜索框被填入关键词回车然后 Agent 读取结果页快照提取出链接。终端里会打印出任务分解的子任务列表、每一轮的推理动作、以及最终的FinalResultJSON。看到result字段里有仓库地址这条闭环就算通了。5. 本篇常见错排查Ref not found in the current page snapshot这是最高频的报错。原因是 Agent 用了上一页快照里的元素引用去点击新页面。解决方式是在系统提示词里强制「每次 browser_navigate 之后必须重新调 browser_snapshot」并且只使用最新快照的 ref。代码层面可以在_acting里加一个判断如果工具返回里包含 Ref not found就自动触发一次快照刷新再重试。MCP 子进程不退出程序结束后 Chromium 还挂着。这是因为StdIOStatefulClient没有正确 close。在main.py的 finally 块里补上await browser_client.close()并且给子进程设一个超时 kill。快照太长导致模型截断页面无障碍树动辄几万字符直接塞给模型会超上下文。按 80000 字符分块每块处理完把STATUS设为CONTINUE再加载下一块只有找到答案才设REASONING_FINISHED。这个逻辑在带观察的推理提示词里已经定义好了你只需要确保_split_snapshot_by_chunk的阈值和模型上下文匹配。任务分解后子任务跑偏比如让它「找最便宜的耳机」它分解成「打开 Amazon」就停了。这时候子任务修正提示词会介入根据当前记忆重新生成子任务列表。如果还是偏检查browser_agent_subtask_revise_prompt.md里的IF_REVISED判断逻辑必要时把原始任务在 prompt 里再强调一遍。模型返回非 JSON 导致解析失败任务分解和反思都要求纯 JSON 输出但模型偶尔会加解释文字。在解析前用正则提取第一个[到最后一个]之间的内容或者用json.loads包一层 try-except 做兜底。6. 后续怎么接得更顺跑通最小闭环之后下一步通常是把它接到长期运行的编码或测试流程里。如果你打算让 Browser Agent 常驻做回归测试或者和 Claude Code 这类编码工具配合建议用 Coding Plan 把模型调用额度固定下来避免每次调试都手动换 Keyhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentbrowser_agent_coding_plan。API Keys 管理页在https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentbrowser_agent_api_keys需要轮换 Key 的时候直接在那里操作。最后说一个我实测下来的经验Browser Agent 的稳定性八成取决于提示词里对「动作粒度」的约束。每次迭代只做一个动作、导航后必须重新快照、下拉框绝不输入只点击这三条写死了Ref not found 能少一大半。代码是胶水提示词才是灵魂。
