Amazon 最近公布了 Kiro Crew，这是一个用于运行多个 Kiro 编码代理的开源系统。它把编码代理从一次性的对话窗口，扩展成可以跨会话、工具和任务持续工作的异步协作空间。
开发者可以把事故调查、工单分流、代码迁移和 PR 监控等任务交给代理。代理在后台继续执行，开发者不需要一直保持当前会话或实时监督每一步操作。
从“问答”转向“任务队列”
传统的编码助手通常围绕一个编辑器窗口或一次对话运行：开发者提出问题，代理给出建议，开发者继续确认。Kiro Crew 的重点则是把任务变成可以独立运行、持续更新状态的工作单元。
这类工作方式更适合以下场景：
- 事故调查：收集日志、定位近期变更，并整理可能的根因。
- 工单分流：读取新工单，提取组件、严重级别和复现信息。
- 代码迁移：按模块推进 API、依赖或配置迁移，并记录未完成项。
- PR 监控：持续检查构建状态、审查意见和需要补充的测试。
关键变化不只是“同时运行更多代理”，而是让任务拥有自己的生命周期。任务可以在开发者离开后继续运行，完成后再返回结果、证据和待处理问题。
多代理系统的价值与边界
多个代理并行工作，可以减少等待时间，也能把不同类型的工作分开。例如，一个代理负责分析日志，另一个代理检查最近的代码变更，第三个代理整理相关工单。最终由开发者审阅汇总结果。
但并行并不等于可以放弃协调。多个代理可能修改同一个文件、重复执行相同检查，或者根据不同上下文得出相互冲突的结论。因此，实际使用时需要明确：
- 每个任务的输入范围和输出格式。
- 代理可以使用哪些仓库、工具和凭据。
- 哪些操作只允许读取，哪些操作需要人工批准。
- 多个任务如何避免同时修改同一分支或目录。
- 任务失败、超时或结果不完整时如何升级给开发者。
Kiro Crew 的异步模式适合降低人工等待，但不应被理解为完全无人值守的生产变更系统。涉及删除数据、修改基础设施、发布版本或合并代码的动作，仍然应该保留权限控制和人工审核。
可以这样组织异步任务
下面是一个示意性的任务清单，用于表达异步编码代理的组织方式。它不是 Kiro Crew 的固定配置格式；实际字段和启动命令应以项目仓库中的文档为准。即使采用其他编排工具，这种拆分方式也可以直接迁移。
将内容保存为 crew-tasks.yaml，再由你的任务调度器或脚本读取：
workspace: payments-service
repository: ./payments-service
policies:
allow_read_logs: true
allow_write_code: false
require_approval_for_merge: true
tasks:
- id: incident-investigation
agent: investigator
prompt: >-
调查 INC-1042。检查过去 24 小时的错误日志、最近 20 次提交和相关配置变更。
输出时间线、可能根因、证据文件以及建议的后续检查。
tools:
- git
- log-search
- id: ticket-triage
agent: triager
prompt: >-
读取未分配的支付工单，提取严重级别、受影响组件、复现步骤和重复工单。
只生成 triage-report.json，不修改业务代码。
tools:
- issue-tracker
- id: pr-monitor
agent: reviewer
prompt: >-
监控 PR #381 的构建状态和审查意见。发现失败时，整理失败步骤和相关日志，
只报告问题，不自动推送提交。
tools:
- git
- ci
可以先用一个简单的 shell 脚本检查任务文件，再把任务交给实际的代理运行器。这个脚本只做本地校验，不假设 Kiro Crew 的具体 CLI：
#!/usr/bin/env bash
set -euo pipefail
TASK_FILE="${1:-crew-tasks.yaml}"
if [[ ! -f "$TASK_FILE" ]]; then
printf 'task file not found: %s\n' "$TASK_FILE" >&2
exit 1
fi
if ! command -v yq >/dev/null 2>&1; then
printf 'yq is required to validate %s\n' "$TASK_FILE" >&2
exit 1
fi
count="$(yq '.tasks | length' "$TASK_FILE")"
if [[ "$count" -eq 0 ]]; then
printf 'no tasks defined\n' >&2
exit 1
fi
yq -r '.tasks[] | [.id, .agent] | @tsv' "$TASK_FILE" |
while IFS=$'\t' read -r task_id agent; do
printf 'ready: task=%s agent=%s\n' "$task_id" "$agent"
done
运行方式：
chmod +x validate-crew-tasks.sh
./validate-crew-tasks.sh crew-tasks.yaml
在真实环境中，可以把脚本最后的输出接入 Kiro Crew 或内部调度器，并为每个任务生成独立工作目录、分支和结果目录。这样即使一个代理失败，也不会阻塞其他任务。
采用时先建立控制面
引入异步编码代理时，建议从只读任务开始。事故信息汇总、工单分类、依赖扫描和 PR 状态报告都能带来收益，同时不会直接改变生产代码。
逐步扩大权限时，可以采用以下检查清单：
- 任务是否有明确的完成条件，而不是“把问题处理好”。
- 代理是否能访问完成任务所需的最小数据集。
- 输出是否包含修改列表、命令结果、日志位置和不确定性说明。
- 代码修改是否进入隔离分支，并经过测试和人工审查。
- 任务是否设置超时、重试次数和费用上限。
- 失败结果是否能通知责任人，而不是静默停滞。
Kiro Crew 的意义在于提供一种面向异步协作的编码代理工作空间。它最适合处理可拆分、可观察、可以延后审阅的工程任务。团队真正需要设计的，不只是如何启动更多代理，还包括任务边界、权限、证据和交付流程。把这些控制面补齐后，代理才会从聊天窗口中的助手，变成开发团队可以管理的后台执行者。