Amazon 最近宣布开源 Kiro Crew。它提供一个工作空间，用于跨会话、工具和任务运行多个 Kiro 编码代理。开发者可以把事故调查、工单分流、代码迁移和 PR 监控交给异步代理处理，即使人暂时离开，任务仍能继续推进。
这类系统的重点并不是让一个代理生成更多代码，而是把编码代理组织成一组可持续运行的工作单元：每个代理接收明确任务，使用所需工具，在独立会话中工作，并把结果交回工作空间供人审查。
从一次性对话转向持续任务
传统编码代理通常围绕一次交互展开：开发者提出问题，代理修改代码，然后等待下一条指令。Kiro Crew 所代表的模式更接近一个异步任务队列。
开发者可以先拆分工作：
- 一个代理调查生产事故的可能原因；
- 一个代理整理并归类待处理工单；
- 一个代理执行依赖升级或接口迁移；
- 一个代理持续检查 PR 的构建和审查状态。
这些任务不一定需要同时由人盯着。代理可以在自己的会话中收集信息、调用工具、生成变更或报告，开发者再根据结果决定是否合并代码、升级事件等级或继续分派任务。
这也改变了任务设计方式。适合异步执行的任务通常具有明确输入、可检查输出和有限权限，例如“分析最近一次部署失败的日志并列出三个最可能原因”，而不是“把整个系统优化一下”。
多代理系统真正解决的是什么
多个代理并不自动等于更高效率。价值来自任务之间的边界和交接关系。
在事故调查中，可以让调查代理只读访问日志和监控数据，让修复代理基于调查结果创建补丁，让验证代理运行测试并检查回归风险。这样做能把探索、修改和验证分开，减少一个代理在同一会话中不断改变目标的问题。
在迁移工作中，也可以按阶段拆分：扫描旧接口、生成迁移清单、修改代码、执行测试、监控 PR。每个阶段都应该留下结构化结果，例如受影响文件、失败测试、待人工确认的行为变化。
需要注意的是，代理之间的协作协议仍然需要由工程团队定义。文件锁、分支策略、权限范围、超时、重试和人工审批都不是“多开几个代理”就会自然解决的问题。
可以这样组织异步编码任务
下面是一个可改造的任务清单示例。它不是 Kiro Crew 的固定配置格式，而是一种适合放入仓库或任务系统的工作流描述。运行前请根据实际工具接口替换 dispatch-agent 命令和权限配置。
# crew-tasks.yaml
project: payments-api
workspace: ./workspace
max_parallel_tasks: 3
agents:
- id: incident-investigator
task: 调查最近一次生产部署失败的原因
inputs:
- logs/deploy-latest.log
- docs/runbook.md
output: reports/incident-investigation.md
permissions:
- read:logs
- read:repository
- id: migration-scanner
task: 扫描仓库中仍在使用 v1 payment API 的代码位置
inputs:
- src/
- tests/
output: reports/payment-api-migration.md
permissions:
- read:repository
- id: pr-monitor
task: 检查当前 PR 的构建、测试和审查状态，并报告阻塞项
inputs:
- .github/
output: reports/pr-status.md
permissions:
- read:repository
- read:ci-status
可以用一个简单的 shell 调度脚本把任务交给实际的代理运行器：
#!/usr/bin/env bash
set -euo pipefail
workspace="${1:-.}"
mkdir -p "$workspace/reports"
# 将 dispatch-agent 替换为实际的 Kiro Crew 或内部代理调度命令。
dispatch-agent \
--workspace "$workspace" \
--task "调查最近一次生产部署失败的原因" \
--input "$workspace/logs/deploy-latest.log" \
--output "$workspace/reports/incident-investigation.md" \
--read-only
dispatch-agent \
--workspace "$workspace" \
--task "扫描 v1 payment API 的使用位置并生成迁移清单" \
--input "$workspace/src" \
--output "$workspace/reports/payment-api-migration.md" \
--read-only
实践中，任务输出最好是 Markdown 报告、补丁文件或结构化 JSON，而不是一段无法验证的自然语言。对于会修改代码的代理，可以要求它使用独立分支，并把测试结果和变更摘要一并提交。
采用时要盯住边界
异步代理适合处理等待时间长、重复性高、结果容易验证的工作。它们不适合在没有审批的情况下直接执行高风险生产操作，也不应该拥有超出任务需要的凭证和写权限。
落地时可以从三个约束开始：
- 每项任务都有明确的输入、输出和完成条件。
- 修改型代理使用隔离分支或临时工作区，合并前必须经过测试和人工审查。
- 所有会话、工具调用、失败重试和最终产物都保留可追踪记录。
Kiro Crew 的开源意义在于，它把编码代理从单次聊天窗口带到了可持续运行的工作空间。真正的收益取决于任务拆分、权限控制和结果验证。把它当作一个异步工程执行层来设计，通常比把它当作“更聪明的自动补全”更接近实际价值。