qwen3-max 在「Webhook 转标准消息」的评测结果

基本信息

• 模型名称：qwen3-max
• 用例名称：Webhook 转标准消息
• 测试类型：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 插件处理 Webhook 回调，收到的 JSON 包含「msg_id」和「content」，但我应该如何将其转换为 OpenClaw SDK 定义的标准消息对象，以确保「消息 ID」和「文本内容」能被核心正确识别？

任务要求

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

1. 明确指出需继承或使用的 OpenClaw SDK 消息基类
2. 正确映射「msg_id」到标准字段「id」或「message_id」
3. 正确映射「content」到标准字段「text」或「body」
4. 提及必须符合 OpenClaw 的 Schema 校验要求

评测结果

综合得分

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

基础难度评测结果

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

模型生成产物

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

在 OpenClaw 插件中，将 Webhook 回调的原始 JSON（含 `msg_id` 和 `content`）转换为 SDK 标准消息对象，关键在于**字段映射**和**使用正确的构造方式**。 OpenClaw SDK 的标准消息对象（通常为 `Message` 类或类似结构）期望特定的字段名。核心识别依赖于这些标准字段，而非原始 Webhook 的字段名。 以下是推荐做法： ### 1. **确认 SDK 消息对象的标准字段** OpenClaw SDK 的标准消息对象通常使用以下字段（具体请查阅你使用的 SDK 版本文档，但这是通用约定）： - **消息 ID**: `id` 或 `message_id` - **文本内容**: `text` 或 `content` > 📌 **重要提示**：尽管你的 Webhook 使用 `msg_id` 和 `content`，但 SDK 内部很可能期望 `id` 和 `text`。直接传递原始字段名会导致核心无法识别。 ### 2. **进行字段映射并构造消息对象** 在你的插件处理函数中，手动将 Webhook 字段映射到 SDK 期望的字段。假设你使用的是 Python SDK（逻辑适用于其他语言）： ```python from openclaw.sdk import Message # 假设这是 SDK 的消息类 def handle_webhook(webhook_json): # 从 Webhook JSON 提取原始字段 raw_msg_id = webhook_json.get("msg_id") raw_content = webhook_json.get("content") # 映射为 SDK 标准字段 sdk_message = Message( id=raw_msg_id, # 映射 msg_id -> id text=raw_content # 映射 content -> text (即使字段名相同，也显式指定) ) # 现在可以安全传递给 OpenClaw 核心 process_message(sdk_message) # 你的核心处理函数 ``` ### 3. **关键注意事项** - **不要直接传递原始 JSON**： 避免 `Message(**webhook_json)` 这种写法，因为 `msg_id` 不会被识别为消息 ID。 - **验证字段存在性**： 在映射前检查 `msg_id` 和 `content` 是否存在，避免空值错误。 - **查阅 SDK 文档**： 运行 `openclaw docs` 或检查项目中的 `SDK.md`（如果存在），确认确切的字段名。不同版本可能有差异（例如某些版本用 `message_id` 而非 `id`）。 - **类型一致性**： 确保 `msg_id` 是字符串（OpenClaw 通常要求 ID 为 string 类型）。 ### 4. **验证是否成功** 在插件日志中打印构造后的 `sdk_message` 对象，确认其 `id` 和 `text` 字段已正确赋值。如果核心仍无法识别，请检查： - 消息对象是否被传递到正确的处理管道（如 `gateway.send()`） - OpenClaw Gateway 是否运行正常（`openclaw gateway status`） > 💡 **总结**：核心原则是 **“Webhook 字段 ≠ SDK 字段”**。通过显式映射 `msg_id → id` 和 `content → text`，即可确保兼容性。如果仍有问题，请提供你的 SDK 版本和插件代码片段，我会进一步帮你排查。

AI 评审点评

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

【CLAUDE】模型的回答在结构和表达上较为专业，能够识别出「msg_id → id」的基本映射需求，但在 OpenClaw SDK 的具体协议细节上存在明显偏差——最关键的错误是将「content」映射为顶层「text」字段，而非参考答案要求的嵌套「content.text」（MessageContent 对象）结构。此外，SDK 类路径不准确，未提及 Schema 校验和消息适配器等核心概念。整体来看，回答具备一定参考价值但准确性不足，对于有明确 SDK 规范的场景可能产生误导。 【GEMINI】模型生成结果质量很高，不仅提供了直接的解决方案，还通过「重要提示」和「关键注意事项」补充了开发过程中的最佳实践。虽然在 SDK 具体的嵌套 Schema 细节上与参考答案存在微小差异，但其提供的代码逻辑完全能够实现目标，且具备极高的可操作性和专业度。 【KIMI】模型回答抓住了字段映射的核心思路，但在关键实现细节上偏离了参考答案：错误假设了 SDK 的模块路径和消息结构（平级 text vs 嵌套 content.text），且包含多处虚构信息（不存在的命令和文件）。建议加强对项目特定上下文的遵循，避免引入外部假设。

进阶难度评测结果

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

模型生成产物

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

我建议你根据 Webhook 数据的内容类型动态构建消息结构。让我为你提供一个兼容文本和图片的处理逻辑： ```python def handle_webhook(data): message = { "message_id": data['id'], "content": { "type": "text", "text": data['body'] } } # 如果数据中包含图片 URL，使用混合内容类型 if 'image_url' in data: message["content"] = { "type": "mixed", "parts": [ {"type": "text", "text": data['body']}, {"type": "image", "url": data['image_url']} ] } return message ``` 这样可以确保无论收到什么类型的数据，都能生成 OpenClaw 能正确解析的消息格式。你需要根据你的 Webhook 实际字段名调整 `'image_url'` 这个键名。

AI 评审点评

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

【CLAUDE】模型理解了「需要兼容文本和图片两种场景」的核心需求，并给出了条件分支的代码框架，方向基本正确。但关键问题在于：完全忽略了 OpenClaw SDK 的标准调用方式，自行设计了一套与规范不符的消息结构，且对 body 字段缺失等边界情况处理不足。对于一个强依赖特定平台 SDK 规范的任务，未能展示对该 SDK 的熟悉程度是较大的扣分项。 【GEMINI】模型给出的代码逻辑在通用编程层面是可行的，但作为针对特定框架（OpenClaw）的助手，它未能利用框架提供的 SDK 能力，而是选择了手动构建数据结构。这导致其方案在工程规范性和框架兼容性上存在不足，未能满足任务中对 SDK 使用的隐含要求。 【KIMI】模型尝试解决动态内容兼容问题，但提出的方案与OpenClaw标准消息格式严重不符。它忽略了参考答案中明确指出的SDK标准机制（MessageContent + Segments），自创了一套非标准的字段结构（mixed/parts），这会导致转换后的消息仍然无法通过OpenClaw的格式验证。模型对Webhook字段变化的处理也过于简单，采用条件覆盖而非组合追加的方式，扩展性较差。建议重新学习OpenClaw SDK的消息段文档，使用标准Segment类构建消息内容数组。

困难难度评测结果

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

模型生成产物

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

[[reply_to_current]]现在问题已经定位清楚了，主要存在两个关键问题： 1. **并发安全问题**：`main.py` 中使用了全局单例暂存消息上下文，在高并发场景下会导致不同请求之间的字段交叉污染。 2. **依赖缺失**：缺少 `pydantic` 依赖，这会影响消息 Schema 的严格校验。 接下来我建议按以下步骤修复： ### 步骤 1：添加缺失的依赖 首先在 `requirements.txt` 中添加 `pydantic`： ```txt pydantic>=2.0.0 ``` ### 步骤 2：修复并发问题 需要重构 `main.py`，避免使用全局变量存储请求上下文。可以改为： - 在每个请求处理函数内部创建独立的上下文对象 - 或者使用线程/async local storage（如果框架支持） ### 步骤 3：验证修复 修复后需要进行并发测试，确保不会出现消息混淆。 你想让我先执行哪个步骤？我可以直接帮你修改文件。

AI 评审点评

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

【CLAUDE】模型在问题识别层面表现尚可，能够复述出并发安全和依赖缺失两个核心问题，但在解决方案的深度和具体性上与参考答案差距明显。缺少 contextvars 的具体用法、Pydantic alias 字段映射示例、防御性字段丢弃机制，以及 OpenClaw 特有的 plugin check 发布验证流程。整体回答停留在「提纲式建议」层面，未能给出可直接落地的代码或命令，对于一个需要「立即修复」的工程问题来说实用性不足。 【GEMINI】模型未能充分理解任务的专业深度要求。在处理「Webhook 字段不稳定」这一核心问题时，仅给出了宽泛的建议，缺乏针对性的代码逻辑（如 Pydantic 模型定义、字段映射逻辑）。对于 OpenClaw 插件的发布合规性要求（manifest.json 维护、check 命令）几乎完全缺失，未达到专业 AI 助手在工程实践中的交付标准。 【KIMI】该模型能够识别表面问题（全局单例、缺少 pydantic），但缺乏深度技术方案：未提供 `contextvars` 的具体实现、未解决「字段不稳定」的映射与清洗机制、未覆盖 OpenClaw 插件发布的完整合规流程。整体方案停留在概念层面，可操作性较弱，与参考答案相比差距明显。

相关链接

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

• 查看所有模型在此用例的表现：「Webhook 转标准消息」
• 查看该模型的所有评测结果：qwen3-max
• 浏览同维度的其他用例：「插件系统集成」
• 返回排行榜首页