目录

• 前置
• 背景
• 使用多智能体而不是硬编码的原因
• 对比n8n dify langGraph
• 架构
• 参考文章

前置

• 端到端产品级通用智能体--windows基于当前代码完整跑起来
• 端到端产品级通用智能体--JoyAgent总结之智能问数
• 端到端产品级通用智能体--JoyAgent总结之深度搜索智能问答

背景

• 我们组是做各个场景监控的，线上机器有非常多，每个小的监控场景都不一样，小监控场景非常广，并不是传统意思的机器CPU, 内存等简单监控，本质上是对所有机器从各个维度，运营商，省份，大洲，大区等维度做告警。线上也有非常多的告警，那某些重要的告警要定位到这个告警的根本原因就成了运营比较迫切需要解决的问题，如果每个重要场景都人工去定位那么根据不同的人专业程度定位速度也不一样，短则二十分钟，长则一小时。这就迫切需要一个平台，能够支持运营人员用自然语言的形式，描述如何通过各个小场景(可以抽象成一个个sql)定位到当前重要场景的根因
• prompt类似下面这样

请基于以下字典集合对 POP 进行根因归类。所有集合运算严格按 key 精确匹配（区分大小写），禁止模糊匹配；差集必须逐元素核对。输出中必须显式列出所有中间集合与依据。

输入：
- Tag1: {...}（主集合，key=POP，value=详情文本）
- TagB: {...}
- TagB_1: {...}
- TagB_2: {...}
- TagC: {...}
- TagD: {...}
- TagE: {...}
- TagF: {...}
- TagG: {...}
- TagH: {...}
- TagI: {...}
- TagJ: {...}
- TagK: {...}
- TagL: {...}
- TagM: {...}

规则：
Step0: 若 Tag1.keys() 为空，输出“所有数据正常”并停止。否则显式列出 TagA.keys()

A: candidate_A = Tag1.keys() - TagB.keys()
  在 candidate_A 中：
  - ∩TagC → 原因1；∩TagD → 原因2；∩TagE → 原因3；∩TagF → 原因4

A.5: candidate_A5 = candidate_A - TagG.keys()（逐元素检查）
  在 candidate_A5 中：
  - ∩TagH → 原因5；∩TagI → 原因6；∩TagJ → 原因7；∩TagK → 原因8；∩TagL → 原因9
  - 若 TagA[POP] 同时包含 KW_in 与 KW_out → 原因10
  - 若包含 KW_out 且不包含 KW_in 且 POP∈TagM → 原因11

B: candidate_B = TagA.keys() ∩ TagB.keys()
  在 candidate_B 中：
  - ∩TagB_1 → 原因12；∩TagB_2 → 原因13
  且 candidate_B 禁止参与 A/A.5

C: 对未命中任何原因者：
  candidate_C = TagA.keys() - (assigned_A ∪ assigned_A5 ∪ assigned_B)
  candidate_C 中每个 POP → “需人工确认”

输出：
按 POP 分组输出命中原因；同一 POP 多原因用中文逗号连接。所有中间集合必须显式输出。

使用多智能体而不是硬编码的原因

• 目前V1.0是定时任务自动获取重要异常告警，然后去定位根因
• 后续V2.0需要实现一个前端界面，或者AI2UI模式，运营人员或者非技术研发人员，在页面上提问比如: 某个时间段福建移动的POP中某几个场景的，xxx特定条件下，根因是什么，这时候这套提醒需要前面加个主路由Agent解析意图，然后发给这个告警根因定位项目去定位。特定拓展条件这套根因项目可以做拓展满足。
• 每个运营人员排查同一个场景排查习惯有所差异，所以prompt略微不同，特殊pop，条件略微有差异。提交prompt后会经过prompt优化器处理。这个过程没法通过固定代码实现，就是某个固定模板---大模型通过固定模版生成代码的模式不太能行的通，因为prompt有差异
• 本质上需要跟人交互部分，没法固定代码加规则引擎去实现
• 如果有些只是详情数据展示用的，后续可以考虑使用本地内存做传输，如果系统高可用就放到第三方缓存去，记录的时候再取出

对比n8n dify langGraph

• Dify + LangGraph对比

  
  
  Dify+LangGraph.png

• LangGraph + (PlanAgent+ExecutorAgent)

  
  
  LangGraph + (PlanAgent+ExecutorAgent).png

• n8n：低代码自动化工作流引擎

1. 定位：无代码/低代码自动化工具，用于连接 API 和系统，非大模型 Agent 框架。
   核心能力
2. 通过可视化流程图（Node-Edge）编排任务（如触发 → 处理 → 执行）
   支持 300+ 应用集成（Slack、Google Sheets、数据库等）
   无原生大模型集成，需通过 API 调用外部 LLM 服务

架构

模式

• ReAct (Reasoning and Acting) 是大模型的一种推理框架，通过交替进行"思考(Thought)-行动(Action)-观察(Observation)"的循环来解决问题。这种模式将语言模型的推理能力与行动能力相结合，使模型不仅能"思考"，还能"行动"并根据结果调整策略。核心工作流程：

1. 思考(Thought): 分析当前状态，制定下一步策略
2. 行动(Action): 执行具体操作（如搜索、计算、调用API等）
3. 观察(Observation): 获取行动结果，作为下一步输入
4. 重复上述过程，直至解决问题

• 其他模式优劣势

  
  
  其他模式优劣势.png
• 模式对比

• 模式对比2

架构

• 完全参考joyagent多agent架构。上面前置部分的文章有详细介绍

  
  
  整体架构.png
• ExecutorAgent会根据PlanningAgent给的子任务进行循环step，每步step包含，think和act。
  1. PlanningAgent规划的动态任务流tag1前置检查任务到来时，ExecutorAgent中think流程会从prompt捞取tag1的数据，然后act流程会去调用clickhouse_mcp获取对应数据，下一个think认为条件已经充分便结束当前子流程，如果ExecutorAgent调用失败或者信息不全这种step模式能自动重试
  2. 带着动态任务流tag1前置检查任务的结果和按需生成相关Tag查询的子任务PlanningAgent也是用step循环决策，think一下，如果tag1无数据则直接标志着任务结束。如果有数据则获取prompt其他需要执行的sql集合，然后act会去调用clickhouse_mcp获取对应数 , 这个具体的执行是ExecutorAgent去执行，PlanExecutor只是规划
  3. 如果第2步没有标志PlanTool结束，则第三步大模型think会带入第2步结果和对应prompt的规则进行决策，最终执行也是ExecutorAgent去的
  4. 如果第2步没有标志PlanTool结束，第4步会根据第3步定位的根因将结果记录，这个结果记录是ExecutorAgent去执行的

• clickhosue_mcp架构

  
  
  clickhosue_mcp架构.png
• mcp架构优点

参考文章

• joyagent