你怎么理解 LLM 和 Agent？什么是模型，什么是 Agent？两者有什么区别和关系？ 模型是怎么感知到有哪些 Tool 的？又是怎么调用 Tool 的？ - Tool 怎么提供给模型？ - 模型怎么选择 Tool？ - Tool Call 之后发生什么？ 一个 System Prompt 至少应该包含哪些部分？ History 会放进 System Prompt 里面吗？ - 很长的历史信息应该怎么处理？ 你的 Agent 系统有没有使用 Skill？ Skill 的 Progressive Disclosure（渐进披露）是什么？ Agent 程序到底是怎么使用一个 Skill 的？ - Skill 本质上是一堆文件时，程序怎么发现它？ - 怎么加载它？ - 怎么让模型真正按照 Skill 工作？ Skill 和 Tool 是什么关系？有什么区别？这些问题怎么回答比较好

这串问题基本是把「Agent 入门必考八连」一次问全了，而且一环扣一环，很适合串成一套话术。我按你的顺序给参考回答口径，素材大多来自 Joye 博客里 Agent 系列那几篇（agentOnboardingGuide、面试复盘），你可以直接当答题模板用。 一、LLM 和 Agent 的区别 一句话版：LLM 是大脑，Agent 是完整的人。模型只负责「输入一段文本，输出一段文本」；Agent 是包着模型的一套系统，核心特征是循环加工具——它能看到任务、决定下一步做什么、调用工具拿结果、再决定下一步，直到任务完成。所以单次 API 调用不是 Agent，只会聊天的机器人也不是 Agent，Agent 的核心目标是「完成任务」而不是「对话」。关系就是：LLM 是 Agent 的推理引擎，Agent 负责给它目标、工具和环境。 二、模型怎么知道有 Tool、怎么调用 不是「感知」，是 API 层面注册。你在请求里把每个工具的定义（名字、描述、参数的 JSON Schema）通过 tools 参数传进去，这些会进到模型上下文前缀里，模型就知道「有哪些工具、各自干什么、参数长什么样」。然后它生成回复时如果觉得该用工具，就会输出一个结构化的 tool_call（选哪个工具、填什么参数），而不是真的去执行——执行发生在你的应用层。执行完把结果作为 tool result 回填给模型，它再基于结果继续生成。整个循环叫 ReAct：推理、行动、观察、再推理。工程要点：参数名和描述写得越清楚，模型选错概率越低；工具太多模型会选不对，几十个以上就该上 tool search 按需加载。 三、System Prompt 至少包含什么 角色和目标、可用的工具和它们的使用边界、输出格式约束、几条不可违背的红线规则。补充一个进阶点：System prompt 要尽量保持静态，时间、文件状态这类动态信息放到 user message 里，否则一改 system 前缀缓存全废——这是 prompt caching 的基本原则，面试里讲出来很加分。 四、History 会放进 System Prompt 吗 一般不会。System prompt 放的是「常驻配置」，对话历史是作为 user/assistant/tool 的轮次消息序列排在 system 后面的。长历史处理有几种层次：最粗暴是 FIFO 砍旧消息（缺点是有信息丢失）；好一点是砍之前先把要丢的轮次压成一条 summary 留在上下文；再往上是做 consolidation，把对话里的事实性信息抽出来存进长期记忆库，用的时候检索注入相关历史而不是全量塞。还有 cache-safe 的讲究：做压缩摘要时别开一个全新的 call 去总结，否则 180k 历史全部原价重算，正确姿势是复用完全相同的 system 和 tools 前缀、只在末尾追加一条「请总结」，让整段命中缓存。 五、我的 Agent 系统用没用 Skill 这个要看你的口径——如果你问的是通用 Agent 设计，业界标配是「Skills 加 tool search」这套渐进式方案（Joye 的语料里写过 Hermes/Agent 的官方口径，这也是 Claude Code、Claude.ai 在用的范式）。我自己这边的工具设计也体现了这个思路：检索、看图、搜群历史、查仓库这些能力是分开注册、按场景调用的，而不是把所有东西一次性灌进上下文。 六、Progressive Disclosure（渐进披露）是什么 平时模型只看到每个 Skill 的一行简介（名字加一句话描述），只有上下文匹配到相关场景时，才把那个 Skill 的 SKILL.md 正文、脚本、参考资料真正加载进来。这样装 50 份「说明书」也不会把上下文撑爆。配套的是 tool search：工具不全量注册，给模型一个「搜索工具的工具」，按需把要用的调进来。面试答这个题，三个关键词就够了：渐进式披露、SOP 标准化、便于分享。 七、Agent 程序到底怎么用一个 Skill 三步。发现：启动时扫描 skills 目录，把每个文件夹里 SKILL.md 的元信息（名字、描述、触发条件）读出来建成索引，这就是模型「看得到」的部分；加载：运行中模型判断当前任务匹配某个 skill，程序才把该 skill 的完整内容（正文步骤、脚本路径、参考资料）注入上下文；遵循：SKILL.md 本质是写给模型读的 SOP——里面写清楚什么时候触发、按什么流程做、调用哪些脚本、输出长什么样，模型照着它一步步执行，需要执行具体动作时再调里面的工具/脚本。本质上目录是索引、运行时是按需注入、SKILL.md 是操作手册。 八、Skill 和 Tool 的关系 Tool 是单个可执行单元，一个函数（schema 加实现），解决「能做什么、怎么被调用」；Skill 是能力包，一个文件夹（SKILL.md 加脚本加示例加指导），解决「怎么组织、什么时候触发、怎么做成一整类任务」。Tool 是手和零件，Skill 是把零件加上操作手册打包好的工具箱——一个 Skill 内部可以编排调用多个工具。再把 MCP 拉进来讲更完整：Function Calling 解决单个函数调用，MCP 把「模型到工具/数据源」的接口标准化，Skills 解决能力怎么打包和触发，三者是不同层的互补关系。MCP 给数据，Skill 给方法论。 最后说下「怎么回答比较好」：这题组的考法是连环追问，所以每问先甩结论关键词再展开，别从头铺垫。就像复盘里那个例子——问 Skills 是什么，60 秒讲形态不如三个关键词（渐进披露、SOP 标准化、可分享）来得精准。还有一条：不会的题别嘴硬，承认再讲「如果要改造我会怎么做」，比硬撑值钱。 想深挖的话，Joye 那篇「Agent 新手入门」系列（agentOnboardingGuide 那篇，讲了 Agent 是什么、Skills/MCP 协议层、工具调用）和两篇模拟面试复盘（agentMockInterview 和 agentMockInterviewReview）基本覆盖了这整串问题的标准答案，值得通读。