背景：随着AI Agent / Agentic AI快速发展，Agentic AI 负载复杂多变，需探索Agentic AI场景下，对计算集群基础设施面临新挑战和要求。Q25：【文本题】业界普遍认为2025年是AI Agent元年，您是否看好AI Agent发展，您认为在哪些AI Agent/Agenti AI应用场景会率先爆发？摘选回复1：1、ai agent是ai发展的必经阶段，未来一定是好的，只是目前ai agent技术还未真正成熟，无法真正做大商用，所以并未像年初的ds一样，呈现千行百业接入ds。2、我觉得后台职能部门会较快出现场景爆发，例如目前的ai在文案编辑方面很强了，在加上agent能力，可以很容易替代市场经分岗、财务分析岗等文职岗位；3、具体到场景，我个人认为在智能客服、智能质检、银行催收、电话营销这四个部分会较快实用，主要是这四个领域普遍有ai基础（例如智能客服已经大量实用ai辅助进行电话接听和电话服务质量ai分析了），其次因为人工成本等因素，使用ai agent意愿更强烈。摘选回复2：AI Agent作为生成式AI的高级形态，被业认为是发展最为迅猛之年，其核心优势在于能自主调用工具执行复杂任务，工具及配套基础设施、技术架构涵盖大模型和相关应用的开发工作。1、在数据处理方面，通过AI Agent能处理数据的清洗和分析相关任务，可以使得相关人员在从事改工作方面尽量减少冗余度，从而成为数据的最为重要的核心力。2、在相关智能制造领域，AI Agent能够对相关设备进行协调运作，降低人工成本以及风险，从而对相关业务有着极为重要的一部分，也使得在AI Agent领域能够参考一些较为经典的定义范围，能够感知到周围的环境变化，自主做出相关人工干预系统，从人为进行干预到大模型进行自适应分析抉择。3、AI Agent的应用领域还在不断地扩大，目前业界共识是大模型+Agent技术已支撑起大量B端商业化场景，C端MVP雏形初现，但要实现更复杂功能，仍需突破长期记忆、多模态整合等技术瓶颈。企业也需做好流程标准化准备，随时为AI Agent的发展做出一部分贡献。4、自主性是指AI Agent无需人工持续干预，可独立完成目标。规划与记忆是指AI Agent可以将复杂任务分解为多个子任务，并通过有效的记忆机制存储和调用信息。闭环执行能力是指AI Agent能够持续监测执行效果，并通过学习反馈进行自我优化迭代。个人认为 AI Agent应该会率先进行爆发出应用场景，应该是有的厂家应该以及发不出自己的大模型产品，比如百度推出的文心大模型，这一模型的推出就降低了一些开发的门槛，为开发工程师奠定了一些基石。同时像一些知名的企业，也都相继出现相关产品的应用，都为进一步打造该市场进行了前期的铺垫。摘选回复3：在消防应急社会治理领域有一家创业公司，他们的AI产品是利用人工智能认知模型技术，基于大数据下的各级法律法规、安全管理条例、行业标准规范、事故案例分析、安全应急常识，开发并训练综合性知识能力服务底座，对外部应用提供接口服务，为具体的细分安全应急应用场景定制输出专业的、权威的、可溯源的知识服务。为各政务部门、各行业企事业单位、社会民众等各级社会安全应急参与者打造综合性安全应急知识服务体系。应用场景有城市九小场所的应急消防管理和监管，使用AI应用，可以通过终端硬件，实时检测九小场所的消防现状，并且给出消防隐患报告，整改方案，违反哪一条法规，如果不整改会怎么处罚。帮助政府执法部门实现了监管和执法，有效防止火灾隐患，解决社会治理难题。Q26【文本题】您在AI Agent/Agentic AI 开发过程中，对基础设施（算力、存储、网络）有哪些痛点诉求？摘选回复1：目前运营商的智算平台采用内部自用和外部售卖单独建设模式，外部售卖平台规模大，训推服务器都有。内部自用规模小，自用智算平台主要以推理场景为主，配置服务器主要为Atlas 800I A2 推理服务器为主，平台具备maas和裸金属两类服务，各使用部门按照需求订购所需产品，目前业务主要以裸金属为主，不熟专属开源模型，如DeepSeek-70B和qweb-32B，在大模型基础上再利用LLM组件部署agent和知识库能力，我主要负责平台基础设施维护，在算力，存储和网络层面有如下困惑。1.计算：业务主要以推理为主，智算服务器为8卡，主要采用单机多卡推理模式为主，但是有两个极端场景比较棘手。（1）多机需求：规划阶段主要用于满足单机场景为主，多机多卡通过参数面互联实现大参数模型的能力未考虑，为了单独的需求，去做网络调整，复杂度过高，在规划阶段没办法做好单机和多机场景规划。（2）低端卡需求：目前部分业务使用910B后对卡的资源利用率进行监控发现，存在资源闲置问题，当业务处于限时，NPU卡闲置严重，为了降低使用成本，我们希望启动300IDUO卡，但是目前的计算方案，异构计算方案没有好的推荐方案。（3）节能需求：当晚上或者业务量低的时候，NPU耗电量大，希望引入节能降耗功能，智算服务器能耗太厉害了。当业务量或者推理任务极少场景下，开启NPU节能功能，降低功耗。2.存储：智算平台需要配置块存储和文件存储，块存储用于存储容器等通算业务产生的数据，文件存储主要用于存储agent知识库和agent生成的用户数据。按照华为智算平台文件存储配置方案，要同时配置性能和容量两类存储，容量合计为2P，实现冷热数据的分层管理，再加上通算的块存储，一个平台需要配置3套存储，建设和维护成本过高，同时，智算服务器通过数据面网络互联文件存储，通算服务器通过存储面互联块存储，为了减少成本，希望将数据面和存储面合并，那么文件存储和块存储方案应该也可以合并使用，但是目前华存储暂不支持1套存储同时提供快和文件存储能力，只能一套存储提高对象和文件存储，希望提供集约化的存储交付方案，降低智算平台的建设成本。3.网络：智算网络包括业务/存储网络（10G100G），管理网络（10G），参数面和数据面网络（100G200G400G），参数面网络初期为了降低建设c目前运营商的智算平台采用内部自用和外部售卖单独建设模式，外部售卖平台规模大，训推服务器都有。内部自用规模小，自用智算平台主要以推理场景为主，配置服务器主要为Atlas 800I A2 推理服务器为主，平台具备maas和裸金属两类服务，各使用部门按照需求订购所需产品，目前业务主要以裸金属为主，不熟专属开源模型，如DeepSeek-70B和qweb-32B，在大模型基础上再利用LLM组件部署agent和知识库能力，我主要负责平台基础设施维护，在算力，存储和网络层面有如下困惑。1.计算：业务主要以推理为主，智算服务器为8卡，主要采用单机多卡推理模式为主，但是有两个极端场景比较棘手。（1）多机需求：规划阶段主要用于满足单机场景为主，多机多卡通过参数面互联实现大参数模型的能力未考虑，为了单独的需求，去做网络调整，复杂度过高，在规划阶段没办法做好单机和多机场景规划。（2）低端卡需求：目前部分业务使用910B后对卡的资源利用率进行监控发现，存在资源闲置问题，当业务处于限时，NPU卡闲置严重，为了降低使用成本，我们希望启动300IDUO卡，但是目前的计算方案，异构计算方案没有好的推荐方案。（3）节能需求：当晚上或者业务量低的时候，NPU耗电量大，希望引入节能降耗功能，智算服务器能耗太厉害了。当业务量或者推理任务极少场景下，开启NPU节能功能，降低功耗。2.存储：智算平台需要配置块存储和文件存储，块存储用于存储容器等通算业务产生的数据，文件存储主要用于存储agent知识库和agent生成的用户数据。按照某智算平台文件存储配置方案，要同时配置性能和容量两类存储，容量合计为2P，实现冷热数据的分层管理，再加上通算的块存储，一个平台需要配置3套存储，建设和维护成本过高，同时，智算服务器通过数据面网络互联文件存储，通算服务器通过存储面互联块存储，为了减少成本，希望将数据面和存储面合并，那么文件存储和块存储方案应该也可以合并使用，但是目前某储暂不支持1套存储同时提供快和文件存储能力，只能一套存储提高对象和文件存储，希望提供集约化的存储交付方案，降低智算平台的建设成本。3.网络：智算网络包括业务/存储网络（10G100G），管理网络（10G），参数面和数据面网络（100G200G400G），初期为了降低降低成本，一般选用00200G端口智算网络，业务量低的时候满足需求，当业务量大，网络的带宽和性能没办法无感平滑扩容。摘选回复2：就是感觉老算力中心抗不住，还是得购置新的一体式机器才能顶上。目前搞了一年多了，感觉在算力上灵活度不够，不知道说的对不对哈，根据我们使用体验来看，推理时GPU会飙到100%，但调用工具或等待API时又空转，传统固定分配的GPU实例造成极大浪费，但是不分配呢，思考推理时又会变慢，搞的我们难以抉择。再就是网络的问题，存在太大的不确定性了。还有一个这里没提到，就是关于Agent的安全性，如果要保障安全性，比如说去开设代码沙箱等，势必也会导致整个流程进一步变慢，启动容器要2-3秒，再推理后输出都不知道要等多久了。所以总结一下，第一就是单纯的算力问题不知道如何最合理化使用？第二就是网络问题？第三就是安全问题，如何在保障安全的情况下保证效率的最优，同时来最优化基础设施分配呢？我想这几个算是我们目前遇到的最大痛点了。摘选回复3：一、算力方面：1、一是需要依赖高性能的算力资源，之前的算力平台是多是传统虚拟化架构，不具备高性能的推理、训练等能力，因此承载AI训练业务算力不足，为此我们24年单独部署了HPC高性能计算平台，在里面分出了一部分算力资源部署deepseek大模型、AI智能体等。2、还有是当前的资源比较分散，缺乏统一调度，除了校内有统一的虚拟化平台、HPC高性能计算平台以外，其实学校还有不少的算力平台，这些算力资源分散在计算机学院、网络中心、各科研实验室等部门，缺乏跨部门的统一算力调度平台，在考虑多agent实现协同的时候就会存在算力调度的问题。例如，开发校园智能运维多agent系统时，需要基于大模型对网络日志、设备监控视频等多模态数据做微调，但各部门的GPU服务器未形成资源池，导致：训练周期被拉长、资源复用率低等问题，单个的agent但无法快速调用其他部门闲置的算力资源。二、存储：1、因为校内为虚拟化架构，所以存储的资源在调度的时候还比较灵活。但在AI agent开发过程中面临主要问题/痛点是多源数据的异构与整合壁垒，AI agen训练需整合跨部门的校园数据（如教务处的教学数据、后勤处的资产台账、图书馆的文献资源、网络中心的运维日志等），但这些数据存储在异构系统中，存储介质与协议不统一：有的是NAS、有的是分布式存储、还有传统服务器本地存储等，数据格式零散，这导致agent训练前的数据清洗与整合耗时较长。三、网络：1、单独部署的HPC高性能计算平台设计的时候均用的数据中心级网络设备，所以平台内部的数据转发很高校。2、痛点在于师生用户量最大的校园网网络，因为很多局点均为千兆网络，所以存在数据传输延迟高的问题。