使用AWS Agentic AI Lens自动化智能体AI Well-Architected审查

使用AWS Agentic AI Lens自动化智能体AI Well-Architected审查

💡 原文英文,约2000词,阅读约需8分钟。
📝

内容提要

Smarsh为审查其首个智能体工作负载,将AWS Well-Architected框架的Agentic AI Lens(含150项最佳实践)封装为Claude自定义技能,从GitHub仓库只读提取证据,数小时内生成带证据引用的审查工作簿。在两个测试仓库上验证,16项预期全部通过。审查发现网关鉴权被禁用、缺乏提示注入筛查等高风险缺口,并据此与AWS专家展开针对性深入讨论。

🔎

延伸解读

把审查框架变成可执行技能的关键设计

Smarsh 没有等待控制台原生支持,而是将 Agentic AI Lens 的 150 项最佳实践提取为结构化 JSON,并配合评估指南和确定性报告脚本,封装成 Claude 自定义技能。这种“镜头即数据、审查员即技能”的做法,让审查过程可版本化、可复用。其中,报告生成器会校验输入,未知条目或无效状态会中止构建,从而防止模型编造内容进入交付物。

先验证工具再信任结果

在正式审查前,Smarsh 用两个合成仓库测试技能本身:一个中等成熟度,一个故意粗糙且含硬编码凭证。带技能运行通过全部 16 项预期,而不带技能的基线仅通过 8 项,且产出的是 18 至 39 项不等的临时清单,缺乏镜头追溯性。评估集随技能一同发布,便于后续回归测试。这提示读者,自动化审查工具本身也需要被评估。

审查发现的高风险缺口与人工判断

实际审查在数小时内完成 150 项评估,发现网关入口鉴权被禁用、消息内容缺乏提示注入筛查、限流仍为 TODO、缺少自动化成本控制等高风险缺口。但技能并非替代人工:工程团队在复核中合并了若干条目,并依据仓库中未被自动发现的证据升级了一项结论。这说明自动化能提升覆盖面和一致性,但最终判断仍需结合团队对系统的实际了解。

从审查结果到更精准的 AWS 协作

审查还暴露出仓库无法回答的系统语义问题,例如 AgentCore 运行时的会话检查点持久性、InvokeAgentRuntime API 的重试与幂等语义、紧急停止代理调用的破窗模式等。Smarsh 没有安排泛泛的架构评审,而是将每个问题映射到具体检查项,形成有明确完成定义的深度工作会。这种以证据和缺口驱动的协作方式,比通用讨论更高效。

❓

Q&A

AWS Agentic AI Lens 是什么?它目前能直接在 Well-Architected Tool 里使用吗?

Agentic AI Lens 是 AWS Well-Architected Framework 的一部分,包含 150 项最佳实践,分布在 41 个问题和六大支柱中,每项都有风险等级和期望结果。它目前仅作为规范性指南提供,还不能在 AWS Well-Architected Tool 中作为透镜直接选择使用。

Smarsh 如何将 Agentic AI Lens 的审查过程自动化?

Smarsh 将 Agentic AI Lens 封装为一个 Claude 自定义技能,该技能包含三个组件:lens_data.json(全部 150 项最佳实践的结构化数据)、assessment-guide.md(五值状态评分标准、证据收集清单和诚实规则)以及 build_report.py(确定性 Python 脚本,用于生成格式化工作簿)。用户只需向 Claude 提供仓库地址并请求 Well-Architected 审查,技能便会以只读方式从 GitHub 仓库收集证据,评估所有 150 项最佳实践,并在数小时内生成带证据引用的审查工作簿。

Smarsh 如何验证这个自动化审查技能本身的可靠性?

Smarsh 构建了两个合成测试仓库:一个中等成熟的 LangGraph 风格工作负载和一个故意粗糙的概念验证(包含硬编码凭证和成本失控历史)。团队分别在有技能和无技能的情况下运行审查,每个仓库按 8 项可验证期望评分(如所有 150 项齐全、无空白状态、每个确定性状态都有证据引用、诚实校准、以及特定发现如硬编码凭证被标记)。使用技能时,16 项期望全部通过;无技能的基线运行仅通过 8 项,且生成的是 18-39 项临时清单,缺乏透镜可追溯性。评估集内置于技能中,支持持续回归测试。

首次对真实工作负载的审查发现了哪些高风险缺口?

审查发现的高风险缺口包括:网关入口授权器在记录的风险接受下禁用了身份验证;对受不良行为者影响的消息内容缺乏提示注入筛查;速率限制仅记录为 TODO;没有自动化成本控制。每个缺口都关联到具体的透镜项、证据和建议的补救措施。

审查结果如何帮助 Smarsh 更有效地与 AWS 专家互动?

审查后的分类整理揭示了一类仓库无法回答的系统语义问题,涉及 AWS 服务本身。团队没有预约一般性的架构审查,而是为 AWS 解决方案架构师构建了有针对性的议程,将每个问题映射到它将关闭的检查项。议程涵盖:AgentCore 运行时作为会话检查点存储的持久性和一致性、InvokeAgentRuntime API 的重试和幂等性语义、停止代理调用的紧急制动模式、用于筛查不可信内容的 Amazon Bedrock Guardrails 模式、Amazon Bedrock AgentCore 的渗透测试规则、以及针对代理运行时威胁检测的 Amazon GuardDuty 和 AWS CloudTrail 覆盖范围。深度探讨变成了有完成定义的工作会议。

Smarsh 计划如何进一步推广和集成这个审查技能?

Smarsh 计划:将该技能内部发布为代理工作负载的标准评估工具(已贡献到公司内部 AI-SDLC 插件市场,并已在第二个架构不同的代理仓库上运行);将审查嵌入软件开发生命周期,使 Well-Architected 检查在开发过程中持续运行,而非仅在最后作为一次性关卡;通过将审查工作簿作为项目里程碑和关卡流程的必需证据来强制执行治理,确保代理工作负载在上线前完成审查;并将“透镜即数据”模式扩展到其他 AWS Well-Architected 透镜和更多仓库,最终覆盖更广泛的应用组合。

🏷️

标签

➡️

继续阅读