1. 为什么我盯上了 Goose Selenium MCP 这条链路自动化测试写久了最烦的不是写脚本而是改脚本。页面一改XPath 全废回归用例跑一半红一片。我最近在折腾一个思路让 AI Agent 直接驱动浏览器用自然语言描述用例由 Agent 自己决定点哪里、填什么、断言什么。Goose 就是干这个的——它是 Block原 Square开源的一个本地 AI Agent 运行时能动态加载 MCP 扩展把外部工具的能力接进来。Selenium MCP 则是把 Selenium WebDriver 的命令封装成 AI 友好的接口让 Goose 用自然语言就能操作浏览器。这套组合适合谁适合已经在做 Web 回归和冒烟测试、想试试 AI Agent 能不能真正落地到测试链路里的同学。它不是什么银弹动态元素照样会翻车但作为「用例触发 → 浏览器操作 → 断言输出」的完整验证动作它跑得通而且可复制。下面我按实际搭建顺序把配置片段、启动参数、测试脚本和踩坑记录都摊开讲。核心检索词先摆出来Goose 驱动 Selenium MCP 做浏览器自动化测试本质是让 AI Agent 通过 MCP 协议调用 WebDriver把自然语言用例翻译成可执行的浏览器动作序列。你不需要重写整套框架只需要把 Goose 当成一个「会自己找元素的执行器」Selenium MCP 当成它的「手」。我实测下来这条链路在 Linux 和 Mac 上最顺Windows 需要走 WSL后面会专门讲。整篇文章的节奏是先讲清楚问题场景再给 TaoToken 的前置配置因为 Goose 需要模型能力然后是可复制的配置和脚本接着验证一次完整请求最后把常见报错对照着排一遍。你跟着做能搭出一个可运行的 AI Agent 测试链路。2. TaoToken 前置给 Goose 接上模型能力Goose 本身是个 Agent 运行时它自己不带模型需要你配置一个 LLM 提供方。我这边用的是 TaoToken 的 API 来驱动 Goose原因是它的接口兼容 OpenAI 风格配置起来直接填 Base URL 和 Key 就行不用改 Goose 的源码。官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址后面不加 UTM 参数。Goose 的模型配置走的是它自己的配置文件通常在~/.config/goose/config.yamlLinux/Mac或者 WSL 里的对应路径。你需要填三个东西Base URL、API Key、Model ID。这三个就是所谓的「三件套」缺一个 Goose 就起不来。我试过只填 Key 不填 Base URLGoose 会默认去连 OpenAI 官方地址结果就是 401因为 Key 不是那边的。先拿 Key。打开 https://taotoken.net/api-keys 登录后创建一个新的 API Key复制出来。这个 Key 只显示一次丢了就重新建。拿到之后在终端里设置环境变量或者直接写进 Goose 的配置。我习惯用环境变量因为这样不会把 Key 硬编码进配置文件export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api然后编辑 Goose 的 config.yaml。如果你还没装 Goose先按下一节的步骤装。配置文件里模型部分大概长这样GOOSE_PROVIDER: openai GOOSE_MODEL: gpt-4o-mini OPENAI_API_KEY: ${TAOTOKEN_API_KEY} OPENAI_BASE_URL: ${TAOTOKEN_BASE_URL}这里GOOSE_PROVIDER填openai是因为 TaoToken 兼容 OpenAI 的接口格式不是说你必须用 OpenAI 的模型。GOOSE_MODEL填你在 TaoToken 上能用的模型 ID比如gpt-4o-mini或者别的。填完之后Goose 启动时会读这个配置把请求发到 TaoToken 的 API 地址。有一点要注意Goose 的配置里 Base URL 不要带/v1后缀TaoToken 的 API 地址就是https://taotoken.net/apiGoose 自己会拼路径。我一开始多加了/v1结果请求打到https://taotoken.net/api/v1/v1/chat/completions直接 404。这个坑后面排障部分还会提。模型选哪个如果你只是跑冒烟测试gpt-4o-mini这种就够响应快、成本低。如果是复杂的回归用例涉及多步断言和动态元素处理可以换更强的模型。TaoToken 的模型对话页面在 https://taotoken.net/models 你可以先在那里试一下模型能不能正常回话确认 Key 和 Base URL 没问题再去配 Goose。这样排障的时候能少绕一圈。3. 可复制配置Goose 安装、Selenium MCP 启动与 settings 片段这一节是整篇的核心我把 Goose 安装、Selenium MCP 扩展配置、以及一个可复制的测试脚本都放出来。你按顺序操作能直接跑起来。先说 Goose 安装。Linux 和 Mac 上一条命令curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bashWindows 用户需要先装 WSL。用管理员权限打开 PowerShell运行wsl --install装完重启进入 WSL 的 Ubuntu 环境再跑上面的 curl 命令。我踩过的坑是WSL 里默认没有 Node.js而 Selenium MCP 是通过npx启动的所以你得在 WSL 里装 Node。推荐用 nvm 装版本管理方便curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash source ~/.bashrc nvm install --lts装完node -v和npx -v都能正常输出才算准备好。接下来配置 Selenium MCP 扩展。Goose 的扩展配置在~/.config/goose/config.yaml里加一段extensionsextensions: selenium-angie: type: stdio cmd: npx args: - -y - angiejones/mcp-selenium env: SELENIUM_BROWSER: chrome SELENIUM_HEADLESS: false这段配置的意思是Goose 启动时会通过 stdio 方式拉起一个子进程执行npx -y angiejones/mcp-selenium把 Selenium MCP 服务器跑起来。SELENIUM_BROWSER指定浏览器SELENIUM_HEADLESS设成false方便你看浏览器实际操作调试阶段建议开着跑 CI 再改成true。这里有个关键点Selenium MCP 需要浏览器驱动。WSL 里默认没有 Chrome你得装一个。在 WSL 的 Ubuntu 里wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | sudo apt-key add - sudo sh -c echo deb [archamd64] http://dl.google.com/linux/chrome/deb/ stable main /etc/apt/sources.list.d/google-chrome.list sudo apt update sudo apt install -y google-chrome-stable装完google-chrome --version能输出版本号就行。Selenium MCP 会自动找 Chrome 的路径一般不用额外配 driver它内部用 Selenium Manager 处理。配置写完后启动 Goose 会话goose session如果扩展加载成功你会看到类似Loaded extension: selenium-angie的输出。如果报错先别急第五节有对照表。现在给一个可复制的测试脚本。Goose 的交互方式是自然语言但你可以把用例写成一段提示词让它按步骤执行。我拿 OrangeHRM 演示站做例子提示词如下导航到 https://opensource-demo.orangehrmlive.com/ 使用用户名 Admin 和密码 admin123 登录 登录后点击 PIM 菜单 添加一名新员工名字叫 Deborah Shmeborah 验证员工列表里出现了 Deborah Shmeborah 然后注销把这段贴进 Goose 会话它会自己规划步骤先navigate再find_element定位用户名输入框send_keys填内容click_element点登录按钮一路往下走。你可以在终端看到它每一步调用的 Selenium 命令和返回结果。如果你想把这段提示词存成文件方便重复跑可以写一个test_case.txt然后用goose session --input test_case.txt这样每次跑回归改一下文本文件就行不用重新敲。实测下来这种方式对冒烟测试特别友好用例维护成本比改 Python 脚本低不少。4. 验证请求从用例触发到断言输出的完整动作配置好之后最关键的一步是验证整条链路真的通了。我拿上面那个 OrangeHRM 用例完整跑一遍把过程拆开讲。启动 Goose 会话后输入提示词。Goose 第一件事是调用 Selenium MCP 的navigate命令打开 OrangeHRM 演示站。终端会输出类似Calling tool: navigate Arguments: {url: https://opensource-demo.orangehrmlive.com/} Result: Successfully navigated to https://opensource-demo.orangehrmlive.com/这一步验证的是 MCP 服务器和浏览器之间的连接。如果这里就报错说明 Chrome 没装好或者 driver 有问题先回去检查第三节的浏览器安装。接着 Goose 会找用户名输入框。它可能用find_element配合nameusername也可能用 CSS 选择器。输出大概长这样Calling tool: find_element Arguments: {by: name, value: username} Result: Element found Calling tool: send_keys Arguments: {text: Admin} Result: Keys sent密码框同理填admin123。然后点登录按钮click_element。登录成功后页面跳转到 Dashboard。Goose 会继续点 PIM 菜单进入员工管理页。添加员工这一步稍微复杂点。Goose 需要点「Add」按钮填 First Name 和 Last Name再点 Save。这里它可能会尝试多种定位策略先试 XPath失败就换 CSS再失败换 name。我在实测中看到它有一次先用//button[typesubmit]没找到自动换成button[typesubmit]就成功了。这种「失败后重试」的能力是 AI Agent 相比固定脚本的一个优势。验证员工是否出现Goose 会调用get_element_text或者find_element去员工列表里搜Deborah Shmeborah。如果找到输出Calling tool: find_element Arguments: {by: xpath, value: //div[contains(text(),Deborah Shmeborah)]} Result: Element found with text: Deborah Shmeborah这就是断言输出的部分。你可以把这段结果当成测试通过的依据。最后注销click_element点用户菜单再点 Logout页面回到登录页。整个流程跑完你在终端能看到一条完整的命令调用链。这就是「用例触发 → 浏览器操作 → 断言输出」的闭环。我建议你第一次跑的时候把SELENIUM_HEADLESS设成false盯着浏览器看确认每一步动作符合预期。跑通之后改成true就可以集成到 CI 里。如果你想更直观地验证模型侧是否正常可以先去 https://taotoken.net/models 发一条测试消息确认模型能回话。因为 Goose 的每一步规划都依赖模型输出模型不通Selenium MCP 再正常也没用。这个顺序别搞反先确认模型通再确认 MCP 通最后跑完整用例。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth这一节我把实际遇到的报错和对应解法列出来你对照着排。每个报错都给出真实错误文本和排查路径。401 Unauthorized。这个最常见通常是 Key 或 Base URL 配错。错误文本类似Error: 401 Unauthorized {error: {message: Invalid API key, type: invalid_request_error}}排查顺序先确认TAOTOKEN_API_KEY环境变量在当前 shell 里能echo出来再确认 Goose 的 config.yaml 里OPENAI_API_KEY引用的变量名一致最后确认 Base URL 是https://taotoken.net/api没有多加/v1。如果 Key 是从 https://taotoken.net/api-keys 刚建的确认复制完整没有多余空格。local proxy failed。错误文本Error: local proxy failed: dial tcp 127.0.0.1:7890: connect: connection refused这个说明你的系统里配了本地代理但代理没启动。Goose 发请求时走了系统代理设置。解法是检查环境变量HTTP_PROXY和HTTPS_PROXY如果不需要代理就 unset 掉unset HTTP_PROXY unset HTTPS_PROXY然后重新启动 Goose 会话。注意这里只是清理本机环境变量不涉及任何网络工具配置。reading choices 报错。错误文本Error from mcp-server: Stdio process error: npm error code ERR_INVALID_URL npm error Invalid URL这个通常出现在 Selenium MCP 启动阶段原因是 WSL 里 Node 版本太旧或者 npx 缓存损坏。解法是先确认node -v在 18 以上然后清 npx 缓存npx clear-npx-cache再重新goose session。如果还不行手动跑一次npx -y angiejones/mcp-selenium看它自己报什么错这样能把问题定位到 MCP 服务器本身还是 Goose 的调用层。OAuth 相关报错。错误文本Error: OAuth token expired or invalidGoose 某些扩展会走 OAuth 授权如果你之前授权过但 token 过期会报这个。解法是删掉 Goose 的凭据缓存通常在~/.config/goose/下有个credentials.json或者类似文件删掉后重新启动会话按提示重新授权。如果你用的扩展不需要 OAuth检查 config.yaml 里是不是误加了auth字段。扩展加载失败但没明显报错。现象是goose session启动后输入提示词Goose 说「我没有可用的浏览器工具」。这通常是扩展没加载成功。检查 config.yaml 的extensions缩进是否正确YAML 对缩进敏感。另外确认npx在 Goose 的运行环境里能找到WSL 里用which npx确认路径。动态元素找不到。这个不算报错但会导致用例失败。Goose 会尝试多种定位策略但如果元素在 iframe 里或者需要等待异步加载它可能失败。解法是在提示词里加一句「等待页面加载完成后再操作」或者让 Goose 先find_element确认存在再点击。实测中OrangeHRM 的休假余额验证就遇到过这个问题动态数字刷新导致文本匹配失败后来改成匹配元素存在而不是精确文本就稳了。排障的核心思路是分层先确认模型通TaoToken 侧再确认 MCP 通Selenium 侧最后确认用例逻辑。每一层都有对应的验证命令别跳步。6. 把这条链路用起来接入文档与长期编码的选择跑通一次之后你可能会想把它固化下来。我的建议是分两步走先用模型对话页面验证模型能力再把 Goose Selenium MCP 接到日常回归里。如果你还在调模型参数、试不同模型对用例规划的影响可以直接去 https://taotoken.net/models 做对比测试。那里能快速切换模型看同一个提示词在不同模型下的执行路径差异。我试过用不同模型跑同一个 OrangeHRM 用例有的模型会先点 PIM 再找 Add 按钮有的会直接找 Add 按钮路径不同但都能到终点。选一个稳定的再写进 Goose 配置。接入文档在 https://taotoken.net/doc 里面有 Base URL、鉴权方式、模型列表的说明。配置 Goose 的时候对照着看能少踩很多坑。特别是 Base URL 的拼接规则文档里写得很清楚别自己猜。如果你打算把这条链路长期用在编码和 Agent 场景里比如让 Goose 不只跑测试还帮你改测试脚本、生成用例那可以考虑 Coding Plan。入口在 https://taotoken.net/coding-plan 适合需要长期稳定调用、跑批量任务的场景。我自己的用法是日常冒烟用按量批量回归和 Agent 长会话用 Coding Plan成本可控。最后说一个实用技巧把 Goose 的会话输出重定向到文件方便回溯。goose session --input test_case.txt | tee test_run_$(date %Y%m%d_%H%M%S).log这样每次跑的完整命令链和断言结果都存下来了出问题能直接翻日志不用凭记忆复现。这个习惯帮我省了不少排查时间。整条链路搭下来最花时间的其实是环境准备尤其是 Windows 走 WSL 那一段。但一旦跑通后面改用例就是改文本文件的事。AI Agent 做自动化测试现在还不完美动态元素、复杂断言照样会翻车但作为冒烟和回归的补充它已经能干活了。你先按第三节的配置跑一遍遇到报错翻第五节基本能覆盖大部分情况。