AI专题总结

1、Q:多模型支持架构应该怎么设计A做一层模型网关、上层agent不直接依赖某个模型厂商(解偶模型厂商)而是统一调用chat、stream chat、embedding这些接口底层用adapter适配不同模型比如gpt、claude、gemini、deepseek等中间用Model Router做模型路由根据租户、场景、成本和延迟选择模型。2、Q:多租户场景下模型切换能不能热更新A可以但不能写死在代码里必须配置化。每个租户都有自己的模型配置比如模型名称、参数、超时时间、版本号。切换时切换配置不重启服务。为了互不影响要做到三点租户配置隔离、请求级配置快照、版本化切换。3、Q:agent的记忆、工具调用、知识检索怎么实现A三个核心模块Memory(记忆):保存短期上下文、保存长期用户信息Tool(工具调用):查订单、发邮件、调用业务APIRetrieval(知识检索):知识库召回-交给模型回答4、Q:一个agent在系统中有哪些状态Aagent要设计成状态机常见状态有已创建、执行中、等待模型、知识检索中、工具调用中、等待工具结果、暂停中、执行完成、执行失败、用户取消、执行超时。复杂一点还有规划中、反思中、重试中。5、Q后端agent是否支持多租户并发调用A支持但要做好隔离。第一数据隔离不同租户的会话、记忆、知识库不能串。第二配置隔离不同租户可以用不同的模型、Prompt和工具。第三资源隔离保证系统稳定性与公平。做限流、并发控制、Token配额。6、QSession和user id 如何绑定AUserID表示用户时谁SessionID表示哪一次对话。一个用户可以有多个Session但一个Session只能属于一个用户。前端每次请求带SessionID后端要校验它是否属于当前user id 和tenant id。7、Qagent工具调用的完整流程怎么走A用户输入问题后后端创建一次Agent Run然后加载上下文包括历史消息、记忆、工具列表、知识检索结果。模型判断是否需要调用工具如果需要就返回Tool Call后端再做权限校验、参数校验然后执行工具结果返回后交给模型生成回答。8、Q长期记忆和短期记忆有什么区别A短期记忆是当前会话上下文主要服务这一轮对话。长期记忆是跨会话沉淀的信息比如用户偏好、项目背景、历史总结。通常要持久化存储。9、QSSE是什么在前后端如何交互ASSE(Server-Sent Events)本质是前端和后端建立一条HTTP长连接。前端发起请求后后端持续往这个连接里推送事件。比如模型生成一段就推一个Token事件发生工具调用就推Tool Call事件完成后推Done事件。10、Q后端推流通畅采用什么数据格式A一般是两层格式外层是SSE协议格式(eventdata)内层data通常是Json。常见事件有start、token、tool call、tool result、status、error、done11、Qagent工具调用时SSE通常包含哪些字段A通常要包含run_id、session_id、agent_id、tool_call_id、tool_name、arguments、status、result、error_code、error_message、timestamp工具开始时推tool call成功或者失败后推tool result12、为什么选择 ReAct 范式来构建这个平台用 Multi-Agent 而不是单 Agent 或传统规则引擎核心优势是什么参考回答选择 ReActReasoning Acting范式本质是因为秒送客诉排查场景有两个典型特征一是输入高度非结构化用户描述可能是我的发票开不了、“骑手让我取消订单这类自然语言二是解决路径需要多步推理和外部数据验证不是单一查询能得出结论。传统规则引擎的问题在于规则维护成本随场景线性增长遇到新客诉类型需要人工补充规则难以处理语义相似的多种表述泛化能力差无法动态组合多个查询动作。单 Agent 的问题在于能力边界有限一个通用 Agent 同时处理发票、风控、日志查询等多个专业域容易什么都会一点但都不够深”而且提示词会变得越来越臃肿。Multi-Agent ReAct 的优势专业化分工发票排查 Agent、诱导取消风控 Agent 各自聚焦一个垂直场景Prompt 和工具集更聚焦动态推理链ReAct 让模型先思考当前需要哪些信息再调用工具获取数据再基于数据继续推理适合先查订单、再查日志、再判定根因这类多跳任务可扩展性新增场景只需要新增一个 Agent 和对应工具不影响已有场景。13、你们设计的两阶段意图识别路由机制具体是怎么工作的第一阶段为什么用 Qwen-Turbo 而不是直接用 Qwen3-Max参考回答两阶段路由的核心目的是在准确性和成本/延迟之间做平衡。第一阶段轻量意图分类用 Qwen-Turbo 这类轻量模型对用户的原始输入做一次快速、稳定的意图分类分类结果决定把请求路由到哪个 Agent比如发票问题路由到发票排查 Agent“骑手诱导取消路由到风控 AgentTurbo 模型成本低、延迟低适合这种边界相对清晰、不需要深度推理的分类任务。第二阶段专业 Agent 深度处理路由到具体 Agent 后由 Qwen3-Max 这类能力更强的模型负责深度推理、工具调用和结论生成在这一阶段通过 Spring AI 的 FunctionToolCallback 机制把 HSF 服务、SLS 日志查询、订单查询等十几个后端服务封装成 Agent 可调用的工具Agent 根据 ReAct 循环自主决定调用哪些工具、如何组合查询。这样分层的好处是第一层只负责分诊”第二层负责治病。如果所有意图识别和推理都用 Qwen3-Max推理成本高、响应慢而且大模型容易被复杂提示词中的多场景规则干扰。14、发票排查 Agent 中你们是如何防止模型幻觉、确保结论可信的具体做了哪些机制参考回答发票排查是对准确性要求很高的场景因为结论直接影响用户是否能成功开票或退款。我们主要从三个层面做防幻觉设计1. Prompt 工程层面在系统提示词里固化标准化排查链路让模型按固定步骤执行识别问题类型 → 查询订单/发票记录 → 校验发票有效期/金额 → 引用数据给出结论加入反幻觉约束明确要求所有结论必须引用具体数据源禁止模型基于内部知识猜测。2. 工具与本地规则结合实现发票有效期校验等本地工具把业务规则硬编码到工具里而不是让模型自己判断例如发票是否过期、金额是否匹配、是否已冲红等关键判定由工具返回结构化结果Agent 只负责基于结果做逻辑组织和输出。3. 输出结构化和可追溯要求 Agent 输出包含问题描述、查询了哪些工具、每个工具返回的关键字段、最终结论、建议操作这样既方便后续人工复核也能把完整推理链路沉淀下来用于后续效果评估和问题归因。15、动态工具注册和调用限流机制是怎么实现的为什么在大模型 Agent 系统里这个设计很重要参考回答实现机制基于 Diamond 配置中心做数据源白名单管理Agent 启动时读取配置按白名单动态装载可用的工具没有授权的工具不会被加载到 Agent 的工具库中每个工具配置独立的调用次数上限Agent 在一次排查过程中对单个工具的调用次数受到限制。这个设计的重要性在于1. 防止大模型失控调用大模型在 ReAct 循环里可能会因为理解偏差或陷入循环反复调用同一个工具。如果没有限流可能导致下游服务被打爆尤其是在高并发客诉排查场景下。2. 权限和安全性通过 Diamond 白名单控制工具可见范围可以按环境、按业务线精细化管控 Agent 能访问哪些敏感数据或服务避免越权查询。3. 热扩展能力新增排查能力时只需要开发对应工具并更新 Diamond 配置不需要重启整个 Agent 服务提升了平台的可维护性。16、在骑手诱导取消场景中AI 与传统风控算法并行验证是怎么设计的差异案例如何回流利用参考回答这个设计的核心目的是用 AI 补足传统算法对非结构化文本的理解能力同时用传统算法做校验形成数据飞轮。1. 并行验证机制AI 侧基于 Qwen3-Max 对司乘通话文本、订单上下文做深度语义理解结合 4 级风险标准和硬性排除条件做判定传统算法侧通过自定义 Interceptor 捕获 AI 分析文本同步调用原有风控算法进行判责对比最终可以拿到两个结果AI 判定结果 vs 传统算法判定结果。2. 差异案例的利用对两类差异重点分析AI 判定为诱导取消传统算法未命中往往是传统算法规则覆盖不足、但 AI 能从语义中捕捉到隐晦表达的案例传统算法判定为诱导取消AI 未命中可能是 AI 对特定话术理解不足或忽略了某些关键上下文。这些差异案例会被沉淀为高质量标注数据用于优化提示词补充 Few-shot 示例作为模型微调fine-tuning的训练样本反向完善传统风控规则让两边能力相互补强。3. 硬性排除条件的作用在 Prompt 中注入硬性排除条件比如通话时长过短、无明确诱导表述等防止 AI 过度敏感导致误判4 级风险标准则让输出更细粒度便于运营人工复核和分类处置。