AI Research 技术调研

Kiro (AWS)：闭源 spec-driven agentic IDE/CLI，无公开应用源码，仅 Powers 集成包内容开源

36分钟阅读

Kiro (AWS)

一句话定位

Kiro 是 AWS 旗下基于 VS Code/Code-OSS 的闭源 spec-driven agentic IDE（另有 CLI/Web/Mobile 多端），2025 年 7 月 14 日发布，团队与代码库均与 Amazon Q Developer 独立；应用本体无公开源码，唯一可读的一手材料是官方文档树（kiro.dev/docs）与工程博客（kiro.dev/blog），后者罕见地公开了具体的 token/延迟/错误率基准数字。

核心架构总览（目录结构关键路径 + 引用的 commit）

  • 无可分析的源码仓库。GitHub org kirodotdev（域名已核实归属 kiro.dev/AWS）下 4 个仓库：
    • kirodotdev/Kiro — 名字具误导性，树内实为 .github/（issue 分诊自动化 workflow）、.kiro/specs/github-issue-automation/、assets/、docs/、scripts/、README.md，不含 Electron/Code-OSS 应用代码。
    • kirodotdev/powers — 真实开源内容仓库（326 stars，309 commits，抓取时点），含约 25 个 POWER.md + mcp.json 集成包（aws-mcp、aws-amplify、stripe、terraform、datadog、dynatrace、neon、postman、zapier 等）。是 markdown 内容包而非应用代码，但确为 Powers 生态实际分发的内容。
    • kirodotdev/spirit-of-kiro — Vue demo 游戏，与 harness 架构无关。
    • kirodotdev/.github — org 元信息，fork 自 amzn/.github。
  • 产品矩阵（抓取时点）：Kiro IDE（VS Code/Code-OSS fork，桌面端）、Kiro CLI（kiro-cli，终端）、Kiro Web（浏览器，接 GitHub/GitLab）、Kiro autonomous agent（独立异步/后台 agent 产品，2025-12 上线，架构与 IDE/CLI 迥异，见下）、Kiro Mobile（iOS，2026-06 上线）。
  • CLI 安装为 curl -fsSL https://cli.kiro.dev/install | bash，滚动发布，文档未披露任何可锁定的版本号或 commit SHA。
  • 抓取日期：2026-07-07，全部经 CloakBrowser（CLOAKBROWSER_PROXY=http://127.0.0.1:7897）读取 kiro.dev 官方文档与博客原文，未使用任何二手摘要。

Agent Loop（主循环 / 何时继续何时停）

无公开源码级循环实现。文档层面可确认：

  • 两种顶层交互模式：Autopilot（默认）——多步执行、立即写文件、无逐步审批，用户可事后中断或回退；Supervised——每个含文件编辑的 turn 结束后暂停，展示 hunk 级 diff 供接受/拒绝后才继续。（/docs/chat/autopilot/、/docs/privacy-and-security/#autopilot-versus-supervised-mode）
  • 官方博客明确承认的设计取舍（/blog/run-all-tasks/）：团队刻意将”一键跑完所有 spec task”的自动连续执行功能延迟约 6 个月上线，原因是”在没有验证基础设施前，无监督的多步执行被判定不安全（agent 会出错，用户回退成本更高）”。
  • Spec 任务执行采用依赖图”wave”调度模型（/docs/specs/）：Kiro 对 tasks.md 构建 DAG，Wave 1 = 无依赖任务（并发执行），Wave 2 = 依赖被 Wave 1 满足的任务，依此类推；wave 间顺序执行，wave 内任务并发——这是文档中对”批处理/spec 模式下循环何时继续”最接近的描述。
  • Hooks 提供循环内的可编程闸门：PreToolUse、UserPromptSubmit、PreTaskExec 三个 trigger 可阻断执行（command action 退出码 2 = 阻断并将 STDERR 作为反馈返回给 agent）；PostToolUse/PostFileSave 等仅为事后通知，不可阻断。（/docs/hooks/）
  • 上下文压力会触发一个隐式循环事件：达到模型上下文 80% 时自动摘要对话（见记忆章节）。
  • 未公开：单轮 agent turn 内部的 ReAct 式工具调用循环、重试逻辑、单轮停止启发式——这是官方未披露的实现细节，标注为”未找到”。

记忆与上下文管理（压缩、长期记忆、会话持久化）

  • 上下文阈值自动摘要：达到模型上下文上限 80% 时自动摘要对话，chat 面板显示上下文占用表；摘要算法/prompt 未公开。（/docs/chat/summarization/）
  • Checkpoint 机制：每条 prompt 创建一个 checkpoint；恢复某个 checkpoint 会同时回滚文件系统状态（通过逐次文件修改工具的快照）与**“context 追加内容”**（聊天轮次）。与仅撤销最近一轮文件改动的”Revert”不同。Kiro 不追踪其自身文件修改工具之外的改动（手动编辑、外部格式化器、MCP 工具改动、bash 命令改动对 checkpoint 快照不可见）。（/docs/chat/checkpoints/）
  • Steering 文件 = 持久化、按需加载的项目级记忆，非会话级聊天记忆。作用域：workspace（.kiro/steering/）vs. global（~/.kiro/steering/），同名时 workspace 覆盖 global。四种加载模式（YAML frontmatter 控制）：
    • always（默认）——每次交互加载
    • fileMatch + fileMatchPattern（glob 或 glob 数组）——仅当操作匹配文件时加载
    • manual——仅通过显式 #steering-file-name 提及或 slash 命令加载
    • auto + 必填 name/description——请求匹配描述时加载（与 Skills 渐进式披露同机制）
    • 亦支持开放标准 AGENTS.md（workspace 根目录或 ~/.kiro/steering/），始终加载，无 inclusion-mode frontmatter。
    • 支持 #[[file:<relative_path>]] 语法做实时文件引用，保持 steering 内容与实际仓库文件同步。（/docs/steering/）
  • Kiro autonomous agent（独立产品）具备真正的跨会话持久记忆：“非会话制……在你的工作中维持上下文”，会记住 PR review 反馈并自动应用到后续任务，为团队部署构建跨 specs/PRs/Slack/Jira/Confluence 的”统一团队记忆”。（/blog/introducing-kiro-autonomous-agent/）这与 IDE/CLI 的按会话聊天模型架构不同。
  • ACP 会话持久化（仅 CLI）：会话写入 ~/.kiro/sessions/cli/<session-id>.json（元数据/状态）与 <session-id>.jsonl（事件日志/对话历史）。支持通过 ACP 协议按 ID session/load。（/docs/cli/acp/）
  • 子 agent 拥有独立隔离的上下文窗口，明确目的是防止主 agent 上下文污染（“context rot”）——文档将其列为使批处理任务执行足够安全上线的三大支柱之一（另两个是 property-based testing 与 diagnostics 工具）。（/blog/run-all-tasks/、/docs/chat/subagents/）

工具体系（定义/调用协议/注册/权限）

  • 内置工具类别在自定义 agent 标签、子 agent 标签、权限 capability 中统一使用：read（文件读/列/搜索）、write（文件写/编辑/删除）、shell（命令执行）、web（fetch/search）、subagent（委派）、context（steering/context 工具），以及元标签 @builtin（全部内置）与 *（全部）。MCP 工具用 @<server>（server 全部工具）或 @<server>/<tool>（指定工具）寻址，支持通配符（@figma/*）。（/docs/custom-agents/、/docs/chat/subagents/）
  • AST 结构化工具取代纯文本工具，约 2026 年 2 月上线（/blog/surgical-precision-with-ast/）：原有 readFile + strReplace 文本匹配工具正被”code read”（返回签名/结构/搜索结果而非全文件）与”code write”（结构化选择器如 ClassName.methodName、function:name、field:name、end，四种类型化操作 insert_node/replace_node/delete_node/replace_in_node）取代。实测在 SWE-PolyBench 子集上 token 减少 20-30%、每任务 LLM 调用最多减少 34%；某 feature-request demo 中工具错误数从 2 降为 0。
  • IDE diagnostics 作为一等工具：agent 直接调用支撑编辑器红波浪线的同一 LSP 基础设施（TypeScript/Python/Rust/SQL/YAML/GraphQL 类型检查器，ESLint，Terraform/CloudFormation/K8s-YAML/Dockerfile IaC 校验器），而非 shell 出去跑 npm run build/npm test。单次检查延迟 < 35ms；生产环境实测命令执行次数减少 29%。（/blog/empowering-kiro-with-ide-diagnostics/）
  • Shell 工具带 cwd 参数、明确拒绝 cd 的持久化效果——命令始终从 workspace 根目录执行；工具会将 cd dir && cmd 模式自动改写为 cmd + cwd=dir（服务端改写，而非仅靠 prompt 约束），并在改写后注入 system reminder。（/blog/hidden-inefficiencies-ai-coding/，discovery #2）
  • 注册/权限模型：统一权限引擎通过 capability/match/exclude/effect YAML 规则（见安全章节）对所有工具类别（内置、MCP、skills、powers）统一生效，是唯一的工具调用权限机制。
  • Powers = 动态加载的 MCP 工具包：文档明确指出成本问题——“五个 MCP server 可能在第一条 prompt 前就消耗 5 万+ token，占上下文窗口的 40%“——因此 Power 的工具只在对话关键词/主题匹配时激活，话题转移后自动去激活（示例：提及 “payment”/“checkout” 时激活 Stripe power，转到 Supabase 工作时去激活）。（/docs/powers/）
  • MCP 支持：标准 MCP 客户端——stdio server（command/args/env，默认 60s 连接握手超时，requestTimeout 默认 120s/调用）与 HTTP server（url+headers 鉴权）。可在自定义 agent profile 内联配置或通过全局 mcp.json 配置。支持 MCP prompt/resource 模板的 # 提及引用，以及 elicitation 请求（server 在工具调用中途请求更多输入）。（/docs/mcp/、/docs/custom-agents/）

Prompt 设计（系统提示结构、动态组装）

  • 未发现泄露/公开的原始系统提示（闭源产品的预期情况）。
  • 动态组装机制在架构层面有文档化描述，通过 steering + skills + powers 分层：
    • Steering：always 文件无条件拼接进每条 prompt；fileMatch 文件按当前打开/编辑文件条件性拼入；manual/auto 文件按显式提及或描述匹配追加。
    • Skills：启动时仅加载 name+description（每个 skill 约几十 token）；完整 SKILL.md 正文仅在激活匹配时加载进上下文——明确的”渐进式披露”架构，与 Anthropic 自家 Agent Skills 规范（agentskills.io）同模式。（/docs/skills/）
    • Powers：POWER.md steering 内容与 MCP 工具 schema 一并加载，按对话关键词/主题匹配门控，避免多个 MCP server 工具定义同时常驻造成”上下文过载”。（/docs/powers/）
    • Custom agents：agent 的系统提示就是 .kiro/agents/*.md 文件 YAML frontmatter 之下的 Markdown 正文——即 prompt = 字面文件内容，未见任何模板引擎。（/docs/custom-agents/）
  • 运行时中途注入的自纠正提醒：确认的具体案例——改写 cd 前缀的 shell 命令后，Kiro 向上下文注入 <system-reminder>Working directory is now back to workspace root...</system-reminder> 消息，以保持 agent 方向正确（证明存在运行时 prompt 注入这一 steering 机制，不仅是静态系统提示文本）。（/blog/hidden-inefficiencies-ai-coding/）
  • EARS notation（Easy Approach to Requirements Syntax）作为 spec requirements 的结构化格式——agent 被训练/prompt 为既能生成也能解析这种受控自然语言语法写入 requirements.md。（/blog/introducing-kiro/、/docs/specs/）

Router / 编排（任务分解、多 agent、子 agent）

  • 模型路由（“Auto”）：一个独立的模型选择层，“结合多个前沿模型与优化技术，交付最优的质量/成本比，为每个任务自动选择最优模型”。免费层保证 >= Sonnet-4.5 级别质量；付费层保证 >= Opus-4.6 级别质量，“配合增强流量路由”。（/docs/models/）路由算法/分类器本身未公开细节。
  • Spec 任务编排 = 基于 DAG 的 wave 调度（见循环章节）：对 tasks.md 建依赖图，可并发安全的任务归入同一 wave 顺序执行。（/docs/specs/）
  • 子 agent（IDE/CLI）：两种内置类型——“context gathering” 子 agent（探索项目、收集相关上下文）与”general purpose” 子 agent（并行化其他任务）。子 agent 并行运行，主 agent 阻塞等待全部完成，各自拥有独立上下文窗口，结果自动返回主 agent。Steering 文件与 MCP server 在子 agent 内行为一致；Specs 与 Hooks 不会传播进子 agent（明确的限制）。自定义子 agent 可定义为 .kiro/agents/ 下的 .md 文件，frontmatter 字段含 name（必填）、description、tools（数组，支持 @server/@server/tool/通配符）、model、includeMcpJson、includePowers。（/docs/chat/subagents/）
  • Kiro autonomous agent（独立产品）采用显式角色专精的多 agent 编排：“research and planning” agent、“code” agent、以及在推进前校验产出的”verification” agent——一条明确的 plan→execute→verify 流水线，不同于 IDE 的子 agent 模型。（/blog/introducing-kiro-autonomous-agent/）
  • ACP（Agent Client Protocol）：Kiro CLI 实现这一开放、编辑器无关的 JSON-RPC-over-stdio 协议（方法：initialize、session/new、session/load、session/prompt、session/cancel、session/set_mode、session/set_model），使 Kiro agent 可被 JetBrains IDE、Zed 或任何兼容 ACP 的编辑器驱动，无需定制集成。Kiro 用 _kiro.dev/ 前缀方法扩展该协议以支持 slash 命令、MCP OAuth 事件、上下文压缩状态。这本质上是”agent”与”调用方编辑器”之间的编排/互操作层，与 agent 内部任务编排是两回事。（/docs/cli/acp/）

Skill / 插件体系

Kiro 有三套明确区分的扩展机制（/docs/skills/#how-skills-differ-from-steering-and-powers 给出官方三方对比表）：

  • Agent Skills — 实现开放的 agentskills.io 标准（可跨兼容工具移植，非 Kiro 专有）。文件夹 = SKILL.md（必填）+ 可选 scripts/、references/、assets/。Frontmatter：name（必填，须与文件夹名一致，小写字母/数字/连字符，最长 64 字符）、description（必填，最长 1024 字符，用于激活匹配）、可选 license、compatibility、metadata。渐进式披露：启动时加载 name+description，完整正文在激活匹配或显式 slash 命令调用时加载。作用域：workspace（.kiro/skills/）vs. global（~/.kiro/skills/），同名 workspace 优先。可从 GitHub URL（子目录或直接 SKILL.md 链接）或本地文件夹导入。（/docs/skills/）
  • Powers — Kiro 专有的 POWER.md（steering）+ MCP server 配置 + 可选 steering/hooks 打包，通过策展市场分发（首发合作方：Datadog、Dynatrace、Figma、Neon、Netlify、Postman、Supabase、Stripe、Strands SDK、AWS Aurora）或社区 GitHub 仓库、或本地自建。与纯 MCP 配置的区别特征：动态关键词触发加载而非启动时全量加载工具 schema。真实内容仓库：github.com/kirodotdev/powers（326 stars），抓取时点约 25 个 POWER.md 包。（/docs/powers/、github.com/kirodotdev/powers）
  • Steering — Kiro 专有的持久化上下文文件（见记忆/prompt 章节），非可移植打包机制，定位为”项目标准与约定”而非”可复用工作流”。
  • Custom agents — 第四种相邻机制：完整 agent 人格（系统提示 + 工具白名单 + 权限规则 + 内联 MCP server），以独立 .md 文件呈现，出现在”agent selector” UI 中，可作为子 agent 被调用。（/docs/custom-agents/）

自进化能力（自我改进 / 学习型记忆 / eval 驱动纠错）

两套不同机制——一套作用于产品本身（Kiro 从聚合遥测数据自我改进），一套作用于用户代码（Kiro 帮助用户代码库收敛到 spec 正确性）：

  • “CORAL”（Continual Optimization via Reasoning and Adaptive Learning） —— 内部系统，名称/缩写在 /blog/hidden-inefficiencies-ai-coding/ 中确认：每天抽样数千个真实（已 opt-in）生产环境 Kiro 会话，对完整工具调用轨迹（不仅是 pass/fail）做基于 LLM 的根因分析，提炼出置信度评分的”经验教训”知识库（分类：工具使用、工作流模式、错误恢复、行为指导），将高置信度经验转化为已上线的修复——工具描述文案改动、系统提示改动、或自动纠正逻辑——无需模型重新训练。两个具体已上线案例带硬指标：(1) 一行工具描述文案修复将错误的 grep glob pattern 用法从搜索请求的 26.10% 降到 0.30%；(2) 自动将 cd X && cmd shell 模式改写为 cmd, cwd=X 消除了一个影响 18% 会话、失败率 100% 的模式。这是”轨迹数据反哺 harness 行为”最清晰的证据（直接呼应轨迹利用章节）。
  • Property-aware code evolution（bug 修复工作流） —— 一套正式方法论（不只是 prompting），用于 agent 自身在 bug-fix 任务上的自我纠正循环：agent 推导出显式的 bug-condition C 与 postcondition P，形成可证伪的根因假设，在写任何修复代码之前先写 bug-condition 测试（必须在未修复代码上 FAIL）与 preservation 测试（必须在未修复代码上 PASS），应用修复后重跑同一套未改动的测试——若某个 bug-condition 测试仍失败，假设被证伪，agent 需重新调查；若某个 preservation 测试翻转，则判定修复引入了非预期副作用，需收窄修复范围。明确建模为差分测试/red-green TDD 结合 property-based testing（底层用 Python 的 Hypothesis 库）。明确声明不适用于非功能性质（性能、竞态条件）——“一个开放问题”，并明确称将此方法从 bug-fixing 扩展到 features/重构是”我们研究的一个活跃方向”。（/blog/bug-fix-paradox/）
  • Spec 中的 Property-Based Testing（更广义）：Kiro 从 EARS notation 的 requirements 中提取可测试性质，生成数百/数千个随机化测试用例（PBT “shrinking” 寻找最小反例），失败时可”自动更新你的实现，或提供选项修复 spec、实现、或测试本身”——即一个明确文档化的、绑定在 spec 产物上的 eval 驱动纠错循环，而非临时性 bugfix。（/docs/specs/correctness/）
  • 未发现底层 LLM 被 Kiro 用这些轨迹数据微调/RL 训练的证据——CORAL 明确将修复以 prompt/工具 schema 编辑的形式上线，“无需模型重训”。Kiro 消费第三方前沿/开放权重模型（Claude、MiniMax、GLM、DeepSeek、Qwen），而非训练自有模型。

可观测性（日志 / trace 格式）

  • ACP agent 日志（CLI）：写入 $TMPDIR/kiro-log/kiro-chat.log（macOS）或 $XDG_RUNTIME_DIR/kiro-log/kiro-chat.log（Linux）。详细级别由 KIRO_LOG_LEVEL 环境变量控制；自定义路径用 KIRO_CHAT_LOG_FILE。（/docs/cli/acp/）
  • ACP 会话事件日志：~/.kiro/sessions/cli/<session-id>.jsonl —— JSONL 事件日志即 CLI 会话的对话/动作轨迹格式。（/docs/cli/acp/）
  • MCP 日志（IDE）：可在 Kiro 面板 > Output 标签 > “Kiro - MCP Logs” 下拉菜单中查看。（/docs/mcp/）
  • 企业级按用户活动报告：每日 CSV 投递到客户自有 S3 bucket，路径 s3://bucket/prefix/AWSLogs/accountId/KiroLogs/user_report/region/year/month/day/00/clientType_accountId_user_report_timestamp.csv，每日 UTC 2:00 AM 生成，每种客户端类型（IDE/CLI/Plugin）一个文件。文档化的指标 schema 包括 Chat_Conversations、Credits_Used、Overage_Cap/Used、Total_Messages（用户 prompt + 工具调用 + 响应）、New_User 标记，以及按模型名动态列出的每模型消息计数（按字母序，“Auto” 开头）。另有一份”legacy”报告（仅 CLI/Plugin）追踪更细粒度的按功能采纳指标：Chat_AICodeLines、CodeFix_、CodeReview_FindingsCount、Dev_（/dev 命令）、DocGeneration_（/doc 命令）、InlineChat_、Inline_、TestGeneration_ —— 即每个 AI 辅助面的接受/拒绝/忽略计数器。（/docs/enterprise/monitor-and-track/user-activity/）
  • 遥测类型（个人/免费层，可 opt-out）：使用数据（Kiro 版本、操作系统、匿名机器 ID）与性能指标（请求数/错误/延迟），覆盖 Login、Tab completion、Code generation、Steering、Hooks、Spec generation、Tools、MCP。（/docs/privacy-and-security/data-protection/）
  • Hook 遥测：hook 的 name 字段明确标注为”telemetry 中显示的标识符”——每个 hook 被单独追踪。（/docs/hooks/）
  • 未发现除 ACP JSONL 事件日志与 CORAL 轨迹分析流水线（内部专用、非用户可见）之外的公开内部 trace-format 规范（例如 OpenTelemetry span）覆盖 agent 自身推理/工具调用序列。

安全与权限（审批门、密钥管理）

这是文档化程度最高的维度。

  • 统一权限模型（IDE 1.0+，取代原”trusted commands”作为唯一机制——trusted commands 仍作为更简单的legacy/并行路径存在）：规则形如 {capability, match?, exclude?, effect}，effect 为 deny/ask/allow，冲突按 deny > ask > allow 解析。Capabilities：fs_read、fs_write、filesystem、shell、web_fetch、web_search、mcp、subagent、skill、power、diagnostics、context、all、builtin。Glob 语法因类别而异：文件系统模式支持 **、{a,b}、[abc]；shell/web/mcp 模式仅支持 *（不支持 **/?/字符类）。Shell 命令在匹配前会被解析并按 ;/&&/||/| 拆分，专门用于防止复合命令绕过 npm test * 这类规则的注入。（/docs/chat/permissions/）
  • 作用域层级：User（~/.kiro/settings/permissions.yaml）、Workspace（~/.kiro/workspace-roots/<hash(workspaceRoot)>/permissions.yaml —— 存储在仓库之外、按用户隔离，因此克隆的恶意仓库无法注入权限规则）、Kiro（硬编码，不可覆盖）、Administration（企业/MDM 专用）、Session（内存态，仅当前会话）。
  • Kiro 作用域硬编码不变量：对 ~/.kiro/settings/、.kiro/settings/、~/.kiro/workspace-roots/ 的写入始终拒绝（agent 不能修改自己的权限配置）；对 .git/**、.kiro/agents/**、.kiro/hooks/**、.kiroignore 的写入始终询问。
  • 受保护路径（两种模式均生效，不可被静默绕过）：.vscode/、vscode~、.git/、git~、.code-workspace（路径包含匹配）；.git、mcp.json（精确 basename 匹配）。
  • Trusted commands（legacy/简化机制，设置搜索”Kiro Agent: Trusted Commands”）：仅做朴素字符串前缀匹配——npm install（精确）、npm *（通配）、裸 *（信任一切）。文档明确声明不分析命令结构/链式/特殊字符——“责任完全在你”。这比新的统一权限引擎的 shell 命令解析弱。
  • Autopilot vs. Supervised —— 明确声明这不是安全边界：原文引述，“Supervised mode is a code review workflow, not a security control. It is designed to help you review and approve agent-generated changes. It does not function as a sandbox, isolation boundary, or access control mechanism.”两种模式授予的底层能力（读/写/执行）完全相同；唯一区别是何时展示 diff 供审批（事前 vs. 事后）——而非 agent 能碰什么。（/docs/privacy-and-security/）
  • Supervised 模式下强制审查的文件修改操作（模型不可跳过）：文件创建/覆盖、文本替换、内容追加、文件删除、代码编辑、符号重命名、文件移动。
  • 数据保护/密钥：传输层 TLS >= 1.2；静态加密用 AWS KMS（默认 AWS 自有密钥；企业版可自带客户管理 KMS 密钥，仅对称密钥）。免费/个人层内容仅存储于 us-east-1；企业数据”不存储”（文档原文，推测意为不超出推理所需留存）。跨区域推理用于负载分布（不改变存储区域），“实验性”模型/功能除外可能全局路由。免费层滥用检测会保留输入最长 60 天，即使用户已 opt-out 服务改进数据共享。（/docs/privacy-and-security/data-protection/）
  • Kiro autonomous agent（独立产品）有自己的密钥模型：按任务配置环境变量/密钥，“加密存储，且从不出现在日志或 pull request 中”。（/blog/introducing-kiro-autonomous-agent/）
  • Headless/CI 模式：需要 KIRO_API_KEY 环境变量（仅 Pro/Pro+/Pro Max/Power 层可用）；因无人工审批工具调用，需显式 --trust-all-tools 或限定范围的 --trust-tools=read,grep；--require-mcp-startup 在 MCP 依赖连接失败时快速失败。最佳实践明确建议：将 key 存为 CI secret，优先用最小权限的 --trust-tools 而非 --trust-all-tools。（/docs/cli/headless/）

沙箱与执行隔离

依产品面而给出两个截然不同的答案：

  • Kiro IDE/CLI（本地、交互式）：无沙箱。 文档反复明确声明：agent 与用户拥有相同的本地机器访问权限——“在你的本地环境中运行，可能访问：本地文件与仓库、环境变量、你环境中存储的 AWS 凭证、其他含敏感信息的配置文件”。推荐的缓解措施是流程级而非沙箱级：使用专用用户账户或容器环境、通过独立 workspace/.gitignore 做 workspace 隔离、限定范围/临时 AWS 凭证、仓库专属 GitHub token。Remote-SSH 扩展（Open VSX 社区扩展）附带明确警告：被攻陷的远程机器”可能利用该连接在你的本地机器上执行代码”。（/docs/privacy-and-security/）
  • Kiro autonomous agent（独立的异步云端产品）：真正的沙箱化。 每个任务”启动一个镜像你开发环境的隔离沙箱环境”并将仓库克隆进去。按任务可配置：
    • 网络访问，明确 3 档：“仅集成”（沙箱只能访问 GitHub 代理）、“常用依赖”（npm/PyPI/Maven registry 可达）、“开放互联网”——外加自定义域名白名单。
    • 环境自动从仓库中检测到的 DevFile（devfile.io）或 Dockerfile 配置；两者均不存在时回退到项目结构分析。
    • 密钥/环境变量按任务限定范围、加密、排除在日志与 PR 之外。（/blog/introducing-kiro-autonomous-agent/）
  • 未披露自主 agent 沙箱实现的进一步技术细节（如容器运行时、Firecracker/gVisor 等、资源限额）——标注为”以上之外未公开”。

与模型的协同设计

Kiro 在产品层是模型无关/多供应商的，但显示出清晰的、由模型行为差异驱动的 prompt/工具协同设计迹象：

  • 多模型目录覆盖 Anthropic（Opus 4.5/4.6/4.7/4.8，Sonnet 4.0/4.5/4.6/5，Haiku 4.5），以及开放权重模型：DeepSeek 3.2、MiniMax M2.1/M2.5、GLM-5、Qwen3 Coder Next——每个都标注了上下文窗口、相对 credit 倍率（相对”Auto”基线 0.05x-2.2x）、按供应商的区域可用性。“Auto” 是 Kiro 自有的路由器，结合多个模型”交付最优的质量/成本比”。（/docs/models/）
  • 推理强度控制：用户可选 Low/Medium/High/XHigh/Max 五档强度（各模型可用档位不同——例如 Opus 4.6 没有 XHigh，只有 Opus 4.7/4.8 支持全部 5 档），明确描述为用 token 消耗换取更深的多步推理；文档明确警告同一倍率的不同模型 credit 成本可能不同，因 tokenizer 差异与内部思考 token 用量不同（举例：Opus 4.8 更新的 tokenizer 相对 4.6 对相同 prompt 产生不同 token 计数）。（/docs/models/）
  • 文档化的按模型行为调优知识被内嵌进产品指导：例如”Opus 4.7 及以后引入自适应思考……根据任务复杂度自动调整推理深度”；“Opus 4.8……在证据不足时主动标记不确定性并提出质疑，而非自信地宣称有进展”——Kiro 文档明确指导用户”如果你在生成代码中看到 bug”就切换到 Opus 4.8。这意味着 harness 的 prompting/工具设计至少部分针对特定模型的自我纠正能力做了调优，而非纯粹模型无关。
  • CORAL 的模型无关修复暗示工具描述文案是针对观察到的 LLM 训练数据先验迭代的：*.py vs **/*.py 的 glob 误用与 cd X && cmd 的 shell 模式问题都被明确诊断为”LLM 从训练数据中学到了这种模式”（ripgrep 默认行为、常见 shell 习惯）——即 Kiro 的工具描述正被专门调整以抵消跨模型的训练先验，这是一种模型感知（即便不是模型专属）的协同设计形式。（/blog/hidden-inefficiencies-ai-coding/）
  • 未发现 Kiro 对任何模型做联合训练或微调的证据——它纯粹是前沿/开放权重模型的消费方，经（按文档所述）Amazon Bedrock 跨区域推理接入。“Kiro is powered by Amazon Bedrock” 是文档披露的唯一基础设施供应商细节。（/docs/privacy-and-security/data-protection/）
  • 未发现：任何与 Anthropic/其他厂商的直接合作披露，涉及协同设计的 prompting API、联合基准测试、或超出标准 Bedrock 模型访问之外的共享 eval 套件。

轨迹利用（session/trajectory 是否反哺训练/评测）

  • CORAL 是这一维度最清晰、最具体的答案：Kiro 每天抽样数千个真实生产会话（来自已 opt-in 用户），对完整工具调用轨迹（不仅是 pass/fail）做基于 LLM 的分析，提炼出持久的”经验教训”到置信度评分知识库，并将高置信度经验转化为已上线的产品改动（工具描述文案改动、系统提示改动、确定性自动纠正代码)——明确”无需模型重训”。这是轨迹驱动的产品演进，而非轨迹驱动的模型训练。（/blog/hidden-inefficiencies-ai-coding/）
  • 明确的数据使用 opt-in/opt-out 框架：“Kiro Free Tier 与 Kiro 个人订阅用户”的内容（prompt、其他输入、生成的响应/代码）可能被用于”服务改进”，文档明确包括”用于底层前沿模型的模型训练”——但这指的是将数据回传给模型供应商的训练流水线，与 CORAL 的 prompt/工具工程循环是两回事。企业用户默认被排除/自动 opt-out。个人用户可通过 IDE 设置 > User > Application > Telemetry and Content（两个独立开关：使用分析与内容收集）、CLI Preferences、或 Kiro Web 设置 > Agent 来 opt-out。即使免费层用户已 opt-out”服务改进”数据共享，仍受一个独立的 60 天输入留存约束用于滥用检测（明确声明不用于模型改进，仅用于滥用分类器训练）。（/docs/privacy-and-security/data-protection/）
  • Kiro autonomous agent 的跨会话学习（另见记忆/自进化章节）是一种独特的、范围更窄的轨迹复用形式：过往任务的 PR review 评论被保留，并作为行为约束应用到同一用户/团队的后续任务——这更接近持久记忆/RAG 机制而非训练数据流水线，但确实明确是”从”先前轨迹（代码审查结果）中”学习”，而非原始聊天回放。
  • Property-Based Testing 失败会反馈进 SPEC 产物本身（而非任何模型）：“发现违反时，Kiro 可以自动更新你的实现，或提供选项修复 spec、实现、或测试本身”——在生成代码失败变成单个项目 spec 文件内结构化反馈循环的意义上与轨迹相关，但不是跨用户学习。
  • 未发现 Kiro 轨迹被作为基准/数据集发布的证据，也未发现原始会话数据被出售/分享给第三方（超出底层 Bedrock 托管模型调用本身所需）的证据。

与同类 harness 的关键差异（1-3 条，可以先留一句概述，后续 synthesis 阶段会做跨 harness 对比）

  • Kiro 是本调研中少见的闭源产品却公开工程博客硬指标（token/延迟/错误率具体数字）的案例，这在信息密度上部分弥补了无法读源码的缺陷，但所有论断的精度上限仍是”文档/博客怎么说”，而非”代码怎么写”。
  • 三套并行的扩展机制（开放标准 Skills、专有 Powers、专有 Steering）并存且有官方对比表，这种”多套机制分层而非归一”的设计在同类 harness 中较为罕见，值得在跨 harness 对比阶段重点比较其边界是否清晰。
  • “Supervised mode is NOT a sandbox” 的明确免责声明，以及 IDE/CLI 与 autonomous agent 两个产品面在沙箱能力上的巨大落差（前者完全无隔离，后者有 3 档网络隔离的真沙箱），是跨 harness 对比”审批 UI vs. 真实安全边界”这一常见混淆点的一个好例证。

原始源码定位

  • repo: 无公开源码。GitHub org kirodotdev 下 kirodotdev/Kiro（仅 issue-triage 自动化，非应用代码）与 kirodotdev/powers（真实开源，POWER.md + mcp.json 内容包）。
  • commit/version analyzed: 不适用——无版本化应用源码；CLI 为滚动发布，无固定版本号。文档/博客抓取时点：2026-07-07。
  • 关键文件列表（相对路径，均为 kiro.dev 站点页面而非仓库文件）：
    • /docs/、/docs/specs/、/docs/specs/correctness/
    • /docs/hooks/、/docs/custom-agents/、/docs/steering/
    • /docs/skills/、/docs/powers/、/docs/mcp/
    • /docs/chat/permissions/、/docs/chat/subagents/、/docs/chat/summarization/、/docs/chat/autopilot/、/docs/chat/checkpoints/
    • /docs/models/
    • /docs/privacy-and-security/、/docs/privacy-and-security/data-protection/
    • /docs/enterprise/monitor-and-track/user-activity/
    • /docs/cli/、/docs/cli/acp/、/docs/cli/headless/
    • /blog/introducing-kiro/、/blog/surgical-precision-with-ast/、/blog/empowering-kiro-with-ide-diagnostics/、/blog/bug-fix-paradox/、/blog/hidden-inefficiencies-ai-coding/、/blog/run-all-tasks/、/blog/introducing-kiro-autonomous-agent/
    • github.com/kirodotdev/powers/blob/main/aws-mcp/POWER.md（示例 Power 文件）

一手源存档（sources/）

/Users/zhao/projects/self-wiki/ai-research/sources/harness/kiro-aws/ 下：

  • NOTES.md（41KB，本 dossier 的直接上游，含全部 12 维度详细发现与逐条引用页面）
  • example-POWER.md（aws-mcp POWER.md 示例文件全文）
  • example-hooks-and-permissions-config.md（hooks JSON schema、custom-agent Markdown frontmatter、permissions YAML、protected paths、trusted-commands 匹配规则的逐字表格）
  • blog-excerpts/（6 篇工程博客全文笔记）：
    • bug-fix-paradox.md
    • empowering-kiro-with-ide-diagnostics.md
    • hidden-inefficiencies-ai-coding.md
    • introducing-kiro-autonomous-agent.md
    • run-all-tasks.md
    • surgical-precision-ast.md

关系图谱

反向链接