企业官网建设流程全解析

• AI 应用
• 人工智能
• 大模型
• AI Agent
• RAG
• 后端
• 前端
• 桌面应用

OpenFic是一款专为小说创作打造的跨平台、AI Native 的一站式 Vibe Writing 工具。它的章节记忆系统解决长篇写作中的两大痛点：章节摘要自动生成（把数千字正文压缩为 200 字结构化记忆）与Agent 上下文智能压缩（在 Token 预算内保住关键信息）。本文带你剖析这套系统的设计思路与成本优化之道。

一、为什么长篇写作需要"记忆系统"？

小说动辄几十万字，但大模型上下文窗口有限。如果每次让 Agent 帮忙续写、检查伏笔都携带全部前文，Token 成本会爆炸。

OpenFic 的思路是分级记忆：

这个"金字塔"结构由 context_builder.py 中的build_context函数实现，它以当前章节为锚点、基于全局阅读序位（跨卷连续编号，见 sequence.py）分层取数，让 Agent 用可控成本"记住"全书脉络。

二、章节摘要：结构化记忆的低成本生成

1. 默认"轻量模型 + 字数门槛"

摘要默认使用轻量模型（summary_config.py 中SUMMARY_LIGHT_MODEL_REFERENCE），而非主力写作模型；同时设置了DEFAULT_SUMMARY_MIN_CHAPTER_WORD_COUNT = 500的门槛——不足 500 字的章节直接跳过摘要，避免为短章节浪费一次 LLM 调用。这是最朴素也最有效的成本优化。

2. 工具调用输出，而非自由文本

生成摘要时，模型被要求必须调用emit_chapter_summary工具输出结构化结果：

• start_time/end_time：章节内事件起止时间
• characters/locations：人物与地点列表
• summary：200 字以内（默认）的摘要

这套提示词定义在 chapter-summary.yaml，明确要求"所有输出都不被用户可见，除工具调用外不输出任何内容，以节省 token 消耗"。生成逻辑在 summary_generator.py 中，还会把上一章原文 + 其摘要一并喂给模型（_previous_chapter_message），帮助它连贯地理解剧情时间线。

3. 过期检测：内容没大改就不重算

修改一章正文后，摘要需要重新生成吗？OpenFic 的答案是用 diff 说话。summary_service.py 中的is_chapter_summary_stale会：

1. 把摘要生成时的正文与当前正文都做归一化（剔除空白和标点）；
2. 用SequenceMatcher计算差异字符数；
3. 差异 ≤ 100 字（SUMMARY_STALE_DIFF_THRESHOLD）则视为"新鲜"，直接复用旧摘要，零成本。

远期摘要更进一步：它记录来源章节摘要的SHA-256 签名列表（chapter_summary_signature），任何一个来源摘要变化，整个区间摘要才判定过期——批量校验，一次查询完成。

4. 远期摘要：固定窗口聚合，而非全文重读

每 10 章（DEFAULT_SUMMARY_LONG_TERM_INTERVAL）为一个固定窗口，生成一条 500 字以内的区间摘要（summary_service.py 的_fixed_summary_windows）。它只读取章节摘要（而非原文）来聚合，Token 消耗再降一个数量级。所有摘要任务都走后台批量作业队列（JOB_TYPE_SUMMARY_BATCH），进度实时推送给前端，不阻塞写作。

三、上下文智能压缩：Agent 会话的"记忆瘦身"

章节记忆解决"书"的记忆，而 Agent 会话（多轮工具调用、读改文件）同样会撑爆上下文。OpenFic 在 agent_runtime/context/ 下实现了两级瘦身策略。

1. 第一级：工具输出剪枝（pruning）

pruning.py 的prune_tool_outputs从最新消息往回扫描历史工具输出：

• 最近 100K Token 内的工具输出受保护（PRUNE_PROTECTED_TOKENS），绝不动刀；
• 超出保护区的旧工具输出，替换为模型可见的占位符[Old tool result content cleared]——模型仍"知道"自己调过什么工具，但不再携带完整结果；
• 技能、子代理派发等受保护工具（_PROTECTED_TOOL_NAMES）的输出永不清除；
• 若预计节省不足 20K Token（PRUNE_MINIMUM_TOKENS）则放弃本次剪枝，避免无谓扰动。

剪枝是纯本地字符串替换，零 LLM 成本。

2. 第二级：窗口压缩（compaction）

当剪枝仍不够，或上下文使用率达到阈值AUTO_TRIGGER_RATIO = 0.8（config.py）时，触发真正的"摘要压缩"：

• 选窗口：window.py 的select_compaction_window将历史按 LLM 轮次分组，从尾部保留TAIL_TOKEN_BUDGET = 20_000（或窗口 50%）的"尾部预算"消息原样保留，只压缩其之前的部分；
• 门槛：待压缩部分不足MIN_COMPACTABLE_TOKENS = 2_000则跳过——小窗口不值得花一次 LLM 调用；
• 压缩：service.py 的compact_window把窗口消息转成<user>/<assistant>/<tool>转录稿，交给提示词链session-compaction（compaction.yaml）生成简报。提示词强制使用固定小节结构：目标 / 决策和理由 / 相关内容 / 错误与修复 / 待办事项，并附当前任务计划（_current_plan_block），确保压缩后 Agent 能"无损续接工作"；
• 持久化 + 冲突保护：摘要连同start_seq/end_seq范围、源 Token 数、摘要 Token 数一起入库（compaction_repo），同一范围并发压缩会触发compaction_conflict中止，保证幂等。

3. 压缩本身的成本也是被计量的

每次压缩都会解析响应的usage，按压缩模型的输入价、输出价、缓存读价计算费用，通过usage_sink计入会话账单（service.py 的_usage_payload）；压缩模型也可单独配置为轻量模型（LIGHT_MODEL_REFERENCE）。Token 统计统一走 tokens.py 的 tiktoken 本地计数，不依赖模型侧返回。

四、成本优化之道：小结

五、结语

OpenFic 的记忆系统给 AI 应用开发者的启发在于：成本优化不是单一技巧，而是一套"分级 + 惰性 + 计量"的组合拳——用金字塔结构减少输入，用 diff 与签名避免重复计算，用纯本地剪枝兜底，用最小门槛抑制无效调用，最后让每一次 LLM 花费都被记账。想深入了解，推荐阅读源码入口 summary_service.py、context_builder.py 与 agent_runtime/context/ 目录。

• AI 应用
• 人工智能
• 大模型
• AI Agent
• RAG
• 后端
• 前端
• 桌面应用