title: 花一周Vibe了一个OpenClaw的Agent市场，踩坑记
花一周Vibe了一个OpenClaw的Agent市场，踩坑记
上周我用Vibe Coding的方式，花了大概一周时间做了一个OpenClaw的Agent市场——catchclaw.me。目前收录了288个Agent，主要是从GitHub上的热门开源项目转换成OpenClaw格式，覆盖Engineering、Marketing、Data Analysis等好几个方向。
这篇文章聊聊做这个项目的过程和踩的坑。
为什么要做Agent市场
起因很简单：我自己用OpenClaw的时候，想找一些现成的Agent来用，发现没有一个集中的地方可以浏览和安装。Skills市场倒是有好几个了，但Agent和Skill不一样——Agent更重、更复杂，需要更完善的描述和分类。
加上最近Vibe Coding这个概念很火，我就想试试能不能用这种方式快速做一个MVP出来。
什么是Vibe Coding
简单说就是你不写详细的设计文档、不画架构图，直接跟AI对话描述你想要什么，让AI帮你一路生成代码。你主要负责把控方向、验收效果，具体实现交给AI。
听起来很美好对吧？实际操作中有不少坑。
技术选型
最终方案是这样的：前端用的Next.js，部署在Vercel上。后端其实没有传统意义上的后端服务，Agent数据是预先从GitHub上爬取下来生成JSON的，构建时直接打包进去。
安装方式做了clawhub install的集成，用户点一下就能把Agent装到自己的OpenClaw里。
为什么选这个方案？因为一周时间实在太短了，能少做一个后端服务就少做一个。静态数据加上Vercel的边缘缓存，性能反而还不错。
踩的坑
坑一：GitHub项目转OpenClaw格式没有标准
这是最头疼的问题。每个GitHub项目的结构都不一样，有的有完善的README和配置文件，有的就一个main.py和几行注释。我需要从这些参差不齐的信息里提取出Agent的名称、描述、能力、依赖等字段。
最后的方案是让AI去读每个项目的README和代码，然后生成标准化的Agent描述。准确率大概在70%左右，剩下的需要手动调整。
坑二：Vibe Coding的"Vibe"会漂移
一开始AI理解你的意图，写出来的代码是对的。但随着项目变复杂，你会发现AI开始"自由发挥"——加一些你没要求的功能，或者用一种跟已有代码风格不一致的写法。
我的经验是，每隔几个小时就需要停下来整理一次代码，把AI写的东西review一遍，该删的删、该改的改。完全放手让AI写是不现实的。
坑三：288个Agent的分类是个苦力活
一开始我想用AI自动分类，但效果很不好——同一个Agent被归到了三四个不同的类别里，或者一些明显属于Engineering的Agent被归到了General里。
最后还是半手动搞的：先让AI做一个初始分类，然后我逐个过了一遍调整。这个过程花了差不多两天时间。
坑四：clawhub install集成的文档太少
clawhub的安装协议文档写得比较简略，很多边界情况没有说明。比如Agent有额外的系统依赖怎么处理、版本冲突怎么办、安装失败怎么回滚。这些问题我最终都是看源码和试错解决的。
一周做完的感受
说实话，Vibe Coding确实能大幅加速开发。如果用传统方式，这个项目至少要两到三周。AI帮你处理了大量的样板代码、UI组件、数据处理脚本，你可以把精力放在产品逻辑上。
但它也不是银弹。代码质量需要你自己把关，产品方向需要你自己判断，AI写的bug也需要你自己调。所谓的Vibe Coding，核心不是让AI写代码这个动作，而是你要有足够清晰的产品想法来引导AI。
Agent市场会像App Store一样爆发吗
这是很多人关心的问题。我做了catchclaw之后，有一些自己的想法。
乐观的因素：OpenClaw的用户在快速增长，Agent的需求确实存在，而且Agent比Skill更有商业化价值（可以收费、可以订阅）。
悲观的因素：目前大部分Agent的质量还不够好，很多就是简单的prompt包装。真正有复杂工作流、能解决实际问题的Agent不多。而且Agent的使用门槛比App高很多，普通用户不太容易上手。
我个人觉得Agent市场更可能走一条跟App Store不同的路——不会有那种全民下载的爆发，而是在特定的专业人群里稳步增长。比如开发者、数据分析师、营销人员这些用OpenClaw比较多的群体。
最终能不能做大，取决于Agent的质量能不能跟上。288个Agent里面，真正好用的可能不到30个。这个比例需要提高。
你们有尝试做过类似的Vibe Coding项目吗？或者用过什么好用的Agent？来评论区分享一下经验。