先说一个我自己的观察。过去一年我帮几支团队看AI agent落地，卡点很少出现在"模型够不够聪明"上，反而集中在同一件事：会话不可续。你和agent聊了四十分钟，把需求拆完、把上下文喂饱，关掉窗口，第二天想接着干，得从头再讲一遍。agent没有记忆，没有排期，没有检查点，它只是一次对话。
KiroCrew这个项目想解决的正是这件事。原项目kirodotdev/KiroCrew目前4400 stars，主语言Python，Apache-2.0许可。它的官方一句话描述是：A persistent workspace for development work that self-improves and continues beyond one session——一个能自我改进、并跨越单个会话持续运行的开发工作区。
现在有了中文翻译版：https://github.com/yangshun2005/KiroCrew-cn 。翻译日期是2026-10-14，翻译已完成。需要说清楚的是，中文版今天刚发布，stars还是0，它不是另一个项目，就是把原项目文档翻译过来，让中文用户少一道语言门槛。
它到底"持久"在哪里
README里有一段话我觉得是理解这个项目的钥匙：多数AI agent会话在关闭聊天后就结束了，而KiroCrew的会话、记忆、调度和任务检查点能在Gateway重启后保留。计划任务和无人值守的多步任务可以持续运行。
拆开看是四个东西：会话、记忆、调度、任务检查点。它们的共同前提是"能扛住Gateway重启"。这一点在企业场景里比想象中重要——不是每个人都能接受一个跑长任务的agent，进程一挂，中间状态全丢。
交互入口它给了好几条：桌面应用、Web仪表盘、CLI，另外还能通过Slack、Discord这类消息渠道继续同一份工作。这个设计思路我比较认可，agent不该被绑死在一个聊天窗口里，你在工位上用仪表盘，出门用手机上的Slack接着推，指向的是同一份工作状态。
再往上一层是KiroCrew Apps，README的说法是把这种体验定制到特定工作场景，把专用界面和智能体、技能、计划、集成、后端服务组合起来。这块我还没实际跑过定制流程，暂时不下结论。
装之前必须先搞明白的前置条件
这是最容易踩的坑，我放在最前面说。
KiroCrew的默认agent运行在kiro-cli之上，而kiro-cli需要你单独安装并登录。首次启动时它会检查这个前置条件，缺失的话会链接到官方安装指南。也就是说，它不是那种装完就能用的单体工具，有一条外部依赖链。
README里没有给出kiro-cli的明确安装命令，只说明要参考正文。所以我的建议是：先把kiro-cli装好、跑通kiro-cli login，再去装KiroCrew本体，顺序反了会浪费一轮排查时间。
环境要求我列一下，都是README原文：
- 操作系统：macOS、Linux、Windows都支持，但Windows需要走原生源码安装，参考Windows指南
- Python：3.12+，pyproject.toml里声明的是
requires-python = ">=3.12"，支持CPython 3.12–3.13 - Node.js：源码构建需要22.12+，推荐24 LTS，还要npm
- 默认agent依赖：
kiro-cli，需要在Gateway主机上安装并运行kiro-cli login - 硬件架构：macOS覆盖x86_64和arm64，Linux覆盖x86_64和aarch64
- Docker方式：用GHCR上的公开多架构镜像
ghcr.io/kirodotdev/kirocrew:stable
另外提醒一句，国内网络环境可能需要换镜像源或者加速下载。README里没有给具体的镜像源配置，只说参考install guide，这一块得自己想办法。
一行命令跑起来
最短路径就三步。
第一步，装kiro-cli并登录。原文没给命令，按官方安装指南走。
第二步，一行命令装Stable版，不需要克隆仓库，也不需要构建前端：
curl-fsSLhttps://download.crew.kiro.dev/cli.sh|sh第三步，打开http://localhost:5476。
如果你需要固定版本，加--version。这里有个细节值得注意：最小可固定版本是0.1.2，因为0.1.0和0.1.1早于manifest签名机制，没有可解析的签名manifest。比如固定到0.6.0：
curl-fsSLhttps://download.crew.kiro.dev/cli.sh|sh-s----version0.6.0生产环境我倾向于固定版本，不跟着Stable漂。这个习惯和agent本身无关，是运维常识。
源码构建的路子
如果你要改代码或者做二次开发，README给的步骤是：
gitclone<仓库地址>cdKiroCrewmakebuildsource.venv/bin/activate kirocrew setup kirocrew doctor kirocrew gateway这里有两个坑。
一是前端要单独构建。前端用npm/Vite在website/目录下构建，产物需要staged到src/kiro_crew/static/dist之后再打包。不是make build一把梭就完事，前端产物没staged过去，跑起来会缺页面。
二是install.sh默认只装预编译wheel。遇到没有预编译wheel的依赖，它会直接拒绝构建，不会自动降级去源码编译。如果你确实需要允许源码编译，得设置KIROCREW_ALLOW_SOURCE_BUILDS=1，同时机器上要有C工具链和-dev头文件。这个设计我认为是对的，默认不编译能保证安装可复现，但第一次遇到报错的人容易懵。
kirocrew doctor这个命令值得单独说一句。它出现在构建流程里，作用类似环境自检。装完先跑doctor再起gateway，能省掉不少"起来了但不对劲"的时间。
发布渠道怎么选
Stable是默认渠道，Insider跟候选发布版本，Nightly跟main分支。README提到发布运行手册里有触发条件、版本形态、晋升行为、发布节奏和更新通道语义。
我的建议很直接：团队用Stable，个人折腾可以用Insider，Nightly只适合你想跟最新改动或者准备提PR的情况。理由不是稳定性玄学，而是Nightly跟main意味着你遇到问题时，别人很难复现你的版本。
中文版真正省掉的是什么
说回中文版本身。
它做的事情不复杂：把原项目README翻译成中文，保留README_en.md作为对照，翻译日期2026-10-14。顶部还加了一段"中文快速上手"，明确标注为非原文内容，是面向中文用户的补充导读，目的是让你不用读完整篇README就能先把项目跑起来。
这个补充导读的价值，恰恰在于它把"这是什么/解决什么问题"“最短路径”“环境要求”“常见坑"四件事前置了。原README信息很全，但对第一次接触的人，得先读一大段才能定位到"我该敲哪条命令”。
翻译本身也有取舍。README里写明了：如有翻译不准确之处，欢迎提Issue或PR。这是负责任的做法，翻译版最怕的就是把原文的技术细节"意译"没了。我对照着看了几处关键描述，比如Gateway重启后保留会话、记忆、调度和检查点这段，中文版是贴着原文走的，没有加戏。
需要克制地说一句：中文版刚发布，翻译已完成，但还没有经过大规模使用检验。术语选择是否顺手、后续原项目更新能不能跟上，这两点我暂时给不出结论，样本太少。
选型时我会怎么看这类项目
不针对KiroCrew，说一套我自己在用的判断顺序，供参考。
第一看持久化边界在哪。是进程内持久，还是能扛进程重启，还是能扛机器重启。这三个层级对应的运维成本差一个量级。KiroCrew README明确说的是能扛Gateway重启，这个层级对多数内部工具够用，但你要清楚它不等于分布式高可用。
第二看外部依赖链有多长。KiroCrew依赖kiro-cli，这就意味着你的部署清单里多了一个需要独立安装、独立登录、独立升级的组件。依赖链越长，权限和凭证管理越要提前设计，尤其是团队共用一台Gateway主机的时候。
第三看入口数量。桌面、Web、CLI、Slack、Discord，入口多对使用者是好事，对管理员是负担——每个入口都是一条访问路径。落地时我一般建议先只开一个入口，跑顺了再加。
第四看无人值守任务的可观测性。README提到计划任务和无人值守的多步任务可以持续运行，心跳机制持续监控系统直到有需要关注的事项。这类能力落地时，重点不是"能不能跑"，而是"跑歪了你怎么知道"。这块的具体实现我还没深入，先留个问号。
第五才是文档语言。中文文档能显著降低上手成本，但它排在后面，因为前四条决定项目能不能用，第五条只决定用得顺不顺。KiroCrew中文版解决的正是第五条，而它顺手把第一条到第四条的关键信息也前置了，这是我觉得它比单纯翻译更有用的地方。
落地顺序建议
如果你打算在团队里试，我给一个顺序。
先在单机上跑通一行安装加kiro-cli login，确认http://localhost:5476能打开。这一步只验证环境，不碰业务。
然后跑一个短的多步任务，故意把Gateway重启一次，看会话和检查点是不是真的还在。这是验证"持久化"这个核心卖点最直接的方式，比读十遍文档有用。
再往后接一个消息渠道，比如Slack，验证跨入口能不能续上同一份工作。
最后才考虑KiroCrew Apps那层定制，以及把计划任务交给它无人值守跑。顺序不要倒过来，前面没验证就上无人值守，出问题很难定位。
至于Docker方式，ghcr.io/kirodotdev/kirocrew:stable是公开多架构镜像，适合常开服务器场景。但镜像方式同样绕不开kiro-cli的前置依赖，别以为容器化就把依赖问题解决了。
收个尾
KiroCrew这个项目值得看的地方，是它把"agent会话"当成一个有生命周期的对象来设计，而不是一次性的问答。会话、记忆、调度、检查点，加上扛Gateway重启，这套组合指向的是能长期驻留的开发工作区。
中文版把这道语言门槛拿掉了，README翻译加中文快速上手导读，让你能更快走到"跑起来"那一步。它今天刚发布，stars还是0，翻译已完成但使用验证还早，这个预期要摆正。
我的建议是：把它当成一个值得花两小时试一下的项目，按上面的顺序走一遍，重点验证重启后状态还在不在。这一条过了，再谈别的。
