10. 高频问题速记
十、高频问题速记¶
这一节仍然是给你面试前快速回收用的，但它不应该只是“背答案的卡片”。更好的用法是：先用这里把一个问题的主线想清楚，再回到前文对应章节，把它讲成完整系统链路。也就是说，这一节不是替代正文，而是帮你把正文压缩成能在面试里快速调出来的表达。
1. 为什么 context 不能放进 struct¶
因为 context 代表的是一次请求、一次任务或者一次调用链上的控制边界，而 struct 往往活得比请求久得多。把它存进 struct，最容易造成两种后果。第一种是生命周期错位，旧请求的 context 被新逻辑继续沿用，取消信号、超时和 trace 信息都开始变得模糊。第二种是边界错位，本来应该在入口处显式传递的控制线，被悄悄埋进了对象内部，调用方看不出来什么时候在用哪个 context。更稳的做法几乎总是把 context 作为参数沿调用链显式传下去，让谁负责取消、谁负责超时、谁负责派生子 context 都清清楚楚。
2. 为什么 map 不能并发写¶
因为普通 map 只是运行时维护的一种键值结构，本身不提供并发同步语义。多个 goroutine 同时写，或者一边写一边读，都可能破坏它内部状态。最直观的后果是运行时直接报 concurrent map writes，更麻烦的情况则是没有马上崩，但数据已经竞争损坏了。这个问题真正想提醒你的不是“map 很特殊”，而是“共享可变状态一定要有同步边界”。所以关键不只是记住“map 不能并发写”，而是养成条件反射：只要一个状态会被多个 goroutine 同时接触，就立刻判断该用锁、channel 还是别的同步方式。
3. 什么时候用接口，什么时候用具体类型¶
默认先用具体类型，只有在边界真的稳定、实现真的可能变化、测试真的需要替身、或者系统真的有插件化扩展需求时，再由消费方定义小接口。Go 的接口设计本来就不是为了先把目录分层做漂亮，而是为了围绕真实变化点建立抽象。很多项目的问题不是接口太少，而是接口太早、太大、太装饰性。面试里如果被问到这个问题，更成熟的回答通常不是“接口有利于解耦”这种空话，而是你能具体说明：比如 Retriever、Embedder、LLMClient 这类边界为什么适合接口，而某个只在当前包内部用、未来并不会替换的对象为什么直接保留具体类型更好。
4. sql.DB 是什么¶
它不是一条数据库连接，而是连接池管理器。你在代码里长期持有并复用的那个 *sql.DB，本质上是在协调一批非常稀缺的资源，也就是数据库连接。这个问题之所以高频，不是因为面试官想听定义，而是因为它能迅速看出你到底有没有把数据库访问理解成资源管理问题。只要你真的明白 sql.DB 是池而不是连接，后面很多事情才会自然成立：为什么 MaxOpenConns 太小会排队，为什么太大又可能把数据库打爆，为什么查询要接住 context，为什么慢查询不只是 SQL 语句本身的问题。
5. 为什么先学 net/http，而不是只学 Gin¶
因为 Gin 解决的是开发体验问题，而 net/http 决定的是底层模型。请求怎样进入服务、Handler 抽象为什么长这样、中间件为什么能一层层包起来、Request.Context() 为什么能承载取消、流式输出为什么最后还是回到 ResponseWriter 和 Flush，这些都属于底层认知。你不把这一层搞清楚，用 Gin 当然也能写接口，但一遇到 SSE、断连取消、自定义中间件、优雅退出这类问题，理解就会变得不稳。先学底层并不是排斥框架，而是为了让你在使用框架时知道它到底帮你封装了什么、没帮你改变什么。
6. 为什么结构化输出重要¶
因为 AI 输出一旦要进入数据库、工作流、工具调用或审计链路，自由文本就不再够用了。结构化输出的价值，在于把“看起来像正确”变成“可以被解析、校验、拒绝和回退”。比如模型说“我觉得应该查一下报销状态”，这只是文本；但如果它返回的是一个符合 schema 的工具调用参数对象，服务端就能检查字段是否齐全、类型是否正确、权限是否允许、缺失时要不要打回重试。越靠近系统边界，越不应该依赖“模型大概会按要求来”，而应该把输出压成后端真正能控制的结构。
7. Tool Calling 最重要的是什么¶
不是“让模型调用函数”，而是把工具调用收进一个安全、可控、可观测的服务端流程。真正成熟的 Tool Calling，一定包括 schema 校验、权限控制、超时、幂等、循环限制、日志和审计。因为工具一旦有了副作用，这就不再是模型体验问题，而是实打实的业务执行问题。很多人会把 Tool Calling 讲成“模型提函数名，系统执行一下”，这太像 demo。更好的说法是：模型只负责提出下一步建议，真正的执行权始终留在服务端。
8. RAG 最重要的是什么¶
不是选一个最炫的向量库，而是把文档处理、切块、召回、过滤、引用、更新和评测做成闭环。RAG 最容易答偏的地方，是把注意力只放在最后那次生成上。其实生成只是尾声，真正决定系统下限的往往是前半段：文档有没有清洗干净，chunk 有没有把语义切散，召回结果有没有权限过滤，引用能不能指回正确版本。只要这条链路没收稳，模型再强也只是在错误材料上合理发挥。
9. AI 应用最关键的线上指标是什么¶
永远不只一个指标。正确率、延迟、成本、可控性、可观测性是最常见的五条主线，但到了具体业务场景，还会进一步落成任务完成率、追问率、人工接管率、工具成功率、引用命中率、单位任务成本这些更贴近业务的指标。真正成熟的回答不是背一串名词，而是让面试官感觉到：你知道这些指标为什么会互相拉扯。比如上下文变长也许能提升一部分正确率，但成本和延迟也会一起上去；多 Agent 也许更灵活，但平均步数和失败点也可能增加。
10. 客户端断开后为什么一定要取消下游调用¶
因为这次请求已经失去用户价值了，再继续跑下去，消耗的只会是系统资源和成本。数据库查询会继续占连接，模型流会继续吐 token，工具调用会继续占用配额，goroutine 也会继续活着。短期看，你会觉得只是“白跑了一会儿”；长期看，这就会变成连接浪费、goroutine 泄漏、成本上升和系统尾延迟变差。所以断连取消从来不是细节，而是服务对资源边界是否敏感的表现。尤其在流式接口里，这一点几乎是必答题。
11. 为什么不能在事务里做长时间外部调用¶
因为事务不是抽象的“原子性盒子”，它背后拿着的是数据库连接，往往还伴随着锁。只要你把长时间网络请求、模型调用、OCR、embedding 这类慢动作塞进事务里，连接和锁就会被白白占住，后面的请求开始排队，吞吐和稳定性都会被拖垮。更稳的做法通常是把事务边界收窄到数据库内部必须同时成功或失败的那几步，把外部调用拆到事务外，必要时再用异步任务、outbox 或幂等键补回一致性。
12. 怎么判断自己是不是只停留在 demo 层¶
最简单的判断方法不是看你做了多少功能，而是看你有没有把工程约束一起做进去。如果项目只有 happy path，没有测试、超时、权限、日志、trace、错误分类、资源释放和评测，那它通常还停留在 demo 层。demo 的特点不是“小”，而是它默认很多现实问题不会发生；真正的系统则恰恰相反，它默认这些问题一定会发生，所以要提前留出抓手。面试时如果你能清楚讲出“我什么时候发现自己不只是做了个 demo”，通常说明你的工程感觉已经开始成形了。
13. 公开高频题型：slice 扩容到底会不会影响原切片¶
公开 Go 面试题很喜欢换着问这个问题，比如“append 后原切片会不会变”“函数里改 slice 为什么外面有时能看到、有时看不到”“slice 是值传递还是引用传递”。这些问法表面不同，背后都在考同一件事：你有没有真正理解 slice 是一个包含指针、长度和容量的描述符。更成熟的回答不是把 slice 粗暴说成“引用类型”，而是先解释共享底层数组和扩容行为，再解释为什么有时修改可见、有时不可见。把这个理解放进真实工程里也很重要，比如 RAG 切块时复用缓冲，如果你没搞清底层数组是否共享，异步处理中很容易把前面已经切好的内容污染掉。
14. 公开高频题型：context 为什么会导致 goroutine 泄漏¶
面试官常常会从“context 有什么用”问起，最后一路追到“为什么不能把 context 放到 struct”“客户端断开后为什么还要继续处理”。真正的考点不是你会不会背 WithTimeout、WithCancel，而是你是否知道取消传播为什么和资源释放绑在一起。只要下游 goroutine、数据库查询、模型流式调用没有接住取消信号，上游结束以后它们就会继续活着。SSE 接口就是最常见的例子：用户页面已经关了，如果 Request.Context() 没有一路传到底层检索和模型调用，系统就会继续白跑。
15. 公开高频题型：sql.DB 到底是什么，连接池参数怎么调¶
这类题看上去像定义题，其实面试官通常在听你会不会把参数和业务负载联系起来。单纯背出 MaxOpenConns、MaxIdleConns、ConnMaxLifetime 的含义价值不大，更重要的是你能不能解释配置错了会怎样。比如 AI 问答系统里，检索请求突然变多，MaxOpenConns 太小会导致应用侧排队；太大又可能把数据库直接压满。能把这些后果讲出来，说明你是真的把连接池当资源管理，而不是在背参数。
16. 公开高频题型：为什么学习时不建议只会 Gin¶
常见问法通常会围绕 Gin 和 net/http 的关系、中间件是怎么工作的、为什么先学标准库再学框架。真正想考的，不是你站哪一派，而是你有没有把 HTTP 请求生命周期、接口抽象和上下文传播想清楚。很多人一答这题就开始做框架横评，这是很容易失分的。更稳的答法是：Gin 完全可以用，但框架没有改变请求生命周期、取消传播和流式响应这些底层事实；如果你连底层模型都没搞清楚，框架只会让你更快写出自己也解释不明白的代码。
17. 公开高频题型：RAG 为什么不准，先查哪里¶
这类题最容易把人带到“是不是模型太差”这个方向上去，实际上更成熟的排查顺序通常是先看文档链路，再看检索链路，最后才看生成。文档有没有清洗干净、切块是不是把条件切散了、过滤有没有做对、rerank 有没有缺失、引用是不是来自错误版本，这些都比 prompt 更值得先查。比如员工问试用期离职提前几天提，系统却答成正式员工规则，问题很可能不是模型胡说，而是切块把试用期例外切散了，或者检索阶段根本没有把文档类型和版本过滤好。
18. 公开高频题型：Tool Calling 和 Agent 怎么防事故¶
常见问法会围绕“模型调错工具怎么办”“工具失败怎么办”“如何避免无限循环”“写操作如何保证安全”。这些问题真正考的是护栏意识。也就是说，你是否知道 schema 是契约、停止条件必须显式定义、写操作必须考虑幂等和权限、人机协同必须在高风险节点进入主路径。最容易答偏的地方，是把答案停在“让模型再试一次”。如果工具本身会退款、发信、关工单，再试一次可能就是事故，不是优化体验。
19. 公开高频题型：MCP 到底解决了什么，没解决什么¶
这类题现在越来越常见，因为很多人一听到 MCP，就容易把它想成“企业工具安全接入的一站式答案”。更好的理解是：MCP 解决的是工具和资源的标准化暴露、发现和调用问题，它让跨语言、跨运行时、跨部署边界的互操作更统一。但它并不替代权限、审计、租户隔离和业务规则。面试时如果你能先把 MCP 放在协议层，再把治理责任拉回服务端，整体成熟度会高很多。
20. 公开高频题型：怎么证明 Agent 改版后真的更好¶
这个问题在考的不是“你有没有主观信心”，而是你有没有评测方法。更靠谱的回答通常会同时讲离线样本集、线上指标、trace 诊断和必要时的 A/B 验证。比如你把单 Agent 改成多 Agent，不能只说“感觉更智能了”，而要看任务完成率有没有提升、平均步数和成本是不是更高、人工接管率有没有下降、失败样本结构有没有变化。只要你能把这些维度讲出来，面试官通常就会觉得你不是在调一个新花样，而是在经营一个可验证的系统。
21. 公开高频题型：什么时候该上 Agent 框架，什么时候老老实实写工作流¶
真正的分界线从来不是“我更喜欢轻量”或者“多 Agent 太重了”，而是流程本身到底有多确定。如果步骤固定、输入输出明确、失败语义清楚，就优先写工作流；只有当系统真的需要模型在多种工具、路径和状态之间做决策，而且团队已经有 trace、评测、审批和恢复能力时，Agent 框架才开始有价值。比如文档入库通常是确定性工作流，而报销助手要在查状态、读制度、判断是否催办、是否需要人工确认之间切换时，才更接近 Agent。
22. 公开高频题型：MCP SDK、FastMCP、普通 HTTP Tool API 怎么选¶
这类题真正考的是你能不能把“协议价值”和“业务复杂度”分开看。如果核心问题是跨客户端、跨服务端、跨语言和跨部署边界的能力暴露与发现，MCP 很值得上；如果只是单服务内部的工具调用，普通 HTTP、gRPC 甚至内部函数往往更直接。官方 SDK 更适合理解协议和做深度控制，高层框架更适合快速原型。一个很实用的判断方式是：你先问自己，你是在解决“接入统一性”，还是只是在解决“本服务内部调用方便不方便”。
23. 公开高频题型：Gin、Chi、Echo、Fiber 怎么比较¶
如果只聊 benchmark，这类题通常就已经答偏了。更成熟的比较方式，是从底层兼容性、上下文语义、中间件模型、绑定与错误处理、性能和心智负担这几条线来讲。Gin 胜在平衡和成熟，Chi 更贴近标准库，Echo 的内建能力更完整，Fiber 则有很鲜明的性能和 Express 风格，但也带来 fasthttp 语义和上下文复用边界。你真正需要让面试官听到的是：你知道不同框架在解决什么问题，也知道它们各自带来的语义约束。
24. 公开高频题型：Kratos、go-kit、Kitex、Hertz 是一类东西吗¶
这类题本身就在考你会不会拆层。更好的回答不是把它们平铺成四选一，而是先说明它们不完全在同一层。Kratos 和 go-kit 更偏服务组织、治理和抽象；Kitex 更偏高性能 RPC；Hertz 更偏高性能 HTTP 和传输层实现。你如果只是做一个面试项目的单服务 HTTP 入口，Kratos、Kitex 这类体系级框架通常不是第一优先；但在企业内部多服务体系里，统一协议、错误、配置和注册发现时，它们的价值就完全不同了。
25. 公开高频题型：OpenAI Agents、LangGraph、PydanticAI 该怎么选¶
这类题特别容易被聊成热度榜，实际上应该按复杂度来源来选。OpenAI Agents 更适合轻量 agent runtime、工具循环、handoff 和 tracing；LangGraph 更适合长任务、图编排、interrupt/resume 和持久状态；PydanticAI 更适合强调类型安全、输出约束、依赖注入和 eval 的 Python 工程体系。真正成熟的回答不是说“我喜欢哪一个”，而是解释团队语言栈、任务是否长生命周期、状态是否复杂、评测和观测基础设施是否已经具备。只要你能按这个维度来讲，答案通常就不会飘。
26. 公开高频题型：什么是 hallucination，为什么会发生，怎么降低¶
更成熟的回答不是一句“模型会胡说”，而是先说明幻觉的本质是“在缺少可靠证据时，模型仍然生成了一个看起来完整的答案”。它可能是编造事实，也可能是错引来源、把旧版规则当新版规则、把工具结果解释偏了。原因通常不只一个模型因素，而是检索质量、上下文完整性、任务说明、结构化约束和后端校验一起决定。降低幻觉最稳的办法，也不是单靠一句“不要编造”，而是优先补证据链：让证据型问题先走检索或工具查询，证据不足时允许回答不知道，输出里显式保留引用和不确定性，再用后端去校验关键字段和引用。
27. 公开高频题型：Prompt Engineering 在工程里究竟是什么¶
它不是写几句漂亮提示词，而是任务设计。你要决定稳定指令放哪，动态上下文从哪来，示例是否需要，输出遵守什么 schema，什么时候该请求工具，什么时候必须拒答或澄清。真正成熟的 Prompt Engineering 一定和评测绑在一起，因为 prompt 一旦进入生产，就不再是个人手感问题，而是一个要版本化、要回归、要能回滚的配置对象。
28. 公开高频题型：system / user / assistant role 有什么作用¶
更稳的理解不是把它们当聊天格式，而是把它们当控制边界。system role 放稳定策略和高优先级规则，user role 放本次需求和外部输入，assistant 或 tool 历史则放模型已经说过什么、工具已经返回什么。把这些边界分开，系统才更容易定位“到底是策略错了、上下文脏了，还是用户问题本来就不明确”。如果全部揉成一段大字符串，排查和治理都会变得很难。
29. 公开高频题型：ChatMemory 和 Agent memory 有什么区别¶
ChatMemory 更像当前会话里给模型看的工作记忆，通常只覆盖最近几轮消息、摘要和当前任务状态。Agent memory 则更广，可以包括长期知识、用户画像、过去执行痕迹和跨任务状态。成熟系统不会把所有 memory 都直接塞进模型上下文，而是把“持久化保存”和“本轮可见”分开处理。这样既能控制成本，也能保持上下文干净。
30. 公开高频题型：ReAct、planning 和普通 workflow 有什么区别¶
工作流适合确定性强、步骤固定的任务；ReAct 适合边查边判断、路径不完全固定的任务；planning 适合长任务和多阶段任务，需要先拆成子目标再执行。它们不是谁更高级，而是谁更匹配当前复杂度。真正成熟的回答一定会补一句代价：ReAct 和 planning 会增加步数、延迟和治理成本，所以不是所有请求都值得上。
31. 公开高频题型：Transformer 核心原理是什么，为什么推理成本高¶
对工程岗位来说，知道 self-attention 是核心就够了。它让模型在处理当前 token 时，可以动态关注上下文中其他位置的信息，所以长文本理解能力明显增强。推理成本高，则主要来自长上下文、长输出、多轮工具循环和重复传输稳定前缀。真正成熟的回答，不会只说“模型单价贵”，而是会把上下文组织方式和请求路径长度一起讲进去。
32. 公开高频题型：上下文窗口是什么，怎么突破长度限制¶
上下文窗口就是这次推理里模型真正能看到的 token 范围，它不是长期记忆，也不是数据库。突破长度限制最稳的路线通常不是盲目换更大窗口模型，而是收回工程控制权：用 RAG 检索替代全量塞文档，用摘要替代全量塞历史，用结构化状态替代重复自然语言，用后台任务处理超长资料。只要能把这几层讲清楚，这题就不会答虚。
33. 公开高频题型：RAG latency 怎么优化¶
先拆耗时，而不是先拍脑袋。一次 RAG 请求至少会经过查询预处理、embedding、召回、rerank、文档抓取、上下文拼接和最终生成。更常见的优化顺序是：先做元数据预过滤，再缩小候选集，关键词和向量检索能并行就并行，embedding 和热门召回结果能缓存就缓存，rerank 只处理真正值得精排的那一小批候选，最后再看模型生成是否还是主要瓶颈。真正有工程味的答案一定会告诉面试官：你知道慢是慢在哪一段，而不是只会说“优化模型”。
34. 公开高频题型：为什么 hybrid search 在企业场景里经常比纯向量更稳¶
因为企业文档里既有语义相近问题，也有大量编号、缩写、岗位等级、产品名、版本号这类需要精确匹配的信号。向量检索擅长语义，关键词检索擅长精确标识，二者结合才更适合真实业务。像 EXP-123、P4、SOC2 这类问题，如果只靠向量，命中经常不够稳。这道题真正想考的，是你有没有把检索看成工程组合，而不是单一算法选型。
35. 公开高频题型：embedding 模型如何选择¶
先看语言和领域匹配，再看维度、成本和延迟，最后看你的主要任务是长文档检索、短问句匹配，还是多语种检索。第一版系统通常不需要追求榜单上最重的模型，能先保证主要语种稳定、召回结果够用、索引成本可控，往往更重要。回答这题时如果你能主动补一句“embedding 选择会反过来影响索引体积、重建成本和查询延迟”，整体就会更像做过工程。
36. 公开高频题型：LLM 服务如何做缓存¶
不要把缓存简单理解成“把答案存起来”。更稳的视角是分层看：完全命中缓存适合高重复、低个性化请求；检索缓存适合热门问题的召回结果和 rerank 结果；embedding 缓存适合稳定文本；稳定 prompt 前缀缓存适合固定系统指令和工具说明。真正难的地方不是“能不能命中”，而是“命中了会不会错”。涉及用户身份、租户、版本、写操作和高时效内容时，缓存边界必须非常谨慎。
37. 公开高频题型：LLM 服务如何做限流和连接管理¶
原则和普通高并发服务类似，只是成本更贵、下游配额更敏感。连接管理上不要每次请求都新建客户端和连接，要复用长期存活的 HTTP client 和 transport；限流上要按用户、租户、模型、接口和并发数多层控制，必要时再区分实时对话和后台任务的优先级。面试里如果你只说“加个限流器”通常还不够，更成熟的回答会把配额、尾延迟、降级和资源池隔离一起讲出来。
38. 公开高频题型：Prompt / Response 为什么要记录，怎么记录才不出事¶
因为没有记录，就很难复盘为什么这次回答错了、这次工具为什么乱调、这次改 prompt 到底影响了什么。但记录也不能等于把所有内容无脑打到日志。更稳的做法是分层记录：稳定记录 prompt 版本、模型、token、耗时、工具调用、引用和错误分类；对完整正文按脱敏、采样、加密和保留期策略处理。这样既能追问题，也不会让敏感数据在日志系统里四处扩散。
39. 公开高频题型：LLM API / SDK 应该怎样设计¶
真正成熟的 SDK 设计，不是把供应商字段一股脑儿暴露给业务层，而是先定义稳定的内部边界，例如同步生成、流式生成、结构化输出、工具调用和取消能力。供应商差异留在 adapter 层，业务层关心的是“我要一条流”“我要一个结构化结果”“我要一个可追踪的工具循环”。这道题背后真正考的是你有没有 provider adapter 心智，以及你会不会把超时、重试、日志字段和模型分级收口到统一地方。
40. 公开高频题型：LangChain4j、Spring AI 这类 Java 生态题，背后到底在考什么¶
这类题表面上在问某个库怎么写 prompt template、怎么返回 JSON、怎么接 Tool Calling，背后真正考的还是通用工程问题：提示模板怎样参数化，结构化输出怎样约束，工具调用怎样做 schema 和权限校验，流式响应怎样处理断连和资源释放，SDK 边界怎样隔离供应商细节。所以你不需要把自己答成 Java 教程，只要能把问题还原成提示管理、输出契约、工具治理、流式接口和适配层设计，答案通常就已经站稳了。
41. 公开高频题型：AI Agent 和普通 ChatBot 有什么区别¶
普通 ChatBot 的核心是“围绕一段对话生成回答”，重点在理解问题和组织语言；AI Agent 的核心则是“围绕一个目标推进执行”，重点在状态、工具、停止条件和副作用控制。前者更像会话接口，后者更像带模型参与决策的执行系统。面试里更成熟的回答，通常会主动补一句：不是所有对话产品都值得做成 Agent，只有当任务真的需要查资料、调工具、分阶段推进或插入审批时，Agent 才开始有意义。
42. 公开高频题型：多 Agent 协作系统应该怎么设计，才不会只是“多开几个角色”¶
多 Agent 真正值得做的前提，是角色边界和工具边界都足够清楚。更稳的做法通常是先定义共享状态，再定义每个 Agent 负责什么决策、能看什么上下文、能用什么工具，最后再定义 handoff 规则、最大轮数、失败回退和人工接管点。比如企业助手里，“资料检索”“业务执行”“合规审核”可以分成三个角色，但共享的仍然应该是同一份任务状态、trace 和审计链路，而不是让三个 Agent 各自自由发挥。真正想考你的，是你会不会把多 Agent 讲成一个受控编排系统，而不是几个会聊天的角色设定。
43. 公开高频题型：streaming response 和 SSE 的关键实现点是什么¶
这类题真正考的通常不是前端能不能边打字边显示，而是后端有没有把长连接当成长生命周期请求来设计。比较成熟的回答会主动讲四件事：为什么单向推流优先考虑 SSE；客户端断开后怎样把取消信号传到底层模型流和工具调用；服务端怎样处理 flush、背压和中途错误；请求结束后怎样释放 goroutine、连接和缓冲区。只要你能把“用户关页面以后，下游为什么也必须停”这层说透，这题基本就站稳了。
44. 公开高频题型：AI Chat 系统整体架构应该怎么拆¶
更稳的拆法通常不是从模型开始，而是从一次会话请求的主链路开始。入口层负责鉴权、限流和会话路由；状态层负责会话摘要、任务状态和历史消息持久化；检索层负责 RAG；模型网关层负责同步、流式、结构化输出和供应商适配；工具运行层负责 schema 校验、权限、超时和审计；观测评测层负责 trace、日志、成本和回归。你如果能把这几层讲清楚，再根据题目决定是否需要 RAG、Tool Calling、后台任务或多 Agent，答案就会非常有工程味。
45. 公开高频题型：对话历史 memory 应该怎么实现¶
不要把它理解成“把所有历史消息都重新发给模型”。更成熟的做法通常是三层结合：完整消息和工具结果持久化在数据库里，最近几轮高相关消息作为短期工作记忆进入本轮上下文，更早历史则被压成摘要或提炼成结构化状态，例如当前单据号、用户偏好、最近一次工具结果。这样做的价值，是把“可追溯的完整历史”和“本轮真正需要的上下文”分开，既保留回放能力，又避免上下文无限膨胀。
46. 公开高频题型：RAG 系统效果应该怎么评估¶
只看主观感觉肯定不够。更稳的做法通常是把评估拆成三层。第一层是检索评估，看关键问题能不能把正确材料召回到前几条候选里；第二层是答案评估，看最终回答是否基于证据、有没有漏掉例外条件、引用是否真实可点开；第三层是线上运行指标，看延迟、成本、追问率、人工接管率和引用命中率有没有变好。面试里如果你能主动补一句“修改 chunk 策略、embedding 模型或 rerank 逻辑以后，我会先跑离线问题集，再看线上 trace 和失败样本”，整体就会非常稳。
47. 公开高频题型：Agent workflow 和普通 workflow 有什么区别¶
普通 workflow 更强调确定步骤和确定分支，适合“上传文档 -> 清洗 -> 切块 -> 向量化”这类确定性流程。Agent workflow 则允许在流程中间由模型决定下一步调用哪个工具、是否需要补资料、是否进入人工确认，所以它多出来的不是“更复杂的图”，而是不确定决策节点。也正因为如此，Agent workflow 一定更依赖状态管理、max step、审计和回放能力；如果这些基础设施没有，很多任务其实更适合老老实实写普通 workflow。
48. 公开高频题型：Prompt 管理系统为什么值得做，应该管什么¶
Prompt 一旦进入生产，它就不再只是开发者本地的一段字符串，而是会持续影响正确率、成本、工具调用路径和用户体验的配置资产。Prompt 管理系统最少应该管四件事：模板与变量、版本与回滚、离线评测结果、上线记录与 trace 关联。这样当你发现某次回答突然变保守、工具调用次数突然上升，才能追到是 prompt 版本变了、模型变了，还是检索上下文变了。没有这层管理，prompt 迟早会散落在代码、数据库和运营配置里，最终谁也说不清哪次改动真正引发了回归。