1. 选题缘由一场罕见的技术代际对谈在 KubeCon 这类技术峰会上台上的嘉宾换了一茬又一茬但有一类对谈我会专门搬个凳子坐下来听——就是上一个时代的缔造者和下一个时代的布道者面对面碰撞。这次把 Kubernetes 核心创始团队的重要成员请来和 Agent Substrate 方向的实践者聊为什么要在 K8s 之上再造一层 Agent 原语就属于典型的代际对话。为什么值得关注因为这位对谈嘉宾是真正定义过原语的人。当年 Pod、Service、Deployment 这批 K8s 原语解决的是分布式系统里最头疼的调度、编排、自愈问题它把几千台机器的资源抽象成了几个概念让后来的开发者不用再自己写状态机。现在轮到了 Agent。过去两年我见过太多团队把 Agent 项目从 demo 推到生产时撞上同一堵墙模型能力早就够用了但工程底座根本撑不住——会话断线后没有恢复能力工具调用无人审批多个 Agent 协作时互相踩踏资源消耗预判不了出了问题翻日志翻到怀疑人生。对这种困境基础设施出身的人会本能地问一句K8s 不是已经有全套编排能力了吗Job 跑批、Deployment 管实例、HPA 扩缩容凭什么说不够这场对谈的答案非常明确K8s 编排的对象是无状态的进程而 Agent 的核心资产是有状态的认知过程两者不是同一个物种。容器化解决的是代码怎么在不同机器上稳定跑起来Agent 需要解决的是一个自主决策的实体怎么在复杂环境里可靠地完成目标任务。前者是执行层的抽象后者是意图层的抽象中间缺的那一层就是 Agent Substrate 想补上的。这篇文章我想抛开对谈现场那些客套和宣传话术用工程视角把这层新原语拆开讲透K8s 原语和 Agent 工作负载之间到底哪些错位了Substrate 这层需要提供什么能力才能填补错位以及对一个正在做 Agent 工程的团队来说什么情况下值得上车、什么情况下只是凑热闹。2. 原语错位分析K8s 编排模型面对 Agent 的四个失效场景2.1 无状态假设首当其冲调度系统杀掉的不只是容器K8s 的一切基石建立在实例可以随时被杀掉、随时被重建这个假设上。ReplicaSet 里的 Pod 被驱逐了kubelet 重新拉一个起来流量切过去用户无感知。这套逻辑对无状态 Web 服务完美但放到 Agent 上第一个矛盾就爆发了。Agent 的价值密度恰恰体现在它的状态里一段和用户进行了 40 分钟的复杂对话、一个在执行中被中断的长任务、一份需要跨会话保留的用户偏好记忆。这些状态散落在推理进程的上下文窗口、外部记忆存储、还有各个工具调用的中间结果里。如果调度系统基于节点压力或者因为一次滚动更新就把 Agent 实例重建了从用户视角看这不仅仅是断线重连而是我的工作全丢了。我在实际项目中踩过一次典型事故。当时我们做了一个能够自主完成市场调研报告的 Agent运行在 K8s 集群里用的是普通 Deployment。某次节点内存水位过高触发了驱逐Pod 被重建那个 Agent 跑到一半的调研任务直接归零——20 多次网页访问、数据抓取和中间的推理链全部遗失。用户回来看到的是一个重启过的对话之前所有上下文全没了。这个场景下K8s 的自愈能力不但没帮忙反而成了破坏者。K8s 原语里也不是完全没有状态方案StatefulSet 保序、PVC 存数据但这些方案的思路是把状态挂在实例旁边而 Agent 的状态是流动的、跨工具的、分布在多个外部系统中的。用一个稳定的存储卷去兜一个对话上下文 工具状态 长期记忆的组合体根本兜不住。对谈里反复强调的那句话非常准确Agent 需要的是会话级的状态原语而不是实例级的状态挂载。2.2 确定性生命周期失效Agent 不是跑完就退出的 JobK8s 的另一个核心假设是工作负载有明确的终态Job 跑完一批数据退出CronJob 按点触发Deployment 里的长跑服务虽然不退出但它的行为逻辑是可预期的。Agent 打破了所有这些边界。首先Agent 的任务边界不由代码声明而由用户意图决定。一个写邮件的 Agent你永远不知道它这次是回一封三句话的简信还是要起草一份 20 页的提案一个数据分析 Agent可能跑完一个 CSV 就交差也可能陷入 50 轮的迭代探索。这种情况下K8s 标准的资源配额 超时控制策略完全失效你设置 10 分钟超时复杂任务会频繁被杀你设置 1 小时超时简单任务又白白占用着 GPU/CPU 配额。更麻烦的是Agent 的执行路径天然带有不确定性。自然语言驱动意味着同样的输入可能走出完全不同的工具调用序列。对谈中那位 Agent 侧的嘉宾举了一个非常形象的类比K8s 编排的是图纸明确的水管工而 Agent 是你只说了要个花园它自己决定种什么花、挖多少土、买什么肥料的水管工。你把这样的实体丢进以确定性为设计前提的调度系统里调度器的预测模型自然全部失准。还有一个被普遍忽视的点Agent 工作负载的结束本身是需要被编排的状态。K8s 里 Pod 退出就是退出日志存下来就算交代了。但 Agent 任务结束时需要产出交付物、需要做结果校验、需要把上下文归档进长期记忆系统这些都属于任务生命周期的一部分。如果只用原生 Job 语义去套任务被标记为 Completed 的那一刻真正重要的收尾工作反而没人做了。2.3 扩缩容维度失配按 CPU 调度的 HPA 管不了上下文窗口HPA 是 K8s 给运维人员最顺手的工具之一根据 CPU、内存等指标自动扩缩 Pod。但对 Agent 来说真正决定资源需求上限的往往不是 CPU而是上下文窗口和外部工具延迟。一个卡在长文档推理上的 Agent它的 CPU 使用率可能一直不高但上下文窗口已经逼近极限随时可能触发 token 截断或模型幻觉加重。另一个执行网页抓取的 AgentCPU 占用低得可怜但网络 IO 和第三方 API 的响应时间完全不可控。这两类场景HPA 的指标模型一个都捕捉不到只能眼睁睁看着服务质量波动。而且Agent 的扩缩容不是简单的加更多实例。如果你的 Agent 依赖会话连续性加一个全新 Pod 并不能分摊现有会话的负载新 Pod 只在承接新的对话时会话才有效。多实例横向扩展的前提是流量可分发、会话可重放但当前的 Agent 往往会话状态深度绑定某一个实例的推理上下文。换句话说你在 K8s 层面做的 AutoScaling很可能只是让集群里有更多闲着的 Agent 实例真实的瓶颈还堵在原来那个 Pod 里。对谈里提到的一个思路我很认同Agent 场景的扩缩容应该建立在会话粒度上而不是实例粒度。系统需要知道当前有多少活跃会话、每个会话处于什么阶段、上下文压力有多大然后再决定是让现有 Agent 实例继续承接、还是把新会话路由给新实例、或者触发某个长任务的状态快照和横向转移。这个逻辑远不是HPA 看一眼 CPU 就加 Pod能覆盖的。2.4 网络与服务模型失效工具调用不是 Service 流量K8s 的 Service/Ingress 模型解决的是东西向流量服务发现、南北向流量负载均衡的问题。对常规后端服务这是标准答案。但 Agent 和外界打交道的主要方式不是被请求而是主动调用工具——访问网页、调数据库、触发支付接口、操作内部系统。这个差异导致两个管理盲区。第一Agent 对外部工具的所有调用本质上都带有副作用。一个普通后端服务调支付接口是业务逻辑里明确的、经过评审的代码路径一个 Agent 调支付接口是模型在推理过程中自主产生的决策。如果不做一层额外的审批、记录和控制系统就像把公司公章的保管权交给了 AI——不是不能给但必须有一道闸。第二Agent 的网络身份是模糊的。K8s 的 NetworkPolicy 可以精细化到 Pod 级别但一个 Agent 实例在执行任务时用户可能中途改变目标它可能调用 A 工具失败后转向 B 工具访问路径充满动态性。用静态网络策略去约束一个自主决策实体你会面临两难策略写死了Agent 失去灵活性策略放开安全审计形同虚设。我在一个金融客户的场景里实践过这个痛点。他们希望 Agent 可以访问内部数据仓库但所有访问要能被追溯。用传统 Service 模型你能看到的只有哪个 Pod 在什么时间访问了哪个 Endpoint但审计需要的核心信息是这次访问是源于用户的哪个请求、Agent 当时在完成什么意图、调用的上下文是什么。这些信息不在网络层而在 Agent 的推理轨迹里。这个例子让我彻底理解了Agent 的基础设施不能只关心网络字节要关心决策过程。维度K8s 现有原语Agent 真实需求状态管理PVC 卷挂载、StatefulSet会话级快照、跨系统记忆、上下文续接生命周期Pod 创建/终止、Job 完成退出意图驱动边界、动态时长、结果交付流程扩缩容HPA 基于 CPU/内存指标会话数、上下文压力、工具延迟、推理进度网络访问Service/NetworkPolicy 基于静态地址工具调用审批、决策路径审计、副作用控制可观测性容器日志、指标、追踪推理轨迹、工具调用链、意图完成度、token 消耗3. Agent Substrate 在补什么从资源编排到认知编排的能力层设计3.1 会话成为一等公民状态不只是存起来而是可调度、可迁移、可恢复对谈中最核心的论断是 Agent Substrate 要把会话Session提升到和 Pod 同等的原语地位。Pod 是 K8s 的最小调度单元会话应该成为 Agent 平台的最小状态单元。这个原语要解决的问题非常具体当 Agent 实例故障、被驱逐或者需要升级时系统必须能把整个会话冻结、转移、在另一个实例上精确恢复。这比简单的持久化复杂得多——它要求底层能够快照模型的推理状态、工具调用的中间结果、外部 API 返回的临时数据还要能在恢复时重建一致的上下文。在实际落地时会话原语至少包括这几个操作挂起Suspend——把会话状态完整归档恢复Resume——在任意有资源的实例上还原会话分叉Fork——基于某次会话的历史派生出一条新的探索路径转移Migrate——跨实例、甚至跨集群的会话热迁移。有了这套操作Agent 才能真正脱离单实例的物理绑定享受到和容器化应用一样的调度自由度——但前提是这种自由度建立在会话语义之上而非物理实例之上。3.2 为每一次工具调用建立审批与审计门Agent 原语层必须提供的一个基础设施能力是对工具调用的结构化拦截。这里的核心不是简单地放行或阻断而是要营造一种确定性任何一次有副作用的外部调用都经过一个可配置的策略网关。策略网关的职责包括验证该 Agent 是否被授权调用这个工具、检查当前调用的参数是否符合预设规则、确认本次调用的预估成本在预算范围之内、记录完整的调用参数和返回结果用于事后审计。高风险的调用场景支付、删除、修改权限还需要进入人工审批队列等待确认后再放行。这个设计和 K8s 的 Admission Controller 在思路上一脉相承——都是在操作真正生效之前插入一道业务逻辑闸门。区别在于K8s 拦截的是资源创建请求Substrate 拦截的是 Agent 的每一个自主决策动作。这种拦截必须足够轻量不能给每一次工具调用都增加几百毫秒延迟同时要足够灵活支持基于意图、用户、工具类型、成本阈值的多维规则组合。我在实践中的判断是这一层有没有决定了 Agent 系统是玩具还是生产系统的分水岭。3.3 预算、配额与多 Agent 协作拓扑把钱和关系变成调度参数一个容易被低估但生产环境必须解决的问题是 Agent 的资源消耗治理。一个 Agent 跑一个晚上可能烧掉上千次 API 调用如果这些调用不是按次计费的内部服务账单会教做人。Substrate 层需要把Token 预算、调用次数预算、执行时长预算作为一等概念纳入调度和管理支持在任务层级设置上限超限时自动降级、终止或转入人工处理。对谈中另一个重要话题是多 Agent 协作的管理。当系统里不再只有一个 Agent而是有一群分工明确的 Agent 时它们之间的通信拓扑、任务委派关系、依赖关系需要被显式地建模。沿用 K8s 的经验K8s 把进程之间的通信抽象为 Service隐藏了背后实例的流转Agent 层也需要类似的抽象把一个 Agent 向另一个 Agent 发起协作请求的过程变得可观测、可路由、可重试。不同之处在于Agent 之间的交互不是简单的 HTTP 调用而是带有语义的任务委派——发起方需要传递目标、约束、上下文接收方可能理解有偏差甚至需要澄清和追问。所以这个协作原语比 Service 复杂得多它要管理的是任务语义的传递而不是网络字节的转发。3.4 独立编排平面为什么这层不能只是 K8s Controller而需要独立平台层这里有个很自然的疑问上述这些能力写一堆 K8s Controller/Operator 不也能实现吗为什么非要另外造一个新层对谈的回应点到了本质K8s Controller 的抽象边界在集群内部而 Agent 的编排诉求天然跨越集群边界。一个 Agent 可能运行在 K8s 集群里但其记忆系统可能托管在外部向量数据库工具调用打在第三方 SaaS 上涉及的数据流跨越多个安全域。如果你把所有编排逻辑塞进 K8s Controller就要把云厂商的数据库、第三方 API、甚至用户端环境全部抽象成 Kubernetes 资源这个复杂度会迅速失控。另一种理解方式是把 K8s 当作 Agent Substrate 的一种执行后端。K8s 负责解决Agent 进程跑在哪里的问题Substrate 负责解决Agent 的认知生命周期如何管理的问题——状态在哪恢复、上下文如何延续、工具调用如何管控、协作如何编排。前者是底盘后者是驾驶逻辑。两者有接口Substrate 调用 K8s API 创建/销毁底层工作负载但各自的抽象层级完全不同。这个分层思路和我最近在多个 Agent 框架项目里看到的趋势完全一致。大家逐渐认识到用Workflow 编排工具管 Agent 流程是对的但 Agent 平台需要的是一整套状态、记忆、安全、治理能力这些已经超出了单纯流程编排的范畴变成一个独立的平台域问题。4. 工程现实判断现在要不要上 Substrate以及过渡阶段怎么走4.1 什么场景值得认真考虑 Substrate 方案听完一套新技术理念最该问的问题永远是关我什么事。根据我对多个 Agent 生产项目的观察以下三类场景当前的痛感最强烈也最值得关注 Substrate 类方案的落地第一类是多 Agent 协作型生产系统。多个 Agent 承担不同角色、需要大量交接上下文、还牵扯到不同的工具权限范围。没有协作层的显式管理系统运行一周后就是一团乱麻消息丢失、任务重复执行、状态错乱。这类团队迫切需要协作拓扑和会话记忆两个原语。第二类是对审计和合规有硬性要求的行业。金融、医疗、政务领域的 Agent 应用任何一个工具调用都需要可追溯。这类场景需要的不是更聪明的模型而是可控的执行层。Substrate 的审批链和审计日志能力在当前所有替代方案里是最完整的设计。第三类是Agent 已经规模化上线、开始被基础设施问题反噬的团队。比如上面说的会话丢失、资源成本不可控、扩缩容失效。这类团队已经有了真实体感转型的 ROI 非常清晰。4.2 什么场景先别凑热闹反过来说如果你处于以下状态我建议先别碰 Substrate把现有方案做好再说单 Agent 的垂直应用、纯 demo/PoC 阶段、团队连基础 Observability 都没做好的时候。一个连日志都收不齐、API 调用都没有 trace 的系统引入再先进的编排层也是沙滩上盖楼。技术和需求是匹配的过早引入抽象只能是负担。4.3 过渡路径不要在 K8s 上干等先补齐四个软原语如果你判断自己的场景确实有需要但团队还没准备好引入完整的 Substrate 平台我的建议是先在自己的 K8s 之上补一套轻量原语把核心思想提取出来用自己能控制的代码实现。具体而言我实际操作过的一条路径是分四步走建立会话持久化层把每次完整会话的快照包括消息历史、关键中间结果、当前任务状态写入对象存储或数据库而不要依赖 Pod 本地磁盘。设计好通过快照恢复任何一次历史会话的接口所有 Agent 实例只做无状态计算状态全在这层读写。给工具调用包一层 Sidecar 代理让所有外部调用走一个统一的代理网关在网关上实现审批、记录、频控和预算统计。这一步的代码量并不大但效果立竿见影——立刻就有了可审计的外部访问。按会话而非实例设计观测指标在现有监控系统上除了 Pod 级别的 CPU/内存指标额外记录会话存活数、会话平均长度、单会话工具调用次数、token 消耗总量、任务中断率。很快你就能看到传统指标完全看不见的东西——比如最贵的会话实际上消耗了多少资源、哪个工具链路的失败对成功率影响最大。用声明式的方式管理 Agent 运行策略把路由规则、审批规则、预算规则放进配置中心用 GitOps 的方式做版本管理。规则变更走 Code Review而不是靠运维同学在生产环境敲命令。这套半套 Substrate方案足够支撑一个中小规模 Agent 系统稳定运行大半年。等它扛不住的那一天你对原语层的需求清单已经写得明明白白再选型时有的是底气。4.4 选型评估清单聊 Substrate 方案时重点问什么最后给一份自己整理的评估清单去跟开源项目维护者或者厂商聊的时候按这个列表逐项过基本不会被宣传话术带跑会话恢复的粒度支持断点精确恢复还是只能从头开始恢复时是否需要原始 Agent 实例仍存活工具审批链路的可配置性哪些环节是引擎内置不可改的哪些是开放接口可以接入现有审批系统的协作拓扑是否支持动态建模固定角色固定链路还是支持运行时动态演进成本控制是否覆盖全链路只统计模型 API 费用还是连工具调用次数和外部服务成本一起管是否支持多集群与混合部署编排面能不能跨云、跨本地审计日志能否支持合规需求记录到什么粒度能否导出到 SIEM 类系统对谈收尾时那位Kubernetes 之父有一句话说得挺通透当年容器编排解决了应用如何在全球规模运行的问题这次 Agent 编排要解决的是智能体如何在全球规模协作的问题。两者底层逻辑都是用好的抽象消灭复杂度只不过这次抽象的对象从无状态进程变成了有认知的实体。我个人的体会是K8s 和 Agent Substrate 不是替代关系而是接力关系——前者已经完成了一个时代的工程化使命后者正在为下一个时代打地基。就算你现在还用不上完整的 Substrate 方案把会话原语、审批原语、协作原语这三个思维模式带进现有 Agent 项目的设计里很多坑就能提前绕过去。