当软件的消费者变成 Agent

软件的消费者正在从人变成 Agent。这件事已经发生了，只是大多数人还没有把它当成一件需要严肃对待的事。

两个数字可以说明变化的速度。Vercel 的 skills.sh 排行榜上，头部 skill 在五个月内积累了约 200 万次安装；MCP 生态的 SDK 月下载量在 2026 年中已经接近一亿次量级。这些数字本身并不重要——重要的是它们背后的含义：Agent 正在成为一类新的软件消费者，而软件行业为人类消费者建立的整套计量体系，对它们几乎全部失效。

这篇文章想讲清楚三件事：旧指标为什么失效，计量为什么必须先于支付，以及一个开放、可验证的计量层为什么是 AI 经济里被所有人跳过、却最终绕不开的基础设施。

一、旧的计量链，在每一环断开

人类软件经济有一套运行了几十年的计量语言：下载、安装、MAU、席位、页面访问、会话时长。这套语言建立在一条隐式链上：

安装 → 可用 → 被展示 → 被选择 → 被使用 → 产生价值

过去几十年，这条链足够好用，因为链上的每一环都对应一个可观测的人类行为。但现在，链上的消费者换成了 Agent——而 Agent 的使用行为，在这条链的每一环上都断裂了：

安装 ≠ 可用。一个 MCP server 被装进配置，不等于 Agent 在任何一次任务里真的调用了它。
可用 ≠ 被展示。Agent 只在它认为相关时才把某个能力纳入候选，这个筛选过程发生在模型内部，外部几乎不可见。
被展示 ≠ 被选择。选择发生在上下文窗口里，是推理的结果，而不是一次可审计的点击。
被选择 ≠ 被使用。调用可能失败、超时、被护栏拦截、被用户撤销。
被使用 ≠ 产生价值。一次成功调用可能什么都没完成，一次失败调用可能已经消耗了最贵的资源。

更麻烦的是，生态里现有的”使用量”信号几乎全部来自自报。skills.sh 的安装数是 CLI 客户端自报的遥测，可刷量、没有公开的统计 API；官方 MCP registry 明确表示不做采纳和使用数据；llms.txt 生态的第三方审计发现，约 3.9 万份声明文件里 97% 从未收到任何 AI 请求——声明了 ≠ 被用了。这些不是个别平台的缺陷，而是整个生态的结构性空白：我们没有任何一套可验证的、统一口径的”Agent 使用量”。

二、计量先于支付

2026 年，支付层正在密集出现：Cloudflare 的 x402 / Agentic Payments、Coinbase 的 Bazaar、OpenAI 与 Stripe 联合发布的 Agentic Commerce Protocol（ACP）。这些协议解决的是同一个问题：Agent 如何为软件能力付钱。

但支付协议们集体默认了一件事：被计费的使用量是可靠的。这是一个危险的默认。你无法为一个无法度量、无法验证的使用行为计费——就像没有电表就没有电费账单。计量（measurement）是计量（metering）的前提，而 metering 是支付的前提。三层必须按顺序建设：

测量（Measure）→ 计量（Meter）→ 支付（Pay）

现在行业里所有人的注意力都在最右端，而最左端——可验证的测量——恰恰是最薄弱、最缺席的一层。x402 能传输”用了 3 次”的凭证，但它无法判断”用了 3 次”是不是真的。这不是支付协议的问题，这是支付协议的地基还没有打。

三、度量什么：五段链

AgentMeasure 提议的共同语言是一条五段链：

Reach → Choice → Use → Utility → Value

Reach（触达）：Agent 在多大范围内看到了这个能力？被索引、被检索到、出现在候选里。
Choice（选择）：在候选集中，Agent 选择了什么、为什么？选择时的上下文与约束是什么？
Use（使用）：调用是否发生、是否成功交付？调用了什么、消耗了什么？
Utility（效用）：调用产生了什么结果？对任务的完成是否真的有贡献？
Value（价值）：最终创造了多少可交换的价值？这是唯一直接通往交易的一环。

每一环都需要单独定义、单独观测。把五环混成一个”使用量”数字，等于重新发明一个不可验证的黑箱。

四、证据纪律：可验证性是社会证明的前提

过去两年，开源社区对”AI 使用量”的社会证明需求在快速上升——star、徽章、排行榜，所有人都在寻找”我的项目被 AI 用了吗”的证据。但这类证明的价值完全取决于一件事：可验证性。

star 可以刷，安装可以刷，自报遥测可以刷。可验证的计量不能——如果它带上了观测上下文（Context：这个事件在哪里被观测到——Agent 运行时、网关、还是服务端自报？）和执行有效性（Validity：这次调用真的成功交付了吗？），并且按证据强度分级（E0–E5，从纯自报到可审计的独立观测），它就从”营销数字”变成了”可反驳的事实”。

这恰恰是 AI 经济最稀缺的东西：可反驳的事实。市场、排名、计费、保险，全都建立在这个地基上。

五、为什么必须是开放标准

计量语言不能是任何一家厂商的黑盒。原因很实际：如果度量口径由某个平台私有定义，那么所有依赖它的市场、排行和计费都会变成该平台的佃农；如果口径不可公开审计，整个体系会退回”自报时代”。

所以 AgentMeasure 的路线是：一套开放的数据语言（reach / choice / use / utility / value）+ 测量语义（观测上下文、执行有效性、证据分级）+ 机器可读的 registry 与 conformance 校验，让市场、计量与支付协议可以构建在一个公开、可审计的事实层上。标准化的窗口期就在 2026——AAIF 已经成立，OpenTelemetry 的 GenAI 语义约定还在 development 状态，谁在这个窗口期定义出可验证的”agent 使用量”，谁就拥有下一个 npm 下载量。

六、现在的状态

这一层不是概念。AgentMeasure 仓库里已经有：

CORE 规范（Draft 0.4.3）：测量对象、三层结构、交互类别、可观测四态、指标资格、qualification（Context × Validity）、测量标签与标准不变量；
参考实现：Provider SDK → Canonical Observation → Collector → Metrics 的端到端管道；
Pipeline Validation #001：本地合成流量验证（42 calls → 84 observations，fail-closed 语义在真实管道中的行为；Measurement Report #001 编号预留给第一个外部 Provider）；
Benchmark 草案：如何对生态里的”使用量”声称做证据分级审计；
Conformance：标准与实现之间的校验向量。

1.0 的毕业标准是明确的：两个独立实现、三个 runtime profiles、两个 tool-side 实现、公开 conformance 与测试向量、5–10 个真实项目、已发布的 discrepancy report，以及安全与隐私审查。这不是一个”再写一份规范”的项目，而是一个从规范到实现到验证的完整闭环。

结语

给三类人各留一句话：

给平台团队：你们即将推出的用量统计，如果不可验证，就会成为下一轮信任危机的起点。现在就把口径和证据写进规范。
给开源维护者：star 会贬值，可验证的使用证据不会。把”被 Agent 使用”的证据放进你的 README，而不是再贴一个自报徽章。
给创业者：计量是支付的地基。当所有人都在修支付层时，地基上还没有几块砖——这就是窗口。

软件的消费者正在从人变成 Agent。上一次软件消费者发生变化时，整个行业重新发明了软件经济学。这一次，变化从计量开始。