Sluke的夹生饭 - ai
type: channel
link: https://www.luweiqing.com/tag/ai/
items: AI Infra：Token 价格博弈策略分析
items: AI Infra：市场缺少 Token 运维服务（Token Runtime Platform）
items: AI Infra：解构 DSpark，Speculative Decoding 的三层逻辑
items: AI Infra：企业 Token 精炼厂是企业 AI 落地的下一阶段
items: AI Infra：Token 工厂的商业模式研究
items: Databricks Genie 战略解读：从数据平台到上下文平台的跃迁
items: AgentMesh：“Agent 虚拟组网 + 能力结算”的基础设施产品
items: AI 存储的真正机会在推理，但训练远未到天花板
items: AI Infra：Tacnode，面向 AI Agent 与实时自动化决策系统的 Context Lake
items: AI Infra：Convex Backend数据库，AI Agent 时代的状态同步方案

AI Infra：Token 价格博弈策略分析
type: item
date: 2026-08-27T18:02:55+08:00
description: 模型更新快。价格难看懂。有的厂商把 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。通用低端更像自来水。前沿高端更像专家时间。企业保障更接近保险和专线服务。三类产品使用同…

AI Infra：市场缺少 Token 运维服务（Token Runtime Platform）
type: item
date: 2026-06-30T10:53:24+08:00
description: 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 的三层逻辑
type: item
date: 2026-06-29T11:36:00+08:00
description: 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 Infra：企业 Token 精炼厂是企业 AI 落地的下一阶段
type: item
date: 2026-06-27T16:55:42+08:00
description: 从模型军备竞赛到业务语义战争过去两年，企业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（…

AI Infra：Token 工厂的商业模式研究
type: item
date: 2026-06-26T17:30:09+08:00
description: 别再叫它 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（Tok…

Databricks Genie 战略解读：从数据平台到上下文平台的跃迁
type: item
date: 2026-06-24T18:58:22+08:00
description: 核心观点：企业 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第四代Ag…

AgentMesh：“Agent 虚拟组网 + 能力结算”的基础设施产品
type: item
date: 2026-06-23T21:19:00+08:00
description: 一、项目背景与执行摘要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 最小…

AI 存储的真正机会在推理，但训练远未到天花板
type: item
date: 2026-06-22T17:20:00+08:00
description: 在投资视角下，仅关注存储总容量的增长远远不够。决定企业价值的核心，是存储被用于何处。下表清晰对比了各存储层级在容量与市场价值上的错配。层级存储容量占比市场价值占比增长驱动力训练存储高中模型训练与后训练推理存储中高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 则立足于归档层。未来十年最值得关注的无疑是推理存储市场，但训练存储同样不容忽视。后训练带来的数据高频迭代、多版本管理以及跨企业数据…

AI Infra：Tacnode，面向 AI Agent 与实时自动化决策系统的 Context Lake
type: item
date: 2026-05-24T19:45:52+08:00
description: 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 时代的状态同步方案
type: item
date: 2026-05-17T20:42:01+08:00
description: 以前做实时应用，得自己拼数据库、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 恰好踩中了这一方向。