在上一篇关于 Cilium 的文章中，我们探讨了 2026 年迁移潮背后的真实原因：它不再仅仅是“一个更快的 CNI”，而是将 Kubernetes 网络、安全、可观测与多集群能力，重新组织成了一套更统一的基础设施底座，并理清了它与 Istio 的分工协作边界。
如果说上一篇回答了“Cilium 到底能为我们带来什么”，那么这一篇我们将更进一步，聚焦于它的演进核心：统一数据平面（Unified Dataplane）。
本文将具体展开，Cilium 究竟是在如何改变平台系统的分层方式，重写那些原本由不同独立组件（如 iptables、Mesh Sidecar、独立监控 Agent 等）分别承担的能力边界，并通过多集群（ClusterMesh）和无 Sidecar 架构的实际案例，探讨其对生产环境的深远影响。
过去的 Kubernetes 平台通常由一组松耦合系统拼起来：
大模型（LLM）与 AI Agent 的爆发不仅带来了业务模式的革命，也引入了诸如提示词注入、数据投毒等全新的应用层安全挑战。当大家的目光都被这些前沿漏洞所吸引时，我们不妨先停下来，问自己一个直击灵魂的问题：在探讨这些复杂的 AI 安全之前，承载所有业务的云原生底座及格了吗？
无论是前沿的 LLM 推理服务、RAG 向量数据库，还是传统的微服务与高并发网关，绝大多数现代应用最终都严重依赖底层的 Kubernetes 容器集群。如果底层基础设施千疮百孔，攻击者根本不需要费尽心机去研究复杂的应用层漏洞，直接利用一个容器逃逸就能接管宿主机并窃取核心数据。
结合正式发布的 OWASP Top 10:2025 与 OWASP Kubernetes Top Ten，本文将为你层层拆解：为什么在今天的大规模生产场景下，传统的云安全手段正面临巨大的盲区？以及我们该如何构建一套涵盖供应链、准入控制、运行时与 GitOps 的四段式防线。
在 Kubernetes 这种高动态、高密度的容器编排环境中，传统的静态边界防御（如外围防火墙）与事后审计（如节点级日志分析）已暴露出严重的覆盖盲区。为了应对现代复杂的攻击链路，基础设施必须针对以下四个核心痛点进行能力演进：
在上一篇中，我们讨论了 RAG 系统的安全性与 Prompt 注入防护。今天我们来聊聊另一个工程化深水区：可观察性（Observability）。
当系统从“能跑”走向“长期可用”，你一定会遇到三类问题：
在这个阶段，我选择建立一套完整的 Metrics（指标） + Logs（日志） 体系，而不是仅仅打印几行 print。
本项目的可观测性包含两部分，目标是覆盖“宏观健康度”与“微观可追溯性”：
在前面2.5篇里，我已经把 FantasyNovelAgent 的主干讲清楚了：
这一篇我们深入探讨 AI 系统最容易被忽视、但至关重要的环节：安全性（Security）。
如果你觉得“我只是写个小说，哪有什么安全问题”，请试想：
本文将从 RAG 注入防护、数据隐私、密钥管理等角度，分享构建安全 AI 应用的实战经验。
传统认知里，prompt 是“用户写给模型的指令”。但在 RAG（检索增强生成）里，prompt 里混入了大量“外部内容”（旧章节、角色卡、甚至网络资料）。
在《实战 · 打造会记忆的AI 写作搭档（一）：多 Agent 架构进化》里，我把“多 Agent 如何协作、记忆如何串起来”讲清楚了；在《实战 · 打造会记忆的AI 写作搭档（二）：数据库篇（从 JSON 到单库，再到关系表）》里，我把“事实层”从 JSON 到 SQLite 再到关系表的演进复盘了一遍。
但当篇幅变成几十万字以后，真正决定体验的往往不是“数据在不在”，而是“我能不能把它找回来”：查照（出现没出现）、结构化筛选（谁属于谁）、语义联想（像不像、是不是同一种氛围）要同时成立。于是我给 FantasyNovelAgent 加了一个清晰的“索引层”，并把检索从“章节”扩展到“全图谱”。
从这里开始，我明确一条底层原则：
如果你已经读过《实战 · 打造会记忆的AI 写作搭档（一）：多 Agent 架构进化》，大概率对“多 Agent 如何协作、记忆如何串起来”有个整体印象。但真正让系统长期可用的，不只是一张好看的架构图，还得有一套能扛住增长的数据底座：能查、能改、能回溯。
这篇文章专注聊“事实层”（数据库）的演进：JSON 文件 → SQLite 单库（KV）→ SQLite 单库（关系表）。至于语义检索、混合检索、全图谱索引与云化迁移，我单独写在下一篇《实战 · 打造会记忆的AI 写作搭档（坤）：检索系统篇（向量检索、混合检索与云化）》里。
长篇小说写作系统的本质，不是“写一段文本”，而是长期维护一个不断生长的世界：角色状态、势力关系、物品流转、地点层级、伏笔链条……随着字数增长，这些信息会指数级膨胀。
当数据只是“文本堆”，你会遇到三类必然问题：
目标一直很明确：
让数据变成“实体关系系统”，再叠加“检索索引层”，最终让 AI 不只是会写，还要会查、会记、不会乱。
最早为了快速起步，我用文件系统存储：角色库、地图、世界观设定等以 JSON（或类 JSON）文件落盘。
写长篇小说时，最痛的不是“写不出来”，而是“写着写着就忘了自己写过什么”：伏笔埋没埋好？角色是不是上一章已经受伤？某个设定到底什么时候定下来的？当篇幅走到几十万字后，这些信息如果只靠人脑和零散笔记维持，很快就会失控。
FantasyNovelAgent 就是从这个需求出发，一点点长出来的：先是一个能跑的 Python 脚本，后来加上动态记忆与自动归档，再到支持多端同步，最后开始迈向前后端分离与云原生存储的雏形。本文复盘这条进化路径，并把关键取舍讲清楚，供同类项目参考。
如果你想先体验一下这个项目，这里有一个在线 Demo：demo online（欢迎试用）。为了避免滥用与泄露成本，Demo 需要你在设置里填写自己的大模型 API Key 后才会真正调用模型能力。
在谈论技术架构之前，先来看看它能做什么。FantasyNovelAgent 并不是一个简单的“续写工具”，它更像是一个由多名专家组成的“写作工作室”。
最近经历了一场面试，面试官抛出了一个看似常规的问题：“你认为什么情况下应该使用 Kubernetes，而什么情况下使用 Kubernetes 是没有必要的、徒增复杂度？”
这个问题当时回答得还算流畅，但之后它反而在我脑海里盘旋了许久。这个问题之所以“刺耳”，是因为它跳出了“怎么用 K8s”的技术细节，直指架构设计的核心权衡：我们引入一个技术栈，到底是为了解决业务的真实痛点，还是仅仅为了满足技术团队的“先进性焦虑”？
很多团队把 Kubernetes 当作现代化研发的标配起点，但现实往往是残酷的：你不是上了 Kubernetes 就自动获得了 Google、AWS、Azure 等云厂商般的基础设施能力；你是上了 Kubernetes 之后，才刚刚开始背负起治理分布式系统的沉重代价。
Kubernetes 的核心价值从来不在于“跑容器”——Docker Compose 也能跑，甚至 systemd 也能跑。它的核心价值在于控制平面（Control Plane）：它提供了一套声明式的 API，允许我们描述系统的“期望状态”，并由系统自动将“实际状态”收敛到期望状态。