diff --git a/DEVELOPMENT.md b/DEVELOPMENT.md deleted file mode 100644 index a3b14fe6a..000000000 --- a/DEVELOPMENT.md +++ /dev/null @@ -1,267 +0,0 @@ -# WeKnora 开发环境快速入门 - -> 无需重新构建 Docker 镜像,实现秒级代码热更新! - -## 🚀 快速开始(3 种方式) - -### 方式 1:推荐 - 使用 Make 命令 - -**终端 1** - 启动基础设施: -```bash -make dev-start -``` - -**终端 2** - 启动后端: -```bash -make dev-app -``` - -**终端 3** - 启动前端: -```bash -make dev-frontend -``` - -访问 http://localhost:5173 开始开发! - -### 方式 2:使用脚本命令 - -```bash -# 终端 1 -./scripts/dev.sh start - -# 终端 2 -./scripts/dev.sh app - -# 终端 3 -./scripts/dev.sh frontend -``` - -### 方式 3:一键启动(交互式) - -```bash -./scripts/quick-dev.sh -``` - -按照提示选择是否启动后端和前端。 - -## 📋 常用命令 - -| 命令 | 说明 | -|------|------| -| `make dev-start` | 启动基础设施(postgres, redis, minio 等) | -| `make dev-stop` | 停止所有服务 | -| `make dev-restart` | 重启所有服务 | -| `make dev-status` | 查看服务状态 | -| `make dev-logs` | 查看服务日志 | -| `make dev-app` | 启动后端(需先启动基础设施) | -| `make dev-frontend` | 启动前端(需先启动基础设施) | - -## 🎯 访问地址 - -| 服务 | 地址 | -|------|------| -| 前端开发服务器 | http://localhost:5173 | -| 后端 API | http://localhost:8080 | -| PostgreSQL | localhost:5432 | -| Redis | localhost:6379 | -| MinIO Console | http://localhost:9001 | -| Neo4j Browser | http://localhost:7474 | -| Jaeger UI | http://localhost:16686 | - -## 💡 开发工作流对比 - -### ❌ 旧方式(慢) - -```bash -# 每次修改代码后 -sh scripts/build_images.sh -p # 重新构建镜像(2-5分钟) -sh scripts/start_all.sh --no-pull # 重启容器 -``` - -### ✅ 新方式(快) - -```bash -# 首次启动(只需一次) -make dev-start - -# 修改后端代码 -# → Ctrl+C 停止 → make dev-app 重启(5-10秒) - -# 修改前端代码 -# → 自动热重载(无需任何操作) -``` - -**时间对比**: -- 旧方式:每次修改 2-5 分钟 -- 新方式首次:1-2 分钟 -- 新方式后续: - - 后端修改:5-10 秒 - - 前端修改:实时热重载 - -## 🔥 进阶:后端热重载 - -安装 Air 实现后端代码修改后自动重启: - -```bash -# 安装 Air -go install github.com/cosmtrek/air@latest - -# 确保 $GOPATH/bin 在 PATH 中 -export PATH=$PATH:$(go env GOPATH)/bin - -# 使用 Air 启动(自动检测) -make dev-app -# 或直接运行 -air -``` - -修改 Go 代码后,Air 会自动重新编译和重启,无需手动操作! - -## 📝 开发场景示例 - -### 场景 1:只修改前端 - -```bash -# 一次性启动基础设施 -make dev-start - -# 启动前端,修改代码自动热重载 -make dev-frontend -``` - -### 场景 2:只修改后端 - -```bash -# 启动基础设施 -make dev-start - -# 启动后端(如果安装了 Air,支持热重载) -make dev-app -``` - -### 场景 3:同时开发前后端 - -```bash -# 终端 1:启动基础设施 -make dev-start - -# 终端 2:启动后端 -make dev-app - -# 终端 3:启动前端 -make dev-frontend -``` - -## 🛠 VS Code 调试配置 - -创建 `.vscode/launch.json`: - -```json -{ - "version": "0.2.0", - "configurations": [ - { - "name": "Launch WeKnora Server", - "type": "go", - "request": "launch", - "mode": "auto", - "program": "${workspaceFolder}/cmd/server", - "env": { - "DB_HOST": "localhost", - "DB_PORT": "5432", - "DOCREADER_ADDR": "localhost:50051", - "MINIO_ENDPOINT": "localhost:9000", - "REDIS_ADDR": "localhost:6379", - "OTEL_EXPORTER_OTLP_ENDPOINT": "localhost:4317", - "NEO4J_URI": "bolt://localhost:7687" - } - } - ] -} -``` - -然后按 F5 开始调试! - -## 🐛 故障排除 - -### 问题:启动后端时报错连接不到数据库 - -**解决**:确保先运行了 `make dev-start` 并等待 30 秒让服务完全启动。 - -查看服务状态: -```bash -make dev-status -``` - -### 问题:前端访问 API 时报 CORS 错误 - -**解决**:前端已配置代理,确保: -1. 后端运行在 `localhost:8080` -2. 前端运行在 `localhost:5173` -3. 查看 `frontend/vite.config.ts` 的代理配置 - -### 问题:端口被占用 - -**解决**:修改 `.env` 文件中的端口配置: - -```bash -# .env -DB_PORT=5433 # 默认 5432 -REDIS_PORT=6380 # 默认 6379 -MINIO_PORT=9001 # 默认 9000 -``` - -然后重启服务: -```bash -make dev-restart -``` - -### 问题:DocReader 需要重新构建 - -**解决**:DocReader 仍使用 Docker 镜像,需要重新构建: - -```bash -sh scripts/build_images.sh -d -make dev-restart -``` - -## 🎯 生产环境部署 - -开发完成后需要部署时: - -```bash -# 构建所有镜像 -sh scripts/build_images.sh - -# 或只构建特定镜像 -sh scripts/build_images.sh -p # 后端 -sh scripts/build_images.sh -f # 前端 -sh scripts/build_images.sh -d # DocReader - -# 启动生产环境 -sh scripts/start_all.sh -``` - -## 📚 更多文档 - -- [完整开发指南](docs/开发指南.md) -- [API 文档](docs/API.md) -- [Agent 开发](docs/AGENT.md) - -## 💪 最佳实践 - -1. **日常开发**:使用 `make dev-*` 命令,享受快速迭代 -2. **提交前测试**:使用完整 Docker 环境测试集成功能 -3. **生产部署**:使用构建镜像的方式部署 - -## 🎉 总结 - -使用开发模式,你可以: - -✅ **不重新构建镜像** - 直接在本地运行代码 -✅ **秒级热更新** - 前端自动热重载,后端快速重启 -✅ **完整调试支持** - IDE 断点调试,实时查看变量 -✅ **节省时间** - 每次修改从 2-5 分钟降至 5-10 秒 - -祝你开发愉快!🚀 - diff --git a/docs/AGENT.md b/docs/AGENT.md deleted file mode 100644 index 8ec12f9b3..000000000 --- a/docs/AGENT.md +++ /dev/null @@ -1,527 +0,0 @@ -# WeKnora Agent Mode 文档 - -## 概述 - -WeKnora Agent Mode 是基于 ReAct (Reasoning + Acting) 框架实现的智能代理系统,能够通过工具调用和迭代推理来回答复杂问题。 - -### 核心特性 - -- **ReAct 框架**: Thought → Action → Observation 循环 -- **工具系统**: 7个知识库相关工具 -- **可选规划**: 可在执行前生成任务计划 -- **事件追踪**: 完整的执行过程可视化 -- **灵活配置**: 支持多种参数调整 - -## 架构设计 - -### Agent 工作流程 - -``` -用户查询 - ↓ -[可选] 生成执行计划 - ↓ -┌─────────────────┐ -│ ReAct 循环开始 │ -├─────────────────┤ -│ 1. Think (思考) │ → LLM 分析当前状态 -│ 2. Act (行动) │ → 调用工具获取信息 -│ 3. Observe (观察)│ → 处理工具返回结果 -│ [可选] Reflect │ → 反思当前步骤 -│ 4. Decide (决策)│ → 继续或结束? -└─────────────────┘ - ↓ -生成最终答案 -``` - -### 组件结构 - -``` -internal/agent/ -├── engine.go # Agent 执行引擎 -├── prompts.go # System prompts -└── tools/ # 工具系统 - ├── tool.go - ├── registry.go - ├── knowledge_search.go - ├── multi_kb_search.go - ├── list_knowledge_bases.go - ├── get_chunk_detail.go - ├── get_related_chunks.go - ├── query_knowledge_graph.go - └── get_document_info.go -``` - -## 配置说明 - -### Agent 配置结构 - -```go -type AgentConfig struct { - Enabled bool // 是否启用 Agent 模式 - EnablePlanning bool // 是否先规划 - MaxIterations int // 最大迭代次数 (1-20) - ReflectionEnabled bool // 是否启用反思 - AllowedTools []string // 允许的工具列表 - Temperature float64 // LLM 温度 (0-2) - ThinkingModelID string // 推理模型 ID - KnowledgeBases []string // 可访问的知识库 ID -} -``` - -### 全局配置 (config.yaml) - -```yaml -agent: - enabled: true - default_max_iterations: 5 - default_temperature: 0.7 - reflection_enabled: false - default_tools: - - knowledge_search - - multi_kb_search - - list_knowledge_bases - - get_chunk_detail - - get_related_chunks - - query_knowledge_graph - - get_document_info -``` - -## 可用工具 - -### 1. knowledge_search -搜索指定知识库中的相关内容。 - -**参数:** -- `knowledge_base_id` (必需): 知识库ID -- `query` (必需): 搜索查询内容 -- `top_k` (可选): 返回结果数量,默认5 - -**示例:** -``` -knowledge_search(knowledge_base_id="kb123", query="什么是RAG", top_k=5) -``` - -### 2. multi_kb_search -在多个知识库中智能搜索,自动选择最相关的知识库。 - -**参数:** -- `query` (必需): 搜索查询内容 -- `top_k` (可选): 每个知识库返回的结果数量,默认3 - -**适用场景:** 跨知识库查询,不确定信息在哪个知识库中 - -### 3. list_knowledge_bases -列出当前可访问的所有知识库。 - -**参数:** 无 - -**用途:** 了解有哪些知识库可以搜索 - -### 4. get_chunk_detail -获取指定chunk的详细信息,包括完整内容、来源文档。 - -**参数:** -- `chunk_id` (必需): Chunk ID - -**用途:** 当搜索结果不够详细时获取完整内容 - -### 5. get_related_chunks -获取与指定chunk相关的其他chunks。 - -**参数:** -- `chunk_id` (必需): Chunk ID -- `relation_type` (可选): "sequential" (顺序) 或 "semantic" (语义) -- `limit` (可选): 返回数量,默认5 - -**用途:** 发现相关信息,扩展上下文 - -### 6. query_knowledge_graph -查询知识图谱中的实体和关系。 - -**参数:** -- `knowledge_base_id` (必需): 知识库ID -- `query` (必需): 查询内容(实体名称或查询文本) - -**前提:** 知识库已配置知识图谱抽取 - -### 7. get_document_info -获取文档的元数据信息。 - -**参数:** -- `knowledge_id` (必需): 文档/知识ID - -**用途:** 了解文档的整体情况 - -## 使用指南 - -### 创建 Agent Session - -```bash -POST /api/v1/sessions - -{ - "knowledge_base_id": "kb123", - "session_strategy": { - "summary_model_id": "model123", - ... - }, - "agent_config": { - "enabled": true, - "enable_planning": false, - "max_iterations": 5, - "reflection_enabled": false, - "allowed_tools": [ - "knowledge_search", - "multi_kb_search", - "list_knowledge_bases" - ], - "temperature": 0.7, - "knowledge_bases": ["kb123", "kb456"] - } -} -``` - -### 发起 Agent 查询 - -```bash -POST /api/v1/sessions/{session_id}/agent-qa - -{ - "query": "请解释RAG技术的工作原理" -} -``` - -### 响应格式 - -Agent 会返回 SSE (Server-Sent Events) 流式响应: - -1. **知识引用** (可选) -```json -{ - "response_type": "references", - "knowledge_references": [...] -} -``` - -2. **Agent 思考过程** (可选,用于调试) -```json -{ - "response_type": "agent_thought", - "content": "我需要先搜索相关知识..." -} -``` - -3. **工具调用** (可选) -```json -{ - "response_type": "agent_action", - "content": "调用工具: knowledge_search" -} -``` - -4. **最终答案** -```json -{ - "response_type": "answer", - "content": "RAG技术的工作原理是...", - "done": true -} -``` - -## 最佳实践 - -### 1. 工具选择策略 - -- **已知知识库**: 使用 `knowledge_search` -- **不确定位置**: 使用 `multi_kb_search` -- **需要上下文**: 使用 `get_related_chunks` -- **探索阶段**: 先用 `list_knowledge_bases` - -### 2. 迭代次数设置 - -- **简单查询**: 3-5 次 -- **复杂问题**: 5-10 次 -- **探索性任务**: 10-15 次 -- **最大限制**: 20 次 (防止无限循环) - -### 3. 温度参数 - -- **精确查询**: 0.3-0.5 (更确定性) -- **创造性任务**: 0.7-1.0 (更多样性) -- **默认推荐**: 0.7 - -### 4. Planning 启用时机 - -- **复杂多步骤任务**: 启用 -- **简单直接查询**: 禁用 -- **探索性问题**: 启用 - -### 5. Reflection 启用时机 - -- **关键任务**: 启用 (提高准确性) -- **快速响应**: 禁用 (减少延迟) -- **默认**: 禁用 - -## 工作原理详解 - -### ReAct Prompt Template - -``` -你是一个智能知识库助手。你的任务是通过使用提供的工具来回答用户问题。 - -工作流程: -1. 分析用户问题,确定需要什么信息 -2. 使用合适的工具获取信息(可以多次调用不同工具) -3. 基于获取的信息,提供准确、完整的答案 - -注意事项: -- 优先使用 multi_kb_search 进行跨知识库搜索 -- 如果需要特定知识库,先用 list_knowledge_bases 查看可用知识库 -- 如果搜索结果不够详细,使用 get_chunk_detail 获取完整内容 -- 使用 get_related_chunks 发现相关信息 -- 如果涉及实体关系,使用 query_knowledge_graph -- 引用信息时,说明来源(chunk_id 或 knowledge_base) -- 如果找不到相关信息,诚实告知用户 - -当前可访问的知识库: -{knowledge_bases} - -{plan_context} -``` - -### 工具调用解析 - -Agent 会尝试从 LLM 输出中解析工具调用,支持的格式: - -``` -tool_name(arg1="value1", arg2="value2") -``` - -例如: -``` -knowledge_search(knowledge_base_id="kb123", query="RAG技术") -``` - -### 循环控制 - -Agent 会在以下情况停止: - -1. LLM 输出包含 "最终答案" 或 "Final Answer" -2. 达到最大迭代次数 -3. 工具调用失败且无法恢复 -4. 检测到重复循环模式 - -## 事件追踪 - -Agent 执行过程中会发送以下事件 (通过 Event Bus): - -### agent.plan -```go -type AgentPlanData struct { - Query string - Plan []string - Duration int64 -} -``` - -### agent.step -```go -type AgentStepData struct { - Iteration int - Thought string - ToolCalls []ToolCall - Duration int64 -} -``` - -### agent.tool -```go -type AgentActionData struct { - Iteration int - ToolName string - ToolInput map[string]interface{} - ToolOutput string - Success bool - Error string - Duration int64 -} -``` - -## 示例场景 - -### 场景 1: 简单知识查询 - -**用户问题**: "什么是 RAG?" - -**Agent 执行流程**: -1. **Think**: 需要搜索 RAG 相关知识 -2. **Act**: `multi_kb_search(query="RAG")` -3. **Observe**: 获得3条相关结果 -4. **Think**: 信息足够,可以回答 -5. **Final Answer**: 基于搜索结果生成答案 - -**迭代次数**: 2 - -### 场景 2: 跨文档关联查询 - -**用户问题**: "比较 RAG 和微调的优缺点" - -**Agent 执行流程**: -1. **Think**: 需要分别查找 RAG 和微调的信息 -2. **Act**: `multi_kb_search(query="RAG优缺点")` -3. **Observe**: 获得 RAG 相关信息 -4. **Think**: 还需要微调的信息 -5. **Act**: `multi_kb_search(query="模型微调优缺点")` -6. **Observe**: 获得微调相关信息 -7. **Think**: 信息完整,进行对比 -8. **Final Answer**: 综合两者信息生成对比答案 - -**迭代次数**: 4 - -### 场景 3: 深入探索 - -**用户问题**: "详细解释向量数据库的工作原理" - -**Agent 执行流程**: -1. **Think**: 先查看有哪些知识库 -2. **Act**: `list_knowledge_bases()` -3. **Observe**: 发现有"数据库技术"知识库 -4. **Think**: 在该知识库中搜索 -5. **Act**: `knowledge_search(knowledge_base_id="db_kb", query="向量数据库")` -6. **Observe**: 找到相关 chunk -7. **Think**: 需要更多细节 -8. **Act**: `get_chunk_detail(chunk_id="chunk123")` -9. **Observe**: 获得完整内容 -10. **Think**: 查看相关内容 -11. **Act**: `get_related_chunks(chunk_id="chunk123", relation_type="sequential")` -12. **Observe**: 获得上下文 -13. **Final Answer**: 基于详细信息生成深入解释 - -**迭代次数**: 7 - -## 常见问题 - -### Q: Agent 和普通 RAG 有什么区别? - -**A**: -- **普通 RAG**: 一次性检索 → 生成答案 -- **Agent**: 可以多次迭代,根据中间结果调整策略,调用不同工具 - -### Q: 什么时候使用 Agent 模式? - -**A**: -- 需要多步推理的复杂问题 -- 需要在多个知识库中查找信息 -- 需要深入探索和关联分析 -- 问题模糊,需要澄清和逐步细化 - -### Q: Agent 模式的成本如何? - -**A**: -- **Token 消耗**: 比普通 RAG 高 (多次 LLM 调用) -- **响应时间**: 较长 (迭代执行) -- **准确性**: 通常更高 (多步验证) - -### Q: 如何优化 Agent 性能? - -**A**: -1. 合理设置 `max_iterations` (避免过多) -2. 选择必要的工具 (`allowed_tools`) -3. 禁用不需要的功能 (planning, reflection) -4. 使用更快的模型作为 thinking_model - -### Q: 工具调用失败怎么办? - -**A**: Agent 会: -1. 在 Observation 中记录错误 -2. 尝试使用其他工具 -3. 如果多次失败,会在最终答案中说明 - -## 技术限制与注意事项 - -### 当前限制 - -1. **工具调用解析**: 使用简单的模式匹配,可能无法处理复杂格式 -2. **Function Calling**: 当前使用 prompt-based 方式,未来可升级为原生 function calling -3. **并行工具调用**: 当前不支持,工具按顺序执行 -4. **图谱查询**: 当前使用 hybrid search,完整图谱功能开发中 - -### 未来改进 - -- [ ] 支持 LLM 原生 function calling (GPT-4, Claude 等) -- [ ] 并行工具执行 -- [ ] 更智能的循环检测 -- [ ] 工具结果缓存 -- [ ] 自定义工具注册 -- [ ] Agent 执行可视化 UI - -## 开发指南 - -### 创建自定义工具 - -```go -package tools - -import ( - "context" - "github.com/Tencent/WeKnora/internal/types" -) - -type CustomTool struct { - BaseTool - // 添加依赖 -} - -func NewCustomTool() *CustomTool { - return &CustomTool{ - BaseTool: NewBaseTool( - "custom_tool", - "工具描述", - ), - } -} - -func (t *CustomTool) Parameters() map[string]interface{} { - return map[string]interface{}{ - "type": "object", - "properties": map[string]interface{}{ - "param1": map[string]interface{}{ - "type": "string", - "description": "参数描述", - }, - }, - "required": []string{"param1"}, - } -} - -func (t *CustomTool) Execute(ctx context.Context, args map[string]interface{}) (*types.ToolResult, error) { - // 实现工具逻辑 - param1 := args["param1"].(string) - - // 执行操作 - result := doSomething(param1) - - return &types.ToolResult{ - Success: true, - Output: result, - Data: map[string]interface{}{}, - }, nil -} -``` - -### 注册自定义工具 - -在 `agent_service.go` 的 `registerTools` 方法中添加: - -```go -case "custom_tool": - registry.RegisterTool(tools.NewCustomTool()) -``` - -## 总结 - -WeKnora Agent Mode 提供了强大的迭代推理能力,适用于复杂的知识查询场景。通过合理配置和工具选择,可以在准确性和效率之间找到最佳平衡点。 - -如有问题或建议,请提交 Issue 或 Pull Request。 - diff --git a/docs/CONTEXT_MANAGER.md b/docs/CONTEXT_MANAGER.md deleted file mode 100644 index 7e5bc4771..000000000 --- a/docs/CONTEXT_MANAGER.md +++ /dev/null @@ -1,401 +0,0 @@ -# LLM Context Manager - 大模型上下文管理器 - -## 概述 - -LLM Context Manager 是一个专门用于管理大模型对话上下文的组件,它**独立于消息存储系统**,专注于管理发送给大模型的上下文窗口。 - -### 关键特性 - -1. **独立管理**: 与消息的数据库存储分离,专门管理发送给 LLM 的上下文 -2. **Token 限制管理**: 自动监控和管理上下文的 Token 数量 -3. **智能压缩**: 当上下文超出限制时,自动应用压缩策略 -4. **按 Session 维护**: 每个会话独立管理其上下文 -5. **灵活配置**: 支持会话级别的自定义配置 - -## 为什么需要 Context Manager? - -### 问题背景 - -- **消息存储** vs **LLM 上下文**: - - 消息存储:完整保存所有对话历史,用于展示和审计 - - LLM 上下文:有 Token 限制,需要精简管理 - -- **Token 限制**: 不同模型有不同的上下文窗口限制(如 4K, 8K, 16K tokens) - -- **性能优化**: 过长的上下文会增加推理时间和成本 - -### 解决方案 - -Context Manager 提供: -- 自动管理上下文窗口大小 -- 智能压缩历史消息 -- 保留最重要的上下文信息 -- 与消息存储解耦 - -## 架构设计 - -``` -┌─────────────────────────────────────────────────────────────┐ -│ Session Service │ -│ │ -│ ┌──────────────────┐ ┌──────────────────┐ │ -│ │ Message Repo │ │ Context Manager │ │ -│ │ (Complete │ │ (LLM Context │ │ -│ │ History) │ │ Window) │ │ -│ └──────────────────┘ └──────────────────┘ │ -│ │ │ │ -│ │ Save all messages │ Manage LLM │ -│ │ for display │ context │ -│ ▼ ▼ │ -│ ┌──────────────────┐ ┌──────────────────┐ │ -│ │ Database │ │ In-Memory │ │ -│ │ (Persistent) │ │ (Session-based) │ │ -│ └──────────────────┘ └──────────────────┘ │ -└─────────────────────────────────────────────────────────────┘ -``` - -## 压缩策略 - -### 1. 滑动窗口策略 (Sliding Window) - -保留最近的 N 条消息,丢弃更早的消息。 - -**优点:** -- 简单高效 -- 不需要额外的 LLM 调用 -- 适合短期对话 - -**配置示例:** -```json -{ - "enabled": true, - "max_tokens": 8192, - "compression_strategy": "sliding_window", - "recent_message_count": 20 -} -``` - -**工作原理:** -``` -原始消息: [system, msg1, msg2, msg3, ..., msg18, msg19, msg20, msg21, msg22] - ↑ - 保留最近20条消息 -压缩结果: [system, msg3, msg4, ..., msg20, msg21, msg22] - └─────┘ └──────────────────────────────────┘ - 保留系统消息 保留最近的20条消息 -``` - -### 2. 智能压缩策略 (Smart Compression) - -使用 LLM 总结旧消息,保留最近消息的完整内容。 - -**优点:** -- 保留历史关键信息 -- 更好的上下文连贯性 -- 适合长期对话 - -**配置示例:** -```json -{ - "enabled": true, - "max_tokens": 8192, - "compression_strategy": "smart", - "recent_message_count": 10 -} -``` - -**工作原理:** -``` -原始消息: [system, msg1, msg2, ..., msg15, msg16, msg17, msg18, msg19, msg20] - └───────────────┘ └─────────────────────────────┘ - 旧消息(总结) 最近消息(保留) - -压缩结果: [system, summary, msg16, msg17, msg18, msg19, msg20] - └─────┘ └──────┘ └──────────────────────────────┘ - 系统消息 总结 保留最近的10条消息(完整) -``` - -## 使用方法 - -### 1. 默认配置 - -如果不设置 `context_config`,系统使用默认配置: -- 最大 Token: 8192 -- 策略: 滑动窗口 -- 保留消息数: 20 - -```go -// 不需要特别配置,自动使用默认设置 -session := &types.Session{ - TenantID: tenantID, - KnowledgeBaseID: kbID, - // context_config 为 nil,使用默认配置 -} -``` - -### 2. 自定义配置 - 滑动窗口 - -```go -session := &types.Session{ - TenantID: tenantID, - KnowledgeBaseID: kbID, - ContextConfig: &types.ContextConfig{ - Enabled: true, - MaxTokens: 16384, // GPT-4 的上下文窗口 - CompressionStrategy: types.ContextCompressionSlidingWindow, - RecentMessageCount: 30, // 保留最近30条消息 - }, -} -``` - -### 3. 自定义配置 - 智能压缩 - -```go -session := &types.Session{ - TenantID: tenantID, - KnowledgeBaseID: kbID, - SummaryModelID: "gpt-4", // 用于总结的模型 - ContextConfig: &types.ContextConfig{ - Enabled: true, - MaxTokens: 8192, - CompressionStrategy: types.ContextCompressionSmart, - RecentMessageCount: 15, // 保留最近15条完整消息 - }, -} -``` - -### 4. 通过 API 创建/更新会话 - -```bash -# 创建带上下文配置的会话 -curl -X POST http://localhost:8080/api/v1/sessions \ - -H "Content-Type: application/json" \ - -H "X-Tenant-ID: 1" \ - -d '{ - "knowledge_base_id": "kb-123", - "context_config": { - "enabled": true, - "max_tokens": 8192, - "compression_strategy": "sliding_window", - "recent_message_count": 20 - } - }' -``` - -## 工作流程 - -### 对话流程 - -``` -1. 用户发送消息 - ↓ -2. 保存消息到数据库 (Message Repo) - ↓ -3. 添加消息到上下文管理器 (Context Manager) - ↓ -4. Context Manager 检查 Token 限制 - ↓ -5. 如果超出限制,应用压缩策略 - ↓ -6. 获取压缩后的上下文 - ↓ -7. 发送给 LLM - ↓ -8. 保存响应到数据库 - ↓ -9. 添加响应到上下文管理器 -``` - -### 代码示例 - -```go -// 在 AgentQA 中的使用 -func (s *sessionService) AgentQA(ctx context.Context, sessionID, query string, assistantMessageID string) ( - []*types.SearchResult, <-chan types.StreamResponse, error, -) { - // 1. 获取会话配置 - session, err := s.sessionRepo.Get(ctx, tenantID, sessionID) - - // 2. 从上下文管理器获取 LLM 上下文(自动应用压缩) - history, err := s.getContextForSession(ctx, session, sessionID) - // history 是压缩后的,适合发送给 LLM 的消息列表 - - // 3. 执行 Agent - eventChan, err := engine.ExecuteStreamWithHistory(ctx, query, history) - - // 4. 保存新消息后,添加到上下文管理器 - // s.AddMessageToContext(ctx, session, sessionID, newMessage) - - return searchResults, responseChan, nil -} -``` - -## 配置参数说明 - -### ContextConfig 字段 - -| 字段 | 类型 | 说明 | 默认值 | -|------|------|------|--------| -| `enabled` | bool | 是否启用上下文管理 | true | -| `max_tokens` | int | 最大 Token 数 | 8192 | -| `compression_strategy` | string | 压缩策略: "sliding_window" 或 "smart" | "sliding_window" | -| `recent_message_count` | int | 保留的最近消息数 | 20 (sliding_window)
10 (smart) | - -### 推荐配置 - -#### 短期对话(客服、问答) -```json -{ - "enabled": true, - "max_tokens": 4096, - "compression_strategy": "sliding_window", - "recent_message_count": 15 -} -``` - -#### 长期对话(咨询、助手) -```json -{ - "enabled": true, - "max_tokens": 8192, - "compression_strategy": "smart", - "recent_message_count": 10 -} -``` - -#### 高端模型(GPT-4 Turbo, Claude) -```json -{ - "enabled": true, - "max_tokens": 16384, - "compression_strategy": "smart", - "recent_message_count": 20 -} -``` - -## 监控和调试 - -### 查看上下文统计 - -```go -// 获取上下文统计信息 -stats, err := contextManager.GetContextStats(ctx, sessionID) -if err == nil { - log.Printf("Session %s context stats:", sessionID) - log.Printf(" Messages: %d", stats.MessageCount) - log.Printf(" Tokens: ~%d", stats.TokenCount) - log.Printf(" Compressed: %v", stats.IsCompressed) - log.Printf(" Original messages: %d", stats.OriginalMessageCount) -} -``` - -### 日志示例 - -``` -INFO Using custom context config for session abc123: strategy=smart, max_tokens=8192, recent_count=10 -INFO Context exceeds max tokens (9500 > 8192), applying compression -INFO Summarizing 15 old messages -INFO Successfully summarized 15 messages -INFO Smart compression: 25 -> 11 messages (system: 1, compressed: 1, recent: 10) -INFO LLM context stats for session abc123: messages=11, tokens=~7800, compressed=true -``` - -## 与消息存储的区别 - -| 特性 | 消息存储 (Message Repo) | 上下文管理器 (Context Manager) | -|------|------------------------|------------------------------| -| 目的 | 完整保存对话历史 | 管理 LLM 输入上下文 | -| 存储 | 数据库(持久化) | 内存(会话级别) | -| 内容 | 所有消息(完整) | 压缩后的消息 | -| 大小限制 | 无限制 | 受 Token 限制 | -| 使用场景 | 展示历史、审计 | LLM 推理输入 | -| 生命周期 | 永久保存 | 会话期间 | - -## 最佳实践 - -1. **选择合适的策略**: - - 短对话 → 滑动窗口(性能更好) - - 长对话 → 智能压缩(保留更多上下文) - -2. **配置 Token 限制**: - - 设置为模型上下文窗口的 70-80% - - 为响应留出足够空间 - -3. **调整保留消息数**: - - 滑动窗口: 15-30 条消息 - - 智能压缩: 8-15 条最近消息 - -4. **监控压缩效果**: - - 定期检查 Token 使用情况 - - 观察压缩是否影响对话质量 - -5. **性能考虑**: - - 智能压缩会额外调用 LLM(有成本) - - 滑动窗口无额外开销 - -## 数据库迁移 - -运行以下迁移脚本添加 `context_config` 字段: - -### MySQL -```bash -mysql -u root -p your_database < migrations/mysql/06-add-context-config-to-sessions.sql -``` - -### ParadeDB/PostgreSQL -```bash -psql -U postgres -d your_database -f migrations/paradedb/06-add-context-config-to-sessions.sql -``` - -## 常见问题 - -### Q1: 上下文管理器的数据会持久化吗? -**A**: 不会。上下文管理器是内存级别的,按 Session 维护。重启后会清空,需要从消息历史重新构建。 - -### Q2: 如何清空某个会话的上下文? -**A**: -```go -err := contextManager.ClearContext(ctx, sessionID) -``` - -### Q3: 压缩后的消息会影响数据库中的消息吗? -**A**: 不会。压缩只影响发送给 LLM 的上下文,数据库中的消息完整保留。 - -### Q4: 智能压缩的总结质量如何保证? -**A**: -- 使用会话配置的 `summary_model_id` 模型 -- 可以使用更强的模型(如 GPT-4)进行总结 -- 总结时使用低 temperature (0.3) 确保一致性 - -### Q5: 如何为现有会话启用上下文管理? -**A**: -```bash -# 更新会话配置 -curl -X PUT http://localhost:8080/api/v1/sessions/{session_id} \ - -H "Content-Type: application/json" \ - -H "X-Tenant-ID: 1" \ - -d '{ - "context_config": { - "enabled": true, - "max_tokens": 8192, - "compression_strategy": "sliding_window", - "recent_message_count": 20 - } - }' -``` - -## 未来改进 - -- [ ] 支持更多压缩策略(如 MapReduce 总结) -- [ ] 支持自定义 Token 计算器 -- [ ] 持久化压缩后的上下文摘要 -- [ ] 支持跨会话的上下文共享 -- [ ] 添加更详细的压缩指标和监控 -- [ ] 支持上下文恢复机制 - -## 参考 - -- [Agent 文档](./AGENT.md) -- [API 文档](./API.md) -- [消息管理](../internal/types/message.go) - diff --git a/docs/MCP功能使用说明.md b/docs/MCP功能使用说明.md new file mode 100644 index 000000000..a43604865 --- /dev/null +++ b/docs/MCP功能使用说明.md @@ -0,0 +1,30 @@ +## MCP 功能使用说明 + +### 功能概述 +- MCP(Model Context Protocol)让 WeKnora 可以安全地连接外部工具或数据源,扩展 Agent 在推理时可调用的能力。 +- 在前端 `设置 > MCP 服务`(`frontend/src/views/settings/McpSettings.vue`)中集中管理所有服务,无需手动改配置文件。 +- 每个服务都包含名称、传输方式(SSE / HTTP Streamable / Stdio)、连接地址或命令、认证信息以及高级超时与重试策略。 + +### 入口与界面 +- 打开控制台左侧菜单 `设置 -> MCP 服务`,即可看到当前租户下的所有 MCP 服务列表。 +- 列表中可快速启停服务、查看描述,并通过右侧菜单执行“测试 / 编辑 / 删除”。 +- “添加服务”按钮会弹出 `McpServiceDialog`,用于创建或修改服务。 + +### 常用操作流程 +1. **新建服务** + - 点击“添加服务”,填写名称与描述,选择传输方式。 + - SSE / HTTP Streamable 需提供可访问的服务 URL;Stdio 需配置 `uvx`/`npx` 命令与参数,可附加环境变量。 + - 根据需要填写 API Key、Bearer Token、超时与重试策略,保存后服务会出现在列表中。 +2. **启停服务** + - 在列表开关中切换启用状态,系统会即时调用后端 `updateMCPService`,失败时会自动回滚状态并弹出提示。 +3. **连接测试** + - 通过更多菜单选择“测试”,前端会调用 `/api/v1/mcp-services/{id}/test` 并弹出 `McpTestResult`。 + - 成功时会展示服务可用的工具清单(含输入 schema)和资源列表;失败时会显示错误信息,方便排查网络或鉴权问题。 +4. **编辑 / 删除** + - “编辑”会带出原有配置,修改后保存即可。 + - “删除”需要在弹窗中确认,完成后列表自动刷新。 + +### 使用建议 +- **传输方式选择**:优先使用 SSE 获取流式体验;需要标准 HTTP Streamable 兼容时再切换;本地调试或离线环境适合使用 Stdio 并在同机启动 MCP Server。 +- **鉴权管理**:将 API Key / Token 保存在“认证配置”中,生产环境建议单独创建最小权限 Key,并定期轮换。 +- **重试策略**:对公网或第三方服务适当提高 `retry_count` 与 `retry_delay`,避免间歇性超时导致 Agent 中断 \ No newline at end of file diff --git a/docs/快速开发模式说明.md b/docs/快速开发模式说明.md index 68b61efc8..70a4f03cc 100644 --- a/docs/快速开发模式说明.md +++ b/docs/快速开发模式说明.md @@ -1,74 +1,7 @@ # 快速开发模式说明 -## 🎯 问题背景 +解决开发流程中,每次修改 `app`(后端)或 `frontend`(前端)代码后,都需要打包Docker镜像的问题,实现这两个模块的热更新 -之前的开发流程中,每次修改 `app`(后端)或 `frontend`(前端)代码后,都需要: - -```bash -# 重新构建 Docker 镜像(耗时 2-5 分钟) -sh scripts/build_images.sh -p # 构建后端 -sh scripts/build_images.sh -f # 构建前端 - -# 重启容器 -sh scripts/start_all.sh --no-pull -``` - -这个流程非常耗时,严重影响开发效率。 - -## ✨ 解决方案 - -现在提供了**快速开发模式**,可以直接在本地运行应用和前端,只在 Docker 中启动基础设施服务(数据库、缓存等),实现: - -- ✅ **前端热重载**:修改代码自动刷新,无需重启 -- ✅ **后端快速重启**:修改代码后 5-10 秒即可重启 -- ✅ **无需构建镜像**:跳过耗时的镜像构建过程 -- ✅ **支持调试**:可以使用 IDE 断点调试 - -## 📦 新增文件 - -### 1. 核心配置文件 - -- **`docker-compose.dev.yml`** - 开发环境 Docker Compose 配置 - - 只启动基础设施服务(postgres, redis, minio, neo4j, docreader, jaeger) - - 不启动 app 和 frontend 容器 - -### 2. 开发脚本 - -- **`scripts/dev.sh`** - 开发环境管理脚本 - - 支持启动/停止基础设施 - - 支持本地运行 app 和 frontend - - 自动检测并使用 Air(Go 热重载工具) - -- **`scripts/quick-dev.sh`** - 一键启动开发环境脚本 - - 交互式启动所有服务 - - 自动创建日志目录 - -### 3. 配置文件 - -- **`.air.toml`** - Air 热重载配置 - - 监控 Go 文件变化 - - 自动重新编译和重启 - -- **`frontend/vite.config.ts`** - 更新的 Vite 配置 - - 添加 API 代理配置 - - 避免 CORS 问题 - -### 4. 文档 - -- **`DEVELOPMENT.md`** - 开发环境快速入门指南 -- **`docs/开发指南.md`** - 完整开发指南 -- **`docs/快速开发模式说明.md`** - 本文档 - -### 5. Makefile 更新 - -新增的 Make 命令: -- `make dev-start` - 启动开发环境基础设施 -- `make dev-stop` - 停止开发环境 -- `make dev-restart` - 重启开发环境 -- `make dev-logs` - 查看服务日志 -- `make dev-status` - 查看服务状态 -- `make dev-app` - 启动后端应用(本地) -- `make dev-frontend` - 启动前端(本地) ## 🚀 使用方法 @@ -104,28 +37,7 @@ make dev-frontend ./scripts/quick-dev.sh ``` -## 📊 效率对比 -### 旧方式(慢) - -| 操作 | 耗时 | -|------|------| -| 修改代码 | - | -| 重新构建镜像 | 2-5 分钟 | -| 重启容器 | 30-60 秒 | -| **总计** | **2.5-6 分钟** | - -### 新方式(快) - -| 操作 | 耗时 | -|------|------| -| 首次启动基础设施 | 1-2 分钟(仅一次) | -| **后续修改后端** | **5-10 秒** | -| **后续修改前端** | **实时热重载** | - -**效率提升:20-60 倍!** - -## 🎓 高级功能 ### 使用 Air 实现后端热重载 @@ -142,32 +54,6 @@ export PATH=$PATH:$(go env GOPATH)/bin make dev-app ``` -### VS Code 调试配置 - -创建 `.vscode/launch.json`: - -```json -{ - "version": "0.2.0", - "configurations": [ - { - "name": "Launch WeKnora Server", - "type": "go", - "request": "launch", - "mode": "auto", - "program": "${workspaceFolder}/cmd/server", - "env": { - "DB_HOST": "localhost", - "DOCREADER_ADDR": "localhost:50051", - "MINIO_ENDPOINT": "localhost:9000", - "REDIS_ADDR": "localhost:6379", - "OTEL_EXPORTER_OTLP_ENDPOINT": "localhost:4317", - "NEO4J_URI": "bolt://localhost:7687" - } - } - ] -} -``` ## 🔄 架构说明 @@ -217,39 +103,4 @@ make dev-app │ └─────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘ -``` - -## 🎯 使用场景 - -### 日常开发 - -使用**开发模式**(`make dev-*`),享受快速迭代。 - -### 集成测试 - -使用**生产模式**(`make start-all`),测试完整环境。 - -### 生产部署 - -```bash -# 构建镜像 -make build-images - -# 启动服务 -make start-all -``` - -## 🔧 故障排除 - -详见 [DEVELOPMENT.md](../DEVELOPMENT.md) 的故障排除部分。 - -## 📚 相关文档 - -- [开发环境快速入门](../DEVELOPMENT.md) -- [完整开发指南](./开发指南.md) -- [API 文档](./API.md) - -## 💬 反馈与建议 - -如有问题或建议,请提交 [Issue](https://github.com/Tencent/WeKnora/issues)。 - +``` \ No newline at end of file diff --git a/frontend/src/api/system/index.ts b/frontend/src/api/system/index.ts index e4bcf7bfc..c58835595 100644 --- a/frontend/src/api/system/index.ts +++ b/frontend/src/api/system/index.ts @@ -43,6 +43,22 @@ export interface ConversationConfig { context_template: string temperature: number max_tokens: number + use_custom_system_prompt?: boolean + use_custom_context_template?: boolean + max_rounds: number + embedding_top_k: number + keyword_threshold: number + vector_threshold: number + rerank_top_k: number + rerank_threshold: number + enable_rewrite: boolean + fallback_strategy: string + fallback_response: string + fallback_prompt?: string + summary_model_id?: string + rerank_model_id?: string + rewrite_prompt_system?: string + rewrite_prompt_user?: string } export function getSystemInfo(): Promise<{ data: SystemInfo }> { diff --git a/frontend/src/components/UserMenu.vue b/frontend/src/components/UserMenu.vue index 74e028434..34aa60cb8 100644 --- a/frontend/src/components/UserMenu.vue +++ b/frontend/src/components/UserMenu.vue @@ -18,7 +18,7 @@