虽然AI时代，但作为软件工程的重要技术工程部分，还是要深入掌握云的使用。
在“一台高配服务器”这个约束下，标准 Kubernetes 的控制面本身就是一种负担。kubeadm 部署的 k8s 控制面包含 API Server、Scheduler、Controller Manager、etcd 等独立组件，仅控制面就需要至少 2 vCPU + 2 GB RAM，且各组件独立部署、独立排障。k3s 则把这些打包成一个不到 70 MB 的单一二进制，默认使用 SQLite 作为单节点数据存储，并内置 containerd、Flannel、Traefik Ingress 和 Klipper LB。关键事实：k3s 是 CNCF 认证的 Kubernetes 发行版，不是 fork，也不是“简化版 API”——任何合法的 Kubernetes manifest 在 k3s 上同样生效。
LLM大语言模型发展到今天，已经形成很多成熟的产业链。但绝大部分开发者是有没有算力条件去DIY一个完整的小模型来理解整个LLM的生命周期和训练过程的。现在以Tiny9为例帮助理解整个模型从数据、预训练到最终运行的简单过程示意，帮助理解LLM的运行机制。
设想这样一个问题：一年一个亿，压多少钱？——成本、毛利、利润之外的那笔账
“流水一个亿，净利十个点，赚一千万。”
这句话看似很有杀伤力。听起来，生意已经讲完了：收入有了，利润有了，接下来只剩鼓掌。
但真正做过生意的人，通常不会停在这里。
Geoffrey Hinton 参与的最新 RSI 相关论文，这篇论文真正有价值的地方，不是“AI 马上爆炸”这种标题党，而是它把一个以前比较玄乎科幻的问题，拆成了一个可以观察、测量、验证的工程问题：
当一种生产工具不仅能够生产财富，而且开始能够生产“更强的生产工具”时，问题就从效率问题升级成了增长函数本身的问题，也标志着是 AI 喧嚣之后进入可持续的产业逻辑。
LLM本身只是推理引擎。真正让系统具备“感知—决策—行动—反馈”能力的，是围绕模型构建的 Agent 架构。
趁着十一假期梳理了一下业界最常被验证的八种 Agent 架构模式和实现思路。它们不是互斥选项，而是可以像积木一样组合的工程机制，没有绝对完美的架构。
以下结合业务场景对常见几种 Agent 架构进行简单拆解。个人习惯使用Golang实现Agent。Python暂不做实现。
为什么我们需要关心Token？做环保经济的使用者、开发者
在大型语言模型（LLM）日益普及的今天，无论是调用API还是部署本地模型，Token都是绕不开的核心概念。它不仅是模型处理文本的基本单位，更是成本计量的直接依据。
MySQL InnoDB 引擎采用聚簇索引（Clustered Index）组织数据，主键不仅决定逻辑唯一性，更直接决定数据的物理存储顺序。这一底层机制是 ID 选型的根本约束条件。
业务 ID 解决的是怎么找到某条记录，数据库主键解决的是怎么存好某条记录。别因为它们都叫 ID，就塞进同一个字段！“
自增ID给 InnoDB 用，业务编号（例：订单order_no使用Snowflake ID）给业务用。此方案是业内比较成熟且稳妥的“双ID”设计，在绝大多数业务场景下都能兼顾性能与扩展性。本质上是把“数据库存储主键”和“业务唯一标识”这两个职责解耦，但注意跨库分库分表场景慎用。
如果系统本身就在做分库分表，那自增ID在跨库场景下会重复，这时候可能需要直接用雪花ID做主键，或者用号段模式（如美团开源的Leaf方案）来生成严格递增的全局ID。
大模型时代的算力焦虑与多租户挑战
自2022年底大语言模型（LLM）迎来爆发式增长以来，AI基础设施的焦点逐渐从“如何训练出更大的模型”转移到“如何高效、低成本地推理和部署模型”。在实际的商业化落地中，大模型服务通常以SaaS（Software as a Service）或MaaS（Model as a Service）的形式提供给成百上千个不同的企业或个人用户。这就引入了多租户（Multi-tenancy） 场景。
密码算法是信息安全的基石。
长期以来，全球商用密码领域由美国主导的 RSA、DSA、AES、SHA 系列算法占据绝对主导地位。然而，随着国际形势的变化和自主可控需求的提升，中国自 1990 年代起逐步构建起一套完整的商用密码算法体系——国密算法（简称 GM/T 系列）。
国密算法由国家密码管理局（简称”国密局”）认定和发布，覆盖了对称加密、非对称加密、哈希摘要、数字签名、身份认证等多种密码学原语，形成了从底层算法到上层协议的完整技术栈。
以下将从算法原理、安全强度、性能特征、应用场景四个维度，系统梳理 SM1、SM2、SM3、SM4、SM7、SM9 及祖冲之（ZUC）算法之间的核心差异与用途区别。
其实个人很反对Golang所谓的“面向接口编程”的这种话术推广理念，这对新手来说是一种严重的误导性，编程语言里有很多类似的Slogan也有各种类似的营销话术上的问题，例如Java的那句“一切皆对象”，这话虽然对但强化传达理念的同时又让新手开发者陷入一种潜意识迷茫，往往容易削足适履。
“如无必要，勿增实体。” —— 奥卡姆剃刀定律
Interface 应该定义在消费方，而不是生产方。
Go Interface本身并不是用来“组织代码层级”的，这是interface被“滥用”的根源。
Go 的 interface 被滥用的根源，不是开发者不会写 interface，而是把 interface 当成了组织代码层级、分层结构、模块边界的工具。
实际上，反直觉的是：代码层级本身并不需要 interface 来证明。