qwen3-8b 在「workspace 依赖误用」的评测结果

基本信息

• 模型名称：qwen3-8b
• 用例名称：workspace 依赖误用
• 测试类型：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 插件时报错了，提示依赖解析失败。我的 package.json 里写的是「"@openclaw/plugin-sdk": "workspace:*"」，请问该怎么改？

任务要求

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

1. 明确指出「workspace:*」仅适用于 Monorepo 内部开发环境
2. 说明发布到 NPM 或生产环境时必须使用具体的版本号或版本范围
3. 给出正确的修改示例，如「^1.0.0」
4. 提到修改后需要重新执行依赖安装以验证兼容性

评测结果

综合得分

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

基础难度评测结果

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

模型生成产物

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

你遇到的依赖解析问题是因为 `workspace:*` 语法仅适用于本地工作区（monorepo）场景，而发布到 npm 时需要明确依赖版本或私有仓库地址。以下是解决方案： --- ### ✅ 正确做法取决于你的实际场景： #### 📦 场景 1：使用公共 npm 包（推荐） 如果你的插件是公开发布的，需将依赖改为具体版本号： ```json "@openclaw/plugin-sdk": "^1.0.0" ``` - 确保已发布过 `@openclaw/plugin-sdk` 到 npm - 运行 `npm install` 后执行 `npm publish` #### 🛡️ 场景 2：使用私有仓库（如 GitHub Packages / Verdaccio） 若依赖是私有包，需配置 npm registry： ```bash npm config set @openclaw:registry https://npm.pkg.github.com npm config set //npm.pkg.github.com/:_authToken YOUR_GITHUB_TOKEN ``` 然后修改 `package.json`： ```json "@openclaw/plugin-sdk": "workspace:*" # 仅在本地开发时使用 ``` 发布时确保已登录： ```bash npm login --registry=https://npm.pkg.github.com ``` #### ⚠️ 场景 3：多包项目（Monorepo） 若使用 Lerna/Yarn Workspaces，需在 `package.json` 中显式声明依赖： ```json "dependencies": { "@openclaw/plugin-sdk": "workspace:*" } ``` 并确保所有包都在同一工作区中。 --- ### 🔍 常见排查步骤： 1. **检查网络**：确保能访问 npm 注册中心 2. **清除缓存**：`npm cache clean --force` 3. **验证 scope**：确认 `@openclaw` 是否为有效 scope（可通过 `npm info @openclaw/plugin-sdk` 查询） 4. **查看完整错误**：提供完整的错误日志（尤其是 `npm ERR!` 部分） --- ### 📝 附加建议： - 如果是内部团队使用，可考虑配置私有 registry - 发布前运行 `npm ls @openclaw/plugin-sdk` 确认依赖解析结果 - 使用 `npm version` 管理语义化版本号 需要我帮你检查具体的错误日志吗？

AI 评审点评

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

【CLAUDE】候选答案抓住了核心问题（workspace:* 不适用于发布场景，应改为具体版本号），基本满足用户需求。但回答结构过于臃肿，引入了多个不必要的场景和步骤，部分内容存在误导（场景2仍保留 workspace:* 写法），且缺少参考答案中提到的 npm pack 验证建议。整体属于「方向正确但不够精准简洁」的回答。 【GEMINI】模型能够识别「workspace:*」在发布时的局限性，并提供了正确的修改方向。但模型在回答中引入了过多的无关场景（如私有仓库配置、Monorepo 内部配置），这不仅没有解决用户关于「插件发布报错」的直接问题，反而可能导致用户混淆。建议在处理此类基础问题时，应优先给出最直接、最标准的解决方案，而非罗列所有可能的配置场景。 【KIMI】候选输出未能准确完成题目要求的核心任务：将「workspace:*」改为可发布结构。虽然识别了问题原因，但提供的多场景方案中包含了错误和矛盾的建议（尤其是场景2），可能导致用户无法正确解决问题。参考答案明确给出了单一正确的修改方案（改为「^1.0.0」并重新安装），而候选输出让用户在多个场景中自行判断，增加了出错风险。建议精简为单一明确方案，删除误导性的场景2和错误的场景3描述。

进阶难度评测结果

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

模型生成产物

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

1. **关于版本改为 `latest`** 不建议直接使用 `latest`。`workspace:*` 是指向当前工作区的依赖，而 `latest` 会强制安装 npm registry 上的最新版本，可能导致版本不一致或兼容性问题。更安全的做法是： - 使用具体版本号（如 `^1.0.0`）或语义化版本范围（如 `>=1.0.0 <2.0.0`）。 - 或保留 `workspace:*`，但需确保所有依赖插件都在同一工作区中。 2. **批量检查其他插件** 可通过以下命令递归扫描所有插件目录并检测 `@openclaw/plugin-sdk` 的依赖项： ```bash find plugins -type d -name 'package.json' | while read pkg; do grep -E '"dependencies"[^}]*"@openclaw/plugin-sdk"[^}]*"workspace:' "$pkg" && echo "⚠️ $pkg 使用了 workspace:*"; done ``` - 若发现类似问题，可手动替换为具体版本号。 - 对于自动化处理，可编写脚本批量替换（需谨慎）。 3. **验证发布脚本** 修改后建议运行以下命令验证： ```bash npm install --workspaces && npm run publish -- --dry-run ``` 检查输出是否报错，确保依赖解析正常。

AI 评审点评

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

【CLAUDE】候选输出整体方向正确，能识别 latest 的风险并推荐 SemVer 范围，也尝试提供批量扫描方案。但存在两个明显不足：一是将「保留 workspace:*」列为可选方案，与发布场景的实际需求相悖；二是完全遗漏了修改依赖后需同步 pnpm-lock.yaml 的说明。批量扫描命令也存在语法错误，工程实用性打折。整体属于及格水平但不够精准。 【GEMINI】候选模型较好地回答了用户关于版本策略和批量检查的问题。建议方案具备可操作性，逻辑清晰。如果能在工程实践环节补充关于 lock 文件同步的说明，以及在风险分析中更强调语义化版本（SemVer）对生产环境稳定性的保障，评价会更高。 【KIMI】候选输出未能准确理解任务核心：将 workspace:* 改为可发布结构。主要问题包括：1）错误地将「保留 workspace:*」作为可行选项；2）批量扫描命令过度复杂且不可靠；3）完全遗漏 pnpm 生态（项目实际使用 pnpm，但候选输出使用 npm 命令）；4）未提及 lockfile 同步。这些缺陷表明候选输出对 monorepo 发布流程的理解不足，工程实践建议与项目上下文脱节。

困难难度评测结果

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

模型生成产物

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

已修复「plugins/auth」插件的依赖问题： 1. 将 `@openclaw/common` 的依赖协议从禁止使用的 `workspace:*` 改为可发布的版本号 `^1.0.0` 2. 确认版本 `1.0.5` 存在且可用 3. 文件写入权限已通过备选方案解决 建议下一步： - 运行 `npm install` 重新安装依赖 - 检查 CI 流水线状态是否已通过 - 验证 `plugins/auth` 是否正常工作

AI 评审点评

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

【CLAUDE】候选输出完成了基本任务（识别并修改了 workspace:* 依赖），但在多个关键细节上存在明显不足：版本号未使用已确认的最新版、权限问题处理不透明、缺乏 peerDependencies 检查、后续验证步骤不够规范且工具选择不当。与参考答案相比，缺少对架构原理的解释和对潜在风险的全面覆盖，整体质量偏低，属于勉强及格或不及格水平。 【GEMINI】候选输出完成了基础的依赖修改任务，但在工程实践的严谨性上有所欠缺。相比参考答案，候选输出未能提供具体的验证指令（如 pnpm filter 构建），也未提醒用户检查 peerDependencies 等关键架构细节。整体表现合格，但缺乏作为专业助手应有的深度建议。 【KIMI】候选输出完成了基础的依赖修改描述，但在关键维度上均有明显缺失：诊断缺乏全局视角，权限恢复过程模糊且工具链建议错误（npm 而非 pnpm），对 OpenClaw 插件发布架构的理解停留在表面，未解释 workspace 转 registry 的本质原因，也未覆盖 peerDependencies 检查和锁定文件更新等必要步骤。整体表现低于及格线。

相关链接

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

• 查看所有模型在此用例的表现：「workspace 依赖误用」
• 查看该模型的所有评测结果：qwen3-8b
• 浏览同维度的其他用例：「插件系统集成」
• 返回排行榜首页