在上一篇中，我们讨论了 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，允许我们描述系统的“期望状态”，并由系统自动将“实际状态”收敛到期望状态。
昨天有幸参加了 Acronis 公司的 Sergey Saburov 的关于 “Agentic Engineering & LLM Security” 的分享。Sergey 深入剖析了现代 LLM 应用面临的安全威胁，并结合 OWASP LLM Top 10 框架提供了大量实战案例。
现结合 OWASP LLM Top 10 v2.0 (2025) 最新官方标准，对分享内容进行了梳理与总结。针对原分享中部分术语的偏差（如 LLM06、LLM10 等）做了必要的修正，并整理了面向 Kubernetes 平台工程师的 Python 代码 PoC（概念验证）与防御脚本，希望能为大家构建安全的 AI 系统提供参考。
定义：包括直接提示注入（Jailbreaking）和间接提示注入（Indirect Prompt Injection）。间接注入是指攻击者将恶意指令植入 LLM 可能检索或处理的数据源（如网页、邮件、文档）中。
在基础设施领域，有些版本更新是“锦上添花”，而有些则是“脱胎换骨”。如果说 Helm 3 让我们告别了 Tiller 的噩梦，那么于 2025 年 11 月 正式发布的 Helm 4，则是 Helm 真正理解并融入 Kubernetes 声明式哲学的成人礼。
经过两个月的社区验证与官方文档沉淀，本文将基于 Helm 4 的实际发布状态，为您澄清那些容易被误解的技术细节。
作为 K8s 包管理的“事实标准”，Helm 4 在发布两个月后，我们终于可以在生产环境中冷静地审视它的价值。对于追求极致稳定的 Platform Engineer 工程师来说，Helm 4 最大的意义不在于功能堆砌，而在于它如何偿还了长久以来的技术债务。
Helm 3 用户最痛的点是什么？莫过于 kubectl apply 和 helm upgrade 之间的“神仙打架”。