译者 | 陈峻
审校 | 重楼
本文将演示如何使用Kumologica和OpenAI协助开发出AI代理API。此类API可以使用用户提交的信息，有效地对企业内生成的用户支持请求案例进行分类，而无需客户支持代理（即：Helpdesk之类的接单人员）的干预。
从实用性角度考虑，这样的API管理方案可以自动对来自各种渠道的案例，进行分类和优先级的判定，识别出那些高优先级的案例，对其应用标签，并将它们分配给适当的成员组，而无需那些“代理”去手动执行此类任务。
目前，市场上典型的案例管理产品包括：ServiceNow、JIRA和Salesforce等。虽然其中的一些产品已内置了案例分类功能，但其实它们往往是基于预先设定好的分类，而不够智能。它们与第三方系统的集成能力也比较受限。
用例背景
在本场景中，ABC企业通过企业门户处理各种IT类和非IT类问题。用户提供各种关键性细节，如：问题的、描述、涉及的部门(包括：基础设施、网络、CRM等)，以及问题应该提交到哪里。一旦用户填写完毕这些细节，案例就会被提交，并进入一个队列，供支持代理人员审查。接着，代理人员从队列中检索出案例，查看其信息，并在案例管理系统中手动创建该案例。下图1展示了ABC企业现有的案例创建流程。
图1当前案例创建的过程(截图归Pranav K所有)
架构设计
针对上述过程，架构团队发现，案例处理中的绝大部分延迟是由人工流程造成的。在人工流程中，支持代理人员需要经历：读取、理解并将案例分类到案例管理平台中预设好的正确部门的过程。对此，他们提出了一种新的设计，以解决延迟，并提高案例系统的整体效率。
根据新的设计，用户在企业门户网站上提交的案例，以及案例管理平台的处理将不再有任何的人工干预。企业门户将通过智能化的案例分类AI代理服务，与案例管理平台直接集成。该代理将自动解读用户提供的详细信息，将案例分类到适当的部门，并在案例管理系统中分配正确的标签和项目。
图2新的案例创建流程(截图归Pranav K所有)
技术设计
在新的设计中，他们将开发基于API的AI代理服务，以便将企业的门户与案例管理平台集成到一起。在流程上，此服务将接受来自企业门户的问题，提取描述细节，并将其传递给AI提供者，以进行分类。然后，AI将返回必要的数据，以便在案例管理平台中创建相应的案例。在此，Kumologica将作为集成框架，以低码的方式构建AI代理，并利用OpenAI节点与OpenAI连接，以完成智能分类。
图3案例创建的详细设计(截图归Pranav K所有)
实现
先决条件
1. 请通过链接，下载KumologicaDesigner，并使用如下命令进行安装。
npm i @kumologica/sdk2. 在Kumologica的项目包中，请使用如下命令安装OpenAI节点。
npm i @kumologica/kumologica-contrib-openai3. 请通过链接登录OpenAI帐号，以访问OpenAI平台上的token。
步骤
现在我们将在Kumologica中开始实施“智能案例分类器（Smartcase Classifier）”服务。如果您是首次接触Kumologica，那么请参考下面的教程以开始学习。
1. 打开Kumologica Designer，将EventListner节点从面板拖放到界面上，并为节点提供以下配置。
Display Name : [POST] /case/create
Provider : AWS
EventSource : Amazon API gateway
Verb : POST
URL : /case/create注意：本文假设ABC企业已经拥有了AWS云基础设施。
2. 拖曳Logger并将其连接到步骤1中添加的EventListener节点上。再为Logger提供以下配置。
Display Name : Log Entry
Level : INFO
Message : 'Request recevied : ' & msg.payload
Log format : String3. 向界面添加两个set属性节点，并提供以下配置。这是为了提取请求数据，并设置对案例进行分类的各个规则。
Set-Property 1
Display Name : Set Case Data
Operation : Set
Target : msg.description
Source : msg.payload.description
Operation : Set
Target : msg.title
Source : msg.payload.title
Set-Property 2
Display Name : Set Case Data
Operation : Set
Target : msg.rule
Source : "if the description contains anything related to cloud, AWS, Azure, Sharepoint then provide the following JSON. label depends on if its AWS , Azure, Sharepoint etc.
Description sttribute in JSON will be the original description from user.
{"Department" : "Infra-support", "Project" : "INF", "Label" : "AWS", "Description" : "" }
if the description contains anything related to network then provide the following JSON.
Description sttribute in JSON will be the original description from user.
{"Department" : "Network-support", "Project" : "NET", "Label" : "Networking", "Description" : "" }"4. 现在从托盘中添加OpenAI节点，并提供以下配置。然后将节点连接到步骤3中的set属性节点。
Display Name : OpenAI
Operation : Single Q&A
Model : gpt-4o-mini
API Key : <>
System : msg.rule
User : msg.description 5. 最后，我们将使用EventListener节点中的响应来结束整个流程。
Display Name : Success
Response : HTTP Response
Status Code : 200
Payload : msg.payload至此，最终的流程如下图所示：
图4Kumologica流程的SmartCaseClassifier服务(截图归Pranav K所有)
试一试
您可以通过在本地使用如下端点，来调用上述流程服务。
Endpoint : http://localhost:1880/case/create
Method : POST
Content-Type : application/json
Body : {
"title" : "Issue in with account access",
"description" : "Request for providing the access the AWS dynamoDB in non prod account"
}完成之后，您将得到如下的响应。该响应显示了AI基于用户的描述，对部门、项目、标签等进行了分类。
JSON
{"Department" : "Infra-support", "Project" : "INF", "Label" : "AWS", "Description" : "Request for providing the access the AWS dynamoDB in non prod account"}小结
综上所述，通过集成Kumologica和OpenAI的案例分类服务，案例管理系统得以大幅简化与自动化。其整体流程的延迟得以减少，而准确性得以提高。当然，企业也应仔细评估其现有的基础设施和潜在的集成挑战。此外，我们也需要花一定的精力去监控AI分类的准确性，并满足监督的要求。总体而言，与任何其他AI的应用相似，我们需要对其持续训练和优化，以确保系统能够适应不断发展的业务需求和案例的动态变化。
译者介绍
陈峻（Julian Chen），51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验。
原文Low-Code AI Agent for Classifying User Support Tickets With OpenAI and Kumologica，作者： Pranav K
