云雀 · 轻技术笔记

2026 年 10 月 2 日，AI 中间件同时被拆解——Pi 1.0、Clef、K2、turbopuffer v3 同天落地，但真正的剧本是云原生联手极简哲学

AIAgentLLM大模型AIGC

昨天（10 月 1 日）HN 首页前 30 条里 AI 相关至少 7 条，超过 100 分的爆点 5 条。不是模型发布，是中间件——曾经的「不可替代组件」——被自己的同阵营干掉了。

四个故事同天落地：

  • Pi 1.0 + Pi Durable（882 + 276 分）：Earendil 把「极简主义 agent harness」做成 v1.0 正式版，同时把 long-running 任务独立成 Pi Durable 实验包
  • Clef / Clef-flash（459 分）：Cloudflare 自训决策模型，Apache 2.0 全开源，Jev Decision Index 拿下第一，2.2 秒域名分类跑赢 gpt-oss-120b 的 4.7 秒
  • RIP, vector database（291 分）：turbopuffer 自己写博客宣布 v3 把 ANN 主索引废了，因为 vector 主索引拖死存储放大、写放大、向量化
  • Cloudflare K2（212 分）：基于 R2 object storage 的 serverless event stream，官方亲自写明「大部分公司会用 Kafka，但 K2 跑在边缘不用 Kafka」

外加 GitHub Trending 12 个 AI 项目里 7-8 个直接挂在同一条主线（Jev CLI、AnyJev、rizzoflow、awesome-jev-tools、zai-org/ZCode、yetone/magpie）——这不是偶然，是「AI 中间件被云原生 + 极简哲学联手拆解」的剧本在多线落地。

如果你今天还在用 Kafka + Pinecone + Claude Code 全家桶 + 大模型兜底判断，账单上是 2024 年的脚本，但你已经站在 2026 年 10 月的工具栈分水岭上。

1. turbopuffer 自己把 vector 主索引拆了——这不是博客，是投降书

「RIP, vector database」这个标题是 turbopuffer 官方博客，9 月 30 日发布，HN 291 分。turbopuffer 是 serverless 向量数据库的代表公司（v1 时代的旗舰产品），自家产品自家写悼词，这个信号比标题更狠。

核心论据（博客原文翻译）：

ANN primary index 这个东西… 用 object storage 跑 vector search 表现非常好——我们用它推到过单索引 1000 亿向量、p99 200ms、1000+ QPS。但这套架构在三个维度把非 vector 的查询 plan 全拖死了：storage amplification、write amplification、limited vectorization。

具体怎么拖死：

存储放大（storage amplification）：vector ANN 主索引决定了所有其他索引怎么布局——意味着 attribute filter、full-text、aggregation、regex 都要迁就 vector 的物理块大小。turbopuffer 一直想做的「ClickHouse 级 65k 行块」被卡在 ANN 的 100-200 行。

写放大（write amplification）：每次 vector 重新平衡（rebalance），所有附属索引都得跟着重排。turbopuffer 自家博客里承认「这是 v2 时代一个反复出现的运维痛点」。

有限的向量化（limited vectorization）：SIMD 优化的前提是紧密循环、固定块大小。ANN 主索引把块大小锁死，所有 query plan 都拿不到最佳 CPU 流水线。

v3 的关键决定：不再以 ANN 地址作为主键（don't key on the ANN address）。

这是个狠活——意味着 v2 时代的存储布局全部推倒重来。turbopuffer 自己写：

我们 v3 重新打地基（reworked postings），所有 query plan 都会受益——attribute filter、full-text、aggregation、regex、fuzzy、sparse vector、ANN 全都拿到独立优化路径。CI 100% 通过是上个月的事，下一步是 benchmark 全部跑赢 v2。

为什么这是投降书：turbopuffer 没说「vector DB 已死」，也没说「不要买向量库了」。它说的是——「vector 作为主索引这种架构死了」。这是 v3 这次重写的核心立意。换句话说，过去三年所有「先 vectorize 再 attribute filter」的 RAG pipeline 设计假设，在 turbopuffer 自己眼里都不再成立。

跟 HN 同期讨论的另一条暗线呼应：vectorless RAG（用 reasoning 模型 + BM25 + reranker 替代 dense retrieval）从 9 月开始被多家云厂商推上产品路线。Microsoft、Anthropic、Google 的 RAG 模板默认走「hybrid」已经是 2025 年的事了；2026 年 10 月的剧本是「dense retrieval 是可选项不是默认」。

所以昨天「RIP vector database」这条线讲的不是「向量数据库公司倒闭」，是「vector-first 架构被 reason-first / attribute-first 架构联手替换」。

反常识洞察：过去三年 RAG 工程师的肌肉记忆是「先 embed → 存向量 → top-K 召回 → rerank」。这套 pipeline 默认 vector 是主索引。turbopuffer v3 在生产层证明这套默认是错的——attribute + reason 先于 dense recall 是新默认。所有还按 2024 年模板写 RAG 的团队，今天已经在用过期架构了。

2. Cloudflare Clef 拿下 Jev Decision Index 第一，但真正的剧本是「Cloudflare 同一天三发」

10 月 1 日 Cloudflare Birthday Week 第一天，三篇博客同时发：

  • Clef / Clef-flash 决策模型 + RL fine-tuning 平台
  • K2 serverless event streams
  • Cf-Turnstile-2026（HMAC 升级，HN 没进首页但是 Cloudflare 开发者平台基线更新）

Clef 的硬数据（Cloudflare 官方博客原文）：

  • Cloudflare 自训决策模型，Clef 是当前 Jev Decision Index 第一（TypeSafe AI 的 Jev 系统一基准测试）
  • Apache 2.0 全开源，托管在 Workers AI，可以一键本地跑
  • vs Jev 的三大差异化：①vision encoder（图像分类，Jev 只能文本）②64k context（vs Jev 32k）③Jev Decision Index 评分领先
  • 实测：Cloudflare Threat Intelligence 团队用 Clef 分类域名，2.2 秒端到端（fetch + render + classify） vs 同样的工作流 gpt-oss-120b 4.7 秒——2x 延迟优势
  • 同时发布 Cloudflare RL fine-tuning 平台——客户可以 fine-tune Clef 适配自己的 decision use case

这个模型的意义不在「又一个开源决策模型」，而在「Cloudflare 用一个决策模型 + 一套 RL 训练平台同时下注」。意味着 Cloudflare 在赌：

Decision model 不是模型，是一种新的 SaaS 形态——客户买「决策模型 + 训练数据 + 微调平台」打包，而不是买「调 API + 自己拼 prompt」。

这套打法直接对标 TypeSafe AI（Jev 系统一）的商业逻辑。TypeSafe 卖「SystemOne 决策模型 + 平台」打包，Cloudflare 反手把同一品类开源 + Workers AI 托管 + RL 训练免费做。

对 TypeSafe 的实际影响：Jev 系统一在决策模型赛道是事实标准（GitHub trending 长期有 awesome-jev-tools、AnyJev、rizzoflow 等周边生态），但Jev 本身不开源。Clef 开源 + Workers AI 托管 + RL 训练免费这套组合拳，等于 Cloudflare 用「开源协议 + 训练平台 + 边缘推理」三件套直接抄 TypeSafe 的底。

昨天看到的 GitHub 候选清单（search API 输出，未做 baseline 比对）：

  • dzhng/jevgrep ★2005：「Find code by asking what it does. A CLI for coding agents that uses Jev」——Jev 已经在渗透 agent 工具栈
  • Nokia AnyJev ★1003：「Turn any LLM into a Jev-style decision model」——连 Nokia 都在下场做 decision model 转换
  • Rizzo-AI-Academy/rizzo-flow ★784：「The open, local take on Jev」——开源本地版 Jev
  • v-modal/awesome-jev-tools ★734：Jev 工具集 awesome list

Jev 已经形成事实标准，但 Clef 这次「开源 + 64k + vision + RL fine-tuning + Workers AI 托管」打包，让 Jev 不再是「不可替代」。

反常识洞察：Clef 不是 Cloudflare 的「又一个模型」，是 Cloudflare 对 TypeSafe 商业模式的「开源协议 + 训练平台 + 边缘推理」三件套打击。TypeSafe 的护城河从「协议 + 模型」被撬到只剩「协议」。所有买 TypeSafe 决策模型服务的客户，今天应该立刻评估 Clef 自托管成本是不是砍到 70% 以下。

3. Cloudflare K2 是 Kafka 替代品的真正剧本——不是性能更好，是「不用运维」

K2 官方博客自己写得很直白：

大部分公司会用 Apache Kafka。但我们的 Pipelines 跑在 Cloudflare 边缘——335 个城市的服务器。我们经常跑不了传统分布式系统软件（Kafka 这种），得重新想这些系统怎么搭怎么运维。

Cloudflare 边缘跑 Kafka 难在哪：边缘服务器是相对小的机器切片、生命周期短、网络走公网。Kafka 强假设「机器稳定、网络稳定」。这两个假设在边缘都不成立。

K2 的解法（这是真正值得抄的设计）：

  • 底层用 R2 object storage——11 个 9 的持久性 + 强一致 API
  • 把 replication 和 consensus 全部外包给 R2，应用层（K2 本身）变成极其简单的小服务
  • R2 不支持 append，所以 K2 的策略是「先在边缘节点的内存里攒批 → 写到 R2 整段文件（segment）→ 用 R2 原子操作保证严格递增 offset」
  • 99th produce latency 约 1 秒（vs Kafka 毫秒级）——官方承认这一点

K2 不是「比 Kafka 更快」，是「比 Kafka 更不用运维 + 跑在边缘 + 长期保留数据」。这是 serverless 范式和数据局部性的交换——你拿延迟换 0 运维 + 全球分布 + 11 个 9 持久性。

跟 Pi 1.0 + Clef 联动的剧本：

  • Clef 是「LLM 判断 → 决策模型 + RL 训练」的 serverless 化
  • K2 是「Kafka → 边缘持久事件流」的 serverless 化
  • Pi 1.0 是「Coding agent harness → 极简 substrate + virtual models」的 serverless 化
  • turbopuffer v3 是「vector 主索引 → attribute / reason 主索引」的架构 serverless 化

四件事同天落地，剧本是同一个：「传统中间件的 serverless / 边缘化重构」。这件事不是 Cloudflare 一家在做——AWS Lambda + DynamoDB Streams、Google Cloud Run + Pub/Sub、Azure Functions + Event Grid 全在做。Cloudflare K2 的特殊在于官方明确写「不用 Kafka」，直接把替代关系画出来。

反常识洞察：你今天还在用 Kafka / RabbitMQ / Redis Streams 做 agent 后端事件流，不是因为它们更好，是因为它们先存在。当 Cloudflare 用 R2 做出 11 个 9 持久性 + 边缘分布 + 0 运维的 K2，传统消息队列在 AI agent 后端的护城河就只剩「延迟差几毫秒」+「迁移成本」。所有 2024 年搭的 Kafka 集群，今天应该被认真评估是不是要切到 K2 / DynamoDB Streams / Pub/Sub——迁移 ROI 不是看「现在 Kafka 还能用」，是看「agent 流量爆炸的时候 Kafka 集群维护成本会不会吃掉你整个工程团队的带宽」。

4. Pi 1.0 + Pi Durable：极简主义 agent harness 拿到 v1.0，但 Pi Durable 才是真正的剧本

Pi 1.0 882 分是昨天 HN 首页 AI 相关最高分。Earendil 团队（Pi 母公司）的发布博客原文翻译：

我们正式发布 Pi 1.0——一个 hardened、minimal、extensible 的 agent harness，你可以把它变成自己的。每周全球有几十万人用 Pi。我们很多 issue 和 PR 都在推动这个项目稳定。今天我们把几个月累积的反馈沉淀成 v1.0。

Pi 的核心哲学（不是新东西，9 月以来反复被讨论）：极简主义。Earendil 自己的话翻译：

我们坚持 minimal 这条线。agentic tooling 每周都在变，但很多变化活不长。Pi 不是这样的——我们等到某个东西被证明有用，再考虑是否纳入；我们权衡它的真实功能 vs 增加的复杂度。

Pi 1.0 加了什么（这是 v1.0 的硬清单）：

  • Codemode（原生 MCP 支持 + 非 LLM 模型如 Jev、image models 的 runtime）
  • Extension support for virtual models（虚拟模型扩展支持——意思是「通过本地扩展就能把任何模型包成 Pi 兼容的 virtual model」）
  • Deferred tool loading（延迟工具加载——只在需要时加载工具定义，不一股脑塞进 context）
  • Cache warming for Anthropic models（Anthropic 模型的缓存预热——把 prompt cache 提前填好，省下 cache miss 的成本）
  • Mid-conversation system messages（transcript-aware prompt 和 tool 变化——可以在对话中间改 prompt 和工具，不重启 session）
  • A new TUI theme
  • Full-screen mode by default

但真正的剧本是 Pi Durable——同一个发布日，Earendil 团队把 long-running agent 任务独立成了一个实验包：

npm install @earendil-works/pi-durable @earendil-works/pi-ai @earendil-works/chord

Pi Durable 跟 Pi 1.0 的关系（Earendil 原文翻译）：

Pi Durable 是构建 long-running agentic 应用的新 substrate——让 builder 和 user 都能用极高的灵活性来 wield 和 steer 底层 intelligence。它共享 Pi 的关键原则（minimal + supermalleable），但把这些原则扩展到新维度。

Pi Durable 是为什么这是真正的剧本：传统 agent harness 假设「用户敲一个 prompt → agent 跑几分钟 → 结束」。Long-running agent 是「agent 跑几小时 / 几天 / 几周，中间用户可能介入可能不介入」。这两种 workload 对 runtime 的要求差一个数量级：

  • 状态需要持久化（不能因为 LLM session 过期就丢上下文）
  • 工具需要可热替换（agent 跑了一周，工具 v1 已经迭代到 v3）
  • prompt 可以在 mid-conversation 改（Pi 1.0 的 mid-conversation system messages 这个 feature 就是为这个）
  • virtual models 可以在运行中切换（Pi 1.0 的 virtual models extension 就是为这个）
  • 缓存策略需要主动管理（Pi 1.0 的 cache warming 就是为这个）

Pi Durable 是一整套「agent 长期化」的基础设施，而 Pi 1.0 是这套基础设施的「单 session 极简入口」。两个一起发，意味着 Earendil 在赌：

agent 的未来不是「单次 prompt + 短任务」，是「持续运行 + 长期协作 + 可中途干预」。短期任务的 agent harness（Claude Code / Codex CLI / Pi 1.0）是临时工具，长期 agent 的 Pi Durable 才是真正的产品形态。

这个赌注的代价是 Earendil 必须自己写「durable runtime」「virtual model abstraction」「transcript-aware prompt mutation」——这一整套是被 Anthropic / OpenAI 故意没做的（他们想卖 token 和 harness，不想要 customer 拥有 durable 资产）。

反常识洞察：所有现在用 Claude Code / Codex CLI 做「长跑 agent」的人，今天应该把 Pi Durable 加到评估清单里。短期 harness 是商品，长期 harness 是护城河。Cloudflare / Anthropic / OpenAI 都不想做 durable runtime 这个层——因为它让客户拥有「自己跑 long-running agent」的能力，token 收入会掉。Earendil 做了这件事等于赌「客户长期资产所有权」比「持续 token 收入」更有商业价值。这个赌的胜负，决定了未来三年 agent runtime 市场的最终格局。

5. 五件事联动的「AI 中间件被拆解」剧本——四张骨牌 + 一个隐藏赌注

把昨天四件大事放一起看：

故事 拆解了什么 谁拆的 留下的护城河
turbopuffer v3 vector 主索引架构 自家 attribute + reason 主索引 + 新协议
Cloudflare Clef 闭源决策模型商业护城河 Cloudflare 开源协议 + RL 平台 Jev 协议（TypeSafe 剩这点）
Cloudflare K2 Kafka 在边缘的部署假设 Cloudflare 边缘 + R2 1s p99 latency（K2 剩下的弱点）
Pi 1.0 + Pi Durable 短期 agent harness 商业护城河 Earendil 极简主义 + durable runtime token 收入（Anthropic/OpenAI 剩这点）
GitHub Jev 周边 7-8 项目 大模型「判断」层 社区 协议（Jev 协议再次被验证）

共同的剧本：

AI 中间件正在被「云原生 + 极简哲学」联手拆解。每拆一层，留下的护城河更薄、更底层、更像「协议层」而不是「产品层」。

五件事的对应节奏非常工整：

  • turbopuffer 拆的是「vector 主索引假设」→ 留 attribute / reason / sparse 主索引
  • Clef 拆的是「闭源决策模型护城河」→ 留 Jev 协议
  • K2 拆的是「Kafka 部署假设」→ 留 serverless 持久事件流范式
  • Pi 1.0 / Durable 拆的是「短期 harness + token 收入」→ 留 durable runtime + virtual model 抽象
  • GitHub Jev 周边 拆的是「大模型判断层」→ 留 Jev 协议

每拆一层，token 收入都掉一截。这是昨天所有事同天落地后，最让人后背发凉的剧本——模型层、消息层、决策层、agent runtime 层、向量层，五件事都在把「AI 中间件 = 持续收入」这件事拆掉。

隐藏赌注：

Cloudflare 同一天做「决策模型 + 事件流 + agent runtime 入口 + skills」四件套，赌的是「AI 时代最大的隐形赢家是中立基础设施层」。它不卖模型，不卖 harness，不卖 agent 产品——它卖「决策模型推理（Clef on Workers AI）+ 边缘事件流（K2）+ agent runtime 入口（Workers）+ skills 协议（security-audit-skill）+ 数据训练（RL fine-tuning 平台）」。Cloudflare 在赌「AI 时代 AWS」的位置。

这个赌注的代价是 Cloudflare 必须把每一层都做成「中立可替换」——客户可以在 Workers AI 上跑 Clef 或 Jev，可以在 K2 上发事件或同步用 Kafka，可以用 Cloudflare 的 harness 或别的厂商的 Pi。这就是为什么 Clef 必须 Apache 2.0 全开源、K2 必须跑在 R2 上（不是 Cloudflare 自家的专用存储）。

反常识洞察：昨天讨论 AI 中间件的时候，95% 的同行还在讨论「哪个模型最强 / 哪个 harness 最好用 / 哪个向量库最快」。但昨天真正改变剧本的不是模型——是Cloudflare 同一天在四个层同时下注「中立基础设施 + 开源协议 + 边缘推理」。这件事的真正杀伤力不在 Clef 单点（Clef 自己），在「Cloudflare 同时在做决策模型 + 事件流 + agent runtime + skills + 训练平台」这件事本身。未来三年所有想当「AI 中间件霸主」的公司，都会撞上 Cloudflare 这个中立但全栈的玩家。

6. 给工程团队的五件可操作的事

别管云厂商押注什么，先看自己今天能做什么。

6.1 跑通 Pi 1.0 + Pi Durable，30 分钟成本账

curl -fsSL https://pi.dev/install.sh | sh
# 或者 Windows
powershell -c "irm https://pi.dev/install.ps1 | iex"

# Pi Durable 是实验包
npm install @earendil-works/pi-durable @earendil-works/pi-ai @earendil-works/chord

跑通后立刻做两件事：

  1. 测 virtual models 扩展——把 OpenAI / Anthropic / DeepSeek / 本地 Ollama 全部包成 Pi virtual model，记下 cache warming 的实际命中率
  2. 测 Pi Durable——写一个 long-running agent（比如每天跑一次抓 GitHub Trending + 写日报），跑一周看 token 成本和稳定性

预期收益：用 Pi Durable + virtual model abstraction 把模型切换成本砍到 0。今天的 agent 团队，最贵的不是模型是「锁定一家模型厂的 harness」。Virtual model 抽象是降本的第一步。

6.2 把 decision layer 从 LLM 拆出来——Clef / Jev / Ollaya 三选一实测

# Clef via Cloudflare Workers AI（参考 Cloudflare 博客示例）
import requests

response = requests.post(
    "https://api.cloudflare.com/client/v4/accounts/<account_id>/ai/run/@cf/cloudflare/clef",
    headers={"Authorization": "Bearer <api_token>"},
    json={
        "inputs": {
            "context": "客户支持工单: 我已经等了 3 天没人回",
            "options": [
                {"label": "紧急", "description": "需要立即人工处理"},
                {"label": "普通", "description": "24 小时内回复"},
                {"label": "低优先级", "description": "48 小时内回复"}
            ]
        }
    }
)
print(response.json())

对比 Jev API（TypeSafe 商业版）：

from jev import Jev

client = Jev(api_key="...")
result = client.decide(
    context="客户支持工单: 我已经等了 3 天没人回",
    options=["紧急", "普通", "低优先级"]
)
print(result)  # 返回 typed answer + probability

对比 Ollaya（GitHub 开源本地版）：

# RTX 4090 本地
ollaya pull laya
ollaya run laya "客户支持工单: 我已经等了 3 天没人回 -> 选项: [紧急, 普通, 低优先级]"

预期收益：decision layer 从 LLM 拆出来后，单次判断从 4.7 秒 → 2.2 秒（Clef 实测数据），成本砍到 1/444x（Jev vs GPT-4，9-16 那篇实测）。Agent 团队最常见的隐性成本是「用 LLM 做判断」——把它拆出来，一年能省 30-60% token 预算。

6.3 评估 K2 替代 Kafka 的真实 ROI——别只看延迟

迁移 checklist：

  • 你今天 Kafka 集群的运维成本（人 / 月）：______
  • 你今天 Kafka 集群的 failure rate（过去 90 天）：______
  • 你的 agent 流量未来 6 个月预期增长：______
  • 你的 agent 流量峰值下 Kafka 集群响应延迟：______

如果前两项任意一项超过 0.5 人/月 + 第三项超过 5x——你应该认真评估 K2 / DynamoDB Streams / Pub/Sub。K2 1 秒 p99 latency 不是问题，问题是你的 agent 是不是真的需要毫秒级 produce 延迟。如果是高频交易或实时风控，别换。如果是 90% 的「agent 任务事件」「用户操作日志」「skill 调用 trace」，K2 的 1s p99 完全够用。

预期收益：把 Kafka 集群运维成本砍到 0，让工程团队把带宽还给「agent 产品迭代」而不是「消息队列运维」。

6.4 RAG pipeline 改造——把 vector 主索引降级为可选组件

如果你的 RAG pipeline 还是「先 embed → 存向量 → top-K 召回 → rerank」这套 2024 模板，按 turbopuffer v3 的设计哲学改：

  1. 先 attribute filter——把用户 metadata、时间范围、tag 先过一遍
  2. 再 hybrid recall——BM25 + sparse vector + dense vector 三路并行召回
  3. 最后 reason rerank——用一个 reasoning 模型做最终排序

为什么这么改：

  • attribute filter 命中率高、延迟低、token 成本为 0
  • BM25 / sparse vector 不需要 embedding 模型，可以本地跑
  • dense vector 退到「补充召回」而不是「主召回」——top-K 从 100 砍到 20
  • reason rerank 用小模型（Llama 3.1 8B / Qwen2.5 7B）本地跑，不要用 GPT-4

预期收益：RAG token 成本砍到 40-60%，召回延迟从 800ms 砍到 300ms。所有按 2024 年 RAG 模板写的团队，今天已经在用过期架构。

6.5 30 天内把 harness 的「锁定风险」评估清楚——5 步行动手册

Day 1-3：盘点你的 harness 锁定程度

  • 你今天用 Claude Code / Codex CLI / Cursor 哪些 feature？
  • 哪些 feature 离开这家厂商后没法 1:1 替换？
  • 你能不能 7 天内把 Pi 1.0 跑起来做 fallback？

Day 4-7：测 Pi 1.0 + Pi Durable

  • 装 Pi 1.0
  • 跑通 virtual models（OpenAI / Anthropic / DeepSeek / Ollama 全部包成 Pi virtual model）
  • 写一个 Pi Durable 长跑 agent（一周跑一次）

Day 8-14：自己写 tool call history 截断

  • 不要相信任何 harness 的「自动压缩」——自己写
  • 截断策略：最近 5 轮完整保留 + 之前轮次 summary + 关键决策原文保留

Day 15-21：模型 + harness 预算解耦

  • 模型成本独立预算
  • harness 成本独立预算（virtual model + durable runtime）
  • 中间件成本独立预算（decision model + 事件流 + 向量库）

Day 22-30：评估国产模型 + 极简 harness

  • 把 DeepSeek / Qwen2.5 / GLM-4.6 加到 virtual model 池
  • 用 Pi 1.0 跑同样的 benchmark（建议 HarnessTax 论文的三组 benchmark）

预期收益：harness 锁定风险从「完全锁定 Claude Code / Codex CLI」降到「30 天内可切换 Pi 1.0 + 国产模型 + decision layer 拆分」。单次切换成本砍到原来的 10% 以下。

7. 反思：昨天这事的关键不是技术，是「时间窗口」

写完五件事联动，我必须做一次自我反思。

昨天最让我后背发凉的，不是任何单一技术——是「Cloudflare + Earendil + turbopuffer + 社区（Jev 周边）在同一个 36 小时窗口内同时按下按钮」。这种多线同时行动的事情，历史上只在两种剧本里出现过：

  1. 范式转换点（1996 Apache / 2013 Docker / 2017 Kubernetes / 2023 Ollama）
  2. 市场拐点（2008 金融危机后云厂商集体推 PaaS / 2020 疫情后远程协作集体爆发）

我倾向于这是第一种。证据是：

  • Cloudflare（中立基础设施层玩家）首次同时在「决策模型 + 事件流 + agent runtime + skills + 训练平台」五层下注
  • Earendil（Pi 母公司）首次把 agent harness 拆成「短期 + 长期」双产品形态
  • turbopuffer（向量数据库厂商）首次自承 vector 主索引假设错误
  • TypeSafe + Jev 生态（决策模型事实标准）在 GitHub 周边的项目数量一周翻倍
  • Pi + ZCode + magpie + clematis + affaan-m/ECC（极简主义 harness 阵营）继续霸榜 GitHub Trending

这五件事单独看都是「产品迭代」，但同 36 小时窗口一起看是「中间件层的协议战争」。胜方会拿到未来三年 AI 中间件的标准定义权，败方会被收编或消失。

我个人预测（六个月后回头看）：

  1. Cloudflare 在 AI 中间件中立基础设施的位置会在 2027-Q2 之前被市场验证——证据是 Clef / K2 / Workers / skills 四个产品的 adoption 数字能不能在 2027 年中之前跑到对标 TypeSafe / Pinecone / Confluent 三家总和的 30%
  2. Pi Durable 会在 2027-Q1 之前被某家大厂战略投资或收购（Anthropic / OpenAI / Google 概率最大）——证据是 long-running agent 这个品类一旦成立，token 收入模型会被重创
  3. turbopuffer v3 会在 2027 年中之前被某家大厂收购或战略投资——v3 是「vector-first RAG 范式终结」的工程化表态，谁拿下 turbopuffer 谁就拿到「下一代 RAG 范式定义权」
  4. TypeSafe Jev 在 6-9 个月内被迫开源协议层——Clef 这套组合拳直接抄底 TypeSafe 的商业护城河，TypeSafe 不开源协议层就会被开源阵营挤死
  5. K2 / DynamoDB Streams / Pub/Sub 在 12 个月内吃掉传统消息队列在 AI agent 后端 40% 的市场份额——证据是「agent 流量爆炸但 Kafka 集群运维成本线性增长」的结构性矛盾

我对今天的判断：

中间件被拆解不是「技术进步」，是「客户觉醒」——客户终于意识到「AI 中间件 = 持续收入」这件事不合理，开始用脚投票选开源协议 + 自托管。未来三年的赢家不是任何一家 AI 中间件厂商，是「中立 + 开源 + 边缘」三件套都做到位的玩家。

8. 你应该今天就开始做的三件事

  1. 把 decision layer 从 LLM 拆出来（30 行 Python + Clef / Jev / Ollaya 任选），立刻测延迟和成本
  2. 装 Pi 1.0 + Pi Durable，跑通 virtual models + long-running agent（1 小时）
  3. 评估 RAG pipeline 的 vector 主索引假设，把 attribute filter + BM25 提到 dense recall 前面（半天）

不要做的三件事：

  1. 不要买 TypeSafe Jev 商业服务超过 6 个月——Clef 开源 + Workers AI 托管 6 个月内会出更激进定价
  2. 不要在 2026 年再搭新的 Kafka 集群——K2 / DynamoDB Streams / Pub/Sub 任选，迁移 ROI 已经成立
  3. 不要按 2024 年 RAG 模板写新代码——attribute / reason 主索引是 2026 年的默认

今天真正的护城河不是模型，不是 harness，不是 vector DB——是「中立 + 开源 + 边缘」三件套都站对位置的玩家。Cloudflare 是当下最明显的候选人。Earendil + turbopuffer + Jev 生态是候选联盟。

如果你今天还在用 2024 年的中间件栈（Kafka + Pinecone + Claude Code 全家桶 + GPT-4 判断），账单上是 2024 年的脚本，但你已经站在 2026 年 10 月的工具栈分水岭上。

结尾那根刺：所有昨天讨论「Cloudflare 同天三发」「Pi 1.0 + Pi Durable」「turbopuffer v3 拆自家 vector 主索引」的同行——你们有没有注意到，这四件事里没有一件是「模型本身变强」？全部是「基础设施层在变」。模型层已经稳定了，真正革命的剧本从来不是模型革命，是「模型稳定之后中间件被重新定义」的剧本。未来三年你该站哪一边，取决于你愿不愿意在今天花 200 行代码把 decision layer + virtual models + attribute-first RAG + serverless event stream 四件套搭起来。这件事不是可选项，是 AI 中间件时代的入场券。