开源AI Agent实战：从零搭建工单处理智能体，LangChain与本地模型部署指南

30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度1. 先别急着选平台搞清楚AI Agent到底能帮你解决什么最近聊AI Agent的人很多但很多人第一步就错了——不是先看哪个平台功能多、哪个平台火而是要先想清楚你的业务到底需要AI Agent做什么。AI Agent简单说就是一个能理解目标、自主调用工具去完成任务的智能体。它和普通聊天机器人的最大区别在于自主性和工具调用能力。比如一个客服Agent能自己查订单、算运费、生成工单一个数据分析Agent能自动拉取数据库、清洗数据、生成图表报告。所以在评估任何平台之前你得先明确几个事任务目标是否清晰是处理固定格式的工单还是应对开放性的用户咨询需要调用哪些工具是内部的API如CRM、ERP接口还是外部的服务如天气、地图、支付对稳定性和成本有多敏感是内部测试用还是直接面向客户的生产环境我见过不少团队一上来就冲着“大而全”的闭源商业平台去结果要么发现核心API对接不了要么成本远超预期要么流程过于僵化业务根本“跑不起来”。折腾一圈后才发现反而是那些开源方案因为灵活、可定制、能私有化部署成了最终落地的主力。这篇文章我就结合实测经验帮你理清思路。我们不比谁的口号响就看谁能真把业务逻辑跑通。重点会放在如何用开源方案从零搭建一个能稳定工作的AI Agent。2. 开源AI Agent的核心组件不是魔法是积木别被“智能体”这个词唬住拆开看一个能跑起来的AI Agent系统主要由以下几块“积木”构成2.1 “大脑”大语言模型这是Agent的决策中心负责理解用户指令、规划任务步骤、生成调用工具的指令。你可以用云端API如OpenAI GPT、Claude、国内大模型也可以用本地部署的开源模型如Llama、Qwen、DeepSeek等。选择的关键在于成本与隐私敏感数据或高频调用本地部署模型是更稳妥的选择。上下文长度处理长文档或多轮对话需要支持长上下文的模型。工具调用格式模型必须能输出结构化的JSON等格式以准确调用工具。2.2 “工具箱”Function/Tool Calling这是Agent的手和脚。每个工具对应一个具体的函数或API接口。例如get_weather(city: str)调用天气API。query_database(sql: str)执行数据库查询。send_email(to: str, subject: str, body: str)调用邮件服务。平台或框架需要有能力将工具的描述名称、参数、说明清晰地“告诉”大模型并能够解析大模型的输出准确地调用对应的工具函数。2.3 “记忆体”短期与长期记忆短期记忆即对话上下文Context让Agent记得当前会话中说过的话。通常由大模型本身的上下文窗口承担。长期记忆需要持久化存储的信息如用户偏好、历史会话摘要、知识库。这通常需要向量数据库如Chroma、Milvus、Qdrant来存储和检索。2.4 “调度器”工作流与状态管理对于复杂任务Agent需要拆解步骤、判断条件、循环或并行执行。这就需要一个调度器来管理任务状态State。比如一个订票Agent的流程可能是理解需求 - 查询航班 - [无结果则调整日期重查] - 确认价格 - 生成订单。2.5 “运行环境”框架与平台这就是将以上所有积木组合起来的“脚手架”。开源领域有几个主流选择LangChain/LlamaIndex生态最丰富的Python框架组件多灵活度高但需要一定的开发量。Semantic Kernel微软出品与.NET生态结合好同样功能强大。AutoGen由微软研究院推出擅长多智能体协作场景。Dify/FastGPT更偏向于开源的“低代码”应用平台提供了可视化编排工作流、知识库管理、Web用户界面的能力能更快地搭建出可交付的应用。对于大多数想让业务“跑起来”的团队我建议从Dify/FastGPT 这类应用平台或LangChain 这类成熟框架入手。它们帮你解决了最繁琐的工程整合问题。3. 实战用开源方案搭建一个客服工单处理Agent我们以一个具体的场景为例搭建一个能自动处理内部IT支持工单的AI Agent。它的任务是从邮件或聊天窗口读取用户提交的工单描述自动分类、提取关键信息如员工ID、设备号、问题类型并调用内部API在Jira或类似系统中创建工单。3.1 环境与工具准备假设我们选择LangChain作为框架Qwen作为本地大模型使用FastAPI提供Web接口。环境清单Python 3.9至少8GB内存运行7B参数的量化版模型安装核心库pip install langchain langchain-community langchain-core pip install fastapi uvicorn pip install requests # 用于调用外部API下载一个适合工具调用的开源模型例如Qwen2.5-7B-Instruct并使用Ollama或vLLM在本地启动模型服务。这里以Ollama为例# 安装Ollama (详见官网) # 拉取并运行模型 ollama pull qwen2.5:7b ollama run qwen2.5:7b # 默认会在 localhost:11434 提供API3.2 定义工具工具箱首先我们定义两个核心工具classify_ticket用于分类和提取信息create_jira_ticket用于创建工单。import json from typing import TypedDict import requests # 定义工单信息结构 class TicketInfo(TypedDict): category: str # 如 “硬件”, “软件”, “网络” employee_id: str asset_tag: str problem_summary: str priority: str # “高”, “中”, “低” # 工具1分类与信息提取这里用LLM模拟实际可接入更复杂的NLP模型 def classify_ticket(description: str) - str: 根据用户描述提取结构化工单信息。 参数: description: 用户的工单描述文本 返回: 格式化的JSON字符串包含分类、员工ID、资产标签、问题摘要、优先级。 # 这里是模拟实际应调用LLM进行处理 # 使用LangChain的LLM组件 from langchain_community.llms import Ollama llm Ollama(modelqwen2.5:7b, base_urlhttp://localhost:11434) prompt f 你是一个IT支持工单分类助手。请从以下用户描述中提取信息并以JSON格式返回。 要求 1. 分类硬件、软件、网络、账户权限、其他。 2. 提取员工ID格式如 E12345。 3. 提取设备资产标签格式如 ASSET-1001。 4. 用一句话总结问题。 5. 判断优先级高系统宕机、无法工作、中功能受限、低咨询、轻微不便。 用户描述{description} 只返回JSON不要有其他文字。 JSON格式示例 {{ category: 硬件, employee_id: E12345, asset_tag: ASSET-1001, problem_summary: 笔记本电脑无法开机, priority: 高 }} response llm.invoke(prompt) # 简单清理响应确保是合法JSON try: # 尝试从响应中提取JSON部分 start response.find({) end response.rfind(}) 1 json_str response[start:end] parsed json.loads(json_str) # 验证必要字段 if all(key in parsed for key in [category, employee_id, asset_tag, problem_summary, priority]): return json.dumps(parsed, ensure_asciiFalse) else: return json.dumps(TicketInfo(category其他, employee_id, asset_tag, problem_summarydescription, priority中)) except json.JSONDecodeError: # 如果解析失败返回一个默认结构 return json.dumps(TicketInfo(category其他, employee_id, asset_tag, problem_summarydescription, priority中)) # 工具2创建Jira工单模拟 def create_jira_ticket(ticket_info_json: str) - str: 根据提取的工单信息调用Jira API创建工单。 参数: ticket_info_json: classify_ticket函数返回的JSON字符串。 返回: 创建成功的工单Key如 “IT-1001”。 ticket_info json.loads(ticket_info_json) # 这里是模拟调用实际需要替换为真实的Jira API端点、认证信息 jira_url https://your-jira-instance.atlassian.net/rest/api/2/issue headers { Content-Type: application/json, Authorization: Bearer YOUR_TOKEN # 实际使用中请安全地管理令牌 } payload { fields: { project: {key: IT}, summary: f[{ticket_info[priority]}] {ticket_info[category]}: {ticket_info[problem_summary]}, description: f员工: {ticket_info[employee_id]}\n设备: {ticket_info[asset_tag]}\n\n原始描述: {ticket_info[problem_summary]}, issuetype: {name: 故障}, priority: {name: ticket_info[priority].upper()} } } # 实际调用此处注释掉避免误操作 # response requests.post(jira_url, jsonpayload, headersheaders) # response.raise_for_status() # return response.json()[key] # 模拟返回 print(f[模拟] 正在创建Jira工单 payload: {payload}) return IT-模拟-10013.3 构建智能体大脑与调度使用LangChain的AgentExecutor来组装。from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate from langchain_community.llms import Ollama # 1. 初始化LLM llm Ollama(modelqwen2.5:7b, base_urlhttp://localhost:11434) # 2. 将函数包装成LangChain工具 from langchain.tools import Tool tools [ Tool( nameclassify_ticket, funcclassify_ticket, description用于分析和分类IT工单描述。输入是用户的原始问题描述文本输出是包含category, employee_id, asset_tag, problem_summary, priority的JSON字符串。 ), Tool( namecreate_jira_ticket, funccreate_jira_ticket, description根据结构化的工单信息JSON格式创建Jira工单。输入是classify_ticket工具输出的JSON字符串输出是新创建的Jira工单Key。 ) ] # 3. 创建提示词模板 prompt ChatPromptTemplate.from_messages([ (system, 你是一个专业的IT支持助手。请根据用户的问题按步骤使用工具来处理。首先使用 classify_ticket 工具分析问题。然后使用 create_jira_ticket 工具创建工单。最后将工单号告知用户。), (placeholder, {chat_history}), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 4. 创建智能体和执行器 agent create_tool_calling_agent(llmllm, toolstools, promptprompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) # verboseTrue 打印详细过程 # 5. 测试运行 if __name__ __main__: test_input 我是员工E54321我的电脑ASSET-7890突然蓝屏了完全没法工作非常紧急 result agent_executor.invoke({input: test_input}) print(\n--- 最终回复 ---) print(result[output])3.4 封装为API服务使用FastAPI提供一个简单的HTTP接口。from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI(titleIT Support Agent API) class TicketRequest(BaseModel): description: str app.post(/process_ticket/) async def process_ticket(request: TicketRequest): 处理工单描述自动分类并创建Jira工单。 try: result agent_executor.invoke({input: request.description}) return {status: success, ticket_created: True, agent_response: result[output]} except Exception as e: raise HTTPException(status_code500, detailfAgent处理失败: {str(e)}) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)现在你可以通过向http://localhost:8000/process_ticket/发送POST请求JSON body:{description: 你的问题描述}来调用这个Agent了。4. 从“能跑”到“跑得好”关键配置与避坑指南上面的例子只是一个最小可行产品。要让它在业务中真正可靠运行你需要关注以下几个层面4.1 模型选择与调优不要盲目追求大参数7B、14B的模型在工具调用、分类等任务上已经表现很好且对资源要求低。先从7B模型开始测试。提示词工程是关键classify_ticket函数里的prompt是核心。你需要反复调试给出清晰的指令和输出格式示例Few-shot确保模型输出稳定、可解析的JSON。温度参数对于工具调用这类需要确定性的任务将LLM的温度temperature设置为0或接近0如0.1以减少随机性。4.2 工具调用的稳定性结构化输出确保LLM的输出能被稳定解析。除了在提示词中约束可以使用LangChain的StructuredOutputParser或框架自带的结构化输出功能。错误处理与重试在create_jira_ticket等调用真实API的工具中必须加入重试逻辑和异常捕获。网络超时、API限流、认证失败都是常见问题。from tenacity import retry, stop_after_attempt, wait_exponential retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min4, max10)) def call_jira_api(payload): # ... API调用代码工具描述要精准给Agent的工具描述description要尽可能准确、无歧义说明输入输出是什么这直接影响LLM选择工具的准确性。4.3 记忆与状态管理会话记忆上述示例是单次调用。如果是多轮对话需要将chat_history传入。LangChain提供了多种记忆后端ConversationBufferMemory等。长期记忆与知识库如果Agent需要根据公司知识库如Wiki、手册回答问题就需要集成向量数据库。流程是将知识库文档切片、向量化存储用户提问时先检索相关片段再将“片段问题”一起交给LLM生成答案。Dify/FastGPT这类平台将此过程可视化降低了实现难度。4.4 部署与监控私有化部署这是开源方案的最大优势。使用Docker将你的Agent应用、模型服务Ollama、向量数据库打包可以在任何内部服务器部署。API网关与认证生产环境一定要为FastAPI接口添加API密钥认证、速率限制等。日志与监控记录每一次Agent的调用、工具使用、LLM的请求和响应。这不仅是排查问题的依据也是优化提示词、分析成本的基础。将日志输出到ELK或类似监控平台。成本控制如果使用云端LLM API必须监控Token消耗。设置预算告警。对于内部工具本地模型是控制长期成本的最佳选择。5. 开源平台 vs. 自研框架怎么选回到标题的问题为什么“能让业务真跑起来的居然是开源的”因为可控。商业/闭源平台像早期的某些云平台提供一站式服务上手快。但当你需要深度定制、对接私有系统、处理特殊数据格式、或对响应延迟和成本有极致要求时就会遇到天花板。开源框架如LangChain给你最大的灵活性。你可以选择任何模型、任何数据库、自定义任何工具。但需要较强的开发能力需要自己组装所有部件处理工程细节。开源应用平台如Dify/FastGPT在灵活性和易用性之间取得了平衡。它们提供了可视化的Agent编排、知识库管理、用户界面同时后端代码是开放的允许你修改和扩展。对于大多数中小团队这是目前最推荐的起点。选择建议验证想法阶段直接用Dify/FastGPT快速拖拽出一个工作流连接你的模型云端或本地看看核心逻辑是否通。深度定制与集成阶段如果Dify无法满足你的复杂业务逻辑或特殊的集成需求再基于LangChain进行二次开发。你可以把Dify当作原型工具验证后的逻辑再用代码实现。追求极致性能与控本阶段全线采用开源模型和开源框架实现完全私有化部署掌控每一个环节。6. 评估AI Agent平台是否合格的检查清单最后无论你评估哪个平台开源或闭源都可以用下面这个清单来拷问它工具接入能否方便地接入我内部的核心系统API是写代码还是配置模型支持是否支持我想要的模型特别是本地部署的模型切换模型成本高吗数据隐私我的业务数据是否会离开我的控制范围能否私有化部署流程编排复杂的工作流判断、循环、分支是否容易实现是写代码还是画图记忆与知识是否支持多轮对话构建和维护知识库是否方便调试与监控是否有清晰的日志让我看到Agent的“思考过程”能否监控每次调用的耗时和成本异常处理工具调用失败时Agent能否重试或降级处理是否有统一的错误处理机制部署运维部署是否复杂是否有Docker镜像如何扩缩容、更新版本核心就一点别只看演示动手搭一个与你真实业务场景相关的、最简单的流程跑一遍。过程中遇到的每一个“卡点”比如API不好接、日志看不清、部署太麻烦都是评估这个平台是否适合你的最重要依据。很多时候正是开源方案的“不完美”所赋予的透明度和控制力让它成为了那个最终能把业务扛起来的选项。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度