2.6 KiB
2.6 KiB
兼容性报告
无法兼容历史的数据库、知识库、配置项，只能重新创建项目
功能性报告
- 将 LightRAG 从调用 package 修改为手动实现，不依赖原本仓库，更好管理。
- 移除 legacy 参数，简化代码逻辑，减少维护成本。
- 权限结构重构
待办事项
- 移除所有对于 v1 的模型的代码的支持、移除所有对于 legacy 参数的支持
- 移除 lightrag
- 新增图谱构建，支持自定义 Schema、支持自定义并发数，知识库与向量检索解耦
- 知识图谱抽取要求支持并发处理
权限部分
- Agent 的 user_id 使用的有歧义，从数据库表到代码中都修改为统一使用 yuxi_id 来代替
- 权限新增一个 guest 的预设字段，暂无任何权限
- rename database table name, such as skills -> agent_skills, subagents -> agent_subagents, mcp, tool_call, 等等
- department 的 id 也不能使用那个索引的 id 来使用了，应该是一个独立的 dept_id，需要确认
- allow user config envs
- add model retry times to agent context config
- 添加用户级别的 Skills 的安装
- 子智能体的优化，参考 PR 的方案。
- 附件上传能够支持转换为 PDF
- 参考 PR，实现内置 Dashscope 的 Embedding 和 rerank 的方法
- 优化知识库的 API 接口设计，使用 /{db_id}/xxx 的形式，整合 mindmap / eval 接口
- allow multi-hop qa generate
- 在工作区的文件编辑的时候，保存和取消的按钮应该是悬浮在编辑框的右上角，而不是在 header 上面
- default enable all build in tools / kbs / skills / mcps / subagents
- 链接 Notion 和 feishu 目前来看，都是支持的
- 知识库的权限调整，修改为三个等级，全局共享、部门共享、指定人可访问- [x] 当前的评估基准是最重要的是评估数据集和评估结果都是放在一个文件里面的，这个是绝对不可以的，应该是放在数据库里面，比如评估数据集是一个表，每一个评估的题目是一个表，评估的结果是一个表，每一个评估的 item 也是一个表，但是数据表太多要注意命名规范。现在第一步就是完成原本的评估的功能的重新梳理
- 考虑如何将知识库更好的挂载到沙盒，是不是可以使用一个别的后端，但是使用别的后端是否还能读取到数据？应该不能
- 智能体体系改进。改进子智能体
- RAG 中的文件的 metadata 包含那些内容？然后 Find 和 Read 的时候要支持展示