Qclaw AI 智能体深度测评：本地执行与跨端能力实战

[图片]

4. 优缺点评价

优点在于整理速度快，并且有回滚机制，如果执行错误还可以一键撤回，不用担心整理错了找不到文件。缺点就是整理结果往往和自己的理想结果存在差异，要想获得好的效果，必须要有详细的提示词，但是这样似乎不如自己手动整理快，并且有一些文件会放到你想不到的文件夹中，不方便后期的查找。

三、测试场景二：带有前置推理的复杂学术检索

1. 场景背景

测试输入：搜索近三年关于路径规划或者扩散模型的计算机 trans 类顶刊上的论文，要结构完整，适合初学者模仿的，整理成一个表格，里面要有论文的阅读链接。

2. 任务拆解与 CoT（思维链）分析

普通的大模型在处理此类指令时，往往会产生幻觉或直接输出模糊结果。而 Qclaw 展现了典型的 Agent 任务分解（Task Decomposition）能力：

它主动识别出指令中的模糊依赖项——'哪些期刊属于 Trans 类？'。系统首先执行了一次内部检索，明确了 T-RO, T-ITS, T-PAMI 等 7 个目标期刊的缩写与全称。随后，它将这些具体期刊名作为限制参数，跨 arXiv 和 Google Scholar API 进行二次定向检索，最终成功渲染出包含 10 篇高匹配度论文的 Markdown 表格。

这种'先解决前置依赖，再执行主任务'的逻辑，大幅降低了科研检索的无效时间。

[图片]

3. 优缺点分析

搜索调研是 agent 的强项，可以返回比较好的结果，并且会把论文链接也一起整理好发给你。比起 GPT 和 Gemini 的 DeepSearch 功能的话，这个返回的结果更加工整，并且可以去搜索一些指定的 skill，从而访问特定的论文网站，灵活性也比较高。GPT 最近也可以正针对网址进行深度调研了，但是使用体感并不好。

四、测试场景三：生态扩展与自主安全排雷

这是本次评测中最具技术价值的环节。测试指令：感觉这篇文章写的不太好，你先去 skillhub 上下载一个写博客的 skill，之后再重新写一个。

1. 动态检索与安全沙箱机制

接收指令后，Qclaw 通过 CLI 后台执行了搜索：

npx clawhub search blog writing 

系统返回了 4 个候选插件。其中评分最高的为 blog-master (2.106)。但 Qclaw 并没有无脑安装最高分版本，而是触发了内部的安全审查机制（集成了 VirusTotal Code Insight）。

系统日志捕获到该插件存在高危模式（包含外部 API 与 eval 风险）：

⚠️ Warning: "blog-master" is flagged as suspicious by VirusTotal Code Insight. This skill may contain risky patterns (crypto keys, external APIs, eval, etc.) 

基于此警告，Qclaw 进一步调用 inspect 命令查看详情，判断该插件主要用于 WordPress 自动化发文，偏离当前需求，进而自主阻断了该安装进程，转向选择安全且对口的 blog-writer-pro。

2. 容错与重试机制

在安装目标插件时，遇到了接口限流问题：

× Rate limit exceeded (retry in 1s, remaining: 0/20, reset in 1s) 

系统自带指数退避（Exponential Backoff）重试逻辑，等待 5 秒后再次发起请求并安装成功，随后自动调用新 Skill 的 rewrite 方法完成了本文初稿的结构重构。

3. 文件发送

在写好文件之后可以指定它存放在桌面或者指定位置，此时在手机上使用 Qclaw 助手，即可让他将你指定的文件发送到手机上。

4. 优缺点分析

这一部分可能是腾讯做的比较好的地方，在安装 skill 时会进行安全审查，避免安装上存在安全漏洞的 skill。Claw 这种自己从 claw 下载 skill 的能力也极大的增强了其能力边界，使得 agent 遇到难以解决的问题也能自己完成从：发现—>搜索—>解决的全流程。并且跨端传输也增强了远程办公的能力。

五、测试场景四：跨应用自动化通信

1. 场景背景

本场景旨在测试 Qclaw 的多模态任务流转能力，即：从公网检索数据 ➡️ 本地处理清洗 ➡️ 通过外部应用（微信）下发通知。 测试指令为：抓取当天 AI 热点资讯，整理成结构化摘要，并通过微信发送给联系人「xxx」。

2. 核心执行逻辑与异常捕获

在执行该长链路任务时，系统展现了优秀的局部容错（Fallback）能力，但在终端通信协议层遇到了阻断。执行流可拆解为两个阶段：

阶段 A：数据检索与容错路由 Agent 首先尝试调用默认的 Web Search 工具，但捕获到了 API 缺失异常：

// 操作 2 — 默认搜索调用失败
web_search(query="AI 人工智能 今日热点 2026 年 3 月 16 日") → Exception: missing_brave_api_key 

在捕获异常后，Agent 触发了自主策略降级，动态切换路由至 Hacker News RSS 源，成功绕过 API 限制并完成了 8 条摘要的结构化整理。

阶段 B：多轮通信尝试（RPC 调度失败） 在消息下发阶段，系统连续遭遇了 4 轮寻址失败。Qclaw 尝试了多种参数重载（Overload）策略：

3. 根因分析（Root Cause Analysis）

经过对底层配置与调用链路的逆向排查，确认此问题并非核心代码 Bug，而是系统环境耦合导致的连接态失效。

虽然系统层面的 openclaw.json 配置显示插件已启用：

"channels":{"wechat-access":{"enabled":true,"token":"****","wsUrl":"wss://mmgrcalltoken.3g.qq.com/agentwss"}}

但 enabled: true 仅代表运行时加载了该模块，不代表全链路连通。wechat-access 的实际底层架构依赖一条极长的代理链路： QClaw Plugin ➡️ WebSocket (腾讯服务器) ➡️ 本地微信 PC 版客户端 ➡️ 联系人内存池 (Map<String, Contact>)。

Unknown target 的真实生成链路如下： 当 message tool 发起 RPC 调用时，网关将请求路由至微信插件。插件在核对本地内存的 Map<String, Contact> 缓存时，发生了 Key Miss（未命中）。 这通常意味着本地微信 PC 端未登录、未授权，或 WebSocket 长连接断开，导致插件根本没有拉取到最新的联系人字典。

此外，针对第 3 轮尝试（使用微信号 xxxxxx 失败），其底层逻辑在于：外部可见的微信号（WeChat ID）与插件内部通信使用的 OpenIM ID 通常存在映射差，无法直接作为 RPC 调用的 Target 参数。

4. 优缺点分析

可能是因为目前微信等社交软件并没有对这些软件开放接口，所以 Qclaw 在与社交软件的交互上还是存在一些问题，不能实现低门槛操作，Qclaw 自己下载了 skill 后也完成不了，可能需要有一定的技术能力才能搞定。

六、评测总结

Qclaw 的出现极大地降低了使用 AI 智能体的操作门槛，Agent 自己能够执行解决问题的闭环的能力也让人眼前一亮。并且 Qclaw 跨端传输的能力也极大地方便了我们远程办公的需求。

但是目前的软件还不是很完善，由于 Qclaw 直接部署在电脑本地，所以经常会执行一些系统级命令与配置，并且是完全不可控的，个人感觉对于不熟悉电脑的小白，经常让 Qclaw 执行这样的系统操作，难免会带来一些问题与损失。并且由于系统的安全设置，Qclaw 的很多操作是受到一定限制的，经常会出现花费了大量 Token，这些 Token 其实是花费在与安全设置斗智斗勇上，并没有解决你的真正问题。Token 的消耗还是较高，希望未来发展的可以少花 Token 多办事。

[图片]