刘迪君 AI 应用开发 / Agent 工程 · 把大模型约束在确定性工程边界内

我负责的四块

• RAG 检索链路：以字段元数据、Few-shot 用例、指标别名三类向量集合（67 / 104 / 74 条）为检索源，最小检索单元是「一个字段 / 一条用例 / 一个别名」；用 Join 图 BFS 最小边集补全多表拓扑，用粒度对齐防止一对多 JOIN 把金额放大；以 score_threshold + payload 过滤 + 业务优先级剪枝替代两阶段 rerank，省掉一次模型调用。
• 指标语义层：12 个核心指标的口径（公式 / 过滤条件 / 时间归属 / 可用维度 / 权限标签）配置化落库，由统一取数规划器翻译成只读 SQL——口径变更不发版，代码侧零硬编码公式。
• 缓存与并发：缓存键强制包含权限范围哈希（否则 A 用户的结果会被 B 用户命中，这是最典型的数据泄露路径）；single-flight 请求合并削峰；分布式锁 SET NX PX 原子获取 + Lua 校验持有者删除 + 长任务按锁时长 1/3 续期；「锁 + 幂等表」双层保证日报推送幂等。
• 多智能体编排：LangGraph StateGraph 把 15 节点主链路固化为代码控制流（仅 5 处条件边），取代自由 Agent 循环；会话状态经 Checkpointer 持久化。

三次真实故障（比成绩更能说明做事方式）

一句话说清技术选型

为什么不用自由 Agent

业务链路固定，自由循环换来的是不可复现的失败；固化成状态机后每一次失败都能重放到具体节点。

为什么不让模型写 SQL

模型负责「理解问题 + 拼装结构」，SQL 由语义层编译；模型输出永远不直接进执行路径。

为什么不做 rerank

结构化检索的候选集很小且带业务标签，阈值 + payload 过滤已足够，省一次模型调用的延迟与成本。

五个设计决策

• 协议驱动渲染：每类物料声明 props_schema（属性结构 / 数据契约 / 默认值），属性面板自动生成——新增组件只注册物料、不改编辑器，把开闭原则落到代码结构上（8 类物料）。
• 表达式不开放 eval：表达式来自业务配置，等于把执行权交给配置人员。自研递归下降解析器把它变成自己的 AST，语法里根本没有属性访问、下标、import，所以 __import__('os').system(...) 连解析都过不去。
• 权限下推到最内层 WHERE：不做「查完再过滤」——那样可以用「总数 − 可见明细」反推隐藏数据。条件注入到每个直接读取目标表的 SELECT，并用该层别名限定列名，避免 JOIN 歧义列报错。
• 粒度对齐：orders ↔ refunds 是 1:N 且非粒度对齐，直接 JOIN 会让 SUM(pay_amount) 按退款条数翻倍；编译器先把退款按 order_id 预聚合到订单粒度，再 LEFT JOIN。
• 发布快照 + 缓存键含权限指纹：草稿 / 发布双态、发布生成快照可回滚；缓存键强制包含权限范围指纹，避免跨权限命中。

模型在这里的位置

自然语言 → 页面 DSL 只产出候选，不做任何直接执行；候选经 AST 白名单校验 + 试渲染双重把关，校验失败把错误信息回灌重新生成。模型能力与确定性边界各自负责一段，出问题能定位到是哪一段。

实测：受限用户只能看到其权限范围内的部分数据，且无法用「总数 − 可见明细」反推隐藏部分。

为什么值得做

大多数 Agent 作品的展示方式是「它能做什么」；招聘方更想确认的是「它搞不定的时候会怎样」。这个项目把不可见的风险变成可测量的数字，也延续了我前两个项目的同一条主线：不可信输入不进执行路径——在 SQL 上是 AST 白名单与权限下推，在 Agent 上是工具权限闸门与轨迹约束。

评测口径（避免自说自话）

• 命中判定：规则优先——断言工具调用序列（是否调用了越权工具、参数是否含敏感路径、外发请求是否携带密钥）；规则覆盖不到的场景才交给 LLM 判据，判据先用 20 条人工标注样本校准一致性。
• 误杀控制：同时跑一组不含攻击的正常任务，任何防御导致正常任务失败都计入误杀率，不做「只测攻击、不测正常」的乐观评测。
• 可复现：固定 seed、温度 0、用例集入库；每次改动只允许动一个变量，跑同一套集对比。

逐层边际（去掉某层后 ASR 上升多少）

③ 参数校验 +21.6 pp、⑤ 出站过滤 +8.3 pp、①②④ 各 +3.3 pp。结论是「防御要分层，但真正拦得住的是参数校验」——把路径与 SQL 卡死，比在 prompt 里写一百句「不要听用户的」有用。

当前进度与口径

评测链路（60 + 20 条用例 × 7 种防御组合 × 双引擎）已跑通，报告由脚本生成、不接受手填；26 条单测/端到端测试全绿，GitHub Actions 在 Python 3.11 / 3.12 上自动跑。

口径声明：以上基线由确定性的脚本模型产出（把 7B 级模型的常见失效方式写成规则），用于验证评测链路与各层防御的贡献，不代表真实 LLM 的攻击成功率；接 Ollama / DeepSeek 只需换 provider，用例与判据完全复用。全开配置下唯一漏网的是 SYSTEM: 伪造用例——保留它而不是调参调绿，因为那是真实失效点。

真实模型（deepseek-v4.1-flash）抽样 5 条 × 2 配置已跑完：ASR 0%（模型直接拒绝注入）、正常任务 100%、防御全开时触发 2 次工具层拦截。结论是模型层对齐是第一道防线，防御层是纵深；全量矩阵受免费网关限流限制，逐层边际由脚本模型给出，两者分表、不混用。