D3 · 上下文、RAG 与网络

本日安排：8 小时净学习。休息另计，算法可独立安排。

学习安排

• 3 小时：AG09–AG14，上下文与 RAG。
• 1.5 小时：NC01–NC04，网络与流式。
• 1.5 小时：检索失败排查实验。
• 1 小时：闭卷复述数据库。
• 1 小时：口述与纠错。

上下文是每次推理时重新组装的输入

一次模型调用实际接收的不只是用户刚发来的那句话。系统指令、当前请求、选入的历史消息、工具定义与结果、检索到的证据、输出格式要求，都会占用上下文预算。上下文工程关心每一轮应把哪些信息放进去、按什么顺序组织、什么时候更新或压缩；Prompt Engineering 更集中在指令和示例怎样表达。[15]

例如售后 Agent 正在处理退货申请。当前轮需要申请 ID、商家与商品、已经核实的签收日期、适用政策版本、用户当前问题和可调用工具。十几轮以前的完整物流响应通常不需要重放；可以保存可追溯的订单引用和摘要，需要时再查原记录。上下文大不表示其中每条信息都可靠，也不能把提示中的内容自动变成业务事实。金额、授权、状态和已执行的退款结果应从结构化业务状态读取。

历史压缩有成本。摘要可能漏掉否定词、日期、条件或说话者；原始工具输出可能很长，旧结果还可能过时。压缩时保留任务目标、未完成事项、用户明确限制、关键实体和来源指针，并标清“已核实事实”和“模型推测”。高风险动作执行前重新查询权威状态。上下文整理不是在模型端建立数据库事务，也不能替代鉴权。

可以把单轮装配想成一次有截止时间的查询计划：先从持久任务状态读出当前阶段和已完成操作，再按本轮任务筛选历史；若需要政策，就在当前主体有权限的范围内检索适用版本；若要执行工具，则只附带该工具所需参数和可验证的返回标识。每项数据最好保留来源、更新时间和作用范围。这样在发现摘要误写或政策过期时，系统知道应回查哪个记录，而不是要求模型从一段对话中猜出真相。

几种常被混为一谈的状态需要分开：Session 是一段交互的组织边界；checkpoint 保存编排执行某一时点的状态，供恢复或继续执行；跨会话 memory 存用户偏好、可复用事实等经过选择的信息；业务状态则以订单、退款账本和权限记录为事实来源。LangGraph 文档也区分线程内图状态快照的 checkpointer 与跨线程应用数据的 store。[16] KV cache 是推理过程用于复用模型中间计算的缓存，不是对话 memory、工作流 checkpoint 或耐久账本。设计时按写入主体、作用域、时效、删除要求与恢复目标选择存储，不要用一个“memory”字段统称所有状态。

RAG 是数据加工与在线决策的两条管线

RAG（Retrieval-Augmented Generation）把外部资料检索进一次生成上下文。它通常包含两条路径。离线侧：来源采集、解析清洗、权限与版本标注、按结构切块、建立关键词或向量索引、校验后发布一代索引。在线侧：解析问题、在授权范围内检索候选、合并或重排、挑出证据、装配上下文，再由模型生成回答并检查引用是否支持结论。

同样是找售后政策，关键词检索擅长精确编号、型号和术语；向量检索按语义相似性找候选。混合检索可以兼顾两种信号，排名融合可使用 Reciprocal Rank Fusion（RRF）按各自名次合并，避免直接把尺度不同的文本匹配分数和向量分数相加。[17][19] Reranker 再对较小候选集按 query 与文档的关系重新排序；如果相关片段根本没进入候选，重排器没有材料可救。[18]

切块会改变检索到的事实边界。原文“签收后七日内可申请；逾期不受理”若把“七日内”与“不受理”切到不同块，查询“签收第八天是否可以退”可能只取回其中一部分，答案缺失条件。优先沿标题、段落、列表和表格结构切分；长段再按句子切分，并保留文档 ID、版本、标题路径和原文定位。Overlap 可降低边界截断风险，也会增加重复候选和索引成本，需用问题集验证，不应设成越多越好。

租户、地区、业务范围和文档有效期要作为检索约束，而不是只在模型读到结果后口头提醒。私有片段不能先进入公共缓存或不受控 trace，再指望生成器主动忽略。索引更新可先建新 generation，核对数量、元数据和抽样查询，再切换线上版本，避免一次查询混用新旧语料。公开政策网页、租户私有工单和实时订单状态也不是同一种数据；文本政策可以 RAG，订单金额通常应走受控的结构化查询。

错误答案要沿数据路径逐段定位

假设虚构的商家 A 当前政策是签收后七日内可申请退货；旧版政策写三十日，商家 B 的政策写六十日。问 A 商家签收十二日后是否符合政策。系统若回答“可以”，不能只说模型幻觉：先确认当前适用的 A 政策是否已进入在线语料，版本和有效期是否正确；再检查该查询是否绑定了正确商家、地区和权限；然后看目标片段有没有进入初召回，重排是否把它挤出；之后核查上下文是否截断“七日”或夹入旧版；最后再检查生成结论和引用。

这个顺序把“检索到什么”与“模型拿到什么”分开。可用标注过的标准问题计算相关证据是否在 top-k 中，排查候选不足；记录重排前后排名，区分召回失败和排序失败；记录最终装配上下文中的片段 ID 与版本，判断预算截断；逐项对照回答中的结论和被引用原文，识别引用不支持结论的问题。

诊断时可把目标证据直接提供给模型做一次受控测试。如果在证据无误且完整注入的条件下仍答错，问题偏向理解、指令或证据冲突处理；这只隔离生成侧的一部分变量，不证明生产检索性能很好。反过来，向量库返回了“相关政策”也不代表正确：若它是旧版本或属于别的租户，错误在数据身份和权限筛选环节，不能归咎为模型没有服从。

评测也应拆成不同问题：召回阶段看标注证据能否进入 top-k；排序阶段看目标证据在候选中的位置；装配阶段确认它是否实际进入模型输入；回答阶段核对重要结论是否被对应片段支持。整体业务成功率仍要看，但单独报一个总分会掩盖具体阶段的退化。例如 top-k 召回不变而答案质量下降，应先查上下文裁剪和生成，不必立刻更换向量索引。

一个可复现的回归集应至少包含正常命中、资料缺失、过期版本、错误租户、切块丢条件、初召回遗漏、重排误排、上下文预算截断和正确证据下生成错误。每例保存期望证据、适用版本、预期答复或拒答，以及失败所在阶段。若知识不存在或授权范围内没有可用证据，系统应明确无答案、补问或转人工，而不是靠调大 top-k 掩饰语料缺口。

长上下文、RAG、Prompt 与训练各自处理不同问题

稳定且体量小、每次决策都需要的说明，可以直接放进上下文；数量大、经常更新、需按租户筛选的资料，更适合外部检索。两种方式可以组合：固定指令放在 prompt，当前任务状态从业务系统装配，政策文档按需检索。增加上下文窗口不等于无条件保留全部历史；多余、冲突或陈旧信息可能干扰当前任务。[15]

Prompt 和示例改变本轮推理可见的指令及演示；RAG 在推理时提供外部证据；监督微调（SFT）用示范输入输出训练权重，使模型更稳定地学会某种任务行为；强化学习（RL）类方法根据奖励或偏好信号优化行为。它们的故障类型不同：政策刚改版，先修知识和索引；系统没把退款限制放进工具参数或服务端校验，先修接口和后端约束；模型持续误解任务格式，可评估提示、示例或微调；确定性的金额核算交给代码。模型优化应由错误分类与可重复评测驱动，不把“再训练一下”当通用修复。[25]

长期 memory 也要有写入策略。把所有对话原文都存进向量库会混入临时信息、错误推断和敏感内容。要记录来源、所属主体、时间、有效期与删除路径；冲突的旧偏好不能无提示覆盖用户的新指令。RAG 检索结果只是候选证据，摘要是派生信息，二者都不自动拥有业务授权。

网络协议与 Agent 的流式响应

TCP 向应用提供可靠、有序的字节流。它不保留业务消息边界，所以一次 write 不保证对应对端的一次 read；应用协议需要用长度字段、分隔符或已定义格式划分消息。[20] TCP 确认的是传输层接收进度，不是对端已写入数据库。调用方在 HTTP 超时后重新发起退款请求，仍可能造成重复业务执行，因此副作用请求需要业务幂等键和结果查询路径。

HTTPS 通常在 HTTP 之下使用 TLS 保护传输机密性和完整性并认证服务器身份，但 TLS 不替应用做用户授权。HTTP/2 在一条 TCP 连接上用多个流并发承载请求，降低连接开销；但 TCP 层丢包可能让连接上的多个流共同等待。HTTP/3 把相同 HTTP 语义映射到 QUIC，QUIC 为流提供独立的可靠传输和流控，减少单个流丢包造成其他流停顿的情况；连接拥塞控制和网络状况仍会影响整体进度。[21][22] 因此，“HTTP/2 没有队头阻塞”或“HTTP/3 因为 UDP 就不可靠”都不准确。

若浏览器只需接收 Agent 的状态更新和流式文本，SSE 是基于 HTTP 的单向事件流；需要客户端和服务端持续双向发送消息时，可评估 WebSocket。SSE 客户端会在连接关闭后重连，协议支持事件 ID 与 Last-Event-ID 恢复位置，但服务端要实际保存事件并按权限补发；自动重连只恢复连接，不会自动恢复后台 Agent 的计算或外部操作。[23]

把任务执行与前端连接拆开：后台任务按持久状态推进，连接只订阅事件。可存最终状态和需要恢复的关键事件，前端携带最后收到的序号续订并去重；若历史事件已过期，服务端返回当前状态快照。客户端取消流连接，表示停止接收或请求取消，不保证已经发出的工具调用、数据库提交或外部退款被撤销。对于长时间等待人工审批的执行，checkpoint 可恢复编排位置，但副作用是否已发生仍要查业务账本。

在服务端还要为一条响应流设定清楚的资源边界：任务总 deadline、单次模型/工具调用超时、并发上限和输出上限分开管理。连接断开后是继续任务、尝试取消还是进入可恢复暂停，应该由任务策略决定；若继续执行，就不能持续保留一个无人消费的无限缓冲区。对可恢复流可以保存重要状态变更和最终产物引用，普通 token 是否逐个落库则按产品所需恢复精度与存储成本决定。

网络超时后的重试需先识别操作性质。纯查询通常可以重新查询最新状态；有副作用的 POST 如果服务端可能已经完成但响应在途中丢失，调用方仅凭超时无法判断操作结果。使用同一业务幂等键重试并查询结果，才有机会把多次传输映射为一次业务意图。[24] TCP 的重传只修复同一连接中的传输丢失，不会替应用为两次 HTTP 请求去重。相同地，SSE 事件序号能恢复观察位置，不是任务 ID，也不应被当成业务幂等键。

从面试问题映射到系统层次

遇到“为什么答案错了”，先问错的是哪一层：规则本身无效，属于知识治理；目标片段没进候选，属于召回；候选顺序不合适，属于排序；正确证据没进最终输入，属于上下文装配；回答超出证据，属于生成与引用校验；Agent 用错了订单或金额，属于业务工具和权限控制。每层都有不同的测试输入和观测数据，不宜拿单个端到端准确率解释所有故障。

遇到“断线是否重跑”，先问任务是否仍在后台运行，再查已持久化状态、工具调用记录和最后事件序号。重连只处理客户端如何继续观察。若任务被可靠取消，应有运行时确认；若副作用已经提交，则更新业务状态或执行补偿流程。系统不能从“前端没看见成功消息”推断“业务没有成功”，也不能从“模型流里出现成功字样”推断“业务已完成”。

选择题

选择题 1

哪项最准确地区分 checkpoint、跨会话 memory 与业务状态？

• A. 三者都是向量检索中的自然语言摘要
• B. Checkpoint 可保存线程执行状态，memory 保存可复用的信息，业务状态以权威业务记录为准
• C. KV cache 就是 checkpoint 的推理引擎版本
• D. 只要模型能在历史中找到退款结果，就无需查业务记录

答案与解析

正确答案：B。

• A 错：三者有不同的范围、存储语义和权威性。
• B 对：它区分了编排恢复、跨会话信息与业务事实。
• C 错：KV cache 是推理计算缓存，不是工作流状态存储。
• D 错：模型历史不等于业务账本。

选择题 2

在 RAG 检索结果里没有目标政策片段，最合适的判断是什么？

• A. 调大 Reranker 的模型参数就一定可以找到它
• B. 先排查语料覆盖、权限过滤和初召回；重排器不能重排未召回文档
• C. 让模型根据相近政策推测即可
• D. 直接把所有租户的政策放入上下文

答案与解析

正确答案：B。

• A 错：候选中缺少证据时，重排无法补回。
• B 对：先判断目标资料是否存在并进入候选集合。
• C 错：相近资料不证明该商家适用此政策。
• D 错：跨租户混入上下文会破坏权限边界。

选择题 3

为什么混合检索常使用 RRF 合并关键词与向量结果？

• A. 它按结果名次融合不同检索排序，不要求两种原始分数可直接比较
• B. 它会自动修复过期文档和错误权限标签
• C. 它等于生成模型重新写一遍索引
• D. 它保证每个问题都能召回正确答案

答案与解析

正确答案：A。

• A 对：RRF 根据名次融合多个结果列表。
• B 错：数据版本和 ACL 问题要由索引和过滤流程解决。
• C 错：RRF 是排名融合，不负责索引重写。
• D 错：任何排名方法都不能保证语料正确或必然召回。

选择题 4

用正确目标片段直接构造上下文后模型仍给出错误结论，可以推出什么？

• A. 生产检索链路已完全正确
• B. 检索错误一定是唯一根因
• C. 生成理解或上下文冲突值得进一步排查，但此测试不能证明生产检索表现
• D. 只要引用链接可点击，结论便有证据支持

答案与解析

正确答案：C。

• A 错：诊断注入绕过了生产检索链路。
• B 错：题设显示生成端也有问题的可能，但不排除其他因素。
• C 对：它隔离部分生成变量，不能替代检索评测。
• D 错：引用存在不等于原文支持具体结论。

选择题 5

关于 HTTP/2 和 HTTP/3 的传输差别，哪项正确？

• A. HTTP/2 每个请求使用独立 TCP 连接
• B. HTTP/2 多流复用仍可能受 TCP 丢包造成的跨流停顿影响；HTTP/3 基于 QUIC 的独立流传输减少该问题
• C. HTTP/3 底层是 UDP，因此没有可靠传输
• D. 两者都改变了 HTTP 方法语义

答案与解析

正确答案：B。

• A 错：HTTP/2 可在连接上复用多个流。
• B 对：这说明了 TCP 与 QUIC 流处理差异。
• C 错：QUIC 在 UDP 之上提供可靠传输机制。
• D 错：HTTP/2 和 HTTP/3 优化传输映射，保留 HTTP 语义。

选择题 6

用户断开 Agent 的 SSE 连接后，哪种设计最能正确恢复？

• A. 把 SSE 重连视为任务重新执行信号
• B. 让前端请求再次触发退款，依赖 TCP 去重
• C. 后台按持久状态运行；客户端按最后事件序号续订，过期时读取状态快照
• D. 断开连接即回滚已提交的数据库事务

答案与解析

正确答案：C。

• A 错：重连是连接行为，不应暗中重跑业务任务。
• B 错：TCP 不会跨 HTTP 请求提供业务幂等。
• C 对：执行和观察分离，并通过序号/快照恢复进度。
• D 错：网络断开无法撤销已提交事务。

简答题

简答题 1

售后 Agent 需要继续处理一个跨多轮任务。请区分本轮上下文、checkpoint、长期 memory、业务状态与 KV cache，并说明退款金额应从哪里读取。

参考解答与评分

本轮上下文是送给模型的当前输入视图，包含当前问题、相关历史、工具和证据；checkpoint 保存线程内编排状态以便续跑；长期 memory 保存经筛选、适合跨会话使用的信息；业务状态以订单/退款记录为权威；KV cache 复用推理中间计算，不是业务存储。退款金额应由业务服务从权威订单和退款状态计算或读取，并在执行前重新校验。

评分点：

• 区分当前上下文与持久化运行状态（1分）。
• 区分 checkpoint 与长期 memory 的作用范围（1分）。
• 说明 KV cache 不是长期记忆或账本（1分）。
• 金额从权威业务数据读取并在执行前校验（1分）。

简答题 2

用户问“商家 A 签收第十二天还能否退货”，检索回答引用了旧版三十天政策。描述一条排查路径，至少覆盖知识版本、检索候选和回答证据。

参考解答与评分

先确认有效语料是否包含 A 当前政策及版本有效期，再检查查询是否应用正确商家、地区和权限过滤。查看目标片段是否进入初召回、重排前后顺序及最终上下文是否被旧版本覆盖或截断。最后对照回答 claim 与原文条款，确认引用是否真支持答案；没有当前证据时应拒答、补问或转人工。

评分点：

• 核实语料存在、有效期与版本（1分）。
• 检查主体/权限过滤条件（1分）。
• 区分初召回、重排和上下文装配（1分）。
• 验证引用支持结论，不足时安全降级（1分）。

简答题 3

一个请求先经词法检索与向量检索得到两个候选列表。说明混合召回、RRF 与 Reranker 的工作顺序及各自局限。

参考解答与评分

词法检索提供精确词项线索，向量检索补充语义相似候选；可先分别召回候选，再用 RRF 按排名合并。对合并后的有限 top-k 列表，Reranker 按查询与文档关系细排。RRF 不修复语料或权限错误，Reranker 也不能找回初召回未包含的文档，因此需要分别评估召回和排序。

评分点：

• 说明词法与向量检索的不同作用（1分）。
• 说明 RRF 按排名融合，不要求原始分数同尺度（1分）。
• 说明 Reranker 对有限候选做重排（1分）。
• 指出重排不能恢复缺失候选（1分）。

简答题 4

Agent 的长任务通过 SSE 向浏览器推送进度。浏览器断线时如何分别处理后台执行、事件恢复和外部副作用？

参考解答与评分

后台任务从持久工作流或业务状态推进，不能由浏览器连接寿命决定。服务端为关键事件保存序号，客户端用最后事件 ID 续订并去重；保留期外则先获取当前状态快照。连接取消只意味着停止观察或发出取消请求，不证明已发出的退款/工具操作被撤销；必须查业务状态并用幂等键避免重放副作用。

评分点：

• 将后台执行与浏览器连接分开（1分）。
• 使用事件序号或 Last-Event-ID 恢复并去重（1分）。
• 事件缺失时返回可验证的状态快照（1分）。
• 对副作用查状态并依赖业务幂等，不假设断连会回滚（1分）。

延伸阅读

• Anthropic：Effective context engineering for AI agents；LangGraph：Persistence。
• Elastic Docs：Hybrid search、Semantic reranking、Reciprocal rank fusion。
• IETF RFC 9293、9113、9114；WHATWG HTML Standard：Server-sent events。

Sources

[15] https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents [16] https://docs.langchain.com/oss/javascript/langgraph/persistence [17] https://www.elastic.co/docs/solutions/search/hybrid-search [18] https://www.elastic.co/docs/solutions/search/ranking/semantic-reranking [19] https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion [20] https://www.rfc-editor.org/rfc/rfc9293.html [21] https://www.rfc-editor.org/rfc/rfc9113.html [22] https://www.rfc-editor.org/rfc/rfc9114.html [23] https://html.spec.whatwg.org/multipage/server-sent-events.html [24] https://docs.stripe.com/api/idempotent_requests [25] https://developers.openai.com/api/docs/guides/model-optimization

面试追问

下面保留原报告的题目和口述参考答案。先自行作答，再展开查看。

AG09｜Prompt Engineering 与 Context Engineering 有什么区别？〔P0〕

口述答案

Prompt Engineering 主要设计指令、示例和输出要求；Context Engineering 还要决定每一轮放进哪些历史、业务状态、检索证据和工具定义，怎样排序、压缩和更新。它是信息组织与生命周期问题，不只是把 system prompt 写长。

售后 Agent 的下一轮需要当前申请、已核实事实、相关政策和待完成动作，不需要十轮前整段物流原始响应。我的上下文构造器区分可信指令与外部数据，保留来源和时间；关键状态从数据库重新装配，不靠模型记住。

追问怎么接

“上下文越多越好吗？”容量上限不是有效利用能力的保证。无关信息、冲突内容和陈旧结果会增加歧义；先评价信息是否帮助当前决策，再考虑扩大窗口。“工具定义很多怎么办？”先按权限和任务筛选，再按需发现，不把上千个 schema 每轮全发。

不要这样答：“模型有百万 token 上下文，所以不需要检索、筛选和状态设计”。

依据与延伸：Context、Tool-Search。

AG10｜Memory、Session、Checkpoint、业务状态、KV Cache 怎么分？〔P0〕

口述答案

它们分别解决不同问题：Session 是一次对话的组织单位；Checkpoint 保存某次执行的编排状态；长期 Memory 保存跨会话仍有用的信息；业务状态是订单、权限和执行结果的事实来源；KV Cache 是模型推理计算的中间缓存。

例如“商家偏好中文”可以成为长期记忆；“正在等审批”是工作流状态；“已退 200 元”必须以业务账本或支付结果为准；历史工具消息是证据记录，不等于当前状态。KV Cache 不能代替上述任何一种业务持久化。

追问怎么接

“长期记忆存什么？”有明确用途、来源、写入时间、过期与删除机制的信息；冲突要可处理，不能自动把模型猜测写成事实。“跨租户记忆怎么防泄漏？”读写路径都绑定主体与命名空间，检索、缓存和 trace 同样隔离；不能只在提示中提醒。

不要这样答：“把所有聊天历史放向量库就是 memory 设计”，或“KV cache 保存了用户长期记忆”。

依据与延伸：LG-Persistence、vLLM-APC。

AG11｜从零说明一个企业 RAG 系统。〔P0〕

口述答案

离线侧先采集、解析与清洗文档，按语义结构切块，保存文档版本、有效期和访问控制，再构建词法与向量索引。在线侧识别查询意图，在授权范围内检索候选，融合排名、必要时重排，把相关证据与来源交给模型，最终校验回答是否有证据支持。

BM25 等词法检索擅长明确词项、商品型号、政策编号；向量检索用于语义相似匹配。Hybrid 将两类候选合并，RRF 按排名融合，避免直接比较量纲不同的分数。Reranker 对较小候选集做更精细的 query–document 相关性判断，不替代第一阶段召回。

追问怎么接

“为什么不直接让模型写 SQL 查全部数据？”结构化订单事实适合受控业务查询，文本政策适合检索，两者可以并用。“chunk 多大？”不背固定 token 数：按文档结构、表格完整性、问题跨度、召回质量和上下文预算测试；保留父章节定位。

不要这样答：“RAG = embedding + vector DB”，或混合检索时直接把未经归一化的 BM25 与余弦分数相加。

依据与延伸：RAG-Paper、Hybrid、RRF、Rerank。

AG12｜RAG 回答错了，怎么定位？〔P0〕

口述答案

按阶段排查，而不是先换大模型。第一，原始知识是否正确、已入库且有效；第二，查询是否表达对了问题，权限与市场过滤是否正确；第三，相关证据是否进入候选、重排后是否保留；第四，证据是否在构造上下文时被截断或冲突覆盖；第五，模型是否错误理解或超出证据作答。

用“给定正确证据”的生成测试隔离生成器，再用带标注证据的查询测检索。检索 Recall@k 看相关证据覆盖，排序指标看位置，答案侧看事实支持和引用正确，最终仍看业务任务结果。

追问怎么接

“Reranker 能救召回漏掉的文档吗？”不能，它通常只重排已有候选。“引用存在就算正确吗？”不够，要检查引用确实支持该结论、版本和适用地区正确。“FAQ 能检索但退款错了？”可能是业务事实查询或执行错误，不一定是 RAG 错。

**不要这样答：**只看端到端正确率，无法判断是知识、检索、上下文、推理还是执行出了问题。

依据与延伸：Rerank、Eval-Practice。

AG13｜长上下文能取代 RAG 吗？历史怎么压缩？〔P0〕

口述答案

小而完整、版本稳定、每次确实都需要的资料，可以直接放入上下文；大型、多租户、经常更新的知识，需要检索、过滤和来源管理。长上下文与 RAG 是可组合的选择，不是二选一。

历史压缩分两类：可重查的大型工具结果保存对象引用与关键事实；对话历史做带来源的摘要，但保留未解决事项、用户限制、关键实体和最新状态。订单 ID、授权范围、金额、执行结果不能只存在自然语言摘要里。压缩后用关键事实与任务成功率做回归。

追问怎么接

“摘要错了怎么办？”摘要是派生信息；关键事实回查原始记录或业务数据库，冲突时不以摘要覆盖事实。“政策更新了怎么办？”保留政策版本和适用时点，并明确执行采用下单时、申请时还是当前规则；这属于产品契约，不能擅自选择。

不要这样答：“摘要保留语义，所以是无损压缩”，或把昨天缓存的政策当成今天写操作的授权依据。

依据与延伸：Context、RAG-Paper。

AG14｜Prompt、RAG、SFT、RL 分别解决什么？〔P1〕

口述答案

Prompt 和示例改变本次推理的指令与演示，不修改模型权重；RAG 在推理时提供外部知识；SFT 用示范数据训练模型更稳定地完成特定行为；RL 类方法依据奖励信号优化行为，成败取决于奖励是否对应真实目标以及训练数据覆盖。

政策每天变化，优先更新知识与检索，而不是每日微调；调用工具总是选错，要先检查工具描述、数据和执行反馈，必要时再训练；确定性的金额校验，直接写代码，不训练模型去近似。先建立错误分布和评测，再决定干预层。

追问怎么接

“为什么不一上来微调？”要区分缺知识、缺能力、上下文不足与接口设计差；微调不解决实时权限、数据库一致性和错误工具契约。“模型自动反思算 RL 吗？”推理时反思不等于权重更新；没有训练过程就不要称为强化学习训练。

不要这样答：“接了知识库就叫训练模型”“反馈一句做错了就是 RL”。

依据与延伸：Model-Optimize、RAG-Paper。

NC01｜TCP 为什么三次握手？可靠字节流、粘包、TIME_WAIT 怎么讲？〔P0〕

口述答案

TCP 建连要让双方确认通信可达并同步各自序列号，典型过程为 SYN、SYN-ACK、ACK。它向应用提供可靠、有序的字节流，不保留业务消息边界；一次 write 不保证对应对端一次 read。所谓粘包/拆包，本质上需要应用协议用长度、分隔符或固定格式定义消息边界。

关闭时两个方向独立关闭，报文可以合并，不能机械认定永远四个包。TIME_WAIT 用来处理最后确认重传及旧连接报文等问题，不能看到连接多就直接关掉相关保护。

追问怎么接

“TCP 重传会导致重复退款吗？”同一连接的传输重复由 TCP 处理；应用超时后重新发 HTTP 请求，仍可能触发第二次业务执行。“ACK 说明什么？”说明传输层的接收进度，不证明应用已经提交数据库。

不要这样答：“TCP 可靠，所以业务不需要幂等”“每次 send 对应一次 recv”。

依据与延伸：TCP、HTTP。

NC02｜HTTPS 请求经过什么？HTTP/1.1、2、3 差在哪里？〔P0〕

口述答案

典型 HTTPS 请求经历名称解析、建立/复用连接、TLS 身份与密钥协商，再发送 HTTP 请求；实际可能复用 DNS、连接和 TLS 会话。TLS 保护传输机密性与完整性并校验对端身份，不替代应用权限控制。

HTTP/1.1 可复用连接，但不具有 HTTP/2 的多流复用机制；HTTP/2 在 TCP 上复用多个流，仍受 TCP 丢包导致的传输层队头阻塞影响；HTTP/3 基于 QUIC，提供独立流传输，减少这类跨流阻塞，但仍有共享拥塞控制等约束。三者保留共同的 HTTP 方法语义。

追问怎么接

“HTTP/3 基于 UDP 就不可靠？”可靠性和流控制由 QUIC 提供，不能只看底层 UDP。“0-RTT 越多越好？”早期数据存在重放风险，不能把不安全重放的写操作无条件塞进去。“连接复用好处？”减少握手与连接资源成本，但需控制连接池和故障连接。

不要这样答：“HTTP/2 没有任何队头阻塞”“HTTPS 能防住有合法账号的越权退款”。

依据与延伸：HTTP2、HTTP3、TLS。

NC03｜HTTP 幂等、超时、重试怎么设计？〔P0〕

口述答案

HTTP 的 safe 指请求语义不要求改变服务端状态；idempotent 指重复相同请求的预期效果与执行一次相同，不要求返回值完全相同。POST 不天然承诺幂等，但服务可以通过业务幂等键提供可安全重试的契约。

远程调用设置连接超时、单次请求超时和整个任务 deadline。按错误类型决定是否重试，使用退避与随机抖动，并限制总尝试次数；429 等情况遵守服务端指示与配额。超时只说明调用方未及时拿到结果，不说明远端没有执行。

追问怎么接

“所有 5xx 都能重试？”有副作用的操作仍需要幂等与状态核查，不能只按状态码决定。“每层重试三次怎样？”多层会放大请求量，统一重试职责与预算。“GET 一定无副作用吗？”HTTP 规定的是安全语义，错误实现仍可能违背它，不能拿方法名代替审计。

不要这样答：“DELETE 第二次返回 404，所以不幂等”“只配置 read timeout 就是完整 deadline”。

依据与延伸：HTTP、AWS-Retry。

NC04｜Agent 用 SSE 还是 WebSocket？断线如何恢复？〔P0〕

口述答案

只需服务端向浏览器推送进度与 token 时，可以用 SSE；需要持续双向交互或其他消息模式时考虑 WebSocket。两者都不提供任务持久化：连接断开和后台任务结束应分开处理。

为可恢复任务记录递增事件序号，重连按已见序号补发，客户端去重；SSE 的 Last-Event-ID 可承载恢复位置，但服务端仍需保留事件并校验访问权。若事件已过期，返回当前快照再续订，而不是假装完全补齐。大批 token 可临时传输，关键状态/操作事件必须可靠保存。

追问怎么接

“每个 token 都必须落库吗？”不必，取决于恢复要求；可持久化最终文本和关键事件，重连以快照替代部分 token。“流已经告诉用户成功，后来工具失败？”成功消息必须由已知业务结果生成；未经验证的推测不要作为不可撤回的确认流出。

不要这样答：“SSE 自动重连，所以任务自然恢复”“HTTP 流断了就默认退款没发生”。

依据与延伸：SSE、WebSocket、LG-Checkpoint。