跳到主要内容

OpenClaw 使用记录

· 阅读需 7 分钟
tanzhuo

OpenClaw 是一个 开源的 AI Agent 自动化执行框架。 它的核心目标是让 AI 不仅仅停留在“对话”，而是能够 **自动规划任务、调用工具、执行操作并持续迭代完成复杂目标，**最近使用下来总结了一些内容。

写这篇记录的起因很简单：聊天式的 AI 用久了，会发现它的天花板不在“答得好不好”，而在“答完之后呢”。代码建议给了，命令列出来了，真正去执行、验证、改错的还是人。Agent 框架要解决的就是这最后一公里——把“说”变成“做”。OpenClaw 是我最近实际跑过一段时间的一个，把使用中的观察和问题记下来，方便自己回头看，也给在选型的人一个参考。

简单来说，OpenClaw 可以理解为：

一个可以自动写代码、执行命令、分析项目并持续迭代任务的 AI 工程助手。

与普通的 ChatGPT 或 Claude 不同，OpenClaw 的设计目标是：

  • 让 AI 具备任务执行能力
  • 可以 拆解复杂目标
  • 自动 调用工具和执行命令
  • 持续 迭代直到任务完成

因此，它更像是一个 AI 自动化开发助手（AI Software Engineer）。

OpenClaw — Personal AI Assistant

OpenClaw 的核心能力​

OpenClaw 的能力主要体现在 任务规划 + 自动执行 + 工具调用 三个方面。

这三者其实对应了 Agent 系统的经典循环：模型先根据目标产出计划（规划），再通过工具作用于真实环境（执行），然后把执行结果——命令输出、报错信息、测试结果——重新喂回模型作为观察（反馈），据此修正下一步动作。循环往复，直到模型判断任务完成。理解了这个「规划—执行—观察」的闭环，OpenClaw 的行为就不难预测了。

1) 任务规划（Planning）​

当用户给 OpenClaw 一个目标，例如：

“帮我给这个项目增加一个 Redis 缓存”

OpenClaw 会自动进行任务拆解，例如：

  1. 分析项目结构
  2. 找到数据库访问代码
  3. 设计缓存策略
  4. 修改代码
  5. 添加测试
  6. 执行验证

这个过程类似一个 AI 自动生成开发计划。

值得强调的是，这份计划不是一次性生成后就一路执行到底的。每完成一步，模型都会重新审视剩余步骤——比如分析项目结构后发现用的是 MyBatis 而不是 JPA，后续的改动方案就会跟着调整。计划是活的，这也是 Agent 和「让模型一次性输出脚本」的本质区别。

2) 自动执行任务​

OpenClaw 不只是给建议，而是可以：

  • 修改代码
  • 创建文件
  • 运行 Shell 命令
  • 安装依赖
  • 执行脚本

例如：

# 拉取目标项目到本地
git clone project
# 安装项目依赖
npm install
# 跑一遍测试，验证改动是否破坏了现有功能
npm run test

AI 可以直接执行这些操作。

执行的关键在于结果回传：命令的 stdout、stderr、退出码都会进入下一轮上下文。测试挂了，模型能看到具体是哪个用例、什么报错，然后自己去改——这就是「持续迭代直到任务完成」的具体形态。

3) 工具调用能力​

OpenClaw 可以通过 Tool 调用不同能力，例如：

  • 文件系统
  • Shell
  • Git
  • HTTP API
  • 编译工具
  • 测试框架

工具本质上是暴露给模型的一组带描述的接口，模型根据任务自行决定调用哪个、传什么参数。这套机制是可扩展的：把内部系统包一层接口注册进去，Agent 就能操作它。能力边界不取决于框架本身，而取决于你愿意给它接上多少工具——当然，接得越多，权限控制也就越需要谨慎。

OpenClaw 的缺陷​

虽然 OpenClaw 很强，但目前仍然存在一些明显问题。

1) 非常依赖模型能力​

OpenClaw 的能力 高度依赖底层模型。

如果模型能力不够：

  • 任务规划能力会下降
  • 代码质量下降
  • 执行容易出错

因此很多时候：

Agent能力 ≈ 模型能力

如果模型弱，OpenClaw 也会变得“很傻”。

这个问题在 Agent 场景下会被放大：普通对话里模型答错一句，人看一眼就能纠正；而在多步执行的循环里，第一步的错误规划会被后续每一步继承，错误是累积的。框架层面的提示词工程只能兜住一部分，兜不住模型本身的推理短板。

2) Token 成本问题​

Agent 系统通常需要：

  • 多轮思考
  • 多次调用模型
  • 持续上下文

对Token的消耗非常高，每次都携带了大量上下文进行模型调用，就算调优也只是减少部分开销，或者替换便宜的模型，但便宜的模型替换又会导致上面的问题，OpenClaw变得完全不可靠，不可控。

原因不难理解：每一轮调用都要带上任务目标、历史操作、文件内容和命令输出，上下文随着迭代轮数近似线性增长，而每轮都是一次完整的模型调用。一个多步任务下来，消耗可能是单次对话的几十倍。成本和能力在这里是一对绕不开的矛盾——省钱换弱模型，第一个问题立刻找上门。

踩坑与注意​

结合前面两个缺陷，实际使用中有几点建议：

  • 别在生产环境直接跑。 Agent 会真的执行命令，删文件、改配置都是真删真改。放进容器或者隔离的工作目录里跑，权限给到最小。
  • 任务要拆小。 目标越大，规划越容易跑偏，上下文也膨胀得越快。「加一个缓存」比「重构整个数据层」靠谱得多。
  • 盯着执行过程。 前面提到执行过程不透明的问题，在没有配套监控平台的情况下，至少要保留完整的操作日志，事后能追溯它到底动了什么。
  • 给成本设上限。 多轮迭代的 Token 消耗很容易失控，尤其是模型在某个错误上反复重试的时候。设置轮数上限或预算上限，避免一觉醒来账单爆炸。

总体来说​

OpenClaw 是一个非常有潜力的 AI Agent 框架。

优点：

  • 自动任务规划
  • 自动执行能力
  • 可扩展的 Agent 架构

缺点：

  • 非常依赖模型
  • Token 成本较高 (模型调用非常高，复杂任务能力完全取决于模型)
  • 执行过程不透明 (非常严重，执行过程完全不透明，需要配合控制平台一起监控才行)

因此它目前更适合：

  • AI 自动化开发
  • DevOps 自动化
  • AI Agent 实验

但如果结合：

  • 强模型
  • 可视化系统
  • Agent 管理平台

未来可能会成为：

AI 自动化团队的核心基础设施。

小结​

Agent 框架的价值在于把模型的输出接到真实环境里闭环执行，OpenClaw 在这条路上做得足够完整：规划、执行、工具调用三件事都有。但它的上限被模型能力锁死，下限被成本和透明度拖累。现阶段我的用法是：小任务、隔离环境、盯着日志跑。等围绕它的监控和管理生态成熟一些，再考虑放到更重要的流程里。

评论 / COMMENTS