网易易盾技术支持实习生一面：Agent 平台项目深挖与客户沟通场景

《面试题目》

1. 自我介绍，介绍实习和项目经历
2. 介绍校园 Agent 平台：为什么做、解决什么问题？
3. 项目团队有几个人？
4. 每个用户的独立 Agent 如何隔离，具体隔离什么？
5. 平台部署在哪里，用了哪些模型？
6. 用户发出请求后，整个 Agent 调用链是怎样的？
7. 185 个工具如何封装？学校接口和数据库权限怎么获取？
8. 为什么用 RAG 检索工具，和 Skills 有什么区别？
9. 文本和多模态请求如何分流，分流规则怎么写？
10. 平台支持单轮还是多轮问答？上下文过长怎么处理？
11. 项目中最大的坑是什么？排查或解决过哪些难题？
12. 对公司业务的了解？
13. 对技术支持岗位的理解？
14. 目前的学历和年级？毕业后读研还是工作？
15. 未来职业规划，更倾向开发还是半开发、半业务？
16. 每周能实习几天，最快什么时候到岗？
17. 遇到解决不了的问题如何求助？会先自己尝试还是直接问？
18. 客户描述问题模糊、情绪着急时，如何处理？
19. 问题排查了几个小时仍没有结论，如何处理？
20. 反问：团队的 AI 使用情况、面试结果反馈时间

《参考解析》

多用户 Agent 的隔离要分四层答，不能只说「一个用户一个实例」。 ① 数据隔离：会话历史、记忆、上传文件、工具调用结果都要带租户/用户维度，查询强制按用户 id 过滤（服务端强制，不接受客户端传参），共享向量库要用元数据过滤或独立集合。② 上下文隔离：不同用户的 Agent 循环互不污染（各自的 messages 与 state），共享的是无状态的模型调用与工具注册表；并发跑时注意每会话的资源配额（token、步数、并发数）。③ 权限隔离：工具调用的授权要落到「这个用户通过这个 Agent 能访问哪些学校接口与数据」——不能在服务端用一把万能密钥替所有用户调用，否则一个用户就能通过 Agent 越权查到别人的数据；正确做法是把用户身份透传到工具层做鉴权（token 互换或按用户签发短时凭证），并在工具注册表里标注所需权限。④ 资源与故障隔离：限流、配额、超时按用户隔离，一个用户的死循环或大请求不能拖垮其他人（独立队列或按租户加权调度）。185 个工具的封装要讲清统一的工具契约（name/description/JSON Schema 参数/返回值约定/超时与错误语义）、分类与按需挂载（不能 185 个全塞进上下文，否则选择准确率骤降）、以及权限标注与审计日志。RAG 检索工具与 Skills 的区别：RAG 是运行时按查询去检索知识（动态、随数据更新、结果不确定），Skill 是预先写好的能力说明与流程文档（静态、随代码版本发布、告诉模型「这类任务该怎么做」）；前者解决「我不知道这件事」，后者解决「我知道但不知道怎么按你们的规范做」。实践中两者互补：Skill 里可以规定「遇到 X 先检索 Y 知识库再回答」。

文本与多模态请求的分流规则，判据要写清楚而不能让模型自由发挥。 常见规则：请求里带图片/音频/文件 → 走多模态链路（选择支持视觉/音频的模型，做 OCR/ASR 预处理，把提取的文本与原始媒体一起送入）；纯文本且长度短、要求低延迟 → 走小模型；需要工具调用或长上下文 → 走带工具的强模型；涉及安全审核的内容先过审核链路。规则可以写成「显式路由表 + 规则引擎」（确定性、可测、可灰度），把模型只用在真正需要判断的地方（比如意图分类），并保留人工可配置的开关；工程上要记录路由决策与命中原因，便于排查「为什么这次走了这条路」。上下文过长的处理按优先级：先做检索式裁剪（只放与当前问题相关的片段）、再对历史做结构化压缩（保留事实/决策/约束，丢弃寒暄与重复）、对工具返回值限长并摘要、最后才滑窗截断，并明确告知模型「上下文已截断」。「项目中最大的坑」这类问题要用 STAR 讲一个具体的技术难题：现象（错误表现与影响面）、定位过程（怎么二分、加了什么日志/埋点、排除了哪些假设）、根因、修复与防复发（加了什么监控或测试）。技术支持岗特别看重「能不能把复杂问题讲清楚」和「有没有把一次性问题变成机制」的自觉。

沟通场景三问的答法。 「遇到解决不了的问题如何求助」：先做有限度的自主排查（明确时间盒，比如 30 分钟，查文档/日志/历史工单），带着已排除的假设 + 现象证据 + 已尝试的动作去求助，而不是把原始问题原样抛出；同时说清求助对象的选择（同事、研发、官方支持），并事后补充到知识库。「客户描述模糊、情绪着急」：先安抚与承接情绪（不辩解、先确认影响面），再用结构化提问把模糊描述变成可复现信息（什么时候、什么操作、什么现象、期望是什么、错误码/截图），给出明确的处理时间点与后续同步节奏；对无法立刻解决的，先给可用的临时规避方案。要紧的是不要与客户争论对错，先把事实固定下来。「排查几小时无结论」：停下来复盘假设是否一开始就错了、请求帮助、把问题升级并同步给客户一个明确的进展与预期时间；同时评估是否需要先止损（回滚、降级、临时开关）而不是继续深挖。技术支持岗位的评判标准通常不是「你技术多强」，而是响应是否及时、沟通是否清晰、是否会做闭环（记录到知识库/推动修复），回答里要把这三点体现出来。