【“小龙虾”OpenClaw面试题，抓紧收藏、赶快吸收】

Q1、OpenClaw 是什么？

OpenClaw 是一个本地运行的多渠道 AI 网关，定位为‘个人 AI 助手平台’。它以 Gateway 形式运行在用户自己的设备（如 macOS 菜单栏、Linux VPS 或 Docker 容器）上，统一接入 WhatsApp、Telegram、Discord、飞书等 10+ 消息平台，并调度多模型、多 Agent，所有数据完全本地化，不经过第三方服务器。

Q2、OpenClaw 解决什么核心问题？

它解决的是 AI Agent 部署碎片化与隐私失控两大痛点：一是避免为每个消息渠道重复开发对接逻辑；二是防止对话数据、API Key 和上下文被托管在不可信的云服务中，实现真正的‘本地优先、隐私可控’的 AI 助手落地。

Q3、OpenClaw的五大核心能力是什么？

1. 多渠道统一接入（插件化 Channel 适配器）；
2. 多模型支持（Anthropic/OpenAI/Google/Ollama 等，含 fallback 机制）；
3. Agent 执行引擎（ReAct 风格循环，支持工具调用、流式输出、context 压缩与修剪）；
4. 插件化扩展体系（工具/渠道/Hook/Provider/Context Engine 均可热插拔）；
5. 本地优先架构（数据存本地 JSONL，API Key 自管，零第三方传输）。

Q4、OpenClaw 中一条用户消息的完整处理链路是怎样的？

链路分为四个阶段共 8 步：
1）渠道适配器接收原始消息；
2）转换为统一 MsgContext 结构；
3）dispatchInboundMessage 补全入站上下文；
4）resolveAgentRoute 匹配目标 Agent 和 Session Key；
5）斜杠命令检查（如 /new、/reset），命中则直接处理返回；
6）runReplyAgent 启动 Agent；
7）runAgentTurnWithFallback 执行 LLM+工具调用循环（构建提示→调 LLM→解析输出→执行工具→结果回传，循环直至最终回复）；
8）ReplyDispatcher 将回复投递回原渠道。

Q5、为什么需要幂等性保护？OpenClaw 是如何实现的？

为防止网络抖动导致渠道重复推送同一条消息，避免 Agent 多次执行产生副作用（如重复扣费、发消息）。OpenClaw 在 Gateway 层基于渠道唯一 ID（如 Telegram message_id）生成 idempotencyKey，重复请求直接返回缓存结果，Agent 不会被二次触发。

Q6、OpenClaw 的排队机制有哪两层？各自作用是什么？

两层排队：
1）enqueueSession（session 级队列）：保证同一 session 内消息串行执行，确保上下文连贯、回复逻辑一致；
2）enqueueGlobal（全局队列）：控制总并发数，防止突发流量打爆 LLM API，规避 OpenAI 等平台的 rate limit。

Q7、OpenClaw 支持流式输出吗？不同渠道是如何适配的？

支持流式输出。对原生支持 WebSocket 的渠道（如 Slack、Discord），通过实时下发 token 实现打字机效果；Telegram 不支持原生流式，OpenClaw 采用两种模拟策略：优先使用 Bot API 的草稿消息接口（sendMessageDraft），不可用时 fallback 到先发空消息再循环调用 editMessageText 逐步追加内容。

Q8、OpenClaw 的技能系统（Skills）如何解决上下文爆炸问题？

采用渐进式披露（Progressive Disclosure）：
1）元数据层（YAML frontmatter）始终轻量加载；
2）指令层仅在语义匹配命中时才加载完整技能；
3）资源层（脚本/模板等）按需拉取。配合会话压缩（Compaction）、Memory Flush 预存关键信息、Context Guard 截断大 tool result 等多重机制协同控 Token。

Q9、OpenClaw 曾发生过哪些重大安全事件？后续做了哪些关键加固？

2026 年 1 月底爆发 Shodan 暴露事件：数百个无认证（auth: none）实例裸露公网，导致对话泄露、API Key 窃取、命令越权执行。v2026.1.29 版本移除无认证选项，强制 Token/密码认证；新增 7 层工具策略管道（profile→group 逐级收窄）、owner-only 工具隔离、子 Agent 工具白名单，并被工信部及国家互联网应急中心列为高风险案例警示。