Kiro Crew：把 AI 编程从一次性对话变成驻留的同事

技术拆解：解析 AI 技术框架——说明、分析、技术评估、价值判断、落地使用。 作者：永亮

---

title: “技术拆解008｜Kiro Crew：把 AI 编程从一次性对话变成驻留的同事” cover: cover.png author: 永亮 digest: ""

技术拆解：解析 AI 技术框架——说明、分析、技术评估、价值判断、落地使用。 作者：永亮

---

大多数 AI 编程会话有一个共同的终点：关掉聊天窗口，会话里积累的判断、纠错和上下文全部清零，下一次从零开始。2026 年 7 月，Amazon 旗下 Kiro 团队把一个针对性的答案扔进了开源社区：Kiro Crew——一个跑在你自己硬件上的持久化开发工作区，跨会话记住工作、把纠错固化为教训、把重复模式固化为技能，人不在场时也能按排程继续干活。项目创建两个月，截至 2026 年 9 月已经拿到约 3,891 个 star、213 位贡献者、发版到 v0.6.0。这篇文章拆六件事：它是什么、核心机制一直到源码层、技术上怎么评估、值不值得用、怎么落地，以及——如果你想自己写一套类似的持久工作区，最小骨架是什么。

一、这是什么

一句话定位：Kiro Crew 是一个跑在本地或你自己服务器上的开源开发工作区，核心主张是工作不该随聊天窗口关闭而结束——会话、记忆、排程、任务检查点都持久化，纠错和失败会变成长期教训，重复的模式会被固化成可复用技能（README 原文：persistent, self-learning, and self-evolving）。

关键事实先摆清楚。仓库 kirodotdev/KiroCrew，2026 年 7 月 16 日创建，主语言 Python（后端约 1,492 个源文件），前端是 React + TypeScript + Tailwind 的仪表盘加 Electron 桌面壳（约 3,712 个源文件），另有 2,502 个测试文件。代码协议 Apache-2.0，但仓库 NOTICE 文件写得很明白：版权归属 Amazon.com, Inc. 或其关联公司；Kiro 与 Kiro Crew 的名称和标识是商标，不在软件许可范围内。它和 AWS 的 Kiro 是同一个团队的作品——默认 agent 运行时就是 Kiro 的命令行工具 kiro-cli，由 Kiro Crew 通过 ACP 协议驱动，README 致谢名单里能直接看到多位 Amazon 员工账号。贡献者按提交量排，前四位合计超过 3,000 次提交，三位维护者 Bolin Chen、Joe Guo、Zezhen Xu 都在其中——这是一个真团队在密集投入，不是刷出来的热度。

二、核心机制

2.1 三层切分：运行时、人格、网关

Kiro Crew 的架构文档把系统拆成三层，这个切分是理解一切的钥匙。

最底下是 kiro-cli，一个 agent 运行时（注意不是 agent）：它持有 LLM 连接、工具执行（bash、文件读写、grep）、MCP 服务器管理、会话持久化、上下文压缩，并对外暴露 ACP——Agent Client Protocol，一个跑在 stdio 上的 JSON-RPC 2.0 接口，任何编排器都能驱动它。中间层是 agent 配置：~/.kiro/agents/ 下的 JSON 文件，只描述「这个 agent 怎么表现」——系统提示词、启用哪些工具、挂哪些 MCP 服务器，每个 agent 都以 kiro-cli acp --agent <名字> 的形式运行。最上面才是 Kiro Crew 本体：一个 asyncio 进程，把桌面应用、网页仪表盘、命令行、Slack、Discord、Telegram、飞书、微信、iMessage 等十几个操作面多路复用到同一批运行时上，并补上运行时刻意不表态的一切：排程、审批、记忆、安全策略、消息连接。

一条消息的完整旅程是：先过网关的钩子（自动回复、变换、注入、拒绝），路由到一个会话，由 ContextBuilder 组装上下文（记忆、技能、教训、历史），作为 ACP 的 prompt 发给 kiro-cli，模型流式返回文本和工具调用，网关把事件流推回操作面，同时追加到 JSONL 格式的会话日志，并异步触发一次记忆固化。有一个细节值得强调：工具调用不是从网关直通运行时的——每一个工具调用都要先经过 Kiro Crew 自己的 PreToolUse 检查点，kiro-cli 才被允许真正执行。安全边界划在编排层，而不是指望提示词自觉。

2.2 持久化：五类存储各司其职

「持久化」在 Kiro Crew 里不是一句口号，是五类结构分明的存储。

第一类是给人看的 markdown 记忆。memory.py 的 MemoryStore 管三份文件：preferences.md（用户偏好）、projects.md（进行中的项目上下文）、history/ 目录下按天命名的摘要（YYYY-MM-DD.md）。配一个 SQLite FTS5 全文索引做关键词检索。历史有明确的衰减梯度：最近 14 天的内容完整注入，15 到 60 天的只注入标题加第一条加剩余条数，61 到 180 天塌缩成一行日期和会话数，超过 180 天的不再读取，心跳服务会把超过 365 天的文件从磁盘上清掉。记忆不是越全越好，这个梯度就是工程上的取舍声明。

第二类是向量记忆。vector_memory.py 的 VectorMemoryStore 同样落在 SQLite 里，分语义键值、情景记录、教训三类行，嵌入向量以 BLOB 形式存进数据库。检索是混合打分——源码里的 _hybrid_score 把关键词分数和向量余弦分数合成，没有向量时自动退化为纯关键词。情景记录按标签配置各自的衰减率，重要性参与排序。嵌入计算在进程内完成，用的是打包进来的 llama-cpp-python，不需要独立嵌入服务；代价是换模型时向量空间整体失效，源码为此实现了 reconcile_embedding_space：换模型后旧嵌入全部作废并重算，避免两种向量空间混着排序。

第三类是教训。learn.py 的 LessonStore 是一个 append-only 的 JSONL 文件，每条教训一条记录，只增不改。用户说「不，以后调用完成前先跑前端检查」，这句话就会以工作区级作用域存进去，今后的会话注入提示时被检索到。教训也会被向量化成语义键存储，写入路径有完整的去重和取代规则：新值确认取代旧值后，引用旧值的情景记忆会被退役——源码注释里留着一条测量记录：一个启用数小时的存储里，101 条情景记忆已有 21 条被退役，其中 14 条来自这条规则。同一条注释还解释了为什么每次固化最多只退役 3 条：被取代的值应该退役少数复述它的记录，而不是切走库存的一片。

第四类是会话台账，这是「跨会话延续」最硬的设计。session_ledger.py 给每个会话维护一个工作台账，状态字段包括 goal（目标）、phase（阶段）、next_step（下一步）、tried_approach 和 tried_rejected_because（试过什么、为什么被否）、artifacts（产物）。写台账的 record() 有一条硬纪律，源码原文：a phase must never move without a logged, classified reason——阶段推进必须带着一条已记录、已分类的事件，空转和跳步被数据结构本身拒绝。每个执行周期，台账被渲染成一个小小的 [work ledger] 块注回提示里，agent 每轮都能看见自己之前认定该做的事。台账写在专用锁文件保护的目录里，锁的是 inode 而不是路径——防止删除目录后排队中的写者拿到一个已被摘除的锁、写进幽灵文件。agent_state.py 则用一个 sidecar JSON 加跨进程咨询文件锁，解决仪表盘进程和 CLI 进程对同一份状态的读写竞态。

第五类是多成员隔离的记忆库。memory_stores.py 实现了一套命名记忆库机制：每个成员可以拥有自己的记忆库，配所有权清单防止其他成员或重建的进程接管旧数据，退役有专用标记，V1 旧库和 V2 新库的代际区分写进了加载逻辑。源码注释对这套机制的解释很直白：同一个谓词如果可能悄悄偏离造它的代码，宁可不要这个谓词——静默失败比没有谓词更糟。这类注释在仓库里密度极高，设计决策连同理由一起留在了代码旁边。

2.3 调度与执行循环：三条「闹钟」各管一类无人值守

无人值守不是一句「后台跑个循环」，源码里是三套机制。

第一类是定时任务。cron.py 的 CronService 把任务存在 crons.json，支持 every、at、cron 三种表达式，时区用 IANA 名称经 ZoneInfo 解析——「工作日早 9 点」这类需求按创建者时区落盘。每次点火有一套预算分解：点火门、认领时审查、会话池排队、整次唤醒四个环节各自分到限时额度，总额 deadline 兜住整轮运行，超预算即失败，连续失败的任务自动暂停而不是无限重试。

第二类是心跳。heartbeat.py 的 HeartbeatService 维护一份 HEARTBEAT.md 任务清单，周期醒来逐个执行。agent 的响应里如果带 HEARTBEAT_KEEP 哨兵，这条任务就被判定为未完成，留到下个周期继续——「没做完，下轮再来」被做成一个可机读的信号，而不是靠模型自觉复述状态。清单的读写都过跨进程锁，心跳服务的最终「读→替换」事务不会盖掉另一个进程刚追加的任务。

第三类是自动催促。autonudge.py 的 AutoNudgeService 管理按会话绑定的催促循环：一个会话可以挂一个目标循环，闲置计时器到点就推它再走一步，循环带墙钟预算，超预算自动停，停止原因全部落盘，网关重启后循环从磁盘状态恢复。配套还有结构化监视器——agent 说「盯着这个部署，好了告诉我」，系统会把这句话解析成一个带探针状态的监视循环，而不是指望 agent 自己记得回来看。

会话侧的支撑也在源码里：活跃会话背后要么是专用的 kiro-cli ACP 进程，要么是共享多路复用运行时上的一个会话句柄——会话是逻辑隔离边界，不一定等于一个操作系统进程，空闲会话进 warm pool 等着被复用。

2.4 自我改进：从纠错到技能的三级沉淀

「自我改进」被拆成三级，每一级有自己的存储和触发条件。

第一级是教训：纠错即时入库（LessonStore），写入向量记忆的教训区时经过语义去重——同一条规则的重复提交不会堆叠。第二级是固化：异步运行的 LLM 固化器把会话日志压成偏好、项目上下文和按天摘要，触发条件是消息数（偏好和项目约 30 条消息）和空闲时长（每日历史约闲置 3 小时）。第三级是技能：重复出现的工作模式会被自动固化为一个 SKILL.md 文件，YAML 头里带着来源记录（自动生成、来自哪个会话、创建和精炼时间、复用次数），来源存证的类叫 AutoSkillProvenance。技能不是生成完就完事——字节级重复的技能会被去重，被定时任务引用过的技能豁免淘汰，全部技能在仪表盘里可见、可编辑、可删除。

把账算在一起：这套机制目前由约 1,492 个 Python 源文件支撑，测试文件 2,502 个，比源代码还多——对一个创建两个月的项目，这个比例本身说明了团队把可靠性放在哪里。

三、技术评估

先说结论的依据形态：这个项目没有 benchmark，也没有性能数字可引，评估只能看工程完成度和治理质量。而这两样恰好是它最硬的部分。

看工程完成度，两个指标。一是源码注释的决策密度：session_ledger.py 里锁 inode 的理由、vector_memory.py 里「退役上限为 3」的测量依据、agent_state.py 里「不可读不等于无意见」的读写纪律——几乎每个非平凡函数都带着「为什么这样做」的说明，这是长期维护者才会留下的痕迹。二是测试比：2,502 个测试文件对 1,492 个源文件，配置里有基线文件、错误码基线文件，安全规则有 semgrep 扫描目录。看治理质量：仓库有排序的十条设计原则（TENETS，第一条 Safety first，冲突时靠前的赢且取舍要写下来）、有写明的 RFC 流程、有商标与代码许可分离的声明——这套治理文本在两个月大的项目里属于超规格配置。

和同类方案比，这个方向上的头部方案大致分三类：终端结对编程工具、通用 agent 编排框架、云端托管的 agent 服务。Kiro Crew 和它们都不在一个格子里：它把「运行时」外包给 kiro-cli 自己只管编排与状态，状态五件套（会话与日志、记忆、审批、治理上限、事件总线）由平台持有最后一句话，其余一切界面都做成可替换的 app——它的第十条原则原话是 everything is an app，做不好 app 化的表面是平台的缺陷，不是把表面塞进核心的许可证。代价同样清楚：整套系统硬依赖 kiro-cli，agent.provider 固定为 acp，不进 Kiro 生态这套东西跑不起来。

热度数据要泼点冷水。star 约 3,891、贡献者 213 人，两个数都不低，但未关闭的 issue 和 PR 合计 1,548，对 star 数而言是个很高的比率——试用者多、打磨未完成。分发渠道也特殊：不走 PyPI 和 npm，桌面包和安装脚本走项目自有 CDN，容器镜像在 GHCR，下载量无从公开统计；贡献者名单里 Amazon 员工账号占了显眼位置，外部社区贡献占比尚小。真实使用规模有限，这个判断必须摆在台面上。

四、价值判断

真问题是真的：agent 干完活就忘、纠错重复发生、排程和审批散落在聊天窗口里——这是 2026 年每一个认真用 AI 编程的团队都在经历的损耗。Kiro Crew 的回答是把工作区状态当基础设施：五类存储、三条闹钟、三级沉淀，全部落在自己控制的硬件上，记忆本地优先、默认不回传。对「同事」这个定位，它给出的工程解释相当完整。

边界同样清楚。第一，生态绑定：硬依赖 kiro-cli 和 Kiro 账号体系，不用 AWS Kiro 的人第一步就会被劝退，这对一个通用开源项目是最重的枷锁。第二，架构上限：网关是会话、运行时、状态同机的单进程模型，横向扩展和多机部署目前不在图上。第三，平台差异：Windows 没有同等的操作系统级沙箱，源码的选择是失败关闭——不声明退出就不放行非沙箱执行。第四，商标在 Amazon 手里，代码可以分叉，名字不能带走。什么时候该用：已经在 Kiro 生态里、想要一个跨会话驻留的开发工作区、且数据必须留在自己机器上——它就是现成答案。什么时候不该用：不用 kiro-cli 的团队、需要多机编排的场景、或只想要一个轻量聊天壳——前两种它架构上就不满足，最后一种它重得没必要。

五、如何落地

安装一行，装完打开 http://localhost:5476 就是仪表盘：

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

前置条件只有一个：在网关所在机器装好 kiro-cli 并单独登录，首次启动会自动检查并给出引导。安装器默认用自带管理的 CPython 3.12（uv 引导），不碰系统解释器；想常驻就 kirocrew service install，Linux 装 systemd 服务，macOS 装 launchd。容器路径也现成：

docker run -d --name kirocrew -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew ghcr.io/kirodotdev/kirocrew:stable

日常用法五条命令覆盖大部分场景：kirocrew chat 交互对话，kirocrew run TASK.md 跑带检查点的任务，kirocrew cron 管定时任务，kirocrew spawn run “任务” 派并行子代理，kirocrew security 看审计。运维侧记住三个：kirocrew doctor 体检，kirocrew logs 看日志，仪表盘 Settings 里能关每天一次的匿名使用心跳。选型建议两条：数据目录用 KIROCREW_HOME 显式指定并纳入备份——记忆、教训、技能全在里面；对外暴露仪表盘务必走令牌认证的远程配置，默认绑定回环是安全基线不是默认值。

六、如何自己做一套类似的方案

「自己写一套」在这个题目上尤其可行，因为 Kiro Crew 本身就证明了运行时和状态层可以分开。最小骨架七步：

1. 先切层：选一个现成的 agent 运行时（kiro-cli、claude-code 的 ACP 适配器，或任何能通过 stdio JSON-RPC 驱动的运行时），自己只写网关——消息路由、会话表、状态存储。这一刀切下去，难度砍掉一半。
2. 会话台账：每个会话一份 append-only 的 JSONL transcript，外加一个状态文件记 goal、phase、next_step、tried_approach。写用临时文件加 rename 的原子写，多读多写场景加跨进程咨询锁。把「阶段推进必须带理由」做成写入校验，这是无人值守不跑偏的关键纪律。
3. 双索引记忆：markdown 文件给人读，SQLite FTS5 管关键词，向量以 BLOB 存同库做语义检索，混合打分、无向量时退化关键词。嵌入用进程内的 llama-cpp 类方案即可，换模型时全量作废旧向量。
4. 固化器：起一个异步循环，按消息数或空闲时长触发，让模型把 transcript 压成偏好、项目、按天摘要三级，摘要带衰减窗口（14 天全文 / 60 天缩写 / 180 天一行）。
5. 教训库：一个 append-only JSONL 足够，注入提示前按作用域过滤，写入时做语义去重和被取代值的旧记录退役。
6. 三条闹钟：cron 表达式调度带时区和每环节限时预算，心跳文件用哨兵信号表达「没做完」，目标循环带墙钟预算和落盘的停止原因。
7. 安全门：所有工具调用先过自己的检查点再放行，配合拒绝目录、敏感路径保护和凭据脱敏。这一步不能省——无人值守放大的是权限，不是智能。

七步加起来，一个两人团队一个季度能交出可用版本。Kiro Crew 的两千多个测试文件提醒了另一半真相：能转起来的骨架不值钱，把锁、边界、失败模式一寸一寸磨对才值钱。

结论

Kiro Crew 把 AI 编程工作区从「一次对话」重新定义为「一份持久状态」：五类存储、三条闹钟、三级沉淀，全部本地优先，且每一层都给了源码级的工程解释。它是 Amazon Kiro 团队的开源作品、硬绑定 kiro-cli、真实使用规模尚待验证——但对已经在 Kiro 生态里、又想让 agent 跨会话记住工作的团队，这是目前完成度最高的现成答案；对想自己造一套的人，它的源码是比任何博客都诚实的教材。

参考来源

• Kiro Crew GitHub 仓库（README、TENETS、GOVERNANCE、NOTICE、MAINTAINERS）：https://github.com/kirodotdev/KiroCrew
• Kiro Crew 架构文档（docs/architecture/overview.md：三层切分、消息流、记忆生命周期、后端组件图）：https://github.com/kirodotdev/KiroCrew/blob/main/docs/architecture/overview.md
• Kiro Crew 源码：src/kiro_crew/agent.py（agent 规格与治理投影）、session.py（会话池与生命周期）、memory.py（MemoryStore，markdown + FTS5）、vector_memory.py（VectorMemoryStore，混合检索与向量空间协调）、memory_stores.py（命名记忆库与所有权）、learn.py（LessonStore，append-only JSONL）、session_ledger.py（工作台账与 record 纪律）、agent_state.py（sidecar 状态与跨进程锁）、cron.py（CronService 调度与预算分解）、heartbeat.py（HeartbeatService 与 HEARTBEAT_KEEP 哨兵）、autonudge.py（AutoNudgeService 目标循环）、skills.py（技能加载、来源存证与去重）、session_summary.py（摘要与脱敏）
• GitHub 仓库元数据与贡献者列表（api.github.com，截至 2026 年 9 月）；最新 release v0.6.0（2026-09-11）
• kiro.dev（Kiro 与 kiro-cli 官方站点）