This happens because network proxy environments on the host do not automatically broadcast down to guest virtual machines or system-level configuration hooks. Furthermore, package managers like apt and protocols like SSH handle proxy routes entirely differently. This post outlines a clean, production-grade configuration to bind both tools directly to your host’s proxy tunnel seamlessly.

1. Unlocking Apt Performance via Explicit Mapping

Setting global environment variables like export http_proxy=… in your shell profile can be brittle and often fails to pass cleanly into elevated environments when invoking commands with sudo . The most bulletproof approach for the Advanced Package Tool (APT) is to supply a direct, persistent configuration directive. To do this, create an isolated configuration file within the apt directory structure:

sudo nano /etc/apt/apt.conf.d/proxy.conf

Inside, append the targeted proxy destinations. Depending on how your host machine’s system configuration handles virtualization loops, select the correct profile below.

Scenario A: You use WSL2 Mirrored Networking

If your .wslconfig is set up with networkingMode=mirrored , the Windows host and Linux guest share the exact same network interface layout. This means localhost (127.0.0.1) maps straight out of the environment to your active host proxy listener:

sudo nano /etc/apt/apt.conf.d/proxy.conf

Acquire::http::Proxy "http://127.0.0.1:7890";
Acquire::https::Proxy "http://127.0.0.1:7890";

Scenario B: You use Default WSL2 NAT Networking

If you are on the default Network Address Translation mode, 127.0.0.1 loops inside the isolated Linux VM instead of breaking out to Windows. You must explicitly target the dynamic host gateway interface IP instead:

# Generate the rule inline using your active network routing matrix
HOST_IP=$(ip route show | grep default | awk '{print $3}')
echo "Acquire::http::Proxy

2. Tunneling Git Clone and SSH Connections

Once apt is optimized, you might run a git clone git@github.com:user/repo.git and find it still crawling or timing out. This is because standard apt.conf blocks only handle HTTP/HTTPS streams, while secure shell connections (SSH) bypass your system environment web variables entirely.

To route secure git traffic over your host’s proxy, you need to configure an internal stream-tunneling bridge using connect-proxy .

Step 1: Install the Proxy Utility

Leverage your newly optimized package manager to fetch the tunneling backend tool:

sudo apt update && sudo apt install connect-proxy

Step 2: Declare the Configuration Maps

Open or create your local user SSH routing configuration map:

nano ~/.ssh/config

Append the following runtime block to force any handshake requests directed at github.com to break out through the proxy tunnel wrapper instead:

nano ~/.ssh/config

Host github.com
User git
ProxyCommand connect -H 127.0.0.1:7890 %h %p

Note: If your environment utilizes standard NAT mode networking, swap 127.0.0.1 for your calculated $ {HOST_IP} . If your proxy engine runs primarily via the SOCKS5 protocol rather than raw HTTP, swap the flag parameter from -H to -S .

Step 3: Secure Permissions and Verify

The SSH engine strictly validates security profiles on your configuration assets. It will bypass the rules completely if permissions are open to systemic modification. Restrict the target file:

chmod 600 ~/.ssh/config

Run a direct test handshake to verify that authentication finishes successfully over the proxy layer:

ssh -T git@github.com

If executed correctly, GitHub will greet you with a successful remote validation notice, and your git clone commands will download at the full capacity of your underlying hardware link.

全世界的开发者已经用充分的实践证明，Code Agents（代码智能体）可以胜任各种软件开发任务，数据库系统这一皇冠上的明珠自然也不例外。我们在数据库领域对 Code Agents 进行了全方位的探索，在享受效率红利的同时，也积累了一系列深刻的经验与教训。我们的日常开发栈涵盖了 GitHub Copilot、Claude Code、Gemini CLI/Antigravity、Cursor 及 Codex 等主流工具。

从辅助阅读到内核开发

首先，即便配合推理能力一般的模型，Code Agents 也足以胜任代码阅读、基础功能修改及自动化代码提交。令人惊叹的是，在处理复杂的 C/C++ 算法、SIMD 指令优化等底层任务时，Code Agents 的理解与编写速度甚至超越了很多资深程序员，且准确性更高。对于许多中国程序员而言，Code Agents 撰写的英文注释和 Commit Messages 显然更加地道流畅。

其次，Code Agents 在数据库周边生态——如命令行工具、GUI 管理端及服务化功能的开发中表现突出。这些领域多采用 Java、Go、Rust 或 Python 等现代流行语言，模型训练数据充足，写起来更得心应手。

最后，在数据库内核开发（C/C++、Go、Rust）中，Code Agents 虽能参与，但也存在明显的短板。对于复杂的并发竞争场景、深度的系统级性能优化，或是那些缺少文档的陈旧闭源仓库，Code Agents 往往显得力不从心，难以自动化解决全部问题。

模型能力的“方差”与劣化

除了 Code Agents 框架本身的差异，底层大模型（LLM）的代差也十分显著。例如，GLM 4.x 系列在逻辑推理上明显逊于 5.x；而在代码生成的细腻度上，Google Gemini 很多时候不如 Anthropic 的 Opus 4.x。

受限于算力成本，各大平台的 Coding Plan 普遍存在各种限流措施。此外，一个比较明显的现象是：大模型新版本发布初期往往“惊为天人”，但随着用户量激增，效果便会出现明显的劣化（降智）。这背后或许是平台方为了节省成本，切换了更高程度量化的版本，或是采取了其他的推理剪枝策略。

人的价值：从编码者到定义者

在 Code Agents 与模型之外，人类工程师本身往往是被忽视的关键变量。实践表明，面对同样的任务，不同水平的工程师利用 AI 产出的结果天差地别。如果人类工程师说不清楚问题、没法验证修改结果，那么他在链路中最大的价值，恐怕只剩下作为“第一责任人”去承担系统故障带来的“背锅”重任了。

复刻 SQLite：生机勃勃的“幻觉”

SQLite ( https://github.com/sqlite/sqlite ) 极具代表性：它应用极广、代码精纯，且作为嵌入式数据库，其系统复杂度适中。近年来，围绕 SQLite 的 Fork 或重写项目层出不穷。从 Turso 早期基于 C 的 libSQL ( https://github.com/tursodatabase/libsql ) 改进，到 2024 年决定用 Rust 重写而生的 Limbo ( https://turso.tech/blog/introducing-limbo-a-complete-rewrite-of-sqlite-in-rust )，再到 2026 年在 Vibe Coding 浪潮下、借助 Claude Code 诞生的一系列 Rust 重写项目，如 FrankenSQLite ( https://github.com/Dicklesworthstone/frankensqlite ) 等，这种趋势愈演愈烈。

2026 年 3 月 Claude Code 源码的泄露引发了全球开发者的“重写狂欢”。尽管这些项目在 README 中列举了各种冠冕堂皇的理由，但我们必须清醒地认识到：随着 Code Agents 的普及，开源项目的复刻版本将呈指数级增长，给人一种“生机勃勃的幻觉”。

当前形势下，Code Agents 虽然可以自主编码、撰写测试，但要保证大型系统软件的工业级质量仍极具挑战。测试用例与测试工具正成为数据库领域最核心的资产。 事实上，SQLite、MySQL 等老牌开源软件很早就决定不开源其核心测试用例和测试工具（如 SQLite 核心测试用例是闭源的），这种未雨绸缪的做法在无意间为今天的 Code Agents 完美复刻制造了巨大的门槛。FrankenSQLite 等项目虽初步证明了 Code Agents 构建数据库系统的潜力，但其系统功能与性能仍远逊于打磨了二十载的 SQLite。

魔法对轰魔法：AI Driven Research

从现状看，Code Agents 能够迅速产出大量实现方案，而验证方案的有效性反而成了最大的吞吐瓶颈。

目前的最佳办法是“以魔法对抗魔法”——让 Code Agents 自己来验证有效性。然而，系统性能验证、并发正确性验证及完整的系统功能验证需要耗费巨大的资源和时间，一不小心就会演变成 AI 之间的“魔法对轰”，浪费无数算力。学术界也在研究中尝试 AI 驱动的研究：AI-Driven Research (ADR)。近期 arXiv 上的论文预印稿 AI-Driven Research for Databases (https://arxiv.org/abs/2604.06566) 提出：为了实现 ADR 在数据库系统研究的实际应用，建议通过让“评估器”与“解决方案”协同进化来实现自动化研究。在优化缓冲区管理、查询改写及索引选择的三个案例研究中，这种方法已初步显现其效果。

The Vibe Coding Revolution: Developing the Tokenizer

This project exemplifies the modern “vibe coding” era—where the distance between a concept and a deployed application is bridged by AI agents and seamless cloud infrastructure.

该项目的开发历程代表了范式的转变，进入了一个全新的时代：“氛围编程”（Vibe Coding）——即通过 AI 智能体和无缝云基础设施，极大地缩短从构思到上线之间的距离。

1. The Engine of Creation: Claude Code

核心创造引擎：Claude Code

The core of this project’s development was driven by Claude Code, Anthropic’s high-agency command-line tool. Unlike traditional chat-based AI assistants, Claude Code operates directly within the developer’s terminal. In the case of the tokenizer-webapp, the developer acted as a “Product Manager,” describing the desired “vibe”—a fast, clean interface that visualizes how LLMs break down text into tokens—while Claude handled the implementation.

该项目的开发核心是由 Claude Code 驱动的。与传统的聊天式 AI 助手不同，Claude Code 直接在开发者的终端中运行。在开发过程中，开发者更像是一位“产品经理”，负责描述预期的“氛围”——即一个简洁、快速、能直观展示大模型如何将文本拆分为 Token 的界面——而 Claude 则负责处理具体的代码实现。

Because the app involves specific libraries like tiktoken or Hugging Face’s transformers, the development benefited from Claude Code’s ability to “think” in terminal commands—initializing Next.js projects, installing npm packages, and troubleshooting environment quirks. This loop of high-level intent followed by agent execution is the hallmark of the vibe coding movement.

由于该应用涉及特定领域的库（如 tiktoken 或 Hugging Face 的 transformers），开发过程充分利用了 Claude Code 的终端操作能力。它能自动初始化 Next.js 项目、安装必要的 npm 包，并解决技术挑战。这种由开发者提供意图、智能体负责执行的迭代闭环，正是“氛围编程”的核心特征。

2. Infrastructure as an Afterthought: Railway

被简化到极致的基础设施：Railway

A key bottleneck in vibe coding is the “Now what?” moment—moving code from a local machine to the internet. For this project, Railway served as the frictionless bridge to production. By linking the GitHub repository (zedware/tokenizer_webapp) to Railway, the deployment was automated.

对于“氛围编程”而言，主要的瓶颈往往在于如何将本地代码发布到互联网上。在这个项目中，Railway 成为了通往生产环境的顺畅桥梁。通过将 GitHub 仓库与 Railway 项目关联，部署过程实现了完全自动化。

The developer could even prompt Claude Code to “deploy to Railway,” triggering the AI to use the Railway CLI to provision the environment, set up internal networking (like tokenizer-webapp.railway.internal), and generate the public domain at tokenizerwebapp-production.up.railway.app.

在工作流中，开发者甚至可以直接要求 Claude Code “将其部署到 Railway”，从而触发 AI 调用 Railway CLI 来配置环境、设置内部网络并生成面向公众的域名。

3. The Result: A Production-Ready Utility

最终成果：生产级的实用工具

The resulting application is a functional tool providing immediate value, allowing users to see a real-time breakdown of text into IDs and tokens—a crucial task for LLM developers. It demonstrates that the barriers to entry for creating specialized tools are collapsing.

最终生成的应用是一个具有实际功能的工具，用户访问时可以实时看到文本被拆解为 ID 和 Token 的过程。这证明了创建专业工具的门槛正在迅速降低。

When you combine Claude Code’s linguistic reasoning with Railway’s operational simplicity, the focus shifts from “How do I build this?” to “What is the best way to solve this problem?” The tokenizer-webapp is a testament to this new era of high-velocity, intent-driven development.

当 Claude Code 的语言推理能力与 Railway 的运维简易性相结合时，开发的重心便从“我该如何构建它？”转移到了“解决这个问题的最佳方案是什么？”。tokenizer-webapp 正是这一高效、意图驱动的开发新时代的有力见证。

数据库系统作为重要的软件基础设施，即便时髦如大模型领域的公司，在训练和推理等业务中也都不可避免的要使用它。正如大模型自己会产生幻觉，在大模型如日中天的今日，人类也容易产生幻觉——要么认为数据库系统不再重要，要么认为大模型公司在使用数据库系统方面也很专业。首先，大模型的训练过程需要用处理多模态的各种数据，会用到各种通用或专用的数据库系统，来做数据的采集、加工和查询等（也就是 AI 数据工程）。当然，我们也得注意，这里主要用的是各种分析型数据库系统（OLAP、大数据系统、Python+Ray 等），并非传统的事务型数据库（OLTP）。其次，大模型公司在提供推理服务时也需要用数据库来管理用户注册、账户和会话等，这里用到的则主要是事务型数据库（OLTP）。要了解大模型公司对数据库的使用及其专业水平，需要大模型公司的员工来透露他们是如何使用数据库的。

OpenAI

大约三周前的 2026-01-22 日，OpenAI 的员工在其官网发布了这篇文章《Scaling PostgreSQL to power 800 million ChatGPT users》（https://openai.com/index/scaling-postgresql）。仅从标题看，OpenAI 利用 PostgreSQL 支撑起了全球的 8 亿 ChatGPT 用户，很了不起。一时间，网上相关的讨论火爆异常，很多人都说这是 OpenAI 和 PostgreSQL 非常强大的证明。文中也说”with a single primary Azure PostgreSQL flexible server instance⁠ and nearly 50 read replicas spread over multiple regions globally”，那就是说它用了大约一主五十备实现了横向的扩展。

仔细读完整篇文章，我们就会发现：

1. 与业界尤其是互联网领域数据库与业务快速发展的演进类似，OpenAI 也是随着业务发展在逐步演进其数据库基础设施。

2. PostgreSQL 数据库也出现过一些过载导致的故障，例如上层 Cache 失效导致数据库被打爆，多表连接吃完 CPU，或业务新上的特性引起写风暴。然后就是业界熟悉的恶性循环：过载引起业务重试，重试又加大负载，最终导致 ChatGPT 和 API 服务降级。

3. PostgreSQL 的一主多备适合读多写少的业务负载，写如果太多的话，PostgreSQL 的行级多版本（MVCC）容易导致过度的写放大，读也会因为扫描更多的行被放大。长期运行必然会遇到臭名昭著的 VACUUM 问题。

4. OpenAI 也得重走大家的老路，把写负载逐步从 PostgreSQL 剥离到更容易横向扩展的 NoSQL 数据库（Azure CosmosDB）。PostgreSQL 中甚至不允许再建新表了。

5. 业务的强事务要求依赖了一主多备的 PostgreSQL，要改造成分库分表的 PostgreSQL 或别的方案也没那么容易。不过既然现有方案能用，就继续撑到搞不定为止。

文章后面详细介绍了 OpenAI 是怎么结合业务来演进 PostgreSQL，支撑业务发展直到八百万级别的 QPS。下面这些场景和措施，互联网与云计算的专业人员估计都很熟悉：

1. PostgreSQL 从一主一备拓展到一主多备，完成横向的读写分离，达成横向扩展及减小单点故障的影响范围。

2. PostgreSQL 从一主多备直接复制试图拓展到级联复制，达成主备时延和负载均衡等的综合平衡。

3. 数据库团队与上层业务团队密切配合，做好表结构设计和复杂 SQL 查询的设计等。

4. 数据库团队与上层业务团队密切配合，增加连接池、Cache 缓存，做好 SQL 分流、SQL 限流、监控和切换预案等。

5. 实在没法扩展的写业务要么与上层业务配合迁移到扩展性更强的 NoSQL，要么寻求分库分表的 Sharding 方案。

Cursor

斯坦福大学的 CS153 课程有不少搞云计算基础设施的人比较喜欢关注的主题，例如，大约一年前的 2025 年 3 月，它发布了 Cursor 公司 CTO 的访谈视频《Standford CS 153: Infra@Scale - Cursor CTO & Co-Founder Sualeh Asif》（https://youtu.be/4jDQi9P9UIw?si=Sfb1HVg_o7MKTKfW）。恰巧其中也提到了 Cursor 公司使用 RDS PostgreSQL 的经验教训。推测他们之前没有什么工业界使用数据库的经验，凭着学校课程学到的知识做出了最初的数据库选型和设计。视频访谈中涉及 PostgreSQL 的部分大致总结如下：

1. Cursor 的主要功能是大模型辅助软件开发，需要动态跟踪维护代码仓中的文件和目录变化，这是通过计算文件或目录的 Hash 值实现的。

2. 他们在数据库中弄了个巨大的表，来保存这些 Hash 值。整个数据库大小为 22TiB，但是这个巨大的表就占了 20TiB。

3. 他们居然还在数据库中定义了外键，那个巨大的表偏偏又需要频繁更新，于是更容易触发 Postgres 中臭名昭著的 VACUUM 问题。

4. 听起来他们也没有评估过 Aurora PostgreSQL 或其他 OLTP 数据库。

5. 搞出严重故障之后出现了个救火英雄，直接基于 S3 新写了个系统把 PostgreSQL 给替换了。

这种特殊的频繁更新负载还是需要认真评估选型，单个数据库实例通常都搞不定。

如果说这些大模型领域的新兴公司的案例对我们有什么启示，那应该是：

1. 专业的事情要交给专业的人来干，除非你有钱有人，可以任性，不怕试错。

2. 对于互联网类的业务负载来说，数据库系统（尤其是 OLTP 系统）不能盲目选型，选型要慎重，一旦沾上就不容易切换。😂

3. 底层基础设施要与上层业务系统紧密配合，做好全栈的技术演进和合作，而不是互相之间泾渭分明，整天想着免责甚至甩锅。

人类喜欢做阶段总结，这不，各路神仙都有自己的 2025 年度总结了。例如：Andrej Karpathy 的 2025 LLM year in review，https://karpathy.bearblog.dev/year-in-review-2025/，Andy Pavlo 的 Data 2025: The year in review with Mike Stonebraker & Andy Pavlo，https://www.dbos.dev/webcast-2025-in-review-with-mike-stonebraker-and-andy-pavlo 等。神仙们的总结自然很好，凡人的总结也不可或缺。我们先吸收点神仙的能量来壮壮胆。需要声明的是，以下大多数是我的总结和发挥，不代表神仙们的原始意见。

Andrej Karpathy 和 Andy Pavlo 的共同特点是愿意花很多时间做教学科普视频，不过前者更难能可贵，而后者本来就是网红教授。Andrej 说 2025 年大模型行业最重要的是六大技术要点：

1. Reinforcement Learning from Verifiable Rewards (RLVR)，从之前的 Pretraining、Supervised Finetuning、Reinforcement Learning from Human Feedback 进化而来。

2. Ghosts vs. Animals / Jagged Intelligence，人类智能是为了生存而进行的生物进化，大模型像个考试或 Benchmarking 选手。所以，尽信榜则不如无榜。这么搞不像是 AGI 通用人工智能应该有的样子。

3. Cursor / new layer of LLM apps，LLM 公司自然想把一切都做到模型或模型服务里头，但是 Cursor 的成功说明应用可能大有可为，仅仅有 Chat 界面或 SDK 的大模型，没法适应人民群众日益增长的需要和无穷的创造力。

4. Claude Code / AI that lives on your computer，Code 是 Agent 的典型代表，把更多的功能放到了本地机器，结合本地上下文、工具调用和理解，可以做更多有实际意义的工作。这是为啥业界炒 Agent 元年的动力之一。

5. Vibe coding，Andrej 发明的这个词很快流行起来。通过自然语言普通人就能实现一定程度的编程，这确实是技术平民化、普及化的重大时刻。即使是我们这些专业技术人员，也有很多不熟悉的语言和工具，通过大模型也可以很快写出一次性的脚本。也许哪一天我们真的可以为每个任务搭积木、定制个数据库系统。

6. Nano banana / LLM GUI，谷歌 Gemini 的 Nano banana 是本年度最有意思的发布，它给大模型带来了图形用户界面 GUI。大模型的聊天窗口还主要是文本，类似计算机早期的命令行界面 CLI。未来的界面应该更像图形界面，提供多模态接口，才符合普罗大众的需求。我的文章封面大部分是 Nano 生成的。

相比之下，数据领域的发展就没有大模型这么激动人心了。但是社会的发展还是需要数据领域的从业者们踏踏实实工作，毕竟数据是一切的基础，要避免 Garbage In，Garbage Out，守住人类的底线。

Andy Pavlo 这次把数据库领域的祖师爷、Postgres 之父、图灵奖得主 Mike Stonebraker 也搞来直播来了。这师徒俩一个扮演比较保守的角色，一个扮演比较激进的角色。读书的时候，教授告诉我：When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong。所以我时时想起这句话，来提醒自己。

Andy 比较八卦，说了些公开或没那么公开的收购、合并、关闭等。不过，看起来比之前要谨慎一些了。大家都熟悉的可能是 Databricks 十亿美金收购 Neon 并且以 Lakebase 的名字发布新产品，最近其官方博客上也有个 Holiday Update 的产品发布。看起来对开源的投入再明显减少，可能是在尽全力整合产品。

2025 年，PostgreSQL 大火，Neon、Crunchy、Supabase 等很多基于它的系统被收购或投资。仿佛时间回到了 200X 年，不过那时国际上是 Greenplum、AsterData 等等一堆基于 Postgres 的 OLAP 系统；国内则是一堆基于 Postgres 的 OLTP 系统。估计这也是 Andy 这次把 Mike 老爷子请出来的原因吧。Mike 现在又搞了个公司 DBOS，要为未来的世界做一个基于 Database 的 OS。

在号称 Agent 元年的今天，不谈 Agents 未免有些 Out 了。最近的 AWS 年度大会 re:Invent 2025 上，其 CTO，著名的大个头荷兰人， Werner Hans Peter Vogels 都宣布这是他最后一次大会演讲，将把机会让给年轻人，并在最后宣布“Werner Out”！Agents 在最近确实很火，也在某些领域获得一些应用。不过，估计要像传统 MIS 应用、Web 应用、移动 App 那么成熟还为时过早。这也给大家做大模型、应用框架、应用工具，甚至数据基础设施的公司和团队带来了新的机会。

无论是从 Google 还是 AWS 发布的 Agents 系列服务来看，围绕 Agents 的核心组件包括：SDK、Framework、Memory、Runtime，当然也少不了 MCP Server、Browser Tool 等。还有一个容易被忽视但极端重要的基础设施，就是 Agent 的全栈监控以及对应的问题诊断分析（Observability）。Agent Ops 背后对应的是可观测数据库及分析系统，现有的可观测性数据系统包括 InfluxDB、Datadog 等，它们也需要为 Agents 改进。从数据系统的角度看，记忆系统（Memory System）显得比较突出和重要，但实际上其背后存放数据的仍然大多是已有的各种数据库系统。如果要更好的服务于 Agent 应用，避免操作一大堆不同的数据库系统，Databricks Neon 等可能是潜在的更好选择。

其实，如果只是做个 Demo 系统，选择的方式可能是哪个容易上手、怎么方便怎么来，别说 Postgres，就算是 SQLite，甚至 DuckDB 都可能够用。当然也有些另类系统，如 Turso，它是用 Rust 写的兼容 SQLite 的小型数据库系统。正经的线上系统还是需要选择成熟的云服务。

此外，MCP 后面可以对接现有的各种数据库系统。所以，从封面或类似的图中看起来，数据库都成了幕后的基础设施。那么，在 Agents 应用时代，数据系统是否也 Out 了呢？如果我们稍为研究一下历史，就会发现以数据库系统为代表的数据系统从来就没有被替代，只不过它们不在聚光灯下而已。

封面的图片是大模型生成的，还不是很靠谱，请勿直接采信。

众所周知，大模型的训练（Training）和推理（Inferencing）是两个截然不同的阶段。大模型的训练与现有的其他系统都明显不同，大模型的推理系统及其服务化则与现有的其他系统更相似一些。推理服务既然是个系统，那么它需要考虑响应时间、吞吐量、资源利用率等常见的系统类指标。从响应时间角度看，推理系统中最基础的指标包括首 Token 时延（TTFT，Time To First Token）、输出 Token 时延（TPOT，Time Per Output Token）等。TTFT 对应于推理服务的 Prefill 阶段，TPOT 对应于推理服务的 Decode 阶段，这是 Transformer 大模型结构计算 Attention 以及一次一 Token 输出的特点决定的。实际上，很多交互式的系统都存在类似 Prefill 和 Decode 阶段（数据库领域喜欢说启动成本高），只不过没有大模型的推理服务这么明显。例如，在数据库中发起一个交互式 SQL 查询后，到系统返回第一条记录一般也会需要较长的时间，其后的记录很多时候可以流式的连续输出。

以数据库为代表的传统系统是运行在 CPU 上的，可以采用多进程、多线程、数据缓存、计划缓存、结果集缓存、批处理等等各种技术手段，来优化响应时间、吞吐量和资源利用率等系统指标。可是大模型是运行在 GPU（或其他各种非 CPU 芯片上）上的，需要适应 GPU 编程的特点和约束；例如，它没法做到类似 CPU 的多线程调度。大模型最基本的优化包括批处理，也就是同时处理多个 Prompt 的推理，要采取各种技巧把显存填满并且减少无效的计算。简单粗暴的把不同长度的 Prompt 按照最长的对齐显然不是高效的做法，因此需要利用 Transformer 结构中 Attention 计算的特点做 Chunked Prefill 等。系统一旦运行起来，大量会话的 Prefill 和 Decode 会同时存在，因此把 Prefill 与 Decode 批量摆到一起做计算也是必须的优化。此外，在一个大规模的服务中，把 Prefill 与 Decode 分开部署也是架构上自然的一类演进。批处理的另外一些优化思路是缓存，例如把同样的 Prompt 对应的推理结果给缓存起来，以存代算。大模型推理服务中存在大量重复的 System Prompt，会话过程中也存在很多重复的其他 Prompt 前缀。实际上，Attention 计算过程中也有很多重复的计算，这些都可以通过 KV Cache 缓存来加速。Cache 机制非常类似于传统系统的类似机制，只不过它主要存放在显存内。如果显存不够大，自然的想法是把它们分级，存放一部分到内存，甚至未来还可以放到其他介质分层中去。大模型的训练过程中存在很多通信路径需要优化，在推理过程中也存在一些通信路径可以优化。典型的情况包括 Prefill 与 Decode 分离之后的 KV Cache 如何跨卡或跨节点快速传输复用等。vLLM 等开源框架已经实现了上述的很多优化技术点。

反过来，如果数据库系统需要跑在 GPU 上，也得遵循硬件的限制，从大模型系统上借鉴一些解决思路和技巧；学术界和工业界也一直有各种尝试。从宏观架构上考虑，数据库要跑在 GPU 上还面临几个实际的约束。首先，AI 芯片并没有多少能够腾出来跑非 AI 的负载，毕竟当前其价格仍然不菲，拿来跑数据库非常不划算。能够拿来跑数据库或其他负载的应该是被淘汰或闲置的旧卡，做点废物利用。其次，AI 芯片的很大一部分浮点数算力，例如 FP16、FP8，不适合拿来跑非 AI 负载，因为这些系统要的至少是 FP64、FP32。最后，很多非 AI 负载需要频繁从内外存读写数据。将数据一次性加载到 GPU 上，然后疯狂的进行计算的场景还不太多。从这个意义上看，将 CPU、GPU 封装到一起，统一内外存访问的模式可能更容易促进传统负载与 AI 负载的结合。

人工智能领域要处理的数据除了结构化数据和半结构化数据之外，更多的是非结构化数据。传统数据库最擅长结构化数据处理，半结构化数据就有点勉强，非结构化数据就更捉襟见肘了。从机器学习到现在的大模型训练，日常的数据处理中，人工智能领域更多的是用 Python 等写程序，发展出了各种函数库或框架来方便数据处理。DuckDB 应该算是数据库领域想要发挥自身强项的典型案例，希望通过简单易用的 SQL 语言和高性能的系统实现来加快日常的数据处理。在大规模的结构化和半结 构化数据处理领域，大数据系统、数据仓库系统、数据湖系统等发挥了更重要的作用。

面对多模态数据分析的挑战，数据领域中最自然的想法是增强或设计新的数据湖等系统，将非结构化数据的处理做得更好，甚至能够在一套系统中处理包括文本、图像、声音、视频等在内所有的数据。于是架构师们要解决的仍然是传统的几大问题：1. 数据存储（存到哪）2. 数据格式（怎么存） 3. 数据查询（怎么算）。从大规模数据处理的角度看，数据存储没得选，优先对象存储。从大规模数据处理生态的角度看，数据格式也好办，优先开源开放格式，不然没法互联互通。数据查询处理除了大规模并行计算外，还得实现各种多模态算子，引入新的代价模型和查询优化技术。从系统部署运行监控的角度看，运行环境（优先容器或轻量级虚拟机），处理器芯片（CPU、NPU、GPU 等），运维监控系统（优先介入现有系统）等都需要选择。

除了大规模数据处理需要多模态数据分析之外，日常不那么大的数据处理也将需要多模态数据分析。例如每个人的手机、平板、笔记本、PC 设备中都存有大量的多模态数据，也应该把它们深入整合起来，做出更易用的查询分析应用。

然而，多模态数据分析处理与传统的大数据处理存在明显的差异。一条结构化数据没多少个字节，用 CPU 处理起来非常快也很经济。一条非结构化数据往往是一个很大的文件，用 GPU 处理也没那么快。这两种数据放到一条数据库记录中同时处理时，显然是后者要占用更多的资源和时间。服务器中 CPU 与 GPU 的配比也很难完美匹配这两种不同的负载，数据除了跨卡流动还得跨机器流动。即便是相对简单的多摸数据向量化（Embedding）后做相似性检索，批量和增量数据 Embedding 做向量化也很慢。因此，我们可以合理推断，多模态数据分析系统要先解决好少量多摸数据的问题，才有机会去解决海量多摸数据的问题。

在某个领域做久的人，容易看什么都带着本领域的习惯，数据系统领域的人也不例外。数据库领域推崇以声明式（Declarative）语言取代命令式（Imperative）语言，把简单带给用户，把复杂留给自己。SQL 语言就是前者的典型代表，也获得了巨大的成功。SQL 语言最初实际是简化的英文自然语言，目标想让商业用户也能够方便的查询和处理数据。如果遵循这样的思路来反思，今天的 SQL 语言其实过于复杂，以至于可以说是忘掉了初衷附录 1。在人工智能时代，大模型（LLM）的接口正好是原生的自然语言。用户可以用自己熟悉的某种自然语言（例如母语），甚至混合多种自然语言（和程序语言）来与大模型对话。

那么问题来了。如果大模型的自然语言接口能够取代 SQL，那数据库系统岂不是要寿终正寝了？其实不然，数据库系统擅长处理的是海量数据的精确查询和严格的 ACID（Atomicity、Consistentcy、Isolation、Durability）事务保证；大模型天生擅长处理不那么精确的任务，结果具有随机性（Stochastic），同一个问题问它两遍都可能会给出不同的结果。按照这个思路，正如大模型需要调用计算器等程序来处理准确的计算附录 2，它也应该调用数据库系统来干后者更适合干的事情。我们必须要承认，人类世界要处理的精确任务远没有非精确的任务多；数据库系统擅长处理的结构化数据也远没有非结构化数据多。

既然大模型可以调用其他系统作为工具，为什么不能反过来，这些系统也把大模型当作工具调用？在数据处理领域，确实也有很多类似的做法。很多数据库通过用户自定义函数（UDF）来调用大模型的 API 接口，将表中的数据作为参数传给大模型，做情感分析、文本摘要、图片识别等各种操作；还有一些系统在 SQL 中扩展更多的操作，例如带语义比较的连接（JOIN）；也有一些系统直接在 Python 中仿照 Pandas、SQL 等扩展类似的语义操作。也许我们现在给人类程序员设计的这些语言最终都会变成 AI 来调用。

无论数据库系统与大模型怎么结合，二者之间都存在多种不匹配（也许按照数据库领域的说法，要叫做阻抗不匹配）。首先，语义算子的处理是非精确的，它与传统算子谁先算、谁后算对最终结果会有影响。此外，在怀疑结果出问题的时候，怎么复现和定位分析？其次，相对于传统算子而言，大部分情况下语义算子的处理是很慢的。数据处理任务可能做不到人类期望的交互式响应，而会变成批处理。第三，查询代价估计和查询优化在这种情况下是否还能工作？

附录 1：TPC-DS Benchmark 中的一个查询示例，估计大部分人没法一眼就看懂。

附录 2：Google Gemini 2.5 Pro 用 Live chat 还数不对 Strawberry 中字母 R 的个数

Data+AI 时代是否需要数据库系统做出改变，甚至设计全新的系统？前者的答案是肯定的，但是后者的答案暂时还不知道。我们可以结合当前的情况做出一些分析。

首先，Agents 应用爆发，与传统的数据应用在操作模式上存在本质的区别，它需要数据库系统更好的支持。例如数据库系统需要支持向量检索，也需要支持 Agents 比人更多更快的访问。此外，Agents 目前的工作方式存在很多试探性操作，包括对数据和元数据一次性发出一堆类似的查询、甚至对数据库做尝试性修改，所以 Databricks Lakebase 也支持类似 Git 的分支管理能力。Agents 的试错模式类似于传统应用开发过程中的开发和测试环境。不过后者一般只需要复制少数几套环境（包括数据库）用于开发测试，不像 Agents 有可能会搞出大量的试错分支。

其次，Agents 应用依赖对大模型的调用。为了解决大模型上下文窗口不够长、外部知识无法及时更新、个性化以及在团队中共享知识等问题，需要数据系统实现对记忆的管理。记忆系统会成为一种新的数据系统形态，还是会在现有的各种数据系统之上成为一种中间件？很多现有系统实际上是当作中间件在实现，负责记忆的提取、增删改查等操作，实际数据的管理还是借助底下现有的数据系统来解决。

第三，Agents 应用、大模型、各种 Agents 开发框架等都需要可观测性管理。Agents 应用涉及多步骤、动态的、多 Agents、多系统的交互，加上大模型结果的不确定性，更需要端到端的可观测性管理来记录、分析和诊断。从数据库系统的角度看，当前的可观测性数据库需要能够适应 Agents 的新需求，例如更多样的数据、更多的 Trace、更复杂的查询分析等。

Berkeley 的研究者发布了《Supporting Our AI Overlords: Redesigning Data Systems to be Agent-First》，https://arxiv.org/pdf/2509.00997，背后更多的是类似 Databricks Lakebase 等的思路。Google 最近与 Kaggle 合作做了个 5 天的 Agents 应用开发课程《5-Day AI Agents Intensive Course with Google》，https://www.kaggle.com/learn-guide/5-day-agents，非常适合从应用角度来观察 Agents 开发过程中涉及的各种软件。总之，面对人工智能带来的巨大变化，数据系统领域需要积极拥抱变化，及时做出适应和改变。