🦞 我们是如何开始做 Agent Analytics 的
我曾经每月花 28 美元，只为了在 5 个 side project 上读取 pageview。我要的不是仪表盘，而是让代理把这件事做掉。
我经常用 Claude Code 和 OpenClaw 做很多小项目、工具和落地页。任意时刻，都会有几件东西在线上运行，我想知道它们到底有没有人在用。
真正的问题从来不是“能不能收集数据”，而是“谁来读取这些数据”。
Mixpanel、Amplitude 这类产品当然能做出很漂亮的仪表盘。但我不想为每个项目都开一个 dashboard。我想让代理自己去读数据、总结问题，再告诉我下一步该做什么。
我真正想要的
我需要的是一个分析系统，具备：
- 代理可以直接调用的 API
- 能在任意开发环境里跑起来的 CLI
- 足够轻量的跟踪脚本
- 一种可以同时管理多个项目的方式，而不是每个项目重新维护一套 dashboard 逻辑
换句话说，我要的是 API-first 的分析，而不是 dashboard-first 的分析。
所以我自己做了一个
Agent Analytics 最早只是一个跑在 Cloudflare Workers 上的小项目。它的核心目标很简单：
给 AI 代理一层真正可操作的度量系统。
现在它由四层组成：
- 轻量 tracker：跟踪页面浏览、关键点击、自定义事件和错误
- 以业务问题为中心的 API：统计、趋势、漏斗、留存、实验、拆分视图
- 包住 API 的 CLI：任何能执行
npx的代理都能直接使用 - 教会代理如何做增长的 skill：不只是 API 文档，而是一整套“该跟踪什么、该问什么、何时实验”的工作流
它改变了什么
当我的代理第一次拿到真实分析数据之后，整个工作方式就变了。
它现在可以：
- 自动创建项目
- 给新站点加上跟踪代码
- 在一轮对话里查询所有项目的数据
- 创建并检查 A/B 实验
- 每天早上给我一个“哪些项目有动静”的简报
它不再只是汇报数字，而是能基于这些数字做动作。
增长闭环
真正让我下定决心做 Agent Analytics 的，是“闭环”这件事。
代理已经会写代码、会部署、会改文案，也会发起实验。但“这次改动到底有没有效果”这一环是断掉的。没有一套让代理自然读取结果的测量层，它就只能不停地出手，却无法真正学习。
Agent Analytics 填的就是这个洞。
- 统计告诉你项目是不是在动
- Funnel 告诉你用户卡在哪一步
- Retention 告诉你他们有没有回来
- Experiments 告诉你哪个变体更好
没有这层，代理只是在“高频产出”。有了这层，它才能开始优化。
现在就能用
Agent Analytics 现在已经能通过 ClawHub skill 使用，也可以通过 开源仓库 自托管。
如果你更想直接使用托管版本，可以从 app.agentanalytics.sh 开始。
我们的目标从来不是再做一个仪表盘，而是做一套代理真正能操作的分析层。
