Jimmy Song – 博客

写在 HAMi 晋升 CNCF Incubating 之后：AI 时代，开源社区正在从代码共同体走向共识网络

Jimmy Song — Wed, 08 Jul 2026 13:56:17 +0000

HAMi 晋升 CNCF Incubating 之后，我更想聊一件被忽略的事：AI 正在把开源社区的稀缺资源，从代码变成共识。

2026 年 7 月 2 日，HAMi 正式晋升 CNCF Incubating 项目（参见 HAMi 的公告）。对一个开源项目来说，这不仅意味着技术能力获得认可，更意味着社区治理、生态建设和真实采用都进了一个新阶段。

但如果你只把 HAMi 的成长理解成“一个 GPU 虚拟化项目成功了”，可能就错过了更重要的变化。

我参与 HAMi 社区建设这段时间，有一个感受越来越强烈：AI 正在改变开源社区的基本生产方式。当 AI Coding 让代码的生产成本不断下降，未来开源项目竞争的核心，将不再是谁写了最多代码，而是谁能建立更强的技术共识、吸引更多贡献者、形成可持续的生态网络。

这篇文章想把这个判断讲清楚。

图 9: 恭喜 HAMi 晋升 CNCF Incubating

HAMi 的成长数据说明：开源项目真正的资产是社区

图 10: HAMi 社区贡献者地图，贡献者来自 27 个国家

先放数据，HAMi 目前是这样的：

指标	数值
GitHub Star	超过 3700
贡献者	来自 27 个国家、近 500 位
参与组织	多家，持续增长
版本发布节奏	每三个月一次

表 3: HAMi 社区关键指标（截至 2026 年 7 月）

把这些数字放在一起，不是想秀“增长指标”。我想说的是另一件事：一个开源项目正在从“某个团队维护的软件”，变成“一群人为了共同目标聚在一起的技术社区”。

这个区别很关键。软件可以被 fork，可以被重写，可以被 AI 一夜生成出来；但一个有共同目标、有信任、有节奏的社区，没法被 fork。这才是开源项目真正不可替代的资产。

从治理成熟度的角度看，HAMi 走过了三个节点：

图 11: HAMi 治理成熟度演进

注意中间这段：从 2024 年 8 月进入 Sandbox，到 2026 年 7 月晋升 Incubating，差不多两年。这两年里，代码当然在增长，但真正让 CNCF 技术监督委员会（TOC）认可的，是社区的多元化、治理的规范化、以及真实生产采用的落地。这些东西，都不是靠写代码写出来的。

2021 年 HAMi 开源的时候，还没有 AI Coding

HAMi 最早开源于 2021 年。那时候，大多数开发者对 AI Coding 还没有今天这样的认知。一个开源项目能不能活下去，靠的是开发者真实投入时间，在 Issue 里讨论问题，用 Pull Request 提交代码，通过 Code Review 建立信任。

今天，环境变了。

在最近的一次 HAMi 社区直播里（玩转 HAMi DRA | 杨守仁 | HAMi 社区直播第二期），有人问了维护者一个问题：“现在 HAMi 的代码里，有多少来自 AI 辅助？”

杨守仁的回答让我印象很深：目前 HAMi 社区大约已经有一半代码由 AI 辅助生成。

一半。这个比例还在涨。

这马上带出一个尖锐的问题：如果 AI 能写越来越多的代码，那开源社区存在的价值到底是什么？是不是以后一个人加上几个 AI Agent，就能 fork 出一个“新 HAMi”？

我的答案是：不能。因为 AI 降低的是代码生产成本，不是技术共识成本。

AI 时代，代码不稀缺了，稀缺的是共识

这句话我想说得再锋利一点。

一个 AI Agent 今天能做的事已经很多：写代码、修 Bug、补测试、生成文档、写迁移脚本。这些能力还在快速变强。但社区里有几件事，AI 目前替代不了，我判断短期内也替代不了。

第一，判断什么问题值得解决。

拿 HAMi 来说，GPU 共享为什么重要？不是因为“把卡切细”这个技术很酷。而是因为 AI 基础设施进入规模化之后，现实变成了这样：GPU 成本巨大，异构硬件越来越多，Kubernetes 原生的资源模型不够用了。

社区需要先共同认可“这个问题值得投入”，才谈得上写代码。这个认可，是人和人之间的事，需要真实场景、真实成本、真实痛点来支撑。AI 可以帮你解决一个已经被定义好的问题，但“什么问题值得定义”，靠的是社区共识。

第二，技术路线的选择。

GPU 虚拟化这个领域，路线很多：MIG、MPS、Time-slicing、vGPU、DRA。每条路线都有取舍，选错了可能要走两年弯路。

代码可以生成，但架构选择本质是价值判断。HAMi 在昇腾 910C 上从硬件 SR-IOV 转向用户态 HAMi-core 的那条路，靠的不是某段代码写得好，而是维护者对“硬件切分太粗、软件切分更灵活”这个判断的坚持。这种判断，是社区在反复讨论、踩坑、验证里磨出来的，不是 prompt 出来的。

第三，信任。

用户选择 HAMi，不是因为“这个仓库里有多少 AI 生成的代码”。他们关心的是：谁在维护？谁在 Review？有没有真实生产案例？出了问题社区会不会响应？

这些东西，每一条都是人和人之间的关系，是社区组织能力的产物，不是代码质量的产物。

把这三点合起来看，AI 时代开源社区的生产模型正在发生变化：

图 12: AI 时代开源生产模型的变化

过去是代码在先，社区从代码里沉淀出来；未来是共识在先，AI 把共识快速变成代码，代码再回流检验共识。稀缺资源的重心，从左边的“代码”移到了右边的“共识”。

AI 时代，开源治理本身也要升级

既然 AI 成了新的贡献者类型，社区的治理规则就必须跟上。

我建议你别把 AI 只当成工具，把它看成一类新的贡献者。以前是“开发者写代码、人 Review”；未来是“人定意图、AI 生成代码、社区 Review、沉淀成共享知识”。中间多了一层，治理的复杂度也多了一层。

HAMi 已经在回应这个问题。它的 CONTRIBUTING.md 里写得很明确：

If you are using any kind of AI assistance to contribute to HAMi, it must be disclosed in the pull request.

也就是说，用 AI 辅助贡献，必须在 PR 里声明。但社区也清楚，光有规范没有门禁是不够的（见 Issue #1998 的讨论），已经在讨论怎么给这条规范加上真正的约束。

这其实是所有 AI 时代开源项目都会撞上的问题，我把它拆成几条：

AI 生成的代码，是否必须声明？
贡献者用的是哪个模型、什么上下文？
怎么保证 AI 代码的安全，避免注入和许可证风险？
Maintainer 该用什么流程去 Review 一段他自己可能看不全的 AI diff？

谁能先把这些规则想清楚、落地，谁的社区就能在 AI 时代把贡献质量稳住。HAMi 的这段探索，值得每个开源项目参考。

CNCF Incubating 的真正意义

回到这次晋升本身。

我倾向于别把它当成一个“荣誉”。CNCF Incubating 真正验证的不是代码质量，而是一个项目有没有能力成为基础设施。它考察的是一整套东西：技术成熟度、社区治理、生产采用、生态建设。

HAMi 的案例，用一句话概括，不是“中国团队做了一个 GPU 项目”，而是：

一个由全球开发者共同参与的 AI Infrastructure 社区正在形成。

前者是个产品故事，后者是个生态故事。CNCF 给出的 Incubating 认可，认可的是后者。因为基础设施的竞争，从来不是单个产品的竞争，而是生态网络的竞争。

总结

未来十年的开源竞争，不会只是代码竞争，而是社区竞争。

当 AI 让每个人都拥有接近无限的代码生产能力之后，真正稀缺的能力会变成三件事：找到正确的问题、建立技术共识、组织全球开发者共同解决问题。

HAMi 的 CNCF Incubating 之路，只是 AI 时代开源社区演进的一个缩影。代码会越来越便宜，共识会越来越贵。谁能理解这个反转，谁就能在 AI 时代把开源社区真正做厚。

加入 HAMi 社区

添加笔者微信 jimmysong，加入聚焦 GPU 虚拟化与异构算力调度的 HAMi 社区，一起聊 AI 时代的开源治理。

Olares 与 HAMi：我看到的端侧 AI 工作站新拐点

Jimmy Song — Wed, 24 Jun 2026 22:30:00 +0800

HAMi 不只在集群里省卡了，它开始在桌面上决定一台 AI 工作站好不好用。

图 1: Olares 与 HAMi：端侧 AI 工作站的一个新拐点

一个老朋友提到一个名字

前几天一位老朋友来找我聊天。我们以前一起张罗国内的云原生社区活动，算是老搭档了。她最近去了一家叫 Olares 的公司，聊着聊着提到一句：他们项目集成了 HAMi。

我平时就在运营 HAMi 社区，听到别人拿它做什么，总会想多看一眼。结果真去翻了翻 Olares 的仓库和官网，第一反应是，哎，这个有点意思。

这不就是我惦记了很久、却一直没舍得下手的那种本地 AI 工作站吗？我之前在《我的 Personal AI Stack》里聊过，对我这种主要靠脑子干活的人来说，订阅模型比养一张高端显卡实在。但“一台机器跑全套 AI”到底能做到什么程度、谁真把它做出来了，我一直想亲眼看一看。

这东西到底是个啥

Olares 不是那种“带块 GPU 的 NAS”，也不是“装了 Ollama 的小主机”。它更像一台拿 Kubernetes 当底的个人云：本地模型、应用、身份、远程访问、开发环境、存储，连 GPU 治理都打包进一台机器，做成一个端侧的云操作系统。

HAMi 在这里不是凑数的。它是把“一张卡”变成“一个能共享、能隔离、能调度的资源池”的那一层。

跟一堆 AI 小主机的区别

市面上喊着 AI 工作站的东西不少，大多是台性能强点的小主机。Olares 不太一样，它是真按一个云来设计的。

官方直接把这台机器定位成 7×24 小时跑的 personal AI cloud，不是让你坐在前面用的 PC。就这一个定位，后面的事基本都说通了：为什么非得用 Kubernetes，为什么那么在意网络穿透和远程访问，为什么 GPU 治理在这里突然变得要紧。

还有俩细节挺能说明问题：它支持 Thunderbolt 5 外接 eGPU，还能两台机器组集群。也就是说，它从一开始就不是个封闭盒子，是单机起步、能往上长的东西。

把一整个云的运行时塞进单机

架构上看，Olares 干的就是把一整套云的运行时压进单机：认证授权、应用生命周期、各种隧道穿透、密钥、可观测中间件，一层都没落下。

这不是“预装几个 AI 应用”，是一个完整的 cloud runtime 被塞进了桌面设备。

下面这张图是我照着它的公开文档重新梳理的分层，特意把 HAMi 那一层单拎出来，因为它是整篇的重点。

图 2: Olares 系统分层架构，HAMi 作为 GPU 资源平面

一个挺有意思的细节

我翻的时候注意到一件事：Olares 的文档，有点跟不上它自己的产品。

它 2025 年的架构页面还写着 nvshare，注明 GPU 只支持每节点一张卡。可翻开版本说明，1.12 就已经集成 HAMi 调度器了，独占、时间切片、显存切片三种模式都有；1.12.2 上多 GPU；1.12.5 直接支持 DGX Spark，还把自动调度铺到全部三种模式。

产品比文档跑得快。这本身就说明点东西：它正从“个人云 OS”往“本地 AI 云 OS”挪。这也是我想专门写一篇的原因。

HAMi 在里面到底干了啥

HAMi 是个 CNCF Sandbox 项目，定位是异构 AI 计算虚拟化中间件。链路上有 Webhook、调度器、Device Plugin，还有负责容器内资源控制的 HAMi-core。我之前在《Kubernetes 正在成为 AI 时代的 GPU Control Plane》里写过一句话概括它：把 GPU 切分从“硬件能力”变成“控制面的能力”。

放到 Olares 上，这就是设置里那个 GPU 模式开关背后真正的东西。表面是个 UI 选项，底下是资源平面的策略切换。

最关键的一环大概率是 HAMi-core，玩法一句话：在容器里拦住 CUDA 调用，做显存虚拟化、算力限流、利用率监控。不靠硬件切，靠软件管。

下面这张图把这条注入链路和三种 GPU 模式放一块了。

图 3: HAMi-core 注入链路与 Olares 的三种 GPU 模式

证据也对得上。Olares 的 GitHub issue 里能直接看到 HAMi 的 libvgpu.so 在 WSL2 下崩过，讨论里也有人提到它通过 /etc/ld.so.preload 注进每个进程，Olares 团队自己也说这套实现从 HAMi 项目“获得了重要启发”。

不过有件事得说清楚：Olares 到底是直接用上游的 HAMi-core，还是自己改了一版，公开资料里没有个统一说法。这地方我就不替它脑补了。

三种模式顺着就懂。整卡独占给重负载；时间切片让轻量服务轮着用，Olares 还会把不活跃的模型先换到内存里，切换大概就 5% 开销；显存切片把显存切成固定配额，让多个应用一起跑。到了 DGX Spark 那种 CPU 和 GPU 共享内存的架构，它就默认走显存切片，因为压根没有传统那种显存换入换出。

为啥我觉得这事对 HAMi 挺重要

HAMi 以前主要在大集群里转：多租户、推理服务、训练推理混部、异构卡。NIO 拿它在 80 个节点、600 张卡上做共享，就是典型。这条线已经很熟了。

Olares 让我觉得新鲜的地方是，它把同一个问题搬到了一台机器上。

图 4: HAMi 的价值叙事从集群效率迁移到端侧产品体验

你在 Olares 上真会同时跑的东西，从来不止一个 Ollama：一个本地模型，一个聊天界面，一个研究 agent，一条图像或视频链路，再加一堆 OCR、语音转写、自动化工具。这种场景要是没有 GPU 调度层，GPU 最后一定退化成“谁先起来谁占住”。

所以对 HAMi 来说，这事挺关键。它从“给平台工程师省卡的工具”，变成了“直接决定普通用户用得爽不爽”的东西。在集群里它管的是利用率和成本，在 Olares 上它管的是并发体验、模型切换、和这台机器到底好不好用。HAMi 不再只跟平台工程师打交道了。

端侧 AI 会往哪走

我的感觉是，端侧 AI 最后不会停在“一个更强的本地模型盒子”，而是会长成“控制平面加模型平面加应用平面”一整套。

NVIDIA 把 DGX Spark、RTX Spark 往桌面上推，故事已经从“本地跑模型”升级到“本地跑 agent”。Olares 这种 CUDA 加 x86 是一条路，DGX Spark 那种统一内存是一条，再往下还有 DIY 小主机加 eGPU 自己拼的。有意思的是 Olares 自己就把 eGPU 和双节点列成了支持路径，appliance 跟 DIY 之间没那么泾渭分明。

不过最后能跑出来的，我猜不是参数最猛的那家，而是能把资源治理、开发体验、应用生态、安全、远程访问捏成一整个闭环的那家。端侧 AI 工作站这个品类要是真能立住，最后拼的不是 GPU 和内存，是控制平面。

顺手把 Olares 收进了我自己维护的 AI Native Landscape，往后好接着看它怎么长。

总结

一句话：Olares 是一台以 Kubernetes 为内核的端侧 AI 操作系统，HAMi 是它把单机 GPU 变成可共享、可隔离、可调度资源池的那一层。

从集群到桌面，HAMi 的故事正从“省卡”往“让端侧 AI 好用”扩。端侧 AI 工作站要是真成一个品类，最后拼的是控制平面，不是单卡性能。

参考文献

每个民族都从纺织开始

Jimmy Song — Sat, 20 Jun 2026 05:41:06 +0000

在安吉的竹编工坊里，我捏着一根劈得极细的竹篾，第一次意识到：原来一匹布、一台机器、一个国家，都是从手里这一根线开始的。

图 1: 竹篾

引言

这件事我想了很久，一直没理清楚。

今年 2 月，公司团建去了浙江安吉。那是中国有名的竹乡，满山都是毛竹，当地人世世代代拿竹子编东西，竹编是国家级非遗。团建安排了一个手工环节，让大家去体验一回。

我对这种“体验式活动”本来没抱太大期待。可真坐下来、拿起竹篾，听老师傅讲怎么挑、怎么压、怎么抬，我突然有点走神。一上一下，一抬一压，经线和纬线在他手里交织，慢慢就成了一片图案。那个动作重复性极强，节奏固定，逻辑清楚。

那一刻我脑子里冒出一个有点离谱的念头：这不就是 0 和 1 吗。

图 2: 在安吉编好的一匹竹编红马，装裱起来

经线抬起是 1，压下是 0。一块织物展开，就是一个由 0 和 1 组成的二维结构。而老师傅嘴里反复念叨的“花本”，也就是预先设计好的一套挑经顺序，本质上就是一段程序：你照着它织，就能织出想要的图案。

这个念头当时一闪而过，我没太当回事。可紧接着 3 月，我又去了一趟荷兰，在阿姆斯特丹待了七天。两件事凑在一起，有些原本模糊的感觉慢慢就清晰了：一根竹篾、一个动作，怎么会和两百年前的织布机、和今天的计算机、甚至和一个国家的工业化，都连得上。

我后来查了资料，发现这个联想并不是我第一个有的，很多技术史学者都认为编织是人类最早的大规模信息编码方式之一。现在 6 月，我坐下来，想把这条线试着理一理。它不是技术文章，是一点个人的、文化的思考。

一次文化的对照

先说荷兰那一趟。

图 3: 阿姆斯特丹市区的运河和教堂

那个国家给我最深的印象，不是风车，不是郁金香，而是它整个国家散发出来的一种气质：克制、有秩序、而且非常“工程”。运河是挖出来的，围海造出来的田叫“圩田”，风车最早不是为了好看，是为了抽水排涝。不过风车之所以那么多，也不全是为了排水，荷兰的风确实大，3 月我在那儿被吹得够呛，那种风是持续不断地推着你走。一个低于海平面的国家，硬是用工程把自己从海里捞了出来，顺便也把那股大风用了起来。

图 4: 风车村 Zaanse Schans 的风车

这种气质渗透到日常的每一个角落。下午六点商场就关门，街上慢慢安静下来，几乎听不到喇叭声，汽车会远远停下来等人。有次晚上我走得离自行车道近了一点，路过的一辆车还特意降下窗户提醒我走人行道。我当时有点意外，后来才反应过来：那里的规则是清楚的，而且大家默认你也该遵守。

图 5: 阿姆斯特丹南郊的街道，路宽，家家有车，骑车的人依然很多

这种气质甚至体现在出行方式上。在市区，开车的人其实不多，自行车才是主流。一来荷兰地势平坦，骑车不费劲；二来专门的自行车道修得到处都是，街道又窄，反而不太适合开车；再加上大家上班的距离普遍不远，骑车刚好。有意思的是，哪怕到了南郊这种路宽、家家户户有车的地方，骑车的人依然很多。自行车对他们来说不是运动，是默认的通勤方式。

我把它和国内的喧闹、速度、大红大绿的招牌放在一起想。这两种气质，其实是两种现代化的路径。荷兰是那种早期的、慢工出细活的国家，从大航海时代到第一个证券交易所，从水利工程到今天的 ASML（阿斯麦）和 Philips（飞利浦），它一直在用“长期、克制、系统”的方式往前走。而中国是后发的追赶者，靠速度、靠规模、靠一代人的拼命，在几十年里跑完了别人几百年的路。

这两种路径没有谁高谁低，但它们会沉淀成完全不同的城市质感，和完全不同的民族性格。荷兰那种“6 点就关门”的从容，中国还要很多年才学得来；而中国那种说干就干、一夜之间修起一条高铁的速度，荷兰大概也做不到。

但有意思的是，如果你顺着历史再往前追，这两种看似迥异的文明，居然有一个共同的起点。那就是纺织。

纺织为什么是工业化的起点

我们这代人，对“工业革命”这个词太熟了，熟到有点麻木。但你想过没有，第一次工业革命最先爆发在哪里？不是钢铁，不是煤炭，不是铁路，而是纺织。

英国的工业革命，几乎就是一部纺织机的发明史。1733 年发明飞梭，织布变快；1764 年发明珍妮纺纱机，一个人能同时纺多根纱；1769 年发明水力纺纱机，机器开始取代人力；1785 年发明动力织布机，自动织布成为现实。这一连串发明，都是在纺织业里发生的。

为什么偏偏是纺织？我一开始也觉得这事有点反直觉，毕竟纺织看起来太“轻”了，不像炼钢造炮那么有力量感。但稍微想想就明白了。

纺织是刚需。每个人都得穿衣服，衣服会磨损，得不停补，这是从农业社会就存在的巨大市场。需求一旦有了，效率的提升就能立刻变成利润，变成继续投入的资本。

更重要的是，纺织的工序特别容易被机械化。纺纱、织布，这两个动作重复性极强、节奏固定，逻辑清楚，机器能直接替代人手。相比之下，炼钢的技术门槛高得多，化工的科学体系当时还没成熟，机械制造本身又得先有工业基础才能起步。

而且纺织的投资门槛适中。建一个纺织厂，比建炼钢厂便宜太多，商人资本、殖民贸易赚来的钱，很容易就能流进来。英国早期工业资本，很大一部分就是从棉花贸易和殖民贸易里来的，而这些钱首先投向的就是纺织厂。

最关键的一点是，纺织业不是孤立的，它会拉动一整条产业链。要纺纱织布，得先种棉花、运棉花；要用机器，得造纺织机械；要驱动机器，得用蒸汽机；蒸汽机要烧煤，得挖煤；棉花和布匹要运，得修铁路。于是蒸汽机最早大规模应用在纺织厂，铁路最早用来运棉花和布匹，机械制造业最早是为纺织设备服务的。一个看起来很“轻”的行业，硬是把机械工业和能源工业都给催了出来。

所以纺织业并不是因为“最复杂”才成为工业的鼻祖，而是因为它最早同时满足了四个条件：需求大、能机械化、门槛低、能带动别人。它是人类从手工业跨进工业体系的第一块试验田。

后发国家都从这条路上来

这里有一个我以前没想过的规律：后发国家的工业化，几乎无一例外，都从纺织开始。

看看日本。今天你一提到日本工业，想到的是丰田汽车。但丰田怎么起家的？丰田的创始人叫丰田佐吉，他最早不是造车的，是发明自动织布机的。1924 年他发明了 G 型自动织机，1926 年成立丰田自动织机制作所，这是整个丰田集团的起点。他儿子丰田喜一郎后来才把业务转向汽车。

所以丰田汽车，是“从织布机里长出来的”。它今天的精益生产、看板管理、全员质量管理那一整套体系，骨子里带着当年做织机时那种对精密、对流程、对零缺陷的执念。

再看韩国。三星今天是世界级的电子和半导体巨头，但它刚成立的时候，做的是干鱼、蔬菜、水果的出口贸易，后来才进入纺织和制糖。韩国战后工业化起步，纺织和服装是它最早赚到外汇的产业之一，三星就是在那个时候靠贸易和纺织积累了第一桶金，七十年代才转向电子。现代集团也是类似的路子，从工程和重工起家，一路扩张到汽车、造船、重工业。

英国是第一个，日本和韩国是后发的样本。你会发现这三个国家的工业化顺序惊人地一致：先纺织，再轻工业，再机械，再重工业，最后走到高技术产业。这条路不是谁设计的，是被成本和市场逼出来的。因为纺织业是工业化门槛最低、市场最大的制造业，每一个想从农业国变成工业国的民族，都得从最容易、最必需的那一步开始。

这背后是一个很朴素的道理：现代化不是一步登天的，它得有个能赚到钱、能积累经验、能培养产业工人的起点。而纺织，正好是这样的起点。

中国走在这条路的哪一段

写到这里，我忍不住回头看中国自己。

中国的近代工业化，最早也是从纺织开始的。清末民初最有名的民族企业，几乎都是纱厂。南通的张謇办大生纱厂，无锡的荣宗敬、荣德生兄弟办申新纱厂，他们是中国第一代民族工业资本家，靠纺织起家，撑起了中国近代工业的半壁江山。张謇那一代人的想法很朴素：外国人靠机器织布赚走了我们的钱，我们就得自己办厂、自己织，把这笔钱留下来。

这是中国的第一段。那时候的中国，正走英国、日本、韩国都走过的那段路。

然后这条路断了。战争、动荡、计划经济，中国的工业化走了很多弯路。直到改革开放，才重新接上。八十年代沿海遍地是来料加工的服装厂、鞋厂、玩具厂，本质上还是那条“从纺织和轻工业起步”的老路，只不过这一次是靠出口、靠廉价劳动力、靠世界工厂的角色重新起步。

再往后，九十年代到两千年代，中国开始往重工业走：钢铁、水泥、造船、化工，一个接一个地追上世界前列。然后是电子工业、家电、手机。再然后是互联网，是高铁，是新能源汽车，是光伏，是半导体，是今天所有人都在谈的 AI。

你把这条线连起来看，会发现中国其实正在走完那条每个后发国家都走过的路，只不过中国走得更快、更猛、规模更大。从张謇的纱厂到今天的新能源车和 AI 大模型，不过是一百多年。一百多年，我们跑完了英国两百多年、日本一百多年才走完的工业化全程，而且还在继续往前。

这件事经常让我有一种很复杂的感觉。一方面是佩服，一代又一代人，从张謇到今天的工程师，真的把一个农业国变成了世界工厂，又变成了今天在不少高技术领域开始领跑的国家。另一方面也有一种隐隐的不安：这条路跑得太快，很多东西被甩在了后面。

一条没有断的线

在这条长长的工业化线索里，有一个细节我一直没忘，就是 2 月在安吉竹编工坊里的那个瞬间。

老师傅讲的“花本”，在中国其实有非常古老的传统。中国汉代的提花机，就是用一套预先设计好的绳索结构来控制经线起落，织工照着它织，就能复制出复杂的花纹。到了十九世纪初，法国人雅卡尔（Jacquard）把这套思路往前推了一大步，用穿孔卡片来控制织布图案：卡片上有孔，钩子就穿过去，经线抬起；没孔，钩子就被挡住，经线压下。有孔无孔，就是 1 和 0。

雅卡尔的穿孔卡片，后来被计算机先驱巴贝奇借去做分析机，又被 Ada Lovelace 写下了人类第一段程序。再往后，IBM 靠穿孔卡片机起家，今天整个计算机产业，往上追，源头居然能追到一台织布机。

这还不是终点。今天 AI 里的 Transformer、矩阵运算、神经网络的权重，说到底都是在大量的“经纬”之间计算关系。织布机要决定哪些经线何时抬起，神经网络要决定哪些参数之间彼此关联，逻辑是相通的。

所以“编织”这个词，不只是某个产业的起点，它更像是一种隐喻：人类从几千年前开始，就在学习怎么把复杂的东西编进结构里，从一匹布，到一段程序，再到一张神经网络。每个民族都在做这件事，只是阶段不同。

我打算把这条技术上的血脉，另外单独写一篇。这里点到为止，是想说明一件事：那条从竹篾开始的线，一直没有断。

总结

从 2 月安吉的一次竹编，到 3 月阿姆斯特丹的运河和风车，再到英国、日本、韩国、中国的工业化，我想说的其实只有一层意思。

每个民族的现代化，都是一条从一根线织成一张网的路。纺织是这条路共同的起点，不是因为纺织多高级，而是因为它最必需、最容易、最能让人赚到第一笔钱、积累第一批工人。从这个起点出发，有人走得克制，像荷兰；有人走得迅猛，像中国。有人用两百年，有人用一百年，有人只用了几十年。但起点是一样的，方向也是一样的，都是从手里那根线，一步步织成了今天的整个工业文明。

荷兰那种 6 点关门、不按喇叭、运河里游着天鹅的从容，是中国还没走到的地方。中国那种说干就干、一夜铺开的速度，也是荷兰学不来的。这两种现代化的气质之间，没有高下，只有取舍。而取舍的背后，是一个国家走到工业化的哪一段，以及它愿意为这条网付出什么样的节奏。

那天在安吉，我捏着一根竹篾，笨手笨脚地跟着老师傅抬一下、压一下，织出歪歪扭扭的一小片图案。那一刻我没想这么多。可是后来回过头想，从那一抬一压开始，往上能追到汉代的提花机，往外能追到一个国家的工业化，往后还能隐隐看到今天的计算机和 AI。一根竹篾，竟然连着这么多东西。

也许所谓文明的演化，说到底，就是人类一直在学习怎么把一件事编进另一件事里。

从一根线开始。

为什么 GPU 成了 AI 时代的基石？给 K8s 老兵的 GPU 科普

Jimmy Song — Wed, 17 Jun 2026 14:28:38 +0000

声明

本文以 Ameen Alam 的 GPU 架构三部曲为主线，并参考 TrendForce、NVIDIA（Slinky/Slurm、GPUDirect 数据通路）、Mirantis 等关于 GPU 基础设施与 Agentic AI 的资料，整理成一篇给 Kubernetes 老兵的 GPU 科普。如果你是 K8s 老兵但没碰过 GPU、没做过训练和推理，这篇是写给你的。

图 1: GPU：A I 的基石

写在前面：一个云原生老兵，为什么来写 GPU

过去十年，我的主战场一直是容器和 Kubernetes。从服务网格到整个云原生生态，我几乎每天都在和调度、网络、存储、可观测这些事打交道，但专注点始终落在 CPU 侧的云原生上。去年我正式切到了 AI 基础设施（AI Infra）。

一头扎进去才发现，这个领域的概念密度高得离谱。Token、Transformer、Tensor Core、HBM、KV Cache 一个接一个砸过来，而绝大多数文档和文章都默认你已经懂，对没训过模型、没推过理的工程师很不友好。

不过我很快摸到一个窍门：别从头硬学，先用你已经烂熟的东西当翻译器。

Kubernetes 老兵脑子里的那套心智模型，调度、Job、Deployment、controller、缓存、利用率、多租户，再到微服务、服务网格、分布式系统、事件驱动、高可用架构，几乎每一样都能在 AI Infra 里找到对应物。一旦把这层映射建立起来，那些看着高深的概念就会变成“哦，原来就是某某的 GPU 版”。这套“用云原生视角翻译 AI”的方法，帮我自己快速上了手，也希望你帮我身边背景相似的朋友少走弯路，所以我决定把它整理出来。

这篇是这套翻译法的第一篇，先解决最底层那个问题：AI 为什么非 GPU 不可？ 后面我还会接着写 GPU 资源管理、调度、可观测这些 K8s 老兵更熟悉的话题。如果你也是从云原生切过来的，希望这篇能帮你省下几天翻资料的功夫。

你在屏幕前打出一句话，AI 一字一字吐出回答。对用过 K8s 的你来说，最自然的理解是：AI 就是跑在 GPU 上的一种“工作负载”，而 GPU 是一种专门给它用的“节点”。

先把黑话翻译成 K8s

AI 圈有一堆术语，对没做过训练推理的人像天书。先给你一张对照表，后面每个词我都会用你能懂的话再讲一遍。

AI 概念	一句话大白话	K8s 老兵的类比
Token（词元）	文本被切成的小单元，AI 逐个生成	一行日志、一个文本块
模型（Model）	一个装着几十亿个数字（权重）的“打分程序”	一个超大镜像，里面装的“权重”不是代码
训练（Training）	喂海量数据反复调参，把模型造出来	跑一个 Job 去 build 镜像，离线、批处理、看吞吐
推理（Inference）	模型造好后，接用户请求吐回答	跑一个 Deployment 接流量，在线、看延迟
Transformer	目前几乎所有大模型（GPT、Claude、LLaMA）共用的架构	一种 controller 设计模式
Tensor Core	GPU 里只干“矩阵乘法”但快到离谱的专用单元	一个只会批量乘法的 sidecar worker
HBM	GPU 板载的高速大显存，模型和缓存都放这	节点本地内存，但带宽碾压普通 RAM
KV Cache	推理时存的“注意力状态”，随对话变长	Pod 本地一本会话记事本，越聊越厚

表 1: AI 黑话 → K8s 老兵的对照表

记住这张表，下面正式开讲。

一个大多数人懒得问的问题

GPU 在 AI 里已经无处不在，以至于大家默认它就该如此。我们关心租哪张卡、用什么框架、部署哪个模型，却很少有人停下来问那个更根本的问题：

为什么是 GPU？

为什么不是更通用的 CPU？为什么一个本来用来渲染游戏画面的芯片，成了这一代最重要技术变革的地基？

答案不只是“它算得快”，而在于计算本身是怎么组织的，以及 AI 这个负载，为什么需要一种和过去五十年软件都不同的架构。

两种计算哲学：工匠与工厂

我们对 CPU 已经很熟悉了。K8s 的控制面、etcd、scheduler 都跑在 CPU 上，它擅长把复杂指令一条接一条地快速执行，核不多（8 到 128 个）但每个都很精。CPU 优化的是延迟：我多快能干完一件复杂的事。 像一个手艺精湛的工匠，一次精雕细琢一件活儿。

GPU 走的是相反的路：在海量数据上同时执行简单指令。一张现代数据中心 GPU 有几千个小核，它优化的是吞吐：我同一时刻能干完多少件简单的事。 像一条几千人的流水线，每个人同时干一模一样的一道工序。

图 2: CPU 工匠 vs GPU 工厂：延迟优先与吞吐优先的两种计算哲学

单看任何一件复杂活儿，工匠（CPU）更快；但只要这活儿是整齐划一、可以并行的，工厂（GPU）每秒的总产出碾压工匠。过去几十年 CPU 统治一切，因为大多数软件（Web 服务、数据库、操作系统）本质上是串行的。然后深度学习来了。

AI 为什么打爆了 CPU

神经网络的核心，本质上是一大堆矩阵乘法（一种数学运算，把两组数字按规则批量相乘相加）。当模型处理一个 token 时，它要做几千、几万个这样的乘法，而这些乘法彼此不用等。

关键洞察一句话：这些运算天然可以并行。

一个 128 核的 CPU 看这种负载，只能一拨一拨顺序扫；一个几千核的 GPU 会把矩阵切块，分给各个小核同时算。同样的活儿，GPU 快出几个数量级，不是因为单个 GPU 核更快（其实更慢），而是问题本身是并行的，而 GPU 天生为这种形状的计算而造。

这就是 AI 跑在 GPU 上的真正原因，不是营销、不是历史包袱，是架构上的契合。

GPU 内部三件套，用 K8s 的话讲

1. Tensor Core：只会批量乘法的 sidecar

GPU 里有两类核。普通 CUDA 核像通用 worker，什么都能算；Tensor Core 是专用单元，它只会干一件事：把两小块矩阵一次乘完。但这一件事它快到离谱，一个周期算完普通核要算几千次的结果。

AI 的核心运算就是矩阵乘法，所以 Tensor Core 等于给 AI 量身定做。用 K8s 的话：普通 CUDA 核像 Deployment 里啥都干的通用 pod，Tensor Core 像一个只做“批量乘法”的高度专用 sidecar，单功能但吞吐碾压。

2. HBM：节点的高速本地内存

算得快还得拿得到数据。GPU 的内存和 CPU 节点一样是分层的，你理解 K8s 节点的 L1/L2 缓存、内存、本地盘，就理解 GPU 的：

图 3: GPU 内存层级：越往上越快越小，越往下越慢越大，HBM 带宽是 AI 的命脉

最底下那层 HBM（高带宽内存）就是 GPU 的“主内存”，模型权重、中间结果和 KV Cache 都存放在这里。它的特点是容量大（单卡通常可达数百 GB）、带宽极高。

为什么要专门造 HBM？因为传统显存（GDDR）平铺在电路板上，连线铺不开，带宽撞墙。HBM 的解法是把内存芯片垂直堆叠（用硅通孔 TSV 连通），整摞紧贴 GPU 核心，接口宽到上千根线并行。打个比方：普通内存像把仓库平铺在停车场，搬运工跑不过来；HBM 像把仓库盖成几十层的高楼紧挨着车间，电梯（TSV）上下飞快。

这里有个反直觉的事实：现代 AI 更多被内存卡住，不是被算力卡住。 Tensor Core 算矩阵乘法的速度，比 HBM 喂数据的速度还快，GPU 经常在等数据。所以每一代新 GPU（H200 → Blackwell → Vera Rubin）最关键的升级不是算力，而是 HBM 带宽（4.8 → 8 → 22 TB/s，数据来源）。

既然搬运是瓶颈，NVIDIA 的另一手就是让数据绕开 CPU 直达 GPU，这三条“高速路”统称 GPUDirect：

GPUDirect Storage：数据从 NVMe 硬盘直达 GPU 显存，不用先绕进主机内存、过一遍 CPU。
GPUDirect RDMA：GPU 显存和网卡（InfiniBand）直接通信，跨机交换梯度不再 CPU 中转。
NVLink：同一台机器里 GPU 之间直连，共享显存。

一句话：CPU 不再是每次数据搬运的交通管制员。用 K8s 的话理解，这就像让数据走“直连数据面”，而不是每个包都过一遍 apiserver。NVIDIA 的优势不只是算得快，而是把存储到 GPU、GPU 到 GPU、GPU 到网络整条数据高速公路都修直了。

3. Transformer + Token：逐字吐回答的程序

Transformer 不是硬件，是一种模型架构（程序结构）。GPT、Claude、LLaMA 这些大模型，底层都是它。它干的事其实很朴素：

读一段文本，预测下一个 token 是什么。

token 是文本被切成的小单元（一个字、半个词）。Transformer 把输入的 token 序列喂进去，吐出一个“最可能的下一个 token”，把它接上去，再把新序列喂回去，预测下下一个……如此循环，一个字一个字地生成整段回答。

图 4: Token 与 Transformer：AI 像接龙一样，每步读入已有 token，预测并吐出下一个 token

用 K8s 的话：Transformer 是一种 controller，它的 reconcile 逻辑就是“看当前状态（已有的 token），输出下一个动作（下一个 token）”，然后不断循环。AI 助手那“一字一字蹦”的效果，就是这么来的。

训练 vs 推理：写菜谱 vs 上菜

这是入门最容易混、却最关键的一组概念。训练和推理是两码事，硬件需求完全不同。

训练（Training）：喂海量数据，反复调整那几十亿个参数，把模型“教”出来。它要跑几周到几个月，是离线批处理，关心吞吐，不关心单次延迟。用 K8s 的话，这像一个跑很久的 Job，目标是 build 出一个模型镜像。
推理（Inference）：模型训好后上线，接用户的每一句话，算出回答吐回去。用户在等，关心延迟；要同时服务上千用户，关心并发。这像一个接流量的 Deployment。

图 5: 训练 vs 推理：训练像跑 Job 写菜谱（离线、看吞吐），推理像跑 Deployment 上菜（在线、看延迟）

这一点直接影响你该关心哪些 GPU 指标。大众话题里霸榜的（Tensor Core 算力、NVLink 带宽、集群规模）主要是训练指标；而真正决定你用 AI 助手爽不爽的（HBM 容量、内存带宽、KV cache 管理）是推理指标，反而少有人谈。可推理才是大多数生产 AI 真正跑的地方。

多 GPU 协作：AI 集群就是一个分布式系统

讲完单卡，回到现实：最大的模型一张卡塞不下，训练动辄要几百、几千张卡一起算。这时候 GPU 集群本质上就是一个分布式系统，而你熟悉的云原生那套几乎全用得上。

多张 GPU = 微服务集群。 一张卡像一个服务实例，大模型被切开放在不同卡上，每张卡算一部分再把结果拼起来。这不就是微服务按职责拆分、分片承担负载的套路。

卡间通信 = 服务网格的数据面。 卡和卡之间要不停交换数据（尤其训练时同步梯度）。机柜内靠 NVLink（几 TB/s），跨机柜靠 InfiniBand。这就像微服务之间的东西向流量：同一节点内 pod 直连最快（NVLink），跨节点跨集群走网络（IB）。NVIDIA 把 GPU、交换机、DPU、RDMA 打包成整机柜（Vera Rubin NVL72），就等于服务网格把数据面、控制面、可观测打通成一整套。

分布式训练的 all-reduce = 分布式一致性。 训练每走一步，要把所有卡算出的梯度同步、求平均，这步叫 all-reduce。搞过 etcd、Raft 的人秒懂，这就是分布式系统里的共识与一致性，只不过这里同步的是梯度，不是状态机日志。

连续批处理 = 事件驱动。 推理时新请求随到随被塞进正在跑的批次，不用等整批跑完。请求像事件，批处理器像消费者，攒一批处理一批，这就是事件驱动、消息队列那套思路，目的是让 GPU 永远有活干、不空转。

分离式推理 = 微服务化。 把 prefill（吃输入，算力密集）和 decode（吐回答，内存密集）拆到不同 GPU 池，各自独立扩缩，KV cache 在它们之间靠 NVLink/RDMA 传递。这完全是微服务按职责拆分、独立扩缩容的玩法，KV cache 就像在服务间传递的会话上下文。

看出来了吧，AI 集群不是什么全新物种，它是把你烂熟的那套分布式系统、微服务、服务网格，搬到 GPU 这套硬件上重演一遍。你过去在 Istio、Envoy 上调流量、在 etcd 上调一致性攒下的经验，在这里照样值钱。

K8s 跑 GPU：训练用 Slurm，推理用 K8s

讲到这，作为 K8s 老兵你一定想问：那 GPU 集群到底用什么调度？答案有意思：训练和推理，常常是两套调度系统。

训练这一侧，HPC 世界的老大哥是 Slurm。 它管着全球 65% 的 TOP500 超算（NVIDIA），大型 AI 训练团队多年来积累了大量 Slurm 脚本、公平份额策略和计费流程。训练是长跑批任务，要的是拓扑感知（把通信频繁的 GPU 摆近点）、长时间独占、高吞吐，Slurm 在这上面打磨了十几年。

推理这一侧，主场是 Kubernetes。 推理是在线服务，要快速扩缩、按请求调度、和服务网格/可观测打通，这些正是 K8s 的强项。

问题来了：很多团队两套都要，难道维护两套环境？NVIDIA 开源了 Slinky 项目来解决这个，做法非常 K8s 原生：

slurm-operator：把 Slurm 的各个守护进程（slurmctld 调度、slurmd 计算、slurmdbd 计费）做成 K8s 的 CRD 和 Pod，控制面靠 Pod 重生做高可用，不需要 Slurm 原生 HA 那套。配置变更通过 ConfigMap/Secret 自动同步，worker 用 HPA 弹性扩缩，缩容前先 drain 跑完任务，升级靠 PodDisruptionBudget 保护在跑任务。
GPU Operator + DCGM Exporter：自动装驱动、设备插件，还能按 Slurm 作业 ID 打标，给你每个作业级别的 GPU 指标（Prometheus 抓）。
ComputeDomains + DRA：像 GB200 NVL72 这种跨节点 NVLink 的机器，K8s 用 DRA（Dynamic Resource Allocation）动态管理跨节点 GPU 互联域，让分布式训练跨节点也能跑满 NVLink 带宽。

NVIDIA 自己已经在生产环境用 Slinky 跑到 8000+ GPU，NCCL 的 all-reduce/all-gather 性能和裸 Slurm 一致，K8s 这层几乎不损耗（NVIDIA 生产实践）。K8s 正在成为 GPU 计算的底座，Slurm 是跑在上面的调度层。

训练和推理对 GPU 调度的需求根本不同，不能用同一套思路管。这也是为什么 GPU 资源管理（后面会讲）要分场景，而 HAMi 这类方案要在 Slurm + K8s 混合环境里当统一的 GPU 资源管理层。

推理的真正大坑：KV Cache

如果只记一个把“GPU 理论”和“AI 推理现实”分开的概念，那就是 KV Cache。

Transformer 在生成每个 token 时，要参考前面所有 token 的关系（这叫“注意力”）。为了不每次都从头算，它把每个 token 的注意力状态存下来，这就是 KV Cache。

问题在于它会越长越大：

用户发来一万 token 的对话，模型给每个 token 存一条状态；
每生成下一个 token，它要把整份 KV Cache 读一遍；
一个 70B 模型在 32K 上下文下，单次请求的 KV Cache 就能到 8 到 16 GB，比模型本身还大；
50 个并发用户一上来，KV Cache 吃掉几百 GB 显存。

图 6: KV Cache 像一本越聊越厚的会话记事本：对话越长本子越厚，每说一个新字都要把整本翻一遍

用 K8s 的话类比：KV Cache 像 Pod 本地的一本会话记事本。对话越长本子越厚，而且每说一个新字，都得把整本从头翻一遍。所以推理的显存，经常不是被模型吃掉的，而是被这本“本子”吃掉的。

这也是为什么会有 paged attention（把这本本子像虚拟内存页一样管，减少碎片，vLLM 把它带火）、NVIDIA Dynamo 的多级缓存（热页留 HBM，温的卸到 CPU 内存，冷的落到 NVMe）。推理工程师有一半精力在管这本本子。

GPU 利用率会撒谎

搞 K8s 的最懂“利用率骗人”：一个 pod 报 Running，不代表它在干活，可能只在 CPU steal 或等 IO。GPU 更严重。

监控里那个“GPU 利用率 %”通常只衡量“GPU 是否在执行某个核”，不衡量执行得多高效。一张卡可以报 90% 利用率，但 Tensor Core 真正忙的时间只有 30%，剩下都在等内存、做核启动开销、或干等数据。

更真实的指标叫 SM Efficiency（SM 活跃率）：它看的是每个时钟周期里，到底有多少 SM 在干有用的活。一张 nvidia-smi 显示 100% 利用率的卡，SM Efficiency 可能只有 20% 到 30%。很多企业以为自己“GPU 跑满了”，其实大量算力在空转。所以判断 GPU 是不是真在干活，别看利用率，看 SM Efficiency。

真正该看的指标（对应 K8s 里你看的 QPS、P99 延迟、资源水位）：

Token 吞吐：每卡每秒生成多少 token，对应能服务多少用户（像 QPS）。
TTFT（首 token 延迟）：从收到请求到吐出第一个 token 的时间，决定“响应感”（像冷启动时间）。
TPOT（Time Per Output Token，每 token 输出时间，也叫 ITL / token 间延迟）：生成每个 token 平均要多久，决定流式流畅度（像 P99）。vLLM、TGI 这类推理框架普遍用 TPOT，NVIDIA 这边更常叫 ITL，指的是同一回事。
内存占用拆解：权重、KV cache、临时激活各占多少，告诉你是不是被内存卡住（像看 pod 的内存水位细分）。

为什么 NVIDIA 这么难撼动

聊 GPU 绕不开 NVIDIA 的统治地位。硬件确实强，但光硬件解释不了为什么 AMD、Intel、一堆创业公司的替代品始终难成气候。答案是生态深度。

CUDA 不只是并行计算平台，它是编程模型、编译器、运行时加一堆库，打磨了 18 年。几乎每个 AI 框架（PyTorch、TensorFlow、JAX）都先在 CUDA 上长出来，再移植到别处。用 K8s 的话：CUDA 之于 GPU，有点像 Linux 内核 + containerd + 一整套 CNCF 工具链之于容器生态，不是换一个内核就能替代的。

换一张别的卡，意味着重新验证推理栈的每一层（核、库、框架、serving、监控、运维）。切换成本不是买不同的硬件，而是重建一整套软件生态。这就是“CUDA 护城河”。

未来：AI 工厂

NVIDIA 现在不再用“GPU”甚至“数据中心”来描述生意，而是说“AI 工厂”：把电力、芯片、数据持续转化成智能的设施。这背后是真实的架构演进：

电力成了首要约束：单个 Vera Rubin 机柜功耗超 100 kW（数据来源），一个中型训练集群要 10 到 50 MW，相当于一个小镇。GPU 不再是最难搞的，搞到稳定供电才是。
散热离开风冷：液冷成了高密度 GPU 的标配。
网络决定 GPU 摆放：AI 集群设计现在是先定网络拓扑，再倒推 GPU 放哪，和传统数据中心正好反过来。
内存带宽仍是扩展前沿：每代加算力，但真正影响体验的是 HBM 带宽。
本质是高可用 + 机房运维：供电冗余、散热容灾、网络拓扑决定延迟、单点故障容灾，全是搞过分布式系统高可用的人熟悉的老问题。AI 工厂不是新魔法，是把你做高可用架构的那套功夫，搬到了一个功率和密度都高一个数量级的机房里。

别急着淘汰 CPU：Agentic AI 正在重塑 CPU:GPU 比例

讲了这么多 GPU 的好，你可能以为 CPU 在 AI 时代要靠边站了。恰恰相反，Agentic AI（智能体）正在把 CPU 请回 C 位。

传统的 LLM 推理，CPU 基本只负责给 GPU 压缩、搬运数据，所以 AI 数据中心的 CPU:GPU 配比一度低到 1:4 甚至 1:8。但智能体不一样：它要自主规划任务、调用工具、在子 Agent 之间路由数据、判断任务有没有完成，这一整套编排（Orchestration）逻辑几乎全压在 CPU 上。再加上智能体常靠强化学习训练，每个动作都要 CPU 评估，CPU 的负载更重。

有研究指出，智能体场景里 CPU 侧的工具处理（Python 解释、网页抓取、检索、数据库查询）能占到总延迟的九成。据 TrendForce 报道，Arm 估算，传统 AI 数据中心每 GW 大约需要 3000 万个 CPU 核，到了智能体时代会飙升到 1.2 亿核，4 倍；CPU:GPU 配比会从 1:4~~1:8 往 **1:1~~1:2** 走。这也是为什么 2026 年 NVIDIA 开始单独卖 Vera CPU、Arm 也亲自下场做 CPU。

对 K8s 老兵的信号很明确：未来的 AI 节点，是 CPU 和 GPU 一起算账的混合负载节点，调度和资源管理得同时管好这两类资源，而不是只盯着 GPU。

这和我（一个 K8s 老兵）有什么关系

讲了这么多硬件，落到我做的东西上：只有先理解 GPU 为什么是 AI 的基石，才能理解“GPU 资源管理”为什么是个真问题。

当一张卡动辄几十万元、整机柜上百千瓦，而生产里 GPU 却经常因为内存带宽、KV cache、批处理没调好而跑不满，“把卡分下去”就远远不够。怎么在一张卡上安全地跑多个租户（像 K8s 把多个 pod 调度到一个节点）、怎么在训练和推理两种截然不同的负载之间切分资源、怎么让利用率从“看起来满”变成“真的满”，这正是 GPU 虚拟化与共享（比如我做的工作）要解决的事。

这里有一组数据很扎心：据 ClearML 的 AI 基础设施调研，只有约 7% 的企业能在峰值时段把 GPU 利用率跑到 85% 以上，超过一半的企业卡在 51% 到 70%，还有 15% 低于 50%。也就是说，绝大多数企业花大价钱买的 GPU，有相当一部分算力在空转。这往往不是硬件不够，而是调度和管理没跟上。

我自己的判断是，GPU 资源管理正在经历三个阶段：Allocation（分配）→ Utilization（利用率）→ Efficiency（效率）。第一阶段只回答“这张卡分给谁”（device plugin、独占或时间片）；第二阶段追问“这张卡用满没”（动态批处理、弹性扩缩，多数企业卡在这）；第三阶段才问“这张卡的算力是不是在产生最大价值”（SM Efficiency、每瓦 token、带宽利用率）。真正的挑战在第三阶段，而未来的 GPU 调度器不该只是资源分配器，而要成为 GPU 内部资源的精细编排器，能看懂有多少 SM 在活跃、Tensor Core 利用率多少、KV cache 占了多少显存，再决定能不能再塞一个请求。

说白了，AI 时代正在重演一遍云原生的故事：从“单机独占”走向“多租户共享 + 调度 + 可观测”。而 GPU，就是这出新戏的主舞台。

这只是上半场：NVIDIA 之外，牌桌上还有谁

读到这你大概发现了，这篇基本只讲了 NVIDIA。没办法，它是当前绝对的主角，绕不开。但如果你以为 AI 加速器的世界只有 NVIDIA，那就大错特错了。

事实上，一场“反英伟达联盟”正在从四面八方集结：

云厂商自研：Google 的 TPU 已经迭代到第六代、支撑自家几乎全部 AI 业务；AWS 的 Trainium（训练）和 Inferentia（推理）越铺越广；Meta、微软也没闲着。
传统芯片巨头：AMD 用 Instinct 系列加 ROCm 死磕，Intel 拿 Gaudi 和 oneAPI 卡位。
中国异构算力生态：华为昇腾、海光 DCU、寒武纪、摩尔线程、燧原、昆仑芯、沐曦、壁仞……在国产替代的窗口里疯狂追赶，软件栈也一步步从“能用”往“好用”走。
开放生态的反扑：UXL 联盟、OpenAI Triton、PyTorch 原生的 AMD/TPU 后端，都在啃 CUDA 这条护城河的墙。

这对一个 K8s 老兵意味着什么？意味着未来的 AI 集群，几乎一定是异构的：机柜里可能同时躺着 NVIDIA、AMD、TPU 和国产卡，一张调度表要管好几种完全不同的硬件。

于是真正有意思的问题来了：

怎么在一套集群里混跑多种加速卡，还能统一调度、统一观测？
K8s 的设备插件、DRA（动态资源分配）往哪演进，才能优雅地描述这些五花八门的硬件？
CUDA 护城河会被开放生态攻破吗，还是说 NVIDIA 会像当年的 x86 一样长期统治？
国产异构算卡要真正进生产，还差哪几块拼图？

这些，我会在后面的文章里再讲。这篇只是把“为什么是 GPU”讲透，下一篇，我们聊聊“GPU 不止一种”之后，AI 基础设施该怎么调度这块大棋。

参考资料

Ameen Alam, Why GPUs Became the Foundation of Modern AI（三部曲 Part 1）
Ameen Alam, The Hidden Technology Behind Modern AI GPUs（Part 2）
Ameen Alam, Real AI Infrastructure and the Future of GPUs（Part 3）
TrendForce, The Great Rebalance: How Agentic AI Is Reshaping the CPU/GPU Ratio（CPU:GPU 比例再平衡）
Anton Polyakov (NVIDIA), Running Large-Scale GPU Workloads on Kubernetes with Slurm（Slinky / Slurm on K8s）
Kawonise, Why NVIDIA GPU Architecture Is Perfect for AI: GPU Data Path for a Single Node（GPUDirect 数据通路）
Mirantis, GPU Infrastructure Automation and Strategy（GPU 基础设施自动化与利用率）

GPU 利用率正在“失灵”：AI 基础设施需要重新定义效率

Jimmy Song — Wed, 17 Jun 2026 05:57:13 +0000

让每一分 GPU，不只是被使用，而是真正创造价值。

我们一直在追求 GPU 利用率

过去几年，不管是 Kubernetes 的 GPU 调度、vGPU、MIG，还是 HAMi，大家其实都在做同一件事，就是把一个指标往上推：

GPU Utilization

这很合理。GPU 太贵了，一张 H100 一小时的成本可以到几美元到十几美元不等，谁也受不了 GPU 在那儿空转。所以整个 AI Infra 社区过去几年的叙事基本就一句话：

提升 GPU 利用率。

我自己长期参与 HAMi 社区，写过的几篇文章，比如《Kubernetes 正在成为 AI 时代的 GPU Control Plane》和《从 GPU 到 Token：AI 基础设施的八层可观测性体系》，其实也都在讲这件事，怎么把 GPU 切得更细、共享得更彻底、调度得更合理。

但最近读到 Arjun Kaarat 在 Towards Data Science 上发表的 When GPU Utilization Lies: The Hidden Systems Problem Slowing Modern AI，我开始重新想一个问题：

GPU 利用率，真的是我们该优化的目标吗？

文章里有一句话，我第一次读到时停了几秒：

“GPUs can be busy without being productive.”

Arjun Kaarat

这句话点破了一层窗户纸。我们过去花那么多精力去推高的那个数字，可能从一开始就回答错了问题。

GPU Busy 不等于 Productive

Kaarat 在文章里讲了一个特别有代表性的故事。

凌晨 2 点，一个基础设施团队被报警，推理延迟突然飙升了 60%。大家打开监控大盘一看，GPU 利用率一切正常：

GPU: 79%
GPU: 82%
GPU: 84%

看起来很健康。于是常规套路上来，触发自动扩容、加节点、加 GPU。云账单一路上涨，但延迟几乎没改善。

一个小时之后才发现根因：有三个节点悄悄进入了 RAID 重建状态，存储吞吐被严重拖慢，把附近的推理任务饿得半死。调度器一直把这几个节点当成“还够健康”，因为 GPU 和内存指标看起来都没问题，可底层磁盘性能已经塌了。

这个故事最打动我的地方在于，它不是一个罕见的边缘 case，而是一个正在变得普遍的故障模式。

很多团队看到监控上：

GPU: 82%
GPU: 84%
GPU: 79%

觉得“我们集群很忙、很健康”。但与此同时：

Latency ↑
Queue ↑
Throughput ↓
Cost ↑

真正的问题是，GPU 在等待。

它在等什么？

检索流水线（Retrieval）把 embedding 喂过来；
SSD 把上下文从存储里读出来；
CPU 把数据 pipeline 准备好；
KV Cache 有足够空间承接新的请求；
存储 I/O 不被后台任务挤占。

GPU 这一头是满的，可喂它的那条数据通路是空的、堵的、或者正在塌的。从仪表盘上看 GPU 是 84%，实际产出可能连一半都不到。Kaarat 在原文里把这种状态描述得很精准：

A GPU that appears active may still spend meaningful time waiting for the system around it.

这就是“忙碌”和“产出”之间那道被忽视的鸿沟。

GPU 利用率的“幻觉”

前面那个 RAID 的故事还只是“点状故障”。Kaarat 文章里更精彩的部分，是讲了一种系统性现象：Fragmentation，资源碎片化。

考虑一个集群里有三个节点，在跑完一波混合的 GenAI 任务之后：

节点	GPU 算力	HBM	存储带宽	I/O CPU
A	可用	几乎占满	可用	可用
B	可用	可用	已饱和	可用
C	有限	可用	可用	已饱和

表 1: 三个节点跑完一波 GenAI 任务后的残留资源

这时候来了一个新的推理任务，需求很普通：要一点 GPU、一点显存、像样的存储带宽、像样的 I/O 能力。

从总量上看，整个集群还有大把资源。A 有 GPU 和带宽，B 有显存，C 有带宽和 CPU。可是没有任何一个节点，能单独把这个任务接下来。

这就是资源碎片化。我把它画出来大概是这样：

图 1: 集群不缺资源，缺的是形状对的资源

集群不是空的，它只是被切成了无法再被有效利用的“边角料”。Kaarat 用一句话概括了这种现象，我觉得是全文最值得记住的一句：

The cluster is not empty. It is fragmented into leftovers that are difficult to use productively.

换一种说法：

集群不缺资源，缺的是“形状对的资源”。

这个判断对 HAMi 这类做 GPU 资源控制面的项目来说，其实非常关键。我们以前总以为“把卡切细、让多人共享”就是解决碎片化，但 Kaarat 指出了一个更深的问题：碎片化不只是 GPU 层面的事，它横跨 GPU、HBM、存储带宽、I/O CPU 多个维度。你把 GPU 切得再细，如果存储维度被堵死了，这个节点对下一个真正有用的任务来说，依然是不可用的。

HAMi 解决了什么

聊到这里，我想正面回答一个问题：HAMi 在这条链路里到底扮演什么角色？

HAMi 解决的是一个非常具体、也非常基础的问题：

GPU 能不能被更多人使用。

它做的事可以归纳成一句话：减少 GPU 层面的碎片化。具体形态包括：

GPU Sharing：让多个 Pod 共享同一张卡，而不是一卡一 Pod；
vGPU / HAMi-core：在用户态做显存隔离和算力限流，把一张卡切成 MB 级的虚拟设备；
MIG 整合：用软件方式管理 NVIDIA MIG 硬件分区；
异构 GPU 统一抽象：把 NVIDIA、昇腾、寒武纪、海光、瀚博等十余种设备，抽象成调度器能统一消费的语义；
DRA 兼容：跟上 Kubernetes 资源模型演进的脚步。

这是第一层效率。它回答的是“GPU 能不能用起来”的问题。

在这一层上，HAMi 的价值已经很清晰了：在国产与海外 GPU 混部、训练与推理混部、多租户共用的真实环境里，HAMi 让一张卡可以服务更多 workload，让集群不再因为“一卡一 Pod”这种粗粒度模型而被白白浪费。

但要注意，这只是效率故事的第一章。

HAMi 之后，我们还缺什么

如果我把视角拉高一点，会发现“提升 GPU 利用率”这件事，实际上是被分在三个不同层次里解决的。

第一层：GPU 能不能被切分、共享、分配？

这是 HAMi 这类项目在解决的问题，对应 GPU 资源控制面。

第二层：谁来使用 GPU？谁先跑、谁排队、谁优先？

这是 Volcano、Kueue、KAI Scheduler 这批调度器在解决的问题，对应作业排队、公平共享、优先级、gang scheduling。

第三层：GPU 真的能跑起来吗？数据通路、存储 I/O、KV Cache 这些东西跟得上吗？

这就是 Kaarat 那篇文章在敲响警钟的地方。当一个节点 RAID 在重建、SSD 队列爆炸、I/O CPU 被后台任务吃光的时候，你分给它再多 GPU、调度器把任务排得再优雅，它也产不出有效算力。

把这三层画在一起，就是下一代 AI 基础设施真正应该长成的样子：

图 2: 从 GPU 利用率到 Productive GPU-Hours

这张图我觉得是理解整件事最关键的一张图。

过去几年，行业几乎所有的注意力都压在最下面两层：Kubernetes + HAMi。这两层把“GPU 能不能被用起来”的问题基本解决了。Volcano、Kueue、KAI 在第二层也很成熟，解决了排队和优先级的问题。

但第三层，Storage / I/O-aware Scheduling，目前几乎是个空白。 而这恰恰是 Kaarat 文章里反复强调的、现代 GenAI 系统里越来越值钱的那一层。因为 RAG、长上下文、多模态这些工作负载，瓶颈早就从“GPU 够不够”转移到了“喂 GPU 的那条数据通路通不通”。

说白了，HAMi 把 GPU 切细了，Volcano 把队列排好了，但如果一个被分到任务的节点根本喂不饱 GPU，那前面所有努力都是在给一个空转的末端供血。

下一代 AI 基础设施该优化什么

基于上面的分层，我想表达一个明确的观点：我们应该把优化目标从“GPU 利用率”升级到“Productive GPU-Hours”。

这不是文字游戏，而是一个能直接换算成钱的转变。

Kaarat 在文章里算过一笔账。一个 1000 张 H100 的集群，按 3 美元每卡每小时混合成本算，一年大约是 2600 万美元。如果碎片化和 I/O stall 偷偷浪费掉其中 10% 的有效 GPU 时间，那就是每年约 260 万美元的无效开销。不是因为 GPU 不见了，而是因为系统没能高效地使用它们。

这笔账可以翻译成一个简单的对照。

过去的目标：

Maximize GPU Utilization

今天的目标：

Maximize Productive GPU-Hours

未来的目标：

Maximize Productive Compute
Across Heterogeneous AI Clusters

这个演进路径，正好对应前面那张分层图里讲的三层结构。最后那个“Across Heterogeneous AI Clusters”，正是 HAMi 一直在推进的异构叙事，未来你不会只优化一种 GPU，你要在 NVIDIA、昇腾、寒武纪、海光这些完全不同的卡之间，统一地最大化有效算力。

换句话说，HAMi 的长期价值，不应该被框死在“提升 GPU 利用率”这个旧叙事里。它的真正方向是：为异构 AI 集群提供一个能让 Productive GPU-Hours 最大化的资源控制面。

从 Utilization 到 Productive GPU-Hours

如果让我用一句话总结这次思考，我会这么说：

HAMi 解决的是“如何让更多 GPU 被使用”，而下一代 AI 基础设施要解决的，是“如何让每一分 GPU 真正创造价值”。

这正是 Kaarat 那篇文章留给我的最深的一句话：

The real question is no longer “Are the GPUs busy?”

It is: “Are they productively busy?”

这也让我开始重新看待 HAMi 社区下一阶段的口号。过去我们说“让 GPU 被更多人共享”，接下来或许应该往这个方向走：

Turn GPU utilization into productive GPU-hours.

让每一分 GPU，不只是被使用，而是真正创造价值。

GPU 利用率从来不是终点，它只是效率故事的第一章。当我们开始谈论 Productive GPU-Hours，开始关心存储、I/O、数据通路和异构集群的整体产出，AI 基础设施才真正进入它的第二章。

致谢与参考

本文部分观点受 Arjun Kaarat 在 Towards Data Science 发表的 When GPU Utilization Lies: The Hidden Systems Problem Slowing Modern AI 一文启发，并引用其公开发表的论文与文章观点，特此致谢。文中两幅示意图（资源碎片化、效率分层架构）均为作者基于原文观点重新绘制，非原图搬运。

Arjun Kaarat. When GPU Utilization Lies: The Hidden Systems Problem Slowing Modern AI. Towards Data Science, 2026.
Kaarat, A., Batthula, V. J. R., & Segall, R. Fitting the Void: Residual-Aware Geometric Packing for GenAI Workloads. IEEE, 2025.

当 Agent 成为长期运行的分布式状态机：解读 Agentic AI 基础设施可靠性

Jimmy Song — Tue, 16 Jun 2026 09:14:34 +0000

声明

本文是对 Hesham ElBakoury 在 Open Compute Project (OCP) 社区分享的论文《AI Infrastructure Reliability Features and Architecture for Agentic AI》（2026 年 6 月）的解读与评价，融合了我个人在 Kubernetes / AI Infra 方向的工程视角，并非论文原文翻译。

Agent 不是一次推理请求，而是长期运行的分布式状态机；因此，Agent 的可靠性问题本质上是分布式系统问题。

写在前面：为什么我要专门聊这篇论文

做云原生这么多年，我有一种很顽固的直觉：一个新的技术形态成不成熟，不看它的模型多强、Demo 多炫，而看它有没有一套成体系的可靠性语言。 Kubernetes 当年能赢，靠的不是容器 runtime，而是 liveness/readiness、控制器 reconcile、PD/PDB、SRE 那一套把“长期运行的分布式状态”讲清楚的话语体系。

前阵子在 Open Compute Project (OCP) 社区里看到 Hesham ElBakoury 分享的一篇论文，眼前一亮，它没有提出任何新算法、新框架，通篇在做一件事：把传统 SRE 的可靠性语言，系统地翻译到 Agentic AI 身上。 这正是我过去半年在 Agentic Runtime 的现实主义、Ark Agentic Runtime 深度解析里反复想讲、却一直没找到一篇“基准文献”来对齐的东西。所以我决定专门写一篇，把它的框架拆开，再从 AI Infra 从业者的角度做一次批判性评价。

一句话定位：它更像是一篇 Agentic AI 的 SRE 白皮书，而不是一篇系统论文。 它的价值不在创新，在于“建立共识”。

一句话总结

传统 AI 关注模型准确率，而 Agentic AI 必须关注“长期运行中的可靠性”，因此需要把容错、恢复、监控、安全和状态管理提升为架构设计的一等公民（first-class citizen）。

传统 AI 与 Agentic AI 的根本分野

论文认为，传统 AI 与 Agentic AI 的根本区别在于执行模型。传统 AI 是一次性的请求 - 响应，关注准确率、延迟和吞吐；而 Agentic AI 是一个持续循环，一次错误不再只是一个错误答案，而是一个可能改变 Agent 后续所有行为的错误决策。

图 1: 传统 AI 的请求 - 响应 vs Agentic AI 的感知→思考→行动→观察循环

下面这张对照表把这种区别讲得最清楚。我建议你重点看最后一行“失败影响”，那才是整篇论文的题眼：

特性	传统 AI	Agentic AI
执行模型	请求 - 响应（Request-Response）	持续循环（Continuous Loop）
状态管理	无状态（Stateless）	有状态（Stateful）
触发方式	人工触发（Human-triggered）	自主发起（Self-initiated）
时间跨度	单次交互	长期运行会话
失败影响	单次输出错误	级联行为变化（Cascading behavior changes）
资源使用	突发（Bursty）	持续（Continuous）

表 1: 传统 AI 与 Agentic AI 的执行模型对照

这张表的关键不在技术细节，而在心智模型的转变：当失败的影响从“一个错误答案”升级为“行为级连锁错误”时，可靠性的权重就必须从架构的最底层重新分配。给一个无状态 API 做容错，和给一个会自主决策、会持续运行的状态机做容错，根本不是同一件事。

核心贡献：Agent 可靠性五维框架

这是全文最值得记住的部分。作者把 Agent 的可靠性拆成五个维度，构成一个完整的评估坐标系。我把它画了出来，中间是“Agent 可靠性”，五个维度像花瓣一样展开：

图 2: Agent 可靠性五维框架：前四维描述 Agent 自身行为，第五维描述承载它的平台

逐个拆开看：

功能可靠性（Functional Reliability）：Agent 是否能完成任务。关注正确性、准确性、一致性、完整性。直白点：这个 Agent 能不能把事办成？
时间可靠性（Temporal Reliability）：Agent 是否能持续稳定。关注时效性、响应性、稳定性、耐久性。直白点：它能不能一直把事办成？
环境可靠性（Environmental Reliability）：面对环境变化是否仍有效。关注适应性、鲁棒性、可移植性。直白点：换个环境它还能干活吗？
社会可靠性（Social Reliability）：这是 Agent 独有的维度。关注安全性、可信度、协作性、可解释性。直白点：它能不能跟人和其他 Agent 安全协作？
系统可靠性（Systemic Reliability）：基础设施层。关注可用性、容错、可扩展性、安全性。直白点：支撑 Agent 的平台靠谱吗？

为什么这个框架有价值

这五个维度的真正价值，在于它让“Agent 可靠性”从一个模糊的概念，变成了可被拆解、可被度量、可被分别负责的工程问题。前四个维度描述 Agent 自身的行为属性，第五个维度描述承载它的平台，而这第五维，正是我们这些做 AI Infra / Kubernetes 的人最该接住的落点。

把 Agent 当作“有状态服务”

论文的第二个核心判断，我深以为然：Agent 最大的基础设施挑战，不是推理，而是状态。

一个 Agent 同时持有记忆（Memory）、目标（Goal）、计划（Plan）、上下文（Context）和工具状态（Tool state）。把它当成 HTTP API + Model 来运维，是当前绝大多数 Demo 经不起生产考验的根因。它真实的形态更接近一个数据库 + 工作流引擎 + LLM + 分布式系统的复合体：

图 3: 错误的运维心智（左）vs 正确的运维心智（右）：Agent 本质是有状态的分布式系统

这其实和当下业界的演进方向完全一致，LangGraph、Temporal、OpenAI Responses API 都在把“有状态的长期运行逻辑”变成一等公民。当一个 Agent 运行数小时甚至数天，它的状态比模型参数本身更关键，也更容易因为一次重启而彻底丢失。 模型可以重新加载，但一个跑了三小时的规划上下文，丢了往往就是丢了。

容错：Agent 系统的“黄金组合”

论文给出了一份 Agent 容错模式清单：

机制	作用	复杂度
冗余（Redundancy）	备用 Agent 随时接管	高
检查点（Checkpointing）	保存状态用于恢复	中
心跳（Heartbeat）	存活检测	低
断路器（Circuit Breaker）	隔离异常 Agent，防止级联	低
回滚（Rollback）	回滚错误决策	中
法定人数（Quorum）	多 Agent 投票达成共识	高
自愈（Self-Healing）	自动检测并纠正错误	高

表 2: Agent 容错模式清单：机制、作用与实现复杂度

其中作者最看重 检查点 + 冗余 + 心跳 这三件套，称为 Agent 系统的“黄金组合”。我用一张闭环图把它们的关系画了出来，这三者缺一不可，少任何一环，恢复链路就断了：

图 4: Agent 容错黄金组合：心跳发现问题 → 检查点保存现场 → 冗余切换实例

黄金组合的闭环逻辑

心跳负责快速发现问题，检查点负责保存可恢复的状态，冗余负责在故障时无缝接管。三者共同构成“发现问题 → 保存现场 → 切换实例”的闭环。这也是为什么这套机制听着都是分布式系统的老朋友，因为 Agent 的可靠性问题，本来就是个分布式系统问题。

恢复机制：把传统灾备思想搬到 Agent

这部分其实是把传统 DR（灾备）的 RTO/RPO 思想搬到了 Agent 场景。论文比较了几种恢复方式：

恢复方式	RTO	RPO	复杂度
冷启动（Cold Start）	分钟~小时	高（完全丢失）	低
温启动（Warm Start）	秒~分钟	中	中
热备（Hot Start）	秒级	低（极小丢失）	高
检查点恢复（Checkpoint Recovery）	秒~分钟	中（自上次检查点）	中
状态重建（State Reconstruction）	分钟~小时	低（可完整恢复）	高

表 3: Agent 恢复方式对比：RTO、RPO 与实现复杂度

作者的结论是：Agent 最适合检查点恢复（Checkpoint Recovery）。 原因前面已经埋下伏笔，Agent 的状态远比模型参数重要。检查点恢复在 RTO、RPO 和实现复杂度三者之间，取得了最平衡的取舍。这也是为什么前面“黄金组合”里检查点排在 C 位。

Agent 可观测性 = 基础设施指标 + 行为分析

这一节是我个人最有共鸣的部分。论文认为传统监控远远不够：传统监控盯的是 CPU、内存、延迟、QPS，而 Agent 必须额外监控行为本身。

Agent 健康（Agent Health）：心跳、资源利用率、错误率、决策延迟。
行为（Behavioral）：动作频率、决策模式、状态转换、目标进度。
系统（System）：Agent 数量、通信量、基础设施健康。

其中“行为”这一层是 Agent 独有的。

最容易踩的坑

一个 Agent 的 CPU 不高、延迟正常，但如果它的“动作频率”突然飙升、“决策模式”偏离基线，这往往才是真正危险的信号。 换句话说：Agent Observability = Infra Metrics + Behavior Analytics。 只盯基础设施指标，会完美错过 Agent 的“行为失控”。

这与我之前在 GPU 到 Token 的可观测性一文中讨论的思路完全相通，Agent 时代必须把行为信号纳入可观测性的第一公民，而不是停留在硬件 / 推理指标那一层。

架构	复杂度	可扩展性	故障隔离	对 Agent 适用性
单体（Monolithic）	低	有限	差	差
分层（Layered）	中	中等	中等	好
微服务（Microservices）	高	高	优秀	优秀
事件驱动（Event-driven）	高	高	好	优秀

从 AI Infra 视角看这篇论文最大的价值

如果站在 Kubernetes / AI Infra 的角度，这篇论文真正传递的是一个范式的迁移：Agent 基础设施将从“Serving”转向“Runtime”。

图 6: 范式迁移：从模型 Serving 到 Agent Runtime，关注点全面右移

过去关注的是 GPU 利用率、吞吐、延迟；未来关注的是状态恢复、长任务连续性、Agent 隔离、Agent 调度、Agent 可观测性、Agent 安全治理。

我对趋势的判断

AI Infra 的下一个阶段，不是更好的模型 Serving，而是更可靠的 Agent Runtime。 这也正是我在 Ark Agentic Runtime 分析和 Agentic Runtime 的现实主义中反复强调的方向，Agent 正在从“一个被 import 的类”变成“一个需要被治理的 workload”。

总结

这篇论文真正的贡献，是把 Agentic AI 的可靠性问题重新归类。它不再是一个模型问题，也不再是一个 prompt 工程问题，而是一个分布式系统问题，而且是一个有状态、长期运行、会自主决策的分布式系统问题。

对于 AI Infra 从业者，这意味着两件事。第一，传统 SRE 的工具箱（检查点、冗余、心跳、断路器、RTO/RPO）可以直接迁移过来，但必须扩展到“行为层”。第二，基础设施的关注重心将从“如何更快地 Serving 模型”转向“如何更可靠地运行 Agent”，也就是 Agent Runtime。

未来的 AI 平台，不仅要跑得快，更要跑得稳。

参考资料

从 GPU 到 Token：AI 基础设施的八层可观测性体系

Jimmy Song — Tue, 09 Jun 2026 03:31:16 +0000

GPU 利用率不是终点，Token 成本才是 AI 基础设施真正的北极星指标。

过去几年，AI 基础设施领域最热门的话题之一是 GPU 调度。无论是 Kubernetes、Volcano、Kueue，还是 HAMi，本质上都在解决同一个问题——如何让昂贵且稀缺的 GPU 被更高效地利用。

但随着越来越多企业开始运行生产级大语言模型（LLM）服务，一个新的现象开始出现：GPU 利用率很高，但用户仍然抱怨系统响应慢；GPU 集群已经接近满载，但业务吞吐量却没有同步增长；显存和算力都还有余量，TTFT（Time To First Token，首 Token 延迟）却持续恶化。这说明一个问题——GPU 利用率已经不足以描述现代 AI 系统的真实运行状态。

对于传统云原生应用来说，我们关注的是 CPU、内存、网络和磁盘。而对于 AI 系统而言，我们还需要关注：GPU 是否真正完成了有效计算、NCCL（NVIDIA Collective Communications Library）通信是否成为瓶颈、Kubernetes 是否正确分配了资源、KV Cache 是否已经耗尽、Token 延迟是否满足用户体验要求、每个 Token 的成本是否合理。换句话说，AI 基础设施的观测对象已经从 GPU 扩展到了整个推理链路。

最近我在参与中国信息通信研究院（CAICT）组织的《算力效能提升技术能力要求：异构算力服务》行业标准制定工作时，与多位专家讨论中反复提到一个核心问题：GPU 和 Token 到底怎样联系起来？如何通过 Token 来衡量 GPU 的产出？ 标准中提出了“词元即服务（Token as a Service）”的概念，将算力服务的度量单位从传统的 GPU 小时推向了 Token，但如何建立从底层硬件到上层 Token 的完整可观测链路，仍然缺乏成熟的实践框架。

恰好在研究这个问题时，看到一篇关于 GPU 与 LLM 可观测性的技术文章（GPU & LLM Inference Observability — Layer-by-Layer Coverage），提出了一个很有建设性的思路：将 AI 系统拆分为从 GPU 硬件到业务成本的八个观测层次，恰好填补了从 GPU 到 Token 之间的观测空白。本文在原文基础上进行了重新整理和解读，去除了具体产品实现细节和厂商推广内容，并结合 Kubernetes、HAMi 与现代 LLM 推理架构，对这套模型进行了扩展。

希望通过这篇文章回答一个问题：

当我们解决了 GPU 调度问题之后，下一步应该观测什么？

八层可观测性架构概览

下面展示了从 GPU 硬件到业务成本的八层观测栈，每一层对应不同的观测对象和责任域：

图 1: AI 基础设施八层可观测性架构

原图来源 GitHub，基于原图翻译并修改。

各层通过 OTel Collector 统一采集数据，分别输出到指标后端、链路追踪后端和日志后端，形成完整的观测闭环。以下逐层展开。

L1 GPU 硬件层

这一层关注 GPU 本身，核心问题是：GPU 是否健康运行？

下表列出了 GPU 硬件层的核心观测指标：

分类	核心指标
Compute	GPU Utilization、SM Occupancy、Tensor Core Activity
Memory	VRAM Usage、HBM Bandwidth
Interconnect	NVLink Throughput、PCIe Throughput
Reliability	ECC Error、XID Error
Thermal	Temperature、Power Draw、Throttle Reason

表 1: GPU 硬件层关键指标

很多团队只关注 GPU Utilization，但需要注意一个关键区分——GPU Utilization ≠ GPU Efficiency。两个 GPU 都可能显示 90% Utilization：一个正在执行 Tensor Core 运算，一个正在等待内存访问，最终性能可能完全不同。因此 SM（Streaming Multiprocessor）Occupancy 与 Tensor Core Activity 往往比 Utilization 更有价值。

L2 CUDA 运行时与通信层

对于分布式训练而言，GPU 计算通常不是瓶颈，通信才是。这一层的核心问题是：GPU 在计算，还是在等待其他 GPU？

下表列出了 CUDA 运行时与通信层的关键指标：

分类	指标
NCCL	AllReduce、AllGather、ReduceScatter
Communication	Duration、Bandwidth
Kernel	Execution Time、P99 Duration
Straggler	Rank Skew

表 2: CUDA 运行时与通信层关键指标

在大规模训练场景中，一个慢节点就可能拖慢整个训练任务。通过监控 NCCL 通信的 Duration 和 Bandwidth，以及各 Rank 之间的 Skew，可以快速定位通信瓶颈。

L3 宿主机与操作系统层

很多 GPU 问题最终都不是 GPU 问题。当 GPU 利用率异常时，原因可能在宿主机的 CPU、内存、磁盘或网络层面。

下表列出了宿主机层面的关键指标：

分类	指标
CPU	Utilization、IO Wait
Memory	Usage、Swap
Disk	Throughput、Latency
Network	Retransmit、Bandwidth
Process	RSS、Thread Count

表 3: 宿主机与操作系统层关键指标

一个常见的误区是：GPU 利用率低，第一反应是 GPU 不够快。实际上经常是 GPU 正在等待数据——DataLoader 太慢、CPU 不足、网络拥塞或存储性能不足，都可能导致 GPU 处于等待状态。

L4 Kubernetes 与调度层

这一层是云原生 AI 基础设施的核心，要回答的问题是：GPU 属于谁？ 需要明确哪个 Pod 正在使用 GPU、哪个 Namespace 消耗最多资源、哪个团队成本最高、哪个模型占用了最多显存。

下表列出了调度层的关键观测维度：

分类	关键属性
Ownership	Pod、Container
Workload	Deployment、Job
Organization	Namespace、Team
Scheduling	GPU Sharing、GPU Partition
Topology	Node、AZ、Region

表 4: Kubernetes 与调度层关键维度

HAMi、Volcano、Kueue 等项目主要工作在这一层。HAMi 解决 GPU Sharing、GPU Partitioning 和异构 GPU 调度等核心问题，而可观测性则负责回答：调度之后是否真正提升了资源利用率？ 这一层的观测数据是资源审计和成本分摊的基础。

L5 训练运行时层

训练阶段需要关注模型本身的运行状态。下表列出了训练运行时的关键指标：

分类	指标
Efficiency	MFU、TFLOPS、Step Time
Gradient	Norm、NaN、Inf
Loss	Training Loss
Data	DataLoader Wait
Checkpoint	Save Time、Restore Time

表 5: 训练运行时关键指标

其中最重要的是 MFU（Model FLOPs Utilization，模型算力利用率）。很多训练任务 GPU 利用率很高，但 MFU 只有 30%，这意味着大量 GPU 时间并没有转化成实际训练进度。MFU 是衡量训练效率的黄金指标，它直接反映了硬件算力转化为有效训练计算的比例。

L6 推理引擎层

这是生产环境最关键的一层，也是目前行业关注度增长最快的一层。下表列出了推理引擎的核心指标：

指标	含义
TTFT	Time To First Token
ITL	Inter Token Latency
Queue Wait	请求排队时间
Throughput	Token 吞吐量
Batch Size	批处理效率
KV Cache Usage	KV Cache 利用率

表 6: 推理引擎关键指标

很多团队仍然只关注 GPU Utilization，而推理系统真正的容量指标往往是 KV Cache（Key-Value Cache）Utilization。

为什么 KV Cache 比 GPU Utilization 更重要

在现代 LLM 推理系统中，GPU 算力通常还有余量，但 KV Cache 往往先耗尽。典型现象是：GPU 利用率只有 60%，KV Cache 已经达到 95%，新请求开始排队，TTFT 快速上升。

对于推理系统而言，KV Cache 更接近于数据库中的 Buffer Pool——它往往决定整个系统的容量上限。当 KV Cache 接近饱和时，系统不得不进行 Eviction（驱逐），这会导致上下文丢失、请求重试，最终表现为延迟飙升和吞吐下降。

L7 生成式 AI API 层

随着 OpenTelemetry GenAI Semantic Conventions 的发展，行业正在形成统一的 AI 可观测性标准。下表列出了 API 层的关键指标：

指标	含义
Input Tokens	输入 Token
Output Tokens	输出 Token
Request Duration	请求耗时
TTFT	首 Token 延迟
Token Throughput	Token 吞吐量

表 7: GenAI API 层关键指标

这一层开始从基础设施视角转向应用视角。API 层的指标直接面向终端用户和业务系统，是服务质量评估（SLA/SLO）的核心数据来源。

L8 业务与成本层

最终企业关心的不是 GPU 利用率，而是：GPU 是否创造了价值？ 下表列出了业务与成本层的核心指标：

指标	含义
Cost per GPU Hour	GPU 小时成本
Cost per Token	Token 成本
Cost per Request	请求成本
Idle GPU Cost	空闲成本
Tokens per Watt	推理效率

表 8: 业务与成本层关键指标

未来 AI 基础设施竞争的核心指标，很可能不是 GPU Utilization，而是 Cost per Useful Token——每产生一个有效 Token 的综合成本。这个指标将硬件成本、能源消耗、推理效率和业务价值统一在一个度量体系内。

跨层故障排查

真正的生产问题往往跨越多个层次。下表列出了常见的跨层故障现象及其可能原因：

现象	可能原因
TTFT 升高	CPU IO Wait、Queue Depth、KV Cache Pressure
Throughput 降低	NCCL、Batch Size、Network
Latency Spike	KV Cache Eviction
OOM	VRAM 不足、Batch 过大
Training Stall	NCCL Straggler

表 9: 跨层故障排查参考

现代 AI 运维正在从单点监控演变为跨层观测。单层指标异常的根因往往在其他层，只有建立跨层关联能力，才能实现快速定位和精准排障。

从 GPU 控制面到 AI 可观测面

过去几年行业主要关注 Kubernetes Scheduler、Volcano、Kueue、HAMi 等项目，解决的是 GPU 如何分配 的问题。未来几年行业会开始关注 GPU 是否真正产生价值，因此 AI 基础设施正在形成新的技术栈：

GPU Hardware
↓
Kubernetes Control Plane
↓
Inference Runtime
↓
Observability Plane
↓
Optimization Plane

GPU 调度决定资源如何分配，Observability 决定资源是否被正确使用，而这两者共同构成下一代 AI Infrastructure Stack。从 GPU Control Plane 到 AI Observability Plane 的演进，标志着 AI 基础设施从“资源管理”走向“价值管理”的新阶段。

总结

AI 基础设施的可观测性正在经历一次根本性的范式转变。过去我们只看 GPU 利用率，现在需要从 GPU 硬件、CUDA 运行时、宿主机操作系统、Kubernetes 调度、训练运行时、推理引擎、GenAI API 到业务成本八个层次建立完整的观测体系。

关键要点回顾：

L1-L3 关注硬件与系统：GPU 健康状态、CUDA 通信效率、宿主机资源是否充足
L4 关注资源分配：Kubernetes 调度和 GPU 共享是否合理，HAMi 等工具解决分配问题
L5-L6 关注模型运行：训练效率（MFU）和推理容量（KV Cache）是核心指标
L7-L8 关注业务价值：从 Token 吞吐到每 Token 成本，最终衡量 GPU 是否创造了价值

GPU 调度是 AI 基础设施的起点，但不是终点。从 GPU 到 Token 的八层可观测性体系，才是确保 AI 基础设施真正创造业务价值的关键闭环。

参考文献

GPU & LLM Inference Observability — Layer-by-Layer Coverage - GitHub

我的 Personal AI Stack：每月 700 元构建一个持续运行的个人 AI 基础设施

Jimmy Song — Sun, 07 Jun 2026 16:58:18 +0800

个人 AI 基础设施不是单一工具，而是长期协同的系统。

图 17: 我的 Personal AI Stack

很多人在讨论 AI Agent、第二大脑（Second Brain）、个人知识管理（PKM）和数字分身。

但过去一年，我逐渐意识到，我真正构建的并不是某个 AI 助手，而是一套持续运行的个人 AI 基础设施（Personal AI Infrastructure）。

它不是某个产品，也不是某个模型，而是一组长期协同工作的系统。

这套系统每天帮助我思考、研究、写作、开发、管理知识、处理邮件、维护网站，并持续积累长期记忆。

如果用一句话概括：

ChatGPT 负责思考，OpenClaw 负责执行，Obsidian 负责记忆，GitHub 负责发布。

从工具到基础设施

大部分 AI 工作流文章的结构都差不多，先讲模型、插件、编辑器。

但我越来越觉得，工具不是重点。

重点是这些工具如何协同工作。

我的工作横跨：

AI 基础设施研究
开源社区运营
技术写作
Developer Relations
产品与生态建设

每天都会产生大量信息：

ChatGPT 对话
技术研究
GitHub 活动
社区讨论
邮件订阅
Hacker News
Discord
微信和飞书消息

问题从来不是缺少信息，而是如何组织信息。

因此我逐渐搭建出了一套围绕自己工作的 Personal AI Stack。

工作流视角

这不是一个单点工具，不是一个模型。它强调的是“思考、记忆、执行、发布”四个层级的持续协同。

整体架构

下面这个架构图展示了我的 Personal AI Stack 如何分层协同。

图 18: Personal AI Stack 架构层次

不同层级对应的核心组件如下。

层	组件
Interface Layer	ChatGPT、Telegram、Discord、飞书、微信
Reasoning Layer	ChatGPT、GLM-5.1、Claude Code、Codex
Memory Layer	Obsidian、Markdown、iCloud
Execution Layer	OpenClaw、Gmail、Calendar、Lark CLI
Publishing Layer	GitHub、Hugo、Cloudflare Pages

表 5: Personal AI Stack 层级与组件

ChatGPT：我的思考系统

虽然很多工作流围绕 Agent 展开，但我使用频率最高的其实是 ChatGPT。

我主要用它：

Deep Research
技术分析
架构讨论
内容策划
写作辅助
职业决策

与其说它是助手，不如说它更像：

Research Partner
Technical Advisor
Thinking Companion

过去几年持续积累的大量对话，让它逐渐理解了我的背景、项目和长期目标。

很多文章、演讲和技术判断，实际上都来自这种持续对话。

OpenClaw：我的执行系统

OpenClaw 是我部署在家里 Mac mini M4 上的 OpenClaw Agent。

平时主要通过 Telegram 与 OpenClaw 交互。

为了避免上下文混杂，我专门使用不同 Telegram 群组管理不同主题：

HAMi
AI Handbook
Personal
Work
Research
Blog

这样天然形成了 Context Isolation。

OpenClaw 负责：

Gmail 邮件管理
Apple Calendar 日程管理
定时任务
Obsidian 操作
GitHub 操作
网站维护
飞书知识库操作
自动化工作流

它更像一个 Chief of Staff，而不是聊天机器人。

OpenClaw 定位

OpenClaw 的价值在于把分散的执行入口统一成结构化的工作流，而不是简单的聊天界面。

OpenClaw 的工作流

OpenClaw 的主要路径是通过 Telegram 入口展开多端执行。

图 19: OpenClaw 执行路径

飞书：公司工作流入口

我以前几乎没有使用过飞书。

加入现在的公司之后，公司整体提倡使用飞书，日常工作流、知识库、协作沟通都在飞书里进行。

刚开始我只是把它当成一个企业 IM 工具。

但现在看，飞书更像是公司级的工作流入口：

群聊
文档
知识库
审批
任务
自动化

对我来说，真正改变使用体验的是 Lark CLI。

通过 Lark CLI，我可以更方便地管理公司的知识库、文档和一些流程化信息。

这让飞书不只是一个聊天工具，而是可以被 OpenClaw 纳入自动化系统的一部分。

从个人 AI Stack 的角度看，飞书承担的是：

工作组织层。

它连接的是公司语境下的信息、知识和任务。

Obsidian：工作记忆（Working Memory）

Obsidian 是我最常用的知识工具。

但我并不把它视为最终知识库。

对于我来说：

Obsidian
=
工作记忆

这里存放：

Daily Notes
Weekly Reports
Research Notes
Inbox
Drafts
临时想法

三年前开始，我养成了持续写周报的习惯。

这些周报记录了：

工作进展
学习内容
社区活动
项目演进
个人思考

从某种意义上说，周报构成了我的日常记忆。

而 Obsidian 则是这些记忆的载体。

GitHub 与 jimmysong.io：长期记忆（Long-term Memory）

很多人会把博客理解为内容发布平台。

但对于我来说，jimmysong.io 更接近于我的长期记忆系统。

这个网站已经持续维护接近十年。

这里记录的不只是技术文章，更重要的是：

我的观点
我的判断
我的经验
我的成长轨迹

与 Obsidian 不同，能够进入网站的内容，通常都经过：

研究
↓
思考
↓
验证
↓
写作
↓
修改
↓
发布

因此：

Obsidian
=
工作记忆

jimmysong.io
=
长期记忆

下面这个流程展示了从 Obsidian 到网站发布的基本路径。

图 20: 长期记忆发布流程

信息流

内容的来源、整理方式和输出渠道之间有清晰的边界，这张图揭示了我的信息流逻辑。

图 21: Personal AI Stack 信息流

GitHub：执行与发布层

GitHub 对我来说已经不仅仅是代码仓库。

它同时承担：

博客内容
网站源码
文档系统
AI Handbook
AI Native Landscape

所有内容最终都会进入 GitHub。

GitHub Actions 自动完成：

构建
测试
发布

最后通过 Cloudflare Pages 提供服务。

下面这张图展示了从 Markdown 到静态站的发布路径。

图 22: GitHub 发布管道

我的开发工具链

目前主要使用三套 AI 开发工具。

Claude Code

我的日常开发主力。

虽然名字叫 Claude Code，但目前主要使用智谱 GLM-5.1。

负责：

编码
重构
调试
文档维护

Codex

主要用于：

初始化项目
大规模代码生成
自动执行复杂任务

OpenClaw

负责开发之外的自动化工作。

三者形成明确分工。

下面这张图展示了我的工具链协作方式。

图 23: 开发工具链协作

为什么不用 Claude？

这是我被问得最多的问题之一。

客观来说，Claude 在代码生成和代码理解方面确实非常强。

我也认真考虑过使用 Claude 作为主力模型。

但最终没有采用。

原因并不是模型能力，而是整体投入产出比。

首先是账号问题。

过去我多次注册 Claude 账号，都遇到过限制和封禁问题。

其次是成本问题。

因为我的所有 AI 工具都是自己付费。

所以我更关注：

能力 / 成本

而不是：

绝对能力

对于企业用户来说，Claude Max 可能是非常合理的选择。

但对于个人付费用户而言，结论可能不同。

这篇文章讨论的，是完全由我个人支付的 Personal AI Stack。

如果公司报销，或者拥有企业预算，那么很多选择都会发生变化。

为什么不自己部署大模型？

这是另一个高频问题。

很多人认为：

买一张显卡 + 开源模型 = 免费 AI

实际上往往并不是这样。

如果只是为了获得一个稳定、强大的 AI 助手，我更倾向：

订阅 > 自建

原因包括：

时间成本

维护模型本身就是工作。

包括：

CUDA
驱动
推理框架
模型升级
网络问题

这些都需要时间。

而我希望把时间花在：

写作
社区
产品
技术研究

成本问题

目前：

ChatGPT Plus
GLM Coding Plan Max

每月总成本不到 600 元。

而一张高端 GPU：

RTX 5090D
RTX PRO
企业 GPU

通常需要数万元。

再加上：

电费
折旧
维护

对于我的场景来说并不划算。

模型升级速度

云端模型每个月都在升级。

而本地模型需要自己跟进。

对于知识工作者来说：

使用最新模型比拥有模型更重要。

订阅与自建

对于个人使用者，订阅服务通常在时间成本、升级速度和稳定性上更具优势。它让你把精力集中在结果，而不是基础设施维护。

日常工具

除了前面介绍的核心系统之外，我还依赖一些日常工具来完善整个工作流。

Atlas Browser：目前的主力浏览器，用于网页阅读、研究和信息收集，优秀内容会通过 Obsidian Clipper 保存到知识库。
Warp：我最常使用的终端工具，现代化的交互体验和 AI 能力让命令行工作更加高效。
Typora：长期使用的 Markdown 编辑器，适合沉浸式写作和长文编辑，很多博客和文档都在这里完成。
CodexBar：用于监控 ChatGPT、Codex、Claude Code 等工具的使用情况。对于重度 AI 用户来说，Token 消耗已经成为一种需要关注的资源指标。
搜狗输入法：我目前主要使用的语音输入工具。相比键盘输入，语音更符合我的思考习惯，尤其是在远程办公、写作和与 AI 交流时效率更高。

这些工具本身并不是系统的核心，但它们构成了整个 Personal AI Stack 的基础体验层，让信息获取、内容创作和日常开发更加顺畅。

我的 AI 使用规模

目前大致消耗：

GLM-5.1

每周：

6 亿 Token

每月：

24 亿 Token

Codex

每周：

2 亿 Token

每月：

8 亿 Token

合计：

每月约 32 亿 Token

大概每天消耗 1 亿 Token。通过 ChatGPT Plus 和 GLM Coding Plan 订阅比起直接充值还是很划算的，不然这些 Token 每月至少要花 500 美元。

这套系统每个月花多少钱？

下面的表格对比了各项固定月度成本。

服务	月费用
ChatGPT Plus	$19.99
GLM Coding Plan Max	¥422.1
iCloud+	$0.99

表 6: 月度成本构成

约：

¥573 / 月

OpenClaw 运行在我的 Mac mini M4 上。

硬件包括：

Mac mini M4
Samsung 990 Pro 1TB
HAGIBIS 扩展坞

总投入约：

¥4469

按四年折旧：

约 100 元 / 月

总成本

整个 Personal AI Stack 固定成本约：

700 元人民币 / 月

这张成本饼图展示了 Personal AI Stack 的月度支出结构。

图 24: Personal AI Stack 月度成本估算

FAQ

这是不是最强配置？

不是。

这不是“最强 AI 工具配置指南”。

这是一个完全自费、面向个人长期使用的 Personal AI Stack。

如果公司报销，或者你有更高预算，可以选择 Claude Max、Cursor、更多 API 服务，甚至本地 GPU 工作站。

但我的目标不是追求绝对最强，而是在个人预算内获得稳定、可持续、可积累的生产力。

为什么不全量同步 ChatGPT 对话到 Obsidian？

因为我不想把 Obsidian 变成聊天记录仓库。

我更关心：

哪些内容值得长期保存？

手动保存本身就是一次筛选。

这比自动同步全部内容更重要。

为什么不用 Notion？

不是因为 Notion 不好。

而是因为我更偏向 Markdown First。

Markdown 的好处是：

本地优先
可版本管理
可迁移
AI 友好
适合长期保存

为什么 Telegram 只用来对接 OpenClaw？

因为 Telegram 的 Bot 生态和 API 更适合做 Agent 入口。

而微信、飞书、Discord 对我来说更多是人与人之间的沟通和社区协作工具。

为什么强调飞书？

因为加入现在的公司后，我才真正开始使用飞书。

公司整体工作流都围绕飞书展开。

对我来说，飞书不是个人知识库，而是公司知识和协作系统。

通过 Lark CLI，它可以进一步变成 OpenClaw 能够操作的工作流入口。

为什么不用本地 AI 工作站？

因为我的主要工作不是训练模型，也不是运营推理服务。

我的主要工作是：

思考
研究
写作
开源社区
软件开发

订阅模型 + Mac mini 已经足够。

本地 AI 工作站投入大、维护复杂，而且模型升级速度未必跟得上云端服务。

为什么不买高端 NVIDIA GPU？

如果主要目的是学习 CUDA、GPU 调度、AI Infra，购买 GPU 有价值。

但如果主要目的是日常生产力，那么高端 GPU 并不一定划算。

对于我来说：

订阅模型比拥有 GPU 更重要。

工作流比模型更重要

过去一年最大的体会是：

很多人认为 AI 的核心是模型。

但我的体验恰恰相反。

真正影响生产力的往往不是模型排行榜，而是工作流设计。

一个 95 分的模型放在优秀工作流里，通常比一个 100 分的模型放在混乱工作流里更有价值。

从某种意义上说，这和云原生世界的发展过程非常相似。

GPU 很重要，但调度系统同样重要。

模型很重要，但工作流同样重要。

Agent 很重要，但长期记忆和执行系统同样重要。

对于我来说，Personal AI Stack 的最终目标并不是替代人。

而是把思考、记忆和执行连接起来，让更多时间留给真正重要的事情。

总结

这篇文章把我的 Personal AI Stack 定义为长期可运行的基础设施，而不是单一工具或单一模型。

核心结论是：在个人付费场景下，稳定的工作流、持续的记忆系统和可执行的自动化，比追求最强模型更能提升生产力。

如果你的目标是长期累计价值，那么把时间放在“协同方式”上，往往比把时间放在“模型排名”上更有回报。

Token 不只是计费单位，它正在成为 AI 时代的新资源单位

Jimmy Song — Thu, 04 Jun 2026 06:41:47 +0000

最近 Linux Foundation 宣布计划成立 Tokenomics Foundation。

图 1: Tokenomics Foundation

刚看到这个消息时，我的第一反应并不是：

又多了一个基金会。

而是：

AI 基础设施正在从「管理 GPU」走向「管理 Token」。

这可能比基金会本身更值得关注。

Linux Foundation 给出的官方理由很简单：

随着企业开始大规模部署生成式 AI 和 Agent，Token 已经成为新的技术支出单位（Unit of Technology Spend）。未来基金会将与 FinOps Foundation 合作，建立 Token 成本管理、Benchmark、开放标准和最佳实践。

如果只是看到这里，很多人会把它理解成：

FinOps for AI

或者：

AI 成本管理

但我觉得事情没有这么简单。

云时代管理的是资源

过去二十年，基础设施行业一直在管理资源。

我们讨论：

CPU
Memory
Storage
Network
GPU

Kubernetes 也是如此。

无论是调度器、自动扩缩容还是资源配额，本质上都在回答一个问题：

资源怎么分配？

这是云时代的核心命题。

AI 时代开始管理结果

AI 出现后，一个有趣的变化开始发生。

企业越来越不关心：

用了多少 GPU

而更关心：

产生了多少 Token

对于大多数企业来说：

GPU 是成本。
Token 才是产出。
GPU、CPU、内存只是生产资料。
Token 才是最终交付物。

J.R. Storment（FinOps Foundation 前执行董事）在 LinkedIn 上有一句话让我印象很深：

Tokens are what all the hardware is being built to produce.

所有硬件最终都在生产 Token。

从这个视角看：

GPU
 ↓
Inference
 ↓
Token

开始形成新的价值链。

Token 可能成为新的资源模型

过去几年我一直在关注 Kubernetes 在 AI 时代的演化。

越来越多的信号表明：

Kubernetes 正在从一个 Compute Control Plane 演化为 AI Control Plane。

而当 AI 成为主流工作负载后，我们管理的资源可能不再只是：

cpu: 8
memory: 32Gi
gpu: 1

而会逐渐变成：

token
context
latency
throughput

这些更接近业务价值的指标。

Tokenomics Foundation 最有意思的地方，不是它会不会定义新的标准。

而是它隐含承认了一件事：

Token 已经开始成为一种资源。

就像 CPU 在云时代那样。

对 AI Infra 的启发

对于做 AI Infra 的团队来说，这个变化值得认真思考。

今天很多项目（包括 HAMi）讨论的是：

GPU 利用率
GPU 共享
GPU 调度
GPU 虚拟化

这些都很重要。

但站在企业视角，他们最终不会采购 GPU 利用率。

他们采购的是：

Cost Per Token

甚至进一步：

Value Per Token

同样一批 GPU：

谁能够产生更多 Token，
谁能够降低每百万 Token 的成本，
谁能够提升每个 Token 的业务价值，

谁就拥有更大的商业价值。

这也是为什么我认为 Tokenomics Foundation 的意义不在于标准本身。

而在于它正在推动整个行业从：

资源管理

走向：

价值管理

我的判断

我不认为 Tokenomics Foundation 会成为下一个 Kubernetes。

它更像 FinOps Foundation、OpenCost 或 OpenTelemetry。

它试图定义的不是软件。

而是 AI 时代的计量体系。

过去十年：

CPU 是基础设施语言

未来十年：

Token 可能成为 AI 基础设施语言

如果这个趋势成立，那么我们今天讨论的 GPU、推理框架、调度系统、Agent Runtime，本质上都只是更大 Token 经济体系中的一部分。

而这，可能才是 Linux Foundation 这次成立 Tokenomics Foundation 真正想表达的信号。

AI 原生全景图独立上线：landscape.jimmysong.io

Jimmy Song — Thu, 04 Jun 2026 06:12:16 +0000

AI 原生全景图有了自己的家。600+ 精选开源项目，全新独立站点，支持 AI 编程工具直接搜索。

缘起

去年七月，我开始在个人网站上收集和整理 AI 开源项目。当时 AI 领域发展太快了，每天都有新的项目冒出来，GitHub 就是一个巨大的宝库，里面有太多值得我们学习和使用的好东西。我想把这些项目系统地整理出来，方便自己也方便大家找到真正有用的工具和框架。

一开始这些数据都放在 jimmysong.io 主站里面，但随着收录的项目越来越多，维护起来越来越吃力。主站本身内容就不少，AI 相关的页面混在里面，更新一个项目数据得重新构建整个站点。所以今年索性把它独立出来，作为一个单独的开源项目来维护和迭代，这就是 ai-native-landscape。

原 jimmysong.io/zh/ai/* 路径下的所有页面已重定向至新站点 landscape.jimmysong.io，原有链接和书签不受影响。

不只是收录，还有评分

市面上的 AI 项目导航不少，但大多只是收录一个名字和链接就完事了。我觉得这不够。

GitHub 上的项目成千上万，你看到一个项目名字，点进去一看，上次更新还是半年前，Issue 也没人回复，这种项目你花时间研究了半天结果发现已经不维护了，挺浪费时间的。

所以 AI 原生全景图做了一件不一样的事：给每个项目打分。

评分基于四个维度：

活跃度（Activity）：提交频率、发布节奏、Issue 响应速度
社区（Community）：贡献者数量、PR 合并速度、讨论活跃度
质量（Quality）：Star 数、Fork 数、被依赖关系
持续性（Sustainability）：维护年限、团队稳定性

四个维度综合起来得到一个健康度分数，让你一眼就能看出这个项目值不值得花时间去研究和使用。

而且这个评分是每日自动更新的，不是静态数据。今天去看和明天去看，分数可能就不一样了。

项目列表也是人工维护的。有些项目虽然开源了但已经很久不活跃了，这样的就不会收录进来。我希望这个列表里的每个项目都是"活的"，你在上面花时间研究不会白费。

目前收录情况

目前覆盖了 AI 领域的八大方向：

分类	说明
智能体系统	Agent 框架、编排与工作流
知识与上下文工程	RAG、向量数据库、文档处理、知识图谱
模型与多模态	基础模型、模型工具链、语音与视觉生成
推理与运行时	模型服务、推理引擎、沙箱、GPU 加速
训练、评测与优化	训练框架、微调对齐、评测基准、可观测性
开发者工具链	MCP 协议、编程智能体、IDE 工具、SDK
应用与体验	聊天界面、工作流自动化、低代码平台
平台与基础设施	云原生 AI、数据平台、安全与运维

截止目前，已收录 600+ 个开源项目，每个项目均提供中英双语描述。

AI Skill 搜索

全景图支持 AI 编程工具直接搜索，不用打开浏览器。一行命令安装：

npx landscape-search

支持 Claude Code、Cursor、GitHub Copilot、OpenAI Codex、Cline、Aider 等主流 AI 编程工具。安装后直接用自然语言搜索就行：

“帮我找一个支持 MCP 协议的 Agent 框架”

无需 API Key，无需本地数据文件，AI 工具会实时拉取最新的项目目录并返回匹配结果。

技术栈

项目用 Astro 构建，部署在 Cloudflare Pages 上，用 TypeScript 保证类型安全。数据以双语 Markdown 文件存储，构建时自动校验、索引和生成 OG 图片。

欢迎参与

GitHub 是大家的宝库，这个项目也希望能靠社区的力量越做越好。

Star 项目：github.com/rootsongjc/ai-native-landscape

提交开源项目：如果你发现某个值得收录的 AI 开源项目，欢迎通过以下方式提交：

在 GitHub 上提交 Issue
或直接提交 PR，在 data/projects/ 目录下添加双语 Markdown 文件

贡献流程详见贡献指南。

链接：

线上站点：landscape.jimmysong.io
GitHub 仓库：rootsongjc/ai-native-landscape
Skill 安装：npx landscape-search

Kubernetes 正在成为 AI 时代的 GPU Control Plane：从 HAMi v2.9 看下一代 AI Infra 的演化

Jimmy Song — Thu, 14 May 2026 06:33:18 +0000

最近在关注国产 GPU 调度和 Kubernetes AI 资源模型的进展，正好 HAMi 发布了 v2.9，就借着这个版本聊聊我对 AI Infra 控制面演化的几个观察。

图 1: Kubernetes 正在成为 AI 时代的 GPU 控制面

为什么现在聊这个话题

2025 年初 DeepSeek R1 发布的时候，很多人关注的是“只花了 560 万美元就训出了能打 OpenAI o1 的模型”。但我当时想的另一件事是：推理成本暴跌之后，GPU 利用率的问题会立刻暴露出来。

果然模型越来越好用，推理需求爆炸式增长，“一张卡跑一个模型”变得越来越奢侈。与此同时，NVIDIA H200 的出口闹剧也直接加速了国产算力的替代进程。先禁售，2025 年底特朗普又开绿灯加了 25% 关税，结果 2026 年 1 月中国海关实际放行数为零。政策层面明确要求 2026 年数据中心国产芯片使用率超过 40%。

现实就是这么骨感：你不但 GPU 不够，而且你得学会同时用好 NVIDIA、昇腾、寒武纪、海光这些完全不一样的东西。

所以 HAMi v2.9 这个版本，我觉得比表面看到的要重要一些。

GPU 不再是一张卡的事

Kubernetes 管理 GPU 的方式一直很粗糙：

resources:
 limits:
 nvidia.com/gpu: 1

这在 2019 年够用，毕竟当时的问题就是一个 Pod 要不要一张 GPU，是或否的问题。

但现在不行了。一个推理服务可能只需要 4GB 显存，一批小模型可以共享一张卡，训练任务要关心 GPU 拓扑和跨卡互联带宽，多租户还要隔离故障域。把 GPU 继续当整数资源管，就像用算盘做统计分析，不是不能用，是思维模型跟不上现实了。

HAMi v2.9 里最值得注意的特性是昇腾 910C 的 HAMi-core 模式。以前昇腾卡共享靠 SR-IOV 硬件虚拟化，粒度粗、不灵活。HAMi-core 换了个思路：用 LD_PRELOAD 在用户态拦截 ACL 调用，实现 MB 级显存隔离和百分比级算力限流。

说白了就是：不靠硬件切，靠软件管。

这跟当年 SDN 把网络控制面从硬件设备里抽出来的路径很像，GPU 切分正在从硬件能力变成集群控制面的能力。考虑到华为昇腾 910C 去年出货了 81 万张、占据国产芯片近半壁江山，这个能力的实际影响面不小。

DRA：Kubernetes 终于有了像样的设备资源模型

Kubernetes v1.34（2025 年 9 月）正式把 DRA（Dynamic Resource Allocation）推向 GA，Red Hat OpenShift 4.21 紧随其后也 GA 了。这不是小事。

Device Plugin 当年解决了“怎么把 GPU 接进 K8s”的问题，但没解决“怎么表达复杂 AI 资源需求”的问题。Device Plugin 只知道节点上有几块卡，不知道你要多少显存、什么拓扑、哪种隔离级别。

DRA 通过 ResourceClaim 和 DeviceClass 把设备资源的声明、分配和管理标准化了。HAMi-DRA 的做法比较务实：没有要求用户改用法，而是通过 Mutating Webhook 把现有 Device Plugin 风格的声明自动转换成 DRA 模型。旧系统不用改，新能力照样用。

我把它类比成当年 CSI 对存储的意义：不是消灭厂商差异，而是让 Kubernetes 能用统一方式消费不同厂商的存储能力。DRA 对 AI 加速器也类似，NVIDIA、昇腾、AMD、Vastai 这些卡永远不会完全一样，但调度层面应该有统一语言。

一条完整的控制面路径

如果跳出版本特性，把 HAMi-core、DRA、CDI、调度器放在一起看，它们其实对应 GPU 资源管理链路的不同层次：

HAMi-core：设备内部怎么切、怎么隔离
DRA：资源怎么声明、分配、绑定
CDI：设备怎么标准化注入容器运行时
调度器/Webhook：怎么调度、准入、观测

把这些层次串起来，从上到下就是 Kubernetes 作为 GPU Control Plane 的完整链路：

图 2: Kubernetes 作为 AI 工作负载的 GPU 控制面

这是一条完整的控制面路径。v2.9 里的 Volcano vGPU 升级到 v0.19 并增强 CDI 支持，看似是设备注入方式的小改进，实际上补齐了这条链路里的关键一环。

异构才是国内 AI Infra 的主战场

国内 AI 集群的现实是：你不可能只围绕一种 GPU 来建设基础设施。

企业环境里经常同时存在 NVIDIA、昇腾、燧原、寒武纪、海光、沐曦、昆仑芯、瀚博等设备，每种卡的驱动、运行时、虚拟化能力、监控方式都不一样。HAMi v2.9 新增瀚博半导体（Vastai）支持，累计覆盖十余种异构算力设备。训练和推理混部、在线和离线混部、国产和海外 GPU 混部、多团队多租户共用一个资源池，这种场景下，统一调度层比单卡性能重要得多。

几个判断

GPU 共享会从“省钱手段”变成默认需求。 推理场景爆发之后，不是所有 workload 都值得独占整张卡。整卡独占会越来越像一种奢侈的资源使用方式。

DRA 是方向，但迁移是渐进的。 Device Plugin 生态太大了，不会一夜消失。HAMi-DRA 的兼容层设计说明项目方也明白这一点。

异构调度会成为 AI Infra 的核心问题。 谁能把不同厂商设备抽象成统一调度语义，谁就占据控制面的关键位置。

Kubernetes 会被 AI workload 反向改造。 从调度语义到资源模型，AI 需要的表达能力远超传统 Web 服务。DRA、CDI、topology-aware scheduling 这些方向不是孤立演进，而是共同说明一件事：Kubernetes 正在从容器编排系统，向 AI 计算控制平面演化。

写在最后

HAMi v2.9 的意义不在于它支持了某个设备或某种切分方式，而在于它让一件事变得更清晰：下一代 AI 基础设施的竞争，不只是模型框架之争，也不只是 GPU 数量之争，而是控制面之争。

GPU 正在从节点上的外部设备，变成 Kubernetes 控制面里的原生资源。谁能定义 AI 时代的资源模型，谁就能定义 AI Infra 的长期边界。

Kubernetes 在 AI 浪潮下的“焦虑”与新生

Jimmy Song — Fri, 03 Apr 2026 05:20:28 +0000

Kubernetes 没有被 AI 取代，但它正被 AI 重新定义。焦虑，是新生的前奏。

在阿姆斯特丹参加完 KubeCon EU 2026 后，我一直在思考一个问题：Kubernetes 没有落伍，但它也不再“够用”；它没有被 AI 取代，却正在被 AI 重新定义。

图 1: KubeCon EU 2026 的 slogan：Keep Cloud Native Moving，本次会议注册人数超过 1.3 万人，再次成为注册人数最多的一届 KubeCon。

这是我第三次到欧洲参加 KubeCon，过去几年的 KubeCon，其实可以通过 slogan 看出社区心态的变化：

2024 巴黎：La vie en Cloud Native

→ 云原生已经成为“生活方式”，是默认存在
2025 伦敦：没有 slogan，只有 10 周年纪念

→ Kubernetes 达到阶段性顶点，开始回顾而不是前进
2026 阿姆斯特丹：Keep Cloud Native Moving

→ 但问题是：要往哪里 moving？

2025 年没有 slogan，本身就是一个信号：

当一个生态开始纪念过去，而不是定义未来，它就已经进入了一个拐点。

本文不回顾演讲内容，而是基于我在 KubeCon 的观察，提炼出关于 Kubernetes 在 AI 浪潮下的焦虑与新生的洞察。

焦虑的根源：Kubernetes 面临“危机”？

KubeCon 现场最大的变化，是 AI 彻底取代了传统云原生话题。讨论的重心从服务优化、微服务管理，转向了如何在 Kubernetes 上部署和管理 AI 工作负载，尤其是推理任务和 GPU 调度。

图 2: KubeCon 正式开始前的 Maintainer Summit，AI 成了唯一话题

Kubernetes 作为基础设施底座，曾是云原生世界的核心。随着 AI 模型爆发式增长，Kubernetes 是否还能作为“通用”平台承载一切，成为了新的焦虑点。

AI 的火热带来了现实问题：Kubernetes 的 “通用性”能否适应 AI 工作负载的复杂性？

AI 爆发带来的聚焦

AI 的火爆让云原生的焦点完全转向了人工智能。AI coding、OpenClaw、大模型、生成模型等技术引发了广泛关注。AI 已经成为现实世界的核心计算需求。

这种需求增长带来了疑问：Kubernetes 能否继续担当基础设施平台，承载复杂任务？尤其是 GPU 共享、推理模型调度、显存分配、设备属性选择等问题，传统 Kubernetes 资源模型是否足够？

过去，Kubernetes 承载了计算、存储、网络等基础设施。但 AI 加速发展下，其“通用性”正被挑战。尤其在推理任务层面，Kubernetes 的模型显得单薄。

与 OpenStack 的对比：Kubernetes 会重蹈覆辙吗？

OpenStack 曾雄心勃勃，试图成为完整的开源云平台，但最终因复杂性和对新技术适应的灵活性不足而未能持续成长。

Kubernetes 是否会步其后尘？我认为 Kubernetes 有不同优势：作为容器和微服务调度平台，已广泛应用，拥有强大社区和厂商支持；它并不试图取代云服务商所有能力，而是作为基础设施控制平面，帮助用户管理资源。

图 3: 云原生社区的贡献者依然活跃，参加 KubeCon EU 2026 的 Maintainer Summit 的人群显示云原生社区的活力。

但随着 AI 工作负载普及，Kubernetes 必须在不被“AI 优化平台”替代的情况下找到新定位。

Kubernetes 的挑战：GPU 资源管理的断裂

NVIDIA 在 KubeCon 上宣布捐赠 GPU DRA（动态资源分配，Dynamic Resource Allocation）驱动给 CNCF，标志着 GPU 资源管理的上游化。GPU 的共享与调度已成为 Kubernetes 亟需解决的问题。

传统上，Kubernetes 依赖 Device Plugin 模型调度 GPU，仅支持基于设备数量的分配（如 nvidia.com/gpu: 1）。但在 AI 推理任务中，需要更多信息来决定资源调度，比如显存大小、GPU 拓扑、共享策略等。NVIDIA DRA 让 GPU 资源管理更灵活智能，逐步缓解 AI 工作负载中的“GPU 资源紧张”问题。

这种变化意味着，Kubernetes 不再只是“容器调度平台”，而是成为处理 AI 专用资源调度的基础设施层。

在这种背景下，社区和产业侧已经开始探索更细粒度的 GPU 资源抽象与调度机制。例如开源项目 HAMi 尝试在 Kubernetes 之上构建一层面向 AI 工作负载的 GPU 资源管理层，支持 GPU 共享、显存粒度分配以及异构设备调度等能力。

图 4: KubeCon EU 2026 Keynote 上的 HAMi 演示

这类实践本质上并不是替代 Kubernetes，而是在其之上补齐 AI 时代所缺失的资源模型。从长期来看，这一层很可能演化为类似 CNI / CSI 的“GPU 资源层（GPU Abstraction Layer）”，成为 AI 原生基础设施中的关键组成部分。

生产化“断层”：AI 的 PoC 多，生产环境少

会后总结普遍提到：PoC 很多，但“日常生产部署”依然稀缺。Pulumi 的总结：

lots of working demos, very few production setups people trust

这说明，许多 AI 工作负载解决方案在技术展示中成功，但从实验到生产的过渡依然困难。无论是 GPU 资源共享，还是推理请求调度，Kubernetes 作为底座能否顺利承接变革，仍是悬而未决的问题。

推理系统的崛起：Kubernetes 调度边界被挑战

在本次 KubeCon 我觉得还有一个重大事件，就是 llm-d 被贡献给 CNCF，成为 Sandbox 项目。

如果说 GPU DRA 代表的是设备资源模型的上游化，那么 llm-d 所代表的，是另一条同样关键的演进路径：分布式 LLM 推理能力正在从各家厂商的工程实现，逐步走向云原生社区中的标准化协作对象。

这件事的意义不只是多了一个开源项目，而是说明 Kubernetes 在 AI 时代面临的挑战，已经不再只是“如何调度 GPU”，还包括“如何承载推理系统本身”。当 prefill / decode 拆分、请求路由、KV cache 管理、吞吐优化等能力进入基础设施层，Kubernetes 的边界正在被重新定义。

传统 Kubernetes 调度器关注 Pod 调度。但在 AI 推理场景，调度责任不仅是选择节点，更是如何根据请求特点选择最合适的推理实例。如模型状态、请求队列深度、缓存命中率等都需纳入调度决策。这一过程逐步被推理运行时控制，形成新的“请求级调度”系统。

这带来了 Kubernetes 调度器与推理系统的分层重叠，Kubernetes 需重新思考自身角色：是继续扩展，还是与推理系统协同？

AI 原生基础设施：生产化的关键挑战

在 AI Native Summit 上，AI 原生基础设施的实际需求尤为突出。讨论焦点不再是“是否能跑在 Kubernetes 上”，而是如何让 AI 工作负载成为 Kubernetes 上的常规业务，稳定运行并具备生产能力。

图 5: 在 KubeCon 后的同场活动 AI Native Summit 上 Linux Foundation 主席 Jonathan 支出云原生正在进入 AI 原生时代。

核心挑战在于交付。与传统应用不同，AI 模型权重通常极大，达几十 GB 甚至 TB 级，导致模型交付和数据管理异常复杂。传统容器交付体系（如镜像层）难以应对如此庞大的数据量和复杂的版本管理。

Kubernetes 未来的重要方向，是将模型权重和数据交付标准化，通过引入 ImageVolume 和 OCI artifacts 解决 AI 模型在 Kubernetes 上的交付和版本管理问题。这不仅能减少“冷启动”时间，还能为模型多租户、合规等需求提供基础设施支撑。

总结

Kubernetes 不会被 AI 取代，但正被 AI 重塑为基础设施核心。这种焦虑，是推动其不断进化的力量——它正从 “通用基础设施平台” 逐步演变为 “AI 支撑的多功能底座”，甚至有媒体将其评论为 AI 操作系统。

未来，Kubernetes 的核心竞争力不再只是容器管理，而是如何有效调度和管理 AI 工作负载，如何让 AI 成为常规运营的一部分。这是我在 AI Native Summit 和 KubeCon 上最大的启发，也是对未来几年 Kubernetes 生态的期待。

参考文献

Token 该怎么翻译？这场争论背后，是语言、技术与标准化的三重冲突

Jimmy Song — Tue, 24 Mar 2026 21:53:16 +0000

技术词汇的翻译，往往是工程、语言与标准化三重力量博弈的结果。

最近围绕 Token 中文翻译的讨论，突然变得异常热闹。

从“模元”到“智元”，再到官方语境逐渐收敛到“词元”，这件事表面上是在争一个术语，但它的传播范围和讨论强度，已经远远超出了技术圈。

尤其是当“词元调用量”开始出现在国家数据、媒体报道和公共表达中时，这个词已经不再只是工程内部的概念，而是进入了一个更大的系统：语言、产业和治理。

很多人关心的是：

Token 到底该翻译成什么？

但在我看来，更本质的问题其实是：

一个原本依赖上下文的工程抽象，如何在中文里被“命名”和“固定下来”？

为什么这个问题会引起这么大的争论？

我自己对这个问题比较敏感，和我的背景有关。

这些年我一直在做中英文技术写作和翻译，包括图书、博客。一个很直接的体感是：

最难翻译的，从来不是定义清晰的词，而是那些刻意保持模糊的词。

Token 就是典型代表。

在英文世界里，它本来就是一个“壳词”：

编译器里是 lexical token
安全体系里是 access token
区块链里也是 token
到了大模型时代，又变成模型处理的基本单位

英文的处理方式很简单：

一个词，多种语境，交给上下文去解释

但中文不一样。

中文一旦进入正式表达，尤其是技术写作或媒体传播，就会天然追问：

这个东西到底是什么？

于是问题就出现了：

词元 → 它是语言单位
智元 → 它是智能单位
模元 → 它是模型单位

你会发现，每一种翻译，其实都在做一件事：

替 Token 做“本体定义”

而 Token，本来就是一个没有完全收敛本体的概念。

Token 到底是什么？其实没有统一答案

如果把视角往工程层再往下压一层，这个问题会变得更清楚：

Token 不是一个统一的计量单位，而是一种约定。

不同模型之间：

tokenizer 不同
切分策略不同
同一句话的 token 数可能不同

更关键的是：

Token 早就不只是文本了

在今天的模型体系里：

文本 → text tokens
图像 → image tokens（patch）
音频 → audio tokens
推理 → reasoning tokens
上下文缓存 → cached tokens

甚至一个请求内部，还会被拆成：

input tokens
output tokens
cached tokens

这意味着：

Token 本质上是“被切分并参与计算的单位”，而不是某种固定对象

“日均万亿词元”是怎么统计的？

关于“日均万亿词元”这一说法，值得认真思考其统计方式。

既然 Token 本身并不统一：

为什么还会有国家级的统一统计？

从工程角度看，这种统计不可能是完全精确的。

更合理的理解是：

这是一个产业级口径的聚合指标

它的作用是：

描述 AI 应用规模
反映调用量增长
支撑产业判断

而不是：

精确到 tokenizer 层面的统一计量

换句话说：

它是一个“可比较的指标”，但不是一个“严格同构的单位”

这和“流量”“算力规模”这类指标，其实很类似。

为什么最终是“词元”？

很多人更喜欢“智元”，因为它更有想象力。

我也能理解。

但从工程和标准化角度看，“词元”的胜出其实非常合理。

它的优势不在于“更准确”，而在于：

可落地

可以直接对应 tokenizer 和现有 NLP 体系

有历史路径

不是凭空创造，而是延续已有术语

语义克制

不额外引入“智能”或“模型”的解释

所以本质上：

“词元”不是最优解，而是最稳解

中文其实不是一个统一体系

很多人会拿日语、韩语来类比，说它们直接用外来词。

但这个对比其实不太成立。

更值得关注的是：

中文世界本身就不是一个统一的技术语言体系

比如：

内存 vs 记忆体
软件 vs 软体
文件 vs 档案

这些差异长期存在。

Token 也很可能走类似路径：

官方语境 → 词元
工程语境 → Token
传播语境 → 智元（或类似表达）

这不是问题，而是常态。

为什么不造一个新词？像“雪糕”那样

中文历史上确实有两种路径：

音译（咖啡、沙发）
再命名（电话、计算机、雪糕）

那 Token 能不能走“雪糕”这条路？

理论上可以，但现实中很难。

原因有三：

Token 不是一个具体对象

雪糕是一个具体物，有形态、有边界。

但 Token 是：

一个跨模态、跨系统的抽象单位

它可以是文本、图像、音频、推理结构。

很难被重新命名成一个稳定概念。

Token 已经嵌入工程体系

API
SDK
计费系统
文档

全部都在使用 Token。

造新词，很难进入工程世界。

窗口期已经过去

成功的再命名，都发生在概念刚进入语言体系的时候。

而 Token：

已经被开发者使用多年
已经成为基础接口的一部分

再造词，成本极高。

一个更贴近翻译者的结论

从翻译角度看，这件事可以总结为一句话：

Token 不适合被“翻译”，更适合被“对齐”。

也就是说：

工程世界 → Token
中文表达 → 词元

而不是试图找到一个完全等价的词。

这场争论真正重要的是什么？

在我看来，这件事最重要的意义，不在于翻译本身，而在于：

Token 正在成为 AI 时代的基础计量单位

就像：

CPU → 计算资源
内存 → 存储资源
带宽 → 网络资源

现在多了一个：

Token → 推理与认知资源的单位

一旦一个概念进入这个层级：

它会被计费
会被调度
会被统计
会被治理

最后的一个判断

我个人的判断是：

Token 不会消失
词元会成为官方表达
智元会反复出现

它们不会统一，也不需要统一。

因为它们解决的是不同问题：

Token → 工程抽象
词元 → 标准化表达
智元 → 叙事想象

总结

Token 很可能会逐渐标准化，但这种标准化不会像“米”“秒”那样建立在物理世界之上，而更像“流量”“带宽”——表面上有统一单位，实际上依然依赖具体实现。

换句话说，Token 不会成为一个被精确定义的自然单位，而会成为一个被广泛接受的工程约定。

它的统一，不是来自物理学，而是来自平台、市场和统计口径。我们正在见证的，不是一个新单位的诞生，而是一种“单位感”的形成。

在阿姆斯特丹的第一天：Kubernetes 正在重新理解 AI

Jimmy Song — Sun, 22 Mar 2026 20:41:19 +0000

今天是我在 KubeCon Europe 2026 的第一天。

图 11: Jimmy 在 KubeCon EU 2026 的第一天

一个很强烈的感受是：

世界很大，但这个圈子真的很小。

老朋友、新周期

在 Maintainer Summit 现场，我见到了很多“老面孔”——

有蚂蚁的同事，也有来自 Tetrate 的朋友，还有一些已经认识接近十年的人。我们从早期的 Kubernetes、Service Mesh、云原生基础设施一路走到今天。

某种意义上，这一代人，是完整经历了：

Kubernetes 崛起
Cloud Native 标准化
微服务与服务网格热潮
再到今天的 AI Infrastructure

这不是一次“新的人进场”，而更像是——

同一批人，进入了一个新的技术周期。

Maintainer Summit 在讨论什么？

如果你问一个问题：

Kubernetes 社区现在最关心什么？

今天的答案其实非常明确：

👉 如何让 AI Workloads 更好地运行在 Kubernetes 上

图 12: Maintainer Summit 的主题就是 AI Infra

在 Maintainer Summit 上，讨论的很多议题都围绕：

LLM / AI workloads 的调度模型
GPU / 加速器资源管理
推理（inference）系统与 Kubernetes 的结合
数据面 vs 控制面的重新分工
可观测性如 OTel 如何观测 AI 负载

换句话说：

Kubernetes 并没有被 AI 替代，而是在主动“吸收”AI。

重要的信号：GPU 正在变成“基础设施层”

今天和 CNCF TOC、Red Hat、以及 vLLM 社区有一场很深入的交流。

我们聊的核心问题其实只有一个：

GPU 应该如何被“平台化”？

一些共识已经非常清晰：

GPU 不再只是一个 device
而是一个 可以被调度、被切分、被共享的资源层

图 13: TOC meeting 上讨论 GPU 资源管理与 LLM Serving 融合

在阿姆斯特丹的 Maintainer Summit 上，我们与 CNCF TOC、Red Hat 和 vLLM 社区围绕 Kubernetes 场景下的 GPU 资源管理与 LLM Serving 融合进行了深入交流，并探讨了 vLLM + HAMi 的潜在联合内容与后续协作。

这背后其实是一个很大的范式转移：

过去	现在
GPU = 节点资源	GPU = 基础设施层
独占	多租户共享
静态绑定	动态调度
框架内部管理	平台层统一管理

而这正是我们在 HAMi 里一直在做的事情。

HAMi：从“项目”到“参考样本”

今天还有一个比较有意思的变化是：

HAMi 不再只是一个“社区项目”，而是开始被当成：

一个 AI Infra 方向的参考实现（reference pattern）

图 14: 「Dynamia 密瓜智能」CTO 李孟轩在 KubeCon EU 2026 Maintainer Summit 上分享 HAMi 的设计理念和实践经验

这体现在几个地方：

被邀请参与 Maintainer Summit 的项目分享
参与 CNCF TOC 的讨论
参与 incubating review demo
和 vLLM 社区探讨联合内容（甚至已经在聊 joint blog 👀）

尤其是在和 Red Hat、vLLM 的交流中，有一个趋势非常明显：

GPU resource management 和 LLM serving 正在发生耦合

也就是说：

上层：vLLM / 推理框架
下层：GPU scheduling / sharing

正在逐渐形成一个“接口面”。

这会是一个很值得下注的方向。

图 15: TAG Workshop 上，HAMi 被当作 Incubating demo 来讨论

值得警惕：AI Infra 创业还没真正爆发

但同时，我也有一个稍微“反直觉”的观察：

还没有看到大规模“AI Infra（K8s 方向）创业浪潮”。

今天看到的大部分公司：

很多是从 CI/CD / Service Mesh / Gateway 转型
很多是传统云厂商延展 AI 能力
很多在做模型、Agent、或者更底层的东西

但真正 focused 在：

“让 AI workload 在 Kubernetes 上运行得更好”

这一层的创业公司，其实还不多。

这可能意味着两件事：

1）这个层还没 Fully formed

现在更多是在：

模型层（LLM / foundation model）
应用层（Agent / Copilot）

而不是：

调度层
资源层
runtime 层

2）或者，这一层门槛很高

因为它本质上是：

Cloud Native × GPU × AI workload 的交叉领域

不是简单的“套壳 AI”，而是基础设施级别的重构。

我的判断

如果把整个 AI 技术栈分层来看：

Agent / Application
 ↓
LLM Serving (vLLM, etc.)
 ↓
AI Runtime / Scheduling
 ↓
GPU Resource Layer
 ↓
Hardware

那么今天大多数创新集中在：

上两层（Agent / LLM）

但真正长期壁垒在：

中间两层（Runtime + Resource Layer）

而 Kubernetes，很可能会继续成为：

这个中间层的默认承载平台

最后

今天的总结是：

Kubernetes 并没有过时，它正在被重新定义。

而我们这一代人，也正在从：

“Cloud Native Builders”

转向：

“AI Infrastructure Builders”

明天继续。

HAMi 官网重构：HAMi 文档与官网为什么要全面改版

Jimmy Song — Tue, 17 Mar 2026 08:55:52 +0800

这次改版不是简单地换一套样式，而是希望把 HAMi 社区的技术表达、内容组织与用户体验，一次性拉到一个更适合长期演进的基础上。欢迎体验新版 HAMi 官网 https://project-hami.io，也欢迎给 HAMi 官网提交 Issue。

过去两个月里，我围绕文档官网做了一轮比较彻底的重构（见 GitHub）。对外看，它像是一次“视觉改版”；但从社区维护者和内容建设者的角度看，这更像是一次信息架构、内容系统和前端体验的整体升级。

这篇文章想系统说明三件事：我们为什么要做这次重构、这次到底改了什么、以及这些改动对 HAMi 社区意味着什么。

为什么要重构官网和文档

HAMi 是一个 CNCF 托管的开源项目，由「Dynamia 密瓜智能」发起和贡献给 CNCF，这几年在 GPU 虚拟化、异构算力调度和 AI 基础设施方向的影响力持续扩大。社区内容越来越多，用户类型也越来越复杂：既有第一次了解项目的新访客，也有来查部署文档、看架构图、找案例、了解生态的工程师和企业用户。

原有站点并不是不能用，但随着内容量增长，几个问题逐渐暴露出来：

首页表达的信息密度不够，难以快速建立对项目价值的整体认知。
文档、博客、社区信息之间的连接不够顺畅，内容入口分散。
搜索体验不稳定，外部方案在实际使用中并不理想。
移动端访问体验还有不少细节问题，尤其是导航、卡片布局和页脚区域。
页面视觉风格不够统一，难以把社区影响力和工程成熟度直观传递出来。

对于一个处在快速演进期的开源社区来说，官网不只是“放文档的地方”，而是社区的公共界面。它需要同时承担项目介绍、知识入口、采用证明、社区连接和品牌表达的职责。

所以这次重构的目标很明确：不是做一次表层美化，而是把官网真正升级为 HAMi 社区的系统化入口。

这次重构重点做了什么

这轮更新并不是单点修改，而是连续完成的一组系统性改造。

首页重新设计，信息架构彻底梳理

这次最明显的变化是首页。

我们重新设计了首页结构，不再只是简单堆叠若干内容区块，而是围绕“项目定位 -> 核心能力 -> 生态入口 -> 内容沉淀 -> 社区信任”这条主线来组织页面。

具体来说，首页完成了几类关键升级：

重做了 Hero 区域，强化第一屏的信息传达和行动入口。
优化了 CTA 设计，让用户可以更快进入文档、博客和资源内容。
新增并强化了多个首页 section，用更结构化的方式展示项目价值和社区外延。
调整了区块之间的视觉层次、背景氛围和滚动节奏，让首页从“内容列表”变成“叙事页面”。

这部分改动包含首页 Hero 动效与氛围层、研究/故事 section、新的资源入口 section、CTA 刷新、统一背景层设计，以及后续对视觉噪音的持续收敛。它们共同解决的是一个核心问题：让访问者在几秒钟内理解 HAMi 是什么、为什么值得继续看下去。

架构图重绘，让技术表达更直观

对于基础设施项目来说，文字说明远远不够，架构图质量会直接影响理解成本。

图 1: HAMi 官网首页的架构图

这次改版过程中，一个非常重要但容易被低估的工作，就是把首页和相关内容中的架构表达重新梳理，并持续重绘关键图示。这样做的价值不只是“更好看”，而是让用户更容易理解 HAMi 在整个 AI 基础设施体系中的位置、能力边界和协作关系。

本次重构，围绕 GPU 虚拟化、控制面/数据面、依赖关系、分层结构、治理路径等主题，站点新增和更新了多张 SVG 与静态图。这意味着官网正在从“文字驱动”转向“图文共同承担解释任务”的表达方式。

图 2: 使用 HAMi 前后对比图，凸显 HAMi 的 GPU 虚拟化和共享能力

对于 HAMi 这样的项目，这种变化非常关键。因为社区面对的不是单一功能点，而是一整套与 Kubernetes、调度器、GPU Operator、异构设备和企业平台协同的系统问题。图示质量上去以后，官网本身就成了更好的技术入口。

新增案例、社区与生态表达，让影响力更可见

这次重构还有一个很重要的方向，就是补齐“社区证明”层。

过去很多开源项目的网站都容易陷入一个问题：文档很全，但用户看不出来这个项目到底有没有被真正采用、社区是否活跃、生态是否在扩展。HAMi 官网这次改版，显然是在有意识地解决这个问题。

图 3: HAMi 生态和设备支持

我们重点强化了几类内容表达：

更适合承载案例与实践经验的内容入口。
更清晰的社区板块与关于信息。
更直观的生态与资源 section。
对贡献者、采用者、生态伙伴这类“社区影响力信号”的集中展示。

这里面有些模块已经直接体现在首页和导航结构里，有些则体现在内容入口与整体表达方式的变化中。核心思路是一致的：HAMi 不应该只被看作一个“功能型项目”，而应该被看作一个持续成长的开源社区与生态节点。

网站首页新增：采用者和贡献者组织列表。

图 4: HAMi 采用者

图 5: HAMi 贡献者组织

这也是为什么改版后，首页会更强调社区、生态、资源和外部链接的组织方式。对一个开源项目来说，被理解、被采用、被信任，很多时候同样重要。

博客样式和内容阅读体验整体升级

除了首页，这次对博客系统也做了很多细节重构。

博客卡片、博客列表、分类信息、元数据样式、分页、链接表现和封面元信息都做了持续调整。博客卡片从更传统的展示方式，逐步优化成更统一、更干净、阅读负担更低的样式。

图 6: HAMi 网站的博客列表页面

这件事的意义不只是“看起来更舒服”。

因为对 HAMi 社区而言，博客并不是附属内容，而是文档之外非常重要的传播层。很多用户第一次认识一个项目，并不是从安装文档开始，而是从一篇技术文章、一次案例解读或者一张架构图开始。

把博客样式和内容承载体验做好，实际上是在增强社区的叙事能力：

技术文章更易读。
项目进展更容易被传播。
架构思考和实践经验更容易被沉淀。
社区公众号和官网博客之间的联动也会更顺畅。

从这个角度看，博客系统的重构，本质上也是社区基础设施的一部分。

移动端体验做了大量细节优化

这轮更新里，移动端优化是一个很明确的主线，而且不是一次性修修补补，而是持续多轮打磨。

本次重构还对移动端进行了优化：

导航栏间距与折叠菜单交互。
菜单按钮点击热区。
语言切换与下拉表现。
卡片布局、首页区块间距与 Hero 偏移。
移动端页脚排版与信息密度。
搜索入口和导航滚动行为。

这些改动看起来碎，但它们决定了手机访问时是不是“顺手”。

图 7: HAMi 网站移动端

HAMi 社区有很多用户会直接在手机上看文章、搜资料、转发内容，移动端体验如果做不好，社区传播链路就会被切断一大截。现在这部分明显更稳了，导航更易点，页面更清楚，信息也没有以前那么拥挤。

这次改版另一个很值得一提的点，是页脚区被认真重做了。

过去很多技术站点的 Footer 都只是几个链接的堆叠，但这次更新里，Footer 的布局、可访问性、移动端表现和链接组织方式都做了明显增强。它不再只是页面底部的“附属区域”，而是承担了站点导航补充、社区触点和品牌收束的作用。

图 8: HAMi 网站 footer

这对开源社区尤其重要。因为用户在页面底部往往会寻找几个关键信号：

还有哪些内容入口可以继续看。
如何联系社区。
站点是否持续维护。
项目的对外表达是否完整。

一个更成熟的 Footer，实际上会提升整站的可信度和完成度。

替换掉不好用的 Algolia 搜索，回到站点内建搜索

搜索是这次改版里最务实、也最能直接提升体验的一项改动。

图 9: HAMi 网站内建搜索

过去外部搜索方案虽然看起来“高级”，但在多语言、内容组织和实际交互上并不总是适合当前站点。我对网站的内建搜索做了增强，包括：

搜索索引结构优化。
搜索按钮与触发交互修复。
搜索结果样式统一。
搜索结果去重、评分与限制优化。
对中文场景和内容分类的更好适配。

对文档站来说，搜索不是锦上添花，而是核心路径。用户找不到内容，再好的页面设计都没有意义。

因此，这次从不好用的外部搜索切回更可控的站内搜索方案，本质上是在把“内容可达性”重新掌握在自己手里。这对多语言技术文档和博客混合型站点尤其重要。

这次改版对 HAMi 社区意味着什么

如果只从页面截图看，这次更新像是“官网变好看了”。但从社区建设的角度看，它的意义更深一层。

第一，HAMi 的对外表达开始更系统了。

官网不再只是分散的页面集合，而是在逐步形成一条完整的叙事链：用户可以从首页理解项目价值，从文档理解能力细节，从博客理解实践路径，从社区和生态模块理解项目影响力。

第二，社区内容资产被重新组织了。

过去很多有价值的文章、图示和说明，可能存在但不够容易被看见。现在通过首页 section、导航和搜索重构，这些内容被更有效地串联起来了。

第三，HAMi 的社区形象更成熟了。

一个成熟的开源项目，不只是代码仓库活跃，还需要有清晰、稳定、可持续的官网表达。网站的结构、风格和易用性，本身就是社区工程能力的一部分。

第四，这为后续继续扩展案例、采用者、贡献者与生态内容打下了基础。

基础框架理顺之后，未来不管是增加更多 case study、补充社区协作入口，还是展示更多采用者和生态伙伴，都会比过去更自然，也更容易被用户理解。

作为社区贡献者，我最看重这次改版的三点

如果用一句话概括，我会认为这次重构真正做对了三件事：

把官网从“内容堆放处”升级成了“社区入口”。
把视觉优化和信息架构调整一起做，而不是只换皮肤。
把搜索、移动端、导航、页脚这些基础体验补齐了。

这几件事听起来不如发一个新特性那样显眼，但它们会直接影响社区内容传播、用户理解成本和项目的长期形象。

对于 HAMi 这样的基础设施项目来说，技术能力当然是根本，但把技术能力讲清楚、组织好、持续呈现出来，同样是一种基础设施。

总结

这轮 HAMi 文档与官网的重构，本质上是在补社区“表达层”的基础设施。

它一方面提升了页面视觉和阅读体验，另一方面也重新梳理了内容组织、首页叙事、搜索路径、移动端访问和社区信号展示方式。首页重新设计、架构图重绘、博客样式统一、移动端优化、Footer 增强，以及从外部搜索回归内建搜索，这些改动合在一起，才构成了这次真正意义上的“重构”。

对外，它让更多人更快理解 HAMi；对内，它也让社区后续继续沉淀案例、扩展生态、服务采用者与贡献者有了更稳固的载体。

官网不是开源社区的附属品，而是社区长期影响力的一部分。HAMi 这次改版，正是在把这件事认真做起来。

如果你关注 Kubernetes 中的 GPU 虚拟化，想要提高 GPU 资源利用率，可以添加我的微信 jimmysong，或者扫描下面的二维码获取更多资讯。

图 10: 加入 HAMi 社区

在 GitHub 上查看 HAMi 项目

GTC 2026 前夜：AI 正在成为新的基础设施

Jimmy Song — Sun, 15 Mar 2026 11:34:06 +0800

AI 正在悄然重塑基础设施格局，GTC 2026 或许将成为这一变革的关键节点。

下周，全球 AI 行业最重要的技术大会之一 NVIDIA GTC 2026 将在美国圣何塞举行。

对很多人来说，GTC 只是一个 GPU 技术大会。但如果你持续关注过去几年 AI 行业的发展，就会发现一个很有意思的现象：

很多 AI 基础设施的重要叙事，都是在 GTC 上逐渐形成的。

从 CUDA、DGX，到 AI Factory，再到最近 Jensen Huang 提出的 AI Five-Layer Cake，NVIDIA 正在不断试图重新定义 AI 时代的计算基础设施。

这也是为什么很多人把 GTC 称为：

AI 的“Woodstock”。

图 1: NVIDIA GTC Conference

今年的 GTC（3 月 16 日—19 日）预计会覆盖 AI stack 的各个层面，包括：

AI 芯片
AI 数据中心
AI Agent
机器人
推理计算

根据 NVIDIA 官方博客的介绍，今年的 keynote 将重点讨论 从芯片到应用的完整 AI stack。

如果把这些信号放在一起，其实能看到一个更大的趋势：

AI 正在从“应用技术”，变成“基础设施”。

工业革命的视角

从更长的时间尺度来看，人类历史上的技术革命，本质上都是基础设施的革命。

通常我们把工业革命划分为四次。

在下表中，可以看到每次工业革命对应的基础设施：

工业革命	基础设施
蒸汽革命	蒸汽机
电气革命	电网
数字革命	计算机
互联网时代	网络

表 1: 工业革命与基础设施对应关系

第一次工业革命：蒸汽

蒸汽机让人类第一次能够大规模利用机械动力。生产不再依赖人力或动物，而是依赖机器。

第二次工业革命：电力

电力改变的不只是动力来源，还改变了生产组织方式。流水线、规模化制造、现代工业体系，都建立在电网基础之上。

第三次工业革命：计算机

计算机让信息可以被数字化处理。软件成为生产工具。

第四次工业革命：互联网与智能化

互联网把所有计算机连接在一起。云计算把计算资源变成基础设施。而 AI，则让机器开始具备一定程度的“认知能力”。

AI 的真正意义

如果观察这些工业革命，会发现一个规律：

每一次工业革命都会产生一种新的 通用基础设施（General Purpose Infrastructure）。

而 AI，很可能会成为下一代基础设施。

NVIDIA 在最近的文章中甚至直接提出：

AI is essential infrastructure, like electricity and the internet.

换句话说：

AI 不再只是一个应用技术，而是一个 新的生产要素。

NVIDIA 的 Five-Layer Cake

最近 Jensen Huang 提出了一个非常有意思的概念：AI Five-Layer Cake。

图 2: AI Five Layer Cake（图片来源 NVIDIA）

AI 被拆解为五个层次：

Energy
Chips
AI Infrastructure
Models
Applications

这个模型其实说明了一件事情：

AI 是一个完整的产业体系。

Jensen Huang 在 Davos 甚至把 AI 描述为：

“人类历史上最大规模的基础设施建设之一。”

GTC 2026 可能释放的几个信号

今年的 GTC 预计会释放几个重要方向。

推理计算

过去 AI 的重点是训练。但未来 AI 的主要负载很可能是 推理（Inference）。

分析师预计，到 2030 年 AI 数据中心市场中 75% 的算力需求来自推理。

Agentic AI

过去 AI 的模式是：

User → Model → Answer

而 Agent 的模式则更为复杂：

User → Agent → Tools → Model → Action

下方流程图展示了 Agent 模式下的主要交互路径：

图 3: Agentic AI 交互流程

AI 不再只是回答问题，而是 执行任务。

Agent 平台

最近有媒体报道称 NVIDIA 可能会推出一个新的 Agent 平台：NemoClaw，目标是帮助企业部署 AI Agent。

如果这个项目真的发布，那意味着 NVIDIA 的 stack 会变成如下结构：

图 4: NVIDIA Agent 平台架构

这其实就是一个完整的 AI stack。

Agent 改变计算负载

Agent 的出现带来了新的计算负载问题。

过去 AI workload 主要是：

Training
Inference

但 Agent 带来第三种 workload：

Agent Workloads

下图展示了 Agent 相关的多样化负载类型：

图 5: Agent Workloads 结构

这种 workload 的特点是 高度碎片化。GPU 不再是被长时间占用，而是大量小请求。这对基础设施提出了新的挑战。

AI 原生基础设施

过去几年，我一直在思考一个问题：

什么是 AI 原生基础设施？

它显然不只是“带 GPU 的 Kubernetes”。我更倾向于认为它需要具备几个特征。

GPU 是一等资源

云计算时代，CPU 是核心资源。AI 时代，GPU 是核心资源。

异构算力

现实世界的 AI 芯片并不只有 NVIDIA：

NVIDIA
华为昇腾
寒武纪
沐曦
摩尔线程
其他专用 AI 芯片

未来的 AI 基础设施必须能够管理 异构算力。

GPU 共享

GPU 是一种非常昂贵的资源。如果不能共享，利用率会非常低。这也是为什么 GPU virtualization 和 slicing 变得越来越重要。

AI 调度

AI 调度不仅包括传统的 CPU、Memory，还包括：

GPU
VRAM
Topology
Bandwidth

一个可能的 AI 技术栈

结合上述趋势，未来 AI stack 可能会呈现如下结构：

图 6: AI 技术栈演进

这个结构与 NVIDIA 的 Five-Layer Cake 十分接近。

我的判断

综合 GTC、AI Factory、Agent、AI Five-Layer Cake 等信号，可以看到一个非常明显的趋势：

AI 正在重写计算基础设施。

未来的竞争很可能不只是“谁拥有最好的模型”，而是：

谁拥有最好的 AI Infrastructure。

就像过去几十年：

电力决定工业能力
互联网决定信息能力
云计算决定软件能力

未来可能是：

AI Infrastructure 决定智能能力。

总结

如果把时间尺度再拉长一点，我们或许正处在一个新的历史阶段。

AI 不再只是一个技术工具。它正在变成 新的基础设施。

就像：

电力
互联网
云计算

一样。

而 AI 原生基础设施，很可能会成为未来十年最重要的技术方向之一。

当 GPU 走向开放调度：HAMi 2025 年的结构性转变

Jimmy Song — Fri, 13 Feb 2026 14:41:48 +0000

GPU 调度的未来，不在于谁的实现更“黑盒”，而在于谁能把资源契约标准化到可治理。

图 17: GPU 走向开放调度

引言

你是否想过：为什么 GPU 这么贵，但整体利用率却经常只有 10%–20%？

图 18: GPU 利用率问题

这不是一个"优化算法"能解决的问题，而是一个结构性问题——GPU 调度正在经历一场从"私有实现"到"开放调度"的转变，类似当年网络走向 CNI、存储走向 CSI 的标准化路径。

在 HAMi 2025 年度回顾中提到：“2025 的 HAMi 已经不再只是一个 GPU 共享工具箱，而是一个更结构性的信号：GPU 正在走向开放调度。”

2025 年，这个转变的信号已经清晰可见：Kubernetes DRA（Dynamic Resource Allocation）进入 GA 并默认启用，NVIDIA GPU Operator 开始默认使用 CDI（Container Device Interface）开放规范，而 HAMi 在 CNCF 的生产级案例正在把"GPU 共享"从实验能力推向运营能力。

本文将从 AI Native Infrastructure 的视角，深入解析这场结构性转变的驱动力、证据链以及对「Dynamia 密瓜智能」和整个行业的战略意义。

为什么“开放调度”很重要

在多云/混合云环境下，GPU 型号多样性会显著放大运维成本。以某大型互联网公司为例，其平台覆盖 H200/H100/A100/V100/4090 等多型号 GPU，跨 5 个集群。如果只能“整卡分配”，资源错配几乎不可避免。

“开放调度”不是一句口号，而是一组正在被主流栈固化的工程契约。

资源表达的标准化

过去，GPU 作为扩展资源（extended resources），调度器无法识别其显存、算力或设备类型等属性。

图 19: 开放调度标准化演进

现在，Kubernetes DRA 通过 DeviceClass、ResourceClaim、ResourceSlice 等对象，让驱动和集群管理员可以定义设备类别与选择条件（支持 CEL 选择器）。Kubernetes 在调度时完成“匹配设备 → 绑定声明 → 把 Pod 放到可访问节点”的完整流程。

更重要的是，Kubernetes 1.34 明确承诺：resource.k8s.io 组的核心 API 进入 GA，DRA 变得稳定且默认启用，后续不会再有破坏性变更。这意味着生态可以以“标准 API”为锚点开始规模化投资。

设备注入的标准化

过去，设备注入容器依赖 vendor-specific 的 hooks 和 runtime class 模式。

现在，CDI 将设备注入语义抽象成开放规范。NVIDIA Container Toolkit 明确将其描述为面向 container runtime 的开放规范，NVIDIA GPU Operator 25.10.0 在安装/升级时默认启用 CDI，直接利用 containerd/CRI-O 等 runtime 的 CDI 支持进行注入。

这意味着“设备进入容器”这一步也在走向可替换、可标准化接口。

HAMi：从“共享工具”到“可治理数据平面”

在标准化通路上，HAMi 的角色需要重新定义：它不是要替代 Kubernetes，而是把 GPU 虚拟化与切分做成可声明、可调度、可治理的数据平面。

数据平面视角

HAMi 的核心是将“整卡整数”的资源单位扩展为 core/memory 等份额，形成完整的分配链路：

设备发现：识别可用 GPU 设备和型号。
调度落位：通过 Scheduler Extender 让原生调度器“看懂”vGPU 资源模型（Filter/Score/Bind 三段式）。
容器内兑现：把份额约束注入容器运行时。
指标导出：提供可观测的利用率、隔离度等指标。

这种方式让“共享”不再是容器里自觉的经验主义，而是可以被 YAML 声明、被策略调度、被指标验收的工程能力。

调度机制：不是替换，而是增强

HAMi 的调度并非替换 Kubernetes，而是用 Scheduler Extender 让原生调度器“看懂”vGPU 资源模型：

Filter：根据显存、算力、设备类型、拓扑等约束过滤节点。
Score：提供 binpack、spread、topology-aware 等可配置策略。
Bind：完成设备与 Pod 的最终绑定。

因此，HAMi 天然适合作为“AI 控制面（队列/配额/优先级）”之下的执行层，与 Volcano、Kueue、Koordinator 等形成职责分工。

图 20: HAMi 调度架构（Filter → Score → Bind）

生产证据：从“能不能共享”到“能不能运营”

CNCF 的公开案例为 GPU 虚拟化的生产级能力提供了直观证据：

在一个跨公有云与私有云的多集群平台中，Kubernetes + HAMi 支撑 10,000+ Pod 并发，把 GPU 利用率从 13% 提升到 37%（近 3 倍）。

图 21: CNCF 生产案例数据汇总：Ke Holdings 13%→37%、DaoCloud 80%+ 利用率、SF Technology 节省 57%

以下是 CNCF 生产案例的实证数据：

案例	场景/项目	核心成果	特色
贝壳找房	跨 5 集群平台 H200/H100/A100/V100/4090 等多型号训练整卡池 vs 推理 vGPU 池	整体 GPU 利用率 13% → 37%（近 3 倍）10,000+ Pod 并发	多型号异构调度
DaoCloud	硬约束：云原生、vendor-agnostic、CNCF 工具链	平均 GPU 利用率 80%+ 运营成本下降 20–30% 10+ 数据中心、10,000+ GPU 卡	统一抽象层跨 NVIDIA + 国产 GPU
Prep EDU	异构 RTX 4070/4090 集群	资源隔离失败 → GPU 虚拟化调度提升利用率	与 GPU Operator、RKE2 生产集成
顺丰科技	大模型推理、测试、语音识别国产 AI 硬件适配（华为昇腾、百度昆仑等）	GPU 节省 57%（生产 + 测试集群）大模型推理 65 服务/28 GPU 测试 19 服务/6 GPU	跨节点协同调度、优先级抢占内存超售技术

这些案例证明，GPU 虚拟化成为经济上有意义的能力，前提是它参与到一个可治理的契约——利用率、隔离度、策略可以被表达、被测量、被持续改进。

国产芯片的崛起：智谱 GLM-5 的实践

一个更具信号意义的案例来自智谱 AI：GLM-5 在上线后不久即完成与华为昇腾、摩尔线程、寒武纪、昆仑芯、沐曦、燧原、海光等国产算力平台的深度推理适配，通过底层算子优化与硬件加速，在国产芯片集群上实现高吞吐、低延迟的稳定运行。详见 GLM-5 开源：从代码到工程，Agentic Engineering 时代最好的开源模型

图 22: 国产芯片生态（GLM-5 + 多厂商）

这个案例的重要性在于：它不是"试验性适配"，而是承载全球爆量生产流的真实部署。GLM 系列模型在全球权威的 Artificial Analysis 榜单中位居开源第一，GLM-5 更是在全球开发者社区中引发爆量采用——在这样的规模下，“能否在多型号、多厂商的国产 GPU 集群上稳定服务"不再是技术验证问题，而是业务连续性问题。

从开放调度的视角看：

硬件层面的异构性正在成为常态：国产芯片从"可用"走向"可规模化部署”，意味着调度系统必须真正具备跨厂商、跨型号的资源抽象与治理能力
“适配"不再是单点工程，而是需要可声明的契约：GLM-5 能在多个国产 GPU 平台上实现"底层算子优化与硬件加速”，恰恰证明了当资源表达、设备注入、调度约束都成为可声明的工程能力时，上层应用才有空间做深度优化
开放调度是国产芯片生态化的前提：当硬件层走向多元化，“能不能在多种芯片上跑"会变成"能不能以可预测的运维成本和治理水平在多种芯片上跑”——这需要标准化接口作为基础

对密瓜智能的战略意义

从密瓜智能的视角，HAMi 的结构性价值更加清晰：

双层机制：开源 vs 商业

图 23: 密瓜智能双层机制（开源 vs 商业）

HAMi（CNCF 开源项目）：负责“采用与信任”，聚焦 GPU 虚拟化与算力优化。
密瓜智能企业产品与服务：负责“落地与规模化运行”，基于 HAMi 提供商业发行版。

这种边界是长期信任的底线——项目与公司产品分离，商业发行版与企业服务基于开源项目。

商业化的正确落点

DaoCloud 的案例已将 vendor-agnostic 与兼容 CNCF 工具链设为硬约束，并把“减少 vendor dependency”写进收益清单。Project-HAMi 的官方文档也将“避免 vendor lock”列为主打价值之一。

在此基础上，商业化更合理的落点不是“把调度闭源”，而是围绕企业真实复杂度提供产品化能力：

更系统化的兼容矩阵
SLO/尾延迟治理
可计费计量
RBAC/配额/多集群治理
升级与回滚安全
对 DRA/CDI 等规范化路径的更快落地与工程化整合

前瞻判断：接下来的 2–3 年

我个人判断，未来 2–3 年，GPU 调度的竞争重点会从“谁的实现更黑盒”转向“谁的契约更开放”。

原因如下：

硬件形态和供应链正在变得更复杂

OpenAI 2026-02-12 发布的“GPT‑5.3‑Codex‑Spark”强调超低时延 serving，包括持久 WebSocket 和 Cerebras 硬件上的专用 serving tier。
大规模 GPU 资产融资（用于泛欧部署）显示了加速器舰队的基础设施规模和金融工程。

这些信号表明，异构性会持续增长——混合加速器、混合云、混合工作负载类型。

低时延推理 tier 会逼迫资源调度体系化

低时延推理 tier（不仅限于 GPU）会推动资源调度走向“多加速器、多层缓存、多类节点”的体系化设计，调度必须面向异构。

开放调度不是理想主义，而是风险管理

在这样的世界里，“开放调度”不是理想主义，而是风险管理。围绕 DRA/CDI 这样不断被固化的开放接口，把调度做成可插拔、多租户可治理、且能被生态共同演进的“控制平面/数据平面组合”，更像是 AI Native Infrastructure 真正可持续的路径。

下一个主战场不是“谁的调度更聪明”，而是“谁能把设备资源契约标准化到可治理”。

总结

当你把 2025 的 HAMi 放回更大的 AI Native Infrastructure 语境里看，它已经不再是“GPU 共享工具箱”的一年，而是一个更结构性的信号：GPU 正在走向开放调度。

图 24: 开放调度未来愿景

这场转变的驱动力来自两端：

上游：DRA/CDI 等标准不断固化。
下游：规模化与多样化（多云、多型号、甚至 GPU 之外的加速器形态）。

对密瓜智能而言，HAMi 的意义已经超出一个“GPU 共享工具”：它把 GPU 虚拟化与切分变成可声明、可调度、可计量的数据平面，让队列/配额/优先级/多租户等控制面治理真正闭环。

AI 学习资源：我从清理中精选的 44 个收藏

Jimmy Song — Sun, 08 Feb 2026 12:17:55 +0000

“学习 AI 的最佳方式是开始动手实践。这些资源将指引你的旅程。”

图 1: AI 学习资源合集

为了保持 AI 资源列表聚焦于生产就绪的工具和框架，我移除了 44 个收集类项目——包括课程、教程、Awesome 列表和 Cookbook。

这些资源并没有消失——它们被整理到了这里。这篇文章是这些教育材料的精选合集，按类型和主题组织。无论你是完全的初学者还是有经验的从业者，都能在这里找到有价值的内容。

为什么从 AI 资源列表中移除收藏类内容？

我的 AI 资源列表现在聚焦于具体的工具和框架——即可以在生产环境中直接使用的项目。收藏类内容虽然有价值，但服务于不同的目的：教育和探索。

通过分离它们，我：

保持资源列表的可操作性和聚焦性
为学习材料创造专属空间
让你更容易找到所需内容

📚 Awesome 列表（14 个合集）

Awesome 列表是社区策划的最佳资源集合，非常适合发现新工具和保持更新。

必探索的 Awesome 列表

Awesome Generative AI

模型、工具、教程和研究论文
适合：全面了解生成式 AI 的格局

Awesome LLM

大语言模型资源：论文、工具、数据集、应用
适合：深入大语言模型

Awesome AI Apps

实用的 LLM 应用、RAG 示例、智能体实现
适合：真实世界的实现示例

Awesome Claude Code

Claude Code 命令、文件和工作流
适合：最大化 Claude Code 的生产力

Awesome MCP Servers

用于模块化 AI 后端系统的 MCP 服务器
适合：使用模型上下文协议构建应用

专业 Awesome 列表

Awesome ChatGPT Prompts - 各种场景的提示词示例
Awesome LLM Apps - 带代码示例的 LLM 应用
Awesome Multimodal LLM - 多模态模型资源
Awesome MCP Clients - MCP 客户端工具和 SDK
Awesome Claude Skills - Claude 技能和工作流
Awesome GitHub Copilot - Copilot 自定义
Awesome Nano Banana Pro - 图像模型提示词和示例
Awesome SaaS - AI 平台模板
Awesome Claude Code Subagents - Claude Code 子智能体

🎓 课程与教程（9 套课程）

来自大学和科技公司的结构化学习路径。

微软 AI 课程系列

AI for Beginners

12 周、24 课时，涵盖神经网络、深度学习、CV、NLP
适合：完整的 AI 基础
形式：课程、测验、项目

Machine Learning for Beginners

12 周、26 课时的经典机器学习课程
适合：无需复杂数学的 ML 基础
形式：项目式练习

Generative AI for Beginners

18 课时构建生成式 AI 应用
适合：实用的 GenAI 开发
形式：动手实践项目

AI Agents for Beginners

11 课时的智能体系统课程
适合：理解自主智能体
形式：项目驱动学习

EdgeAI for Beginners

优化、部署和真实世界的边缘 AI
适合：端侧 AI 应用
形式：实践教程

MCP for Beginners

模型上下文协议课程
适合：使用 MCP 构建
形式：跨语言示例和实验

官方平台课程

Hugging Face Learn Center

涵盖 LLM、深度强化学习、CV、音频的免费课程
适合：Hugging Face 生态系统动手实践
形式：交互式笔记本

OpenAI Cookbook

使用 OpenAI API 的可运行示例
适合：OpenAI API 最佳实践
形式：代码示例和指南

PyTorch Tutorials

从基础到高级的深度学习
适合：掌握 PyTorch
形式：全面的教程

🍳 Cookbook 与示例合集（5 个合集）

实用的代码示例和配方。

Claude Cookbooks

使用 Claude 构建的笔记本和示例
适合：Anthropic Claude 集成
形式：Jupyter 笔记本

Hugging Face Cookbook

带有 Jupyter 笔记本的实用 AI Cookbook
适合：开源模型和工具
形式：动手示例

Tinker Cookbook

训练和微调示例
适合：微调工作流
形式：平台特定配方

E2B Cookbook

构建 LLM 应用的示例
适合：LLM 应用开发
形式：配方和教程

arXiv Paper Curator

6 周的 RAG 系统课程
适合：生产级 RAG
形式：项目式学习

📖 指南与手册（5 个资源）

特定主题的深入指南。

Prompt Engineering Guide

全面的提示工程资源
适合：掌握提示词设计
形式：指南、论文、讲座、笔记本

Evaluation Guidebook

Hugging Face 的 LLM 评估最佳实践
适合：评估 LLM 性能
形式：实用指南

Context Engineering

设计和优化超越提示工程的上下文
适合：高级上下文管理
形式：实用手册

Context Engineering Intro

上下文工程的模板和指南
适合：为 AI 助手提供项目上下文
形式：模板 + 指南

Vibe-Coding Workflow

使用 LLM 构建 MVP 的 5 步提示模板
适合：使用 AI 快速原型开发
形式：工作流模板

🗂️ 模板与工作流合集

可重用的模板和工作流。

Claude Code Templates

各种编程场景的代码模板
适合：Claude AI 开发
形式：模板集合

n8n Workflows

2,000+ 个专业组织的 n8n 工作流
适合：工作流自动化
形式：可搜索的目录

N8N Workflows Catalog

社区驱动的可重用工作流模板
适合：工作流导入和版本控制
形式：模板目录

📊 研究与评估

学术和评估资源。

LLMSys PaperList

LLM 系统论文策划列表
适合：训练、推理、服务研究
形式：论文集合

Free LLM API Resources

提供免费/试用 API 访问的 LLM 提供商
适合：零成本实验
形式：提供商列表

🎨 其他值得注意的资源

System Prompts and Models of AI Tools

社区策划的系统提示词和 AI 工具示例集合
适合：提示词和智能体工程
形式：资源集合

ML Course CS-433

EPFL 机器学习课程
适合：学术 ML 基础
形式：讲座、实验、项目

Machine Learning Engineering

机器学习工程开放书：计算、存储、网络
适合：生产 ML 系统
形式：全面指南

Realtime Phone Agents Course

构建低延迟语音智能体
适合：语音 AI 应用
形式：动手课程

LLMs from Scratch

从第一性原理构建工作 LLM
适合：理解 LLM 内部原理
形式：代码仓库 + 书籍材料

💡 如何使用这个合集

完全初学者

从开始：Microsoft 的 AI for Beginners
练习：PyTorch Tutorials
探索：Awesome AI Apps 获取灵感

开发者

构建技能：OpenAI Cookbook + Claude Cookbooks
查找工具：Awesome Generative AI + Awesome LLM
学习工作流：n8n Workflows Catalog

研究人员

保持更新：Awesome Generative AI + LLMSys PaperList
深入研究：Awesome LLM
实现：Hugging Face Cookbook

产品构建者

查找示例：Awesome AI Apps
学习工作流：n8n Workflows Catalog
研究模式：Awesome LLM Apps

🔄 没有被移除的内容

智能体框架和生产工具仍保留在 AI 资源列表中，包括：

AutoGen - 微软的多智能体框架
CrewAI - 高性能多智能体编排
LangGraph - 有状态多智能体应用
Flowise - 可视化智能体平台
Langflow - 可视化工作流构建器
以及其他 80+ 个智能体框架

这些都是你可以用来构建应用的功能性工具，而不是教育合集。它们属于 AI 资源列表。

📝 总结

我从 AI 资源列表中移除了 44 个收集类项目，以保持其对生产工具的聚焦：

14 个 Awesome 列表 - 发现新工具并保持更新
9 个课程与教程 - 结构化学习路径
5 个 Cookbook - 实用代码示例
5 个指南与手册 - 深入资源
4 个模板集合 - 可重用工作流
7 个其他资源 - 研究和评估

这些资源对于学习和探索仍然极其有价值。它们只是服务于与 AI 资源列表中生产聚焦工具不同的目的。

下一步：

收藏此帖子以备将来参考
探索 AI 资源列表获取生产工具（智能体框架、数据库等）
查看们的博客获取更多 AI 工程见解

致谢：此合集是在我的 AI 资源清理倡议期间编制的。特别感谢所有这些 awesome 列表、课程和合集的维护者，感谢他们对 AI 社区的宝贵贡献。

站在巨人的肩膀上：致敬支撑现代 AI 的传统基础设施

Jimmy Song — Sun, 08 Feb 2026 11:27:32 +0000

“如果我看得更远，那是因为我站在巨人的肩膀上。” —— 艾萨克·牛顿

图 1: 站在巨人的肩膀上：致敬支撑现代 AI 的传统基础设施

在大语言模型、向量数据库和 AI 智能体的热潮中，我们很容易忘记：现代 AI 并非凭空出现。今天的 AI 革命建立在数十年基础设施工作之上——分布式系统、数据管道、搜索引擎和编排平台，这些都是在"AI Native"成为流行语之前就已存在的技术。

这篇文章致敬那些传统开源项目，它们成为了 AI 基础设施的隐形基石。它们本身不是"AI 项目"，但没有它们，我们今天所知的 AI 革命就不会存在。

演进之路：从大数据到 AI

时代	关注点	核心技术	AI 关联
2000 年代	网络搜索与索引	Lucene、Elasticsearch	语义搜索基础
2010 年代	大数据与分布式计算	Hadoop、Spark、Kafka	规模化数据处理
2010 年代	云原生	Docker、Kubernetes	模型部署平台
2010 年代	流处理	Flink、Storm、Pulsar	实时 ML 推理
2020 年代	AI Native	Transformers、向量数据库	建立在上面所有技术之上

表 1: 数据基础设施演进

大数据框架：数据引擎

在我们能够对 PB 级数据训练模型之前，我们需要存储、处理和移动这些数据的方法。

Apache Hadoop (2006)

GitHub: https://github.com/apache/hadoop

Hadoop 通过让分布式计算大众化，证明了普通硬件可以处理网络规模的数据集。其 HDFS 文件系统和 MapReduce 范式成为大数据处理的基石。

对 AI 的意义：

现代机器学习训练数据集存储在与 HDFS 兼容的存储中
基于 Hadoop 构建的数据湖成为训练数据仓库
证明了分布式计算可以水平扩展

Apache Kafka (2011)

GitHub: https://github.com/apache/kafka

Kafka 以其基于日志的架构重新定义了数据流。它成为全球企业实时数据流的神经系统。

对 AI 的意义：

机器学习模型的实时特征管道
AI 智能体系统的事件驱动架构
流式推理管道
模型遥测和监控骨干网

Apache Spark (2014)

GitHub: https://github.com/apache/spark

Spark 将内存计算带入大数据，使迭代算法（如 ML 训练）能够规模化运行。

对 AI 的意义：

MLlib 使数据工程师能够使用机器学习
模型训练的分布式数据处理
Spark ML 成为大数据库机器学习的事实标准
证明了内存计算可以加速机器学习工作负载

搜索引擎：检索基础

在 RAG（检索增强生成）成为流行语之前，搜索引擎已经在解决规模化检索问题。

Elasticsearch (2010)

GitHub: https://github.com/elastic/elasticsearch

Elasticsearch 通过其分布式架构和 RESTful API 使全文搜索易于访问和扩展。它成为搜索的标准。

对 AI 的意义：

开创了分布式倒排索引结构
证明了搜索工作负载可以水平扩展
许多"AI 搜索"系统实际上在底层使用 Elasticsearch
查询 DSL 影响了现代向量数据库查询语言

OpenSearch (2021)

GitHub: https://github.com/opensearch-project/opensearch

当 AWS 分叉 Elasticsearch 时，它确保了搜索基础设施保持真正的开源。OpenSearch 继续着可访问、可扩展搜索的使命。

对 AI 的意义：

保持搜索的开源创新
2023 年添加了向量搜索功能
展示了社区分叉的韧性

数据库：从 SQL 到向量

从关系数据库到向量数据库的演变代表了范式转变——但两者都与 AI 相关。

铺路的传统数据库

Dgraph (2015) - 图数据库，证明专门的数据结构能够实现新的用例
TDengine (2019) - 用于物联网机器学习工作负载的时序数据库
OceanBase (2021) - 证明 ACID 事务可以扩展的分布式数据库

对 AI 的意义：

证明专门的数据库引擎可以超越通用数据库
数据库内部技术（索引、分片、复制）现在应用于向量数据库
多模型数据库（图 + 向量 + 关系）正在成为 AI 应用的标准

云原生：运行时基础

当 Docker 和 Kubernetes 出现时，它们并非为 AI 而构建——但没有它们，AI 无法规模化。

Docker (2013) & Kubernetes (2014)

GitHub: https://github.com/kubernetes/kubernetes

Kubernetes 成为云原生应用程序的操作系统。其声明式 API 和控制器模式使其非常适合 AI 工作负载。

对 AI 的意义：

模型部署平台（KServe、Seldon Core）运行在 K8s 上
GPU 编排（NVIDIA GPU Operator、Volcano、HAMi）扩展了 K8s
Kubeflow 使 K8s 成为机器学习管道的标准
微服务模式支持模块化 AI 智能体架构

服务网格与无服务器

Istio (2016)、Knative (2018) - 服务网格和无服务器平台，证明了：

网络级可观察性适用于 AI 模型调用
零扩展是成本效益推理的必要条件
流量分割实现机器学习模型的 A/B 测试

对 AI 的意义：

AI 网关模式从 API 网关 + 服务网格演变而来
无服务器推理平台使用 Knative 风格的自动扩展
可观察性模式（追踪、指标）现在是机器学习系统的标准

API 网关：从 REST 到 LLM

API 网关并非为 AI 设计，但它们成为 AI 网关模式的基础。

Kong、APISIX、KGateway

这些 API 网关解决了规模化限流、认证和路由问题。当大语言模型出现时，同样的模式适用：

AI 网关演进：

传统 API 网关 (2010 年代)
 ↓
限流 → 令牌桶限流
认证 → API 密钥 + 组织管理
路由 → 模型路由（GPT-4 → Claude → 本地模型）
可观察性 → LLM 特定遥测（令牌使用、成本）
 ↓
AI 网关 (2024)

对 AI 的意义：

证明了集中式 API 管理可以规模化
插件架构支持 LLM 特定功能
流量管理模式适用于提示路由
安全模式（mTLS、JWT）现在保护 AI 端点

工作流编排：管道骨干

数据工程需要管道。机器学习工程需要管道。AI 智能体需要工作流。

Apache Airflow (2015)

GitHub: https://github.com/apache/airflow

Airflow 通过其基于 DAG 的方法使管道编排易于访问。它成为 ETL 和数据工程的标准。

对 AI 的意义：

机器学习管道编排（特征工程、训练、评估）
证明了基于 DAG 的工作流定义可以规模化
提示工程管道使用 Airflow 风格的编排
调度器模式现在应用于 AI 智能体工作流

n8n、Prefect、Flyte

从 Airflow 基础演进而来的现代工作流平台：

n8n (2019) - 具有 AI 功能的可视化工作流自动化
Prefect (2018) - 面向机器学习的 Python 原生工作流编排
Flyte (2019) - 面向机器学习/数据的 Kubernetes 原生工作流编排

对 AI 的意义：

多模态智能体需要工作流编排
RAG 管道本质上是嵌入的 ETL 管道
提示链是基于 DAG 的编排

数据格式：湖屋基础

在我们能够对海量数据集进行训练之前，我们需要支持 ACID 事务和模式演进的格式。

Delta Lake、Apache Iceberg、Apache Hudi

这些表格式为数据湖带来了可靠性：

对 AI 的意义：

训练数据集需要版本控制和可重现性
特征存储使用 Delta/Iceberg 作为存储格式
证明"大数据"可以具有事务语义
模式演进处理机器学习特征漂移

隐形线索：为什么这些项目重要

所有这些项目有什么共同点？

它们首先解决了规模化问题 - AI 训练/推理需要水平扩展
它们证明了分布式系统可行 - 现代 AI 本质上是分布式的
它们创建了生态系统模式 - 插件系统、扩展点、API
它们建立了最佳实践 - 可观察性、安全性、CI/CD
它们培养了开发者习惯 - YAML 配置、声明式 API、CLI 工具

AI Native 连续体

现代"AI Native"基础设施没有取代这些项目——它建立在这些项目之上：

传统项目	AI Native 演进	示例
Hadoop HDFS	分布式模型存储	数据集用 HDFS，检查点用 S3
Kafka	实时特征管道	Kafka → 特征存储 → 模型服务
Spark ML	分布式机器学习训练	MLlib → PyTorch 分布式
Elasticsearch	向量搜索	ES → Weaviate/Qdrant/Milvus
Kubernetes	机器学习编排	K8s → Kubeflow/KServe
Istio	AI 网关服务网格	Istio → 带有 mTLS 的 LLM 网关
Airflow	机器学习管道编排	Airflow → 面向机器学习的 Prefect/Flyte

表 2: 从传统到 AI Native

我们为什么要从 AI 资源列表中移除它们

这篇文章致敬这些项目，但我们也要将它们从我们的 AI 资源列表中移除。原因如下：

它们不是"AI 项目"——它们是基础基础设施。

Hadoop、Kafka、Spark 是数据工程工具，不是机器学习框架
Elasticsearch 是搜索，不是语义搜索
Kubernetes 是通用编排
API 网关服务 REST/GraphQL，不仅仅是 LLM

但它们的存在并不影响其重要性。

通过移除它们，我们要承认：

AI 有自己的生态系统 - Transformers、向量数据库、大模型运维
传统基础设施有自己的领域 - 数据工程、云原生
交叉点是创新发生的地方 - AI 原生数据平台、基于 K8s 的大模型运维

我们站立的巨人

下次当你：

在 Kubernetes 上部署模型
通过 Kafka 流式传输特征
使用向量数据库搜索嵌入
使用 Prefect 编排 RAG 管道

记住：你站在 Hadoop、Kafka、Elasticsearch、Kubernetes 和无数其他项目的肩膀上。它们铺设了我们现在行驶的道路。

未来：建造新的巨人

正如 Hadoop 和 Kafka 使现代 AI 成为可能，今天的 AI 基础设施将成为明天的基础：

向量数据库 可能成为所有搜索的新标准
大语言模型可观察性 可能演变为通用分布式追踪
AI 智能体编排 可能重新发明工作流自动化
GPU 调度 可能影响通用资源管理

循环继续。今天的巨人将成为明天的基础。

结语：感恩与延续

当我们清理 AI 资源列表以专注于 AI 原生项目时，我们不会忘记我们的起源。传统大数据和云原生基础设施使 AI 革命成为可能。

致 Hadoop 贡献者、Kafka 维护者、Kubernetes 贡献者和所有构建基础的人：谢谢。

你们的工作使 ChatGPT、Transformers 以及我们现在称之为"AI"的一切成为可能。

站在你们的肩膀上，我们看得更远。

致谢：这篇文章受到需要重构我们的 AI 资源列表的启发。这里提到的 27 个项目将被移除——不是因为它们不重要，而是因为它们值得有自己的类别：基石。

加入 Dynamia 密瓜智能后的第一个月：为什么 AI Native Infra 值得投入

Jimmy Song — Fri, 06 Feb 2026 12:53:08 +0000

光阴似箭，不知不觉我加入「Dynamia 密瓜智能」已经一个月了。这篇文章想分享我这一个月的观察：为什么 AI Native Infra 是一个值得投入的方向，以及如果你也在考虑职业或技术方向，这里有什么可以参考的判断。

引言

结束了近五年的远程工作后，我在上个月正式加入 Dynamia 密瓜智能，担任开源生态 VP。这个决定并不突然，而是我从云原生走向 AI Native Infra 的自然延续。

但这篇文章不只讲我的个人选择，更想回答一个更普遍的问题：在 AI 基础设施创业浪潮中，为什么算力治理是值得投入的方向？

过去十年，我持续在基础设施领域工作：从 Kubernetes 到 Service Mesh，再到今天的 AI Infra。我越来越确信，AI 时代的核心挑战不是"模型能不能跑"，而是"算力能不能被高效、稳定、可控地运行"。这个判断，是我这一个月在 Dynamia 观察和思考后，更加坚定的结论。

这篇文章只回答三个问题：什么是 AI Native Infra、为什么 GPU 虚拟化是刚需、为什么我选择 Dynamia 与 HAMi。

什么是 AI Native Infra

AI Native Infrastructure（AI 原生基础设施）的核心，不是再加一层平台，而是重建治理对象：从“服务和容器”扩展到“模型行为与算力资产”。

我将它概括为三个变化：

模型成为执行主体：需要治理的不只是进程，还包括模型行为。
算力成为稀缺资产：GPU/显存/带宽需要被精细调度与计量。
不确定性成为默认状态：系统要能在波动中保持可观测和可恢复。

所以，AI Native Infra 的本质是：让算力治理从“资源分配动作”升级为“业务可持续能力”。

为什么 GPU 虚拟化是刚需

很多团队在做模型推理优化，但企业在生产环境里更先遇到的是“GPU 用不好”。这正是 GPU 虚拟化的价值所在。

结构性闲置：小任务独占大卡，GPU 长期空转。
伪隔离风险：原生共享缺硬边界，单任务 OOM 容易连带故障。
调度失灵：有人排队等卡，有人占卡不用，短缺与闲置并存。
碎片化浪费：有总量、无整卡，无法高效装箱。
厂商锁定焦虑：闭源和深度耦合方案让迁移成本失控。

一句话总结：GPU 不仅要能申请，还要能切分、隔离、调度和治理。

HAMi 与 Dynamia 的关系

这是最常被问到的问题，我用最短的话说明：

HAMi：CNCF 托管的开源项目与社区，聚焦 GPU 虚拟化与异构算力调度。
Dynamia（密瓜智能）：HAMi 的发起与主导公司，基于 HAMi 提供企业级产品与服务。

开源项目不等同于公司产品，但两者协同演进。HAMi 负责形成行业采用与技术信任，Dynamia 负责把能力落到企业生产环境并规模化运行。这种“双轮驱动”是 Dynamia 的独特性。

HAMi 提供了什么能力

HAMi（Heterogeneous AI Computing Virtualization Middleware）在 Kubernetes 上提供三类关键能力：

虚拟化与切分：将物理 GPU 按需切分为逻辑资源，提高利用率。
调度与拓扑感知：结合拓扑选择更优放置，减少通信瓶颈。
隔离与可观测：支持配额、策略与监控，降低生产风险。

目前，HAMi 已吸引来自 16 个国家的 360 余位贡献者，最终用户超过 200 家企业，并持续扩大国际影响力。

趋势对话：AI 基础设施创业浪潮

AI 基础设施正迎来新一轮创业热潮。上个月 vLLM 团队创立的公司完成 1.5 亿美元融资，SGLang 商业化后的 RadixArk 估值达 40 亿美元，Databricks 以 13 亿美元收购 MosaicML——这些都指向一个共识：谁能帮企业更高效、更低成本地运行大模型，谁就掌握下一代 AI 基础设施的钥匙。

在此背景下，Dynamia 与 HAMi 的定位更加清晰。很多团队做"模型性能加速"和"推理优化"（如 vLLM、SGLang），而我们选择做 “资源调度和虚拟化”——让现有加速硬件资源被更好地统筹使用。

两者相辅相成：前者让单个模型跑得更快更省钱，后者确保集群层面的算力分配是高效、公平且可控的。这类似于把 Kubernetes 在 CPU/内存调度上的思路，延伸到 AI 时代的 GPU/异构算力管理。

为什么 AI Native Infra 值得投入

这一个月的观察让我更加确信，算力治理是 AI 基础设施中最被低估、也最具潜力的方向。如果你在考虑职业或技术投入，我的判断是：

第一，这是一个真实且紧迫的痛点

模型训练和推理优化吸引了大量关注，但企业在生产环境首先遇到的是"GPU 用不好"——结构性闲置、调度失灵、碎片化浪费、厂商锁定焦虑。这些问题不解决，再快的模型也无法规模化落地。GPU 虚拟化与异构算力调度，是企业 AI 转型的"基础设施基础设施"（Infra below Infra）。

第二，这是一个清晰的长期赛道

vLLM、SGLang 等推理优化框架层出不穷，它们让单个模型跑得更快；但谁来确保集群层面的算力分配是高效、公平且可控的？这类似于把 Kubernetes 在 CPU/内存调度上的成功，延伸到 AI 时代的 GPU/异构算力管理。这不是一两年就能做完的事，而是未来五到十年的持续建设方向。

第三，这是一个开放且可验证的路径

Dynamia 选择以 HAMi 开源项目为底座，先解决通用能力，再支撑企业级落地。这意味着技术方向在社区是透明的、可验证的，你可以通过参与开源、观察采用、评估生态，来形成自己的判断——而不是依赖闭源方案的黑盒承诺。

第四，这是一个正在打开的窗口期

AI 基础设施正在重构，今天投入建设，价值会在未来几年持续释放。vLLM 团队的公司融资 1.5 亿美元，SGLang 商业化后的 RadixArk 估值 40 亿美元，Databricks 以 13 亿美元收购 MosaicML——这些都在验证同一个趋势：谁能帮企业更高效地运行大模型，谁就掌握下一代 AI 基础设施的钥匙。

我希望把过去在云原生和开源社区的经验，投入到 HAMi 与 Dynamia 的下一阶段：让 GPU 资源从"成本中心"变成"可运营资产"。这不仅是我的职业选择，更是我对下一代基础设施方向的判断和投入。

总结

从云原生到 AI Native Infra，我这一个月的观察让我更加确信：真正决定 AI 应用上限的，是基础设施对算力的治理能力。

HAMi 在解决 GPU 虚拟化与异构算力调度的基础问题，Dynamia 在推动这些能力进入大规模生产环境。如果你也在寻找一个值得长期投入的技术方向，AI Native Infra —— 尤其是算力治理与调度 —— 是一个真实痛点、清晰路径、开放生态且正在打开窗口期的赛道。

加入 Dynamia，不只是职业选择，更是参与下一代基础设施建设的选择。我希望这篇文章的观察和思考，能给你在判断技术方向和职业机会时提供一些参考。

加入 HAMi 社区

添加笔者微信 jimmysong 加入聚焦于 GPU 虚拟化与异构算力调度的 HAMi 社区交流讨论。

如果你也在关注 HAMi、GPU 虚拟化、AI Native Infra 或 Dynamia，欢迎交流。

我使用的 Vibe Coding 大模型推荐

Jimmy Song — Sat, 24 Jan 2026 10:44:42 +0000

编程模型的选择没有绝对标准，关键是找到最适合自己工作流的那一套组合。

最近经常有人问我一个问题：

你现在日常编程，到底在用哪些大模型？

索性借这篇文章，把我最近一个多月真实在用的 Vibe Coding 组合系统梳理一下。这不是一篇测评，也不是排行榜，更不是那种“用一次就来写推荐”的广告文，而是我已经稳定使用了一段时间、而且还在持续高频调用的模型与工具组合。

先说结论：我现在的主力模型组合

如果用一句话总结我现在的状态，大概是：

多模型并行 + 多工具入口 + 场景分工 + 顺手优先

目前我最常用的几类大语言模型（LLM）是：

智谱 GLM 4.7（编程大模型） 👉 日常主力，调用频率最高
Claude Sonnet 4.5 👉 目前我个人觉得“手感最好”的编程模型
Codex 5.2（ChatGPT / Copilot / OpenAI 系） 👉 解决疑难杂症、复杂上下文问题
Gemini 3.0 Pro（偶尔使用） 👉 免费额度在那，不用白不用

这些模型对我来说不是“谁淘汰谁”的关系，而是在不同工具和不同场景下，各自发挥价值。

为什么我会把 GLM 4.7 当作“日常主力”

我用智谱 GLM 4.7 已经接近一个月，累计 token 使用量接近 4 亿。这不是浅尝辄止，而是非常重度、非常日常的使用。

而且有一个很重要的前提是：我不是只在一个工具里用它。

订阅福利

速来拼好模，智谱 GLM Coding 超值订阅，邀你一起薅羊毛！Claude Code、Cline 等 20+ 大编程工具无缝支持，“码力”全开，越拼越爽！立即开拼，享限时惊喜价！订阅入口 - bigmodel.cn

下图展示了智谱官方优惠活动页面：

图 1: 智谱 GLM Coding 超值订阅优惠页面

不只是 Open Code，用起来顺才是真的顺

在 Open Code 里，GLM 4.7 是我最常切换到的模型之一：

反应速度快
成本可控
很适合高频打断、快速调整的 Vibe Coding 节奏

它非常适合那种“我先试一版 → 不满意 → 马上改 → 再细化”的工作流。

在 Cloud Code 里也很好用（这是关键）

另外一个让我持续使用 GLM 4.7 的原因是：它在 Cloud Code 里的体验也很好。

Cloud Code 本身是原生支持 Claude Code 的，而我经常：

在 Claude Code 的环境里
直接调用 GLM 4.7 来写代码、改代码、补逻辑

这点非常重要，因为这意味着：我并不需要为了用某个模型，去迁就某个工具。

GLM 4.7 能自然地融入我已经习惯的工具链，这是我持续用它的根本原因之一。

编程能力 + 成本，决定它能不能当“主力”

从纯编程体验来说，我的主观判断是：

GLM 4.7 至少在 Claude Sonnet 4.0 这一档

在 Web coding、脚手架、业务逻辑、快速原型这些高频场景里，它已经完全够用。

再加上成本压力明显更小，它就非常适合当那种“我可以放心多问几轮、多改几版”的主力模型。

下图为我个人 GLM 4.7 累计 token 使用量的截图：

图 2: 我已经使用了 4 亿 token 的智谱 GLM 4.7 模型

其他模型：我为什么还在用，但不用它们当主力

Claude Sonnet 4.5：目前最“顺手”的编程体验

我不避讳地说一句：Sonnet 4.5 依然是我心目中编程体验最好的模型之一。

但它的问题也很现实：

成本更高
更适合用在关键节点，而不是全程高频消耗

所以我通常把它用在：

架构级修改
比较关键的代码生成
需要一次到位的场景

Codex 5.2：专门解决“疑难杂症”

Codex 对我来说，更多是：

看复杂上下文
处理历史代码
解决“别的模型反复跑偏”的问题

好用，但不适合当烧 token 的主力。

Gemini 3.0 Pro：偶尔“薅一下免费额度”

我有时也会用 Gemini 3.0 Pro，尤其是在 Antigravity 里的调用，或者直接调用 Sonnet 4.5 或 Gemini。

下图展示了 Antigravity 工具中 Gemini 3.0 Pro 的界面：

图 3: Antigravity 里的 Gemini 3.0 Pro

原因很简单：有免费额度，不用白不用。

这类使用更多是补充型，不会进入我的核心工作流，但确实能解决一些临时需求。

Vibe Coding 的“灵魂”：语音输入

如果你还没试过语音 + 编程模型，那你对 Vibe Coding 的理解，可能还停留在 70%。

我目前最常用的：秒言（Mac）

我现在在 Mac 上主要用的是秒言：

识别准确
延迟低
非常适合边想边说、边说边改代码

下图为秒言语音输入法的界面截图：

图 4: 秒言语音输入法

虽然这家公司已经不在了，但我之前兑换过积分，目前还能继续用一段时间。

智谱 AI 语音输入法：性价比型选择

如果你已经订阅了智谱的编程套餐，那它的 AI 语音输入法是可以免费使用的。

客观说一句：

体验还在进化中
但胜在集成度高、额外成本为零

对已经在用 GLM 4.7 的人来说，这是一个完全合理的备选方案。

命令行工具的智能化：用免费方案也能很顺手

如果你主要在命令行环境工作，又希望有完全免费的模型支持，我建议试试 Sourcegraph 的 Amp。

它提供一个免费模式，支持在命令行工具里获得智能编程助手，唯一的代价是在命令行里显示广告。说实话，那点广告对用户体验的影响微乎其微，而且它的智能水平其实还不错。

对于命令行开发者来说，这是一个相当实惠的选择：

完全免费
无需付费订阅
命令行体验很顺畅
广告并不影响使用

如果你的工作流主要在终端，这套方案值得一试。

关于 GLM 4.7 的订阅这件事

这篇文章写到这里，你应该能看出来：我不是因为有优惠才开始用它，而是因为已经在用，所以顺便提一下优惠。

目前 GLM 4.7 的订阅正好处在优惠期，据我了解到这个月底结束，大概还剩一周左右。

如果你：

本来就需要一个可长期使用的编程模型
又不想在成本上太有心理负担

那这个时间点，其实还挺合适的。

文章里的链接和二维码，是我自己的订阅入口。是否使用，完全取决于你自己的判断。

最后一点个人感受

现在这种AI + 编程 + 语音的状态，对我来说已经有点像一种轻度娱乐。

有空的时候，我会随手做点 Vibe Coding：不一定上线、不一定交付，就是自己玩、自己爽、顺便学点新东西。

如果你已经在写代码，也已经在用大模型，我的建议只有一句：

不要执着于“哪个最强”，而是找到“在你工具链里最顺的那一个”。

对我来说，目前这套组合就是答案。

我的模型与工具实践补充

除了上面提到的主力模型和工具，我还经常在 VS Code 里用到 GPT-4.1 和 GPT-5 mini。因为我订阅了 Copilot Pro，这两个模型在 VS Code 侧边栏和编辑器内都可以免费用。

我的常见用法包括：

自定义提示词：比如让模型帮我优化文章结构、润色内容、自动排版，或者批量处理 Markdown。
调用 MCP/工具链：结合 VS Code 的 MCP 工具，快速插入新资源、生成图表、批量处理内容。

这种集成体验极大提升了内容生产和开发效率，尤其适合需要频繁编辑、重构、批量处理的场景。

另外，我还会用 OpenAI 推出的 Atlas 浏览器。它可以在浏览器侧边栏直接与 ChatGPT 对话，支持：

针对任意网页提问、总结、重写内容
直接访问本地网站和页面，调试本地服务
结合历史 Memory，跨网页追踪上下文
让 ChatGPT 充当编辑、UI/UX 工程师，给出专业建议

Atlas 最大的优势是免费、无缝集成，尤其适合调试本地网页、快速获取内容建议、或作为多角色 AI 助手。

这两个工具的组合，让我在内容创作、开发和调试时都能获得高质量、免费的 AI 支持。

总结

Vibe Coding 并不是“哪个模型最强”或“哪个工具最全”的问题，而是如何把多模型、多入口、多场景的能力，组合成最适合自己习惯的开发体验。我的实践证明，找到顺手的模型和工具链，才是提升效率和乐趣的关键。

ADD 的真正拐点：当 Spec 成为 AI 时代的软件核心资产

Jimmy Song — Tue, 20 Jan 2026 07:51:36 +0000

Spec 的角色正在发生质变，成为 AI 时代工程系统的治理锚点。

软件工程的本质与 AI 带来的成本结构变化

从第一性原理来看，软件工程始终在做一件事：把人类意图，稳定、可控、可复用地转化为可执行系统。

人工智能（AI）并没有改变这一工程本质，但它极大地改变了成本结构：

实现成本急剧下降：代码、测试、样板逻辑正在被快速商品化。
一致性成本显著上升：意图漂移、隐性冲突、跨模块不一致变得更频繁。
治理成本被放大：当 agent 可以直接“动手”，审计、责任与可解释性成为硬约束。

因此，ADD（Agent-Driven Development）时代的核心问题不是“能否让 agent 干活”，而是如何在 agent 高度自治的前提下，仍然保持工程系统的可控性与意图守恒。

ADD 时代的拐点：结构性变化的三大条件

许多人将 ADD 的“爆发”归因于多 agent 更成熟、模型更强、工具更自动。但实际上，真正的结构性拐点来自于以下三点同时成立：

Agent 已具备跨步骤执行能力

基于 LangChain、LangGraph、CrewAI 等框架，agent 不再只是 prompt 调用，而是能规划、拆解、执行、回溯的长生命周期实体。

Agent 开始进入 To B 的真实交付链路

一旦进入企业级研发，问题立刻从“能否生成”转变为“谁批准的、是否合规、能否回滚”。

传统工程工具缺乏代理时代的控制平面

Git、CI、Issue Tracker 等工具是为“人类开发者协作”设计的，而不是为“代理执行”设计的。

当这三点叠加，ADD 必然会从“效率工具”转向“治理系统”。

Spec 的角色变化：从说明文档到系统约束

在 ADD 语境下，Spec 正在发生根本性变化：

Spec 不再是“写给人看的说明”，而是“写给系统和 agent 执行的约束与事实来源”。

Spec 至少承担三类职责：

意图与边界的可验证表达

需求、验收条件、设计原则不再只是文本，而是可被检查、对齐、回溯的对象。

组织协作的稳定契约

当 agent 参与交付，口头共识和隐性经验会迅速失效，版本化、可审计的工件成为协作基础。

代理执行的策略面（Policy Surface）

Agent 能写代码、改配置、触发流水线，Spec 必须成为“什么可以做、什么不能做”的执行约束。

从这个角度看，Spec 的地位正在接近 AI-native 基础设施中的 Control Plane。

多 Agent 工作流的现实形态：编排与治理优先

在近期的一些系统（如 APOX 等 To B 产品）中，行业共识正在形成：

多 agent 协同不再追求“全自动”，而是阶段化、门禁化。
LangGraph 等框架用于构建可持久、可调试的 agent workflow。
RAG（如基于 Milvus）用于沉淀历史 Spec、决策、上下文为长期记忆。
IDE 主要负责执行效率，而不是工程治理。

图 1: APOX 用户界面

APOX（AI Product Orchestration eXtended）是一款面向企业级软件交付的多智能体协同工作流平台，其核心目标是：

把从产品需求到可执行代码的整个过程用可治理的 Agentflow + 明确的工程工件链路串联起来。
为每个交付阶段配备专职 AI agent（如 PRD、PO、Architecture、Developer、Impl、Coding 等）。
在每一步嵌入人工确认门禁与全量审计轨迹，从而解决传统 AI 编码工具无法治理“意图漂移与一致性”的问题。
平台提供 VS Code 插件，实现 IDE 本地与 Web 工件的实时同步，使 Spec 与代码、任务和审批状态在版本库中共存。
支持根据企业需求对不同 agent 分配不同基础模型。

APOX 的定位不是简单提高代码生成速度，而是把“规格（Spec）”从辅助文档提升为工程中可验证、可约束和可追溯的核心资产，构建适用于 Agent-Driven Development 的控制平面和工作流治理体系。

这类系统强调：

从 PRD → Spec → Task → Implementation 的显式工件链路。
每一阶段的人工确认与审计点。
Spec 与代码、仓库、IDE 的双向同步。

这不是“AI 更聪明”，而是工程系统在适配代理时代。

Spec 的长期价值：工程资产的核心锚点

这一判断并非贬低代码，而是承认现实：

算法和模型能力存在长期差异化。
通用工程实现正在快速同质化。
难以复制的是：如何定义问题、约束系统、治理变更。

在 ADD 时代，Spec 的价值体现在：

决定 agent 能做什么、不能做什么。
承载组织对系统的长期理解。
是审计、合规、责任追溯的锚点。

代码会被不断重写，Spec 才是长期资产。

ADD 的风险与挑战：Living Spec 与治理约束

ADD 也面临显著风险：

Spec 是否能成为 Living Spec

即：当实现发生关键变化，系统能否识别“意图变化”，并推动 Spec 更新，而不是悄然漂移。

治理是否能做到低摩擦但强约束

门禁过重，团队会绕开；门禁过轻，系统易失控。

这两点决定了 ADD 是“下一代工程范式”，还是“又一轮工具泡沫”。

工程系统的控制平面化趋势

从更宏观的视角看，ADD 是工程系统“控制平面化”的必然结果：

工程系统正在从“人类协作工具”，演进为“代理执行的控制系统”。

在这一结构中：

Agent / IDE 是 执行平面。
RAG / Memory 是 状态与记忆平面。
Spec 是意图与策略平面。
门禁、审计、回溯构成治理闭环。

这与 AI-native 基础设施的演进路径高度一致。

总结

ADD 时代的胜出者，不会是“agent 最多、生成最快”的系统，而是最先把 Spec 从文档升级为可治理、可审计、可执行资产的系统。在自动化程度不断提升的时代，真正稀缺的是对意图的长期控制能力。

AI 语音输入法正在成为编程时代的新快捷键

Jimmy Song — Sun, 18 Jan 2026 06:53:08 +0000

语音输入法不只是“快”，它正成为开发者与 AI 协作的全新入口。

注意

2026 年 1 月 12 日，因运营过程中遭遇资金困难，秒言项目宣布停止运营，团队同步解散。应用不再更新维护，现有版本在当前设备与系统下可继续使用，且不存储任何音频或转录内容。

图 1: 语音输入法能成为开发者的新快捷键吗？我的深度对比体验

AI 语音输入法，正在变成“编程时代的新快捷键”

我越来越确信一件事：PC 端的 AI 语音输入法，正在从“输入工具”，演化为编程与 AI 协作时代的基础交互层。

它不仅仅是为了更快打字，更决定了你如何把意图交给系统——无论是写文档、写代码，还是在 IDE、终端、对话框里和 AI 协作。

也正因为如此，语音输入法的体验差异，远比表面看起来要大。

我评估 AI 语音输入法的六个维度

在长期高频使用后，我总结出一套评估标准，用于判断 AI 语音输入法的实际表现：

响应速度：从按下快捷键到出字，是否足够跟得上思维
连续输入稳定性：长时间使用，是否会突然失效或漏识别
中英混输与专业词：代码、路径、缩写、产品名是否可靠
开发者友好度：是否真的考虑了命令行、IDE、自动化场景
交互克制程度：是否引入过多花样干扰输入本身
订阅与成本结构：是独立付费，还是能融入已有工具订阅

基于这些维度，我重点对比了秒言、闪电说 和 智谱 AI 语音输入法。

秒言：目前体验最“对路”的国产产品

秒言是我最早深度使用的国产 AI 语音输入法，也是目前整体体验让我最愿意持续使用的一个。

图 2: 秒言是我目前用的最多的 Mac 端语音输入法

秒言语音输入又快又准。注册解锁专属会员权益，立即开启高效输入！邀请链接：https://www.miaoyan.cn/download.html 邀请码：3JHI3XG5

命令模式：开发者效率的关键差异

需要特别说明的是，秒言的命令模式，并不是用语音改文本，而是：

你用自然语言描述需求，系统直接生成一条 可执行的命令行命令。

这对开发者来说非常重要：

不只是输入
而是把语音变成自动化入口
本质上是在把语音接入 CLI 或工具链

这种设计明显偏向 工程效率，而不是办公润色。

使用体验总结

响应速度快，接近即时
输出内容相对干净，不太乱猜
交互设计克制，没有多余概念
对开发者心智友好

但也有现实不足：

是一个 完全独立的产品
需要 单独付费
当前还处于相对小规模使用阶段

从产品策略看，它更像一个"纯工具"，而不是生态的一部分。

闪电说：端侧优先的路线，但开发者体验取决于你怎么配

闪电说更像是另一条路线：它把语音输入当作"本地优先的基础能力"，强调低延迟与隐私（至少产品叙事上是这样）。这种路线天然的优势是：速度与边际成本更可控，适合把语音输入当作"随时可用的系统能力"，而不是云端服务。

图 3: 闪电说设置页面

但从开发者体验的角度，它的上限往往取决于"增强能力怎么实现"：

如果只是做基础转写，体验会更像一款高质量的本地输入工具；但一旦你希望它在中英混输、术语纠错、符号与格式化上更进一步，常见做法是引入可选的 AI 纠错/润色能力，而这通常意味着额外配置（例如自带 Key 或订阅增强能力）。这条路线的关键 trade-off 不是"能不能用"，而是"你愿意为增强能力付出多少配置成本"。

如果你希望语音输入是"轻量、稳定、不打扰"的底座，闪电说值得放进对比；但如果你的目标是把语音变成开发者工作流的一部分（例如命令生成、可执行动作），那它需要在"命令层"和"可控性"上给出更强的产品化设计。

智谱 AI 语音输入法：稳定但有摩擦

我后来也完整试用了智谱 AI 语音输入法。

图 4: 智谱语音输入法的设置界面

它的优点在于：

长时间连续输入更稳定
很少出现完全无响应的情况
对较长中文输入容错不错

但在高频使用下，问题也很突出：

空档期误识别：按下快捷键但没说话，会识别出莫名字符，破坏输入节奏
输出内容偶尔偏乱：有时会多加无关词，整体可控性不如秒言
基础识别错误：如“智谱 → 智普”，对专业用户是信任问题
产品设计偏花：各种语气、风格相关设计，增加认知负担

订阅绑定：智谱的现实优势

虽然体验上我更偏向秒言，但 智谱有一个非常现实的优势：

如果你已经订阅了智谱的编程套餐，语音输入法可以直接免费使用。

这意味着：

不需要为输入法单独付费
心理和决策成本更低
更容易成为“默认工具”被留下来

从商业角度看，这是一个非常聪明的策略。

主要对比表

下表对比了三款产品在各维度的表现，便于快速扫读。

维度	秒言	闪电说	智谱 AI 语音输入法
响应速度	快，接近即时	通常偏快（端侧取向）	略慢于秒言
连续输入稳定性	稳定	取决于实现与环境	很稳定
空档期误识别	少	一般更克制（看版本）	明显：不说话也会出字符
输出干净度/可控性	高	偏"输入工具"风格	偶尔偏乱
开发者差异点	自然语言→可执行命令	端侧优先 / 可选增强	生态附带能力
订阅与成本	独立产品，需单买	基础可用；增强常需配置/订阅	绑定编程套餐可免费
我当前偏好	体验最好	更像"底座路线"	易留下但不够干净

表 1: 秒言、闪电说与智谱 AI 语音输入法核心对比

AI 语音输入法的用户忠诚度

语音输入法的迁移成本其实不高：一个快捷键，一种输出习惯。

真正决定用户是否留下来的，是：

输出是否可控
是否持续制造恼人的小问题
是否融入了你已有的工作流与付费结构

就我个人而言：

体验最好、最顺的，仍然是秒言
最容易被留下来的，很可能是智谱
闪电说更像"底座路线"，值得持续关注其增强能力的实现方式

这三点并不矛盾。

总结

秒言在 工程取向、命令能力、输入控制感 上更成熟
智谱在 稳定性与订阅绑定 上更有现实优势
闪电说走 端侧优先 + 可选增强 的路线，关键在于如何平衡"基础能力"与"增强成本"
谁能真正成为"默认入口"，取决于是否减少干扰、修复高频小问题，以及是否把语音输入真正当作"基础设施"而非附加功能

AI 语音输入法的竞争，已经不是识别率之争，而是谁能占住那个你每天都会按下的快捷键。

从空间数据到 AI 开源：技术标准、数据主权与全球化的分野

Jimmy Song — Sun, 11 Jan 2026 03:43:52 +0000

技术标准与数据主权的分野，决定了 AI 时代基础设施开源的全球竞争格局。

在本文中，我将以苹果地图和天气中空气质量数据的呈现差异为切入点，探讨技术标准与数据主权如何影响不同国家的 AI 开源路径，并进一步分析在 AI 时代，基础设施级开源为何成为生态主导权的关键战场。

作者按

这篇文章源自一个非常日常的观察：为什么在苹果地图和天气里，中国的空气质量数据是“点状”的，而其他国家往往是“面状”的。

图 1: Apple Weather 中的空气质量地图，从中可以看到中国的数据是点，而其他一些国家是面

起初它看起来像是产品体验差异，但当我把这个问题放到工程、标准和系统设计的语境下重新审视时，发现它其实指向一个更大的问题：不同国家如何理解技术、标准、开放与主权之间的关系。

作为一名长期从事云原生、AI 基础设施与开源生态工作的工程师，我逐渐意识到，这种差异并不只存在于空气质量或地图数据中，而是在 AI 时代被进一步放大，直接影响着我们如何开源模型、如何构建基础设施、以及是否能够参与全球规则的制定。

写下这篇文章，并不是为了评判对错，而是试图用一个具体而微的例子，解释一种结构性的差异，并讨论在 AI 时代，这种差异可能带来的长期影响与现实机遇。

尤其重要的是：在 AI 基础设施与 Infra 级开源这一层面，竞争才刚刚开始。中国并非没有机会，但路径选择将变得比以往任何时候都更加关键。

空气质量数据的呈现差异：技术标准与主权的缩影

下图展示了空间数据、AI 开源与技术标准的分野。通过对比不同国家在苹果地图和天气中空气质量数据的呈现方式，可以直观感受到背后技术标准与主权策略的不同。

图 2: 空间数据、AI 开源与技术标准的分野

如果你长期使用全球化产品，比如地图、天气、交通或各类数据服务，可能会注意到一个反复出现、却很少被认真讨论的现象：中国的数据呈现方式，往往与全球主流标准存在明显差异。

一个非常直观的例子，来自苹果地图或苹果天气中的空气质量展示。在中国，空气质量通常以一个一个离散的点呈现；而在美国、欧洲、日本等国家，它往往被渲染成连续覆盖的区域。

乍一看，这像是产品体验的差异，甚至会让人误以为“中国的数据不完整”。但如果把它当作一个工程问题、一个系统设计问题来思考，就会发现：这并不是数据能力的问题，而是技术标准、数据主权与开放策略的不同选择。

而这种选择，并不只体现在空气质量上。

空气质量只是切片：更大的差异在空间型公共数据

空气质量只是一个高度可见、风险相对较低的例子。类似的差异，长期存在于更广泛的空间型与公共数据领域。

地图与坐标体系
测绘与高精度空间数据
实时交通与人口流动
遥感、环境、城市运行数据

在全球主流体系中，这类数据通常被视为公共信息基础设施。它们被标准化、网格化、API 化，允许插值、建模和再分发，并被广泛用于科研、商业和产品创新。

而在中国，这些数据往往呈现出另一种形态：分级、离散、口径严格、解释权集中。

这不是单一领域的技术偏好，而是一种系统性的技术与治理逻辑。

全球视角下的三种路径

将中国放入全球坐标系，可以看到在“公共数据与技术标准如何开放”这个问题上，全球大致存在三种不同路径。

工程开放型：标准与生态优先

以美国及部分欧美国家为代表，这类体系的核心特征是：

公共数据优先作为基础设施
标准与接口先行
鼓励工程自治与生态演化
容忍模型推断与不确定性

这一路径直接塑造了全球基础软件与基础设施级开源格局。Linux、Kubernetes、云原生体系，本质上都是规则层开放的产物。

治理主权型：可控与可审计优先

以中国为代表，这一路径更强调：

空间与公共数据的敏感性
数据首先是治理能力的一部分
标准、口径、发布方式高度绑定
强调可追溯、可问责、可控

在这种体系中，“点状数据”并不是技术落后，而是一种可治理的技术形态。当一个技术系统被设计为治理系统时，它的首要目标并不是可复用性，而是可控性。

折中协调型：谨慎开放、工程国际化

还有一些国家试图在两者之间寻找平衡，在空间数据上保持谨慎，在工程与产业层面高度国际化。它们说明了一点：差异并非先进或落后，而是目标函数不同。

下图从全球视角对比了这三种路径的核心特征、典型案例及其优势与挑战。左侧的“工程开放型”通过标准与生态主导了全球基础软件格局；中间的“治理主权型”强调数据主权与安全可控，但在规则层影响力上存在局限；右侧的“折中协调型”试图在安全与开放之间寻求平衡。这三种路径的分野，直接影响着各国在 AI 时代的基础设施竞争格局。

图 3: 全球视角：公共数据与技术标准开放的三种路径

空气质量“点”与“面”的本质

在所有空间型公共数据中，空气质量是一个非常理想的观察窗口：

不直接涉及军事或核心经济安全
高度可见、每日更新、人人可感知

中国并不缺空气质量数据，恰恰相反，监测站密度处于全球领先水平。真正的差异在于：

是否允许插值
是否允许模型推断
是否允许平台进行二次解释

“点”意味着真实、可追溯；“面”意味着模型、推断与解释权的再分配。这正是技术标准与数据主权的分水岭。

下图对比了两种不同的技术路径：左侧的“治理主权型”强调数据的可追溯性和可控性，采用离散的点状数据呈现；右侧的“工程开放型”则允许模型插值和推断，通过连续的面状区域提供更友好的用户体验。这种差异的本质不在于技术能力的高低，而在于对数据主权、治理能力与开放生态之间权衡的不同选择。

图 4: 空间数据呈现方式的技术标准与主权分野

AI 时代的放大效应

理解了上述逻辑，很多 AI 时代的现象就不再令人困惑。

例如：

为什么中国的 AI 公司更愿意开源大语言模型（LLM）权重，而美国公司近几年却明显转向闭源？
为什么基础软件与基础设施级开源，依然主要由美国主导？

关键不在“开不开源”，而在于“开源到哪一层”。

模型权重，是静态、可声明的资产
基础设施、运行时、协议与标准，是动态、可演化的系统规则

开源权重，本质上是资产层的开放；而基础设施级开源，意味着对运行规则与解释权的让渡。

下图对比了 AI 开源的两个不同层次。左侧展示的是“模型权重层开源”，这是中国路径的典型特征——开放静态的数字资产，成本低且风险可控，但不涉及运行规则的制定。右侧展示的是“基础设施层开源”，这是美国路径的核心策略——通过开放开发工具、协议标准、运行时和算力调度等基础设施，定义 AI 的使用方式，从而掌握生态规则与解释权。关键洞察在于：开源模型权重不等于掌握 AI 生态，真正的竞争焦点正在向“AI 如何运行”的基础设施层转移。

图 5: AI 时代开源的两个层次：模型权重 vs 基础设施

美国的选择：主攻规则层与运行层

过去一两年，美国主导的 AI 开源与生态动作展现出高度一致的方向：并不急于开源最强模型，而是集中定义“AI 如何被使用”。

Linux Foundation 新成立 AAIF（Agentic AI Foundation），重点放在 AI 基础设施、标准与工具链协作
以 MCP（Model Context Protocol）为代表的协议，试图定义 Agent 与工具、系统的通用交互方式
大型科技公司普遍把重心放在 API、平台、运行时与生态绑定上

这些动作的共同点是：竞争模型能力，但掌控使用规则。

中国的变化：从模型导向走向基础设施导向

需要强调的是，这种差异，并不意味着中国没有意识到问题。

无论是在政策讨论层面，还是在产业与研究机构内部，“只开源模型而不掌握基础设施与标准主导权”的风险，早已被反复讨论。

真正的难点在于，如何在既有治理逻辑与风险框架下，完成方向性的转向。而这种转向，已经在一些具体实践中出现。

基础设施层的探索与实践

在 AI 时代，基础设施往往从最工程化的问题开始。

HAMi 项目

HAMi 这类项目关注的并不是模型能力，而是：

GPU 资源的抽象、分配与隔离
多租户 AI 工作负载的运行方式
算力如何从硬件资产转变为可治理系统资源

这类项目的意义不在于“是否 SOTA”，而在于它们开始进入“AI 如何运行”的问题域。

系统软件视角的 AI Runtime 重构

研究机构层面的探索同样值得关注。智源研究院推动的 FlagOS，本身就是一个清晰信号：AI 正在被重新视为系统软件问题，而不仅是模型或算法问题。

产业级玩家的长期技术栈投入

在产业界，华为的策略也体现出类似方向：不是简单开源模型，而是尝试构建完整、可控的 AI 技术栈，从算力到框架，再到平台与生态。这是一条更慢、更重，但更接近基础设施级竞争的路径。

现实判断：AI 基础设施竞争的起点

把视角拉长，会发现一个容易被忽略的事实：

在 AI 基础设施与 Infra 级开源这个层面，中美之间并不存在一个已经尘埃落定的格局。

美国的优势在于：

成熟的工程文化
标准组织与基金会机制
对规则层开放的高度熟练

而中国的变量在于：

巨大的 AI 应用场景
对算力与系统效率的极端需求
正在发生的方向性调整

真正的不确定性不在于“能不能追上”，而在于：是否能够在保持治理底线的前提下，逐步释放工程自治与标准共建的空间。

总结

空气质量的“点”与“面”、模型权重与运行世界，这些表象背后指向的，从来不是简单的技术路线之争，而是一个国家如何在开放、标准与主权之间，寻找自己的平衡点。

AI 时代，这个问题不会消失，只会变得更加具体、更加工程化。而这，正是中国 AI 基础设施开源仍然存在机遇的地方。

正式加入 Dynamia 密瓜智能，开启 AI 原生基础设施新征程

Jimmy Song — Wed, 07 Jan 2026 07:41:57 +0000

算力治理是 AI 规模化落地的关键瓶颈，从硬件消耗到核心资产，这条长期被低估的路径需要被重新定义。

图 1: Dynamia.ai 密瓜智能

新的起点

我近日正式加入 Dynamia 密瓜智能，出任 开源生态 VP，负责公司在开源、技术叙事与 AI 原生基础设施（AI Native Infrastructure）生态方向的长期建设。

为什么选择 Dynamia

我选择加入 Dynamia，并非因为这是一家试图“解决 AI 一切问题”的公司，而恰恰相反，是因为 Dynamia 高度聚焦于 AI 原生基础设施中一个无法回避、却长期被低估的核心问题：算力，尤其是 图形处理器（GPU），正在从“技术资源”演变为一种需要被精细化治理和经济化管理的基础设施要素。

在长期的云原生、分布式系统与 AI 基础设施（AI Infra）实践中，我逐渐形成了一个清晰判断：随着大语言模型（LLM）和 AI 代理（AI Agent）进入规模化落地阶段，真正限制系统扩展性与可持续性的瓶颈，已不再只是模型能力本身，而是算力如何被计量、分配、隔离、调度，以及如何在系统层面形成可治理、可核算、可优化的运行机制。从这一视角看，AI 基础设施的核心挑战，本质上正在演变为一个“资源治理与 Token 经济”问题。

关于 Dynamia 与 HAMi

Dynamia 密瓜智能是一家专注于 AI 原生基础设施的科技公司，植根开源基因，通过技术创新驱动异构算力效率跃升。公司主导的开源项目 HAMi（Heterogeneous AI Computing Virtualization Middleware）是 云原生计算基金会（CNCF）沙箱项目，提供 GPU、NPU 等异构设备的虚拟化、共享、隔离和拓扑感知调度能力，已被 50+ 企业和机构广泛采用。

Dynamia 的技术路线

在这一背景下，Dynamia 所坚持的技术路线——从 GPU 这一 AI 系统中最昂贵、最稀缺、也最缺乏统一抽象的一层 入手，将算力视为一种可以被度量、被切分、被调度、被治理，乃至被“Token 化”进行精细化核算与优化的基础资源——与我对 AI 原生基础设施的长期判断高度一致。

这条路径在短期内并不以“模型能力”或“应用创新”为卖点，也并不容易被简单包装成故事；但在算力成本持续上升、异构加速器成为常态、AI 系统走向多租户与规模化运营的趋势下，这类基础设施层面的能力，正逐渐成为 AI 体系能否成立与扩展的前提条件。

未来工作重点

作为 Dynamia 的开源生态 VP，我将重点投入在 AI 原生基础设施的技术叙事、开源生态建设与全球开发者协作 上，推动算力从“被消耗的硬件资源”，走向 可治理、可计量、可优化的 AI 基础设施核心资产，为下一阶段 AI 系统的规模化与可持续演进奠定基础。

总结

加入 Dynamia 是我职业道路上的一个重要节点，也是我对 AI 原生基础设施长期看好的一次实际行动。算力治理不是短期能见效的热点，但却是 AI 规模化落地绕不开的基础设施命题。我期待与全球开发者一起，在这条长期被低估的路径上探索、建设、落地。

参考文献

在我的 Mac 上并行运行 AI Agent：Verdent 独立应用实战体验

Jimmy Song — Sun, 04 Jan 2026 02:26:07 +0000

最近我花了更多时间在真实项目中体验“vibe coding”类工具，而不是只做演示。其中一个项目就是我的个人网站，我经常调整内容结构、导航和布局。

在这个过程中，我开始更认真地使用 Verdent 的 Mac 独立应用。让我印象深刻的不是某个单一功能，而是它与传统 AI 编码工具截然不同的整体体验。

图 1: Verdent 独立应用界面

Verdent 并不像一个等待指令的助手，更像是一个让工作可以并行推进的环境。

不同的起点：以任务为中心，而非对话

大多数 AI 编码工具以对话为起点，Verdent 则以任务为起点。

我在 Verdent 应用中打开网站仓库时，没有先写一大段 prompt，而是直接创建了多个任务：一个重构导航和 SEO 结构，一个探索首页布局优化，还有一个审查现有内容组织。

每个任务都会立即启动自己的 agent 和独立工作区。从一开始，应用就鼓励我像在纸上画草图或在多个文件间跳转那样“并行思考”。

这种框架本身就改变了工作方式。

为多任务而生，始终保持上下文

在真实开发中切换上下文不可避免，通常最容易丢失的是连续性。

Verdent 处理得很好。每个任务都独立保存完整上下文。我可以中断一个任务，切换到另一个，稍后再回来，无需重新解释问题或加载文件。

比如，一个 agent 正在分析网站导航结构，另一个在探索布局方案。我可以自由切换，所有进度都不会丢失，每个 agent 都记得自己在做什么。

这种体验比传统对话式工具更贴近开发者的思维方式。

用 Workspace 安全并行

并行讨论相对容易，但当并行变成同时改代码时，隔离变成了必需。

Verdent 用 Workspace 来解决这个问题。每一个 Workspace 都是隔离独立的代码环境，有自己的修改状态、提交记录和分支。这不仅仅是分离的问题，而是让并发代码改动变得可管理。

具体效果：

多个任务可以同时写代码
改动互不影响
若有冲突，清晰可见、可处理

我故意让不同的 agent 涉及项目的重叠部分：一个修改 Markdown 内容和链接，另一个调整 CSS 和布局逻辑。它们在各自的 Workspace 里同时运行。没有发生冲突。后来我审查了每个 Workspace 的差异（diff），只合并了合理的部分。

这种隔离消除了 AI 辅助编码中的大量焦虑。不用担心并行编辑造成破坏，开始更自由地实验，因为每个改动都存在于自己独立的代码环境里。

并行 agent 更像“分工协作”

并行并不意味着所有 agent 在同一时刻完成同一阶段的工作，而是通过隔离与阶段重叠，把原本串行的流程压缩成更高效的协作模式。

在 Verdent 中，每个 agent 运行在独立的工作区，本质上是自动管理的分支或工作树。在实践中，我会为同一个需求创建多个职责不同的 task，例如规划、实现和审查。但这并不意味着它们在同一时刻完成同一阶段的工作。

这些 task 会按需被触发，各自执行一段时间并产出明确的工件（artifacts）作为协作边界。规划 task 负责生成规划文档或约束说明；实现 task 基于这些文档推进代码改动并产出 diff；审查 task 则依据既定的规划目标和审计标准，对已生成的变更进行阶段性 review。通过以工件为中心的阶段重叠执行，原本严格串行的流程被压缩为更接近团队协作的工作方式。

拆分为多个 task 的价值不在于并行执行，而在于并行认知和清晰的协作边界。

虽然把多个角色放进同一个 task 在技术上是可行的，但会让规划、实现和审查共享同一个上下文，从而削弱角色隔离和结果可审查性。

可定制性与设计取舍

除了工作流本身，Verdent 还开放了丰富的可配置能力。

你可以自定义 MCP 设置，创建带自定义 prompt 的 subagent，通过斜杠（/）命令快速复用 prompt，还能编写个人规则（Rules）影响 agent 行为和回复风格，并为命令配置权限（Permissions）实现基础安全隔离。Verdent 支持主流大模型（GPT、Claude、Gemini、K2），还集成了 DiffLens，适合不想用 IDE、只需轻量代码审查体验的用户。支持订阅和 credit 充值两种计费方式。

图 2: Verdent 设置界面

当然，Verdent 也有明确的设计取舍。它不是围绕 tab 补全，也没有插件系统，否则就会变成传统 IDE——这显然不是它的目标。Verdent 并不追求对代码的细粒度直接操作，大多数变更都通过对话任务和 agent 编辑间接完成。这让体验更纯粹聚焦，但对于超大型复杂代码库，Verdent 更适合作为编排层补充，而非主力开发环境。

Verdent 的定位

现在 AI 编码工具层出不穷，有的主打更智能的编辑器，有的追求更快的生成。

Verdent 的独特之处在于它关注编排，而不仅仅是“助手”。

它不试图取代你的编辑器，而是作为更高一层的“总控”，协调多个 agent 的规划、执行和审查。

这让它特别适合探索性开发、重构和早期设计——正是我在网站项目中最常做的工作。

总结

Verdent 独立应用不仅提升了效率，更改变了我的工作结构。

我不再一切都按顺序推进，而是重新回到“并行思考”，让系统来支撑这种方式。

Verdent 更像是默认假设 AI 已经深度融入开发流程的环境，而不是某个“AI 功能”。

对于想要尝试 AI 原生工作流的开发者，这种转变值得关注。

2025 年度回顾：从云原生到 AI 原生的蜕变之旅

Jimmy Song — Wed, 31 Dec 2025 10:02:01 +0000

技术的浪潮不断演进，唯有主动拥抱变化，才能持续创造价值。2025 年，我选择了从云原生迈向 AI 原生，这一年是自我突破与体系重塑的关键节点。

2025 年对我而言，是一个转折点。这一年，我不仅改变了技术方向，也改变了思考问题的方式。从云原生基础设施到 AI 原生基础设施，这不仅是内容的迁移，更是思维模式的升级。

图 1: 再见 2025！

这一年，我对网站进行了大规模的重构，并对内容进行了系统性的整理。除了技术层面的改进，我更想分享这一年来的思考和变化。

一次勇敢的转身：拥抱 AI 原生时代

2025 年初，我做了一个重要的决定：将个人定位从云原生布道师转变为 AI 基础设施架构师。这不仅仅是一个头衔的变更，更是一次深思熟虑的战略转型。

当我看到 AI 技术浪潮席卷而来，Agent 化应用开始改变软件的形态，我意识到：如果继续固守云原有的边界，可能会错过一个时代。于是，我开始系统性地调整网站的内容结构，将重心转向 AI 原生基础设施。

这次转型并非放弃过去，而是在云原生的基础上向前延伸。Kubernetes 和 Istio 等云原生经典内容依然保留并持续更新，但新增了 AI Agent 设计模式、AI 原生全景图等内容，形成了更完整的知识版图。

内容创作：从技术细节到生态视野

AI Agent 设计模式：系统化知识构建

Agent 是 AI 时代软件形态的一次重要进化。但当我试图理解 Agent 的设计原理时，发现碎片化的信息无处不在，却缺乏系统性的知识体系。于是，我开始撰写《AI Agent 设计模式》这本书。

书中分析了 Agent 的上下文生命周期、控制循环机制，总结了多个经过验证的架构模式。为了让复杂的知识更易消化，我采用了分册结构，将内容划分为多个逻辑部分，让读者可以循序渐进地学习。

AI 工具生态：绘制开源全景图

AI 领域的工具和框架层出不穷，每天都有新的项目诞生。为了帮助读者快速理解这个生态，我建立了一个完整的 AI OSS 资料库。

这个资料库涵盖了从 Agent 框架到开发工具，再到部署服务的全栈内容。我不仅收录了当前活跃的项目，还建立了归档机制，保存了 150+ 个历史项目的详细信息。更重要的是，我开发了一套评分系统，从质量、可持续性等多个维度对项目进行客观评价，帮助读者判断哪些工具值得投入时间学习。

博客写作：更快速地捕捉技术趋势

2025 年，我写了 120 多篇博客文章。相比往年，这些文章更注重对技术趋势的观察和思考，而非单纯的技术教程。

我开始关注更深层次的问题：AI 基础设施会如何演进？北京的开源计划对 AI 产业意味着什么？一次技术收购可能引发什么样的蝴蝶效应？这些文章让我和读者一起，不仅看到了技术的"是什么"，更思考了"为什么"和"会怎样"。

用户体验：让知识更易被发现和消费

内容再好，如果无法被便捷地发现和阅读，价值也会大打折扣。2025 年，我在网站功能上投入了大量精力，目标只有一个：让读者获得更流畅的阅读体验。

搜索的全面升级

随着内容量的增长，原有的搜索功能已经难以满足需求。我重新设计了搜索系统，不仅支持模糊搜索和结果评分，还优化了搜索索引的加载性能。更重要的是，新的搜索界面更加友好，支持键盘导航和分类过滤，让用户可以更快地找到想要的内容。

多端体验优化

移动端的阅读体验得到了显著提升。我重构了移动端导航和目录系统，让手机上的阅读更加顺畅。深色模式也更加完善，不仅修复了多个显示问题，还确保了图片和图表在深色背景下的良好呈现。

内容分发的效率革命

一个重要的变化是微信公众号发布工作流的优化。以前将网站内容发布到公众号需要手动处理很多细节，现在几乎可以实现一键导出。这个工作流自动处理图片、元数据、样式等所有细节，将原本需要半小时的工作压缩到几分钟。

此外，我还新增了术语表功能，为技术术语添加了高亮和提示；优化了 SEO 和社交媒体分享的元数据；整理了过时内容，统一了图书的封面和元数据。这些看似细微的改进，都在默默提升着用户的体验。

内容演变：更立体的知识表达

回顾 2025 年的内容创作，我发现自己在几个维度上都有了明显的变化。

从教程到观察

早期的内容更偏向于技术教程和实践指南，告诉大家"怎么做"。但今年，我更关注"为什么"和"趋势是什么"。我开始写更多技术趋势分析、生态地图绘制、深度案例研究。这些内容或许不能直接告诉你某个 API 怎么用，但能帮助你理解技术演进的方向。

从中文到双语

AI 是全球性的技术浪潮，不能局限于中文世界。2025 年，我几乎为所有新增的 AI 工具都撰写了中英文双语文档，重要博客文章也都有英文版本。这虽然增加了工作量，但让内容可以触达更广泛的读者。

从文字到多媒体

文字是高效的，但并非所有的知识都适合用文字表达。今年我大量使用架构图和示意图来解释复杂概念，全年新增了 59 个图表。这些视觉化的内容降低了理解门槛，让抽象的概念变得更加直观。同时，我也优化了图片在深色模式下的显示，确保视觉体验的一致性。

开发方式：拥抱 AI 辅助编程

2025 年不仅是内容主题转向 AI 的一年，也是我自己深度实践 AI 辅助编程的一年。

我开发了 VS Code 插件，创建了大量 prompt 来自动化重复性工作。我尝试了多种 AI 编程工具，确定了适合自己的工具链。我甚至将网站迁移到了 Cloudflare Pages，利用其边缘计算服务开发了聊天机器人。这些实践大大提升了开发效率，让我有更多时间专注于思考和创造，而非机械的编码。

这让我深刻体会到：AI 不会取代开发者，但善于使用 AI 的开发者会取代不使用 AI 的开发者。我也将更多的心得分享出来，帮助更多人掌握 AI 辅助编程的方法。

展望 2026：继续前行

回顾 2025 年，本站完成了一次深刻的蜕变：从云原生技术博客转变为 AI 基础设施知识库。但这只是一个开始，不是终点。

展望 2026 年，我计划在几个方向上继续深耕：

完善知识体系：继续补充 GPU 基础设施和 AI Agent 的内容，特别是实战案例和性能调优方面的知识。
跟踪生态演进：AI 工具和框架的迭代速度极快，我需要持续跟踪这个快速变化的生态，及时更新内容。
深化工程实践：分享更多 AI 工程化的实战经验，帮助读者将理论转化为实践。
探索知识连接：考虑建立知识图谱，将不同内容版块连接起来，提供更智能的导航和推荐。

写在最后

2025 年是变革的一年，也是成长的一年。从云原生到 AI 原生，从技术实践到生态观察，本站的内容和功能都发生了质的飞跃。

但更让我欣慰的是，这次转型让我和读者一起，站在了技术浪潮的前沿。我们不仅在学习新技术，更在思考技术如何改变世界，如何改变我们编写软件的方式。

技术的浪潮不断演进，唯有主动拥抱变化，才能持续创造价值。感谢每一位读者的陪伴和支持，期待在 2026 年继续分享技术的洞察和实践。

延伸阅读：

秒言：一个更适合中文语境的语音输入工具（对我来说是 Whisper Flow 的现实替代）

Jimmy Song — Wed, 31 Dec 2025 03:21:13 +0000

语音输入工具的真正价值，在于能否无缝融入日常写作与沟通流程。秒言让我第一次觉得“语音 + AI”在中文场景下变得顺手且高效。

注意

图 1: 语音输入

最近我重新开始尝试语音输入工具，起因很简单：有人在微信上推荐了秒言。

图 2: 秒言 macOS UI

此前我曾试用过 WisprFlow，也曾写过文章吐槽它在中文场景下的体验——中文识别不够稳定，加上订阅价格并不便宜，最终我选择卸载。

这次试用秒言后，我的结论很明确：它是我目前用过更接近“可以日常使用”的中文语音输入工具之一。

秒言让我愿意继续用下去的两个关键点

在实际体验过程中，秒言有两个让我愿意持续使用的突出优点：

快

按下快捷键开始说话，松开键文字就插入到当前输入框里，几乎没有延迟感。这种“没有打断感”的输入流非常关键，决定了它能否成为日常工具。
准

尤其是在中文口语、连续表达，以及中英文混合的场景下，识别准确率明显优于我此前对同类产品的预期。对于我这种经常写技术文档、夹杂英文名词的人来说，这一点非常加分。

正是因为这两个原因让我觉得秒言是特别适合作为氛围编程的一个语音输入工具，因为在使用 CLI 的时候，如果你在 Vibe coding 工具中输入中文的时候，会出现如下这种情况，中文与输入框不对齐。

图 3: 命令行中输入中文与输入框不对齐

这种情况下就特别适合语音输入，秒言可以完美解决这个问题。

命令模式：AI 能力真正融入输入流

秒言最吸引我的功能是它的命令模式。

你可以直接对着输入框说“把这段话翻译成英文”“帮我整理成会议纪要”“改写得更正式一点”，它会把结果直接输出到你正在输入的地方，而不是跳转到另一个聊天窗口。

这种设计的价值在于：AI 能力嵌入输入流，而不是额外增加一个流程。

这也是我认为它“对标 Wispr Flow”最关键的一点——但在中文语境下，秒言更顺手。

平台覆盖与费用说明

关于平台支持和费用，秒言目前覆盖桌面端（macOS/Windows），移动端暂时还没有。

费用方面，界面里会出现类似 Pro 的提示，但和团队确认后，目前整体是免费开放，普通用户有足够的日常使用时长，实际体验中基本不会被限制打断。

总结

秒言在中文语境下的语音输入体验，已经接近“可以日常使用”的标准。

无论是输入流畅度、识别准确率，还是命令模式的 AI 能力嵌入，都让它成为我目前最推荐的中文语音输入工具之一。

如果你正在寻找一款真正适合中文场景的语音输入工具，不妨试试秒言。

秒言语音输入又快又准。注册解锁专属会员权益，立即开启高效输入！邀请链接：https://www.miaoyan.cn/download.html 邀请码：3JHI3XG5

参考文献

秒言官网 - miaoyan.cn

Manus 被 Meta 收购后的蝴蝶效应

Jimmy Song — Tue, 30 Dec 2025 03:18:24 +0000

AI 应用的成败，往往不在于技术本身，而在于能否将能力规模化交付并形成闭环。

图 1: Manus 被 Meta 收购后的蝴蝶效应

当“讨论它的人”并不是“付费它的人”

2025 年 12 月 30 日，一条消息刷屏朋友圈：Meta 以数十亿美元收购 Manus（Manus Joins Meta for Next Era of Innovation）。这家起家于中国、从诞生起就面临大厂围剿压力的创业公司，在不到一年的时间里完成了从爆红、迁往新加坡、到被全球巨头收购的“终局冲刺”。

Manus 官方口径是：产品与订阅将继续通过 App 和网站提供，公司仍在新加坡运营；而团队将并入 Meta，为其消费者与企业产品（包括 Meta AI）提供通用 Agent 能力。

与“谁赢了”相比，我更关注这件事引发的连锁反应：它在不同人群中触发了完全相反的判断体系，而这种分裂会反过来重塑 AI 应用的增长路径与创业策略。

两种舆论场：祝福与质疑并存

Manus 被收购后，朋友圈的主流情绪是祝福与兴奋，大家将其视为华人团队全球化的一次漂亮样本——在最卷的赛道里，用极短时间拿到极大结果。

与此同时，公众号评论区则成为“反叙事的泄压阀”，质疑主要集中在以下三点：

技术是否有壁垒（如“同类多如牛毛”“大厂自研不难”）。
估值与泡沫（如“AI 泡沫又一例”）。
对买方判断力的不信任（如“巨头病急乱投医”“重演旧故事”）。

这种分歧并非谁更懂 AI，而是评价坐标系不同：朋友圈关注“路径与结果”，评论区则关注“正当性与配不配”。

1 亿 ARR 从哪里来：目标用户不在你我的社交圈

许多人对 Manus 的营销声量和争议印象深刻，容易先入为主地产生保留态度。但如果它在 10 个月内实现“严格口径 1 亿 ARR”，就说明一个事实：它的收入并不依赖“广泛共识”，而来自一群高度集中、强付费意愿的全球用户。

Manus 的核心用户画像更接近“个人即生产单元”的群体，包括自由职业者、独立开发者、独立研究者以及中小企业的关键交付者。他们不在乎争论“是不是套壳”，只关心“能否端到端把任务交付出来”，以及“能否让我少雇一个人、少熬几个夜、少切十个工具”。

因此，出现了一个反直觉现象：讨论最热的人未必付费，付费最稳的人往往沉默。

对于这些用户而言，工具不是身份标签，而是利润杠杆。

对创业者的三点启示：AI 应用时代的增长范式变了

结合上述现象，Manus 案例为创业者带来三点启示：

增长不再等同于好评率

AI 应用可以先商业化、后形成共识。舆论场可以长期撕裂，但现金流不会等待认知统一。

“重营销”正在从污名变成能力

当底层模型与能力扩散速度极快，差异会被迅速抹平。能否被看见、被理解、被买单，本身就是壁垒的一部分。不是所有营销都值得尊重，但“分发与心智占领”已经成为 AI 应用不可回避的战场。

全球化不再是锦上添花，而可能是生存策略

从支付意愿、合规边界、人才密度到估值体系，市场结构决定了很多团队“只能在海外完成闭环”。这并不浪漫，但很现实。

我的一个感想

作为长期从事云原生与 AI 基础设施的人，我习惯用“技术壁垒”去评估产品；而 Manus 这类案例提醒我：在 AI 应用层，壁垒未必首先体现在模型或代码，而常常体现在 组织速度、产品化能力、交付闭环与分发效率。

当一个系统能把“能力”稳定地转化为“结果”，它就拥有了商业意义上的护城河——哪怕技术栈并不满足旁观者对“纯粹”的想象。

Manus 被 Meta 收购的最大蝴蝶效应，或许不是一笔交易本身，而是让更多创业者意识到：AI 时代的胜负手，正在从“你用什么模型”转向“你能不能把结果规模化交付”。

总结

Manus 被 Meta 收购事件，不仅是一次资本与技术的交汇，更是 AI 应用时代增长范式转变的缩影。对于创业者而言，如何理解并把握“用户结构”“分发能力”与“全球化闭环”，将成为未来竞争的关键。

从京沪开源生态方案，看中国 AI Infra 开源的机会、路径与约束

Jimmy Song — Thu, 25 Dec 2025 10:01:19 +0000

开源已成为中国 AI 基础设施（AI Infra, AI Infrastructure）制度化建设的关键抓手，京沪双方案揭示了技术与治理的分工与张力。

北京与上海开源方案的观察视角

以北京与上海同日发布的两份开源体系建设方案为切口，结合中国过往基金会实践与国际开源治理经验，讨论 AI Infra 进入制度化开源阶段后的真实机会、结构性约束与潜在风险。

图 1: 北京与上海开源方案相继推出开源生态体系建设方案

为什么要把北京和上海放在一起看

我并不常因为一份地方政策文件专门写文章。在圣诞节期间，北京和上海的经济和信息化局分别发布了各自的开源生态体系建设方案：

但这一次，北京与上海在同一天分别发布了各自的开源体系建设方案，这个时间点与组合方式，本身就释放出一个值得认真对待的信号：中国正在尝试以更系统、更制度化的方式推进开源，尤其是与 AI 基础设施（AI Infra, AI Infrastructure）相关的开源能力。

如果只单独看北京方案，很容易把它理解为一次地方性的产业政策升级；如果把北京与上海两份方案放在一起看，则更像是在勾勒一种分工明确的“双中心结构”。

这已经不是“要不要发展开源”的问题，而是：

在 AI 时代，开源将以什么样的制度形态、工程路径和治理方式存在。

开源被当作“产业基础设施工程”来做

无论是北京还是上海，两份方案都体现出一个非常一致的判断：

开源不再被视为社区自发行为，而是被当作一种需要系统建设的产业基础设施能力。

这在 AI Infra 领域尤为明显。

从算力调度、模型评测、工具链，到数据要素、许可证合规、供应链安全，这些过去往往隐藏在“工程细节”里的问题，第一次被系统性地纳入政策语言。这至少说明，决策层已经意识到：

AI 竞争不只发生在模型参数规模上
更发生在工具链、基础设施、评测体系与工程化能力上
而这些能力，天然更适合通过开源来构建公共底座

在这一点上，北京与上海是高度一致的。

Infra 与 Platform 的两种开源路径

当视角进一步拉近，两份方案的差异就变得非常清晰。

北京：偏向 AI Infra 的“底座型”开源路径

北京方案的关键词，集中在：

异构算力调度
模型评测工具链
数据要素与数据治理
RISC-V 软硬件协同
SBOM、许可证兼容性、开源合规
供应链安全与产业韧性

这是一种非常典型的“把 AI 当作基础设施问题”的视角。

它关心的不是项目数量或社区规模，而是：

能否形成可复用的工程能力
能否被产业与政府长期采信
能否在安全、合规、治理层面站得住

某种程度上，北京更像是在回答一个问题：

开源如何成为一种“可治理、可审计、可规模化落地”的公共能力？

上海：偏向 AI Platform 的“规模化与国际化”路径

相比之下，上海方案的重心明显不同：

打造人工智能国际开源社区
覆盖“开发—训练—测试—托管—运营”的全链条平台
海外站、多语种、海外活动
算力券、模型券等资源联动
“开源平台首发 / 全球同步首发”的“双首发”机制
明确的社区、企业与开发者规模目标

上海更关心的是：

开源如何形成规模效应
如何支撑商业化企业成长
如何在全球范围内被看见、被采用

这是一种“把开源当作全球化数字产品与平台能力”的路径。

合在一起看：一个完整但张力很大的结构

将北京与上海放在一起，反而能拼出一幅更完整的图景：

北京负责“让开源站得住”，上海负责“让开源走出去”。

从结构上看，这是一次相当清晰的分工：

北京偏向制度、治理与基础能力
上海偏向社区、商业化与国际传播

这两种路径并不冲突，甚至在理论上是互补的。真正的问题在于：它们能否在实践中形成正反馈，而不是各自为政。

对“机构化、平台化开源”的谨慎态度

正因为这两份方案都写得足够“系统”，我反而更加谨慎。

原因并不复杂：中国并不是第一次尝试用基金会、协会或平台的方式来推动开源。

过去十多年里，我们已经多次看到类似路径反复出现，也反复暴露出一些结构性问题：

中立性与多方信任的建立难度极高
展示性指标（数量、活动、授牌）与生态强度之间存在巨大鸿沟
商业化与长期维护机制难以跑通

这些问题，并不会因为方案写得更完整就自动消失。

京沪双方案下的四个风险点

如果要“听其言，也要观其行”，我会重点关注以下四个风险：

指标是否会绑架工程现实

当“国际影响力项目”“明星项目”“首发项目”成为硬指标，是否会诱导包装、迁移与短期造势，而非真正解决工程难题？

是否滑向平台中心主义

AI Infra 的长期格局，更接近协议、标准与互操作优先的模式。如果最终演化为“少数平台集中资源与话语权”，短期可能高效，长期却会抑制外部参与与国际协作。

国际化是否被低估为“运营问题”

真正的国际协作，从来不只是语言、站点或活动问题，还涉及治理结构、合规边界与供应链信任。

应用示范是否变成一次性项目

如果“首方案”“算力券”只是采购式打法，而没有形成持续迭代与社区反哺机制，对生态的长期增益会非常有限。

三年后，什么才是 AI Infra 开源的“硬结果”

如果三年后复盘这轮制度化开源是否成功，我更愿意看这三类结果：

是否出现事实标准与互操作生态，包括调度接口、评测基准、Agent 工具调用协议、可观测语义等。
是否将合规与供应链安全做成公共能力，SBOM、许可证兼容、漏洞监测，是否真正产品化、服务化。
是否跑通可持续维护的商业机制，让核心维护者可以长期留下，而不是靠情怀与补贴支撑。

如果用北极星指标来衡量这个方案是否成功，我会认为是出现了若干扎根于本土服务于全球的优秀开源商业化公司。

总结

京沪两地的开源生态方案，标志着中国 AI Infra 开源进入制度化、工程化的新阶段。未来三年，真正的成果不在于指标完成，而在于能否形成可持续的工程能力、事实标准与维护机制。只有持续参与与实践，才能推动开源成为 AI 基础设施的公共底座。

参考文献

从 2025 年起，软件工程不再以代码为中心，而是以运行时与成本为中心

Jimmy Song — Wed, 24 Dec 2025 14:59:11 +0000

2025 年，软件工程的核心不再只是代码本身，而是运行时的可控性与成本治理，这一转变正重塑行业的底层逻辑。

回顾 2025 年，我越来越清晰地意识到：这一年并不是“代码不重要了”，而是 工程的价值坐标发生了整体迁移。如果说过去十多年软件工程围绕的是代码质量、架构演进与交付效率，那么从 2025 年起，决定系统成败的重心正在转向——运行时是否可控，以及成本是否可治理。

这并非一句口号，而是我在这一年里反复被现实验证过的结论。

我的 2025：从“平台工程”到“运行时问题”

在年度回顾中，我记录了一个明显变化：我花在“如何写好一个系统”的时间在减少，而花在“如何把系统跑稳、跑久、跑得起”的时间在增加。

这种关注点的迁移，是云原生十年积累后的自然延伸。

下面这张时间线图展示了我近几年关注点的变化：

图 1: 我的关注点迁移时间线

我的关注点从云原生平台工程，逐步转向 LLM 应用工程，再到 AI 基础设施，最终聚焦于 Agentic Runtime 的运行时治理与成本控制。

当 AI 工作负载真正进入业务场景后，工程师面临的核心问题也随之转变：

推理、训练、评测是否在抢同一池算力
GPU 利用率是否长期低于预期
成本是否随着并发线性失控
系统是否具备失败隔离与回放能力

这些问题，已经超出了代码层面的范畴。

行业共识正在形成：AI 改写的是工程重心

2025 年，行业逐渐形成共识：AI 正在重写软件工程。但真正的变化，并不发生在 IDE 或补全速度上，而是体现在 工程复杂性的迁移。

过去，复杂性主要集中在代码与接口，问题主要靠抽象、重构与测试解决。

而现在，复杂性转移到了运行时、资源与成本层面，问题必须通过调度、隔离、观测与治理来应对。

这也是为什么同样的 AI 工具：

对初级工程师是“加速器”
对资深工程师却是“放大镜”

AI 工具会放大你是否真正理解系统在生产环境中如何运行。

为什么“成本”成为第一性原理

在传统云原生系统中，CPU 利用率低往往只是效率问题；而在 AI 系统中，GPU 利用率低往往是现金流问题。

2025 年，我反复遇到如下场景：

资源“看起来不够”，但利用率却并不高
为了解决排队问题不断扩容，反而推高单位成本
系统缺乏明确的预算与配额边界，最终只能靠限流止血

这些现象的根本原因，并非模型选择，而是 缺乏一套面向 AI 工作负载的运行时与成本控制面。

下方流程图直观展示了 GPU 资源与成本压力的循环关系：

图 2: AI 系统中的 GPU 资源与成本循环

AI 系统中，GPU 资源供给有限导致排队等待，进而造成吞吐下降。为解决这个问题往往盲目扩容，反而推高单位成本并带来预算压力，最终迫使系统采用更精细的调度与治理策略。

工程问题，最终会以成本的形式暴露出来。

Agent 兴起，但真正的难题在运行时

2025 年，Agent（智能体，Agent, Intelligent Agent）成为显学；2026 年，它将进入“能不能跑”的阶段。

Agent 的挑战从来不在“是否聪明”，而在于：

是否有清晰的权限与数据边界
是否运行在可隔离的执行环境中
是否可以被观测、评估与回放
是否受到明确的成本与预算约束

这些能力，构成了我在这一年里不断尝试梳理的 Agentic Runtime（智能体运行时，Agentic Runtime） 轮廓。

下方流程图展示了 Agentic Runtime 的核心能力层次：

图 3: Agentic Runtime 的能力分层

Agentic Runtime 从底层的 Agent 与工作流开始，向上通过编排与工具协议连接，由运行时管理状态、记忆与评估，提供安全执行环境（Sandbox 与策略），最终在顶层实现资源与成本控制面，统一管理 GPU、配额与计费。

没有运行时，Agent 只是 Demo；没有成本约束，Agent 只是风险放大器。

2026 展望：工程的“地基”重新变得重要

展望 2026，我保持谨慎但乐观。

我不认为未来属于“最会写 Prompt 的人”，而更可能属于：

理解运行时边界的人
能把算力当作受限资源治理的人
能把 AI 系统当作长期运行系统来设计的人

从 2025 年起，软件工程不再以代码为中心，而是以 运行时与成本为中心。这不是工程的退化，而是一次回归：回到对系统整体负责，对真实世界约束负责。

对我个人而言，这既是年度总结，也是接下来几年持续投入的方向。

总结

2025 年，软件工程的重心已从代码本身转向运行时与成本治理。AI 与 Agent 的普及并未削弱工程价值，而是将复杂性推向了更高层次。未来，理解运行时、治理算力与成本，将成为工程师新的核心竞争力。希望这份年度回顾，能为同行带来一些启发与思考。

从云原生到 AI 原生：Kubernetes 如何承载下一代 AI Agent

Jimmy Song — Wed, 24 Dec 2025 12:10:58 +0000

作为一个长期在云原生领域工作的实践者，我越来越确信一件事：AI Agent 不只是一个应用形态的变化，而是基础设施范式的迁移。

随着人工智能从 Demo、Copilot 逐步走向真正承担任务与责任的系统，AI Agent（智能体） 正在成为企业 IT 架构中的新执行单元。它们不仅“会思考”，还会行动：能够调用工具、访问系统、协作完成目标。

那么，问题随之而来：

这样的系统，应该运行在什么样的基础设施之上？

在我看来，Kubernetes 依然是一个应对大规模场景的好选择，但前提是：我们必须用 AI 原生（AI-Native）的方式，重新理解 Kubernetes。

生产级 AI Agent 面临的云原生挑战

在真实生产环境中，AI Agent 暴露出与传统微服务完全不同的基础设施需求。Agent 并不是“另一个 HTTP 服务”，它们具有三个显著特征：

行为是非确定性的（由模型推理驱动）
执行路径是动态的（工具调用不可预先穷举）
决策需要被审计、约束和复盘

如果直接套用现有云原生基础设施，会迅速遇到瓶颈。

下面的表格总结了 AI Agent 在云原生环境下的主要挑战与风险：

挑战类别	Agent 的真实需求	如果缺失会发生什么
策略与安全	能基于上下文、身份、任务动态控制工具与数据访问	Agent 拥有“超级用户”权限，风险不可控
可观测性	不只看到“是否成功”，还要看到为什么这样决策	难以调试、难以复盘、难以问责
治理与一致性	平台级护栏（Guardrails）强制执行组织策略	每个 Agent 都可能成为“影子 AI”

表 3: AI Agent 在云原生环境下的挑战与风险

这些问题，本质上都指向一个结论：

AI Agent 需要被视为 Kubernetes 的一等公民，而不是普通工作负载。

核心架构：让 Agent 成为 Kubernetes 的原生对象

回顾云原生（Cloud Native）技术的演进路径，我们已经走过类似的阶段：

物理机 → 虚拟机
虚拟机 → 容器
容器 → 微服务
微服务 → 声明式、可治理的平台

AI Agent 只是下一步。

一个面向生产环境的 AI Agent 架构，至少需要三层能力：

Agent 编排层：声明式定义 Agent
工具服务化层（MCP Services）：把能力变成可治理的服务
AI 原生数据平面 / 网关：统一策略、安全与协议

Agent 编排层：声明式管理 Agent

Agent 不应再是某个 SDK 里的“运行时对象”，而应像 Pod、Deployment 一样被管理。

关键思想如下：

Agents 即 Kubernetes 资源

Agent 使用 CRD（CustomResourceDefinition, 自定义资源定义） 进行定义
可通过 kubectl 或 GitOps 管理生命周期
Agent 的模型、工具、策略全部显式声明

一个典型 Agent 定义包含以下内容：

Agent 逻辑（推理循环）
模型配置（指定使用哪个大语言模型）
可调用工具集

这与我们当年把“应用”拆解为 Deployment、Service、ConfigMap 的过程高度一致。

工具服务化层：MCP Services 是必然选择

在 Agent 架构中，工具（Tools） 是真正产生“行动”的地方。

早期 MCP 工具往往是：

本地进程
与单个 Agent 紧耦合
缺乏版本、权限、审计能力

这在企业环境中难以持续。

MCP 服务化的本质价值

工具 → 远程服务
服务 → Kubernetes 原生工作负载
能力 → 可复用、可治理、可审计

这一步，和当年把脚本变成微服务的过程本质类似。

AI 原生网关：Agent 世界的“控制平面入口”

当 Agent 数量增加、工具和模型多样化之后，连接本身就成为系统风险。

传统 API Gateway 并不理解以下场景：

MCP
Agent-to-Agent（A2A, Agent 间通信）
模型调用上下文

因此需要一个AI 原生网关，专门处理中介与治理问题。

它至少要理解三类流量：

A2T：Agent → Tool
A2L：Agent → LLM
A2A：Agent ↔ Agent

并在这些路径上统一执行：

身份与授权
策略与护栏
审计与限流

架构实现概览

下方的架构图展示了 AI 原生系统在 Kubernetes 上的核心分层与流量路径：

图 3: AI 原生架构分层与流量路径

总结

AI Agent 并没有否定云原生，相反：

AI Agent 是云原生在智能时代的自然延伸。

声明式 → Agent 定义
Service → MCP Services
Service Mesh → AI 原生网关

如果说 Kubernetes 是“自动化工厂”，那么 AI Agent 就是真正开始动手干活的智能工人。

而 AI 原生网关，正是那套为智能工人量身定制的安全与治理体系。

这不是一个可选架构，而是AI 走向生产的必经之路。

AI 原生全景图：一站式 AI 项目导航与评分体系

Jimmy Song — Tue, 23 Dec 2025 08:32:52 +0000

AI 原生全景图不仅是一个项目导航，更是推动 AI 开源生态透明化、可量化的创新尝试。

注：本文面向普通读者，重点介绍平台功能与使用场景；如果你想查看评分的技术细节与计算公式，请参阅： AI 项目评分与收录标准。

项目背景与定位

AI 原生全景图（AI Native Landscape）旨在为开发者、研究者和企业用户提供一站式的 AI 开源项目导航与评估平台。随着大语言模型（LLM）、多模态模型（Multimodal Model）等 AI 技术的快速发展，开源社区涌现出大量创新项目，但信息分散、质量参差不齐，给用户带来筛选和决策难题。

图 1: AI 原生全景图

AI 原生全景图通过系统化收录主流 AI 开源项目，截止本文发稿时，已收录 851 个开源项目。该全景图结合多维度评分体系，帮助用户高效发现、比较和选择最适合自身需求的 AI 工具与框架。平台不仅关注模型本身，还涵盖数据集、推理引擎、评测工具、应用框架等全链路生态，致力于推动 AI 开源生态的透明化、可量化和可持续发展。

主要界面与功能亮点

平台首页以全景图与列表双视图结合的方式展示项目分布，支持分类筛选、关键词搜索与标签导航，帮助用户快速定位目标项目。

图 2: 开源项目详情页面

对普通读者而言，主要体验点包括：

卡片视图：以一句话概览、星级和总体分数帮助快速浏览与对比。
健康卡：在项目页面或侧边栏显示综合健康度与关键维度（活跃度、社区、影响力、持续性），并标注最近一次更新，方便判断项目是否还在维护。
详情页：提供更多背景信息、项目链接与应用场景，帮助你评估是否适配你的需求。
智能徽章：在卡片上直观展示例如“活跃”、“新项目”、“高人气”、“已归档”等标签，帮助你快速捕捉项目的显著特征。

如果你对徽章判定或分数的具体规则感兴趣，详细说明已放在评分规则页面。

评分与排名机制

平台使用多维度的评分来反映项目的整体健康与流行度，主要维度包括：活跃度（Activity）、社区（Community）、质量（Quality）、持续性（Sustainability），以及综合得出的 健康度（Health）。这些分数帮助你快速判断项目是否适合用于生产或试验。

数据来源与更新机制

平台的数据主要来源于 GitHub、项目清单、官方文档与社区推荐。我们会定期自动同步并更新指标，以保证界面上显示的“最近更新”与评分能够反映项目当前的维护状态。长期未更新或判定为“不活跃”的项目会被移到归档页，归档项目仍可检索并保留历史评分，但不会出现在活跃榜单的默认视图中，以便读者更容易关注仍在维护与活跃的项目。

对于普通读者，重要的是：

页面会显示关键指标与“最近更新”时间，帮助你快速判断项目是否仍在维护；
AI 原生全景图持续对评分模型进行迭代以改善结果的公平性与区分度；

如何参与与校正数据

如果你希望让某个项目被收录或更新数据，可以：

提交 AI 开源项目收录申请
在项目仓库中保持 README、License、文档等信息完善，便于我们抓取与判断；
如需更快速的同步或遇到数据问题，请在项目 Issue 中联系维护者或在站点讨论区提出请求。

典型应用场景或用户反馈

AI 原生全景图已被广泛应用于 AI 开发者选型、企业技术调研、学术研究等多种场景。例如：

开发者可通过平台快速筛选适合自身需求的模型或工具，节省大量调研时间。
企业技术团队利用评分榜单进行竞品分析和技术路线规划。
教育和研究机构参考全景图了解 AI 开源生态发展趋势，辅助课程设计与课题选题。

部分用户反馈平台“信息全面、结构清晰、评分公正”，极大提升了 AI 项目选型与学习效率。社区建议也在持续推动平台功能与内容优化。

总结

AI 原生全景图以系统化、可量化的方式梳理 AI 开源生态：后端 Worker 负责可靠的数据采集与评分计算（支持回填与迁移），前端组件负责快速渲染与可视化（含智能徽章、健康卡与指标说明）。

如果你希望深入了解评分细节或参与改进：

欢迎社区参与测评、回填历史数据与完善评分规则，共同推动 AI 开源生态更加透明与可持续。

AI 2026：基础设施、Agent 与下一次云原生变革

Jimmy Song — Fri, 19 Dec 2025 03:54:28 +0000

2026 年 AI 的真正转折点不是自治，而是基础设施的成熟——Agentic Runtime、GPU 效率和组织设计将决定胜负。

引言：2026 年不是 AI 时刻，而是基础设施时刻

回顾过去十五年，软件领域的每一次重大变革都遵循着类似的轨迹。微服务的普及并非因为大家热爱分布式系统，而是因为单体架构遇到了组织极限。Kubernetes 的成功也不是因为容器新颖，而是基础设施终于契合了团队的运作方式。云原生从来不是关于 YAML，而是关于大规模可运维性。

AI 如今正站在类似的拐点上。

2026 年的核心问题，不是模型是否会变得更自治。这个争论忽略了本质。真正的问题是，AI 能否在真实系统中变得可运维、可治理、经济可持续。

当下，大多数组织受限的不是智能本身，而是基础设施：GPU 利用率低下、推理成本飙升、Agent 演示脆弱，以及把 AI 当作功能而非运行时的惯性。AI 的下一个阶段，将由基础设施的成熟度和其承载责任的能力决定，而不是模型的突破。

从自动化到能力倍增——熟悉的云原生模式

回顾早期云计算的普及，主流叙事是成本降低：服务器更少、资本支出更低、弹性扩缩容。然而，真正的红利出现在后期——团队意识到云带来了全新的运营模式。

AI 正在重演这一模式。

下图展示了从自动化到能力倍增的转变。

图 1: 从自动化到能力倍增

AI 的第一波浪潮关注于替代劳动力。第二波则将 AI 重新定义为能力倍增器：同样的团队，能观察更多信号，覆盖更广领域，更早采取行动。

这与监控、追踪和 SRE 实践的演进如出一辙。它们并未减少工程师数量，而是让持续观测成为可能，取代了偶尔抽样。

前瞻性的 AI 系统——监控每一次交互、日志和信号——只有在底层基础设施足够强大时才可行。这暴露了一个关键约束：AI 能力的扩展速度远超基础设施。

如果没有高效的调度、隔离和利用率提升，能力倍增只会带来成本倍增。

Agent 正在变成分布式系统，无论你是否承认

业界常把 Agent 当作产品讨论。实际上，Agent 正在演化为分布式系统。

下图突出展示了这一架构转变。

图 2: Agent 正在变成分布式系统

单体 Agent 设计类似早期的单体应用：演示效果惊艳，但行为脆弱，故障模式不透明。随着任务复杂度提升，系统必须将工作拆解为规划、执行、验证和复核——协作变得不可避免。

这不仅是理念的变化，更是架构的转型。

多 Agent 系统带来了微服务时代熟悉的挑战：

协调与编排
资源争用
故障隔离
可观测性与回滚
阶段间的确定性产物

将其称为“多 Agent 协作”其实有误导性。真正发生的是工作负载的拆解与控制面的出现。Agent 正在从工具转变为争夺有限资源的工作负载。

认识到这一点，就能明白 Agent 的进步为何离不开基础设施的成熟。

AI 基础设施是模型与组织之间缺失的一层

云原生教会我们，只有存在控制面，抽象才能扩展。

而当前，AI 还缺乏成熟的控制面。

下图展示了模型与组织之间的基础设施缺口。

图 3: AI 基础设施是模型与组织之间缺失的一层

模型本身很强大，但其外围的基础设施——调度、隔离、配额、成本归因、可观测性——尤其是在 GPU 层面，依然非常原始。

GPU 昂贵、稀缺且常常利用率低。在许多环境下，利用率仍低于 30–40%，而推理成本却持续上升。训练流水线长期占用资源，推理负载又会突发激增，组织不得不在浪费与抑制创新之间做选择。

这不是模型问题，本质上是 AI 基础设施问题。

AI 的下一个阶段，取决于我们能否像管理 CPU 一样管理 GPU：

细粒度分配
公平共享
抢占与优先级
明确的归属与计费

在 GPU 利用率成为设计首要目标之前，AI 系统都将处于经济脆弱状态。

行业专家的重要性源于基础设施的“暴露效应”

随着模型在通用推理能力上趋于平台期，差异化转向了其他方向。

下图展示了基础设施如何“暴露”行业专家的价值。

图 4: 行业专家的重要性源于基础设施的“暴露效应”

在云原生系统中，竞争优势最终从框架转向了运维卓越：更优的运行手册、事件响应和成本控制。AI 也在走类似的路径。

高价值的 AI 系统必须在金融、医疗、制造、基础设施运维等高密度、规则繁多的领域运行。此时，关键不再是抽象智能，而是能否编码行业约束、异常和故障模式。

在这里，行业专家成为核心——不是作为提示工程师，而是系统塑造者。他们决定 Agent 的权限、人类介入点和错误隔离策略。

基础设施决定了这些专业知识能否被安全地“产品化”。

仿真正在成为 AI 的新“预发环境”

云原生运维的一个重要经验：分布式系统不能在生产环境中测试。

AI 系统同样如此——它们会行动、规划并修改状态。

下图展示了仿真作为 AI 新“预发环境”的作用。

图 5: 仿真正在成为 AI 的新“预发环境”

直接在真实环境中训练和验证 Agent 不可持续。未来属于仿真优先的 AI 开发——即在沙箱环境中模拟真实系统、负载和约束。

这种方式类似于预发集群、混沌工程和压力测试，但面向决策系统。评估标准也从静态基准转向行为指标：人工干预率、回滚频率和成本影响。

能构建这些环境的组织，将更快更安全地推进。反之，则会被保守部署和有限自治所束缚。

总结

技术革命的成功，从来不只是新奇，而在于基础设施、工具链与组织模式的协同。

AI 正接近这个关键时刻。

2026 年的领先者，将是那些：

把 AI 视为运行时，而非功能
优化资源效率，尤其是 GPU
认识到 Agent 本质是分布式系统
围绕持续学习系统重塑组织
在自治之前，优先投资基础设施

AI 已不再只是模型问题，而是基础设施挑战。下一个阶段的胜负，将不在实验室，而在生产系统中决出。

在 COSCon'25 现场，我看到的中国开源真实状态

Jimmy Song — Thu, 18 Dec 2025 06:03:46 +0000

今年 12 月初，我在北京参加了 COSCon'25 中国开源年会。虽然我从事开源领域多年，但这还是我第一次参加开源社主办的开源年会，而且还是以分论坛出品人的身份参与。以前我总以为这样的会议太过高屋建瓴、曲高和寡，但是实际参与后，还是有些收获的。

需要说明的是，这篇文章不是大会总结，也不是官方回顾。关于大会规模、参与人数、论坛数量等信息，官方已经整理得很完整，这里不再重复，感兴趣的可以直接参考开源社发布的文章： COSCon'25 第十届中国开源年会在北京圆满落幕，万字长文带你重温高光时刻！

图 1: 第十届 COSCon 现场

我更想写的是：站在现场、站在工程一线、站在组织者而不是观众的位置，我看到的中国开源正在发生的变化。

这届 COSCon，不再试图“证明开源很重要”

一个很直观的感受是： 几乎没有人再花时间论证“为什么要做开源”。

早些年的大会上，常见的叙事是：

开源是否安全
开源能不能商业化
中国能不能做自己的开源项目

而在 COSCon'25，这些问题基本已经被默认为“背景条件”。讨论更多集中在已经在做开源的人，接下来怎么走。

这并不意味着问题消失了，而是说明一件事：

开源在中国工程圈，已经不再是“理念层面的选择”，而是现实中的工作方式。

AI 成为背景噪音，而不是主角

本届大会的主题是 Open Source × Open Intelligence，但有意思的是，AI 并没有以“主角姿态”出现。

它更像一种背景噪音—— 几乎所有话题都绕不开 AI，但又没有谁在单独“讲 AI”。

你会在这些地方反复看到它：

云原生调度，讨论的是 GPU / NPU / 异构资源
存储与数据，讨论的是训练与推理的数据路径
Serverless，讨论的是 LLM 冷启动与弹性
可观测性，讨论的是系统复杂度失控之后怎么办

AI 并没有被当成“风口”，而是被当成新的工作负载现实。这是一个非常重要、但不容易被宣传稿捕捉到的变化。

作为云原生分论坛出品人的真实感受

我参与出品了本届大会的云原生开源分论坛。这个角色让我看到一些和“听众视角”完全不同的细节。

第一，议题明显向“工程问题”收敛

讲 Kubernetes 概念的几乎没有；讲“某某架构思想”的也很少。

更多是：

你在什么规模下踩了什么坑
你为什么选了这个方案而不是另一个
哪些问题现在还解决不了

很多分享并不“好听”，但非常真实。

第二，高校与产业的边界在变薄

这一点今年尤为明显。

一些来自高校和研究机构的分享，已经不再是“论文视角”，而是直接面对工业系统里的核心问题，比如：

Serverless LLM 的冷启动
RDMA 在推理路径中的真实价值
Prefill / Decode 分离到底是不是工程上可行

这些内容不一定马上能落地，但已经开始与工程问题正面碰撞，而不是各说各话。

第三，开源不再只谈代码

在不少讨论中，“治理”“维护成本”“社区协作方式”被频繁提及。

这其实是一个信号：当项目真正被用起来，代码反而不再是最难的部分。

主论坛：更多问题，而不是答案

如果用一句话形容主论坛，我会说： 它在反复提出问题，但并不急着给结论。

比如：

AI 时代的开源，边界是否发生了变化？
模型、数据、芯片是否应该进入开源核心？
开发者的角色是否正在被重新定义？

这些问题没有标准答案，但被不断抛出，本身就说明它们已经成为共识层面的疑问，而不只是少数人的思考。

展区与分论坛，反而更接近真实生态

相比主论坛，我个人更关注分论坛和展区。

在那里你会看到：

很多项目并不再强调“我要替代谁”
更多在讨论“我能和谁一起工作”
有不少社区已经在认真谈长期维护，而不是发布版本

这可能不性感，但很重要。

一点个人判断

如果一定要给 COSCon'25 下一个判断，我会说：

中国开源，正在从“能不能做”，转向“能不能长期做下去”。

这是一个更难、也更现实的阶段。

这届 COSCon 并没有试图制造某种宏大叙事，它更像一次阶段性的“状态暴露”：问题更多了，参与者更复杂了，但讨论也更贴近真实世界了。

开源并不依赖一届大会向前走，但这样的现场，能让人更清楚地知道： 我们现在到底站在什么位置。

解析 Goose：为什么它会进入 AAIF，以及这对 Agentic Runtime 意味着什么

Jimmy Song — Fri, 12 Dec 2025 08:16:48 +0000

在这一轮 Agent 浪潮里，Goose 并不是一个“第一眼就让人兴奋”的项目。

图 1: Goose App UI

它没有炫技式的 Demo，也没有铺天盖地的多模态展示，更不像一个面向 C 端用户的 AI 产品。但就是这样一个看起来“朴素”的项目，却成为了 Agentic AI Foundation（AAIF）的首批捐赠项目之一，与 Anthropic 的 MCP、OpenAI 的 AGENTS.md 并列。

这件事本身，就很值得拆一拆。

这篇文章并不是想证明 Goose 有多强，而是想回答三个更现实的问题：

Goose 到底解决了什么容易被忽略、但长期关键的问题？
为什么是 Goose，而不是其他 Agent 框架，进入了 AAIF？
这件事对我所关注的 Agentic Runtime 和 AI-Native 基础设施意味着什么？

Goose 的真实定位：它不是 IDE，也不是聊天机器人

如果只看表面功能，Goose 很容易被误解成两类东西之一：

一个“多模型 AI 桌面客户端”
或者一个“能跑命令的智能编程助手”

但在 Block 内部，它从一开始就不是按“工具”来设计的。

Goose 的诞生背景，和 Block 自身的工程环境关系很大。

Block（原 Square）是一家典型的工程驱动型公司：系统复杂、自动化需求高、内部工具多，而且真实生产环境中的执行成本非常高。在近两年的 AI 转型中，Block 并没有把重点放在“选哪个模型”或“引入哪个 AI 工具”上，而是直接盯住了工程执行层本身。

Goose 正是在这样的背景下诞生的。

它的目标不是“让人写得更快”，而是让模型能够稳定、可控地动手做事：跑测试、改代码、驱动 UI、调用内部系统，并且能在真实工程环境中长期运行。

如果用一句话概括：

Goose 更像一个可执行的 Agent Runtime，而不是一个以对话为中心的产品。

Block 做 AI 转型，起点不是工具，而是组织结构

理解 Goose，还绕不开 Block 的一次组织层面的转向。

在 Block CTO 的访谈中，有一个信号非常明确：AI 转型的起点，并不是买工具或堆模型，而是组织结构本身。

Block 从偏业务线的 GM 制，转向更偏工程职能的 Functional 制，让工程和设计重新成为公司的核心调度单元。这本质上是一次 Conway’s Law 的主动应对。

如果组织结构本身不允许技术能力被统一调度，那么 Agent 最终只会停留在“个人助手”或“工程玩具”的层面。

从这个角度看，Goose 并不仅仅是一个工具，而是一种文化信号：

每个员工，都可以用 AI 去构建和执行真实的系统行为。

这也解释了一个很多人忽略的事实： Goose 并没有被包装成 SaaS，也没有急着商业化，而是被直接开源，并迅速标准化。

因为它在 Block 内部承担的角色，更接近“执行模型的操作系统”，而不是一个可以单独售卖的产品。

为什么 Goose 能进入 AAIF？不是因为“技术最强”

这是外界最困惑的一点。

如果只看炫技能力、模型支持或社区热度，Goose 并不占优势。但 AAIF 选择它，关注的并不是“能力上限”，而是位置是否正确。

从 AAIF 首批项目的组合来看，其实已经形成了一条很清晰的链路：

MCP（Anthropic）：定义模型如何安全、标准化地调用工具
AGENTS.md（OpenAI）：定义 Agent 在代码仓库中的行为约定
Goose（Block）：一个真实可运行的、开源的 Agent 执行框架

Goose 的角色并不是制定新协议，而是作为这些协议的落地承载体和参考实现。

它证明了一件事：

MCP 不是纸面标准
Agent 不是研究概念
在真实企业环境中，它们是可以跑起来的

从这个角度看，Goose 的“普通”，反而是一种优势。

它没有绑定 Block 的商业护城河，也没有不可替代的私有 API；它可以被 fork、被替换、被审计，足够“无聊”，也足够中立。

而这，正是公共基础设施最重要的特质。

Goose 的意义，不在今天，而在 2–3 年后

如果站在更长时间尺度上看，Goose 的价值会更清楚。

我们正在经历的，很像容器早期的阶段：现在的 Agent 项目，大多是 Demo、IDE 插件、Workflow 封装，而真正缺失的是一个可持续运行、可调度、可观测的执行层。

Goose 已经踩在这个方向上了。

Block 衡量 Goose 成功与否的指标也很直接：

每周节省了多少人类工时
非技术团队减少了多少对工程团队的依赖

这背后对应的是一个我越来越确信的判断：

企业真正需要的，不是“更聪明的模型”，而是“更便宜的执行”。

Agent 的长期价值，并不在生成质量，而在执行替代率。

AAIF 是一次基础设施层面的共识尝试

就像 CNCF 之于云原生一样，AAIF 并不保证一定成功。

但它至少标志着一个变化： Agent 不再只是应用层的创新，而开始进入基础设施层的协同阶段。

Goose 作为其中的参考实现，很可能会长期存在于这个坐标系中——哪怕未来它被替代、被重写、被演化。

写在最后

如果你把 Goose 当成一个“产品”，它确实不耀眼。

但如果把它放进 Agentic AI 的长期演化路径中，它的意义就会变得清晰：

它不是终点，但它是一个必要的中间态。

对我而言，Goose 的出现，反而进一步确认了一件事：

Agentic Runtime 不是一个概念问题，而是一个工程问题，也是一个组织问题。

而这，正是接下来几年最值得投入精力的方向之一。

ARK：多智能体系统终于开始进入工程师的世界

Jimmy Song — Thu, 11 Dec 2025 13:19:46 +0000

云原生与 AI 的深度融合，ARK 平台为多智能体系统工程化落地提供了新范式。

引言

AI Agent（智能体）正在从“单 Agent Demo”阶段迈向“规模化运行”。真正的挑战并不在于模型本身，而在于运行时的工程问题：模型管理、工具调用、状态维护、弹性伸缩、团队协作、可观测性、部署升级等。这些问题是传统 Agent 库难以解决的。

ARK（Agentic Runtime for Kubernetes） 提供了一套可运行、可观测、可治理、可持续交付的多智能体操作系统。它不是一个 Python 库，而是完整的运行时平台。

图 15: ARK Dashboard

注意：本文中提到的 ARK 指的是麦肯锡开源的 ARK Agent Runtime for Kubernetes。

本文将以工程师视角，重新梳理 ARK 的核心能力，解答如下问题：

ARK 到底解决了哪些工程难题？
为什么它值得云原生领域重点关注？
它与 LangChain、CrewAI 等框架有何本质差异？
对 Agentic Runtime 生态有哪些启示？

ARK 的基础架构：将 Agent 作为 Kubernetes 原生工作负载

ARK 的核心思想是：Agent 不是脚本，而是一个可调度、可治理、可观测的 Kubernetes 工作负载（Workload）。

下面这张架构图展示了 ARK 的底层结构。

图 16: ARK 整体架构

这张图体现了 ARK 的关键设计：

CRD 负责声明需求（Agent、Model、Team、Tool、Memory 等）
Controller 负责将声明转化为实际的 Pod / Service
API 提供统一通信入口与 Team 编排能力
Memory 支持 Agent 的长期状态管理
MCP Server 让外部系统成为工具
Dashboard 提供可视化管理与观测能力

ARK 采用了典型的云原生 Operator 模式，并将其应用于多智能体系统。

CRD：ARK 的“抽象层”

与传统 Agent 框架“代码即逻辑”的方式不同，ARK 通过 CRD（自定义资源定义，Custom Resource Definition）来抽象 Agent 应用的组成部分。

ARK 的 CRD 主要包括以下类型：

Model
Agent
Team
Tool
Memory
Evaluation

这些 CRD 对应了 Agent 系统的所有关键部件。

下图展示了 CRD 的结构关系：

图 17: CRD 结构（简化版）

通过 CRD，ARK 实现了如下工程特性：

所有资源可 GitOps 化，支持声明式管理
变更可审计、可回滚、可持续交付
模型、工具、Agent 的演进无需改动业务代码

这正是 ARK 面向工程体系的关键基因。

Agent 执行链路：从 Query 到工具调用

图 18: 在 ARK Dashboard 中查看 Query 详情

在 ARK 中，一个 Agent 接收到 Query（请求）后的完整执行链路如下：

图 19: Agent 执行流程

该链路具备以下特性：

Memory（记忆模块）在执行链路中天然参与，无需代码特化
大语言模型（LLM）和工具调用由运行时统一治理
Agent 可以长期驻留于 Pod，不是一次性进程

这使得 ARK 更像一个“Agent 微服务平台”。

下面是一个请求的响应事例：

多 Agent 的真正价值：Team Orchestration

ARK 的 Team CRD 允许将多个 Agent 编织成一个高层次的“系统”，实现多智能体协作。

下图展示了多 Agent 团队的协作模式：

图 20: 多 Agent 团队协作

Team 的工程价值体现在：

让“专家协作”变得声明式、可配置
策略灵活（如轮询、角色分配、路由等）
A2A Gateway 负责消息传递
Team 本身具备可观测性（每轮协作均有日志）

对于企业而言，这意味着“Agent 组织结构”可以标准化、可重放、可调优。

ARK 与其它框架的本质差异

许多工程师初见 ARK 时会疑惑：

“它是不是只是把 LangChain 或 CrewAI 用 Kubernetes 包装了一下？”

实际上，二者有本质区别。下图对比了 ARK 与主流 Agent 框架的结构差异：

图 21: ARK vs LangChain / AutoGPT / CrewAI

下表进一步总结了两者的关键差异：

维度	传统 Agent 库	ARK
核心模式	写 Python 代码	写 CRD（声明式）
部署	本地/容器	Kubernetes 原生调度
状态	代码内部管理	Memory CR + 服务
工具	在代码层集成	Tool CR + MCP
多 Agent 协作	代码管理对话	Team CR + A2A 协议
观测	几乎没有	OTel / Langfuse / Dashboard
适用场景	Demo / 原型 / 单 Agent	企业级生产 / 多 Agent 系统

表 3: ARK 与传统 Agent 库对比

一句话总结：

LangChain 是“构建 Agent 的库”，ARK 是“运行 Agent 的平台”。

两者并不冲突，甚至高度互补。

ARK 的工程价值

用简明语句总结 ARK 的工程价值：

将 Agent 变成 可治理的 Workload
将模型、工具、记忆统一抽象为 可复用资源
使多 Agent 协作 结构化、可观测、可调优
让 Agent 的升级与迭代进入 CI/CD + GitOps 模式
让企业可以像管理微服务一样 管理智能体

这是一条明确的演进路线：

Agent → Service → Platform → Runtime → Operating System

ARK 当前定位于第四阶段：Runtime。

对 Agentic Runtime 的启发

ARK 为 Agentic Runtime 的建设提供了三条直接启发：

统一调度系统

Agent Runtime 必须运行在统一调度系统上（Kubernetes、MicroVM、Wasmtime 等）

声明式能力边界

必须用 declarative（声明式）抽象来拆分能力边界，包括：
- Model Layer
- Tool Layer
- Memory Layer
- Workflow Layer
- Team Layer
- State Layer

可观测性

必须有可观测性，否则多 Agent 系统无法工程化
- Langfuse
- OTel
- 日志 / 事件
- 结构化 JSON

ARK 展示了一个方向：

多智能体系统是一个工程问题，而非提示词工程问题。

总结

如果你只需要构建一个简单的 Agent，LangChain、CrewAI、AutoGPT 等框架已经足够。

但如果你要运营一个由几十到几百个 Agent 组成的系统，并且它们需要协作、长期运行、持续交付与治理，ARK 这类 Runtime 是必然趋势。

它为 Agentic AI 提供了：

云原生的运行模型
可观测的执行路径
可治理的抽象层
可扩展的组件化架构

因此，ARK 值得被视为多智能体工程化的早期范本。

开源也会突然跑路？一个 AI 聊天开发工具居然直接 404 了

Jimmy Song — Thu, 11 Dec 2025 05:20:15 +0000

“开源”在 AI 时代已不再等同于可信承诺，商业项目随时可能收回代码，开发者需警惕表象与现实的落差。

Lunary 仓库消失：一次真实的开源“跑路”案例

在更新我网站上的 AI 开源项目资源库时，第一次遇到一个让我愣住的场景：一个还在对外宣传、拥有官网和商业服务的“开源 AI 工具”，突然在 GitHub 上彻底消失，仓库直接 404。

这个项目叫 Lunary。

原本的仓库地址： https://github.com/lunary-ai/lunary 现在已经变成了 404 Not Found。

值得注意的是，官网 lunary.ai 依然在线，但“开源代码库”这个核心承诺已经消失。

Lunary 的定位与功能

下面介绍一下 Lunary 的主要功能和定位，帮助理解其在 AI 工具生态中的角色。

Lunary 号称是面向大语言模型（LLM）应用的 Observability（可观测性）与 Evaluations（评估）平台，主打：

LLM 会话与反馈日志
成本、延迟、指标分析
Prompt 版本管理
分布式追踪
Evaluations
支持自托管与托管模式
提供 JS / Python SDK，集成 LangChain

整体定位非常清晰： “AI 应用的开发与调试工具”。

事实上，这类产品在过去一年大量涌现，属于新兴的 AI DevTool 赛道。

“开源”标签的现实与风险

问题的核心并不是工具本身，而是它自称“开源”。

Lunary 一直强调：

“Lunary is an open-source platform for developers.”

这种说法非常适合获客，因为开源意味着透明、可信、可自托管、可参与生态。

但现在仓库没了，只剩下网站继续宣传，这就很耐人寻味。

Lunary 并不是一个小众的 hobby project，而是一家商业公司主导的项目。如果是个人突然删库，或许并不意外，但一个对外运营的商业公司这样做极为罕见。

这让我第一次真正看到 AI DevTools 领域的一个现实：“开源”正在被当成品牌词，而不是承诺。

可能导致删库的行业原因

下面分析一下行业内常见的删库原因，帮助开发者理解背后的动因。

商业化压力增加：这类工具的商业模式普遍难以持续，团队可能转向闭源 SaaS。
方向调整（Pivot）：公司发现原有方向难以盈利，准备换赛道。
团队变动：被收购、核心成员退出或资金问题，都可能导致仓库关闭。
合规或法律风险：可观测性产品涉及用户数据，有时会被要求撤下公共代码。

无论原因如何，对用户的影响只有一个：它已经不再是“开源产品”了。

AI 工具领域的“伪开源”现象

最值得关注的不是 Lunary 这家公司，而是这种现象正在 AI 工具领域快速蔓延。

大量项目以“开源”作为获客手段，但缺乏开源治理和长期承诺。

高替代性、高同质化和商业压力，让这类 DevTools 的存活率本就不高。

而当商业团队主导开源时，一个决策就可以让仓库瞬间消失。

在云原生（Cloud Native）时代，大家已经见过一轮“伪开源”；在 AI 时代，这一现象正在加速发生。

给开发者的三点现实教训

结合本次案例，总结三点对开发者极具现实意义的教训：

“开源标签”不等于可信：商业公司主导的开源项目没有社区或基金会托底，随时可能收回。
AI DevTools 的不稳定性远高于基础设施：这类工具不是刚需，替代性极强，生命周期很短。
工具可用性要优先于“是否开源”：因为它随时可能不再开源。

个人维护 AI 项目列表的首次“删库”体验

在过去两年收集了数百个项目，这是我第一次遇到“商业开源项目直接消失，官方仓库 404”的案例。

这件事在我看来，是一个行业信号：AI 开源世界正在进入漂移期，商业项目的开源承诺越来越不稳定。

也提醒所有做技术选型的人：在 AI 时代，开源已经不再是一个可以默认信任的标签。

总结

Lunary 仓库的消失并非孤例，而是 AI 工具领域“伪开源”现象的缩影。开发者在选择工具时，需警惕“开源”标签背后的实际承诺，关注项目的治理结构和可持续性。未来，开源与商业的边界将更加模糊，理性判断和风险意识将成为技术选型的必备能力。

Lunary 仓库的突然消失，揭示了 AI DevTools 领域开源项目的不稳定性。对于开发者而言，技术选型时应更加关注项目的可用性和社区治理，而非仅凭“开源”标签做决策。未来，随着行业发展，类似现象或将更加频繁，唯有理性判断与风险意识，才能在快速变化的技术浪潮中立于不败之地。

AI 原生时代的 CNCF？Agentic AI Foundation 正式成立

Jimmy Song — Wed, 10 Dec 2025 03:25:45 +0000

智能体生态的标准化与开放协作，已经不是锦上添花，而是 AI 原生时代能不能工程化落地的关键分水岭。

AAIF（Agentic AI Foundation）的成立，是头部厂商在“智能体协议层”提前卡位的结果。
真正的难点不在技术，而在组织如何从“人执行 + AI 辅助”迁移到“智能体执行 + 人监督”。
智能体落地需要一整条分阶段 adoption path，而不是一堆协议和 demo。
CNCF 和 AAIF 是互补关系：前者管“智能体跑在什么基础设施上”，后者管“智能体之间怎么协作”。这恰好对应我在 ArkSphere 中构建的体系。

云原生的问题解决了，AI 原生的问题刚开始

过去十年，云原生靠 Kubernetes、Service Mesh、微服务等技术，把“应用如何在云上跑”这件事基本定型。但 AI 原生的问题完全不同： 不是“怎么部署一个服务”，而是“系统里有多少行为可以交给智能体自己跑”。

CNCF 的 Cloud Native AI（CNAI）解决的是基础设施层问题： “模型训练 / 推理 / RAG 怎么在 Kubernetes 上规模化、安全地运行？”

而 AI 原生真正缺的是另一层： 智能体怎么协作、怎么访问工具、怎么治理、怎么被审计。

这正是 AAIF 想补的空档。

AAIF 的三件武器：协议 + 运行时 + 开发规范

AAIF 托管了三件来自创始成员的核心技术：

① Anthropic 的 Model Context Protocol（MCP）

https://github.com/modelcontextprotocol

一个“智能体系统调用接口”：

统一定义智能体如何访问数据库、API、文件、外部工具；
设计目标更像 AI 版 gRPC + OAuth；
已被 Claude、Cursor、ChatGPT、VS Code、Microsoft Copilot、Gemini 等接入。

它不是最耀眼的技术，但可能会成为整个 Agentic 生态的 plumbing。

② Block 的 Goose 框架

https://github.com/block/goose

MCP 的参考运行时：

本地优先、可组合的智能体 workflow 引擎；
让企业可以先在小范围试点智能体，而不用押注特定厂商；
是协议落地的工程模板。

③ OpenAI 的 AGENTS.md

https://agents.md

一个朴素但有效的规范：

在项目仓库里放一份 AGENTS.md；
写清楚编译步骤、测试、约束、上下文规则；
所有“理解 AGENTS.md 的智能体”都能按同一套指令操作代码库。

让智能体的行为更可预测、更可审计。

为什么 AAIF 这么“着急”成立？这是一次标准层的抢跑

对比一下历史：

Kubernetes 前身 Borg 在 Google 内部跑了十几年，K8s 开源两年后才捐给 CNCF；
PyTorch 发布六年后才加入 Linux Foundation；
而 MCP 从发布到被捐给 AAIF，只用了 1 年多。

AAIF 不是“成熟技术进基金会”，而是提前把关键位置按住。

原因很现实：

防止智能体生态碎片化 现在各种“工具调用协议”百花齐放，三年后很可能变成互不兼容的孤岛生态。
协议层比模型层更容易形成全球共识 模型竞争无法避免，但协议可以标准化、开源化，并避免厂商私有垄断。
地缘科技竞争的必然动作 把 Agentic AI 的底层行为标准放进 Linux Foundation，本身就是一种“公共化”，既是合作姿态也是战略布局。

AAIF vs CNCF：不是竞争，是两层拼图

CNCF 的角色：

“智能体工作负载跑在什么底座上？” Kubernetes、Service Mesh、可观测性、AI Gateway、RAG Infra，都在这一层。

AAIF 的角色：

“智能体怎么协作、怎么调用工具、怎么治理？” 协议、运行时、行为规范，都在这一层。

类比关系：

领域	负责内容
AAIF	Agentic Runtime 的语义层、协作层
CNCF/CNAI	AI Native Infra 的资源层、执行层

表 3: AAIF 与 CNCF 对比

这正好对应我在 ArkSphere 架构图中的上层语义与底层基础设施。

长期来看，两边会高度耦合： CNCF 的 KServe、KAgent、AI Gateway 会默认支持 MCP / AGENTS.md， AAIF 的 Runtime 会默认跑在云原生底座上。

真正的难点：不是协议，而是组织和人

绝大多数企业会卡在：

智能体到底能负责多少？
错了谁背锅？
审计、SLO、合规怎么定义？
多智能体协作怎么可视化？
工具调用权限怎么控？

换句话说，智能体落地不是“技术迁移”，而是“组织迁移”。

如果 AAIF 不能给出：

分阶段 adoption 方法论
典型组织结构迁移路径
工程级 best practice
失败案例与反模式

那它很难做到像 CNCF 那样形成真正的产业影响力。

小结：AAIF 是边界被画出来的那一刻

AAIF 的成立，对我来说像是：

“智能体世界的战场边界终于画出来了，接下来要看工程界能不能把它跑通。”

CNCF 当年解决了“云原生怎么跑”， AAIF 现在试图解决“智能体怎么协作”。

未来五年，谁能把这两个世界真正连上，谁就会站在下一代基础设施的入口处。

这一点，也是我在 ArkSphere 单独拉一条“Agentic Runtime + AI Native Infra”研究路线的原因。

AI 原生时代的“三体”架构

最后再加点私货，是我对 ArkSphere 的思考。

图 3: AAIF × CNCF：AI 原生智能体架构的三层关系

这张图展示了 AI 原生时代的三层结构：

CNCF（底层）：提供智能体运行必须的云原生底座，包括 Kubernetes、Service Mesh、GPU 调度与安全体系。
AAIF（中层）：定义智能体的运行时语义与标准，包括 MCP 协议、Goose 参考运行时、AGENTS.md 行为规范。
ArkSphere（桥接层）：将“Agentic Runtime 语义层”与“AI Native Infra 基础设施层”对齐，形成可工程化的智能体架构规范。

一句话概括：

Infra 负责“跑起来”，Runtime 负责“怎么行动”，ArkSphere 负责“怎么拼成系统”。

Bun 被 Anthropic 收购：AI 原生运行时的结构性信号

Jimmy Song — Wed, 03 Dec 2025 05:24:00 +0000

运行时的归属变迁，正重塑 AI 编程与基础设施的底层逻辑。

Bun 被 Anthropic 收购的消息公布后，我的关注点并不在于交易本身，而在于它暴露出来的结构性信号：通用语言运行时开始被卷入 AI 编程系统的路径依赖之中。这不是“一个 JS 项目找到归宿”，而是“语言运行时第一次被头部大模型厂商纳入统一工程体系”。

这一事件值得深入拆解。

Bun 的工程特征与现状

在分析 Bun 的行业意义前，先梳理其运行时特性。下方列表总结了 Bun 的主要工程能力：

高性能 JavaScript/TypeScript 运行时
内置打包工具（bundler）、测试框架、包管理器
单文件可执行
冷启动极快
Node 兼容但没有 Node 的历史依赖

这些能力已形成可测量的性能壁垒。

但需要指出，Bun 当前尚未具备 AI 运行时（AI Runtime）的核心属性，主要缺失包括：

权限模型
工具隔离
能力声明协议
模型可理解的执行语义
沙箱化执行环境

因此，Bun 的“AI 原生（AI Native）”属性尚未建立，而 Anthropic 的收购为其向该方向演进提供了机会。

头部模型厂商收购通用运行时的意义

历史上，模型公司收购编辑器、插件、IDE 并不罕见，但在已知公开案例中，主流大模型厂商此前从未直接收购过成熟的通用语言运行时。Bun × Anthropic 是第一次明显把 runtime 拉进 AI 编程系统版图的事件。这一动作释放了两个工程层面的信号：

AI 写代码的速度持续提升，运行环境的确定性需求被放大。生成→执行→验证→销毁的循环加剧了环境不可重复性问题。
模型需要“可控的执行底座”而非传统操作系统。Agent（智能体）不适合在不可控、不可预测的 OS 层执行工具。
运行时需要嵌入到模型的内部工程链路中。未来的 IDE、Agent、自动修复管线，都可能直接调用 runtime 的 API。

这不是短期的业务整合，而是工程链路压缩趋势的显现。

AI 编码时代的运行时需求分化

结合过去一年对智能体运行时（Agentic Runtime）的观察，AI 编码时代对运行时的需求正在分化。下方列表总结了主要趋势性工程抽象：

确定性：AI 生成的代码不会被逐行审查，执行结果跨机器、跨时间必须一致。
最小分发单元：用户不再安装语言环境和大量依赖，可验证、可复制、可移动的单一执行单元成为合理路径。
工具隔离：模型不能直接访问 OS 的全部能力，需要严格定义工具可见的上下文和权限。
短生命周期执行：Agent 的调用模式更像“批任务”，而非长驻服务。
能力声明：运行时需暴露“我能做什么”，而非全部操作系统接口。
可嵌入自测试链路：模型生成代码后需立刻执行测试、收集错误、循环改写，运行时必须提供可观测性和诊断原语。

这些需求并非 Bun 独有，也非 Bun 首创，但 Bun 这种偏“单体可控”的运行时结构更容易沿此方向演进。

图 3: AI 原生运行时的最小执行循环示意图

Bun 在 Anthropic 体系下的潜在角色

如果将 Bun 仅视为 Node.js 替代品，收购事件意义有限。但若将其视为未来 AI 编码系统的执行底层，逻辑会更清晰：

代码由模型生成
构建由 runtime 自带工具链完成
测试、验证、修复由模型循环调用 runtime
所有执行行为由 runtime 定义语义
runtime 形成 Anthropic 内部的“最小稳定层”

这种模式类似 Chrome 与 V8 的关系：执行引擎与上层系统长期共演化，性能与语义同步演进。

Bun 能否承担这一角色，取决于 Anthropic 的架构选择，但事件本身已为该方向打开了可能性。

产业趋势与未来演化

结合事实、迹象与工程趋势，可以预见以下方向：

“Agent Runtime（智能体运行时）”类别将逐步明确
bundler、runtime、test runner 的边界持续模糊
云厂商将推出具备能力声明的可控 runtime
权限模型与安全沙箱下沉到语言运行时层
运行时成为模型工具链的一部分，而非外部环境

这些趋势并非短期内全部落地，而是工程演化的必然路径。

总结

Bun × Anthropic 的结合不是“开源项目被收编”，而是语言运行时首次被大模型体系主动吸收进工程链路。模型层的竞争仍将持续，但真正重塑软件形态的，是 AI 原生运行时的结构性变革。这是值得长期关注的基础层变化。

Agentic Runtime 的现实主义：从麦肯锡 Ark 看 2026 年的基础设施趋势

Jimmy Song — Tue, 02 Dec 2025 12:05:49 +0000

声明

ArkSphere 与 McKinsey Ark 无任何隶属或关联关系。

Agentic Runtime 的价值不在于统一接口，而在于语义治理和工程范式的变革。Ark 只是趋势的缩影，未来属于可治理的 Agentic Workload。

最近 ArkSphere 社区关注麦肯锡开源的 Ark（Agentic Runtime for Kubernetes）。虽然该项目仍处于技术预览阶段，但其架构和语义模型已成为 2026 年 AI Infra 方向的重要风向标。

本文重点分析 Ark 的工程范式和语义模型对行业的启示，避免重复讨论统一模型 API 失败的原因和基础架构通用逻辑，聚焦于 ArkSphere 社区的独特视角。

Ark 的语义模型与工程范式

Ark 的最大价值在于将 Agent 作为 Kubernetes 一级公民，通过 CRD（自定义资源定义，Custom Resource Definition）和控制器（Reconciler）实现任务闭环。这种语义抽象不仅提升了治理能力，也与主流云厂商的 Agentic Runtime 路线高度一致。

Ark 主要资源包括：

Agent（推理主体）
Model（模型选择与配置）
Tools（能力插件/MCP, Model Capability Plugin）
Team（多 Agent 协作）
Query（任务生命周期）
Evaluation（评估）

下方图表展示了 Agentic Runtime 的语义关系：

图 5: Agentic Runtime 语义关系图

架构与社区活跃度

Ark 架构采用标准的控制面（Control Plane）体系，强调运行时语义的统一。其社区活跃度高，工程师主导，代码结构清晰但生产可用性仍在完善。

图 6: Ark 架构与控制面流程

ArkSphere 的边界与启发

Ark 的出现让 ArkSphere 的边界更加清晰。ArkSphere 不做统一模型接口、多云 abstraction、工具大杂烩或框架层写法大全，而是聚焦于：

Agentic Runtime 的语义体系（任务、状态、工具调用、协作图谱等）
企业级运行时治理模型（权限、审计、隔离、多租户、合规、成本追踪）
国内生态工具整合能力
运行时视角的工程范式

ArkSphere 是 runtime-level 的生态与工程体系，不是“模型抽象层”，也不是“agent 开发框架”。

2026 年的关键变化

2026 年将进入 Agentic Runtime 时代，Agent 不再是一个 class，而是一个 workload，需要被治理而不是被 import。Ark 只是趋势中的一个案例，方向已非常明确：

语义模型和可治理性成为亮点
任务闭环是核心价值

总结

Ark 的现实主义启示我们：未来属于 Runtime、语义、可治理性和 Workload-level 的 Agent，行业不再追求统一 API 或框架写法，而是聚焦于可治理的运行时语义和工程范式。

深度解析 Ark：AI 时代的 Kubernetes？还是一场新的工程范式重构？

Jimmy Song — Tue, 02 Dec 2025 10:54:26 +0000

声明

ArkSphere 与 McKinsey Ark 无任何隶属或关联关系。

Ark 的最大价值在于工程范式的重塑，而非功能本身。它为 AI Infra 指明了方向，也为社区生态留下了巨大空间。

最近我们 ArkSphere 社区里有不少人开始研究 McKinsey 开源的 Ark（Agentic Runtime for Kubernetes）。

有人觉得它很激进，有人觉得它是咨询公司玩票，也有人抛出那句现实主义金句：

现阶段需要的是“agentic runtime 圈子的现实主义”，而不是“统一模型的浪漫主义”。

这句话我非常认同。

我花了点时间分析 Ark 的源码、架构和设计理念，也结合我们社区的讨论，最终得出的判断是：

Ark 的意义不在功能，而在范式。

它不是答案，但它指向了 AI Infra 的方向。

下面是我对 Ark 的解读，偏工程、偏架构、偏趋势，也包括对 ArkSphere 的启发。

Ark 到底是什么？

Ark 的核心定位是：把 Agent 当成 Kubernetes Workload 来运行的 Runtime。

它不是框架、不是 SDK、不是 AutoGen 那类多智能体工具，而是一个完整的系统，包括：

控制面（Controller）
自定义资源模型（CRD, Custom Resource Definition）
API 服务
Dashboard
CLI
Python SDK

本质上，Ark 是 Agent 的控制平面（Control Plane）。

Ark 在 Kubernetes 中定义了七类核心 CRD。下方流程图展示了这些资源之间的关系：

图 9: Ark CRD 资源关系

通过这套 CRD，Ark 将 Agent 系统资源化、声明式化，从而具备了如下能力：

生命周期管理
多租户隔离
RBAC（Role-Based Access Control，基于角色的访问控制）
可观测性
可升级性
可扩展性（工具、模型、MCP）

换句话说，Ark 关注的不是“怎么写 Agent”，而是“怎么在企业级系统里运营 Agent”。

三层架构：语言与组件混搭，但体系完整

Ark 的整体架构分为三层，分别对应不同的技术栈和职责。下方流程图展示了各层组件的关系：

图 10: Ark 三层架构组件分层

这不是“贴膜项目”，而是一个完整可运行的 AI Runtime 体系，工程化程度远高于目前市场上的 Agent 框架。

它是不是 AI 时代的 Kubernetes？

回顾 Kubernetes 的核心价值：

Kubernetes 从来不是“统一云 API”，它统一的是“应用运行模型”。

云厂商 API 没统一，网络没统一，存储没统一。统一的是：Pod、Deployment、Service 这些应用模型。

Kubernetes 的成功在于：

它在差异之上提供了一个稳定的应用抽象。

Ark 的目标并不是统一所有大语言模型（LLM）、MCP 或工具格式，而是：

Agent 的资源模型（CRD） + 控制面（Reconciler） + 生命周期。

从这个角度看，Ark 提供了 AI 时代的“声明式应用模型”雏形。

能否成为“AI 时代的 Kubernetes”，目前还言之过早，但它已经提供了一个种子。

和其他框架对比：不在一个层级

当前主流 Agent 框架如 LangChain、CrewAI、AutoGen、MetaGPT 等，解决的问题与 Ark 完全不同。

下表对比了各框架的定位与局限：

名称	解决什么问题	本质局限
LangChain	Agent/Tool 组合	不关心部署与治理
AutoGen	多 Agent 对话	缺乏控制面和生命周期
CrewAI	工作流式多 Agent	缺少调度、RBAC、资源模型
MetaGPT	Agent SOP	只是执行逻辑，不是平台
OpenDevin	AI IDE/开发助手	不是 Agent Runtime
Ark	Agent 的控制平面 + 资源化体系	功能尚未成熟

表 3: 主流 Agent 框架与 Ark 对比

简而言之：

其他工具关注“怎么写 Agent”。
Ark 关注“Agent 怎么运行、调度、治理、观测、扩展”。

这就是架构级别的差异。

执行流程：像 Pod 一样被调度的 Agent

Ark 的执行流程非常接近 Kubernetes 控制器模型。下方时序图展示了核心流程：

图 11: Ark Agent 执行流程

可以看到，Ark 的流程逻辑透明，工程路径清晰，让 Agent 系统进入“可控”状态。

生产可用性：方向正确，但仍是技术预览

根据官方标注和源码成熟度，目前 Ark 具备如下特性：

可运行
可学习
可扩展
但暂不建议在生产环境大规模使用

主要原因包括：

CRD 结构可能变动
API 尚不稳定
MCP 生态尚未成型
Memory 服务仍较为简单
多 Agent Team 执行策略较初级

但工程体系已经成型，这一点非常重要。

社区活跃度：小而精，麦肯锡强驱动

图 12: agents-at-scale-ark GitHub

从 GitHub 数据来看：

Stars：222
Fork：50
Contributors：48
Commit 频率持续
绝大多数贡献来自麦肯锡内部

注：数据截止到本文发稿时 2025 年 12 月 2 日。

稳定度高，但开放性一般。

这也是 ArkSphere 的机会所在：

范式是对的，但生态需要社区来推动。

2026 的趋势：从框架时代走向 Runtime 时代

经过深度分析，我越来越确定如下判断：

2023–2024：大模型 API 调用时代
2024–2025：Agent 框架时代
2025–2027：Agent Runtime / Control Plane 时代（Ark 的方向）

当所有人都在写 Agent 的 Python 脚本时，真正的价值在于：

多 Agent 任务调度
工具注册与治理
Session/Memory 生命周期
结果可复现性
RBAC、审计、租户隔离
可观测性
企业内部个人化智能体系统

Ark 正在提供一个可落地的路径。

对 ArkSphere 的启发

Ark 给 ArkSphere 的启发非常关键且直接：

ArkSphere 不应该做“功能堆叠”，而应该做“范式建设”

Ark 提供了未来 Agentic Runtime 的雏形：

资源模型
控制面
工具注册
多 Agent 协作
评估与治理

ArkSphere 的角色应该是：

汇聚范式、产出规范、孵化生态，而不是重写 Ark 本身。

这就是“AI 原生时代的 CNCF（Cloud Native Computing Foundation）”。

中国本土化空间巨大

本土化可做的方向包括但不限于：

国产大语言模型对接（如 Qwen、DeepSeek、智谱）
企业私有化场景
本地工具/MCP Discovery 生态
多集群/边缘推理
企业级 RBAC、审计、数据隔离
更适合工业场景的 AgentSpec
Runtime/Controller 的增强版本

换句话说：

Ark 解决的是“模型”，而 ArkSphere 可以解决的是“生态”。

我们要的不是“LLM 时代的 Kubernetes”，而是“AI Runtime 的产业级认知体系”

拆解 Ark 后最大的感受是：

AI 原生的未来不是一堆工具，而是一套工程体系。

ArkSphere 可以成为这套体系的发起者。

总结

Ark 并非“万能 Runtime”，也不是“AI 时代的 Kubernetes 终极版本”。

但它做对了一件关键的事情：

它把过去大家在写 Python Agent 脚本时绕不开的痛点，全部抽象成了 Kubernetes 下的资源和控制器。

它代表的是工程学，而不是 Demo。

它不够成熟，但方向是对的。

它不是终点，但它给了我们一条清晰的路线图。

对于我正在运营的 ArkSphere 社区来说，Ark 给了一个明确启发：

未来属于 Runtime，属于 Control Plane，属于可治理的 Agent 系统。

而真正能把这套体系做大的，不是麦肯锡，而是社区。

加入 ArkSphere 社区

从会用 AI 到离不开 AI：为什么 AI 工程时代还没真正开始

Jimmy Song — Sat, 29 Nov 2025 12:41:01 +0000

AI 工程的真正拐点，不是"多少人在用"，而是"多少人离不开"。只有当不用 AI 会带来直接的机会损失和效率损失，AI 工程时代才算真正到来。

起点：关于 2026 年 AI 的预测

最近看到 Amazon CTO Werner Vogels 对 2026 的两个预测冲击最大：

Renaissance Developer：开发者需要跨越代码、产品、商业、社会影响
个性化学习：AI 将重塑教育，围绕差异化路径而非统一大纲

这两点共同指向：AI 不只是工具，而是在重塑人如何成长、如何被定义。

修正：2026 年真的会"AI 饱和"吗？

我最初的预测是：2026 年 AI 使用趋于饱和。但现实告诉我这太乐观了。

到 2025 年底，即便在互联网人群中，大多数人对 AI 的使用仍停留在"听说过"“玩过几次"阶段。距离"日常工作流必需品"还很远。

更关键的是，这个判断有条件约束：基础设施供给、监管、算力成本在 3–6 年内不出现反向制动。任何一个变量中断（成本翻倍、模型停服、政策突变），采纳曲线就会被打破。

拐点的真相：从"会用"到"离不开”

“离不开"是个模糊的词。更精准的定义，需要用指标衡量。

此图展示了衡量 AI 离不开的量化指标，对比目标阈值与当前状态：

图 7: AI 离不开的指标化定义

与互联网、手机、支付的拐点对比：它们都进入了"不用就无法运作"的阶段。AI 还没有。多数指标仍远低于阈值，这就是为什么 2026 年最可能的结果是”会用 AI 的人越来越多，离不开 AI 的人仍是少数"。

会用 ≠ 会构建：五层能力递进

这个差异不是二元论，而是一个清晰的阶梯。

此图展示了 AI 能力成熟度的五层递进模型，从工具使用者到自治系统的演进路径：

图 8: AI 能力成熟度五层模型

当前的缺口最大在第三、四层。大多数人卡在第一、二层，进入第四层的寥寥无几。这意味着高价值的稀缺性不会消失，只会上升。

为什么 AI 工程时代还没到来：三维延缓因素

不是技术问题卡住了，而是三个维度的约束同时按住了进度条。

此图展示了延缓 AI 工程成熟的三维制约因素（技术、制度、组织）及其对应的延缓指标：

图 9: AI 工程成熟的三维制约

关键观察：只要有一个维度被卡住，整个生态的成熟就会延缓。当前三个维度都没有充分成熟的解决方案。

现实窗口：能力进阶的三条路

未来三年不是"赢家通吃"，而是多个能力等级同时升值。

能力方向	短期价值	长期前景	瓶颈
第一→二层（工具→集成）	⭐⭐ 快速贬值	⭐ 饱和	门槛低，竞争剧烈
第二→三层（集成→沉降）	⭐⭐⭐⭐ 稀缺	⭐⭐⭐⭐ 持续升值	需要行业深度、长期迭代
第三→四层（沉降→抽象）	⭐⭐⭐⭐⭐ 极稀缺	⭐⭐⭐⭐⭐ 定义生态	思维跨度大，需要社区影响力

关键结论：虽然"会用 AI"的人快速增加（压低第一层价值），但由于三维延缓因素，第三、四层的稀缺性只会上升。

我在 arksphere.dev 上做的事

基于上述判断，我专注探索 AI Native 基础设施的架构演化。目标不是整理模型用法，而是研究支撑可扩展智能系统的底层能力栈：调度、存储、推理、Agent Runtime、自治控制、观测与可靠性。

内容不再是课程或技巧合集，而是围绕 Infra → Runtime → System Abstraction 的持续演进记录。arksphere.dev 是这个实验与沉降的场地。

总结

AI 工程时代的拐点不在"多少人在用"，而在"多少人离不开"。后者需要五个可度量指标同时达阈值，目前距离仍远。

“会用 ≠ 会构建"不是二元论，而是五层递进阶梯。第三、四层的稀缺性随着第一层人数增加而上升——这正是未来三年最大的机遇窗口。

但这个窗口的宽度，很大程度取决于技术、制度、组织三个维度如何协同演进。希望更多人在做 AI 工程时，不仅关注技术创新，还能为制度建设、人才成长、风险治理这些"隐形的工程"投入同等思考。

把 Antigravity 用成一个更像 VS Code 的 AI IDE

Jimmy Song — Thu, 20 Nov 2025 03:55:34 +0000

在迁移 IDE 时最大的痛点就是用户习惯问题，通过安装一些列插件和配置，可以让 Antigravity 更像 VS Code，在保留用户习惯的基础上增加 Open Agent Manager 功能。

Antigravity 发布第一天我就装上了。几天用下来，最大的感觉是：它更像一个“智能体（Agent）控制台”，而不是传统意义上的集成开发环境（IDE）。不过我还是习惯 VS Code 那一套界面和插件生态，所以花了一点时间，把 Antigravity 调成了一个“更像 VS Code 的 AI IDE”。

图 1: Antigravity IDE UI

下面是我实际在用的配置和步骤，读者可以直接照着复现。

Antigravity 初体验

几条主观印象：

界面分为智能体管理视图和编辑器视图，逻辑有点像 AgentHQ + VS Code。
智能体改代码速度很快，一次完成的比例明显高于普通“聊天型”助手。
编辑器区域和上下文窗口都很大，适合长 diff、长日志。
默认用的是 OpenVSX / OpenVSCode Gallery，扩展生态和我现有的 VS Code 不完全一致。

后面的所有操作，都围绕一个目标：保留 Antigravity 的智能体特性，同时尽量沿用我在 VS Code 里的工作流。

切换扩展市场为 VS Code 官方 Marketplace

Antigravity 本质是 VS Code fork，可以直接改 Marketplace 配置。

在 Antigravity 里：

在主菜单中 Settings -> Antigravity Settings -> Editor，找到以下两项，把 URL 改成 VS Code 的地址。

Marketplace Item URL:

https://marketplace.visualstudio.com/items

Marketplace Gallery URL:

https://marketplace.visualstudio.com/_apis/public/gallery

图 2: VSCode Marketplace 配置

重启 Antigravity。

改完之后，扩展搜索和安装就等同于 VS Code 官方 Marketplace 了，后面安装 AMP、GitHub Theme、VS Code Icon 等扩展都走这一套。

安装 AMP 扩展

AMP 目前尚未官方支持 Antigravity，不过通过 VS Code Marketplace 可以直接装。

步骤：

打开扩展面板（和 VS Code 一样的那个 Extensions 图标）。
搜索 AMP 扩展，正常安装。
登录时使用 AMP 的 API 密钥（API Key）。

目前在 Antigravity 里尚不支持像 VS Code 那样一键登录账号，只能走 API 密钥方式。

小结

装好之后，AMP 在 Antigravity 内的体验和 VS Code 基本一致，补全、重构都能正常使用，只是登录这一段需要手动配置一次。

之所以要安装 AMP，是因为它有免费模式，我自己使用过程中感觉用来撰写文档、执行脚本和作为日常的命令行工具都很方便，速度特别快，尤其用来优化 prompt 效果也很棒。

导入 CodeX 扩展

CodeX 在网页端目前未提供直接的 VSIX 下载链接，我的做法是先通过 VS Code 导出，再导入 Antigravity。

图 3: 在 VS Code 中导出 Codex Extension

具体步骤：

在 VS Code 中安装 CodeX 扩展（如果之前没装的话）。
打开 VS Code 的扩展管理界面，找到 CodeX，导出为 .vsix 文件。
切换到 Antigravity，打开 Extensions 面板，选择“Install from VSIX”（从 VSIX 安装）。
选中刚才导出的 codex-x.x.x.vsix 文件，完成安装。

提示

因为本机 VS Code 已经登录过 CodeX，导入到 Antigravity 后，它可以自动复用登录状态，我这边没有再走一次登录流程。

优化编辑器配置

除了扩展市场和插件，还有几处小改动，让整体体验更接近 VS Code：

主题：选择和 VS Code 相同的配色方案，减少视觉切换成本，我选择使用 GitHub Theme 和 vscode-icons。
Editor Settings：在“Open Editor Settings”里，把缩进、格式化、行宽等参数改成自己在 VS Code 里的那一套。这些我都定义在了 workspace 的 settings.json 里了，无需迁移。

做完这些之后，编辑区几乎就是一个“带智能体控制台的 VS Code”。

解决 Chrome 浏览器调试问题

如果你使用的是虚拟网卡「TUN 模式」，那么会遇到无法启动 Chrome 浏览器调试功能，因为 Antigravity 使用 CDP 通过 localhost 来调试网页，而 TUN 会拦截这些流量。解决方式是在 Antigravity 的「Settings」- 「HTTP: No Proxy」中增加以下配置：

localhost
127.0.0.1

图 4: 配置 Antigravity 的本地流量不通过代理

遗留问题

要想彻底从 VS Code/GitHub Copilot 迁移到 Antigravity，我目前认为还存在以下几个主要问题：

自定义能力受限：Antigravity 无法像 Copilot Chat 那样支持自定义 prompt 和 Agent，目前只支持“规则”（rules）配置，这限制了更灵活的工作流定制。
模型生态待完善：Antigravity 尚未原生接入各大厂商的最新模型，比如 OpenAI、Anthropic、Microsoft、xAI 等，而 GitHub Copilot 在这方面表现更优。
成本考量：
- 未来的价格预测可能在每月 20 美元起。
- 目前不支持免费模型，这与 GitHub Copilot（即使是 Copilot Pro 用户也享有免费模型选项）形成对比。
稳定性问题：Agent 在运行过程中经常遇到“Agent terminated due to error”的提示，需要手动重试或开始新会话，这在一定程度上影响了工作流的流畅性。不过我相信这个问题今后可能会得到解决。

GitHub Copilot VS. Antigravity

虽然 Antigravity 在某些方面已经做得很好，但与 GitHub Copilot 和 VS Code 的结合仍有很大的提升空间。

我常用的大模型在 VS Code 中都有支持：

图 5: Copilot 支持的大模型（部分）

我长期积累的 prompt：

图 6: Copilot chat 可以快速调用自定义 prompt

我收藏的 agent：

图 7: Copilot chat 可以选择自定义 agent

下面是我使用 VS Code/VS Code 的一些体会，我觉得暂时无法被其他 IDE 替代：

Ask/Edit/Agent/Plan 模式很切合我的工作习惯。
支持自定义 prompt 和 agent，经过我长时间的积累，很多 prompt 和 agent 是我日常使用了，很难再找到其他地方用得上。
模型上新最快，一有新模型出来，GitHub Copilot 就能第一时间用上。
跟 VS Code 配合最好，可以无缝集成，无需额外配置，使用起来非常方便。
更新频繁，我前几天给 VS Code 提交的 Bug 当晚就修复了。
Copilot Chat 的快捷键调用十分方便，可以快速调用各种功能。
GitHub 为我免费开通了 Pro 账户，虽然每月 premium 调用额度只有 300 次，但是结合其他插件，比如 AMP、Codex、Droid、Qwen 等，可以实现更高效的工作流程。即使将来开通了付费账户，10 美元每月的费用，也在同类产品中具有很高的性价比。

实践经验

最后几条目前实际使用中的经验，偏主观，但也可以当作参考：

建议不要把 Antigravity 当成“VS Code + 聊天框”，要用它的智能体功能做成完整任务：让智能体先给出计划，再执行修改。
每次大的改动都新开一个 Git 分支，把智能体的行为限制在分支里，所有 diff 走正常的拉取请求（PR, Pull Request）流程。
对智能体的输出尽量要求有“产物（Artifacts）”（方案、计划、测试说明），而不是只看最终代码，这样方便回溯和复盘。
VS Code 里已经非常顺手的插件（AMP、CodeX 这种）可以直接迁移过来，减少切换 IDE 的认知负担，把精力集中在体验新的智能体工作流上。

总结

目前我的体验是：Antigravity 负责提供更强的智能体能力和多视图控制台，而通过上述几步，把界面和插件生态调得足够接近 VS Code，可以比较平滑地迁移日常开发工作流。

Cloudflare 11·18 全网故障：隐性假设如何摧毁现代互联网基础设施

Jimmy Song — Wed, 19 Nov 2025 18:56:34 +0800

现代互联网基础设施的最大风险，往往不是代码本身，而是那些未被显式定义的隐性假设和自动化配置链路。Cloudflare 的这次故障，是所有 Infra/AI 工程师都必须正视的警钟。

昨天（11 月 18 日），Cloudflare 发生了自 2019 年以来影响面最大的全网级故障。由于本站托管在 Cloudflare 上，也未能幸免。这也是本站上线 8 年来，极少数因故障而无法访问的情况（上一次是 GitHub Pages 故障，发生在微软收购 GitHub 的那年）。

图 1: jimmysong.io 因 Cloudflare 故障导致宕机持续长达 27 分钟

本次问题并非攻击或传统意义上的软件 bug，而是一条看似“安全”的权限更新，引爆了现代基础设施体系中最脆弱的一环：隐性假设（Implicit Assumption）与自动化配置链路（Automated Configuration Pipeline）。Cloudflare 官方已发布博客 Cloudflare outage on November 18, 2025 说明事故原因。

下面是本次故障的链式反应过程：

一次权限调整，引发元数据变化；
元数据变化导致 feature file 行数翻倍；
行数翻倍触发代理模块内存上限；
内存上限导致核心代理 panic；
代理 panic 引发下游系统集体崩溃。

这种链式反应，是当今互联网规模下最典型、也最危险的系统性失败方式。

事故根源：隐性假设不是契约

首先介绍本次事故的核心隐患。Bot Management 的 feature file 每五分钟自动生成，依赖一个默认前提：

system.columns 查询结果只包含 default 数据库。

这一假设未被写入文档，也未在配置中验证，仅存在于工程师的心智模型中。

当 ClickHouse 权限更新后，r0 的底层表也暴露出来，查询结果瞬间翻倍。文件大小突破了 FL2 的 200 feature 内存预设，最终引发 panic。

隐性假设一旦被破坏，系统就缺乏缓冲空间，极易导致级联故障。

配置链路的风险高于代码链路

本次事故并非代码修改导致，而是数据面变更：

SQL 查询行为改变；
自动生成的 feature file；
全网自动广播。

现代基础设施的典型现象是：数据、schema、metadata 远比代码更容易破坏系统稳定性。

Cloudflare 的 feature file 属于“供应链输入”，而非普通配置。任何进入自动化广播路径的内容，其地位等同于系统级指令。

语言安全无法消除边界层复杂性

有前 Cloudflare 工程师对此做出精准概括：

Rust 能避免一类错误，但边界层、数据契约（Data Contract）、配置管道的复杂性并不会因此消失。

FL2 的 panic 源自一行 unwrap()。这不是语言问题，而是系统契约缺失：

feature 数量增长无上边界验证；
文件 schema 缺少版本约束；
feature 生成逻辑依赖隐性行为；
核心代理错误模式为 panic 而非降级。

现代分布式系统（Distributed System）的大部分事故来自“坏输入”，而非“坏内存”。

核心代理需要可控失败路径

FL/FL2 是 Cloudflare 的核心代理，所有请求都必须经过。此类组件的失败路径不能以 panic 结束，应具备如下能力：

忽略异常特征；
截断超限字段；
回退到旧版本；
fail-open 或 fail-close；
跳过 Bot 模块继续处理流量。

只要代理“活着”，全网就不会完全瘫痪。

数据变更比代码变更更不可控

本次事故的本质在于：

权限的细微变更；
ClickHouse 默认行为改变；
查询结果扩散到分布式系统；
自动化发布放大错误；
边缘代理因输入失控崩溃。

未来 AI Infra（AI Infrastructure）将更加复杂：模型、tokenizer、adapter、RAG index、KV snapshot 都需高频更新。

未来的 AI 基础设施中，数据面的风险将远高于代码面。

恢复过程展现工程组织成熟度

Cloudflare 在事故期间采取了多项措施：

阻断错误 feature file 的继续生成；
强行分发上一版本文件；
回滚 Bot 模块配置；
让 Workers KV、Access 在核心代理外运行；
分阶段恢复流量。

在全球数百个 PoP 同时恢复，体现了极高的工程成熟度。

这次事故对 Infra/AI/云原生工程师的启示

Cloudflare 事件呈现了未来大型系统常见的四类风险：

隐性假设失效；
配置供应链污染；
自动化发布放大错误；
核心代理缺少降级路径。

对 AI Infra 从业者而言更具现实意义：

模型权重更新无 schema 核验；
adapter 合并可能被污染；
RAG index 增量构建不稳定；
inference graph 配置可能被坏数据破坏；
自动 rollout 的模型可能全网扩散错误。

AI 工程正在重演 Cloudflare 的基础设施困境，只是规模更快、风险更大。

前 Cloudflare 员工观点总结

他的观点准确指出了分布式系统中最难解决的部分：

问题不是代码，而是契约缺失；
不是语言，而是输入边界未定义；
不是模块，而是配置供应链缺少验证；
不是 bug，而是缺乏 fail-safe 机制。

这次事故证明：现代基础设施真正脆弱之处在于“行为边界”，而非“内存边界”。

总结

Cloudflare 11·18 故障并非偶然，而是现代互联网基础设施演化到大规模、高度自动化阶段的必然产物。

本次事件带来的核心启示：

系统假设必须显式化；
配置链路必须验证；
自动化发布需有“死门”机制；
核心代理需设计可控失败路径；
数据面的契约必须严于代码面契约。

在 AI-native Infra 时代，这些要求只会更加严格。

参考文献

云原生的下半场：AI Native 平台工程时代已经到来

Jimmy Song — Mon, 17 Nov 2025 11:07:40 +0000

云原生的下半场不是被 AI 取代，而是被 AI 重写。平台工程的未来，将以模型和 Agent 为核心，重塑技术栈与开发体验。

自 2015 年接触 Docker 和 Kubernetes 起，我始终沿着云原生主线前行：从最初在 YAML 里写 Deployment，到探索 Service Mesh、可观测性，再到近两年聚焦 AI Infra 与 AI Native 平台。站在 2025 年回望，2015–2025 可视为“云原生的上半场”。以 KubeCon / CloudNativeCon NA 2025 为标志，行业正集体迈入“下半场”：AI Native 平台工程时代。

图 1: KubeCon NA 2025 现场照片

本文将回顾云原生的上一个十年，并结合 KubeCon NA 2025 的内容，梳理关键拐点与下一个十年的技术坐标系。

2015–2025：云原生的“上半场”

过去十年，云原生技术主题大致分为三个阶段。下方流程图展示了各阶段的演进关系。

下方流程图展示了云原生技术主题在过去十年的演进关系：

图 2: 云原生十年技术演进流程

第一阶段：2015–2017 容器编排标准化

本阶段的主线是容器化与编排标准化。

Docker 实现“打包一次，到处运行”的工程现实
Kubernetes 在多轮“编排战争”中胜出，成为事实标准
CNCF 成立，Prometheus、Envoy 等项目陆续加入
企业关注点集中在应用如何迁移到 Kubernetes

在实际工作中，这一阶段最典型的任务是将一批 Java 服务从虚拟机迁移到容器和 K8s，重点理解 Deployment、Service、Ingress 等基础概念。

第二阶段：2018–2020 服务网格与可观测性

Kubernetes 稳定后，复杂度开始从“部署”转向“通信”和“运维”。

Service Mesh（Istio / Linkerd / Consul）解决东西向流量治理
可观测性三件套（Logs / Metrics / Traces）成为默认配置
多集群、多 Region 实践逐步落地
企业开始关注庞大微服务系统的治理

这一阶段，我投入大量时间研究 Istio、服务网格和流量治理，并撰写 Kubernetes Handbook 及 Istio 相关书籍。关注点转向系统稳定性、可观测性和可靠性提升。

第三阶段：2021–2025 平台工程与 GitOps

随着微服务和工具数量激增，平台复杂度开始反噬开发者，Platform Engineering 成为行业关键词。

GitOps（Argo CD / Flux）推动交付流程声明化
内部开发者平台（IDP）成为大中型企业建设重点
“平台即产品”理念传播
FinOps、成本治理、合规审计纳入平台维度
DevOps 从“工具实践”演化为“组织能力 + 平台能力”

我的体会是：大家逐渐意识到，“给开发者一堆工具”并非答案，更需要端到端交付路径和稳定抽象层，让开发者专注业务而非工具拼接。

下表压缩展示了“上半场”各阶段的主要特征。

阶段	核心矛盾	关键技术栈	典型问题
2015–2017 编排	从 VM 迁移到容器	Docker、Kubernetes、CNI	如何可靠部署、如何滚动升级
2018–2020 网格	微服务数量扩大，通信与观测变复杂	Istio/Linkerd、Prometheus、Jaeger	排障困难、可观测性碎片化
2021–2025 平台	工具堆叠过多，开发体验持续下滑	GitOps、IDP、FinOps、Policy-as-Code	开发者疲惫、平台团队被压扁

表 1: 云原生上半场阶段特征

KubeCon NA 2025：云原生“下半场”的信号

2025 年 KubeCon 的主旋律已不再是“如何用好 Kubernetes”，而是聚焦 AI 时代，如何将 Kubernetes 与云原生生态重构为 AI Native 平台。

今年 KubeCon NA 2025 上，行业出现了以下集中信号：

CNCF 发布 Certified Kubernetes AI Conformance Program
Dynamic Resource Allocation（DRA, 动态资源分配）进入主流语境
Model Runtime / Agent Runtime 项目成为大会热点
厂商聚焦 AI SRE、AI Assist Dev、AI 安全与供应链治理
Alex Zenla 等讲者直言 Kubernetes 底层结构需重构

这些内容共同构成了清晰分界线：云原生正式进入“下半场”。

上半场 vs 下半场：云原生叙事的切换

如果将 2015–2025 视为“上半场”，那么 2025–2035 很可能是“下半场”。下表对比了两者的核心差异。

该表展示了平台对象、目标、抽象层等关键维度的变化。

维度	上半场（2015–2025）	下半场（2025–2035，AI Native）
核心对象	容器、Pod、微服务	模型、推理任务、Agent、数据管线
平台目标	稳定交付应用	持续、高效地运行 AI 工作负载与 Agent 编排
抽象层	Deployment / Service / Ingress / Job	Model / Endpoint / Graph / Policy / Agent
资源调度	CPU / 内存 / 节点	GPU / TPU / ASIC / KV Cache / 带宽 / 能耗
工程主线	DevOps / GitOps / 平台工程 1.0	AI Native Platform Engineering / AI SRE
安全与合规	镜像安全、CVE、供应链 SBOM	模型安全、数据安全、AI 供应链与“幻觉依赖”
运行时形态	容器 + VM + Serverless	容器 + WASM + Nix + Agent Runtime

表 2: 云原生上下半场核心差异

从开发者视角看，最直观的变化是：未来平台不再以“服务”为一等公民，而是以“模型 + Agent”为核心。

样貌之一：AI Native 平台的技术分层

为帮助理解 AI Native 平台的结构，下方分层图展示了各技术层级的关系。

下方分层图展示了 AI Native 平台各技术层级的关系：

图 3: AI Native 平台分层示意

原有云原生主要聚焦于 L0 + L2（Kubernetes + 平台工程），而 AI Native 时代，L1（Model Runtime、Agent Runtime、异构资源调度）成为新主战场。

关键变化一：从“容器为中心”到“模型为中心”

在上半场，云原生主要对象是应用进程，容器仅为打包形式。下半场则需处理：

模型版本管理与灰度发布
推理性能、延迟与成本平衡
多模型组合、路由、A/B 实验
模型与数据、特征、向量索引的关系

KubeCon NA 2025 上 CNCF 发布的 AI Conformance Program，核心在于标准化模型工作负载，让其像 Deployment 一样被管理。平台工程将迎来新的抽象层，不再只是“部署服务”，而是“部署模型能力”。

关键变化二：DRA 与异构资源调度的黄金窗口期

过去编写 Deployment 时，主要关注 CPU 和内存。如今，GPU 推理、训练、Agent Runtime 等场景下，静态配额已无法满足需求。

动态资源分配（Dynamic Resource Allocation）带来如下变化：

资源类型可插拔（GPU/TPU/FPGA/ASIC）
按拓扑、NUMA、显存碎片智能调度
推理请求与算力分配绑定，实现更细粒度 QoS
成本优化与功耗控制纳入调度决策

这是 Kubernetes 诞生以来最重要的“资源观”升级。调度器不再只是集群组件，而是 AI 平台的策略引擎。

关键变化三：Agent Runtime 成为新一代运行时

KubeCon 上涌现出一批代表性项目：

Edera：精简、可验证 runtime 再设计
Flox：基于 Nix 的“uncontained”运行环境
Golem：基于 WASM 的大规模 Agent Orchestration

这些项目的共识是：AI Agent 不适合完全套用传统容器运行模型。Agent 具备如下特点：

强状态性：上下文、记忆、会话
高并发但颗粒度细：海量轻量任务
对延迟和冷启动极其敏感
需支持失败后继续执行（resume）

新一代运行时关注如何为“十万级 Agent”提供可靠执行、状态管理和审计，而不仅仅是“多开 Pod”。

关键变化四：AI SRE 与 AI 安全

KubeCon NA 2025 上，安全与运维话题因 AI 被进一步放大：

软件供应链攻击与 CVE 持续增加
LLM 辅助编码带来“幻觉依赖库”和“vibecoded 漏洞”
AI 驱动的制品扫描、依赖审计和许可分析
“AI SRE”正式归类为产品类别

传统云原生已关注安全和 SRE，但现在需面对模型权重、数据集、向量库、Agent 工作流等新资产。AI Native 平台工程需同时回答：

代码和依赖是否安全
模型和数据是否可信
Agent 行为是否可控

这将推动 Policy-as-Code、MCP、Graph 权限系统与 AI 深度集成。

关键变化五：开源参与从“加分项”变成“门槛”

大会访谈中，平台工程负责人普遍提到：

招聘更看重候选人在 Kubernetes / 相关项目的上游贡献
参与开源显著缩短 ramp up 时间
AI Native 新项目（Model Runtime、Agent Runtime、Scheduler）也走开源路线

个人职业发展角度，参与 AI Native 相关开源项目将成为平台工程和 AI Infra 角色的基本要求，而不只是“简历加分项”。

云原生的“下半场”轮廓

下表压缩展示了“下半场”各方向的技术焦点与本质差异。

该表总结了 AI Native 平台工程的关键坐标。

方向	技术焦点	与上半场的本质差异
AI Native 平台	Model/Agent 一等公民，统一抽象与治理	对象从服务转向模型和推理
资源调度	DRA、异构算力、拓扑感知、功耗与成本	从静态配额转向动态、策略驱动
运行时	容器 + WASM + Nix + Agent Runtime	从“进程容器化”到“执行图容器化”
平台工程	IDP + AI SRE + 安全 + 成本 + 合规	从工具拼盘转向“自治平台”
安全与供应链	LLM 依赖、模型权重、数据集、向量库的全链路治理	守护对象从镜像扩大为“所有 AI 工程资产”
开源与生态	AI Infra / Model Runtime / Agent Runtime 上游协作	不只是“用开源”，而是“在开源里造未来”

表 3: 云原生下半场技术坐标

总结

过去十年，云原生完成了从容器编排到平台工程 1.0 的演化。以 KubeCon NA 2025 为节点，行业系统性地将 AI 引入云原生技术与组织栈：

Kubernetes 不再只是“跑微服务的基础设施”，而是“AI 工作负载的运行时”
Platform Engineering 不再只是“整合工具”，而是“为模型和 Agent 提供自治平台”
安全、SRE、运行时、调度、网络，都将在 AI 驱动下重构

对我而言，过去十年关注“如何让应用在云原生世界里更稳”，未来十年则聚焦“如何让 AI 在云原生世界里更好、更安全、更可控”。这就是我眼中，云原生“下半场”的开场哨。

NotebookLM：我目前最常用、也最愿意推荐的 AI 学习与内容组织工具

Jimmy Song — Mon, 17 Nov 2025 08:44:45 +0000

NotebookLM 是我迄今用过最贴合知识工作者需求的 AI 工具，它真正帮我把庞杂信息结构化，极大提升了学习和内容创作效率。

作为一个长期学习主义者、读技术规范、研究开源项目的人，我一直在寻找一种工具，能在我面对海量资料时替我“抄近道”、减少机械性阅读、帮我快速建立全局理解。NotebookLM 是过去一年里我用下来体验最顺滑、也最稳定可靠的一个。

它不是传统意义上的“聊天式 AI 工具”，更像是一个能把你的资料吃进去、组织出来、再以各种结构化方式呈现给你的 AI 原生学习与内容组织系统。越用越觉得，它对我学习新技术、理解陌生领域、整理大项目文档、构建教学材料的帮助，是其他通用大语言模型（LLM）给不了的。

NotebookLM 给我带来的核心价值

NotebookLM 在实际使用中为我带来了多方面的提升，尤其是在学习新技术、整理文档和内容创作方面表现突出。

快速理解陌生技术：把庞杂资料丢进去，它帮我生成“可学的版本”

我最常用、也是最离不开的场景，就是学习一个我完全不熟悉的技术或开发框架。面对几十页甚至几百页的文档，我通常的做法是：

把官方文档、README、设计文档、架构草图全部加入一个 Notebook
让 NotebookLM 帮我生成：
- 学习指南
- 简报
- 关键知识点
- FAQ
- Quiz
最终得到一个结构清晰的“学习入口”，而不是一场资料洪水。

下面这张流程图展示了 NotebookLM 如何将复杂文档压缩为可学习的结构：

图 5: NotebookLM 文档结构化流程

最终我获得的是一个“整理好的知识体系”，而不是一堆等我啃的 PDF。

生成 MindMap：大量文档瞬间变成结构化知识图谱

我很依赖 MindMap 来构建“知识的骨架”。NotebookLM 的 MindMap 最大的优势有：

自动识别主题间的关联
可以交互式展开或折叠节点
支持多来源文档综合生成

虽然目前只能导出 PNG，但逻辑结构本身已经是非常好的“知识压缩”。

下表对比了不同工具的自动生成能力和可视化效果：

工具	自动生成能力	多文档整合	可视化质量	导出格式
NotebookLM	强	强	好	仅 PNG（暂不支持 SVG）
常见 LLM 工具	较弱	较弱	弱	视工具而定
思维导图软件（手工）	无	无	强	全支持

表 7: 主流工具 MindMap 能力对比

NotebookLM 最大的优势是自动性。

生成教学大纲、培训稿、图书结构：真正节约我大量时间

NotebookLM 不只是“总结”，它能按我给的提示词帮我生成正式的教学结构。只要把项目文档、API 说明、架构设计、案例、视频、博客全都丢进去，让它按提示词生成：

教学大纲
项目培训手册
课程结构
图书章节架构
幻灯片文本
培训案例说明

对于需要写内容、做培训、做演讲的大部分人而言，这个功能非常省心。

下面是我真实在用的典型提示词示例：

根据提供的内容摘录，编写一份详细的培训手册，系统地阐述通过提供内容中所涉及的核心原则。手册应采用专业和指导性的语气，将复杂的概念分解为可行的步骤和课程。确保内容完全基于源材料，涵盖从所提供内容涉及的所有方面。

培训手册应包括以下内容：
1. 培训目标和预期成果
2. 培训内容和结构
3. 培训方法和工具
4. 培训评估和反馈
5. 培训总结和后续行动
6. 培训案例和实例
7. 培训资源和参考文献

实际效果往往出奇地好。

多格式输入能力：这是我见过最稳的

NotebookLM 支持直接 ingest 各种资料类型，解析能力非常稳定。下表是我的实际体验总结：

输入类型	我的实际使用体验
PDF	最稳，解析结构清晰
Google Docs	更新即同步，非常顺滑
Word / PPT	可正常识别
YouTube 视频	自动总结 + 提取关键内容，很好用
网站 URL	视网站结构，成功率高
纯文本	没问题
图片	部分成功，但足够应对截图内容

表 8: NotebookLM 多格式输入体验

相比之下，其他工具经常出现格式解析问题、乱码、丢内容、跳段落的问题。NotebookLM 在“多格式 ingest”这一点上体验特别稳定。

我目前最常用的 NotebookLM 工作流

下面这张流程图展示了我每天实际使用 NotebookLM 的工作流：

图 6: NotebookLM 日常工作流

其本质就是：让 AI 先帮我抓全局 → 再帮我深入 → 再帮我输出内容。

我遇到的小遗憾与建议

NotebookLM 已经很好用，但我仍有一些强烈期待的改进方向：

MindMap 的导出格式应该支持 SVG 或基于文本（Markmap）

目前只能 PNG，放大容易糊。下表是我对未来功能的期待：

期待功能	用途
SVG 导出	用于写书、做幻灯片、可放大不失真
Markmap 输出	对写 Markdown 的开发者最友好
原始 JSON	允许自行做二次渲染

表 9: MindMap 导出格式期待

我非常期待 NotebookLM 支持 Markmap 格式导出，这对习惯用 Markdown 写博客和文档的用户来说极为友好。

最近 Google 还推出了类似 DeepWiki 的 CodeWiki，可为 GitHub 项目自动生成带图片的 Wiki，但目前也未支持 Mermaid 或 Markmap。

对话记录应该支持长期保存

现在的体验是：

聊天不会持续保存
只有手动“加入笔记”才能留存结果

这导致一些知识背景容易丢失，期待未来推出“Notebook 对话历史”功能。

幻灯片生产能力如果能支持模板，会更适合作为创作者工具

目前 Video Overview 的视觉风格虽然多，但无法：

上传自己的 PPT 模板
套用企业/个人品牌模版

如果未来能开放 PPT 模板能力，NotebookLM 会直接成为内容创作者的“视频生成中枢”。

Deep Research 早日上线并全面开放

我特别期待这个功能，因为它可能会让 NotebookLM 从“知识整理工具”升级为“研究级工具”。期待它能做到：

稳定地抓取更多公开网页
保证引用质量
能和 Notebook 原有资料结合

这是我个人非常关注的大升级。

移动端希望尽快增强，而不是只提供播放内容

当前移动端体验极简，只能：

听音频
查看 Notebook Guide 的摘要
简单的问答

期待移动端早日支持：

编辑 Notebook
深度对话
MindMap 交互
内容输出能力（生成文档、大纲等）

总结

NotebookLM 是我目前真正意义上“每天都在用”的 AI 工具之一，因为它做到了一件关键的事情：

把信息组织好，把知识结构化，让我不用从零开始面对庞杂文档。

无论是：

学习新技术
阅读长文档
做课程
做培训
写书
做演讲稿
做内容总结

它都能在最前期帮我节省大量时间，把注意力集中在“理解”和“创作”本身。

我会继续把 NotebookLM 作为我的重要工具之一，也会在未来继续观察它的 Deep Research、模板系统与移动端的进展。

这是一款真正贴近“知识工作者”需求的工具，也值得被更多人认识。

Helm v4：交付范式收敛与插件体系重建

Jimmy Song — Fri, 14 Nov 2025 11:06:46 +0000

Helm 4 的发布不仅是技术升级，更是云原生交付范式的深度收敛。插件体系重建与供应链治理能力，让 Helm 再次成为 Kubernetes 生态的核心驱动力。

Helm 从 2016 年第一次发布起，一直是 Kubernetes 生态最重要的应用分发工具之一。Helm v4 不是一次“小版本增强”，而是一次围绕 交付方式、扩展方式、供应链方式 的全面更新。

本文重建 Helm 的历史脉络，并聚焦 Helm 4 为什么构成一次范式收敛式的发布。

Helm：从 Tiller 到声明式交付

下方为文字描述的时间线，展示了 Helm 从 v2 到 v4 的关键演进节点，便于理解其技术路线变化：

2016：Helm v2 发布，采用 Tiller 架构。
2017：Chart Hub 扩张，大型项目开始提供官方 Chart。
2018：安全模型争议加剧，Tiller 的权限问题变得明显。
2019：Helm v3 发布，移除 Tiller，开始支持 OCI。
2021：GitOps 普及，Server-Side Apply（SSA）成为主流的交付语义基础。
2023：kstatus 被广泛用于控制器的状态判断与健康计算。
2025：Helm v4 发布，带来 SSA、WASM 插件、可重现构建与内容哈希缓存等特性。

Helm 的每一次大版本都紧跟 Kubernetes 主流范式，推动了声明式交付和生态工具的进步。

Helm v4 带来的根本性变化

本节详细解析 Helm v4 的核心技术升级与范式转变。

交付范式更新：默认 Server-Side Apply（SSA, Server-Side Apply）

在 Helm v3 及之前，Helm 采用“三方合并（3-way merge）”模型进行资源交付。而 Helm v4 则全面切换为 Server-Side Apply（SSA, Server-Side Apply），即由 API Server 决定字段所有权。

这种转变带来以下直接结果：

与 kubectl apply 及 GitOps 控制器（如 Argo、Flux）语义完全统一
多控制器共管同一对象时，避免 silent override，冲突可解释
Helm 行为正式进入 Kubernetes 官方推荐的声明式交付范式

下方流程图对比了 Helm v3 与 v4 的交付语义差异。

图 3: Helm v3/v4 交付语义对比

Helm 终于与当代 Kubernetes 版本的交付语义对齐，提升了资源管理的可预测性与安全性。

kstatus 驱动的 wait 行为与 readiness 注解

在 Helm 3 中，--wait 仅能对有限资源做模糊状态判断，缺乏扩展性和可解释性。

Helm 4 引入了 kstatus（Kubernetes Status） 作为健康状态解析基础，并支持两个关键注解：

helm.sh/readiness-success
helm.sh/readiness-failure

Chart 作者可精确定义安装成功或失败的条件，Helm 的等待模型首次具备“可解释性 + 可扩展性”，从“模板工具”升级为真正的“部署编排器”。

扩展体系重建：WASM 插件系统

Helm 4 对插件模型进行了彻底重构，主要包括：

插件类型化与结构化

不再允许随意脚本，插件需遵循类型化、结构化标准

WebAssembly 插件运行时（Extism）

更安全（沙箱隔离）
跨语言支持
易于在 CI/CD、企业平台中统一管控
可预测、可测试

Post-renderer 纳入插件体系

摆脱“external executable 黑盒”时代
Helm 成为可编程平台，而非简单模板渲染器

工程化能力升级：可重现构建、内容哈希缓存、chart API v3

Helm v4 在工程化能力上有以下提升：

Chart 打包可重现（支持签名、SBOM、SLSA 等供应链治理）
本地缓存采用内容哈希，避免 version-based 冲突
chart API v3（实验性）更严格、更灵活
SDK 日志体系升级为 Go slog（现代化 logging）

这些能力让 Helm chart 能正式进入严肃的软件供应链治理体系。

功能差异对照（Helm v3 → v4）

下表对比了 Helm v3 与 v4 在核心领域的功能差异，便于快速理解升级价值。

领域	Helm 3	Helm 4
Apply 模型	三方合并	默认 SSA
Wait 行为	模糊、不可扩展	kstatus + 注解
插件体系	脚本、不可控	WASM、插件类型化
Post-renderer	外部可执行	插件化子系统
构建	不可重现	可重现构建
缓存	name/version	内容哈希
Chart API	v2	v2 + v3（实验）
SDK Logs	标准库 log	slog

表 3: Helm v3 与 v4 功能差异对照

这是 Helm 一次“技术债集中偿还 + 对齐 Kubernetes 当代语义”的发布。

为什么 Helm v4 是范式收敛事件？

Helm v4 的发布不仅是功能升级，更是交付范式的深度收敛，主要体现在以下三方面：

Kubernetes 交付语义统一到 SSA

过去：kubectl、GitOps、Helm 各自有一套逻辑。现在：全部统一到 SSA，交付行为一致，生态协同更顺畅。

插件体系进入平台时代

WASM（WebAssembly）带来安全、通用、可控的插件运行时。基础设施项目普遍采用 WASM：Envoy → WASM Filters，Kubernetes → WASM CRI/OCI，Helm 也正式加入平台化阵营。

chart 进入供应链治理体系

可重现构建与 Digest 校验，让 Helm chart 能像镜像一样被严肃管理，供应链安全能力全面提升。

整个生态进入同一种能力基线，推动云原生交付标准化。

我的 Helm 历史与观察

作为 Helm v2 时代的早期用户，我经历了如下阶段：

Tiller 安全争议
v3 大迁移（state 存储于 secret）
社区 chart 大规模收敛
OCI 化
今日的 SSA / WASM / reproducible build

Helm 每一次大版本升级都不是追逐热点，而是主动对齐 Kubernetes 主流范式：

v3 对齐 K8s“无 cluster-side runtime”原则
v4 对齐 SSA、kstatus、WASM、OCI 等近五年技术进步

Helm 是最典型的基础设施项目演进节奏：不是靠堆功能，而是靠与平台一致的语义演进。

总结

Helm v4 的发布标志着 Kubernetes 应用交付进入新范式。SSA、WASM 插件、kstatus、可重现构建等能力，让 Helm 不仅是模板工具，更是供应链治理与平台化扩展的核心。对于云原生开发者和平台团队而言，Helm v4 是一次值得关注的范式升级。

参考文献

Kimi K2 Thinking：国产思维型大模型的真正觉醒

Jimmy Song — Fri, 14 Nov 2025 08:25:26 +0000

国产大模型终于从“写得像人”迈向“想得像人”，Kimi K2 的开源是中国 AI 路线的分水岭。

国产大模型的叙事正在从“Chat 型模型”，转向“思维型模型（Thinking Model, Thinking Model）”。

Moonshot AI 开源的 Kimi K2 Thinking 标志着这场转折第一次真正落地。K2 并不是又一个 ChatGLM/Qwen 式的迭代，而是中国团队首次完成了“深度推理 + 长上下文 + 工具调用连续性”三者的统一训练。这也是思维模型路线的核心，正是过去 Claude、Gemini 领先的原因。

K2 开源的意义：国产模型进入思维型时代

K2 的开源为何成为拐点？因为它首次让国产模型具备了以下能力：

稳定执行 200–300 次工具调用（工具链推理稳定性）
深度、多阶段推理链连续执行（CoT Consistency, Chain-of-Thought Consistency）
256k 上下文作为“思维缓冲区”（Working Memory, Working Memory）
原生 INT4 加速 + MoE 激活稀疏度调度

这是一条完全不同于“堆参数 → 堆 benchmark”的路线，强调推理能力而非参数规模。

一句话总结：

K2 是国产模型第一次进入思维型模型（Thinking Model, Thinking Model）序列。

K2 的技术路线拆解

K2 的技术路线可以拆解为五个关键点，每一点都直接影响模型的推理能力和生态适配性。

MoE 专家分工：认知分工而非参数扩展

K2 的 MoE（Mixture of Experts, Mixture of Experts）设计理念与以往不同。其核心不是激活更少的参数或更便宜地跑更大模型，而是将不同认知子技能分配给不同专家。例如：

数学推理专家
规划专家
工具调用专家
浏览器任务专家
代码生成专家
长链路保持专家

这种分工方式直接对齐了 Claude 3.5 的认知分层（Cognitive Layering, Cognitive Layering）路线。K2 的 MoE 是“让模型分工思考”，而不是“让模型便宜计算”。

256K 上下文：打造模型的工作记忆

K2 的超长上下文不仅仅是参数炫技，更是用于构建模型的“思维缓冲区”。它允许全过程保留推理链、工具调用状态、多阶段反思，以及长任务（如科研、代码 refactor）不中断，稳定执行多阶段 Agent 流程。长期思考需要长期记忆支持，K2 的长上下文就是为持续推理链打造的“内存”。

工具调用与推理链交织训练

K2 在工具调用与推理链交织训练方面表现突出。传统开源模型通常是：

生成推理
输出 JSON 函数调用
工具返回结果
再继续推理

这种方式下，推理链与调用链是分离的。而 K2 的训练方式则允许推理链随时调用工具，并将工具结果塞回推理链，进入下一阶段思考。支持 200–300 步连续工具调用不中断，与 Claude 3.5 的 Interleaved CoT + Tool Use 完全一致。

INT4 原生量化：保障推理链稳定性

K2 的 INT4（INT4, 4-bit Integer Quantization）路线不是普通的后量化。其目的不仅是降低显存、提高吞吐，更重要的是确保深度推理链不会因算力不足而中断。深度思维链的最大杀手是超时、冻结、Worker 不稳定。INT4 让国产 GPU（非 H100）也能跑完整推理链，这对国产生态意义重大。

MoE + 长上下文 + 工具链：统一训练而非模块拼接

K2 最重要的特性是整体训练路线：专家分工、长上下文驱动一致性、工具调用通过真实执行训练、浏览器任务与长步骤任务强化、INT4 进入训练闭环。它不是“ChatLLM + Memory + RAG + Tools”的拼贴式路线，而是一体化推理系统。

K2 与国际主流路线的对齐与差异

K2 与国际主流模型（如 Claude、Gemini、OpenAI）在认知推理、超长上下文、工具调用机制等方面高度对齐，但也有国产模型的独特优势：

原生 INT4 + 国产算力适配路线全球少见
工具链连续性比大多数开源模型更稳定
开源程度更高，生态可复用性更强

国产 AI Infra 的协同价值：K2 × RLinf × Mem-alpha

K2 生态中还出现了一系列重要开源基础设施。下表总结了这些项目类型及其对 K2 的价值：

这是各基础设施与 K2 协同价值的对比表：

项目	类型	对 K2 的价值
RLinf	强化学习训练系统	用于训练更强的规划/浏览器任务能力
Mem-alpha	记忆增强框架	可与 K2 结合形成长期记忆 Agent
AgentDebug	Agent 错误调试系统	用于分析 K2 的 toolchain 错误
UI-Genie	GUI Agent 训练系统	可作为 K2 的 Agent 能力扩展实验场

表 3: 国产 AI Infra 生态协同价值

这套组合已经隐约构成了一个国产 AI Agent Infra Stack。

个人观点：K2 的路线意义

我认为 K2 的意义不在模型本身，而在于其技术路线：

K2 标志着国产模型第一次从“语言生成竞争”，进入“思维能力竞争”。

过去三年，中国开源模型的主线是评测得分、参数规模、指令跟随、对齐数据。但 K2 是第一个明确走上深度推理、工具交织、认知分工、长期任务链、原生性能优化的路线。这代表中国模型路线开始与美国同步，而不是追赶旧路线。

未来一年值得关注的 K2 生态发展方向

K2 未来生态影响力将取决于以下几个关键点：

是否开放工具注册表（Tool Registry, Tool Registry）
是否支持动态记忆（Mem-alpha 融合）
是否开放 MoE 专家结构
是否能与 vLLM / llm-d / KServe 形成国产推理链优化路线
是否有针对多节点的连续推理链容错

这些能力将决定 K2 的生态影响力和技术扩展性。

K2 思维路线架构图

下方流程图展示了 K2 思维模型的核心架构及其与外部 Agent/应用的协同关系：

图 3: K2 思维路线架构图

结语

K2 是国产模型路线第一次走在正确方向：

从“写得像人”到“想得像人”。

思维型模型时代正在到来，国产模型首次站在了国际前沿的同一条路线图上。

参考文献

TRAE SOLO vs VS Code：从“AI 工程实体”视角重新审视编程工具

Jimmy Song — Fri, 14 Nov 2025 07:14:39 +0000

编程工具正在从“辅助型 AI”进化为真正的工程实体，如何用流水线视角重新理解 TRAE SOLO 与 VS Code 的定位？

最近 TRAE 国际版 SOLO 模式全面向海外用户开放，据称是“响应式编码 Agent”，并且已经对国际用户开放正式版试用，只是按 Token 做了限流。

我之前就用过 TRAE 的早期版本（没有 SOLO 资格），也试过 Qoder 和 Kiro，在 AI Coding 领域可以说是百花齐放，各有千秋。

现在多了 GitHub 在 Universe 上抛出的 Agent HQ 概念，以及我在《AI 原生应用架构》里写的“AI 作为工程实体（AI Engineering Entity, AIEE）”框架，把这些东西放在一起，其实可以重新梳理一遍今天的编程工具格局。

本文将用“AI 工程实体”视角，对比 TRAE SOLO 和 VS Code（带 Copilot、Plan/Agent 模式和 Agent HQ），并结合个人使用体验，梳理两者在工程自动化、协作与治理上的差异。

三个工程角色抽象：端到端执行体、上下文协作体与专业决策体

在工程视角下，可以用三类角色来抽象当前主流 AI 编程工具：

端到端执行体（End-to-End Executor）：

面向“从需求到上线”的端到端工作流，具备自主规划、拆任务、写代码、跑测试、预览甚至部署的能力，官方称其为“AI-Powered Context Engineer”。
用户体验上，它像一个“整链路包办式执行体”：你给需求，它真按项目干，哪怕慢一点、蠢一点。

上下文协作体（Contextual Collaborator）：

VS Code 是强大的编辑器，Copilot 从行级补全升级到 Chat、Plan agent、Agent mode，支持多步任务、代码库分析、计划执行。
它不主动接管整个项目，而是在你主导下高效完成局部环节，灵活处理模糊任务，更像局部工段的自动化单元。

专业决策体（Expert Orchestrator / Specialist Engine）：

GitHub 的 Agent HQ 是“AI 编码 Agent 的中枢平台”，统一控制平面，可接入 OpenAI、Anthropic、Google、xAI 等多家 Agent，并行跑、对比结果。
更像“关键步骤的专业决策体”，主导规划、审查、重构或决策，不主动接管项目，但在关键环节提供高质量输出。

这三者对应了《AI 作为工程实体（AIEE, AI Engineering Entity）》里的结构：

单一端到端执行体（TRAE SOLO）；
IDE 驻留的上下文协作体（VS Code + Copilot）；
多实体调度的专业决策体平台（Agent HQ）。

产品现状快速校对

为避免记忆偏差，先梳理几个关键事实点。

TRAE / TRAE SOLO

TRAE 宣称“10x AI Engineer”，可独立理解需求、执行开发任务。
SOLO 模式对国际用户已 GA，强调全链路自动化，国际站用户可直接使用，但有 Token 限制。
底层有开源 Trae Agent CLI，可在真实代码库里执行多步工程任务。
TraeIDE 官方页面显示已内置 Claude 3.5/3.7、DeepSeek 等模型，但社区普遍反馈新模型接入节奏偏慢，如 Claude Sonnet 4.5 等更新跟进滞后。

因此，“TRAE 不支持 Claude”这一说法目前已不准确，至少在 TraeIDE 官方层面，Claude 系列已成为内置模型之一。实际 SOLO 模式用到哪颗模型、是否暴露给用户，目前仍不透明，体验有待提升。

VS Code + Copilot + Agent HQ

Copilot 在 VS Code 已进化出 Chat、Plan agent、Todo/多步任务执行能力：
- Plan 模式可分析代码库、生成执行计划、拆分 Todo，再交由实现 Agent 逐步执行。
- Agent mode 在 VS Code 中提供更自动化的“多步同伴程序员”体验。
GitHub 在 2025 Universe 推出 Agent HQ 平台，将 Copilot 与第三方 Agent（Anthropic、OpenAI、Google、xAI、Cognition 等）统一纳入控制平面，支持并行运行、结果对比。

简而言之：

TRAE 更像“把一个工程实体塞进 IDE”；
VS Code + Copilot 更像“在成熟 IDE 上增加一组工程实体”；
Agent HQ 则定位为“多工程实体总部”。

用“AI 工程实体”框架重构对比维度

在《AI 作为工程实体（AIEE, AI Engineering Entity）》中，定义如下：

AI 从编辑器里的自动补全，变成“软件供应链中的正式节点”，可接收任务、产出可审查工件（PR/diff/报告）、通过测试/门禁、失败时被替换。它不再只是“增强的人类开发者”，而是流水线中的“工程功能单元”。

基于此，可重构 TRAE 和 VS Code 的关键对比维度：

是否作为“独立职责单元”存在
能否从自然语言需求出发，自主规划、实施、产出 PR/报告，而不依赖人类持续介入。
上下文建模能力
能否跨文件、跨目录、结合终端输出、浏览器内容，形成稳定的工程上下文。
在流水线中的位置
是 IDE 内的一层增强，还是 CI/CD、代码审查流程中的正式节点。
可审查和可替换性
产出的工件是否标准化（PR、diff、报告），可纳入常规流水线审查和回滚。
多主体协作能力
是否天然支持“多 Agent 协作”，还是单 Agent 强化。

TRAE SOLO vs VS Code：工程实体差异表

下表总结了两者在工程实体视角下的主要差异。表格前补充说明：VS Code 默认包含 Copilot Chat + Plan/Agent 模式，并可挂载 Agent HQ 生态。

你可以将此表理解为：“如果把 AI 当工程实体放进流水线，TRAE 和 VS Code 各自扮演什么角色？”

表格内容如下：

维度	TRAE SOLO	VS Code + Copilot / Agent
工程角色	单一强工程实体，直接承接“从想法到上线”的端到端任务	IDE + 多类工程实体（Plan、实现、审查），本身更像工程基座
任务粒度	项目级 / 功能级：从 PRD 风格描述到完整项目 scaffold、实现、测试、预览	函数级 / 文件级为主，Plan 模式可提升到特性级/子系统级
上下文建模	强调“上下文工程”：读代码库、终端输出、浏览器内容，作为统一上下文输入 SOLO	以代码库为主，Plan Agent 根据代码分析生成计划，Agent mode 按计划调度
自动执行能力	可以主动改文件、跑命令、跑测试、起本地服务，形成完整循环	Plan/Agent 可运行命令、修改文件、跑测试，但默认更依附在你当前项目和工作流里
人类介入位置	更偏“事后审查”：让它先跑出版本，再整体审阅、微调	更偏“过程中协同”：你频繁介入计划、实现和 review，每步都有控制点
产物形式	代码改动、测试结果、运行预览，部分场景产出 PR/文档	代码补全、重构、PR 评论、CodeQL 报告、Plan/Todo 列表
多 Agent 能力	核心是 SOLO 这个大 Agent，其他能力（如 Trae Agent CLI）更多是扩展	Copilot 自身就是一类 Agent，Agent HQ 允许接入多家 Agent 并行竞赛
模型透明度	产品内对具体模型暴露不充分，用户难以知道当前使用哪颗模型	GitHub 明确标出 Copilot 背后模型族群，Agent HQ 还会直接表明 Agent 来源
性能体验	自动化强，但速度偏慢，遇到复杂项目容易卡在“思考阶段”；Token 限制存在硬上限	在熟悉项目里响应速度相对稳定，多数场景只做局部修改，整体延迟可控
隐私与合规	官方和第三方测评都提到存在广泛遥测和数据收集，企业落地需额外评估	企业版 Copilot 有明确的数据隔离和合规说明，适配大部分企业治理要求

表 3: TRAE SOLO 与 VS Code 工程实体差异对比

从表中可以看出：

你想要“一个能从需求到上线负责到底的 AI 工程实体”，TRAE SOLO 更像是那个角色。
你想要“一个稳定的工程基座 + 一堆可插拔的工程实体”，VS Code + Copilot + Agent HQ 更符合这个框架。

工作流对比：两个工程实体流水线

为便于理解两者的工程流程，下面用流程图展示 TRAE SOLO 与 VS Code 的典型工作流。

图 3: TRAE SOLO 与 VS Code 工程实体流水线对比

该流程图展示了两种典型协作模式：

TRAE SOLO 试图将“上下文聚合 → 规划 → 实现 → 测试 → 预览/部署”全部包裹在同一个工程实体里，用户只在需求输入和产物审查两个环节介入。
VS Code + Copilot + Agent HQ 则以 IDE 为运行时，Plan/Implementation/Review agent 分别对应不同工程实体角色，Agent HQ 支持多 Agent 并行竞赛，开发者可挑选最优方案。

模型透明度、速度与“可预期性”

结合个人体验，工程实体视角下的模型透明度与速度问题如下：

模型透明度

TRAE 当前产品层面对“调用哪颗模型”暴露有限，切换 MAX 模式仅能推测“用了更强模型或更高配额”，但无明确反馈。
社区长期反馈新模型接入慢，部分强模型（如 Claude 系列）在其他平台可用，TRAE 内尚未同步。

这意味着：

TRAE 难以作为“可精确配置的工程单元”，更像黑盒，难以在 CI/CD 或生产流水线中做模型变更管理。
VS Code + Copilot + Agent HQ 在标准化上更强，GitHub 明确标注 Copilot 背后模型家族，Agent HQ 直接以 Agent 来源为抽象边界。

速度与可预期性

TRAE SOLO 的“慢”主要源于执行更多步骤（读文件、分析、规划、测试），以及工程流程可视化不足，UI 上表现为“Thinking…”等提示，难以判断是卡死还是规划。
VS Code 的 Plan 模式会显式列出计划和 Todo 列表，Agent mode 强调“按计划执行”，用户能清晰看到工程实体的工作状态，提升了可预期性。

Agent HQ 的定位：单实体 vs 多实体总部

从平台视角看，GitHub 和 TRAE 的路线差异如下：

Agent HQ 的核心思路是：未来开发将依赖多个专长不同的 Agent 并行协作，GitHub 做的是“Agent 总部”，而非唯一工程 Agent，开发者可在统一控制平面调度 Agent，接入现有 GitHub Flow（Issue、PR、Review、CI/CD）。
TRAE 更像“自有 IDE + Agent + 上下文工程全栈”，交付一体化体验。

工程实体组织形式上：

GitHub 在做“多主体工程体系的基础设施和治理”；
TRAE 在做“垂直整合的工程实体 + 私有运行时”。

两者并不互斥，分别对应“广义平台 + 多实体调度”与“单一强实体 + 自有工具链”。

主观体验与工程框架融合

将个人主观体验转化为工程语言，总结如下：

VS Code 更习惯“一个 IDE + 多种视图”的单模式体验，TRAE 拆分 IDE 模式和 SOLO 模式，需心智切换。
TRAE 工程实体能力强于普通补全工具，能揽活，但模型不透明、上下文质量不稳定，治理能力尚待完善。
VS Code 不主动接管整个项目，但局部工作稳定，Plan、Agent、Review 组合可实现多主体协作。

结合《AI 作为工程实体（AIEE）》框架：

TRAE SOLO 是一个 已经能承担完整工程任务的单一 AI 工程实体（AIEE, AI Engineering Entity），但在模型透明度、工程治理和企业级可控性上仍有明显短板。
VS Code + Copilot + Agent HQ 是一个 面向多工程实体的基础设施平台，短期内在“端到端代工”上不如 TRAE 激进，但在工程一致性、模型可替换性和组织级治理上路径更清晰。

总结

本文以“AI 工程实体”视角，系统对比了 TRAE SOLO 与 VS Code（含 Copilot、Agent HQ）在自动化、协作、模型透明度等方面的差异。TRAE SOLO 更适合追求端到端自动化的个人开发者或小团队，而 VS Code + Copilot + Agent HQ 则为多主体协作、企业级治理和工程一致性提供了更强基础设施。未来，AI 工程实体将成为软件开发流水线中的正式节点，工具选择需结合自身工程需求与治理要求。

Jimmy Song – 博客

写在 HAMi 晋升 CNCF Incubating 之后：AI 时代，开源社区正在从代码共同体走向共识网络

HAMi 的成长数据说明：开源项目真正的资产是社区

2021 年 HAMi 开源的时候，还没有 AI Coding

AI 时代，代码不稀缺了，稀缺的是共识

AI 时代，开源治理本身也要升级

CNCF Incubating 的真正意义

总结

Olares 与 HAMi：我看到的端侧 AI 工作站新拐点

一个老朋友提到一个名字

这东西到底是个啥

跟一堆 AI 小主机的区别

把一整个云的运行时塞进单机

一个挺有意思的细节

HAMi 在里面到底干了啥

为啥我觉得这事对 HAMi 挺重要

端侧 AI 会往哪走

总结

参考文献

每个民族都从纺织开始

引言

一次文化的对照

纺织为什么是工业化的起点

后发国家都从这条路上来

中国走在这条路的哪一段

一条没有断的线

总结

为什么 GPU 成了 AI 时代的基石？给 K8s 老兵的 GPU 科普

写在前面：一个云原生老兵，为什么来写 GPU

先把黑话翻译成 K8s

一个大多数人懒得问的问题

两种计算哲学：工匠与工厂

AI 为什么打爆了 CPU

GPU 内部三件套，用 K8s 的话讲

1. Tensor Core：只会批量乘法的 sidecar

2. HBM：节点的高速本地内存

3. Transformer + Token：逐字吐回答的程序

训练 vs 推理：写菜谱 vs 上菜

多 GPU 协作：AI 集群就是一个分布式系统

K8s 跑 GPU：训练用 Slurm，推理用 K8s

推理的真正大坑：KV Cache

GPU 利用率会撒谎

为什么 NVIDIA 这么难撼动

未来：AI 工厂

别急着淘汰 CPU：Agentic AI 正在重塑 CPU:GPU 比例

这和我（一个 K8s 老兵）有什么关系

这只是上半场：NVIDIA 之外，牌桌上还有谁

参考资料

GPU 利用率正在“失灵”：AI 基础设施需要重新定义效率

我们一直在追求 GPU 利用率

GPU Busy 不等于 Productive

GPU 利用率的“幻觉”

HAMi 解决了什么

HAMi 之后，我们还缺什么

下一代 AI 基础设施该优化什么

从 Utilization 到 Productive GPU-Hours

致谢与参考

当 Agent 成为长期运行的分布式状态机：解读 Agentic AI 基础设施可靠性

写在前面：为什么我要专门聊这篇论文

一句话总结

传统 AI 与 Agentic AI 的根本分野

核心贡献：Agent 可靠性五维框架

把 Agent 当作“有状态服务”

容错：Agent 系统的“黄金组合”

恢复机制：把传统灾备思想搬到 Agent

Agent 可观测性 = 基础设施指标 + 行为分析

推荐的混合架构（Hybrid Architecture）

从 AI Infra 视角看这篇论文最大的价值

总结

参考资料

从 GPU 到 Token：AI 基础设施的八层可观测性体系

八层可观测性架构概览

L1 GPU 硬件层

L2 CUDA 运行时与通信层

L3 宿主机与操作系统层

L4 Kubernetes 与调度层

L5 训练运行时层

L6 推理引擎层

为什么 KV Cache 比 GPU Utilization 更重要

L7 生成式 AI API 层