去年年底我在AWS上海分会场听一个分享会后有个做云资源的同学拉住我问你们搞的Agent到底跟以前的命令行脚本有什么区别是不是拿大模型把Shell和AWS CLI包了一层就算Agent了这个问题当时问得全场都笑了但仔细想了想他说的确实沾边。拿大模型把AWS CLI包一层确实是很多入门级Agent干的事可一旦真正进入生产环境你会发现里面还藏着编排、工具注册、权限收敛、上下文记忆这一大堆东西。最近社区里讨论比较多的Kiro Agent典型就是跑在AWS上的一个命令行智能体。网上关于它的资料相当散官方文档也没把架构讲透很多人光是搭环境、调权限就被卡了好几天。这篇我把Kiro这类CLI形态的Agent拆开揉碎从它到底解决了什么问题讲起再逐层拆架构、聊权限设计、对比Claude Code、Pi Agent、Hermes Agent这些同类框架最后说部署上线时最容易踩的那些坑。1. Kiro Agent到底是什么——不是又一套玩具框架先说结论Kiro Agent本质上是一个跑在终端里的AI代理它的核心场景是帮你把AWS云资源的创建、检查、运维操作从一串串手敲命令变成一句自然语言指令。比如你说帮我看看这个Region里所有没打标签的EC2实例它自己去翻AWS CLI、跑查询、整理结果甚至能接着执行下一步操作。但这只是表面。真正区分它和普通脚本的是它具备了三样东西任务拆解能力、工具调用能力、和结果回环验证能力。脚本是写死的顺序流程Agent是会根据每步输出决定下一步怎么走的活流程。这也是为什么它叫Agent而不是Tool。1.1 为什么Kiro选了CLI这个形态你可能也会问为什么这类工具都倾向于做成CLI工具而不是Web界面我在实际用下来有几个很现实的体会终端是运维和开发者的主场。AWS的用户群体里绝大多数动手能力强的Kiro用户日常就是泡在终端里的与其开一个浏览器页面来回切换不如直接在Shell里把事办了。CLI形态天然方便跟其它工具链组合。Kiro跑出来的结果可以管道给jq、grep也可以接进CI/CD流水线这是Web应用完全做不到的。上下文更纯粹。没有浏览器那一堆标签页、前端路由、鉴权跳转一个终端窗口就可以承载完整的会话消息这对Agent的上下文管理压力也小很多。当然CLI形态也有代价比如没有可视化界面多步任务的过程跟踪基本靠日志。这个问题往后可以通过挂TUI前端解决但从第一版本看CLI的取舍是合理的。1.2 它和AWS CLI是什么关系很多人的第一反应是Kiro是不是在AWS CLI上面套了一个转发壳这个理解对了一半。它确实依赖AWS CLI提供的底层能力但不只是转发。从架构上看Kiro把AWS CLI封装成Agent可调用的工具并在上面加了一层语义理解。传统做法是你得自己拼--filter、--query这些参数Kiro的做法是你描述意图它帮你去拼参数、执行命令、解析JSON输出然后把结果塞回给模型做下一步判断。举个例子你想看所有非运行状态的EC2手写AWS CLI大概是这样的aws ec2 describe-instances \ --filters Nameinstance-state-name,Valuesstopped,stopping \ --query Reservations[].Instances[].[InstanceId,State.Name] \ --output table如果是直接用Kiro那就是一句话kiro 列出这个账号下所有不在运行状态的EC2实例这句自然语言背后Agent要完成的是意图识别、实例类型判断、命令选择、参数组装、权限核对、结果解析、输出整理这几步。所以Kiro跟AWS CLI的关系是底座与上层建筑而不是简单的替身。1.3 它适配的是哪类用户和场景Kiro不是给所有人生造的玩具。适合用它的我总结下来是这三类人AWS架构师和运维工程师日常要频繁做资源盘点、配置检查、成本分析Kiro可以把重复性很高的查询和操作变成对话式任务。开发团队的DevOps负责人需要快速排查问题、批量处理资源又不想记一大坨繁琐的CLI参数。刚刚接触AWS的初学者你甚至不用先记住那些命令参数用自然语言就能把资源状态问出来边用边学CLI的写法。不适合用它的人也很明确一是需要极致精细化控制、每一个参数都要精确指定的场景二是对操作合规审计要求极其严格、不允许模型自由决定执行命令的场景。前者用脚本后者只能走审批流。2. 整体架构拆解接入层、编排层、执行层、模型层如何协作架构图网上很难找到官方版这大概是Kiro这类项目最让初学者头疼的地方。我结合自己落地同类Agent的经验把Kiro的整体架构拆成四层来看基本可以涵盖所有核心链路。2.1 四层架构总览这四层从用户视角向系统内部依次是层级核心职责关键组件类比接入层跟人交互接收输入、展示输出CLI终端、会话管理、参数解析门店前台编排层决定下一步做什么是整个Agent的大脑Agent核心循环、提示词工程、任务规划器门店店长工具层真正去执行操作、获取数据工具注册表、AWS CLI封装、Shell执行器、权限校验执行任务的员工模型层提供推理能力和语义理解大模型接口、模型路由、上下文管理大脑的决策中枢每一层都不是孤立存在的层与层之间有明确的调用协议。接入层拿到用户输入后会把它包装成统一的消息结构丢给编排层编排层会决定该调哪个工具然后把调用请求发给工具层工具层执行完返回结构化结果编排层拿到结果开始下一轮循环直到它认为任务已经完成为止。2.2 请求流转的完整链路为了让你看清楚整个过程我拿查看指定EC2实例的CPU利用率这个简单任务做例子完整走一遍链路用户在终端输入kiro 看一下i-0abc123那个实例的CPU使用率接入层CLI解析器先把这条字符串解析成合法的参数结构建立一个会话ID并把消息追加到该会话的历史记录中。编排层拿到消息后与模型层发生第一次交互系统提示词 历史上下文 当前用户消息一起送到模型层。模型层返回的是工具调用结构化输出里面包含工具名ec2_metric、参数instance_idi-0abc123, metricCPUUtilization以及为什么选这个工具的简短理由。编排层校验这个工具确实存在然后转交工具层执行。工具层先做权限检查再组装成AWS CLI命令执行后把JSON结果返回。这一步会有超时控制防止个别命令长时间挂死。编排层把执行结果成功、错误、或数据作为观察结果再次发送给模型层让模型判断下一步是继续调用工具还是直接生成最终答案。如果模型判断任务已完成就生成面向用户的摘要接入层把它打印在终端中。整个循环就是经典的ReAct模式Reason Act推理一步、行动一步、观察结果、再推理。Kiro能自动做事核心秘密就在这个循环里。很多Agent产品做出来效果不好十有八九是这个循环里的某一环断了。2.3 架构设计上的几个关键取舍在实际做这类架构时有几个点特别容易纠结我也一并说说我的看法。顺序执行的严谨 vs 并行执行的效率。AWS环境里的任务经常有多个依赖关系比如创建实例之前得先建安全组、先配子网。Kiro这类Agent默认倾向顺序执行因为模型在前一步结果没出来之前很难正确决策。但这也意味着耗时长的任务会比较慢。折中做法是加一个任务依赖图只有互相独立的步骤才并行。本地执行 vs 云端代理执行。早期版本大多直接在用户本地跑好处是AWS凭证不用额外管理用你本机配置好的profile就行。但到了团队协作场景Agent跑在服务器上、大家共享一个执行环境更合理。Kiro在这块的设计是两种都能跑本地模式面向个人远程模式面向团队但远程模式的权限和审计要求会高很多。瘦客户端 vs 胖客户端。所谓瘦客户端就是工具层只做转发把命令发给本地的AWS CLI执行胖客户端则是把AWS的API调用直接集成在Kiro内部不走CLI。这两种各有优缺点瘦客户端开发快、复用已有CLI能力但是解析CLI文本输出麻烦胖客户端拿到的是结构化数据、更可靠但工作量翻倍。多数早期实现都先走瘦客户端等框架稳定了再逐步把高频工具改为原生调用这是比较省力的演进路径。3. 核心组件拆解Agent框架的骨架细节架构分层看完了这一节我聚焦到具体组件看看每个部分内部是怎么设计的。理解了这些细节你就能举一反三换到别的Agent框架上也能快速上手。3.1 CLI接入层的命令设计与交互协议CLI工具看着简单实际好用的命令行入口设计起来有不少讲究。Kiro采用的模式几个关键点如下。第一点是子命令的划分。它把交互分成两类一类是交互式对话在终端里进入一个kiro的提示符模式可以连续对话另一类是一次性执行kiro 指令直接跑完退出。交互模式适合探索性任务一次性模式适合脚本调用两者互补。第二点是会话持久化。终端窗口关掉再打开之前的对话应该还在。这个要靠会话文件实现Kiro默认把会话历史记录存在用户目录下的隐藏文件夹里。会话ID、创建时间、消息列表、相关的工具调用记录会被保存下来。这既是记忆的持久化也是排查问题时的证据链。第三点是Token和成本预估。即便模型很便宜在终端里跑着跑着烧掉几十万Token也不奇怪。做得好的CLI工具会在执行前预估一下这次调用的Token成本和风险等级遇到高危操作还会二次确认。3.2 编排层Agent核心循环和任务规划编排层是整个Agent最核心的部分也是最难做好的部分。这里我分开讲三个子机制。第一个是工具选择的策略。模型怎么知道该调用哪个工具Kiro会把所有工具的描述、参数Schema、使用场景写进系统提示词里模型根据用户的需求和工具描述做匹配。效果好不好很大程度上取决于工具描述写得准不准。一个AWS命令你用两句话描述清楚使用场景和典型参数模型选错的概率会低很多反之描述模糊的工具在复杂任务里几乎不会被正确选中。第二个是任务的分解。当用户给的是一个复杂任务比如帮我把这台服务器的环境搭好模型不能一步完成需要拆成安装依赖、配置系统服务、验证运行状态等子任务。拆得好不好取决于提示词里是否约束了输出格式。常见的做法是让模型先输出一个JSON格式的任务计划然后按计划逐步执行每步执行完检查结果再决定是否调整后续计划。第三个是失败重试机制。云平台操作失败太常见了尤其是权限不足、资源冲突、限流这类问题。Agent不应一遇到失败就终止而应尝试换一种方式重试。我通常会在提示词里明确告诉模型遇到权限错误可以尝试检查当前身份遇到资源冲突可以等待几秒再重试遇到参数错误先反思是不是参数拼错了。这个反思-重试的过程决定了Agent在无人值守时的靠谱程度。3.3 工具层AWS服务调用的封装方法工具层是Agent真正动手的地方。它的架构设计直接决定了Agent能力边界和安全性下面按执行链路的顺序拆解。工具注册表是第一步。工具不是随便写个函数就能给模型用必须在注册表里登记工具名、输入参数Schema、描述、权限要求、超时设置。工具注册表很像一个API网关模型能感知到的只有注册表里暴露的内容。那些没有注册的工具模型是看不到也调不动的这是一个重要的安全边界。工具描述要做到机器可读、语义清晰。Kiro里每个工具的描述都包含使用场景、参数含义、返回值的结构说明。正常人写工具可能只写一句查询EC2实例但真正好用的工具描述要写成查询指定地域的EC2实例列表支持按状态过滤返回实例ID、名称、状态、类型、公网IP。当用户想了解实例运行状况时使用此工具。参数校验也放在工具层。AWS CLI对参数格式要求非常严格日期时间、CIDR、ARN格式只要错一点就执行失败。工具层在调用CLI之前先把模型生成的参数通过JSON Schema校验一遍格式不对就直接拒绝并给出修正建议这能省下大量来回重试的过程。执行引擎的选择直接影响稳定性。Kiro默认调用本机的AWS CLI这意味着它需要装配好有效凭证。这里必须提醒一个坑直接用subprocess调用CLI时别忽略环境变量传递。如果你的CLI依赖某个AWS_PROFILE或AWS_REGION环境变量而Agent后台进程没继承就会拿到一个默认配置环境从而跑到错误的区域甚至报身份错误。3.4 模型层接口抽象和多模型适配Kiro之所以能保持灵活跟模型层做了良好的抽象关系很大。它不绑定某一个固定的模型服务而是定义了统一的模型接口后面再对接OpenAI接口、Anthropic的Claude、DeepSeek甚至本地部署的模型。这也是搜索词里claude code如何使用kiro的模型接口这个问题的由来只要模型提供标准的对话补全或工具调用接口Kiro就可以通过配置切过去。在模型层里有两个细节值得单独说。一个是工具调用Function Calling能力的适配。各家模型对工具调用的格式不一样Kiro的模型层会做一次内部转换把工具的JSON Schema转成模型认识的格式再解析模型返回的工具调用信息统一回编排层。这样切换模型的时候上面几层完全感知不到变化。另一个是上下文的压缩。随着对话轮数越来越多发给模型的上下文字符串会越来越长费用和延迟一起涨。Kiro在模型层封装了上下文管理当历史记录超过阈值时会对旧消息做摘要只保留关键信息。更像人的记忆机制——旧的事记个大概当前的对话记得清楚。4. 命令执行权限设计允许全部执行背后的风险与取舍搜索kiro使用教程时有一个高频词条是kiro设置所有命令允许执行。这听起来很方便但恰恰是这类Agent最危险的一个按钮。我建议所有打算在生产环境跑Kiro的人先停下来把权限模型想清楚。4.1 权限模式有哪几档从权限严格到宽松大致可以分四档权限模式行为表现使用场景风险等级白名单模式只有注册白名单里的命令可以执行生产环境、审计场景低确认模式每个危险命令执行前弹确认框开发环境、半自动场景中黑名单模式大部分命令放行少数危险命令拦截有一定把握的个人环境中高放行模式所有命令都允许执行本地测试、玩具项目极高网上说的设置所有命令允许执行对应的就是最后一种放行模式。我理解很多初学者为了跑通Demo会选它毕竟每条命令都要确认很烦。但这东西就跟给应用开了一个root权限一样你永远不知道模型的某一步决策会带出什么后果。4.2 为什么全部放行是危险操作想清楚这个逻辑你需要理解Agent的行为特征。模型在决策时的目标函数是完成用户的任务它不会像人一样天然有安全意识。你可以通过提示词约束它但当任务复杂、上下文变长时提示词的影响力会指数下降。举个例子。你让Kiro清理一下不再使用的测试环境如果权限全部放行它可能会尝试删除包含其他项目资源在内的整个资源组。它认为的测试环境和你在AWS控制台里规划的资源边界不一定一致。这种边界认知偏差在没有权限拦截的情况下就会被直接放大成事故。还有一个隐蔽的风险是权限提升。假设当前Agent使用的IAM用户只能操作EC2但你的黑名单或放行模式下命令执行是local shell。攻击者如果能向Agent注入恶意命令或者在某个接口返回里放一段隐藏指令模型有概率会执行它。一旦执行了不是通过AWS CLI而是直接在Shell上的命令比如curl | bash那这台机器本身就可能被控制后面什么权限都不好使了。所以我的建议是即便在本地开发环境也至少要开确认模式让高危命令必须人工批准。不要为了省事把所有开关都关上。4.3 最小权限原则怎么落地把最小权限原则落地到Kiro的权限设计里我总结了一套可行的做法。第一步给Kiro准备独立的IAM账号或角色不要直接用Admin级凭证。这个身份只需要配置最小权限比如它要做资源盘点那就只给ec2:Describe*类只读权限要做发布操作就给对应服务的最细粒度权限。权限不够导致的报错应该通过IAM策略迭代来解决而不是直接给一个宽松策略。第二步在工具注册表层面区分只读工具和写操作工具。只读工具有ec2_describe、s3_list、cloudwatch_get_metric写操作工具有ec2_create、s3_put、lambda_invoke。权限校验器会在执行前判断当前操作是读还是写写操作强制走确认流程或者MFA验证。第三步命令执行加一层Shell审计。所有通过Agent执行的命令行都要输出成日志文件带上命令内容、执行身份、执行时间、结果摘要。这不是为了事后追责而是为了出问题时你能定位到是哪条命令、哪个决策链导致的。第四步定时收敛配置。即使你初始配置了最小权限跑了一段时间后可能因为加了新功能权限悄悄变宽。每季度做一次权限审计把不再使用的策略删掉。反正Kiro这类工具的理念就是用对话完成操作权限文件频繁变更也没有太大维护成本。5. 与Claude Code、Pi Agent、Hermes Agent的横向对比只看Kiro一家可能很难判断它的架构特点。我把它放在当前Agent生态里跟几个常见框架一起比较大家各自的定位就清晰了。5.1 定位和形态的差异Claude Code是Anthropic官方的编码Agent主打在终端里辅助写代码读代码库、改文件、跑测试。它的工具集围绕代码理解和编辑设计。Pi Agent则是一个更偏执行和自动化的Agent支持更广泛的系统操作。Hermes Agent的定位偏本地部署和推理强调可以在低算力环境下跑起来。Kiro的差异化在于它把底座建在AWS上工具集主要围绕云资源管理类比的话就像是为云原生运营场景专门调校过的触手。这几种Agent在架构上的共性很明显都是意图理解 工具调用 结果回环的Agent框架都遵循基础Agent的核心模式。区别在于工具集的宽度和深度。Claude Code把文件读写、代码检索、命令执行这组编码工具做得很深Kiro则把AWS服务的调用链做得很完善。前者的定位是编码助手后者的定位是云上运维助手。5.2 Skill与Agent的区别聊Agent框架绕不开Skill技能这个概念很多人弄不清楚Skill和Agent的区别。简单说Skill是Agent身上的一组可复用能力包比如EC2管理技能、S3管理技能Agent是具备编排、调度、决策能力的运行时。一个Agent可以挂载多个SkillSkill之间是平级的Agent则负责在合适的时机选择合适的Skill。我用一个生活化类比Agent是店长Skill是店里各项业务流程的标准作业手册。店长能根据当天情况决定按哪本手册干活也能同时调用多本手册协作但他自己并不直接拥有手册里的具体技能。所以你在设计Kiro这类框架时要把每个Skill做得够内聚然后在Agent层通过描述来引导模型选择。Skill做得好不好直接决定了Agent整体能力的上限。5.3 Harness与Agent的区别再一个常见概念是Harness。如果你搜过相关关键词可能看到harness agent这类说法。在Agent框架里Harness通常指运行Agent的脚手架和配线系统包含命令执行、日志采集、安全隔离、上下文传递这些基础设施。Agent是大脑Harness是身体的骨架和神经。区别就在于Agent决定了做什么、按什么顺序做Harness保证了能不能做、做了怎么记录、出了事怎么隔离。一个没有Harness的Agent框架相当于大脑直接连着肌肉没有骨骼保护也没有神经系统感知疼痛。在Kiro架构里提醒你设置超时、做日志审计、做权限隔离这些都属于Harness层的职责。5.4 什么场景选什么框架我自己的选择经验大致是这样你主要是写业务代码、需要终端里辅助编程Claude Code是最顺手的它的上下文管理非常成熟。你要做的是自动化执行多条系统命令、按流程跑任务Pi Agent这种偏执行的框架更能顶住。你有隐私或算力限制希望Agent和模型都本地部署Hermes Agent这类能做本地推理的更合适。你的核心战场是AWS要经常跟EC2、S3、Lambda、CloudWatch打交道Kiro这种云底座Agent更对口。当然现在很多框架已经互相借鉴这些边界也在模糊。但架构设计上仍然有各自的倾向性底层对应的应用场景和风险模型不同。6. 从零部署与上手踩坑排查架构原理讲了一堆最后落地上手才是硬道理。这一节把从零跑通Kiro的过程和容易翻车的环节都过一遍。6.1 环境准备在开始之前确保你的环境满足这几项基础要求Python 3.10以上终端环境macOS/Linux更合适Windows建议用WSL已安装并配置好AWS CLI可以通过aws sts get-caller-identity确认身份有效一个可用的模型API Key支持OpenAI接口格式的模型或者Claude接口格式本地有网络访问云服务的能力我个人部署时踩的第一个坑就是AWS CLI的Region没设置导致查询时不在预期区域。建议在项目目录里统一维护一个配置文件把region和profile写死避免依赖环境变量的隐式默认值。6.2 安装与初始化流程安装Kiro如果是走Python包方式通常就是一条命令pip install kiro-agent不过更稳的做法是创建虚拟环境再装避免和系统Python环境打架python3 -m venv kiro-venv source kiro-venv/bin/activate pip install kiro-agent装完以后先做配置初始化生成配置目录kiro init这一步会创建配置文件、默认的会话目录和日志目录。初始化完成后要做的第一件事是把模型接口配好。Kiro支持配置模型API端点、模型名称、API Key。如果你想用Claude Code体验过的模型接口只需要把端点地址和模型名填进去就行。原理就是之前说的模型层接口抽象底层换成Claude模型不用改上层任何逻辑。验证配置是否成功建议先跑一个只读任务kiro 查看当前账号ID和我所在的区域如果返回了正常结果说明链路通了如果返回错误根据错误类型做定位权限问题检查IAM网络问题检查Route53和Security Group模型问题检查API Key和模型名称。6.3 命令执行权限的设置实践把基础链路跑通以后我强烈建议先不要急着放开执行权限。按照安全原则第一版配置先使用白名单模式并且只往白名单里登记只读的查询命令。Kiro的配置文件里白名单和黑名单的配置结构大体是这样的permissions: mode: whitelist # whitelist / confirm / blacklist / allow_all whitelist: - aws ec2 describe-instances - aws s3 ls - aws cloudwatch get-metric-statistics confirm_commands: - aws ec2 stop-instances - aws s3 rm - aws iam * blacklist: - rm -rf - aws iam delete-*这个配置的含义很清晰默认只允许白名单里的命令如果遇到确认列表里的高危命令会停下来问用户是否执行黑名单里的命令无论如何都不执行。当你对Agent的决策有信心了再逐步扩大白名单范围但全部放行那个选项还是慎重使用为好。配置完成后用一条写操作命令验证权限控制是否生效kiro 停止我用Test开头的那个EC2实例如果配置正确Kiro应该会打印一条需要确认的提示等待你手动输入y或n。它不会直接执行这条操作。看到这个表现你就知道权限控制是在真实生效的。6.4 常见错误的排查链路在社区类似工具的使用里最高频的一个错误信息是Agent execution terminated due to error.。这条提示非常笼统定位问题得一步步排查。我从实际操作出发把排查链路整理成一个有序流程第一步看日志。Kiro在初始化时已经生成了日志目录一般会记录每一步工具调用的请求和响应。打开最新日志找到终止前最后一次完整的动作看看它是权限错误、网络错误还是模型返回异常。第二步确认当前身份和权限。检查一下Kiro进程实际使用的AWS身份是不是你预期中的那个kiro 执行 aws sts get-caller-identity如果这步都失败说明Agent没拿到有效凭证或者凭证角色没有执行这个查询的权限。第三步检查工具参数是否合法。Agent生成的命令参数偶尔会不合法比如把一个不存在的InstanceID传给了工具。这种情况下工具执行会报错Agent在看到报错后如果重试还是同样参数就会触达重试上限最终因失败而终止。处理方式是缩小任务范围或者直接指定更明确的参数。第四步检查上下文长度。随着对话越来越长超出模型上下文窗口会导致请求失败。后续会话如果一直参考旧内容也容易导致模型决策紊乱。解决办法是开始一个新会话或者开启上下文摘要功能。我把这些排查内容整理成表格方便你对照错误现象可能原因排查方向命令执行失败但Agent继续跑工具返回了非零退出码看日志里的具体命令输出同一错误反复重试后终止工具输出异常、模型没理解报错检查工具描述是否需要补充常见错误解释权限报错IAM策略不足用AWS控制台查具体操作的权限要求模型接口超时API端点不可达或模型负载高换轻量模型或加大超时配置上下文超长历史消息过多新开会话或开启摘要6.5 记忆机制对多轮任务的影响最后讲一个用户经常忽略的部分Agent的记忆。Kiro既然有会话概念就有历史消息的存储和回传机制。这会影响两件事一是多轮对话的连贯性二是长时间任务的成本。会话刚开始的时候历史消息比较少模型聚焦在刚讨论的任务上指令跟随质量很高。但对话超过十几轮后模型容易被历史信息干扰抓不住最新意图。我建议在复杂任务里尽量把需求一次说完整避免拆成很多轮补丁式指令。帮我查一个EC2就那个昨天说的这种模糊引用很容易让模型选错实例。相反给一份明确的信息比如实例ID、资源名称、时间范围Agent的准确率会高一个台阶。另外还要注意Kiro会把工具执行的详细信息塞进上下文。比如你已经查了十几次EC2状态每次查询的JSON输出都在历史里后面的请求都会被这些旧输出占据上下文窗口。会话一旦变得卡顿优先考虑开新会话而不是继续追加对话。7. 一个亲身经历让Kiro自动清理临时资源讲了这么多理论我分享一个自己在项目里实际用Kiro的场景能帮你更具体地理解架构里每层是怎么协作的。当时我有一批CloudFormation栈创建出来的临时测试环境由于反复调试环境里堆了几十个失去价值的堆栈手动清理非常费劲。我用Kiro挂载了CloudFormation相关的Skill权限设为确认模式然后发了一条指令找出所有名称带tmp-前缀、且最后更新时间超过三天的CloudFormation堆栈列出它们的资源列表然后问我是否删除。Kiro的执行链路是这样的它先通过工具列出全部堆栈按条件过滤出17个符合条件的堆栈然后逐个调用描述堆栈资源的工具把每个堆栈的资源整理成摘要最后在终端里打印了一张汇总表并询问我是否执行删除。我确认后它逐个执行删除每删除一个就验证一次删除状态失败的堆栈单独记录原因。这里值得留意的是Agent没有在一开始就直接删东西而是先列表-摘要-确认-删除-验证这套流程。这个行为不是模型天然会有的是把工具描述和权限提示词都设计好后的结果。我在CloudFormation Skill的提示词里明确写了删除是高风险操作必须先展示计划和影响范围获得用户确认后再执行。这些约束就像给Agent装上了肌肉记忆让它在正确的轨道上做决策。后来我又让它对比删除前后的堆栈列表确认清理工作完整。整个过程大概十分钟比我手写脚本快多了而且每一步都有日志后续审计也有依据。8. Kiro这种架构的下一步演进方向聊到最后我想说说这类架构接下来会往哪走也算给你后续自己改造项目一个方向参考。现在Kiro这种CLI Agent最大的瓶颈我认为是单会话、单任务的局限。它默认是一个用户在一个会话里完成任务缺少并发和协同能力。下一步比较自然的演进方向是任务队列把一堆指令排队执行每个任务独立追踪进度完成后汇总报告。这就把它从交互工具变成了一个可以嵌入自动化流水线的调度器。第二个方向是记忆的分层。现在的记忆基本就是会话历史模型要拿就走不要就丢。更合理的做法是把记忆分成工作记忆和长期记忆工作记忆保存当前任务相关的状态长期记忆保存多次执行后沉淀下来的经验比如这个VPC的网段冲突是因为和另一个环境的CIDR重叠。有了长期记忆Agent在后续任务里就不会重复踩同一个坑。第三个方向是策略化权限。现在的权限配置是静态的白名单和黑名单是固定的。更理想的做法是权限决策跟场景绑定同一个aws s3 rm命令在测试账号里被允许执行在生产账号里就必须走审批流。通过给每个工具调用附加一个风险评估器根据环境标签和资源类型动态判断该不该放行这才是企业级Agent该有的安全形态。我自己在实际落地中最大的体会是Agent能不能在云上真正替代一部分人的工作拼的不是模型多聪明而是它的编排层、工具层、权限层这些周边设施够不够扎实。Kiro的架构已经把这套骨架搭起来了接下来就是在这些方向上不断加肉。如果你正准备在自己的AWS环境里跑一个Agent项目我建议你先拿Kiro这类框架起步把架构跑通再去定制自己的Skill和权限策略比自己从零造轮子稳得多。