AI 面试模块
OpenClaw、MCP 与工具生态面试模块
围绕 OpenClaw、小龙虾、MCP、Skills、飞书集成和本地自动化工具，整理面试可讲的架构与落地问题。
视频里 OpenClaw、小龙虾、Skills、MCP 和飞书集成出现很多次。面试中这类内容不能只讲“装了一个工具”，要上升到 Agent 工具生态：工具如何暴露能力、如何约束权限、如何接入办公系统、如何处理本地环境和异常。
#概念速记
| 概念 | 面试表达 |
|---|---|
| OpenClaw/小龙虾 | 面向本地和办公自动化的 Agent 工具环境，可通过插件、Skills 和配置扩展能力 |
| Skill | 对某类任务的流程封装，通常包含说明、脚本、模板和工具调用规范 |
| MCP | Model Context Protocol，用标准协议把外部工具、数据源和资源暴露给模型或 Agent |
| 飞书集成 | 把 Agent 放到协作入口，处理消息、审批、文档、通知或自动化任务 |
| 配置文件 | 管理工具、权限、环境变量、模型、任务参数和运行策略 |
#高频问题与参考回答
#MCP 解决什么问题？
MCP 解决的是模型和外部工具之间的标准化连接问题。没有标准协议时，每个工具都要单独适配；有 MCP 后，工具可以用统一方式暴露资源、函数和上下文，Agent 能更容易发现和调用能力。工程上还需要处理鉴权、权限、超时、审计和错误格式。
#Skill 和普通脚本有什么区别？
普通脚本只解决一次执行，Skill 更像“可复用任务能力包”。它不仅包含脚本，还包含何时使用、输入输出、约束、依赖和验证方式。面试回答可以说：Skill 的价值是把经验流程固化，让 Agent 在类似任务中稳定复用。
#飞书接入 Agent 要注意什么？
首先是鉴权和回调验证，避免伪造请求。其次是消息幂等，防止重复处理。第三是异步任务，因为模型调用可能较慢。第四是权限边界，Agent 不能随意读写所有文档或群聊。第五是可观测性，每次自动回复、文档修改和失败都要记录。
#本地自动化工具为什么容易出问题？
本地环境差异大，包括操作系统、依赖版本、浏览器权限、文件路径、网络代理、模型 Key、杀毒软件和沙箱限制。成熟做法是提供安装检查、依赖诊断、最小可运行示例、日志路径和卸载/恢复流程。
#项目追问
- 你如何给工具设计参数 Schema？
- 工具执行失败时错误如何返回给 Agent？
- 是否区分只读工具和写入工具？
- 外部系统凭证如何保存，如何避免泄漏？
- 飞书消息重复推送如何幂等？
- 用户取消任务后，后台模型调用和工具任务怎么终止？
- 如何让不同 Agent 共享同一套工具能力？
#可讲项目案例
一个办公自动化 Agent 可以这样描述：用户在飞书发送任务，服务端验证回调后创建异步任务；Agent 根据任务类型调用文档检索、网页读取、表格处理或文件整理工具；每个工具都通过 Schema 校验参数，写操作需要用户确认；最终结果回传飞书，并把执行日志、Token 成本和失败原因写入审计表。
#面试中要避开的坑
- 不要把 MCP 讲成某一个具体工具，它更像协议和连接层。
- 不要说 Agent 可以无限制控制电脑，生产环境必须有权限边界。
- 不要只讲安装教程，要讲配置、诊断、日志、权限和安全。
- 不要把飞书接入当成简单 Webhook，企业协作入口必须重视鉴权、幂等和审计。
#MCP 工具接入的工程链路
面试里可以把 MCP 接入讲成一条链路：工具服务先定义可调用能力，包括名称、描述、参数和返回值；Agent 在运行时发现这些能力；模型根据任务选择工具并生成参数；工具服务执行后返回结构化结果；Agent 根据结果继续推理或结束。这里最关键的是“协议标准化”和“权限可控”，而不是某个工具本身。
#配置文件应该包含什么
配置文件不是随便写几个 Key。一个成熟的 Agent 工具配置通常包括模型配置、工具开关、权限范围、环境变量引用、日志级别、任务默认参数、超时、重试和安全策略。面试中可以强调：敏感信息不应该直接写进配置文件，应使用环境变量、系统 Keychain 或密钥管理服务。
| 配置项 | 示例 | 面试关注点 |
|---|---|---|
| 模型 | 模型名、温度、最大 Token | 可切换、可灰度 |
| 工具 | 文件、浏览器、飞书、搜索 | 最小权限原则 |
| 运行 | 超时、最大步骤、预算 | 防循环、防失控 |
| 安全 | 白名单、审批、脱敏 | 防误操作、防泄漏 |
| 日志 | Trace、错误码、审计 | 可定位、可追责 |
#飞书集成细节
飞书类办公集成一般有三类入口：机器人消息、文档/表格事件、审批或任务通知。消息入口要处理签名校验、重复事件、异步回复和用户权限；文档入口要处理协作者权限、版本冲突和编辑审计；通知入口要避免刷屏，并支持任务状态查询。真正可落地的回答要包含“幂等键”，例如用 event_id 或 message_id 防止重复执行。
#本地自动化的安全边界
本地工具可以提高效率，但风险比普通 Web API 更高。建议把能力分层：读取文件、整理文件、执行脚本、控制浏览器、发送外部消息。每一层都需要不同确认级别。删除文件、覆盖文件、提交表单、发送消息、上传资料这类操作应默认需要人工确认。
#故障诊断路径
当 OpenClaw 或类似工具安装/运行失败，可以按环境、依赖、配置、网络、权限、日志五步排查。环境看操作系统和版本；依赖看 Node/Python/浏览器/扩展；配置看路径、Key 和格式；网络看代理和接口连通；权限看文件、麦克风、辅助功能或浏览器控制；日志看具体错误码和堆栈。这个排查路径比背安装教程更有面试价值。
#MCP 三类核心能力
MCP 面试要讲清 Tools、Resources、Prompts 的边界。Tools 是模型可调用的动作，例如查数据库、发请求、写文件；Resources 是服务端暴露给客户端的上下文，例如文件、数据库 schema、业务文档；Prompts 是可复用的提示模板，通常由用户显式选择。把三者混在一起，会显得只会用工具但不懂协议。
| MCP 能力 | 作用 | 设计重点 |
|---|---|---|
| Tools | 执行动作或调用系统能力 | 参数 Schema、权限、超时、错误码 |
| Resources | 暴露上下文数据 | URI、MIME、访问控制、更新时间 |
| Prompts | 提供可复用任务模板 | 参数校验、用户触发、注入防护 |
#MCP Server 架构
一个 MCP Server 可以按四层设计：协议层处理 JSON-RPC 和 capability negotiation；能力层注册 tools/resources/prompts；适配层连接本地文件、数据库、HTTP API、飞书等外部系统；安全层处理鉴权、最小权限、审计、脱敏和速率限制。面试时不要只讲“接一个 server”，要讲 server 背后的权限边界。
#MCP 安全风险
MCP 的风险来自“模型可以连接更多真实系统”。典型风险包括硬编码凭证、长生命周期 token、命令注入、工具投毒、上下文里的间接 Prompt Injection、跨用户上下文泄漏和过度授权。最佳实践是：工具默认只读，写操作审批；凭证不进模型上下文；工具描述不可被用户输入覆盖；日志不记录完整密钥和敏感内容。
#调试和验收
MCP 工具上线前要用 Inspector 或等价工具逐项验收：工具列表是否正确、参数是否有必填和枚举、错误是否结构化、资源 URI 是否能按权限读取、Prompt 参数是否校验、异常场景是否返回标准错误。验收通过后再接入 Agent，而不是直接让模型试用生产工具。
#候选人自检清单
- 能否在 2 分钟内讲清楚这个模块解决什么业务问题、为什么不是简单调用模型 API。
- 能否说清输入、处理、模型调用、后处理、评测、监控、回滚的完整链路。
- 能否给出至少一个真实项目指标，例如召回率、命中率、延迟、Token 成本、人工复核通过率或线上失败率。
- 能否解释一个失败案例：问题如何发现、如何定位、怎么修复、修复后用什么指标验证。
- 能否区分“学习过概念”和“真正落地过系统”，面试回答要用具体约束、权衡和数据支撑。