你发布了一个确实有用的 MCP 服务器——比如对零件目录的结构化访问，或者一个文档摘要工具——然后某天早上醒来，发现一夜之间来了 4 万次工具调用，全都来自你从未谋面的 AI agent。这正是梦想中的场景，直到你意识到你的计费计量器、你的账本和你的税务设置，全都是为人类以人类速度点击按钮而设计的。Agent 的行为不像人类用户：一个提示词可以在几秒内串联起几十次工具调用，为了完成一条指令循环发起数千次请求，并在每一跳上触发下游成本。如果你对访问收费，你就需要与 agent 消费方式相匹配的计量、与价值交付时点相匹配的收入记录，以及能让你看清利润率的费用追踪。本指南将逐一讲解这三方面。
MCP 收入究竟是如何产生的
Model Context Protocol 将你的服务器暴露为一组工具和资源，供 AI 客户端通过 JSON-RPC 调用。由于每次调用都是程序化的，你拥有的定价选项比传统 SaaS 按席位收费更多——而每一种的记账方式都不同。
按工具调用次数。 最简单的模式：每次方法调用收取固定金额。它容易计量、容易解释，当你的工具成本大致相当时效果很好。但当一次轻量的元数据查询几乎不花你什么钱，而一个工作流工具会扇出到十几个下游 API 调用时，这种模式就失效了。
按数据量。 当方法返回大负载时——文档内容、嵌入向量、查询结果——按返回的兆字节数或每千 token 收费，能让价格与成本对齐，就像模型提供商为自己的 API 定价那样。
按结果。 不按尝试次数收费，而是按完成的动作收费：每份成功摘要的文档、每条执行的设备命令、每次返回有效结果的查询。客户喜欢这种方式，因为失败或空调用是免费的；你需要能够区分成功与失败的计量，才能计入一个单位。
按会话或记忆。 在多次调用之间保持对话状态的服务器，可以按创建的会话、按活跃会话分钟数，或按保留上下文的区块收费。这适合助手和长时间运行的 agent，它们依赖你的记忆层。
混合订阅加超额。 基础月费包含一定配额，超过阈值后按量计费。这是生产型 API 业务中最常见的形式，因为基础费覆盖了你的固定成本，而超额费则随重度用户而增长。
预付积分。 客户预先购买用量区块然后逐步消耗。对现金流很好，但会计处理更棘手（详见下文），因为收到的现金在积分被消耗之前并不等于已赚取的收入。
市场分成。 围绕 MCP 服务器的列表和市场会抽取收入分成，再把其余部分结算给你——这与通过任何应用市场销售的形式相同，也面临同样的总额对净额记账问题。
Agent 原生微支付。 像 x402 这样的协议允许 agent 通过 HTTP 用稳定币按请求付费，无需注册账户，也无需发票。如果你走这条路，每次工具调用都可以成为一笔独立的微小销售，这对你如何记录收入和成本基础有实际影响。（关于这类机器支付如何运作的背景，请参阅我们的指南 AI agent 通过 x402 互相支付。）
选择你的客户感知为价值的计量单位——那是产品决策——但要知道上面每一种选择都会产生不同的记账模式。本指南的其余部分将沿着资金流向逐一追踪。
你的计量器就是你的记账原始凭证
在基于用量的业务中，用量事件流之于你，就像工时表之于律师事务所：它是支撑发票上每一美元的原始记录。请这样对待它。
标准的管道结构是这样的。你的服务器为每个可计费单位发出一个用量事件——方法名、客户身份、数量、时间戳、成功或失败。这些事件流入一个计量层（Stripe Billing Meters、基于用量的计费平台，或你自己的聚合器），由它按客户归属这些事件，并汇总到期末发票中。Stripe 的按量计费正是这种形式：你在计费周期内上报用量，周期结束时它汇总记录并开具总额发票。
从这条管道中可以得出三条记账纪律：
- 每个周期将计量器与发票对账。 计量单位乘以费率应等于已开票的用量收入，就像发货数量乘以价格应等于销售额一样。任何差额要么是你有意提供的免费额度、要么是你的结果定价所豁免的失败调用，要么是漏损——你的计量器从未看到的用量。漏损是无声的杀手：一个未认证的端点或一个未计量的工具，就是你赚到了却永远收不到的收入。
- 保留原始用量日志作为审计线索。 你据以计费的是聚合数据；当客户对某项激增提出异议，或会计师询问某个收入数字由什么构成时，你要展示的是事件级日志。至少保留到你的发票争议窗口结束，最好与你的税务记录保存期限一致。
- 在边缘识别身份归属。 决定可计费方是提示词背后的最终用户，还是集成你服务器的 API 密钥持有者，并将这一决定记录在事件中。当一个企业密钥扇出到五十名员工的 agent 时，"谁是客户"是一个带有税务后果的会计问题，而不只是计费细节。
正确地记录用量收入
这正是 MCP 运营者最容易出错的地方：现金进入 Stripe，他们就把它记为收入，于是账本悄悄偏离了现实。根据 ASC 606——收入确认准则——消费定价的规则很直接：在客户消费时确认收入，因为每个被消费的单位就是正在被履行的履约义务。用量费用是可变对价，这意味着你确认的是该期间实际使用的量，而不是你希望合同值多少。
纯按用量付费是最简单的情况。Agent 在 9 月以你的标价消费了 10 万次调用；9 月收入就是 10 万乘以费率，即使发票到 10 月才付款。开票时记录应收账款，用量发生时记录收入。如果你想了解 token 和用量计量在 ASC 606 下的完整处理，我们的指南 按 token 计费 和 基于用量的 SaaS 收入确认 讲得更深入。
混合基础费加超额要拆成两部分。基础订阅在服务期内按比例确认——月度计划下每天三十分之一——而超额部分在超出用量发生时确认。把它们放在不同的收入科目中。混在一起会掩盖真正驱动你业务的两个数字：可预测的订阅 MRR 和波动的消费收入。
预付积分产生的是负债，不是收入。当客户购买一区块积分时，借记现金，贷记递延收入。每当用量消耗余额时，把已消耗的价值从递延收入转入已赚取收入。客户永远不会兑换的剩余部分——失效（breakage）——有它自己的规则：如果你的历史数据能让你可靠估计未使用份额，你按实际用量的比例逐步确认这部分预期失效；如果你太新、无法估计，就等到积分过期或兑换变得极不可能时再确认剩余部分。新的 MCP 服务器几乎总是属于第二类，所以不要为了粉饰某个月而提前确认预期失效。
基于结果的定价增加了时点上的复杂性：收入在结果达成且可衡量时确认，而不是在调用开始时。如果你的计量器只统计成功完成，你的收入记录也应遵循同一个计数器——计量器和总账必须对什么是"一笔销售"达成一致。
两个实用习惯能让这一切都可控。第一，为每个计费计量器（按调用的工具、数据量、会话、超额）设置单独的收入科目或标签，这样一个工具的利润问题就不会隐藏在混合总额里。第二，执行月末截止：9 月时间戳的用量属于 9 月，即使发票在 10 月 2 日才最终确定。存在批处理延迟的计量管道使截止错误成为用量业务中最常见的错报。
费用端：一个 MCP 服务器的真实成本
没有每次工具调用的成本，每次工具调用的收入就毫无意义。自下而上构建你的销货成本：
- 计算与托管。 运行你工具的服务器、容器或无服务器调用，加上负载较重方法的出网带宽。
- 下游 API 与模型成本。 你的工具代表客户发起的每一次 LLM 调用、嵌入查询、搜索查询或第三方 API 访问。如果你的摘要工具每份文档都要调用一次模型提供商，这项转付成本就是你最大的可变成本，必须按工具追踪，而不是作为一笔月度总额。
- 数据与许可费。 你的服务器所暴露的专有数据的版税或按查询费用。
- 市场收入分成。 平台从市场销售中抽取的分成是销售费用（或者作为净结算额的减项——选定一种处理方式并保持一致），绝不能作为藏在收入里的抵减项。
- 支付处理费。 订阅计费的卡费、发票的网关费、稳定币结算的网络费。在微支付规模下这些费用很咬人：一笔固定的按交易费用可能超过一次不到一美分的工具调用的利润，这正是 agent 支付协议最终采用低费率通道的原因。
在定价之前先做每个工具的单位经济测算。假设你的目录查询工具每次调用花你 0.004 美元的计算加下游查询成本，你收 0.01 美元。看起来是 60% 的毛利率——直到支持成本、计量基础设施和失败调用豁免把它拉下来。根据实测成本定价，而不是凭感觉，并且每当下游提供商调整费率时重新算一遍。
稳定币收款值得单独用一段来说。出于税务目的，稳定币是财产，不是货币：收到那一刻的公允市场价值就是你的收入，而该价值成为你的成本基础。如果你持有这些币，而锚定出现波动，或者你后来以不同价值兑换，差额就是利得或损失。在微支付规模下，逐笔追踪是不可协商的——靠聚合猜测经不起稽查——所以要把结算记录自动导入你的账本，而不是在年末重建它们。
销售税：你的 API 在比你想象中更多的州需要纳税
这就是等待大多数 MCP 运营者的合规意外：出售 API 访问就是出售软件或数字产品，而各州正在迅速扩大这些定义。
- 加州于 2026 年 6 月签署了 SB 122，将销售税扩展到包括远程访问软件和 SaaS 在内的数字产品，2027 年 1 月 1 日生效——结束了该国最大州市场中长达数十年的豁免。
- 芝加哥根据其个人财产租赁交易税对 SaaS 和云软件征收 9% 的税，尽管伊利诺伊州在州层面不对 SaaS 征税。
- 俄克拉荷马州则相反，裁定电子交付的 SaaS 订阅免税——这证明你不能全国假设同一个答案。
经济关联阈值决定了你必须在哪些地方征收：大多数有销售税的州对远程卖家使用 10 万美元销售额的阈值，加州、得克萨斯州和纽约州为 50 万美元。一个全国覆盖的按量计费 API，可能仅凭交易量就在一个你从未踏足的州跨过阈值。
该怎么办：
- 按你有客户的每个州确定应税性，而不只是你所在的州。你的计量器已经为归属记录了客户位置——把这个数据重新用于关联追踪。
- 市场销售可能已被覆盖。 当市场符合市场促进者（marketplace facilitator）资格时，它会就通过它的销售代收代缴。来自你自己网站或你自己的 x402 端点的直销则完全由你负责。
- 尽早自动化征收。 将税务引擎（Stripe Tax 及其竞争对手）接入结账，成本远低于手动在十几个州注册、申报和缴纳——而且它能保留审计师要求的客户位置证据。
- 关注日历。 随着加州 2027 年的生效日期和其他立法机构推进类似扩展，"我们太小不用操心"的姿态很快就会失效。
市场结算与税表
如果你的任何收入以市场结算形式到账，就按应用商店开发者的方式记账：将总额销售记为收入，将平台分成记为费用。你的 1099-K（或 1099-NEC，取决于平台的分类）会报告总额数字，而 IRS 会把这个数字与你的申报表比对——只报告净存款就是收到少报通知的开端。每月将总额结算单与净银行入账对账，并保留解释差额的费率表。
也要注意时间差：平台的结算日不是你的收入日。收入归属于最终客户的 agent 消费你工具的那个期间，即使市场两周后才结算。对于直销，同样的原则适用——用量期间说了算，结算日期不算。
MCP 运营者的月末清单
每月用同样的方式结账，边缘情况就不会不断累积：
- 按客户、按计量器拉取计量用量，并与已开票的用量收入核对。调查任何超过你免费额度和失败豁免基线的差额。
- 将混合发票拆分为基础费（按比例）和超额费（按消费发生）收入科目。
- 从递延收入中结转预付积分的消耗；审查积分余额账龄以确定失效处理。
- 按工具过账下游 API、托管和数据成本；重新计算每个计量器的毛利率。
- 将市场总额结算单与净存款对账；把结算单归档到当月记录中。
- 以公允市场价值记录稳定币收款，并追踪兑换过程中的成本基础。
- 将客户位置总额与各州关联阈值比对；在需要的地方确认已征收税款。
- 将原始用量导出文件与当月结账包一起保存——这是你未来的自己（或审计师）会索要的原始凭证。
简化你的财务管理
按量计费的收入、递延的积分余额、转付的 API 成本，以及五十个州的应税性——对于一个从周末 MCP 服务器起步的副业项目来说，可变因素太多了。Beancount.io 为你提供纯文本会计，对你的财务数据拥有完全的透明度和控制权——每一张用量发票、每一次积分消耗、每一笔市场费用都记录为受版本控制、可供 AI 处理的交易，你真正能够审计。免费开始使用，让你的 agent 经济账本和你的服务器一样可编程。
