赋予您的 AI 一颗能记忆的大脑。

Memory Brain 是一个本地优先、SQLite 驱动的记忆系统，赋予 Knox 跨对话、跨会话和跨项目的持久化、结构化记忆能力。 它用受人类记忆科学启发的多层认知架构，取代了 无状态 LLM 的"金鱼记忆"。

在此体验带 Memory Brain 的 KnoxChat VS Code 扩展 >>>

目录​

• 为什么选择 Memory Brain？
• 工作原理
• 架构概览
• 记忆类型
• 5 层记忆层级
• 核心功能
• 全部 79 个操作参考
• 数据库架构
• 优势
• 配置
• 测试覆盖
• 工具集成

为什么选择 Memory Brain？​

与 LLM 的每次对话都从零开始。AI 忘记了您的偏好、过去的决策、项目上下文以及之前有效的模式。您最终只能反复重复说明、重新解释代码库，并丢失花费数小时才获得的洞察。

Memory Brain 通过以下方式解决这个问题：

工作原理​

记忆工具调用流程​

User or Agent
    │
    ▼
┌─────────────────────┐
│   memory tool call  │  action: "store", params: { title, content, ... }
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│   BrainManager      │  dispatch(action, params) → routes to handler
│   (Service Layer)   │  emits events, records audit log
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│   BrainStore        │  SQLite CRUD, BM25 search, consolidation
│   (Data Layer)      │  17 tables, 27 indexes, WAL mode
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│   brain.sqlite      │  ~/.knox/memory/brain.sqlite
│   (Local Database)  │  Your data. Your machine. No cloud.
└─────────────────────┘

1. 智能体（或用户）使用 action 和 params 调用 memory 工具。
2. BrainManager.dispatch() 路由到 79 个操作处理器之一。
3. 处理器调用 BrainStore（SQLite 层）或专门的模块（KnowledgeGraph、LearningEngine、CheckpointManager 等）。
4. 事件被发送并记录在审计跟踪中。
5. 向调用者返回人类可读的格式化字符串。

自动记忆生命周期​

Memory Brain 不仅仅是存储——它主动管理记忆健康：

 Store ──► Hot Tier ──► Warm Tier ──► Cold Tier ──► Pruned
           (active)     (1-7 days)   (7-90 days)   (>90 days)
              ▲                                        │
              └─── Promote (frequent retrieval) ◄──────┘

 Background: Ebbinghaus decay, spaced repetition, consolidation

频繁访问的记忆会被提升回热层。衰减到重要性阈值以下的记忆会被逐步合并，最终被清除。这使系统保持快速和精准。

架构概览​

模块映射​

core/context/memory/brain/
├── BrainManager.ts        # Service layer — 79-action dispatch, event bus
├── BrainStore.ts          # SQLite data layer — 17 tables, CRUD, search
├── types.ts               # TypeScript interfaces, enums, input/output models
├── ContextBuilder.ts      # Token-budgeted multi-source context assembly
├── KnowledgeGraph.ts      # Entity/edge CRUD, spreading activation traversal
├── LearningEngine.ts      # Pattern recording, Jaccard similarity suggestions
├── AutoMemory.ts          # Rule-based extraction, topic segmentation
├── CheckpointManager.ts   # Snapshots, rollback, event replay, undo
├── BatchOperations.ts     # Bulk store/delete/update, batch audit logging
├── AdvancedFeatures.ts    # SessionDiscovery, FiveTierHierarchy, SpacedRepetition,
│                          # RootCauseAnalyzer, LruCache, MetricsStorage
├── PerformanceMonitor.ts  # MetricsCollector, HealthScorer, PredictiveAnalytics,
│                          # HealingEngine, ConsolidationTracker
├── LlmMemoryService.ts   # LLM-powered entity extraction, summarization, scoring
├── LlmResilience.ts      # CircuitBreaker, rate limiting, decision caching
├── SleepConsolidation.ts  # Background scheduler, Ebbinghaus decay application
├── WorkingMemory.ts       # In-memory session state, short-term buffer
├── test-memory-tool.ts    # 94 integration tests — 100% pass rate
├── test-brain-debug.ts    # 202 ultra-comprehensive integration tests
├── test-brain-debug-modules.ts  # 59 module-level unit tests
└── test-brain-tool-calls.ts     # 88 end-to-end tool call tests

设计原则​

• 本地优先：所有数据在 ~/.knox/memory/brain.sqlite。没有任何数据离开您的机器。
• 零配置：开箱即用，带合理默认值。
• LLM 可选：每个 LLM 增强功能都有基于规则的回退。
• 全程审计：每个写操作都带有完整撤销支持的日志记录。
• 优雅降级：断路器、速率限制和弹性回退链。

记忆类型​

1. 语义记忆 — 你知道什么​

从对话中提取的长期事实、决策和知识。

特性：BM25 启发式重排序、重要性评分、情感标签（positive、negative、neutral、surprise、urgency、curiosity）、显著性加权、TTL 过期、关键词索引。

2. 情景记忆 — 发生了什么​

完整的对话历史：每条用户消息、助手响应、工具调用和工具结果，按会话存储。

• 追踪 role、token_count、importance_score、emotional_valence
• 通过外键链接到会话
• 支持跨会话搜索（search_backlogs）
• 自动检测会话内的主题切换（get_session_topics）

3. 知识图谱 — 事物如何关联​

实体及其关系，建模为有向图。

 ┌──────────┐   uses    ┌─────────────┐   depends_on   ┌──────────┐
 │  Knox    ├──────────►│ TypeScript  ├───────────────►│  SQLite  │
 │ (person) │           │ (technology)│                │  (tech)  │
 └──────────┘           └─────────────┘                └──────────┘

13 种实体类型：person、organization、technology、concept、project、file、function、class、variable、location、event、product、custom。

图遍历：扩散激活——从任何实体开始探索，发现按边权重加权的关联节点。

4. 学习模式 — 什么有效，什么无效​

按目标类型（coding、debugging、analysis、research 等）追踪方法的成功/失败率。使用 Jaccard 相似度根据过去的结果为新问题建议最佳方法。

5. 程序性记忆 — 如何做事​

命名的有序工作流及其步骤。追踪执行次数和成功率。

{
  "name": "deploy-to-production",
  "steps": ["Run lint", "Run tests", "Build", "Push to registry", "Deploy"],
  "success_rate": 0.92,
  "execution_count": 13
}

6. 工作记忆 — 当下​

内存中的会话状态和短期缓冲区，刷新到磁盘。为当前对话上下文提供快速访问，无需数据库查询。

5 层记忆层级​

受 CPU 缓存层级和艾宾浩斯遗忘曲线启发。

┌─────────────────────────────────────────────────┐
│  TIER 1: ACTIVE   │ Currently in-session        │ Working Memory
├───────────────────┼─────────────────────────────┤
│  TIER 2: HOT      │ Frequently accessed, recent │ Full fidelity
├───────────────────┼─────────────────────────────┤
│  TIER 3: WARM     │ 1-7 days old, moderate use  │ Full fidelity
├───────────────────┼─────────────────────────────┤
│  TIER 4: COLD     │ 7-90 days old, low access   │ Compressed
├───────────────────┼─────────────────────────────┤
│  TIER 5: FROZEN   │ Archived, rarely accessed   │ Compressed
└───────────────────┴─────────────────────────────┘

自动转换​

间隔重复​

需要复习的记忆会自动浮出。每次检索都会提升记忆的重要性分数，防止衰减——访问越频繁，保留越久。

核心功能​

1. Context Builder​

在 token 预算内自动组装最相关的记忆。用于在每次对话开始时为 AI 提供上下文。

预算分配（默认 4000 tokens）：

memory({ action: "build_context", query: "TypeScript migration", max_tokens: 4000 })

2. 检查点与回滚​

完整的记忆状态快照，支持时间点恢复。

• 创建：快照所有语义记忆、实体和学习模式
• 对比：查看自检查点以来的变更（新增、删除、修改）
• 回滚：将记忆恢复到任何检查点——对话历史保留
• 压缩：gzip 压缩用于节省空间的长期存储
• 生命周期清理：自动清除旧检查点

检查点策略：

• manual — 手动显式创建检查点
• time_based — 按可配置间隔自动创建
• adaptive — 当变更阈值被超过时自动创建
• hybrid — 结合时间和自适应触发器

memory({ action: "create_checkpoint", label: "before-refactor-v2" })
memory({ action: "rollback_checkpoint", checkpoint_id: 4 })

3. 完整审计跟踪​

每个写操作都被记录，包含目标类型、目标 ID 和详情。支持按操作、时间范围和目标过滤。实现：

• 撤销：逆转任何特定操作
• 事件重放：从检查点开始重放变更
• 取证：准确了解什么在何时发生了变更

4. 自动提取​

传入原始文本（对话、代码审查、会议记录），Memory Brain 自动提取：

• 语义记忆（事实、决策、洞察）
• 命名实体（人物、技术、项目）
• 情感标签
• 主题分割

默认基于规则工作。配置 LLM 后可使用 LLM 增强提取（LLM 不可用时自动回退到规则）。

5. 跨会话搜索​

跨所有历史对话会话搜索，支持过滤器：

• 查询文本（全文搜索）
• 日期范围（from_date、to_date）
• 角色过滤器（user、assistant、tool）
• 会话 ID 过滤器

6. 性能监控​

实时健康监控和自我修复能力：

• 度量：追踪操作计数、延迟、缓存命中率
• 健康分数：碎片化、过时数据、容量的加权综合评分
• 容量预测：预测何时达到存储或内存限制
• 自动修复：检测并修复常见问题（孤立记录、索引碎片化）
• 趋势分析：24 小时回溯的历史度量

7. 批量操作​

高效的批量操作：

• batch_store — 一次调用存储多个记忆
• batch_delete — 按 ID 列表删除多个记忆
• batch_update_importance — 批量更新重要性分数
• batch_move_tier — 在层级之间移动记忆
• batch_audit_log — 一次记录多个事件

8. LLM 增强功能（可选）​

连接 LLM 后解锁高级功能：

所有 LLM 功能包括：

• 速率限制：每小时可配置的调用/token 数
• 断路器：重复失败后自动禁用
• 决策缓存：避免对类似输入的冗余 LLM 调用

全部 79 个操作参考​

核心记忆（6 个操作）​

会话管理（5 个操作）​

知识图谱（6 个操作）​

学习引擎（3 个操作）​

程序性记忆（3 个操作）​

标签与集合（6 个操作）​

关联（1 个操作）​

自动记忆（1 个操作）​

维护（5 个操作）​

检查点与回滚（5 个操作）​

审计与撤销（4 个操作）​

跨会话搜索（1 个操作）​

导出 / 导入（2 个操作）​

检查点策略（4 个操作）​

批量操作（5 个操作）​

高级功能（7 个操作）​

性能与健康（11 个操作）​

LLM 增强（4 个操作）​

数据库架构​

17 张表配合 27 个优化索引，运行在启用 WAL 模式和外键约束的 SQLite 上。

brain_sessions           — Conversation sessions
brain_episodic           — Conversation turns (messages, tool calls)
brain_semantic           — Long-term factual memories
brain_associations       — Cross-memory links
brain_entities           — Knowledge graph nodes
brain_graph_edges        — Knowledge graph relationships
brain_learning_patterns  — Success/failure patterns
brain_procedures         — Named workflows
brain_tags               — Memory tags (many-to-many)
brain_collections        — Named memory groups
brain_collection_items   — Collection membership
brain_config             — Configuration key/value store
brain_checkpoints        — Memory state snapshots
brain_rate_limits        — LLM rate limit tracking
brain_audit_log          — Full audit trail
brain_session_topics     — Auto-detected topic shifts
brain_metrics_snapshots  — Performance metrics history

存储：单文件 ~/.knox/memory/brain.sqlite。活跃使用数月后典型大小为 1-10 MB。

优势​

对比向量数据库（Pinecone、Chroma、Weaviate）​

对比基于文件的记忆（.md 文件、JSON）​

对比无记忆（无状态 LLM）​

主要优点​

1. 隐私优先 — 一切存储在本地。核心功能无需 API 调用。
2. 自维护 — 自动合并、衰减、提升和修复。
3. 弹性 — 断路器、回退、速率限制。无单点故障。
4. 可观测 — 完整审计跟踪、健康度量、性能监控。
5. 可逆 — 任何破坏性操作都有检查点/回滚。
6. Token 高效 — Context Builder 只组装 token 预算内的内容。
7. 结构化 — 不只是文本块：类型化实体、加权边、分类事实。
8. 经过测试 — 4 个测试套件中 443 个集成测试，覆盖所有 79 个操作，100% 通过率。
9. LLM 可选 — 每项功能都无需 LLM 即可工作。增强功能优雅降级。
10. 可移植 — 以 JSON 导出/导入一切。在机器间自由迁移。

配置​

所有设置存储在 brain_config 表中，可通过工具调用读取/更新。

memory({ action: "get_config" })
memory({ action: "update_config", key: "max_hot_memories", value: "1000" })

测试覆盖​

四个测试套件执行 443 个集成测试，覆盖所有 79 个操作，通过实际的 dispatch 管线在真实 SQLite 数据库上调用每个操作。

套件 1：test-memory-tool.ts — 94 个测试​

覆盖所有核心 dispatch 操作的原始集成测试。

套件 2：test-brain-debug.ts — 202 个测试​

超全面的集成测试，对每个 dispatch 操作进行深度输出验证、边缘用例和多步骤工作流。

套件 3：test-brain-debug-modules.ts — 59 个测试​

各个类的模块级别单元测试（BrainStore、KnowledgeGraph、LearningEngine、ContextBuilder、CheckpointManager、BatchOperations、AdvancedFeatures、PerformanceMonitor）。

套件 4：test-brain-tool-calls.ts — 88 个测试​

端到端测试，验证所有 79 个工具枚举操作通过 BrainManager.dispatch() 工作，按操作层级组织。

总结​

每个测试套件使用全新的临时数据库，验证输出格式，并在完成后自行清理。

快速入门​

存储记忆​

memory({ action: "store", category: "decision", title: "Use SQLite for memory",
         content: "Chose SQLite over Postgres for zero-config local storage.",
         keywords: "database,sqlite,architecture", importance: 0.9 })

召回相关上下文​

memory({ action: "recall", query: "database choice", limit: 5 })

构建对话前上下文​

memory({ action: "build_context", query: "TypeScript migration project",
         max_tokens: 4000 })

在风险操作前创建安全检查点​

memory({ action: "create_checkpoint", label: "before-major-refactor" })
// ... do risky work ...
memory({ action: "rollback_checkpoint", checkpoint_id: 1 })  // oops, undo

追踪有效方法​

memory({ action: "learn_pattern", goal_type: "debugging",
         description: "Binary search through git history to isolate regression",
         success: true, tokens_used: 1200 })

// Next time:
memory({ action: "suggest_approach", query: "find regression", goal_type: "debugging" })

工具集成​

Memory Brain 作为一等内置工具完全集成到 Knox 工具调用系统中，具有自己的 UI 类别、拦截器验证和权限控制。

注册架构​

core/tools/definitions/memory.ts     → Tool definition (schema, 79 actions, params)
core/tools/implementations/memory.ts → Implementation (routes to BrainManager.dispatch)
core/tools/callTool.ts               → Dispatch (BuiltInToolNames.Memory → memoryImpl)
core/tools/builtIn.ts                → Enum (Memory = "builtin_memory")
core/tools/index.ts                  → allTools array (includes memoryTool)
core/config/load.ts                  → Config (tools: [...allTools])

工具标识​

在 UI 中的显示​

memory 工具显示在 Tools 面板的 Permissions 组下：

● Permissions  [12]                              ⬤ ON
  [Files] Read File                        Auto-Approve
  [Files] Create New File                  Auto-Approve
  [Terminal] Run Terminal Command          Auto-Approve
  [Files] View Subdirectory                Auto-Approve
  [Files] View Repo Structure              Auto-Approve
  [Search] Exact Search                    Auto-Approve
  [Search] Web Search                      Auto-Approve
  [Diff] View Diff                         Auto-Approve
  [Files] Read Currently Open File         Auto-Approve
  [Tool] Load Skill                        Auto-Approve
  [Tool] LSP                               Auto-Approve
  [Memory] Memory                          Auto-Approve

文件位置​

权限状态​

每个工具可以处于三种权限状态之一，通过点击循环切换：

整个 Permissions 组也可以通过组开关整体开关。

工具调用流程（端到端）​

1. LLM generates tool call:
   { name: "builtin_memory", arguments: { action: "store", ... } }

2. ToolCallInterceptor validates:
   - Tool exists in registry ✓
   - Required params present (action) ✓
   - Logs call to history, tracks metrics

3. Permission check:
   - toolSettings["builtin_memory"] === "allowedWithoutPermission"
   - Auto-approved (no user prompt)

4. callTool() dispatches:
   - Matches BuiltInToolNames.Memory
   - Calls memoryImpl(args, extras)

5. memoryImpl() routes:
   - Gets BrainManager singleton
   - Calls brain.dispatch(args.action, args)

6. BrainManager.dispatch() handles:
   - Routes to appropriate handler (store, recall, search, etc.)
   - Records audit trail
   - Emits events
   - Returns formatted string

7. Result returned to LLM as ContextItem[]

在此体验带 Memory Brain 的 KnoxChat VS Code 扩展 >>>

Memory Brain 是 KnoxCore 平台的一部分。所有数据保留在您的机器上。

一个全面的 Todo/Task 管理系统，分析复杂的用户请求，将其分解为结构化的依赖感知任务，并通过工具调用驱动的流同步和持久化会话管理来跟踪进度。

在此安装 KnoxChat 扩展 >>>

问题 — 非结构化的任务执行​

此前，复杂的多步骤请求以整体操作方式处理：

• 无可见性：用户无法看到 AI 正在处理什么或还有什么待处理
• 无恢复：失败的步骤需要重新启动整个请求
• 无持久化：如果会话中断，进度就会丢失
• 无依赖管理：不了解任务排序或前置条件

解决方案 — 流同步任务引擎​

一个完整的任务编排系统，涵盖 VS Code 扩展后端（TodoManager）、双向协议层、Redux 状态管理（todoSlice + planTaskSlice）、工具调用驱动的流同步（todoStreamSync）以及 React GUI（TodoPanel + PlanTaskStatusPanel）。

核心架构​

1. 丰富的数据模型 (core/index.d.ts)​

每个任务是一个包含 30 个字段的 TodoItem：

type TodoStatus = "pending" | "in-progress" | "completed" | "failed" | "cancelled" | "blocked";
type TodoPriority = "high" | "medium" | "low";
type TodoComplexity = "simple" | "medium" | "complex";
type TodoCategory = "coding" | "analysis" | "research" | "testing" | "documentation" | "refactoring" | "devops" | "general";

interface TodoItem {
  id: string;
  title: string;
  description: string;
  status: TodoStatus;
  priority: TodoPriority;
  complexity: TodoComplexity;
  category: TodoCategory;
  dependsOn: string[];           // Upstream task IDs
  blockedBy: string[];           // Tasks blocking this one
  filePaths: string[];           // Associated file paths
  toolsNeeded: string[];         // Tools needed (edit_file, run_terminal_cmd, etc.)
  estimatedTimeMs: number;       // Estimated time in milliseconds
  actualTimeMs: number;          // Actual time spent in milliseconds
  retryCount: number;
  maxRetries: number;
  errorMessage?: string;
  resultPreview?: string;        // Human-readable evidence summary
  verified?: boolean;            // true if completion verified by evidence
  evidenceScore?: number;        // 0-1 confidence score
  toolCallCount?: number;        // Number of tool calls that contributed
  subtasks: TodoItem[];          // Recursive nesting
  parentId?: string;             // Parent todo ID (if subtask)
  orderIndex: number;            // Display order
  createdAt: number;
  startedAt?: number;
  completedAt?: number;
  progress: number;              // 0-100
  tags: string[];                // Technology tags (typescript, react, docker, etc.)
}

2. 会话管理​

任务被分组到具有完整生命周期的 TodoSession 对象中：

interface TodoSession {
  id: string;
  title: string;
  description: string;
  prompt: string;                          // Original user request
  todos: TodoItem[];
  status: "idle" | "active" | "paused" | "completed" | "failed";
  progress: number;                        // 0-100
  stats: TodoSessionStats;
  config: TodoSessionConfig;
  createdAt: number;
  startedAt?: number;
  completedAt?: number;
  workspaceDirectory?: string;
  conversationId?: string;
}

统计数据 — 11 个聚合计数器，包括 verifiedTodos：

interface TodoSessionStats {
  totalTodos: number;
  completedTodos: number;
  verifiedTodos: number;     // Completed todos verified by tool-call evidence
  failedTodos: number;
  cancelledTodos: number;
  inProgressTodos: number;
  pendingTodos: number;
  blockedTodos: number;
  totalEstimatedTimeMs: number;
  totalActualTimeMs: number;
  totalRetries: number;
}

功能 1：AI 驱动的任务分析与分解​

自动分析用户消息以检测何时任务分解有价值，然后使用 ReasoningEngine 或本地 NLP 回退来将其分解。

智能检测 (shouldCreateTodos())：

• 显式触发器：消息中包含 /todo 或 @todo
• 模式匹配：17 个正则模式用于检测复杂任务（全栈、CRUD、REST API、CI/CD、auth、GraphQL、微服务、架构、迁移、数据库架构、组件库、测试框架等）
• 多子句检测：包含 3+ 个由逗号、分号、and 或 then 分隔的子句（每个 >10 字符）的消息
• 阈值：2+ 模式匹配触发创建

AI 分析（通过 ReasoningEngine.performTaskAnalysis()）：

User: "Build a REST API with authentication, add unit tests, and set up Docker deployment"

AI Analysis Result:
├── Todo 1: Set up Express.js REST API scaffold     [high, coding, simple]
├── Todo 2: Implement JWT authentication middleware  [high, coding, medium]
├── Todo 3: Create CRUD endpoints                   [medium, coding, medium]
├── Todo 4: Write unit tests with Jest              [medium, testing, medium]  → depends on [1,2,3]
└── Todo 5: Create Dockerfile and docker-compose    [low, devops, simple]     → depends on [1]

本地回退分析 (performLocalAnalysis())：

• 句子边界分割（. ; and then, then）
• 单句输入的逗号分割回退
• 通过 8 个关键词字典自动推断类别（coding、analysis、research、testing、documentation、refactoring、devops、general）
• 复杂度：simple（≤2 步）、medium（3–5）、complex（>5）
• 优先级分配：前三分之一 = high，中间 = medium，后三分之一 = low
• 通过正则提取文件路径（/path/to/file.ext）
• 技术标签检测：TypeScript、JavaScript、React、Node.js、Python、Rust、API、Database、UI、CSS、HTML、Docker
• 从动作动词推断工具：create → edit_file、test → run_terminal_cmd、search → grep_search/codebase_search、install → run_terminal_cmd、delete → delete_file、list → list_dir

计划生成： 对于复杂任务（>2 步），系统通过 ReasoningEngine.generateImplementationPlan() 生成结构化实施计划并写入 .knox/plans/plan_{sessionId}.md。计划步骤有状态标记（❌ → 🔄 → ✅），随着 todo 进展而更新。

功能 2：顺序流同步执行引擎​

任务在流同步模型中逐个执行。GUI 的 todoStreamSync 驱动推进——后端 TodoManager.processNextTodos() 只将下一个就绪的 todo 标记为 in-progress（最多 1 个并发）。

依赖解析：

[Task A] ──→ [Task C] ──→ [Task E]
[Task B] ──→ [Task D] ──┘

• Tasks execute sequentially (1 at a time)
• Task B starts only after Task A completes
• Dependency-blocked tasks transition: blocked → pending when upstream completes

关键机制：

• processNextTodos()：选择第一个就绪的 todo（pending + 依赖已满足）并标记为 in-progress。一次只允许 1 个。
• areDependenciesMet()：检查所有 dependsOn 的 todo 是否为 completed 或 cancelled
• unblockDependentTodos()：当依赖解决时将 blocked → pending；清除 blockedBy 引用
• getReadyTodos()：返回所有依赖已满足的 pending todo
• advanceToNextTodo()：从 GUI 流同步调用；完成当前进行中的 todo，触发 processNextTodos()
• AbortController：在暂停/取消时干净地取消进行中的执行

执行模型（流同步）：

todoStreamSync.ts (GUI)                        TodoManager.ts (IDE)
────────────────────                           ─────────────────────
onStreamStart()                                
  ├─ Build tracker state                       
  ├─ dispatch(startTodoSession)  ──────────→   startSession()
  │                                              └─ processNextTodos() → mark first todo in-progress
  │                                            
onToolCallEvent() × N                          
  ├─ Count tool calls on current task          
  ├─ Collect affected file paths               
  ├─ If toolCallCount ≥ 3 (AUTO_ADVANCE):     
  │   dispatch(completeTodo)     ──────────→   completeTodo() → unblock deps → processNextTodos()
  │                                            
onStreamEnd() [wrapperDepth === 0 only]        
  ├─ Complete ALL remaining tasks              
  └─ dispatch(completeTodo) for each  ─────→   completeTodo() → checkSessionCompletion()

功能 3：带退避的自动重试​

失败的任务以递增的延迟自动重试。

配置：

• retryOnFailure：开关自动重试（默认：true）
• maxRetries：每个任务的最大重试次数（默认：2）

退避公式： 1000 × retryCount ms

• 第 1 次重试：1 秒延迟
• 第 2 次重试：2 秒延迟

行为：

• 如果还有重试次数：重置状态为 pending，增加 retryCount，在退避后安排重试
• 如果重试次数耗尽：永久标记为 failed 并附带 errorMessage，仍处理下一个 todo
• 手动重试：通过 UI 按钮可用，增加 retryCount，重置状态为 pending

功能 4：持久化会话存储​

会话自动保存到磁盘，在编辑器重启后依然存在。

存储布局：

.knox/
├── todos/
│   ├── {sessionId}.json         # Full session + all todos (JSON)
│   └── ...
└── plans/
    ├── plan_{sessionId}.md      # Implementation plan (Markdown)
    └── ...

特性：

• 自动保存计时器：每个会话的可配置间隔（默认 30s），通过 setInterval
• 事件触发保存：在状态变化时通过 persistSession() 调用
• 原子写入：通过 vscode.workspace.fs.writeFile API
• 启动时加载：loadPersistedSessions() 从 .knox/todos/ 读取所有 .json 文件
• 会话删除：同时移除内存中的 map 条目和磁盘上的 JSON 文件

功能 5：实时进度跟踪 UI​

两个 React 面板，集成到聊天界面中，支持实时更新。

主面板 — TodoPanel.tsx（9 个子组件）：

次要面板 — PlanTaskStatusPanel.tsx：

• 统一的流式进度面板，合并 Knox MS 任务元数据和 todo 进度
• TodoTaskRow 子组件渲染带状态图标和工具调用计数的个别 todo 项
• 当 Knox MS 任务为空时回退到基于 todo 的任务列表
• 在流式传输期间显示来自 planTaskSlice 的 todoCurrentTitle

使用 29 个 Lucide React 图标，包括 Shield、Zap、CheckCircle2、Loader2、Lock、AlertTriangle、Code2、FlaskConical、Globe、FileText、Wrench、Sparkles、Lightbulb 等。

面板状态：

Collapsed:  [Todo Progress ▼] [75%] ████████░░
Expanded:   Status • 3/4 completed • 75% with full task list, actions, stats
No Session: Create form with prompt input

功能 6：双向协议层​

在 VS Code 扩展和 React webview 之间完全类型化的消息传递，定义在 core/protocol/ 中。

IDE → Webview（5 种消息） — ToWebviewFromIdeOrCoreProtocol：

Webview → IDE（13 种消息） — ToIdeFromWebviewProtocol：

功能 7：Redux 状态管理​

两个 Redux Toolkit slice，包含 12 个异步 thunk，覆盖完整的会话生命周期。

todoSlice 状态：

interface TodoState {
  currentSession: TodoSession | null;
  sessions: TodoSession[];
  isPanelVisible: boolean;
  isPanelCollapsed: boolean;
  isLoading: boolean;
  error: string | null;
  autoCreateEnabled: boolean;
  viewingSessionId: string | null;
}

12 个异步 Thunk： createTodoSession、startTodoSession、pauseTodoSession、resumeTodoSession、cancelTodoSession、retryTodo、skipTodo、completeTodo、advanceSession、fetchCurrentSession、fetchAllSessions、deleteTodoSession

12 个同步 Reducer： sessionCreated、sessionUpdated、sessionCompleted、todoUpdated、progressUpdated、togglePanelVisible、togglePanelCollapsed、setPanelCollapsed、setPanelVisible、toggleAutoCreate、setViewingSession、clearError

planTaskSlice 集成： planTaskSlice 跟踪流式传输元数据（Knox MS + todo 同步），字段包括：

• hasTodoSync、todoSessionId、todoCurrentIndex、todoCompletedCount
• 由 todoStreamSync 通过 syncTodoProgress action 更新

自动重置： 当新聊天会话开始时，Todo 状态通过 newSession extra reducer 重置。

功能 8：会话配置​

每个会话 8 个可调参数（TodoSessionConfig）：

功能 9：国际化 (i18n)​

跨英语和中文的 107 个翻译键，提供完整的多语言支持。

扩展 (extensions/vscode/src/i18n/locales/en/todo.json)： 43 个键，覆盖会话生命周期、任务操作、状态消息、计划审批、验证轮次

GUI (gui/src/locales/en/todo.json)： 64 个键，覆盖面板 UI、状态标签、操作按钮、统计数据、空状态、提示信息、验证徽章、难度等级

语言： English (en) + Chinese (zh)

功能 10：VS Code 命令注册​

通过 TodoManager.registerCommands() 中的 vscode.commands.registerCommand 注册 18 个命令：

功能 11：工具调用驱动的进度跟踪 (todoStreamSync)​

设计原则：

1. 工具调用 = 进度。 每个工具调用推进当前任务的计数。足够多的调用后，任务被标记为完成。
2. 顺序模型。 AI 按顺序执行任务。currentIndex 指针向前推进。
3. 不得提前完成。 任务仅在积累足够的工具调用后 或 整个对话结束时（在 wrapperDepth === 0 的最外层包装退出）才完成。
4. 每个完成的任务都获得盾牌图标。 在跟踪器层面没有"低证据"与"已验证"的区分。

架构：

callTool.ts          todoStreamSync.ts              TodoManager.ts
───────────         ──────────────────             ──────────────────
ToolCallEvent ──→   onToolCallEvent()
                      ├─ Count on current task
                      ├─ Collect file paths
                      ├─ If count ≥ 3 (AUTO_ADVANCE_THRESHOLD):
                      │   completeCurrentAndAdvance()
                      │     └─ dispatch(completeTodo) ──────→  completeTodo()
                      │                                          ├─ Parse verification metadata
                      │                                          ├─ Update plan file (🔄 → ✅)
                      │                                          ├─ Unblock dependents
                      │                                          └─ processNextTodos()
                      │
                      └─ emitProgress() → syncTodoProgress   planTaskSlice
                                           (Redux action)       → PlanTaskStatusPanel (UI)
                                                                → TodoPanel (UI)

跟踪器状态：

interface TrackerState {
  sessionId: string;
  todos: TodoEntry[];      // { id, title, completed, toolCallCount, files, chars }
  currentIndex: number;
  totalToolCalls: number;
  totalChars: number;
  finished: boolean;
  roundCount: number;
}

关键常量：

• AUTO_ADVANCE_THRESHOLD = 3 — 自动推进到下一个任务所需的工具调用次数

包装深度跟踪：

• onWrapperEnter() / onWrapperExit() 管理一个 wrapperDepth 计数器
• 流结束协调（onStreamEnd()）仅在 wrapperDepth === 0 时触发
• 中间工具调用轮次（depth > 0）为空操作

会话初始化：

• 如果 Redux 中存在会话且为 idle → 初始化跟踪器 + 启动后端会话
• 如果会话为 active → 附加跟踪器而不重新启动
• 如果没有会话 → 每 200ms 轮询一次，最长 8 秒，然后放弃
• 早期的工具调用和数据块在跟踪器初始化前被缓冲

流结束行为：

• 在最外层退出时：无条件完成所有剩余任务
• 每个剩余任务获得 dispatch(completeTodo) 并附带结果预览（例如，"Completed with N tool call(s), M file(s)"）
• 通过 setCompletionSummary 分发完成摘要

验证元数据解析 (TodoManager)： 当 completeTodo() 接收到 resultPreview 字符串时，parseVerificationMetadata() 提取：

• verified：如果预览包含 [verified]、Verified:、text verified 或 [tool-evidence] 则为 true
• evidenceScore：从 score: N%、evidence: N%、keyword match: N% 或 (N%) 提取；如果已验证默认为 0.8，否则为 0
• toolCallCount：从 N tool call 模式提取

UI 指示器：

• 盾牌图标（🛡 青色）：带工具调用证据的已验证完成
• 对勾（✓）：标准完成
• 警告（⚠ 黄色）：低证据完成 — 可能需要审查
• 闪电徽章（⚡N）：工具调用计数指示器
• 百分比徽章：低置信度项目的证据分数
• 结果预览提示：悬停时显示完整证据摘要

什么是 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 种不同的修复操作类型诊断和修复自身。

修复操作​

自我修复工作原理​

当自主循环遇到错误时：

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 意味着无限制——没有上限。

特殊参数​

35+ REST 端点​

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

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

总结​

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

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

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

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

Knox Memory System (knox-ms) 是一个革命性的自定义 AI 模型，通过像人脑一样运作的智能记忆管理系统，提供真正无限的上下文窗口长度。与受固定上下文窗口限制的传统 LLM（即使有上下文缓存）不同，knox-ms 通过复杂的计划-任务-记忆架构编排多个底层模型来突破这些限制。

核心创新：无限上下文​

knox-ms 的核心突破是其记忆系统——一个存储在 Knox Server System(KSS) 中的动态、自更新知识库，它：

• 像大脑一样运作：在无限次对话中维护持久、有组织的记忆
• CRUD 操作：根据任务执行动态地创建、读取、更新和删除记忆条目
• 上下文缓存集成：与 LLM 上下文缓存（提示缓存）无缝配合以优化性能
• 智能记忆管理：自动决定哪些内容需要记住、更新或遗忘
• 层级组织：从近期（完整细节）到长期（语义摘要）结构化信息

架构理念​

Memory System (大脑) = 核心智能
  ↓ 管理和更新
Context Cache (LLM) = 工作记忆
  ↓ 增强于
Vector Embeddings & Rerank (工具) = 信息检索

工作原理：

1. 记忆系统作为持久化大脑，存储所有会话历史、计划和学习到的模式
2. LLM 上下文缓存作为工作记忆，由记忆系统的智能加载优化
3. 向量嵌入提供在需要时检索相关用户项目上下文的工具

这种架构使 knox-ms 能够处理任何规模的对话和项目——从简短查询到跨月开发项目——而不会丢失上下文或达到 token 限制。

模型身份​

{
    "id": "knox/knox-ms",
    "object": "model",
    "created": 1735689600,
    "owned_by": "KnoxChat",
    "root": "knox/knox-ms",
    "parent": null
}

架构​

核心组件​

1. 计划模型​

• 默认模型：Your preferred model
• 用途：分析输入并创建结构化的执行计划
• 输出：带有难度分类（简单/中等/困难）的任务分解
• 职责：
  • 解析用户意图
  • 将复杂请求分解为原子任务
  • 分配难度级别
  • 定义执行顺序和依赖关系

2. 任务/TODO 系统​

作为智能任务管理器：

• 按类型（编码 vs. 非编码）分类任务
• 根据复杂度将任务路由到适当的模型
• 追踪任务进度和状态
• 管理任务依赖和执行顺序
• 记录任务完成情况和结果

任务难度矩阵：

3. 向量嵌入与重排序系统​

向量嵌入与重排序系统通过以下方式提供智能上下文检索：

• 用途：将用户项目文件、代码和文档转换为语义向量以进行智能检索
• 范围：与记忆系统分离——专注于用户的项目内容，而非 knox-ms 内部状态
• 组件：
  • 嵌入生成：将用户项目文件处理为向量嵌入
  • 向量存储：存储带有元数据（文件路径、时间戳、类型）的嵌入
  • 语义搜索：基于用户查询检索相关项目上下文
  • 重排序引擎：使用高级排序算法按相关性重新排列搜索结果

向量嵌入流水线：

1. 索引阶段（按需或后台）：

   User Project Files → Chunking → VoyageAI Embedding API → Vector Store
   

   • 支持的文件类型：.rs、.py、.js、.ts、.md、.json、.yaml 等
   • 分块大小：2048 个 token，带重叠
   • 嵌入模型：voyage-3.5（通用）或 voyage-code-3（代码导向项目）
   • API：VoyageAI Embeddings API

2. 检索阶段（每次请求）：

   User Query → VoyageAI Query Embedding → Semantic Search → Top-K Results → VoyageAI Rerank → Final Context
   

   • Top-K：从向量搜索中获取 20-50 个候选项
   • 重排序模型：rerank-2.5（VoyageAI）
   • 最终选择：前 5-10 个最相关的分块

与 Knox-MS 的集成：

• 为计划模型提供相关项目上下文以更好地进行任务分解
• 为代码模型选择提供代码示例和模式
• 将项目特定知识与 knox-ms 内部记忆分离

存储结构：

KSS://knox-ms-vectors/
├── projects/
│   ├── {project_id}/
│   │   ├── metadata.json       # File index and metadata
│   │   ├── chunks/
│   │   │   ├── file_{hash}.json  # Chunked content with embeddings
│   │   └── index/
│   │       └── stats.json      # Indexing statistics
│   └── cache/
│       └── queries/            # Cached query results

4. 记忆系统​

记忆系统是 knox-ms 的大脑——通过智能、动态的记忆管理提供真正无限的上下文：

核心概念：类人记忆​

正如人脑不会存储每个细节，而是根据相关性组织和更新记忆，knox-ms 记忆系统：

• 持久存储：基于 KSS 的树结构文件系统，提供无限存储
• 动态 CRUD 操作：根据任务执行持续地创建、读取、更新和删除记忆
• 智能组织：自动以层级结构组织信息
• 上下文感知加载：仅将相关记忆加载到 LLM 上下文缓存中
• 自我优化：总结、压缩和重组记忆以保持效率

记忆 vs. 上下文缓存 vs. 向量嵌入​

记忆系统管理进入 LLM 上下文缓存的内容，而向量嵌入作为获取相关项目信息的工具。

动态 CRUD 操作​

记忆系统根据任务执行进行智能 CRUD 操作：

CREATE（新信息）：

• 新会话初始化 → 创建 session/{session_id}/ 目录
• 新计划生成 → 创建 plans/plan_{id}.md
• 新任务开始 → 创建 tasks/task_{id}.md
• 发现新模式 → 在 knowledge/patterns/ 中创建条目

READ（上下文加载）：

• 从 history.md 加载最近的对话
• 从 plans/ 检索相关计划
• 从 tasks/status.md 获取任务状态
• 查询知识库以查找类似的过往情况

UPDATE（记忆优化）：

• 任务完成 → 用结果更新 tasks/task_{id}.md
• 对话继续 → 追加到 history.md
• 上下文增长过大 → 用摘要更新 context.md
• 新模式匹配已有模式 → 更新 knowledge/patterns/

DELETE（记忆优化）：

• 旧的临时文件 → 摘要化后删除
• 冗余信息 → 移除重复
• 失败/取消的任务 → 归档或删除
• 过期的缓存条目 → 使其失效并移除

KSS 存储结构​

• KSS 存储：将所有 knox-ms 交互存储在 KSS 上的树结构文件系统中

• Markdown 文件：所有内容以 .md 文件形式持久化，便于人类阅读

• 动态更新：根据计划和任务系统的执行自动更新相关文件

• 关注点分离：

  • 记忆系统（KSS）：Knox-ms 内部状态、会话历史、任务记录、计划
  • 向量嵌入：用于上下文检索的用户项目内容、代码、文档

• 层级组织（KSS）：

• 层级组织（KSS）：

  KSS://knox-ms-memory/
  ├── sessions/
  │   ├── {session_id}/
  │   │   ├── context.md          # Current conversation context (optimized for cache)
  │   │   ├── history.md          # Full conversation history
  │   │   ├── tasks/
  │   │   │   ├── task_{id}.md    # Individual task records
  │   │   │   └── status.md      # Task status tracker
  │   │   └── plans/
  │   │       └── plan_{id}.md    # Execution plans
  │   └── summary.md              # Session summary
  ├── knowledge/
  │   ├── code/                   # Code-related memory
  │   ├── concepts/               # Learned concepts
  │   └── patterns/               # Recognized patterns
  └── index.md                    # Global memory index
  

上下文缓存集成​

记忆系统智能地管理 LLM 上下文缓存（提示缓存）：

优化策略：

1. 缓存优化加载：组织记忆以最大化缓存命中率
2. 稳定前缀：将常用上下文保持在稳定前缀中以利于缓存
3. 动态后缀：追加每次请求变化的任务特定上下文
4. 缓存失效：当记忆显著更新时进行智能失效
5. Token 管理：在缓存重用和新鲜上下文之间取得平衡

记忆 → 缓存流程：

Memory System (KSS) 
  → Load relevant memory 
  → Structure for optimal caching 
  → LLM Context Cache (prompt cache)
  → Execute task
  → Update Memory with results
  → Optimize cache structure

优势：

• 成本效率：跨请求复用缓存上下文（降低输入 token 成本）
• 速度：通过缓存提示加快响应时间
• 无限扩展：记忆系统处理缓存无法处理的内容（无限历史）
• 智能：记忆系统决定缓存什么 vs. 总结什么

记忆能力​

• 上下文优化：持续优化和总结过往交互
• 相关检索：仅提取当前任务所需的上下文
• 循环集成：在任务执行期间持续更新
• KSS 优势：可扩展、持久、经济高效的无限记忆存储
• 跨会话学习：在不同会话间共享知识
• 模式识别：识别和记忆重复出现的模式

API 规范​

模型对象​

{
    "architecture": {
        "input_modalities": ["file", "image", "text"],
        "modality": "text+image->text",
        "output_modalities": ["text"],
        "tokenizer": "Claude"
    },
    "context_length": -1,
    "created": 1735689600,
    "id": "knox/knox-ms",
    "object": "model",
    "owned_by": "KnoxChat",
    "parent": null,
    "permission": [
        {
            "allow_create_engine": true,
            "allow_fine_tuning": false,
            "allow_logprobs": true,
            "allow_sampling": true,
            "allow_search_indices": false,
            "allow_view": true,
            "created": 1735689600,
            "group": null,
            "id": "modelperm-knox-ms-001",
            "is_blocking": false,
            "object": "model_permission",
            "organization": "*"
        }
    ],
    "pricing": {
        "completion": "0.000015",
        "image": "0",
        "input_cache_read": "0.0000003",
        "input_cache_write": "0.0000015",
        "internal_reasoning": "0",
        "prompt": "0.000003",
        "request": "0",
        "web_search": "0"
    },
    "root": "knox/knox-ms",
    "supported_parameters": [
        "enable_vector_search",
        "include_reasoning",
        "max_tokens",
        "memory_mode",
        "project_id",
        "reasoning",
        "rerank_threshold",
        "response_format",
        "session_id",
        "stop",
        "structured_outputs",
        "temperature",
        "tool_choice",
        "tools",
        "top_k",
        "vector_top_k",
        "verbosity"
    ],
    "top_provider": {
        "context_length": -1,
        "is_moderated": true,
        "max_completion_tokens": 128000
    }
}

特殊参数​

请求格式​

{
    "model": "knox/knox-ms",
    "messages": [
        {
            "role": "user",
            "content": "Build a REST API with user authentication"
        }
    ],
    "temperature": 0.7,
    "max_tokens": 8192,
    "stream": true,
    "session_id": "session_abc123",
    "project_id": "proj_xyz789",
    "enable_vector_search": true,
    "vector_top_k": 30,
    "rerank_threshold": 0.5,
    "memory_mode": "full",
    "include_reasoning": true
}

响应格式（流式）​

{
    "id": "chatcmpl-knox-ms-xxx",
    "object": "chat.completion.chunk",
    "created": 1735689600,
    "model": "knox/knox-ms",
    "choices": [
        {
            "index": 0,
            "delta": {
                "role": "assistant",
                "content": "..."
            },
            "finish_reason": null
        }
    ],
    "knox_ms_meta": {
        "current_task": "task_001",
        "task_status": "in_progress",
        "plan_id": "plan_001",
        "model_used": "Your preferred model",
        "memory_tokens_saved": 45000,
        "vector_search": {
            "enabled": true,
            "chunks_retrieved": 8,
            "rerank_score_avg": 0.78,
            "retrieval_time_ms": 145
        }
    }
}

响应格式（非流式）​

{
    "id": "chatcmpl-knox-ms-xxx",
    "object": "chat.completion",
    "created": 1735689600,
    "model": "knox/knox-ms",
    "choices": [
        {
            "index": 0,
            "message": {
                "role": "assistant",
                "content": "..."
            },
            "finish_reason": "stop"
        }
    ],
    "usage": {
        "prompt_tokens": 150,
        "completion_tokens": 2500,
        "total_tokens": 2650
    },
    "knox_ms_meta": {
        "tasks_completed": 5,
        "plans_executed": 1,
        "total_model_calls": 8,
        "memory_operations": {
            "reads": 12,
            "writes": 5
        },
        "vector_search": {
            "enabled": true,
            "total_chunks_retrieved": 8,
            "rerank_score_avg": 0.78,
            "retrieval_time_ms": 145,
            "project_files_indexed": 342
        }
    }
}

工作流程详解​

1. 请求处理流程​

1. 接收用户输入
2. 记忆系统加载（如提供了 session_id）：
   a. READ：从 KSS 加载会话上下文
   b. READ：解析相关历史和任务状态
   c. 组织记忆以实现最优 LLM 上下文缓存
   d. 准备稳定前缀（可缓存）+ 动态后缀（新上下文）
3. 向量嵌入与重排序（如提供了 project_id 且已启用）：
   a. 通过任意向量数据库从用户输入生成查询嵌入
   b. 在项目向量存储（KSS）中执行语义搜索
   c. 检索 Top-K 候选分块
   d. 使用任意 rerank 模型按相关性重排序结果
   e. 提取最相关的项目上下文
4. 计划模型分析输入 + 记忆上下文 + 项目上下文
   - 利用 LLM 上下文缓存提高效率
   - 记忆系统提供相关的历史上下文
5. 任务/TODO 系统接收结构化计划
6. 对于每个任务：
   a. 确定任务类型（编码/通用）
   b. 评估难度（简单/中等/困难）
   c. 选择适当的模型
   d. UPDATE：在记忆系统（KSS）中创建任务记录
   e. 使用相关记忆上下文（已缓存）执行任务
   f. 向用户流式传输响应
   g. UPDATE：将任务结果写入记忆系统
   h. UPDATE：更新任务状态
7. 记忆系统 CRUD 操作：
   a. UPDATE：追加到 history.md
   b. UPDATE：如需要则用摘要优化 context.md
   c. CREATE/UPDATE：将学到的模式保存到知识库
   d. DELETE：移除临时文件
   e. 为下次请求的上下文缓存进行优化
8. 返回带有元数据的最终响应

2. 记忆管理流程（CRUD 操作）​

1. 请求开始时（READ）：
   - READ：从 KSS 加载会话上下文
   - READ：解析 history.md 以获取相关上下文
   - READ：从任务状态构建工作上下文
   - READ：获取相关知识库条目
   - 组织加载的记忆以优化 LLM 上下文缓存
   - 如提供了 project_id 则触发向量搜索（工具操作）

2. 执行期间（CREATE/UPDATE）：
   - CREATE：初始化新的任务记录（tasks/task_{id}.md）
   - UPDATE：实时更新任务状态（tasks/status.md）
   - UPDATE：将中间结果写入 KSS 上的任务文件
   - UPDATE：维护运行中的上下文摘要
   - 缓存会话的向量搜索结果（工具缓存）
   - UPDATE：将重要事件追加到 history.md

3. 请求完成时（UPDATE/DELETE/CREATE）：
   - UPDATE：将完整交互追加到 KSS 上的 history.md
   - UPDATE：优化 context.md（如超出阈值则进行摘要）
   - CREATE/UPDATE：将新模式添加到 knowledge/patterns/
   - UPDATE：将最终任务状态和结果写入 KSS
   - DELETE：移除临时/冗余数据
   - UPDATE：重组记忆结构以实现最优缓存
   - CREATE：如创建了新项目文件则更新向量嵌入（工具更新）
   - UPDATE：使过期缓存条目失效

4. 记忆优化（后台）：
   - 分析记忆使用模式
   - 将旧对话压缩为摘要
   - 归档已完成的会话
   - 构建语义索引以加快检索

3. 向量嵌入索引流程（工具操作）​

注意：向量嵌入作为检索用户项目信息的工具，而非大脑/记忆。

1. 项目索引（由 API 或 webhook 触发）：
   - 扫描项目目录中支持的文件类型
   - 过滤二进制文件、构建产物、node_modules 等
   - 将文件分割为语义段（2048 个 token，256 个重叠）
   - 使用任意向量数据库 API 生成嵌入（voyage-3.5 或 voyage-code-3）
   - 将分块和嵌入存储在 KSS 中（KSS://knox-ms-vectors/）
   - 更新项目索引统计

2. 增量更新（文件变更时）：
   - 通过文件哈希比较检测变更文件
   - 通过任意向量数据库重新分块和重新嵌入修改的文件
   - 用新嵌入更新 KSS 向量存储
   - 使相关查询缓存失效

3. 查询处理（每次请求 - 工具使用）：
   - 通过任意向量数据库从用户输入生成查询嵌入
   - 在向量存储（KSS）中执行余弦相似度搜索
   - 检索 Top-K 候选项（例如 K=30）
   - 将候选项传递给任意 rerank 模型
   - 选择 Top-N 结果（例如 N=8）
   - 为计划模型格式化上下文
   - 在会话中缓存结果以供复用

4. 上下文优化策略​

记忆系统（大脑）和向量嵌入（工具）协同工作以实现无限上下文：

记忆系统（大脑 - 基于 KSS）：

1. 滑动窗口：保持最近 N 个 token 的完整细节以提供即时上下文
2. 智能摘要：压缩较早的交互同时保留关键洞察
3. 语义索引：索引重要概念、决策和模式以便检索
4. 选择性加载：仅将相关记忆段加载到 LLM 上下文缓存中
5. 层级压缩：
   • 近期（最近几轮）：包含所有上下文的完整细节
   • 中期（上一会话）：关键要点和决策
   • 长期（历史）：语义摘要和模式
6. 上下文缓存优化：组织记忆以最大化 LLM 提示缓存命中
7. 动态 CRUD：根据任务执行持续更新记忆
8. 模式识别：从过往交互中学习并应用于新情况

向量嵌入（工具 - 项目上下文检索）：

1. 语义搜索：通过任意向量数据库基于查询含义检索相关代码/文档
2. 重排序：使用任意 rerank 模型进行细粒度相关性评分
3. 缓存：缓存频繁查询结果以加快检索
4. 增量索引：仅更新变更文件以减少开销
5. 元数据过滤：按文件类型、时间或项目区域预过滤

集成：

• 记忆系统管理加载什么上下文以及何时加载
• 向量嵌入提供获取相关项目信息的工具
• LLM 上下文缓存受益于记忆系统的智能组织
• 三者协同工作以突破上下文窗口限制

knox-ms 模型通过其智能记忆管理系统提供真正无限的上下文，使跨月开发项目在不丢失上下文或达到 token 限制的情况下成为可能。

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

• OpenAI API 兼容基础 URL：https://knox.chat/v1
• 标准 API 基础 URL：https://knox.chat

之后/现在​

• OpenAI API 兼容基础 URL：https://api.knox.chat/v1
• 标准 API 基础 URL：https://api.knox.chat

聊天体验​

即时响应流式传输​

等待完整响应或处理连接中断的日子已经过去。我们全新的实时聊天系统在 AI 生成响应时逐字符传输，创造出自然的对话流程，感觉更像是与人聊天而非查询机器。

改进亮点：

• 零延迟：消息在 AI 生成时即时显示
• 不间断连接：自动重连确保您永远不会丢失对话
• 无缝体验：不再有加载动画或冻结的界面
• 双向通信：系统现在可以双向发送更新

增强的可靠性​

之前的系统依赖于容易断开或超时的基本 HTTP 连接。新架构提供：

• 自动恢复：如果连接中断，会无缝重连而不丢失上下文
• 更好的错误处理：清晰的错误消息和优雅的降级处理
• 防火墙友好：即使在受限的网络环境中也能正常工作
• 更低的资源消耗：更高效的连接池管理减少服务器负载

实时仪表盘分析​

实时统计数据​

您的统计数据现在可以即时更新，无需手动刷新。每次 API 调用、每个使用的 token、每笔产生的费用——全部实时可见。

关键改进：

• 即时更新：在使用服务时实时查看使用统计数据的变化
• 低于 20 毫秒的延迟：变更几乎瞬间显示
• 节省 99% 带宽：不再需要持续轮询或页面刷新
• 智能聚合：每 30 秒进行一次定期汇总，提供全面洞察

高级分析标签页​

全新的高级标签页为专业用户提供精密的分析工具：

对比模式：

• 不同时间段的并排分析
• 模型性能对比
• 跨供应商的成本效率追踪

模型性能分析：

• 深入分析单个模型的使用模式
• 成功率追踪
• 响应时间分析
• Token 效率指标

增强的可视化：

• 实时更新的交互式图表
• 下钻功能用于详细分析
• 导出功能用于外部报告
• 自定义日期范围选择

多维度洞察​

统计页面现在提供五个全面的视图：

• 概览：高级指标和趋势
• 模型：按 AI 模型的详细细分
• 供应商：不同 AI 供应商的性能对比
• 分析：高级指标和性能指示器
• 高级：专业用户深度分析工具

透明的实时计费​

即时成本可见性​

不再猜测成本或等待计费更新。每次请求现在都提供即时的成本反馈。

实时成本追踪：

• 消费前提醒：在扣费前查看预估成本
• 实时成本更新：在计算时观察实际成本的出现
• 退款通知：当超估成本被退还时获得通知
• 进度指示器：查看系统获取实际供应商成本的状态

精确的计费流程​

新的计费系统提供前所未有的透明度：

1. 即时预估：在您发起请求时显示预测成本
2. 后台验证：异步从供应商获取实际成本
3. 自动退款：自动退还任何多收的金额
4. 实时更新：所有变更即时显示在您的界面中

智能重试逻辑：系统最多尝试 15 次从供应商获取准确成本，采用智能退避间隔，确保最大准确性。

成本明细可见性​

用户现在可以看到：

• 预消费金额（初始预估）
• 实际成本（从供应商验证）
• 退款金额（如适用）
• 最终计费状态（成功或回退）

活动页面增强​

实时活动监控​

活动页面现在提供系统使用的实时洞察：

• 实时请求追踪：实时查看请求
• 实时状态更新：即时监控成功率和失败情况
• 动态过滤：无需页面重新加载即可实时过滤活动
• 即时搜索：立即查找特定活动

增强的用户体验​

• 流畅交互：所有操作无需页面刷新
• 响应式设计：针对所有设备尺寸优化
• 智能缓存：更快的加载时间和更少的服务器请求
• 渐进式加载：内容在可用时逐步显示

性能提升​

速度提升​

整个平台现在以前所未有的速度运行：

• 快 3-5 倍：实时更新消除了慢速 HTTP 轮询的需要
• 降低服务器负载：高效的连接管理
• 更好的资源利用：智能缓存和连接池
• 优化的数据库查询：更快的数据检索和处理

用户体验改进​

• 不再需要刷新按钮：一切自动更新
• 即时反馈：每个操作提供即时的视觉确认
• 流畅动画：精心打磨的过渡和加载状态
• 一致性能：无论网络条件如何都能提供可靠的体验

健壮的架构​

向后兼容性​

新系统与现有工作流程保持完全兼容：

• 优雅降级：如需要可回退到之前的方法
• 零停机迁移：为现有用户提供无缝过渡
• API 兼容性：所有现有集成继续正常工作

面向未来的设计​

在设计时就考虑了可扩展性：

• 基于房间的广播：为未来的多用户功能奠定基础
• 输入指示器：为实时协作功能做好准备
• 在线状态检测：用户状态追踪框架
• 语音/视频就绪：架构支持未来的媒体流

这对您意味着什么​

对于普通用户​

• 更快的对话：聊天响应在生成时即时显示
• 成本透明：始终准确了解您的支出
• 实时洞察：实时监控您的使用模式
• 可靠的服务：因连接问题而丢失对话的情况不再发生

对于专业用户​

• 高级分析：深入了解使用模式和性能指标
• 实时监控：实时追踪系统性能和成本
• 导出功能：生成报告并在外部分析数据
• 对比工具：有效评估不同的模型和供应商

对于管理员​

• 全系统可见性：实时监控所有用户和系统健康状况
• 即时警报：在问题发生时获得通知
• 性能追踪：监控系统效率和资源使用
• 成本管理：追踪和优化整个组织的支出

展望未来​

此次更新为令人期待的未来功能奠定了基础：

• 协作工作空间：多用户聊天室和共享对话
• 高级通知：基于使用模式和成本的智能警报
• 预测分析：AI 驱动的使用趋势洞察
• 自定义仪表盘：根据个人需求定制的个性化视图

向实时架构的转变不仅仅是一次技术升级——它是对用户应如何与 AI 服务交互的完全重新构想。KnoxChat 的每个方面现在都能即时响应、提供透明的反馈，并在信息可用的那一刻就提供洞察。

欢迎来到 KnoxChat AI 对话平台，在这里一切都实时发生，您始终完全掌控您的 AI 交互和成本。

从 RAG 到推理：Knox 如何通过语义智能实现 90%+ 的上下文准确率

执行摘要​

Knox AI 上下文系统代表了 AI 理解代码方式的范式转变。与将代码视为文本块的传统检索增强生成（RAG）系统不同，Knox 实现了一个多维语义理解引擎，由以下技术驱动：

• 深度语义分析：跨 5+ 种语言的完整 AST 解析和符号解析
• 知识图谱架构：14 种关系类型的基于图的遍历
• 时序智能：完整的代码演化追踪和模式分析
• 上下文排序与裁剪：ML 驱动的相关性评分，带 4 因子加权
• 增量更新：实时分析，10-100 倍性能提升
• 自适应学习：从用户交互中持续改进
• 协作智能：团队级上下文共享和同步

核心结论：Knox 实现了 90-95% 的上下文准确率，相比 RAG 的 60-70%，从根本上改变了 AI 辅助开发的可能性。

为什么这个系统是革命性的​

传统 RAG 的问题​

传统 RAG 系统应用于代码时面临根本性局限：

Knox 的优势​

Knox 不仅仅是检索代码——它理解代码：

// Traditional RAG sees this as text:
"function calculateTotal(items: Item[]): number { ... }"

// Knox understands:
{
  entity: "calculateTotal",
  type: "Function",
  parameters: [{ name: "items", type: "Item[]" }],
  returnType: "number",
  calls: ["validateItems", "applyDiscounts", "computeTax"],
  calledBy: ["checkout", "orderSummary"],
  complexity: 12,
  patterns: ["StrategyPattern", "ValidatorPattern"],
  evolution: {
    created: "2025-10-01",
    modifications: 7,
    hotspot: true,
    refactored: ["ExtractMethod", "SimplifyConditionals"]
  },
  relationships: {
    dependsOn: ["Item", "TaxCalculator", "DiscountService"],
    usedBy: ["OrderProcessor", "InvoiceGenerator"]
  }
}

系统架构​

高层概览​

Knox 实现了一个分层智能架构，每一层都建立在前一层之上，创造前所未有的代码理解能力：

核心组件详解​

1. Tree-Sitter 解析引擎（tree_sitter_integration.rs）​

Knox 理解能力的基础：支持多种语言的真正 AST 解析。

支持的语言：

• TypeScript/JavaScript（完整 ES2024 支持）
• Rust（带宏展开）
• Python（2.x 和 3.x）
• Go（带泛型）
• Java（至 Java 21）

能力：

pub struct TreeSitterParser {
    // Extract complete code structure
    functions: Vec<FunctionDefinition>,    // All functions with signatures
    classes: Vec<ClassDefinition>,          // Classes with inheritance
    interfaces: Vec<InterfaceDefinition>,   // Interface contracts
    types: Vec<TypeDefinition>,             // Custom types/aliases
    imports: Vec<ImportStatement>,          // All dependencies
    exports: Vec<ExportStatement>,          // Public API surface
    
    // Build relationships
    call_graph: CallGraph,                  // Function call chains
    dependency_tree: DependencyTree,        // Import dependencies
    inheritance_hierarchy: ClassHierarchy,  // OOP relationships
}

性能：

• TypeScript/JavaScript： ~1,000 LOC/秒
• Rust： ~800 LOC/秒
• Python： ~1,200 LOC/秒
• 增量解析： 更新时快 10-100 倍

关键创新： 与基于正则的解析器不同，Knox 使用语言服务器自身的解析逻辑，确保与语言语义 100% 准确。

核心功能深入​

2. 知识图谱引擎（knowledge_graph.rs）​

Knox 关系理解的核心：一个以前所未有的细节映射代码关系的属性图。

节点类型（8 种）：

pub enum NodeType {
    Function,    // Functions and methods
    Class,       // Classes and structs
    Interface,   // Interfaces and traits
    Type,        // Type aliases and definitions
    Variable,    // Global variables and constants
    Constant,    // Compile-time constants
    Module,      // Modules and namespaces
    File,        // File-level metadata
}

边类型（14 种关系类型）：

pub enum EdgeType {
    // Direct relationships
    Calls,        // Function A calls Function B
    CalledBy,     // Reverse call relationship
    Imports,      // Module A imports Module B
    ImportedBy,   // Reverse import relationship
    
    // OOP relationships
    Extends,      // Class inheritance
    Implements,   // Interface implementation
    
    // Data flow relationships
    Uses,         // Uses a variable/constant
    UsedBy,       // Used by another entity
    Defines,      // Defines a type/constant
    DefinedIn,    // Where defined
    
    // Logical relationships
    References,   // References another entity
    ReferencedBy, // Referenced by others
    DependsOn,    // Logical dependency
    DependencyOf, // Reverse dependency
    
    // Containment
    Contains,     // Module contains class
    ContainedIn,  // Class contained in module
}