基础设施
eBPF：内核的可编程边界
eBPF 被大多数人认识的方式是通过 Cilium、Pixie、BCC 这类工具：一种无侵入的 tracing 技术，能在不修改代码的情况下观测进程行为。这个认知框架是准确的，但不完整。 把 eBPF 理解为"更好的 strace"，会错过它更根本的含义：Linux 内核从一个固定功能的黑盒，变成了
AI 基础设施
内存带宽才是瓶颈：AI 芯片的 Roofline 账本
买 GPU 的时候，大多数人盯着的是 FLOPS。A100 312 TFLOPS，H100 989 TFLOPS，H200 更高。这个数字直观，好对比，销售材料里也总是把它放在最显眼的位置。 但如果你真的跑过 LLM 推理，会发现一件让人困惑的事：你的实际算力利用率（MFU）往往只有 30%~50%
AI 基础设施
推理时扩展：另一种 Scaling 的工程账单
过去两年，"Scaling Law 是否失效"的讨论反复出现。支持者说模型能力还在上升，质疑者说边际效益在递减。但争论的焦点已经悄悄从训练时计算转移到了推理时计算。 o1 是这个转变的公开标志。它的核心逻辑是：与其在训练时堆更多 token，不如在推理时给模型更多"思考时间"。这个逻辑在 2025
系统与运行时
WebAssembly 在服务端的漫长旅程
WebAssembly 在浏览器里已经算是成熟技术了。Figma 用它跑渲染引擎，Google Earth 用它处理地图，AutoCAD 用它把 C++ 代码跑在 Web 上。这些用例已经足够有说服力。 但浏览器内的成熟，并没有自动带来服务端的成熟。过去几年，"WASM 将改变服务端架构"的说法一直
AI 基础设施
AI 编译器的现实账单
过去三年，AI 编译器领域密集地涌现了一批工具和框架。Triton、OpenXLA、MLIR、TVM、Halide 改进版……每隔几个月就有一篇论文或一个新项目声称"让工程师用高层语言写出接近手写 CUDA 的性能"。 这个承诺很诱人，因为 CUDA 手写 kernel 是一件极度依赖专家经验的事。
硬件与体系结构
RISC-V 的生态现实
RISC-V 这几年被讲得很多，但讲法两极分化：要么是"开放指令集将改变一切"，要么是"永远只能跑嵌入式"。两种说法都不够准确，但合在一起，大概勾勒出了它真实的处境。 它从哪里来 RISC-V 诞生于 2010 年加州大学伯克利分校的一个课堂项目。设计者的出发点很简单：需要一个干净的指令集做研究，但
AI 基础设施
Agent 工具层工程：设计给 LLM 用的接口
工具是 Agent 能力的物理边界。一个 Agent 能做什么，本质上取决于它有哪些工具、这些工具设计得怎么样。 工具设计这件事，在大多数 Agent 系统里是被严重低估的工程问题。常见的实现方式是：把现有的函数或 API 包一层，写个描述，往 Agent 里一扔，能跑就好。到了生产，问题集中爆发—
AI 基础设施
Context Engineering：不是 Prompt 写得漂亮，而是信息怎么进窗口
"Context Engineering"这个词在过去一年里被提及的频率越来越高。 Andrej Karpathy 在 2025 年说过一句话，大意是：Prompt Engineering 这个词已经低估了真实的工程问题——真正的挑战不是怎么写出漂亮的 prompt，而是怎么在 context 窗口
AI 基础设施
Agent 系统的成本工程：Token 消耗不是运营成本，是架构信号
大多数团队发现成本问题的时机都太晚。 Demo 阶段，一次 Agent 运行消耗几分钱，团队觉得 LLM API 成本完全可控。到了生产，加上完整的系统提示、跨会话记忆检索、多轮工具调用之后，同一个任务的成本变成了几块钱。用户量稍微上来，账单就开始让人难受。 这不是"规模化的代价"，这是架构问题——
AI 基础设施
Agent 评估工程：你怎么知道 Agent 变好了还是变坏了
每次更新模型版本、调整工具描述、修改系统提示，你是怎么判断 Agent 变好了还是变坏了的？ 大多数团队的诚实回答是：看感觉。手动跑几个典型任务，主观判断一下，没有明显退步就上线。 这在 demo 阶段可以接受。在生产里，它意味着你对 Agent 的质量没有任何客观感知——你是在蒙眼开车。 为什么传