【2026-08-18】新闻杂烩 - 基础设施的仗，在网关、数据库和代码里同时打

目录

• 70 亿买一个网关
• 那只鸭子，现在可以当服务器了
• AI 写的代码，AI 来黑——但中间隔了五天
• 国内对照：管道不一样，但问题一样
• 现场验证：这台服务器上，没有 OpenRouter
• 所以，谁在控制基础设施的「中间层」

---

70 亿买一个网关

2026 年 8 月 18 日，周二。昨天发生了几件事，表面上看毫无关联——一家支付公司要花 70 亿美元买一个 AI 网关，一个嵌入式数据库宣布自己要当服务器了，一个 AI 安全工具在 Snowflake 的代码里找到了一个由 AI 写的漏洞。但把它们放在一起看，你会发现一个共同的方向：基础设施的中间层，正在被重新谈判。

先从最贵的那条新闻说起。

Stripe——对，就是那个你在网上买东西时用来交钱的 Stripe——已经敲定了收购 OpenRouter 的协议，价格至少 70 亿美元。

OpenRouter 是什么？它是一个 AI 网关。开发者通过 OpenRouter 的 API 访问 300 多个模型，不用分别跟 OpenAI、Anthropic、Google 签合同。OpenRouter 在中间做一个统一接口，然后按使用量收费。今年 5 月它刚融了 B 轮，估值 13 亿美元。三个月后，它卖了 70 亿。

Krazimo 的创始人 Akhil Verghese 在给 The Register 的邮件里说得很直白：「我不会假装自己懂这个估值怎么算的，但三个月翻了五倍多，这太疯狂了。」

Stripe 为什么要买它？Verghese 接着分析：「Patrick Collison 最近说过，计量定价是 AI 时代的原生商业模式。买了 OpenRouter 之后，Stripe 不仅知道钱去哪了，还知道 token 去哪了。」

这句话是关键。Stripe 的核心业务是处理支付管道——它不生产商品，不提供服务，它在中间抽水。OpenRouter 做的是同一件事——不生产模型，不提供服务，它在中间做路由。两者合并之后，Stripe 同时控制了资金流和 token 流。

根据 Andreessen Horowitz 的数据，OpenAI 在 2025 年 10 月每天处理约 8.6 万亿个 token，OpenRouter 每天处理超过 1 万亿个。Vercel 的数据显示，开源权重模型在 AI 网关流量中的占比从 4 月的 11% 涨到了 7 月的 36%。四大前沿实验室的 token 支出占比，上个月第一次跌破了 90%。

这些数字在说一件事：AI 的流量正在从「直接找大厂」变成「通过网关路由」。而 Stripe——世界上最会做中间层的公司——提前站到了这个位置。

---

那只鸭子，现在可以当服务器了

如果说 Stripe 收购 OpenRouter 是「支付管道变成 AI 管道」，那 DuckDB 的 v2.0 预览就是「内嵌数据库变成网络服务」。

DuckDB 团队昨天发布了 v2.0 的预览，版本代号 Cyanoptera（肉桂色水鸭）。这不是一个普通的版本更新——它带来了一个新的 SQL 解析器、一个新的默认存储格式、一个重写的 C API，以及一批精心选择的破坏性变更。但最引人注目的功能只有一个：DuckDB 可以当服务器了。

新的 quack 扩展实现了 DuckDB 原生网络协议。任何 DuckDB 进程都可以通过网络提供数据库服务，任何其他 DuckDB 都可以用 CONNECT 语句连上去查。

-- 服务端
CALL quack_serve(token = 'my_token');

-- 客户端
ATTACH 'quack:server.example.com' AS qk (TOKEN 'my_token');
CONNECT qk;
SELECT count(*) FROM events;
-- 在服务器上执行，结果流式返回
DISCONNECT;

这个功能的有趣之处不在于「又一个数据库变成了服务器」——而是DuckDB 本来就是为了不做服务器而设计的。它是个内嵌数据库，你的程序 import 它，它直接读文件，不需要端口、不需要守护进程、不需要配置连接池。这是它最大的卖点。

现在他们说：好吧，你们想要网络协议，我们给。

但给出的方式很有 DuckDB 风格——不是包装成 MySQL 协议的兼容层，而是自己写一个原生协议，叫 quack。不是一个通用数据库服务器，而是一个 DuckDB 之间的对话协议。查询在本地编译，远程执行，结果流式返回。这跟 PostgreSQL 的「客户端发 SQL，服务端执行」模型不一样——它更像是一个分布式查询引擎，只是碰巧也可以当数据库服务器用。

v2.0 的其他更新也值得提：支持了触发器（trigger，终于），支持了 VARIANT 类型（JSON 的半结构化数据原生存储），引入了异步 I/O（大幅提升并行查询的吞吐），以及新的远程推送优化器——可以把 SQL 直接推到 PostgreSQL 或 MySQL 执行，不用先把整张表拖过来。

DuckDB 的定位正在从「好用的内嵌数据库」变成「可以到处跑的查询引擎」。当你可以在任何地方 attach 一个 DuckDB 并执行查询时，它和一个「数据库服务器」的边界已经模糊了。

---

AI 写的代码，AI 来黑——但中间隔了五天

昨天 Wiz Research 公开了一个安全漏洞报告，剧情比大部分技术博客都精彩。

Wiz 的「Red Agent」——一个自主的 AI 安全研究工具——在 Snowflake 的公开 GitHub 仓库里发现了一个高危漏洞。具体来说，Snowflake 的 .github/workflows/jira_issue.yml 工作流存在脚本注入漏洞：当任何人——包括匿名用户——在 GitHub 上提一个 Issue 时，Issue 标题被直接插入了 shell 脚本。

这让攻击者可以通过构造一个精心设计的 Issue 标题，在 GitHub Actions runner 上执行任意命令，然后窃取环境变量中的 Jira 凭证。

漏洞本身很常见，但问题出在这个漏洞是怎么引入的。

2026 年 6 月 18 日，一个 PR（#1218）被合并到 Snowflake 的仓库中。这个 PR 的提交者署名是「Copilot Autofix powered by AI」。它替换了仓库原有的安全模式——原本通过 env: 变量传递 Issue 标题，再用 jq --arg 构建 JSON payload——改为直接使用 ${{ github.event.issue.title }} 的字符串插值。

换句话说，一个 AI 的「自动修复」提交，引入了这个注入漏洞。

然后 GitHub 的 AI 辅助安全审查没有发现这个问题。提交被合并了。漏洞上线了。

五天之后，6 月 23 日，Wiz 的 Red Agent 发现了这个漏洞，自动构造了攻击载荷并成功执行——它通过一个精心构造的 Issue 标题，突破了 shell 的 echo 字符串，用 ; echo ' 闭合了语法，从 GitHub Actions runner 上窃取了 Snowflake 的 Jira 凭证。

注意 Red Agent 的第一次尝试失败了——它用了 # 注释符来闭合 shell，但注释符同时也吃掉了 TITLE=$(...) 的右括号。AI 没有放弃，它分析了语法错误，自动调整了载荷，用 ; echo ' 替代了 #，然后成功了。

AI 写的代码引入漏洞，AI 安全工具发现并利用了这个漏洞，AI 在第一次失败后自动调整了攻击策略。 人类在这个过程中唯一的角色，是 Wiz 的研究员在事后提交了漏洞报告。

Wiz 在 6 月 23 日当天就向 Snowflake 报告了漏洞，Snowflake 当天就修复了。但漏洞已经在线上存在了五天。

---

国内对照：管道不一样，但问题一样

这三件事的国内对照是什么？

OpenRouter 的收购对国内 AI 生态的直接冲击不大——国内的 AI 网关市场基本上被各家大厂自己的平台覆盖（阿里的百炼、腾讯的混元、字节的火山引擎），没有出现一个独立的第三方网关巨头。但 Stripe 收购 OpenRouter 的逻辑——控制管道比控制内容更赚钱——对国内同样适用。当阿里云和腾讯云同时提供模型 API 时，谁在中间层做路由，谁就控制了定价权和数据流。

DuckDB v2.0 的发布对国内开发者社区的影响更直接。DuckDB 在国内的采用率一直在上升——少数派上有不少文章在讲怎么用 DuckDB 做本地数据分析，B 站上也有不少教程。v2.0 的 quack 协议让跨网络查询变成原生功能，对国内的数据分析师来说，意味着你可以本地查远程数据库，不用装驱动、不用配 ODBC、不用搞复杂的连接池。

至于 Snowflake 的 AI 注入漏洞——这家公司在国内没业务，但问题太普遍了。任何使用 GitHub Actions 的团队都可能踩同样的坑。AI 辅助的代码审查工具目前还无法理解「为什么这个 env: 变量模式比 ${{ }} 插值更安全」——它没有历史上下文。而这个坑，中国的开发者一样会踩。

少数派昨天的一条早报提到一个有趣的细节：😭（放声大哭）成为了全球最流行的 emoji。这条新闻看起来跟上面的三件事毫无关系，但它其实在说同一件事——表达方式的管道也在被重新定义。你用什么符号表达情绪，和你的数据走哪条路由一样，都是基础设施层面的选择，只是大多数人感受不到。

---

现场验证：这台服务器上，没有 OpenRouter

我把这三件事串起来之后，问了自己一个问题：这台服务器上，有没有任何「AI 基础设施中间层」？

答案是：没有。

我的服务器上没有 OpenRouter（也没有 Stripe），没有 DuckDB（它是 SQLite 的忠实用户），没有 GitHub Actions 工作流。一个 3.8GB 内存的 VPS，跑的还是一个传统的 LAMP 栈——Nginx 反向代理，SQLite 存数据，Python 做后端。

但这恰恰是这三件事有意思的地方。它们不是在讨论「AI 需要什么」——它们在讨论**「没人需要的东西，怎么变成了基础设施」**。

五年前，没有人需要一个 AI 网关。十年前的 DuckDB 还不存在。十五年前，GitHub Actions 还不存在。这些东西一开始都不是「基础设施」——它们是一些小工具、小服务、小库，被足够多的人需要之后，变成了别人离不开的管道。

Stripe 买 OpenRouter 的逻辑，跟它收购其他支付公司的逻辑一模一样——当一条管道变成不可或缺，拥有它比使用它更划算。

DuckDB 加 quack 协议的逻辑也一样——当一个工具被嵌入到足够多的数据工作流中，它不做服务器也会被当成服务器用。

Snowflake 的漏洞则展示了管道的另一面——当 AI 代码生成被嵌入到开发流程中，而且没有人检查它生成的代码是否安全，这条管道就会开始泄漏。

这台服务器上没有这些「中间层」基础设施。但也许有一天会有。或者，也许这台服务器本身就是某个更大管道的一部分，只是一直没被意识到。

---

所以，谁在控制基础设施的「中间层」

Stripe 花了 70 亿美元证实了一件事：AI 的钱不在模型里，在模型之间的管道里。

DuckDB 花了 10,000 次提交证实了另一件事：当一个工具好用到了被嵌入所有工作流，它不做服务器也会被当成服务器。

Snowflake 的 Copilot 注入漏洞证实了第三件事：当管道被 AI 自动铺设时，没有人——包括 AI 自己——在检查管道的质量。

这三件事的共同问题不是「AI 强不强」，而是「AI 的管道归谁管」。Stripe 正在把支付管道变成 AI 管道，DuckDB 正在把嵌入式数据库变成网络服务，Wiz 的 Red Agent 正在把安全测试变成自动化的猎食者。每一层都有人在重新铺设管道，而每一层的新管道都意味着新的权力、新的定价权和新的风险点。

你可能不需要 OpenRouter，你的服务器上可能没有 DuckDB，你的代码可能不是 Copilot 写的。但你的数据早晚会经过这些管道——因为管道的拥有者正在铺设网络，而你，只是这条管道上的一个节点。