Chrome DevTools MCP如何让长自动化会话的令牌消耗不失控【免费下载链接】chrome-devtools-mcpChrome DevTools for coding agents项目地址: https://gitcode.com/GitHub_Trending/chr/chrome-devtools-mcpChrome DevTools MCP 是一个让 AI 编码助手控制和检查实时 Chrome 浏览器的 MCP 服务器MCP 是连接 AI 与外部工具的标准协议。当助手反复抓取页面、截图和网络数据时上下文会迅速膨胀成本与延迟随之上升这是长会话的主要痛点。本文拆解该项目内置的输出压缩机制并说明如何在入口、数据流、输出三处调优压低令牌消耗。一个具体的使用场景你的助手已经交互了三轮对话开始变慢了。每问一次看看这个页面完整的截图和整棵无障碍树快照都会进入上下文几百个元素的页面一次快照就是几千字符它再去查网络请求全量请求列表又被塞进来。几轮之后上下文窗口接近打满响应一轮比一轮慢。原因不在工具太重而在于每个工具默认都会返回你没要求的数据。底层机制拆解Chrome DevTools MCP 如何控制令牌消耗实际上项目把 Token-Optimized令牌优化写成了顶层约束返回语义摘要而非原始数据大数据落盘而非内联。docs/design-principles.md 中Reference over Value一条要求重资产只传文件路径。落到代码里有三层实现。入口层收窄工具面每个注册工具的描述和参数定义本身就要占上下文所以减少工具数量是最直接的省法。服务器默认按类别暴露 50 多个工具--category-performancefalse可以整组移除性能工具如果任务只是基础浏览--slim会把工具面收敛到navigate、evaluate、screenshot三个。关键配置项是--slim。数据流层过滤与分页工具被调用后也不是所有返回都要进上下文。列表类工具统一接了过滤 分页管线list_network_requests支持用resourceTypes只返回指定资源类型list_console_messages用types只保留 error 一类消息。内部分页由 src/utils/pagination.ts 实现默认每页 20 条并在响应里附上hasNextPage让 agent 按需翻页而不是一次取全量。关键配置项是pageSize。输出层大文件落盘重型数据遵循传路径、不传数据流的原则。take_snapshot基于无障碍树生成文本快照快照模块 的描述明确写着优先用快照而非截图并且提供filePath参数把快照存盘而不是挂在响应里。performance_start_trace有autoStop参数让追踪自动停止filePath把原始 trace 写到磁盘进入对话的只是哪里慢、为什么慢的语义摘要。截图侧--screenshotFormatwebp比默认 PNG 小约 3 到 5 倍。关键配置项是filePath。端到端实操路径压缩 Chrome DevTools MCP 的令牌消耗先在 MCP 客户端配置的args里收窄工具面例如加入--category-emulationfalse和--headless只保留本次会话要用的类别。然后压缩图片输出追加--screenshotFormatwebp与--screenshotMaxWidth1280让每张截图在进上下文前就被缩放。最后约束取数行为在提示词里明确要求列表类结果只取前 20 条需要时再翻页让 agent 走分页管线。改完重跑同一条调试流程每轮对话的上下文增量应能从上万字符降到几千字符。边界与进阶选项--slim只保留 3 个工具覆盖不了性能追踪、内存分析等需求建议只在简单浏览场景使用。--categoryExtensions、--categoryPwa等类别开关目前仅支持 stdio 直连不兼容--autoConnect与远程调试连接。若你要在手动浏览器和 agent 自动化之间共享登录态优先考虑--browser-url连接已有实例注意调试端口暴露的安全影响已知限制清单见 README.md 的 Known limitations 一节。速查清单核心词Chrome DevTools MCP--slim收敛到 3 个工具--category-*false关整组resourceTypes过滤请求pageSize控制分页filePath大文件落盘【免费下载链接】chrome-devtools-mcpChrome DevTools for coding agents项目地址: https://gitcode.com/GitHub_Trending/chr/chrome-devtools-mcp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考