AI、云原生与工程实践https://www.krli.org/zh-CNhttps://www.krli.org/2026/10/19/%E4%BB%8B%E7%BB%8D%E6%90%AD%E5%AD%90Dazi/https://www.krli.org/2026/10/19/%E4%BB%8B%E7%BB%8D%E6%90%AD%E5%AD%90Dazi/搭子是我正在做的本地优先桌面 AI 工作伙伴。这篇文章介绍它为什么围绕工作组织简报、会话和档案，以及支撑持续协作的工程取舍。Mon, 19 Oct 2026 02:00:00 GMThttps://www.krli.org/2026/05/08/CXL-%E5%86%85%E5%AD%98%E5%B1%82%E7%BA%A7%E7%9A%84%E4%B8%8B%E4%B8%80%E6%AC%A1%E9%87%8D%E7%BB%84/https://www.krli.org/2026/05/08/CXL-%E5%86%85%E5%AD%98%E5%B1%82%E7%BA%A7%E7%9A%84%E4%B8%8B%E4%B8%80%E6%AC%A1%E9%87%8D%E7%BB%84/内存一直是计算机体系结构里最少被讨论、但最常成为瓶颈的部分。CPU 的进化有 Moore's Law 可以讲，GPU 的进化有 FLOPS 的增长曲线可以讲，内存的进化……大部分时候就是 DDR 的版本号在变，DIMM 的规格在更新，延迟数字在缓慢改善。 CXL（Compute Express LiFri, 08 May 2026 06:00:00 GMThttps://www.krli.org/2026/05/08/Rust-%E8%BF%9B%E5%85%A5Linux%E5%86%85%E6%A0%B8%E4%B9%8B%E5%90%8E/https://www.krli.org/2026/05/08/Rust-%E8%BF%9B%E5%85%A5Linux%E5%86%85%E6%A0%B8%E4%B9%8B%E5%90%8E/Linux 6.1 在 2022 年 12 月合并了第一批 Rust 代码。这件事发生时，内核社区里争论的声音几乎和支持的声音一样大。两年多过去了，尘埃并没有完全落定，但已经足够看清楚一些东西了。 Rust 进入 Linux 内核，不是一个关于编程语言的故事。它是一个关于如何在几千人同时参与的超大型Fri, 08 May 2026 02:00:00 GMThttps://www.krli.org/2026/05/07/Linux-%E8%B0%83%E5%BA%A6%E5%99%A8%E6%8D%A2%E4%BA%86%E5%BF%83%E8%84%8F-EEVDF-%E6%9B%BF%E4%BB%A3-CFS/https://www.krli.org/2026/05/07/Linux-%E8%B0%83%E5%BA%A6%E5%99%A8%E6%8D%A2%E4%BA%86%E5%BF%83%E8%84%8F-EEVDF-%E6%9B%BF%E4%BB%A3-CFS/Linux 6.6 在 2023 年末改掉了沿用十五年的 CFS 调度器，换成了 EEVDF。这件事在内核社区引发过不少讨论，在更广泛的工程圈里几乎没有激起什么水花。 大多数工程师对调度器的感知，停留在"它在底下自动跑，我不用管"。这个感知在大部分场景里没错，但在越来越多的延迟敏感型工作负载里，调度Thu, 07 May 2026 02:00:00 GMThttps://www.krli.org/2026/05/06/eBPF-%E5%86%85%E6%A0%B8%E5%8F%AF%E7%BC%96%E7%A8%8B%E5%8C%96%E8%B5%B0%E5%88%B0%E5%93%AA%E4%B8%80%E6%AD%A5%E4%BA%86/https://www.krli.org/2026/05/06/eBPF-%E5%86%85%E6%A0%B8%E5%8F%AF%E7%BC%96%E7%A8%8B%E5%8C%96%E8%B5%B0%E5%88%B0%E5%93%AA%E4%B8%80%E6%AD%A5%E4%BA%86/2022 年，Brendan Gregg 在一次演讲里说了一句话："eBPF 对 Linux 的意义，就像 JavaScript 对浏览器的意义。" 这个类比被反复引用，但也经常被误解。它的意思不是"eBPF 让内核编程变得更容易"——内核编程从来不容易，eBPF 也没有改变这一点。它的意思是：eBWed, 06 May 2026 02:00:00 GMThttps://www.krli.org/2026/05/05/%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%E7%9A%84%E5%8F%AF%E6%8C%81%E7%BB%AD%E6%80%A7%E5%9B%B0%E5%A2%83/https://www.krli.org/2026/05/05/%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%E7%9A%84%E5%8F%AF%E6%8C%81%E7%BB%AD%E6%80%A7%E5%9B%B0%E5%A2%83/2024 年 3 月，一个叫 Jia Tan 的账号在 XZ Utils 里植入了后门。 XZ Utils 是一个 Linux 压缩工具库，几乎所有主流发行版都预装。这个后门经过精心设计，能在特定条件下劫持 sshd 的认证过程——影响范围是全球所有运行受感染发行版的 Linux 服务器。 让这件事Tue, 05 May 2026 02:00:00 GMThttps://www.krli.org/2026/05/04/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F%E9%87%8C%E7%9A%84%E6%97%B6%E9%97%B4%E9%97%AE%E9%A2%98/https://www.krli.org/2026/05/04/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F%E9%87%8C%E7%9A%84%E6%97%B6%E9%97%B4%E9%97%AE%E9%A2%98/在单机上写代码，时间是理所当然的。System.currentTimeMillis() 返回一个数，sleep(1000) 等一秒，事件有先后顺序，日志按时间戳排列，因果清晰。 一旦把系统拆成多台机器，这个"理所当然"就碎掉了。 --- 物理时钟会漂移 每台机器都有硬件时钟，靠晶振产生频率。晶振不是Mon, 04 May 2026 02:00:00 GMThttps://www.krli.org/2026/05/03/SQLite-%E9%87%8D%E6%96%B0%E8%BF%9B%E5%85%A5%E5%90%8E%E7%AB%AF%E8%A7%86%E9%87%8E/https://www.krli.org/2026/05/03/SQLite-%E9%87%8D%E6%96%B0%E8%BF%9B%E5%85%A5%E5%90%8E%E7%AB%AF%E8%A7%86%E9%87%8E/SQLite 长期背负着一个标签：适合原型开发、移动端、嵌入式，但不适合生产级服务端。这个判断曾经相当准确，但现在值得重新审视。 Cloudflare D1、Turso、Litestream、fly.io 的 LiteFS——这些出现在过去两三年的项目，都在围绕 SQLite 构建可以认真交付的后端Sun, 03 May 2026 02:00:00 GMThttps://www.krli.org/2026/05/02/%E5%90%8E%E9%87%8F%E5%AD%90%E5%AF%86%E7%A0%81%E5%AD%A6%E7%9A%84%E5%AE%89%E9%9D%99%E8%90%BD%E5%9C%B0/https://www.krli.org/2026/05/02/%E5%90%8E%E9%87%8F%E5%AD%90%E5%AF%86%E7%A0%81%E5%AD%A6%E7%9A%84%E5%AE%89%E9%9D%99%E8%90%BD%E5%9C%B0/2024 年 8 月，NIST 正式发布了三项后量子密码学标准：FIPS 203（ML-KEM）、FIPS 204（ML-DSA）、FIPS 205（SLH-DSA）。这件事在密码学圈子里是里程碑式的，在一般技术媒体里几乎没有引起波澜。 大多数工程师对量子计算的感知，停留在"实用量子计算机还很遥远"Sat, 02 May 2026 02:00:00 GMThttps://www.krli.org/2026/05/01/AI%E6%95%B0%E6%8D%AE%E4%B8%AD%E5%BF%83%E7%9A%84%E7%94%B5%E5%8A%9B%E8%B4%A6%E5%8D%95/https://www.krli.org/2026/05/01/AI%E6%95%B0%E6%8D%AE%E4%B8%AD%E5%BF%83%E7%9A%84%E7%94%B5%E5%8A%9B%E8%B4%A6%E5%8D%95/训练一个 GPT-4 量级的模型消耗多少电？估算值在 50 GWh 左右，大约相当于一座小城市一个月的用电量。这个数字在两年前还能让人惊叹一下，现在已经是行业基本盘。 更值得关注的变化是推理侧。训练是一次性的成本，推理是持续的——每天数亿次请求，每次都要经过 GPU。随着 AI 服务的普及和使用量增Fri, 01 May 2026 06:00:00 GMThttps://www.krli.org/2026/05/01/eBPF-%E5%86%85%E6%A0%B8%E7%9A%84%E5%8F%AF%E7%BC%96%E7%A8%8B%E8%BE%B9%E7%95%8C/https://www.krli.org/2026/05/01/eBPF-%E5%86%85%E6%A0%B8%E7%9A%84%E5%8F%AF%E7%BC%96%E7%A8%8B%E8%BE%B9%E7%95%8C/eBPF 被大多数人认识的方式是通过 Cilium、Pixie、BCC 这类工具：一种无侵入的 tracing 技术，能在不修改代码的情况下观测进程行为。这个认知框架是准确的，但不完整。 把 eBPF 理解为"更好的 strace"，会错过它更根本的含义：Linux 内核从一个固定功能的黑盒，变成了Fri, 01 May 2026 02:00:00 GMThttps://www.krli.org/2026/04/29/%E5%86%85%E5%AD%98%E5%B8%A6%E5%AE%BD%E6%89%8D%E6%98%AF%E7%93%B6%E9%A2%88-AI%E8%8A%AF%E7%89%87%E7%9A%84Roofline%E8%B4%A6%E6%9C%AC/https://www.krli.org/2026/04/29/%E5%86%85%E5%AD%98%E5%B8%A6%E5%AE%BD%E6%89%8D%E6%98%AF%E7%93%B6%E9%A2%88-AI%E8%8A%AF%E7%89%87%E7%9A%84Roofline%E8%B4%A6%E6%9C%AC/买 GPU 的时候，大多数人盯着的是 FLOPS。A100 312 TFLOPS，H100 989 TFLOPS，H200 更高。这个数字直观，好对比，销售材料里也总是把它放在最显眼的位置。 但如果你真的跑过 LLM 推理，会发现一件让人困惑的事：你的实际算力利用率（MFU）往往只有 30%~50%Wed, 29 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/28/%E6%8E%A8%E7%90%86%E6%97%B6%E6%89%A9%E5%B1%95-%E5%8F%A6%E4%B8%80%E7%A7%8D-Scaling-%E7%9A%84%E5%B7%A5%E7%A8%8B%E8%B4%A6%E5%8D%95/https://www.krli.org/2026/04/28/%E6%8E%A8%E7%90%86%E6%97%B6%E6%89%A9%E5%B1%95-%E5%8F%A6%E4%B8%80%E7%A7%8D-Scaling-%E7%9A%84%E5%B7%A5%E7%A8%8B%E8%B4%A6%E5%8D%95/过去两年，"Scaling Law 是否失效"的讨论反复出现。支持者说模型能力还在上升，质疑者说边际效益在递减。但争论的焦点已经悄悄从训练时计算转移到了推理时计算。 o1 是这个转变的公开标志。它的核心逻辑是：与其在训练时堆更多 token，不如在推理时给模型更多"思考时间"。这个逻辑在 2025 Tue, 28 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/27/WebAssembly-%E6%9C%8D%E5%8A%A1%E7%AB%AF%E7%9A%84%E6%BC%AB%E9%95%BF%E6%97%85%E7%A8%8B/https://www.krli.org/2026/04/27/WebAssembly-%E6%9C%8D%E5%8A%A1%E7%AB%AF%E7%9A%84%E6%BC%AB%E9%95%BF%E6%97%85%E7%A8%8B/WebAssembly 在浏览器里已经算是成熟技术了。Figma 用它跑渲染引擎，Google Earth 用它处理地图，AutoCAD 用它把 C++ 代码跑在 Web 上。这些用例已经足够有说服力。 但浏览器内的成熟，并没有自动带来服务端的成熟。过去几年，"WASM 将改变服务端架构"的说法一直Mon, 27 Apr 2026 06:00:00 GMThttps://www.krli.org/2026/04/27/AI-%E7%BC%96%E8%AF%91%E5%99%A8%E7%9A%84%E7%8E%B0%E5%AE%9E%E8%B4%A6%E5%8D%95/https://www.krli.org/2026/04/27/AI-%E7%BC%96%E8%AF%91%E5%99%A8%E7%9A%84%E7%8E%B0%E5%AE%9E%E8%B4%A6%E5%8D%95/过去三年，AI 编译器领域密集地涌现了一批工具和框架。Triton、OpenXLA、MLIR、TVM、Halide 改进版……每隔几个月就有一篇论文或一个新项目声称"让工程师用高层语言写出接近手写 CUDA 的性能"。 这个承诺很诱人，因为 CUDA 手写 kernel 是一件极度依赖专家经验的事。Mon, 27 Apr 2026 01:00:00 GMThttps://www.krli.org/2026/04/26/RISC-V-%E7%94%9F%E6%80%81%E7%9A%84%E7%8E%B0%E5%AE%9E%E5%A4%84%E5%A2%83/https://www.krli.org/2026/04/26/RISC-V-%E7%94%9F%E6%80%81%E7%9A%84%E7%8E%B0%E5%AE%9E%E5%A4%84%E5%A2%83/RISC-V 这几年被讲得很多，但讲法两极分化：要么是"开放指令集将改变一切"，要么是"永远只能跑嵌入式"。两种说法都不够准确，但合在一起，大概勾勒出了它真实的处境。 它从哪里来 RISC-V 诞生于 2010 年加州大学伯克利分校的一个课堂项目。设计者的出发点很简单：需要一个干净的指令集做研究，但Sun, 26 Apr 2026 06:00:00 GMThttps://www.krli.org/2026/04/26/Agent-%E5%B7%A5%E5%85%B7%E5%B1%82%E5%B7%A5%E7%A8%8B/https://www.krli.org/2026/04/26/Agent-%E5%B7%A5%E5%85%B7%E5%B1%82%E5%B7%A5%E7%A8%8B/工具是 Agent 能力的物理边界。一个 Agent 能做什么，本质上取决于它有哪些工具、这些工具设计得怎么样。 工具设计这件事，在大多数 Agent 系统里是被严重低估的工程问题。常见的实现方式是：把现有的函数或 API 包一层，写个描述，往 Agent 里一扔，能跑就好。到了生产，问题集中爆发—Sun, 26 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/25/Context-Engineering-%E4%B8%8D%E6%98%AF-Prompt-%E5%86%99%E5%BE%97%E6%BC%82%E4%BA%AE/https://www.krli.org/2026/04/25/Context-Engineering-%E4%B8%8D%E6%98%AF-Prompt-%E5%86%99%E5%BE%97%E6%BC%82%E4%BA%AE/"Context Engineering"这个词在过去一年里被提及的频率越来越高。 Andrej Karpathy 在 2025 年说过一句话，大意是：Prompt Engineering 这个词已经低估了真实的工程问题——真正的挑战不是怎么写出漂亮的 prompt，而是怎么在 context 窗口Sat, 25 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/24/Agent-%E7%B3%BB%E7%BB%9F%E7%9A%84%E6%88%90%E6%9C%AC%E5%B7%A5%E7%A8%8B/https://www.krli.org/2026/04/24/Agent-%E7%B3%BB%E7%BB%9F%E7%9A%84%E6%88%90%E6%9C%AC%E5%B7%A5%E7%A8%8B/大多数团队发现成本问题的时机都太晚。 Demo 阶段，一次 Agent 运行消耗几分钱，团队觉得 LLM API 成本完全可控。到了生产，加上完整的系统提示、跨会话记忆检索、多轮工具调用之后，同一个任务的成本变成了几块钱。用户量稍微上来，账单就开始让人难受。 这不是"规模化的代价"，这是架构问题——Fri, 24 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/23/Agent-%E8%AF%84%E4%BC%B0%E5%B7%A5%E7%A8%8B/https://www.krli.org/2026/04/23/Agent-%E8%AF%84%E4%BC%B0%E5%B7%A5%E7%A8%8B/每次更新模型版本、调整工具描述、修改系统提示，你是怎么判断 Agent 变好了还是变坏了的？ 大多数团队的诚实回答是：看感觉。手动跑几个典型任务，主观判断一下，没有明显退步就上线。 这在 demo 阶段可以接受。在生产里，它意味着你对 Agent 的质量没有任何客观感知——你是在蒙眼开车。 为什么传Thu, 23 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/22/Agent-%E7%B3%BB%E7%BB%9F%E7%9A%84%E5%AE%89%E5%85%A8%E5%B7%A5%E7%A8%8B/https://www.krli.org/2026/04/22/Agent-%E7%B3%BB%E7%BB%9F%E7%9A%84%E5%AE%89%E5%85%A8%E5%B7%A5%E7%A8%8B/传统 LLM 应用的安全问题，主要是输出质量问题：模型说了不该说的话，或者被诱导输出了有害内容。这类问题的影响范围，大致等于"一个人能说的话"的影响范围。 Agent 系统的安全问题性质不同。当 LLM 拿到了工具——可以写文件、调 API、执行代码、提交代码库、发送消息——"输出"就不再是文本，而Wed, 22 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/21/Agent-%E7%B3%BB%E7%BB%9F%E5%8F%AF%E8%A7%82%E6%B5%8B%E6%80%A7/https://www.krli.org/2026/04/21/Agent-%E7%B3%BB%E7%BB%9F%E5%8F%AF%E8%A7%82%E6%B5%8B%E6%80%A7/一个 Agent 在生产环境里执行了一系列操作，最终结果是错的。你怎么知道问题出在哪一步？是模型的推理出了问题，还是工具返回了错误的数据，还是 Orchestrator 给 Executor 的上下文打包有误？ 在传统服务里，这个问题有成熟的答案：日志、链路追踪、指标。三位一体的可观测性体系经过十几Tue, 21 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/20/%E5%BC%80%E6%BA%90%E9%A1%B9%E7%9B%AE%E4%B8%AD%E7%9A%84AI-Agent%E5%AE%9E%E8%B7%B5/https://www.krli.org/2026/04/20/%E5%BC%80%E6%BA%90%E9%A1%B9%E7%9B%AE%E4%B8%AD%E7%9A%84AI-Agent%E5%AE%9E%E8%B7%B5/我们团队从去年开始在几个开源项目里引入 AI Agent，处理 issue triage、PR review 辅助、依赖更新、文档检查等重复性工作。 到目前为止，有些地方跑得比预想好，有些地方踩了不小的坑。这篇是一个实践者视角的工程笔记，不是方案推销。 开源项目的特殊性 在私有项目里引入 AI AgMon, 20 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/19/AI-Maintainer-%E5%BC%80%E6%BA%90%E6%B2%BB%E7%90%86%E5%BC%95%E5%85%A5Agent%E7%9A%84%E5%B7%A5%E7%A8%8B%E8%BE%B9%E7%95%8C/https://www.krli.org/2026/04/19/AI-Maintainer-%E5%BC%80%E6%BA%90%E6%B2%BB%E7%90%86%E5%BC%95%E5%85%A5Agent%E7%9A%84%E5%B7%A5%E7%A8%8B%E8%BE%B9%E7%95%8C/开源维护者的时间大多花在哪里？ 审 PR、回 issue、追依赖更新、跑 CI、做 release note——这些工作重复度高、上下文切换频繁，没有一件能完全自动化，但每一件都有一个固定的认知成本。一个中等规模的开源项目，维护者每周大概花 20-40% 的时间在这类"行政性"工作上，这个比例随着项Sun, 19 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/18/Multi-Agent-%E5%8D%8F%E8%B0%83%E5%8D%8F%E8%AE%AE%E5%B1%82%E8%AE%BE%E8%AE%A1/https://www.krli.org/2026/04/18/Multi-Agent-%E5%8D%8F%E8%B0%83%E5%8D%8F%E8%AE%AE%E5%B1%82%E8%AE%BE%E8%AE%A1/前三篇分别讨论了 Harness 的控制边界、Agentic Memory 的检索本质、工作流编排的状态管理。这篇往上走一层：当多个 Agent 需要真正协作时，协议层是什么样的？ 已解决的问题和还没解决的问题 先做一个现状判断。 工具调用协议，基本成熟。 MCP（Model Context ProSat, 18 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/17/AI-Agent-%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%BC%96%E6%8E%92%E8%AE%BE%E8%AE%A1/https://www.krli.org/2026/04/17/AI-Agent-%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%BC%96%E6%8E%92%E8%AE%BE%E8%AE%A1/大多数 Agent 失败不是因为模型不够聪明，而是因为任务结构不对。 给一个 Agent 一个模糊的长任务，它会开始推理、执行、出错、自我修正，然后在某个节点彻底偏离轨道。这个现象在复杂任务里几乎是必然的，不是 Agent 能力的问题，是任务组织方式的问题。 工作流编排解决的就是这个问题：如何把一个Fri, 17 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/16/Agentic-Memory-%E5%B7%A5%E7%A8%8B%E8%AE%BE%E8%AE%A1/https://www.krli.org/2026/04/16/Agentic-Memory-%E5%B7%A5%E7%A8%8B%E8%AE%BE%E8%AE%A1/几乎所有团队在第一次遇到 Agent 记忆问题时，第一反应都是去找一个向量数据库。 这个直觉不完全错，但它把问题想窄了。Agent 的记忆问题不是"怎么存"，而是"在对的时刻，把对的东西喂给模型"。这是一个检索问题，存储只是检索的前提条件。 先把问题说清楚 Agent 在执行任务时，有两种截然不同的Thu, 16 Apr 2026 02:00:00 GMThttps://www.krli.org/2026/04/15/AI-Agent-Harness%E5%B7%A5%E7%A8%8B%E5%AE%9E%E8%B7%B5/https://www.krli.org/2026/04/15/AI-Agent-Harness%E5%B7%A5%E7%A8%8B%E5%AE%9E%E8%B7%B5/过去一年，"Agent" 这个词被用得极度滥泛。几乎所有能调用 LLM 的系统都开始自称 Agent，从一个简单的 prompt chain 到复杂的多智能体协作框架，混在一起难以区分。 真正值得关注的，是那些在生产环境里实际跑起来的系统，背后有一套东西把它们撑起来——不是模型本身，而是围绕模型构建Wed, 15 Apr 2026 03:00:00 GMThttps://www.krli.org/2026/01/15/llm_inference_parallel_blog/https://www.krli.org/2026/01/15/llm_inference_parallel_blog/聊 LLM 推理并行策略的文章很多，大多数的结论长这个样子：DP 适合模型单卡放得下的场景，TP 适合单层参数量大的情况，PP 适合层数多的模型，实际部署用 3D 并行。 这些话都对，但都没说清楚一件事：这个决策树背后的约束是什么。 技术选型不是在菜单上挑菜，每个选项背后都有它成立的前提条件。理解前Thu, 15 Jan 2026 02:00:00 GMThttps://www.krli.org/2024/11/27/Model-Context-Protocol-%E7%AE%80%E4%BB%8B/https://www.krli.org/2024/11/27/Model-Context-Protocol-%E7%AE%80%E4%BB%8B/Anthropic 今天发布了 Model Context Protocol（MCP）。 消息不算意外。任何在生产环境跑过 AI Agent 的人都会遇到同一堵墙：模型能推理，但它摸不到数据。每接一个数据源，就要写一套胶水代码。这件事不优雅，也不可持续。 MCP 试图解决的，就是这个问题。 --- Wed, 27 Nov 2024 15:39:00 GMThttps://www.krli.org/2024/11/14/%E8%BD%AC%E8%BD%BD-%E6%94%BE%E4%B8%8B%E6%89%8B%E6%9C%BA%E7%B3%BB%E5%88%97/https://www.krli.org/2024/11/14/%E8%BD%AC%E8%BD%BD-%E6%94%BE%E4%B8%8B%E6%89%8B%E6%9C%BA%E7%B3%BB%E5%88%97/放下手机，回归真实 一、原作者的观点 原作者（微博suelence）通过自己的经历，深刻地揭示了手机对人们生活的影响。她指出： 1. 手机让我们逃避现实：在无聊的时候拿起手机，因为我们失去了观察世界的乐趣和能力。 2. 手机让我们失去感知力：太久的虚拟生活，让长着五官手脚的我们，活得越来越没有感受力Thu, 14 Nov 2024 04:14:00 GMThttps://www.krli.org/2024/11/11/%E5%85%B3%E4%BA%8E%E5%86%99%E4%BD%9C/https://www.krli.org/2024/11/11/%E5%85%B3%E4%BA%8E%E5%86%99%E4%BD%9C/莱斯利·兰波特有一句话被反复引用："If you're thinking without writing, you only think you're thinking." 这句话的重量，我在管理开源社区和 AI 基础设施项目的过程中，感受越来越深。 --- 我见过很多工程师，代码写得非常好，方案设Mon, 11 Nov 2024 12:25:00 GMThttps://www.krli.org/2024/11/01/%E4%BA%91%E5%8E%9F%E7%94%9F%E8%BF%90%E7%BB%B4%E4%B8%8E%E4%BC%A0%E7%BB%9F%E8%87%AA%E5%8A%A8%E5%8C%96%E8%BF%90%E7%BB%B4%E7%9A%84%E5%8C%BA%E5%88%AB/https://www.krli.org/2024/11/01/%E4%BA%91%E5%8E%9F%E7%94%9F%E8%BF%90%E7%BB%B4%E4%B8%8E%E4%BC%A0%E7%BB%9F%E8%87%AA%E5%8A%A8%E5%8C%96%E8%BF%90%E7%BB%B4%E7%9A%84%E5%8C%BA%E5%88%AB/"你们用 Kubernetes 了吗？" "用了，我们所有服务都容器化了，用 Helm 管理部署。" "那你们的 Operator 或者 Controller 写了多少？" "……那个还没有。" 这段对话在很多团队里都发生过。工具换了，但运维的思路没换。这是传统自动化运维和云原生运维之间最根本的裂缝Fri, 01 Nov 2024 15:23:11 GMThttps://www.krli.org/2024/10/30/%E5%8A%9F%E4%B8%8D%E5%94%90%E6%8D%90/https://www.krli.org/2024/10/30/%E5%8A%9F%E4%B8%8D%E5%94%90%E6%8D%90/胡适在给毕业生的文章里写过："功不唐捐。没有一点努力是会白白丢了的。" 这句话在 gap 期的第三个月，开始有了具体的重量。 --- 今年花了将近十个月找工作。这段时间并不是想象中的"充电"或"沉淀"，更多时候是一种低烈度的焦虑：不知道哪个投出去的简历会有回音，不知道这段空白时间算是在认真准备还是在Wed, 30 Oct 2024 14:31:00 GMThttps://www.krli.org/2024/10/20/%E5%A3%B0%E6%98%8E%E5%BC%8F%E4%B8%8E%E5%91%BD%E4%BB%A4%E5%BC%8F%EF%BC%9A%E7%BC%96%E7%A8%8B%E4%B8%96%E7%95%8C%E7%9A%84%E4%B8%A4%E7%A7%8D%E6%80%9D%E8%B7%AF/https://www.krli.org/2024/10/20/%E5%A3%B0%E6%98%8E%E5%BC%8F%E4%B8%8E%E5%91%BD%E4%BB%A4%E5%BC%8F%EF%BC%9A%E7%BC%96%E7%A8%8B%E4%B8%96%E7%95%8C%E7%9A%84%E4%B8%A4%E7%A7%8D%E6%80%9D%E8%B7%AF/声明式和命令式的区别，每篇云原生入门文章都会讲。但大多数解释停留在"你描述目标，系统决定过程"这个层面，然后举个 SQL 的例子，结束。 这个解释并没有错，只是它遮蔽了更重要的工程含义。 --- 本质差异不在语法，在谁持有状态 命令式的核心假设：调用方知道当前状态，知道如何从 A 到 B。 bashSun, 20 Oct 2024 07:03:00 GMThttps://www.krli.org/2024/09/22/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-kubernetes%E6%BA%90%E7%A0%81%E5%89%96%E6%9E%90-3-%E5%86%85%E7%BD%AE%E8%B5%84%E6%BA%90%E5%85%A8%E5%9B%BE/https://www.krli.org/2024/09/22/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-kubernetes%E6%BA%90%E7%A0%81%E5%89%96%E6%9E%90-3-%E5%86%85%E7%BD%AE%E8%B5%84%E6%BA%90%E5%85%A8%E5%9B%BE/接着第二篇 GVR 数据结构的话题往下走。搞清楚 Kubernetes 怎么在内部表示资源之后，自然会有一个问题：它到底内置了哪些资源，这些资源是怎么组织的，设计边界在哪？ 这篇是读书过程中整理的"内置资源全图"，但我想绕过那种把所有资源逐一列出来的写法。知道 Deployment 管无状态、StaSun, 22 Sep 2024 03:13:00 GMThttps://www.krli.org/2024/09/22/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-kubernetes%E6%BA%90%E7%A0%81%E5%89%96%E6%9E%90-2-%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/https://www.krli.org/2024/09/22/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-kubernetes%E6%BA%90%E7%A0%81%E5%89%96%E6%9E%90-2-%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/Group、Version、Resource核心数据结构 在整个Kubernetes体系架构中，资源是Kubernetes最重要的概念，可以说Kubernetes的生态系统都围绕着资源运作。Kubernetes系统虽然有相当复杂和众多的功能，但它本质上是一个资源控制系统——注册、管理、调度资源并维护Sun, 22 Sep 2024 03:06:00 GMThttps://www.krli.org/2024/09/22/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-kubernetes%E6%BA%90%E7%A0%81%E5%89%96%E6%9E%90-1/https://www.krli.org/2024/09/22/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0-kubernetes%E6%BA%90%E7%A0%81%E5%89%96%E6%9E%90-1/《Kubernetes 源码剖析》不是一本适合新手的书。它默认你已经会用 K8s，然后带你去看"这些东西为什么这样设计"。读完第一章，我意识到那些我以为自己理解的东西，其实只是停留在 API 层面——我知道怎么写 YAML，但不知道为什么这样写是对的。 真正有价值的，是理解 Kubernetes 的Sun, 22 Sep 2024 02:52:00 GMThttps://www.krli.org/2024/09/21/%E4%BA%91%E5%8E%9F%E7%94%9F%E7%9A%84%E5%BC%80%E5%8F%91%E7%90%86%E5%BF%B5/https://www.krli.org/2024/09/21/%E4%BA%91%E5%8E%9F%E7%94%9F%E7%9A%84%E5%BC%80%E5%8F%91%E7%90%86%E5%BF%B5/一个服务上了 Kubernetes，不代表它是"云原生的"。Kubernetes 会尽力调度、重启、扩容你的服务，但它对你的代码有一份隐性的期望清单——不写进文档，但违反了就会出问题。 这份清单里的大多数条目，开发者在本地开发时不会遇到，只有在生产环境里才会被打脸。 --- SIGTERM 契约：优Sat, 21 Sep 2024 03:13:00 GMThttps://www.krli.org/2024/03/15/Pod%E7%9A%84%E5%90%AF%E5%8A%A8%E8%BF%87%E7%A8%8B/https://www.krli.org/2024/03/15/Pod%E7%9A%84%E5%90%AF%E5%8A%A8%E8%BF%87%E7%A8%8B/大多数 Kubernetes 入门文章会把 Pod 启动过程讲成一个线性的编号列表：API Server 接收请求 → Scheduler 选节点 → kubelet 拉镜像 → 容器启动。 这个描述没有错，但它掩盖了真正重要的东西：这个过程根本不是线性的，它是多个独立控制循环并发协作的结果，而且每Fri, 15 Mar 2024 06:25:00 GMThttps://www.krli.org/2024/01/15/%E5%8F%88%E6%8A%8A%E5%8D%9A%E5%AE%A2%E8%BF%81%E7%A7%BB%E5%88%B0cloudflare%E4%BA%86/https://www.krli.org/2024/01/15/%E5%8F%88%E6%8A%8A%E5%8D%9A%E5%AE%A2%E8%BF%81%E7%A7%BB%E5%88%B0cloudflare%E4%BA%86/这篇文章的动机很简单：DNSPod 对已备案域名的解析做了限制，导致我无法把域名解析到境外的静态托管服务。绕开它的最直接方式，是把 nameserver 切到 Cloudflare，让 CF 接管整个 DNS 层。 这是一次被动迁移，但结果比预期要好。 --- 问题背景 我的博客是 Hexo 静态站Mon, 15 Jan 2024 04:40:00 GMThttps://www.krli.org/2023/09/20/Kubernetes-Operator%E5%BC%80%E5%8F%91%E6%8C%87%E5%8D%97/https://www.krli.org/2023/09/20/Kubernetes-Operator%E5%BC%80%E5%8F%91%E6%8C%87%E5%8D%97/"我们是不是应该写一个 Operator？" 这个问题在架构评审里出现的频率，远超 Operator 实际应该被使用的频率。Operator 是一个功能强大但成本不低的扩展机制——它值得被认真对待，不值得被滥用。 --- 先想清楚为什么要写 Kubernetes 原生提供的控制器（DeploymenWed, 20 Sep 2023 03:15:00 GMThttps://www.krli.org/2023/09/15/%E4%BA%91%E5%8E%9F%E7%94%9F%E7%9A%84%E4%B8%80%E4%BA%9B%E6%A6%82%E5%BF%B5/https://www.krli.org/2023/09/15/%E4%BA%91%E5%8E%9F%E7%94%9F%E7%9A%84%E4%B8%80%E4%BA%9B%E6%A6%82%E5%BF%B5/"云原生"这个词被滥用得已经没什么意义了。每个厂商都说自己的产品是云原生的，每篇架构文章都声称某方案"符合云原生理念"。但真正用过这套东西的人知道，云原生不是一个技术标签，它是一种对系统如何失败和恢复的不同假设。 --- 一个根本性的假设转变 传统运维假设基础设施是稳定的。机器不会随机消失，网络是可Fri, 15 Sep 2023 04:14:00 GMThttps://www.krli.org/2023/02/28/%E5%9C%A8WSL2%E4%B8%AD%E8%8E%B7%E5%8F%96%E5%AE%BF%E4%B8%BB%E6%9C%BAIP/https://www.krli.org/2023/02/28/%E5%9C%A8WSL2%E4%B8%AD%E8%8E%B7%E5%8F%96%E5%AE%BF%E4%B8%BB%E6%9C%BAIP/在 WSL2 里配置代理，绕不开的问题是：WSL2 和 Windows 宿主机不共享网络栈，WSL2 的 IP 每次启动都可能变化，宿主机的 IP 同样如此。 常见的方案是解析 /etc/resolv.conf 里的 nameserver： bash hostip=$(cat /etc/resolvTue, 28 Feb 2023 10:19:56 GMThttps://www.krli.org/2023/01/20/docker0%E7%BD%91%E6%A1%A5/https://www.krli.org/2023/01/20/docker0%E7%BD%91%E6%A1%A5/调试容器网络问题的时候，大多数人习惯先跑 docker inspect，看一眼 IP，ping 一下，然后开始凭感觉排查。这个方式不是不行，只是效率很低。 真正有效的调试姿势，是理解 Docker 的默认网络模型建立在哪几块 Linux 内核原语上，以及这些原语之间是怎么拼在一起的。docker0 Fri, 20 Jan 2023 06:03:00 GMThttps://www.krli.org/2022/03/16/%E6%9E%84%E5%BB%BA%E9%95%9C%E5%83%8F%E7%9A%84%E5%87%A0%E7%A7%8D%E6%96%B9%E5%BC%8F/https://www.krli.org/2022/03/16/%E6%9E%84%E5%BB%BA%E9%95%9C%E5%83%8F%E7%9A%84%E5%87%A0%E7%A7%8D%E6%96%B9%E5%BC%8F/容器镜像构建这件事看起来简单，实际上坑不少。 选错工具不会立刻爆炸，但会在 CI/CD 流水线里积累隐患：构建速度慢、安全审计无从下手、在集群环境里需要挂载 Docker socket 导致权限失控。这篇文章不做工具大全，只讲几个真正值得关注的决策点。 核心问题：要不要依赖 Docker daemoWed, 16 Mar 2022 13:49:00 GMThttps://www.krli.org/2018/04/13/Go-%E8%AF%AD%E8%A8%80-struct%E8%BD%ACmap%E7%9A%84%E4%B8%89%E7%A7%8D%E6%96%B9%E6%B3%95/https://www.krli.org/2018/04/13/Go-%E8%AF%AD%E8%A8%80-struct%E8%BD%ACmap%E7%9A%84%E4%B8%89%E7%A7%8D%E6%96%B9%E6%B3%95/在 Go 里，struct 和 map 各有用途：struct 是强类型、编译期检查的领域模型，map 是动态键值对，适合序列化、动态字段处理、模板渲染等场景。当两者之间需要互转时，有三条路可走，选哪条取决于你对类型信息、性能和字段控制的要求。 一个前置约束 无论用哪种方法，struct 里参与转换Fri, 13 Apr 2018 06:42:00 GMThttps://www.krli.org/2018/04/09/swag%E6%B3%A8%E8%A7%A3%E6%8C%87%E5%8D%97/https://www.krli.org/2018/04/09/swag%E6%B3%A8%E8%A7%A3%E6%8C%87%E5%8D%97/API 文档和代码之间的漂移是微服务项目的慢性病。接口签名改了，文档没跟上，调用方踩坑，全靠口口相传。Swag 解决这个问题的思路是：把文档写进代码注释，工具来生成 Swagger 规范文件。 代价是你必须学一套注解语法。这篇文章把最常用的部分梳理清楚，跳过官方文档里那些模糊的示例。 项目级注解 在Mon, 09 Apr 2018 09:10:00 GMThttps://www.krli.org/2018/04/03/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F-03-%E5%8D%95%E4%BE%8B%E6%A8%A1%E5%BC%8F-Python%E5%AE%9E%E7%8E%B0/https://www.krli.org/2018/04/03/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F-03-%E5%8D%95%E4%BE%8B%E6%A8%A1%E5%BC%8F-Python%E5%AE%9E%E7%8E%B0/单例模式（Singleton Pattern）的意图只有一句话：确保某个类只有一个实例，并提供全局访问点。它是 GoF 23 种设计模式中最被滥用、也最常被误解的一个。 本文梳理 Python 中几种实现方式的本质差异，以及在 AI 基础设施工程中真实触发这个模式的场景。 四种实现方式 1. MetTue, 03 Apr 2018 09:40:00 GMThttps://www.krli.org/2018/04/03/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F-02-%E6%8A%BD%E8%B1%A1%E5%B7%A5%E5%8E%82%E6%A8%A1%E5%BC%8F-Python%E5%AE%9E%E7%8E%B0/https://www.krli.org/2018/04/03/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F-02-%E6%8A%BD%E8%B1%A1%E5%B7%A5%E5%8E%82%E6%A8%A1%E5%BC%8F-Python%E5%AE%9E%E7%8E%B0/抽象工厂（Abstract Factory）解决的问题和工厂方法不同。 工厂方法管的是"怎么创建某一类对象"；抽象工厂管的是"如何保证一组相关对象来自同一个家族"。两者是层次性的差别，不是程度性的差别。 --- 核心约束：产品族一致性 假设你在构建一个 RAG 系统，需要三个组件：LLM 客户端、ETue, 03 Apr 2018 09:38:00 GMThttps://www.krli.org/2018/04/03/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F-01-%E7%AE%80%E5%8D%95%E5%B7%A5%E5%8E%82%E6%A8%A1%E5%BC%8F-Python%E5%AE%9E%E7%8E%B0/https://www.krli.org/2018/04/03/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F-01-%E7%AE%80%E5%8D%95%E5%B7%A5%E5%8E%82%E6%A8%A1%E5%BC%8F-Python%E5%AE%9E%E7%8E%B0/简单工厂模式（Simple Factory）不在 GoF 的 23 种设计模式之列，但它是很多人第一个真正用到的"模式"。它的意图只有一句话：把"该创建哪种对象"的判断逻辑，从调用方剥离出来，集中到一个工厂函数里。 理解这句话之前，先看它解决的是什么问题。 问题：创建逻辑散落在调用方 假设你在写一个Tue, 03 Apr 2018 09:37:00 GMThttps://www.krli.org/2018/04/03/Gin-%E7%B3%BB%E5%88%97%E6%95%99%E7%A8%8B-03-%E4%BD%BF%E7%94%A8Redis/https://www.krli.org/2018/04/03/Gin-%E7%B3%BB%E5%88%97%E6%95%99%E7%A8%8B-03-%E4%BD%BF%E7%94%A8Redis/Gin框架中使用Redis Redis是一种高性能的键值对存储数据库，广泛用于缓存、会话管理、消息队列等场景。在Gin框架中使用Redis可以显著提升应用程序的性能。 一、安装Redis驱动 首先，我们需要安装Go语言的Redis驱动。推荐使用go-redis/redis库，它提供了丰富的API和良Tue, 03 Apr 2018 08:58:00 GMThttps://www.krli.org/2018/04/03/Gin-%E7%B3%BB%E5%88%97%E6%95%99%E7%A8%8B-02-%E4%BD%BF%E7%94%A8MySQL%E6%95%B0%E6%8D%AE%E5%BA%93/https://www.krli.org/2018/04/03/Gin-%E7%B3%BB%E5%88%97%E6%95%99%E7%A8%8B-02-%E4%BD%BF%E7%94%A8MySQL%E6%95%B0%E6%8D%AE%E5%BA%93/在 Go 的 Web 项目里，数据库访问层的选型争论从来没停过：database/sql 原生接口、sqlx、GORM，还是更轻量的 sqlc？每个选项背后都是不同的工程权衡，和"哪个更好用"关系不大，和"你愿意把多少控制权交给库"关系很大。 这篇文章从 database/sql 出发，讲清楚它的设Tue, 03 Apr 2018 01:51:00 GMThttps://www.krli.org/2018/04/02/Python-asyncio%E6%A8%A1%E5%9D%97%E8%AF%A6%E8%A7%A3/https://www.krli.org/2018/04/02/Python-asyncio%E6%A8%A1%E5%9D%97%E8%AF%A6%E8%A7%A3/大多数 asyncio 教程都在讲 API，很少有人讲清楚它到底在解决什么问题，以及它在哪里会让你翻车。 这篇文章不是文档搬运。它来自真实项目里踩过的坑。 --- 异步的本质是什么 先把一个误解排掉：async/await 不让你的代码跑得更快，它让你的 CPU 在等 I/O 的时候不闲着。 这个区Mon, 02 Apr 2018 14:37:00 GMThttps://www.krli.org/2018/04/02/Gin-%E7%B3%BB%E5%88%97%E6%95%99%E7%A8%8B-01/https://www.krli.org/2018/04/02/Gin-%E7%B3%BB%E5%88%97%E6%95%99%E7%A8%8B-01/用 Go 写 HTTP 服务，标准库 net/http 已经够用了。路由注册、Handler 接口、中间件链——基本能力都有。那为什么还需要 Gin？ 这个问题值得先想清楚，再决定要不要引入一个框架依赖。 --- 标准库的边界在哪里 net/http 的路由匹配是前缀树的简单实现，不支持路径参数。写Mon, 02 Apr 2018 07:36:00 GMThttps://www.krli.org/2017/11/10/PythonHooking/https://www.krli.org/2017/11/10/PythonHooking/Monkey patching 是 Python 社区里争议最持久的技术之一。反对它的人说它是"全局副作用的温床"；拥护它的人说它是"动态语言的正当权利"。两边说的都不错，但都没解决一个实际问题：你在什么情况下该用它，在什么情况下该克制。 这篇文章不讲道德，只讲工程判断。 --- Python 对象Fri, 10 Nov 2017 02:34:00 GMT