先说一个我自己的观察。过去一年我帮几支团队看AI agent落地卡点很少出现在模型够不够聪明上反而集中在同一件事会话不可续。你和agent聊了四十分钟把需求拆完、把上下文喂饱关掉窗口第二天想接着干得从头再讲一遍。agent没有记忆没有排期没有检查点它只是一次对话。KiroCrew这个项目想解决的正是这件事。原项目kirodotdev/KiroCrew目前4400 stars主语言PythonApache-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 AppsREADME的说法是把这种体验定制到特定工作场景把专用界面和智能体、技能、计划、集成、后端服务组合起来。这块我还没实际跑过定制流程暂时不下结论。装之前必须先搞明白的前置条件这是最容易踩的坑我放在最前面说。KiroCrew的默认agent运行在kiro-cli之上而kiro-cli需要你单独安装并登录。首次启动时它会检查这个前置条件缺失的话会链接到官方安装指南。也就是说它不是那种装完就能用的单体工具有一条外部依赖链。README里没有给出kiro-cli的明确安装命令只说明要参考正文。所以我的建议是先把kiro-cli装好、跑通kiro-cli login再去装KiroCrew本体顺序反了会浪费一轮排查时间。环境要求我列一下都是README原文操作系统macOS、Linux、Windows都支持但Windows需要走原生源码安装参考Windows指南Python3.12pyproject.toml里声明的是requires-python 3.12支持CPython 3.12–3.13Node.js源码构建需要22.12推荐24 LTS还要npm默认agent依赖kiro-cli需要在Gateway主机上安装并运行kiro-cli login硬件架构macOS覆盖x86_64和arm64Linux覆盖x86_64和aarch64Docker方式用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.0curl-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_BUILDS1同时机器上要有C工具链和-dev头文件。这个设计我认为是对的默认不编译能保证安装可复现但第一次遇到报错的人容易懵。kirocrew doctor这个命令值得单独说一句。它出现在构建流程里作用类似环境自检。装完先跑doctor再起gateway能省掉不少起来了但不对劲的时间。发布渠道怎么选Stable是默认渠道Insider跟候选发布版本Nightly跟main分支。README提到发布运行手册里有触发条件、版本形态、晋升行为、发布节奏和更新通道语义。我的建议很直接团队用Stable个人折腾可以用InsiderNightly只适合你想跟最新改动或者准备提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翻译已完成但使用验证还早这个预期要摆正。我的建议是把它当成一个值得花两小时试一下的项目按上面的顺序走一遍重点验证重启后状态还在不在。这一条过了再谈别的。