Token 优化实战：Trace 与 Lighthouse 响应策略

Token 优化实战：Trace 与 Lighthouse 响应策略

学习目标

本章学习 Chrome DevTools MCP 在性能分析（Trace）和审计（Lighthouse）工具中的 Token 优化实现。你将理解：

• Trace 数据从录制到摘要的完整处理链路
• Insight 提取算法如何将大 Trace 拆解为可管理的子问题
• Lighthouse 报告的摘要化策略
• 分页机制在大数据量场景中的应用

前置知识

• Token 优化与 Agent 响应策略 — 四种 Token 优化策略

---

项目实践

Trace 录制 → 摘要 → Insight 三级提取

Chrome DevTools MCP 的性能工具组（performance_start_trace、performance_stop_trace、performance_analyze_insight）实现了三级信息提取：

第一级：Trace 摘要（getTraceSummary）

当 performance_stop_trace 完成录制后，系统调用 getTraceSummary(trace) 生成包含以下内容的摘要：

• Core Web Vitals（LCP、INP、CLS）数值与评级
• 关键事件时间线（FCP、LCP、DOMContentLoaded 等）
• 主线程阻塞时间汇总
• 网络请求统计

第二级：Insight 提取（getInsightOutput）

Chrome DevTools 前端内置了多个 Insight 检测器，每个 Insight 聚焦一个具体性能问题：

Insight 名称	关注点	输出示例
LCPBreakdown	LCP 元素分解	”LCP 元素是图片，加载时间中网络延迟占 60%“
INPBreakdown	交互延迟来源	”INP 耗时 400ms，其中 JavaScript 执行占 300ms”
CLSBreakdown	布局偏移来源	”CLS 0.25 主要由 导致”
RenderBlocking	渲染阻塞资源	”3 个 render-blocking 资源，总计延迟 800ms”

每个 Insight 的输出约 200 Token，Agent 可以按需调用 performance_analyze_insight 深入查看特定问题。

第三级：完整 Trace 数据

如果 Agent 需要原始数据（如调试特殊问题），Trace 数据存储在 McpContext.#traceResults 数组中，可通过工具响应中的文件路径访问。

Lighthouse 报告摘要化

lighthouse_audit 工具的响应经过摘要处理（LighthouseData.summary）：

// 摘要结构
{
  summary: {
    mode: "navigation",
    device: "desktop",
    url: "https://example.com",
    scores: [
      { id: "performance", title: "Performance", score: 0.85 },
      { id: "accessibility", title: "Accessibility", score: 0.92 }
    ],
    audits: { failed: 3, passed: 45 },
    timing: { total: 12000 }
  },
  reports: ["/tmp/lighthouse-report.html"]
}

关键设计决策：

• 只返回分数摘要，不返回完整的 LHR（Lighthouse Result）——完整 LHR 可达数万行
• 报告文件通过 reports 字段返回路径，Agent 可读取完整详情
• 摘要中的 audits.failed 计数让 Agent 快速判断严重程度

分页机制：网络请求与控制台消息

list_network_requests 和 list_console_messages 使用分页控制响应大小：

// 参数设计
{
  pageIdx: zod.number().int().optional().describe("Page number (0-based)"),
  pageSize: zod.number().int().optional().describe("Max items per page"),
}

实现细节：

• 默认 pageSize = 50（在工具描述中注明）
• 网络请求通过 NetworkCollector 按页提取
• 控制台消息通过 ConsoleCollector 按页提取，支持按类型过滤（log、error、warn）
• Agent 可根据返回数量判断是否需要翻页

设计取舍

取舍	选择	原因
Trace 摘要 vs 完整 Trace	摘要优先	Agent 90% 的场景只需摘要
Insight 分拆 vs 整体报告	分拆	让 Agent 按需查看，不浪费 Token
Lighthouse 完整 LHR vs 摘要	摘要 + 文件引用	摘要满足快速判断，文件满足深入分析

陷阱与对策

陷阱	后果	对策
在 Trace 录制期间打开太多页面	Trace 数据膨胀	建议 Agent 在录制前关闭无关标签页
Lighthouse 在节流模式下运行过慢	超时	默认 30 秒超时，Agent 可调整
网络请求列表不分页	响应过大，Token 耗尽	始终设置 pageSize 默认值
Insight 提取失败（Trace 数据不完整）	空 Insight	返回 “no data available” 而非空响应

参考来源

• Chrome DevTools Performance Panel
• Lighthouse Architecture