Token 工厂：AI 时代最热门的生态，创业者该站在哪个位置？
当一台数据中心不再被当作"存储电力和芯片的仓库"，而被当作一条"把电力冶炼成智能的产线"，整个 AI 产业的商业逻辑就被重写了一遍。这篇文章想回答一个问题：在这条产线周围，一个三五个人的团队，到底该站在哪个位置才能启动自己的飞轮。一、先说清楚：什么是"Token 工厂"过去我们理解数据中心，习惯用两个词：算力、存储。你交电费、买显卡、租机柜，本质是在囤积一堆能算数的铁疙瘩。但 2026 年前后，一种新的说法开始成为主流叙事——数据中心不再是存储中心，而是 Token 工厂。这个转变听起来只是换了个名字，实际上换了一整套记账方式。在固定的电力包络下，一座 AI 工厂把电力、芯片、网络、冷却、模型和调度系统，工业化地转化成一个个 token（词元），再以 token 为计量单位，把"智能"卖出去。换句话说，输入是电、卡、网、数据、模型；输出不再是"算力小时"，而是 token，以及 token 之上的 Agent、决策和业务结果。这套逻辑一旦成立，工厂老板关心的 KPI 就完全变了。他不再问"我有多少张卡"，而是问四个更锋利的问题：每秒能吐多少 token（吞吐）？每一度电能榨出多少 token（能效）？每个 token 的成本是多少（单价）？产线的利用率和可用性有多高？有芯片厂商甚至把这件事说得更直白：在 AI 工厂时代，"每瓦每秒产出的 token 数"几乎直接等价于收入。这句话值得每个想进入这个赛道的人抄在笔记本第一页。而且 token 本身开始"分级"，像工业品一样被商品化：面向 C 端轻量场景的消费级 token，往往免费或低价引流；嵌进金融风控、工业质检这类刚需场景的专业级 token，能卖出溢价；用于高复杂推理、科研突破的前沿级 token，则是最贵的那一档。定价维度也从单纯的"快不快"，扩展到智能密度、上下文长度、响应时延、合规与可靠性等级。一句话总结：Token 工厂的本质，是在电力约束下，把训练成果和推理基础设施抽象成一条 token 产线，再按分层定价把智能按需卖出去。理解了这个底座，我们才能谈生态，谈创业。二、把复杂生态讲简单：三侧市场任何一个成熟的产业，最终都会分化出清晰的分工。Token 工厂生态也一样。与其画一张让人眼花的产业链长图，不如用一个更好记的框架：三侧市场。第一侧，生产侧（Token Producers）。 目标只有一个——更便宜、更稳定、更高性能地生产 token。这里住着 GPU 云、训练工厂、推理引擎、调度系统。他们卷的是成本优势、性能优势和供给稳定性。这一侧最重、最烧钱，也最像"重工业"。第二侧，渠道侧（Token Distributors）。 这一侧最容易被忽略，却可能是整个生态里最有意思的位置。它负责把 token 能力包装、分发、销售、嵌入到具体场景里——开发者生态、Marketplace、账户体系、增长通道都在这里。它回答的是一个关键问题：谁把 token 能力，变成了可购买、可使用、可信任、可传播的产品？第三侧，消费侧（Token Consumers）。 token 在真实业务、真实应用、真实 Agent 场景里被消耗掉。企业的 Copilot、客服、风控、代码生成，都在这一侧烧 token。它追求的是真实场景、高频使用、高留存、高消耗。为什么一定要把"渠道侧"单独拎出来，而不是简单粗暴地分成"生产"和"消费"两端？因为在互联网的历史里，控制渠道的人，往往比控制生产的人活得更好。生产侧拼的是规模经济，渠道侧拼的是网络效应。前者越做越便宜，后者越做越离不开。App Store 不生产 App，却定义了整个移动应用的分发规则；这就是渠道的力量。对一个创业团队来说，这个框架的价值在于：它帮你排除掉两个几乎不可能的选项，聚焦到那个真正可行的位置。生产侧太重，不适合小团队起步；消费侧容易掉进"做项目"的陷阱，一个客户一个交付，长不成平台。唯一适合小团队做楔子（wedge）的，是渠道侧。三、两个引擎：Token 工厂的双飞轮如果说三侧市场解释的是"生态里有哪些参与者"，那么双飞轮解释的是"这个生态靠什么转起来"。Token 工厂真正的护城河，不来自单点的模型能力，而来自两个相互耦合、彼此强化的飞轮。飞轮一：生产飞轮，创造价格空间这个飞轮的唯一核心变量，是 Cost per Token（单位 token 成本）。它的转动逻辑是一条自我强化的链条：更好的推理引擎，带来更高的每瓦 token 产出；成本随之下降；成本下降释放出利润空间；利润空间允许你降价；降价吸引更多业务进来；业务规模扩大提高了利用率；利用率提升又进一步摊薄成本……于是成本继续下降。GPU、KV 缓存、推理调度、Prefill/Decode 分离——所有这些眼花缭乱的技术名词，其实都在为同一个目标服务：让每一个 token 更便宜。生产飞轮最终沉淀下来的资产，是成本优势。它对应的是规模经济。飞轮二：流通飞轮，创造需求空间很多人以为这个飞轮的核心是"token 消耗量"。这是一个常见的误判。Token 消耗是结果，不是资产。今天你平台上跑了 100 亿 token，明天用户迁移到别的平台，这 100 亿就归零了。真正能沉淀下来、别人搬不走的，是另一样东西——活跃的高价值消费主体本身。因为开发者会离开，Agent 可以迁移，Marketplace 可以被复制，但如果这个消费主体的身份、信用、余额、收益、邀请关系、历史数据都留在你的平台上，那么 token 消耗自己会回来。所以流通飞轮的核心变量，不是消耗量，而是持续产生消费的经济主体。它转动的逻辑是：更多高价值消费者进来，开发更多 Agent，产生更多业务，消耗更多 token，获得更多收益，收益又转化成更多权益，权益吸引更多消费者……流通飞轮沉淀下来的资产，是消费者网络。它对应的是网络效应。两个飞轮如何咬合这才是整个商业模式最漂亮的一层。生产飞轮降低 token 成本，释放价格空间；价格空间降低了整个生态的进入门槛，推动流通飞轮增长。流通飞轮扩大 token 消费和收入规模，反过来给生产飞轮提供更多资金、数据和规模，让成本进一步下降。一句话概括：生产飞轮创造价格空间，流通飞轮创造需求空间。 一边是供给侧效率，一边是需求侧流量。当两个飞轮真正咬合，平台就同时握住了规模经济和网络效应两种几乎无法复制的优势。四、创业者的拷问：到底该站哪？框架讲完了，最难的问题来了：一个三五个人、半年到一年要做出东西的团队，究竟从哪个节点切入？这个问题的答案，不是被"选"出来的，而是被连续否决逼出来的。这也是整个思考过程里最有价值的部分——每一次否决，都排除掉一个看起来很美、实则会被巨头吞并或过重无法冷启动的候选。否决一：生产侧全栈。 自己建数据中心、买卡、做训练工厂？这是 NVIDIA 们的终局形态，不是创业公司的 MVP。直接排除。否决二：推理引擎。 做一个 vLLM 的替代品？技术门槛极高，且已有大量成熟开源方案在卷。红海，不建议。否决三：AI Gateway。 做一个统一的 API 入口、路由、鉴权、限流？听起来很性感，但这个赛道已经挤满了玩家。更致命的是，Gateway 解决的是"能不能调用"，它不会持续降低 token 成本，也无法建立真正的留存——用户不会因为一个 Gateway 而离不开你。否决四：Token Optimizer。 那做一个夹在应用和推理引擎之间的优化层呢？负责缓存、压缩、路由、重试，每一次请求都帮客户省 token。这个方向一度非常诱人，因为"每省一个 token，客户立刻能看到 ROI"。但这里有个致命的追问：推理引擎厂商会不会自己把这层做掉？答案是：会，而且一定会做一部分。凡是能提升"每秒 token 数"的能力——连续批处理、KV 缓存、前缀缓存、投机解码——都是推理引擎的核心 KPI，他们没有理由不做。所以如果 Token Optimizer 的定位只是"路由 + 缓存 + 重试"，那么它三年内会退化成推理引擎的一个配置项，没有独立的投资价值。那什么是推理引擎永远做不了的？答案藏在数据里。推理引擎只能看见它自己。它不知道：今天这家企业的预算还剩多少、这个请求来自哪个部门和业务线、调用方是不是 VIP、是生产流量还是测试流量、是否临近月末预算耗尽、要不要走审批。这些信息，统统不属于推理层。它们属于业务层。于是思路收敛出一个关键判断：真正值得做的，不是围绕 token 优化，而是围绕 Business Policy（业务策略） 的运行治理。推理引擎优化的是 Inference（推理），而创业公司真正该优化的是 Business Decision（业务决策）。两者根本不在一层。至此，剩下两个真正值得做的产品浮出水面。五、剩下的两个产品：一个造 Token，一个用 Token收敛到最后，整个战略只剩下两个旗舰产品。它们分别对应供给侧和需求侧，几乎没有重叠，却高度互补。供给侧：Business Token Runtime它不是 Gateway，也不是 Agent 框架，更像企业 AI 的控制平面。它的定位是：把企业的业务意图（Business Intent）转换成最优的执行计划（Execution Plan），并持续治理 token 在不同模型、不同供应商、不同 Agent 之间的生命周期。推理引擎的输入是 Prompt、输出是 Token；而它的输入是 Business Goal（业务目标）、输出是 Business Result（业务结果）。中间要跨越上下文、策略、工作流、审批、工具、Agent、模型、执行、评估——这一整条链路上的数据，推理引擎几乎一个都拿不到。这正是它无法被吞并的根本原因。它管理的不是显存和算子，而是六种"业务 token"：意图、上下文、策略、执行、记忆、价值。每一层都对应一个企业愿意掏钱的采购理由，也每一层都是推理引擎看不见、因而覆盖不了的位置。对小团队来说，它不该一上来就做完整平台——那样销售周期太长、交付太重。更现实的路径是先从业务策略治理这个最轻、最不需要改造客户业务系统的模块切入，直接解决企业"AI 花钱失控"的焦虑，再逐步向上下文、执行、学习几层扩展。需求侧：Passport这是整个流通飞轮的核心产品。很多人第一反应会把它理解成账号系统、会员体系或者钱包——这恰恰是最大的误解。Passport 不是身份系统（Identity System），它是关系管理系统。它管理的对象也不是传统意义上的"用户"，而是 Token Consumer：任何能够持续消费、分发、转化或放大 token 价值的主体。这个主体可以是开发者、企业、ISV，未来甚至 Agent 本身都会成为最大的消费者。它真正要回答的问题，不是"这个用户是谁"，而是"这个消费主体是否值得被长期经营？它能持续消耗多少 token？能带来多少生态价值？平台该如何激励、分发、结算和放大它？"顺着这个逻辑，Passport 沉淀的是五类会越来越值钱的资产：身份（知道是谁）、信用（是否可信）、能力（擅长什么）、经济（创造了多少价值）、关系（连接了谁）。这里有两个反直觉但极其重要的判断：第一，Passport 应该采用邀请制 + 付费制。 但这么做的目的不是制造稀缺，也不是赚那点会员费，而是控制生态质量。邀请制意味着更低的获客成本、更高的社区质量、更少的滥用和刷量，以及更强的开发者身份认同——就像 Linear、Superhuman、Cursor 早期做的那样。更妙的是，邀请码本质上是"消费者网络的边生成器"，它不只带来一个新用户，还带来关系、上下游和信任的传递。第二，Passport 不该卖会员，而该卖增长。 如果 Gold 版 Passport 只是"更多模型、更高额度"，那它就退化成了消费订阅。真正更大的机会是：Passport 卖的是曝光、更低手续费、更高收益分成、更多推广资源、更多企业客户、更靠前的 Marketplace 排序权重。这和 App Store、Shopify、GitHub Marketplace 的逻辑一致——生态参与者付费，不是为了"用更多功能"，而是为了"获得更多增长机会"。如果要用一句话概括这对产品的关系：Business Token Runtime 负责把 token 造好，Passport 负责把 token 用好。前者积累成本优势，后者积累网络效应。六、最后一跳：产品应该落在开发者的桌面上产品定义清楚了，还剩一个形态问题：Passport 到底长什么样？一个 Web 后台？这里发生了整个思考里的最后一次转向，也是最落地的一跳：Passport 不该是一个纯 Web Dashboard，它应该落在开发者的桌面上，成为一个 Developer / Agent Passport Gateway。为什么是桌面？因为桌面产品天然贴着开发者的工作流：它可以成为开发者每天打开的工具，而不是偶尔登录的后台。本地 API Key、本地项目、本地 Agent、本地 MCP Server，都更适合一个桌面入口来承载。它能观察到 Agent 从构建、测试、调用到发布的完整过程，沉淀别人拿不到的使用数据。Credits、Agent 资产、配置、收益信号都在这个 Gateway 里，账户锁定天然更强。需要说清楚边界：这个 Gateway 不是要去和 Cursor、VS Code、Claude 桌面端正面竞争。它不做代码编辑，也不做 IDE。它是站在它们旁边的经济与分发层——负责 token 账户、Agent 管理、Credits、分发、收益和推广。IDE 负责写代码，Gateway 负责把开发者的日常工作流，变成 token 流通的入口。一句话定位：Passport Gateway 是开发者和 Agent 进入 Token 经济的桌面入口。七、飞轮怎么转起来：冷启动与真正的难点产品想清楚了，最后一个问题是：第一批用户从哪来，飞轮怎么开始转？冷启动的最小闭环，大致是这样一条链路：先从上游拿到一批低价 token 或 Credits，邀请几十个 Agent Builder 进来，每人用 Gateway 创建一两个 Agent；平台帮他们做精选展示，推给一个明确的渠道或企业试用池；记录下 token 消耗和真实反馈，根据表现给优秀 Agent 更多 Credits 和推广资源——这就是最小的流通飞轮。但这里必须泼一盆冷水：这个产品最难的地方，从来不是写代码，而是资源编排。一个真正能转起来的最小生态，需要同时把四方拧在一起：上游为什么愿意给你低价 token？——因为你能带来它单独拿不到的增量消费。开发者为什么愿意加入你？——因为你能给他省钱，还能给第一批真实用户和曝光。渠道为什么配合你？——因为你能给它带来它想要的内容或流量。消费者为什么用这些 Agent？——因为它们真的解决了问题。这四个"为什么"里，任何一个断了，飞轮就转不起来。所以这类团队真正稀缺的能力，往往不是工程，而是开发者关系、BD、以及把运营做成可复制流程的能力。工程当然重要，但它不是瓶颈——这一点，恰恰和多数技术团队的直觉相反。早期还有一个务实建议：不要做"开放生态"，要做"策展生态"。别急着把大门敞开让所有人涌进来，而是精心挑选、亲手扶持第一批高质量的 Agent 和开发者。质量密度，在生态的冷启动阶段，比数量重要得多。八、几个必须正视的风险任何一个诱人的方向，都有它的暗礁。这个方向最该警惕的失效模式，几乎都指向同一个错误——把窄口做宽了。过早平台化。 还没验证核心假设，就急着搭"完整 Token Economy 平台"，摊子铺大，资源摊薄，哪一头都做不深。退化成普通 Auth。 Passport 一旦被做成登录 / SSO，就失去了它作为关系经营系统的全部价值。退化成积分钱包。 只做 Credits 充值消费，就变成了一个没有网络效应的记账工具。Marketplace 没有流动性。 供给和需求没有真正匹配起来，货架摆满了却没人买，生态就是死的。低质量消费污染指标。 靠补贴刷出来的消费量，会让北极星指标失真，误导整个团队的判断。最后一个风险尤其值得展开：衡量什么，你就会得到什么。 如果把注册用户数、DAU、总 token 消耗当北极星，团队就会去刷这些虚荣指标。更对的锚点，是"每月高价值消费者贡献的有效 token 经济价值"——只计入那些真正产生业务结果、带来转化、有复购和网络扩散的消费，剔除刷量、纯测试和补贴驱动却零留存的部分。衡量关系，而不只是用户；衡量有效消费，而不只是消耗总量。结语：不要先造工厂，先占入口回到最开始那个问题：在 Token 工厂这条产线周围，一个小团队该站在哪？答案已经清晰了。不要先去造 Token 工厂，也不要一头扎进企业项目里做交付。应该先做 Token 经济的入口账户，控制高价值消费者和 Agent Builder 的分发关系。具体路径是：从渠道侧的一个极窄楔子切入——一个落在开发者桌面上的 Developer / Agent Passport Gateway；先服务好开发者的身份、Credits、邀请、上架和收益，把最小流通飞轮转起来；再逐步向 Marketplace、企业和完整的 Token 经济 OS 扩展。生产飞轮拼的是成本，流通飞轮拼的是关系。前者是巨头的主场，后者才是小团队真正能建立复利的地方。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 的工作流编排，都可以归纳到这一套逻辑中，将业务流程中的“预测、验证、状态复用”构建为统一的优化模型。
Workspace里面存放着文档、代码、SQL、配置文件、日志和Git仓库。它的作用，是将这些文件组织起来，方便团队协作。对于Agent而言，Workspace不再只是一个文件系统，而是一个持续产生、提炼和沉积“上下文”（Context）的动态空间。每一次修改文档、执行SQL、调用工具、编写Prompt，乃至与Agent的每一轮对话，都会留下全新的语义信息。Agent真正需要理解的，不再是某一个孤立的文件，而是整个Workspace当前所表达的整体状态。因此，Workspace正在经历一场根本性的蜕变：从“文件仓库”演进为“Token提炼车间”。一、文件只是原材料一个成熟的Workspace，往往容纳着多种类型的数据：核心文档：PRD、设计文档、Roadmap数据结构：SQL、Schema、数据库定义行为规范：agent.md、CLAUDE.md思考方式：Prompt、Agent Conversation演进轨迹：Git Commit、Issue、TODO执行记录：Tool Call、CLI操作这些要素，过去是孤立的岛屿，而今在Agent的视野里，已接连成一片大陆。一份PRD向Agent阐明产品目标，一组SQL映射出业务模型，agent.md定义了工作规范，Prompt体现着思考方式，Git Commit记录了系统的演化过程，Agent Conversation则留存了每一项决策的原始依据。真正有价值的信息，不存在于任何一个独立的文件中，而存在于这些元素之间的关系之中。这些隐形的“关系”，正是Token的原始矿脉。Workspace真正生产的是Token很多人认为，大模型时代生产的是推理Token。但事实上，在企业内部，还存在着另一种价值更高的Token——它们并非模型凭空生成的文本，而是从真实的业务活动中提炼出来的语义单元。原始数据提炼后的Token产品文档产品目标、业务能力SQL业务实体、业务关系、核心指标Prompt思考模式、执行策略agent.md项目规范、团队约束Git Commit系统演化方向Agent对话决策过程Tool调用执行行为这些Token不描述文件本身，它们描述的是Workspace在某一时刻的 “运行状态”。例如，一条SQL：SELECT * FROM Orders WHERE status='Pending'数据库看到的是查询语句，而Agent更关心的是：企业高度关注“待处理订单”。“订单”是核心业务实体。当前业务架构围绕订单生命周期展开。这条SQL，就这样被“提炼”为了一个业务Token (Business Token)。同样，一个Prompt：先分析，再规划，最后执行。它不仅仅是提示词，更表达了一种认知模式：规划先行，执行后置，并且要具备反思能力。 这个Prompt，因此被提炼为一个认知Token (Cognitive Token)。Agent并非直接“阅读”文件，而是在“翻译”和“萃取”它们的语义精髓——也就是Token。Agent工作的实质，并非逐字阅读文件，而是在持续不断地“生产”Token。二、Workspace：持续运行的Token工厂如果将Workspace视为一条流水线，其工作流程会变得清晰可见：原料投入：文档、SQL、Prompt、对话、Git记录、日志等。语义解析：理解每种数据的结构和含义。Token萃取：从语义中提炼出关键信息单元。图谱构建：将Token连接形成关系网络。状态估算：基于关系网络，推断Workspace的当前状态。未来预测：根据演化轨迹，预测下一步可能的最佳行动。Workspace的每一次变动，都会催生新的Token。这些Token不断累积，最终形成一个动态的、自更新的语义图谱 (Semantic Graph)。Agent真正“理解”的是这张图谱，而非文件本身。正因如此，一个具备Token生产能力的Workspace，可以回答许多传统IDE无法企及的问题：洞悉这个项目真正的核心目标是什么。推演当前项目的实际进展阶段。理解团队采用特定架构的决策逻辑。识别哪些业务实体最为关键。预测哪些模块在未来最可能变更。建议下一步最应该优先完成什么。这些问题的答案，不存在于某个Markdown文件里，而存在于Token之间形成的那张复杂而精确的关系网络中。三、从Business Token到Cognitive Token这种能力不仅适用于企业。对于企业，Workspace提炼出的是业务Token (Business Token)。对于个人，Workspace提炼出的是认知Token (Cognitive Token)。一个人的Workspace同样包含着丰富的数据：笔记、浏览记录Prompt、Agent对话记录日历、Git仓库、邮件、文档经过语义提炼，系统可以恢复出他的：当前目标、关注方向知识结构与决策习惯长期偏好与未来计划例如，一个人连续阅读MCP、Claude Code和Agent Framework的文档，并不断修改相关的AI项目。系统不会仅仅记录下“浏览历史”这一条信息，它会进一步提炼生成一个更高级的Token：“正在寻找新的Agent开发工作流”。这背后是多个“文件”（MCP资料、Claude Code使用记录、Agent实践笔记）共同作用，最终“提炼”出的一个高级认知Token。因此，业务Token与认知Token并无本质区别。它们都是对特定“状态”的表达。企业描述的是业务状态，个人描述的是认知状态。四、Workspace：从记录历史到预测未来更大的价值，在于从“理解现在”迈向“预测未来”。当Workspace持续积累Token后，它便能恢复出整个项目的演化轨迹。例如，过去三十天内：新增了Prompt、SQL、Tool和API新增了测试用例模型通过分析团队长期的工作模式，便可以预测：下一步大概率需要：增加Memory模块、重构Workflow、引入新的Agent或优化业务模型。更进一步，它甚至能提前生成：下一版PRD的草案下一版SQL的框架下一个Prompt的优化方案下一次Agent协作的预演计划Workspace从此拥有了预测能力。它描述的不再只是“已经发生了什么”，还能够推断出“未来最可能发生什么”。五、Workspace，将成为AI时代最重要的生产设施传统软件时代，Workspace是代码管理工具。Copilot时代，Workspace是上下文来源。而在Agent时代，Workspace将成为Token的核心生产设施。未来的竞争，不再是谁拥有更多的文件，而是谁能持续地将文件、行为、思考、决策和协作过程，系统性地提炼为高价值的Token。对企业而言，这意味着构建起你的业务Token工厂 (Business Token Factory)。对个人而言，这意味着打造你的认知Token工厂 (Cognitive Token Factory)。当Workspace的使命从“保存文件”升级为“生产Token”，AI才真正开始有能力去理解你的项目，理解你的团队，最终，理解你自己。
从模型军备竞赛到业务语义战争过去两年，企业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 文件系统、对象归档。清晰的层次划分，也为存储初创企业标定了市场空间和估值天花板。
语言是思想的 KV Cache，使用人数和时间更长的语言，会有一些优势语言像 KV Cache 的地方维度语言KV Cache作用保存和传递上下文保存和复用推理上下文价值让思考可以连续累积让模型推理可以低成本延续特征用得越久，表达越稳定命中越高，推理越高效结果沉淀出更强的协作效率沉淀出更强的计算效率语言使用人数越多、使用时间越长，通常会形成三类优势：1. 语义约定更稳定长期使用会把大量含糊表达，压缩成更固定的含义。同一个词、一个缩写、一句行话，大家默认理解趋同，沟通成本下降。例如：场景效果商业条款、指标、分工更标准化技术概念、接口、术语更统一组织协作和交接更顺滑2. 语料和表达资产更厚使用人数越多，语言里的高质量文本、案例、模板、知识库就越多。这会带来一个累积效应：后来的使用者可以直接站在前人的表达之上，而不必从零开始。这和 KV Cache 的逻辑很像。前面已经生成和验证过的上下文，后面可以直接复用。这也是很多人认为中文成语是“压缩包”的原因。3. 网络效应更强语言不仅是交流工具，也是分发协议。谁掌握了更大的语言网络，谁就更容易获得内容、社区、教育、出版、软件生态的外溢优势。这会进一步带来：优势具体表现信息密度高更容易形成专业分工协作半径大更容易跨地域连接迁移成本高重新学习另一套语言体系成本更大4. 补充说明语言的优势不只是“人数多”和“时间长”，更关键是：条件说明统一程度高否则语义碎片化，复用困难书写体系成熟才能沉淀可检索、可传递的知识教育和制度支持才能把语言优势转成长期资产跨行业渗透深才能形成真正的上下文积累语言使用越广、沉淀越久，就越像一个高命中率的长期上下文缓存。它会同时提升沟通效率、知识复用效率和组织协同效率。