Jimmy Song – 博客

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”

表 1: 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 上的核心分层与流量路径：

图 1: 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 OSS 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 库，而是完整的运行时平台。

图 1: ARK Dashboard

注意：本文中提到的 ARK 指的是麦肯锡开源的 ARK Agent Runtime for Kubernetes。

本文将以工程师视角，重新梳理 ARK 的核心能力，解答如下问题：

ARK 到底解决了哪些工程难题？
为什么它值得云原生领域重点关注？
它与 LangChain、CrewAI 等框架有何本质差异？
对 Agentic Runtime 生态有哪些启示？

ARK 的基础架构：将 Agent 作为 Kubernetes 原生工作负载

ARK 的核心思想是：Agent 不是脚本，而是一个可调度、可治理、可观测的 Kubernetes 工作负载（Workload）。

下面这张架构图展示了 ARK 的底层结构。

图 2: 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 的结构关系：

图 3: CRD 结构（简化版）

通过 CRD，ARK 实现了如下工程特性：

所有资源可 GitOps 化，支持声明式管理
变更可审计、可回滚、可持续交付
模型、工具、Agent 的演进无需改动业务代码

这正是 ARK 面向工程体系的关键基因。

Agent 执行链路：从 Query 到工具调用

图 4: 在 ARK Dashboard 中查看 Query 详情

在 ARK 中，一个 Agent 接收到 Query（请求）后的完整执行链路如下：

图 5: Agent 执行流程

该链路具备以下特性：

Memory（记忆模块）在执行链路中天然参与，无需代码特化
大语言模型（LLM）和工具调用由运行时统一治理
Agent 可以长期驻留于 Pod，不是一次性进程

这使得 ARK 更像一个“Agent 微服务平台”。

下面是一个请求的响应事例：

多 Agent 的真正价值：Team Orchestration

ARK 的 Team CRD 允许将多个 Agent 编织成一个高层次的“系统”，实现多智能体协作。

下图展示了多 Agent 团队的协作模式：

图 6: 多 Agent 团队协作

Team 的工程价值体现在：

让“专家协作”变得声明式、可配置
策略灵活（如轮询、角色分配、路由等）
A2A Gateway 负责消息传递
Team 本身具备可观测性（每轮协作均有日志）

对于企业而言，这意味着“Agent 组织结构”可以标准化、可重放、可调优。

ARK 与其它框架的本质差异

许多工程师初见 ARK 时会疑惑：

“它是不是只是把 LangChain 或 CrewAI 用 Kubernetes 包装了一下？”

实际上，二者有本质区别。下图对比了 ARK 与主流 Agent 框架的结构差异：

图 7: 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 系统

表 1: 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 的资源层、执行层

表 1: 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 的思考。

图 1: 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 这种偏“单体可控”的运行时结构更容易沿此方向演进。

图 1: 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 的语义关系：

图 1: Agentic Runtime 语义关系图

架构与社区活跃度

Ark 架构采用标准的控制面（Control Plane）体系，强调运行时语义的统一。其社区活跃度高，工程师主导，代码结构清晰但生产可用性仍在完善。

图 2: 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。下方流程图展示了这些资源之间的关系：

图 1: Ark CRD 资源关系

通过这套 CRD，Ark 将 Agent 系统资源化、声明式化，从而具备了如下能力：

生命周期管理
多租户隔离
RBAC（Role-Based Access Control，基于角色的访问控制）
可观测性
可升级性
可扩展性（工具、模型、MCP）

换句话说，Ark 关注的不是“怎么写 Agent”，而是“怎么在企业级系统里运营 Agent”。

三层架构：语言与组件混搭，但体系完整

Ark 的整体架构分为三层，分别对应不同的技术栈和职责。下方流程图展示了各层组件的关系：

图 2: 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 的控制平面 + 资源化体系	功能尚未成熟

表 1: 主流 Agent 框架与 Ark 对比

简而言之：

其他工具关注“怎么写 Agent”。
Ark 关注“Agent 怎么运行、调度、治理、观测、扩展”。

这就是架构级别的差异。

执行流程：像 Pod 一样被调度的 Agent

Ark 的执行流程非常接近 Kubernetes 控制器模型。下方时序图展示了核心流程：

图 3: Ark Agent 执行流程

可以看到，Ark 的流程逻辑透明，工程路径清晰，让 Agent 系统进入“可控”状态。

生产可用性：方向正确，但仍是技术预览

根据官方标注和源码成熟度，目前 Ark 具备如下特性：

可运行
可学习
可扩展
但暂不建议在生产环境大规模使用

主要原因包括：

CRD 结构可能变动
API 尚不稳定
MCP 生态尚未成型
Memory 服务仍较为简单
多 Agent Team 执行策略较初级

但工程体系已经成型，这一点非常重要。

社区活跃度：小而精，麦肯锡强驱动

图 4: 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 如何将复杂文档压缩为可学习的结构：

图 1: NotebookLM 文档结构化流程

最终我获得的是一个“整理好的知识体系”，而不是一堆等我啃的 PDF。

生成 MindMap：大量文档瞬间变成结构化知识图谱

我很依赖 MindMap 来构建“知识的骨架”。NotebookLM 的 MindMap 最大的优势有：

自动识别主题间的关联
可以交互式展开或折叠节点
支持多来源文档综合生成

虽然目前只能导出 PNG，但逻辑结构本身已经是非常好的“知识压缩”。

下表对比了不同工具的自动生成能力和可视化效果：

工具	自动生成能力	多文档整合	可视化质量	导出格式
NotebookLM	强	强	好	仅 PNG（暂不支持 SVG）
常见 LLM 工具	较弱	较弱	弱	视工具而定
思维导图软件（手工）	无	无	强	全支持

表 1: 主流工具 MindMap 能力对比

NotebookLM 最大的优势是自动性。

生成教学大纲、培训稿、图书结构：真正节约我大量时间

NotebookLM 不只是“总结”，它能按我给的提示词帮我生成正式的教学结构。只要把项目文档、API 说明、架构设计、案例、视频、博客全都丢进去，让它按提示词生成：

教学大纲
项目培训手册
课程结构
图书章节架构
幻灯片文本
培训案例说明

对于需要写内容、做培训、做演讲的大部分人而言，这个功能非常省心。

下面是我真实在用的典型提示词示例：

根据提供的内容摘录，编写一份详细的培训手册，系统地阐述通过提供内容中所涉及的核心原则。手册应采用专业和指导性的语气，将复杂的概念分解为可行的步骤和课程。确保内容完全基于源材料，涵盖从所提供内容涉及的所有方面。

培训手册应包括以下内容：
1. 培训目标和预期成果
2. 培训内容和结构
3. 培训方法和工具
4. 培训评估和反馈
5. 培训总结和后续行动
6. 培训案例和实例
7. 培训资源和参考文献

实际效果往往出奇地好。

多格式输入能力：这是我见过最稳的

NotebookLM 支持直接 ingest 各种资料类型，解析能力非常稳定。下表是我的实际体验总结：

输入类型	我的实际使用体验
PDF	最稳，解析结构清晰
Google Docs	更新即同步，非常顺滑
Word / PPT	可正常识别
YouTube 视频	自动总结 + 提取关键内容，很好用
网站 URL	视网站结构，成功率高
纯文本	没问题
图片	部分成功，但足够应对截图内容

表 2: NotebookLM 多格式输入体验

相比之下，其他工具经常出现格式解析问题、乱码、丢内容、跳段落的问题。NotebookLM 在“多格式 ingest”这一点上体验特别稳定。

我目前最常用的 NotebookLM 工作流

下面这张流程图展示了我每天实际使用 NotebookLM 的工作流：

图 2: NotebookLM 日常工作流

其本质就是：让 AI 先帮我抓全局 → 再帮我深入 → 再帮我输出内容。

我遇到的小遗憾与建议

NotebookLM 已经很好用，但我仍有一些强烈期待的改进方向：

MindMap 的导出格式应该支持 SVG 或基于文本（Markmap）

目前只能 PNG，放大容易糊。下表是我对未来功能的期待：

期待功能	用途
SVG 导出	用于写书、做幻灯片、可放大不失真
Markmap 输出	对写 Markdown 的开发者最友好
原始 JSON	允许自行做二次渲染

表 3: 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 的交付语义差异。

图 1: 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

表 1: 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 能力扩展实验场

表 1: 国产 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/应用的协同关系：

图 1: 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 有明确的数据隔离和合规说明，适配大部分企业治理要求

表 1: TRAE SOLO 与 VS Code 工程实体差异对比

从表中可以看出：

你想要“一个能从需求到上线负责到底的 AI 工程实体”，TRAE SOLO 更像是那个角色。
你想要“一个稳定的工程基座 + 一堆可插拔的工程实体”，VS Code + Copilot + Agent HQ 更符合这个框架。

工作流对比：两个工程实体流水线

为便于理解两者的工程流程，下面用流程图展示 TRAE SOLO 与 VS Code 的典型工作流。

图 1: 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 — Fri, 14 Nov 2025 04:21:07 +0000

闭源模型不断加速，开源生态被动追赶。工程师真正需要关注的，是基础设施和可控性，而不是表面上的“Twin”现象。

最近看到一封邮件，主题是：“Every Big AI Model Now Has an Open-Source Twin”。直译过来，大意是“每一个大厂闭源模型，现在都有一个开源的孪生兄弟”。

从媒体或 VC 的视角，这是一个极其好讲的故事：闭源发布旗舰模型，社区迅速给出开源对标，形成“开源正在追平闭源”的叙事，生态繁荣、创新加速、未来可期。

但站在长期深耕基础设施、云原生（Cloud Native）、基础架构（Infrastructure）的人视角，这样的说法存在几个问题：

它把“节奏同步”讲成了“能力追平”；
它忽略了数据、算力和工程体系这些真正决定上限的因素；
它模糊了一个关键事实：开源整体处于 被动响应状态 ，而不是并行主导。

本文将从工程与基础设施视角，拆解“Open-Source Twin”叙事的成立程度，并分享我个人更关注的核心问题。

从“有 Twin 了”到“要同步响应”：叙事是怎么被改写的

我们先梳理一下现象。

过去两年，行业内反复出现如下模式：

大厂发布闭源旗舰模型（如 GPT-5 系列、Claude 4/4.5、Gemini 2.5 等）。
很快出现一批开源对标（如 Qwen、GLM、Yi、K2 等），在参数规模、Benchmark 指标上做对齐。
媒体和社区开始用“开源 Twin”“平替”“对标款”等词汇传播。

仅看这一层，容易得出乐观结论：开源已经建立了完整的对标能力，闭源再怎么跑，社区都能跟上。

但更关键的问题是：谁在定义节奏，谁在制定玩法，谁在承担真实成本。

目前结构非常清晰：

节奏由闭源大厂定义：决定何时提升推理能力、拉长上下文、推动多模态、推理特化（如 R1 系列）。
开源生态被动启动响应机制：每次闭源升级，都会引导新一轮“开源对标”。

换句话说，现在的模式不是大家并行创新、互相激发，而是闭源在赛道最前面不断换挡、变道，开源在后面不断调档、调整路线，确保自己至少不被甩出视野。

“Every Big AI Model Has an Open-Source Twin”这句话，从工程视角重写，更接近：

Every Big AI Model Now Forces an Open-Source Response.

开源生态现在到底在“同步”什么

理解“同步响应”现象，至少要分三类。

在进入列表之前，先补充背景：闭源旗舰模型每次更新，不只是“参数更多、指标更高”，而是在不断 重写约束条件 ，包括推理成本、交互形态、上下文长度、多模态一致性、推理过程可解释性等。

在这样的背景下，开源要同步的不是单纯的“分数”，而是越来越复杂的 目标函数（Objective Function）。

同步的是能力上限的“想象边界”

闭源模型本质上在扩展“大家觉得一个模型应该能做到什么”的边界，例如：

从纯文本到文本 + 图像 + 音频 + 视频；
从单轮问答到工程级推理、写代码、调试、修复、重构；
从几千 token 上下文到十万级甚至更长；
从“黑箱输出”到具备思维链条、推理轨迹、可校验输出。

开源模型随后会对齐目标：“我们也要长上下文、也要多模态、也要会写代码、也要能跑 agent 工作流。”

同步的是接口与使用形态的“期望值”

终端开发者、企业用户一旦被闭源模型教育过一轮：

交互延迟可以低到什么程度；
上下文可以拉多长而不崩；
多模态输入有多顺滑；
推理过程有多“聪明”；

他们对 任何开源模型 的期待都会被重新标定。

于是开源不得不做几件事：

在推理框架层面不断优化，如 vLLM、SGLang、TGI 等，尽量缩小 latency 差距；
在 Serving 形态上贴近闭源体验，例如兼容 OpenAI API、提供更友好的 SDK；
在多模态、长上下文上强行补课，即便训练成本极高。

同步的是“表面指标”，而不是“完整能力”

从 Benchmark 角度，开源确实可以在一批公开测试集上追到 80%–90%：

MMLU、GSM8K、HumanEval；
常见的推理、阅读理解、代码生成指标。

但这些指标只能反映 表层能力，而不是：

对长尾问题的稳健性；
在复杂、多步骤场景下的稳健性；
在大规模生产系统中的稳定性与可控性；
在长期演进中的“工程健康度”。

这也是我不太认同“Twin”这个词的原因之一：它用一层指标的相似，掩盖了底层结构的巨大差异。

为什么“开源 Twin”听起来很好，实际偏离了核心矛盾

从基础设施和工程角度看，现在的问题从来不是“开源能不能抄到一个差不多的架构出来”，而是：

谁能大规模、可持续地管理数据、算力、调度系统和工程团队，构建长期演化的模型生产流水线。

这里有三个关键矛盾。

数据不可获得，训练 recipe 不可完整复现

开源可以复现大致的网络结构、优化技巧，但拿不到：

闭源的数据来源和清洗标准；
过滤策略、去毒、对齐细节；
大规模合成数据的生成与选优方法。

结果是：就算你把参数堆到类似规模，跑到类似步骤，效果也未必能真正对齐。

很多开源项目事实上只能用更粗糙的数据、更有限的算力预算、更保守的训练策略，逼近一个“可用但并不稳定”的状态。

算力差距是结构性的，不是靠一两次筹资能补上的

训练旗舰模型需要的算力，不是几百张卡、几千张卡的问题，而是 结构性长期投入。

开源阵营里，能接近这个量级的通常有几个特征：

背后依靠大公司或国家级实验室；
资金不是社区捐赠，而是实打实的业务预算；
算力供给可以长期规划，而不是一次性“烧一把”。

现实情况是：

真正有能力做“旗舰级开源模型”的主体，本质上也是“机构”，而不是松散的个人社区；
所谓“开源 Twin”背后，多半是有企业背书、有产品目标、有商业诉求的。

从这个角度讲，“开源 vs 闭源”更像是“多家大厂 vs 几家巨头”，而不是“社区 vs 公司”。

架构“复现”不等于架构“主导”

很多开源模型在架构上看起来跟闭源非常像：

Transformer 变体、MoE 变体；
决策层上做了一些轻微改造；
某些地方加入了一点推理优化。

但从产业力量格局来看，真正推动这些架构走向生产规模、验证可行性的人，还是闭源一侧。开源主要做的是：

验证闭源路线在弱算力上的可行性；
探索“小一点、便宜一点”的近似方案；
在特定场景下做裁剪与适配。

所以，“Twin”这个词更像是市场部的说法，而不是工程团队的说法。

从我的视角：这场游戏真正重要的是什么

作为云原生、服务网格（Service Mesh）、分布式系统（Distributed System）领域的工程师，现在看 AI Infra 时的惯性思维是：

把“模型”当作系统中的一个组件，进一步关注其依赖的基础设施、调度系统和工程流水线。

在这个视角下，所谓“每个闭源模型都有开源 Twin”，真正让我在意的是下面这几件事。

图 1: 闭源定义节奏，开源形成同步响应的结构化机制图

开源模型能否长期在生产环境中“站得住”

关注点不是能不能跑 demo，而是：

版本升级有没有清晰节奏；
回滚与兼容策略是否健全；
模型权重、推理框架、配置之间有没有良好的演进轨迹；
整个栈在可观测性、排障能力上是否可控。

如果这些基础设施层不成熟，所谓“Twin”就只是“我也有一个看上去差不多的东西，但别问我能不能撑住你线上业务”。

训练与推理基础设施是否形成可复制的“工程范式（Engineering Paradigm）”

开源领域真正有价值的是能否形成统一、可教、可迁移的工程范式，例如：

训练流水线：数据准备 → 预处理 → 训练 → 评估 → 对齐 → 部署；
推理基础设施：vLLM / SGLang / TGI 等如何在不同 GPU 拓扑下保持一致表现；
调度与资源管理：在 Kubernetes、云原生基础设施上，如何管理大规模推理负载。

如果这些能沉淀下来，“开源 Twin”就不只是表面上的“也有一个模型”，而是有一整套可复用、透明、可学习的工程体系。

开源的真正价值：可控性和议价权，而不是绝对性能

现实地讲，可预见时间内闭源旗舰在 综合能力 上仍会领先：更大规模、更复杂训练、更好数据、更丰富场景调优。

对企业和开发者来说，开源的重要价值不在于“我要完全替代掉闭源”，而在于：

保持技术路线的可控性；
获取一定的议价权，不至于被某一家厂商锁死；
在隐私敏感、合规要求高的场景里，建立自己的模型栈。

从这个角度看，“Twin”这个词应该冷静重写成：

开源在很多场景下，可以提供一条可控、成本更灵活的替代路径，但它不是闭源的镜像，而是另一个工程决策空间。

对工程师和团队的现实建议：别迷信“Twin”，看清结构

在进入最后小结前，分享我个人对这个话题的可执行观点。

前提是：如果你是工程师、架构师或技术负责人，真正要做的决策不是“站开源还是闭源”，而是：

在你的业务约束下，如何组合闭源 API、开源权重、自建基础设施，得到一个 可演化、可观测、可迁移 的系统。

在这个前提下，“Every Big AI Model Has an Open-Source Twin”可以拆成几条冷静判断：

看到“开源 Twin”，先问自己：它能否在你的生产环境里长久稳定地跑，而不是只跑基准测试。
真正要深入理解的是：它背后有没有一套清晰的训练/ 推理基础设施故事，而不是只有权重链接。
把“开源 vs 闭源”的问题，重写成“我在哪些环节必须要闭源（能力/ 成本），在哪些环节必须要开源（可控/ 合规）。”
如果你做的是基础设施和平台层，更要关注：
- 如何让不同模型在统一的调度、监控、日志体系下以一致方式运行；
- 如何在 Kubernetes / 云原生栈上，把大模型当成一个可观察、可治理的服务，而不是神秘黑箱。

总结

闭源旗舰不断加速、换挡、增加维度，开源生态被迫形成越来越成熟的同步响应机制。真正决定双方距离的，是数据、算力和工程基础设施，而不是一两次模型 release。

对我个人来说，关注点会继续放在：

推理基础设施（如 vLLM、SGLang、TGI 等）的演进；
训练与调度：在云原生环境下如何稳定管理模型生命周期；
工程范式的沉淀：如何从“跑得起来”走向“可复现、可维护、可演化”。

Ingress NGINX 退役的启示：云原生时代的技术债与迁移路径

Jimmy Song — Thu, 13 Nov 2025 01:55:35 +0000

云原生基础设施的演进，最终都要面对技术债与治理的现实。Ingress NGINX 的退役，是一次关于标准化与可持续性的深刻提醒。

Kubernetes 官方宣布：Ingress NGINX 将在 2026 年 3 月彻底停止维护。这不是一次普通的项目 sunset，而是整个 Kubernetes 网络模型演进的标志事件。它揭示了技术栈从“灵活但脆弱”走向“可控、可治理”的必然趋势。

作为长期推动 Kubernetes 与云原生实践的人，我既经历过 Ingress NGINX 的辉煌时代，也见证了它的技术债一步步堆积。以下是这篇文章给我的清晰启发。

技术债终会反噬，特别是基础设施组件

Ingress NGINX 的核心问题并非用户减少，而是“维护成本永久大于贡献速度”。高灵活性带来的巨大攻击面、多年的复杂配置遗留、社区维护者不足，最终让项目无法持续。

基础设施层的组件一旦无法持续安全更新，就不再是资产，而是负担。

我的结论

未来 Infra 的门槛将更高，对安全、可维护性要求更严，个人英雄式的核心维护者模式会持续失效。

Kubernetes 正式进入 Gateway API 时代

在介绍 Gateway API（Gateway API, Gateway Application Programming Interface）之前，需要回顾 Ingress 的 API 设计。Ingress 在当年以简洁著称，但现在已经无法满足流量治理、可扩展性、安全策略、多团队协作等现代需求。

Gateway API 的设计哲学更现代：

跨角色的治理模型（Infra / Dev / Ops）
CRD（Custom Resource Definition, 自定义资源定义）拓展能力强
插件化的实现
明显更好的可观测性和生命周期管理

这意味着：整个生态在流量层面正在从“控制器差异化”走向“API 标准化”。

多数用户对底层网络栈的复杂度没有准备

长期社区观察发现，多数用户将 Ingress NGINX 当作黑盒使用。如今需要从 Ingress 迁移到 Gateway API 或其他 Ingress controller，这对大量集群来说是一场“隐性迁移潮”。

本次公告提醒了两点：

复杂系统中的“默认组件”一旦停更，会带来大范围的不可见风险
云原生体系需要更长期、可持续的供应链治理

安全是最后一根稻草

官方公告反复强调安全风险与漏洞无法持续修复。这再次证明：灵活性与安全永远是 tradeoff（权衡），越贴近数据平面的组件越不能妥协。

云原生世界的“个人维护者瓶颈”会越来越突出

Ingress NGINX 几乎长期依赖 1–2 名维护者，最终不得不退役。这暴露了开源世界一个长期问题：依赖关键项目，但贡献不足。

未来 Infra 发展趋势很明确：

大厂进入底层开源基础设施的意愿会增强
个人维护者难以支撑关键基础组件
商业化与开源的边界会继续收紧

给我个人的方向启发：Gateway API、L7 流量治理与 AI-Native Infra 结合

Ingress NGINX 的退役说明一个底层趋势：统一而可扩展的 API 将成为云原生基础设施的主导范式。

我正在研究的 AI-Native（AI 原生）基础架构——推理路由、模型网关、AI Gateway、Agent Orchestrator——也会走类似路径：从早期的灵活 hack，到成熟的标准化、治理化 API。

总结

Ingress NGINX 称得上 Kubernetes 历史上最重要的控制面之一。它的退役不是失败，而是体系发展到下一个阶段的必然结果。

对我而言，这是一次强提醒：

技术债不可逃避
Infra 必须长期主义
标准化 API 是未来
开源的可持续性需要集体投入
AI 与云原生的结合会复制同样的演进轨迹

参考文献

什么样的 AI 平台算得上 Kubernetes 原生？

Jimmy Song — Wed, 12 Nov 2025 12:39:18 +0000

云原生 AI 平台的标准化，是推动 AI 基础设施生态进化的关键一步，也是行业迈向互信与协作的里程碑。

近年来，云原生生态正逐步从通用计算扩展到 AI 计算领域。CNCF（Cloud Native Computing Foundation，云原生计算基金会）正在推动一项新的认证计划——Kubernetes AI Conformance（Kubernetes AI 兼容性认证），旨在为 AI 平台建立一套与 Kubernetes 兼容、可互操作的技术标准。

这一认证计划试图回答一个核心问题：

“一个 AI 平台，怎样才算真正的 Kubernetes 原生？”

为什么需要 AI Conformance

当前，许多 AI 平台都宣称“运行在 Kubernetes 上”，但实际落地时表现差异明显。下面列举几种常见情况：

有的平台仅仅是在 Kubernetes 上运行容器，未与控制面深度集成。
有的平台则真正与 Kubernetes 控制面、调度、观测系统实现了深度融合。
还有不少厂商自建控制器、调度器、存储接口，导致跨环境迁移和互操作性存在障碍。

CNCF 推出 AI Conformance 的核心目的，是通过统一标准，让 AI 平台在不同云、不同集群中都能保持一致行为，成为生态的共同语言，类似于“Certified Kubernetes”的作用。

Kubernetes 原生 AI 平台的关键标准

Kubernetes 原生 AI 平台需满足以下几个关键标准：

架构原生：一切皆为 Kubernetes 对象

在 AI 训练、推理、批处理等场景下，所有任务都应以 Pod、Job、CRD（Custom Resource Definition，自定义资源定义）的方式声明。调度、扩缩、生命周期管理应交由 Kubernetes 控制面执行，而非平台自建。

例如，Kubeflow Training Operator、RayCluster CRD、vLLM Operator 都采用了这种原生对象声明方式。

调度原生：算力资源统一调度

AI 平台需要通过 Kubernetes 的 Device Plugin（设备插件）与 Scheduler（调度器）协同感知 GPU、NPU 等异构算力资源，并支持 resources.requests/limits 的资源管理。任务调度行为应具备可观测性和可追踪性，避免黑箱运行。

存储原生：声明式数据与模型访问

数据和模型的访问不应依赖宿主路径，而应通过 PVC（PersistentVolumeClaim，持久卷声明）、CSI（Container Storage Interface，容器存储接口）、S3/NAS 等标准接口挂载。凭据、参数等敏感信息由 Secrets、ConfigMap 注入。整个 pipeline 能够被 GitOps / CI/CD 流程重放，确保可追溯性和自动化。

网络与服务原生：兼容 Mesh 与 Gateway

AI 推理服务应以标准 Service、Ingress、Gateway API 暴露，支持多集群服务发现与路由策略，并能与 Istio、Envoy、Linkerd 等服务网格无缝对接。

此外，平台需输出标准化监控指标（如 Prometheus）、日志（如 FluentBit）、追踪信息（如 OpenTelemetry），以便于统一观测和运维。

可移植与可互操作

真正的 Kubernetes 原生 AI 平台应能在不同环境下保持一致行为，包括：

公有云（如 EKS、GKE、ACK）
私有云（如 OpenShift、KubeSphere）
裸机集群

同时，平台应能直接集成 Kubeflow、Ray、KServe、Triton 等主流生态组件，实现高度互操作性。

CNCF 的目标：从“运行在 Kubernetes 上”到“生长于 Kubernetes 中”

CNCF 希望通过 AI Conformance 认证机制，像过去的 Certified Kubernetes 一样，推动整个 AI 基础设施生态进入标准化阶段。

未来，行业可能会看到：

Certified AI Platform 徽标，成为平台互信凭证。
自动化校验 bot（Verify Conformance Bot），提升测试效率。
多版本测试套件（如 v1.33、v1.34 等），保障兼容性。

这些举措将成为云厂商、AI 平台、AI Infra 开源项目的重要技术门槛和生态互信基础。

总结

AI 时代，标准化是生态持续演化的基础。AI 平台要想在云原生生态中长期发展，不仅要“跑在 Kubernetes 上”，更要“生长在 Kubernetes 中”。

真正的 Kubernetes 原生 AI 平台 应具备：

控制面兼容、数据面透明、扩展面声明式、可移植、可观测、可重放。

这正是 AI 与云原生交汇的关键，也是下一阶段 AI 基础设施的根基。

ChatGPT Atlas 架构解剖：为什么体积巨大、运行方式不同、Agent 又如此缓慢？

Jimmy Song — Tue, 11 Nov 2025 01:46:24 +0000

AI Native 浏览器的体积和复杂度不是缺点，而是新一代操作系统形态的必然结果。

Atlas 的体积为何远超 Chrome？到底多了什么？

Atlas 的安装体积达到数 GB，这一现象并非偶然。它不仅仅是传统意义上的“浏览器壳程序”，而是集成了多种核心组件：

Chromium 渲染内核（Chromium Rendering Engine） + 独立 AI Runtime（AI Runtime） + Agent 安全沙箱（Agent Sandbox） + 全局上下文管线（Global Context Pipeline） 的组合体。

Chrome 只是网页渲染器，而 Atlas 已经成为一个 AI 工作流执行环境。

Atlas 的架构设计决定了其体积远超传统浏览器。

Atlas 与 Chrome 的核心区别：多了一整套 AI Runtime

很多人认为 Atlas 只是“Chromium + AI 功能”，但实际情况远比这复杂。Atlas 在 Chromium 基础上，额外叠加了完整的 AI 子运行时（AI Sub-runtime），形成了独立的系统级子操作环境。

下方的流程图展示了 Atlas 在 Chrome 基础上新增的 AI 子系统：

图 1: Atlas 在 Chrome 基础上新增了 AI 子运行时

这并非简单的功能扩展，而是系统级的架构升级。

Atlas 的本地数据结构：不是缓存，是完整浏览器 + AI 子系统

Atlas 首次启动时，会在本地生成独立的 host Profile，路径如下：

/Users/<user>/Library/Application Support/com.openai.atlas/browser-data/host/

与 Chrome 相比，Atlas 的数据结构更加庞大，包含多种核心数据：

12K AmountExtractionHeuristicRegexes
960K AutofillStates
4.0M BrowserMetrics-spare.pma
169M component_crx_cache
93M extensions_crx_cache
1.1M OpenCookieDatabase
2.7G OptGuideOnDeviceModel
19M Safe Browsing
123M screen_ai
1.7G user-<uuid>
...

这些数据不仅仅是浏览缓存，更包括：

Chromium 完整 Profile（Cookie、Local State、Shader、Safe Browsing 等）
Atlas 专用 AI 模型与特征数据
- OptGuideOnDeviceModel（推理引导模型）
- screen_ai（页面结构理解模型）
- WasmTtsEngine
Agent 执行轨迹与上下文持久化
- 全部保存在 user-<uuid> 中

Chrome 只需保存渲染缓存，而 Atlas 还需存储 AI 运行状态、DOM 语义摘要、Agent 执行痕迹以及大语言模型（LLM）上下文片段，因此体积自然以 GB 为单位。

Atlas 只有一个 host Profile 的原因

Chrome 支持多个 Profile，而 Atlas 仅有 host/ 与 user-<uuid>。其原因在于：

Agent 工作流依赖全局上下文，无法碎片化
AI Memory 需要跨页面共享
OpenAI 的 IPC 与安全沙箱设计目前仅支持单一主体

这属于架构层面的限制，未来可能会有调整。

Atlas 的进程架构：比 Chrome 更复杂

Chrome 的多进程架构主要包括：

主进程
扩展进程
渲染/网络进程

而 Atlas 的进程架构则更加复杂，包含：

主进程（Chromium Shell）
渲染进程（DOM/JS）
AI Runtime 进程
Agent Sandbox 隔离环境
页面抽取与语义解析进程
安全策略与权限仲裁进程
模型推理协调层（LLM Orchestrator）

每个层级之间都通过严格的进程间通信（IPC, Inter-Process Communication）进行数据交互，没有任何一步是“脚本级执行”，确保了安全性与可靠性。

Atlas Agent 的运行原理：为什么慢？为什么不像脚本？

Atlas 的 Agent 并非直接执行脚本，而是通过多轮推理与安全沙箱机制完成任务。每一次动作都包含完整的大语言模型（LLM）推理、DOM 观察、沙箱执行与再推理。

Agent 的运行流程如下：

LLM 决策下一步
沙箱执行动作
生成新的页面观测（结构化 DOM）
LLM 再次推理下一步
循环直到任务结束

因此，Atlas Agent 的执行特点包括：

速度永远比脚本慢（如 Playwright/Selenium 直接执行）
必须隔离以保证安全
多轮推理确保可靠性
结构化 DOM 便于模型理解页面内容

这也是 Agent 速度较慢的根本原因。

Atlas 正在向“AI Native OS”演化

Atlas 的能力已远超传统浏览器，正逐步向 AI Native 操作系统（AI Native OS）演化。下表对比了两者的核心能力：

这是 Atlas 与传统浏览器能力的对比表：

能力	浏览器	AI OS（Atlas）
渲染网页	✔	✔
执行 JS	✔	✔
页面内容语义理解	✘（只有解析）	✔
自动化执行任务	插件	内建
任务级推理	✘	✔
跨页面工作流程	✘	✔
Agent 安全沙箱	✘	✔
全局 AI 上下文	✘	✔

表 1: 传统浏览器与 AI OS（Atlas）能力对比

Atlas 已经具备 AI OS 的 30%～40% 核心能力。它不仅仅是浏览器，更是：

AI Runtime + 渲染引擎 + Agent 工作流执行器

总结

Atlas 表面上看似浏览器，实则是一个重量级 AI Runtime：

体积庞大：本地需存放 AI 模型、特征数据与 Agent 上下文
进程复杂：安全、推理、DOM 抽取均需独立管线
Agent 执行缓慢：每一步都需推理，而非直接脚本执行
Profile 巨大：保存的是 AI 系统状态，而非简单缓存

Chrome 是网页处理器，而 Atlas 已经成为 AI 工作流引擎，两者本质上属于不同的技术物种。

ChatGPT Atlas 深度使用两周：作为开发者，我看到的真实潜力与结构性短板

Jimmy Song — Tue, 11 Nov 2025 01:26:05 +0000

AI 浏览器的未来不是功能堆叠，而是统一开发者上下文与工作流。Atlas 已经改变了我的日常，但距离理想还有关键差距。

为什么我在 Atlas 上线第一天就切换了主力浏览器？

图 1: 使用 ChatGPT 1000+ 天，Atlas 19 天

作为一个长期同时使用多种开发工具的用户，包括 ChatGPT（GPT-4/5、Codex、o1 系列）、Chrome（多 Tab、高密度检索）、VSCode（本地工程环境）、macOS ChatGPT Desktop（本地上下文读取）、以及本地 Hugo / Flask / FastAPI 调试环境，我在看到 Atlas 的设计理念后，第一时间将其作为主力浏览器。两周深度体验后，我的核心观点是：

Atlas 将浏览器从“渲染器”变成“AI Runtime 的宿主”。

本文将以开发者视角，系统梳理 Atlas 带来的架构优势、工作流增强点、结构性痛点与未来方向。

Atlas 给开发者带来的真实增强点

Atlas 的核心创新在于将本地开发环境与 AI 原生打通，极大提升了开发者的工作流效率。

本地开发与 AI 的原生融合：`localhost` 访问能力

过去，浏览器与 AI 工具之间是两套割裂的世界：浏览器只能看到本地服务，ChatGPT 只能分析云端上传的片段，AI 无法直接感知工程现场的真实状态。而 Atlas 首次实现了 AI 对本地服务的直接读取。

下方流程图展示了本地服务与 Atlas 的集成方式：

图 2: Atlas 本地服务集成流程

这种能力对开发者意义重大：

调试 API 时，ChatGPT 可直接查看响应内容。
文档预览时，AI 能比对原始文件与渲染结果。
Hugo / SSG 本地预览，AI 可读取完整 HTML。
快速复盘本地错误页面，定位问题更高效。
本地工程环境首次被“读进”AI 的推理空间。

这些都是 Chrome + Web ChatGPT 当前版本尚未实现的能力。

侧边栏 ChatGPT：持续运行的「任务线程」

Atlas 的侧边栏 ChatGPT 不再是传统“一问一答式”，而是持续运行的任务线程。开发者可以在多个 Tab 间切换，保持同一对话历史，真正实现“助手层”的体验。

下方时序图展示了典型的开发流程：

图 3: Atlas 侧边栏任务线程

优势包括：

对话历史固定在左侧，不被页面遮挡。
无需切换聊天窗口，专注任务流。
多 Tab 阅读体验不受影响，AI 成为真正的开发助手。

Atlas 的结构性痛点（开发者视角）

尽管 Atlas 带来了诸多创新，但在实际开发场景下仍存在明显的结构性短板。

单对话只能引用一个 Tab，上下文受限

开发者常常需要对比多个文档、API、实现或架构图，但当前 ChatGPT 对话只能绑定当前可见 Tab 的内容，无法实现多页面推理。

下方流程图展示了理想的多页面绑定方式：

图 4: 多页面绑定对话

未来 AI 浏览器应支持一个对话同时绑定多个页面，实现真正的多上下文推理。

桌面端与 Web/Atlas 的会话界面缺乏一致性

虽然 Atlas、Web ChatGPT 和 ChatGPT Desktop 使用的是同一个 conversation_id，上下文本身是统一的，但三端的显示策略不同，导致“历史一致但实时不一致”。

Web / Atlas（浏览器端） 每条消息都会立即写入服务端，因此它们之间的更新是实时可见的。
ChatGPT Desktop（桌面端） 为了支持本地上下文和更快渲染，采用了本地缓存模型；它会自动 pull Web/Atlas 的更新，但自身的更新并不会自动推送回浏览器端。

结果就是：

三端的上下文始终一致，但 UI 刷新节奏不一致： Desktop → Web/Atlas 不会自动同步，Web 必须刷新页面才能看到最新消息，Atlas 侧边栏甚至无法刷新。

图 5: 三个端点界面不同步问题

这会在开发者工作流里造成一个非常常见的割裂： “明明是同一段对话，但不同端看到的内容不完全一样”。

缺少 Prompt 模板与快捷指令系统

在日常开发中，Prompt 模板（如代码审查、文档重写、BUG 复盘、API 总结、架构评审等）极为重要。Chrome 时代可通过插件实现，但 Atlas 目前完全缺位。

下表总结了理想的模板与指令系统能力：

能力	理想行为
Prompt 模板库	侧边栏可调用、变量支持
自定义指令	`/review`, `/refactor`, `/summarize`
多设备同步	桌面、浏览器、未来移动端一致
上下文感知	AI 自动匹配你当前正在做的任务

表 1: Prompt 模板与指令系统能力对比

Atlas 目前尚未支持 Prompt 模板与快捷指令系统。

Atlas 隐藏了一些 DevTools 能力

Atlas 的 DevTools 本身是完整的 Chromium 套件，调试 HTML、网络请求、性能、控制台等都完全可用。但当前版本移除了 Chrome DevTools 中的「Device Mode」移动端模拟功能，包括 UA/viewport 切换、触控模拟和响应式模式。因此在 Atlas 里暂时无法进行移动端调试。这不是底层能力缺失，而是 UI 层尚未暴露相关入口。

缺少移动端，工作流上下文割裂

目前 Atlas 尚未推出移动端版本，导致通勤、旅行、碎片时间无法与桌面端工作流联动。上下文、历史、Tab、任务区、记忆均无法同步，影响开发者的整体体验。

Agent 速度与可靠性问题

Atlas 的 Agent 执行速度慢、偶尔卡住或无法完成任务，反馈机制不透明，缺乏可视化中断控制。这些问题使其在生产任务中难以被采用。

Atlas、Chrome、ChatGPT Desktop 核心能力对比

下表总结了三者在核心开发者能力上的差异，便于 Hacker News 读者快速了解技术定位。

能力	Chrome	ChatGPT Desktop	Atlas
浏览网页	✔	✘	✔
本地上下文（VSCode/CLI）	✘	✔✔	✘
本地服务 localhost 读取	✔（浏览器）	✘	✔✔（AI 可读）
ChatGPT 深度集成	✘	✔	✔✔
Tab ←→ 对话绑定	✘	✘	✔
DevTools	✔✔	✘	✔
多网页同时注入对话	✘	✘	✘
Prompt 模板系统	插件	✘	✘
移动端	✔	✔（ChatGPT App）	✘
Agent 自动化	✘	✔	✔（但不成熟）

表 2: Atlas vs Chrome vs ChatGPT Desktop 核心能力对比

Atlas 的独特性在于：

Atlas 是主流 AI 浏览器中首个原生把 localhost 页面直接注入到对话上下文的产品，但并非目前唯一能访问本地内容的方案。

AI 浏览器的未来：不是“更智能”，而是“更统一”

未来的 AI 浏览器应以统一上下文与工作流为核心，而非简单功能堆叠。下方流程图展示了理想的架构：

图 6: AI 浏览器未来架构

理想的 AI 浏览器应具备：

跨 Tab、跨对话、跨设备的统一上下文图谱。
网页结构的语义解析能力。
本地文件、API、运行时的统一读取能力。
可观察、可中断的 Agent 任务执行系统。
统一的 Prompt 模板运行层。
多设备协同的知识轨迹（memory graph）。
可扩展的插件机制。

目前所有 AI 浏览器都不具备这些能力，包括 Atlas。但 Atlas 的方向正确，原生能力仍在完善，已走在这条路径的前 20%。

总结

过去两周的深度体验让我得出如下结论：

Atlas 还远不成熟，但已经足够强大，显著改变了我的查文档、写代码、分析页面的方式。
它降低了 AI 与网页内容之间的壁垒，让我减少了对 ChatGPT Desktop 的依赖。
但它仍然缺少开发者真正需要的关键能力，包括多网页同时注入、原生 Prompt 模板、DevTools 完整支持、移动端、可信 Agent Runtime。

Atlas 现在像是：

Chrome + ChatGPT + localhost 集成

但要成为

开发者的下一代操作系统（AI OS）

还需补齐上述关键能力。

方向是对的，我会继续使用，也会持续观察它是否能成为未来开发者的默认工具链。

KAITO 与 KubeFleet：CNCF 正在重塑 AI 推理基础设施

Jimmy Song — Sat, 08 Nov 2025 17:40:00 +0000

云原生的声明式与多集群能力，正在成为 AI 推理基础设施的标准化底座。

AI 推理（Inference）正在成为云原生基础设施的下一个战场。随着大语言模型（LLM）能力与规模的迅速增长，传统单集群推理架构已难以满足全球化、高可用与成本优化的需求。2025 年 10 月底，CNCF 宣布托管两个新项目 —— KAITO（Kubernetes AI Toolchain Operator） 与 KubeFleet，这标志着云原生社区正式进入 AI 推理基础设施标准化阶段。

本文对这两个项目进行系统性分析，并探讨其对 AI Infra 生态的战略意义。

AI 推理的复杂性：从单集群到多集群

随着大模型推理负载特征变化，企业开始采用多集群（multi-cluster）推理架构。下方总结了多集群架构带来的三大挑战：

部署一致性问题：不同集群间模型版本、依赖与配置漂移难以控制。
计算资源稀缺问题：需要智能调度可用 GPU，避免资源浪费或热点。
服务可靠性问题：推理端点需满足低延迟、高可用与跨地域 SLA。

KAITO 与 KubeFleet 正是为解决这些问题而生。

下图展示了 KAITO 与 KubeFleet 的架构设计。

图 1: KAITO 与 KubeFleet 架构设计

图示说明：

顶层为 KubeFleet Hub Cluster（控制多集群放置逻辑）。
下层为三个地域集群（US / EU / APAC），每个集群有 Active Nodes 与 Spare GPU。
Inference Gateway 统一暴露全局推理入口。
箭头方向体现“放置与汇聚”的控制流。

KAITO：AI 推理的声明式编排层

KAITO（Kubernetes AI Toolchain Operator）由微软团队发起，是一个声明式的 AI 工作负载管理框架。它通过 CRD（Custom Resource Definition）抽象模型生命周期，使 LLM 推理像部署微服务一样可配置、可复用。

项目地址：github.com/kaito-project/kaito

下表总结了 KAITO 的核心特性与设计理念：

特性/理念	说明
工作区模型管理	支持预训练模型与自带模型（BYO Model）
自动资源分配	根据模型规模与 GPU 可用性自动申请节点与卷
多节点优化	支持分布式存储与计算调度
内置可观测性	直接输出推理延迟、吞吐与错误指标
声明式部署	模型视为 Kubernetes 原生资源对象，支持 YAML 配置与 GitOps

表 1: KAITO 核心特性与设计理念

例如，推理管线可声明为 YAML：

apiVersion: aitoolchain.io/v1
kind: ModelDeployment
metadata:
 name: qwen2-7b
spec:
 model: qwen2-7b
 engine: vllm
 replicas: 3
 resources:
 gpu: 2

这使得 AI 平台具备了与应用服务相同的部署一致性与 GitOps 能力。

KubeFleet：多集群智能调度与放置

KubeFleet 由 Azure Kubernetes Service（AKS）团队主导，是一个跨集群工作负载编排器（Multi-Cluster Orchestrator），专注于智能放置推理工作负载。

项目地址：github.com/kubefleet-dev/kubefleet

下表总结了 KubeFleet 的功能亮点与使用场景：

功能/场景	说明
集群能力发现	评估每个集群的 GPU 类型、数量、成本与地理位置
智能放置决策	根据策略在最合适的集群部署推理任务
阶段化更新	支持跨测试、预发、生产集群的灰度发布
一致性控制	保证不同集群的部署模板统一
全球推理服务	支持 Geo-distributed Inference
GPU 异构资源池调度	支持企业级多环境一体化发布

表 2: KubeFleet 功能亮点与使用场景

KAITO × KubeFleet：AI 推理基础设施的分层设计

下表总结了 KAITO 与 KubeFleet 在 AI 推理基础设施中的分层定位：

层级	职责	代表项目
Global Placement 层	选择在哪个集群部署	KubeFleet
Cluster Orchestration 层	定义如何部署模型	KAITO
Runtime 层	执行推理引擎	vLLM / TGI / SGLang / Triton
Infra 层	提供算力与调度基础	Kubernetes / GPU / CNI / Storage

表 3: AI 推理基础设施分层设计

这套分层设计体现了 CNCF 的一贯思路：以声明式与插件化的方式抽象复杂基础设施，降低 AI 推理平台的进入门槛。

生态意义与趋势判断

AI Infra 正在被云原生化，CNCF 正在吸纳 AI 工作负载进入其治理体系，这将推动 AI 平台逐步形成与云原生一致的标准栈。多集群调度成为新战场，GPU 异构性与跨地域合规推动企业采用多集群推理架构。KubeFleet 可能成为 Karmada / Clusternet 之后的“AI Federation”代表。声明式 AI 运维将替代手动脚本式部署，KAITO 的 CRD 模型可能成为未来 ML Serving 的标准语义层。微软与 CNCF 的战略协作增强，这两个项目均来自 Azure 团队，意味着云厂商正以开源基础设施标准方式参与 AI 生态竞争。

与现有项目的对比关系

下表对比了 KAITO、KubeFleet 与主流 AI 推理基础设施项目的功能：

功能	KAITO	KubeFleet	Kubeflow	KServe	HAMI
模型声明式部署	✅	–	✅	✅	–
多集群调度	–	✅	–	部分支持	✅
GPU 异构感知	✅	✅	部分	✅	✅
Telemetry / Metrics	✅	✅	✅	✅	✅
云厂商支持	Microsoft / CNCF	Microsoft / CNCF	Google	IBM / RedHat	AWS

表 4: AI 推理基础设施项目功能对比

总结

KAITO 与 KubeFleet 的出现，是 AI Infra 演进的重要分水岭。它们代表了云原生社区对 AI 推理的正式介入，也揭示了未来的趋势：

AI 推理的复杂性，将被 Kubernetes 的声明式与多集群体系所吸收。
这两个项目值得被纳入任何研究 AI 原生基础设施的参考架构中。
对于开发者与平台团队而言，它们不仅是新工具，更是 AI 基础设施标准化的信号。

参考文献

使用云原生大模型开源四件套构建高效推理体系：KServe + vLLM + llm-d + WG Serving

Jimmy Song — Sat, 08 Nov 2025 05:21:59 +0000

云原生推理体系的标准化与模块化，正让大模型部署像 Web 服务一样简单高效。

大模型推理正在从单机加速器时代迈向云原生分布式体系。当前最具代表性的组合是 KServe、vLLM、llm-d 与 WG Serving（Working Group Serving）。它们分别承担标准接口、执行引擎、调度层和协作规范四个角色，共同形成可扩展、可观测、可治理的推理底座。

下方时间线梳理了四件套的关键演进节点：

图 1: 云原生大模型推理四件套演进时间线

架构总览

下方架构图展示了四件套在推理体系中的分层协作关系：

图 2: 云原生大模型推理四件套架构总览

KServe：云原生模型服务核心

KServe 是 Kubernetes 原生的推理控制平面。它以 CRD（Custom Resource Definition, 自定义资源定义）形式抽象模型服务，使 AI 推理像微服务一样可部署、可扩缩、可灰度。

下表总结了 KServe 的核心能力与新特性：

维度	描述
核心目标	提供 Kubernetes 原生的推理标准与控制面
核心能力	CRD 标准化、弹性伸缩、流量治理、网关统一入口
新特性	LeaderWorkerSet 支持、AI Gateway 集成、与 llm-d 对接

表 1: KServe 核心能力与新特性

KServe 的关键能力包括：

统一接口：InferenceService CRD 定义输入输出协议，与 REST/GRPC 或 OpenAI API 兼容。
弹性调度：支持 GPU 自动伸缩与 ModelMesh 多模型托管。
流量治理：金丝雀发布、A/B 测试、推理图（InferenceGraph）。

最新版本引入 LeaderWorkerSet（LWS）机制与 Envoy AI Gateway 扩展，使多 Pod 大模型推理成为原生能力。KServe 正从传统 ML 服务平台转型为 生成式 AI 控制平面标准。

vLLM：高性能推理执行引擎

vLLM 聚焦极致吞吐与显存效率，是当前开源性能标杆。

下方时序图展示了 vLLM 推理的主要流程：

图 3: vLLM 推理流程

下表总结了 vLLM 的核心技术机制与效果：

特性	技术机制	效果
PagedAttention	显存分页管理	延长上下文，减少碎片
Continuous Batching	动态批调度	提高 GPU 利用率
Prefix Cache	前缀复用	降低延迟与成本

表 2: vLLM 核心技术机制与效果

vLLM 兼容 OpenAI API，支持 INT8/FP8 等量化及多种并行模式，适配 NVIDIA、AMD、TPU、Gaudi 等硬件。在单机或小规模场景下，vLLM 可独立运行；在集群环境中，它是 KServe/llm-d 的执行底座。

llm-d：分布式推理调度层

llm-d 是 Kubernetes 上的大模型调度与编排系统，为 vLLM 提供多实例协同能力。设计目标：让集群像单机一样推理。

下表总结了 llm-d 的核心机制与技术亮点：

模块	功能	技术亮点
Scheduler	缓存感知路由	按前缀亲和调度
Prefill/Decode 分离	异构硬件优化	A100 Prefill + L40 Decode
Cache Manager	全局缓存索引	GPU/CPU/NVMe 层次化缓存

表 3: llm-d 核心机制与技术亮点

下方流程图展示了 llm-d 的分布式调度与缓存机制：

图 4: llm-d 分布式调度与缓存机制

llm-d 在 KServe 控制面下以 Leader/Worker 形式运行，调度器嵌入 Envoy 或独立部署，可实时依据缓存与负载信息决策路由。其出现让多节点大语言模型（LLM）推理首次具备了自治调度与弹性并行。

WG Serving：协同标准与生态枢纽

WG Serving 是 Kubernetes 社区推动的 AI Serving 工作组，定义推理在 K8s 中的统一语义。

下表总结了 WG Serving 的核心成果与标准化贡献：

成果/标准	说明
Gateway Inference Extension (GIE)	基于 Envoy 的推理网关协议，支持模型识别、流式转发、优先级与缓存亲和路由
LeaderWorkerSet CRD	显式描述 Leader–Worker 协作结构，成为 llm-d 和 KServe 实现多 Pod 推理的基础
接口对齐	倡导 OpenAI-style API 与 K8s 资源对象融合，推动多框架互通

表 4: WG Serving 核心成果与标准化贡献

GIE 是云原生 AI 推理的“统一网关语言”，就像 Ingress 定义 HTTP 服务入口一样，它定义了推理请求在 Kubernetes 内的标准语义与网关行为，使推理系统可组合、可观测、可扩展。

下方流程图展示了 WG Serving 在推理体系中的标准化协作关系：

图 5: WG Serving 标准化协作关系

WG Serving 不是产品，而是形成行业共识的标准层，正促成云原生 AI 推理的统一语言。

组合架构

下表总结了四件套在系统中的分工与角色：

层级	组件	角色
入口层	Envoy + GIE	统一 API 网关与流量调度钩子
控制层	KServe + LWS	生命周期管理、弹性伸缩、流量编排
调度层	llm-d	前缀感知路由、跨 Pod 协作、缓存管理
执行层	vLLM	高效推理执行与缓存复用

表 5: 云原生大模型推理四件套分工与角色

下方架构图展示了四件套的协同关系：

图 6: 云原生大模型推理四件套协同关系

客户端以 OpenAI API 格式发送请求，经 GIE 网关调度到最优 Leader，Prefill 完成后缓存传递至 Worker Decode，最终流式返回结果。整套链路兼具标准接口、高吞吐与弹性伸缩特性。

生态收敛趋势

下表总结了云原生大模型推理生态的收敛趋势与特性对比：

趋势/特性	说明
API 统一化	OpenAI 式接口成为事实标准，KServe 与 vLLM 等均原生兼容
模块解耦	网关、调度、推理分层，利于独立演进与替换
缓存分层化	GPU–CPU–NVMe 三级 KV 缓存成为主流方案
社区协同	WG Serving、PyTorch 基金会、CNCF 等共同推动跨项目融合

表 6: 云原生大模型推理生态收敛趋势与特性对比

下方对比矩阵展示了各项目的核心能力：

项目	控制面	推理性能	分布式能力	接口兼容	缓存机制	弹性扩缩
KServe	✅ CRD / LWS	⚪ 中	⭐ 多模型管理	✅ OpenAI API	⚪ 无	✅
vLLM	⚪ 无	🌟 极高	⭐ 多 GPU	✅ OpenAI API	✅ Paged KV	⚪ 无
llm-d	⭐ K8s 原生调度	🌟 高	🌟 多实例协同	✅ 继承上层接口	🌟 全局缓存	✅
WG Serving	🌟 标准抽象	⚪ 无	🌟 跨项目协同	🌟 统一规范	⚪ 不涉及	⚪

表 7: 云原生大模型推理四件套特性对比矩阵

未来推理栈将以标准 API 与可插拔模块为核心，实现像部署 Web 服务一样部署大语言模型（LLM）。

部署范式示例

在 Kubernetes 集群中，四件套的部署范式如下：

Prefill 层：4 × A100 Pod，负责长上下文计算。
Decode 层：16 × L4 Pod，执行流式生成。
llm-d 调度器：依据缓存命中率动态路由。
KServe 控制面：管理 LWS 资源与扩缩容。
Envoy GIE 网关：统一 OpenAI 接口入口。

下方拓扑图展示了部署结构：

图 7: 云原生大模型推理四件套部署拓扑

此组合实现高并发、低成本、可观测的大模型服务。

结语：标准化的未来

下表总结了四件套在推理体系中的层级、角色与核心贡献：

层级	角色	核心贡献
入口层	WG Serving (GIE)	统一流量入口与接口规范
控制层	KServe	Kubernetes 原生部署与管理
调度层	llm-d	前缀缓存感知的分布式推理调度
执行层	vLLM	高性能、低成本推理引擎

表 8: 云原生大模型推理四件套层级与核心贡献

结论：
这套“四件套”标志着大模型推理进入标准化与可组合时代。未来趋势将聚焦于：

API 规范化（OpenAI / OpenInference）
缓存分层与共享化
控制面与数据面解耦
云原生平台一体化编排

总结

云原生大模型推理“四件套”——KServe、vLLM、llm-d、WG Serving——正在推动推理体系的标准化、模块化与生态融合。通过分层协作与标准接口，开发者可实现高性能、低成本、可观测的大语言模型推理服务，助力 AI 原生架构的落地与创新。

为什么 AI 推理天然属于 Kubernetes

Jimmy Song — Wed, 05 Nov 2025 03:44:57 +0000

AI 推理的未来，不在于“更快的 GPU”，而在于“更智能的基础设施”。

AI 推理与云原生的天然契合

AI 推理（AI Inference）系统需要在性能、弹性、成本和可运维性之间取得平衡。这些，正是 Kubernetes 在云原生时代十年积累下来的核心能力。

当我们重新审视 AI 基础设施时，Kubernetes 不仅是“容器编排系统”，更正在成为 AI 推理的运行时底座。

AI 推理系统具备的核心诉求包括：

弹性（请求高峰 vs. 空闲期）
低延迟（推理响应时间敏感）
成本控制（GPU 资源昂贵）
灰度发布与版本管理（模型迭代频繁）
多租户与隔离（不同模型/团队共享集群）

而这些恰恰是云原生技术十年来解决的问题。换句话说：AI Inference 正在重走云原生微服务的路，只不过底层算力从 CPU 变成 GPU。

AI 推理与训练在资源使用和架构诉求上存在显著差异。下表对比了两者的主要特征，帮助理解为何推理场景与云原生架构高度契合。

对比维度	AI 训练	AI 推理
资源形态	长时间占用 GPU、计算密集	短时高并发、负载波动
优先目标	吞吐量最大化	响应时间最短
成本模式	固定资源投入	动态资源弹性分配
运维方式	批量作业	服务化部署
可观测性关注点	Loss、Step、GPU 利用率	QPS、延迟、Token 吞吐

表 1: AI 训练与推理的资源与运维对比

这些特征与 Kubernetes 的核心理念（弹性调度、声明式管理、资源隔离）高度一致。换句话说，AI 推理场景的复杂性，正好被云原生架构“预设”了答案。

Kubernetes 的能力映射图谱

Kubernetes 提供了丰富的原生能力，能够精准映射到 AI 推理的各类需求。下表总结了主要特性及其在推理场景下的价值。

Kubernetes 特性	对 AI 推理的价值
Horizontal Pod Autoscaler (HPA)	根据 GPU 利用率或延迟自动扩缩副本数
Vertical Pod Autoscaler (VPA)	动态调整容器的 CPU/GPU 限额以适配负载
Cluster Autoscaler (CA)	自动扩缩集群节点池，应对大规模推理请求
Device Plugin	GPU/TPU 资源注册与隔离
Node Affinity / Taints	确保模型副本在合适节点分布
Service Mesh / Ingress	支持灰度发布与 A/B 测试
Observability Stack	采集推理指标：延迟分布、吞吐、模型版本性能等

表 2: Kubernetes 特性与 AI 推理价值映射

这些能力组合在一起，形成了一个“AI 推理即服务”的云原生基座。

云原生 AI 推理架构图

下图展示了典型的云原生 AI 推理系统架构，涵盖了请求入口、推理服务、资源调度、监控与自动伸缩等关键环节。

图 1: 云原生 AI 推理架构

该架构实现了推理请求的高效路由、弹性资源调度、性能监控与自动扩缩容的闭环。

AI 推理运行模式的演进路径

AI 推理平台的演进可分为三个阶段。下面的列表梳理了每个阶段的主要特征和技术要点。

容器化部署阶段

模型打包成 Docker 镜像，通过 YAML 文件部署。
优点：标准化；缺点：缺乏动态调度。

自动伸缩与资源调优阶段

引入 HPA/VPA/KEDA，实现 GPU 资源的动态分配。
加入监控与指标反馈，实现闭环性能调优。

AI 原生平台阶段

模型、版本、监控、成本管理一体化。
引入模型注册中心（Model Registry）、KServe、vLLM 等生态组件。

为什么 Kubernetes 是 AI 推理的理想底座

Kubernetes 作为 AI 推理平台的基础，具备以下独特优势：

弹性与可预测性：请求峰谷差异巨大，Kubernetes 自动伸缩可在秒级完成副本调整。
资源复用与隔离：支持 GPU 分片（MIG）、共享（fractional GPU）等机制，提升资源利用率。
灰度发布与版本治理：Deployment + Service Mesh 支撑模型灰度切换与多版本共存。
跨环境一致性：一次定义，处处运行。支持本地、私有云、公有云的统一推理体验。
生态完备：与 Kubeflow、KServe、Ray、vLLM 等组件无缝集成，构建 AI Infra 全栈体系。

这些能力让 Kubernetes 成为 AI 推理工程师的首选平台。

AI 原生基础设施的未来趋势

下图展示了 DevOps 与 AI 的融合路径，体现了从自动化部署到智能反馈的演进闭环。

图 2: DevOps 与 AI 融合演进路径

未来，Kubernetes 将贯穿整个链路，从应用编排到模型服务，逐步演进为“AI 原生平台工程”的基础设施。主要趋势包括：

趋势方向	核心内容
GPU 调度与可观测性融合	指标将覆盖延迟、吞吐、token 利用率等维度
模型治理平台化	自动评估模型性能与资源性价比
成本与能耗感知调度	动态决策最优 GPU 节点与实例
边缘推理协同	Kubernetes + Edge 构成分布式智能推理网格

表 3: AI 原生基础设施未来趋势

总结

过去十年，Kubernetes 定义了云原生基础设施的语言；未来十年，它也将定义 AI 推理的基础运行时。AI 不只是算法问题，更是工程问题。Kubernetes 让我们第一次有机会，用系统化、声明式的方式去治理 AI 的复杂性。AI 推理的未来，关键不在于“更快的 GPU”，而在于“更智能的基础设施”，这正是云原生的意义所在。

为什么玻璃便宜，但安装贵：AI 时代的 Jevons 悖论与 Baumol 效应

Jimmy Song — Mon, 03 Nov 2025 17:27:19 +0000

AI 让虚拟世界无限扩张，却让现实世界的人工变得前所未有地昂贵。

玻璃自爆的现实启示

上个月，我家客厅的落地窗玻璃自爆了。厂家报价时，我惊讶地发现：

玻璃本身只要 500 元，但更换费用高达 2500 元。

图 1: 自爆的玻璃

这里，贵的不是玻璃，而是运输、吊装、人工、协调这些“非玻璃”的部分。

以一块 3.2 平方米的双层中空钢化玻璃为例，材料成本可能只占总费用的 20%，剩下的 80% 都是人、时间与现实世界的摩擦。

这一现实让我联想到 a16z 最近的一篇文章 Why AC is cheap, but AC repair is a luxury。其实在中国，我们也在经历同样的现象：材料越来越便宜，但人工越来越贵。

为了更直观地理解背后的经济学逻辑，下方思维导图梳理了相关悖论与效应：

图 2: AI 时代的生产力悖论

上图展示了 Jevons 悖论（Jevons’ Paradox）、Baumol 效应（Baumol’s Cost Disease）及其在中国现实中的交织。

Jevons 悖论：效率越高，消费越多

英国经济学家 William Stanley Jevons 在 1865 年提出了著名的 Jevons 悖论（Jevons’ Paradox）：当某项技术变得更高效、更便宜时，人们反而会消费更多这种资源。

在今天的中国，这一悖论有诸多现实例证：

智能手机、光伏板、芯片、AI 推理的单价不断下降；
但我们消费的智能终端、数据中心、电力与算力却越来越多。

以人工智能（AI, Artificial Intelligence）为例，模型推理成本在快速下降，但调用量反而呈指数级增长。

越便宜的算力，反而越被滥用。这正是现代版的 Jevons 悖论。

Jevons 悖论的本质不是“节省”，而是“扩张”：效率提升带来更低边际成本，最终扩大需求总量。

Baumol 效应：效率越低，成本越高

与 Jevons 悖论相对的，是 Baumol 效应（Baumol’s Cost Disease），它揭示了另一种更隐秘的通胀机制。

当部分行业的生产力暴涨、工资提升时，其他低效率行业也必须提高薪酬，才能留住劳动力。

例如：

科技公司和金融行业的人均产值高、工资高；
结果是水电工、木工、保姆的工资也被迫上升——因为他们也要和程序员、AI 工程师争夺劳动力市场。

我家的玻璃维修就是这种典型案例：

玻璃的生产高度自动化，价格几乎透明；但安装仍然依赖人工、吊装、运输协调——效率几乎没变，却越来越贵。

AI 时代的“双效应叠加”

AI 的到来，让 Jevons 悖论与 Baumol 效应同时发生，下表总结了主要领域的表现：

这是对比 Jevons 效应和 Baumol 效应在不同领域的具体体现：

领域	Jevons 效应（越便宜越用）	Baumol 效应（越低效越贵）
算力与模型	推理成本下降，调用量爆炸	GPU 电费、机房维护成本上升
内容生产	文案生成几乎零成本	审核与合规人力成本上升
制造业	自动化提升产能	安装、运输、售后人力成本增加
教育服务	AI 教师提升效率	线下辅导、家教价格攀升

表 1: AI 时代主要领域的 Jevons 与 Baumol 效应对比

因此，我们正进入一个有趣的时代：AI 让数字世界趋近零成本，却让现实世界变得昂贵。

你可以几秒钟生成一份 3D 装修设计图，但真正请工人来装玻璃、走电线，依旧要花几天几千块。

反身型 Baumol 效应：人类“最后 1%”的高价时代

AI 自动化 99% 的流程后，剩下那 1% 必须由人完成的工作，反而会成为新的高价值环节。

例如：

放射科医生：AI 能读片，但“签字责任”必须是人类；
自动驾驶：AI 能开车，但仍需人类安全员监管；
软件系统：AI 能生成代码，但架构审核、上线批准仍由人负责。

这就是所谓的“反身型 Baumol 效应（Reflexive Turbo-Baumol Effect）”：

当 AI 自动化绝大部分工作时，剩下那 1% 的人类劳动，反而变成稀缺资源与监管瓶颈。

中国语境：从“廉价劳动力”到“昂贵人工”

过去二十年，中国的经济增长建立在廉价劳动力 + 技术扩张上。而现在，AI 让脑力劳动变得更便宜，反而凸显了体力劳动的稀缺与不可替代性。

你可以几分钟让 AI 写一本书、生成一本报告，但要修一块玻璃、装一扇窗、换一台热水器，仍然要几个人、几小时、几百公里的物流。

这是一种结构性反转：

AI 让“虚拟工作”无限扩张；
但“物理劳动”却在变成奢侈品。

未来的通胀，不在工厂，而在现实服务业。这可能是未来十年中国社会的新常态。

AI 富足时代的“贵人工业”

当我们谈论 AI 带来的生产力革命时，也许更该问自己：

谁来完成那最后的 1%？

AI 让虚拟世界趋近零成本，但让现实世界的“人类协作”成本暴露无遗。

未来十年，真正稀缺的，不是算力，而是人力的最后一公里能力：懂机械、能上门、能动手、能承担责任的人。

也许那时，“修玻璃的人”才是真正的贵族劳动者。

总结

AI 正在重塑生产力结构，让数字世界的边际成本趋近于零，但也让现实世界的人工与服务变得前所未有地昂贵。Jevons 悖论和 Baumol 效应的叠加，将深刻影响未来中国的经济与社会分工。我们需要重新认识“人力”的价值，尤其是那些无法被自动化取代的最后一公里能力。

参考资料

Why AC is cheap, but AC repair is a luxury - a16z.substack.com

GitHub Copilot CLI 自定义 Agent 实战：打造命令行 AI 助手

Jimmy Song — Mon, 03 Nov 2025 15:10:20 +0000

让命令行成为你的 AI 战友，而不仅仅是工具箱。

背景：从 AI 补全到 AI 助手

自 2024 年底 GitHub 推出 Copilot Chat、CLI、Workspace 三件套以来，Copilot 已经从“智能补全”演进为“AI Pair Programmer”（AI 编程助手）。2025 年 10 月，GitHub 官方宣布 Copilot CLI（命令行版 Copilot）支持自定义 Agent 与任务委托。这一更新让开发者能够在终端中构建属于自己的 AI 助手，让 Copilot 不仅能补全代码，还能自动执行复杂任务、创建分支、发起 PR，甚至帮你重构整个模块。

本文将介绍 Copilot CLI 的核心能力，并结合实际场景，帮助你快速上手自定义 Agent。

功能概览

Copilot CLI 的自定义 Agent 功能主要包括以下几个方面。每项能力都极大提升了命令行 AI 助手的实用性和灵活性。

自定义 Agent

自定义 Agent 让 Copilot 理解你的上下文与工作流，成为真正懂你的命令行助手。你可以在不同层级定义 Agent：

项目级：.github/agents/
组织级：{org}/.github/agents/
全局配置：~/.copilot/agents/

下面是一个典型的 Agent 配置示例，适用于 Kubernetes 场景。此配置文件定义了 Agent 的基本信息、可用工具和工作流说明，便于在实际开发中快速复用。

---
name: k8s-assistant
description: "Cloud-native specialist that helps manage and generate Kubernetes YAML manifests."
tools:
 - read
 - search
 - edit
 - shell
---

### 🧭 Kubernetes Agent Instructions

You are a Kubernetes specialist assisting developers and platform engineers.

#### 🎯 Goals
- Generate, explain, and optimize Kubernetes YAML configurations.
- Diagnose `kubectl` outputs and suggest fixes.
- Automate Helm values and chart templating.

#### ⚙️ Workflow
1. Use `kubectl` and `helm` to validate and apply configurations.
2. Parse YAMLs using `yq`.
3. Recommend improvements for manifests (resource requests, labels, probes, etc.).

将该文件保存到 .github/agents/ 目录下，并命名为 k8s.agent.md，然后在 copilot 交互式命令中通过如下命令调用自定义 Agent：

/agent k8s

此时，你的终端就拥有了一个“Kubernetes 智能体”，如下图所示，可以帮你生成、优化、解释 YAML，甚至直接运行相关命令。

在下图中展示了实际在 Copilot CLI 中使用 Kubernetes 智能体的效果：

图 1: 在 Copilot CLI 中使用 Kubernetes 智能体

你可以通过 /agent 命令来调用不同的 Agent，或者通过 /delegate 命令来委托任务。

当我询问 Copilot CLI 如何创建一个 Kubernetes 智能体或 YAML 配置中有什么问题时，它可以提供详细的解释和优化建议。下图展示了与 Kubernetes 智能体交互的实际场景：

图 2: 在 Copilot CLI 中与 Kubernetes 智能体交互

注：更多 Agent 配置请参考 awesome-copilot。

委托任务（/delegate）

委托任务功能让 Copilot CLI 能够自动化处理代码修改和协作流程。下面的命令展示了如何通过 /delegate 实现自动化重构：

/delegate "Refactor the logging module for performance"

执行上述命令后，CLI 会自动完成以下步骤：

提交未暂存改动到新分支；
启动 Copilot Coding Agent；
在后台自动修改代码；
创建 Draft Pull Request；
返回链接供你审阅。

这种方式极大简化了“写代码 + 发起 PR”的流程，非常适合团队协作、自动修复与异步开发。

性能优化

新版 Copilot CLI 在性能上也有显著提升：

输出支持 token-by-token 流式显示，响应更及时；
并行调用工具，提高整体处理速度；
内存占用更低，修复了闪屏等体验问题；
与 GitHub MCP Server 的集成更加顺畅。

应用场景

自定义 Agent 能够覆盖多种开发与协作场景。下表总结了典型应用及其说明，帮助你根据实际需求选择合适的 Agent 类型。

场景	说明
云原生工程师	定义“k8s-agent”，直接在命令行生成 YAML、执行 kubectl 检查。
DevOps 团队	创建“pipeline-agent”，帮你生成 CI/CD 流程、Lint 脚本。
技术布道者 / DevRel	为示例仓库定义“demo-agent”，自动生成样例与文档。
独立开发者 / 一人公司	定义“release-agent”，帮你自动打包、发布、创建版本说明。

表 1: Copilot CLI Agent 应用场景

结合 MCP（Model Context Protocol）

GitHub Copilot CLI 内置了对 MCP（Model Context Protocol）的支持。MCP 让 Agent 能够直接访问本地文件或外部数据源，实现上下文注入与状态持久化。这为构建“AI-native CLI 工具链”提供了基础能力。

通过 MCP，Agent 可以：

访问和处理本地或远程数据；
保持任务上下文的连续性；
支持更复杂的自动化和集成场景。

在下方的流程图中，展示了 Copilot CLI 调用工具（tool）的整体流程，有助于理解其自动化决策机制。

图 3: Copilot 的 tool 调用流程

总结

GitHub Copilot CLI 的 Agent 功能标志着“AI 在命令行的原生化”。它不仅是补全命令的工具，更是可以执行复杂逻辑的 AI 工作流引擎。随着 MCP 生态逐步完善，未来的 CLI 可能不再是命令集合，而是 AI 助手的集合。

参考文献

从 Kubernetes 到 Qwen：AI 时代的“开源”为何变了？

Jimmy Song — Thu, 30 Oct 2025 11:31:01 +0000

AI 时代的开源已不再是“看得见源码”，而是“能加载模型、能微调智能”。美国厂商闭源筑护城河，中国厂商开源抢生态，开源的意义和玩法都发生了根本变化。

图 1: AI 时代开源的逻辑彻底变了

引言

十年前，云原生浪潮掀起时，美国的 Google、Red Hat、Docker 等公司开源了大量基础设施软件——Kubernetes、Docker、Istio 成了全球开发者的共同语言。

然而进入大模型时代，局面却完全反转：美国科技公司几乎不再开源核心模型，而中国厂商（如智谱、阿里、面壁、零一万物、月之暗面等）却频频发布开源大模型。为什么会出现这种转变？“AI 开源”与“基础设施开源”又有什么根本区别？

云原生时代与 AI 时代的开源逻辑变化

下表对比了云原生与 AI 时代开源的核心逻辑、盈利方式和资源依赖。

时代	代表技术	开源核心逻辑	盈利方式	对资源依赖
云原生时代（2010s）	Istio、Kubernetes、Docker	共建标准、扩张生态	托管服务（GKE、EKS）	CPU 级算力，可社区驱动
AI 大模型时代（2020s）	Ollama、GPT、Qwen	模型即资产、控制数据	API 服务或闭源 SaaS	GPU 级算力、集中化

表 1: 云原生与 AI 时代开源逻辑对比

云原生开源强调“共建标准”，而 AI 大模型开源则意味着“核心资产的开放”，两者的本质和动因截然不同。

美国公司为何不再真正开源

美国科技公司在 AI 时代选择闭源，背后有多重原因：

商业逻辑转向护城河思维：训练成本高昂，模型权重成为核心壁垒，开源等于让出竞争力。
算力与数据不可复制：社区难以复现 GPT-4 级别模型。
安全与合规约束：模型权重可能涉及用户数据，监管严格。
“开放”被重新定义为“API 可访问”：开放平台更多指接口开放，而非代码与权重开放。

中国公司为何更愿意开源

中国厂商在 AI 领域积极开源，主要基于以下考量：

用开源换生态、换认知，快速建立品牌影响力。
“开源 + 商业许可”双轨模式，兼顾生态扩展与商业收益。
数据政策环境更灵活，政策鼓励自主模型。
国家战略驱动，“自主可控”与“开源生态”成为科技战略重点。

开源载体的迁移：从 GitHub 到 Hugging Face

开源的载体也发生了变化。下表展示了 GitHub 与 Hugging Face 在开源形态上的区别。

平台	时代	核心资产	开源形态
GitHub	软件 / 云原生	源码 (.go /.py /.js)	可编译、可运行
Hugging Face	AI 模型	模型权重 + Tokenizer + 推理脚本	可加载、可微调

表 2: GitHub 与 Hugging Face 开源形态对比

GitHub 主要开源“程序逻辑”，而 Hugging Face 则开源“模型智力”，两者的核心资产完全不同。

AI 开源的核心要素

AI 时代的开源不仅仅是代码开放，更包括权重、推理代码和微调能力。下面分别说明三大要素。

开放权重（Weights）

模型训练后的全部知识都存储在权重参数中。拥有权重即拥有模型的“智力本体”。闭源模型（如 GPT-4）只提供 API，不开放权重。

开放推理代码（Inference Code）

推理代码定义了如何加载权重、分词、并发计算和显存优化。下方代码演示了如何加载 Qwen3 模型：

from transformers import AutoModelForCausalLM, AutoTokenizer

# 加载模型与分词器
model_name = "Qwen/Qwen3-4B-Instruct-2507"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
 model_name,
 torch_dtype="auto", # 自动选择 FP16 或 FP32
 device_map="auto" # 自动分配到 GPU / CPU
)

# 推理
prompt = "你好，请简要介绍一下大模型的微调原理。"
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

微调（Fine-tuning）

微调是在开源模型基础上再训练，使其适应特定数据和场景。常见方式有 LoRA / QLoRA，成本低，能让通用模型变成企业专属助手。

企业为何选择自部署而非 API

企业在实际应用中，往往更倾向于自部署开源模型。下表总结了主要原因和说明。

原因	说明
数据隐私	敏感数据不能外传
成本可控	API 按调用计费，长期昂贵
可定制性	可结合企业知识做 RAG / Agent
可运维性	可离线运行、统一监控、合规部署

表 3: 企业自部署开源模型的主要原因

Qwen3-4B-Instruct-2507 模型结构与使用

以 Qwen3-4B-Instruct-2507 为例，介绍 Hugging Face 上模型的目录结构和使用方法。

目录结构说明

模型下载后目录结构如下：

图 2: Qwen3-4B-Instruct-2507 目录结构

开源模型的目录结构可以用下图表示：

图 3: 开源大模型目录结构

在开源模型的目录结构中，model.safetensors 文件即为模型权重，存储数十亿参数。还有其他文件，如 README.md、LICENSE、.gitattributes，其作用说明如下：

分类	文件	作用说明
模型定义	`config.json`, `model.safetensors.*`, `model.safetensors.index.json`	定义模型结构与参数权重
分词系统	`tokenizer.json`, `tokenizer_config.json`, `vocab.json`, `merges.txt`	定义文本输入输出的编码方式
推理配置	`generation_config.json`	控制生成策略（温度、top_p 等）
元信息	`README.md`, `LICENSE`, `.gitattributes`	模型介绍、许可、Git 属性

表 4: 开源模型的目录结构

加载与推理代码示例

以下代码展示了如何加载并运行 Qwen3-4B-Instruct-2507 模型：

from transformers import AutoTokenizer, AutoModelForCausalLM

# 加载分词器和模型
tokenizer = AutoTokenizer.from_pretrained(
 "Qwen/Qwen3-4B-Instruct-2507",
 trust_remote_code=True
)
model = AutoModelForCausalLM.from_pretrained(
 "Qwen/Qwen3-4B-Instruct-2507",
 device_map="auto"
)

# 构造输入并推理
prompt = "你好，解释一下云原生的意义。"
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

如显存不足，可采用量化加载方式：

mdl = AutoModelForCausalLM.from_pretrained(
 "Qwen/Qwen3-4B-Instruct-2507",
 device_map="auto",
 load_in_8bit=True
)

开源 LLM 的开发者应用场景

开源大模型为开发者带来了丰富的应用场景。下表总结了常见方向、用途和工具。

方向	能做的事	工具
聊天 / 助手	本地 ChatGPT	LM Studio、TextGen WebUI
知识库 RAG	接私有数据问答	LangChain、LlamaIndex
智能体 Agent	任务执行、工具调用	LangGraph、Autogen
微调 / 适配	定制企业知识	PEFT、LoRA
模型服务	部署为 API 服务	vLLM、TGI、Ollama
研究实验	模型压缩、量化	BitsAndBytes、FlashAttention

表 5: 开源 LLM 的典型应用场景与工具

开源模型生命周期

开源模型从下载到生产上线的完整生命周期如下：

下载模型权重
加载推理代码
本地推理或部署服务
微调专属数据
企业集成 RAG / Agent
上线生产环境

如何判断开源大模型的许可证

下载一个开源模型 = 拥有一颗可加载、可训练、可商用的“智能大脑”；但能不能拿它赚钱，还得看它的 License。

同传统的开源项目一样，对于大模型，是否可以商用，也需要关注许可证。

查看方法：

Hugging Face 模型主页右上角 → License: ...
仓库根目录下的 LICENSE 或 README.md 文件

简要的判断流程如下：

图 4: 开源大模型许可证判断流程

总结

AI 时代的开源已从“能看源码”转变为“能加载模型、能微调智能”。美国厂商以闭源维护商业护城河，中国厂商则用开源抢占生态高地。开源的真正价值在于赋能开发者，让每个人都能拥有属于自己的“通用大脑”，构建智能基础设施。

Jimmy Song – 博客

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

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

AI 爆发带来的聚焦

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

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

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

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

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

总结

参考文献

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

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

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

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

为什么最终是“词元”？

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

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

一个更贴近翻译者的结论

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

最后的一个判断

总结

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

老朋友、新周期

Maintainer Summit 在讨论什么？

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

HAMi：从“项目”到“参考样本”

值得警惕：AI Infra 创业还没真正爆发

1）这个层还没 Fully formed

2）或者，这一层门槛很高

我的判断

最后

HAMi 官网重构：HAMi 文档与官网为什么要全面改版

为什么要重构官网和文档

这次重构重点做了什么

首页重新设计，信息架构彻底梳理

架构图重绘，让技术表达更直观

新增案例、社区与生态表达，让影响力更可见

博客样式和内容阅读体验整体升级

移动端体验做了大量细节优化

Footer 重做，底部信息不再只是“收尾”

替换掉不好用的 Algolia 搜索，回到站点内建搜索

这次改版对 HAMi 社区意味着什么

作为社区贡献者，我最看重这次改版的三点

总结

GTC 2026 前夜：AI 正在成为新的基础设施

工业革命的视角

第一次工业革命：蒸汽

第二次工业革命：电力

第三次工业革命：计算机

第四次工业革命：互联网与智能化

AI 的真正意义

NVIDIA 的 Five-Layer Cake

GTC 2026 可能释放的几个信号

推理计算

Agentic AI

Agent 平台

Agent 改变计算负载

AI 原生基础设施

GPU 是一等资源

异构算力

GPU 共享

AI 调度

一个可能的 AI 技术栈

我的判断

总结

当 GPU 走向开放调度：HAMi 2025 年的结构性转变

引言

为什么“开放调度”很重要

资源表达的标准化

设备注入的标准化

HAMi：从“共享工具”到“可治理数据平面”

数据平面视角

调度机制：不是替换，而是增强

生产证据：从“能不能共享”到“能不能运营”

国产芯片的崛起：智谱 GLM-5 的实践

对密瓜智能的战略意义

双层机制：开源 vs 商业

商业化的正确落点

前瞻判断：接下来的 2–3 年