AI 编码 Agent 缺少线上崩溃上下文？用 xcrashlytics 把 Crashlytics 带进终端
AI 编码 Agent 能读代码、跑测试，却未必知道线上用户正在遇到什么崩溃。开发者往往要在 Firebase 控制台里搜问题、复制堆栈，再把版本影响手工贴进对话；上下文断在了监控平台和代码仓库之间。
xcrashlytics 是一个面向 macOS 的命令行工具，用于查询 Firebase Crashlytics 数据，也能读取已下载到本机的 Xcode Organizer 崩溃报告。它的定位不是替 Agent 自动修 bug，而是把崩溃证据以终端输出和 JSON 形式交给开发者或编码 Agent。项目 README 标注 MIT 许可证、Swift 6.0 和 macOS 15+；Firebase CLI 是其安装和认证流程的一部分。
从问题到证据：先搜，再看影响
安装后，在应用仓库初始化配置并扫描应用：
firebase login xcrashlytics init --scan xcrashlytics issues --limit 10
扫描会发现应用并写入 .xcrashlytics.json；若检测到多个应用，可通过 xcrashlytics use 选择配置。工具复用 Firebase CLI 登录，不要求额外配置 gcloud。
调查某个功能最近的异常，可以按关键词和时间范围查找：
xcrashlytics issues "checkout" --since 7d xcrashlytics show FB-ISSUE_ID xcrashlytics breakdown FB-ISSUE_ID --by version --since 30d
这三步分别回答“哪些问题与 checkout 有关”“崩溃信息和堆栈是什么”“哪些版本及多少用户受到影响”。版本、操作系统和设备都可用于 breakdown。README 特别区分精确报告计数与抽样分析：issues、breakdown 用于报告总量；blame 和按用户筛查则基于抽样事件，不能把抽样排名当成精确总数。
给 Agent 可复用的结构化输出
交互式终端输出适合人工排查；自动化和 Agent 工作流可请求 JSON：
xcrashlytics issues --since 7d --format json xcrashlytics events FB-ISSUE_ID --latest --app-frames-only --format json
成功结果包含 schemaVersion、data 和 warnings，错误结果包含稳定的 error.code 与提示。issues、events、blame 和 breakdown 也支持逐行 NDJSON。实际接入时，提示 Agent 先检查 warnings，再把版本范围、事件计数和堆栈片段纳入分析；不要仅凭一个异常标题就认定根因。
项目还提供 export 将调查结果导出为 Markdown，便于放入工单或团队讨论。不过导出报告可能包含堆栈和日志，公开分享前仍需检查敏感信息。README 说明导出会排除用户 ID、自定义键、日志和 breadcrumbs，但崩溃消息与源码帧仍需谨慎处理。
iOS 本地报告与边界条件
对于 iOS，工具可以读取已由 Xcode Organizer 下载的 App Store 或 TestFlight 报告，不需要为此连接 Apple 服务：
xcrashlytics issues --xcode xcrashlytics groups --xcode
本地报告会分配 XC- ID，可继续用于 show、export 和 open。Firebase 堆栈若缺少 Apple 二进制符号，可提供对应构建的 dSYM；但 Firebase 事件没有二进制 UUID，因此工具会提示 DSYM_UNVERIFIED，开发者必须自己确认 dSYM 与构建匹配。
使用前还要了解几个限制：Crashlytics 数据保留期为 90 天，--since 最长也只能查询 90 天；Firebase 命令使用尚无兼容性保证的 v1alpha API，服务端变化可能要求更新 CLI。该项目只负责检索证据，不会自动诊断或修复代码。
如果团队已经在使用 Firebase Crashlytics，xcrashlytics 的价值在于减少“监控控制台→复制粘贴→Agent 对话”的切换，把可核查的线上事实带回终端。建议先从只读的 issues 与 show 工作流开始，再把结构化结果接入 Agent；让模型基于证据提出假设，而不是让它凭空猜测生产故障。