很多团队用 Redis 或 MySQL 存"谁是主、锁在谁手上"这类集群状态，网络一分区就两边各自称主，出现脑裂。根因不是代码写得烂，是这两种库的复制模型本就不保证"分区的少数派会主动退位"。etcd 底层是 Raft，用多数派（quorum）把这件事写进了协议：拿不到多数派票就当不了主、提交不了写，少数派自动失效。这篇讲清楚问题、根因和解法——etcd 的拓扑怎么摆、选主/锁/配置下发怎么用、生产上的最佳实践，以及一串真能让你半夜被叫起来的坑。

很多人一上来就问"异地双活用什么库",顺序反了。先得想清楚容灾要做到什么程度（RTO/RPO），再决定要不要双活、双活怎么分层，最后才落到数据层选型。这篇按这个顺序走一遍：先讲容灾的两把尺子和五档常用做法，再讲双活为什么只是其中一档、难在分层，最后以 Redis 为例把数据层选型讲透——拓扑、故障切换、双向复制、Valkey 差异，一样不落。

网络会出的岔子一长串——分区、脑裂、闪断、非对称路由、DNS 故障、丢包、抖动、拥塞、时钟漂移——它们全归结为 CAP 里那个躲不掉的 P，所以真正的选择题只在 C 和 A 之间。网络交易选 C，音视频会议和实时通信选 A。本文先按类把网络问题列全，再结合我最近踩的几次坑，重点讲 AP + 最终一致性在实时通信里怎么落地：媒体面为什么天生 AP、信令面的冲突怎么和解、以及什么东西绝对不能最终一致。

很多人以为异地双活的音视频服务，难在 FreeSWITCH 怎么集群。其实 FreeSWITCH 这层信令早有成熟的无状态做法，真正的坑在两处：一是跨机房的 MySQL 怎么同时写不打架，二是活跃通话的会话和媒体流钉死在单机房、切不过去。这篇讲清这三层各自的一致性模型，为什么信令可以 AP、计费必须 CP、媒体只能就近锚定，以及一套能落地的分层方案。

2025 年的 DORA 报告给所有狂热押注 AI 编码工具的管理者和工程师泼了一盆清醒的冷水：AI 不是团队能力的替代品，而是组织系统的放大器。成熟的工程团队借它跑得更快更稳，而流程混乱、测试匮乏、架构腐化的团队，只会被 AI 加速推向事故与返工的深渊。本文拆解 2025 DORA 报告的核心洞察：AI 改变了什么、为什么它会同时推高吞吐量与稳定性风险、企业必须具备的七项基础能力、内部上下文的关键价值，并给出一套可在团队落地的七步实操框架。

单个项目的知识库用 Sphinx + MyST + Mermaid 不难建，难的是一个软件业务由七八个仓库拼起来之后，那些横跨仓库的知识落进了缝里。这其实是个老问题——Eric Evans 在 2003 年就用 DDD 回答过：限界上下文、统一语言、上下文映射。本文把 DDD 的这三件武器搬到知识库上，给出一个联邦式结构（事实源在各仓库，领域层只写三类文件，索引层可重建），再详细讲人和不同 AI 工具（Cursor、Codex、Claude Code）如何通过"写-管-读"闭环共同维护它，以及 MCP 怎么做统一出口。附四类原料的处理法、业界产品对照、按链路落地的顺序、治理清单，和一份带链接的参考文献。

FreeSWITCH 是一台优秀的媒体/B2BUA 引擎，但它没有原生集群能力，信令和媒体又和业务逻辑挤在同一个进程里。想把它扩到上万路，硬堆 FreeSWITCH 是最贵的一条路。这篇讲清 FreeSWITCH 架构的精华与包袱各在哪，为什么 OpenSIPS 和 rtpengine 恰好补在它最薄的两个地方——信令边缘和媒体传输——以及三件套怎么分工、容量能提到什么量级。

FreeSWITCH 用 switch_core 内核加模块插件的方式把一整套电话系统塞进一个进程，既不拆成微服务，也不是简单的单进程多线程。这篇从源码层面讲清它的状态边界划在哪、这种结构为什么快、又为什么脆，以及为什么这套二十年前为语音打磨的架构，做不成今天意义上的高性能 SFU。

DeepSeek 开源了自己的 agent harness（dsh），主打一句话——"一切皆插件"。它跟别家的 agent 框架不一样的地方不在功能多寡，而在架构范式：模型、工具、技能、会话、沙箱、存储、循环、调度、界面全是插件，连"主循环"本身都能被换掉，没有一个特权核心可以打补丁。本文从一个老程序员被"特权核心"坑过的角度，讲清楚这件事为什么值得关注，以及它的代价在哪。

中台这几年在很多公司里越来越尴尬：不直接赚钱、效率难衡量、自研的还没开源的好用，团队士气低落。但中台没落不是模式失败，是定位错了——它被当成了 KPI 和权力中心，忘了自己本该是让业务跑得更快的“铺路队”。AI 时代要活下去，中台得回归平台工程的本分：精兵简政、当产品不当收费站、把采用率当唯一裁判。

当性能卡在延迟上、当可靠性被跨国网络拖垮、当突发流量把源站压垮时，边缘节点常常是那个"离用户最近、最稳、最快"的解法。这篇从我做音视频就近接入的经历讲起，理清边缘节点到底适合哪些场景、有哪些经典案例、落地时怎么做、又容易踩哪些坑——核心是一句：边缘换来的是延迟和稳定，代价是一致性和运维复杂度，时间和空间从来不可兼得。

Pi 的 README 里有一节 Philosophy，通篇是"不做什么"：不做 MCP、不做 sub-agent、不做权限弹窗、不做 plan mode、不做内置 todo。但把仓库翻一遍会发现，这些被拒绝的功能全都以示例扩展的形式躺在 examples/ 目录里。这篇结合代码和数据讲清一件事：Pi 的克制不是靠作者意志力，是靠三个支点撑住的——按 token 而不是按行数度量"最小"、用扩展点给需求留泄压阀、以及一套敢说不的治理。文末给一个把 Pi 当 Agent 引擎嵌入自己项目的完整实例：代码库合规巡检 agent，含只读工具收敛、自定义工具落库、事件流审计。

生产上的 AI Agent 大多不是死在模型不行，而是死在记忆管得烂：要么什么都记，Token 和存储一起爆炸；要么什么都记不住，用户说三遍它忘三遍。这篇讲清楚一套像人脑一样分层的记忆系统——工作记忆、情景记忆、语义记忆、程序记忆，以及写入、巩固、检索、遗忘的完整生命周期，最后给一套可落地的参考架构和 checklist。

把 tinyhumansai 开源的 OpenHuman clone 下来读了一遍——一个纯 Rust 内核 + Tauri 桌面的开源 AI 助手。它把"AI 助手"拆成了三件事：一块会按时给自己喂料、压缩成"记忆树"的持久记忆大脑；一个跑在可恢复图（tinyagents）上的编排器，能把一群子代理当成一支舰队来指挥；外加一整套从语音、会议、工作流到加密的 agent 间通信的家当。真正让我放下的是它的取舍：复杂的 ML 全外包给开源 crate，内核只负责"对与错"的调度与安全，隐私开关一到 Rust 层就直接掐死出网。这篇按代码讲讲它这套"会折腾的剥洋葱式"架构，以及一个老后端能从中抄走的东西。

拆 i365dev 开源的 free4chat——一个"开房间就能说话、不注册不存数据"的实时语音文字聊天室。真正让我感兴趣的不是功能，而是它为了"不养服务器"这个目标换了三次技术栈：Go+Pion、Elixir+Membrane，最后落到 Cloudflare 全托管（RealtimeKit + Workers + Durable Object）。这篇按代码讲清楚它现在的架构：Worker 只发一个短期 token，媒体走 WebRTC 数据面，两小时房间过期、三层反机器人，以及那个藏在 Durable Object 里的 AI 助手 Luna，还有它踩过的坑和留给自己的下一步。

微服务各管一套权限，最后往往没人说得清谁能调用谁。本文给出统一授权中心的分层架构、协议选择、典型实例与演进路线，重点讲清身份、决策和执行如何分工。

很多人以为限流就是"每秒放 100 个请求"，配个数字完事。真上了规模才发现，限流是分层的、分策略的、还得跟业务谈判的。这篇把限流拆成"在哪一层限、按什么维度限、用什么算法、放行还是拒绝、拒了怎么告诉客户端"几件事，配上可抄的配置和一张决策清单。

做后端和 SDK 这些年，我越来越依赖一个东西：给每个服务配一个能把主流程完整跑一遍的 Sample App——Web Service 就配个 Test Web App，音视频应用就配个 Native App。它既是 E2E 测试工具，又是一个"永远在线的模拟用户"，还是最诚实的一份活文档。AI 能帮你把它写得飞快，但要不要养、往哪个方向养，得你自己拿主意。

最近又被几个内部自研平台教育了一回：东西能跑，但难学、难问、难接手，很多“为什么”只存在某些人的脑子里。本文借这个亲身体会，聊聊企业中间件到底该买、用开源，还是自研；也给一份少踩坑的决策清单。

设计评审上最值钱的不是答案，是问题。借《The Thinker's Guide to Socratic Questioning》的九类提问，和《胡思乱想消除指南》里对付灾难化思维的那套反驳法，我把它们改造成一份可以照着问的设计体检清单。