aiagent/docs/architecture/缺失能力.md

缺失能力分析

概述

当前项目已有 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 异步执行	第三梯队	低	调度可用性