跳到主要内容

Knox Memory System — 完整功能深度解析

· 阅读需 18 分钟
Knox Anderson
Knox Anderson
Knox Dev Team

Knox Memory System (knox-ms) 已达到完全生产就绪状态。每个子系统——从自主任务编排到自我修复基础设施——都已上线并完全投入运行。本文全面介绍 knox-ms 的每项功能、能力和架构决策，使其成为第一个拥有真正无限、类脑记忆的 AI 模型。

什么是 Knox-MS？​

Knox-MS 是一个自定义 AI 模型（knox/knox-ms），通过模仿人脑的智能记忆管理系统提供真正无限的上下文窗口长度。与其他所有受固定上下文窗口限制的 LLM 不同，knox-ms 通过复杂的 Plan → Task → Memory 架构编排多个底层模型，动态管理记住什么、总结什么以及忘记什么。

Memory System (Brain) = Core Intelligence
  ↓ manages and updates
Context Cache (LLM) = Working Memory
  ↓ enhanced by
Vector Embeddings & Rerank (Tool) = Information Retrieval

结果：任意规模的对话和项目——从快速问答到跨越数月的开发工作——都不会丢失上下文或触及 token 限制。

1. 自主编排引擎​

knox-ms 的核心是一个完全自主的执行循环，每个阶段都由 LLM 推理驱动。

目标优化​

当您发送请求时，系统不只是简单回应——它会思考。自主核心通过 LLM 驱动的目标分析分解您的输入，将复杂请求拆解为结构化的目标层级。如果目标模糊，引擎会在继续之前内部提出澄清性的子问题来优化它。

多任务规划​

一旦理解了目标，knox-ms 会生成包含 1 到 8 个并行或顺序任务的结构化执行计划。每个任务按以下维度分类：

  • 类型 — 编码、分析、研究、通用
  • 难度 — 简单、中等或困难
  • 依赖关系 — 哪些任务必须在其他任务开始前完成

如果规划失败或生成单一整体任务，系统会优雅地降级为更简单的计划，而不是直接失败。

智能任务系统​

任务不是静态的待办事项——它们是自适应执行单元，具有：

  • 优先级计算 — 基于依赖关系、难度和目标相关性动态计算
  • 依赖图 — 任务按照其关系排序和并行化
  • 自适应重试与模型升级 — 如果任务在较简单的模型上失败，会自动使用更强大的模型重试
  • 难度升级 — 失败或低质量的任务会以更高的难度层级重新排队

状态机循环执行​

自主引擎作为状态机运行，带有定义好的检查点。每次迭代：

  1. 执行下一批就绪任务
  2. 使用基于 LLM 的评估和置信度评分进行自我质量评估
  3. 如果质量低于阈值则应用修正
  4. 通过基于 LLM 的成就评估检查目标完成情况
  5. 如果目标评估识别出需要额外任务则优化计划
  6. 创建恢复检查点
  7. 重复直到目标完全达成或达到迭代限制

这种架构意味着 knox-ms 可以自主处理复杂的多步骤目标——规划、执行、评估、修正和完成，每一步都无需人工干预。

2. 记忆系统——是大脑，不是缓冲区​

记忆系统是 knox-ms 与其他所有 AI 模型的根本区别所在。它提供持久、有组织、自我优化的记忆，工作方式完全像人脑。

类人记忆管理​

就像你的大脑不会存储每次对话的每个细节一样，knox-ms 通过持续的 CRUD 操作智能管理信息：

  • CREATE — 新会话、计划、任务记录和发现的模式自动存储
  • READ — 每次请求只加载相关记忆到工作上下文中
  • UPDATE — 任务结果、对话历史和上下文摘要持续优化
  • DELETE — 临时文件、冗余信息和过时缓存条目自动清理

分层记忆组织​

记忆以树状文件系统组织，具有多个详细层级：

层级保留策略详细程度
近期（最近几轮）完整细节包含所有上下文的完整对话
中期（当前会话）关键要点决策、结果、重要交流
长期（历史）语义摘要模式、学到的概念、压缩知识

自动记忆管理器​

自动记忆管理器处理每个记忆条目的生命周期：

  • 评分 — 每个记忆条目接收一个相关性分数，随时间按艾宾浩斯遗忘曲线衰减
  • 保留策略 — 可配置的保留期限，自动清理低于分数阈值的条目
  • 去重 — 检测并合并相似的记忆以防止膨胀
  • 压缩 — 在保留关键信息的同时压缩旧记忆
  • 可配置限制 — 最大条目数、记忆大小上限和清理间隔均可调节

摘要引擎​

Knox-ms 包含提取式和结构化两种摘要能力：

  • 提取式摘要 从对话历史中提取最重要的句子和事实
  • 结构化摘要 使用 LLM 调用产生有组织的分层摘要，包含关键决策、结果和学到的模式
  • 摘要与原始历史一起保存，既提供快速访问的概览，又在需要时提供完整细节

3. 上下文管理——设计即无限​

上下文管理器是记忆系统和 LLM 工作上下文窗口之间的桥梁。

多层上下文​

knox-ms 不是将所有内容一股脑塞入单个 prompt，而是维护多个上下文层级：

  • 活跃上下文 — 当前任务的即时工作集
  • 会话上下文 — 更广泛的会话历史和目标
  • 跨会话上下文 — 来自先前会话的知识和模式
  • 全局知识 — 学到的模式和永久知识库条目

智能压缩​

当上下文超过阈值时，系统应用渐进式压缩：

  • 旧的轮次被摘要化，而近期轮次保持完整
  • 压缩比可配置（从最小到激进）
  • 当内存压力大时，可使用强制压缩作为自我修复操作

上下文缓存优化​

Knox-ms 结构化记忆以最大化 LLM prompt 缓存命中率：

  1. 稳定前缀 — 常用上下文放置在一致的位置以启用缓存
  2. 动态后缀 — 每次请求变化的任务特定上下文附加在稳定部分之后
  3. 智能失效 — 只有在记忆显著更新时才使缓存失效，而非每次更改都失效

这意味着您可以获得 prompt 缓存的成本和速度优势，同时保持真正无限的上下文深度。

4. 知识图谱​

Knox-ms 构建和维护一个持久化知识图谱，捕获概念、代码实体、决策和模式之间的关系。

图结构​

  • 知识节点 — 个别事实、概念、代码模式或决策
  • 关系 — 节点之间的类型化连接（依赖于、相关于、取代等）
  • 相关性评分 — 每个节点和关系携带一个根据访问模式和时效性更新的分数

LLM 驱动的知识提取​

当任务完成时，knox-ms 使用 LLM 调用执行结构化知识提取：

  • 每段内容被分析以产生包含标题、内容、标签和相关性分数（0.0–1.0）的知识条目
  • 提取的知识存储在图中，可用于未来的上下文加载
  • 系统随时间学习哪些类型的知识最有用

5. 向量嵌入与语义搜索​

Knox-ms 包含完整的向量嵌入管线，用于对项目内容和对话历史进行语义搜索。

嵌入管线​

  1. 索引 — 项目文件被分块（2048 tokens，带重叠）并使用 VoyageAI 模型嵌入（通用内容使用 voyage-3.5，代码使用 voyage-code-3）
  2. 存储 — 嵌入以每用户范围持久化到 Knox 存储，首次访问时延迟加载
  3. 搜索 — 查询被嵌入并使用余弦相似度与存储向量匹配
  4. 重排序 — 候选结果使用 VoyageAI 的 rerank-2.5 模型进行细粒度相关性重排序

弹性嵌入服务​

嵌入管线为生产可靠性而构建：

  • 指数退避重试 — 失败的 API 调用最多重试可配置次数，使用指数延迟（500ms × 2^attempt）加抖动以避免惊群效应
  • 智能重试过滤 — 4xx 错误（429 速率限制除外）跳过重试，因为重试不会成功
  • 断路器 — 连续 5 次失败后，系统打开断路器并在 60 秒内快速失败，防止级联故障。半开状态允许周期性探测，连续 3 次成功后断路器关闭
  • Mock 回退 — 在开发环境或 VoyageAI 持续不可用时，确定性 mock 嵌入确保系统继续运行

TTL 和容量管理​

向量存储被主动维护：

  • 基于 TTL 的淘汰 — 超过配置最大年龄的向量自动移除
  • 容量强制 — 使用 LRU 淘汰（最旧优先）执行每用户向量限制
  • 缓存清理 — 过期的嵌入缓存条目在维护周期中被清除
  • 存储持久化 — 任何变更后，清理状态异步持久化到 Knox 存储

6. 自我修复基础设施​

Knox-ms 不仅能从错误中恢复——它通过 12 种不同的修复操作类型诊断和修复自身。

修复操作​

操作作用
Switch Model当前模型失败或表现不佳时路由到不同的底层模型
Fallback to Simpler为困难任务降级到更简单、更可靠的模型
Clear Cache清除所有会话的所有缓存上下文条目以解决数据过时问题
Reduce Context Size按可配置百分比强制压缩缓存上下文以保持在限制内
Optimize Memory触发记忆清理，移除旧历史和过时的记忆状态
Adjust Batch Size修改运行时批处理参数
Throttle Requests在高负载场景下应用请求速率限制
Prioritize Cache调整缓存优先级以获得更好的命中率
+ 4 个更多针对边缘情况的额外运行时配置覆盖

自我修复工作原理​

当自主循环遇到错误时：

  1. 系统分析错误原因并选择最合适的修复操作类型
  2. 选定的操作委派给自我管理器，后者执行真正的系统更改（不是模拟）
  3. 循环在应用修复后重试失败的操作
  4. 如果修复失败，系统可以升级到更激进的操作

所有修复操作都通过实际的子系统调用执行——模型切换更新中继的默认模型，缓存清除操作真实的上下文管理器，记忆清理针对实际的记忆存储运行。

优化引擎​

除了错误恢复，自我管理器还主动应用 8 种优化类型：

  • 基于观察到的执行模式的性能优化
  • 减少内存和 token 使用的资源优化
  • 提高输出准确性的质量优化
  • 更快响应时间的延迟优化

7. 学习与模式识别​

Knox-ms 从每次执行中学习，随时间变得更加智能。

它学习什么​

  • 目标分类 — 识别正在请求的目标类型，并建议经过验证的方法
  • 模型性能追踪 — 记录哪些模型在哪些任务类型和难度上表现最好
  • 任务类型成功率 — 追踪每个任务类别的成功/失败率以改善未来规划
  • 方法建议 — 在生成新计划之前，系统查阅学到的模式并应用来自过去成功经验的模型偏好和方法提示

学习如何整合​

在自主执行循环中：

  • 规划前 — 系统调用学习服务获取基于当前目标的方法建议，可能影响模型选择和任务分解
  • 执行后 — 成功或失败与完整执行数据（所有任务、使用的模型、token 计数、延迟）一起记录
  • 随时间 — 系统建立执行模式数据库，持续提高规划质量

记忆巩固​

后台巩固任务定期运行以加强长期记忆：

  • 艾宾浩斯衰减 — 记忆条目的相关性随时间自然衰减，模拟人类遗忘曲线
  • 强化 — 经常访问或高度相关的记忆被增强
  • 深度摘要 — 旧的详细记忆被合并为紧凑的摘要
  • 知识图谱更新 — 新的关系和模式被整合到图中
  • 向量存储维护 — TTL 淘汰、容量强制和缓存清理作为每个巩固周期的一部分运行

巩固系统自动检测 knox-ms 是否可用，仅在服务初始化时运行——无需手动配置。

8. 会话管理​

每次 knox-ms 交互都通过由 Redis 支撑的强大会话系统管理。

会话特性​

  • 会话状态持久化 — 完整的会话状态存储在 Redis 中，带自动过期
  • 分布式锁 — 使用 Lua 脚本的原子锁获取（SET key value NX EX ttl）防止跨多进程的竞态条件
  • 安全锁释放 — 在释放前原子性地验证所有权，防止一个进程意外释放另一个进程的锁
  • 锁延期 — 长时间运行的操作可以带所有权验证延长其锁的 TTL
  • 原子度量 — 会话度量（迭代计数、任务完成等）使用原子 Redis 操作防止并发下的更新丢失

检查点​

自主引擎在执行期间以可配置的间隔创建检查点：

  • 检查点通过存储集成持久化到 Knox 存储
  • 它们捕获完整的循环状态、已完成的任务和当前计划
  • 恢复时，执行可以从最后一个检查点继续而非重新开始
  • 检查点端点接受带可配置限制的会话范围查询

9. 实时事件流​

Knox-ms 通过 Server-Sent Events (SSE) 提供对自主执行的完整可见性。

21 种事件类型​

系统流式传输覆盖执行每个阶段的类型化事件：

  • 目标优化事件
  • 规划和任务创建事件
  • 任务开始、进度和完成事件
  • 自我评估和修正事件
  • 修复操作事件
  • 检查点创建事件
  • 执行完成事件
  • 以及更多

客户端集成​

前端事件服务提供：

  • 类型化事件处理 — 所有 21 种事件类型的强类型处理器
  • 自动重连 — 连接丢失时使用指数退避加抖动
  • Last-Event-ID 支持 — 带事件重放的无缝重连，确保不遗漏任何事件
  • 自动关闭 — 收到 execution_completed 时连接自动关闭

10. 执行分析与历史​

每次自主执行都被持久化以供长期分析和回顾。

记录的内容​

每次执行存储：

  • 执行记录 — 执行 ID、会话 ID、目标、优化后的目标、目标分解、循环状态、迭代次数、配置快照、最终响应、时间戳和取消信息
  • 任务记录 — 个别任务 ID、计划 ID、类型、难度、状态、结果/错误、token 使用量和执行时间
  • 聚合度量 — 跨 6 个类别的 14 个度量：性能、tokens、内存、质量、弹性和延迟

分析 API​

两个专用端点提供历史洞察：

  • 执行历史 — 带状态过滤的分页查询，返回带计算时长的执行记录
  • 聚合分析 — 总/成功执行数、成功率、总任务数、每种度量类型的平均值和每种任务类型的成功率

11. 中继集成与模型路由​

Knox-ms 不使用单一模型——它通过 Knox 中继基础设施动态路由请求。

路由工作原理​

  1. 通道选择 — 系统根据模型需求和可用性选择最佳可用通道
  2. 适配器管线 — 请求流经 channel selection → adaptor → convert_request → do_request → do_response
  3. 完整计费集成 — 每次中继调用都被正确计量和计费
  4. 动态模型切换 — 默认模型可以在运行时更改（例如，由切换到更可靠模型的自我修复操作触发）
  5. 优雅降级 — 如果主要中继路径失败，回退机制确保请求仍能完成

这意味着 knox-ms 可以使用您喜欢的任何模型作为底层引擎，同时用完整的记忆、规划和自我修复基础设施包装它。

12. 存储架构​

Knox-ms 使用双存储架构实现持久性和性能。

Knox 存储（持久存储）​

  • 用户和会话级别的记忆文件
  • 计划和任务存储
  • 摘要和索引
  • 向量嵌入（knox-ms/vectors/user_{id}/store.json 的每用户存储）
  • 执行检查点
  • 任务结果和执行摘要

Redis（快速状态）​

  • 会话状态和分布式锁
  • 使用原生 Redis 集合（SADD、SMEMBERS、SREM）的基于集合的数据结构
  • 通过 Lua 脚本实现的原子操作，实现无竞态的状态管理
  • 带原子增量的度量计数器
  • Redis 不可用时的本地缓存回退

13. 配置与管理控制​

knox-ms 的每个方面都可以通过经过验证的 API 端点进行配置。

自主引擎配置​

控制执行循环行为：

  • max_iterations (1–1,000) — 最大自主循环迭代次数
  • max_execution_time_secs (10–86,400) — 执行时间限制
  • goal_confidence_threshold (0.0–1.0) — 认定目标达成的最低置信度
  • max_healing_attempts (0–20) — 放弃前最多尝试多少次自我修复
  • max_parallel_tasks (1–50) — 并行任务执行的并发限制
  • context_window_size (1K–10M) — 工作上下文窗口大小
  • checkpoint_interval (1–100) — 创建恢复检查点的频率

上下文配置​

微调上下文管理：

  • active_context_window (1K–10M tokens)
  • compression_ratio (0.01–1.0)
  • hierarchy_levels (1–10)
  • retrieval_top_k (1–100)
  • relevance_threshold (0.0–1.0)
  • cross_session_max_age_days (1–3,650)
  • max_graph_entities (100–1M)

记忆配置​

调节自动记忆管理器：

  • max_context_tokens (1K–10M)
  • summarize_trigger_tokens (100–1M)
  • knowledge_retention_threshold (0.0–1.0)
  • cleanup_threshold_days (1–3,650)
  • dedup_similarity_threshold (0.0–1.0)

用户偏好​

个人用户可以自定义他们的自主执行体验：

  • 最大迭代次数和时间限制
  • 置信度阈值
  • 检查点间隔
  • 所有验证与管理员配置使用相同的界限

所有配置都持久化到数据库并在启动时加载，因此您的设置在重启后仍然有效。

14. 前端体验​

knox-ms 前端提供丰富、交互式的界面，用于与记忆系统交互和管理。

视觉架构​

  • Brain Memory Architecture — 记忆系统分层结构的可视化表示
  • Knox-MS Panel — 在 Chat 和 Code 视图中均可用的主交互面板
  • Vector Search UI — 搜索和探索项目的语义嵌入
  • Session Manager — 查看、管理和切换活跃会话
  • Memory Explorer — 浏览记忆树、检查条目、查看分数和保留策略
  • Task System UI — 监控活跃任务、查看计划和跟踪执行进度

自主设置​

用户可以直接从 UI 配置自主执行偏好：

  • 设置在组件挂载时从后端加载
  • 更改通过实时验证保存到后端
  • Toast 通知确认保存成功或报告错误

本地化​

为所有 knox-ms UI 元素提供完整的国际化支持和 i18n 字符串。

15. 全栈类型安全​

Knox-ms 从后端到前端保持端到端类型安全。

自动类型同步​

同步脚本从 Rust 后端自动生成 TypeScript 接口：

  • 从 5 个后端源文件生成 19 个接口和 2 个联合类型
  • 类型映射处理所有 Rust → TypeScript 转换：String → string、Option<T> → T | null、Vec<T> → T[]、HashMap<K,V> → Record<K,V> 等
  • Rust 文档注释（///）保留为 TypeScript JSDoc（/** */）
  • 脚本可配置——添加新类型只需向源列表添加条目即可

这确保前端和后端在数据结构上永远不会失去同步。

API 快速参考​

模型标识​

{
  "id": "knox/knox-ms",
  "object": "model",
  "owned_by": "KnoxChat",
  "context_length": -1
}

context_length 为 -1 意味着无限制——没有上限。

特殊参数​

参数类型描述
session_idstring用于记忆持久化的唯一会话标识符
project_idstring用于向量嵌入检索的项目标识符
enable_vector_searchboolean启用对项目内容的语义搜索（默认：true）
vector_top_kinteger检索的向量搜索候选数量（默认：30）
rerank_thresholdfloat最低重排序分数阈值，0.0–1.0（默认：0.5）
memory_modestring记忆策略：full、summarized、selective
include_reasoningboolean在响应中包含任务规划推理
verbositystring输出详细程度：minimal、normal、verbose

35+ REST 端点​

Knox-ms 暴露了全面的 REST API，涵盖：

  • 自主执行管理（启动、取消、状态、历史、分析）
  • 记忆操作（探索、搜索、清理）
  • 知识图谱查询
  • 向量搜索和索引
  • 会话管理
  • 检查点操作（列出、恢复、删除，带适当的会话范围）
  • 配置管理（引擎、上下文、记忆、用户偏好）
  • 实时事件流（SSE）

总结​

Knox-MS 不是渐进式改进——它是 AI 交互的全新方法。通过结合自主编排、类脑记忆、自我修复基础设施、持续学习和生产级可靠性，knox-ms 提供了其他任何模型都无法实现的：随时间增长智慧的真正无限上下文。

每个子系统都已完全投入运行、经过实战检验，并为生产工作负载做好准备。无论您使用 knox-ms 进行快速提问还是长达数月的开发项目，系统都会在每次交互中记忆、学习、适应和改进。

立即开始使用 Knox-MS — 选择 knox/knox-ms 作为您的模型，亲身体验无限上下文。

>>> Knox-MS 无限上下文定理