子安饮墨馀三斗，留与卿儿作赋来
Agent 和 Skill 这两个概念讲清楚,你就知道什么时候该用哪个了。
| Skill(技能) | Agent(智能体) | |
|---|---|---|
| 本质 | 一套可复用的工作流程/操作手册 | 一个有独立人设 + 工具 + 知识的 AI 助手 |
| 作用 | 教会 AI "遇到这类任务怎么做" | 打包成一个可以直接对话/派任务的对象 |
| 谁在调用 | 由当前 AI(比如我)在需要时临时加载 | 用户从 agent 选择器里主动选中它来对话 |
| 有没有独立身份 | 没有,它只是知识片段 | 有,有名字、描述、欢迎语、启动提示 |
| 能否绑定资源 | 一般只带流程和脚本 | 可绑定参考文件、知识空间、连接器(connector)、能力开... |
AI Agent 上线后，Token 账单往往是最大的"惊喜"。一个中等规模的客服 Agent，日均处理 5000 次对话，每次对话平均消耗 4000 tokens，按 Claude/GPT-4 级别模型计算，月费轻松突破 $3000+。更扎心的是——70% 以上的请求存在高度相似性，重复为相同问题付费。
真实场景：某 SaaS 平台的运维 Agent，处理告警自动诊断。80% 的告警是同类问题（CPU 高、磁盘满、OOM），每次都从头推理，token 白白烧掉。
三层优化策略，叠加使用可降低 50-70% 的 Token 开销：
业务日活突破千万，Redis 单线程瓶颈暴露无遗：QPS 从 10 万飙到 50 万后，单实例 CPU 打满，只能靠 Redis Cluster 横向扩展。然而 Cluster 模式带来的运维代价不小——数据迁移 slot、客户端 MOVED/ASK 重定向、跨 slot 事务限制、节点故障时的 failover 抖动，6 节点起步的资源开销也让成本翻了 3 倍。
如果有一款 完全兼容 Redis 协议 的内存数据库，单节点就能吃满多核 CPU、扛住百万 QPS，运维复杂度直降一个量级——这就是 DragonflyDB 的定位。
Dragon...
运维团队用 Terraform 管理基础设施已是标配，但随着规模增长，HCL 的局限性越来越明显：
count、for_each、dynamic 嵌套三层以上可读性断崖式下跌terratest 要写 Go 代码，跨语言维护成本高Pulumi 的思路很直接：用你已经会的编程语言（Python/Go/TypeScript/J...
运维 Kubernetes 集群，节点层面最头疼的三件事：
传统方案是用 Ansible/Cloud-Init 做配置收敛，但本质上还是"可变基础设施"。节点跑久了，谁也不敢保证状态一致。
Talos Linux 的解法很彻底：去掉 SSH、去掉 shell、去掉包管理器，整个 OS 只通过 API 管理，...
当你的 Terraform 项目从 3 个环境扩展到 10+ 个 AWS 账户、每个账户 20+ 个模块时，你会遇到这些问题：
backend.tf、provider.tf，改一处要改十几个文件terraform -chdir 和 workspaces 能解决部分问题，但面对多账...
你的 AI Agent 上线了，Demo 阶段一切顺利。但当日均请求量破万后，问题接踵而至：
本质上，LLM API 是你系统中最不稳定的外部依赖。传统 SRE 的可靠性模式——重试、降级、熔断——在 Agent 场景下需要针对性适配。
构建 4 层防御体系：智能重试 → 模型降级 → 熔断保护 → 成本熔断，让 Agent 在生产环...
用过 Tailscale 的运维都知道它"开箱即用"的爽感——WireGuard 内核加持、NAT 穿透丝滑、ACL 一键下发。但当你把它用到生产环境，痛点逐渐暴露：
如果你需要 ...
AI 应用落地后，向量检索是绕不过的核心环节。pgvector 适合轻量场景，但当向量数据量超过千万级、QPS 要求 > 1000、需要多租户隔离时，你需要一个专用的向量数据库。
Qdrant 是当前最活跃的开源向量数据库之一（Rust 编写，性能优异），支持分布式集群、丰富的过滤条件、多向量存储。问题在于：从 Docker 单机跑通到生产集群稳定运行，中间有大量避坑细节。
本文给出从 0 到生产就绪的完整路径。
| 维度 | 选型/配置 |
|---|---|
| 部署形态 | Kubernetes StatefulSet，3 节点 Raft 集群 |
| 存储 | NVMe SSD（IOPS 敏... |
某生产 Aurora MySQL 集群上有两张日历相关的大表，需要把两个 varchar(255) 字段扩展到 varchar(500)。看似只是一条 ALTER TABLE MODIFY COLUMN，但这两张表分别是 6000 万行 / 37GB 和 3500 万行 / 28GB，而且集群还被另一套业务共用。
如果直接执行原生 ALTER TABLE，会踩到 MySQL 的一个经典陷阱：
InnoDB 的
MODIFY COLUMN在涉及字符集 / COLLATE 变更时，会强制走ALGORITHM=COPY（全表重建），即使你显式写ALGORITHM=INPLACE...