真正有用的 token，得先代表一件真正有价值的东西

最近讨论 AI Agent 的支付时，大家很容易把问题收缩成一件事：怎样给 Agent 一只钱包，让它可以自己买 API、数据或别的服务。这个场景当然是真实的。一个能代表人或组织跨服务执行任务的软件主体，迟早会遇到 payment。本文里说的 Agent，就是这种能被委托做事的软件；“委托”指的是人或组织给它的一份带范围和期限的行动授权。

但我觉得这还是把最显眼的一步，当成了整个问题。

Agent 会把这个问题推到台前，是因为它开始代表人或组织，以机器的速度跨服务调用资源。一次调用背后不一定只是价格；它也可能涉及配额、许可证、访问权、可撤销的资格，或者在一个计费周期之后才结算的服务。要把这些东西分配给 Agent、限制它的范围、记录它的消耗并在事后对账，系统必须先把它们表达成可识别的业务单位。今天有的系统叫它 credit、quota、license 或 entitlement；有的会用 token 来标识或承载其中的某一类。关键不在每个对象是不是都叫 token，而在它必须指向真实的权利、服务、资格或已记录事件，而不是一个脱离业务的抽象名字。为了避免混淆，下文把“业务 token”收窄为服务方能够兑现的使用权；资格、授权和回执则分别按自己的角色讨论。

如果一个 token 要代表某项服务使用权，它就得指向一项定义清楚的可兑现权利。与它相关的凭据可以承载签发者关于主体的声明；是否由该出示者使用这项使用权，仍要由出示过程和资源服务自己的策略决定。回执可以证明服务方记录或声明自己交付了什么。它们承担的是不同角色，即使同一份签名对象、凭据或账本条目可以同时承载其中不止一种角色。这个使用权能否被核验、使用或执行，取决于围绕它的服务、策略和记录。没有对应的服务，它只是一串记录。没有清楚的权利和消耗规则，它也很难解释自己到底代表了什么。

所以我一直觉得，AI Agent 的基础设施不应该只被讲成 wallet 或 payment。支付只是结算的一种方式。当 Agent 跨组织、跨服务商，或者代表别人行动时，身份、委托、资源单位、使用记录和 billing 才会变得特别尖锐。商业世界早就在处理这些问题，只是过去通常由航空公司、酒店、信用卡公司和大型云服务商自己维护一整套封闭系统。

我前面写过，AI Agent 不只是需要一只钱包。那篇讲的是谁授权 Agent、它能做什么、出了问题怎样追溯。这篇想把另一个问题讲得更具体一点：当一个系统说自己给了 Agent 一份 credit，它到底给了什么？

我做 ArcBlock 时一直觉得，一个真正有用的 token，得先代表一件真的、在业务里有明确价值的东西，而不是一个孤立的概念。它可能是可以消耗的资源，也可能是一个带条件的资格。把这些对象都混成一串抽象字符，系统迟早会对不上账。

模型 token、使用额度、授权和回执不是同一回事

今天这个词已经有点乱了。模型 token 是基础模型处理数据的单位。^[1] 产品里的 credit，往往是用户能用多少次图片生成、多少次 API 调用、多少存储或推理资源的使用额度。访问 token 可以表示调用资源的授权信息，credential 则可以携带签发者对主体作出的声明，供资源服务判断这次请求是否应该获准。它们相互关联，但不是同一种对象。

为了不把它们又混回去，本文把四类对象分开：

下文说的“业务 token”，只指使用权这个角色，也就是能被服务方兑现的使用额度或使用权。它不会自己执行服务；服务方的规则和系统决定它是否被识别、核验、消耗和结算。凭据或其他签名对象可以承载身份、授权、资格、使用权或回执中的一种或多种；账本条目也可以引用其中任何一种。承载它的格式，不等于它承担的角色。这些角色同样重要，但不是同一份待消费的额度。

这听起来很 old school，其实非常重要。10,000 次检索调用、100 GPU 分钟和 1 GB-month 存储，本来就是不同的计量单位。后一个也不能简单理解成“上传了 1 GB 文件”，而是需要事先说明它按文件大小、保留时间还是平均占用来计算。把每一个动作都立刻变成一笔货币支付，并不会让系统更清楚。一个常见做法，是先把它们按照自己的规则记下来，等到一个 billing 周期再结算。

很多数字服务已经这样管理 credit。用户拿到一组 credit，某种规格的图片消耗一个单位，另一种规格消耗更多单位。这里的重点不是它有没有被命名成 token，而是系统能不能回答：这个 credit 是谁发的，能用在什么服务上，什么时候失效，已经被怎样消耗，出现差异时应该查什么记录。Stripe 的 Billing Credits 就是一个很朴素的例子。它把 credit grant 分配给特定客户，并可用于以计量价格计费、用量由 Stripe Meters 报告的合格订阅项；状态包括 pending、granted、depleted、expired 和 voided。它也明确不允许把这些 credit 连接到数字钱包或用作第三方支付。^[2]

一个真正有用的使用额度，看起来经常很无聊。它可能只是“按明确计量规则保留 1 GB 数据一个计费月”的存储使用权，而不是一个很会讲故事的名字。

会员系统早就在把使用权、资格和回执分开处理

我一直觉得，航空公司、酒店和信用卡的会员体系，是理解 token 在现实商业中可以代表什么的一个好入口。它们本来就是在运行的商业系统：没有把所有东西都叫成积分，也没有把所有记录都当成付款。

拿一个很普通的航空会员计划作示意。完成一次符合规则的飞行后，乘客的账户可能增加里程积分。这是一种可累积的使用额度，符合条件时可以用来兑换一段旅程或别的服务。同一个计划还可能记录会员等级。等级不是“更多的里程”，而是一种资格状态，会员可以向服务方出示凭据来证明它：它在有效期内可能改变优先登机、行李或候补的规则，却不能像里程一样被拆开花掉。

如果会员等级带来升舱券，升舱券又是第三种对象。它通常有自己的有效期、适用航线、舱等和库存条件。一次退票产生的 travel credit 也不是里程或升舱券的别名，而是对未来一次订票的受限使用权。订票或升舱完成后留下的确认记录，则是回执。它说的是服务方按当时规则处理过一件事，不是账户里又多了一份可以继续消费的额度。

信用卡计划也有类似的层次。很多计划会按消费规则记 points，提供可以抵扣特定账单项目的 credit，或者发放只能在某项活动中使用的优惠券。它们出现在同一个 app 里，不代表规则相同。读者如果把它们想成一堆“不同类型的业务对象”，而不是一堆可以随意互换的数字，就比较容易理解 Agent 系统为什么也需要把单位分开。

小商家把这个逻辑做得更直白。很多餐馆有盖章卡：吃六次，第七次免费。没有人会认真计算这顿饭到底多贵，然后给半个章还是两个章。规则就是到店一次记一个章，满了之后兑现一次服务。它很简单，但已经包含了发行、持有、消耗和兑现。优惠券也是同样的逻辑。它只在一个确定的交易里改变可兑现的内容。

把它们分别来看：里程积分是可累积的使用额度；会员等级是会员可以用凭据证明的资格状态；升舱券是一项具体使用权；订票或升舱后的确认记录才是回执。它们不能因为都出现在同一个会员系统里，就被当成同一种 token。

这也能看出可替代（fungible）和不可替代（non-fungible）的区别为什么有实际意义。若规则规定任意一次同类 API 调用都相同，10 次调用可以合并成一笔额度。若一项权利绑定某个乘客、日期、座位或任务，它就需要按单件追踪。能否转让是另一条规则，不能从“可替代”或“不可替代”直接推出。回执则是历史事件记录，不是待消费的使用权。过去 NFT 的大量公众讨论聚焦在头像和数字艺术品上，我一直觉得挺可惜。更有意思的部分本来是很普通的东西：一张票、一份证书，或者一项需要独立核验的资格。

ARC 所面向的系统，会把这个类比再往前推一步。一个应用可以按不同规则计量流量、存储、计算、模型使用和 API 调用。统一的 credit 只有在仍保留底层计量、适用范围、换算、期限和结算规则时才有意义；它不应把这些差异掩盖掉。

资源以外，还有同样重要、但更像资格与凭证的对象：软件使用许可证、用户会员资格、控制访问的授权、用户对网络节点或账户的身份与控制关系，以及和线上服务使用有关的凭据。ARC 所面向的系统需要把这些关系分开处理。DID 和 Verifiable Credentials 机制可以表达主体、资格和授权相关的声明；其他服务关系可以使用自己的对象。例如，一条已有的 DID 域名托管流程会先检查要托管的域名；订阅完成后，DID Names NFT 会发到用户的钱包，使该域名可以用于 Blocklet 平台。把域名加入 Blocklet 后，HTTPS 证书会另行自动生成。许可证、会员资格、访问授权、域名相关的 NFT、证书和使用记录，都应当按各自真正的规则分型，因为它们的签发、核验、撤销、有效期和对账方式可能不同。

系统还可能把第三方能力包装成自己的服务。此时，一项内部使用权还要尊重底层服务商的可用范围、速率限制、有效期和结算条件。它不能假装自己的 credit 已经抹平了这些外部约束。这正是为什么新的计算服务也需要像航空公司那样，把不同权益和不同记录说清楚。复杂不是为了花样多，而是为了不把不同的承诺混成一笔模糊的余额。

数据库能记账；多方对账时，区块链才显出优势

单一服务商给自己的客户记 API 用量，用普通数据库就够了。只要各方信任运营者，或者接受它导出的记录和审计流程，它同样可以支持审计和对账。一个本地运行的 Agent 整理文件、调用自家工具，也应该把记录留在合适的本地系统里。

但当不同主体需要独立检查或质疑同一份记录时，问题就变了。多方共用一个数据库、再配上签名回执，可以在各方已经同意由某个运营者保管记录时正常工作。限制不是数据库不能记账，而是每个参与者都必须把大型平台的私有数据库和接口当成最终事实来源：运营者控制记录格式、访问、导出和历史更正，独立核验和可携带性会变得更昂贵，它也自然成为守门人。对小服务商而言，能否参与也更容易取决于那个平台的接口和许可。公共区块链或其他开放的分布式账本的优势就在这里：参与方可以各自保留并验证同一段有序历史，再用共同可引用的规则表达身份、委托、资格、使用权和回执，而不必各自从头建设一套可信平台，也不必把业务根记录交给某一家平台。

问题在不同主体需要独立检查或质疑同一份记录时才会变得尖锐。一个 Agent 可能代表某个用户，使用另一个组织提供的数据，再调用第三方的计算服务，把结果交给客户或审计方。这个过程中，谁在行动、它代表谁、它凭什么使用这份资源、服务方声称哪一次使用被处理过、哪一个系统扣除了哪个单位，开始不再只是某一家后台的内部问题。

这时，我觉得比较清楚的顺序是：身份回答“谁在行动”；委托回答“凭什么行动、边界在哪里”；使用权回答“它可以消耗什么服务”；回执和账本记录的是系统声称或观察到发生了什么。这个顺序不是每个系统都要完整照搬的技术栈，它只是在提醒我们不要把不同的问题折成一个 token。

一个 DID 可以标识一个主体，但它本身不等于现实世界的身份，也不自动给出访问权限。W3C 的 DID 标准也没有要求可验证数据注册表必须是区块链，可信 database、分布式账本和其他存储方式都可以承担那一层。^[3] VC 可以携带签发者对某个主体作出的可验证声明。例如，一个组织可以签发关于某个 Agent 获准处理一类工作的声明。资源服务仍然要按自己的访问控制框架和策略判断。^[4] 如果凭据机制提供状态检查，也要检查它的状态。^[5]

Blockchain 在这里的合适位置，是多方能够访问并同意治理规则时的一层共享、可核验记录，而不是每个动作的目的地。NIST 对 blockchain 的描述是 tamper-evident、tamper-resistant 的分布式账本，不是一个能保证所有输入都真实的机器。它可以帮助参与者检查记录、签名和出处后来有没有被改动；它不能替我们判断传感器有没有错、服务有没有真的完成、某个 Agent 有没有撒谎。^[6]

这也决定了隐私边界。大多数原始数据、prompt 和业务细节不需要公开。很多时候，保留在合适的系统里，必要时只共享带有适当披露和访问控制的签名回执或 hash commitment，就够了。签名首先证明的是签发者作出了一项声明；hash 只能让收到原始内容的人检查它是否与先前承诺的内容一致。可审计不是把一切摊在公共网络上；它是让该看的人，在该看的时候，能够验证该看的那部分。

Agent 让多方核验和对账从例外变成日常

举一个容易计量的示意。假设某个组织给项目 P 分配了 10,000 次文件检索 API 的使用额度，有效期到 9 月 30 日；它再委托 Agent A 只为项目 P 使用这份额度。系统需要写清楚服务由谁提供、Agent 可以调用哪些方法、每次调用扣多少单位、超过范围时怎么处理。

当 Agent A 在授权范围内调用 API 时，服务方可以出具一份签名使用回执，写明它看到的是哪个 Agent、什么时间、多少次调用、所引用的委托和额度编号。回执首先证明的是服务方作出了“其计量系统按这个规则记录了一次请求”的声明，不自动证明这份声明或任何业务结果一定正确。如果每一层都保留可相互引用的记录，而且相关主体能够访问它们，这些记录就能帮助追查和对账异常，不会自己替各方裁决争议。

在这个例子里，真正的 payment 可以在 billing 完成后发生，也可以用预先拥有的 credit、合同约定的额度或别的结算方式处理。系统不需要让 Agent 为每一次检索即时付款。把文件检索换成计算、模型推理、数据访问、存储，或一个专用工具完成的服务，结构都类似，只是计量规则不同。

Agent 的特殊之处不在于它让这种记账第一次出现，而在于它会以机器的速度、跨系统地把这种记账放大。复杂的 credit、会员和审计机制历史上更常见于大型组织；现在一个小团队也会同时用很多模型、数据源和自动化服务，它同样需要把“谁能用什么、用了多少、结果由谁承担”说清楚。

如果这些单位只能藏在每家公司的私有表里，系统当然仍能运行。但一旦一个业务要接入多个服务商、多个 Agent 或多个客户，它就可能反复遇到集成和对账工作。DID、VC、细粒度委托、只追加不随意回写的账本和可验证回执的意义，不是替代每一个 database，而是让不同服务商至少能用可相互引用的格式表达“谁被委托、有什么额度、发生了哪次使用”。这仍需要兼容的字段、语义、信任策略和争议流程，不会自动发生。

这条路没有魔法。身份不等于授权，签名不等于真实，账本不等于服务质量，token 也不等于一项服务已经存在。真正的系统还要处理撤销、期限、隐私、异常、争议和谁来承担责任。这些麻烦一点都没有因为用了 blockchain 就消失。

这也是 ARC 正在建设成的环境：Blocklet 可以识别带有 DID 的调用者，在该 DID 的数据空间中读写数据，并通过 Provider 访问资源。对 Agent 来说，payment 只是其中一个关系；身份、委托、凭据、资源使用权和记录也都要有各自清楚的位置。ArcBlock 当前的方向，是在适当的信任边界上让重要的授权和使用记录更可核验。一个 token 只有在它代表一项真实服务、权利或资格时才有意义；跨服务的额度、凭据、结算和对账仍要和具体业务、服务商及治理规则一起定义。

参考

附录：来源怎样约束本文

这篇文章把四类材料放在一起，但不把它们混成同一种证据：

证据地图

这些资料的作用不是替这篇文章背书一个结论，而是给关键术语划出边界。本文不判断任何 token 的法律性质、合规性或市场价值；它讨论的是：一个数字化业务对象何时能准确地代表已经存在的服务使用权、资格、记录或责任链。