知识库这里，希望支持文档的分类，添加，删除，批量导入文档

[xusongyu1994]

⚠️ 搜索是否存在类似issue

• 我已经搜索过issues和disscussions，没有发现相似issue

总结

知识库这里，目前只能依靠对话进行文档的分类，删除，实在是很麻烦，希望支持文档的分类，添加，删除，批量导入文档

举例

No response

动机

No response

[xusongyu1994]

还有希望知识库里的文档，支持导出功能

[zhayujie]

谢谢建议，我们规划一下

[yangziyu-hhh]

谢谢建议，我们规划一下

我希望参与知识库文档管理功能的开发。目前知识库主要依赖对话完成文档分类和删除，管理大量文档时不够方便。

我计划分阶段实现：第一阶段增加分类创建、重命名、删除，以及文档新增、编辑、移动和批量删除；第二阶段支持 MD、TXT、ZIP 批量导入，并提供目标分类选择、重名处理、导入进度和错误提示。

实现将继续以 ~/cow/knowledge/ 文件目录作为数据来源，并重点处理路径穿越、ZIP 解压安全、文件大小限制和索引同步问题。为控制 PR 范围，我准备先提交基础文档管理功能。请问这个方向是否符合项目规划？如果没有正在进行的相关工作，我可以开始设计和开发。

[zhayujie]

谢谢建议，我们规划一下

我希望参与知识库文档管理功能的开发。目前知识库主要依赖对话完成文档分类和删除，管理大量文档时不够方便。

我计划分阶段实现：第一阶段增加分类创建、重命名、删除，以及文档新增、编辑、移动和批量删除；第二阶段支持 MD、TXT、ZIP 批量导入，并提供目标分类选择、重名处理、导入进度和错误提示。

实现将继续以 ~/cow/knowledge/ 文件目录作为数据来源，并重点处理路径穿越、ZIP 解压安全、文件大小限制和索引同步问题。为控制 PR 范围，我准备先提交基础文档管理功能。请问这个方向是否符合项目规划？如果没有正在进行的相关工作，我可以开始设计和开发。

非常欢迎设计贡献这个重要的模块，文档管理是我们规划中的重要功能，你的方案方向和分阶段策略都符合项目预期，可以开始设计和开发。目前没有正在进行的相关工作。

有几个点可以在设计的时候考虑一下：

1. 索引同步

• 知识库与 memory 共用向量索引（~/cow/memory/long-term/index.db），由 MemoryManager.sync() 按文件 hash 增量更新。但目前只有路径含 memory/ 的写入会触发 mark_dirty()，knowledge/ 的变更不会。通过 API 直接操作文件后，需要显式触发 mark_dirty() 或 sync，否则向量检索会与文件内容不一致。
• 删除/移动文件后目前没有孤儿 chunk 的清理逻辑，做删除和移动功能时需要同步处理（参考 delete_by_path()）。

2. 写操作收敛到 KnowledgeService

读侧已有 KnowledgeService（list_tree / read_file / build_graph），并通过 dispatch() 同时服务 Web API 和云端回调。建议新增的写操作（增删改移）也作为 action 加到 KnowledgeService.dispatch() 里，而不是只在 web_channel.py 中实现 handler，这样其他通道可以复用。

3. index.md / log.md 的一致性

knowledge/index.md 是 Agent 按 knowledge-wiki 技能维护的分类索引。通过 UI 增删/移动文档后 index.md 会失效，设计时需要明确策略（API 同步更新，或将其降级为可选缓存）。另外这两个元文件应在 UI 中保护，不允许被当作普通文档删除。

4. 分类即子目录

分类没有独立的数据结构，本质是目录操作。注意：目录名合法性校验、重命名分类会导致所有子文档索引路径变化（相当于批量 delete + re-embed）、删除非空分类需要确认策略。

5. 上传与批量导入

可复用 web_channel.py 中现有的 UploadHandler / upload_file() 和路径清洗函数（_sanitize_upload_relative_path() 等）。但现有上传没有文件大小限制，批量导入时建议补上：单文件上限、ZIP 解压后总大小上限、文件数上限。另外注意 ZIP 内中文文件名的编码问题（GBK/UTF-8）。

6. 与 Agent 写入的并发

对话过程中 Agent 可能正在通过 write/edit 工具写 knowledge 文件，UI 操作与之可能并发。不需要复杂的锁，但要做好文件不存在等情况的容错，且不要在 API 层缓存目录树。

关于 PR 拆分：第一个 PR 建议更小一些，可以只包含分类管理 + 文档删除/移动（纯文件操作 + 索引同步），把核心的索引同步问题先解决并充分 review；文档新增/编辑（涉及编辑器 UI）放第二个，批量导入放第三个。

期待你的设计方案，有问题随时在这里讨论。

[yangziyu-hhh]

谢谢建议，我们规划一下

我希望参与知识库文档管理功能的开发。目前知识库主要依赖对话完成文档分类和删除，管理大量文档时不够方便。
我分阶段实现：第一阶段增加分类创建、重命名、删除，以及文档新增、编辑、移动和批量删除；第二阶段支持MD、TXT、ZIP批量导入，并提供目标分类选择、重命名处理、导入进度计划和错误提示。
实现将继续以~/cow/knowledge/文件目录作为数据源，并重点处理路径传输、ZIP解压安全、文件大小限制和索引同步问题。为控制PR范围，我准备先提交基础文档管理功能。请问这个方向是否符合项目规划？如果没有发起的相关工作，我可以开始设计和开发。

非常欢迎设计贡献这个重要的模块，文档管理是我们规划中的重要功能，你的方案方向和分阶段策略都符合项目预期，可以开始设计和开发。目前还没有开展的相关工作。

有几点可以在设计的时候考虑一​​下：

1. 索引同步

• 知识库与内存占用支持索引（~/cow/memory/long-term/index.db），由MemoryManager.sync()按文件哈希增量更新。但目前只有路径含memory/的写入会触发mark_dirty()，knowledge/的变更不会。通过API直接操作文件后，需要显式触发mark_dirty()或同步，否则支持搜索会与文件内容不一致。
• 删除/移动文件后目前没有孤儿块的清理逻辑，做删除和移动功能时需要同步处理（参考delete_by_path()）。

2. 写操作收敛到KnowledgeService

侧读KnowledgeService（list_tree/ read_file/ build_graph），并通过dispatch()同时服务 Web API 和云端回调。建议增加的写操作（增删改移）也作为操作加到KnowledgeService.dispatch()里，而不是只在web_channel.py实现处理程序中，这样其他通道可以复用。

3. index.md/log.md的一致性

knowledge/index.md是Agent按知识wiki技能维护的分类索引。通过UI增减/移动文档后index.md会失效，设计时需要明确的策略（API同步更新，或将其降级为可选服务器）。另外这两个元文件应在UI中保护，不允许被像普通文档删除一样。

4.分类即子目录

分类没有独立的数据结构，本质是操作目录。注意：目录名合法性校验、重命名分类会导致所有子文档索引路径变化（实际上批量删除+重新嵌入）、删除非空分类需要确认策略。

5. 上传与批量导入

可复用web_channel.py中现有的UploadHandler/upload_file()和路径清理函数（_sanitize_upload_relative_path()等）。但现有上传没有文件大小限制，批量导入时建议补上：单文件上限、ZIP解压后总大小上限、文件数上限。另外注意ZIP内中文文件名的编码问题（GBK/UTF-8）。

6. 与 Agent 读取的负载

对话过程中 Agent 可能正在通过 write/edit 工具编写知识文件，UI 操作可能会发生。不需要复杂的锁，但要整理文件不存在等情况的内容错，且不要在 API 层存储目录树。

关于PR拆分：第一个PR建议更小一些，可以只包含分类管理+文档删除/移动（纯文件操作+索引同步），把核心的索引同步问题先解决并充分复习；文档新增/编辑（涉及编辑器UI）放第二个，批量导入放第三个。

期待你的设计方案，有问题随时在这里讨论。

感谢详细建议，这些点对控制首个 PR 的范围和保证索引一致性很有帮助。我计划按以下方案推进：

第一个 PR 仅实现分类管理和文档删除/移动。分类继续使用 knowledge/ 下的子目录，不引入独立数据结构。所有写操作将作为 action 收敛到 KnowledgeService.dispatch()，供 Web API、云端回调和其他通道复用。

文件删除、移动及分类重命名时，会先通过 delete_by_path() 清理旧路径索引，再调用 mark_dirty() 和 MemoryManager.sync() 更新新路径，避免孤儿 chunk 和检索内容不一致。knowledge/index.md 与 knowledge/log.md 将作为受保护元文件，暂不允许通过 UI 删除或移动；UI 分类树以真实目录结构为准。

实现中还会加入目录名和路径安全校验、非空分类删除确认、目标路径冲突检查，以及文件被 Agent 并发修改或删除时的容错，不在 API 层缓存目录树。

后续将拆分为两个独立 PR：第二个实现文档新增与编辑，第三个复用现有上传能力实现批量导入及文件数量、大小、ZIP 安全和中文文件名处理。

我会先整理第一个 PR 的 action 接口和索引同步流程，再开始实现。请问这个设计和拆分方式是否符合预期？

[zhayujie]

谢谢建议，我们规划一下

我希望参与知识库文档管理功能的开发。目前知识库主要依赖对话完成文档分类和删除，管理大量文档时不够方便。
我分阶段实现：第一阶段增加分类创建、重命名、删除，以及文档新增、编辑、移动和批量删除；第二阶段支持MD、TXT、ZIP批量导入，并提供目标分类选择、重命名处理、导入进度计划和错误提示。
实现将继续以~/cow/knowledge/文件目录作为数据源，并重点处理路径传输、ZIP解压安全、文件大小限制和索引同步问题。为控制PR范围，我准备先提交基础文档管理功能。请问这个方向是否符合项目规划？如果没有发起的相关工作，我可以开始设计和开发。

非常欢迎设计贡献这个重要的模块，文档管理是我们规划中的重要功能，你的方案方向和分阶段策略都符合项目预期，可以开始设计和开发。目前还没有开展的相关工作。
有几点可以在设计的时候考虑一​​下：
1. 索引同步

• 知识库与内存占用支持索引（~/cow/memory/long-term/index.db），由MemoryManager.sync()按文件哈希增量更新。但目前只有路径含memory/的写入会触发mark_dirty()，knowledge/的变更不会。通过API直接操作文件后，需要显式触发mark_dirty()或同步，否则支持搜索会与文件内容不一致。
• 删除/移动文件后目前没有孤儿块的清理逻辑，做删除和移动功能时需要同步处理（参考delete_by_path()）。

2. 写操作收敛到KnowledgeService
侧读KnowledgeService（list_tree/ read_file/ build_graph），并通过dispatch()同时服务 Web API 和云端回调。建议增加的写操作（增删改移）也作为操作加到KnowledgeService.dispatch()里，而不是只在web_channel.py实现处理程序中，这样其他通道可以复用。
3. index.md/log.md的一致性
knowledge/index.md是Agent按知识wiki技能维护的分类索引。通过UI增减/移动文档后index.md会失效，设计时需要明确的策略（API同步更新，或将其降级为可选服务器）。另外这两个元文件应在UI中保护，不允许被像普通文档删除一样。
4.分类即子目录
分类没有独立的数据结构，本质是操作目录。注意：目录名合法性校验、重命名分类会导致所有子文档索引路径变化（实际上批量删除+重新嵌入）、删除非空分类需要确认策略。
5. 上传与批量导入
可复用web_channel.py中现有的UploadHandler/upload_file()和路径清理函数（_sanitize_upload_relative_path()等）。但现有上传没有文件大小限制，批量导入时建议补上：单文件上限、ZIP解压后总大小上限、文件数上限。另外注意ZIP内中文文件名的编码问题（GBK/UTF-8）。
6. 与 Agent 读取的负载
对话过程中 Agent 可能正在通过 write/edit 工具编写知识文件，UI 操作可能会发生。不需要复杂的锁，但要整理文件不存在等情况的内容错，且不要在 API 层存储目录树。
关于PR拆分：第一个PR建议更小一些，可以只包含分类管理+文档删除/移动（纯文件操作+索引同步），把核心的索引同步问题先解决并充分复习；文档新增/编辑（涉及编辑器UI）放第二个，批量导入放第三个。
期待你的设计方案，有问题随时在这里讨论。

感谢详细建议，这些点对控制首个 PR 的范围和保证索引一致性很有帮助。我计划按以下方案推进：

第一个 PR 仅实现分类管理和文档删除/移动。分类继续使用 knowledge/ 下的子目录，不引入独立数据结构。所有写操作将作为 action 收敛到 KnowledgeService.dispatch()，供 Web API、云端回调和其他通道复用。

文件删除、移动及分类重命名时，会先通过 delete_by_path() 清理旧路径索引，再调用 mark_dirty() 和 MemoryManager.sync() 更新新路径，避免孤儿 chunk 和检索内容不一致。knowledge/index.md 与 knowledge/log.md 将作为受保护元文件，暂不允许通过 UI 删除或移动；UI 分类树以真实目录结构为准。

实现中还会加入目录名和路径安全校验、非空分类删除确认、目标路径冲突检查，以及文件被 Agent 并发修改或删除时的容错，不在 API 层缓存目录树。

后续将拆分为两个独立 PR：第二个实现文档新增与编辑，第三个复用现有上传能力实现批量导入及文件数量、大小、ZIP 安全和中文文件名处理。

我会先整理第一个 PR 的 action 接口和索引同步流程，再开始实现。请问这个设计和拆分方式是否符合预期？

没问题，期待你的实现，保持沟通

[yangziyu-hhh]

谢谢建议，我们规划一下

我希望参与知识库文档管理功能的开发。目前知识库主要依赖对话完成文档分类和删除，管理大量文档时不够方便。
我分阶段实现：第一阶段增加分类创建、重命名、删除，以及文档新增、编辑、移动和批量删除；第二阶段支持MD、TXT、ZIP批量导入，并提供目标分类选择、重命名处理、导入进度计划和错误提示。
实现将继续以~/cow/knowledge/文件目录作为数据源，并重点处理路径传输、ZIP解压安全、文件大小限制和索引同步问题。为控制PR范围，我准备先提交基础文档管理功能。请问这个方向是否符合项目规划？如果没有发起的相关工作，我可以开始设计和开发。

非常欢迎设计贡献这个重要的模块，文档管理是我们规划中的重要功能，你的方案方向和分阶段策略都符合项目预期，可以开始设计和开发。目前还没有开展的相关工作。
有几点可以在设计的时候考虑一​​下：
1. 索引同步

• 知识库与内存占用支持索引（~/cow/memory/long-term/index.db），由MemoryManager.sync()按文件哈希增量更新。但目前只有路径含memory/的写入会触发mark_dirty()，knowledge/的变更不会。通过API直接操作文件后，需要显式触发mark_dirty()或同步，否则支持搜索会与文件内容不一致。
• 删除/移动文件后目前没有孤儿块的清理逻辑，做删除和移动功能时需要同步处理（参考delete_by_path()）。

2. 写操作收敛到KnowledgeService
侧读KnowledgeService（list_tree/ read_file/ build_graph），并通过dispatch()同时服务 Web API 和云端回调。建议增加的写操作（增删改移）也作为操作加到KnowledgeService.dispatch()里，而不是只在web_channel.py实现处理程序中，这样其他通道可以复用。
3. index.md/log.md的一致性
knowledge/index.md是Agent按知识wiki技能维护的分类索引。通过UI增减/移动文档后index.md会失效，设计时需要明确的策略（API同步更新，或将其降级为可选服务器）。另外这两个元文件应在UI中保护，不允许被像普通文档删除一样。
4.分类即子目录
分类没有独立的数据结构，本质是操作目录。注意：目录名合法性校验、重命名分类会导致所有子文档索引路径变化（实际上批量删除+重新嵌入）、删除非空分类需要确认策略。
5. 上传与批量导入
可复用web_channel.py中现有的UploadHandler/upload_file()和路径清理函数（_sanitize_upload_relative_path()等）。但现有上传没有文件大小限制，批量导入时建议补上：单文件上限、ZIP解压后总大小上限、文件数上限。另外注意ZIP内中文文件名的编码问题（GBK/UTF-8）。
6. 与 Agent 读取的负载
对话过程中 Agent 可能正在通过 write/edit 工具编写知识文件，UI 操作可能会发生。不需要复杂的锁，但要整理文件不存在等情况的内容错，且不要在 API 层存储目录树。
关于PR拆分：第一个PR建议更小一些，可以只包含分类管理+文档删除/移动（纯文件操作+索引同步），把核心的索引同步问题先解决并充分复习；文档新增/编辑（涉及编辑器UI）放第二个，批量导入放第三个。
期待你的设计方案，有问题随时在这里讨论。

感谢详细建议，这些点对控制首个 PR 的范围和保证索引一致性很有帮助。我计划按以下方案推进：
第一个 PR 仅实现分类管理和文档删除/移动。分类继续使用 knowledge/ 下的子目录，不引入独立数据结构。所有写操作将作为 action 收敛到 KnowledgeService.dispatch()，供 Web API、云端回调和其他通道复用。
文件删除、移动及分类重命名时，会先通过 delete_by_path() 清理旧路径索引，再调用 mark_dirty() 和 MemoryManager.sync() 更新新路径，避免孤儿 chunk 和检索内容不一致。knowledge/index.md 与 knowledge/log.md 将作为受保护元文件，暂不允许通过 UI 删除或移动；UI 分类树以真实目录结构为准。
实现中还会加入目录名和路径安全校验、非空分类删除确认、目标路径冲突检查，以及文件被 Agent 并发修改或删除时的容错，不在 API 层缓存目录树。
后续将拆分为两个独立 PR：第二个实现文档新增与编辑，第三个复用现有上传能力实现批量导入及文件数量、大小、ZIP 安全和中文文件名处理。
我会先整理第一个 PR 的 action 接口和索引同步流程，再开始实现。请问这个设计和拆分方式是否符合预期？

没问题，期待你的实现，保持沟通

非常感谢认可
下午的PR 主要把知识库从只能查看，升级成了可以进行基础管理。

现在支持新建、重命名和删除分类，也可以删除或移动文档。分类仍然就是 knowledge/ 下面的真实文件夹，没有引入额外的数据结构。Web 页面、云端回调和其他调用方的写操作，都会统一走 KnowledgeService.dispatch()。

文件删除、移动或者分类重命名后，会立即清理旧路径的搜索索引，再重新同步知识库，避免搜到已经不存在的内容。操作过程中如果文件刚好被 Agent 修改或删除，也会返回明确结果，不会直接报错；移动时如果目标文件已经存在，也不会覆盖。

安全方面补了路径穿越、非法目录名和符号链接逃逸检查。knowledge/index.md 和 knowledge/log.md 仍然可以查看，但不能通过 UI 或接口删除、移动，也不会自动修改它们的内容。

前端操作也顺便优化了：新增了统一弹窗、分类选择、删除确认、操作状态和错误提示。每次操作完成后都会重新读取真实目录树，确保页面和文件系统保持一致。

[GHbingbing]

期待这个功能早日上线

[xusongyu1994]

谢谢建议，我们规划一下

我希望参与知识库文档管理功能的开发。目前知识库主要依赖对话完成文档分类和删除，管理大量文档时不够方便。
我分阶段实现：第一阶段增加分类创建、重命名、删除，以及文档新增、编辑、移动和批量删除；第二阶段支持MD、TXT、ZIP批量导入，并提供目标分类选择、重命名处理、导入进度计划和错误提示。
实现将继续以~/cow/knowledge/文件目录作为数据源，并重点处理路径传输、ZIP解压安全、文件大小限制和索引同步问题。为控制PR范围，我准备先提交基础文档管理功能。请问这个方向是否符合项目规划？如果没有发起的相关工作，我可以开始设计和开发。

非常欢迎设计贡献这个重要的模块，文档管理是我们规划中的重要功能，你的方案方向和分阶段策略都符合项目预期，可以开始设计和开发。目前还没有开展的相关工作。
有几点可以在设计的时候考虑一​​下：
1. 索引同步

• 知识库与内存占用支持索引（~/cow/memory/long-term/index.db），由MemoryManager.sync()按文件哈希增量更新。但目前只有路径含memory/的写入会触发mark_dirty()，knowledge/的变更不会。通过API直接操作文件后，需要显式触发mark_dirty()或同步，否则支持搜索会与文件内容不一致。
• 删除/移动文件后目前没有孤儿块的清理逻辑，做删除和移动功能时需要同步处理（参考delete_by_path()）。

2. 写操作收敛到KnowledgeService
侧读KnowledgeService（list_tree/ read_file/ build_graph），并通过dispatch()同时服务 Web API 和云端回调。建议增加的写操作（增删改移）也作为操作加到KnowledgeService.dispatch()里，而不是只在web_channel.py实现处理程序中，这样其他通道可以复用。
3. index.md/log.md的一致性
knowledge/index.md是Agent按知识wiki技能维护的分类索引。通过UI增减/移动文档后index.md会失效，设计时需要明确的策略（API同步更新，或将其降级为可选服务器）。另外这两个元文件应在UI中保护，不允许被像普通文档删除一样。
4.分类即子目录
分类没有独立的数据结构，本质是操作目录。注意：目录名合法性校验、重命名分类会导致所有子文档索引路径变化（实际上批量删除+重新嵌入）、删除非空分类需要确认策略。
5. 上传与批量导入
可复用web_channel.py中现有的UploadHandler/upload_file()和路径清理函数（_sanitize_upload_relative_path()等）。但现有上传没有文件大小限制，批量导入时建议补上：单文件上限、ZIP解压后总大小上限、文件数上限。另外注意ZIP内中文文件名的编码问题（GBK/UTF-8）。
6. 与 Agent 读取的负载
对话过程中 Agent 可能正在通过 write/edit 工具编写知识文件，UI 操作可能会发生。不需要复杂的锁，但要整理文件不存在等情况的内容错，且不要在 API 层存储目录树。
关于PR拆分：第一个PR建议更小一些，可以只包含分类管理+文档删除/移动（纯文件操作+索引同步），把核心的索引同步问题先解决并充分复习；文档新增/编辑（涉及编辑器UI）放第二个，批量导入放第三个。
期待你的设计方案，有问题随时在这里讨论。

感谢详细建议，这些点对控制首个 PR 的范围和保证索引一致性很有帮助。我计划按以下方案推进：
第一个 PR 仅实现分类管理和文档删除/移动。分类继续使用 knowledge/ 下的子目录，不引入独立数据结构。所有写操作将作为 action 收敛到 KnowledgeService.dispatch()，供 Web API、云端回调和其他通道复用。
文件删除、移动及分类重命名时，会先通过 delete_by_path() 清理旧路径索引，再调用 mark_dirty() 和 MemoryManager.sync() 更新新路径，避免孤儿 chunk 和检索内容不一致。knowledge/index.md 与 knowledge/log.md 将作为受保护元文件，暂不允许通过 UI 删除或移动；UI 分类树以真实目录结构为准。
实现中还会加入目录名和路径安全校验、非空分类删除确认、目标路径冲突检查，以及文件被 Agent 并发修改或删除时的容错，不在 API 层缓存目录树。
后续将拆分为两个独立 PR：第二个实现文档新增与编辑，第三个复用现有上传能力实现批量导入及文件数量、大小、ZIP 安全和中文文件名处理。
我会先整理第一个 PR 的 action 接口和索引同步流程，再开始实现。请问这个设计和拆分方式是否符合预期？

没问题，期待你的实现，保持沟通

非常感谢认可 下午的PR 主要把知识库从只能查看，升级成了可以进行基础管理。

现在支持新建、重命名和删除分类，也可以删除或移动文档。分类仍然就是 knowledge/ 下面的真实文件夹，没有引入额外的数据结构。Web 页面、云端回调和其他调用方的写操作，都会统一走 KnowledgeService.dispatch()。

文件删除、移动或者分类重命名后，会立即清理旧路径的搜索索引，再重新同步知识库，避免搜到已经不存在的内容。操作过程中如果文件刚好被 Agent 修改或删除，也会返回明确结果，不会直接报错；移动时如果目标文件已经存在，也不会覆盖。

安全方面补了路径穿越、非法目录名和符号链接逃逸检查。knowledge/index.md 和 knowledge/log.md 仍然可以查看，但不能通过 UI 或接口删除、移动，也不会自动修改它们的内容。

前端操作也顺便优化了：新增了统一弹窗、分类选择、删除确认、操作状态和错误提示。每次操作完成后都会重新读取真实目录树，确保页面和文件系统保持一致。

谢谢建议，我们规划一下

我希望参与知识库文档管理功能的开发。目前知识库主要依赖对话完成文档分类和删除，管理大量文档时不够方便。

我计划分阶段实现：第一阶段增加分类创建、重命名、删除，以及文档新增、编辑、移动和批量删除；第二阶段支持 MD、TXT、ZIP 批量导入，并提供目标分类选择、重名处理、导入进度和错误提示。

实现将继续以 ~/cow/knowledge/ 文件目录作为数据来源，并重点处理路径穿越、ZIP 解压安全、文件大小限制和索引同步问题。为控制 PR 范围，我准备先提交基础文档管理功能。请问这个方向是否符合项目规划？如果没有正在进行的相关工作，我可以开始设计和开发。

我当时提出这个issues的时候，就尝试过自己动手完善知识库，奈何水平不行改不动，这位大兄弟加油，期待你这个新功能的早日上线

[zhayujie]

现在支持新建、重命名和删除分类，也可以删除或移动文档。分类仍然就是 knowledge/ 下面的真实文件夹，没有引入额外的数据结构。Web 页面、云端回调和其他调用方的写操作，都会统一走 KnowledgeService.dispatch()。

第一个PR已合并，感谢 @yangziyu-hhh 贡献~

[shuaiger]

补充一个问题，知识库里的链接（cross link），点不了~