从Hello World到生产部署：Agent开发完整教程

从Hello World到生产部署Agent开发完整教程引言为什么现在是学习Agent开发的黄金时代痛点引入从“脚本化工具人”到“自主智能助手”的瓶颈各位读者朋友们我是老周一个在互联网摸爬滚打了12年、从传统后端开发一路转投AI落地的技术博主。最近一年多我收到的最多私信不是关于Python语法、不是关于微服务架构而是清一色的“老周老周我写了个调用ChatGPT的聊天机器人脚本只会死记硬背指令连‘帮我查下我上个月GitHub提交量前三的仓库然后用Markdown写个周报大纲再把大纲的第3部分关于API网关优化的内容补成500字初稿最后用微信文件传输助手发给我’这种连贯需求都做不了怎么破”“看了网上一堆‘零代码Agent’教程搭出来的东西要么只能处理预定义的两三步要么连接第三方服务就得掏高额订阅费我想自己写一个可定制、可扩展、最后能真刀真枪用到公司内部的Agent该从哪开始”“最近老板给了个KPI把我们部门每周花10人天处理的‘客户售前售后工单分类→知识库检索→自动化工具调用→人工审核辅助→回复话术生成→多渠道同步邮件、飞书、官网后台’这套流程用Agent降本50%以上完全不知道怎么拆解需求、怎么选技术栈、怎么踩坑避坑……”如果你也有过以上类似的感受——觉得自己现在写的AI工具只是个“高级API调用器”没有自主思考、没有多工具协作、没有状态管理、更没有容错能力——那恭喜你你已经找到了从“入门脚本仔”进阶到“Agent架构师”的正确入口。解决方案概述一文带你走完Agent开发的全生命周期今天这篇文章我不会像网上很多教程那样一上来就给你扔LangChain的代码片段让你照着敲一个简单的搜索Agent或者计算器Agent就完事了也不会像一些“高大上”的论文解读那样只讲ReAct、Reflexion、Plan-and-Execute这些晦涩的理论不告诉你怎么落地。我会以一个真实可落地的企业级客户服务工单全流程处理Agent为核心案例带你走完Agent开发的完整生命周期需求拆解与技术选型先从业务视角拆解真实痛点再对比现在主流的Agent框架LangChain、AutoGen、CrewAI、LangGraph等选出最适合我们需求的技术栈基础概念与环境搭建帮你把Agent相关的所有核心概念大模型LLM、工具Tool、状态State、规划器Planner、执行器Executor、记忆Memory、评估器Evaluator全部搞懂然后手把手搭建一个“零污染、开箱即用”的开发环境Hello World级Agent构建用最基础的代码实现一个能“打招呼、查天气、做简单数学题”的单工具Agent帮你理解Agent的基本工作原理中间层Agent迭代多工具协作与短期记忆在Hello World的基础上加入多工具自动选择、短期对话记忆实现连贯的多轮对话核心业务Agent开发状态管理、长期记忆、规划与反思把中间层的能力迁移到我们的客户服务工单场景加入LangGraph做复杂的状态流转加入向量数据库ChromaDB/Weaviate做长期知识库记忆加入ReAct/Reflexion框架做自主规划与错误修正生产部署准备安全性、可观测性、性能优化解决把Agent从本地推到生产环境时必须要面对的三个核心问题——用户数据安全与合规LLM调用数据脱敏、API密钥管理、权限控制、可观测性日志、监控、追踪、性能优化Prompt优化、工具调用缓存、LLM调用并发控制生产环境部署Docker容器化、Kubernetes部署、API封装把我们的业务Agent打包成Docker镜像推送到私有镜像仓库然后用Kubernetes做集群化部署最后封装成RESTful API或者飞书/企业微信的机器人接口方便业务部门直接对接Agent评估与持续迭代建立一套完整的Agent评估体系业务指标、技术指标、用户体验指标然后通过持续的反馈收集与Prompt/工具/框架的调整不断优化Agent的性能行业发展与未来趋势回顾Agent技术的发展历史对比现在主流的Agent技术方案展望未来Agent的发展方向比如多模态Agent、分布式Agent、通用人工智能AGI的雏形。最终效果展示先给你打个鸡血在正式开始之前我先给你看一下我们这个客户服务工单全流程处理Agent的最终演示截图与视频链接视频链接放在了文章的“总结与扩展”部分的“相关资源”里用户输入工单用户通过飞书机器人输入“我是ABC科技的李小明我上周购买的你们公司的企业级API网关标准版订单号123456789今天早上突然挂了所有请求都返回500 Internal Server Error麻烦帮我处理一下”工单信息提取与验证Agent自动从用户输入中提取出客户姓名、公司名称、产品型号、订单号、问题类型、问题描述等信息然后调用公司内部的CRM系统验证客户身份、调用订单管理系统验证订单状态问题分类与优先级判定Agent结合知识库中的历史工单分类规则与订单状态已付款、在服务期内把问题分类为“API网关故障-生产环境紧急”优先级判定为“P0最高优先级”知识库检索与初步解决方案生成Agent从公司内部的API网关知识库存储在Weaviate向量数据库中中检索出“API网关返回500 Internal Server Error的常见原因与排查步骤”然后生成一个初步的排查方案大纲自动化工具调用与故障定位Agent根据初步排查方案大纲依次调用公司内部的云监控系统查看API网关实例的CPU、内存、磁盘使用率、请求量、错误率等指标、日志系统检索最近30分钟API网关的错误日志、API网关管理系统查看API网关的配置文件、证书状态、后端服务连接状态最终定位到故障原因是“后端服务连接超时阈值设置过低原来设置为1秒现在部分核心后端服务的响应时间已经超过了1.5秒”初步解决方案执行与验证Agent调用API网关管理系统的自动化配置修改接口把后端服务连接超时阈值从1秒调整为3秒然后调用云监控系统的接口等待5分钟确认错误率已经降到0以下API网关已经恢复正常最终回复话术生成与多渠道同步Agent结合故障定位结果、初步解决方案执行结果、知识库中的回复话术模板生成一个符合客户身份与问题类型的友好、专业的回复话术然后同步到飞书机器人、邮件、官网后台三个渠道工单归档与知识库更新Agent把本次工单的所有信息用户输入、身份验证结果、问题分类结果、知识库检索结果、自动化工具调用结果、故障定位结果、解决方案执行结果、回复话术归档到公司内部的工单管理系统然后生成一个“API网关生产环境紧急故障处理案例”更新到Weaviate向量数据库中方便以后遇到类似问题时快速检索。整个流程下来Agent只用了不到10分钟的时间而如果是人工处理的话至少需要10人天以上的工作量包括工单分类、身份验证、故障定位、解决方案执行、回复话术生成、多渠道同步等直接降本99%以上第一章需求拆解与技术选型——不要为了用Agent而用Agent核心概念在正式开始需求拆解与技术选型之前我们需要先搞懂几个最最基础的核心概念——这些概念虽然简单但却是理解整个Agent开发体系的基石很多初学者就是因为没搞懂这些概念导致后面踩了无数的坑。1.1.1 什么是Agent关于Agent的定义现在学术界和工业界还没有一个完全统一的标准但我个人比较认同OpenAI在GPT-4 Technical Report中给出的定义以及LangChain创始人Harrison Chase给出的简化版定义OpenAI的定义Agent是一个能够感知环境Perceive Environment、做出决策Make Decisions、执行动作Execute Actions、并根据环境反馈Environment Feedback不断优化决策与动作的自主智能系统。Harrison Chase的简化版定义Agent LLM 工具Tools 记忆Memory 规划Planning 反思Reflection。为了让大家更直观地理解这两个定义我们可以用一个人类的类比来解释LLM相当于人类的大脑负责思考、推理、决策、语言生成工具Tools相当于人类的手和脚负责执行具体的动作比如打开电脑、搜索资料、计算数学题、打电话等记忆Memory相当于人类的大脑海马体负责存储短期记忆比如刚才和用户说了什么和长期记忆比如之前学到的知识、处理过的类似案例规划Planning相当于人类的大脑前额叶皮层负责制定解决问题的计划比如“帮我买个菜”的计划可以拆解为“列购物清单→查看钱包余额→选择超市→前往超市→选购商品→结账→回家”反思Reflection相当于人类的自我反省能力负责根据环境反馈不断优化自己的计划和动作比如“刚才列的购物清单里忘了买酱油下次要注意”、“刚才选择的超市离我家太远了下次选择更近的那家”感知环境Perceive Environment相当于人类的眼睛、耳朵、鼻子等感官负责收集环境中的信息比如用户的输入、工具执行的结果、外部系统的状态等执行动作Execute Actions相当于人类的手和脚和上面的“工具Tools”是同一个意思环境反馈Environment Feedback相当于人类的行动结果比如“我刚才搜索了一下‘今天的天气’结果显示今天北京晴天温度25℃”。从上面的类比可以看出Agent本质上就是一个“模拟人类行为”的自主智能系统——它不是一个简单的“高级API调用器”而是一个能够“像人类一样思考、像人类一样行动、像人类一样学习”的系统。1.1.2 什么是LLMLLMLarge Language Model大语言模型是一种基于Transformer架构的预训练语言模型它通过在海量的文本数据上进行预训练学习到了语言的语法、语义、逻辑推理能力以及各种领域的知识。关于LLM的详细原理比如Transformer架构、自注意力机制、预训练任务、微调方法等我会在后面的“第四章核心原理解析”部分详细讲解这里大家只需要记住LLM的几个核心特点即可语言理解与生成能力强LLM能够理解用户的自然语言输入并且能够生成流畅、自然、符合语法和语义的自然语言输出逻辑推理能力强LLM能够进行简单的数学推理、逻辑推理、因果推理等知识覆盖面广LLM在预训练阶段学习到了海量的文本数据包括各种领域的知识比如历史、地理、科学、技术、医学、法律等上下文学习能力强LLM能够通过Few-Shot Learning少样本学习、One-Shot Learning单样本学习、**Zero-Shot Learning零样本学习**的方式在不需要重新预训练或微调的情况下学习到新的任务幻觉问题LLM有时候会生成一些看似合理但实际上是错误的内容这种现象被称为“幻觉Hallucination”——这是LLM目前最大的一个缺点也是我们在开发Agent时需要重点解决的问题之一。现在主流的LLM主要分为两类闭源LLM和开源LLM闭源LLM由大公司开发只提供API接口不提供模型权重比如OpenAI的GPT-4o/GPT-4 Turbo/GPT-3.5 Turbo、Google的Gemini 1.5 Pro/Gemini 1.5 Flash、Anthropic的Claude 3 Opus/Claude 3 Sonnet/Claude 3 Haiku、百度的文心一言、阿里的通义千问、腾讯的混元等开源LLM由社区或公司开发提供模型权重可以在本地或私有服务器上部署比如Meta的Llama 3/Llama 2、Mistral AI的Mistral 7B/Mixtral 8x7B/Mixtral 8x22B、Qwen的通义千问开源系列、Zephyr的Zephyr 7B等。1.1.3 什么是ToolsTools工具是Agent用来执行具体动作的接口——这些动作可以是LLM本身做不到的比如查询实时天气、查询股票行情、调用公司内部的CRM系统、发送邮件、控制智能家居设备等也可以是LLM本身能做到但做得不够好的比如复杂的数学计算、精确的信息检索、代码执行等。一个典型的Tool通常包含以下几个核心要素Tool名称Name一个简洁、明了、唯一的名称用来让LLM识别这个ToolTool描述Description一个详细、清晰、准确的描述用来告诉LLM这个Tool的功能、使用场景、输入输出格式等——这是LLM能否正确选择和使用Tool的关键Tool输入参数Input Parameters一个结构化的输入参数定义通常用JSON Schema或Pydantic模型来定义用来告诉LLM这个Tool需要哪些输入参数每个参数的类型、格式、是否必填等Tool执行逻辑Execution Logic一段具体的代码用来实现这个Tool的功能——这段代码可以是调用第三方API、可以是查询数据库、可以是执行本地脚本、可以是调用公司内部的系统等Tool输出结果Output Results一个结构化的输出结果定义通常用JSON格式来定义用来告诉LLM这个Tool执行后的结果是什么——同样这是LLM能否正确理解Tool执行结果的关键为了让大家更直观地理解Tool的核心要素我们可以看一个简单的查询实时天气的Tool的例子frompydanticimportBaseModel,Fieldimportrequests# 1. 定义Tool输入参数的Pydantic模型classWeatherToolInput(BaseModel):city:strField(...,description要查询天气的城市名称必须是中文城市名比如‘北京’、‘上海’、‘广州’)api_key:strField(...,description查询天气的API密钥这里我们使用和风天气的免费API密钥)# 2. 定义Tool执行逻辑defweather_tool(city:str,api_key:str)-str: 查询指定城市的实时天气信息 # 调用和风天气的免费实时天气APIurlfhttps://devapi.qweather.com/v7/weather/now?location{city}key{api_key}responserequests.get(url)response.raise_for_status()# 如果API调用失败抛出异常dataresponse.json()# 解析API返回的结果生成一个简洁、清晰的自然语言描述ifdata[code]200:weatherdata[now][text]temperaturedata[now][temp]humiditydata[now][humidity]wind_dirdata[now][windDir]wind_scaledata[now][windScale]returnf{city}现在的天气是{weather}温度{temperature}℃湿度{humidity}%风向{wind_dir}风力等级{wind_scale}级else:returnf查询{city}的天气失败错误代码{data[code]}错误信息{data.get(message,未知错误)}# 3. 定义Tool的完整信息名称、描述、输入参数模型、执行逻辑weather_tool_info{name:weather_tool,description:查询指定中文城市的实时天气信息包括天气状况、温度、湿度、风向、风力等级等,input_model:WeatherToolInput,func:weather_tool}从上面的例子可以看出一个Tool的实现其实并不复杂——复杂的是Tool描述的编写必须要详细、清晰、准确让LLM一眼就能看明白这个Tool的功能、使用场景、输入输出格式以及Tool执行逻辑的健壮性必须要处理各种异常情况比如API调用失败、参数格式错误、网络连接超时等。1.1.4 什么是MemoryMemory记忆是Agent用来存储历史信息的模块——这些历史信息可以是用户的输入、Agent的输出、工具的执行结果、Agent的规划与反思内容等。没有记忆的Agent就像一个“金鱼脑”——每次对话都是新的开始完全不记得之前和用户说了什么也不记得之前处理过什么任务这样的Agent是不可能完成连贯的多轮对话任务也不可能完成复杂的多步骤任务的。Memory通常可以分为以下几类短期记忆Short-Term MemorySTM也叫上下文记忆Context Memory用来存储最近的几轮对话信息——这些信息通常会直接作为Prompt的一部分输入到LLM中帮助LLM理解当前的对话上下文。短期记忆的容量通常比较小比如只存储最近的10轮对话信息因为LLM的上下文窗口长度是有限的比如GPT-3.5 Turbo的上下文窗口长度是16k tokensGPT-4 Turbo的上下文窗口长度是128k tokensClaude 3 Opus的上下文窗口长度是200k tokens长期记忆Long-Term MemoryLTM用来存储大量的、长期的历史信息——这些信息通常不会直接作为Prompt的一部分输入到LLM中而是通过**向量检索Vector Retrieval的方式从长期记忆中检索出与当前任务最相关的几条信息然后再作为Prompt的一部分输入到LLM中。长期记忆的容量通常非常大可以存储几百万甚至几千万条信息因为它是存储在向量数据库Vector Database**中的实体记忆Entity Memory也叫知识库记忆Knowledge Base Memory用来存储结构化的知识信息——这些信息通常是关于某个实体比如人、公司、产品、事件等的属性和关系。实体记忆的实现方式通常有两种一种是存储在图数据库Graph Database中另一种是存储在向量数据库中程序记忆Procedural Memory也叫技能记忆Skill Memory用来存储Agent处理某个特定任务的步骤和规则——这些步骤和规则通常是通过微调Fine-Tuning、**强化学习Reinforcement LearningRL或者Prompt工程Prompt Engineering**的方式学习到的。在后面的“第五章核心业务Agent开发状态管理、长期记忆、规划与反思”部分我会详细讲解短期记忆、长期记忆、实体记忆的实现方式。1.1.5 什么是PlanningPlanning规划是Agent用来制定解决问题的计划的模块——当Agent遇到一个复杂的多步骤任务时它不会直接开始执行而是先制定一个详细的、可执行的计划然后再按照计划一步步执行。没有规划的Agent就像一个“无头苍蝇”——遇到复杂任务时它会盲目地尝试各种工具和动作最后要么任务失败要么虽然完成了任务但效率极低。现在主流的Planning方法主要有以下几种Zero-Shot Planning零样本规划LLM直接根据用户的输入制定解决问题的计划不需要任何示例Few-Shot Planning少样本规划LLM根据用户提供的几个示例制定解决问题的计划ReAct Planning推理-行动规划这是目前最流行的Planning方法之一它的核心思想是**“先推理Reasoning再行动Acting然后根据行动结果再推理再行动直到任务完成”**——ReAct Planning把推理和行动结合起来大大提高了Agent的推理能力和行动准确性Plan-and-Execute Planning计划-执行规划这是另一种非常流行的Planning方法它的核心思想是**“先由一个‘规划器Planner’制定一个详细的、多步骤的计划然后再由一个‘执行器Executor’按照计划一步步执行执行器在执行过程中如果遇到问题可以随时请求规划器调整计划”**——Plan-and-Execute Planning把规划和执行分开大大提高了Agent处理复杂任务的能力Reflexion Planning反思规划这是一种在ReAct Planning基础上改进的Planning方法它的核心思想是**“在执行完每一步行动之后Agent都会进行一次‘反思Reflection’总结这一步行动的成功或失败的原因然后根据反思结果调整下一步的计划和行动”**——Reflexion Planning大大提高了Agent的容错能力和学习能力。在后面的“第五章核心业务Agent开发状态管理、长期记忆、规划与反思”部分我会详细讲解ReAct Planning、Plan-and-Execute Planning、Reflexion Planning的实现方式。1.1.6 什么是StateState状态是Agent用来存储当前任务的执行状态的模块——这些状态可以是任务的当前进度、已经收集到的信息、已经执行过的工具和动作、当前的计划、反思的内容等。State是复杂Agent开发的核心——没有State的Agent只能处理简单的单步骤任务或者简单的多轮对话任务而无法处理复杂的、有分支的、有循环的多步骤任务比如我们的客户服务工单全流程处理Agent。现在主流的State管理方法主要有以下几种字典Dictionary管理用一个简单的Python字典来存储State——这种方法非常简单但只适合处理简单的任务因为它没有类型检查、没有状态验证、没有状态流转控制Pydantic模型管理用Pydantic模型来定义State的结构和类型——这种方法比字典管理好一些因为它有类型检查、有状态验证但还是没有状态流转控制LangGraph State管理这是目前最流行的State管理方法之一它是LangChain团队开发的一个专门用于构建复杂Agent的框架——LangGraph用**图Graph**的形式来定义Agent的状态流转每个节点Node代表一个Agent的动作比如LLM推理、工具执行、状态更新等每条边Edge代表状态流转的条件比如“如果工具执行成功就进入下一个节点如果工具执行失败就进入反思节点”——LangGraph的State管理非常强大它支持类型检查、状态验证、状态流转控制、分支、循环、并行执行等。在后面的“第五章核心业务Agent开发状态管理、长期记忆、规划与反思”部分我会详细讲解LangGraph State管理的实现方式。问题背景现在我们已经搞懂了Agent开发的几个最最基础的核心概念接下来我们要进入需求拆解的环节——在正式开始需求拆解之前我们需要先了解一下我们的客户服务工单全流程处理Agent的问题背景。我所在的公司是一家专注于企业级云原生API网关产品的公司——我们的API网关产品主要面向中大型企业客户帮助他们解决API的安全、性能、监控、管理等问题。最近一年多随着我们公司业务的快速发展我们的客户数量从原来的几百家增长到了现在的几千家相应的我们的客户售前售后工单数量也从原来的每天几十条增长到了现在的每天几千条——这给我们的客户服务团队带来了巨大的压力人力成本高我们的客户服务团队现在有50多个人每个人每天要处理几十条甚至上百条工单人力成本非常高响应时间长因为工单数量太多很多P0/P1级别的紧急工单都不能得到及时的处理导致客户满意度下降处理效率低很多工单的处理流程都是重复的比如工单分类、身份验证、知识库检索、回复话术生成等但因为没有自动化工具的帮助客户服务人员还是要手动完成这些流程知识库更新慢很多客户服务人员在处理完工单之后不会及时把处理案例更新到知识库中导致知识库的内容越来越陈旧检索效率越来越低新员工培训成本高新员工入职之后需要花几个月的时间来学习知识库中的内容、学习工单处理流程、学习各种工具的使用培训成本非常高。为了解决以上这些问题我们公司的老板给了我一个KPI在3个月之内用Agent把我们部门每周花10人天处理的‘客户售前售后工单分类→知识库检索→自动化工具调用→人工审核辅助→回复话术生成→多渠道同步邮件、飞书、官网后台’这套流程降本50%以上同时把P0/P1级别的紧急工单的平均响应时间从原来的1小时降到10分钟以内客户满意度从原来的85%提升到95%以上。问题描述在了解了问题背景之后接下来我们要把这个模糊的KPI转化为清晰的、可量化的、可执行的问题描述。经过和客户服务团队的几次深入沟通我们最终把问题描述整理成了以下几个部分1.3.1 业务范围我们的Agent只处理企业级云原生API网关产品的售前售后工单——不处理其他产品的工单也不处理非工单类的咨询比如“你们公司的地址在哪里”、“你们公司的招聘信息在哪里”等。1.3.2 输入渠道我们的Agent支持以下几种输入渠道官网后台客户通过我们公司的官网后台提交工单飞书机器人客户通过我们公司的飞书企业号提交工单邮件客户通过发送邮件到我们公司的客户服务邮箱提交工单。1.3.3 输出渠道我们的Agent支持以下几种输出渠道官网后台把处理结果同步到官网后台的工单详情页飞书机器人把处理结果同步到飞书机器人的对话窗口邮件把处理结果同步到客户的邮箱工单管理系统把处理结果归档到我们公司内部的工单管理系统向量数据库把处理案例更新到我们公司内部的API网关知识库存储在Weaviate向量数据库中。1.3.4 核心功能我们的Agent需要具备以下几个核心功能工单信息提取与验证从用户输入中自动提取出客户姓名、公司名称、产品型号、订单号、问题类型、问题描述、联系方式等信息调用公司内部的CRM系统验证客户身份是否是我们的付费客户、客户等级是什么调用公司内部的订单管理系统验证订单状态是否已付款、是否在服务期内、服务等级是什么问题分类与优先级判定结合知识库中的历史工单分类规则与订单状态、客户等级把问题分类为售前咨询、售后故障、售后咨询、售后投诉等几大类每大类下面再细分几个小类比如售后故障下面可以细分为“API网关故障-生产环境紧急、API网关故障-测试环境非紧急、API网关配置问题、API网关性能问题”等结合知识库中的历史工单优先级判定规则与问题类型、订单状态、客户等级把问题优先级判定为P0最高优先级需要立即处理、P1高优先级需要在1小时内处理、P2中优先级需要在4小时内处理、P3低优先级需要在24小时内处理知识库检索与初步解决方案生成从公司内部的API网关知识库存储在Weaviate向量数据库中包括产品文档、常见问题FAQ、历史工单处理案例等中检索出与当前问题最相关的Top 10条信息结合检索到的信息生成一个初步的排查方案大纲或初步的解决方案大纲自动化工具调用与故障定位根据初步排查方案大纲依次调用公司内部的云监控系统、日志系统、API网关管理系统等自动化工具收集相关的信息结合收集到的信息定位到故障的具体原因初步解决方案执行与验证如果故障原因是可以通过自动化工具解决的比如后端服务连接超时阈值设置过低、API网关配置错误、证书过期等Agent会调用相应的自动化工具执行初步解决方案初步解决方案执行完成之后Agent会调用相应的自动化工具验证解决方案是否有效人工审核辅助如果故障原因是无法通过自动化工具解决的比如需要手动重启API网关实例、需要手动修改后端服务的代码等或者Agent对自己的处理结果没有足够的信心置信度低于80%Agent会把所有收集到的信息、初步的排查方案大纲、初步的解决方案大纲、故障定位结果等整理成一个人工审核辅助报告发送给客户服务团队的人工审核人员人工审核人员可以在人工审核辅助报告的基础上修改或补充处理方案然后把处理方案返回给Agent最终回复话术生成与多渠道同步结合故障定位结果、解决方案执行结果、知识库中的回复话术模板、客户身份、客户等级、问题类型、问题优先级生成一个友好、专业、符合客户身份与问题类型的最终回复话术把最终回复话术同步到官网后台、飞书机器人、邮件三个渠道工单归档与知识库更新把本次工单的所有信息用户输入、身份验证结果、问题分类结果、知识库检索结果、自动化工具调用结果、故障定位结果、解决方案执行结果、回复话术、人工审核结果等归档到公司内部的工单管理系统生成一个**“API网关生产环境/测试环境紧急/非紧急故障处理案例”或“API网关售前/售后咨询处理案例”**更新到Weaviate向量数据库中。1.3.5 非功能需求除了核心功能之外我们的Agent还需要具备以下几个非功能需求安全性与合规性所有用户数据包括客户姓名、公司名称、订单号、联系方式、工单内容等都必须加密存储不能明文存储所有LLM调用数据包括用户输入、Agent的输出、工具的执行结果等都必须脱敏处理比如把客户姓名、公司名称、订单号、联系方式等敏感信息替换成占位符然后再发送给闭源LLM所有API密钥包括LLM API密钥、第三方服务API密钥、公司内部系统API密钥等都必须**存储在安全的密钥管理系统KMS**中不能明文写在代码里或配置文件里所有Agent的访问都必须进行权限控制比如只有付费客户才能使用Agent处理售后故障工单只有客户服务团队的人工审核人员才能访问人工审核辅助报告所有Agent的操作都必须记录日志并且日志必须保存至少6个月方便审计可观测性必须建立一套完整的日志系统记录Agent的所有操作包括LLM调用、工具调用、状态更新、错误处理等必须建立一套完整的监控系统监控Agent的所有性能指标包括LLM调用的延迟、LLM调用的成本、工具调用的延迟、工具调用的成功率、Agent的响应时间、Agent的处理成功率等必须建立一套完整的追踪系统追踪每个工单的完整处理流程从用户输入到最终回复性能优化P0/P1级别的紧急工单的平均响应时间必须小于10分钟P2/P3级别的非紧急工单的平均响应时间必须小于30分钟Agent的处理成功率必须大于95%LLM调用的成本必须控制在每月10万元以内可扩展性必须支持快速添加新的工具比如添加调用公司内部的财务系统的工具、添加调用公司内部的人力资源系统的工具等必须支持快速添加新的知识库比如添加公司内部的其他产品的知识库等必须支持快速添加新的输入输出渠道比如添加企业微信机器人、添加钉钉机器人等必须支持水平扩展当工单数量增加时可以通过增加Agent的实例数量来提高处理能力容错能力如果某个工具调用失败Agent必须能够自动重试最多重试3次如果重试3次之后还是失败Agent必须能够把任务交给人工审核人员处理如果LLM调用失败Agent必须能够自动切换到另一个LLM比如从GPT-4o切换到Claude 3 Opus再切换到文心一言如果所有LLM都调用失败Agent必须能够把任务交给人工审核人员处理如果向量数据库检索失败Agent必须能够跳过知识库检索步骤直接把任务交给人工审核人员处理易用性客户通过输入渠道提交工单时不需要学习任何新的指令只需要用自然语言描述自己的问题即可人工审核人员查看人工审核辅助报告时报告的内容必须清晰、简洁、有条理方便人工审核人员快速理解问题开发人员添加新的工具、新的知识库、新的输入输出渠道时必须有详细的文档和示例方便开发人员快速上手。问题解决技术选型现在我们已经把模糊的KPI转化为了清晰的、可量化的、可执行的问题描述接下来我们要进入技术选型的环节——这是Agent开发中非常重要的一个环节技术选型的好坏直接决定了Agent开发的效率、成本、以及最终的效果。在进行技术选型之前我们需要先明确我们的技术选型原则成熟稳定我们选择的技术必须是成熟稳定的有大量的企业级应用案例不能选择太新的、还在快速迭代的技术开源免费我们选择的技术必须是开源免费的或者有免费的企业级版本这样可以降低我们的成本社区活跃我们选择的技术必须是社区活跃的有大量的文档、教程、示例遇到问题时可以快速找到解决方案可扩展性强我们选择的技术必须是可扩展性强的支持快速添加新的功能与我们公司现有技术栈兼容我们选择的技术必须是与我们公司现有技术栈兼容的——我们公司现有的技术栈主要是Python、Go、Docker、Kubernetes、PostgreSQL、Redis等。根据以上的技术选型原则接下来我们要对Agent开发的各个核心组件进行技术选型1.4.1 LLM选型首先是LLM的选型——LLM是Agent的“大脑”LLM的好坏直接决定了Agent的推理能力、语言理解与生成能力、以及最终的效果。我们首先对比一下现在主流的闭源LLM和开源LLM的优缺点LLM类型优点缺点闭源LLM1. 推理能力强2. 语言理解与生成能力强3. 上下文窗口长度大4. 不需要自己部署只需要调用API5. 更新速度快1. 成本高2. 数据安全与合规性问题需要把敏感数据发送给第三方3. 可定制性差不能重新预训练或微调模型只能通过Prompt工程来调整模型的行为4. 调用延迟高取决于网络状况和第三方服务的负载开源LLM1. 成本低只需要支付服务器的费用2. 数据安全与合规性好可以在本地或私有服务器上部署不需要把敏感数据发送给第三方3. 可定制性强可以重新预训练或微调模型也可以修改模型的代码4. 调用延迟低取决于服务器的性能1. 推理能力相对较弱尤其是小模型2. 语言理解与生成能力相对较弱3. 上下文窗口长度相对较小小模型通常只有4k/8k tokens大模型虽然有32k/128k tokens但部署成本非常高4. 需要自己部署和维护需要一定的技术能力和服务器资源5. 更新速度相对较慢根据我们的问题描述和技术选型原则我们最终决定同时使用闭源LLM和开源LLM闭源LLM我们选择OpenAI的GPT-4o、Anthropic的Claude 3 Opus、百度的文心一言4.0作为我们的主LLM——这些LLM的推理能力、语言理解与生成能力都非常强上下文窗口长度也足够大GPT-4o的上下文窗口长度是128k tokensClaude 3 Opus的上下文窗口长度是200k tokens文心一言4.0的上下文窗口长度是128k tokens可以满足我们的需求开源LLM我们选择Meta的Llama 3 70B Instruct、Qwen的通义千问2.5 72B Instruct作为我们的备用LLM——这些LLM的推理能力、语言理解与生成能力也比较强上下文窗口长度也足够大Llama 3 70B Instruct的上下文窗口长度是8k tokens通义千问2.5 72B Instruct的上下文窗口长度是32k tokens当闭源LLM调用失败时可以自动切换到这些备用LLMLLM调用框架我们选择LiteLLM作为我们的LLM调用框架——LiteLLM是一个开源的、轻量级的LLM调用框架它可以统一调用现在主流的闭源LLM和开源LLM的API不需要为每个LLM编写不同的调用代码大大提高了我们的开发效率同时LiteLLM还支持LLM调用的成本控制、速率限制、自动重试、自动切换LLM等功能非常适合我们的需求。1.4.2 Agent框架选型接下来是Agent框架的选型——Agent框架是Agent开发的“脚手架”Agent框架的好坏直接决定了Agent开发的效率、以及Agent的可扩展性和可维护性。现在主流的Agent框架主要有以下几种LangChain、AutoGen、CrewAI、LangGraph、Semantic Kernel等——我们首先对比一下这些Agent框架的优缺点Agent框架开发公司/团队核心特点优点缺点适用场景LangChainHarrison Chase前Google员工最早的、最流行的Agent框架之一提供了大量的预构建组件LLM、Tools、Memory、Chains、Agents等1. 社区最活跃文档最丰富示例最多2. 提供了大量的预构建组件开发效率高3. 支持现在主流的LLM、Tools、Memory等4. 有LangSmith这个强大的调试、监控、评估工具1. 早期版本的Chains和Agents的可扩展性和可维护性比较差2. 学习曲线比较陡峭3. 对于复杂的、有分支的、有循环的多步骤任务的支持不够好不过后来推出了LangGraph解决了这个问题简单的单步骤任务、简单的多轮对话任务、快速原型开发AutoGenMicrosoft专注于多Agent协作的Agent框架每个Agent都有自己的角色和任务Agent之间可以通过对话的方式进行协作1. 多Agent协作能力强2. 支持Agent之间的对话、工具调用、代码执行等3. 有Microsoft的背书社区活跃度也比较高1. 对于单Agent的支持不够好2. 学习曲线比较陡峭3. 可观测性不够强多Agent协作的任务比如软件开发团队、客户服务团队等CrewAIJoão Moura基于LangChain开发的、专注于多Agent协作的Agent框架每个Agent都有自己的角色、目标、工具、背景故事等Agent之间可以通过任务分配的方式进行协作1. 多Agent协作能力强2. 配置简单开发效率高3. 支持现在主流的LLM、Tools、Memory等4. 有LangSmith这个强大的调试、监控、评估工具1. 对于单Agent的支持不够好2. 对于复杂的、有分支的、有循环的多步骤任务的支持不够好3. 可扩展性和可维护性相对较弱多Agent协作的任务比如内容创作团队、市场调研团队等、快速原型开发LangGraphLangChain团队基于LangChain开发的、专门用于构建复杂Agent的框架用图的形式来定义Agent的状态流转每个节点代表一个动作每条边代表状态流转的条件1. 状态管理能力强支持类型检查、状态验证、状态流转控制、分支、循环、并行执行等2. 可扩展性和可维护性强3. 支持现在主流的LLM、Tools、Memory等4. 有LangSmith这个强大的调试、监控、评估工具5. 可以和LangChain的其他组件无缝集成1. 学习曲线比较陡峭2. 文档和