从简单聊天机器人到多Agent协作系统的技术演进
通俗来说，AI Agent（智能体）= LLM + 记忆 + 工具 + 规划能力
AI Agent = 大脑(LLM) + 记忆 + 工具 + 规划 ┌──────────────────────────────────────────┐ │ AI Agent │ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ 🧠 LLM │ │ 📝 记忆 │ │ │ │ (大脑) │ │ (上下文) │ │ │ │ 理解/推理 │ │ 对话历史 │ │ │ │ 生成/规划 │ │ 用户偏好 │ │ │ └──────────┘ └──────────┘ │ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ 🔧 工具 │ │ 📋 规划 │ │ │ │ 搜索 │ │ 分解任务 │ │ │ │ 文件操作 │ │ 制定步骤 │ │ │ │ API调用 │ │ 评估结果 │ │ │ └──────────┘ └──────────┘ │ └──────────────────────────────────────────┘
类比：如果LLM是"大脑"，那么Agent就是一个"有大脑、有记忆、会用工具、能做计划的完整员工"。
第一代：纯对话 (2023年初)
用户: "帮我写一封邮件"
│
▼
┌──────────┐
│ LLM │ → "好的，以下是邮件内容：..."
└──────────┘
特点:
· 一问一答，无记忆
· 不能使用工具
· 不能访问外部数据
· 不能处理复杂任务
例子: 早期的ChatGPT网页版
第二代：带记忆 (2023年中)
用户: "帮我写一封邮件"
│
├── 对话历史注入
▼
┌──────────────────────┐
│ LLM │
│ 输入: │
│ [System: 你是助手] │
│ [History: ...] │
│ [User: 写邮件] │
└──────────────────────┘
特点:
· 多轮对话，记住上下文
· 但仍然不能"行动"
· 本项目的体现: ChatMessageEntity 历史管理
Token预算截断策略
Token预算截断 (本项目实现):
┌────────────────────────────────┐
│ 总Token预算: 8000 │
│ 系统提示词: -1000 │
│ 工具描述: -500 │
│ 当前消息: -200 │
│ ────────────── │
│ 历史可用: 6300 Token │
│ │
│ 从最早的对话开始截断 │
│ 保留最近的重要对话 │
└────────────────────────────────┘
第三代：ReAct推理 (2024年) ← 本项目的核心架构
用户: "帮我查一下北京今天的天气，并推荐穿搭"
│
▼
┌──────────────────────────────────────────────┐
│ ReAct 推理循环 │
│ │
│ Round 1: │
│ Thought: 用户想知道北京天气，我需要搜索 │
│ Action: 调用搜索工具("北京天气今天") │
│ Observation: 北京今天 15°C，多云转晴 │
│ │
│ Round 2: │
│ Thought: 已获取天气信息，现在推荐穿搭 │
│ Action: 无需工具，直接回答 │
│ Answer: 北京今天15度多云转晴，建议穿... │
└──────────────────────────────────────────────┘
ReAct = Reasoning (推理) + Acting (行动)
本项目的实现:
· 4节点Graph: LLM → BRANCH → TOOL/END
· BRANCH节点: 分析LLM输出，判断是否有工具调用
· TOOL节点: 执行工具，将结果注入消息列表
· 循环直到LLM不再调用工具 → END节点输出最终答案
工具调用检测:
┌─────────────────────────────────────┐
│ 优先: 原生ToolCall结构体 │
│ {function: {name: "search", │
│ arguments: {query: "北京天气"}}} │
│ │
│ 兜底: 正则解析JSON │
│ {"tool":"search","arguments":{...}} │
└─────────────────────────────────────┘
第四代：多Agent协作 ← 本项目的并行执行引擎
用户: "分析这份报告，翻译成英文，并生成PPT大纲"
│
▼
┌─────────────────────────────────────────────┐
│ 主Agent (Orchestrator) │
│ │
│ LLM判断: 需要3个子Agent并行协作 │
│ │
│ dispatch_agents: [ │
│ {agent: "rag", task: "分析报告"}, │
│ {agent: "translate", task: "翻译"}, │
│ {agent: "ppt", task: "生成大纲"} │
│ ] │
└──────┬──────────────┬──────────────┬────────┘
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│ RAG │ │ Translate│ │ PPT │
│ Agent │ │ Agent │ │ Agent │
│(并行) │ │(并行) │ │(并行) │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└──────┬───────┴──────────────┘
│
Merger汇总
│
▼
主Agent综合所有结果
→ 最终输出
本项目三种并行模式:
┌──────────────────────────────────────┐
│ Level 1: ParallelToolExecutor │
│ → 同时执行多个工具调用 │
│ │
│ Level 2: SubAgentGraphBuilder │
│ → 同时派发多个子Agent │
│ │
│ Level 3: TaskDecompExecutor │
│ → 将大任务分解为N个子任务并行执行 │
└──────────────────────────────────────┘
第五代：自主规划 ← 本项目的Plan Mode
用户: "帮我准备下周的产品发布会"
│
▼
┌──────────────────────────────────────────────┐
│ Plan Mode (计划模式) │
│ │
│ Step 1: LLM生成执行计划 │
│ ┌──────────────────────────────────────┐ │
│ │ 📋 执行计划: │ │
│ │ 1. 收集产品资料 (RAG Agent) │ │
│ │ 2. 撰写发布会演讲稿 (文案Agent) │ │
│ │ 3. 制作PPT大纲 (PPT Agent) │ │
│ │ 4. 生成邀请函 (文案Agent) │ │
│ │ │ │
│ │ 预计需要: 15分钟 │ │
│ │ 是否确认执行? [确认] [修改] [取消] │ │
│ └──────────────────────────────────────┘ │
│ │
│ Step 2: 用户确认后，逐步执行 │
│ Step 3: 每步可HITL审批 │
│ Step 4: 汇总所有步骤结果 │
└──────────────────────────────────────────────┘
行业Agent框架对比: ┌───────────────────────────────────────────────────────┐ │ 复杂度 │ │ │ │ 低 ←──────────────────────────────────────→ 高 │ │ │ │ LangChain AutoGPT CrewAI MetaGPT │ │ (简单链式) (自主Agent) (多Agent) (多Agent+角色) │ │ ↑ │ │ │ │ │ ┌────┴──────────────────────────────────────┐ │ │ │ Enterprise Agent Hub (本项目) │ │ │ │ │ │ │ │ · 比LangChain更强: Graph引擎+并行执行 │ │ │ │ · 比AutoGPT更稳: 熔断/限流/安全防护 │ │ │ │ · 比CrewAI更全: 17个Agent+多通道+RAG │ │ │ │ · 企业级: 密钥池/降级/可观测性/审计 │ │ │ └───────────────────────────────────────────┘ │ └───────────────────────────────────────────────────────┘