1、Q:多模型支持架构应该怎么设计？
A：做一层模型网关、上层agent不直接依赖某个模型厂商(解偶模型厂商)，而是统一调用chat、stream chat、embedding这些接口，
底层用adapter适配不同模型，比如gpt、claude、gemini、deepseek等，中间用Model Router做模型路由，根据租户、场景、成本和延迟选择模型。
2、Q:多租户场景下模型切换能不能热更新？
A：可以，但不能写死在代码里，必须配置化。
每个租户都有自己的模型配置，比如模型名称、参数、超时时间、版本号。切换时切换配置不重启服务。
为了互不影响要做到三点：租户配置隔离、请求级配置快照、版本化切换。
3、Q:agent的记忆、工具调用、知识检索怎么实现？
A：三个核心模块：
Memory(记忆):保存短期上下文、保存长期用户信息
Tool(工具调用):查订单、发邮件、调用业务API
Retrieval(知识检索):知识库召回->交给模型回答
4、Q:一个agent在系统中有哪些状态？
A：agent要设计成状态机，常见状态有：已创建、执行中、等待模型、知识检索中、工具调用中、等待工具结果、暂停中、执行完成、执行失败、用户取消、执行超时。
复杂一点还有规划中、反思中、重试中。
5、Q：后端agent是否支持多租户并发调用？
A：支持，但要做好隔离。
第一：数据隔离，不同租户的会话、记忆、知识库不能串。
第二：配置隔离，不同租户可以用不同的模型、Prompt和工具。
第三：资源隔离，保证系统稳定性与公平。做限流、并发控制、Token配额。
6、Q：Session和user id 如何绑定？
A：UserID表示用户时谁，SessionID表示哪一次对话。一个用户可以有多个Session，但一个Session只能属于一个用户。
前端每次请求带SessionID，后端要校验它是否属于当前user id 和tenant id。
7、Q：agent工具调用的完整流程怎么走？
A：用户输入问题后，后端创建一次Agent Run，然后加载上下文，包括历史消息、记忆、工具列表、知识检索结果。
模型判断是否需要调用工具，如果需要就返回Tool Call，后端再做权限校验、参数校验，然后执行工具结果返回后，交给模型生成回答。
8、Q：长期记忆和短期记忆有什么区别？
A：短期记忆是当前会话上下文，主要服务这一轮对话。
长期记忆是跨会话沉淀的信息，比如用户偏好、项目背景、历史总结。通常要持久化存储。
9、Q：SSE是什么？在前后端如何交互？
A：SSE(Server-Sent Events)本质是前端和后端建立一条HTTP长连接。前端发起请求后，后端持续往这个连接里推送事件。
比如，模型生成一段，就推一个Token事件；发生工具调用就推Tool Call事件；完成后推Done事件。
10、Q：后端推流通畅采用什么数据格式？
A：一般是两层格式，外层是SSE协议格式(event+data)，内层data通常是Json。
常见事件有：start、token、tool call、tool result、status、error、done
11、Q：agent工具调用时SSE通常包含哪些字段？
A：通常要包含：run_id、session_id、agent_id、tool_call_id、tool_name、arguments、status、result、error_code、error_message、timestamp
工具开始时推tool call，成功或者失败后推tool result，
12、为什么选择 ReAct 范式来构建这个平台？用 Multi-Agent 而不是单 Agent 或传统规则引擎，核心优势是什么？
参考回答：选择 ReAct（Reasoning + Acting）范式，本质是因为秒送客诉排查场景有两个典型特征：一是输入高度非结构化，用户描述可能是"我的发票开不了"、“骑手让我取消订单"这类自然语言；二是解决路径需要多步推理和外部数据验证，不是单一查询能得出结论。传统规则引擎的问题在于：
规则维护成本随场景线性增长，遇到新客诉类型需要人工补充规则；
难以处理语义相似的多种表述，泛化能力差；
无法动态组合多个查询动作。
单 Agent 的问题在于能力边界有限：一个通用 Agent 同时处理发票、风控、日志查询等多个专业域，容易"什么都会一点，但都不够深”，而且提示词会变得越来越臃肿。Multi-Agent + ReAct 的优势：
专业化分工：发票排查 Agent、诱导取消风控 Agent 各自聚焦一个垂直场景，Prompt 和工具集更聚焦；
动态推理链：ReAct 让模型先思考"当前需要哪些信息"，再调用工具获取数据，再基于数据继续推理，适合"先查订单、再查日志、再判定根因"这类多跳任务；
可扩展性：新增场景只需要新增一个 Agent 和对应工具，不影响已有场景。
13、你们设计的"两阶段意图识别路由机制"具体是怎么工作的？第一阶段为什么用 Qwen-Turbo 而不是直接用 Qwen3-Max？
参考回答：两阶段路由的核心目的是在准确性和成本/延迟之间做平衡。第一阶段：轻量意图分类
用 Qwen-Turbo 这类轻量模型，对用户的原始输入做一次快速、稳定的意图分类；
分类结果决定把请求路由到哪个 Agent，比如"发票问题"路由到发票排查 Agent，“骑手诱导取消"路由到风控 Agent；
Turbo 模型成本低、延迟低，适合这种"边界相对清晰、不需要深度推理"的分类任务。
第二阶段：专业 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 级风险标准则让输出更细粒度，便于运营人工复核和分类处置。