我如何使用 Kiro 优化其自身的 MCP 配置

Source: Dev.to

请提供您希望翻译的正文内容，我将按照要求保留源链接、保持原有的 Markdown 格式和技术术语，仅翻译文本部分。谢谢！

问题概述

我遇到了一个问题。我的 Kiro 设置随着时间的推移累计了 14 台 MCP 服务器：AWS 工具、网页自动化、文档服务器、邮件集成。这样就有数十个工具，在每次对话开始时全部加载到上下文中——即使我并不需要它们。

可扩展性的隐藏成本 – MCP 服务器让 AI 助手能够访问外部工具和服务。功能强大，但每增加一个服务器就会占用更多的上下文窗口。工具越多 → 在你提出第一个问题之前消耗的 token 越多，响应越慢，而且 AI 有时会因为选项太多而挑错工具。

自我优化方法

我使用了 Kiro CLI 的 Auto 模型（默认模式，会将前沿模型与针对不同任务的专用模型相结合）。对于这类工作（分析配置文件、研究文档、生成结构化输出），Auto 会为每一步挑选合适的模型，而不是使用单一的高成本模型来完成所有任务。

1. 创建恢复点

   /checkpoint init

   这会生成一个检查点，若出现问题可以回滚。
   额外安全提示： 在 ~/.kiro 中初始化一个 git 仓库，并在实验前提交一次。即使 Kiro 无法启动，也能提供恢复路径。

2. 提示 Kiro（在 ~/.kiro 中运行）：

   “这是我的 Kiro 配置文件夹。这里的 mcp 配置文件中有太多 MCP 服务器。你能帮我将这些 MCP 服务器分组并转换为 Kiro Powers 吗？请在线仔细研究它们的工作原理以及语法和文件夹结构的细节。检查是否有些 MCP 服务器已经被现有或新建的 powers 覆盖，以避免重复。请先准备一份详细计划并在对代码进行任何更改前向我提出建议。”

   最后一句很重要——我希望先得到一个可以审阅的计划，而不是立即修改文件。

Kiro 的提议

Kiro 分析了我的 mcp.json，在网上查阅了 Powers 文档，并返回了一份 整合计划。在进行更改之前，它还创建了原始配置的备份 (mcp.json.backup)——这是一项明智的预防措施，我甚至不需要提出请求。

基于功能的逻辑分组

之前

{
  "mcpServers": {
    "awslabs.aws-api-mcp-server": { ... },
    "aws-knowledge-mcp-server": { ... },
    "awslabs.aws-serverless-mcp-server": { ... },
    "bedrock-agentcore-mcp-server": { ... },
    "strands-agents": { ... },
    "email-calendar-mcp": { ... }
    // … 8 more …
  }
}

之后 – 根据关键字按需加载的六个 Powers：

关键洞察： 工具自然按工作流聚类。

• 构建 AWS 基础设施时，我需要 CDK 服务器和 AWS 文档，但不需要 Playwright。
• 测试网页应用时，我需要浏览器自动化，但不需要架构图工具。

对话

在审阅计划后，我批准了它：

“我批准你的计划，开始实施！”

Kiro 随后：

• 创建了文件夹结构。
• 编写了带有相应关键字和入职说明的 POWER.md 文件。
• 为每个 Power 配置了单独的 mcp.json。
• 添加了包含最佳实践的 steering 文件。

后续问题与细化

每个问题都进一步完善了结果。AI 负责实现，我负责引导设计。为此，我们都需要了解 Kiro Power 是什么。

Kiro Power 的样子

一个 Kiro Power 是一个自包含的包：文档、最佳实践以及它自己的 MCP 服务器配置捆绑在一起。当 Power 被激活时，它的 MCP 服务器会变为可用；当不需要时，它们则保持在上下文之外。

示例：aws-development Power

aws-development/
├── POWER.md
├── mcp.json
└── steering/
    ├── aws-api-workflows.md
    ├── serverless-patterns.md
    ├── cdk-best-practices.md
    └── architecture-diagrams.md

POWER.md 前置信息

---
name: "aws-development"
displayName: "AWS Development"
description: "Comprehensive AWS development toolkit..."
keywords:
  - "aws"
  - "cloud"
  - "serverless"
  - "lambda"
  - "cdk"
  - "cloudformation"
  - "infrastructure"
  - "api"
  - "documentation"
  - "diagrams"
mcpServers:
  - "aws-api"
  - "aws-knowledge"
  - "aws-serverless"
  - "aws-diagram"
  - "aws-cdk"
---

keywords 数组是触发机制。 当 Kiro 在你的对话中看到这些词中的任意一个时，它会自动加载此 Power。关键词匹配简单却有效：使用与你自然描述任务时相同的词汇。

要点

• 将相关的 MCP 服务器分组到 Powers 中，以减少启动上下文大小。
• 使用关键字驱动的激活，仅加载所需工具。
• 在任何批量更改之前创建检查点和备份。
• 与 AI 迭代——先请求计划，审查，批准，然后让它实现。

通过将 14 个单独的 MCP 服务器合并为 6 个按需 Powers，我显著降低了初始 token 负载，加快了响应速度，并使 Kiro 的工具选择更加可靠。同样的方法可以应用于任何臃肿的 Kiro 配置。优化愉快！

Source: …

结果

主文件 mcp.json 现在几乎是空的，只包含引用已安装 Powers 的 Powers 部分。服务器只有在需要时才会加载，这意味着启动更快。

• 上下文污染已消除。 当我在处理网页前端时，电子邮件和日历工具不会再占用上下文。
• AI 能做出更好的工具选择，因为可用选项更少且更相关。

Powers 会根据对话中的关键词激活：

• 询问 “CDK stacks” → 加载 AWS Development Power。
• 询问 “browser testing” → 加载 Web Automation Power。

有趣的并不仅仅是具体的优化，而是 方法 本身。我使用 Kiro 来：

1. 分析它自己的配置。
2. 研究我不太熟悉的文档。
3. 提出重构方案。
4. 讨论边缘情况。
5. 在多个文件中实现更改。
6. 验证结果。

亲自尝试

如果你的 MCP 配置已经变得难以管理，同样的方法同样适用：

1. 首先运行 /checkpoint init（或使用 Git 作为安全网，即使 Kiro 无法启动也能工作）。
2. 在 ~/.kiro 文件夹中打开 Kiro CLI，要求它分析你的 mcp.json 并提出分组建议。
3. 审核计划，讨论任何疑虑，进行完善，然后批准并让它执行。
4. 测试关键字是否触发正确的 Powers。

• Powers 不需要 MCP 服务器。你可以 创建仅文档的 Powers，使用针对特定框架或模式的 steering 文件。
• 它们是可移植的：推送到 GitHub 仓库，其他人即可安装。
• 社区 Powers 仓库 包含来自 Datadog、Figma、Stripe 等的示例。

如果你还没有尝试过 Kiro，可以 免费开始使用。

这将带来什么

我使用了一个 AI 工具来重新组织同一个 AI 工具访问其功能的方式。系统根据我实际的使用方式改进了自己的配置，仅用了 15 分钟。

同样的模式适用于 MCP 之外的场景：将你的 AI‑tooling 配置视为会不断演进的东西。

1. 从默认设置开始。
2. 使用工具并注意出现的摩擦。
3. 请求 AI 帮助减少这些摩擦。

配置文件并非神圣不可更改；它们只是代码库中可以重构和改进的另一部分。