# FDE W4D3 评测题 · 特药理赔 Agent 主流程 > 配套手册：《FDE-W4D3-特药理赔Agent主流程-学习手册.html》 > 主题：10 节点主流程编排、各节点职责、编排 vs 复用（OCR/DB/Rule 复用 W2、知识库复用 W3、LangGraph 复用 W4D2）、为什么不要重写工具 > 场景主线：特药理赔 Agent（36 岁候选人，Java + 大数据 + 医疗保险背景） > 题型：L1 基础 / L2 进阶 / L3 深度 / L4 场景，共 13 题 > 计分：每题满分 10 分；参考答案折叠在 `
` 中，建议先自答再看。 --- ## L1 基础（概念识别，每题 10 分） ### Q1. 请按顺序列出特药理赔 Agent 的主流程节点（至少 8 个）。 - **考察点**：是否记住整条主链路。 - **评分维度**： - 顺序正确（上传→OCR→抽取→完整性→检索→规则→风险→人工→结论→回写）（7 分） - 共 10 节点且命名清晰（3 分）
参考答案 ①上传材料 → ②OCR → ③字段抽取 → ④材料完整性检查 → ⑤保单&知识库检索 → ⑥规则引擎校验 → ⑦风险等级判断 → ⑧人工审批(HITL) → ⑨结论生成 → ⑩结果回写。共 10 节点。
### Q2. 主流程中哪些节点是"复用已有工具"，哪些是"LLM 节点"，哪些是"纯逻辑/IO"？ - **考察点**：区分编排中的能力来源。 - **评分维度**： - 复用：OCR/检索/规则/回写（4 分） - LLM：抽取/风险/结论（3 分） - 逻辑/IO：上传/完整性/人工审批（3 分）
参考答案 - **复用 W2/W3 工具**：OCR（②）、检索（⑤，保单 DB + 知识库 RAG）、规则校验（⑥）、结果回写（⑩）。 - **LLM 节点**：字段抽取（③）、风险等级判断（⑦）、结论生成（⑨）。 - **纯逻辑/IO 或 HITL**：上传（①）、完整性检查（④）、人工审批（⑧，interrupt）。
### Q3. 为什么这个 Agent 是 Agentic Workflow 而不是纯 Agent？ - **考察点**：呼应 W4D1 概念，落实到本业务。 - **评分维度**： - 确定性主流程骨架（4 分） - 模型只在抽取/风险/结论决策（3 分） - 人工审批节点控制（3 分）
参考答案 主流程是开发者编排的确定性图骨架（顺序、条件边、interrupt 时机都写死），只有"抽取/风险判断/结论生成"几个节点由模型决策，且高风险必须人工审批。模型不决定整体流程走向，只在节点内发挥智能——这正是 Agentic Workflow，兼顾可控与灵活、满足医保合规。
--- ## L2 进阶（机制理解，每题 10 分） ### Q4. 节点⑥（规则引擎校验）为什么必须用规则引擎而非让 LLM 直接算赔付金额？ - **考察点**：确定性计算 vs 模糊智能的边界。 - **评分维度**： - 金额需精确/可复算/可审计（5 分） - LLM 会算错且不可解释、引发客诉合规风险（5 分）
参考答案 赔付金额、比例、免赔额是硬计算，必须精确、可复算、可审计，不能靠模型"感觉"。LLM 可能算错还自信，导致客诉与合规风险。正确做法：抽取字段 + 检索依据喂给 W2 已有规则引擎做确定性判定，模型只负责模糊的抽取与前面的判断，硬计算留给规则引擎。
### Q5. 节点⑤（检索）为什么要"带引用"，如何处理检索结果才稳妥？ - **考察点**：RAG 溯源与 State 成本控制。 - **评分维度**： - 带引用：防幻觉、可审计、可申诉（4 分） - 存摘要+引用 id，不全量塞 State（4 分） - 查不到要明确信号传给规则引擎（2 分）
参考答案 带引用（chunk_id/条款号）能让下游规则引擎和结论生成溯源，防幻觉、满足医保合规审计与用户申诉。处理上：检索结果不要原样全量塞进 State（长文档占存储、烧 token），应存"摘要 + 引用 id"，详情按需再查；且"查不到"（断保/无该药）要作为明确信号传给规则引擎，而非让模型猜。
### Q6. 节点⑧（人工审批）在 LangGraph 里怎么实现？它依赖 W4D2 的什么机制？ - **考察点**：HITL 落地，跨天衔接。 - **评分维度**： - 条件边路由 + interrupt 暂停（5 分） - 依赖 Checkpointer 存状态 + Command(resume) 恢复（5 分）
参考答案 `risk_level == high` 时条件边路由到 `human_approve` 节点，节点内 `interrupt()` 暂停把案件推给审核员。依赖 W4D2 的 Checkpointer（存暂停前状态，保证可恢复）和 Command(resume=决策)（同 thread_id 唤醒继续）。全程留痕可审计，超时可升级。
### Q7. 节点⑩（回写）和通知为什么要幂等？不幂等会怎样？ - **考察点**：把 Day1 幂等考点落到业务最危险处。 - **评分维度**： - 图会重放节点（4 分） - 重复打款/重复发短信（4 分） - 结论与回写最终一致（2 分）
参考答案 LangGraph 在中断恢复/重试时会重放节点。若回写/通知工具不幂等，重放会重复打款、重复发短信，造成资金损失与用户投诉。因此回写工具要幂等+去重，且结论生成与回写要保证最终一致（如"已回写"状态标记），避免"结论出了但回写失败"。
--- ## L3 深度（原理与权衡，每题 10 分） ### Q8. 什么是"编排"、什么是"复用"？本流程里各举两个例子。 - **考察点**：本日核心概念辨析。 - **评分维度**： - 编排=新写的薄控制层（顺序/分支/等人/汇总）（5 分） - 复用=W2/W3 已有工具包成 @tool（5 分）
参考答案 - **编排（Orchestration）**：Agent/LangGraph 新写的薄控制层，决定"调哪些工具、什么顺序、何时等人、怎么汇总"。例：图的节点顺序、条件边分支、interrupt 时机、结论汇总。 - **复用（Reuse）**：把 W2/W3 已有的成熟能力（OCR、保单 DB 查询、规则引擎、知识库 RAG、结果回写）包成 `@tool` 直接挂进图，不重写。例：ocr_scan（W2）、rule_engine（W2）、rag_search（W3）、save_claim（W2）。
### Q9. 为什么"不要重写工具"，请列出至少 4 条理由。 - **考察点**：工程哲学——复用优于重写。 - **评分维度**：每条理由 2.5 分，满分 10；覆盖：口径一致/省成本/更可靠/责任清晰/易演进（任 4 条）。
参考答案 1. **口径一致**：两套 OCR/规则对不上，结论是"两套系统冲突"，合规灾难。 2. **省成本**：重写识别/规则需数月，重新测试过审，没必要。 3. **更可靠**：老服务已跑通、有监控熔断，新写 bug 多。 4. **责任清晰**：模糊智能给模型、确定性计算给工具，问题易定位。 5. **易演进**：工具升级（换 OCR 模型）不影响编排层，只换实现。 注：复用可能是"加适配层"（把 Java 接口包成 @tool），不是完全不碰旧工具——这是适配不是重写。
### Q10. 材料完整性检查（节点④）应该在流程的什么位置？为什么要"前置拦截"？ - **考察点**：流程设计的健壮性思维。 - **评分维度**： - 位置在抽取之后、检索之前（3 分） - 脏数据不流入规则引擎/检索（4 分） - 缺失则条件边转人工/补传，不浪费下游算力（3 分）
参考答案 节点④放在抽取之后、检索之前。前置拦截原因：① 必备材料缺失时，后续检索/规则引擎在脏数据上跑没意义且可能误判；② 缺失应走条件边转"请补传"或直接人工，避免浪费下游 RAG/规则算力；③ 早失败早返回，用户体验与成本都更好。它是纯逻辑节点，输出 missing 列表与 need_human 标记。
### Q11. 风险等级（节点⑦）的判定标准和"可解释性"为什么重要？ - **考察点**：把模型决策与合规要求结合。 - **评分维度**： - 判定维度清晰（金额/材料/规则边界/欺诈）（4 分） - 可解释=审核员看懂为何 high、可申诉（3 分） - 标准可配置（3 分）
参考答案 risk_level 由 LLM 综合"抽取+检索+规则结果"给出 low/medium/high，决定自动过还是转人工。判定标准必须清晰（如大额/材料异常/规则边界/疑似欺诈→high）、可配置（随政策调阈值）、可解释（审核员能看懂为什么判 high）。可解释性直接关系合规审计与用户申诉——不可解释的风险分级在保险场景不可接受。
--- ## L4 场景（特药理赔 Agent 实战，每题 10 分） ### Q12. 请用 LangGraph 描述特药理赔 Agent 的图结构（节点 + 关键边），并说明哪些节点是复用、哪些是 LLM。 - **考察点**：综合把主流程落成图，对应 W4D2 能力。 - **评分维度**： - 节点齐全（4 分） - 关键边（START/条件边/interrupt/END）正确（4 分） - 标注复用 vs LLM（2 分）
参考答案 节点：upload→ocr(ToolNode,复用W2)→extract(LLM)→completeness(逻辑)→retrieve(ToolNode,复用W2+W3)→rule_check(ToolNode,复用W2)→risk_judge(LLM)→human_approve(interrupt,HITL)→conclude(LLM)→writeback(ToolNode,复用W2)→END。 关键边：START→upload；completeness 条件边（need_human?→human_approve:retrieve）；risk_judge 条件边（high→human_approve:conclude）；human_approve→conclude；writeback→END。compile 挂 PostgresSaver 持久化。
### Q13. 假设你接手这个项目，团队里有人主张"用 LLM 重写一套识别和规则，去掉老 Java 服务，更统一"。请陈述你的反对理由与正确做法。 - **考察点**：工程判断力——复用优于重写，落到管理沟通。 - **评分维度**： - 反对重写（口径/成本/可靠/合规）（5 分） - 正确做法：适配层包成 @tool 复用（3 分） - 编排薄层、智能点缀（2 分）
参考答案 反对理由：① 口径一致——新老两套识别/规则对不上会引发合规与客诉；② 成本——重写数月且要重测重审；③ 可靠——老 Java 服务有监控熔断、已验证，LLM 算规则不可复算；④ 合规——赔付必须确定性、可审计，不能靠模型"感觉"。 正确做法：保留老服务，加一个轻适配层把它包成 `@tool`（返回结构化 JSON）挂进 LangGraph；Agent 只做编排薄层（顺序/分支/等人/汇总）与模糊智能（抽取/风险/结论），确定性计算全交给复用工具。即"能复用绝重写，编排薄如纸"。
--- ## 评分汇总表 | 题号 | 层级 | 主题 | 满分 | 自评分 | 达标要求 | |------|------|------|------|--------|----------| | Q1 | L1 | 主流程节点 | 10 | / | 顺序正确+10节点 | | Q2 | L1 | 复用/LLM/逻辑分类 | 10 | / | 三类分清 | | Q3 | L1 | Agentic Workflow 定性 | 10 | / | 确定性骨架+模型节点 | | Q4 | L2 | 规则引擎而非 LLM 算钱 | 10 | / | 精确/可审计/防错 | | Q5 | L2 | 检索带引用+处理 | 10 | / | 溯源+摘要+信号 | | Q6 | L2 | 人工审批实现 | 10 | / | interrupt+Checkpointer | | Q7 | L2 | 回写幂等 | 10 | / | 重放→不重复 | | Q8 | L3 | 编排 vs 复用 | 10 | / | 定义+各2例 | | Q9 | L3 | 不重写理由 | 10 | / | ≥4 条理由 | | Q10 | L3 | 完整性前置拦截 | 10 | / | 位置+健壮性 | | Q11 | L3 | 风险等级可解释 | 10 | / | 标准/可解释/可配置 | | Q12 | L4 | 图结构落地 | 10 | / | 节点+边+复用标注 | | Q13 | L4 | 反对重写决策 | 10 | / | 理由+适配层做法 | | **合计** | — | — | **130** | **/** | — | ### 达标线 - **达标线①（流程图）**：Q1~Q3 + Q12 得分 ≥ 40/50，能徒手画出 10 节点主流程并说清每节点职责与"复用/LLM/逻辑"属性。 - **达标线②（编排 vs 复用）**：Q8 + Q9 + Q13 得分 ≥ 25/30，能讲清"编排（薄控制层）vs 复用（W2/W3 工具）"并说清不重写工具的五大理由。 - **总分达标**：≥ 100/130（约 77%）可视为本日面试达标；L4 两题（Q12、Q13）必须各 ≥ 7 分，否则需重练图落地与工程决策表达。 - **建议**：失分多在"编排 vs 复用"或图落地时，重读手册 s9（编排 vs 复用）、s10（图代码）、s11（易错点），并对照 W4D1/W4D2 串起"概念→框架→业务"三层。