后端SpringAI基本客服聊天服务以及审计功能实现
约 1386 字大约 5 分钟
2026-08-07
一、模块概述
在本失物招领系统中，我使用最新的Agent技术构造了一个面向用户提供咨询和查增数据库的AI助手模块。 该模块的基本架构方案是：
- 在网络接入层，采用的是HTTP协议，请求——响应模式。用户的每一个咨询请求会发送到后端的对应controller，同步的将请求发送给Agent框架进行处理，并阻塞等待响应的返回。
- 后端AI框架中维护的单例且线程安全的ChatClient，由其将请求包装上下文并发送给实际的远程LLM推理并将返回的结果包装返回给用户。 简单的概述是这样，但当Agent系统落地到实际的工程上时，就需要考虑更多：
- 应用中调用Agent接口的响应速度RT是怎样的？构建这个系统时有做什么措施去保证这个接口不会因为大量的并发请求打入，多线程同时处理导致服务瘫痪吗？（高并发、高可用）
- Agent系统该如何去监控它每一次运行的状态，如何把每一次请求的调用链路落库，审计其调用链路，token消耗，总耗时，tool调用等信息，让每一次的Agent调用都透明化。后续的排错和优化都更有迹可循（审计，后台监控）
- 对于每一个用户，如何去维护用户对话时Agent的上下文，上下文超过了LLM调用的上下文限制导致上下文被截断，这种问题有考虑吗？（上下文工程）
当然，这些也只是单纯从后端角度去考虑应用级Agent的开发工作。当进一步深入Agent开发时，我们还需要考虑例如 如何编排Agent让Agent能够处理长程任务，同时保证任务执行的高效，质量结果高等等问题。
由于本项目单机部署，业务场景的流量较小（根据微信公众平台统计的流量数据，日均访问量约为50），失物招领是读多写少的业务场景，主要目标是保证读能高效，同时系统也要有抗住一定小并发的容错率。
同时AI助手结合到失物招领领域，主要面临的业务场景应该是： 1. 我丢了某样东西，你能帮我查一下吗 - 查询、推荐能力 2. 我捡到了某样东西，我该怎么提交 - 数据库修改，添加能力 3. 系统咨询类问题 - 知识库 4. 其他无关紧要的闲聊 - 意图识别
对于3，4类的业务场景，由于业务系统的相关知识点少（不是大型企业系统，要求精准命中知识，且能处理海量数据）同时没有太强的意图识别要求，我们认为可以不加入RAG以及Graph Runtime，而是通过在系统上下文中增加知识以及强调注意意图识别来解决。但当业务系统更加丰富，对于知识回答要求准确时，则必须考虑接入RAG了。
基于上述业务场景的考虑，我们认为AI助手的能力边界应该止步于：1. 有一定的角色上下文能力，这一点通过设定Agent的系统上下文即可保证。2. 能协助用户查询丢失的物品，帮助其发布或管理自己的物品。
这些任务都属于短流程的业务场景，可能仅仅需要一到两次的工具调用和结果分析就能给出答案。而长流程的业务场景，则是：“我今天要去西藏，帮我规划一下今天的行程安排，以及注意事项”。这类场景，如果要给出一个
对于失物招领的业务场景，接入AI的主要价值就在于让用户能使用简单的口头描述，比如”我在某个地方丢了某样东西“，AI就能通过分析用户的口头描述，生成查询数据的工具调用请求，去查询数据库，同时推荐最可能的丢失物品。利用AI的智能化，让口头语言的描述也能对接上后端的数据库，其意义不止在于降低了系统整体的使用门槛，也极大优化用户的使用体验，让失物招领系统更具人性化。
仅仅是查询、推荐，还不能够完全发挥AI的智能。当我们把数据库的增删查等各项业务能力都抽象为TOOL工具交给AI调用时，整个业务系统就变成了一个智能化的个体，我们只需要和智能化的个体对话，就能代替我们发布事物招领、在繁琐的物品列表中去寻找自己丢失的东西，从而将人和业务真正解绑，人不再去亲自操作，而是有一个客服或者助手，代替你去完成，甚至给你提供情感价值，缓解你丢失物品的焦虑感。
二、怎么解决这些问题？
说完了系统的基本架构、以及后端搭建的过程中应该考虑的问题