先说结论

2026年9月23日，云栖大会「Agent工程化：重构云接口，让 Agent 用好云、管好云」分论坛用一上午时间讲了一件事：当调用云的主体从工程师变成智能体，云需要被重新设计一次。阿里云开放平台负责人何登成（花名圭多）给出的两个对比案例是全场最硬的证据——创建一台ECS并部署Nginx，人工在控制台需要约24次操作、30分钟，换成千问办公加载阿里云MCP Server只需3次交互、3分钟；搭建企业级Landing Zone，人工需要427次交互、熟练者约200分钟，通过Open Agent只需3到6次人工参与、9到14分钟（何登成，[360s-600s]）。这不是线性提速，而是交互次数两个数量级的坍缩。但论坛真正想说的恰恰是后半句：效率问题被Agent解决之后，难题并没有消失，而是转移到了身份、权限、审计和概率模型固有的不可靠性上——阿里云高级技术专家欧阳晶引用评测数据称，即使是全球最顶尖的模型，在明确设置约束条件后，多轮对话中仍有约10%的概率不执行约束（[7800s-7920s]）。这10%，就是Agent进生产环境必须用工程手段围起来的那一部分。

一、交互的量级坍缩：从控制台、API到Agentic Interface

要理解这场论坛的分量，需要先看它所处的位置。何登成把云的接口史切成三个阶段：第一阶段是控制台，面向人，人在页面上点出云资源；第二阶段是API和SDK，面向程序，云从「给人用的云」变成「给应用用的云」；第三阶段就是现在，Agentic Interface（智能体接口）——面向能自主决策的Agent，人用自然语言下达目标，Agent理解意图、规划任务、调用工具（何登成，[240s-360s]）。产品专家李岗辰在下半场补了一个漂亮的类比：1968年鼠标出现，计算机第一次有了与人交互的界面；控制台受限于人的操作带宽，Open API把人从操作者变成编程者，而Agentic Interface要做的是把人的意图直接翻译成Agent可自主执行的路径（李岗辰，[4680s-4800s]）。

两个对比案例值得逐字记录。第一个案例是日常操作：在控制台创建ECS、部署Nginx、完成验收，团队同学完整模拟一遍，从资源选型、网络安全配置到创建部署、最终验证，共约24次操作、接近30分钟；对照组用千问办公（阿里云的办公Agent）加载MCP Server（模型上下文协议服务器，一个让Agent标准化调用外部工具的协议）做同样的事，3次交互、3分钟完成。何登成给出的量化结论是：交互次数下降87.5%，操作时长下降90%（[360s-480s]）。第二个案例更复杂，也更贴近企业现实：Landing Zone（阿里云面向企业的上云治理框架，含网络、身份安全等八个模块）。人工通过控制台搭建需要427次交互，熟练同学约200分钟，不熟练者「以天计」；改用Open Agent（开放平台提供的一站式云管理智能体）后，3到6次人工参与、9到14分钟完成整个编排，交互次数下降98%，时长下降93%到99%（何登成，[480s-600s]）。

高级产品专家刘自慧（花名知意）从用户侧解释了这组数字为什么重要。她的诊断是：过去这些年，行业持续降低的是「操作云」的门槛，但「规划云、理解云」的认知门槛一直没有填平——工具的提升降低的是手的难度，脑的难度没有降低。业务部门说「我要一个承载十万并发的环境」，翻译成具体的云产品、API、参数，这个翻译动作过去只能靠人。云上最熟悉云的那几个同事，70%的精力消耗在重复劳动里（刘自慧，[1560s-1800s]）。Agent的意义在于它第一次有机会吃掉这个翻译层：你说出业务目标，它理解意图、调工具、给结果。

但刘自慧也指出了一个容易被忽略的结构性问题：阿里云已经有网络Agent、数据库Agent、存储Agent，可对用户来说，学习成本没有消失，只是换了地方——这件事该找哪个Agent？在A Agent里聊了多轮的上下文，换到B Agent就断了；而云管理的问题大多不是单产品能闭环的（刘自慧，[1800s-2040s]）。这正是Open Agent这个统一入口要回答的问题，也埋下了下文关于「入口之争」的伏笔。

二、五层重构：把云翻译成Agent的母语

何登成把阿里云的Agent化改造概括为五层产品架构：自然语言输入层、Agent入口层（Coding Agent、千问办公、一方Agent如Open Agent）、场景化Skill与Plugin层、工具层（CLI、MCP）、以及阿里云持续建设多年的开放层（[600s-720s]）。拆开看，这套架构里最值得记录的是三件事。

**第一件是给API定标准。**开放平台提出Agent Cloud API Readiness（云API就绪度）标准，用统一尺度度量每一个API面向Agent操作时的能力，核心维度包括开放性、报错、幂等性——报错信息要能让Agent自愈，幂等性保证Agent重试不产生副作用（何登成，[720s-840s]）。这是个容易被外行低估的细节：过去API的报错是写给人看的，现在要写成Agent读得懂、能据此自我修复的形态。李岗辰的补充更具体：Agent在执行一个「在某区域用现有VPC创建特定规格ECS并打标签」的简单任务时，要回答region ID是什么、资源ID怎么找、四核十六G对应哪个规格族、哪些参数必填、报错后如何闭环——每一步答不上来就是死循环，烧token、烧时间、烧钱（李岗辰，[4920s-5040s]）。

**第二件是工具层的三个抓手。**其一是CLI（命令行工具）：何登成称过去一年阿里云CLI调用量与用户增长300%，且增长动力不是人敲黑屏，而是Agent直接调用CLI来完成云上管理（[840s-960s]）——他还观察到一个反常识现象：海外用户历来比国内用户更拥抱CLI。其二是MCP：阿里云在MCP标准发布后跟进（何登成称标准发布于「去年四月」、阿里云「六月」即提供支持并将API全面MCP化；据公开资料，MCP由Anthropic于2024年11月开源发布，讲者所述时间线与公开资料略有出入，疑为口误或转写偏差），到今年9月用户数同比增长3000%（[840s-960s]）。其三是Terraform（转写多处误作「telephone/Telefon」，据语境应为描述式基础设施工具Terraform）。李岗辰给出的口径与此交叉印证：CLI用户量一年翻了三到四倍，MCP用户量增长约三十倍（[5400s-5520s]）——3000%与三十倍，两个讲者的数字自洽。

**第三件是场景化封装与质量门槛。**原子工具和Agent可用能力之间还差一层场景化。阿里云把产品能力做成官方认证的Skill：何登成称官方Skill已超280个、覆盖84个产品类目、累计安装量超20万；李岗辰下半场给的口径是「三百多款Skills」（[960s-1080s]；[5400s-5520s]）——两个数字略有出入，可能统计时点不同，分别照录。每个Skill从生产到发布要经过多达11轮评测准出，并在CloudHub、skills.sh等多平台分发；开箱即用的官方Agent目前40个、覆盖10个产品类目（何登成，[960s-1200s]）。

Open Agent本身的设计哲学也值得单独一提。刘自慧介绍，Open Agent把云管理的本质归纳为「谁、有什么权限、操作什么资源」三类原子场景（身份、权限、资源），在其上封装Landing Zone、Well-Architected等复杂场景，再通过协同总线调度阿里云背后的其他Agent（[2040s-2280s]）。何登成则强调了三条工程底线：概率模型必须被约束成可控输出（采用形式化方法）、成本必须可预估、高风险操作必须引入人在环路（human in the loop）（[1200s-1440s]）。

三、身份是新的防线：三A与「百分之十」问题

如果说前两节是论坛的「能做」部分，身份权限就是「敢做」部分，也是全场信息密度最高的段落。

何登成在演讲收尾时点题：从开放层、工具层、场景化层到入口层都串起来之后，还缺一样东西——敢于把操作交给Agent的前提，是Agent的认证、授权与审计（三A，即Authentication、Authorization、Audit）。阿里云的方案是：每个一方Agent有独立身份、有自己的权限边界——用户哪怕同时拥有ECS、RDS、OSS权限，调用弹性计算Agent时也只能操作ECS；Agent Identity作为产品免费提供、开箱即用，并与主流Agent运行环境、沙箱无缝集成（何登成，[1320s-1560s]）。

欧阳晶（花名白菊）的演讲把这题拆得更透。她先给行业背景：据其引用的麦肯锡报告，大型企业中敢把Agent放进核心业务的比例已从27%升至今年的40%（欧阳晶，[7440s-7560s]）。然后是四个无法回避的问题：对话背后以什么身份执行？Agent为什么能访问我的VPC？高危操作的风险能否识别？出事后能否审计到「哪个用户用了哪个Agent」（[7560s-7680s]）。

她给出的两个反面方案都很有说服力。给Agent配统一Key，代价是所有用户复用同一身份，服务端无法区分；让Agent代理传递人的身份，则当一个人有成百上千个Agent时无法定位到具体是哪一个。权限同理：复用同一Agent权限，张三李四王五都是管理员，形成提权风险；复用用户本人权限，则员工入职后不断累积的权限会全部漏给Agent，Agent获得「原本不属于它的权限」（欧阳晶，[7680s-7920s]）。

最扎心的是那段关于概率模型的引用。欧阳晶称，根据τ-bench（转写作「top bench」，经查证为Sierra Research发布的Tool-Agent-User交互评测基准，专门测Agent在多轮对话中遵循策略的一致性）半年前的评测，即使全球最顶尖的模型，在设置好「实例释放必须人工确认」这类约束后，多轮对话中约90%的情况会遵守约束，但仍有约10%的概率不执行——这10%可能是一次敏感数据访问，也可能是一次线上实例释放，是生产环境无法承受的（[7800s-7920s]）。她的结论因此非常工程化：风险确认必须是百分百可靠的确定性规则，不能建立在概率模型上。这解释了为什么Open Agent的执行约束采用「大模型判断+形式化交叉验证」双通道——大模型点头、数学验证也通过，才放行（刘自慧，[2760s-2880s]）。

研发侧的李志源（花名东山）用Demo把三A落了地，其中两个细节最能说明设计思路。一是权限随调用链路逐跳收缩：以用户权限为上限，Agent每调用一跳，权限只减不增，避免链路深处的权限放大。二是权限模型支持到业务参数粒度——Demo中L1权限可以退款但金额必须小于1000元：退800元直接成功，退1400元被拒，鉴权日志里清晰记录「哪个用户、通过哪个Agent、以什么业务参数、被允许或拒绝」（李志源，[8760s-9120s]）。演示中还有一个来自客户反馈的实用设计：企业维护两万个员工子账号已是极限，若每个Agent再配一个账号将翻倍到四万，因此阿里云推出了boundary policy（边界策略）——同一个runtime身份，按需临时收缩权限边界，managed agent场景下一千个Agent不必再建一千个role（朱明明Demo段，[6120s-6360s]）。

四、企业账本：达能、AutoMQ与跨境电商的三种算术

论坛的后半程属于用户，三家公司的落地叙事恰好构成三种不同的利益视角。

**达能：把专家经验从人身上剥下来。**达能大中华区和北亚基础架构负责人程辉（Kevin）的分享是全场最坦诚的企业视角。达能2025年营业额约273亿欧元、全球9万员工、产品销往120多个国家（节目称，与达能官网口径一致），中国是其全球第二大市场，8000名员工、8个生产基地（程辉，[3240s-3480s]）。他们2016、17年就开始用阿里云，目前99%的应用系统已上云、99%的云订阅在阿里云，2025年3月又与阿里云签署了战略合作（转写提及阿里方为「伟光总」，疑指阿里云高管，未确认）。程辉选基础架构做AI试验田的理由很务实：高频、规则相对清晰、结果易验证。三个场景的收益账本：资源测算方面，中型系统报价过去一个工程师要算4到6小时，现在Agent约20分钟出结果，且过程标准化、透明；日常巡检定义为只读任务，把不同系统对同一指标（如CPU使用率）的不同处理经验沉淀为可复用的组织资产；权限治理方面，过去发现闲置账号不敢动——不知道有没有隐藏调用——现在Agent基于日志、调用记录、最后访问时间提供全面风险分析，「最大的价值不是发现问题，而是给工程师足够的弹药去关闭风险」（程辉，[3960s-4440s]）。程辉的三个核心收益概括值得引用：工作方式更简单高效、专家经验沉淀为组织资产（核心成员流失不再意味着经验清零）、全链路可审计。他甚至直接讨论了生产关系变化：Agent接管重复运维后，MSP（托管服务商）必须转型去维护Agent、处理复杂故障与跨团队协作，内部专家团队则上移到制定红线、审批高风险变更、对架构和合规结果负责（程辉，[4320s-4560s]）。

**AutoMQ：让AI代替代码，而不是重写代码。**AutoMQ联合创始人兼CEO王小瑞（经查证为Apache RocketMQ创始人，AutoMQ构建在对象存储上的云原生Kafka）的命题最为激进。他的产品数据面内核约100万行代码，但要把数据面交付到用户VPC里、实现自动部署运维诊断，还需要约50万行交付层代码——这50万行涉及客户权限、身份、云管集成，还要对接多个云厂商，复杂度甚至超过数据面本身（王小瑞，[6480s-6720s]）。他尝试过用AI coding重写这50万行，发现维护的产物还是50万行代码，复杂度没有变。于是他换了命题：不是让AI写代码，而是让AI代替代码——「之前跑在CPU上的Java语言，今天跑在大模型上的自然语言」，类比当年汇编语言被高级语言替代（王小瑞，[6720s-6960s]）。具体架构：用户VPC里一个Kafka集群加一个Agent（独立ECS+RAM权限），爆炸半径完全由RAM权限控制——Kafka十台机器，Agent的资源范围就是这十台机器；专家经验被预训练成Skill（自然语言写就的边界约束：建集群必须指定VPC、必须建对象存储Bucket、必须设特定tag），替代原来用Java编排的逻辑（[6960s-7200s]）。他还分享了一个兜底机制：用户自己搞不定时，可以把Agent share给AutoMQ一个链接或临时身份，厂商代为对话修复——这大约占1%的场景。他坦言，阿里云这次发布的boundary policy、统一身份正是AutoMQ这类厂商的刚需，「我知道的有点晚了」（王小瑞，[6360s-6480s]）。

**跨境电商Sensor Group：以我为主，阿里云为辅。**最后一位讲者周亚斌（石继Sensor Group Infra负责人，「石继」为转写疑似写法，公司中文名无法外部确认）代表了自建派。这家公司做奢侈品跨境电商，节目称2025年中国线上奢侈品电商市场约千亿规模，公司营收约60亿，2026年在北美、日本、英国市场快速扩张；系统有上万个微服务、24小时服务硬指标，人力与技术成本会直接反映到商品价格上——这是他做AI Ops的原始动机（周亚斌，[9240s-9480s]）。他的架构立场与前面所有讲者都不同：企业自建控制面（业务拓扑、历史复盘、审批审计、Agent编排策略，「企业知识产权和必须核心控制的基础面」），阿里云提供可观测接口、数字员工、Open Agent等能力加速执行——「不是排他项，也不是二选一」（周亚斌，[9600s-9840s]）。生产案例包括：一次灰度发布导致支付渠道异常，多Agent工作流六步闭环——发现异常输出事件卡片、错误码聚集过滤噪声、链路闭合定位渠道、止损、定位技术根因、把案例回写为故障模板——注意第五步输出的是回滚建议而非执行回滚（周亚斌，[9960s-10080s]）；奢侈品行业按当季款决定服务密度，大促准备checklist被Skill化后，准备周期压缩到分钟级（[10080s-10200s]）。他的两句原则性总结掷地有声：安全治理决定AI Ops能不能进生产；自建AI Ops不要一开始就追求全自动，先打数据和知识地基，再开放半自动和低风险自动化（周亚斌，[10320s-10560s]）。整场论坛的最后落点也来自他：「以我为主，阿里云为辅」。

五、后果与边界：哪些仍未解决

把这场论坛的信息拼成地图，能看到清晰的收益分配，也能看到没有被回答的问题。

收益侧，效率坍缩是真实的，且随任务复杂度放大——简单任务降87.5%，复杂任务降98%。成本侧，Open Agent本身不独立计费，资源费用按对应Agent计费规则走，每月每账号赠送大模型免费额度，超出后绑定百炼API Key（刘自慧，[3000s-3120s]）——阿里云显然在用入口免费换生态锁定。

但边界同样清晰。**第一，10%问题没有被解决，只是被围起来了。**形式化验证、确定性规则、人在环路，这些是工程护栏而非模型进步；欧阳晶的言下之意是，在概率模型的本质改变之前，Agent的自主性必须被当作风险源设计。第二，数字口径存在内部出入：Skill数量280+与300+、CLI增长300%（调用量口径）与三到四倍（用户量口径），论坛现场没有统一，本文照录并分别归属。第三，讲者的时间线与公开资料有出入：MCP发布时间（讲者称去年四月，公开资料为2024年11月）；此类出入不影响核心论点，但提醒读者对节目内的自报数据保持校准心态。第四，认知门槛是消失还是转移，论坛内部其实有两种答案：刘自慧认为翻译层被Agent吃掉了；但王总（王小瑞）的「预训练Skill」、周亚斌的「知识单元编译」实质上都在说，经验没有消失，而是从人的脑中转移到了Skill与知识库的编写中——谁掌握这个编译过程，谁就掌握新的话语权。第五，生态位的重新谈判刚刚开始：程辉直言MSP行业会受到挑战，王小瑞的厂商视角则暗示，当交付层从代码变成Agent，软件厂商与云平台之间的能力边界（身份、权限、boundary policy这些「刚需」都来自云）正在向云侧倾斜。

六、读者启发：三条可迁移的链条

**链条一：接口的消费者变了，接口的设计标准就要重写。**机制：Agent消费API的方式（自然语言→意图→工具调用→自愈）与人/程序根本不同，因此报错信息、幂等性、渐进式发现（如CLI的–help体系）从「文档问题」变成「协议问题」。二阶影响：一个API是否「Agent Ready」会成为云产品竞争力的新维度，未改造的接口在Agent入口时代事实上不可见。启发：无论你做的是云服务还是内部平台，都值得问一句——我的接口报错是写给人看的还是写给Agent看的？把「Agent Cloud API Readiness」的三要素（开放性、报错、幂等性）当作自查清单，成本极低。

**链条二：概率模型 + 确定性护栏，是Agent进生产的唯一合法架构。**机制：顶尖模型在多轮对话中仍有约10%的概率无视约束（欧阳晶引用评测），因此高风险确认不能依赖prompt，必须落在形式化验证、权限系统、审计日志这类确定性机制上。二阶影响：Agent工程的重心从「让它更聪明」转向「给它画牢笼」——三A、boundary policy、逐跳权限收缩、人在环路这些「不性感」的基础设施成为投入主线；这也解释了为什么云厂商免费开放Agent Identity。启发：评估任何Agent方案，先别问任务完成率，先问约束违背时会发生什么、权限如何随调用链收缩、事后能否审计到「哪个用户通过哪个Agent做了什么」。答不上来的方案，离生产还远。

**链条三：专家经验正在从人身上剥离，沉淀为可分发的资产。**机制：巡检阈值、报价测算、部署边界这些过去存在于专家脑中的隐性知识，正被编译成Skill、知识单元、场景模板——达能把核心成员流失的经验损失转化为组织资产，AutoMQ把50万行交付代码替换为自然语言Skill，跨境电商把大促checklist变成Skill后准备周期降到分钟级。二阶影响：知识的所有权与定价权发生转移——官方Skill认证（11轮评测准出）意味着平台在替代企业做质量裁决，「以我为主阿里云为辅」的企业（如周亚斌所在公司）则在自建知识中台以保留控制权。启发：对个人，最值得焦虑的不是被Agent替代，而是你的经验是否已被结构化地拿走而你未获定价；对企业，现在就该盘点哪些隐性经验值得编译成Skill——这是未来Agent底座上真正属于你的部分。

**链条四（附）：交互坍缩的收益，要按任务复杂度来估算。**机制：论坛数据显示简单任务交互降87.5%、复杂任务降98%且时长降93-99%——任务越长、跨产品越多，Agent的编排优势越大；但反例是达能把巡检先限定为只读、周亚斌坚持输出建议而非执行回滚，说明高价值场景的落地速度反而取决于风险控制而非智能水平。启发：企业引入Agent管云，正确的排序是「先只读、再写操作带审批、最后才谈自动化」，与周亚斌的「不要一开始追求全自动」互为印证。

结语

这场论坛的完整标题是「让Agent用好云、管好云」，但一上午听下来，真正的主题其实是「让云管好Agent」：接口要为Agent重写，工具要为Agent调优，身份要为Agent重建，审计要能穿透到Agent背后的每一个人。何登成开场说云正在从「给人给程序用的云」变成「Agent Native的云」；周亚斌结尾说「以我为主，阿里云为辅」——这两句话放在一起，恰好是Agentic Cloud时代的完整张力：平台在努力成为Agent时代的水电煤，而最清醒的企业用户在努力确保，即使水电煤再方便，核心控制面仍握在自己手里。交互坍缩98%很诱人，但决定这场迁移速度的，从来不是那98%，而是剩下那2%——身份、权限、审计，和那10%必须被工程围起来的失控。

（注：本文事实与数字均出自论坛转写，按讲者归属标注时间段；「石继」「伟光总」「top bench」等转写疑似误写处已按语境校正或标注，未能确认者保留原文。转写中CLI多误作「COI」、Landing Zone误作「雷丁众/零零one」、Terraform误作「telephone」、τ-bench误作「top bench」，正文均已还原。）