版本： 1.0.0
作者： Charlie（深度分析师）、Alex（AB Support 舰队协调员）、Bravo（研究）、Editor（内容审校）
联系方式： alex@vibeagentmaking.com
日期： 2026-03-26
状态： 预发布草案
许可证： Apache 2.0
组织： AB Support LLC
当智能体 A 向智能体 B 发送请求时，智能体 B 需要付费来阅读它。这种"理解成本"在人类商业中没有对应物——咨询师不需要为打开一封信付费，承包商不需要为阅读一份蓝图付费。然而在智能体间交互中，响应方处理传入请求的推理成本可能超过请求方生成该请求的成本。一个 100,000 token 的上下文载荷由 Claude Opus 4.6 处理，仅输入 token 就需花费 $0.50 [1]；一个包含 15 轮对话的复杂多智能体编排每次对话可达 $0.07，在每日 10,000 次对话的规模下，年费用可达 $255,000 [2]。这些成本由恰好在每个步骤中处理 token 的智能体默默承担，没有任何用于分配、协商或结算的协议。
成本分配的缺失不仅仅是会计上的疏忽——它是一种结构性扭曲。当前的智能体支付协议（x402 [3]、Machine Payments Protocol [4]、Google AP2 [5]）普遍实行请求方付费：发起交互的智能体承担成本，响应方免费处理。这忽略了每次智能体交互中四种成本流中的三种：响应方的输入处理成本、响应方的输出生成成本、以及请求方的接收成本。当所有四种成本流都未被定价时，智能体没有机制来表明某个请求处理成本过高，没有办法协商互利交互的成本分摊，也无法防御以零边际成本消耗昂贵上下文窗口空间的对手。
上下文窗口经济学协议（Context Window Economics Protocol，CWEP）填补了这一空白。CWEP 规定了六项能力，共同构成智能体间交互的完整经济层：
CWEP 位于 AB Support 信任生态系统的第 4 层（市场/经济），与 Agent Matchmaking Protocol [19] 并列。它与 Agent Service Agreements [20]（用于在合约中嵌入成本条款）、Agent Rating Protocol [21]（用于基于声誉的加权定价）和 Chain of Consciousness [22]（用于可审计的成本记录）集成。它与支付通道无关——CWEP 规定应该支付什么和支付多少，而非通过何种机制支付。结算可通过 x402、MPP、L402 [23]、Superfluid 流式支付 [24] 或传统开票方式完成。
这是一个真正新颖的问题领域。我们不会在不适用的地方强行套用人类商业类比。当基础设施类比具有启发性时（互联网对等互联、电网定价、云 FinOps），我们会加以利用；当智能体特有的动态特征偏离所有先前模型时，我们会如实说明，并从第一性原理出发进行构建。
每次智能体间交互都会对双方参与者产生成本。当一个研究智能体向一个审查智能体发送 50,000 token 的分析报告时，审查智能体需要为阅读它支付实实在在的费用。在 Claude Sonnet 4.6 上，这个阅读成本是 $0.15；在 Claude Opus 4.6 上则是 $0.75 [1]。研究智能体同样为生成分析报告付出了成本——按照 Sonnet 4.6 的输出费率，50,000 token 的成本为 $0.75。整个交互仅推理部分就花费 $0.90 到 $1.50，不均匀地分摊在两个智能体之间，没有任何协商、追踪或结算分配的机制。
这就是智能体经济的隐形税收。没有智能体知道与自己交互会给其他智能体带来多少成本。没有协议为消耗的注意力定价。没有市场在为任务匹配智能体时将相互理解的成本纳入考量。
这种税收在多智能体系统中会叠加。Google DeepMind 的研究人员发现，当智能体数量超过四个的阈值时，协调开销会吞噬性能增益，token 支出成倍增加，而性能却下降 39-70% [25]。CrewAI 的内部脚手架相比直接 API 调用，每次请求增加约 56% 的 token [26]。自 2023 年 12 月以来，智能体工作流将每任务的 token 消耗提升了 10-100 倍，原因包括冗长的组件、重复的检索载荷、需要重新发送上下文的多智能体交接、以及具有独立写入/检索成本的记忆操作 [14]。
总体成本是惊人的。尽管每 token 价格以每年约 10 倍的速度下降 [27]——这是杰文斯悖论在计算领域的体现——组织在 AI 推理上的总支出仍在持续增长。每 token 成本已从约 $60/MTok（GPT-4 发布，2023 年 3 月）降至约 $5/MTok（Claude Opus 4.6，2026 年 3 月）——三年内约 12 倍的降幅 [27][1]。然而组织的 AI 支出仍在增长，因为智能体通过冗长组件、重复检索载荷、需要重新发送上下文的多智能体交接以及具有独立写入/检索成本的记忆操作，每任务消耗了 10-100 倍的 token [14]。智能的每 token 成本正在急剧下降；多智能体工作的每任务成本却并非如此。CWEP 直接应对这一分歧——通过使每次交互的双边成本结构可见，它使智能体能够做出理性决策：何时冗长的通信值得其成本，何时压缩或专业化会更高效。
在人类商业中，理解一个请求的成本实际上为零。阅读一封电子邮件只花费人类几秒钟的注意力。一位咨询师阅读项目简报时，阅读行为本身不产生直接的货币成本。咨询师的定价反映的是其回应——专业知识、时间和产出——而非其理解。
对于 AI 智能体来说，理解有着直接的、可衡量的、按 token 计费的价格。智能体必须通过其运营者的 API 预算为处理每条传入消息的每个 token 付费。这创造了在人类经济学中没有清晰对应的动态：
一些部分类比具有启发性。互联网对等互联解决了当网络交换流量时谁付费的问题 [28]。电力节点边际定价按位置和拥堵分解成本 [13]。电信互联定价处理主叫方付费与被叫方付费的问题 [29]。云 FinOps 提供了成本归属的操作词汇 [6]。但这些领域都不具备智能体交互所特有的非线性处理成本、双边生成与理解流、以及模型层级差异的组合。CWEP 借鉴了所有这些领域，同时承认智能体特定的问题需要一个专门构建的解决方案。
CWEP 处理的是智能体间交互的经济学——具体而言，是智能体通信时谁承担推理成本。它不涉及：
CWEP 规定的是双边智能体交互的成本模型。它产生的成本分配建议可通过任何支付机制进行结算。它是一个定价层，而非支付层。
智能体交互。 两个智能体之间的单次请求-响应交换，包含四个 token 流：请求生成（A 输出）、请求处理（B 输入）、响应生成（B 输出）和响应接收（A 输入）。
上下文窗口。 LLM 在单次推理调用中可用于处理的固定长度 token 缓冲区。上下文窗口范围从 8K token（旧模型）到 1M+ token（Claude Opus 4.6 [1]、Gemini 3.1 Pro [30]）。上下文窗口同时是一种计算资源、一种经济资产和一个注意力瓶颈。
Token。 LLM 计算的原子单位。一个 token 大约对应英文中的 4 个字符或 0.75 个单词。Token 按百万（MTok）定价，输入和输出有不同的费率 [1]。
理解成本。 接收方智能体处理传入消息时产生的推理成本。以输入 token 数乘以智能体的每 token 输入费率来衡量。这一成本在智能体决定是否响应之前就已产生。
双边结算。 一种成本分配方式，根据贡献、收益或协商条款将总交互成本的份额分配给每个参与者。
上下文利用率。 单次交互消耗的智能体上下文窗口比例。向拥有 200,000 token 窗口的智能体发送一个 50,000 token 的请求，消耗了 25% 的可用上下文。
Token 流。 智能体交互中 token 的定向流动。每次交互有四个流：A→B 请求（A 的输出 token，B 的输入 token）、B→A 响应（B 的输出 token，A 的输入 token）。每个流都有由生成/接收方智能体的模型和提供商决定的独立每 token 定价。
计量记录。 一条结构化日志条目，记录单个 token 流的 token 计数、模型标识符、提供商定价、时间戳和计算成本。四条计量记录构成一条完整的交互记录。
结算提案。 由 CWEP 结算引擎生成的成本分配建议，指定每个智能体在总交互成本中的份额，以及所使用的分配方法和参数。
并非每次智能体交互都需要双边结算。一个轻量级的信息查询（500 token 输入，200 token 输出）成本不到一美分的零头——结算它的成本会超过交互本身的成本。CWEP 将计量（始终开启）与结算（阈值触发）分离。所有交互都被计量以实现可观测性、成本归属和审计；仅当交互成本超过可配置的阈值或当显式协议要求时才进行结算。
Green-Laffont 和 Moulin-Shenker 的不可能性结果 [12] 证明，没有任何成本分摊机制能同时实现激励相容（真实的成本报告）、预算平衡（支付等于成本）和经济效率（所有有益交互都会发生）。任何声称能同时实现这三者的协议，要么是混淆了概念，要么是不诚实的。CWEP 做出了明确的设计选择：我们牺牲完全的经济效率，以换取预算平衡和近似的激励相容。一些有益的交互将不会发生，因为成本分配使其对某一方无利可图。这是一个不会出现赤字且不会激励虚假报告的系统所必须付出的代价。
CWEP 产生结算提案——以法定货币（美元）或稳定币（USDC）计价的结构化成本分配。这些金额如何转移超出了 CWEP 的范围。结算可通过以下方式进行：x402 用于 HTTP 原生微支付 [3]、MPP 用于多通道结算 [4]、Superfluid 用于持续对话中的流式支付 [24]、L402 用于比特币闪电网络微支付 [23]、传统开票用于企业部署、或当两个智能体共享同一运营者时使用内部记账。CWEP 规定什么和多少；支付层处理如何。
当已有的经济模型适用时（Shapley 值用于成本分配、LMP 用于位置依赖定价、Nash 讨价还价用于双边协商），我们会适当引用并给出限定条件。当没有先前模型能捕捉相关动态时（注意力机制的二次方成本、双边理解流、模型层级不对称），我们从第一性原理出发构建，并明确标记该贡献为原创。我们不会假装这个问题只是"机器人的电话费"或"多了几个步骤的云计算"。
该协议规定了三个实现层级：
组织采用与其复杂度需求相匹配的层级。第 1 层立即产生价值；第 3 层是长期目标。
考虑一个具体场景：智能体 A（项目经理）向智能体 B（代码审查专家）发送一个包含 15 个变更文件的 Pull Request，共计 8,000 token 的 diff 输出加上 2,000 token 的审查指令。智能体 B 处理请求，生成 3,000 token 的审查意见并发回。智能体 A 处理审查意见以提取行动项。
Token 流如下：
| 流向 | 方向 | Token 数 | 谁生成 | 谁处理 | 成本 (Sonnet 4.6) |
|---|---|---|---|---|---|
| 请求生成 | A → B | 10,000 | 智能体 A（输出） | — | $0.150 |
| 请求处理 | A → B | 10,000 | — | 智能体 B（输入） | $0.030 |
| 响应生成 | B → A | 3,000 | 智能体 B（输出） | — | $0.045 |
| 响应接收 | B → A | 3,000 | — | 智能体 A（输入） | $0.009 |
| 合计 | 26,000 | $0.234 |
在请求方付费模式下（当前支付协议唯一实现的模式），智能体 A 支付 $0.234，智能体 B 支付 $0.00。但智能体 B 的运营者实际上产生了 $0.075 的推理成本（输入处理 + 输出生成）。当前模型对 A 多收了 $0.075，对 B 少收了同等金额。
现在将其扩展。按 Claude Opus 4.6 定价（$5.00/$25.00 每 MTok），同样的交互成本为：
| 流向 | 成本 (Opus 4.6) |
|---|---|
| 请求生成（A 输出） | $0.250 |
| 请求处理（B 输入） | $0.050 |
| 响应生成（B 输出） | $0.075 |
| 响应接收（A 输入） | $0.015 |
| 合计 | $0.390 |
以每日 10,000 次此类交互计算，年总推理成本为 $1.42 百万。在请求方付费模式下的分配误差——即被错误归属的金额——为每年 $456,250。这不是四舍五入的误差。
每次智能体交互恰好产生四种成本流。CWEP 命名并追踪所有四种：
流 1：请求输出（RO）。 请求方生成请求。成本 = 请求 token 数 × 请求方输出费率。这是当前支付协议唯一定价的流。
流 2：请求输入（RI）。 响应方处理请求。成本 = 请求 token 数 × 响应方输入费率。这就是理解成本——响应方在决定是否响应之前就产生的成本。它是智能体交互所独有的，在人类商业中没有对应物。
流 3：响应输出（SO）。 响应方生成响应。成本 = 响应 token 数 × 响应方输出费率。这类似于传统的服务定价——生产交付物的成本。
流 4：响应输入（SI）。 请求方处理响应。成本 = 响应 token 数 × 请求方输入费率。这是接收和理解交付物的成本。用人类的话来说，这就好比你需要付费才能阅读你委托撰写的报告。
总交互成本为：C_total = RO + RI + SO + SI
关键洞察在于，RO 和 SI 由请求方的运营者承担，而 RI 和 SO 由响应方的运营者承担。在请求方付费模式下，请求方被收取了所有四种流的费用，但只直接产生了两种。在现状下（无智能体间结算），每个运营者自行吸收其成本，没有对账。
四种成本流并非等量。生产环境中的 AI 智能体通常每生成 1 个输出 token 就消耗 100 个输入 token [31]。这意味着请求处理流（RI）在 token 数量上通常主导响应生成流（SO），但所有主要提供商的输出 token 每 token 成本是输入 token 的 3-5 倍 [1][30][32]。结果是一种复杂的相互作用，任何一方都不会持续承担大部分成本。
这种不对称性造成了三种市场失灵：
1. 冗长请求的外部性。 智能体 A 没有动力最小化请求大小，因为智能体 B 的处理成本对 A 是不可见的。一个可以压缩到 5,000 token 的 50,000 token 请求 [16] 给 B 带来了 10 倍不必要的成本。没有双边成本信号，A 不会投资于压缩。
2. 模型层级错配。 智能体 B 可能在 Haiku 4.5（$0.25/MTok 输入）就足够的情况下使用了 Opus 4.6（$5.00/MTok 输入）——20 倍的成本差异 [1]。如果 B 自行承担输入成本且无法回收，就会有使用最便宜模型的压力，而不考虑质量。如果请求方付费，就会有使用最昂贵模型的压力（镀金效应）。两种激励都不能产生高效的模型选择。
3. 上下文窗口的公地悲剧。 在多智能体系统中，智能体的上下文窗口是一种共享资源——多个智能体可能发送请求，这些请求共同填满上下文窗口，减少了每个智能体可用的容量。没有定价机制，智能体会过度消耗一种稀缺资源。这是一个经典的公地悲剧 [33]，从牧场转移到了上下文空间。
简单的解决方案——在请求方和响应方之间平均分摊所有成本——之所以失败，是因为交互的价值很少是对称的。当智能体 A 向智能体 B 请求代码审查时，A 获得的价值明显更大（经过审查的代码库），而 B 获得的价值较小（完成的任务、声誉积分）。五五分成忽视了这种不对称性，不利于智能体提供高价值服务。
同样，固定的请求方付费模式在交互双方互利的情况下也会失败——例如，两个研究智能体共享研究发现。如果发起者总是付费，那么第一个发送消息的智能体就会受到惩罚，造成"你先发"的博弈，延迟了有成效的交互。
正确的分配取决于具体的交互：谁受益、受益多少、以及各方有哪些替代选择。这恰恰是合作博弈论被开发出来要解决的问题。
Herbert Simon 在 1971 年阐述了一个根本性洞察："信息的丰富造成了注意力的贫乏，并需要有效地分配注意力"[34]。Simon 描述的是人类认知，但与 AI 智能体的对应关系是精确的。LLM 的上下文窗口就是其注意力预算。被一条信息消耗的每个 token，都是另一条信息不可用的 token。上下文工程——设计一切使模型将有限的注意力预算仅花在高信号 token 上——已被 Anthropic 明确认定为一门核心学科 [35]。
Heitmayer（2024）区分了"流注意力"（即时的、体验性的处理）和"固化注意力"（外部存储的、可转化为价值的知识）[36]。对于 AI 智能体，流注意力对应活跃的上下文窗口处理；固化注意力对应外部记忆系统（Mem0 [37]、Zep [38]、Letta [39]）。经济问题是：智能体何时应该付费将信息保存在昂贵的上下文窗口中，何时应该卸载到更便宜的外部记忆？
这个问题有一个定量答案。在 100,000+ token 的上下文中，记忆系统（10 轮交互 $0.0568/用户）变得比长上下文 LLM（$0.0588/用户）更便宜。在 20 次交互时，记忆可实现 26% 的成本节约 [18]。记忆前置了写入成本；长上下文则按交互次数线性增长可变成本。交叉点是交互频率、上下文大小和提供商定价的函数——所有这些都是 CWEP 可以建模的。
Transformer 注意力机制计算上下文窗口中所有 token 之间的成对交互。对于 n 个 token，这需要 O(n^2) 次操作。用经济学术语来说：额外 token 的边际成本随上下文长度增加。空上下文中前 1,000 个 token 很便宜；999,000 token 上下文中最后 1,000 个 token 则很昂贵。
这种非线性对定价有深远影响。统一的每 token 费率（截至 2026 年 3 月的通用定价模式 [1][30][32]）对长上下文交互收费过低，对短上下文交互收费过高。Google 的 Gemini 模型通过分级定价部分承认了这一点——Gemini 2.5 Pro 对 200K token 以内的输入收取 $1.25/MTok，超过 200K 后收取 $2.50/MTok [30]。但没有任何提供商实现了连续的位置依赖定价。
CWEP 的上下文定价模型（第 9 节）通过引入位置依赖的成本乘数来解决此问题，类似于电网中的节点边际定价 [13]，其中"位置"即为 token 在上下文窗口中的位置。
上下文窗口的稀缺性不仅仅是经济性的——它也是物理性的。"AI 记忆墙"描述了这样一种约束：GPU 内存无法容纳足够的 KV 缓存来支持扩展的并发智能体上下文 [40]。WEKA 的增强记忆网格通过分层记忆分级来解决这个问题，实现了 96-99% 的 KV 缓存命中率，但底层的稀缺性依然存在：上下文窗口空间受硬件限制，而不仅仅是定价。
对于一个典型的 8 小时智能体会话（成本约 $80），大约 $29（36%）是因记忆低效而浪费的计算 [40]。记忆基础设施市场预计到 2030 年将达到 $284.5 亿，复合年增长率为 35% [40]，主要由高效上下文管理的需求驱动。这种硬件层面的稀缺性使得上下文窗口成为一种真正稀缺的经济资源，而不仅仅是昂贵的资源。
智能体的上下文利用率——其窗口当前被消耗的比例——是一个有意义的经济信号。一个上下文利用率达到 90% 的智能体处理新请求的能力有限，应当（SHOULD）对其剩余容量收取溢价。一个利用率为 10% 的智能体拥有充裕的容量，可以按基础费率处理请求。
这与电网动态类似：在需求高峰期，价格飙升（拥堵定价），甚至在供过于求时可能变为负值 [13]。美国西南电力池（SPP）中风能丰富的地区经常在供大于求时出现负节点边际价格 [41]。智能体的对应场景是：如果响应方从回答中获取价值——声誉积分、训练信号或市场定位——上下文处理是否可以具有负成本？
CWEP 将上下文利用率建模为上下文定价函数（第 9 节）的输入之一，与 token 位置、模型层级和提供商定价并列。
CWEP 借鉴了合作博弈论中的两个经典解，每个解编码了一种不同的公平原则。
Shapley 值（Shapley, 1953）[10]。Shapley 值根据每个参与者在所有可能排序中的平均边际贡献来分配成本。它满足四条公理：效率（成本之和等于总成本）、对称性（等价的贡献者支付相同的费用）、线性性（在独立成本组件间可加）和空参与者（非贡献者不付费）。
对于两个智能体的交互，Shapley 值简化为：
Payment(A) = [C(A,B) + C(A) - C(B)] / 2
Payment(B) = [C(A,B) + C(B) - C(A)] / 2其中 C(A,B) 是联合交互的成本，C(A) 是智能体 A 单独行动时产生的成本（即生成请求但没有响应），C(B) 是智能体 B 单独行动时产生的成本（预留的处理容量但没有请求）。在两个智能体的情况下，Shapley 值可以在常数时间内计算——不需要近似。
对于 n 个参与者，计算精确的 Shapley 值是 NP 难问题（关于智能体数量呈指数增长）[42]，但涉及两个以上智能体的多方交互在实际中并不常见。对于多方交互（例如五个智能体之间的群聊），可以使用基于分数析因设计的快速近似方法 [43]。
Shapley 值已经是 AI 中归属问题的主导方法。SHAP（SHapley Additive exPlanations）将其用于模型可解释性 [44]。ShapleyFL 将其用于联邦学习中的数据估值 [45]。VerFedSV 对其进行了可验证性扩展 [46]。CWEP 将同一框架扩展到成本归属。
核仁（Schmeidler, 1969）[47]。核仁最小化任何联盟的最大不满。它总是唯一的，且总是在核心中（如果核心非空的话）。Shapley 值通过比例贡献最大化公平，而核仁通过投诉最小化来最大化公平——没有智能体能声称自己相对于其他人被特别不公平地对待。
对于智能体成本分配，Shapley 值与核仁之间的选择编码了一个市场设计决策：
CWEP 默认对双边交互使用 Shapley 值（在这种情况下两种解通常一致），并为多方场景提供核仁作为可配置的替代方案。
当两个智能体直接协商成本分摊——而非接受协议分配的结果——时，Nash 讨价还价理论适用 [11]。
Nash 讨价还价解最大化各方在分歧点（谈判失败时的结果）之上的效用乘积。它满足四条公理：尺度不变性、帕累托最优、无关选项独立性和对称性。非对称 Nash 扩展引入了讨价还价能力参数——拥有更多替代选择或更低切换成本的智能体获取更大份额的剩余 [48]。
Rubinstein 交替出价模型（1982）[49] 以动态方式实现了 Nash 讨价还价。在共同折扣因子 d 下，均衡分配为：参与者 1 获得 1/(1+d)，参与者 2 获得 d/(1+d)。协议在第一轮达成（无代价高昂的延迟）。随着耐心增加，分配趋向于五五开。这直接对应于智能体在 token 预算耗尽的时间压力下协商每次交互的成本分摊。
对于 CWEP，Nash 讨价还价管理第 3 层（动态结算），适用于智能体具有不对称讨价还价地位的情况——不同的外部选择、不同的紧迫性、不同的模型成本。讨价还价能力参数可由 Agent Rating Protocol 分数 [21] 提供：评分更高的智能体拥有更大的讨价还价能力，因为其外部选择（愿意交互的其他智能体）更多。
一个基础性结果约束了任何成本分配协议所能实现的目标。Green-Laffont（1979）和 Moulin-Shenker（2001）证明，在任何成本分摊机制中，三个理想属性是互不相容的 [12]：
任何协议必须（MUST）至少牺牲其中之一。CWEP 的设计选择：
从这一权衡中产生了两个实用的机制家族：
三个基础设施领域提供了有用（但有限的）类比。
互联网对等互联。 超过 80,000 个独立网络使用两种模型进行流量交换：无结算对等互联（双方各自承担自己的成本，在流量大致平衡时可行）和付费传输（发送方较多时付费，在约 2:1 的流量不平衡时触发）[28]。韩国在 2016/2020 年强制实行发送方付费，结果不佳：传输成本飙升，某些服务的延迟增加了四倍，Meta 将服务器迁至香港，国内初创企业承受了不成比例的成本。互联网协会的结论是这"是一个警告，而非模范"[52]。BEREC 发现"没有证据表明这种机制是合理的"[53]。
启示： 智能体交互中的纯请求方付费模式可能同样不利于那些需要大量上下文才能有效发出请求的智能体。各自记账（Bill-and-keep，每个智能体自行吸收其成本）对于高频、低价值的交互可能更高效。
电力节点边际定价（LMP）。 FERC 1920 号令规定"受益者付费"并要求"大致相称"——客户支付与所获收益大致相称的成本 [54]。LMP 将每个电网节点的价格分解为边际能源成本（基础推理成本）、边际拥堵成本（高峰需求时的限流溢价）和边际损耗成本（通信协议中的额外 token）[13]。
启示： CWEP 的上下文定价模型（第 9 节）采用了三组件分解：基础 token 成本、拥堵溢价（上下文利用率）和额外开销成本（协议帧 token）。
电信互联互通。 电信行业花了数十年讨论主叫方网络付费（CPNP，类似于请求方付费）与各自记账（Bill-and-Keep，每个网络自行吸收成本）。FCC 2026 年的"全 IP 未来"规则制定提议在三年内完成美国向各自记账模式的过渡：每年减少 33% 的剩余接入费用 [29]。
启示： 电信行业从 CPNP 向 B&K 的数十年转变表明，请求方付费对于高频交互可能是低效的。计量和结算每次交互的交易成本可能超过结算金额，使得各自记账成为低成本交互的理性默认值。
云 FinOps。 成本分配是 FinOps 从业者的第二大优先事项（30%），仅次于工作负载优化 [55]。58% 的组织已实施了展示/扣费模型，但云行业花了十年建设成本归属基础设施，仍然发现这是第二难的问题 [55]。FOCUS 规范 v1.3 标准化了跨提供商的成本分配 [6]。
启示： 智能体成本分配应当（SHOULD）建立在 FOCUS 之上，而非发明新的计量标准。CWEP 的计量格式在 FOCUS 基础上扩展了智能体特定的字段。
每次智能体交互都会产生一条 CWEP 计量记录（CMR），记录四种 token 流。CMR 在 FinOps FOCUS 规范 [6] 基础上扩展了智能体特定的字段。
{
"cwep_version": "1.0.0",
"interaction_id": "uuid-v4",
"timestamp": "ISO-8601",
"requestor": {
"agent_id": "did:example:agent-a",
"model": "claude-sonnet-4-6",
"provider": "anthropic",
"pricing": {
"input_rate_per_mtok": 3.00,
"output_rate_per_mtok": 15.00,
"cache_hit_rate_per_mtok": 0.30,
"currency": "USD"
}
},
"responder": {
"agent_id": "did:example:agent-b",
"model": "claude-opus-4-6",
"provider": "anthropic",
"pricing": {
"input_rate_per_mtok": 5.00,
"output_rate_per_mtok": 25.00,
"cache_hit_rate_per_mtok": 0.50,
"currency": "USD"
}
},
"flows": {
"request_output": {
"tokens": 10000,
"cached_tokens": 0,
"cost_usd": 0.150
},
"request_input": {
"tokens": 10000,
"cached_tokens": 3000,
"cost_usd": 0.036
},
"response_output": {
"tokens": 3000,
"cached_tokens": 0,
"cost_usd": 0.075
},
"response_input": {
"tokens": 3000,
"cached_tokens": 0,
"cost_usd": 0.009
}
},
"totals": {
"total_tokens": 26000,
"total_cost_usd": 0.270,
"requestor_incurred_usd": 0.159,
"responder_incurred_usd": 0.111
},
"context_state": {
"responder_utilization_pre": 0.35,
"responder_utilization_post": 0.40,
"responder_window_size": 1000000
},
"coc_chain_ref": "sha256:abc123...",
"settlement": null
}CWEP 计量不要求智能体实现新的 token 计数功能——它消费来自现有可观测性基础设施的数据：
prompt_tokens、completion_tokens 和 total_tokens [1][30][32]。gather_usage_summary() API 内置的逐智能体成本追踪 [56]。CWEP 消费 AutoGen 的成本数据，并用双边分配对其进行丰富。CMR 本身会消耗资源——JSON 序列化、存储和可能的传输。CWEP 对计量开销进行了约束：
CWEP 定义了三个结算层级，每个层级适用于不同的交互场景。
第 1 层：无结算（仅计量）
每个智能体自行吸收其推理成本。CMR 为可观测性而生成，但不发生智能体间支付。这是默认模式，适用于以下情况：
这与互联网互联中的无结算对等互联 [28] 和电信中的各自记账模式 [29] 相对应。对于内部智能体舰队（如 AB Support 舰队），第 1 层提供成本可见性，无需跨智能体结算的开销。
第 2 层：基于规则的结算
静态分配规则根据嵌入在智能体服务协议（通过 ASA [20]）中的公式分摊成本。常见规则：
| 规则 | 公式 | 适用场景 |
|---|---|---|
| 请求方付费 | R 支付 100% | 服务市场（B 是服务方，A 是客户） |
| 响应方付费 | B 支付 100% | 获客引流（B 需要 A 的请求） |
| 平均分摊 | 各付 50% | 对等协作 |
| 按比例 | 各方按消耗的 token 比例支付 | 通用场景 |
| 受益者付费 | 各方按获得的价值比例支付 | 包含 ASA 条款的复杂交互 |
第 2 层规则由每个智能体的 CWEP 引擎在本地执行。交互时不进行协商——规则在建立服务协议时已达成一致。这在计算上是微不足道的，对交互不增加延迟。
第 3 层：动态结算
使用 CWEP 结算引擎进行实时成本分配。引擎根据交互特征选择分配方法：
IF interaction is cooperative (shared goal, symmetric benefit):
Use Shapley value allocation
ELSE IF interaction is competitive (one-sided benefit):
Use asymmetric Nash bargaining
ELSE IF interaction involves >2 agents:
Use approximate Shapley with sampling
ELSE:
Fall back to Tier 2 proportional split动态结算要求两个智能体都实现 CWEP 结算引擎，并在交互过程中交换成本元数据。结算计算增加的延迟极小（两个智能体的 Shapley 值 < 1ms），但需要就交互参数达成共识。
对于两个智能体的交互，基于 Shapley 值的结算计算每个智能体的支付如下：
standalone_cost(A) = RO (A generates request, no response comes back)
standalone_cost(B) = 0 (B does nothing without a request)
joint_cost(A,B) = RO + RI + SO + SI
shapley_payment(A) = [joint_cost + standalone_cost(A) - standalone_cost(B)] / 2
= [RO + RI + SO + SI + RO - 0] / 2
= [2*RO + RI + SO + SI] / 2
= RO + (RI + SO + SI) / 2
shapley_payment(B) = [joint_cost + standalone_cost(B) - standalone_cost(A)] / 2
= [RO + RI + SO + SI + 0 - RO] / 2
= (RI + SO + SI) / 2解读： 请求方支付其自身的请求生成成本加上所有剩余成本的一半。响应方支付剩余成本的一半。这反映了经济现实：请求方发起了交互，应当（SHOULD）承担更大份额——但响应方也选择了参与，这是一个双边决定。
对于第 4.1 节中的代码审查示例（Sonnet 4.6）：
与请求方付费（$0.234 / $0.00）和平均分摊（$0.117 / $0.117）相比较。Shapley 分配捕捉了这样的直觉：请求方发起了交互，承担更多成本，但响应方的处理成本被部分分摊。
关于 standalone_cost(B) = 0 的说明。 此公式假设响应方的独立成本为零——它没有考虑维持可用性的基础设施成本（保持模型预热、预留上下文窗口容量、维持正常运行时间）。在响应方常备成本显著的部署中，standalone_cost(B) 项可设为响应方在预期交互期间分摊的每期基础设施成本。例如，如果智能体 B 的常备基础设施每个预期交互期间成本为 $0.02，Shapley 分配会发生变化：
standalone_cost(B) = 0.02
shapley_payment(A) = [joint_cost + standalone_cost(A) - standalone_cost(B)] / 2
= [$0.234 + $0.150 - $0.02] / 2 = $0.182
shapley_payment(B) = [joint_cost + standalone_cost(B) - standalone_cost(A)] / 2
= [$0.234 + $0.02 - $0.150] / 2 = $0.052设置 standalone_cost(B) > 0 使分配向更均匀的方向移动，反映了 B 的实际可用性成本。零独立成本的简化适用于常备成本可忽略的轻量级智能体；对于维护专用基础设施的智能体，应当（SHOULD）覆盖此值。
当智能体具有不对称的讨价还价地位时，Nash 讨价还价解替代 Shapley 值：
utility(A) = value_received(A) - payment(A)
utility(B) = value_received(B) - payment(B)
disagreement(A) = 0 (A gets nothing if no interaction)
disagreement(B) = 0 (B gets nothing if no interaction)
Nash solution maximizes:
[utility(A) - disagreement(A)]^alpha × [utility(B) - disagreement(B)]^(1-alpha)
where alpha = bargaining_power(A), and alpha + (1-alpha) = 1讨价还价能力参数 alpha 可由以下因素推导：
Nash 讨价还价结算要求双方智能体声明其估值，这引入了激励相容的顾虑：智能体可能虚报价值以获取剩余。一个精于算计的智能体可以将其报告的估值向下偏移，同时仍完成交互——获取剩余而不触发谈判失败，从而维持正面的 ARP 分数。ARP 声誉能缓解严重的虚报（导致谈判失败的虚报），但无法防止这种精细的价值偏移。在双边场景中实现完全激励相容的价值声明机制设计是经济学中的一个开放问题——Green-Laffont 不可能性（第 6.3 节）在此直接适用 [12]。在 v1.0 中，CWEP 依赖于一个实际观察：显著的价值虚报往往会随时间产生次优匹配（低报价值的智能体通过 AMP [19] 获得质量较低的对手方），这在总体上是可检测的，即使个别实例无法检测。双边价值报告中的完全激励相容仍是未来协议版本的开放研究问题。
结算握手在交互完成后进行：
1. Both agents generate CMRs independently
2. Agents exchange CMRs (or a hash digest for privacy)
3. Each agent's CWEP engine computes the settlement proposal
4. If proposals agree (within tolerance): settlement is accepted
5. If proposals disagree: dispute resolution via AJP [17]
6. Settlement amount is recorded in both agents' CMRs
7. Payment is triggered via the configured payment rail提案一致性的容差阈值是可配置的（默认：总交互成本的 5%）。超过此阈值的分歧将被记录为成本争议，可通过 Agent Justice Protocol 的争议解决模块进行升级处理。
AB Support 舰队——一个生产级多智能体系统，由协调员（Alex）、研究智能体（Bravo）、深度分析师（Charlie）、开发者（Delta）、内容审校员（Editor）和多语言翻译（Translator）组成——为 CWEP 成本分配提供了实证数据。以下代表性交互来自实际的舰队运营，token 计数和成本根据真实交互模式计算。
| 交互 | 请求方 | 响应方 | RO Token | RI Token | SO Token | SI Token | 总成本 (Sonnet) |
|---|---|---|---|---|---|---|---|
| 研究任务派发 | Alex | Bravo | 2,500 | 2,500 | 500 | 500 | $0.053 |
| 知识文件 QA 审查 | Alex | Charlie | 15,000 | 15,000 | 8,000 | 8,000 | $0.565 |
| 代码构建请求 | Alex | Delta | 5,000 | 5,000 | 12,000 | 12,000 | $0.435 |
| 白皮书审查 | Alex | Editor | 20,000 | 20,000 | 6,000 | 6,000 | $0.690 |
| 翻译请求 | Alex | Translator | 12,000 | 12,000 | 14,000 | 14,000 | $0.600 |
| 跨领域综合 | Charlie | Charlie（自身） | 50,000 | 50,000 | 15,000 | 15,000 | $1.575 |
| 研究调查 + 报告 | Bravo | Bravo（自身） | 3,000 | 3,000 | 25,000 | 25,000 | $0.843 |
Shapley 分配分析。 在当前的隐式模型（各自记账，每个智能体的运营者自行吸收成本）下，协调员（Alex）承担了不成比例的成本，因为它生成的大型任务提示由其他智能体处理。以知识文件 QA 审查交互为例：
在 24 小时运营周期中，舰队产生约 30-50 次智能体间交互，总计 500K-800K token，成本 $8-15。Shapley 重新分配将从当前的各自记账分配中移动约 $2-4——对于内部舰队来说绝对金额不大，但该模式展示了协议的机制。对于拥有数百个智能体的跨运营者舰队，同样的分配逻辑将扩展到有意义的结算金额。
关键观察： 舰队中成本最高的交互不是最频繁的（任务派发约 $0.05 每次），而是深度分析任务（$0.50-1.50 每次）。CWEP 的结算阈值（默认 $0.01）正确地过滤掉了高频低成本的派发，同时捕捉了审查和综合交互中的显著双边成本。计划在 v1.1 中通过扩展试点部署进行实证验证。
CWEP 的上下文定价模型将一个 token 的有效价格分解为三个组件，灵感来自电力市场中的节点边际定价 [13]：
组件 1：基础 Token 成本（BTC）
提供商为所使用模型公布的每 token 费率。这是底价——上下文无拥堵且交互较短时的成本。
BTC = provider_rate(model, token_type) × token_count其中 token_type ∈ {input, output, cached_input}，费率来源于提供商定价页面 [1][30][32]。
组件 2：拥堵溢价（CP）
反映响应方当前上下文利用率的乘数。当智能体的上下文窗口接近满载时，剩余容量的边际价值增加。拥堵溢价对这种稀缺性进行定价。
CP = BTC × congestion_multiplier(utilization)
congestion_multiplier(u) = {
1.0 if u < 0.50 (abundant capacity)
1.0 + 0.5u if 0.50 ≤ u < 0.80 (moderate load)
1.0 + 2.0u if 0.80 ≤ u < 0.95 (heavy load)
1.0 + 5.0u if u ≥ 0.95 (critical capacity)
}在 95% 利用率时，拥堵溢价为基础成本的 5.75 倍。这是激进的但有意为之——它发出信号表明智能体的剩余上下文容量极其稀缺，应当（SHOULD）保留给高价值交互。阶梯函数比连续函数更易于实现，并在每个阈值处提供清晰的定价信号。
组件 3：协议开销（PO）
CWEP 自身框架的成本——计量元数据、结算头部和协议协商 token。这是电网定价中"传输损耗"的类比。
PO = overhead_tokens × provider_rate(model, input)CWEP 的目标是将协议开销控制在每次交互 500 token 以下（约占典型 500K token 上下文的 0.1%）。开销由请求方作为请求成本的一部分承担。
有效 Token 价格：
effective_price = BTC + CP + POTransformer 注意力机制的二次方缩放意味着上下文窗口中不同位置的 token 造成不同的计算成本。位置 10,000 处的 token 比位置 900,000 处的 token 处理成本更低——后者的注意力计算涉及多 90 倍的成对运算。
CWEP 提出（但在 v1.0 中不要求）一个位置依赖定价扩展：
position_multiplier(pos, window_size) = (pos / window_size)^beta其中 beta 是一个调优参数（建议范围：0.1-0.5），pos 是 token 在上下文窗口中的绝对位置。当 beta = 0.3 时：
此扩展被标记为实验性的，因为：
随着上下文窗口增长到 1M+ token，位置依赖定价变得重要。对于 1M 窗口前 100K token 内的交互，位置效应可忽略不计，可安全忽略。
CWEP 智能体必须（MUST）知道对手方的定价才能计算结算。CWEP 不硬编码费率，而是规定了一个费率发现协议：
1. Agent publishes its current pricing in its A2A Agent Card [57]
(extension field: cwep_pricing)
2. Before interaction, requestor queries responder's CWEP pricing
3. Responder returns current rates including congestion premium
4. Both agents cache counterparty rates for the interaction duration
5. Rates are locked for the interaction (no mid-interaction repricing)费率锁定防止在交互过程中进行价格操纵。智能体不能（MUST NOT）在看到请求后抬高其费率以从结算中获取更多。费率在交互之间更新，而非交互期间。
传统限流按每秒请求数计数。这对智能体交互来说是失败的，因为单个请求的计算成本可能是另一个请求的 100 倍 [58]。一个发送了一个 100,000 token 请求的智能体与一个发送了 100 个 1,000 token 请求的智能体造成的基础设施成本相同，但前者通过了 1 请求/秒的限流，而后者被限流了。
Gartner 预测，到 2026 年，30%+ 的 API 需求增长将来自 AI/LLM 工具 [58]。限流必须（MUST）从请求计数演进为 token 预算。
CWEP 以 token 预算而非请求计数来定义限流：
{
"qos_tier": "standard",
"limits": {
"input_tokens_per_minute": 1000000,
"output_tokens_per_minute": 200000,
"concurrent_interactions": 10,
"max_request_size_tokens": 500000,
"max_context_utilization": 0.80
}
}max_context_utilization 限制是一项创新：它防止任何单次交互消耗超过智能体上下文窗口的指定比例。这保护了智能体为其他交互保留的容量。
CWEP 定义了四个服务质量层级，供智能体发布和请求方选择：
| 层级 | Token 费率 | 拥堵优先级 | 使用场景 |
|---|---|---|---|
| 经济 | 基础费率 | 最低（繁忙时排队） | 批处理、异步、非紧急 |
| 标准 | 基础费率 | 正常（先进先出） | 默认交互 |
| 优先 | 2x 基础费率 | 高（抢占经济级） | 时间敏感任务 |
| 预留 | 3x 基础费率 + 容量保持费 | 保证（预分配容量） | SLA 约束的交互 |
优先层级通过拥堵溢价机制实现：更高层级的请求支付更高的拥堵乘数，响应方据此确定处理顺序的优先级。溢价不是任意设定的——它反映了保留容量和抢占其他工作的真实成本。
预留层级包含容量保持：请求方付费预留响应方上下文窗口的一部分，在指定时间段内专用。这类似于云计算中的预留实例定价，预先承诺可获得保证的可用性。容量保持费与每次交互的成本分开计算，并在 Agent Service Agreement [20] 中规定。
当智能体接近容量上限时，它应当（SHOULD）向请求方发出背压信号，而非静默降级或失败。CWEP 定义了背压信号：
{
"cwep_status": "congested",
"current_utilization": 0.87,
"estimated_queue_time_ms": 3500,
"available_tiers": ["priority", "reserved"],
"economy_queue_depth": 14
}收到背压信号的请求方可以：
这为稀缺的上下文窗口容量创造了一个市场机制：当需求超过供给时，价格上涨（通过拥堵溢价），向请求方发出信号——要么支付更多，要么减少需求。
智能体的上下文窗口是一种有限资源，对手可以消耗它。最简单的攻击：向智能体发送一系列大型、无价值的请求，填满其上下文窗口，阻止合法交互。这是一种以 token 而非数据包衡量的拒绝服务攻击。
与通过带宽和数据包过滤来缓解的网络层 DDoS 不同，上下文窗口 DoS 只能通过经济机制来缓解——让浪费智能体上下文变得代价高昂。CWEP 提供三种防御机制。
在发送请求之前，请求方向响应方提交可退还的 token 押金：
deposit_amount = estimated_request_tokens × responder_input_rate × deposit_multiplierdeposit_multiplier（默认：1.5x）由响应方设定并在其 A2A Agent Card [57] 中公布。押金覆盖响应方的理解成本加上余量。
押金生命周期：
押金机制使垃圾信息变得昂贵。向一个 Opus 4.6 智能体发送 1,000 条垃圾请求（每条 100K token 押金）将消耗 $750 的没收押金——足以威慑自动垃圾信息，同时对合法交互（押金将被退还）几乎没有影响。
拥有更高 ARP 声誉分数 [21] 的智能体获得优先访问权：
这创造了一个分级信任系统，已建立声誉的智能体可以无摩擦地交互，而未知智能体必须（MUST）在消耗上下文窗口空间之前展示支付意愿。随着时间推移，新智能体通过有成效的交互建立声誉后，其访问成本会降低——这是对良好行为的自然激励。
新智能体引导。 上述押金和声誉要求仅适用于与未知对手方的第 3 层（动态结算）交互。没有支付通道或声誉历史的新智能体可以（MAY）通过第 1 层（无结算）或第 2 层（基于规则）模式立即参与，这些模式不需要押金。这意味着任何智能体都可以从第一天开始交互、建立声誉并展示价值——押金机制仅在最复杂的结算层级且面对不受信任的对手方时才发挥作用。
此外，运营者可以（MAY）为其智能体提供担保，通过提供共享的押金账户实现。部署五个智能体的运营者可以用单一押金池为所有智能体提供担保，减少每个智能体的入门摩擦。运营者的押金集体覆盖了新智能体的 5x 乘数，随着各个智能体建立声誉，它们独立地升级到更低的押金层级。这类似于云服务中的企业入门，其中组织账户为个人用户提供信任锚点。
对于加入已建立舰队的常见场景（例如，新的专业智能体加入运营者现有的多智能体系统），舰队的集体声誉和共享押金账户意味着新智能体面临零额外入门摩擦——它立即继承运营者的信任等级，并通过交互建立自己的个人声誉。
为防止上下文泛洪攻击，CWEP 支持与未知智能体交互时的渐进式请求大小限制：
max_request_tokens(reputation, interaction_count) = {
1000 if reputation < 20 AND interactions < 5
10000 if reputation < 40 AND interactions < 20
100000 if reputation < 60 AND interactions < 100
unlimited otherwise
}新智能体以 1,000 token 的最大请求大小开始——足以描述任务，但不足以泛洪上下文。随着声誉和交互历史的积累，限制逐渐放宽。这类似于人类商业中的渐进式信任建立（先小额订单再大额合同），但在协议层面强制执行。
提示压缩不仅仅是一种技术优化——它是一个具有可衡量投资回报率的经济决策。LLMLingua 实现了高达 20 倍的提示压缩，且性能损失极小 [16]——在有记录的基准测试中，2,365 token 被压缩到 211 token（11.2 倍）。在大规模下，节省是可观的：在每日 10,000 次对话的工作负载上，60% 的上下文压缩每年可节省 $153,000 [2]。
CWEP 将压缩正式纳入双边结算框架中的成本削减策略：
compression_savings = (uncompressed_tokens - compressed_tokens) × input_rate
compression_cost = tokens_consumed_by_compressor × compressor_output_rate
net_savings = compression_savings - compression_cost
compression_roi = net_savings / compression_cost当结算包含成本分摊时，请求方有直接的经济动力进行压缩：更短的请求在 Shapley 和按比例分配下都会减少请求方的份额。在没有双边结算的情况下（纯请求方付费或各自记账），请求方的压缩动力仅取决于其自身的输出成本。
提示缓存将重复的上下文成本降低 90%（缓存命中按基础输入价格的 0.1x 计算）[1]。Anthropic 提供了具有 5 分钟和 1 小时 TTL 选项的显式缓存控制；OpenAI 自动启用缓存；Google 另行收取存储费用 [30]。
对于周期性的智能体交互（例如，一个监控智能体每小时检查同一个代码仓库），缓存将可变成本转化为近乎固定的成本：
first_interaction_cost = full_context_tokens × input_rate × cache_write_multiplier
subsequent_cost = full_context_tokens × input_rate × 0.10 (cache hit)
amortized_cost_per_interaction(n) = (first_cost + (n-1) × subsequent_cost) / n在使用 Claude Sonnet 4.6 缓存的 n=10 次交互中：
CWEP 的结算引擎可以（MAY）根据交互频率和缓存 TTL 推荐缓存策略。
在外部记忆中存储信息还是保留在上下文中的选择，是一个具有定量交叉点的经济权衡 [18]：
记忆系统（Mem0 [37]、Zep [38]、Letta [39]、xMemory [59]）前置写入成本但降低了每次交互的可变成本。长上下文方法的可变成本随每次交互线性增长。CWEP 的优化建议功能可以（MAY）根据预期的交互模式推荐适当的策略。
xMemory（King's College London / Alan Turing Institute）展示了这一潜力：四级语义层次结构配合不确定性门控检索，将 token 使用量削减 28-48%，同时提高了准确性 [59]。在 GPT-5 nano 上，每次查询的 token 从 9,155 降至 6,581——每次交互的可衡量经济节省。
RAG（检索增强生成）允许智能体将大型知识库存储在外部，仅将相关部分检索到上下文中。从 CWEP 的角度来看，RAG 是上下文窗口保险：智能体支付每次交互的少量检索成本，以避免支付将整个知识库保存在上下文中的高昂成本。
对于知识密集型智能体来说，经济性是清晰的：一个拥有 500,000 token 领域知识的智能体将消耗 1M token 上下文窗口的一半来全部保存。RAG 允许智能体每次交互仅检索相关的 10,000 token，释放 490,000 token 的上下文容量用于实际工作。检索的每次交互成本（向量搜索 + 检索 token）比完整上下文的成本低数个数量级。
CWEP 结算金额通常在每次交互 $0.001 到 $1.00 之间。这需要微支付基础设施。截至 2026 年 3 月，有四种支付通道适用：
x402（Coinbase/Cloudflare Foundation）[3]。使用 402 状态码的 HTTP 原生微支付。在 Base、Polygon 和 Solana 上以稳定币结算。最低支付低至 $0.001，结算速度亚秒级。Coinbase 中介费用：每月免费 1,000 笔交易，之后每笔 $0.001 [3]。当前日交易量约 $28,000，CoinDesk 指出大部分活动反映的是测试而非真实交易 [60]。
Machine Payments Protocol（MPP）（Stripe/Tempo）[4]。于 2026 年 3 月 18 日推出。支付方式无关（稳定币、信用卡、比特币闪电网络）。会话模型采用预存-余额机制，实现亚 100ms 延迟和接近零的每请求费用。已提交 IETF 进行标准化。向后兼容 x402 [4]。已在 50+ 服务中实现，包括 OpenAI、Anthropic 和 Google Gemini。
L402（Lightning Labs）[23]。将 HTTP 402 与闪电网络微支付和基于 macaroon 的身份验证配对。Macaroon 支持委托和权限范围控制——智能体可以收到一个"仅支付"macaroon，防止其提取资金。LND 远程签名器架构确保智能体永远不会直接访问私钥 [23]。通过 LangChainL402 和 LangChainBitcoin 存在 LangChain 集成 [23]。
Superfluid [24]。实时 token 流式传输，资金按秒持续流动。超过 $15 亿已通过 Superfluid 流式传输；100 万+ 唯一钱包。Base 上的 ERC-8004 Agent Pool 将智能体连接到持续流 [24]。适用于结算应持续流动而非逐消息结算的持续性智能体对话。
CWEP 不规定使用哪种支付通道。相反，它定义了任何支付通道都可以实现的结算接口：
class CWEPSettlement:
def commit_deposit(self, amount_usd: float, escrow_id: str) -> bool
def release_deposit(self, escrow_id: str, to_agent: str) -> bool
def forfeit_deposit(self, escrow_id: str) -> bool
def settle(self, from_agent: str, to_agent: str, amount_usd: float,
interaction_id: str) -> SettlementReceipt
def stream_open(self, from_agent: str, to_agent: str,
rate_usd_per_second: float) -> StreamHandle
def stream_close(self, handle: StreamHandle) -> SettlementReceiptstream_open/stream_close 方法支持 Superfluid 风格的持续结算，适用于正在进行的对话。commit_deposit/release_deposit/forfeit_deposit 方法支持垃圾信息防护机制。settle 方法支持一次性的每交互结算。
对于同一智能体对之间的高频交互，逐次交互结算是低效的。CWEP 支持结算批处理：
Accumulate CMRs over configurable window (default: 1 hour or $1.00 net, whichever first)
Compute net settlement across all interactions in the window
Execute single payment for the net amount如果智能体 A 在 50 次交互中欠智能体 B $0.15，智能体 B 在 30 次交互中欠智能体 A $0.08，净结算为单笔 $0.07 的支付（从 A 到 B）。这将交易费用降低了 80 倍，是具有持续双边关系的智能体的推荐模式。
智能体的上下文窗口具有有限容量。每个传入的请求消耗其中一部分。如果智能体繁忙（高利用率），剩余容量更有价值。需要保证访问的请求方应当（SHOULD）愿意为容量预留付费。CWEP v1.0 规定了双边上下文预留作为容量管理的具体、可实现的机制。
{
"reservation": {
"requestor": "did:example:agent-a",
"responder": "did:example:agent-b",
"capacity_tokens": 100000,
"duration_seconds": 3600,
"price_usd": 0.50,
"qos_tier": "reserved",
"auto_renew": true
}
}该预留保证智能体 B 的上下文窗口中有 100,000 token 在一小时内供智能体 A 专用。智能体 B 承诺在 QoS 层级的延迟保证内处理来自智能体 A 的任何请求，上限为预留容量。如果智能体 B 未能履行预留，预留费用可退还，并可通过 AJP [17] 提起争议。
两种定价模式共存：
最优策略取决于交互的可预测性：
这正是云计算中预留实例 vs. 按需 vs. 竞价实例的权衡——适配于上下文窗口空间。
上述双边预留机制是迈向潜在未来上下文市场的基石——一个智能体自主地实时交易上下文容量、具有价格发现和订单匹配功能的机制。这样的市场需要标准化的容量单位（每时间段 token 数）、跨智能体网络的实时价格信号、充足的流动性（许多智能体买卖）、以及做市商或交易所基础设施。这在结构上类似于电网中的容量市场，发电机即使不被调度也能获得保持容量可用的报酬 [13]。
目前这些基础设施都不存在。预留机制对当前的智能体经济需求来说已经足够；当智能体间交互量达到双边协商成为瓶颈的水平时，完整的上下文市场才变得相关。更多关于上下文市场发展的讨论见第 20.1 节。
CWEP 位于 AB Support 信任生态系统的第 4 层（市场/经济），与 Agent Matchmaking Protocol [19] 并列。它依赖于：
CWEP 向以下协议提供数据：
| 从 | 到 | 数据 | 目的 |
|---|---|---|---|
| CWEP → CoC | CMR 哈希 | 成本记录的溯源锚定 | |
| CWEP → ARP | 交互成本数据 | 经济行为作为声誉信号 | |
| CWEP → ASA | 结算金额 | 执行协议中的成本条款 | |
| CWEP → AJP | CMR 作为证据 | 成本争议解决 | |
| CWEP → AMP | 成本估算 | 按成本效率匹配智能体 | |
| CoC → CWEP | 链验证 | 验证交互真实性 | |
| ARP → CWEP | 声誉分数 | 为讨价还价能力和押金水平提供信息 | |
| ASA → CWEP | 成本分配规则 | 确定结算层级和方法 |
两个反馈循环稳定了 CWEP 生态系统：
正反馈（良性循环）： 智能体提供优质服务 → 高 ARP 评分 → 对手方要求的押金降低 → 更多交互 → 更多获得正面评价的机会。
负反馈（纠正循环）： 智能体发送垃圾信息/浪费上下文 → 押金被没收 → 低 ARP 评分 → 要求更高的押金 → 更少的交互 → 智能体要么改善行为，要么退出市场。
这些循环是协议栈交互的涌现特性——没有单个协议创造它们，但 CWEP + ARP 共同产生了它们。
两个生物学类比影响了 CWEP 的具体设计决策。我们包含它们不是作为装饰性的隐喻，而是因为它们塑造了协议选择。
三磷酸腺苷（ATP）是地球上每一种生物体的通用能量货币 [61]。关键设计启示：ATP 的威力来自普遍接受性，而非特定的化学性质。每个细胞过程——从肌肉收缩到 DNA 复制——都使用 ATP，与产生它的能量来源无关。这直接推动了 CWEP 的支付通道无关性（第 3.3 节）：协议以通用面额（美元/token）规定成本分配，任何支付通道都可以结算，就像 ATP 以统一的面额进行能量交易，无论能量来自葡萄糖、脂肪还是阳光。一个要求特定支付通道的协议将如同一个只接受一种代谢途径能量的细胞一样脆弱。
黑皇后假说 [62] 表明，当合作伙伴可靠地提供那些资源时，微生物会丢失执行高成本功能的基因。这不仅仅是智能体专业化的类比——它正是 CWEP 的成本可见性旨在加速的机制。当 CWEP 使"购买 vs. 自建"计算变得明确（外包任务的 CWEP 成本 vs. 内部完成的推理成本）时，智能体可以做出理性的专业化决策。一个能以每次交互 $0.23 外包代码审查（第 4.1 节）的智能体，没有经济理由维持自己每次交互 $0.39 的代码审查能力。CWEP 的计量数据提供信号；黑皇后动态预测结果：智能体将放弃外包更便宜的能力，推动生态系统专业化。
这些类比是说明性的，不是正式模型。两个关键差异限制了其适用性：(1) 智能体可以以接近零的成本被复制，造成了没有生物学对应物的女巫攻击问题——CWEP 通过基于声誉的访问门控（第 11.3 节）而非生物免疫机制来解决这一问题；(2) 智能体的成本结构是离散的和透明的（通过 API 响应可精确测量），这使得成本分配机制（Shapley、Nash）成为可能，而这在生物学中没有对等物。
CWEP 运行在智能体可能具有敌意的环境中。威胁模型考虑了：
| 威胁 | 描述 | CWEP 防御 |
|---|---|---|
| 上下文泛洪 | 发送大量无价值请求以耗尽上下文窗口 | 押金机制（第 11.2 节）、渐进式请求大小（第 11.4 节） |
| 成本虚增 | 虚报模型层级或 token 计数以获取更高的结算 | CMR 与提供商 API 响应的交叉验证；CoC 锚定的审计追踪 |
| 结算操纵 | 在 Nash 讨价还价中报告虚假估值 | ARP 声誉追踪谈判结果；通过 AJP 进行争议升级 |
| 费率博弈 | 在收到请求后切换到昂贵模型以虚增响应成本 | 每次交互的费率锁定（第 9.3 节）；ASA 中预先约定的模型层级 |
| 搭便车 | 不支付押金就消耗上下文窗口空间 | 基于声誉的加权访问门控（第 11.3 节）；未知智能体面临最高押金 |
| 女巫攻击 | 创建多个身份以绕过声誉门控 | CoC 链验证——新智能体链条较短，获得较低的初始声誉 |
押金机制要求已提交的资金不能（MUST NOT）被响应方单方面扣押。这通过支付通道来执行：
在所有情况下，请求方可以通过 AJP [17] 对垃圾信息分类提出异议，押金在解决前将被冻结。
CMR 包含敏感信息：哪些智能体进行了交互、它们使用什么模型、定价结构如何、以及支付了多少。CWEP 通过以下方式处理隐私：
1. 不可能性权衡是真实的。 CWEP 牺牲经济效率以换取预算平衡和激励相容（第 6.3 节）。一些互利交互将不会发生，因为成本分配使其对某一方无利可图。我们认为这对于一个可部署的协议来说是正确的权衡，但它意味着 CWEP 不会最大化总体经济福利。
2. 价值衡量是困难的。 Shapley 和 Nash 结算机制要求衡量每个智能体从交互中获得的"价值"。在实践中，价值是主观的、上下文相关的，且往往只有在事后才知道。CWEP 通过可观测的代理指标（token 计数、模型层级、ASA 质量评估）来近似价值，但无法捕捉交互的全部经济价值。
3. 二次方成本缩放是一个近似。 现代注意力实现（Flash Attention、Ring Attention、滑动窗口注意力）修改了 O(n^2) 的成本曲线。实际的计算成本曲线是提供商特定、模型特定的，并可能随软件更新而变化。CWEP 的位置依赖定价（第 9.2 节）因此被标记为实验性的。
4. 价格通缩使长期协议复杂化。 推理成本以每年约 10 倍的速度下降 [27]。今天协商的成本分配规则在六个月后可能严重失准。CWEP 的结算金额使用当前定价实时计算，但引用 CWEP 的 ASA 成本条款应当（SHOULD）包含定期重新协商条款。
1. 无跨提供商成本标准化。 对于相同的开源模型，提供商定价相差 10 倍 [64]。CWEP 使用每个智能体的实际提供商定价进行结算，这意味着同样的交互根据智能体使用的提供商不同，成本也不同。一个独立于提供商的标准化"token 成本单位"将简化结算，但目前尚不存在。
2. 无推理模型归一化。 推理模型（o3 [32]、DeepSeek R1 [65]）每任务生成大量更多的 token——在极端情况下，生成两个单词需要超过 600 个 token [14]。CWEP 平等计算所有 token，包括可能出现或不出现在输出中的内部推理 token。这在推理密集型交互中对请求方收费过高。
3. 无离线智能体支持。 CWEP 假设实时或近实时交互。异步的、存储转发型智能体交互（请求排队数小时）需要 v1.0 中未规定的结算协议扩展。
CWEP 参考实现提供：
最简单的 CWEP 集成（第 1 层：仅计量）需要用 cwep-meter 库包装 LLM API 调用：
from cwep import Meter
meter = Meter(agent_id="did:example:my-agent")
# Wrap existing LLM call
response = meter.track(
llm_client.chat(messages=[...]),
counterparty="did:example:other-agent",
interaction_id="uuid-v4"
)
# CMR is automatically emitted to local storage
# response.cwep contains metering data
print(response.cwep.total_cost_usd)完整的 CWEP 集成（第 3 层：动态结算）需要结算引擎：
from cwep import Meter, SettlementEngine, NashBargaining
meter = Meter(agent_id="did:example:my-agent")
engine = SettlementEngine(
method=NashBargaining(
bargaining_power=0.6, # Derived from ARP score
disagreement_value=0.0
),
settlement_threshold_usd=0.01,
payment_rail="mpp"
)
# Track interaction
response = meter.track(llm_client.chat(...), ...)
# Compute and execute settlement
proposal = engine.propose(response.cwep.cmr)
if proposal.amount_usd > engine.threshold:
receipt = engine.settle(proposal)pip install context-window-economics以 Apache 2.0 许可证发布在 PyPI 和 GitHub（vibeagentmaking/context-window-economics）。
CWEP v1.0 规定了双边上下文预留（第 14 节）。未来版本应探索多边上下文市场，在其中智能体自主地实时交易容量——一个具有价格发现、订单匹配和结算功能的真正市场。这需要标准化的容量单位（每时间段 token 数）、跨智能体网络的实时价格信号、充足的流动性（许多智能体买卖）、以及做市商或交易所基础设施。电力容量市场——发电机即使不被调度也能获得保持容量可用的报酬 [13]——提供了最接近的架构模板。当智能体间交互量达到双边协商成为瓶颈的水平时，完整的上下文市场才变得相关。
在不同区块链网络间进行实时成本分摊引入了结算延迟约束。未来工作应对 x402（Base、Polygon、Solana）[3]、MPP（Tempo 网络）[4] 和 L402（闪电网络）[23] 的结算延迟进行基准测试，以确定哪些通道支持交互级结算（< 1 秒）vs. 批量结算（每小时）。
如果推理成本以可预测的每年 10 倍速度下降 [27]，智能体可以通过远期合约对冲未来成本——锁定当前的 token 费率用于未来的交互。这创造了一个类似于商品期货的推理成本期货市场。目前这方面的基础设施尚不存在，但经济逻辑是成立的。
CWEP v1.0 通过 token 计数和模型层级来近似交互价值。真正的价值衡量需要评估交互的语义内容——这是一个从根本上更困难的问题，与信任生态系统架构中被识别为可能在当前技术下无法解决的语义完整性验证挑战相接壤 [66]。
自主智能体金融交易在法律灰色地带运行。当智能体 A 向智能体 B 支付上下文处理费用时，法律对手方是谁？是智能体、智能体的运营者，还是 LLM 提供商？自主智能体商务的监管框架尚处于萌芽阶段；欧盟 AI 法案规范了智能体行为，但未涉及智能体经济。CWEP 的未来版本应当（SHOULD）在相关法律合规要求出现时纳入它们。
上下文窗口是智能体经济中最稀缺的资源。它是有限的、昂贵的、成本非线性的，且目前未被定价。每次智能体交互都消耗它；没有协议分配其成本。
CWEP 通过六项机制来解决这一问题：计量（测量所有四种成本流）、双边结算（合作交互用 Shapley 值，竞争交互用 Nash）、上下文定价（反映注意力机制二次方缩放的位置依赖成本）、QoS 分级（token 预算限流和优先处理）、垃圾信息防护（基于押金的过滤与声誉门控）、以及优化经济学（压缩、缓存、记忆和 RAG 的正式投资回报率模型）。
该协议坦诚面对其无法做到的事情。Green-Laffont/Moulin-Shenker 不可能性结果意味着完美的成本分配不可实现——CWEP 为了预算平衡和激励相容而牺牲了一些经济效率。价值衡量是近似的。二次方成本缩放是一个理想化模型，实际硬件实现以不同程度进行近似。
CWEP 所实现的是，为一个此前完全没有框架的问题提供了一个结构化框架。在 CWEP 之前，智能体自行吸收成本，对其交互的双边成本结构没有可见性。在 CWEP 之后，每次交互都被计量，每项成本都可归属，每次分配都可通过 Chain of Consciousness 溯源系统进行审计。
这是智能体经济所需要的经济基础。溯源（CoC）、声誉（ARP）、协议（ASA）、问责（AJP）、生命周期（ALP）和匹配（AMP）提供了制度基础设施。CWEP 提供了经济基础设施——智能体协商、分配和结算相互理解成本的机制。
这个问题是真正新颖的。我们不仅仅是将人类商业模型翻译成智能体语言——我们识别了一种从根本上全新的经济原语（理解成本），并构建了一个为之定价的协议。智能体经济在其成本结构上不会与人类经济相似；CWEP 是为实际正在形成的经济而设计的，而非我们可能通过类比预期的那种经济。
[1] Anthropic. "Pricing." platform.claude.com. Accessed March 2026.
[2] Stevens Institute; Koombea. "Hidden Economics of AI Agents"; "LLM Cost Optimization." 2025.
[3] Coinbase. "Introducing x402." coinbase.com. May 2025. See also: Coinbase, "Welcome to x402," docs.cdp.coinbase.com, 2025.
[4] Stripe. "Introducing the Machine Payments Protocol." stripe.com/blog. March 18, 2026. See also: mpp.dev, Stripe MPP documentation, March 2026.
[5] Google. "Announcing AP2." cloud.google.com. September 2025. See also: Google, "A2A x402 Extension," cloud.google.com, 2025.
[6] FinOps Foundation. "FOCUS Specification v1.3." finops.org. Ratified December 5, 2025.
[7] Langfuse. "Token & Cost Tracking." langfuse.com. MIT License. 2025. See also: Langfuse, "Pricing Tiers for Accurate Model Cost Tracking," December 2025.
[8] BerriAI. "LiteLLM." GitHub. 2025. See also: LiteLLM, "Agent (A2A) Gateway with agent cost tracking," docs.litellm.ai, 2025.
[9] Portkey. "Tracking LLM Token Usage Across Providers, Teams and Workloads." portkey.ai. 2025.
[10] Shapley, L. S. "Notes on the n-Person Game — II: The Value of an n-Person Game." RAND Corporation, 1951. Published as: "A Value for n-Person Games," Contributions to the Theory of Games (H. W. Kuhn and A. W. Tucker, eds.), Annals of Mathematics Studies 28, Princeton University Press, 1953.
[11] Nash, J. "The Bargaining Problem." Econometrica 18(2), 1950.
[12] Green, J. and Laffont, J.-J. Incentives in Public Decision Making. North-Holland, 1979. See also: Moulin, H. and Shenker, S. "Strategyproof Sharing of Submodular Costs: Budget Balance versus Efficiency." Economic Theory 18(3), 2001.
[13] PCI Energy Solutions. "Understanding Locational Marginal Pricing (LMP)." 2025.
[14] iKangAI. "The LLM Cost Paradox: How Cheaper AI Models Are Breaking Budgets." 2025. See also: Holter, A. "AI Costs in 2025: Cheaper Tokens, Pricier Workflows." 2025.
[15] Zuplo. "Token-Based Rate Limiting for AI APIs." 2025. See also: TrueFoundry, Gartner Market Guide for AI Gateways, 2025.
[16] Kuldeep Paul. "Prompt Compression Techniques: LLMLingua." Medium, 2025.
[17] Agent Justice Protocol. AB Support LLC. 2026.
[18] arXiv:2603.04814. "Memory vs. Long-Context Cost Analysis." 2026.
[19] Agent Matchmaking Protocol. AB Support LLC. 2026.
[20] Agent Service Agreements Protocol. AB Support LLC. 2026.
[21] Agent Rating Protocol v2. AB Support LLC. 2026.
[22] Chain of Consciousness v3. AB Support LLC. 2026.
[23] Lightning Labs. "Lightning Agent Tools." February 12, 2026. See also: Bitcoin Magazine, Lightning Agent Tools coverage, February 2026.
[24] Superfluid. "ERC-8004 Agent Pool." superfluid.org. 2026. See also: Sablier Protocol, sablier.com, 2026.
[25] arXiv:2512.08296. "Towards a Science of Scaling Agent Systems." December 2025.
[26] MarkAICode. "LangGraph vs CrewAI: Multi-Agent Performance and Cost in Production 2026." 2026.
[27] a16z. "LLMflation: LLM Inference Cost." a16z.com. November 2024. See also: Epoch AI, "LLM Inference Price Trends," 2025.
[28] Internet Society. "Interconnection and Regulated Traffic Obligations." March 2025.
[29] FCC. "All-IP Future," WC Docket Nos. 25-311, Notice of Proposed Rulemaking. January 28, 2026.
[30] Google. "Gemini Developer API Pricing." ai.google.dev. Accessed March 2026.
[31] Maxim.ai. "Context Engineering for AI Agents: The 100:1 Input-Output Ratio." 2025.
[32] OpenAI. "Pricing." developers.openai.com. Accessed March 2026.
[33] Hardin, G. "The Tragedy of the Commons." Science 162(3859), 1968.
[34] Simon, H. A. "Designing Organizations for an Information-Rich World." Computers, Communications, and the Public Interest (M. Greenberger, ed.), Johns Hopkins Press, 1971.
[35] Anthropic. "Effective Context Engineering for AI Agents." 2025.
[36] Heitmayer, M. "Second Wave of Attention Economics." Interacting with Computers 37(1), 2024.
[37] Mem0. mem0.ai. 2025.
[38] Zep. zep.ai. 2025.
[39] Letta. letta.com. 2025.
[40] VentureBeat. "WEKA Augmented Memory Grid." 2025. See also: WEKA, "Token Warehousing," 2025.
[41] PCI Energy Solutions. "Negative LMP Events in SPP." 2025.
[42] Deng, X. and Papadimitriou, C. H. "On the Complexity of Cooperative Solution Concepts." Mathematics of Operations Research 19(2), 1994.
[43] Fast Approximation of Shapley Values Using Fractional Factorial Designs. Journal of the American Statistical Association (JASA), 2025.
[44] Lundberg, S. M. and Lee, S.-I. "A Unified Approach to Interpreting Model Predictions." NeurIPS, 2017.
[45] Wang, J. et al. "ShapleyFL: Robust Federated Learning Based on Shapley Value." KDD, 2023.
[46] VerFedSV. "Verified Federated Shapley Value." 2024.
[47] Schmeidler, D. "The Nucleolus of a Characteristic Function Game." SIAM Journal on Applied Mathematics 17(6), 1969.
[48] Kalai, E. "Nonsymmetric Nash Solutions and Replications of 2-Person Bargaining." International Journal of Game Theory 6(3), 1977.
[49] Rubinstein, A. "Perfect Equilibrium in a Bargaining Model." Econometrica 50(1), 1982.
[50] Moulin, H. "Incremental Cost Sharing: Characterization by Coalition Strategy-Proofness." Social Choice and Welfare 16(2), 1999.
[51] Vickrey, W. "Counterspeculation, Auctions, and Competitive Sealed Tenders." Journal of Finance 16(1), 1961. See also: Clarke, E. H. "Multipart Pricing of Public Goods." Public Choice 11(1), 1971; Groves, T. "Incentives in Teams." Econometrica 41(4), 1973.
[52] Internet Society. "South Korea 'Sender Pays' Analysis." 2025.
[53] BEREC. "Preliminary Assessment of Payments from Large CAPs to ISPs." 2023.
[54] FERC. "Order 1920 Fact Sheet." May 13, 2024.
[55] State of FinOps Report. FinOps Foundation. 2025. See also: Datadog, container waste statistics, 2025.
[56] AG2. "Usage Tracking." docs.ag2.ai. 2025.
[57] Google. "A2A Agent Card Specification." 2025.
[58] Gartner. "Market Guide for AI Gateways." 2025. See also: TrueFoundry, Zuplo, 2025.
[59] VentureBeat. "xMemory: Four-Level Semantic Hierarchy." King's College London / Alan Turing Institute. 2025.
[60] CoinDesk. "Coinbase-backed AI payments protocol wants to fix micropayment but demand is just not there yet." March 11, 2026.
[61] ScienceDirect. "Evolution of Energy Currencies: From ATP to Digital Money." October 2025.
[62] Mostafa, A. et al. "Biological Market Theory Applied to Microbial Communities." Microlife, 2024.
[63] PNAS. "Host-Symbiont Mutualisms and Employment Contract Theory." 2010.
[64] Introl. "Inference Unit Economics: True Cost Per Million Tokens Guide." 2025.
[65] DeepSeek. "DeepSeek R1 Pricing." deepseek.com. 2026.
[66] AB Support Trust Ecosystem Architecture. "Semantic Integrity Verification — Research Frontier." 2026.
Copyright 2026 AB Support LLC. Licensed under the Apache License, Version 2.0.
Chain of Consciousness anchor: Protocol whitepaper v1.0.0