智谱 AI Native Builder 实习面试：31 问深挖项目与 Agent 权限

时间: 2026-10
来源: 牛客网

《面试题目》

请自我介绍一下。
你是不是 03 年的？
你住在哪里？
老家是哪的？
高中在哪上的？
研究生论文压力大不大？
能实习多长时间？
你怎么理解 AI Native Builder 这个岗位？
你平时开发用什么 AI 工具？
讲一个你花功夫最多、印象最深的项目？
这个项目工期多久？
这个系统的架构怎么设计？
你们团队怎么分工、怎么协作？
第二个系统（质量数据系统）是你一个人开发的吗？
你说的「数据处理」具体指什么？
意图识别是怎么做的？
数据怎么路由到对应部门？
这个系统的架构也是你负责的吗？
怎么保证 Agent 不执行「导出所有供应商及员工敏感数据」这类指令？
敏感数据权限怎么控制？
工具调用怎么做权限校验？
Agent 越权怎么解决？
知识库怎么设计？
文档怎么切分？
怎么检索？
知识库的权限怎么控制？
内部文档给 Agent 用，有没有考虑泄露？
如果文档做倒排或索引，怎么同时解决切分和权限？
关键词/倒排的局限在于，「苹果」和「apple」匹配不上怎么办？
整体要把 Agent 效果提上来，除了换模型、加约束，还能怎么优化？
手撕：写一个敏感数据导出拦截函数（伪代码即可）。

《参考解析》

先看清这份面试的结构。 前半段是个人信息的连续追问（年级、住址、老家、高中、论文压力、可实习时长），这部分不考技术，考的是实习可行性与稳定性——面试官在判断你能不能真的来、能来多久、会不会中途因为论文或异地断掉。回答要直接给确定信息：能实习的起止时间、每周到岗天数、论文进度和预计答辩时间，含糊其辞（「看情况」「应该可以」）反而是减分项。

后半段才是有信息量的部分，主线只有一条：这个人做过的系统，以及他有没有能力让 Agent 在权限边界内干活。从「数据处理具体指什么」「意图识别怎么做的」「数据怎么路由到部门」到「知识库怎么切分、怎么检索、权限怎么控」，问的都是同一件事的上下游。

怎么理解 AI Native Builder 这个岗位。 这个角色的核心不是「会用 AI 工具写代码」，而是用 AI 原生的方式把一个需求端到端做成能跑的东西：过去做一个内部系统要产品、后端、前端、算法分工排队，现在一个人带着 Agent 就能把数据管道、检索、权限、界面串起来。所以回答里要体现三件事——一是端到端交付的意识和能力（从需求到上线你一个人能覆盖多少），二是对工具链的熟练度（知道你用什么、为什么用它、它的边界在哪），三是对工程约束的敏感（权限、数据边界、可维护性这些不会因为用 AI 就消失，反而更需要人来把关）。回答「平时开发用什么 AI 工具」时别只报名字，要讲清分工：哪类任务用 IDE 补全、哪类用带仓库上下文的 Agent、哪类只用来做方案讨论，以及你怎么验证它给的代码。

项目深挖要按「一句话定位 → 数据流 → 我的边界 → 量级」来答。 被问到「这个系统的架构怎么设计」时，先给一句定位（这个系统解决谁的什么问题），再按数据从哪来、经过什么处理、落到哪、被谁消费讲一遍，最后明确自己负责的那一段以及和团队的分工边界。追问「是你一个人开发的吗」时如实说，不是一个人就讲清协作方式（谁定接口、怎么联调、代码评审怎么做）。「花功夫最多的项目」「工期多久」这类问题背后是在核验真实性，数字口径要提前想好：多少人月、多少数据量、多少 QPS、上线后指标变化多少，每一个数字都要能被追两层。

意图识别与数据路由。 意图识别通常有三条路：规则/词典匹配（可控、可解释，但泛化差）、模型分类（泛化好，但要标注数据、有长尾和置信度问题）、两者混合（高频走规则、不确定的落模型，低置信度转人工）。工程上真正要讲的是兜底与可回归：置信度阈值怎么定、误判落到哪个兜底分支（转人工或反问澄清）、上线后怎么通过 badcase 回流迭代。数据路由到部门则是一个映射加规则的问题：意图或字段命中路由表决定去哪，多部门交叉时按主责加抄送处理，还要有人工改派入口和路由日志，否则出了错根本查不出是谁分错了。

Agent 敏感数据防导出：拦截要做在哪些层。 这类题的关键认知是「别指望靠一句提示词拦住模型」，防线要分层：

输入侧——检测用户输入里的越权意图（如「导出全部供应商和员工信息」），命中高风险模式时不下发工具、直接走审批或拒绝话术；同时对提示注入做隔离，外部文档内容只当数据、不当指令。
工具侧——高风险工具（导出、批量查询、对外发送）单独建工具，参数用 schema 严格约束并做上限校验（最大行数、最大时间范围、字段白名单、必须带明确的对象 id），禁止「无条件全量导出」这种调用形态；给模型看到的工具描述里写清适用场景与禁止事项。
执行侧——用调用者的身份去查数据，而不是用服务账号；在数据访问层做行级/列级权限过滤，敏感字段按需脱敏；每次调用落审计日志（谁、什么时间、什么参数、返回多少行）；超过阈值触发二次确认或人工审批。

伪代码的思路大致是：check(user, tool, params) → 先看用户有没有这个工具权限，再看参数是否落在允许范围（对象、字段、行数上限），再看数据本身是否需要脱敏或审批，任一不通过就返回拒绝原因并记审计，全部通过才真正执行，执行结果再按权限做字段裁剪和行数截断。要点是把「能不能导出」变成确定性的代码判断，而不是交给模型自觉。

工具调用权限校验与越权防护。 权限校验不能放在提示词里，要放在工具执行前后的代码里：① 身份传递——用户身份一路带到数据层，下游按这个身份做校验（不要用服务账号一把梭）；② 工具级 ACL——角色到工具的授权表，工具上线时就要定义好谁能调；③ 参数级校验——目标对象是否属于该用户可访问的范围（常见的越权是「参数里换个 id 就能看别人的数据」，所以要做对象级鉴权，而不只是接口级）；④ 最小权限——能只读的就不给写，能查单条的就不给批量；⑤ 审计与告警——异常频次、大批量拉取、敏感字段访问要能告警。另一个常被忽略的点是间接越权：Agent 通过检索把不属于该用户的文档带进上下文，等于绕过了数据权限，所以检索环节也要带权限过滤。

知识库：切分、检索、权限要一起设计，不能各做各的。 切分上按文档结构（标题层级、表格、代码块）切，再对超长段落做语义切分，保留一定重叠避免答案被切断；每个 chunk 都要带上元数据——文档 id、所属部门、密级、可访问角色、版本与时间，这些元数据是后面做权限和过滤的基础。检索上用混合检索：向量召回语义相近的内容，BM25/倒排召回精确词和专有名词，两路结果合并后过 rerank 取 Top-K，再按 token 预算塞进上下文。权限要做成检索前过滤（pre-filter）而不是检索后裁剪：把用户的角色与可访问范围变成检索的过滤条件，从候选集里就排除无权文档；否则「先召回再删掉」既浪费上下文，也容易在摘要或引用环节泄露。文档给 Agent 用确实存在泄露风险，所以还要考虑输出侧过滤（响应里出现高密级字段就拦截）、日志脱敏，以及把「只读检索」和「可执行动作」分开授权。

倒排索引怎么同时解决切分与权限，以及「苹果」和「apple」怎么办。 倒排索引本身是按词到文档的映射，切分带来的影响是粒度：如果一个 chunk 太长，命中一个词就带出整段；太短又丢上下文。可行的做法是双粒度索引——段落级做检索定位，文档级做权限与版本归属，chunk 里存文档 id，检索时先用权限标签过滤候选文档，再在候选文档的 chunk 里做打分。纯关键词/倒排的局限是字面不匹配（「苹果」和「apple」、同义词、缩写、中英混写、错别字都召回不了），解决办法通常是几层叠加：查询归一化与分词（大小写、全半角、繁简、中英标点）、同义词与别名词典、查询改写/扩展（用模型把 query 扩成若干等价表达）、引入向量检索做语义召回并与倒排结果融合，最后用 rerank 排序。只靠倒排或只靠向量都会漏，混合检索加 rerank 是当前更稳的默认解。

除了换模型、加约束，还能怎么把 Agent 效果提上来。 按投入产出排，最先动的往往不是模型：① 数据与知识——切分粒度、元数据完整性、脏数据与过期文档清理、把答案直接写清的「事实型文档」，这是最常见的效果瓶颈；② 检索——混合召回加 rerank、查询改写、按问题类型路由到不同索引；③ 上下文组织——只放相关的片段、把长期事实外置成结构化数据、控制历史长度，避免注意力被稀释；④ 工具设计——工具粒度、命名与描述（模型选错工具多半是描述没写清）、参数 schema 的约束强度、错误信息回灌让模型自修正；⑤ 流程拆解——把一步到位的大任务拆成先规划再执行的子步骤，确定性环节用代码或 workflow 固定；⑥ 评测与回归——建一批带标准答案的真实任务跑回归，否则每次改动都是凭感觉，改好一个坏一个；⑦ 路由分级——简单问题走小模型或规则、复杂问题才上大模型，同时降成本与延迟；⑧ 人机协同——低置信度转人工、给用户一个「接着改」的交互入口，比硬把不确定性都压在模型身上更实在。

手撕拦截函数的答题要点。 面试官要看的不是完整实现，而是你有没有把权限当成确定性逻辑写下来：入参要有调用者身份、工具名和参数；先做身份与工具 ACL 校验，再做参数范围校验（对象归属、字段白名单、行数上限），再做数据级鉴权与脱敏策略，任一步不过就返回结构化的拒绝原因并写审计日志，通过后执行并在返回前按权限裁剪字段。写的时候把「拒绝原因分类」和「审计」这两块带上，比多写几行业务判断更能体现工程意识。

《面试题目》

《参考解析》

相关面经