上岸仓项目组
上岸仓项目组 · 内部技术文档

LLM Agent 查询基础设施:从“能接”到“可推理、可追问、可演进”

Technical Brief · Infrastructure Design · Query Engineering
本页给出一套可复用的方法:先以查询语义定义业务,再用 Read Model 承接结构化表达,通过 Query Surface 与 Operation Surface 明确边界,最终以流程化验收和案例迁移确保长期稳定。目标不是“接口接通”,而是构建可持续的 Agent 查询底座。

01. 第一性原理:LLM 需要可推理的查询面

LLM 擅长

自然语言理解、条件抽取、在明确 schema 上组合推理、承接 follow-up。

LLM 不擅长

猜黑盒接口能力、记忆零散隐式规则、在单 query 字符串上稳定检索。

工程结论

不要让模型猜能力,应显式给出实体、字段、过滤、排序、limit、detail by id。

Q* = { entity, schema, filter, sort, limit, projection, aggregation, detail by id }

当查询语义被显式建模,系统可稳定回答“这些结果的 id”“第 2 条展开”“只给我链接”等追问;否则只能依赖 prompt 补丁,成本和风险持续上升。

阐释表达

业务方关心:用户提问千变万化,但目标很朴素,就是想快速拿到准确结果,并且能继续追问“给我链接”“展开第2条”“把这些结果的 id 给我”。如果每次追问都答不稳,用户会直接判断系统不可靠。

工程上落地:不要把能力藏在接口内部规则里,要把实体、字段、筛选条件、排序、limit、详情查询入口写成明确契约。模型并不需要“聪明猜测”,它需要的是可被执行的结构化边界。

上线后:一旦查询语义明确定义,后续新增问题类型时只需要扩展字段和样例,不必持续在 prompt 上打补丁,维护成本和回归风险都会明显下降。

展开细节:底层最小交付集合与失败模式
  • 最小交付集合:实体定义、读模型、字段字典、查询能力边界、样例查询、稳定详情能力。
  • 字段字典至少覆盖:字段名、类型、中文语义、可筛选/排序/聚合、可空、枚举范围。
  • 若无稳定主键与 detail by id,follow-up 会在“这条/第2条/这些结果的 id”场景失稳。
  • 若只有单 query 字符串,无法稳定表达范围过滤、排序、聚合,属于兼容层而非主查询底座。
推荐查询样例:
- 给我湖南 2020 年后的资料
- 把刚才结果的 id 列出来
- 只要链接
- 第 2 条展开详情

02. 三层架构:稳定数据面与动作面解耦

2.1 分层职责

  • Read Model:面向查询的读视图/宽表,一行一个稳定实体。
  • Query Surface:对外暴露结构化查询能力,优先 text2sql 或结构化 Query API。
  • Operation Surface:下载、导出、审批、触发任务等动作能力,独立于查询链路。

2.2 设计约束

  • 必须有稳定主键,列表与详情分离,支持 detail by id
  • 返回结构机器友好,避免仅文本拼接结果。
  • 必须具备字段级过滤、明确排序、默认与最大 limit。
Read Model: 扁平实体、清晰字段、可索引查询 Query Surface: text2sql / Query API / REST(兼容层) Operation Surface: 下载/导出/审批等动作能力
图 1 · 查询与动作分层,避免互相污染

2.3 方案优先级

优先级实现形态适配度说明
1只读视图/宽表 + text2sql查询表达力最强,follow-up 稳定性最佳
2结构化 Query API中高安全边界更强,但灵活性低于 SQL
3固定参数 REST可做过渡,需补齐字段语义与契约
4单字符串检索仅可兼容接入,不应作为主查询底座

阐释表达

业务方关心:同一个对话里既会出现“查资料”,也会出现“下载、导出、提交”这类动作。如果底层把两类能力混在一起,渠道体验会出现时好时坏,用户会感觉系统“忽然像搜索,忽然像按钮”。

工程上落地:把 Read Model、Query Surface、Operation Surface 明确拆层。查询层只负责事实检索与结构化返回,动作层只负责执行行为与状态回执,两边通过清晰契约衔接而不是靠隐式约定。

上线后:架构分层稳定后,新增一个业务域通常只需要接入新的读模型与能力配置,不必改动核心 runtime 逻辑,扩展速度和故障定位效率都会提升。

展开细节:字段规范、契约示例与反模式

推荐统一字段:id/title/type/category/region/year/status/summary/content/source/created_at/updated_at;URL 类字段统一为 url/pdf_url/h5_url/download_url/preview_url

{
  "name": "search_kaoqing_documents",
  "kind": "query",
  "input_schema": {
    "region": {"type": "string"},
    "year_gte": {"type": "integer"},
    "limit": {"type": "integer", "default": 20}
  },
  "result_schema": {
    "entity": "document",
    "list_fields": ["id", "title", "year", "region", "pdf_url", "h5_url"]
  }
}

反模式:只有字符串 query、零散接口爆炸、页面导向返回、没有 detail by id

03. 接入流程:十阶段闭环推进

  1. Stage 01 业务澄清:明确用户问题、主实体、默认返回与不支持范围。
  2. Stage 02 能力评审:判定 query / operation / workflow,优先查询语义完备性。
  3. Stage 03 底层补齐:实体定义、字段字典、契约、样例、性能边界。
  4. Stage 04 接入设计:能力注册、输入输出 schema、delivery role、working set 策略。
  5. Stage 05 适配编码:字段归一化、错误结构化、稳定主键承接。
  6. Stage 06 本地联调:基础查询、无结果、follow-up、超时与错误路径。
  7. Stage 07 渠道联调:验证用户提问自然度与展示一致性。
  8. Stage 08 灰度观察:成功率、空结果率、follow-up 成功率、异常样本沉淀。
  9. Stage 09 正式上线:配置、日志、限流、超时、回滚方案齐备。
  10. Stage 10 上线复盘:回收缺陷,迭代规范、用例与回归测试集。

阐释表达

业务方关心:业务希望尽快上线,但更担心上线后频繁返工。真正影响体验的不是“接口今天通没通”,而是核心场景、异常场景、追问场景能不能稳定复现并被团队共同验收。

工程上落地:十阶段流程不是形式化流程,而是把风险前置。需求澄清阶段解决语义歧义,底层评审阶段解决能力边界,联调阶段解决真实链路问题,灰度阶段解决真实用户分布问题。

上线后:每个阶段都留下可追溯产物(样例、日志、结论),后续发生故障时能快速判断是上游数据、适配映射、working set 还是渠道展示问题,避免盲改 prompt。

展开细节:阶段产出与退出标准
阶段关键产出退出标准
需求澄清10+ 典型问题、主实体、默认返回策略能明确“用户查什么、详情落哪”
底层评审能力类型判定、方案优先级结论无稳定 id / 无 detail by id 则退回
本地联调基础查询+follow-up+异常样例不泄露中间态、话术与数据一致
灰度上线成功/失败样本库与监控面板跟踪成功率、空结果率、超时率

核心要求:每一阶段都应有可验证的“退出标准”,而不是凭主观感受推进。

04. 验收与治理:四维检查矩阵

数据结构

实体定义、稳定 id、字段字典、可追溯来源。

查询能力

过滤、排序、limit、聚合、detail by id、投影查询。

Agent 承接

capability 注册、schema 契约、working set 与 follow-up 连续性。

语义完整 可观测 性能 follow-up 安全
图 2 · 验收目标应均衡,不应只追求“接口可用”

上线前最小判定句

  • 能否稳定回答“这些结果的 id 给我”。
  • 能否稳定回答“第 2 条展开”。
  • 能否稳定回答“把链接发我”。
  • 能否在上游失败时返回可控错误而非内部栈。

若以上任一无法稳定承接,应判为“有条件接入”或“不建议接入”。

阐释表达

业务方关心:用户不会看系统内部架构,只会问“结果对不对、追问顺不顺、失败时是不是体面”。因此上线门槛必须围绕真实问法来定义,而不是围绕内部模块是否开发完成。

工程上落地:把检查清单做成硬约束:稳定主键、detail by id、字段字典、结构化错误、限流超时、日志链路都要可验证。尤其是“第2条”“只给链接”这类追问,是最能暴露系统短板的试金石。

上线后:验收标准可复用后,新业务域接入不会每次都从头争论“什么叫完成”,团队协作成本下降,质量基线也会更稳定。

展开细节:上线前检查项(摘录)
  • 数据与实体:核心实体定义完整,主键跨轮稳定,不依赖标题做伪主键。
  • 查询面:支持精确/范围/枚举过滤,支持 limit 与稳定排序,查询语义文档化。
  • 适配层:capability、输入输出 schema、字段映射、working set 规则齐备。
  • 可观测性:能追踪用户问题、planner 路径、adapter 参数、上游摘要、最终回复。
  • 安全与性能:只读、限流、超时、最大返回条数、慢查询风险说明。
验收口令:
1) 这些结果的 id 给我
2) 第 2 条展开
3) 把链接发我
4) 刚才那批里湖南的有哪些

05. 案例演进:从兼容接入走向稳定查询底座

5.1 当前状态与问题

兼容式 REST 接入可以快速上线,但当查询进入“范围过滤 + 追问 + 统计”阶段,单字符串检索会迅速暴露语义瓶颈。

维度兼容接入现状目标能力
查询表达模糊 query 字符串结构化过滤与排序
详情承接弱,依赖临时上下文稳定 detail by id
统计分析基本不可用支持 group by / count / topN
可扩展性靠新增接口补洞沿同一 schema 平滑演进

5.2 四阶段迁移路径

  1. 保留兼容接口,保证在线服务连续。
  2. 建设 kaoqing_document_read_model,补字段字典与索引。
  3. 将主查询切换为 text2sql 或结构化 Query API。
  4. 补齐聚合统计与更细粒度投影,降低上下文与 token 成本。
迁移目标:Maturity(t) = 稳定查询 × 追问承接 × 可观测性 × 可扩展性

阐释表达

业务方关心:历史系统通常已经在线,不能为了“理想架构”一次性推翻。业务可接受的路径是先保住可用,再逐步增强查询质量,让用户感知持续变好而不是频繁波动。

工程上落地:先兼容存量 REST 保证接入速度,再补读模型和结构化查询能力,最后把主查询路径迁移到 text2sql 或 Query API。迁移过程要始终保持双轨可回退,避免单点切换带来服务风险。

上线后:能力从“模糊检索”进化到“结构化查询”后,统计分析、范围过滤、投影输出会自然解锁,后续新需求不再被单一 query 字符串卡住。

展开细节:兼容 REST 与目标读模型对照
兼容态请求:
POST /sac/kq/pdf
{
  "query": "福建"
}

目标态(结构化):
{
  "entity": "kaoqing_document",
  "filters": {"region": "浙江", "year >= 2021": true, "confirmed": true},
  "sort": ["year:desc", "updated_at:desc"],
  "limit": 20,
  "fields": ["id", "title", "year", "region", "pdf_url"]
}
目标 SQL:
SELECT id, title, year, region, pdf_url
FROM kaoqing_document_read_model
WHERE region = '浙江'
  AND year >= 2021
ORDER BY year DESC, updated_at DESC
LIMIT 20;

06. 交付模板:一次接入应沉淀哪些资产

6.1 必交付

  • 业务域说明与能力类型判定(query/operation/workflow)。
  • 读模型定义、字段字典、查询边界、输入输出 schema。
  • 典型自然语言样例与对应查询样例。
  • 联调用例、灰度指标、已知限制与回滚策略。

6.2 最低工程标准

  • 返回结构机器友好,字段命名统一。
  • 只读、安全、超时、限流、最大结果数明确。
  • 日志可定位完整链路,错误语义可解释。
业务说明 读模型设计 契约定义 联调样例 监控日志 灰度复盘 可复用的业务域接入资产包
图 3 · 单次接入的产物应可积累为长期资产

阐释表达

业务方关心:同类需求会反复出现,大家最怕“同一个坑反复踩”。如果每次接入都只留下代码不留下方法论,下一次还是要重新摸索,交付周期和风险都会反弹。

工程上落地:把业务说明、字段字典、接口契约、联调用例、灰度结论打包成标准交付物。这样后续团队拿到模板就能快速复用,不会因为人员变化导致认知断层。

上线后:模板化资产会形成组织记忆,接入效率会随着项目推进持续提高,文档不再是“补材料”,而是直接影响研发速度和稳定性的生产资料。

展开细节:接入文档建议目录
  • 业务域说明:业务目标、典型问题、结果主实体与不支持范围。
  • 底层能力:数据来源、字段字典、查询边界、错误语义、性能边界。
  • Agent 设计:路径选择、delivery role、working set 字段、follow-up 策略。
  • 联调与验收:基础用例、追问用例、边界用例、灰度样本、复盘结论。
结论等级判定条件
可接入语义、性能、安全、可观测均达标
有条件接入需补稳定 id / detail by id / 字段字典 / 日志链路
不建议接入仅模糊 query,无法承接 follow-up,结构不可验收