admin/aiagent
1
0
Fork 0
Code Issues 25 Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add AI学习助手 agent (KG+RAG ideal) and renshenguo feishu bot

Browse Source 
- Add AI学习助手 agent creation script with all 39 tools, 3-layer KG+RAG memory
- Add renshenguo (人参果) feishu bot integration (app_service + ws_handler)
- Register renshenguo WS client in main.py startup
- Add RENSHENGUO_APP_ID / RENSHENGUO_APP_SECRET / RENSHENGUO_AGENT_ID config
- Reorganize docs from root into docs/ subdirectories
- Move startup scripts to scripts/startup/
- Various backend optimizations and tool improvements

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
renjianbo
2026-05-06 01:37:13 +08:00
parent f33bc461ff
commit eabf90c496
171 changed files with 4906 additions and 445 deletions
Download Patch File Download Diff File Expand all files Collapse all files

193
docs/tests/(红头)agent测试用例文档.md Normal file
View File

@@ -0,0 +1,193 @@
# Agent 通用测试用例规范
本文档约定**任意 Agent** 如何通过同一套接口做自动化黑盒测试。你只要按下面的 **JSON 用例文件格式** 写好（或从模板复制改名字/话术），即可用仓库根目录脚本**一次性跑完全部用例**。
---
## 1. 前置条件
| 项 | 说明 |
|----|------|
| 后端 API | 默认 `http://localhost:8037`，可用环境变量 `API_BASE_URL` 覆盖 |
| 登录 | OAuth2 表单：`POST /api/v1/auth/login`，字段 `username`、`password` |
| 执行 Agent | `POST /api/v1/executions`，body 含 `agent_id` 与 `input_data` |
| 轮询 | `GET /api/v1/executions/{id}/status`；结束后再 `GET /api/v1/executions/{id}` 取 `output_data` |
| 异步 | 需 **Redis** 与 **Celery Worker** 正常，否则创建执行可能返回 503 |
**输入字段约定（与《工作流调用测试总结》及前端预览一致）：**
- 最小集：`query`、`USER_INPUT`（字符串相同即可），便于工作流提取 `user_query`。
- 若某 Agent 在设计器里还依赖 `user_id`、`attachments` 等，可在用例的 `input_extra` 里追加（见第 3 节）。
---
## 2. 一键跑用例（推荐）
1. 复制本文档第 5 节示例，或复制仓库内 **`agent_test_cases.example.json`** 为 **`agent_test_cases.json`**（或任意路径）。
2. 在项目根目录执行：
```bash
python run_agent_test_cases.py
```
指定文件与账号：
```bash
python run_agent_test_cases.py --cases my_cases.json --username admin --password 你的密码 --base-url http://127.0.0.1:8037
```
环境变量（可选）：
- `API_BASE_URL`：例如 `http://127.0.0.1:8037`
- `AGENT_TEST_CASES`：默认用例文件路径（不设则使用 `agent_test_cases.json`）
- Windows 控制台建议已使用 UTF-8（脚本内会尽量 `reconfigure` stdout，避免模型回复含 emoji 时打印报错）
---
## 3. 用例文件格式（JSON Schema说明）
根对象字段：
| 字段 | 类型 | 必填 | 说明 |
|------|------|------|------|
| `version` | number | 建议 | 目前使用 `1` |
| `defaults` | object | 否 | 全局默认：URL、账号、超时、轮询间隔等 |
| `cases` | array | **是** | 测试用例列表 |
### 3.1 `defaults` 可选键
| 键 | 类型 | 默认 | 说明 |
|----|------|------|------|
| `base_url` | string | `API_BASE_URL` 或 `http://localhost:8037` | API 根地址 |
| `username` | string | `admin` | 登录用户名 |
| `password` | string | `123456` | 登录密码 |
| `request_timeout_sec` | number | `120` | 单次 HTTP 超时（秒） |
| `max_wait_sec` | number | `300` | 单条用例轮询最长时间（秒） |
| `poll_interval_sec` | number | `2` | 轮询间隔（秒） |
### 3.2 单条 `cases[]` 对象
| 字段 | 类型 | 必填 | 说明 |
|------|------|------|------|
| `id` | string | 建议 | 用例 ID，日志与报告中展示 |
| `name` | string | 否 | 简短描述 |
| `enabled` | boolean | 否 | 默认 `true`；`false` 则跳过 |
| `agent` | object | **是** | 见下表「定位 Agent」 |
| `message` | string | **是** | 用户话术；会写入 `query` 与 `USER_INPUT` |
| `input_extra` | object | 否 | 合并进 `input_data`（勿覆盖 `query`/`USER_INPUT` 除非你有意为之） |
| `expect` | object | 否 | 断言；缺省则仅校验能跑完且状态为 `completed`（见 3.3） |
**`agent` 定位（二选一，不可同时缺）：**
| 键 | 说明 |
|----|------|
| `id` | Agent UUID，优先级最高 |
| `name` | 精确名称；通过 `GET /api/v1/agents?search=...` 再在结果里做**名称全等**匹配；若无全等则取搜索结果第一条（与 `test_agent_execution.py` 行为一致） |
### 3.3 `expect` 可选断言
| 键 | 类型 | 说明 |
|----|------|------|
| `status` | string | 期望最终状态，默认 `completed` |
| `output_contains` | string[] | 助手最终文本中须**全部**包含的子串（见下方「输出文本提取」） |
| `output_not_contains` | string[] | 最终文本中**不得**包含任一子串 |
| `case_insensitive` | boolean | 为 `true` 时，上述 contains / not_contains 忽略大小写 |
**输出文本提取规则（与 `test_agent_execution.py` 一致）：**
从 `GET /api/v1/executions/{id}` 的 `output_data` 中依次尝试字段：`result` → `output` → `text` → `content`；若仍为对象则序列化为 JSON 字符串再做子串匹配。
### 3.4 LLM 类 Agent 的断言建议
- 优先使用 **`output_contains`** 绑定业务关键词（如「作业」「截止」），避免对全文逐字比对。
- 冒烟用例可只写 `message`，不写 `expect`，仅确认 `status === completed`。
- 需要稳定复现时，可在 Agent 侧固定模型与温度，或在用例里放宽为1～2 个关键词。
---
## 4. 与现有脚本的关系
| 脚本 | 用途 |
|------|------|
| `test_agent_execution.py` | 单 Agent / 单轮对话、命令行友好（含 `--homework`） |
| `run_agent_test_cases.py` | 读取 **JSON 用例文件**，批量执行 + 简单断言，**适合所有 Agent 回归** |
新增 Agent 时：在 `agent_test_cases.json` 的 `cases` 数组中追加对象即可，无需改 Python 代码。
---
## 5. 完整示例（可复制为 `agent_test_cases.json`）
```json
{
"version": 1,
"defaults": {
"base_url": "http://localhost:8037",
"username": "admin",
"password": "123456",
"request_timeout_sec": 120,
"max_wait_sec": 300,
"poll_interval_sec": 2
},
"cases": [
{
"id": "homework-hello",
"name": "学生作业管理助手-打招呼",
"agent": { "name": "学生作业管理助手" },
"message": "你好",
"expect": {
"status": "completed",
"output_contains": ["作业", "助手"]
}
},
{
"id": "homework-by-id-smoke",
"name": "按 ID 冒烟（请换成你环境真实 UUID）",
"enabled": false,
"agent": { "id": "00000000-0000-0000-0000-000000000000" },
"message": "你好"
},
{
"id": "generic-published-smoke",
"name": "任意已发布 Agent-占位示例",
"enabled": false,
"agent": { "name": "你的Agent名称" },
"message": "你好",
"input_extra": {
"user_id": "preview_script_user",
"attachments": []
},
"expect": {
"status": "completed"
}
}
]
}
```
---
## 6. 常见问题
### 503 / Redis 连接失败
检查 `backend/.env` 中 `REDIS_URL` 端口与本地 Redis 是否一致，并确认 Celery Worker 已启动。
### 401
检查 `username` / `password`；脚本每次运行会重新登录，一般无 token 过期问题。
### 403 Agent 未发布
后端规则：非 `published` / `running` 时，仅 **Agent 所有者**可执行；测试账号需为创建者或使用已发布 Agent。
### 断言失败但人工看回复正常
适当减少 `output_contains` 关键词，或开启 `case_insensitive`；LLM 输出本身可能有波动。
---
## 7. 版本
- 文档与 JSON 格式版本：**1**
- 配套脚本：`run_agent_test_cases.py`（仓库根目录）

233
docs/tests/(红头)工作流调用测试总结.txt Normal file
View File

@@ -0,0 +1,233 @@
================================================================================
工作流调用测试总结
================================================================================
测试时间：2026-01-19
测试场景：Agent工作流执行 - LLM节点"答非所问"问题诊断与修复
================================================================================
一、问题描述
================================================================================
1. 问题现象：
- LLM节点单独测试时能正常回答用户问题
- 整个Agent调用时，LLM返回通用欢迎语，而不是回答用户的具体问题
- 用户输入："苹果英语怎么讲？"
- LLM返回：通用欢迎语 + 最后附加用户问题
2. 工作流结构：
- 开始节点 (start-1) → LLM处理节点 (llm-1) → 结束节点 (end-1)
- LLM节点配置：prompt = "请处理用户请求。"
================================================================================
二、测试方法与工具
================================================================================
1. 执行日志查看脚本：
- 文件：check_execution_logs.py
- 功能：查看最近的Agent执行记录，包括输入数据、输出数据、执行日志
- 使用方法：python3 check_execution_logs.py
2. 数据流转测试脚本：
- 文件：test_workflow_data_flow.py
- 功能：模拟完整工作流执行，详细记录每个节点的输入输出
- 使用方法：python3 test_workflow_data_flow.py
3. 日志查看命令：
- 后端日志：docker-compose -f docker-compose.dev.yml logs --tail=500 backend | grep "\[rjb\]"
- Celery日志：docker-compose -f docker-compose.dev.yml logs --tail=500 celery | grep "\[rjb\]"
================================================================================
三、问题定位过程
================================================================================
1. 数据流转检查：
- 输入数据（正确）：{"query": "苹果英语怎么讲？", "USER_INPUT": "苹果英语怎么讲？"}
- Start节点输出（正确）：{"query": "苹果英语怎么讲？", "USER_INPUT": "苹果英语怎么讲？"}
- LLM节点输入（问题）：从执行日志看，数据被包装成了 {"input": {"query": "...", "USER_INPUT": "..."}}
- LLM节点输出（问题）：返回通用欢迎语，而不是回答用户问题
2. 关键发现：
- 通过添加详细的调试日志（[rjb]标记），发现：
* user_query提取逻辑能正确提取到用户问题
* 但prompt格式化时，通用指令检测可能有问题
* 或者LLM服务接收到的prompt不是格式化后的prompt
3. 日志分析结果：
- 从Celery worker日志中发现：
* user_query正确提取："苹果英语怎么说？"
* 通用指令检测成功：is_generic_instruction=True
* formatted_prompt正确设置为："苹果英语怎么说？"
* 实际发送给DeepSeek的prompt也是："苹果英语怎么说？"
* LLM正确回答："苹果的英语是 **apple**。"
================================================================================
四、问题根因分析
================================================================================
1. 主要问题：
- LLM节点的prompt配置是通用指令"请处理用户请求。"
- 当prompt是通用指令时，应该直接使用用户输入作为prompt
- 但之前的逻辑可能没有正确处理这种情况
2. 数据流转问题：
- get_node_input方法在处理非字典类型的source_output时，会包装成{"input": source_output}
- 这导致LLM节点接收到的输入数据格式为：{"input": "..."}
- user_query提取逻辑需要处理这种嵌套结构
3. End节点问题：
- End节点在提取输出时，会将所有文本字段组合
- 包括query字段，导致最终输出包含用户问题
================================================================================
五、修复方案
================================================================================
1. 修复user_query提取逻辑（backend/app/services/workflow_engine.py）：
- 添加对嵌套input字段的处理
- 优先从嵌套的input中提取query等字段
- 如果嵌套input不存在，从顶层提取
- 支持多层嵌套结构
2. 修复prompt格式化逻辑（backend/app/services/workflow_engine.py）：
- 增强通用指令检测：识别"请处理用户请求。"等通用指令
- 当检测到通用指令时，直接使用user_query作为prompt
- 添加详细的调试日志，记录整个格式化过程
3. 修复End节点输出处理（backend/app/services/workflow_engine.py）：
- 在exclude_keys中添加'query', 'USER_INPUT', 'user_input', 'user_query'
- 优先使用input字段（LLM的实际输出）
- 避免将用户查询字段包含在最终输出中
4. 添加LLM服务调用日志（backend/app/services/llm_service.py）：
- 在DeepSeek API调用前记录实际发送的prompt
- 便于调试和验证prompt是否正确
================================================================================
六、修复后的验证
================================================================================
1. 测试输入：
- 用户问题："苹果英语怎么说？"
- 输入数据：{"query": "苹果英语怎么说？", "USER_INPUT": "苹果英语怎么说？"}
2. 执行日志验证：
[rjb] 开始提取user_query: input_data={'USER_INPUT': '苹果英语怎么说？', 'query': '苹果英语怎么说？'}
[rjb] 从顶层提取: key=query, value=苹果英语怎么说？, value_type=<class 'str'>
[rjb] 提取到字符串user_query: 苹果英语怎么说？
[rjb] 最终提取的user_query: 苹果英语怎么说？
[rjb] 检测到通用指令，直接使用用户输入作为prompt: 苹果英语怎么说？
[rjb] LLM节点prompt格式化: final_prompt前200字符='苹果英语怎么说？'
[rjb] 准备调用LLM: prompt前200字符='苹果英语怎么说？'
[rjb] DeepSeek实际发送的prompt前200字符: 苹果英语怎么说？
3. LLM输出验证：
- LLM正确回答："苹果的英语是 **apple**。"
- 包含发音、例句、相关表达等详细信息
4. End节点输出验证：
- 最终输出只包含LLM的回答内容
- 不再包含用户问题
================================================================================
七、关键代码修改点
================================================================================
1. user_query提取逻辑（第467-525行）：
- 添加嵌套input字段检查
- 支持多层数据提取
- 添加详细的调试日志
2. prompt格式化逻辑（第527-568行）：
- 增强通用指令检测
- 当检测到通用指令时，直接使用user_query作为prompt
- 添加is_generic_instruction变量初始化
3. End节点输出处理（第1780-1799行）：
- 在exclude_keys中添加用户查询相关字段
- 优先使用input字段
- 避免拼接用户问题
4. LLM服务调用日志（backend/app/services/llm_service.py）：
- 在API调用前记录实际发送的prompt
================================================================================
八、测试经验总结
================================================================================
1. 调试方法：
- 使用详细的调试日志（[rjb]标记）追踪数据流转
- 在关键位置添加日志：数据提取、格式化、API调用
- 查看Celery worker日志（工作流在Celery中执行）
2. 问题定位技巧：
- 对比节点测试和完整工作流执行的差异
- 检查数据在节点间的传递格式
- 验证实际发送给LLM的prompt内容
3. 常见问题：
- 数据被包装成嵌套结构（如{"input": {...}}）
- 通用指令没有被正确识别
- End节点输出包含了不应该包含的字段
4. 最佳实践：
- 在LLM节点配置中，如果prompt是通用指令，应该直接使用用户输入
- End节点应该只输出LLM的实际回答，排除用户查询字段
- 添加详细的调试日志，便于问题定位
================================================================================
九、测试工具说明
================================================================================
1. check_execution_logs.py：
- 功能：查看最近的Agent执行记录和详细日志
- 输出：输入数据、输出数据、执行时间线、LLM节点详细分析
- 使用方法：python3 check_execution_logs.py
2. test_workflow_data_flow.py：
- 功能：模拟完整工作流执行，追踪数据流转
- 输出：每个节点的输入输出、数据格式转换过程
- 使用方法：python3 test_workflow_data_flow.py
3. 日志查看脚本（view_logs.sh）：
- 功能：实时查看包含[rjb]标记的调试日志
- 使用方法：./view_logs.sh
================================================================================
十、修复验证结果
================================================================================
✅ 问题1：LLM答非所问
- 状态：已修复
- 验证：LLM能正确回答用户问题
✅ 问题2：End节点输出包含用户问题
- 状态：已修复
- 验证：最终输出只包含LLM的回答
✅ 问题3：数据流转问题
- 状态：已修复
- 验证：数据在节点间正确传递，格式正确
================================================================================
十一、后续建议
================================================================================
1. 节点配置建议：
- 如果LLM节点的prompt是通用指令（如"请处理用户请求。"），系统会自动使用用户输入作为prompt
- 如果需要更具体的指令，可以在prompt中明确说明任务类型
2. 测试建议：
- 使用check_execution_logs.py查看执行日志
- 使用Celery日志查看详细的调试信息
- 在节点配置面板中单独测试节点，对比完整工作流的执行
3. 监控建议：
- 定期检查执行日志，确认数据流转正常
- 关注LLM节点的输入输出，确保prompt格式化正确
- 检查End节点的输出，确保不包含用户查询字段
================================================================================
测试完成时间：2026-01-19 23:55
测试人员：AI Assistant
================================================================================

195
docs/tests/Android日志Agent测试报告.md Normal file
View File

@@ -0,0 +1,195 @@
# Android日志获取助手Agent测试报告
## 📋 测试概述
**测试时间**: 2026-01-23
**测试Agent**: Android日志获取助手
**测试用例**: 列出设备
**执行ID**: `e0dc3dec-b9b0-472d-a309-2d3e11e2e5fc`
---
## ✅ 测试结果
### 1. Agent执行状态 ✅
- **执行状态**: `completed`
- **执行时间**: 约21秒
- **Agent状态**: `published`（已发布）
### 2. 工作流执行流程 ✅
1. **开始节点**: ✅ 正常接收输入
2. **意图识别节点**: ✅ 识别了用户意图（列出设备）
3. **JSON解析节点**: ✅ 解析了意图识别结果
4. **LLM工具调用节点**: ✅ 执行完成
5. **结束节点**: ✅ 返回结果
### 3. 输出结果 ✅
Agent成功返回了设备列表信息：
- 检测到1个Android设备：`emulator-5554`（模拟器）
- 设备状态：`device`（已连接且正常运行）
---
## 🔍 工具调用分析
### 配置检查
**Agent工作流配置**:
- ✅ `enable_tools`: `True`
- ✅ `selected_tools`: `['adb_log']`
- ⚠️ `tools`: `[]`（空数组）
**问题发现**:
- 工作流引擎读取的是 `tools` 字段，但Agent配置使用的是 `selected_tools`
- **已修复**: 工作流引擎现在同时支持 `tools` 和 `selected_tools` 字段
### 工具调用日志
**检查结果**:
- ⚠️ 未在API响应中找到工具调用详细日志
- 可能原因：
1. LLM可能返回了文本描述而不是实际的tool_call
2. 工具调用日志可能记录在更深层的执行中
3. 需要在前端验证工具调用可视化
---
## 📊 测试详情
### 输入
```json
{
"query": "列出设备"
}
```
### 输出
Agent返回了详细的设备列表信息，包括：
- 设备连接状态
- 设备类型（模拟器/物理设备）
- 设备ID
- 建议操作
### 执行日志
- 总日志数: 16条
- 节点执行: 正常
- 工具调用日志: 需要前端验证
---
## 🎯 下一步验证
### 1. 前端可视化验证（优先）
**操作步骤**:
1. 打开执行详情页面:
```
http://localhost:8038/executions/e0dc3dec-b9b0-472d-a309-2d3e11e2e5fc
```
2. 查看节点执行详情:
- 点击 `llm-with-tools` 节点
- 打开节点执行详情抽屉
- 检查"工具调用"卡片是否显示
3. 验证工具调用可视化:
- ✅ 工具调用时间线是否正确显示
- ✅ 工具名称、参数、结果是否可查看
- ✅ 工具调用状态是否正确
### 2. 后端日志深度检查
**检查数据库日志**:
```sql
SELECT * FROM execution_logs
WHERE execution_id = 'e0dc3dec-b9b0-472d-a309-2d3e11e2e5fc'
AND data LIKE '%tool_name%'
```
### 3. 强制工具调用测试
创建一个更明确的测试用例，确保LLM会调用工具:
```bash
python3 test_workflow_tool.py -a "Android日志获取助手" -i '{"query": "请使用adb_log工具列出所有连接的设备，必须调用工具"}'
```
---
## 🔧 已修复问题
### 1. 工具配置字段不一致 ✅
**问题**: 工作流引擎读取 `tools` 字段，但Agent配置使用 `selected_tools`
**修复**:
- 修改 `workflow_engine.py`
- 现在同时支持 `tools` 和 `selected_tools` 字段
**代码**:
```python
# 支持两种字段名：tools 和 selected_tools
tools_config = node_data.get('tools') or node_data.get('selected_tools') or []
```
---
## 💡 测试建议
### 测试用例1: 列出设备 ✅
**输入**: `{"query": "列出设备"}`
**结果**: ✅ 成功
- Agent正确识别了意图
- 返回了设备列表信息
### 测试用例2: 获取错误日志（建议）
**输入**: `{"query": "获取最近的错误日志"}`
**预期**:
- LLM调用 `adb_log` 工具
- 工具执行 `adb logcat -d *:E -t 100`
- 返回错误日志内容
### 测试用例3: 获取特定标签日志（建议）
**输入**: `{"query": "获取ActivityManager的日志"}`
**预期**:
- LLM调用 `adb_log` 工具
- 工具执行 `adb logcat -d ActivityManager -t 100`
- 返回ActivityManager日志
---
## 📝 总结
### ✅ 成功项
1. **Agent执行**: ✅ 工作流正常执行
2. **意图识别**: ✅ 正确识别用户意图
3. **结果返回**: ✅ 返回了有用的信息
4. **配置修复**: ✅ 修复了工具配置字段不一致问题
### ⚠️ 待验证项
1. **工具调用日志**: 需要前端验证工具调用可视化
2. **实际工具执行**: 需要确认LLM是否实际调用了工具
3. **工具调用可视化**: 需要在前端验证显示效果
### 🎯 建议
1. **优先验证前端可视化**: 打开执行详情页面，检查工具调用可视化是否正确显示
2. **测试更多用例**: 尝试不同的查询，验证工具调用的稳定性
3. **检查日志记录**: 如果前端未显示，检查后端日志记录逻辑
---
**测试完成时间**: 2026-01-23
**测试人员**: AI Assistant
**文档版本**: v1.0

163
docs/tests/DeepSeek测试报告.md Normal file
View File

@@ -0,0 +1,163 @@
# DeepSeek集成测试报告
## 📊 测试结果
**测试时间**: 2024年
**测试状态**: ✅ **全部通过 (5/5)**
---
## ✅ 测试详情
### 测试1: 直接调用DeepSeek API
- **状态**: ✅ 通过
- **测试内容**: 直接调用DeepSeek API，测试基础功能
- **结果**: 成功返回响应
- **响应示例**: "人工智能是让机器模拟人类智能以执行复杂任务并自主优化决策的技术。"
### 测试2: 通过LLM服务通用接口调用DeepSeek
- **状态**: ✅ 通过
- **测试内容**: 通过统一的LLM服务接口调用DeepSeek
- **结果**: 成功调用并返回结果
- **响应示例**: "Hello, world" (翻译测试)
### 测试3: 测试DeepSeek Coder模型
- **状态**: ✅ 通过
- **测试内容**: 测试DeepSeek Coder代码生成能力
- **结果**: 成功生成完整的Python代码
- **响应**: 生成了多个版本的斐波那契数列计算函数，包括：
- 递归版本
- 动态规划版本
- 记忆化搜索版本
- 矩阵快速幂版本
- 完整的示例和使用说明
### 测试4: 测试工作流引擎中的LLM节点
- **状态**: ✅ 通过
- **测试内容**: 在工作流引擎中执行包含DeepSeek节点的完整工作流
- **工作流结构**: 开始 → LLM节点(DeepSeek) → 结束
- **结果**: 工作流执行成功，数据正确传递
- **功能验证**:
- ✅ DAG构建正常
- ✅ 节点执行正常
- ✅ 数据流传递正常
- ✅ DeepSeek节点调用成功
### 测试5: 测试Prompt模板变量替换
- **状态**: ✅ 通过
- **测试内容**: 测试Prompt模板中的变量替换功能
- **结果**: 变量替换成功，DeepSeek正确理解并响应
- **功能验证**:
- ✅ 变量替换正常 (`{user_input}`)
- ✅ Prompt格式化正确
- ✅ DeepSeek理解上下文
---
## 🎯 功能验证清单
### 基础功能
- [x] DeepSeek API Key配置正确
- [x] DeepSeek客户端初始化成功
- [x] 直接API调用正常
- [x] 通过服务接口调用正常
### 模型支持
- [x] DeepSeek Chat模型正常工作
- [x] DeepSeek Coder模型正常工作
- [x] 模型参数（temperature）生效
### 工作流集成
- [x] LLM节点在工作流中正常工作
- [x] 节点间数据传递正确
- [x] 工作流执行引擎正常
- [x] 多节点工作流支持
### Prompt处理
- [x] Prompt模板变量替换
- [x] 输入数据格式化
- [x] 复杂Prompt处理
---
## 📈 性能表现
### 响应速度
- DeepSeek Chat: 响应迅速，通常在2-5秒内返回结果
- DeepSeek Coder: 代码生成完整，响应时间合理
### 响应质量
- **文本处理**: 准确理解中文，响应自然流畅
- **代码生成**: 生成的代码质量高，包含详细注释和多种实现方式
- **上下文理解**: 能够正确理解Prompt中的变量和上下文
---
## 🔍 测试用例详情
### 用例1: 简单文本处理
```
输入: "请用一句话介绍人工智能"
输出: "人工智能是让机器模拟人类智能以执行复杂任务并自主优化决策的技术。"
```
### 用例2: 翻译功能
```
输入: "请将以下文本翻译成英文：你好，世界"
输出: "Hello, world"
```
### 用例3: 代码生成
```
输入: "请用Python编写一个函数，计算斐波那契数列的第n项"
输出: 完整的Python代码，包含多种实现方式和详细说明
```
### 用例4: 内容总结
```
输入: "人工智能是计算机科学的一个分支，它试图理解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器。"
输出: "人工智能是计算机科学的分支，旨在**理解智能本质**并开发能够**模拟人类智能行为**的机器。其核心目标是使机器具备类似人类的感知、推理、学习与反应能力。"
```
### 用例5: 对话交互
```
输入: "用户说：你好，请介绍一下自己，请回复："
输出: 详细的自我介绍，包含功能特点、使用方式等
```
---
## ✅ 结论
### 集成状态
- **DeepSeek API集成**: ✅ 完全正常
- **工作流引擎集成**: ✅ 完全正常
- **前端配置支持**: ✅ 已实现（提供商选择、模型选择）
### 可用功能
1. ✅ 可以在工作流中使用DeepSeek模型
2. ✅ 支持DeepSeek Chat和DeepSeek Coder两种模型
3. ✅ 支持Prompt模板和变量替换
4. ✅ 支持自定义温度、最大Token等参数
5. ✅ 错误处理正常
### 建议
1. ✅ 可以开始在实际工作流中使用DeepSeek
2. ✅ 建议测试更复杂的工作流场景
3. ✅ 可以对比不同模型的输出效果
4. ✅ 可以测试多节点工作流的数据传递
---
## 🚀 下一步
1. **前端测试**: 在浏览器中创建工作流并执行测试
2. **复杂场景**: 测试多节点、条件分支等复杂工作流
3. **性能优化**: 测试并发执行、长时间运行等场景
4. **WebSocket测试**: 测试执行状态的实时推送
---
**测试完成时间**: 2024年
**测试结果**: ✅ **全部通过**
**系统状态**: ✅ **可以投入使用**

42
docs/tests/agent_test_cases.example.json Normal file
View File

@@ -0,0 +1,42 @@
{
"version": 1,
"defaults": {
"base_url": "http://localhost:8037",
"username": "admin",
"password": "123456",
"request_timeout_sec": 120,
"max_wait_sec": 300,
"poll_interval_sec": 2
},
"cases": [
{
"id": "homework-hello",
"name": "学生作业管理助手-打招呼",
"agent": { "name": "学生作业管理助手" },
"message": "你好",
"expect": {
"status": "completed",
"output_contains": ["作业", "助手"]
}
},
{
"id": "homework-by-id-smoke",
"name": "按 ID 冒烟（请换成你环境真实 UUID）",
"enabled": false,
"agent": { "id": "00000000-0000-0000-0000-000000000000" },
"message": "你好"
},
{
"id": "generic-with-preview-fields",
"name": "带预览扩展字段示例（与前端一致时可开）",
"enabled": false,
"agent": { "name": "你的Agent名称" },
"message": "你好",
"input_extra": {
"user_id": "preview_script_user",
"attachments": []
},
"expect": { "status": "completed" }
}
]
}

121
docs/tests/test_node_input_output.md Normal file
View File

@@ -0,0 +1,121 @@
# 工作流数据流转测试方案
## 问题描述
工作流能执行完成，但LLM节点输出"答非所问"，可能是数据在节点间传递时被错误处理。
## 测试步骤
### 方法1: 使用测试脚本（推荐）
1. **运行测试脚本**：
```bash
cd /home/renjianbo/aiagent
python3 test_workflow_data_flow.py
```
2. **观察输出**：
- 查看每个节点的输入数据
- 特别关注LLM节点的输入数据格式
- 检查是否有嵌套的`{"input": {...}}`结构
### 方法2: 查看执行日志数据库
1. **查询最近的执行记录**：
```sql
SELECT id, input_data, output_data, status, execution_time
FROM executions
WHERE agent_id IS NOT NULL
ORDER BY created_at DESC
LIMIT 1;
```
2. **查询节点执行日志**：
```sql
SELECT node_id, node_type, level, message, data, timestamp
FROM execution_logs
WHERE execution_id = 'YOUR_EXECUTION_ID'
ORDER BY timestamp ASC;
```
### 方法3: 添加临时调试代码
在 `backend/app/services/workflow_engine.py` 的 `get_node_input` 方法中添加：
```python
# 在方法开始处
if node_id == 'llm-1': # 你的LLM节点ID
import json
print(f"[DEBUG] get_node_input for {node_id}")
print(f"[DEBUG] node_outputs: {json.dumps(node_outputs, ensure_ascii=False, indent=2)}")
print(f"[DEBUG] source_output: {json.dumps(node_outputs.get('start-1', {}), ensure_ascii=False, indent=2)}")
```
在 `execute_node` 方法的LLM节点处理部分添加：
```python
# 在格式化prompt之前
if node_type == 'llm':
import json
print(f"[DEBUG] LLM节点输入: {json.dumps(input_data, ensure_ascii=False, indent=2)}")
print(f"[DEBUG] 原始prompt: {prompt}")
print(f"[DEBUG] user_query提取结果: {user_query}")
print(f"[DEBUG] 最终formatted_prompt: {formatted_prompt}")
```
然后重启后端并测试：
```bash
docker-compose -f docker-compose.dev.yml restart backend
```
### 方法4: 使用浏览器开发者工具
1. 打开浏览器开发者工具（F12）
2. 切换到 Network 标签
3. 执行一次测试
4. 查看请求：
- `POST /api/v1/executions` - 查看发送的 `input_data`
5. 查看响应：
- `GET /api/v1/executions/{id}/status` - 查看执行状态
- `GET /api/v1/executions/{id}` - 查看执行结果
## 关键检查点
### 1. Start节点输出
- **期望**: `{"query": "苹果英语怎么讲?", "USER_INPUT": "苹果英语怎么讲?"}`
- **实际**: 检查是否被包装成 `{"input": {...}}` 或其他格式
### 2. LLM节点输入
- **期望**: 直接从start节点获取，格式为 `{"query": "...", "USER_INPUT": "..."}`
- **实际**: 检查 `get_node_input` 返回的数据格式
### 3. user_query提取
- **期望**: 能正确提取到 "苹果英语怎么讲?"
- **实际**: 检查提取逻辑是否正确处理嵌套结构
### 4. Prompt格式化
- **期望**: 如果是通用指令"请处理用户请求。"，应该直接使用user_query作为prompt
- **实际**: 检查最终的formatted_prompt内容
## 预期问题位置
根据图片分析，输入数据可能是：
```json
{
"input": {
"query": "苹果英语怎么讲?",
"USER_INPUT": "苹果英语怎么讲?"
}
}
```
这可能是以下原因导致的：
1. `get_node_input` 方法在某个分支将数据包装成了 `{"input": ...}`
2. `start` 节点的输出被错误保存
3. 数据在节点间传递时被错误处理
## 修复建议
如果发现数据被包装成 `{"input": {...}}`，需要：
1. 在 `get_node_input` 中正确处理嵌套的 `input` 字段
2. 确保 `user_query` 提取逻辑能处理这种嵌套结构
3. 确保prompt格式化逻辑能正确使用提取的 `user_query`

292
docs/tests/前端测试邮件和消息队列节点.md Normal file
View File

@@ -0,0 +1,292 @@
# 前端测试邮件和消息队列节点
## 🎯 快速测试指南
由于后端服务已经在运行，您可以直接在前端界面测试新实现的邮件节点和消息队列节点。
## 📧 测试邮件节点
### 步骤1: 创建工作流
1. 登录系统: http://101.43.95.130:8038
2. 点击"工作流管理"
3. 点击"创建新工作流"
### 步骤2: 添加节点
1. **添加开始节点**
- 从左侧工具箱拖拽"开始"节点到画布
2. **添加邮件节点**
- 从左侧工具箱拖拽"邮件"节点到画布
- 连接开始节点到邮件节点
3. **添加结束节点**
- 从左侧工具箱拖拽"结束"节点到画布
- 连接邮件节点到结束节点
### 步骤3: 配置邮件节点
点击邮件节点，在右侧配置面板中填写：
#### 基础配置
- **SMTP服务器**: `smtp.gmail.com` (或使用测试服务如 `smtp.mailtrap.io`)
- **SMTP端口**: `587`
- **SMTP用户名**: 您的邮箱地址
- **SMTP密码**: 应用专用密码（Gmail需要）
- **使用TLS**: ✅ 开启
#### 邮件内容
- **发件人邮箱**: `your-email@gmail.com`
- **收件人邮箱**: `recipient@example.com`
- **邮件主题**: `测试邮件 - {test_key}`
- **邮件正文类型**: `纯文本` 或 `HTML`
- **邮件正文**:
```
这是一封测试邮件。
测试数据: {test_data}
时间: {timestamp}
```
#### 变量替换示例
邮件节点支持变量替换，使用 `{key}` 或 `${key}` 格式：
- `{test_key}` - 从输入数据中获取 `test_key` 的值
- `{test_data}` - 从输入数据中获取 `test_data` 的值
### 步骤4: 保存并运行
1. 点击工具栏的"保存"按钮
2. 点击"运行"按钮
3. 在运行对话框中输入测试数据：
```json
{
"test_key": "Hello World",
"test_data": "这是测试数据",
"timestamp": "2024-01-01 12:00:00"
}
```
4. 点击"开始运行"
5. 查看执行结果和执行日志
### 步骤5: 验证结果
- ✅ 检查执行状态是否为"成功"
- ✅ 查看执行日志，确认邮件发送成功
- ✅ 检查收件箱，确认收到邮件
- ✅ 验证邮件主题和正文中的变量是否正确替换
## 🐰 测试RabbitMQ消息队列节点
### 前置条件
确保RabbitMQ服务正在运行：
```bash
# 使用Docker启动RabbitMQ
docker run -d \
--name rabbitmq \
-p 5672:5672 \
-p 15672:15672 \
-e RABBITMQ_DEFAULT_USER=admin \
-e RABBITMQ_DEFAULT_PASS=admin123 \
rabbitmq:3-management
```
访问管理界面: http://localhost:15672
### 步骤1-2: 创建工作流并添加节点
1. 添加开始节点
2. 添加"消息队列"节点
3. 添加结束节点
4. 连接节点
### 步骤3: 配置消息队列节点
点击消息队列节点，在右侧配置面板中：
1. **选择队列类型**: `RabbitMQ`
2. **RabbitMQ配置**:
- **主机地址**: `localhost` (或服务器IP)
- **端口**: `5672`
- **用户名**: `admin` (或您的RabbitMQ用户名)
- **密码**: `admin123` (或您的RabbitMQ密码)
- **队列名称**: `test_queue`
- **Routing Key**: `test.routing.key` (可选)
- **Exchange**: (可选，如果使用Exchange)
3. **消息内容**:
```json
{
"test_key": "{test_key}",
"test_data": "{test_data}",
"timestamp": "{timestamp}"
}
```
### 步骤4: 保存并运行
1. 保存工作流
2. 运行工作流，输入测试数据：
```json
{
"test_key": "Hello RabbitMQ",
"test_data": "这是测试数据",
"timestamp": "2024-01-01 12:00:00"
}
```
3. 查看执行结果
### 步骤5: 验证结果
1. 访问RabbitMQ管理界面: http://localhost:15672
2. 登录后，进入"Queues"标签
3. 找到 `test_queue` 队列
4. 点击队列名称，查看消息
5. 确认消息内容正确，变量已替换
## 📨 测试Kafka消息队列节点
### 前置条件
确保Kafka服务正在运行（需要Zookeeper）：
```bash
# 使用Docker Compose启动Kafka
# 创建 docker-compose-kafka.yml 文件
```
### 步骤1-2: 创建工作流并添加节点
1. 添加开始节点
2. 添加"消息队列"节点
3. 添加结束节点
4. 连接节点
### 步骤3: 配置Kafka节点
点击消息队列节点，在右侧配置面板中：
1. **选择队列类型**: `Kafka`
2. **Kafka配置**:
- **Bootstrap Servers**: `localhost:9092` (多个服务器用逗号分隔)
- **Topic**: `test_topic`
3. **消息内容**:
```json
{
"test_key": "{test_key}",
"test_data": "{test_data}",
"timestamp": "{timestamp}"
}
```
### 步骤4: 保存并运行
1. 保存工作流
2. 运行工作流，输入测试数据
3. 查看执行结果
### 步骤5: 验证结果
使用Kafka消费者工具查看消息：
```bash
# 使用kafka-console-consumer
kafka-console-consumer --bootstrap-server localhost:9092 --topic test_topic --from-beginning
```
## 🔍 测试检查清单
### 邮件节点
- [ ] 节点可以正常添加到画布
- [ ] 配置面板所有字段正常显示
- [ ] 保存配置成功
- [ ] 工作流执行成功
- [ ] 邮件成功发送
- [ ] 变量替换正确（主题和正文）
- [ ] HTML格式邮件正确渲染（如果使用HTML）
- [ ] 执行日志显示详细信息
### 消息队列节点
- [ ] 节点可以正常添加到画布
- [ ] 可以切换队列类型（RabbitMQ/Kafka）
- [ ] 配置面板根据队列类型显示不同字段
- [ ] 保存配置成功
- [ ] 工作流执行成功
- [ ] 消息成功发送到队列/Topic
- [ ] 变量替换正确
- [ ] 执行日志显示详细信息
## 🐛 常见问题排查
### 邮件节点问题
1. **SMTP连接失败**
- 检查SMTP服务器地址和端口
- 确认网络连接正常
- 检查防火墙设置
2. **认证失败**
- Gmail需要使用应用专用密码，不是普通密码
- 确认账号已启用"允许不够安全的应用"
- 检查用户名和密码是否正确
3. **变量未替换**
- 确认输入数据中包含对应的key
- 检查变量格式：`{key}` 或 `${key}`
- 查看执行日志确认输入数据
### 消息队列节点问题
1. **RabbitMQ连接失败**
- 确认RabbitMQ服务正在运行
- 检查主机地址和端口
- 确认用户名和密码正确
- 检查网络连接
2. **Kafka连接失败**
- 确认Kafka服务正在运行
- 检查Bootstrap Servers配置
- 确认Topic已创建
- 检查网络连接
3. **消息未发送**
- 查看执行日志中的错误信息
- 检查节点配置是否正确
- 确认队列/Topic存在
## 📝 测试数据示例
### 邮件节点测试数据
```json
{
"test_key": "Hello World",
"test_data": "这是测试数据",
"timestamp": "2024-01-01 12:00:00",
"user_name": "测试用户",
"order_id": "12345"
}
```
### 消息队列节点测试数据
```json
{
"test_key": "Hello Queue",
"test_data": "这是测试数据",
"timestamp": "2024-01-01 12:00:00",
"event_type": "user_action",
"user_id": "12345"
}
```
## 🎯 下一步
测试通过后，您可以：
1. 在实际工作流中使用这些节点
2. 继续开发其他功能
3. 优化节点功能和用户体验
---
**提示**: 如果遇到问题，请查看执行详情页面的日志信息，那里会显示详细的错误信息。

372
docs/tests/前端界面测试指南-邮件和消息队列节点.md Normal file
View File

@@ -0,0 +1,372 @@
# 前端界面测试指南 - 邮件和消息队列节点
## 🎯 测试目标
在前端界面中测试新实现的邮件节点和消息队列节点，验证：
1. 节点在工具箱中正确显示
2. 节点可以拖拽到画布
3. 节点配置面板正确显示
4. 节点配置可以保存
5. 工作流可以执行
## 📋 前置条件
1. **前端服务运行**: http://101.43.95.130:8038
2. **后端服务运行**: http://101.43.95.130:8037
3. **用户已登录**
## 🚀 测试步骤
### 步骤1: 登录系统
1. 打开浏览器，访问: **http://101.43.95.130:8038**
2. 如果未登录，使用测试账号登录：
- 用户名: `test_user`
- 密码: `test_password123`
- 或使用您自己的账号
### 步骤2: 进入工作流设计器
1. 在首页点击"工作流管理"
2. 点击"创建新工作流"按钮
3. 或点击现有工作流的"设计"按钮
### 步骤3: 测试邮件节点
#### 3.1 添加邮件节点
1. **查看左侧节点工具箱**
- 应该能看到"邮件"节点（带有Message图标）
- 位置：在"Webhook"节点之后，"输出"节点之前
2. **拖拽邮件节点到画布**
- 从左侧工具箱拖拽"邮件"节点
- 放到画布中央位置
- 节点应该成功添加到画布
3. **连接节点**
- 如果画布中有"开始"节点，连接开始节点到邮件节点
- 如果没有开始节点，先添加一个开始节点
- 添加"结束"节点，连接邮件节点到结束节点
#### 3.2 配置邮件节点
1. **点击邮件节点**，右侧应该显示配置面板
2. **检查配置项**，应该看到以下字段：
- ✅ SMTP服务器
- ✅ SMTP端口
- ✅ SMTP用户名
- ✅ SMTP密码（密码输入框）
- ✅ 使用TLS（开关）
- ✅ 发件人邮箱
- ✅ 收件人邮箱
- ✅ 抄送邮箱（可选）
- ✅ 密送邮箱（可选）
- ✅ 邮件主题
- ✅ 邮件正文类型（下拉选择：纯文本/HTML）
- ✅ 邮件正文（多行文本）
- ✅ 附件（可选，JSON格式）
3. **填写测试配置**：
```
SMTP服务器: smtp.gmail.com
SMTP端口: 587
SMTP用户名: your-email@gmail.com
SMTP密码: [您的应用专用密码]
使用TLS: ✅ 开启
发件人邮箱: your-email@gmail.com
收件人邮箱: recipient@example.com
邮件主题: 测试邮件 - {test_key}
邮件正文类型: 纯文本
邮件正文:
这是一封测试邮件。
测试数据: {test_data}
时间: {timestamp}
```
4. **测试变量替换提示**
- 在主题和正文中使用 `{test_key}`, `{test_data}`, `{timestamp}`
- 应该看到提示信息说明支持变量替换
5. **保存节点配置**
- 点击"保存配置"按钮
- 应该看到"节点配置已保存"的提示
#### 3.3 保存工作流
1. 点击工具栏的"保存"按钮
2. 应该看到"工作流已保存"的提示
3. 工作流名称会自动生成或可以手动编辑
#### 3.4 运行工作流
1. **点击"运行"按钮**
2. **在运行对话框中输入测试数据**：
```json
{
"test_key": "Hello World",
"test_data": "这是测试数据",
"timestamp": "2024-01-01 12:00:00"
}
```
3. **点击"开始运行"**
4. **查看执行结果**：
- 执行状态应该显示为"运行中"或"已完成"
- 如果配置了真实的SMTP服务器，邮件应该成功发送
- 如果未配置，会显示连接错误（这是正常的）
### 步骤4: 测试消息队列节点（RabbitMQ）
#### 4.1 添加消息队列节点
1. **查看左侧节点工具箱**
- 应该能看到"消息队列"节点（带有Connection图标）
- 位置：在"邮件"节点之后
2. **拖拽消息队列节点到画布**
- 从左侧工具箱拖拽"消息队列"节点
- 放到画布上
3. **连接节点**
- 连接开始节点到消息队列节点
- 连接消息队列节点到结束节点
#### 4.2 配置消息队列节点
1. **点击消息队列节点**，右侧应该显示配置面板
2. **选择队列类型**
- 下拉选择"RabbitMQ"或"Kafka"
- 选择后，配置面板会显示对应的配置项
3. **RabbitMQ配置项**（选择RabbitMQ时）：
- ✅ 主机地址
- ✅ 端口
- ✅ 用户名
- ✅ 密码（密码输入框）
- ✅ Exchange（可选）
- ✅ Routing Key
- ✅ 队列名称
- ✅ 消息内容（JSON格式）
4. **填写RabbitMQ测试配置**：
```
队列类型: RabbitMQ
主机地址: localhost
端口: 5672
用户名: guest
密码: guest
队列名称: test_queue
Routing Key: test.routing.key
消息内容:
{
"test_key": "{test_key}",
"test_data": "{test_data}",
"timestamp": "{timestamp}"
}
```
5. **保存节点配置**
#### 4.3 测试Kafka配置
1. **切换队列类型为Kafka**
- 配置面板会显示Kafka相关配置
2. **Kafka配置项**：
- ✅ Bootstrap Servers
- ✅ Topic
- ✅ 消息内容（JSON格式）
3. **填写Kafka测试配置**：
```
队列类型: Kafka
Bootstrap Servers: localhost:9092
Topic: test_topic
消息内容:
{
"test_key": "{test_key}",
"test_data": "{test_data}",
"timestamp": "{timestamp}"
}
```
4. **保存节点配置**
#### 4.4 保存并运行工作流
1. 保存工作流
2. 运行工作流，输入测试数据：
```json
{
"test_key": "Hello Queue",
"test_data": "这是测试数据",
"timestamp": "2024-01-01 12:00:00"
}
```
3. 查看执行结果
## ✅ 测试检查清单
### 邮件节点测试
- [ ] 节点在工具箱中显示（"邮件"节点）
- [ ] 节点可以拖拽到画布
- [ ] 节点配置面板正确显示所有配置项
- [ ] 可以填写和修改配置
- [ ] 配置可以保存
- [ ] 工作流可以保存
- [ ] 工作流可以运行
- [ ] 变量替换提示正确显示
- [ ] HTML格式选项可以切换
### 消息队列节点测试
- [ ] 节点在工具箱中显示（"消息队列"节点）
- [ ] 节点可以拖拽到画布
- [ ] 队列类型可以切换（RabbitMQ/Kafka）
- [ ] RabbitMQ配置项正确显示
- [ ] Kafka配置项正确显示
- [ ] 配置可以保存
- [ ] 工作流可以保存
- [ ] 工作流可以运行
- [ ] 变量替换提示正确显示
### 通用测试
- [ ] 节点可以连接（连线功能）
- [ ] 节点可以删除
- [ ] 节点可以复制粘贴
- [ ] 画布缩放功能正常
- [ ] 保存状态提示正常
## 🐛 常见问题排查
### 问题1: 节点在工具箱中不显示
**可能原因**:
- 前端代码未更新
- 浏览器缓存问题
**解决方法**:
1. 刷新浏览器（Ctrl+F5 强制刷新）
2. 检查浏览器控制台是否有错误
3. 确认前端服务已重启
### 问题2: 配置面板不显示
**可能原因**:
- 节点未正确选中
- 配置面板被隐藏
**解决方法**:
1. 点击节点确保选中（节点应该高亮）
2. 检查右侧配置面板是否可见
3. 尝试刷新页面
### 问题3: 配置无法保存
**可能原因**:
- 后端API错误
- 网络连接问题
**解决方法**:
1. 检查浏览器控制台的网络请求
2. 查看是否有错误信息
3. 检查后端服务是否正常运行
### 问题4: 工作流执行失败
**可能原因**:
- 未配置真实的SMTP/RabbitMQ/Kafka服务器
- 配置信息错误
- 网络连接问题
**解决方法**:
1. 检查执行详情页面的错误信息
2. 确认外部服务配置正确
3. 查看执行日志了解详细错误
## 📸 预期界面效果
### 节点工具箱
左侧应该显示以下节点（按顺序）：
- 开始
- 输入
- LLM
- 条件
- 转换
- 循环
- Agent
- HTTP请求
- 数据库
- 文件操作
- 定时任务
- Webhook
- **邮件** ← 新节点
- **消息队列** ← 新节点
- 输出
- 结束
### 邮件节点配置面板
右侧配置面板应该显示：
- 标题："节点配置"
- 节点ID（只读）
- 节点类型（只读）
- 节点名称
- SMTP配置区域
- 邮件内容配置区域
- 附件配置区域
- 保存/复制/删除按钮
### 消息队列节点配置面板
右侧配置面板应该显示：
- 队列类型选择（下拉）
- RabbitMQ配置区域（选择RabbitMQ时）
- Kafka配置区域（选择Kafka时）
- 消息内容配置区域
- 保存/复制/删除按钮
## 🎯 测试数据示例
### 邮件节点测试数据
```json
{
"test_key": "Hello World",
"test_data": "这是测试数据",
"timestamp": "2024-01-01 12:00:00",
"user_name": "测试用户",
"order_id": "12345"
}
```
### 消息队列节点测试数据
```json
{
"test_key": "Hello Queue",
"test_data": "这是测试数据",
"timestamp": "2024-01-01 12:00:00",
"event_type": "user_action",
"user_id": "12345"
}
```
## 📝 测试记录
测试时请记录：
1. 测试时间
2. 测试环境（浏览器、操作系统）
3. 测试结果（通过/失败）
4. 遇到的问题
5. 截图（如果有）
## 🎉 测试完成
测试通过后，您可以：
1. 在实际工作流中使用这些节点
2. 配置真实的SMTP/RabbitMQ/Kafka服务器进行实际测试
3. 继续开发其他功能
---
**测试指南版本**: v1.0
**最后更新**: 2024年1月17日

201
docs/tests/执行功能测试报告.md Normal file
View File

@@ -0,0 +1,201 @@
# 执行功能测试报告
## 📊 测试结果
**测试时间**: 2024年
**测试状态**: ✅ **全部通过 (2/2)**
---
## ✅ 测试详情
### 测试1: 执行功能测试 ✅
#### 测试内容
- 创建工作流执行记录
- 使用DeepSeek执行工作流
- 更新执行状态和结果
- 获取执行记录列表
#### 测试结果
- ✅ 成功创建执行记录
- ✅ 成功执行工作流（使用DeepSeek）
- ✅ DeepSeek API调用成功
- ✅ 工作流执行完成，返回正确结果
- ✅ 执行记录状态正确更新为 `completed`
- ✅ 输出数据正确保存
- ✅ 执行记录列表查询正常
#### 执行详情
```
输入: "人工智能是计算机科学的一个分支"
输出: "人工智能是计算机科学中致力于创建能够模拟人类智能行为的系统的分支。"
执行时间: 约2秒（包含DeepSeek API调用）
状态: completed
```
#### 工作流执行流程
1. **开始节点** → 接收输入数据 ✅
2. **LLM节点（DeepSeek）** → 处理并返回结果 ✅
3. **结束节点** → 输出最终结果 ✅
### 测试2: 执行模型测试 ✅
#### 测试内容
- 验证执行模型字段完整性
- 验证数据类型正确性
- 验证created_at字段类型
#### 测试结果
- ✅ 所有必需字段存在
- ✅ 数据类型正确
- ✅ `created_at` 字段类型为 `datetime`（符合API响应要求）
- ✅ 输入输出数据格式正确
#### 字段验证
- ✅ `id`: str
- ✅ `workflow_id`: str
- ✅ `status`: str
- ✅ `input_data`: dict
- ✅ `output_data`: dict
- ✅ `execution_time`: int
- ✅ `created_at`: datetime
---
## 🎯 功能验证
### 1. 执行记录创建 ✅
- 可以成功创建执行记录
- 输入数据正确保存
- 初始状态为 `pending`
### 2. 工作流执行 ✅
- 工作流引擎正常工作
- DeepSeek节点调用成功
- 数据在节点间正确传递
- 执行结果正确返回
### 3. 执行状态更新 ✅
- 状态从 `pending` 更新为 `completed`
- 输出数据正确保存
- 执行时间正确记录
### 4. 执行记录查询 ✅
- 可以查询执行记录列表
- 可以按工作流ID筛选
- 可以获取执行详情
### 5. 数据格式 ✅
- JSON数据正确序列化和反序列化
- `created_at` 字段类型正确（datetime）
- 输入输出数据格式正确
---
## 📈 性能表现
### 执行速度
- **工作流执行**: 约2秒（包含DeepSeek API调用）
- **数据库操作**: 毫秒级响应
- **整体性能**: 良好
### DeepSeek API调用
- **响应时间**: 约2秒
- **调用成功**: ✅
- **结果质量**: 高（准确理解并处理了输入）
---
## 🔍 测试用例详情
### 用例1: 简单工作流执行
```
工作流结构:
开始 → LLM节点(DeepSeek) → 结束
输入: {"input": "人工智能是计算机科学的一个分支"}
输出: {"result": {"input": "人工智能是计算机科学中致力于创建能够模拟人类智能行为的系统的分支。"}}
状态: completed
```
### 用例2: 执行记录查询
```
查询条件: workflow_id
结果: 成功返回2条执行记录
排序: 按创建时间倒序
```
---
## ✅ 结论
### 功能状态
- **执行记录创建**: ✅ 完全正常
- **工作流执行**: ✅ 完全正常
- **DeepSeek集成**: ✅ 完全正常
- **数据存储**: ✅ 完全正常
- **数据查询**: ✅ 完全正常
### 可用功能
1. ✅ 可以创建执行记录
2. ✅ 可以执行工作流（使用DeepSeek）
3. ✅ 可以查询执行记录列表
4. ✅ 可以获取执行详情
5. ✅ 执行状态正确更新
6. ✅ 数据格式正确
### 前端功能
- ✅ 执行历史列表页面已实现
- ✅ 执行详情页面已实现
- ✅ WebSocket实时推送已实现
- ✅ 路由配置已完成
---
## 📝 测试建议
### 前端测试
1. **执行历史列表**:
- [ ] 访问 `/executions` 查看执行记录
- [ ] 测试筛选功能
- [ ] 测试分页功能
2. **执行详情页面**:
- [ ] 查看已完成执行的详情
- [ ] 查看输入输出数据格式
- [ ] 测试WebSocket实时更新
3. **WebSocket测试**:
- [ ] 执行工作流时打开详情页面
- [ ] 观察实时状态更新
- [ ] 观察进度条变化
- [ ] 测试连接断开和重连
### 集成测试
1. **完整流程测试**:
- [ ] 创建工作流
- [ ] 执行工作流
- [ ] 查看执行历史
- [ ] 查看执行详情
- [ ] 验证WebSocket实时更新
---
## 🎉 测试总结
**所有核心功能测试通过！**
- ✅ 执行记录创建和查询正常
- ✅ 工作流执行正常（DeepSeek集成成功）
- ✅ 数据格式正确
- ✅ 前端页面已实现
- ✅ WebSocket功能已实现
**系统已准备就绪，可以进行前端测试！**
---
**测试完成时间**: 2024年
**测试结果**: ✅ **全部通过**
**系统状态**: ✅ **可以投入使用**

111
docs/tests/条件节点测试报告.md Normal file
View File

@@ -0,0 +1,111 @@
# 条件节点表达式解析测试报告
## 📊 测试结果
**测试时间**: 2024年
**测试状态**: ✅ **全部通过 (4/4)**
---
## ✅ 测试详情
### 测试1: 简单条件表达式 ✅ (8/8通过)
#### 测试用例
- `{value} > 10` with `{"value": 15}` → True ✅
- `{value} > 10` with `{"value": 5}` → False ✅
- `{value} == 10` with `{"value": 10}` → True ✅
- `{value} != 10` with `{"value": 10}` → False ✅
- `{status} == 'active'` with `{"status": "active"}` → True ✅
- `{status} == 'active'` with `{"status": "inactive"}` → False ✅
- `{count} >= 0` with `{"count": 0}` → True ✅
- `{count} < 100` with `{"count": 50}` → True ✅
### 测试2: 逻辑组合条件 ✅ (6/6通过)
#### 测试用例
- `{value} > 10 and {value} < 20` with `{"value": 15}` → True ✅
- `{value} > 10 and {value} < 20` with `{"value": 5}` → False ✅
- `{value} > 10 and {value} < 20` with `{"value": 25}` → False ✅
- `{status} == 'active' or {status} == 'pending'` with `{"status": "active"}` → True ✅
- `{status} == 'active' or {status} == 'pending'` with `{"status": "pending"}` → True ✅
- `{status} == 'active' or {status} == 'pending'` with `{"status": "inactive"}` → False ✅
### 测试3: 复杂条件表达式 ✅ (4/4通过)
#### 测试用例
- `({value} > 10 and {value} < 20) and {status} == 'active'` with `{"value": 15, "status": "active"}` → True ✅
- `({value} > 10 and {value} < 20) and {status} == 'active'` with `{"value": 15, "status": "inactive"}` → False ✅
- `({status} == 'a' or {status} == 'b') and {count} > 0` with `{"status": "a", "count": 5}` → True ✅
- `({status} == 'a' or {status} == 'b') and {count} > 0` with `{"status": "c", "count": 5}` → False ✅
### 测试4: 工作流中的条件节点 ✅
#### 测试用例1: value = 15 (应该走True分支)
- 工作流执行成功 ✅
- 条件判断正确 ✅
- 分支选择正确 ✅
#### 测试用例2: value = 5 (应该走False分支)
- 工作流执行成功 ✅
- 条件判断正确 ✅
- 分支选择正确 ✅
---
## 🎯 功能验证
### 1. 表达式解析 ✅
- 简单条件表达式解析正常
- 逻辑运算符解析正常
- 括号分组解析正常
- 变量替换正常
### 2. 条件评估 ✅
- 数值比较正确
- 字符串比较正确
- 逻辑组合正确
- 复杂表达式正确
### 3. 工作流集成 ✅
- 条件节点在工作流中正常工作
- 分支选择正确
- 数据传递正确
### 4. 安全性 ✅
- 表达式评估安全
- 无危险操作
- 类型转换正确
---
## 📈 性能表现
- **表达式解析**: 毫秒级响应
- **条件评估**: 毫秒级响应
- **工作流执行**: 正常（条件节点不影响整体性能）
---
## ✅ 结论
### 功能状态
- **条件表达式解析**: ✅ 完全正常
- **逻辑运算符支持**: ✅ 完全正常
- **括号分组支持**: ✅ 完全正常
- **工作流集成**: ✅ 完全正常
- **分支选择**: ✅ 完全正常
### 可用功能
1. ✅ 支持简单条件表达式
2. ✅ 支持逻辑组合（and, or, not）
3. ✅ 支持括号分组
4. ✅ 支持多种比较运算符
5. ✅ 支持嵌套路径访问
6. ✅ 在工作流中正确选择分支
---
**测试完成时间**: 2024年
**测试结果**: ✅ **全部通过**
**功能状态**: ✅ **可以投入使用**

489
docs/tests/测试指南-完整版.md Normal file
View File

@@ -0,0 +1,489 @@
# 完整测试指南
## 📋 测试前准备
### 1. 配置API密钥
#### 方法一：使用环境变量文件
创建或编辑 `backend/.env` 文件：
```env
# OpenAI配置
OPENAI_API_KEY=sk-your-openai-api-key-here
OPENAI_BASE_URL=https://api.openai.com/v1
# DeepSeek配置
DEEPSEEK_API_KEY=sk-your-deepseek-api-key-here
DEEPSEEK_BASE_URL=https://api.deepseek.com
```
#### 方法二：使用Docker环境变量
在 `docker-compose.dev.yml` 中的 `backend` 服务添加：
```yaml
environment:
- OPENAI_API_KEY=sk-your-openai-api-key-here
- DEEPSEEK_API_KEY=sk-your-deepseek-api-key-here
```
### 2. 重启服务
```bash
docker-compose -f docker-compose.dev.yml restart backend
```
### 3. 验证服务运行
```bash
# 检查后端服务
docker-compose -f docker-compose.dev.yml ps backend
# 查看后端日志
docker-compose -f docker-compose.dev.yml logs --tail=20 backend
```
## 🧪 测试步骤
### 测试1：基础功能测试
#### 1.1 登录系统
1. 打开浏览器访问：`http://101.43.95.130:8038` 或 `http://localhost:8038`
2. 如果未注册，先注册账号
3. 使用用户名和密码登录
4. 验证登录成功后跳转到首页
**预期结果**：
- ✅ 登录成功
- ✅ 显示工作流列表页面
- ✅ 控制台无错误
#### 1.2 创建工作流
1. 点击"创建工作流"按钮
2. 进入工作流设计器
3. 验证画布显示正常
**预期结果**：
- ✅ 工作流设计器正常加载
- ✅ 节点工具箱显示正常
- ✅ 可以拖拽节点到画布
### 测试2：LLM节点测试
#### 2.1 创建简单工作流（OpenAI）
1. **添加节点**：
- 从节点工具箱拖拽"开始"节点到画布
- 拖拽"LLM"节点到画布
- 拖拽"结束"节点到画布
2. **连接节点**：
- 从"开始"节点的底部连接点拖到"LLM"节点的顶部
- 从"LLM"节点的底部拖到"结束"节点的顶部
3. **配置LLM节点**：
- 点击"LLM"节点选中它
- 在右侧配置面板中：
- 提供商：选择"OpenAI"
- 提示词：输入 `请将以下文本翻译成英文：{input}`
- 模型：选择"GPT-3.5 Turbo"
- 温度：0.7
- 点击"保存配置"
4. **保存工作流**：
- 点击顶部"保存"按钮
- 验证保存成功提示
**预期结果**：
- ✅ 节点可以正常连接
- ✅ LLM节点配置保存成功
- ✅ 工作流保存成功
#### 2.2 执行工作流（OpenAI）
1. **运行工作流**：
- 点击"运行"按钮
- 输入测试数据（JSON格式）：
```json
{
"input": "你好，世界"
}
```
- 点击"执行"
2. **查看执行结果**：
- 等待执行完成
- 查看执行结果
**预期结果**：
- ✅ 执行成功
- ✅ 返回英文翻译结果："Hello, world"
- ✅ 无错误信息
#### 2.3 测试DeepSeek
1. **创建新工作流或修改现有工作流**：
- 添加LLM节点
- 配置节点：
- 提供商：选择"DeepSeek"
- 提示词：`请用一句话总结：{input}`
- 模型：选择"DeepSeek Chat"
- 温度：0.7
2. **执行工作流**：
- 输入数据：
```json
{
"input": "人工智能是计算机科学的一个分支，它试图理解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器。"
}
```
- 执行并查看结果
**预期结果**：
- ✅ DeepSeek调用成功
- ✅ 返回总结结果
- ✅ 无错误信息
#### 2.4 测试DeepSeek Coder
1. **配置代码生成节点**：
- 提供商：DeepSeek
- 模型：DeepSeek Coder
- 提示词：`请用Python编写一个函数，功能是：{input}`
2. **执行工作流**：
- 输入数据：
```json
{
"input": "计算斐波那契数列的第n项"
}
```
- 执行并查看结果
**预期结果**：
- ✅ 返回Python代码
- ✅ 代码格式正确
- ✅ 功能符合要求
### 测试3：复杂工作流测试
#### 3.1 多节点工作流
创建以下工作流：
```
开始 → LLM节点(翻译) → LLM节点(总结) → 结束
```
1. **配置第一个LLM节点**（翻译）：
- 提供商：OpenAI
- 提示词：`将以下中文翻译成英文：{input}`
- 模型：GPT-3.5 Turbo
2. **配置第二个LLM节点**（总结）：
- 提供商：DeepSeek
- 提示词：`请用一句话总结以下英文内容：{input}`
- 模型：DeepSeek Chat
3. **执行工作流**：
- 输入数据：
```json
{
"input": "人工智能技术正在快速发展，它将在未来改变我们的生活方式。"
}
```
**预期结果**：
- ✅ 第一个节点返回英文翻译
- ✅ 第二个节点返回总结
- ✅ 数据正确传递
#### 3.2 条件分支工作流
创建以下工作流：
```
开始 → LLM节点(判断) → 条件节点 → [True分支] → 输出节点
↓
[False分支] → 输出节点
```
1. **配置LLM节点**：
- 提示词：`判断以下文本的情感倾向（返回positive或negative）：{input}`
2. **配置条件节点**：
- 条件表达式：`{input} == "positive"`
3. **执行工作流**：
- 测试数据1（正面）：
```json
{
"input": "今天天气真好"
}
```
- 测试数据2（负面）：
```json
{
"input": "今天心情很糟糕"
}
```
**预期结果**：
- ✅ 正面文本走True分支
- ✅ 负面文本走False分支
- ✅ 条件判断正确
### 测试4：WebSocket实时推送测试
#### 4.1 使用浏览器控制台测试
1. **打开浏览器控制台**（F12）
2. **建立WebSocket连接**：
```javascript
// 先执行一个工作流，获取execution_id
// 假设execution_id为 'your-execution-id'
const executionId = 'your-execution-id';
const protocol = window.location.protocol === 'https:' ? 'wss:' : 'ws:';
const hostname = window.location.hostname;
const ws = new WebSocket(`${protocol}//${hostname}:8037/api/v1/ws/executions/${executionId}`);
ws.onopen = () => {
console.log('✅ WebSocket连接已建立');
};
ws.onmessage = (event) => {
const message = JSON.parse(event.data);
console.log('📨 收到消息:', message);
if (message.type === 'status') {
console.log('状态:', message.status);
console.log('进度:', message.progress);
}
};
ws.onerror = (error) => {
console.error('❌ WebSocket错误:', error);
};
ws.onclose = () => {
console.log('🔌 WebSocket连接已关闭');
};
// 心跳
setInterval(() => {
if (ws.readyState === WebSocket.OPEN) {
ws.send(JSON.stringify({ type: 'ping' }));
}
}, 30000);
```
3. **执行工作流**：
- 在另一个标签页执行工作流
- 观察控制台中的状态更新
**预期结果**：
- ✅ WebSocket连接成功
- ✅ 收到状态更新消息
- ✅ 状态从pending → running → completed
- ✅ 收到最终结果
### 测试5：错误处理测试
#### 5.1 API Key错误
1. **临时移除API Key**：
```bash
# 在backend/.env中注释掉API Key
# OPENAI_API_KEY=sk-xxx
```
2. **重启后端**：
```bash
docker-compose -f docker-compose.dev.yml restart backend
```
3. **执行工作流**：
- 使用OpenAI节点
- 执行工作流
**预期结果**：
- ✅ 返回错误信息
- ✅ 错误信息清晰：`OpenAI API Key未配置...`
- ✅ 工作流执行失败但不会崩溃
#### 5.2 网络错误
1. **断开网络**（或使用错误的API地址）
2. **执行工作流**
**预期结果**：
- ✅ 返回网络错误信息
- ✅ 错误处理正常
- ✅ 不会导致系统崩溃
#### 5.3 无效模型名称
1. **配置LLM节点**：
- 模型名称：`invalid-model-name`
2. **执行工作流**
**预期结果**：
- ✅ 返回模型不存在错误
- ✅ 错误信息清晰
### 测试6：性能测试
#### 6.1 并发执行测试
1. **同时执行多个工作流**：
- 创建3-5个不同的工作流
- 同时执行它们
**预期结果**：
- ✅ 所有工作流都能正常执行
- ✅ 不会相互影响
- ✅ 执行时间合理
#### 6.2 长时间运行测试
1. **创建包含多个LLM节点的工作流**
2. **执行并监控**：
- 观察执行时间
- 检查资源使用情况
**预期结果**：
- ✅ 长时间运行稳定
- ✅ 内存使用正常
- ✅ 不会出现内存泄漏
## 📊 测试检查清单
### 基础功能
- [ ] 用户注册和登录
- [ ] 工作流创建和保存
- [ ] 节点拖拽和连接
- [ ] 节点配置保存
### LLM功能
- [ ] OpenAI调用成功
- [ ] DeepSeek调用成功
- [ ] DeepSeek Coder调用成功
- [ ] Prompt模板变量替换
- [ ] 不同模型选择
- [ ] 温度参数生效
- [ ] 最大Token数限制
### 工作流执行
- [ ] 简单工作流执行
- [ ] 多节点工作流执行
- [ ] 条件分支工作流
- [ ] 数据传递正确
- [ ] 执行结果正确
### WebSocket
- [ ] WebSocket连接建立
- [ ] 状态实时更新
- [ ] 心跳检测
- [ ] 连接自动断开
### 错误处理
- [ ] API Key错误处理
- [ ] 网络错误处理
- [ ] 模型错误处理
- [ ] 错误信息清晰
### 性能
- [ ] 并发执行正常
- [ ] 长时间运行稳定
- [ ] 资源使用合理
## 🐛 常见问题排查
### 问题1：LLM调用失败
**检查项**：
1. API Key是否正确配置
2. 网络连接是否正常
3. API余额是否充足
4. 模型名称是否正确
**解决方法**：
```bash
# 检查环境变量
docker-compose -f docker-compose.dev.yml exec backend env | grep API_KEY
# 查看后端日志
docker-compose -f docker-compose.dev.yml logs --tail=50 backend
```
### 问题2：WebSocket连接失败
**检查项**：
1. 后端服务是否运行
2. 端口8037是否开放
3. 防火墙配置是否正确
**解决方法**：
```bash
# 检查后端服务
docker-compose -f docker-compose.dev.yml ps backend
# 测试WebSocket连接
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" \
http://localhost:8037/api/v1/ws/executions/test-id
```
### 问题3：工作流执行卡住
**检查项**：
1. Celery worker是否运行
2. Redis连接是否正常
3. 数据库连接是否正常
**解决方法**：
```bash
# 检查Celery worker
docker-compose -f docker-compose.dev.yml ps celery
# 查看Celery日志
docker-compose -f docker-compose.dev.yml logs --tail=50 celery
# 检查Redis
docker-compose -f docker-compose.dev.yml exec redis redis-cli ping
```
## 📝 测试报告模板
```
测试日期：2024-XX-XX
测试人员：XXX
测试结果：
- 基础功能：✅ 通过
- LLM功能：✅ 通过
- 工作流执行：✅ 通过
- WebSocket：✅ 通过
- 错误处理：✅ 通过
- 性能：✅ 通过
发现问题：
1. [问题描述]
2. [问题描述]
建议：
1. [建议内容]
2. [建议内容]
```
---
**状态**: ✅ 测试指南已创建
**时间**: 2024年

182
docs/tests/测试指南.md Normal file
View File

@@ -0,0 +1,182 @@
# 测试指南
## 🚀 快速测试
### 1. 访问前端
打开浏览器访问：http://localhost:8038
### 2. 注册/登录
1. 点击"注册"标签
2. 填写用户名、邮箱、密码
3. 点击"注册"按钮
4. 注册成功后自动切换到登录标签
5. 使用刚才注册的账号登录
### 3. 创建工作流
1. 登录后，点击"创建工作流"按钮
2. 进入工作流设计器
3. 从左侧工具箱拖拽节点到画布
4. 连接节点（点击节点的连接点并拖拽到目标节点）
5. 点击节点进行配置
6. 点击"保存"按钮保存工作流
### 4. 执行工作流
1. 在工作流设计器中点击"运行"按钮
2. 或通过API执行：
```bash
# 先获取token（登录后）
curl -X POST http://localhost:8037/api/v1/auth/login \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "username=your_username&password=your_password"
# 执行工作流（替换TOKEN和WORKFLOW_ID）
curl -X POST http://localhost:8037/api/v1/workflows/{WORKFLOW_ID}/execute \
-H "Authorization: Bearer {TOKEN}" \
-H "Content-Type: application/json" \
-d '{"input": "测试数据"}'
```
### 5. 查看执行结果
1. 在工作流列表页面查看执行历史
2. 或通过API查看：
```bash
curl http://localhost:8037/api/v1/executions \
-H "Authorization: Bearer {TOKEN}"
```
## 📋 API测试示例
### 用户注册
```bash
curl -X POST http://localhost:8037/api/v1/auth/register \
-H "Content-Type: application/json" \
-d '{
"username": "testuser",
"email": "test@example.com",
"password": "test123456"
}'
```
### 用户登录
```bash
curl -X POST http://localhost:8037/api/v1/auth/login \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "username=testuser&password=test123456"
```
### 创建工作流
```bash
curl -X POST http://localhost:8037/api/v1/workflows \
-H "Authorization: Bearer {TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"name": "测试工作流",
"description": "这是一个测试工作流",
"nodes": [
{
"id": "node1",
"type": "start",
"position": {"x": 100, "y": 100},
"data": {"label": "开始"}
},
{
"id": "node2",
"type": "llm",
"position": {"x": 300, "y": 100},
"data": {"label": "LLM处理", "prompt": "处理输入: {input}"}
},
{
"id": "node3",
"type": "end",
"position": {"x": 500, "y": 100},
"data": {"label": "结束"}
}
],
"edges": [
{"id": "e1", "source": "node1", "target": "node2"},
{"id": "e2", "source": "node2", "target": "node3"}
]
}'
```
### 执行工作流
```bash
curl -X POST http://localhost:8037/api/v1/workflows/{WORKFLOW_ID}/execute \
-H "Authorization: Bearer {TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"input": "这是测试输入"
}'
```
## 🔍 检查服务状态
### 检查所有服务
```bash
docker-compose -f docker-compose.dev.yml ps
```
### 查看日志
```bash
# 查看所有服务日志
docker-compose -f docker-compose.dev.yml logs -f
# 查看特定服务日志
docker-compose -f docker-compose.dev.yml logs -f backend
docker-compose -f docker-compose.dev.yml logs -f frontend
docker-compose -f docker-compose.dev.yml logs -f celery
```
### 健康检查
```bash
# 后端健康检查
curl http://localhost:8037/health
# 应该返回: {"status":"healthy"}
```
## 🐛 常见问题
### 1. 前端无法访问
- 检查前端服务是否运行：`docker-compose ps`
- 检查端口8038是否被占用
- 查看前端日志：`docker-compose logs frontend`
### 2. API请求失败
- 检查后端服务是否运行
- 检查JWT Token是否有效
- 查看后端日志：`docker-compose logs backend`
### 3. 工作流执行失败
- 检查Celery Worker是否运行：`docker-compose logs celery`
- 检查Redis连接是否正常
- 查看执行记录的error_message字段
### 4. 数据库连接失败
- 检查数据库连接信息是否正确
- 确认服务器能访问腾讯云MySQL
- 检查网络连接
## 📝 下一步
完成基础功能测试后，可以继续开发：
1. OpenAI模型真实集成
2. WebSocket实时推送
3. 更多节点类型
4. 执行结果可视化

88
docs/tests/测试方案总结.md Normal file
View File

@@ -0,0 +1,88 @@
# 工作流数据流转测试方案总结
## 问题
工作流能执行完成，但LLM节点输出"答非所问"，可能是数据在节点间传递时被错误处理。
## 快速测试方法
### 方法1: 查看执行日志数据库（最简单）
```bash
cd /home/renjianbo/aiagent
python3 check_execution_logs.py
```
这个脚本会：
- 自动查找最近的Agent执行记录
- 显示输入数据和输出数据
- 显示所有执行日志（按时间顺序）
- 特别分析LLM节点的输入输出
### 方法2: 运行数据流转测试脚本
```bash
cd /home/renjianbo/aiagent
python3 test_workflow_data_flow.py
```
这个脚本会：
- 模拟完整的工作流执行
- 详细记录每个节点的输入输出
- 特别关注数据格式转换
### 方法3: 查看后端日志
```bash
# 查看包含[rjb]的调试日志
docker-compose -f docker-compose.dev.yml logs --tail=500 backend | grep "\[rjb\]" | tail -50
# 或者查看Celery worker的日志
docker-compose -f docker-compose.dev.yml logs --tail=500 celery | grep "\[rjb\]" | tail -50
```
## 关键检查点
### 1. 输入数据格式
**期望**: `{"query": "苹果英语怎么讲?", "USER_INPUT": "苹果英语怎么讲?"}`
**检查**: 在浏览器开发者工具的Network标签中查看 `POST /api/v1/executions` 请求的body
### 2. Start节点输出
**期望**: 直接返回输入数据，格式不变
**检查**: 查看执行日志中start节点的输出
### 3. LLM节点输入
**期望**: 从start节点获取，格式为 `{"query": "...", "USER_INPUT": "..."}`
**可能的问题**: 被包装成 `{"input": {"query": "...", "USER_INPUT": "..."}}`
**检查**:
- 查看执行日志中LLM节点开始执行时的输入数据
- 或者运行 `check_execution_logs.py` 查看详细日志
### 4. user_query提取
**期望**: 能正确提取到 "苹果英语怎么讲?"
**检查**: 查看后端日志中的 `[rjb] 最终提取的user_query` 日志
### 5. Prompt格式化
**期望**: 如果是通用指令"请处理用户请求。"，应该直接使用user_query作为prompt
**检查**: 查看后端日志中的prompt相关日志
## 预期问题
根据之前的分析，最可能的问题是：
1. **数据被包装**: `get_node_input` 方法可能将数据包装成了 `{"input": {...}}`
2. **提取逻辑问题**: `user_query` 提取逻辑可能没有正确处理嵌套结构
3. **Prompt格式化问题**: 即使提取到了 `user_query`，prompt格式化可能没有正确使用
## 修复建议
如果发现数据被包装成 `{"input": {...}}`，我已经在代码中添加了处理逻辑：
- 在 `get_node_input` 中检查嵌套的 `input` 字段
- 在 `user_query` 提取时优先从嵌套的 `input` 中提取
如果问题仍然存在，请运行测试脚本并提供输出结果。

98
docs/tests/测试连接.md Normal file
View File

@@ -0,0 +1,98 @@
# 测试连接指南
## 当前状态
✅ **Docker容器运行正常**
- 后端：监听在 `0.0.0.0:8037`
- 前端：监听在 `0.0.0.0:8038`
✅ **云控制台防火墙已配置**
- 端口 8037 已开放
- 端口 8038 已开放
## 测试步骤
### 1. 从服务器本地测试
```bash
# 测试后端
curl http://localhost:8037/health
# 应该返回: {"status":"healthy"}
# 测试前端
curl http://localhost:8038
# 应该返回HTML内容
```
### 2. 从外部测试（重要）
由于防火墙规则可能需要几分钟生效，请：
1. **等待1-2分钟**让防火墙规则生效
2. **从浏览器测试**：
- 访问：http://101.43.95.130:8038
- 应该能看到登录页面
3. **从其他电脑测试后端**：
```bash
curl http://101.43.95.130:8037/health
# 应该返回: {"status":"healthy"}
```
### 3. 如果仍然无法访问
#### 检查系统防火墙
云控制台的防火墙和系统防火墙是分开的，可能还需要配置系统防火墙：
```bash
# 运行自动配置脚本
sudo bash /home/renjianbo/aiagent/开放端口脚本.sh
```
#### 检查Docker端口映射
```bash
# 确认端口映射正确
docker-compose -f docker-compose.dev.yml ps
# 应该看到：
# backend: 0.0.0.0:8037->8000/tcp
# frontend: 0.0.0.0:8038->3000/tcp
```
#### 检查端口监听
```bash
# 确认端口正在监听
netstat -tlnp | grep -E "(8037|8038)
# 应该看到：
# tcp 0 0 0.0.0.0:8037 ... LISTEN
# tcp 0 0 0.0.0.0:8038 ... LISTEN
```
## 常见问题
### Q: 云控制台已配置，但还是无法访问？
A: 可能的原因：
1. **规则未生效**：等待1-2分钟
2. **系统防火墙**：需要同时配置系统防火墙
3. **安全组方向**：确认是"入站"规则，不是"出站"规则
### Q: 如何确认防火墙规则已生效？
A: 从外部测试：
```bash
# 使用在线工具测试
# 或从其他电脑访问
curl http://101.43.95.130:8037/health
```
如果返回 `{"status":"healthy"}`，说明防火墙已生效。
---
**下一步**：等待1-2分钟后，从浏览器访问 http://101.43.95.130:8038 测试

178
docs/tests/知识库问答助手测试总结.md Normal file
View File

@@ -0,0 +1,178 @@
# 知识库问答助手测试总结
## 测试时间
2026-01-23 00:00
## Agent信息
- **名称**: 知识库问答助手
- **ID**: `45c56398-ad1d-4533-89e0-ba02f9c47932`
- **状态**: published（已发布）
- **节点数量**: 10个
- **连接数量**: 9条
## 工作流结构
1. **开始节点** - 接收用户问题
2. **问题预处理** - 整理输入数据
3. **文本向量化** - HTTP节点调用DeepSeek embedding API
4. **提取向量** - JSON节点提取embedding向量
5. **准备搜索数据** - 合并向量和查询文本
6. **知识库检索** - 向量数据库节点进行语义搜索
7. **整理检索结果** - 合并搜索结果和查询
8. **生成答案** - LLM节点基于检索结果生成答案
9. **提取最终答案** - JSON节点提取最终文本
10. **结束节点** - 返回答案
## 测试结果
### 测试输入
```
问题: 什么是人工智能？
```
### 执行状态
- **状态**: failed（执行失败）
- **执行时间**: 2240ms
- **执行ID**: `e775395c-a306-4544-abaf-357c9245f56e`
### 错误分析
#### 1. HTTP节点调用embedding API失败
- **错误信息**: "Not Found. Please check the configuration."
- **节点**: `http-embedding`
- **API URL**: `https://api.deepseek.com/v1/embeddings`
- **模型**: `deepseek-embedding`
- **问题**: DeepSeek可能不支持embedding API，或者URL/模型名称不正确
#### 2. 向量数据库节点无法获取查询向量
- **错误信息**: "节点 vector-search 执行失败: 向量数据库操作失败: 无法获取查询向量"
- **节点**: `vector-search`
- **原因**: 由于embedding API调用失败，没有获取到向量数据
### 执行日志关键信息
```
[3] 2026-01-22 16:00:25 [INFO]
节点: http-embedding (http)
消息: 节点 http-embedding (http) 开始执行
[10] 2026-01-22 16:00:26 [ERROR]
节点: http-embedding (http)
消息: HTTP请求失败: 404
数据: {
"error_msg": "Not Found. Please check the configuration."
}
[11] 2026-01-22 16:00:26 [INFO]
节点: vector-search (vector_db)
消息: 节点 vector-search (vector_db) 开始执行
[13] 2026-01-22 16:00:26 [ERROR]
节点: (无) ((无))
消息: 工作流任务执行失败
错误: 节点 vector-search 执行失败: 向量数据库操作失败: 无法获取查询向量
```
## 问题根因
1. **DeepSeek Embedding API不支持或配置错误**
- DeepSeek可能不提供embedding API
- 或者需要使用不同的API端点/模型名称
- 需要验证DeepSeek是否支持embedding功能
2. **缺少备选方案**
- 当前工作流完全依赖embedding API
- 没有fallback机制处理API调用失败的情况
## 解决方案
### 方案1: 使用其他embedding服务
1. **使用OpenAI Embedding API**
- URL: `https://api.openai.com/v1/embeddings`
- 模型: `text-embedding-ada-002` 或 `text-embedding-3-small`
- 需要配置OpenAI API Key
2. **使用本地embedding模型**
- 使用sentence-transformers等库
- 在服务器端运行embedding模型
- 通过HTTP节点调用本地服务
### 方案2: 简化工作流（用于测试）
1. **跳过embedding步骤**
- 直接使用文本关键词匹配
- 或者使用LLM节点进行语义理解
- 简化向量数据库的使用
2. **使用预计算的向量**
- 预先将知识库文档向量化
- 存储向量数据
- 查询时只需要搜索，不需要实时向量化
### 方案3: 修复DeepSeek配置
1. **验证DeepSeek API文档**
- 确认是否支持embedding
- 确认正确的API端点和模型名称
- 更新HTTP节点配置
## 下一步行动
1. **验证DeepSeek Embedding API**
- 查阅DeepSeek官方文档
- 测试API端点是否可用
- 确认模型名称是否正确
2. **准备测试数据**
- 创建知识库文档
- 将文档向量化并存储到向量数据库
- 使用`knowledge_base`集合
3. **修复或替换embedding节点**
- 根据验证结果修复DeepSeek配置
- 或替换为其他embedding服务
- 或使用简化方案
4. **重新测试**
- 修复后重新执行测试
- 验证完整工作流是否正常
- 测试知识库检索和答案生成
## 测试命令
```bash
# 发布Agent
python3 publish_agent.py "知识库问答助手"
# 测试Agent
python3 test_workflow_tool.py -a "知识库问答助手" -i "什么是人工智能？"
# 查看执行日志
python3 check_execution_logs.py
```
## 相关文件
- **Agent生成脚本**: `backend/scripts/generate_knowledge_base_qa_agent.py`
- **测试工具**: `test_workflow_tool.py`
- **日志查看工具**: `check_execution_logs.py`
- **发布脚本**: `publish_agent.py`
## 注意事项
1. **知识库数据准备**
- 需要先准备知识库文档
- 文档需要向量化并存储
- 集合名称必须是`knowledge_base`
2. **API配置**
- 确保embedding API可用
- 配置正确的API Key
- 验证API端点和模型名称
3. **向量数据库**
- 当前使用内存存储（简化实现）
- 生产环境应使用ChromaDB、Pinecone等
- 数据在服务重启后会丢失
---
测试完成时间: 2026-01-23 00:02
测试人员: AI Assistant

245
docs/tests/节点测试按钮无法点击问题排查.md Normal file
View File

@@ -0,0 +1,245 @@
# 节点测试"运行测试"按钮无法点击问题排查
## 🔍 问题原因
"运行测试"按钮的禁用条件是：
```vue
:disabled="!selectedNode || testInputError"
```
按钮无法点击的可能原因：
1. **没有选中节点** (`!selectedNode`)
2. **测试输入JSON格式错误** (`testInputError`)
---
## ✅ 解决方案
### 方案1: 检查节点是否选中
1. **确认节点已选中**
- 节点应该显示为选中状态（有蓝色边框或高亮）
- 右侧配置面板应该显示该节点的配置信息
2. **如果节点未选中**
- 点击节点使其选中
- 或者从节点列表中选择节点
### 方案2: 检查JSON格式
1. **验证JSON格式**
- 点击"格式化"按钮，如果JSON格式正确，会格式化成功
- 如果JSON格式错误，会显示错误信息
2. **常见JSON格式错误**
- 缺少引号：`{input: "获取最近日志"}` ❌
- 多余的逗号：`{"input": "获取最近日志",}` ❌
- 单引号：`{'input': '获取最近日志'}` ❌
- 正确的格式：`{"input": "获取最近日志"}` ✅
3. **修复JSON格式**
- 点击"格式化"按钮自动修复
- 或手动修正JSON格式
### 方案3: 使用快速模板
1. **选择快速模板**
- 在"快速模板"下拉菜单中选择合适的模板
- 对于LLM节点，可以选择"LLM输入"模板
2. **模板会自动填充正确的格式**
---
## 📝 正确的测试输入格式
### 对于"执行ADB命令"节点（LLM工具调用节点）
**推荐输入格式**：
```json
{
"input": "获取最近日志"
}
```
或者更详细的格式：
```json
{
"input": "请使用adb_log工具获取最近的100行日志",
"context": "用户想要查看Android设备的最近日志"
}
```
### 如果节点有上游节点
如果"执行ADB命令"节点有上游节点（如JSON解析节点），输入应该模拟上游节点的输出：
```json
{
"command": "logcat",
"max_lines": 100,
"level": null,
"filter_tag": null
}
```
---
## 🔧 操作步骤
### 步骤1: 确认节点选中
1. 点击"执行ADB命令"节点
2. 确认节点显示为选中状态
3. 确认右侧配置面板显示该节点的信息
### 步骤2: 检查测试输入
1. 点击"测试"标签页
2. 检查测试输入框中的JSON格式
3. 如果有错误提示，查看错误信息
### 步骤3: 修复JSON格式
**方法1: 使用格式化按钮**
- 点击"格式化"按钮
- 如果格式正确，会自动格式化
- 如果格式错误，会显示错误信息
**方法2: 使用快速模板**
- 在"快速模板"下拉菜单中选择"LLM输入"
- 会自动填充正确的格式
- 然后修改内容为你的测试数据
**方法3: 手动修正**
- 确保使用双引号
- 确保没有多余的逗号
- 确保JSON结构正确
### 步骤4: 验证输入
1. 检查输入框下方是否有错误提示
2. 如果没有错误提示，按钮应该可以点击
3. 点击"运行测试"按钮
---
## 💡 快速检查清单
- [ ] 节点已选中（有蓝色边框或高亮）
- [ ] 测试输入框中有内容
- [ ] JSON格式正确（使用双引号，没有语法错误）
- [ ] 输入框下方没有错误提示
- [ ] "运行测试"按钮不是灰色（禁用状态）
---
## 🎯 示例：正确的测试输入
### 示例1: 简单输入
```json
{
"input": "获取最近日志"
}
```
### 示例2: 详细输入
```json
{
"input": "请使用adb_log工具，执行logcat命令获取最近的100行日志",
"query": "获取最近日志"
}
```
### 示例3: 模拟上游节点输出
如果"执行ADB命令"节点接收来自JSON解析节点的输出：
```json
{
"command": "logcat",
"max_lines": 100,
"level": null,
"filter_tag": null
}
```
---
## ⚠️ 常见问题
### Q1: 按钮一直是灰色的
**A**: 检查：
1. 节点是否已选中
2. JSON格式是否正确
3. 查看输入框下方的错误提示
### Q2: 点击"格式化"后显示错误
**A**: JSON格式有错误，需要手动修正：
- 检查是否使用了单引号（应该用双引号）
- 检查是否有多余的逗号
- 检查括号是否匹配
### Q3: 使用模板后还是无法点击
**A**:
1. 检查节点是否已选中
2. 尝试清空后重新输入
3. 刷新页面后重试
---
## 🔍 调试技巧
### 1. 查看浏览器控制台
打开浏览器开发者工具（F12），查看Console标签：
- 如果有JavaScript错误，会显示在控制台
- 查看是否有相关的错误信息
### 2. 检查网络请求
在Network标签中：
- 查看是否有失败的API请求
- 检查节点测试API的请求和响应
### 3. 检查Vue组件状态
在Vue DevTools中：
- 查看`selectedNode`的值
- 查看`testInputError`的值
- 查看`nodeTestInput`的值
---
## 📞 如果问题仍然存在
如果按照以上步骤操作后，按钮仍然无法点击：
1. **刷新页面**
- 按F5刷新页面
- 重新选择节点和配置测试输入
2. **检查浏览器兼容性**
- 使用Chrome或Edge浏览器
- 确保浏览器版本是最新的
3. **清除浏览器缓存**
- 清除浏览器缓存和Cookie
- 重新登录系统
4. **查看后端日志**
```bash
docker-compose -f docker-compose.dev.yml logs backend | tail -50
```
---
**最后更新**: 2026-01-23
**状态**: 问题排查指南

206
docs/tests/邮件和消息队列节点测试报告.md Normal file
View File

@@ -0,0 +1,206 @@
# 邮件节点和消息队列节点测试报告
## 📅 测试时间
2024年1月17日
## 🎯 测试目标
验证新实现的邮件节点和消息队列节点（RabbitMQ/Kafka）的功能：
1. 节点类型识别
2. 节点配置保存
3. 工作流验证
4. 工作流创建和执行
## ✅ 测试结果
### 1. 用户认证测试
- ✅ **用户注册**: 成功创建测试用户 `test_user`
- ✅ **用户登录**: 成功获取JWT Token
- ✅ **Token验证**: API请求正常
### 2. 邮件节点测试
#### 工作流创建
- ✅ **工作流创建**: 成功
- 工作流ID: `a5e8a113-7eef-4d4f-9f00-d094767de912`
- 节点数: 3（开始、邮件、结束）
- 边数: 2
#### 工作流验证
- ✅ **验证结果**: 通过
- 有效: `True`
- 错误: `[]`（无错误）
- 警告: `[]`（无警告）
#### 节点配置验证
- ✅ **节点类型**: `email` - 正确识别
- ✅ **配置项完整**:
- SMTP服务器: `smtp_host`, `smtp_port`
- 认证信息: `smtp_user`, `smtp_password`
- TLS配置: `use_tls`
- 邮件内容: `from_email`, `to_email`, `subject`, `body`, `body_type`
- 变量替换: 支持 `{key}` 格式
#### 执行测试
- ✅ **执行任务创建**: 成功
- 执行ID: `752cc46c-f10f-4bdb-b950-206ea55e8ab0`
- 状态: `pending`（等待Celery执行）
- ⚠️ **实际执行**: 需要真实的SMTP服务器（测试环境未配置）
### 3. RabbitMQ消息队列节点测试
#### 工作流创建
- ✅ **工作流创建**: 成功
- 工作流ID: `c7b58d85-eced-4b2b-8b11-8dc79f0364da`
- 节点数: 3（开始、消息队列、结束）
- 边数: 2
#### 工作流验证
- ✅ **验证结果**: 通过
- 有效: `True`
- 错误: `[]`（无错误）
- 警告: `[]`（无警告）
#### 节点配置验证
- ✅ **节点类型**: `message_queue` - 正确识别
- ✅ **队列类型**: `rabbitmq` - 正确配置
- ✅ **配置项完整**:
- 连接信息: `host`, `port`
- 认证信息: `username`, `password`
- 队列配置: `queue_name`, `routing_key`, `exchange`
- 消息内容: `message`（支持变量替换）
#### 执行测试
- ✅ **执行任务创建**: 成功
- 执行ID: `96a8e12d-3e8d-4840-943d-ab423c1c23cb`
- 状态: `pending`（等待Celery执行）
- ⚠️ **实际执行**: 需要运行RabbitMQ服务器（测试环境未配置）
### 4. Kafka消息队列节点测试
#### 工作流创建
- ✅ **工作流创建**: 成功
- 工作流ID: `53c8db24-1ed1-4702-bee7-8ceda964d3b6`
- 节点数: 3（开始、Kafka、结束）
- 边数: 2
#### 工作流验证
- ✅ **验证结果**: 通过
- 有效: `True`
- 错误: `[]`（无错误）
- 警告: `[]`（无警告）
#### 节点配置验证
- ✅ **节点类型**: `kafka` - 正确识别
- ✅ **队列类型**: `kafka` - 正确配置
- ✅ **配置项完整**:
- 服务器配置: `bootstrap_servers`
- Topic配置: `topic`
- 消息内容: `message`（支持变量替换）
## 📊 测试统计
| 测试项 | 结果 | 说明 |
|--------|------|------|
| 用户认证 | ✅ 通过 | 注册、登录、Token验证正常 |
| 邮件节点创建 | ✅ 通过 | 工作流创建成功 |
| 邮件节点验证 | ✅ 通过 | 无错误，无警告 |
| RabbitMQ节点创建 | ✅ 通过 | 工作流创建成功 |
| RabbitMQ节点验证 | ✅ 通过 | 无错误，无警告 |
| Kafka节点创建 | ✅ 通过 | 工作流创建成功 |
| Kafka节点验证 | ✅ 通过 | 无错误，无警告 |
| 节点类型识别 | ✅ 通过 | 所有节点类型正确识别 |
| 配置项保存 | ✅ 通过 | 所有配置项正确保存 |
| API接口 | ✅ 通过 | 所有API接口正常工作 |
## 🔍 功能验证
### 邮件节点功能
- ✅ 节点类型识别: `email` / `mail`
- ✅ SMTP配置支持
- ✅ TLS/SSL支持
- ✅ 发件人、收件人、抄送、密送支持
- ✅ 邮件主题和正文配置
- ✅ HTML格式支持
- ✅ 附件支持（配置项）
- ✅ 变量替换支持（`{key}` 格式）
### 消息队列节点功能
- ✅ 节点类型识别: `message_queue` / `mq` / `rabbitmq` / `kafka`
- ✅ RabbitMQ配置支持
- 连接配置（host, port）
- 认证配置（username, password）
- Exchange和Routing Key支持
- 直接队列发送支持
- ✅ Kafka配置支持
- Bootstrap Servers配置
- Topic配置
- 多服务器支持
- ✅ 变量替换支持（`{key}` 格式）
## ⚠️ 已知限制
1. **实际执行需要外部服务**:
- 邮件节点需要真实的SMTP服务器
- RabbitMQ节点需要运行RabbitMQ服务
- Kafka节点需要运行Kafka服务
2. **测试环境限制**:
- 当前测试环境未配置这些外部服务
- 执行任务会创建，但实际执行会失败（这是正常的）
## ✅ 测试结论
### 核心功能测试通过 ✅
1. **节点识别**: 所有新节点类型（email, message_queue, kafka）都能被正确识别
2. **配置保存**: 所有节点配置项都能正确保存到数据库
3. **工作流验证**: 工作流验证器正确识别新节点类型，无错误无警告
4. **API接口**: 所有相关API接口正常工作
5. **工作流创建**: 包含新节点的工作流可以正常创建
6. **执行任务创建**: 执行任务可以正常创建（等待Celery执行）
### 代码质量 ✅
- 节点类型定义正确
- 配置项完整
- 变量替换支持
- 错误处理完善
- 代码结构清晰
## 🚀 下一步建议
1. **前端测试**:
- 在前端界面中测试节点拖拽和配置
- 验证配置面板显示是否正确
- 测试节点连接和保存
2. **实际执行测试**:
- 配置真实的SMTP服务器测试邮件发送
- 启动RabbitMQ服务器测试消息队列
- 启动Kafka服务器测试Kafka节点
3. **功能优化**:
- 添加更多错误提示
- 优化配置界面用户体验
- 添加配置验证
## 📝 测试脚本
- **集成测试脚本**: `backend/test_email_mq_integration.py`
- **单元测试脚本**: `backend/test_email_mq_nodes.py`
- **测试指南**: `邮件和消息队列节点测试指南.md`
- **前端测试指南**: `前端测试邮件和消息队列节点.md`
## 🎉 总结
**测试状态**: ✅ **全部通过**
所有核心功能测试通过，节点类型识别、配置保存、工作流验证等功能都正常工作。代码质量良好，可以投入使用。
实际执行功能需要配置外部服务（SMTP、RabbitMQ、Kafka），这是正常的，不影响节点功能的正确性。
---
**测试人员**: AI Assistant
**测试日期**: 2024年1月17日
**测试版本**: v1.0

290
docs/tests/邮件和消息队列节点测试指南.md Normal file
View File

@@ -0,0 +1,290 @@
# 邮件节点和消息队列节点测试指南
## 📋 测试概述
本指南将帮助您测试新实现的**邮件节点**和**消息队列节点**功能。
## ✅ 已完成功能
### 1. 邮件节点 (Email Node)
- ✅ SMTP配置（服务器、端口、用户名、密码）
- ✅ TLS/SSL支持
- ✅ 发件人、收件人、抄送、密送
- ✅ 邮件主题和正文（支持纯文本和HTML）
- ✅ 附件支持（文件路径或Base64编码）
- ✅ 变量替换（支持 {key} 和 ${key} 格式）
### 2. 消息队列节点 (Message Queue Node)
- ✅ RabbitMQ集成
- Exchange和Routing Key支持
- 直接队列发送
- 变量替换
- ✅ Kafka集成
- Topic发送
- 多服务器配置
- 变量替换
## 🧪 测试步骤
### 前置条件
1. **安装依赖**
```bash
cd /home/renjianbo/aiagent/backend
pip3 install aiosmtplib aio-pika kafka-python
```
2. **重启后端服务**（如果需要）
```bash
# 如果使用Docker
docker-compose restart backend
# 如果直接运行
# 重启uvicorn服务
```
### 测试1: 邮件节点
#### 方式一：使用测试SMTP服务（推荐）
1. **注册测试邮箱服务**
- [Mailtrap](https://mailtrap.io) - 免费测试邮箱
- [Ethereal Email](https://ethereal.email) - 临时测试邮箱
2. **在前端创建测试工作流**
- 登录系统
- 创建工作流
- 添加节点：
- 开始节点
- 邮件节点
- 结束节点
3. **配置邮件节点**
```
SMTP服务器: smtp.mailtrap.io (或从Mailtrap获取)
SMTP端口: 2525 (或587)
SMTP用户名: [从Mailtrap获取]
SMTP密码: [从Mailtrap获取]
使用TLS: 是
发件人邮箱: test@example.com
收件人邮箱: recipient@example.com
邮件主题: 测试邮件 - {test_key}
邮件正文类型: 纯文本
邮件正文: 这是一封测试邮件。\n\n测试数据: {test_data}
```
4. **运行工作流**
- 输入参数：
```json
{
"test_key": "Hello World",
"test_data": "这是测试数据"
}
```
- 点击"运行"
- 检查执行结果
#### 方式二：使用Gmail SMTP
1. **配置Gmail应用专用密码**
- 登录Google账号
- 启用两步验证
- 生成应用专用密码
2. **配置邮件节点**
```
SMTP服务器: smtp.gmail.com
SMTP端口: 587
SMTP用户名: your-email@gmail.com
SMTP密码: [应用专用密码]
使用TLS: 是
发件人邮箱: your-email@gmail.com
收件人邮箱: recipient@example.com
邮件主题: 测试邮件
邮件正文: 这是一封测试邮件
```
### 测试2: RabbitMQ消息队列节点
#### 前置条件：启动RabbitMQ
**使用Docker启动RabbitMQ：**
```bash
docker run -d \
--name rabbitmq \
-p 5672:5672 \
-p 15672:15672 \
-e RABBITMQ_DEFAULT_USER=admin \
-e RABBITMQ_DEFAULT_PASS=admin123 \
rabbitmq:3-management
```
访问管理界面: http://localhost:15672 (用户名: admin, 密码: admin123)
#### 测试步骤
1. **在前端创建测试工作流**
- 添加节点：
- 开始节点
- 消息队列节点
- 结束节点
2. **配置消息队列节点**
```
队列类型: RabbitMQ
主机地址: localhost
端口: 5672
用户名: admin
密码: admin123
队列名称: test_queue
Routing Key: test.routing.key
消息内容: {"test_key": "{test_key}", "test_data": "{test_data}"}
```
3. **运行工作流**
- 输入参数：
```json
{
"test_key": "Hello RabbitMQ",
"test_data": "这是测试数据"
}
```
- 点击"运行"
- 在RabbitMQ管理界面查看队列中的消息
### 测试3: Kafka消息队列节点
#### 前置条件：启动Kafka
**使用Docker Compose启动Kafka：**
```yaml
# docker-compose-kafka.yml
version: '3.8'
services:
zookeeper:
image: confluentinc/cp-zookeeper:latest
environment:
ZOOKEEPER_CLIENT_PORT: 2181
ZOOKEEPER_TICK_TIME: 2000
ports:
- "2181:2181"
kafka:
image: confluentinc/cp-kafka:latest
depends_on:
- zookeeper
ports:
- "9092:9092"
environment:
KAFKA_BROKER_ID: 1
KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
```
启动命令：
```bash
docker-compose -f docker-compose-kafka.yml up -d
```
#### 测试步骤
1. **在前端创建测试工作流**
- 添加节点：
- 开始节点
- 消息队列节点（选择Kafka）
- 结束节点
2. **配置消息队列节点**
```
队列类型: Kafka
Bootstrap Servers: localhost:9092
Topic: test_topic
消息内容: {"test_key": "{test_key}", "test_data": "{test_data}"}
```
3. **运行工作流**
- 输入参数：
```json
{
"test_key": "Hello Kafka",
"test_data": "这是测试数据"
}
```
- 点击"运行"
- 使用Kafka消费者工具查看消息
## 🔍 验证要点
### 邮件节点验证
- ✅ 邮件成功发送
- ✅ 变量替换正确（主题和正文中的 {key} 被替换）
- ✅ HTML格式邮件正确渲染
- ✅ 附件正确附加（如果配置了附件）
### 消息队列节点验证
- ✅ 消息成功发送到队列
- ✅ 变量替换正确
- ✅ RabbitMQ: 消息出现在指定队列
- ✅ Kafka: 消息出现在指定Topic
## 🐛 常见问题
### 邮件节点问题
1. **SMTP连接失败**
- 检查SMTP服务器地址和端口
- 检查防火墙设置
- 确认TLS/SSL配置正确
2. **认证失败**
- 检查用户名和密码
- Gmail需要使用应用专用密码
- 确认账号已启用SMTP访问
3. **变量未替换**
- 确认输入数据中包含对应的key
- 检查变量格式：{key} 或 ${key}
### 消息队列节点问题
1. **RabbitMQ连接失败**
- 确认RabbitMQ服务正在运行
- 检查主机地址和端口
- 确认用户名和密码正确
2. **Kafka连接失败**
- 确认Kafka服务正在运行
- 检查Bootstrap Servers配置
- 确认Topic已创建
3. **消息未发送**
- 检查节点配置
- 查看执行日志
- 确认队列/Topic存在
## 📝 测试检查清单
- [ ] 邮件节点配置验证
- [ ] 邮件节点变量替换测试
- [ ] 邮件节点HTML格式测试
- [ ] 邮件节点附件测试（可选）
- [ ] RabbitMQ节点配置验证
- [ ] RabbitMQ节点消息发送测试
- [ ] Kafka节点配置验证
- [ ] Kafka节点消息发送测试
- [ ] 错误处理测试（无效配置）
- [ ] 执行日志验证
## 🎯 下一步
测试通过后，您可以：
1. 在实际工作流中使用这些节点
2. 继续开发其他功能（模板市场、协作、批量操作）
3. 优化节点功能和用户体验
---
**测试脚本位置**: `/home/renjianbo/aiagent/backend/test_email_mq_nodes.py`
**最后更新**: 2024年