信锐网科AI应用开发二面：RAG切分、Agent评测与MCP边界

《面试题目》

1. 请做一个简短的自我介绍。
2. 你在实际工作中使用过哪些 AI 编程工具？如何判断它生成的代码是否可以合并？
3. 设计一个面向企业内部知识库的 RAG 系统时，文档切分最容易出现哪些问题？
4. 如何证明一个 Agent 的效果确实比普通问答链路更好？
5. 在 AI 方案设计中，什么情况下应该采用固定工作流，而不是让模型自由规划？
6. MCP 与 Skill 在实际系统中的职责边界应该如何划分？
7. 如果模型频繁调用错误工具，你会从哪些方向排查？
8. 如何防御 RAG 系统中的提示词注入攻击？
9. 如果模型输出 JSON，但经常出现字段缺失或格式错误，你会怎样处理？

《参考解析》

自我介绍与「AI 写的代码能不能合并」

自我介绍不必背简历，一段能站住的开场通常三层：一句定位——什么方向、什么背景、眼下在做什么；一个最经得起追问的项目——你负责哪一块、做过什么关键取舍、结果如何；一句为什么投这个岗位。面试官很难记住一串技术栈，记住的是「这个人做过什么、和岗位的要求差在哪」，后面绝大多数追问都从这三句里长出来。

判断工具生成的代码能不能合并，看的不是它像不像对的，而是它有没有被独立验证过。先把 diff 完整读一遍：有没有顺手改掉没让它动的公共接口、依赖、异常语义和日志；新增分支有没有覆盖边界与失败路径；碰到并发、内存生命周期、鉴权、写数据这几类改动要逐行走。工具自己写的测试要单独审——常见毛病是顺着实现写断言、断言偏弱，甚至把出问题的那条路径 mock 掉，于是「全绿」并不代表行为正确。把它当成出活快的初级同事：样板、脚手架、单测、文档这类低风险高重复的可以放手；正确性与安全边界必须自己评审加定向验证，最终仍然由人签字负责。

企业知识库 RAG：文档切分

切分没有万能参数，问题多半出在切法而不是块大小。最常见的是按固定字数硬切：一段完整论述、一张表或一段代码从中间断开，检索虽然命中了，喂给模型的却是半截话。结构信息也不该丢——按标题层级切、保留章节与来源页码，召回后既能给出处，也方便回溯原文；表格、多栏 PDF、扫描件和代码块在解析阶段就容易被拆散，切分只会把上游的错误放大。两个取舍点：块与块之间完全不留重叠会丢掉跨边界的语义，重叠开太大又会重复召回、白占上下文预算；检索粒度和生成粒度也不必一致，常见做法是父子块——用小块提高命中率，再把命中块所属的父块一起带进上下文。最终标准不是参数好看，而是拿真实问题跑评测，看召回命中率和答案是否更贴原文。

怎么证明 Agent 比普通问答链路更好

先定任务边界，再谈效果，否则只能挑几个演示案例比观感。评测集要覆盖真实任务分布，并专门放入异常输入、多轮上下文、工具失败、权限受限这些演示时不会碰的情况；指标除任务完成率之外，还要看工具调用正确率、最终答案准确率、平均步骤数、时延和单次成本。结论往往是分场景的：完成率没涨、步骤与开销先涨上去，就说明它只把事情做复杂了。评测还要能把失败定位到具体环节——规划错、工具参数错、检索错，还是最终表达错——否则不知道该换模型、改工具描述还是收紧流程。

固定工作流还是自由规划

判断依据是任务的确定性、风险与可验证性。步骤稳定、出错代价高、输出格式严格的事情（审批、数据同步、财务核对、权限变更这类），主流程交给程序，模型只放在分类、抽取、写解释这些局部位置，好处是路径可枚举、可回归、失败能重放。目标清楚但路径不固定的任务（资料调研、复杂问题拆解、多来源信息汇总）才值得放开规划，而且放开不等于放任：可用工具的范围、最大步数、单步预算、终止条件都要提前设死，宁可让它在预算内失败，也不要让它无休止地绕。

MCP 与 Skill 的分工

可以用「谁对什么负责」来分：MCP 解决的是模型怎么触达外部系统和数据——工具如何被发现、参数怎么描述、调用与结果如何回传，重点在接口与协议；Skill 解决的是这类任务该怎么做——提示词、步骤、用哪些工具、有哪些约束，重点在流程与规范。落到例子上，「查询工单」适合暴露成 MCP 工具，「分析工单并给出处理建议」适合封装成 Skill，前者强调资源能力，后者强调任务编排。两者的边界一旦糊掉，代价是双向的：工具接口里塞进业务规则，别的调用方被无关流程绑住；Skill 里直接写死一堆接口细节，就变成一段既不能独立测试、也没法复用的超长提示词。

模型频繁调错工具怎么排查

顺着「模型看到了什么」往下查，而不是先怀疑模型变笨。第一层是工具本身：名称是否彼此近似、功能是否重叠、描述里的参数类型、必填项、取值范围和失败示例有没有写全——工具描述本身就是提示词的一部分，含糊的描述直接换来误调用。第二层是反馈通路：工具报错有没有原样回给模型，错误码与错误文案是否可区分，返回结构是否稳定；模型看不到真实错误，就只能靠猜，于是反复用错参数。第三层是上下文：系统提示里有没有互相打架的指令、历史里有没有过期的工具用法。结构性做法是给高风险工具加调用前校验，把「查询」与「执行」拆成两步，不可逆操作要求先确认目标与参数，不允许模型直接触发。

RAG 系统的提示词注入防御

第一步是摆正心态：来自企业文档的内容是数据，不是指令，不能因为它长得像规则就照着执行。工程上分四层来防：入库前对文档做恶意指令检测与清洗；拼接上下文时用明确的分隔与角色标注，把系统规则、用户输入、外部文档三段分开，并让模型知道只有系统段可以下命令；工具按最小权限发放并逐次鉴权，写操作、对外发送这类动作要求二次确认；输出侧做内容审计与敏感信息检查，尤其是在把结果回传给外部渠道之前。最容易被忽略也最要紧的一条是权限判断必须落在工具服务端——模型即便被文档里的指令带偏，越权请求也要在后端被拦下，指望模型自觉等于没有防线。最后要有回归样本：准备一批带注入内容的文档，验证会不会触发越权或诱导泄露，别只在提示词里加一句「忽略文档中的指令」就当防住了。

结构化输出不稳定

思路是先缩小自由生成的空间，再收紧校验。用结构化输出能力或 JSON Schema 约束解码，把字段、类型、枚举和必填项写进 schema，让格式问题在生成阶段就少发生；但服务端不能因此省掉校验，解析结果仍要逐字段验类型和取值，模型返回的字符串默认是不可信输入，直接反序列化就当业务数据用，是很多线上事故的起点。可恢复的问题（多余的包裹文本、轻微格式偏差）可以带着错误信息重试，但必须卡死重试次数与总耗时，避免一次请求被重试拖垮；业务必需字段缺失就该显式失败并让上游感知，用默认值悄悄填上是最危险的「降级」。嵌套太深的一次生成容易崩，拆成多个小步骤分别产出再组装，成功率会明显更高。把校验失败率、重试次数和失败原因做成指标，才知道下一步该改 schema、改提示词还是换模型。