用 PostHog 探索 LLM 成本从总花费、模型/用户/链路分解到回归告警的完整实战指南【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthogPostHog 会在采集ingestion阶段为每一条$ai_generation与$ai_embedding事件附加逐调用per-call的成本元数据因此一切成本问题最终都归结为对这两类事件的一次聚合查询——差异只在于你如何分组、过滤和对比。本指南以 exploring-llm-costs SKILL 及其六份引用参考文档为主体结合仓库内 AI 可观测性后端的真实实现系统讲解如何在 PostHog 中统计总花费、按模型/供应商/用户/链路/自定义维度拆分成本、分析 token 与缓存命中经济学、排查成本突增regression并把结论固化到 Insight、Dashboard 与 Alert 中。读完你就能针对“我们在 LLM 上花了多少钱”“哪个模型/用户/功能最贵”“成本为什么飙升”这类问题直接给出可复现的 SQL 与 MCP 工具调用方案。成本数据的核心模型成本属性与事件集规则所有成本都以美元USD计价在采集时按事件逐条写入。PostHog 根据「模型 供应商」与 token 数量推导成本——你不能手工设置并指望它长期可信。成本属性只存在于$ai_generation与$ai_embedding两类事件上完整属性见 cost properties 参考文档。属性出现位置含义$ai_total_cost_usdgeneration、embedding单次调用的权威总成本rollup 时必须用它$ai_input_cost_usdgeneration、embedding输入 token 产生的成本$ai_output_cost_usdgeneration、embedding输出 token 产生的成本$ai_request_cost_usdgeneration、embedding每次请求的固定费用如 Anthropic 的 per-request fee通常为0$ai_web_search_cost_usdgeneration、embeddinggeneration 内部 web-search 工具调用的成本通常为0$ai_audio_cost_usdgeneration模型按单独费率计费的音频模态成本通常为0$ai_image_cost_usdgeneration图像模态成本通常为0$ai_video_cost_usdgeneration视频模态成本通常为0$ai_input_tokensgeneration、embedding发给模型的 token跨模态总计$ai_output_tokensgeneration模型返回的 token跨模态总计$ai_total_tokensgeneration、embedding输入 输出 token$ai_cache_read_input_tokensgeneration由供应商提示词缓存prompt cache命中的输入 token$ai_cache_creation_input_tokensgeneration写入供应商提示词缓存的输入 token$ai_reasoning_tokensgeneration推理模型的思考 token按输出计费$ai_modelgeneration、embedding成本的首要分解维度$ai_providergeneration、embedding次要分解维度openai、anthropic…$ai_is_errorgeneration在成本汇总中排除/包含失败调用$ai_trace_id所有$ai_*事件把成本汇总到链路trace层级$ai_session_id所有$ai_*事件把成本汇总到会话层级把相关 trace 分组汇总时永远 sum$ai_total_cost_usd不要加和分量在采集阶段$ai_total_cost_usd input output request web_search加上任何模态成本。只对$ai_input_cost_usd $ai_output_cost_usd求和会悄悄丢掉 request 费用和 web-search 费用——对 Anthropic 的请求费以及任何带工具增强的 generation 而言这两项真实且非零。UI 中的成本单元格正是按event IN ($ai_generation, $ai_embedding)对$ai_total_cost_usd求和请与它保持一致。这一点在仓库后端也有实现印证AI 可观测性仪表盘模板在构建 Total cost (USD) 与 Cost per user (USD) 看板瓦片时均以$ai_generation事件配合math: sum、math_property: $ai_total_cost_usd聚合见 dashboard_templates.py。事件集规则trace 与 evaluation 事件$ai_trace与$ai_span事件不携带可汇总的成本。要得到某条 trace 的总成本需按其$ai_trace_id匹配对其下的$ai_generation与$ai_embedding事件的$ai_total_cost_usd求和。部分 SDK 封装器会出于便利把$ai_total_cost_usd复制到$ai_trace上但查询执行器依然只按event IN ($ai_generation, $ai_embedding)聚合——不要把事件集混用否则会重复计数。$ai_evaluation事件也会输出成本属性采集时与$ai_generation、$ai_embedding一同计费但内置的/ai-observability汇总与查询执行器不把它们计入成本。只有当用户明确要“含评估的总花费”时才把$ai_evaluation显式加进事件过滤如event IN ($ai_generation, $ai_embedding, $ai_evaluation)并说明这是扩展口径否则保持 generation embedding 以对齐 UI。用户维度distinct_id是规范的用户维度——客户通常在 SDK 中设置它。需要更丰富的按用户拆分时使用人员属性如email、company_tier先通过posthog:read-data-schema探查存在哪些属性不要凭空猜测名字。成本从哪来三种来源路径与诊断查询成本可以通过三种方式到达事件上采集端按以下优先级应用权威规则见 PostHog 官方文档 Calculating LLM costs预计算passthrough——SDK/手工采集直接设置$ai_input_cost_usd、$ai_output_cost_usd、$ai_request_cost_usd、$ai_web_search_cost_usd。采集端原样保留并把$ai_total_cost_usd填为它们的和。适用于调用方已知成本的情形。自定义定价custom——SDK 设置$ai_input_token_price/$ai_output_token_price必选成对可选$ai_cache_read_token_price、$ai_cache_write_token_price、$ai_request_price、$ai_web_search_price。采集端乘以 token 数得到成本。Token 价格是“每 token”单价不是每百万 token。自动模型匹配自动查找——采集端按$ai_model$ai_provider查价优先 OpenRouter其次手工表兜底。三个元数据属性可以告诉你走了哪条路径——成本看起来不对时先读它们详见 cost sources 参考文档属性含义$ai_model_cost_used定价查找命中的规范模型 id可能不同于$ai_model$ai_cost_model_sourceopenrouter|manual|custom|passthrough$ai_cost_model_provider查找所使用的供应商诊断按模型和来源统计零成本/空成本调用当某个模型的$ai_total_cost_usd为 null 或 0 时同时按模型和$ai_cost_model_source分组才能看清每个模型的零成本调用分别来自哪条采集路径只有source NULL的行说明采集端从未匹配到定价条目修复方式添加自定义定价或修正$ai_model/$ai_providersource custom且成本为 0 则是显式配置的零价格通常是$ai_input_token_price/$ai_output_token_price配错。不按来源分组时这两种情况看起来完全一样。posthog:execute-sql SELECT properties.$ai_model AS model, properties.$ai_cost_model_source AS source, count() AS calls, countIf(toFloat(properties.$ai_total_cost_usd) 0 OR properties.$ai_total_cost_usd IS NULL) AS zero_cost_calls FROM events WHERE event $ai_generation AND timestamp now() - INTERVAL 7 DAY GROUP BY model, source ORDER BY zero_cost_calls DESC三条核心规则大部分出错场景都被三条规则覆盖原文见 SKILL.mdRollup 用$ai_total_cost_usd求和绝不用分量相加。分量会漏掉 request 与 web-search 费用。UI 的成本单元格就是按event IN ($ai_generation, $ai_embedding)对$ai_total_cost_usd求和照做即可。完整属性与理由见 cost properties。成本查询务必同时包含$ai_generation和$ai_embedding除非项目可证明不使用 embedding——漏掉它们会静默少算。$ai_trace和$ai_span不携带可汇总成本部分 SDK 封装器会把$ai_total_cost_usd复制到$ai_trace所以不要把它纳入 rollup否则会重复计数。永远设置时间范围。没有时间范围的成本查询会扫描整张 events 表。$ai_total_cost_usd在采集时经由三条路径之一写入passthrough / custom / 自动查找。当成本看起来不对时先读$ai_cost_model_source见 cost sources 的优先级规则与诊断查询。缓存命中的数学计算取决于供应商对缓存 token 的报数方式包含于$ai_input_tokens或独立于它。永远按事件级标志$ai_cache_reporting_exclusive分支不要按供应商名字硬编码——公式见 cache accounting。distinct_id是规范用户维度。客户常附加自定义属性feature、tenant_id、workflow_name——分组前先用posthog:read-data-schema探查它们不要猜名字。工作流一统计时间窗口内的总花费posthog:execute-sql SELECT round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS total_cost_usd FROM events WHERE event IN ($ai_generation, $ai_embedding) AND timestamp now() - INTERVAL 30 DAY工作流二成本分解breakdown每个成本问题都是同一个模板的变体——按某个维度分组、对$ai_total_cost_usd聚合。breakdown patterns 参考文档 提供了七类可直接运行的 SQL 配方按天看成本随时间变化Cost over time按模型看成本Cost by model按用户看成本Cost by user头部消费者按链路看成本Cost by trace最贵链路按自定义维度看成本Cost by custom dimension单次调用成本分布Cost per call输入 vs 输出 vs 缓存经济学Input vs output vs cache economics按天看成本附 token 与调用量posthog:execute-sql SELECT toDate(timestamp) AS day, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd, sum(toInt(properties.$ai_input_tokens)) AS input_tokens, sum(toInt(properties.$ai_output_tokens)) AS output_tokens, count() AS calls FROM events WHERE event IN ($ai_generation, $ai_embedding) AND timestamp now() - INTERVAL 30 DAY GROUP BY day ORDER BY day按模型看成本posthog:execute-sql SELECT properties.$ai_model AS model, properties.$ai_provider AS provider, count() AS calls, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd, round(avg(toFloat(properties.$ai_total_cost_usd)), 6) AS avg_cost_per_call, sum(toInt(properties.$ai_input_tokens)) AS input_tokens, sum(toInt(properties.$ai_output_tokens)) AS output_tokens FROM events WHERE event IN ($ai_generation, $ai_embedding) AND timestamp now() - INTERVAL 30 DAY GROUP BY model, provider ORDER BY cost_usd DESC按用户看成本头部消费者注意排除distinct_id被默认成 trace id 的行——部分 SDK 在没有设置用户时会把 distinct_id 默认成 trace IDposthog:execute-sql SELECT distinct_id, count() AS calls, countDistinct(properties.$ai_trace_id) AS traces, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd FROM events WHERE event IN ($ai_generation, $ai_embedding) AND timestamp now() - INTERVAL 30 DAY AND ( properties.$ai_trace_id IS NULL OR distinct_id ! properties.$ai_trace_id ) -- 过滤掉 distinct_id 被默认成 trace id 的行 GROUP BY distinct_id ORDER BY cost_usd DESC LIMIT 25想要更丰富的按用户视图带人员属性/ai-observability/users页面本身就是这个形态——先去看看它再决定是否手写。按链路看成本最贵链路posthog:execute-sql SELECT properties.$ai_trace_id AS trace_id, count() AS llm_calls, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd, sum(toInt(properties.$ai_input_tokens)) AS input_tokens, sum(toInt(properties.$ai_output_tokens)) AS output_tokens, min(timestamp) AS started_at FROM events WHERE event IN ($ai_generation, $ai_embedding) AND timestamp now() - INTERVAL 7 DAY AND isNotNull(properties.$ai_trace_id) GROUP BY trace_id ORDER BY cost_usd DESC LIMIT 25然后用posthog:query-llm-trace深入最贵的几条链路看哪些 span 与 generation 在驱动成本。按自定义维度看成本客户常附加自己的维度feature、tenant_id、workflow_name。先探查、再分组posthog:read-data-schemakind: event_properties、event_name: $ai_generation找出自定义键posthog:read-data-schemakind: event_property_values抽查取值是否正确按发现的属性分组posthog:execute-sql SELECT properties.feature AS feature, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd, count() AS calls FROM events WHERE event IN ($ai_generation, $ai_embedding) AND timestamp now() - INTERVAL 30 DAY AND isNotNull(properties.feature) GROUP BY feature ORDER BY cost_usd DESC不要猜自定义属性的名字——它们因项目而异。单次调用成本分布用分位数看偏态总和会掩盖偏态。用分位数看是否少数调用占大头posthog:execute-sql SELECT properties.$ai_model AS model, round(quantile(0.5)(toFloat(properties.$ai_total_cost_usd)), 6) AS p50_cost, round(quantile(0.95)(toFloat(properties.$ai_total_cost_usd)), 6) AS p95_cost, round(quantile(0.99)(toFloat(properties.$ai_total_cost_usd)), 6) AS p99_cost, round(max(toFloat(properties.$ai_total_cost_usd)), 6) AS max_cost FROM events WHERE event $ai_generation AND timestamp now() - INTERVAL 7 DAY GROUP BY model ORDER BY p99_cost DESC输入 vs 输出 vs 缓存经济学输出 token 通常比输入贵 3–5 倍缓存读约是输入的 10%。拆分花费以找到优化目标posthog:execute-sql SELECT properties.$ai_model AS model, round(sum(toFloat(properties.$ai_input_cost_usd)), 4) AS input_cost, round(sum(toFloat(properties.$ai_output_cost_usd)), 4) AS output_cost, round(sum(toFloat(properties.$ai_request_cost_usd)), 4) AS request_cost, round(sum(toFloat(properties.$ai_web_search_cost_usd)), 4) AS web_search_cost, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS total_cost, sum(toInt(properties.$ai_input_tokens)) AS input_tokens, sum(toInt(properties.$ai_output_tokens)) AS output_tokens, sum(toInt(properties.$ai_cache_read_input_tokens)) AS cache_read_tokens, sum(toInt(properties.$ai_cache_creation_input_tokens)) AS cache_write_tokens, round( if( any(properties.$ai_cache_reporting_exclusive) true, sum(toInt(properties.$ai_cache_read_input_tokens)) / nullIf(sum(toInt(properties.$ai_input_tokens)) sum(toInt(properties.$ai_cache_read_input_tokens)) sum(toInt(properties.$ai_cache_creation_input_tokens)), 0), sum(toInt(properties.$ai_cache_read_input_tokens)) / nullIf(sum(toInt(properties.$ai_input_tokens)), 0) ), 3 ) AS cache_hit_rate FROM events WHERE event $ai_generation AND timestamp now() - INTERVAL 30 DAY GROUP BY model ORDER BY total_cost DESCcache_hit_rate使用 cache accounting 中供应商感知的公式——它分支于$ai_cache_reporting_exclusive因此对 exclusive 和 inclusive 两类供应商分母都正确且无需硬编码任何供应商或模型名。若单个模型在不同事件间混用了两种报数风格不常见请在 GROUP BY 里加$ai_cache_reporting_exclusive拆分而不是用any()。排名与汇总请基于total_cost——只加 input/output 分量会丢掉 request 与 web-search 费用并可能与/ai-observabilityUI 产生偏差。如果某模型的request_cost或web_search_cost在total_cost中占比可观那就是另一个优化杠杆例如对话更频繁的供应商、重工具 generation。低cache_hit_rate且该模型支持提示词缓存时提示词结构调整就能显著改变成本。工作流三检查单条链路的成本用户粘贴一条 trace URL 并询问其成本时抓取该 trace 并给出逐事件分解posthog:query-llm-trace { traceId: trace_id, dateRange: {date_from: -30d} }对返回的事件按 span 名或模型分组、对$ai_total_cost_usd求和以定位是哪个步骤驱动了成本。trace 响应已附带totalCost作为便捷字段。工作流四排查成本突增cost regression“我们的 LLM 账单跳涨了——为什么”几乎总是以下四种原因之一调用变多、提示词变大、换了新模型、缓存命中率变化。按顺序排查完整的 5 步剧本见 regression debugging 参考文档。Step 1 — 确认并圈定突增范围按天输出 60 天成本、调用量与单调用均成本对比跳变前后的calls与avg_cost_per_call。调用量翻倍是量的问题单调用成本上升则是提示词、模型或缓存的问题。posthog:execute-sql SELECT toDate(timestamp) AS day, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd, count() AS calls, round(sum(toFloat(properties.$ai_total_cost_usd)) / count(), 6) AS avg_cost_per_call FROM events WHERE event IN ($ai_generation, $ai_embedding) AND timestamp now() - INTERVAL 60 DAY GROUP BY day ORDER BY dayStep 2 — 观察模型组合漂移用 breakdown patterns 的“按模型看成本”配方分别跑跳变前一周与后一周做 diff。新$ai_model值出现、旧值消失都是强信号。Step 3 — 排查提示词膨胀按天模型看平均输入/输出 tokenposthog:execute-sql SELECT toDate(timestamp) AS day, properties.$ai_model AS model, round(avg(toInt(properties.$ai_input_tokens)), 1) AS avg_input_tokens, round(avg(toInt(properties.$ai_output_tokens)), 1) AS avg_output_tokens FROM events WHERE event $ai_generation AND timestamp now() - INTERVAL 30 DAY GROUP BY day, model ORDER BY day, modelStep 4 — 排查缓存退化按天重跑“输入 vs 输出 vs 缓存经济学”配方并跟踪cache_hit_rate。缓存命中率下滑往往跟着一次系统提示词变更使缓存前缀失效。Step 5 — 隔离到功能面确定机制调用变多/提示词变大/新模型/缓存变差后按能区分功能的自定义属性如feature、workflow_name分组找出是哪个表面在作祟再用posthog:query-llm-trace深入一条代表性链路。工作流五物化为 Insight、Dashboard 与 Alert临时查询回答完问题后把它们固化成 Insight打包进 Dashboard或接上 Alert。完整可运行的 JSON 见 materializing 参考文档。保存“按天 LLM 成本”Insightposthog:insight-create { name: Daily LLM cost, query: { kind: TrendsQuery, dateRange: {date_from: -30d}, series: [ { kind: EventsNode, event: $ai_generation, math: sum, math_property: $ai_total_cost_usd }, { kind: EventsNode, event: $ai_embedding, math: sum, math_property: $ai_total_cost_usd } ], trendsFilter: { formula: A B, aggregationAxisPrefix: $, decimalPlaces: 2 } } }两条 series 都必需——漏掉$ai_embedding会静默丢失 embedding 花费。若项目可证明不用 embedding相关窗口内$ai_embedding的count()为 0可去掉 series B 和公式得到更简单的 Insight。做“按用户成本”时加第三条math: dau的 series 并把公式改为(A B) / C。做分解时加breakdownFilterbreakdown: $ai_model或任意其他维度。这与仓库内置模板的结构一致AI 可观测性默认仪表盘的成本瓦片以$ai_total_cost_usd为math_property见 dashboard_templates.py构建自定义看板时照此镜像即可。加入 Dashboard保存 Insight 后用posthog:dashboard-create或-update打包。默认的/ai-observability/dashboard已包含 Cost、Cost per user、Cost by model 瓦片——构建自定义看板时镜像这一结构。设置成本阈值告警posthog:alert-create { insight: insight_id, name: Daily LLM cost over $100, subscribed_users: [user_id], threshold: { configuration: { bounds: {upper: 100}, type: absolute } }, condition: {type: absolute_value}, config: {series_index: 0}, enabled: true }该 Insight 必须是单值趋势查询例如粗体数字的每日成本。subscribed_users必填且至少包含同一团队的一个用户 id。threshold.configuration.type取值absolute或percentagecondition.type取值absolute_value、relative_increase或relative_decrease。如果 MCP 工具拒绝该载荷运行posthog:docs-search搜索 alerts 获取当前 schema——告警 API 可接受的枚举值会变化。构造 UI 链接的规范永远不要手写https://app.posthog.com/...链接。该主机名会丢掉区域region与项目前缀导致用户被重定向到登录页而不是你想要的页面。正确做法优先使用工具返回的规范 URL。query-llm-traces-list和query-llm-trace会返回_posthogUrl——直接展示该值。对单条 trace向该 URL 追加?timestampurl_encoded_iso即该 trace 最早事件的时间返回的链接不带时间戳而没有时间戳时 trace 页面会从某个固定早期日期扫描而不是围绕该 trace 的十分钟窗口。否则用generate-app-url构造链接。它解析正确的区域主机与/project/id/前缀例如https://us.posthog.com/project/2/ai-observability/traces。具体 id 通过params传入绝不内联进路径Dashboardgenerate-app-url {url: /ai-observability/dashboard}Traces 列表按成本排序generate-app-url {url: /ai-observability/traces}Generations 列表generate-app-url {url: /ai-observability/generations}Users 列表按用户成本generate-app-url {url: /ai-observability/users}单条 tracegenerate-app-url {url: /ai-observability/traces/{id}, params: {id: trace_id}}generate-app-url无法表达查询参数所以上面描述的单 trace 链接需要你自己追加?timestampurl_encoded_iso。始终向用户展示一条 UI 链接以便可视化验证。更多实战提示综合 SKILL.md 的 Tips 与参考文档SKILL.md以下提示能显著提升成本分析的准确性永远设置时间范围——没有时间范围的成本查询会扫描整张 events 表。汇总成本时务必把$ai_embedding与$ai_generation一起纳入——embedding 单次很便宜但规模化后会累积。token、成本、模型与$ai_trace_id属性都在events上但消息内容$ai_input/$ai_output_choices只存在于posthog.ai_events表——若需要把内容与成本放在一起看参考 exploring-llm-traces 技能的事件参考。成本在采集时写入——如果$ai_total_cost_usd缺失或为 0先读$ai_cost_model_sourcepassthrough表示 SDK 提供了成本custom表示自定义 token 价格openrouter/manual表示自动查找缺失表示模型未被匹配少见自定义模型、微调模型。用countIf(properties.$ai_total_cost_usd IS NULL)按(model, source)分组排查。自定义定价用的是“每 token”价格不是每百万——如果自定义定价的模型看起来贵/便宜了约 100 万倍那几乎肯定是这个 bug。只有用户明确要求时才从成本汇总中排除报错调用——供应商对很多错误模式照样收费包含它们才是真实的账单。按用户汇总时排除distinct_id properties.$ai_trace_id的行——部分 SDK 在未设置用户时把 distinct_id 默认成 trace ID。成本在 trace 内对$ai_generation$ai_embedding事件可加对$ai_span求和得到 0。$ai_trace可能携带来自部分 SDK 封装器的$ai_total_cost_usd——不要纳入 rollup 以免重复计数。$ai_evaluation事件也带成本但不在 UI 默认 rollup 内只有用户明确要评估花费时才把它算进总账。缓存命中率取决于$ai_cache_reporting_exclusive——按事件级标志分支而非按供应商或模型名。供应商行为与 SDK 版本会漂移该标志是采集端对该具体事件的最终解析结果。回答“X 为什么贵”时同时展示成本与 token 拆分——用户几乎总想知道该压缩提示词、压缩输出还是换模型。构建自定义仪表盘前先确认内置/ai-observability/dashboard瓦片是否已能回答该问题——重复造轮子是浪费。大租户把常用成本查询物化为 Insight 并用insight-query复用一次性查询用 ad-hoc SQL 没问题但在每次看板加载时都重跑它则很昂贵。让这份技能保持不过时供应商的报数行为哪些 token 是 inclusive/exclusive、哪些成本出现在哪里会随时间漂移同一供应商在不同 SDK 版本下也可能不同。为避免腐化分支于事件级标志$ai_cache_reporting_exclusive、$ai_cost_model_source而不是硬编码供应商或模型名——这些标志是采集端对该具体事件的最终解析答案是唯一正确的事实来源。$ai_total_cost_usd对 rollup 始终是权威的——优先用它而不是加和分量后者会随着新成本类别加入而漂移。本文未覆盖的内容新成本类别、定价查找变更、新供应商接入先用posthog:docs-search搜索 calculating costs 或 AI observability不要信任本文件中的硬编码规则。如果发现本技能与 UI 矛盾以 UI 为准并标记本技能需要更新。延伸阅读cost properties —— 完整属性 schema、总成本原理、事件集规则cost sources —— 成本如何在采集时写入附诊断查询cache accounting —— exclusive 与 inclusive 供应商、缓存命中率公式breakdown patterns —— 每种常见拆分的 SQL 配方regression debugging —— 成本突增的 5 步排查剧本materializing —— Insight、Dashboard、Alert 的 JSON 载荷exploring-llm-traces —— 拆解出的贵链路指向的 trace 深查技能后端仪表盘模板实现dashboard_templates.py【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考