feat: 增强记忆体系并补齐 TUI 记忆命令支持

[Yumiue]

变更概述

本 PR 围绕 NeoCode 的记忆能力做了一轮增强，主要包括：

• 引入可配置的记忆提取器策略，支持 rule、llm、auto
• 增加显式项目记忆加载能力，将工作区中的约定文件注入上下文
• 调整聊天链路的上下文拼装顺序，优先注入项目记忆与工作记忆
• 为 TUI 增加记忆查看与恢复相关命令，并补齐帮助面板说明
• 修复 /remember 手动记忆未稳定落库的问题
• 修复 /todo add 对多词内容解析不完整的问题

主要改动

1. 记忆能力增强

• 为记忆模块抽象 MemoryExtractor
• 新增规则式提取器与 LLM 提取器
• 增加提取器工厂与模式选择逻辑
• 支持 memory.extractor、memory.extractor_model、memory.extractor_timeout_seconds 等配置项
• 增加项目记忆服务，用于读取 AGENTS.md、.neocode/memory.md 等显式约定文件

2. 聊天上下文拼装优化

• 聊天服务新增项目记忆注入
• 调整上下文注入优先级：
  1. role prompt
  2. explicit project memory
  3. working memory
  4. todo context
  5. recalled structured memory

3. TUI 命令扩展与修复

新增/补齐以下命令支持：

• /memory
• /memory-list
• /project-memory
• /resume
• /remember <text>
• /memory-mode

同时补充 /help 面板中的命令说明，避免实际可用命令与帮助信息不一致。

4. 交互问题修复

• 修复 /remember 仅依赖提取器推断、导致提示成功但不一定真正保存的问题
• 修复 /todo add 只能读取首个单词作为内容的问题，现已支持多词内容并识别尾部优先级参数

配置变更

新增示例配置项：

• memory.project_files
• memory.project_prompt_chars
• memory.extractor
• memory.extractor_model
• memory.extractor_timeout_seconds

同时统一 provider 命名中的 doubao 表达。

文档更新

• 补充记忆架构说明
• 补充记忆提取策略说明
• 更新 README 与示例配置

测试

已运行：

go test ./internal/server/service ./internal/tui/services ./internal/tui/components ./internal/tui/core

[codecov]

Codecov Report

❌ Patch coverage is 56.80820% with 295 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/tui/services/api_client.go	0.00%	60 Missing ⚠️
internal/server/service/llm_memory_extractor.go	64.76%	22 Missing and 15 partials ⚠️
internal/server/service/memory_service.go	56.09%	29 Missing and 7 partials ⚠️
cmd/server/main.go	0.00%	32 Missing ⚠️
internal/server/service/project_memory_service.go	63.63%	17 Missing and 11 partials ⚠️
internal/tui/core/update.go	60.29%	18 Missing and 9 partials ⚠️
configs/app_config.go	50.94%	25 Missing and 1 partial ⚠️
...rnal/server/service/rule_based_memory_extractor.go	83.33%	15 Missing and 9 partials ⚠️
...nternal/server/service/memory_extractor_factory.go	36.00%	16 Missing ⚠️
internal/server/service/chat_service.go	65.38%	5 Missing and 4 partials ⚠️

📢 Thoughts on this report? Let us know!

[minorcell]

@Yumiue

[minorcell]

抛开方案本身是否正确不谈，这里的 rule、llm、auto 分别是什么意思？各自的输入、输出、触发条件、执行行为和适用场景是什么？文档里都没有写清楚。

如果连核心概念和行为定义都缺失，这份文档就不能算是架构设计文档，最多只是一些未经展开的想法罗列。

[minorcell]

这里我比较怀疑这层设计的必要性。

这些内容，例如当前任务、最近动作、下一步计划、最近对话轮次，本质上都属于会话上下文的一部分，理论上已经可以通过 messages/context 来维护。

在这种前提下，再额外引入一层“工作会话记忆”做持久化，收益是什么？如果没有明确收益，这基本就是在增加额外复杂度和维护负担。

[Yumiue]

这个是长记忆部分内容

[Yumiue]

恢复退出的状态

[minorcell]

恢复退出的状态

我理解“恢复退出状态”这个诉求。

但如果目标只是恢复上次工作现场，是否有考虑过 session / resume 机制，而不是单独再抽一层 memory。像 Claude / Codex 的做法，本质上也是先把 resume 做好。

所以这里的关键问题是：
这部分为什么必须是 memory？它和 session 的职责边界是什么？

如果边界讲不清楚，就很容易变成重复设计，既增加复杂度，也增加维护负担。

[minorcell]

此外，先不讨论方案本身，这里的“记住改过什么文件”我也比较怀疑其必要性。

首先，这类记录天然会非常多，实际使用下来很容易迅速膨胀成噪音，而不是有效记忆。

其次，这部分本质上和 Git 的职责是重复的。文件变更记录本来就应该以 Git 作为事实来源，需要查看时完全可以通过命令或工具链获取。

这类能力本身已经有现成模块可以承载了，没有必要再额外做一套新的。
如果只是重复已有能力，而且效果不一定比现有方案更好，那这部分设计的收益是很不好评估的。

[minorcell]

你们这里有很多能力都在暴露给用户做配置。问题是，配置项一多，用户面对的就不再是“灵活性”，而是实实在在的心智负担。

像这里的 extractor、extractor_model、extractor_timeout_seconds，都需要用户理解其含义、差异和影响范围，这本身就说明方案还不够收敛。

建议尽量减少不必要的配置暴露，把能够在系统内部收敛掉的复杂度收敛掉，而不是转嫁给用户。