- 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>
203 lines
7.0 KiB
Markdown
203 lines
7.0 KiB
Markdown
# 缺失能力分析
|
||
|
||
## 概述
|
||
|
||
当前项目已有 34 个内置工具、自主进化系统(agent_create / tool_register / code_tool_create / capability_check / extension_log)、工作流引擎(DAG + HITL 审批节点)、Agent 记忆系统(RAG + 向量 + 持久化)、异步执行(Celery + Redis)等能力。但在生产级复杂任务执行方面,仍存在以下 10 项关键缺失。
|
||
|
||
---
|
||
|
||
## 第一梯队:复杂任务的硬伤(3 项)
|
||
|
||
### 1. 完全没有并行执行
|
||
|
||
**现象:**
|
||
- 工作流 DAG 一次只执行一个节点,即使多个分支之间没有依赖关系
|
||
- Orchestrator 的 debate 模式 3 个 Agent 逐个串行执行,而非并发
|
||
- `orchestrator.py` 中 debate 用的是 `for agent in agents` 循环,而非 `asyncio.gather`
|
||
|
||
**影响:**
|
||
- 复杂任务耗时 = 所有步骤耗时之和,而非最长路径耗时
|
||
- 多 Agent 协作(并行分析、投票)形同虚设
|
||
- 吞吐量瓶颈
|
||
|
||
**涉及文件:**
|
||
- `backend/app/services/workflow_engine.py` — DAG 执行循环(`execute()` 方法)
|
||
- `backend/app/agent_runtime/orchestrator.py` — `_debate()` 方法
|
||
|
||
---
|
||
|
||
### 2. AgentOrchestrator 不进入工作流
|
||
|
||
**现象:**
|
||
- Orchestrator 的 4 种模式(router / sequential / debate / pipeline)仅通过 API 端点 `/orchestrate` 暴露
|
||
- 工作流引擎的节点类型只有 `start / llm / agent / approval / condition / end` 等,没有 `orchestrator`
|
||
- 编排能力与工作流系统完全割裂
|
||
|
||
**影响:**
|
||
- 无法在工作流中组合多 Agent 协作模式
|
||
- 复杂场景需要外部脚本调用 API,无法在工作流中可视化编排
|
||
|
||
**涉及文件:**
|
||
- `backend/app/api/agent_chat.py` — Orchestrator API 入口
|
||
- `backend/app/services/workflow_engine.py` — 缺少 orchestrator 节点类型
|
||
- `backend/app/agent_runtime/workflow_integration.py` — 只有 `run_agent_node()`,无 `run_orchestrator_node()`
|
||
|
||
---
|
||
|
||
### 3. 输出质量验证完全缺失
|
||
|
||
**现象:**
|
||
- 没有评判/评估节点检查 Agent 输出质量
|
||
- 搜索 `evaluate_output`、`verify_result`、`quality_check`、`validate_node` — 零结果
|
||
- Agent 执行完直接返回结果,不对质量做任何检查
|
||
- `AgentLearningPattern` 只在后台统计成功率,不做实时检查
|
||
|
||
**影响:**
|
||
- Agent 不知道自己做得好不好
|
||
- 错误结果直接交付用户
|
||
- 自我修正闭环缺失最关键的一环
|
||
|
||
**涉及文件:**
|
||
- 无现有实现,需从零构建
|
||
|
||
---
|
||
|
||
## 第二梯队:生产可靠性(3 项)
|
||
|
||
### 4. 节点级自动重试是空壳
|
||
|
||
**现象:**
|
||
- `error_handler` 节点类型存在,但只记录意图不实际重试(代码注释:"实际重试需要重新执行前一个节点,这里只记录")
|
||
- 一个节点失败 → `WorkflowExecutionError` → 整个工作流停止
|
||
- Celery 层面有任务级重试(指数退避),但节点级没有
|
||
|
||
**影响:**
|
||
- LLM 调用偶发超时 = 整个工作流失败
|
||
- 无法配置"这个节点失败后重试 3 次"
|
||
|
||
**涉及文件:**
|
||
- `backend/app/services/workflow_engine.py` — error_handler 节点(约 4068-4128 行)
|
||
- `backend/app/tasks/workflow_tasks.py` — Celery 重试逻辑
|
||
|
||
---
|
||
|
||
### 5. 工具级人工审批缺失
|
||
|
||
**现象:**
|
||
- 人工审批(HITL)只存在于工作流节点层面(`approval` 节点类型)
|
||
- AgentRuntime 对所有工具自动执行,不暂停确认
|
||
- `deploy_push`、`send_email`、`database_query`(写操作)、`schedule_create` 等风险工具无二次确认
|
||
|
||
**影响:**
|
||
- Agent 可能执行危险操作而用户不知情
|
||
- 缺少安全围栏
|
||
|
||
**涉及文件:**
|
||
- `backend/app/agent_runtime/core.py` — ReAct 循环中工具自动执行
|
||
- `backend/app/agent_runtime/schemas.py` — `AgentToolConfig` 缺少审批配置
|
||
- `backend/app/services/workflow_engine.py` — approval 节点(约 1374-1422 行,可复用逻辑)
|
||
|
||
---
|
||
|
||
### 6. 没有降级/回退链
|
||
|
||
**现象:**
|
||
- 模型不可用 → Agent 直接报错
|
||
- Agent 执行失败 → 无备选方案
|
||
- 搜索 `fallback`、`degradation`、`backup` — 零结果
|
||
|
||
**影响:**
|
||
- 单点故障无容错
|
||
- 无法配置"主模型挂了自动切备用模型"
|
||
|
||
**涉及文件:**
|
||
- `backend/app/agent_runtime/schemas.py` — `AgentLLMConfig` 无 fallback 字段
|
||
- `backend/app/agent_runtime/core.py` — ReAct 循环无模型切换逻辑
|
||
|
||
---
|
||
|
||
## 第三梯队:体验与效率(4 项)
|
||
|
||
### 7. 进度上报太粗糙
|
||
|
||
**现象:**
|
||
- WebSocket 只推送 `status: "running"` 和 `status: "completed"`
|
||
- 进度值固定:0 → 50 → 100,没有实际进度百分比
|
||
- WebSocket 每 2 秒轮询 DB,而非主动推送
|
||
|
||
**影响:**
|
||
- 用户看不到任务执行到哪一步
|
||
- 复杂任务(7 步)和简单任务(2 步)进度条一样
|
||
|
||
**涉及文件:**
|
||
- `backend/app/websocket/manager.py` — WebSocket 管理器(轮询 DB)
|
||
- `backend/app/services/workflow_engine.py` — 无进度回调钩子
|
||
- `backend/app/tasks/workflow_tasks.py` — Celery 进度更新只调一次
|
||
|
||
---
|
||
|
||
### 8. Agent 间知识不共享
|
||
|
||
**现象:**
|
||
- 每个 Agent 的 RAG 记忆按 `(scope_kind, scope_id)` 隔离
|
||
- 学习模式也按 Scope 隔离
|
||
- "SQL优化专家"学到的知识,"数据分析师"用不了
|
||
|
||
**影响:**
|
||
- 知识孤岛,重复学习
|
||
- 自主进化创建的 Agent 从零开始,无法继承父 Agent 经验
|
||
|
||
**涉及文件:**
|
||
- `backend/app/agent_runtime/memory.py` — 记忆隔离
|
||
- `backend/app/services/agent_learning_service.py` — 学习模式隔离
|
||
|
||
---
|
||
|
||
### 9. 没有结果缓存
|
||
|
||
**现象:**
|
||
- 相同查询发给同一 Agent,每次都完整执行 LLM + 工具
|
||
- 工具结果、LLM 响应均不缓存
|
||
- 搜索 `cache`、`redis_cache`、`ttl` — 仅在 Celery 配置中有 `result_backend`
|
||
|
||
**影响:**
|
||
- 重复工作浪费 token 和时间
|
||
- 同一用户反复问相似问题,每次都重新跑
|
||
|
||
**涉及文件:**
|
||
- 无现有实现,需从零构建
|
||
|
||
---
|
||
|
||
### 10. Agent 独立异步执行是空壳
|
||
|
||
**现象:**
|
||
- `execute_agent_task`(Celery 任务)返回 `{"status": "pending"}` 占位符
|
||
- 代码注释:`# TODO: 实现Agent执行逻辑`
|
||
- 非工作流的 Agent 执行没有真正的异步支持(只能同步调用 API)
|
||
|
||
**影响:**
|
||
- Agent 聊天无法异步后台执行
|
||
- 调度触发的 Agent 执行不会真正运行
|
||
|
||
**涉及文件:**
|
||
- `backend/app/tasks/agent_tasks.py` — execute_agent_task 是空壳
|
||
- `backend/app/tasks/scheduler_tasks.py` — 定时调度无法真正执行 Agent
|
||
|
||
---
|
||
|
||
## 总结
|
||
|
||
| # | 缺失能力 | 梯队 | 复杂度 | 影响面 |
|
||
|---|---------|------|--------|--------|
|
||
| 1 | 并行执行 | 第一梯队 | 高 | 性能、吞吐量 |
|
||
| 2 | Orchestrator 入工作流 | 第一梯队 | 中 | 编排能力整合 |
|
||
| 3 | 输出质量验证 | 第一梯队 | 中 | 结果可靠性 |
|
||
| 4 | 节点级自动重试 | 第二梯队 | 低 | 稳定性 |
|
||
| 5 | 工具级人工审批 | 第二梯队 | 中 | 安全性 |
|
||
| 6 | 降级/回退链 | 第二梯队 | 低 | 容错性 |
|
||
| 7 | 粒度进度上报 | 第三梯队 | 低 | 用户体验 |
|
||
| 8 | Agent 知识共享 | 第三梯队 | 高 | 知识利用率 |
|
||
| 9 | 结果缓存 | 第三梯队 | 中 | 效率、成本 |
|
||
| 10 | Agent 异步执行 | 第三梯队 | 低 | 调度可用性 |
|