FDE W2D3 学习手册 · 数据库 Tool 与规则 Tool

W2 Week2 Day3 · A 级（必须掌握，安全核心）· 5h · 学完能讲透"让 Agent 安全查库、可靠算规则"的设计与风控

一、数据库 Tool 的定位与安全基调

数据库 Tool 让 Agent 能查保单、理赔记录、药品目录等。但它和 OCR 不同——直接接触核心业务数据，一旦设计不当，轻则查错、重则SQL 注入 / 越权读隐私 / 拖垮生产库。

二、参数化 SQL 与防注入

2.1 什么是 SQL 注入

若把模型给的参数直接拼进 SQL 字符串，攻击/幻觉可能注入恶意语句：

# 错误示范：字符串拼接
sql = "SELECT * FROM policy WHERE policy_no = '" + args['policy_no'] + "'"
# 若 policy_no = "x'; DROP TABLE policy; --"  → 灾难

2.2 参数化查询（Prepared Statement）

# 正确：占位符 + 参数绑定，数据库区分"代码"和"数据"
cur.execute(
  "SELECT policy_no, holder, special_drug_limit FROM policy WHERE policy_no = %s",
  (args['policy_no'],)        # 参数由驱动安全转义
)

三、只读账号与最小权限

3.1 专用只读账号

数据库 Tool 用的连接账号，必须是独立的、只读（SELECT only）的专用账号，绝不复用业务写库账号或 DBA 账号。

3.2 最小权限原则

• 只授予 Tool 实际需要的库/表/列读权限。
• PII 列（身份证、手机号）要么不授予，要么授权脱敏视图。
• 网络层限制 Tool 账号只能从应用服务器 IP 连。

四、表和字段白名单

4.1 为什么需要白名单

参数化解决了"注入"，但没解决"查到不该查的表/字段"。白名单在应用层再锁一层：只允许访问预定义的表和字段。

ALLOWED_TABLES = {"policy", "claim_record", "drug_catalog"}
ALLOWED_COLUMNS = {
  "policy": {"policy_no","holder","special_drug_limit","valid_until"},
  "claim_record": {"claim_id","status","amount","reason"},
  "drug_catalog": {"drug_name","is_special","price"}
}
def build_query(table, columns, where):
    if table not in ALLOWED_TABLES: raise PermissionError("表不在白名单")
    bad = set(columns) - ALLOWED_COLUMNS[table]
    if bad: raise PermissionError(f"字段不在白名单: {bad}")
    # 只允许等值/IN 条件，列名也必须白名单校验
    ...

五、查询超时与返回数量限制

5.1 查询超时

给每个查询设语句超时（如 PostgreSQL 的 statement_timeout），防止慢查询/全表扫描拖垮数据库。

cur.execute("SET LOCAL statement_timeout = 3000")  # 3 秒超时
cur.execute("SELECT ... FROM policy WHERE ...")

5.2 返回数量限制

• 强制 LIMIT（如最多 50 行），避免一次返回几万行撑爆上下文/内存。
• 分页或聚合优先；需要全量时走离线任务而非 Tool 实时返回。
• 返回前裁剪/脱敏敏感字段，只留下游需要的。

六、审计日志

6.1 记什么

• 谁（哪个用户/session）在何时查了什么（表/条件/参数）。
• 返回了什么摘要（脱敏后），命中多少行。
• 查询是否成功、耗时、是否触发白名单拒绝。

6.2 审计的价值

保险行业对 PII 访问有合规要求（可追溯、可审计）。审计日志用于：合规报备、异常检测（某账号频繁查陌生保单）、争议溯源。

七、规则 Tool 的定位

规则 Tool 负责确定性的业务决策与计算：理赔金额怎么算、风险等级怎么定、是否拒赔。它和数据库 Tool 互补——一个取数，一个决策。

八、简单规则脚本 vs Drools 规则引擎

8.1 Drools 简介

Drools（drools.org）是成熟的 Java 规则引擎，用 DRL 描述规则：when（条件）→ then（动作）。规则与业务代码解耦，支持版本管理、规则流、复杂事件。

rule "特药目录内且额度充足-全额赔付"
  when
    $c : Claim( drugInCatalog == true, amount <= specialDrugLimit )
  then
    $c.setPayAmount($c.getAmount());
    $c.setRiskLevel("low");
    $c.setReason("特药在目录内且额度充足");
end

九、规则版本管理

• 规则要版本化：每条规则有版本号、生效时间、作者、变更原因。
• 决策可回溯：一次理赔结论要能关联到"当时生效的哪版规则"，避免政策变了却说不清旧案为何那么赔。
• 灰度/回滚：新规则先小流量，异常可快速回滚到上一版。
• 审批流：规则变更走审批，不能谁改了线上就变。

十、命中依据、金额计算与风险等级

10.1 命中依据（为什么这么算）

规则引擎输出不只给结果，还要给依据链：命中了哪些规则、输入是什么、得出什么结论。这既是可解释性，也是争议处理依据。

{
  "pay_amount": 1280.00,
  "risk_level": "low",
  "hit_rules": ["R-特药目录内", "R-额度充足"],
  "reason": "药品奥希替尼在特药目录，金额1280≤额度30万",
  "rule_version": "v2026.03"
}

10.2 金额计算与风险等级

十一、资源与工具

• Drools 官网：drools.org —— 规则引擎、DRL 语法、决策表。
• PostgreSQL 文档：postgresql.org/docs/current —— statement_timeout、权限、脱敏（如 pgcrypto）。
• LangChain Tools：python.langchain.com/docs/how_to/tools —— 如何把 SQL/函数封装成 Agent 可调的 Tool。
• SQLAlchemy / JDBC：参数化查询的标准做法。

十二、面试达标线①：数据库 Tool 的安全设计

• 只读账号：专用 SELECT-only 账号，绝不复用写/DBA 账号，纵深防御。
• 参数化：占位符绑定，数据库区分代码与数据，杜绝 SQL 注入。
• 白名单：应用层限制可查的表、字段、条件列（用白名单不用黑名单）。
• 超时 + 限量：statement_timeout + 强制 LIMIT，保护生产库。
• 审计：记谁/何时/查什么/返回多少，关联业务 session，日志防篡改。

十三、面试达标线②：规则引擎在理赔风控的应用与对比 LLM 算金额

• 怎么用：Agent 用 LLM 理解用户诉求→调用数据库 Tool 取数→调用规则 Tool（Drools）→规则引擎按版本化规则算出 pay_amount / risk_level，并附带命中依据链。
• 优势总结：精确、可复现、可审计、可热更新、合规友好——这是金额/风控这种"不能错"的场景必须上规则引擎的根本原因。

十四、W2D3 自测清单

十五、高频面试题速记卡