腾讯大模型应用岗：真实面试题与口述答案

这组题按用户提供的腾讯面经截图整理，编号 T01 至 T26 对应截图顺序；它不是腾讯官方题库。RAG 是 Retrieval-Augmented Generation，即检索增强生成：先找外部证据，再据此回答。答案是可以直接说出口的技术口径，涉及个人项目时必须替换成自己确实做过、能展示证据的经历。原理可继续复习 RAG、Agent 生产化、评测体系 和 Aladdin 项目手册。

一面：项目、框架与运行状态

T01. 完整讲一遍你的 RAG/Agent 项目流程参考答案

我的 Aladdin 项目解决的是一个任务由哪些 Agent 来做、按什么顺序做，以及失败后怎样继续。用户提交需求后，简单任务直接匹配，复杂任务先由模型提出任务节点和依赖关系。模型只负责提出方案，代码还会检查依赖是否有环、节点输入输出是否匹配，不能把模型生成的计划直接当成可执行流程。

匹配时先排除不满足业务条件的 Agent，再把任务描述和 Agent 能力描述转成向量，用 pgvector 召回语义接近的候选。用户确认方案和报价后，执行系统按依赖派发任务，下游使用上游已验收的结果，最后按验收状态推进结算。比如生成网站时，设计结果是 Coding 的输入，不能两个节点各做各的。业务状态保存在数据库，重复请求用幂等键识别，失败区分可重试、需重新分配和需人工处理。

这里需要区分两件事：我的向量检索主要用于找合适的 Agent；典型知识库 RAG 则是先从文档里找证据，再把证据交给模型生成带引用的答案。两者都用检索，但检索对象和最终目标不同，不能把用了向量库就等同于做了知识库问答。

T02. 为什么用 LangGraph？与 LangChain 怎样比较？了解腾讯自研 Agent 框架吗？参考答案

我选 LangGraph，主要是需要把执行状态、分支和恢复点明确下来，不是因为它能调用更聪明的模型。LangChain 提供模型、工具和 Agent 等常用组件；LangGraph 更偏底层的有状态编排，可以定义节点、条件边和循环。两者可以配合使用，并不是必须二选一。

在 Aladdin 中，规划器用 StateGraph 组织生成方案、检查结构和必要时修正；Coding Agent 则把 TSX 和 CSS 的生成、校验拆开，用 PostgreSQL checkpointer 保存执行进度。比如 TSX 已经通过校验，生成 CSS 时中断，恢复后可以继续处理 CSS，不必把已完成部分全部重做。代价是要自己设计状态结构、恢复入口和版本兼容，简单的一次模型调用没必要上这种编排。

Checkpoint 保存的是图的运行状态，不代表外部操作天然只执行一次。恢复时可能重新执行某段逻辑，所以写数据库、发消息或结算仍要有业务幂等；平台的任务和资金状态也不由 LangGraph 代管。腾讯自研框架如果没有实际使用经验，我不会把公开信息说成亲身实践；我会重点比较状态恢复、工具权限、观测和迁移成本。

T03. Agent 死循环怎样熔断？海量并发下不能只靠内存怎么办？参考答案

我会给每次运行设置步数、总时长和费用预算三道硬上限，再判断是否真的有进展。比如 Agent 连续用相同参数查同一个接口，结果也没有变化，就不应该继续消耗 Token；可以让它换一次策略，仍无进展就停止并记录原因。一次任务陷入循环是终止该任务，下游服务持续失败则是对服务熔断，二者不能混为一谈。

多实例下，这些限制必须由共享状态约束。任务入队后，Worker 限时领取执行权，也就是租约；领取、预算预占和状态推进用原子操作或带版本条件的更新，避免两个 Worker 同时认为还有额度。模型调用前按本次最大消耗预留预算，返回后再核算，不能等账单超了才发现。

如果 Worker 崩溃，租约到期后可以重新领取，但旧 Worker 恢复后也可能继续返回结果。因此更新结果时还要校验当前执行版本，拒绝过期执行者写回。外部写操作使用稳定的幂等键，无法安全自动恢复的任务转人工。这样重启、重复投递和循环失控都有明确处理路径，不只依靠进程里的计数器。

T04. 工具失败、模型返回非法 JSON 怎么处理？分布式会话状态放哪里？参考答案

先判断失败原因和操作有没有可能已经生效，再决定能不能重试。限流、暂时性网络故障可以退避重试，也就是隔一段时间再试，并设置总次数和总时限；参数、权限或业务规则错误，重复提交通常没有意义，应修正参数或直接终止。

尤其是写操作超时，只能说明没收到结果，不能说明没执行成功。例如创建订单接口超时，我会用同一个幂等键查询或重试，不能换一个请求 ID 再创建。模型返回 JSON 时则依次检查能否解析、字段类型是否满足 Schema、字段之间是否满足业务规则；金额是数字也可能是负数，格式合法不等于业务合法。校验失败可把具体错误反馈给模型有限修复，仍失败就显式报错，不猜测字段含义后写库。

会话消息、任务进度和工具结果按租户、会话及运行 ID 落数据库，Redis 用于缓存和临时协调。多实例更新同一运行时要检查状态版本，防止旧请求覆盖新进度。日志同时记录错误类别和本次执行位置，恢复时才能知道该重做哪一步，而不是整条链路盲目重跑。

一面：RAG 的检索、重排与生成

T05. 长文档和十万字以上资料怎样分块？参考答案

我会先按文档结构切，再根据检索效果调块大小，目标是让一个片段足够独立地说明一件事，同时保留回到上下文的能力。先解析章节、段落、表格和页码，再把较长章节拆成子块，保存所属父章节、文档版本和原始位置。

比如报销制度里，金额上限在表格，适用对象在小标题，例外条件在下一段。如果只按字数切开，模型可能找到金额，却答错适用人群。我会把标题、表头和必要条件带进子块；检索命中后，再回取父块或相邻段落补足语境。重叠只解决边界附近信息被切断的问题，不能代替结构解析。

十万字资料通过异步任务分批解析和建索引，不一次塞给模型。块太小容易丢语境，太大则会稀释相关信息、增加上下文费用，所以没有一个通用最佳字数。我会用真实问题比较正确证据是否被找回、最终答案是否准确以及延迟和 Token 消耗。具体分块策略可复习 RAG 笔记。

T06. BM25 加向量混合检索，结果如何融合打分？参考答案

我会让 BM25 和向量检索各取一批候选，再去重融合。BM25 更擅长精确词、型号和编号，向量检索更擅长同义表达。比如搜索某个错误码，关键词很重要；问某个功能怎样退款，语义检索更容易找到标题叫售后规则的文档。

两路分数的含义和范围不同，不能直接相加。我通常先用 RRF（Reciprocal Rank Fusion，倒数排名融合）：每个文档的融合分数是它在各路结果中的 1 / (k + 排名) 之和，其中小写 k 是控制排名影响程度的常数，不是取前多少条的 K。某篇文档在两路都靠前，就能得到更高分；只出现在一路，则只累计那一路的分数。

RRF 简单、对分数尺度不敏感，但它只看名次，忽略了原始分数差距。对精度要求高时，融合后再用 Reranker 细排；也可以在有验证数据时做分数归一化和加权。最终要同时看正确证据的 Recall@K、答案质量和延迟，不能只看某一路检索分数变高了。

T07. Rerank 原理是什么？线上服务很慢怎样优化？参考答案

向量召回先快速找出可能相关的文档，Rerank 再仔细比较问题和这些文档是否真的匹配。常见的 Embedding 检索分别把问题、文档编码成向量，文档向量可以提前算好；常见的交叉编码器 Reranker 则把问题和一个候选片段一起输入模型，直接判断这对文本的相关性，因此更能分辨否定、条件和细节，但每次查询都要重新计算这些组合。

例如用户问免费版是否支持导出，两篇候选都提到了导出，一篇说企业版支持，另一篇说免费版不支持。粗召回可能都排得很高，重排需要识别哪一篇真正回答了免费版这个条件。不过 Rerank 只能重排已有候选，召回阶段没找到正确文档，它也救不回来。

优化时先拆出排队、网络和推理耗时，再减少无关候选、裁剪冗余内容、使用轻量模型或批量推理。候选数和文本长度减少后要回测，不能把正确证据一起删掉。最后给重排设延迟预算，超时回退到融合检索排序，同时观察 P95，也就是 95% 请求耗时不超过的值，避免少量慢请求拖垮用户体验。

T08. 召回正确但大模型答错，原因和解决方案是什么？参考答案

召回命中只证明证据进入过候选集，不证明它最终进入了模型上下文，更不证明答案使用了它。我会拿一条失败请求，沿着召回结果、重排结果、最终上下文和回答逐段检查。

如果正确片段被重排降下去或被长度限制截掉，应该调整检索和上下文选择；如果证据进了上下文但缺少例外条件，要补充相邻片段或改分块；如果完整证据在场，模型仍然忽略它，则检查提示约束、冲突资料和推理能力。比如文档写的是试用期不支持退款，模型只抓住另一段支持退款，就不是简单提高召回率能解决的。

我还会做一个对照：只给模型经过确认的正确证据，看它能不能答对。这样可以区分是上下文噪声还是生成环节的问题。回答要关联到实际支持结论的引用，证据不足就说明无法确定；有引用不等于结论正确，还要校验引用内容是否真的支持答案。

T09. Lost-in-the-Middle 怎样解决？参考答案

Lost-in-the-Middle 指的是：即使相关证据已经放进上下文，模型也可能更容易利用开头或结尾的信息，忽视中间的信息。这不是超过窗口导致的截断，两者排查方法不同；表现也会受模型、问题和文档长度影响。

我的第一步不是单纯把窗口调大，而是删掉重复和无关片段，让关键证据更集中。再根据问题把最相关证据和必要限定条件组织在一起，放在更容易被关注的位置。如果确实需要跨很多章节推理，就先从各章节抽出带出处的事实，再汇总，避免直接把几十页材料扔给模型。中间摘要仍要保留来源，否则压缩本身可能丢信息。

验证时保持问题和证据不变，只移动证据到开头、中间、结尾，比较答案正确率和引用准确率。如果位置一换结果就明显变化，才有理由针对这个问题优化。调整顺序只能缓解风险，不能保证所有模型都不再漏读中间内容。

一面工程题：并发、成本与安全

T10. 上线十万用户后，会话状态能存在内存吗？放哪里，各有什么取舍？参考答案

会话状态不能只放单机内存，因为扩容后下一次请求可能落到另一台机器，重启也会丢记录。不过十万注册用户不等于十万并发请求，容量设计还要看同时在线数、请求频率、会话长度和数据保留时间。

我会把消息、任务状态和必要的工具结果放数据库；Redis 缓存最近上下文、热点数据和短期限流计数；大附件、长原文放对象存储，数据库只保存引用。内存可以做本地加速，但丢失后必须能重建。数据库适合长期记录和事务，代价是读写开销；Redis 延迟低，但有内存成本、过期和淘汰问题；对象存储适合大文件，不适合频繁逐条更新会话。

存到共享库还不够，还要解决同一会话并发写入的问题。我会给消息排序、给状态更新加版本条件，避免两个请求互相覆盖；缓存键包含租户和会话身份。某轮模型请求只加载必要上下文，不把全部历史每次读出来送给模型。这样既能跨实例恢复，也能控制读写和推理成本。

T11. SSE 与普通 HTTP 有何区别？用户断开后，后端还要调用模型吗？参考答案

SSE 是 Server-Sent Events，即服务端事件推送。SSE 本身就是 HTTP，只是响应按事件持续发送，而不是等所有内容完成后一次返回。服务端使用事件流格式，适合单向推送生成内容和任务进度；HTTP 也可以做其他形式的流式响应，所以不是只有 SSE 才能流式传输。SSE 也不会让模型生成得更快，它主要让用户更早看到结果。

断开后是否继续，要看任务是否已经独立受理。即时聊天如果没有继续生成的价值，我会把取消信号传给模型调用并释放连接；已经受理的报告生成、代码执行等后台任务，则继续运行和保存结果，页面按任务 ID 查询或重新订阅。关闭网页不应直接等同于取消业务任务，更不能撤销已经成功的写操作。

重连也不等于自动恢复 Token。要支持补发，服务端需要保存事件及序号，客户端带上最后收到的位置，服务端据此补发并让客户端去重；仅仅重新建立 SSE 连接，并不能让模型从上次字符位置继续生成。如果没有事件回放能力，就返回已保存的任务状态和结果，明确告知流已经中断。

T12. 大量用户访问，Token 成本飙升怎样控制？参考答案

我首先看完成一个有效任务总共花多少钱，而不只看一次模型调用的单价。一个便宜模型如果总答错、反复重试，可能比强模型直接做对更贵。先把费用拆到模型、输入输出 Token、调用次数和任务类型，找出是长历史、重复请求、多 Agent 协作还是失败重试在消耗。

针对不同来源分别处理：简单任务走轻量模型，长历史按需压缩，检索只传相关证据，同一文档重复处理复用结果；限制输出长度、循环步数和重试次数，并给租户和单任务设置预算。缓存也有边界，个人化答案必须隔离权限，知识更新后要失效，不能为了省钱把别人的结果返回给当前用户。

例如固定格式提取可以先用低成本模型并做 Schema 校验，失败再升级；需要复杂推理或高风险判断时则不一味降级。用同一批任务比较调整前后的正确率、延迟和总费用，再逐步上线，才能知道省掉的是浪费还是质量。

T13. 几十轮长对话全部送模型太贵，怎样优化？参考答案

我会把完整聊天记录和本轮真正需要的上下文分开。完整记录持久化保存，本轮只装入系统约束、最近几轮原文、当前任务状态，以及与当前问题相关的旧信息。这样不是简单删历史，而是减少每次重复发送的内容。

具体做法是：近期对话保留原文，早期对话生成可更新摘要，明确偏好和已确认事实单独记录，必要时检索原始片段。比如用户第一轮说预算不超过一万元，二十轮后改成八千元，当前状态应以新预算为准，并能追溯修改来源，不能把两个数一起当有效约束。

摘要也可能遗漏或编造，所以它不能成为唯一记录。关键数字、授权和业务结果尽量从结构化状态或原文读取，不能靠模型记忆猜。测试时会专门放入早期约束、后续修正和隔很多轮再提问的用例，检查压缩后还能不能答对。

T14. 向量库高并发会遇到什么问题？参考答案

我会先区分是查询本身慢，还是请求排队慢。并发高时，即使单次近邻搜索很快，也可能卡在连接池、CPU、内存带宽或远程网络；同时大量写入还会带来索引维护压力。需要把排队时间、实际查询耗时、数据规模和过滤条件一起看。

另一个容易忽略的问题是过滤后的召回。例如用户只能查某个租户的文档，近似索引找到的邻居如果大部分都不属于该租户，过滤后就可能凑不够候选。这时要结合检索引擎能力调整搜索范围、分区或检索计划；数据很少的租户也可能直接精确扫描更合适。权限过滤不能为了速度省掉。

优化顺序是先修查询和连接池配置，再调索引与搜索参数、批量写入和资源隔离，最后根据真实规模考虑副本或分片。近似搜索更快往往伴随召回取舍，所以压测不能只报 QPS（每秒查询数），还要同时看 P95 和相同过滤条件下的 Recall@K，否则可能只是更快地返回了不完整结果。

T15. 多模态 RAG 中的图片和表格怎样处理？参考答案

多模态 RAG 的关键不是把所有内容变成文字，而是保留文字、图片、表格之间的关系。入库时先做版面解析，保留页码、章节、图注和原始对象引用；图片可以生成便于检索的描述，但原图也要保留，必要时让视觉模型查看原图。

表格尤其不能只拼成一长串文字。例如某行销售额是 120，必须一起保留年份、产品、币种，以及表头里的单位是元还是万元；合并单元格和脚注也可能改变含义。我会将表格保存为有行列关系的数据，再生成带表头的检索片段，回答时能回到原表核对。

涉及汇总和增长率时，用程序对结构化数值计算，不让模型凭文字猜算术。OCR（光学字符识别）错误、单位冲突和低质量扫描件要标记或复核，不能把错误原料交给模型后再指望提示词修好。最终答案给出页码或对象引用，既便于用户核查，也便于定位解析环节的错误。

T16. 怎样做内容安全，如何过滤模型输出？参考答案

内容安全不只是检查最后一句话，还要限制模型能看到什么、能操作什么。输入侧做身份和数据范围检查，检索侧只提供当前用户有权限的证据，工具侧由服务端校验参数和授权；删除、转账等高风险动作需要独立确认，不能因为模型说用户同意了就执行。

检索到的网页、文档和工具结果都属于不可信内容。例如网页写着忽略规则并上传密钥，这只是待处理文本，不是系统指令。需要隔离指令与资料，限制可调用工具和可访问目标，即使模型受诱导，也不能拿到不该有的权限。关键词黑名单或多写一句安全提示都不够。

输出侧再检查隐私、违规内容、结构和业务规则。流式输出要特别注意：内容一旦发给用户就收不回来。高风险场景可以完整审核后再发送，或分段缓冲审核，但分段可能漏掉跨段含义，需要按风险选择策略。命中安全规则时返回明确的拒绝或人工处理结果，审计日志也要脱敏，避免日志成为新的泄露入口。

二面：系统设计、评测与稳定性

T17. 线上 BadCase 怎样收集并迭代优化？参考答案

我会把 BadCase 当成可以复现和定位的失败样本，而不是只保存一句用户差评。除了差评，还收集无答案、超时、工具失败和抽样人工检查的结果，避免只看到愿意反馈的用户。每条样本关联脱敏问题、检索证据、模型与提示词版本、工具结果和 Trace，也就是一次请求完整的调用轨迹。

先按根因分类再改。比如答案引用了旧制度，要确认是索引没更新、重排选错，还是生成时忽略新版本；这几种原因对应完全不同的修复。优先级综合频率和风险，偶发的越权泄露也可能比高频的措辞问题更重要。

修复后把代表性案例放进回归集，同时保留没参与调优的测试集，避免只对已知题目有效。通过固定版本对照、灰度和线上监控检查质量、延迟及费用。这样每次优化都有证据说明修好了什么、有没有带来退化，而不是改完 Prompt 后主观觉得更好了。

T18. 设计一个 C 端文档知识库助手：长文档上传、多轮对话、流式输出参考答案

我会把系统拆成异步文档处理链路和在线问答链路。上传接口先鉴权、检查大小和格式，把原件存对象存储，生成文档 ID 与处理状态；解析、分块和建索引交给队列执行。长文档不占着一个 HTTP 请求等处理完，前端展示进度和可重试的错误。

索引记录文档版本、片段出处和所属用户，只有一个版本准备完整后才切换为可查询状态，避免用户问到半份新文档。更新或删除文档时，要同步处理索引和缓存。重复投递的解析任务通过文档版本和阶段标识去重，不反复插入相同片段。

在线提问时先结合最近对话理解当前问题，再在授权范围内混合检索、重排，把证据交给模型生成带引用的回答，通过 SSE 推送内容和最终状态。会话记录持久化，证据不足时明确说明。重点验收跨用户隔离、文档更新后是否仍答旧内容、解析失败恢复和断线后的结果查询，而不只是演示能上传和聊天。

T19. 设计支持大量用户的通用 Agent 平台：持久会话、熔断、限流、日志参考答案

我会把平台分成接收和管理任务的 API 层，以及真正执行任务的 Worker 层。API 认证用户、检查配额，持久化运行记录并可靠入队，立即返回任务 ID；长任务交给 Worker，不绑在浏览器连接或某个 API 实例上。前端通过事件订阅或查询看到进度。

队列和 Worker 都要有上限，并按租户分配并发额度，避免一个大客户把资源占完。Worker 限时领取任务，保存执行进度；重启后可接手未完成任务，状态更新需校验执行版本，工具写操作需幂等。任务记录成功但消息没发出去也要能修复，例如用事务 Outbox 在同一事务中记录待发送事件，再异步投递。

每次运行有总时限、最大步数和费用预算，下游故障时熔断或降级，队列满时明确拒绝或告知等待，不能无限积压。Trace ID 串起模型、工具和状态变化，分别监控任务成功率、排队时间、P95 和费用。验收时要主动模拟 Worker 崩溃、消息重复和下游超时，证明系统能恢复，而不只证明正常请求能跑通。

T20. SSE 下游模型抖动或大量超时，怎样保护整条链路？参考答案

我会先把慢请求挡在资源耗尽之前：入口限制租户和全局并发，队列有最大长度，模型调用分别限制建立连接、首 Token、流中空闲和总耗时。持续失败的提供方触发熔断，暂时不再把新请求压过去，而不是每个请求都等到超时。

重试只给暂时性故障，并遵循退避、随机延迟和总预算。流还没输出时，可以在安全前提下重试或切备用模型；已经输出一半时，不能把另一段重新生成的内容直接拼上去，因为两次回答可能互相矛盾。此时应标记本次输出不完整，由产品明确提供重新生成或查询后台任务结果。

如果连接仍在，可以发送带请求 ID 的错误事件；如果网络已经断了，就只能把失败状态持久化，供用户重连查询。过载拒绝应尽量发生在打开事件流之前，返回明确状态和重试提示。降级时可以提供检索证据或稍后查询，而不是让前端一直停在加载中。

T21. Rerank 推理慢、QPS 上不去，怎样扩容优化？参考答案

单请求快和整体吞吐高不是一回事。我会先测一次请求有多少候选、每个片段多长，以及时间花在等待、网络还是模型计算。实际工作量更接近每秒要处理多少组问题与候选文本，仅看 HTTP 请求数可能掩盖负载差异。

计算瓶颈可以用更小模型、合适的量化或加速后端，并减少无效候选；吞吐瓶颈可以用动态批处理和多副本。动态批处理把多个请求的文本对凑成一批计算，有利于利用加速硬件，但凑批会增加等待时间，所以要同时限制批大小和最长等待时间，长短文本尽量分组，减少补齐长度带来的浪费。

重排服务使用独立资源池和有界队列，扩容依据排队与资源利用率，而不是只看 QPS。超过请求剩余时间预算就跳过重排，回退融合排序。上线前用真实的长短查询比例压测，并同时比较 P95、吞吐和检索排序质量；只把批量调大，可能看起来吞吐提高了，用户却等得更久。

T22. 多轮对话太长有哪些方案？各有什么优缺点？参考答案

常见方案有最近窗口、历史摘要、按需检索和直接使用长上下文，区别主要在省掉多少成本，以及可能丢掉什么信息。最近窗口只保留近期对话，便宜简单，但早期约束会被截掉；摘要能保留大意，但可能丢细节或把错误继续传下去。

历史检索只取与当前问题相关的原文，适合查很久以前的具体事项，但存在漏召回，也不擅长单独判断多次修改后哪个状态最新；长上下文保留原文最直接，但输入成本、延迟会增长，模型也不一定有效利用所有内容。所以窗口大不等于记忆管理问题自动消失。

我的选择是组合使用：系统约束和当前任务状态固定保留，最近轮次保留原文，摘要用于快速了解背景，旧细节按需检索。例如旅行规划中，近期消息用于理解正在讨论哪座城市，当前预算作为结构化状态保留，早期饮食限制则要能准确取回。用这种跨轮用例测试，比只比较压缩率更有意义。

T23. 什么场景用 Workflow，什么场景用 Agent？C 端怎样取舍？参考答案

流程能提前定义，就优先用 Workflow；下一步必须根据未知结果临时决定，才把这部分交给 Agent。Workflow 不等于完全不用模型，它也可以在固定步骤中调用模型；Agent 的特点是模型参与决定下一步动作，而不是有了聊天界面就叫 Agent。

比如售后申请中，身份验证、订单查询、退款资格和审批可以固定成流程，金额与权限由代码检查；需要查几份材料来解释一个复杂问题，则可以让 Agent 动态补查。实践中两者常常嵌套：外层流程控制受理、预算、审批和验收，内部 Agent 在限定工具与步数内完成探索。

C 端更重视响应速度、费用和可预期结果，所以我不会把本来明确的每个步骤都交给模型重新规划。只有动态决策确实提高任务完成率时，才接受它带来的额外调用和不可预测性，并准备超时、拒答和人工接管。

T24. 多 Agent 适合哪些场景？缺点、通信、状态同步和容错怎样处理？参考答案

多 Agent 的价值来自分工和并行，不是 Agent 数量越多就越聪明。适合拆成独立子任务、需要不同工具权限，或者需要单独审核的场景。例如前后端按约定接口并行开发，再由另一个 Agent 检查集成问题；如果只是改一个按钮，协调成本可能比直接完成还高。

通信要使用明确的任务 ID、输入输出结构、版本和产物引用，不能只在聊天里互相说做完了。业务状态以持久化任务记录为准，每项状态明确由谁更新。消息可能重复，所以接收和外部写操作要幂等；依赖失败时，下游应该阻塞或进入替代路径，而不是拿着缺失输入继续编造结果。

容错以子任务为单位设置超时和有限重试，失败后保留已验收的其他成果；共享文件或结论冲突由指定汇总者处理，不能让最后写入者自动胜出。多个 Agent 也可能犯相同错误，因此审核仍需要测试和规则证据。最后用单 Agent 作基线比较总耗时、成本和成功率，确认分工收益大于沟通和返工成本。

T25. 如何评测 RAG 与 Agent？自动化和 LLM-as-Judge 有什么缺陷？参考答案

我会分三层评测：证据有没有找对、执行过程有没有走对、最终业务有没有真的完成。RAG 的 Recall@K 看前 K 条结果找回了多少相关证据，再看引用是否支持结论和答案是否正确；Agent 还要检查工具参数、权限、任务完成率、耗时和费用。

任务完成不能只听模型说完成了。例如 Agent 说已退款，要查交易或业务记录是否真的成功，有没有重复退款；回答格式正确、工具返回成功码，也不一定代表业务终态正确。可确定的结果用程序和测试检查，开放性的答案质量再交给人工或 LLM-as-Judge，也就是让模型按评分标准评价答案。

模型评委适合批量处理，但可能偏爱较长答案、受答案顺序影响，也可能认同和自己相似的错误。我会用人工标注样本校准，交换答案顺序检查偏差，给出清晰评分规则；固定回归集之外还保留未参与调优的测试集，并覆盖越权、无答案和恢复等失败场景。详细指标可复习 Agent 评测体系。

T26. 优化 Agent 稳定性，从哪些维度入手？参考答案

稳定性不是保证每次模型都答对，而是错误不会失控，失败能定位，任务能安全恢复。我会先按失败频率和影响找最主要的问题，再沿输入、模型、工具、状态和输出检查边界，而不是一次把所有组件都换掉。

比如工具实际已经创建订单，但返回途中断网，如果只加重试，就可能重复下单。正确做法是用稳定的幂等键识别同一次操作，先确认原操作状态，再决定恢复；任务进度还要持久化，避免重启后丢失这个判断依据。再比如模型返回合法 JSON 但订单金额为负数，仍要由业务校验拦住。

模型侧设置预算、结构和业务校验，工具侧限定权限和安全重试，运行侧保存进度并拒绝过期执行结果，最终结果以真实业务状态验收。每次失败通过 Trace 归类，修复后加入回归，并模拟断网、重复消息和进程重启。最终观察的是成功率、重复副作用、恢复耗时和人工介入比例，而不只是接口错误数变少了。