Kiro Workflows：多 Agent 编排的声明式工作流框架

什么是 Kiro Workflows？

Kiro Workflows 是 Kiro 的一个新功能，允许用户通过一种结构化的声明式语言（JSON 或 YAML）编排多个 Agent。Workflow 将工作组织成一张图，由有序的 Agent 步骤序列、并行分支和带条件停止的循环组成。

Kiro Runtime 在后台执行工作流，每个步骤在独立的会话中运行。这意味着审查 Agent 可以在不继承编写代码的 Agent 的推理过程的情况下评估工作。每个步骤通过输出引用将结果向前传递。循环重复直到满足条件（例如获得批准裁决），整个运行过程会将其进度报告回主聊天会话，这样就可以让工作继续、回答偶发问题或在运行过程中提供指导。

简而言之，普通的聊天会话迫使我们引导模型经历每个阶段，一遍又一遍地提醒它早期的决策，而工作流则将这个过程捕获为可复用的配方，让运行时来执行——把"实现……，现在审查……，现在修复……"变成一个可以完善并再次运行的单一过程。

一个 Workflow schema 大致如下：

{
    "name": "",
    "description": "",
    "inputs": {
        # Values that are going to be interpolated when referenced. 
    },
    "steps": [
        {
            "type": "",
            "id": "",
            "steps": [
                {
                    "type": "step",
                    "id": "",
                    "agent": "",
                    "prompt": "",
                    "artifacts:" {
                        # Agent report as a file
                    }
                },
            ]
        }
    ]
}

Kiro workflow 中有五种节点类型：

step — 使用 prompt 运行单个 Agent 会话。工作的基本单元。

sequence — 按顺序逐一运行其子节点。

parallel — 并发运行多个分支，带有 join 策略（all、allSettled 或 any）。

repeat — 重复运行其子节点直到满足停止条件（或达到 maxIterations），onMaxIterations 行为可以是 abort、continue 或 pause。

watch — 轮询外部系统（不调用 LLM），例如 GitHub PR（github-pr）或自定义命令处理器。

一个小术语说明：只有 step 真正运行 Agent。其他四种都是结构或控制流节点——sequence、parallel 和 repeat 组织其他节点，watch 观察外部系统而不调用模型。所以如果问题具体是"有多少种 Agent 步骤类型"，答案是 1 种（step）；如果是"workflow 图由多少种节点类型构成"，答案是 5 种。

在 Kiro workflow 中，inputs 是模板变量，不是类型化 schema。例如，在这个项目中 inputs 是一个 map，每个 key 是变量名，value 是类型提示字符串——人类可读的描述，不是强制执行的类型：

"inputs": {
  "profile": "AWS SSO profile for credentialed phases (default: Walsen)",
  "run_deploy": "whether to run `just deploy` (default: false)"
}

"whether to run ... (default: false)" 这个字符串是给阅读者的文档；运行时不会将其转换为布尔值或进行校验。在启动时，无论传入什么 inputs，都会代入到步骤 prompt 中出现 {{run_deploy}}、{{profile}} 等位置。

所以实际情况是：

在定义时 — 类型提示可以说任何内容："prompt"、"file"、"string"、"whether to..."、路径描述、分支名。这些是打包配方中会看到的约定（例如 goal: "prompt"，prd_path: "file"，max_iterations: ...），但它们是描述性标签，不是经过校验的类型系统。

在启动时 — 实际传入的值都是字符串。通过 workflowPath 配合 inputs 启动时，每个值都是字符串（这就是为什么 run_deploy 传入的是字符串 "false"，而不是 JSON 布尔值）。运行时将它们作为文本代入 prompt。

一切都是文本替换。运行时没有枚举校验、没有 required/optional 强制、没有数字解析。如果某个 input 应该表现得像布尔值或选项，这个逻辑在步骤 prompt 中实现——例如部署步骤读取 {{run_deploy}}，prompt 告诉 Agent"如果不是 true，就不要部署"。Agent 来解释它，运行时只负责传递字符串。

Inputs 代表什么的常见约定（不是强制类型，只是通常的使用方式）：

自由格式的 prompt 文本 — 任务描述（goal、prompt、research_directions）。

文件或目录路径 — 步骤读取/写入的绝对路径（design_path、prd_path、report_path、workdir、spec_dir、worktree_path）。

Git 引用 — 分支或主线名称（branch、worktree_branch、mainline_branch）。

类似 Flag 的字符串 — 是/否或 prompt 解释的选项（run_deploy）。

短标量 — profile 名称、计数、标识符（profile、max_iterations）。

两个需要注意的地方，以免产生误导：

步骤输出与 inputs 是不同的东西。除了启动时的 inputs，步骤之间还通过 {{step_id.output}} 和 {{previous.output}} 相互引用，通过 {{artifacts.<name>}} 引用产物。这些没有在 inputs 中声明——它们是在运行时产生的。校验器会检查这些结构引用（被引用的步骤是否在更早运行并产生输出），但不会校验 inputs 的类型提示。

对于在启动时接收 inputs 的配方形式（workflowPath 或 bundled:///agent:// 配方），保持值简短——路径、分支、一行字符串。长任务文本放在配方的步骤 prompt 中（创建 workflow 时嵌入），不要作为启动 input 传入。

所以直接回答：Kiro 没有强制固定的 input 类型集合——inputs 是带有描述性类型提示的命名字符串变量，"类型"实际上只是一种约定（prompt / path / reference / flag / scalar），步骤 prompt 赋予它们意义。

Kiro 中可用的注册 Agent（可以在步骤节点的 agent 字段中命名的 Agent）是以下九个内置的 wf-*/reviewer Agent：

wf-coder — 读取文件、编辑代码、运行测试、执行提交；通用实现。

wf-planner — 调查代码库并生成有序的实现计划。

wf-design — 为功能编写需求和技术设计文档。

wf-design-reviewer — 审查技术设计，查找歧义、漏洞和未验证的假设；机械裁决。

semantic_reviewer — 本地 diff 或 PR 的行为和叙事代码审查；撰写审查意见和裁决。

wf-review-aggregator — 将多个审查输出合并为单一综合裁决。

wf-auto-researcher — 自主研究子 Agent：运行实验、基准测试、提交改进。

wf-pr-submitter — 从分支发起 Pull Request 并记录 PR 元数据。

wf-pr-responder — 回应 PR 审查评论和 CI 反馈。

还有一个 wf-workflow-creator，设计/保存 workflow 定义，但通常不会把它放在步骤中。

为了一个演讲，我构建了一个小项目：一个部署在 AWS Amplify 上的在线数独，后端使用 Lambda 和 DynamoDB。

对于这个项目，我有 2 个需求：

一个测试工作流，包含多个 Agent 识别问题并就地修复。完成后部署修复。

实现一个新功能，让用户在开始游戏前选择难度等级，完成后部署新功能。部署将是条件性的，使用功能开关。

对于想看这个项目的人，它在这里。

这是工作流的实际运行演示：https://youtu.be/zqEOtFmRC_I。对于英语用户，视频是西班牙语的，但可以开启英文字幕。

就像 KiroCrew 刚推出时一样，Kiro Workflows 也有其缺陷：很难理解如何启用它们或如何运行它们，文档也不够清晰。虽然实际上只需要告诉 Kiro"运行工作流 ...."就这么简单。

我听到评论说它消耗大量 tokens，但老实说我没有遇到这种情况：测试工作流消耗不超过 70 tokens，实现工作流大约 150 tokens，所以我认为这是非常合理的。显然我也没有以最正确的方式使用它，只是凭直觉和 Kiro 带我走到的程度。

这是一个具有巨大潜力的功能：它让你能够以多种方式运行流程、将它们纳入自动化、动态生成它们，以及更多。

我认为我们需要等待、使用它们，并向 Kiro 团队发送正确的反馈，以便它围绕市场的真实需求来塑造。

Workflows（概述） — 概念：Agent 步骤、序列、循环和并行分支的图；每个步骤在独立的全新会话中运行。

创作 Workflows — 配方是如何创建的（在聊天中描述预期结果，Kiro 生成图，保存为配方以便复用）。这里涵盖节点类型、{{...}} 引用和 inputs。

Workflow 示例 — 打包配方的形态（以及一个说明：打包配方集合可能因客户端版本而异）。

运行和管理 Workflows — 后台执行、检查点、节点状态/输出/产物、循环（repeat）进度、watch 游标、暂停/恢复。

支持参考资料：

Introducing Kiro workflows（官方博客，概念性）

Introducing Workflows in Kiro Web（更新日志）

从 https://kiro.dev/docs/workflows/ 开始，其下是创作页面——这是我们讨论的定义（节点类型、作为 {{...}} 模板变量的 inputs、{{step_id.output}} 引用、wf-* 步骤 Agent）最接近 schema 参考的地方。