AIAgent开发框架-LangChain

前言

回顾人类与机器的协同模式已经经历了如下几大阶段：

搜索引擎阶段： 机器负责信息检索，人进行逻辑推理、任务执行。

LLM阶段：机器负责内容推理和任务执行，人输入指令。

Agent阶段：机器负责推理决策 + 自主执行，人输入目标定义、需求明确、结果校验。

如运维领域已经出现了SQL/代码审计、AIOPS故障定位根因分析、OAM/YAML/配置自动生成等各类AIAgent。

我觉得AI时代人机协同的范式应该就是人重思考，AI执行。

AI Agent

AI Agent也称人工智能体/智能代理内置

  • 大语言模型(LLM)
  • 记忆（Memory）
  • 解析器/控制逻辑（Agent Core）
  • 工具集(Tools)

AI Agent本质是把原本需要人类与LLM进行的多轮推理、决策、实践的过程，通过程序自动化。赋予LLM在完成决策后，调用工具和执行任务的能力。

架构概览

image

AIAgent工作流程

1个企业级AIAgent应用应该具备以下流程

用户提问
   ↓
1. 意图识别 & 分类
   ↓
2. 历史对话压缩/摘要
   ↓
3. 少样本示例检索（Few-shot）
   ↓
4. RAG 知识库粗检索（向量库）
   ↓
5. Rerank 重排序（精排）
   ↓
----------------------------------
【第一次 LLM 调用：工具决策】
----------------------------------
   ↓
6. 工具参数校验 + 权限校验
   ↓
7. 执行工具调用（K8s/API/DB/CLI）
   ↓
8. 工具结果清洗、格式化
   ↓
----------------------------------
【第二次 LLM 调用：最终回答生成】
----------------------------------
   ↓
返回答案

1. 用户提问 → 意图识别 & 分类

  • 目的：理解用户需求，判断属于哪类操作（查询/修改/告警/数据分析等）。

  • 实现方式：

    • 训练意图分类模型（BERT/LLM zero-shot 或 fine-tune）。

    • 输出分类标签 + 置信度。

2. 历史对话压缩 / 摘要

  • 目的：减少上下文长度，保留关键信息，让 LLM 更高效。

  • 实现方式：

    • 摘要模型压缩历史消息。

    • 可选：按时间窗口/关键实体抽取。

3. 少样本示例检索（Few-shot）

  • 目的：给 LLM 提供类似场景或模板，让生成更准确。

  • 实现方式：

    • 构建少量示例库。

    • 使用相似度匹配或 embedding 检索最相关示例。

4. RAG 知识库粗检索（向量库）

  • 目的：从知识库中找到可能有用的文档/片段。

  • 实现方式：

    • 文档向量化（OpenAI Embeddings / FAISS / Milvus 等）。

    • 通过用户 query 向量与库向量匹配，返回 Top-K 文档。

5. Rerank 重排序（精排）

  • 目的：提高知识片段的相关性，减少 LLM “胡编”的概率。

  • 实现方式：

    • 使用专门的reranker 模型（如cross-encoder交叉编码器模型）。

    • 结合 query、上下文、实体信息重新评分。

【第一次 LLM 调用：工具决策】

  • 功能：决定下一步需要调用哪个工具，并生成调用参数。

  • 输入：意图标签 + 历史上下文 + 检索知识。

  • 输出：工具调用指令或决策。

6. 工具参数校验 + 权限校验

  • 目的：保证操作安全性和合法性。

  • 实现方式：

    • 参数类型、范围、格式校验。

    • 用户权限/角色校验（RBAC 或自定义权限系统）。

7. 执行工具调用（K8s/API/DB/CLI）

  • 实现方式：

    • 根据工具类型调用对应接口。

    • 可能涉及异步执行或任务队列。

8. 工具结果清洗、格式化

  • 目的：统一输出格式，便于 LLM 生成最终答案。

  • 实现方式：

    • JSON 标准化。

    • 提取关键字段、统计数据、表格化信息等。

【第二次 LLM 调用：最终回答生成】

  • 目的：将工具结果、知识片段、上下文整合成自然语言输出。

  • 实现方式：

    • LLM 生成面向用户的自然回答。

    • 可选择多轮对话生成、带解释的回答或建议操作。

Agentic Workflow设计范式

RAG：通过内部知识库 + 检索 + LLM推理，解决模型知识不足的问题，保证回答的准确性与稳定性；、

Agent：通过LLM推理 + 工具调用，实现对外部系统和能力的动态操作与执行；

Workflow：通过预定义流程编排，提供稳定、可控的任务骨架。

Agentic Workflow：因此在实际系统中，例如扣子常采用Workflow + Agent + RAG的组合模式：

由Workflow负责整体流程控制，在关键节点嵌入 Agent 提供智能决策能力，并结合 RAG 引入企业知识，实现兼具稳定性与灵活性的Agentic Workflow架构。

1.Agent（完全/多轮推理型）

特点：

  • 核心是 LLM + 工具 + while loop

  • 能多轮推理、自主决定调用哪些工具

  • 每次调用 LLM 都可能产生新的行动

  • 优势：灵活，能处理未知场景

  • 风险：死循环、成本高、不可控、可能误操作

典型场景：

  • 自动排障 Agent（理论上LLM决定每步）

  • 自动化脚本生成

  • 高度动态任务、高度自动化

2.RAG（Retrieval-Augmented Generation）+ Workflow

image

特点：

  • 支持加载企业内部文档、私有知识库，信息更贴合业务
  • 流程固定，行为可控、稳定、可预测
  • 减少无效LLM调用，Token成本更低
  • 易调试、易监控、易上线运维

典型场景：

  • 告警分析

  • 事件根因分析

  • 运维知识问

LangChain

在AI Agent中

  • LLM是大脑，负责生成决策和答案；
  • 工具是手脚，执行具体操作；
  • 记忆是经验，积累上下文和历史信息；
  • 而解析器/控制逻辑（LangChain或Dify）才是中枢神经，将大脑、手脚和经验高效协同起来。没有中枢神经，Agent无法根据LLM输出的答案自动调用对应工具执行任务。

LangChain是开发AI Agent 的一站式框架，它的核心价值在于将大模型（LLM）、记忆、工具、规划等 Agent 核心模块串联起来，使开发者无需从零实现整个系统，就能快速搭建能够自主完成复杂任务的智能体。

LangChain 的核心模块可以总结为六大类（加上 RAG 增强）：

1.LLM

LLM负责处理Prompt并生成结果，是AI Agen核心能力组件。

根据部署方式不同，模型通常分为外部 LLM（云模型） 和 企业内部 LLM（私有模型） 两种。

1. 外部LLM（云LLM）

外部LLM指由第三方厂商提供的大语言模型服务，通过互联网API调用。

常见的外部模型包括：

  • ChatGPT（由 OpenAI 提供）
  • Claude（由 Anthropic 提供）

客户端通过HTTP API调用模型服务，通常按照 Token使用量进行计费。

2. 企业内部 LLM（私有LLM）

企业内部 LLM 指企业将开源大模型部署在自身基础设施中，对内部用户提供推理服务。

常见部署模型包括：

  • DeepSeek
  • Llama
  • Qwen

企业通常借助推理框架（如 vLLM）将模型封装为API服务，对内部系统或用户开放访问。

私有化部署的特点：

  • 数据不出企业内网，安全性更高
  • 可以根据业务需求进行定制化优化
  • 初期需要投入 GPU 服务器等算力资源

在硬件方面，大多数大模型推理需要GPU加速才能达到可接受的响应速度和并发能力。

2.ModelI/O(模型I/O)

管理提示词模板、格式化输入，解析模型输出。

0c1f9c2dab1d67ee4088d365b9f0e29a

提示词分类

System Prompt（系统提示词）

System Prompt（系统提示词）用于定义模型的人设与行为规则。

Agent Skill

自研Agent客户端会在代码中封装System Prompt，或在客户端（Claude Code）预留Skills文件与System Prompt 输入入口，支持自定义 Agent Skills。

为啥需要Agent skill？

降本：解决上下文臃肿与成本爆炸

不再把海量SOP、API文档全量塞进System Prompt，而是通过Skill Router动态路由按需挂载技能。

大幅减少Token消耗，避免模型注意力丢失，同时降低推理成本。

解耦：解决多智能体协调复杂

Skill采用无状态设计，配合Blackboard黑板模式共享状态，让各技能之间完全解耦。

不需要Agent之间频繁通信，避免逻辑死循环，提升系统稳定性与可扩展性。

增效：确保Agent调用到工具准确率：

解决Agen有工具但不去用，不会用的问题：模块化Skill 把 Instructions（指令）+ Reference（知识）+ Scripts（执行逻辑） 打包成完整技能包。

让 AI 清楚知道在什么业务节点、该调用哪个工具、如何组合使用，确保工具真正落地业务。

image

 

Agent Skill企业级架构

image

RAG是动态知识路由，Agent Skill是动态技能路由，它们都是Prompt路由（Prompt Routing） 的不同落地形式。

User/Human Prompt（用户提示词）

指用户以自然语言输入的内容，即人类提出的问题或请求。

Assistant Prompt（助手提示词）

AI之前的历史回答记录，LLM客户端与LLM的对话记忆。

Context Prompt（上下文提示词）

LLM没有记忆，豆包和DeepSeek某些情况能记住我们，是因为它们属于Chart智能体，而不是LLM。

短期记忆 = 对话历史，直接放在上下文。

长期记忆 = 存在外面，通过 RAG 检索后，再放进上下文

上下文 = 模型在这一轮能看到的所有信息

如果智能体需要支持多轮交互，记忆模块是提示用户体验的重要部

Tool Prompt（工具提示词）

工具说明书，告诉LLM有哪些工具可以用，需要生成哪些参数。

LLM生成json格式参数之后，Agent Core结合反射机制调用函数/类，传参执行。

3.Chain（链）

将多个步骤/调用串联成复杂流程，实现流水线式推理。

4.Tools（工具）

当前主流 LLM（如豆包、GPT-4o、Claude、通义千问、文心一言）均不支持直接调用工具

而Agent可通过Prompt向模型描述意图与可用工具，引导LLM根据人类语言输入，输出对应的目标工具名称和执行参数，再由Agent Core根据LLM输出的工具名称和参数，间接调用执行工具，经过多轮思考+实践，最终完成任务。

正是这关键的一步，使AI完成了从聊天工具到AI Agent(自助思考+使用工具)的跨越。

LLM
 ↓
Function Calling
{
 "name":"query_pod_event",
 "arguments":{"pod":"podA"}
}
 ↓
Agent
 ↓
MCP 调用
 ↓
MCP Server
 ↓
Kubernetes API

5.MCP相关

在AI Agent规模化落地过程中，同一业务工具往往需要适配不同的Agent框架和LLM，导致工具描述与调用代码重复开发，增加了维护成本。

d1af96c0f042f5a8ed8042f36dcc14bd

5.1.MCP协议

MCP（Model Context Protocol，模型上下文协议）是一种标准化协议，用于让 AI 应用（如 Agent）统一发现和调用外部工具、数据源及服务。

通俗来说，MCP就是为AI应用与外部能力之间的交互制定一套统一标准协议，避免不同Agent框架重复开发工具接入代码。

5.2.MCP Server

实现了MCP（Model Context Protocol，模型上下文协议）的服务端，就是 MCP Server。

from fastmcp import FastMCP

# 实例化MCP服务，名字自定义
mcp = FastMCP("demo-mcp-server")

# 注册工具，装饰器自动生成MCP JSON Schema
@mcp.tool()
def add(a: int, b: int) -> int:
    """
    两个数字相加
    :param a: 数字1
    :param b: 数字2
    :return: a+b结果
    """
    return a + b

# 资源示例（MCP Resource）
@mcp.resource("greeting://{name}")
def get_greeting(name: str) -> str:
    """动态资源，返回问候语"""
    return f"Hello {name}, from FastMCP!"

if __name__ == "__main__":
    # 默认 transport="stdio"，给Claude Desktop调用
    # mcp.run()
    # 如果要http远程访问，替换为：
    mcp.run(transport="http", host="127.0.0.1", port=8000)

MCP Server 遵循MCP协议规范，向 MCP Client 暴露工具（Tools）、资源（Resources）和提示模板（Prompts）等能力，供 AI 应用或 Agent 使用。

5.3.Tools

1个MCP Server可以注册并暴露多个Tools（工具），供AI Agent通过MCP协议发现(tools/list)和调用(tools/call)。

mcp-server
    ↓
暴露tool schema
    ↓
client 获取 schema
    ↓
LLM 生成参数
    ↓
client调用mcp-server中注册的某1个工具

6.AI Agent（智能体）

理解用户意图与任务目标，并解析理解MCP Server暴露的工具描述及参数 Schema

结合任务需求自主决策并发起工具调用

根据执行结果持续推理与调整执行策略，直至完成任务目标。

7.RAG（检索增强生成）

LLM本身虽然具备强大的推理与文本/图片/视频生成能力，但其内置知识是静态的，无法实时更新，也无法直接使用企业或个人的私有、隐私数据。

通过持续微调大模型来更新知识，门槛和成本较高，需要大量高性能显卡、充足算力资源，还必须依赖专业的算法工程师进行训练与调优，对大多数企业来说难以负担。

RAG能有效解决大模型的幻觉（胡编乱造）和知识滞后问题，让模型在不需重新训练的情况下，掌握私有或最新的知识。

import os
from langchain_openai import ChatOpenAI
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_community.embeddings import HuggingFaceEmbeddings
# 加载
loader = TextLoader("./ops_sop.txt", encoding="utf-8")
documents = loader.load()
splitter = RecursiveCharacterTextSplitter(
    chunk_size=300,  # 每块300字符
    chunk_overlap=50  # 重叠50字符
)
texts = splitter.split_documents(documents)
print(f"切分后总共 {len(texts)} 个 chunk")


#LLM
chat_model=ChatOpenAI(
    name="gpt-4.1-mini",
    base_url="https://api.openai-proxy.org/v1",
    api_key="",
    temperature=0.5,
    max_tokens=20,
)

# Embedding模型
embedding = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh")
vectordb = Chroma.from_documents(
    documents=texts,
    embedding=embedding,
    persist_directory="./ops_sop"
)
#存储到向量数据库
vectordb.persist()



#RAG
def blog_agent(query: str):
    docs = vectordb.similarity_search(query, k=1)
    return "\n\n---\n\n".join([d.page_content for d in docs])


#RAG工作流
def ops_agent(key_word, top_k=1) -> str:
    #查询向量数据库:prompt---->Embeding模型---->向量---->查询向量数据库--->返回文档--->LLM
    retrieved_docs = vectordb.similarity_search(query=key_word, k=top_k)
    context = "\n\n".join([d.page_content for d in retrieved_docs])
    #提示词
    prompt = f"你是运维专家，基于以下文档回答问题：\n{context}\n\n问题：{key_word}"
    # 调用 ChatOpenAI
    response = chat_model.invoke(prompt)
    return response.content

# 提问
if __name__ == "__main__":
    while True:
        q = input("我是运维专家，请输入你的问题：")
        print(f"请参考：{ops_agent(q)}")
rag

不需要重新训练LLM，只需将最新的内部文档数据接入检索知识库，LLM即可基于检索到的真实、实时信息生成回答，既实现了知识更新，又保护了数据隐私，同时大幅降低LLM落地门槛和成本。

image

RAG流程所需模型分类

在大模型应用中，RAG（检索增强生成）是解决知识时效性、事实准确性的核心方案。

c2641636fbeace12ee150fbaa5943c15

支撑整个RAG流程的，正是5类核心模型。它们各司其职、环环相扣，从原始文本处理到最终答案生成，每一步都离不开特定模型的支撑。
阶段核心模型核心作用
文本拆分（Chunking） Chunk 模型 将长文档按语义或长度切分为小块，为后续向量化与检索做准备
向量化（Embedding） Embedding 模型 把文本小块编码为向量，实现语义层面的相似性检索
候选精排（Rerank） Rerank模型 对粗召回候选集逐对计算相关性分数，按分数重排序并过滤冗余噪声
内容精炼（可选） 提纯模型 提取关键信息或生成摘要，精简素材以提升后续处理效率
答案生成 LLM 整合高相关性素材，组织语言生成连贯、准确的最终回答

8.Graph RAG

传统 RAG（Retrieval-Augmented Generation）主要依赖用户提示词与文本块之间的语义相似度匹配来完成知识检索。

其核心流程是将文档切分为多个文本块（Chunk），通过向量化（Embedding）存入向量数据库，在用户提问时根据语义相似度检索相关文本，并将检索结果作为上下文提供给大模型生成回答。

这种方式虽然能够有效补充大模型的知识，但仍然存在明显局限：

  • 检索对象是文本块，只具备语义相似关系；
  • 无法表达实体之间的结构化关系；
  • 对复杂问题（尤其是涉及多步推理的问题）支持较弱。

Graph RAG在传统RAG流程的基础上，增加知识图谱作为知识组织方式，将原本以文本块为单位的知识，进一步抽象为 实体（Entity）与关系（Relation） 的结构化表示，从而构建语义网络。

通过这种方式，系统不仅能够检索相关文本信息，还能够理解不同知识实体之间的关联关系。

小结

从系统架构角度来看，无论是向量数据库还是知识图谱，本质上都是为大模型提供外部知识存储能力。

由于大模型本身的知识主要固化在训练参数中，这些知识既难以实时更新，也无法存储企业私有数据。因此，在实际应用中，通常需要构建独立的知识存储体系，为模型提供可持续更新的知识来源。

在AI Agent或知识问答系统中，这类外部知识存储通常被称为长期记忆（Long-term Memory）。

长期记忆用于保存系统在不同任务和时间周期中积累的知识，并在需要时通过检索机制提供给大模型使用，从而支持更复杂的任务处理和推理能力。

目前，常见的长期记忆实现方式主要包括三类：

模型参数微调

通过微调大模型参数，将知识固化在模型内部。这种方式推理效率高，但更新成本较高，且不适合频繁变化的知识。

知识图谱

将知识以 实体—关系—实体 的结构化形式进行存储，形成语义网络。知识图谱擅长表达实体之间的复杂关系，并支持多跳推理。

向量数据库

将非结构化数据（如文档、代码、日志等）转化为向量表示，通过语义相似度检索实现知识获取。向量数据库适合处理大规模文本知识，但不具备复杂关系表达能力。

在实际系统中，这三种方式通常结合使用，共同构建完整的知识记忆体系。

 

 

参考

posted on 2026-03-19 10:17  运维体系建设之路  阅读(295)  评论(0)    收藏  举报