小厂 Agent 开发一面：Text-to-SQL、RAG 与 Agent 范式

《面试题目》

1. 请做一下自我介绍。
2. 企业问数平台的项目场景和数据规模是什么？
3. 问数平台的意图识别是怎么设计的？
4. 怎么保证模型输出 SQL 的正确性？
5. 夏都探源项目的 Agent 链路代码架构是怎么实现的？
6. 夏都探源的意图识别怎么设计？
7. 意图识别使用模型会不会导致耗时过长？
8. 简单说一下 RAG 系统。
9. 分块的重叠值怎么设置？
10. 长文档怎么处理？
11. 大表格被分到不同 chunk 怎么处理？
12. 记忆压缩策略有哪些？
13. 了解过自查询（self-query）吗？
14. 说一下常见的 Agent 范式。
15. 了解多 Agent 吗？
16. 说一下 A2A 协议。
17. 了解过 Hermes 吗？
18. 反问环节。

《参考解析》

Text-to-SQL 的正确性要靠“约束 + 校验 + 可恢复”三层。 首先做 schema linking，把表、字段、指标口径和 few-shot 示例放进向量库，按用户问题召回相关上下文，避免把整库 schema 塞给模型。生成后先做权限过滤，用户没有权限的表直接拒绝并让模型重新生成；再做语法校验和有限次修复，只修语法、不改业务意图，同时设最大重试次数防止死循环。执行结果还要做合理性检查，比如行数、空值、指标量级是否异常。对于时间、区域、指标口径缺失的问题，先用三元组判断缺哪一项，向用户追问一次；追问后仍不完整就不再查，避免模型猜口径。

RAG 的难点在入库和检索，不在“接一个向量库”。 离线侧要清洗文档、识别扫描件和图表，按文档结构选择分块策略：结构化文档按标题层级切，长文用父子分块，问答材料按 QA 对切，图表则把图注、表头和上下文一起转成可检索文本。分块之间保留 10%—15% 的重叠，具体比例要看 chunk 的 token 大小和语义密度，重叠太多会引入重复召回，太少会切断跨段语义。在线侧用向量、关键词、图谱多路召回，RRF 融合后再用 cross-encoder 精排；长文档靠父子块先把子块召回、再补父块上下文，大表格则按行或列拆成带表头的小块，检索时把表头一起带上，最后用确定性代码校验汇总结果。

Agent 范式要能说出适用边界。 ReAct 是边想边做，适合步骤不多、需要工具反馈的任务；Plan-and-Execute 先规划再执行，适合复杂多步任务，但计划错了会放大错误；Reflection 是在输出后加一层审查，适合对质量敏感、可以接受额外延迟的场景。多 Agent 不是越多越好，只有当任务能按角色或子目标清晰拆开、且通信成本可控时才值得用；A2A 是一套 Agent 之间发现能力、交换任务和结果的互操作协议，Hermes 则是另一类面向工具调用和结构化输出的模型/框架方向。没学过的部分坦诚说没接触，比硬编概念好。

意图识别的耗时要用数据说话。 规则前置可以挡住高频、明确的请求，小模型负责灰区分类，规则再做兜底；把路由和业务工作流拆开，路由只输出类别和置信度，复杂处理交给下游子图。优化手段包括缓存高频问题的路由结果、并行调用、给模型设超时和降级路径，以及用全链路追踪看每个节点的耗时。面试官问“用模型会不会慢”，其实是在看你有没有工程意识：能不能定位瓶颈、能不能在准确率和延迟之间做取舍。