Kiro Aws Expert Agent

Kiro AWS Expert Agent

English

用一个 JSON 文件，让 Kiro CLI 按需查询 AWS 官方文档——不污染主会话上下文，不拖慢启动速度。

本文分享这个轻量方案的设计思路，以及在 Kiro CLI agent 体系中做架构选择时的一些思考。

痛点

我日常用 Kiro CLI 做各种项目，偶尔需要查 AWS 文档——某个 API 的参数、某个服务的区域可用性、CDK 的写法。

直觉上有两个选择：

1. 全局加载 AWS Knowledge MCP Server：在 ~/.kiro/settings/mcp.json 里配置，每次启动 Kiro CLI 都会加载。但这意味着即使我在写一个纯前端项目，AWS 的工具定义也会占用上下文窗口、消耗 token。
2. 让 Kiro 用 web_search 在线搜索：Kiro CLI 内置了 web_search 工具，明确要求它搜索 AWS 文档，大多数时候也能得到答案。

两种方式都能用，但都不够理想。

三种方案的对比

在动手之前，我仔细比较了三种方案：

方案一：全局集成 MCP Server

// ~/.kiro/settings/mcp.json
{
  "mcpServers": {
    "aws-knowledge": {
      "url": "https://knowledge-mcp.global.api.aws",
      "type": "http"
    }
  }
}

优点是体验最好——Kiro 可以直接调用 search_documentation、read_documentation、get_regional_availability 等专用工具，结果精准且结构化。

缺点是始终在线。MCP server 的工具定义会出现在每次对话的上下文中，无论你是否在做 AWS 相关的工作。对于偶尔查 AWS 的用户来说，这是不必要的开销。

方案二：web_search

> 搜索 AWS 文档，查找 CloudFront Standard Log v2 的配置方法

Kiro CLI 内置的 web_search 工具可以搜索互联网，包括 AWS 文档。不需要任何额外配置。

但 web_search 是通用搜索引擎，和 AWS Knowledge MCP Server 的专用工具相比有明显差距：

关键区别：web_search 就像用 Google 搜 AWS 文档，而 Knowledge MCP Server 就像直接在 AWS 文档站内搜索。后者能做到前者做不到的事——比如查询某个 API 在哪些区域可用。

而且两者有一个共同的问题：搜索结果都会进入主会话上下文。

方案三：Subagent

这是我最终选择的方案。利用 Kiro CLI 的 自定义 Agent 机制，把 AWS Knowledge MCP Server 封装成一个独立的 subagent。

> 查询 Lambda 的最新功能

Kiro 的 default agent 根据 subagent 的 description 识别到这是 AWS 相关查询，自动将请求委托给 aws-expert subagent。subagent 在自己的上下文中调用 MCP server，查完文档后把结果返回给主会话。

核心优势：上下文隔离。AWS 文档的搜索过程、中间结果、工具调用都留在 subagent 的上下文里，主会话只收到最终答案。这是前两种方案都做不到的。

AWS MCP Server 生态

在选择用哪个 MCP server 之前，值得了解一下 AWS 官方提供了哪些 MCP server。完整列表在 。

其中"入门三件套"是：

• AWS MCP：统一入口，聚合多个 AWS MCP server 的能力
• AWS API MCP Server：直接调用 AWS API
• AWS Knowledge MCP Server：查询 AWS 文档和知识库

我选择 Knowledge MCP Server 是因为它完全是只读的文档查询，不需要 AWS 凭证，不会对账户产生任何影响，非常适合封装成一个安全的 subagent。

它提供 5 个工具：

数据源覆盖 AWS 官方文档、API 参考、What's New、Builder Center、博客、Well-Architected 指南、Amplify 文档、CDK/CloudFormation 文档和示例。

agent.json 设计解析

整个 subagent 的核心就是一个 JSON 文件，安装到 ~/.kiro/agents/aws-expert.json：

{
  "name": "aws-expert",
  "description": "Delegate to this agent when the user asks about AWS services, features, configurations, best practices, or troubleshooting. This agent connects to the live AWS Knowledge MCP Server to search real-time official documentation, API references, What's New announcements, blogs, Well-Architected guidance, CDK/CloudFormation examples, and Amplify docs. Use this agent instead of answering from general knowledge whenever the user needs current, accurate, or detailed AWS information. Triggers on: AWS, Lambda, EC2, S3, CloudFront, DynamoDB, ECS, EKS, IAM, VPC, CDK, CloudFormation, Bedrock, SageMaker, or any AWS service name.",
  "prompt": "You are an AWS documentation expert...",
  "mcpServers": {
    "aws-knowledge": {
      "url": "https://knowledge-mcp.global.api.aws",
      "type": "http"
    }
  },
  "tools": ["@aws-knowledge"],
  "allowedTools": ["@aws-knowledge/*"],
  "includeMcpJson": false
}

每个字段都有特定的设计考量：

description：给主 agent 看的路由指令

这是最关键的字段。Kiro 的 default agent（kiro_default）根据 description 来决定是否将请求委托给这个 subagent。

如果 description 只写"AWS documentation expert"，kiro_default 可能会想"我自己也懂 AWS"，然后用自己的知识回答。所以 description 必须明确传达两件事：

1. 什么时候该委托："Delegate to this agent when..."
2. 为什么要委托而不是自己回答："This agent connects to the live AWS Knowledge MCP Server"——强调这个 subagent 能做 kiro_default 做不到的事（查实时文档）

末尾的触发关键词列表帮助路由匹配，覆盖常见 AWS 服务名。

prompt：给 subagent 自己看的行为指导

prompt 和 description 的职责完全不同：

• description → 给 kiro_default 看，决定"要不要调用我"
• prompt → 给 aws-expert 自己看，决定"被调用后怎么回答"

这里有一个关键的设计考量：subagent 的回复不会直接呈现给用户，而是先返回给 kiro_default，由 kiro_default 转述。这个转述过程中，kiro_default 会根据自己的判断对内容进行总结和压缩。如果 subagent 的回复是一大段非结构化的文本，压缩后很容易丢失关键信息。

所以 prompt 里要求 aws-expert 用固定的结构返回响应——Direct Answer、Complete Code Examples、Step-by-Step Instructions、Key Requirements、Documentation URLs。这样即使 kiro_default 做了压缩，结构化的格式也能帮助它保留每个部分的核心内容，而不是把整个回复笼统地缩成一两句话。prompt 里甚至直接写明了 "Your response will be summarized by another agent - make code examples PROMINENT"，提醒 subagent 把代码示例放在最显眼的位置。

tools vs allowedTools

这两个字段容易混淆：

• tools：定义 subagent 能用哪些工具（可用范围）
• allowedTools：定义哪些工具不需要用户确认就能直接调用

两者缺一不可。没有 tools，subagent 没有工具可用；没有 allowedTools，每次调用 MCP 工具都会弹出确认提示。

includeMcpJson: false

这个字段确保 subagent 不会加载用户全局 mcp.json 中的其他 MCP server。aws-expert 只需要 AWS Knowledge MCP Server，不需要用户可能配置的 git、fetch 等其他工具。保持 subagent 的工具集干净。

已知限制：响应压缩

这是使用 subagent 架构时最容易踩的坑。

问题

Kiro 的 default agent（kiro_default）在收到 subagent 的回复后，会对内容进行转述。这个过程中，kiro_default 会根据自己的判断对内容进行总结和压缩。

原因

这不是 bug，而是 kiro_default 的设计行为。subagent 的回复对 kiro_default 来说只是"参考信息"，它会根据自己的判断决定呈现多少内容给用户。

解决办法

方法一：在 prompt 中要求结构化输出（已内置）

上文提到，aws-expert 的 prompt 已经要求 subagent 用固定结构返回响应，并明确提醒 "Your response will be summarized by another agent"。这是主要的应对手段——结构化的格式让 kiro_default 在压缩时能保留每个部分的核心内容，而不是把整个回复笼统地缩成一两句话。大多数场景下，这已经足够。

方法二：在提问时明确要求保留完整内容

> 查询 CloudFront Functions 的完整代码示例，请完整转述 subagent 的回复，不要省略代码

在 prompt 中加上"完整转述""不要省略"等指令，可以进一步引导 kiro_default 减少压缩。不能保证每次都有效，但大多数情况下能改善。

方法三：直接在主会话中集成 MCP Server

如果你的工作场景需要频繁获取完整代码示例，更可靠的做法是跳过 subagent，直接把 MCP Server 加到主会话：

// ~/.kiro/settings/mcp.json
{
  "mcpServers": {
    "aws-knowledge": {
      "url": "https://knowledge-mcp.global.api.aws",
      "type": "http"
    }
  }
}

这样 Kiro 直接调用 MCP 工具，结果不经过转述，完整度有保障。代价是 MCP 工具定义会始终占用上下文。

怎么选

• 快速查询和研究（"这个 API 支持哪些参数？""这个服务在哪些区域可用？"）→ 用 aws-expert subagent，响应压缩影响不大
• 需要完整代码示例用于实施（"给我一个完整的 CDK stack 示例"）→ 直接集成 MCP Server 更可靠

快速开始

安装

bash  查询 2026 年新增的 EC2 实例类型
> How to configure CloudFront Standard Log v2?
> AWS App Runner 在 eu-west-1 是否可用？

卸载

rm ~/.kiro/agents/aws-expert.json

前置要求

• Kiro CLI 1.24+
• 互联网连接

总结

回过头看，aws-expert 本身并不复杂——就是一个 JSON 文件，把一个 MCP server 封装成了 subagent。真正有价值的是背后的思路：当你发现某个能力"偶尔需要但不想常驻"时，subagent 是一个很好的封装方式。

这个模式不局限于 AWS 文档查询。任何你觉得"加到主会话太重，不加又不方便"的能力，都可以用同样的方式处理——绑定一个 MCP server，或者挂载一组 Skills，写好 description 让 kiro_default 知道什么时候该委托，写好 prompt 控制 subagent 的输出质量。一个 JSON 文件就是一个专用工具。

Kiro CLI 的 自定义 Agent 文档 和 配置参考 覆盖了所有可用的字段。如果你有自己的场景，不妨从一个最小的 agent.json 开始试试。

相关资源

• Kiro CLI 自定义 Agent 文档
• Agent 配置参考
• AWS MCP Servers
• AWS Knowledge MCP Server

许可证

MIT License - 详见 LICENSE 文件。