模型更新快。价格难看懂。有的厂商把 API 降到几分钱一百万 Token。有的旗舰模型维持几十美元高价。新模型发布就降价抢用户。能力升级后反而提价。同一家厂商同时提供缓存价、批处理价、峰谷价、标准价。如果 Token 是大模型的电，为什么不像电价一样稳定？答案是：Token 是计量单位。用户真正买的是任务成功完成。一百万 Token 可能生成一堆没用的文字。也可能完成价值数万元的代码修复。比如合同审查。比如药物研究。厂商按 Token 收费。真正争夺的是谁完成任务、谁控制调用入口、谁获得价值。理解了这一点，就能看懂价格为什么同时涨又跌。一、先纠正误区：Token 单价不代表模型贵不贵假设有两个模型做同一项任务。指标模型 A模型 B每次调用成本1 元3 元一次成功率40%90%平均调用次数2.5 次1.1 次完成任务的费用2.5 元3.3 元人工检查与返工高低只看单次调用，模型 A 便宜。算上失败重试和人工检查，模型 B 更省钱。用户承担的成本有个公式：每次成功任务成本 = (Token 费用 + 工具费用 + 重试成本 + 人工审校 + 等待损失) ÷ 任务成功率这叫单位智能价格。过去人们比较每百万 Token 价格。就像只看出租车每公里多少钱。不看能不能把人准时送到目的地。现在进入 Agent 阶段。同一个任务包含长上下文、内部推理、多轮工具调用。Token 数量和业务结果的关系变不稳定。斯坦福 AI Index 有公开数据。在达到 GPT-3.5 相近能力时，模型推理成本在 2022 年 11 月到 2024 年 10 月下降超过 280 倍。这比简单比较标价更有意义。二、定价由三股力量决定：成本地板、价值天花板、竞争闸门模型的价格夹在三股力量中间。成本地板：厂商最低愿意卖多少钱一次推理需要芯片、显存、内存、网络、电力、机房。还要分摊研发、训练、运维及闲置容量。架构优化、量化、推测解码会降低单位推理成本。成本地板不是固定数字。实时请求比离线任务贵。高峰时段比空闲时段稀缺。超低延迟比普通响应需要更多资源。厂商计算的是某类请求占用了多少稀缺容量。举个例子。白天高峰期调用比凌晨闲时贵 30%。这就是成本差异。价值天花板：客户最多愿意付多少钱聊天摘要可能值几分钱。发现一处重大合同风险可能值数万元。模型能力升级后，如果能进入代码、法律、医疗环节，客户愿意支付的上限会提高。因此新模型可能让单位计算成本下降。同时让每次成功任务的商业价值上升。一个力量拉低价格。另一个力量留下上涨空间。比如说。一个代码 Agent 每月省工程师 20 小时。企业愿意为它多付几百元。竞争闸门：厂商能拿走多少价值价值很高不等于厂商可以随意定价。客户可以选择其他闭源模型。也可以选择开源模型。还可以自建推理服务。竞争越充分，价格越接近成本地板。可替代模型越少，切换成本越高，厂商越有机会靠近价值天花板。价格区间可以写成：成本地板 ≤ 模型价格 ≤ 客户愿意支付的任务价值最终靠近哪一端，取决于替代模型数量、切换成本和厂商掌握的入口。这个三层模型解释了一个矛盾现象。同一时期通用模型大幅降价。旗舰模型仍然维持高价。甚至提价。三、新模型发布时，四个变量同时变化每次模型升级，都可能移动三条边界。变量一：单位推理成本下降模型架构更高效。硬件性价比提高。缓存命中率提升。同样数量的 Token 消耗更少资源。厂商可以降价抢市场。也可以维持标价，把成本改善转化为毛利。变量二：可完成任务的价值上升当成功率从 60% 升到 90%，模型角色会变化。从提供参考意见变成独立完成流程。客户购买的人工替代量扩大。价格天花板随之上升。举例来说。之前需要人看一遍修改的代码。现在可以直接用。节省的时间值钱。变量三：单个任务消耗的 Token 增多更长上下文、更深推理和更多工具调用，都会增加一次任务的 Token 消耗。单价下降不等于单任务账单下降。一个 Agent 连续工作一小时，消耗量可能远高于几十轮普通聊天。比如一个数据分析任务。可能需要 5 万 Token。而写一封邮件只要 500 Token。变量四：替代关系被重新洗牌新模型会把旧旗舰变成中端型号。也会让原来做不了某项任务的低价模型跨过可用门槛。价格竞争最激烈的时刻，往往发生在多个模型同时达到够用水平之后。这四个变量共同造成了今天的 K 型价格结构。市场层级用户购买什么竞争状态价格走向通用低端摘要、分类、改写、简单问答模型高度可替代快速趋近成本价中端能力稳定推理、代码辅助、常规 Agent新旧模型正面竞争价格持续承压前沿高端高难推理、长任务、高可靠执行合格供给较少保留明显溢价企业保障SLA、安全、数据隔离、专属容量切换成本较高按保障能力收费同样是 Token。通用低端更像自来水。前沿高端更像专家时间。企业保障更接近保险和专线服务。三类产品使用同一个计量单位。定价逻辑已经分开。四、厂商围绕价格，主要在玩四种游戏游戏一：低价抢入口模型厂商可以用接近成本的价格争取开发者、调用量和生态适配。阶段性亏损也可以接受。一旦某个模型成为应用的默认模型，厂商得到的远不止当前 Token 收入。还能获得真实任务反馈、开发工具适配、品牌心智和未来升级机会。低价相当于购买市场入口。这类策略适合能力已经达到够用、推理成本领先、急需扩大生态的模型。价格越低，开发者越愿意把预处理、分类、检索增强和普通 Agent 任务放上去。调用量又会反过来改善资源利用率。游戏二：高价收能力溢价旗舰模型瞄准其他模型完成不了的任务。或者失败代价很高的任务。这里的客户更关心成功率、稳定性和人工替代量。假设一个代码 Agent 每月可以节省工程师 20 小时。模型费用从 200 元涨到 400 元。对企业采购决策的影响可能很小。只要节省的人力与交付周期仍然远高于费用，厂商就有提价空间。测试这类高价能否成立，要看涨价之后单位成功任务量是否继续增长。调用量增长只能说明使用增加。结合任务成功率、客户留存和收入变化，才能判断厂商是否拥有定价权。游戏三：把同一种 Token 拆成不同价格算力有个特殊属性。某个时刻空下来的 GPU 容量，过后无法重新出售。很像航空座位和酒店房间。于是厂商开始按照请求特征定价：请求类型客户让渡什么厂商获得什么常见价格实时优先支付更高费用可预留容量、提供低延迟溢价标准请求接受普通排队正常调度标准价离线 Batch接受延迟完成可填充闲置算力通常折价缓存命中复用相同上下文减少重复计算大幅折价峰谷价格调整使用时段平滑负载谷时低、峰时高主流厂商的公开价格体系里已经有这些。OpenAI 的 Batch API 相比同步调用提供 50% 折扣。Prompt Caching 的缓存输入最高可节省 90%。Anthropic 同样提供 Batch 折扣。对标准速度、快速模式、缓存写入、缓存读取分别计价。DeepSeek V4 已采用峰谷价格。空闲时段价格为高峰时段的一半。厂商调整的对象已经从模型型号扩展到时间、速度、延迟、缓存、并发和服务保障。Token 价格开始具有云计算现货市场的特征。游戏四：前台卖结果，后台优化 Token当模型能够稳定完成完整任务，用户就不愿继续研究输入和输出分别多少钱。更愿意按解决一个工单付费。或者按完成一次代码修改付费。或者按管理一个 Agent 席位付费。应用厂商可以在前台收取固定任务费。后台使用路由系统进行成本控制。简单步骤交给低价小模型。关键判断交给旗舰模型。重复上下文走缓存。非实时任务进入 Batch。这时 Token 仍然存在。但它逐渐变成应用厂商内部的成本单位。类似云服务器的 CPU 时间。终端客户看到的是任务、席位、订阅和业务结果。五、同一张牌桌上，不同模型厂商分别在争什么如果只看 API 价格，所有基座模型厂商似乎都在争夺同一批 Token。实际上，它们的收入来源和战略目标差异很大。OpenAI、Anthropic 等独立模型厂商，需要从模型能力和产品服务中直接获得收入。Google、阿里和字节可以用较低的模型价格带动云计算、搜索、办公和企业服务。Meta 可以开放模型权重，用模型层的低价换取生态影响力。DeepSeek 可以凭借成本优势主动降低市场价格锚。所以厂商计算的收益不能只看 Token 毛利：厂商总收益 = Token 毛利 + 云资源收入 + 订阅收入 + 生态入口价值 + 未来客户锁定收益不同厂商对这五项收益赋予的权重不同。定价策略也就不同。OpenAI：覆盖全部价格带，争夺智能入口OpenAI 更适合采用旗舰溢价、小模型防御、订阅捆绑的组合。最强模型承担高端定价。低价模型承接摘要、分类和普通问答。Cache 与 Batch 吸收可复用、可延迟的任务。个人及企业订阅降低用户对单次 Token 价格的敏感度。工具、Agent 和 API 生态继续增加切换成本。当 DeepSeek 等厂商大幅降价时，OpenAI 没有必要让所有旗舰产品同步降价。它可以用低价小模型守住通用市场。同时让旗舰模型继续收取能力溢价。Anthropic：守住专业任务的高可靠溢价Anthropic 的重点场景是代码、复杂知识工作、长任务和企业 Agent。它更重视任务成功率、稳定性和企业信任形成的价格空间。其公开价格体系已经把标准速度、Fast 模式、Batch、缓存写入和缓存读取拆开计价。愿意等待的客户获得折扣。要求低延迟的客户支付溢价。企业客户还可以为安全、数据驻留、专属容量和 SLA 付费。这套策略能否持续，取决于 Anthropic 能否在高价值任务中维持成功率差距。一旦低价模型达到相近的可靠性，原有溢价就会受到挤压。Google：用模型价格带动云、搜索和办公生态Google 同时拥有模型、TPU、Google Cloud、搜索和 Workspace。它可以接受较低的模型层毛利。因为客户调用模型时，还会使用云计算、存储、数据库、搜索和办公服务。因此 Google 可以让 Flash 类模型以低价获取大规模调用。用 Pro 类模型承接复杂任务。再通过 Priority、Batch、Flex 和 Context Cache 对不同类型的算力需求分别定价。它的优势来自交叉补贴。即使某类 Token 利润很薄，只要模型带动了更多云资源和企业订阅，整体策略仍然成立。DeepSeek：用成本领先重设市场价格锚DeepSeek 的主要武器是低推理成本、低公开价格、缓存优惠、峰谷定价和较低的迁移门槛。极低价格能够让 DeepSeek 迅速进入默认路由。承接预处理、代码、RAG 和普通 Agent 任务。峰谷价格把可延迟任务移到空闲时段。缓存低价则鼓励用户把长上下文和高频调用放到同一平台。DeepSeek 争取的也不只是当前 API 收入。行业影响力、开发者入口、模型标准和未来产品扩展空间都属于其战略收益。它对高价厂商的压力，在于不断降低能力已经够用的市场价格。一旦客户认为低价模型可以完成任务，高价模型就必须证明自己能显著提高成功率。阿里 Qwen 与字节豆包：模型低价，云平台回收阿里和字节都拥有模型之外的基础设施与业务入口。Qwen 可以通过开放权重和多尺寸模型矩阵扩大开发者覆盖。再由 Model Studio、云计算、企业部署和行业服务实现收入。阿里云已经对 Batch、Context Cache 和实时推理进行差异定价。缓存读取价格可以显著低于普通输入。豆包则可以利用消费应用、内容流量和火山引擎扩大调用规模。低价模型进入客服、营销、内容和互联网应用后，可以继续带动企业推理、多模态服务和云资源消费。火山方舟也已经提供在线推理、批量推理和上下文缓存等不同服务形态。这两类厂商都可以把模型作为云平台的获客入口。Token 毛利下降，只要带动的云资源和企业服务收入足够大，整体收益仍然可能增加。Meta：让模型层商品化，争夺开放生态Meta 选择开放模型权重。让开发者和企业自行部署、微调和优化模型。这种策略相当于把模型许可价格压到很低。同时把推理成本交给云厂商和使用者承担。Meta 获得开发者生态、技术标准和应用能力。也会压缩闭源模型的长期定价空间。当开放模型逐渐达到足够好的水平，闭源厂商就需要把收费点继续向 Agent、工具、企业安全和托管服务迁移。Kimi、智谱等独立厂商：在局部市场建立能力溢价缺少大型云业务和广告业务补贴的独立模型厂商，很难长期承受全面价格战。更可行的路径是集中在长上下文、Coding、复杂推理和垂直行业等高价值场景。它们可以通过 API 兼容降低迁移门槛。通过旗舰模型和订阅计划获取收入。再用搜索、工具、Agent 服务和行业交付扩大客单价。例如 Kimi 把长上下文、编程 Agent 和深度推理作为重点场景。同时兼容 OpenAI API 格式，降低开发者接入成本。这类厂商必须证明自己在某些任务上的成功率显著领先。能力相近、价格稍低的中间位置，很容易受到低价模型和大厂旗舰的双向挤压。把各家厂商放进同一张博弈表博弈方主要目标主导策略最大风险OpenAI控制智能入口全价格带、订阅、Agent 生态低价模型侵蚀中端调用Anthropic获得专业能力溢价高可靠、高价、企业服务能力差距缩小Google带动云、搜索和办公生态低价引流、分层定价、捆绑生态协同无法转化为客户锁定DeepSeek重设行业价格锚成本领先、峰谷定价、缓存低价低价难以形成持续利润阿里 Qwen扩大模型与云生态开放权重、模型矩阵、云回收开源使用量无法转化为云收入字节豆包获取高频调用和企业流量低价、消费端分发、火山引擎通用模型高度同质化Meta推动模型层商品化开放权重、生态扩张模型影响力难以形成直接收入Kimi、智谱建立局部能力溢价长上下文、Coding、Agent被低价与旗舰模型双向挤压对手出牌以后，厂商如何反应模型定价是一场连续博弈。每次降价、开放权重或能力升级，都会引发对手调整。对手动作常见应对低价模型大幅降价推出小模型防御，下调 Cache 和 Batch 价格，保留旗舰价格旗舰模型提价挑选相近能力的型号降价，提供迁移优惠，争夺路由流量开放模型达到可用门槛强化托管、SLA、安全、工具和 Agent 服务云厂商进行捆绑销售独立厂商强调模型能力、平台中立和跨云部署多模型路由平台扩大提供阶梯折扣，建设自有路由，用 Context 和工具绑定客户这场博弈最终会形成三种市场均衡：第一，通用 Token 高度同质化。价格逐渐靠近边际推理成本。第二，前沿模型保持差异化。少数厂商继续获得能力溢价。第三，企业市场通过长期合同谈判。Token 价格与 SLA、容量、安全和 Context 服务捆绑。最危险的是中间位置。成本无法做到最低。能力又没有拉开明显差距。这样的模型既无法赢得价格战。也难以获得高端任务的价值溢价。六、为什么 Token 单价长期下降，整个市场的花费仍可能上升价格下降会释放原来不存在的需求。当一次调用很贵时，企业只把模型用于少数重要任务。价格下降后，模型会进入每封邮件。每段代码。每次搜索。每个客服对话。Agent 又把一次短调用变成长时间、多步骤的连续执行。可以把企业 AI 总支出写成：AI 总支出 = 单位 Token 价格 × 每项任务 Token 数 × AI 执行的任务数量第一项持续下降。后两项可能以更快速度增长。这与历史上的计算机、带宽和云服务相似。单位成本越来越低。总消耗量和总市场规模继续扩大。Token 越便宜，企业越敢于让 Agent 阅读更多上下文。尝试更多方案。调用更多工具。价格战真正争夺的也清晰了。厂商牺牲一部分单位毛利。希望自己承接未来增长最快的 Token 消耗量。举个例子。十年前服务器租金很贵。现在便宜多了。但是云市场的总体支出却增长了十几倍。同样的道理适用在 Token 上。七、未来三到五年，Token 定价会怎样演化相同智能的价格继续下降，最前沿智能仍可维持高价当低价模型达到上一代旗舰水平，旧能力会迅速商品化。新旗舰如果解锁新的高价值任务，仍能重新建立溢价区间。因此市场会同时出现两条曲线。固定能力水平的价格持续下降。能力最前沿的价格反复抬高后再下移。价格表会从一维变成多维未来的价格表会加入更多变量。包括推理强度、响应速度、上下文长度、缓存读写、峰谷时段、并发保障、数据驻留和工具调用。模型厂商会尽量让每一类客户为自己最在意的资源付费。比如说。需要低延迟的客户多付钱。可以接受延迟的客户享受折扣。长上下文任务单独计价。缓存命中的调用价格更低。多模型路由会成为价格发现者单一模型很难在所有任务上同时做到能力最强、速度最快和价格最低。路由平台会根据任务难度、时延要求和预算实时选择模型。一旦路由层掌握任务入口，它就能知道完成某类任务的最低有效成本。模型厂商的公开标价会变成报价。路由层掌握真实成交价与分配权。未来的重要竞争，将发生在谁控制默认路由。想象一下。你提交一个任务。路由平台自动选择最合适的模型。便宜的用它。贵的也用。全程你不用操心。可复用 Context 会形成新的价格层长任务中，大量输入来自企业知识、历史对话、工具定义和工作状态。这些内容反复计算会产生巨额浪费。缓存价格大幅低于普通输入价格。已经表明可复用 Context 正从附属功能变成独立资源。未来企业关心的指标会从用了多少 Token 扩展。到多少 Token 被重复计算。多少上下文可以复用。多少业务知识能跨模型保留。模型越频繁切换，稳定的 Context 层越有价值。比如一个客服系统。每天的常见问题答案可以缓存在系统里。下次遇到类似问题直接从缓存读。不重新调用模型。厂商收入会向 Token 之外迁移通用 Token 的毛利被竞争压缩后，收入会更多来自订阅席位。Agent 服务。工具调用。企业 SLA。专属容量。安全治理。数据与 Context 管理。模型成为流量入口。利润分布在入口上方和周边服务中。举个例子。微软 Copilot for Enterprise 不光收模型调用费。还收订阅费和集成服务费。这才是真正的收入大头。八、普通用户和企业应该怎样比较模型价格面对复杂价格表，可以先放下每百万 Token 最低价。用真实任务做一次小规模测试。至少记录六个指标：指标要回答的问题单次任务 Token 账单输入、输出、缓存和工具一共多少钱首次成功率不返工能否直接使用平均重试次数为得到合格结果需要调用几次人工审校时间人需要花多少时间检查和修改任务完成时延等待是否影响业务流程切换成本更换模型要不要重写提示词、工具和数据接口最后计算每次成功任务的总成本。这个数字能穿透大部分定价话术。低价模型如果需要频繁重试，可能并不便宜。高价模型如果显著减少人工并提高成功率，也可能更划算。缓存、Batch 和路由优化带来的节省，往往比追逐一张最低标价更大。给你一个实操步骤。选 10 个典型任务。分别用 A 模型和 B 模型跑一遍。记录每个任务的实际花费和时间。算出哪个模型综合成本更低。结语：Token 会越来越便宜，智能不会只有一个价格大模型市场正在形成一套分层定价体系。通用能力不断商品化。价格向成本靠拢。前沿能力持续打开新任务。价格靠近业务价值。缓存、Batch、峰谷和优先服务，把同一款模型拆成多个算力市场。Agent 与垂直应用继续向上走。开始按任务结果收费。新模型每次发布，都在同时改写成本地板。价值天花板。竞争闸门。因此未来最重要的问题不会是哪家 Token 最便宜。而会是：谁能用最低的总成本，稳定完成最有价值的任务？这才是 Token 定价博弈最后要回答的问题。
AI Infra：市场缺少 Token 运维服务（Token Runtime Platform）
Token Runtime Platform 将像云时代的 CMP+APM+FinOps 一样，成为 AI Native 企业的软件新基础设施，只是管理对象从计算资源变为 Token Runtime。核心部分是：可观测性和 FinOps一、市场三阶段：每阶段6-12个月企业关注“怎么用上 AI”（AI Gateway、Prompt、RAG），管理 Model。关注“怎么稳定运行”（成本、Agent 资源、Workflow ROI），管理对象从 Prompt → Context → Token → Workflow，Token Runtime Platform 需求出现。关注“怎么运营 AI”（数千 Agent、万亿 Token/天），管理 Enterprise AI Runtime，平台成为基础设施。二、为什么必然出现AI Runtime 与 Kubernetes 演化路径一致：LLM → Gateway → Context → Agent → Token Runtime → Governance，复杂度驱动。三、市场空间企业 AI 成本中，GPU 占比下降，模型 API、Context、Agent Runtime 和 Token 快速增长，最终 Business Tokens 指数增长，管理 Token 的需求同步上升。四、产品架构（四层）Runtime Access：统一入口（API/Model/Agent/MCP Gateway），采集全部运行时数据。Runtime Intelligence：数据平面，为 Prompt、Context、Embedding、Agent 等生成 Trace/Metrics/Events/Logs。Runtime Analytics：核心壁垒，解析 Token 用量、成本、延迟、业务 KPI，建立 Prompt→Context→Agent→Workflow→部门的映射。Runtime Governance：运营层，含 FinOps（预算/计费/ROI）、Policy（限流/审批/配额/模型选择）、Optimization（Prompt 压缩/KV 缓存/模型路由），形成 Observe→Analyze→Optimize→Govern 闭环。未来第五层 Autonomous Runtime：系统自动发现成本过高→压缩 Context、模型过大→切换、Cache Miss→预热、ROI 下降→修改 Workflow。五、竞争空白现有产品（AI Gateway、LLM Observability、APM、FinOps、Agent 平台）只覆盖局部，缺少整合 Runtime Intelligence + Business Intelligence + FinOps + Governance 的 Token Runtime Platform。六、投资价值市场：早期，需求显现。技术门槛：高（需深入 Runtime、模型、Agent、业务语义）。客户价值：高（直接降本增效）。替换成本：高（沉淀全链路运行数据和治理策略）。平台潜力：高（可扩展为 AI Control Plane）。窗口期：全球尚无明确领导者。6.1 两大护城河：运行时语义数据（Prompt 演化、Context 模式、Agent 协作等）治理策略资产（路由/预算/压缩/调度规则）6.2 长期判断企业软件从云计算（CPU/内存→CMP）→云原生（容器/服务→K8s）→AI Native（Token/Context/Agent/Workflow→Token Runtime Platform），未来管理核心从资源转向智能执行过程。该平台将从运维工具进化为 AI 运行控制面，统一连接模型、Agent、上下文、业务语义，构建可观测+成本治理+自动优化+运营管理。率先建立数据与策略双重壁垒者，有望成长为 AI Native 的基础设施。
AI Infra：解构 DSpark，Speculative Decoding 的三层逻辑
DSpark 底层采用"空间换时间"的设计，通过预测、并行执行、验证、回滚四个步骤，将串行 Token 生成转换为块级并行执行；在预测和验证阶段，利用 KV Cache 对 Transformer 的中间状态进行复用，实现增量计算，从而进一步提升执行速度。以下是对 DSpark（及整个 Speculative Decoding 架构）的理解：层次核心机制核心作用第一层空间换时间 (Memory → Compute)增加缓存与中间状态存储，减少重复计算第二层预测 + 并行 + 验证 + 回滚将串行生成转化为并行执行流第三层KV Cache 复用支撑预测和验证阶段的高速增量计算这三层共同作用，缺一不可。第一层：空间换时间 (Space for Time)这是整个系统设计的根本基石，究竟增加了哪些“空间”？Draft Model（草稿模型）Draft KV Cache（草稿缓存）Target KV Cache（目标缓存）Hidden State（隐藏状态）Confidence State（置信度状态）这些都是额外占用的 GPU Memory。而它们换来的是什么？更少的 Forward 调用更少的 Attention 计算更高的 Token/s 吞吐因此，从系统设计的宏观视角来看，其逻辑链条十分清晰：更多 Memory (空间) ↓ 更少 Compute (计算) ↓ 更低 Latency (延迟)这就是典型的以空间换时间策略。第二层：预测 + 并行 + 验证 + 回滚真正让推理性能发生数量级跃迁的是这一层。对比传统 Decoder 与 DSpark 的执行流差异：传统 Decoder（串行的囚徒）：Predict ──↓── Forward ──↓── Predict ──↓── Forward ...每一步都等待上一步的结果，无法并行。DSpark（并行的突围）：Predict 8 Tokens ↓ 一次 Parallel Verification ↓ Accept / Rollback（按需修正）在此过程中，Forward 的次数发生了本质变化：8 次 Serial ↓ 缩减为 2 次 BatchGPU 不再不断等待单个 Token 的产出，而是转为一次性处理整个 Token Block。这里的核心贡献在于：把串行依赖改造成块级（Block-level）的并行执行。第三层：KV Cache 的角色定位KV Cache 在整个流程中承担的是加速器的角色，而非并行机制本身。以 Draft 模型预测一个序列 ABCDEFGH 为例：如果没有 KV Cache：A —— 重新算 Prompt B —— 重新算 Prompt+A C —— 重新算 Prompt+A+B每一步都在空转过去的计算。如果有 KV Cache：Prompt ——→ KV ↓ A ——→ KV+ ↓ B ——→ KV+它解决的问题非常具体且关键：每生成一个 Token，不需要重新计算前面的 Attention。因此，它的加速范围是明确的：Draft Prediction（草稿预测）Target Verification（目标验证）但它并不直接决定：Prediction Accuracy（预测准确率）Parallelism Capability（并行能力）需要特别强调的是： 严格来说，KV Cache 加速的是“状态复用”，而不是“并行”本身。并行来自于 Speculative Decoding 的算法设计。即使完全没有 KV Cache，理论上仍然可以进行并行预测和验证，只是每一步都会重复计算 Attention，导致性能急剧下降。超越 LLM：一种预测驱动的并行范式结合近期对 Token Factory 的探索，我们可以将上述机制抽象为一种更通用的基础设施优化范式：State (状态) ↓ Prediction (预测) ↓ Parallel Execution (并行执行) ↓ Verification (验证) ↓ Commit / Rollback (提交或回滚)在这个通用框架下：State： 对应 KV Cache、Workspace、Business Memory、Ontology 等可复用的上下文状态。Prediction： 用于提前推测未来的执行路径或结果。Parallel Execution： 将原本线性的流程转换为块级并行处理。Verification： 保证最终结果与原始基准完全一致。Rollback： 处理预测失败的局部修正机制。这套“预测驱动的并行执行”范式已经超出了 LLM 推理本身的范畴。CPU 的分支预测、数据库的事务执行、现代 AI 推理优化，甚至未来 Agent 的工作流编排，都可以归纳到这一套逻辑中，将业务流程中的“预测、验证、状态复用”构建为统一的优化模型。
从模型军备竞赛到业务语义战争过去两年，企业AI的讨论始终围绕三个关键词展开：更大的模型、更便宜的推理、更长的Context。这三个方向本质上都是在优化「大模型处理通用信息的能力」，而当GPU算力不再是瓶颈、开源模型效果追平头部闭源模型、RAG与Agent框架成为通用组件时，企业AI的「通用基建红利」已经见顶。进入2026年新的产业周期，核心关注点正在发生明确转移。Databricks发布Genie One、Genie Ontology、Genie Agents，将企业AI的核心从SQL Copilot升级到Business Context（业务上下文）。官方将Genie Ontology定义为「持续演化的业务知识图谱与上下文层」，用于为Agent提供统一、可信的业务语义。SelectDB在最新（20260626）产品战略中，将AI能力深入数据库内核，强调语义理解、企业知识以及Agent与数据系统的一体化，不再停留在传统数据库查询能力，产品方向明确从「数据库」转向「AI数据基础设施」。这两家公司分别代表了两条技术路线：Databricks从湖仓平台向上延伸做语义封装，SelectDB从数据库内核向上做语义内嵌，路径不同，却共同指向同一个产业共识：企业 AI 的竞争中心，已经开始从 Model Layer 转向 Business Context Layer。这正是 Business Token Factory（企业Token精炼厂） 对应的下一代产业机会。一、企业AI缺的不是模型，是Business Token当前企业已经配齐了所有AI落地的基础能力，且均已形成标准化的开源或商用方案，不存在不可逾越的技术壁垒：能力是否成熟GPU算力是基座模型是推理框架是向量数据库是数据仓库是MCP（模型上下文协议）是理论上，一个Agent已经可以打通企业所有业务系统。但真正的核心问题是：Agent 能连接数据，并不代表理解业务。举个最常见的场景：你问Agent「本月华东区的销售额完成率是多少」，它能从ERP里拉出所有订单数据，但它不知道：华东区要不要算刚并入的安徽区域？销售额按下单时间还是回款时间计算？经销商的退换货要不要倒扣？这些规则散在各个部门的SOP、财务的私人Excel、业务负责人的经验里，从来没有被结构化、统一化、持续更新过。原始数据库里只有Customer（客户）、Order（订单）、Inventory（库存）这类基础字段，但Agent真正需要回答的是：哪些客户存在流失风险？哪些订单需要优先审批？哪些库存正在影响利润？当前销售目标有没有缺口？这些信息既不存在于原始数据库中，也无法靠单次查询得到，它需要基于统一的业务规则持续计算、动态更新，最终形成全公司对齐的标准语义。我们把这种经过业务语义校准、可直接被Agent理解和推理、携带完整业务上下文的最小信息单元，叫做Business Token。它既不是数据库的原始字段，也不是大模型的分词Token，更不是静态的元数据，而是企业业务状态的动态抽象。因此，企业AI落地的真正缺口从来不是数据，也不是模型，而是Business Token。二、产业已经验证：Context Layer正在成为新的平台层Databricks发布最核心的产品，不是面向终端的Genie One，而是位于整个技术栈中间的Genie Ontology，它的出现，意味着Databricks的产品结构已经发生了本质变化：Genie One（终端应用） ↓ Genie Agents（智能体层） ↓ Genie Ontology（业务语义层） ↓ Unity Catalog（数据目录） ↓ Lakehouse（湖仓平台）这里最大的变化是：Genie Ontology不再只是传统意义上的元数据，它开始承担业务实体、KPI定义、业务规则、业务关系、权限管控等核心职能，官方将其描述为「持续学习、持续更新的企业Context Layer」，所有Agent的回答和执行都必须建立在这层业务语义之上。意味着Agent不再直接连接数据库，而是连接统一的Business Context。SelectDB的产品演进则验证了另一个方向：过去数据库的核心能力是SQL查询，现在大量语义理解、AI算子、Agent接口、业务逻辑正在向数据库内核迁移，数据库厂商已经明确意识到：未来企业的核心竞争点从来不是SQL引擎的性能，而是Business Semantic Engine（业务语义引擎）。一条从应用层往下封装，一条从基础设施层往上内嵌，两条路线最终的目标完全一致：业务语义内嵌。三、Business Token Factory：企业业务上下文的生产线如果基于这个趋势重新梳理整个企业Agent技术栈，会得到一个非常清晰的分层结构：Enterprise Agent（企业智能体） ↓ Business Context Runtime（业务上下文运行时） ↓ Business Token Factory（企业Token精炼厂） ↓ Enterprise Data（企业原始数据） ↓ Storage（存储层）Business Token Factory不做存储数据、训练模型、提供GPU这类通用基建，它只做一件事：持续生产标准化的Business Token，比如：订单延期风险、客户流失概率、预算超支事件 审批优先级、供应链异常、利润变化原因这些Token不需要Agent再做额外的语义校准，可以直接进入推理环节，因此Business Token Factory本质上是「企业业务上下文的标准化生产线」。结合Databricks的产品分层，我们可以清晰看到它的定位差异：产品层DatabricksBusiness Token FactoryAgent层Genie AgentsEnterprise Agents运行时层Genie OntologyBusiness Context Runtime引擎层Ontology（内置）Business Semantic Engine（独立）数据层Unity CatalogHTAP / Lakehouse（混合事务/分析处理）存储层Object StorageAI Storage二者最大的区别只有一层：Business Token Factory将业务语义引擎从数据平台的内置能力中独立出来，成为专门的Business Token生产层，而不是数据平台的附属功能。四、商业模式验证：从项目制到生态的四层演进Databricks的收入结构已经率先发生变化：过去它的核心收入来自算力、SQL查询、湖仓存储，现在Genie One、Genie Agents、Genie Ontology正在成为新的收入支柱——也就是说，它的收入来源已经从「卖数据基建」转向「卖企业AI运行时」。Business Token Factory的商业模式可以在此基础上进一步延伸，沿着企业软件的成熟路径分为四层，逐步从项目制升级为平台生态：第一层：项目实施收入帮助企业完成Agent、工作流、业务上下文的从0到1部署，交付标准化的AI落地方案，获得一次性项目收入，完成初始的客户积累。第二层：基础设施总包收入整合GPU、存储、基座模型、数据库等所有通用基建，作为企业AI的总服务商统一交付，企业不需要分别采购不同厂商的产品，只需要支付整体AI项目费用，Business Token Factory成为企业AI基础设施的统一入口。第三层：订阅制ARR收入持续为企业提供动态更新的Business Context，收费方式从一次性项目费转向按使用量付费的订阅制：包括上下文运行时费用、Business Token订阅费、Agent运行时费用、工作流运行时费用，收入结构转为稳定的ARR（年度经常性收入）。第四层：生态型网络效应收入随着越来越多的Agent、应用接入同一套Business Token，平台会积累全行业的业务上下文、工作流标准、Agent使用数据，最终形成Context Intelligence（上下文智能），具备持续的数据网络效应，成为行业级的业务语义标准。这四层演进本质是从「卖人力」到「卖能力」再到「卖标准」的升级，壁垒远高于普通SaaS，因为它绑定了企业最核心的业务语义资产。五、核心壁垒与架构变革当前很多企业的AI落地还停留在「ERP→RAG→LLM」的简单链路，实践已经反复验证这个方案存在四个共性痛点：业务定义不统一：同个「活跃用户」，销售定义是30天下单，运营定义是7天登录，Agent给出的结果没人信推理结果不稳定：同一个问题问两次，得到两个不同的答案，缺少一致的语义标准没有统一KPI体系：各部门的指标口径没有对齐，无法支撑跨部门的业务决策无法持续迭代：业务规则变化后，需要手动调整RAG的知识库，无法自动学习更新Databricks推出Genie Ontology的核心目标，正是解决这个问题：建立统一的业务定义、业务实体、业务关系，为Agent提供可信的上下文基础。这意味着未来企业AI的核心组件，从来不是更大的知识库，而是Business Semantic Module（业务语义模块）：它持续维护企业的实体、关系、状态、规则、事件，动态生成标准化的Business Token，不再是数据库的附属能力，也不只是RAG的前处理环节，而是整个企业AI Runtime的核心。与之对应，未来的企业软件架构将彻底从「Data Pipeline（数据管道）」转向「Business Token Pipeline（业务token管道）」：ERP / CRM / MES / OA（业务系统） ↓ Business Semantic Module（业务语义模块） ↓ Business Token Factory（Token精炼厂） ↓ Business Context Runtime（上下文运行时） ↓ Enterprise Agent（企业智能体） ↓ Workflow（工作流） ↓ Business Action（业务动作）原始数据不再直接进入大模型，而是首先进入业务语义模块，完成业务理解、状态计算、关系推导、事件生成，形成标准化的Business Token之后，再进入Agent参与推理。六、投资启示：Business Token Factory是Agent时代的新业务操作系统Databricks没有继续卷模型能力，而是投入重兵做业务语义；SelectDB没有继续卷数据库性能，而是聚焦AI与业务语义的融合——两条完全不同的技术路线，最终汇聚到了同一个产业方向：企业AI的核心竞争力，不再是模型接入能力，而是业务语义的持续生产能力。Business Token Factory正是这一趋势的进一步演化：它将业务语义模块从辅助能力提升为企业AI的核心运行层，持续将零散的企业数据加工为可计算、可推理、可执行的Business Token，向所有Agent提供统一的Business Context Runtime。随着企业内部Agent的数量持续增长，Business Token Factory有机会成为企业AI的统一入口，连接算力、存储、数据库、基座模型和所有业务系统，成为企业AI的总控平台。在这个架构中，业务语义模块不再只是提高模型准确率的组件，而是企业AI能否规模化落地、持续演进、形成商业闭环的核心基础设施。过去三年，企业AI的故事是「用大模型重构一切」；接下来三年，故事的主线会变回「企业本身」——谁能帮企业把散落在各个系统、各个部门、各个员工脑子里的业务逻辑，提炼成可复用、可信任、可进化的Business Token，谁就会成为Agent时代的Windows，成为所有企业AI应用的底层业务操作系统。
别再叫它 API 聚合了，它正在控制 AI 世界的“石油管道”上周和一个做投资的朋友聊天，他抱怨说现在看 AI 项目看到头秃。基础模型那波已经卷成麻花，应用层又虚头巴脑，找不到护城河。我给他画了张图，他一下就懂了。我说，你别盯着挖金矿的（模型厂商）和卖水的（云厂商），你应该去看那条“输油管道”。而这条管道里流淌的，不是石油，是 Token。管道的控制者，我把它叫做 Token Factory（Token 工厂）。OpenRouter、Portkey、LiteLLM Cloud 这些公司，都在这条赛道上。它们生产的不是模型，而是一个标准化的产品：推理 Token。这玩意儿才是 AI 商业化的真正咽喉。为了讲清楚这个逻辑，我把 Token Factory 的商业模式拆成了五层。这五层，从低到高，价值完全不同。一、最底层：Token 转售，听着像二道贩子，其实是“AI界的Stripe”最早期，这门生意听起来一点都不性感，甚至有点 low。说白了，就是个二道贩子。比如 OpenRouter，它自己一个模型都不训。它先从 OpenAI、Anthropic 那儿批量“批发”模型推理能力，再零售卖给我们这些开发者。用户付 $100 │ ▼ OpenRouter（过一手） │ │ 付 $95 ▼ OpenAI / Anthropic收入哪来？就挣那 5% 左右的差价和充值手续费。乍一看，这护城河也太浅了，不就是个倒买倒卖的生意吗？但有意思的地方在于它的定位。它刻意保持 Token 的官方原价，然后靠服务费赚钱。这招非常聪明，它不是在跟模型厂商抢利差，而是在做支付和渠道的基础设施。所以，准确的定义不是“AI 代理商”，而是 AI 时代的 Stripe。它解决的是一个极其无聊但极其重要的问题：让开发者用一行代码，就能接入全世界所有的模型，不用管后面那一堆账单、密钥和对账。这一层，赚的是辛苦钱，但也是所有故事的起点。二、第二层：路由，从“管道”到“大脑”，真正值钱的来了如果只做一层，Token Factory 永远只是个微利的管道工。真正让它开始值钱的，是第二层：Routing（路由）。这玩意儿我天天在用，感受太深了。比如我随手发一个请求：“帮我用 Python 写个二分查找。”一个好的 Router，它脑子里会瞬间闪过一堆决策：任务分析：这是一个标准代码任务。模型匹配：Claude Sonnet 干这活最利索，性价比最高。成本计算：不用上 GPT-4，浪费钱。执行：直接把任务甩给 Sonnet。如果我再问：“帮我研究一下最近 AI 制药的新突破。”Router 又会立刻判断：这是深度研究任务，得调用具备联网或深度推理能力的模型，比如有 Deep Research 功能的 GPT 或 Gemini。看到了吗？从此以后，作为用户，我们根本不需要关心模型叫什么。我们只关心三个词：最便宜，最快，最准。但对企业来说，这背后还有更深的逻辑：成本调度、延迟调度、SLA 调度、自动灾备、多云切换……这些能力让 Router 瞬间从一个管道工，变成了一个指挥交通的操作系统（Inference OS）。护城河一下子就冒出来了——算法和调度数据，是模型厂商自己都无法轻易复制的。三、第三层：算力市场，当“AI司机”的 Uber再往下走一层，事情就更有意思了。现在越来越多的独立推理服务商（Inference Provider）爆发式增长，比如 Groq、Together、Fireworks。他们手里有海量的 GPU，专门优化推理速度，比通用云快得多、也便宜得多。Token Factory 做了什么？它把这些分散的“算力司机”全部接入了自己的网络。于是，商业模型变成了一个双边市场：供给侧：成千上万的 GPU 集群，随时待命。需求侧：数百万开发者，嗷嗷待哺地发出推理请求。平台：Token Factory 居中调度，撮合交易。这像极了 Uber。Uber 不拥有任何一辆车，但它控制了出行服务的调度和定价。Token Factory 也一样，它不拥有任何一块 GPU，但它控制着推理能力的生产和分发。这也是为什么现在很多投资人不再提“API 聚合”，而开始用 AI Compute Marketplace（AI 算力市场） 这个概念。这个叙事，比卖接口要性感十倍。四、第四层：Token 财务治理，比“省钱”更重要的是“知道钱花哪儿了”好了，当一个公司开始大规模使用 AI 时，一个恐怖的场景出现了：Token 花费完全失控。财务总监会发现，他不知道那 10 万美金的账单是怎么来的。是研发部在疯狂调优？是市场部在批量生成文案？还是某个失控的 Agent 陷入了死循环，一夜之间花掉 800 万 Token？Token Factory 在这里找到了第四层价值：Token FinOps（Token 成本治理）。他们提供的已经不是一个 API 接口，而是一个管理面板。功能包括：预算、配额、角色权限、实时花费、成本归属、计费仪表盘。谁花的，花了多少，花在哪个模型上，ROI 是多少，一目了然。这一刀，直接切中了企业级客户的命门。你卖 API，IT 部门可能觉得你在增加他们的工作。但你卖管理和控制，CFO 都会帮你说话。所以，这一层的产品，已经从“工具”变成了“SaaS 订阅服务”，护城河是企业管理能力。五、第五层：Token 智能，这是终极的“上帝视角”和真正的护城河以上四层，都是业务和产品上的创新。但最让我觉得恐怖的，是第五层：Token Intelligence（Token 智能）。因为这些平台每天处理着天文数字般的推理请求，它们手里握着全世界最珍贵的数据。比如 OpenRouter，每周处理数万亿 Token，它们能看到：哪个模型的代码能力被调用得最频繁？哪个推理服务商最近频繁宕机？哪种 Prompt 技巧的成功率最高？哪种类型的 AI 应用正在爆炸式增长？这太可怕了。这种跨模型的、全局的、真实的推理行为数据，是任何一家模型厂商都绝对拿不到的。OpenAI 只能看到自家 GPT 的表现。Anthropic 只能了解 Claude 的优缺点。但 OpenRouter 站在上帝视角，看着所有模型在同一个擂台上打群架，知道每一场具体的比分和细节。这形成了一个无法被超越的数据网络效应：接入的平台越多，数据越厚；数据越厚，路由越准；路由越准，用户越多。从去年开始，OpenRouter 已经开始基于这些数据发布论文，研究超百万亿 Token 的模型真实使用状况了。这已经不是在卖 Token，而是在掌握 AI 产业的真实脉搏。它的价值，彻底从管道，变成了大脑，又变成了预言家。总结：一条全新的价值链所以，别再把它看作一个简单的接口工具了。把视野拉高，它正在形成一条控制“AI 推理经济”的全新价值链。结合我之前研究的“Token 经济”框架，现在这张图可以画完整了：Model Factory（模型工厂）：OpenAI、DeepSeek，生产的是基础模型能力。Token Factory（Token 工厂）：OpenRouter、Portkey，生产的是通用、可调度的推理 Token。Business Token Factory（业务 Token 工厂）：将企业散落的数据，持续转化为高价值的、带着业务语义的业务 Token。Agent Factory（智能体工厂）：Manus、OpenHands 等，拿着上面的推理 Token 和业务 Token，去执行具体的业务动作。结论就是，在 AI 狂飙的时代，谁控制算力、谁控制模型，当然重要。但谁控制了 Token 的生产、调度、结算和运营，谁就掌握了将算力和算法变现的“水龙头”。OpenRouter 正在做的事，就是让自己从一个卖水管的，变成那个掌握水龙头的总闸。而我们，正在用水龙头的另一边——业务数据——制造出能真正浇灌企业价值的特种水源。
Databricks Genie 战略解读：从数据平台到上下文平台的跃迁
核心观点：企业 AI 的竞争焦点已从数据基础设施（Data Infrastructure）转向上下文基础设施（Context Infrastructure）。一、战略背景：为什么是现在？Databricks 此次发布了Genie系列产品，Genie One, Genie Agents, and Genie Ontology，是一次架构升级。战略意图清晰：将 Databricks 从传统的 Lakehouse（湖仓）升级为企业 Agent 的运行平台。架构演进路径：Data Platform（数据平台） ↓ Context Platform（上下文平台） ↓ Agent Platform（智能体平台）核心驱动因素：外部驱动： 企业 AI 应用落地受阻，模型能力虽强但缺乏业务语境。内部驱动： Databricks 需构建新的增长曲线，从存储计算转向智能决策。二、环境分析：企业 AI 的真实瓶颈Databricks CEO Ali Ghodsi 指出："Enterprise AI has a context problem."（企业 AI 存在上下文问题）2.1 核心痛点企业 AI 失败的原因并非模型推理能力不足，而是缺乏企业语境（Business Context）。场景示例： 销售 Agent 回答“哪些客户值得重点跟进？”所需上下文： CRM 数据、历史订单、组织结构、Slack 讨论、Jira 项目、产品文档、KPI 定义等。现状： 信息散落在 50+ 不同系统中，传统 RAG（检索增强生成）难以解决。2.2 差距分析传统方案： Document + Vector Search + LLM。缺失环节： 缺乏统一的业务语义层，导致 Agent 无法理解数据背后的业务含义。三、核心战略：从 Data 到 Context 的跃迁Databricks 新战略的核心在于抽象出了Context Layer（上下文层）。这是此次架构升级最大的战略价值。新三层架构：Genie One（用户入口） ↑ Genie Agents（执行单元） ↑ Genie Ontology（核心语境） ↑ Lakehouse（数据底座）战略定位变化：传统 Lakehouse： 管理 Data（数据）。新 Genie 平台： 管理 Meaning（含义/语境）。四、产品战术：Genie 三层架构解析4.1 核心层：Genie Ontology（上下文本体）这是投资人应关注的核心资产。定义： Self-improving Context Layer（自进化上下文层）。功能： 自动抽取业务指标、组织关系、业务规则、数据血缘、实体关系。构成： Knowledge Graph（知识图谱）+ Semantic Layer（语义层）+ Metadata Layer（元数据层）。价值： 形成统一的企业语义层，让 Agent 理解业务逻辑。4.2 执行层：Genie Agents（智能体）Databricks 对 Agent 的重新定义：Agent = Prompt + Ontology + Workflow机制： 任何 Genie 对话均可保存为 Agent。继承能力： Memory（记忆）、Instruction（指令）、Context（语境）、Workflow（工作流）、Tool（工具）。场景： 每周销售分析、库存监控、客户流失预警等重复性问题自动化。4.3 入口层：Genie One（用户界面）类似“企业版 ChatGPT"，但具备更强的业务执行力。能力维度ChatGPTGenie One查询企业数据部分强调用业务工具部分强执行业务动作弱强示例： 销售经理输入“分析过去 90 天高潜客户并安排会议”，Genie One 可一次性完成读取、分析、生成文档、调用工具及执行任务。五、支持活动：全域知识整合为实现 Context Layer，Databricks 构建了强大的生态整合能力。数据源整合： 支持 Databricks、Google Drive、Slack、Jira、Confluence、SharePoint、CRM、ERP 等 50+ 系统。价值链优化： 将散落在各系统的非结构化数据转化为结构化业务语境。核心能力： 持续学习企业知识，确保上下文随业务变化而更新。六、行业演进：数据基础设施的四代变迁从行业演进角度看，Databricks 正在重复数据库三十年的发展路径，试图成为数据库 + 语义层+Agent 平台的统一体。代际核心产品管理对象代表企业第一代数据库数据 (Data)Oracle, MySQL第二代数仓分析 (Analytics)Snowflake, Databricks第三代语义层业务知识 (Context)dbt, Genie Ontology第四代Agent Runtime业务执行 (Execution)Agent Platforms未来趋势： 企业软件架构将从“用户找系统”（ERP/CRM）转变为"Agent 主动使用系统”。七、控制与启示：投资视角的验证站在数据基础设施初创企业及投资人视角，Genie 发布释放了三个关键信号：6.1 核心信号：Ontology 成为基础设施含义： Context Infrastructure 开始独立成层。验证： 全球数据基础设施龙头已将竞争焦点从 Data Infrastructure 转向 Context Infrastructure。6.2 产品信号：Agent 直接成为产品含义： 传统 SaaS 界面开始被 Agent 替代。趋势： 交互方式从 GUI 向 LUI（语言用户界面）转变。6.3 平台信号：Lakehouse 向 Agent Runtime 演进含义： 数据平台竞争进入 Agent 时代。终局判断： Databricks 正在把 Context 做成企业知识层，未来很可能走向 Enterprise Agent Operating System（企业 Agent 操作系统）。结论：Agent 时代最稀缺的资产，不是模型，不是算力，而是Context。Databricks 通过 Genie Ontology 构建了这一壁垒，为行业确立了新的竞争标准。
一、项目背景与执行摘要1.1 项目背景驱动因素：外部趋势： AI Agent 爆发式增长，单一 Agent 能力有限，多 Agent 协作成为必然；现有网络架构无法支撑 Agent 间的自动发现与安全互联；缺乏标准化的能力交易与结算机制。内部机遇： 构建 Agent 时代的网络层与交易层基础设施，抢占“身份 - 地址 - 权限 - 价格 - 账本”的关键入口。1.2 执行摘要产品定义： AgentMesh 是为多个 Agent 提供虚拟内网自动发现、互联协作，并按协议完成计费、授权和结算的基础设施平台。核心价值：虚拟组网： 隐藏真实 IP，实现私有逻辑网络内的自动发现与安全访问。能力支付： 将 Agent 能力商品化，支持可定价、可授权、自动结算。战略意图： 成为 Agent 时代的网络层和交易层基础设施，构建“网络效应 + 结算闭环”的核心壁垒。二、市场环境与营销现状2.1 市场机会与痛点痛点维度现状问题AgentMesh 机会点网络连接Agent 暴露公网 IP，风险高，发现难虚拟组网协议：逻辑内网地址，自动发现，安全互联能力交易调用即 RPC，无定价，无结算能力支付协议：能力商品化，按次/按量/按结果付费协作信任组织间协作互不信任，数据不敢共享联邦式网络：多组织协作，互不暴露真实网络2.2 典型应用场景企业内协作： 部门间 Agent 像在同一局域网，安全高效。外包能力调用： 临时购买外部 Agent 能力（如 OCR、推理）。AI 工具市场： 能力像 API 一样被交易，形成生态。私有推理集群： 调度、计费、审计一体化。三、营销目标与营销战略3.1 战略定位定位陈述： Agent 时代的网络层和交易层基础设施。关键入口要素：要素作用身份 (Identity)谁在网络里 (Agent DID)地址 (Address)它能被谁找到 (Overlay Address)权限 (Permission)它能调用什么 (Capability Token)价格 (Price)调用要付多少钱 (Micropayment)账本 (Ledger)发生过什么交易 (Audit Log)3.2 商业模式三层收入结构：基础设施订阅： 月费/年费（面向企业和开发者）。交易抽佣： 每笔能力交易抽成（市场越大，收入越高）。高级网络服务： 专线、中继、审计、合规（面向高要求客户）。增值包策略： 企业私网包、能力市场包、结算包。3.3 竞争壁垒壁垒类型核心内容护城河效应网络协议组网、路由、穿透、密钥轮换技术门槛，难以复制支付协议微支付、预授权、结算、争议处理信任机制，迁移成本高生态网络能力供给方越多，网络效应越强最强壁垒：网络效应 + 结算闭环四、营销组合与营销策略4.1 产品策略 (Product)核心架构：层级模块职责接入层SDK / Agent Runtime一行代码接入网络层Overlay Mesh发现、路由、转发、加密支付层Micropayment Protocol预授权、计量、结算市场层Capability Registry能力上架、搜索、定价审计层Receipt Ledger调用凭证、支付凭证、争议记录关键协议设计：AMP (Agent Mesh Protocol)： 虚拟组网协议。定义 Join, Discover, Dial, Heartbeat 消息。特征：临时身份、地址抽象、端到端加密。CPP (Capability Payment Protocol)： 能力支付协议。定义 Quote, Reserve, Authorize, Prove, Settle 动作。支持按次、按量、按结果付费。4.2 价格策略 (Price)基础服务： 免费 tier 吸引开发者，付费 tier 解锁高级功能。交易抽佣： 初期低抽佣鼓励流通，后期随生态成熟调整。差异化定价： 针对企业私网、高合规需求提供溢价服务。4.3 渠道与推广 (Place-Promotion)开发者社区： 通过 SDK 易用性（30 分钟接入）在 GitHub、技术社区传播。生态合作： 与大模型厂商、Agent 平台合作预装。标杆案例： 打造企业内多 Agent 协作、外包能力调用等标杆场景。五、支持活动与业务流程5.1 关键业务流程接入流程： Agent 启动 -> 注册临时身份 -> 获取虚拟地址 -> 加入 Mesh。交易流程： 发现能力 -> 获取报价 -> 锁定预算 -> 授权调用 -> 提交证明 -> 自动结算。审计流程： 全程记录调用凭证与支付凭证，支持争议处理。5.2 核心能力建设安全技术： mTLS 短期证书、端到端加密、中继不可见明文。结算系统： 高并发微支付处理能力、争议仲裁机制。开发者体验： 极简 SDK、完善文档、沙箱环境。六、实施计划与行动方案6.1 最小可行产品 (MVP)第一阶段目标： 能连、能付、能审计。MVP 模块目标描述Agent SDK让 Agent 30 分钟内接入Overlay Mesh完成私网通信，支持 NAT 穿透Capability Registry实现能力上架与搜索Micropayment Wallet支持小额自动支付Audit Log可追溯调用与账单6.2 实施路线图Phase 1 (0-6 月)： 完成 MVP，验证核心协议，招募种子开发者。Phase 2 (6-12 月)： 完善支付协议，引入首批能力供给方，跑通交易闭环。Phase 3 (12-24 月)： 扩展企业级功能（私网、合规），推动生态网络效应。七、营销组织与营销控制7.1 风险评估与应对风险类型潜在问题应对预案技术风险网络穿透失败、延迟高优化中继节点布局，提供降级方案安全风险身份伪造、支付欺诈强化 DID 认证，引入多方审计机制生态风险早期供给不足，冷启动难官方提供基础能力包，补贴早期交易者7.2 绩效衡量指标网络规模： 接入 Agent 数量、活跃 Mesh 网络数。交易规模： 日均调用次数、GMV、结算成功率。生态健康度： 能力供给方数量、复购率、开发者满意度。7.3 组织保障产研团队： 聚焦协议标准化与 SDK 易用性。生态团队： 负责能力供给方引入与开发者关系。合规团队： 确保支付与数据流转符合各地法规。结语：AgentMesh 不仅是一个技术产品，更是 Agent 经济的生产关系重构者。通过虚拟组网解决连接信任，通过能力支付解决价值交换，最终构建一个开放、安全、可繁荣的 Agent 协作生态。
AI 存储的真正机会在推理，但训练远未到天花板
在投资视角下，仅关注存储总容量的增长远远不够。决定企业价值的核心，是存储被用于何处。下表清晰对比了各存储层级在容量与市场价值上的错配。层级存储容量占比市场价值占比增长驱动力训练存储高中模型训练与后训练推理存储中高Token 规模持续膨胀归档存储很高低全量数据长期保留未来 AI 存储市场最大的结构性变化，并非容量增加，而是价值重心从训练存储向推理存储迁移。然而，训练存储自身仍有可观的增长空间——后训练市场才刚刚拉开帷幕。一、AI 存储的需求拆解AI 时代的存储需求大致可拆为三个部分：训练数据推理状态（如 KV Cache、会话上下文等）归档数据对应的总量公式为：AI 存储总量 = 训练存储 + 推理存储 + 归档存储二、全球市场总规模根据预测，2030 年全球总存储容量约 35 ZB。其中，AI 相关存储的占比将从目前的 10% 以上提升至 30%～40%，对应市场规模约 10～14 ZB。三、训练存储：后训练打开新空间训练存储服务于模型训练的全流程，包括预训练、后训练、SFT、RLHF 以及合成数据训练等。典型厂商有 DDN、WEKA、VAST Data、Hammerspace 等。过往存在一种判断：大模型数量有限，一旦训练集群建成，存储需求便会回落。这一看法忽略了一个关键变化——后训练正在成为主战场。预训练产出的是基础模型，数量确实受限。而后训练则让模型适配具体场景，企业、行业乃至单个任务都需要独立进行：银行为风控模型，医院为病历分析模型等。此类后训练任务成百上千，每个任务都需要海量高质量标注数据、对比数据和合成数据。后训练的特性进一步放大了存储需求：数据高频更新，业务规则变化意味着需要重新处理数据，而非一次定型。数据来源分散，涉及企业自有数据、第三方数据以及合成数据，均需长期保存。实验迭代频繁，同一模型会反复调参比对，大量中间状态和 checkpoint 必须保留。因此，训练存储的利用率并不会如过去预想那样快速下滑。虽然预训练的超大模型数量趋于收敛，但后训练的长尾需求将持续拉动存储增长。至 2030 年，训练存储预计占 AI 存储总量的 20%～25%，约为 2～3 ZB。由于其性能要求高，单价达普通存储的 5～10 倍，对应市场规模约 400～600 亿美元。后训练的进一步扩张还可能推高这一数字。四、推理存储：最大的价值机会推理时代催生了全新的数据类别。过去是“数据进，模型出”，现在则是“状态进，Token 出”。新增的关键数据包括：KV Cache（缓存历史对话的中间计算结果，避免重复推理）会话状态（用户与 AI 交互的完整上下文）Agent 记忆（ AI 助手对用户习惯与偏好的长期记录）业务上下文（如企业的客户数据和流程信息）工作流状态（多步任务的当前进度）这些数据的增长逻辑与训练存储截然不同。训练规模取决于模型数量，而推理规模取决于用户数、Agent 数量以及调用频率。以 ChatGPT 为例，2023 年用户约 1 亿，到 2026 年可能超过 10 亿；Token 消耗的增速远快于模型迭代速度。一名员工现在仅用 1 个 ChatGPT，未来可能同时调用 10 到 100 个 Agent。因此，推理存储的增速将远超训练存储。至 2030 年，推理存储占 AI 存储总量的 40%～50%，约为 4～7 ZB。推理存储对时延极度敏感（亚毫秒级访问），并且要求 KV 共享、GPU 直连和分层缓存，价值密度极高。估算市场规模约 800～1,200 亿美元，将成为最大的 AI 存储细分市场。五、归档存储：量大但价值偏低归档存储用于长期保留原始训练数据集、企业业务数据、日志、视频及 IoT 数据等。其容量占比最大，但单位价值最低，价格趋近于普通云存储。2030 年，归档存储预计占 AI 存储总量的 30%～40%，约 3～5 ZB，对应市场规模 150～250 亿美元。六、中国市场的分化按全球 15%～20% 的比例估算，2030 年中国 AI 存储规模约 1.5～2.5 ZB。细分结构如下：训练存储：0.3～0.5 ZB，市场价值 60～100 亿美元推理存储：0.7～1.2 ZB，市场价值 120～220 亿美元归档存储：0.5～0.8 ZB，市场价值 30～50 亿美元七、投资落脚点2030 年 AI 存储的价值分布将进一步分化：赛道容量占比市场价值占比投资价值训练存储20%～25%30%～35%中高推理存储40%～50%50%～60%很高归档存储30%～40%10%～15%低对应到代表性公司：DDN 深耕训练存储，WEKA 同时覆盖训练与推理，VAST Data 主攻推理存储，MinIO 则立足于归档层。未来十年最值得关注的无疑是推理存储市场，但训练存储同样不容忽视。后训练带来的数据高频迭代、多版本管理以及跨企业数据协作，将持续创造新的存储需求。若结合 NVIDIA 的 AI Factory 路线图，可将市场进一步细分为四层：HBM、KV Cache SSD、AI 文件系统、对象归档。清晰的层次划分，也为存储初创企业标定了市场空间和估值天花板。
AI Infra：Tacnode，面向 AI Agent 与实时自动化决策系统的 Context Lake
1. 定位：Tacnode 是面向 AI Agent 与实时自动化决策系统的 Context Lake，用统一的数据与语义上下文层，替代传统“数据库 + 搜索 + 向量库 + 流处理”的拼接式架构对比其他类型的产品分类Tacnode 的关系数据库有数据库能力，但不是核心叙事HTAP接近，但 HTAP 只是底层能力Lakehouse有实时分析能力，但重点不在 BIFeature Store部分覆盖，但不局限于 ML featureVector DB内置向量能力，但不是单点产品Agent Memory覆盖，但不仅仅存 memoryRealtime Data Platform更接近，但还缺“上下文”表达2. 三段式核心叙事传统数据库解决数据如何被正确保存;Tacnode 解决多个 AI/系统 如何基于同一时刻的真实世界状态做决策2.1 问题：AI 系统正在变成连续决策系统，而基础设施还活在“请求-响应”时代Agent 不再是一次性查询，而是持续运行、持续消费上下文的决策体。多 agent 协同、实时风控、自动化运营，这些新工作负载的共同特征是：高频状态变化 + 多系统共享 + 强一致性 + 实时决策。但今天的基础设施——OLTP、OLAP、搜索、向量、流处理——仍然作为独立的筒仓存在。Agent 拿到的永远是不同步的、延迟的、语义割裂的“部分世界”，这已经不是性能问题，而是一个系统性的正确性问题。2.2 分析：基础设施的核心矛盾已从“数据存储”迁移到“上下文一致性”Snowflake 和 Databricks 解决了数据如何统一存放的问题，但当 AI 自己变成决策主体时，真正关键的不再是“存了多少数据”，而是“多个智能体是否共享同一个实时世界状态”。换句话说，瓶颈从 Compute 转向了 State / Context 的 coherence。这是一个被严重低估的结构性迁移，也恰恰是传统 lakehouse 架构无法天然适配的盲区。2.3 方案：用统一 Context Runtime 收敛所有上下文工作负载Tacnode 把数据库、向量、搜索、流处理和实时分析收敛为一套 Decision‑time Context System。它不是一个更好的数据库，而是一个让所有 AI 系统看到同一现实、基于同一语义进行推理的上下文引擎。无论是 agent memory、实时风控还是多步骤 workflow，Tacnode 提供的是可验证的上下文一致性，而不是一个存储接口。最终，它会成为 AI 系统的 State Infrastructure，一层不会被频繁替换的持久化底座。3. 参考：https://tacnode.io/https://github.com/lotus-data/lotus
AI Infra：Convex Backend数据库，AI Agent 时代的状态同步方案
以前做实时应用，得自己拼数据库、API、Redis、WebSocket，再加上缓存和乐观更新。每一层都独立，状态同步的麻烦事最后全堆给开发者。Convex 试图把这些琐事都包了。它不单是个数据库，更像是一个响应式状态后端运行时。简单说，它把后端压缩成了一个统一的状态同步引擎。它是什么这套东西整合了文档数据库、TypeScript 函数、响应式同步、自动缓存、Serverless 执行，还有 AI 工作流层。但核心不在存储，而在维持客户端与服务端之间一致且实时的状态视图。核心逻辑：声明依赖在 Convex 里，查询不是“读库”。useQuery(api.messages.list) 这行代码其实是在注册一个声明：“我依赖 messages 表”。一旦表数据变动，引擎自动重算查询、算差异、同步到客户端、触发 UI 更新。整个链条由内向外驱动。不用手动搞 WebSocket，不用管缓存失效，也不用引入 Redux 或 React Query 这些中间层。解决了什么麻烦Web 开发里最头疼的状态一致性问题——实时协作、聊天、AI Agent 的 UI、长事务、多人操作、乐观更新和缓存失效。Convex 把这些抽象成了一个 State Sync Engine，让开发者只关注逻辑，不用管同步细节。为什么现在突然火了AI Agent 本质是长生命周期的状态机，天然需要持久化状态、多步骤推理、实时变化、UI 联动、乐观执行、记忆管理、事件流和人机协同。Convex 已经从 Web App 后端演化成 Agent-native Backend，官网甚至直接叫它"Agent 构建模块”。架构简述前端 → 响应式 SDK → Sync Engine → Convex Runtime → 数据库 + 函数执行。核心是 Sync Engine：数据库采用文档关系模型，支持强事务和依赖追踪，能自动识别查询间的数据依赖。函数运行环境是 TypeScript 原生、Serverless、强一致性，内置响应式查询追踪。Sync Engine 自动处理 WebSocket 连接、重连、订阅、diff 同步、缓存失效、乐观更新与重试，维护一个稳定的 Client State Graph。和竞品比怎么样比 Firebase 进一步。Firebase 只做数据同步（DB → Client），Convex 做的是状态同步（Function → Query Graph → State）。它有事务优先级、查询图，以及确定性的同步与执行模式。可以说是“适用于后端状态的 React"。比 Supabase 更“危险”。Supabase 竞争的是 SQL 与 Postgres 生态；Convex 竞争的是 Reactive Application State 层，而这正是 AI Agent 时代的关键——它是一个持续运行的状态系统。缺点Vendor lock-in 很强，数据迁移成本高。尽管代码已开源，商业层面的绑定仍然存在。查询模型不适用于复杂 BI、OLAP 以及对 SQL 依赖较重的大型企业场景。它在 infra 演进中的位置传统链路是“数据库 → API → 前端”，Convex 将其转换为"State Runtime → Agent → UI"。它处于 Agent Runtime（L3.5 层级），已接近 Agent OS 的雏形，但尚缺完整的编排、记忆层级、语义状态管理与长周期规划能力。为什么值得关注Convex 将“同步”提升为基础设施的一等公民。Agent 系统的核心瓶颈，正从模型推理转向状态一致性——包括记忆管理、上下文维护、工作流协调、多 Agent 协作、人机协同以及长时执行。Convex 恰好踩中了这一方向。