先看两个数字。
第一个：用 Vibe Coding 做出应用的人里，有 63% 此前从未当过开发者。第二个：安克创新只用了十二个月，就把零星几个智能体扩成 600 多个流程 Agent，几乎覆盖了所有业务。
这两个数字其实说的是同一件事：造 Agent 的门槛，正在低到人人都能上手。
过去做应用，是 IT 部门一年精心上线几个系统；而现在，是每个业务负责人、每个一线员工，都在为自己手上的活儿随手造一个 Agent。建设的主体变成了“所有人”，应用数量自然就会快速增长。
但这也带来一个新问题：造 Agent 很容易，可要在企业级规模上真正落地，并不简单。
难就难在，它把企业逼到了一道“两难”选择题前——两条路，看着都不好走：
第一个选择是放任不管：那就会导致安全没有人审，同一个系统也可以被三个团队各接一遍，风险接口慢慢失控——你甚至不知道企业里跑了多少个 Agent。
第二个选择是对 Agent 逐个管控：但如果每个 Agent 都要评审、审计、上护栏，那么 IT 设施就会不堪重负，创新速度被完全卡住，成本也扛不住。
可问题是，在员工随手就能造 Agent 的时代，让 IT 去当每一道流程的守门人，本身就是个伪命题。所以纠结“管还是不管”，没有意义。
真正该问的是：按什么优先级、用什么方式来管？ 这，正是本届亚马逊云科技中国峰会想给出的答案。
我把亚马逊云科技在中国峰会上给出的产品架构体系，理解为一套服务企业的三层治理逻辑：
第一层，先做到让企业“看得见”——让企业要知道自己有什么 Agent、谁在建、接了哪些系统；
第二层，再做到让流程“看得清”——让业务要看清每个 Agent 在做什么、为什么这么做、有没有越权；
第三层，给关键 Agent 加“可靠性保障”。不是所有 Agent 都一视同仁地重投入，而是先识别关键场景，再把工程质量、安全验收和底层现代化补上。
这三层是层层递进的：先看见全局，才知道哪个 Agent 值得细看；先看清每个 Agent，才知道哪些关键场景需要上可靠性保障。 下面，我就顺着这条主线，一层层展开。
一、企业看得见——知道企业里有哪些 Agent、谁在建、接了什么
首先，Agent 治理的起点不是上护栏，而是要给企业建一张全局视图。
但这里有个反常识的地方：视图不能光靠“强制申报”。你越要求各团队上报，他们可能越把好用的东西藏在体系外。
想要建设统一的全局视图，只有一种解法——通过好用，让每个 Agent 建设行为自然汇聚进来。这需要两件事同时成立：第一个是入口足够统一，第二个是能力要足够强大。
关于“入口必须统一”这一点，亚马逊云科技给出的解法是 Amazon Quick——它不是给工程师的开发工具，而是给所有人的统一构建入口，一个面向业务部门、即插即用的 Agent 平台。
它的八个功能模块连成一条完整闭环：Spaces（统一数据访问）、Chat Agent（智能交互）、QuickSight（数据洞察）、Research（深度分析）、Flows（轻量自动化）、Automate（复杂流程）、Quick App（零代码建应用）、Create Deliverables（文档创作），从获取数据到交付成果全程贯通。
它要解决的不是“问答”，而是“把事干完”。亚马逊云科技内部的应用案例就是证明：销售团队跨站点扩张分析，从点击五十多次、耗时四小时，到压缩成十五分钟出完整报告，准备时间缩短 93%；Prime 配送团队每周一百小时的“数据搬砖”直接消失等。
Quick 背后还有一层“知识图谱”——一个能理解人员、文档、沟通与数据之间关系的 Agentic Search 层，它会随着每次查询持续学习。你在第一百天得到的答案，肯定会比第一天更好。这样一个会随使用变强的入口，对团队自然很有吸引力。
此外，光有统一入口还不够，能力也必须足够强大。
如果入口里的能力不行，团队照样会跑到体系外去找更好用的工具。这也是 Amazon Bedrock 的多模型选择成为整套体系前提的原因。Claude、OpenAI、Llama、Grok、Mistral、Amazon Nova，加上中国开发者最关注的 DeepSeek、Qwen3、MiniMax、Kimi、智谱 GLM，都能通过统一 API 接入。
当下，大多数模型三个月就会换代一次，今天最好的，明天有可能就成为第二名——Amazon Bedrock 平台可以让你始终站在选择权这一边，这也是让团队甘愿在体系内构建、而不出走的根本原因。
与此同时，AgentCore Gateway 统一工具接入后，各团队也不必把同一个系统重复对接三遍；多框架兼容（LangChain、LangGraph、Strands）也可以让工程团队继续用自己熟悉的工具，不强迫迁移，这样在管理层统一收口后，就能大幅降低推广阻力。
当前面“统一入口”和“能力足够强大”两者做到位后，企业落地效果就会很好。例如小鹏汽车的“灵犀”平台案例是最好的证明。小鹏汽车提出过一个反直觉的事实——效率不等于效能：单点 AI 工具能把写代码的速度提上去，但是整个集成、联调、测试、CI/CD 仍靠人工，部门整体效能并没提升。
直到他把建设行为统一收口到一个平台，Agent 规模化的复利才会真正显现出来。
目前，“灵犀”这套平台基于 Kiro、Bedrock 与 EKS，已经沉淀 700 多个 Skills、连接 400 多个 API 端点，AI 代码覆盖率部分部门超过 70%，累计跑完 14 万多个工作流，六个核心阶段成功率均超过 99.7%，交付代码零 P0/P1 缺陷。
小鹏在科技峰会上给这套平台的定位是——“一支永不下班的研发军团”。
走到这一步，企业“看得见”算是完成了。但接下来的问题是：一家企业可以知道自己有 600 个 Agent 在跑，但这个 Agent 的判断，该不该用，敢不敢用？依然是个问题。
二、流程看得清：看清每个 Agent 在做什么、有没有越权
如果说企业“看得见”解决的是“管理层敢不敢放手”，那么流程“看得清”解决的就是业务层“敢不敢真用”。前者看的是全局有多少 Agent，后者看的是每一个 Agent 内部到底在做什么。
实际上，对许多公司而言，目前 Agent 的首要问题，往往不是“不够聪明”，而是“不够可控”。
当它开始自主调用工具、访问数据、执行操作，企业高管心里想的是：它做了什么我不知道；它越权了我可能也不知道；出了事我找不到证据，也找不到人负责。
这也是 63% 的企业停留在试点阶段的原因——不是技术不行，是没有信任基础。这是企业里的一种信任债。
而且这笔债还在以指数级的速度增长。峰会上有个耐人寻味的观点：当前沿模型发现漏洞、串联攻击链的能力正指数级提升，安全团队的待办清单也随之指数级膨胀——模型越强，需要被看清、被管住的风险点就越多。信任债不会自己消失，只会越滚越大。
还这笔债，亚马逊云科技给出了三层解法。
第一层，行为可追溯（Observability）。AgentCore 的 Session、Trace、Span 多粒度自动采集，让 Agent 的每一步推理、每一个行动都端到端可查。出了问题不再是黑箱，而是可以精确回放：它在哪一步做了什么判断、调了哪个工具、返回了什么结果，全有记录。
第二层，边界可执行（Policy 加 Gateway 硬拦截）。更进一步的信任，来自“越权根本不可能发生”，而非“越权之后能查到”。
这里有个机制要讲清楚：Policy 的价值不是“让 Agent 知道规则”，而是“规则在 Agent 推理之外独立执行”。
以客服 Agent 的退款上限为例——Prompt 里写“最多退 100 块”，用户可以通过巧妙的话术说服它绕过；但在 AgentCore Policy 里硬性规定参数上限后，即便 Agent 被忽悠，Gateway 也会在工具执行前直接拦截。这种边界的设定，不是依赖 Agent 自律，而在执行层强制生效。
第三层，身份可识别。让每个 Agent 都有明确身份，接入企业现有的权限体系——哪个 Agent 能访问哪些数据，都有清晰的权限记录和审计路径。让 Agent 成为一个有身份、有边界、有责任归属的系统参与方。
可追溯、边界可执行、身份可识别，解决的是 Agent “能不能被看清、被约束、被追责”的问题。
但当 Agent 真正开始自主行动，风险不会等到上线后才发生，安全也不能再沿用“上线前审一次、出了事再审计”的老模式。因为一个被攻击、被诱导或发生误判的 Agent，可能在几秒钟内调用工具、改写数据、触发流程，对企业造成不可逆的伤害。
所以，安全不能再是上线前的一道关卡，而要前置到研发交付的每个环节、并持续进行。这正是亚马逊云科技推出安全产品家族 Amazon Continuum 所要解决的问题。
本质上，Continuum 是一套面向 Agent 时代、用于保护工作负载的综合安全工具集。它的渗透测试能力，可以按需运行具备完整上下文的 AI 测试——过去数周才能启动的渗透测试，如今数小时内即可完成，成本只是人工的一小部分；Amazon Continuum Threat Modeling 则能直接从 coding agent 生成威胁模型，无需切换上下文，并结合应用架构、源代码与设计文档，覆盖 STRIDE 六大类别的威胁与缓解措施；而面对“模型越强、漏洞 backlog 膨胀越快”的现实，Continuum for Code Vulnerabilities 专门用来消化这份不断累积的安全待办。
这样一套下来，内部可见的价值能让业务“把原本不敢交出去的事，现在敢交了”。
例如，Thomson Reuters 的平台工程团队基于 AgentCore 构建 Agentic 平台工程中枢后，运维自动化率达 70%，生产力提升十五倍。影石创新把剪辑这件“重活”交给了 AI：用户操作不到五秒，AI 几分钟自动成片，背后支撑千万级用户同时剪辑的大并发。
这些企业敢做这些业务的底气，正是他们反复强调的——亚马逊云科技“完善的 AI 治理体系，能让企业专注业务本身，而不用担心背后的风险。”
三、执行靠得住——Agent 的最后一关
未来，企业里的 Agent 只会越来越多，可靠性保障不可能平均用力。前两步建立的可见性，恰恰可以帮助企业识别：哪些 Agent 只是辅助工具，哪些已经进入关键流程，必须接受更全面的可靠性保障。
对于这批关键 Agent，亚马逊云科技把可靠性拆解到了四个方向：写得对、发得快、用得稳、地基牢。
写得对——代码质量（Kiro）。 AI 写代码极快，但快不一定等于好。代码生成已经很便宜了，但如果工具不懂你的环境、标准和架构，它只会“以指数级的速度制造技术债”。
为此，亚马逊云科技的 Kiro 产品专门从源头保证正确性：先把需求转化为清晰的需求说明、结构化设计和验证测试，再写第一行代码。小鹏“灵犀”平台正是这套“先定义、再实现、自动验证”理念的结果。
在灵犀平台上，缺陷自动修复时间从两天压缩到十分钟，同类 Bug 下次可秒级命中、全程无需真人介入。对一个扛着量产车研发的关键平台来说，这种“不仅少出错、还能快速自愈”的特性，才是它被企业团队信任的根本。
发得快——交付质量（DevOps Agent 加 Release Management）。 可靠性不仅仅在于代码本身，还在于它能不能安全地进生产。Agent 写码快十倍，流水线若还是老速度，动能照样卡死。Release Management 能在代码生成后自动接手：审查、拉环境、跑测试，在上线前就提前发现隐患。
一个真实例子是，开发者只是把某个参数改了个更易懂的名字，看似零风险，Release Management 的生产风险评估却在几秒内发现，这次改名会在多个引用同一参数的服务间造成隐性的破坏性变更，并附上修复建议和影响摘要，防患于未然。
用得稳——安全验收（Amazon Continuum）。 Amazon Continuum 把渗透测试、威胁建模、漏洞治理整合为一套面向 Agent 的安全能力，让原本数周的安全测试压缩到数小时，是关键 Agent 上生产前的最后一道安全验收。
地基牢——技术底座现代化（Amazon Transform）。 Agent 能不能跑稳，也取决于底下的地基是不是 AI-ready。但大量企业的遗留系统并不是——他们的代码库庞大、架构老化、技术债累积，这些“看不见的成本”也正卡着 AI 落地。
Amazon Transform 可以让企业实现遗留系统的现代化：例如，拜耳把数百个与 SQL Server 高度耦合的 .NET 遗留应用，用 Agentic AI 自动重构、迁移到 .NET 8 与 PostgreSQL，全球客户借此累计节省超过 160 万小时的人工现代化工作。
新发布的 Transform Continuous Modernization 可以把“被调用一次就结束”的工具变成“永不停歇的 Agent”：在 Agent 不断写出新代码的同时，它在后面持续发现技术债、修复、验证补丁，并从每次转换中学习。
到这里，三层治理逻辑才真正闭环：换句话说，Agent 的企业级落地，不是把一个个智能体造出来就结束了，而是要让它们在可见、可信、可靠的体系里运行。
四、结尾：能造只是开始，会管才是壁垒
回到最初的两个选择题。
放任与全管，也从来都不是真正的选择。真正的答案是分层治理——先建“企业看得见”，让管理层敢放手；再建“流程看得清”，让业务敢真用；最后针对关键应用，攻克可靠性，每一层都是下一层的地基。
企业 AI 竞争的下半场，拼的不再是谁用了最新的模型。模型会换代，工具会普及，真正难以复制的，是一套贯通“外部可见—内部可见—可靠性”的治理体系，以及企业把评估标准牢牢握在自己手里的能力。
这也是亚马逊云科技始终强调“任意模型、任意框架”的原因。它卖的从来不是某一个 Agent，而是让所有 Agent 都能被看清、被管住、被信任的那片土壤。
本届峰会的主题是“Agentic Now，Go Build”。Go Build 是一句面向所有人的号召。
但在全员皆 Builder 的时代，企业真正要补的下一课，是它背后那半句没说出口的话——
Go Govern。
