Kiro Powers 本文是讲的 Kiro Power 生态系统技术解构。探讨 Power 组件的精确句法结构、控制

本文是讲的 Kiro Power 生态系统技术解构。探讨 Power 组件的精确句法结构、控制其激活的算法逻辑、其与模型上下文协议的深层集成机制，以及利用 AI 根据现有技术文档自动生成 Power 配置文件等。

1. 执行摘要与核心架构理念

在人工智能辅助软件工程（AISE）的快速演进中，集成开发环境（IDE）正从单纯的代码补全工具转变为具备自主推理能力的智能代理系统。然而，随着大型语言模型（LLM）被赋予越来越多的外部工具、库和文档访问权限，一个被称为“上下文过载（Context Overload）”的关键瓶颈日益凸显。当代理程序试图同时加载AWS、Kubernetes、React和Stripe等多个技术栈的完整上下文时，令牌（Token）消耗量不仅会迅速耗尽有限的上下文窗口，还会因信息信噪比的降低导致模型推理能力的显著退化，这种现象被称为“上下文腐烂（Context Rot）”1。

Kiro Powers 代表了解决这一挑战的范式转变。与传统静态、全局性的上下文管理不同，Powers 引入了一种动态的、即时编译（Just-In-Time）的架构。一个“Power”不仅仅是一个配置文件，它是领域专长的模块化封装，融合了行为引导（Steering）、模型上下文协议（MCP）服务器配置以及事件驱动的钩子（Hooks）3。这些模块在默认状态下保持休眠，仅在检测到特定的语义触发器——如关键词、文件模式或代理意图——时才被激活，从而在保持轻量级上下文窗口的同时，保留了对深度专业能力的访问权限5。

2. 语境经济学与 Kiro Powers 的架构必要性

2.1 上下文效率悖论与令牌经济

在传统的基于 LLM 的 IDE 应用中，上下文管理通常是加法式的。如果开发人员同时处理后端基础设施、支付网关和前端框架，系统往往会尝试同时加载这三个领域的所有 SDK 定义、API 模式和最佳实践。对现有研究片段的分析表明，仅连接五个标准的 MCP 服务器就可能加载超过 100 个工具定义，消耗约 50,000 个令牌1。这种饱和状态导致模型推理不仅变慢，而且更容易产生幻觉，因为模型必须在大量无关的干扰信息中寻找相关指令。

Kiro Powers 通过将上下文视为一种专门的、可加载的资产来解决这个问题。这种架构类似于操作系统的“动态链接库（DLL）”或游戏控制台的“卡带”模型，但应用于代理的认知状态管理。

2.2 Power Bundle 的解剖学结构

从文件系统的角度来看，Kiro Power 不是单个文件，而是一个强制执行严格模式的目录包。该目录结构旨在将元数据、工具配置和行为引导逻辑物理分离，以支持模块化加载。

标准目录结构规范：

路径/文件	必选性	功能描述	核心作用
`my-power/`	Root	根目录	命名空间容器
`├── POWER.md`	必选	清单文件、元数据与激活逻辑	定义 Power 的身份、触发条件及高级说明书
`├── mcp.json`	可选	工具桥接配置	定义与外部 MCP 服务器的连接参数与环境变量
`├── steering/`	可选	细粒度上下文注入目录	存放特定子任务的引导文件，避免一次性加载所有文档
`│ ├── workflows.md`	-	过程性知识	针对特定任务（如数据库迁移）的步骤指南
`│ ├── policies.md`	-	约束性知识	编码规范、禁止模式与安全策略
`└── hooks/`	可选	事件驱动自动化脚本	定义文件保存、创建等生命周期事件的响应逻辑

2.2.1 核心清单（`POWER.md`）

POWER.md 是 Power 的入口点。它利用 YAML 前置元数据（Frontmatter）来定义 Power 的语义边界——即它何时应该“苏醒”。文件的主体部分则充当代理的“入职手册”，在 Power 被激活的瞬间注入到系统提示词（System Prompt）中，指导代理如何使用随后加载的工具4。

2.2.2 工具桥梁（`mcp.json`）

此文件将 Power 映射到通过模型上下文协议提供的外部能力。它定义了实例化 MCP 服务器所需的可执行文件路径、参数、环境变量和网络端点。与全局 MCP 设置不同，这些配置的作用域严格限制在 Power 的激活生命周期内。

3. 详尽的配置语法与格式规范

Power 的稳健性完全取决于其配置文件的精度。以下是对每个组件的详细技术规范说明。

3.1 `POWER.md` 规范与 YAML Frontmatter

POWER.md 文件的头部必须包含一个严格的 YAML frontmatter 块。这个块会被 Kiro IDE 的意图检测引擎解析，用于构建路由索引。

完整语法参考：

# name: "aws-cdk-infrastructure" # 唯一标识符，建议使用 kebab-case 
displayName: "AWS CDK Infrastructure Expert" # UI 显示名称 
description: "Provides specialized tools and best practices for defining cloud infrastructure using AWS CDK, including CloudFormation validation and deployment workflows." 
keywords: ["aws", "cdk", "cloudformation", "infrastructure", "deploy", "stack"] # 核心触发词

# Power Instructions

## Purpose

## Capabilities

-   **Infrastructure Definitions**: Generating TypeScript CDK constructs.
-   **Validation**: Checking stacks against security policies.
-   **Deployment**: synthesizing CloudFormation templates.

## Onboarding

[代理在首次激活此 Power 时应执行的检查步骤。例如：]

1.  Check if `cdk.json` exists in the root.
1.  Verify AWS credentials are accessible in the environment.
1.  Suggest installing the specific CDK version matches `package.json`.

## Best Practices

-   Always use specific versions for Construct Libraries.
-   Enable deletion protection for stateful resources like RDS and S3 buckets.

字段深度解析：

name: 一个符合 kebab-case 的标识符（例如 aws-cdk-infrastructure）。它在安装的 Power 集中必须是唯一的。
displayName: 出现在 Kiro UI “Powers” 面板中的人类可读名称。
description: 当用户的输入不包含直接关键词匹配时，代理路由层会使用此描述来进行语义相关性评估。如果用户问“如何让我的服务器上线？”，即使没有提到“AWS”，语义匹配也可能根据描述中的“deployment”激活此 Power 。
keywords: 主要的触发机制。最佳实践是混合使用高频通用词（如 "database"）和特定的技术名词（如 "Postgres", "RLS"）。

3.2 `mcp.json` 深度配置架构

mcp.json 文件决定了代理如何物理连接到外部工具。它支持本地命令执行和远程 HTTP/SSE 连接两种模式。其结构必须符合严格的 JSON 规范。

Schema 定义与注解：

JSON

{
  "mcpServers": {
    "local-server-example": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://localhost/mydb"
      ],
      "env": {
        "PGPASSWORD": "${PG_PASSWORD}", 
        "NODE_ENV": "development"
      },
      "disabled": false,
      "autoApprove": [
        "query_table",
        "describe_schema"
      ],
      "disabledTools": [
        "drop_table",
        "truncate_table"
      ]
    },
    "remote-server-example": {
      "url": "https://mcp.supabase.com/v1/mcp",
      "headers": {
        "Authorization": "Bearer ${SUPABASE_KEY}"
      },
      "autoApprove": ["*"]
    }
  }
}

关键配置细节与安全策略：

变量扩展（Variable Expansion） : ${VAR_NAME} 语法允许访问用户全局环境或工作区 .env 文件中的变量。这是防止在共享的 Power 中硬编码敏感凭据（如 API 密钥）的关键机制。
autoApprove（自动批准） : 此数组对于用户体验至关重要。它列出了代理可以在不暂停等待用户确认的情况下执行的工具名称。对于“只读”工具（如获取文档、读取架构、列出文件），应填充此列表以保持交互流畅。如果设置为 ["*"]，则所有工具都会自动批准，但这通常只建议用于完全无副作用的服务器7。
disabledTools（禁用工具） : 显式阻止 MCP 服务器暴露的特定功能。这在企业环境中非常有用，例如，允许开发人员使用数据库 MCP 查询数据，但通过配置禁用 drop_table 或 delete_user 等危险操作，从而实现权限的细粒度控制。

3.3 事件驱动的 Agent Hooks 配置

Hooks（钩子）是定义在 .kiro.hook 文件中的自动化脚本。虽然它们可以独立存在，但在 Power 中，它们通常用于执行与领域相关的自动化任务（例如，Stripe Power 可能有一个钩子，在检测到 .env 文件更改时验证 Stripe API 密钥格式）。

Hooks JSON Schema：

JSON

{
  "enabled": true,
  "name": "Hook Name",
  "description": "Description of the automation workflow",
  "version": "1",
  "when": {
    "type": "fileEdited", 
    "patterns": ["**/*.ts", "src/api/*.js"]
  },
  "then": {
    "type": "askAgent", 
    "prompt": "Review the changes in {{filePath}}. Check for any hardcoded API keys...",
    "command": "npm run lint -- {{filePath}}" 
  }
}

触发器类型 (when.type) 详解：

fileCreated: 当匹配模式的新文件被创建时激活。常用于生成样板代码、添加许可证头或初始化配置文件8。
fileEdited: 当文件内容被修改时激活。适用于实时文档同步、增量测试生成或代码风格检查。
fileSaved: 与编辑不同，仅在用户显式保存文件（Ctrl+S）时触发。这是运行 Linter、Formatter 或触发构建脚本的理想时机。
fileDeleted: 文件被删除时触发。用于清理引用、更新索引文件或移除过时的测试文件。
userTriggered: 允许通过 Slash Commands（如 /fix-lint）手动触发钩子，为用户提供按需的自动化能力13。

动作类型 (then.type) 详解：

askAgent: 实例化一个后台代理会话来执行认知任务（例如，“审查此代码是否存在安全漏洞”）。必须包含 prompt 字段。这是 Kiro 区别于传统 Task Runner 的核心能力。
runCommand / executeCommand: 直接执行 Shell 命令。这对于集成 CLI 工具（如 eslint, kubectl, aws）至关重要。注意：在不同的文档版本中，此字段可能被称为 execute_bash，但在最新的 IDE Hooks 配置中，标准倾向于使用 runCommand 或 executeCommand。

4. 动态激活机制与触发时机分析

Kiro Power 的核心优势在于其“按需（On-Demand）”特性。理解其激活的算法逻辑对于设计高效的 Power 至关重要。

4.1 触发时机：在推理之前（Pre-Inference）

用户查询中的一个核心问题是：“触发时机是在 AI 回复时还是请求时？”

结论：触发发生在“请求处理阶段（Request Processing Phase）”，即在用户发送请求之后，但在 AI 开始生成回复之前。

详细流程解析：

用户输入截获：当用户在聊天面板输入“帮我部署这套代码到 AWS”并按下回车时，Kiro 的编排层首先拦截该消息。
意图与关键词匹配：
- 关键词扫描：系统扫描输入中是否包含已安装 Powers 的 keywords 列表中的词汇（如 "AWS", "deploy"）。
- 语义向量检索：系统可能并行运行一个轻量级的嵌入检索，将用户查询的向量与各 Power 的 description 向量进行比对，以识别没有直接关键词匹配但意图相关的 Power。
上下文注入（Context Injection） ：
- 一旦确定相关的 Power（例如 AWS Power），系统会读取该 Power 的 POWER.md 内容和 mcp.json 定义的工具列表。
- 这些信息被动态插入到发送给 LLM 的系统提示词（System Prompt）中。这意味着当 LLM 开始“思考”如何回复时，它已经“知道”了自己拥有 AWS 相关的知识和工具。
推理与回复：LLM 基于注入了新上下文的提示词生成回复或调用工具。

为何不在回复时？ 如果 Power 在 AI 回复时才触发，AI 将无法使用 Power 中的工具来构建回复，也无法遵循 Power 中的最佳实践，这违背了 Power 存在的初衷。

4.2 代理式循环激活（Agentic Loop Activation）

除了直接的用户触发，Power 还可以在多步任务执行过程中通过代理式评估被激活。

场景：用户要求“构建一个全栈应用”。
分解：代理将任务分解为“设计数据库”、“搭建后端”、“开发前端”。
动态加载：当代理开始执行“设计数据库”子任务时，系统会根据任务描述（Task Description）再次评估可用 Power。此时，即使原始提示词中没有提到“Neon DB”，但由于子任务涉及数据库，系统可能会自动激活 neon-db Power。这实现了真正的“上下文随动”。

4.3 冲突解决与上下文卸载

去激活（Deactivation） ：这是 Power 与传统 MCP 的关键区别。Powers 是瞬态的。如果对话从“数据库优化”转向“前端样式调整”，系统设计旨在卸载数据库相关的上下文，并加载设计相关的上下文（如 Figma Power）。这种机制防止了上下文窗口被无关的历史数据填满2。
多 Power 协同：如果任务同时涉及多个领域（如“将 Stripe 支付数据写入 Supabase”），系统会同时激活这两个 Power，前提是总 Token 数未超标。如果超标，系统可能会根据与当前焦点的相关性对 Power 内容进行截断或摘要。

5. 与模型上下文协议（MCP）的深度联动

Kiro Power 与 MCP 的关系是互补的：MCP 提供了工具通信的标准，而 Power 提供了工具使用的编排逻辑。

5.1 封装与生命周期管理

Kiro Power 充当 MCP 服务器的容器。在传统设置中，MCP 服务器通常在全局配置文件 ~/.kiro/settings/mcp.json 中定义，这意味着它们在 IDE 启动时加载并一直驻留。

而在 Power 中，mcp.json 是局部的。

联动生命周期表：

阶段	传统全局 MCP	Power 集成 MCP	优势分析
注册	用户手动编辑全局 JSON	安装 Power 时自动解析	降低配置门槛，实现一键安装 9
启动	IDE 启动时	Power 激活时	节省系统资源，减少后台进程
上下文	始终占用 Token	仅在相关时注入	防止上下文污染，提高模型专注度
卸载	IDE 关闭时	Power 去激活时	释放连接和内存

5.2 引导层（Steering）对 MCP 的增强

单纯连接一个 MCP 服务器（例如数据库工具）可能是有风险的，因为 AI 可能会执行破坏性操作。Power 通过 POWER.md 中的引导层增强了 MCP 的安全性与实用性。

操作约束：POWER.md 可以包含明确指令，例如：“当使用 database_query 工具时，始终先运行 EXPLAIN 分析查询计划，且禁止在未获得用户明确许可的情况下执行 DELETE 或 DROP 语句。”
最佳实践绑定：对于 AWS Power，mcp.json 提供了 aws_cli 工具，而 POWER.md 则规定：“在使用 CLI 创建 S3 存储桶时，必须默认启用加密和版本控制。” 这将工具能力与业务规范紧密结合。

6. 高级工作流：基于现有文档自动生成 Power 配置文件

用户提出了一个前沿需求：“如何让 AI 根据现有的开发或运维文档自动生成这个 Power 配置文件。”

目前，Kiro 尚未提供一个直接的“URL 转 Power”的一键按钮，但我们可以设计一个基于元提示词（Meta-Prompting）的自动化工作流来实现这一目标。这个过程模拟了一个高级工程师阅读文档并编写配置文件的认知过程。

6.1 “文档到 Power”的转化管道

要实现自动化，我们需要构建一个管道，将非结构化数据（HTML、Markdown、PDF 文档）转化为结构化的 JSON 和 YAML。

管道步骤：

摄取（Ingestion） ：将目标工具的官方文档（如 API 参考、CLI 手册、最佳实践指南）作为上下文输入给 Kiro。
解析与提取（Parsing & Extraction） ：AI 分析文档，提取核心概念（用于关键词）、命令结构（用于 MCP）和操作规范（用于 Steering）。
合成（Synthesis） ：将提取的信息映射到 Kiro Power 的文件架构中。
验证（Validation） ：检查生成的 JSON 是否符合 Schema，YAML 是否有效。

6.2 自动化生成器的元提示词设计（Meta-Prompt）

您可以将以下提示词作为模板，输入给 Kiro（或任何能够访问文档的 LLM），以生成 Power 文件。

提示词模板：

角色设定：你是一位 Kiro Power 架构专家，精通 MCP 协议和 Kiro 的上下文管理机制。

任务：我需要为 [工具/库名称，例如：Kubernetes Helm] 创建一个 Kiro Power。我已经提供了该工具的官方文档（见附件/链接/下方文本）。

执行步骤：

分析文档：

识别该工具的核心领域术语，用于生成 keywords。

提取 CLI 命令或 API 端点，用于构建 mcp.json。

总结“最佳实践”、“注意事项”或“常见错误”，用于编写 POWER.md 和 steering 文件。

生成文件结构：请生成以下文件的完整代码块：

POWER.md：

包含严格的 YAML Frontmatter（name, description, keywords）。

“Onboarding”部分：基于文档的安装/配置指南。

“Capabilities”部分：该工具能做什么。

“Steering”部分：AI 在使用此工具时必须遵守的规则（从文档的警告部分提取）。

mcp.json：

如果文档提到该工具已有 MCP 服务器，请使用标准配置。

如果没有，请配置一个基于 CLI 的通用 MCP 包装器（使用 stdio 通信或命令执行）。

设置 autoApprove 列表，包含所有只读/发现类命令（如 list, get, status）。

设置 disabledTools，屏蔽极其危险的命令（如 system prune, format）。

steering/workflows.md（可选）：

如果文档中有“快速开始”或“教程”，将其转化为分步工作流指南。

hooks/auto-lint.kiro.hook（可选）：

如果该工具涉及配置文件（如 YAML, JSON），生成一个在文件保存时自动运行验证命令（如 helm lint）的钩子。

约束条件：

输出必须是有效的 Markdown 代码块。

mcp.json 中的环境变量必须使用 ${VAR_NAME} 格式，不要硬编码密钥。

关键词列表应包含至少 10 个高相关性词汇。

6.3 自动化生成案例研究：为 Redis CLI 生成 Power

假设我们将 Redis CLI 的帮助文档输入给 AI，应用上述策略，预期的生成结果分析：

关键词提取：AI 应识别出 "redis", "cache", "key-value", "store", "set", "get", "ttl" 等词汇。
MCP 配置逻辑：
- AI 识别到 redis-cli 是可执行文件。
- 在 mcp.json 中，它会配置一个 command: "redis-cli"。
- 智能安全判断：AI 应将 GET, KEYS (慎用), INFO 放入 autoApprove；将 FLUSHALL, FLUSHDB 放入 disabledTools 或不自动批准列表，因为文档通常会标记这些为危险操作。
Steering 生成：
- 文档中关于“生产环境禁用 KEYS 命令”的警告，会被 AI 转化为 POWER.md 中的一条规则：“Do not use KEYS * in production context; use SCAN instead.”

6.4 解析非结构化文档的挑战与对策

挑战：文档格式不统一，有时 API 参数分散在多个页面。
对策：使用 RAG（检索增强生成）技术。如果文档量巨大（如 AWS 文档），不要一次性放入上下文。而是先让 AI 生成目录索引，然后针对特定模块（如“S3 CLI Reference”）分别生成 Steering 文件，最后在 POWER.md 中引用这些子文件。这符合 Power 的“分层引导”设计哲学。

7. 案例研究：设计一个复杂的企业级 DevOps Power

为了展示上述所有概念的综合应用，我们将设计一个虚构的 "Acme Corp Kubernetes Deployment Power" 。

7.1 需求场景

Acme 公司有一套内部的 Kubernetes 部署规范，要求所有 Pod 必须有资源限制（Resource Limits），且必须包含特定的标签（Labels）。开发人员经常忘记这些规则。

7.2 Power 文件结构设计

1. `POWER.md` (Manifest)

## 
name: "acme-k8s-deploy" 
displayName: "Acme Corp K8s Standard" 
description: "Enforces Acme Corp's engineering standards for Kubernetes manifests, including mandatory labels and resource quotas." 
keywords: ["kubernetes", "k8s", "deployment", "pod", "service", "yaml", "acme-deploy"]

# Acme K8s Standards

## Rules

1.  **Resource Limits**: Every container MUST have `resources.limits` and `resources.requests` defined.
1.  **Labels**: Every metadata block MUST contain `app.kubernetes.io/owner`.
1.  **Images**: Always use ECR paths `123456.dkr.ecr.us-east-1.amazonaws.com/...`, never public Docker Hub.

2. mcp.json (Tooling)

配置 kubectl 作为工具，但限制其权限。

{
  "mcpServers": {
    "kubectl-wrapper": {
      "command": "kubectl",
      "args": ["proxy", "--port=8080"], 
      "disabled": false,
      "autoApprove": ["get_pods", "describe_service", "logs"]
    }
  }
}

hooks/validate-k8s-yaml.kiro.hook (Automation)

当用户保存 YAML 文件时，自动检查是否符合公司规范。

{
  "name": "Validate K8s Manifest",
  "when": {
    "type": "fileSaved",
    "patterns": ["k8s/*.yaml", "helm/**/*.yaml"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "Check this YAML file against Acme Corp's standards defined in POWER.md. Specifically look for missing resource limits and owner labels. If violations are found, suggest strict fixes."
  }
}

7.3 工作流演示

触发：用户在编辑器中打开 k8s/deployment.yaml。
激活：由于文件路径匹配和内容（包含 "kind: Deployment"），Kiro 激活 acme-k8s-deploy Power。
干预：用户按下 Ctrl+S 保存。
执行：fileSaved 钩子触发。
反馈：Kiro 的后台代理读取 POWER.md 中的规则，分析刚保存的 YAML，发现缺少 resources 字段。
结果：Kiro 弹出提示：“检测到违规：缺少资源限制。建议添加如下配置...”，并提供修复代码。

8. 安全性、治理与最佳实践

随着 Power 赋予 AI 更多能力，安全性治理变得至关重要。

8.1 权限隔离原则

最小权限原则（PoLP） ：在 mcp.json 中，应默认禁用所有破坏性操作，仅通过 autoApprove 开放必要的只读操作。对于写操作，应始终保留“人机回环（Human-in-the-Loop）”，即要求用户点击确认。
环境隔离：Power 应能够识别当前环境（开发 vs 生产）。可以通过读取 NODE_ENV 或特定的 .env 变量，在生产环境中自动禁用高危 Power 或钩子。

8.2 Power 的分发与更新

GitOps 管理：企业应建立一个中心的“Power Repository”，所有 Power 作为 Git 子模块分发给开发团队。这确保了所有人的 POWER.md 中的合规性规则是同步更新的6。
版本控制：mcp.json 引用的工具版本应锁定，避免因外部工具升级导致 Power 行为不可预测。

8.3 防止提示词注入（Prompt Injection）

由于 Power 的内容会被注入到 System Prompt，恶意的 Power 作者可能会试图覆盖 AI 的核心指令。
防御：Kiro 平台层通常会对注入的内容进行沙箱化处理，或者在 System Prompt 中给予 Power 上下文较低的优先级，确保 AI 始终遵循核心的安全准则（如“不生成有害代码”）。

9. 结论

Kiro Powers 彻底改变了 AI 在 IDE 中的角色。它不仅仅是一个“更聪明的聊天机器人”，而是一个动态的、上下文感知的DevOps 编排引擎。

通过将知识（Steering）、工具（MCP）和自动化（Hooks）封装在模块化的 Power Bundle 中，Kiro 解决了 LLM 在面对庞大技术栈时的上下文过载问题。特别是其与 MCP 的深度集成，使得 IDE 能够安全、受控地与外部世界交互。

对于追求极致效率的工程团队而言，掌握“如何将现有文档自动化转化为 Power”这一元技能，将是将组织内部隐性知识显性化、并赋予 AI 执行力的关键步骤。这标志着软件工程从“人写代码”向“人定义规则，AI 执行与守护”的智能体时代的跨越。

附录：核心组件与功能速查表

组件 (Component)	文件位置 (Location)	核心功能 (Function)	关键语法特征 (Critical Syntax)
Manifest	`POWER.md`	激活逻辑与领域概述	YAML Frontmatter (`keywords`, `name`)
Tool Config	`mcp.json`	工具连接与权限控制	`mcpServers` 对象, `autoApprove` 数组
Steering	`steering/*.md`	深度上下文与最佳实践	标准 Markdown, 可分层引用
Automation	`.kiro/hooks/*.kiro.hook`	事件驱动的自动化操作	JSON: `when` (触发器), `then` (动作)
Prompt Gen	(AI Generated)	从文档自动生成配置	Meta-Prompting 策略, RAG 分析

Kiro Powers