如何为多智能体并发会话配置 chrome-devtools-mcp 的 --experimentalPageIdRouting 页面路由【免费下载链接】chrome-devtools-mcpChrome DevTools for coding agents项目地址: https://gitcode.com/GitHub_Trending/chr/chrome-devtools-mcp当多个 agent 或子代理运行在同一个 MCP client 上、并且 client 让它们共享一个 chrome-devtools-mcp server 实例时页面级工具调用默认都作用于“当前选中的页面”两个 agent 同时操作不同标签页会互相串台。Chrome DevTools MCP server 为此提供了页面路由模式用--experimentalPageIdRouting启动 server 后页面级工具会暴露pageId参数每个 agent 传自己正在操作的标签页的pageId工具调用就被路由到对应的页面上去。本文的主路径使用 docs/advanced-usage.md 中 Concurrent sessions 一节的 JSON 配置并用 docs/cli.md 描述的实验性 CLI 做手动验证。适用前提是多数 MCP client 会为每个会话各启动一个 chrome-devtools-mcp server这种场景不需要本文的配置它专门面向“client 跨并发 agent / 子代理共享单个 server 实例”的情况。server 通过npx启动配置中会用到npx -y chrome-devtools-mcplatest。在 MCP client 配置中启用页面路由修改你 MCP client 的 server 配置即mcpServers对应的 JSON 配置在args中加上--experimentalPageIdRouting{ mcpServers: { chrome-devtools: { command: npx, args: [ -y, chrome-devtools-mcplatest, --experimentalPageIdRouting ] } } }这是主路径的完整配置。如果你同时运行多个相互独立的 MCP client 会话并希望每个会话各自启动一个临时的 Chrome profile再追加--isolated可选分支{ mcpServers: { chrome-devtools: { command: npx, args: [ -y, chrome-devtools-mcplatest, --experimentalPageIdRouting, --isolated ] } } }为什么要区分这两种情况默认情况下 server 使用固定的 Chrome user data directoryLinux / macOS 为$HOME/.cache/chrome-devtools-mcp/chrome-profileWindows 为%USERPROFILE%\.cache\chrome-devtools-mcp\chrome-profile该目录在多次运行之间不清空、会被复用且同一时间只能有一个浏览器使用它。--isolated则改用临时 user data directory浏览器关闭后自动清理避免多个独立会话的 server 实例共享同一目录。共享单实例的并发 agent 场景本文主场景不需要--isolated因为所有 agent 本来就用同一个浏览器里的不同标签页。改完配置后重启 MCP client或重启 server 进程使新args生效然后进入验证。路由启用后 pageId 怎么使用启用后页面级page-scoped工具会在入参中要求pageId。docs/tool-reference.md 中对这类参数的统一描述是 “Targets a specific page by ID”并在多数页面级工具navigate_page、take_screenshot、take_snapshot、click、fill、list_network_requests等中标注为required。配合路由使用的典型操作序列用new_page必填url打开一个新标签页可选参数包括background后台打开不置前和timeout。调用list_pages无参数获取当前所有打开页面及其pageId。之后的页面级调用都带上自己的pageId例如navigate_page传pageIdurltake_screenshot传pageId。如需要把某个页面设为后续调用的上下文可用select_page必填pageId。也就是说agent A 和 agent B 各自从list_pages拿到自己的页面 ID 后即使并发调用navigate_page、fill、take_snapshot请求也会各自落在对应标签页上而不是共享同一个“当前选中页”。用 CLI 手动验证路由是否生效docs/cli.md 提供了一个实验性 CLI它作为客户端连到一个后台chrome-devtools-mcpdaemonLinux/Mac 用 Unix socketWindows 用 named pipe。首次调用工具时 daemon 会自动启动同一后台实例在后续命令间复用、保留浏览器状态。安装并确认 CLI 可用npm i chrome-devtools-mcplatest -g chrome-devtools status # check if install worked.CLI 中页面级工具要求把pageId作为第一个位置参数。下面这条验证链路使用文档中的原始命令# 打开一个新页面并查看当前所有页面--output-formatjson 便于程序化处理 chrome-devtools new_page https://example.com chrome-devtools list_pages --output-formatjson # 将 page 1 导航到目标地址 chrome-devtools navigate_page 1 --url https://web.dev # 对 page 1 截图并保存到文件确认结果来自指定页面 chrome-devtools take_screenshot 1 --filePath screenshot.png # 结束时停止后台 daemon chrome-devtools stopchrome-devtools stop会终止后台 daemon 及其浏览器会话只在确认本次验证/会话结束时执行。验证通过的判据chrome-devtools status显示 daemon 在运行list_pages返回各打开页面及其pageId对某个pageId调用navigate_page/take_screenshot后返回结果例如保存的screenshot.png与指定页面的内容一致。如果 CLI 挂起或连接失败先用chrome-devtools stop停掉后台进程再重试需要更详细的日志时设置DEBUG环境变量例如DEBUG* chrome-devtools list_pages另外当--categoryExtensions和--pageIdRouting同时启用时evaluate_script支持用--pageId number指定目标页--serviceWorkerId string则用于指定扩展 service workerchrome-devtools evaluate_script () document.title --pageId 1命名差异与已知限制同一个能力在文档中有两种写法docs/advanced-usage.md 的并发会话一节使用--experimentalPageIdRouting而 docs/configuration.md 自动生成的选项列表中登记为--pageIdRouting/--page-id-routing类型 boolean默认true并说明用--no-page-id-routing关闭。本文按并发会话一节使用--experimentalPageIdRouting示例两种写法均保留原文。pageId启用路由后是页面级工具 schema 中的必填参数agent 侧生成工具调用时必须带上它。close_page无法关闭最后一个打开的页面tool reference 明确说明 “The last open page cannot be closed”。CLI 只支持无需额外参数即可在 MCP server 中使用的工具因此--categoryExtensions类工具目前不在 CLI 中可用且--categoryExtensions本身仅在 pipe 连接下受支持autoConnect、browserUrl、wsEndpoint在其可用前Chrome 149不受支持。完成以上配置并验证后共享单个 server 实例的多个 agent 就能通过pageId各自路由到自己的标签页并发工作后续如需扩展各 agent 的调试手段可参考 docs/tool-reference.md 中的完整工具与参数说明。【免费下载链接】chrome-devtools-mcpChrome DevTools for coding agents项目地址: https://gitcode.com/GitHub_Trending/chr/chrome-devtools-mcp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考