目錄

• 前置
• 背景
• 使用多智能體而不是硬編碼的原因
• 對比n8n dify langGraph
• 架構(gòu)
• 參考文章

前置

• 端到端產(chǎn)品級通用智能體--windows基于當(dāng)前代碼完整跑起來
• 端到端產(chǎn)品級通用智能體--JoyAgent總結(jié)之智能問數(shù)
• 端到端產(chǎn)品級通用智能體--JoyAgent總結(jié)之深度搜索智能問答

背景

• 我們組是做各個場景監(jiān)控的，線上機(jī)器有非常多，每個小的監(jiān)控場景都不一樣，小監(jiān)控場景非常廣，并不是傳統(tǒng)意思的機(jī)器CPU, 內(nèi)存等簡單監(jiān)控，本質(zhì)上是對所有機(jī)器從各個維度，運(yùn)營商，省份，大洲，大區(qū)等維度做告警。線上也有非常多的告警，那某些重要的告警要定位到這個告警的根本原因就成了運(yùn)營比較迫切需要解決的問題，如果每個重要場景都人工去定位那么根據(jù)不同的人專業(yè)程度定位速度也不一樣，短則二十分鐘，長則一小時。這就迫切需要一個平臺，能夠支持運(yùn)營人員用自然語言的形式，描述如何通過各個小場景(可以抽象成一個個sql)定位到當(dāng)前重要場景的根因
• prompt類似下面這樣

請基于以下字典集合對 POP 進(jìn)行根因歸類。所有集合運(yùn)算嚴(yán)格按 key 精確匹配（區(qū)分大小寫），禁止模糊匹配；差集必須逐元素核對。輸出中必須顯式列出所有中間集合與依據(jù)。

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

規(guī)則：
Step0: 若 Tag1.keys() 為空，輸出“所有數(shù)據(jù)正?！辈⑼Ｖ埂７駝t顯式列出 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 → “需人工確認(rèn)”

輸出：
按 POP 分組輸出命中原因；同一 POP 多原因用中文逗號連接。所有中間集合必須顯式輸出。

使用多智能體而不是硬編碼的原因

• 目前V1.0是定時任務(wù)自動獲取重要異常告警，然后去定位根因
• 后續(xù)V2.0需要實(shí)現(xiàn)一個前端界面，或者AI2UI模式，運(yùn)營人員或者非技術(shù)研發(fā)人員，在頁面上提問比如: 某個時間段福建移動的POP中某幾個場景的，xxx特定條件下，根因是什么，這時候這套提醒需要前面加個主路由Agent解析意圖，然后發(fā)給這個告警根因定位項(xiàng)目去定位。特定拓展條件這套根因項(xiàng)目可以做拓展?jié)M足。
• 每個運(yùn)營人員排查同一個場景排查習(xí)慣有所差異，所以prompt略微不同，特殊pop，條件略微有差異。提交prompt后會經(jīng)過prompt優(yōu)化器處理。這個過程沒法通過固定代碼實(shí)現(xiàn)，就是某個固定模板---大模型通過固定模版生成代碼的模式不太能行的通，因?yàn)閜rompt有差異
• 本質(zhì)上需要跟人交互部分，沒法固定代碼加規(guī)則引擎去實(shí)現(xiàn)
• 如果有些只是詳情數(shù)據(jù)展示用的，后續(xù)可以考慮使用本地內(nèi)存做傳輸，如果系統(tǒng)高可用就放到第三方緩存去，記錄的時候再取出

對比n8n dify langGraph

• Dify + LangGraph對比

  
  
  Dify+LangGraph.png

• LangGraph + (PlanAgent+ExecutorAgent)

  
  
  LangGraph + (PlanAgent+ExecutorAgent).png

• n8n：低代碼自動化工作流引擎

1. 定位：無代碼/低代碼自動化工具，用于連接 API 和系統(tǒng)，非大模型 Agent 框架。
   核心能力
2. 通過可視化流程圖（Node-Edge）編排任務(wù)（如觸發(fā) → 處理 → 執(zhí)行）
   支持 300+ 應(yīng)用集成（Slack、Google Sheets、數(shù)據(jù)庫等）
   無原生大模型集成，需通過 API 調(diào)用外部 LLM 服務(wù)

架構(gòu)

模式

• ReAct (Reasoning and Acting) 是大模型的一種推理框架，通過交替進(jìn)行"思考(Thought)-行動(Action)-觀察(Observation)"的循環(huán)來解決問題。這種模式將語言模型的推理能力與行動能力相結(jié)合，使模型不僅能"思考"，還能"行動"并根據(jù)結(jié)果調(diào)整策略。核心工作流程：

1. 思考(Thought): 分析當(dāng)前狀態(tài)，制定下一步策略
2. 行動(Action): 執(zhí)行具體操作（如搜索、計(jì)算、調(diào)用API等）
3. 觀察(Observation): 獲取行動結(jié)果，作為下一步輸入
4. 重復(fù)上述過程，直至解決問題

• 其他模式優(yōu)劣勢

  
  
  其他模式優(yōu)劣勢.png
• 模式對比

• 模式對比2

架構(gòu)

• 完全參考joyagent多agent架構(gòu)。上面前置部分的文章有詳細(xì)介紹

  
  
  整體架構(gòu).png
• ExecutorAgent會根據(jù)PlanningAgent給的子任務(wù)進(jìn)行循環(huán)step，每步step包含，think和act。
  1. PlanningAgent規(guī)劃的動態(tài)任務(wù)流tag1前置檢查任務(wù)到來時，ExecutorAgent中think流程會從prompt撈取tag1的數(shù)據(jù)，然后act流程會去調(diào)用clickhouse_mcp獲取對應(yīng)數(shù)據(jù)，下一個think認(rèn)為條件已經(jīng)充分便結(jié)束當(dāng)前子流程，如果ExecutorAgent調(diào)用失敗或者信息不全這種step模式能自動重試
  2. 帶著動態(tài)任務(wù)流tag1前置檢查任務(wù)的結(jié)果和按需生成相關(guān)Tag查詢的子任務(wù)PlanningAgent也是用step循環(huán)決策，think一下，如果tag1無數(shù)據(jù)則直接標(biāo)志著任務(wù)結(jié)束。如果有數(shù)據(jù)則獲取prompt其他需要執(zhí)行的sql集合，然后act會去調(diào)用clickhouse_mcp獲取對應(yīng)數(shù) , 這個具體的執(zhí)行是ExecutorAgent去執(zhí)行，PlanExecutor只是規(guī)劃
  3. 如果第2步?jīng)]有標(biāo)志PlanTool結(jié)束，則第三步大模型think會帶入第2步結(jié)果和對應(yīng)prompt的規(guī)則進(jìn)行決策，最終執(zhí)行也是ExecutorAgent去的
  4. 如果第2步?jīng)]有標(biāo)志PlanTool結(jié)束，第4步會根據(jù)第3步定位的根因?qū)⒔Y(jié)果記錄，這個結(jié)果記錄是ExecutorAgent去執(zhí)行的

• clickhosue_mcp架構(gòu)

  
  
  clickhosue_mcp架構(gòu).png
• mcp架構(gòu)優(yōu)點(diǎn)

參考文章

• joyagent