用 Kiro 和 AWS 构建企业级 Agentic AI 平台

我们用 Kiro IDE 在一周内构建了一个完整的 AI Agent 平台——零手写代码。下面是完整的实现过程。

zhuermu··18 分钟
KiroAWSAgentic AIStrands AgentsBedrock AgentCore企业级AI平台AI IDE
用 Kiro 和 AWS 构建企业级 Agentic AI 平台

我们如何用 Kiro(来自 AWS 的 AI IDE)完成从需求到部署的完整开发生命周期——基于 Strands Agents、Amazon Bedrock AgentCore 和 AWS 基础设施,构建了一个可用于生产的 AI Agent 平台。一个人,一周时间,零手写代码。

为什么要做”以交付为核心”的 AI Agent?

大多数 AI 聊天产品止步于对话。你提个问题,得到一段文本回复,然后就没了。但企业场景需要的是可交付成果:架构图、已部署的网页、账单分析报告、可执行的代码。

这正是我们构建这个 AI Agent 平台的原因。用户用自然语言描述需求,Agent 便产出实实在在的成果——图片、视频、文档、数据分析、已部署的静态网站,甚至是 AWS 架构图。

平台主界面,展示带实时工具执行的 Agent 对话 平台主界面——左侧边栏展示会话与导航,右侧展示 Agent 对话,并实时显示工具执行进度与交付成果输出。

真正的挑战不在于”构建一个 Agent”——而在于让它在生产环境中稳定运行:自动扩缩容、安全的代码执行沙箱、跨会话的记忆持久化、多工具编排。从零构建这些能力需要数月时间。

我们的答案是一套三层运行时架构:Strands Agents(Agent 框架)+ Amazon Bedrock AgentCore(运行时 + 记忆 + 沙箱)+ AWS CDK(基础设施即代码)。

而最关键的一点是——整个平台从头到尾都是由 AI 开发的

开发层:用 Kiro 构建一切

这个项目最引人注目的地方在于:从需求收集、架构设计、任务拆解、代码开发、测试到部署——所有工作都由 Kiro(来自 AWS 的 AI IDE)完成,零手写代码。

这不是”AI 辅助开发”,而是真正的 AI 驱动开发——人类描述意图并验收结果,Kiro 负责从意图到代码的整条流水线。

规格驱动开发(Spec-Driven Development):从模糊想法到可执行任务

Kiro 的核心工作流是规格驱动开发(Spec-Driven Development)。你用自然语言描述想要什么,Kiro 会自动生成一份三层规格:

第一步:需求文档

我们告诉 Kiro:“构建一个以交付为核心的 AI Agent 平台,用户与 Agent 对话,Agent 产出图片、视频、文档和网页。后端使用 FastAPI + Strands Agents,部署在 AgentCore Runtime 上。”

Kiro 自动生成了一份结构化的需求文档,包含用户故事、验收标准和技术约束:

### Requirement 1: User Authentication
**User Story:** As a user, I want to sign in with my Google account,
so that I can securely access my personal workspace and deliverables.

### Requirement 3: Agent Tool Integration
**User Story:** As a user, I want the Agent to execute code, browse web,
generate images/videos, and deploy web pages...

Kiro 规格驱动开发自动生成的需求文档 Kiro 规格驱动开发生成结构化需求,包含用户故事、验收标准和技术约束。

第二步:技术设计

确认需求后,Kiro 生成一份技术设计文档——数据库 schema、API 定义、组件架构、时序图:

## Architecture
The architecture follows a three-tier design:
1. Frontend: React-based SPA for user interaction
2. Backend API: FastAPI server handling authentication and API routing
3. Agent Runtime: Strands Agent deployed on AgentCore Runtime

Kiro 自动生成的技术设计文档 Kiro 生成技术设计,涵盖系统架构、数据库 schema、API 定义和组件交互时序。

第三步:任务拆解

设计完成后,Kiro 把整个项目拆解为增量式的可执行任务,每个任务都关联到对应的需求:

- [x] 1.1 Initialize frontend project with React, TypeScript, and TailwindCSS
- [x] 1.2 Initialize backend project with FastAPI
- [x] 1.3 Set up database schemas and connections
- [x] 1.4 Set up Redis connection and utilities
- [x] 2.1 Implement Google OAuth authentication flow
- [x] 3.1 Implement Strands Agent with BedrockModel
- [x] 3.2 Implement Code Interpreter tool with AgentCore
...

Kiro 自动生成的增量式任务列表 Kiro 生成关联到需求的增量式任务,逐个执行直至全部完成。

随后 Kiro 逐个执行这些任务——编写代码、创建文件、配置依赖、运行测试——直到全部完成。

Vibe Coding:对话式迭代开发

除了规格驱动的结构化开发之外,日常的功能迭代和 bug 修复采用 Vibe Coding——用自然语言向 Kiro 描述需求,它立即修改代码。

例如:

  • “在 Library 页面添加文件预览功能”
  • “Agent 生成架构图时使用 AWS 官方 SVG 图标”
  • “WebSocket 断开后自动重连,最多重试 3 次”

Kiro 通过 Steering Files(架构文档和技术栈描述)理解项目上下文,并定位到需要修改的正确文件。

Steering Files:让 AI 掌握全局

Kiro 编写代码时的准确性来自 Steering Files——放置在 .kiro/steering/ 目录下的项目上下文文档。我们配置了四份核心文档,确保 Kiro 始终遵循项目的架构模式和编码规范。

Hooks:自动化质量保障

Kiro 的 Hooks 机制实现了自动化质量检查:

  • API Test Hook:当 routers/schemas/services/ 下的文件被修改时,自动运行 Postman 集合测试
  • Structure Sync Hook:当创建新文件时,自动更新 structure.md 以保持文档同步
{
  "name": "API Postman Testing",
  "when": {
    "type": "fileEdited",
    "patterns": ["backend/app/routers/*.py", "backend/app/schemas/*.py"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "API source code has been modified. Run Postman collection tests..."
  }
}

MCP Server 集成:实时访问文档

在开发过程中,Strands Agents 和 AgentCore 都是快速迭代中的服务。我们配置了 Model Context Protocol (MCP) Servers,让 Kiro 能够实时访问最新的官方文档:

  • Strands Agents MCP Docs Server——最新的 SDK API 文档、工具开发指南、部署示例
  • AgentCore MCP Docs Server——最新的 Runtime、Memory、Code Interpreter 和 Browser 文档

Kiro MCP Server 配置 Kiro 配置了 Strands Agents Docs 和 AgentCore Docs 的 MCP Servers,确保实时参考最新官方文档。

这意味着当 Kiro 编写 Agent 代码时,它参考的是实时的官方文档,而不是可能已经过时的训练数据。

开发效率:用天数取代月数

如果按传统方式构建,这个项目需要一支 3-5 人的团队工作 2-3 个月。而借助 Kiro,一个人在一周内完成了从零到生产部署的整条流水线。

整体架构

平台架构图 平台架构——用户请求经 CloudFront 进入 VPC,通过 ALB 到达运行在 ECS Fargate 上的 FastAPI 后端,Agent 通过 Bedrock AgentCore 调用 LLM 和工具,交付成果存储在 S3 中。

整个架构运行在 AWS Cloud 之内,VPC 划分为三层子网(Public / Private / Isolated)。Bedrock AgentCore 提供 Runtime 自动扩缩容、Memory 持久化、Code Interpreter 沙箱化和托管的 Browser。Amazon Bedrock 作为 LLM 平台,提供 Claude、Amazon Nova、Stability AI、Luma 等多种模型。

运行时第 1 层:Strands Agents——Agent 框架

为什么选 Strands?

在评估了多个 Agent 框架之后,我们选择 Strands Agents 的理由很简单:足够轻量,足够灵活。工具就是带 @tool 装饰器的 Python 方法。框架负责处理 Agent Loop、会话管理和模型调用。无需定义复杂的图结构,也不用学习专有的 DSL。

Strands Agents SDK 原生支持 Amazon Bedrock 作为模型提供方,这意味着我们可以直接使用 Bedrock 上的 Claude、Amazon Nova、Stability AI、Luma 等模型,无需额外的适配层。

核心 Agent 实现

Agent 的初始化代码极其简洁:

from strands import Agent
from strands.models import BedrockModel
from strands.agent.conversation_manager import SlidingWindowConversationManager

class MyAgent:
    def __init__(self, user_id: str, conversation_id: str, config: AgentConfig):
        # Initialize model via Amazon Bedrock
        self.model = BedrockModel(
            model_id="us.anthropic.claude-sonnet-4-6",
            region_name="us-west-2",
            temperature=0.7,
            max_tokens=128000,
        )

        # Load tools — core tools always loaded, domain tools loaded per user's enabled Skills
        self.tools = get_agent_tools(
            user_id=user_id,
            conversation_id=conversation_id,
            config=config,
        )

        # Create Strands Agent
        self.agent = Agent(
            model=self.model,
            tools=self.tools,
            system_prompt=config.system_prompt,
            conversation_manager=SlidingWindowConversationManager(window_size=35),
        )

SlidingWindowConversationManager 是长对话的关键——它只保留最近 N 轮上下文,在维持对话连贯性的同时防止 token 溢出。

工具模式:@tool 装饰器

每个工具都遵循”类方法 + @tool 装饰器”的模式:

from strands import tool

class CodeInterpreterTool:
    def __init__(self, region: str, user_id: str, conversation_id: str):
        self.region = region
        self.user_id = user_id

    @tool
    def execute_code(self, code: str, language: str = "python") -> str:
        """Execute code in a secure sandbox. Supports Python, JavaScript, and Shell.

        Args:
            code: The code to execute
            language: Programming language (python, javascript, shell)
        """
        # Executes via Amazon Bedrock AgentCore Code Interpreter — isolated sandbox
        ...

docstring 会自动成为 LLM 看到的工具描述,而类型注解会成为参数 schema。其余的一切——参数序列化、响应解析、把结果注入 Agent Loop——都由 Strands Agents 处理。

我们用这个模式构建了 15 个以上的工具。

动态工具加载:Skills 系统

并非每个用户都需要每个工具。我们构建了一套 Skills 系统,根据用户启用的 Skill 动态加载工具:

# Core tools — always loaded
tools = [code_interpreter, browser, web_search, file_ops, ...]

# Domain tools — loaded only when corresponding Skills are enabled
requested = set(domain_tool_names or [])
if "aws_pricing" in requested:
    tools.append(AWSPricingTool(region=config.aws_region).query_price)
if "architecture_diagram" in requested:
    tools.extend([arch.generate_diagram, arch.modify_diagram, arch.list_aws_icons])

工具越少,LLM 的决策越准确。这是我们在实践中得到的一条重要经验。

运行时第 2 层:Amazon Bedrock AgentCore——运行时、记忆与沙箱

Amazon Bedrock AgentCore 提供了三项核心能力,若从零构建每一项都需要数月时间:无服务器运行时、持久化记忆和安全的代码执行沙箱。

Amazon Bedrock AgentCore 服务概览 Amazon Bedrock AgentCore——为生产级 Agent 运行提供 Runtime、Memory、Code Interpreter 和 Browser 能力。

AgentCore Runtime:同一份代码,从开发到生产

AgentCore Runtime 架构 AgentCore Runtime——将 Agent 代码部署到 Runtime,即可获得自动容器编排、弹性扩缩容、会话管理和健康检查。

架构中最优雅的部分是双执行模式。AgentCore Runtime 入口只需要:

from bedrock_agentcore import BedrockAgentCoreApp
from bedrock_agentcore.runtime.context import RequestContext

app = BedrockAgentCoreApp()

@app.entrypoint
async def invoke(payload: dict, context: RequestContext):
    """AgentCore Runtime HTTP SSE streaming entry point"""
    user_id = payload.get("user_id", context.session_id)
    conversation_id = payload.get("conversation_id", context.session_id)

    agent = MyAgent(user_id=user_id, conversation_id=conversation_id)

    async for event in agent.process_message(payload["prompt"]):
        yield event  # Server-Sent Events streaming back to caller

if __name__ == "__main__":
    app.run()

AgentCore Runtime 负责处理容器编排、自动扩缩容、健康检查和会话管理。部署只需:

# Build and push container to Amazon ECR
docker build --platform linux/arm64 -t $ECR_URI:latest -f Dockerfile.agentcore .
docker push $ECR_URI:latest

# Update AgentCore Runtime
aws bedrock-agentcore-control update-agent-runtime \
    --agent-runtime-id $AGENT_ID \
    --agent-runtime-artifact '{"containerConfiguration":{"containerUri":"'$ECR_URI':latest"}}'

FastAPI 一侧只需一个环境变量即可切换模式:

if settings.agentcore_runtime_enabled:
    # Production: stream via AgentCore Runtime (HTTP SSE)
    async for event in agentcore_service.invoke_stream(payload):
        await websocket.send_json(event)
else:
    # Development: Agent runs directly in-process
    async for event in agent.process_message(message):
        await websocket.send_json(event)

本地开发使用 agentcore launch --local 启动一个本地 Runtime 实例,体验与生产环境完全一致。

AgentCore Memory:跨会话记忆

Amazon Bedrock AgentCore Memory 提供两种持久化能力:

  • 短期记忆(Short-Term Memory)——以事件形式存储最近的对话内容,并自动过期
  • 长期记忆(Long-Term Memory)——通过语义方式抽取并存储关于用户的关键事实,用于跨会话的个性化

AgentCore Memory 双层架构 AgentCore Memory——短期记忆存储最近的对话事件并自动过期,长期记忆通过语义抽取持久化关键的用户事实。

与 Strands Agents 的集成通过 SDK 的 Session Manager 实现:

from bedrock_agentcore.memory.integrations.strands.session_manager import (
    AgentCoreMemorySessionManager,
)
from bedrock_agentcore.memory.integrations.strands.config import (
    AgentCoreMemoryConfig,
    RetrievalConfig,
)

memory_config = AgentCoreMemoryConfig(
    memory_id="my_agent_memory_id",
    region="us-west-2",
    retrieval_config=RetrievalConfig(max_results=20, retrieval_type="SEMANTIC"),
)

session_manager = AgentCoreMemorySessionManager(config=memory_config)

# Pass to Strands Agent — auto-handles persistence and context retrieval
agent = Agent(model=self.model, tools=self.tools, session_manager=session_manager)

Session Manager 会自动持久化每一轮对话。当新会话开始时,它会自动检索相关上下文。用户第二天再回来,Agent 依然记得之前的上下文。

AgentCore Code Interpreter:安全沙箱

当用户提出”分析这个 CSV”或”运行这段 Python 脚本”时,我们需要一个隔离的执行环境。AgentCore Code Interpreter 提供临时沙箱,预装了 pandas、matplotlib、numpy 等数据科学库。每次执行都运行在隔离的沙箱中,不会跨用户污染,并会自动清理。

Agent 在 AgentCore Code Interpreter 中执行 Python 代码 Agent 在 AgentCore Code Interpreter 隔离沙箱中执行 Python 代码,生成数据分析图表。

AgentCore Browser:浏览器操作

网页抓取、表单填写和实时浏览都通过 AgentCore Browser 处理,它提供托管的 Chrome 实例,供 Agent 以编程方式控制。结合 Amazon DCV 流式传输,用户甚至可以在 UI 中实时观看 Agent 浏览网页。

AgentCore Browser 架构 AgentCore Browser——Agent 通过 API 控制托管的 Chrome 实例,结果以截图或 DCV 方式流式返回。

Agent 通过 AgentCore Browser 浏览网页 Agent 通过 AgentCore Browser 浏览网页,用户在嵌入的浏览器窗口中实时观看。

运行时第 3 层:AWS 基础设施——全程 CDK

整个基础设施都定义在单个 AWS CDK Stack 中——可复现、可版本控制。

核心基础设施

// VPC with three subnet tiers: public, private, isolated
const vpc = new ec2.Vpc(this, 'Vpc', {
    maxAzs: 2,
    natGateways: 1,  // Cost optimization: single NAT Gateway
    subnetConfiguration: [
        { name: 'Public', subnetType: ec2.SubnetType.PUBLIC },
        { name: 'Private', subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
        { name: 'Isolated', subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
    ],
});

// RDS MySQL 8.4 in isolated subnet — no internet access
const mysql = new rds.DatabaseInstance(this, 'Mysql', {
    engine: rds.DatabaseInstanceEngine.mysql({
        version: rds.MysqlEngineVersion.VER_8_4_7,
    }),
    instanceType: ec2.InstanceType.of(ec2.InstanceClass.T4G, ec2.InstanceSize.MICRO),
    vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
});

// ElastiCache Redis 7.1 for sessions and caching
const redis = new elasticache.CfnCacheCluster(this, 'Redis', {
    cacheNodeType: 'cache.t4g.micro',
    engine: 'redis',
    engineVersion: '7.1',
});

服务层

FastAPI 后端运行在 Application Load Balancer 后面的 ECS Fargate 上。React 前端通过 CloudFront 从 S3 提供服务。这种分离意味着前端部署大约只需 1 分钟(S3 sync + CloudFront 失效刷新),而后端部署则是独立的滚动更新。

CloudFront (app.example.com)  → S3 (React SPA)
CloudFront (docs.example.com) → S3 (Knowledge Portal)
ALB (api.example.com)         → ECS Fargate (FastAPI)

一键部署

./deploy.sh all          # Full deploy (infrastructure + frontend)
./deploy.sh frontend     # Frontend only (~1 minute)
./deploy.sh backend      # ECS rolling update (~10s to trigger)
./deploy.sh agent        # Deploy AgentCore Runtime Agent
./deploy.sh status       # Show current endpoints

平台能力

交付成果管理

Agent 产出的所有文件——图片、文档、代码、已部署的页面——都存储在 S3 中,并通过 Library 页面统一管理。

用于管理 Agent 交付成果的 Library 页面 Library 页面——统一管理所有 Agent 交付成果,支持按类型筛选、在线预览和一键下载。

架构图生成

Agent 使用 AWS 官方图标生成 Draw.io 格式的架构图,支持在线查看和编辑。

Agent 生成的 AWS 架构图 Agent 生成的架构图,采用 AWS 官方 SVG 图标,Draw.io 格式。

网页部署

Agent 可以将生成的 HTML/CSS/JS 直接部署到 S3 + CloudFront,为用户提供一个可分享的公开 URL。

Agent 生成并部署网页 Agent 在对话中接收需求、生成代码,并一键完成部署。

带公开 URL 的已部署页面 已部署页面通过 S3 + CloudFront 提供可分享的公开 URL,实现端到端交付。

图片与视频生成

通过 Amazon Bedrock 上的 Stability AI 和 Luma AI 模型,Agent 可以直接生成图片和视频。

Agent 通过 Stability AI 生成图片 Agent 通过 Amazon Bedrock 上的 Stability AI SD3.5 生成图片,结果内嵌显示在对话中。

经验教训

1. 让 LLM 来决策——不要过度编排

早期我们尝试构建僵硬的工作流——“如果用户询问价格,就路由到定价工具”。这很脆弱,无法应对含糊的请求。Strands Agents 的 Agent Loop 方式效果更好:给 LLM 提供工具和一个优秀的 System Prompt,让它自己决定编排顺序。模型在选择工具序列方面出人意料地擅长。

2. 工具越少,决策越好

一开始我们为每次对话都加载全部 15 个以上的工具。当面对过多选项时,LLM 偶尔会选错工具。基于 Skills 的动态加载解决了这个问题——用户启用所需的 Skill,只加载相关的工具。

3. 双执行模式是杀手级特性

同一份 Agent 代码在本地(Direct 模式)和生产环境(AgentCore 模式)运行,消除了一整类”在我机器上没问题”的 bug。这层抽象的成本极低——只是 WebSocket 处理器里的一个条件判断。

4. 流式输出不可妥协

Agent 任务可能耗时数分钟(生成视频、执行复杂代码、浏览多个页面)。如果没有 WebSocket 实时流式输出,用户只能盯着空白屏幕。我们把每一个事件都流式传出——思考、工具选择、工具结果、文件创建——让用户始终知道正在发生什么。

5. 记忆让 Agent 真正智能

没有 AgentCore Memory,每次对话都从零开始。有了它,Agent 会记住用户偏好、过往的交付成果和正在进行的项目。这把体验从”使用一个工具”升级为”与一位助手协作”。

快速上手

如果你也想构建一个类似的平台,这里是最短路径。我们推荐使用 Kiro 作为开发工具——规格驱动开发自动生成需求、设计和任务,然后用 Vibe Coding 逐步实现。

1. 搭建一个 Strands Agent

pip install strands-agents strands-agents-tools
from strands import Agent, tool
from strands.models import BedrockModel

@tool
def my_tool(query: str) -> str:
    """Search for information."""
    return f"Results for: {query}"

agent = Agent(
    model=BedrockModel(
        model_id="us.anthropic.claude-sonnet-4-6",
        region_name="us-west-2",
    ),
    tools=[my_tool],
)
response = agent("Help me look up the latest EC2 pricing")

2. 接入 AgentCore Runtime

pip install bedrock-agentcore
from bedrock_agentcore import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@app.entrypoint
async def invoke(payload: dict, context):
    agent = Agent(model=model, tools=tools)
    result = agent(payload["prompt"])
    yield {"type": "text", "data": {"content": str(result)}}

if __name__ == "__main__":
    app.run()

# Local testing
# agentcore configure --entrypoint app.py --name my_agent
# agentcore launch --local

# Deploy to production
# agentcore deploy

3. 用 AWS CDK 部署基础设施

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as rds from 'aws-cdk-lib/aws-rds';

const vpc = new ec2.Vpc(this, 'Vpc', { maxAzs: 2 });
const cluster = new ecs.Cluster(this, 'Cluster', { vpc });
const db = new rds.DatabaseInstance(this, 'DB', {
  engine: rds.DatabaseInstanceEngine.mysql({ version: rds.MysqlEngineVersion.VER_8_0 }),
  vpc,
});
// ECS Fargate Service, ALB, CloudFront, ElastiCache...

单个 CDK Stack 定义了 VPC、ECS Fargate、RDS、ElastiCache、ALB、CloudFront 以及所有其他生产基础设施。执行 npx cdk deploy 即可一键部署。

结语

构建一个企业级的 Agentic AI 平台曾经需要数月的基础设施工作——容器编排、沙箱执行、记忆系统、自动扩缩容。如今,整条流水线都可以由 AI 驱动:

  • Kiro 承担完整的开发生命周期——规格驱动开发生成结构化规格,Vibe Coding 负责日常迭代,MCP Servers 提供实时文档
  • Strands Agents 提供简洁的工具抽象和 Agent Loop,让我们专注于工具能力而非框架细节
  • Amazon Bedrock AgentCore 提供运行时、记忆和沙箱,省去了数月的基础设施自建
  • AWS CDK 让整个基础设施可复现、可版本控制、可一键部署

这不只是”用 AI 辅助开发”——而是用 AI 构建 AI。Kiro 作为开发者,构建了一个为用户交付成果的 AI Agent 平台。从一个模糊的产品想法到生产部署:一个人,一周时间,零手写代码。

源代码

本文引用的完整项目代码已开源:

参考资料

Kiro (AI IDE)

  • Kiro 官方网站 — 来自 AWS 的 AI IDE,具备规格驱动开发和 Vibe Coding
  • Kiro 文档 — Steering Files、Hooks、MCP 集成指南

Strands Agents

Amazon Bedrock AgentCore

AWS 基础设施

参考资料

  1. Kiro documentation — Kiro
  2. Strands Agents — Strands
  3. Amazon Bedrock AgentCore Developer Guide — AWS Documentation