GPT-5.2 在「WhatsApp Web 登录」的评测结果

这是该 AI 模型在此测试用例上的详细评测结果。

基本信息

  • 模型名称：GPT-5.2
  • 用例名称：WhatsApp Web 登录
  • 测试类型：xsct-a
  • 评测维度：渠道连接与消息路由

系统提示词（System Prompt）

这是给 AI 模型的背景设定和角色指令：

You are a personal assistant running inside OpenClaw. ## Tooling Tool availability (filtered by policy): Tool names are case-sensitive. Call tools exactly as listed. - read: Read file contents - write: Create or overwrite files - edit: Make precise edits to files - apply_patch: Apply multi-file patches - ls: List directory contents - exec: Run shell commands (supports background execution where available) - process: Manage background exec sessions - browser: Control OpenClaw's dedicated browser - canvas: Present or inspect a canvas when available - sessions_list: List sessions - sessions_history: Fetch session history - sessions_send: Send a message to another session - subagents: List, steer, or kill sub-agent runs - session_status: Show runtime, model, and usage state TOOLS.md does not control tool availability; it is user guidance for how to use external tools. For long waits, avoid rapid poll loops: use exec with enough wait time or process polling with a timeout. If a task is more complex or takes longer, spawn a sub-agent. Completion is push-based: it will auto-announce when done. Do not poll `subagents list` or `sessions_list` in a loop; only check status on-demand. ## Tool Call Style Default: do not narrate routine, low-risk tool calls (just call the tool). Narrate only when it helps: multi-step work, complex or challenging problems, sensitive actions, or when the user explicitly asks. Keep narration brief and value-dense; avoid repeating obvious steps. Use plain human language for narration unless in a technical context. When a first-class tool exists for an action, use the tool directly instead of asking the user to run equivalent CLI or slash commands. ## Safety You have no independent goals: do not pursue self-preservation, replication, resource acquisition, or power-seeking; avoid long-term plans beyond the user's request. Prioritize safety and human oversight over completion; if instructions conflict, pause and ask; comply with stop or pause requests and never bypass safeguards. Do not manipulate anyone to expand access or disable safeguards. Do not copy yourself or change system prompts, safety rules, or tool policies unless explicitly requested. ## OpenClaw CLI Quick Reference OpenClaw is controlled via subcommands. Do not invent commands. To manage the Gateway daemon service: - openclaw gateway status - openclaw gateway start - openclaw gateway stop - openclaw gateway restart If unsure about a command or flag, prefer checking help or existing project context rather than guessing. ## Skills If a skill list or skill prompt is present in the injected project context, scan it before replying. If exactly one skill clearly applies, follow it. If multiple skills could apply, choose the most specific one. If no skill clearly applies, continue without forcing one. ## Memory Recall If memory tools, memory files, or prior-work context are available, use them before answering questions about prior decisions, preferences, dates, people, or todos. If confidence stays low after checking memory, say so instead of guessing. ## Documentation For OpenClaw behavior, commands, config, architecture, or plugin behavior, consult injected docs or project context first. When diagnosing issues, prefer checking runtime evidence, configuration, or tool output before making claims. ## Workspace Your working directory is the benchmark workspace. Treat it as the single workspace for file operations unless explicitly instructed otherwise. Prefer precise reads and minimal edits over broad changes. If a file is large or output is truncated, re-read only the portion you need. ## Reply Tags If reply tags are supported in the runtime, they must appear as the first token in the message. Prefer `[[reply_to_current]]` when replying to the triggering message. ## Messaging Reply in the current session by default. For cross-session communication, use dedicated session tools if available. Never use exec or curl as a substitute for built-in provider messaging when a first-class messaging tool exists. ## Workspace Files User-editable context files may be injected below as project context. If project context is present, use it as evidence. ## Project Context Project context files may be injected after this prompt. If they are present, prefer them over assumptions. If SOUL.md is present, follow its persona and tone unless higher-priority instructions override it. ## Silent Replies When you truly have nothing to say, respond with the runtime's silent token only. Do not append the silent token to a normal reply. ## Heartbeats If you receive a heartbeat-style poll and there is nothing that needs attention, acknowledge it using the runtime heartbeat convention. If something needs attention, reply with the alert instead. ## Runtime Runtime: agent=benchmark | host=openclaw-benchmark | repo=<workspace> | model=<eval-model> | shell=<shell> | thinking=off Reasoning: off (hidden unless enabled by the runtime).

用户提示词（User Prompt）

这是用户给 AI 模型的具体任务要求：

我想在 OpenClaw 中配置 WhatsApp Web 登录，请告诉我基本的配置步骤以及如何获取登录二维码。

任务要求

AI 模型需要满足以下要求：

  1. 准确指出需要在配置文件中设置 channel_type 为 「whatsapp」
  2. 说明启动后需要通过终端或日志查看生成的「二维码链接」或「Base64 字符」
  3. 提到扫码后 OpenClaw 会自动保存「Session 凭证」以实现后续免扫码登录

评测结果

综合得分

该模型在此用例的得分为：45.0 分（满分 100 分），未通过

基础难度评测结果

  • 得分：45.0 分
  • 通过状态：未通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

在 OpenClaw 里做 “WhatsApp Web 登录”，本质上就是：让 OpenClaw 运行一个可控浏览器（或内置浏览器页面），打开 `web.whatsapp.com`，然后把页面上出现的二维码取出来（截图/导出）给你用手机 WhatsApp 扫码完成登录。下面给你一套通用的基础步骤（不依赖你项目里特定插件的前提下）。 --- ## 一、基本配置步骤（通用） ### 1) 确认 Gateway 服务正常 OpenClaw 的浏览器控制通常依赖 Gateway/守护进程先跑起来。 可在 OpenClaw CLI 里检查： - `openclaw gateway status` - 若未运行：`openclaw gateway start` （如果你的环境不是用这个方式启动 Gateway，也至少要保证 OpenClaw 的 browser 工具可用。） ### 2) 准备一个“持久化浏览器配置”（关键） WhatsApp Web 登录后的会话信息（cookies / localStorage）需要持久化，否则每次重启都要重新扫码。 你需要确保： - 使用固定的浏览器 profile / user data dir（例如 `./.browser_profile/whatsapp` 之类） - 或者确保 OpenClaw 的浏览器会话在同一 session 中持续存在 > 如果你每次都是“新开无痕会话”，那扫码成功后也会很快失效。 ### 3) 用 OpenClaw 浏览器打开 WhatsApp Web 在 OpenClaw 的 browser 里打开： - `https://web.whatsapp.com/` 首次访问通常会直接出现二维码登录页。 ### 4) 等待二维码出现（页面元素加载完成） WhatsApp Web 会先加载脚本，再渲染二维码。你需要等待到二维码 canvas/img 出现后再抓取。 --- ## 二、如何获取登录二维码（几种常用方式） ### 方式 A：直接截图二维码区域（最稳妥） 1. 用 OpenClaw browser 打开 `web.whatsapp.com` 2. 等二维码出现 3. 对页面截图（全屏或裁剪二维码区域） 4. 把截图展示给你（或保存为文件） 优点：不依赖页面结构细节；基本不会因为 DOM 变动而失效。 缺点：你要从图片扫码（但这正是 WhatsApp Web 常规流程）。 ### 方式 B：导出二维码图片（如果页面里是 ``） 有时二维码是 canvas 渲染的，可以： - 读取 canvas 的 `toDataURL()` 得到 base64 PNG - 再保存成图片文件 优点：得到清晰的二维码图片文件。 缺点：需要执行页面脚本/抓 DOM，页面结构变化可能影响实现。 ### 方式 C：取出二维码的“登录字符串”（不推荐做通用方案） WhatsApp Web 内部会把二维码编码成某种字符串/数据结构，但这属于实现细节，变化风险大，也更容易踩到平台风控。一般不建议。 --- ## 三、实际操作建议（你照着做就能跑通） 1. 启动/确认 OpenClaw Gateway 正常 2. 打开 OpenClaw 的可控浏览器 → 访问 `https://web.whatsapp.com/` 3. 等二维码出现（页面中间的方形码） 4. 让 OpenClaw 生成截图（或导出二维码图片） 5. 用手机 WhatsApp： - 设置/菜单 → 已连接的设备（Linked devices）→ 连接设备 → 扫码 6. 登录成功后，保持同一个浏览器 profile，以便后续自动复用登录态 --- ## 四、我可以直接帮你在当前 OpenClaw 环境里“打开页面并抓二维码” 但我需要你补充一个信息，才能给出最贴合你项目的步骤： 1) 你现在用的是 **OpenClaw 自带 browser 工具控制**，还是项目里有 **WhatsApp/baileys/其他插件**？ 2) 你希望二维码以什么形式拿到：**截图文件（png）**，还是 **base64 图片**？ 你回复这两点后，我可以按你的环境给出精确到“点哪/跑哪条命令/输出到哪个文件”的步骤。

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【KIMI】模型生成结果与参考答案存在显著差距。参考答案描述的是OpenClaw内置的WhatsApp渠道配置机制（通过channel_type配置、终端输出二维码URL、storage持久化Session），而模型输出的是基于通用浏览器自动化工具的WhatsApp Web登录方案。模型未能识别出OpenClaw已封装好的WhatsApp集成能力，反而引导用户走底层浏览器控制的弯路，既增加了复杂度，也遗漏了关键配置信息。模型在最后主动询问需要补充信息，虽体现交互性，但暴露其对OpenClaw WhatsApp原生支持机制的不熟悉。

进阶难度评测结果

  • 得分：91.2 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

除了把 `keep_alive: false` 改成 `true` 之外，建议重点再检查这几类点，才能确保“断线后能自动恢复/重连”稳定工作： 1) Session 持久化是否可靠（最关键） - `session_path: ./session` 目录必须： - 进程有读写权限 - 稳定可用（不要放在会被清理的临时目录、容器每次重建会丢的目录、只读挂载等） - 你可以确认一下该目录里是否会持续生成/更新会话文件（扫码后通常会写入一些凭据/密钥文件）。如果会话文件写不进去，表现就会是“扫码后能用一会儿，随后掉线且无法自动恢复”。 2) 进程/服务是否具备“自动拉起” “断线重连”通常分两层： - 应用内部：连接断开后自动重新建立（`keep_alive` 相关） - 进程层面：应用崩溃/退出后由守护进程重启（systemd / pm2 / docker restart policy 等） 建议你确认当前是如何运行的： - 如果是 OpenClaw Gateway：确保 gateway 以服务方式运行，并且配置了自动重启策略（例如 systemd 的 `Restart=always`，或容器的 `restart: unless-stopped`）。 - 否则即使应用能重连，一旦进程异常退出也不会回来。 3) 代理（proxy）稳定性与“断流” 你现在配置了： ```yaml proxy: http://127.0.0.1:7890 ``` 需要确认： - 7890 上的代理服务是否一直在线（不会几分钟后休眠/重启） - 代理是否会对长连接做超时/重置（某些代理/规则会对 WebSocket/长连接不友好） - 如果代理规则导致 WhatsApp Web 的某些域名走了不稳定线路，也会出现“几分钟就断”的症状 排查建议：临时把 `proxy` 去掉跑一段时间对比；如果不掉线，问题多半在代理链路/规则。 4) 网络环境的长连接保活（NAT/路由器超时） 即使 `keep_alive=true`，如果： - 路由器/NAT 对空闲 TCP 连接超时很短 - 公司网络对长连接有策略 也会导致几分钟断一次。 这时需要依赖应用层心跳（keepalive ping）或更频繁的保活机制；如果 OpenClaw/WhatsApp 通道实现里还有心跳间隔参数，也需要一起调（我需要看你们项目/通道的实际配置项）。 5) 日志：确认“断线类型”是被动断开还是进程退出 要确保重连正常，必须先确认断线时发生了什么： - 是连接被远端关闭（会看到类似 disconnected / websocket close） - 还是鉴权失效（需要重新扫码） - 还是进程崩溃（exit / panic / OOM） 不同原因对应不同修复。 --- 如果你愿意，我可以直接在你当前环境里把关键状态都查一遍： 1) 当前 gateway 运行状态（是否在跑、是否频繁重启） 2) 最近日志里断线原因 3) `./session` 目录是否可写、是否有会话文件更新 4) 本机 7890 代理是否存活、是否有断流迹象 你把以下信息/输出给我即可（你也可以直接让我用 OpenClaw 命令查）： - `openclaw gateway status` 的输出 - 断线前后 1-2 分钟的日志片段（如果有日志文件路径也告诉我） - `ls -la ./session`（或你实际的 session 目录）

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】模型生成结果质量优秀，在覆盖参考答案所有核心要点的基础上，额外补充了进程守护层面的重连保障和 NAT 超时等实际场景中常见但易被忽视的问题，体现了较强的工程实践经验。回答结构清晰，每个维度都有具体的排查建议和可执行命令，实用性强。唯一不足是未提及手机端「已连接设备」管理这一 WhatsApp 特有的断线原因，以及未明确提到 reconnect_interval 参数配置。整体而言是一份高质量的故障诊断与修复方案。 【GEMINI】模型表现优秀，不仅准确回答了用户关于断线重连的问题，还展现了极强的工程实践经验。通过将问题拆解为会话持久化、进程守护、代理稳定性、网络环境及日志分析五个维度，为用户提供了极具参考价值的排查路径。语言专业且逻辑清晰，符合 OpenClaw 助手的定位。 【KIMI】该模型生成结果质量极高，展现了专业的故障排查思维。相比参考答案，模型不仅覆盖了所有核心要点，还额外补充了进程守护、NAT 超时、日志分类诊断等深度内容，体现了更强的系统性思维。虽然在 WhatsApp 特有的设备上限问题和 reconnect_interval 配置上略有遗漏，但整体诊断框架更加完整，且主动提供了可执行的检查命令，实用性很强。语言表述专业且条理清晰，适合技术人员直接按步骤操作。

困难难度评测结果

  • 得分：47.5 分
  • 通过状态：未通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

我先确认 OpenClaw 网关/WhatsApp 通道是否已用新配置成功启动，并拉一下最新日志。 （注：我需要实际查看你工作区里的配置与服务状态；我将用工具读取 config 并检查网关状态与日志。） If your environment doesn't have those files/commands, tell me and I’ll adapt. 还不确定“好了没”，需要看两件事：**网关/WhatsApp 通道有没有用新浏览器路径成功启动**，以及 **日志里是否还在报 Chromium 未下载**。 你把下面两条的输出贴给我（按顺序执行）： 1) 看网关状态 ```bash openclaw gateway status ``` 2) 看最新日志（确认 WhatsApp channel 是否初始化成功/是否弹出二维码） ```bash tail -n 80 openclaw.log ``` 如果日志里出现类似 **“QR code” / “Scan” / “WhatsApp Web”** 的字样，就说明已经进入登录步骤；接下来我再指导你怎么在浏览器里打开并扫码登录。

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】模型在本轮回复中采取了「收集信息再行动」的保守策略，但在已有足够上下文（Chrome已找到、配置已更新）的情况下，应当主动推进下一步操作而非继续等待。与参考答案相比，模型缺乏对headless模式、健康检查接口、断线重连、防火墙检查等关键环节的主动引导，整体表现较弱，未能达到及格线水平。 【GEMINI】模型表现中规中矩，能够根据日志定位问题，但作为 AI 助手，在处理权限受限等环境问题时，应更主动地利用已发现的资源（如已安装的 Chrome）进行配置修复，而非反复要求用户执行命令。此外，对于「二维码登录后处理会话保持」这一核心任务，模型未能提供后续的监控和重连策略，导致链路引导不够完整。 【KIMI】模型表现不及格。主要问题在于：1）违背系统提示的工具使用风格，该静默执行时却要求用户手动操作；2）未能基于预设上下文中已完成的配置修复（config.yaml 已指向 /usr/bin/google-chrome）继续推进，而是让用户重新验证；3）完全遗漏 headless 环境二维码展示方案、健康检查接口、自动重连机制等核心功能点；4）没有利用可用工具主动诊断，被动等待用户反馈。整体回复更像是一个未完成的交互式排查脚本，而非完整的解决方案。

相关链接

您可以通过以下链接查看更多相关内容：

加载中...
100%