淘天 AI Agent开发 一面

1. 自我介绍

2. 多阶段 RAG 里同时使用 BM25 和向量召回，混合检索策略通常怎么设计

混合检索的关键不是把两路结果简单拼起来，而是根据问题类型决定两路召回各自承担什么角色。BM25 对精确术语、错误码、接口名、字段名、版本号这类关键词命中很强，向量召回则更擅长语义改写、口语化表达和抽象问题。真正稳定的设计一般是先并行召回，再做去重、融合、重排，最后再进入上下文构建阶段。

如果问题本身是“精确定位型”，比如某个报错码、类名、接口路径，BM25 权重通常更高；如果问题是“意图表达型”，比如用户用自然语言描述故障现象，向量召回的权重会更高。工程里比较常见的是先取两路 topk，再用 RRF 或学习到的融合分数合并，之后再用 cross-encoder 做精排，避免一开始就在粗召回阶段把相关证据漏掉。

3. 多阶段 RAG 中为什么不能只做一次召回，二段甚至三段检索分别在解决什么问题

一次召回的问题是，它默认用户问题已经表达得足够清楚，且语料组织方式与用户提问方式天然一致。但实际业务里往往不是这样。很多问题带有省略、歧义、跨文档依赖和隐含条件，一次召回经常只能拿到“看起来相关”的片段，而拿不到真正支撑答案的证据。

二段检索通常是在第一次粗召回后，对 query 做重写、补全或子问题拆解，再进行更有针对性的召回。三段检索则常出现在复杂流程里，比如第一段找主题文档，第二段找规则文档，第三段找异常案例或历史记录。它解决的不是“模型不够强”，而是信息搜集本身需要迭代。

4. RAG 处理 PDF 扫描件时，OCR 和版面理解为什么不能分开看

扫描件 PDF 的难点不只是把图像转成文字，更在于文字和空间结构是一体的。很多信息依赖表格格线、标题层级、页眉页脚、脚注、印章区域和字段相对位置。如果只做 OCR，不做版面理解，最后得到的是一串扁平文本，表格关系和区域归属会全部丢掉，后续检索和抽取都会变形。

所以工业里一般不会把 OCR 当成纯文本识别问题，而是联合做文本框检测、阅读顺序恢复、表格结构恢复和块级语义归类。像票据、合同、制度文件、审阅材料这类文档，如果没有 layout-aware 的处理，后面的向量化和 chunk 切分会从第一步就带偏。

5. 结合 OCR 和文档解析时，为什么很多团队会引入结构化中间层，而不是直接把全文送进向量库

直接把全文送进向量库的好处是快，但问题也很明显：检索粒度粗、字段边界模糊、证据不可控。结构化中间层的价值是把文档解析成标题树、段落块、表格单元、字段对、页码锚点和区域坐标，这样后续检索和引用都能更细粒度。尤其在需要溯源、审计和高亮回显的场景里，没有结构化中间层，后续系统几乎不可维护。

这个中间层还能承担 chunk 生成、元数据过滤和证据去重的职责。很多 RAG 项目线上效果差，不是 embedding 不行，而是文本入库前已经丢了关键结构，后面再怎么调模型都补不回来。

6. 多 Agent 系统里，State 管理和 Checkpoint 机制为什么是核心，不只是工程细节

多 Agent 一旦开始跑长流程，问题就不再是“能不能生成答案”，而是“能不能持续正确地推进状态”。如果没有显式 State，系统每一步都只能依赖当前上下文猜自己走到哪了，任务一长就容易漂移。Checkpoint 的作用则是把某个时刻的状态、执行节点、工具输入输出、失败原因和恢复位点保存下来，一旦中断或超时，可以从指定节点继续，而不是整条链路重跑。

这两者直接决定系统是否可恢复、可审计、可调试。很多看起来很会“编排”的 Agent，一旦遇到外部接口抖动、用户中途补充信息、节点失败重试，就会暴露没有状态模型的问题。

7. LangGraph 里的 Checkpoint 和 Memory 到底有什么区别

Checkpoint 更接近工作流执行快照，它保存的是某一时刻任务图的状态，用于中断恢复、回放和失败重试。Memory 更接近会话或用户级记忆，用来保存偏好、上下文摘要、长期信息或者跨会话可复用内容。前者强调恢复执行，后者强调延续认知。

这两者如果混在一起，系统会非常难治理。工作流状态应该是短期、严格可控、具备生命周期的，而长期记忆需要更强的筛选和摘要机制。把一次任务中的中间错误直接沉淀成长记忆，是很多 Agent 系统污染用户画像的根源。

8. 对话执行中出现状态竞争问题时，通常怎么解决

状态竞争一般出现在并发节点写同一个状态字段、重试逻辑覆盖旧结果、流式输出节点和工具节点同时更新共享上下文这几种场景。解决思路首先是拆分状态，把只读状态、节点私有状态和共享聚合状态分开；其次是明确写入规则，比如 append-only、last-write-wins、版本号比较或者 reducer 合并；再进一步则是为关键字段增加乐观锁或 CAS 语义。

如果状态模型设计得不好，多 Agent 系统就会出现很隐蔽的问题：日志看起来每个节点都成功了，但最后汇总结果不一致。真正线上稳定的系统，一定是先把状态读写协议定清楚，再谈 prompt 和能力。

9. 把 Choice 接口封装成 MCP 工具时，为什么参数设计和输出约束都很关键

Choice 类型工具的本质是“在有限候选里做选择”，它比自由生成更容易控，但也更容易因为 schema 设计不当出错。如果候选项语义边界不清晰、枚举项之间重叠严重，模型就会频繁犹豫或者做表面匹配。参数设计要尽量显式，把候选定义、适用条件、冲突规则和兜底项写清楚，否则模型会把分类任务做成开放式生成。

输出约束也不能只靠 prompt 说“请从以下选项里选择”，而应该从协议层限制输出格式。例如 MCP 工具的返回和调用参数都要结构化，这样下游节点才不会把一个意图分类问题变成自然语言解析问题。

choice_tool = {
    "name": "route_intent",
    "description": "根据用户问题选择处理路由",
    "parameters": {
        "type": "object",
        "properties": {
            "query": {"type": "string"},
            "candidates": {
                "type": "array",
                "items": {"type": "string"}
            }
        },
        "required": ["query", "candidates"]
    }
}

10. MCP 工具接入后，模型调用工具前后的处理流程一般是什么样的

一个成熟的调用链路一般包括请求预处理、工具选择、参数补全、调用执行、结果规范化、异常包装和回写状态。工具前处理阶段需要做权限判断、参数校验、上下文裁剪和幂等键生成，避免模型直接把脏参数打到外部系统。工具调用后，不能把原始结果不加处理地塞回模型，而应该做字段清洗、失败码映射、分页摘要和敏感信息脱敏。

如果是多轮调用场景，还要记录工具结果和后续决策之间的因果链。否则一旦答案错了，你只能看到“调用过工具”，却不知道模型是否正确使用了工具返回。

11. Agent 里单个节点的 token 预算一般怎么控制，为什么这件事比想象中更重要

token 预算本质上是在控制信息密度和系统成本。预算太松，节点会把不必要上下文全带进去，导致推理成本、时延和噪声都上升；预算太紧，关键证据被裁掉，模型就开始凭先验猜。一个成熟系统通常会给不同节点不同预算，比如规划节点需要更高抽象信息，执行节点更需要精确结构化输入，审查节点只需要摘要和关键证据。

真正困难的地方在于预算不是固定数字，而要和节点角色、上下文来源、历史长度以及模型窗口动态联动。很多长链 Agent 后面越来越不稳定，本质上不是模型忘了，而是上下文装配没有做预算管理。

12. 如果子任务失败，比如数据获取为空，整个工作流应该怎么设计恢复逻辑

不能简单把“空结果”当成“任务失败”，要先区分是真的没数据、参数错了、权限不足、接口超时，还是检索粒度不对。恢复逻辑通常要和失败类型绑定：参数型错误适合重试并修正输入，权限型错误要转人工或走兜底说明，检索型错误适合改写 query 或扩大范围，真正无数据则应该尽早终止，避免后续节点在空上下文上继续胡乱生成。

比较稳的工作流设计会把失败状态编码进图里，而不是一概抛异常。这样每条失败路径都有明确流向，系统才不会在错误状态下继续“硬跑”。

13. FastAPI + SSE 做流式输出时，后端通常怎么把多节点执行结果实时推给前端

核心思路是把内部执行事件抽象成统一的 event stream，再由 SSE 按序推送。每个节点开始执行、调用工具、返回部分结果、失败重试、状态完成，都可以映射成结构化事件。这样前端不需要理解内部图结构，只需要根据事件类型决定显示进度、步骤、引用、部分答案或错误提示。

真正要做稳，还得处理断流重连、事件去重和最终一致性。否则前端看到的会是“中间消息有了，最终结果没了”或者“断线重连后重复显示一遍”。所以生产环境的流式输出一般会带 event_id、cursor 或 checkpoint token，确保可恢复。

from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import json, tim