本文是一份可发布版部署记录。真实 IP、域名、账号、密码、下载链接、业务目录名、机器唯一标识等敏感信息已经替换为占位符。命令中的 <...> 需要按自己的环境替换。 目标与拓扑 这次目标是用三台数据节点部署一套 ClickHouse 高可用集群，拓扑采用： 1 shard x 3 replicas 含义是：集群只有一个逻辑分片，三台机器都保存同一份数据的完整副本。任意一台数据节点宕机时，只要 ClickHouse Keeper 仍然有多数派，剩余节点仍可继续提供读写服务。 规划节点如下： 主机名示例地址角色ch-01<ch-01-ip>ClickHouse Server + ClickHouse Keeperch-02<ch-02-ip>ClickHouse Server + ClickHouse Keeperch-03<ch-03-ip&
接上篇 上一篇用全开源组件（Whisper + Hermes + Edge-TTS）搭了个语音助手，能跑，但体验就是"能用"二字： * 中文识别只有 70 分，方言基本歇菜 * 英文唤醒词"Alexa"喊着别扭 * 说完到回复要等 4-8 秒 * 它说话的时候你插不了嘴 这些问题靠堆开源组件很难根治。于是我去试了火山引擎（字节跳动）的语音服务，结果直接换了条路。 这篇分两段：先讲怎么用火山引擎的 ASR/TTS 替换掉开源组件（小改），再讲怎么上端到端实时语音模型（大改）。 第一段：先把 ASR 和 TTS 换成火山引擎 为什么换 我用豆包输入法的时候发现它语音识别准得离谱。一查，豆包用的就是字节自家的火山引擎 Seed-ASR。开通后有免费额度（
起因 事情是从一块 ESP32-S3 开发板开始的。 我手上有一块 Seeed Studio XIAO ESP32-S3 Sense，带摄像头和麦克风。最初的想法很美好：用这块板子做一个无线语音终端，对着它说话，连到我服务器上跑的 Hermes Agent（一个自托管的 AI agent），让它回答我。 但折腾到一半我突然意识到一件事：我的麦克风、音响、服务器全在家里，为什么要绕一圈用 ESP32？直接把麦克风和音响插到服务器上不就行了？ ESP32 那条路（做无线拾音终端）当然也有价值，但那是"为了学嵌入式而学"，不是解决问题的最短路径。于是这个项目就从"嵌入式项目"变成了"在服务器上拼一个语音助手"。这篇就记录后者。 教训零：先想清楚你要解决的是什么问题。很多时候最优解比你最初设想的简单得多。 目标
作为kiro的骨灰级用户,这篇是我自己折腾 Kiro / Kiro Remote / Ubuntu Server 代理问题后的复盘。 核心不是“怎么配一个代理”，而是先判断：到底是谁在访问外网？ 谁访问外网，代理就要配给谁。 0. 先说结论 Kiro 相关代理大概分三类： 场景真正访问外网的进程在哪里代理应该配在哪里本地 KiroWindows / Mac 本机本机 Clash / Proxifier / 系统代理服务端 Kiro / CLIUbuntu Server 上的 shell、CLI、node、kiro 进程Ubuntu 的环境变量，比如 HTTP_PROXY / HTTPS_PROXYKiro Remote远程 Ubuntu 上的 ~/.kiro-server 和 extensionHost远程 Ubuntu 的 Kiro Server
这篇不是医学建议，只是记录一次三岁孩子生病期间，作为家长从慌乱到逐渐冷静的全过程。 真正重要的不是“我用了什么神药”，而是：怎么观察，什么时候去医院，怎么避免因为焦虑而乱加药。 一、事情开始：周天第一次发烧 这次孩子生病是从周天开始的。 一开始是发烧。和以前不一样的是，以前孩子很多时候发一次烧，退下来之后状态就慢慢好了。但这一次有点拉扯：用了几次退烧药，体温退下去之后又反复，孩子状态也不是特别稳定。 当时最让我焦虑的不是单纯发烧，而是后面出现了比较明显的咳嗽，尤其是痰音很重。 那种声音对家长来说很折磨。听起来像是喉咙里、气管里全是痰，孩子又不会像大人一样把痰咳出来。于是我开始担心：是不是肺炎？是不是细菌感染？是不是要用抗生素？ 后来回头看，这种焦虑很正常，但也最容易导致家长乱判断、乱加药。 二、第一次去医院：急性支气管炎 第一次去医院，医生判断是急性支气管炎。 做了血常规和甲乙流咽拭子。 血常规整体并不吓人：白细胞正常，中性粒细胞没有明显升高，CRP 只是轻度升高。这个结果至少说明一件事：不像典型的严重细菌感染。 甲流、
背景 上一篇讲了 Skill 本身的设计——用户侧 Skill 包、CLI 层、服务端、展示层。但 Skill 后端不是孤立运行的，它需要一套基础设施来解决：谁能调、调多少、花多少钱、上游怎么保护。 这篇讲的是 Skill 后端之外的那些"不性感但不能没有"的系统。 整体拓扑 用户（CLI） │ │ HTTP + API Key ▼ ┌─────────────────────────────────────────────────────┐ │ Gateway（Go） │ │ 鉴权 → 余额检查 → 用户限流 → 路由转发 │ │ │ │ ┌──────────────────────────────────┐ │ │ │ 用户服务（Python/FastAPI）
背景 我做了一套面向 AI Agent 的垂直业务 Skill。 一开始我以为自己只是在做一个“复杂一点的 Skill”。但系统跑通之后，我发现真正有意思的不是业务本身，而是背后的架构问题： 怎么让一个 Agent 可靠地完成一个多步骤、多数据源、需要用户确认、还要生成可交付成果的复杂任务？ 如果只是让 Agent 调一个 API，这件事并不难。 难的是： * 任务不是一步完成，而是很多步骤串起来； * 每一步会产生大量中间数据； * 中间需要用户确认，不能完全自动跑到底； * 外部 API 有凭据、限流、异步任务、失败重试； * 最终结果不能只停留在对话窗口里，而要能保存、分享、复查。 这已经不是“给 Agent 一个工具”那么简单了。 更准确地说，我做的是一个： Agent-facing vertical application package
Harness、Skills、Workflow：三个概念的关系，以及我现在的选择 做了几个比较重的 AI Skill 之后，我开始重新思考一个问题： 我现在做的东西，到底算 Skill、Workflow，还是 Harness？ 一开始我把这三个概念放在同一条线上比较，后来发现这样容易混乱。更准确地说，它们不是同一层级的东西。 * Workflow 是一种确定性流程编排方式。 * Skill 是一种能力封装形态。 * Harness 是一套能力运行与治理框架。 它们不是三选一，也不是谁比谁高级，而是解决不同层级的问题。一个成熟的 Agent 系统里，三者甚至可以同时存在。 一、Workflow：确定性流程编排 Workflow 是最传统、最稳定的工程抽象。 它的核心不是“每一步都完全没有判断”，而是： 流程控制权主要在代码或流程引擎手里。 也就是说，开发者提前定义好： * 有哪些步骤； * 每一步输入是什么； * 每一步输出是什么； * 失败怎么重试； * 哪些分支可以走；
一个真实项目的限流实现记录。不用 Redis，不用令牌桶，纯内存 Go 实现，200 行代码搞定 per-user 限流。 背景 我们有一个多租户的 API Gateway（Go + Gin），后面挂了 4 个业务后端。每个用户通过 API Key 鉴权，不同用户有不同的请求频率限制（RPM，Requests Per Minute）。 需求很简单： * 每个用户独立限流，互不影响 * 限额从数据库读，管理员随时可调 * 超限返回 429，不排队不等待 * 不引入 Redis（单机部署，没必要） 为什么选滑动窗口 常见的限流算法有四种： 算法 优点 缺点 固定窗口 实现最简单 窗口边界有突发问题 滑动窗口
上一篇聊完普通解析、泛域名解析、A 记录、TXT 记录、普通证书和通配证书之后，我对 DNS 的理解已经比以前清楚很多了。 以前我对 DNS 的理解基本停留在： 域名 -> IP 也就是： A 记录 后来才发现，DNS 不只是“把域名解析成 IP”。 它还承担了： 命名 寻址 验证 策略 委派 缓存 排障 这些角色。 这篇算是 DNS 的扩展篇，整理一下接下来还值得补的内容。 目标不是背概念，而是让自己以后遇到 DNS、证书、域名、Caddy、Cloudflare、阿里云解析这些问题时，能知道从哪里下手排查。 一、DNS 不只是
最近在折腾 frp、Caddy、内网穿透和域名分流的时候，我突然发现一个问题： 我以前对 DNS 的理解其实挺片面的。 以前我理解 DNS，大概就是： 域名 -> IP 比如： weini.xin -> 服务器 IP www.weini.xin -> 服务器 IP 也就是说，我过去主要只知道 A 记录。 A 记录确实是 DNS 里最常见、最直观的一种记录，但这次深入折腾之后，我发现 DNS 远不只是“域名转 IP”这么简单。 它其实同时参与了： 域名寻址 服务入口命名 泛域名管理 证书验证
这次踩了一个挺经典的坑：我在云服务器上折腾 frp 的时候，顺手开了 UFW 防火墙，结果把自己 SSH 入口给挡住了。 服务器没死，服务也没坏，但我就是连不上。 最后发现：不是服务器出问题，是我自己把自己关在了门外。 事情背景 我有一台云服务器，上面跑了一些服务： Caddy / Nginx Docker frp 一些 Go / Python / Node / Bun 服务 最近在折腾 frp，用来做内网穿透和服务分流。 因为涉及端口暴露，我当时想着：“要不顺手把 UFW 开起来，做一层本机防火墙？” 这个想法本身没错，但问题是：我这是一台云服务器。 云服务器本来就有一层安全组，比如阿里云安全组、腾讯云安全组、AWS Security Group 之类的。公网入口本来就可以在云后台控制。 结果我在云安全组之外，
陕公网安备61011302002223号