阿里 AI 应用面试，RAG 和 Agent 会被怎样追问？

RAG（检索增强生成）通过检索外部知识，为大模型提供相关上下文，辅助生成有依据的回答。 以向量检索为例，完整流程分为两个阶段：

1. 索引阶段（离线）：加载、清洗文档，切分为适合检索的片段，通过 Embedding 模型进行向量化，建立索引，并关联保存片段原文、来源等元数据。
2. 检索生成阶段（在线）：将用户问题向量化，检索 Top-K 相关片段，按需过滤和重排，再将片段原文、原始问题和回答要求组织成 Prompt，由大模型生成答案。

例如，员工问“出差怎么报销”，系统先检索报销流程、凭证要求等制度条款，再据此组织回答。向量用于查找资料，片段原文才是模型生成答案的主要依据。

评估时，需要分别检查检索的相关性与覆盖度，以及答案的正确性和忠实性。其中，忠实性关注结论是否得到所用资料支持。资料不足时说明缺口，知识发生变化后同步更新索引及关联内容。

RAG 文档切分要在“检索能定位”和“片段足以回答”之间取舍。 常见策略有四类：

1. 固定长度切分：按字符数或 Token 数分块，适合快速建立基线。
2. 递归切分：优先按段落、句子等边界切分，超长部分再继续细分。
3. 结构化切分：依据标题、条款、函数或表格等文档结构组织片段。
4. 语义切分：根据相邻内容的语义变化确定边界，同时限制块的最小和最大长度。

确定块大小时，先明确长度单位与 Embedding 输入上限，再看问题需要多大的证据单元。块太小，容易拆开前提和结论；块太大，会混入多个主题，增加检索噪声与生成成本。通常先保留自然边界，超长部分递归细分，再用同一批业务问题比较块大小和重叠量，检查证据召回、答案质量、延迟与成本。

例如运维手册中的适用版本、触发条件和恢复步骤应能一起取回。需要“小块定位、大段阅读”时，可以用父子块，把写入索引的子块与交给模型阅读的父段落分开。

RAG 评估应覆盖检索质量、生成质量和端到端效果。先建立有代表性的评估集，明确每题的答案要点和原文依据，并固定知识库、配置和评分规则，再分三层评价：

• 检索层：评估证据的相关性、覆盖度和排序，分别保存候选结果和最终上下文。
• 生成层：对照答案要点评估正确性与完整性，检查结论是否得到上下文支持（忠实性），以及引用是否准确。
• 端到端：评估任务完成情况、延迟与成本，固定样本和评分规则比较优化前后。

例如问“出差住宿能报多少、需要什么凭证”，只找到限额而没找到凭证要求，属于证据覆盖不足；两项规定都进入上下文，答案却漏掉一项，则属于生成遗漏。分层评估有助于定位具体问题，并判断改动改善了哪个环节。

Agent Skill 是把一类任务的执行方法整理成可复用的技能包，通常包括任务说明、操作步骤和输出要求，还可以附带脚本、参考资料与模板。Agent 在遇到相关任务时加载这些内容，再使用已有工具完成工作。

以常见的 Agent Skills 格式为例，技能目录的入口是 SKILL.md：元信息描述名称和适用场景，正文说明怎样执行。系统可以先提供少量元信息，匹配任务后加载正文，需要时再读取资源或运行脚本。这种按需展开的方式，让一套较完整的工作方法可以复用，同时减少每次都塞入全部资料的开销。

例如“面试题答案编写”Skill 可以规定怎样查证资料、组织核心回答、处理图示和检查来源；真正的检索、读文件和生成内容，由 Agent 结合工具执行。

以企业研搜助手为参考示例，项目把业务工具按公开搜索、内部数据、内部文档和文件交付分组，由三个业务专家和主 Agent 分别使用。

• 网络搜索工具交给网络专家：输入搜索问题和检索参数，调用 Tavily，返回包含标题、链接和内容等字段的搜索结果，用来补充公开资料。
• 数据库工具交给数据库专家：先获取表名，再查看列名与样例数据，最后输入 SQL 执行查询，返回带列头的数据文本，用来回答库存、销售等具体业务问题。
• 知识库工具交给 RAGFlow 专家：先列出可用助手及知识库信息，再输入助手名称和问题，返回内部文档问答结果。
• 文件工具由主 Agent 使用：读取上传材料，把整理好的内容写成 Markdown，再按需要转换成 PDF，完成用户要求的文件交付。

框架还提供 task 委派和 write_todos 计划管理：前者把子任务交给专家，后者记录计划状态。它们属于通用编排能力；搜索、查库和生成报告等业务能力则由项目工具接入。

深度研搜（Python）

下面以一个整合公开资料、企业数据库和内部知识库的研搜助手为参考示例。

项目采用主从式多 Agent：一个主智能体统一面对用户，配置三个自定义业务专家子智能体，按信息来源分工。后端使用 Python 和 FastAPI，DeepAgents 负责主从调度，底层由 LangGraph 承接执行状态；大模型负责理解问题、选择调用和整理结果，Tavily、MySQL、RAGFlow 分别提供真实信息。

• 主智能体：理解目标、拆分任务、选择专家，拿到结果后判断是否还缺信息，最后汇总回答。读取上传文件、生成 Markdown 和转换 PDF 由它调用文件工具完成。
• 网络搜索子智能体：通过 Tavily 搜索公开网页，补充最新公开信息。
• 数据库查询子智能体：先确认表和字段，再生成、执行 SQL，获取结构化业务数据。
• RAGFlow 子智能体：选择合适的知识库助手，查询企业内部的非结构化文档。

例如新能源团队研究某类电池的技术路线与量产进展，主智能体把政策和竞品公告查询交给网络助手，把相关业务统计交给数据库助手，把内部产品资料查询交给 RAGFlow 助手；结果回来后统一解释，再按要求生成文件。拆开的主要原因是三类数据源的工具、查询步骤和上下文不同，能把各领域的细节留在子任务里；代价是多了调度、信息交接和模型调用开销。若需求只有单一知识库问答，一个 Agent 配检索工具通常就足够。

我主要看下一步有多依赖新观察、任务是否需要显式维护全局计划，以及延迟和费用预算来选择。

• ReAct 把推理、行动和观察交替起来：根据当前信息选择工具，执行后读反馈，再决定下一步。它适合搜索、排障这类路径难以预先确定的任务，优点是能及时适应新信息；代价是多轮模型与工具往返，长任务也容易重复探索或遗漏整体目标。
• Plan and Execute 先生成可检查的多步骤计划，再由执行器完成子任务，并根据结果判断继续、结束或重规划。它适合目标能拆解、依赖关系较清楚、需要跟踪多项交付的长任务；代价是规划与计划维护本身有开销，初始假设错误时也需要及时调整。

两者可以组合：例如产业调研先规划研究维度和报告交付项，每个维度内部用 ReAct 搜索、读取和补查，再根据执行结果更新计划。显式规划有助于管理全局目标，但不会自动保证更正确、更快或更便宜。如果步骤已经固定，用普通工作流就能完成，也不一定需要再让模型规划。

Function Calling 是模型根据用户问题和工具定义，生成工具名称及结构化参数，再由应用执行工具、把结果交回模型的过程。完整流程可以分成五步：提供工具定义、模型生成调用、应用校验并执行、按调用标识回填结果、模型继续判断或回答。

例如用户问北京天气，应用把天气工具的用途和城市参数说明发给模型。模型提出查询北京的调用，应用实际请求天气服务，再把查询结果关联到这次调用交回模型，模型才据此组织回答。工具定义不代表函数已经执行；一次任务也可能不调用工具，或者连续调用多轮。

可靠的工具调用需要把工具定义、参数校验、受控执行和结果反馈连成闭环。模型根据上下文提出调用，应用负责验证、执行，并把真实结果交回模型。

1. 定义清楚：说明工具用途、适用条件、输入字段和返回内容，让模型知道何时该用、需要提供什么。
2. 校验参数：既检查类型、必填项等结构，也核对对象、时间和参数来源。凭证、用户身份和权限范围由应用提供与检查。
3. 受控执行：只调用允许的工具，设置超时与调用上限，按原因决定补问、有限重试或停止。下单等写操作超时后，要先确认执行状态，或使用服务端支持的幂等机制，避免重复操作。
4. 反馈并确认结果：成功返回真实数据，失败返回具体原因和可修正的信息，再检查结果是否满足任务。参数生成成功、HTTP 返回成功，都不等于任务完成。

例如用户问“这里明天会下雨吗”，系统却只有即时天气工具，就要先澄清城市，并说明当前工具不提供明天预报；即使生成了合法的北京参数，也还没有回答用户的问题。

控制上下文要区分完整历史的存储和本轮模型的输入。历史保存在 Redis 或检查点里，不代表模型会自动读到；本轮不发送旧消息，也不必删除原始记录。调用前应统计指令、工具定义、历史和工具结果的 token 占用，按模型窗口预留输出空间，在超限前处理长输入。

再按信息的后续用途选择策略：

• 保留原文：近期讨论、最新更正，以及需要精确引用的内容。
• 直接裁剪：已经结束、与当前任务无关的过程。
• 抽取或摘要：把当前目标、仍生效的约束、已确认进度和待核验事项整理成简短状态。
• 外置并按需取回：长网页、报告和旧材料放在外部存储，需要时再读取相关原文。

例如报告范围从“上半年”改成“第二季度”，摘要要保留新范围和原有的来源要求。取舍是否合理，要用多轮任务检查约束、更正和关键事实有没有丢；质量达标后，再比较 token、耗时与成本。

下面用一个 32,000 token 的预算例子，把“保留、裁剪、摘要、外置”四种处理方式放在一起比较。报告范围发生更正时，也要把新约束带入下一轮。

Agent 的分层记忆，应按信息服务什么范围、保留多久、何时读写来设计，再从存储中选出本轮模型需要的内容。一种实用组织方式是：

1. 近期对话：保留当前会话最近的原始消息，延续指代、追问和用户更正；较早过程可以摘要或按需回查。
2. 当前任务状态与摘要：明确保存目标、约束、已确认参数、进度和待办，避免模型每轮从聊天中重新猜测。关键事实用结构化字段，摘要补充经过与背景。它与近期对话都服务当前任务，通常属于短期信息。
3. 跨会话长期记忆：保存后续仍有用的偏好、项目事实、历史决策和经过验证的经验，按用户、组织和项目限定作用域，需要时再检索。

这不是统一的“三层标准”，也不要求三套数据库。重点是把保存的信息与本轮上下文分开：Redis 或检查点负责保存，读取、筛选和注入才让模型实际用到。写入前判断价值与依据，读取时检查权限、有效期和相关性，并控制预算；发生更正、过期或删除时同步维护。

例如长期默认是“华北、按周”，本次用户要求“华南、按月”，当前任务采用新参数，长期默认暂时不变；只有用户明确改变默认，才更新相应的长期条目。

Agent 评估要先定义任务在什么条件下算完成，再同时衡量结果质量、执行过程和运行代价。回答流畅、工具返回成功，都不能直接代替任务成功。

1. 建立有代表性的任务集：固定输入、初始状态、权限和验收条件，覆盖正常任务、信息不足、工具异常与高风险边界，并留出不参与调参的测试集。
2. 按任务选择评分器：问答检查事实、完整性和依据；建单检查实际记录、关键字段和重复单；代码修改检查需求用例、原有功能与修改范围。能用规则或执行结果验证的优先自动检查，开放式质量由明确量表的模型裁判辅助，并用人工样本校准。
3. 统计成功与稳定性：报告固定预算内的任务成功率，区分一次通过、重试后通过和人工接管；同一任务重复运行，按场景看波动，不能用挑出的最好结果代表日常表现。
4. 同时比较代价：记录端到端耗时、费用、工具错误和人工介入。用相同任务与评分规则比较新旧版本，再通过线上抽样验证实际表现。

例如建单任务，成功应是“正确客户下创建了字段齐全且无重复的订单”，而不只是最后回复“已建单”。如果身份或必填信息缺失，正确行为可能是先澄清，而非强行创建。