模型是支点，
harness 才是杠杆
Kiro 把 agent 主循环替你写好了，循环之外那一圈得你自己配。同一个模型，这一圈配得好不好，决定它是只能改几行的工具，还是能扛大型系统的开发者。但有一件事得先说清：Kiro 是两条产品线，IDE 和 CLI 功能并不对齐，本文每讲一个能力都标清属于哪条线。
同一个模型，
环境决定它的上限
把模型当一名刚入职的开发者认真带，那些一直搁着没做的事就能重新动起来；而模型本身的能力又确实是天花板。两面合起来：harness 是可调的杠杆，模型是固定的支点。支点换不了，能动手的只有杠杆。Kiro 把"配杠杆"这件事做得很成熟、很现成，除了 steering、hooks、skills 这些可配的原语，它还自带一个强默认范式：先写规格（spec），人审通过，再让 agent 照着实现。
一条贯穿全文的纪律：harness 会随时间失效。模型一升级，之前搭的脚手架可能反倒成了累赘。所以下文每介绍一层，都顺带想它的退役时机，这点留到结语。另一条只对 Kiro 成立的提醒：它迭代极快，版本之间行为会变，凡标注了具体行为（某个按钮在哪、某命令默认值多少）的地方，落地前用你当前版本号再确认一次。
这篇只讲「配 Kiro」
Kiro 提供的是已经实现好的 agent 主循环，你不需要自己写 loop。本文只讨论一件事：这个现成框架该怎么配。三类东西不要混：①模型给的（改不了，第〇层）、②你配的（本文主体）、③你从零建的（不在本文范围）。
选型与计费、上下文管理、知识与工具的搭建顺序、用 Spec 与 Subagent 编排、把验证独立出来。全是在 Kiro 里只配不建的东西。
还有 ①模型能力：这是给定的，改不了，只能绕开，算是 harness 的地基（第〇层）。
用 API 或 SDK 从零搭一个 agent，是另一套打法：自己写主循环、自己设计 prompt 缓存、自己实现 MCP server。
遇到此类内容本文只点到为止、标明「不在本文范围」，不展开。
五层，自下而上盖
第〇层：你绕不开的地基
这层不是搭出来的，是给定的，但要先认清它，因为它决定了 harness 能精简到什么程度。共享 这一层 IDE 和 CLI 基本一致，差异只在切换入口。
Kiro 的上下文窗口随模型而定，不是一个固定值。选哪个模型，这次会话能用多大的窗口也就定了。
| 模型 | 上下文窗口 | 适合 |
|---|---|---|
| Opus 4.8 / 4.7 / 4.6 | 100 万 token | 长上下文、长时编码、大库导航 |
| Sonnet 4.6 | 100 万 token | 日常编码与探索的性价比之选 |
| Opus 4.5 / Sonnet 4.5 / 4.0 / Haiku 4.5 | 20 万 token | 单任务、成本敏感场景 |
Opus 4.6 / Sonnet 4.6 的 1M 是 2026-03-24 才从 200K 升上来的，仅对 Pro / Pro+ / Power 付费层开放，且能力下发后需重启 IDE / CLI 才生效。所以"4.6 = 1M"文档上没错，但落到你的环境里，还卡着付费层和客户端版本这两道坎；若选了 4.6 却没看到 1M，先核对这两条。
窗口大不等于可以随便塞。context rot（上下文腐烂） 是这层最关键的概念：随着上下文增长，模型性能会下降，因为注意力被分散到更多 token 上，旧的、不相关的内容开始干扰当前任务。这是注意力机制的固有特性，不是某个工具的 bug。
看占用：CLI 用 /context show 看窗口被 context files / tools / responses / prompts 各占了多少；IDE 在面板里直接显示。状态栏的 context 进度条让你不用反复打断就一眼看见剩多少：
/compact 或开 subagent。context files 上限是模型窗口的 75%，超了自动丢弃。Kiro 能选的模型很多，所以选型这步得权衡一下。
Low / Medium / High / XHigh / Max（具体可选档随模型变）。IDE 在模型选择器右侧的 Effort 面板里调，显示成"Claude Opus 4.6 · Max"这种样子；CLI 用 /effort high 调，会持久化，还能在配置里给每个模型设默认 effort。官方明说：effort 越高，token 越多、花的 credit 越贵。经验：编码、长时任务把 effort 往高了调（XHigh 是平衡点），Max 留给真正困难的问题，不必盲目设到最高。单说配 harness，4.8 这一代最值得关注的是幻觉明显少了，这直接关系到验证那块要花多少力气。这一点 Kiro 官方自己也印证了：它在模型说明里点名 Claude Opus 4.8，说它"比前代少 4 倍概率放过生成代码里的缺陷"，并列为"最高可靠性"的选项。
精简的是返工次数，不是验证本身。生成不等于评估、由独立 agent 验收而非执行者自评，这套分工制衡不可删除（详见第四层）。模型变可靠，省的是"反复改"的成本，不是"要不要查"的判断。
Kiro 是 credit 倍率制：每个模型对应一个倍率，选用的模型越贵、推理投入越深，消耗的 credit 越多。理解这套机制，才能把成本用在关键处。
| 模型 | credit 倍率（约） | 含义 |
|---|---|---|
| Auto 路由器 | 基准 1.0x | 拿不准时让它选，帮你做贵/便宜的分配 |
| Claude Haiku | ≈ 0.4x | 简单查询、跑脚本、读日志 |
| Claude Sonnet 系 | ≈ 1.3x | 日常 agentic 主力：交互式开发、迭代、查询、调工具，性价比最均衡 |
| Claude Opus 系 | ≈ 2.2x | 编程主力：关键代码、复杂推理、回归代价高的改动 |
| 部分开放权重 | 低至 0.05x | 成本极敏感、可靠性要求不高的批量活 |
顺着这套机制有三条可直接应用：① 按角色给模型分工，Opus 系做编程主力（关键代码、复杂推理），Sonnet 做日常 agentic 主力（多数交互式开发都用它），Haiku 与开放权重做最廉价的轻量任务，拿不准交给 Auto；② effort 是成本的另一个变量，同一模型 Max 比 Low 明显更贵，简单任务别习惯性设 Max；③ 大任务拆开，调研用 Sonnet、写关键代码切到 Opus，而不是全程使用最强模型。
关于推理后端：官方只确认 Kiro 的推理跑在 AWS 区域（us-east-1、eu-central-1）、采用跨区推理，并未逐字写明"Amazon Bedrock"；对外就说"AWS 托管、跨区推理"，别把合理推断说成官方明示。
上下文：你唯一真正在管的资源
loop 是现成的，你管理的是输入哪些内容、何时清理，这一层基本就决定了 Kiro 能发挥到什么程度。注意 IDE、CLI、ACP 三种用法在这一层分歧很大：CLI 有一整套斜杠命令（/compact、/rewind、/tangent），IDE 是面板按钮和 # 引用，ACP 则是把 CLI 的能力经协议搬进第三方编辑器（下一节细说）。
模型完成一步操作后，你有多个选择，最顺手的是"继续"，但其他几个选项就是用来帮你管上下文质量的。
先厘清一件容易混的事。Kiro 有三种用法：IDE、CLI、ACP。ACP 不是第三个独立产品，而是 CLI 的一种模式：你跑 kiro-cli acp，底层还是 CLI 的 agent 内核，只是改用开放协议（JSON-RPC）对外通信，于是能在 JetBrains、Zed、Neovim 这些第三方编辑器的 AI 面板里调用 Kiro。所以 ACP 的能力基本是 CLI 的子集：终端专属的交互式命令（rewind 的 turn 选择器、tangent 的切换）拿不到，IDE 的 GUI 专属功能（checkpoint 面板、Spec 面板）更没有。
下面这张表把每个上下文动作，在三种模式下有没有、怎么用、什么时候用一次列清。其中有几个命名最容易误解（rewind 不回文件、clear 只清屏），表里标出：
| 动作 | IDE | CLI | ACP | 什么时候用 / 注意 |
|---|---|---|---|---|
| 继续同会话 | ✓ 面板 | ✓ 发消息 | ✓ session/prompt | 上下文还相关就继续，窗口里的内容都在起作用 |
| 压缩上下文 | ✓ Summarization | ✓ /compact | ✓* compaction | 会话堆满过时调试信息时，带指令手动压；别等自动 compact 在模型最钝时才触发 |
| 开全新对话（清空重来） | ✓ 新建 chat | ✓ /chat new | ✓ session/new | 开始全新任务用这个。CLI 别用 /clear，它只清屏、不清上下文，容易混淆 |
| 回退「对话」（fork） | ✗ 无 rewind | ✓ /rewind | ✗ | 想丢掉失败尝试、留住读文件成果。只回对话不回文件，磁盘改动还在 |
| 回退「代码+上下文」 | ✓ checkpoint Restore | △ 实验（影子 git） | ✗ 无 GUI | 文件被改乱要连代码一起退；rewind 管不了文件。checkpoint 不能替代 git |
| 支线探索 | ✗ | ✓ /tangent | ✗ | 探索旁支又不想污染主线；Ctrl+T 切换 |
| 切换模型 | ✓ 选择器 | ✓ /model | ✓ session/set_model | 按任务难度选，贵模型留给关键编码（见 0.4） |
| 切 agent 配置 | ✓ | ✓ /agent swap | ✓ session/set_mode | 换一套 agent 的工具集与默认模型 |
| 委派 Subagent | ✓ | ✓ 最多 4 并行 | ✓ _session/terminate | 下一步产生大量只需结论的输出，把中间噪音留在子上下文（见第三层） |
| 加文件到上下文 | ✓ # 引用 | ✓ @path / /context add | ✓* 经命令扩展 | 这次会话临时要参考某个文件 |
| 大库 / 海量文档检索 | — | ✓ /knowledge（实验） | — | 内容超约 10MB 或上千文件，按需检索、不占常驻上下文（见 1.7） |
| 图片输入 | ✓ | ✓ | ✓ image 能力 | 贴截图或设计稿让模型看 |
✓* = Kiro 对 ACP 的扩展能力，实验性，且要宿主编辑器实现 _kiro.dev/ 扩展才生效；不实现就降级成纯标准 ACP（只剩会话、模型、流式）。✗ 该模式没有此动作，— 官方未列为支持，△ 实验性、需手动开启。
IDE 这一侧整体没有斜杠命令，对应的是面板按钮：Summarization（对标 /compact）、checkpoint 面板的 Restore（回退代码+上下文）、Revert（只撤最近一个 turn 的改动）、以及 # 上下文引用。
compaction 的本质是有损压缩：接近窗口上限时，把整个对话总结成更精简的描述，模型在一个新的上下文里基于摘要继续。CLI 用 /compact 手动触发，上下文溢出时也会自动触发；两个可调项是默认保留最近 2 对消息、默认保留 2% 的上下文窗口，取更保守的那个。一个 Kiro 特有的细节：compact 之后是新建一条 session，不是原地压缩，原会话用 /chat resume 能找回。IDE 对应的是 Summarization 功能，逻辑一样。
第一个要注意的：自动 compact 触发那一刻，模型恰好因为 context rot 处在最不智能的状态，却要做最关键的"保留什么、丢弃什么"的决策。典型失败链路：一段很长的 debug 会话后触发自动 compact，摘要聚焦在调试上；接着你说"现在去修另一个文件那个警告"，但警告的细节已经被丢掉了。正确做法是主动管理：在你清楚下一步、模型状态还好时，提前手动 /compact。
CLI /clear 只清屏幕显示，不清已保存的对话上下文。官方文档对此写得很明确：只清显示，不清已保存的对话。常见误用是误以为 /clear 能开新对话，结果上下文并未清除。Kiro 里真正开新对话是 /chat new，需注意这一区别。
Kiro 在"回退"上有一个容易混淆的设计：它把"回退对话"和"回退文件"拆成了两个独立机制，无法用一个命令同时完成。
回的是「对话」
在某个早期 turn 处把会话 fork 成新分支，选择器里能看到每个 turn 的 prompt 预览和当时的上下文占用百分比。
但官方写得很清楚，它不回滚文件改动：磁盘上后续 turn 改过的文件原样留着，想把文件也退回去得靠版本控制。
回的是「代码 + 上下文」
每发一个 prompt 自动建 checkpoint，点 Restore 把代码库和 Kiro 上下文一起退回那个点。
CLI 也有 checkpoint，但是实验性功能，用影子 git 仓库实现，要手动开启（chat.enableCheckpoint true），且 session 结束就清理、不跨会话。
它只追踪 Kiro agent 自己用内建工具改的文件。你手动编辑的、formatter 跑的、MCP 工具或 bash 命令改的文件，它不追踪，Restore 时可能被一起覆盖丢失。所以官方反复强调：checkpoint 不能替代 git，务必配合版本控制用。
两个诉求两个工具：只想丢掉"试方案 A"这段对话噪音、保留读文件的成果，用 /rewind；方案 A 已经把文件改乱了，用 checkpoint Restore（或直接 git）把文件也退回去。
CLI 官方把"向对话提供上下文"明确分成四类，按"是否占用常驻 token"来选：
| 方式 | 占常驻上下文？ | 适合 |
|---|---|---|
| Agent Resources | 是，每次请求都占用 token | 跨 session 常驻的项目规则 |
| Skills（skill://） | 元数据常驻，正文按需加载 | 可复用的专业工作流 |
| Session Context（/context add） | 是，仅当前 session | 这次会话临时要参考的文件 |
| Knowledge Bases（/knowledge） | 否，只在被搜索时才占 | 大型代码库、海量文档 |
一条经验法则：新任务 = 新会话。刚实现完一个功能、接下来要写它的文档，就该考虑开新会话（CLI 用 /chat new，再说一遍，不是 /clear）。关联任务之间有权衡：复用上下文更快更省，模型不必重新读你刚改的文件；新建会话更干净，但要重新读相关文件、更慢更费 credit。决策规则：下一个任务若与当前上下文高度相关就继续，否则开新会话。
CLI /knowledge（实验性）可以把大文件、整个文档库、甚至整个代码库做成一个语义检索的知识库：它只在被检索命中时才占用上下文，平时不消耗 token。官方判断标准很明确：内容超过约 10MB 或上千文件，就不宜放入常驻上下文，改用 Knowledge Base。它是一个可选的持久语义索引层，大库场景下能省去大量"让 agent 逐个读取文件"的开销，代价是属于实验性功能、稳定性有限，以及超大库的索引性能瓶颈（见 2.3）。
知识与工具：施工图
这一层是全文核心框架。一个常被忽略的前提：harness 的重要性等于甚至超过模型本身，团队常盯着 benchmark，可实际跑起来，效果更多看你围着模型搭的这一圈生态。这一层有一个有利条件：Kiro 的 Steering / Skills / Hooks / MCP 大部分是 IDE 与 CLI 共享的，配置一次，两边都能用。
一个常见误解是 agent 找代码全靠实时遍历文件、没有索引。Kiro 不是这样，它是三种机制并存的混合体，这是最容易想当然搞错的地方：
值得强调：符号级、结构级的代码理解（在不少工具里要靠手动装 LSP 才有），Kiro 把它做进了产品（CLI 的 tree-sitter code 工具、IDE 的索引和 AST 编辑）。所以在 Kiro 里这不是一个"你要去搭"的脚手架，而是"理解它已经在那"的既有能力。
harness 的构建有顺序，每层建立在前一层之上，不宜跳跃。Kiro 的版本是 Steering → Hooks → Skills → Powers → 代码智能 → MCP → Subagents。每层带"常见错误"和"属于哪条线"：
.kiro/steering/，支持多种加载模式。原则：只放"广泛适用"的内容，过多会拖累性能。常见错误：把可复用的专业知识写进去（那类内容应放进 skill）。详见 2.4。.kiro/settings/mcp.json，并提供企业治理（MCP Registry）和一键安装链接。常见错误：基础配置尚未就绪就先接入 MCP。详见 2.7。核心约束：模型在大代码库里的能力上限，等于它找到正确 context 的能力。几个反复出现的实践：Steering 保持精简且分模式（别都设成 always 加载）；按子目录约束 test 和 lint；用 .gitignore 和 protected paths 排除生成文件；结构不清晰时让 Kiro 生成 codebase map（IDE 用 #repository，存量库还能先生成 structure.md / tech.md / product.md）；让模型用 tree-sitter 符号搜索而非纯字符串 grep；大库用 Knowledge Base 而非全部载入。
Kiro 的 embedding 索引在超大代码库上目前有性能瓶颈。社区报告过五万文件级、带多年 git 历史的库索引较难完成、CPU 占用偏高的情况，相关反馈在官方 GitHub 上作为待改进的 feature request 跟踪(截至发稿仍在处理中)。中小型库(几千文件)索引表现正常，超大型单体库可以预期"索引较慢、宜配合 Knowledge Base 和分模块"，按规模选择策略即可。
Steering 文件放在 .kiro/steering/（工作区级）或 ~/.kiro/steering/（全局级），冲突时工作区优先。每个 .md 自动加载，按领域拆分。IDE 点 "Generate Steering Docs" 会生成 product / tech / structure 三个基础文件，Kiro 对项目的基本认识就建在这上面。steering 比一份从头到尾全量加载的项目说明灵活，灵活就灵活在这四种 inclusion 模式上（写在文件最开头的 YAML front-matter 里）：
| 模式 | 语法 | 行为 |
|---|---|---|
| always（默认） | 省略即此 | 每次交互都加载 |
| fileMatch | inclusion: fileMatch + fileMatchPattern | 只在处理匹配该 glob 的文件时加载 |
| auto | inclusion: auto + 必填 name/description | 靠 description 语义匹配请求自动加载，机制和 Skills 一样 |
| manual | inclusion: manual | 不自动加载，聊天里用 #文件名 显式引用 |
fileMatch 是关键：Kiro 的 steering 文件是扁平的（集中在一个目录下），靠 inclusion 模式而非文件所在目录来决定何时加载。想要"某个子目录专属规则"，做法是写一条 fileMatch glob 去匹配那批文件，而非把规则文件放进该子目录。补充：用 #[[file:相对路径]] 可把活的工作区文件链进 steering（有反馈说该语法在 CLI 偶尔不生效、IDE 正常）；兼容 AGENTS.md 但它不支持 inclusion 模式、永远全量加载；CLI 用 custom agent 时 steering 不会自动加载，必须在 agent 配置的 resources 字段显式加。
Kiro 的 Skills 用的就是开放 Agent Skills 标准，因此社区中成熟的 skill 经验和现成的 skill 包，这里基本可直接复用。结构完全一致：
位置：工作区 .kiro/skills/，全局 ~/.kiro/skills/，同名工作区优先。name（须与文件夹同名）和 description（Kiro 用于语义匹配）都是必填。渐进式披露也一样：启动只加载 name+description，请求匹配才加载完整 SKILL.md。那几条最佳实践直接适用：不堆砌废话、建一个 Gotchas 章节记录失败点、善用文件系统做渐进式披露、description 写触发条件而非摘要。
Kiro 激活 skill 时，是把 SKILL.md 正文当原始文本注入，不带 skill 所在目录路径。结果是：放在全局目录（~/.kiro/skills/）的 skill，其 SKILL.md 里写的相对引用（references/xxx.md）可能解析不到；工作区内的 skill 正常(这是社区在官方 GitHub 上跟踪的一个开放 issue)。所以在这一点修复前，全局 skill 上"瘦 SKILL.md + references 按需加载"这套模式不太稳，简单的做法是把 skill 放工作区，或把内容尽量写进 SKILL.md 正文。
这一层 IDE 和 CLI 分歧最大，必须分开讲。
事件丰富，含文件系统 & spec
放在 .kiro/hooks/，每个是一个 *.kiro.hook JSON 文件，可提交进 git 团队共享。
- Prompt Submit / Agent Stop
- Pre / Post Tool Use（工具调用前后，可阻断）
- File Create / Save / Delete（文件系统事件）
- Pre / Post Task Execution（spec 任务前后）
- Manual Trigger
两种动作：Ask Kiro（发 prompt，起一轮新 loop、消耗 credit）和 Run Command（跑 shell，不耗 credit、更快，退出码非 0 可在 Pre Tool Use 阶段阻断）。
另一套，更精简
写在 agent JSON 配置的 hooks 字段里，事件只有：
agentSpawn（agent 初始化）userPromptSubmitpreToolUse/postToolUsestop
没有文件事件、也没有 spec 任务事件（那些是 IDE 独有）。
一个缺口：会话结束、压缩前、子 agent 结束这类生命周期事件，两条线目前都没有直接对应。
MCP 接入配置在 .kiro/settings/mcp.json（工作区级）或用户级，两者合并、工作区优先。标准 mcpServers 格式，本地 server 用 command/args/env，远程用 url/headers。Kiro 在这块的几样东西：自动批准更细（autoApprove / disabledTools / disabled）；MCP Registry（CLI 组织集中下发 server，registry 默认值可本地逐键覆盖，适合企业管控）；一键安装链接（"Add to Kiro" 放进 README）。一点注意：Web Kiro Web 的 sandbox 目前只支持本地 stdio server，不支持远程 server。
降本机制：Kiro 有 Tool Search，工具多时不预加载全部工具定义，而是运行时按需搜索拉取。CLI 默认关闭，触发阈值是占上下文 5% 或 5 万 token，建议 5 个以上 MCP server 时打开。Powers 则把"MCP 工具 + 知识 + 工作流"打成一个包，按上下文动态激活：MCP 给工具，Skills 给操作知识，Powers 给"工具加知识"的合订本。
贯穿这一层有一条原则：工具和指令都不是越多越好。工具的 schema 和过长的指令都会挤占模型用于推理的空间。一个简短的 steering、一个聚焦的 skill，往往优于堆砌冗余配置。Kiro 因为按 credit 计费，这条还有直接的成本含义：每多一份常驻上下文，每次请求都在为它付费。默认倾向应是"先用最少的配置验证模型能否胜任，再根据实际遇到的问题逐步增加"。这条暗线会在结语"边搭边砍"中收束。
编排：计划该交给谁
到这一层，问题变成：一个任务，是让模型自行逐回合在脑子里记着整个计划，还是把计划交到别处持有。编排的核心就一个问题：计划（plan）在谁手中。最朴素的做法是让模型把计划记在上下文里逐回合走，但任务一大，计划就容易在压缩和漂移中走样。
Kiro 给出的答案与众不同：把 plan 落盘成 spec 文件，经人工审核，再让 agent 照着实现。plan 不再由模型在上下文里逐回合记忆，而是变成磁盘上可版本控制、可团队 review 的三个 markdown 文件。这就是 Kiro 的招牌能力 Spec-driven development，它是 IDE 独占的（CLI 没有内置 spec，只有一个轻量的 Plan agent，见 3.7）。这样换来的好处是看得懂、审得了、追得到：动手写代码前先在文档层面想清楚、人确认过，特别适合复杂、回归代价高、需要团队对齐的开发。
每个 spec 生成三个文件，放在 .kiro/specs/<feature>/ 下，一个 feature 一个目录：
WHEN [条件] THE SYSTEM SHALL [行为]）。清晰、可测试、可追溯。两种工作流变体，外加一个快捷模式：Requirements-First（变体；行为清楚、架构灵活）· Design-First（变体；已有架构或要满足延迟/合规等硬性非功能需求）· Quick Plan（一种独立的会话模式，严格说不算"变体"：一次性自动生成全部三个文件、跳过阶段间审批，适合你信任 Kiro 输出的成熟 feature）。默认是带审批关卡的：Requirements →（人审）→ Design →（人审）→ Tasks，进 design 前还有个 Analyze Requirements 步骤帮你查需求里的矛盾、歧义、缺口。注意分工：spec 只管单个 feature 的计划，项目级常驻上下文走 steering，两者分开。
tasks.md 有专门的执行界面，实时显示每个任务状态。Run all Tasks：Kiro 自动构建任务依赖图，把无依赖的任务分成"波次（waves）"，第一波所有无依赖任务并发跑，第二波跑依赖被第一波满足的，以此类推。波次之间串行，波次内并发。Sync Files：触发后让 Kiro 扫描代码库、自动标记已完成的任务，应对"你或队友在别的会话已经做了一部分"。除了一次跑完，也可以逐个任务执行(点任务上方的 Start Task)，跑完单独 review 再进下一个，适合想"一个任务一审"的人。
结构化三文档流程
给复杂 feature、团队协作、回归代价高的改动用。想清楚了、要落地、要留痕、要团队对齐时选它。
即兴的对话式开发
快速探索、做原型、目标还不明确时用。Spec 是 Kiro 的"强默认"取向，但不是硬约束，Vibe 随时可用。
Subagent 是 IDE 和 CLI 都有的能力，只是控制粒度不同。它和"spec 任务的波次并行"（3.3）是两回事：后者是任务编排层的并行，前者是开一个带独立上下文窗口的子 agent 去单独跑一段。共同点是子 agent 有自己的全新窗口，主 agent 决定是否委派，干完把结果汇总回主 agent，中间噪音留在子上下文里。两条线的差异：
~/.kiro/agents（全局）或 .kiro/agents（项目）放 .md 文件定义自定义 subagent（YAML frontmatter 配 name / description / tools / model），它们还会以斜杠命令形式出现。注意 IDE 的 subagent 不能访问 Spec，Hooks 也不在其中触发。subagent 工具，控制更细。CLI 内置 subagent 工具（早期实验性的 delegate 已弃用、被它取代），比 IDE 多暴露几个控制：最多 4 个并行（硬上限，规划并行度时需记住）；可点名用自定义 agent（"用 backend agent 去重构……"，编排 agent 的 tools 里必须含 subagent 才能委派，干完用内置 summary 工具汇总）；Ctrl+G 打开执行监视器看每个子 agent 实时状态；权限上有 availableAgents（限制能派哪些，支持 glob）、trustedAgents（免批准运行）。适用场景（两条线通用）：研究密集型任务（读几十个文件后返回摘要）、多个彼此独立的子任务（并行做）、需要全新视角（不继承主会话假设）、提交前的独立审查。判断心智："我需要这些工具输出本身，还是只需要结论？"只需结论就委派。
用一句话框定 Kiro 编排能力的边界，避免预期错位。Kiro 的编排是 agent 驱动、自然语言描述的，plan 的持有者始终是 LLM 主 agent，而非一段确定性脚本。两个具体表现：
max_iterations，上限 10 轮）同样是你用自然语言描述意图、agent 决定怎么做，没有可手写的脚本或 schema。所以 Kiro 的强项是：用 spec 把单个 feature 的计划落盘审清楚，再用子 agent 做有限的并行委派和对抗式审查。理解这条边界，配置时就不会期待它去做脚本级、可逐行重跑的大规模确定性编排。
没有 spec 时的轻量补偿
CLI 1.23 起内置（Shift+Tab 或 /plan）：结构化提问 → 只读探索代码库 → 产出任务分解 → 把批准的 plan 交接给执行 agent。但产出是临时 plan，不是落盘的 spec 三件套，别混为一谈。
是示例 pattern，不是开箱功能
Kiro 没有一个叫"Agent Teams"的内置产品。官方示例仓演示过用 subagent + steering + prompts + hooks 拼出多 agent 团队（architect 分派任务给 coder/ops，再交 reviewer 和 security-reviewer），但那是示例 pattern，要自己拼。
仅 Pro/Pro+/Power 订阅，默认关闭。这是更接近"前沿 agent"的另一套形态，不是 CLI 子 agent：在隔离 sandbox 里 clone 仓库，最多 10 个任务并发，内部协调几个专职子 agent（调研规划 / 写代码 / 验证），跨任务跨 repo 有持久记忆，能从 PR review 反馈里学团队规范，可从 GitHub issue 用 /kiro 评论分派任务。这个模式下你不能选模型（agent 自动选）。
验证：执行者不应评判自己的产出
现在写代码已经很便宜了，瓶颈跟着就挪到了验证上。这是搭脚手架时最容易被忽略、却最关键的一层。
核心只有一句：让执行任务的 agent 评价自己的产出，它几乎总会自信地给好评，即便质量平庸，在没有二元通过/失败标准的任务上尤其如此。这跟让开发者 review 自己的代码没两样。解法是把生成和评估分开，像传统团队里开发和 QA 是不同的人。一个关键工程现实：把一个独立的评审 agent 调教得严格苛刻，比让执行 agent 学会自我批评容易得多。code review、QA 独立、审计分离，人类世界早就在用分工制衡。
Kiro 把这套分工做进了产品，你不用从零搭：
Kiro IDE 默认 Autopilot，agent 会端到端自主干活，跨文件改代码、跑命令、做架构决策，中途不逐步停下来问你。这是 Kiro 有意的取向:优先让 agent 连贯推进，把控制点放在事后,你看全部 diff、整体回滚、或执行中随时打断。如果你更习惯"逐步确认"，切到 Supervised 即可(每个含文件编辑的回合结束后停下等你批准，改动按 hunk 逐块 accept/reject)。两种节奏没有优劣，按任务和个人习惯选。
这是 Kiro 官方文档里专门强调的一点：Supervised 不是沙箱、不是隔离边界、不是访问控制，两种模式下 agent 的底层权限完全一样。它只决定"改动落盘前是否向你展示 diff"。真正的安全边界是另一套机制：protected paths、trusted commands、workspace isolation、credential scoping，其中"写受保护路径需要批准"在两种模式下都强制生效。CLI 侧的权限模型不同：用 /tools trust / untrust / trust-all 控制哪些工具免确认。
所以配验证要把两件事分开想：Autopilot / Supervised 管的是 review 节奏（要不要逐块看），protected paths / trusted commands 管的才是安全（能不能动）。不要把 Supervised 当作安全边界。
Kiro 还有一个较为特别的内置验证能力：基于属性的测试（Property-Based Testing）。它从 EARS 格式的 requirements 里自动抽取"属性"，生成成百上千个随机用例进行测试，用 shrinking 技术找出最小反例（类似于内置的红队）。测试失败时，Kiro 会给你"改实现 / 改测试 / 改需求"三个选项。这正好跟 spec 的可追溯性接上了：需求 → 任务 → 属性测试串成一条链。这一步，Kiro 把"形式化需求"接到了"自动验证"上；默认不开，可选启用。
把 agent 当新员工 onboard
把前面四层组合应用于一个真实战役，全程只用 Kiro 的现成能力，没有任何自建 agent。这里讲的是方法论；方法论跟用什么工具没关系，下面把它逐条对到 Kiro 的机制上，并诚实标出现实约束。大型遗留代码库不能一次性交给 agent，正确做法是一个五步闭环：
每次任务结束都把经验写回去，下一轮 agent 起点更高。你不会让新人第一天就面对几十万行代码，对 agent 也一样。
把项目的常识、约定、踩坑沉淀进 steering，并尽量做成独立于代码分支的工程产物维护（context 若被分支隔离，各分支上的 agent 就成了"不同的人"）。海量测试日志、文档、历史代码用 Knowledge Base 做语义索引，按需检索而非全部载入。
用 Skills 承载专业工作流，遵循"指向中心知识库而不复制内容"保持轻量；尤其建一个 debugging skill，把"调查 bug 必须先做根因分析、杜绝盲目试错"设成硬约束。
大改动先用 spec 把计划想清楚、人审过再动手（审批关卡正是"在几十万行里别盲目下手"的结构性保障）；需要并行探索时用 subagent（记住 4 个的上限）。
用 review loop / 独立 reviewer 把关，关键模块用 protected paths 锁住，别让 Autopilot 在没防护的情况下去动核心代码。
Kiro 的 embedding 索引在超大代码库（几万文件级、带多年 git 历史）上目前有性能瓶颈，索引可能较慢甚至难以完成。所以在超大型单体库上，别假设 #codebase 能无差别覆盖全库，配合 Knowledge Base + 分模块 scope 来用更稳妥。这一点和"把 agent 当新员工、切片输入"的方法论其实一致：本来就不该一次性载入整个库。
四点要点（把四层串起来的总结）：scope 隔离是前提，大库必须切片输入、逐步扩展；debugging skill 必须设为硬约束，盲目改一行可能引发连锁故障；context 尽量独立于代码分支，否则各分支上的 agent 等同于不同个体；大库别迷信全量索引，需要时启用 Knowledge Base。这不是开箱即用的万能方案，需要有人持续维护 context 层、渐进式推进。
边搭边砍：harness 的半衰期
harness 不是一次搭好就一劳永逸，它有半衰期。模型一旦增强，就该主动删减脚手架。能删多少，取决于模型多强。这条原则站得住脚：harness 的每个零件都押了一个"模型能做到什么"的假设，而假设会过期。一个为旧模型的某种缺陷打的补丁，等模型升级、那个缺陷消失之后，补丁本身就成了纯负担，反而拖慢性能。所以正确的心态不是"如何让 Kiro 更强"，而是"我可以停止做什么"。
- 验证 harness：模型变可靠，review loop 轮次、Supervised 逐块审查都可适当放松
- spec 审批关卡密度：简单成熟的 feature 用 Quick Plan 跳过关卡
- 为某个版本调的具体配置：Kiro 迭代极快，这些会过期
- 生成与评估分离：没有独立 evaluator，边界任务的 bug 仍会被遗漏
- 需求分析与质量把关：复杂高风险的仍走人审
- 上下文纪律：steering 精简、context 独立于分支
三个具体落点：① 模型变可靠，验证脚手架就该变薄——但分工制衡本身不能删；② spec 的审批关卡按模型能力调档，但别整个关掉；③ Kiro 自己迭代极快，你为某个版本调的配置也会过期——把配置当成需要持续维护的对象、定期审查一遍。
最后归结为一句：清晰区分可删减的部分（脚手架）与不可删减的部分（上下文纪律、分工验证）。有价值的 harness 组合空间不会随模型进步而缩小，只会移动位置；最好的 agent 框架，是你能删掉的那个。建议每隔 3 到 6 个月、或每次大版本模型发布后感到性能停滞时，做一次完整的 harness 审计，主动删掉不再必要的假设。