把 DeepSeek Harness（DSH）和 Codex Harness 放在一起看，会看到另一条更激进的路线：未来的软件未必还是一个封装好的 App。模型、Skill、工具、数据、执行环境和界面可以在运行时临时组合，任务结束后，这套组合也可以随之消失。

今天我们打开一个个 App。以后，Agent 可能根据任务临时组装一个”应用”。

这不是给旧软件多装一个聊天框，而是在改变软件的基本单位。

Harness 正在变成新的软件运行时

DeepSeek 对 Agent 的定义很直接：

Agent = Model + Harness

DSH 把模型、工具、Skill、会话、沙箱、存储、Loop、调度和 UI 都做成插件。标准模式、PTC 模式、极简模式和创造模式，背后是不同的运行时组合。创造模式甚至可以检查当前 runtime、在内存中试验插件，再把它们组合成新的 preset。DeepSeek 官方预览页

Codex 走的路径不同，落点却很接近。Codex 的 Web、CLI、IDE 扩展和桌面 App 共用同一套 Harness；App Server 通过双向 JSON-RPC，把 Agent Loop、会话、配置、授权和事件流暴露给不同客户端。外部产品也可以借此嵌入 Codex，而不用重新实现整套 Agent 逻辑。OpenAI：Unlocking the Codex harness

两家公司都在做同一件事：把 Harness 从产品内部的实现细节，变成可复用、可组合的运行时。

DSH 仍处于开发者预览阶段，官方也明确提醒核心插件和 API 还会变化。Codex App Server 同样是快速演进中的平台接口。它们还不是已经定型的行业标准，但方向已经足够清楚。

App 会变成一次运行时组合

传统软件把界面、流程、业务逻辑、数据和执行能力打包在一起：

用户 → App → UI / Workflow / Logic / Data / Execution

Harness-native 软件更像：

用户目标
   ↓
Agent
   ↓
Harness
   ↓
按任务选择 Model / Skill / Tool / Data / UI
   ↓
执行并交付结果

比如用户提出一个任务：

研究大疆最近两年的海外市场变化，给我一份带图表的报告。

Harness 可以临时加载网页搜索、财务数据、视频与论坛检索、PDF 阅读、电子表格、图表生成和报告渲染。它们共同组成一个研究应用。报告交付后，这个组合没有必要继续存在。

这类软件可以叫 Ephemeral Software：为一个任务生成，运行一次或几次，然后消失。

软件不会因此变少。恰恰相反，当开发和组装成本下降，大量过去不值得单独开发的内部工具、个人工具和一次性工具都会出现。减少的可能不是软件数量，而是每一份软件都要变成长期产品的必要性。

SaaS 会被拆包，Workflow 最先承压

今天的 SaaS 通常把五层东西一起卖给用户：

Agent 最容易接管的是 Interface 和 Workflow，因为自然语言正在成为新的交互入口，Harness 又能负责流程编排。

过去，销售要进入 CRM，筛客户、查记录、写邮件、建任务、设 follow-up。以后，他只需要说：

找出过去两周没有跟进、但成交概率最高的 20 个客户。分别写一封邮件，高价值客户先让我确认。

CRM 的大量页面和点击路径会退到 Agent 背后，但客户记录、权限、历史互动、邮件发送和审计日志不会消失。Agent 越能执行任务，越需要这些真实数据和动作接口。

所以 SaaS 面临的不是整齐划一的”死亡”。分化会更明显：

• 靠用户手动操作固定流程创造价值的 Workflow SaaS，风险更高。
• 掌握业务事实的 System of Record，价值可能上升。
• 能完成真实动作的 System of Action，也会变得更重要。

判断一家软件公司是否安全，可以问一个很直接的问题：

Agent 有没有理由绕过它？

如果 Agent 只需要它的 API，不需要它的界面，产品的定价、分发和护城河都要重新算。

软件市场会从 App Economy 转向 Capability Economy

今天，软件行业的基本单位是 Application：Photoshop、Figma、Salesforce、Expedia。

Harness 看到的却是一个个能力：

remove_background()
render_video()
query_customer()
book_flight()
generate_contract()
send_campaign()

应用被拆开后，Agent 要做的是在任务中发现、比较和调用能力。DSH 的插件架构已经把这件事推进到运行时内部；它的 subagent 接口还允许同一上下文注册多个 provider，包括 Codex、Claude Code 和 DSH SDK。DeepSeek Harness：Subagent

Agent 也开始成为另一个 Agent 的 Tool。软件生态不再只是 App Store 里的一排图标，而会逐渐长成一张 Capability Graph：通用 Agent 负责理解目标，专业 Agent 接下子任务，再调用底层工具和服务。

新的分发问题也随之出现。开发者过去研究的是”怎么让人下载我的 App”，以后还要研究”怎么让 Agent 选择我的能力”。

这会催生新的基础设施：Capability Registry、Agent Search、可靠性排名、Eval、归因、支付和声誉系统。

模型很重要，但模型优势不等于应用壁垒

当模型和 Harness 解耦，同一套运行时可以接多个模型：分类交给小模型，代码交给 Coding Model，视觉任务交给 VLM，复杂推理再调用 Frontier Model。

顶级模型仍然有巨大的价值，只是应用不必把全部能力押在单一模型上。Harness 越成熟，应用越容易根据成本、速度和任务类型切换模型。

这会让一批”LLM API + Prompt + Workflow + 漂亮 UI”的应用承压。Agent Loop、工具调用、上下文管理、沙箱、权限、Skill 和 Subagent 正在变成公共基础设施。单纯把这些部件拼在一起，越来越难形成长期壁垒。

AI 应用的壁垒会集中到五种资产

Harness 可以复制工作流，却不能凭空生成真实世界里的资产。未来更值得看的，是下面五件事：

1. 独有的 Context 和 Data：客户记录、案件材料、库存、价格、历史交互。
2. Execution：支付、发货、发邮件、改配置、提交订单等真实动作。
3. Feedback Loop：大量任务结果能否持续改善判断和执行。
4. Permission 和 Trust：用户是否敢授权它处理资金、隐私和高风险操作。
5. Distribution 和 Network：用户、商家、开发者和供需关系是否已经形成网络。

法律 Agent 的价值不会来自一个”很懂法律”的 Prompt，而会来自案例库、客户材料、执业权限、律师网络和案件结果。

电商 Agent 也一样。推荐话术容易复制，商品、库存、价格、支付、物流和售后网络复制起来很慢。

企业 AI 的护城河则会落在企业数据、权限、执行接口、审计和历史结果上。

代码会变便宜，”什么叫正确”会变贵

OpenAI 的 Harness Engineering 实验提供了一个很具体的信号：一个内部 beta 项目的代码库在五个月后达到约百万行，覆盖应用逻辑、基础设施、工具和文档；期间约有 1,500 个 PR 被创建并合并，起初由三名工程师驱动 Codex 完成。OpenAI：Harness engineering

OpenAI 对这项实验的总结不是”程序员消失了”。团队的主要工作从亲手写代码，转向设计环境、表达意图和建立反馈闭环。

代码生成得越快，真正稀缺的东西越往上游移动：

Specification
Architecture
Test
Eval
Policy
Context
Observability
Feedback Loop

实现成本下降，不代表软件工程变简单。工程师要把”正确”写进环境，让 Agent 能检查、修正并持续运行。Harness Engineering 这个名字准确地描述了这种变化。

GUI 不会消失，它会变成 Control Plane

所有软件都变成聊天框，既不现实，也没有必要。

视频时间线、3D 空间、CAD、地图和设计画布依然是高带宽输入工具。Agent 完成任务后，人也需要检查、比较、修改和确认结果。

GUI 更大的变化，是操作层逐渐让位给控制层：

• Agent 正在做什么？
• 它用了哪些数据？
• 花了多少钱？
• 为什么做这个决定？
• 哪些动作需要批准？
• 失败发生在哪里？

工作台不会消失，但它的重心会从 Workspace 移向 Control Plane。

商业模式会从 Seat Economy 转向 Machine Economy

SaaS 按 seat 收费，是因为人在操作软件。Agent 成为主要操作者后，一个 Agent 可能替代大量页面操作，同时产生远高于人的 API 调用量。

计价方式会逐渐向 Usage、Transaction、Outcome、Compute、Data 和 Agent Action 移动。

这不一定降低 SaaS 的收入。一个人一天打开 CRM 20 次，一个 Agent 可能调用接口 20,000 次。软件消费没有消失，消费者从人变成了机器，定价单位也要跟着变。

接下来值得关注的五个位置

未来三到五年，最有机会的可能不是另一个 Chat UI，而是五个基础位置：

• Agent Runtime / Harness Infrastructure：让 Agent 长期稳定运行。
• Context Infrastructure：让 Agent 获得正确、可更新的长期上下文。
• Capability Economy Infrastructure：帮助 Agent 发现、购买和调用服务。
• Trust / Eval / Observability：判断 Agent 和 Tool 是否可靠。
• Vertical System of Action：控制行业数据、执行能力和反馈闭环，直接交付结果。

最后一类的市场可能最大。AI 招聘、法务、财务、电商运营、市场研究、软件开发、内容生产和客服，最终比拼的都不是”谁做了一个行业 Agent”，而是谁掌握了 Agent 完成任务时绕不开的数据、权限、动作和结果。

软件的第一用户，正在从人变成 Agent

过去，人是用户，软件是工具。

现在，人还是用户，Agent 是助手，软件继续当工具。

再往前走一步，人只负责提出目标，Agent 会成为软件的直接使用者：

Human → Goal → Agent → consume Software

这才是 DSH 和 Codex Harness 释放出的真正信号。Coding Agent 变强只是表面变化，底层变化是”Agent 作为软件第一用户”的基础设施开始成熟。

Harness 会把 Agent 平台化，Agent 会吸收大量 Workflow。传统 App 随后被拆成 Experience、Context、Capability 和 Execution。

以后最有价值的软件公司，未必拥有界面最完整的 App。它可能只拥有一项能力，但那项能力掌握真实数据、可以执行关键动作，而且 Agent 无法绕开。

事件事实以 @elliwoodtong 的 X 记录 为准（2026-08）：Upsider 是一个运行在 X 上的 AI Agent，它评估了与我的账户之间的交互，然后自动向我的链上地址发送了 token。本文区分事实与判断：事实标注来源，判断明确标注。

发生了什么

一个叫 Upsider 的 Agent，在 X 上评估了与我的交互，然后自动给我转了 token。

金额多少、几点几分、从哪个地址到哪个地址，全在链上，谁都能查。这不是人类代付，是 Agent 自己跑完了整条流程：

评估交互 → 判断价值 → 决定奖励 → 执行结算

中间没有任何一步需要人点头。按我的证据阶梯（E0–E5），这笔转账本身是 E4——链上可验证、可交叉核对。这是 Agent 经济里我见过的最硬的一笔事实。

但注意，硬的部分止步于「钱」。

两半

这笔转账把 Agent 经济劈成了两半。

一半是结算：谁付给谁、多少、何时。区块链把这一半变成了可验证的事实，谁也赖不掉。

另一半是归因：奖励的是什么？为什么值这个价？对接收方是不是真实效用？

链上回答不了这三个问题。

支付可验证，价值不可归因。

这句话是我对 Upsider 事件最核心的判断。它不只是对一笔转账的描述，而是对当前整个 Agent 经济结构的描述。

链条

把 Upsider 的流程拉直，是六段：

Interaction → Evaluation → Decision → Reward → Settlement → Outcome

交互、评估、决策、奖励、结算、结果。

我把这六段和我们站内的计量语言对齐一下（AgentMeasure 五段链）：Reach → Choice → Use → Utility → Value。

• Settlement 对应 Value 的结算侧，有基础设施：链、代币、支付轨道。
• Evaluation 和 Decision 对应 Choice/Use 之间的判断，没有计量语义：什么叫一次值得奖励的交互，评价标准是什么，单位是什么，没人定义。
• Outcome 是最终结果：这笔奖励对接收方产生了多少效用，无法验证，甚至没有人在采集。

六段链条，前四段的语义是空的，第五段有基础设施，第六段没人管。

这不是 Upsider 一家的问题，是结构性的。

为什么这是重大信号

第一，Agent 成为经济主体，不再是比喻。

此前「Agent 经济」大多还停留在 API 调用、按量计费、人代付。Upsider 是第一次我亲眼看到：Agent 自己评估、自己判断、自己决策、自己结算，钱真的动了。它不是模拟，是真实结算。

第二，支付先于计量到来了。

我们在 创刊号 里写过「计量先于支付」：没有可靠计量，就无法比较、定价与结算。Upsider 给出的是反例，或者说，是时间差：支付来了，计量缺席。钱已经开始流动，但没人能说清这笔钱对应的效用是什么。

第三，和 x402 是同一件事的两面。

上一篇文章 审计过 x402「结算第 1.62 亿笔支付」的声称，结论是：支付轨道正在建在没人能验证的数字之上。Upsider 是小规模样本，x402 是支付轨道本身。规模差几个数量级，缺口是同一个：单位未定义，效用不可验证。

当 Agent 开始自己付钱，真金白银会流过没人能验证的计量语义。这不再是分析问题，是财务完整性问题。

判断

• 结算侧会继续指数级扩张。 链上支付、代币奖励、Agent 托管钱包，这些基建已经很成熟，Upsider 只是第一个让我注意到的例子。
• 计量侧会在未来 12 个月成为兵家必争之地。 谁先定义「一次有价值交互」的单位、公开口径、让第三方可以重放验证，谁就拿到了 Agent 经济的会计标准。
• AgentMeasure 的路线被验证了，但节奏要加快。 计量先于支付，没错；但现实是支付不等计量。缺的已经不是论据，是能落地的单位定义与观测规范。

下一步

我把 Upsider 事件记入 Agent Capability Index 的月度跟踪信号，下一期 Agent Capability Monthly 会把它放进 Top 5 signals。

如果你也在做 Agent 支付、代币奖励或 Agent 计量，欢迎来 AgentMeasure 讨论区 对口径。这条链上的每一段，都需要定义，需要观测，需要能被第三方重放。

结算已经有基础设施了。计量语义，还空着。

Agent Capability Monthly is a fixed monthly report answering one question: as agents become software consumers, what is happening to the software economy. The structure is fixed in eight sections: new capabilities, new providers, pricing changes, MCP/Skills ecosystem, agent commerce, measurement developments, top 5 signals, Roy’s view.

Issue 01 is the baseline issue: it does not chase this month’s news. It fixes the ecosystem’s current state, the measurement method, and the data definitions that every future issue reports deltas against. Facts carry sources and dates; judgments are labeled as judgments.

0. Why a monthly report is needed now

As software consumers shift from humans to agents, the old measurement chain (installs, seats, page views) breaks at every link, and no stable discourse for the new measurement layer exists yet. The industry conversation is fragmented: some talk about protocols, some about tools, some about payments, some about observability. This report does one thing: record the ecosystem with a fixed vocabulary so that change becomes visible.

Two factual foundations of the baseline:

• Agent Capability Index (public map): 106 entries / 11 categories of agent-invocable software, v0.1 seed data with provider, interface, pricing, availability, and source.
• AgentMeasure (open measurement infrastructure): the five-stage chain Reach → Choice → Use → Utility → Value, evidence grading E0–E5, observation context Context × execution validity Validity.

1. New capabilities

Baseline definition: a Capability is a single capability of software that an agent can invoke — not the whole app. Inclusion criteria: public documentation, a verifiable interface (API / CLI / SDK / MCP / self-hosted), and a stated pricing model.

Baseline distribution (106 entries):

Judgment: Payments and Real-world Action are the smallest and most unstable categories (partner-gated APIs, opaque pricing). This is the data-layer reflection of the measurement-before-payment gap — the capabilities closest to money are the ones with the least public accounting.

2. New providers

Baseline definition: a provider is an organization offering at least one invocable capability. v0.1 skews toward US/EU infrastructure vendors; the Chinese ecosystem (WeChat, Feishu, DingTalk, …) will be filled in v0.2 — which is itself a backlog item and a contribution opportunity (Add a capability).

Judgment: today’s provider structure is heavily concentrated in “agent-era infrastructure” — search, browsers, vector DBs, inference APIs. Consumer-facing real-world capabilities (booking, delivery, payments) remain partner-gated and under-open. The metric worth tracking over the next 12 months is not how many APIs appear, but how many real-world capabilities start opening to agents.

3. Pricing changes

Baseline facts (sources linked):

• The model price war that began in H2 2025 continues: Claude Opus 4.5 launched and was aggressively discounted, read as price dumping against Google and OpenAI (reseller.co.nz, PYMNTS); o3 dropped ~80%, creating a new price-performance tier (Towards AI); Q4 2025 model pricing changes are now being tracked systematically (dataku).
• Falling inference cost → each agent “thought” is cheaper → per-call cost share falls while the share of capability/software cost rises.

Judgment: the model price war is the supply-side precondition of the Agent Capability Economy: once inference is no longer the cost center, a software “capability fee” becomes a separately priced, separately billable object. That is the macro condition under which CaaS (Capability as a Service) can exist.

4. MCP / Skills ecosystem

Baseline facts:

• GitHub MCP Registry launched (2025-09): a central discovery and trust entry point for MCP servers (InfoWorld, DevOps.com).
• MCP’s first-year spec release (2025-11) shifted focus to authorization extensions — from “can connect” to “can safely act on a user’s behalf” (modelcontextprotocol.info).
• Ecosystem scale (established site figures): MCP SDK monthly downloads approached the 100M level by mid-2026; the top skills.sh skill accumulated ~2M installs in five months.
• But the official registry explicitly does not publish adoption or usage data — the discovery layer is consolidating while the usage layer still has no data (see §6).

Judgment: the MCP ecosystem is moving from “protocol fragmentation” to a three-layer stack — protocol + registry + authorization. Registries solve discovery, authorization solves trust, and neither produces usage data. Measurement is not being replaced; it is being approached — the more standardized the connection layer, the more feasible a unified measurement vocabulary becomes.

5. Agent commerce

Baseline facts:

• Agentic Commerce Protocol (ACP): OpenAI and Stripe jointly defined a protocol for agents buying software/services on a user’s behalf; Stripe ships an Agent Toolkit with paid-tools and usage-based billing/metering alongside it (The AI Journal, Stactize, DeepWiki: usage-based billing).
• Google AP2 (Agent Payments Protocol): the competing autonomous-transaction protocol candidate (The AI Journal).
• Established site figures: Cloudflare x402 / Agentic Payments, Coinbase Bazaar, and ACP are the main 2026 payment-layer players.
• OpenAI DevDay 2025 positioned ChatGPT as an “AI OS” with in-chat apps and commerce as part of the platform narrative (windowsforum).

Judgment: the payment layer is converging from “who can charge an agent” into a protocol contest — ACP vs AP2 vs x402 vs Bazaar. But every payment protocol silently assumes that metered usage is reliable. That assumption does not hold today: payment is the last three layers; measurement is the first layer, and the industry is paying attention to the last three only.

6. Measurement developments

Baseline facts:

• Stripe’s Agent Toolkit builds usage-based billing and metering directly into the agent payment stack (DeepWiki).
• OpenTelemetry published an AI agent observability guide; GenAI semantic conventions are still evolving (opentelemetry.io).
• Established site figures: AAIF has been formed; AgentMeasure published Benchmark Run #001 (an evidence audit of six real agent-usage claims: every number is self-reported, nobody publishes the unit definition); the CORE spec is at Draft 0.4.3; Pipeline Validation #001 (42 calls → 84 observations); Measurement Report #001 is reserved for the first external provider.

Judgment: measurement is becoming mainstream, but the directions diverge: payment vendors build metering to bill, observability tools build telemetry to debug, and AgentMeasure argues for a third kind — verifiable measurement to compare and settle. Same goal, different vocabularies. Whoever defines a verifiable, cross-vendor “agent usage” first owns the next npm download count. The window is 2026.

7. Top 5 signals

1. Protocols are consolidating; the usage layer still has no data. MCP now has a registry and authorization extensions, but adoption and usage data remain absent — the faster discovery consolidates, the more visible the measurement gap becomes.
2. Payment vendors are building metering themselves. Stripe’s Agent Toolkit ships metering, which is the strongest validation yet that “measurement precedes payment” — the largest payment rails are betting on usage metering.
3. The model price war clears the way for capability pricing. As inference costs collapse, independent pricing and billing of software capability becomes economically viable for the first time.
4. Real-world capabilities are the least open. Payments and Real-world action are the smallest, most partner-gated categories in the index — openness is the next bottleneck and the next opportunity.
5. The standardization window is open. AAIF exists, OTel GenAI semantics are not finalized, and ACP/AP2 are unformed — 2026 is the window to define “verifiable agent usage.”

8. Roy’s updated view

The baseline judgment holds, plus one addition:

• Unchanged: measurement precedes payment; the five-stage chain (Reach → Choice → Use → Utility → Value) is the irreducible granularity; evidence grading (E0–E5) is the minimum implementation of verifiability.
• Added: payment vendors building metering is not a threat — it is validation. It moves measurement from an academic claim into the plumbing of commercial infrastructure. AgentMeasure’s position should advance from “proposing a measurement language” to “acting as the referee and registry for cross-vendor definitions” — coexisting with ACP/AP2/x402, owned by none of them.
• Next (Aug–Sep): grow the Capability Index to 200+ entries and open provider claiming; publish Measurement Report #001 (first external provider data); make this report a fixed expectation — same day every month.

*Related: Agent Capability Index · When the Software Consumer Becomes an Agent · Every Agent Usage Number Is Self-Reported · AgentMeasure · Subscribe via RSS · 中文版

Agent Capability Monthly 是每月一期的固定报告，回答一个问题：Agent 作为新的软件消费者，软件经济正在发生什么。结构固定为八段：新能力、新 provider、定价变化、MCP/Skills 生态、Agent 商业、计量进展、Top 5 信号、Roy 的判断。

创刊号是基线号：不追求当月新闻，而是把生态当前状态、计量方法与数据口径固定下来。后续每一期只报告与基线的变化（delta）。事实标注来源与日期，判断明确标注为判断。

0. 为什么现在需要一份月度报告

当软件的消费者从人变成 Agent，旧计量链（安装、席位、页面访问）在每一环断开，而新计量体系还没有形成稳定话语。行业讨论是碎片化的：有人讲协议、有人讲工具、有人讲支付、有人讲 observability。这份报告想做一件事：用固定口径持续记录这个生态，让「变化」可以被看见。

基线的两个事实底座：

• Agent Capability Index（公共地图）：收录 106 条 / 11 类可被 Agent 调用的软件能力，v0.1 种子数据，附 provider、interface、pricing、availability 与来源。
• AgentMeasure（开放计量基础设施）：五段链 Reach → Choice → Use → Utility → Value，证据分级 E0–E5，观测上下文 Context × 执行有效性 Validity。

1. New capabilities 新能力

基线口径：能力（Capability）= 软件可被 Agent 调用的一次能力，而非整个 App。收录标准：有公开文档、有可验证的接口（API / CLI / SDK / MCP / 自托管）、能说明计价方式。

基线分布（106 条）：

判断：支付类与真实世界动作类的条目最少、且最不稳定（合作制 API、定价不透明），这正是「计量先于支付」缺口在数据层的体现——越接近钱的能力，越缺少公开口径。

2. New providers 新 provider

基线口径：provider = 提供至少一个可调用能力的组织。v0.1 以欧美基础设施厂商为主，中文生态（微信/飞书/钉钉等）将在 v0.2 补齐——这本身就是一个待办，也是社区可贡献的方向（Add a capability）。

判断：当前 provider 结构高度集中在「Agent 时代的基础设施」——搜索、浏览器、向量库、推理 API。真正面向 Agent 的消费级能力（预订、配送、支付）仍以合作制为主，开放度不足。未来 12 个月最值得跟踪的，不是新增了多少 API，而是多少真实世界能力开始向 Agent 开放。

3. Pricing changes 定价变化

基线事实（来源见链接）：

• 2025 下半年开始的模型定价战持续：Claude Opus 4.5 上市后大幅降价，被视为对 Google 与 OpenAI 的「价格倾销」(reseller.co.nz、PYMNTS)；o3 价格下调 80%，形成新的性价比档位 (Towards AI)；Q4 2025 的模型定价变化已被系统性跟踪 (dataku)。
• 推理成本下降 → Agent 的每次「思考」更便宜 → 单次调用成本占比下降，能力与软件的定价占比上升。

判断：模型价格战是 Agent Capability Economy 的供给侧前提：当推理不再是成本大头，软件的「能力费」才会成为可单独定价、单独计费的对象。这也是 CaaS（Capability as a Service）可能成立的宏观条件。

4. MCP / Skills ecosystem 协议与工具生态

基线事实：

• GitHub MCP Registry 上线（2025-09）：为 MCP server 提供集中发现与信任入口 (InfoWorld、DevOps.com)。
• MCP 一周年 spec 更新（2025-11）：重点转向授权（authorization）扩展——从「能连」走向「能安全地代表用户调用」(modelcontextprotocol.info)。
• 生态规模（站内既有口径）：MCP SDK 月下载量在 2026 年中接近 1 亿次量级；skills.sh 头部 skill 五个月约 200 万次安装。
• 但官方 registry 明确不做采纳与使用数据——发现层在聚合，使用层依然无数据（见第 6 节）。

判断：MCP 生态正在从「协议碎片」走向「协议 + 注册表 + 授权」三层。注册表解决发现，授权解决信任，但两者都不产生使用数据。这意味着：measurement 不是被替代，而是被不断逼近——连接越标准化，计量口径的统一就越可能。

5. Agent commerce Agent 交易

基线事实：

• Agentic Commerce Protocol（ACP）：OpenAI 与 Stripe 联合推出，为 Agent 代用户购买软件/服务定义协议；Stripe 同步提供 Agent Toolkit（含 paid tools 系统与 usage-based billing/metering）(The AI Journal、Stactize、DeepWiki: usage-based billing)。
• Google AP2（Agent Payments Protocol）：与 ACP 并列的自主交易协议候选 (The AI Journal)。
• 站内既有口径：Cloudflare x402 / Agentic Payments、Coinbase Bazaar 与 ACP 同为 2026 年支付层的主要玩家。
• OpenAI DevDay 2025 把 ChatGPT 定位为「AI OS」，in-chat apps 与 commerce 成为平台叙事 (windowsforum)。

判断：支付层正在从「谁能收 Agent 的钱」快速收敛为「协议之争」——ACP vs AP2 vs x402 vs Bazaar。但所有支付协议都默认「被计费的使用量是可靠的」。这个默认目前不成立：支付是最后三层，测量是最先一层，行业把注意力全放在最后三层上。

6. Measurement developments 计量进展

基线事实：

• Stripe Agent Toolkit 直接内置 usage-based billing 与 metering，把「用量计费」做进 Agent 支付栈 (DeepWiki)。
• OpenTelemetry 发布 AI agent observability 指南，GenAI 语义约定仍在演进 (opentelemetry.io)。
• 站内既有口径：AAIF 已成立；AgentMeasure 已发布 Benchmark Run #001（对六个真实 Agent 用量声明的证据审计：每个数字都是自报的，没人发布单位定义）；CORE 规范到 Draft 0.4.3，Pipeline Validation #001（42 calls → 84 observations）；Measurement Report #001 编号预留给第一个外部 Provider。

判断：计量正在成为「显学」，但方向分化：支付商在做计量以计费（metering for billing），可观测工具在做调试以排障（observability for debugging），而 AgentMeasure 主张的是第三类——可验证以比较与结算（verifiable measurement for markets）。三类目的一致，但口径不同；谁先定义出可验证、跨厂商统一的「Agent 使用量」，谁就拥有下一个 npm 下载量。窗口期就在 2026。

7. Top 5 signals 本月最重要信号

1. 协议开始收敛，使用层依然无数据：MCP 有了 Registry 与授权扩展，但采纳与使用数据仍缺席——发现层聚合越快，计量缺口越刺眼。
2. 支付商亲自下场做计量：Stripe Agent Toolkit 内置 metering，说明「计量先于支付」正在被最大的支付基础设施验证。
3. 模型定价战为能力定价铺路：推理成本暴跌，软件能力的独立定价与计费第一次在经济上可行。
4. 真实世界能力开放度不足：Capability Index 中 Payments 与 Real-world 类别条目最少且多为合作制——开放度是下一个瓶颈，也是下一个机会。
5. 标准窗口期：AAIF 成立、OTel GenAI 语义约定未定稿、ACP/AP2 协议未定型——2026 年是定义「可验证的 Agent 使用量」的窗口。

8. Roy’s updated view 最新判断

基线判断保持不变，并增加一条：

• 不变：measurement 先于 payment；五段链（Reach → Choice → Use → Utility → Value）是不可再压缩的计量粒度；证据分级（E0–E5）是可验证性的最小实现。
• 新增：支付商亲自做 metering 不是威胁，而是验证——它把「计量」从学术主张变成了商业基础设施的组成部分。AgentMeasure 的定位应从「提出计量语言」推进到「成为跨厂商口径的裁判与注册表」：与 ACP/AP2/x402 并存，但不属于任何一家。
• 下一步（8–9 月）：Capability Index 扩到 200+ 条并开放 provider 认领；发布 Measurement Report #001（第一个外部 Provider 数据）；把本刊做成固定预期——每月同日更新。

相关材料：Agent Capability Index · 当软件的消费者变成 Agent · 每个 Agent 用量数字，都是自报的 · AgentMeasure · 订阅 RSS

实验

“Agent 用量”正在成为 2026 年的社会证明——徽章、对比、计量和支付的依据。所以我们去找真实的公开用量声称，对每一个只问一个问题：这个数字能验证吗？

六个声称，六个来源，一个下午的阅读：

证据阶梯（E0–E5）：无证据 → 自报聚合 → 披露方法 → 第三方验证 → 独立观察 → 交叉验证观察。

发现

1. 每个数字都是自报的。 声称之间的差别不是诚实度，而是可重放性。两个 x402 数字可能真实、但无法验证——没有披露计数方法，没有公开原始数据。冒充统计无法验证，且关键术语未定义。

2. 最强的声称来自唯一的独立观察者。 llms.txt 审计（E3）打败了所有数据完美的平台。独立性胜过体量。

3. 徽章是薄弱环节。 注册表徽章继承了其来源的验证语义。一个没有披露方法的徽章，是穿着高分级外衣的低分级。

4. 没人发布单位定义。 六个声称没有一个说明”一笔支付”“一个商家”“一次 AI 请求”“一次冒充”到底指什么。这是最关键的缺口：你无法审计你无法定义的东西。

为什么现在重要

支付轨道正在建在这些数字之上。当 x402 以每笔 $0.25 结算 1.62 亿笔时，一个错误定义的单位就是财务完整性问题，而不是分析问题。Agent 经济即将让真金白银流过没人能验证的测量。

标准的工作

这就是 AgentMeasure 存在的原因：让 E3（独立重放）变得便宜，而不是对 E1 说教。具体来说：

• 单位定义必须随每个公开指标发布。 什么算尝试、操作、交付、被消费的结果——写清楚，而不是暗示。
• 观察发生在 callee 侧。 调用者不能自报自己的用量；这是测量与新闻稿的区别。
• unknown 是默认值。 每条观察从不合格开始，只有证据才能升级它。CI、基准测试和健康检查不能再悄悄污染公开数字。

完整评分表与来源在 Benchmark Run #001。如果你发布用量数字，告诉我们它是怎么分级的。如果你有我们该审计的声称，发过来——下一轮审计已经排期。

The experiment

“Agent usage” is becoming the social proof of 2026 — the basis for badges, comparisons, metering, and payment. So we went looking for real, public usage claims and asked one question of each: can this number be verified?

Six claims, six sources, one afternoon of reading:

The grading ladder (E0–E5): no evidence → self-reported aggregate → disclosed method → third-party verification → independent observation → cross-checked observation.

What we found

1. Every number is self-reported. The difference between the claims was not honesty but replayability. Two x402 numbers are probably true and impossible to verify — no disclosed counting method, no public raw data. The impersonation statistic is unverifiable and its key term undefined.

2. The strongest claim came from the only independent observer. The llms.txt audit (E3) beat every platform with perfect data. Independence beats volume.

3. Badges are the weak link. A registry badge inherits the verification semantics of its source. A badge with no disclosed method is a low grade wearing high-grade colors.

4. Nobody publishes the unit definition. None of the six claims states what counts as “a payment”, “a merchant”, “an AI request”, or “an impersonation”. This is the gap that matters: you cannot audit what you cannot define.

Why this matters now

Payment rails are being built on top of these numbers. When x402 settles 162 million payments at $0.25 each, a misdefined unit is a financial-integrity problem, not an analytics problem. The agent economy is about to route real money through measurements nobody can verify.

The standard’s job

This is why AgentMeasure exists: to make E3 cheap, not to moralize about E1. Concretely:

• Unit definitions must ship with every public metric. What counts as an attempt, an operation, a delivery, a consumed result — stated, not implied.
• Observation happens at the callee boundary. Callers cannot self-report their own usage; that is the difference between a measurement and a press release.
• Unknown is the default. Every observation starts unqualified and is upgraded only by evidence. CI, benchmarks, and health checks cannot quietly pollute public numbers.

The full scorecard with sources is in Benchmark Run #001. If you publish usage numbers, tell us how they’re graded. If you have a claim we should audit, send it over — the next run is already scheduled.

两个数字可以说明变化的速度。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。上一次软件消费者发生变化时，整个行业重新发明了软件经济学。这一次，变化从计量开始。

相关材料：白皮书：如何度量 AI Agent 对软件的使用 · 英文版文章 · AgentMeasure 仓库 · CORE 规范 · Benchmark 草案

Two numbers illustrate the speed. On Vercel’s skills.sh leaderboard, the top skill accumulated roughly 2 million installs in five months; the MCP ecosystem’s SDK downloads were approaching the 100-million-per-month scale by mid-2026. The numbers themselves don’t matter. What matters is what they mean: agents are becoming a new class of software consumer, and the entire measurement system the software industry built for human consumers fails almost completely for them.

This essay makes three points: why the old metrics break, why measurement must precede payment, and why an open, verifiable measurement layer is the infrastructure everyone is skipping — and no one can eventually avoid.

1. The old measurement chain breaks at every link

The human software economy runs on a measurement language decades old: downloads, installs, MAU, seats, pageviews, session time. It rests on an implicit chain:

Installed → Available → Presented → Chosen → Used → Value created

For decades this chain worked because each link corresponded to an observable human behavior. Now the consumer on the chain is an agent — and agent behavior breaks the chain at every single link:

• Installed ≠ available. An MCP server in a config file is not a capability that was ever invoked in a task.
• Available ≠ presented. Agents only surface a capability into the candidate set when the model deems it relevant — a filtering process that is largely invisible from outside.
• Presented ≠ chosen. Choice happens inside the context window. It is the result of reasoning, not an auditable click.
• Chosen ≠ used. The call may fail, time out, hit a guardrail, or be cancelled by the user.
• Used ≠ value created. A successful call can accomplish nothing; a failed call can consume the most expensive resources.

Worse, almost every “usage” signal in the ecosystem today is self-reported. skills.sh install counts come from CLI client telemetry — gameable, with no public stats API. The official MCP registry explicitly does not provide adoption or usage data. A third-party audit of the llms.txt ecosystem found that of ~39,000 declared files, 97% had never received a single AI request — declared ≠ used. These are not defects of individual platforms; they are a structural gap: there is no verifiable, standardized measure of “agent usage” anywhere in the ecosystem.

2. Measurement precedes payment

In 2026 the payment layer is arriving fast: Cloudflare’s x402 / Agentic Payments, Coinbase’s Bazaar, OpenAI and Stripe’s Agentic Commerce Protocol (ACP). These protocols solve the same problem: how agents pay for software capabilities.

But they all quietly assume one thing: that the usage being billed is trustworthy. That is a dangerous default. You cannot bill for a usage behavior you cannot measure and verify — no meter, no electricity bill. Measurement is the precondition for metering, and metering is the precondition for payment. The layers must be built in order:

Measure → Meter → Pay

Everyone’s attention is on the rightmost layer. The leftmost layer — verifiable measurement — is the weakest and most absent of all. x402 can transport a credential that says “used 3 times”; it cannot tell whether “used 3 times” is true. This is not a flaw of payment protocols. It is the foundation under them that has not yet been poured.

3. What to measure: the five-link chain

The common language AgentMeasure proposes is a five-link chain:

Reach → Choice → Use → Utility → Value

• Reach: how widely did the agent see this capability? Indexed, retrieved, present in the candidate set?
• Choice: among candidates, what was chosen and why? What context and constraints shaped the choice?
• Use: did the call happen, and did it deliver? What was invoked and consumed?
• Utility: what did the call produce? Did it actually contribute to the task?
• Value: how much exchangeable value was created? The only link that leads directly to transactions.

Each link needs its own definition and its own observation. Collapsing all five into a single “usage” number is just inventing a new unverifiable black box.

4. Evidence discipline: verifiability is the precondition of social proof

Over the past two years, open source has developed a strong appetite for social proof of AI usage — stars, badges, leaderboards, everyone looking for evidence that “my project is being used by AI.” But the value of that proof depends entirely on one thing: verifiability.

Stars can be bought. Installs can be gamed. Self-reported telemetry can be faked. Verifiable measurement cannot — if it carries the observation context (where the event was observed: agent runtime, gateway, or server-side self-report?) and execution validity (did the attempt actually deliver?), and grades its claims by evidence strength (E0–E5, from pure self-report to auditable independent observation), it stops being a marketing number and becomes a falsifiable fact.

That is exactly what the AI economy is scarcest in: falsifiable facts. Markets, rankings, billing, and insurance all sit on that foundation.

5. Why it must be an open standard

A measurement language cannot be any vendor’s black box. The reason is practical: if the measurement semantics are privately defined by one platform, every market, ranking, and billing system built on them becomes that platform’s tenant; if the semantics cannot be publicly audited, the whole system regresses to the self-report era.

So AgentMeasure’s route is: an open data language (reach / choice / use / utility / value) plus measurement semantics (observation context, attempt validity, evidence grading) plus machine-readable registry and conformance checks — so markets, metering, and payment protocols can build on a public, auditable fact layer. The standardization window is open right now, in 2026 — AAIF was founded, OpenTelemetry’s GenAI semantic conventions are still in development. Whoever defines verifiable “agent usage” in this window owns the next npm download count.

6. Where things stand

This layer is not a concept. The AgentMeasure repository already contains:

• The Core Specification (Draft 0.4.3): measurement objects, three-layer structure, interaction classes, observability states, metric eligibility, qualification (Context × Validity), measurement labels, and standard invariants;
• A reference implementation: an end-to-end pipeline from Provider SDK → Canonical Observation → Collector → Metrics;
• Pipeline Validation #001: local synthetic-traffic verification (42 calls → 84 observations), including how fail-closed semantics behave in a real pipeline; the Measurement Report #001 number is reserved for the first external provider;
• A benchmark draft: how to run evidence-graded audits of “usage” claims across the ecosystem;
• Conformance: check vectors between the standard and implementations.

The 1.0 graduation criteria are explicit: two independent implementations, three runtime profiles, two tool-side implementations, public conformance and canonical test vectors, 5–10 real projects, a published discrepancy report, and security and privacy review. This is not a “write another spec” project; it is a closed loop from spec to implementation to verification.

Closing

One line for each of three audiences:

• To platform teams: usage stats you ship without verifiability will become the starting point of the next trust crisis. Put the semantics and evidence into your spec now.
• To open-source maintainers: stars depreciate; verifiable usage evidence does not. Put “used by agents” evidence in your README instead of another self-reported badge.
• To founders: metering is payment’s foundation. While everyone is building the payment layer, there are still almost no bricks in the foundation — that is the window.

The software consumer is changing from humans to agents. The last time the software consumer changed, the industry reinvented software economics. This time, it starts with measurement.

Related: Whitepaper — How Software Usage by AI Agents Should Be Measured · 中文版文章 · AgentMeasure repository · Core Specification · Benchmark draft

作者：Roy Tong（仝夏瑞） 参考实现：AgentMeasure 仓库（GitHub）。

摘要

AI Agent 越来越多地代表用户与组织选择、调用并与软件交易。当 Skill、MCP server、 API、CLI 这些接口越来越容易创建与分发时，经济价值日益向它们背后的稀缺能力集中： 专有数据、算力、执行、权限、交易与真实世界的履约。

这在产生支付问题之前，先产生了计量问题。一个能力要能被可靠地定价、比较、计费与 优化，生态必须先就”什么算选择、什么算一次操作、什么算成功交付、什么算结果被消费、 什么算结果、什么算计费单位”达成共识。

AgentMeasure 为这个正在形成的 Capability Economy 提出一套开放计量标准：Reach → Choice → Use → Utility → Value 的共同数据语言，加上未来 Metering、Marketplace 与 支付轨道可以构建其上的测量语义。目标不是仪表盘，而是让 Capability as a Service （CaaS，本文用法）成为可能的计量基础。

一、从 SaaS 到 Capability Economy

软件分发曾有一条可读的链路：下载、安装、使用。每个时代有自己的经济单元。下面描述 的转变是增量，不是替代：与 seat-based SaaS、request-based API 并存的， callable capabilities 正在成为 Agent 中介的软件消费的一种新经济单元。

SaaS
人 → 应用 → 席位 / 月

API Economy
软件 → API → 请求 / Token

Capability Economy
Agent → Capability → 操作 / 结果

三股力量推动向第三行迁移：

接口被 Agent 吸收。 UI 与工作流越来越多地由 Agent 执行，而不是呈现给人。软件 剩下的是一件可调用的外衣——skill 文件、MCP tool、CLI、endpoint。

分发制品正在商品化。 开放的 Skill、开放的 MCP adapter、开放的 CLI，任何人都能 在几小时内创作并发布。接口可能变得廉价易造；能力依然是稀缺的交付物。

稀缺性下移。 稀缺层不再是应用外壳，而是可调用外衣所控制的访问权：

数据 · 算力 · 动作 · 权限 · 信任 · 真实世界履约

搜索能力因索引而稀缺；预订能力因能确认预订而稀缺；支付能力因能移动金钱而稀缺。 当商业价值集中在能力上，自然的经济单元就变成操作、数量、效应、结果——或其中任何 一项的收入分成。

如果 Capability 成为经济单元，Capability 计量就变成基础设施。 这是本文的论点。

论点与假设（Thesis and assumptions）

AgentMeasure 建立在三个尚未完全证实的趋势判断上：

1. Agent 将中介越来越多的软件选择与执行。
2. 更多软件能力将脱离其人类 UI 被独立暴露。
3. 基于使用、效应与结果的商业模型将与 seat-based 定价并存。

即使这些趋势发展不均衡，测量标准依然有用：对象、质量规则与声称纪律本身成立为 一套 Agent 软件测量标准。

二、先计量，后变现（Measurement Before Monetization）

CaaS 要能定价、计费与建立声誉，先要有共同的测量语义。四个问题说明这一点：

一个用户任务 → 1 个 Operation → 3 次重试
收 1 次钱还是 3 次？

工具成功返回 → Agent 忽略了结果
价值交付了吗？

预订 API 执行了 → 预订从未被确认
能力履约了吗？

任务成功 → 没有这个能力也能成功吗？
Provider 能主张价值吗？

这些问题都无法由原始调用次数回答，也无法由支付轨道回答。它们需要关于 operation / attempt / delivery / consumption / effect / outcome 的一致定义，以及 把观察转化为这些对象的一致规则。这个共识就是切入点：先计量，后变现。

现实证据：商业先于计量到来

这并非假设——Agent 中介商业的支付与发现基础设施已经存在：

• Cloudflare Agents SDK 允许 MCP Tool 按单次调用定价并经 x402 收费 （Charge for MCP tools）。
• Coinbase x402 Bazaar 是发现层：Agent 搜索带价格与 schema 的服务，并经 MCP 完成付费调用（x402 Bazaar）。
• OpenAI 与 Stripe 的 Agentic Commerce Protocol（ACP） 已在真实 agentic commerce 流程中使用（报道）。

这证明本节的论点：支付与发现基础设施先于共同的 capability 测量语义到来—— 这正是 AgentMeasure 要填补的空缺。

三、测量对象

Observation 是证据单位，不是业务测量单位。 AgentMeasure 先定义业务单位：

Provider
    ↓
Software Entity
    ↓
Capability
    ↓
Interaction Surface

Capability 是主要的功能与测量对象。Offering 是一个或多个 Capability 的商业包装 ——定义于 Commercial Extension（实验性），绝不插入 Core 测量谱系。

观察发生在 Interaction Surface 层；归属到 Software Entity 经机器可读 registry 解析——观察时绝不猜测。

定价不是核心模型的对象。 Offering——引用一个或多个 Capability 的商业包装， 含允许的 surface、定价政策、服务级别目标与商业约束——定义在 Commercial Extension （实验性、非规范性）中，使测量语义的演进不被任何支付设计绑架。

分布事件（Distribution events）

商业归因进入范围后，discovery 重新获得商业意义——但不成为选择分母：

Published → Listed → Retrieved / Discovered → Presented

Presented 仍是选择指标的分母；Discovered 是分布归因事件，回答 哪个 Skill / Registry / Marketplace 带来了 Capability 使用。

四、Agent–Capability 交互模型

Reach → Value 是测量视角，不是普适执行状态机。 不同类别的能力有不同的有意义链路：

Information   操作 → 结果 → 消费
Action        操作 → 效应 → 确认
Transaction   操作 → 授权 → 提交 / 结算

Interaction Class（information / action / transaction / computation / communication / control / storage / sensing）决定适用哪条链路、哪些 Utility 信号 有意义。搜索结果被消费；预订被确认；支付被结算。把所有能力塞进一条流水线， 产出的数字会失去含义。

五、测量框架

AgentMeasure 定义 Metric Families，不定义全局北极星。

M1 Distribution — Reach。 能力进入 Agent 世界了吗？ Available Clients · Eligible Opportunities · Presentations · Presentation Rate · Distribution Coverage

M2 Choice — 最 Agent-native。 Agent 有机会时会选它吗？ 选择数 · Observed Selection Rate（Observed Selected ÷ Presented）· Conditional Choice Share · 首选率

M3 Execution — Use。 选了以后好用吗？Draft 0.4 分开计数 Operation 与 Attempt—— 这正是未来 Metering 需要的区分：

Operations · Attempts · Attempts per Operation
Operation 完成率 · Operation 成功率
Attempt 失败率 · 重试率 · 延迟

M4 Utility — 有效使用。 能力交付了可用信息，还是引发了预期效应？

Result Utility     已交付 · 已消费 · 已接受
Effect Utility     已应用 · 已确认 · 已回退 / 失败

M5 Outcome — Value。 改善任务了吗？ 任务成功关联 · 增量提升 · 节省时间 · 节省成本

关系测量（从独立章节降级为小节）：Trial → Active → Repeated → Preferred → Dependent。最不可替代的 Dependent 依然是长期资产信号。

六、测量质量与声称纪律

证据质量不是覆盖质量，两者都不是限定质量，也都不是方法论。一组 100% 真实但只覆盖 2% Agent 的事件，不是市场数据。

Measurement Quality
├── Provenance / Evidence Strength  观察来自哪里？其来源被支持得多强？
├── Coverage                        我们看到了多少世界？
├── Qualification                   这算不算真实生产使用？
├── Sampling                        采样了吗？不确定性多少？
├── Identity                        标识归一得怎么样？
└── Method/version                  用什么统计、哪个规范版本？

限定使用。 每条观察携带两条轴——Usage Context（流量来源）与 Validity（观察是否 真实）。Strict Qualified Usage = production + validity=normal：公共指标的 默认口径。unknown 的 context/validity 单独披露，绝不静默计入——没有”报 unknown → 进排行榜”的激励。重试是同一 Operation 的另一次 Attempt，作为可靠性信号保留，不算 多次逻辑使用。

声称纪律。 每个公开指标携带 Measurement Label：分子、分母、可观测人群、合格 人群、runtime 覆盖、grain、choice mode、decision authority、selection constraint。 观测到的选择绝不说成偏好；关联绝不说成因果；不可观测绝不说成负面。

七、测量与计量（Measurement and Metering）

从测量标准通向 CaaS 的桥是语义的：测量单位 ≠ 计费单位，且三个计量概念必须 绝对分开——Event 是为什么计费，Unit 是按什么单位计，Quantity 是多少单位：

因此，计量语义按 Offering 定义：

Billable Event        哪个测量事实触发计费
Billable Unit         计量单位（操作、记录、GPU-秒、效应…）
Billable Quantity     单位如何计数（按策略：attempts、确认…）
Pricing Model         按操作 · 按数量 · 按效应 · 按结果 · 收入分成
Pricing Policy        版本化的价格规则（flat、阶梯、企业协议、surge…）
Quote                 单次调用实际适用的条款（quote_id、policy 版本、单价）
Metering Policy       测量事实 → 计费事实的映射（规则、排除），版本化
Metering Ledger       可重放、可纠错的计量事实账本（revision / supersedes / reversal）
Commercial Attribution  哪些参与方贡献了发现 / 选择 / 收入

支付不在范围内。 AgentMeasure 不定义支付轨道、钱包、结算货币、商户记录关系或 金融托管。它产出支付系统消费的事实——合格操作、已确认效应、合格结果、计费数量、 商业归因。

AgentMeasure 标准化经济事实，不移动金钱。

八、归因与增量

能力参与了成功任务，不等于它导致了成功。

• 归因测量（observational）：哪些能力参与了任务链——只能支持”关联”与”参与执行链”的结论。
• 增量测量（counterfactual）：能力的存在创造了多少额外价值——随机对照是最强 证据，但许多能力无法随机关闭。因此因果声称遵循 Value Evidence Ladder：

V0 Association            任务成功时参与过
V1 Matched / Observational 控制已知混淆变量比较
V2 Offline Ablation       重放任务、移除能力
V3 Quasi-experiment       switchback / 自然变异
V4 Randomized Holdout     最强因果证据

只允许用实际产出的证据等级支持对应的因果声称强度——与测量质量的纪律一致。

商业归因扩展观察侧到分发链：

GitHub Skill → Registry → Agent 推荐 → Capability → 支付

谁贡献了发现、选择与收入？这是未来 Agent affiliate 与收入分成模型的基础——且绝不 与因果增量混为一谈。

九、能力信任与可比性（Capability Trust and Comparability）

能力消费者的选择受多种因素塑造。Agent 与 Marketplace 可以在品牌、政策、价格、 用户偏好与平台约束之外越来越多地比较机器可读的性能信号——这正是 AgentMeasure 的 Decision Authority / Selection Constraint 模型描述的轴：

Capability Signals
可靠性 · 延迟 · 价格 · 新鲜度 · 消费 · 效应成功 · 结果 · 安全 · 测量覆盖

AgentMeasure 不计算通用 AgentMeasure Score。Agent A 在乎价格，Agent B 在乎延迟， Agent C 在乎隐私。排名是 Agent 与 Marketplace 的产品决策；标准只定义可比较的信号 与让它们可比较的 Label。Measurement Label 是这种可比性的基础。

十、观察与部署架构（Observation & Deployment Architecture）

不同测量 surface 能看到的东西不同；单边接入就有价值，但声称必须匹配 surface：

分发侧 → Agent Runtime 侧 → Provider 侧 → 效应 / 结果侧

双侧观察（Agent runtime + provider）构成佐证（E2）；仅 Provider 侧也足以支持 provider-scoped 的使用指标。标准不在请求关键路径上：观察异步产出、仅元数据、 落盘前伪匿名。

十一、互操作

标准是 transport-neutral、vendor-neutral 的。现有基础设施作为实现例子而非前提： MCP 承载生命周期事件与 trace context；OpenTelemetry 承载工具 span；Codex/Claude Code/DeepSeek Harness 暴露带能力声明的观察点；registry 提供实体身份。未来的支付 轨道消费标准的事实，而不是扩展标准的核心。

十二、不做什么与治理

AgentMeasure 不是支付协议、Marketplace、钱包或通用声誉系统。标准不：

• 移动金钱或托管资金；
• 给能力排名或给 Provider 打分；
• 定义什么是”好”能力；
• 要求任何中心服务器、Agent 侧安装或开源 Provider。

标准本身由社区治理（AUP 流程，proposals/）；建立在它之上的商业产品不得控制 标准的定义。

十三、开放问题

1. 任务边界：什么算一个”任务”，由谁定义？
2. 效应验证：不深度集成每个目标系统，如何确认效应（预订确认、支付结算）？
3. 规模化增量：如何在不干扰生产的情况下跨生态运行反事实实验？
4. 候选集可观测性：Presented 是关键分母，多数 runtime 尚未暴露 routing 层信号。
5. 跨 Agent 身份：同一 client 跨 Codex/Claude/DSH——何时可知？
6. 计费单位共识：Provider 与支付轨道最终会就哪些测量事实达成一致，误计量的代价多大？
7. 隐私：伪匿名下关联与留存能走多远？

十四、结论

软件消费者正在从人变成 Agent，经济单元正在从席位转向可调用的能力。在能力被定价、 计费与比较之前，生态需要一套共享的测量语言——什么算选择、什么算操作、什么算交付、 消费、效应与结果，以及哪些数字能支持哪些结论。

AgentMeasure 就是那个提案：测量语义作为基础设施，商业语义作为未来扩展，支付交给 别人的轨道。今天：让开发者知道 Agent 如何真实使用自己的能力。下一步：让 Capability 可以跨 Agent 被统一度量、比较和计量。长期：成为 CaaS 与 Agent Capability Economy 的统一计量基础。

参考文献

1. RFC 2119 / BCP 14 — Key words for use in RFCs to Indicate Requirement Levels。
2. OpenTelemetry GenAI semantic conventions — gen_ai.* 工具调用遥测字段。
3. Model Context Protocol (MCP) 规范 — 工具发现与调用 surface。
4. MCP Registry — 实体解析的 server 身份入口。
5. EDPB — 伪匿名化指引（伪匿名数据仍可能属于 personal data）。
6. Cloudflare — Charge for MCP tools（x402 / Agentic Payments）。
7. Coinbase — x402 Bazaar：Discover & pay over MCP。
8. OpenAI / Stripe — Agentic Commerce Protocol（ACP），2025 年 9 月发布；见 Digital Transactions 报道。
9. AgentMeasure 规范 — Core / Metrics / Data / Entity / Quality / Correlation （standard/）；Commercial Extension（extensions/COMMERCIAL.md，实验性）； 机器可读 registry（schemas/、registry/）；参考实现与 conformance vectors 同仓发布。

规范全文（测量对象、生命周期、指标家族、质量、报告）与参考实现（AgentMeasure）均已开源。AgentMeasure 1.0 毕业标准：2 个独立实现、3 个 runtime profiles、2 个 tool-side 实现、公开 conformance + canonical test vectors、5-10 个真实项目、已发布的 discrepancy report、安全与隐私审查。

Roy Tong The reference implementation lives in the AgentMeasure repository.

0. Abstract

AI agents increasingly select, invoke, and transact with software on behalf of users and organizations. As interfaces such as Skills, MCP servers, APIs and CLIs become easier to create and distribute, economic value increasingly shifts toward the scarce capabilities behind them: proprietary data, compute, execution, permissions, transactions and real-world fulfillment.

This creates a measurement problem before it creates a payment problem. A capability cannot be reliably priced, compared, billed or optimized until the ecosystem agrees on what constitutes a selection, an operation, a successful delivery, a consumed result, an outcome and a billable unit.

AgentMeasure proposes an open measurement standard for this emerging capability economy: a common data language — reach, choice, use, utility, value — plus the measurement semantics that metering, marketplaces and payment rails can later build on. The goal is not a dashboard. It is the measurement foundation that makes Capability as a Service (CaaS, as used in this paper) possible.

1. From SaaS to Capability Economy

Software distribution once had a readable chain: downloaded, installed, used. Each era has had its own economic unit. The shift described below is additive, not replacement: alongside seat-based SaaS and request-based APIs, callable capabilities are emerging as a new economic unit for agent-mediated software consumption.

SaaS
Human → Application → Seat / Month

API Economy
Software → API → Request / Token

Capability Economy
Agent → Capability → Operation / Outcome

Three forces are driving the shift to the third row.

Interfaces are being absorbed by agents. The UI and the workflow are increasingly executed by the agent, not presented to a human. What remains for software is a callable surface — a skill file, an MCP tool, a CLI, an endpoint.

Distribution artifacts are commoditizing. An open Skill, an open MCP adapter, an open CLI can be authored and published by anyone in hours. Interfaces may become cheap to create; capabilities remain scarce to deliver.

Scarcity moved down the stack. The scarce layer is no longer the app shell; it is what the callable surface controls access to:

Data · Compute · Action · Permission · Trust · Real-world fulfillment

A search capability is scarce because of its index; a booking capability because it can confirm a reservation; a payment capability because it can move money. When commercial value concentrates in the capability, the natural economic unit becomes the operation, the quantity, the effect, the outcome — or a revenue share on any of them.

If capability becomes the economic unit, capability measurement becomes infrastructure. That is the thesis of this paper.

Thesis and assumptions

AgentMeasure is built on three trend judgments that are not yet fully established:

1. Agents will mediate a growing share of software selection and execution.
2. More software capabilities will be exposed independently of their human UI.
3. Usage-, effect-, and outcome-based commercial models will coexist with seat-based pricing.

The measurement standard remains useful even if these trends progress unevenly: the objects, quality rules and claim discipline stand on their own as an agent software measurement standard.

2. Measurement Before Monetization

Before CaaS can have pricing, billing and reputation, it needs common measurement semantics. Four questions make the point:

One user task → 1 Operation → 3 retries
Charge 1 time or 3?

Tool returned successfully → Agent ignored the result
Was value delivered?

Booking API executed → reservation was never confirmed
Was the capability fulfilled?

Task succeeded → would it succeed without the capability?
Can the provider claim value?

None of these questions can be answered by raw call counts, and none of them can be answered by a payment rail. They require agreed definitions of operation, attempt, delivery, consumption, effect and outcome — and agreed rules for turning observations into those objects. That agreement is the wedge: measurement before monetization.

Emerging evidence: commerce is arriving before measurement

The premise is not hypothetical — payment and discovery infrastructure for agent-mediated commerce already exists:

• Cloudflare Agents SDK allows MCP tools to be priced per call and charged via x402 (Charge for MCP tools).
• Coinbase x402 Bazaar is a discovery layer where agents search services with price and schema, and complete paid calls over MCP (x402 Bazaar).
• OpenAI and Stripe’s Agentic Commerce Protocol (ACP) is being used in real agentic commerce flows (announcement coverage).

These prove the thesis of this section: payment and discovery infrastructure is arriving before common capability measurement semantics — the gap AgentMeasure fills.

3. Measurement Objects

An observation is an evidence unit, not a business measurement unit. AgentMeasure defines the business units first:

Provider
    ↓
Software Entity
    ↓
Capability
    ↓
Interaction Surface

Capability is the primary functional and measurement object. An Offering is the commercial packaging of one or more capabilities — defined in the Commercial Extension (experimental), never inserted into the core measurement lineage.

Observation happens on Interaction Surfaces; attribution resolves to Software Entities through a machine-readable registry — never guessed at observation time.

Pricing is deliberately not an object of the core model. An Offering — commercial packaging referencing one or more capabilities, with permitted surfaces, pricing policy, service level objectives and commercial constraints — is defined in the Commercial Extension (experimental, non-normative), so that measurement semantics can evolve without being coupled to any payment design.

Distribution events

With commercial attribution in scope, discovery regains business meaning — without becoming the choice denominator:

Published → Listed → Retrieved / Discovered → Presented

Presented remains the denominator of choice metrics; Discovered is a distribution-attribution event, answering which Skill / Registry / Marketplace brought capability usage.

4. Agent–Capability Interaction Model

Reach → Value is a measurement view, not a universal execution state machine. Different classes of capabilities have different meaningful chains:

Information   Operation → Result → Consumption
Action        Operation → Effect → Confirmation
Transaction   Operation → Authorization → Commit / Settlement

The Interaction Class (information / action / transaction / computation / communication / control / storage / sensing) determines which chain applies and therefore which Utility signals are meaningful. A search result is consumed; a booking is confirmed; a payment is settled. Forcing every capability through one pipeline would produce numbers that mean different things.

5. Measurement Framework

AgentMeasure defines metric families, not a universal KPI.

M1 Distribution — Reach. Is the capability in the agent world? Available Clients · Eligible Opportunities · Presentations · Presentation Rate · Distribution Coverage

M2 Choice — the most agent-native family. When the agent had the chance, did it choose the capability? Selections · Observed Selection Rate (Observed Selected ÷ Presented) · Conditional Choice Share · First-choice Rate

M3 Execution — Use. Was it usable after selection? The Draft 0.4 model counts operations and attempts separately — the distinction that metering will eventually need:

Operations · Attempts · Attempts per Operation
Operation Completion Rate · Operation Success Rate
Attempt Failure Rate · Retry Rate · Latency

M4 Utility — effective use. Did the capability deliver usable information or cause the intended effect?

Result Utility      Delivered · Consumed · Accepted
Effect Utility      Applied · Confirmed · Reversed / Failed

M5 Outcome — Value. Did it improve the task? Task Success Association · Incremental Lift · Time Saved · Cost Saved

Relationships (formerly a separate chapter, now a subsection): Trial → Active → Repeated → Preferred → Dependent. Dependency — the least replaceable — remains the long-term asset signal.

6. Measurement Quality & Claim Discipline

Evidence quality is not coverage quality; both are not qualification quality; none is methodology. A set of perfectly attested events covering 2% of agents is not market data.

Measurement Quality
├── Provenance / Evidence Strength   where did this observation come from, and how
│                                    strongly is its origin supported?
├── Coverage                         how much of the world did we see?
├── Qualification                    does this count as real production use?
├── Sampling                         sampled? with what uncertainty?
├── Identity                         how well do identifiers resolve to entities?
└── Method/version                   which statistics, which spec version?

Qualified usage. Every observation carries two axes — Usage Context (where the traffic came from) and Validity (whether the observation is genuine). Strict Qualified Usage = production + validity=normal: the default for public metrics. Unknown context/validity is disclosed separately, never silently included — no “report unknown → make the leaderboard” incentive. A retry is an additional attempt of the same operation, kept as a reliability signal, not as a distinct logical use.

Claim discipline. Every published metric carries a Measurement Label: numerator, denominator, observable population, qualified population, runtime coverage, grain, choice mode, decision authority, selection constraint. Observed choice is never presented as preference; association is never presented as causation; unobservable is never interpreted as negative.

7. Measurement and Metering

The bridge from measurement standard to CaaS is semantic: measurement unit ≠ billable unit, and the three metering concepts must stay separated — Event is why billing triggers, Unit is what is counted, Quantity is how many:

Metering semantics therefore define, per Offering:

Billable Event       which measured fact triggers a charge
Billable Unit        the unit of quantity (operation, record, GPU-second, effect…)
Billable Quantity    how the unit is counted (per policy: attempts, confirmations…)
Pricing Model        per-operation · per-quantity · per-effect · per-outcome · revenue share
Pricing Policy       versioned price rules (flat, volume tiers, enterprise agreement, surge…)
Quote                the terms actually applicable to one call (quote_id, policy version, unit price)
Metering Policy      how measurement facts map to billable facts (rules, exclusions), versioned
Metering Ledger      replayable, correctable record of metered facts (revision / supersedes / reversal)
Commercial Attribution  which parties contributed to discovery / selection / revenue

Payment is out of scope. AgentMeasure does not define payment rails, wallets, settlement currencies, merchant-of-record relationships, or financial custody. It produces the facts — qualified operation, confirmed effect, qualified outcome, billable quantity, commercial attribution — that payment systems consume.

AgentMeasure standardizes economic facts, not money movement.

8. Attribution and Incrementality

A capability’s participation in a successful task is not evidence that it caused the success.

• Attribution measurement is observational: which capabilities participated in the task chain. It supports claims of association and contribution to the execution chain — nothing more.
• Incrementality measurement is counterfactual: how much additional value did the capability create? Randomized comparison is the strongest evidence, but many capabilities cannot be randomly switched off. Claims therefore follow a Value Evidence Ladder:

V0 Association             participated when the task succeeded
V1 Matched / Observational known confounders controlled
V2 Offline Ablation        replay tasks with the capability removed
V3 Quasi-experiment        switchback / natural variation
V4 Randomized Holdout      strongest causal evidence

Only the evidence actually produced may support the corresponding causal claim strength — the same discipline as measurement quality.

Commercial attribution extends the observational side along the distribution chain:

GitHub Skill → Registry → Agent Recommendation → Capability → Payment

Who contributed to discovery, selection and revenue? This is the future basis for agent affiliate and revenue-sharing models — and it must never be conflated with causal incrementality.

9. Capability Trust and Comparability

A capability consumer’s choice is shaped by many factors. Agents and marketplaces can increasingly compare machine-readable performance signals alongside brand, policy, price, user preference, and platform constraints — exactly the axes AgentMeasure’s Decision Authority / Selection Constraint model describes:

Capability Signals
Reliability · Latency · Price · Freshness · Consumption · Effect Success
Outcome · Safety · Measurement Coverage

AgentMeasure does not calculate a universal AgentMeasure Score. Agent A cares about price, Agent B about latency, Agent C about privacy. Ranking is a product decision for agents and marketplaces; the standard defines only comparable signals and the labels that make them comparable. The Measurement Label is the foundation of this comparability.

10. Observation & Deployment Architecture

Measurement surfaces differ in what they can see; single-sided adoption has value, but the claim must match the surface:

Distribution Side → Agent Runtime Side → Provider Side → Effect / Outcome Side

Two-sided observations (agent runtime + provider) enable corroboration (E2); the provider side alone is sufficient for provider-scoped usage metrics. The standard is not on the critical request path: observations are emitted asynchronously, metadata only, pseudonymized before persistence.

11. Interoperability

The standard is transport-neutral and vendor-neutral. Current infrastructure binds to it as implementation examples, not as preconditions: MCP carries lifecycle events and trace context; OpenTelemetry carries tool spans; Codex, Claude Code, and DeepSeek Harness expose observation points with declared capability matrices; registries provide entity identity. Payment rails, when they arrive, consume the standard’s facts rather than extending its core.

12. Non-goals and Governance

AgentMeasure is not a payment protocol, a marketplace, a wallet, or a universal reputation system. The standard does not:

• move money or custody funds;
• rank capabilities or score providers;
• define what a “good” capability is;
• require any central server, agent-side install, or open-source provider.

The standard itself is community-governed (AUP process, proposals/); commercial products built on it must not control the standard’s definitions.

13. Open Questions

1. Task boundaries. What is the unit of a “task,” and who defines it?
2. Effect verification. How to confirm an effect (booking confirmed, payment settled) without deep integration into every target system?
3. Incrementality at scale. How to run counterfactual experiments across the ecosystem without disturbing production?
4. Candidate-set observability. Presentation is the key denominator; most runtimes do not expose it yet.
5. Cross-agent identity. Same client across Codex, Claude, and DSH — when is that knowable?
6. Billable-unit consensus. Which measurement facts will providers and payment rails actually agree on, and at what cost of mis-measurement?
7. Privacy. How far can correlation and retention go under pseudonymity?

14. Conclusion

The software consumer is changing from humans to agents, and the economic unit is shifting from seats to callable capabilities. Before capabilities can be priced, billed and compared, the ecosystem needs a shared measurement language — what a selection is, what an operation is, what a delivery, a consumption, an effect and an outcome are, and which numbers can support which conclusions.

AgentMeasure is that proposal: measurement semantics as infrastructure, commercial semantics as a future extension, payment as someone else’s rails. Measure how agents use software capabilities today; make capabilities comparable and meterable next; build the measurement foundation for Capability as a Service in the long term.

References

1. RFC 2119 / BCP 14 — Key words for use in RFCs to Indicate Requirement Levels.
2. OpenTelemetry GenAI semantic conventions — gen_ai.* tool-call telemetry fields.
3. Model Context Protocol (MCP) specification — tool discovery and invocation surfaces.
4. MCP Registry — server identity as the entry point for entity resolution.
5. EDPB — guidance on pseudonymisation (pseudonymised data may still be personal data).
6. Cloudflare — Charge for MCP tools (x402 / Agentic Payments).
7. Coinbase — x402 Bazaar: discover & pay over MCP.
8. OpenAI / Stripe — Agentic Commerce Protocol (ACP), announced September 2025; see Digital Transactions coverage.
9. AgentMeasure specification — Core, Metrics, Data, Entity, Quality, Correlation (standard/); Commercial Extension (extensions/COMMERCIAL.md, experimental); machine-readable registry (schemas/, registry/); reference implementation and conformance vectors in the same repository.

The normative specification (Measurement Objects, Lifecycle, Metric Families, Quality, Reporting) and the reference implementation (AgentMeasure) are published openly. Graduation to AgentMeasure 1.0 requires two independent implementations, three runtime profiles, two tool-side implementations, a public conformance suite with canonical test vectors, 5–10 real projects, a published discrepancy report, and security and privacy reviews.