在Kubernetes上构建Agent Substrate：为智能体打造运行时原语

最近看了一段 Kubernetes 创始人与 Agent 框架团队的对谈录QA 环节有人抛出一个特别直接的问题容器编排已经做得这么成熟为什么还要在 K8s 上面再给 Agent 造一层原语听完回答我反而更确信了一件事——容器只解决了 Agent 的“住所”Agent 真正需要的是一整套面向智能体的运行时语义。今天这篇文章不去复述整个对谈而是从这个问题出发把 Agent Substrate 到底是什么、要解决什么、以及如何在现有 K8s 集群里动手实现一次讲透。内容适合正在用 K8s 却又为 Agent 状态和会话管理头疼的开发者也适合正准备做 Agent 平台的架构师。1. 先对齐一个基本事实K8s 不知道 Agent 是谁1.1 容器只是 Agent 的身体不是大脑很多人的第一个反应是“Agent 不也是跑在容器里嘛调度好容器不就行了”。这个理解只看到了物理载体没看到 Agent 的执行模型。一个普通的 Web 服务是无状态的请求进来响应出去K8s 的 Deployment、Service、HPA 管好副本数就够了。但 Agent 不一样它有一个“思考过程”这个过程跨域多次工具调用、多轮用户交互甚至需要保留上一个小时之前的上下文。我见过不少团队把 Agent 塞进 Pod 里然后发现 K8s 视角里暴露出来的只有 CPU、内存、重启次数至于这个 Agent 到底卡在哪一步、它记住了什么、为什么同一个问题换一个 Pod 实例就没有历史平台层完全看不见。这不是 K8s 不行而是它的设计目标本来就不是理解“智能体”这种业务实体。K8s 说“我帮你把进程跑起来”但 Agent 需要的往往是“我帮你把一段连续的认知活动跑完”。所以容器是 Agent 的身体不是大脑。身体可以由 K8s 来调度、重启、伸缩大脑的状态和决策过程必须由更高一层来管理。这也是 Agent Substrate 出现的最根本原因。1.2 直接用 K8s 编排 Agent 的尴尬现状我先讲一个真实踩过的“草台班子”式编排有人用一个 Deployment 跑 Agent API没有任何会话持久化用户跟 Agent 聊了半小时中间一个节点扩容滚动更新所有连接断掉重连Agent 就忘了用户叫什么。用户以为自己在跟同一个智能体对话其实底层 Pod 已经换了一批。更吓人的是把记忆塞进 ConfigMap 的玩法。Agent 推理过程中把中间结果写入 ConfigMap一旦更新配置触发滚动重启整个 Agent 资产生命周期被打断之前积累的上下文全部清零。还有团队用 Job 跑 Agent 任务Job 本身是一次性的任务执行不到一半遇到外部 API 超时重试机制没用直接 Failed用户只能手动重新发起连从断点续跑都做不到。这些问题的共同点是K8s 原生原语面向的是进程生命周期而 Agent 的诉求是任务生命周期和用户生命周期。进程挂了可以重建任务断了必须知道断在哪Pod 可以随便换但一段和用户的对话一旦丢失体验上就是不可接受的。于是大家开始在自己的业务代码里硬编码一堆调度逻辑造出比 K8s 还复杂的轮子。1.3 对谈里的那个比喻对谈里有个比喻我印象很深K8s 给了你一套房子Agent 是房客。你给房客发一把钥匙让他住进去这没问题。但房客住在里面需要的是床、桌子、水电网络、邻居关系、以及“我上次把东西放在哪儿”的记性。你不可能每次都要房客自己造家具。容器编排负责的恰恰只是“发钥匙开门”这件事居住期间的秩序要靠房客自己搭这就是为什么需要在 K8s 之上造一层新原语。这个比喻和我在生产环境里的体感完全一致。Agent 不是单纯的进程它有角色、有技能、有上下文、有记忆、有协作关系。这些概念无法用 Pod 和 Service 表达。你可以用 CRD 强行把这些概念表达为自定义资源但如果你只是定义一堆 CRD 而没有配套的控制器和运行时语义那和在业务代码里硬编码没有本质区别。真正要造的是一套能让“房客”安心住下来的基础设施也就是 Agent Substrate。2. 给 Agent 造的新原语到底长什么样2.1 Agent 原语声明一个智能体很多人第一次接触 Agent 原语时都会问这不就是一个模板吗和 Helm Chart 有什么区别区别在于 Helm Chart 描述的是怎么把 Pod、Service 等对象部署出来而 Agent 原语描述的是一个智能体的意图和能力边界。一个完整的 Agent 资源应该包含这些内容底层的模型标识、系统提示词、绑定的工具集、资源配额、最长运行步数、会话策略、审计策略。这些字段在传统的容器编排里找不到对应关系。模型标识不是镜像地址工具集不是端口列表系统提示词不是环境变量。它是一个独立于容器实现之上的概念层。举一个实际的设计例子我常用的 Agent CRD 大概长这样apiVersion: substrate.example.com/v1 kind: Agent metadata: name: support-bot spec: model: gpt-4o-mini systemPrompt: 你是客户支持助理回答要简洁必要时调用订单系统查询。 tools: - name: order-api endpoint: http://billing-service:8080 permission: read resources: cpu: 500m memory: 256Mi maxSteps: 10 sessionPolicy: ttl: 24h status: phase: Ready sessions: 12这个 YAML 里没有告诉 Kubernetes 怎么跑容器它只说明了一件事我需要在集群里“存在”一个具备某种能力的 Agent。具体如何映射到 Deployment、StatefulSet、Service应该由 Substrate 的控制器去操心。这才是“声明式”的正解用户表达业务意图平台负责翻译成基础设施动作。2.2 会话原语和 Agent 的一次连续对话Agent 和传统 API 最本质的区别在于会话。普通 REST API 是无状态的每一次调用都是独立的但 Agent 与用户的交互是一段有开头、有上下文、有结尾的连续过程。Session 是 Agent 世界里最核心的原语之一它解决的是“这段对话应该记住什么”的问题。会话原语需要至少承担四个职责会话的创建与生命周期管理、上下文一致性、持久化、以及会话恢复。这个资源在运行时可以很简单就是一个带着 sessionId 的状态对象但它是整个 Agent 平台的基石。没有 SessionAgent 不过是一个接一个孤立的 Prompt 调用。实际实现里Session CRD 需要跟踪以下状态当前 Agent 引用、用户标识、上下文窗口内的消息历史、过期的摘要、以及最后活跃时间。当一段时间没有消息控制器就把这个 Session 归档释放 Worker 资源。当用户带着同一个 sessionId 回来控制器再从存储中恢复上下文让 Agent 继续之前的对话。这个能力远比“把容器重启一下”复杂但它是 Agent 应用体验的本质。2.3 记忆原语短中长期的分布式状态记忆是 Agent 最容易被忽略的原语。人们常把记忆理解为“把对话历史存到数据库”但真正的 Agent 记忆体系需要区分短期、中期和长期。短期记忆就是当前上下文窗口的内容中期记忆可以是对历史对话的摘要或者向量检索结果长期记忆则包含用户偏好、业务规则、领域知识。我在手工搭建 Agent 服务时经常看到把所有这些记忆塞进同一个 Redis Key 的做法。一开始没问题一旦并发会话变多、记忆量增大单个 Agent 实例就会频繁超时。更好的做法是把记忆抽象成独立的 memory store 原语由 Substrate 层提供统一的读写接口底层可以是向量数据库、关系型数据库、对象存储的组合。记忆原语的价值在于它让“记住什么、忘掉什么”成为平台策略而不是业务代码里的散乱逻辑。比如短期记忆可以放在本地缓存中期记忆根据 TTL 降级到分布式存储长期记忆通过定期离线任务写入冷存储。这些策略被抽象成 CRD 的配置项之后Agent 开发者只需要声明“这个 Agent 需要保留六个月内的用户偏好”不需要关心底层存储具体如何实现。2.4 工具与权限原语Agent 不只是聊天它还要调用外部系统。工具原语是对 Agent 所有外部能力的抽象包括 API 调用、数据库查询、浏览器操作、代码执行等。它相当于给 Agent 装上了“手脚”但手脚怎么用、能不能用、用得多频繁完全取决于权限边界。在设计 Tool 原语时有几个容易踩坑的点首先是默认拒绝原则任何工具在最开始都应该没有任何权限只有在 Agent CRD 里显式声明了才可使用其次是调用频率控制避免一个 Agent 因为推理循环失控对某个 API 发起每秒上百次的请求最后是审计日志所有工具调用都应该记录调用者、参数、结果和耗时方便后续追溯。工具原语还需要解决一个很大的问题动态注册。Agent 运行过程中可能需要临时加载一个插件如果都要重启 Pod 就太笨重了。把这个能力下沉到 Substrate 之后控制器可以监听 ToolBinding 资源的创建将新的工具定义热挂载到已经运行的 Agent 进程里而不打断现有会话。这一点在生产环境里非常实用。2.5 协作原语多 Agent 之间的“消息总线”多 Agent 协作是当前很热的主题但很多人把它实现成一种远程过程调用Agent A 调用 Agent B 的 HTTP 接口把任务丢过去。这么做的问题在于协作关系非常脆弱一旦某个 Agent 没有响应整个链路就断了。真正的多 Agent 协作应该基于消息和事件而不是直接调用函数。协作原语需要提供至少这些能力一个统一的主题命名空间每个 Agent 可以订阅自己关心的主题一个针对 Agent 间消息的数据结构可以携带调用方、目标方、任务上下文、结果回执一套可靠的消息投递机制保证消息不会因为 Agent 重启而丢失以及一个死信队列让失败的消息可以被接管和重试。在 K8s 环境里这个原语通常不能只靠 Service 解决。Service 解决的是“找到对方”但不解决“怎么可靠的把话说清楚”。你需要一个消息总线可以是 NATS、Kafka也可以是轻量级的 Redis Stream。Substrate 层的责任是把这套消息能力封装成一个 Agent 可以理解的语义级接口让 Agent 只关心消息的本体不关心 Topic 的持久化和消费者偏移量。2.6 控制原语把策略交给平台Agent 平台还必须有控制原语这是很多人没有意识到的。控制原语指的是那些对 Agent 行为进行限制的策略比如最大推理步数、成本预算、敏感操作二次确认、单会话最大 Token 数、以及对某些危险工具的禁用。我见过不少 Agent 事故几乎都是因为缺少控制原语。比如一个 Agent 在循环里反复调用同一个外部 API产生高额账单比如 Agent 在收到错误回执后不断重试删除操作差点把测试环境的数据清空。如果这些策略是写在 Agent 业务代码里的每次修改都要发版如果把策略下沉到 Substrate那运维人员只需要更新一个 Policy CRD控制器会自动把策略同步到相关的所有 Agent 实例上。控制原语的设计目标是把“Agent 不能做什么”这个决策从 Agent 内部剥离出来放到平台层。这样做的好处是安全策略可以被统一审计、统一测试也更容易满足合规要求。3. 在 K8s 上实现 Substrate 的架构思路3.1 复用 K8s 的哪个部分不重复哪个部分明确要在 K8s 之上造一层新原语首先要分清哪些能力直接复用哪些必须自己造。K8s 在资源调度、隔离、滚动更新、多租户隔离、RBAC 权限、以及可观测性上非常成熟这些应该直接拿来用不需要重造。而 Agent 的状态机、上下文存储、消息路由、工具管理、会话生命周期这些概念K8s 原生没有需要 Substrate 自己实现。一个常见的误解是“既然 K8s 有 CRD 和 Operator那我只需要写几个 CRD 就行了”。CRD 只是定义了一堆数据结构和校验规则真正的逻辑在控制器里。如果你只是定义 CRD而不写控制器那 Agent 资源只是一张永远不会被调度的表。所以架构核心是“K8s API Operator 模式 外部存储”其中 Operator 负担翻译和调谐的职责。架构上我会这样分层最底层是 K8s 集群本身提供计算资源和网络中间层是 Substrate 控制器通过监听 Agent 相关 CR 的创建、更新、删除生成对应的 Deployment、StatefulSet、Service、ConfigMap 等原生资源最上层是 Agent 运行时它运行在容器里但通过 Substrate 提供的 API 访问会话、记忆、工具等能力。这样 K8s 原生对象始终是执行体CRD 是我们暴露给业务层的语义。3.2 用 CRD 定义 Agent 资源在实现一个最小版本时我建议先只定义四个核心 CRDAgent、Session、ToolBinding、Message。不要一上来就定义几十个资源那样维护成本会爆炸。Agent 是最顶层的智能体定义包含模型、提示词、默认工具、资源限制、会话策略。Session 描述一次具体对话绑定 Agent、记录消息历史、维护上下文。ToolBinding 定义 Agent 可以使用的外部工具以及它的权限范围。Message 是 Agent 之间的通信单元也可以用在 Session 内记录事件流。定义 CRD 时要注意 Kubernetes API 规范至少需要给好 OpenAPI v3 schema 校验。否则用户创建一个缺少必填字段的 Agent 资源控制器要花很大力气去排查错误。下面是 CRD 的简化版本apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: agents.substrate.example.com spec: group: substrate.example.com scope: Namespaced names: plural: agents singular: agent kind: Agent versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object required: [model, systemPrompt] properties: model: type: string systemPrompt: type: string tools: type: array items: type: string这个示例把必填字段定义到了 API 层避免运行时错误。实际项目中还需要加状态子资源等这些都属于细节但一个好的 CRD 设计能让后续控制器的实现大幅简化。3.3 Controller 调谐逻辑Substrate 的核心是控制器。我建议用现有的 Operator 框架Python 生态里比较顺手的是 KOPFGo 生态是 controller-runtime。用 KOPF 写一个最小控制器代码很直接监听 Agent 事件然后创建对应的 StatefulSet。Agent 通常是有状态的所以我会用 StatefulSet 而不是 Deployment。StatefulSet 能让每个 Agent 实例有稳定的网络标识和存储身份这对会话恢复非常重要。控制器在创建 Agent 后根据 spec 生成一个 StatefulSet再生成一个 Service 暴露会话 API并把模型、系统提示词、工具列表写入 ConfigMap 或环境变量。下面是 KOPF 控制器的核心代码段import kopf import kubernetes kopf.on.create(substrate.example.com, v1, agents) def create_agent(spec, name, namespace, **kwargs): api kubernetes.client.AppsV1Api() statefulset { apiVersion: apps/v1, kind: StatefulSet, metadata: { name: fagent-{name}, namespace: namespace, labels: {app: agent, agent: name} }, spec: { serviceName: fagent-{name}, replicas: 1, selector: {matchLabels: {app: agent, agent: name}}, template: { metadata: {labels: {app: agent, agent: name}}, spec: { containers: [ { name: agent-runtime, image: agent-runtime:0.1, env: [ {name: MODEL, value: spec.get(model)}, {name: SYSTEM_PROMPT, value: spec.get(systemPrompt)} ] } ] } } } } api.create_namespaced_stateful_set(namespace, statefulset)这段代码只是示例但它展示了核心思路用户创建 Agent 资源控制器把它翻译成有状态的运行实例。调谐逻辑不只是创建还需要监听更新当 ToolBinding 添加新工具时控制器要更新 Agent 对应的配置并滚动更新 StatefulSet。这个过程利用了 Kubernetes 自身的滚动更新不需要自己实现“重启 Pod”的逻辑。3.4 事件驱动设计Agent 运行过程中会产生大量事件一个工具调用成功、一次推理完成、一个 Session 超时、一次消息投递失败。这些事件如果都写到日志里管理和分析会很困难。Substrate 层应该把事件当作一等公民统一标准化以后再处理后分发。K8s 的 watch 机制本身就适合做事件源。控制的 CRD 状态字段可以携带最新的事件信息外部系统通过监听 K8s API 获得事件流。内部的消息总线则承载高频事件比如 Agent 之间的推理消息、工具调用回执、实时变量变化。低频事件进入 K8s status高频事件进入消息总线这是一个比较好的分工。在设计事件驱动时要注意避免控制器被高频事件惊动。如果 Agent 每次推理步都更新 status控制器会频繁触发调谐造成不必要的资源开销。一个实用的做法是把高频事件放到独立的存储或总线只在状态发生显著性变化时才同步到 CRD status。这样既保持了 Kubernetes API 的可观测性又不会把控制器压垮。4. 动手搭一个最小可用的 Agent Substrate4.1 环境准备纸上谈兵没意思我建议直接动手。一个单节点的 k3s 集群就够用如果只想在本地折腾用 kind 也可以。还需要一个能跑控制器的地方代码用 Python安装 kopf 依赖和 kubernetes client。为了存储会话和记忆可以快速起一个 mini 的 Redis 或者直接用 SQLite 跑在 Agent Pod 里MVP 阶段不需要过度设计。环境准备的大致步骤# 创建 k3s 单节点集群 curl -sfL https://get.k3s.io | sh - export KUBECONFIG/etc/rancher/k3s/k3s.yaml # 安装控制器的 Python 依赖 pip install kopf kubernetes pyyaml这里的要点是确保控制器能访问集群 API。本地开发时我一般把 kubeconfig 挂到环境变量里方便快速联调。生产环境则建议把控制器部署在集群内用 ServiceAccount 做认证。4.2 创建 CRD 的步骤集群就绪之后先把之前定义的 Agent CRD 应用进去kubectl apply -f crd.yaml然后验证一下kubectl get crd agents.substrate.example.com如果显示 Established说明 CRD 已经注册成功接下来就可以创建 Agent 资源。建议先用一个最简单的 Agent 测试比如一个连模型都不接的假 Agent只让它输出固定的响应用于验证控制器是否能把它翻译成 StatefulSet。创建 Agent 资源后观察控制器日志kubectl logs -f deployment/substrate-controller正常日志里会看到类似“创建 StatefulSet agent-test”的输出。这一步跑通说明 Agent 原语的声明式创建链路已经通了。4.3 实现 Pod 生成和会话绑定很多 Agent 运行时需要共享同一个会话上下文所以我会在 Agent Pod 里塞一个 sidecar专门处理 Session 的读写。这个设计让 Agent 主进程可以无状态地处理推理有状态的上下文全部交给 sidecar 和外部存储降低了 Agent 实例的耦合度。控制器在生成 StatefulSet 时可以往 Pod 模板里增加一个容器比如一个监听 8080 端口的 session-server。Agent 主进程每次收到用户请求先把请求连同 sessionId 发给 sidecar由 sidecar 从 Redis 中读取历史消息拼成上下文再让主进程调用模型。这个过程简化了 Agent 代码的职责状态管理收敛到 Substrate 层。会话绑定还涉及生命周期清理。当 Session TTL 到期或用户显式结束会话控制器可以删除对应的 Sidecar 会话缓存或者标记 Session CR 为 expired。MVP 阶段可以只在 Session CR 的 status 中记录最后活跃时间由定时任务统一清理避免为每个会话都维护一个定时器。4.4 演示运行效果我实际跑通一遍是这样的先创建 Agent 资源后StatefulSet 自动出现然后用一个临时 curl 命令给它发一条“你好我是张三”Agent 返回“你好张三我能帮你什么”。接着把 StatefulSet 删掉控制器自动重建一个新的 Pod再用同一个 sessionId 发消息Agent 直接说“张三你好我们刚才见过”。这句话说明会话上下文已经从 Redis 恢复Agent 没有因为 Pod 重启而失忆。这一步演示的核心价值是告诉读者Agent 的无状态重启是可以实现的但需要 Session 原语配合。没有 Session 原语单纯依赖 K8s 的 Pod 重启永远达不到这个效果。多 Agent 通信的最小实现大概这样在 Agent 的 spec 里声明一个订阅主题比如support-ticket.created。控制器创建 Agent Pod 时往 pod 环境变量里注入一个消费这个主题的配置。Agent 运行时收到消息事件触发自己的处理逻辑。两个 Agent 之间不需要互相知道 IP 地址只需要知道业务事件的主题这样协作就解耦了。4.5 多 Agent 通信的最小实现消息总线我建议用 NATS体量轻而且部署简单。在 K8s 里可以快速部署一个 NATS 服务Substrate 控制器把 NATS 地址注入所有 Agent Pod。消息格式定义一个统一的 Schema至少要包含事件类型、来源、目标、载荷、追踪 ID 五个字段。Agent 处理和发布消息的流程收到消息从对应主题消费事件把载荷解析后合并到当前上下文触发模型推理。发出消息Agent 推理过程中决定调用其他 Agent 或触发外部流程向指定主题发布消息。重试与失败如果目标 Agent 没有回复发布者带着追踪 ID 把任务放到重试队列或者触发超时补偿逻辑。这个实现不需要每个 Agent 都开放一个 Service不需要知道协作对象的 Pod IP也不需要自己封一套消息协议。消息总线把通信彻底从 Agent 业务逻辑中剥离这一点在多 Agent 规模扩大后会显得越来越重要。5. 踩坑记录与排查指南5.1 Controller 自愈反而导致记忆丢失最典型的坑是“K8s 帮我重启 Pod结果我的 Agent 失忆了”。原因是 Agent 进程将上下文写在了本地内存Pod 一重启就什么都没有了。K8s 层面的自愈是对的但业务层没有同步恢复状态体验就崩了。解决思路比较明确记忆和 Session 必须落到 Pod 外部这样 Pod 无论怎么重建只要 sessionId 不变就能从持久化存储恢复上下文。实际操作中还要注意 Agent 的启动流程。建议在启动阶段先注册到 Substrate 的服务发现然后拉取所有活跃 Session 的元数据而不是等第一个请求进来了再恢复。这样第一个返回消息就不会出现“我不记得你是谁”的尴尬。5.2 调谐循环与 Agent 推理过程互相打架控制器会持续 watch 所有 CR 的状态如果 Agent 在一次推理过程中频繁更新 status控制器可能以为对象发生变化然后触发滚动更新直接把正在工作的 Pod 替代掉。这个问题在库存系统上很容易忽视但发生一次就是重大事故。我的做法是给 Agent 资源增加一个状态锁当 Agent 正在处理会话时status 里标记busy: true控制器看到这个标记后只更新其他子资源不主动滚动更新主 Pod。只有 busy 状态结束控制器才评估是否需要重排。这个锁不一定需要 CRD 强制只要控制器遵守约定就行但一定要写在实现文档里。5.3 事件总线背压Agent 之间通信频率上来后消息很可能会出现积压。NATS 或 Kafka 自身有 backpressure但如果不处理Agent 消费端会因为处理太慢导致延迟越来越大。我遇到过 Agent 拿到的消息已经是三分钟前的旧事件推理结果自然没有意义。解决方案有三类给消息设置 TTL超时消息直接丢弃给消费组设置水位线积压超过一定数量时触发降级策略以及控制发布频率在 Agent 推理循环里加入节流。这些都是 Substrate 层可以做的策略不需要每个 Agent 自己实现。5.4 权限设计遗漏很多 Agent 平台上线后出的第一个事故都是权限问题。某个 Agent 拥有数据库的删除权限一次工具调用把整张表清空。原因多半是 ToolBinding 的权限模型太粗糙只有“允许”和“拒绝”两级。工具权限至少应该分读、写、执行、删除四类并且每个权限都要绑定到具体的 API 路径或数据表而不是整个数据库。Substrate 层还需要默认拦截高风险操作。比如在执行任何 delete 操作之前要求 Agent 发送一个“待确认事件”由人工审批或者策略引擎自动审批。有了这层控制原语单纯靠 Prompt 约束模型的误操作问题终于能在基础设施层面得到收敛。5.5 原语过多导致心智负担最后一个坑是自己给自己挖的。造 Agent Substrate 的时候容易陷入“把一切都做成 CRD”的冲动。Agent 做了 CRDSession 做了 CRDMessage 做了 CRD不够Event 也做Policy 也做知识库也做目录也做。结果就是没有一个开发者能记得住几十种资源的字段用户创建资源光看 schema 就要看半天。做 MVP 时我用 Programmer 简单原则约束自己先把 Agent、Session、ToolBinding、Message 四个核心原语跑通其他能力都以这四个原语的组合方式表达。比如知识库可以当成一个 ToolBinding 指向外部向量库比如事件策略可以放在 Agent 的 spec 里。原语多了以后如果不是有极强的生态规划最后基本都会变成负担而不是生产力。6. 一些个人体会把 Agent Substrate 想在 K8s 上做一层新原语听起来像是在给本已庞大的 Kubernetes 生态“叠床架屋”但真正深入之后会发现容器编排层和智能体执行层解决的根本不是同一个问题。K8s 擅长管理进程、网络、存储这类基础设施Agent 需要的是会话、记忆、工具权限、多智能体协作这些更高层次的语义。两者不是替代关系而是互补关系。我个人在实际操作中的体会是不要一上来就搭建一个完整的 Agent 平台。先做一个最简单的 Substrate只提供 Agent 和 Session 两个原语把你的现有 Agent 跑上去。等真正发现缺什么再逐步往上面加 ToolBinding 和消息总线。这个过程一定要保持“声明式”原则任何 Agent 状态都应该能用kubectl get agents一眼看到这样排查问题会轻松很多。最后再分享一个小技巧不管你的 Substrate 最终用多少原语一定要让所有 Agent 的运行时信息都暴露在 K8s 事件流里。很多 Agent 故障往往不是模型问题而是平台层的资源调度和状态同步问题。把这些信息统一纳管到 K8s你的 Debug 效率会上升一个量级。