LLM on Zampo Blog

AI 写了 10 万行 K8s 代码，真正难的不是生成

Mon, 06 Jul 2026 18:20:00 +0800

你可能已经用了几年 K8s。

Deployment 会写，Service 会配，Pod 挂了也知道先看 events。可真要问 kubelet、scheduler、controller、CNI 在里面怎么配合，很多人心里还是一团黑箱。

你也可能已经开始用 AI 写代码。

让它补测试、改函数、迁移一段逻辑，确实省时间。但到了 code review，你又会忍不住多看两眼：这个 helper 哪来的？这个边界条件是不是少了？它看起来很顺，真的和原来的行为一样吗？

webernetes 这个项目有意思，就卡在这两个不信任中间。

Sam Rose 在 ngrok 博客里写，他把 Kubernetes 的一部分核心行为搬进了浏览器：kubelet、调度器、deployment controller、kube-proxy、CNI 网络模拟、容器运行时。博客开头还给了几个很刺眼的数字：接近 10 万行代码，552 个 commit，629 个文件，两个月。

更反常识的是，它的 gzip 后体积大约 140KiB。

作为对比，一个 Go 写的 hello world 编译成 WebAssembly，gzip 后大约 540KiB。也就是说，你直觉里那个“把 K8s 编译成 WASM 塞进浏览器”的方案，连一个 hello world 的体积都先把你劝退了。

所以 webernetes 最值得看的地方，不是“AI 写了 10 万行代码”。

真正值得看的是：这些 AI 写出来的代码，最后是怎么被人审查、被测试、被对照到可以相信的。

它不是把完整 K8s 编译进浏览器

很多人第一反应会问：这是不是把 Kubernetes 编译成 WebAssembly？

你装的 Ollama，在多用户场景下会慢 20 倍——但这不是它的错

Mon, 29 Jun 2026 20:00:00 +0800

你装了 Ollama，跑个 Qwen3 8B。一个人用，很流畅。

然后给团队搭了个内部 chatbot。三个人同时用——卡炸了。

你以为是模型太大，换了更小的模型。还是卡。

这时候你可能开始怀疑：是不是 Ollama 性能不行？

不是。问题根本不在于 Ollama 快不快。而在于你把它用在了它不被设计服务的场景里。

一个人 v.s. 三个人，不是「慢一点」，是架构决定的

先说一组数据。同一块 GPU，跑同一个模型：

并发数	Ollama（总 tok/s）	vLLM（总 tok/s）	差距
1	~62	~71	~1.1x
8	~82	~187	~2.3x
50	~155	~920	~5.9x
100+	封顶	继续涨	~15-20x

一个人用，Ollama 和 vLLM 几乎一样快。

两个人开始，vLLM 慢慢拉开距离。

五十个人？Ollama 的吞吐量基本封顶了——请求在排队，后来的等着前面的完成才能开始。vLLM 还在涨。

这不是 Ollama「性能不行」。「性能」这个词让你觉得是优化做得不够，换个版本、换个模型、换个量化格式就能追上。但这不是优化问题——是架构不为此设计。

Ollama 做推理的方式很简单：来一个请求，生成完，再来下一个。它不做 continuous batching。

什么叫 continuous batching？想象一个收银台。传统做法：排一队，一个一个结。轮到你才开始，结完才叫下一个。

Continuous batching 的做法：柜台一有空位，就让新人进来。不等前面的人全结完。柜台利用率直接拉满。

vLLM 就是这样调度请求的。每一轮推理迭代，它重新看一遍「现在谁还需要计算」，有空位就把新请求塞进去。GPU 利用率从 ~50% 拉到 85-92%。

Ollama 的设计目标从来不是「服务多用户」。它的价值是另一件事——让开发者用一条命令跑起一个模型。

1
2


ollama pull qwen3:8b
ollama run qwen3:8b

两条命令，从选模型到本地 API，全程不超过两分钟。这个体验就是 Ollama 的核心竞争力。

tRPC-Agent-Go 快速上手：Go 生态终于有了自己的 Agent 框架

Fri, 26 Jun 2026 10:00:00 +0800

引子：Go 生态的 Agent 空白

如果你是一个 Go 后端开发者，过去两年一定被各种 AI Agent 框架刷过屏。LangChain、CrewAI、AutoGen、LangGraph…… 清一色 Python。而你手上的 Go 项目要做 Agent 能力，选项屈指可数：要么嵌一个 Python 子进程（运维噩梦），要么自己手搓胶水代码（重复造轮子），要么指望社区那几个半成品框架。

这个局面在 2025 年中开始改变。腾讯 tRPC 团队开源了 tRPC-Agent-Go，到今天刚好 13 个月，115 个 Release，1.4k Stars，已经在腾讯元宝、腾讯视频、腾讯新闻等业务线跑过了生产流量。

这篇文章的目标很简单：用 10 分钟让你知道 tRPC-Agent-Go 是什么、能不能用、怎么上手。第二篇再深入工程落地。

tRPC-Agent-Go 是什么

一句话：tRPC-Agent-Go 是腾讯 tRPC 团队出品的 Go 语言生产级 Agent 框架，对标 Python 生态的 LangChain / LangGraph / CrewAI。

它的定位不是"Go 版的 LangChain"，而是自顶向下重新设计：以 Agent 接口为核心执行单元，以图工作流为高级编排手段，以事件流为通信载体。覆盖了单 Agent 对话、多 Agent 协作、图工作流、MCP/A2A/AG-UI 协议、RAG、可观测性、评测等全栈能力。

关键背景数据：

腾讯 tRPC 是覆盖近 200w+ 节点、5w+ 服务的内部 RPC 框架，tRPC-Agent-Go 是其 AI 方向的延伸
已生产验证于腾讯元宝、腾讯视频、腾讯新闻、IMA、QQ 音乐等业务
要求 Go 1.21+，Apache-2.0 协议
不强制依赖 tRPC 框架，可以独立使用

核心概念速览（点到为止）

tRPC-Agent-Go 的核心抽象只有五个 Agent 类型 + 一个 Runner + Tool + Memory，一看就懂。