人人都是 Builder 的时代，企业的真正挑战是“怎么管”？

先看两个数字。 第一个：用 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 的每一步推理、每一个行动都端到端可查。出了问题不再是黑箱，而是可以精确回放：它在哪一步做了什么判断、调了哪个工具、返回了什么结果，全有记录。 第二层