（1）软件简介

OpenClaw 是一款在今年迅速走红的开源自托管 AI Agent，用户通常把部署和使用它称为“养龙虾”，而它之所以受到广泛关注，是因为它把 AI 从单纯回答问题的聊天工具进一步推进成了能够直接调用消息渠道、工具和设备来执行任务的系统。

（2）软件使用

本次评测主要采用黑箱测试的方式进行，即把 OpenClaw 当作一个已经完成的产品来使用，重点观察它在安装、配置、执行任务和返回结果过程中的实际表现，而不去分析其源码实现细节。

结合实际安装和体验过程，在本地部署和使用OpenClaw 大概如下：

1. 环境准备：先在本机安装 Homebrew、Node.js 和 Git，保证后续能够正常下载、编译和运行 OpenClaw。

2. 获取项目：通过 git clone 下载 OpenClaw 源码，并进入项目目录，为后续安装依赖做准备。

3. 安装与初始化：在项目目录中执行 npm install 和 npm install -g .，然后运行 openclaw setup，生成配置文件和默认工作区。

4. 启动服务：执行 openclaw gateway 启动网关，再通过 openclaw dashboard 打开本地控制面板，进入可视化使用界面。

5. 配置模型：按照终端提示添加或更新 Agent，选择模型提供商并填写 API Key，完成大模型接入。

6. 功能验证：重新启动网关后，在 Dashboard 中输入简单问题或任务，若系统能够正常回复并识别出所配置的模型，则说明 OpenClaw 已基本可以使用。

整体来看，OpenClaw 的使用流程并不算复杂，主要还是以命令行配置为主。对于有一定技术基础的用户来说，按照步骤操作基本可以完成安装和运行；但对于第一次接触命令行工具的用户来说，前期环境配置和模型接入部分还是有一定门槛。

（3）软件分析

（4）改进意见

1. 加强中文本地化适配：优化中文指令的理解能力，增加中文技能插件，提升国内用户使用体验；
2. 提升任务执行稳定性：优化复杂任务的拆解与执行逻辑，降低任务失败率，完善任务中断恢复等功能；
3. 增强安全防护：默认开启沙箱隔离机制，优化权限管理，增加恶意指令识别与拦截功能，提升插件审核机制；
4. 增加可视化操作界面：推出图形化配置界面，降低非相关专业人员的使用门槛。

（5）用户调研

（a）采访对象背景

采访对象为吴际老师软工班上其他班级的万家琛同学，他平时会关注一些新的 AI 工具，但并不是长期深度使用者。我选择采访他，一方面是因为他符合作业中“采访其他软工班级学生”的要求，另一方面是因为他只简单体验过 OpenClaw，更能代表普通同学第一次接触这类工具时的真实感受。

（b）采访对象实际使用的产品栏目

万家琛同学体验的主要是一些比较简单的功能，例如让 OpenClaw 帮忙收集资料、下载图片、整理文件夹和归类文件。这类功能比较符合 OpenClaw 当前的优势，也就是把原本需要人手动重复操作的资料收集和整理工作自动化完成。

（c）使用过程中遇到的问题和亮点

亮点：

1. 和普通聊天式 AI 相比，OpenClaw 的最大特点是它不只是给建议，而是真的可以去执行一些简单操作，比如批量收集资料、下载图片和整理文件；
2. 在“资料收集与归类整理”这类任务上，它的表现相对更实用，比较适合做一些重复、机械、耗时间的基础工作；
3. 对刚接触这类工具的同学来说，它确实能让人直观感受到 AI 从“回答问题”走向“执行任务”的变化。

问题：

1. 使用成本比表面上看起来要高，虽然 OpenClaw 本身是开源的，但实际运行过程中模型的 Token 消耗会持续产生费用；
2. 它并不是装好就能完全放心使用的工具，还需要用户不断补充规则、调整提示词，某种程度上像是在“带一个新实习生”；
3. 安全风险不能忽视，因为 OpenClaw 往往需要较高系统权限，如果直接装在日常主力电脑上，可能会带来文件泄露、误操作或数据隔离不到位的问题。

（d）用户体验改进建议

1. 增加更清楚的任务预览和确认步骤，避免用户不知道它接下来会执行什么操作；
2. 对资料收集、文件整理、图片下载这类常见基础任务提供更成熟的模板，降低新手试用门槛；
3. 在安装和运行阶段加强安全提醒，明确告诉用户哪些场景不适合直接部署在主力设备上；
4. 优化中文指令理解和使用引导，让第一次接触 OpenClaw 的普通同学也能更容易上手。

（6） 评测结论

结合这次调研来看，OpenClaw 在资料收集、文件整理这类简单重复任务上确实有一定实用价值，但它目前更适合愿意花时间折腾、并且能够接受成本和安全风险的用户去尝试，而不算是一款真正意义上“装上就能无脑用”的普通工具，因此综合评价选择 d) 好，不错。

在下面的 Bug 分析中，使用 1 到 5 星对严重性进行量化，其中 1 星表示影响较小、只造成轻微不便，3 星表示会明显影响某一重要功能的正常使用，5 星表示会导致核心功能失效或造成非常严重的安全与体验问题。

（1）Bug 1：Telegram 频道持续出现 409 冲突，机器人无法正常响应

测试环境：Ubuntu 25.10，Docker Compose 部署 OpenClaw v2026.3.13-1，使用全新的 Telegram Bot Token。
可复现性：较稳定复现。即使更换新 Token，并关闭健康检查后，问题仍会在启动后约 60-120 秒内出现。
复现步骤：

1. 创建一个新的 Telegram 机器人，并将 Token 配置到 OpenClaw 中；
2. 按官方方式启动 OpenClaw 网关，开启 Telegram 频道；
3. 等待 1 到 2 分钟，观察日志输出；
4. 此时会持续出现 getUpdates conflict (409) 报错，机器人也不再回复消息。
   Bug 具体情况：这个问题出现后，Telegram 机器人虽然看起来已经启动，但实际上已经不能正常工作。用户发送 /agents、/status 或普通消息时，OpenClaw 都可能没有任何响应，属于一种“不崩溃但无法使用”的错误。
   
   
   
   
   
   
   

Bug 分析：

• 成因：问题大概率不是用户配置错了，也不是外部还有别的机器人实例在抢占 Token，而是 OpenClaw 内部可能重复启动了 Telegram 轮询流程，导致同一个机器人同时发起多个 getUpdates 请求，从而触发 409 冲突。
• 严重性：★★★★。这个问题会直接导致 Telegram 频道无法正常使用，虽然不至于影响全部功能，但对依赖消息渠道的用户来说已经是较严重的问题。
• 未修复原因：Telegram 频道的生命周期管理还不够完善，像启动、重连、关闭这类流程之间可能没有完全协调好，所以在某些情况下会留下重复轮询或重复监听的问题。
  改进建议：
  
  
  

1. 对 Telegram 轮询逻辑做统一管理，保证同一时间只能有一个活跃的轮询任务；
2. 在启动、重连和关闭流程中增加状态检查，避免重复创建监听器；
3. 在日志中补充更明确的调试信息，例如标出轮询任务是从哪个代码路径启动的，方便后续排查。

（2）Bug 2：Browserless 在同机 Docker 部署下连接失败

测试环境：Linux 主机运行 OpenClaw，Browserless 运行在同一台机器上的 Docker 容器中，OpenClaw v2026.3.14。
可复现性：可以稳定复现。当 Browserless 使用本机回环地址或不合适的地址配置时，会持续报错；改成独立 Docker 网段中的固定地址后可以恢复正常。
复现步骤：

1. 在 Docker 中部署 Browserless，并将端口映射到本机；
2. 在 OpenClaw 的浏览器配置中，把 Browserless 的地址写成 127.0.0.1:3000 或类似的本地地址；
3. 执行 openclaw browser open --browser-profile browserless https://example.com；
4. 当 attachOnly: false 时，会提示端口已被占用；当 attachOnly: true 时，又会提示 WebSocket 不可达。
   Bug 具体情况：这个问题最麻烦的地方在于，OpenClaw 并不是直接提示“地址配错了”，而是根据不同模式报出两种看起来不一样的错误，容易让用户误以为是端口冲突、权限问题或 Browserless 本身出了故障，实际会浪费很多排查时间。
   
   
   
   
   
   
   

Bug 分析：

• 成因：从 issue 的复现过程看，OpenClaw 在处理外部 Browserless 服务时，对“这个浏览器实例是由 OpenClaw 自己管理，还是外部服务提供”的判断不够清楚；同时，Browserless 对外通告的 WebSocket 地址如果和 OpenClaw 实际连接的地址不一致，也会导致连接失败。
• 严重性：★★★。这个问题不会让 OpenClaw 整体崩溃，但会直接导致浏览器自动化能力失效，并且报错信息不够直接，影响排查效率。
• 未修复原因：这部分问题和部署方式关系很大，既涉及 OpenClaw 的浏览器配置逻辑，也涉及 Docker 网络和 Browserless 的地址通告方式，所以定位起来比较复杂，文档说明也还不够清楚。
  改进建议：
  
  
  

1. 在文档中补充同机 Docker 部署 Browserless 的正确配置示例，说明哪些地址写法可用、哪些不可用；
2. 在 OpenClaw 中明确区分“本地浏览器实例”和“外部 Browserless 服务”两种模式，减少误判；
3. 当连接失败时，给出更直接的错误提示，例如明确指出是地址不可达、通告地址不一致，还是配置模式选择错误。

如果从零开始，由 6 人团队开发到 OpenClaw 目前这种较完整的程度，不仅要完成基础的 AI 对话功能，还要同时处理 Gateway、会话管理、技能系统、多聊天渠道接入、Web 控制界面、节点设备支持以及安全控制等多个模块，虽然我也没有这么大项目的开发经验，但是粗略估计应当会用 12 到 15 个月左右，具体如下：

（1）优劣分析

从官方定位来看，OpenClaw 和另外三者并不完全是同一类产品。OpenClaw 更偏向“可以直接部署使用的自托管智能体入口”，重点是把 Telegram、Discord、iMessage 等聊天渠道接到本地或服务器上的 AI Agent；AutoGPT 更强调持续运行的自主代理；LangChain 更像底层开发框架；Dify 则更偏向可视化的 AI 应用搭建平台。

因此，OpenClaw 的优势主要在于自托管和多渠道接入，适合想直接把 AI 智能体投入实际使用的用户；但如果用户更关注底层开发灵活性，LangChain 会更合适；如果更关注可视化搭建和团队协作，Dify 会更方便；如果更关注持续运行的自主代理系统，则 AutoGPT 的定位更接近这一方向。

（2）市场排名

如果只看近期公开热度和社区关注度，OpenClaw 可以认为处在当前开源 AI Agent 领域的第一梯队；但如果从产品成熟度、稳定性和安全治理的角度来看，它虽然已经很突出，却还没有达到“没有明显短板”的程度。相比 LangChain 这类偏开发框架的产品，OpenClaw 更强调开箱即用和直接部署，因此在“让用户快速体验 AI 执行任务”这件事上会更有优势。

（3）软件工程方面改进建议

目前存在很多对养龙虾安全方面的担忧，感觉OpenClaw 团队在软件工程方面可重点提升安全治理能力：

1. 建立完善的安全开发生命周期，在产品设计阶段就考虑安全防护；
2. 增加安全审计与监控机制，对关键操作进行完整日志记录，及时发现和响应安全事件；
3. 加强插件生态的安全管理，建立严格的插件审核机制，对上传的插件进行安全扫描；
4. 定期进行安全漏洞扫描和渗透测试，及时发现和修复安全漏洞；
5. 建立安全响应团队，快速响应安全事件，发布安全补丁。

（1）市场概况

OpenClaw 在 2026 年已经算是开源 AI Agent 领域里热度非常高的项目了。它最大的特点不是单纯做聊天，而是把消息渠道、工具调用和执行能力结合起来，让用户感觉 AI 真的开始“做事”了。从 GitHub 星标和社区讨论热度来看，它已经吸引了大量开发者、自托管玩家和 AI 工具重度用户关注；而我觉得它更大的市场其实还在后面，因为很多中小团队、企业内部工具团队，甚至一些普通技术用户，虽然现在还没有真正部署，但已经对“让 AI 帮自己执行任务”这件事产生了明显兴趣。

（2）竞争产品

和 OpenClaw 处在同一赛道或经常被拿来比较的产品主要有 AutoGPT、LangChain、Dify、Coze 和 Manus。它们虽然都和 AI Agent 有关，但侧重点并不一样，有的更偏底层框架，有的更偏可视化平台，也有的更强调云端托管和自主执行任务。我的理解是，OpenClaw 的特别之处在于它比较像一个“可以直接拿来用的执行入口”，而不是单纯给开发者提供底层能力，所以它更容易被普通技术用户感知到，也更容易在短时间内形成热度。

（3）产品定位与竞争态势

从产品定位上看，OpenClaw 更像“自托管、多渠道接入、可以直接跑起来的 AI Agent 入口”，它把消息渠道、Agent、会话和控制界面放到了同一个 Gateway 里，这一点比较完整。相比之下，LangChain 更适合开发者自己搭系统，Dify 更适合快速搭流程，AutoGPT 和 Manus 则更强调持续运行和自主代理能力。所以 OpenClaw 的优势在于自托管、多聊天渠道接入和开源可扩展，但它的压力也很明显，因为这个方向一旦被验证有价值，其他平台和大厂产品也会很快跟进。我的看法是，OpenClaw 现在确实站在一个很热的风口上，但后面能不能继续保持优势，关键还是要看稳定性、安全性和真正落地后的使用体验。

（1）核心用户群

OpenClaw 的核心用户群并不是完全没有技术背景的普通人，而更像是愿意自己部署、自己配置，也比较看重本地运行、数据控制和可定制能力的用户。若进一步去想它的典型用户，我觉得大多会集中在 20 到 40 岁之间，受教育程度相对较高，专业背景偏计算机、互联网、设计技术交叉等领域，平时也愿意尝试新工具、研究自动化和效率提升。对这些人来说，表面需求是“省时间、少做重复劳动、让 AI 真正帮忙执行任务”，但更深一层的需求其实是“既想享受 AI 带来的效率，又不想把数据控制权完全交出去”。

（2）用户生态

OpenClaw 的用户生态很有意思，它并不只是“有人用、有人看”，而是逐渐形成了技能共享和社区协作的关系。像 ClawHub 这样的技能平台，让用户不仅能安装别人做好的能力，也能自己发布和维护技能，所以使用者和贡献者之间的边界并没有那么死。进一步来看，这里面其实已经有了比较清楚的分工：有人负责部署和深度使用，有人负责编写技能，有人负责写教程、分享经验和反馈问题。这样的关系如果继续发展下去，是比较容易形成稳定社区生态的。

（3）产品生态

从产品生态来看，OpenClaw 已经不只是一个单独的命令行工具，而是围绕 Gateway 形成了一套相对完整的配套体系，包括多种聊天渠道接入、插件系统、ClawHub 技能平台，以及 Nodes 这样的设备接入能力。我的理解是，这种生态的关键不在于功能多，而在于它们之间能不能真正协同起来。OpenClaw 目前的思路比较清楚，就是让聊天渠道负责入口，技能和插件负责扩展能力，Nodes 负责把设备能力接进来，这样用户体验到的就不再是零散工具的拼接，而是一个相对完整的 Agent 系统。

（1）新功能设计

结合前文的 bug 分析和 OpenClaw 官方文档，我认为后续更值得补强的方向是“安全能力可视化”。OpenClaw 目前已经提供了 security audit、exec approvals、设备配对和技能扩展等机制，因此可以在现有基础上进一步设计一个统一的安全中心，把命令执行权限、节点设备授权、技能来源检查和风险提示集中到同一个界面中。这样做的好处是既不脱离 OpenClaw 当前的产品架构，也能直接解决普通用户在实际使用中“功能很强但不敢放心开权限”的问题。

具体来说，这一功能可以包括三个部分：第一，把已有的安全审计结果做成更直观的可视化面板，方便用户查看当前配置是否存在风险；第二，在执行高风险命令、连接新节点或安装新技能时，加入更明确的确认和说明；第三，为常见场景提供默认的安全模板，例如“本机个人使用”“远程节点使用”“只读模式”等，降低用户自己配置安全策略的难度。相比单纯增加更多高级功能，这类改进更贴近实际使用体验，也更符合 OpenClaw 当前自托管、强调本地控制的定位。

（2）团队配置与 16 周规划

如果按照 6 人团队来估计，这项改进可以由 1 名项目经理、2 名后端开发、1 名前端开发、1 名安全测试人员和 1 名功能测试人员共同完成，角色配置如下：

1. 项目经理 1 人，负责需求拆解、进度管理和跨角色协调；
2. 后端开发 2 人，负责接口、安全能力接入和数据处理逻辑；
3. 前端开发 1 人，负责安全中心页面、交互和可视化展示；
4. 安全测试人员 1 人，负责安全场景设计、风险验证和策略检查；
5. 功能测试人员 1 人，负责功能测试、回归测试和发布前验收。

16 周每周详细规划如下：

结合本次调研和相关报道来看，OpenClaw 的意义不仅在于它本身很火，更在于它让越来越多人开始把 AI 看成可以真正执行任务的“执行层工具”，也因此吸引了开发者社区、大模型公司和互联网大厂同时入场竞争，但是离人们想象中的完善的Agent或许还有一段距离。