从 LLM API 的“无状态”原罪，看懂 Chatbot 到 Agent 的 AI 产品范式变迁与未来

yan5xu2025年09月01日约 19 分钟

当 OpenAI 在 2020 年 6 月发布 text-completion 接口时，人们还没预料到，这个简单的 API 会为两年后一款彻底改变世界的应用，铺平了道路。

那时的它，功能纯粹而直接：输入一段文本，模型续写下一段。它的工作方式类似一台智能打字机，核心任务是“补全”。

LLM 的推理接口，成为了后续所有 AI 应用的“基座”。要理解 AI 产品的范式变迁，预判其未来，我们必须回到这个起点，审视这个“基础模块”本身的设计、演化，以及它给整个生态带来的根本性约束。我将以 Prompt Cache 这一技术为线索，剖析从 Chatbot 到 Agent 的产品范式演进史，并揭示一个普遍存在于应用层的核心问题——一个由 API “无状态”特性所引发的“架构错配”。

序章：API 的黎明 —— 从“打字机”到“Chatbot”

第一幕：蛮荒时代的“打字机” (`text-completion`)

text-completion 奠定了大模型交互的底层范式：万物皆为文本补全。无论是后来的结构化对话，还是复杂的工具调用，在模型计算前，它们都会被处理成一个线性的文本序列，等待模型“续写”下一个词元（Token）。这个认知，是理解 LLM 所有行为和约束的基础。

curl https://api.openai.com/v1/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_OPENAI_API_KEY" \
  -d '{
    "model": "text-davinci-002",
    "prompt": "请用中文解释一下什么是‘贴现现金流’（Discounted Cash Flow, DCF）：\n\n",
    "max_tokens": 150,
    "temperature": 0.5
  }'

响应示例:
贴现现金流是一种公司估值方法，它通过预测公司未来将产生的自由现金流，并使用一个折现率将其折算回现值，从而估算出公司的内在价值。这个方法的核心思想是，公司今天的价值，等于其未来所有现金流的总和……

正是基于这种简单而强大的交互模式，催生了第一波 AI 应用。其中最知名的代表之一，就是营销文案公司 Jasper（当时名为 Jarvis）。它通过提供一系列精心设计的模板和表单，将复杂的 Prompt 工程封装在清爽的 UI 之下，让用户能够高效生成博客文章、社交媒体文案等内容，迅速证明了生成式 AI 巨大的商业潜力。

在 2022 年 10 月，它得到了市场顶格验证，由顶级风投 Insight Partners 领投，以 15 亿美元的估值完成了 1.25 亿美元的融资。此刻，text-completion 范式走上了它的巅峰。

第二幕：对话时代的“Chatbot” (`chat-completion`)

其兴也勃焉，其亡也忽焉。就在 Jasper 融资完成的同时，OpenAI 的高层为了抢占 Chatbot 的先机，暂时搁置了正在路上的 GPT-4，临时调整方向在 GPT-3 的基础上开发一款名为 "Chat with GPT-3.5" 的产品。13 天后，ChatGPT 以研究预览版的姿态上线，迅速展现出世界级的影响力：仅用了约两个月时间，就吸引了 1 亿月度活跃用户，成为历史上用户增长最快的消费级应用（这一纪录在 2025 年初被 Deepseek 打破）。

全世界突然意识到，原来对话才是 LLM 智能最好的表现形态。

市场的需求，倒逼着 API 本身的进化。2023 年 3 月 1 日，OpenAI 正式推出了搭载 gpt-3.5-turbo 模型的 chat-completion API。它通过引入结构化的角色格式，极大地简化了对话的管理，和应用构建门槛，实质上将“构建一个 Jasper”的技术门槛，从一个复杂的工程挑战，拉低到了任何一个普通开发者都能完成的水平。这对以 Jasper 为代表的一批早期 AI 产品造成了颠覆性冲击。

然而，在这层封装之下，一个根本性的事实并未改变：chat-completion API 本质上是一个 “语法糖” (Syntactic Sugar)。它帮助开发者更好地组织输入，但其底层逻辑依然是“文本补全”。更重要的是，API 本身是无状态 (Stateless) 的。

每一次调用都是一次独立的计算，API 不会“记住”之前的交互。这种特性，给用户带来了一种普遍的体感——AI 仿佛有 “金鱼记忆”。这种“健忘”并非模型的能力问题，而是其运行的规则所决定的。为了维系对话的连续性，开发者必须在每一次请求中，重新发送全部的历史对话记录。

当对话简短时，这不成问题。但随着对话轮次增多，或是在 Agent 需要多步推理的场景下，重复发送全部历史记录的方式，在成本和延迟上，迅速成为一个难以忽视的瓶颈。

正是在这个背景下，一个旨在优化重复计算效率的技术，登上了历史舞台，并将在未来深刻地影响整个 AI 产品的技术选型和架构设计。

它正是 Prompt Cache。

第一章：分道扬镳 —— “Chatbot”与“知识库问答”的时代

Prompt Cache 的登场，并未带来一个大一统的技术标准。相反，它几乎立刻沿着当时 AI 应用最主要的两条脉络——Chatbot 与知识库问答——分化出了两种截然不同的 API 设计哲学和实现路径。这背后，是两种产品范式及其交互本质的深刻差异。

路线一：为“连续对话”而生的无状态 API (Stateless API)

以 OpenAI 的 ChatGPT 为旗帜，Chatbot 确立了 AI 应用的第一个主流范式。其核心交互模式，可以被定义为 “连续对话” (Continuous Dialogue)。在这种模式下，上下文信息是流式、增量的，每一轮新的对话都必须建立在之前所有历史的基础上。

为了服务这种交互，一条由 OpenAI、DeepSeek 等厂商所引领的技术路线逐渐清晰：坚持 无状态 API (Stateless API) 的设计，并将缓存优化完全置于后端。

在它们的 chat-completion 接口中，API 本身不保存任何会话状态。开发者有责任在每一次请求中，重新发送增长的、完整的对话历史。这种设计的表面之下，是服务端推理引擎的极致优化。其后台普遍采用 KV Cache 技术，对传入 Prompt 的相同前缀 (identical prefix) 部分进行缓存。当引擎检测到一个长 Prompt 的前缀与上一次请求完全一致时，它会跳过对这部分的重复计算，从而大幅提升效率。诸如 vLLM 项目中的 PagedAttention 等开源技术，正是这类优化的杰出代表，它使得管理和复用 KV Cache 变得空前高效。

这种模式，就是 “隐式缓存” (Implicit Caching)。对开发者而言，缓存是透明的、自动的，API 接口保持了无状态的简洁性。这是一种典型的体验优先设计，完美服务于构建流畅、无缝的“连续对话”这一核心产品诉求。

路线二：为“反复提问”而生的显式缓存 (Explicit Cache)

与此同时，在企业服务和深度应用领域，以知识库问答为代表的第二种范式也正在崛起。其典型场景是，用户上传一份冗长的文档——一份财报、一部法典、一篇学术论文——然后围绕这份固定内容，从不同角度进行多次、非连续的 “反复提问” (Repeated Querying)。

在这种模式下，超长文档是固定的“背景知识”，而用户的每次提问都是一次独立的、针对该背景的“探查”。如果每次都重传原文，成本将无法接受。

为这种需求，以 Google 的 Gemini API 和国内的 Kimi (Moonshot AI) 为代表，选择了另一条道路：显式缓存(Explicit Cache)。

Google 在其 Gemini API 中正式提供了 Caching Service，允许开发者创建一个名为 CachedContent 的对象。开发者可以先将长篇文档（如 RAG 检索结果）存入其中，并获得一个唯一的名称作为句柄。在后续的无数次查询中，开发者只需传递这个简短的句柄和新的问题即可。Kimi 的平台也提供了类似的机制来高效处理其引以为傲的长上下文窗口。

这是一种将上下文 “资产化管理” (Asset Management) 的思想。它在 API 层面就赋予了“状态”一个明确的身份，视长文本为一种可被持久化、可被反复调用的“知识资产”，赋予开发者在处理超长上下文时前所未有的灵活性和经济性。

小结

至此，行业格局初定。两大产品范式催生了两条泾渭分明的技术路线：

• Chatbot 的“连续对话”需求，由 OpenAI 和 DeepSeek 所代表的 “无状态 API + 隐式缓存” 路线来满足。
• 知识库问答的“反复提问”需求，由 Google 和 Kimi 所代表的 “显式缓存” 路线来支持。

技术路线的分野，清晰地印证了：技术的选择，最终服务于产品的交互范式。

然而，这场看似稳定的双雄对峙，很快就被一个全新的物种所打破。它的出现，将彻底改变 Prompt 的结构，并对现有的缓存机制提出颠覆性的挑战。

第二章：范式再转移 —— Agent 带来的性能挑战与架构演进

这个打破了原有技术路线平衡的全新物种，就是 AI Agent。

它的出现，标志着 AI 应用的第二次范式转移。如果说 Chatbot 的核心是“交谈”，那么 Agent 的核心则是“行动”。这场深刻的变革，体现在两大核心特征之上：

首先，是 Prompt 结构的系统化。 Agent 的 Prompt 不再是简单的线性对话历史，而演变成一个更加复杂和庞大的三段式结构：

1. 静态前缀 (Static Prefix)：包括定义 Agent 身份与目标的系统指令 (System Prompt)，以及描述其可用 API 的工具定义 (Tool Definitions)。
2. 动态后缀 (Dynamic Suffix)：包括其推理过程（思考链, Chain of Thought）和调用工具的记录（行动历史, Action History）。

其次，交互模式转为异步。 Chatbot 的交互是由人类驱动的同步 (Synchronous) 过程，问一句，AI 答一句。而 Agent 则开启了一种 与人类解耦的、异步 (Asynchronous) 的执行模式。用户设定目标后，Agent 便进入一个自驱动的 “Agentic Loop” 中，在后台连续不断地、没有人类停顿地进行背靠背调用，直至任务完成。

这种 “Prompt 尺寸膨胀” 与 “高频连续调用” 的双重压力叠加，使得 Prompt Cache 的角色发生了质变：它从一个“锦上添花”的优化项，一跃成为决定 Agent 性能与成本的“生命线”。 在没有高效缓存机制的情况下，Agent 完成任务的累积延迟和 Token 消耗将变得无法接受，使其在商业应用中彻底失去可行性。

面对这一全新的、严苛的性能要求，原有的两大技术路线受到了严峻的考验，并催生出了第三种更具适应性的方案。

新需求下的技术选型：三种缓存策略的适应性分析

路线一：隐式缓存 (Implicit Caching) —— 自动前缀匹配的天然优势

以 OpenAI 和 DeepSeek 为代表的“无状态 API + 隐式缓存”路线，与 Agent 范式表现出良好的兼容性。其核心优势在于，推理引擎能够自动缓存任何完全相同的前缀 (identical prefix)。这不仅包括 Agent 庞大的静态部分（系统指令+工具定义），也自然地覆盖了不断增长的动态历史。也就是说，在 Agentic Loop 的第 N 步，服务端能完全复用第 N-1 步的全部计算成果，只处理最后新增的增量部分。这种“开箱即用”的可靠性，使其成为当前构建 Agent 的主流选择之一。

路线二：显式缓存 (Explicit Caching) —— 工作流错配与冗余计算

然而，以 Google 的 CachedContent 为代表的显式缓存路线，却在 Agent 场景中遭遇了“水土不服”。其核心症结在于一个致命的工程悖论：

让我们审视 Agentic Loop 的真实流程：在第 N 轮请求中，开发者需要将第 N-1 轮模型的输出（即 Assistant 的回答或思考）作为历史，加入到新的 Prompt 中。这部分刚刚生成的输出，其 KV Cache 在上一轮的计算中其实已经被预热（prefilled）过了。但为了使用显式缓存，开发者无法直接利用这个“热”状态。他必须发起一次全新的 API 调用，来创建一个包含了这部分新历史的、全新的缓存资产。

这个额外的创建步骤，强制服务端对刚刚才生成、计算过的内容，进行了一次完全冗余的 prefill 处理。这等同于为了使用缓存，开发者反而要付出额外的时间和计算成本。这种在工作流层面的根本性错配，使其在 Agent 这种高度动态的场景中，几乎不具备可用性。

路线三：开发者引导的缓存 (Developer-Guided Caching) —— 兼具控制与效率的混合范式

正是在这种背景下，一种更精妙的、介于两者之间的方案应运而生，其代表就是 Anthropic 的 cache_control 机制。

根据 Anthropic 的官方文档，其工作方式并非简单的自动检测，而是赋予了开发者一种极为精准的控制能力。开发者可以在 Prompt 的任何内容块（无论是 system 消息还是 messages 中的条目）中，插入一个 cache_control 对象。这个对象就像一个 “缓存断点” (caching breakpoint)。

当 API 收到带有此断点的请求时，它会缓存从 Prompt 开始一直到包含这个断点在内的所有内容。

这个机制的设计，堪称是为复杂 Prompt 场景的“量身定做”。对于 Agent 而言，开发者可以将这个断点策略性地放置在庞大且不变的静态前缀的末尾——例如，放在包含所有工具定义的 tools 数组之后，或包含详细背景设定的 system 消息的最后一个文本块中。

这样一来，开发者就实现了一种完美平衡：

• 相比隐式缓存，它提供了绝对的可预测性。开发者明确知道缓存的边界在哪里，无需猜测服务端的“黑盒”行为，这对于构建稳定、可复现的复杂系统至关重要。
• 相比显式缓存，它没有任何手动管理句柄的负担，也彻底规避了“冗余计算”的性能陷阱，因为缓存的创建和使用是在同一次 API 调用中原子化地 (atomically) 完成的。

可以说，这种开发者引导的缓存机制，是当前在 API 层面，最契合 Agent 产品范式的工程方案。

结论：新范式呼唤新架构

Agent 的降临，如同一场猛烈的风暴。它没有简单地让天平倒向某一方，而是彻底解构了原有的二元对立格局，催生出一个由隐式、引导式、显式构成的，更加多元和复杂的缓存技术光谱。

Anthropic 的方案虽然在当前看来更胜一筹，但它仍是一种在现有 API 框架下的“精装修”。无论是哪种缓存策略，它们本质上都还是一种“补丁”，是为了绕过一个更深层次的、源自模型底层的根本性约束。

而这个约束，正是我们接下来要深入剖析的“架构错配”的根源。

第三章：从必然的妥协，到架构的错配

要理解我们今天面临的困境，必须先理解我们是如何走到这里的。AI 应用的架构，并非一成不变，而是由两个相互作用的层面——推理层与应用层——在不同历史阶段的共同演化所塑造的。

第一阶段：推理层驱动的“无状态”时代

在故事的开篇，所有的焦点都集中在推理层。核心挑战是：如何将实验室里庞大、昂贵的自回归模型，转化为一个能被全球开发者稳定调用的公共服务？

在模型 Autoregressive（自回归）这一根本约束下，叠加着实现全球化、高并发、经济可行的工程目标，推理层的架构师们做出了当时唯一正确且必要的选择：设计无状态 API。

这个选择，是一次清醒而成功的妥协。它极大地简化了服务的扩展性，让任何请求都能被算力池中的任意一台机器处理。而对于当时主流的应用层——以 Chatbot 和知识库问答为代表的“浅层应用”——这个架构是完全够用的。

开发者在应用层手动管理对话历史，而推理层则通过 Prompt Cache 这一后端优化，巧妙地缓解了重复计算的痛点。在这个阶段，两层之间达成了一种和谐：推理层提供了稳定、可扩展的“计算引擎”，应用层则在其上进行封装和创造。一切看起来都很完美。

第二阶段：应用层崛起，矛盾开始浮现

然而，技术的演进，正在悄然改变两层之间的关系。

随着模型能力本身逐渐进入平台期，创新的重心开始不可逆转地从推理层向应用层转移。行业关注的焦点，从“模型能做什么”变成了“我们能用模型构建什么”。

正是在这个背景下，以 Agent 为代表的“深度应用”登上了历史舞台。Agent 的核心，是复杂的、多步骤的、需要长期记忆的任务流。它对“状态”的需求，不再是 Chatbot 那样线性的、短暂的对话历史，而是结构化的、持久的、可被灵活调用的复杂记忆。

此刻，昔日的和谐被打破了。应用层对状态管理提出了前所未有的、苛刻的要求，而推理层提供的，依然是那个为上一代应用设计的“无状态”接口。

更关键的是，应用层对 Prompt Cache 带来的速度和成本优势产生了路径依赖。对于 Agent 这种动辄数十步调用的场景，能否命中缓存，是决定其性能生死的关键。这种依赖，迫使开发者不得不围绕这个“非承诺”的特性，构建起一套复杂而脆弱的应用层补丁。

为了最大限度地压榨缓存效率，开发者必须在自己的代码里进行“特殊管理”：

• Prompt 结构固化：开发者必须像外科手术般，精确地将 Prompt 拆分为“永不变化的前缀”和“动态变化的后缀”。系统指令、工具定义的顺序、乃至其中的每一个空格，都必须保持字节级的绝对一致。任何微小的、意外的改动，都可能导致缓存瞬间失效，性能雪崩。
• 避免动态信息注入：一些看似合理的操作，比如在 System Prompt 中动态加入当前时间或用户信息，都可能成为缓存的“毒药”，开发者必须克制这种冲动，或者用更复杂的逻辑将其后置。

这正是我们所说的 “心智负担” (Mental Overhead)。开发者被迫将大量精力，从设计核心业务逻辑，转移到迁就一个底层“黑盒”的运行机制上。这是一种典型的 “泄露抽象”（ leaky abstraction），推理层的实现细节，反向渗透并扭曲了应用层的架构设计。

诊断：从妥协到错配

至此，我们便能清晰地诊断出问题的本质：

一个为早期应用设计的、成功的架构妥协，随着应用层的进化，已经演变成了一个阻碍未来的架构错配。

应用层的开发者们，正戴着“无状态 API”这副镣铐，艰难地进行着我们所说的 “状态模拟” ——这不再仅仅是一种聪明的“工程变通”，而逐渐成为了一种沉重的、限制性的负担。

推理层与应用层，这两个曾经紧密协作的伙伴，它们的发展步调开始失调。应用层已经进入到下个阶段，而推理层的基础设施，还停留在过去。

弥合这条日益扩大的裂谷，不再是应用层单方面的修修补补所能完成的。它等待着一场源自底层的、对推理层本身的变革。

第四章：未来的范式 —— 推理层与应用层的深度耦合

面对上述架构错配，可以从两个层面探索解决方案：一是挖掘现有范式的潜力，二是从根本上改变推理层与应用层的关系。

第一：现有范式的潜力 —— “上下文微调”

我们重新审视显式缓存。它的实际价值所达成的效果，可以被描述为一种 “上下文微调” (Contextual Fine-Tuning)：利用显式缓存，将详尽的、结构化的指令集或规则库一次性注入模型，使其在缓存的生命周期内，其行为表现在专业性和稳定性上，都接近一个经过专门微调的模型。

与隐式缓存那种短暂的、“非承诺”的特性不同，显式缓存创建的是一个可被主动管理的、持久化的“知识资产”。这种模式尤其适合 工作流 (Workflow) 类型的 AI 产品。

让我们以一个“AI 金融分析师”的工作流为例，其核心节点是“执行贴现现金流估值”。要让 AI 可靠地执行此任务，需要遵循的“方法论文档”可能长达 100,000 Token。

• 传统 API 模式：每次调用，都必须重复处理这 100k Token 的“方法论”。由于隐式缓存可能被回收，开发者需要反复支付成本和 “冷启动”带来的额外延迟。
• 显式缓存模式：一次性处理这 100k Token 的“方法论”并将其存为缓存资产。后续所有调用都可以直接复用这个结果，确保了可预测的低延迟，并将这部分成本摊销到几乎为零。

这不仅仅是成本优化，而是用 Prompting 的灵活性，实现了接近 Fine-Tuning 的专业性与性能稳定性，改变了 AI 应用的成本结构和能力边界。

第二：未来范式的探索 —— 从“原生状态”到“深度耦合”

然而，“上下文微调”所创建的缓存，仍是固定的。一个更理想的方向是：让推理层自身支持模块化、可组合的状态管理，正如 LMCache 及其 CacheBlend 等研究所探索的那样。

这种能力究竟解决了什么问题？让我们设想一个更复杂的 Agent 场景。

一个“全能项目助理” Agent，需要在一场对话中动态切换角色和能力。对话开始时，它的角色是 “代码评审工程师”。

• Prompt 结构：[角色 A: 代码评审指令] + [工具 A: Linter, Git Blame] + [对话历史]

用户在得到代码反馈后，紧接着说：“很好，现在请基于这些修改，切换到 ‘技术文档撰写者’ 的角色，帮我起草一份设计文档。”

• 新的 Prompt 结构：[角色 B: 文档撰写指令] + [工具 B: 制图工具] + [同样的对话历史]

在现有的缓存体系下，这是一场灾难。因为 Prompt 的前缀（角色和工具定义）发生了根本性改变，从 [角色 A + 工具 A] 变成了 [角色 B + 工具 B]。这导致整个缓存失效，推理引擎必须从头开始，重新计算包括冗长的 [对话历史] 在内的全部内容。

而 CacheBlend 这样的模块化缓存，则从根本上解决了这个问题。开发者可以预先将不同的模块分别缓存：

• 缓存块 1: [角色 A: 代码评审指令] + [工具 A]
• 缓存块 2: [角色 B: 文档撰写指令] + [工具 B]
• 缓存块 3: [对话历史] (动态增长)

当角色切换发生时，CacheBlend 的核心机制——注意力融合 (Attention Blending)——开始发挥作用。它并非简单地拼接数据块，而是在生成下一个词元时，通过修改注意力计算的逻辑，允许模型同时从多个、非连续的缓存块中汲取上下文。

换言之，在生成新内容时，模型可以同时“看到”并利用 [对话历史] 的缓存（缓存块 3），以及新换上的 [角色 B + 工具 B] 的缓存（缓存块 2），而无需将它们合并成一个连续的序列再进行昂贵的重新计算。推理层在硬件层面实现了对不同上下文来源的动态融合，这是一种原生的能力。

这正是我们所说的深度耦合。应用层的逻辑（切换角色），直接转化为了推理层的原生操作（动态融合缓存）。这种能力，是任何应用层“补丁”都无法企及的。

这个变革的前提，是高性能开源模型的成熟。随着以 DeepSeek-V3.1、OpenAI 的 GPT-OSS 系列、以及 Moonshot 的 Kimi-K2 为代表的新一代开源模型，在性能上追平甚至超过部分闭源模型时，定制推理层的可能性，首次从模型供应商下放到了应用开发者手中。

所以下一代真正的 AI 原生应用，将不会诞生于对通用 API 的封装之上，而是会被协同设计出来：产品需求将反向定义推理层架构。而对推理层的深度改造，本身就构成了应用最核心的技术壁垒。

结语：跨越裂谷，迎接真正的 AI 原生时代

我们从一个简单的 API 出发，回顾了 AI 应用从“文本补全”到“Chatbot”，再到“Agent”的范式变迁。从中我们得出了核心诊断：应用层的快速进化与推理层固有的“无状态”设计之间，已经形成了一道深刻的架构“错配”裂谷。

过去，开发者只能在这道裂谷上，通过手动管理和“心智负担”，搭建脆弱的“应用层补丁”作为桥梁。现在，以 DeepSeek-V3.1、Kimi-K2 等为代表的高性能开源模型的成熟，正在将定制推理层的权力重新下放，为弥合这条裂谷提供了硬件和软件上的根本前提。

前进的道路已经清晰：不再是应用层单方面地去适应推理层，而是通过推理层与应用层的深度耦合，共同进化，协同设计。这标志着一个新时代的到来——一个由产品需求驱动底层架构变革的 AI 原生时代。

但这场变革的终局，远不止于此。

随着我们开始定制推理层（Inference）以原生支持状态管理，并用 “上下文微调”（Contextual Fine-Tuning） 等高级 Prompting 策略来模拟专家知识注入，AI 产品的能力边界将不再是静态的。

不妨更加大胆一些：下一场革命将消除模型能力的“三位一体”边界。 即便是今天被视为相互独立的训练（Training/Data Preparation）、推理（Inference/Computation）和应用（Application/Interaction） 三个层级，也将走向融合。未来，一个真正的 AI 原生产品将是一个 “全栈 AI 产品”——它不仅仅是封装 API 的应用，而是将数据、推理和用户界面整合进一个协同优化的、原生的、有状态的系统。推理层的优化将前置到数据准备和模型加载阶段，产品的实时反馈将反哺上下文管理，形成一个闭环。

这正预示着 “简单套壳”时代的彻底终结。对推理层和状态管理的深度改造，本身就构成了下一代 AI 应用最核心的技术壁垒。

这场始于推理层的变革，最终将如何重塑团队、工具，乃至“AI 产品”的定义？我们相信，这正是当下所有 AI 建设者最值得思考和探索的方向。

参考文献

1. "Jasper raises 1.5B valuation," TechCrunch, October 18, 2022.
2. "Introducing ChatGPT," OpenAI Blog, November 30, 2022.
3. "ChatGPT sets record for fastest-growing user base in history, analyst note says," Reuters, February 2, 2023.
4. "The Inside Story of How ChatGPT Was Built From the People Who Made It," The New York Times, March 12, 2024.
5. "Introducing ChatGPT and Whisper APIs," OpenAI Blog, March 1, 2023.
6. "PagedAttention for Large Language Models," The vLLM open source project blog, June 2023.
7. Pope, R., et al. "Efficiently Scaling Transformer Inference," ML Sys 2023 Conference Proceedings, 2023.
8. "Improve prompt performance with caching," Google AI for Developers Documentation, Accessed August 2025.
9. "Prompt Caching," Anthropic Documentation, Accessed August 2025.
10. Zhang, Z., et al. "CacheBlend: A Scalable and Efficient Context-Aware Inference Engine for Large Language Models," arXiv preprint arXiv:2405.02869, May 6, 2024.
11. "Global AI Application Market Observation in January: 'DeepSeek' Emerges, Achieving 100 Million User Growth in Just 7 Days," NetMarvel, February 14, 2025.