先搜索一下大厂博客以及现在秋招面经，给我现在agent的八股题并且结合例子进行回答

我按“Agent 应用开发／Agent Infra 秋招岗”整理，不把它混成纯算法岗题库。下面先交代检索到的面经，再给你可以直接练口述的 20 道题，每题结合例子解释。 资料范围说明：搜到了近期秋招面经，其中两篇自述面试时间是 8 月 9 日、8 月 12 日，但正文没有标年份，因此不能把每篇都严格确认成“2026 年面经”。面经是候选人自述，不代表公司的统一题库；下面也会区分“面经实问”和“工程延伸”。 一、这次搜到的面试到底问什么 《字节 AI Agent 开发秋招一面面经》问了：RAG 切分、Token、Transformer、Lost in the Middle、上下文长度、多 Agent 编排、SFT/PPO/DPO/GRPO，以及树相关算法。 《字节 agent 开发一面面经》问了：RAG 项目、AI Coding 质量保障、SSE/WebSocket、数据库索引、高并发榜单，以及两个栈实现队列并追问线程安全。 《字节 app infra agent 开发秋招一面面经》问了：KV Cache、网络请求链路、TCP、MySQL、Redis、分布式 ID、排序。 这几个样本给出的信号是：不能只背 ReAct、MCP、LangGraph。项目设计、模型基础、后端基础和手撕都要准备。 官方资料主要参考 Anthropic 的工具设计、上下文工程、多 Agent 研究系统，以及 2026 年 1 月的 Agent eval 文章；同时参考 OpenAI 的 Agent 实践指南。2025 年文章用于解释基础工程原则，不当成最新模型能力结论。 二、Agent 核心题 第一题：Agent 和 Workflow 有什么区别？什么时候不该用 Agent？ 来源：官方资料延伸。 例子：发票系统固定执行“识别金额→校验税号→入库”，即使识别步骤调用了大模型，也可以只是 Workflow。用户说“调查这个月报销异常”，系统根据查到的记录决定继续查谁、调用什么工具、是否需要补充证据，才体现了 Agent 的动态决策。 口述回答：区别不在调用几次模型，而在执行路径由谁控制。Workflow 主要由代码预定义路径；Agent 由模型结合环境反馈动态选择下一步，但权限和执行边界仍由程序控制。 业务规则明确、流程稳定、错误代价高时，优先使用确定性流程。不要为了简历上出现 Agent，就把普通条件判断换成模型判断。 第二题：ReAct 是什么？Agent loop 怎么实现？ 来源：官方资料延伸。 例子：用户问“订单为什么还没到”。Agent 查订单，发现已发货；再查物流，发现地址异常；最后请求用户确认地址，而不是一开始就编出原因。 口述回答：ReAct 将推理与行动交替进行，模型根据观察结果更新下一步。工程上可以理解为：模型生成回复或工具调用请求，程序校验并执行工具，把结果放回上下文，然后继续调用模型。 循环必须有退出机制：完成任务、需要用户补充信息、达到步数或预算上限、连续失败后转人工。 不需要把模型完整思维链展示出来才能实现 ReAct。真正需要记录的是可观察的工具调用、返回结果、状态变化和错误。 第三题：Function Calling 是模型在执行函数吗？怎么防止乱调？ 来源：官方工具设计延伸。 例子：模型生成 refund_order(order_id="A123" amount=100)，不代表钱已经退了。这只是一个结构化调用请求，真正退款的是后端。 口述回答：模型负责选择工具和生成参数，运行时负责参数解析、Schema 校验、身份鉴权、业务校验和实际执行。 Schema 能检查 amount 是不是数字，但不能证明该用户有权退 A123，也不能证明应退金额就是 100。订单归属、金额计算、退款资格必须在服务端判断。 高风险操作需要必要确认；工具返回也要区分“已提交”“处理中”“已完成”，避免模型把提交成功误说成业务成功。 第四题：工具怎么设计才好用？工具越多越好吗？ 来源：Anthropic 工具设计文章。 例子：给模型一个 execute_sql 工具，让它自己拼表关联，往往不如提供语义明确的查询订单工具。但一个“查询并自动退款”的万能工具又把读取和危险写入绑在一起了。 口述回答：工具应该职责清晰、边界明确，描述包含适用场景、参数语义、限制和失败处理。返回结果应该是决策所需的信息，而不是整个数据库对象。 比如查订单，返回订单号、状态、可退金额和规则依据即可，不应顺手返回不必要的个人信息。 工具数量多会增加选择难度和上下文开销，可以按任务动态加载。是否合并工具，要同时考虑调用效率与权限边界，不能只追求少调用一次。 第五题：MCP 和 Function Calling 有什么区别？ 来源：工程延伸，参考 MCP 官方文档。 例子：公司有文档检索服务，希望不同 Agent 客户端都能接入。可以通过 MCP 提供统一接口，而不是为每个客户端重新写一套集成。 口述回答：Function Calling 是模型输出结构化工具调用请求的机制；MCP 是应用与外部工具、资源等能力之间的标准化交互协议。 它们不是替代关系。应用可以从 MCP Server 获取工具定义，再提供给模型；模型决定调用后，由应用通过 MCP 执行。 MCP 不会自动让模型更会规划，也不会自动解决权限、安全和工具质量问题。 第六题：什么时候用多 Agent？中心化编排有什么优缺点？ 来源：面经实问＋Anthropic 多 Agent 文章。 例子：研究三个国家的新能源政策，可以分给三个研究 Agent，各自检索，再向主 Agent 汇报证据；主 Agent 发现口径冲突后要求补查。若只是改一个小函数，拆成五个 Agent 可能更慢、更贵。 口述回答：适合多 Agent 的任务通常可拆分、可并行，不同子任务需要不同上下文或工具。收益主要是并行探索、上下文隔离和专业分工。 代价是通信、重复劳动、信息损失、共享状态冲突，以及更高的 token 成本。 中心化编排便于统一目标、预算和结果验收，但协调者可能成为瓶颈；去中心化更灵活，却更难处理终止、冲突和责任归属。 单纯同时运行几个互不交流的模型调用，不足以说明做了多 Agent 协作。面试时要说清任务如何委派、结果如何传递、冲突如何处理。 三、RAG 与上下文 第七题：RAG 的 Chunk 怎么切？大小怎么定？ 来源：面经实问。 例子：退款政策写着“七天内可退”，下一段是“定制商品除外”。如果切分把例外条件丢掉，就可能生成错误结论。 口述回答：先按文档结构切分，尽量保留标题、段落、表格和语义完整性，再结合 token 预算设置大小与必要重叠。保留来源、章节、版本、生效时间等元数据。 Chunk 太小容易缺上下文，太大容易引入噪声、稀释匹配信号并增加成本。不能直接背“固定 512 最好”。 可以把几种大小作为实验候选，在同一评测集上比较检索召回、答案正确率和成本。候选参数是实验起点，不是通用最优值。 需要兼顾精准匹配与完整上下文时，可以小块检索，再补充所属父段落。 第八题：向量检索为什么不够？混合检索和 Reranker 分别解决什么？ 来源：面经 RAG 追问延伸，参考微软官方资料。 例子：查询“错误码 E1047”，关键词匹配很重要；查询“设备老是自己重启”，语义检索更容易找到写着“异常重启”的文档。 口述回答：关键词检索擅长精确词项，向量检索擅长语义相似，混合检索结合两者，再通过融合方法合并候选。 Reranker 对查询与候选文档进行更细致的相关性判断，把更合适的内容排在前面，但增加延迟和计算成本。 最关键的边界：正确文档根本没进入候选集，重排救不回来。先检查召回，再检查排序。 第九题：RAG 回答错了，你怎么定位？ 来源：面经项目追问延伸。 例子：用户问今年差旅标准，系统引用了去年的政策。这个问题可能是版本过滤失败，不一定是模型能力不够。 口述回答：沿链路拆开排查：知识库有没有正确文档，解析是否完整，查询是否准确，召回是否命中，排序是否靠前，最终有没有放进上下文，模型有没有正确使用证据。 检索层可以看 Recall@k、MRR 或 nDCG；生成层看事实正确性、证据支持程度和引用准确性。 还可以做一个定位实验：直接把正确材料交给模型。若仍答错，重点查提示和生成；若答对，重点查检索链路。这个实验用于定位，不代表检索问题已经解决。 第十题：Prompt Engineering 和 Context Engineering 有什么区别？ 来源：面经 Context 实问＋Anthropic 上下文文章。 例子：提示词明明要求“按最新政策回答”，但上下文里放了大量旧政策，模型仍可能用错。继续加一句“务必使用最新政策”不一定有效。 口述回答：Prompt Engineering 主要优化指令如何表达；Context Engineering 管理当前推理时模型实际看到的全部信息，包括指令、工具定义、检索结果、历史消息和任务状态。 核心不是把所有资料塞进去，而是把当前决策所需的高信号信息放进去。 实际可以采用按需检索、工具输出裁剪、结构化状态、历史压缩和子任务上下文隔离。 第十一题：上下文爆了怎么办？窗口是不是越大越好？ 来源：面经实问。 例子：代码 Agent 跑了几十轮，上下文主要被旧日志占满，群友 8334“不能修改公共接口”的要求反而被淹没。 口述回答：先减少无用工具输出，对历史做压缩，把目标、约束、已完成事项、失败尝试和待办保存为结构化状态；原始材料留在外部，需要时再检索。 压缩不能只保留“做了什么”，还要保留为什么不能继续某条路径、哪些操作已经执行过，否则容易重复犯错或重复写入。 更大窗口不保证更好：它可能提高成本和延迟，也可能出现长上下文利用能力下降。Lost in the Middle 描述的是相关信息处在长上下文中间时，某些模型和任务上的利用效果较差，不是“中间内容必然看不到”。 另外，“支持多少 token”和“在这么长的输入上仍可靠”是两回事。 第十二题：Agent 的记忆怎么设计？ 来源：官方上下文文章延伸。 例子：用户长期偏好中文回答，可以作为偏好保存；某次退款正在等待确认，是任务状态；退款政策属于外部知识。这三类信息不应混成一份聊天摘要。 口述回答：区分会话上下文、任务状态、长期偏好和外部知识，分别选择存储与读取方式。 任务状态通常适合结构化持久化；长期记忆需要来源、时间、更新和删除机制。不是每句话都值得长期保存，也不是全部记忆都需要向量数据库。 涉及用户信息，还要做用户隔离、访问控制和过期管理，不能