字节 AI 应用面试 12 问：RAG、Agent 与项目评测

在大模型应用中，AI Agent（智能体）是以模型为决策核心，围绕任务目标调用工具，并依据执行反馈持续调整行动的软件系统。 核心能力包括目标理解、行动规划、工具使用和反馈调整。

从基本运行过程看，可以用四部分来理解：

Agent = 模型 + 工具集 + 运行循环 + 当前状态

• 模型（Model）：理解目标，结合当前信息选择工具和下一步行动。
• 工具集（Tools）：执行外部操作，例如检索文档、查询数据库或调用业务接口；实际执行由应用程序完成。
• 运行循环（Loop）：组织模型决策、工具执行和结果反馈，持续推进任务，并在任务完成或达到执行限制时停止。
• 当前状态（State）：保存任务目标、对话、工具结果和中间进展，为后续决策提供依据。

例如比较北京和上海的实时温度，模型选择天气工具，应用执行查询并记录结果，运行循环再把结果交回模型进行比较；若缺少其中一地的数据，可根据反馈决定是否补查。

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

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

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

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

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

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

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

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

LangChain 侧重用组件和高层 Agent 架构构建应用，LangGraph 侧重显式控制有状态流程的执行。 两者可以一起使用，不能简单理解为“LangChain 只能顺序执行，LangGraph 才能做 Agent”。

• LangChain 提供模型、消息、工具和检索等集成，以及可通过中间件定制的 Agent 封装，适合快速连接模型与业务能力、构建常见工具调用 Agent。
• LangGraph 是较底层的编排框架与运行时。开发者定义状态、节点及流转规则，组织分支、循环、并行和暂停恢复，适合需要精细控制执行路径与状态生命周期的任务。
• 当前 LangChain 的 Agent 建立在 LangGraph 之上，也能使用持久化、流式输出和人工介入等能力；直接写 LangGraph，主要是为了进一步掌控流程结构，而不是获得前者完全没有的功能。

例如普通知识问答，可以先用模型、检索器和提示词组成清楚的处理流程；标准工具调用助手，可以从 LangChain Agent 开始。若问数系统要显式安排检索、SQL 生成、校验、有限纠错和人工处理分支，直接用 LangGraph 更容易表达这些控制规则，节点里仍可复用 LangChain 组件。

Agent 中的 Harness 是围绕模型搭建的执行系统，负责把模型的判断转成实际操作，再把操作结果反馈给模型。模型主要负责理解任务、推理和选择动作；Harness 负责提供上下文、执行工具、维护状态，并落实权限、预算和验证规则。

可以从四项职责理解它：

1. 准备上下文：组织任务要求、历史消息和相关资料，控制每次调用给模型看什么。
2. 执行动作：提供工具和运行环境，校验调用参数与权限，执行后返回真实结果或错误。
3. 管理过程：维护任务状态，限制循环次数、时间和成本，并按任务需要保存恢复点。
4. 验证与反馈：通过测试、业务规则和执行日志判断结果是否达标，失败时让模型修正或转人工处理。

例如查询两座城市的天气，模型可以决定调用哪个工具、传什么城市；真正发起查询、处理超时、回传温度和检查结果是否齐全的，是 Harness。它的作用是让 Agent 能持续、可控地完成任务，而不只是生成一段看起来合理的回答。

深度研搜（Python）

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

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

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

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

Agent Loop 是围绕当前任务状态反复进行决策、执行和反馈的控制过程。每一轮都把任务要求与已有结果交给模型，由模型决定下一步；运行系统执行合法的工具调用，把真实结果写回状态，再判断继续、等待输入还是结束。

一轮通常包括五步：

1. 构建输入：组织任务目标、当前进度、历史消息、相关资料和可用工具。
2. 模型决策：生成工具调用请求、直接回答，或提出需要用户补充的问题。
3. 执行动作：检查工具是否存在、参数和权限是否符合要求，再调用工具。
4. 更新状态：把调用与结果关联起来，记录新事实、进度、错误和资源消耗。
5. 判断下一步：目标未完成则进入下一轮；需要信息或审批则暂停；满足完成条件或触发停止条件时结束。

例如查询某类商品及库存，第一轮先搜索商品，拿到商品 ID 后，下一轮才能查询对应库存，最后结合两次结果回答。循环的作用就在于让下一步依赖前一步的实际反馈，而不是一次性猜出整条路径。

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

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

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

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

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

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

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

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

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

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

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

大模型幻觉是生成了事实错误、缺乏依据或与给定材料冲突的内容。治理要把事实依据和执行结果接入回答过程，再验证关键结论。 可以按四步处理：

1. 识别并定位：把答案中的关键事实、数字、引用和“已完成”的动作分别拿出来，与原文、业务数据和工具真实返回核对，区分资料缺失、检索错误、上下文丢失与生成偏离。
2. 提供可靠依据：知识问答检索有来源、版本和适用范围的材料；实时数据通过工具查询，保留原始返回。检索相关不等于证据充分，还要检查是否覆盖问题中的条件。
3. 约束生成：要求围绕证据回答、给出对应出处；缺少依据时补问、补查或明确无法判断。结构化输出可以限制字段和格式，但不能单独保证字段里的事实正确。
4. 验证并回归：用规则或业务系统校验编号、计算和操作状态，对关键结论检查引用是否真正支持。把失败样本加入评测集，同时观察错误率、有效回答率、延迟和成本。

例如，报销问答引用了旧版制度，即使回答与旧文档完全一致，也可能不适用于当前员工。应先修正文档版本和检索条件，再验证生成结果；只修改“不要编造”的提示词，解决不了错误依据的问题。

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

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

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