Agent 核心篇

对应课件：agent核心/07-15。Agent 是当前 AI 应用岗的核心差异化考点——面试官想确认你不是"跑通了 Demo"，而是理解它为什么这样运转、在哪里会失控、怎么让它值得托付。本篇 11 题覆盖从协议到多 Agent 实现的完整链路。

---

Q01 · Tool Calling 的原理是什么？模型真的"执行"了函数吗？

难度：★★★★ ｜ 频率：极高 ｜ 对应课件：agent核心/07

面试官：你说你做过 Agent，那 Tool Calling 底层是怎么实现的？模型真的会执行你的函数吗？

第 1 层追问：模型不执行任何东西

先纠正一个最常见的误解。

参考回答：模型从不执行任何函数。它做的只是输出一段结构化的"调用意向"——函数名 + 参数值的文本；真正的执行发生在你的代码里。完整闭环是四步：你的 SDK 把 tools 定义发给模型 → 模型返回 tool_calls（调用意向）→ 你的程序执行对应函数 → 把结果作为 tool 角色消息回传，模型再基于结果继续。理解这一点的工程意义：安全边界在你手里——模型只能"请求"，批不批、怎么执行、结果给不给，全是你的代码说了算。

第 2 层追问：协议背后的机制

那模型是怎么"学会"发出这种调用意向的？

参考回答：剥开工业包装，tool calling 是三样老朋友拼装，没有任何新魔法。注入：SDK 把 tools 定义序列化成文本（类似一段"可用函数列表"的说明）拼进输入——本质上和你在 system prompt 里手写"你有以下工具可用"没有区别。生成：模型经过后训练（SFT/RLHF）专门训练过"见到工具列表 + 合适的用户请求时，输出调用格式的文本"。解析：推理服务把这段特殊文本解析成结构化的 tool_calls 对象返回。所以它可靠性不错，但仍是概率行为——可能不调该调的工具、编造不存在的参数值、给格式错误的参数，应用层必须校验 + 兜底。

第 3 层追问：tool_choice 能干什么？

有什么手段控制模型的调用行为？

参考回答：tool_choice 控制调用倾向，四档："auto"（默认）模型自行决定调不调、调哪个；"none" 禁止调用，纯对话；"required" 强制至少调一个；指定具体函数——强制模型把自然语言填进某个 schema。最后这档特别实用：强制调用一个"信息提取器"函数，等于一个"自然语言 → 结构化数据"的转换器，比如从用户的话里抽 {城市, 日期}，这是结构化输出的另一条实现路径。

第 4 层追问：并行调用怎么回事？

用户问"北京和上海今天哪个适合跑步"，模型会怎么调天气工具？

参考回答：现代模型支持一次返回多个 tool_calls——两个 get_weather（北京、上海）在同一条回复里。协议要求每个 tool_call 都要有对应的一条 tool 消息回传，靠 tool_call_id 配对；执行侧可以并发（两个天气查询同时发）。工程要点：并发执行时结果必须按 id 对号入座回填，顺序可以乱、配对不能错；且回传时一条都不能少——缺一条 tool 消息，下一次请求直接报协议错误。

考察意图与踩坑点

• 考察意图：这题是 Agent 面试的"试金石"。第 1 层答不出"模型不执行"这半句，后面所有 Agent 问题都会被面试官在心里降档。
• 踩坑点：说"模型执行了函数，把结果返回给我"——方向反了；不知道 tool_calls 可能是多个、tool 消息要按 id 一一对应。
• 一句话总结：模型只发"调用意向"，执行永远在你的代码里——注入、生成、解析三步拼装，概率行为必须校验兜底。

---

Q02 · 讲讲 ReAct。它和普通的"链式调用"差在哪？

难度：★★★ ｜ 频率：高 ｜ 对应课件：agent核心/08

面试官：Agent 的经典模式是 ReAct。说说它是什么，为什么需要它？

第 1 层追问：思想本身

用一句话说清 ReAct 的洞察。

参考回答：ReAct = Reasoning + Acting，核心洞察是：把"行动"插入"思考"之间。传统一次性回答里，模型必须在不掌握任何新信息的情况下直接推理出答案；ReAct 让模型先想"我需要什么信息"→ 调工具拿 → 看结果再想下一步 → 循环，直到信息足够才给最终答案。边收集信息边推理，而不是"闭卷猜完再交卷"。这个词也是 Agent 行为自主性的思想源头。

第 2 层追问：和链式调用（Chain）的本质区别

我用 LangChain 拼一条链不也能调工具吗？

参考回答：区别在控制流由谁决定。链是你写死的流程：先 A 后 B 再 C，编译期固定，不管输入是什么都走同一条路。ReAct Agent 是模型在运行时决定下一步调什么、调几次、什么时候停——控制流是模型根据中间结果动态选的。所以选型标准很清晰：步骤能预先确定的用链（便宜、可预测、好调试），步骤取决于中间结果的开放式任务才用 Agent（"帮我调研 X"——要搜几次、读几页，事先不知道）。

第 3 层追问：代价是什么？

动态控制流的代价呢？

参考回答：三个代价，答不出这个说明没实战过。延迟和成本：每一轮"思考 + 调用"都是一次完整 LLM 请求，一个任务跑十几轮很正常，token 烧得飞快。不可预测性：模型可能选错工具、绕远路、陷入循环——所以必须有终止闸门（下一题的主题）。难测试：链可以单元测试每个环节，Agent 的执行路径是动态的，只能靠端到端评测 + 轨迹分析。这也是"能用链解决就别上 Agent"的行业共识来源：Agent 的灵活性是用可控性换的。

考察意图与踩坑点

• 考察意图：考"链 vs Agent"的选型判断——这是课程反复强调的主线（能用固定链解决的别上 Agent），也是团队里真实的设计争论。
• 踩坑点：把 ReAct 背成"推理和行动结合"的名词解释，说不出和链的控制流差异；什么都想上 Agent，暴露没被成本毒打过。
• 一句话总结：行动插入思考之间，边收集边推理；链是写死的流程，Agent 是运行时的决策——灵活性拿可控性换的。

---

Q03 · 你的 Agent 陷入死循环怎么办？

难度：★★★★ ｜ 频率：极高 ｜ 对应课件：agent核心/08

面试官：Agent 的 while 循环里模型反复调同一个工具停不下来，你见过吗？怎么防？

第 1 层追问：先描述现象

死循环长什么样？

参考回答：两种典型形态，见一次就认识。形态一"鬼打墙"：search["qwen3 发布时间"] → 结果不满意 → search["qwen3 发布时间"] → ……同参数反复调同一工具，模型"卡带"了。形态二"打乒乓"：read_file[a] → read_file[b] → read_file[a] → read_file[b]……在两个状态间横跳。共同点：while True 没有出口，程序永久卡死并持续烧 token——最小可用的 Agent 主循环（"反复调用模型，直到不再请求工具"）有个致命缺陷：唯一的正常出口是模型自己不再要工具，模型失控时没有任何保险。

第 2 层追问：防护机制

生产级 Agent 怎么设计出口？

参考回答：四道独立的终止闸门，缺一不可：自然终止——模型不再发起 tool_calls（唯一正常出口）；轮次上限——循环次数 ≥ max_rounds 直接停，防死循环和反复横跳；token 预算——累计消耗 ≥ budget 停，防成本失控；重复检测——连续 N 次调用完全相同（函数名 + 参数哈希）判定卡带，强制中断。四道闸门防的是不同故障：轮次防"次数多"，预算防"单轮贵"，重复检测专治"卡带"。

第 3 层追问：触发闸门之后呢？

闸门拦住了，然后呢？直接给用户报错吗？

参考回答：拦截只是止损，还得优雅降级。方案按场景选：一，带上已收集的信息总结——"我查了 N 轮，目前了解到……但未能完全确认"，比裸报错体验好得多；二，注入"纠偏提示"再给一次机会——把"你已连续 3 次用相同参数调用同一工具，请换一个查询词或改变策略"写进上下文，很多循环一次纠偏就解开；三，换路径——降级为不用 Agent 的固定流程兜底。同时把触发事件记进日志和指标——闸门触发率本身就是重要的可观测信号，突然升高说明行为层在退化。

第 4 层追问：能不能从根上减少死循环？

与其事后拦，怎么事前防？

参考回答：三个源头手段。一，提示词层面：系统提示词里写明"如果连续两次搜索结果不理想，请更换关键词或放弃该方向"——给模型"承认失败"的合法出口，很多死循环是模型不知道"可以放弃"。二，工具返回值层面：工具结果里带引导信息（"没有找到结果，建议尝试 XXX"），返回空字符串是诱发循环的最佳方式。三，工具设计层面：参数 schema 清晰、工具粒度小，模型选错工具的概率自然低——工具设计是行为质量的上游。

考察意图与踩坑点

• 考察意图：这是 Agent 工程化的必答题——课程把"四道闸门"作为生产级 Agent 的分界线，面试官同样把它当"Demo 与生产"的分界线。
• 踩坑点：只答"加个 max 轮次"（四道闸门只答出一道）；说"把 temperature 调低就行"——采样参数解决不了行为层失控；不知道触发后的降级处理，只会拦不会收尾。
• 一句话总结：四道闸门——自然终止、轮次、预算、重复检测；拦截后要总结降级 + 纠偏重试，触发率要进指标。

---

Q04 · 什么任务该用 Agent？什么任务不该？

难度：★★★ ｜ 频率：高 ｜ 对应课件：agent核心/08、LangChain指南/11

面试官：团队里有人什么任务都想套 Agent。你怎么判断一个任务该不该用 Agent？

第 1 层追问：判断标准

给一个你能守住的标准。

参考回答：一句话标准：步骤能不能事先写死。任务流程固定、输入输出明确（翻译、摘要、固定格式抽取）——用链/工作流，便宜、稳定、可测试。任务步骤取决于中间结果、路径无法预知（开放调研、多源数据核实、需要"看情况"的决策）——用 Agent，让模型在运行时决定控制流。中间地带的默认倾向：先用链，链解决不了再升 Agent——成本和可控性的差价摆在那里。

第 2 层追问：判断的量化依据

"步骤写不死"太主观，有没有更硬的信号？

参考回答：四个硬信号，命中越多越该用 Agent。一，分支不可枚举：if-else 写不全合法路径（用户问题的下一条动作取决于上一轮工具返回了什么）。二，需要多轮工具：答案依赖 ≥ 2 次有依赖关系的调用（先查 ID 再查详情）。三，失败要重试换路：A 方案不行要自动换 B 方案，重试逻辑本身就是决策。四，任务目标明确但路径开放："给我 Y 的可信结论"目标清晰，"怎么查"开放。反过来，凡是单次调用能解决、路径唯一、不需要看中间结果的，Agent 是纯开销。

第 3 层追问：混合形态呢？

真实系统一般是纯链或纯 Agent 吗？

参考回答：不是，生产系统几乎都是混合体。典型形态：外层链 + 局部 Agent——主流程用固定图编排（LangGraph），其中某个节点放一个 Agent 处理开放子任务，做完回到主流程。例如客服系统：意图分类（链）→ 查订单（固定工具调用）→ 复杂投诉处理（Agent 子图）→ 汇总回复（链）。另一种是Agent 内嵌链：Agent 的某个工具本身就是一条预处理链。判断粒度从"整个系统"细化到"每个环节"，这才是课程说的"循环、图与骨架工程"（Loop/Graph/Harness）的实际用法。

考察意图与踩坑点

• 考察意图：考工程判断力。这题没有标准答案，但"什么都能上 Agent"和"Agent 没用"两个极端都是减分项。
• 踩坑点：说不出"步骤能否预先确定"这个核心判据；不知道混合形态，只会"全链或全 Agent"的二选一。
• 一句话总结：步骤能写死用链、写不死才上 Agent；四个硬信号（分支、多轮依赖、换路重试、目标明路径开）；生产系统是图里嵌 Agent。

---

Q05 · 怎么设计一个好用的工具？工具越多越好吗？

难度：★★★ ｜ 频率：高 ｜ 对应课件：agent核心/07、09

面试官：Agent 好不好用，工具设计占一半。你会怎么设计工具？是不是工具给得越多越强？

第 1 层追问：好工具的特征

一个"好工具"长什么样？

参考回答：四个特征。一，单一职责、粒度小：一个工具做一件事——web_search(query) 和 read_webpage(url) 分开，比一个"搜索并总结网页"的大杂烩强。二，参数 schema 清晰：参数名自解释、类型明确、枚举值封闭，description 写清"什么时候用我、参数怎么填"——这段说明就是模型的"工具说明书"。三，返回结构化、带引导：返回 JSON 带状态和摘要，失败时给出"建议尝试 XXX"，绝不返回空字符串。四，幂等且安全：查询类天然幂等；写操作要可校验、可回滚。

第 2 层追问：小工具组合为什么优于大而全？

为什么拆小？给模型少一点的工具不是更简单吗？

参考回答：因为模型是按"说明书"选工具的概率系统。大而全的工具参数多、行为分支多，模型填错参数的概率随参数数上升；小工具各自描述精准，选择空间小、命中率高。组合性还带来行为涌现：DeepResearch Agent 只有 web_search 和 read_webpage 两个小工具，模型自己发展出"并行发起多个搜索 → 筛选 URL 精读 → 对比多方信息"的策略——策略是模型在运行时组合出来的，不是你写死的。工具越正交，组合空间越大。

第 3 层追问：那工具数量呢？

到底挂多少个工具合适？

参考回答：少而精，并且按需加载。工具的 schema 每轮都注入上下文：token 成本随工具数线性涨，且工具越多模型选错的概率越高（注意力稀释在几十份说明书上）。实践上限：核心循环里挂 5-10 个以内；更多工具时分而治之——按任务域拆成多个 Agent/子图，各挂各的工具；或者用渐进式披露：主上下文只放工具目录（一行一个），模型用到时再展开完整说明。这就是课程里 Skill 机制解决的问题：让工具/能力的"说明书"也变成按需检索的资源。

考察意图与踩坑点

• 考察意图：工具设计是"用 Agent 的人"和"做 Agent 的人"的分水岭——做过的人都有"改一行工具描述，行为质量立变"的体感。
• 踩坑点：说"工具越多能力越强"；工具返回纯字符串且失败时返回空；参数设计成一个大 dict 什么都能塞。
• 一句话总结：单一职责、schema 清晰、返回带引导；小工具正交组合出涌现策略；核心循环 5-10 个，多了上渐进式披露。

---

Q06 · MCP 是什么？和直接写函数有什么区别？什么时候用 Skill / 多 Agent？

难度：★★★★ ｜ 频率：高（区分度极高）｜ 对应课件：agent核心/10-12

面试官：现在都在聊 MCP。它解决什么问题？你自己的工具函数直接写不就完了，为什么要套一层协议？

第 1 层追问：MCP 解决什么

先说 MCP 的定位。

参考回答：MCP（Model Context Protocol）是把"能力供给"和"Agent 本体"解耦的开放协议。没有它，每个工具都和你的 Agent 代码锁死：工具要用特定 SDK 注册、换框架全重写、别人的工具拿过来不能直接用。MCP 定义了 Server（能力提供方）↔ Client（Agent 侧连接器） 的标准协议：文件系统、数据库、GitHub 都有现成 MCP Server，你的 Agent 作为 Client 接上就能用——工具从"我写的函数"变成"即插即用的生态组件"。类比 USB：定义一个通用接口，设备和主机自由组合。

第 2 层追问：和自己写函数的真实差别

那我自己注册工具和接 MCP Server，实际差在哪？

参考回答：三个实际差别。一，复用边界：自写函数只在你的进程里；MCP Server 是独立进程/服务，一次实现、任何支持 MCP 的客户端都能用（Claude、Cursor、你的自研 Agent 共享同一个工具服务）。二，维护解耦：工具升级由 Server 方独立发布，Agent 侧不动代码。三，成本：多一层协议交互（进程间/网络通信），简单场景纯属开销——所以选型不是"越标准越好"：自己项目里两三个私有工具，直接写函数最简；要接入生态或对外提供能力，MCP 才是正解。

第 3 层追问：Skill 和多 Agent 又怎么选？

需要扩展能力时，Skill、MCP、多 Agent 怎么选？

参考回答：三者的扩展维度不同，按"扩展什么"选。扩展"知识/操作手册" → Skill：SKILL.md 文档 + 按需加载（渐进式披露），把"怎么做某类任务"的说明书做成可检索资源，主上下文只留目录——解决提示词膨胀。扩展"执行能力" → MCP：接外部系统（数据库、浏览器、第三方服务）。扩展"并行与隔离" → 多 Agent/子代理：任务分解成子任务，各子代理有独立上下文和工具集，干完汇总——解决单 Agent 上下文过载和"一人干所有事"的职责混乱。真实系统三者叠加：主 Agent 按任务调 Skill 手册、连 MCP 工具、把大子任务派给子代理。

第 4 层追问：多 Agent 的代价？

子代理听起来很美，代价呢？

参考回答：三个代价，答不出说明只在纸面上见过多 Agent。一，成本放大：每个子代理独立带上下文跑完整循环，N 个子代理 ≈ N 倍 token。二，协调误差：任务分解错了、子结果合并错了，错误在代理间传递放大——"编辑部"模式（一个 agent 负责分派和汇总）能收敛但多一跳延迟。三，调试复杂度跳级：单 Agent 看一条轨迹，多 Agent 要看 N 条轨迹 + 交互记录。所以课程的选型策略是：先单 Agent + 好工具；上下文塞不下或需要真并行（如多路调研）才上多 Agent。

考察意图与踩坑点

• 考察意图：这题是 2025-2026 年面试的热门区分题——MCP 人人在谈，能讲清"何时不用"的候选人极少。第 3 层的三维选型框架是本课程的招牌框架，答出即差异化。
• 踩坑点：把 MCP 说成"工具商店"或"模型"——它是协议；"全上 MCP"或"全不用 MCP"两个极端；把多 Agent 当默认架构炫技。
• 一句话总结：知识扩展用 Skill、能力扩展用 MCP、并行隔离用多 Agent——先问"扩展什么"，再问"用什么"。

---

Q07 · 上下文工程是什么？和提示词工程什么关系？

难度：★★★★ ｜ 频率：高 ｜ 对应课件：agent核心/13

面试官：常听说"上下文工程是新的提示词工程"。你怎么理解这两者的关系？

第 1 层追问：概念升级的原因

为什么会有这个说法？

参考回答：因为 Agent 时代的上下文是动态的。提示词工程的经典场景是单轮静态：一条提示词调到最优就完事。Agent 的上下文是每个运行轮次都在变化的复合体：系统提示词 + 工具定义 + 历史消息 + 工具返回结果 + 检索材料——每一项都动态进进出出。上下文工程处理的是这个动态预算的分配问题：有限的窗口里，每轮放什么、挤掉什么、怎么压缩。一句话：提示词工程优化"怎么说一句话"，上下文工程管理"整个会话里都装着什么"。

第 2 层追问：具体做什么？

上下文工程在实操上有哪些手段？

参考回答：四个方向的工具箱。一，预算分配：给各组成部分设额度（工具定义 X token、历史 Y token、材料 Z token），超了先砍谁要有预设优先级——系统提示词和关键约束最后砍，工具返回的原始大文本最先压。二，压缩：工具返回值截断/摘要（网页全文 → 关键段）、历史消息定期摘要。三，结构化布局：稳定内容放前缀（吃 KV Cache）、关键指令放首尾（对抗 lost in the middle）、用分隔符把材料围起来。四，按需加载：Skill 的渐进式披露、RAG 的检索——上下文里只放当下需要的，能检索到的不常驻。

第 3 层追问：一个综合例子

拿你的 DeepResearch Agent 举例，上下文工程体现在哪？

参考回答：三个具体设计。一，工具返回截断：read_webpage 只回传清洗后的正文关键部分，不把原始 HTML 塞进上下文——网页全文几万 token，塞三页就爆窗。二，系统提示词定预算规则：明确"搜索结果不足时换关键词，最多 N 轮"——把终止策略写进上下文的稳定前缀。三，历史裁剪：长调研任务里，已处理完的中间轮次（搜索结果原文）压缩成结论性短句，保留"查过什么、结论是什么"，丢掉原文细节。整个 Agent 能跑多深的任务，上下文管理比模型能力更早成为瓶颈。

考察意图与踩坑点

• 考察意图：这是从"会用 Agent"到"懂 Agent 工程学"的分界概念，也是课程的核心主张之一。能讲出"预算 + 压缩 + 按需加载"三板斧即过关。
• 踩坑点：把上下文工程说成"提示词写长一点"；只谈概念给不出一个具体例子（说明没实操过）。
• 一句话总结：提示词工程管一句话怎么说，上下文工程管整个窗口里装什么——预算分配、压缩、按需加载三件套。

---

Q08 · Agent 上线前怎么评测？上线后怎么知道它健康？

难度：★★★★ ｜ 频率：中（答好极加分）｜ 对应课件：agent核心/15

面试官：Agent 的行为是概率性的，你怎么评测它？上线后又盯什么指标？

第 1 层追问：上线前的评测

评测怎么做？

参考回答：三层评测金字塔。一，端到端任务评测：构造任务集（含目标 + 必要的环境/工具桩），跑完看任务成功率——最核心但最贵的指标，要人工或 LLM 裁判判分。二，轨迹评测：不只看结果，看路径——工具选择对不对、轮次合理吗、有没有死循环/无效调用。结果对但绕了 15 轮，是"运气好"不是"可靠"。三，行为边界测试：越权测试（诱导它调不该调的写操作）、拒答测试、闸门触发测试。因为行为是概率性的，每题要跑多次看稳定性（同任务 5 次成功 4 次 = 80% 成功率，不是"能跑通"）。

第 2 层追问：上线后盯什么？

线上监控看哪些数？

参考回答：四组信号。一，成本与延迟：每任务平均 token 消耗、轮次数、端到端时延、P99——token 成本是 Agent 的"心跳监测"。二，闸门触发率：轮次上限触发率、重复检测触发率——突然升高 = 行为退化最灵敏的信号。三，结果质量代理指标：用户采纳率（点了引用/复制了结果）、人工抽查评分、失败案例自动聚类。四，安全事件：写操作频率、权限校验拦截数。配套动作：全量轨迹落日志（课程里的"事件轨迹"调试法：从轨迹定位是工具层、行为层还是引擎层的问题）+ 每周抽失败轨迹复盘。

第 3 层追问：评测和线上的差距怎么处理？

评测集上 90 分，线上用户还是骂，为什么？

参考回答：三个真实的 gap。一，分布偏移：评测题是合成的，用户的真实问题更刁钻、更口语、更多歧义——所以要用线上真实失败案例回流评测集，持续换血。二，环境差异：评测时工具桩是理想返回，线上 API 会超时、返回脏数据、格式漂移——评测要注入故障（工具超时、返回空）看 Agent 的鲁棒性。三，单点 vs 长会话：单任务成功率 90%，十步流程的端到端成功率可能只剩 35%——概率连乘的残酷，这也是为什么多步任务要设计"步间校验"而不是指望每步都稳。评测的结论永远是下限，不是上线后的真实表现。

考察意图与踩坑点

• 考察意图：评测与可观测是把 Agent 从 Demo 推向生产的能力证明——团队招人时"能不能独立守一个 Agent 服务"就看这题。
• 踩坑点：只答"让 GPT 打个分"；不知道轨迹评测和闸门指标；没意识到概率系统的成功率要多次运行才成立。
• 一句话总结：评测三层（任务成功率、轨迹质量、行为边界）+ 线上四组信号（成本、闸门触发率、质量代理、安全）——轨迹日志是调试的眼睛。

---

Q09 · Agent 的记忆怎么设计？"把历史全塞进上下文"为什么不行？

难度：★★★★ ｜ 频率：高 ｜ 对应课件：agent核心/13、LangChain指南（记忆章节）

面试官：用户和 Agent 聊了五十轮，下个月回来接着聊。你的记忆方案是什么？直接把历史全塞进上下文不行吗？

第 1 层追问：全量塞历史为什么不行

先说最朴素方案的死穴。

参考回答：三个硬伤。成本：多轮 Agent 每次请求都携带全量历史，token 消耗随轮数线性涨——五十轮长会话的账单是灾难级的。注意力稀释：老对话挤占窗口，相关内容被冲淡，存在 lost in the middle 现象——塞得越多，模型对关键信息的利用率反而下降。上限：再大的窗口也有边界，长任务（几十轮 + 每轮工具返回大块内容）必然撞墙。所以记忆系统的目标不是"存得多"，而是在有限的上下文预算里，放当下最有用的信息。

第 2 层追问：那记忆怎么分层？

具体方案是什么？

参考回答：经典三层结构。工作记忆：当前上下文窗口内的内容——近期消息 + 当前任务状态，是最直接的"思考现场"。短期记忆（会话级）：本会话的完整历史，超出窗口的部分做滑动窗口 + 摘要压缩——老对话压成一段摘要，近期对话保留原文（LangChain 里就是 summary buffer 的思路：预算内保原文，超了就摘要）。长期记忆（跨会话）：外部存储，又分两类——情景记忆（历史对话和事件，向量化后按需检索）与画像/事实记忆（用户偏好、关键事实，结构化存储、可编辑）。核心思想一句话：上下文窗口只是缓存，真正的记忆在外部存储，按需加载——这和上下文工程的"预算分配、按需加载"是同一套哲学。

第 3 层追问：长期记忆怎么写、怎么读？

具体的读写机制？

参考回答：写入：不是每轮都写——在对话结束或任务里程碑时，用 LLM 抽取"值得记住的事实"（偏好、约束、结论），去重合并后落库。读取：当前问题先检索相关记忆（语义检索），命中才注入，且控制注入条数预算——记忆是"检索来的上下文"，和 RAG 同构。更新与遗忘：新事实和旧事实冲突时以新为准并保留时间戳；过期信息设 TTL；被证伪的记忆要能删除。

第 4 层追问：记忆系统的坑？

这套方案会出什么问题？

参考回答：三个真坑。记忆污染：一句错误信息（用户口误、模型幻觉）被固化进长期记忆，之后永远影响输出——所以记忆必须可查看、可编辑、可清空，用户对自己的记忆有控制权（这也是隐私合规要求）。检索噪声：记忆库大了以后，注入不相关的旧记忆比不注入更糟——它会误导当前判断。评估难：记忆系统的好坏标准是"该想起的想得起、该忘的别捣乱"——要专门构造"需要跨会话回忆"的测试用例来验证。

考察意图与踩坑点

• 考察意图：记忆是"上下文工程"的延伸考题，考察能否把 RAG 的检索思维迁移到记忆设计上——这是知识迁移能力的直接证明。
• 踩坑点：只会说"存数据库里"；分不清"存了"和"检索得到且用得上"；不知道记忆污染和合规问题。
• 一句话总结：窗口是缓存、外部存储是记忆、检索是读取——该想起的想得起，该忘的别捣乱。

---

Q10 · 为什么用 LangChain/LangGraph？自己裸写不行吗？

难度：★★★ ｜ 频率：高（转行者几乎必被问）｜ 对应课件：全套框架课程

面试官：我看你项目全是用 LangChain 做的。这些框架不就是包了一层 API 吗？自己裸写不行吗？

第 1 层追问：先表态

直接回答：要不要用框架？

参考回答：用，但有明确边界。框架的价值不在"能调模型"——调 API 谁都会。价值在工程化配套：统一的抽象层（模型/工具/记忆/检索可替换）、流式输出、结构化输出校验、LangGraph 的状态管理与持久化。这些能力裸写不是不行，是重复造轮子——每个都是周级工作量，而且是容易写出 bug 的那种。

第 2 层追问：框架具体帮你省了什么？

说得具体点。

参考回答：四类。抽象层：换模型、换嵌入模型不用改业务代码——供应商锁定风险直接对冲掉。运行时能力：LCEL 的流式、重试、并发批处理，都是管道级别的一行接入。编排与状态：LangGraph 的图编排 + Checkpointer（断点恢复、人在回路、时间旅行调试）——这是裸写最容易翻车的地方，Agent 跑到第 8 轮崩了，没有 checkpoint 就只能从头再来。生态集成：几百个 loader、向量库、工具的现成适配，接 Milvus 还是接 Pinecone 是配置问题不是开发问题。

第 3 层追问：框架的代价呢？

世上没有免费午餐。

参考回答：三个代价要诚实说。抽象税：简单场景被套上复杂抽象，调试时抽象泄漏——报错栈穿过框架层，定位问题的成本变高。版本动荡：LangChain 迭代快，API 变动频繁，升级是真实的维护成本。文档碎片化：集成度高意味着文档覆盖不均，很多坑要读源码才能解决。对应的纪律是：把框架当"库"用，别当"架构"服从——业务核心逻辑保持独立、可测试，别让流程的可读性散在链的隐式拼接里。

第 4 层追问：什么场景你不会用框架？

举反例证明你不是框架的俘虏。

参考回答：单次调用、无状态、不需要流式的脚本——一个 httpx 直接调 OpenAI SDK 更快、更透明、零抽象税。判断标准我总结成一条：需要"编排、状态、流式、集成"中的两项以上，框架收益才为正；只占一项，裸写。另外面试时能讲出框架的源码级机制（LCEL 的 Runnable 协议、LangGraph 的 superstep 调度），本身就是"不是黑盒使用者"的证明——这是这道题的隐藏得分点。

考察意图与踩坑点

• 考察意图：面试官在筛"框架的俘虏"——只会用不懂为什么用的人，换个框架就废了。答出"价值在工程化配套而非模型调用"这条主线就赢了大半。
• 踩坑点：无脑吹框架（"不用框架写不了"）或无脑贬（"就是套壳"）都是减分项；说不出自己裸写时要付出什么，等于没用过裸写方式。
• 一句话总结：框架的价值是编排、状态、流式、集成这四件工程苦役——占两项以上才值得用，且永远当库用、别当架构服从。

---

Q11 · 多 Agent 系统怎么设计？子代理和普通工具有什么本质区别？

难度：★★★★ ｜ 频率：高（2026 热点）｜ 对应课件：agent核心/12、langgraph框架指南/10

面试官：任务太大单 Agent 吃不消，你会拆成多 Agent。怎么拆？子代理和你注册的普通工具函数，本质区别在哪？

第 1 层追问：什么时候才值得拆

先说：什么信号说明该拆了？

参考回答：三堵墙，撞上至少一面才值得拆。墙一，上下文污染：长任务的 messages 里堆满已无用的中间工具结果，注意力被稀释、质量肉眼可见下降——裁剪只能缓解，因为"哪些还有用"很难判断。墙二，串行低速：主循环一步接一步，两个毫无依赖的子任务也只能排队。墙三，职责混杂：一个 Agent 又写代码又查资料又排版，系统提示词塞满互相打架的指令。子代理对三堵墙各有一剂药：干净上下文（治墙一）、可并行（治墙二）、提示词专一（治墙三）。判断口诀：上下文脏了、可并行了、职责真多了——三者至少占一才拆。短会话硬拆只会让任务描述变复杂，分而治之的成本就藏在"任务描述必须自包含"里。

第 2 层追问：子代理和工具的本质关系

你说拆成子代理——它和我注册一个普通函数工具，差在哪？

参考回答：心智模型一句话：子代理就是"返回字符串的高级工具"——输入是任务描述，输出是执行结果，接口和普通工具完全同构（calculate("...") → "60" 和 run_sub_agent("调研XX") → "要点+来源" 没有本质差异）。所以实现上可以把子代理包装成 Tool 注册进工具表，主代理不需要知道这个工具背后是函数还是一整个 Agent——分而治之不需要发明新机制，复用现有的一切。和普通工具的差异只有两点，都源于它是"活的"：执行时长（内部要跑若干轮循环，秒到分钟级）、内部状态（有自己的 messages、工具集、系统提示词）。这个同构视角是架构保持干净的关键。

第 3 层追问：怎么实现？

说下具体结构。

参考回答：三层结构。一，岗位说明书（SubAgentSpec）：每个子代理一份配置——专一职责的系统提示词、只装配职责内的工具（工具是负债）、更小的轮次预算（小任务不需要大预算）。二，工具包装：把子代理包成 run_sub_agent(task) 工具，关键设计是每次调用都创建全新实例——不复用，保证上下文绝对干净（脏上下文是墙一的病根，复用等于带病上岗）。三，主代理组装：主代理是"项目经理"——拆解任务、委派、汇总；委派的任务描述必须自包含（子代理看不到主代理的任何历史，缺背景就会瞎做——这是子代理系统的第一大翻车点，要在工具 description 里反复强调）。并行收益直观：主代理一次 tool_calls 发出多个子代理调用，执行层并发跑；且主代理上下文里只有子代理的最终结果（几百 token），不是内部完整轮转（可能上万 token）——上下文隔离的直接收益。

第 4 层追问：工程上有哪些坑？

多 Agent 上生产，要注意什么？

参考回答：五个要点，全是真坑。① 结果契约：子代理返回自由文本，主代理要再消费——子代理的系统提示词里要规定输出结构（如"结论/要点/来源"三段式），代理间通信也该有 schema。② 预算乘法：子代理是 token 黑洞，主代理轮次 × 子代理轮次是最坏情况的乘法关系——必须给子代理更小的预算并计入总账（token 闸门要扩展成"含子代理的总账"）。③ 观测级联：子代理的事件要向上转发，否则调试时主代理只显示"调用了子代理，10 分钟后返回"，中间一片漆黑——trace 必须跨代理层级连续。④ 失败传播：子代理达到轮次上限返回"（未完成）"时，把失败设计成可被主代理理解的结果而不是异常——失败处理就成了模型的自然决策（重试/换方案/如实上报）而非代码崩溃路径。⑤ 深度限制：子代理可以再生子代理（无限套娃），工程上常见限 2 层——不限制会导致预算指数爆炸 + 定位问题如地狱。

考察意图与踩坑点

• 考察意图：考多 Agent 是"真搭过"还是"只看过架构图"——第 3 层的三层结构和第 4 层的五个工程坑，只有动手实现过的人才答得出。与 Q06 的分工：Q06 管"何时用"（选型），本题管"怎么实现"（结构与坑）。
• 踩坑点：只会说"多个 Agent 协作完成任务"；不知道子代理 = 高级工具的同构关系；漏掉预算乘法和观测级联——这两个是多 Agent 系统最常见的生产事故源。
• 一句话总结：三堵墙至少撞一面才拆；子代理是返回字符串的高级工具——Spec 定岗位、每次 spawn 新实例、任务必须自包含；五个工程坑里预算乘法和观测级联最致命。

---

本篇速记卡

题	一句话核心
Q01 Tool Calling	模型只发调用意向，执行在你代码里；注入-生成-解析，概率行为要校验
Q02 ReAct	行动插入思考之间；链是写死的流程，Agent 是运行时决策
Q03 死循环	四道闸门：自然终止/轮次/预算/重复检测；拦后降级 + 纠偏重试
Q04 选型	步骤能写死用链；写不死才 Agent；生产是图里嵌 Agent
Q05 工具设计	单一职责 + schema 清晰 + 返回带引导；小工具组合出涌现策略
Q06 扩展选型	知识用 Skill、能力用 MCP、并行用多 Agent；先问扩展什么
Q07 上下文工程	预算分配、压缩、按需加载——Agent 的瓶颈先出现在窗口不在模型
Q08 评测	任务成功率 + 轨迹质量 + 边界测试；线上盯闸门触发率
Q09 记忆分层	窗口是缓存、外部存储是记忆、检索是读取；防记忆污染
Q10 框架选型	编排/状态/流式/集成占两项以上才用框架；当库用，别当架构服从
Q11 多Agent设计	三墙至少撞一面才拆；子代理=高级工具，任务自包含；预算乘法+观测级联是命门