用途：面向 Amplitude 数据做实时产品问题取证，回答“X 今天是否在触发”“这次发布是否破坏了 Y”“哪些用户受 Z 影响”等问题。
主要能力与用法：典型流程是多工具串联。先用 get_amplitude_context（可带 projectId）获取上下文，不要猜测项目 ID；再用 search_amp_entities 复用已有分析，避免重建；查询前先查看已连接目录，用当前 taxonomy 读取器确认候选事件名称、状态与可查询性，并读取事件、用户或群组属性以获得准确名称和范围，不要猜测名称，否则会返回结构正确但数据为空的图表；用 check_for_recent_event_ingestion 确认事件是否在实时写入，静默事件会让图表始终为空。
量化与定位：用 query_amplitude_data 分批查询，每次一个切片（按版本、原因属性、平台等），而非单个超大查询；优先使用类型化 chart 参数（kind: 'segmentation'，含 events、where/group_by、date_range），由服务端编译并自动做校验与 taxonomy 检查。环境相关问题时对比 prod 与 staging/UAT 项目。用 query_amplitude_data 按用户 ID 分组排名受影响用户，再用 use_amplitude_cohorts action: 'find' 获取完整集合；用 get_amp_user_data include: 'timeline' 按用户重建时间线，可批量调用（单次最多 10 个标识符）。
参数化常见错误：编译错误可自行修复，400 会指出问题字段和修复提示，只需改该字段后重试。常见问题包括相对范围单位与 interval 不匹配、漏斗 conversion_window 缺少单位、使用了该图表类型不支持的过滤操作符（存在性用 set）。date_range 必填，用 {relative: "Last 30 Days"} 或 {start, end} 纪元秒，不能同时使用；小时级间隔窗口上限约 8 天，日级粒度上限约 30 天。每个过滤条件需要合法操作符和匹配的 scope，scope 不匹配说明把用户属性当作事件属性或反之。
报告内容：事件是否触发、量级与首次出现时间；受影响用户数量及活跃用户占比；关键切片（版本、平台、原因属性）；受影响用户证据，包括量级最高的用户和 2–3 条重建时间线。
限制：资料未提供收费、价格、具体平台支持范围及完整官方文档等信息。