QwenPaw调研分析

一、QwenPaw 是什么？一句话定位

QwenPaw（原名 CoPaw）是阿里 AgentScope 团队开源的"个人 AI 智能体工作台"，定位介于轻量级聊天机器人和重型企业 Agent 平台之间。它是一个你可以部署在自己机器上、接入多种聊天工具、通过 Skill 无限扩展能力的"AI 助手操作系统内核"。

它不是一个简单的 ChatBot，也不是一个纯粹的编码 Agent。它是一个具备记忆、定时任务、多智能体协作、MCP 协议集成的完整 Agent 运行时。2026年4月从 CoPaw 正式更名为 QwenPaw（Qwen Personal Agent Workstation），标志着全面融入通义千问生态。

基本数据

维度	详情
GitHub Stars	15.5k+
Forks / Contributors	2.1k / 136
提交数	878+
技术栈	Python 75.6% + TypeScript 18.7%（后端 FastAPI，前端 Vue+Vite）
许可证	Apache 2.0
部署方式	Docker 一键 / 本地 conda-pack / 魔搭社区云端
支持渠道	钉钉、飞书、Discord、Telegram、QQ、微信、iMessage
本地模型	Ollama、llama.cpp、LM Studio

---

二、架构解析：不是"又一个聊天框架"

2.1 核心设计哲学------"微型公司"类比

理解 QwenPaw 的关键在于：它的设计哲学更接近于一个"操作系统内核"，提供基础运行时和核心 API，真正的功能通过"插件"和"技能"来扩展。用一家微型公司来类比：

核心引擎（Engine）= CEO + 行政部 → 调度资源、管理生命周期、提供基础服务
插件系统（Plugin）= 职能部门       → 网络访问、数据库连接等重型能力
技能系统（Skill）= 员工的具体技能   → 发邮件、写代码、搜索新闻等具体任务
记忆系统（Memory）= 共享云盘       → 持久化对话历史、用户偏好、执行上下文
定时任务（Cron）= 自动打卡机       → 按配置自动运行任务

每个智能体拥有独立的 Runner、ChannelManager、MemoryManager、MCP 客户端和定时任务管理器------这是多智能体 Workspace 隔离设计的基础。

2.2 三层能力模型------Skill 是灵魂

这是理解 QwenPaw 的关键。很多人把它和普通 ChatBot 混淆，根本差异在于它的三层能力模型（由 Anthropic 首创、现已成为行业通用标准）：

层级	角色	说明
第一层	基础模型 + Prompt	纯对话能力，回答问题
第二层	Agent = 模型 + Tools	具备执行能力：读文件、调API、跑代码
第三层	Skill = 指导 Agent 的标准化流程	定义"先做什么、后做什么、调什么工具"的完整工作流

Skill 本质上是一个目录：

my-skill/
├── SKILL.md          # 必须：指令 + 元数据（Skill 的"灵魂"）
├── scripts/          # 可选：可执行代码
├── references/       # 可选：参考文档
└── assets/           # 可选：模板、资源

我的理解：Skill 是 QwenPaw 最有价值的设计。它把"如何完成一个任务"从模型能力中解耦出来，变成了可复用、可分享、可版本控制的标准化资产。这比单纯依赖 Prompt Engineering 高效得多------你不需要每次都写一长串提示词，而是把最佳实践沉淀到 Skill 里。而且由于 Skill 遵循行业通用标准，一个为 OpenClaw 编写的 Skill 也可以在 QwenPaw 中使用，反之亦然。

2.3 源码结构

src/qwenpaw/
├── agents/                # 智能体核心模块
│   ├── react_agent.py     # QwenPawAgent 主类（ReAct 循环）
│   ├── model_factory.py   # 模型工厂（支持多模型切换）
│   ├── command_handler.py # 命令处理器
│   ├── acp/               # 多智能体通信协议（Agent Communication Protocol）
│   ├── context/           # 上下文管理
│   ├── memory/            # 记忆系统（基于 ReMe）
│   ├── mission/           # 任务系统
│   ├── skills/            # 技能扩展
│   └── hooks/             # 生命周期钩子
├── app/
│   ├── console/           # 前端控制台（Vue+Vite）
│   ├── mcp/               # MCP 协议客户端
│   └── server.py          # FastAPI 服务端
├── config/                # 配置管理
└── utils/                 # 工具函数

2.4 记忆系统------ReMe 机制

QwenPaw 的记忆不是简单地把聊天记录存下来，而是基于 ReMe（Retrieval-augmented Memory） 机制。与竞品对比：

维度	QwenPaw	OpenClaw	Hermes Agent
核心存储	本地文件 + SQLite (AgentScope Runtime)	SQLite + Markdown	SQLite WAL + FTS5 + MEMORY.md
长期记忆	每个 Agent 独立的 memory 目录	MEMORY.md（工作区根目录）	MEMORY.md (2200字符) + USER.md (1375字符)
向量化检索	支持（通过 AgentScope Runtime）	可选扩展（LanceDB）	不用向量库（FTS5 + LLM 摘要）
对话压缩	自动压缩，重要信息持久保存	每日日志 + 定期摘要	Agent 自动策展 + KEPA 反向传播
隔离性	每 Agent 完全隔离	单工作区共享	分层但非严格隔离

Hermes Agent 的记忆最"智能"------它会通过 KEPA 反向传播机制自动从交互反馈中学习优化。QwenPaw 的记忆最"实用"------每个 Agent 独立隔离，适合多角色场景。OpenClaw 的记忆最"灵活"------支持多种存储后端。

2.5 技术栈选型评价

QwenPaw 选 Python 做后端是一个深思熟虑的决策：

优势：

• AI/ML 生态天然亲和，各种模型库直接调用
• 内存占用远低于 Node.js 全家桶（~100MB vs OpenClaw 的 ~500MB）
• 冷启动快，部署简单
• 对中国开发者更友好（Python 在国内 AI 领域普及度极高）

代价：

• 异步并发不如 Node.js 原生（虽然 FastAPI 通过 asyncio 弥补了一部分）
• 前端工程化不如全 TypeScript 栈统一
• 包管理和依赖冲突是老大难问题（Docker 部署一定程度上规避了这个问题）

---

三、重点一：与 HiClaw 的多 Agent 协作

3.1 HiClaw 是什么？

HiClaw 是阿里云 Higress 团队于2026年3月开源的"Team 版 OpenClaw"------一个多智能体协作操作系统。 它自己不实现 Agent 逻辑，而是编排和管理多个 Agent 容器。

核心架构：Manager-Worker 模式

┌───────────────────────────────────────────────────────┐
│                    用户（Human）                        │
│            通过 Element Web / Matrix 客户端交互           │
└────────────────────────┬──────────────────────────────┘
                         │
┌────────────────────────▼──────────────────────────────┐
│                  Manager 容器                          │
│  ┌──────────────┐  ┌──────────────────┐               │
│  │ Higress AI   │  │ Tuwunel Matrix   │               │
│  │ 网关         │  │ 服务器            │               │
│  │ (密钥保管+   │  │ (自建IM,         │               │
│  │  流量入口)    │  │  透明可审计)      │               │
│  └──────────────┘  └──────────────────┘               │
│  ┌──────────────┐  ┌──────────────────┐               │
│  │ MinIO        │  │ Element Web      │               │
│  │ (文件共享)    │  │ (聊天客户端)      │               │
│  └──────────────┘  └──────────────────┘               │
│  ┌─────────────────────────────────────┐              │
│  │   Manager Agent（只管理不执行）        │              │
│  │   任务接收 → 拆解 → 分配 → 监控 → 整合  │              │
│  └─────────────────────────────────────┘              │
└────────────────────────┬──────────────────────────────┘
            ┌────────────┼────────────┐
            ▼            ▼            ▼
     ┌──────────┐ ┌──────────┐ ┌──────────┐
     │ Worker A │ │ Worker B │ │ Worker C │
     │ (QwenPaw │ │ (OpenClaw│ │ (Hermes  │
     │  ~100MB) │ │  ~500MB) │ │  ~200MB) │
     │ 临时JWT  │ │ 临时JWT  │ │ 临时JWT  │
     │ 技能隔离  │ │ 技能隔离 │ │ 技能隔离  │
     └──────────┘ └──────────┘ └──────────┘

关键设计亮点：

1. 零信任安全：Worker 永远不接触真实 API Key。所有凭证（API Key、GitHub PAT 等）集中存储在 Higress AI 网关（AES-256 加密），Worker 只持有 15 分钟有效的 JWT 令牌（"工牌"）。即使 Worker 被攻击，攻击者也拿不到任何有效凭证。

2. Matrix 协议通信：所有 Agent 对话发生在 Matrix 群聊房间中，人类可以随时进入观察、用 @ 指令任何 Worker 修正偏差。这种"聊着天把团队管了"的体验非常直觉。

3. 异构 Agent 混编：同一个 Team 可以混合 OpenClaw、QwenPaw、Hermes Agent 甚至 Claude Code。HiClaw 官方建议"用确定性 Agent（OpenClaw/QwenPaw）做 Leader，用 Hermes 做自主编码执行"。

4. 一键部署 ：bash <(curl -sSL https://higress.ai/hiclaw/install.sh) 一条命令搞定全部组件。

5. 文件共享中枢：大量中间产物（代码、文档、日志）走 MinIO 共享存储而非群聊，避免对话上下文被大文件撑爆。

6. 防惊群机制：内置消息分发管理，减少无效消息干扰，确保 Worker 只接收与自己相关的任务。

3.2 QwenPaw + HiClaw 实战：怎么配合？

HiClaw 1.0.4 版本正式支持 QwenPaw（当时还叫 CoPaw）作为 Worker。集成通过 Matrix Channel 和配置桥接层实现。

为什么 QwenPaw Worker 是 HiClaw 的理想搭配？

对比维度	QwenPaw Worker	OpenClaw Worker
内存占用	~100MB（Python 轻量）	~500MB（Node.js 全家桶）
冷启动时间	快（Python 原生）	较慢
本地环境访问	支持（浏览器、文件系统、桌面应用）	容器隔离，无法访问
适合场景	产品分析、文档处理、桌面自动化、轻量编码	代码编写、复杂工程任务
记忆管理	ReMe（对话压缩+持久化，每Agent隔离）	SQLite + Markdown
Web 控制台	有（管理频道/技能/定时任务/环境变量）	无独立控制台

HiClaw 解决了 QwenPaw 的一大痛点：传统方式下，如果要让一个新 Agent 运行时触达用户，需要逐个适配钉钉、飞书、Discord 等十几种渠道，工程量巨大。而接入 HiClaw 后，只需实现一个 Matrix Channel 适配器，就可以通过 Element Web 或任何 Matrix 客户端交互------这就是"Matrix 作为统一通信层"的价值。

实战 Demo：搭建一个"产品-研发-测试"协作团队

第一步：部署 HiClaw

# Linux/macOS 一键安装
bash <(curl -sSL https://higress.ai/hiclaw/install.sh)
# 选择语言"中文" → 安装模式"快速开始" → LLM平台"阿里云百炼" → 输入 API Key

安装完成后验证：

docker ps | grep hiclaw-manager  # 确认 Manager 容器运行
# Element Web:   http://127.0.0.1:18088
# Higress 控制台: http://localhost:18001
# MinIO 控制台:  http://localhost:18080

第二步：在 Element Web 中向 Manager 下达指令

帮我创建三个Worker：
- 产品经理Alice（使用 CoPaw 内核，负责需求分析和产品设计）
- 研发工程师Bob（使用 OpenClaw 内核，负责代码编写）
- 测试工程师Carol（使用 CoPaw 内核，负责测试用例和验证）

把他们拉到同一个项目房间"计算器项目"中。

任务：设计并实现一个Web版科学计算器。
让Alice先出产品方案，然后安排Bob编码，最后让Carol测试。

第三步：Manager 自动执行

Manager 会：

1. 创建 3 个 Worker 容器（Alice 和 Carol 用 CoPaw 内核，仅 ~100MB；Bob 用 OpenClaw 内核，~500MB）
2. 创建项目 Matrix 房间
3. 将所有 Worker 拉入房间
4. 向 Alice 分配需求分析任务
5. Alice 完成后，自动分配给 Bob 编码
6. Bob 完成后，自动分配给 Carol 测试
7. 你全程在 Matrix 房间中可以看到所有对话，随时 @任何 Worker 修正方向

实际效果（基于社区反馈）：Manager 创建 Worker 和项目房间通常很顺利，但有时不会自动把 Worker 拉入房间，需要用户提醒："请把 Worker 都拉到项目房间里"。这说明 HiClaw 目前还在打磨中，但核心架构已经可用。

进阶用例：运维场景（来自阿里云内部"泰山"SRE 系统实践）

这个用例来自阿里云内部实践，非常有参考价值：

任务：在 HiClaw 上为 SRE 团队组建一个协作空间

1. 管理员向 Manager 下达指令：
   - 组建一个SRE团队
   - 创建团队管家 sre-bot（使用 CoPaw 内核）
   - 从 Excel 中读取真人用户列表，批量创建 Matrix 账号
   - sre-bot 负责：任务分解、成员协调、进度同步

2. 工作模式：
   - sre-bot 是唯一对接 Manager 的数字人
   - 多个真人用户通过 Matrix 客户端 @sre-bot 派发任务
   - sre-bot 接收任务后分解，通过 Manager 创建更多 Worker 执行

3. 关键设计：
   - 真人不直接与 Manager 交互（安全隔离）
   - sre-bot 作为"团队管家"角色，而非单纯的执行者
   - 展示了 QwenPaw Worker 可以扮演"管理"角色，而非只做"执行"

这个用例展示了 HiClaw 架构的灵活性------QwenPaw Worker 在这里不是"写代码的工人"，而是"接单分发的管家"，体现了角色设计的多样性。

混编部署建议：用 QwenPaw Worker 做轻量级角色（产品、文档、数据分析、团队管家），用 OpenClaw Worker 做重型编码角色。这样一台 8GB 内存的服务器也能跑 4-5 个 Worker。

3.3 不接入 HiClaw 的多 Agent 协作------可行但有限

QwenPaw 自身支持"在同一实例内运行多个独立智能体工作区"。但根据 GitHub Issue #3224 的深度讨论，当前存在四个显著局限：

局限	说明	实际影响
手动挡组队	需手动创建每个工作区，逐个配置角色和提示词	复杂任务认知负担重，用户必须先想清楚需要什么角色
一次性生命周期	无法以"团队"为单位持久化保存和复用	每次处理新任务都要重建，无法积累"团队经验"
静态角色	角色提示词创建后固定，不会从反馈中自我优化	某个角色发现更好策略也无法自动沉淀
扁平协作	缺少 Leader-Worker 层级架构	无法自动拆解、分配、监控任务，人类变成"人肉路由器"

不用 HiClaw，QwenPaw 单独能做什么多 Agent 协作？

能做的（适合简单场景）：

• 创建 2-3 个独立 Agent 工作区，分别赋予不同角色
• 通过 ACP（Agent Communication Protocol）模块实现 Agent 间异步通信
• 适合"工作与生活身份隔离"或"不同领域的专家分工"

做不到的（需要 HiClaw 的场景）：

• 自动任务拆解和分配（没有 Leader 角色）
• 自动进度监控和结果整合
• 动态组队和团队复用
• 人类全程可见的透明协作流
• 跨 Agent 的上下文共享和记忆协同

Demo：QwenPaw 单实例多 Agent 协作（不依赖 HiClaw）

场景：用"代码编写员"和"代码审查员"协作

步骤：
1. 在 QwenPaw Web 控制台创建"工作区 A"：
   - 角色：资深代码审查员
   - 技能：代码分析、安全扫描
   - 提示词：你是一位严格的代码审查员，关注安全漏洞和性能问题

2. 创建"工作区 B"：
   - 角色：全栈开发工程师
   - 技能：代码生成、测试编写
   - 提示词：你是一位全栈工程师，擅长 Python 和 TypeScript

3. 用户手动协调：
   → 在"工作区 B"：请帮我实现一个用户登录模块
   → 拷贝工作区 B 产出的代码
   → 在"工作区 A"：请审查以下代码 [粘贴代码]
   → 拷贝审查意见回"工作区 B"修改

问题显而易见：人类变成了"人肉路由器"，在两个工作区之间手动搬运信息。这就是为什么 HiClaw 的 Manager 角色如此重要------它把人从"协调者"变成了"决策者"。

Issue #3224 提出的解决方案------Agent Teams

Issue #3224 提出了一个很有野心的特性：自然语言驱动的自进化多智能体协作团队。它参考了三个成熟方案：

参考来源	核心能力	与 QwenPaw 的对齐点
Claude Code Agent Teams	多实例并行，共享任务列表和邮箱系统	领导-成员层级架构、智能体间直接通信
HKUDS/ClawTeam	Leader Agent 自动组建子 Agent 团队	自然语言自动组队、自组织协作
agent-teams-playbook Skill	216 行提示词实现"说句话就能自动组队"	自然语言触发团队创建

如果这个特性落地，QwenPaw 将可以在不依赖 HiClaw 的情况下实现完整的多 Agent 协作。但目前还在规划阶段（截至2026年5月），短期内仍然推荐 HiClaw 方案。

结论：选择决策树

你需要多 Agent 协作吗？
├── 不需要 → QwenPaw 单 Agent 即可
├── 简单分工（2-3 Agent，手动协调可接受）→ QwenPaw 单实例多工作区
├── 复杂协作（4+ Agent，需要自动调度）→ QwenPaw + HiClaw
└── 企业级多角色协同 → HiClaw + 混编 Worker（QwenPaw + OpenClaw）

---

四、重点二：用 QwenPaw 协助编程的最佳实践

4.1 先说结论：QwenPaw 不是最好的编码 Agent，但可以变得很好

QwenPaw 的定位是"个人助理工作台"，不是专门的编码 Agent（那是 Qwen Code / Qoder 的定位）。但通过 Skill 系统 + MCP 集成 + 合适的底层模型，它完全可以成为一个强大的编程助手。

编程能力 = 代码类 Skill + MCP 工具集成 + 合适的底层模型

4.2 最佳实践一：编写自定义 Coding Skill（推荐度最高）

这是最推荐的方式。创建一个专门的编码技能包，将你的编码最佳实践沉淀下来：

# SKILL.md 示例：全栈开发助手

---
name: fullstack-dev
description: 全栈开发助手，支持需求分析、代码生成、测试编写、代码审查
version: 1.0.0
author: your-name
tags: [coding, development, fullstack]
---

## 角色定义
你是一位资深全栈开发工程师，精通 Python、TypeScript、React、FastAPI。

## 工作流程

### 1. 需求分析阶段
- 收到用户需求后，先确认技术栈和约束条件
- 输出简短的技术方案（不超过5条要点）
- 等待用户确认后再动手

### 2. 代码生成阶段
- 使用 `write_file` 工具直接写入文件
- 遵循项目现有的代码风格和目录结构
- 每个文件生成后立即运行 lint 检查

### 3. 测试阶段
- 为每个核心函数编写单元测试
- 使用 `execute_command` 运行测试套件
- 测试不通过时自动修复并重试（最多3次）

### 4. 代码审查阶段
- 检查安全漏洞（SQL注入、XSS、命令注入）
- 检查性能问题（N+1查询、内存泄漏）
- 输出审查报告

## 约束
- 不要过度设计，三行相似代码优于一个过早抽象
- 优先修改现有文件，而非创建新文件
- 除非用户要求，不添加注释

将这个 Skill 放到 QwenPaw 的技能目录下，Agent 就会按照这个标准化流程来执行编码任务。关键价值在于：你不需要每次都写一长串 Prompt，这个 Skill 会持续生效，而且可以随着实践不断优化。

由于 Skill 遵循行业通用标准，你也可以直接从 skills.sh（社区已有 80,000+ 个 Skill）中搜索和安装编码相关的 Skill，比如 react-dev、fastapi-dev、unit-testing 等。

4.3 最佳实践二：通过 MCP 集成开发工具链

QwenPaw 内置 MCP（Model Context Protocol）客户端，可以接入外部工具，让 Agent 真正"动手"操作你的开发环境：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-server-filesystem", "/your/project"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-server-github"],
      "env": { "GITHUB_TOKEN": "your-token" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-server-postgres", "postgresql://..."]
    }
  }
}

通过 MCP，QwenPaw 可以：

• 读写项目文件（不只是生成代码文本，而是直接写入文件系统）
• 操作 Git 仓库（提交、创建分支、发起 PR）
• 查询和修改数据库
• 调用 CI/CD 流水线
• 操作浏览器（配合 Playwright MCP Server）

独特优势：由于 QwenPaw 运行在本地环境（非严格容器隔离），可以直接访问本地文件系统、浏览器、桌面应用。在编码场景下，这意味着它可以直接操作你的 IDE、运行本地测试、查看浏览器效果------这是容器化的 OpenClaw Worker 做不到的。

4.4 最佳实践三：选择合适的底层模型

编程场景下的模型选择建议：

场景	推荐模型	原因
复杂架构设计 / 长时任务	Qwen3.7-Max（API）	推理能力最强，通过35小时连续运行测试验证
日常编码任务	Qwen3-Coder / Qwen-Coder（API）	专为编码优化，代码理解和生成能力最强
代码补全 / 简单修改	CoPaw-Flash（本地）	快速响应，零 API 费用
隐私敏感项目	Ollama + Qwen3 本地模型	数据完全不出本地
需要最强编码能力	Claude Opus 4.7 / Sonnet 4.6（API）	QwenPaw 支持接入非 Qwen 模型

关键提示：QwenPaw 的模型工厂（model_factory.py）支持多模型切换。你完全可以在同一个 QwenPaw 实例内，为不同的 Agent 工作区配置不同的模型------比如"架构师"用 Qwen3.7-Max，"日常助手"用 CoPaw-Flash。

4.5 最佳实践四：HiClaw 多 Agent 编程团队（复杂项目）

对于较大的项目，可以用 HiClaw 搭建一个"AI 开发团队"：

向 HiClaw Manager 下达指令：

创建一个全栈开发团队用于开发"在线文档编辑器"项目：

1. 架构师 Arch（CoPaw Worker）
   - 负责技术选型、架构设计、代码审查
   - 安装技能：architecture-review, tech-selection

2. 前端工程师 Frontend（OpenClaw Worker）
   - 负责 React + TypeScript 前端开发
   - 安装技能：react-dev, unit-testing

3. 后端工程师 Backend（OpenClaw Worker）
   - 负责 Python FastAPI 后端开发
   - 安装技能：fastapi-dev, api-testing

4. 测试工程师 QA（CoPaw Worker）
   - 负责编写测试计划、执行测试、报告bug
   - 安装技能：test-planning, bug-reporting

工作流程：
- Arch 先出架构方案，我确认后分配给 Frontend 和 Backend 并行开发
- Frontend 和 Backend 完成后，QA 进行集成测试
- 发现 bug 后 QA 直接 @对应工程师修复

为什么多 Agent 编码比单 Agent 更好？

维度	单 Agent 编码	多 Agent 编码团队
上下文管理	一个窗口承载所有信息，容易"忘"	每个 Agent 专注自己的领域，上下文更精准
代码一致性	前后端风格不一致	各自遵循领域最佳实践
质量保障	测试经常被跳过	QA 专职测试，不会被遗忘
审查环节	自己写自己查，质量堪忧	架构师独立审查，发现问题
扩展性	任务越复杂，Agent 越容易崩溃	并行处理，线性扩展

4.6 编程场景完整工作流示例

场景：用户想开发一个 Python CLI 工具，用于批量重命名文件

推荐方案：单 Agent + Coding Skill + MCP（不需要 HiClaw）

1. 在 QwenPaw Web 控制台加载 fullstack-dev Skill
2. 配置 MCP 接入本地文件系统
3. 对话：

   用户：帮我写一个 Python CLI 工具，支持正则批量重命名文件，
        要求支持 --dry-run 预览、--recursive 递归、--pattern 正则匹配

4. QwenPaw 按 Skill 定义的流程自动执行：

   ├── [需求分析] 确认技术选型（Click + pathlib + re）
   │   └── 输出5条技术要点，等待用户确认
   │
   ├── [代码生成] 通过 MCP 创建项目目录结构
   │   ├── rename_tool/
   │   │   ├── __init__.py
   │   │   ├── cli.py          # Click CLI 入口
   │   │   ├── renamer.py      # 核心逻辑
   │   │   └── utils.py        # 工具函数
   │   ├── tests/
   │   │   ├── test_renamer.py
   │   │   └── test_cli.py
   │   └── pyproject.toml
   │
   ├── [测试] 运行 pytest，不通过则自动修复（最多重试3次）
   │
   ├── [代码审查] 自检安全漏洞和性能问题
   │
   └── [交付] 输出使用说明和安装方式

5. 后续迭代：用户直接在同一工作区说"加个 --exclude 参数"
   QwenPaw 会记住之前的上下文（ReMe 记忆），直接修改现有代码

4.7 与 Claude Code 编码体验的对比

维度	QwenPaw 编码	Claude Code 编码
编码能力	依赖底层模型 + Skill 补强	原生编码优化，最强
部署方式	本地/云端自部署	商业服务，无需部署
本地模型	原生支持	不支持
渠道集成	钉钉/飞书/QQ/微信	仅终端/IDE/Web
定时任务	支持（Cron 定时检查代码质量）	有限支持
数据隐私	数据不出本地	数据经 Anthropic 服务器
多 Agent	需 HiClaw	Agent Teams 内置
价格	免费（开源）	付费
适合场景	隐私敏感 + 中文生态 + 定制化需求	追求最强编码能力

务实建议：如果你的核心需求是"强大的编码助手"，Claude Code 目前是最强的。但如果你有以下额外需求，QwenPaw 是更好的选择：

• 需要通过钉钉/飞书等与 AI 交互
• 需要本地部署，数据不出本地
• 需要定时任务（比如每天自动运行 lint 检查）
• 需要与 HiClaw 配合搭建编码团队

---

五、竞品对比：QwenPaw 在 Agent 生态中的位置

5.1 四大 Agent 框架横向对比

维度	QwenPaw	OpenClaw	Hermes Agent	Claude Code
定位	个人AI助理工作台	插件化通用Agent	自我进化个人智能体	商业编码Agent
开源	是（Apache 2.0）	是	是	否
语言	Python 为主	Node.js/TypeScript	Python 为主	不公开
内存占用	~100MB	~500MB	~200MB	N/A（商业服务）
GitHub Stars	15.5k	30万+	~25k+	N/A
Skill 生态	成长中	80,000+（skills.sh）	自动生成Skill	内置
多Agent	基础（需HiClaw增强）	支持（可做HiClaw Worker）	单Agent为主	Agent Teams
编码能力	通过Skill扩展	强（原生工具）	中	最强
本地模型	原生一等支持	需配置	支持	不支持
中文生态	最好（钉钉/飞书/QQ/微信）	弱	弱	弱
部署门槛	最低（Docker一键）	中	中	无需部署
记忆系统	ReMe（每Agent隔离）	SQLite+Markdown+LanceDB	4层记忆+KEPA	文件+会话
自我进化	不支持	不支持	最强（KEPA）	不支持

5.2 与字节 DeerFlow 的差异

维度	QwenPaw	DeerFlow
核心定位	多Agent协作 + 个人助手	单Agent深度任务
擅长场景	工程型任务（多角色协作）	研究型任务（深度调研、长文分析）
多Agent	支持（+HiClaw）	不支持
渠道接入	多渠道（钉钉/飞书/QQ等）	主要是CLI和Web

5.3 我的综合判断

• 纯编码场景：Claude Code > Qwen Code > OpenClaw > QwenPaw。QwenPaw 编码不是原生强项，但可通过 Skill 和 MCP 大幅补强。
• 个人助理 / 中文生态 ：QwenPaw > 所有竞品。钉钉飞书微信 QQ 全覆盖是碾压级优势。
• 多 Agent 协作：HiClaw（+QwenPaw/OpenClaw混编）> Claude Code Agent Teams > 其他。HiClaw 的 Matrix 透明协作 + 零信任安全是目前最成熟的方案。
• 自我进化 / 长期陪伴：Hermes > QwenPaw > OpenClaw。Hermes 的 KEPA 反向传播记忆独一无二。
• 隐私敏感场景 ：QwenPaw > 所有竞品。本地模型支持最原生、最简单、最自然。
• 部署门槛 ：QwenPaw（Docker一键）≈ Claude Code（免部署）> 其他。

---

六、优缺点总结

优势

1. 部署门槛极低：Docker 一键启动，号称业界最低门槛，名副其实
2. 中文生态无敌：钉钉、飞书、微信、QQ 全覆盖，国内用户开箱即用
3. 本地模型原生支持：Ollama/llama.cpp/LM Studio 一等公民集成，数据不出本地
4. Skill 架构优雅：三层解耦设计清晰，遵循行业标准，跨平台可复用
5. 与 HiClaw 深度互补：轻量 Worker（1/5 内存），可访问本地环境
6. ReMe 记忆系统：对话自动压缩 + 重要信息持久化 + 每Agent隔离
7. 完全开源可控：Apache 2.0，数据主权归用户
8. Web 控制台友好：图形化管理频道、技能、定时任务、工作区文件、环境变量

劣势

1. 编码能力非原生强项：不像 Claude Code / Qwen Code 那样专为编码优化，需要通过 Skill 和 MCP 补强
2. 多 Agent 协作依赖 HiClaw：单实例多工作区功能较基础，复杂协作必须引入 HiClaw
3. Skill 生态尚在成长期：相比 OpenClaw 的 80,000+ 社区 Skill，差距明显
4. 社区规模差距：15.5k Stars vs OpenClaw 30万+ Stars，第三方资源和教程少
5. 正在经历架构迁移：Issue #4727 显示正在从 AgentScope 1.x 迁移到新版本，存在短期不稳定风险
6. Python 环境依赖：虽然 Docker 缓解了问题，但原生部署仍可能遇到包管理冲突
7. Agent Teams 特性尚未落地：Issue #3224 提出的"自然语言驱动多智能体团队"还在规划阶段

---

七、总结与建议

适合你用 QwenPaw 的场景

• 你需要一个部署在自己机器上的 AI 助手，数据不出本地
• 你需要通过钉钉/飞书/微信与 AI 交互，而不只是在终端里
• 你需要定时执行任务（每天汇总新闻、定期检查服务状态、自动运行 lint）
• 你需要用本地模型，不想付 API 费用或有隐私顾虑
• 你需要与 HiClaw 配合搭建多 Agent 协作团队
• 你的团队在国内，需要深度融入阿里云/通义千问生态

不太适合的场景

• 纯粹追求最强编码 Agent → 用 Claude Code 或 Qwen Code
• 需要开箱即用的丰富 Skill 生态 → 用 OpenClaw
• 需要 Agent 自我进化和深度个性化 → 用 Hermes Agent

我的整体评价

QwenPaw 的核心价值不在于"它能做什么别人做不了的事"，而在于它让"拥有一个AI助手"这件事变得足够简单和可控。对于国内开发者和团队来说，它可能是目前综合体验最好的开源 AI Agent 框架------不是最强的，但是最趁手的。

结合 HiClaw 之后，它从"个人助手"升级为"团队协作平台"，这种"轻量 Worker + 强力 Manager"的组合是一条值得关注的路径。特别是当 Issue #3224 的 Agent Teams 特性落地之后，QwenPaw 有可能在不依赖 HiClaw 的情况下也具备完整的多 Agent 协作能力------届时它的竞争力会再上一个台阶。

一句话总结：QwenPaw 是目前国内开发者搭建个人 AI 助手的最佳起点，HiClaw 是将其升级为团队协作平台的最佳路径。编码场景下，Skill + MCP + 合适模型的组合可以让它成为一个够用的编程助手，但如果你对编码能力有极致追求，建议与专业编码 Agent（如 Claude Code 或 Qwen Code）配合使用。