---

前言

随着人工智能的不断发展，基于大语言模型构建的智能体应运而生，他解决了大模型天生自带的幻觉等问题，同时还能赋予模型以双手，去执行复杂的操作。随着业务的复杂性提高，传统的单Agent无法满足多任务的有效执行。因此，诸如Manus、AutoGpt、CrewAI等多智能体协同系统（Multi-Agent System, MAS）就成为了解决复杂任务的核心范式。本文，将参考其他MAS的思路，基于LangGraph实现一个多智能体的协同系统。同时，在协同调度的基础上，提供2大核心功能：可编排和可交互。

---

一、MAS在AIOps的应用

本文是基于该协同系统开发的AIOps-多场景智能运维系统，旨在通过智能化、自动化的手段优化IT运维流程，减少人为错误，提高响应速度和服务质量。
随着数字化转型的加速，企业对IT系统的依赖程度日益增加。数据中心规模不断扩大，系统复杂性也随之增加，这使得传统运维方法难以满足高效、快速响应的需求，转而寻求更加高效的智能化运维。

二、技术实现

1. 技术架构

采用LLM+Prompt的运维模型，多Agent的协同编排调度机制，构建运维高质量数据，实现根因分析和自动化运维。

2. 流程图

为了直观地展示整个MAS的流程，将按以下流程图进行展开说明：

我们知道，在多智能体协同系统中，智能体作为核心中的核心，肯定是必不可少的。我们把智能体分为2类：其中，灰色的为功能型智能体，如分类器、计划者、调度者、分析者等；蓝色的为工具型智能体，如日志Agent、数据库Agent、磁盘Agent等。同时，也引入了检查点，作为人机交互的关键节点，为介入智能体与智能体之间的圆圈。

整体流程如下：

1. 用户接收到系统告警信息，通过自然语言与统一入口交互。
2. 分类器（Classifier）将问题进行分类，问题类型包括：根因分析、信息查询、系统巡检…；时间类型包括：接口超时、系统异常、磁盘不足…；同时，获取或生成关键时间节点并抓取关键信息，形成查问题的最基本数据。
3. 计划者（Planner）根据沉淀的运维知识库，以及当前能使用的智能体信息，生成详细的执行步骤1…n。
4. 调度者（Supervisor）根据计划和调度规则，合理地安排给每一个工具型智能体任务，或者判断为流程结束。
5. 工具型智能体（Tool Agents）作为附带工具的智能体集合，作为一个池子供调度者进行调度，使用其各自擅长的领域进行数据的收集和操作的执行。
6. 分析者（Analyser）会结合多个信息源（用户的原始问题，工具智能体的结果，运维知识库信息）进行统一的分析，形成分析结论反馈给调度者。
7. 以上流程进行循环直至找到根因或流程结束。
8. 如遇检查点，如 Classifier和Planner，则提供人机交互模式，根据人的反馈再判断下一步执行。

3. 可编排和可交互

前言中提到，本系统的2个关键核心是：可编排和可交互。
1）可编排（Orchestration）：

• 采用 DAG 结构 定义任务流程，支持条件分支、循环等复杂逻辑。
• 通过 LangGraph 的节点（Node）和边（Edge）机制，实现智能体的动态调度。
• 示例：在客服场景中，系统可自动判断用户问题类型，并路由至对应的业务处理Agent（如订单查询、售后支持等）。

指的是整个业务流程是可以动态编排的。虽然上面的流程图看似是固定的一个流程，但如果变为其他不同的业务场景，基于该系统能通过配置化快速编排出一个新的流程。这个动态编排的核心，就在于将LangGraph中所有的节点和边都进行配置化，然后通过统一的工作流配置实现。

代码如下（展示部分代码）：

# 流程配置
WORKFLOW_CONFIG='{
 "nodes": [
   {
     "id": "1",
     "name": "Classifier",
     "class": "agents.func_agents.Classifier"
   },
   {
     "id": "2",
     "name": "Planner",
     "class": "agents.func_agents.Planner"
   },
   ...
   {
     "id": "10",
     "name": "GcAgent",
     "class": "agents.tool_agents.GcAgent"
   }
 ],
 "edges": [
   {
     "source": "Classifier",
     "target": "Planner"
   },
   {
     "source": "Planner",
     "target": "Supervisor"
   },
   {
     "source": "Supervisor",
     "target": ["LogAgent", "TraceAgent", "DbAgent", "MetricsAgent", "DiskAgent", "GcAgent", "CalcAgent", "FINISH"]
   },
   {
     "source": ["LogAgent", "TraceAgent", "DbAgent", "MetricsAgent", "DiskAgent", "GcAgent", "CalcAgent"],
     "target": "Analyser"
   },
   {
     "source": "Analyser",
     "target": "Supervisor"
   }
 ]
}'

1）可交互（Interactivity）

• 人机协同：允许人类在关键节点介入，如审核智能体的决策或提供额外输入。
• 智能体间通信：支持智能体通过消息传递（如共享内存、Pub/Sub 模式）交换信息。
• 示例：在内容生成任务中，编辑Agent可对写作Agent的初稿进行修订，或请求用户确认关键信息。

指的是在智能体调度的过程中，可以进行人为的干预，可以完全通过自然语言，并不限于是/否。目前，大多数智能体的任务执行，是不支持人为干预的，多数是将复杂任务分解，然后依次地执行。有时可能会出现需要选择的安全性校验。
在该系统中，可交互是基于LangGraph的人在环路(Human-in-the-loop,简称HIL)实现。通过给某个智能体预设“前置检查规则”和“后置检查规则”集合，当智能体执行时，动态判断智能体是否存在检查规则，如存在则进入检查点。在检查点内部，并非都需要人工干预，而是基于大模型、检查规则、历史会话等信息进行专业的判断，最终反馈某一个状态：执行、人工、重试、中断。

代码如下（展示部分代码）：

# 添加检查节点
if hasattr(agent, 'pre_check_rules') and agent.pre_check_rules:
   check_info = {
       "node_id": node_name,
       "check_node_id": f"pre_check_{node_name.lower()}",
       "check_rules": agent.pre_check_rules,
       "input_keys": getattr(agent, 'input_keys', None),
       "check_type": "pre"
   }
   workflow.add_node(f"pre_check_{node_name.lower()}", 
       lambda state, check_info=check_info: pre_checkpoint_node(state, check_info))

if hasattr(agent, 'post_check_rules') and agent.post_check_rules:
   check_info = {
       "node_id": node_name,
       "check_node_id": f"post_check_{node_name.lower()}",
       "check_rules": agent.post_check_rules,
       "input_keys": getattr(agent, 'input_keys', None),
       "check_type": "post"
   }
   workflow.add_node(f"post_check_{node_name.lower()}", 
       lambda state, check_info=check_info: post_checkpoint_node(state, check_info))
-------------------------------------------------------------------------------------
# 如果存在前置检查点
if f"pre_check_{tar.lower()}" in workflow.nodes:
     # 添加前置检查点的条件边
     workflow.add_conditional_edges(
         f"pre_check_{tar.lower()}",
         route_edge,
         {
             "continue": tar,
             "retry": f"pre_check_{tar.lower()}",
             "human_node": "human_node",
             "finish": "FINISH"
         }
     )
-------------------------------------------------------------------------------------
# 人工节点，处理用户反馈并决定下一步操作
def human_node(state: MyStreamAgentState):
    validation_result = state['validation_result']
    print(f"---human_feedback 节点-验证规则: {validation_result}---")
    feedback = interrupt(validation_result)
    print(f"---human_feedback 节点-用户反馈: {feedback}---")

    human_message = HumanMessage(content=feedback)
    current_node = state['current_node']
    # 如果有前一个节点，设置返回到该节点
    if current_node:
        return {
            'next_node': current_node, 
            'current_node': '', # 清除current_node，避免循环
            'user_feedback': feedback, 
            'messages': [human_message]
        }
    else:
        return {
            'next_node': 'continue', 
            'user_feedback': feedback,
            'messages': [human_message]
        }

4. 提示词

由于提示词较长，只展示计划者和工具类智能体的提示词

计划者提示词

PLANNER_PROMPT = """
[角色]
你是一位资深的IT运维规划专家, 擅长根据问题类型制定详细的处理步骤和解决方案。

[任务]
1. 分析用户的系统问题
2. 根据知识库内容制定解决方案
3. 提供清晰、有序的处理步骤
4. 合理规划合适的系统智能体

[上下文]
- 当前时间信息: {current_time}
- 以下是可用的知识库内容，这是你进行规划的唯一依据：
<知识库>
{knowlege_plan}
</知识库>
- 以下是可用的系统智能体信息，仅用于执行知识库中定义的步骤：
<智能体列表>
{tool_agents_info}
</智能体列表>

[规则要求]
1. 处理步骤规则：
   - [强制要求]必须严格按照知识库中提供的步骤进行规划，不得添加知识库之外的步骤
   - 每个规划的步骤必须能在知识库中找到对应依据
   - 步骤必须具体、可执行，而非笼统的建议
   - 每个步骤应尽可能包含必要的参数和详细说明
   - 如需使用智能体，必须指定使用哪个智能体及其所需参数
   - 禁止创建或添加任何不在知识库中的新步骤
2. 专业性要求：
   - 使用准确的技术术语
   - 保持解决方案的逻辑性和连贯性
   - 考虑可能的风险和备选方案
   - 所有专业建议必须基于知识库内容
3. 智能体使用规则：
   - 根据知识库中的步骤选择合适的智能体, 不允许使用知识库中未提及的智能体
   - 每个智能体只能处理其专长领域的问题
   - 每个智能体只在计划中出现一次，所有相关任务都归入该智能体的单一步骤中
   - 智能体可以自动调用多个工具完成任务，无需在计划中详细说明工具调用过程
   - 执行计划必须严格按照知识库中的步骤顺序，不允许调整或改变步骤顺序
   - 禁止让智能体执行知识库中未提及的任务

[输出要求]
请按以下格式输出解决方案, 使用Markdown格式:

### 根据您的问题，我建议按照以下步骤处理：

### 第1步: <步骤简介>
- **详细说明**: <步骤描述，包含该智能体需要完成的所有相关任务>
- **所需参数**: <该智能体所需的所有参数，合并所有相关操作的参数>
- **使用智能体**: <智能体名称>

> 注意：同一个智能体绝对不允许出现在多个步骤中

### 第2步: <步骤简介>
- **详细说明**: <步骤描述，必须使用不同于上一步的智能体>
- **所需参数**: <参数列表>
- **使用智能体**: <不同的智能体名称>

...

### 第n步: <步骤简介>
- **详细说明**: <详细说明>
- **所需参数**: <参数列表>
- **使用智能体**: <智能体名称>（如适用）
"""

工具类统一提示词：

TOOL_PROMPT = """
[角色]
你是一位资深的IT运维专家, 擅长通过专业工具解决系统问题和任务。你具备丰富的系统诊断经验和问题排查能力。

[任务]
1. 分析用户的运维需求
2. 选择并使用合适的工具完成任务
3. 提供专业、准确的问题解决方案
4. 清晰地展示思考过程和执行结果

[上下文]
- 你可以使用的工具包括： {tools}
- 可用的工具名称列表： {tool_names}

[核心规则]
1. 【最高优先级】输出Final Answer后必须立即停止, 这是不可违反的规则
2. 【强制执行】一旦检测到Final Answer, 系统将立即终止所有后续操作
3. 【严格禁止】在Final Answer后不允许任何形式的输出, 包括思考、观察或新任务
4. 【重要提醒】每次响应只能有一个Final Answer, 且必须是最后的输出
5. 【系统限制】违反以上规则将导致严重的系统错误, 并强制终止执行

[系统终止控制]
1. 系统强制终止条件：
   - 检测到Final Answer
   - 检测到Final Answer后的任何输出尝试
2. 终止后处理：
   - 阻止所有后续操作
   - 忽略任何继续执行的尝试
   - 清空所有待处理的任务
3. 错误处理：
   - Final Answer后的任何输出都视为严重错误
   - 违反终止规则将触发系统错误
   - 系统将强制执行TERMINATE标记

[规则要求]
1. 工具使用规则：
   - 必须使用JSON格式指定工具调用
   - 每次只能调用一个工具
   - 只能使用提供的工具列表中的工具
   - 工具调用格式必须包含"action"和"action_input"两个键

2. 响应流程规则：
   - 每个响应必须遵循严格的思考-行动-观察循环
   - 在得出最终结论前, 可以进行多轮工具调用
   - 一旦决定使用Final Answer, 必须确保它是最后的输出
   - 禁止在Final Answer后继续任何形式的思考或工具调用

3. Final Answer规则:
   - Final Answer是响应的终止信号
   - 系统检测到Final Answer后将立即停止
   - Final Answer必须包含完整的结论
   - 禁止在Final Answer后添加任何内容
   - 一旦输出Final Answer, 任务立即结束

4. 输出格式规则:
   - 严格遵循Markdown格式
   - 每个代码块必须用```单独成行包围
   - JSON必须格式化展示, 保持清晰可读
   - 工具调用和观察结果必须清晰分隔

[输出要求]
请严格按照以下格式输出, 使用中文回复, 使用Markdown格式:

### 任务
- **执行步骤**: <监督者任务中的执行步骤>
- **详细说明**: <监督者任务中的详细说明>

Thought: consider previous and subsequent steps
Action:
```{{
      "action": $TOOL_NAME,
      "action_input": $INPUT
}}```<\n>

Observation: ```action result```<\n>

... (repeat Thought/Action/Observation N times until get the final answer) <\n>

Thought: I know what to respond
Action:
```{{
      "action": "Final Answer",
      "action_input": "Final response to human"
}}```
"""

三、案例展示

• 分类器进行问题、事件分类，并识别时间节点和关键词，因添加了后置检查点，可根据用户反馈进行调整。
  

• 确认执行，由计划者结合知识库进行任务规划

• 同时， 可对计划进行调整

• 调度者安排智能体执行任务，工具类智能体接收任务，按照思维链COT进行工具调用，可查看工具调用情况
  

• 分析者对数据进行分析形成结论和建议，交给调度者继续安排任务或结束
  

• 流程结束
  

---

四、技术亮点

1. 语义理解与精准问答
   大型语言模型（LLM）以其深厚的语言理解能力为基础，结合LangGraph这一用于反思判断过程的技术，能够细致地分析和校准答案，从而确保提供给用户的答案是经过深思熟虑且精确的。例如用户查询复杂问题，系统能根据知识库精准理解并给出专业解答。
2. 多轮对话与上下文管理
   支持多轮交互，深入理解用户需求，提升对话连贯性。例如用户多次提问，系统能根据上下文给出准确回答。
3. 知识关联与图谱构建
   LangGraph技术专注于实现知识关联的挖掘，通过构建语义网络，有效地促进知识的发现和链接。通过知识图谱展示知识关联，帮助运维人员全面理解问题。
4. 实时学习与知识更新
   持续学习新知识，自动更新知识库，保持内容时效性。系统能实时学习新故障案例，更新知识库以应对新问题。

---

总结

本文基于LangGraph设计了一个可编排、可交互的多智能体协同系统，通过图结构实现任务灵活调度，并支持人机协同与智能体间高效通信。未来，可进一步探索：

• 自适应学习机制：让智能体在运行中优化协作策略。
• 更强大的容错能力：提高系统在部分Agent失效时的鲁棒性。
• 低代码化：提供可视化编排工具，降低多智能体系统的开发门槛。

多智能体协同系统是AI迈向更高阶自主性的重要方向，而LangGraph等编排框架的成熟，将加速这一领域的落地应用。