AI开源软件工具

AWS 把编码 Agent 变成「长期员工」：Kiro bots 正式可用，每个 bot 有自己的记忆、权限和排班

2026年11月7日2 次阅读
AWS 把编码 Agent 变成「长期员工」：Kiro bots 正式可用，每个 bot 有自己的记忆、权限和排班

先讲结论：从「管会话」变成「管岗位」

2026 年 11 月 5 日，AWS 在 Kiro Crew 里正式上线了 Kiro bots。官方博客的原话是 "generally available in Kiro Crew"——不是预览，是可用的正式功能。

一句话说清它解决什么：过去你用 AI 写代码，是开一个会话干一件事，干完关掉，下次再从头解释一遍背景；现在你可以给「构建健康」「代码审查」这类长期职责各建一个 bot，它有名字、有独立记忆、有自己的工具权限，会自己开子会话干活，只在需要你拍板时才回来找你。

需要先说明：核心事实来自 Kiro 官方博客、官方 changelog 和 kiro.dev/crew 产品页；第三方判断（分析师评价、行业影响）基于多家媒体转述整理，主要来自 InfoWorld 11 月 5 日的报道，VentureBeat 等媒体同日也做了转述。

这个 bot 到底是什么

按官方定义，bot 是一个「具名的、长期运行的 Agent」，你为它划定一块固定的工作职责。它和普通会话的区别在于四件事：

  • 有自己的工作区：目标、笔记、里程碑、check-in 都归它自己，不混在聊天记录里。
  • 有自己的记忆：官方叫 Notes，记录项目背景、你之前做过的决定、偏好和约束。你可以随时查看、编辑、删除，记忆不是黑盒。
  • 有自己的权限：只拿到这份职责需要的工具。官方举的例子很直白——研究 bot 能搜网页、读文件，但不许改文件；部署 bot 能跑部署脚本，但每次变更前要你批准。
  • 有自己的看板：你可以直接跟它说「我想看什么」，它维护一个仪表盘，把这一块的状态摊在一页上。

它还能在聊天里被安排日程：比如每天早上排查隔夜的构建失败，或者每周五准备发布说明。定时任务的结果进工作日志，只有「发现」和「需要你决策」才回到聊天。

怎么用：四步就能起第一个

  1. 打开 Kiro Crew 侧栏的 bots 工作区，点 Add a bot。
  2. 选底子：默认 agent，或你已有的 custom agent（它会继承那个 agent 的提示词、模型、工具和技能）。
  3. 写清职责和边界：它负责什么、能看哪些来源、什么算「做完了」、什么时候必须问你。
  4. 加一个日程，先跑一周，再根据结果调权限和提示词。

官方建议从一个「窄到能一次评审完、又值得重复做」的职责开始。四个现成模板可以直接抄：

  • Issue 分诊 bot：读工单队列、打标签、标重复，对 bug 起草复现步骤；能评论，不能关闭。
  • 构建健康 bot：每 30 分钟查一次 CI，把新失败和你已知的 flaky 测试分开，只报需要人看的。
  • 代码审查 bot：按你过去的决定（比如错误处理怎么写、哪个依赖已经排除）审每个 PR；能评论、能要求修改，不能批准、不能合并。
  • 发布就绪 bot：管发布前清单，确认改动有测试和发布说明，最后要你签字才上线。

另外两个细节值得注意：每个 bot 可以单独选模型，它的子 Agent 也可以选更便宜更快的模型——「用强模型做规划、用快模型做例行检查」是官方明确支持的省钱路径。Kiro Crew 本身是 Apache-2.0 开源项目，代码在 GitHub 的 kirodotdev/KiroCrew，截至目前约 4.8k stars，安全上有 8 层防护（命令黑名单、治理上限、敏感路径保护、工具审批、OS 沙箱、凭证脱敏、签名审计日志等），可以自己审。

为什么这事值得关注

不是「又多了一个 Agent 功能」，而是把 Agent 的组织方式从「任务」换成了「职责」。

当一个人同时开五六个 Agent 会话时，真正的工作量不在写代码，而在当调度员：记住每个会话停在哪、谁在等审批、哪一步跑偏了。InfoWorld 引用的分析师把这个成本叫「协调税」（coordination tax）——并行的后台重试和工具调用会让 token 和算力开销迅速叠加。Kiro 的做法是把这份协调工作交给一个常驻的监督者：bot 自己开并行子会话、盯着进度、把跑偏的拉回来，最后只把结果和需要决策的点交回来。

对普通开发者的实际差别是：你不再需要「记得上下文」，而是「设定判断标准」。

适用场景：谁现在就该试

  • 长期维护的项目：仓库里有稳定的 CI、issue 队列、发布节奏——这三块正好对应 build-health、intake、release 三类 bot。
  • 一个人管多个仓库的独立开发者：没有人帮你分担上下文切换，一个常驻 bot 相当于多一个不上班的搭档。
  • 团队想统一评审标准：把「我们团队的评审规矩」写进代码审查 bot，比让每个新人和每段 AI 输出重新学一遍更稳定。
  • 已经在用 CLI / IDE Agent、但被会话管理拖住的人：Crew 复用你现有的 .kiro 配置、skill 和 MCP server，迁移成本低。

不适用的情况

  • 一次性任务：就改一个函数、查一个报错，用普通会话更快，建 bot 是纯开销。
  • 没有稳定输入源的职责：如果你的流程每周都在变，先别自动化，先把流程定下来。
  • 需要强审计的敏感操作：bot 可以申请更多工具权限，但授权链越长，越难回溯「它为什么这么做」。官方虽然提供审计日志和可编辑记忆，但跨数周的决策追溯仍是被点名的风险。
  • 想靠它省钱的团队：Crew 本身免费，但 Agent 的推理走你的 Kiro 套餐额度，定时任务照样计费。只有「纯脚本、不调模型」的定时任务才不消耗请求。

避坑：三个已经出现的问题

  1. 权限蔓延：bot 会主动申请新工具，人容易一路点同意。建议像对待外包一样，给每个 bot 固定身份范围、预算上限，定期重审权限，而不是养成「看到弹窗就批」的习惯。
  2. 成本放大：并行 + 后台重试 + 定时任务，是三个乘数。上线前先只放一个 bot、一个日程，量一周的「正确完成量 / 人工评审时间 / 运行成本」三项，再决定是否扩。
  3. 行为漂移：每个 bot 会随你的纠正不断演化，几周后两个 bot 的做事风格可能完全不同。把关键约束写成可检查的规则文件，而不是靠一句句口头纠正。

同一时间窗口的其他更新（截至 11 月 6 日）

  • 11 月 3 日，Kiro CLI 3.0.0：V3 成为默认 Agent 框架，Classic 界面、桌面 App、内联补全正式退役；V3 带来云会话、记忆、自动审批、/sandbox 隔离和 Workflows。
  • 11 月 4 日，额度共享（credit pooling）：企业可按席位共享额度，每席位 20 美元/月、含 500 credits，最少 2 席位，首月按天折算。
  • 11 月 4 日，模型转正：Claude Haiku 5.5 与 Kimi K3 在 IDE / CLI / Crew / Web 全面 GA。
  • 11 月 5 日，IDE 1.4.121 与 CLI 3.1.0：新增压缩前后 Hook（Pre/Post Compaction），压缩前可拦截、压缩后可把摘要外的信息补回上下文；子 Agent 获得只读记忆访问；CLI 的 /usage 开始显示本次会话已用额度。

成本与时间

  • 钱：Kiro Crew 本身不单独收费，但必须绑一个 Kiro 套餐；Crew 的模型请求和 IDE / CLI 一样计入套餐，没有单独计费。企业席位 20 美元/月含 500 credits。真正的不确定项是并行子会话的 token 消耗，建议先按「一个 bot 一天跑几次、每次几个子会话」估。
  • 时间：建第一个 bot 大约 10~20 分钟（含写边界）；跑一周能看出它是否真的减少了你的上下文切换。

行动建议

  1. 先列出你这周重复解释过两次以上的上下文——那就是第一个 bot 的候选职责。
  2. 只给它读权限 + 一个日程，观察三次运行结果，再决定要不要放开写权限。
  3. 把「什么算完成」写成三到五条可检查的规则，放进 bot 的说明里，而不是留在聊天记录。
  4. 如果你在用别的 Agent 平台，Kiro Crew 声明兼容 OpenClaw / Hermes 等开放标准技能与 MCP server，可以先拿一个现有 skill 试跑，不必重写。

参考来源

评论

0 条已公开
登录或注册后可以参与评论。

正在加载评论...