FantasyNovelAgent - Tag - Shengxu · Cloud Architecture & DevOps

Practical · Building a Memory-Enabled AI Writing Partner (Part 4): Observability (Metrics + Logs + Trace + Cost)

Thu, 05 Feb 2026 16:00:00 +0800

In the previous post, we discussed the security of RAG systems and Prompt injection protection. Today, let’s dive into another engineering deep-water zone: Observability.

When a system evolves from “it works” to “it’s reliable long-term,” you will inevitably encounter three types of problems:

Slow: Is retrieval slow? Is the LLM slow? Or is some Agent stuck in a retry loop?
Expensive: Is a specific pipeline silently consuming all the tokens? Why doesn’t this month’s API bill add up?
Weird: Intermittent bugs that can’t be reproduced, leaving you to fix code based on “gut feeling.”

At this stage, I chose to build a complete Metrics + Logs system, rather than just sprinkling in a few print statements.

Practical · Building a Memory-Enabled AI Writing Partner (Part 3): Security Architecture (RAG Protection, Fact Guard, and BYOK)

Wed, 04 Feb 2026 10:00:00 +0800

In the previous 2.5 articles, I’ve already laid out the backbone of FantasyNovelAgent:

This article dives deep into the most overlooked yet critical aspect of AI systems: Security.

If you’re thinking, “I’m just writing a novel, what security issues could there be?”, consider this:

Practical Guide: Building a Memory-Enabled AI Writing Partner (ikun) – Retrieval System (Vector Search, Hybrid Search & Cloud Deployment)

Wed, 28 Jan 2026 10:30:00 +0800

In “Practical · Building a Memory-Enabled AI Writing Partner (Part 1): Multi-Agent Architecture Evolution”, I clarified how multiple agents collaborate and how memory is chained together. In “Practical · Building a Memory-Enabled AI Writing Partner (Part 2): Database Evolution (From JSON to Single Database to Relational Tables)”, I reviewed the evolution of the “fact layer” from JSON to SQLite and then to relational tables.

However, when the text length reaches hundreds of thousands of words, what truly determines the experience is often not “whether the data exists,” but “whether I can retrieve it”: exact lookup (did it appear or not), structured filtering (who belongs to whom), and semantic association (is it similar, is it the same atmosphere) must all work simultaneously. So I added a clear “index layer” to FantasyNovelAgent and expanded retrieval from “chapters” to the “full knowledge graph.”

Practical · Building a Memory-Enabled AI Writing Partner (Part 2): Database (From JSON to Single Table to Relational Tables)

Wed, 28 Jan 2026 10:00:00 +0800

If you’ve already read Building a Memory-Powered AI Writing Partner (Part 1): Multi-Agent Architecture Evolution, you likely have a high-level understanding of how multiple agents collaborate and how memory is chained together. But what truly makes a system viable long-term isn’t just a pretty architecture diagram—it requires a data foundation that can withstand growth: one that supports querying, modification, and rollback.

This article focuses on the evolution of the “fact layer” (the database): JSON files → SQLite single database (KV) → SQLite single database (relational tables). Semantic search, hybrid search, full graph indexing, and cloud migration are covered separately in the next article, Building a Memory-Enabled AI Writing Partner (ikun): Retrieval System (Vector Search, Hybrid Search, and Cloud Migration).

Practical Guide · Building a Memory-Powered AI Writing Partner (Part 1): Multi-Agent Architecture Evolution

Sun, 25 Jan 2026 10:00:00 +0800

When writing a long novel, the most painful part isn’t “not being able to write”—it’s “forgetting what you’ve already written.” Did I set up that foreshadowing properly? Was that character already injured in the last chapter? When exactly was that world-building rule established? Once your manuscript crosses the hundreds-of-thousands-of-words mark, relying solely on your brain and scattered notes quickly becomes unmanageable.

FantasyNovelAgent grew out of this exact need. It started as a simple Python script, then evolved to include dynamic memory and auto-archiving, later added multi-device sync, and is now taking its first steps toward a front-end/back-end separation with cloud-native storage. This article retraces that evolution path and explains the key trade-offs, offering a reference for similar projects.