大厂 MCP 面试实录本地 AI 助手安全文件访问 MCP Server 设计本文采用模拟面试形式复盘大厂 MCP 相关岗位面试中针对本地 AI 助手安全文件访问场景的考察逻辑与回答思路。面试官今天我们考察的是本地 AI 助手场景下的 MCP Server 设计。业务需求是为本地部署的 AI 助手开发一个可安全访问用户本地文件的 MCP Server传输层要求用 stdio你先说说整体的设计思路候选人首先基于 MCP 的客户端-服务端架构本地 AI 助手作为 Host内置的 MCP Client 会启动本地的 MCP Server 子进程通过 stdio 传输层通信Server 从 stdin 读取 JSON-RPC 消息向 stdout 返回响应所有日志写入 stderr 避免破坏通信链路 [资料2]。能力设计上只读的文件读取操作适合封装为 Resource通过 URI 标识文件路径模型可直接读取上下文写文件、删除文件等有副作用的操作封装为 Tool明确操作语义与参数约束。安全层面首先做路径白名单限制只允许访问用户指定的根目录所有传入路径做标准化与遍历校验同时把模型传入的所有参数视为不可信输入服务端独立完成校验与权限判断 [资料1]。面试官你提到读文件用 Resource、写操作用 Tool为什么做这个区分如果我把所有文件操作都做成 Tool 是否可行候选人核心是语义匹配Resource 是只读的上下文供给天然符合文件读取的只读属性模型可通过 URI 模板直接访问无需额外调用逻辑减少不必要的模型调用成本Tool 用于有副作用的操作能明确暴露操作的风险与参数约束符合 MCP 的能力分类规范 [资料1]。全量做成 Tool 在功能上可行但存在两个问题一是读操作每次都需要模型发起调用增加交互成本二是 Resource 的 URI 模板可做路径前缀约束天然适配文件的层级结构而 Tool 需要额外在参数里做路径校验。但如果业务场景中读文件也需要鉴权、脱敏那 Resource 就不合适了——因为 Resource 默认不携带调用上下文无法关联用户身份此时读操作也需要封装为 Tool在参数中携带用户标识完成权限校验。面试官stdio 是本地子进程通信如果 Server 进程崩溃、或者传输中出现格式错误的 JSON-RPC 消息Client 侧需要做哪些处理你提到日志写 stderr这里面有什么容易踩坑的地方候选人首先是异常处理逻辑Client 侧需要监听 Server 子进程的退出状态非正常退出时要按退避策略自动重启避免频繁重启导致的资源雪崩针对 JSON-RPC 消息因为 stdio 是换行分隔的消息流 [资料2]需要做消息分片处理避免缓冲区未收全完整消息就解析导致失败遇到非法 JSON 时要返回对应的 JSON-RPC 错误响应且不能将错误内容写入 stdout避免污染后续通信链路。关于 stderr 日志的坑点第一绝对不能往 stdout 写入任何非 JSON-RPC 内容哪怕是一行调试 print 都会导致 Client 解析消息失败这是 stdio 传输最常见的踩坑点 [资料2]第二stderr 默认是无缓冲的日志量过大会占用 IO 资源甚至占满磁盘因此需要做日志级别控制生产环境仅保留 warn 及以上日志同时配置日志轮转策略。另外还要注意stdio 传输默认是同步请求-响应模式长耗时的文件读取操作需要设置超时时间超时阈值应根据业务 SLA 与压测结果确定超时后可以终止子进程或返回错误避免阻塞 Client。面试官现在用户可能让模型读取敏感文件比如 /etc/passwd 或者用户目录外的文件你怎么防止路径遍历如果遇到几个 G 的大文件直接读取全量内容传输会不会有问题候选人路径遍历的防护需要做三层校验第一Server 启动时配置允许访问的根目录比如用户主目录下的 Documents 文件夹所有传入的文件路径先通过标准化解析解析符号链接与..等相对路径片段再校验标准化后的路径是否在允许的根目录下从根源上避免越权访问第二校验当前进程对目标文件的读权限避免读取到无权限的系统文件第三参数 schema 仅做结构约束服务端必须独立完成路径校验不能信任模型传入的路径参数 [资料1]。针对大文件场景不能直接读取全量内容返回给模型否则会占满上下文窗口。可以做分块读取给读文件 Tool 增加 offset、limit 参数每次返回合适大小的内容片段由模型根据需求多次调用也可以结合 RAG 思路先对文件做切块、索引模型调用时仅返回相关的语义片段同时保留来源元数据支持引用与排错 [资料1]。举个例子参考 MCP Python SDK 的公开示例写法 [资料4]核心逻辑可以简化为伪代码# 伪代码文件读取工具的核心实现逻辑 ALLOWED_ROOT Path.home() / Documents mcp.tool() def read_file(path: str, offset: int 0, limit: int 1024 * 1024) - str: # 路径标准化与白名单校验 target_path (ALLOWED_ROOT / path).resolve() if not str(target_path).startswith(str(ALLOWED_ROOT.resolve())): raise ValueError(访问的路径超出允许范围) if not target_path.exists() or not target_path.is_file(): raise ValueError(文件不存在或不是普通文件) # 分块读取避免占满上下文 with open(target_path, r, encodingutf-8) as f: f.seek(offset) return f.read(limit)面试官stdio 是本地传输如果后续业务要支持多用户并发访问或者要把 Server 部署到远程服务器你的方案有什么问题怎么取舍候选人stdio 传输的本质是 Client 启动本机子进程天然只支持单实例、本机访问无法支持多用户并发也不适合远程部署。如果要支持多用户或远程场景需要切换到 Streamable HTTP 传输此时需要补充一系列远程能力首先是认证与授权每次请求都要校验用户身份且要做细粒度的权限控制不能因为请求来自 AI 应用就默认可信 [资料1]其次是会话管理、限流、超时控制避免单个用户的请求占用过多资源还要做租户隔离不同用户的文件目录互相隔离审计日志需要记录用户ID、调用的Tool、访问的资源范围、结果状态同时对敏感字段脱敏 [资料1]。但切换传输层的取舍也很明显stdio 方案实现简单、延迟低、无需额外网络配置适合本地单用户场景Streamable HTTP 方案复杂度高需要处理网络通信、安全、运维等问题适合多用户、远程部署的场景本地场景下不需要过度设计。面试官你提到高风险操作需要用户确认这个确认逻辑放在 Server 还是 Client 做如果模型试图跳过确认步骤直接执行怎么处理候选人确认逻辑必须放在 Server 端做因为 Server 是操作执行方最清楚操作的风险。Server 在执行写文件、删除文件等高风险操作时先返回一个需要确认的响应明确告知操作的影响比如“将覆盖 /home/user/docs/report.txt 的内容是否继续”Client 侧收到确认请求后弹出提示给用户用户确认后再向 Server 发送执行请求。如果模型跳过确认步骤直接发送执行请求Server 直接拒绝执行必须等 Client 携带确认标识的请求才能继续不能信任模型的调用流程。面试官点评 -考察点MCP 核心架构与三类能力的语义区分、stdio 传输的协议特性与边界、安全防护设计、异常处理与可观测性、方案扩展性权衡。 -合格回答能明确 Resource 与 Tool 的适用场景知道 stdio 传输的日志约束与消息格式要求能完成基础的路径遍历防护理解参数校验必须由服务端执行的原则。 -加分项能结合大文件场景设计分块读取/RAG 方案明确用户确认的落地方案能区分本地与远程场景的技术取舍考虑到审计日志的脱敏与子进程生命周期管理对 MCP 的安全边界有清晰认知。总结本地单用户场景下基于 stdio 传输的 MCP Server 实现成本低、延迟小核心是要守住安全边界把模型输入视为不可信输入做好路径校验、日志隔离、异常处理与用户确认流程。如果需要支持多用户或远程访问再切换到 Streamable HTTP 传输补充认证、授权、会话管理等能力避免过度设计。参考资料MCP 基础知识stdio | https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/stdioMCP Protocol Overview and Schema | https://modelcontextprotocol.io/specification/2026-07-28/basic/transportsMCP Python SDK | https://github.com/modelcontextprotocol/python-sdk