大模型基础面试题

大模型基础

Prompt工程、Context工程和Harness工程，这三个的侧重点和区别是什么？

建议参考这个视频：www.bilibili.com/video/BV1Zk…

这三个工程代表了AI应用开发的三个不同层次，从描述任务到补充背景知识，再到构建执行闭环，是层层递进的关系。

Prompt工程

核心：向大模型描述"怎么完成这个任务"

本质：通过自然语言指令，把任务目标、执行方式、输出格式、约束条件告诉模型

技术手段：

手段	说明
零样本	直接通过指令描述任务，不提供示例
少样本	提供几个输入输出的示例，让模型模仿
举反例	告诉模型"不要这样做"，通过负面案例约束模型行为

适用场景：通用任务、模型已有相关知识储备的任务

核心局限性：大模型的知识是有限的，缺乏专门领域的垂直背景知识

Context工程

核心：为大模型补充"完成任务所需的背景知识"

本质：解决Prompt工程的知识局限性，通过外部信息供给让模型具备领域知识

技术手段：

手段	说明
RAG（检索增强生成）	通过检索外部文档库来补充知识
长期记忆管理	把历史对话、用户偏好、项目背景等信息存储起来，需要时召回
动态上下文注入	根据当前任务阶段动态加载相关的工具文档、API说明、业务规则
上下文压缩与摘要	当信息量超过上下文窗口时，把历史信息压缩成摘要，保留关键信息
多源信息融合	把数据库查询结果、API返回数据、文档检索内容融合到上下文中

适用场景：垂直领域应用、需要外部知识的任务、多轮对话场景

解决的问题："信息供给"问题，但仍然无法解决模型在执行过程中偏离目标的问题

Harness工程

核心：构建"任务执行的确定性闭环"

本质：在模型外围构建一套机制，保证复杂任务能够按计划执行，一旦出现偏差能够及时纠正

要解决的问题：当模型需要一步步执行复杂任务时，某一步出现偏差，后续步骤会基于错误的前提继续执行，导致偏差越来越大

典型架构（六层）：

层级	作用
循环层	建立"观察→决策→行动→验证"的循环引擎
工具层	提供文件读写、API调用等原子能力
上下文层	作为信息防火墙控制输入质量
持久化层	管理跨会话的状态和记忆
验证层	在执行后自我验收，失败则重试
约束层	设定权限边界防止失控

适用场景：复杂任务编排、自动化工作流、需要多步执行的Agent

三者的关系

工程	解决的问题
Prompt工程	"怎么说清楚任务"
Context工程	"怎么补充知识"
Harness工程	"怎么保证执行"

在实际项目中，三者是配合使用的：

• Prompt工程把任务描述清楚
• Context工程补充必要的背景知识
• Harness工程保证执行过程不偏离目标

在你自己的项目中，具体用到了哪些Harness工程的设计？

我的项目没有直接使用Anthropic的Harness框架，但实现了一套类似的自我纠错闭环机制，核心理念是一致的：在复杂任务执行过程中及时检测偏差并纠正，防止"一步错、步步错"。

具体实现："规划→执行→验证→纠错"的闭环流程

规划阶段：

• 当用户提交一个复杂任务时，大模型分析任务目标
• 拆解成多个子步骤，生成执行计划

执行阶段：

• 系统按照计划依次执行每个子步骤
• 每一步都会记录执行结果和中间状态

验证阶段：

• 执行完一个阶段后，对执行结果进行打分评估
• 打分的维度包括：
  • 任务完成度（是否达成了当前步骤的目标）
  • 结果正确性（输出是否符合预期格式和约束）
  • 资源消耗（Token和工具调用是否合理）

纠错机制：

• 如果分数达标，系统继续执行下一步
• 如果分数不达标，系统不会继续往下走，而是带着错误上下文回到规划阶段重新分析
• 具体来说，系统会把当前步骤的执行结果、错误信息、评分反馈给大模型
• 让大模型分析失败原因，调整执行计划，然后重新执行

核心价值：一旦发现偏差就立即纠正，而不是带着错误继续往下走，避免错误累积放大。

防止死循环的机制

机制	说明
最大执行步数限制	比如一个任务最多允许执行50步，如果50步内没有完成，系统会判定任务失败
单步重试次数限制	比如每个步骤最多重试3次，如果3次都失败，就跳过这个步骤或回退到上一步重新规划

Transformer / 自注意力机制

回答：Transformer 的关键是自注意力：每个 token 都能根据上下文动态关注其他 token。它的优势是并行度高、能建模长距离依赖，但代价是注意力计算随序列长度增长很快。回答时可以补一句：自注意力让模型“自己决定看谁”，而不是靠固定窗口。

传统编程、传统NLP与大模型处理业务有什么本质区别？

• 传统编程（如 if-else 规则）： 将所有的规则写死在代码里（如关键词匹配）。缺点是用户的表达方式千变万化，规则无法穷举，稍微改变说法就会匹配失败。
• 传统NLP技术： 依赖关键词匹配、TF-IDF、朴素贝叶斯等进行统计层面的文本分析。本质上是在“数词频”、“算概率”，并不真正理解语言的含义，容易因为拆词错误导致误判。
• 大模型（LLM）： 通过让机器阅读海量文本数据（书籍、网页、代码等）进行训练。它不需要人为写死规则，而是通过大量阅读自然而然地“悟”出了语言的用法、常识和推理能力，能够真正理解复杂的语境和千变万化的表达。

大模型名字里的“大”指的是什么？参数的具体含义是什么？

• “大”的含义： 指的是模型的参数量巨大。例如 7B 代表 70 亿个参数，72B 代表 720 亿个参数（B = Billion，十亿）。
• 参数的含义： 参数可以理解为模型大脑里的“连接数”（类似人类大脑的突触连接）。每个参数本质上是一个数字（权重），所有参数组合在一起构成了模型对语言的理解能力。
• 参数量级与能力的关系： 参数越多，模型能记住的知识越多，处理复杂任务（如逻辑推理、创作）的能力越强，但需要的运行硬件（显存、算力）资源也越高、推理速度越慢。

什么是 MoE（混合专家架构）？它有什么优势？

• 定义： MoE 全称 Mixture of Experts（混合专家架构）。与传统大模型（稠密模型，处理输入时所有参数都参与计算）不同，MoE 模型内部被拆分成多个“专家”子网络，每次推理时只激活其中最相关的一部分专家来处理当前输入，其余不参与计算。
• 优势： 能够以更低的计算成本获得更强的模型能力。例如 DeepSeek-V3 总参数量为 671B，但每次推理只激活 37B 的参数。这意味着它拥有 671B 的知识容量，但推理开销仅相当于 37B 模型，极大地控制了推理成本。

什么是 Token？为什么要关注 Token？

• 定义： Token 是大模型内部处理文本的最小处理单元，是模型将文本切碎后的小片段。

• 计算规则：

  • 英文：1 个单词大约相当于 1~1.5 个 Token（如 "unbelievable" 可能被切分为多个 Token）。
  • 中文：1 个汉字大约相当于 1~2 个 Token。

• 关注的原因：

  1. 计费标准： API 调用通常按消耗的 Token 数量计费（输入和输出总和）。

  2. 上下文窗口限制： 大模型能接收的信息量上限是按 Token 计算的，而不是字数。

什么是上下文窗口？它在 RAG 系统中解决了什么问题？

• 定义： 上下文窗口是模型在一次对话中能看到的文本总量上限（单位是 Token）。它包含了系统提示词、历史对话、当前问题以及模型的回答。如果超出这个限制，最早的内容会被截断。常见的窗口大小有 8K、128K 甚至 1M。
• 在 RAG（检索增强生成）中的作用： 很多企业知识库（如产品手册）动辄几十万字，直接塞给模型容易超出窗口上限，或者让模型“迷失在信息海洋中”。RAG 系统通过先检索出最相关的文本片段，再将这些片段喂给大模型，既避免了超窗口问题，又能让模型聚焦关键信息提供准确回答。

什么是 Temperature？不同业务场景下该如何设置？

• 定义： Temperature（温度）是调用大模型时用来控制回答随机性和创造力的参数。
• 作用机制与场景推荐：
  • Temperature = 0 ~ 0.2（低）： 模型总是选择概率最高的词，回答最确定、最稳定。适用场景： RAG 问答、代码生成等需要极度准确、不能自由发挥的场景。
  • Temperature = 0.5 ~ 0.7（中）： 回答自然流畅，有一定变化。适用场景： 日常对话、客服闲聊。
  • Temperature = 0.7 ~ 1.0+（高）： 随机性强，创意度高。适用场景： 创意写作、头脑风暴等需要多样性的场景。

基座模型和 Chat 模型有什么区别？

• 基座模型（Base Model）： 仅经过第一阶段“预训练”（阅读海量数据学习语言规律）。它的特点是只会续写，不具备理解指令和回答问题的能力。比如输入“中国的首都是”，它会续写“北京，是...”，而不会把它当作一个问题来回答。
• Chat 模型（Instruct 模型）： 在基座模型的基础上进行了第二阶段“对齐训练”（指令微调和人类反馈强化学习 RLHF）。它能够理解人类指令，按照要求进行对话、总结和问答。（类似于读了很多书的学生，经过培训后变成了懂得沟通的员工）。
• 命名特征： Chat 模型通常带有 -Instruct 或 -Chat 后缀（部分新模型如 Qwen3 默认发布的就是 Chat 版本）。

为什么在构建 RAG 系统时，只能调用 Chat 模型？

RAG 的核心工作流是：把“检索到的文本片段 + 用户的提问”一起发给大模型，要求模型根据片段回答问题。 这就要求模型必须理解指令（“根据提供的文本回答问题”）并组织语言作答。基座模型缺乏指令理解能力，面对这样的输入只会进行无意义的“文本续写”，无法完成 RAG 的总结与问答任务。因此必须调用经过指令微调的 Chat 模型。

什么是模型量化？常见的量化格式有哪些？

• 量化定义： 模型参数本质上是具体的数字（权重）。量化就是把模型权重从高精度（如 16 位浮点数 BF16/FP16）压缩到低精度（如 8位 INT8 或 4位 INT4）的过程。
• 作用： 牺牲极小的精度，大幅度降低模型体积和推理时所需的显存占用，让普通显卡甚至 CPU 也能运行大模型。
• 常见格式：
  • GPTQ / AWQ： 依赖 GPU 推理的量化格式，速度快，精度较好。
  • GGUF： 支持 CPU 推理（也支持 GPU），适合显存不足或无独立显卡的本地部署场景。

简述 FP32, FP16, BF16 的区别？为什么大模型训练主流选择 BF16？

浮点数由符号位、指数位（决定数值范围）和尾数位（决定数值精度）组成。

• FP32（单精度）： 范围大、精度高，但占用显存极大（每参数 4 字节），目前很少直接用于模型存储。
• FP16（半精度）： 占 2 字节，把更多的位数给了“精度”，导致其“数值范围”极小（最大约 6.5 万），在大模型训练中非常容易发生数值溢出（算错）。
• BF16（脑浮点）： 占 2 字节，保留了和 FP32 一样大的“数值范围”，牺牲了一部分“精度”。
• 原因： 大模型训练中，参数数值变化范围极大，数值溢出（寄不到）是致命的，而精度稍低（地址粗一点）影响不大。因此 BF16 通过牺牲一点点精度换取了和 FP32 一样的广阔范围，保证了训练的稳定性，成为当前的主流。

什么是AgentSkills

Agent Skill是Anthropic 这个公司推出的一种新的范式，解决的是Agent上下文太长的问题，其实也是上下文工程的一种典型实现。

我们来做个比喻，Agent就像一个酒店的大厨，而MCP、Function Call这些就像是后厨的锅碗瓢盆、葱姜蒜等这些工具和食材，随着我们对厨师的要求越来越多，需要让他会做各种菜，我么就给他堆满了工具和食材。

但是，厨师有了工具和食材就能做出好菜了么？未必，因为随着工具越来越多，食材越来越多，反而会让厨师更难以做出美味的菜肴，因为他可能不知道什么时候该用哪口锅，该用哪种酱油了。

这时候，就需要一个菜谱，来指导厨师做菜，而这个菜谱，就是Skill！

Agent Skills 的做法，是把一些已经被验证有效的做事方式，抽象出来，封装成一个独立的能力模块，让 Agent 在需要的时候直接使用。

**Agent Skill 本质上就是一个标准化的目录结构。**你可以先把它理解为：一个给 Agent 用的能力文件夹目录。

一个完整的 Skill，至少包含一个核心文件，其余内容都是围绕这个核心文件展开的

my-skill/ # 技能名称
├── SKILL.md # 必选：技能的介绍说明与指令约束
├── scripts/ # 可选：可执行的脚本
├── references/ # 可选：可参考的示例文件
└── assets/ # 可选：图片等资源文件

这个结构就是 Agent Skills 的核心，就是为了让 Agent 在运行时，可以分层、有选择地加载信息，而不是一次性把所有内容塞进上下文。

把 SKILL.md、Reference、Script 放在一起看，其实它们就共同构成了Agent Skills的核心：渐进式披露机制。

所谓渐进式披露，顾名思义，就是不一次性把 Skill 的全部信息塞进上下文，而是根据 Agent 所处的阶段，按需、分层地加载信息。

在 Agent Skills 中，这种披露是严格分阶段发生的：

1. 技能发现阶段

   客户端只扫描 Skill 目录，并且只读取 SKILL.md 中由 --- 包裹的元数据。Agent 在这个阶段只关心一件事：这个 Skill 是做什么的，当前任务要不要用它。而 Instruction、Reference、Script 在这个阶段都不会被加载。

2. 执行决策阶段

   当 Agent 基于元数据判断需要使用该 Skill 后，才会加载 SKILL.md 中的 Instruction。此时 Agent 才开始理解：这个 Skill 具体该怎么用，执行流程是什么，哪些地方需要额外注意。

3. 细节补充阶段

   Reference 不会自动进入上下文。只有当 Instruction 中明确指示，或执行过程中确实需要查阅某些细节时，Agent 才会按文件粒度读取对应的 Reference 内容。这一步的目的就是补充当前步骤所必需的最小信息集。

4. 确定性执行阶段

   当流程中出现不适合交给模型自由生成的部分，Agent 会按 Instruction 的约定调用 Script。Script 负责用稳定、可控的代码完成具体操作，并只把结果返回给 Agent。大模型既不需要理解实现细节，也不会被大量原始内容干扰。只是调用，获取结果即可。

正是这种分层、延迟、按需加载的设计，使 Agent Skills 能够在保证执行稳定性的同时，显著降低上下文 token 的消耗。这也是 Agent Skills 演进为真正工程化能力模块的关键所在。

什么是A2A?

A2A全程是Agent to Agent protocol，是一个解决了多个智能体之间相互隔离，无法交流的问题的。

但是需要注意的是，他主要解决的是多个独立部署的智能体之间的互相协作问题，而有些我们自己搭建的多智能体，本身已经实现了协作的话，那就不再需要A2A了。

一般用在我们开发的Agent，需要调用别的团队、或者部门、或者是公司提供的，可能是用其他语言编写的Agent的时候。

当我们的agent要调用其他的agent，以前只能通过http调用，或者通过mcp调用，但是有了A2A之后，A2A就能实现互相调用了，有点类似RPC协议。

image-20260421225706151

1、客户端Agent首先需要知道远程Agent能做什么。它通过获取智能体卡（Agent Card） 来了解服务端支持的任务类型、输入输出格式、是否需要认证等信息。

2、客户端根据 Agent Card 中声明的能力，构造一个合法的 Task。将该 Task 封装进一条 request 类型的 Message，发送给服务端。

3、服务端收到 Message 后，验证 task_type 是否支持（对照自身 Agent Card），执行任务逻辑（可能调用工具、模型、外部 API 等），若任务生成具体产出（如图片、代码文件、报告等），则创建 Artifact。

4、服务端将结果（包括对 Artifact 的引用）封装进 response Message。

深度思考与开发实战

什么是大模型的思维链（CoT）和深度思考？它解决了什么问题？

• 定义： 思维链（Chain of Thought, CoT）是指让大模型在给出最终答案之前，先在内部（或显式地向用户展示）进行一步步的逻辑推理过程（Thinking）。
• 解决的问题： 避免大模型面对复杂问题“脱口而出”导致错误。就像人类做数学题需要在草稿纸上演算一样，模型把推理过程展开，每一步都“想清楚”再往下走，能大幅提升数学、逻辑推理、复杂代码生成的正确率。

开发者为什么需要通过 API 调用大模型，而不是直接使用网页版？

网页端（如 ChatGPT, DeepSeek 网页版）是面向个人用户的应用层产品，而 API 提供了底层的接入能力。开发者必须使用 API 的原因包括：

1. 系统集成能力： 可以将 AI 无缝接入 Java 业务系统（如客服、OA 系统）。
2. 自动化与批量处理： 可以利用代码瞬间处理成千上万条数据。
3. 精准的参数控制： 能够自定义 System Prompt（设定 AI 角色），灵活调整 Temperature（控制创意度）等核心参数。
4. 支持高级架构（如 RAG）： 网页版无法实现“向量检索 + LLM 回答”的自动化流水线。
5. 数据隐私与安全： 通过企业级 API 调用可以获得更好的数据隐私保障协议。

为什么现在大多数大模型平台都兼容 OpenAI 的接口协议？

因为 OpenAI 的 Chat Completions API 已经成为了大模型 API 世界的“事实标准”。 目前无论是国内的 DeepSeek、通义千问、智谱、SiliconFlow，还是国外的各大主流厂商，基本都提供了兼容 OpenAI 协议的 API 接口。 这意味着开发者只需要学习并掌握这一套协议，就能调用市面上几乎所有的大模型。在切换模型或平台时，代码逻辑一行都不用改，只需要替换 baseURL 和 API Key 即可，实现了零成本迁移。

大模型本身有记忆吗？多轮对话是如何实现的？

大模型本身是没有记忆的。 每次 API 调用都是完全独立的，模型绝对不会自动记住你上一次请求的内容。 多轮对话的实现原理： 所谓的多轮对话，其实是客户端（开发者）在每次发送请求时，把之前的完整对话历史记录（即整个 messages 数组）重新打包发送给模型。模型是通过读取这段完整的对话历史，才能理解当前的上下文。这也是为什么多轮对话越长，消耗的 Token 数量就越多的原因。

请解释一下请求参数 messages 数组中的三种常见角色（role）及其作用？

在 messages 数组中，通常包含以下三种角色：

• system（系统角色）：用于定义模型的行为规则，相当于给模型一份“工作手册”。模型会始终遵守系统消息中的指令，通过它能从根本上改变模型的行为风格（如设定为电商客服、技术顾问等）。在 RAG 系统中，system 消息被用来注入检索到的参考资料和回答限制。
• user（用户角色）：代表用户的输入内容，也就是用户向大模型提出的具体问题。
• assistant（助手角色）：代表模型之前的回答内容。它的主要作用是和 user 角色组合在一起，共同构建出多轮对话的上下文。 (注：OpenAI 新版 API 引入了 developer 角色替代 system，但功能一致且多数兼容平台仍使用 system)。

调用大模型 API 时，常用的几个控制参数（如 temperature、max_tokens）分别是什么作用？

• model：指定要调用的具体模型 ID（例如 Qwen/Qwen3-32B 或 gpt-4o）。
• temperature：控制回答的随机性（取值范围一般为 0~2）。值越小（如0），回答越确定、严谨；值越大，回答越发散、具有创造性。它和 top_p 参数作用类似，一般二选一进行调节。
• max_tokens：控制模型最多能生成的 Token 数量。如果模型的回答超过了这个数值，内容就会被强制截断。
• stream：流式开关。设置为 true 会启用流式响应（逐字推送），设置为 false 则是非流式响应（一次性返回完整结果）。

如何通过 API 响应监控大模型调用的 Token 计费成本？

在非流式响应的 JSON 结果中，包含一个非常关键的 usage 字段，它专门用于 Token 用量统计，主要包含：

• prompt_tokens：输入消耗的 Token 数（即你的 system + user + assistant 历史消息总和）。
• completion_tokens：模型生成的回答所消耗的 Token 数。
• total_tokens：总 Token 数，即上述两者的总和。API 就是按照这个总和或输入/输出分别计价的。

遇到模型回答只说了一半就突然断掉的情况，可能是什么原因？如何排查？

可以通过检查响应 JSON 中的 finish_reason（模型停止生成的原因）字段来排查：

• 如果 finish_reason 的值是 length：说明回答达到了 max_tokens 设定的长度上限被截断了。解决办法是把请求参数中的 max_tokens 调大。
• 如果 finish_reason 的值是 stop：说明模型正常结束了生成任务，认为回答已经完整。

实际开发与应用

Agent 修不好 bug 怎么办

回答：先看是不是信息不够、工具不对、上下文太长，还是任务本身超出能力边界。工程上通常会加三层兜底：缩小问题范围、切换更强模型、交给人类接管。真正成熟的 Agent 不是永远成功，而是失败时能给出可诊断、可恢复的结果。

模型路由 / 熔断

回答：模型路由就是根据任务类型、成本、时延和风险选择不同模型。简单问题走便宜模型，复杂推理走强模型，敏感或失败率高的任务加熔断和降级。熔断不是拒绝服务，而是当上游异常、超时或成本失控时，切换到可用的保底策略。

ReAct 模式怎么实现

回答：ReAct 的核心是让模型在“思考 - 行动 - 观察”之间循环。实现上一般会把模型输出限制成结构化格式，再由执行器根据 action 调工具，拿到 observation 后继续喂回模型。这样比单次生成更适合复杂任务，因为它允许模型边做边修正。

Code Agent 怎么设计

回答：Code Agent 一般要拆成“理解任务、规划步骤、调用工具、验证结果、修复失败”几个环节。核心能力不是一次性写出完美代码，而是能读仓库、定位文件、改代码、跑测试、看报错再迭代。实践中会把编辑器、搜索、测试、日志和终端能力都抽象成工具，并限制每一步的权限和上下文。

你用 AI 写代码的实践

回答：可以从“提需求、写骨架、补测试、查 bug、重构”五个阶段讲。比较成熟的用法不是让 AI 一次性生成全部代码，而是让它生成局部方案、补单元测试、解释报错和给出重构建议。面试里最好举一个真实例子，说明 AI 在哪一步最省时间。

用 Java 调用大模型 API（如使用 OkHttp）时，在网络设置方面需要特别注意什么？

必须调大 HTTP 客户端的超时时间（Timeout）。 普通的 REST API 响应通常在毫秒级，但大模型生成回答需要计算，耗时可能长达几秒到几十秒。特别是在进行“流式调用”时，连接需要保持较长的时间。因此，设置 connectTimeout 和特别是 readTimeout（如设为 60秒 甚至 120秒）是非常必要的，否则极易抛出读取超时异常。

在 RAG（检索增强生成）系统中，我们如何把检索到的专有知识传递给大模型？

这主要利用了请求参数中的 system（系统消息） 机制。 在实际开发中，我们会在代码中动态组装一段 Prompt，将检索出的私有文本片段直接拼接进 system 消息中，例如：“你是一个知识库问答助手。请根据以下参考资料回答用户的问题...参考资料：{动态注入检索到的文本}”。 通过这种方式，大模型就能基于给定的外部知识来准确回答问题，有效缓解幻觉。

什么是 Prompt 工程？为什么它在 RAG（检索增强生成）场景中非常重要？

Prompt 工程是设计和优化输入给大语言模型（LLM）的提示词，以引导模型输出高质量、符合预期的回答的一门技术。

在 RAG（检索增强生成）场景中，Prompt 极其重要，因为：

• 约束知识边界：好的 Prompt 能够限制模型只能使用提供的参考资料进行回答，防止模型使用其预训练知识进行“幻觉”补充（如自己编造“一般情况”或“特殊规定”）。
• 规范输出格式：能够强制模型标注信息来源（如 [1]），让用户可以追溯事实。
• 防止无效回答：能有效剔除模型自带的“多余兜底话术”（如“建议您联系客服确认”），直接给出干脆明确的答案。 好的 Prompt 能让模型更准确、更可控、更符合具体的业务需求。