# 龙虾之后，我为什么又装了一个 KiroCrew？ > KiroCrew 不只是 Kiro 的一个新入口，而是加在 kiro-cli 上的一层持久化工作空间——会话管理、长期记忆、Skill、计划任务、多 Agent 和微信/企业微信 Channel。我没让它跑 Demo，而是先让它整理我十多年前的博客，提炼出一份能长期使用的个人写作风格。 - 作者: zhuermu - 发布: 2026-08-09 - 网页版: https://zhuermu.com/blog/kirocrew-experience/ --- 前段时间参加公司内部的一次培训，有人突然问了一句： “KiroCrew 是什么？” 这是我第一次听到这个名字。 当时我没太在意，以为它只是 Kiro 众多端侧（Web、Desktop、Mobile、CLI）里的一个新功能。我直接回了一句：“不知道唉。” 后来刷到一位同事的朋友圈，他转发了一篇文章：[《AWS 开源 Kiro Crew：让 AI 编码智能体进化为自主工程团队》](https://mp.weixin.qq.com/s/cZeXLj12X_9FKCXentqdVg)，配文是：**用 Kiro 养虾，性价比太香了。** 看完介绍，我一下来了兴趣。 它的界面不像临时拼出来的命令行工具，更像一个可以长期使用的 Agent 工作台。我去 Kiro 官网和 GitHub 看了一圈，才发现 Kiro 生态里多了一个开源项目：KiroCrew。 我果断下载下来体验。 装完后的第一反应是：**好家伙，微信和企业微信居然已经支持了。** 更省事的是，我不需要重新准备 OpenAI、Anthropic 或其他模型厂商的 API Key。机器上已经配置好了 kiro-cli ，安装 KiroCrew 后就能直接使用 Kiro 支持的模型。 对长期使用 Kiro 的人来说，这个门槛确实很低。 ## 1它不只是一个新入口，而是一个持久化工作空间 我一开始把 KiroCrew 理解成 Kiro 新增加的一个端侧入口。 真正用起来以后，我觉得它更像是加在 kiro-cli 上面的一层持久化工作空间。 kiro-cli 负责模型推理、编码和工具执行；KiroCrew 在它外面补上了会话管理、长期记忆、Skill、计划任务、多 Agent、消息 Channel 和可视化界面。 简单理解，大概是这样： ![kiro-cli 与 KiroCrew 的能力分层](https://zhuermu.com/images/wx/kirocrew-experience/img-01-ade5d2bf.png) 图 1： kiro-cli 负责推理和执行，KiroCrew 把一次对话扩展成可以持续管理的工作空间。 普通聊天工具的基本单位通常是“一次对话”。窗口关掉或上下文被清理，这次工作很容易就断了。 KiroCrew 想解决的是另一件事：**一次对话结束以后，工作能不能继续。** ## 2它不是产品规划出来的，而是从内部自然长出来的 我后来从内部了解到，KiroCrew 最开始并不是什么正式规划的大产品，而是 AWS 内部几位 Kiro 爱好者开发的小工具。发布后很快受到同事欢迎，短时间内就有数万名内部用户开始使用。 很多产品是先有规划、排期和指标，再慢慢寻找用户。KiroCrew 恰好反了过来：它先解决开发者自己的问题，因为确实有人需要，才一步步长成了今天的样子。 据我从内部了解到，项目早期发起者中有多位中国人或华人。无论这是不是唯一原因，KiroCrew 对国内使用环境的重视是实实在在的——早期版本就把微信和企业微信放进了支持范围。 很多海外 Agent 项目默认大家都在 Telegram、Discord 或 Slack 上工作。但现实是，我们的大量沟通仍然发生在微信和企业微信里。如果一个 Agent 只能活在浏览器或终端里，它离日常使用还有一段距离。 需要说明的是，“短时间内数万名内部用户”来自我了解到的内部信息，不是公开运营数据，目前也没有独立公开资料可以交叉验证。 ## 3我没有先拿它跑 Demo，而是让它整理我十多年前写的博客 安装 KiroCrew 后，我做的第一批事情不是让它表演写代码，而是整理我大学期间写下的博客。 我从 2010 年左右开始写博客，前后写了很多年。内容包括技术学习、ACM、找工作和个人成长。当时没想过什么“个人风格”，有东西想记录就写下来，质量也参差不齐。 有些文章现在回头看，错别字不少，段落也长，很多技术内容早已过时。但里面也保留了一些今天很难重新补出来的东西：当时为什么做一件事、失败时怎么想、遇到了什么人，以及一些很具体的小细节。 我让 KiroCrew 抓取这些旧文章，分析叙事方式、语言习惯和文章结构，再整理成一份可以长期保存的个人写作风格。 它最后总结出四个词：**真实、直接、过程、反思。** 这个结果我基本认可。相比站在讲台上讲“行业趋势”，我更习惯先说自己为什么碰到这个问题，中间踩了什么坑，最后又是怎么理解的。 第一次提炼出来的风格并不完美。它很容易把“口语化”理解成多塞几个“说白了”“本质上”，像 AI 在模仿一个人，而不是这个人自己在说话。 后来我们一起调整 Skill，要求它保留真实经历、选择过程和不体面的部分，而不是机械复制旧文章里的口头禅。 这件事让我真正感受到 KiroCrew 的记忆和 Skill 有什么用。它不只是记住“用户喜欢口语化文章”，而是把旧文章、后续纠正和公众号写作流程逐渐整理成一个可以继续修改的写作系统。 ![在 KiroCrew 中提炼公众号写作风格的实际界面](https://zhuermu.com/images/wx/kirocrew-experience/img-02-988915b7.png) 图 2：实际提炼过程并不只是生成一句风格总结，还包括纠错、收窄边界和反复修改 Skill。 以后再写文章，我仍然要判断内容对不对，也仍然要自己改，但至少不用每次从头解释“不要写成机构稿”“不要为了完整编造故事”。 ## 4微信 Bot 扫码成功了，为什么就是不能用？ 我最初是在公司的电脑上安装 KiroCrew。 配置微信 Bot 时，扫码过程看起来没有问题，但后面始终无法使用。我第一反应是：是不是 KiroCrew 的微信 Channel 有 Bug？ 后来我让 KiroCrew 检查日志和网络请求，最后发现问题不在 KiroCrew，而是公司的终端策略拦截了微信登录。这台工作电脑本来就不允许登录微信，只是扫码界面没有直接告诉我原因。 也就是说，我折腾了半天，一开始就找错了方向。 最后我把 KiroCrew 安装到个人电脑，微信 Channel 才正常跑起来。 ## 5Kiro 本来能看懂图片，为什么到了微信里就不行？ 微信 Bot 跑起来以后，我又发现了一个问题：直接在 Kiro 中发送图片，它可以理解；通过微信把图片发给 KiroCrew，它却看不懂。 后端明明还是 Kiro，模型能力也没有变，为什么换了一个入口就不认识图片了？ 这次我干脆让 KiroCrew 检查自己。 排查后发现，问题不在后端模型。 kiro-cli 本身具备图片理解能力，但微信 Channel 的图片转发链路还不完整，图片内容没有完整进入 Agent 会话。 这个问题目前还没有消失，但排查过程挺有意思：我让一个工具检查自己为什么不能正确接收图片，它最后定位到了自己的集成缺口。 从用户发出图片，到 Channel 接收、下载媒体、转换格式、写入消息，再到模型拿到图片，中间任何一层缺失，最后表现出来都是“它看不懂”。 ![微信图片从用户进入 kiro-cli 的完整消息链路](https://zhuermu.com/images/wx/kirocrew-experience/img-03-a8adae25.png) 图 3：模型能看图，不代表整条消息链路都能传图；当前缺口发生在图片进入 Agent 会话之前。 ## 6真正用起来以后，我最喜欢什么？ 目前使用时间还不算长，但有几个感受已经比较明确。 ### 界面干净，我愿意一直开着 KiroCrew 的界面很干净，没有为了显得专业而塞满监控面板。会话、任务、文件、记忆、计划任务和设置都能找到，第一眼又不会让人觉得压力很大。 纯命令行当然也能工作。但当任务跨越多个会话、多个 Agent 和几天时间后，只靠终端窗口就容易乱。 KiroCrew Dashboard 至少让我知道：现在有哪些会话，哪些任务还在跑，Agent 调用了什么工具，哪些操作正在等审批。 ### 多 Agent 很容易启动，但效果还要看任务 KiroCrew 启动多个 Agent 的门槛很低。一个问题可以拆成几条独立工作流，让不同 Agent 分别调查，再把结果带回主会话。 但我对“多 Agent 能解决所有复杂问题”仍然有疑问。 任务怎么拆、哪些步骤可以并行、结果冲突时听谁的，仍然需要人来判断。Agent 数量多了不一定更快，也可能只是更贵、更乱。 现阶段我认可的是：**它让并行调度变得容易了，最终质量还得看具体任务。** ### 当前上下文丢了，不代表所有工作都消失了 我在改公众号排版 Skill 时，不小心执行了 /clear ，把当前会话上下文清掉了。 重新说“继续”时，它并没有猜出我要做什么。等我补充任务名称后，它重新读取留下的 Skill 文件和相关内容，把没有完成的工作接了下去。 这没有宣传语里“永不失忆”那么神奇，但反而更真实。KiroCrew 不是读心术；当前上下文没有了，它仍然需要历史会话、持久文件、项目状态或一句明确的任务线索。 区别在于，以前清掉会话往往意味着从头再来；现在至少还有恢复路径。 ## 7OpenClaw、Hermes 已经这么火，为什么还会有 KiroCrew？ 研究 KiroCrew 时，很难绕开 OpenClaw 和 Hermes Agent。 截至 2026 年 8 月 9 日，我查看 GitHub 页面时，OpenClaw 大约有 38.6 万 stars，Hermes Agent 大约有 22.7 万，KiroCrew 则是 2400 左右。 差距很大，但 KiroCrew 本来就是围绕 Kiro 用户构建的工具。相比 stars，我更关心它们的差异。我让 KiroCrew 做了一次总结： | 项目 | 产品中心定位 | 更适合关注什么 | | --- | --- | --- | | OpenClaw | 运行在自己设备和聊天渠道里的个人 AI 助手 | 多种消息入口、设备节点、工具与插件扩展 | | Hermes Agent | 能从任务经验中形成记忆并改进 Skill 的学习型 Agent | 学习循环、模型与执行后端选择、研究型工作流 | | KiroCrew | 建立在 kiro-cli 上的持久化开发工作空间 | 多会话、任务延续、调度、可见执行和 Kiro 集成 | 它们有不少重叠能力：Gateway、记忆、Skill、计划任务、消息 Channel、子 Agent。真正的区别不在功能表里有没有某个勾，而在产品把什么放在最中心。 OpenClaw 已经很火，不代表后面不该再出现 Hermes 和 KiroCrew。这个品类还没有找到唯一答案；入口、记忆、执行、安全、调度和模型自由度之间，不同团队自然会有不同取舍。 ![OpenClaw、Hermes Agent 与 KiroCrew 的产品中心定位](https://zhuermu.com/images/wx/kirocrew-experience/img-04-59f777cc.png) 图 4：三个项目有不少重叠能力，真正的差异是各自把入口、学习还是工作空间放在中心。 ## 8KiroCrew 目前也有两个现实问题 ### 微信 Channel 的图片链路还不完整 前面已经提到，Kiro 本身能够理解图片，但从微信发送的图片没有完整转发到 Agent 会话。 这会直接限制手机端的使用场景。比如看到一张报错截图，最自然的动作就是发给 Bot 分析；如果还要回到 Desktop 或 Web 重新上传，微信这个入口就没有完全打通。 ### 现成支持仍然集中在 kiro-cli 对 Kiro 用户来说，复用已有登录、模型和工具环境很省事；对没有用过 Kiro 的人来说，这就是一道额外门槛。 目前 KiroCrew 现成支持的 Agent 大脑仍然是 kiro-cli 。它也支持 ACP（Agent Client Protocol），使用 Claude Code、Codex 等其他 CLI 的用户可以自行构建连接器，但这显然不如开箱即用简单。 没有使用过 Kiro 的用户，可以先体验免费版本，再判断这套绑定是否适合自己。 ## 9我现在怎么看 KiroCrew？ KiroCrew 不像一个从竞品分析表里设计出来的产品。它身上还有明显的内部工具痕迹：先解决自己人的问题，再一点点补齐外部用户需要的能力。 我喜欢这种成长方式，因为它面对的问题通常比较真实；但真实不等于成熟，微信图片链路和其他 CLI 的接入体验都还需要继续完善，长期运行的稳定性也有待验证。 我不会说它是“最强龙虾”。这种结论既没有统一标准，也没什么意义。 但如果你已经在使用 Kiro，又希望 Agent 不只存在于一次 CLI 对话里，我觉得 KiroCrew 值得装下来试试。 对我来说，它目前最有价值的地方很朴素： **我可以把一件没有做完的事留在那里，过一段时间回来，再想办法接着做。** 至于它最后会不会成为我长期使用的 Agent 工作台，我还在继续观察。 毕竟才刚开始养，虾还没长大。 • • • 项目地址： • KiroCrew：https://github.com/kirodotdev/KiroCrew • OpenClaw：https://github.com/openclaw/openclaw • Hermes Agent：https://github.com/NousResearch/hermes-agent 如果你也在使用 KiroCrew，欢迎告诉我你拿它做了什么，以及遇到了哪些坑。 如果这篇文章对你有帮助，欢迎点个爱心、收藏起来，或者转发给同样在折腾 Agent 的朋友。 关注我，继续分享 AI Agent、云计算和技术实践中的真实体验。