参考资料

• FastAPI 大型应用
• Docker Compose

项目实战（29） - 进阶：垂直行业 Agent 项目案例

读完后，你应能完成以下任务：

• 绘制“项目实战（29） - 进阶：垂直行业 Agent 项目案例 / 怎么读这些案例”的关键对象与数据流，解释“你不需要做完所有行业项目，但要学会把任何行业项目拆成同一套工程语言。”，并用源码位置、日志或 Trace 标注证据。
• 为“项目实战（29） - 进阶：垂直行业 Agent 项目案例 / 案例一：合同风控审查 Agent”设计正常与异常输入，验证“业务问题：法务/风控审核一份合同要 30-60 分钟，标准不统一，容易漏掉租期、违约金、权利义务不对等等风险。”，输出首个偏差位置与回归测试结果。
• 实现“项目实战（29） - 进阶：垂直行业 Agent 项目案例 / 案例二：法律检索与类案分析 Agent”的最小代码或配置，检验“普通关键词检索能搜到词，但很难回答“这个案件和哪些案例相似、裁判倾向是什么”。”，输出命令、结果与 Diff，并说明不适用边界。

一、垂直行业 Agent 项目案例的真实应用场景

你准备 AI 应用工程师面试，手里有好几个项目素材：合同审查、法律检索、智能客服、车联网助手、教育对话、多模态素材中心。它们看起来跨度很大，如果逐个背技术栈，很容易讲成流水账。

更稳的做法是把它们拆成同一套结构：业务问题是什么，输入数据从哪里来，RAG 和工具调用怎么配合，Agent 为什么要拆，哪些动作必须人工确认，最后用什么指标证明有效。这样换一个行业，也能讲出工程深度。

二、怎么读这些案例

不要背项目名。面试官不关心你能不能说出“合同风控审查 Agent”这个名字，他关心你能不能讲清：

拆解项	要回答的问题
业务问题	这个项目替谁解决什么痛点
输入数据	文档、图片、数据库、用户问题分别来自哪里
核心链路	RAG、工具调用、Agent 编排怎么串起来
关键难点	为什么不是调一次模型就行
指标	准确率、召回率、延迟、成本、人工节省怎么衡量
简历表达	写成项目经历时怎么不堆名词
面试追问	面试官最可能追哪一层

下面每个案例都按这个模板读。你不需要做完所有行业项目，但要学会把任何行业项目拆成同一套工程语言。

三、案例一：合同风控审查 Agent

业务问题：法务/风控审核一份合同要 30-60 分钟，标准不统一，容易漏掉租期、违约金、权利义务不对等等风险。

核心链路：

合同上传
  -> PDF/Word/OCR 解析
  -> 抽取甲方、乙方、金额、期限、违约条款
  -> 检索法律条文、合同模板、历史审查案例
  -> 规则判断硬风险
  -> LLM 解释条款风险和修改建议
  -> 生成 Markdown/PDF 审查报告

关键难点：

• 金额、日期、主体这些字段不能靠模型自由发挥，要抽取后校验。
• 违约金过高、管辖不利、权利义务不对等等风险，适合“规则 + 模型解释”组合。
• 报告里的每个风险点都要带合同片段和依据来源。

简历表达：

设计合同风控审查 Agent，支持 PDF/Word 合同解析、关键字段抽取、法律 RAG 检索和风险规则判断；基于 LangGraph 编排“字段抽取、法律审查、商业风险、报告生成”多步骤流程，输出带合同片段和依据引用的审查报告。

面试追问：你怎么保证模型不会乱判风险？答法是：确定性字段和硬规则走代码校验，模型负责解释和建议，最终报告必须带证据。

四、案例二：法律检索与类案分析 Agent

业务问题：法律咨询、类案检索、法条查询、案件研判都需要找依据。普通关键词检索能搜到词，但很难回答“这个案件和哪些案例相似、裁判倾向是什么”。

核心链路：

用户问题
  -> 识别检索意图
  -> Query Rewrite / 任务拆解
  -> Hybrid Search 检索法条、司法解释、案例
  -> rerank 精排依据
  -> 生成类案要点、裁判倾向、法律依据、处理建议

关键难点：

• 法条号、案号适合 BM25，口语化法律问题适合向量召回。
• 法律回答必须保留依据，不能只给结论。
• 类案分析要结构化输出：争议焦点、法院观点、适用规则、相似点和差异点。

简历表达：

构建法律检索与类案分析 Agent，清洗法条、司法解释、裁判案例和合同范本，采用 Milvus + Elasticsearch 双路召回、RRF 融合和 rerank 精排，支持 Query Rewrite、依据引用和结构化类案分析，降低直接生成带来的幻觉风险。

面试追问：法律场景为什么不能只靠大模型？答法是：法律回答必须可追溯，模型只能组织依据，不能凭记忆编依据。

五、案例三：企业智能客服中枢

业务问题：客服问题来源复杂，有政策问答、订单查询、账单问题、技术问题、投诉转人工。一个简单聊天机器人容易答错、乱调工具或把用户晾住。

核心链路：

用户问题
  -> 意图识别三路融合
  -> RAG 知识问答 / 业务工具调用 / 转人工
  -> 多 Agent 路由到 General、Technical、Billing
  -> 三层记忆保留会话、摘要、用户画像
  -> LLM-as-Judge 抽样评估回复质量

关键难点：

• 路由要稳：规则识别强特征，embedding 匹配历史意图，LLM 处理长句和多意图。
• 工具调用要可控：查订单是只读，退款/建工单是写操作，要确认。
• RAG 没命中时不能硬拒答，客服场景要转人工接住用户。

简历表达：

实现企业智能客服中枢，集成 RAG 知识库、Function Calling 工具调用、Redis 会话记忆和多 Agent 路由；通过规则、embedding 和 LLM 分类三路融合识别意图，支持政策问答、订单查询、账单处理、转人工和 LLM-as-Judge 质量评估。

面试追问：怎么判断是查知识库还是调工具？答法是：先路由，再分支处理；RAG 没证据转人工，工具调用走权限、参数和确认。

六、案例四：车联网 APP 智能助手

业务问题：用户在车联网 APP 里既会问“割草机怎么用”，也会查“今天割了多少草”，还可能发“停止割草、开灯、设置童锁”这类指令。

核心链路：

用户输入
  -> 主协调 Agent
  -> 指令 Agent / 数据查询 Agent / 知识库 Agent / 天气 Agent
  -> 汇总 Agent 统一返回
  -> 危险指令前端确认后执行

关键难点：

• 指令 Agent 只生成 command，不直接执行。
• 数据查询和知识问答是两类能力，不能混在一个 prompt 里硬猜。
• 开关设备、停止任务、设置童锁这类动作要前端确认。

简历表达：

基于 LangGraph 设计车联网 APP 智能助手，包含主协调 Agent、指令 Agent、数据查询 Agent、知识库 Agent 和天气 Agent；支持设备知识问答、运行数据查询、天气查询和设备指令生成，危险指令通过前端确认后再执行。

面试追问：为什么指令不直接执行？答法是：模型只负责生成候选动作，后端和前端负责权限、参数、风险确认。

七、案例五：K12 教育多智能体对话系统

业务问题：教育 AI 不只是“答题”。它要批改作业、讲错题、陪伴情绪、分析学情，还要保证多轮对话连贯和服务稳定。

核心链路：

学生输入 / 作业图片
  -> OCR / 图文解析
  -> 主 Agent 路由
  -> 作业批改 Agent / 错题辅导 Agent / 情绪陪伴 Agent / 学情分析 Agent
  -> RabbitMQ / A2A 做服务化通信
  -> 学情看板和风险预警

关键难点：

• 学科问题、情绪陪伴、学情分析的上下文和安全边界不同，适合拆 Agent。
• 作业图片需要 OCR 或 VLM，不能只处理纯文本。
• 教育场景要注意异常容错和降级，避免学生卡在流程中。

简历表达：

搭建 K12 教育多智能体对话系统，基于 LangGraph 设计全局状态总线，拆分作业批改、错题辅导、情绪陪伴、学情分析等业务 Agent；通过 OCR 接入图文作业，结合向量检索和学情数据生成个性化辅导，并设计异常容错和服务降级策略。

面试追问：为什么教育场景要多 Agent？答法是：不同任务的输入、上下文、安全边界和生命周期不同，拆开更容易控制。

八、案例六：多模态素材中心

业务问题：电商、内容和客服团队有大量商品图、详情页、视频素材。用户问“这张图里展示的功能是什么”或“找一段开箱视频”，纯文本知识库回答不了。

核心链路：

图片/视频/文本素材
  -> OCR / VLM / ASR
  -> 生成 retriever_text 和结构化标签
  -> text/image/video 统一 asset 表
  -> 按模态动态召回和重排
  -> 前端返回文字答案 + 素材片段

关键难点：

• 图片、视频不能只存 URL，要生成可检索文本和标签。
• manual 路线适合人工维护标题、分类、标签；enriched 路线适合 OCR/VLM/ASR 自动补充。
• 不同模态相似度分布不同，阈值和 topK 不能一套参数走天下。

简历表达：

设计多模态素材中心，统一管理 text/image/video 资产，通过 OCR、VLM、ASR 提取图片文字、图像描述和视频摘要，生成 retriever_text 入库检索；按模态配置召回阈值和 topK，支持图文客服回答和素材证据回跳。

面试追问：多模态知识库和普通 RAG 最大差别是什么？答法是：普通 RAG 的证据是文本，多模态 RAG 要先把图片/视频转成可检索证据，并保留素材定位。

九、可迁移的方法论

维度	任何垂直项目都要问
输入	用户输入、文档、图片、数据库、外部 API 分别是什么
知识库	哪些内容走 RAG，哪些内容走结构化查询
工具	哪些是只读工具，哪些是写操作
Agent 编排	是固定 workflow，还是需要 Agent 动态决策
记忆	只要当前会话，还是要跨会话画像
评测	看召回、正确率、拒答、满意度还是业务指标
权限	谁能看、谁能查、谁能执行动作

会这个表，看到一个新行业项目就不会慌。先把输入、知识、工具、编排、记忆、评测、权限画出来，再决定用不用 RAG、Agent、MCP、GraphRAG。

十、工程上真正会踩的坑

• 行业术语没标准化。同一个设备、条款、学科知识点有多个叫法，检索和图谱都会断。
• 只有功能没有指标。写“实现智能客服”，不如写路由准确率、转人工率、P90 延迟。
• 报告无引用。合同和法律项目尤其危险，没有依据就是模型作文。
• 危险指令无确认。车联网、工单、退款、发消息都不能让模型直接执行。
• 多模态只入库不评测。图片和视频也要测召回，不然只是存了一堆素材。
• 案例堆叠没有主线。简历里写 6 个项目，不如写 2 个能讲清架构、难点和指标的项目。

十一、总结

• 案例一：合同风控审查 Agent：业务问题：法务/风控审核一份合同要 30-60 分钟，标准不统一，容易漏掉租期、违约金、权利义务不对等等风险。
• 案例二：法律检索与类案分析 Agent：普通关键词检索能搜到词，但很难回答“这个案件和哪些案例相似、裁判倾向是什么”。
• 案例三：企业智能客服中枢：工具调用要可控：查订单是只读，退款/建工单是写操作，要确认。
• 案例四：车联网 APP 智能助手：业务问题：用户在车联网 APP 里既会问“割草机怎么用”，也会查“今天割了多少草”，还可能发“停止割草、开灯、设置童锁”这类指令。
• 案例五：K12 教育多智能体对话系统：业务问题：教育 AI 不只是“答题”。
• 案例六：多模态素材中心：用户问“这张图里展示的功能是什么”或“找一段开箱视频”，纯文本知识库回答不了。