AI 面试问题
什么是 Harness 工程？
Harness Engineering，也被叫做驾驭工程，是给 AI Agent 设计工作环境的一套工程方法，包括上下文管理、工具调用、沙箱环境、权限控制、测试验证、日志观测、评审机制和反馈回路，目的是为了让Agent在真实工程系统中更可靠、更可控，并持续完成任务。
Harness 工程解决了什么问题？
Harness 工程的核心思路是为 Coding Agent 提供良好的环境条件，限制边界条件，避免模型犯错。 比如：团队架构规则只存在于老员工脑子里、项目启动方式没有写清楚、测试入口散落在不同目录、日志和报错没有暴露给 Agent、UI 问题需要打开浏览器才能验证，但 Agent 只能看代码代码、评审标准没有机械化，只能靠人最后兜底
Harness 工程包含哪些内容？
主要分为两部分：引导和反馈
引导是在Agent 执行任务之前，告诉它怎么做，常见形式包括：AGENTS.md、架构文档、编码规范、项目启动脚本、API 文档、领域知识、示例任务、Skills、任务拆解方式。
反馈发生在 Agent执行任务之后，作用是告诉Agent有没有做对，常见形式包括：单元测试、类型检查、linter、静态分析、架构测试、浏览器自动化、运行日志、metrics 和 traces、代码评审 Agent、LLM judge、人类 review。
Harness 工程和 Prompt 工程的区别？
Prompt 工程偏向输入设计，主要解决“这次怎么让模型更好地回答”；Harness 工程偏向系统设计，主要解决“怎么让模型在工程环境里长期可靠地工作”。
如果在 prompt 里写：请遵守项目架构，不要跨层调用。这是 Prompt工程。但如果你把架构边界写进 custom linter，让 Agent 每次改代码后都能被自动检查，这就是 Harness 工程。
如果在 prompt 里说：修改完成后请运行测试，这还只是提示工程。但如果系统在 Agent 准备结束前拦截它，要求它执行测试、读取完整输出、失败后回到需求重新修，那就是Harness工程。
你设计 Prompt 的核心原则是什么？
- 清晰：把任务目标、边界和输出要求讲清楚
- 结构化：把角色、指令、上下文、示例、格式约束拆开组织
- 可评测：每次调整 Prompt 都要基于测评集做对比
既然大模型已经这么强了，为什么还要做 Agent？
我理解 Agent 本质上是一个能自主完成目标的 AI 系统，跟传统 AI 最核心的区别在于「自主性」和「能行动」。
传统 AI 是你问一个问题它回答一个问题，每次都是独立的，被动响应。
而 Agent 有自己的规划能力，你给它一个复杂目标，它会自己把任务拆成多步，通过调工具、访问记忆、感知环境来一步步执行，直到完成。
它不只是输出文字，而是真的能做事。
Agent 的本质是什么？
Agent是以 LLM 为核心，具备规划（Planning）、记忆（Memory）和工具调用（Tool Use）能力，能够自主拆解复杂任务、循环执行、感知反馈并持续推进任务直到完成的计算实体，实现从“文本生成”到“任务自主执行”，不再只是被动响应指令，而是能像人类员工一样，自主实现任务闭环。
Agent 核心组件有哪些？
有四个核心组件：LLM、工具、记忆、规划模块。
- LLM 是整个系统的大脑，负责理解任务和做决策。
- 工具让 Agent 能跟外部世界交互，搜索、执行代码、调 API 都靠它。
- 记忆让 Agent 在任务执行过程中保持状态，不会「失忆」。
- 规划模块负责把复杂目标拆解成可执行的步骤。这四个组合在一起，才让 Agent 具备了自主完成任务的能力。
Agent 和单纯的LLM接口调用（chat）区别是什么？
核心在于是否具备实际执行任务的能力，LLM主要是被动接受用户的输入来生成文本回答，主要为一问一答。Agent是设定任务目标、拆解复杂任务、主动调用工具、获取反馈直到完成任务的循环逻辑，LLM只是Agent的大脑，Agent还有手脚（插件/工具/API）和记忆。
Agent 如果在执行中陷入死循环怎么办？
这其实是在落地Agent中必须考虑的问题，可以通过设置最大迭代次数、引入反思机制Reflection、人工介入等方式来解决。
Agent 系统测评有哪些关键指标？
- 任务完成率：用户交给 Agent 的任务到底有没有完成。比如订票 Agent 有没有完成订票，代码 Agent 有没有成功生成可运行代码
- 结果质量：最终回答是否准确、完整、有用，是否符合用户意图
- 执行过程质量：工具有没有调用对，步骤是否合理，有没有无意义的重复调用，有没有错误处理和降级逻辑
- 系统性能：包括延迟、token 消耗、接口费用、整体成本
- 稳定性：模型调用、工具调用、外部 API 是否经常失败，失败后是否能重试或降级
- 用户反馈：包括点赞、点踩、评分、评论，也包括隐式反馈，比如用户是否重复提问、是否频繁点击重新生成、是否换一种说法继续问。
如何设计多 Agent 的协作与动态切换机制？
协作靠两件事：消息传递和共享状态。
消息传递是 Agent 完成自己的工作后把结果发出去，下一个 Agent 取用；共享状态是所有 Agent 共同读写一个状态对象，记录任务进展和中间结果。
动态切换靠 Orchestrator 来做，有两种方式：一种是静态路由，提前写好规则「任务类型 A 就找 Agent X」；另一种是让 LLM 动态决策，根据当前情况实时判断该把任务交给谁。我的实践是两种混用，主流程用静态路由保证稳定，边缘情况才交给 LLM 动态判断。
为什么有时候选择「手搓」Agent，而不是直接用成熟框架？
我的感受是框架用起来快，但有几个实际痛点。第一是抽象层太多，调试的时候不知道哪步出了问题，得一层层往下扒；第二是版本升级经常有破坏性变更，线上稳定性难保证；第三是框架的通用设计往往和具体业务需求有偏差，定制起来反而更费劲。手搓的代码完全在自己掌控之内，可观测性好、出问题好排查，也更方便做性能优化。所以我现在的策略是核心逻辑手写，只在边缘功能上用框架的工具。
单体 Agent 遇到瓶颈，Multi-Agent 方案怎么设计？
Single-Agent 适合任务流程清晰、复杂度适中的场景，实现简单、好维护；Multi-Agent 适合需要专业分工、任务量大或者需要并行执行的复杂场景。
Multi-Agent 架构上主要有两种拓扑：中心化的 Orchestrator 模式，由一个主 Agent 统一调度各个 Worker；去中心化的 Peer-to-Peer 模式，Agent 之间直接通信。
我在工程里用中心化用得更多，因为好控制、好调试，出问题链路清晰。
什么是 Multi-Agent？
多智能体系统（Multi-Agent）就是多个 Agent 协作完成任务，每个 Agent 各有分工，有的负责搜索、有的负责写代码、有的负责做评审。
我理解单个 Agent 主要受两个限制：一是 context 窗口大小，复杂任务信息量一多就撑爆了；二是单点能力，什么都让一个 Agent 做，每件事都是泛才。
Multi-Agent 通过专业分工和并行执行，能处理更复杂、更长流程的任务，这是我在实际项目里选择多智能体方案的核心原因。
Agent 是如何进行反思的？
Agent 的反思机制，本质上是“生成后再评估，然后根据反馈修正结果”。常见有两类：
- 自我反馈和外部反馈，自我反馈靠大模型自己审查输出，适合查文案一致性、约束遵循、有没有误改内容；
- 外部反馈是把结果放进真实工具里验证，适合代码、计算、JSON、图表这类必须拿事实说话的任务。
Agent 的记忆系统是什么？短期和长期记忆方案怎么设计？
我理解记忆系统分两层。
第一层是短期记忆，用于当前会话，用截断对话或者总结摘要去控制prompt长度、同时保持语义连贯。
第二层是长期记忆，用于跨会话场景，用向量召回最相关的历史信息，再按需放回上下文。在实践中，不要把写入长期记忆做成“默认全部存储”，而要设准入条件（该存储的存储，该忘的忘），同时要对记忆定期清理、合并和更新，这样Agent的记忆才能更稳定。
短期记忆过长超过 token 限制怎么办？
记忆压缩常见有四种方法：摘要压缩、滑动窗口、重要性过滤、结构化抽取。
- 摘要压缩是把长对话总结成简短摘要；
- 滑动窗口是只保留最近 N 轮对话；
- 重要性过滤是打分筛选，只留重要内容；
- 结构化抽取是把关键信息抽成结构化数据存起来。
在实际项目里最常用的是摘要压缩和滑动窗口，而且经常组合用，滑动窗口丢弃前先做一次摘要，尽量不丢重要信息。
Agent 中的 Skills 是什么？
Skills 本质是结构化的本地文件夹，用来补充某个领域的流程、知识和工具，让模型在相关场景下自动或按需调用，是面向大模型的能力封装。
Agent 中的 Skills 和 Prompt 的区别是什么？
Prompt是一段临时说明，告诉大模型这次要做什么和怎么做，等任务结束后，这段说明的作用基本也就结束了；Skills是把这套做事方法沉淀下来，下次遇到类似问题，不需要从头再讲一遍，大模型可以按场景去调用。
Agent 系统里面 Skill 是怎么编写的？如何保证高质量的Skill？
通过Skill创建器（例如Codex自带的 Skill Creator），来协助创建Skill，但是高质量的Skill的标准需要我们自己来把关，通过下面五个流程来创建Skill：
- 判断这个任务值不值得封装
- 提取专家决策和常见反模式
- 把指令写得简洁且约束合适
- 配齐模板、参考资料和脚本
- 用真实任务反复验证执行效果
如何判断任务值不值得做成 skill？
- 如果一个任务里，熟手和新手的差距主要体现在边界判断、风险识别、优先级取舍，那它就很适合做成 Skill
- 如果一个任务一句 Prompt 就能说清，或者三步以内就能完成，通常没必要专门做成 Skill。Skill 不是越多越好。它有维护成本，要写说明、配资源、做测试、反复迭代。
- Skill 的价值在复用。如果你的团队每周都会做类似的分析、审核、发布、改写或生成任务，那么把它沉淀成 Skill，长期收益通常很高。
提取专家决策该写什么？
- 提取决策树
- 什么条件下走方案 A
- 什么条件下切到方案 B
- 什么情况下应该停止、降级或者补充信息
- 提取反模式和不要做的事情
- 不要把来源不明的内容当成事实写进输出
- 不要在高风险操作里直接执行修改，应该先生成计划再验证
- 不要为了把结果写完整，擅自编造缺失信息
- 提取模板和示例
Agent 推理模式有哪些？ReAct 是啥？具体是怎么实现的？
Agent 的推理模式我用过几种。
最基础的是直接输出答案，没有中间推理；CoT 是让 LLM 先把推理过程写出来再给答案，准确率更高；ReAct 是在 CoT 基础上加了「行动」，让 LLM 交替输出思考和工具调用，每次行动后再根据结果继续思考，形成一个循环。
我觉得 ReAct 是目前 Agent 用得最广的模式，因为它推理过程可见，又能动态利用外部工具，两个优点都有。
什么是 RAG？
RAG全称检索增强生成，就是让大模型在回答问题前先去“查资料”（检索），相当于让它开卷考试：模型本身可能没学过公司的内部文档，但只要把相关内容找出来给它，它就能结合这些资料给出靠谱的答案（生成）。
为什么需要RAG？
大模型本身只有它训练时见过的知识，如果问它“你们公司差旅报销流程是什么”，它肯定答不上来，因为它根本没见过你们的制度文件（不了解私域知识）。如果硬要它回答，大概率就是瞎编。解决这个问题的直观思路：把相关资料喂给它不就行了，这就是RAG的核心逻辑，关键是如何做到“精确投喂”，只把问题最相关的知识检索出来给大模型。
RAG 你也做了一段时间了，你觉得实际落地中最难的地方在哪？
我觉得 RAG 最难的不是把它跑起来，一个基础的 Demo 一两天就能搭起来，难的是把它调好。工程上最让我头疼的有三块。
- 第一是文档预处理，原始数据的格式五花八门，PDF 里面的表格、图片、嵌套的格式，处理不好就是一堆乱码进了知识库，进去的是垃圾出来的也是垃圾。
- 第二是检索质量的调优，向量召回不准是整个系统效果的天花板，但问题来源很多，Chunking、Embedding、Query 改写，任何一个环节出问题都会影响结果，排查起来很费劲。
- 第三是效果评估，答案对不对很难系统性地衡量，不知道是哪个环节出了问题，优化就变成了瞎猜。
你们 RAG 知识库上线之后，文档更新了怎么办？
我理解知识库更新的核心挑战是，文档变了，对应的 chunk 和向量都要跟着变，而且要做到增量处理，不能每次全量重建。
我们的通用方案是给每个文档算一个内容 hash，通过轮询或者监听数据源变更，检测到文档新增、修改、删除的时候，先清掉旧的向量，再重新切割入库。
对于实时性要求比较高的场景，我会用消息队列比如 Kafka 做变更事件驱动，实现秒级的入库。
你们线上跑了 RAG，那你怎么衡量它的效果好不好？
我评估 RAG 效果是分两层来看的。
检索层看该召回的有没有召回到，我用 Hit@K 和 MRR 来衡量。生成层看答案对不对、有没有幻觉、和问题相不相关，我主要用 RAGAs 框架，里面的 Faithfulness、Answer Relevancy 和 Context Recall 这三个指标是最核心的。
我的建议是一定要在自己的业务数据上跑，不能只看通用排行榜，那个不能代表你的场景。
另外线上指标，就是用户的点踩率、追问率、转人工率这些，才是最终的衡量标准，离线指标只是辅助。
什么是 MCP 协议？
MCP（Model Context Protocol）是模型上下文协议，目的是为AI应用提供一个标准化接口，使其能够连接外部数据源和工具。例如，AI应用可以通过MCP连接到本地文件或数据库、搜索引擎或计算器、工作流或专业提示词等，从而获取到上下文信息并执行实际任务，可以把 MCP 理解为 AI 应用的”TypeC 接口”。
什么是 Function Calling ？原理是什么？
Function Calling 我的理解是这样一套机制：开发者用 JSON schema 把工具描述好传给模型，模型判断需要调工具的时候不输出自然语言，而是直接输出一段结构化的 tool_calls JSON，告诉你「我要调哪个函数、参数是什么」，你的代码拿到这段 JSON 去真正执行，把结果塞回对话，模型再生成最终答案。
整个流程本质上是两轮对话：第一轮模型说「我需要调这个工具」，你去执行，第二轮模型拿到执行结果说「答案是这个」。我觉得最核心的设计是，模型全程只做决策，执行的事情一律由宿主代码完成，职责分得很清楚。
MCP 与 Function Calling（函数调用）有什么区别？
函数调用是LLM的内部能力，依赖于LLM的返回结果，不同模型（如ChatGPT和Claude）的函数调用返回结构体并不统一；MCP是和LLM无关的外部标准协议，不同的AI应用都可以接入相同的MCP Server。
MCP 的安全机制如何保障？
MCP本身无法在协议层面保证安全，需要开发者在应用层使用时遵循安全最佳实践：如沙箱隔离、最小权限原则、人工授权、安全说明文档等方式。
什么是 A2A 协议？它和 MCP 协议的区别是什么？
A2A 是 Google 在 2025 年发布的协议，专门解决多个 AI Agent 之间怎么互相通信的问题。我理解它和 MCP 的区别是这样的：MCP 解决的是「单个 Agent 怎么连工具和数据」，A2A 解决的是「多个 Agent 之间怎么分工协作」。
一个 Agent 通过 A2A 可以把子任务委托给另一个专业 Agent，接收方按自己的 Skill 声明承接，支持异步长任务和流式推送结果。两者是互补的，不冲突：MCP 向下连工具，A2A 向上连 Agent，在复杂的多 Agent 系统里这两个通常都要用到。