今年 HUAWEI CONNECT 2026 的主题消息刚放出来时朋友圈里做云原生和 AI 应用的人几乎都在聊同一个词Agentic Cloud。当时我的第一反应是华为云终于把 Agent智能体这个过去一年里被反复讨论的概念正式提升到了云平台战略的核心位置。这和我过去一年在华为云上做 Agent 相关实验的感受是能对上的——算力、模型、数据这些基础能力已经慢慢齐了真正缺的是一个能让 Agent 顺畅生长、被统一调度的云环境。如果你和我一样既关注华为云的产品动态又不想停留在“看新闻”的阶段而是希望搞清楚 Agentic Cloud 到底是什么、底层有哪些技术支撑、自己能不能基于华为云快速搭一个能用的 Agent 智能助手那这篇文章应该对你有点用。我会先从这次大会主题背后的逻辑讲起再拆解技术底座最后用一套基于 DeepSeek 搭建 Agent 的完整实验过程带你把“Agentic Cloud”这个听起来很宏大的概念落到一台真实的华为云 ECS 上。1. 从“Cloud Native”到“Agentic Cloud”华为云到底在转什么弯1.1 HUAWEI CONNECT 2026 主题解读华为云的一次定位刷新HUAWEI CONNECT 是华为每年最重要的全联接大会过去几年主题一直围绕“智能世界”“加速行业智能化”这类大方向。这次把 Agentic Cloud 直接放进大会主题信号其实非常明确华为云希望对外传递的定位已经不再只是“算力底座”或“模型工场”而是“智能体生长的云”。怎么理解这个转变之前的云核心逻辑是“你租资源我来运维”不管你是跑网站、数据库还是训练模型云厂商提供的是计算、存储、网络这些原料。而 Agentic Cloud 的逻辑变成云平台不仅要提供原料还要提供“培育环境”——Agent 要能在这个环境里被创建、学习、调用工具、处理数据甚至自动申请和释放资源。从产品动作上看这个转向其实早有苗头。华为云这两年陆续推出的盘古大模型、昇腾 AI 云服务、以及围绕 Agent 开发推出的系列工具链都是 Agentic Cloud 这盘棋里的棋子。这次把它们统一到“Agentic Cloud”这个主题下面等于是官方盖了章今后的华为云会把智能体作为云上的一等公民来对待。1.2 为什么是“智能体”而不是继续堆算力我身边有个朋友问过一个问题国内云计算市场竞争这么激烈华为云有昇腾芯片算力是强项为什么不继续打算力牌反而要讲 Agentic Cloud这里面的逻辑我觉得要从客户需求的变化来理解。前两年大家拼的是“你 GPU 多不多、训练快不快”因为那时大家还在训大模型。可到了现在这个阶段大部分企业的痛点已经不是送训出一个基础模型而是“模型怎么真正用起来”。可 Agent 就是一种让大模型从“单轮对话工具”转变成“能独立完成复杂任务”的软件形态。它需要自主规划、调用工具、读取知识库、执行动作。这个需求单靠卖虚拟机、卖 GPU 是解决不了的。Agentic Cloud 的价值恰好在这里它把模型调用、知识库、工具注册、任务编排、资源调度这些东西从“开发者自己拼装”变成“云平台原生提供”。华为云在这个节点提出这个概念等于告诉市场你不只是买我的算力你更应该是用我这一整套环境来批量生产智能体。这一步棋其实是把一个拼配置的市场拉进了一个拼平台能力的市场。1.3 我和这次主题的对照过去一年在 Agent 落地时踩到的墙说实话我一开始对“Agentic Cloud”是有怀疑的。因为过去一年我自己为了在云上搭一套 Agent 服务确实踩了不少墙。举个例子单是把大模型部署到云服务器再通过 API 给到应用就涉及安全组、弹性 IP、模型显存估算、并发控制这些问题。等这些弄完了你又要单独搭向量数据库做知识库又要写工具调用的代码又要处理模型“胡言乱语”的问题。整个过程其实非常手工化根本谈不上“云原生”。正因为自己经历过这种碎活所以再回头看 HUAWEI CONNECT 2026 聚焦 Agentic Cloud我才意识到华为云想解决的正是这些“碎活”。它想把 Agent 的部署、编排、工具接入、监控运维提升为云平台的默认能力。这是一个比较大的范式转移背后需要一整套新的技术栈来支撑。2. Agentic Cloud 的技术底座拆解算力、模型、数据与服务编排2.1 算力层昇腾 AI 云服务与异构计算Agentic Cloud 首先需要算力支撑。Agent 不像传统的 Web 服务那样流量稳定它的算力消耗和任务复杂度强相关一个简单问答可能只消耗少量 token而一次复杂的多步推理可能需要在短时间内调动大量计算资源。这就要求云平台具备很强的弹性算力调度能力。华为云在这一层的核心是昇腾 AI 云服务。昇腾芯片这几年在训练和推理场景已经积累了不少实际案例尤其是推理场景昇腾的性价比表现越来越接近主流 GPU 的水平。基于昇腾的云服务可以按需提供训练和推理资源配合容器服务进行弹性伸缩基本上能覆盖 Agent 在不同阶段的算力波动。从实际配置经验来看个人做 Agent 实验不一定需要用到昇腾用一台普通的 ECS 就能跑通流程。但如果要做企业级的 Agent 服务推理算力、弹性伸缩、故障转移这些就必须纳入设计。Agentic Cloud 的意义就是把这一层技术风险吸收掉让你不用自己 K8s 集群管理和 GPU 调度。2.2 模型层盘古大模型 第三方模型开放Agent 的“大脑”是模型。华为云自己的盘古大模型从 NLP 到多模态已经覆盖了不少行业场景。但 Agentic Cloud 要想真正成为开放生态只靠自家模型是不够的。实际开发中用得更多是多种模型的组合调用。华为云目前的思路也比较务实盘古负责深度行业场景同时对第三方模型保持开放态度。近期社区里非常流行的 DeepSeek 系列模型也能通过多种方式部署在华为云的资源上。这种“第一方 第三方”的模型矩阵让开发者可以根据 Agent 的任务难度和成本预算灵活选型。我自己在实验中体会很深Agent 对模型的要求和聊天机器人不一样。聊天机器人只要回复流畅即可Agent 则需要模型具备准确的理解能力、稳定的指令遵循能力、以及可靠的工具调用Function Calling能力。因此你在选模型时不能只盯着跑分还要实测它在多轮任务中的稳定性。2.3 数据层云上数据空间与知识库工程Agent 真正产生价值的场景几乎都是需要结合企业内部数据的。比如客服助手要查订单库运维助手要翻日志库流程助手要读合同文档。没有数据支撑Agent 再聪明也只能回答通用问题。华为云在数据层的布局一方面强调数据空间的构建也就是让数据在安全合规的前提下能被Agent 有序地访问和使用。另一方面是向量数据库和知识库工程。简单说企业的非结构化文档会被分割、向量化之后存储Agent在回答问题是先去知识库里检索相关内容再结合大模型生成答案。这个环节我在实操中花的时间最多。因为知识库的质量直接决定 Agent 的回答质量不是把 PDF 传上去就完事。你要考虑文档解析的准确性、分块大小对检索结果的影响、向量化模型的选型、以及检索结果的重排策略。这些问题在 Agentic Cloud 的框架下将来会有更多平台级工具来简化但理解底层逻辑依然是必须的。2.4 服务编排层Agent 生命周期管理Agentic Cloud 里最“云原生”的部分是 Agent 的生命周期管理。一个 Agent 不能只是“在服务器上跑着一个 Python 脚本”它应该像微服务一样有版本管理、灰度发布、监控日志、弹性伸缩这些能力。华为云现有的云原生工具链其实都可以迁移到 Agent 场景容器服务负责跑 Agent 的运行时函数工作流负责响应外部事件API 网关负责统一对外接口云日志服务和监控服务负责把 Agent 的行为记录下来。把这些组件串起来就形成了一个能够支撑 Agent 从开发、测试、上线到运维的全套环境。我在搭建实验环境时虽然用的是比较轻量的方案但也刻意保留了“编排”的思想。比如 Agent 的工具调用通过 API 网关统一暴露事件触发通过函数工作流来实现日志统一上报到云日志服务。这样做的收益很直接后续想要扩展 Agent 能力不需要拆掉重来只需要在现有框架上加新工具。3. 实战在华为云上基于 DeepSeek 搭一个 Agent 智能助手3.1 方案选型为什么我选 ECS Ollama Dify概念聊得再多不如实际动手跑一个 Agent。这里我分享一套我实测过的方案技术栈是华为云 ECS Ollama DeepSeek 模型 Dify 平台。先说选型逻辑。DeepSeek 作为模型近期的表现已经不需要我多吹了。它最吸引我的是开源权重我可以把它部署在自己的云服务器上而不是每次调用都走闭源 API数据隐私和成本都可控。对于实验性质的 Agent这是非常合适的起点。Ollama 是我常用的本地模型运行工具。它几乎把模型部署简化为了一条命令支持 DeepSeek 系列模型还提供了兼容 OpenAI 的 API 接口方便后续和 Dify、LangChain 这类框架对接。Dify 则负责把模型变成一个真正的 Agent。它是开源的 LLMOps 平台提供了可视化的工作流编排、知识库管理、工具调用和 Agent 应用发布功能。用它可以省去大量前后端代码让我专注于验证 Agent 本身的逻辑。整套方案的好处是每一层都是业界主流的开源方案你学会之后完全可以迁移到其他云平台或本地环境。同时它也不依赖昂贵的 GPU 实例一台配置适中的 CPU 云服务器就能跑通流程。如果你想用更企业级的方式可以考虑用华为云的 CCE 容器引擎来部署这套环境配合弹性伸缩实现更高可用。但对于“跑通一个能用的 Agent”这个目标来说ECS 单机方案成本最低、排查也直接。3.2 环境准备与华为云产品配置的关键步骤接下来是实际操作。先说环境规划我会列出关键步骤和配置里容易卡住的地方。创建云服务器 ECS我选择的配置是2核8G本文实验区域选择靠近自己业务的可用区操作系统选择 Ubuntu 22.04 LTS。这里有个细节如果你想跑更大的 DeepSeek 模型比如 14B 甚至 32B建议直接上 4核16G 或更高配置否则量化后的模型也会很吃力。还想更流畅直接选择带 GPU 的实例比如华为云的加速型实例。购买时需要一并配置弹性公网 IP 和密钥对。记住密码登录虽然简单但生产环境强烈建议用密钥对。绑定弹性 IP 后记录下这个 IP 和实例 ID。配置安全组这一步是新手最容易踩坑的地方。创建 ECS 的时候华为云默认会分配一个安全组。你需要在这个安全组里配置入方向规则放通 22 端口用于 SSH 登录。放通 80 端口用于后续访问 Dify 的 Web 界面。放通 443 端口如果你要配置 HTTPS 访问。如果是实验环境可以暂时放通 3000、5000 这类应用常用端口但要谨慎生产环境不应该向全世界开放。这些都是入方向的配置。出方向默认是全部放通的不用特别改。安装 Docker 和 Docker ComposeDify 是依赖 Docker Compose 来启动的所以第一步是把 Docker 环境装好。在 Ubuntu 上执行安装命令时可以挑选国内可用的镜像源这样拉取镜像时速度会快很多不然你可能会在 pull 镜像这一步浪费很长时间。用 Ollama 拉取 DeepSeek 模型安装好 Ollama 后在终端执行ollama pull deepseek-r1:7b这里我选的是 7B 版本的模型因为 2核8G 的 CPU 实例要兼顾 Dify 和后面的 Agent 任务模型太大会直接 OOM。如果你的实例是 GPU 型建议选择更高版本的模型效果差距还是很明显的。拉取完成后查看一下 Ollama 的网络监听情况。Ollama 默认只监听 127.0.0.1如果 Dify 和 Ollama 在同一台机器上这个配置是合适的如果要跨机器访问需要把环境变量OLLAMA_HOST改成0.0.0.0但这样做必须同时用安全组限制访问来源否则你的模型服务相当于裸奔。启动 Dify 并完成初始配置用 Docker Compose 启动 Dify第一次启动需要拉取好几个镜像耐心等待。启动完成后访问http://你的弹性IP/install进入初始化页面设置管理员账号。这里有个细节如果你是在华为云的安全组里放通了 80 端口那直接用http://IP就能访问不需要写端口号。3.3 把 DeepSeek 接进 Dify 并发布成可用服务Dify 启动成功后就是整个实验的核心把 Ollama 里的 DeepSeek 模型配置到 Dify 中然后创建一个能用的 Agent 应用。添加模型供应商在 Dify 的设置页面里找到“模型供应商”选择 Ollama。填入模型名称要和拉取时一致基础 URL 填http://host.docker.internal:11434。这里要注意Dify 是跑在 Docker 容器里的所以你访问宿主机上的 Ollama 时不能用127.0.0.1而要用host.docker.internal。这个细节我在这上面卡了差不多半小时才反应过来。创建 Agent 应用模型接入后创建一个新应用应用类型选“Agent”。Dify 的 Agent 类型应用可以提供“思考 调用工具”的能力。在最简单的情况下你可以不加任何外部工具先测试它能不能顺畅对话。接下来可以给 Agent 加一个工具让智能助手具备实际做事能力。Dify 内置了一些工具比如网页搜索、计算器等。你也可以通过 OpenAI 工具协议接入自定义 API。实操中最常见的是接一个自定义 API 工具让 Agent 能够查询某个特定系统的数据。你需要提供一个描述清晰的 OpenAPI Schema模型才能知道什么时候该调用这个工具、参数怎么填。测试并发布在 Dify 的调试对话框里输入问题比如“帮我查询一下今天的订单量”然后观察 Agent 是否自动选择了正确的工具调用。如果一切正常就可以点击“发布”生成一个分享链接或者 API 密钥。通过 API 密钥你的 App 或客服系统就能直接调用这个Agent 了。到这里为止你已经有一个能在华为云上独立运行的 Agent 服务了。它的知识库可能还不够丰富工具也只接了一个但整体链路是通的从云资源、到模型推理、再到智能体应用发布全部跑在华为云的底座上。这个链路其实就是 Agentic Cloud 的最小原型。4. 配置 Agent 服务时最容易踩的四个坑及排查思路4.1 安全组和弹性 IP 的端口问题半天连不上有不少朋友复制我的方案去操作第一个问题就是“网页访问不了SSH 也连不上”。大概率不是华为云服务坏了而是安全组没有放通对应的入方向端口。华为云的 ECS 默认会建立一个安全组但入方向规则往往只放通了 22 端口80 和 443 没有放通。排查思路其实不复杂先确认你访问的是弹性 IP 而不是私有 IP然后检查安全组入方向是否放通了对应端口最后在服务器本地用curl 127.0.0.1:80测试服务是否正常监听。如果本地正常、远程不通问题基本锁定在安全组或防火墙上。Ubuntu 的 ufw 防火墙如果没有放行对应端口也会导致外网无法访问。这个坑之所以普遍是因为很多人习惯在本地开发时不关心端口开放到了云上还是同样的思维。云环境的安全组本质上就是你的外部防火墙它是默认拒绝的。记住这个心智模型后面凡是“外部访问不了”的问题第一反应都应该是查安全组。4.2 模型上下文长度导致的答非所问接好 Dify 之后第一个容易出现的问题是Agent 聊着聊着就“失忆”了甚至回答的内容和上下文完全对不上。这通常不是模型的智能问题而是上下文窗口溢出了。Dify 默认会拼接对话历史发送给模型当你开启的工具返回结果比较长时上下文占用很容易超过模型的最大 tokens。一些模型处理长上下文时还会出现中间内容被截断或注意力分散的问题。我的处理办法在 Dify 的模型参数里调整“上下文窗口”的最大值同时设置合理的“记忆”策略比如只保留最近 6 轮对话。另外在知识库检索的场景里控制好注入到上下文中的检索片段数量我个人习惯限制在 3 到 5 个片段每个片段在 200 到 500 个 token 之间。这样既保留关键信息又不至于撑爆上下文。4.3 工具调用失败Function Calling 的职责划分Agent 和普通聊天机器人最大的差别是工具调用。我实测下来工具调用失败一般有两个层面的原因你得分清是模型层还是接口层。模型层的原因模型没能从用户的自然语言中准确判断出该调用哪个工具、参数对不对。此时你需要优化工具的描述信息。比如你提供了一个“查询天气”的工具描述里可以写清楚“当用户询问某地未来几天的天气情况时调用此工具地点参数填写城市名”。描述越具体模型的选择就越准确。接口层的原因Agent 确实调用你的 API 了但 API 返回了报错或者格式不对。最常见的是自定义工具的 API 返回数据格式和 Dify 预期不匹配。Dify 的工具调用通常期望一个标准 JSON 格式的响应如果 API 返回的是纯文本或者格式不对Agent 就无法解析自然也就没法继续回答。4.4 并发上来的性能症状与成本控制思路当你的 Agent 演示给同事看之后通常就会面临一个小问题多个人同时用服务器卡死了。尤其是我这种 CPU 方案跑 7B 模型本身就已经很吃力两个以上并发会话就会明显感受到响应变慢。如果你要坚持 CPU 推理有几个比较实用的优化手段一是限制 Dify 应用的并发数避免资源耗尽二是把 Ollama 的OLLAMA_NUM_PARALLEL参数调低让模型一次只服务一个请求三是给 ECS 配好云监控告警当 CPU 和内存超过阈值时主动提醒。如果你的目标是更正式的 Demo建议升级到 GPU 实例比如华为云的推理加速型实例然后部署更高版本的 DeepSeek 模型。这时成本会明显上升但换来的是流畅的交互体验。个人实验阶段我建议就用 CPU 版本跑通逻辑即可等你要做真正的产品演示时再考虑算力升级不要一上来就追求高配。5. 大会之外的思考Agentic Cloud 对开发者到底意味着什么5.1 开发者要换的“思维范式”聊完实操再说回 HUAWEI CONNECT 2026 和 Agentic Cloud。站在开发者的角度这个趋势带来的最大挑战不是学一个新框架而是要换一种构建应用的思路。传统的云原生开发核心对象是“服务”。你定义接口、部署实例、配置负载均衡。但 Agentic Cloud 的核心对象是“智能体”。你要关注的不只是接口和实例还要有角色的设定、目标的拆解、工具的规划、记忆的管理、行为的安全边界。服务是确定性的同一个输入必然得到同一个输出Agent 是概率性的同样的输入在不同上下文里可能有不同的执行路径。这种思维差异会在你看材料、选工具时体现出来。以前你选云产品时会优先看“性能指标”现在你还要看功能接口和工具生态。这是 Agentic Cloud 给我带来的最直接的认知迭代。5.2 云厂商的竞争焦点正在转移如果把 Agentic Cloud 放到整个云计算行业来看华为云这一动作其实代表了一个趋势云厂商的竞争焦点正在从算力规模转向“智能体的生产效率”。前几年大家还在拼“谁的 GPU 最多、训练集群最大”但 Agent 时代客户关心的是“我能不能快速做出一个高质量的应用”。这背后需要的是模型调用、知识库管理、工具编排、数据安全这些能力的深度整合。谁的平台能把这些能力以最低的使用门槛提供出来谁就能在下一阶段获得开发者青睐。我在华为云上完成这套 DeepSeek Agent 实验之后最深的感受就是单点能力其实大家都差不多真正的差异在于平台整合能力。虽然我这套方案没有用到很多华为云的高阶服务但在这个过程中ECS、安全组、镜像服务这些基础能力配套的稳定性和文档质量确实让我少花了很多时间在排查环境问题上。5.3 我的后续计划与实操建议最后说点我自己的后续计划也算是给大家一个借鉴。我接下来打算做的事主要有三件一是把前面实验里用到的 Dify 部署从 ECS 单机迁移到华为云 CCE 容器引擎上配合弹性伸缩做更高可用二是接一个真实的业务数据源比如把我平时的一些统计数据做成知识库让 Agent 能够基于实际数据回答问题三是通过函数工作流做定时任务让 Agent 每天早上自动汇总信息并推送到工作群。如果你也打算开始自己的 Agent 实验我给你三个小建议不用纠结最开始选什么模型。先用 Ollama 跑一个 7B 级别的模型把 Agent 的流程跑通。框架通了你自然知道瓶颈在哪里再针对性地换更好的模型。知识库的投入会占据你大部分时间但这是值得的。Agent 的差异化价值基本都来自知识库和工具的质量而不是模型本身的智能。每次该 Agent 的回答之前先思考“这个进程为什么会产生这样的行为”而不是直接换模型或改参数。Agent 的问题往往出在工具描述、上下文管理和数据质量上模型经常是替你背锅的那个。老话讲能跑起来的系统才是好系统。Agentic Cloud 听起来很远但它无非就是让智能体的开发、部署、运维变得更简单、更顺滑。你只要愿意花半天时间在华为云上实实在在跑通一个基于 DeepSeek 的 Agent那些概念、新闻、发布会上的名词就都会变成你手里可以随意调用的能力。