一. 架构决策为什么用 Agent而不是传统流程意图的复杂性与动态性传统客服机器人基于意图识别Intent Classification 固定SOP流转,但在该项目场景中用户的表达往往是多意图混合且带有上下文依赖的,传统流程需要配置极其复杂的正则和状态机而ReActAgent可以通过“思考-行动”循环自主决定先查设备日志排查再查知识库原因最后给出建议工具调用的动态规划统不仅有静态知识库还接入了IoT设备数据,Agent可以根据及其的实时状态动态编排工具链,比如发现异常Agent会自主调用“生成依从性报告”工具而不是靠用户主动触发,这种“主动关怀”是传统状态机无法实现的容错与自我修正项目场景下用户描述往往不规范,Agent的ReAct循环允许它在工具调用失败或信息不足时进行自我反思Reflection并向用户追问而不是直接抛出“我不明白您的意思”二. 工程兜底Tool设计与异常处理机制LLM是不稳定的在项目场景下一次错误的压力参数指导可能导致机器事故,系统如何保证绝对安全Tool设计的“防御性编程”参数强校验所有暴露给LLM的Tool底层全部使用Pydantic进行严格的Schema校验,LLM传错参数如把压力值传成字符串或超出安全阈值Pydantic会直接拦截并返回结构化错误而不是让脏数据进入业务逻辑只读与写操作分离对于涉及设备参数修改的ToolAgent只有“建议权”没有“执行权”,Agent只能生成“建议将压力调至X”的报告必须经过用户或工作人员在UI上的二次确认Human-in-the-loop从物理层面杜绝AI误操作异常处理的三层兜底L1 (解析层)使用OutputFixingParser,如果LLM输出的JSON格式错误Parser会自动把错误信息喂回给LLM让它重新格式化而不是直接报错L2 (执行层)多重try-except,如果第三方IoT接口超时或返回空数据Agent会捕获异常并在Prompt中注入“设备数据暂时不可用请基于通用指南回答”的上下文避免幻觉L3 (业务层)设置最大迭代步数Max Iterations和置信度阈值,如果Agent绕了3圈还没解决问题或者检索到的知识相关性得分低于阈值强制触发降级策略——无缝转接“专属顾问”人工客服并附带Agent之前的思考过程摘要保证用户体验不中断三.RAG的特殊性如何做到 Precision5 1.0通用RAG在该领域往往会“水土不服”,你的检索精度极高具体做了哪些针对性的工程优化切分策略Chunking的领域定制操作手册和指南具有极强的结构化特征,我们没有用简单的固定字符切分而是基于Markdown标题层级和表格边界进行语义切分,对于“型号与对照表”这种关键数据将其转化为“QA对”或“JSON格式”单独存储确保检索时不会把表头和数据行切断混合检索Hybrid Search虽然用了ChromaDB做向量检索但对于“RMed Fit P10”这种精确型号或者“AH 5”这种精确数值纯向量检索容易飘,引入了SQLite FTS5 做关键词精确匹配将向量召回和关键词召回的结果进行RRF倒数排名融合这就是为什么我们的 MRR 能达到 1.0元数据过滤Metadata Filtering在检索前Agent会先提取用户的设备型号和购买时间将其作为 Metadata Filter 传给 ChromaDB,绝不把“家用机器”的指南召回给“工用机器”用户从源头上切断幻觉四. 性能与评估102ms 延迟与 RAGAS 体系102ms 的端到端延迟对于包含检索和生成的RAG系统来说非常低你是怎么做到的RAGAS 是怎么指导你优化的极致性能优化模型选择与部署没有盲目追求大参数模型而是选择了Qwen2.5这种在指令遵循和工具调用上表现优异的开源模型并通过Ollama进行本地化/私有化部署结合 vLLM 等推理加速框架大幅降低了首字延迟TTFT流式输出Streaming采用LCEL 的流式编排检索一结束生成模块立刻开始吐字用户体感延迟远低于实际端到端延迟缓存策略针对“滤网更换周期”、“常见漏水排查”等高频且答案固定的问题在检索层之上增加了 Redis 语义缓存命中缓存直接返回耗时降至 10ms 级别RAGAS 驱动的持续迭代不是上线前测一次而是把 RAGAS 集成到了 CI/CD 流水线中,每次更新知识库或更换 Prompt都会自动跑一遍评估集Faithfulness 0.863 的代价与收益为了达到这个指标在 Prompt 中加入了极其严苛的约束如“如果上下文中没有提到该问题请直接回答‘知识库未收录’严禁推测”,这虽然牺牲了一点点“Answer Relevancy”有时显得不够聪明但在严格场景下“知之为知之不知为不知”才是最高级的智能五. 模型超时重试怎么设计核心原则拒绝无脑重试必须引入“幂等性”与“退避策略”防止雪崩效应幂等性设计重试的前提是请求必须幂等,在系统中像检索操作手册、查询设备状态等无副作用操作天然支持重试但如果是涉及修改用户设备参数的写操作必须在请求头中携带全局唯一的Idempotency-Key(如 UUID),服务端根据该 Key 缓存状态,若发现相同 Key 的请求正在处理或已完成直接返回缓存结果彻底杜绝重复修改和操作风险指数退避 抖动Exponential Backoff Jitter当遇到网络超时或 502/503 等瞬时故障时重试间隔不能是固定的,应采用指数退避如 1s - 2s - 4s并加入随机抖动因子如 ±0.5s,这能有效打散并发请求的重试时间避免大量请求在同一瞬间重试导致服务端负载瞬间翻倍即“惊群效应”重试次数与熔断严格限制最大重试次数通常 3~5 次为宜,若连续失败应触发熔断机制直接返回降级结果而不是让 Agent 陷入无限重试的死循环六. Tool 调用失败了怎么回退核心原则错误必须结构化回退必须分层级Fallback Chain结构化错误分类工具返回的不能是一段自然语言而必须是结构化 JSON,系统需根据error_type精准分类瞬态故障Timeout/502触发指数退避重试参数错误Schema Error/400禁止重试将错误信息反馈给 LLM让其修正参数后重新调用权限/业务拒绝403/Empty Result禁止重试直接记录日志并返回明确的“未找到”或“无权限”提示多级降级策略Fallback Chain为关键工具配置备选方案,例如主用的高精度翻译 API 挂了自动降级到备用 API备用 API 也挂了降级到本地小模型小模型也失败最终降级为返回友好的静态提示语或转人工任务剪枝如果某个非核心子工具永久失效Agent 应具备“大局观”主动跳过该子目标优先保障核心任务的完成而不是让整个任务卡死七. 对话记忆越积越长怎么裁剪核心原则分层渐进式压缩优先无损有损兜底即时轻量化SnipCompact每轮请求前通过纯文本处理截断超长的工具日志如保留首尾和省略号、合并连续重复的助手消息、删除空消息,这一步零成本能挡住大部分上下文膨胀滑动窗口 无损归档MicroCompact仅保留最近 N 轮如最近 5-10 轮的完整对话,更早的历史消息移出上下文窗口写入本地磁盘或 Redis上下文中仅保留一个占位符如“[前文已归档需要时可调用 read_memory 工具]”,这是无损的模型需要时可按需检索有损摘要压缩AutoCompaction当 Token 占用达到阈值如 78%时触发 LLM 对早期历史进行结构化摘要,保留核心目标、已完成的步骤、关键决策和修改过的文件列表丢弃中间的探索过程和冗余日志紧急全量压缩Full Compaction当濒临溢出如 92%时执行最激进的压缩仅保留系统提示词、当前核心目标和最近一次工具结果丢弃所有中间调试细节八. Token 消耗怎么压下来核心原则从输入、输出、模型路由三个维度进行全链路“瘦身”输入端极致压缩工具结果裁剪工具返回的原始数据如几万行的日志、完整的数据库表绝不能直接塞给 LLM,必须在工具层做预处理只返回 LLM 需要的关键字段如只返回order_id和status并限制最大字符数动态 Prompt 注入不要把所有规则都写在 System Prompt 里,将规则拆分为“常驻规则”和“场景规则”只在触发特定意图时才将相关规则动态注入上下文模型路由Model Routing不要杀鸡用牛刀,对于意图识别、信息抽取、简单分类等任务使用轻量级小模型如 7B/8B只有在复杂的逻辑推理、代码生成或最终总结时才调用强模型如 72B/405B,实测可将整体成本降低 40%~60%输出端控制在 Prompt 中明确要求输出格式例如“仅输出 JSON”、“不超过 200 字”、“使用 Markdown 表格”,限制输出长度能大幅减少 Output Token 的消耗高频任务 Skill 化对于日报生成、周报整理等高频重复任务将其封装为固定的 SkillPrompt 脚本避免每次都让 LLM 重新规划步骤可节省 80% 以上的 Token九. 日志和告警怎么配核心原则结构化 Trace聚焦高价值信号避免“狼来了”全链路 Trace 记录采用 JSONL 格式记录 Agent 的每一步决策,每条日志必须包含run_id、step、typethought/action/observation、input_tokens、latency等字段,特别是thought字段是排查“目标漂移”和“幻觉性成功”的关键聚焦核心 KPI 告警不要对所有日志都告警重点监控以下指标死循环/绕圈同一任务中同一个工具被连续调用超过 3 次或单任务迭代步数超过阈值如 10 步Token 预算熔断单次任务的 Token 消耗超过预设上限如 50k Tokens立即暂停并告警防止失控导致高额账单工具失败率某工具的失败率在短时间内如 1 分钟超过 30%触发告警告警降噪配置for: 2m这样的持续时间条件过滤掉网络抖动引起的瞬时毛刺,同时支持告警分组和静默避免同一根因引发几百条告警轰炸十.线上模型效果突然下降排查和回滚流程是怎样的?使用”精准排查 多级回滚”策略进行排查1.核心排查流程基于 RAGAS 指标的快速定位当线上用户反馈“变笨了”或出现指导错误时不会盲目去改 Prompt而是依托搭建的RAGAS自动化评估体系按照优先级进行分层排查第一步看 Context Recall召回率—— 排查检索层约占 50% 的问题现象模型回答“知识库未收录”或给出的建议与型号不符排查动作优先检查知识库更新记录,很多时候效果下降是因为增量同步时旧文档被误删但新文档的向量索引还在“构建中”或者新增文档导致检索权重漂移老文档被挤出了 Top-K26,会立即对比新旧版本的知识库快照确认检索链路是否健康第二步看 Faithfulness忠实度—— 排查生成层项目场景的 P0 红线现象模型开始“一本正经胡说八道”比如给出了错误的湿化器档位建议排查动作检查近期的 Prompt 变更记录或模型温度Temperature参数,在项目场景下宁可回答“信息不足”也绝不能脑补,如果是 Prompt 约束被削弱立即回退 Prompt 版本第三步看 Answer Relevancy相关性—— 排查意图与路由层现象用户问“下水功能漏水怎么办”系统却回答了“机器故障报修”。排查动作检查路由日志和 Query 改写模块,确认用户的真实意图是否被正确分类到了对应的知识库或工具链上2. 紧急回滚机制从“一键切流”到“版本快照”如果排查发现是核心组件如新上线的 Embedding 模型、新 Prompt 或知识库更新引发了系统性故障会立即启动多级回滚预案(1).模型与 Prompt 回滚秒级恢复ModelFactory 和 Prompt 管理实现了版本化,一旦发现新模型或新 Prompt 导致幻觉率飙升可以通过网关层立即将流量 100% 切回上一个稳定版本Immediate Rollback整个过程对用户无感(2).知识库版本回退分钟级恢复针对知识库更新导致的灾难会利用 ChromaDB 或向量数据库的版本快照功能一键将知识库状态回退到更新前的时间点,回退后使用包含真实用户问题的“黄金测试集”跑一遍自动化评估确认 Precision 和 Faithfulness 恢复到基线水平如 0.863 以上后再重新开放线上流量3.服务降级策略保底线防崩溃在排查和回滚期间为了保证 C 端用户的体验系统会触发多级降级策略Fallback(1).轻度降级L1如果大模型推理耗时变长或队列堆积系统会自动关闭非核心的“创意生成”或“超长多轮记忆”功能精简 Prompt限制最大输出 Token优先保障核心问答的可用性(2).中度降级L2 - 缓存兜底如果检索服务出现抖动系统会强制优先走 Redis 语义缓存,对于“滤网多久换一次”这类高频问题直接返回缓存的标准答案跳过实时推理用极低延迟保障基本服务(3).重度降级L3 - 人工接管如果大模型频繁超时或发生严重幻觉触发安全熔断机制,系统会直接返回静态兜底话术如“当前系统维护中已为您转接专属人工顾问”并附带用户的设备异常日志无缝转交人工处理,在项目场景下宁可保守转人工绝不可冒进编造总结来说面对线上效果下降原则是排查靠量化指标RAGAS回滚靠版本快照底线靠多级降级,在 AI 领域工程化的最高境界不是让系统永远不出错而是当错误发生时有能力在秒级内将其控制在安全边界内不让风险暴露给用户