<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>Well-Architected on AI博士 万戈</title>
        <link>https://www.yesmiracle.net/tags/well-architected/</link>
        <description>AI博士万戈的技术博客，聚焦 Agentic AI、AI Infra 与 Agent Security，分享 AI 基础设施与工程落地实践。</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>zh-cn</language>
        <managingEditor>admin@yesmiracle.net (万戈)</managingEditor>
        <webMaster>admin@yesmiracle.net (万戈)</webMaster>
        <lastBuildDate>Sat, 03 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.yesmiracle.net/tags/well-architected/index.xml" rel="self" type="application/rss+xml" /><item>
        <title>AWS 出手了！Well-Architected Agent 上线——AI 云架构师自动体检，65&#43; 服务 4 大支柱连修复代码一起给！</title>
        <link>https://www.yesmiracle.net/post/20261003-aws-well-architected-agent/</link>
        <pubDate>Sat, 03 Oct 2026 00:00:00 +0000</pubDate>
        <author>admin@yesmiracle.net (万戈)</author>
        <guid>https://www.yesmiracle.net/post/20261003-aws-well-architected-agent/</guid>
        <description>&lt;img src="https://www.yesmiracle.net/post/20261003-aws-well-architected-agent/cover.svg" alt="Featured image of post AWS 出手了！Well-Architected Agent 上线——AI 云架构师自动体检，65&#43; 服务 4 大支柱连修复代码一起给！" /&gt;&lt;p&gt;如果你负责过任何一套跑在 AWS 上的生产系统，下面这个场景应该不陌生：账单下个月又涨了，安全团队丢来一份几十页的检查清单，老板问你「这套架构到底行不行」，而你手上只有 Trusted Advisor 那几条不痛不痒的通用建议。&lt;/p&gt;
&lt;p&gt;10 月 1 日，AWS 干脆把这个环节交给了一个 Agent。&lt;/p&gt;
&lt;p&gt;在 AWS News Blog 的一篇公告里，AWS 发布了 &lt;strong&gt;AWS Well-Architected Agent&lt;/strong&gt; 的公开预览（public preview）。一句话概括：它像一个经验丰富的云架构师那样，自动把你 AWS 环境里的资源、利用率和应用拓扑扫一遍，然后按成本、安全、性能、韧性四大支柱给出有上下文、能排序、可落地的优化建议。&lt;/p&gt;
&lt;p&gt;不是那种放之四海皆准的通用 checklist，而是带着你业务目标一起看的建议。&lt;/p&gt;
&lt;h2 id=&#34;它到底在做什么&#34;&gt;它到底在做什么&lt;/h2&gt;
&lt;p&gt;官方对它的描述是「分析你的 AWS 环境，交付有针对性的、上下文相关的建议」。拆开看，它做三件事：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;自动把利用率指标、资源配置、应用拓扑关联起来分析&lt;/li&gt;
&lt;li&gt;对照 Well-Architected 最佳实践做评估，覆盖 &lt;strong&gt;65+ 个 AWS 服务&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;每一条发现都带一份「实施包」——不只是告诉你有问题，还告诉你该怎么改&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;我比较在意的是最后一点。这类工具过去最大的毛病就是「诊断很准，处方很虚」：它告诉你某台实例利用率低，但要不要换、换成什么规格、代码怎么调整，全靠你自己琢磨。Well-Architected Agent 想补上的，正是这中间的断层。&lt;/p&gt;
&lt;h2 id=&#34;三个核心能力&#34;&gt;三个核心能力&lt;/h2&gt;
&lt;h3 id=&#34;目标对齐先有目标才排得出优先级&#34;&gt;目标对齐：先有目标，才排得出优先级&lt;/h3&gt;
&lt;p&gt;你先声明业务目标（比如「这个应用要控成本」「那个系统要保可用性」），Agent 再按这些目标，把建议按「影响」和「工作量」两个维度排序。同一套环境，目标不一样，排出来的优先级也不一样。&lt;/p&gt;
&lt;p&gt;这点其实挺关键的——过去工具给你一串红色告警，但哪个先动手得靠猜。现在它能替你把这串告警排成一条路线。&lt;/p&gt;
&lt;h3 id=&#34;三层递进的建议从一台实例到整个架构&#34;&gt;三层递进的建议：从一台实例到整个架构&lt;/h3&gt;
&lt;p&gt;这是全文最有干货的部分，它把建议分成了三个粒度：&lt;/p&gt;
&lt;table&gt;
  &lt;thead&gt;
      &lt;tr&gt;
          &lt;th&gt;层级&lt;/th&gt;
          &lt;th&gt;内容&lt;/th&gt;
          &lt;th&gt;适用场景&lt;/th&gt;
      &lt;/tr&gt;
  &lt;/thead&gt;
  &lt;tbody&gt;
      &lt;tr&gt;
          &lt;td&gt;单资源配置&lt;/td&gt;
          &lt;td&gt;具体资源的发现 + 具体的美元影响 + 分步修复&lt;/td&gt;
          &lt;td&gt;精准定位到某台实例、某个 bucket&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;应用级汇总&lt;/td&gt;
          &lt;td&gt;跨多个资源、按应用聚合的发现&lt;/td&gt;
          &lt;td&gt;看一个应用整体的健康度&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;架构级模式&lt;/td&gt;
          &lt;td&gt;架构设计层面的模式与建议，附 IaC 代码改动&lt;/td&gt;
          &lt;td&gt;需要动 Terraform / CDK 的场景&lt;/td&gt;
      &lt;/tr&gt;
  &lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;那个「具体的美元影响」值得单独拎出来说——它把技术问题和钱直接挂钩。真正推动改动落地的时候，一句「这个能用回多少成本」往往比任何技术指标都好使。&lt;/p&gt;
&lt;h3 id=&#34;修复方式自由选&#34;&gt;修复方式自由选&lt;/h3&gt;
&lt;p&gt;你可以跟着控制台的 walk-through 一步步点，也可以直接拿走更新后的 IaC 模板（比如一份改好的 CDK 函数，复制进代码库就能用），还能用 AWS CLI 命令自己跑。三条路随便挑，不用被绑死在某个界面里。&lt;/p&gt;
&lt;h2 id=&#34;怎么用起来&#34;&gt;怎么用起来&lt;/h2&gt;
&lt;p&gt;上手路径不复杂，我理了一下顺序：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;创建 agent profile&lt;/strong&gt;：指定要监控哪些 AWS 账号 / 区域、聚焦哪些优化支柱（成本 / 性能 / 韧性 / 安全）、需要什么权限&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;配好 IAM 角色&lt;/strong&gt;：用客户自管的 role，给 Agent 读取资源配置、利用率指标、应用拓扑的权限&lt;/li&gt;
&lt;li&gt;创建 profile 后 &lt;strong&gt;24 小时内&lt;/strong&gt;，资源和应用的推荐就会生成&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;它还支持一个我觉得相当实用的场景：&lt;strong&gt;上线前的架构评审&lt;/strong&gt;。你可以把 Terraform、CloudFormation 或 CDK 项目打包成 .zip 传上去，选一个 Well-Architected lens，让 Agent 在部署之前就把问题挑出来。也就是说，问题可以在你按下 deploy 之前就暴露。&lt;/p&gt;
&lt;p&gt;另外你还能给应用补上下文——账号、区域、服务、标签，补得越细，建议越贴合。&lt;/p&gt;
&lt;h2 id=&#34;一个不能忽略的细节它不会自己动手&#34;&gt;一个不能忽略的细节：它不会自己动手&lt;/h2&gt;
&lt;p&gt;这一点得说清楚，免得被「AI 云架构师」这种说法带偏。&lt;/p&gt;
&lt;p&gt;公告从头到尾，都没有说 Agent 会自主应用变更。它给的是建议、是要改的 IaC 代码、是 CLI 命令——&lt;strong&gt;改不改、怎么改，还是你按下那个键&lt;/strong&gt;。官方在「Things to know」里也明确写了：生成式 AI 产生的建议可能包含错误或不完整的信息，你需要在自己的上下文里评估，并做好 oversight。&lt;/p&gt;
&lt;p&gt;从工具定位上看，AWS 这个分寸拿捏得算克制。毕竟在云上，「让 AI 自动改生产环境」这件事，谁都还不敢真放手。&lt;/p&gt;
&lt;h2 id=&#34;它和-trusted-advisorwell-architected-tool-是什么关系&#34;&gt;它和 Trusted Advisor、Well-Architected Tool 是什么关系&lt;/h2&gt;
&lt;p&gt;有人会问：AWS 不是早就有 Well-Architected Tool 和 Trusted Advisor 了吗？&lt;/p&gt;
&lt;p&gt;按外媒的解读，Well-Architected Agent 更像是这两个工具的「下一代进化」——把过去需要人工逐项对照的评审流程，交给 Agent 自动跑。而老工具并没有下架，官方说得很明确：你仍然可以用 Well-Architected Tool 做人工评估，配合自定义 lens 来衡量你自己的最佳实践。&lt;/p&gt;
&lt;p&gt;简单说，老工具是「表格 + 人工」，新 Agent 是「AI + 自动 + 带代码」。&lt;/p&gt;
&lt;h2 id=&#34;写在最后&#34;&gt;写在最后&lt;/h2&gt;
&lt;p&gt;把这条新闻放回 AWS 这两年的脉络里看，意思会更清楚。今年 7 月我写过 &lt;a class=&#34;link&#34; href=&#34;https://www.yesmiracle.net/post/20260713-aws-devops-agent-release-management/&#34; &gt;《代码爆炸了！AWS DevOps Agent 新增 AI 发布管理》&lt;/a&gt;——当时 AWS 用 DevOps Agent 去堵&lt;strong&gt;发布环节&lt;/strong&gt;的缺口。现在，它用 Well-Architected Agent 去堵&lt;strong&gt;架构审查环节&lt;/strong&gt;的缺口。&lt;/p&gt;
&lt;p&gt;两条线拼在一起，AWS 的算盘就摆明了：把云上从「写代码 → 审代码 → 发布 → 跑起来 → 回头看架构」这条链子，一环一环地 Agent 化。&lt;/p&gt;
&lt;p&gt;当然，现阶段的它边界也很清楚：只在美东（弗吉尼亚）、美东（俄亥俄）、美西（俄勒冈）提供，而且只有买了 AWS Support 计划的客户能用——毕竟它本身就是 AWS Support 交付的。预览阶段，功能还会继续变。&lt;/p&gt;
&lt;p&gt;但方向已经摆出来了。以后「让 AI 帮你看看这套架构有没有问题」，可能真会像现在「让 AI 帮你写段代码」一样平常。&lt;/p&gt;
</description>
        </item>
        
    </channel>
</rss>
