夜雨聆风
全文约3432字，阅读约需7分钟，请仔细看看哦~
开始阅读正文
多年来我们都是本着以客户/用户为中心来构建产品的，因为我们认为产品最终是给人用的，所以要“以人为本”来考虑如何构建产品。产品是给人用的思路一直是正确的，但是现在，这个假设正在快速发生变化。
我们把几个事情串在一起来看一下：
一个是某AI手机尝试通过系统层智能助手绕开传统应用交互模式，但由于各大App的抵制，这个事情尚未成功，趋势已显而易见。
另一个是某头部企业发布的智能助手应用，以自研大模型为统一入口，整合了电商、本地生活、出行、支付等核心服务。该产品定位为生活消费场景的智能代理，支持通过自然对话完成跨应用操作。得益于其完整的应用生态，该方案较好地规避了此前同类产品面临的挑战。
还有一个是Openclaw，它的出现使得数字员工的可能性大大增强，甚至带动了特定硬件设备的销售增长，展现出AI应用对硬件市场的反哺效应。
所以，我们可以清楚的看到产品从给人用的假设正在快速演变成给机器（这里特指Agent）用的方向演进。或者至少是产品的构建现在既要考虑“用户友好”，还要开始考虑“机器友好”或“Agent友好”，而且这两个的比例会逐渐从以人使用为主，过度到以Agent使用为主。
我预测云服务的用户主体也会从 “人” 单维，转向 “人 + Agent” 双维，甚至在海量自动化场景中，Agent 会成为云服务的直接、高频消费主体。云服务面向 Agent 构建，本质是适配 AI 智能体成为新的服务交互者和资源使用者的产业变化，也是云服务从 “数字化基础设施” 升级为 “AI 原生基础设施” 的必然要求。
企业和开发者的核心需求是从人手动操作云资源的能力升级到更多自动化。之前很多自动化操作都是通过自动化脚本、通过Teraform等IaC的方式来自动化部署服务，但是这些都是需要事先人工编码或人工编排好流程，缺乏自主决策能力，也就是说自动化程度还可以进一步提高。通过 Agent可以实现云服务更高的自动化调用、批量执行、闭环运营。比如 Agent 自动调用云函数做数据处理、调用云服务器做模型推理、调用云存储做数据归档，这个过程中人是需求发起者，Agent 是直接的执行层和调用者，云服务若不适配 Agent，会成为自动化链路的 “断点”。
2、Agent 的使用特性与人类完全不同
传统云服务是适配人使用的，因此一般是非连续、低频次，并且需要可视化，交互友好，而Agent是连续、高频次、程序化、无感知，比如 Agent 可能每秒发起上千次 API 调用，而人每天的云操作可能就只有少数几次。传统云服务的设计（如可视化控制台、手动权限配置、非标准化接口）会让 Agent 的调用效率大打折扣，甚至无法落地。之前经常被诟病为“工程师设计的产品”对Agent来说反而不是一个突出的体验问题。
在多智能体协作、工业自动化、智能运维等 AI 原生场景，本质是 Agent 封装业务逻辑，云服务提供算力、存储等原子能力的协同模式。云服务的整体使用方式会发生变化，用户使用从传统的Console、API、命令行的途径，增加通过Agent的途径，这个就是华为云的智能助手。这个智能助手将是用户跟华为云交互的全新途径。Agent与云服务将相互加强，没有 Agent 的适配，云服务的能力无法被高效激活。
4、云服务的价值从“为人提供工具”升级为“为 Agent 提供基础设施”
云服务的重要价值是降低数字化和智能化的门槛，而Agent 是人类向 AI 时代过渡的核心载体。面向 Agent 构建云服务，本质是让云服务成为Agent 的能力底座，通过适配Agent，让人类无需掌握复杂的云操作，只需向Agent下达自然语言指令，就能实现云资源的按需使用，这是云服务易用性的终极体现。传统云服务的SPI分层也将演变成新的分层方式，原先的SPI三层将压缩成新的“New IaaS”，这些能力都将被Agent调用。之上再叠加Agent平台层，以及Agent应用层，如下图所示：
我们可以从下面几个方面来分析对云产品构建的影响。
1、除了用户友好，还要增加Agent友好的维度
云平台已经有了API接口，为什么还有提供MCP的服务方式？很多MCP的介绍中都拿USB接口作为统一标准的例子来解释提出MCP的目的，但是标准化只是一方面，另外很关键的一点是MCP是给Agent自动调用的，而不像传统API服务，主要是给程序员（人）使用的（API最终是被程序调用的，但是API的说明是给人看的）。而MCP是需要加上各种服务的元数据，使得这个MCP服务可以被自动发现，自动调用。
传统Open API实现了“语法/协议层面的标准化”（如 RESTful、OpenAPI 3.0 规范），但这种标准化是为 “人” 服务的 —— 规范的作用是让程序员能更清晰地理解接口、更高效地编写调用代码，而非让机器（Agent）能自主解析、自主调用。传统 Open API 的核心链路是程序员阅读自然语言文档（人理解）→ 解析接口规范（人判断）→ 编写代码硬编码调用逻辑（人实现）→ 程序执行调用。全程的决策者是人，服务的能力、适用场景、参数怎么填、异常怎么处理，都需要程序员提前理解并写死在代码里。哪怕有结构化的 OpenAPI 规范，也只是简化人的理解成本，而非让 Agent 能自主决策。规范里只有参数类型、请求方式、返回值格式，没有语义级的服务能力描述 ，Agent 无法直接解析。
MCP 的核心链路则是Agent 读取结构化元数据（机器解析）→ 自主认知服务能力/适用场景（机器决策）→ 自主填充参数/发起调用/处理异常（机器实现）→ 自主解析结果并复用（机器闭环）。全程的决策者是Agent，人只需要给 MCP 服务配置结构化、机器可解析的元数据，后续无任何人工介入。所以，MCP 的元数据体系比传统 API 的文档维度丰富得多，核心包含机器（Agent）能直接解析的语义层信息，而非单纯的语法层信息。这些元数据是结构化、机器可解析的，也是 Agent 能实现 “自动发现、自动决策、自动调用、自动闭环” 的基础。这是传统 Open API 完全不具备的能力，也是 MCP 的核心价值。所以从API到MCP就是一个典型的从用户友好到机器友好的例子。
2、云服务要提供MCP的服务方式
云服务的构建中，之前强调需要按照“API First”的原则来构建，理想的情况下，用户可以选择Console、API、CLI的任何一种方式与云服务进行交互和使用。我们通过一个API网关来提供云服务的API服务。那现在我们还需要提供一个MCP网关，然后通过这个网关来提供我们云服务的MCP服务。这些云服务的MCP服务底层可以是依赖之前的API服务，但是需要从Agent的维度补充上MCP的元数据。另外，如果要给Agent提供一个更好的体验，需要从Agent使用的维度设计一些更粗粒度的MCP服务，而不仅仅是把API进行一个简单的包装。
3、从高可用、高并发的维度审视云服务的设计
Agent调用服务的方式对动态弹性的要求会更高。Agent 的调用具有突发式、批量式特征（比如某一时刻 Agent 同时发起上万次模型推理调用），云服务需要提供毫秒级的响应速度、99.99% 以上的高可用等，且需避免接口限流、超时等问题导致 Agent 的自动化链路中断。对云服务的弹性要求比之前的Serverless还要更进一步。
4、身份认证与细粒度权限管控
与人员权限控制不同，Agent像数字员工，同时也是服务主体，需要为 Agent 配置独立的服务权限，并实现接口级或资源级的细粒度权限管控（比如某 Agent 仅能调用 “数据读取” 接口，无法调用 “数据删除” 接口），同时支持权限的自动化分配和回收，用来适配 Agent 的动态创建和销毁的情况。
5、面向 Agent 调用特性的计量与计费
之前在推动云服务的Serverless化建设的时候，一个同时开展的工作项就是需要改造原先云服务的计量计费模块。因为Serverless类云服务会产生大量的计量信息，超过了原先系统的处理能力。面向人的包年包月、按台/按存储量等计费方式，需要从面向 Agent的角度进行重新审视。不仅需要提供按调用量、按算力消耗、按会话时长、按原子能力使用次数等多种计费方式，还要同时提供机器可读的计费账单，让 Agent 能自主监控成本、调整调用策略。
除此之外，其他像日志、API和系统错误码的设计等都需要系统性思考如何提供机器友好的格式和信息，而非人类友好的文字格式和提示，让 Agent 能根据日志和错误码自主调整调用策略等。
从”用户友好“到”机器友好“实际在在很多领域都在发生了。比如我们把现代化的自动化工厂称为”Lightout（黑灯）“工厂，这个主要就是因为这个工厂在晚上不需要开灯，因为照明是给人用的，而自动化工厂中的机器人它们不需要照明。
我们构建产品，现在到了需要开始从“以人为中心的体验设计”，转向“以 Agent 为中心的工程化设计” 。人关注易用性、可视化、交互友好、低学习成本，Agent 关注标准化、高可用、高并发、可组合、自动化。对云服务来说，面向 Agent 构建云服务，不是一个可选的创新方向，而是云服务厂商在 AI 原生时代必须要做的事情。让云服务从 “人用的工具”，真正升级为 “Agent 能高效调用的 AI 原生基础设施”。谁能率先实现对 Agent 的深度适配，谁就能占据 AI 时代云服务的核心赛道!
-END-
