ARTICLE · 1218409
openFuyao x 复旦大学软件工程实验室 Panel 回顾:Agentic时代,集群调度技术体系将如何演进?
近期，openFuyao开源社区与复旦大学软件工程实验室（CodeWisdom团队）联合举办“Agentic时代，集群调度技术体系将如何演进”Panel活动，围绕Agentic负载带来的调度挑战、Kubernetes的角色定位及其与Agent Runtime的分层协作机制，结合产业实践展开深入讨论，共探AI Native基础设施的架构演进方向。
各位专家认为，Agentic 时代，Kubernetes不会被“取代”，但会从全栈调度者退位为资源底座，而调度智能的重心将上移到Agent Runtime与推理数据平面，即Kubernetes和Agent Runtime分层调度：Kubernetes继续管节点与 Pod 编排、GPU 分配、多租户硬隔离、集群级弹性，Runtime则接管上下文组装与复用、会话状态与记忆持久化、工具调用鉴权与审计、请求级路由。真正的技术难点不在于某一层的调度算法，而在于分层维度和以及多层之间在目标函数不可比条件下的柔性协同机制，以及从容器语义向Agent语义（会话、状态、语义资源）的体系化扩展。
openFuyao社区沿此方向推进技术演进：v26.09推出高性能K8s沙箱调度引擎，并发创建调度吞吐量>3000实例/秒，单实例调度时延<30ms，支持E2B沙箱与普通Pod共集群、共节点部署，回应Agent对细粒度、低时延调度的需求。针对状态长期保留、任务间歇执行的痛点，通过快照换入换出实现空闲释放、按需恢复，结合快慢双路径调度，兼顾响应速度与资源效率。
活动背景
AI Agent应用正由单次模型调用走向长链路、状态化和工具密集型执行，呈现突发并发、任务生命周期差异大、状态与缓存依赖强、安全边界细粒度等特征。
Kubernetes是云原生集群调度编排的事实标准，但其以Pod为核心的编排机制，难以直接覆盖Agent所需的请求级路由、执行环境动态创建、会话状态保持、缓存复用及亚秒级资源决策。E2B、CubeSandbox等专用沙箱与运行时系统，以按需创建的隔离环境支撑快速启动、高并发与安全隔离；部分系统与Kubernetes集成，由专用运行时管理沙箱生命周期与细粒度调度，呈现“Kubernetes＋Agent Runtime”的组合趋势。
未来AI Native基础设施将以Kubernetes为核心底座分层演进，还是形成新的运行时与控制面范式？本次访谈将结合产业实践展开探讨。
主持人
彭鑫
复旦大学
复旦大学计算与智能创新学院副院长、教授，国家级高层次人才计划入选者。中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员，中国汽车工程学会汽车基础软件分会副主任，《Journal of Software: Evolution and Process》联合主编（Co-Editor），《ACM Transactions on Software Engineering and Methodology》、《Empirical Software Engineering》、《Automated Software Engineering》、《软件学报》等期刊编委。2016年获得“NASAC青年软件创新奖”，2023年入选上海市东方英才拔尖项目，2024年获得“中创软件人才奖”。主要研究方向包括软件智能化开发、AI原生与云原生系统、泛在计算软件系统、智能汽车及工业软件等。研究工作多次获得IEEE Transactions on Software Engineering年度最佳论文奖、ICSM最佳论文奖、ACM SIGSOFT杰出论文奖、IEEE TCSE杰出论文奖等奖项。担任2022年与2023年CCF中国软件大会（CCF ChinaSoft）组织委员会主席与程序委员会共同主席，以及ICSE、FSE、ASE、ISSTA、ICSME、SANER等会议程序委员会委员。
访谈嘉宾
王昊奋
同济大学
同济大学长聘教授、博士生导师，聚焦知识图谱与知识增强大模型研究，以及AI产业落地。核心成果包括全球首个知识增强推理模型KAG-Thinker（超万Star）、记忆操作系统MemOS（日调用量超150万次）及大模型评测平台AI-Ceping（30万+月活），已落地机场调控、金融风控等多场景。出版《知识图谱》《检索增强生成：理论与实践》《记忆工程》等6部专著，共发表高水平会议和期刊论文100多篇，谷歌学术被引超1.5万次。主持国自然重点、面上、国家新一代AI重大专项课题等10多个国家AI项目，获中交协科技进步一等奖、2026年IF设计奖、HCII最佳论文、DASFAA最佳学生论文等荣誉。他曾担任两家AI独角兽企业CTO，构建了全球首个可交互养成的虚拟偶像—“琥珀·虚颜”；所构建的智能客服机器人已累计服务用户超过100亿人次。目前，他担任全球最大开放知识图谱社区OpenKG首任轮值主席，中国计算机学会术语工委副主任，自然语言处理专委会副主任（执行），中国中文信息学会理事，大模型专委会指导委员，语言与知识计算专委会副主任，上海市计算机学会自然语言处理专委会副主任等社会职位。
金鑫
北京大学
北京大学计算机学院长聘副教授、博士生导师。研究领域为系统软件、计算机网络、云计算。获ACM SIGCOMM Rising Star Award、CCF青年科技奖、阿里巴巴达摩院青橙奖、USENIX FAST最佳论文奖、USENIX NSDI最佳论文奖等奖项。
胡昊
openFuyao社区
华为公司软件领域科学家委员会委员，华为公司 ICT 公共开发部首席资深架构师，openFuyao 社区技术委员会主席。
章明星
清华大学
清华大学副教授、趋境科技联合发起人，主要从事机器学习系统研究。发起 Mooncake、KTransformers、AgentENV 等开源项目，GitHub 累计斩获 3 万余星标，成果已广泛应用于数十万张 GPU 并服务数千万用户。在国际顶级会议与期刊发表论文近 50 篇，包含国内高校首篇 OSDI 论文，并荣获 FAST 最佳论文奖、SIGSOFT 杰出论文奖。受邀担任 OSDI、SOSP、ASPLOS、FAST、EuroSys 等国际顶级系统会议的程序委员会委员。曾获蚂蚁 Intech 科技奖，WAIC 璀璨明星奖、华为奥林帕斯奖、ChinaSys 新星奖、ChinaSys 优博及 IEEE TCSC 优博，入选教育部中央高校青年教师科研创新能力支持项目（U40）、中国科协青年人才托举计划，并担任科技部重点研发项目课题负责人。
郑然
百度
百度杰出架构师，百度智能云技术委员会主席。自加入百度以来，一直从事分布式系统和工程架构的研发工作，先后负责大规模分布式索引系统、云原生平台、分布式存储技术、虚拟化和弹性计算技术等大型分布式系统的设计和研发, 现阶段重点负责公有云 AI infra 和 Agent Infra 的产品和技术研发工作。
高丰
之江实验室
博士，之江实验室高级工程师，博士后合作导师。长期从事分布式计算、计算机体系结构、云计算等领域的研究。课题牵头“软件定义的泛在操作系统”国家科技部重点研发项目，国家自然基金区域集成创新重大项目等项目，获得省部级科技进步5次奖。在之江实验室任职期间，主持“端边云协同分布式操作系统”、“广域协同智能计算系统”等，在端边云协同计算等方向取得技术突破。在《电子学报》、VLDB等国内外重要期刊与会议上发表了学术论文10余篇，申请中国、美国等国家发明专利共20余项。
史明伟
阿里云
阿里云智能高级技术专家，前函数计算研发负责人。现AgentRun研发负责人，AgentCore首席架构师。
王泽锋
华为云
华为云开源技术负责人，CNCF 技术监督委员会（TOC）副主席、CNCF 官方大使，Kubernetes 资深维护者。2015 年起参与 Kubernetes 及 CNCF 社区，是国内最早的 Kubernetes Maintainer 之一，先后发起 KubeEdge、Volcano、Karmada 等多个 CNCF 开源项目。2024 年成为中国本土首位 CNCF TOC 委员，2025 年出任 TOC 副主席，并获 CNCF 终身成就奖（全球仅 3 人）。目前主要负责华为云在云原生、AI 与 Agent 领域的开源战略、技术贡献、生态合作及开源项目产品化落地。
姚晓忠
openFuyao社区
openFuyao社区技术委员会执行秘书、openFuyao技术专家，10+年软件设计和开发经验，曾主导华为内部大型项目重构和产品线软件工程能力提升工作。
访谈记录
Question 1
主持人：当前的Agentic AI场景对基础设施提出了什么样的新挑战？从当前已经落地或近期可能规模化落地的业务看，哪些Agentic AI场景对集群基础设施的要求最高？这些场景面临的核心问题是什么？当前进行了哪些方面的探索？
王昊奋：
我比较关注Coding Agent 和能直接操作企业系统的业务 Agent。前者要频繁启动环境，又希望复用仓库、依赖和缓存；后者可能改完订单，还要等人审批才能继续。调度对象正在从“一个计算进程”，变成“带着知识、状态、权限和执行历史的一段任务”。同样是等待，等模型返回、等人工审批、等支付确认，对资源保留和失败重试的要求完全不同。需要补上的，就是这些业务含义与资源决策之间的连接。
另外，沙箱预热、快照和持久化工作流已经解决了部分问题，但恢复环境不等于恢复任务。系统还要知道：哪些步骤完成了，当时依据什么，哪些操作不能重做。尤其当 Agent 开始根据执行经验调整策略时，不仅要保存结果，还要记录结果产生的条件，否则一次偶然成功就可能被当成通用经验。
观点讨论
@彭鑫：业务含义与资源决策之间的连接，这个确实是个新问题，云原生时代资源调度似乎对于业务没有那么敏感。Coding Agent 和能直接操作企业系统的业务 Agent，正好对应我们软件工程领域常说的 AI4SE 和 SE4AI 。
@王昊奋：对的，这块是新的挑战和新的需要完成的工作，尤其是当进入企业或要进行组织智能的变革和数智化推进时。
@彭鑫：这背后可观测性也是个难题，远比云原生软件系统的可观测性复杂。
@章明星：我个人感觉核心还是对于弹性的要求比之前都高了很多。也就是需要真的 serverless。我们实际的场景中基本上密度做到每颗 cpu 上跑十几甚至几十个 sandbox 都是可能的。实际执行时间比较短，大多数时间都在等 llm。但是做到这么高的密度需要的内存弹性其实比较难实现的。
@顾荣：我觉得Agentic场景一个比较有意思的地方就是应用特点（用户意图）和底层资源供给对接要求更高了，以前一个作业的资源需求刻画的往往比较粗糙，端到端实际用户体验和底层基础设施能力有一定距离，现在通过Agent一下被拉近了。
金鑫：
现在以Coding Agent为代表的Agentic场景对AI Infra带来了新挑战。Agentic场景的特点是长程（多轮）、有状态、工具调用。之前的LLM Inference主要针对LLM在GPU的执行进行优化。在Agentic场景下，工具调用在端到端执行时间的比例变得重要，需要对工具调用部分进行系统优化，并且考虑Agentic场景LLM Inference -> Tool Call -> LLM Inference -> Tool Call -> …这种在LLM Inference和Tool Call来回交替执行的特点，对LLM Inference和Tool Call进行协同调度。
高丰：
我个人经验，挑战最大的不是并发最高的场景，而是"上下文最重 + 权限最大"的场景。我接触过一些 agent，对运行基础设施挑战的有三个：
代码与软件工程 Agent——上下文最重，一轮任务要反复全库检索、读文件、跑测试、看报错；权限也最危险，直接握着 shell 和 git。
金融风控 Agent——高风险业务下兜底机制的真实可信度，防止模型由于过度自信Overconfidence引发风控合规风险。上下文体量中等，但约束多、全链路归因等要求高。每一次查询都必须携带行级列级权限和数据来源，上下文组织和权限体系一致性高。
长时运行的运维与企业业务 Agent——会话以小时乃至天计，记忆必须持久化、可迁移、可跨故障恢复。
我理解核心矛盾集中在两侧：上下文侧，前缀每轮都在变，KV Cache 大量失效，成本随轮次线性上涨；安全侧，集群给的隔离粒度（命名空间、Pod）远粗于业务要求的权限粒度（例如在数据层面，某个 Agent 只能读某张表的某几列）。现有探索也分两路——用沙箱化执行把"能执行代码"和"别乱执行代码"分开。
胡昊：
Agent负载和传统的负载：微服务，我们看到至少有五个基础假设的不同。
生命周期形态的假设不同。传统请求来了就处理，处理完就结束。Agent会话可能存活几小时，真正占用GPU的时间不到百分之五。活跃和占用资源不再是同一件事。
状态耦合度的假设不同。传统微服务大都可以随便迁移，状态在数据库里。Agent的状态散落在KV Cache、会话记忆、沙箱文件系统、工具连接里。调度一个任务，实际是调度它依赖的全部状态。
并发形态的假设不同。传统QPS相对平滑，峰值均值比大概二比一到五比一。Agent是事件驱动的脉冲，峰值均值比可以到五十比一，不可预测。
执行拓扑的假设不同。传统请求是单跳的，Agent是多跳DAG加循环，拓扑在运行时才生成。调度决策发生在Pod创建时，执行拓扑在运行时才展开，两个时间尺度对不上。
安全边界粒度的假设不同。传统是服务级隔离，相对静态。Agent需要单次工具调用级的隔离，读文件、访问数据库、调用外部API各一套权限，且在一次Run内动态变化。
这五个里，前四个是工程问题。状态耦合可以通过更好的Runtime解决，并发脉冲可以通过弹性策略缓解，执行拓扑可以通过动态创建来适配。Kubernetes社区正在做的DRA、in-place resize、agent-sandbox，都是在补这些。
但第五个不是工程问题。声明式API的整个前提是“期望状态可以被完整描述”。Kubernetes的每一次调度，都建立在一个假设上：你在YAML里写清楚你要什么，系统负责让现实收敛到你的描述。但Agent的执行路径无法被预先声明——它要调什么工具、访问什么数据、生成什么代码，都是运行时才决定的。这不是“声明式API不太适合Agent调度层”，是范式冲突。声明式API在资源供给层仍然有效，因为“我要8张H100”是可以预先声明的。但在调度决策层，它和Agent的执行模型在根上不兼容。
这里有三个结构性矛盾。
会话连续性和资源弹性不可调和。缩容到零意味着KV Cache丢失、沙箱状态丢失、会话上下文丢失。永不缩容意味着资源浪费率超过百分之九十。当前所有探索都是在找“缩容但不丢状态”的中间态，但这个中间态的存在性本身没有被证明——它可能只在特定负载分布下成立。
调度决策频次和控制平面设计假设不可调和。Kubernetes API Server假设调度决策低频且持久。Agent场景的决策频次高出两到三个数量级。把高频决策塞进为低频设计的控制循环，结果不是性能下降，是控制平面本身成为瓶颈。
状态本地性和调度灵活性不可调和。KV Cache在GPU显存里，会话记忆在特定节点内存里，工具连接在特定Pod网络命名空间里。状态本地化，调度需要全局灵活。迁移状态成本高，不迁移则丧失灵活性。
三个矛盾里，第一个和第三个有工程上的折中空间，第二个是架构性的，只能通过分层解决。
郑然：
我也和各位老师分享一下我的观察, 我觉得agentic场景对 infra 层提出的主要挑战有:
生命周期差异：相比常驻服务, 秒级工具调用与数小时长任务共存，调度和编排能力提出新挑战；
状态特点：会话状态、KV 缓存、记忆都是状态数据，不完全符合 K8S "宠物式"管理的设计理念；
安全性： agent执行过程中生成的代码不完全可信，且 Agent 自身可能"失控", 甚至成为变攻击者；
推理服务：推理服务的特性提出新的挑战, PD分离分角色部署, kvcache服务管理, 请求级调度的公平性和抢占, 这些给推理服务的部署编排带来全新的架构挑战；
GPU资源管理: 模型SPMD计算范式, 异构芯片, GPU资源切分等需要引入了新的技术挑战。
观点讨论
@张晨曦：看起来很多都是业务特点带来的问题。
@胡昊：对，是业务负载模型特征带来的问题。传统 Pod 建立在长稳假设上，而 Agent 很可能既不长，也不稳。
@彭鑫：大家此前对大模型、智能体的应用看的比较多，但对于支撑Agentic应用落地的云基础设施了解可能没那么多。但要支持Agentic AI在各行业应用落地，基础设施支持是个关键问题。
@郑然：同意，和传统 pod 的工作模式有很大差异。
史明伟：
回答这个问题我从几个业务的形态和需求变化出发，第一：Agent由单轮到多轮，上下文的延续对于运行时提出了要求； 第二：工作负载的形态以IO为主，对于算力供给形式提出了要求；第三：Agent连接和操作的内容对于数据传输和交互的形态提出了要求；第四：基础设施运行内容本身可信度对于Infra安全边界提出了要求。
姚晓忠：
我认为多 Agent 协作是一个难点，一次入口请求，会产生数量不确定的内部请求。 用户并发不能直接代表模型、工具和沙箱的实际负载，Agent 间通信、任务编排、级联失败等场景，如何保证长任务执行的可靠性，如何进行端到端的追踪，这都给基础设施带来更大挑战。
王泽锋：
我首先看到的是Kubernetes API 原语的gap。
如果把原生的 Kubernetes Pod 直接当作 AI Agent 来运行，会遇到非常严重的“水土不服”：
冷启动延迟鸿沟：传统容器启动要经历调度、网络分配、拉镜像等流程，耗时往往在秒级甚至分钟级；而 Agent 无论是在交互式对话还是多智能体拆解突发子任务时，都要求亚秒级、毫秒级的拉起。
“空转等待”引发的资源利用率假象：Agent 是极端的 I/O 密集型负载。在长会话中，超过 90% 的时间都在等待 LLM 生成 Token、等待 MCP Tool 或外部 API 响应。如果为每个 Agent 独占分配静态 Pod 资源，会导致 CPU 利用率不到 1% 但内存/配额已被占满的“假象”。
会话状态与无状态底座的语义错配：云原生架构天然偏好无状态；但 Agent 高度依赖多轮上下文、执行进度和 Memory。频繁将状态卸载和外挂拉取，会带来高昂的网络 I/O 与延迟开销。
控制面调度风暴：Multi-Agent 常常会瞬间裂变出成百上千个短生命周期的临时实例，这种瞬时的高频创建和销毁，会对集群调度器和控制面造成近似 DDoS 级别的压力。
未知代码执行的安全边界失效：高级 Agent 普遍具备调用Code Interpreter的能力，即实时生成 Python/Bash 代码并执行。这属于不可信代码，传统的runC容器极易发生越权或容器逃逸，多租户隔离面临严峻考验。
Question 2
主持人：Agentic时代的高并发、低延时、强隔离、状态保持、工具调用和企业安全治理等诉求，对Kubernetes已有的调谐机制、存储机制等提出了新的挑战，现有以 Kubernetes 为基础的集群管理体系是否需要进行重构或扩展？以Kubernetes为基础的模式是否还是最优解？哪些能力应继续由 Kubernetes 统一承载，哪些能力更适合交给 Agent Runtime 或上层框架？
王昊奋：
对于 以 Kubernetes 为基础的体系是否需要重构，以及哪些能力应交给 Agent Runtime？
我的判断是，先扩展，不必推倒重来。Kubernetes 管节点、Pod、配额和基础网络存储；Agent Runtime 管执行环境、会话和任务续跑。最近讨论的 Harness，关注的是模型周围那套让它真正把事情做完的机制，包括上下文组织、工具调用、执行循环和结果检查。它与 Runtime有重叠，但不是 Kubernetes 的替代品，也不一定是独立的一层。
延续前面说的，知识和语义的作用，是让这套机制知道“该怎么做、为什么这样做”。例如，工具描述不能只有参数，还应说明它是否修改业务数据、需要什么权限、失败后能否重试。Harness 据此组织执行，Runtime 和工具网关落实约束，Kubernetes 提供资源与基础隔离。没必要让底层理解全部业务，但上层必须把业务要求交代清楚。
观点讨论
@彭鑫：上次跟一个企业专家讨论，他也提到现在两种思路。一是在现有的云原生体系之上去构建Agentic AI运行支撑，二是推动未来针对Agentic AI的特点重新设计。目前似乎大部分企业还是选择第一种。
金鑫：
Kubernetes提供基础的集群管理能力。针对Agentic负载的各类需求，需要对Kubernetes进行相应的重构和扩展。由Kubernetes提供底层集群的管理，与Agent相关的状态、会话、工具调用等细粒度资源管理交给上层的Agent Runtime。
章明星：
当前 K8s 的控制面引入的延迟还是比较高的，没法满足对于 sandbox 快速启动的需求，所以在构建 AgentENV 的时候我们选择的是绕开 K8s 直接管理资源。
另外一个问题是 sandbox 现在隔离性要求都比较高 K8s 虽然现在也能管理 microvm 但是实际的功能不是很全，对于 fork，迁移之类的操作支持也不够灵活。
甚至因为未来可能会需要做分布式 agent 环境，说不定是 agent runtime 来拉起多个 K8s。当然这些都不是 K8s 本身有啥本质问题，感觉更多是历史债务导致为了特定目的重写一个效率高。
顾荣：
我想从 Kubernetes 的视角来谈一谈我的想法，其实非常有趣，Kubernetes从设计之初主要是管理调度微服务为主的应用的，但是近10年来的若干次IT技术浪潮中，比如大数据系统成熟期、深度学习发展期、大模型推理爆发期，很多人都尝试着将大数据计算框架、CNN模型训练框架、大模型推理框架搭载到Kubernetes之上，为什么会这样？先搁置Kubernetes是不是完全适合这个计算框架不谈，应该是真正做一个广为使用的资源管理调度框架就很难，人们发现时下公开可用最接近他们需求的就是Kubernetes框架了，它提供了容器化运维部署的便利性、资源抽象管理和扩展的灵活性、负载和资源调度编排的极致弹性。
但是，比较遗憾的是大数据系统、深度学习框架、推理引擎系统，包括今天我们谈的Agentic框架，严格意义上来说它们都不是“云原生”的，也就是说从设计构建之初不是运行在“K8s+Docker+存算分离+资源抽象+Serverless计算”这套云原生环境上的。将它们对接部署运行到Kubernetes 往往会遇到水土不服问题，直接的表现是两个方面：1）Kubernetes提供的一些优势和先进的能力，上层既有计算服务框架设计的时候没用上；2）现有计算服务框架的一些需求或依赖假设，Kubernetes不一定满足。
因此，我认为通常而言，需要在Kubernetes这种非常基础的Infra编排调度管理系统之上，还需要再做一些面向Agentic的中间件。我们在大数据和深度学习时代就做个一个开源项目Fluid， 解决那时类似的问题。
胡昊：
Kubernetes 面对新的负载模型情况下，需要退一步，而是职责适当“窄化”：从全栈的资源供给+调度中进行分层，面对 Agent 这样的复杂模型时候，就把敏捷的调度能力让渡给专门的调度器，自身只充当资源供应者角色。K8s 充当集群级别的 HAL 还是相当够格的。
另外一个问题是：Agent 调度太新、发展太快了。现在固化为生态事实来说很难稳定下来。所以就像 google 搞 quic 的理由类似，先把它从内核的网络栈里拿出来。这样可以快速发展、演进、试错。
观点讨论
@彭鑫：确实“资源”的概念也是分级的，越往上越接近现实世界，越往下越接近机器世界。比如Agent在上层看可能是一个订单审核数字员工（类比现实世界中这个岗位上的工作人员），而到了底层就是一堆计算存储网络资源的组合。
高丰：
我理解不该重构，而该"定位边界"：K8s 继续管机器与生命周期，把上下文与权限交给 Agent Runtime。
应留在 K8s 的：节点与 Pod 编排、GPU 分配、多租户硬隔离、集群级弹性。声明式 API 的价值在"资源终态收敛"，这部分没有变，也不该变。
应给 Runtime 的：上下文的组装与复用、会话状态与记忆的持久化、工具调用的鉴权与审计、请求级路由。
理由很直接：kube-scheduler 的决策粒度是秒到分钟级，很多Agent 的调度粒度是请求到毫秒级，硬塞进控制面只会让 API Server 变成瓶颈。从现实层面vLLM、SGLang 的 continuous batching 与 prefix cache 都在推理进程内决策，本来也下放不了。所以"K8s + Agent Runtime"不是过渡形态，而是稳态分工：K8s 提供容量与隔离的确定性，Runtime 提供上下文与权限的灵活性。
史明伟：
从实际业务规模化落地来看，无法避免对大规模资源运维需求，K8s 仍是节点/网络/存储通用底盘的最优解，但从业务特点而言，Pod，Workload已经无法独自承载 Agent 语义。
需要明确的分层调度和管理：K8s 管 Pod 资源，Agent Runtime 管会话/沙箱/工具/记忆，上层框架管 Agent 协作。
关键解耦：业务状态锚定 Sandbox 而非 Pod，用化身代替绑定， incarnation 隔离重建前后的物理实例。 状态延续，而不需要物理资源延续，减轻基础设施长久以来的状态持久化原生支持困难又不稳定的困境。
郑然：
我的理解不是"替代"或"重构"，而是"分层分工"。K8s 的声明式 API、控制循环、Pod 编排和生态（CNI/CSI/CRI可观测）依然是最优底座, 同时 Agent 需要的是"短时间存活的执行单元"， 总结的说, Kubernetes 的设计思想依然优秀, 但也不适合直接照搬, 而为了满足 agent 的特点和要求, "控制面"和"数据面"都需要同步演进和扩展
适合继续由"kubernetes"统一承载的（"控制面"）：
节点与物理资源（CPU/GPU/内存）的池化管理、NUMA/拓扑感知、taints/affinity；
网络与存储插件底座（CNI/CSI 的通用能力）、多租户隔离（namespace、配额）、安全基线（PSA、网络策略）；
长期服务工作负载（模型服务、控制面组件、带状态的有状态服务）
面对大量和高密度 agent 程序的情况下, 需要极致的优化甚至裁剪,
来实现更大的规模和性能, 容器数量可能比普通在线服务高1 到 2 个数量级甚至更多
适合交给 Agent Runtime / 上层框架的（"数据面"）：
请求级路由：一个 Agent 服务请求该进哪个推理实例；
执行环境动态创建：镜像预置、按需拉起、快照恢复/池化（避免冷启动成本）；
会话与缓存亲和：把请求路由到 KV 缓存/记忆所在的节点；
新的生命周期原语：create、suspend、resume、destroy 等作为一等原语；
总之不管是"控制面架构"还是"数据面架构", 都需要面向 agentic 的特点演进, 直接照搬用还是比较难的
姚晓忠：
我理解短期内不会，K8s实在是太成熟、太庞大了，这就注定了它的演进是非常谨慎的，意味着我们现在Agent负载带来的大量、迫切的诉求，当前它是没法及时满足的。 那么大家先到的一种做法就是需要在现有的K8s基础上进行切分和加层，快速作出一个新的“跑在k8s上的控制面，来进行自治”。 等这一切到了一定的阶段，成熟了、收敛了，再被K8s的基座来吸收和消化，成为新的标准。
王泽锋：
我接触过的很多企业用户都提出了复用k8s底座的诉求，这出于两方面考虑，a）物理上统一资源池，可以实现Agentic Workload与传统微服务或者LLM Inference等Workload共池混部，提高资源利用率；b）统一的Infra团队可以share knowledge，人员效率提升。
但是正如问题1中讨论到的，K8s缺少合适的API primitive，对于Sandbox生命周期的各个状态，尤其是暂停、休眠、fork等操作应该进行显性语义支持的扩展。Kubernetes-sigs/Agent-Sandbox给出了一个探索性的实现，但是没有解决agentic workload 高频创删带来的APIserver压力问题。这也是为什么不少开源项目选择类似“overlay”的方案，将K8s作为部署底座，划出一块专用的资源来运行Agent应用，但是这种方案又带来的资源分配相对固化的问题。
观点讨论
@高丰：是的，从应用响应的维度，资源的 ready 和释放的速度和应用的速度其实差异很大
@郑然：主要是 K8S 设计之初不是按照 Agent 的特点设计的, 缺少了一些核心要素。
@高丰：让 Agentic Runtime 直接管资源，挑战很大，而 K8S其实提供了一层抽象。
@姚晓忠：K8s缺少了"暂停"和"恢复"等原语。
Question 3
主持人：在当前一些 Agent 应用场景中，Kubernetes 通常负责节点和 Pod 级的资源编排，Ray和 Agent Runtime 等系统提供了更细粒度的调度（Ray负责 Actor、Task 等任务级调度，推理平台或 Agent Runtime 还可能承担请求级和会话级调度）。这样的分层调度是否会成为常态？各层应分别负责哪些决策，彼此之间的边界应如何划分？不同调度层之间又该如何共享资源状态、协调优先级和资源抢占？
王昊奋：
分层会是常态，因为各层掌握的信息不同。Kubernetes 看容量和资源放置，Ray 看 Task、Actor 的计算依赖，推理引擎看组批和 KV Cache，上层执行系统看任务阶段与业务依赖。两个步骤技术上可以并行，不代表业务上允许并行，比如付款必须等审批完成。这种先后关系，应由理解任务语义的上层保证，不能让资源调度器猜。
跨层不必共享全部知识，只需交换明确的优先级、预算、截止时间、状态位置和安全暂停点。资源紧张时，底层提出回收要求，上层选择暂停对象。如果 Agent 还在后台试验新策略，这类探索任务就应与正式业务区分配额和优先级，不能为了“让自己变得更好”，挤占正在服务用户的资源。
观点讨论
@彭鑫：上下层视角不一样但同时上层又依赖下层，会不会导致冲突？
@王昊奋：肯定会，所以需要有专门的semantic layer来管理，识别和解决冲突。
金鑫：
Kubernetes负责集群管理，以Pod为单位进行分配，不感知Pod内部的Agent会话和状态。Agent Runtime管理Agent会话，包括相关状态、工具调用等。对于Agentic负载要求的高弹性、快速扩缩容，一种思路是优化/重写Kubernetes相关组件，另一种思路是让Kubernetes以粗粒度分配大块资源，然后由Agent Runtime根据每个Agent任务的实时需求将这些资源分配给相应任务，并对Agent Runtime的扩缩容进行系统优化以满足Agentic负载需求。
章明星：
目前看起来 k8s 主要负责最开始基础资源池的 provision 和提供多租户的能力，后面交给特定的 agent runtime 来细粒度调度。等需要更收敛了之后再吸收回 k8s。
存储资源目前都是存算分离的，写一套高性能 io 链路就行。cpu/内存资源比较复杂，现在是和上层 rl 框架联合调度的。
顾荣：
我觉得这种分层调度将会成为常态，本质上就是我们看到的服务语义层级形成了，这个是技术生态发展丰富的重要表现。个人觉得这个有点类似早期信息传输，从只有简单的1、2层，发展到了计算机网络TCP/IP协议多层。这个和人类社会的很多分工调度也很类似。
高丰：
我理解分层调度会成为常态，但正确的分法不是按粒度（Pod / Task / 请求），可以从按决策的时间常数与信息完备度来分。
K8s 层只看到资源声明、看不到内容，做秒级的容量决策；推理与会话层能看到 token 和缓存，做毫秒级的复用与路由决策；Agent 编排层能看到语义与工具，做任务级的规划与授权决策。三者不是上下级，而是各自掌握对方不具备的信息。
彭老师说的层间协调的关键，是共享的不是"资源状态"而是成本信号——底层向上暴露 cache 命中率、队列深度、显存水位，上层据此决定重排、降级还是抢占。KV Cache 亲和性路由就是典型例子：把同一会话的请求固定打到同一副本，这个维度 K8s 完全看不见。反面教训是 Mesos 的两级调度——层级划分本身没错，它死于层间缺乏反馈，上层不知道下层真实发生了什么。
观点讨论
@彭鑫：最后就是各种权衡，比如上层的最优策略可能因为下层不支持而进行调整追求次优解。
@高丰：分层是解决复杂问题的一个重要方法，将来应用也是一样的。
@胡昊：分层是解耦和利旧的现实选择，但多层次下（如果考虑：资源、负载、请求，可能还不只两层），协同的复杂度不是线性增长的，是指数增长的。每一层都有自己的目标函数、自己的决策周期、自己的信息视图，层与层之间的目标可能冲突，决策可能互相干扰，信息可能不一致。这是一个典型的NP问题：在多层目标函数不可比的情况下，找到一个全局最优的协同策略，计算复杂度随层数和资源规模指数上升。当前产业界还没有明确答案。这个问题的方向可能不是继续寻找全局最优的协同算法，而是接受次优解，并引入柔性的协同机制。多层协同的困难不在于缺少一个组件，而在于缺少一个能在目标函数不可比的情况下做权衡的机制。
胡昊：
分层调度是（如果保留 K8s 作为 HAL 时的）必然选择，真正难确定的是：层与层之间怎么协同。当前看到的实践是：Agent调度器可以完全by-pass API server。它不走声明式配置发布那条路径，不和Kubernetes调度器竞争同一个决策队列，通过二级池化来解决。这是可行的。但这里有两个容易被忽略的点：
即使Kubernetes只供应资源池这一层，这一层本身也已经在变。DRA的出现和持续发展，说明过去的硬件抽象不够用了。device plugin机制把设备当成黑盒，调度器只知道“这个节点有几张GPU”，不知道GPU之间的互联拓扑、显存层次、或者一张GPU能不能被多个工作负载按需切分。DRA把设备资源的声明、分配、生命周期管理独立出来，让GPU、NPU、FPGA可以作为带属性的资源被声明和调度。这本身就是资源池层为了适应新负载而做的改变。
多层协同，如果追求极致的资源利用率和敏捷度，本身可能是个 NP 问题。
郑然：
这个问题我认为分层是合理的设计, Ray 是一个计算框架, 类似 hadoop/spark 这样的技术, 负责任务层的编排逻辑, Ray 对 K8S 来说属于一种工作负载类型, 而 K8S 负责全局的资源调度和管理, 可以在全局视角做出最优的资源分配的决策, 也可以实现在线服务或者推理服务和 Ray 任务的混合部署. 针对 Ray 任务的特点, K8S 也需要设计适配层, 比如社区的 kubeRay 项目实现了这样的功能
史明伟：
分层调度是常态，我会认为有了AI之后Kubernetes 不是分层调度的必然选择。当 IaaS 操作足够简单时，完全可以由 IaaS 层的 Agent 直接承担节点管理、网络、存储、自愈等能力，上层 Runtime 只负责 Agent 语义调度。这样状态管理与优先级控制更直接，K8s 的复杂度反而成为不必要的中间层。
分层调度的边界按状态驻留粒度划分：底层管机器生命周期，上层管会话、沙箱、请求、GPU 与 Actor。K8s 原本承担的职责可以被 IaaS 层 Agent 替代，而不是必须由 K8s 承担。
直接基于 IaaS 调度，Session 与物理资源的状态关系更明确，优先级与抢占策略可以跨机器统一制定，不需要在 K8s 调度器和 Runtime 调度器之间反复协商。这种替代最适合单一、同构、大规模的 Agent 负载；如果集群里同时跑传统服务、微服务与 Agent，通用 K8s 仍然是更经济的选择。上层 Runtime 通过 Provider 抽象对接不同底层实现，底层是 K8s 还是 IaaS Agent 对业务透明，未来可以在两者之间切换。
简言之：分层调度必然存在，但分层的位置可以下移，K8s 只是其中一个可选实现。
姚晓忠：
分层已经成为常态，不同分层掌握的信息不同，集群层知道资源总量和租户配额，Runtime 知道哪些任务可以运行或恢复，让每一层都承担自己最了解的决策，是合理的。
王泽锋：
我觉得分层调度会成为常态（当然前提还是许多企业用户需要复用K8s底座，这与公有云的资源池管理策略并不相同），但不应该变成每一层各自做一遍完整调度，更不应先把集群资源按框架或应用静态切池。
Kubernetes 仍适合承担集群级的资源治理：节点、GPU、网络等资源的统一视图，以及配额、队列、公平性和抢占规则。Ray 或 Agent Runtime 则更了解任务、会话、工具调用和 sandbox 的运行状态，适合在执行过程中做细粒度决策，例如任务放置、会话复用、休眠恢复和弹性扩缩。
另外资源的共享和分配本身也应该是细粒度、敏捷的。Agent 负载的并发和资源需求变化很快，如果先为某个 Runtime 固定分配一批 Pod 或节点，再在其内部二次调度，容易形成资源闲置、状态滞后和调度边界僵化。相比之下，更理想的是让不同调度层共享统一的资源视图，并能根据实时需求快速申请、归还和调整资源。
所以关键不是把 Kubernetes、Ray 和 Agent Runtime 串成严格的层级，而是让它们各自保留最擅长的决策：集群层维护全局公平和资源边界，运行时处理高频执行语义；两者通过资源状态、优先级和抢占协议实时协同。这样才能同时兼顾 Agent 的低延迟需求，以及与训练、推理、微服务混部时的资源利用率。
观点讨论
@彭鑫：这个挺复杂的，越上面的层次对最终资源的感知越弱但对业务优先级的掌控最强，反之越下面的层次对最终资源的感知越强但对业务优先级的掌控最弱。
@顾荣：是的，哲学上来说，世界上最远的距离就是从“知道”（上层业务理解）到“做到”（底层资源调度）。
Question 4
主持人：随着长会话推理、多Agent协作和工具密集型任务的发展，记忆、KV Cache、分布式内存、存储带宽、网络拓扑和数据位置越来越直接地影响Agent性能，现有集群是否需要将这些能力纳入统一的资源描述、状态观测和调度体系？CSI、CNI 等既有机制能否通过扩展满足这些需求，还是需要由专用 Runtime、推理框架或数据平面进行更细粒度的管理？与此同时，面对更加动态和状态化的 Agent 工作负载，现有的可观测、弹性伸缩、故障诊断等运维能力需要做出哪些调整和创新？
王昊奋：
不能把所有状态都当成缓存。KV Cache 丢了通常可以重算，业务记录丢了可能导致重复执行，Agent 记忆则要回答“这条经验从哪里来、现在还适不适用”。如果工具版本或业务规则已经变化，过去有效的方法就未必还能用。因此，除了记录数据位置，还应保留知识来源、适用条件和版本依赖；这些信息会影响状态能否复用，而不只是影响访问速度。
运维也要从“机器有没有问题”走向“任务为什么没做好”。需要把执行步骤、证据、工具调用以及当时使用的策略版本串起来，才能判断失败来自资源不足、知识过期还是执行逻辑有误。尤其是 Harness 会持续调整时，没有版本记录和可重放的测试，就很难分清所谓进步究竟来自方法改进、资源增加，还是碰巧遇到了简单任务。
金鑫：
面向Agentic负载，需要从容器级指标向Agent语义指标演进。除了传统的容器级的CPU、Memory资源利用率等基础指标外，需要对Agentic负载增加新的指标，比如Agent思考步数、工具调用类型和次数、工具调用资源开销、会话时长等。
章明星：
内存池可能可以考虑设计类似 csi 的接口，记忆这些上层概念其实是独立的，而且变化的太快了，说不定还没标准化完就过时了。可观测性和隔离性很重要，可能 ebpf 之类的技术重要性会大幅提升，主要还是灵活配置和弹性的需求。
观点讨论
@胡昊：以 Mooncake 这样的 KV Cache 为例，数据的搬移和访问路径在经过多层抽象之后，还能不能保持物理路径上的最优/自优？这个恐怕是“是否需要建立新的抽象模型”的衡量标准。同时也和数据搬移路径有关：如果经过 CSI 会导致额外的复制发生，比如在超节点的情况下，CSI 如果限制了 CPU-offload 的能力，那么这种抽象就可能损害了物理路径最短的优化空间。
@章明星：是否最优只和放置/淘汰策略有关吧，上层资源管理的抽象似乎不直接影响。
@胡昊：我现在对这个问题还没有把握，原因就是：还不能判断当前的抽象、新的抽象会否影响极致的物理路径最短化，这个是现在这个算力、运力都稀缺的时代的一个关键要素。得一条一条看过来才行。尤其还有超节点的出现，多平面的拓扑结构，是否会让这种语义抽象付出额外的运行时成本还不好讲。
@郑然：没错, 超节点, 多平面等技术的普及也是需要重点设计的场景。
顾荣：
我认为现有集群非常有必要将这些Agent性能紧密相关的状态信息情况纳入统一的资源描述、状态观测和调度体系，从而更快、更准、更细地感知负载，从而支持更好的资源分配调度以及应用状态跟踪，并且我比较合适的做法就是通过扩展CSI、CNI 等既有机制去满足这些功能，尽量在Kubernetes标准化扩展的方式去设计最好，能够通过扩展CSI、CNI实现这样做比较好，不能够的再在这一层通过引入专用 Runtime等机制实现。是的，现有的可观测需要做更多的创新，除了系统层面之外，一些高级的数据结构和算法，比如概率型数据结构、近似算法等，复杂观测分析方法将有更多用武之地。
高丰：
记忆、KV Cache、分布式内存等不该纳入统一的资源描述与调度体系，也不该靠扩展 CSI、CNI 来解决。CSI/CNI 的设计假设是"存储和网络是通用资源、可脱离计算独立存在"；而 KV Cache 是计算的副产品——生命周期与某次请求绑定、不可序列化迁移、价值随时间衰减。两者性质根本不同，往通用存储栈上靠是南辕北辙。正确做法是推理框架自管 KV 的分配、驱逐与迁移，集群只暴露拓扑感知；Mooncake 的 KVCache-centric 架构、DeepSeek 的磁盘 KV 缓存，本质都是在绕过通用存储栈自建。
运维范式也要跟着换：可观测要从"服务健康"转向"上下文健康"——token 预算消耗、缓存命中率、工具调用是否陷入死循环；弹性伸缩要从"按 QPS 扩副本"转向"按会话数和上下文队列长度扩"。
郑然：
首先CSI管理的是"存储资源"，而KV缓存是按 token 粒度访问的细分状态，我认为本质是"计算状态"而非"存储资源"；CNI管理网络资源，而 Agent 需要的是数据位置感知路由等token粒度的流量控制，这更贴近应用层而不是资源层, 更适合单独设计, 这有点类似 service mesh 的技术理念.
面向 agentic workload 的特点, 我觉得还有很多挑战和创新空间, 主要包括:
设计面向推理服务包括kvcache在内的控制器: 充分考虑推理服务的编排需求, 包括模型并行计算单元, 网络拓扑亲和性, 请求路由, PD 分离, kvcache 服务等；
可观测：从"节点/容器指标"升级为"端到端轨迹", 一次 Agent 任务涉及多轮推理、多次缓存访问，用 trace 串联（OpenTelemetry GenAI 语义约定是重要趋势），并保留命令级轨迹日志供事后审计, 归因和效果优化是非常有帮助的；
弹性伸缩：从"按指标伸缩"升级为"按会话与负载预测伸缩"；
故障诊断：面向 Agent 策略/语义任务失败设计故障诊断方案而非资源失败, 比如工具用错、上下文污染等等。
姚晓忠：
资源方面，当前产业给的答案是不会全部塞进 Kubernetes 资源模型里，K8s 管设备与拓扑（DRA），专用数据平面管数据搬运（Mooncake），网关管决策（KV 感知路由），这些决策需要理解模型、缓存布局和请求状态，扩展 CSI/CNI 接口本身并不会自动获得这些语义。运维方面，以往主要关注服务健康指标，现在还要能感知应用负载指标，如关联任务、步骤、模型请求、工具调用，区分正在计算、等待外部依赖、等待人工和异常停滞等多种状态。
王泽锋：
我觉得需要先区分两类关注对象。第一类是与基础设施和资源管理直接相关的内容，可以逐步纳入 Kubernetes 的资源描述和调度体系。甚至可以通过 CRD 或 API 扩展，描述一个 Managed Agent 的部署方式、资源诉求、隔离等级、生命周期策略，以及是否允许休眠、迁移或恢复。Kubernetes 关注的是：这个 Agent 应部署在哪里、需要什么资源、处于什么基础设施生命周期阶段。
第二类是 Agent 的业务语义，例如记忆内容、Session 上下文、运行轨迹、工具调用过程和推理计划。这些更适合由 Agent Runtime 或上层框架处理，没有必要要求 Kubernetes 理解，更不应让它参与这类业务语义的coordination。
当然，集群层和 Runtime 之间需要协同。KV Cache 是否可复用、会话是否活跃、恢复是否紧急、模型是否已预热、任务能否迁移或休眠，都会影响资源利用率和调度效果。但两层之间共享的应该是经过收敛的资源信号和明确的策略约束，而不是把完整的业务状态不断同步给 Kubernetes。
这样既能让 Kubernetes 继续承担统一的资源治理和基础设施运维，也能让 Runtime 保持对 Agent 业务语义的控制权，避免系统因为跨层耦合过深而变得难以扩展和维护。
观点讨论
@顾荣：比较认同Kevin的这个观点，个人认为如果能够尽量归属到第一类的放到第一类比较好，这样尽量下层，这就是基础设施的意义所在。
Question 5
主持人：未来三到五年，面向Agentic 应用的基础设施可能形成怎样的技术体系和总体架构？未来基础设施最需要突破的关键能力是什么？哪些能力有望沉淀为跨场景复用的通用基础设施能力或形成新的规范？哪些能力适合平台自主建设，哪些更适合开源项目和生态推动发展？
王昊奋：
我倾向于认为，资源底座之上会形成更稳定的 Agent 执行体系，知识、记忆和策略也会成为可管理、可验证的对象。最近的 RSI 探索与此有关：Agent 不只是完成任务，还尝试修改自己的工具使用方式、上下文组织或 Harness，再通过评测保留有效改动。不过，积累记忆、改一次提示词，并不等于实现了递归自我改进；关键要看改进后的系统能否进一步提升自身的改进能力，而不是只提高某次任务的得分。
对企业来说，眼下更实际的目标是“允许改进，但改得有据可查”。经验要有来源和适用范围，修改要能评测、回滚，权限边界和最终验收标准不能由 Agent 自己随意改。沙箱、检查点、执行记录和评测接口可以由生态共建；领域知识、业务规则和成功标准需要企业自己掌握。未来的竞争，不只是看谁的 Agent 会做事，还要看谁能让它从经验中改进，又不把错误越积越多。
金鑫：
针对Agentic负载的长程、有状态、工具调用等特点，构建Agent Runtime，推进Agent的沙箱、状态管理、可观测等方面的技术创新和规范化，实现高密度、高弹性、高资源率用率。从Agent Runtime到Agent沙箱等方面都有机会形成好的开源项目，推动生态发展。
章明星：
我觉得根本上还是需要把 serverless 这个词陈诺了但是实际上现有架构根本没做到的极致弹性真的实现。这个需要池化，ckpt/restore 等一系列的功能的实现，同时还是在强隔离（至少 microvm 级）假设下实现。开源还是很重要的，至少我们会持续推进大模型厂商底层 agent infra 的开源。
顾荣：
最后这个问题非常宏大也令人期待！！我想提醒关注的一点是：从基础设施的视角来看，以前我们研究的是人类如何用应用，从而更好的满足他们，现在Agentic 应用时代，将会更多关注应用如何调应用，并优化整个流程。这一切对于基础设施要求更高，系统自发演化、自主优化、自生态化的需求会更加旺盛。由于各种异构复杂、跨组织、跨平台等等问题，开源合作将变得更加重要。5年之后的这个沙龙，有可能就由我们的智能体在彭老师智能体的编排下完成。
高丰：
未来三到五年会形成 K8s 底座 + Agent Runtime 控制面 + 上下文/记忆层作为独立基础设施的三层结构。K8s 不会消失，但会退到后面。
最需要突破的是两个能力，正好对应 Agent 的两条主线。一是上下文的数据平面：可寻址、可复用、可计费、可隔离的记忆存储——类似今天我们有数据库之于业务系统，却还没有一个"上下文数据库"之于 Agent。二是Agent 的授权与审计基础设施：细粒度授权（谁允许这个 Agent 在什么条件下调用哪个工具）、可撤销、每一次工具调用都留下可追溯记录。
生态分工上，K8s 与 CNCF 继续做底座和隔离原语；上下文层与 Agent 授权协议最可能由开源和标准组织推动（MCP 之于工具调用、OAuth 之于授权就是这样的路径）；而企业内部的数据治理层必须平台自建——它和自家数据资产强绑定，通用不了。
补一句我们的实践：在做面向智能体的数据价值溯源的工作中，我们意识到，"数据从哪来、被谁用、产生了什么价值"这个问题，在 Agent 时代会被放大成授权决策的输入——溯源正在从一项合规需求，变成安全基础设施。
胡昊：
我倾向于认为“一个资源底座、多种调度模式、多样化运行时、语义资源治理”的分层体系更可能成功。四个判断。
Kubernetes传统的硬件使能和资源池化逻辑仍然成立，而且还在进一步完善。DRA把设备资源的声明、分配和生命周期管理从kubelet的device plugin机制里独立出来，让GPU、NPU、FPGA乃至超节点内存池可以作为一等资源被声明和调度。超节点的抽象也在往这个方向走，灵衢的内存统一编址、鲲鹏超节点的统一内存池，本质上都是把“节点”这个概念的边界向外扩展，让资源池化的粒度从单机走向机柜级乃至更大。这一层的工作不会消失，反而会继续加深，因为它解决的是“资源从哪来、怎么被安全地隔离和交付”这个任何上层都绕不开的问题。
调度器会多元化，而不是收敛到一个统一调度器。面向常稳业务的传统调度模式仍然需要，面向Agent的调度模式则是另一套实现策略。两类调度器可以在调度时完全by-pass API server，直接和资源池化的供给能力对话，但共享同一个资源池。共享的是资源供给能力，分开的是调度决策路径。问题3里提到的多层协同困境，在这里会以更具体的形式出现：传统调度器优化SLO达标率，Agent调度器优化任务完成时间加缓存命中率，请求层优化KV Cache复用率，这些目标函数不可比，当资源紧张时，没有任何一层能独立做出全局合理的裁决。这不是某个组件缺失的问题，是协同机制本身需要重新设计。
在真正执行上，无论传统负载还是Agent负载，底层运行时机制会更加多样化。沙箱隔离机制不只一种选择：microVM、gVisor、容器、wasm 隔离，各自适用于不同的安全等级和启动速度要求。存储和快照机制也会分化，数据搬移和远程数据访问机制同样如此。Kubernetes和Runtime在这一层的分工是：Kubernetes确保这些运行时机制能拿到它们需要的硬件资源，Runtime决定在给定资源上跑哪种机制。
最终的难题会落在语义资源的治理上。当前的资源访问控制，前提是资源本身在Kubernetes的资源模型里。GPU在，存储卷在，网络端点在。但Agent在执行中访问的大量资源不在这个模型里：GitHub issue、PR、文档、数据记录、API配额。这些资源有状态、有权限边界、有生命周期、有归属关系，它们应该像PV或者GPU一样被声明、被授予、被回收。当前它们不能，因为Kubernetes的资源模型里没有“语义资源”这个类别。访问一个GitHub issue，在Kubernetes眼里和访问任何外部HTTP端点没有区别，都是一个网络连接。
语义级别+动态柔性治理的难点，在机器化系统之上很难解决，但 AI 本身可能就是答案，所以会落在 AI for infra 上。
郑然：
面向 agentic workload来说,我认为主要的演进方向还有:
更高的容器密度, 优化资源效率
更快和更大的控制面架构, 满足大规模和高速控制的能力
精细化的网络策略和内外网访问加速, 支持灵活的网络访问
智能体安全, 从模型, 技能, 工具, 运行时等维度保障智能体的行为安全可控
回顾云原生技术的普及过程, Kubernetes技术的成功很大程度上得益于其强大的扩展性, 通过 CRI/CNI/CSI 提供向下面向云的扩展接口, 利用 operator 机制提供向上面向应用层的扩展接口, 最终成为事实性标准, 演进成云原生时代的"操作系统". 众所周知, agent harness 由 loop 循环, 工具调用, 上下文组织, 会话管理, 多 agent 协议等核心部分组成, 不过相比于云原生时代的kubernetes技术, 我觉得还没有出现agent时代的"kubernetes", 能够同时提供"向上"和"向下"的扩展接口. 未来将agent框架和 agent runtime 演化为事实性标准, 让agent应用在此基础上二次开发和"向上""向下"按需扩展, 我觉得这是一个非常值得期待的方向, 并且这样的技术一定是通过开源社区来实现的。
姚晓忠：
当前我做不了太清晰的判断，不过“资源底座 + Agent生命周期管理 + 决策网关 + SLO/成本治理”这几层是应该存在的。
史明伟：
Serverless 的核心单位从“请求”变为“会话”。基础设施需要直接管理 Session 的创建、活跃、空闲、休眠、恢复、迁移和销毁。 我认为的关键演进方向，有些已经是正在发生的，以前是上层适配底层，新的AI驱使下Agent层不会太多迁就底层的架构演进节奏。
会话成为一等资源：调度、计费、隔离、可观测都以 Session 为单位，而不是 Pod 或函数实例。
K8s 角色变薄下移：通用集群中 K8s 仍是经济选择，但专有场景下可以直接用 IaaS 层 Agent 管理机器，减少中间抽象。
记忆与 KV Cache 分层治理：记忆管“上下文里放什么”，分 L0-L3；KV Cache 管“计算结果如何复用”，分请求级、会话级、公共前缀级和持久化级。
执行平面协议标准化：类似于容器时代的 OCI，Agent 与沙箱之间的交互协议最终需要事实标准，但前提是杀手级应用出现。
上下文动态注入驱动底层设计：架构分离、数据迁移、上下文注入会反向决定底层需要提供什么样的存储、网络和沙箱能力。
王泽锋：
关于问题5，我比较期待 Agentic 基础设施逐步形成三层协同的体系：
统一资源底座：以 Kubernetes 为核心，承载计算、存储、网络、设备、身份权限和多租户治理。
Agent Runtime：管理 sandbox、会话、工具执行、状态恢复和隔离。
推理与数据平面：处理模型路由、KV Cache、数据位置和网络路径等高频决策。
重点不是把所有能力都放进 Kubernetes，而是让各层通过清晰、收敛的资源和策略接口协同工作。
我期待看到几项能力进一步成熟：高频、细粒度的资源调度；状态化 sandbox 的休眠、恢复和迁移；结合 KV Cache、数据位置和网络拓扑的调度；以及能够追踪模型、工具、sandbox、存储和网络全链路的可观测和故障诊断能力。
其中，资源描述、隔离与生命周期、设备和拓扑感知、配额与优先级等能力，有机会沉淀为跨场景复用的通用基础设施，并由 Kubernetes 生态和开源社区共同推进。Agent 的记忆、规划、工具协议和业务工作流则仍会快速演进，更适合由 Runtime 和应用平台持续探索。
平台可以把这些能力组合成可运营、可治理的产品；开源社区则可以推动底层接口和跨 Runtime 的互操作性，避免未来形成新的割裂。
以上部分内容转载自
CodeWisdom微信公众号
欢迎关注CodeWisdom，Codewisdom平台由复旦大学软件工程实验室运营，提供智能化软件开发平台及线上沙龙相关资讯，关注可了解更多智能化软件开发的最新消息~
Panel：AI原生基础设施关键技术挑战 | openFuyao#KADC 2026
